https://bugzilla.novell.com/show_bug.cgi?id=474879
User teheo@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=474879#c9
Tejun Heo changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
Info Provider| |DOlsson@WEB.de
--- Comment #9 from Tejun Heo 2009-02-25 01:13:38 MST ---
Hello, sorry about the delay.
* Highpoint controllers curiously share the same PCI ID for completely
different controllers. So, the driver loader (udev in this case) doesn't know
in prior which driver to load. Only the drivers themselves can determine
whether they can drive the controller during initialization, so they take turn
until the correct one (pata_hpt3x2n in this case) grabs the controller. And
the hpt366 driver is the original IDE driver which is there only for debugging
and falling back when the new libata ones don't work as in your case.
* Device names are not guaranteed to be stable. libata no longer pre-allocates
device nodes to specific port as IDE did (just can't do it in reasonable way
anymore). It generally stays stable with PCI devices but there is no
guarantee. USB probing is done asynchronously, so depending on luck, it can
end up anywhere. Plus, with upcoming parallel libata probing, things will get
even more dynamic. So, devices should be selected via unique device ID (the
default) or filesystem labels. This also allows putting in extra controllers
or moving drives around can be done without worrying about device node renames.
* There are still some rough edges on a few libata drivers for old PATA
controllers, mostly due to lack of hardware availability and test coverage.
Are you interested in shipping the controller to me so that I can work on it?
I'll pay for the shipping + replacement controller.
Thanks.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.