Hi Matthew! I see ... so there is an alternate method for the kernel to find its system volume by not using the dynamically built /dev/sdX names? I'll dig into that, thanks for the pointer! Back to the original topic ... do you have any news with regard to putting the code back into the sym8xx driver that reads the user configured channel/device negotiation settings (transfer speed and width limits, timeouts, disconnect, etc. etc.) from the EEPROM? This is really causing headaches here with those setups that use external devices, slightly buggy devices, long cables and similar stuff where the auto-detected defaults aren't working. Many thanks! regards, Peter On Saturday 09 April 2005 16:02, Matthew Wilcox wrote: > On Sat, Apr 09, 2005 at 12:57:22AM +0200, Peter Missel wrote: > > It also makes the driver ignore the adapter ordering in multiple-channel > > setups. This machine here has an LSI 21002, where the LVD channel is on > > device function 1 and the UW channel is on 0. Naturally the user will set > > the adapter order in BIOS such that the system HDD (on the LVD channel) > > becomes /dev/sda regardless of other drives on the UW channel. Now, with > > the latest driver releases ignoring this BIOS adjustment, the channels > > are scanned in order of appearance on the PCI bus rather than in the > > order the user wants ... in this case, the LVD channel ends up becoming > > sym1, which means that whenever I connect my external MO drive to the > > U/UW channel, I get a kernel panic because Linux can't find its system > > volume. > > This is an inevitable consequence of conversion to the pci_driver model. > So it's a choice: either support this or support hotplug. I chose to > support hotplug. This isn't a problem specific to sym2, it's something > that all scsi systems face. The intended way to solve this is to use > a UUID or label to mount your root fs. Unfortunately, this means you > have to use an initrd. > > Yes, this sucks and isn't nearly as easy to configure as it needs to be. > But there really is no way around it -- I can't control what order the > devices are discovered in. - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
