Continuing saga: FreeBSD -CURRENT hangs with ATA code after
April
Joe Marcus Clarke
marcus at FreeBSD.org
Mon Mar 2 14:39:42 PST 2009
On Mon, 2009-03-02 at 23:20 +0200, Alexander Motin wrote:
> Joe Marcus Clarke wrote:
> > I started this thread on May 31 of last year:
> >
> > http://lists.freebsd.org/pipermail/freebsd-current/2008-May/085923.html
> >
> > The problem remains as of:
> >
> > FreeBSD fugu.marcuscom.com 8.0-CURRENT FreeBSD 8.0-CURRENT #12: Sun Mar
> > 1 16:10:52 EST 2009
> > gnome at fugu.marcuscom.com:/space/obj/usr/src/sys/FUGU i386
> >
> > The only way I can boot this system is to hack in the ATA code from
> > April 9, 2008. I would love just to be able to boot this guy on a
> > default -CURRENT.
>
> 1) If I understand right, you had working system on April 9, 2008 and
> not working on May 31, 2008 and now. Have you tried to narrow down that
> interval between working and not working system to find exact point of
> breakage? I see no documented changes in Promise support there in CVS
> log, but for example, on Apr 10 2008 I see some related changes
> unmentioned in commit message.
>
> 2) To properly associate problem with present sources I would like to
> see full problem verbose messages for the current HEAD.
I cannot save off the dmesg, but here is the last ATA lines (with
debugging printf):
acd0: <HL-DT-ST DVD+RW GRA-4120B/F114> CDRW drive at ata1 as master
acd0: read 6890KB/s (6890KB/s) write 6890KB/s (6890KB/s), 2048KB buffer,
UDMA33
acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet
acd0: Writes: CDR, CDRW, test write, burnproof
acd0: Audio: play, 256 volume levels
acd0: Mechanism: ejectable tray, unlocked
acd0: Medium: no/blank disc
ata2: Identifying devices: 00000000
ata2: New devices: 00000000
ata3: Identifying devices: 00000001
ata3: New devices: 00000001
Enter ata_promise_mio_command
After ATA_OUTL(ctlr->r_res2, (ch->unit + 1) << 2, 0x00000001);
After ATA_OUTB(ctlr->r_res2, 0x4e8 + (ch->unit << 8), atadev->unit &
0x0f);
Command is 236
Running generic command
After that, I expect to see:
"After running generic command: %d"
Where %d is the result of the command. So ata_promise_mio_command() is
not returning. The 236 is the value of request->u.ata.command as passed
to ata_promise_mio_command().
Is this helpful, or should I markup ata_generic_command() as well?
As for the full dmesg, I'll try and hook the serial console back up to
see if I can capture it.
Joe
>
> 3) As my mom told me 15 years ago, if you don't understand what's going
> on, insert debugging printfs. If system hangs and we have no other
> sources of information, I would start from putting
> printf("%s\n", __func__);
> wherever it is possible to get readable path. I would start from every
> ata_promise_mio_* function beginning of HEAD code.
>
--
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome at FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090302/23480da1/attachment.pgp
More information about the freebsd-current
mailing list