From andre.albsmeier@mchp.siemens.de  Tue Aug  1 12:07:36 2000
Return-Path: <andre.albsmeier@mchp.siemens.de>
Received: from david.siemens.de (david.siemens.de [192.35.17.14])
	by hub.freebsd.org (Postfix) with ESMTP id 3874037B8D7
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  1 Aug 2000 12:07:35 -0700 (PDT)
	(envelope-from andre.albsmeier@mchp.siemens.de)
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by david.siemens.de (8.10.1/8.10.1) with ESMTP id e71J7X611663
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 1 Aug 2000 21:07:33 +0200 (MET DST)
Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.42.7])
	by mail1.siemens.de (8.10.1/8.10.1) with ESMTP id e71J7W122137
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 1 Aug 2000 21:07:32 +0200 (MET DST)
Received: (from localhost)
	by curry.mchp.siemens.de (8.10.2/8.10.2) id e71J7Wa33519
	for FreeBSD-gnats-submit@freebsd.org; Tue, 1 Aug 2000 21:07:32 +0200 (CEST)
Message-Id: <200008011907.e71J7WU00651@curry.mchp.siemens.de>
Date: Tue, 1 Aug 2000 21:07:32 +0200 (CEST)
From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
To: FreeBSD-gnats-submit@freebsd.org
Subject: YAMAHA CDR100 does not like multiple LUN probing
X-Send-Pr-Version: 3.2

>Number:         20347
>Category:       kern
>Synopsis:       YAMAHA CDR100 does not like multiple LUN probing
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    ken
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Aug 01 12:10:01 PDT 2000
>Closed-Date:    Mon Aug 7 23:54:12 PDT 2000
>Last-Modified:  Mon Aug 07 23:55:45 PDT 2000
>Originator:     Andre Albsmeier
>Release:        FreeBSD 4.1-STABLE i386
>Organization:
>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.


>How-To-Repeat:

Try the above example

>Fix:

--- sys/cam/cam_xpt.c.ORI	Tue Aug  1 20:54:41 2000
+++ sys/cam/cam_xpt.c	Tue Aug  1 20:57:00 2000
@@ -418,6 +418,10 @@
 		CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0
 	},
 	{
+		{ T_WORM, SIP_MEDIA_REMOVABLE, "YAMAHA", "CDR100*", "*" },
+		CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0
+	},
+	{
 		/*
 		 * The 8200 doesn't like multi-lun probing, and probably
 		 * don't like serial number requests either.

>Release-Note:
>Audit-Trail:

From: "Kenneth D. Merry" <ken@kdm.org>
To: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/20347: YAMAHA CDR100 does not like multiple LUN probing
Date: Tue, 1 Aug 2000 14:03:09 -0600

 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
 

From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>,
	FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/20347: YAMAHA CDR100 does not like multiple LUN probing
Date: Wed, 2 Aug 2000 18:46:31 +0200

 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
 

From: "Kenneth D. Merry" <ken@kdm.org>
To: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/20347: YAMAHA CDR100 does not like multiple LUN probing
Date: Sun, 6 Aug 2000 13:33:42 -0600

 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
 

From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>,
	FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/20347: YAMAHA CDR100 does not like multiple LUN probing
Date: Mon, 7 Aug 2000 06:49:59 +0200

 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
 
Responsible-Changed-From-To: freebsd-bugs->ken 
Responsible-Changed-By: sheldonh 
Responsible-Changed-When: Mon Aug 7 05:04:15 PDT 2000 
Responsible-Changed-Why:  
Mr Merry seems to be getting into this one. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=20347 

From: "Kenneth D. Merry" <ken@kdm.org>
To: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/20347: YAMAHA CDR100 does not like multiple LUN probing
Date: Mon, 7 Aug 2000 18:54:29 -0600

 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
 

From: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>,
	FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/20347: YAMAHA CDR100 does not like multiple LUN probing
Date: Tue, 8 Aug 2000 08:21:09 +0200

 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
 

From: "Kenneth D. Merry" <ken@kdm.org>
To: Andre Albsmeier <andre.albsmeier@mchp.siemens.de>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/20347: YAMAHA CDR100 does not like multiple LUN probing
Date: Tue, 8 Aug 2000 00:43:28 -0600

 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
 
State-Changed-From-To: open->closed 
State-Changed-By: ken 
State-Changed-When: Mon Aug 7 23:54:12 PDT 2000 
State-Changed-Why:  
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. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=20347 
>Unformatted:
