ahci(4) hang reproduced, this time it was cdrdao scanbus
Joerg Schilling
Joerg.Schilling at fokus.fraunhofer.de
Sat Aug 15 12:19:17 UTC 2009
>wanted to burn an audio cd today and ran `cdrdao scanbus' to find out
>cdrdao's --device arg for the optical drive (turns out its the same
why do you use cdrdao for writing an audio CD?
>numbering as camcontrol devlist reports i.e.
> <PIONEER DVD-RW DVR-216D 1.09> at scbus3 target 0 lun 0 (cd1,pass3)
>becomes --device 3,0,0) - after which ahci(4) hung again with the board's
>disk access led on solid. This time tho I took a photo:
> http://people.freebsd.org/~nox/ahcihang1.jpg
This may be a bug in the driver, a driver is not allowed to do retries in case
that a command was send via SCSI pass through.
> cdrdao is in ports as sysutils/cdrdao and is mostly used for writing
>or cloning audio cds or vcds. (I haven't tried cdrecord's -scanbus
>command tho I wouldn't be surprised if it behaves the same... cdrecord
>is in ports as sysutils/cdrtools and sysutils/cdrtools-devel; you usually
>want cdrtools-devel.)
Cloning CDs is not really implemented in cdrdao, if you really like to
clone, use the clone feature from cdrtools:
readcd -clone f=img.out
cdreccord -v -raw96r -clone img.out
but note that there is a quality loss with cloning, I recommend to call this:
cdda2wav -vall cddb=0 -paranoia -Owav -B
cdrecord -v -sao -text -useinfo *.wav
for best quality of a CD-Audio copy.
>Oh and btw, the actual burning (after reboot + fsck) then went just
>fine, its just the scanbus command that ahci(4) apparently doesn't like...
If you like to see what causes the hang, call:
cdrecord -scanbus -V
Jörg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
More information about the freebsd-current
mailing list