Re: strange umass/scsi behaviour
On Thu, 31 Jul 2003, John Hay wrote: Does anyone have an idea why the umass/scsi code behave differently between if you boot with a device already plugged in as opposed to plugging it in later? In my case it is a Sandisk Cruiser. If I plug it in before booting, it works just great, but if I plug it in later, it does not want to work. The problem is that only da0 pitch up in the /dev directory. There should be a da0s1 too. Using fdisk on da0 does show what looks like a valid partition table with one DOS partition. I have tried camcontrol reset, inquiry, start and rescan, but can't get da0s1 to make its appearance. Sounds like a GEOM problem. Unless you have other errors from da0 after the last line you posted, it appears the command retry attempt succeeded. At that point, the problem is likely with GEOM not parsing the partition table when it appears and making the slice show up. But I don't know enough about GEOM to claim this its fault. Ok, but why does geom pick it up correctly when booting with the disk plugged in? Does geom mabe get called before the disk is ready? If that Opened disk ... message is from geom, the order of things looks like geom gets called just after the Unretryable error. When you boot with it attached, USB is turned on early enough in the boot cycle that the delay while probing SCSI/ATA devices gives the USB device enough time to warm up before GEOM does its taste of the device (last in the boot cycle). I'm sending a copy of this to phk@ to see if he has any further thoughts. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange umass/scsi behaviour
John Hay wrote: Does anyone have an idea why the umass/scsi code behave differently between if you boot with a device already plugged in as opposed to plugging it in later? In my case it is a Sandisk Cruiser. If I plug it in before booting, it works just great, but if I plug it in later, it does not want to work. Below is the dmesg output of the various stages. [ ... ] I had a disk that would behave in exactly this way. Try this: camcontrol debug -I -P -T -S -X -c 0:0:0 camcontrol reset 0:0:0 camcontrol rescan 0:0:0 Probably it will just work after the reset/rescan without the debug; the disk I had wanted an explicit bus reset after it was connected, and that made it happy. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange umass/scsi behaviour
On Wed, 30 Jul 2003, John Hay wrote: Does anyone have an idea why the umass/scsi code behave differently between if you boot with a device already plugged in as opposed to plugging it in later? In my case it is a Sandisk Cruiser. If I plug it in before booting, it works just great, but if I plug it in later, it does not want to work. umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer 2.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) There's nothing sinister going on here. What happens is your device is slow to power up and initialize when plugged in. It's not ready for the bus scan from CAM but it's awake enough to answer the initial INQUIRY. When you boot with it attached, there's a longer delay between when the port is powered up and CAM scans the device and so you don't get any messages. What behavior does the device give after you get the above dmesg? Does it print out errors on console that the retry failed? (see last line of the dmesg). I've been thinking about adding a bit of a delay to the umass CAM attach call for such devices. uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xece0-0xecff irq 11 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 Port powered up. [~3 secs, perhaps] ad0: 6194MB IBM-DADA-26480 [13424/15/63] at ata0-master UDMA33 acd0: CDROM TEAC CD-ROM CD-224E at ata1-master PIO4 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer 2.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 14MB (29120 512 byte sectors: 64H 32S/T 14C) Device probed. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange umass/scsi behaviour
On Tue, Jul 29, 2003 at 11:28:18PM -0700, Nate Lawson wrote: On Wed, 30 Jul 2003, John Hay wrote: Does anyone have an idea why the umass/scsi code behave differently between if you boot with a device already plugged in as opposed to plugging it in later? In my case it is a Sandisk Cruiser. If I plug it in before booting, it works just great, but if I plug it in later, it does not want to work. umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer 2.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) There's nothing sinister going on here. What happens is your device is slow to power up and initialize when plugged in. It's not ready for the bus scan from CAM but it's awake enough to answer the initial INQUIRY. When you boot with it attached, there's a longer delay between when the port is powered up and CAM scans the device and so you don't get any messages. What behavior does the device give after you get the above dmesg? Does it print out errors on console that the retry failed? (see last line of the dmesg). I've been thinking about adding a bit of a delay to the umass CAM attach call for such devices. The last message is Opened disk da0 - 6. That is a little strange because I thought we only do 10 byte commands to usb devices. The problem is that only da0 pitch up in the /dev directory. There should be a da0s1 too. Using fdisk on da0 does show what looks like a valid partition table with one DOS partition. I have tried camcontrol reset, inquiry, start and rescan, but can't get da0s1 to make its appearance. uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xece0-0xecff irq 11 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 Port powered up. [~3 secs, perhaps] ad0: 6194MB IBM-DADA-26480 [13424/15/63] at ata0-master UDMA33 acd0: CDROM TEAC CD-ROM CD-224E at ata1-master PIO4 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer 2.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 14MB (29120 512 byte sectors: 64H 32S/T 14C) Device probed. Yip, if I get that far, the disk is accessable. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange umass/scsi behaviour
On Wed, Jul 30, 2003 at 08:44:34AM +0200, John Hay wrote: The last message is Opened disk da0 - 6. That is a little strange because I thought we only do 10 byte commands to usb devices. The problem is that only da0 pitch up in the /dev directory. There should be a da0s1 too. Using fdisk on da0 does show what looks like a valid partition table with one DOS partition. I have tried camcontrol reset, inquiry, start and rescan, but can't get da0s1 to make its appearance. AFAIK, the message Opened disk da0 - 6 is from GEOM and means that the attempt to open the da0 device resulted in error 6 -- ENXIO, Device not configured. That can happen if the device is unplugged early or, as in your case, if the device comes up too slowly. As for the problem with the slice node not appearing, I suspect it has to do with GEOM, too. GEOM seems to have bugs that can be triggered by plugging or unplugging devices on the fly. Perhaps Poul-Henning could drop a comment on that. -- Yar ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange umass/scsi behaviour
On Wed, 30 Jul 2003, John Hay wrote: On Tue, Jul 29, 2003 at 11:28:18PM -0700, Nate Lawson wrote: On Wed, 30 Jul 2003, John Hay wrote: Does anyone have an idea why the umass/scsi code behave differently between if you boot with a device already plugged in as opposed to plugging it in later? In my case it is a Sandisk Cruiser. If I plug it in before booting, it works just great, but if I plug it in later, it does not want to work. umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer 2.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) There's nothing sinister going on here. What happens is your device is slow to power up and initialize when plugged in. It's not ready for the bus scan from CAM but it's awake enough to answer the initial INQUIRY. When you boot with it attached, there's a longer delay between when the port is powered up and CAM scans the device and so you don't get any messages. What behavior does the device give after you get the above dmesg? Does it print out errors on console that the retry failed? (see last line of the dmesg). I've been thinking about adding a bit of a delay to the umass CAM attach call for such devices. The last message is Opened disk da0 - 6. No, according to your message it's Retrying Command (per Sense Data). That is a little strange because I thought we only do 10 byte commands to usb devices. That message is from GEOM and has nothing to do with 10 byte commands. The problem is that only da0 pitch up in the /dev directory. There should be a da0s1 too. Using fdisk on da0 does show what looks like a valid partition table with one DOS partition. I have tried camcontrol reset, inquiry, start and rescan, but can't get da0s1 to make its appearance. Sounds like a GEOM problem. Unless you have other errors from da0 after the last line you posted, it appears the command retry attempt succeeded. At that point, the problem is likely with GEOM not parsing the partition table when it appears and making the slice show up. But I don't know enough about GEOM to claim this its fault. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange umass/scsi behaviour
Does anyone have an idea why the umass/scsi code behave differently between if you boot with a device already plugged in as opposed to plugging it in later? In my case it is a Sandisk Cruiser. If I plug it in before booting, it works just great, but if I plug it in later, it does not want to work. umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer 2.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) ... What behavior does the device give after you get the above dmesg? Does it print out errors on console that the retry failed? (see last line of the dmesg). I've been thinking about adding a bit of a delay to the umass CAM attach call for such devices. The last message is Opened disk da0 - 6. No, according to your message it's Retrying Command (per Sense Data). Yip, you are right, I was looking here locally, but that was after trying lots of camcontrol commands. That is a little strange because I thought we only do 10 byte commands to usb devices. That message is from GEOM and has nothing to do with 10 byte commands. ok The problem is that only da0 pitch up in the /dev directory. There should be a da0s1 too. Using fdisk on da0 does show what looks like a valid partition table with one DOS partition. I have tried camcontrol reset, inquiry, start and rescan, but can't get da0s1 to make its appearance. Sounds like a GEOM problem. Unless you have other errors from da0 after the last line you posted, it appears the command retry attempt succeeded. At that point, the problem is likely with GEOM not parsing the partition table when it appears and making the slice show up. But I don't know enough about GEOM to claim this its fault. Ok, but why does geom pick it up correctly when booting with the disk plugged in? Does geom mabe get called before the disk is ready? If that Opened disk ... message is from geom, the order of things looks like geom gets called just after the Unretryable error. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
strange umass/scsi behaviour
Hi, Does anyone have an idea why the umass/scsi code behave differently between if you boot with a device already plugged in as opposed to plugging it in later? In my case it is a Sandisk Cruiser. If I plug it in before booting, it works just great, but if I plug it in later, it does not want to work. Below is the dmesg output of the various stages. # Here I have plugged it in after FreeBSD was already up and running. umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk Cruzer 2.00 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) # Here I boot with it plugged in. FreeBSD 5.1-CURRENT #12: Tue Jul 29 09:59:56 SAST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LAPTOP Preloaded elf kernel /boot/kernel/kernel at 0xc04e5000. Preloaded elf module /boot/kernel/snd_neomagic.ko at 0xc04e51f4. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04e52a8. Preloaded elf module /boot/kernel/acpi.ko at 0xc04e5354. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 363961368 Hz CPU: Pentium II/Pentium II Xeon/Celeron (363.96-MHz 686-class CPU) Origin = GenuineIntel Id = 0x66a Stepping = 10 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134135808 (127 MB) avail memory = 124919808 (119 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: DELL CPi A on motherboard pcibios: BIOS version 2.10 Using $PIR table, 5 entries at 0xc00fbda0 Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_acad0: AC adapter on acpi0 acpi_cmbat0: Control method Battery on acpi0 acpi_cmbat1: Control method Battery on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Power Button on acpi0 acpi_button1: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 7 INTD is routed to irq 11 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xf400-0xf7ff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib1: slot 0 INTA is routed to irq 11 pcib1: slot 0 INTB is routed to irq 5 pci1: display, VGA at device 0.0 (no driver attached) pcm0: NeoMagic 256AV mem 0xfda0-0xfdaf,0xf8c0-0xf8ff irq 5 at device 0.1 on pci1 pcm0: SigmaTel STAC9704 AC97 Codec cbb0: TI1225 PCI-CardBus Bridge at device 3.0 on pci0 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 pcib0: slot 3 INTA is routed to irq 11 cbb1: TI1225 PCI-CardBus Bridge at device 3.1 on pci0 cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 pcib0: slot 3 INTA is routed to irq 11 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 UDMA33 controller port 0x860-0x86f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xece0-0xecff irq 11 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered umass0: SanDisk Cruzer, rev 1.10/1.00, addr 2 pci0: bridge, PCI-unknown at device 7.3 (no driver attached) atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 orm0: Option ROMs at iomem 0xcf800-0xc,0xcf000-0xcf7ff,0xce800-0xcefff,0xce000-0xce7ff,0xc-0xcdfff on isa0 pmtimer0 on isa0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 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/8 bytes threshold
