RE: Linux 2.6.16-rc3

RE: Linux 2.6.16-rc3

[Brown, Len]

>> >- In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy 
>> >Mahajan has  another regression, but he's off collecting more info.
>> 
>> We're talking here about a system from 1999 where Windows 98
>> refuses to run in ACPI mode and instead runs in APM mode.
>
>If it worked before a change which was installed, it's a regression
>regardless of whether another OS tries to use ACPI on that system or
>not.  I don't understand how one can use that fact to label this as
>not a regression from Linux's perspective.

I don't think anybody claimed this isn't a regression for the 600X.
Sanjoy has done a wonderful job documenting that.

My point is that it that on the grand scale of bugs serious enough
to have an effect on the course of 2.6.16, this one doesn't qualify
unless the same issue is seen on other systems.

-Len

RE: Linux 2.6.16-rc3

[Brown, Len]

>> >- In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy 
>> >Mahajan has  another regression, but he's off collecting more info.
>> 
>> We're talking here about a system from 1999 where Windows 98
>> refuses to run in ACPI mode and instead runs in APM mode.
>
>If it worked before a change which was installed, it's a regression
>regardless of whether another OS tries to use ACPI on that system or
>not.  I don't understand how one can use that fact to label this as
>not a regression from Linux's perspective.

I don't think anybody claimed this isn't a regression for the 600X.
Sanjoy has done a wonderful job documenting that.

My point is that it that on the grand scale of bugs serious enough
to have an effect on the course of 2.6.16, this one doesn't qualify
unless the same issue is seen on other systems.

-Len

Re: Linux 2.6.16-rc3

[Andrew Morton]

"Brown, Len" <len.brown@intel.com> wrote:
>
> My point is that it that on the grand scale of bugs serious enough
>  to have an effect on the course of 2.6.16, this one doesn't qualify
>  unless the same issue is seen on other systems.

I think we can assume that it will be seen there.  2.6.16 is going into
distros and will have more exposure than 2.6.15, let alone 2.6.16-rcX.

Re: Linux 2.6.16-rc3

[Sanjoy Mahajan]

> I think we can assume that it will be seen there.  2.6.16 is going into
> distros and will have more exposure than 2.6.15, let alone
> 2.6.16-rcX.

A related point is that S3 sleep/wake problems are very difficult to
debug.  The bug is often not reproducible (I've had a few of those).
Or it happens early in the wakeup, when the serial console hasn't been
restored to a working state (at least on some machines, see bugzilla
#4270).  Or the system has bugs that prevents its going to sleep,
which also prevents any wakeup problems from being investigated.  

Or they happen to regular users, who give up and say 'my laptop cannot
go to sleep in Linux, oh well'.  Besides being inconvenient, it gives
Linux a bad name, especially when people nearby have iBooks and
PowerBooks running MacOS that sleep and wake in 2-3 seconds, including
restoring networking and wireless.

So there's value in chasing any S3 bugs that can be reproduced,
especially those affecting sleeping.

The TP 600X is indeed old, and perhaps the bug is caused by an
otherwise fine change uncovering a 600X hardware or firmware bug
(perhaps the point that comment #8 at bugzilla 5989 is getting at).
However, one of the beauties of Linux, and a nightmare for developers,
is that Linux works on all sorts of hardware.  I don't know whether
this bug should affect the 2.6.16 schedule.  But I think its worth
solving eventually, if only to point where it's clear that it's unique
to this model.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

Re: Linux 2.6.16-rc3

[Arjan van de Ven]

On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> "Brown, Len" <len.brown@intel.com> wrote:
> >
> > My point is that it that on the grand scale of bugs serious enough
> >  to have an effect on the course of 2.6.16, this one doesn't qualify
> >  unless the same issue is seen on other systems.
> 
> I think we can assume that it will be seen there.  2.6.16 is going into
> distros and will have more exposure than 2.6.15, 

2.6.15 went into distros as well, such as Fedora Core 4 ;)

Re: Linux 2.6.16-rc3

[Michal Jaegermann]

On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> > 
> > I think we can assume that it will be seen there.  2.6.16 is going into
> > distros and will have more exposure than 2.6.15, 
> 
> 2.6.15 went into distros as well, such as Fedora Core 4 ;)

And promptly broke laptop suspension.  See, for example:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180998

   Michal

Re: Linux 2.6.16-rc3

[Andrew Morton]

Michal Jaegermann <michal@harddata.com> wrote:
>
> On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> > On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> > > 
> > > I think we can assume that it will be seen there.  2.6.16 is going into
> > > distros and will have more exposure than 2.6.15, 
> > 
> > 2.6.15 went into distros as well, such as Fedora Core 4 ;)
> 
> And promptly broke laptop suspension.  See, for example:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180998
> 

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 developers?

<I have this vaguely unsettled feeling that distros must get more bug
reports than the usptream developers, yet we hear so little about it>

Re: Linux 2.6.16-rc3

[Lee Revell]

On Mon, 2006-02-13 at 20:08 -0700, Michal Jaegermann wrote:
> On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> > On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> > > 
> > > I think we can assume that it will be seen there.  2.6.16 is going into
> > > distros and will have more exposure than 2.6.15, 
> > 
> > 2.6.15 went into distros as well, such as Fedora Core 4 ;)
> 
> And promptly broke laptop suspension.  See, for example:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180998

It broke suspension on YOUR laptop - the bug report does not give a make
and model.  2.6.15 would not have shipped if it broke suspend on the
developers' laptops.

Lee

Re: Linux 2.6.16-rc3

[Dave Jones]

On Mon, Feb 13, 2006 at 07:28:38PM -0800, Andrew Morton wrote:
 > Michal Jaegermann <michal@harddata.com> wrote:
 > >
 > > On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
 > > > On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
 > > > > 
 > > > > I think we can assume that it will be seen there.  2.6.16 is going into
 > > > > distros and will have more exposure than 2.6.15, 
 > > > 
 > > > 2.6.15 went into distros as well, such as Fedora Core 4 ;)
 > > 
 > > And promptly broke laptop suspension.  See, for example:
 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180998
 > > 
 > 
 > 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?

Tiny changes.
- The icmp remote DoS fix.
- Dropped a patch that broke booting with 'quiet' bootparam
- the 'dm_crypt: zero key before freeing it' change

 > There seem to be several ACPI problems there.  Do we have a reliable means
 > of feeding such reports up into the (for example) acpi developers?
 > 
 > <I have this vaguely unsettled feeling that distros must get more bug
 > reports than the usptream developers, yet we hear so little about it>

I'd love more hours in the day to push more of them upstream, as
I bet would other vendors kernel maintainers.

Should anyone want to drink from the firehose that is 'redhat kernel bugzilla',
let me know, and I'll see if I can't get a fedora-kernel-bugs mailing
list or the like set up.

Some subsystem maintainers (ACPI for example) really help out here,
and add acpi-bugzilla@list.sourceforge.net to all the Fedora ACPI bugs.
(I believe that list actually gets bug reports from other distro bugzillas too)

(There's also a few 'meta-bugs' -- enter FCMETA_ACPI as a bug id
and you get a link to a dependancy tree showing all the ACPI bugs
reported. There's a bunch of those for various subsystems which
makes it a little easier to track, though again, it's time-consuming
just sorting through stuff).  Off the top of my head, theres one
for USB, SCSI, ACPI, ALSA, SATA (All with FCMETA_ prefix)
Some of them are a bit sparse due to lack of time & effort so far.
		
		Dave

Re: Linux 2.6.16-rc3

[Arjan van de Ven]

> <I have this vaguely unsettled feeling that distros must get more bug
> reports than the usptream developers, yet we hear so little about it>

the number of quality reports (eg enough information to do anything)
isn't that high; Dave is pretty good in sending the good ones on, it
often takes time though to get all the basic info..

Re: Linux 2.6.16-rc3

[Arjan van de Ven]

On Mon, 2006-02-13 at 20:08 -0700, Michal Jaegermann wrote:
> On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> > On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> > > 
> > > I think we can assume that it will be seen there.  2.6.16 is going into
> > > distros and will have more exposure than 2.6.15, 
> > 
> > 2.6.15 went into distros as well, such as Fedora Core 4 ;)
> 
> And promptly broke laptop suspension.  See, for example:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180998


fedora core 4 never really supported suspend in the first place tho..

Re: Linux 2.6.16-rc3

[Michal Jaegermann]

On Mon, Feb 13, 2006 at 07:28:38PM -0800, Andrew Morton wrote:
> Michal Jaegermann <michal@harddata.com> wrote:
> >
> > On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> > > On Mon, 2006-02-13 at 00:12 -0800, Andrew Morton wrote:
> > > > 
> > > > I think we can assume that it will be seen there.  2.6.16 is going into
> > > > distros and will have more exposure than 2.6.15, 
> > > 
> > > 2.6.15 went into distros as well, such as Fedora Core 4 ;)
> > 
> > And promptly broke laptop suspension.  See, for example:
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180998
> > 
> 
> That's suspend-to-disk, yes?

No.  That is an S3 suspension to RAM.  On the box in question it
generally worked for quite a long while now provided
'acpi_sleep=s3_bios' was passed to a kernel or video would be
unrestorable.  It is Acer Travelmate 230 with i845G video.

I did not try on that laptop suspend-to-disk so far (and in this
moment the damn thing is just plain broken).

   Michal

Re: Linux 2.6.16-rc3

[Michal Jaegermann]

On Mon, Feb 13, 2006 at 10:30:56PM -0500, Lee Revell wrote:
> On Mon, 2006-02-13 at 20:08 -0700, Michal Jaegermann wrote:
> > On Mon, Feb 13, 2006 at 09:57:48AM +0100, Arjan van de Ven wrote:
> > > 
> > > 2.6.15 went into distros as well, such as Fedora Core 4 ;)
> > 
> > And promptly broke laptop suspension.  See, for example:
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180998
> 
> It broke suspension on YOUR laptop - the bug report does not give a make
> and model.

Yes, indeed.  It is Acer Travelmate 230 and it is using
'acpi_sleep=s3_bios'.  The bug report noted though that the
following showed up:

Yenta O2: res at 0x94/0xD4: 00/ca
Yenta O2: enabling read prefetch/write burst
    ACPI-0265: *** Error: No installed handler for fixed event [00000002]

which was not something which I have seen before and indeed on
another laptop with the same kernel is absent.  But it was also not
there on 230 with earlier kernels.

BTW - this another laptop mentioned above, which happens to be Acer
Travelmate 740, is doing suspend/resume with 2.6.15 kernel, and no
'acpi_sleep=s3_bios' is needed,  but shortly after such cycle both
an external mouse and a touchpad go crazy and a mouse pointer
refuses to move in X from the left screen edge.  Not very useful and
so far I did not found a way to reset rodents.  No problems of that
sort before I will try to suspend.  Always something "interesting".
It is actually possible that in this case this is a problem with
"ATI Radeon Mobility M6" video driver which gets upset by suspend
(or some other pieces driving display) but I do not really know.

   Michal

Re: Linux 2.6.16-rc3

[Sanjoy Mahajan]

> I don't think anybody claimed this isn't a regression for the 600X.

I narrowed it further.  The short story is that this commit (diff below
sig) makes the second S3 sleep go into the endless loop, if the loaded
modules are exactly thermal, processor, intel_agp, and agpgart:

53f11d4ff8797bcceaf014e62bd39f16ce84baec is first bad commit
diff-tree 53f11d4ff8797bcceaf014e62bd39f16ce84baec (from 02b28a33aae93a3b53068e0858d62f8bcaef60a3)
Author: Len Brown <len.brown@intel.com>
Date:   Mon Dec 5 16:46:36 2005 -0500

    [ACPI] Enable Embedded Controller (EC) interrupt mode by default
    
    "ec_intr=0" reverts to polling
    "ec_burst=" no longer exists.
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    Acked-by: Luming Yu <luming.yu@intel.com>

:040000 040000 9eec66712c68ebe372b2fb2c8d78bdc99df942ab e7e62cd09983730aee468edd4ba1cce50786b7e5 M	Documentation
:040000 040000 6e7db46918f6124f64a11f6757560078a8a27519 aa8abb1023024902300cb2e7a5bf74acd8c579e8 M	drivers

If I boot with ec_intr=0, the second sleep works fine.

Here is the full story.  First I tried a system with the minimal set of
modules to boot and run X (S3 sleep-wake wrecks the VGA consoles, but X
restores fine with 'chvt 1; sleep 0.5 ; chvt 7' on wakeup).  So I
stopped every service and unloaded all modules possible, which left only
intel_agp and agpgart.  Then, for each of the usual loaded modules
(except for sound modules, which often has sleep-wake problems anyway),
I tried:

1. Load the module
2. S3 sleep-wake-sleep-wake
3. Unload the module

to see whether the second sleep went into the infinite loop (visible
across the console).  The one culprit I found was 'thermal' (which
brings in 'processor').  Other modules didn't trigger the problem.

Then I recompiled using a minimal config, with only networking (for X to
work) and the acpi modules, and maybe a few others that I couldn't
avoid, and retested to make sure 'thermal' still triggered the problem,
which it did.  I used this config, or one just like it for 2.6.15, as a
base for all other kernels in the bisection search, using the nearest
ancestor's .config and then
   yes '' | make oldconfig
to make the new .config

Eventually bisection converged to the commit above, and then I retested
that kernel with 'ec_intr=0'.

Is this a problem with the TP 600X hardware, in which case I'll just use
ec_intr=0 forever, or is there more software debugging (DSDT or related
to the diff)?  I can turn on gobs of ACPI debugging and send the useful
parts of the log file.

In the bisection, many kernels worked fine, meaning that the second S3
cycle returned and I could compile the next bisection kernel.  In doing
that I noticed another problem, that the fan would not turn on with some
of these good kernels even though the system was hot enough (plenty of
chance for it to turn on since the next compile heated up the CPU).  For
example, acpi -t showed

     Thermal 1: ok, 46.0 degrees C
     Thermal 2: active[0], 42.0 degrees C
     Thermal 3: ok, 31.0 degrees C
     Thermal 4: ok, 34.0 degrees C

but the fan was off.  

So whenever I had a good kernel (meaning taht S3 sleep-wake-sleep-wake
returned), I checked whether the fan would turn on, to collect data for
a separate bisection search.  However, the data seems inconsistent.  If
I feed the data to a fresh git bisect, it complains about one commit
being marked both good and bad.  So I'll ask on the git list about that
issue.

-Sanjoy

`A society of sheep must in time beget a government of wolves.'
   - Bertrand de Jouvenal


diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 5dffcfe..2ad64ef 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -452,6 +452,11 @@ running once the system is up.
 
 	eata=		[HW,SCSI]
 
+	ec_intr=	[HW,ACPI] ACPI Embedded Controller interrupt mode
+			Format: <int>
+			0: polling mode
+			non-0: interrupt mode (default)
+
 	eda=		[HW,PS2]
 
 	edb=		[HW,PS2]
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index bb3963b..d4366ad 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -73,7 +73,7 @@ static struct acpi_driver acpi_ec_driver
 	.class = ACPI_EC_CLASS,
 	.ids = ACPI_EC_HID,
 	.ops = {
-		.add = acpi_ec_poll_add,
+		.add = acpi_ec_intr_add,
 		.remove = acpi_ec_remove,
 		.start = acpi_ec_start,
 		.stop = acpi_ec_stop,
@@ -147,7 +147,7 @@ static union acpi_ec *ec_ecdt;
 
 /* External interfaces use first EC only, so remember */
 static struct acpi_device *first_ec;
-static int acpi_ec_poll_mode = EC_POLL;
+static int acpi_ec_poll_mode = EC_INTR;
 
 /* --------------------------------------------------------------------------
                              Transaction Management
@@ -1594,4 +1594,4 @@ static int __init acpi_ec_set_intr_mode(
 	return 0;
 }
 
-__setup("ec_burst=", acpi_ec_set_intr_mode);
+__setup("ec_intr=", acpi_ec_set_intr_mode);

Re: Linux 2.6.16-rc3

[Pavel Machek]

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 developers?
> 
> <I have this vaguely unsettled feeling that distros must get more bug
> reports than the usptream developers, yet we hear so little about it>

Its about 1:1 upstream:suse bugs for me... Unfortunately
suse bugs are often for old kernel...
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: Linux 2.6.16-rc3

[Ben Castricum]

> We still have some serious bugs, several of which are in 2.6.15 as well:
> [...]
> - "Ben Castricum" <lk@bencastricum.nl> reports that ppp has started
>  exhibiting mysterious failures (again).

I found the time to do some more testing, this time with the latest 
2.6.16-rc4 from git and still pppd version 2.4.1.

The problem was very easy to reproduce, within 10 minutes I appeared again. 
I could narrow the problem down to not being able to _send_ traffic. 
Ifconfig -a and tcpdump showed traffic coming in, but not going out. I tried 
stracing the relevant programs (I use pptp to connect to the dsl modem)

root@gateway:~# ps -ef | grep pp
root       870     1  0 16:47 ?        00:00:00 /usr/sbin/upnpd ppp0 eth1
root       329     1  0 16:45 ?        00:00:00 /usr/sbin/pptp pptp: call 
manager for 10.0.0.138
root       323   322  0 16:45 ?        00:00:14 /usr/sbin/pptp pptp: 
GRE-to-PPP gateway on /dev/ptmx
root       322     1  0 16:45 ?        00:00:00 /usr/sbin/pppd call adsl
root      3156  2941  0 17:15 pts/2    00:00:00 grep pp

root@gateway:~# strace -p 322
select(4, [0 3], NULL, [0 3], NULL <unfinished ...>

(nothing happening there)

root@gateway:~# strace -p 323
write(4, " \201\210\v\0\0\0\0\0\2\320X", 12) = 12
select(5, [0 4], NULL, NULL, NULL)      = 1 (in [4])
read(4, "E\0\0`\36P\0\0@/G\225\n\0\0\212\n\0\0\0010\1\210\v\0@\0"..., 8260) 
= 96
write(0, "\377\3\0!E\0\0< \211@\0(\6\27\336\310\256\260\215\325T"..., 64) = 
64
select(5, [0 4], NULL, NULL, {0, 500000}) = 1 (in [4], left {0, 488000})
read(4, "E\0\0T\36Q\0\0@/G\240\n\0\0\212\n\0\0\0010\1\210\v\000"..., 8260) = 
84
write(0, "\377\3\0!E\0\0000_E@\0w\6\320rRH\340\256\325T\313\304\20"..., 52) 
= 52
select(5, [0 4], NULL, NULL, {0, 0})    = 0 (Timeout)
write(4, " \201\210\v\0\0\0\0\0\2\320Z", 12) = 12
select(5, [0 4], NULL, NULL, NULL)      = 1 (in [4])
read(4, "E\0\0T\36R\0\0@/G\237\n\0\0\212\n\0\0\0010\1\210\v\000"..., 8260) = 
84
write(0, "\377\3\0!E\0\0000_F@\0w\6\320qRH\340\256\325T\313\304\20"..., 52) 
= 52
select(5, [0 4], NULL, NULL, {0, 500000}) = 1 (in [4], left {0, 472000})
read(4, "E\0\0T\36S\0\0@/G\236\n\0\0\212\n\0\0\0010\1\210\v\000"..., 8260) = 
84
write(0, "\377\3\0!E\0\0000\21\223@\0q\6\205\\P\313\200\364\325T"..., 52) = 
52
select(5, [0 4], NULL, NULL, {0, 0})    = 0 (Timeout)
write(4, " \201\210\v\0\0\0\0\0\2\320\\", 12) = 12
select(5, [0 4], NULL, NULL, NULL)      = 1 (in [4])
read(4, "E\0\0T\36T\0\0@/G\235\n\0\0\212\n\0\0\0010\1\210\v\000"..., 8260) = 
84
write(0, "\377\3\0!E\0\0000C\2@\0h\6\17\233\311\307UJ\325T\313\304"..., 52) 
= 52
select(5, [0 4], NULL, NULL, {0, 500000}) = 1 (in [4], left {0, 496000})
read(4, "E\0\0`\36U\0\0@/G\220\n\0\0\212\n\0\0\0010\1\210\v\0@\0"..., 8260) 
= 96
write(0, "\377\3\0!E\0\0<0e@\0003\6\4T\303\200\256i\325T\313\304"..., 64) = 
64
select(5, [0 4], NULL, NULL, {0, 0})    = 0 (Timeout)
write(4, " \201\210\v\0\0\0\0\0\2\320^", 12) = 12
select(5, [0 4], NULL, NULL, NULL)      = 1 (in [4])
read(4, "E\0\0d\36V\0\0@/G\213\n\0\0\212\n\0\0\0010\1\210\v\0D\0"..., 8260) 
= 100
write(0, "\377\3\0!E\0\0@:S\0\0003\6\203Y\311\32_\330\325T\313\304"..., 68) 
= 68
select(5, [0 4], NULL, NULL, {0, 500000}) = 1 (in [4], left {0, 484000})
read(4, "E\0\0`\36W\0\0@/G\216\n\0\0\212\n\0\0\0010\1\210\v\0@\0"..., 8260) 
= 96
write(0, "\377\3\0!E\0\0<\275\240@\0%\6\24\355\310\320\31E\325T\313"..., 64) 
= 64
select(5, [0 4], NULL, NULL, {0, 0})    = 0 (Timeout)
write(4, " \201\210\v\0\0\0\0\0\2\320`", 12) = 12
select(5, [0 4], NULL, NULL, NULL)      = 1 (in [4])
read(4, "E\0\0d\36X\0\0@/G\211\n\0\0\212\n\0\0\0010\1\210\v\0D\0"..., 8260) 
= 100
write(0, "\377\3\0!E\0\0@a\264\0\0003\6\250\345\311\374\22\t\325"..., 68) = 
68
select(5, [0 4], NULL, NULL, {0, 500000}) = 1 (in [4], left {0, 496000})
read(4, "E\0\0d\36Y\0\0@/G\210\n\0\0\212\n\0\0\0010\1\210\v\0D\0"..., 8260) 
= 100
write(0, "\377\3\0!E\0\0@j\217\0\0003\6\272\317\310\350\370W\325"..., 68) = 
68
select(5, [0 4], NULL, NULL, {0, 0})    = 0 (Timeout)
write(4, " \201\210\v\0\0\0\0\0\2\320b", 12) = 12
select(5, [0 4], NULL, NULL, NULL)      = 1 (in [4])
read(4, "E\0\0T\36Z\0\0@/G\227\n\0\0\212\n\0\0\0010\1\210\v\000"..., 8260) = 
84
write(0, "\377\3\0!E\0\0000\26\217@\0p\6\375o\310\251\215\6\325T"..., 52) = 
52
select(5, [0 4], NULL, NULL, {0, 500000}) = 1 (in [4], left {0, 440000})
read(4, "E\0\0T\36[\0\0@/G\226\n\0\0\212\n\0\0\0010\1\210\v\000"..., 8260) = 
84
write(0, "\377\3\0!E\0\0000\3672@\0o\6[-\310\264O\232\325T\313\304"..., 52) 
= 52
select(5, [0 4], NULL, NULL, {0, 0})    = 0 (Timeout)
write(4, " \201\210\v\0\0\0\0\0\2\320d", 12) = 12
select(5, [0 4], NULL, NULL, NULL <unfinished ...>

(and so on...)

root@gateway:~# strace -p 329
select(7, [3 4 6], [], NULL, NULL <unfinished ...>

nothing hapening here either.

checking the iptables setup (I flushed the rules before I started with 
troubleshooting):
root@gateway:~# iptables-save
# Generated by iptables-save v1.2.6a on Wed Feb 22 17:10:44 2006
*filter
:INPUT ACCEPT [6204:440626]
:FORWARD ACCEPT [8:284]
:OUTPUT ACCEPT [18978:2854072]
COMMIT
# Completed on Wed Feb 22 17:10:44 2006
# Generated by iptables-save v1.2.6a on Wed Feb 22 17:10:44 2006
*nat
:PREROUTING ACCEPT [44153:2316103]
:POSTROUTING ACCEPT [805:50699]
:OUTPUT ACCEPT [2308:153409]
COMMIT
# Completed on Wed Feb 22 17:10:44 2006

root@gateway:~# iptables-save
# Generated by iptables-save v1.2.6a on Wed Feb 22 17:10:48 2006
*filter
:INPUT ACCEPT [6721:478137]
:FORWARD ACCEPT [8:284]
:OUTPUT ACCEPT [20528:3083677]
COMMIT
# Completed on Wed Feb 22 17:10:48 2006
# Generated by iptables-save v1.2.6a on Wed Feb 22 17:10:48 2006
*nat
:PREROUTING ACCEPT [44241:2320941]
:POSTROUTING ACCEPT [806:50777]
:OUTPUT ACCEPT [2309:153487]
COMMIT
# Completed on Wed Feb 22 17:10:48 2006


Does this help anything?

Kind regards,
Ben 

Re: Linux 2.6.16-rc3

[Helge Hafting]

Andrew Morton wrote:

>We still have some serious bugs, several of which are in 2.6.15 as well:
>
[...]

>- Helge Hafting reports a usb printer regression - I don't know if that's
>  still live?
>  
>
I tried printing four pages of graphichs with 2.6.16-rc3-mm1
and it worked fine.  When I had the problem I couldn't even print
three, I had to print the 10 pages I needed one by one.

So I believe the situation has improved.

Helge Hafting

Re: Linux 2.6.16-rc3

[Helge Hafting]

Andrew Morton wrote:

>We still have some serious bugs, several of which are in 2.6.15 as well:
>
[...]

>- Helge Hafting reports a usb printer regression - I don't know if that's
>  still live?
>  
>
I tried printing four pages of graphichs with 2.6.16-rc3-mm1
and it worked fine.  When I had the problem I couldn't even print
three, I had to print the 10 pages I needed one by one.

So I believe the situation has improved.

Helge Hafting

Re: Linux 2.6.16-rc3

[Matthew Wilcox]

On Fri, Feb 17, 2006 at 06:12:04PM -0800, Roland Dreier wrote:
>  > +int execute_in_process_context(void (*fn)(void *data), void *data,
>  > +			       struct execute_work *ew)
>  > +{
>  > +	if (!in_interrupt()) {
>  > +		fn(data);
>  > +		return 0;
>  > +	}
> 
> Is testing in_interrupt() really sufficient to make this work?  I seem
> to remember that (at least) with CONFIG_PREEMPT disabled, there are
> contexts where it is not safe to sleep but where both in_interrupt()
> and in_atomic() still return 0.

That's correct -- in process context, with PREEMPT disabled and a spinlock
held, it's unsafe to call this function.  It works well for the SCSI
usage (where it's called either in interrupt context or in user
context with no spinlocks held), but it's not *always* safe.

I think this needs to be documented in the kerneldoc.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Re: Linux 2.6.16-rc3

[Roland Dreier]

 > +/**
 > + * execute_in_process_context - reliably execute the routine with user context
 > + * @fn:		the function to execute
 > + * @data:	data to pass to the function
 > + *
 > + * Executes the function immediately if process context is available,
 > + * otherwise schedules the function for delayed execution.
 > + *
 > + * Returns:	0 - function was executed
 > + *		1 - function was scheduled for execution
 > + */
 > +int execute_in_process_context(void (*fn)(void *data), void *data,
 > +			       struct execute_work *ew)
 > +{
 > +	if (!in_interrupt()) {
 > +		fn(data);
 > +		return 0;
 > +	}

Is testing in_interrupt() really sufficient to make this work?  I seem
to remember that (at least) with CONFIG_PREEMPT disabled, there are
contexts where it is not safe to sleep but where both in_interrupt()
and in_atomic() still return 0.

 - R.

Re: Linux 2.6.16-rc3

[Roland Dreier]

 > +/**
 > + * execute_in_process_context - reliably execute the routine with user context
 > + * @fn:		the function to execute
 > + * @data:	data to pass to the function
 > + *
 > + * Executes the function immediately if process context is available,
 > + * otherwise schedules the function for delayed execution.
 > + *
 > + * Returns:	0 - function was executed
 > + *		1 - function was scheduled for execution
 > + */
 > +int execute_in_process_context(void (*fn)(void *data), void *data,
 > +			       struct execute_work *ew)
 > +{
 > +	if (!in_interrupt()) {
 > +		fn(data);
 > +		return 0;
 > +	}

Is testing in_interrupt() really sufficient to make this work?  I seem
to remember that (at least) with CONFIG_PREEMPT disabled, there are
contexts where it is not safe to sleep but where both in_interrupt()
and in_atomic() still return 0.

 - R.

Re: Linux 2.6.16-rc3

[Greg KH]

On Fri, Feb 17, 2006 at 04:42:43PM -0800, James Bottomley wrote:
> On Thu, 2006-02-16 at 21:01 +0100, Jens Axboe wrote:
> > That's what I suggested in the first place as well. I still think it's a
> > good idea, fwiw :)
> 
> OK smarty pants ... some of us are a bit slower on the uptake.  How
> about this then.  It won't solve the target problem, but it will solve
> the device put.
> 
> James
> 
> [PATCH] add execute_in_process_context() API

I like it, nice job.

Acked-by: Greg Kroah-Hartma <gregkh@suse.de>

thanks,

greg k-h

Re: Linux 2.6.16-rc3

[Greg KH]

On Fri, Feb 17, 2006 at 04:42:43PM -0800, James Bottomley wrote:
> On Thu, 2006-02-16 at 21:01 +0100, Jens Axboe wrote:
> > That's what I suggested in the first place as well. I still think it's a
> > good idea, fwiw :)
> 
> OK smarty pants ... some of us are a bit slower on the uptake.  How
> about this then.  It won't solve the target problem, but it will solve
> the device put.
> 
> James
> 
> [PATCH] add execute_in_process_context() API

I like it, nice job.

Acked-by: Greg Kroah-Hartma <gregkh@suse.de>

thanks,

greg k-h

Re: Linux 2.6.16-rc3

[James Bottomley]

On Thu, 2006-02-16 at 21:01 +0100, Jens Axboe wrote:
> That's what I suggested in the first place as well. I still think it's a
> good idea, fwiw :)

OK smarty pants ... some of us are a bit slower on the uptake.  How
about this then.  It won't solve the target problem, but it will solve
the device put.

James

[PATCH] add execute_in_process_context() API

We have several points in the SCSI stack (primarily for our device
functions) where we need to guarantee process context, but (given the
place where the last reference was released) we cannot guarantee this.

This API gets around the issue by executing the function directly if
the caller has process context, but scheduling a workqueue to execute
in process context if the caller doesn't have it.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

Index: BUILD-2.6/include/linux/workqueue.h
===================================================================
--- BUILD-2.6.orig/include/linux/workqueue.h	2006-02-17 13:02:00.000000000 -0600
+++ BUILD-2.6/include/linux/workqueue.h	2006-02-17 17:57:52.000000000 -0600
@@ -20,6 +20,12 @@
 	struct timer_list timer;
 };
 
+struct execute_work {
+	struct work_struct work;
+	void (*fn)(void *);
+	void *data;
+};
+
 #define __WORK_INITIALIZER(n, f, d) {				\
         .entry	= { &(n).entry, &(n).entry },			\
 	.func = (f),						\
@@ -74,6 +80,8 @@
 void cancel_rearming_delayed_work(struct work_struct *work);
 void cancel_rearming_delayed_workqueue(struct workqueue_struct *,
 				       struct work_struct *);
+int execute_in_process_context(void (*fn)(void *), void *,
+			       struct execute_work *);
 
 /*
  * Kill off a pending schedule_delayed_work().  Note that the work callback
Index: BUILD-2.6/kernel/workqueue.c
===================================================================
--- BUILD-2.6.orig/kernel/workqueue.c	2006-02-17 13:02:01.000000000 -0600
+++ BUILD-2.6/kernel/workqueue.c	2006-02-17 18:00:15.000000000 -0600
@@ -27,6 +27,7 @@
 #include <linux/cpu.h>
 #include <linux/notifier.h>
 #include <linux/kthread.h>
+#include <linux/hardirq.h>
 
 /*
  * The per-CPU workqueue (if single thread, we always use the first
@@ -476,6 +477,45 @@
 }
 EXPORT_SYMBOL(cancel_rearming_delayed_work);
 
+static void execute_in_process_context_work(void *data)
+{
+	void (*fn)(void *data);
+	struct execute_work *ew = data;
+
+	fn = ew->fn;
+	data = ew->data;
+
+	fn(data);
+}
+
+/**
+ * execute_in_process_context - reliably execute the routine with user context
+ * @fn:		the function to execute
+ * @data:	data to pass to the function
+ *
+ * Executes the function immediately if process context is available,
+ * otherwise schedules the function for delayed execution.
+ *
+ * Returns:	0 - function was executed
+ *		1 - function was scheduled for execution
+ */
+int execute_in_process_context(void (*fn)(void *data), void *data,
+			       struct execute_work *ew)
+{
+	if (!in_interrupt()) {
+		fn(data);
+		return 0;
+	}
+
+	INIT_WORK(&ew->work, execute_in_process_context_work, ew);
+	ew->fn = fn;
+	ew->data = data;
+	schedule_work(&ew->work);
+
+	return 1;
+}
+EXPORT_SYMBOL_GPL(execute_in_process_context);
+
 int keventd_up(void)
 {
 	return keventd_wq != NULL;

Re: Linux 2.6.16-rc3

[James Bottomley]

On Thu, 2006-02-16 at 21:01 +0100, Jens Axboe wrote:
> That's what I suggested in the first place as well. I still think it's a
> good idea, fwiw :)

OK smarty pants ... some of us are a bit slower on the uptake.  How
about this then.  It won't solve the target problem, but it will solve
the device put.

James

[PATCH] add execute_in_process_context() API

We have several points in the SCSI stack (primarily for our device
functions) where we need to guarantee process context, but (given the
place where the last reference was released) we cannot guarantee this.

This API gets around the issue by executing the function directly if
the caller has process context, but scheduling a workqueue to execute
in process context if the caller doesn't have it.

Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

Index: BUILD-2.6/include/linux/workqueue.h
===================================================================
--- BUILD-2.6.orig/include/linux/workqueue.h	2006-02-17 13:02:00.000000000 -0600
+++ BUILD-2.6/include/linux/workqueue.h	2006-02-17 17:57:52.000000000 -0600
@@ -20,6 +20,12 @@
 	struct timer_list timer;
 };
 
