On Tue, 16-Apr-2013 at 21:38:22 +0200, Jeremy Chadwick wrote:
On Tue, Apr 16, 2013 at 07:55:20PM +0200, Andre Albsmeier wrote:
I have lost one of my CDROM drives (HL-DT-STDVD-RAM GH22LP20/2.00)
after going from 7.4 to 9.1 when using ATA_CAM. It is attached to
a Promise PDC20268 UDMA100 controller. A standard harddisk drive
attached to this controller works well. Cables, controller and drive
where replaced already.
Kernel gives me:
atapci1: <Promise PDC20268 UDMA100 controller> port
0xb000-0xb007,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9800-0x980f mem
0xdf800000-0xdf803fff irq 11 at device 12.0 on pci0
ata2: <ATA channel> at channel 0 on atapci1
ata3: <ATA channel> at channel 1 on atapci1
...
ada0 at ata2 bus 0 scbus2 target 0 lun 0
ada0: <Maxtor 7B300R0 BAH41G10> ATA-7 device
ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
ada0: 286188MB (586114704 512 byte sectors: 16H 63S/T 16383C)
...
(cd2:ata3:0:0:0): got CAM status 0x50
(cd2:ata3:0:0:0): fatal error, failed to attach to device
(cd2:ata3:0:0:0): lost device, 4 refs
(cd2:ata3:0:0:0): removing device entry
...
Attaching the CDROM drive to the controller that is integrated on
the mainboard (Intel PIIX4 UDMA33 controller) does not show this
problem (but here I don't have UDMA66).
It also works when not using ATA_CAM:
...
acd0: DVDR <HL-DT-STDVD-RAM GH22LP20/2.00> at ata3-master UDMA66
...
So this semes to be a problem with the Promise controller and ATA_CAM.
Any ideas? Or should I file PR?
The controller in question is a Promise Ultra100 TX2.
Right. Tried with an Ultra133, same effect.
The error message comes from sys/cam/scsi/scsi_cd.c, in function
cddone(). The logic is a little hard for me to follow (I understand
about 70% of it). Look at lines 1724 to 1877 for stable/9.
1. Can you provide full output from a verbose boot when the CD/DVD drive
is attached to the Promise controller?
Attached below. I have just filtered out some ahc cruft...
Later I will try to boot a -current kernel -- just to see
how this behaves...
2. What firmware version the card is using? The PDC20268 had many, many
firmware problems relating to ATAPI devices.
It is the latest BIOS: 2.20.0.15.
3. I wouldn't worry about ATA66 vs. ATA33; this drive can only support
up to about 22MBytes/second so ATA66 isn't going to get you anything,
so as a workaround, using the PIIX4 for it would not hurt you.
Probably. But I already had cdrecord complain when it
came to the funky DMA speed test it is doing. It went
away when using the UDMA66 port. And on the other hand
I sometimes use the PIIX4 port for other stuff and I
do not want to attach the cdrom to the slave port.
4. ONLY if this turns out to be a "controller thing": I'm not sure how
much effort should be spent trying to make this work, as the PDC20268 is
legacy/deprecated hardware (made/released 13 years ago).
The whole box is more than 13 years old (good old Asus BX board) ;-)
But since it worked in 7.4-STABLE I feel that this is some kind
of regression. I do not want to waste anyone's resources in fixing
it -- just if someone is curious and/or has an idea how to fix
it...
And here is the dmesg:
{snipping for mail brevity}
