annoying frequent overcurrent messages.

annoying frequent overcurrent messages.

[Dave Jones]

I have a box that's having its dmesg flooded with..

hub 1-0:1.0: over-current change on port 1
hub 1-0:1.0: over-current change on port 2
hub 1-0:1.0: over-current change on port 1
hub 1-0:1.0: over-current change on port 2
hub 1-0:1.0: over-current change on port 1
hub 1-0:1.0: over-current change on port 2
hub 1-0:1.0: over-current change on port 1
hub 1-0:1.0: over-current change on port 2
hub 1-0:1.0: over-current change on port 1
hub 1-0:1.0: over-current change on port 2
hub 1-0:1.0: over-current change on port 1
hub 1-0:1.0: over-current change on port 2

over and over again..
The thing is, this box doesn't even have any USB devices connected to it,
so there's absolutely nothing I can do to remedy this.

lsusb -v output below

		Dave


Bus 004 Device 001: ID 0000:0000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0000 
  idProduct          0x0000 
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.17-1.2366.fc6 ohci_hcd
  iProduct                2 OHCI Host Controller
  iSerial                 1 0000:02:01.1
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval             255
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             2
  wHubCharacteristic 0x0002
    No power switching (usb 1.0)
    Ganged overcurrent protection
  bPwrOn2PwrGood        0 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0xc0
  PortPwrCtrlMask    0xf6 
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power

Bus 003 Device 001: ID 0000:0000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0000 
  idProduct          0x0000 
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.17-1.2366.fc6 ohci_hcd
  iProduct                2 OHCI Host Controller
  iSerial                 1 0000:02:01.0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval             255
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             2
  wHubCharacteristic 0x0002
    No power switching (usb 1.0)
    Ganged overcurrent protection
  bPwrOn2PwrGood        0 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0xc0
  PortPwrCtrlMask    0xf6 
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power

Bus 002 Device 001: ID 0000:0000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x0000 
  idProduct          0x0000 
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.17-1.2366.fc6 ehci_hcd
  iProduct                2 EHCI Host Controller
  iSerial                 1 0000:02:01.2
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval              12
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             4
  wHubCharacteristic 0x0009
    Per-port power switching
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood       10 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0xc0
  PortPwrCtrlMask    0xf6 
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power
   Port 3: 0000.0100 power
   Port 4: 0000.0100 power

Bus 001 Device 001: ID 0000:0000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0000 
  idProduct          0x0000 
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.17-1.2366.fc6 uhci_hcd
  iProduct                2 UHCI Host Controller
  iSerial                 1 0000:00:1f.2
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval             255
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             2
  wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
  bPwrOn2PwrGood        1 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0xc0
  PortPwrCtrlMask    0xf6 
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power
-- 
http://www.codemonkey.org.uk

Re: annoying frequent overcurrent messages.

[Alan Stern]

Dave Jones wrote:

> I have a box that's having its dmesg flooded with..
> 
> hub 1-0:1.0: over-current change on port 1
> hub 1-0:1.0: over-current change on port 2
> hub 1-0:1.0: over-current change on port 1
> hub 1-0:1.0: over-current change on port 2
...

> over and over again..
> The thing is, this box doesn't even have any USB devices connected to it,
> so there's absolutely nothing I can do to remedy this.

Well, overcurrent is a potentially dangerous situation.  That's why it 
gets reported with dev_err priority.

Evidently it's a hardware fault.  Perhaps the overcurrent-detect input 
lines are floating and constantly triggering as a result.  It's not even 
clear that attaching a USB device would make the problem go away.

Since you're not using the UHCI controller on that computer, you could 
simply rmmod uhci-hcd (or modify /etc/modprobe.conf to prevent it from 
being loaded in the first place).  That would stop the constant interrupts 
and the syslog spamming.

But as for fixing the underlying hardware problem, I don't think there's 
anything we can do.

Alan Stern

Re: annoying frequent overcurrent messages.

[Dave Jones]

