Bug 20347

Summary: YAMAHA CDR100 does not like multiple LUN probing
Product: Base System Reporter: Andre Albsmeier <Andre.Albsmeier>
Component: kernAssignee: Kenneth D. Merry <ken>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.1-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description Andre Albsmeier 2000-08-01 20:10:01 UTC 
The YAMAHA CDR100 doesn't like multiple LUN probing. If you, for example,
wire down your devices like this

device          pass15  at scbus1 target 5
device          cd1     at scbus1 target 5
device          pass16  at scbus1 target 6
device          cd0     at scbus1 target 6

where target 5 is a "YAMAHA CDR100" and target 6 is another cdrom,
the following message appears in dmesg

(cd0:ahc1:0:5:0): Duplicate Wired Device entry!
(cd0:ahc1:0:5:0): Second device will not be wired
(cd0:ahc1:0:5:0): lost device
(cd0:ahc1:0:5:0): removing device entry

and the other cdrom (target 6) becomes cd1.

How-To-Repeat: 
Try the above example
Comment 1 ken 2000-08-01 21:03:09 UTC 
On Tue, Aug 01, 2000 at 21:07:32 +0200, Andre Albsmeier wrote:
> >Environment:
> 
> probably all FreeBSD versions
> 
> >Description:
> 
> The YAMAHA CDR100 doesn't like multiple LUN probing. If you, for example,
> wire down your devices like this
> 
> device          pass15  at scbus1 target 5
> device          cd1     at scbus1 target 5
> device          pass16  at scbus1 target 6
> device          cd0     at scbus1 target 6
> 
> where target 5 is a "YAMAHA CDR100" and target 6 is another cdrom,
> the following message appears in dmesg
> 
> (cd0:ahc1:0:5:0): Duplicate Wired Device entry!
> (cd0:ahc1:0:5:0): Second device will not be wired
> (cd0:ahc1:0:5:0): lost device
> (cd0:ahc1:0:5:0): removing device entry
> 
> and the other cdrom (target 6) becomes cd1.

This isn't a problem with the drive and multiple-lun probing, but rather a
problem with the hard-wiring code.

The problem is that the hard-wiring code evidently can't deal with multiple
peripheral drivers wired to the same bus/target/lun.

A work-around here would be to not hard-wire your pass devices, and just
hard-wire your CDROM devices.

Ken
-- 
Kenneth Merry
ken@kdm.org
Comment 2 Andre Albsmeier 2000-08-02 17:46:31 UTC 
On Tue, 01-Aug-2000 at 14:03:09 -0600, Kenneth D. Merry wrote:
> On Tue, Aug 01, 2000 at 21:07:32 +0200, Andre Albsmeier wrote:
> > >Environment:
> > 
> > probably all FreeBSD versions
> > 
> > >Description:
> > 
> > The YAMAHA CDR100 doesn't like multiple LUN probing. If you, for example,
> > wire down your devices like this
> > 
> > device          pass15  at scbus1 target 5
> > device          cd1     at scbus1 target 5
> > device          pass16  at scbus1 target 6
> > device          cd0     at scbus1 target 6
> > 
> > where target 5 is a "YAMAHA CDR100" and target 6 is another cdrom,
> > the following message appears in dmesg
> > 
> > (cd0:ahc1:0:5:0): Duplicate Wired Device entry!
> > (cd0:ahc1:0:5:0): Second device will not be wired
> > (cd0:ahc1:0:5:0): lost device
> > (cd0:ahc1:0:5:0): removing device entry
> > 
> > and the other cdrom (target 6) becomes cd1.
> 
> This isn't a problem with the drive and multiple-lun probing, but rather a
> problem with the hard-wiring code.
> 
> The problem is that the hard-wiring code evidently can't deal with multiple
> peripheral drivers wired to the same bus/target/lun.
> 
> A work-around here would be to not hard-wire your pass devices, and just
> hard-wire your CDROM devices.

I tried this already with the following entries:

