In kernel 2.6.23.8 USB_PERSIST feature does not work if the same USB
device is detached and reattached while computer is suspended. The
mount points for the USB storage device mounted before suspend are
lost and the device has to be remounted after resume.
Please advise,
Thank you,
Raymano Garibaldi
On Sunday 18 November 2007 20:14, Raymano Garibaldi wrote:
> In kernel 2.6.23.8 USB_PERSIST feature does not work if the same USB
> device is detached and reattached while computer is suspended. The
> mount points for the USB storage device mounted before suspend are
> lost and the device has to be remounted after resume.
Does it work in 2.6.23.7? What messages you see in the kernel logs
(in both kernels, good and bad)?
--
vda
The last time I tried this and it worked was 2.6.21. Below is a
portion of the kernel log file where I had a USB storage device
attached to the computer, then suspended the computer, while computer
was suspended detached and reattached the USB storage device, and
resumed the computer.
--------------------------------------------------------------------------------------------------------------------------------
Nov 18 23:07:42 myfaun Stopping tasks ... done.
Nov 18 23:07:42 myfaun Suspending console(s)
Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Synchronizing SCSI cache
Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Stopping disk
Nov 18 23:07:42 myfaun ACPI handle has no context!
Nov 18 23:07:42 myfaun ACPI handle has no context!
Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1f.2 disabled
Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1f.1 disabled
Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.7 disabled
Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.3 disabled
Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.2 disabled
Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.1 disabled
Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.0 disabled
Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1b.0 disabled
Nov 18 23:07:42 myfaun Disabling non-boot CPUs ...
Nov 18 23:07:42 myfaun CPU 1 is now offline
Nov 18 23:07:42 myfaun SMP alternatives: switching to UP code
Nov 18 23:07:42 myfaun CPU1 is down
Nov 18 23:07:42 myfaun Intel machine check architecture supported.
Nov 18 23:07:42 myfaun Intel machine check reporting enabled on CPU#0.
Nov 18 23:07:42 myfaun CPU0: Intel P4/Xeon Extended MCE MSRs (24) available
Nov 18 23:07:42 myfaun CPU0: Thermal monitoring enabled
Nov 18 23:07:42 myfaun Back to C!
Nov 18 23:07:42 myfaun Enabling non-boot CPUs ...
Nov 18 23:07:42 myfaun SMP alternatives: switching to SMP code
Nov 18 23:07:42 myfaun Booting processor 1/1 eip 3000
Nov 18 23:07:42 myfaun Initializing CPU#1
Nov 18 23:07:42 myfaun Calibrating delay using timer specific
routine.. 6004.38 BogoMIPS (lpj=10003815)
Nov 18 23:07:42 myfaun CPU: After generic identify, caps: bfebfbff
20100000 00000000 00000000 0000e49d 00000000 00000001 00000000
Nov 18 23:07:42 myfaun monitor/mwait feature present.
Nov 18 23:07:42 myfaun CPU: Trace cache: 12K uops, L1 D cache: 16K
Nov 18 23:07:42 myfaun CPU: L2 cache: 2048K
Nov 18 23:07:42 myfaun CPU: Physical Processor ID: 0
Nov 18 23:07:42 myfaun CPU: Processor Core ID: 1
Nov 18 23:07:42 myfaun CPU: After all inits, caps: bfebfbff 20100000
00000000 0000b180 0000e49d 00000000 00000001 00000000
Nov 18 23:07:42 myfaun Intel machine check architecture supported.
Nov 18 23:07:42 myfaun Intel machine check reporting enabled on CPU#1.
Nov 18 23:07:42 myfaun CPU1: Intel P4/Xeon Extended MCE MSRs (24) available
Nov 18 23:07:42 myfaun CPU1: Thermal monitoring enabled
Nov 18 23:07:42 myfaun CPU1: Intel(R) Pentium(R) D CPU 3.00GHz stepping 05
Nov 18 23:07:42 myfaun CPU1 is up
Nov 18 23:07:42 myfaun ACPI: Unable to turn cooling device [dfe34dc8] 'off'
Nov 18 23:07:42 myfaun Switched to high resolution mode on CPU 1
Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16
(level, low) -> IRQ 19
Nov 18 23:07:42 myfaun PM: Writing back config space on device
0000:00:1b.0 at offset f (was 100, writing 105)
Nov 18 23:07:42 myfaun PM: Writing back config space on device
0000:00:1b.0 at offset 4 (was 4, writing fdff8004)
Nov 18 23:07:42 myfaun PM: Writing back config space on device
0000:00:1b.0 at offset 3 (was 0, writing 8)
Nov 18 23:07:42 myfaun PM: Writing back config space on device
0000:00:1b.0 at offset 1 (was 100000, writing 100002)
Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16
(level, low) -> IRQ 19
Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1b.0 to 64
Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23
(level, low) -> IRQ 18
Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.0 to 64
Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19
(level, low) -> IRQ 17
Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.1 to 64
Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18
(level, low) -> IRQ 16
Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.2 to 64
Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16
(level, low) -> IRQ 19
Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.3 to 64
Nov 18 23:07:42 myfaun PCI: Enabling device 0000:00:1d.7 (0000 -> 0002)
Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23
(level, low) -> IRQ 18
Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.7 to 64
Nov 18 23:07:42 myfaun PM: Writing back config space on device
0000:00:1d.7 at offset f (was 100, writing 107)
Nov 18 23:07:42 myfaun PM: Writing back config space on device
0000:00:1d.7 at offset 4 (was 0, writing fdfff000)
Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1e.0 to 64
Nov 18 23:07:42 myfaun PM: Writing back config space on device
0000:00:1f.1 at offset 8 (was f001, writing fa01)
Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18
(level, low) -> IRQ 16
Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1f.1 to 64
Nov 18 23:07:42 myfaun ata2: port disabled. ignoring.
Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19
(level, low) -> IRQ 17
Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1f.2 to 64
Nov 18 23:07:42 myfaun pnp: Failed to activate device 00:07.
Nov 18 23:07:42 myfaun pnp: Failed to activate device 00:08.
Nov 18 23:07:42 myfaun e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
Nov 18 23:07:42 myfaun ata4: SATA link down (SStatus 0 SControl 300)
Nov 18 23:07:42 myfaun ata6: SATA link down (SStatus 0 SControl 300)
Nov 18 23:07:42 myfaun ata5: SATA link down (SStatus 0 SControl 300)
Nov 18 23:07:42 myfaun ata1.00: configured for UDMA/33
Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Starting disk
Nov 18 23:07:42 myfaun ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Nov 18 23:07:42 myfaun ata3.00: configured for UDMA/100
Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] 488397168 512-byte hardware
sectors (250059 MB)
Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Write Protect is off
Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Write cache: enabled, read
cache: enabled, doesn't support DPO or FUA
Nov 18 23:07:42 myfaun Restarting tasks ... <6>usb 5-6: USB
disconnect, address 5
Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] READ CAPACITY failed
Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Result: hostbyte=0x01 driverbyte=0x00
Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Sense not available.
Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Write Protect is off
Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Mode Sense: 00 00 00 00
Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Assuming drive cache: write through
Nov 18 23:07:42 myfaun done.
Nov 18 23:07:42 myfaun usb 5-6: new high speed USB device using
ehci_hcd and address 6
Nov 18 23:07:42 myfaun usb 5-6: configuration #1 chosen from 1 choice
Nov 18 23:07:42 myfaun scsi10 : SCSI emulation for USB Mass Storage devices
Nov 18 23:07:42 myfaun usb-storage: device found at 6
Nov 18 23:07:42 myfaun usb-storage: waiting for device to settle before scanning
Nov 18 23:07:48 myfaun scsi 10:0:0:0: Direct-Access USB 2.0 Flash
Disk 1.00 PQ: 0 ANSI: 2
Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] 1982464 512-byte hardware
sectors (1015 MB)
Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Write Protect is off
Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Mode Sense: 03 00 00 00
Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Assuming drive cache: write through
Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] 1982464 512-byte hardware
sectors (1015 MB)
Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Write Protect is off
Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Mode Sense: 03 00 00 00
Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Assuming drive cache: write through
Nov 18 23:07:48 myfaun sdg: sdg1 sdg2
Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Attached SCSI removable disk
Nov 18 23:07:48 myfaun sd 10:0:0:0: Attached scsi generic sg6 type 0
Nov 18 23:07:48 myfaun usb-storage: device scan complete
--------------------------------------------------------------------------------------------------------------------------------
Thanks,
Raymano G.
On 11/18/07, Denys Vlasenko <[email protected]> wrote:
> On Sunday 18 November 2007 20:14, Raymano Garibaldi wrote:
> > In kernel 2.6.23.8 USB_PERSIST feature does not work if the same USB
> > device is detached and reattached while computer is suspended. The
> > mount points for the USB storage device mounted before suspend are
> > lost and the device has to be remounted after resume.
>
> Does it work in 2.6.23.7? What messages you see in the kernel logs
> (in both kernels, good and bad)?
> --
> vda
>
Is there any other information that I can provide which might help in
resolving this bug?
On 11/18/07, Raymano Garibaldi <[email protected]> wrote:
> The last time I tried this and it worked was 2.6.21. Below is a
> portion of the kernel log file where I had a USB storage device
> attached to the computer, then suspended the computer, while computer
> was suspended detached and reattached the USB storage device, and
> resumed the computer.
>
> --------------------------------------------------------------------------------------------------------------------------------
> Nov 18 23:07:42 myfaun Stopping tasks ... done.
> Nov 18 23:07:42 myfaun Suspending console(s)
> Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Synchronizing SCSI cache
> Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Stopping disk
> Nov 18 23:07:42 myfaun ACPI handle has no context!
> Nov 18 23:07:42 myfaun ACPI handle has no context!
> Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1f.2 disabled
> Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1f.1 disabled
> Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.7 disabled
> Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.3 disabled
> Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.2 disabled
> Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.1 disabled
> Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.0 disabled
> Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1b.0 disabled
> Nov 18 23:07:42 myfaun Disabling non-boot CPUs ...
> Nov 18 23:07:42 myfaun CPU 1 is now offline
> Nov 18 23:07:42 myfaun SMP alternatives: switching to UP code
> Nov 18 23:07:42 myfaun CPU1 is down
> Nov 18 23:07:42 myfaun Intel machine check architecture supported.
> Nov 18 23:07:42 myfaun Intel machine check reporting enabled on CPU#0.
> Nov 18 23:07:42 myfaun CPU0: Intel P4/Xeon Extended MCE MSRs (24) available
> Nov 18 23:07:42 myfaun CPU0: Thermal monitoring enabled
> Nov 18 23:07:42 myfaun Back to C!
> Nov 18 23:07:42 myfaun Enabling non-boot CPUs ...
> Nov 18 23:07:42 myfaun SMP alternatives: switching to SMP code
> Nov 18 23:07:42 myfaun Booting processor 1/1 eip 3000
> Nov 18 23:07:42 myfaun Initializing CPU#1
> Nov 18 23:07:42 myfaun Calibrating delay using timer specific
> routine.. 6004.38 BogoMIPS (lpj=10003815)
> Nov 18 23:07:42 myfaun CPU: After generic identify, caps: bfebfbff
> 20100000 00000000 00000000 0000e49d 00000000 00000001 00000000
> Nov 18 23:07:42 myfaun monitor/mwait feature present.
> Nov 18 23:07:42 myfaun CPU: Trace cache: 12K uops, L1 D cache: 16K
> Nov 18 23:07:42 myfaun CPU: L2 cache: 2048K
> Nov 18 23:07:42 myfaun CPU: Physical Processor ID: 0
> Nov 18 23:07:42 myfaun CPU: Processor Core ID: 1
> Nov 18 23:07:42 myfaun CPU: After all inits, caps: bfebfbff 20100000
> 00000000 0000b180 0000e49d 00000000 00000001 00000000
> Nov 18 23:07:42 myfaun Intel machine check architecture supported.
> Nov 18 23:07:42 myfaun Intel machine check reporting enabled on CPU#1.
> Nov 18 23:07:42 myfaun CPU1: Intel P4/Xeon Extended MCE MSRs (24) available
> Nov 18 23:07:42 myfaun CPU1: Thermal monitoring enabled
> Nov 18 23:07:42 myfaun CPU1: Intel(R) Pentium(R) D CPU 3.00GHz stepping 05
> Nov 18 23:07:42 myfaun CPU1 is up
> Nov 18 23:07:42 myfaun ACPI: Unable to turn cooling device [dfe34dc8] 'off'
> Nov 18 23:07:42 myfaun Switched to high resolution mode on CPU 1
> Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16
> (level, low) -> IRQ 19
> Nov 18 23:07:42 myfaun PM: Writing back config space on device
> 0000:00:1b.0 at offset f (was 100, writing 105)
> Nov 18 23:07:42 myfaun PM: Writing back config space on device
> 0000:00:1b.0 at offset 4 (was 4, writing fdff8004)
> Nov 18 23:07:42 myfaun PM: Writing back config space on device
> 0000:00:1b.0 at offset 3 (was 0, writing 8)
> Nov 18 23:07:42 myfaun PM: Writing back config space on device
> 0000:00:1b.0 at offset 1 (was 100000, writing 100002)
> Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16
> (level, low) -> IRQ 19
> Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1b.0 to 64
> Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23
> (level, low) -> IRQ 18
> Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.0 to 64
> Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19
> (level, low) -> IRQ 17
> Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.1 to 64
> Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18
> (level, low) -> IRQ 16
> Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.2 to 64
> Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16
> (level, low) -> IRQ 19
> Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.3 to 64
> Nov 18 23:07:42 myfaun PCI: Enabling device 0000:00:1d.7 (0000 -> 0002)
> Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23
> (level, low) -> IRQ 18
> Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.7 to 64
> Nov 18 23:07:42 myfaun PM: Writing back config space on device
> 0000:00:1d.7 at offset f (was 100, writing 107)
> Nov 18 23:07:42 myfaun PM: Writing back config space on device
> 0000:00:1d.7 at offset 4 (was 0, writing fdfff000)
> Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1e.0 to 64
> Nov 18 23:07:42 myfaun PM: Writing back config space on device
> 0000:00:1f.1 at offset 8 (was f001, writing fa01)
> Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18
> (level, low) -> IRQ 16
> Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1f.1 to 64
> Nov 18 23:07:42 myfaun ata2: port disabled. ignoring.
> Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19
> (level, low) -> IRQ 17
> Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1f.2 to 64
> Nov 18 23:07:42 myfaun pnp: Failed to activate device 00:07.
> Nov 18 23:07:42 myfaun pnp: Failed to activate device 00:08.
> Nov 18 23:07:42 myfaun e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
> Nov 18 23:07:42 myfaun ata4: SATA link down (SStatus 0 SControl 300)
> Nov 18 23:07:42 myfaun ata6: SATA link down (SStatus 0 SControl 300)
> Nov 18 23:07:42 myfaun ata5: SATA link down (SStatus 0 SControl 300)
> Nov 18 23:07:42 myfaun ata1.00: configured for UDMA/33
> Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Starting disk
> Nov 18 23:07:42 myfaun ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> Nov 18 23:07:42 myfaun ata3.00: configured for UDMA/100
> Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] 488397168 512-byte hardware
> sectors (250059 MB)
> Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Write Protect is off
> Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
> Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Write cache: enabled, read
> cache: enabled, doesn't support DPO or FUA
> Nov 18 23:07:42 myfaun Restarting tasks ... <6>usb 5-6: USB
> disconnect, address 5
> Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] READ CAPACITY failed
> Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Result: hostbyte=0x01 driverbyte=0x00
> Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Sense not available.
> Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Write Protect is off
> Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Mode Sense: 00 00 00 00
> Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Assuming drive cache: write through
> Nov 18 23:07:42 myfaun done.
> Nov 18 23:07:42 myfaun usb 5-6: new high speed USB device using
> ehci_hcd and address 6
> Nov 18 23:07:42 myfaun usb 5-6: configuration #1 chosen from 1 choice
> Nov 18 23:07:42 myfaun scsi10 : SCSI emulation for USB Mass Storage devices
> Nov 18 23:07:42 myfaun usb-storage: device found at 6
> Nov 18 23:07:42 myfaun usb-storage: waiting for device to settle before scanning
> Nov 18 23:07:48 myfaun scsi 10:0:0:0: Direct-Access USB 2.0 Flash
> Disk 1.00 PQ: 0 ANSI: 2
> Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] 1982464 512-byte hardware
> sectors (1015 MB)
> Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Write Protect is off
> Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Mode Sense: 03 00 00 00
> Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Assuming drive cache: write through
> Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] 1982464 512-byte hardware
> sectors (1015 MB)
> Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Write Protect is off
> Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Mode Sense: 03 00 00 00
> Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Assuming drive cache: write through
> Nov 18 23:07:48 myfaun sdg: sdg1 sdg2
> Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Attached SCSI removable disk
> Nov 18 23:07:48 myfaun sd 10:0:0:0: Attached scsi generic sg6 type 0
> Nov 18 23:07:48 myfaun usb-storage: device scan complete
>
> --------------------------------------------------------------------------------------------------------------------------------
>
> Thanks,
> Raymano G.
>
> On 11/18/07, Denys Vlasenko <[email protected]> wrote:
> > On Sunday 18 November 2007 20:14, Raymano Garibaldi wrote:
> > > In kernel 2.6.23.8 USB_PERSIST feature does not work if the same USB
> > > device is detached and reattached while computer is suspended. The
> > > mount points for the USB storage device mounted before suspend are
> > > lost and the device has to be remounted after resume.
> >
> > Does it work in 2.6.23.7? What messages you see in the kernel logs
> > (in both kernels, good and bad)?
> > --
> > vda
> >
>
On Tue, 20 Nov 2007 17:04:32 -0700 "Raymano Garibaldi" <[email protected]> wrote:
> Is there any other information that I can provide which might help in
> resolving this bug?
Let's cc the USB developers.
> On 11/18/07, Raymano Garibaldi <[email protected]> wrote:
> > The last time I tried this and it worked was 2.6.21. Below is a
> > portion of the kernel log file where I had a USB storage device
> > attached to the computer, then suspended the computer, while computer
> > was suspended detached and reattached the USB storage device, and
> > resumed the computer.
> >
> > --------------------------------------------------------------------------------------------------------------------------------
> > Nov 18 23:07:42 myfaun Stopping tasks ... done.
> > Nov 18 23:07:42 myfaun Suspending console(s)
> > Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Synchronizing SCSI cache
> > Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Stopping disk
> > Nov 18 23:07:42 myfaun ACPI handle has no context!
> > Nov 18 23:07:42 myfaun ACPI handle has no context!
> > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1f.2 disabled
> > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1f.1 disabled
> > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.7 disabled
> > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.3 disabled
> > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.2 disabled
> > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.1 disabled
> > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1d.0 disabled
> > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device 0000:00:1b.0 disabled
> > Nov 18 23:07:42 myfaun Disabling non-boot CPUs ...
> > Nov 18 23:07:42 myfaun CPU 1 is now offline
> > Nov 18 23:07:42 myfaun SMP alternatives: switching to UP code
> > Nov 18 23:07:42 myfaun CPU1 is down
> > Nov 18 23:07:42 myfaun Intel machine check architecture supported.
> > Nov 18 23:07:42 myfaun Intel machine check reporting enabled on CPU#0.
> > Nov 18 23:07:42 myfaun CPU0: Intel P4/Xeon Extended MCE MSRs (24) available
> > Nov 18 23:07:42 myfaun CPU0: Thermal monitoring enabled
> > Nov 18 23:07:42 myfaun Back to C!
> > Nov 18 23:07:42 myfaun Enabling non-boot CPUs ...
> > Nov 18 23:07:42 myfaun SMP alternatives: switching to SMP code
> > Nov 18 23:07:42 myfaun Booting processor 1/1 eip 3000
> > Nov 18 23:07:42 myfaun Initializing CPU#1
> > Nov 18 23:07:42 myfaun Calibrating delay using timer specific
> > routine.. 6004.38 BogoMIPS (lpj=10003815)
> > Nov 18 23:07:42 myfaun CPU: After generic identify, caps: bfebfbff
> > 20100000 00000000 00000000 0000e49d 00000000 00000001 00000000
> > Nov 18 23:07:42 myfaun monitor/mwait feature present.
> > Nov 18 23:07:42 myfaun CPU: Trace cache: 12K uops, L1 D cache: 16K
> > Nov 18 23:07:42 myfaun CPU: L2 cache: 2048K
> > Nov 18 23:07:42 myfaun CPU: Physical Processor ID: 0
> > Nov 18 23:07:42 myfaun CPU: Processor Core ID: 1
> > Nov 18 23:07:42 myfaun CPU: After all inits, caps: bfebfbff 20100000
> > 00000000 0000b180 0000e49d 00000000 00000001 00000000
> > Nov 18 23:07:42 myfaun Intel machine check architecture supported.
> > Nov 18 23:07:42 myfaun Intel machine check reporting enabled on CPU#1.
> > Nov 18 23:07:42 myfaun CPU1: Intel P4/Xeon Extended MCE MSRs (24) available
> > Nov 18 23:07:42 myfaun CPU1: Thermal monitoring enabled
> > Nov 18 23:07:42 myfaun CPU1: Intel(R) Pentium(R) D CPU 3.00GHz stepping 05
> > Nov 18 23:07:42 myfaun CPU1 is up
> > Nov 18 23:07:42 myfaun ACPI: Unable to turn cooling device [dfe34dc8] 'off'
> > Nov 18 23:07:42 myfaun Switched to high resolution mode on CPU 1
> > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16
> > (level, low) -> IRQ 19
> > Nov 18 23:07:42 myfaun PM: Writing back config space on device
> > 0000:00:1b.0 at offset f (was 100, writing 105)
> > Nov 18 23:07:42 myfaun PM: Writing back config space on device
> > 0000:00:1b.0 at offset 4 (was 4, writing fdff8004)
> > Nov 18 23:07:42 myfaun PM: Writing back config space on device
> > 0000:00:1b.0 at offset 3 (was 0, writing 8)
> > Nov 18 23:07:42 myfaun PM: Writing back config space on device
> > 0000:00:1b.0 at offset 1 (was 100000, writing 100002)
> > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16
> > (level, low) -> IRQ 19
> > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1b.0 to 64
> > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23
> > (level, low) -> IRQ 18
> > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.0 to 64
> > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19
> > (level, low) -> IRQ 17
> > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.1 to 64
> > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18
> > (level, low) -> IRQ 16
> > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.2 to 64
> > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16
> > (level, low) -> IRQ 19
> > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.3 to 64
> > Nov 18 23:07:42 myfaun PCI: Enabling device 0000:00:1d.7 (0000 -> 0002)
> > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23
> > (level, low) -> IRQ 18
> > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1d.7 to 64
> > Nov 18 23:07:42 myfaun PM: Writing back config space on device
> > 0000:00:1d.7 at offset f (was 100, writing 107)
> > Nov 18 23:07:42 myfaun PM: Writing back config space on device
> > 0000:00:1d.7 at offset 4 (was 0, writing fdfff000)
> > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1e.0 to 64
> > Nov 18 23:07:42 myfaun PM: Writing back config space on device
> > 0000:00:1f.1 at offset 8 (was f001, writing fa01)
> > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18
> > (level, low) -> IRQ 16
> > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1f.1 to 64
> > Nov 18 23:07:42 myfaun ata2: port disabled. ignoring.
> > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19
> > (level, low) -> IRQ 17
> > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device 0000:00:1f.2 to 64
> > Nov 18 23:07:42 myfaun pnp: Failed to activate device 00:07.
> > Nov 18 23:07:42 myfaun pnp: Failed to activate device 00:08.
> > Nov 18 23:07:42 myfaun e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
> > Nov 18 23:07:42 myfaun ata4: SATA link down (SStatus 0 SControl 300)
> > Nov 18 23:07:42 myfaun ata6: SATA link down (SStatus 0 SControl 300)
> > Nov 18 23:07:42 myfaun ata5: SATA link down (SStatus 0 SControl 300)
> > Nov 18 23:07:42 myfaun ata1.00: configured for UDMA/33
> > Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Starting disk
> > Nov 18 23:07:42 myfaun ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> > Nov 18 23:07:42 myfaun ata3.00: configured for UDMA/100
> > Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] 488397168 512-byte hardware
> > sectors (250059 MB)
> > Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Write Protect is off
> > Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
> > Nov 18 23:07:42 myfaun sd 2:0:0:0: [sda] Write cache: enabled, read
> > cache: enabled, doesn't support DPO or FUA
> > Nov 18 23:07:42 myfaun Restarting tasks ... <6>usb 5-6: USB
> > disconnect, address 5
> > Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] READ CAPACITY failed
> > Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Result: hostbyte=0x01 driverbyte=0x00
> > Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Sense not available.
> > Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Write Protect is off
> > Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Mode Sense: 00 00 00 00
> > Nov 18 23:07:42 myfaun sd 9:0:0:0: [sdf] Assuming drive cache: write through
> > Nov 18 23:07:42 myfaun done.
> > Nov 18 23:07:42 myfaun usb 5-6: new high speed USB device using
> > ehci_hcd and address 6
> > Nov 18 23:07:42 myfaun usb 5-6: configuration #1 chosen from 1 choice
> > Nov 18 23:07:42 myfaun scsi10 : SCSI emulation for USB Mass Storage devices
> > Nov 18 23:07:42 myfaun usb-storage: device found at 6
> > Nov 18 23:07:42 myfaun usb-storage: waiting for device to settle before scanning
> > Nov 18 23:07:48 myfaun scsi 10:0:0:0: Direct-Access USB 2.0 Flash
> > Disk 1.00 PQ: 0 ANSI: 2
> > Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] 1982464 512-byte hardware
> > sectors (1015 MB)
> > Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Write Protect is off
> > Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Mode Sense: 03 00 00 00
> > Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Assuming drive cache: write through
> > Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] 1982464 512-byte hardware
> > sectors (1015 MB)
> > Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Write Protect is off
> > Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Mode Sense: 03 00 00 00
> > Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Assuming drive cache: write through
> > Nov 18 23:07:48 myfaun sdg: sdg1 sdg2
> > Nov 18 23:07:48 myfaun sd 10:0:0:0: [sdg] Attached SCSI removable disk
> > Nov 18 23:07:48 myfaun sd 10:0:0:0: Attached scsi generic sg6 type 0
> > Nov 18 23:07:48 myfaun usb-storage: device scan complete
> >
> > --------------------------------------------------------------------------------------------------------------------------------
> >
> > Thanks,
> > Raymano G.
> >
> > On 11/18/07, Denys Vlasenko <[email protected]> wrote:
> > > On Sunday 18 November 2007 20:14, Raymano Garibaldi wrote:
> > > > In kernel 2.6.23.8 USB_PERSIST feature does not work if the same USB
> > > > device is detached and reattached while computer is suspended. The
> > > > mount points for the USB storage device mounted before suspend are
> > > > lost and the device has to be remounted after resume.
> > >
> > > Does it work in 2.6.23.7? What messages you see in the kernel logs
> > > (in both kernels, good and bad)?
> > > --
> > > vda
> > >
> >
The report is a bit of a mess due to top-posting, but I guess people can work
it out.
If this doesn't get fixed within a few days please be sure to raise a
report against USB at bugzilla.kernel.org and check the "regression" box,
thanks.
On Sat, 24 Nov 2007, Andrew Morton wrote:
> On Tue, 20 Nov 2007 17:04:32 -0700 "Raymano Garibaldi" <[email protected]> wrote:
>
> > Is there any other information that I can provide which might help in
> > resolving this bug?
>
> Let's cc the USB developers.
>
> > On 11/18/07, Raymano Garibaldi <[email protected]> wrote:
> > > The last time I tried this and it worked was 2.6.21. Below is a
Sorry, that's not possible. 2.6.21 doesn't include USB Persist
support. Nor does 2.6.22.
There were some experimental patches with early versions of USB Persist
for those kernels. They are different from what eventually went into
2.6.23.
> > > On 11/18/07, Denys Vlasenko <[email protected]> wrote:
> > > > On Sunday 18 November 2007 20:14, Raymano Garibaldi wrote:
> > > > > In kernel 2.6.23.8 USB_PERSIST feature does not work if the same USB
> > > > > device is detached and reattached while computer is suspended. The
> > > > > mount points for the USB storage device mounted before suspend are
> > > > > lost and the device has to be remounted after resume.
USB Persist was never meant to allow you to detach and reattach a
device while the computer is suspended; it was meant to deal with
hibernation. So what you observed is the correct behavior, not a bug.
Detaching and reattaching a device while the computer is suspended
should result in exactly the same behavior as detaching and reattaching
the device while the computer is awake.
If you try doing the same thing but with the computer in hibernation
instead of suspended, you may find it more in line with what you
expect.
Alan Stern
The device which has the root fs is a READ-ONLY device. There is no
way for it to change between getting detached and reattached to the
computer which is suspended. In such a case there is no possibility of
hibernation because there is nothing to write back to.
I understand that this is currently considered a feature but I am
arguing here that there should also be another feature that allows
this to work under suspend to ram the same as it does with suspend to
disk (hibernation).
Here's a scenario:
1) You are at the airport working on a laptop without a hard drive,
which you have booted up using a live USB distro on a read-only USB
key drive.
2) You want to board your plane so you suspend your laptop. You can't
keep the USB stick in your laptop because you can not fit the laptop
back in the bag with the USB stick still attached. So you detach the
USB stick while the laptop is still suspended.
3) You get on the plane and after some time when you are allowed to
work again you stick back in the USB stick, resume the laptop and
continue work where you left off.
This scenario is not currently possible with the any kernel after
2.6.22. It is a very important missing feature.
And yes. This feature does work under the 2.6.21 kernel, exactly
because the kernel did not have the USB suspend and persist feature
available. Under the 2.6.21 kernel, during suspend, the kernel is
totally unaware of what is happening to the USB device so nothing
happens when the USB device is detached and reattached while the
computer is suspended, hence making the described scenario above
possible. I currently, and very frequently, use this feature on my
live USB distro, FaunOS which uses kernel 2.6.21.
Thank you,
Raymano G.
On 11/25/07, Alan Stern <[email protected]> wrote:
> On Sat, 24 Nov 2007, Andrew Morton wrote:
>
> > On Tue, 20 Nov 2007 17:04:32 -0700 "Raymano Garibaldi" <[email protected]> wrote:
> >
> > > Is there any other information that I can provide which might help in
> > > resolving this bug?
> >
> > Let's cc the USB developers.
> >
> > > On 11/18/07, Raymano Garibaldi <[email protected]> wrote:
> > > > The last time I tried this and it worked was 2.6.21. Below is a
>
> Sorry, that's not possible. 2.6.21 doesn't include USB Persist
> support. Nor does 2.6.22.
>
> There were some experimental patches with early versions of USB Persist
> for those kernels. They are different from what eventually went into
> 2.6.23.
>
> > > > On 11/18/07, Denys Vlasenko <[email protected]> wrote:
> > > > > On Sunday 18 November 2007 20:14, Raymano Garibaldi wrote:
> > > > > > In kernel 2.6.23.8 USB_PERSIST feature does not work if the same USB
> > > > > > device is detached and reattached while computer is suspended. The
> > > > > > mount points for the USB storage device mounted before suspend are
> > > > > > lost and the device has to be remounted after resume.
>
> USB Persist was never meant to allow you to detach and reattach a
> device while the computer is suspended; it was meant to deal with
> hibernation. So what you observed is the correct behavior, not a bug.
> Detaching and reattaching a device while the computer is suspended
> should result in exactly the same behavior as detaching and reattaching
> the device while the computer is awake.
>
> If you try doing the same thing but with the computer in hibernation
> instead of suspended, you may find it more in line with what you
> expect.
>
> Alan Stern
>
>
On Sun, 25 Nov 2007, Raymano Garibaldi wrote:
> The device which has the root fs is a READ-ONLY device. There is no
> way for it to change between getting detached and reattached to the
> computer which is suspended.
You might think so at first. But suppose another device of the same
type got plugged in instead -- with different data stored on it. That
would be just as bad.
> I understand that this is currently considered a feature but I am
> arguing here that there should also be another feature that allows
> this to work under suspend to ram the same as it does with suspend to
> disk (hibernation).
...
> This scenario is not currently possible with the any kernel after
> 2.6.22. It is a very important missing feature.
This has nothing to do with USB particularly; it applies to all forms
of hot-pluggable or removable storage. Even floppy disks.
> And yes. This feature does work under the 2.6.21 kernel, exactly
> because the kernel did not have the USB suspend and persist feature
> available.
Wait a minute. You're saying that USB Persist worked under 2.6.21
because it wasn't available? That makes no sense. Besides, if you
don't like USB Persist under 2.6.23, you can always eliminate it by
turning off CONFIG_USB_PERSIST.
> Under the 2.6.21 kernel, during suspend, the kernel is
> totally unaware of what is happening to the USB device so nothing
> happens when the USB device is detached and reattached while the
> computer is suspended, hence making the described scenario above
> possible. I currently, and very frequently, use this feature on my
> live USB distro, FaunOS which uses kernel 2.6.21.
It may be the case that _your_ particular computer wasn't aware of
unplug or replug events during suspend, but if so then it was a bug and
it isn't true in general. The fact that your computer is now aware of
these things proves this.
In short, you aren't reporting a bug -- you're asking for a new feature
to be added.
>From the point of view of the kernel, being suspended is in some
respects like remaining awake. Hotplug events are detected in either
case. Would you also want the ability to unplug and replug your root
fs while the computer was running? Would it make sense to add such an
ability?
There was a time during the 2.4 kernel series when usb-storage would
try to keep track of devices after they had been unplugged and
recognize them when they were re-attached. Linus himself said it was
a bad idea and consequently it was removed. Now you're saying you want
it back. I think you'll have to convince Linus before anyone else will
pay attention. It's worth a try -- he might think your airport
scenario is common enough to be worth supporting.
Alan Stern
Thanks for responding Alan.
On 11/26/07, Alan Stern <[email protected]> wrote:
> On Sun, 25 Nov 2007, Raymano Garibaldi wrote:
>
> > The device which has the root fs is a READ-ONLY device. There is no
> > way for it to change between getting detached and reattached to the
> > computer which is suspended.
>
> You might think so at first. But suppose another device of the same
> type got plugged in instead -- with different data stored on it. That
> would be just as bad.
>
This is possible. However I believe giving an option to the user to
allow this behavior is important. It's about choice.
> > I understand that this is currently considered a feature but I am
> > arguing here that there should also be another feature that allows
> > this to work under suspend to ram the same as it does with suspend to
> > disk (hibernation).
> ...
> > This scenario is not currently possible with the any kernel after
> > 2.6.22. It is a very important missing feature.
>
> This has nothing to do with USB particularly; it applies to all forms
> of hot-pluggable or removable storage. Even floppy disks.
>
True.
> > And yes. This feature does work under the 2.6.21 kernel, exactly
> > because the kernel did not have the USB suspend and persist feature
> > available.
>
> Wait a minute. You're saying that USB Persist worked under 2.6.21
> because it wasn't available? That makes no sense. Besides, if you
> don't like USB Persist under 2.6.23, you can always eliminate it by
> turning off CONFIG_USB_PERSIST.
>
I have tried this. Simply turning off CONFIG_USB_PERSIST doesn't work.
In this case the USB drive file system is unmounted on resume, even if
the drive remained plugged in during suspend.
> > Under the 2.6.21 kernel, during suspend, the kernel is
> > totally unaware of what is happening to the USB device so nothing
> > happens when the USB device is detached and reattached while the
> > computer is suspended, hence making the described scenario above
> > possible. I currently, and very frequently, use this feature on my
> > live USB distro, FaunOS which uses kernel 2.6.21.
>
> It may be the case that _your_ particular computer wasn't aware of
> unplug or replug events during suspend, but if so then it was a bug and
> it isn't true in general. The fact that your computer is now aware of
> these things proves this.
>
I have tried this on many different computers. Also our distro users
have successfully tried this throughout the world. Whether it was a
bug or not, the desired behavior existed in kernel 2.6.21.
> In short, you aren't reporting a bug -- you're asking for a new feature
> to be added.
>
> From the point of view of the kernel, being suspended is in some
> respects like remaining awake. Hotplug events are detected in either
> case. Would you also want the ability to unplug and replug your root
> fs while the computer was running? Would it make sense to add such an
> ability?
>
Yes. I believe because of the advances in solid state drive
technology, especially detachable ones like USB flash drives, the
ability to unplug and replug a live root fs is becoming an important
feature.
> There was a time during the 2.4 kernel series when usb-storage would
> try to keep track of devices after they had been unplugged and
> recognize them when they were re-attached. Linus himself said it was
> a bad idea and consequently it was removed. Now you're saying you want
> it back. I think you'll have to convince Linus before anyone else will
> pay attention. It's worth a try -- he might think your airport
> scenario is common enough to be worth supporting.
>
> Alan Stern
>
>
Thanks again Alan. I will post a feature request.
Raymano G.
On Mon, 26 Nov 2007, Raymano Garibaldi wrote:
> > Wait a minute. You're saying that USB Persist worked under 2.6.21
> > because it wasn't available? That makes no sense. Besides, if you
> > don't like USB Persist under 2.6.23, you can always eliminate it by
> > turning off CONFIG_USB_PERSIST.
> >
>
> I have tried this. Simply turning off CONFIG_USB_PERSIST doesn't work.
> In this case the USB drive file system is unmounted on resume, even if
> the drive remained plugged in during suspend.
Something about this doesn't sound right.
When you have CONFIG_USB_PERSIST enabled, do you remember to turn on
the Persist feature for the root fs device by writing a "1" to the
device's power/persist file in sysfs?
Can you try building a kernel with CONFIG_USB_PERSIST and
CONFIG_USB_DEBUG both enabled, and post the dmesg log from immediately
after resuming?
Alan Stern
Hi Alan,
Here's what I got after compiling kernel with CONFIG_USB_PERSIST and
CONFIG_USB_DEBUG both enabled. The attached files are:
config - shows the .config file used when compiling kernel 2.6.23.9
sysandmount.txt - shows mounts and the state of persist for all usb
devices right before suspending.
dmesg_attached.txt - dmesg right after resuming when the USB device
remained attached while machine was suspend
dmesg_detachedandreattached.txt - dmesg right after resuming when the
USB device was detached while suspended and then reattached before
resuming.
Thanks,
Raymano G.
On 11/26/07, Alan Stern <[email protected]> wrote:
> On Mon, 26 Nov 2007, Raymano Garibaldi wrote:
>
> > > Wait a minute. You're saying that USB Persist worked under 2.6.21
> > > because it wasn't available? That makes no sense. Besides, if you
> > > don't like USB Persist under 2.6.23, you can always eliminate it by
> > > turning off CONFIG_USB_PERSIST.
> > >
> >
> > I have tried this. Simply turning off CONFIG_USB_PERSIST doesn't work.
> > In this case the USB drive file system is unmounted on resume, even if
> > the drive remained plugged in during suspend.
>
> Something about this doesn't sound right.
>
> When you have CONFIG_USB_PERSIST enabled, do you remember to turn on
> the Persist feature for the root fs device by writing a "1" to the
> device's power/persist file in sysfs?
>
> Can you try building a kernel with CONFIG_USB_PERSIST and
> CONFIG_USB_DEBUG both enabled, and post the dmesg log from immediately
> after resuming?
>
> Alan Stern
>
>
On Tue, 27 Nov 2007, Raymano Garibaldi wrote:
> Hi Alan,
>
> Here's what I got after compiling kernel with CONFIG_USB_PERSIST and
> CONFIG_USB_DEBUG both enabled. The attached files are:
>
> config - shows the .config file used when compiling kernel 2.6.23.9
>
> sysandmount.txt - shows mounts and the state of persist for all usb
> devices right before suspending.
>
> dmesg_attached.txt - dmesg right after resuming when the USB device
> remained attached while machine was suspend
>
> dmesg_detachedandreattached.txt - dmesg right after resuming when the
> USB device was detached while suspended and then reattached before
> resuming.
This all looks okay. Earlier you wrote:
> I have tried this. Simply turning off CONFIG_USB_PERSIST doesn't work.
> In this case the USB drive file system is unmounted on resume, even if
> the drive remained plugged in during suspend.
But the logs you just posted show that the filesystem _does_ remain
mounted after resume, provided you don't unplug the drive. At least
that's what it looked like -- it was hard to tell for sure because each
logfile contained multiple suspend/resume cycles with varying outcomes.
Alan Stern
The feature does work as long as the device remains plugged in and
that is what I have said in my previous postings too. What I'm saying
that should work and worked under 2.6.21 and is not working currently
is the ability to unplug and plug back in the device while the
computer is suspended before resuming without losing the mount.
On 11/28/07, Alan Stern <[email protected]> wrote:
> On Tue, 27 Nov 2007, Raymano Garibaldi wrote:
>
> > Hi Alan,
> >
> > Here's what I got after compiling kernel with CONFIG_USB_PERSIST and
> > CONFIG_USB_DEBUG both enabled. The attached files are:
> >
> > config - shows the .config file used when compiling kernel 2.6.23.9
> >
> > sysandmount.txt - shows mounts and the state of persist for all usb
> > devices right before suspending.
> >
> > dmesg_attached.txt - dmesg right after resuming when the USB device
> > remained attached while machine was suspend
> >
> > dmesg_detachedandreattached.txt - dmesg right after resuming when the
> > USB device was detached while suspended and then reattached before
> > resuming.
>
> This all looks okay. Earlier you wrote:
>
> > I have tried this. Simply turning off CONFIG_USB_PERSIST doesn't work.
> > In this case the USB drive file system is unmounted on resume, even if
> > the drive remained plugged in during suspend.
>
> But the logs you just posted show that the filesystem _does_ remain
> mounted after resume, provided you don't unplug the drive. At least
> that's what it looked like -- it was hard to tell for sure because each
> logfile contained multiple suspend/resume cycles with varying outcomes.
>
> Alan Stern
>
>
On Thu, 29 Nov 2007, Raymano Garibaldi wrote:
> The feature does work as long as the device remains plugged in and
> that is what I have said in my previous postings too. What I'm saying
> that should work and worked under 2.6.21 and is not working currently
> is the ability to unplug and plug back in the device while the
> computer is suspended before resuming without losing the mount.
Okay, guess I misunderstood what you wrote before.
The patch below for 2.6.23 should do what you want (and more besides).
It forces the USB Persist feature to apply to all persist-enabled
devices, whether they were unplugged or not.
There's no chance of this getting accepted into the official kernel in
such a simple form, but at least it will allow you to do what you want.
Alan Stern
--- 2.6.23/drivers/usb/core/driver.c1 2007-11-29 10:57:36.000000000 -0500
+++ 2.6.23/drivers/usb/core/driver.c 2007-11-29 11:01:44.000000000 -0500
@@ -1550,6 +1550,9 @@
if (!(udev->reset_resume && udev->do_remote_wakeup))
return -EPERM;
}
+
+ /* Force all system resumes to be reset-resumes */
+ udev->reset_resume = 1;
return usb_external_resume_device(udev);
}
Alan Stern wrote:
> On Thu, 29 Nov 2007, Raymano Garibaldi wrote:
>
>> The feature does work as long as the device remains plugged in and
>> that is what I have said in my previous postings too. What I'm saying
>> that should work and worked under 2.6.21 and is not working currently
>> is the ability to unplug and plug back in the device while the
>> computer is suspended before resuming without losing the mount.
>
> Okay, guess I misunderstood what you wrote before.
>
> The patch below for 2.6.23 should do what you want (and more besides).
> It forces the USB Persist feature to apply to all persist-enabled
> devices, whether they were unplugged or not.
>
> There's no chance of this getting accepted into the official kernel in
> such a simple form, but at least it will allow you to do what you want.
>
> Alan Stern
>
>
> --- 2.6.23/drivers/usb/core/driver.c1 2007-11-29 10:57:36.000000000 -0500
> +++ 2.6.23/drivers/usb/core/driver.c 2007-11-29 11:01:44.000000000 -0500
> @@ -1550,6 +1550,9 @@
> if (!(udev->reset_resume && udev->do_remote_wakeup))
> return -EPERM;
> }
> +
> + /* Force all system resumes to be reset-resumes */
> + udev->reset_resume = 1;
> return usb_external_resume_device(udev);
> }
..
Mmm.. how about a nice sysfs attr that the suspend scripts can write
that value to as needed ?
On Thu, 29 Nov 2007, Mark Lord wrote:
> Alan Stern wrote:
> > On Thu, 29 Nov 2007, Raymano Garibaldi wrote:
> >
> >> The feature does work as long as the device remains plugged in and
> >> that is what I have said in my previous postings too. What I'm saying
> >> that should work and worked under 2.6.21 and is not working currently
> >> is the ability to unplug and plug back in the device while the
> >> computer is suspended before resuming without losing the mount.
> >
> > Okay, guess I misunderstood what you wrote before.
> >
> > The patch below for 2.6.23 should do what you want (and more besides).
> > It forces the USB Persist feature to apply to all persist-enabled
> > devices, whether they were unplugged or not.
> >
> > There's no chance of this getting accepted into the official kernel in
> > such a simple form, but at least it will allow you to do what you want.
> >
> > Alan Stern
> >
> >
> > --- 2.6.23/drivers/usb/core/driver.c1 2007-11-29 10:57:36.000000000 -0500
> > +++ 2.6.23/drivers/usb/core/driver.c 2007-11-29 11:01:44.000000000 -0500
> > @@ -1550,6 +1550,9 @@
> > if (!(udev->reset_resume && udev->do_remote_wakeup))
> > return -EPERM;
> > }
> > +
> > + /* Force all system resumes to be reset-resumes */
> > + udev->reset_resume = 1;
> > return usb_external_resume_device(udev);
> > }
> ..
>
> Mmm.. how about a nice sysfs attr that the suspend scripts can write
> that value to as needed ?
Write what value to? Besides, there already _is_ a sysfs attribute
scripts can use to enable or disable USB-Persist for each device.
Alan Stern
On 11/29/07, Alan Stern <[email protected]> wrote:
> On Thu, 29 Nov 2007, Raymano Garibaldi wrote:
>
> > The feature does work as long as the device remains plugged in and
> > that is what I have said in my previous postings too. What I'm saying
> > that should work and worked under 2.6.21 and is not working currently
> > is the ability to unplug and plug back in the device while the
> > computer is suspended before resuming without losing the mount.
>
> Okay, guess I misunderstood what you wrote before.
>
> The patch below for 2.6.23 should do what you want (and more besides).
> It forces the USB Persist feature to apply to all persist-enabled
> devices, whether they were unplugged or not.
>
> There's no chance of this getting accepted into the official kernel in
> such a simple form, but at least it will allow you to do what you want.
>
> Alan Stern
>
>
> --- 2.6.23/drivers/usb/core/driver.c1 2007-11-29 10:57:36.000000000 -0500
> +++ 2.6.23/drivers/usb/core/driver.c 2007-11-29 11:01:44.000000000 -0500
> @@ -1550,6 +1550,9 @@
> if (!(udev->reset_resume && udev->do_remote_wakeup))
> return -EPERM;
> }
> +
> + /* Force all system resumes to be reset-resumes */
> + udev->reset_resume = 1;
> return usb_external_resume_device(udev);
> }
>
>
>
Alan,
Thank you! Thank you! Thank you!
Who'd have thought such a simple patch could make someone so happy?
That did the trick. I just tried it and it works beautifully whether
the device remains plugged in during suspend or if it's unplugged and
plugged back in during suspend and before resume.
Now if this could only become the default behavior ;-)
Thanks again,
Raymano G.