On Wed, Jul 12, 2006 at 10:19:39AM -0400, Alan Stern wrote:
 > Dave Jones wrote:
 > 
 > > I have a box that's having its dmesg flooded with..
 > > 
 > > hub 1-0:1.0: over-current change on port 1
 > > hub 1-0:1.0: over-current change on port 2
 > > hub 1-0:1.0: over-current change on port 1
 > > hub 1-0:1.0: over-current change on port 2
 > ...
 > 
 > > over and over again..
 > > The thing is, this box doesn't even have any USB devices connected to it,
 > > so there's absolutely nothing I can do to remedy this.
 > 
 > Well, overcurrent is a potentially dangerous situation.  That's why it 
 > gets reported with dev_err priority.
 > 
 > Evidently it's a hardware fault.  Perhaps the overcurrent-detect input 
 > lines are floating and constantly triggering as a result.  It's not even 
 > clear that attaching a USB device would make the problem go away.
 > 
 > Since you're not using the UHCI controller on that computer, you could 
 > simply rmmod uhci-hcd (or modify /etc/modprobe.conf to prevent it from 
 > being loaded in the first place).  That would stop the constant interrupts 
 > and the syslog spamming.
 > 
 > But as for fixing the underlying hardware problem, I don't think there's 
 > anything we can do.

we could at least rate-limit the messages.

		Dave

-- 
http://www.codemonkey.org.uk

Re: annoying frequent overcurrent messages.

[Ray Lee]

On 7/12/06, Alan Stern <stern@rowland.harvard.edu> wrote:
> Dave Jones wrote:
> > I have a box that's having its dmesg flooded with..
> >
> > hub 1-0:1.0: over-current change on port 1
> > hub 1-0:1.0: over-current change on port 2
> > hub 1-0:1.0: over-current change on port 1
> > hub 1-0:1.0: over-current change on port 2
> ...
>
> > over and over again..
> > The thing is, this box doesn't even have any USB devices connected to it,
> > so there's absolutely nothing I can do to remedy this.
>
> Since you're not using the UHCI controller on that computer, you could
> simply rmmod uhci-hcd (or modify /etc/modprobe.conf to prevent it from
> being loaded in the first place).  That would stop the constant interrupts
> and the syslog spamming.

For the syslog spamming, you could jus emit the message once when the
state is first noticed, then emit a everything good message when it
clears up. There's no need to log it repeatedly during the problem
period.

Ray

Re: annoying frequent overcurrent messages.

[Alan Stern]

On Wed, 12 Jul 2006, Ray Lee wrote:

> On 7/12/06, Alan Stern <stern@rowland.harvard.edu> wrote:
> > Dave Jones wrote:
> > > I have a box that's having its dmesg flooded with..
> > >
> > > hub 1-0:1.0: over-current change on port 1
> > > hub 1-0:1.0: over-current change on port 2
> > > hub 1-0:1.0: over-current change on port 1
> > > hub 1-0:1.0: over-current change on port 2
> > ...
> >
> > > over and over again..
> > > The thing is, this box doesn't even have any USB devices connected to it,
> > > so there's absolutely nothing I can do to remedy this.
> >
> > Since you're not using the UHCI controller on that computer, you could
> > simply rmmod uhci-hcd (or modify /etc/modprobe.conf to prevent it from
> > being loaded in the first place).  That would stop the constant interrupts
> > and the syslog spamming.
> 
> For the syslog spamming, you could jus emit the message once when the
> state is first noticed, then emit a everything good message when it
> clears up. There's no need to log it repeatedly during the problem
> period.

That's almost exactly how the driver behaves currently -- the message is
printed just once when the state is first noticed.  Nothing is printed 
when the state is cleared, and nothing gets printed repeatedly during the 
problem period.  But then the problem recurs very quickly.


On Wed, 12 Jul 2006, Dave Jones wrote:

> we could at least rate-limit the messages.

That's true for every message in the kernel.  How do you decide which 
messages to rate-limit?

Note that this particular message will cause problems only in the presence 
of defective hardware.

Alan Stern

Re: annoying frequent overcurrent messages.

[Ray Lee]

