Hi!
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Reduce code duplication in drivers/base/suspend.c by introducing a separate
> function for printing diagnostic messages.
>
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
ACK, thanks.
Hi!
> > Can you break this up into two patches? If the first adds the queuing
> > code and the second adds autosuspend support, it will be much easier to
> > appraise and test them.
>
> Hi,
>
> this code implements delayed execution of output requests arriving
> for suspended HID devices.
us
Hi!
> >Problem is that suspending _with_ removable mass
> >storage devices
> >attached just will not work. User will unplug them,
> >then complain
> >about corruption. Advanced user will unplug them, work
> >with them
> >somewhere else, replug them, then loose filesystem.
> >
> >Feel free to se
Hi!
> > Problem is that suspending _with_ removable mass storage devices
> > attached just will not work. User will unplug them, then complain
> > about corruption. Advanced user will unplug them, work with them
> > somewhere else, replug them, then loose filesystem.
> >
> > Feel free to send pat
Hi!
> > Problem is that suspending _with_ removable mass storage devices
> > attached just will not work. User will unplug them, then complain
> > about corruption. Advanced user will unplug them, work with them
> > somewhere else, replug them, then loose filesystem.
> >
> > Feel free to send pat
Hi!
> > > > The GNOME hath spoken?
> >
> > > I also thought about that,
> > >
> > > I think that the best solution is still to hide connect/disconnect of
> > > usb devices from userspace (now it also causes corruption)
> > > But to refuse suspend with any usb mass storage device connect
Hi!
> > > In that case the user would see data corruption - just as if he mounts a
> > > piece
> > > of removable media in a USB card reader; yanks out the card and modifies
> > > it
> > > elsewhere, and then puts it back in.
> >
> > > I my opinion we can't really defend ourselves against such
Hi!
> > Ok. To be honest, you are the first reporter that seems to have read
> > the documentation above, but not understood what to do.
>
> thanks for the compliment ;-) _I_ very much know what to do (i mailed
> the right person after all ;), but i dont really count and on the 6
(Can we get
Hi!
> > > Even if one doesn't use the fb console at all, radeonfb apparently
> > > is still required on some ThinkPad models to work around BIOS bugs:
> > >
> > > http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep#Radeon_GPU_not_powered_off
> >
> >
> > s2ram should be ab
Hi!
> > You're better off using the VGA console, and lettign X re-initialize the
> > graphics device. That generally at least has a reasonably good chance of
> > working.
> >
> > Re-initializing graphics modes really is very hard. You can try with the
> > BIOS video hack (I forget the kernel c
Hi!
> > disabling the following radeonfb options in the .config made resume work
> > again:
>
> In general, don't even *try* to use radeonfb for suspend/resume.
>
> I don't think it has ever worked, except on some very rare laptops
> (largely PPC Macs) where people had enough information to se
Hi!
> > > > You should have /proc/acpi/battery/*/state ; it shows current power
> > > > consumption.
> > >
> > > Yes, that works. Cool :-)
> >
> > Good... so how much power is it saving for you?
>
> Nothing USB:
> present rate:1874 mA
>
> Mouse in use:
> present rate:20
Hi1
> > Measurements on x60:
>
> What strange architectures is that?
It is thinkpad x60. i386 architecture.
> > Feb 1 15:58:14 amd kernel: Added idle timer for firing in 10 seconds
> > ^[ Feb 1 15:58:24 amd kernel: state is 0
> > Feb 1 15:58:24 amd kernel: Modded idle timer for firing in 10
Hi!
>
> this preliminary patch should suspend your mouse, if it supports remote
> wakeup. In fact it should do this to all devices which are HID, claimed by
> the input layer and support remote wakeup.
>
> It works for me with my mouse. I've tested letting it autosuspend and
> resume. It survives
On Wed 2007-01-31 16:54:39, Alan Stern wrote:
> On Wed, 31 Jan 2007, Oliver Neukum wrote:
>
> > > timer whenever there is any activity, and when the timer expires you know
> > > the device has been idle long enough that you should suspend it. That's
> > > exactly how the autosuspend infrastructur
Hi!
> > You should have /proc/acpi/battery/*/state ; it shows current power
> > consumption.
>
> Yes, that works. Cool :-)
Good... so how much power is it saving for you?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(
Hi!
> this preliminary patch should suspend your mouse, if it supports remote
> wakeup. In fact it should do this to all devices which are HID, claimed by
> the input layer and support remote wakeup.
>
> It works for me with my mouse. I've tested letting it autosuspend and
> resume. It survives g
Hi!
> > >> if (ret != -EAGAIN)
> > >> msleep(1000);
> > >> +if (try_to_freeze())
> > >> +uea_err(INS_TO_USBDEV(sc), "suspend/resume not
> > >> supported, "
> > >> +"please unplug/repl
Hi!
> > No, HID is the preferred... I am not sure what is going on - on my box
> > STR does not work at all thanks to nvidia chip turning the display on
> > all the way as the very last step of suspend ;(
>
> One or several of these options might help cure this:
> - agp=off kernel command line (p
Hi!
> >> >I started using el-cheapo usb mouse... only to find out that it breaks
> >> >suspend to RAM. Suspend-to-disk works okay. I was not able to extract
> >> >any usefull messages...
> >> >
> >> >Resume process hangs; I can still switch console and even type on
> >> >keyboard, but userland is
Hi!
> >I started using el-cheapo usb mouse... only to find out that it breaks
> >suspend to RAM. Suspend-to-disk works okay. I was not able to extract
> >any usefull messages...
> >
> >Resume process hangs; I can still switch console and even type on
> >keyboard, but userland is dead, and I was no
Hi!
I started using el-cheapo usb mouse... only to find out that it breaks
suspend to RAM. Suspend-to-disk works okay. I was not able to extract
any usefull messages...
Resume process hangs; I can still switch console and even type on
keyboard, but userland is dead, and I was not able to get mag
Hi!
> > usb 2-1: new full speed USB device using uhci_hcd and address 68
> > usb 2-1: USB disconnect, address 68
> > usb 2-1: unable to read config index 0 descriptor/start
> > usb 2-1: chopping to 0 config(s)
>
> Does anybody know a legitimate reasons a device should have
> 0 configurations? Ind
On Thu 2007-01-11 08:48:53, Oliver Neukum wrote:
> Am Mittwoch, 10. Januar 2007 23:35 schrieb Alan Stern:
> > > Apparently here: drivers/base/core.c:
> > >
> > > void device_del(struct device * dev)
> > > {
> > > struct device * parent = dev->parent;
> > > struct class_interface *class
Hi!
> > The obvious change with this device is that usb_set_configuration() is never
> > called, but that should not matter.
>
> No, I think you're barking up the wrong tree.
>
> Pavel, did you have CONFIG_USB_MULTITHREAD_PROBE turned on? I bet you did
> -- there's no other way to generate the
Hi!
> Here are a bunch of USB patches for 2.6.19.
>
> They contain:
> - new driver for usb debug device (client side only so far)
> - helper functions to find usb endpoints easier
> - minor bugfixes
> - new device support
> - usb core rework for autosuspend logic
>
Hi!
> From: Paolo Abeni <[EMAIL PROTECTED]>
>
> A binary interface is added to usbmon. For each USB bus present on the host
> system a new file is added to the debugfs directory, in the form "usb%db".
>
> USB records are stored in a liked list, alike current text interface
> implementation, so
On Sun 2006-10-08 21:57:17, Oliver Neukum wrote:
> Am Sonntag, 8. Oktober 2006 21:36 schrieb Pavel Machek:
> > Mee too
> >
> > Please, lets do few "autosuspend" things, and when we know how it
> > looks, we can think about doing something more advanced.
>
Hi!
> > > The power management functions without
> > > timeout are also exported. For other power control features like
> > > cpu frequency considerable effort has been made to export them to
> > > user space.
> >
> > Yes, and many of us use the much lighter weight kernel based control
> > model
Hi!
> > That is, the standard model is useless? I think you've made
> > a few strange leaps of logic there ... care to fill in those
> > gaps and explain just _why_ that standard model is "useless"???
> >
> > Recall by the way that the autosuspend stuff kicked off with
> > discussions about exac
Hi!
> > > OK, let me state the basics.
> > >
> > > To get real power savings, we:
> > > - blank the display
> > > - spin down the hard drive
> > > - put the CPU into an ACPI sleep state
> > >
> > > To do the latter well, we need to make sure there's no DMA. It is
> > > important that less or lit
Hi!
> > > > > - the issues of manual & automatic suspend and remote wakeup are
> > > > > orthogonal
> > > > > - there should be a common API for all devices
> > > >
> > > > AFAIK there is no demonstrated need for an API to suspend
> > > > individual devices. ...
> > >
> > > I doubt that a lot.
On Fri 2006-10-06 09:04:51, Oliver Neukum wrote:
> Am Freitag, 6. Oktober 2006 04:47 schrieb David Brownell:
> > On Thursday 05 October 2006 2:25 pm, Oliver Neukum wrote:
> >
> > > - the issues of manual & automatic suspend and remote wakeup are
> > > orthogonal
> > > - there should be a common A
On Thu 2006-10-05 17:45:25, Alan Stern wrote:
> On Thu, 5 Oct 2006, Oliver Neukum wrote:
>
> > I have a few observations, but no solution either:
> > - if root tells a device to suspend, it shall do so
>
> Probably everyone will agree on that.
Not sure... I'm not sure if root is in business of t
On Thu 2006-10-05 20:43:59, Oliver Neukum wrote:
> Am Donnerstag, 5. Oktober 2006 20:24 schrieb Alan Stern:
> > On Thu, 5 Oct 2006, Oliver Neukum wrote:
> >
> > > Am Donnerstag, 5. Oktober 2006 18:21 schrieb Alan Stern:
> > > > Currently we don't have any userspace APIs for such a daemon to use.
On Thu 2006-10-05 18:35:21, Oliver Neukum wrote:
> Am Donnerstag, 5. Oktober 2006 18:21 schrieb Alan Stern:
> > Currently we don't have any userspace APIs for such a daemon to use. The
> > only existing API is deprecated and will go away soon.
>
> I trust it'll be replaced.
It does not seem tha
Hi!
> > > Plug/unplug should be easy enough to simulate from usb driver, no?
> >
> > if a USB driver doesn't define suspend/resume methods, then the core simply
> > unplugs it on suspend, and replugs on resume (IIRC).
>
> No longer true, and IIRC it never was. All that happens is that URB
> su
Hi!
> > (So we are talking runtime suspend?)
>
> Yes. Otherwise the patch would have been ready two days ago.
> But if I am implenting this, I'll do a full implementation.
>
> > No, I do not know what the right interface is. I started to suspect
> > that drivers should suspend/resume devices aut
Hi!
> this implements suspend support for usblp. According to the CUPS people
> ENODEV will make CUPS retry the job. Thus it is returned in the runtime
> case. My printer survives suspend/resume cycles with it.
Does it allow uhci to powersave, thus saving lots of power?
Hi!
You marked all the patches as 1/3, btw.
> this patch avoid that the kernel thread block the suspend process.
> Some work is still need to recover after a resume.
>
> Signed-off-by: Matthieu CASTET <[EMAIL PROTECTED]>
>
>
> this patch avoid that the kernel thread block the suspend process.
Hi!
> > Reproduce it with 2.6.18, then it is bugzilla time, or post
> > to linux-usb mailing list.
>
> Thanks Pavel. I tried with kernel 2.6.18. It worked fine with bulk
> device ( USB key). But does not work with isochronous device and system
> hangs. This time I did not have kdb so could not f
t; regards
> Alex
>
> Am Sonntag, 24. September 2006 11:08 schrieb Pavel Machek:
> > Hi!
> >
> > I made some quick experiments, and usb still eats 4W of battery
> > power. (With whole machine eating 9W, that's kind of a big deal)...
> >
> > T
Hi!
> > I made some quick experiments, and usb still eats 4W of battery
> > power. (With whole machine eating 9W, that's kind of a big deal)...
> >
> > This particular machine has usb bluetooth, but it can be disabled by
> > firmware, and appears unplugged. (I did that). It also has fingerprint
>
Hi!
> >I made some quick experiments, and usb still eats 4W of battery
> >power. (With whole machine eating 9W, that's kind of a big deal)...
> >
> >This particular machine has usb bluetooth, but it can be disabled by
> >firmware, and appears unplugged. (I did that). It also has fingerprint
> >sca
Hi!
I made some quick experiments, and usb still eats 4W of battery
power. (With whole machine eating 9W, that's kind of a big deal)...
This particular machine has usb bluetooth, but it can be disabled by
firmware, and appears unplugged. (I did that). It also has fingerprint
scanner, that can't b
Hi!
> > > +main kernel instead of as a separate module, you can put
> > > +"usbcore.persist=1" on the boot command line. You can also change the
> > > +kernel's behavior on the fly using sysfs: Type
> > > +
> > > + echo y >/sys/module/usbcore/parameters/persist
> >
> > Does sysfs treat 'y' as '1
Hi!
> > > And we also need to be able to handle devices in the device tree that do
> > > not have a suspend/resume function, or ones that are not attached to any
> > > bus, without failing the suspend, as obviously they do not care or need
> > > to worry about the whole issue.
> >
> > Ah, there's
This limits power budget on spitz to 250mA. I'm not sure if it is the
right value, but it is certainly better than default 500mA, and
prevents nasty failure mode with zd1201.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
PATCH FOLLOWS
KernelVersion: 2.6.17-rc6-git
diff --git a/
Hi!
> > > If that does the job we need to somehow inherit the power supply maximum
> > > from
> > > PCI when we allocate the root hub's device structure.
> >
> > I don't think there is such a convention that's generic for PCI. There
> > might
> > be ACPI-specific tables holding that value, but
Hi!
> > diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
> > index acde886..1d8b58c 100644
> > --- a/drivers/usb/host/ohci-pxa27x.c
> > +++ b/drivers/usb/host/ohci-pxa27x.c
> > @@ -185,6 +185,13 @@ int usb_hcd_pxa27x_probe (const struct h
> > /* Select Power Managem
On Út 06-06-06 10:02:55, Mark Lord wrote:
> Pavel Machek wrote:
> >
> >Common cellphones are 2W, iirc; (so it would be ~1mW) but I was more
> >interested in system power consumption. WIFI is too power intensive
> >for a cellphone (mostly). Is this designed to go in
> >> UWB is a high-bandwidth, low-power, point-to-point radio
> >> technology using a wide spectrum (3.1-10.6HGz). It is
> >
> >How much power is low power?
>
> For what I know (and I could be wrong) max is around -40dBm/MHz
> in the US. I am no expert in the nitty-gritty radio details, but
>
Hi!
> > It's Ok if it involves a drive change, so long as its an optional change,
> > which
> > means that it shouldn't affect the interface very much (i.e. the calling
> > convention). That's why it'd be good to augment and/or modify pm_message_t
> > to implement the changes, so we wouldn't hav
Hi!
> > https://bugzilla.novell.com/show_bug.cgi?id=173420
>
> >From Comment #30 at the above url: "The Linux ACPI code seems to
> actively prevent the fan from running and that worries me."
>
> I saw that as well, and found the following recipe would work around
> the problem:
>
> 1. Set the t
Hi!
> > > > During swsusp the system is
> > > > supposed to be completely off, with no suspend power available. Hence
> > > > all the power sessions are guaranteed to be interrupted, and the boot
> > > > kernel doesn't have to worry about destroying any of them.
> > >
> > > Not ne
On Út 25-04-06 16:13:41, David Brownell wrote:
> On Tuesday 25 April 2006 2:41 pm, Pavel Machek wrote:
>
> > > Well, if we had a pm_should_I_spin_down_drives() it would make sense to me
> > > that it return FALSE during kernel_restart_prepare() too ... surely kexec
&
(aha, I see the mail now)
> > > I've begun thinking that calls like pm_should_I_spin_down_drives() would
> > > be a
> > > better structural approach than continually redefining this "freeze"
> > > thing so
> > > it makes less and less sense to all other drivers ... who nonethless need
> > > to
Hi!
> That's suspend-to-disk, yes?
>
> Dave, would you have the 2.6.15-1.1830_FC4 -> 2.6.15-1.1831_FC4 details
> handy? There surely can't be much difference?
>
> There seem to be several ACPI problems there. Do we have a reliable means
> of feeding such reports up into the (for example) acpi
On So 04-02-06 23:14:26, Russell King wrote:
> On Sat, Feb 04, 2006 at 08:47:29AM -0800, Martin J. Bligh wrote:
> >
> > > > [Bug 5958] CF bluetooth card oopses machine when
> > > > http://bugzilla.kernel.org/show_bug.cgi?id=5958
> > >
> > > This isn't a serial bug - it's a bluetooth ldisc
Hi!
> http://projects.o-hand.com/hx2750/patches/usb_pxa27x_udc-r0.patch
>
> is the pxa27x driver itself. I've taken the one from handhelds.org and
> made changes to get full CDC-Ethernet running with it instead of
> CDC-Subset by handling the pxa27x specific configuration issues
> properly. I've
Hi!
> > since I switched to 2.6.15-rc2-git6, my machine is not able to suspend
> > anymore if my USB printer is plugged in. The problem is reproducible.
> >
> > usb 1-2: new full speed USB device using uhci_hcd and address 3
> > drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 3 i
Hi!
Of course I forgot the patch...
Pavel
Remove useless initalizers.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff --git a/drivers/usb/gadget/file_storage.c
b/drivers/usb/gadget/file_storage.c
--- a/drivers/usb/
Hi!
> > > What's the reason for this prejudice against C++-style comments in the
> > > kernel? I've never understood it... They seem so obviously useful,
> > > saving 3 characters of typing at the end of each comment line.
> >
> > I've never seen a piece of non-crappy code using them... that's
Hi!
> > This converts comments into C-style,
>
> You missed a lot of them.
Yes, I know, at one point I realized you probably liked it that
way. Shall I resent just the "remove the initializer" part?
> What's the reason for this prejudice against C++-style comments in the
> kernel? I've never u
Hi!
This converts comments into C-style, and removes unused
initializers. I'd like it applied...
On a related note -- how well does it work, particulary with different
hosts? It uses 'volatile' quite heavily, and that scares me a lot.
Signed-off-by: Pavel Machek <[EMAIL PROTE
Hi!
> > In -mm, usb breaks suspend to disk. Compiled without
> > CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it
> > actually tries to suspend USB, but it fails and machine refuses to
> > suspend. Is it known or is it worth debugging?
>
> More details please.
>
> 2.6.14-rc1 is a
Hi!
In -mm, usb breaks suspend to disk. Compiled without
CONFIG_USB_SUSPEND, it just plainly fails; iwth USB_SUSPEND, it
actually tries to suspend USB, but it fails and machine refuses to
suspend. Is it known or is it worth debugging?
Hi!
> - You might want to differentiate between this key and the ENTER key
> of your keyboard, at least I do. If the kernel is sending the same
> code for both keys, this is not possible in userspace.
No, I think that you can still diferentiate between them ... they come
from different keyboa
Hi!
> I discovered a minor change in 2.6.10-mm1, changing this value back
> corrects the "ok" button issue.
>
>
> diff -urN linux/drivers/usb/input/ati_remote.c
> linux-2.6.11/drivers/usb/input/ati_remote.c
> --- linux/drivers/usb/input/ati_remote.c2005-08-02
> 17:56:26.0 +1200
>
> > Yes. (Actually I'm not sure if PMSG_FREEZE or PMSG_SUSPEND is right
> > thing to do for suspend.)
>
> Until they have different values, it's a moot point isn't it?
They already have different values in my and SuSE trees, and I plan to
propagate that upstream very soon after 2.6.12. Until the
Hi!
> > Well, you can do "half suspend to ram; change your frequency; half
> > resume" today, and it should work, but I do not think you'll like the
> > speed.
>
> Indeed. With people running things like cpuspeed daemons to dynamically
> scale speed, this is going to be really painful.
> Of co
> I've been considering for a while that, in addition to ->probe and ->remove,
> we
> have the following:
>
> "struct device" -->
> ->attach - binds to the device and allocates data structures
> ->probe - detects and sets up the hardware
> ->start - begins transactions (like DMA)
> ->stop - stop
On Po 25-04-05 18:13:27, Dave Jones wrote:
> On Mon, Apr 25, 2005 at 02:58:31PM -0700, Andrew Morton wrote:
> > Alan Stern <[EMAIL PROTECTED]> wrote:
> > >
> > > On Mon, 25 Apr 2005, Alexander Nyberg wrote:
> > >
> > > > Not sure what you mean by "make kexec work nicer" but if it is because
>
Hi!
> > I don't like this notion of "stop" separated from power states anyway, I
> > think it just doesn't work in practice.
>
> Yeah, after giving it some additional thought, I think there are better ways.
>
> >
> > Ben.
> >
>
> Ok, here's a new idea.
>
> For many devices "->suspend" and "-
Hi!
> > > Well it seems that people are starting to want to hook the reboot
> > > notifier, or the device shutdown facility in order to properly shutdown
> > > pci drivers to make kexec work nicer.
> > >
> > > So here's a patch for the PCI core that allows pci drivers to now just
> > > add a "shu
Hi!
> > > Actually this patch should be in the queue somewhere... We had it in
> > > suse trees for a long time, and IMO it can solve problem easily.
> > >
> > > Pavel
> > >
> > > --- clean-git/kernel/sys.c2005-04-23 23:21:55.
Hi!
> > > Well it seems that people are starting to want to hook the reboot
> > > notifier, or the device shutdown facility in order to properly shutdown
> > > pci drivers to make kexec work nicer.
> > >
> > > So here's a patch for the PCI core that allows pci drivers to now just
> > > add a "shu
Hi!
> Well it seems that people are starting to want to hook the reboot
> notifier, or the device shutdown facility in order to properly shutdown
> pci drivers to make kexec work nicer.
>
> So here's a patch for the PCI core that allows pci drivers to now just
> add a "shutdown" notifier function
Hi!
> > Apr 13 21:22:52 amd kernel: usb 2-2: new full speed USB device using
> > uhci_hcd and address 3
> > Apr 13 21:22:52 amd kernel: usb-storage: This device (0693,0002,0100 S 06 P
> > 50) has unneeded SubClass and Protocol entries in unusual_devs.h
> > Apr 13 21:22:52 amd kernel:Please s
Hi!
...
Apr 13 21:22:52 amd kernel: usb 2-2: new full speed USB device using uhci_hcd
and address 3
Apr 13 21:22:52 amd kernel: usb-storage: This device (0693,0002,0100 S 06 P 50)
has unneeded SubClass and Protocol entries in unusual_devs.h
Apr 13 21:22:52 amd kernel:Please send a copy of th
Hi!
> Here, for your consideration, are fixups I still have in my tree after
> updating to rc2.
>
> (USB & Framebuffer lists copied because a reasonable number apply
> there).
>
> Regards,
>
> Nigel
>
> diff -ruNp
> 840-combined-pm_message_t-patch.patch-old/drivers/base/power/resume.c
> 840-
Hi!
> > > a) apply
> > > b) compile
> > > c) work
> > >
> > > ?
> > >
> >
> > The patches I sent certainly meet those requirements -- in my testing,
> > and against 2.6.12-rc1.
> >
> > You're wanting a version that applies to 2.6.12-rc1-mm? Then instead
> > of the patch I previously sent on
Hi!
> > Please. I think that's all the suspend-related patches I've sent
> > recently, and from what I see of Pavel's patch they're basically a
> > superset: comparable pm_message_t changes, plus real bugfixes. :)
>
> I'm getting wholly fed up with this whole fiasco. How about I just drop
Hi!
> > And here's the patch. Applies cleanly against the latest kernel.org BK.
> > Agaist Greg's latest BK, and maybe against the MM tree, you'll want
> > to globally substitute HCD_STATE and USB_STATE with HC_STATE before
> > applying the patch.
> >
> > Summary of changes: cope with pm_messag
Hi!
> Guys, is this something which we expect will be fixed when the USB power
> management fixes are complete?
Changing config during hibernate should be okay for all things that
are hot-pluggable (when we are done ;-). That includes USB
Hi!
> > In 2.6.11-rc[23], I get problems after swsusp resume:
> >
> > Feb 4 23:54:39 amd kernel: Restarting tasks...<3>hub 3-0:1.0:
> > over-current change on port 1
> > Feb 4 23:54:39 amd kernel: done
> > Feb 4 23:54:39 amd kernel: hub 3-0:1.0: connect-debounce failed, port
> > 1 disabled
>
Hi!
> > > Your logs don't indicate which host controller driver is bound to each of
> > > your hubs. /proc/bus/usb/devices will contain that information. Without
> > > it, it's hard to diagnose what happened.
> >
> > I do not think I have any hubs... no external hubs anyway. And I do
> > not
Hi!
> > In 2.6.11-rc[23], I get problems after swsusp resume:
> >
> > Feb 4 23:54:39 amd kernel: Restarting tasks...<3>hub 3-0:1.0:
> > over-current change on port 1
> > Feb 4 23:54:39 amd kernel: done
> > Feb 4 23:54:39 amd kernel: hub 3-0:1.0: connect-debounce failed, port
> > 1 disabled
>
Hi!
> In 2.6.11-rc[23], I get problems after swsusp resume:
>
> Feb 4 23:54:39 amd kernel: Restarting tasks...<3>hub 3-0:1.0:
> over-current change on port 1
> Feb 4 23:54:39 amd kernel: done
> Feb 4 23:54:39 amd kernel: hub 3-0:1.0: connect-debounce failed, port
> 1 disabled
> Feb 4 23:54:3
Hi!
In 2.6.11-rc[23], I get problems after swsusp resume:
Feb 4 23:54:39 amd kernel: Restarting tasks...<3>hub 3-0:1.0:
over-current change on port 1
Feb 4 23:54:39 amd kernel: done
Feb 4 23:54:39 amd kernel: hub 3-0:1.0: connect-debounce failed, port
1 disabled
Feb 4 23:54:39 amd kernel: hu
Hi!
From: Bernard Blackham <[EMAIL PROTECTED]>
This fixes types in USB w.r.t. driver model. It should not actually
change any code. Please apply,
Pavel
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
diff -ru linu
Hi!
> > > > boot
> > > > swsusp suspend
> > > > SWSUSP MESSAGES AFTER IMAGE WAS WRITTEN
> > > > (RE)BOOT
> > > > SWSUSP MESSAGES SWITCHING TO OLD IMAGE
> > > > swsusp resume
> > > >
> > > > I've certainly found cases where the the "MISSING LOG DATA" had some
> > > > inform
Hi!
> > In any case this isn't under our control.
> > Devices are resumed in the same order they were detected initially. I
> > think the only way to solve this problem is to find a workaround for EHCI
> > controllers that act weird when they resume.
>
> The problem could well be in UHCI inst
Hi!
> > Okay, it is probably different problem (and looks like usb
> > problem). It worked ok in 2.6.9, right?
>
> I don't know. This laptop is quite new.
> Noapic doesn't work.
Okay, it probably never worked before. I'm happy that it at least
works after unplug/replug :-). Probably better suspe
Hi!
> > > with 2.6.10 (i386/UP/UHCI)
> > > :00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 03)
> > > :00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 03)
> > > :00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 03)
> > > :00:1d.7 USB Control
Hi!
> with 2.6.10 (i386/UP/UHCI)
> :00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 03)
> :00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 03)
> :00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 03)
> :00:1d.7 USB Controller: Intel Corp. 828
Hi!
> I don't have swsusp compiled in, but if I unload and
> reload the module, then it works.
> Anyway, this is not the intended behaviour, as it
> worked fine till 2.6.10 without unload/reload.
Yes it is a bug. Find which changeset causes it and complain to its author.
It is probably going to b
Hi!
> With kernel 2.6.10, I have the following problem with uhci_hcd:
> After an ACPI S3 suspend it fails to see any USB device plugged in.
> If I unload the module and load it again, it works again.
> I hadn't this problem with previous kernels, where it worked just fine.
> Do you know something
Hi!
> One significant example involves USB mice. If they were to be
> suspended (usb_suspend_device) after a few seconds of inactivity,
> that change could often spread up the device tree and let the
> USB host controller stop DMA access. Some x86 CPUs could
> then enter C3 and save a couple Wat
Hi!
> It seems there's a problem with USB OHCI driver that causes these traces to
> appear on suspend on an AMD64-based box:
Check if OHCI's suspend/resume method is called correctly and that
OHCI really acts on it.
Pavel
--
People
1 - 100 of 195 matches
Mail list logo
