No IDE drivers loaded for Toshiba Satellite 320 CDS

No IDE drivers loaded for Toshiba Satellite 320 CDS

[Frans Pop]

Hi,

We've received an installation report for Debian for an older system where
no IDE driver gets loaded. The system does not have any IDE device listed in
lspci. When ide-generic is modprobed manually, both the CD and hard disk
work fine.

Any suggestions on how such a system could be recognized?
If we could do that, the installation system could take responsibility for
loading ide-generic and making sure it is included in the initrd.

Or even better, any chance to make the kernel/udev load ide-generic
automatically for this system?

See http://bugs.debian.org/472487 for details. I can get additional info
from the owner of the system if needed.

Cheers,
FJP

Output of lspci -nn:
00:00.0 Host bridge [0600]: Toshiba America Info Systems CPU to PCI bridge [1179:0601] 
(rev a0)
00:04.0 VGA compatible controller [0300]: Chips and Technologies F65555 HiQVPro 
[102c:00e5] (rev c6)
00:0b.0 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 02)
00:11.0 Communication controller [0780]: Toshiba America Info Systems FIR Port 
[1179:0701] (rev 21)
00:13.0 CardBus bridge [0607]: Toshiba America Info Systems ToPIC97 [1179:060f] (rev 
20)
00:13.1 CardBus bridge [0607]: Toshiba America Info Systems ToPIC97 [1179:060f] (rev 
20)

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Frans Pop]

On Wednesday 02 April 2008, Frans Pop wrote:
> We've received an installation report for Debian for an older system
> where no IDE driver gets loaded. The system does not have any IDE device
> listed in lspci. When ide-generic is modprobed manually, both the CD and
> hard disk work fine.

Forgot to mention that the kernel used was 2.6.22. A retry with 2.6.24 
should be possible if needed.

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Lennart Sorensen]

On Wed, Apr 02, 2008 at 03:24:26PM +0200, Frans Pop wrote:
> We've received an installation report for Debian for an older system where
> no IDE driver gets loaded. The system does not have any IDE device listed in
> lspci. When ide-generic is modprobed manually, both the CD and hard disk
> work fine.
> 
> Any suggestions on how such a system could be recognized?
> If we could do that, the installation system could take responsibility for
> loading ide-generic and making sure it is included in the initrd.
> 
> Or even better, any chance to make the kernel/udev load ide-generic
> automatically for this system?
> 
> See http://bugs.debian.org/472487 for details. I can get additional info
> from the owner of the system if needed.
> 
> Cheers,
> FJP
> 
> Output of lspci -nn:
> 00:00.0 Host bridge [0600]: Toshiba America Info Systems CPU to PCI bridge [1179:0601] 
> (rev a0)
> 00:04.0 VGA compatible controller [0300]: Chips and Technologies F65555 HiQVPro 
> [102c:00e5] (rev c6)
> 00:0b.0 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 02)
> 00:11.0 Communication controller [0780]: Toshiba America Info Systems FIR Port 
> [1179:0701] (rev 21)
> 00:13.0 CardBus bridge [0607]: Toshiba America Info Systems ToPIC97 [1179:060f] (rev 
> 20)
> 00:13.1 CardBus bridge [0607]: Toshiba America Info Systems ToPIC97 [1179:060f] (rev 
> 20)

How old is that system?  Maybe the IDE isn't even PCI based.  That would
explain why nothing shows in lspci, but the IDE ports are still present
and working.

One could always just manually tell the system to always load
ide-generic, since deciding what to load does seem to be a userspace
choice these days.

-- 
Len Sorensen

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Frans Pop]

On Wednesday 02 April 2008, Lennart Sorensen wrote:
> How old is that system?

Not sure. As the system only has 32MB RAM I'd say sometime late 1990s.

> Maybe the IDE isn't even PCI based.  That would explain why nothing shows
> in lspci, but the IDE ports are still present and working.

Could be. What would it be then? ISA? Any way to recognize that?

I did find a product page, but it's low on real specs:
http://www.toshiba.ca/web/product.grp?lg=en&section=1&group=223&product=1605

> One could always just manually tell the system to always load
> ide-generic, since deciding what to load does seem to be a userspace
> choice these days.

Well, in the Debian Installer we prefer to load things automatically 
whenever possible. If the kernel does not do it, that's fine.

But to have the installer itself automatically load ide-generic for the 
user, we'd still have to somehow recognize that we need the driver.
Any ideas/suggestions what to look for?

Cheers,
FJP

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Lennart Sorensen]

On Wed, Apr 02, 2008 at 04:29:40PM +0200, Frans Pop wrote:
> Not sure. As the system only has 32MB RAM I'd say sometime late 1990s.

Well if Win95 was preinstalled, and being a 233MMX, then probably around
1997 or 1998, although just before Win98 came out I imagine.

> Could be. What would it be then? ISA? Any way to recognize that?

Yeah ISA seems likely.

Given IDE says PIO mode only, it sure isn't a busmastering IDE
controller.

> I did find a product page, but it's low on real specs:
> http://www.toshiba.ca/web/product.grp?lg=en&section=1&group=223&product=1605
> 
> Well, in the Debian Installer we prefer to load things automatically 
> whenever possible. If the kernel does not do it, that's fine.

I am sure the debian installer used to always load ide-generic after
trying everything else.  There was probably a reason for that.  You
never have been able to detect isa devices releably (even after pnp was
invented).  Certainly the debian installer in 2.0 worked fine when I
installed my 486.  Having reinstalled (only upgraded) ever since, I
can't say if the installer would still work on it (I just figured it
probably would).  I could try it out again though.

> But to have the installer itself automatically load ide-generic for the 
> user, we'd still have to somehow recognize that we need the driver.
> Any ideas/suggestions what to look for?

If you can't see any other disks, load it.  Heck load it last no matter
what since any supported IDE ports should have already had their driver
loaded, so worst case it does nothing in which case the autoclean of
unneeded kernel modules could remove it again, and best case it finds an
old isa/vlb style IDE controller on the standard port numbers and works
with it.

-- 
Len Sorensen

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Frans Pop]

On Wednesday 02 April 2008, Lennart Sorensen wrote:
> I am sure the debian installer used to always load ide-generic after
> trying everything else.  There was probably a reason for that.  You
> never have been able to detect isa devices releably (even after pnp was
> invented).

Well, what the installer used to do for Sarge and Etch was basically to load 
_all_ drivers (including ide-generic) manually by default, which is totally 
useless as most devices are perfectly autodetected nowadays. It also wastes 
memory as you'd end up having a lot of unused drivers in memory.

Post-etch we decided to change that and currently drivers are only loaded if 
autodetected (with some exceptions, such as for sparc sbus and hppa bus). 
We were aware that this could cause some regressions, but so far this is the 
first real report.

Another change in Debian since Etch is that initramfs-tools no longer loads 
ide-generic by default, which IMO is also a good thing. We can easily make 
it load ide-generic when needed, but for that again we first have to know 
that it _is_ needed.

> > But to have the installer itself automatically load ide-generic for the
> > user, we'd still have to somehow recognize that we need the driver.
> > Any ideas/suggestions what to look for?
>
> If you can't see any other disks, load it.

Yes, that could be one way to implement it: load it and then check if that 
added any devices.

> Heck load it last no matter 
> what since any supported IDE ports should have already had their driver
> loaded, so worst case it does nothing in which case the autoclean of
> unneeded kernel modules could remove it again, and best case it finds an
> old isa/vlb style IDE controller on the standard port numbers and works
> with it.

That would still leave us with the problem of not knowing whether it needs 
to be added for initramfs-tools or not.

If there are no other suggestions, I guess we'll go with a "load and check" 
implementation. Thanks a lot for your input.

Anybody know how other distributions deal with this?

Cheers,
FJP

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Lennart Sorensen]

On Wed, Apr 02, 2008 at 06:20:03PM +0200, Frans Pop wrote:
> Well, what the installer used to do for Sarge and Etch was basically to load 
> _all_ drivers (including ide-generic) manually by default, which is totally 
> useless as most devices are perfectly autodetected nowadays. It also wastes 
> memory as you'd end up having a lot of unused drivers in memory.
> 
> Post-etch we decided to change that and currently drivers are only loaded if 
> autodetected (with some exceptions, such as for sparc sbus and hppa bus). 
> We were aware that this could cause some regressions, but so far this is the 
> first real report.
> 
> Another change in Debian since Etch is that initramfs-tools no longer loads 
> ide-generic by default, which IMO is also a good thing. We can easily make 
> it load ide-generic when needed, but for that again we first have to know 
> that it _is_ needed.

Well, my educated guess (and that's all it is) is that any system with a
386, 486 or pentium might have an ISA based IDE controller.  For that
matter I used to have an ISA based IDE controller on my sound card in a
PPro, although that one was PnP capable (although I always ran with that
disabled because it sucked).

Essentially if you have an ISA bus there could be an IDE controller
there.  No way to really know without probing the standard IDE ports,
which is pretty much what ide-generic does as far as I can tell.  I
think many architectures other than x86 also have generic IDE
controllers that are supported as long as ide-generic is loaded with the
architecture specific code having defined the ports to look at.

> Yes, that could be one way to implement it: load it and then check if that 
> added any devices.

Well even if you see other disks doesn't mean you don't also have an old
IDE controller you want to use, so probably load it and see if it finds
any disks is the best bet after loading all the other probeable drivers
first.

> That would still leave us with the problem of not knowing whether it needs 
> to be added for initramfs-tools or not.
> 
> If there are no other suggestions, I guess we'll go with a "load and check" 
> implementation. Thanks a lot for your input.

I think that's the best you can do.

> Anybody know how other distributions deal with this?

I gave up other distributions for Debian in 1999, so I can't help there.

-- 
Len Sorensen

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Frans Pop]

On Wednesday 02 April 2008, Lennart Sorensen wrote:
> > Yes, that could be one way to implement it: load it and then check if
> > that added any devices.
>
> Well even if you see other disks doesn't mean you don't also have an old
> IDE controller you want to use, so probably load it and see if it finds
> any disks is the best bet after loading all the other probeable drivers
> first.

I've decided (at least for now) to only do this f /sys/bus/isa is present.
I added a check to see if there are additional devices in /sys/block after 
loading ide-generic to decide whether or not to also include it in the 
initrd for the installed system.

/sys/bus/isa is present for this machine so it works even if (as Ondrej 
suggests) the controller is not actually on the ISA bus. We can always 
extend the test if it turns out systems without ISA bus are also affected.

I'll also send out a call for testing specifically for this issue.

Thanks to you and Ondrej for the discussion.

Cheers,
FJP

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Lennart Sorensen]

On Thu, Apr 03, 2008 at 07:47:06PM +0200, Frans Pop wrote:
> I've decided (at least for now) to only do this f /sys/bus/isa is present.
> I added a check to see if there are additional devices in /sys/block after 
> loading ide-generic to decide whether or not to also include it in the 
> initrd for the installed system.

I am just wondering if arm, m68k, etc might have IDE ports that work
with ide-generic.  I have no idea to be quite honest.

> /sys/bus/isa is present for this machine so it works even if (as Ondrej 
> suggests) the controller is not actually on the ISA bus. We can always 
> extend the test if it turns out systems without ISA bus are also affected.

Hmm, I must admit my newest x86 does in fact not have a /sys/bus/isa.  I
guess it really does not have anything left resembling ISA.

> I'll also send out a call for testing specifically for this issue.

I can certainly give the installer a shot on my 486, if I can manage to
boot it somehow.  Any floppy images for the installer around anymore? :)

Do I have to put a disk image on a harddisk and boot from that?  CD and
network boot are not an option.

-- 
Len Sorensen

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Frans Pop]

On Thursday 03 April 2008, Lennart Sorensen wrote:
> I am just wondering if arm, m68k, etc might have IDE ports that work
> with ide-generic.  I have no idea to be quite honest.

I plan to mention other arches in the call for testing, so I guess we'll 
find out.

> I can certainly give the installer a shot on my 486, if I can manage to
> boot it somehow.  Any floppy images for the installer around anymore? :)

Of course there are ;-)
http://ftp.debian.org/debian/dists/lenny/main/installer-i386/current/images/floppy/

These use 2.6.22. They don't have the fix I just implemented though. If the 
IDE controller is not detected, try booting the installer with 
hw-detect/load-ide=true
The daily built images, which do have the fix, use 2.6.24, but the increase 
in the size of the kernel causes the boot floppy to be too big so 
installing from floppy is currently not possible. We're working on fixing 
that.

> Do I have to put a disk image on a harddisk and boot from that?

That's an alternative. Use either the netboot or hd-media images for that, 
and it means that you could use a daily image. With the hd-media images 
you'll also need to copy a CD image on the hard disk.

Cheers,
FJP

(Apologies to the list for the somewhat OT post, suggest we follow up 
privately if needed.)

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Tejun Heo]

Frans Pop wrote:
> On Wednesday 02 April 2008, Lennart Sorensen wrote:
>>> Yes, that could be one way to implement it: load it and then check if
>>> that added any devices.
>> Well even if you see other disks doesn't mean you don't also have an old
>> IDE controller you want to use, so probably load it and see if it finds
>> any disks is the best bet after loading all the other probeable drivers
>> first.
> 
> I've decided (at least for now) to only do this f /sys/bus/isa is present.
> I added a check to see if there are additional devices in /sys/block after 
> loading ide-generic to decide whether or not to also include it in the 
> initrd for the installed system.
> 
> /sys/bus/isa is present for this machine so it works even if (as Ondrej 
> suggests) the controller is not actually on the ISA bus. We can always 
> extend the test if it turns out systems without ISA bus are also affected.
> 
> I'll also send out a call for testing specifically for this issue.
> 
> Thanks to you and Ondrej for the discussion.

Please be advised that some modern controllers are dual interfaced. 
Native one and legacy one.  The legacy one is SFF compliant and 
depending on configuration may appear at legacy IO addresses, so if you 
aren't careful, you can end up with two drivers driving the same 
hardware which usually doesn't end too well.  Loading generic drivers 
w/o knowing that it's needed is quite dangerous.  I would strongly 
advise against it.

-- 
tejun

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Frans Pop]

On Sunday 13 April 2008, Tejun Heo wrote:
> Please be advised that some modern controllers are dual interfaced.
> Native one and legacy one.  The legacy one is SFF compliant and
> depending on configuration may appear at legacy IO addresses, so if you
> aren't careful, you can end up with two drivers driving the same
> hardware which usually doesn't end too well.  Loading generic drivers
> w/o knowing that it's needed is quite dangerous.  I would strongly
> advise against it.

I totally agree. The problem being discussed here is exactly how to know it 
is needed. If you have better suggestions for that, I'd appreciate it.

As you specifically say "modern controllers", I suspect that the problem is 
limited as I guess those are fairly unlikely to be found in machines that 
have an ISA bus.

I also think the way I've implemented in the Debian installer should be 
relatively safe:
1) ide-generic is only loaded _after_ any otherwise detected modules
2) it is only loaded if an ISA bus is present
3) it is only included in the initrd for the installed system if loading it
   in the installer resulted in additional block devices appearing

I would unload ide-generic in the installer if no additional block devices 
appear, but unfortunately that's not possible as it is marked "permanent".

By loading it after any other drivers I expect there will be no issues 
during the installation (as the other driver will already have claimed the 
device). Making sure it is only loaded for the installed system if actually 
needed should avoid problems there.

ATM I can only see this causing problems in systems that need both 
ide-generic and some other driver as adding ide-generic in the initrd is 
likely to result in it being loaded before that other driver.

Again, if anyone has a better suggestion how to implement this (preferably 
without asking the user whether he has a device that needs ide-generic, 
which most users are unlikely to know anyway), I'd appreciate it.

Cheers,
FJP

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Lennart Sorensen]

On Sun, Apr 13, 2008 at 03:59:20PM +0200, Frans Pop wrote:
> I totally agree. The problem being discussed here is exactly how to know it 
> is needed. If you have better suggestions for that, I'd appreciate it.
> 
> As you specifically say "modern controllers", I suspect that the problem is 
> limited as I guess those are fairly unlikely to be found in machines that 
> have an ISA bus.
> 
> I also think the way I've implemented in the Debian installer should be 
> relatively safe:
> 1) ide-generic is only loaded _after_ any otherwise detected modules
> 2) it is only loaded if an ISA bus is present
> 3) it is only included in the initrd for the installed system if loading it
>    in the installer resulted in additional block devices appearing

OK, great for x86 perhaps, what about other systems?

> I would unload ide-generic in the installer if no additional block devices 
> appear, but unfortunately that's not possible as it is marked "permanent".
> 
> By loading it after any other drivers I expect there will be no issues 
> during the installation (as the other driver will already have claimed the 
> device). Making sure it is only loaded for the installed system if actually 
> needed should avoid problems there.
> 
> ATM I can only see this causing problems in systems that need both 
> ide-generic and some other driver as adding ide-generic in the initrd is 
> likely to result in it being loaded before that other driver.

In the past debian would load ide-generic last.  It worked great.  Keep
doing that.  I am not aware of loading ide-generic after all the other
drivers ever causing any harm in the older debian installers.

> Again, if anyone has a better suggestion how to implement this (preferably 
> without asking the user whether he has a device that needs ide-generic, 
> which most users are unlikely to know anyway), I'd appreciate it.

I would say just load the generic driver and let it grab whatever other
drivers haven't already.  If this causes a problem, then there is a
kernel bug to be fixed.  It shouldn't be the installers problem.  After
all what happens if ide-generic and all the other drivers are built in
rather than modules?  If that broke then the kernel already has issues,
and as far as I can tell that isn't a problem.

So just load it.  If it didn't cause any additional ide ports to appear,
then you can unload it again.

-- 
Len Sorensen

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Alan Cox]

> > 1) ide-generic is only loaded _after_ any otherwise detected modules

That is the correct approach, as with libata and ata_generic/pata_legacy

> > 2) it is only loaded if an ISA bus is present

All PC class systems have an ISA bus, it may be on the main board and
called LPC but it is there.

> > 3) it is only included in the initrd for the installed system if loading it
> >    in the installer resulted in additional block devices appearing
> 
> OK, great for x86 perhaps, what about other systems?

Should be valid for all sane ISA bus systems. The IDE legacy code as per
arch probe rules.

> > I would unload ide-generic in the installer if no additional block devices 
> > appear, but unfortunately that's not possible as it is marked "permanent".

Yes - old IDE doesn't do hotplugging, libata can so your approach would
work there.


Alan

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Frans Pop]

On Monday 14 April 2008, Alan Cox wrote:
> > > 2) it is only loaded if an ISA bus is present
>
> All PC class systems have an ISA bus, it may be on the main board and
> called LPC but it is there.

The actual test is if /sys/bus/isa exists, which it does not at least on my 
current PC class desktop (em64t).
My 4 year old laptop (i386) does have it though.

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Frans Pop]

On Monday 14 April 2008, you wrote:
> > I also think the way I've implemented in the Debian installer should be
> > relatively safe:
> > 1) ide-generic is only loaded _after_ any otherwise detected modules
> > 2) it is only loaded if an ISA bus is present
> > 3) it is only included in the initrd for the installed system if
> > loading it in the installer resulted in additional block devices
> > appearing
>
> OK, great for x86 perhaps, what about other systems?

As I've said before, that needs testing.

> In the past debian would load ide-generic last.  It worked great.  Keep
> doing that.  I am not aware of loading ide-generic after all the other
> drivers ever causing any harm in the older debian installers.

Maybe not, but having it loaded in _every_ installed Debian system even when 
it was completely unused is definitely something we want to get rid of.

Note that the old behavior relied on the fact that initramfs-tools also 
loaded ide-generic by default, which it now no longer does.

Cheers,
FJP

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Lennart Sorensen]

On Sun, Apr 13, 2008 at 11:39:04AM +0900, Tejun Heo wrote:
> Please be advised that some modern controllers are dual interfaced. 
> Native one and legacy one.  The legacy one is SFF compliant and 
> depending on configuration may appear at legacy IO addresses, so if you 
> aren't careful, you can end up with two drivers driving the same 
> hardware which usually doesn't end too well.  Loading generic drivers 
> w/o knowing that it's needed is quite dangerous.  I would strongly 
> advise against it.

If you can't safely load the generic driver then the kernel is very
broken and needs fixing.

After all there is no reason I couldn't have multiple IDE controllers,
some of which have dual interfaces, and some of which only have the old
generic interface (like the IDE port on my old ISA sound card).

If a driver supports a device with dual interfaces, then it better
reserve both sets of ports to prevent the generic driver from trying to
use them.

-- 
Len Sorensen

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Alan Cox]

> If a driver supports a device with dual interfaces, then it better
> reserve both sets of ports to prevent the generic driver from trying to
> use them.

That isn't the problem. The generic driver doesn't know if there is
another valid driver for the ports - how can it - and the other driver
may not be loaded first so cannot reserve the ports. If you load the
generic driver last then you should be fine, and the link order for IDE
and libata puts acpi, pci generic and legacy at the end for good reason.

Libata pata_legacy has some smarts in this area but they are only good
for the common cases.

Alan

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Tejun Heo]

Alan Cox wrote:
>> If a driver supports a device with dual interfaces, then it better
>> reserve both sets of ports to prevent the generic driver from trying to
>> use them.
> 
> That isn't the problem. The generic driver doesn't know if there is
> another valid driver for the ports - how can it - and the other driver
> may not be loaded first so cannot reserve the ports. If you load the
> generic driver last then you should be fine, and the link order for IDE
> and libata puts acpi, pci generic and legacy at the end for good reason.
> 
> Libata pata_legacy has some smarts in this area but they are only good
> for the common cases.

Always loading generic or ata_generic used to be safe.  It's still 
pretty safe but not as much as before.  Nowadays, there are good number 
of controllers which have dual interfaces.  Usually an ahci interface 
and a legacy one but there are other controllers which also implement 
dual interface.

Because PCI BARs usually contain IO regions for legacy interface in PCI 
BAR 0-4, the native driver can work it out by claiming all PCI BARs on 
attach, which I learned the hard way after seeing the generic driver 
borking the native one on certain configurations.  The thing I'm worried 
about is that there are a lot of vendors making this type of controllers 
nowadays and a lot of BIOS implementations for each of them.  And of 
course each BIOS implementation has its own many ways of configuring the 
dual mode (or more thanks to fake RAIDs) controller.

I wouldn't be too surprised if one of those plethora of configurations 
gets the compatible IO port and BAR configurations mismatched. 
Especially when the controller is put into native mode.  It's entirely 
possible to leave the compatible IO ports enabled while not setting the 
PCI BARs accordingly.  Some of them might even think that's better to 
prevent IDE drivers from attaching to it.

So, I don't really want to depend on that.  I don't know.  Do I sound 
paranoid?

-- 
tejun

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Alan Cox]

> Always loading generic or ata_generic used to be safe.  It's still 
> pretty safe but not as much as before.  Nowadays, there are good number 

ata_generic is always safe unless you force it to grab every class
device. By default it grabs only those devices we know obey the class
interface well enough and for which we have no proper driver (usually
because there are no documents). Ditto for ide/pci/generic.

The trickier one is pata_legacy, which tries to be smart and knows about
the known exception so *should* always be safe. The old IDE legacy driver
lacks these smarts so in some cases will do the wrong thing even if
loaded last.

Alan

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Tejun Heo]

Alan Cox wrote:
>> Always loading generic or ata_generic used to be safe.  It's still 
>> pretty safe but not as much as before.  Nowadays, there are good number 
> 
> ata_generic is always safe unless you force it to grab every class
> device. By default it grabs only those devices we know obey the class
> interface well enough and for which we have no proper driver (usually
> because there are no documents). Ditto for ide/pci/generic.
> 
> The trickier one is pata_legacy, which tries to be smart and knows about
> the known exception so *should* always be safe. The old IDE legacy driver
> lacks these smarts so in some cases will do the wrong thing even if
> loaded last.

Right, I was thinking about drivers/ide/ide-generic.c which just grabs 
every known legacy IO ports.  This actually caused rather serious 
problems on some ATI controllers under certain configurations.  :-(

-- 
tejun

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Lennart Sorensen]

On Tue, Apr 15, 2008 at 11:37:26AM +0900, Tejun Heo wrote:
> Alan Cox wrote:
> >>If a driver supports a device with dual interfaces, then it better
> >>reserve both sets of ports to prevent the generic driver from trying to
> >>use them.
> >
> >That isn't the problem. The generic driver doesn't know if there is
> >another valid driver for the ports - how can it - and the other driver
> >may not be loaded first so cannot reserve the ports. If you load the
> >generic driver last then you should be fine, and the link order for IDE
> >and libata puts acpi, pci generic and legacy at the end for good reason.
> >
> >Libata pata_legacy has some smarts in this area but they are only good
> >for the common cases.
> 
> Always loading generic or ata_generic used to be safe.  It's still 
> pretty safe but not as much as before.  Nowadays, there are good number 
> of controllers which have dual interfaces.  Usually an ahci interface 
> and a legacy one but there are other controllers which also implement 
> dual interface.
> 
> Because PCI BARs usually contain IO regions for legacy interface in PCI 
> BAR 0-4, the native driver can work it out by claiming all PCI BARs on 
> attach, which I learned the hard way after seeing the generic driver 
> borking the native one on certain configurations.  The thing I'm worried 
> about is that there are a lot of vendors making this type of controllers 
> nowadays and a lot of BIOS implementations for each of them.  And of 
> course each BIOS implementation has its own many ways of configuring the 
> dual mode (or more thanks to fake RAIDs) controller.
> 
> I wouldn't be too surprised if one of those plethora of configurations 
> gets the compatible IO port and BAR configurations mismatched. 
> Especially when the controller is put into native mode.  It's entirely 
> possible to leave the compatible IO ports enabled while not setting the 
> PCI BARs accordingly.  Some of them might even think that's better to 
> prevent IDE drivers from attaching to it.
> 
> So, I don't really want to depend on that.  I don't know.  Do I sound 
> paranoid?

Yes.  After all you would quickly see a problem if you built a kernel
with all the IDE drivers built in, which some people do.  In that case
ide generic is always activated last and anything bad that would happen
with loading a module would happen built in too.

I think it is the wrong place to worry about problems.  If a native
driver takes control of a chip, it is that drivers responsibility to
reserve any relevant ports on that chip sufficiently to prevent another
driver from messing with it that doesn't know anything about that chip.
If the native driver doesn't load at all, then ide-generic ought to try
and drive the chip if it has legacy ports.

So my opinion is that making life easy to those machines with legacy ide
ports is a good thing, while trying to be overly paranoid about one
driver potentially hitting a bug in another driver is just silly.  Why
couldn't two native ide drivers potentially go looking for the same
ports too?  Are you sure no native driver uses the legacy IDE port
numbers to control a chip in native mode?  Finding bugs is good since
then they can be fixed.  Trying to prevent hitting bugs (which shouldn't
be there in the first place) doesn't seem useful.

-- 
Len Sorensen

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Tejun Heo]

Hi,

Lennart Sorensen wrote:
> Yes.  After all you would quickly see a problem if you built a kernel
> with all the IDE drivers built in, which some people do.  In that case
> ide generic is always activated last and anything bad that would happen
> with loading a module would happen built in too.

Yeah, pick the right configuration.  You can make it malfunction.

> I think it is the wrong place to worry about problems.  If a native
> driver takes control of a chip, it is that drivers responsibility to
> reserve any relevant ports on that chip sufficiently to prevent another
> driver from messing with it that doesn't know anything about that chip.
> If the native driver doesn't load at all, then ide-generic ought to try
> and drive the chip if it has legacy ports.

I'm not too sure whether that will be always possible and I'm less sure 
we'll get enough test coverage over this kind of stuff.

> So my opinion is that making life easy to those machines with legacy ide
> ports is a good thing, while trying to be overly paranoid about one
> driver potentially hitting a bug in another driver is just silly.  Why
> couldn't two native ide drivers potentially go looking for the same
> ports too?  Are you sure no native driver uses the legacy IDE port
> numbers to control a chip in native mode?  Finding bugs is good since
> then they can be fixed.  Trying to prevent hitting bugs (which shouldn't
> be there in the first place) doesn't seem useful.

Yeah, theoretically, you're right.  The problem is that what breaks when 
things go wrong.  If you don't probe generic ports by default, harddisks 
won't be detected on some legacy systems but you can always prompt the 
user about loading the generic driver.  If you probe generic ports by 
default, when things go wrong, you break modern machines in an 
unrecoverable (w/o reset) way.  I'd rather choose bothering the user on 
legacy machines.

thanks.

-- 
tejun

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Frans Pop]

On Wednesday 16 April 2008, Tejun Heo wrote:
> Yeah, theoretically, you're right.  The problem is that what breaks when
> things go wrong.  If you don't probe generic ports by default, harddisks
> won't be detected on some legacy systems but you can always prompt the
> user about loading the generic driver.  If you probe generic ports by
> default, when things go wrong, you break modern machines in an
> unrecoverable (w/o reset) way.  I'd rather choose bothering the user on
> legacy machines.

The problem here is determining whether a machine is "legacy" or not.
So far in this discussion I've seen no suggestions how to do that (except 
maybe for my test whether /sys/bus/isa is present), which would mean asking 
_all_ users, and that's a damned ugly option.

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Tejun Heo]

Frans Pop wrote:
> On Wednesday 16 April 2008, Tejun Heo wrote:
>> Yeah, theoretically, you're right.  The problem is that what breaks when
>> things go wrong.  If you don't probe generic ports by default, harddisks
>> won't be detected on some legacy systems but you can always prompt the
>> user about loading the generic driver.  If you probe generic ports by
>> default, when things go wrong, you break modern machines in an
>> unrecoverable (w/o reset) way.  I'd rather choose bothering the user on
>> legacy machines.
> 
> The problem here is determining whether a machine is "legacy" or not.
> So far in this discussion I've seen no suggestions how to do that (except 
> maybe for my test whether /sys/bus/isa is present), which would mean asking 
> _all_ users, and that's a damned ugly option.

Asking when no harddisk is detected w/ the option to choose it 
explicitly should do for most cases.  No?

-- 
tejun

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Lennart Sorensen]

On Thu, Apr 17, 2008 at 07:12:35AM +0900, Tejun Heo wrote:
> Asking when no harddisk is detected w/ the option to choose it 
> explicitly should do for most cases.  No?

I suppose it might, although I could still see an older machine have a
PCI controller as well as an ISA legacy controller on an ISA sound card,
and might even have a CDROM drive connected to the sound card.  Not very
likely though, but not imposible.  In that case you might detect the HD
connected to the HD, but not the CDROM connected to the sound card.
That might be confusing to the user.  On the other hand anyone running
such old hardware might just have a pretty good idea what they are doing
and could run in expert mode and tell the installer to also load the
generic driver.

I still think the correct solution is to always try loading it, posibly
with a boot option to make the installer not do so for any machines that
have issues with that.  Any such machines should then have bug reports
filed so that the driver that runs their chipset's IDE controller in a
native mode can ensure they reserve the legacy IDE ports so that nothing
else (like the generic driver) can go poking at them.

After all I thought the whole point of all the ports listed in
/proc/ioports was to indicate which io ports were currently reserved by
which driver so that no other driver could try to access them.  If it
doesn't in fact work that way then it probably should.

-- 
Len Sorensen

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Tejun Heo]

Lennart Sorensen wrote:
> After all I thought the whole point of all the ports listed in
> /proc/ioports was to indicate which io ports were currently reserved by
> which driver so that no other driver could try to access them.  If it
> doesn't in fact work that way then it probably should.

It does work most of the time and it's probably safe to load legacy / 
generic drivers on most configurations.  It's just that we're talking 
about 15+ years of gap between ISA and PCI-e and there could be some 
exceptions and we might need to tread a bit more carefully.  To me, it 
sounds reasonable.

Thanks.

-- 
tejun

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Alan Cox]

> The problem here is determining whether a machine is "legacy" or not.
> So far in this discussion I've seen no suggestions how to do that (except 
> maybe for my test whether /sys/bus/isa is present), which would mean asking 
> _all_ users, and that's a damned ugly option.

Libata pata_legacy handles this itself for all known cases using the
ruleset

IF any PCI device -> no PATA legacy scans beyond IDE0/IDE1
IF any PCI IDE in legacy compat mode  -> No pata_legacy bind to that port
IF CS55x0 or MPIIX -> read the chipset magic [these are the obscure 'not
PCI but not ISA' specials]

Alan

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Ondrej Zary]

On Wednesday 02 April 2008 15:24:26 Frans Pop wrote:
> Hi,
>
> We've received an installation report for Debian for an older system where
> no IDE driver gets loaded. The system does not have any IDE device listed
> in lspci. When ide-generic is modprobed manually, both the CD and hard disk
> work fine.
>
> Any suggestions on how such a system could be recognized?
> If we could do that, the installation system could take responsibility for
> loading ide-generic and making sure it is included in the initrd.
>
> Or even better, any chance to make the kernel/udev load ide-generic
> automatically for this system?
>
> See http://bugs.debian.org/472487 for details. I can get additional info
> from the owner of the system if needed.
>
> Cheers,
> FJP
>
> Output of lspci -nn:
> 00:00.0 Host bridge [0600]: Toshiba America Info Systems CPU to PCI bridge
> [1179:0601] (rev a0)
> 00:04.0 VGA compatible controller [0300]: Chips and Technologies F65555
> HiQVPro [102c:00e5] (rev c6)
> 00:0b.0 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 02)
> 00:11.0 Communication controller [0780]: Toshiba America Info Systems FIR
> Port [1179:0701] (rev 21)
> 00:13.0 CardBus bridge [0607]: Toshiba America Info Systems ToPIC97
> [1179:060f] (rev 20)
> 00:13.1 CardBus bridge [0607]: Toshiba America Info Systems ToPIC97
> [1179:060f] (rev 20)

Looks like the controller is not a separate PCI device. Toshiba provides Bus 
Mastering driver for Windows 95:
http://209.167.114.38/support/download/files_Archive/Index/windows_95_files.htm

So the controller probably can do DMA but it's not a standard IDE controller. 
And looks like there's no driver in the kernel for it.

-- 
Ondrej Zary

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Lennart Sorensen]

