--- 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
>
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
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
38 matches
Mail list logo