#device         pass15  at scbus1 target 5
device          cd1     at scbus1 target 5
#device         pass16  at scbus1 target 6
device          cd0     at scbus1 target 6

Same result:

andre@bali:~>dmesg | egrep 'cd|pass0'
(pass0:ahc0:0:0:0): Duplicate Wired Device entry!
(pass0:ahc0:0:0:0): Second device will not be wired
(pass0:ahc0:0:0:0): Duplicate Wired Device entry!
(pass0:ahc0:0:0:0): Second device will not be wired
(cd0:ahc1:0:5:0): lost device
(cd0:ahc1:0:5:0): removing device entry
cd1 at ahc1 bus 0 target 6 lun 0
cd1: <PLEXTOR CD-ROM PX-40TS 1.11> Removable CD-ROM SCSI-2 device 
cd1: 20.000MB/s transfers (20.000MHz, offset 15)
cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed



Another try was this: I removed all wiring entries
from the kernel conf (leaving only a "device cd" line):

device cd
#device         pass15  at scbus1 target 5
#device         cd1     at scbus1 target 5
#device         pass16  at scbus1 target 6
#device         cd0     at scbus1 target 6

And the result:

andre@bali:~> dmesg | grep cd
(cd1:ahc1:0:5:0): lost device
(cd1:ahc1:0:5:0): removing device entry
cd0 at ahc1 bus 0 target 6 lun 0
cd0: <PLEXTOR CD-ROM PX-40TS 1.11> Removable CD-ROM SCSI-2 device
cd0: 20.000MB/s transfers (20.000MHz, offset 15)


I have three other Yamaha CD-Writers: CD400, CD4260 and a CD6416.
With all of these everything works perfectly.

Also, the CDR100 is known to be broken with multiple LUN probing.
You can see this if you enable the 'Multiple LUN support' in the
Adaptec BIOS: When booting, you will see 8 CDR100 devices appear
under the assigned SCSI ID when the controller BIOS scans the bus.
All other CD Writers behave normally here...


