I'm using a ten year old 486 as a firewall, with an aged transparent
2.5Mb Promise caching IDE controller managing a couple of fairly
bog-standard IDE disks (one a 420Mb 1989-vintage Western Digital of some
kind, the other a 1994-vintage 1Gb IBM disk). I can't find out the model
numbers without taking the machine to pieces, because even with 2.2.20
the (new) ide driver says
Jun 30 00:33:50 esperi kernel: hda: non-IDE drive, CHS=2047/16/63
Jun 30 00:33:50 esperi kernel: hdb: non-IDE drive, CHS=895/15/62
Jun 30 00:33:50 esperi kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
but then it finds the partitions OK:
Jun 30 00:33:50 esperi kernel: Partition check:
Jun 30 00:33:50 esperi kernel: hda: hda1 hda2 hda3 < hda5 hda6 hda7 > hda4
Jun 30 00:33:50 esperi kernel: hdb: hdb1 < hdb5 hdb6 hdb7 >
2.4 doesn't get anywhere near this far. It finds the IDE controller but
fails to find any of the attached drives, and panics because it can't
mount /.
When I try to force it with kernel parameters, viz `hda=2047,16,63
hdb=895,15,62', it says
hda6: bad access: block=2, count=2
end_request: I/O error, dev 03:06 (hda), sector 2
and then panics because it can't mount root.
I must admit to not knowing where to start debugging this one.
The old disk-only driver works OK with this machine, but it doesn't
support IRQ-based transfer that I can see, with the result that my
16450 UART is dropping incoming packets like confetti :((((
(log from the old driver starting up in 2.4:
Jun 30 13:00:44 esperi kernel: hda: 1007MB, CHS=2047/16/63
Jun 30 13:00:44 esperi kernel: hdb: 406MB, CHS=895/15/62
Jun 30 13:00:44 esperi kernel: Partition check:
Jun 30 13:00:44 esperi kernel: hda: hda1 hda2 hda3 < hda5 hda6 hda7 > hda4
Jun 30 13:00:44 esperi kernel: hdb: hdb1 < hdb5 hdb6 hdb7 >
pretty uninformative, really.)
Anyone got any idea how I could start to debug this? I could really do
with a driver that supports IRQ on this machine...
--
`What happened?'
`Nick shipped buggy code!'
`Oh, no dinner for him...'
On 30 June 2002 17:22, Nix wrote:
> I'm using a ten year old 486 as a firewall, with an aged transparent
> 2.5Mb Promise caching IDE controller managing a couple of fairly
> bog-standard IDE disks (one a 420Mb 1989-vintage Western Digital of some
> kind, the other a 1994-vintage 1Gb IBM disk). I can't find out the model
> numbers without taking the machine to pieces, because even with 2.2.20
> the (new) ide driver says
If 2.4 kernel does not work:
Andre Hedrick <[email protected]> [09 apr 2002]
ATA/ATAPI Storage Architect [2.0,2.2,2.4]
HBA interface developer
Serial ATA Architect [future release]
Voting NCITS member AT-Attachment Committee
If 2.5 kernel does not work:
Martin Dalecki <[email protected]> [11 mar 2002]
IDE subsystem maintainer for 2.5
(mail Vojtech Pavlik <[email protected]> too)
Include lspci data and .config
--
vda
On Mon, 1 Jul 2002, Denis Vlasenko said:
> On 30 June 2002 17:22, Nix wrote:
>> I'm using a ten year old 486 as a firewall, with an aged transparent
>> 2.5Mb Promise caching IDE controller managing a couple of fairly
>> bog-standard IDE disks (one a 420Mb 1989-vintage Western Digital of some
>> kind, the other a 1994-vintage 1Gb IBM disk). I can't find out the model
>> numbers without taking the machine to pieces, because even with 2.2.20
>> the (new) ide driver says
[snip --- probe fails to pick up any drives in 2.4, 2.2 says `non-IDE disk'
but then works OK: if detection is forced with kernel parameters, 2.4 says
`hda6: bad access: block=2, count=2'... old hd.c driver works, but...]
> If 2.4 kernel does not work:
> Andre Hedrick <[email protected]> [09 apr 2002]
[so copied: Andre, the earlier post is at
<http://www.uwsg.iu.edu/hypermail/linux/kernel/0206.3/0679.html>.]
> Include lspci data and .config
lspci? On a 486 that's considerably older than the PCI spec itself? It's
ISA here, as far as the eye can see... as for ATA/ATAPI, forget it :)
One of the problems I'm having is that without PCI info, with a box
that's old enough that I can't easily tell what the hard drive models
actually *are*, it's hard to know where to start debugging :) I may have
to pull it apart and see if the drives have identifying labels on them.
I think that one of the problem spots may be that do_probe() spends most
of its time trying to fire ATA commands at the drive: I don't expect the
drives in *this* machine to make head or tail of that.
Anyway, I'm going to start a cautious forward merge of the 2.2 ide-probe
code into 2.4, and see when the behaviour changes. (Cautious and *slow*,
because this box is a firewall that has to be running most of the
time, so I'll have to sneak debugging in at odd hours. :( )
--
`What happened?'
`Nick shipped buggy code!'
`Oh, no dinner for him...'
On Mon, 1 Jul 2002, Andre Hedrick spake:
> Lemme guess PDC5030 or 4030
I've just tried with that driver and append="ide0=dc4030". No joy:
identical output to the `normal' ide.c case (i.e. controller found, but
no drives found), and no mention of `Promise caching controller'
anywhere in the output. I guess my ancient Promise isn't one of those
after all. (Again, not *all* that surprising: this disk controller is
older than Linux...)
:(
I'll scatter a bunch of printk's through the code in 2.2 and 2.4
ide-probe.c and see what happens in 2.2 versus 2.4 probing; it'll be
tomorrow before that's doable though because I can only reboot the
machine in the early morning when nobody else is around.
(The code in ide-probe.c is very divergent anyway, but this might give
me, or someone else, *some* clue.)
--
`What happened?'
`Nick shipped buggy code!'
`Oh, no dinner for him...'