[5.3BETA7] ad0 gone after suspend/resume cycle

I've been seeing this little feature ever since ATAng was introduced and
also reported it back then, but didn't get any real response. Properly my 
own fault for not being precise enough. :-) But I better try again
before 5.3 goes stable. 
The subject at hand is an 'old' Toshiba Satellite Pro 6000(dmesg
attached) and FreeBSD5.3BETA7 GENERIC kernel+debugging. When I suspend with
'acpiconf -s 3' and afterwards resumes, ad0 is removed with the message:
"ad0: WARNING - removed from configuration."
Trying to track down why this happens, I've come so far that 
ata-all.c:ata_identify_devices(ata_channel*) doesn't find anything
after the resume. So, ata-all.c:ata_reinit(ata_channel*) starts by
detaching the devices that were lost during reset(this means ad0), then detaches the
devices that were lost during identify(none) and finally attaching the devices
that were found by ata_identify_devices(I'm guessing here?). In this case 
none.
The above is properly a wrong interpretation of the code, but I'm new at
this, so be nice. :o) The question then is: why is my drive lost?
I can't be helpful with a dump, because 1) the laptop doesn't panic()
and 2) it's kind of hard to doadump without a configured drive. :o)
This might not even be something wrong with ATA, but I don't know
whereelse to look.

This is output when resuming with verbose boot:
ata0: reiniting channel ..
ata0: reset tp1 mask=03 ostat0=80 ostat1=80
ad0: stat=0x80 err=0x80 lsb=0x80 msb=0x80
ad0: stat=0x80 err=0x80 lsb=0x80 msb=0x80
ad0: stat=0xd0 err=0xd0 lsb=0xd0 msb=0xd0
ad0: stat=0x50 err=0x00 lsb=0xfe msb=0x3f
ata0-slave:  stat=0x00 err=0x00 lsb=0xfe msb=0x3f
ata0: reset tp2 stat0=50 stat1=00 devices=0x0
ata0: resetting done ..
ad0: WARNING - removed from configuration
ata0: device config done ..

and the backtrace, when forcing a panic after the call to ata_reinit in
ata_resume:
db> trace
kdb_enter(c0684e14) at kdb_enter+0x2b
panic(c06716ac,c152e600,c152e600,c067169c,c155ec00) at panic+0x127
ata_resume(c155ec00) at ata_resume+0x3a
bus_generic_resume(c1564280) at bus_generic_resume+0x42
bus_generic_resume(c155d700,c18efc40,c06ba5e0,c18efc40,b) at bus_generic_resume+0x42
pci_resume(c155d700) at pci_resume+0x57
bus_generic_resume(c1530100,c1530100,c1530100,cbe92ac4,c07f8b2b) at bus_generic_resume+0x42
acpi_pcib_resume(c1530100,cbe92ad8,c05062d2,c1530100,c1530980) at acpi_pcib_resume+0x13
acpi_pcib_acpi_resume(c1530100) at acpi_pcib_acpi_resume+0xb
bus_generic_resume(c1530980) at bus_generic_resume+0x42
bus_generic_resume(c1530b00) at bus_generic_resume+0x42
bus_generic_resume(c14a7000,4,75003,16,80045003) at bus_generic_resume+0x42
acpi_SetSleepState(c1530900,3,1,cbe92b88,c06e42d8) at acpi_SetSleepState+0x2a0
acpiioctl(c06e42d8,80045003,cbe92c60,3,c1558960) at acpiioctl+0xa3
spec_ioctl(cbe92b88,cbe92c34,c054c1db,cbe92b88,c06db020) at spec_ioctl+0xd7
spec_vnoperate(cbe92b88) at spec_vnoperate+0x13
vn_ioctl(c190e088,80045003,cbe92c60,c190ae80,c1558960) at vn_ioctl+0x19f
ioctl(c1558960,cbe92d14,3,1,292) at ioctl+0x3e0
syscall(2f,2f,2f,bfbfedc0,3) at syscall+0x213
Xint0x80_syscall() at Xint0x80_syscall+0x1f

I don't know if this is enough, but let me know if you need more
information. 

Thanks,
Peter
-- 
"What I like most about myself is that I'm so understanding when I mess
things up."