+struct execute_work {
+	struct work_struct work;
+	void (*fn)(void *);
+	void *data;
+};
+
 #define __WORK_INITIALIZER(n, f, d) {				\
         .entry	= { &(n).entry, &(n).entry },			\
 	.func = (f),						\
@@ -74,6 +80,8 @@
 void cancel_rearming_delayed_work(struct work_struct *work);
 void cancel_rearming_delayed_workqueue(struct workqueue_struct *,
 				       struct work_struct *);
+int execute_in_process_context(void (*fn)(void *), void *,
+			       struct execute_work *);
 
 /*
  * Kill off a pending schedule_delayed_work().  Note that the work callback
Index: BUILD-2.6/kernel/workqueue.c
===================================================================
--- BUILD-2.6.orig/kernel/workqueue.c	2006-02-17 13:02:01.000000000 -0600
+++ BUILD-2.6/kernel/workqueue.c	2006-02-17 18:00:15.000000000 -0600
@@ -27,6 +27,7 @@
 #include <linux/cpu.h>
 #include <linux/notifier.h>
 #include <linux/kthread.h>
+#include <linux/hardirq.h>
 
 /*
  * The per-CPU workqueue (if single thread, we always use the first
@@ -476,6 +477,45 @@
 }
 EXPORT_SYMBOL(cancel_rearming_delayed_work);
 
+static void execute_in_process_context_work(void *data)
+{
+	void (*fn)(void *data);
+	struct execute_work *ew = data;
+
+	fn = ew->fn;
+	data = ew->data;
+
+	fn(data);
+}
+
+/**
+ * execute_in_process_context - reliably execute the routine with user context
+ * @fn:		the function to execute
+ * @data:	data to pass to the function
+ *
+ * Executes the function immediately if process context is available,
+ * otherwise schedules the function for delayed execution.
+ *
+ * Returns:	0 - function was executed
+ *		1 - function was scheduled for execution
+ */
+int execute_in_process_context(void (*fn)(void *data), void *data,
+			       struct execute_work *ew)
+{
+	if (!in_interrupt()) {
+		fn(data);
+		return 0;
+	}
+
+	INIT_WORK(&ew->work, execute_in_process_context_work, ew);
+	ew->fn = fn;
+	ew->data = data;
+	schedule_work(&ew->work);
+
+	return 1;
+}
+EXPORT_SYMBOL_GPL(execute_in_process_context);
+
 int keventd_up(void)
 {
 	return keventd_wq != NULL;

Re: Linux 2.6.16-rc3

[Jens Axboe]

On Thu, Feb 16 2006, James Bottomley wrote:
> On Thu, 2006-02-16 at 18:18 +0000, Russell King wrote:
> > Maybe implementing it as a helper function would be the best and
> > simplest solution?
> > 
> > static void scsi_release(struct device *dev)
> > {
> > 	schedule_release_process(dev, scsi_release_process);
> > }
> > 
> > where schedule_release_process() contains more or less what I posted
> > in the previous mailing.
> 
> That's almost exactly the execute_in_process_context() API that began
> this discussion (and which Andi NAK'd).  However, it could possibly be
> resurrected with the proviso that the caller has to feed in the
> workqueue memory.  How would people feel about that?

That's what I suggested in the first place as well. I still think it's a
good idea, fwiw :)

-- 
Jens Axboe

Re: Linux 2.6.16-rc3

[Jens Axboe]

On Thu, Feb 16 2006, James Bottomley wrote:
> On Thu, 2006-02-16 at 18:18 +0000, Russell King wrote:
> > Maybe implementing it as a helper function would be the best and
> > simplest solution?
> > 
> > static void scsi_release(struct device *dev)
> > {
> > 	schedule_release_process(dev, scsi_release_process);
> > }
> > 
> > where schedule_release_process() contains more or less what I posted
> > in the previous mailing.
> 
> That's almost exactly the execute_in_process_context() API that began
> this discussion (and which Andi NAK'd).  However, it could possibly be
> resurrected with the proviso that the caller has to feed in the
> workqueue memory.  How would people feel about that?

That's what I suggested in the first place as well. I still think it's a
good idea, fwiw :)

-- 
Jens Axboe

Re: Linux 2.6.16-rc3

[James Bottomley]

On Thu, 2006-02-16 at 18:18 +0000, Russell King wrote:
> Maybe implementing it as a helper function would be the best and
> simplest solution?
> 
> static void scsi_release(struct device *dev)
> {
> 	schedule_release_process(dev, scsi_release_process);
> }
> 
> where schedule_release_process() contains more or less what I posted
> in the previous mailing.

That's almost exactly the execute_in_process_context() API that began
this discussion (and which Andi NAK'd).  However, it could possibly be
resurrected with the proviso that the caller has to feed in the
workqueue memory.  How would people feel about that?

James

Re: Linux 2.6.16-rc3

[James Bottomley]

On Thu, 2006-02-16 at 18:18 +0000, Russell King wrote:
> Maybe implementing it as a helper function would be the best and
> simplest solution?
> 
> static void scsi_release(struct device *dev)
> {
> 	schedule_release_process(dev, scsi_release_process);
> }
> 
> where schedule_release_process() contains more or less what I posted
> in the previous mailing.

That's almost exactly the execute_in_process_context() API that began
this discussion (and which Andi NAK'd).  However, it could possibly be
resurrected with the proviso that the caller has to feed in the
workqueue memory.  How would people feel about that?

James

Re: Linux 2.6.16-rc3

[Russell King]

On Thu, Feb 16, 2006 at 10:14:31AM -0800, James Bottomley wrote:
> On Thu, 2006-02-16 at 18:09 +0000, Russell King wrote:
> > where scsi_release() is the function called by the device model on the
> > last put of a scsi device.
> > 
> > I guess is more or less what you're trying to do invasively via the
> > driver model.
> 
> Yes ... except I think more than just SCSI has the problem (and we
> actually have it in more than one release function) so it seems like a
> good candidate for a general abstraction.

Maybe implementing it as a helper function would be the best and
simplest solution?

static void scsi_release(struct device *dev)
{
	schedule_release_process(dev, scsi_release_process);
}

where schedule_release_process() contains more or less what I posted
in the previous mailing.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Linux 2.6.16-rc3

[Russell King]

On Thu, Feb 16, 2006 at 10:14:31AM -0800, James Bottomley wrote:
> On Thu, 2006-02-16 at 18:09 +0000, Russell King wrote:
> > where scsi_release() is the function called by the device model on the
> > last put of a scsi device.
> > 
> > I guess is more or less what you're trying to do invasively via the
> > driver model.
> 
> Yes ... except I think more than just SCSI has the problem (and we
> actually have it in more than one release function) so it seems like a
> good candidate for a general abstraction.

Maybe implementing it as a helper function would be the best and
simplest solution?

static void scsi_release(struct device *dev)
{
	schedule_release_process(dev, scsi_release_process);
}

where schedule_release_process() contains more or less what I posted
in the previous mailing.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Linux 2.6.16-rc3

[James Bottomley]

On Thu, 2006-02-16 at 18:09 +0000, Russell King wrote:
> where scsi_release() is the function called by the device model on the
> last put of a scsi device.
> 
> I guess is more or less what you're trying to do invasively via the
> driver model.

Yes ... except I think more than just SCSI has the problem (and we
actually have it in more than one release function) so it seems like a
good candidate for a general abstraction.

James

Re: Linux 2.6.16-rc3

[James Bottomley]

On Thu, 2006-02-16 at 18:09 +0000, Russell King wrote:
> where scsi_release() is the function called by the device model on the
> last put of a scsi device.
> 
> I guess is more or less what you're trying to do invasively via the
> driver model.

Yes ... except I think more than just SCSI has the problem (and we
actually have it in more than one release function) so it seems like a
good candidate for a general abstraction.

James

Re: Linux 2.6.16-rc3

[Russell King]

On Thu, Feb 16, 2006 at 09:57:32AM -0800, James Bottomley wrote:
> On Thu, 2006-02-16 at 17:12 +0000, Russell King wrote:
> > This is probably an idiotic question, but if there's something in the
> > scsi release handler can't be called in non-process context, why can't
> > scsi queue up the release processing via the work API itself, rather
> > than having to have this additional code and complexity for everyone?
> 
> It's because, in order to get a guaranteed single allocation for the
> workqueue to execute in user context, I need to know when the release
> will be called.  The only way to do that is to add the execute in
> process context directly to kref_put.

Is there something in the driver model which would prevent something
like this?

static void scsi_release_process(void *p)
{
	struct my_work *work = p;
	struct device *dev = work->dev;

	/* destroy dev */

	kfree(work);
}

static void scsi_release(struct device *dev)
{
	struct my_work *work;

	work = kmalloc(sizeof(struct my_work), GFP_ATOMIC);
	if (work) {
		INIT_WORK(&work->work, scsi_release_process, work);
		work->dev = dev;
		schedule_work(&work->work);
	} else {
		printk(KERN_ERR ...);
	}
}

where scsi_release() is the function called by the device model on the
last put of a scsi device.

I guess is more or less what you're trying to do invasively via the
driver model.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Linux 2.6.16-rc3

[Russell King]

On Thu, Feb 16, 2006 at 09:57:32AM -0800, James Bottomley wrote:
> On Thu, 2006-02-16 at 17:12 +0000, Russell King wrote:
> > This is probably an idiotic question, but if there's something in the
> > scsi release handler can't be called in non-process context, why can't
> > scsi queue up the release processing via the work API itself, rather
> > than having to have this additional code and complexity for everyone?
> 
> It's because, in order to get a guaranteed single allocation for the
> workqueue to execute in user context, I need to know when the release
> will be called.  The only way to do that is to add the execute in
> process context directly to kref_put.

Is there something in the driver model which would prevent something
like this?

static void scsi_release_process(void *p)
{
	struct my_work *work = p;
	struct device *dev = work->dev;

	/* destroy dev */

	kfree(work);
}

static void scsi_release(struct device *dev)
{
	struct my_work *work;

	work = kmalloc(sizeof(struct my_work), GFP_ATOMIC);
	if (work) {
		INIT_WORK(&work->work, scsi_release_process, work);
		work->dev = dev;
		schedule_work(&work->work);
	} else {
		printk(KERN_ERR ...);
	}
}

where scsi_release() is the function called by the device model on the
last put of a scsi device.

I guess is more or less what you're trying to do invasively via the
driver model.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Linux 2.6.16-rc3

[James Bottomley]

On Thu, 2006-02-16 at 17:12 +0000, Russell King wrote:
> This is probably an idiotic question, but if there's something in the
> scsi release handler can't be called in non-process context, why can't
> scsi queue up the release processing via the work API itself, rather
> than having to have this additional code and complexity for everyone?

It's because, in order to get a guaranteed single allocation for the
workqueue to execute in user context, I need to know when the release
will be called.  The only way to do that is to add the execute in
process context directly to kref_put.

James

Re: Linux 2.6.16-rc3

[James Bottomley]

On Thu, 2006-02-16 at 17:12 +0000, Russell King wrote:
> This is probably an idiotic question, but if there's something in the
> scsi release handler can't be called in non-process context, why can't
> scsi queue up the release processing via the work API itself, rather
> than having to have this additional code and complexity for everyone?

It's because, in order to get a guaranteed single allocation for the
workqueue to execute in user context, I need to know when the release
will be called.  The only way to do that is to add the execute in
process context directly to kref_put.

James

Re: Linux 2.6.16-rc3

[Stefan Richter]

Russell King wrote:
> On Wed, Feb 15, 2006 at 08:56:00PM -0500, James Bottomley wrote:
[...]
>>OK, this is what I'm proposing as the device model fix.  What it does is
>>thread context checking APIs throughout the device subsystem.  SCSI can
>>then use it simply via device_put_process_context().
[...]
>>Since this is planned for post 2.6.16, we have plenty of time to argue
>>about it.
> 
> This is probably an idiotic question, but if there's something in the
> scsi release handler can't be called in non-process context, why can't
> scsi queue up the release processing via the work API itself, rather
> than having to have this additional code and complexity for everyone?

Moreover, why are SCSI release handlers called in non-process context in 
the first place? IMO the fix should be to make sure that SCSI release 
handlers are always called from process context --- by the respective 
layers which manage physical devices, i.e. one or more layers beneath 
SCSI core.
-- 
Stefan Richter
-=====-=-==- --=- =----
http://arcgraph.de/sr/

Re: Linux 2.6.16-rc3

[Stefan Richter]

Russell King wrote:
> On Wed, Feb 15, 2006 at 08:56:00PM -0500, James Bottomley wrote:
[...]
>>OK, this is what I'm proposing as the device model fix.  What it does is
>>thread context checking APIs throughout the device subsystem.  SCSI can
>>then use it simply via device_put_process_context().
[...]
>>Since this is planned for post 2.6.16, we have plenty of time to argue
>>about it.
> 
> This is probably an idiotic question, but if there's something in the
> scsi release handler can't be called in non-process context, why can't
> scsi queue up the release processing via the work API itself, rather
> than having to have this additional code and complexity for everyone?

Moreover, why are SCSI release handlers called in non-process context in 
the first place? IMO the fix should be to make sure that SCSI release 
handlers are always called from process context --- by the respective 
layers which manage physical devices, i.e. one or more layers beneath 
SCSI core.
-- 
Stefan Richter
-=====-=-==- --=- =----
http://arcgraph.de/sr/

Re: Linux 2.6.16-rc3

[Russell King]

On Wed, Feb 15, 2006 at 08:56:00PM -0500, James Bottomley wrote:
> On Tue, 2006-02-14 at 10:34 -0600, James Bottomley wrote:
> > Well, I can't solve the problem that it requires memory allocation from
> > IRQ context to operate.  Based on that, it's an unsafe interface.  I'm
> > going to put it inside SCSI for 2.6.16, since it's better than what we
> > have now, but I don't think we can export it globally.
> 
> OK, this is what I'm proposing as the device model fix.  What it does is
> thread context checking APIs throughout the device subsystem.  SCSI can
> then use it simply via device_put_process_context().  Since we have to
> supply the kref_work; I'd plan to do that as an additional element in
> struct scsi_device.
> 
> This, by itself, won't solve the SCSI target problem, but I plan to fix
> that via a device model addition which would have target alloc waiting
> around for any deleted targets to disappear.
> 
> Since this is planned for post 2.6.16, we have plenty of time to argue
> about it.

This is probably an idiotic question, but if there's something in the
scsi release handler can't be called in non-process context, why can't
scsi queue up the release processing via the work API itself, rather
than having to have this additional code and complexity for everyone?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Linux 2.6.16-rc3

[Russell King]

On Wed, Feb 15, 2006 at 08:56:00PM -0500, James Bottomley wrote:
> On Tue, 2006-02-14 at 10:34 -0600, James Bottomley wrote:
> > Well, I can't solve the problem that it requires memory allocation from
> > IRQ context to operate.  Based on that, it's an unsafe interface.  I'm
> > going to put it inside SCSI for 2.6.16, since it's better than what we
> > have now, but I don't think we can export it globally.
> 
> OK, this is what I'm proposing as the device model fix.  What it does is
> thread context checking APIs throughout the device subsystem.  SCSI can
> then use it simply via device_put_process_context().  Since we have to
> supply the kref_work; I'd plan to do that as an additional element in
> struct scsi_device.
> 
> This, by itself, won't solve the SCSI target problem, but I plan to fix
> that via a device model addition which would have target alloc waiting
> around for any deleted targets to disappear.
> 
> Since this is planned for post 2.6.16, we have plenty of time to argue
> about it.

This is probably an idiotic question, but if there's something in the
scsi release handler can't be called in non-process context, why can't
scsi queue up the release processing via the work API itself, rather
than having to have this additional code and complexity for everyone?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Linux 2.6.16-rc3

[James Bottomley]

On Tue, 2006-02-14 at 10:34 -0600, James Bottomley wrote:
> Well, I can't solve the problem that it requires memory allocation from
> IRQ context to operate.  Based on that, it's an unsafe interface.  I'm
> going to put it inside SCSI for 2.6.16, since it's better than what we
> have now, but I don't think we can export it globally.

OK, this is what I'm proposing as the device model fix.  What it does is
thread context checking APIs throughout the device subsystem.  SCSI can
then use it simply via device_put_process_context().  Since we have to
supply the kref_work; I'd plan to do that as an additional element in
struct scsi_device.

This, by itself, won't solve the SCSI target problem, but I plan to fix
that via a device model addition which would have target alloc waiting
around for any deleted targets to disappear.

Since this is planned for post 2.6.16, we have plenty of time to argue
about it.

James

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 6b355bd..4ae42de 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -338,10 +338,10 @@ struct device * get_device(struct device
  *	put_device - decrement reference count.
  *	@dev:	device in question.
  */
-void put_device(struct device * dev)
+void put_device_process_context(struct device * dev, struct kref_work *work)
 {
 	if (dev)
-		kobject_put(&dev->kobj);
+	  kobject_put_process_context(&dev->kobj, work);
 }
 
 
@@ -445,7 +445,7 @@ EXPORT_SYMBOL_GPL(device_register);
 EXPORT_SYMBOL_GPL(device_del);
 EXPORT_SYMBOL_GPL(device_unregister);
 EXPORT_SYMBOL_GPL(get_device);
-EXPORT_SYMBOL_GPL(put_device);
+EXPORT_SYMBOL_GPL(put_device_process_context);
 
 EXPORT_SYMBOL_GPL(device_create_file);
 EXPORT_SYMBOL_GPL(device_remove_file);
diff --git a/include/linux/device.h b/include/linux/device.h
index 58df18d..ac9d457 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -396,7 +396,13 @@ extern int (*platform_notify_remove)(str
  *
  */
 extern struct device * get_device(struct device * dev);
-extern void put_device(struct device * dev);
+extern void put_device_process_context(struct device * dev,
+				       struct kref_work *work);
+static inline void put_device(struct device *dev)
+{
+	put_device_process_context(dev, NULL);
+}
+						  
 
 
 /* drivers/base/power.c */
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index 2a8d8da..d079fea 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -76,7 +76,12 @@ extern int kobject_register(struct kobje
 extern void kobject_unregister(struct kobject *);
 
 extern struct kobject * kobject_get(struct kobject *);
-extern void kobject_put(struct kobject *);
+extern void kobject_put_process_context(struct kobject *, struct kref_work *);
+
+static inline void kobject_put(struct kobject *kobj)
+{
+	kobject_put_process_context(kobj, NULL);
+}
 
 extern char * kobject_get_path(struct kobject *, gfp_t);
 
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 6fee353..16b15db 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -18,15 +18,29 @@
 #ifdef __KERNEL__
 
 #include <linux/types.h>
+#include <linux/workqueue.h>
 #include <asm/atomic.h>
 
 struct kref {
 	atomic_t refcount;
 };
 
+struct kref_work {
+	struct work_struct work;
+	struct kref *kref;
+	void (*release)(struct kref *kref);
+};
+
 void kref_init(struct kref *kref);
 void kref_get(struct kref *kref);
-int kref_put(struct kref *kref, void (*release) (struct kref *kref));
+int kref_put_process_context(struct kref *kref,
+			     void (*release) (struct kref *kref),
+			     struct kref_work *work);
+static inline int kref_put(struct kref *kref,
+			   void (*release) (struct kref *kref))
+{
+	return kref_put_process_context(kref, release, NULL);
+}
 
 #endif /* __KERNEL__ */
 #endif /* _KREF_H_ */
diff --git a/lib/kobject.c b/lib/kobject.c
index efe67fa..6b80c54 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -372,10 +372,10 @@ static void kobject_release(struct kref 
  *
  *	Decrement the refcount, and if 0, call kobject_cleanup().
  */
-void kobject_put(struct kobject * kobj)
+void kobject_put_process_context(struct kobject * kobj, struct kref_work *work)
 {
 	if (kobj)
-		kref_put(&kobj->kref, kobject_release);
+		kref_put_process_context(&kobj->kref, kobject_release, work);
 }
 
 
@@ -537,7 +537,7 @@ EXPORT_SYMBOL(kobject_init);
 EXPORT_SYMBOL(kobject_register);
 EXPORT_SYMBOL(kobject_unregister);
 EXPORT_SYMBOL(kobject_get);
-EXPORT_SYMBOL(kobject_put);
+EXPORT_SYMBOL(kobject_put_process_context);
 EXPORT_SYMBOL(kobject_add);
 EXPORT_SYMBOL(kobject_del);
 
diff --git a/lib/kref.c b/lib/kref.c
index 0d07cc3..66231cf 100644
--- a/lib/kref.c
+++ b/lib/kref.c
@@ -13,6 +13,7 @@
 
 #include <linux/kref.h>
 #include <linux/module.h>
+#include <linux/hardirq.h>
 
 /**
  * kref_init - initialize object.
@@ -33,27 +34,47 @@ void kref_get(struct kref *kref)
 	atomic_inc(&kref->refcount);
 }
 
+static void kref_release_process_context(void *data)
+{
+	struct kref_work *work = data;
+
+	work->release(work->kref);
+}
+
 /**
- * kref_put - decrement refcount for object.
+ * kref_put_user - decrement refcount for object and put in user context
  * @kref: object.
  * @release: pointer to the function that will clean up the object when the
  *	     last reference to the object is released.
  *	     This pointer is required, and it is not acceptable to pass kfree
  *	     in as this function.
+ * @work:    pointer to a kref_work used to take the release through user
+ *	     context (may be null)
  *
- * Decrement the refcount, and if 0, call release().
+ * Decrement the refcount, and if 0, call release().  If work is not null
+ * execute release via schedule_work if not in process context.
  * Return 1 if the object was removed, otherwise return 0.  Beware, if this
  * function returns 0, you still can not count on the kref from remaining in
  * memory.  Only use the return value if you want to see if the kref is now
  * gone, not present.
  */
-int kref_put(struct kref *kref, void (*release)(struct kref *kref))
+int kref_put_process_context(struct kref *kref,
+			     void (*release)(struct kref *kref),
+			     struct kref_work *work)
 {
 	WARN_ON(release == NULL);
 	WARN_ON(release == (void (*)(struct kref *))kfree);
 
 	if (atomic_dec_and_test(&kref->refcount)) {
-		release(kref);
+		if (!work || !in_interrupt())
+			release(kref);
+		else {
+			INIT_WORK(&work->work, kref_release_process_context,
+				  work);
+			schedule_work(&work->work);
+		}
+			
+			
 		return 1;
 	}
 	return 0;
@@ -61,4 +82,4 @@ int kref_put(struct kref *kref, void (*r
 
 EXPORT_SYMBOL(kref_init);
 EXPORT_SYMBOL(kref_get);
-EXPORT_SYMBOL(kref_put);
+EXPORT_SYMBOL(kref_put_process_context);

Re: Linux 2.6.16-rc3

[James Bottomley]

On Tue, 2006-02-14 at 10:34 -0600, James Bottomley wrote:
> Well, I can't solve the problem that it requires memory allocation from
> IRQ context to operate.  Based on that, it's an unsafe interface.  I'm
> going to put it inside SCSI for 2.6.16, since it's better than what we
> have now, but I don't think we can export it globally.

OK, this is what I'm proposing as the device model fix.  What it does is
thread context checking APIs throughout the device subsystem.  SCSI can
then use it simply via device_put_process_context().  Since we have to
supply the kref_work; I'd plan to do that as an additional element in
struct scsi_device.

This, by itself, won't solve the SCSI target problem, but I plan to fix
that via a device model addition which would have target alloc waiting
around for any deleted targets to disappear.

Since this is planned for post 2.6.16, we have plenty of time to argue
about it.

James

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 6b355bd..4ae42de 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -338,10 +338,10 @@ struct device * get_device(struct device
  *	put_device - decrement reference count.
  *	@dev:	device in question.
  */
-void put_device(struct device * dev)
+void put_device_process_context(struct device * dev, struct kref_work *work)
 {
 	if (dev)
-		kobject_put(&dev->kobj);
+	  kobject_put_process_context(&dev->kobj, work);
 }
 
 
@@ -445,7 +445,7 @@ EXPORT_SYMBOL_GPL(device_register);
 EXPORT_SYMBOL_GPL(device_del);
 EXPORT_SYMBOL_GPL(device_unregister);
 EXPORT_SYMBOL_GPL(get_device);
-EXPORT_SYMBOL_GPL(put_device);
+EXPORT_SYMBOL_GPL(put_device_process_context);
 
 EXPORT_SYMBOL_GPL(device_create_file);
 EXPORT_SYMBOL_GPL(device_remove_file);
diff --git a/include/linux/device.h b/include/linux/device.h
index 58df18d..ac9d457 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -396,7 +396,13 @@ extern int (*platform_notify_remove)(str
  *
  */
 extern struct device * get_device(struct device * dev);
-extern void put_device(struct device * dev);
+extern void put_device_process_context(struct device * dev,
+				       struct kref_work *work);
+static inline void put_device(struct device *dev)
+{
+	put_device_process_context(dev, NULL);
+}
+						  
 
 
 /* drivers/base/power.c */
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index 2a8d8da..d079fea 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -76,7 +76,12 @@ extern int kobject_register(struct kobje
 extern void kobject_unregister(struct kobject *);
 
 extern struct kobject * kobject_get(struct kobject *);
-extern void kobject_put(struct kobject *);
+extern void kobject_put_process_context(struct kobject *, struct kref_work *);
+
+static inline void kobject_put(struct kobject *kobj)
+{
+	kobject_put_process_context(kobj, NULL);
+}
 
 extern char * kobject_get_path(struct kobject *, gfp_t);
 
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 6fee353..16b15db 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -18,15 +18,29 @@
 #ifdef __KERNEL__
 
 #include <linux/types.h>
+#include <linux/workqueue.h>
 #include <asm/atomic.h>
 
 struct kref {
 	atomic_t refcount;
 };
 
+struct kref_work {
+	struct work_struct work;
+	struct kref *kref;
+	void (*release)(struct kref *kref);
+};
+
 void kref_init(struct kref *kref);
 void kref_get(struct kref *kref);
-int kref_put(struct kref *kref, void (*release) (struct kref *kref));
+int kref_put_process_context(struct kref *kref,
+			     void (*release) (struct kref *kref),
+			     struct kref_work *work);
+static inline int kref_put(struct kref *kref,
+			   void (*release) (struct kref *kref))
+{
+	return kref_put_process_context(kref, release, NULL);
+}
 
 #endif /* __KERNEL__ */
 #endif /* _KREF_H_ */
diff --git a/lib/kobject.c b/lib/kobject.c
index efe67fa..6b80c54 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -372,10 +372,10 @@ static void kobject_release(struct kref 
  *
  *	Decrement the refcount, and if 0, call kobject_cleanup().
  */
-void kobject_put(struct kobject * kobj)
+void kobject_put_process_context(struct kobject * kobj, struct kref_work *work)
 {
 	if (kobj)
-		kref_put(&kobj->kref, kobject_release);
+		kref_put_process_context(&kobj->kref, kobject_release, work);
 }
 
 
@@ -537,7 +537,7 @@ EXPORT_SYMBOL(kobject_init);
 EXPORT_SYMBOL(kobject_register);
 EXPORT_SYMBOL(kobject_unregister);
 EXPORT_SYMBOL(kobject_get);
-EXPORT_SYMBOL(kobject_put);
+EXPORT_SYMBOL(kobject_put_process_context);
 EXPORT_SYMBOL(kobject_add);
 EXPORT_SYMBOL(kobject_del);
 
diff --git a/lib/kref.c b/lib/kref.c
index 0d07cc3..66231cf 100644
--- a/lib/kref.c
+++ b/lib/kref.c
@@ -13,6 +13,7 @@
 
 #include <linux/kref.h>
 #include <linux/module.h>
+#include <linux/hardirq.h>
 
 /**
  * kref_init - initialize object.
@@ -33,27 +34,47 @@ void kref_get(struct kref *kref)
 	atomic_inc(&kref->refcount);
 }
 
+static void kref_release_process_context(void *data)
+{
+	struct kref_work *work = data;
+
+	work->release(work->kref);
+}
+
 /**
- * kref_put - decrement refcount for object.
+ * kref_put_user - decrement refcount for object and put in user context
  * @kref: object.
  * @release: pointer to the function that will clean up the object when the
  *	     last reference to the object is released.
  *	     This pointer is required, and it is not acceptable to pass kfree
  *	     in as this function.
+ * @work:    pointer to a kref_work used to take the release through user
+ *	     context (may be null)
  *
- * Decrement the refcount, and if 0, call release().
+ * Decrement the refcount, and if 0, call release().  If work is not null
+ * execute release via schedule_work if not in process context.
  * Return 1 if the object was removed, otherwise return 0.  Beware, if this
  * function returns 0, you still can not count on the kref from remaining in
  * memory.  Only use the return value if you want to see if the kref is now
  * gone, not present.
  */
-int kref_put(struct kref *kref, void (*release)(struct kref *kref))
+int kref_put_process_context(struct kref *kref,
+			     void (*release)(struct kref *kref),
+			     struct kref_work *work)
 {
 	WARN_ON(release == NULL);
 	WARN_ON(release == (void (*)(struct kref *))kfree);
 
 	if (atomic_dec_and_test(&kref->refcount)) {
-		release(kref);
+		if (!work || !in_interrupt())
+			release(kref);
+		else {
+			INIT_WORK(&work->work, kref_release_process_context,
+				  work);
+			schedule_work(&work->work);
+		}
+			
+			
 		return 1;
 	}
 	return 0;
@@ -61,4 +82,4 @@ int kref_put(struct kref *kref, void (*r
 
 EXPORT_SYMBOL(kref_init);
 EXPORT_SYMBOL(kref_get);
-EXPORT_SYMBOL(kref_put);
+EXPORT_SYMBOL(kref_put_process_context);

Re: Linux 2.6.16-rc3

[Andrew Morton]

Thierry Vignaud <tvignaud@mandriva.com> wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
> 
>  > >  > It's not a "regression".  PM didn't work with ens1370 at all in
>  > >  > the eralier version.
>  > > 
>  > >  btw, PM support in snd-intel8x0 is broken (at least regarding
>  > >  suspending) in 2.6.16-rc2-mm1 on a nforce2 chipset
>  > 
>  > Can you identify when this breakage occurred?
> 
>  i'll try to compile a few older kernels (and/or just older
>  alsa-kernel) if you want but i'm not sure it's a regression (i'll
>  check if it has ever worked before).

OK, thanks.

>  i've tried unloading/reloading sound modules after resuming (maybe
>  would it work if unloaded before suspending but of course full PM
>  support would be nicer).
> 
>  not sure if it can help but while resuming, the snd-intel8x0 printed
>  quite a lot of warnings (due to preempting[1] i guess?) such as:
>  BUG: scheduling while atomic: zsh/0x00000001/2196
>   <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
>   <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
>   <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
>   <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
>   <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
>   <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
>   <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
>   <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
>   <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
>   <c0102973> sysenter_past_esp+0x54/0x75  
> 
>  dmesg after resuming (only look at the beginning, the end is only ehci
>  garbage b/c ehci is bugging for monthes (rejecting mass media after
>  writing a few Mo)):

That's odd.  I don't see what could have elevated preempt_count() on that
path.  What does `grep PREEMPT .config' say?

Re: Linux 2.6.16-rc3

[Thierry Vignaud]

[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]

Andrew Morton <akpm@osdl.org> writes:

> >  > It's not a "regression".  PM didn't work with ens1370 at all in
> >  > the eralier version.
> > 
> >  btw, PM support in snd-intel8x0 is broken (at least regarding
> >  suspending) in 2.6.16-rc2-mm1 on a nforce2 chipset
> 
> Can you identify when this breakage occurred?

i'll try to compile a few older kernels (and/or just older
alsa-kernel) if you want but i'm not sure it's a regression (i'll
check if it has ever worked before).

i've tried unloading/reloading sound modules after resuming (maybe
would it work if unloaded before suspending but of course full PM
support would be nicer).

not sure if it can help but while resuming, the snd-intel8x0 printed
quite a lot of warnings (due to preempting[1] i guess?) such as:
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  

dmesg after resuming (only look at the beginning, the end is only ehci
garbage b/c ehci is bugging for monthes (rejecting mass media after
writing a few Mo)):

[-- Attachment #2: bug.suspend.broken_dmesg1 --]
[-- Type: text/plain, Size: 70080 bytes --]

e+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <d4938e56> snd_intel8x0_chip_init+0x110/0x39e [snd_intel8x0]
 <d4939142> intel8x0_resume+0x5e/0x1ba [snd_intel8x0]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
PCI: Setting latency timer of device 0000:00:08.0 to 64
ohci_hcd 0000:01:07.0: PCI D0, from previous PCI D3
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c011d16a> msleep+0x17/0x1c
 <c01b5d83> pci_set_power_state+0x127/0x16a   <c01b5dd3> pci_enable_device_bars+0xd/0x38
 <c01b5e0c> pci_enable_device+0xe/0x2c   <cf848a1b> usb_hcd_pci_resume+0x11b/0x1b7 [usbcore]
 <c01b6dee> pci_device_resume+0x16/0x43   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
ACPI: PCI Interrupt 0000:01:07.0[A] -> Link [LNK4] -> GSI 12 (level, low) -> IRQ 12
ohci_hcd 0000:01:07.1: PCI D0, from previous PCI D3
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c011d16a> msleep+0x17/0x1c
 <c01b5d83> pci_set_power_state+0x127/0x16a   <c01b5dd3> pci_enable_device_bars+0xd/0x38
 <c01b5e0c> pci_enable_device+0xe/0x2c   <cf848a1b> usb_hcd_pci_resume+0x11b/0x1b7 [usbcore]
 <c01b6dee> pci_device_resume+0x16/0x43   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
ACPI: PCI Interrupt 0000:01:07.1[B] -> Link [LNK1] -> GSI 11 (level, low) -> IRQ 11
ehci_hcd 0000:01:07.2: PCI D0, from previous PCI D3
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c011d16a> msleep+0x17/0x1c
 <c01b5d83> pci_set_power_state+0x127/0x16a   <c01b5dd3> pci_enable_device_bars+0xd/0x38
 <c01b5e0c> pci_enable_device+0xe/0x2c   <cf848a1b> usb_hcd_pci_resume+0x11b/0x1b7 [usbcore]
 <c01b6dee> pci_device_resume+0x16/0x43   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
ACPI: PCI Interrupt 0000:01:07.2[C] -> Link [LNK2] -> GSI 11 (level, low) -> IRQ 11
ehci_hcd 0000:01:07.2: lost power, restarting
usb usb5: root hub lost power or was reset
ehci_hcd 0000:01:07.2: reset command 080002 (park)=0 ithresh=8 period=1024 Reset HALT
ehci_hcd 0000:01:07.2: MWI active
ehci_hcd 0000:01:07.2: ...powerdown ports...
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c011d16a> msleep+0x17/0x1c
 <cf861ed1> ehci_pci_reinit+0xf6/0xfe [ehci_hcd]   <cf86584f> ehci_pci_resume+0xbd/0x10a [ehci_hcd]
 <cf848a7a> usb_hcd_pci_resume+0x17a/0x1b7 [usbcore]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
ehci_hcd 0000:01:07.2: reset command 080002 (park)=0 ithresh=8 period=1024 Reset HALT
ehci_hcd 0000:01:07.2: init command 010009 (park)=0 ithresh=1 period=256 RUN
ehci_hcd 0000:01:07.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
ehci_hcd 0000:01:07.2: ...powerup ports...
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <cf86309c> ehci_run+0x165/0x16f [ehci_hcd]
 <c028c6bf> schedule_timeout+0x7a/0x95   <c011c755> process_timeout+0x0/0x5
 <c011d16a> msleep+0x17/0x1c   <cf865895> ehci_pci_resume+0x103/0x10a [ehci_hcd]
 <cf848a7a> usb_hcd_pci_resume+0x17a/0x1b7 [usbcore]   <c01b6dee> pci_device_resume+0x16/0x43
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
nvidiafb: your nForce DIMMs are not arranged in optimal banks!
i2c_adapter i2c-0: PM: resume from 0, parent 0000:02:00.0 still 1
i2c_adapter i2c-1: PM: resume from 0, parent 0000:02:00.0 still 1
i2c_adapter i2c-2: PM: resume from 0, parent 0000:02:00.0 still 1
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c01af304> vsnprintf+0x45a/0x497
 <c028c6bf> schedule_timeout+0x7a/0x95   <c011c755> process_timeout+0x0/0x5
 <c01fe3cb> ps2_sendbyte+0xa1/0xdd   <c0124c68> autoremove_wake_function+0x0/0x2d
 <c01fe5bb> ps2_command+0xdd/0x2ce   <c02271bc> atkbd_probe+0x4c/0xe0
 <c022842f> atkbd_reconnect+0x97/0xfc   <c01fc876> serio_reconnect_driver+0x21/0x34
 <c01fc8ba> serio_resume+0xb/0x1a   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6c6> schedule_timeout+0x81/0x95
 <c028c6bf> schedule_timeout+0x7a/0x95   <c011c755> process_timeout+0x0/0x5
 <c01fe64f> ps2_command+0x171/0x2ce   <c0124c68> autoremove_wake_function+0x0/0x2d
 <c02271bc> atkbd_probe+0x4c/0xe0   <c022842f> atkbd_reconnect+0x97/0xfc
 <c01fc876> serio_reconnect_driver+0x21/0x34   <c01fc8ba> serio_resume+0xb/0x1a
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c01fe731> ps2_command+0x253/0x2ce
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c02271bc> atkbd_probe+0x4c/0xe0
 <c022842f> atkbd_reconnect+0x97/0xfc   <c01fc876> serio_reconnect_driver+0x21/0x34
 <c01fc8ba> serio_resume+0xb/0x1a   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c01fe3cb> ps2_sendbyte+0xa1/0xdd
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c01fe5bb> ps2_command+0xdd/0x2ce
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c022736e> atkbd_activate+0x1a/0x69
 <c0228455> atkbd_reconnect+0xbd/0xfc   <c01fc876> serio_reconnect_driver+0x21/0x34
 <c01fc8ba> serio_resume+0xb/0x1a   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c01fe3cb> ps2_sendbyte+0xa1/0xdd
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c01fe5d8> ps2_command+0xfa/0x2ce
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c022736e> atkbd_activate+0x1a/0x69
 <c0228455> atkbd_reconnect+0xbd/0xfc   <c01fc876> serio_reconnect_driver+0x21/0x34
 <c01fc8ba> serio_resume+0xb/0x1a   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c01fe3cb> ps2_sendbyte+0xa1/0xdd
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c01fe5bb> ps2_command+0xdd/0x2ce
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c0227385> atkbd_activate+0x31/0x69
 <c0228455> atkbd_reconnect+0xbd/0xfc   <c01fc876> serio_reconnect_driver+0x21/0x34
 <c01fc8ba> serio_resume+0xb/0x1a   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c01fe3cb> ps2_sendbyte+0xa1/0xdd
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c01fe5d8> ps2_command+0xfa/0x2ce
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c0227385> atkbd_activate+0x31/0x69
 <c0228455> atkbd_reconnect+0xbd/0xfc   <c01fc876> serio_reconnect_driver+0x21/0x34
 <c01fc8ba> serio_resume+0xb/0x1a   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c01fe3cb> ps2_sendbyte+0xa1/0xdd
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c01fe5bb> ps2_command+0xdd/0x2ce
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c0227397> atkbd_activate+0x43/0x69
 <c0228455> atkbd_reconnect+0xbd/0xfc   <c01fc876> serio_reconnect_driver+0x21/0x34
 <c01fc8ba> serio_resume+0xb/0x1a   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c01fe3cb> ps2_sendbyte+0xa1/0xdd
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c01fe5bb> ps2_command+0xdd/0x2ce
 <c0228465> atkbd_reconnect+0xcd/0xfc   <c01fc876> serio_reconnect_driver+0x21/0x34
 <c01fc8ba> serio_resume+0xb/0x1a   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c01fe3cb> ps2_sendbyte+0xa1/0xdd
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c01fe5d8> ps2_command+0xfa/0x2ce
 <c0228465> atkbd_reconnect+0xcd/0xfc   <c01fc876> serio_reconnect_driver+0x21/0x34
 <c01fc8ba> serio_resume+0xb/0x1a   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c0213851> ide_do_request+0x515/0x730
 <c010339a> common_interrupt+0x1a/0x20   <c028c59f> wait_for_completion+0x70/0xc2
 <c0112f98> default_wake_function+0x0/0xc   <c0213b37> ide_do_drive_cmd+0xcb/0xf0
 <c0211301> generic_ide_resume+0x7d/0x88   <c01a84c8> blk_end_sync_rq+0x0/0x1d
 <c02177f3> task_no_data_intr+0x0/0x63   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c59f> wait_for_completion+0x70/0xc2
 <c0112f98> default_wake_function+0x0/0xc   <c0213b37> ide_do_drive_cmd+0xcb/0xf0
 <c0211301> generic_ide_resume+0x7d/0x88   <c01a84c8> blk_end_sync_rq+0x0/0x1d
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
BUG: warning at drivers/ide/ide-iops.c:1235/ide_wait_not_busy()
 <c0214b0a> ide_wait_not_busy+0x48/0x92   <c02136d9> ide_do_request+0x39d/0x730
 <c01a83bc> freed_request+0x1d/0x37   <c0213cf8> ide_intr+0x19c/0x1d4
 <c0219548> ide_dma_intr+0x0/0x8f   <c01302f8> handle_IRQ_event+0x21/0x4a
 <c0130397> __do_IRQ+0x76/0xcf   <c0104abe> do_IRQ+0x5e/0x79
 =======================
 <c010339a> common_interrupt+0x1a/0x20   <c01019bc> default_idle+0x2b/0x53
 <c0101a24> cpu_idle+0x40/0x5e   <c0322602> start_kernel+0x299/0x29b
usb usb1: finish resume
ohci_hcd 0000:00:02.0: lost power
usb usb1: root hub lost power or was reset
ohci_hcd 0000:00:02.0: resetting from state 'reset', control = 0x600
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c011d0d9> __mod_timer+0x9f/0xa9
 <c028c6bf> schedule_timeout+0x7a/0x95   <c011c755> process_timeout+0x0/0x5
 <c011d16a> msleep+0x17/0x1c   <cf828643> ohci_run+0x19e/0x46d [ohci_hcd]
 <cf8291ba> ohci_bus_resume+0x35e/0x5e4 [ohci_hcd]   <cf840c5e> hcd_bus_resume+0x2d/0x7a [usbcore]
 <cf83d974> hub_resume+0x38/0x17f [usbcore]   <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
 <cf83c56a> usb_generic_resume+0x73/0xcf [usbcore]   <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
 <cf83e46a> usb_resume_device+0x46/0xa1 [usbcore]   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:00:02.0: OHCI controller state
ohci_hcd 0000:00:02.0: OHCI 1.0, NO legacy support registers
ohci_hcd 0000:00:02.0: control 0x683 RWE RWC HCFS=operational CBSR=3
ohci_hcd 0000:00:02.0: cmdstatus 0x00000 SOC=0
ohci_hcd 0000:00:02.0: intrstatus 0x00000004 SF
ohci_hcd 0000:00:02.0: intrenable 0x8000000a MIE RD WDH
ohci_hcd 0000:00:02.0: hcca frame #0003
ohci_hcd 0000:00:02.0: roothub.a 01000203 POTPGT=1 NPS NDP=3(3)
ohci_hcd 0000:00:02.0: roothub.b 00000000 PPCM=0000 DR=0000
ohci_hcd 0000:00:02.0: roothub.status 00008000 DRWE
ohci_hcd 0000:00:02.0: roothub.portstatus [0] 0x00000100 PPS
ohci_hcd 0000:00:02.0: roothub.portstatus [1] 0x00000100 PPS
ohci_hcd 0000:00:02.0: roothub.portstatus [2] 0x00000100 PPS
ohci_hcd 0000:00:02.0: restart complete
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c011d16a> msleep+0x17/0x1c
 <cf83d9b0> hub_resume+0x74/0x17f [usbcore]   <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
 <cf83c56a> usb_generic_resume+0x73/0xcf [usbcore]   <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
 <cf83e46a> usb_resume_device+0x46/0xa1 [usbcore]   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:00:02.0: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
usb usb2: finish resume
ohci_hcd 0000:00:03.0: lost power
usb usb2: root hub lost power or was reset
ohci_hcd 0000:00:03.0: resetting from state 'reset', control = 0x600
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <cf842dc0> usb_start_wait_urb+0x141/0x14b [usbcore]
 <c028c6bf> schedule_timeout+0x7a/0x95   <c011c755> process_timeout+0x0/0x5
 <c011d16a> msleep+0x17/0x1c   <cf828643> ohci_run+0x19e/0x46d [ohci_hcd]
 <cf8291ba> ohci_bus_resume+0x35e/0x5e4 [ohci_hcd]   <cf840c5e> hcd_bus_resume+0x2d/0x7a [usbcore]
 <cf83d974> hub_resume+0x38/0x17f [usbcore]   <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
 <cf83c56a> usb_generic_resume+0x73/0xcf [usbcore]   <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
 <cf83e46a> usb_resume_device+0x46/0xa1 [usbcore]   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:00:03.0: OHCI controller state
ohci_hcd 0000:00:03.0: OHCI 1.0, NO legacy support registers
ohci_hcd 0000:00:03.0: control 0x683 RWE RWC HCFS=operational CBSR=3
ohci_hcd 0000:00:03.0: cmdstatus 0x00000 SOC=0
ohci_hcd 0000:00:03.0: intrstatus 0x00000004 SF
ohci_hcd 0000:00:03.0: intrenable 0x8000000a MIE RD WDH
ohci_hcd 0000:00:03.0: hcca frame #0003
ohci_hcd 0000:00:03.0: roothub.a 01000203 POTPGT=1 NPS NDP=3(3)
ohci_hcd 0000:00:03.0: roothub.b 00000000 PPCM=0000 DR=0000
ohci_hcd 0000:00:03.0: roothub.status 00008000 DRWE
ohci_hcd 0000:00:03.0: roothub.portstatus [0] 0x00000100 PPS
ohci_hcd 0000:00:03.0: roothub.portstatus [1] 0x00000100 PPS
ohci_hcd 0000:00:03.0: roothub.portstatus [2] 0x00000100 PPS
ohci_hcd 0000:00:03.0: restart complete
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c011d16a> msleep+0x17/0x1c
 <cf83d9b0> hub_resume+0x74/0x17f [usbcore]   <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
 <cf83c56a> usb_generic_resume+0x73/0xcf [usbcore]   <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
 <cf83e46a> usb_resume_device+0x46/0xa1 [usbcore]   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:00:03.0: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
usb usb3: finish resume
ohci_hcd 0000:01:07.0: lost power
usb usb3: root hub lost power or was reset
ohci_hcd 0000:01:07.0: resetting from state 'reset', control = 0x0
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <cf842dc0> usb_start_wait_urb+0x141/0x14b [usbcore]
 <c028c6bf> schedule_timeout+0x7a/0x95   <c011c755> process_timeout+0x0/0x5
 <c011d16a> msleep+0x17/0x1c   <cf828643> ohci_run+0x19e/0x46d [ohci_hcd]
 <cf8291ba> ohci_bus_resume+0x35e/0x5e4 [ohci_hcd]   <cf840c5e> hcd_bus_resume+0x2d/0x7a [usbcore]
 <cf83d974> hub_resume+0x38/0x17f [usbcore]   <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
 <cf83c56a> usb_generic_resume+0x73/0xcf [usbcore]   <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
 <cf83e46a> usb_resume_device+0x46/0xa1 [usbcore]   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:01:07.0: OHCI controller state
ohci_hcd 0000:01:07.0: OHCI 1.0, NO legacy support registers
ohci_hcd 0000:01:07.0: control 0x083 HCFS=operational CBSR=3
ohci_hcd 0000:01:07.0: cmdstatus 0x00000 SOC=0
ohci_hcd 0000:01:07.0: intrstatus 0x00000004 SF
ohci_hcd 0000:01:07.0: intrenable 0x8000001a MIE UE RD WDH
ohci_hcd 0000:01:07.0: hcca frame #01fe
ohci_hcd 0000:01:07.0: roothub.a ff000203 POTPGT=255 NPS NDP=3(3)
ohci_hcd 0000:01:07.0: roothub.b 00000000 PPCM=0000 DR=0000
ohci_hcd 0000:01:07.0: roothub.status 00008000 DRWE
ohci_hcd 0000:01:07.0: roothub.portstatus [0] 0x00000100 PPS
ohci_hcd 0000:01:07.0: roothub.portstatus [1] 0x00000100 PPS
ohci_hcd 0000:01:07.0: roothub.portstatus [2] 0x00000100 PPS
ohci_hcd 0000:01:07.0: restart complete
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c011d0d9> __mod_timer+0x9f/0xa9
 <c028c6bf> schedule_timeout+0x7a/0x95   <c011c755> process_timeout+0x0/0x5
 <c011d16a> msleep+0x17/0x1c   <cf83d9b0> hub_resume+0x74/0x17f [usbcore]
 <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]   <cf83c56a> usb_generic_resume+0x73/0xcf [usbcore]
 <cf83d610> finish_device_resume+0x119/0x16a [usbcore]   <cf83e46a> usb_resume_device+0x46/0xa1 [usbcore]
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
ohci_hcd 0000:01:07.0: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
usb 3-2: finish resume
usb 3-2: gone after usb resume? status -19
hub 3-0:1.0: resume port 2 --> -19
hub 3-0:1.0: logical disconnect on port 2
usb usb4: finish resume
ohci_hcd 0000:01:07.1: lost power
usb usb4: root hub lost power or was reset
ohci_hcd 0000:01:07.1: resetting from state 'reset', control = 0x0
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <cf842dc0> usb_start_wait_urb+0x141/0x14b [usbcore]
 <c028c6bf> schedule_timeout+0x7a/0x95   <c011c755> process_timeout+0x0/0x5
 <c011d16a> msleep+0x17/0x1c   <cf828643> ohci_run+0x19e/0x46d [ohci_hcd]
 <cf8291ba> ohci_bus_resume+0x35e/0x5e4 [ohci_hcd]   <cf840c5e> hcd_bus_resume+0x2d/0x7a [usbcore]
 <cf83d974> hub_resume+0x38/0x17f [usbcore]   <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
 <cf83c56a> usb_generic_resume+0x73/0xcf [usbcore]   <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
 <cf83e46a> usb_resume_device+0x46/0xa1 [usbcore]   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
ohci_hcd 0000:01:07.1: OHCI controller state
ohci_hcd 0000:01:07.1: OHCI 1.0, NO legacy support registers
ohci_hcd 0000:01:07.1: control 0x083 HCFS=operational CBSR=3
ohci_hcd 0000:01:07.1: cmdstatus 0x00000 SOC=0
ohci_hcd 0000:01:07.1: intrstatus 0x00000004 SF
ohci_hcd 0000:01:07.1: intrenable 0x8000001a MIE UE RD WDH
ohci_hcd 0000:01:07.1: hcca frame #01fe
ohci_hcd 0000:01:07.1: roothub.a ff000202 POTPGT=255 NPS NDP=2(2)
ohci_hcd 0000:01:07.1: roothub.b 00000000 PPCM=0000 DR=0000
ohci_hcd 0000:01:07.1: roothub.status 00008000 DRWE
ohci_hcd 0000:01:07.1: roothub.portstatus [0] 0x00000100 PPS
ohci_hcd 0000:01:07.1: roothub.portstatus [1] 0x00000100 PPS
ohci_hcd 0000:01:07.1: restart complete
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c011d0d9> __mod_timer+0x9f/0xa9
 <c028c6bf> schedule_timeout+0x7a/0x95   <c011c755> process_timeout+0x0/0x5
 <c011d16a> msleep+0x17/0x1c   <cf83d9b0> hub_resume+0x74/0x17f [usbcore]
 <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]   <cf83c56a> usb_generic_resume+0x73/0xcf [usbcore]
 <cf83d610> finish_device_resume+0x119/0x16a [usbcore]   <cf83e46a> usb_resume_device+0x46/0xa1 [usbcore]
 <c02025d9> resume_device+0x7d/0x96   <c02026a7> dpm_resume+0x58/0x80
 <c02026dc> device_resume+0xd/0x16   <c012db1f> pm_suspend_disk+0xbf/0xc8
 <c012cb95> enter_state+0x50/0x16f   <c012cd37> state_store+0x83/0x8f
 <c012ccb4> state_store+0x0/0x8f   <c0173492> subsys_attr_store+0x1e/0x22
 <c0173a1b> sysfs_write_file+0x92/0xb9   <c0173989> sysfs_write_file+0x0/0xb9
 <c01491ca> vfs_write+0x83/0x122   <c01499df> sys_write+0x3c/0x63
 <c0102973> sysenter_past_esp+0x54/0x75  
ohci_hcd 0000:01:07.1: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
usb usb5: finish resume
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028c6bf> schedule_timeout+0x7a/0x95
 <c011c755> process_timeout+0x0/0x5   <c011d16a> msleep+0x17/0x1c
 <cf83d9b0> hub_resume+0x74/0x17f [usbcore]   <cf83c4f7> usb_generic_resume+0x0/0xcf [usbcore]
 <cf83c56a> usb_generic_resume+0x73/0xcf [usbcore]   <cf83d610> finish_device_resume+0x119/0x16a [usbcore]
 <cf83e46a> usb_resume_device+0x46/0xa1 [usbcore]   <c02025d9> resume_device+0x7d/0x96
 <c02026a7> dpm_resume+0x58/0x80   <c02026dc> device_resume+0xd/0x16
 <c012db1f> pm_suspend_disk+0xbf/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001002 POWER sig=se0 CSC
ehci_hcd 0000:01:07.2: GetStatus port 3 status 001403 POWER sig=k CSC CONNECT
Restarting tasks...<3>BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c0112f8f> try_to_wake_up+0xe1/0xea
 <c012cea3> thaw_processes+0x97/0xc4   <c012d90e> unprepare_processes+0x25/0x2a
 <c012db24> pm_suspend_disk+0xc4/0xc8   <c012cb95> enter_state+0x50/0x16f
 <c012cd37> state_store+0x83/0x8f   <c012ccb4> state_store+0x0/0x8f
 <c0173492> subsys_attr_store+0x1e/0x22   <c0173a1b> sysfs_write_file+0x92/0xb9
 <c0173989> sysfs_write_file+0x0/0xb9   <c01491ca> vfs_write+0x83/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102973> sysenter_past_esp+0x54/0x75
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0002
ohci_hcd 0000:00:02.0: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
hub 1-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
 done
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c014922a> vfs_write+0xe3/0x122
 <c01499df> sys_write+0x3c/0x63   <c0102a3a> work_resched+0x5/0x16
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c028be58> io_schedule+0xe/0x16
 <c014a963> sync_buffer+0x2b/0x2e   <c028c733> __wait_on_bit+0x31/0x56
 <c014a938> sync_buffer+0x0/0x2e   <c014a938> sync_buffer+0x0/0x2e
 <c028c7b9> out_of_line_wait_on_bit+0x61/0x69   <c0124d17> wake_bit_function+0x0/0x3c
 <c014a1b3> __wait_on_buffer+0x1c/0x1f   <c017b03e> ext3_bread+0x47/0x61
 <c017c4a2> dx_probe+0x3a/0x2af   <c017d4e4> ext3_find_entry+0xc2/0x4ed
 <c01af373> snprintf+0x1b/0x1f   <c017dfaa> ext3_lookup+0x1f/0x75
 <c0153848> __lookup_hash+0xaa/0xc3   <c0155916> open_namei+0xc9/0x4e5
 <c0148839> do_filp_open+0x1c/0x31   <c01af373> snprintf+0x1b/0x1f
 <c014885d> filp_open+0xf/0x11   <c0151295> do_coredump+0x4e9/0x59e
 <c011e84a> __dequeue_signal+0x149/0x154   <c011f777> get_signal_to_deliver+0x3eb/0x418
 <c0111230> do_page_fault+0x0/0x4c3   <c0102372> do_notify_resume+0x6f/0x5a1
 <c0103463> error_code+0x4f/0x54   <c028dd4a> iret_exc+0x136/0x779
 <c01116a3> do_page_fault+0x473/0x4c3   <c0111230> do_page_fault+0x0/0x4c3
 <c0102a5e> work_notifysig+0x13/0x19  
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c01a7957> generic_make_request+0x191/0x1c2
 <c028be58> io_schedule+0xe/0x16   <c014a963> sync_buffer+0x2b/0x2e
 <c028c733> __wait_on_bit+0x31/0x56   <c014a938> sync_buffer+0x0/0x2e
 <c014a938> sync_buffer+0x0/0x2e   <c028c7b9> out_of_line_wait_on_bit+0x61/0x69
 <c0124d17> wake_bit_function+0x0/0x3c   <c014a1b3> __wait_on_buffer+0x1c/0x1f
 <c017b03e> ext3_bread+0x47/0x61   <c017d571> ext3_find_entry+0x14f/0x4ed
 <c017dfaa> ext3_lookup+0x1f/0x75   <c0153848> __lookup_hash+0xaa/0xc3
 <c0155916> open_namei+0xc9/0x4e5   <c0148839> do_filp_open+0x1c/0x31
 <c01af373> snprintf+0x1b/0x1f   <c014885d> filp_open+0xf/0x11
 <c0151295> do_coredump+0x4e9/0x59e   <c011e84a> __dequeue_signal+0x149/0x154
 <c011f777> get_signal_to_deliver+0x3eb/0x418   <c0111230> do_page_fault+0x0/0x4c3
 <c0102372> do_notify_resume+0x6f/0x5a1   <c0103463> error_code+0x4f/0x54
 <c028dd4a> iret_exc+0x136/0x779   <c01116a3> do_page_fault+0x473/0x4c3
 <c0111230> do_page_fault+0x0/0x4c3   <c0102a5e> work_notifysig+0x13/0x19
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
hub 2-0:1.0: state 7 ports 3 chg 0000 evt 0002
ohci_hcd 0000:00:03.0: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
hub 2-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c01354ed> get_page_from_freelist+0x7d/0x2fb
 <c01a7957> generic_make_request+0x191/0x1c2   <c028be58> io_schedule+0xe/0x16
 <c014a963> sync_buffer+0x2b/0x2e   <c028c733> __wait_on_bit+0x31/0x56
 <c014a938> sync_buffer+0x0/0x2e   <c014a938> sync_buffer+0x0/0x2e
 <c028c7b9> out_of_line_wait_on_bit+0x61/0x69   <c0124d17> wake_bit_function+0x0/0x3c
 <c014a1b3> __wait_on_buffer+0x1c/0x1f   <c014c575> __bread+0x59/0x6c
 <c01771b4> read_inode_bitmap+0x28/0x4c   <c01779ed> ext3_new_inode+0x3f9/0x824
 <c017d188> ext3_create+0x5d/0xc2   <c017d12b> ext3_create+0x0/0xc2
 <c0155811> vfs_create+0x5e/0x9a   <c0155982> open_namei+0x135/0x4e5
 <c0148839> do_filp_open+0x1c/0x31   <c01af373> snprintf+0x1b/0x1f
 <c014885d> filp_open+0xf/0x11   <c0151295> do_coredump+0x4e9/0x59e
 <c011e84a> __dequeue_signal+0x149/0x154   <c011f777> get_signal_to_deliver+0x3eb/0x418
 <c0111230> do_page_fault+0x0/0x4c3   <c0102372> do_notify_resume+0x6f/0x5a1
 <c0103463> error_code+0x4f/0x54   <c028dd4a> iret_exc+0x136/0x779
 <c01116a3> do_page_fault+0x473/0x4c3   <c0111230> do_page_fault+0x0/0x4c3
 <c0102a5e> work_notifysig+0x13/0x19  
hub 2-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
hub 3-0:1.0: state 7 ports 3 chg 0004 evt 0006
ohci_hcd 0000:01:07.0: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
hub 3-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c01354ed> get_page_from_freelist+0x7d/0x2fb
 <c01a7957> generic_make_request+0x191/0x1c2   <c028be58> io_schedule+0xe/0x16
 <c014a963> sync_buffer+0x2b/0x2e   <c028c733> __wait_on_bit+0x31/0x56
 <c014a938> sync_buffer+0x0/0x2e   <c014a938> sync_buffer+0x0/0x2e
 <c028c7b9> out_of_line_wait_on_bit+0x61/0x69   <c0124d17> wake_bit_function+0x0/0x3c
 <c014a1b3> __wait_on_buffer+0x1c/0x1f   <c0178352> __ext3_get_inode_loc+0x27b/0x2c2
 <c017841e> ext3_reserve_inode_write+0x1a/0x7a   <c017889b> ext3_mark_inode_dirty+0x11/0x27
 <c01858ca> journal_dirty_metadata+0x12e/0x15c   <c0177d87> ext3_new_inode+0x793/0x824
 <c017d188> ext3_create+0x5d/0xc2   <c017d12b> ext3_create+0x0/0xc2
 <c0155811> vfs_create+0x5e/0x9a   <c0155982> open_namei+0x135/0x4e5
 <c0148839> do_filp_open+0x1c/0x31   <c01af373> snprintf+0x1b/0x1f
 <c014885d> filp_open+0xf/0x11   <c0151295> do_coredump+0x4e9/0x59e
 <c011e84a> __dequeue_signal+0x149/0x154   <c011f777> get_signal_to_deliver+0x3eb/0x418
 <c0111230> do_page_fault+0x0/0x4c3   <c0102372> do_notify_resume+0x6f/0x5a1
 <c0103463> error_code+0x4f/0x54   <c028dd4a> iret_exc+0x136/0x779
 <c01116a3> do_page_fault+0x473/0x4c3   <c0111230> do_page_fault+0x0/0x4c3
 <c0102a5e> work_notifysig+0x13/0x19  
hub 3-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
ohci_hcd 0000:01:07.0: GetStatus roothub.portstatus [1] = 0x00010100 CSC PPS
hub 3-0:1.0: port 2, status 0100, change 0001, 12 Mb/s
usb 3-2: USB disconnect, address 3
usb 3-2: usb_disable_device nuking all URBs
usb 3-2: unregistering interface 3-2:1.0
usb 3-2:1.0: uevent
usb 3-2: unregistering device
usb 3-2: uevent
hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
hub 4-0:1.0: state 7 ports 2 chg 0000 evt 0002
ohci_hcd 0000:01:07.1: GetStatus roothub.portstatus [0] = 0x00010100 CSC PPS
hub 4-0:1.0: port 1, status 0100, change 0001, 12 Mb/s
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c01a7957> generic_make_request+0x191/0x1c2
 <c028be58> io_schedule+0xe/0x16   <c014a963> sync_buffer+0x2b/0x2e
 <c028c733> __wait_on_bit+0x31/0x56   <c014a938> sync_buffer+0x0/0x2e
 <c014a938> sync_buffer+0x0/0x2e   <c028c7b9> out_of_line_wait_on_bit+0x61/0x69
 <c0124d17> wake_bit_function+0x0/0x3c   <c014a1b3> __wait_on_buffer+0x1c/0x1f
 <c0178352> __ext3_get_inode_loc+0x27b/0x2c2   <c017841e> ext3_reserve_inode_write+0x1a/0x7a
 <c017889b> ext3_mark_inode_dirty+0x11/0x27   <c017be7c> add_dirent_to_buf+0x1fa/0x279
 <c017c836> ext3_add_entry+0x11f/0x871   <c0177e08> ext3_new_inode+0x814/0x824
 <c017cf97> ext3_add_nondir+0xf/0x3a   <c017d1b9> ext3_create+0x8e/0xc2
 <c017d12b> ext3_create+0x0/0xc2   <c0155811> vfs_create+0x5e/0x9a
 <c0155982> open_namei+0x135/0x4e5   <c0148839> do_filp_open+0x1c/0x31
 <c01af373> snprintf+0x1b/0x1f   <c014885d> filp_open+0xf/0x11
 <c0151295> do_coredump+0x4e9/0x59e   <c011e84a> __dequeue_signal+0x149/0x154
 <c011f777> get_signal_to_deliver+0x3eb/0x418   <c0111230> do_page_fault+0x0/0x4c3
 <c0102372> do_notify_resume+0x6f/0x5a1   <c0103463> error_code+0x4f/0x54
 <c028dd4a> iret_exc+0x136/0x779   <c01116a3> do_page_fault+0x473/0x4c3
 <c0111230> do_page_fault+0x0/0x4c3   <c0102a5e> work_notifysig+0x13/0x19
hub 4-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
hub 5-0:1.0: state 7 ports 5 chg 0004 evt 000c
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT
hub 5-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
usb 5-2: USB disconnect, address 3
usb 5-2: usb_disable_device nuking all URBs
usb 5-2: unregistering interface 5-2:1.0
usb 5-2:1.0: uevent
usb 5-2: unregistering device
usb 5-2: uevent
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c011652c> vprintk+0x23f/0x286
 <c01a7957> generic_make_request+0x191/0x1c2   <c028be58> io_schedule+0xe/0x16
 <c014a963> sync_buffer+0x2b/0x2e   <c028c733> __wait_on_bit+0x31/0x56
 <c014a938> sync_buffer+0x0/0x2e   <c014a938> sync_buffer+0x0/0x2e
 <c028c7b9> out_of_line_wait_on_bit+0x61/0x69   <c0124d17> wake_bit_function+0x0/0x3c
 <c014a1b3> __wait_on_buffer+0x1c/0x1f   <c014c575> __bread+0x59/0x6c
 <c017550e> read_block_bitmap+0x27/0x4a   <c0176336> ext3_new_blocks+0x191/0x55d
 <c01281c3> debug_mutex_add_waiter+0x14/0x25   <c0179dad> ext3_get_blocks_handle+0x12b/0x89d
 <c0179dad> ext3_get_blocks_handle+0x12b/0x89d   <c0179fd5> ext3_get_blocks_handle+0x353/0x89d
 <c0102a5e> work_notifysig+0x13/0x19   <c011652c> vprintk+0x23f/0x286
 <c011652c> vprintk+0x23f/0x286   <c010dc72> smp_apic_timer_interrupt+0x2a/0x2f
 <c01033bc> apic_timer_interrupt+0x1c/0x24   <c017a5ad> ext3_direct_io_get_blocks+0x8e/0xa8
 <c017a5d6> ext3_get_block+0xf/0x12   <c014b904> __block_prepare_write+0x114/0x379
 <c014bb7f> block_prepare_write+0x16/0x22   <c017a5c7> ext3_get_block+0x0/0x12
 <c01795fc> ext3_prepare_write+0x7f/0x115   <c017a5c7> ext3_get_block+0x0/0x12
 <c013216e> generic_file_buffered_write+0x21e/0x52b   <c0183f09> journal_stop+0x1c7/0x1d1
 <c017ef4f> __ext3_journal_stop+0x19/0x34   <c013353e> __generic_file_aio_write_nolock+0x3a1/0x3de
 <c013377e> generic_file_aio_write+0x3d/0xa4   <c0133792> generic_file_aio_write+0x51/0xa4
 <c017701d> ext3_file_write+0x19/0x83   <c0148df6> do_sync_write+0xb8/0xf3
 <c0124c68> autoremove_wake_function+0x0/0x2d   <c017ba41> ext3_orphan_del+0x52/0x1b6
 <c015d87a> inode_setattr+0x146/0x150   <c01affab> _mmx_memcpy+0x3c/0x136
 <c0169540> dump_write+0x10/0x1c   <c016b515> elf_core_dump+0x6ad/0xb32
 <c015dba3> notify_change+0x20d/0x21d   <c01512f1> do_coredump+0x545/0x59e
 <c011e84a> __dequeue_signal+0x149/0x154   <c011f777> get_signal_to_deliver+0x3eb/0x418
 <c0111230> do_page_fault+0x0/0x4c3   <c0102372> do_notify_resume+0x6f/0x5a1
 <c0103463> error_code+0x4f/0x54   <c028dd4a> iret_exc+0x136/0x779
 <c01116a3> do_page_fault+0x473/0x4c3   <c0111230> do_page_fault+0x0/0x4c3
 <c0102a5e> work_notifysig+0x13/0x19  
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 4
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c01a7957> generic_make_request+0x191/0x1c2
 <c028be58> io_schedule+0xe/0x16   <c014a963> sync_buffer+0x2b/0x2e
 <c028c733> __wait_on_bit+0x31/0x56   <c014a938> sync_buffer+0x0/0x2e
 <c014a938> sync_buffer+0x0/0x2e   <c028c7b9> out_of_line_wait_on_bit+0x61/0x69
 <c0124d17> wake_bit_function+0x0/0x3c   <c014a1b3> __wait_on_buffer+0x1c/0x1f
 <c014c575> __bread+0x59/0x6c   <c0179c0d> ext3_get_branch+0x6b/0xe0
 <c0179d37> ext3_get_blocks_handle+0xb5/0x89d   <c0135653> get_page_from_freelist+0x1e3/0x2fb
 <c01858ef> journal_dirty_metadata+0x153/0x15c   <c0178830> ext3_mark_iloc_dirty+0x2d7/0x331
 <c017a5ad> ext3_direct_io_get_blocks+0x8e/0xa8   <c017a5d6> ext3_get_block+0xf/0x12
 <c0164d2d> do_mpage_readpage+0xe3/0x318   <c0132461> generic_file_buffered_write+0x511/0x52b
 <c0165787> mpage_readpages+0x8e/0xef   <c017a5c7> ext3_get_block+0x0/0x12
 <c01357b8> __alloc_pages+0x4d/0x25d   <c0177e7e> ext3_readpages+0x0/0x15
 <c0136aaf> __do_page_cache_readahead+0x140/0x201   <c017a5c7> ext3_get_block+0x0/0x12
 <c013377e> generic_file_aio_write+0x3d/0xa4   <c013379b> generic_file_aio_write+0x5a/0xa4
 <c0132a98> filemap_nopage+0x148/0x2e2   <c013bab5> __handle_mm_fault+0x201/0x6a2
 <c013c102> get_user_pages+0x1ac/0x25b   <c016b7eb> elf_core_dump+0x983/0xb32
 <c01512f1> do_coredump+0x545/0x59e   <c011e84a> __dequeue_signal+0x149/0x154
 <c011f777> get_signal_to_deliver+0x3eb/0x418   <c0111230> do_page_fault+0x0/0x4c3
 <c0102372> do_notify_resume+0x6f/0x5a1   <c0103463> error_code+0x4f/0x54
 <c028dd4a> iret_exc+0x136/0x779   <c01116a3> do_page_fault+0x473/0x4c3
 <c0111230> do_page_fault+0x0/0x4c3   <c0102a5e> work_notifysig+0x13/0x19
BUG: scheduling while atomic: zsh/0x00000001/2196
 <c028b93f> schedule+0x43/0x54e   <c0177e7e> ext3_readpages+0x0/0x15
 <c0136aaf> __do_page_cache_readahead+0x140/0x201   <c017a5c7> ext3_get_block+0x0/0x12
 <c028be58> io_schedule+0xe/0x16   <c0131043> sync_page+0x0/0x36
 <c0131076> sync_page+0x33/0x36   <c028c7ed> __wait_on_bit_lock+0x2c/0x51
 <c0131169> __lock_page+0x50/0x56   <c0124d17> wake_bit_function+0x0/0x3c
 <c0132b5c> filemap_nopage+0x20c/0x2e2   <c013bab5> __handle_mm_fault+0x201/0x6a2
 <c013c102> get_user_pages+0x1ac/0x25b   <c016b7eb> elf_core_dump+0x983/0xb32
 <c01512f1> do_coredump+0x545/0x59e   <c011e84a> __dequeue_signal+0x149/0x154
 <c011f777> get_signal_to_deliver+0x3eb/0x418   <c0111230> do_page_fault+0x0/0x4c3
 <c0102372> do_notify_resume+0x6f/0x5a1   <c0103463> error_code+0x4f/0x54
 <c028dd4a> iret_exc+0x136/0x779   <c01116a3> do_page_fault+0x473/0x4c3
 <c0111230> do_page_fault+0x0/0x4c3   <c0102a5e> work_notifysig+0x13/0x19
note: zsh[2196] exited with preempt_count 1
 0:0:0:0: rejecting I/O to dead device
EXT3-fs error (device sda1): ext3_find_entry: reading directory #2 offset 0
ehci_hcd 0000:01:07.2: Unlink after no-IRQ?  Controller is probably using the wrong IRQ.
usb 5-2: khubd timed out on ep0in len=8/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
 0:0:0:0: rejecting I/O to dead device
usb 5-2: device not accepting address 4, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 5
 0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0in len=18/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 5, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 6
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 6, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 7
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 7, error -110
ehci_hcd 0000:01:07.2: GetStatus port 3 status 001403 POWER sig=k CSC CONNECT
hub 5-0:1.0: port 3, status 0501, change 0001, 480 Mb/s
hub 5-0:1.0: debounce: port 3: total 100ms stable 100ms status 0x501
ehci_hcd 0000:01:07.2: port 3 low speed --> companion
ehci_hcd 0000:01:07.2: GetStatus port 3 status 003402 POWER OWNER sig=k CSC
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0000
hub 3-0:1.0: state 7 ports 3 chg 0000 evt 0004
ohci_hcd 0000:01:07.0: GetStatus roothub.portstatus [1] = 0x00010301 CSC LSDA PPS CCS
hub 3-0:1.0: port 2, status 0301, change 0001, 1.5 Mb/s
 0:0:0:0: rejecting I/O to dead device
hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x301
ohci_hcd 0000:01:07.0: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS
usb 3-2: new low speed USB device using ohci_hcd and address 4
ohci_hcd 0000:01:07.0: GetStatus roothub.portstatus [1] = 0x00100303 PRSC LSDA PPS PES CCS
usb 3-2: skipped 1 descriptor after interface
usb 3-2: default language 0x0409
usb 3-2: new device found, idVendor=045e, idProduct=0040
usb 3-2: new device strings: Mfr=1, Product=3, SerialNumber=0
usb 3-2: Product: Microsoft 3-Button Mouse with IntelliEye(TM)
usb 3-2: Manufacturer: Microsoft
usb 3-2: uevent
usb 3-2: device is bus-powered
usb 3-2: configuration #1 chosen from 1 choice
usb 3-2: adding 3-2:1.0 (config #1, interface 0)
usb 3-2:1.0: uevent
usbhid 3-2:1.0: usb_probe_interface
usbhid 3-2:1.0: usb_probe_interface - got id
input: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM) as /class/input/input3
input: USB HID v1.10 Mouse [Microsoft Microsoft 3-Button Mouse with IntelliEye(TM)] on usb-0000:01:07.0-2
drivers/usb/core/inode.c: creating file '004'
hub 3-0:1.0: state 7 ports 3 chg 0000 evt 0004
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
 0:0:0:0: rejecting I/O to dead device
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0004
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001002 POWER sig=se0 CSC
hub 5-0:1.0: port 2, status 0100, change 0001, 12 Mb/s
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0004
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT
hub 5-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 9
usb 5-2: khubd timed out on ep0in len=18/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 9, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 10
usb 5-2: khubd timed out on ep0in len=18/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 10, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 11
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 11, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 12
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 12, error -110
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0004
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001002 POWER sig=se0 CSC
hub 5-0:1.0: port 2, status 0100, change 0001, 12 Mb/s
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0004
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT
hub 5-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 13
usb 5-2: khubd timed out on ep0in len=8/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 13, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 14
usb 5-2: khubd timed out on ep0in len=18/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 14, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 15
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 15, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 16
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 16, error -110
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0004
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001002 POWER sig=se0 CSC
hub 5-0:1.0: port 2, status 0100, change 0001, 12 Mb/s
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x100
hub 5-0:1.0: state 7 ports 5 chg 0000 evt 0004
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT
hub 5-0:1.0: port 2, status 0501, change 0001, 480 Mb/s
hub 5-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 17
usb 5-2: khubd timed out on ep0in len=8/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 17, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 18
usb 5-2: khubd timed out on ep0in len=18/64
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 18, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 19
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 19, error -110
ehci_hcd 0000:01:07.2: port 2 high speed
ehci_hcd 0000:01:07.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT
usb 5-2: new high speed USB device using ehci_hcd and address 20
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: khubd timed out on ep0out len=0/0
usb 5-2: device not accepting address 20, error -110

[-- Attachment #3: Type: text/plain, Size: 153 bytes --]


while testing suspending with that kernel, the root shell that echoed
in /sys/power/state got killed with "note: zsh[2196] exited with preempt_count 1"

Re: Linux 2.6.16-rc3

[Andrew Morton]

Thierry Vignaud <tvignaud@mandriva.com> wrote:
>
> Takashi Iwai <tiwai@suse.de> writes:
> 
>  > It's not a "regression".  PM didn't work with ens1370 at all in the
>  > eralier version.
> 
>  btw, PM support in snd-intel8x0 is broken (at least regarding
>  suspending) in 2.6.16-rc2-mm1 on a nforce2 chipset

Can you identify when this breakage occurred?

Re: Linux 2.6.16-rc3

[James Bottomley]

On Mon, 2006-02-13 at 12:38 -0800, Greg KH wrote:
> > - Nasty warnings from scsi about kobject-layer things being called
> from
> >   irq context.  James has a push-it-to-process-context patch which
> sadly
> >   assumes kmalloc() is immortal, but no other fix seems to have
> offered
> >   itself.
> 
> This has been the case for a long time.  I don't really think there is
> a
> rush to get this fixed, but I really like James's proposed patch.
> It's
> up to him if he feels it is ready for 2.6.16 or not.

Well, I can't solve the problem that it requires memory allocation from
IRQ context to operate.  Based on that, it's an unsafe interface.  I'm
going to put it inside SCSI for 2.6.16, since it's better than what we
have now, but I don't think we can export it globally.

James

Re: Linux 2.6.16-rc3

[James Bottomley]

On Mon, 2006-02-13 at 12:38 -0800, Greg KH wrote:
> > - Nasty warnings from scsi about kobject-layer things being called
> from
> >   irq context.  James has a push-it-to-process-context patch which
> sadly
> >   assumes kmalloc() is immortal, but no other fix seems to have
> offered
> >   itself.
> 
> This has been the case for a long time.  I don't really think there is
> a
> rush to get this fixed, but I really like James's proposed patch.
> It's
> up to him if he feels it is ready for 2.6.16 or not.

Well, I can't solve the problem that it requires memory allocation from
IRQ context to operate.  Based on that, it's an unsafe interface.  I'm
going to put it inside SCSI for 2.6.16, since it's better than what we
have now, but I don't think we can export it globally.

James

RE: Linux 2.6.16-rc3

[Brown, Len]

>i have a bug similar to:
>http://bugzilla.kernel.org/show_bug.cgi?id=6038 (marked as blocking by
>Andrew) on my laptop.

6038 is in NEEDINFO.
If no submitter participates, it may never get fixed.

-Len

RE: Linux 2.6.16-rc3

[Brown, Len]

>i have a bug similar to:
>http://bugzilla.kernel.org/show_bug.cgi?id=6038 (marked as blocking by
>Andrew) on my laptop.

6038 is in NEEDINFO.
If no submitter participates, it may never get fixed.

-Len

Re: Linux 2.6.16-rc3

[Andrew Morton]

Dave Jones <davej@redhat.com> wrote:
>
>   > argh.   The fix for this oops is still languishing in David's tree.
> 
>  I was waiting for it to turn up in an -mm release first to be
>  sure everything was ok.

If we're at -rc<late> and we have a fix in hand and we know we will want
that fix in 2.6.x, I don't think there's a lot of point in hanging around -
slam it in asap, give it the most exposure possible.

Re: Linux 2.6.16-rc3

[Dave Jones]

On Mon, Feb 13, 2006 at 06:44:42PM -0800, Andrew Morton wrote:
 > Andrew Morton <akpm@osdl.org> wrote:
 > >
 > > Avuton Olrich <avuton@gmail.com> wrote:
 > > >
 > > > I should have realized that would happen, hopefully here's a better
 > > >  one. Please let me know anything I can do to help.
 > > > 
 > > >  http://68.111.224.150:8080/~sbh/P1010031.JPG
 > > 
 > > Thanks.  Yes, it does look like the same bug.
 > 
 > argh.   The fix for this oops is still languishing in David's tree.

I was waiting for it to turn up in an -mm release first to be
sure everything was ok.

If you're ok with it going as is, Linus, please pull
from master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq.git/
to get the changesets below.

		Dave


commit 7d5e350fab47f1273bc8b52d5f133ed6e4baeb7f
Author: Dave Jones <davej@redhat.com>
Date:   Thu Feb 2 17:03:42 2006 -0500

    [CPUFREQ] Whitespace/CodingStyle cleanups

    Signed-off-by: Dave Jones <davej@redhat.com>

commit a85f7bd310dbc9010309bfe70b6b02432a11ef59
Author: Thomas Renninger <trenn@suse.de>
Date:   Wed Feb 1 11:36:04 2006 +0100

    [CPUFREQ] Check whether driver init did not initialize current freq

    Check whether driver init did not initialize current freq

    Signed-off-by: Thomas Renninger <trenn@suse.de>
    Signed-off-by: Dave Jones <davej@redhat.com>

commit 9d2725bb815d915fc6c8531097d9e71b579a8763
Author: Thomas Renninger <trenn@suse.de>
Date:   Wed Feb 1 11:38:37 2006 +0100

    [CPUFREQ] Check for not initialized freq on cpufreq changes

    Test for old_freq equals 0 to insure not to divide by 0:
    ______________________________________________

    Check for not initialized freq on cpufreq changes

    Signed-off-by: Thomas Renninger <trenn@suse.de>
    Signed-off-by: Dave Jones <davej@redhat.com>

commit e4472cb3706ceea42797ae1dc79d624026986694
Author: Dave Jones <davej@redhat.com>
Date:   Tue Jan 31 15:53:55 2006 -0800

    [CPUFREQ] cpufreq_notify_transition cleanup.

    Introduce caching of cpufreq_cpu_data[freqs->cpu], which allows us to
    make the function a lot more readable, and as a nice side-effect, it
    now fits in < 80 column displays again.

    Signed-off-by: Dave Jones <davej@redhat.com>

Re: Linux 2.6.16-rc3

[Andrew Morton]

Andrew Morton <akpm@osdl.org> wrote:
>
> Avuton Olrich <avuton@gmail.com> wrote:
> >
> > I should have realized that would happen, hopefully here's a better
> >  one. Please let me know anything I can do to help.
> > 
> >  http://68.111.224.150:8080/~sbh/P1010031.JPG
> 
> Thanks.  Yes, it does look like the same bug.

argh.   The fix for this oops is still languishing in David's tree.


--- a/arch/i386/kernel/timers/timer_tsc.c
+++ b/arch/i386/kernel/timers/timer_tsc.c
@@ -272,6 +272,10 @@ time_cpufreq_notifier(struct notifier_bl
 	if (val != CPUFREQ_RESUMECHANGE)
 		write_seqlock_irq(&xtime_lock);
 	if (!ref_freq) {
+		if (!freq->old){
+			ref_freq = freq->new;
+			goto end;
+		}
 		ref_freq = freq->old;
 		loops_per_jiffy_ref = cpu_data[freq->cpu].loops_per_jiffy;
 #ifndef CONFIG_SMP
@@ -297,6 +301,7 @@ time_cpufreq_notifier(struct notifier_bl
 #endif
 	}
 
+end:
 	if (val != CPUFREQ_RESUMECHANGE)
 		write_sequnlock_irq(&xtime_lock);
 

Re: Linux 2.6.16-rc3

[Jan Dittmer]

Linus Torvalds wrote:
> 
> On Mon, 13 Feb 2006, Jan Dittmer wrote:
> 
>>This breaks compilation on 3 archs compared to -rc2:
>>
>>- mips: broke
>>- sparc: broke
>>- sparc64: broke
> 
> 
> Should be ok in -git now, pls verify.
> 

- mips: fixed
  Details: http://l4x.org/k/?d=10915

- sparc: fixed
  Details: http://l4x.org/k/?d=10932

- sparc64: fixed
  Details: http://l4x.org/k/?d=10933

Good work,

Jan

Re: Linux 2.6.16-rc3

[Greg KH]

On Sun, Feb 12, 2006 at 07:05:20PM -0800, Andrew Morton wrote:
> 
> We still have some serious bugs, several of which are in 2.6.15 as well:
> 
> - Nathan's "sysfs-related oops during module unload", which Greg seems to
>   have under control.

Yes, this isn't a "regression" but has been there for a while.  It can
also only be triggered by a root user, so it's severity is much lower.

> - Various reports similar to
>   http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
>   PCI quirk handling.

I have a patch for this, which will be going to Linus later tonight.

> - Nasty warnings from scsi about kobject-layer things being called from
>   irq context.  James has a push-it-to-process-context patch which sadly
>   assumes kmalloc() is immortal, but no other fix seems to have offered
>   itself.

This has been the case for a long time.  I don't really think there is a
rush to get this fixed, but I really like James's proposed patch.  It's
up to him if he feels it is ready for 2.6.16 or not.

> - Helge Hafting reports a usb printer regression - I don't know if that's
>   still live?

He never reported back, and one other person who reported this, figured
out that it was bad ram in the system.  Replacing that fixed the issue.
I've also printed a lot of stuff here (tax time...) and had no problems.

> - "Carlo E.  Prelz" <fluido@fluido.as> has another USB/ehci regression
>   ("ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15
>   rc1").

Fixed by the previously mentioned EHCI quirk/handoff patch that will be
going to Linus.

So, that's it for the USB stuff, thankfully.

thanks,

greg k-h

Re: Linux 2.6.16-rc3

[Greg KH]

On Sun, Feb 12, 2006 at 07:05:20PM -0800, Andrew Morton wrote:
> 
> We still have some serious bugs, several of which are in 2.6.15 as well:
> 
> - Nathan's "sysfs-related oops during module unload", which Greg seems to
>   have under control.

Yes, this isn't a "regression" but has been there for a while.  It can
also only be triggered by a root user, so it's severity is much lower.

> - Various reports similar to
>   http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
>   PCI quirk handling.

I have a patch for this, which will be going to Linus later tonight.

> - Nasty warnings from scsi about kobject-layer things being called from
>   irq context.  James has a push-it-to-process-context patch which sadly
>   assumes kmalloc() is immortal, but no other fix seems to have offered
>   itself.

This has been the case for a long time.  I don't really think there is a
rush to get this fixed, but I really like James's proposed patch.  It's
up to him if he feels it is ready for 2.6.16 or not.

> - Helge Hafting reports a usb printer regression - I don't know if that's
>   still live?

He never reported back, and one other person who reported this, figured
out that it was bad ram in the system.  Replacing that fixed the issue.
I've also printed a lot of stuff here (tax time...) and had no problems.

> - "Carlo E.  Prelz" <fluido@fluido.as> has another USB/ehci regression
>   ("ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15
>   rc1").

Fixed by the previously mentioned EHCI quirk/handoff patch that will be
going to Linus.

So, that's it for the USB stuff, thankfully.

thanks,

greg k-h

Re: Linux 2.6.16-rc3

[Paul Fulghum]

On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:

> - A couple of random tty-related oopses reported by Jesper Juhl.  We
>   don't know why these happened - they appear to not be related to the tty
>   buffering changes.

I just posted a patch for this under
[PATCH] tty reference count fix

This is not related to the tty buffering changes.

-- 
Paul Fulghum
Microgate Systems, Ltd

Re: Linux 2.6.16-rc3

[Rafael J. Wysocki]

On Monday 13 February 2006 14:51, Takashi Iwai wrote:
> At Mon, 13 Feb 2006 14:09:51 +0100,
> Rafael J. Wysocki wrote:
> > 
> > On Monday 13 February 2006 13:02, Takashi Iwai wrote:
> > > At Sun, 12 Feb 2006 19:05:20 -0800,
> > > Andrew Morton wrote:
> > > > 
> > > > - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> > > >   regression ("alsa suspend/resume continues to fail for ens1370")
> > > 
> > > It's not a "regression".  PM didn't work with ens1370 at all in the
> > > eralier version.
> > > 
> > > About the problem there, I have no idea now what's wrong.  The
> > > suspend-to-disk works fine if the driver is built as module but not as
> > > built-in kernel.
> > 
> > That may be related to the fact that modular drivers are not present in
> > memory during resume (just a thought).
> 
> I think the modular drivers are on memory but the order of
> re-initialization is different.

No, they are not (this is the part I'm sure of).  software_resume() is called
before any modules have a chance to be loaded unless you boot with
noresume, load them from an initrd and start the resume manually.

Greetings,
Rafael

Re: Linux 2.6.16-rc3

[Rafael J. Wysocki]

On Monday 13 February 2006 14:51, Takashi Iwai wrote:
> At Mon, 13 Feb 2006 14:09:51 +0100,
> Rafael J. Wysocki wrote:
> > 
> > On Monday 13 February 2006 13:02, Takashi Iwai wrote:
> > > At Sun, 12 Feb 2006 19:05:20 -0800,
> > > Andrew Morton wrote:
> > > > 
> > > > - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> > > >   regression ("alsa suspend/resume continues to fail for ens1370")
> > > 
> > > It's not a "regression".  PM didn't work with ens1370 at all in the
> > > eralier version.
> > > 
> > > About the problem there, I have no idea now what's wrong.  The
> > > suspend-to-disk works fine if the driver is built as module but not as
> > > built-in kernel.
> > 
> > That may be related to the fact that modular drivers are not present in
> > memory during resume (just a thought).
> 
> I think the modular drivers are on memory but the order of
> re-initialization is different.

No, they are not (this is the part I'm sure of).  software_resume() is called
before any modules have a chance to be loaded unless you boot with
noresume, load them from an initrd and start the resume manually.

Greetings,
Rafael

Re: Linux 2.6.16-rc3

[Daniel Drake]

Adrian Bunk wrote:
> On Sun, Feb 12, 2006 at 07:05:20PM -0800, Andrew Morton wrote:
>> ...
>> - Various reports similar to
>>   http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
>>   PCI quirk handling.
>> ...
> 
> This bug contains a patch.
> 
> What is the status of this patch?

The patch is in Greg's tree so should see its way to Linus soon. 
However, it's not the complete fix for the general issue.

Gentoo have had two reports of it. One is fixed by David's patch, the 
other is not (http://bugs.gentoo.org/122277 - will be re-filed on kernel 
bugzilla once I have investigated more).

Daniel

Re: Linux 2.6.16-rc3

[Andi Kleen]

Con Kolivas <kernel@kolivas.org> writes:

> On Monday 13 February 2006 21:39, Andrew Morton wrote:
> > That looks like a different cpufreq bug.  Unfortunately the critical first
> > few lines have scrolled away.  Please boot with `vga=extended' so we get to
> > see them.
> 
> Just as a suggestion, why don't we print oopsen out in the opposite direction 
> so the critical information is in the last few lines and the stacktrace in 
> reverse, or have that as a bootparam option oops=reverse .

x86-64 has a one line "executive summary" with the RIP etc. 
at the end to solve that problem. Might be a good idea for i386 too.

-Andi

Re: Linux 2.6.16-rc3

[Thierry Vignaud]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

Takashi Iwai <tiwai@suse.de> writes:

> It's not a "regression".  PM didn't work with ens1370 at all in the
> eralier version.

btw, PM support in snd-intel8x0 is broken (at least regarding
suspending) in 2.6.16-rc2-mm1 on a nforce2 chipset

even if not playing while suspending, ALSA won't resume playing: no
more program can play anything strace show that sound programs block
on unfinished "futex(0xb7768060, FUTEX_WAIT, 29, NULL..." calls

lspci -vvvv:

[-- Attachment #2: bug.suspend.lspci --]
[-- Type: text/plain, Size: 8816 bytes --]

00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev b2)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
	Capabilities: <access denied>

00:00.1 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:00.2 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:00.3 RAM memory: nVidia Corporation nForce 420 Memory Controller (DDR) (rev b2)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:01.0 ISA bridge: nVidia Corporation nForce ISA Bridge (rev c3)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Capabilities: <access denied>

00:01.1 SMBus: nVidia Corporation nForce PCI System Management (rev c1)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at 5000 [size=16]
	Region 1: I/O ports at d000 [size=16]
	Region 2: I/O ports at d400 [size=32]
	Capabilities: <access denied>

00:02.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3) (prog-if 10 [OHCI])
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at e0081000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

00:03.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3) (prog-if 10 [OHCI])
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 3
	Region 0: Memory at e0080000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

00:05.0 Multimedia audio controller: nVidia Corporation nForce Audio (rev c2)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (250ns min, 3000ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at e0000000 (32-bit, non-prefetchable) [size=512K]
	Capabilities: <access denied>

00:06.0 Multimedia audio controller: nVidia Corporation nForce Audio (rev c2)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (500ns min, 1250ns max)
	Interrupt: pin A routed to IRQ 3
	Region 0: I/O ports at d800 [size=256]
	Region 1: I/O ports at dc00 [size=128]
	Region 2: Memory at e0082000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

00:08.0 PCI bridge: nVidia Corporation nForce PCI-to-PCI bridge (rev c2) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: de000000-dfffffff
	Prefetchable memory behind bridge: 10000000-100fffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

00:09.0 IDE interface: nVidia Corporation nForce IDE (rev c3) (prog-if 8a [Master SecP PriP])
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Region 4: I/O ports at e400 [size=16]
	Capabilities: <access denied>

00:1e.0 PCI bridge: nVidia Corporation nForce AGP to PCI Bridge (rev b2) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: dc000000-ddffffff
	Prefetchable memory behind bridge: d0000000-d7ffffff
	Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-

01:06.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 64)
	Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (2500ns min, 2500ns max), Cache Line Size 08
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at c000 [size=128]
	Region 1: Memory at df000000 (32-bit, non-prefetchable) [size=128]
	[virtual] Expansion ROM at 10000000 [disabled] [size=128K]
	Capabilities: <access denied>

01:07.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
	Subsystem: Adaptec Unknown device 0335
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (250ns min, 10500ns max), Cache Line Size 08
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at df001000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

01:07.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
	Subsystem: Adaptec Unknown device 0335
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (250ns min, 10500ns max), Cache Line Size 08
	Interrupt: pin B routed to IRQ 11
	Region 0: Memory at df002000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

01:07.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
	Subsystem: Adaptec Unknown device 03e0
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (4000ns min, 8500ns max), Cache Line Size 10
	Interrupt: pin C routed to IRQ 11
	Region 0: Memory at df003000 (32-bit, non-prefetchable) [size=256]
	Capabilities: <access denied>

02:00.0 VGA compatible controller: nVidia Corporation NVCrush11 [GeForce2 MX Integrated Graphics] (rev b1) (prog-if 00 [VGA])
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (1250ns min, 250ns max)
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at dc000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
	[virtual] Expansion ROM at dd000000 [disabled] [size=64K]
	Capabilities: <access denied>

Re: Linux 2.6.16-rc3

[Thierry Vignaud]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

Takashi Iwai <tiwai@suse.de> writes:

> It's not a "regression".  PM didn't work with ens1370 at all in the
> eralier version.

btw, PM support in snd-intel8x0 is broken (at least regarding
suspending) in 2.6.16-rc2-mm1 on a nforce2 chipset

even if not playing while suspending, ALSA won't resume playing: no
more program can play anything strace show that sound programs block
on unfinished "futex(0xb7768060, FUTEX_WAIT, 29, NULL..." calls

lspci -vvvv:

[-- Attachment #2: bug.suspend.lspci --]
[-- Type: text/plain, Size: 8816 bytes --]

00:00.0 Host bridge: nVidia Corporation nForce CPU bridge (rev b2)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Region 0: Memory at d8000000 (32-bit, prefetchable) [size=64M]
	Capabilities: <access denied>

00:00.1 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:00.2 RAM memory: nVidia Corporation nForce 220/420 Memory Controller (rev b2)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:00.3 RAM memory: nVidia Corporation nForce 420 Memory Controller (DDR) (rev b2)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:01.0 ISA bridge: nVidia Corporation nForce ISA Bridge (rev c3)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Capabilities: <access denied>

00:01.1 SMBus: nVidia Corporation nForce PCI System Management (rev c1)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at 5000 [size=16]
	Region 1: I/O ports at d000 [size=16]
	Region 2: I/O ports at d400 [size=32]
	Capabilities: <access denied>

00:02.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3) (prog-if 10 [OHCI])
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at e0081000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

00:03.0 USB Controller: nVidia Corporation nForce USB Controller (rev c3) (prog-if 10 [OHCI])
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 3
	Region 0: Memory at e0080000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

00:05.0 Multimedia audio controller: nVidia Corporation nForce Audio (rev c2)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (250ns min, 3000ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: Memory at e0000000 (32-bit, non-prefetchable) [size=512K]
	Capabilities: <access denied>

00:06.0 Multimedia audio controller: nVidia Corporation nForce Audio (rev c2)
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (500ns min, 1250ns max)
	Interrupt: pin A routed to IRQ 3
	Region 0: I/O ports at d800 [size=256]
	Region 1: I/O ports at dc00 [size=128]
	Region 2: Memory at e0082000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

00:08.0 PCI bridge: nVidia Corporation nForce PCI-to-PCI bridge (rev c2) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: de000000-dfffffff
	Prefetchable memory behind bridge: 10000000-100fffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-

00:09.0 IDE interface: nVidia Corporation nForce IDE (rev c3) (prog-if 8a [Master SecP PriP])
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Region 4: I/O ports at e400 [size=16]
	Capabilities: <access denied>

00:1e.0 PCI bridge: nVidia Corporation nForce AGP to PCI Bridge (rev b2) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: dc000000-ddffffff
	Prefetchable memory behind bridge: d0000000-d7ffffff
	Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR+ NoISA+ VGA+ MAbort- >Reset- FastB2B-

01:06.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 64)
	Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (2500ns min, 2500ns max), Cache Line Size 08
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at c000 [size=128]
	Region 1: Memory at df000000 (32-bit, non-prefetchable) [size=128]
	[virtual] Expansion ROM at 10000000 [disabled] [size=128K]
	Capabilities: <access denied>

01:07.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
	Subsystem: Adaptec Unknown device 0335
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (250ns min, 10500ns max), Cache Line Size 08
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at df001000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

01:07.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
	Subsystem: Adaptec Unknown device 0335
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (250ns min, 10500ns max), Cache Line Size 08
	Interrupt: pin B routed to IRQ 11
	Region 0: Memory at df002000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>

01:07.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
	Subsystem: Adaptec Unknown device 03e0
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (4000ns min, 8500ns max), Cache Line Size 10
	Interrupt: pin C routed to IRQ 11
	Region 0: Memory at df003000 (32-bit, non-prefetchable) [size=256]
	Capabilities: <access denied>

02:00.0 VGA compatible controller: nVidia Corporation NVCrush11 [GeForce2 MX Integrated Graphics] (rev b1) (prog-if 00 [VGA])
	Subsystem: ABIT Computer Corp. Unknown device 7105
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (1250ns min, 250ns max)
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at dc000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
	[virtual] Expansion ROM at dd000000 [disabled] [size=64K]
	Capabilities: <access denied>

Re: Linux 2.6.16-rc3

[Adrian Bunk]

On Sun, Feb 12, 2006 at 07:05:20PM -0800, Andrew Morton wrote:
>...
> - Various reports similar to
>   http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
>   PCI quirk handling.
>...

This bug contains a patch.

What is the status of this patch?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Linux 2.6.16-rc3

[Linus Torvalds]

On Mon, 13 Feb 2006, Jan Dittmer wrote:
> 
> This breaks compilation on 3 archs compared to -rc2:
> 
> - mips: broke
> - sparc: broke
> - sparc64: broke

Should be ok in -git now, pls verify.

		Linus

Re: Linux 2.6.16-rc3

[Benjamin LaHaise]

On Sun, Feb 12, 2006 at 10:22:55PM -0500, Trond Myklebust wrote:
> > - Benjamin LaHaise <bcrl@kvack.org> had an NFS problem ("NFS processes
> >   gettting stuck in D with currrent git").
> 
> ...but which was apparently not repeatable:
> 
>         As of this afternoon's tree
>         (6150c32589d1976ca8a5c987df951088c05a7542)  after the more
>         recent set of nfs patches, it seems to be behaving itself.  Will
>         keep sysrq enabled to see if it hits again, though.
> 
> I've had no news from Ben since then...

Confirmed: I've had no problems with NFS since that update, and my test 
box uses NFS regularly.

			-ben
-- 
"Ladies and gentlemen, I'm sorry to interrupt, but the police are here 
and they've asked us to stop the party."  Don't Email: <dont@kvack.org>.

Re: Linux 2.6.16-rc3

[Takashi Iwai]

At Mon, 13 Feb 2006 15:34:28 +0100,
Patrizio Bassi wrote:
> 
> Takashi Iwai ha scritto:
> > At Mon, 13 Feb 2006 14:31:23 +0100,
> > Patrizio Bassi wrote:
> >   
> >> Takashi Iwai ha scritto:
> >>     
> >>> At Mon, 13 Feb 2006 13:37:55 +0100,
> >>> Patrizio Bassi wrote:
> >>>   
> >>>       
> >>>> Takashi Iwai ha scritto:
> >>>>     
> >>>>         
> >>>>> At Sun, 12 Feb 2006 19:05:20 -0800,
> >>>>> Andrew Morton wrote:
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> >>>>>>   regression ("alsa suspend/resume continues to fail for ens1370")
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> It's not a "regression".  PM didn't work with ens1370 at all in the
> >>>>> eralier version.
> >>>>>
> >>>>> About the problem there, I have no idea now what's wrong.  The
> >>>>> suspend-to-disk works fine if the driver is built as module but not as
> >>>>> built-in kernel.
> >>>>>
> >>>>>
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> i wrote "regression" because before (ehm...exactly don't know...about
> >>>> 2.6.14 time)
> >>>> after suspend i had to restart my distro's mixer values service or i
> >>>> couldn't hear anything.
> >>>> and...ok..it was boring but worked.
> >>>>     
> >>>>         
> >>> You abused the function which wasn't officially supported :)
> >>>
> >>>
> >>> Takashi
> >>>
> >>>   
> >>>       
> >> nice i'm an abuser! :)
> >>
> >> ok, seriously..that's bad, because before it was not implemented, so ok...
> >> but now it fails with errors (and make apps not working properly) which
> >> is worse.
> >>     
> >
> > My rough guess is the initialization order, the resume was called too
> > early.
> >
> > What about to put sleep between snd_ensoniq_chip_init() and
> > snd_ak4531_resume()?  Or put more delay in snd_ak4531_resume()?
> >
> >
> > Takashi
> >
> >   
> i'm almost sure the problem is not there (or, at least not only)
> infact i get 0x660 errors (or better a long flood...) while suspending too.

IIRC, suspend calls resume callback once to revive the devices back.
So, basically you see the same problem here.


Takashi

Re: Linux 2.6.16-rc3

[Takashi Iwai]

At Mon, 13 Feb 2006 15:34:28 +0100,
Patrizio Bassi wrote:
> 
> Takashi Iwai ha scritto:
> > At Mon, 13 Feb 2006 14:31:23 +0100,
> > Patrizio Bassi wrote:
> >   
> >> Takashi Iwai ha scritto:
> >>     
> >>> At Mon, 13 Feb 2006 13:37:55 +0100,
> >>> Patrizio Bassi wrote:
> >>>   
> >>>       
> >>>> Takashi Iwai ha scritto:
> >>>>     
> >>>>         
> >>>>> At Sun, 12 Feb 2006 19:05:20 -0800,
> >>>>> Andrew Morton wrote:
> >>>>>   
> >>>>>       
> >>>>>           
> >>>>>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> >>>>>>   regression ("alsa suspend/resume continues to fail for ens1370")
> >>>>>>     
> >>>>>>         
> >>>>>>             
> >>>>> It's not a "regression".  PM didn't work with ens1370 at all in the
> >>>>> eralier version.
> >>>>>
> >>>>> About the problem there, I have no idea now what's wrong.  The
> >>>>> suspend-to-disk works fine if the driver is built as module but not as
> >>>>> built-in kernel.
> >>>>>
> >>>>>
> >>>>>   
> >>>>>       
> >>>>>           
> >>>> i wrote "regression" because before (ehm...exactly don't know...about
> >>>> 2.6.14 time)
> >>>> after suspend i had to restart my distro's mixer values service or i
> >>>> couldn't hear anything.
> >>>> and...ok..it was boring but worked.
> >>>>     
> >>>>         
> >>> You abused the function which wasn't officially supported :)
> >>>
> >>>
> >>> Takashi
> >>>
> >>>   
> >>>       
> >> nice i'm an abuser! :)
> >>
> >> ok, seriously..that's bad, because before it was not implemented, so ok...
> >> but now it fails with errors (and make apps not working properly) which
> >> is worse.
> >>     
> >
> > My rough guess is the initialization order, the resume was called too
> > early.
> >
> > What about to put sleep between snd_ensoniq_chip_init() and
> > snd_ak4531_resume()?  Or put more delay in snd_ak4531_resume()?
> >
> >
> > Takashi
> >
> >   
> i'm almost sure the problem is not there (or, at least not only)
> infact i get 0x660 errors (or better a long flood...) while suspending too.

IIRC, suspend calls resume callback once to revive the devices back.
So, basically you see the same problem here.


Takashi

Re: Linux 2.6.16-rc3

[Patrizio Bassi]

Takashi Iwai ha scritto:
> At Mon, 13 Feb 2006 14:31:23 +0100,
> Patrizio Bassi wrote:
>   
>> Takashi Iwai ha scritto:
>>     
>>> At Mon, 13 Feb 2006 13:37:55 +0100,
>>> Patrizio Bassi wrote:
>>>   
>>>       
>>>> Takashi Iwai ha scritto:
>>>>     
>>>>         
>>>>> At Sun, 12 Feb 2006 19:05:20 -0800,
>>>>> Andrew Morton wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
>>>>>>   regression ("alsa suspend/resume continues to fail for ens1370")
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> It's not a "regression".  PM didn't work with ens1370 at all in the
>>>>> eralier version.
>>>>>
>>>>> About the problem there, I have no idea now what's wrong.  The
>>>>> suspend-to-disk works fine if the driver is built as module but not as
>>>>> built-in kernel.
>>>>>
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> i wrote "regression" because before (ehm...exactly don't know...about
>>>> 2.6.14 time)
>>>> after suspend i had to restart my distro's mixer values service or i
>>>> couldn't hear anything.
>>>> and...ok..it was boring but worked.
>>>>     
>>>>         
>>> You abused the function which wasn't officially supported :)
>>>
>>>
>>> Takashi
>>>
>>>   
>>>       
>> nice i'm an abuser! :)
>>
>> ok, seriously..that's bad, because before it was not implemented, so ok...
>> but now it fails with errors (and make apps not working properly) which
>> is worse.
>>     
>
> My rough guess is the initialization order, the resume was called too
> early.
>
> What about to put sleep between snd_ensoniq_chip_init() and
> snd_ak4531_resume()?  Or put more delay in snd_ak4531_resume()?
>
>
> Takashi
>
>   
i'm almost sure the problem is not there (or, at least not only)
infact i get 0x660 errors (or better a long flood...) while suspending too.

there may be a bug or problem during suspending, and these problems
affect the normal resume.

however sleep is not always trustable...soif you think that's an init
problem you may add a
boolean value to check if init is completed or not and poll for TRUE
value in the resume function.

but, as i wrote before, i'm not sure the problem is **only** there.

Patrizio

Re: Linux 2.6.16-rc3

[Patrizio Bassi]

Takashi Iwai ha scritto:
> At Mon, 13 Feb 2006 14:31:23 +0100,
> Patrizio Bassi wrote:
>   
>> Takashi Iwai ha scritto:
>>     
>>> At Mon, 13 Feb 2006 13:37:55 +0100,
>>> Patrizio Bassi wrote:
>>>   
>>>       
>>>> Takashi Iwai ha scritto:
>>>>     
>>>>         
>>>>> At Sun, 12 Feb 2006 19:05:20 -0800,
>>>>> Andrew Morton wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
>>>>>>   regression ("alsa suspend/resume continues to fail for ens1370")
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> It's not a "regression".  PM didn't work with ens1370 at all in the
>>>>> eralier version.
>>>>>
>>>>> About the problem there, I have no idea now what's wrong.  The
>>>>> suspend-to-disk works fine if the driver is built as module but not as
>>>>> built-in kernel.
>>>>>
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> i wrote "regression" because before (ehm...exactly don't know...about
>>>> 2.6.14 time)
>>>> after suspend i had to restart my distro's mixer values service or i
>>>> couldn't hear anything.
>>>> and...ok..it was boring but worked.
>>>>     
>>>>         
>>> You abused the function which wasn't officially supported :)
>>>
>>>
>>> Takashi
>>>
>>>   
>>>       
>> nice i'm an abuser! :)
>>
>> ok, seriously..that's bad, because before it was not implemented, so ok...
>> but now it fails with errors (and make apps not working properly) which
>> is worse.
>>     
>
> My rough guess is the initialization order, the resume was called too
> early.
>
> What about to put sleep between snd_ensoniq_chip_init() and
> snd_ak4531_resume()?  Or put more delay in snd_ak4531_resume()?
>
>
> Takashi
>
>   
i'm almost sure the problem is not there (or, at least not only)
infact i get 0x660 errors (or better a long flood...) while suspending too.

there may be a bug or problem during suspending, and these problems
affect the normal resume.

however sleep is not always trustable...soif you think that's an init
problem you may add a
boolean value to check if init is completed or not and poll for TRUE
value in the resume function.

but, as i wrote before, i'm not sure the problem is **only** there.

Patrizio

Re: Linux 2.6.16-rc3

[Takashi Iwai]

At Mon, 13 Feb 2006 14:31:23 +0100,
Patrizio Bassi wrote:
> 
> Takashi Iwai ha scritto:
> > At Mon, 13 Feb 2006 13:37:55 +0100,
> > Patrizio Bassi wrote:
> >   
> >> Takashi Iwai ha scritto:
> >>     
> >>> At Sun, 12 Feb 2006 19:05:20 -0800,
> >>> Andrew Morton wrote:
> >>>   
> >>>       
> >>>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> >>>>   regression ("alsa suspend/resume continues to fail for ens1370")
> >>>>     
> >>>>         
> >>> It's not a "regression".  PM didn't work with ens1370 at all in the
> >>> eralier version.
> >>>
> >>> About the problem there, I have no idea now what's wrong.  The
> >>> suspend-to-disk works fine if the driver is built as module but not as
> >>> built-in kernel.
> >>>
> >>>
> >>>   
> >>>       
> >> i wrote "regression" because before (ehm...exactly don't know...about
> >> 2.6.14 time)
> >> after suspend i had to restart my distro's mixer values service or i
> >> couldn't hear anything.
> >> and...ok..it was boring but worked.
> >>     
> >
> > You abused the function which wasn't officially supported :)
> >
> >
> > Takashi
> >
> >   
> nice i'm an abuser! :)
> 
> ok, seriously..that's bad, because before it was not implemented, so ok...
> but now it fails with errors (and make apps not working properly) which
> is worse.

My rough guess is the initialization order, the resume was called too
early.

What about to put sleep between snd_ensoniq_chip_init() and
snd_ak4531_resume()?  Or put more delay in snd_ak4531_resume()?


Takashi

Re: Linux 2.6.16-rc3

[Takashi Iwai]

At Mon, 13 Feb 2006 14:31:23 +0100,
Patrizio Bassi wrote:
> 
> Takashi Iwai ha scritto:
> > At Mon, 13 Feb 2006 13:37:55 +0100,
> > Patrizio Bassi wrote:
> >   
> >> Takashi Iwai ha scritto:
> >>     
> >>> At Sun, 12 Feb 2006 19:05:20 -0800,
> >>> Andrew Morton wrote:
> >>>   
> >>>       
> >>>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> >>>>   regression ("alsa suspend/resume continues to fail for ens1370")
> >>>>     
> >>>>         
> >>> It's not a "regression".  PM didn't work with ens1370 at all in the
> >>> eralier version.
> >>>
> >>> About the problem there, I have no idea now what's wrong.  The
> >>> suspend-to-disk works fine if the driver is built as module but not as
> >>> built-in kernel.
> >>>
> >>>
> >>>   
> >>>       
> >> i wrote "regression" because before (ehm...exactly don't know...about
> >> 2.6.14 time)
> >> after suspend i had to restart my distro's mixer values service or i
> >> couldn't hear anything.
> >> and...ok..it was boring but worked.
> >>     
> >
> > You abused the function which wasn't officially supported :)
> >
> >
> > Takashi
> >
> >   
> nice i'm an abuser! :)
> 
> ok, seriously..that's bad, because before it was not implemented, so ok...
> but now it fails with errors (and make apps not working properly) which
> is worse.

My rough guess is the initialization order, the resume was called too
early.

What about to put sleep between snd_ensoniq_chip_init() and
snd_ak4531_resume()?  Or put more delay in snd_ak4531_resume()?


Takashi

Re: Linux 2.6.16-rc3

[Takashi Iwai]

At Mon, 13 Feb 2006 14:09:51 +0100,
Rafael J. Wysocki wrote:
> 
> On Monday 13 February 2006 13:02, Takashi Iwai wrote:
> > At Sun, 12 Feb 2006 19:05:20 -0800,
> > Andrew Morton wrote:
> > > 
> > > - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> > >   regression ("alsa suspend/resume continues to fail for ens1370")
> > 
> > It's not a "regression".  PM didn't work with ens1370 at all in the
> > eralier version.
> > 
> > About the problem there, I have no idea now what's wrong.  The
> > suspend-to-disk works fine if the driver is built as module but not as
> > built-in kernel.
> 
> That may be related to the fact that modular drivers are not present in
> memory during resume (just a thought).

I think the modular drivers are on memory but the order of
re-initialization is different.


Takashi

Re: Linux 2.6.16-rc3

[Takashi Iwai]

At Mon, 13 Feb 2006 14:09:51 +0100,
Rafael J. Wysocki wrote:
> 
> On Monday 13 February 2006 13:02, Takashi Iwai wrote:
> > At Sun, 12 Feb 2006 19:05:20 -0800,
> > Andrew Morton wrote:
> > > 
> > > - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> > >   regression ("alsa suspend/resume continues to fail for ens1370")
> > 
> > It's not a "regression".  PM didn't work with ens1370 at all in the
> > eralier version.
> > 
> > About the problem there, I have no idea now what's wrong.  The
> > suspend-to-disk works fine if the driver is built as module but not as
> > built-in kernel.
> 
> That may be related to the fact that modular drivers are not present in
> memory during resume (just a thought).

I think the modular drivers are on memory but the order of
re-initialization is different.


Takashi

Re: Linux 2.6.16-rc3

[Patrizio Bassi]

Takashi Iwai ha scritto:
> At Mon, 13 Feb 2006 13:37:55 +0100,
> Patrizio Bassi wrote:
>   
>> Takashi Iwai ha scritto:
>>     
>>> At Sun, 12 Feb 2006 19:05:20 -0800,
>>> Andrew Morton wrote:
>>>   
>>>       
>>>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
>>>>   regression ("alsa suspend/resume continues to fail for ens1370")
>>>>     
>>>>         
>>> It's not a "regression".  PM didn't work with ens1370 at all in the
>>> eralier version.
>>>
>>> About the problem there, I have no idea now what's wrong.  The
>>> suspend-to-disk works fine if the driver is built as module but not as
>>> built-in kernel.
>>>
>>>
>>>   
>>>       
>> i wrote "regression" because before (ehm...exactly don't know...about
>> 2.6.14 time)
>> after suspend i had to restart my distro's mixer values service or i
>> couldn't hear anything.
>> and...ok..it was boring but worked.
>>     
>
> You abused the function which wasn't officially supported :)
>
>
> Takashi
>
>   
nice i'm an abuser! :)

ok, seriously..that's bad, because before it was not implemented, so ok...
but now it fails with errors (and make apps not working properly) which
is worse.

Patrizio

Re: Linux 2.6.16-rc3

[Patrizio Bassi]

Takashi Iwai ha scritto:
> At Mon, 13 Feb 2006 13:37:55 +0100,
> Patrizio Bassi wrote:
>   
>> Takashi Iwai ha scritto:
>>     
>>> At Sun, 12 Feb 2006 19:05:20 -0800,
>>> Andrew Morton wrote:
>>>   
>>>       
>>>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
>>>>   regression ("alsa suspend/resume continues to fail for ens1370")
>>>>     
>>>>         
>>> It's not a "regression".  PM didn't work with ens1370 at all in the
>>> eralier version.
>>>
>>> About the problem there, I have no idea now what's wrong.  The
>>> suspend-to-disk works fine if the driver is built as module but not as
>>> built-in kernel.
>>>
>>>
>>>   
>>>       
>> i wrote "regression" because before (ehm...exactly don't know...about
>> 2.6.14 time)
>> after suspend i had to restart my distro's mixer values service or i
>> couldn't hear anything.
>> and...ok..it was boring but worked.
>>     
>
> You abused the function which wasn't officially supported :)
>
>
> Takashi
>
>   
nice i'm an abuser! :)

ok, seriously..that's bad, because before it was not implemented, so ok...
but now it fails with errors (and make apps not working properly) which
is worse.

Patrizio

Re: Linux 2.6.16-rc3

[Takashi Iwai]

At Mon, 13 Feb 2006 13:37:55 +0100,
Patrizio Bassi wrote:
> 
> Takashi Iwai ha scritto:
> > At Sun, 12 Feb 2006 19:05:20 -0800,
> > Andrew Morton wrote:
> >   
> >> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> >>   regression ("alsa suspend/resume continues to fail for ens1370")
> >>     
> >
> > It's not a "regression".  PM didn't work with ens1370 at all in the
> > eralier version.
> >
> > About the problem there, I have no idea now what's wrong.  The
> > suspend-to-disk works fine if the driver is built as module but not as
> > built-in kernel.
> >
> >
> >   
> i wrote "regression" because before (ehm...exactly don't know...about
> 2.6.14 time)
> after suspend i had to restart my distro's mixer values service or i
> couldn't hear anything.
> and...ok..it was boring but worked.

You abused the function which wasn't officially supported :)


Takashi

Re: Linux 2.6.16-rc3

[Takashi Iwai]

At Mon, 13 Feb 2006 13:37:55 +0100,
Patrizio Bassi wrote:
> 
> Takashi Iwai ha scritto:
> > At Sun, 12 Feb 2006 19:05:20 -0800,
> > Andrew Morton wrote:
> >   
> >> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> >>   regression ("alsa suspend/resume continues to fail for ens1370")
> >>     
> >
> > It's not a "regression".  PM didn't work with ens1370 at all in the
> > eralier version.
> >
> > About the problem there, I have no idea now what's wrong.  The
> > suspend-to-disk works fine if the driver is built as module but not as
> > built-in kernel.
> >
> >
> >   
> i wrote "regression" because before (ehm...exactly don't know...about
> 2.6.14 time)
> after suspend i had to restart my distro's mixer values service or i
> couldn't hear anything.
> and...ok..it was boring but worked.

You abused the function which wasn't officially supported :)


Takashi

Re: Linux 2.6.16-rc3

[Rafael J. Wysocki]

On Monday 13 February 2006 13:02, Takashi Iwai wrote:
> At Sun, 12 Feb 2006 19:05:20 -0800,
> Andrew Morton wrote:
> > 
> > - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> >   regression ("alsa suspend/resume continues to fail for ens1370")
> 
> It's not a "regression".  PM didn't work with ens1370 at all in the
> eralier version.
> 
> About the problem there, I have no idea now what's wrong.  The
> suspend-to-disk works fine if the driver is built as module but not as
> built-in kernel.

That may be related to the fact that modular drivers are not present in
memory during resume (just a thought).

Greetings,
Rafael

Re: Linux 2.6.16-rc3

[Rafael J. Wysocki]

On Monday 13 February 2006 13:02, Takashi Iwai wrote:
> At Sun, 12 Feb 2006 19:05:20 -0800,
> Andrew Morton wrote:
> > 
> > - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
> >   regression ("alsa suspend/resume continues to fail for ens1370")
> 
> It's not a "regression".  PM didn't work with ens1370 at all in the
> eralier version.
> 
> About the problem there, I have no idea now what's wrong.  The
> suspend-to-disk works fine if the driver is built as module but not as
> built-in kernel.

That may be related to the fact that modular drivers are not present in
memory during resume (just a thought).

Greetings,
Rafael

Re: Linux 2.6.16-rc3

[Patrizio Bassi]

Takashi Iwai ha scritto:
> At Sun, 12 Feb 2006 19:05:20 -0800,
> Andrew Morton wrote:
>   
>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
>>   regression ("alsa suspend/resume continues to fail for ens1370")
>>     
>
> It's not a "regression".  PM didn't work with ens1370 at all in the
> eralier version.
>
> About the problem there, I have no idea now what's wrong.  The
> suspend-to-disk works fine if the driver is built as module but not as
> built-in kernel.
>
>
>   
i wrote "regression" because before (ehm...exactly don't know...about
2.6.14 time)
after suspend i had to restart my distro's mixer values service or i
couldn't hear anything.
and...ok..it was boring but worked.

now i get 0x660 errors if i try to restore values and device seems dead,
just flood the syslog.
sound apps slow down (like 100% cpu usage) and no sound produced.

only fix is reboot.


>> - ghrt <ghrt@dial.kappa.ro> reports an alsa regression ("PROBLEM: SB
>>   Live!  5.1 (emu10k1, rev.  0a) doesn't work with 2.6.15")
>>     
>
> I couldn't find this bugzilla entry...
>
>
> Takashi
>
>   

Re: Linux 2.6.16-rc3

[Patrizio Bassi]

Takashi Iwai ha scritto:
> At Sun, 12 Feb 2006 19:05:20 -0800,
> Andrew Morton wrote:
>   
>> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
>>   regression ("alsa suspend/resume continues to fail for ens1370")
>>     
>
> It's not a "regression".  PM didn't work with ens1370 at all in the
> eralier version.
>
> About the problem there, I have no idea now what's wrong.  The
> suspend-to-disk works fine if the driver is built as module but not as
> built-in kernel.
>
>
>   
i wrote "regression" because before (ehm...exactly don't know...about
2.6.14 time)
after suspend i had to restart my distro's mixer values service or i
couldn't hear anything.
and...ok..it was boring but worked.

now i get 0x660 errors if i try to restore values and device seems dead,
just flood the syslog.
sound apps slow down (like 100% cpu usage) and no sound produced.

only fix is reboot.


>> - ghrt <ghrt@dial.kappa.ro> reports an alsa regression ("PROBLEM: SB
>>   Live!  5.1 (emu10k1, rev.  0a) doesn't work with 2.6.15")
>>     
>
> I couldn't find this bugzilla entry...
>
>
> Takashi
>
>   

Re: Linux 2.6.16-rc3

[Takashi Iwai]

At Sun, 12 Feb 2006 19:05:20 -0800,
Andrew Morton wrote:
> 
> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
>   regression ("alsa suspend/resume continues to fail for ens1370")

It's not a "regression".  PM didn't work with ens1370 at all in the
eralier version.

About the problem there, I have no idea now what's wrong.  The
suspend-to-disk works fine if the driver is built as module but not as
built-in kernel.


> - ghrt <ghrt@dial.kappa.ro> reports an alsa regression ("PROBLEM: SB
>   Live!  5.1 (emu10k1, rev.  0a) doesn't work with 2.6.15")

I couldn't find this bugzilla entry...


Takashi

Re: Linux 2.6.16-rc3

[Takashi Iwai]

At Sun, 12 Feb 2006 19:05:20 -0800,
Andrew Morton wrote:
> 
> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
>   regression ("alsa suspend/resume continues to fail for ens1370")

It's not a "regression".  PM didn't work with ens1370 at all in the
eralier version.

About the problem there, I have no idea now what's wrong.  The
suspend-to-disk works fine if the driver is built as module but not as
built-in kernel.


> - ghrt <ghrt@dial.kappa.ro> reports an alsa regression ("PROBLEM: SB
>   Live!  5.1 (emu10k1, rev.  0a) doesn't work with 2.6.15")

I couldn't find this bugzilla entry...


Takashi

Re: Linux 2.6.16-rc3

[Andrew Morton]

Avuton Olrich <avuton@gmail.com> wrote:
>
> I should have realized that would happen, hopefully here's a better
>  one. Please let me know anything I can do to help.
> 
>  http://68.111.224.150:8080/~sbh/P1010031.JPG

Thanks.  Yes, it does look like the same bug.

Re: Linux 2.6.16-rc3

[Con Kolivas]

On Monday 13 February 2006 21:39, Andrew Morton wrote:
> That looks like a different cpufreq bug.  Unfortunately the critical first
> few lines have scrolled away.  Please boot with `vga=extended' so we get to
> see them.

Just as a suggestion, why don't we print oopsen out in the opposite direction 
so the critical information is in the last few lines and the stacktrace in 
reverse, or have that as a bootparam option oops=reverse .

Cheers,
Con

Re: Linux 2.6.16-rc3

[Andrew Morton]

Avuton Olrich <avuton@gmail.com> wrote:
>
> On 2/12/06, Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > Ok,
> >  it is out there (or in the process of getting mirrored out), so go wild.
> 
> Hello, I appear to be getting the same issue I had back here:
> http://lkml.org/lkml/2006/2/1/121
> 
> A fix appeared a few messages later:
> http://lkml.org/lkml/2006/2/1/129
> http://lkml.org/lkml/2006/2/1/131
> 
> I'm obviously unsure if these were correct fixes or what but they did
> fix it, and they were or are in -mm afaik.
> 
> I am not _sure_ this is the same bug, but the panic messages rings a
> bell (sorry, I already deleted the old pictures as it appeared to be
> taken care of in -mm).
> 
> In the case that it's not the same issue here's a new snapshot of the
> kernel panic:
> http://68.111.224.150:8080/~sbh/P1010029.JPG
> ..and the config:
> http://68.111.224.150:8080/~sbh/micromachine.config
> 
> If an essential part of the panic is missing please let me know and I
> will try to remember how I got it shrunk down better last time.
> 

That looks like a different cpufreq bug.  Unfortunately the critical first
few lines have scrolled away.  Please boot with `vga=extended' so we get to
see them.

Re: Linux 2.6.16-rc3

[Patrizio Bassi]

Andrew Morton ha scritto:
> We still have some serious bugs, several of which are in 2.6.15 as well:
>
> - The scsi_cmd leak, which I don't think is fixed.
>
> - The some-x86_64-boxes-use-GFP_DMA-from-bio-layer bug, which causes
>   oom-killings.
>
> - The skbuff_head_cache leak, which has been around since at least
>   2.6.11.  Another box-killer, but is seems very hard to hit. 
>   (mki@mozone.net, "the dreaded oom-killer (reproducable in 2.6.11 -
>   2.6.16-rc1) :(")
>
> - http://bugzilla.kernel.org/show_bug.cgi?id=6060: an apparent ACPI
>   regression.
>
> - Nathan's "sysfs-related oops during module unload", which Greg seems to
>   have under control.
>
> - http://bugzilla.kernel.org/show_bug.cgi?id=6049 - another acpi
>   regression.  We have the actual offending commit here.
>
> - A couple of random tty-related oopses reported by Jesper Juhl.  We
>   don't know why these happened - they appear to not be related to the tty
>   buffering changes.
>
> - http://bugzilla.kernel.org/show_bug.cgi?id=6038, another box-killing
>   acpi regression.
>
> - Various reports similar to
>   http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
>   PCI quirk handling.
>
> - "Ben Castricum" <lk@bencastricum.nl> reports that ppp has started
>   exhibiting mysterious failures (again).
>
> - Nasty warnings from scsi about kobject-layer things being called from
>   irq context.  James has a push-it-to-process-context patch which sadly
>   assumes kmalloc() is immortal, but no other fix seems to have offered
>   itself.
>
> - In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy Mahajan has
>   another regression, but he's off collecting more info.
>
> - Helge Hafting reports a usb printer regression - I don't know if that's
>   still live?
>
> - "Carlo E.  Prelz" <fluido@fluido.as> has another USB/ehci regression
>   ("ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15
>   rc1").
>
> - Gerrit Bruchhuser <gbruchhaeuser@gmx.de> seems to have an aic7xxx
>   regression ("AHA-7850 doesn't detect scanner anymore") but he doesn't say
>   which kernel got it right.
>
> - http://bugzilla.kernel.org/show_bug.cgi?id=5914 - a sata bug (which is
>   quite unremarkable :(), but this one is reported to eat filesystems.
>
> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
>   regression ("alsa suspend/resume continues to fail for ens1370")
>
> - Bjorn Nilsson <bni.swe@gmail.com> has an sk99lin regression ("3COM
>   3C940, does not work anymore after upgrade to 2.6.15")
>
> - Andrey Borzenkov <arvidjaar@mail.ru> has an acpi-cpufreq regression
>   ("cannot unload acpi-cpufreq")
>
> - "P.  Christeas" <p_christ@hol.gr> had an autofs regression ("Regression
>   in Autofs, 2.6.15-git"), whic might be fixed now?
>
> - ghrt <ghrt@dial.kappa.ro> reports an alsa regression ("PROBLEM: SB
>   Live!  5.1 (emu10k1, rev.  0a) doesn't work with 2.6.15")
>
> - jinhong hu <jinhong.hu@gmail.com> reports what appears to be a qlogic
>   regression ("kernel 2.6.15 scsi problem")
>
> - Benjamin LaHaise <bcrl@kvack.org> had an NFS problem ("NFS processes
>   gettting stuck in D with currrent git").
>
>
>
> These are clear regressions, reported in the last month by people who are
> willing to test patches.  They're almost all in subsystems which have
> active and professional maintainers.
>
>   
Really sad to say, but my Alsa ens1370 regression due to suspend problem
is still there.
Only fix is reboot actually. Ready to patch :)

PS.

i have a bug similar to:
http://bugzilla.kernel.org/show_bug.cgi?id=6038 (marked as blocking by
Andrew)
on my laptop.

but my dma expiry problem only happens during suspend.
I have a Sis 630 chipset with a 2.5" hitachi drive.
Been there...for ages..i can say: always...never got a working 2.6 kernel.
However in my poor opinion it's not blocking on my system, just boring.


Patrizio

Re: Linux 2.6.16-rc3

[Patrizio Bassi]

Andrew Morton ha scritto:
> We still have some serious bugs, several of which are in 2.6.15 as well:
>
> - The scsi_cmd leak, which I don't think is fixed.
>
> - The some-x86_64-boxes-use-GFP_DMA-from-bio-layer bug, which causes
>   oom-killings.
>
> - The skbuff_head_cache leak, which has been around since at least
>   2.6.11.  Another box-killer, but is seems very hard to hit. 
>   (mki@mozone.net, "the dreaded oom-killer (reproducable in 2.6.11 -
>   2.6.16-rc1) :(")
>
> - http://bugzilla.kernel.org/show_bug.cgi?id=6060: an apparent ACPI
>   regression.
>
> - Nathan's "sysfs-related oops during module unload", which Greg seems to
>   have under control.
>
> - http://bugzilla.kernel.org/show_bug.cgi?id=6049 - another acpi
>   regression.  We have the actual offending commit here.
>
> - A couple of random tty-related oopses reported by Jesper Juhl.  We
>   don't know why these happened - they appear to not be related to the tty
>   buffering changes.
>
> - http://bugzilla.kernel.org/show_bug.cgi?id=6038, another box-killing
>   acpi regression.
>
> - Various reports similar to
>   http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
>   PCI quirk handling.
>
> - "Ben Castricum" <lk@bencastricum.nl> reports that ppp has started
>   exhibiting mysterious failures (again).
>
> - Nasty warnings from scsi about kobject-layer things being called from
>   irq context.  James has a push-it-to-process-context patch which sadly
>   assumes kmalloc() is immortal, but no other fix seems to have offered
>   itself.
>
> - In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy Mahajan has
>   another regression, but he's off collecting more info.
>
> - Helge Hafting reports a usb printer regression - I don't know if that's
>   still live?
>
> - "Carlo E.  Prelz" <fluido@fluido.as> has another USB/ehci regression
>   ("ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15
>   rc1").
>
> - Gerrit Bruchhuser <gbruchhaeuser@gmx.de> seems to have an aic7xxx
>   regression ("AHA-7850 doesn't detect scanner anymore") but he doesn't say
>   which kernel got it right.
>
> - http://bugzilla.kernel.org/show_bug.cgi?id=5914 - a sata bug (which is
>   quite unremarkable :(), but this one is reported to eat filesystems.
>
> - Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
>   regression ("alsa suspend/resume continues to fail for ens1370")
>
> - Bjorn Nilsson <bni.swe@gmail.com> has an sk99lin regression ("3COM
>   3C940, does not work anymore after upgrade to 2.6.15")
>
> - Andrey Borzenkov <arvidjaar@mail.ru> has an acpi-cpufreq regression
>   ("cannot unload acpi-cpufreq")
>
> - "P.  Christeas" <p_christ@hol.gr> had an autofs regression ("Regression
>   in Autofs, 2.6.15-git"), whic might be fixed now?
>
> - ghrt <ghrt@dial.kappa.ro> reports an alsa regression ("PROBLEM: SB
>   Live!  5.1 (emu10k1, rev.  0a) doesn't work with 2.6.15")
>
> - jinhong hu <jinhong.hu@gmail.com> reports what appears to be a qlogic
>   regression ("kernel 2.6.15 scsi problem")
>
> - Benjamin LaHaise <bcrl@kvack.org> had an NFS problem ("NFS processes
>   gettting stuck in D with currrent git").
>
>
>
> These are clear regressions, reported in the last month by people who are
> willing to test patches.  They're almost all in subsystems which have
> active and professional maintainers.
>
>   
Really sad to say, but my Alsa ens1370 regression due to suspend problem
is still there.
Only fix is reboot actually. Ready to patch :)

PS.

i have a bug similar to:
http://bugzilla.kernel.org/show_bug.cgi?id=6038 (marked as blocking by
Andrew)
on my laptop.

but my dma expiry problem only happens during suspend.
I have a Sis 630 chipset with a 2.5" hitachi drive.
Been there...for ages..i can say: always...never got a working 2.6 kernel.
However in my poor opinion it's not blocking on my system, just boring.


Patrizio

Re: Linux 2.6.16-rc3

[Yoichi Yuasa]

Hi Jan

On Mon, 13 Feb 2006 09:46:56 +0100
Jan Dittmer <jdi@l4x.org> wrote:

> Linus Torvalds wrote:
> > The most user-visible one (eventually) is the unshare() system call, which 
> > glibc wanted. Along with some fixes for fstatat() (use the proper 64-bit 
> > interfaces, not the "newer old" one).
> 
> This breaks compilation on 3 archs compared to -rc2:
> 
> - mips: broke
>      AR      arch/mips/lib-32/lib.a
>      GEN     .version
>      CHK     include/linux/compile.h
>      UPD     include/linux/compile.h
>      CC      init/version.o
>      LD      init/built-in.o
>      LD      .tmp_vmlinux1
>    arch/mips/kernel/built-in.o(.text+0x9820): In function `einval':
>    /usr/src/ctest/rc/kernel/arch/mips/kernel/scall32-o32.S: undefined reference to `sys_newfstatat'
>    make[1]: *** [.tmp_vmlinux1] Error 1
>    make: *** [cdbuilddir] Error 2
> 
> 
>    Details: http://l4x.org/k/?d=10888

MIPS 32bit machines need fstatat64 support.

Yoichi

Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>

diff --git a/arch/mips/kernel/scall32-o32.S b/arch/mips/kernel/scall32-o32.S
index d7c4a38..d83e033 100644
--- a/arch/mips/kernel/scall32-o32.S
+++ b/arch/mips/kernel/scall32-o32.S
@@ -623,7 +623,7 @@ einval:	li	v0, -EINVAL
 	sys	sys_mknodat		4	/* 4290 */
 	sys	sys_fchownat		5
 	sys	sys_futimesat		3
-	sys	sys_newfstatat		4
+	sys	sys_fstatat64		4
 	sys	sys_unlinkat		3
 	sys	sys_renameat		4	/* 4295 */
 	sys	sys_linkat		4

Re: Linux 2.6.16-rc3

[Jan Dittmer]

Linus Torvalds wrote:
> The most user-visible one (eventually) is the unshare() system call, which 
> glibc wanted. Along with some fixes for fstatat() (use the proper 64-bit 
> interfaces, not the "newer old" one).

This breaks compilation on 3 archs compared to -rc2:

- mips: broke
     AR      arch/mips/lib-32/lib.a
     GEN     .version
     CHK     include/linux/compile.h
     UPD     include/linux/compile.h
     CC      init/version.o
     LD      init/built-in.o
     LD      .tmp_vmlinux1
   arch/mips/kernel/built-in.o(.text+0x9820): In function `einval':
   /usr/src/ctest/rc/kernel/arch/mips/kernel/scall32-o32.S: undefined reference to `sys_newfstatat'
   make[1]: *** [.tmp_vmlinux1] Error 1
   make: *** [cdbuilddir] Error 2


   Details: http://l4x.org/k/?d=10888

- sparc: broke
     SYSMAP  System.map
     SYSMAP  .tmp_System.map
     HOSTCC  arch/sparc/boot/btfixupprep
     BTFIX   arch/sparc/boot/btfix.S
     AS      arch/sparc/boot/btfix.o
     LD      arch/sparc/boot/image
   arch/sparc/kernel/built-in.o(.data+0x794): In function `sys_call_table':
   : undefined reference to `sys_newfstatat'
   make[2]: *** [arch/sparc/boot/image] Error 1
   make[1]: *** [image] Error 2
   make: *** [cdbuilddir] Error 2


   Details: http://l4x.org/k/?d=10897

- sparc64: broke
     AR      arch/sparc64/lib/lib.a
     GEN     .version
     CHK     include/linux/compile.h
     UPD     include/linux/compile.h
     CC      init/version.o
     LD      init/built-in.o
     LD      .tmp_vmlinux1
   arch/sparc64/kernel/head.o(.text+0xe78): In function `sys_call_table':
   /usr/src/ctest/rc/kernel/arch/sparc64/kernel/head.S: undefined reference to `sys_newfstatat'
   make[1]: *** [.tmp_vmlinux1] Error 1
   make: *** [cdbuilddir] Error 2


   Details: http://l4x.org/k/?d=10898

Jan

Re: Linux 2.6.16-rc3

[Jens Axboe]

On Sun, Feb 12 2006, Andrew Morton wrote:
> 
> We still have some serious bugs, several of which are in 2.6.15 as well:
> 
> - The scsi_cmd leak, which I don't think is fixed.

It is fixed in 2.6.16-rcX.

> - The some-x86_64-boxes-use-GFP_DMA-from-bio-layer bug, which causes
>   oom-killings.

Still pending.

-- 
Jens Axboe

Re: Linux 2.6.16-rc3

[Jens Axboe]

On Sun, Feb 12 2006, Andrew Morton wrote:
> 
> We still have some serious bugs, several of which are in 2.6.15 as well:
> 
> - The scsi_cmd leak, which I don't think is fixed.

It is fixed in 2.6.16-rcX.

> - The some-x86_64-boxes-use-GFP_DMA-from-bio-layer bug, which causes
>   oom-killings.

Still pending.

-- 
Jens Axboe

Re: Linux 2.6.16-rc3

[Sanjoy Mahajan]

> systems newer than 6 years old.

According to the sticker on the bottom, this model was made in
04/2000, so the 6 years is right.

> We're talking here about a system from 1999 where Windows 98 refuses
> to run in ACPI mode and instead runs in APM mode.

I haven't tried Windows 98 on this machine, but Windows 98SE would run
in ACPI mode if it weren't for a cheap hack by IBM.  The latest BIOS
(1.11), which I'm using, claims to be from 1999.  However, that date
is almost surely wrong.  The readme/changelog with the BIOS update
diskette is dated Sept 20, 2001 and contains this note about the 1.01
update:

 - (Fix) If Windows 98 Second Edition is installed as APM mode and
         an updated BIOS is installed with a BIOS date 12/02/99 or 
         later, Windows 98SE will change the mode from APM to ACPI 
         whenever a New hardware profile is created.  So this BIOS 
         set the date to 11-30-99. 

Probably IBM marked all the BIOS dates as 11-30-99 in order to work
around this W98SE misfeature.  My guess is that BIOS 1.11 is really
from Sept 2001, or 4.5 years ago.  Old, but not octagenerian!

> I consider that it works in ACPI mode at all as "miraculous":-)

Amen to that.  I was very pleased when the combination of newer ACPI
releases plus my modifying the DSDT made S3 work.

> I do think the issue merits investigation ...

Although I have little idea of what sections of code to modify,
especially since the commit in question merges two well travelled
branches, I'm happy to test patches.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

Re: Linux 2.6.16-rc3

[Sanjoy Mahajan]

> systems newer than 6 years old.

According to the sticker on the bottom, this model was made in
04/2000, so the 6 years is right.

> We're talking here about a system from 1999 where Windows 98 refuses
> to run in ACPI mode and instead runs in APM mode.

I haven't tried Windows 98 on this machine, but Windows 98SE would run
in ACPI mode if it weren't for a cheap hack by IBM.  The latest BIOS
(1.11), which I'm using, claims to be from 1999.  However, that date
is almost surely wrong.  The readme/changelog with the BIOS update
diskette is dated Sept 20, 2001 and contains this note about the 1.01
update:

 - (Fix) If Windows 98 Second Edition is installed as APM mode and
         an updated BIOS is installed with a BIOS date 12/02/99 or 
         later, Windows 98SE will change the mode from APM to ACPI 
         whenever a New hardware profile is created.  So this BIOS 
         set the date to 11-30-99. 

Probably IBM marked all the BIOS dates as 11-30-99 in order to work
around this W98SE misfeature.  My guess is that BIOS 1.11 is really
from Sept 2001, or 4.5 years ago.  Old, but not octagenerian!

> I consider that it works in ACPI mode at all as "miraculous":-)

Amen to that.  I was very pleased when the combination of newer ACPI
releases plus my modifying the DSDT made S3 work.

> I do think the issue merits investigation ...

Although I have little idea of what sections of code to modify,
especially since the commit in question merges two well travelled
branches, I'm happy to test patches.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

Re: Linux 2.6.16-rc3

[David S. Miller]

From: "Brown, Len" <len.brown@intel.com>
Date: Mon, 13 Feb 2006 02:07:50 -0500

> >- In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy 
> >Mahajan has  another regression, but he's off collecting more info.
> 
> We're talking here about a system from 1999 where Windows 98
> refuses to run in ACPI mode and instead runs in APM mode.

If it worked before a change which was installed, it's a regression
regardless of whether another OS tries to use ACPI on that system or
not.  I don't understand how one can use that fact to label this as
not a regression from Linux's perspective.

RE: Linux 2.6.16-rc3

[Brown, Len]

 
>- In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy 
>Mahajan has  another regression, but he's off collecting more info.

We're talking here about a system from 1999 where Windows 98
refuses to run in ACPI mode and instead runs in APM mode.
So I don't consider a regression on this box as "serious" --
I consider that it works in ACPI mode at all as "miraculous":-)

However, I do think the issue merits investigation in the event
that it has an effect on systems newer than 6 years old.

thanks,
-Len

RE: Linux 2.6.16-rc3

[Brown, Len]

 
>- In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy 
>Mahajan has  another regression, but he's off collecting more info.

We're talking here about a system from 1999 where Windows 98
refuses to run in ACPI mode and instead runs in APM mode.
So I don't consider a regression on this box as "serious" --
I consider that it works in ACPI mode at all as "miraculous":-)

However, I do think the issue merits investigation in the event
that it has an effect on systems newer than 6 years old.

thanks,
-Len

Re: Linux 2.6.16-rc3

[Arjan van de Ven]

On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> We still have some serious bugs, several of which are in 2.6.15 as well:
> 
> - The scsi_cmd leak, which I don't think is fixed.

didn't this got nailed down to a 2.6.15 specific queueing bug, fixed in
2.6.16-rc ?

Re: Linux 2.6.16-rc3

[Arjan van de Ven]

On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> We still have some serious bugs, several of which are in 2.6.15 as well:
> 
> - The scsi_cmd leak, which I don't think is fixed.

didn't this got nailed down to a 2.6.15 specific queueing bug, fixed in
2.6.16-rc ?

RE: Linux 2.6.16-rc3

[Brown, Len]

 
>- http://bugzilla.kernel.org/show_bug.cgi?id=6049 - another acpi
>  regression.  We have the actual offending commit here.

per my note in the bug report, I believe that this failure
is not related to the "offending commit", and thus that commit
should not be reverted.  I believe that this failure is because
the system is booted with "pci=noacpi" in IOAPIC mode --
and unsuportable configuration -- and will endeavor to confirm...

thanks,
-Len

RE: Linux 2.6.16-rc3

[Brown, Len]

 
>- http://bugzilla.kernel.org/show_bug.cgi?id=6049 - another acpi
>  regression.  We have the actual offending commit here.

per my note in the bug report, I believe that this failure
is not related to the "offending commit", and thus that commit
should not be reverted.  I believe that this failure is because
the system is booted with "pci=noacpi" in IOAPIC mode --
and unsuportable configuration -- and will endeavor to confirm...

thanks,
-Len

Re: Linux 2.6.16-rc3

[James Bottomley]

On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> - The scsi_cmd leak, which I don't think is fixed.

Erm, you mean the leak caused by flush barriers?  That was verified as
fixed (albeit accidentally) in 2.6.16-rc1.

James

Re: Linux 2.6.16-rc3

[James Bottomley]

On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> - The scsi_cmd leak, which I don't think is fixed.

Erm, you mean the leak caused by flush barriers?  That was verified as
fixed (albeit accidentally) in 2.6.16-rc1.

James

Re: Linux 2.6.16-rc3

[Jeff Garzik]

Andrew Morton wrote:
> - http://bugzilla.kernel.org/show_bug.cgi?id=5914 - a sata bug (which is
>   quite unremarkable :(), but this one is reported to eat filesystems.

Issue closed, as the bug notes...

	Jeff

Re: Linux 2.6.16-rc3

[Jeff Garzik]

Andrew Morton wrote:
> - http://bugzilla.kernel.org/show_bug.cgi?id=5914 - a sata bug (which is
>   quite unremarkable :(), but this one is reported to eat filesystems.

Issue closed, as the bug notes...

	Jeff

Re: Linux 2.6.16-rc3

[Sanjoy Mahajan]

> In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy Mahajan has
> another regression, but he's off collecting more info.

I'm nearly done with bisecting (spent a day on a wild bisect goose
chase due to being careless) and I'm 95% sure the problem is
introduced by:

commit b8e4d89357fc434618a59c1047cac72641191805
Author: Bob Moore <robert.moore@intel.com>
Date:   Fri Jan 27 16:43:00 2006 -0500

    [ACPI] ACPICA 20060127

But I will know for sure shortly.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

Re: Linux 2.6.16-rc3

[Sanjoy Mahajan]

> In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy Mahajan has
> another regression, but he's off collecting more info.

I'm nearly done with bisecting (spent a day on a wild bisect goose
chase due to being careless) and I'm 95% sure the problem is
introduced by:

commit b8e4d89357fc434618a59c1047cac72641191805
Author: Bob Moore <robert.moore@intel.com>
Date:   Fri Jan 27 16:43:00 2006 -0500

    [ACPI] ACPICA 20060127

But I will know for sure shortly.

-Sanjoy

`Never underestimate the evil of which men of power are capable.'
         --Bertrand Russell, _War Crimes in Vietnam_, chapter 1.

Re: Linux 2.6.16-rc3

[Trond Myklebust]

On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> We still have some serious bugs, several of which are in 2.6.15 as well:

> - Benjamin LaHaise <bcrl@kvack.org> had an NFS problem ("NFS processes
>   gettting stuck in D with currrent git").

...but which was apparently not repeatable:

        As of this afternoon's tree
        (6150c32589d1976ca8a5c987df951088c05a7542)  after the more
        recent set of nfs patches, it seems to be behaving itself.  Will
        keep sysrq enabled to see if it hits again, though.

I've had no news from Ben since then...

Cheers,
  Trond

Re: Linux 2.6.16-rc3

[Trond Myklebust]

On Sun, 2006-02-12 at 19:05 -0800, Andrew Morton wrote:
> We still have some serious bugs, several of which are in 2.6.15 as well:

> - Benjamin LaHaise <bcrl@kvack.org> had an NFS problem ("NFS processes
>   gettting stuck in D with currrent git").

...but which was apparently not repeatable:

        As of this afternoon's tree
        (6150c32589d1976ca8a5c987df951088c05a7542)  after the more
        recent set of nfs patches, it seems to be behaving itself.  Will
        keep sysrq enabled to see if it hits again, though.

I've had no news from Ben since then...

Cheers,
  Trond

Re: Linux 2.6.16-rc3

[Andrew Morton]

We still have some serious bugs, several of which are in 2.6.15 as well:

- The scsi_cmd leak, which I don't think is fixed.

- The some-x86_64-boxes-use-GFP_DMA-from-bio-layer bug, which causes
  oom-killings.

- The skbuff_head_cache leak, which has been around since at least
  2.6.11.  Another box-killer, but is seems very hard to hit. 
  (mki@mozone.net, "the dreaded oom-killer (reproducable in 2.6.11 -
  2.6.16-rc1) :(")

- http://bugzilla.kernel.org/show_bug.cgi?id=6060: an apparent ACPI
  regression.

- Nathan's "sysfs-related oops during module unload", which Greg seems to
  have under control.

- http://bugzilla.kernel.org/show_bug.cgi?id=6049 - another acpi
  regression.  We have the actual offending commit here.

- A couple of random tty-related oopses reported by Jesper Juhl.  We
  don't know why these happened - they appear to not be related to the tty
  buffering changes.

- http://bugzilla.kernel.org/show_bug.cgi?id=6038, another box-killing
  acpi regression.

- Various reports similar to
  http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
  PCI quirk handling.

- "Ben Castricum" <lk@bencastricum.nl> reports that ppp has started
  exhibiting mysterious failures (again).

- Nasty warnings from scsi about kobject-layer things being called from
  irq context.  James has a push-it-to-process-context patch which sadly
  assumes kmalloc() is immortal, but no other fix seems to have offered
  itself.

- In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy Mahajan has
  another regression, but he's off collecting more info.

- Helge Hafting reports a usb printer regression - I don't know if that's
  still live?

- "Carlo E.  Prelz" <fluido@fluido.as> has another USB/ehci regression
  ("ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15
  rc1").

- Gerrit Bruchhuser <gbruchhaeuser@gmx.de> seems to have an aic7xxx
  regression ("AHA-7850 doesn't detect scanner anymore") but he doesn't say
  which kernel got it right.

- http://bugzilla.kernel.org/show_bug.cgi?id=5914 - a sata bug (which is
  quite unremarkable :(), but this one is reported to eat filesystems.

- Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
  regression ("alsa suspend/resume continues to fail for ens1370")

- Bjorn Nilsson <bni.swe@gmail.com> has an sk99lin regression ("3COM
  3C940, does not work anymore after upgrade to 2.6.15")

- Andrey Borzenkov <arvidjaar@mail.ru> has an acpi-cpufreq regression
  ("cannot unload acpi-cpufreq")

- "P.  Christeas" <p_christ@hol.gr> had an autofs regression ("Regression
  in Autofs, 2.6.15-git"), whic might be fixed now?

- ghrt <ghrt@dial.kappa.ro> reports an alsa regression ("PROBLEM: SB
  Live!  5.1 (emu10k1, rev.  0a) doesn't work with 2.6.15")

- jinhong hu <jinhong.hu@gmail.com> reports what appears to be a qlogic
  regression ("kernel 2.6.15 scsi problem")

- Benjamin LaHaise <bcrl@kvack.org> had an NFS problem ("NFS processes
  gettting stuck in D with currrent git").



These are clear regressions, reported in the last month by people who are
willing to test patches.  They're almost all in subsystems which have
active and professional maintainers.

Re: Linux 2.6.16-rc3

[Andrew Morton]

We still have some serious bugs, several of which are in 2.6.15 as well:

- The scsi_cmd leak, which I don't think is fixed.

- The some-x86_64-boxes-use-GFP_DMA-from-bio-layer bug, which causes
  oom-killings.

- The skbuff_head_cache leak, which has been around since at least
  2.6.11.  Another box-killer, but is seems very hard to hit. 
  (mki@mozone.net, "the dreaded oom-killer (reproducable in 2.6.11 -
  2.6.16-rc1) :(")

- http://bugzilla.kernel.org/show_bug.cgi?id=6060: an apparent ACPI
  regression.

- Nathan's "sysfs-related oops during module unload", which Greg seems to
  have under control.

- http://bugzilla.kernel.org/show_bug.cgi?id=6049 - another acpi
  regression.  We have the actual offending commit here.

- A couple of random tty-related oopses reported by Jesper Juhl.  We
  don't know why these happened - they appear to not be related to the tty
  buffering changes.

- http://bugzilla.kernel.org/show_bug.cgi?id=6038, another box-killing
  acpi regression.

- Various reports similar to
  http://bugzilla.kernel.org/show_bug.cgi?id=6011, seemingly related to USB
  PCI quirk handling.

- "Ben Castricum" <lk@bencastricum.nl> reports that ppp has started
  exhibiting mysterious failures (again).

- Nasty warnings from scsi about kobject-layer things being called from
  irq context.  James has a push-it-to-process-context patch which sadly
  assumes kmalloc() is immortal, but no other fix seems to have offered
  itself.

- In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy Mahajan has
  another regression, but he's off collecting more info.

- Helge Hafting reports a usb printer regression - I don't know if that's
  still live?

- "Carlo E.  Prelz" <fluido@fluido.as> has another USB/ehci regression
  ("ATI RS480-based motherboard: stuck while booting with kernel >= 2.6.15
  rc1").

- Gerrit Bruchhuser <gbruchhaeuser@gmx.de> seems to have an aic7xxx
  regression ("AHA-7850 doesn't detect scanner anymore") but he doesn't say
  which kernel got it right.

- http://bugzilla.kernel.org/show_bug.cgi?id=5914 - a sata bug (which is
  quite unremarkable :(), but this one is reported to eat filesystems.

- Patrizio Bassi <patrizio.bassi@gmail.com> has an alsa suspend
  regression ("alsa suspend/resume continues to fail for ens1370")

- Bjorn Nilsson <bni.swe@gmail.com> has an sk99lin regression ("3COM
  3C940, does not work anymore after upgrade to 2.6.15")

- Andrey Borzenkov <arvidjaar@mail.ru> has an acpi-cpufreq regression
  ("cannot unload acpi-cpufreq")

- "P.  Christeas" <p_christ@hol.gr> had an autofs regression ("Regression
  in Autofs, 2.6.15-git"), whic might be fixed now?

- ghrt <ghrt@dial.kappa.ro> reports an alsa regression ("PROBLEM: SB
  Live!  5.1 (emu10k1, rev.  0a) doesn't work with 2.6.15")

- jinhong hu <jinhong.hu@gmail.com> reports what appears to be a qlogic
  regression ("kernel 2.6.15 scsi problem")

- Benjamin LaHaise <bcrl@kvack.org> had an NFS problem ("NFS processes
  gettting stuck in D with currrent git").



These are clear regressions, reported in the last month by people who are
willing to test patches.  They're almost all in subsystems which have
active and professional maintainers.

Linux 2.6.16-rc3

[Linus Torvalds]

Ok,
 it is out there (or in the process of getting mirrored out), so go wild. 

And remember - if you get the tar-balls, you can get the patch file as a 
bonus FOR THE SAME PRICE! Have we got an unbeatable deal for you or what?

Of course, if you get the git repo, you'll get both anyway. And a nifty 
full log, since I'm just appending the short version here as a teaser.

Most of it is your run-of-the-mill fixes, with some driver updates making 
it all a bit larger (DVB in particular, but there's a few odd ones 
elsewhere too). 

The most user-visible one (eventually) is the unshare() system call, which 
glibc wanted. Along with some fixes for fstatat() (use the proper 64-bit 
interfaces, not the "newer old" one).

MIPS updates to round it up, although other architectures got their 
regularly scheduled updates too (powerpc, arm, ia64, s390..)

The shortlog gives more details.

		Linus

----

Adrian Bunk:
      VIDEO_CX88_ALSA must select SND_PCM
      V4L/DVB (3428): drivers/media/dvb/ possible cleanups
      kernel/kprobes.c: fix a warning #ifndef ARCH_SUPPORTS_KRETPROBES
      don't allow users to set CONFIG_BROKEN=y
      drivers/serial/jsm/: cleanups
      drivers/ide/ide-io.c: make __ide_end_request() static
      IDE: always enable CONFIG_PDC202XX_FORCE
      OCFS2: __init / __exit problem
      fs/ocfs2/dlm/dlmrecovery.c must #include <linux/delay.h>
      Let CDROM_PKTCDVD_WCACHE depend on EXPERIMENTAL
      i386: HIGHMEM64G must depend on X86_CMPXCHG64
      drivers/base/: proper prototypes
      V4L/DVB (3318e): DVB: remove the at76c651/tda80xx frontends
      drivers/video/Kconfig: remove unused BUS_I2C option

Akinobu Mita:
      fix generic_fls64()

Al Viro:
      cris: asm-offsets related build failure
      remove bogus asm/bug.h includes.
      bogus asm/delay.h includes
      drive_info removal outside of arch/i386
      missing includes in drivers/net/mv643xx_eth.c
      fix breakage in ocp.c
      restore power-off on sparc32
      ppc: last_task_.... is defined only on non-SMP
      drivers/scsi/mac53c94.c __iomem annotations
      fallout from ptrace consolidation patch: cris/arch-v10
      missing include in ser_a2232
      fix __user annotations in fs/select.c
      ipv4 NULL noise removal
      timer.c NULL noise removal
      kernel/sys.c NULL noise removal
      dvb NULL noise removal
      drivers/char/watchdog/sbc_epx_c3.c __user annotations
      fix __user annotations in drivers/base/memory.c
      drivers/edac/i82875p_edac.c __user annotations
      cmm NULL noise removal, __user annotations
      scsi_transport_iscsi gfp_t annotations
      sg gfp_t annotations
      eeh_driver NULL noise removal
      bogus extern in low_i2c.c
      amd64 time.c __iomem annotations
      __user annotations of video_spu_palette
      net/ipv6/mcast.c NULL noise removal
      arch/x86_64/pci/mmconfig.c NULL noise removal
      nfsroot port= parameter fix [backport of 2.4 fix]
      umount_tree() decrements mount count on wrong dentry
      arm: fix dependencies for MTD_XIP
      mips: namespace pollution - mem_... -> __mem_... in io.h
      s390x compat __user annotations
      powermac pci iomem annotations
      drivers/media/video __user annotations and fixes
      powerpc signal __user annotations
      sn3 iomem annotations and fixes
      compat_ioctl __user annotations
      s390 misc __user annotations
      fix iomem annotations in dart_iommu
      __user annotations in powerpc thread_info
      synclink_gt is PCI-only
      s390 __get_user() bogus warnings removal
      type-safe min() in prism54
      mark HISAX_AMD7930 as broken
      m32r_sio iomem annotations
      sh: lvalues abuse in arch/sh/boards/renesas/rts7751r2d/io.c

Alan Cox:
      SBC EPX does not check/claim I/O ports it uses (2nd Edition)
      rio cleanups
      Fix some ucLinux breakage from the tty updates
      ide: set latency when resetting it821x out of firmware mode

Alexey Dobriyan:
      dscc4: fix dscc4_init_dummy_skb check
      include/asm-*/bitops.h: fix more "~0UL >> size" typos
      ixj: fix writing silence check
      ipmi: mem_{in,out}[bwl] => intf_mem_{in,out}[bwl]
      dscc4: fix dscc4_init_dummy_skb check

Alexey Kuznetsov:
      [NETLINK]: Fix a severe bug
      [NETLINK]: illegal use of pid in rtnetlink

Ananth N Mavinakayanahalli:
      Kprobes: Fix deadlock in function-return probes

Andi Kleen:
      x86_64: Update defconfig
      x86_64: Disallow kprobes on NMI handlers
      x86_64: Define pmtmr_ioport to 0 when PM_TIMER is not available
      x86_64: Allow to run main time keeping from the local APIC interrupt
      x86_64: Automatically enable apicmaintimer on ATI boards
      x86_64: Fix swiotlb dma_alloc_coherent fallback
      x86_64: Undo the earlier changes to remove unrolled copy/memset functions
      x86_64: Remove CONFIG_INIT_DEBUG
      x86_64: Remove rogue default y in EDAC Kconfig
      x86_64: Clear more state when ignoring empty node in SRAT parsing
      x86_64: Do more checking in the SRAT header code
      x86_64: Fix zero mcfg entry workaround on x86-64
      x86_64: Don't allow kprobes on __switch_to
      x86_64: Calibrate APIC timer using PM timer
      i386/x86-64: Don't ack the APIC for bad interrupts when the APIC is not enabled
      x86_64: Let impossible CPUs point to reference per cpu data
      Fix bad apic fix on i386
      x86-64: Add sys_unshare
      x86_64: GART DMA merging fix

Andreas Gruenbacher:
      Fix two ext[23] uninitialized warnings
      Fix building external modules on ppc32

Andreas Mohr:
      ide Kconfig fixes

Andreas Schwab:
      ufs: fix char vs. __s8 clash in ufs

Andrew Morton:
      sx.c warning fixes
      parport_serial: printk warning fix
      quota_v2: printk warning fixes
      sx.c printk warning fixes
      uninline __sigqueue_free()
      ip2main.c warning fixes
      reiserfs_get_acl() build fix
      jbd: fix transaction batching
      uli526x warning fix
      module: strlen_user() race fix
      x86: don't initialise cpu_possible_map to all ones
      select: fix returned timeval
      tipar fixes
      fbdev: video_setup() warning fix

Andrey Panin:
      [SERIAL] SIIG 8-port serial boards support

Andy Gospodarek:
      r8169: fix forced-mode link settings

Antonino A. Daplas:
      nvidiafb: Add support for Geforce4 MX 4000

Arjan van de Ven:
      ocfs2: Semaphore to mutex conversion.

Arnaud Giersch:
      parport: add parallel port support for SGI O2
      parport: fix documentation
      parport: remove dead address in MAINTAINERS

Ashok Raj:
      x86_64: data/functions wrongly marked as __init with cpu hotplug.
      x86_64: Dont record local apic ids when they are disabled in MADT

Atsushi Nemoto:
      [SERIAL] initialize spinlock for port failed to setup console
      [MIPS] Sparse: Fix some compiler/sparse warnings in ptrace32.c
      [MIPS] Build blast_cache routines from template
      [MIPS] Sparse: Add _MIPS_SZINT and _MIPS_ISA to CHECKFLAGS to fix sparse warnings.
      [MIPS] Remove wrong __user tags.
      [MIPS] ieee754[sd]p_neg workaround
      [MIPS] Sparse: Add some __user tags to signal functions.
      [MIPS] Fix minor sparse warnings
      [MIPS] Fix dump_tlb.c warning and cleanup.
      [MIPS] TX49 MFC0 bug workaround
      [MIPS] Sparse: Add __user tags to syscall.c
      [MIPS] Add 'const' to readb and friends

Becky Bruce:
      documentation/powerpc: add bus-frequency property to SOC node
      powerpc: Add FSL USB node to documentation

Ben Dooks:
      [ARM] 3303/1: S3C24XX - add clock enable usage counting
      [ARM] 3306/1: S3C24XX - update defconfig
      [ARM] 3299/1: S3C24XX - fix irq range on adc device
      [ARM] 3326/1: H1940 - Control latches

Benjamin Herrenschmidt:
      Fix uevent buffer overflow in input layer
      powerpc: Fix sound driver use of i2c
      powerpc: Thermal control for dual core G5s

Bjorn Helgaas:
      [IA64] avoid broken SAL_CACHE_FLUSH implementations
      ia64: drop arch-specific IDE MAX_HWIFS definition

Carsten Otte:
      ext2: print xip mount option in ext2_show_options

Catalin Marinas:
      [ARM] 3290/1: Fix the FIFO size detection
      [ARM] 3313/1: Use OSC4 instead of OSC1 for CLCD

Chen, Kenneth W:
      [IA64] remove staled comments in asm/system.h
      x86_64: Fix memory policy build without CONFIG_HUGETLBFS
      [IA64] add syscall entry for *at()

Chris McDermott:
      x86-64: Fix HPET timer on x460

Chris Pascoe:
      V4L/DVB (3308): Use parallel transport for FusionHDTV Dual Digital USB

Christoph Lameter:
      hugetlb: add comment explaining reasons for Bus Errors
      hugetlbpage: return VM_FAULT_OOM on oom
      Updates for page migration
      zone reclaim: do not check references to a page during zone reclaim
      vmscan: remove duplicate increment of reclaim_in_progress
      vmscan: skip reclaim_mapped determination if we do not swap

Chuck Ebbert:
      sched: only print migration_cost once per boot
      i386 cpu hotplug: don't access freed memory
      i386: print kernel version in register dumps
      kobject: don't oops on null kobject.name

Cornelia Huck:
      s390: fix to_channelpath macro
      s390: fix locking in __chp_add() and s390_subchannel_remove_chpid()

Daniel Jacobowitz:
      [MIPS] Support /proc/kcore for MIPS

Dave C Boutcher:
      powerpc: return correct rtas status from ibm,suspend-me
      powerpc: prod all processors after ibm,suspend-me
      powerpc: remove useless call to touch_softlockup_watchdog

Dave Jones:
      Fix build failure in recent pm_prepare_* changes.
      EDAC config cleanup
      missing license tag in intermodule
      V4L/DVB (3318c): fix saa7146 kobject register failure
      More informative message on umount failure
      Fix s390 build failure.

Davi Arnaut:
      Fix keyctl usage of strnlen_user()

David Binderman:
      [IRDA]: out of range array access 

David Brownell:
      SPI: spi_butterfly, restore lost deltas

David Chinner:
      [XFS] Account for the page we just wrote when we detect congestion during

David Gibson:
      powerpc: Cleanup, consolidating icache dirtying logic
      Hugepages need clear_user_highpage() not clear_highpage()

David S. Miller:
      [TG3]: Update driver version and release date.
      [SPARC64]: Add .gitignore file for sparc64 boot images.
      [SPARC64]: Update defconfig.
      [SPARC]: Wire up sys_unshare().
      [SPARC64]: Update defconfig.

dean gaudet:
      fcntl F_SETFL and read-only IS_APPEND files

Domen Puncer:
      drivers/isdn/sc/ioctl.c: copy_from_user() size fix

Eric Dumazet:
      percpu data: only iterate over possible CPUs

Eric Paris:
      s390: remove one set of brackets in __constant_test_bit()

Eric Sesterhenn:
      i2c: Use module_param in i2c-algo-sibyte

Eric Sesterhenn / snakebyte:
      BUG_ON() Conversion in fs/ocfs2/
      BUG_ON() Conversion in fs/configfs/

Eric W. Biederman:
      edac_mc: Remove include of version.h

Evgeniy Dushistov:
      ufs: fix oops with `ufs1' type
      ufs: fix hang during `rm'

Felix Oxley:
      fs/jffs/intrep.c: 255 is unsigned char

Fernando Luis Vazquez Cao:
      Compilation of kexec/kdump broken

Francois Romieu:
      r8169: prevent excessive busy-waiting
      8139too: fix a TX timeout watchdog thread against NAPI softirq race

Geoff Levand:
      powerpc: Fix spufs initialization sequence.

George Anzinger:
      Normalize timespec for negative values in ns_to_timespec

Grant Grundler:
      [PARISC] Remove unnecessary extern declarations from asm/pci.h

Greg Kroah-Hartman:
      USB: Fix GPL markings on usb core functions.
      kobject_add() must have a valid name in order to succeed.
      DRM: fix up classdev interface for drm core
      IB: fix up major/minor sysfs interface for IB core

Greg Ungerer:
      m68knommu: compile fixes for mcfserial.c
      m68knommu: need pm_power_off in m68knommu
      m68knommu: hardirq.h needs definition of NR_IRQS
      m68knommu: use tty_schedule_flip() in 68360serial.c
      m68knommu: use tty_schedule_flip() in 68328serial.c

Hans Verkuil:
      V4L/DVB (3403): Add probe check for the tda9840.
      V4L/DVB (3300): Add standard for South Korean NTSC-M using A2 audio.

Haren Myneni:
      kexec: fix in free initrd when overlapped with crashkernel region

Heiko Carstens:
      s390: compile fix: missing defines in asm-s390/io.h
      s390: fix compat syscall wrapper
      [SPARC64]: Fix sys_newfstatat syscall table entry for 64-bit.
      remove bogus comment from init/main.c
      s390: update default configuration
      s390: earlier initialization of cpu_possible_map
      s390: update maintainers file
      s390: fix non smp build of kexec
      s390: add support for unshare system call
      s390: add #ifdef __KERNEL__ to asm-s390/setup.h
      s390: fstatat64 support

Helge Deller:
      [PARISC] Use kzalloc and other janitor-style cleanups
      [PARISC] Drop unused do_check_pgt_cache()
      [PARISC] Clean up compiler warning in pci.c
      [PARISC] Add CONFIG_DEBUG_RODATA to protect read-only data
      [PARISC] Use DEBUG_KERNEL to catch used-after-free __init data

Herbert Poetzl:
      quota: remove unused sync_dquots_dev()
      quota: fix error code for ext2_new_inode()

Herbert Xu:
      [IPV6]: Don't hold extra ref count in ipv6_ifa_notify
      [IPV4] multipath_wrandom: Fix softirq-unsafe spin lock usage
      [IPV6]: Fix illegal dst locking in softirq context.
      [ICMP]: Fix extra dst release when ip_options_echo fails
      [PPP]: Fixed hardware RX checksum handling

Hidetoshi Seto:
      [IA64] mca_drv: Add minstate validation

Holger Eitzenberger:
      [NETFILTER]: ULOG/nfnetlink_log: Use better default value for 'nlbufsiz'

Horms:
      [IPV4]: Document icmp_errors_use_inbound_ifaddr sysctl
      [IPV4]: Remove suprious use of goto out: in icmp_reply

Hugh Dickins:
      x86: fix stack trace facility level

Ian Campbell:
      [WATCHDOG] sa1100_wdt.c sparse clean (2)

Ian Pickworth:
      V4L/DVB (3416): Recognise Hauppauge card #34519

Ingo Molnar:
      sem2mutex: drivers/macintosh/windfarm_core.c
      solve false-positive soft lockup messages during IDE init
      Fix spinlock debugging delays to not time out too early
      SLOB=y && SMP=y fix
      x86: print out early faults via early_printk()

Ivan Kokshaysky:
      alpha: set cpu_possible_map much earlier

J. Bruce Fields:
      [OCFS2] Documentation Fix
      knfsd: fix nfs4_open lock leak

Jack Steiner:
      [IA64-SGI] Update TLB flushing code for SN platform

Jake Moilanen:
      powerpc: IOMMU SG paranoia

James Bottomley:
      [PARISC] Fix floating point invalid exception trap handler

Jan Beulich:
      x86_64: small fix for CFI annotations
      x86_64: minor odering correction to dump_pagetable()
      prevent recursive panic from softlockup watchdog

Jan Glauber:
      s390: timer interface visibility

JANAK DESAI:
      unshare system call -v5: Documentation file
      unshare system call -v5: system call handler function
      unshare system call -v5: unshare filesystem info
      unshare system call -v5: unshare namespace
      unshare system call -v5: unshare vm
      unshare system call -v5: unshare files
      unshare system call -v5: system call registration for i386
      powerpc: unshare system call registration

Janak Desai:
      [IA64] unshare system call registration for ia64

Jason Gaston:
      piix: add Intel ICH8M device IDs
      i2c-i801: I2C patch for Intel ICH8

Jay Vosburgh:
      bonding: allow bond to use TSO if slaves support it

Jayachandran C:
      UDF: Fix issues reported by Coverity in namei.c
      IPMI: fix issues reported by Coverity in ipmi_msghandler.c

Jean Delvare:
      ide-disk: Restore missing space in log message
      I2C: Resurrect i2c_smbus_write_i2c_block_data.
      hwmon: Fix negative temperature readings in lm77 driver
      hwmon: Inline w83792d register access functions
      hwmon: Add f71805f documentation
      hwmon: New f71805f driver
      hwmon: Fix reboot on it87 driver load

Jeff Dike:
      uml: add debug switch for skas mode
      uml: close TUN/TAP file descriptors
      uml: balance list_add and list_del in the network driver
      uml: block SIGWINCH in ptrace tester child
      uml: initialize process FP registers properly
      uml: remove a dead file

Jeff Garzik:
      [libata sata_sil] implement 'slow_down' module parameter
      [libata sata_mv] do not enable PCI MSI by default

Jeff Mahoney:
      ocfs2/dlm: fix compilation on ia64
      reiserfs: disable automatic enabling of reiserfs inode attributes

Jeff Moyer:
      fix O_DIRECT read of last block in a sparse file

Jens Axboe:
      fix ordering on requeued request drainage
      cciss: softirq handler needs to save interrupt flags
      blk: Fix SG_IO ioctl failure retry looping

Jes Sorensen:
      drivers/sn/ must be entered for CONFIG_SGI_IOC3
      [IA64-SGI] sn2 housekeeping
      [IA64-SGI] include/asm-ia64/sn/intr.h more sn2 housekeeping
      [IA64] prevent sn2 specific code to be run in generic kernels

Jesper Juhl:
      Don't check pointer for NULL before passing it to kfree [arch/powerpc/kernel/rtas_flash.c]
      wrong firmware location in IPW2100 Kconfig entry
      netfilter: fix build error due to missing has_bridge_parent macro

Jesse Allen:
      orinoco: support smc2532w

Jesse Brandeburg:
      e100: remove init_hw call to fix panic

Jiri Slaby:
      V4L/DVB (3439a): media video stradis memory fix

Joel Becker:
      o Remove confusing Kconfig text for CONFIGFS_FS.
      configfs: Clean up MAINTAINERS entry
      configfs: Add permission and ownership to configfs objects.

John Blackwood:
      arch/x86_64/kernel/traps.c PTRACE_SINGLESTEP oops

John Heffner:
      [TCP]: rcvbuf lock when tcp_moderate_rcvbuf enabled

Jon Mason:
      x86_64: IOMMU printk cleanup

Jordan Crouse:
      [SERIAL] Fix compile error in 8250_au1x00.c
      [MMC] Remove extra character in AU1XXX MMC Kconfig entry

KAMBAROV, ZAUR:
      coverity: udf/balloc.c null deref fix

KAMEZAWA Hiroyuki:
      shmdt cannot detach not-alined shm segment cleanly.

Karsten Keil:
      i4l: warning fixes

Keith Owens:
      [IA64-SGI] Recursive flags do not work for selective builds
      Tell kallsyms_lookup_name() to ignore type U entries

Kevin VanMaren:
      x86_64: When allocation of merged SG lists fails in the IOMMU don't merge

Kirill Korotaev:
      [NETFILTER]: Fix possible overflow in netfilters do_replace()

Kristian Slavov:
      [IPV6]: Address autoconfiguration does not work after device down/up cycle

Kumar Gala:
      gianfar: Fix sparse warnings
      [SERIAL] 8250 serial console update uart_8250_port ier
      powerpc: Add CONFIG_DEFAULT_UIMAGE for embedded boards

Kurt Hackel:
      ocfs2/dlm: fixes

Kyle McMartin:
      [PARISC] Use F_EXTEND() for COMMAND_GLOBAL
      [PARISC] atomic64 support
      [PARISC] Move pm_power_off export to process.c
      [PARISC] Remove obsolete _hlt cruft
      [PARISC] Add chassis_power_off routine
      [PARISC] Clean up printk in superio.c
      [PARISC] Arch-specific compat signals
      [PARISC] Simplify DISCONTIGMEM in Kconfig
      [PARISC] New syscalls (inotify, *at, pselect6/ppoll, migrate_pages)
      [IA64] Remove stale comment from ia64/Kconfig
      sys_hpux: fix strlen_user() race

Latchesar Ionkov:
      v9fs: symlink support fixes
      v9fs: v9fs_put_str fix
      v9fs: fix corner cases when flushing request

Lennert Buytenhek:
      sis900: remove cfgpmcsr I/O space register define
      [ARM] 3300/1: make ixdp2x01 co-exist with other ixp2000 machine types
      [ARM] 3301/1: remove unnecessary clock default from ixdp2801 defconfig
      [ARM] 3302/1: make pci=firmware the default for ixp2000

Linas Vepstas:
      Clean up Documentation/driver-model/overview.txt
      Documentation: Updated PCI Error Recovery

Linus Torvalds:
      Revert "x86_64: Fix the node cpumask of a cpu going down"
      mm/slab.c (non-NUMA): Fix compile warning and clean up code
      ppc: fix up trivial Kconfig config selection
      Revert "kconfig: detect if -lintl is needed when linking conf,mconf"
      Linux v2.6.16-rc3

Loren M. Lang:
      RocketPoint 1520 [hpt366] fails clock stabilization

Lucas Correia Villa Real:
      [ARM] 3284/1: S3C2400 - adds support to GPIO
      [ARM] 3286/2: S3C2400 - adds to the table of supported CPUs
      [ARM] 3283/1: S3C2400 - defines the number of serial ports
      [ARM] 3314/1: S3C2400 - adds s3c2400.h

Luiz Fernando Capitulino:
      bonding: Sparse warnings fix

Manu Abraham:
      V4L/DVB (3294): Fix [Bug 5895] to correct snd_87x autodetect

Marcelo Tosatti:
      make "struct d_cookie" depend on CONFIG_PROFILING
      powerpc/8xx: last two 8MB D-TLB entries are incorrectly set

Marcin Rudowski:
      V4L/DVB (3266): Fix NICAM buzz on analog sound

Marco Manenti:
      V4L/DVB (3297): Add IR support to KWorld DVB-T (cx22702-based)

Marcus Sundberg:
      [NETFILTER]: ctnetlink: Fix subsystem used for expectation events

Mark Fasheh:
      [OCFS2] Make ip_io_sem a mutex
      ocfs2: fix compile warnings
      ocfs2: don't wait on recovery when locking journal

Mark Mason:
      [MIPS] BCM1125 PCI fixes
      [MIPS] BCM1480: Cleanup debug code left behind in the PCI driver.
      [MIPS] SB1: Add oprofile support.

Mark Maule:
      [IA64-SGI] fix smp_affinity redirection when using CONFIG_PCI_MSI
      [IA64-SGI] disable msi for all altix pci devices

Markus Lidel:
      I2O: don't disable PCI device if it is enabled before probing
      I2O: fix and workaround for Motorola/Freescale controller
      Fix i2o_scsi oops on abort

Markus Rechberger:
      V4L/DVB (3429): Missing break statement on tuner-core
      V4L/DVB (3434): changed comment in tuner-core.c
      V4L/DVB (3281): Added signal detection support to tvp5150
      V4L/DVB (3306): Fixed i2c return value, conversion mdelay to msleep
      V4L/DVB (3325): Disabled debug on by default in tvp5150

Martin Michlmayr:
      Fix compilation errors in maps/dc21285.c
      [ARM] 3304/1: Add help descriptions to ARCH config items that don't have one
      [ARM] 3305/1: Minor typographical and spelling fixes in Konfig

Matt Waddel:
      Add wording to m68k .S files to help clarify license info

Matthew Wilcox:
      [PARISC] Make flush_tlb_all_local take a void *
      [PARISC] Update b180_defconfig
      [PARISC] Remove {,un}lock_kernel from perf ioctl

Mauro Carvalho Chehab:
      V4L/DVB (3406): Added credits for em28xx-video.c
      V4L/DVB (3405): Fixes tvp5150a/am1 detection.
      V4L/DVB (3453a): Alters MAINTAINERS file to point to newer v4l-dvb email
      V4L/DVB (3318a): Makes Some symbols static.

Michael Chan:
      [TG3]: Flush tg3_reset_task()

Michael Ellerman:
      powerpc: Don't allocate zero bytes in finish_device_tree()
      powerpc: Make sure we don't create empty lmb regions
      powerpc: Refuse to boot a kdump kernel via OF
      powerpc: Fix !SMP build of rtas.c
      powerpc: Don't overwrite flat device tree with kdump kernel
      powerpc: Don't use toc in decrementer_iSeries_masked

Michael Krufky:
      V4L/DVB (3392): Add PCI ID for DigitalNow DVB-T Dual, rebranded DViCO FusionHDTV DVB-T Dual.
      V4L/DVB (3413): Kill nxt2002 in favor of the nxt200x module
      V4L/DVB (3414): rename dvb_pll_tbmv30111in to dvb_pll_samsung_tbmv
      V4L/DVB (3417): make VP-3054 Secondary I2C Bus Support a Kconfig option.
      V4L/DVB (3431): fixed spelling error, exectuted --> executed.
      V4L/DVB (3442): Allow tristate build for cx88-vp3054-i2c
      V4L/DVB (3299): Kconfig: DVB_USB_CXUSB depends on DVB_LGDT330X and DVB_MT352
      V4L/DVB (3310): Use MT352 parallel transport function for all Bluebird FusionHDTV DVB-T boxes.

Michael Neuling:
      powerpc: hypervisor check in pseries_kexec_cpu_down

Michael Richardson:
      ide: cast arguments to pr_debug() properly

Michal Ostrowski:
      Fix RocketPort driver

Mike Isely:
      V4L/DVB (3418): Cause tda9887 to use I2C_DRIVERID_TDA9887

Miklos Szeredi:
      fuse: fix request_end() vs fuse_reset_request() race

Nathan Lynch:
      powerpc: avoid timer interrupt replay effect when onlining cpu

Nathan Scott:
      [XFS] Fix missing inode atime update from the utime syscall.

NeilBrown:
      md: Handle overflow of mdu_array_info_t->size better
      md: Assorted little md fixes
      md: Make sure rdev->size gets set for version-1 superblocks

Nick Piggin:
      mm: compound release fix
      sched: remove smpnice

Nicolas Pitre:
      [ARM] 3293/1: don't invalidate the whole I-cache with xscale_coherent_user_range
      [ARM] 3294/1: don't invalidate individual BTB entries on ARMv6
      [ARM] 3307/1: old ABI compat: mark it experimental
      [ARM] 3308/1: old ABI compat: struct sockaddr_un
      [ARM] 3309/1: disable the pre-ARMv5 NPTL kernel helper in the non MMU case
      [ARM] 3310/1: add a comment about the possible __kuser_cmpxchg transient false
      [ARM] 3311/1: clean up include/asm-arm/mutex.h

OGAWA Hirofumi:
      fat: Replace an own implementation with ll_rw_block(SWRITE,)
      Trivial optimization of ll_rw_block()
      fat: Fix truncate() write ordering

Olaf Hering:
      powerpc: remove pointer/integer confusion in generic_calibrate_decr
      powerpc: restore clock speed in /proc/cpuinfo
      powerpc: remove pointer/integer confusion in of_find_node_by_name
      powerpc: add refcounting to setup_peg2 and of_get_pci_address
      powerpc: fix compile warning in udbg_init_maple_realmode

Oleg Nesterov:
      sys_signal: initialize ->sa_mask
      do_sigaction: cleanup ->sa_mask manipulation

Oliver Endriss:
      V4L/DVB (3307): Support for Galaxis DVB-S rev1.3

Pablo Neira Ayuso:
      [TEXTSEARCH]: Fix broken good shift array calculation in Boyer-Moore
      [NETFILTER]: ctnetlink: add MODULE_ALIAS for expectation subsystem

Paolo 'Blaisorblade' Giarrusso:
      Kbuild menu - hide empty NETDEVICES menu when NET is disabled

Patrick Boettcher:
      V4L/DVB (3312): FIX: Multiple usage of VP7045-based devices
      V4L/DVB (3313): FIX: Check if FW was downloaded or not + new firmware file

Patrick McHardy:
      [NETFILTER]: Fix undersized skb allocation in ipt_ULOG/ebt_ulog/nfnetlink_log
      [NETFILTER]: nfnetlink_queue: fix packet marking over netlink
      [NETFILTER]: Fix missing src port initialization in tftp expectation mask
      [NETFILTER]: Check policy length in policy match strict mode
      [NETFILTER]: Fix ip6t_policy address matching
      [NETFILTER]: Prepare {ipt,ip6t}_policy match for x_tables unification
      [NETFILTER]: Fix check whether dst_entry needs to be released after NAT

Paul E. McKenney:
      Fix comment to synchronize_sched()

Paul Fulghum:
      new tty buffering locking fix
      tty buffering stall fix

Paul Mackerras:
      powerpc/64: Fix bug in setting floating-point exception mode
      ppc: Use the system call table from arch/powerpc/kernel/systbl.S

Pavel Machek:
      Fix Userspace interface breakage in power/state
      swsusp: kill unneeded/unbalanced bio_get

Peter Horton:
      [MIPS] Fix Cobalt PCI cache line sizes

Peter Missel:
      V4L/DVB (3409): Mark Typhoon cards as Lifeview OEM's

Peter Oberparleiter:
      s390: fix sclp memory corruption in tty pages list

Peter Osterlund:
      pktcdvd: remove version string
      pktcdvd: Don't waste kernel memory

Peter Williams:
      lib: Fix bug in int_sqrt() for 64 bit longs

Phillip Susi:
      pktcdvd: Fix overflow for discs with large packets
      pktcdvd: Allow larger packets

Prarit Bhargava:
      [IA64-SGI] Hotplug driver related fix in the SN ia64 code.
      [IA64-SGI] Small cleanup for misuse of list_for_each to list_for_each_safe.

Rafael J. Wysocki:
      Fix build failure in recent pm_prepare_* changes.

Ralf Baechle:
      [MIPS] Remove stray .set mips3 resulting in 64-bit instruction in 32-bit kernels.
      [MIPS] Fix C version of ssnop to use the right opcode.
      [MIPS] Get rid of unnecessary prototypes.  Fixes and optimizations for HZ > 100.
      [MIPS] RTLX compile fixes.
      [MIPS] Revert "mips: add pm_power_off"
      [MIPS] Check function pointers are non-zero before calling.
      [MIPS] Rename _machine_power_off to pm_power_off so the kernel builds again.
      [MIPS] Rename include/asm-mips/cobalt to include/asm-mips/mach-cobalt.
      [MIPS] CPU definitions for Cobalt.
      [MIPS] Nevada support for SGI O2.
      [MIPS] Bullet proof uaccess.h against 4.0.1 miss-compilation.
      [MIPS] Get rid of CONFIG_SB1_PASS_1_WORKAROUNDS #ifdef crapola.
      [MIPS] Sibyte: Make all setup functions __init.
      [MIPS] Reformat to 80 columns.
      [MIPS] Remove commented out code to add -mmad for Nevada.
      [MIPS] local_irq_restore wasn't safe to be used in other macros mode.
      [MIPS] Cleanup fls implementation.
      [MIPS] IP22: Fix serial console detection
      [MIPS] Shrink Qemu configuration to the bare minimum that is need and tested.
      [MIPS] Remove buggy inline version of memscan.
      [MIPS] MIPS R2 optimized endianess swapping.
      [MIPS] Oprofile: Support for 34K UP kernels.
      [MIPS] Fix linker script to work for non-4K page size.
      [MIPS] Clear ST0_RE on bootup.
      [MIPS] Add support for TIF_RESTORE_SIGMASK.
      [MIPS] Make do_signal return void.
      [MIPS] Wire up new syscalls.
      [SERIAL] ip22zilog: Whitespace cleanup.

Randy Dunlap:
      V4L/DVB (3433): Fix printk type warning
      parport: fix printk format warning
      cpuset: fix sparse warning
      edac: use C99 initializers (sparse warnings)

Ravikiran G Thirumalai:
      x86_64: Fix the node cpumask of a cpu going down
      NUMA slab locking fixes: move color_next to l3
      NUMA slab locking fixes: irq disabling from cahep->spinlock to l3 lock
      NUMA slab locking fixes: fix cpu down and up locking
      x86_64: Fix the node cpumask of a cpu going down
      slab: Avoid deadlock at kmem_cache_create/kmem_cache_destroy

Richard Purdie:
      [ARM] 3291/1: PXA27x: Correct get_clk_frequency_khz turbo flag handling
      [ARM] 3292/1: Fix memory corruption in asm-arm/checksum.h: ip_fast_csum()
      stop CompactFlash devices being marked as removable

Robb, Sam:
      kconfig: detect if -lintl is needed when linking conf,mconf

Robert Love:
      inotify: fix one-shot support

Robin Holt:
      [IA64-SGI] Fix XPC code which sleeps with spin_lock_irqsave().

Rudolf Marek:
      i2c: Rename i2c-sis96x documentation file

Russ Anderson:
      [IA64-SGI] Shub2 BTE address fix

Russ Dill:
      [ARM] 3295/1: Fix oprofile init return value

Russell King:
      [MMC] Add MMC command type flags
      [SERIAL] 8250: limit range of runtime ports
      [ARM] Remove ARCH_CAMELOT from at91 defconfigs
      [SERIAL] uart_port iotype member should use UPIO_*
      [SERIAL] uart_port flags member should use UPF_*
      [SERIAL] Remove unnecessary serial.h include
      Fix compiler warning in driver core for CONFIG_HOTPLUG=N
      drivers/base/bus.c warning fixes
      [ARM] Experimental config options should have (EXPERIMENTAL)
      [SERIAL] Remove incorrect code from ioc4 serial driver

Sam Ravnborg:
      kconfig: fix /dev/null breakage
      kbuild: fix build with O=..

Samir Bellabes:
      [NETFILTER]: nf_conntrack: fix incorrect memset() size in FTP helper

Samuel Ortiz:
      [IRDA]: Set proper IrLAP device address length

schwab@suse.de:
      disable per cpu intr in /proc/stat

Sergei Shtylylov:
      [MIPS] TX49x7: Fix timer register #define's
      [MIPS] Au1xx0: really set KSEG0 to uncached on reboot
      [MIPS] Au1200: Make KGDB compile
      [MIPS] TX49x7: Fix reporting of the CPU name and PCI clock

Shaohua Li:
      x86_64: timer resume
      x86_64: mark two routines as __cpuinit

Stefan Weinhuber:
      s390: dasd extended error reporting module

Steffen Klassert:
      3c59x: collision statistic fix

Stephen Hemminger:
      [NET] snap: needs hardware checksum fix
      [NET]: Add CONFIG_NETDEBUG to suppress bad packet messages.
      sky2: power management fix
      sky2: pci config space checking
      sky2: ethtool rx_coalesce settings fix
      sky2: set mac address fix
      sky2: clear irq race
      sky2: add irq to entropy pool
      sky2: support msi interrupt (revised)
      sky2: version 0.15 update
      [BRIDGE]: fix for RCU and deadlock on device removal
      [BRIDGE]: netfilter handle RCU during removal
      [BRIDGE]: fix error handling for add interface to bridge

Stephen Smalley:
      SELinux: fix size-128 slab leak
      MAINTAINERS/CREDITS: Update SELinux contact info
      selinux: require SECURITY_NETWORK
      selinux: require AUDIT

Steve Langasek:
      __cmpxchg() must really always be inlined on alpha

Suzuki:
      Fix do_path_lookup() to add the check for error in link_path_walk()

Takashi Iwai:
      Fix "value computed is not used" compile warnings with gcc-4.1

Tejun Heo:
      block: request_queue->ordcolor must not be flipped on SOFTBARRIER
      block: implement elv_insert and use it (fix ordcolor flipping bug)

Thibaut VARENE:
      [PARISC] pdc_stable version 0.22
      ide: restore support for AEC6280M cards in aec62xx.c

Tobias Klauser:
      umem: check pci_set_dma_mask return value correctly
      i2c: Use ARRAY_SIZE macro

Tong Li:
      OProfile: fixed x86_64 incorrect kernel call graphs

Tony Lindgren:
      [ARM] 3279/1: OMAP: 1/3 Fix low-level io init
      [ARM] 3280/1: OMAP: 2/3 Fix low-level io init for omap1 boards
      [ARM] 3278/1: OMAP: 3/3 Fix low-level io init for omap2 boards

Tony Luck:
      [IA64] Fix CONFIG_PRINTK_TIME
      [IA64] sys32_signal() forgets to initialize ->sa_mask

Trond Myklebust:
      VFS: Ensure LOOKUP_CONTINUE flag is preserved by link_path_walk()

Ulrich Drepper:
      namei.c: unlock missing in error case
      fstatat64 support

V. Ananda Krishnan:
      jsm: update for tty buffering revamp

Venkatesh Pallipadi:
      x86_64: Only switch to IPI broadcast timer on Intel when C3 is supported

Vincent Hanquez:
      debugfs: hard link count wrong
      debugfs: trivial comment fix

Vitaly Bordug:
      [SERIAL] PPC32 CPM_UART: update to utilize the new TTY flip API

Vitaly Fertman:
      someone broke reiserfs V3 mount options, this fixes it

Vlad Yasevich:
      [SCTP]: Fix 'fast retransmit' to send a TSN only once.

Wim Van Sebroeck:
      [WATCHDOG] pcwd.c add comments + tabs
      [WATCHDOG] pcwd.c card_found-- fix.
      [WATCHDOG] pcwd.c private data struct patch
      [WATCHDOG] pcwd.c Control Status #2 patch
      [WATCHDOG] pcwd.c move get_support to pcwd_check_temperature_support
      [WATCHDOG] pcwd.c show card info patch
      [WATCHDOG] pcwd.c - update module version info

Yasuyuki Kozakai:
      [NETFILTER]: nf_conntrack: check address family when finding protocol module
      [NETFILTER]: iptables: fix typos in ipt_connbytes.h

Yoichi Yuasa:
      [SERIAL] 8250_pci: add new PCI serial card support

Zach Brown:
      list.h: don't evaluate macro args multiple times
      x86_64: align per-cpu section to configured cache bytes

Zhang, Yanmin:
      Export cpu topology in sysfs

Zou Nan hai:
      [IA64] Fix a possible buffer overflow in efi.c
      [IA64] Fix wrong use of memparse in efi.c