On 7/12/06, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Wed, 12 Jul 2006, Ray Lee wrote:
>
> > On 7/12/06, Alan Stern <stern@rowland.harvard.edu> wrote:
> > > Dave Jones wrote:
> > > > I have a box that's having its dmesg flooded with..
> > > >
> > > > hub 1-0:1.0: over-current change on port 1
> > > > hub 1-0:1.0: over-current change on port 2
> > > > hub 1-0:1.0: over-current change on port 1
> > > > hub 1-0:1.0: over-current change on port 2
> > > ...
> > >
> > > > over and over again..
> > > > The thing is, this box doesn't even have any USB devices connected to it,
> > > > so there's absolutely nothing I can do to remedy this.
> > >
> > > Since you're not using the UHCI controller on that computer, you could
> > > simply rmmod uhci-hcd (or modify /etc/modprobe.conf to prevent it from
> > > being loaded in the first place).  That would stop the constant interrupts
> > > and the syslog spamming.
> >
> > For the syslog spamming, you could jus emit the message once when the
> > state is first noticed, then emit a everything good message when it
> > clears up. There's no need to log it repeatedly during the problem
> > period.
>
> That's almost exactly how the driver behaves currently -- the message is
> printed just once when the state is first noticed.  Nothing is printed
> when the state is cleared, and nothing gets printed repeatedly during the
> problem period.  But then the problem recurs very quickly.

Then the logging of the 'all cleared up' message would be better if it
had a bit of hysteresis to it -- the good state is noticed, but don't
log it as such until it hangs out there for a while and has had a
chance to quiesce.

Ray

Re: annoying frequent overcurrent messages.

[Alan Stern]

On Wed, 12 Jul 2006, Ray Lee wrote:

> > > For the syslog spamming, you could jus emit the message once when the
> > > state is first noticed, then emit a everything good message when it
> > > clears up. There's no need to log it repeatedly during the problem
> > > period.
> >
> > That's almost exactly how the driver behaves currently -- the message is
> > printed just once when the state is first noticed.  Nothing is printed
> > when the state is cleared, and nothing gets printed repeatedly during the
> > problem period.  But then the problem recurs very quickly.
> 
> Then the logging of the 'all cleared up' message would be better if it
> had a bit of hysteresis to it -- the good state is noticed, but don't
> log it as such until it hangs out there for a while and has had a
> chance to quiesce.

You didn't read what I wrote -- there _is_ no "all cleared up" message.

Alan Stern

Re: annoying frequent overcurrent messages.

[Ray Lee]

On 7/12/06, Alan Stern <stern@rowland.harvard.edu> wrote:
> > Then the logging of the 'all cleared up' message would be better if it
> > had a bit of hysteresis to it -- the good state is noticed, but don't
> > log it as such until it hangs out there for a while and has had a
> > chance to quiesce.
>
> You didn't read what I wrote -- there _is_ no "all cleared up" message.

You're right, I didn't -- my apologies. However:

> > That's almost exactly how the driver behaves currently -- the message is
> > printed just once when the state is first noticed.  Nothing is printed
> > when the state is cleared, and nothing gets printed repeatedly during the
> > problem period.  But then the problem recurs very quickly.

If you change my wording from "all cleared up message" to "clearing
the internal state that keeps track of whether we're still in an
overcurrent situation" then my suggestion still makes sense. In short,
don't believe we're out of the overcurrent state until a bit of time
passes.

Before we go any further, let's make sure my suggestion could even fix
anything for Dave. Dave? How often are these messages printed? Do they
come in clumps? Or are they periodic? In other words, would a bit of
hystersis in the state clearing code remove most of the messages for
you? Or am I just stirring up trouble?

Ray

Re: annoying frequent overcurrent messages.

[Dave Jones]

On Wed, Jul 12, 2006 at 01:19:43PM -0400, Alan Stern wrote:
 > On Wed, 12 Jul 2006, Dave Jones wrote:
 > 
 > > we could at least rate-limit the messages.
 > 
 > That's true for every message in the kernel.  How do you decide which 
 > messages to rate-limit?

anything the user doesn't have any means of fixing should be able to be
ignored. With dmesg filled with these, it's hard to ignore them.

 > Note that this particular message will cause problems only in the presence 
 > of defective hardware.

Defective it may be, I'm not arguing that.    But spewing hundreds of
these an hour isn't going to make the user fix the problem (if they even can)
any faster.

*grumbles and goes to edit modprobe.conf*

		Dave

-- 
http://www.codemonkey.org.uk

Re: annoying frequent overcurrent messages.

[Alan Stern]

On Wed, 12 Jul 2006, Dave Jones wrote:

> On Wed, Jul 12, 2006 at 01:19:43PM -0400, Alan Stern wrote:
>  > On Wed, 12 Jul 2006, Dave Jones wrote:
>  > 
>  > > we could at least rate-limit the messages.
>  > 
>  > That's true for every message in the kernel.  How do you decide which 
>  > messages to rate-limit?
> 
> anything the user doesn't have any means of fixing should be able to be
> ignored. With dmesg filled with these, it's hard to ignore them.

