Re: [linux-usb-devel] [BUG] USB_PERSIST
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.0 -0500 > +++ 2.6.23/drivers/usb/core/driver.c2007-11-29 11:01:44.0 -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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [BUG] USB_PERSIST
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 > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [BUG] USB_PERSIST
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [BUG] USB_PERSIST
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.0 -0500 +++ 2.6.23/drivers/usb/core/driver.c2007-11-29 11:01:44.0 -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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[linux-usb-devel] [FEATURE REQUEST] Transparent hot plugging of root file system on portable storage devices.
Hi, I would like to request a feature in the Linux kernel that would allow a user to unplug a live read-only root file system which exists on a detachable storage device such as a USB key drive. The desired behavior is that once the same device is reattached to the computer the user can continue work transparently without having to reboot. Having such a feature is becoming more important with advances in detachable solid state drive technology. Having the root FS on a wireless storage device such as D.A.V.E. (http://www.seagate.com/www/en-us/products/consumer_electronics/DAVE) would require such a feature in the kernel in case the wireless connection between the storage device and the computer is temporarily lost. The user should have the ability to continue work transparently once the wireless connection is reestablished. Thank you, Raymano G. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [BUG] USB_PERSIST
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [BUG] USB_PERSIST
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[linux-usb-devel] [FEATURE REQUEST] Transparent hot plugging of root file system on portable storage devices.
Hi, I would like to request a feature in the Linux kernel that would allow a user to unplug a live read-only root file system which exists on a detachable storage device such as a USB key drive. The desired behavior is that once the same device is reattached to the computer the user can continue work transparently without having to reboot. Having such a feature is becoming more important with advances in detachable solid state drive technology. Having the root FS on a wireless storage device such as D.A.V.E. (http://www.seagate.com/www/en-us/products/consumer_electronics/DAVE) would require such a feature in the kernel in case the wireless connection between the storage device and the computer is temporarily lost. The user should have the ability to continue work transparently once the wireless connection is reestablished. Thank you, Raymano G. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [BUG] USB_PERSIST
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 > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [BUG] USB_PERSIST
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] USB_PERSIST
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 :00:1f.2 disabled > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1f.1 disabled > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.7 disabled > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.3 disabled > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.2 disabled > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.1 disabled > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.0 disabled > Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :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 > 2010 e49d 0001 > 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 2010 > b180 e49d 0001 > 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 :00:02.0[A] -> GSI 16 > (level, low) -> IRQ 19 > Nov 18 23:07:42 myfaun PM: Writing back config space on device > :00:1b.0 at offset f (was 100, writing 105) > Nov 18 23:07:42 myfaun PM: Writing back config space on device > :00:1b.0 at offset 4 (was 4, writing fdff8004) > Nov 18 23:07:42 myfaun PM: Writing back config space on device > :00:1b.0 at offset 3 (was 0, writing 8) > Nov 18 23:07:42 myfaun PM: Writing back config space on device > :00:1b.0 at offset 1 (was 10, writing 12) > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1b.0[A] -> GSI 16 > (level, low) -> IRQ 19 > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1b.0 to 64 > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1d.0[A] -> GSI 23 > (level, low) -> IRQ 18 > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1d.0 to 64 > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1d.1[B] -> GSI 19 > (level, low) -> IRQ 17 > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1d.1 to 64 > Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1d.2[C] -> GSI 18 > (level, low) -> IRQ 16 > Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1d.2 to 64 > Nov 18 23:07:42 myf
Re: [BUG] USB_PERSIST
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 :00:1f.2 disabled Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1f.1 disabled Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.7 disabled Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.3 disabled Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.2 disabled Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.1 disabled Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :00:1d.0 disabled Nov 18 23:07:42 myfaun ACPI: PCI interrupt for device :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 2010 e49d 0001 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 2010 b180 e49d 0001 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 :00:02.0[A] - GSI 16 (level, low) - IRQ 19 Nov 18 23:07:42 myfaun PM: Writing back config space on device :00:1b.0 at offset f (was 100, writing 105) Nov 18 23:07:42 myfaun PM: Writing back config space on device :00:1b.0 at offset 4 (was 4, writing fdff8004) Nov 18 23:07:42 myfaun PM: Writing back config space on device :00:1b.0 at offset 3 (was 0, writing 8) Nov 18 23:07:42 myfaun PM: Writing back config space on device :00:1b.0 at offset 1 (was 10, writing 12) Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1b.0[A] - GSI 16 (level, low) - IRQ 19 Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1b.0 to 64 Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1d.0[A] - GSI 23 (level, low) - IRQ 18 Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1d.0 to 64 Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1d.1[B] - GSI 19 (level, low) - IRQ 17 Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1d.1 to 64 Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1d.2[C] - GSI 18 (level, low) - IRQ 16 Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1d.2 to 64 Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1d.3[D] - GSI 16 (level, low) - IRQ 19 Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1d.3 to 64 Nov 18 23:07:42 myfaun PCI: Enabling device :00:1d.7 ( - 0002) Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1d.7[A] - GSI 23 (level, low) - IRQ 18 Nov 18 23:07:42 myfaun PCI: Setting
Re: [BUG] USB_PERSIST
23:07:42 myfaun PM: Writing back config space on device :00:1d.7 at offset 4 (was 0, writing fdfff000) Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1e.0 to 64 Nov 18 23:07:42 myfaun PM: Writing back config space on device :00:1f.1 at offset 8 (was f001, writing fa01) Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1f.1[A] -> GSI 18 (level, low) -> IRQ 16 Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1f.1 to 64 Nov 18 23:07:42 myfaun ata2: port disabled. ignoring. Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1f.2[B] -> GSI 19 (level, low) -> IRQ 17 Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :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 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] USB_PERSIST
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] USB_PERSIST
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] USB_PERSIST
.7 at offset 4 (was 0, writing fdfff000) Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1e.0 to 64 Nov 18 23:07:42 myfaun PM: Writing back config space on device :00:1f.1 at offset 8 (was f001, writing fa01) Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1f.1[A] - GSI 18 (level, low) - IRQ 16 Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :00:1f.1 to 64 Nov 18 23:07:42 myfaun ata2: port disabled. ignoring. Nov 18 23:07:42 myfaun ACPI: PCI Interrupt :00:1f.2[B] - GSI 19 (level, low) - IRQ 17 Nov 18 23:07:42 myfaun PCI: Setting latency timer of device :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 ... 6usb 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[REQUEST] New boot flag/kernel option
I would like to request a new boot flag/kernel option that would make the following scenario possible: 1) Working on laptop with a live USB distro on a read-only USB stick. 2) Suspend laptop. 3) Detach USB stick. 4) Do other things, get on a plane, go on a bus, deal with police officer giving you a ticket for operating a laptop while driving... 5) Attach the same read-only USB stick. 6) Resume laptop. 7) Continue work as if nothing happened. The last time we were able to do something like this was in 2.6.21. If not, could you please advise a workaround to get this functionality with the latest kernels. Thank you very much, Raymano - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[REQUEST] New boot flag/kernel option
I would like to request a new boot flag/kernel option that would make the following scenario possible: 1) Working on laptop with a live USB distro on a read-only USB stick. 2) Suspend laptop. 3) Detach USB stick. 4) Do other things, get on a plane, go on a bus, deal with police officer giving you a ticket for operating a laptop while driving... 5) Attach the same read-only USB stick. 6) Resume laptop. 7) Continue work as if nothing happened. The last time we were able to do something like this was in 2.6.21. If not, could you please advise a workaround to get this functionality with the latest kernels. Thank you very much, Raymano - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-1] [USB Mass Storage] [USB_PERSIST] Losing mounted USB storage after resume
The scenario that you've described is exactly what I have in mind as well. The lack of this feature, which worked fine in 2.6.21, is holding us back on updating the kernel in our LiveUSB distribution. I think that this is a feature that would be more and more needed as portable storage devices start growing in capacity and speed and start getting smaller in physical size. Please advise us on how to accomplish this. Kernel boot option; patch; anything! We'll take anything. Thanks Raymano G. On 11/15/07, Mark Lord <[EMAIL PROTECTED]> wrote: > Raymano Garibaldi wrote: > > Hi, > > > > Is there a way/patch that would revert the USB mass storage > > suspend/resume behavior to the way things worked on and prior to > > kernel 2.6.21? > > > > The problem is mounting a usb drive, suspending while mounted, > > detaching the usb drive during suspend, reattaching usb drive during > > suspend before resume, and resuming. > > > > In this case the mount is lost and the drive has to be remounted after > > resume. If the device remains attached while the computer is > > suspended, USB_PERSIST works as expected and the device remains > > mounted when the computer resumes. Kernel 2.6.21-x would leave the > > mount point intact whether the device was left attached or was > > detached and reattached while the computer was suspend. > > > > We need this functionality particularly in read-only live USB distros. > > In this case the USB device is read-only and can not change while the > > computer is suspended even if it gets detached and is reattached > > before resume. > .. > > Some kind of boot flag would cure this one nicely. > > I have the same issue here: boot/run notebook from USB stick, > eventually suspend the notebook and unplug the stick so it can > be packed into the case for travel. > > Unpack at the other end, replug the stick, and resume from suspend. > This should be doable, perhaps with a boot parameter override or something. > > ??? > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.23-1] [USB Mass Storage] [USB_PERSIST] Losing mounted USB storage after resume
Hi, Is there a way/patch that would revert the USB mass storage suspend/resume behavior to the way things worked on and prior to kernel 2.6.21? The problem is mounting a usb drive, suspending while mounted, detaching the usb drive during suspend, reattaching usb drive during suspend before resume, and resuming. In this case the mount is lost and the drive has to be remounted after resume. If the device remains attached while the computer is suspended, USB_PERSIST works as expected and the device remains mounted when the computer resumes. Kernel 2.6.21-x would leave the mount point intact whether the device was left attached or was detached and reattached while the computer was suspend. We need this functionality particularly in read-only live USB distros. In this case the USB device is read-only and can not change while the computer is suspended even if it gets detached and is reattached before resume. Thank you, Raymano G. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6.23-1] [USB Mass Storage] [USB_PERSIST] Losing mounted USB storage after resume
Hi, Is there a way/patch that would revert the USB mass storage suspend/resume behavior to the way things worked on and prior to kernel 2.6.21? The problem is mounting a usb drive, suspending while mounted, detaching the usb drive during suspend, reattaching usb drive during suspend before resume, and resuming. In this case the mount is lost and the drive has to be remounted after resume. If the device remains attached while the computer is suspended, USB_PERSIST works as expected and the device remains mounted when the computer resumes. Kernel 2.6.21-x would leave the mount point intact whether the device was left attached or was detached and reattached while the computer was suspend. We need this functionality particularly in read-only live USB distros. In this case the USB device is read-only and can not change while the computer is suspended even if it gets detached and is reattached before resume. Thank you, Raymano G. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.23-1] [USB Mass Storage] [USB_PERSIST] Losing mounted USB storage after resume
The scenario that you've described is exactly what I have in mind as well. The lack of this feature, which worked fine in 2.6.21, is holding us back on updating the kernel in our LiveUSB distribution. I think that this is a feature that would be more and more needed as portable storage devices start growing in capacity and speed and start getting smaller in physical size. Please advise us on how to accomplish this. Kernel boot option; patch; anything! We'll take anything. Thanks Raymano G. On 11/15/07, Mark Lord [EMAIL PROTECTED] wrote: Raymano Garibaldi wrote: Hi, Is there a way/patch that would revert the USB mass storage suspend/resume behavior to the way things worked on and prior to kernel 2.6.21? The problem is mounting a usb drive, suspending while mounted, detaching the usb drive during suspend, reattaching usb drive during suspend before resume, and resuming. In this case the mount is lost and the drive has to be remounted after resume. If the device remains attached while the computer is suspended, USB_PERSIST works as expected and the device remains mounted when the computer resumes. Kernel 2.6.21-x would leave the mount point intact whether the device was left attached or was detached and reattached while the computer was suspend. We need this functionality particularly in read-only live USB distros. In this case the USB device is read-only and can not change while the computer is suspended even if it gets detached and is reattached before resume. .. Some kind of boot flag would cure this one nicely. I have the same issue here: boot/run notebook from USB stick, eventually suspend the notebook and unplug the stick so it can be packed into the case for travel. Unpack at the other end, replug the stick, and resume from suspend. This should be doable, perhaps with a boot parameter override or something. ??? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
