From: Matthew Wilcox <matthew@wil.cx>
To: Peter Missel <peter.missel@onlinehome.de>
Cc: Matthew Wilcox <matthew@wil.cx>, linux-scsi@vger.kernel.org
Subject: Re: SYM8xx_2 driver ignores certain EEPROM settings
Date: Sat, 9 Apr 2005 15:02:18 +0100 [thread overview]
Message-ID: <20050409140218.GC8669@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <200504090057.22687.peter.missel@onlinehome.de>
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.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
next prev parent reply other threads:[~2005-04-09 14:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200412311343.42484.peter.missel@onlinehome.de>
2004-12-31 14:53 ` SYM8xx_2 driver ignores certain EEPROM settings Matthew Wilcox
2004-12-31 15:01 ` James Bottomley
2004-12-31 15:20 ` Peter Missel
2005-01-01 22:16 ` Matthias Andree
2005-01-02 0:28 ` Peter Missel
2005-01-02 0:40 ` Matthias Andree
2005-01-02 1:03 ` Matthew Wilcox
2005-01-02 9:58 ` Peter Missel
2005-02-26 19:34 ` Peter Missel
2005-04-08 22:57 ` Peter Missel
2005-04-09 14:02 ` Matthew Wilcox [this message]
2005-04-09 21:44 ` Peter Missel
2005-04-18 17:55 ` Peter Missel
2005-05-04 21:47 ` SYM8xx_2 sync speed negotiation Peter Missel
2005-06-18 21:52 ` Peter Missel
2005-06-19 10:45 ` endless loop problem with SYM8xx_2: unexpected disconnect Christian Werner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050409140218.GC8669@parcelfarce.linux.theplanet.co.uk \
--to=matthew@wil.cx \
--cc=linux-scsi@vger.kernel.org \
--cc=peter.missel@onlinehome.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox