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)
--

[ message continues ]

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

[ message continues ]

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
--

[ message continues ]

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:

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
--

[ message continues ]

Well if Win95 was preinstalled, and being a 233MMX, then probably around

Yeah ISA seems likely.

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

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

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
--

[ message continues ]

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 

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

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
--

[ message continues ]

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

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


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

-- 
Len Sorensen
--

[ message continues ]

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
--

[ message continues ]

I am just wondering if arm, m68k, etc might have IDE ports that work

Hmm, I must admit my newest x86 does in fact not have a /sys/bus/isa.  I

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
--

[ message continues ]

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

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'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.)
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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

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
--

[ message continues ]

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


All PC class systems have an ISA bus, it may be on the main board and

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

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


Alan
--

[ message continues ]

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.
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

Hi,



I'm not too sure whether that will be always possible and I'm less sure 

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
--

[ message continues ]

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.
--

[ message continues ]

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

-- 
tejun
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

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

-- 
Ondrej Zary
--

[ message continues ]

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
--

[ message continues ]

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
--

[ message continues ]

On Wed, 2 Apr 2008 22:34:58 +0200

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
--

[ message continues ]