On Wed, Apr 02, 2008 at 06:33:46PM +0200, Ondrej Zary wrote:
> On Wednesday 02 April 2008 15:24:26 Frans Pop wrote:
> > Output of lspci -nn:
> > 00:00.0 Host bridge [0600]: Toshiba America Info Systems CPU to PCI bridge
> > [1179:0601] (rev a0)
> > 00:04.0 VGA compatible controller [0300]: Chips and Technologies F65555
> > HiQVPro [102c:00e5] (rev c6)
> > 00:0b.0 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 02)
> > 00:11.0 Communication controller [0780]: Toshiba America Info Systems FIR
> > Port [1179:0701] (rev 21)
> > 00:13.0 CardBus bridge [0607]: Toshiba America Info Systems ToPIC97
> > [1179:060f] (rev 20)
> > 00:13.1 CardBus bridge [0607]: Toshiba America Info Systems ToPIC97
> > [1179:060f] (rev 20)
> 
> Looks like the controller is not a separate PCI device. Toshiba provides Bus 
> Mastering driver for Windows 95:
> http://209.167.114.38/support/download/files_Archive/Index/windows_95_files.htm
> 
> So the controller probably can do DMA but it's not a standard IDE controller. 
> And looks like there's no driver in the kernel for it.

I don't think that bus master package is for that machine.  The
datasheet for it mentioned PIO4 max.  I think the BUSIDE.EXE is for
machines with the early PIIX controller (which that particular machine
clearly doesn't have since it has no PCI IDE controller).

-- 
Len Sorensen

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Ondrej Zary]

On Wednesday 02 April 2008 22:05:49 Lennart Sorensen wrote:
> On Wed, Apr 02, 2008 at 06:33:46PM +0200, Ondrej Zary wrote:
> > On Wednesday 02 April 2008 15:24:26 Frans Pop wrote:
> > > Output of lspci -nn:
> > > 00:00.0 Host bridge [0600]: Toshiba America Info Systems CPU to PCI
> > > bridge [1179:0601] (rev a0)
> > > 00:04.0 VGA compatible controller [0300]: Chips and Technologies F65555
> > > HiQVPro [102c:00e5] (rev c6)
> > > 00:0b.0 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 02)
> > > 00:11.0 Communication controller [0780]: Toshiba America Info Systems
> > > FIR Port [1179:0701] (rev 21)
> > > 00:13.0 CardBus bridge [0607]: Toshiba America Info Systems ToPIC97
> > > [1179:060f] (rev 20)
> > > 00:13.1 CardBus bridge [0607]: Toshiba America Info Systems ToPIC97
> > > [1179:060f] (rev 20)
> >
> > Looks like the controller is not a separate PCI device. Toshiba provides
> > Bus Mastering driver for Windows 95:
> > http://209.167.114.38/support/download/files_Archive/Index/windows_95_fil
> >es.htm
> >
> > So the controller probably can do DMA but it's not a standard IDE
> > controller. And looks like there's no driver in the kernel for it.
>
> I don't think that bus master package is for that machine.  The
> datasheet for it mentioned PIO4 max.  I think the BUSIDE.EXE is for
> machines with the early PIIX controller (which that particular machine
> clearly doesn't have since it has no PCI IDE controller).

I mean S320BIDE.EXE - that's for this machine only.

-- 
Ondrej Zary

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Lennart Sorensen]

On Wed, Apr 02, 2008 at 10:10:23PM +0200, Ondrej Zary wrote:
> I mean S320BIDE.EXE - that's for this machine only.

Hmm, I missed that one.  I wonder how they do it.  Well ISA did support
bus mastering DMA although it seems rare to implement it.  Or it could
be VLB style.

-- 
Len Sorensen

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Ondrej Zary]

On Wednesday 02 April 2008 22:22:25 Lennart Sorensen wrote:
> On Wed, Apr 02, 2008 at 10:10:23PM +0200, Ondrej Zary wrote:
> > I mean S320BIDE.EXE - that's for this machine only.
>
> Hmm, I missed that one.  I wonder how they do it.  Well ISA did support
> bus mastering DMA although it seems rare to implement it.  Or it could
> be VLB style.

I suspect that the IDE controller is integrated into the Toshiba chipset but 
does not appear as a separate PCI device. It could be controlled by some 
registers of the "host-bridge" or some other device.

-- 
Ondrej Zary

Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

[Alan Cox]

On Wed, 2 Apr 2008 22:34:58 +0200
Ondrej Zary <linux@rainbow-software.org> wrote:

> On Wednesday 02 April 2008 22:22:25 Lennart Sorensen wrote:
> > On Wed, Apr 02, 2008 at 10:10:23PM +0200, Ondrej Zary wrote:
> > > I mean S320BIDE.EXE - that's for this machine only.
> >
> > Hmm, I missed that one.  I wonder how they do it.  Well ISA did support
> > bus mastering DMA although it seems rare to implement it.  Or it could
> > be VLB style.
> 
> I suspect that the IDE controller is integrated into the Toshiba chipset but 
> does not appear as a separate PCI device. It could be controlled by some 
> registers of the "host-bridge" or some other device.

Toshiba Piccolo series. PCI chipset integrated IDE, not supported as
Toshiba refused to even answer emails about it. If you want it to work
you need to find out what registers their driver writes to

Alan