twitter: linux.kernel - 25 new messages in 16 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* Added in stricter no merge semantics for block I/O - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3b72407f650a139e?hl=en
* usb: otg: add notifier support - 4 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/dad470d391a03375?hl=en
* MAINTAINERS: add i2c tree for embedded platforms - 3 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/6b9a024c8479e333?hl=en
* sysfs_ops show vector: size of buffer not required? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/8aafe8a10e8404cc?hl=en
* x86, mce: Rename cpu_specific_poll to mce_cpu_specific_poll - 2 messages, 1
author
http://groups.google.com/group/linux.kernel/t/fc4cba69013002ea?hl=en
* fix the lockdep warning in tty_fasync() - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/b92a5fcdc20fcbff?hl=en
* 2.6.31.8 (OpenSUSE): BUG: scheduling while atomic: swapper/0/0x10000002 - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/8d0ef337656f9662?hl=en
* linux-next: add utrace tree - 3 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/67ebc22686b326f0?hl=en
* ata: Disable NCQ for Crucial M225 brand SSDs - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/89c4d92bc1e1249b?hl=en
* regulator: support max8649 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/0c21f2834789c0db?hl=en
* Fix 1 untangling ima mess, part 2 with counters - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/fca0cbdc1743a322?hl=en
* move efifb's probe function to .devinit.text - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/7db9be36a46d6f4f?hl=en
* R: [Bug #14886] Asus P2B-DS not detected as SMP moterboard - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/f306c860bbde469a?hl=en
* dma: Add barrierless dma mapping/unmapping api - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3756402bfba9b5ed?hl=en
* usbhid driver: replacing resume or using a post resume function - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/7e60ff7d909ff25e?hl=en
* Status of 'toshiba-acpi: Add support for hotkey notifications' patch? - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/04841ac3760a48ee?hl=en

==============================================================================
TOPIC: Added in stricter no merge semantics for block I/O
http://groups.google.com/group/linux.kernel/t/3b72407f650a139e?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 7:20 am
From: "Alan D. Brunelle"

Added in stricter no merge semantics for block I/O

Updated 'nomerges' tunable to accept a value of '2' - indicating that _no_
merges at all are to be attempted (not even the simple one-hit cache).

The following table illustrates the additional benefit - 5 minute runs of
a random I/O load were applied to a dozen devices on a 16-way x86_64 system.

nomerges Throughput %System Improvement (tput / %sys)
-------- ------------ ----------- -------------------------
0 12.45 MB/sec 0.669365609
1 12.50 MB/sec 0.641519199 0.40% / 2.71%
2 12.52 MB/sec 0.639849750 0.56% / 2.96%

Signed-off-by: Alan D. Brunelle <alan.brunelle@hp.com>
Cc: jens.axboe@oracle.com
---
Documentation/ABI/testing/sysfs-block | 14 ++++++++++++++
Documentation/block/queue-sysfs.txt | 10 +++++-----
block/blk-sysfs.c | 11 +++++++----
block/elevator.c | 11 ++++++++++-
include/linux/blkdev.h | 3 +++
5 files changed, 39 insertions(+), 10 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block
index d2f9033..954624f 100644
--- a/Documentation/ABI/testing/sysfs-block
+++ b/Documentation/ABI/testing/sysfs-block
@@ -128,3 +128,17 @@ Description:
preferred request size for workloads where sustained
throughput is desired. If no optimal I/O size is
reported this file contains 0.
+
+What: /sys/block/<disk>/queue/nomerges
+Date: January 2010
+Contact:
+Description:
+ Standard I/O elevator operations include attempts to
+ merge contiguous I/Os. For known random I/O loads these
+ attempts will always fail and result in extra cycles
+ being spent in the kernel. This allows one to turn off
+ this behavior on one of two ways: When set to 1, complex
+ merge checks are disabled, but the simple one-shot merges
+ with the previous I/O request are enabled. When set to 2,
+ all merge tries are disabled. The default value is 0 -
+ which enables all types of merge tries.
diff --git a/Documentation/block/queue-sysfs.txt b/Documentation/block/queue-sysfs.txt
index e164403..f652740 100644
--- a/Documentation/block/queue-sysfs.txt
+++ b/Documentation/block/queue-sysfs.txt
@@ -25,11 +25,11 @@ size allowed by the hardware.

nomerges (RW)
-------------
-This enables the user to disable the lookup logic involved with IO merging
-requests in the block layer. Merging may still occur through a direct
-1-hit cache, since that comes for (almost) free. The IO scheduler will not
-waste cycles doing tree/hash lookups for merges if nomerges is 1. Defaults
-to 0, enabling all merges.
+This enables the user to disable the lookup logic involved with IO
+merging requests in the block layer. By default (0) all merges are
+enabled. When set to 1 only simple one-hit merges will be tried. When
+set to 2 no merge algorithms will be tried (including one-hit or more
+complex tree/hash lookups).

nr_requests (RW)
----------------
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index 8606c95..e854424 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -189,7 +189,8 @@ static ssize_t queue_nonrot_store(struct request_queue *q, const char *page,

static ssize_t queue_nomerges_show(struct request_queue *q, char *page)
{
- return queue_var_show(blk_queue_nomerges(q), page);
+ return queue_var_show((blk_queue_nomerges(q) << 1) |
+ blk_queue_noxmerges(q), page);
}

static ssize_t queue_nomerges_store(struct request_queue *q, const char *page,
@@ -199,10 +200,12 @@ static ssize_t queue_nomerges_store(struct request_queue *q, const char *page,
ssize_t ret = queue_var_store(&nm, page, count);

spin_lock_irq(q->queue_lock);
- if (nm)
+ queue_flag_clear(QUEUE_FLAG_NOMERGES, q);
+ queue_flag_clear(QUEUE_FLAG_NOXMERGES, q);
+ if (nm == 2)
queue_flag_set(QUEUE_FLAG_NOMERGES, q);
- else
- queue_flag_clear(QUEUE_FLAG_NOMERGES, q);
+ else if (nm)
+ queue_flag_set(QUEUE_FLAG_NOXMERGES, q);
spin_unlock_irq(q->queue_lock);

return ret;
diff --git a/block/elevator.c b/block/elevator.c
index 9ad5ccc..ee3a883 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -474,6 +474,15 @@ int elv_merge(struct request_queue *q, struct request **req, struct bio *bio)
int ret;

/*
+ * Levels of merges:
+ * nomerges: No merges at all attempted
+ * noxmerges: Only simple one-hit cache try
+ * merges: All merge tries attempted
+ */
+ if (blk_queue_nomerges(q))
+ return ELEVATOR_NO_MERGE;
+
+ /*
* First try one-hit cache.
*/
if (q->last_merge) {
@@ -484,7 +493,7 @@ int elv_merge(struct request_queue *q, struct request **req, struct bio *bio)
}
}

- if (blk_queue_nomerges(q))
+ if (blk_queue_noxmerges(q))
return ELEVATOR_NO_MERGE;

/*
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index ffb13ad..f71f5c5 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -463,6 +463,7 @@ struct request_queue
#define QUEUE_FLAG_IO_STAT 15 /* do IO stats */
#define QUEUE_FLAG_CQ 16 /* hardware does queuing */
#define QUEUE_FLAG_DISCARD 17 /* supports DISCARD */
+#define QUEUE_FLAG_NOXMERGES 18 /* No extended merges */

#define QUEUE_FLAG_DEFAULT ((1 << QUEUE_FLAG_IO_STAT) | \
(1 << QUEUE_FLAG_CLUSTER) | \
@@ -589,6 +590,8 @@ enum {
#define blk_queue_queuing(q) test_bit(QUEUE_FLAG_CQ, &(q)->queue_flags)
#define blk_queue_stopped(q) test_bit(QUEUE_FLAG_STOPPED, &(q)->queue_flags)
#define blk_queue_nomerges(q) test_bit(QUEUE_FLAG_NOMERGES, &(q)->queue_flags)
+#define blk_queue_noxmerges(q) \
+ test_bit(QUEUE_FLAG_NOXMERGES, &(q)->queue_flags)
#define blk_queue_nonrot(q) test_bit(QUEUE_FLAG_NONROT, &(q)->queue_flags)
#define blk_queue_io_stat(q) test_bit(QUEUE_FLAG_IO_STAT, &(q)->queue_flags)
#define blk_queue_flushing(q) ((q)->ordseq)
--
1.6.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: usb: otg: add notifier support
http://groups.google.com/group/linux.kernel/t/dad470d391a03375?hl=en
==============================================================================

== 1 of 4 ==
Date: Tues, Jan 26 2010 7:30 am
From: David Brownell

On Tuesday 26 January 2010, Felipe Balbi wrote:
> >
> >Thing is, supplying current is a bit more involved. If the
> >board can't supply 300 mA, the USB configuration selection
> >mechanism has to know that, so it never selects peripheral
> >configurations which require that much current.
>
> but that's done already by the usb core, no ? It rules out configuration
> based on the hub->power_budget (can't remember if the field is that
> exact name).

Yes, it handles that ... but where does the power budget
come from? That's what I meant by "more involved".

As in, the host/supplying side of the power equation can't
be event driven like the peripheral/consuming side can.

And that's another reason I think it's best to fully solve
the common (peripheral, recharge-that-batter) case first.

- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 4 ==
Date: Tues, Jan 26 2010 7:40 am
From: David Brownell

On Tuesday 26 January 2010, Felipe Balbi wrote:
> just remember of another problem which I couldn't solve yet:
>
> if you boot the board with the usb cable already attached, then we miss
> the first notification because when the notifier is called, usb
> controller driver isn't probed yet.

That's part of why the OTG transceiver driver has methods
used by host and peripheral drivers to register themselves.

Standard init sequence there is to do nothing until both
drivers are fully initialized ... last step being to
register the drivers with the transceiver. That way the
transceiver can know when its peer drivers are ready.

Example: VBUS present from a host. If the board runs
in OTG mode, as soon as both drivers are registered then
the B-Default state machine would start running ... and
that involves (see the OTG state machine!) issuing a VBBUS
event.

Same thing can be done with the power events. As soon
as an event listener is registered, it could be fed any
events it missed. (Just one approach; one must sort
out any other interdependencies too. In this case, it
can make sense to consume 100mA current right away, and
then adjust the draw later if needed.)

== 3 of 4 ==
Date: Tues, Jan 26 2010 7:50 am
From: David Brownell

On Tuesday 26 January 2010, Mark Brown wrote:
> > > Yes please - it's not just chargers either, this can also be used by
> > > PMICs which do power path management that includes USB.
>
> > Color me confused ... what do you mean by "power path"?
>
> In the sort of design I'm talking about there is generally a system
> power rail which is generated from the various power sources available
> to the system, which might include a combination of batteries, USB and
> wall adaptors.

Just as an example: drivers/mfd/tps6510.c supports exactly
that trio of power sources. More than one system rail though,
which (as you know) is pretty common -- core != I/O.

It's *way* simpler than e.g. the TWL6030. :)

> The power path management logic is the hardware which
> controls which of these are actually being used as supplies, and may
> also include battery charger management.
>
> > Do you mean something like "the board as a whole can take N mA of
> > current from USB", rather than specifically addressing a charger?
>
> Pretty much, from this point of view.

OK -- clear now.

> > It's not uncommon to do things like use VBUS current to power the
> > USB circuitry, too. That can leave less for other purposes. All
> > of that being rather board-specific.
>
> In this sort of design either VBUS goes through the power path
> management logic before anything else gets to use it or the hardware
> will know about the headroom it needs to leave. The power path
> management will usually do things like try to suppliment VBUS with any
> battery that's available to generate the main system supply rail.
>
> This all needs to function without software since it tends to get used
> to decide things like if the system is able to begin power up at all, .

Yep. That's part of the reason the USB specs have hard
rules about having 100 mA available (for some period)
even before software can come up.

Bus powered devices can come up on that 100mA, running
enough to enumerate ... and request more power, if they
need it.

Not all Linux systems can boot with that little power!

- Dave

== 4 of 4 ==
Date: Tues, Jan 26 2010 8:20 am
From: Mark Brown

On Tue, Jan 26, 2010 at 07:44:46AM -0800, David Brownell wrote:
> On Tuesday 26 January 2010, Mark Brown wrote:

> > In the sort of design I'm talking about there is generally a system
> > power rail which is generated from the various power sources available
> > to the system, which might include a combination of batteries, USB and
> > wall adaptors.

> Just as an example: drivers/mfd/tps6510.c supports exactly
> that trio of power sources.

Yup, it's a fairly standard feature set for all in one PMICs, WM835x and
WM831x are also examples of this.

> More than one system rail though,
> which (as you know) is pretty common -- core != I/O.

Yes, in this context the system rail is the supply input to the
regulators rather than the regulated voltages that are (mostly)
used directly by the chips.

> Bus powered devices can come up on that 100mA, running
> enough to enumerate ... and request more power, if they
> need it.

> Not all Linux systems can boot with that little power!

Some can even brown themselves out going full pelt with the full 500mA
supply if there's no battery to supplement it :/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: MAINTAINERS: add i2c tree for embedded platforms
http://groups.google.com/group/linux.kernel/t/6b9a024c8479e333?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 26 2010 7:30 am
From: Jean Delvare

On Tue, 26 Jan 2010 14:38:30 +0000, Ben Dooks wrote:
> On Mon, Jan 25, 2010 at 11:10:55AM +0100, Jean Delvare wrote:
> > On Mon, 25 Jan 2010 10:20:34 +0100, Uwe Kleine-K??nig wrote:
> > > Signed-off-by: Uwe Kleine-K??nig <u.kleine-koenig@pengutronix.de>
> > > Cc: Ben Dooks <ben-linux@fluff.org>
> > > ---
> > > Hello,
> > >
> > > I wonder if it makes sence to split the "I2C SUBSYSTEM" entry into
> > > something like:
> > >
> > > I2C SUBSYSTEM (PC drivers, core)
> > > M: Jean Delvare <khali@linux-fr.org>
> > > L: ...
> > > W: ...
> > > T: quilt ...
> > > S: ...
> > > F: Documentation/i2c/
> > > F: drivers/i2c/
> > > F: include/linux/i2c.h
> > > F: include/linux/i2c-*.h
> > >
> > > I2C SUBSYSTEM (embedded platforms)
> > > M: Ben Dooks <ben-linux@fluff.org>
> > > L: ...
> > > W: ...
> > > T: git ...
> > > S: ...
> > > F: drivers/i2c/
> > > F: include/linux/i2c-*.h
> > >
> > > (I'm not entirely sure about the file patterns for the 2nd entry.)
> >
> > I'm not sure what value it adds, compared to having a single entry as
> > we have today. scripts/get_maintainer.pl will produce the same output,
> > won't it?
> >
> > This script (and our minds) being directory-driven, I suspect that the
> > only efficient way to split the entries would be to first move all i2c bus
> > driver for embedded platforms to a separate subdirectory. I'm leaving
> > it to Ben and the embedded community to decide whether they want to do
> > that or not.
>
> I'd much prefer to see just the one directory of i2c drivers, the
> minor point being people silly enough to load modules by explicit path

Never thought of that, but I wouldn't care. There is no good reason to
do this.

> and the second is that having all the drivers in one place makes it
> easier to update them when changing something in the core...

This doesn't seem to be a blocker either. For one thing, i2c
subsystem-wide changes tend to affect chip drivers more than bus
drivers. And even then, looking for drivers in 2 directories doesn't
seem much harder than looking into just one, especially when said 2
directories live next to each other.

So I see no objection to a mass move of all embedded/system i2c bus
drivers to a separate sub-directory.

--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Tues, Jan 26 2010 7:40 am
From: Wolfram Sang

> So I see no objection to a mass move of all embedded/system i2c bus
> drivers to a separate sub-directory.

And with the PCA9xxx-controllers? The ISA-driver into non-embedded and the
platform-driver into embedded? Hmmm...

And (in 80 years ;)) there might be just one I2C-maintainer taking care of them
all? Then, why the split?

I am all for taking the embedded-burden away from you, just I am not too fond
of this idea.

Regards,

Wolfram

--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |

== 3 of 3 ==
Date: Tues, Jan 26 2010 8:40 am
From: Jean Delvare

On Tue, 26 Jan 2010 16:37:59 +0100, Wolfram Sang wrote:
> > So I see no objection to a mass move of all embedded/system i2c bus
> > drivers to a separate sub-directory.
>
> And with the PCA9xxx-controllers? The ISA-driver into non-embedded and the
> platform-driver into embedded? Hmmm...

Ideally the ISA driver would go to the trash can ;) and having both on
separate directories doesn't strike me as being a problem. We have
i2c-algo-bit-based drivers in many places and this has never been a
problem.

> And (in 80 years ;)) there might be just one I2C-maintainer taking care of them
> all? Then, why the split?

That's a more valid argument. But then again, MAINTAINERS can be edited
again later as needed, with split entries getting merged or the other
way around. What matters is that MAINTAINERS reflects the reality of
who is doing what.

> I am all for taking the embedded-burden away from you, just I am not too fond
> of this idea.

I'm not forcing anyone, and I would welcome alternative solutions.

==============================================================================
TOPIC: sysfs_ops show vector: size of buffer not required?
http://groups.google.com/group/linux.kernel/t/8aafe8a10e8404cc?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 7:40 am
From: Greg KH

On Tue, Jan 26, 2010 at 12:01:27PM +0530, Himanshu Chauhan wrote:
> On Mon, Jan 25, 2010 at 08:36:46PM -0800, Greg KH wrote:
> > On Sun, Jan 24, 2010 at 01:11:18PM +0530, Himanshu Chauhan wrote:
> > > Hi All,
> > >
> > > The sysfs_ops's show vector doesn't have a size of the
> > > buffer given to the vector, while store on the other hand
> > > has. What is the rationale behind it?
> >
> > If you need to check the size, you are doing something wrong.
> >
> > Seriously, that is the reason. A sysfs file should be a single value,
> > which will never overflow the buffer.
> >
> I was talking in context of usb/ip's show_status. It writes a lot of data
> into this buffer.

Then it needs to be fixed. Again, it must be, one value per file, that
is the sysfs rule.

> Which seems to over flow the buffer. But anyways, I will check if it
> can be reduced or at least be splitted into differnt device
> attributes.

That would be great.

> BTW, Greg, Did you take a look at other patches I had sent? Are are worth or
> I need rework?

They are in my "to-apply" queue that I will be flushing out in the next
few days.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: x86, mce: Rename cpu_specific_poll to mce_cpu_specific_poll
http://groups.google.com/group/linux.kernel/t/fc4cba69013002ea?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 26 2010 7:40 am
From: Andi Kleen

On Tue, Jan 26, 2010 at 07:33:43AM +0100, Borislav Petkov wrote:
> Uuh, dmidecode doesn't even start to look usable in my book because you
> have to rely on BIOS vendors to fill out the information for you. Here
> are some assorted excerpts from dmidecode on my machines:

For most of the information in DMI decode you can't even
find it any other way. If you can't get it from the BIOS
it's simply not there.

One example are silkscreen labels, which are extremly important
for any kind of hardware error handling.

On my server class systems the information is largely correct. If it's not
on your system perhaps you need to complain to the vendor.

On non server class there are a lot of BIOS problems, but typically
the platforms there don't have enough support for good error
handling anyways.

> how is my L3 4-way set-associative and how do they come up with that???

Cache/CPU information is in lscpu. The important part are the motherboard
resources.

> on any system. And this tool should be distributed with the kernel
> sources like perf is, so that you don't have to jump through hoops to

Most distributions have some kind of summary tool to aggregate
complete system configuration.

It's not the same everywhere, but that's one of the strengths
of Linux imho, not a weakness.

> Oh yes, EDAC has the edac-utils too which access /sysfs files but even
> so, it is suboptimal and we really need a single interface/output
> channel/whatever you call a beast like that to reliably transfer human
> readable hw error info to userspace and/or network. And this has to be
> pushed from kernel space outwards as early as the gravity of the error
> suggests, IMO.

You just reinvented mcelog, congratulations.

> valid reasons to panic the machine. Imagine, for example, you encounter
> (as unlikely as it might be) a multibit error during L1 data cache
> scrubbing which hasn't been consumed yet. Now, technically, no data
> corruption has taken place yet so you can easily start the shell on

When no data corruption has been taken it's not a UC error.

An UC error in this case is defined as something that the hardware
tells us is a UC error, worse even a uncontained UC error

The reason the hardware tells us about that is that it wants us to prevent
further damage. And the primary way to do that is to NOT write anything
to disk, because that would risk corrupting it.

For contained memory UC errors I wrote all the infrastructure last year to
handle them. Making hwpoison better is still an ongoing
project, but it's already quite usable.

> And even if an UC causes data corruption, panicking the system doesn't
> mean that the error has been contained. Nothing can assure you that by
> the time do_machine_check() has run the corrupted data hasn't left the
> CPU core and landed in another core's cache (maybe even on a different

That is why the panic stops all cpus to prevent that.

But yes if the disk write happens at exactly the wrong point the error
could still escape, but we try to keep the window as small as possible.
Typically there's also some hardware help with that to catch currently
in flight transactions. It depends on the platform how well it works.

> Yes, I'm very well aware of that. I'm currently working on a solution.
> It's just an idea now but I might be able to read DIMM configuration
> on the SPD ROM on the DIMM along with their labels and position on the

The SPD ROM doesn't have labels. The only entity who knows them
is the BIOS (or someone who just studied the semantics of the motherboard,
but I don't think we can rely on that)

> 1. Resilient error reporting that reliably pushes decoded error info to
> userspace and/or network. That one might be tricky to do but we'll get
> there.

Not at all tricky. At least on modern Intel platforms mcelog
already does it.

>
> 2. Error severity grading and acting upon each type accordingly. This
> might need to be vendor-specific.

mcelog does it mostly. It's not perfect yet, but not too bad.

> 3. Proper error format suiting all types of errors.

I plan to look into that.

But "suiting all types of errors" is probably a mistake,
I don't think it makes sense to try to invent the one
perfect error that covers everything. People have tried
that in the past and it was always a spectacular failure.

I suspect the better goal is rather a range of error formats
for common situations with a lot of flexibility.

> 5. Error thresholding, representation, etc all done in userspace (maybe
> even on a different machine).

mcelog does that for memory errors on modern systems.

> 6. Last but not least, and maybe this is wishful thinking, a good tool
> to dump hwinfo from the kernel. We do a great job of detecting that info
> already - we should do something with it, at least report it...

IMHO there are already enough of them.

-Andi

--
ak@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Tues, Jan 26 2010 8:10 am
From: Andi Kleen

On Tue, Jan 26, 2010 at 06:06:26PM +0900, Hidetoshi Seto wrote:
> How about having a system file which can be maintained with kernel,
> e.g. like /proc/hwinfo, /sys/devices/platform/hwinfo, or directory
> with some files like /somewhere/hwinfo/{dmi,acpi,pci,...} etc.?

Why not do that in user space?

In fact it's often already done.

Just because we're kernel programmers doesn't mean that everything
needs to be solved inside the kernel.

> >> And since it's kernel
> >> based it cannot do most of the interesting reactions. And it doesn't
> >> have a usable interface to add user events.
> >>
> >> And yes having all that crap in syslog is completely useless, unless
> >> you're debugging code.
> >
> > So basically, IMHO we need:
> >
> > 1. Resilient error reporting that reliably pushes decoded error info to
> > userspace and/or network. That one might be tricky to do but we'll get
> > there.
>
> I think it would be better to think "error" is a subset of "event",
> which could be reported if interested but otherwise be filtered.
> Use of TRACE_EVENT() for mce event aim such approach at least.

The whole trace event infrastructure right now is not really
aimed/useful for "always on low overhead background monitoring" like
standard error handling requires.

In principle it could be probably fixed (although I'm a bit
sceptical on the "low overhead" part), but I suspect the result
would be neither optimized for error handling nor optimized
for performance monitoring anymore. They simply have
very different requirements.

When you do full event tracing anyways it makes some sense to get events
for errors too, but that's a quite different use-case.

For the "standard" error handling I think we're better of with
something optimized for the job.

> > 2. Error severity grading and acting upon each type accordingly. This
> > might need to be vendor-specific.
>
> I think you mean severity grading in kernel.
> Even if hardware reported an error and graded it as corrected, kernel
> can escalate the severity, likely based on some threshold.

I don't think the kernel should do that, it's so much a policy
decision and these are best kept as near the administrator
as possible (= user space)

That is for some cases it might make sense to have limited thresholds
in the kernel, but I suspect they are limited. Mostly it would
be the case when the hardware itselfs already keeps these counters.

>
> > 3. Proper error format suiting all types of errors.
>
> As mentioned in Andi's PDF, CPER format is one of good candidate
> available today, I think.

Yes for hardware errors. It's definitely not perfect and somewhat
overdesigned, but I'm not sure we could come up with a much better one.
At least a subset of it with some extensions might do. Also in some
cases the error is already in this format.

The advantage of it is that it's at least well understood and documented.

> > 4. Vendor-specific hooks where it is needed for in-kernel handling of
> > certain errors (L3 cache index disable, for example).
>
> Some difficulty would be there to add such hook in the UE handling path,
> but anyway we can have it for the CE path. Just need to be organized.
>
> > 5. Error thresholding, representation, etc all done in userspace (maybe
> > even on a different machine).
>
> (...BTW, how about putting mcelog tree under the /tools, Andi?)

I don't see the advantage. Linux has always been a collection
of packages, not a unified single big tree. Also my current
impression is that the in tree user space builds don't work
very well.

-Andi

==============================================================================
TOPIC: fix the lockdep warning in tty_fasync()
http://groups.google.com/group/linux.kernel/t/b92a5fcdc20fcbff?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 8:00 am
From: Américo Wang

On Tue, Jan 26, 2010 at 04:33:38AM -0800, Eric W. Biederman wrote:
>>>
>>> That or tweak __f_setown to use irqsave/irqrestore variants for it's
>>> locks, __f_setown is already atomic. I prefer that direction because the
>>> code is just a little simpler.
>>>
>>
>> Oh, very good advice!
>>
>> Patch is below.
>>
>> -------------->
>> Commit 703625118 causes a lockdep warning:
>>
>> [ INFO: possible irq lock inversion dependency detected ]
>> 2.6.33-rc5 #77
>> ---------------------------------------------------------
>> emacs/1609 just changed the state of lock:
>> (&(&tty->ctrl_lock)->rlock){+.....}, at: [<ffffffff8127c648>]
>> tty_fasync+0xe8/0x190
>> but this lock took another, HARDIRQ-unsafe lock in the past:
>> (&(&sighand->siglock)->rlock){-.....}
>>
>> This is due to we use write_lock_irq() in __f_setown() which turns
>> the IRQ on in write_unlock_irq(), causes this warning.
>>
>> Switch it ot write_lock_irqsave() and write_unlock_irqrestore(),
>> as suggested by Eric.
>>
>> Reported-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
>>
>> ----
>>
>> diff --git a/fs/fcntl.c b/fs/fcntl.c
>> index 97e01dc..556b404 100644
>> --- a/fs/fcntl.c
>> +++ b/fs/fcntl.c
>> @@ -199,7 +199,8 @@ static int setfl(int fd, struct file * filp, unsigned long arg)
>> static void f_modown(struct file *filp, struct pid *pid, enum pid_type type,
>> int force)
>> {
>> - write_lock_irq(&filp->f_owner.lock);
>> + int flags;
>
>Minor nit. This should be "unsigned long flags;"
>

Right... Below is an updated version.

Thanks.

------------>

Commit 703625118 causes a lockdep warning:

[ INFO: possible irq lock inversion dependency detected ]
2.6.33-rc5 #77
---------------------------------------------------------
emacs/1609 just changed the state of lock:
(&(&tty->ctrl_lock)->rlock){+.....}, at: [<ffffffff8127c648>]
tty_fasync+0xe8/0x190
but this lock took another, HARDIRQ-unsafe lock in the past:
(&(&sighand->siglock)->rlock){-.....}

This is due to we use write_lock_irq() in __f_setown() which turns
the IRQ on in write_unlock_irq(), causes this warning.

Switch it to write_lock_irqsave() and write_unlock_irqrestore(),
as suggested by Eric.

Reported-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>

---
diff --git a/fs/fcntl.c b/fs/fcntl.c
index 97e01dc..82cc8a7 100644
--- a/fs/fcntl.c
+++ b/fs/fcntl.c
@@ -199,7 +199,8 @@ static int setfl(int fd, struct file * filp, unsigned long arg)
static void f_modown(struct file *filp, struct pid *pid, enum pid_type type,
int force)
{
- write_lock_irq(&filp->f_owner.lock);
+ unsigned long flags;
+ write_lock_irqsave(&filp->f_owner.lock, flags);
if (force || !filp->f_owner.pid) {
put_pid(filp->f_owner.pid);
filp->f_owner.pid = get_pid(pid);
@@ -211,7 +212,7 @@ static void f_modown(struct file *filp, struct pid *pid, enum pid_type type,
filp->f_owner.euid = cred->euid;
}
}
- write_unlock_irq(&filp->f_owner.lock);
+ write_unlock_irqrestore(&filp->f_owner.lock, flags);
}

int __f_setown(struct file *filp, struct pid *pid, enum pid_type type,

==============================================================================
TOPIC: 2.6.31.8 (OpenSUSE): BUG: scheduling while atomic: swapper/0/0x10000002
http://groups.google.com/group/linux.kernel/t/8d0ef337656f9662?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 8:00 am
From: "Ulrich Windl"

Hello,

maybe it's reported to death already, but I saw a few bugs during boot
with the "current" kernel for openSUSE 11.2. The machine has an AMD
Athlon II DUal Core processor:

klogd 1.4.1, log source = ksyslog started.
<5>[ 0.000000] Linux version 2.6.31.8-0.1-desktop (geeko@buildhost)
(gcc version 4.4.1 [gcc-4_4-branch revision 150839] (SUSE Linux) ) #1
SMP PREEMPT 2009-12-15 23:55:40 +0100
<6>[ 0.000000] KERNEL supported cpus:
<6>[ 0.000000] Intel GenuineIntel
<6>[ 0.000000] AMD AuthenticAMD
<6>[ 0.000000] NSC Geode by NSC
<6>[ 0.000000] Cyrix CyrixInstead
<6>[ 0.000000] Centaur CentaurHauls
<6>[ 0.000000] Transmeta GenuineTMx86
<6>[ 0.000000] Transmeta TransmetaCPU
<6>[ 0.000000] UMC UMC UMC UMC
<6>[ 0.000000] BIOS-provided physical RAM map:
<6>[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800
(usable)
<6>[ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000
(reserved)
<6>[ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000
(reserved)
<6>[ 0.000000] BIOS-e820: 0000000000100000 - 00000000cfee0000
(usable)
<6>[ 0.000000] BIOS-e820: 00000000cfee0000 - 00000000cfee3000 (ACPI
NVS)
<6>[ 0.000000] BIOS-e820: 00000000cfee3000 - 00000000cfef0000 (ACPI
data)
<6>[ 0.000000] BIOS-e820: 00000000cfef0000 - 00000000cff00000
(reserved)
<6>[ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000
(reserved)
<6>[ 0.000000] BIOS-e820: 00000000fec00000 - 0000000100000000
(reserved)
<6>[ 0.000000] BIOS-e820: 0000000100000000 - 0000000130000000
(usable)
<6>[ 0.000000] DMI 2.4 present.
<6>[ 0.000000] last_pfn = 0x130000 max_arch_pfn = 0x1000000
<7>[ 0.000000] MTRR default type: uncachable
<7>[ 0.000000] MTRR fixed ranges enabled:
<7>[ 0.000000] 00000-9FFFF write-back
<7>[ 0.000000] A0000-BFFFF uncachable
<7>[ 0.000000] C0000-C7FFF write-protect
<7>[ 0.000000] C8000-FFFFF uncachable
<7>[ 0.000000] MTRR variable ranges enabled:
<7>[ 0.000000] 0 base 000000000000 mask FFFF80000000 write-back
<7>[ 0.000000] 1 base 000080000000 mask FFFFC0000000 write-back
<7>[ 0.000000] 2 base 0000C0000000 mask FFFFF0000000 write-back
<7>[ 0.000000] 3 base 0000CFF00000 mask FFFFFFF00000 uncachable
<7>[ 0.000000] 4 base 000100000000 mask FFFFE0000000 write-back
<7>[ 0.000000] 5 base 000120000000 mask FFFFF0000000 write-back
<7>[ 0.000000] 6 disabled
<7>[ 0.000000] 7 disabled
<7>[ 0.000000] TOM2: 0000000130000000 aka 4864M
<6>[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new
0x7010600070106
<7>[ 0.000000] e820 update range: 00000000cff00000 -
0000000100000000 (usable) ==> (reserved)
<7>[ 0.000000] e820 update range: 0000000000002000 -
0000000000006000 (usable) ==> (reserved)
<6>[ 0.000000] Scanning 1 areas for low memory corruption
<6>[ 0.000000] modified physical RAM map:
<6>[ 0.000000] modified: 0000000000000000 - 0000000000002000
(usable)
<6>[ 0.000000] modified: 0000000000002000 - 0000000000006000
(reserved)
<6>[ 0.000000] modified: 0000000000006000 - 000000000009f800
(usable)
<6>[ 0.000000] modified: 000000000009f800 - 00000000000a0000
(reserved)
<6>[ 0.000000] modified: 00000000000f0000 - 0000000000100000
(reserved)
<6>[ 0.000000] modified: 0000000000100000 - 00000000cfee0000
(usable)
<6>[ 0.000000] modified: 00000000cfee0000 - 00000000cfee3000 (ACPI
NVS)
<6>[ 0.000000] modified: 00000000cfee3000 - 00000000cfef0000 (ACPI
data)
<6>[ 0.000000] modified: 00000000cfef0000 - 00000000cff00000
(reserved)
<6>[ 0.000000] modified: 00000000e0000000 - 00000000f0000000
(reserved)
<6>[ 0.000000] modified: 00000000fec00000 - 0000000100000000
(reserved)
<6>[ 0.000000] modified: 0000000100000000 - 0000000130000000
(usable)
<7>[ 0.000000] initial memory mapped : 0 - 01000000
<6>[ 0.000000] init_memory_mapping: 0000000000000000-
0000000036ffe000
<6>[ 0.000000] NX (Execute Disable) protection: active
<7>[ 0.000000] 0000000000 - 0000200000 page 4k
<7>[ 0.000000] 0000200000 - 0036e00000 page 2M
<7>[ 0.000000] 0036e00000 - 0036ffe000 page 4k
<7>[ 0.000000] kernel direct mapping tables up to 36ffe000 @ 7000-
12000
<6>[ 0.000000] RAMDISK: 37863000 - 37feffbb
<6>[ 0.000000] Allocated new RAMDISK: 00af9000 - 01285fbb
<6>[ 0.000000] Move RAMDISK from 0000000037863000 - 0000000037feffba
to 00af9000 - 01285fba
<4>[ 0.000000] ACPI: RSDP 000f6fb0 00014 (v00 GBT )
<4>[ 0.000000] ACPI: RSDT cfee3000 0003C (v01 GBT GBTUACPI
42302E31 GBTU 01010101)
<4>[ 0.000000] ACPI: FACP cfee3040 00074 (v01 GBT GBTUACPI
42302E31 GBTU 01010101)
<4>[ 0.000000] ACPI: DSDT cfee30c0 05E23 (v01 GBT GBTUACPI
00001000 MSFT 03000000)
<4>[ 0.000000] ACPI: FACS cfee0000 00040
<4>[ 0.000000] ACPI: SSDT cfee8fc0 0095E (v01 PTLTD POWERNOW
00000001 LTP 00000001)
<4>[ 0.000000] ACPI: HPET cfee9940 00038 (v01 GBT GBTUACPI
42302E31 GBTU 00000098)
<4>[ 0.000000] ACPI: MCFG cfee9980 0003C (v01 GBT GBTUACPI
42302E31 GBTU 01010101)
<4>[ 0.000000] ACPI: TAMG cfee99c0 002FA (v01 GBT GBT B0
5455312E BG 53450101)
<4>[ 0.000000] ACPI: APIC cfee8f00 00084 (v01 GBT GBTUACPI
42302E31 GBTU 01010101)
<7>[ 0.000000] ACPI: Local APIC address 0xfee00000
<4>[ 0.000000] could not find any ACPI SRAT memory areas.
<3>[ 0.000000] failed to get NUMA memory information from SRAT table
<7>[ 0.000000] NUMA - single node, flat memory mode
<6>[ 0.000000] Node: 0, start_pfn: 0, end_pfn: 130000
<7>[ 0.000000] Setting physnode_map array to node 0 for pfns:
<7>[ 0.000000] 0 4000 8000 c000 10000 14000 18000 1c000 20000
24000 28000 2c000 30000 34000 38000 3c000 40000 44000 48000 4c000 50000
54000 58000 5c000 60000 64000 68000 6c000 70000 74000 78000 7c000 80000
84000 88000 8c000 90000 94000 98000 9c000 a0000 a4000 a8000 ac000 b0000
b4000 b8000 bc000 c0000 c4000 c8000 cc000 d0000 d4000 d8000 dc000 e0000
e4000 e8000 ec000 f0000 f4000 f8000 fc000 100000 104000 108000 10c000
110000 114000 118000 11c000 120000 124000 128000 12c000
<7>[ 0.000000] node 0 pfn: [0 - 130000]
<7>[ 0.000000] Reserving 10240 pages of KVA for lmem_map of node 0
at 12d800
<7>[ 0.000000] remove_active_range (0, 1234944, 1245184)
<6>[ 0.000000] Reserving total of 2800 pages for numa KVA remap
<6>[ 0.000000] kva_start_pfn ~ 34600 max_low_pfn ~ 36ffe
<6>[ 0.000000] max_pfn = 130000
<5>[ 0.000000] 3984MB HIGHMEM available.
<5>[ 0.000000] 879MB LOWMEM available.
<7>[ 0.000000] max_low_pfn = 36ffe, highstart_pfn = 36ffe
<7>[ 0.000000] Low memory ends at vaddr f6ffe000
<7>[ 0.000000] node 0 will remap to vaddr f4600000 - f6e00000
<7>[ 0.000000] allocate_pgdat: node 0 NODE_DATA f4600000
<7>[ 0.000000] remap_numa_kva: node 0
<7>[ 0.000000] remap_numa_kva: f4600000 to pfn 0012d800
<7>[ 0.000000] remap_numa_kva: f4800000 to pfn 0012da00
<7>[ 0.000000] remap_numa_kva: f4a00000 to pfn 0012dc00
<7>[ 0.000000] remap_numa_kva: f4c00000 to pfn 0012de00
<7>[ 0.000000] remap_numa_kva: f4e00000 to pfn 0012e000
<7>[ 0.000000] remap_numa_kva: f5000000 to pfn 0012e200
<7>[ 0.000000] remap_numa_kva: f5200000 to pfn 0012e400
<7>[ 0.000000] remap_numa_kva: f5400000 to pfn 0012e600
<7>[ 0.000000] remap_numa_kva: f5600000 to pfn 0012e800
<7>[ 0.000000] remap_numa_kva: f5800000 to pfn 0012ea00
<7>[ 0.000000] remap_numa_kva: f5a00000 to pfn 0012ec00
<7>[ 0.000000] remap_numa_kva: f5c00000 to pfn 0012ee00
<7>[ 0.000000] remap_numa_kva: f5e00000 to pfn 0012f000
<7>[ 0.000000] remap_numa_kva: f6000000 to pfn 0012f200
<7>[ 0.000000] remap_numa_kva: f6200000 to pfn 0012f400
<7>[ 0.000000] remap_numa_kva: f6400000 to pfn 0012f600
<7>[ 0.000000] remap_numa_kva: f6600000 to pfn 0012f800
<7>[ 0.000000] remap_numa_kva: f6800000 to pfn 0012fa00
<7>[ 0.000000] remap_numa_kva: f6a00000 to pfn 0012fc00
<7>[ 0.000000] remap_numa_kva: f6c00000 to pfn 0012fe00
<7>[ 0.000000] High memory starts at vaddr f6ffe000
<6>[ 0.000000] mapped low ram: 0 - 36ffe000
<6>[ 0.000000] low ram: 0 - 36ffe000
<6>[ 0.000000] node 0 low ram: 00000000 - 36ffe000
<6>[ 0.000000] node 0 bootmap 0000f000 - 00015e00
<6>[ 0.000000] (11 early reservations) ==> bootmem [0000000000 -
0036ffe000]
<6>[ 0.000000] #0 [0000000000 - 0000001000] BIOS data page ==>
[0000000000 - 0000001000]
<6>[ 0.000000] #1 [0000001000 - 0000002000] EX TRAMPOLINE ==>
[0000001000 - 0000002000]
<6>[ 0.000000] #2 [0000006000 - 0000007000] TRAMPOLINE ==>
[0000006000 - 0000007000]
<6>[ 0.000000] #3 [0000200000 - 0000aefab0] TEXT DATA BSS ==>
[0000200000 - 0000aefab0]
<6>[ 0.000000] #4 [000009f800 - 0000100000] BIOS reserved ==>
[000009f800 - 0000100000]
<6>[ 0.000000] #5 [0000af0000 - 0000af80fe] BRK ==>
[0000af0000 - 0000af80fe]
<6>[ 0.000000] #6 [0000007000 - 000000f000] PGTABLE ==>
[0000007000 - 000000f000]
<6>[ 0.000000] #7 [0000af9000 - 0001285fbb] NEW RAMDISK ==>
[0000af9000 - 0001285fbb]
<6>[ 0.000000] #8 [012d800000 - 0130000000] KVA RAM
<6>[ 0.000000] #9 [0034600000 - 0036e00000] KVA PG ==>
[0034600000 - 0036e00000]
<6>[ 0.000000] #10 [000000f000 - 0000016000] BOOTMAP ==>
[000000f000 - 0000016000]
<6>[ 0.000000] found SMP MP-table at [c00f55a0] f55a0
<4>[ 0.000000] Zone PFN ranges:
<4>[ 0.000000] DMA 0x00000000 -> 0x00001000
<4>[ 0.000000] Normal 0x00001000 -> 0x00036ffe
<4>[ 0.000000] HighMem 0x00036ffe -> 0x00130000
<4>[ 0.000000] Movable zone start PFN for each node
<4>[ 0.000000] early_node_map[4] active PFN ranges
<4>[ 0.000000] 0: 0x00000000 -> 0x00000002
<4>[ 0.000000] 0: 0x00000006 -> 0x0000009f
<4>[ 0.000000] 0: 0x00000100 -> 0x000cfee0
<4>[ 0.000000] 0: 0x00100000 -> 0x0012d800
<7>[ 0.000000] On node 0 totalpages: 1037947
<7>[ 0.000000] free_area_init_node: node 0, pgdat f4600000,
node_mem_map f4602000
<7>[ 0.000000] DMA zone: 32 pages used for memmap
<7>[ 0.000000] DMA zone: 0 pages reserved
<7>[ 0.000000] DMA zone: 3963 pages, LIFO batch:0
<7>[ 0.000000] Normal zone: 1728 pages used for memmap
<7>[ 0.000000] Normal zone: 219454 pages, LIFO batch:31
<7>[ 0.000000] HighMem zone: 7889 pages used for memmap
<7>[ 0.000000] HighMem zone: 804881 pages, LIFO batch:31
<6>[ 0.000000] Using APIC driver default
<6>[ 0.000000] ACPI: PM-Timer IO Port: 0x4008
<7>[ 0.000000] ACPI: Local APIC address 0xfee00000
<6>[ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
<6>[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
<6>[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
<6>[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
<6>[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
<6>[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
<6>[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
<6>[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
<6>[ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000]
gsi_base[0])
<6>[ 0.000000] IOAPIC[0]: apic_id 2, version 33, address 0xfec00000,
GSI 0-23
<6>[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl
dfl)
<6>[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low
level)
<7>[ 0.000000] ACPI: IRQ0 used by override.
<7>[ 0.000000] ACPI: IRQ2 used by override.
<7>[ 0.000000] ACPI: IRQ9 used by override.
<6>[ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs
<6>[ 0.000000] Using ACPI (MADT) for SMP configuration information
<6>[ 0.000000] ACPI: HPET id: 0x10b9a201 base: 0xfed00000
<6>[ 0.000000] SMP: Allowing 4 CPUs, 2 hotplug CPUs
<7>[ 0.000000] nr_irqs_gsi: 24
<6>[ 0.000000] PM: Registered nosave memory: 0000000000002000 -
0000000000006000
<6>[ 0.000000] PM: Registered nosave memory: 000000000009f000 -
00000000000a0000
<6>[ 0.000000] PM: Registered nosave memory: 00000000000a0000 -
00000000000f0000
<6>[ 0.000000] PM: Registered nosave memory: 00000000000f0000 -
0000000000100000
<6>[ 0.000000] Allocating PCI resources starting at cff00000 (gap:
cff00000:10100000)
<6>[ 0.000000] NR_CPUS:128 nr_cpumask_bits:128 nr_cpu_ids:4
nr_node_ids:8
<6>[ 0.000000] PERCPU: Embedded 14 pages at c1296000, static data
34204 bytes
<4>[ 0.000000] Built 1 zonelists in Zone order, mobility grouping
on. Total pages: 1028298
<4>[ 0.000000] Policy zone: HighMem
<5>[ 0.000000] Kernel command line: root=/dev/sda8
resume=/dev/sysVG/swapLV splash=silent vga=0x317
<6>[ 0.000000] bootsplash: silent mode.
<4>[ 0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes)
<6>[ 0.000000] Dentry cache hash table entries: 131072 (order: 7,
524288 bytes)
<6>[ 0.000000] Inode-cache hash table entries: 65536 (order: 6,
262144 bytes)
<6>[ 0.000000] Enabling fast FPU save and restore... done.
<6>[ 0.000000] Enabling unmasked SIMD FPU exception support... done.
<6>[ 0.000000] Initializing CPU#0
<6>[ 0.000000] Initializing HighMem for node 0 (00036ffe:0012d800)
<6>[ 0.000000] Memory: 4092768k/4980736k available (4720k kernel
code, 59016k reserved, 2951k data, 464k init, 3251080k highmem)
<6>[ 0.000000] virtual kernel memory layout:
<6>[ 0.000000] fixmap : 0xff5b5000 - 0xfffff000 (10536 kB)
<6>[ 0.000000] pkmap : 0xff000000 - 0xff200000 (2048 kB)
<6>[ 0.000000] vmalloc : 0xf77fe000 - 0xfeffe000 ( 120 MB)
<6>[ 0.000000] lowmem : 0xc0000000 - 0xf6ffe000 ( 879 MB)
<6>[ 0.000000] .init : 0xc097f000 - 0xc09f3000 ( 464 kB)
<6>[ 0.000000] .data : 0xc069c1b2 - 0xc097e0c8 (2951 kB)
<6>[ 0.000000] .text : 0xc0200000 - 0xc069c1b2 (4720 kB)
<6>[ 0.000000] Checking if this processor honours the WP bit even in
supervisor mode...Ok.
<6>[ 0.000000] Hierarchical RCU implementation.
<6>[ 0.000000] NR_IRQS:2304 nr_irqs:440
<4>[ 0.000000] Fast TSC calibration using PIT
<4>[ 0.000000] Detected 2812.665 MHz processor.
<4>[ 0.000055] Console: colour dummy device 80x25
<6>[ 0.000057] console [tty0] enabled
<7>[ 0.000482] hpet clockevent registered
<7>[ 0.000487] alloc irq_desc for 24 on node 0
<7>[ 0.000489] alloc kstat_irqs on node 0
<6>[ 0.000495] HPET: 4 timers in total, 1 timers will be used for
per-cpu timer
<6>[ 0.001006] Calibrating delay loop (skipped), value calculated
using timer frequency.. 5625.33 BogoMIPS (lpj=2812665)
<4>[ 0.006162] kdb version 4.4 by Keith Owens, Scott Lurndal.
Copyright SGI, All Rights Reserved
<6>[ 0.006230] Security Framework initialized
<6>[ 0.006243] AppArmor: AppArmor initialized
<4>[ 0.006260] Mount-cache hash table entries: 512
<6>[ 0.006355] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64
bytes/line)
<6>[ 0.006360] CPU: L2 Cache: 1024K (64 bytes/line)
<6>[ 0.006364] CPU: Physical Processor ID: 0
<6>[ 0.006366] CPU: Processor Core ID: 0
<6>[ 0.006370] mce: CPU supports 6 MCE banks
<6>[ 0.006378] using C1E aware idle routine
<6>[ 0.006383] Performance Counters: AMD PMU driver.
<6>[ 0.006388] ... version: 0
<6>[ 0.006391] ... bit width: 48
<6>[ 0.006393] ... generic counters: 4
<6>[ 0.006396] ... value mask: 0000ffffffffffff
<6>[ 0.006400] ... max period: 00007fffffffffff
<6>[ 0.006403] ... fixed-purpose counters: 0
<6>[ 0.006406] ... counter mask: 000000000000000f
<6>[ 0.006411] Checking 'hlt' instruction... OK.
<6>[ 0.010745] Unpacking initramfs...
<3>[ 0.018131] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.018138] Modules linked in:
<4>[ 0.018143] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.018147] Call Trace:
<4>[ 0.018159] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.018166] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.018172] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.018178] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.018184] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.018190] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.018196] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.018201] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.018206] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.018212] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.018218] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.018224] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.018229] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.018235] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.018240] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.018245] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.018250] [<c0981627>] do_copy+0xa1/0xe6
<4>[ 0.018255] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.018261] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.018266] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.018272] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.018277] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.018282] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.027082] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.027089] Modules linked in:
<4>[ 0.027093] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.027097] Call Trace:
<4>[ 0.027108] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.027115] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.027120] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.027126] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.027132] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.027138] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.027143] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.027149] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.027154] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.027160] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.027166] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.027171] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.027177] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.027183] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.027188] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.027193] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.027199] [<c0981627>] do_copy+0xa1/0xe6
<4>[ 0.027204] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.027209] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.027215] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.027220] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.027225] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.027230] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.036220] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.036226] Modules linked in:
<4>[ 0.036231] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.036235] Call Trace:
<4>[ 0.036246] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.036253] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.036258] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.036264] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.036269] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.036275] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.036281] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.036287] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.036292] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.036297] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.036303] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.036309] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.036315] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.036320] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.036325] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.036330] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.036336] [<c09815c3>] do_copy+0x3d/0xe6
<4>[ 0.036341] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.036346] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.036352] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.036357] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.036362] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.036367] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.045219] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.045227] Modules linked in:
<4>[ 0.045231] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.045235] Call Trace:
<4>[ 0.045247] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.045253] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.045259] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.045264] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.045270] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.045276] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.045281] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.045287] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.045292] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.045298] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.045303] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.045309] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.045315] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.045320] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.045326] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.045330] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.045336] [<c0981627>] do_copy+0xa1/0xe6
<4>[ 0.045341] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.045347] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.045352] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.045357] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.045362] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.045368] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.054226] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.054232] Modules linked in:
<4>[ 0.054237] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.054241] Call Trace:
<4>[ 0.054251] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.054258] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.054263] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.054269] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.054275] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.054281] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.054286] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.054292] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.054297] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.054303] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.054309] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.054314] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.054320] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.054326] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.054331] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.054336] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.054341] [<c0981627>] do_copy+0xa1/0xe6
<4>[ 0.054346] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.054352] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.054357] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.054363] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.054368] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.054373] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.063082] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.063088] Modules linked in:
<4>[ 0.063092] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.063096] Call Trace:
<4>[ 0.063106] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.063112] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.063118] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.063123] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.063129] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.063135] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.063141] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.063146] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.063151] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.063157] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.063163] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.063168] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.063174] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.063180] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.063185] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.063190] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.063196] [<c09815c3>] do_copy+0x3d/0xe6
<4>[ 0.063201] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.063206] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.063212] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.063217] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.063222] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.063228] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.072153] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.072159] Modules linked in:
<4>[ 0.072164] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.072168] Call Trace:
<4>[ 0.072179] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.072185] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.072191] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.072196] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.072202] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.072208] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.072214] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.072220] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.072225] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.072230] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.072236] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.072242] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.072248] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.072253] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.072259] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.072263] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.072269] [<c0981627>] do_copy+0xa1/0xe6
<4>[ 0.072274] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.072279] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.072285] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.072290] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.072295] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.072300] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.081111] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.081118] Modules linked in:
<4>[ 0.081122] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.081126] Call Trace:
<4>[ 0.081137] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.081143] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.081149] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.081155] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.081161] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.081167] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.081172] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.081178] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.081183] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.081188] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.081194] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.081200] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.081206] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.081211] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.081216] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.081221] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.081227] [<c09815c3>] do_copy+0x3d/0xe6
<4>[ 0.081232] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.081238] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.081243] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.081248] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.081253] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.081259] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.090140] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.090147] Modules linked in:
<4>[ 0.090151] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.090155] Call Trace:
<4>[ 0.090166] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.090173] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.090178] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.090184] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.090190] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.090196] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.090201] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.090207] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.090212] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.090218] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.090223] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.090229] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.090235] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.090241] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.090246] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.090251] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.090256] [<c0981627>] do_copy+0xa1/0xe6
<4>[ 0.090261] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.090267] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.090272] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.090278] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.090283] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.090288] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.100080] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.100086] Modules linked in:
<4>[ 0.100091] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.100095] Call Trace:
<4>[ 0.100106] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.100113] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.100118] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.100124] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.100130] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.100135] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.100141] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.100147] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.100152] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.100157] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.100163] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.100169] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.100175] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.100180] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.100186] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.100190] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.100196] [<c0981627>] do_copy+0xa1/0xe6
<4>[ 0.100201] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.100207] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.100212] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.100217] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.100222] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.100228] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.109088] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.109095] Modules linked in:
<4>[ 0.109100] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.109104] Call Trace:
<4>[ 0.109115] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.109121] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.109127] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.109133] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.109138] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.109144] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.109150] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.109156] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.109161] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.109167] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.109173] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.109178] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.109184] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.109190] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.109195] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.109200] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.109206] [<c0981627>] do_copy+0xa1/0xe6
<4>[ 0.109211] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.109216] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.109222] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.109227] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.109232] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.109238] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.118041] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.118048] Modules linked in:
<4>[ 0.118052] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.118056] Call Trace:
<4>[ 0.118066] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.118073] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.118079] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.118084] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.118090] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.118096] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.118102] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.118107] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.118112] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.118118] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.118124] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.118130] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.118135] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.118141] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.118146] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.118151] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.118157] [<c0981627>] do_copy+0xa1/0xe6
<4>[ 0.118162] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.118167] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.118173] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.118178] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.118183] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.118188] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.127070] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.127076] Modules linked in:
<4>[ 0.127080] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.127085] Call Trace:
<4>[ 0.127095] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.127102] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.127107] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.127113] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.127118] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.127124] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.127130] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.127136] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.127141] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.127146] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.127152] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.127158] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.127164] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.127169] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.127175] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.127180] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.127185] [<c0981627>] do_copy+0xa1/0xe6
<4>[ 0.127190] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.127196] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.127201] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.127206] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.127211] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.127217] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.135994] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.136001] Modules linked in:
<4>[ 0.136005] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.136009] Call Trace:
<4>[ 0.136020] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.136026] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.136032] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.136037] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.136043] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.136050] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.136055] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.136061] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.136066] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.136071] [<c02d3adc>] generic_perform_write+0x13c/0x1e0
<4>[ 0.136077] [<c02d3bfb>] generic_file_buffered_write+0x7b/0x150
<4>[ 0.136083] [<c02d55c3>]
__generic_file_aio_write_nolock+0x213/0x530
<4>[ 0.136089] [<c02d5a15>] generic_file_aio_write+0x65/0xe0
<4>[ 0.136094] [<c031538c>] do_sync_write+0xdc/0x130
<4>[ 0.136100] [<c03156ba>] vfs_write+0xba/0x1b0
<4>[ 0.136105] [<c03160c3>] sys_write+0x53/0xa0
<4>[ 0.136110] [<c0981627>] do_copy+0xa1/0xe6
<4>[ 0.136115] [<c0980f6b>] flush_buffer+0x81/0xb8
<4>[ 0.136121] [<c09a770d>] gunzip+0x374/0x428
<4>[ 0.136127] [<c098147b>] unpack_to_rootfs+0x29f/0x3aa
<4>[ 0.136132] [<c0981ef9>] populate_rootfs+0x59/0x87
<4>[ 0.136137] [<c097fcd3>] start_kernel+0x38d/0x3ae
<4>[ 0.136143] [<c097f087>] i386_start_kernel+0x87/0x9f
<6>[ 0.141362] Freeing initrd memory: 7731k freed
<6>[ 0.143213] ACPI: Core revision 20090521
<3>[ 0.148749] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.148753] Modules linked in:
<4>[ 0.148757] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.148761] Call Trace:
<4>[ 0.148773] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.148780] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.148785] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.148791] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.148797] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.148803] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.148809] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.148814] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.148819] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.148826] [<c048c574>] acpi_ps_complete_op+0x229/0x249
<4>[ 0.148833] [<c048c9bb>] acpi_ps_parse_loop+0x2e4/0x331
<4>[ 0.148839] [<c048b9d8>] acpi_ps_parse_aml+0xdd/0x33e
<4>[ 0.148845] [<c048a890>] acpi_ns_one_complete_parse+0x11c/0x149
<4>[ 0.148851] [<c048a8ff>] acpi_ns_parse_table+0x42/0x8f
<4>[ 0.148857] [<c0487059>] acpi_ns_load_table+0x69/0xf8
<4>[ 0.148863] [<c048ef1c>] acpi_tb_load_namespace+0x6e/0x136
<4>[ 0.148869] [<c048effa>] acpi_load_tables+0x16/0x4b
<4>[ 0.148875] [<c09abfe7>] acpi_early_init+0x7e/0x11d
<4>[ 0.148881] [<c097fcd8>] start_kernel+0x392/0x3ae
<4>[ 0.148887] [<c097f087>] i386_start_kernel+0x87/0x9f
<3>[ 0.149006] BUG: scheduling while atomic: swapper/0/0x10000002
<4>[ 0.149010] Modules linked in:
<4>[ 0.149014] Pid: 0, comm: swapper Not tainted 2.6.31.8-0.1-
desktop #1
<4>[ 0.149017] Call Trace:
<4>[ 0.149023] [<c020845a>] try_stack_unwind+0x17a/0x1a0
<4>[ 0.149028] [<c020708c>] dump_trace+0x6c/0x130
<4>[ 0.149034] [<c0208008>] show_trace_log_lvl+0x58/0x80
<4>[ 0.149039] [<c0208056>] show_trace+0x26/0x40
<4>[ 0.149044] [<c0692e53>] dump_stack+0x79/0x91
<4>[ 0.149049] [<c023f137>] __schedule_bug+0x87/0x90
<4>[ 0.149054] [<c0693b88>] schedule+0x688/0x7a0
<4>[ 0.149060] [<c02480eb>] __cond_resched+0x2b/0x60
<4>[ 0.149065] [<c0693dfd>] _cond_resched+0x3d/0x50
<4>[ 0.149070] [<c048c574>] acpi_ps_complete_op+0x229/0x249
<4>[ 0.149076] [<c048c9bb>] acpi_ps_parse_loop+0x2e4/0x331
<4>[ 0.149083] [<c048b9d8>] acpi_ps_parse_aml+0xdd/0x33e
<4>[ 0.149088] [<c048a890>] acpi_ns_one_complete_parse+0x11c/0x149
<4>[ 0.149095] [<c048a8ff>] acpi_ns_parse_table+0x42/0x8f
<4>[ 0.149100] [<c0487059>] acpi_ns_load_table+0x69/0xf8
<4>[ 0.149105] [<c048ef1c>] acpi_tb_load_namespace+0x6e/0x136
<4>[ 0.149111] [<c048effa>] acpi_load_tables+0x16/0x4b
<4>[ 0.149116] [<c09abfe7>] acpi_early_init+0x7e/0x11d
<4>[ 0.149121] [<c097fcd8>] start_kernel+0x392/0x3ae
<4>[ 0.149126] [<c097f087>] i386_start_kernel+0x87/0x9f
<6>[ 0.153296] Mapping cpu 0 to node 0
<6>[ 0.154164] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
<6>[ 0.164172] CPU0: AMD Athlon(tm) II X2 240 Processor stepping 02
<6>[ 0.164974] Booting processor 1 APIC 0x1 ip 0x6000
<6>[ 0.000999] Initializing CPU#1
<6>[ 0.000999] Mapping cpu 1 to node 0
<6>[ 0.000999] Calibrating delay using timer specific routine..
5625.44 BogoMIPS (lpj=2812722)
<6>[ 0.000999] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64
bytes/line)
<6>[ 0.000999] CPU: L2 Cache: 1024K (64 bytes/line)
<6>[ 0.000999] CPU: Physical Processor ID: 0
<6>[ 0.000999] CPU: Processor Core ID: 1
<6>[ 0.000999] mce: CPU supports 6 MCE banks
<6>[ 0.000999] x86 PAT enabled: cpu 1, old 0x7040600070406, new
0x7010600070106
<6>[ 0.235481] CPU1: AMD Athlon(tm) II X2 240 Processor stepping 02
<6>[ 0.235508] checking TSC synchronization [CPU#0 -> CPU#1]:
passed.
<6>[ 0.235983] Brought up 2 CPUs
<6>[ 0.235991] Total of 2 processors activated (11250.77 BogoMIPS).
<7>[ 0.236113] CPU0 attaching sched-domain:
<7>[ 0.236115] domain 0: span 0-1 level MC
<7>[ 0.236117] groups: 0 1
<7>[ 0.236121] domain 1: span 0-1 level NODE
<7>[ 0.236123] groups: 0-1
<7>[ 0.236126] CPU1 attaching sched-domain:
<7>[ 0.236128] domain 0: span 0-1 level MC
<7>[ 0.236130] groups: 1 0
<7>[ 0.236132] domain 1: span 0-1 level NODE
<7>[ 0.236134] groups: 0-1
<6>[ 0.238031] devtmpfs: initialized
<6>[ 0.238131] Booting paravirtualized kernel on bare hardware
<6>[ 0.238131] regulator: core version 0.5
<4>[ 0.238131] Time: 20:18:12 Date: 01/23/10
[...]

Regards,
Ulrich Windl

==============================================================================
TOPIC: linux-next: add utrace tree
http://groups.google.com/group/linux.kernel/t/67ebc22686b326f0?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 26 2010 8:10 am
From: Johannes Stezenbach

On Mon, Jan 25, 2010 at 04:07:21PM -0800, Linus Torvalds wrote:
> On Tue, 26 Jan 2010, Renzo Davoli wrote:
> >
> > The solution is that everybody can code his/her optimized kernel/user
> > interface for tracing in his/her kernel module, i.e. utrace.
>
> I don't think people understand. That is simply not a "solution". That is
> a PROBLEM. The thing you describe is an absolute disaster. Which is
> exactly why I rant against it.
>
> The last thing we want to have is "here, take this, and make your own
> kernel module mess around it optimized for your particular crazy
> scenario".
>
> But every SINGLE post in this thread that has argued for utrace has argued
> exactly this way.

I haven't followed much of the utrace discussions, but my impression was
that utrace primarily is a cleanup effort, replacing "don't change it,
you might break it" code with a clean, well defined (and even documented)
implementation. To make it easier for people not familiar
with the low-level architecture details to experiment with
debugging stuff.

Two points to consider:

1. If you'd merge utrace + ptrace-on-utrace, but never anything else
which uses the utrace API, wouldn't it still be an improvement?

2. A well defined utrace API makes debugging code more hackable, thus more
likely that someone might come up with a brilliant killer debug
feature in the future. (This might sound lame, but there are already
a few people doing crazy things with utrace while I'm not aware
that people have done such experiments based on the current ptrace impl.)

BTW, the ptrace improvements discussed elsewhere in this thread
(like using an fd intead of signals/wait) are orthogonal
to utrace, no? IMHO it's a seperate discussion.

Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Tues, Jan 26 2010 8:30 am
From: Linus Torvalds

On Tue, 26 Jan 2010, Johannes Stezenbach wrote:
>
> 1. If you'd merge utrace + ptrace-on-utrace, but never anything else
> which uses the utrace API, wouldn't it still be an improvement?

I already said earlier that I'd be perfectly happy to merge utrace code,
as long as it was clear that I'm not merging a platform for crazy work.
IOW, the end result might be merging 99% of the code, but I want to set
peoples _expectations_ right. I'm not at all interested in merging stuff
that has various exported helper functions for people doing random things,
but I could happily merge stuff that cleans up internal implementation.

> 2. A well defined utrace API makes debugging code more hackable, thus more
> likely that someone might come up with a brilliant killer debug
> feature in the future.

I don't really agree.

Clean code makes things easier to improve, and maybe utrace cleans thigns
up. But defining new API's makes me very worried, and quite frankly, the
last thing I ever want to see is a new interface that out-of-tree modules
starr using for random hacking.

So I'd be much happier without the whole utrace kernel interface and
callbacks, and very much would want to avoid the whole issue of plugins.
I'd like to see ptrace improvements - not something else.

In other words, I'd much much rather keep the utrace thing _internal_ to
ptrace. If people have performance complaints about ptrace, let's look at
fixing those _as_such_, rather than look at new modules etc.

> BTW, the ptrace improvements discussed elsewhere in this thread
> (like using an fd intead of signals/wait) are orthogonal
> to utrace, no? IMHO it's a seperate discussion.

Largely, yes. Tied together to some degree of course, but the whole issue
of code cleanup can be seen as a reasonably independent first step (while
moving to a fd-based interface should probably not be done without some
cleanup first, so they _are_ somewhat tied together).

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 3 ==
Date: Tues, Jan 26 2010 8:40 am
From: Christoph Hellwig

On Tue, Jan 26, 2010 at 08:28:15AM -0800, Linus Torvalds wrote:
> I already said earlier that I'd be perfectly happy to merge utrace code,
> as long as it was clear that I'm not merging a platform for crazy work.
> IOW, the end result might be merging 99% of the code, but I want to set
> peoples _expectations_ right. I'm not at all interested in merging stuff
> that has various exported helper functions for people doing random things,
> but I could happily merge stuff that cleans up internal implementation.

> Clean code makes things easier to improve, and maybe utrace cleans thigns
> up. But defining new API's makes me very worried, and quite frankly, the
> last thing I ever want to see is a new interface that out-of-tree modules
> starr using for random hacking.

To be fair Roland and Oleg did a lot of work on improving ptrace support
that was an offsprint of utrace. It would be great if the reamaining
architectures would catch up on beeing converted to it and getting rid
of the existing hairy arch ptrace code as much as possible.

I'm still not really set on utrace either, but the in-kernel gdbstub
Frank has started could be a real killer if it ever gets done up to
a fully usable state. If it really requires all the utrace abstractions
that seem a bit overdone I'm not sure. Might be a better idea to try to
get uprobes and the gdbstub in without it and see how much of the
abstraction will be needed anyway as a fallout, just without exporting
them to modules and thus actually making them published APIs.

==============================================================================
TOPIC: ata: Disable NCQ for Crucial M225 brand SSDs
http://groups.google.com/group/linux.kernel/t/89c4d92bc1e1249b?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 26 2010 8:10 am
From: Alan Cox

> Should work with 64, 128 (tested) and 256 GB capacities with any
> firmware versions in
> drivers/ata/libata-core.c because of ATA errors in dmesg, hangs and
> filesystem corruption.

If you've only tested one type why list all three ? Also you've not
listed a firmware version so do you know which are affected ?

What controllers did you test with ?

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Tues, Jan 26 2010 8:20 am
From: Vishal Rao

2010/1/26 Alan Cox <alan@lxorguk.ukuu.org.uk>:
>> Should work with 64, 128 (tested) and 256 GB capacities with any
>> firmware versions in
>> drivers/ata/libata-core.c because of ATA errors in dmesg, hangs and
>> filesystem corruption.
>
> If you've only tested one type why list all three ? Also you've not
> listed a firmware version so do you know which are affected ?
>
> What controllers did you test with ?
>
> Alan
>

The 3 IDs should match I believe and the firmware parameter is NULL.
Affected firmware versions include at least the latest 1916 and the
previous 1819, likely older ones as well.

Tested with my own Crucial CT128M225 model which has the IndiLinx
Barefoot controller.

The libata-core.c file has an existing line for "OCZ_CORESSD" for a
particular firmware version
but I suspect many, if not all of those controllers may have this issue?
At least one user of Intel SSDs reports no issues with existing
kernels and I've read that
they do NCQ right.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: regulator: support max8649
http://groups.google.com/group/linux.kernel/t/0c21f2834789c0db?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 8:20 am
From: Liam Girdwood

On Tue, 2010-01-26 at 07:14 -0500, Haojian Zhuang wrote:
> On Tue, Jan 26, 2010 at 7:00 AM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
> > On Tue, Jan 26, 2010 at 06:54:48AM -0500, Haojian Zhuang wrote:
> >> On Tue, Jan 26, 2010 at 6:04 AM, Mark Brown
> >
> >> > I'd expect the time taken to enable to be the voltage multipled by the
> >> > step size rather than divided by the step size?
> >
> >> I don't agree at this point. The unit of step is uV/uSec. The function
> >> should return uSec. So voltage divided by the step is more reasonable.
> >
> > Ah, then the variable step is confusingly named since it's actually a
> > rate of change rather than a step size - I'd suggest rate or something
> > like that instead.
> >
>
> update this patch.
>

Applied.

Thanks

Liam

==============================================================================
TOPIC: Fix 1 untangling ima mess, part 2 with counters
http://groups.google.com/group/linux.kernel/t/fca0cbdc1743a322?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 8:30 am
From: Al Viro

On Tue, Jan 26, 2010 at 10:16:55AM -0500, Mimi Zohar wrote:
> --- security-testing-2.6.orig/init/main.c
> +++ security-testing-2.6/init/main.c
> @@ -663,9 +663,9 @@ asmlinkage void __init start_kernel(void
> proc_caches_init();
> buffer_init();
> key_init();
> + radix_tree_init();
> security_init();
> vfs_caches_init(totalram_pages);
> - radix_tree_init();
> signals_init();
> /* rootfs populating might need page-writeback */
> page_writeback_init();

FWIW, I'd take radix_tree_init() much earlier than that; it's a common
infrastructure and if we have it early it'll mean less headache.

AFAICS, it can go right after mm_init(). Objections, anyone?

Other than that, I'm OK with that one.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: move efifb's probe function to .devinit.text
http://groups.google.com/group/linux.kernel/t/7db9be36a46d6f4f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 8:30 am
From: Peter Jones

On 01/23/2010 03:35 PM, Uwe Kleine-König wrote:
> A pointer to efifb_probe is passed to the core via
> platform_driver_register and so the function must not disappear when the
> .init sections are discarded. Otherwise (if also having HOTPLUG=y)
> unbinding and binding a device to the driver via sysfs will result in an
> oops as does a device being registered late.
>
> An alternative to this patch is using platform_driver_probe instead of
> platform_driver_register plus removing the pointer to the probe function
> from the struct platform_driver.

__devinit looks reasonable enough to me.

Acked-By: Peter Jones <pjones@redhat.com>

>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Cc: Peter Jones <pjones@redhat.com>
> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
> Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> Cc: Jaya Kumar <jayakumar.lkml@gmail.com>
> Cc: Ralf Baechle <ralf@linux-mips.org>
> Cc: Maciej W. Rozycki <macro@linux-mips.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Chandramouli Narayanan <mouli@linux.intel.com>
> Cc: Huang Ying <ying.huang@intel.com>
> ---
> drivers/video/efifb.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/video/efifb.c b/drivers/video/efifb.c
> index eb12182..2161f21 100644
> --- a/drivers/video/efifb.c
> +++ b/drivers/video/efifb.c
> @@ -201,7 +201,7 @@ static int __init efifb_setup(char *options)
> return 0;
> }
>
> -static int __init efifb_probe(struct platform_device *dev)
> +static int __devinit efifb_probe(struct platform_device *dev)
> {
> struct fb_info *info;
> int err;

--
Peter

The trouble with the global village are all the global village idiots.
-- Paul Ginsparg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: R: [Bug #14886] Asus P2B-DS not detected as SMP moterboard
http://groups.google.com/group/linux.kernel/t/f306c860bbde469a?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 8:30 am
From: Dmitry Artamonow

On 20:40 Mon 11 Jan , Rafael J. Wysocki wrote:
> On Monday 11 January 2010, flinco@libero.it wrote:
> > Tried 2.6.32.3. The issue is still present.
>
> Thanks for the update.
>
> Rafael

(I have some troubles with registering on kernel bugzilla, so posting here,
adding people from bug to CC: list)

Hi!
I'm also using P2B-DS and can confirm that starting with kernel 2.6.32
SMP stopped working (and don't work still - tested with current git
v2.6.33-rc5-238-g158c168) The issue seems to have something to do with the
fact that ACPI is blacklisted on P2B-DS. I used to workaround this bug
on newer kernels (>=2.6.32) by passing "acpi=force" in kernel arguments.
Finally, yesterday I found some time to write simple automated bisection
script and leaved it to run on machine overnight. Here's result:
---------------------------------------------------------------------------
e5b8fc6ac158f65598f58dba2c0d52ba3b412f52 is the first bad commit
commit e5b8fc6ac158f65598f58dba2c0d52ba3b412f52
Author: Len Brown <len.brown@intel.com>
Date: Tue Jul 7 23:22:58 2009 -0400

ACPI: check acpi_disabled in acpi_table_parse() and acpi_table_parse_entries()

Allow consumers of the acpi_table_parse()/acpi_table_parse_entries() API
to gracefully handle the acpi_disabled=1 case via return value
rather than checking the global flag themselves.

Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
---------------------------------------------------------------------------

I re-checked this result and yes - reverting this commit on both 2.6.32 and
current git (v2.6.33-rc5-238-g158c168) makes problem go away.

--
Best regards,
Dmitry "MAD" Artamonow

==============================================================================
TOPIC: dma: Add barrierless dma mapping/unmapping api
http://groups.google.com/group/linux.kernel/t/3756402bfba9b5ed?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 9:00 am
From: Randy Dunlap

On Mon, 25 Jan 2010 18:35:46 -0800 adharmap@codeaurora.org wrote:

> From: Abhijeet Dharmapurikar <adharmap@quicinc.com>
>
> Tests have shown that there is a significant performance gain
> when a driver uses mapping/unmapping functions without a barrier
> multiple times and calls dsb() only after the last buffer. This
> api adds support for barrierless dma operations on ARMv6
> and ARMv7.
>
> Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
> ---
>
> Please refer to the earlier post here http://lkml.org/lkml/2010/1/4/347.
> These changes only are only for the arm v6 and v7
> architecture and introduce dma_map/unmap_single_nobarrier api.
> The idea is to extend the cpu_cache_fns.dma_.*_range functions to accept
> a third boolean argument that tells it whether to execute the barrier or
> skip it. Note that this applies over Linux 2.6.33-rc5 and needs a few changes
> to apply on the linux-next tree.
>
>
> arch/arm/include/asm/cacheflush.h | 12 ++++----
> arch/arm/include/asm/dma-mapping.h | 57 ++++++++++++++++++++++++++++++++++--
> arch/arm/mm/cache-v6.S | 15 ++++++----
> arch/arm/mm/cache-v7.S | 19 +++++++++++-
> arch/arm/mm/dma-mapping.c | 17 ++++++-----
> drivers/staging/dream/pmem.c | 4 +-
> 6 files changed, 97 insertions(+), 27 deletions(-)

Along with the other comments, the patch is also missing updates
to Documentation/DMA-API.txt ...

---
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: usbhid driver: replacing resume or using a post resume function
http://groups.google.com/group/linux.kernel/t/7e60ff7d909ff25e?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 9:00 am
From: "Rick L. Vinyard, Jr."

I was looking for an example of a hid driver that needs to customize
resume or provides a post resume function, but couldn't find one.

I would like to implement some post resume code. In particular, the g13 on
resume loses the backlight color, LCD image and LED state. On resume, it
needs feature reports sent to re-establish these settings.

However, I couldn't find a way to either provide a post resume function or
replace resume with a call to hid_resume() followed by the feature
reports.

Any suggestions?

---

Rick

==============================================================================
TOPIC: Status of 'toshiba-acpi: Add support for hotkey notifications' patch?
http://groups.google.com/group/linux.kernel/t/04841ac3760a48ee?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 9:00 am
From: Frans Pop

Hi Matthew,

What's the status of the patch below [1]? IIRC you were waiting for feedback
from a particular user?

The patch works fine for me on my Satellite A40 and I'd like to see
it included.

Cheers,
FJP

[1] Patch has been rebased for current mainline.

Author: Matthew Garrett <mjg59@srcf.ucam.org>
Subject: toshiba-acpi: Add support for hotkey notifications

Calling the ENAB method on Toshiba laptops results in notifications being
sent when laptop hotkeys are pressed. This patch simply calls that method
and sets up an input device if it's successful.

Signed-off-by: Matthew Garrett <mjg@redhat.com>

diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c
index 77bf5d8..13344b1 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -46,6 +46,8 @@
#include <linux/backlight.h>
#include <linux/platform_device.h>
#include <linux/rfkill.h>
+#include <linux/input-polldev.h>
+#include <linux/input.h>

#include <asm/uaccess.h>

@@ -62,9 +64,10 @@ MODULE_LICENSE("GPL");

/* Toshiba ACPI method paths */
#define METHOD_LCD_BRIGHTNESS "\\_SB_.PCI0.VGA_.LCD_._BCM"
-#define METHOD_HCI_1 "\\_SB_.VALD.GHCI"
-#define METHOD_HCI_2 "\\_SB_.VALZ.GHCI"
+#define TOSH_INTERFACE_1 "\\_SB_.VALD"
+#define TOSH_INTERFACE_2 "\\_SB_.VALZ"
#define METHOD_VIDEO_OUT "\\_SB_.VALX.DSSX"
+#define GHCI_METHOD ".GHCI"

/* Toshiba HCI interface definitions
*
@@ -116,6 +119,37 @@ static const struct acpi_device_id toshiba_device_ids[] = {
};
MODULE_DEVICE_TABLE(acpi, toshiba_device_ids);

+struct key_entry {
+ char type;
+ u16 code;
+ u16 keycode;
+};
+
+enum {KE_KEY, KE_END};
+
+static struct key_entry toshiba_acpi_keymap[] = {
+ {KE_KEY, 0x101, KEY_MUTE},
+ {KE_KEY, 0x13b, KEY_COFFEE},
+ {KE_KEY, 0x13c, KEY_BATTERY},
+ {KE_KEY, 0x13d, KEY_SLEEP},
+ {KE_KEY, 0x13e, KEY_SUSPEND},
+ {KE_KEY, 0x13f, KEY_SWITCHVIDEOMODE},
+ {KE_KEY, 0x140, KEY_BRIGHTNESSDOWN},
+ {KE_KEY, 0x141, KEY_BRIGHTNESSUP},
+ {KE_KEY, 0x142, KEY_WLAN},
+ {KE_KEY, 0x143, KEY_PROG1},
+ {KE_KEY, 0x17f, KEY_BRIGHTNESSDOWN},
+ {KE_KEY, 0xb05, KEY_PROG2},
+ {KE_KEY, 0xb06, KEY_WWW},
+ {KE_KEY, 0xb07, KEY_MAIL},
+ {KE_KEY, 0xb30, KEY_STOP},
+ {KE_KEY, 0xb31, KEY_PREVIOUSSONG},
+ {KE_KEY, 0xb32, KEY_NEXTSONG},
+ {KE_KEY, 0xb33, KEY_PLAYPAUSE},
+ {KE_KEY, 0xb5a, KEY_MEDIA},
+ {KE_END, 0, 0},
+};
+
/* utility
*/

@@ -251,6 +285,9 @@ static acpi_status hci_read2(u32 reg, u32 *out1, u32 *out2, u32
*result)
struct toshiba_acpi_dev {
struct platform_device *p_dev;
struct rfkill *bt_rfk;
+ struct input_polled_dev *poll_dev;
+ struct input_dev *hotkey_dev;
+ acpi_handle handle;

const char *bt_name;

@@ -711,6 +748,154 @@ static struct backlight_ops toshiba_backlight_data = {
.update_status = set_lcd_status,
};

+static struct key_entry *toshiba_acpi_get_entry_by_scancode(int code)
+{
+ struct key_entry *key;
+
+ for (key = toshiba_acpi_keymap; key->type != KE_END; key++)
+ if (code == key->code)
+ return key;
+
+ return NULL;
+}
+
+static struct key_entry *toshiba_acpi_get_entry_by_keycode(int code)
+{
+ struct key_entry *key;
+
+ for (key = toshiba_acpi_keymap; key->type != KE_END; key++)
+ if (code == key->keycode && key->type == KE_KEY)
+ return key;
+
+ return NULL;
+}
+
+static int toshiba_acpi_getkeycode(struct input_dev *dev, int scancode,
+ int *keycode)
+{
+ struct key_entry *key = toshiba_acpi_get_entry_by_scancode(scancode);
+
+ if (key && key->type == KE_KEY) {
+ *keycode = key->keycode;
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static int toshiba_acpi_setkeycode(struct input_dev *dev, int scancode,
+ int keycode)
+{
+ struct key_entry *key;
+ int old_keycode;
+
+ if (keycode < 0 || keycode > KEY_MAX)
+ return -EINVAL;
+
+ key = toshiba_acpi_get_entry_by_scancode(scancode);
+ if (key && key->type == KE_KEY) {
+ old_keycode = key->keycode;
+ key->keycode = keycode;
+ set_bit(keycode, dev->keybit);
+ if (!toshiba_acpi_get_entry_by_keycode(old_keycode))
+ clear_bit(old_keycode, dev->keybit);
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static void toshiba_acpi_notify(acpi_handle handle, u32 event, void **data)
+{
+ u32 hci_result, value;
+ struct key_entry *key;
+
+ if (event != 0x80)
+ return;
+ do {
+ hci_read1(HCI_SYSTEM_EVENT, &value, &hci_result);
+ if (hci_result == HCI_SUCCESS) {
+ if (value == 0x100)
+ continue;
+ else if (!(value & 0x80)) {
+ key = toshiba_acpi_get_entry_by_scancode
+ (value);
+ if (!key) {
+ printk(MY_INFO "Unknown key %x\n",
+ value);
+ continue;
+ }
+ input_report_key(toshiba_acpi.hotkey_dev,
+ key->keycode, 1);
+ input_sync(toshiba_acpi.hotkey_dev);
+ input_report_key(toshiba_acpi.hotkey_dev,
+ key->keycode, 0);
+ input_sync(toshiba_acpi.hotkey_dev);
+ }
+ } else if (hci_result == HCI_NOT_SUPPORTED) {
+ /* This is a workaround for an unresolved issue on
+ * some machines where system events sporadically
+ * become disabled. */
+ hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result);
+ printk(MY_NOTICE "Re-enabled hotkeys\n");
+ }
+ } while (hci_result != HCI_EMPTY);
+}
+
+static int toshiba_acpi_setup_keyboard(char *device)
+{
+ acpi_status status;
+ acpi_handle handle;
+ int result;
+ const struct key_entry *key;
+
+ status = acpi_get_handle(NULL, device, &handle);
+ if (ACPI_FAILURE(status)) {
+ printk(MY_INFO "Unable to get notification device\n");
+ return -ENODEV;
+ }
+
+ toshiba_acpi.handle = handle;
+
+ status = acpi_evaluate_object(handle, "ENAB", NULL, NULL);
+ if (ACPI_FAILURE(status)) {
+ printk(MY_INFO "Unable to enable hotkeys\n");
+ return -ENODEV;
+ }
+
+ status = acpi_install_notify_handler (handle, ACPI_DEVICE_NOTIFY,
+ toshiba_acpi_notify, NULL);
+ if (ACPI_FAILURE(status)) {
+ printk(MY_INFO "Unable to install hotkey notification\n");
+ return -ENODEV;
+ }
+
+ toshiba_acpi.hotkey_dev = input_allocate_device();
+ if (!toshiba_acpi.hotkey_dev) {
+ printk(MY_INFO "Unable to register input device\n");
+ return -ENOMEM;
+ }
+
+ toshiba_acpi.hotkey_dev->name = "Toshiba input device";
+ toshiba_acpi.hotkey_dev->phys = device;
+ toshiba_acpi.hotkey_dev->id.bustype = BUS_HOST;
+ toshiba_acpi.hotkey_dev->getkeycode = toshiba_acpi_getkeycode;
+ toshiba_acpi.hotkey_dev->setkeycode = toshiba_acpi_setkeycode;
+
+ for (key = toshiba_acpi_keymap; key->type != KE_END; key++) {
+ set_bit(EV_KEY, toshiba_acpi.hotkey_dev->evbit);
+ set_bit(key->keycode, toshiba_acpi.hotkey_dev->keybit);
+ }
+
+ result = input_register_device(toshiba_acpi.hotkey_dev);
+ if (result) {
+ printk(MY_INFO "Unable to register input device\n");
+ return result;
+ }
+
+ return 0;
+}
+
static void toshiba_acpi_exit(void)
{
if (toshiba_acpi.bt_rfk) {
@@ -718,9 +903,15 @@ static void toshiba_acpi_exit(void)
rfkill_destroy(toshiba_acpi.bt_rfk);
}

+ if (toshiba_acpi.hotkey_dev)
+ input_unregister_device(toshiba_acpi.hotkey_dev);
+
if (toshiba_backlight_device)
backlight_device_unregister(toshiba_backlight_device);

+ acpi_remove_notify_handler(toshiba_acpi.handle, ACPI_DEVICE_NOTIFY,
+ toshiba_acpi_notify);
+
remove_device();

if (toshiba_proc_dir)
@@ -742,11 +933,15 @@ static int __init toshiba_acpi_init(void)
return -ENODEV;

/* simple device detection: look for HCI method */
- if (is_valid_acpi_path(METHOD_HCI_1))
- method_hci = METHOD_HCI_1;
- else if (is_valid_acpi_path(METHOD_HCI_2))
- method_hci = METHOD_HCI_2;
- else
+ if (is_valid_acpi_path(TOSH_INTERFACE_1 GHCI_METHOD)) {
+ method_hci = TOSH_INTERFACE_1 GHCI_METHOD;
+ if (toshiba_acpi_setup_keyboard(TOSH_INTERFACE_1))
+ printk(MY_INFO "Unable to activate hotkeys\n");
+ } else if (is_valid_acpi_path(TOSH_INTERFACE_2 GHCI_METHOD)) {
+ method_hci = TOSH_INTERFACE_2 GHCI_METHOD;
+ if (toshiba_acpi_setup_keyboard(TOSH_INTERFACE_2))
+ printk(MY_INFO "Unable to activate hotkeys\n");
+ } else
return -ENODEV;

printk(MY_INFO "Toshiba Laptop ACPI Extras version %s\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================

You received this message because you are subscribed to the Google Groups "linux.kernel"
group.

To post to this group, visit http://groups.google.com/group/linux.kernel?hl=en

To unsubscribe from this group, send email to linux.kernel+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/linux.kernel/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Tuesday, January 26, 2010

linux.kernel - 25 new messages in 16 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts