Date: Sat, 22 Mar 1997 07:44:40 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!freefall.cdrom.com!freebsd-hackers, ponds!lakes.water.net!rivers Subject: More "dup alloc" info. Message-ID: <199703221244.HAA09437@lakes.water.net>
next in thread | raw e-mail | index | archive | help
Just F.Y.I. - I'm still stumbling around with this dup alloc problem. I'm using 2.1.7.1 sources now... Anyway, I've discovered that if I had a printf() to aha_done [my reproduction is with an aha1542b; and an IDE machine - but I'm working on the 1542b] to print the current processor level (cpl) that problem is masked. That is, I don't reproduce the bug. This would tend to indicate that some timing is involved; and that, somewhere the cpl must be at least splbio(). However, using: if(cpl & bio_imask != bio_imask) checks in some suspect places (i.e. scsi_done(), biodone()) I haven't been able to verify this. (That is, none of them were tripped.) Again - it seems that a SCSI command is being constructed which contains a data buffer just chock full of the requisite 0x00s, but that data certainly isn't making it to the disk... scsi_done() is convinced the operation completed successfully. (I.e. sdstart() queued it, and an interrupt came back for it.. scsi_done() dump'd the xs buffer to print all 0x00s.) BUT - those 0x00s aren't making it to the disk... argh... Help, I'm running out of ideas ... - Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703221244.HAA09437>