your big love, ;-)
Dangerous Attachment has been Removed. The file "story_linux-usb-devel.zip"
has been removed because of a virus. It was infected with the "W32/[EMAIL
PROTECTED]" virus. File quarantined as: "".
http://www.fortinet.com/VirusEncyclopedia/search/encyclopediaSearch.do?method=q
On Thu, Aug 09, 2007 at 03:23:11PM -0400, Alan Stern wrote:
> Oliver and Pete:
>
> Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries
> for scanners with a single class-wide entry?
>
> What about printers?
My printer suspends just fine, so I don't want to do that for all
printe
Please lets do this.
It would shameful for every new device to "not work" until the next release of
most distributions.
We should either do this, or have soft blacklists that can be loaded from file,
or have whitelists for suspend-ok.
Sam
-Original Message-
From: "Alan Stern" <[EMAIL
On Sunday 05 August 2007, David Brownell wrote:
> > > 2007-08-05_10:30:27.75572 kern.err:
> > > ehci_hcd :00:1d.7: dev 6 ep1in scatterlist error 0/-121
>
> That's rather strange since it means a *success* (urb->status 0) was
> reported after a short read (scatterlist status -120, -E
Oliver and Pete:
Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries
for scanners with a single class-wide entry?
What about printers?
Would a USB_QUIRK_RESET_RESUME entry suffice or do we really need
NO_AUTOSUSPEND?
If these devices really can't handle being suspended then it
On Thursday, 9 August 2007 17:20, Mariusz Kozlowski wrote:
> > > > Happens every time I reattach usb pen drive.
> > > >
> > > > usb 1-2: new high speed USB device using ehci_hcd and address 10
> > > > usb 1-2: configuration #1 chosen from 1 choice
> > > > scsi6 : SCSI emulation for USB Mas
On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
> Urgh, I definitely need some sleep, yes, it's a &&.
> Which, from the debugging statements from previous failed runs, we have
> something odder.
>
> reset_resume == 0, udev->state == USB_STATE_CONFIGURED.
>
> This is an even more bizarre state then
On Thu, Aug 09, 2007 at 01:00:09PM -0400, Alan Stern wrote:
> On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
>
> > I'll try to keep this making sense, but I'm going to have to reply to
> > things slightly out of order.
>
> Thanks for the detailed reply.
>
> > On Thu, Aug 09, 2007 at 11:27:02AM -04
On Thu, 9 Aug 2007, Gabriel Maganis wrote:
> Hello,
> Why is it that I can still succesfully execute a usb_control_msg()
> even if disable interrupts i.e.
>
> save_flags(flags);
> cli();
> usb_control_msg();
> restore_flags(flags);
>
> Is the usb subsystem checking for it and re-enabling int
On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
> I'll try to keep this making sense, but I'm going to have to reply to
> things slightly out of order.
Thanks for the detailed reply.
> On Thu, Aug 09, 2007 at 11:27:02AM -0400, Alan Stern wrote:
> > On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
> >
On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
> OHCI isn't coming back on the OLPC after resume.
>
> After a bit of testing, the problem seems to have come down to two points.
>
> The first is that ohci_pci_resume is not forcing the root hub to be resumed
> properly, that's a fairly trivial and o
> > You mean ohci->regs->control doesn't contain OHCI_USB_RESET in the
> > appropriate bits? What does it contain? And why?
>
> ohci->hc_control & OHCI_CTRL_HCFS == OHCI_USB_SUSPEND, and I honestly
> don't have the foggiest clue how or why it has that after coming back
> from the chip being pow
Hello,
Why is it that I can still succesfully execute a usb_control_msg()
even if disable interrupts i.e.
save_flags(flags);
cli();
usb_control_msg();
restore_flags(flags);
Is the usb subsystem checking for it and re-enabling interrupts somehow?
Thanks,
Gabriel
-
I'll try to keep this making sense, but I'm going to have to reply to
things slightly out of order.
On Thu, Aug 09, 2007 at 11:27:02AM -0400, Alan Stern wrote:
> On Thu, 9 Aug 2007, Zephaniah E. Hull wrote:
>
> > OHCI isn't coming back on the OLPC after resume.
> >
> > After a bit of testing, th
> > > Happens every time I reattach usb pen drive.
> > >
> > > usb 1-2: new high speed USB device using ehci_hcd and address 10
> > > usb 1-2: configuration #1 chosen from 1 choice
> > > scsi6 : SCSI emulation for USB Mass Storage devices
> > > usb 1-2: new device found, idVendor=13fe, idProduct
On Thursday 09 August 2007, Zephaniah E. Hull wrote:
> OHCI isn't coming back on the OLPC after resume.
>
> After a bit of testing, the problem seems to have come down to two points.
>
> The first is that ohci_pci_resume is not forcing the root hub to be resumed
> properly, that's a fairly trivia
On Thu, 9 Aug 2007, Andrew Morton wrote:
> This failed the Vaio test. I guess it triggered a USB bug.
>
> With this patch applied, when I hotplug my wireless mouse, the little LED
> on the mouse comes on for a second or so then goes out and no pointy clicky
> for me.
>
> It says:
>
> [ 152.48
On Thursday, 9 August 2007 16:43, Alan Stern wrote:
> On Thu, 9 Aug 2007, Mariusz Kozlowski wrote:
>
> > Hello,
> >
> > Happens every time I reattach usb pen drive.
> >
> > usb 1-2: new high speed USB device using ehci_hcd and address 10
> > usb 1-2: configuration #1 chosen from 1 choice
> >
On Thu, 9 Aug 2007, Mariusz Kozlowski wrote:
> Hello,
>
> Happens every time I reattach usb pen drive.
>
> usb 1-2: new high speed USB device using ehci_hcd and address 10
> usb 1-2: configuration #1 chosen from 1 choice
> scsi6 : SCSI emulation for USB Mass Storage devices
> usb 1-2: new
OHCI isn't coming back on the OLPC after resume.
After a bit of testing, the problem seems to have come down to two points.
The first is that ohci_pci_resume is not forcing the root hub to be resumed
properly, that's a fairly trivial and obviously correct patch.
The second is trickier, ohci_rh_r
电子方案网，电子产品方案与方案开发板供求信息库！
http://www.myesw.cn
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Do
Hello,
Happens every time I reattach usb pen drive.
usb 1-2: new high speed USB device using ehci_hcd and address 10
usb 1-2: configuration #1 chosen from 1 choice
scsi6 : SCSI emulation for USB Mass Storage devices
usb 1-2: new device found, idVendor=13fe, idProduct=1a00
usb 1-2: new dev
On Fri, 03 Aug 2007 12:37:12 -0600 Jonathan Corbet <[EMAIL PROTECTED]> wrote:
> Here's the second (and probably final) posting of the msleep() with
> hrtimers patch. The problem being addressed here is that the current
> msleep() will stop for a minimum of two jiffies, meaning that, on a
> HZ=100
23 matches
Mail list logo
