Re: Continuing saga: FreeBSD -CURRENT hangs with ATA code after April

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