In article <106085798526...@192.168.2.69> you write:
>Hi,
Hi!
>
>the switch to ahci was successful and it looks
>quite good, overall.
>
>But probably i found a bug. I could need advise
>where and how to submit it.
>
>A particular sequence of SCSI commands leads to
>an elsewise harmless stall of the dialog between
>libburn and drive.
>To close and re-open the libcam connection before
>this sequence is enough to circumvent the
>problem. But this remedy is not desirable.
>
>Long story:
>------------------------------------------------
>
>I did the switch to ahci. Now my disk is
>ada and my eSATA attached burner is not acd1|cd1
>but only cd0.
>
>The IDE ROM works fine with the vanilla
>configuration. It obviously staid under ata
>control as acd0|cd1.
>
>With the poor eSATA connection at 3000 GBit/s
>i still get the stalls. But after killing the
>writing process and about 4 minutes of waiting
>i get my drive back in most cases.
>Sometimes i have to do a power cycle on the drive
>to get it back as /dev/cd0.
>Still no reboot or panic. I begin to like ahci.
>(I find no trace of power cycle or re-plugging
> in dmesg.)
>
Ah thats good! :) You could try booting with verbose logging (I think
thats option 5. in the beastie menu that comes up at boot), maybe then
you will see something.
>
>The speed setter in camcontrol seems not to work.
>Writing still gets stuck after a few MB.
>
Is this on 8.0 release or on stable/8 or head? As I said maybe that
part of the code wasn't in 8.0 yet...
>So i used the boot time option.
>dmesg tells:
> cd0 at ahcich4 bus 0 target 0 lun 0
> cd0: <TSSTcorp CDDVDW SH-S223B SB02> Removable CD-ROM SCSI-0 device
> cd0: 300.000MB/s transfers
>
>I added to /boot/device.hints :
> hint.ahcich.4.sata_rev="1"
>
>After reboot, i see in dmesg:
> cd0 at ahcich4 bus 0 target 0 lun 0
> cd0: <TSSTcorp CDDVDW SH-S223B SB02> Removable CD-ROM SCSI-0 device
> cd0: 150.000MB/s transfers
>
>Now everything seems to work - except libburn.
>Grrr.
>
>
>Writing looks good. But it does not end.
>It is stuck in
> READ DISC INFORMATION
> 51 00 00 00 00 00 00 00 22 00
>and waits for the reply of the drive.
>This happens when the new media state shall be
>inquired after burning was completed.
>
>If i do
> cam_close_device()
>and re-open the drive, then the same command
>sequence succeeds.
>(But this is a very undesirable gesture at that
> point of processing.)
>
>The problem does not appear with USB (and did
>not while the drive was built-in at SATA).
>The drive is surely not to blame.
>
>So now i could need advise about filing a bug
>report.
>
I have Cc'd mav@ who afaik did most of the ahci(4) work, let's see what
he has to say and if he wants you to file a PR...
>------------------------------------------------
>
>Have a nice day :)
>
>Thomas
Ditto! :)
Juergen
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
