5.2.1 p9 --> 5.2 current 20040708 upgrade ATA_IDENTIFY no interrupt
jhandvil
during boot (copied by hand, please excuse typo's):
ata0-master: FAILURE - ATA_IDENTIFY no interrupt
ata0-master: FAILURE - ATA_IDENTIFY no interrupt
Mounting root from ufs:/dev/ad0s1a
setrootbyname failed
ffs_mountroot: can't find rootvp
Root mount failed: 6
System info -
AMD Athlon 1.33 266MHZ DDR (133MHZ FSB). 1024MB ram DDR PC2100
IDE HD as Master 0, Sony DVD+/- RW as Master 1 (disabled -- see below)
NVIDIA GeForce 3 AGP
Sound Blaster LIVE
(from 5.2.1 p9 kernel dmesg)
atapci0: <VIA 8233 UDMA100 controller> port 0xff00-0xff0f at device 17.1 on
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
ad0: 152627MB <ST3160023A> [310101/16/63] at ata0-master UDMA100
Cursory google search and scan of UPDATING found only two encounters with this
problem, both of which used a DVD RW drive. Thinking this might be the
culprit, I disabled (read unplugged) my Sony DVD+/-RW drive and rebooted to
no avail. I attempted to boot w/ disabled ACPI, but I get the same message.
For now I have failed over to the 5.2.1 kernel which appears to work in some
broken manner with the -current world (enough to run X). Any suggestions for
bootstrapping the -current kernel?
Thanks,
Justin
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
jhandvil
> jhandvil wrote:
> > Just upgraded from 5.2.1 p9 to 5.2-current. Received the following error
> > during boot (copied by hand, please excuse typo's):
> >
> > ata0-master: FAILURE - ATA_IDENTIFY no interrupt
> > ata0-master: FAILURE - ATA_IDENTIFY no interrupt
> > Mounting root from ufs:/dev/ad0s1a
> > setrootbyname failed
> > ffs_mountroot: can't find rootvp
> > Root mount failed: 6
>
> WITNESS in the kernel config and report to the list if there are any
> changes?
Thanks for the fast response. I toggled turned off WITNESS (and turned on
DDB), and I got the same response.
I tried digging some more. I know that there was an issue earlier with the
via 8237 and dma, so I tried disabling dma (hw.ata.ata_dma=0). This had no
effect. I'll attempt to dig around in the PCI driver and the ata driver a
little more and see if I can add some traces around the interrupt assignment.
Any additional suggestions would be much appreciated.
Great Cthulu sig. I'm a bit of a H.P. Lovecraft fan myself.
jhandvil
> On Sunday 11 July 2004 07:34 am, Ivan Voras wrote:
> > jhandvil wrote:
> > > Just upgraded from 5.2.1 p9 to 5.2-current. Received the following
> > > error during boot (copied by hand, please excuse typo's):
> > >
> > > ata0-master: FAILURE - ATA_IDENTIFY no interrupt
> > > ata0-master: FAILURE - ATA_IDENTIFY no interrupt
> > > Mounting root from ufs:/dev/ad0s1a
> > > setrootbyname failed
> > > ffs_mountroot: can't find rootvp
> > > Root mount failed: 6
> >
> > I have a very similar situation at my machine. Could you try toggling
> > WITNESS in the kernel config and report to the list if there are any
> > changes?
>
> Thanks for the fast response. I toggled turned off WITNESS (and turned on
> DDB), and I got the same response.
>
> I tried digging some more. I know that there was an issue earlier with the
> via 8237 and dma, so I tried disabling dma (hw.ata.ata_dma=0). This had no
> effect. I'll attempt to dig around in the PCI driver and the ata driver a
> little more and see if I can add some traces around the interrupt
> assignment. Any additional suggestions would be much appreciated.
Additional information: I added a printf at line 236 of ata-queue.c (in
function ata_completed). The output shows the values in the ata_request
structure:
...
command=0xec (ATA_ATA_IDENTIFY)
flags=0x282 (ATA_R_IMMEDIATE | ATA_R_READ | ATA_R_TIMEOUT)
retries=-1
...
This command is called from ata_identify_devices. I will trace out further to
see what is being passed in the ata_channel struct. Please let me know any
additional traces that will help to find the root cause.
Bruce M Simpson
> > > ata0-master: FAILURE - ATA_IDENTIFY no interrupt
> > > ata0-master: FAILURE - ATA_IDENTIFY no interrupt
> > > Mounting root from ufs:/dev/ad0s1a
> > > setrootbyname failed
> > > ffs_mountroot: can't find rootvp
> > > Root mount failed: 6
This is a very, very similar situation to what I've just observed on
several IBM ThinkPad T41 systems with the Panasonic UJDA755 CDRW module!
Please post as much information about your hardware configuration as you
can; please also see my recent posts to -mobile for descriptions of how
to pull a backtrace in the situation where your machine faults and drops
into the debugger without the ability to 'call doadump'.
I now strongly suspect we have a bug in ata(4). I will backtrack through
green@'s recent commits concerning atapicam as I think this may tell
part of the story (he identified some other issues and suggested fixes,
I have a hunch he is on a similar track).
I'm in a debugging session now and will post further results of my findings
on -mobile.
Regards,
BMS
jhandvil
Excellent! I added a panic immediately after the error in ata_completed so
that I can perform the backtrace. I will post the response to the group as
soon as I rebuild the kernel and reboot.
jhandvil
> On Sunday 11 July 2004 02:29 pm, Bruce M Simpson wrote:
> > On Sun, Jul 11, 2004 at 10:43:21AM -0400, jhandvil wrote:
> > > > > ata0-master: FAILURE - ATA_IDENTIFY no interrupt
> > > > > ata0-master: FAILURE - ATA_IDENTIFY no interrupt
> > > > > Mounting root from ufs:/dev/ad0s1a
> > > > > setrootbyname failed
> > > > > ffs_mountroot: can't find rootvp
> > > > > Root mount failed: 6
> >
> > This is a very, very similar situation to what I've just observed on
> > several IBM ThinkPad T41 systems with the Panasonic UJDA755 CDRW module!
> >
> > Please post as much information about your hardware configuration as you
> > can; please also see my recent posts to -mobile for descriptions of how
> > to pull a backtrace in the situation where your machine faults and drops
> > into the debugger without the ability to 'call doadump'.
> >
> > I now strongly suspect we have a bug in ata(4). I will backtrack through
> > green@'s recent commits concerning atapicam as I think this may tell
> > part of the story (he identified some other issues and suggested fixes,
> > I have a hunch he is on a similar track).
> >
> > I'm in a debugging session now and will post further results of my
> > findings on -mobile.
>
> Excellent! I added a panic immediately after the error in ata_completed so
> that I can perform the backtrace. I will post the response to the group as
> soon as I rebuild the kernel and reboot.
After a few painstaking attempts (forgot to add options KDB which caused a
panic when entering DDB) I have a handwritten trace from DDB. I hope that it
is more useful than it looks to me, because I don't see anything new that I
don't already know. I added a printf before the (retry < 0) check, and I
hard-coded the kdb_enter immediately before the end of the check (after the
"FAILURE: ATA_IDENTIFY no interrupt" trace). The trace is shorthand, I
wasn't about to copy it verbatim:
100049 (0xc24086e0) fork_trampoline() at fork_trampoline
100048 (0xc2408580) sched_switch(...,0) at +0x123
100047 (0xc2408580) sched_switch(...,0) at +0x123
100015 (0xc2281580) sched_switch(...,0) at +0x123
100014 (0xc2281420) sched_switch(...,0) at +0x123
100013 (0xc22812c0) kdb_enter(c07d5245,c2375c00,2) at +0x2b (*** hard coded
entry in ata-queue.c: ata_completed)
100012 (0xc2281160) fork_trampoline at fork_trampoline
100038 (0xc22c96e0) fork_trampoline at fork_trampoline
100037 (0xc22c9580) fork_trampoline at fork_trampoline
100036 (0xc22c9420) fork_trampoline at fork_trampoline
100035 (0xc22c92c0) fork_trampoline at fork_trampoline
100034 (0xc22c9160) sched_switch(...,0) at +0x123
100033 (0xc22c9000) sched_switch(...,0) at +0x123
100032 (0xc2287dc0) sched_switch(...,0) at +0x123
100031 (0xc2287c60) sched_switch(...,0) at +0x123
100001 (0xc227c160) fork_trampoline at fork_trampoline
100000 (0xc227c160) fork_trampoline at fork_trampoline
100024 (0xc22872c0) sched_switch(...,0) at +0x123
100023 (0xc22872c0) fork_trampoline at fork_trampoline
100022 (0xc2287000) fork_trampoline at fork_trampoline
100021 (0xc2281dc0) fork_trampoline at fork_trampoline
100020 (0xc2281c60) fork_trampoline at fork_trampoline
100019 (0xc2281k00) fork_trampoline at fork_trampoline
100018 (0xc22819a0) sched_switch(...,0) at +0x123
100017 (0xc2281840) fork_trampoline at fork_trampoline
100016 (0xc22816e0) fork_trampoline at fork_trampoline
100011 (0xc2281000) sched_switch(...,0) at +0x123
100010 (0xc227cdc0) sched_switch(...,0) at +0x123
100009 (0xc227cc60) fork_trampoline at fork_trampoline
100008 (0xc227cb00) fork_trampoline at fork_trampoline
100007 (0xc227c9a0) fork_trampoline at fork_trampoline
100006 (0xc227c840) sched_switch(...,0) at +0x123
100005 (0xc227c6e0) fork_trampoline at fork_trampoline
100004 (0xc227c580) sched_switch(...,0) at +0x123
100003 (0xc227c420) fork_trampoline at fork_trampoline
100002 (0xc227c2c0) sched_switch(...,0) at +0x123
0 (0xc08dabc0) sched_switch(...,0) at +0x123
> trace
kdb_enter (c07d5245, c2375c00,2) at +0x2b
ata_completed(0xc2613000,1,c2321698,0,c0806396) at +0xb0
taskqueue_run(0xc2321680,db0bdd34,c060c47c,0,db0bdd48) at +0x83
taskqueue_thread_loop(0,db0bdd48,0,c063b640,0) at +0x2b
fork_exit(0xc063b640,0,db0bdd48) at +0x98
fork_trampoline() at fork_trampoline + 0x8
--- trap 0x1, eip = 0, esp = 0xdb0bdd7c, ebp = 0 ---
Please let me know what else is needed.