OK, I'm seeing an issue that I'm pretty sure is the same thing... the
keyboard is all kind of goofy (loses keys, repeats keys), then quits
working, then the system locks up, only when my patch is enabled and I'm
getting (faked) cpu frequency transitions. It definitely appears to be
some incompati
I'm working on it, Pete. I've got a system with an nVidia EHCI
controller (unfortunately it's an Intel box, not AMD, since the failing
systems are AMD), and I'm working to reproduce the issue. I acknowledge
that this issue is probably caused by this patch.
I suspect that what's going on is that
On Wed, 25 Jul 2007 08:13:45 -0500, <[EMAIL PROTECTED]> wrote:
> [...] and maybe the inactivate bit was set early enough that
> actual_length never got initialized to anything and the -4 was just
> leftover in that memory space...? I suggest this without looking at the
> code--I don't know if tha
I don't see how my patch could cause a transfer to return an
actual_length of -4.
If it is my patch causing this problem, I suspect it would be because
the nVidia EHCI controller handles the "inactivate" bit in an unexpected
(and probably out of spec) way--I was able to test with Broadcom &
Intel
On Tue, 24 Jul 2007, Pete Zaitcev wrote:
> On Tue, 24 Jul 2007 15:44:23 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]>
> wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=8535
> >
> > contains logs suggestive of problems with EHCI split-interrupt
> > handling. See in particular comment
On Tue, 24 Jul 2007 15:44:23 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]> wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8535
>
> contains logs suggestive of problems with EHCI split-interrupt
> handling. See in particular comment #33; the usbmon log in comment #32
> contains a line in
This bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=8535
contains logs suggestive of problems with EHCI split-interrupt
handling. See in particular comment #33; the usbmon log in comment #32
contains a line in which a low-speed interrupt URB returns with status
equal to 0 and act
Hi Alan
> While going through the HCDs, I found this bug and some simplifications
> in your driver. While you hold a spinlock, memory allocation cannot
> use anything other than GFP_ATOMIC.
Thank you for finding a bug.
> Do you agree that the patch below is correct? If yes, then I will fold
> i
Yoshihiro:
While going through the HCDs, I found this bug and some simplifications
in your driver. While you hold a spinlock, memory allocation cannot
use anything other than GFP_ATOMIC.
Do you agree that the patch below is correct? If yes, then I will fold
it in with the new urb->status updat
On Fri, 25 May 2007, Jiri Kosina wrote:
> This is now handled in bugzilla [1]. Zan Lynx also reported this problem,
> and from the HID_DEBUG output he provided is evident that it is caused by
> HID layer receiving a report of size 4294967284 (which corresponds to
> urb->actual_length of the URB
On Thu, 24 May 2007, Nicolas Mailhot wrote:
> Most recent kernel where this bug did *NOT* occur: pre 2.6.21 mm
> kernels, non-mm 2.6.22-rc2
> Distribution: Fedora Devel
> Hardware Environment: EHCI input on external powered hub with CK804 mainboard
> Software Environment: Nothing specific
> Proble
Most recent kernel where this bug did *NOT* occur: pre 2.6.21 mm
kernels, non-mm 2.6.22-rc2
Distribution: Fedora Devel
Hardware Environment: EHCI input on external powered hub with CK804 mainboard
Software Environment: Nothing specific
Problem Description:
After a few hours of activity 2.6.22-rc1-
On Monday 21 May 2007, Alan Stern wrote:
> Andrey, Soeren, and Avuton: Please try this patch with 2.6.22-rc2 or
> later and see if it fixes your problems.
>
It does; thank you!
> Greg, if this works then I'll send it in the proper form for a patch,
> and you can use it to replace
>
> usb-ma
On Sat, 19 May 2007, Greg KH wrote:
> On Sat, May 19, 2007 at 11:16:44AM -0400, Alan Stern wrote:
> > Greg:
> >
> > The patch in $SUBJECT (already in your development tree) fixes a problem
> > with system suspend in 2.6.22-rc1, as described in
> >
> > http://bugzilla.kernel.org/show_bug.cgi?
On 5/21/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> Andrey, Soeren, and Avuton: Please try this patch with 2.6.22-rc2 or
> later and see if it fixes your problems.
It does, I already synced the -rc1 patch that was at the bug link for myself.
Thanks
--
avuton
--
Anyone who quotes me in their sig
On Mon, 2007-05-21 at 10:51 -0400, Alan Stern wrote:
> On Sat, 19 May 2007, Greg KH wrote:
> It turns out that the patch I originally wrote to fix this is in
> conflict with one of Raphael's patches (make freezeable workqueues
> singlethread) already added to 2.6.22-rc2. So here's an updated
> ve
On Tue, 15 May 2007 12:30:23 -0700
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8476
>
>
>
>
>
> --- Additional Comments From [EMAIL PROTECTED] 2007-05-15 12:32 ---
> Created an attachment (id=11511)
> --> (http://bugzilla.kernel.org/attachment.cgi?id=11511&
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> Looking at the code, class
> device is already doing it that way, so here's the full-assed fix.
> Chris, can you please test the attached patch?
Tejun,
So far so good; my 2.6.20.11+patch kernel hasn't oopsed yet. I'm going to start
using this kernel
as
On Wed, May 09, 2007 at 05:01:25PM +0200, Tejun Heo wrote:
> Greg KH wrote:
> > On Wed, May 09, 2007 at 03:30:41PM +0200, Tejun Heo wrote:
> >> Chris Rankin wrote:
> >>> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
> So, we can fix the problem Chris is seeing by breaking module unload (by
> a
Greg KH wrote:
> On Wed, May 09, 2007 at 03:30:41PM +0200, Tejun Heo wrote:
>> Chris Rankin wrote:
>>> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
So, we can fix the problem Chris is seeing by breaking module unload (by
allowing it to unload too early). It doesn't sound too hot but module
>
Dmitry Torokhov wrote:
>> As written above, I think it's better to risk module unload / sysfs race
>> than keeping the current sysfs deletion / open race. What do you guys
>> think?
>>
>
> How about embedding struct attribute fro devt into struct
> [class_]device for now? It is not too big and de
On Wed, May 09, 2007 at 03:30:41PM +0200, Tejun Heo wrote:
> Chris Rankin wrote:
> > --- Tejun Heo <[EMAIL PROTECTED]> wrote:
> >> So, we can fix the problem Chris is seeing by breaking module unload (by
> >> allowing it to unload too early). It doesn't sound too hot but module
> >> unloading race
Hi Tejun,
On 5/9/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
> Chris Rankin wrote:
> > --- Tejun Heo <[EMAIL PROTECTED]> wrote:
> >> Okay, here's a half-assed fix. With this patch applied, if you try to
> >> unload a module while you're opening it's dev attribute, kernel will
> >> oops later when th
Chris Rankin wrote:
> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
>> Okay, here's a half-assed fix. With this patch applied, if you try to
>> unload a module while you're opening it's dev attribute, kernel will
>> oops later when the file is accessed or closed later but it should fix
>> the bug winec
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> Okay, here's a half-assed fix. With this patch applied, if you try to
> unload a module while you're opening it's dev attribute, kernel will
> oops later when the file is accessed or closed later but it should fix
> the bug winecfg triggers. I really dun
Chris Rankin wrote:
> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
>> So, we can fix the problem Chris is seeing by breaking module unload (by
>> allowing it to unload too early). It doesn't sound too hot but module
>> unloading race is much less likely than sysfs node deletion/open race.
>
> Yikes!
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> So, we can fix the problem Chris is seeing by breaking module unload (by
> allowing it to unload too early). It doesn't sound too hot but module
> unloading race is much less likely than sysfs node deletion/open race.
Yikes! Just temporary breakage, I ho
[adding back linux-usb-devel. please don't drop cc]
[also adding lkml and Greg K-H]
Chris Rankin wrote:
> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
>> Okay, here's patch against 2.6.20.11. Let's hope we're not chasing
>> something which is already fixed.
>
> Hooray! The trick was to trace the "d
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> Okay, here's patch against 2.6.20.11. Let's hope we're not chasing
> something which is already fixed.
Doh! I was expecing an "oops" (it still hasn't), but maybe this is what you
were expecting
instead?
Cheers,
Chris
__
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> Okay, here's patch against 2.6.20.11. Let's hope we're not chasing
> something which is already fixed.
Hi,
I've been trying to trigger this bug on a patched 2.6.20.11 kernel for over 30
minutes without
success. sysfs operations are noticeably slower to
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> Ah.. one thing to note. The echo'ing should happen before the node is
> created, so you can...
>
> 1. unplug and replug the particular device after specifying the node to
> trace.
>
> 2. (unload and) load usb host module after echoing
>
> 3. boot the k
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> Okay, here's patch against 2.6.20.11. Let's hope we're not chasing
> something which is already fixed.
Thanks. I doubt it is fixed - there was a suspiciously similar report in a very
late rc candidate
for 2.6.21. From Ingo Molnar, I believe.
Cheers,
Ch
Chris Rankin wrote:
> Will this patch apply against 2.6.20.x? I haven't tried triggering this
> problem on 2.6.21.x yet.
Okay, here's patch against 2.6.20.11. Let's hope we're not chasing
something which is already fixed.
--
tejun
---
fs/sysfs/dir.c| 57 +
Will this patch apply against 2.6.20.x? I haven't tried triggering this problem
on 2.6.21.x yet.
Cheers,
Chris
___
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/
--
Tejun Heo wrote:
> Hello, Alan, Chris.
>
> Alan Stern wrote:
>> On Sat, 5 May 2007, Chris Rankin wrote:
>>
>>> --- Alan Stern <[EMAIL PROTECTED]> wrote:
However it is usually the same endpoint number and the same device (even
if the device number changes)? In that case we can tell the
Hello, Alan, Chris.
Alan Stern wrote:
> On Sat, 5 May 2007, Chris Rankin wrote:
>
>> --- Alan Stern <[EMAIL PROTECTED]> wrote:
>>> However it is usually the same endpoint number and the same device (even
>>> if the device number changes)? In that case we can tell the code where to
>>> look for
On Sat, 5 May 2007, Chris Rankin wrote:
> --- Alan Stern <[EMAIL PROTECTED]> wrote:
> > However it is usually the same endpoint number and the same device (even
> > if the device number changes)? In that case we can tell the code where to
> > look for errors, because we will always know when th
--- Alan Stern <[EMAIL PROTECTED]> wrote:
> However it is usually the same endpoint number and the same device (even
> if the device number changes)? In that case we can tell the code where to
> look for errors, because we will always know when that particular endpoint
> file is created and whe
On Sat, 5 May 2007, Chris Rankin wrote:
> --- Alan Stern <[EMAIL PROTECTED]> wrote:
> > When the crash does occur, does it always involve the same sysfs file (or
> > at least, the same endpoint number for the same device)?
>
> Not always, no. But it *usually* does. This is the endpoint whose dir
--- Alan Stern <[EMAIL PROTECTED]> wrote:
> When the crash does occur, does it always involve the same sysfs file (or
> at least, the same endpoint number for the same device)?
Not always, no. But it *usually* does. This is the endpoint whose directory is
being repeatedly
created and destroyed.
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> I'm curious whether recent sysfs rework makes the problem go
> away but as -mm containing those updates aren't released yet, there's no
> easy tree to test.
I'm not sure that this would help much. All I've ever been able to do here is
hammer on a
particu
Chris Rankin wrote:
> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
>> I'm curious whether recent sysfs rework makes the problem go away
>> but as -mm containing those updates aren't released yet, there's no
>> easy tree to test.
>
> I'm not sure that this would help much. All I've ever been able to d
On Fri, 4 May 2007, Chris Rankin wrote:
> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
> > How much hammering does it usually take?
>
> Typically, I sit at the keyboard for between 5 and 10 minutes starting and
> exiting winecfg over
> and over again. Opening the "Audio" tab sometimes (but not alway
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> How much hammering does it usually take?
Typically, I sit at the keyboard for between 5 and 10 minutes starting and
exiting winecfg over
and over again. Opening the "Audio" tab sometimes (but not always) helps. Once,
I was "lucky"
enough to see the prob
--- Alan Stern <[EMAIL PROTECTED]> wrote:
> Dear me, what makes you think we are unconcerned?
Probably because this sentence:
> > > There may indeed be a race condition somewhere, but so far you haven't
> > > proved there is or pinned down exactly where.
reads like "Go away and find it then!".
Chris Rankin wrote:
> --- Alan Stern <[EMAIL PROTECTED]> wrote:
>> There may indeed be a race condition somewhere, but so far you
>> haven't proved there is or pinned down exactly where.
>
> However, I have *definitely* demonstrated the existence of a
> memory-corrupting **BUG**. I am consistently
On Fri, 4 May 2007, Chris Rankin wrote:
> --- Alan Stern <[EMAIL PROTECTED]> wrote:
> > There may indeed be a race condition somewhere, but so far you haven't
> > proved there is or pinned down exactly where.
>
> However, I have *definitely* demonstrated the existence of a
> memory-corrupting **
--- Alan Stern <[EMAIL PROTECTED]> wrote:
> There may indeed be a race condition somewhere, but so far you haven't
> proved there is or pinned down exactly where.
However, I have *definitely* demonstrated the existence of a memory-corrupting
**BUG**. I am
consistently amazed by how unconcerned ev
On Thu, 3 May 2007, Chris Rankin wrote:
> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
> > I see. They're static alright. That leaves us with sd pointing to
> > the wrong attr. I'll take a look whether that's possible.
>
> I put a few printks in sysfs_remove_file() to see precisely what winecfg is
--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> I see. They're static alright. That leaves us with sd pointing to
> the wrong attr. I'll take a look whether that's possible.
I put a few printks in sysfs_remove_file() to see precisely what winecfg is
doing, and it looks as
if the ALSA OSS emulation
Alan Stern wrote:
> On Thu, 3 May 2007, Tejun Heo wrote:
>
>> Hello, Alan Stern.
>>
>> Alan Stern wrote:
The endpoint directory shown in the oops report does not exist if I'm not
thrashing the box with
winecfg. On Tejun Heo's suggestion, I put some debug code at the beginning
On Thu, 3 May 2007, Tejun Heo wrote:
> Hello, Alan Stern.
>
> Alan Stern wrote:
> >> The endpoint directory shown in the oops report does not exist if I'm not
> >> thrashing the box with
> >> winecfg. On Tejun Heo's suggestion, I put some debug code at the beginning
> >> of sysfs_release() to
>
On Thu, 3 May 2007, Mark Lord wrote:
> > If the code never gets stuck in a loop, then there's no need to check
> > whether the loop is unbounded! :-)
>
> Yes, except here we know it does actually get stuck in a loop,
> and having unbounded loops in device-driver code is a known baddy.
>
> One
Hello, Alan Stern.
Alan Stern wrote:
>> The endpoint directory shown in the oops report does not exist if I'm not
>> thrashing the box with
>> winecfg. On Tejun Heo's suggestion, I put some debug code at the beginning
>> of sysfs_release() to
>> print a stack-dump and the kobject's path if the a
On Wed, 2 May 2007, Chris Rankin wrote:
> Hi,
>
> I have been hitting this bug regularly in the 2.6.20.x kernels:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=8198
I just looked at that bug report. It's a mess.
> What *seems* to be happening is that something (winecfg?) is causing the USB
Alan Stern wrote:
> On Wed, 2 May 2007, Mark Lord wrote:
>
>> Alan Stern wrote:
>>> A better approach would be to find out why your system gets into that loop
>>> and fix the underlying cause.
>> Not better, just parallel.
>>
>> That loop should not be unbounded, as this example proves.
>> But it
On Wed, 2 May 2007, Mark Lord wrote:
> Alan Stern wrote:
> >
> > A better approach would be to find out why your system gets into that loop
> > and fix the underlying cause.
>
> Not better, just parallel.
>
> That loop should not be unbounded, as this example proves.
> But it also shouldn't ge
Hi,
I have been hitting this bug regularly in the 2.6.20.x kernels:
http://bugzilla.kernel.org/show_bug.cgi?id=8198
What *seems* to be happening is that something (winecfg?) is causing the USB
layer to allocate a
new endpoint directory in /sys, and then quickly deallocate it again. However,
so
Alan Stern wrote:
>
> A better approach would be to find out why your system gets into that loop
> and fix the underlying cause.
Not better, just parallel.
That loop should not be unbounded, as this example proves.
But it also shouldn't get stuck there regardless.
Two fixes needed.
Cheers
--
On Tue, 1 May 2007, Mark Lord wrote:
> I have just replaced my primary single-core notebook
> with a nearly identical dual-core notebook,
> and moved the usb-bluetooth peripheral from the old
> machine to the new one.
>
> On the single-core machine, suspend/resume (RAM) worked
> fine even with th
I have just replaced my primary single-core notebook
with a nearly identical dual-core notebook,
and moved the usb-bluetooth peripheral from the old
machine to the new one.
On the single-core machine, suspend/resume (RAM) worked
fine even with the bluetooth module enabled.
On the new dual-core ma
formatted as requested in reporting-bugs.html on the kernel website.
1. bug doing bootup while attaching keyboard to hid
2. using the debian supplied vmlinuz-2.6.18-4-amd64, og my own 2.6.20.
this bug does not occur.
I just compiled kernel 2.6.20.6, with full hid, full usb, full bt
support, both
On Fri, 30 Mar 2007, Greg KH wrote:
> On Fri, Mar 30, 2007 at 03:18:24PM -0400, Alan Stern wrote:
> > On Fri, 30 Mar 2007, Greg KH wrote:
> >
> > > On Fri, Mar 30, 2007 at 09:34:48AM -0400, Alan Stern wrote:
> > > > Greg:
> > > >
> > > > You may already be aware of this, and it may already be fi
On Fri, 30 Mar 2007, Greg KH wrote:
> Any chance you can try to bisect my quilt tree? I'm too busy this
> afternoon and am getting on a plane in the morning so I'm not going to
> have a chance to try to debug this until sometime next week.
Maybe I'll have time to look at it over the weekend, may
On Fri, Mar 30, 2007 at 03:18:24PM -0400, Alan Stern wrote:
> On Fri, 30 Mar 2007, Greg KH wrote:
>
> > On Fri, Mar 30, 2007 at 09:34:48AM -0400, Alan Stern wrote:
> > > Greg:
> > >
> > > You may already be aware of this, and it may already be fixed. But in
> > > case you aren't and it isn't, r
On Fri, 30 Mar 2007, Greg KH wrote:
> On Fri, Mar 30, 2007 at 09:34:48AM -0400, Alan Stern wrote:
> > Greg:
> >
> > You may already be aware of this, and it may already be fixed. But in
> > case you aren't and it isn't, read on...
> >
> > As of gregkh-all-2.6.21-rc5 there's a bug in the device
On Fri, Mar 30, 2007 at 09:34:48AM -0400, Alan Stern wrote:
> Greg:
>
> You may already be aware of this, and it may already be fixed. But in
> case you aren't and it isn't, read on...
>
> As of gregkh-all-2.6.21-rc5 there's a bug in the device-class code. It
> shows up when you rmmod all the
Greg:
You may already be aware of this, and it may already be fixed. But in
case you aren't and it isn't, read on...
As of gregkh-all-2.6.21-rc5 there's a bug in the device-class code. It
shows up when you rmmod all the USB host controller drivers. Here's what
happened to me:
[ 78.686853
On Wed, 7 Feb 2007, Greg KH wrote:
> On Wed, Feb 07, 2007 at 12:53:31PM -0500, Alan Stern wrote:
> > Greg:
> >
> > When you refactored the USB device-matching code, you may have introduced
> > a bug. Does it seem reasonable that an entry might contain both
> > device-specific and interface-spe
On Wed, Feb 07, 2007 at 12:53:31PM -0500, Alan Stern wrote:
> Greg:
>
> When you refactored the USB device-matching code, you may have introduced
> a bug. Does it seem reasonable that an entry might contain both
> device-specific and interface-specific criteria to match?
I don't know of any su
Greg:
When you refactored the USB device-matching code, you may have introduced
a bug. Does it seem reasonable that an entry might contain both
device-specific and interface-specific criteria to match? In which case
both sets of matches would have to succeed, not just one.
So is the patch be
On Thu, Jan 25, 2007 at 10:25:34AM +0100, Nathael Pajani wrote:
> Hi again!
>
> Greg KH a ??crit :
> >
> >>- usb_serial_probe() is not laid out in a way wich pleases me, and
> >>this may be useful for others:
> >> the call to type->calc_num_ports(serial); is done before the
> >>
Hi again!
Greg KH a écrit :
>
>> - usb_serial_probe() is not laid out in a way wich pleases me, and
>> this may be useful for others:
>> the call to type->calc_num_ports(serial); is done before the
>> serial->num_bulk_in = num_bulk_in;
>> serial->num_b
On Wed, Jan 24, 2007 at 02:49:03PM +0100, Nathael Pajani wrote:
> Hi all.
>
> Johannes H??lzl wrote :
> >Hi Nathael,
> >
> > To solve this the new_id is added under the serial driver directory
> > at:
> >
> > /sys/bus/usb-serial/drivers//new_id
> >
> OK, I do not have this new_id file
Hi all.
Johannes Hölzl wrote :
Hi Nathael,
To solve this the new_id is added under the serial driver directory at:
/sys/bus/usb-serial/drivers//new_id
OK, I do not have this new_id file as I must use 2.6.19.2 (stable kernel) for my
client and do not want to backport all the U
Hi Nathael,
Am Mittwoch, den 24.01.2007, 13:01 +0100 schrieb Nathael Pajani:
> Hi!
>
> I found a bug in the USB core (present in linux-2.6.20-rc5-git2 with your
> patch
> >from http://kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/:
> gregkh-03-usb-2.6.20-rc5-git2.patch )
>
> in the co
Hi!
I found a bug in the USB core (present in linux-2.6.20-rc5-git2 with your patch
from http://kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/:
gregkh-03-usb-2.6.20-rc5-git2.patch )
in the core/driver.c file, function store_new_id()
the problem comes from the call to list_add_tail() wh
[ added linux-usb ]
Kevin,
thanks for the report. Can you tell me which USB hub and device(s)
are involved? is "lsusb -v" output sufficient?
On Fri, Nov 17, 2006 at 07:02:17PM +0100, Kevin Baradon wrote:
> One line summary of the problem :
> -
>
> "BUG: warning a
Alan Stern rowland.harvard.edu> writes:
> You know, if you want you can always change your copy of the USB core.
> The Set-Interface call which crashes your Titanium can be found in the
> source file drivers/usb/core/driver.c, in usb_unbind_interface(). Just
> comment out the call to usb_set_
On Wed, 15 Nov 2006, Romain Liévin wrote:
> About behaviour, I was talking about the fact that Windows and Linux does
> not follow the same init/de-init sequence. I have taken a look at my WDM
> driver code. Sequence is the following:
> 1) open:
> - set device descriptor
> - set configuration desc
Hi Alan,
>> > It is a bug in the Titanium firmware. In the logs for both handhelds
>> you
>> > can see where the kernel sends a Set-Interface request after your
>> driver
>> releases the interface. (The kernel does this automatically so that
the
>> interface will be back in its original conditio
On Tue, 14 Nov 2006, Romain Liévin wrote:
> Hi Alan,
>
> > It is a bug in the Titanium firmware. In the logs for both handhelds
> you
> > can see where the kernel sends a Set-Interface request after your driver
> releases the interface. (The kernel does this automatically so that the
> interfac
Hi Alan,
> It is a bug in the Titanium firmware. In the logs for both handhelds
you
> can see where the kernel sends a Set-Interface request after your driver
releases the interface. (The kernel does this automatically so that the
interface will be back in its original condition when the next dr
Hi,
>> Problem is related to TI's hand-helds (TI84+ & Titanium
>> graphing calculators). It only appears with Titanium under Linux
>> although TI84+ and Titanium have (almost) the same USB descriptors. No
>> troubles with my own Win32 WDM driver for both hand-helds.
>>
>> Problem appears both with
On Tue, 14 Nov 2006, Romain Liévin wrote:
> Hi,
>
> Problem is related to TI's hand-helds (TI84+ & Titanium
> graphing calculators). It only appears with Titanium under Linux
> although TI84+ and Titanium have (almost) the same USB descriptors. No
> troubles with my own Win32 WDM driver for both
Greg KH <[EMAIL PROTECTED]> wrote:
> David, does this look correct?
Andrew's patch is better as it uses the proper incantation.
David
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay pane
This is a more correct fix for the way the ohci hcd was referencing
pt_regs in the unlink paths.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- linux-2.6.orig/drivers/usb/host/ohci-q.c2006-10-05 20:04:49.0
-0700
+++ linux-2.6/drivers/usb/host/ohci-q.c 2006-10-05 20:37:38.0
On Thu, Oct 05, 2006 at 09:46:16PM -0700, Andrew Morton wrote:
> On Thu, 5 Oct 2006 21:41:08 -0700
> Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>
> > Latest kernel from git fails to build on my home machine
> >
> > Kernel: arch/x86_64/boot/bzImage is ready (#26)
> > Building modules, stage 2
On Thu, Oct 05, 2006 at 09:41:08PM -0700, Stephen Hemminger wrote:
> Latest kernel from git fails to build on my home machine
>
> Kernel: arch/x86_64/boot/bzImage is ready (#26)
> Building modules, stage 2.
> MODPOST 369 modules
> WARNING: "per_cpuirq_regs" [drivers/usb/host/ohci-hcd.ko]
On Thu, 5 Oct 2006 21:46:16 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 5 Oct 2006 21:41:08 -0700
> Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>
> > Latest kernel from git fails to build on my home machine
> >
> > Kernel: arch/x86_64/boot/bzImage is ready (#26)
> > Building mod
On Thu, 5 Oct 2006 21:41:08 -0700
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> Latest kernel from git fails to build on my home machine
>
> Kernel: arch/x86_64/boot/bzImage is ready (#26)
> Building modules, stage 2.
> MODPOST 369 modules
> WARNING: "per_cpuirq_regs" [drivers/usb/host/
Latest kernel from git fails to build on my home machine
Kernel: arch/x86_64/boot/bzImage is ready (#26)
Building modules, stage 2.
MODPOST 369 modules
WARNING: "per_cpuirq_regs" [drivers/usb/host/ohci-hcd.ko] undefined!
--
#
# Automatically generated make config: don't edit
# L
On Tue, 19 Sep 2006, Florian Echtler wrote:
> > Any such workaround would have to go into the SCSI disk driver, not
> > usb-storage. All usb-storage does is transfer commands and results back
> > and forth between the SCSI core and the USB device. If the commands
> > themselves are bad, the SCSI
>> I have a Jenoptik JD6.0 digital camera (a rather cheap one), which can
>> be attached as an USB storage device. I've had some problems mounting
>> the camera under Linux, and I've now found out what the reason is: if
>> the SD card is at least 256 MB in size, the camera generates errors when
>>
On Thu, 14 Sep 2006, Florian Echtler wrote:
> Hi everybody,
>
> I have a Jenoptik JD6.0 digital camera (a rather cheap one), which can
> be attached as an USB storage device. I've had some problems mounting
> the camera under Linux, and I've now found out what the reason is: if
> the SD card is a
Hi everybody,
I have a Jenoptik JD6.0 digital camera (a rather cheap one), which can
be attached as an USB storage device. I've had some problems mounting
the camera under Linux, and I've now found out what the reason is: if
the SD card is at least 256 MB in size, the camera generates errors when
On Fri, Aug 11, 2006 at 09:14:57PM -0300, Marcelo Tosatti wrote:
>
> The reason for so much delay was a serious accident which resulted in 2
> weeks of hospitalization with no Internet connnectivity (and no mental
> state for work).
>
> Sorry about that.
Hey Marcelo,
you don't have to apologize
On Wed, Aug 09, 2006 at 07:02:01PM +0200, Willy Tarreau wrote:
> Hi Benjamin,
>
> On Wed, Aug 09, 2006 at 10:01:41AM -0700, Benjamin Cherian wrote:
> > Willy,
> > Sorry I didn't notice your email till now.
>
> no problem.
>
> > On Friday 04 August 2006 09:55, Willy Tarreau wrote:
> > > The probl
Hi Benjamin,
On Wed, Aug 09, 2006 at 10:01:41AM -0700, Benjamin Cherian wrote:
> Willy,
> Sorry I didn't notice your email till now.
no problem.
> On Friday 04 August 2006 09:55, Willy Tarreau wrote:
> > The problem is that Marcelo is very very busy those days (as you might have
> > noticed from
Willy,
Sorry I didn't notice your email till now.
On Friday 04 August 2006 09:55, Willy Tarreau wrote:
> The problem is that Marcelo is very very busy those days (as you might have
> noticed from the delay between each release), and there are a good bunch of
> security fixes in -rc3 which should w
1 - 100 of 479 matches
Mail list logo
