Re: live-USB on SanDisk Cruzer Glide (was: Re: USB hubs/controllers detached before umass devices)
I've tested on a few different machines I have at my disposal and in
all cases, NetBSD/{amd64,i386} (-10 or current) booted from a SanDisk
Cruzer Glide (16GB) and mounting a filesystem read/write will report
an HBA error and write errors on shutdown.
I've now moved my NetBSD-10 live-USB installations to USB flash drives by
PNY and they have no issues upon system shutdown.
The SanDisk devices do work, I just can't use one as a bootable device
with NetBSD.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
live-USB on SanDisk Cruzer Glide (was: Re: USB hubs/controllers detached before umass devices)
On Sat, 16 Mar 2024, John D. Baker wrote: > On Sat, 16 Mar 2024, John D. Baker wrote: > > > The only difference is that the USB devices with netbsd-10 are > > branded SanDisk and the ones with -current are branded PNY. I've just completed a dump/restore to swap the i386 live images so that 10.0_RC6 is on the PNY flash drive and -current (10.99.10) is on the SanDisk flash drive. The problem follows the SanDisk drive. Anything that causes the filesystem to be altered provokes the "Generic HBA error" (and if the disk was actually mounted, further "error writing fsbn " messages). Hitting reset to skip the 40-minute wait for all the retries to time out, rebooting the live image single-user and running 'fsck' to repair the filesystem, then immediately issuing 'halt', the system again reports the "Generic HBA error" but continues with the remaining steps to halt the system. Has anyone else had issues using a SanDisk USB flash drive for a NetBSD live image for NetBSD 9.99.*, -10, -current? These exact same SanDisk USB flash drives (Cruzer Glide 16GB) have been used with netbsd-8 and netbsd-9 in the past and did not exhibit this problem. (By "used", I mean installed/updated/tested. They've never seen any active use beyond that.) When used as a non-boot disk, it doesn't seem to have any problem even if left mounted at system halt/reboot. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: USB hubs/controllers detached before umass devices
On Sat, 16 Mar 2024, John D. Baker wrote: > The only difference is that the USB devices with netbsd-10 are > branded SanDisk and the ones with -current are branded PNY. > > Still updating/checking the netbsd-10/i386 live-USB setup. Same as my netbsd-10/amd64 live-USB setup. Seems anything that modifies the filesystem, even something relatively harmless like a forced 'fsck' on an already-clean file system from single-user mode will trigger the problem when the machine is then halted or rebooted. Below is an example of simply allowing the system to go multi-user, logging in and rebooting: $ shutdown -r now ; exit Shutdown NOW! shutdown: [pid 1223] wall: You have write permission turned off; no reply possible Mar 16 20:16:44 nblive10_i386 shutdown: reboot by live: NetBSD/i386 (nblive10_i386) (constty) login: Mar 16 20:16:52 nblive10_i386 syslogd[442]: Exiting on signal 15 [ 75.2656479] syncing disks... done [ 75.3859144] wd5: detached [ 75.4236845] wd4: detached [ 75.4460055] wd3: detached [ 75.4860049] wd2: detached [ 75.5160043] wd1: detached [ 75.5460050] wd0: detached [ 75.5760051] uhub3: detached [ 75.6060050] uhub2: detached [ 75.6460050] uhub1: detached [ 75.6760039] uhub0: detached [ 75.7060038] inphy0: detached [ 75.7460049] fxp0: detached [ 75.7760043] audio0: detached [ 75.8060036] makphy0: detached [ 75.8460037] wm0: detached [ 75.8760037] iic0: detached [ 75.9060045] atabus2: detached [ 75.9460035] atabus1: detached [ 75.9760037] atabus0: detached [ 76.0183341] usb3: detached [ 76.0505600] usb2: detached [ 76.0827866] usb1: detached [ 76.1150118] usb0: detached [ 76.1460037] pci4: detached [ 76.1760030] pci3: detached [ 76.2060036] pci2: detached [ 76.2360028] pci1: detached [ 76.2761541] sysbeep0: detached [ 76.3060036] midi0: detached [ 76.3458067] ichsmb0: detached [ 76.3760032] uhci3: detached [ 76.4060036] uhci2: detached [ 76.4460030] uhci1: detached [ 76.4760022] uhci0: detached [ 76.5060030] ppb3: detached [ 76.5460024] ppb2: detached [ 76.5760030] ppb1: detached [ 76.6109196] ppb0: detached [ 76.6360021] sd0(umass0:0:0:0): generic HBA error [ 77.6097832] sd0a: error writing fsbn 13207857 (sd0 bn 13207858; cn 13103 tn 0 sn 34) [ 79.5273860] sd0a: error writing fsbn 13207857 (sd0 bn 13207858; cn 13103 tn 0 sn 34) [ 80.561] sd0a: error writing fsbn 13207858 (sd0 bn 13207859; cn 13103 tn 0 sn 35) [ 81.4949480] sd0a: error writing fsbn 13207859 of 13207859-13207868 (sd0 bn 13207860; cn 13103 tn 0 sn 36) [ 82.4786168] sd0a: error writing fsbn 13207869 of 13207869-13207872 (sd0 bn 13207870; cn 13103 tn 0 sn 46) [ 343.7188423] sd0a: error writing fsbn 13207873 (sd0 bn 13207874; cn 13103 tn 0 sn 50) [ 670.1236467] sd0a: error writing fsbn 13207858 (sd0 bn 13207859; cn 13103 tn 0 sn 35) [ 996.5184079] sd0a: error writing fsbn 13207859 of 13207859-13207868 (sd0 bn 13207860; cn 13103 tn 0 sn 36) [ 1322.9532457] sd0a: error writing fsbn 13207869 of 13207869-13207872 (sd0 bn 13207870; cn 13103 tn 0 sn 46) [ 1649.3679973] sd0a: error writing fsbn 13207873 (sd0 bn 13207874; cn 13103 tn 0 sn 50) [ 2176.5780366] sd0: cache synchronization failed [ 2226.8017161] sd0: detached [ 2226.8351744] scsibus0: detached [ 2226.8726040] rebooting... -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: USB hubs/controllers detached before umass devices
On Sat, 16 Mar 2024, John D. Baker wrote: > I will try again on my live-USB drive which has -current on it. My -current live-USB drives shutdown cleanly (amd64 and i386). The only difference is that the USB devices with netbsd-10 are branded SanDisk and the ones with -current are branded PNY. Still updating/checking the netbsd-10/i386 live-USB setup. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
USB hubs/controllers detached before umass devices
I just updated my NetBSD live-USB devices to 10.0_RC6. They boot successfully, but when performing an orderly shutdown, the various uhubN and usbN devices are detached before the USB-resident filesystems are unmounted and the underlying umassN (sdN) devices are detached. This leaves the system hung trying to detach the sdN device but then getting: sd0(umass0:0:0:0) Generic HBA error sd0a unable to read fsbn (etc.) Has anyone else seen this? It did not happen when my live-USB had netbsd-9 on it. I will try again on my live-USB drive which has -current on it. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Problem with umass/scsibus/wd0
Well, the power adapter cable arrived today but it doesn't solve the problem. With 'scsictl sd0 start' and 'dkctl sd0 makewedges' it works fine, so I'm moving on to finding something to address the display problem. Thanks for all the help so far. On Wed, 13 Mar 2024, Paul Goyette wrote: On Wed, 13 Mar 2024, Michael van Elst wrote: On Tue, Mar 12, 2024 at 11:00:02PM -0700, Paul Goyette wrote: ``scsictl sd0 start'' makes a little bit of progress, and claims to be "fabricating a geometry". ``gpt show -a sd0'' shows two partitions (one for NetBSD backups, and one for Windoze backups) # gpt show sd0 startsize index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 342014 Unused 2048 4294967296 1 GPT part - NetBSD FFSv1/FFSv2 4294969344 3518951424 2 GPT part - Windows basic data 7813920768 49119 Unused 7813969887 32 Sec GPT table 7813969919 1 Sec GPT header That looks fine. But it does not seem to progress to the discover-wedges process, and no wedges seem to exist: # dkctl sd0 listwedges /dev/rsd0: no wedges configured The wedge autodetection happens when the device attaches (and failed since the disk was offline). This is different from disklabels that are fetched by the first opener (and are usually dropped with the last close, except traditionally for vnd). You can manually trigger autodetection with dkctl sd0 makewedges Yup, that's the magic word. I used scsictl and dkctl both, and the external drive appeears normal. Thanks! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+ !DSPAM:65f231e1156131740011365! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Problem with umass/scsibus/wd0
On Wed, 13 Mar 2024, Michael van Elst wrote: On Tue, Mar 12, 2024 at 11:00:02PM -0700, Paul Goyette wrote: ``scsictl sd0 start'' makes a little bit of progress, and claims to be "fabricating a geometry". ``gpt show -a sd0'' shows two partitions (one for NetBSD backups, and one for Windoze backups) # gpt show sd0 startsize index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 342014 Unused 2048 4294967296 1 GPT part - NetBSD FFSv1/FFSv2 4294969344 3518951424 2 GPT part - Windows basic data 7813920768 49119 Unused 7813969887 32 Sec GPT table 7813969919 1 Sec GPT header That looks fine. But it does not seem to progress to the discover-wedges process, and no wedges seem to exist: # dkctl sd0 listwedges /dev/rsd0: no wedges configured The wedge autodetection happens when the device attaches (and failed since the disk was offline). This is different from disklabels that are fetched by the first opener (and are usually dropped with the last close, except traditionally for vnd). You can manually trigger autodetection with dkctl sd0 makewedges Yup, that's the magic word. I used scsictl and dkctl both, and the external drive appeears normal. Thanks! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Problem with umass/scsibus/wd0
On Tue, Mar 12, 2024 at 11:00:02PM -0700, Paul Goyette wrote: > > ``scsictl sd0 start'' makes a little bit of progress, and claims > to be "fabricating a geometry". ``gpt show -a sd0'' shows two > partitions (one for NetBSD backups, and one for Windoze backups) > > # gpt show sd0 > startsize index contents > 0 1 PMBR > 1 1 Pri GPT header > 2 32 Pri GPT table > 342014 Unused > 2048 4294967296 1 GPT part - NetBSD FFSv1/FFSv2 > 4294969344 3518951424 2 GPT part - Windows basic data > 7813920768 49119 Unused > 7813969887 32 Sec GPT table > 7813969919 1 Sec GPT header That looks fine. > But it does not seem to progress to the discover-wedges process, > and no wedges seem to exist: > > # dkctl sd0 listwedges > /dev/rsd0: no wedges configured The wedge autodetection happens when the device attaches (and failed since the disk was offline). This is different from disklabels that are fetched by the first opener (and are usually dropped with the last close, except traditionally for vnd). You can manually trigger autodetection with dkctl sd0 makewedges Greetings, -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Problem with umass/scsibus/wd0
On Tue, 12 Mar 2024, Paul Goyette wrote: On Wed, 13 Mar 2024, Simon Burge wrote: Not enough USB power? Same model external drive: https://forums.tomshardware.com/threads/2tb-wd-elements-2621-is-detected-on-one-of-my-computers-but-not-the-other.3720369/#post-22432202 Certainly a possibility. But I wouldn't have a clue on how to fix it. Ah, /i read further and found the links to Amazon. The new box _should_ have enuf power since it is USB3.2. But considering the price, I ordered a cable. I'll report results next week (I don't have Amazon Prime, so shipping takes a couple additional days!) +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Problem with umass/scsibus/wd0
On Wed, 13 Mar 2024, Simon Burge wrote: Not enough USB power? Same model external drive: https://forums.tomshardware.com/threads/2tb-wd-elements-2621-is-detected-on-one-of-my-computers-but-not-the-other.3720369/#post-22432202 Certainly a possibility. But I wouldn't have a clue on how to fix it. +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Problem with umass/scsibus/wd0
On Wed, 13 Mar 2024, Michael van Elst wrote: Sounds like that drive isn't spinning up. The "Elements" product doesn't exactly tell what it is, some units either come with their own power supply or require non-standard USB power. The device is pretty standard. One thing I forgot to mention in the original report is that it used to work just fine with NetBSD on the old build. Maybe 'scsictl sd0 start' helps to get the disk online. If that has an effect you may need 'dkctl sd0 makewedges' if you use a GPT label. ``scsictl sd0 start'' makes a little bit of progress, and claims to be "fabricating a geometry". ``gpt show -a sd0'' shows two partitions (one for NetBSD backups, and one for Windoze backups) # gpt show sd0 startsize index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 342014 Unused 2048 4294967296 1 GPT part - NetBSD FFSv1/FFSv2 4294969344 3518951424 2 GPT part - Windows basic data 7813920768 49119 Unused 7813969887 32 Sec GPT table 7813969919 1 Sec GPT header But it does not seem to progress to the discover-wedges process, and no wedges seem to exist: # dkctl sd0 listwedges /dev/rsd0: no wedges configured +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Problem with umass/scsibus/wd0
Michael van Elst wrote: > p...@whooppee.com (Paul Goyette) writes: > > >[ 29641.773703] umass0 at uhub11 port 4 configuration 1 interface 0 > >[ 29641.773703] umass0: Western Digital (0x1058) Elements 2621 (0x2621), rev > >3.20/10.34, addr 4 > >[ 29641.773703] umass0: using SCSI over Bulk-Only > >[ 29641.793714] scsibus0 at umass0: 2 targets, 1 lun per target > >[ 29641.793714] sd0 at scsibus0 target 0 lun 0: > >disk fixed > >[ 29641.793714] sd0(umass0:0:0:0): Check Condition on CDB: 0x00 00 00 00 00 > >00 > >[ 29641.793714] SENSE KEY: Not Ready > >[ 29641.793714] ASC/ASCQ: Logical Unit Is In Process Of Becoming Ready > >[ 29641.793714] sd0: drive offline > > > Sounds like that drive isn't spinning up. > > The "Elements" product doesn't exactly tell what it is, some units > either come with their own power supply or require non-standard > USB power. Not enough USB power? Same model external drive: https://forums.tomshardware.com/threads/2tb-wd-elements-2621-is-detected-on-one-of-my-computers-but-not-the-other.3720369/#post-22432202 Cheers, Simon.
Re: Problem with umass/scsibus/wd0
p...@whooppee.com (Paul Goyette) writes: >[ 29641.773703] umass0 at uhub11 port 4 configuration 1 interface 0 >[ 29641.773703] umass0: Western Digital (0x1058) Elements 2621 (0x2621), rev >3.20/10.34, addr 4 >[ 29641.773703] umass0: using SCSI over Bulk-Only >[ 29641.793714] scsibus0 at umass0: 2 targets, 1 lun per target >[ 29641.793714] sd0 at scsibus0 target 0 lun 0: disk >fixed >[ 29641.793714] sd0(umass0:0:0:0): Check Condition on CDB: 0x00 00 00 00 00 00 >[ 29641.793714] SENSE KEY: Not Ready >[ 29641.793714] ASC/ASCQ: Logical Unit Is In Process Of Becoming Ready >[ 29641.793714] sd0: drive offline Sounds like that drive isn't spinning up. The "Elements" product doesn't exactly tell what it is, some units either come with their own power supply or require non-standard USB power. Maybe 'scsictl sd0 start' helps to get the disk online. If that has an effect you may need 'dkctl sd0 makewedges' if you use a GPT label.
Problem with umass/scsibus/wd0
On my new build, I finally got my monitor/display issues resolved, so today I turned to making my usual off-line backup. For several years I've used an external USB-driven hard-drive for the backups, but now when I try to attach the external drive, it never comes ready: [ 29641.773703] umass0 at uhub11 port 4 configuration 1 interface 0 [ 29641.773703] umass0: Western Digital (0x1058) Elements 2621 (0x2621), rev 3.20/10.34, addr 4 [ 29641.773703] umass0: using SCSI over Bulk-Only [ 29641.793714] scsibus0 at umass0: 2 targets, 1 lun per target [ 29641.793714] sd0 at scsibus0 target 0 lun 0: disk fixed [ 29641.793714] sd0(umass0:0:0:0): Check Condition on CDB: 0x00 00 00 00 00 00 [ 29641.793714] SENSE KEY: Not Ready [ 29641.793714] ASC/ASCQ: Logical Unit Is In Process Of Becoming Ready [ 29641.793714] sd0: drive offline ... [ 29671.778736] sd0: detached [ 29671.778736] scsibus0: detached [ 29671.778736] umass0: detached [ 29671.778736] umass0: at uhub11 port 4 (addr 4) disconnected I've waited patiently for the situation to resolve (in one case, I waited for several hours) but the drive never comes ready. And I've also tried numerous usb ports, all with the same result. The drive still works on my Windoze laptop with no issues. I cannot try any other NetBSD systems - I only have one. This is on a GENERIC 10.99.10 NetBSD built locally from sources updated ``Sun Mar 3 23:26:30 UTC 2024''. And here is the provenance of the usb port. (They're all pretty much the same, as this machine has only xhci controllers.) [ 1.039673] usb4 at xhci2: USB revision 3.1 [ 2.045963] uhub4 at usb4: NetBSD (0x) xHCI root hub (0x), class 9/0, rev 3.00/1.00, addr 0 [ 2.605967] uhub11 at uhub4 port 5: ASUS TEK. (0x174c) ASM107x (0x3074), class 9/0, rev 3.00/0.01, addr 1 Anyone got any suggestions? +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: umass
On Tue, Apr 14, 2020 at 03:18:08PM +0200, Jaromr Dole?ek wrote: > Le mar. 14 avr. 2020 à 15:11, Patrick Welche a écrit : > > > > I just plugged in my USB SD card reader to a box with a new kernel and: > > > > ugen0: Generic (0x058f) Mass Storage Device (0x6366), rev 2.00/1.00, addr 1 > > > > No SD... > > > > On NetBSD 9.99.52, it used to look like: > > > > Apr 2 20:12:19 quantz /netbsd: [ 110784.6752445] umass0: Generic (0x058f) > > Mass Storage Device (0x6366), rev 2.00/1.00, addr 1 > > Apr 2 20:12:19 quantz /netbsd: [ 110784.6752445] umass0: using SCSI over > > Bulk-Only > > Are you sure you have umass* in your kernel config, and that you re-run > config? No I'm not - I must check! (You remind me that it doesn't include usbdevices.conf) Thanks, Patrick
Re: umass
Le mar. 14 avr. 2020 à 15:11, Patrick Welche a écrit : > > I just plugged in my USB SD card reader to a box with a new kernel and: > > ugen0: Generic (0x058f) Mass Storage Device (0x6366), rev 2.00/1.00, addr 1 > > No SD... > > On NetBSD 9.99.52, it used to look like: > > Apr 2 20:12:19 quantz /netbsd: [ 110784.6752445] umass0: Generic (0x058f) > Mass Storage Device (0x6366), rev 2.00/1.00, addr 1 > Apr 2 20:12:19 quantz /netbsd: [ 110784.6752445] umass0: using SCSI over > Bulk-Only Are you sure you have umass* in your kernel config, and that you re-run config? Mine with -current: [ 2.630264] umass0 at uhub0 port 6 configuration 1 interface 0 [ 2.630264] umass0: SanDisk (0x0781) Ultra Fit (0x5583), rev 3.00/1.00, addr 1 [ 2.630264] umass0: using SCSI over Bulk-Only [ 2.630264] scsibus0 at umass0: 2 targets, 1 lun per target ... SCSI over Bulk-Only should be unaffected by the removal of ISD-ATA support. Jaromir
umass
I just plugged in my USB SD card reader to a box with a new kernel and: ugen0: Generic (0x058f) Mass Storage Device (0x6366), rev 2.00/1.00, addr 1 No SD... On NetBSD 9.99.52, it used to look like: Apr 2 20:12:19 quantz /netbsd: [ 110784.6752445] umass0: Generic (0x058f) Mass Storage Device (0x6366), rev 2.00/1.00, addr 1 Apr 2 20:12:19 quantz /netbsd: [ 110784.6752445] umass0: using SCSI over Bulk-Only Apr 2 20:12:19 quantz /netbsd: [ 110784.7252748] scsibus0 at umass0: 2 targets, 1 lun per target Apr 2 20:12:19 quantz /netbsd: [ 110784.7252748] sd0 at scsibus0 target 0 lun 0: disk removable Apr 2 20:12:20 quantz /netbsd: [ 110785.3756729] sd0: fabricating a geometry Apr 2 20:12:20 quantz /netbsd: [ 110785.3756729] sd0: 29808 MB, 29808 cyl, 64 head, 32 sec, 512 bytes/sect x 61046784 sectors Why the umass removal? What should I use instead? Cheers, Patrick
Re: USB umass hard drive "failed to create xfers" when attaching
On 2020/03/20 07:21, Nick Hudson wrote:
>
>
> On 19/03/2020 09:19, sc.dy...@gmail.com wrote:
>> On 2020/03/19 07:10, Nick Hudson wrote:
>>> On 19/03/2020 07:05, sc.dy...@gmail.com wrote:
On 2020/02/17 21:33, Nick Hudson wrote:
>>>
>>> [snip]
>>>
> xhci could do better and support multiple DMA segments, but uvm could
> also help.
To access each DMA segment in usb_dma_t *dma, should it be processed
like this?
for (i = 0; i < dma->udma_block->nsegs; i++) {
bus_dma_segment_t *ds = &dma->udma_block->map->dm_segs[i];
process_segment(ds->ds_addr, ds->ds_len);
}
>>>
>>> I started looking into this and have some changes to fix [ou]hci.
>>> xhci and dwc2 seem to be a bit harder.
>>
>> dwc2 is a Greek to me.
>
> It's quite involved as the HC is pretty dumb, but I think it's well written.
>
>
>>
>>> http://src.illumos.org/source/xref/netbsd-src/sys/dev/usb/ehci.c#3011
>>>
>>> Is how ehci currently does it.
>>
>> I've read that part of echi, but I cannot make me understood completely.
>> Does ehci always split the transfer into 4kB chunks even
>> it is physically contiguous?
>
> That function creates a list of transfer descriptors (TDs) for the xfer
> buffer/length required. Each ehci TD can handle 5 ehci pages[*] worth
> of buffer. For each page in the TD we can pass the DMA address and so
> it doesn't matter if the physical memory is contigous or not.
>
> [ou]hci are very close to being correct, but need a couple of tweaks to
> make sure i) that there are enough TDs and ii) misaligned buffers (wrt
> page boundaries) get handled properly.
>
> Nick
>
> [*] It just so happens that ehci page is 4KB like most arches.
Thank you for your detailed explanation.
How ehci works for multiple segment DMA differs from what I tries to do for
xchi.
The xhci.c has to learn it.
Re: USB umass hard drive "failed to create xfers" when attaching
On 19/03/2020 09:19, sc.dy...@gmail.com wrote:
On 2020/03/19 07:10, Nick Hudson wrote:
On 19/03/2020 07:05, sc.dy...@gmail.com wrote:
On 2020/02/17 21:33, Nick Hudson wrote:
[snip]
xhci could do better and support multiple DMA segments, but uvm could
also help.
To access each DMA segment in usb_dma_t *dma, should it be processed
like this?
for (i = 0; i < dma->udma_block->nsegs; i++) {
bus_dma_segment_t *ds = &dma->udma_block->map->dm_segs[i];
process_segment(ds->ds_addr, ds->ds_len);
}
I started looking into this and have some changes to fix [ou]hci.
xhci and dwc2 seem to be a bit harder.
dwc2 is a Greek to me.
It's quite involved as the HC is pretty dumb, but I think it's well written.
http://src.illumos.org/source/xref/netbsd-src/sys/dev/usb/ehci.c#3011
Is how ehci currently does it.
I've read that part of echi, but I cannot make me understood completely.
Does ehci always split the transfer into 4kB chunks even
it is physically contiguous?
That function creates a list of transfer descriptors (TDs) for the xfer
buffer/length required. Each ehci TD can handle 5 ehci pages[*] worth
of buffer. For each page in the TD we can pass the DMA address and so
it doesn't matter if the physical memory is contigous or not.
[ou]hci are very close to being correct, but need a couple of tweaks to
make sure i) that there are enough TDs and ii) misaligned buffers (wrt
page boundaries) get handled properly.
Nick
[*] It just so happens that ehci page is 4KB like most arches.
Re: USB umass hard drive "failed to create xfers" when attaching
On 2020/03/19 07:10, Nick Hudson wrote:
> On 19/03/2020 07:05, sc.dy...@gmail.com wrote:
>> On 2020/02/17 21:33, Nick Hudson wrote:
>
> [snip]
>
>>> xhci could do better and support multiple DMA segments, but uvm could
>>> also help.
>>
>> To access each DMA segment in usb_dma_t *dma, should it be processed
>> like this?
>>
>> for (i = 0; i < dma->udma_block->nsegs; i++) {
>> bus_dma_segment_t *ds = &dma->udma_block->map->dm_segs[i];
>>
>> process_segment(ds->ds_addr, ds->ds_len);
>> }
>
> I started looking into this and have some changes to fix [ou]hci.
> xhci and dwc2 seem to be a bit harder.
dwc2 is a Greek to me.
> http://src.illumos.org/source/xref/netbsd-src/sys/dev/usb/ehci.c#3011
>
> Is how ehci currently does it.
I've read that part of echi, but I cannot make me understood completely.
Does ehci always split the transfer into 4kB chunks even
it is physically contiguous?
>
> Nick
>
Re: USB umass hard drive "failed to create xfers" when attaching
On 19/03/2020 07:05, sc.dy...@gmail.com wrote:
> On 2020/02/17 21:33, Nick Hudson wrote:
[snip]
>> xhci could do better and support multiple DMA segments, but uvm could
>> also help.
>
> To access each DMA segment in usb_dma_t *dma, should it be processed
> like this?
>
> for (i = 0; i < dma->udma_block->nsegs; i++) {
> bus_dma_segment_t *ds = &dma->udma_block->map->dm_segs[i];
>
> process_segment(ds->ds_addr, ds->ds_len);
> }
I started looking into this and have some changes to fix [ou]hci.
xhci and dwc2 seem to be a bit harder.
http://src.illumos.org/source/xref/netbsd-src/sys/dev/usb/ehci.c#3011
Is how ehci currently does it.
Nick
Re: USB umass hard drive "failed to create xfers" when attaching
On 2020/02/17 21:33, Nick Hudson wrote:
> On 17/02/2020 16:23, Paul Goyette wrote:
> [...]
>
>>> More info...
>>>
>>> First, this is on a amd64 system, witwh 8core/16thread and 128GB of RAM.
>>>
>>> On IRC it was suggested (thanks, maya!) that the error message might be
>>> related to memory fragmentation. I didn't believe it (given how much
>>> RAM I have), but a quick check with top(1) showed that I had more than
>>> 100GB of 'file cache' active. So, I unmounted all my development trees
>>> (to force the cache to get flushed). Sure enough, I am now able to
>>> successfully mount the USB drive!
>>>
>>> So, sounds like "something somewhere isn't quite right (tm)". I would
>>> have expected a memory allocation failure to automatically trigger some
>>> mechanism to reclaim some of the file cache...
>>
>> And, based on more discussion, this would seem to be a kernel virtual
>> address fragmentation issue, and not related to physical memory being
>> available. The concensus on IRC is that this is a bug in the xhci(4)
>> driver.
>
> Yes and no.
>
> xhci could do better and support multiple DMA segments, but uvm could
> also help.
To access each DMA segment in usb_dma_t *dma, should it be processed
like this?
for (i = 0; i < dma->udma_block->nsegs; i++) {
bus_dma_segment_t *ds = &dma->udma_block->map->dm_segs[i];
process_segment(ds->ds_addr, ds->ds_len);
}
>
> Nick
Re: USB: Logical Unit Is In Process Of Becoming Ready [was Re: USB umass hard drive "failed to create xfers" when attaching]
w...@netbsd.org (Thomas Klausner) writes: >umass0: using SCSI over Bulk-Only >scsibus0 at umass0: 2 targets, 1 lun per target >sd0 at scsibus0 target 0 lun 0: disk fixed >sd0(umass0:0:0:0): Check Condition on CDB: 0x00 00 00 00 00 00 >SENSE KEY: Not Ready > ASC/ASCQ: Logical Unit Is In Process Of Becoming Ready >sd0: drive offline >autoconfiguration error: sd0: unable to open device, error = 5 That's one of the design issues with wedges. A regular disk exists even when "offline" and evaluating partitions can be deferred to the time when it is opened by some process. Wedges are only created when the device is online, which means you cannot open them to trigger anything. The only option is to poll an "offline" disk regularly to find out when to retry the wedge creation. But this alone is of questionable value because this state usually refers to removable media where partitioning can easily change. So you also need to drop wedges when you detect that the medium got ejected. This may require polling as well, at least in otherwise idle periods. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
USB: Logical Unit Is In Process Of Becoming Ready [was Re: USB umass hard drive "failed to create xfers" when attaching]
While we're talking about annoyances (sorry for hijacking the thread) I often see something like: umass0 at uhub4 port 3 configuration 1 interface 0 umass0: Samsung (0x4e8) D3 Station (0x6125), rev 3.00/2.02, addr 1 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: disk fixed sd0(umass0:0:0:0): Check Condition on CDB: 0x00 00 00 00 00 00 SENSE KEY: Not Ready ASC/ASCQ: Logical Unit Is In Process Of Becoming Ready sd0: drive offline autoconfiguration error: sd0: unable to open device, error = 5 I can usually work around this with # dkctl sd0 makewedges but it'd be nicer if it worked automatically... Thomas On Mon, Feb 17, 2020 at 07:56:02AM -0800, Paul Goyette wrote: > With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC > I get the following errors when plugging in a USB hard drive: > > umass0 at uhub1 port 2 configuration 1 interface 0 > umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr > 32 > umass0: using SCSI over Bulk-Only > umass0: autoconfiguration error: failed to create xfers > > This worked correctly with a 9.99.42 kernel built from sources dated > 2020-01-25 19:35:05 UTC > > Anyone got any clues on how this got broke? Or how to fix? > > > ++--+---+ > | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | > | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | > ++--+---+ >
Re: USB umass hard drive "failed to create xfers" when attaching
p...@whooppee.com (Paul Goyette) writes: >> other data structures in KVA space and that helps. Something that almost >> always helps is to reduce the value of the kernel variable desiredvnodes >> (you may restore it a few seconds later). >Would that be ``sysctl kern.maxvnodes'' or some other variable? Yes, but often you don't come to running sysctl so you change the variable from ddb. To be clear: reducing it doesn't prevent the problem. Reducing it temporarily frees memory, which also happens to remove some fragmentation. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: USB umass hard drive "failed to create xfers" when attaching
On Tue, 18 Feb 2020 at 09:33, Chavdar Ivanov wrote: > > On Tue, 18 Feb 2020 at 03:15, Paul Goyette wrote: > > > > On Mon, 17 Feb 2020, Michael van Elst wrote: > > > > > p...@whooppee.com (Paul Goyette) writes: > > > > > >> So, sounds like "something somewhere isn't quite right (tm)". I would > > >> have expected a memory allocation failure to automatically trigger some > > >> mechanism to reclaim some of the file cache... > > > > > > It's not the file cache. Freeing the file cache however also cleans up > > > other data structures in KVA space and that helps. Something that almost > > > always helps is to reduce the value of the kernel variable desiredvnodes > > > (you may restore it a few seconds later). > > > > Would that be ``sysctl kern.maxvnodes'' or some other variable? > > > > > > > Since free memory is not the problem, none of this is triggered > > > automatically. > > > > Got it. > > > > > > ++--+---+ > > | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > > | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | > > | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | > > ++--+---+ > > I wonder if I hadn't had a problem in the same ballpark a minute ago. > > On a 20GB laptop, after two days running pkg_rolling-replace, and > which also run zfs, I built qemu-4.2 replacing wip/qemu-4.1; the first > VM I tried was a Windows Server Next with 4GB memory, which started, > but on the rolling dots froze, freezing everything else; the machine > still responded to ping, but I was not able to log on the console or > break into the debugger with C-S-Esc, so I had to reset it. After that > the same VM started without any problem. And this got repeated again - the same VM was working fine, doing the normal Windows Updates, as one does; the host was running pkg_rolling-replace. I lost ssh connections to the host, it still responded to pings; I had left htop running on the console - which was still running, but I could not get anything on the keyboard - which was an external USB one; I suddenly remembered that this laptop has a built-in one, which still responded; I was able to get into the debugger, trace pointed to an entry in qemu-nvmm, I rebooted with 0x104 to get a dump, but it didn't get created - even if the messages file had a record of it, savecore did not find any. > > > > > -- > --
Re: USB umass hard drive "failed to create xfers" when attaching
On Tue, 18 Feb 2020 at 03:15, Paul Goyette wrote: > > On Mon, 17 Feb 2020, Michael van Elst wrote: > > > p...@whooppee.com (Paul Goyette) writes: > > > >> So, sounds like "something somewhere isn't quite right (tm)". I would > >> have expected a memory allocation failure to automatically trigger some > >> mechanism to reclaim some of the file cache... > > > > It's not the file cache. Freeing the file cache however also cleans up > > other data structures in KVA space and that helps. Something that almost > > always helps is to reduce the value of the kernel variable desiredvnodes > > (you may restore it a few seconds later). > > Would that be ``sysctl kern.maxvnodes'' or some other variable? > > > > Since free memory is not the problem, none of this is triggered > > automatically. > > Got it. > > > ++--+---+ > | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | > | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | > ++--+---+ I wonder if I hadn't had a problem in the same ballpark a minute ago. On a 20GB laptop, after two days running pkg_rolling-replace, and which also run zfs, I built qemu-4.2 replacing wip/qemu-4.1; the first VM I tried was a Windows Server Next with 4GB memory, which started, but on the rolling dots froze, freezing everything else; the machine still responded to ping, but I was not able to log on the console or break into the debugger with C-S-Esc, so I had to reset it. After that the same VM started without any problem. --
Re: USB umass hard drive "failed to create xfers" when attaching
On Mon, 17 Feb 2020, Michael van Elst wrote: p...@whooppee.com (Paul Goyette) writes: So, sounds like "something somewhere isn't quite right (tm)". I would have expected a memory allocation failure to automatically trigger some mechanism to reclaim some of the file cache... It's not the file cache. Freeing the file cache however also cleans up other data structures in KVA space and that helps. Something that almost always helps is to reduce the value of the kernel variable desiredvnodes (you may restore it a few seconds later). Would that be ``sysctl kern.maxvnodes'' or some other variable? Since free memory is not the problem, none of this is triggered automatically. Got it. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: USB umass hard drive "failed to create xfers" when attaching
mlel...@serpens.de (Michael van Elst) writes: > g...@lexort.com (Greg Troxel) writes: > >>My impression is that something, perhaps more umass than *hci, needs a >>very large chunk of memory. > > umass allocates two 64k (MAXPHYS sized) DMA buffers and a few smaller ones. > For all drivers but ehci each buffer must use contigous physical pages. > > ehci learned to use multiple DMA segments some time ago, so the > error is now rare. xhci still has to learn it, other drivers may > not be able to support it due to hardware limitations. > >>My fuzzy impression is that the standard wisdom is that drivers should >>not demand really large continuous chunks. > > 64kbyte is not really large. Thanks for the clarity, and agreed that 64 kB is nowhere near large.
Re: USB umass hard drive "failed to create xfers" when attaching
g...@lexort.com (Greg Troxel) writes: >My impression is that something, perhaps more umass than *hci, needs a >very large chunk of memory. umass allocates two 64k (MAXPHYS sized) DMA buffers and a few smaller ones. For all drivers but ehci each buffer must use contigous physical pages. ehci learned to use multiple DMA segments some time ago, so the error is now rare. xhci still has to learn it, other drivers may not be able to support it due to hardware limitations. >My fuzzy impression is that the standard wisdom is that drivers should >not demand really large continuous chunks. 64kbyte is not really large. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: USB umass hard drive "failed to create xfers" when attaching
p...@whooppee.com (Paul Goyette) writes: >available. The concensus on IRC is that this is a bug in the xhci(4) >driver. xhci could support scatter/gather transfers to multiple smaller buffers to mitigate the problem, so far only ehci(4) does this. But some hardware wouldn't support it unless you switch to PIO transfers and it doesn't fully solve the problem. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: USB umass hard drive "failed to create xfers" when attaching
p...@whooppee.com (Paul Goyette) writes: >So, sounds like "something somewhere isn't quite right (tm)". I would >have expected a memory allocation failure to automatically trigger some >mechanism to reclaim some of the file cache... It's not the file cache. Freeing the file cache however also cleans up other data structures in KVA space and that helps. Something that almost always helps is to reduce the value of the kernel variable desiredvnodes (you may restore it a few seconds later). Since free memory is not the problem, none of this is triggered automatically. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: USB umass hard drive "failed to create xfers" when attaching
On 17/02/2020 16:23, Paul Goyette wrote: [...] More info... First, this is on a amd64 system, witwh 8core/16thread and 128GB of RAM. On IRC it was suggested (thanks, maya!) that the error message might be related to memory fragmentation. I didn't believe it (given how much RAM I have), but a quick check with top(1) showed that I had more than 100GB of 'file cache' active. So, I unmounted all my development trees (to force the cache to get flushed). Sure enough, I am now able to successfully mount the USB drive! So, sounds like "something somewhere isn't quite right (tm)". I would have expected a memory allocation failure to automatically trigger some mechanism to reclaim some of the file cache... And, based on more discussion, this would seem to be a kernel virtual address fragmentation issue, and not related to physical memory being available. The concensus on IRC is that this is a bug in the xhci(4) driver. Yes and no. xhci could do better and support multiple DMA segments, but uvm could also help. Nick
Re: USB umass hard drive "failed to create xfers" when attaching
Paul Goyette writes: > First, this is on a amd64 system, witwh 8core/16thread and 128GB of RAM. > > On IRC it was suggested (thanks, maya!) that the error message might be > related to memory fragmentation. I didn't believe it (given how much > RAM I have), but a quick check with top(1) showed that I had more than > 100GB of 'file cache' active. So, I unmounted all my development trees > (to force the cache to get flushed). Sure enough, I am now able to > successfully mount the USB drive! > > So, sounds like "something somewhere isn't quite right (tm)". I would > have expected a memory allocation failure to automatically trigger some > mechanism to reclaim some of the file cache... I have seen this too, on ehci. My impression is that something, perhaps more umass than *hci, needs a very large chunk of memory. The system can end up with lots of memory available, but not one large enough. If the available memory in bytes is enough, that may not trigger reclaiming. My fuzzy impression is that the standard wisdom is that drivers should not demand really large continuous chunks.
Re: USB umass hard drive "failed to create xfers" when attaching
This is now PR kern/54997 On Mon, 17 Feb 2020, Paul Goyette wrote: With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC I get the following errors when plugging in a USB hard drive: umass0 at uhub1 port 2 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 32 umass0: using SCSI over Bulk-Only umass0: autoconfiguration error: failed to create xfers This worked correctly with a 9.99.42 kernel built from sources dated 2020-01-25 19:35:05 UTC When it was working, this is what dmesg reported: umass0 at uhub1 port 1 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 6 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: disk fixed sd0: fabricating a geometry sd0: 1863 GB, 1907727 cyl, 64 head, 32 sec, 512 bytes/sect x 3907024896 sectors sd0: fabricating a geometry Anyone got any clues on how this got broke? Or how to fix? More info... First, this is on a amd64 system, witwh 8core/16thread and 128GB of RAM. On IRC it was suggested (thanks, maya!) that the error message might be related to memory fragmentation. I didn't believe it (given how much RAM I have), but a quick check with top(1) showed that I had more than 100GB of 'file cache' active. So, I unmounted all my development trees (to force the cache to get flushed). Sure enough, I am now able to successfully mount the USB drive! So, sounds like "something somewhere isn't quite right (tm)". I would have expected a memory allocation failure to automatically trigger some mechanism to reclaim some of the file cache... And, based on more discussion, this would seem to be a kernel virtual address fragmentation issue, and not related to physical memory being available. The concensus on IRC is that this is a bug in the xhci(4) driver. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ !DSPAM:5e4abe59169311060514377! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: USB umass hard drive "failed to create xfers" when attaching
With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC I get the following errors when plugging in a USB hard drive: umass0 at uhub1 port 2 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 32 umass0: using SCSI over Bulk-Only umass0: autoconfiguration error: failed to create xfers This worked correctly with a 9.99.42 kernel built from sources dated 2020-01-25 19:35:05 UTC When it was working, this is what dmesg reported: umass0 at uhub1 port 1 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 6 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: disk fixed sd0: fabricating a geometry sd0: 1863 GB, 1907727 cyl, 64 head, 32 sec, 512 bytes/sect x 3907024896 sectors sd0: fabricating a geometry Anyone got any clues on how this got broke? Or how to fix? More info... First, this is on a amd64 system, witwh 8core/16thread and 128GB of RAM. On IRC it was suggested (thanks, maya!) that the error message might be related to memory fragmentation. I didn't believe it (given how much RAM I have), but a quick check with top(1) showed that I had more than 100GB of 'file cache' active. So, I unmounted all my development trees (to force the cache to get flushed). Sure enough, I am now able to successfully mount the USB drive! So, sounds like "something somewhere isn't quite right (tm)". I would have expected a memory allocation failure to automatically trigger some mechanism to reclaim some of the file cache... And, based on more discussion, this would seem to be a kernel virtual address fragmentation issue, and not related to physical memory being available. The concensus on IRC is that this is a bug in the xhci(4) driver. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: USB umass hard drive "failed to create xfers" when attaching
On Mon, 17 Feb 2020, Paul Goyette wrote: On Mon, 17 Feb 2020, Paul Goyette wrote: With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC I get the following errors when plugging in a USB hard drive: umass0 at uhub1 port 2 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 32 umass0: using SCSI over Bulk-Only umass0: autoconfiguration error: failed to create xfers This worked correctly with a 9.99.42 kernel built from sources dated 2020-01-25 19:35:05 UTC When it was working, this is what dmesg reported: umass0 at uhub1 port 1 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 6 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: disk fixed sd0: fabricating a geometry sd0: 1863 GB, 1907727 cyl, 64 head, 32 sec, 512 bytes/sect x 3907024896 sectors sd0: fabricating a geometry Anyone got any clues on how this got broke? Or how to fix? More info... First, this is on a amd64 system, witwh 8core/16thread and 128GB of RAM. On IRC it was suggested (thanks, maya!) that the error message might be related to memory fragmentation. I didn't believe it (given how much RAM I have), but a quick check with top(1) showed that I had more than 100GB of 'file cache' active. So, I unmounted all my development trees (to force the cache to get flushed). Sure enough, I am now able to successfully mount the USB drive! So, sounds like "something somewhere isn't quite right (tm)". I would have expected a memory allocation failure to automatically trigger some mechanism to reclaim some of the file cache... ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: USB umass hard drive "failed to create xfers" when attaching
On Mon, 17 Feb 2020, Paul Goyette wrote: With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC I get the following errors when plugging in a USB hard drive: umass0 at uhub1 port 2 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 32 umass0: using SCSI over Bulk-Only umass0: autoconfiguration error: failed to create xfers This worked correctly with a 9.99.42 kernel built from sources dated 2020-01-25 19:35:05 UTC When it was working, this is what dmesg reported: umass0 at uhub1 port 1 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 6 umass0: using SCSI over Bulk-Only scsibus0 at umass0: 2 targets, 1 lun per target sd0 at scsibus0 target 0 lun 0: disk fixed sd0: fabricating a geometry sd0: 1863 GB, 1907727 cyl, 64 head, 32 sec, 512 bytes/sect x 3907024896 sectors sd0: fabricating a geometry Anyone got any clues on how this got broke? Or how to fix? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
USB umass hard drive "failed to create xfers" when attaching
With a 9.99.46 kernel built from sources dated 2020-02-07 16:26:35 UTC I get the following errors when plugging in a USB hard drive: umass0 at uhub1 port 2 configuration 1 interface 0 umass0: Western Digital (0x1058) Ext HDD 1021 (0x1021), rev 2.00/20.02, addr 32 umass0: using SCSI over Bulk-Only umass0: autoconfiguration error: failed to create xfers This worked correctly with a 9.99.42 kernel built from sources dated 2020-01-25 19:35:05 UTC Anyone got any clues on how this got broke? Or how to fix? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
wd* at umass? owners wanted for testing
Hi, as part of work on jdolecek-ncq branch, I've made some mechanical changes to adjust the umass_isdata.c driver code to still hopefully work. I don't have the hardware though, so I'd like to have a real confirmation from somebody who does, before the branch would be merged. If you have the hardware which is attached as wd* at umass?, can you please try to boot the kernel from the branch, check if it actually works and let me know the results? Thank you. Jaromir
Re: Shutdown hangs if umass(4) media still mounted
On Fri, 30 Sep 2016, co...@sdf.org wrote: > Hi, I'm seeing a similar issue with using wireless (internal card is USB) > on a lemote yeeloong w/ 7.99.39.. With the latest revisions I've tried, I no-longer had any problems with umass(4) media (my root-on-SD-card setup). It unmounts and syncs properly and then shuts down or reboots as directed. The only time I've used the wireless under NetBSD recently was to attempt to characterize a faulty access point/dhcp server at a motel. (That was inconclusive. While my NetBSD systems could associate with the access point, DHCP requests went unanswered. In that instance, the YeeLoong with 7.99.?? behaved as well as my ThinkPad T42 with 7.0_STABLE. Meanwhile my old G4 Powerbook with OS X 10.4.11 got an IP address just fine.) Before that, I seem to recall that it worked OK when I took it places that had wireless access. I explicitly do not have any wireless facility on my local network, so I couldn't say anything about recent updates. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Shutdown hangs if umass(4) media still mounted
Hi, I'm seeing a similar issue with using wireless (internal card is USB) on a lemote yeeloong w/ 7.99.39.. After some time, it will cease to work, and dmesg will show: ehci_sync_hc: cv_timedwait() = 35 .. If I attempt to use it. It did work successfully for a few hours though. Was wireless working for more than a few hours in the past? Pointers welcome :-)
Shutdown hangs if umass(4) media still mounted
I just updated my Lemote Yeeloong to 7.99.32 (previously 7.99.27) and upon shutting down I saw the following messages: ehci_sync_hc: cv_timedwait() = 35 ehci_sync_hc: cv_timedwait() = 35 umass0: BBB reset failed, TIMEOUT ehci_sync_hc: cv_timedwait() = 35 umass0: BBB bulk-in clear stall failed, TIMEOUT ehci_sync_hc: cv_timedwait() = 35 umass0: BBB bulk-in clear stall failed, TIMEOUT ehci_sync_hc: cv_timedwait() = 35 ehci_sync_hc: cv_timedwait() = 35 umass0: BBB reset failed, TIMEOUT ehci_sync_hc: cv_timedwait() = 35 umass0: BBB bulk-in clear stall failed, TIMEOUT ehci_sync_hc: cv_timedwait() = 35 umass0: BBB bulk-in clear stall failed, TIMEOUT [pattern repeats] On this system, "/" and "/var" are on an SD card in the Yeeloong's USB-attached SD card reader. They are still mounted at this point. I had no such problem with shutdown/reboot before. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: umass problem with xhci (USB 3)
On Sat, 4 Jun 2016, Paul Goyette wrote: On Sat, 4 Jun 2016, Nick Hudson wrote: Output from a kernel with UMASS_DEBUG / XHCI_DEBUG and xhcidebug = 10 umassdebug = 0x0010 usbdebug = 1 Please Interestingly, with today's sources and the above-listed debug set, everything seems to work just fine! I guess I need to rebuild my non-debug kernel and see if it works. Well, this must have been a transient problem. A newly-built kernel works just fine, and now my original kernel works, too! At least I learned how to turn on the USB debugging stuff! +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: umass problem with xhci (USB 3)
On Sat, 4 Jun 2016, Nick Hudson wrote: Output from a kernel with UMASS_DEBUG / XHCI_DEBUG and xhcidebug = 10 umassdebug = 0x0010 usbdebug = 1 Please Interestingly, with today's sources and the above-listed debug set, everything seems to work just fine! I guess I need to rebuild my non-debug kernel and see if it works. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: umass problem with xhci (USB 3)
On 04-Jun-16 1:34 AM, Paul Goyette wrote: With a kernel built from sources dated 2016-05-29 at 23:57:35 UTC, when attaching my external hard drive (near-line backup device), I get the following messages: uhub0 at usb0: vendor 8086 xHCI Root Hub, class 9/0, rev 1.00/1.00, addr 0 ... Jun 4 08:21:37 pokey /netbsd: umass0 at uhub0 port 2 configuration 1 interface 0 Jun 4 08:21:37 pokey /netbsd: umass0: Western Digital Ext HDD 1021, rev 2.00/20.02, addr 24 Jun 4 08:21:37 pokey /netbsd: umass0: using SCSI over Bulk-Only Jun 4 08:21:37 pokey /netbsd: umass0: failed to create xfers Output from a kernel with UMASS_DEBUG / XHCI_DEBUG and xhcidebug = 10 umassdebug = 0x0010 usbdebug = 1 Please Nick
Re: umass problem with xhci (USB 3)
On Sat, 4 Jun 2016, Takahiro Hayashi wrote: but every device I plug in, regardless of USB connector, gets attached to uhub0 (the one for xHCI)! So I cannot get the external drive to work by connecting to a USB2 port. Any suggestions? To avoid the problem, please add "userconf=disable xhci*" to /boot.cfg. The xhci driver tries to route all USB ports (even 2.0) to xhci as possible if it's Intel PCH. (see sys/dev/pci/xhci_pci.c) You can see some information about port routing by booting kernel -x. This doesn't seem to be such a good idea! If I add the userconf command, then none of my USB devices works, not even the keyboard and mouse! (Please don't ask for a dmesg, I have no working keyboard to type the dmesg command!) For now, I guess I will have to disable USB3 in the BIOS settings. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
Re: umass problem with xhci (USB 3)
Hi, On 2016/06/04 09:34, Paul Goyette wrote: With a kernel built from sources dated 2016-05-29 at 23:57:35 UTC, when attaching my external hard drive (near-line backup device), I get the following messages: uhub0 at usb0: vendor 8086 xHCI Root Hub, class 9/0, rev 1.00/1.00, addr 0 ... Jun 4 08:21:37 pokey /netbsd: umass0 at uhub0 port 2 configuration 1 interface 0 Jun 4 08:21:37 pokey /netbsd: umass0: Western Digital Ext HDD 1021, rev 2.00/20.02, addr 24 Jun 4 08:21:37 pokey /netbsd: umass0: using SCSI over Bulk-Only Jun 4 08:21:37 pokey /netbsd: umass0: failed to create xfers Interestingly, even though this motherboard has both USB2 and USB3 ports, and dmesg includes uhub1 at usb1: vendor 8086 EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 ... uhub2 at uhub1 port 1: vendor 8087 product 8000, class 9/0, rev 2.00/0.05, addr2 but every device I plug in, regardless of USB connector, gets attached to uhub0 (the one for xHCI)! So I cannot get the external drive to work by connecting to a USB2 port. Any suggestions? To avoid the problem, please add "userconf=disable xhci*" to /boot.cfg. The xhci driver tries to route all USB ports (even 2.0) to xhci as possible if it's Intel PCH. (see sys/dev/pci/xhci_pci.c) You can see some information about port routing by booting kernel -x. -- t-hash
umass problem with xhci (USB 3)
With a kernel built from sources dated 2016-05-29 at 23:57:35 UTC, when attaching my external hard drive (near-line backup device), I get the following messages: uhub0 at usb0: vendor 8086 xHCI Root Hub, class 9/0, rev 1.00/1.00, addr 0 ... Jun 4 08:21:37 pokey /netbsd: umass0 at uhub0 port 2 configuration 1 interface 0 Jun 4 08:21:37 pokey /netbsd: umass0: Western Digital Ext HDD 1021, rev 2.00/20.02, addr 24 Jun 4 08:21:37 pokey /netbsd: umass0: using SCSI over Bulk-Only Jun 4 08:21:37 pokey /netbsd: umass0: failed to create xfers Interestingly, even though this motherboard has both USB2 and USB3 ports, and dmesg includes uhub1 at usb1: vendor 8086 EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 ... uhub2 at uhub1 port 1: vendor 8087 product 8000, class 9/0, rev 2.00/0.05, addr2 but every device I plug in, regardless of USB connector, gets attached to uhub0 (the one for xHCI)! So I cannot get the external drive to work by connecting to a USB2 port. Any suggestions? +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +--+--++