That wasn't a rhetorical question.  A large percentage of the messages in
the USB hub driver have the potential to spam the syslog, given the right
sort of hardware disfunction.  But it doesn't seem practical to rate-limit
all of them.

Alan Stern

Re: annoying frequent overcurrent messages.

[Alan Cox]

Ar Mer, 2006-07-12 am 13:51 -0400, ysgrifennodd Dave Jones:
> Defective it may be, I'm not arguing that.    But spewing hundreds of
> these an hour isn't going to make the user fix the problem (if they even can)
> any faster.
> 
> *grumbles and goes to edit modprobe.conf*

dmidecode
pci svid/subdevice

submit patch

I agree entirely with the other Alan here, overcurrent is a serious item
with a potential severity not that far below "your cpu fan seems to have
stopped going round  [Ok]"


If its a dodgy board it should be possible to id and blacklist its UHCI
controller

Re: annoying frequent overcurrent messages.

[Pavel Machek]

Hi!

> > I have a box that's having its dmesg flooded with..
> > 
> > hub 1-0:1.0: over-current change on port 1
> > hub 1-0:1.0: over-current change on port 2
> > hub 1-0:1.0: over-current change on port 1
> > hub 1-0:1.0: over-current change on port 2
> ...
> 
> > over and over again..
> > The thing is, this box doesn't even have any USB devices connected to it,
> > so there's absolutely nothing I can do to remedy this.
> 
> Well, overcurrent is a potentially dangerous situation.  That's why it 
> gets reported with dev_err priority.

Well, I see overcurrents all the time while doing suspend/resume...

Why is it dangerous? USB should survive plugging something that
connects +5V and ground. It may turn your machine off, but that should
be it...?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: annoying frequent overcurrent messages.

[Arjan van de Ven]

On Thu, 2006-07-13 at 14:08 +0200, Pavel Machek wrote:
> Hi!
> 
> > > I have a box that's having its dmesg flooded with..
> > > 
> > > hub 1-0:1.0: over-current change on port 1
> > > hub 1-0:1.0: over-current change on port 2
> > > hub 1-0:1.0: over-current change on port 1
> > > hub 1-0:1.0: over-current change on port 2
> > ...
> > 
> > > over and over again..
> > > The thing is, this box doesn't even have any USB devices connected to it,
> > > so there's absolutely nothing I can do to remedy this.
> > 
> > Well, overcurrent is a potentially dangerous situation.  That's why it 
> > gets reported with dev_err priority.
> 
> Well, I see overcurrents all the time while doing suspend/resume...
> 
> Why is it dangerous? USB should survive plugging something that
> connects +5V and ground. It may turn your machine off, but that should
> be it...?

it's fun if your main storage resides near it on the same hub... 
like your suspend device
(now ok suspend-to-usb-disk is silly I suppose, but I can think of some
really cool usage models that that allows in an office-less office)

Re: annoying frequent overcurrent messages.

[Alan Stern]

On Thu, 13 Jul 2006, Pavel Machek wrote:

> > Well, overcurrent is a potentially dangerous situation.  That's why it 
> > gets reported with dev_err priority.
> 
> Well, I see overcurrents all the time while doing suspend/resume...
> 
> Why is it dangerous? USB should survive plugging something that
> connects +5V and ground. It may turn your machine off, but that should
> be it...?

The key words here are "potentially", "should", and "may".

BTW, what sort of overcurrents do you see during suspend/resume?

Alan Stern

Re: annoying frequent overcurrent messages.

[Pavel Machek]

Hi!

> > > Well, overcurrent is a potentially dangerous situation.  That's why it 
> > > gets reported with dev_err priority.
> > 
> > Well, I see overcurrents all the time while doing suspend/resume...
> > 
> > Why is it dangerous? USB should survive plugging something that
> > connects +5V and ground. It may turn your machine off, but that should
> > be it...?
> 
> The key words here are "potentially", "should", and "may".
> 
> BTW, what sort of overcurrents do you see during suspend/resume?

Okay, that was on X32, and I'm not using it for now, sorry about
that. "Overcurrent on port XY" was the message, IIRC, but...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: annoying frequent overcurrent messages.

[Al Boldi]

On Thu, 2006-07-13 at 14:08 +0200, Pavel Machek wrote:
> > > I have a box that's having its dmesg flooded with..
> > > 
> > > hub 1-0:1.0: over-current change on port 1
> > > hub 1-0:1.0: over-current change on port 2
> > > hub 1-0:1.0: over-current change on port 1
> > > hub 1-0:1.0: over-current change on port 2
> > ...
> > 
> > > over and over again..
> > > The thing is, this box doesn't even have any USB devices connected to 
> > > it, so there's absolutely nothing I can do to remedy this.
> > 
> > Well, overcurrent is a potentially dangerous situation.  That's why it 
> > gets reported with dev_err priority.
> 
> Well, I see overcurrents all the time while doing suspend/resume...
> 
> Why is it dangerous? USB should survive plugging something that
> connects +5V and ground. It may turn your machine off, but that should
> be it...?

I don't want to sound alarming here, but I just had a USBFlashStick fried by 
a machine, while in suspend-to-ram running 2.6.17.

I am blaming hw, but does anybody know how I can get my data back?

Thanks!

--
Al

Re: annoying frequent overcurrent messages.

[Pavel Machek]

On Thu 13-07-06 23:50:55, Al Boldi wrote:
> On Thu, 2006-07-13 at 14:08 +0200, Pavel Machek wrote:
> > > > I have a box that's having its dmesg flooded with..
> > > > 
> > > > hub 1-0:1.0: over-current change on port 1
> > > > hub 1-0:1.0: over-current change on port 2
> > > > hub 1-0:1.0: over-current change on port 1
> > > > hub 1-0:1.0: over-current change on port 2
> > > ...
> > > 
> > > > over and over again..
> > > > The thing is, this box doesn't even have any USB devices connected to 
> > > > it, so there's absolutely nothing I can do to remedy this.
> > > 
> > > Well, overcurrent is a potentially dangerous situation.  That's why it 
> > > gets reported with dev_err priority.
> > 
> > Well, I see overcurrents all the time while doing suspend/resume...
> > 
> > Why is it dangerous? USB should survive plugging something that
> > connects +5V and ground. It may turn your machine off, but that should
> > be it...?
> 
> I don't want to sound alarming here, but I just had a USBFlashStick fried by 
> a machine, while in suspend-to-ram running 2.6.17.

Well, I have one usb sticdk fried by regular use under linux (like --
5 minutes of regular use!) and another fried by my dad on windows. So
these beasts are crap.

> I am blaming hw, but does anybody know how I can get my data back?

Probably not easily. Specialized shop might desolder flash chip and
read it directly... or you may try swapping flash chip into
'not-yet-fried' stick...

-- 
Thanks for all the (sleeping) penguins.

Re: annoying frequent overcurrent messages.

[Al Boldi]

Pavel Machek wrote:
> On Thu 13-07-06 23:50:55, Al Boldi wrote:
> > On Thu, 2006-07-13 at 14:08 +0200, Pavel Machek wrote:
> > > > > I have a box that's having its dmesg flooded with..
> > > > >
> > > > > hub 1-0:1.0: over-current change on port 1
> > > > > hub 1-0:1.0: over-current change on port 2
> > > > > hub 1-0:1.0: over-current change on port 1
> > > > > hub 1-0:1.0: over-current change on port 2
> > > >
> > > > ...
> > > >
> > > > > over and over again..
> > > > > The thing is, this box doesn't even have any USB devices connected
> > > > > to it, so there's absolutely nothing I can do to remedy this.
> > > >
> > > > Well, overcurrent is a potentially dangerous situation.  That's why
> > > > it gets reported with dev_err priority.
> > >
> > > Well, I see overcurrents all the time while doing suspend/resume...
> > >
> > > Why is it dangerous? USB should survive plugging something that
> > > connects +5V and ground. It may turn your machine off, but that should
> > > be it...?
> >
> > I don't want to sound alarming here, but I just had a USBFlashStick
> > fried by a machine, while in suspend-to-ram running 2.6.17.
>
> Well, I have one usb sticdk fried by regular use under linux (like --
> 5 minutes of regular use!) and another fried by my dad on windows. So
> these beasts are crap.
>
> > I am blaming hw, but does anybody know how I can get my data back?
>
> Probably not easily. Specialized shop might desolder flash chip and
> read it directly... or you may try swapping flash chip into
> 'not-yet-fried' stick...

Or there is (should be) a fuse?

Thanks!

--
Al