I think, we should consider putting the quirk entry into cam_xpt.c
-- sure the hard-wiring code will still have the problems you wrote
about but the CDR100 is broken for sure :-(

What do you think?

Thanks a lot,

	-Andre
Comment 3 ken 2000-08-06 20:33:42 UTC 
On Wed, Aug 02, 2000 at 18:46:31 +0200, Andre Albsmeier wrote:
> On Tue, 01-Aug-2000 at 14:03:09 -0600, Kenneth D. Merry wrote:
> > On Tue, Aug 01, 2000 at 21:07:32 +0200, Andre Albsmeier wrote:
> > > >Environment:
> > > 
> > > probably all FreeBSD versions
> > > 
> > > >Description:
> > > 
> > > The YAMAHA CDR100 doesn't like multiple LUN probing. If you, for example,
> > > wire down your devices like this
> > > 
> > > device          pass15  at scbus1 target 5
> > > device          cd1     at scbus1 target 5
> > > device          pass16  at scbus1 target 6
> > > device          cd0     at scbus1 target 6
> > > 
> > > where target 5 is a "YAMAHA CDR100" and target 6 is another cdrom,
> > > the following message appears in dmesg
> > > 
> > > (cd0:ahc1:0:5:0): Duplicate Wired Device entry!
> > > (cd0:ahc1:0:5:0): Second device will not be wired
> > > (cd0:ahc1:0:5:0): lost device
> > > (cd0:ahc1:0:5:0): removing device entry
> > > 
> > > and the other cdrom (target 6) becomes cd1.
> > 
> > This isn't a problem with the drive and multiple-lun probing, but rather a
> > problem with the hard-wiring code.
> > 
> > The problem is that the hard-wiring code evidently can't deal with multiple
> > peripheral drivers wired to the same bus/target/lun.
> > 
> > A work-around here would be to not hard-wire your pass devices, and just
> > hard-wire your CDROM devices.
> 
> I tried this already with the following entries:
> 
> #device         pass15  at scbus1 target 5
> device          cd1     at scbus1 target 5
> #device         pass16  at scbus1 target 6
> device          cd0     at scbus1 target 6
> 
> Same result:
> 
> andre@bali:~>dmesg | egrep 'cd|pass0'
> (pass0:ahc0:0:0:0): Duplicate Wired Device entry!
> (pass0:ahc0:0:0:0): Second device will not be wired
> (pass0:ahc0:0:0:0): Duplicate Wired Device entry!
> (pass0:ahc0:0:0:0): Second device will not be wired

You shouldn't get those messages unless you've got pass0 wired down...
In any case, that looks to be a different device than the one that is going
away:

> (cd0:ahc1:0:5:0): lost device
> (cd0:ahc1:0:5:0): removing device entry
> cd1 at ahc1 bus 0 target 6 lun 0
> cd1: <PLEXTOR CD-ROM PX-40TS 1.11> Removable CD-ROM SCSI-2 device 
> cd1: 20.000MB/s transfers (20.000MHz, offset 15)
> cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed
> 

It looks like there is some missing information in there, namely why cd0
went away...

> Another try was this: I removed all wiring entries
> from the kernel conf (leaving only a "device cd" line):
> 
> device cd
> #device         pass15  at scbus1 target 5
> #device         cd1     at scbus1 target 5
> #device         pass16  at scbus1 target 6
> #device         cd0     at scbus1 target 6
> 
> And the result:
> 
> andre@bali:~> dmesg | grep cd
> (cd1:ahc1:0:5:0): lost device
> (cd1:ahc1:0:5:0): removing device entry
> cd0 at ahc1 bus 0 target 6 lun 0
> cd0: <PLEXTOR CD-ROM PX-40TS 1.11> Removable CD-ROM SCSI-2 device
> cd0: 20.000MB/s transfers (20.000MHz, offset 15)

There weren't any other error messages before the 'lost device' message?

> I have three other Yamaha CD-Writers: CD400, CD4260 and a CD6416.
> With all of these everything works perfectly.
> 
> Also, the CDR100 is known to be broken with multiple LUN probing.
> You can see this if you enable the 'Multiple LUN support' in the
> Adaptec BIOS: When booting, you will see 8 CDR100 devices appear
> under the assigned SCSI ID when the controller BIOS scans the bus.
> All other CD Writers behave normally here...
> 
> 
> I think, we should consider putting the quirk entry into cam_xpt.c
> -- sure the hard-wiring code will still have the problems you wrote
> about but the CDR100 is broken for sure :-(
> 
> What do you think?

I think you're right, that drive needs a quirk entry, but it still isn't
clear to me what's going on with those error messages.

But all the problems go away when you add the quirk entry?

Ken
-- 
Kenneth Merry
ken@kdm.org
Comment 4 Andre Albsmeier 2000-08-07 05:49:59 UTC 
On Sun, 06-Aug-2000 at 13:33:42 -0600, Kenneth D. Merry wrote:
> On Wed, Aug 02, 2000 at 18:46:31 +0200, Andre Albsmeier wrote:
> > On Tue, 01-Aug-2000 at 14:03:09 -0600, Kenneth D. Merry wrote:
> > > On Tue, Aug 01, 2000 at 21:07:32 +0200, Andre Albsmeier wrote:
> > > > >Environment:
> > > > 
> > > > probably all FreeBSD versions
> > > > 
> > > > >Description:
> > > > 
> > > > The YAMAHA CDR100 doesn't like multiple LUN probing. If you, for example,
> > > > wire down your devices like this
> > > > 
> > > > device          pass15  at scbus1 target 5
> > > > device          cd1     at scbus1 target 5
> > > > device          pass16  at scbus1 target 6
> > > > device          cd0     at scbus1 target 6
> > > > 
> > > > where target 5 is a "YAMAHA CDR100" and target 6 is another cdrom,
> > > > the following message appears in dmesg
> > > > 
> > > > (cd0:ahc1:0:5:0): Duplicate Wired Device entry!
> > > > (cd0:ahc1:0:5:0): Second device will not be wired
> > > > (cd0:ahc1:0:5:0): lost device
> > > > (cd0:ahc1:0:5:0): removing device entry
> > > > 
> > > > and the other cdrom (target 6) becomes cd1.
> > > 
> > > This isn't a problem with the drive and multiple-lun probing, but rather a
> > > problem with the hard-wiring code.
> > > 
> > > The problem is that the hard-wiring code evidently can't deal with multiple
> > > peripheral drivers wired to the same bus/target/lun.
> > > 
> > > A work-around here would be to not hard-wire your pass devices, and just
> > > hard-wire your CDROM devices.
> > 
> > I tried this already with the following entries:
> > 
> > #device         pass15  at scbus1 target 5
> > device          cd1     at scbus1 target 5
> > #device         pass16  at scbus1 target 6
> > device          cd0     at scbus1 target 6
> > 
> > Same result:
> > 
> > andre@bali:~>dmesg | egrep 'cd|pass0'
> > (pass0:ahc0:0:0:0): Duplicate Wired Device entry!
> > (pass0:ahc0:0:0:0): Second device will not be wired
> > (pass0:ahc0:0:0:0): Duplicate Wired Device entry!
> > (pass0:ahc0:0:0:0): Second device will not be wired
> 
> You shouldn't get those messages unless you've got pass0 wired down...
> In any case, that looks to be a different device than the one that is going
> away:

Well, all others are wired down. pass0 is a standard disk drive. I have now
attached the complete dmesg below (with quirk entry and without errors :-))


> > (cd0:ahc1:0:5:0): lost device
> > (cd0:ahc1:0:5:0): removing device entry
> > cd1 at ahc1 bus 0 target 6 lun 0
> > cd1: <PLEXTOR CD-ROM PX-40TS 1.11> Removable CD-ROM SCSI-2 device 
> > cd1: 20.000MB/s transfers (20.000MHz, offset 15)
> > cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed
> > 
> 
> It looks like there is some missing information in there, namely why cd0
> went away...
> 
> > Another try was this: I removed all wiring entries
> > from the kernel conf (leaving only a "device cd" line):
> > 
> > device cd
> > #device         pass15  at scbus1 target 5
> > #device         cd1     at scbus1 target 5
> > #device         pass16  at scbus1 target 6
> > #device         cd0     at scbus1 target 6
> > 
> > And the result:
> > 
> > andre@bali:~> dmesg | grep cd
> > (cd1:ahc1:0:5:0): lost device
> > (cd1:ahc1:0:5:0): removing device entry
> > cd0 at ahc1 bus 0 target 6 lun 0
> > cd0: <PLEXTOR CD-ROM PX-40TS 1.11> Removable CD-ROM SCSI-2 device
> > cd0: 20.000MB/s transfers (20.000MHz, offset 15)
> 
> There weren't any other error messages before the 'lost device' message?

As far as I can remeber, no.


 
> > I have three other Yamaha CD-Writers: CD400, CD4260 and a CD6416.
> > With all of these everything works perfectly.
> > 
> > Also, the CDR100 is known to be broken with multiple LUN probing.
> > You can see this if you enable the 'Multiple LUN support' in the
> > Adaptec BIOS: When booting, you will see 8 CDR100 devices appear
> > under the assigned SCSI ID when the controller BIOS scans the bus.
> > All other CD Writers behave normally here...
> > 
> > 
> > I think, we should consider putting the quirk entry into cam_xpt.c
> > -- sure the hard-wiring code will still have the problems you wrote
> > about but the CDR100 is broken for sure :-(
> > 
> > What do you think?
> 
> I think you're right, that drive needs a quirk entry, but it still isn't
> clear to me what's going on with those error messages.

Well, I can do more tests if you like. I can do all variations of tests:
with and without quirk, with and w/o pass device, ....

Actually, the "lost device" together with the "removing device entry" errors
were already seen on 3.x-STABLE. I never cared about them since I don't really
use the CD functionality of the CDR100. But with 4.1-STABLE, the errors made
my cd0 drive (the Plextor) become cd1 and so I deciced to dig into this.


> But all the problems go away when you add the quirk entry?

Yes, I can even use the CDR100 as CD-ROM drive now.

Here is the complete dmesg now (with quirk entry):

Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD 4.1-STABLE #0: Thu Aug  3 22:25:07 CEST 2000
    root@bali.ofw.tld:/src/obj-4/src/src-4/sys/bali
Timecounter "i8254"  frequency 1193154 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (503.94-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x672  Stepping = 2
  Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,XMM>
real memory  = 268423168 (262132K bytes)
avail memory = 257937408 (251892K bytes)
Preloaded elf kernel "kernel" at 0xc0314000.
Pentium Pro MTRR support enabled
npx0: <math processor> on motherboard
npx0: INT 16 interface
apm0: <APM BIOS> on motherboard
apm: found APM BIOS v1.2, connected at v1.2
pcib0: <Intel 82443BX (440 BX) host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
pcib1: <Intel 82443BX (440 BX) PCI-PCI (AGP) bridge> at device 1.0 on pci0
pci1: <PCI bus> on pcib1
pci1: <Matrox MGA G400 AGP graphics accelerator> at 0.0 irq 11
isab0: <Intel 82371AB PCI to ISA bridge> at device 4.0 on pci0
isa0: <ISA bus> on isab0
pci0: <Intel PIIX4 ATA controller> at 4.1
pci0: <Intel 82371AB/EB (PIIX4) USB controller> at 4.2
intpm0: <Intel 82371AB Power management controller> port 0xe800-0xe80f irq 9 at device 4.3 on pci0
intpm0: I/O mapped e800
intpm0: intr IRQ 9 enabled revision 0
smbus0: <System Management Bus> on intsmb0
smb0: <SMBus general purpose I/O> on smbus0
intpm0: PM I/O mapped e400 
bktr0: <BrookTree 878> mem 0xe1000000-0xe1000fff irq 14 at device 9.0 on pci0
iicbb0: <I2C generic bit-banging driver> on bti2c0
iicbus0: <Philips I2C bus> on iicbb0 master-only
iicsmb0: <I2C to SMB bridge> on iicbus0
smbus1: <System Management Bus> on iicsmb0
smb1: <SMBus general purpose I/O> on smbus1
iic0: <I2C general purpose I/O> on iicbus0
smbus2: <System Management Bus> on bti2c0
smb2: <SMBus general purpose I/O> on smbus2
bktr0: Hauppauge Model 61314 B1M 
bktr0: Detected a MSP3410D-B4 at 0x80
Hauppauge WinCast/TV, Philips PAL I tuner, msp3400c stereo.
pci0: <unknown card> (vendor=0x109e, dev=0x0878) at 9.1 irq 14
fxp0: <Intel Pro 10/100B/100+ Ethernet> port 0xd000-0xd01f mem 0xde000000-0xde0fffff,0xe0000000-0xe0000fff irq 15 at device 10.0 on pci0
fxp0: Ethernet address 00:a0:c9:ca:9c:85
ahc0: <Adaptec 2940 Ultra2 SCSI adapter> port 0xb800-0xb8ff mem 0xdd800000-0xdd800fff irq 10 at device 11.0 on pci0
ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs
ahc1: <Adaptec 2940 Ultra SCSI adapter> port 0xb400-0xb4ff mem 0xdd000000-0xdd000fff irq 11 at device 12.0 on pci0
ahc1: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs
isa0: too many dependant configs (8)
isa0: unexpected small tag 14
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
vga0: <Generic ISA VGA> at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> on isa0
sc0: VGA <9 virtual consoles, flags=0x200>
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
fd1: <1200-KB 5.25" drive> on fdc0 drive 1
sio0 at port 0x3f8-0x3ff irq 4 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/9 bytes threshold
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven port
unknown: <PNP0401> can't assign resources
unknown: <PNP0501> can't assign resources
unknown: <PNP0501> can't assign resources
unknown: <PNP0700> can't assign resources
unknown: <PNP0f13> can't assign resources
unknown0: <PNP0c01> at iomem 0-0x9ffff,0x100000-0xfffffff,0xe8000-0xeffff,0xf0000-0xf3fff,0xf4000-0xf7fff,0xf8000-0xfffff,0xce600-0xcffff,0xfffe0000-0xffffffff on isa0
unknown: <PNP0000> can't assign resources
unknown1: <PNP0100> at port 0x40-0x43 irq 0 on isa0
unknown2: <PNP0b00> at port 0x70-0x71 irq 8 on isa0
unknown: <PNP0303> can't assign resources
unknown3: <PNP0c04> at port 0xf0 irq 13 on isa0
unknown4: <PNP0200> at port 0-0xf,0x80-0x90,0x94-0x9f,0xc0-0xde drq 4 on isa0
unknown5: <PNP0800> at port 0x61 on isa0
unknown6: <PNP0a03> at port 0xcf8-0xcff on isa0
unknown: <PNP0c02> can't assign resources
sbc0: <Creative SB AWE64> at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0
sbc0: setting card to irq 5, drq 1, 5
pcm0: <SB DSP 4.16> on sbc0
joy0: <Generic PnP Joystick> at port 0x200-0x207 on isa0
unknown7: <WaveTable> at port 0x620-0x623 on isa0
da0 at ahc0 bus 0 target 0 lun 0
da0: <QUANTUM XP32275W LYK8> Fixed Direct Access SCSI-2 device 
da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled
da0: 2170MB (4445380 512 byte sectors: 255H 63S/T 276C)
da1 at ahc0 bus 0 target 1 lun 0
da1: <QUANTUM XP32275W LYK8> Fixed Direct Access SCSI-2 device 
da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled
da1: 2170MB (4445380 512 byte sectors: 255H 63S/T 276C)
da2 at ahc0 bus 0 target 2 lun 0
da2: <QUANTUM XP34550W LYK8> Fixed Direct Access SCSI-2 device 
da2: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled
da2: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C)
da3 at ahc0 bus 0 target 3 lun 0
da3: <QUANTUM XP34550W LYK8> Fixed Direct Access SCSI-2 device 
da3: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled
da3: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C)
Mounting root from ufs:/dev/da2s1a
da10 at ahc1 bus 0 target 0 lun 0
da10: <iomega jaz 2GB E.17> Removable Direct Access SCSI-2 device 
da10: 20.000MB/s transfers (20.000MHz, offset 15)
da10: Attempt to query device size failed: NOT READY, Medium not present
da11 at ahc1 bus 0 target 1 lun 0
da11: <IOMEGA ZIP 100 E.08> Removable Direct Access SCSI-2 device 
da11: 3.300MB/s transfers
da11: Attempt to query device size failed: NOT READY, Medium not present
cd0 at ahc1 bus 0 target 6 lun 0
cd0: <PLEXTOR CD-ROM PX-40TS 1.11> Removable CD-ROM SCSI-2 device 
cd0: 20.000MB/s transfers (20.000MHz, offset 15)
cd0: cd present [224480 x 2048 byte records]
cd1 at ahc1 bus 0 target 5 lun 0
cd1: <YAMAHA CDR100 1.12> Removable Worm SCSI-2 device 
cd1: 3.300MB/s transfers
cd1: Attempt to query device size failed: NOT READY, Logical unit not ready, cause not reportable
Comment 5 Sheldon Hearn freebsd_committer freebsd_triage 2000-08-07 13:04:15 UTC 
Responsible Changed
From-To: freebsd-bugs->ken

Mr Merry seems to be getting into this one.
Comment 6 ken 2000-08-08 01:54:29 UTC 
On Mon, Aug 07, 2000 at 06:49:59 +0200, Andre Albsmeier wrote:
> On Sun, 06-Aug-2000 at 13:33:42 -0600, Kenneth D. Merry wrote:
> > On Wed, Aug 02, 2000 at 18:46:31 +0200, Andre Albsmeier wrote:
> > > I have three other Yamaha CD-Writers: CD400, CD4260 and a CD6416.
> > > With all of these everything works perfectly.
> > > 
> > > Also, the CDR100 is known to be broken with multiple LUN probing.
> > > You can see this if you enable the 'Multiple LUN support' in the
> > > Adaptec BIOS: When booting, you will see 8 CDR100 devices appear
> > > under the assigned SCSI ID when the controller BIOS scans the bus.
> > > All other CD Writers behave normally here...
> > > 
> > > 
> > > I think, we should consider putting the quirk entry into cam_xpt.c
> > > -- sure the hard-wiring code will still have the problems you wrote
> > > about but the CDR100 is broken for sure :-(
> > > 
> > > What do you think?
> > 
> > I think you're right, that drive needs a quirk entry, but it still isn't
> > clear to me what's going on with those error messages.
> 
> Well, I can do more tests if you like. I can do all variations of tests:
> with and without quirk, with and w/o pass device, ....
> 
> Actually, the "lost device" together with the "removing device entry" errors
> were already seen on 3.x-STABLE. I never cared about them since I don't really
> use the CD functionality of the CDR100. But with 4.1-STABLE, the errors made
> my cd0 drive (the Plextor) become cd1 and so I deciced to dig into this.

Well, could you try wiring down your devices with LUNs as well?  e.g.:

device		cd1	at scbus1 target 5 unit 0

I think your drive needs a quirk entry, definitely, but I'm curious to see
whether wiring down the devices would fix the problem.

Ken
-- 
Kenneth Merry
ken@kdm.org
Comment 7 Andre Albsmeier 2000-08-08 07:21:09 UTC 
On Mon, 07-Aug-2000 at 18:54:29 -0600, Kenneth D. Merry wrote:
> On Mon, Aug 07, 2000 at 06:49:59 +0200, Andre Albsmeier wrote:
> > On Sun, 06-Aug-2000 at 13:33:42 -0600, Kenneth D. Merry wrote:
> > > On Wed, Aug 02, 2000 at 18:46:31 +0200, Andre Albsmeier wrote:
> > > > I have three other Yamaha CD-Writers: CD400, CD4260 and a CD6416.
> > > > With all of these everything works perfectly.
> > > > 
> > > > Also, the CDR100 is known to be broken with multiple LUN probing.
> > > > You can see this if you enable the 'Multiple LUN support' in the
> > > > Adaptec BIOS: When booting, you will see 8 CDR100 devices appear
> > > > under the assigned SCSI ID when the controller BIOS scans the bus.
> > > > All other CD Writers behave normally here...
> > > > 
> > > > 
> > > > I think, we should consider putting the quirk entry into cam_xpt.c
> > > > -- sure the hard-wiring code will still have the problems you wrote
> > > > about but the CDR100 is broken for sure :-(
> > > > 
> > > > What do you think?
> > > 
> > > I think you're right, that drive needs a quirk entry, but it still isn't
> > > clear to me what's going on with those error messages.
> > 
> > Well, I can do more tests if you like. I can do all variations of tests:
> > with and without quirk, with and w/o pass device, ....
> > 
> > Actually, the "lost device" together with the "removing device entry" errors
> > were already seen on 3.x-STABLE. I never cared about them since I don't really
> > use the CD functionality of the CDR100. But with 4.1-STABLE, the errors made
> > my cd0 drive (the Plextor) become cd1 and so I deciced to dig into this.
> 
> Well, could you try wiring down your devices with LUNs as well?  e.g.:
> 
> device		cd1	at scbus1 target 5 unit 0
> 
> I think your drive needs a quirk entry, definitely, but I'm curious to see
> whether wiring down the devices would fix the problem.
> 

This brings me back to 3.5-STABLE behaviour:

(cd1:ahc1:0:5:0): lost device
(cd1:ahc1:0:5:0): removing device entry

and

cd0 at ahc1 bus 0 target 6 lun 0
cd0: <PLEXTOR CD-ROM PX-40TS 1.11> Removable CD-ROM SCSI-2 device 
cd0: 20.000MB/s transfers (20.000MHz, offset 15)
cd0: cd present [224480 x 2048 byte records]

This is OK since the CDR100 is known to be offended when it gets
probed for more LUNs (even with ROM Version 1.12 :-().

Here is the relevant part of the config file:

device		ahc0
device		scbus0	at ahc0
device		pass0	at scbus0 target 0 unit 0
device		da0	at scbus0 target 0 unit 0
device		pass1	at scbus0 target 1 unit 0
device		da1	at scbus0 target 1 unit 0
device		pass2	at scbus0 target 2 unit 0
device		da2	at scbus0 target 2 unit 0
device		pass3	at scbus0 target 3 unit 0
device		da3	at scbus0 target 3 unit 0
device		pass4	at scbus0 target 4 unit 0
device		da4	at scbus0 target 4 unit 0
device		pass5	at scbus0 target 5 unit 0
device		da5	at scbus0 target 5 unit 0
device		pass6	at scbus0 target 6 unit 0
device		da6	at scbus0 target 6 unit 0

device		ahc1
device		scbus1	at ahc1
device		pass10	at scbus1 target 0 unit 0
device		da10	at scbus1 target 0 unit 0
device		pass11	at scbus1 target 1 unit 0
device		da11	at scbus1 target 1 unit 0
device		pass12	at scbus1 target 2 unit 0
device		da12	at scbus1 target 2 unit 0
device		pass13	at scbus1 target 3 unit 0
device		da13	at scbus1 target 3 unit 0
device		pass14	at scbus1 target 4 unit 0
device		da14	at scbus1 target 4 unit 0
device		pass15	at scbus1 target 5 unit 0
device		cd1	at scbus1 target 5 unit 0
device		pass16	at scbus1 target 6 unit 0
device		cd0	at scbus1 target 6 unit 0


Do you want me to try more things ?

	-Andre
Comment 8 ken 2000-08-08 07:43:28 UTC 
On Tue, Aug 08, 2000 at 08:21:09 +0200, Andre Albsmeier wrote:
> On Mon, 07-Aug-2000 at 18:54:29 -0600, Kenneth D. Merry wrote:
> > Well, could you try wiring down your devices with LUNs as well?  e.g.:
> > 
> > device		cd1	at scbus1 target 5 unit 0
> > 
> > I think your drive needs a quirk entry, definitely, but I'm curious to see
> > whether wiring down the devices would fix the problem.
> > 
> 
> This brings me back to 3.5-STABLE behaviour:
> 
> (cd1:ahc1:0:5:0): lost device
> (cd1:ahc1:0:5:0): removing device entry
> 
> and
> 
> cd0 at ahc1 bus 0 target 6 lun 0
> cd0: <PLEXTOR CD-ROM PX-40TS 1.11> Removable CD-ROM SCSI-2 device 
> cd0: 20.000MB/s transfers (20.000MHz, offset 15)
> cd0: cd present [224480 x 2048 byte records]
> 
> This is OK since the CDR100 is known to be offended when it gets
> probed for more LUNs (even with ROM Version 1.12 :-().

[ ... ]

> Do you want me to try more things ?

No, that's all right.  I think there may be something wrong with the
hardwiring code, but I don't really feel like looking into it at the
moment. :)

Thanks for trying things out, though.

I'll commit the quirk entry.

Ken
-- 
Kenneth Merry
ken@kdm.org
Comment 9 Kenneth D. Merry freebsd_committer freebsd_triage 2000-08-08 07:54:12 UTC 
State Changed
From-To: open->closed

Thanks for the report, and thanks for doing diagnostics for me. :) 

Patch commited in rev 1.90 of cam_xpt.c in -current, rev 1.80.2.6 in 
RELENG_4 and rev 1.42.2.23 in cam_xpt.c.