* Re: [PATCH] KVM: MMU: initialize sptes early
From: Xiao Guangrong @ 2011-10-24 7:41 UTC (permalink / raw)
To: Zhao Jin; +Cc: avi, mtosatti, linux-kernel, kvm
In-Reply-To: <1319440880-2610-1-git-send-email-cronozhj@gmail.com>
On 2011/10/24 15:21, Zhao Jin wrote:
> Otherwise, the following kvm_sync_pages() will see invalid sptes in a new
> shadow page.
>
No, kvm_sync_pages just handle the unsync page, but the new sp is the sync page.
^ permalink raw reply
* [U-Boot] error
From: mailrepl at apnic.net @ 2011-10-24 7:45 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111024074540.31BF1B66C9@tofu.apnic.net>
--
###################################
## This is an automated response ##
###################################
## Replies sent to the sender of ##
## this response will *NOT* be ##
## read by humans or stored. ##
###################################
The APNIC whois database currently uses the RIPE-181 format when returning
database objects.
This format defines the 'notify:' as being:
notify
The e-mail address to which notifications of changes to
an object should be sent.
( source, $ whois -h whois.apnic.net -- -v inetnum )
That is, the address in the 'notify' attribute will be sent an email by
the database software when the object changes.
In general, the address in the 'notify' field is not the address to send
reports of network abuse to. Instead, please read the output of the
APNIC whois query and contact the address listed in the 'e-mail:' attribute
of the accompanying person object.
The address 'dbmon at apnic.net' is used internally by APNIC to track changes
to certain database object. Please do not send network abuse reports to
this address.
If there are no other contact email addresses, APNIC's database
administration section should be able to help. Their address is listed in
the below URL.
Contacting APNIC Pty Ltd:
Please refer to http://www.apnic.net/emails.html for the appropriate
area to direct your query to.
We hope the information above is beneficial.
APNIC Staff
-------------------------------------------------------------------------
- $Id: dbmon,v 1.1 2003/03/13 09:03:54 root Exp $
-------------------------------------------------------------------------
^ permalink raw reply
* [U-Boot] Failed to apply patch
From: Stefan Roese @ 2011-10-24 7:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <D93043FBAB424B3D9A6FC409F8C700CA@mistral.in>
On Monday 24 October 2011 09:33:55 Sadashiva wrote:
> I downloaded the latest version of u-boot source code of version
> number u-boot-2011.03.tar.bz2.
>
> from ftp://ftp.denx.de/pub/u-boot/ website and the MPL patches for
> this from the website
>
> http://www.mpl.ch/t2722.html
> Latest MPL supported version. Patches are available here: MPL
> patches
>
> But when I apply the patch example
> test at test-laptop:~/toolchain_2011/u-boot-2011.03$patch -p1 <
> u-boot-2011.03.mpl-patches
>
> I am getting failed message like.
>
> patching file MAINTAINERS
> Hunk #1 FAILED at 342.
Please contact MPL about this. I don't know these out-of-tree patches.
Best would be if MPL (or someone else) would correctly support these boards in
mainline again.
Best regards,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
^ permalink raw reply
* Re: [PATCH] KVM: MMU: fix the condition of syncing a new shadow page
From: Xiao Guangrong @ 2011-10-24 7:46 UTC (permalink / raw)
To: Zhao Jin; +Cc: avi, mtosatti, linux-kernel, kvm
In-Reply-To: <1319440880-2610-2-git-send-email-cronozhj@gmail.com>
On 2011/10/24 15:21, Zhao Jin wrote:
> Should be "or" since a new shadow page is synced if either it is
> not leaf or there already exists another unsync shadow page with
> the same gfn.
>
It is obviously wrong, we need to sync pages only if it has unsync page
*and* the new shadow page breaks the unsync rule(only the level 1 sp can
became unsync).
^ permalink raw reply
* No linkage from /sys entries for a given scsi_host to its PCI device details?
From: Sampathkumar, Kishore @ 2011-10-24 7:48 UTC (permalink / raw)
To: linux-scsi@vger.kernel.org
In-Reply-To: <S932680Ab1INNeE/20110914133404Z+1759@vger.kernel.org>
[root@host26 /]# ls -l /dev/disk/by-id/wwn-0x5000c5000f8f4583
lrwxrwxrwx. 1 root root 9 Oct 19 11:14 wwn-0x5000c5000f8f4583 -> ../../sdg
[root@host26 /]# ls /sys/block/sdg/device/scsi_disk
3:0:5:0
^
|
The above is the host{number} for the SCSI Host controller (in the above case "host3").
[root@host26 /]# ls /sys/class/scsi_host/host3
active_mode device io_delay scan unchecked_isa_dma version_nvdata_persistent
board_assembly device_delay logging_level sg_tablesize unique_id version_product
board_name fw_queue_depth power state version_bios
board_tracer fwfault_debug proc_name subsystem version_fw
can_queue host_busy prot_capabilities supported_mode version_mpi
cmd_per_lun host_sas_address prot_guard_type uevent version_nvdata_default
>From the above, there is no linkage to the PCI device corresponding to the above host controller. The only way I could establish the linkage was to actually start from the PCI device ID for this controller, and then, doing the following:
[root@host26 /]# ls /sys/class/pci_bus/0000:0c/device/0000:0c:00.0
broken_parity_status host3 numa_node resource subsystem_device
class irq pools resource0 subsystem_vendor
config local_cpulist power resource1 uevent
device local_cpus remove resource3 vendor
driver modalias rescan rom vpd
enable msi_bus reset subsystem
I think it is very useful to have the necessary linkage to get to the PCI device from the /sys/class/scsi_host/host3 entries.
Thanks,
- Kishore
^ permalink raw reply
* [PATCH] drivers: create a pin control subsystem v8
From: Linus Walleij @ 2011-10-24 7:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111024073604.GA8708@ponder.secretlab.ca>
On Mon, Oct 24, 2011 at 9:36 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, Oct 24, 2011 at 09:26:38AM +0200, Linus Walleij wrote:
(...)
>> I was more thinking along the lines of one device per GPIO controller,
>> then you ioctl() to ask /dev/gpio0 how many pins it has or so.
>
> And there is also the question of whether it is even a good idea to
> export pinctrl manipulation to userspace.
The application I've seen is in automatic control.
I think people do things like connect they GPIO pins to electrical
relays, plus on top of that they use all the stuff in drivers/staging/iio.
All that from userspace. Controlling entire factories and industrial
robots, weapon systems too, I'm afraid.
The control of these dangerous things runs on a realtime-patched
kernel, in a single userspace app with a few threads and they have
done some realtime-tetris scheduling the beast more or less
manually with SCHED_FIFO. Basically that app is all that runs on
the board, and its threads take precedence over everything else
on the system.
That is the typical beast that is poking around on the GPIO sysfs
interfaces...
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] drivers: create a pin control subsystem v8
From: Linus Walleij @ 2011-10-24 7:48 UTC (permalink / raw)
To: Grant Likely
Cc: Mike Frysinger, Linus Walleij, Stephen Warren, Sascha Hauer,
Barry Song, linux-kernel, Joe Perches, Russell King, Linaro Dev,
Lee Jones, David Brown, linux-arm-kernel, Stijn Devriendt
In-Reply-To: <20111024073604.GA8708@ponder.secretlab.ca>
On Mon, Oct 24, 2011 at 9:36 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Mon, Oct 24, 2011 at 09:26:38AM +0200, Linus Walleij wrote:
(...)
>> I was more thinking along the lines of one device per GPIO controller,
>> then you ioctl() to ask /dev/gpio0 how many pins it has or so.
>
> And there is also the question of whether it is even a good idea to
> export pinctrl manipulation to userspace.
The application I've seen is in automatic control.
I think people do things like connect they GPIO pins to electrical
relays, plus on top of that they use all the stuff in drivers/staging/iio.
All that from userspace. Controlling entire factories and industrial
robots, weapon systems too, I'm afraid.
The control of these dangerous things runs on a realtime-patched
kernel, in a single userspace app with a few threads and they have
done some realtime-tetris scheduling the beast more or less
manually with SCHED_FIFO. Basically that app is all that runs on
the board, and its threads take precedence over everything else
on the system.
That is the typical beast that is poking around on the GPIO sysfs
interfaces...
Yours,
Linus Walleij
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Martin Schwidefsky @ 2011-10-24 7:48 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Simon Kirby, Peter Zijlstra,
Linux Kernel Mailing List, Dave Jones, Thomas Gleixner
In-Reply-To: <20111023113422.GD5156@elte.hu>
On Sun, 23 Oct 2011 13:34:22 +0200
Ingo Molnar <mingo@elte.hu> wrote:
>
> * Martin Schwidefsky <schwidefsky@de.ibm.com> wrote:
>
> > +#define cputime_zero ((__force cputime_t) 0ULL)
> > +#define cputime64_zero ((__force cputime64_t) 0ULL)
>
> Hm, why are these still needed?
>
> This:
>
> if (*newval == cputime_zero)
> return;
>
> Could be written as the much simpler:
>
> if (!*newval)
> return;
>
> with no ill effect that i can see.
These types are still there because cputime_t can be u32 or u64. E.g. this
timer->expires.cpu = 0;
will give the following sparse warning
kernel/posix-cpu-timers.c:463:46: warning: implicit cast to nocast type
if you architecture happens to have a u64 as cputime_t.
We could get rid of cputime64_t as it always should be a u64. To keep
things symmetrical I choose to keep both defines.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply
* [U-Boot] [Resend PATCH V2] misc: pmic: fix regression in pmic_fsl.c (SPI)
From: Stefano Babic @ 2011-10-24 7:48 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319092483-8201-1-git-send-email-helmut.raiger@hale.at>
On 10/20/2011 08:34 AM, Helmut Raiger wrote:
> This fixes write access to PMIC registers, the bug was
> introduced partly in commit 64aac65099 and in commit c9fe76dd91.
> It was tested on an i.mx31 with a mc13783.
>
> Signed-off-by: Helmut Raiger <helmut.raiger@hale.at>
> ---
> V2: threw in the wrong read back line (again and again)
Applied to u-boot-imx, thanks.
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: DeviceTree and children devices
From: Felipe Balbi @ 2011-10-24 7:49 UTC (permalink / raw)
To: Grant Likely
Cc: Felipe Balbi, Linux Kernel Mailing List, Linux USB Mailing List
In-Reply-To: <20111024074124.GB8708@ponder.secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 3152 bytes --]
On Mon, Oct 24, 2011 at 09:41:24AM +0200, Grant Likely wrote:
> On Mon, Oct 24, 2011 at 09:42:28AM +0300, Felipe Balbi wrote:
> > Hi Grant,
> >
> > I have a question about how DeviceTree should be written in case a
> > device has a child device.
> >
> > The way things are integrated on OMAP is that we will always have a
> > parent device which is a wrapper around an IP core in order to
> > integrate with the OMAP context (clocks, power management, etc).
> >
> > That wrapper has its own address space and its own IRQ number
> > (generally). On my dwc3 driver I have modeled the OMAP wrapper as a
> > parent device which allocates a child device for the core IP driver.
> > This makes it a lot easier to re-use the core IP driver on other SoCs or
> > PCI (there's a glue layer for PCI too).
> >
> > So I wonder if we should describe that on DeviceTree and not have the
> > OMAP glue layer allocate the core IP driver. Just to illustrate, here's
> > what we have:
> >
> > static int dwc3_omap_probe(struct platform_device *pdev)
> > {
> > struct platform_device *dwc3;
> > struct resource res[2];
> >
> > dwc3 = platform_device_alloc("dwc3", -1);
> > /* check*/
> >
> > dwc3->dev.parent = &pdev->dev;
> >
> > /* copy DMA fields from parent too */
> >
> > res[0].start = start_address;
> > res[0].end = end_address;
> > res[0].flags = IORESOURCE_MEM;
> >
> > res[1].start = irq_number;
> > res[1].flags = IORESOURCE_IRQ;
> >
> > ret = platform_add_resources(dwc3, res, ARRAY_SIZE(res));
> > /* check */
> >
> > return platform_add_device(dwc3);
> > }
> >
> > and I wonder if I should have a DeviceTree like so:
> >
> > usb@xxxxx {
> > compatible = "ti,dwc3-omap"; // This is TI OMAP
> > // wrapper
> > range = <....>;
> >
> > ...
> >
> > usb@yyyy {
> > compatible = "synopsys,dwc3", // This is core IP
> > // inside wrapper
> >
> > ...
> > };
> > };
> >
> > then I can drop the dwc3 platform_device allocation and all of that
> > resource copying, etc.
> >
> > What do you think ?
>
> Looks reasonable to me. of_platform_populate() should be able to
> handle the device generation for you here.
Ok cool I looking into that and it handles everything I need. There are
only three issues which I see:
a) it hardcoded DMA mask to 32-bit. Right ?
b) it's not using dma_set_coherent_mask()
c) in case parent is a valid pointer, shouldn't it copy DMA mask from
parent ?
I mean (doesn't solve (a) above):
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index ed5a6d3..172d4a9 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -204,7 +204,12 @@ struct platform_device *of_platform_device_create_pdata(
#if defined(CONFIG_MICROBLAZE)
dev->archdata.dma_mask = 0xffffffffUL;
#endif
- dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
+
+ if (parent)
+ dma_set_coherent_mask(&dev->dev, parent->coherent_dma_mask);
+ else
+ dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
+
dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* RE: No linkage from /sys entries for a given scsi_host to its PCI device details?
From: Sampathkumar, Kishore @ 2011-10-24 7:50 UTC (permalink / raw)
To: linux-scsi@vger.kernel.org
In-Reply-To: <E4D7778E36CF944ABD2F7E18D2DB9666271B897A1A@inbmail02.lsi.com>
Same text as before; but properly formatted.
[root@host26 /]# ls -l /dev/disk/by-id/wwn-0x5000c5000f8f4583
lrwxrwxrwx. 1 root root 9 Oct 19 11:14 wwn-0x5000c5000f8f4583 -> ../../sdg
[root@host26 /]# ls /sys/block/sdg/device/scsi_disk
3:0:5:0
The above is the host{number} for the SCSI Host controller (in the above case "host3").
[root@host26 /]# ls /sys/class/scsi_host/host3
active_mode device io_delay scan unchecked_isa_dma version_nvdata_persistent
board_assembly device_delay logging_level sg_tablesize unique_id version_product
board_name fw_queue_depth power state version_bios
board_tracer fwfault_debug proc_name subsystem version_fw
can_queue host_busy prot_capabilities supported_mode version_mpi
cmd_per_lun host_sas_address prot_guard_type uevent version_nvdata_default
>From the above, there is no linkage to the PCI device corresponding to the above host controller. The only way I could establish the linkage was to actually start from the PCI device ID for this controller, and then, doing the following:
[root@host26 /]# ls /sys/class/pci_bus/0000:0c/device/0000:0c:00.0
broken_parity_status host3 numa_node resource subsystem_device
class irq pools resource0 subsystem_vendor
config local_cpulist power resource1 uevent
device local_cpus remove resource3 vendor
driver modalias rescan rom vpd
enable msi_bus reset subsystem
I think it is very useful to have the necessary linkage to get to the PCI device from the /sys/class/scsi_host/host3 entries.
Thanks,
- Kishore
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/4] Add parsing of L2CAP Fixed Channel list
From: Andrei Emeltchenko @ 2011-10-24 7:51 UTC (permalink / raw)
To: Peter Krystad; +Cc: linux-bluetooth
In-Reply-To: <1319239802-22457-4-git-send-email-pkrystad@codeaurora.org>
Hi Peter,
On Fri, Oct 21, 2011 at 04:30:01PM -0700, Peter Krystad wrote:
> Add DUMP_VERBOSE display of L2CAP Fixed Channel list.
> Example output:
>
> 2011-10-21 12:01:50.423246 > ACL data: handle 39 flags 0x02 dlen 20
> L2CAP(s): Info rsp: type 3 result 0
> Fixed channel list
> L2CAP
> CONNLESS
> A2MP
We can be more specific here since each channel is printed on new line
> ---
> parser/l2cap.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/parser/l2cap.c b/parser/l2cap.c
> index 7915788..ce78d05 100644
> --- a/parser/l2cap.c
> +++ b/parser/l2cap.c
> @@ -811,6 +811,7 @@ static void info_opt(int level, int type, void *ptr, int len)
> {
> uint32_t mask;
> int i;
> + uint8_t list;
>
> p_indent(level, 0);
>
> @@ -830,6 +831,21 @@ static void info_opt(int level, int type, void *ptr, int len)
> break;
> case 0x0003:
> printf("Fixed channel list\n");
> + list = get_val(ptr, 1);
We had discussion about this with Mat Martineau and agreed that we read 8
octets (there is one bit in 8th octet - AMP test manager)
> + if (parser.flags & DUMP_VERBOSE) {
> + if (list & L2CAP_FC_L2CAP) {
> + p_indent(level + 1, 0);
> + printf("L2CAP\n");
> + }
> + if (list & L2CAP_FC_CONNLESS) {
> + p_indent(level + 1, 0);
> + printf("CONNLESS\n");
> + }
> + if (list & L2CAP_FC_A2MP) {
> + p_indent(level + 1, 0);
> + printf("A2MP\n");
> + }
> + }
I know that this is common in hcidump but I do not like current approach.
I have sent similar patch and the difference (beyond mentioned above) is
that I define decode table:
+static struct features l2cap_fix_chan[] = {
+ { "L2CAP Signalling Channel", L2CAP_FC_L2CAP },
+ { "L2CAP Connless", L2CAP_FC_CONNLESS },
+ { "AMP Manager Protocol", L2CAP_FC_A2MP },
+ { 0 }
+};
then:
+ if (parser.flags & DUMP_VERBOSE)
+ for (i=0; l2cap_fix_chan[i].name; i++)
+ if (fc_mask & l2cap_fix_chan[i].flag) {
+ p_indent(level + 1, 0);
+ printf("%s\n", l2cap_fix_chan[i].name);
+ }
http://www.spinics.net/lists/linux-bluetooth/msg17247.html
This is the way how it is done is wireshark network packet analyzer.
Then if you want to add one extra feature (like AMP test manager) => you
just add new table entry. Otherwise you have to create new "if" branch.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: Linux 3.1-rc9
From: Linus Torvalds @ 2011-10-24 7:51 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: Ingo Molnar, Simon Kirby, Peter Zijlstra,
Linux Kernel Mailing List, Dave Jones, Thomas Gleixner
In-Reply-To: <20111024094817.30c01c9b@de.ibm.com>
On Mon, Oct 24, 2011 at 9:48 AM, Martin Schwidefsky
<schwidefsky@de.ibm.com> wrote:
>
> These types are still there because cputime_t can be u32 or u64. E.g. this
>
> timer->expires.cpu = 0;
>
> will give the following sparse warning
>
> kernel/posix-cpu-timers.c:463:46: warning: implicit cast to nocast type
Ok, we should probably special-case zero for that case too (we
consider zero to be very special - it's not only the NULL pointer, but
0 is special for the bitwise types etc). So this is very arguably a
sparse issue: casting zero is special.
Linus
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
From: Paolo Bonzini @ 2011-10-24 7:53 UTC (permalink / raw)
To: Kevin Wolf; +Cc: Alexander Graf, qemu-devel, avi
In-Reply-To: <4EA515B9.8070204@redhat.com>
On 10/24/2011 09:37 AM, Kevin Wolf wrote:
>> Why? cache=unsafe is explicitly allowing to s/data/manure/ on
>> crash.
>
> It's surely expected on a host crash, but is it for a qemu crash?
> cache=unsafe was introduced to avoid fsync() costs, which it still
> does after this patch.
I think it's not about "why is it there", but rather about "what is it
useful for". My interpretation of it is "I do not need the image
anymore unless the command exits cleanly": VM installations, qemu-img
conversions, BDRV_O_SNAPSHOT (doesn't do it yet, but it could). Even
SIGINT and SIGTERM would be excluded from this definition, but they cost
nothing so it's nice to include them.
>> If you do this for raw-posix, you need to do it for all protocols.
>
> rbd could use it, too, right. Any other protocol I missed?
NBD could, but it doesn't support flush yet.
In general, even if it were useful to implement this, I'm not sure this
is the best way to implement it. For example you could simply clear
BDRV_O_NO_FLUSH in qcow2_open.
Paolo
^ permalink raw reply
* Re: [Xenomai-help] installing xenomai on pandaboard
From: Robert @ 2011-10-24 7:53 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
In-Reply-To: <4E78D7C0.2090108@domain.hid>
Dnia 20 września 2011 20:13 Gilles Chanteperdrix <gilles.chanteperdrix@domain.hid> napisał(a):
> On 09/20/2011 07:26 PM, Robert wrote:
> > Can someone help me installing xenomai on panda?
> >
> > What should I do, to install xenomai on ubuntu host?
> > Download kernel from kernel.org and patch it with xenomai and adeos-patch, or download kernel from git repository, or download ubuntu image-omap4 via apt-get source?
> >
> > The last one would download 2.6.38 kernel, but there is no adeos patch for this version yet.
> > It is also possible to download 2.6.37-9, but the same problem.
>
> The upcoming xenomai 2.6.0 supports panda. It should be released real
> soon now, in the mean-time, you can try xenomai 2.6.0-rc3.
>
>
Hi again,
I have downloaded xenomai 2.6.0-rc5, and kernel 2.6.38.8 from kernel.org to ubuntu 11.04 on pandaboard.
Patched it with adeos included in xeno package.
Compiled the kernel, modules and copied uImage to boot partition.
After reboot i got the following dmesg | grep -i xeno:
user@domain.hid
[ 1.195556] I-pipe: Domain Xenomai registered.
[ 1.195587] Xenomai: hal/arm started.
[ 1.195861] Xenomai: scheduling class idle registered.
[ 1.195861] Xenomai: scheduling class rt registered.
[ 1.199798] Xenomai: real-time nucleus v2.6.0-rc5 (head) loaded.
[ 1.199798] Xenomai: debug mode enabled.
[ 1.590240] Xenomai: native skin init failed, code -19.
[ 1.590270] Xenomai: starting POSIX services.
[ 1.980804] Xenomai: POSIX skin init failed, code -19.
[ 2.371429] Xenomai: RTDM skin init failed, code -19.
user@domain.hid
user@domain.hid
user@domain.hid
user@domain.hid
/usr/xenomai/bin/xeno-test-run-wrapper: 19: source: not found
./xeno-test failed: dead child 1238 not found!
user@domain.hid
Xenomai: incompatible feature set
(userland requires "kuser_tsc fastsynch nosmp", kernel provides "sa1100 v6 eabi
kuser_tsc fastsynch smp", missing="nosmp").
Should I disable smp in kernel config?
^ permalink raw reply
* [U-Boot] [PATCH 3/3] qong: remove unneeded IOMUX settings
From: Stefano Babic @ 2011-10-24 7:56 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319162491-2293-3-git-send-email-festevam@gmail.com>
On 10/21/2011 04:01 AM, Fabio Estevam wrote:
> On qong board some of the USBH2 pins are set via GPR register, so don need to setup
> the IOMUX for each pin individually.
>
> Other than that, these pins should not be configured as primary function because the primary
> function selects SSI functionality.
>
> Let GPR register do the work and remove the unneeded IOMUX setup.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
>
Hi Fabio,
> Stefano,
>
> I don't have access to the qong board to test this, but I believe this is the right thing to do here.
I have not written this code and I do not know the history, but reading
the manual I agree with you. The setup of the iomux is ininfluent,
because the pins are already set in "Hardware mode 2" in the GPR
register (GPR[11]).
>
> board/davedenx/qong/qong.c | 6 ------
> 1 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/board/davedenx/qong/qong.c b/board/davedenx/qong/qong.c
> index de32fb5..70af593 100644
> --- a/board/davedenx/qong/qong.c
> +++ b/board/davedenx/qong/qong.c
> @@ -120,12 +120,6 @@ int board_early_init_f(void)
> mx31_gpio_mux(IOMUX_MODE(MUX_CTL_USBH2_STP, MUX_CTL_FUNC));
> mx31_gpio_mux(IOMUX_MODE(MUX_CTL_USBH2_DATA0, MUX_CTL_FUNC));
> mx31_gpio_mux(IOMUX_MODE(MUX_CTL_USBH2_DATA1, MUX_CTL_FUNC));
> - mx31_gpio_mux(IOMUX_MODE(MUX_CTL_STXD3, MUX_CTL_FUNC));
> - mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SRXD3, MUX_CTL_FUNC));
> - mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SCK3, MUX_CTL_FUNC));
> - mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SFS3, MUX_CTL_FUNC));
> - mx31_gpio_mux(IOMUX_MODE(MUX_CTL_STXD6, MUX_CTL_FUNC));
> - mx31_gpio_mux(IOMUX_MODE(MUX_CTL_SRXD6, MUX_CTL_FUNC));
>
> #define H2_PAD_CFG (PAD_CTL_DRV_MAX | PAD_CTL_SRE_FAST | PAD_CTL_HYS_CMOS | \
> PAD_CTL_ODE_CMOS | PAD_CTL_100K_PU)
Acked-by: Stefano Babic <sbabic@denx.de>
Best regards,
Stefano Babic
--
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================
^ permalink raw reply
* Re: DeviceTree and children devices
From: Grant Likely @ 2011-10-24 7:58 UTC (permalink / raw)
To: balbi; +Cc: Linux Kernel Mailing List, Linux USB Mailing List
In-Reply-To: <20111024074957.GB15288@legolas.emea.dhcp.ti.com>
On Mon, Oct 24, 2011 at 9:49 AM, Felipe Balbi <balbi@ti.com> wrote:
> On Mon, Oct 24, 2011 at 09:41:24AM +0200, Grant Likely wrote:
>> On Mon, Oct 24, 2011 at 09:42:28AM +0300, Felipe Balbi wrote:
>> > then I can drop the dwc3 platform_device allocation and all of that
>> > resource copying, etc.
>> >
>> > What do you think ?
>>
>> Looks reasonable to me. of_platform_populate() should be able to
>> handle the device generation for you here.
>
> Ok cool I looking into that and it handles everything I need. There are
> only three issues which I see:
>
> a) it hardcoded DMA mask to 32-bit. Right ?
> b) it's not using dma_set_coherent_mask()
> c) in case parent is a valid pointer, shouldn't it copy DMA mask from
> parent ?
>
> I mean (doesn't solve (a) above):
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index ed5a6d3..172d4a9 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -204,7 +204,12 @@ struct platform_device *of_platform_device_create_pdata(
> #if defined(CONFIG_MICROBLAZE)
> dev->archdata.dma_mask = 0xffffffffUL;
> #endif
> - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> +
> + if (parent)
> + dma_set_coherent_mask(&dev->dev, parent->coherent_dma_mask);
> + else
> + dma_set_coherent_mask(&dev->dev, DMA_BIT_MASK(32));
> +
Right, this does need to be fixed. The existing code just matched
what the historical powerpc code did, but it is certainly not correct.
g.
^ permalink raw reply
* nouveau KMS fails with Vanta TNT2-M64
From: Meelis Roos @ 2011-10-24 7:32 UTC (permalink / raw)
To: Linux Kernel list, Ben Skeggs; +Cc: Francisco Jerez, Dave Airlie
Hello,
got an old Nvidia card, Vanta/TNT2-M64. Without KMS, text console and X
work fine. With modeset=1, KMS logs a lot of errors and X screen is
garbled (mostly understabdable but vertical bands of compressed double
image and some horizontal distortions - sorry, no camera here with me
today). Some other nvidia and radeon cards work fine in this computer.
Kernel is 3.1-rc10-dirty (the only patch to rc10 is about ps/2 mouse
recognition and should be irrelevant).
When trying to use KMS, I get the following dmesg:
Oct 24 10:15:36 rhn kernel: [ 0.000000] Initializing cgroup subsys cpu
Oct 24 10:15:36 rhn kernel: [ 0.000000] Linux version 3.1.0-rc10-dirty (mroos@rhn) (gcc version 4.6.1 (Debian 4.6.1-15) ) #4 PREEMPT Tue Oct 18 14:44:44 EEST 2011
Oct 24 10:15:36 rhn kernel: [ 0.000000] BIOS-provided physical RAM map:
Oct 24 10:15:36 rhn kernel: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
Oct 24 10:15:36 rhn kernel: [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
Oct 24 10:15:36 rhn kernel: [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
Oct 24 10:15:36 rhn kernel: [ 0.000000] BIOS-e820: 0000000000100000 - 000000001ffc0000 (usable)
Oct 24 10:15:36 rhn kernel: [ 0.000000] BIOS-e820: 000000001ffc0000 - 000000001fff8000 (ACPI data)
Oct 24 10:15:36 rhn kernel: [ 0.000000] BIOS-e820: 000000001fff8000 - 0000000020000000 (ACPI NVS)
Oct 24 10:15:36 rhn kernel: [ 0.000000] BIOS-e820: 00000000ffb80000 - 00000000ffc00000 (reserved)
Oct 24 10:15:36 rhn kernel: [ 0.000000] BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
Oct 24 10:15:36 rhn kernel: [ 0.000000] Notice: NX (Execute Disable) protection missing in CPU!
Oct 24 10:15:36 rhn kernel: [ 0.000000] DMI 2.3 present.
Oct 24 10:15:36 rhn kernel: [ 0.000000] DMI: /D815EEA2 , BIOS EA81520A.86A.0039.P21.0211061753 11/06/2002
Oct 24 10:15:36 rhn kernel: [ 0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
Oct 24 10:15:36 rhn kernel: [ 0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
Oct 24 10:15:36 rhn kernel: [ 0.000000] last_pfn = 0x1ffc0 max_arch_pfn = 0x100000
Oct 24 10:15:36 rhn kernel: [ 0.000000] MTRR default type: uncachable
Oct 24 10:15:36 rhn kernel: [ 0.000000] MTRR fixed ranges enabled:
Oct 24 10:15:36 rhn kernel: [ 0.000000] 00000-9FFFF write-back
Oct 24 10:15:36 rhn kernel: [ 0.000000] A0000-BFFFF uncachable
Oct 24 10:15:36 rhn kernel: [ 0.000000] C0000-CFFFF write-protect
Oct 24 10:15:36 rhn kernel: [ 0.000000] D0000-DFFFF uncachable
Oct 24 10:15:36 rhn kernel: [ 0.000000] E0000-FFFFF write-protect
Oct 24 10:15:36 rhn kernel: [ 0.000000] MTRR variable ranges enabled:
Oct 24 10:15:36 rhn kernel: [ 0.000000] 0 base 000000000 mask FE0000000 write-back
Oct 24 10:15:36 rhn kernel: [ 0.000000] 1 base 020000000 mask FFFF00000 write-back
Oct 24 10:15:36 rhn kernel: [ 0.000000] 2 base 020000000 mask FFFF00000 uncachable
Oct 24 10:15:36 rhn kernel: [ 0.000000] 3 disabled
Oct 24 10:15:36 rhn kernel: [ 0.000000] 4 disabled
Oct 24 10:15:36 rhn kernel: [ 0.000000] 5 disabled
Oct 24 10:15:36 rhn kernel: [ 0.000000] 6 disabled
Oct 24 10:15:36 rhn kernel: [ 0.000000] 7 disabled
Oct 24 10:15:36 rhn kernel: [ 0.000000] PAT not supported by CPU.
Oct 24 10:15:36 rhn kernel: [ 0.000000] original variable MTRRs
Oct 24 10:15:36 rhn kernel: [ 0.000000] reg 0, base: 0GB, range: 512MB, type WB
Oct 24 10:15:36 rhn kernel: [ 0.000000] reg 1, base: 512MB, range: 1MB, type WB
Oct 24 10:15:36 rhn kernel: [ 0.000000] reg 2, base: 512MB, range: 1MB, type UC
Oct 24 10:15:36 rhn kernel: [ 0.000000] total RAM covered: 512M
Oct 24 10:15:36 rhn kernel: [ 0.000000] Found optimal setting for mtrr clean up
Oct 24 10:15:36 rhn kernel: [ 0.000000] gran_size: 64K ^Ichunk_size: 64K ^Inum_reg: 1 ^Ilose cover RAM: 0G
Oct 24 10:15:36 rhn kernel: [ 0.000000] New variable MTRRs
Oct 24 10:15:36 rhn kernel: [ 0.000000] reg 0, base: 0GB, range: 512MB, type WB
Oct 24 10:15:36 rhn kernel: [ 0.000000] initial memory mapped : 0 - 01800000
Oct 24 10:15:36 rhn kernel: [ 0.000000] Base memory trampoline at [c009e000] 9e000 size 4096
Oct 24 10:15:36 rhn kernel: [ 0.000000] init_memory_mapping: 0000000000000000-000000001ffc0000
Oct 24 10:15:36 rhn kernel: [ 0.000000] 0000000000 - 0000400000 page 4k
Oct 24 10:15:36 rhn kernel: [ 0.000000] 0000400000 - 001fc00000 page 2M
Oct 24 10:15:36 rhn kernel: [ 0.000000] 001fc00000 - 001ffc0000 page 4k
Oct 24 10:15:36 rhn kernel: [ 0.000000] kernel direct mapping tables up to 1ffc0000 @ 17fb000-1800000
Oct 24 10:15:36 rhn kernel: [ 0.000000] ACPI: RSDP 000ff980 00014 (v00 AMI )
Oct 24 10:15:36 rhn kernel: [ 0.000000] ACPI: RSDT 1fff0000 0002C (v01 D815EA D815EEA2 20021106 MSFT 00001011)
Oct 24 10:15:36 rhn kernel: [ 0.000000] ACPI: FACP 1fff1000 00074 (v01 D815EA EA81510A 20021106 MSFT 00001011)
Oct 24 10:15:36 rhn kernel: [ 0.000000] ACPI: DSDT 1ffe0000 030E4 (v01 D815E2 EA81520A 00000023 MSFT 0100000B)
Oct 24 10:15:36 rhn kernel: [ 0.000000] ACPI: FACS 1fff8000 00040
Oct 24 10:15:36 rhn kernel: [ 0.000000] ACPI: SSDT 1ffe30e4 00035 (v01 D815EA EA81510A 00000015 MSFT 0100000B)
Oct 24 10:15:36 rhn kernel: [ 0.000000] 511MB LOWMEM available.
Oct 24 10:15:36 rhn kernel: [ 0.000000] mapped low ram: 0 - 1ffc0000
Oct 24 10:15:36 rhn kernel: [ 0.000000] low ram: 0 - 1ffc0000
Oct 24 10:15:36 rhn kernel: [ 0.000000] Zone PFN ranges:
Oct 24 10:15:36 rhn kernel: [ 0.000000] DMA 0x00000010 -> 0x00001000
Oct 24 10:15:36 rhn kernel: [ 0.000000] Normal 0x00001000 -> 0x0001ffc0
Oct 24 10:15:36 rhn kernel: [ 0.000000] Movable zone start PFN for each node
Oct 24 10:15:36 rhn kernel: [ 0.000000] early_node_map[2] active PFN ranges
Oct 24 10:15:36 rhn kernel: [ 0.000000] 0: 0x00000010 -> 0x0000009f
Oct 24 10:15:36 rhn kernel: [ 0.000000] 0: 0x00000100 -> 0x0001ffc0
Oct 24 10:15:36 rhn kernel: [ 0.000000] On node 0 totalpages: 130895
Oct 24 10:15:36 rhn kernel: [ 0.000000] free_area_init_node: node 0, pgdat c139c5a4, node_mem_map dfbc0200
Oct 24 10:15:36 rhn kernel: [ 0.000000] DMA zone: 32 pages used for memmap
Oct 24 10:15:36 rhn kernel: [ 0.000000] DMA zone: 0 pages reserved
Oct 24 10:15:36 rhn kernel: [ 0.000000] DMA zone: 3951 pages, LIFO batch:0
Oct 24 10:15:36 rhn kernel: [ 0.000000] Normal zone: 992 pages used for memmap
Oct 24 10:15:36 rhn kernel: [ 0.000000] Normal zone: 125920 pages, LIFO batch:31
Oct 24 10:15:36 rhn kernel: [ 0.000000] Using APIC driver default
Oct 24 10:15:36 rhn kernel: [ 0.000000] ACPI: PM-Timer IO Port: 0x408
Oct 24 10:15:36 rhn kernel: [ 0.000000] Found and enabled local APIC!
Oct 24 10:15:36 rhn kernel: [ 0.000000] Allocating PCI resources starting at 20000000 (gap: 20000000:dfb80000)
Oct 24 10:15:36 rhn kernel: [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
Oct 24 10:15:36 rhn kernel: [ 0.000000] pcpu-alloc: [0] 0
Oct 24 10:15:36 rhn kernel: [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129871
Oct 24 10:15:36 rhn kernel: [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.1.0-rc10-dirty root=/dev/sda3 ro lapic petconsole=1980@192.168.74.17/eth0,1975@192.168.74.24/00:50:8d:91:d9:f0
Oct 24 10:15:36 rhn kernel: [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
Oct 24 10:15:36 rhn kernel: [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Oct 24 10:15:36 rhn kernel: [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Oct 24 10:15:36 rhn kernel: [ 0.000000] Initializing CPU#0
Oct 24 10:15:36 rhn kernel: [ 0.000000] Memory: 514724k/524032k available (2366k kernel code, 8856k reserved, 1348k data, 284k init, 0k highmem)
Oct 24 10:15:36 rhn kernel: [ 0.000000] virtual kernel memory layout:
Oct 24 10:15:36 rhn kernel: [ 0.000000] fixmap : 0xfffe3000 - 0xfffff000 ( 112 kB)
Oct 24 10:15:36 rhn kernel: [ 0.000000] vmalloc : 0xe07c0000 - 0xfffe1000 ( 504 MB)
Oct 24 10:15:36 rhn kernel: [ 0.000000] lowmem : 0xc0000000 - 0xdffc0000 ( 511 MB)
Oct 24 10:15:36 rhn kernel: [ 0.000000] .init : 0xc13a1000 - 0xc13e8000 ( 284 kB)
Oct 24 10:15:36 rhn kernel: [ 0.000000] .data : 0xc124fa56 - 0xc13a0b40 (1348 kB)
Oct 24 10:15:36 rhn kernel: [ 0.000000] .text : 0xc1000000 - 0xc124fa56 (2366 kB)
Oct 24 10:15:36 rhn kernel: [ 0.000000] Checking if this processor honours the WP bit even in supervisor mode...Ok.
Oct 24 10:15:36 rhn kernel: [ 0.000000] NR_IRQS:16
Oct 24 10:15:36 rhn kernel: [ 0.000000] CPU 0 irqstacks, hard=df406000 soft=df408000
Oct 24 10:15:36 rhn kernel: [ 0.000000] Console: colour VGA+ 80x25
Oct 24 10:15:36 rhn kernel: [ 0.000000] console [tty0] enabled
Oct 24 10:15:36 rhn kernel: [ 0.000000] Fast TSC calibration using PIT
Oct 24 10:15:36 rhn kernel: [ 0.000000] Detected 930.445 MHz processor.
Oct 24 10:15:36 rhn kernel: [ 0.008004] Calibrating delay loop (skipped), value calculated using timer frequency.. 1860.89 BogoMIPS (lpj=3721780)
Oct 24 10:15:36 rhn kernel: [ 0.008300] pid_max: default: 32768 minimum: 301
Oct 24 10:15:36 rhn kernel: [ 0.008564] Mount-cache hash table entries: 512
Oct 24 10:15:36 rhn kernel: [ 0.008935] Initializing cgroup subsys blkio
Oct 24 10:15:36 rhn kernel: [ 0.009152] mce: CPU supports 5 MCE banks
Oct 24 10:15:36 rhn kernel: [ 0.009327] CPU: Intel Pentium III (Coppermine) stepping 06
Oct 24 10:15:36 rhn kernel: [ 0.009538] ACPI: Core revision 20110623
Oct 24 10:15:36 rhn kernel: [ 0.014597] ACPI: setting ELCR to 0200 (from 0e00)
Oct 24 10:15:36 rhn kernel: [ 0.015783] Performance Events: p6 PMU driver.
Oct 24 10:15:36 rhn kernel: [ 0.015956] ... version: 0
Oct 24 10:15:36 rhn kernel: [ 0.016008] ... bit width: 32
Oct 24 10:15:36 rhn kernel: [ 0.016155] ... generic registers: 2
Oct 24 10:15:36 rhn kernel: [ 0.016302] ... value mask: 00000000ffffffff
Oct 24 10:15:36 rhn kernel: [ 0.016453] ... max period: 000000007fffffff
Oct 24 10:15:36 rhn kernel: [ 0.016603] ... fixed-purpose events: 0
Oct 24 10:15:36 rhn kernel: [ 0.016748] ... event mask: 0000000000000003
Oct 24 10:15:36 rhn kernel: [ 0.017147] NMI watchdog enabled, takes one hw-pmu counter.
Oct 24 10:15:36 rhn kernel: [ 0.020001] NET: Registered protocol family 16
Oct 24 10:15:36 rhn kernel: [ 0.020001] ACPI: bus type pci registered
Oct 24 10:15:36 rhn kernel: [ 0.020001] PCI: PCI BIOS revision 2.10 entry at 0xfda95, last bus=2
Oct 24 10:15:36 rhn kernel: [ 0.020001] PCI: Using configuration type 1 for base access
Oct 24 10:15:36 rhn kernel: [ 0.025692] bio: create slab <bio-0> at 0
Oct 24 10:15:36 rhn kernel: [ 0.026151] ACPI: Added _OSI(Module Device)
Oct 24 10:15:36 rhn kernel: [ 0.026303] ACPI: Added _OSI(Processor Device)
Oct 24 10:15:36 rhn kernel: [ 0.026452] ACPI: Added _OSI(3.0 _SCP Extensions)
Oct 24 10:15:36 rhn kernel: [ 0.026602] ACPI: Added _OSI(Processor Aggregator Device)
Oct 24 10:15:36 rhn kernel: [ 0.027974] ACPI: EC: Look up EC in DSDT
Oct 24 10:15:36 rhn kernel: [ 0.029752] ACPI: Executed 1 blocks of module-level executable AML code
Oct 24 10:15:36 rhn kernel: [ 0.036673] ACPI: Interpreter enabled
Oct 24 10:15:36 rhn kernel: [ 0.036828] ACPI: (supports S0 S5)
Oct 24 10:15:36 rhn kernel: [ 0.037019] ACPI: Using PIC for interrupt routing
Oct 24 10:15:36 rhn kernel: [ 0.040761] ACPI: Power Resource [FDDP] (off)
Oct 24 10:15:36 rhn kernel: [ 0.041617] ACPI: Power Resource [URP1] (off)
Oct 24 10:15:36 rhn kernel: [ 0.042506] ACPI: Power Resource [URP2] (off)
Oct 24 10:15:36 rhn kernel: [ 0.042965] ACPI: Power Resource [LPTP] (off)
Oct 24 10:15:36 rhn kernel: [ 0.049109] ACPI: No dock devices found.
Oct 24 10:15:36 rhn kernel: [ 0.049276] PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug
Oct 24 10:15:36 rhn kernel: [ 0.050130] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
Oct 24 10:15:36 rhn kernel: [ 0.051358] pci_root PNP0A03:00: host bridge window [io 0x0000-0x0cf7] (ignored)
Oct 24 10:15:36 rhn kernel: [ 0.051368] pci_root PNP0A03:00: host bridge window [io 0x0d00-0xffff] (ignored)
Oct 24 10:15:36 rhn kernel: [ 0.051378] pci_root PNP0A03:00: host bridge window [mem 0x20000000-0xffefffff] (ignored)
Oct 24 10:15:36 rhn kernel: [ 0.051406] pci 0000:00:00.0: [8086:1130] type 0 class 0x000600
Oct 24 10:15:36 rhn kernel: [ 0.051426] pci 0000:00:00.0: reg 10: [mem 0xf8000000-0xfbffffff pref]
Oct 24 10:15:36 rhn kernel: [ 0.051488] pci 0000:00:01.0: [8086:1131] type 1 class 0x000604
Oct 24 10:15:36 rhn kernel: [ 0.051566] pci 0000:00:1e.0: [8086:244e] type 1 class 0x000604
Oct 24 10:15:36 rhn kernel: [ 0.051625] pci 0000:00:1f.0: [8086:2440] type 0 class 0x000601
Oct 24 10:15:36 rhn kernel: [ 0.051722] pci 0000:00:1f.1: [8086:244b] type 0 class 0x000101
Oct 24 10:15:36 rhn kernel: [ 0.051775] pci 0000:00:1f.1: reg 20: [io 0xffa0-0xffaf]
Oct 24 10:15:36 rhn kernel: [ 0.051822] pci 0000:00:1f.2: [8086:2442] type 0 class 0x000c03
Oct 24 10:15:36 rhn kernel: [ 0.051877] pci 0000:00:1f.2: reg 20: [io 0xef40-0xef5f]
Oct 24 10:15:36 rhn kernel: [ 0.051922] pci 0000:00:1f.3: [8086:2443] type 0 class 0x000c05
Oct 24 10:15:36 rhn kernel: [ 0.051977] pci 0000:00:1f.3: reg 20: [io 0xefa0-0xefaf]
Oct 24 10:15:36 rhn kernel: [ 0.052110] pci 0000:00:1f.4: [8086:2444] type 0 class 0x000c03
Oct 24 10:15:36 rhn kernel: [ 0.052165] pci 0000:00:1f.4: reg 20: [io 0xef80-0xef9f]
Oct 24 10:15:36 rhn kernel: [ 0.052211] pci 0000:00:1f.5: [8086:2445] type 0 class 0x000401
Oct 24 10:15:36 rhn kernel: [ 0.052233] pci 0000:00:1f.5: reg 10: [io 0xe800-0xe8ff]
Oct 24 10:15:36 rhn kernel: [ 0.052249] pci 0000:00:1f.5: reg 14: [io 0xef00-0xef3f]
Oct 24 10:15:36 rhn kernel: [ 0.052338] pci 0000:02:00.0: [10de:002d] type 0 class 0x000300
Oct 24 10:15:36 rhn kernel: [ 0.052362] pci 0000:02:00.0: reg 10: [mem 0xfd000000-0xfdffffff]
Oct 24 10:15:36 rhn kernel: [ 0.052376] pci 0000:02:00.0: reg 14: [mem 0xf2000000-0xf3ffffff pref]
Oct 24 10:15:36 rhn kernel: [ 0.052416] pci 0000:02:00.0: reg 30: [mem 0xfeaf0000-0xfeafffff pref]
Oct 24 10:15:36 rhn kernel: [ 0.052483] pci 0000:00:01.0: PCI bridge to [bus 02-02]
Oct 24 10:15:36 rhn kernel: [ 0.052646] pci 0000:00:01.0: bridge window [mem 0xfca00000-0xfeafffff]
Oct 24 10:15:36 rhn kernel: [ 0.052656] pci 0000:00:01.0: bridge window [mem 0xf0700000-0xf47fffff pref]
Oct 24 10:15:36 rhn kernel: [ 0.052705] pci 0000:01:08.0: [8086:2449] type 0 class 0x000200
Oct 24 10:15:36 rhn kernel: [ 0.052728] pci 0000:01:08.0: reg 10: [mem 0xfc9fe000-0xfc9fefff]
Oct 24 10:15:36 rhn kernel: [ 0.052744] pci 0000:01:08.0: reg 14: [io 0xdf00-0xdf3f]
Oct 24 10:15:36 rhn kernel: [ 0.052806] pci 0000:01:08.0: supports D1 D2
Oct 24 10:15:36 rhn kernel: [ 0.052813] pci 0000:01:08.0: PME# supported from D0 D1 D2 D3hot D3cold
Oct 24 10:15:36 rhn kernel: [ 0.052824] pci 0000:01:08.0: PME# disabled
Oct 24 10:15:36 rhn kernel: [ 0.052853] pci 0000:01:0b.0: [10b5:1147] type 0 class 0x000700
Oct 24 10:15:36 rhn kernel: [ 0.052874] pci 0000:01:0b.0: reg 10: [mem 0xfc9ffc00-0xfc9ffc7f]
Oct 24 10:15:36 rhn kernel: [ 0.052890] pci 0000:01:0b.0: reg 14: [io 0xdc00-0xdc7f]
Oct 24 10:15:36 rhn kernel: [ 0.052906] pci 0000:01:0b.0: reg 18: [io 0xdff4-0xdff7]
Oct 24 10:15:36 rhn kernel: [ 0.052922] pci 0000:01:0b.0: reg 1c: [io 0xdff0-0xdff3]
Oct 24 10:15:36 rhn kernel: [ 0.052954] pci 0000:01:0b.0: reg 30: [mem 0xfc9ff000-0xfc9ff7ff pref]
Oct 24 10:15:36 rhn kernel: [ 0.052997] pci 0000:00:1e.0: PCI bridge to [bus 01-01] (subtractive decode)
Oct 24 10:15:36 rhn kernel: [ 0.053158] pci 0000:00:1e.0: bridge window [io 0xd000-0xdfff]
Oct 24 10:15:36 rhn kernel: [ 0.053169] pci 0000:00:1e.0: bridge window [mem 0xfc900000-0xfc9fffff]
Oct 24 10:15:36 rhn kernel: [ 0.053180] pci 0000:00:1e.0: bridge window [mem 0xf0600000-0xf06fffff pref]
Oct 24 10:15:36 rhn kernel: [ 0.053189] pci 0000:00:1e.0: bridge window [io 0x0000-0xffff] (subtractive decode)
Oct 24 10:15:36 rhn kernel: [ 0.053198] pci 0000:00:1e.0: bridge window [mem 0x00000000-0xffffffff] (subtractive decode)
Oct 24 10:15:36 rhn kernel: [ 0.053218] pci_bus 0000:00: on NUMA node 0
Oct 24 10:15:36 rhn kernel: [ 0.053229] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Oct 24 10:15:36 rhn kernel: [ 0.053404] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
Oct 24 10:15:36 rhn kernel: [ 0.053831] pci0000:00: Unable to request _OSC control (_OSC support mask: 0x08)
Oct 24 10:15:36 rhn kernel: [ 0.057909] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12)
Oct 24 10:15:36 rhn kernel: [ 0.058330] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *9 10 11 12)
Oct 24 10:15:36 rhn kernel: [ 0.058741] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12) *0, disabled.
Oct 24 10:15:36 rhn kernel: [ 0.059296] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11 12)
Oct 24 10:15:36 rhn kernel: [ 0.059704] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12)
Oct 24 10:15:36 rhn kernel: [ 0.060194] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11 12) *0, disabled.
Oct 24 10:15:36 rhn kernel: [ 0.060757] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11 12) *0, disabled.
Oct 24 10:15:36 rhn kernel: [ 0.061319] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 *10 11 12)
Oct 24 10:15:36 rhn kernel: [ 0.062056] vgaarb: device added: PCI:0000:02:00.0,decodes=io+mem,owns=io+mem,locks=none
Oct 24 10:15:36 rhn kernel: [ 0.062346] vgaarb: loaded
Oct 24 10:15:36 rhn kernel: [ 0.062492] vgaarb: bridge control possible 0000:02:00.0
Oct 24 10:15:36 rhn kernel: [ 0.063108] SCSI subsystem initialized
Oct 24 10:15:36 rhn kernel: [ 0.063520] libata version 3.00 loaded.
Oct 24 10:15:36 rhn kernel: [ 0.063891] PCI: Using ACPI for IRQ routing
Oct 24 10:15:36 rhn kernel: [ 0.064096] PCI: pci_cache_line_size set to 32 bytes
Oct 24 10:15:36 rhn kernel: [ 0.064182] reserve RAM buffer: 000000000009fc00 - 000000000009ffff
Oct 24 10:15:36 rhn kernel: [ 0.064190] reserve RAM buffer: 000000001ffc0000 - 000000001fffffff
Oct 24 10:15:36 rhn kernel: [ 0.064774] pnp: PnP ACPI init
Oct 24 10:15:36 rhn kernel: [ 0.064949] ACPI: bus type pnp registered
Oct 24 10:15:36 rhn kernel: [ 0.065700] pnp 00:00: [bus 00-ff]
Oct 24 10:15:36 rhn kernel: [ 0.065710] pnp 00:00: [io 0x0cf8-0x0cff]
Oct 24 10:15:36 rhn kernel: [ 0.065718] pnp 00:00: [io 0x0000-0x0cf7 window]
Oct 24 10:15:36 rhn kernel: [ 0.065726] pnp 00:00: [io 0x0d00-0xffff window]
Oct 24 10:15:36 rhn kernel: [ 0.065734] pnp 00:00: [mem 0x20000000-0xffefffff window]
Oct 24 10:15:36 rhn kernel: [ 0.065945] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
Oct 24 10:15:36 rhn kernel: [ 0.066075] pnp 00:01: [dma 4]
Oct 24 10:15:36 rhn kernel: [ 0.066083] pnp 00:01: [io 0x0000-0x000f]
Oct 24 10:15:36 rhn kernel: [ 0.066090] pnp 00:01: [io 0x0081-0x0083]
Oct 24 10:15:36 rhn kernel: [ 0.066097] pnp 00:01: [io 0x0087]
Oct 24 10:15:36 rhn kernel: [ 0.066103] pnp 00:01: [io 0x0089-0x008b]
Oct 24 10:15:36 rhn kernel: [ 0.066110] pnp 00:01: [io 0x008f]
Oct 24 10:15:36 rhn kernel: [ 0.066116] pnp 00:01: [io 0x00c0-0x00df]
Oct 24 10:15:36 rhn kernel: [ 0.066242] pnp 00:01: Plug and Play ACPI device, IDs PNP0200 (active)
Oct 24 10:15:36 rhn kernel: [ 0.066279] pnp 00:02: [io 0x0070-0x0071]
Oct 24 10:15:36 rhn kernel: [ 0.066289] pnp 00:02: [irq 8]
Oct 24 10:15:36 rhn kernel: [ 0.066406] pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active)
Oct 24 10:15:36 rhn kernel: [ 0.066436] pnp 00:03: [io 0x0061]
Oct 24 10:15:36 rhn kernel: [ 0.066546] pnp 00:03: Plug and Play ACPI device, IDs PNP0800 (active)
Oct 24 10:15:36 rhn kernel: [ 0.066578] pnp 00:04: [io 0x00f0-0x00ff]
Oct 24 10:15:36 rhn kernel: [ 0.066587] pnp 00:04: [irq 13]
Oct 24 10:15:36 rhn kernel: [ 0.066698] pnp 00:04: Plug and Play ACPI device, IDs PNP0c04 (active)
Oct 24 10:15:36 rhn kernel: [ 0.066810] pnp 00:05: [irq 12]
Oct 24 10:15:36 rhn kernel: [ 0.066947] pnp 00:05: Plug and Play ACPI device, IDs PNP0f03 PNP0f13 (active)
Oct 24 10:15:36 rhn kernel: [ 0.067042] pnp 00:06: [io 0x0060]
Oct 24 10:15:36 rhn kernel: [ 0.067050] pnp 00:06: [io 0x0064]
Oct 24 10:15:36 rhn kernel: [ 0.067057] pnp 00:06: [irq 1]
Oct 24 10:15:36 rhn kernel: [ 0.067196] pnp 00:06: Plug and Play ACPI device, IDs PNP0303 PNP030b (active)
Oct 24 10:15:36 rhn kernel: [ 0.068123] pnp 00:07: [io 0x03f0-0x03f1]
Oct 24 10:15:36 rhn kernel: [ 0.068131] pnp 00:07: [io 0x03f2-0x03f3]
Oct 24 10:15:36 rhn kernel: [ 0.068139] pnp 00:07: [io 0x03f4-0x03f5]
Oct 24 10:15:36 rhn kernel: [ 0.068145] pnp 00:07: [io 0x03f7]
Oct 24 10:15:36 rhn kernel: [ 0.068153] pnp 00:07: [irq 6]
Oct 24 10:15:36 rhn kernel: [ 0.068160] pnp 00:07: [dma 2]
Oct 24 10:15:36 rhn kernel: [ 0.068384] pnp 00:07: Plug and Play ACPI device, IDs PNP0700 (active)
Oct 24 10:15:36 rhn kernel: [ 0.068976] pnp 00:08: [io 0x03f8-0x03ff]
Oct 24 10:15:36 rhn kernel: [ 0.068984] pnp 00:08: [irq 4]
Oct 24 10:15:36 rhn kernel: [ 0.069226] pnp 00:08: Plug and Play ACPI device, IDs PNP0501 (active)
Oct 24 10:15:36 rhn kernel: [ 0.069803] pnp 00:09: [io 0x02f8-0x02ff]
Oct 24 10:15:36 rhn kernel: [ 0.069813] pnp 00:09: [irq 3]
Oct 24 10:15:36 rhn kernel: [ 0.070045] pnp 00:09: Plug and Play ACPI device, IDs PNP0501 (active)
Oct 24 10:15:36 rhn kernel: [ 0.070895] pnp 00:0a: [io 0x0378-0x037f]
Oct 24 10:15:36 rhn kernel: [ 0.070904] pnp 00:0a: [io 0x0778-0x077f]
Oct 24 10:15:36 rhn kernel: [ 0.070924] pnp 00:0a: [irq 7]
Oct 24 10:15:36 rhn kernel: [ 0.070931] pnp 00:0a: [dma 3]
Oct 24 10:15:36 rhn kernel: [ 0.071274] pnp 00:0a: Plug and Play ACPI device, IDs PNP0401 (active)
Oct 24 10:15:36 rhn kernel: [ 0.071434] pnp 00:0b: [mem 0xfff00000-0xffffffff]
Oct 24 10:15:36 rhn kernel: [ 0.071442] pnp 00:0b: [mem 0xffb00000-0xffbfffff]
Oct 24 10:15:36 rhn kernel: [ 0.071593] pnp 00:0b: Plug and Play ACPI device, IDs INT0800 (active)
Oct 24 10:15:36 rhn kernel: [ 0.072577] pnp 00:0c: [mem 0x00000000-0x0009ffff]
Oct 24 10:15:36 rhn kernel: [ 0.072586] pnp 00:0c: [mem 0x000e0000-0x000fffff]
Oct 24 10:15:36 rhn kernel: [ 0.072594] pnp 00:0c: [mem 0x00100000-0x1fffffff]
Oct 24 10:15:36 rhn kernel: [ 0.072602] pnp 00:0c: [mem 0x00000000-0xffffffff disabled]
Oct 24 10:15:36 rhn kernel: [ 0.072610] pnp 00:0c: [mem 0x00000000-0xffffffff disabled]
Oct 24 10:15:36 rhn kernel: [ 0.072847] system 00:0c: [mem 0x00000000-0x0009ffff] could not be reserved
Oct 24 10:15:36 rhn kernel: [ 0.073012] system 00:0c: [mem 0x000e0000-0x000fffff] could not be reserved
Oct 24 10:15:36 rhn kernel: [ 0.073166] system 00:0c: [mem 0x00100000-0x1fffffff] could not be reserved
Oct 24 10:15:36 rhn kernel: [ 0.073322] system 00:0c: Plug and Play ACPI device, IDs PNP0c01 (active)
Oct 24 10:15:36 rhn kernel: [ 0.073344] pnp: PnP ACPI: found 13 devices
Oct 24 10:15:36 rhn kernel: [ 0.073490] ACPI: ACPI bus type pnp unregistered
Oct 24 10:15:36 rhn kernel: [ 0.116295] Switching to clocksource acpi_pm
Oct 24 10:15:36 rhn kernel: [ 0.116490] PCI: max bus depth: 1 pci_try_num: 2
Oct 24 10:15:36 rhn kernel: [ 0.116525] pci 0000:00:01.0: PCI bridge to [bus 02-02]
Oct 24 10:15:36 rhn kernel: [ 0.116686] pci 0000:00:01.0: bridge window [mem 0xfca00000-0xfeafffff]
Oct 24 10:15:36 rhn kernel: [ 0.116846] pci 0000:00:01.0: bridge window [mem 0xf0700000-0xf47fffff pref]
Oct 24 10:15:36 rhn kernel: [ 0.117135] pci 0000:00:1e.0: PCI bridge to [bus 01-01]
Oct 24 10:15:36 rhn kernel: [ 0.117289] pci 0000:00:1e.0: bridge window [io 0xd000-0xdfff]
Oct 24 10:15:36 rhn kernel: [ 0.117449] pci 0000:00:1e.0: bridge window [mem 0xfc900000-0xfc9fffff]
Oct 24 10:15:36 rhn kernel: [ 0.117609] pci 0000:00:1e.0: bridge window [mem 0xf0600000-0xf06fffff pref]
Oct 24 10:15:36 rhn kernel: [ 0.117920] pci 0000:00:1e.0: setting latency timer to 64
Oct 24 10:15:36 rhn kernel: [ 0.117931] pci_bus 0000:00: resource 0 [io 0x0000-0xffff]
Oct 24 10:15:36 rhn kernel: [ 0.117940] pci_bus 0000:00: resource 1 [mem 0x00000000-0xffffffff]
Oct 24 10:15:36 rhn kernel: [ 0.117949] pci_bus 0000:02: resource 1 [mem 0xfca00000-0xfeafffff]
Oct 24 10:15:36 rhn kernel: [ 0.117957] pci_bus 0000:02: resource 2 [mem 0xf0700000-0xf47fffff pref]
Oct 24 10:15:36 rhn kernel: [ 0.117966] pci_bus 0000:01: resource 0 [io 0xd000-0xdfff]
Oct 24 10:15:36 rhn kernel: [ 0.117974] pci_bus 0000:01: resource 1 [mem 0xfc900000-0xfc9fffff]
Oct 24 10:15:36 rhn kernel: [ 0.117983] pci_bus 0000:01: resource 2 [mem 0xf0600000-0xf06fffff pref]
Oct 24 10:15:36 rhn kernel: [ 0.117991] pci_bus 0000:01: resource 4 [io 0x0000-0xffff]
Oct 24 10:15:36 rhn kernel: [ 0.117999] pci_bus 0000:01: resource 5 [mem 0x00000000-0xffffffff]
Oct 24 10:15:36 rhn kernel: [ 0.118128] NET: Registered protocol family 2
Oct 24 10:15:36 rhn kernel: [ 0.118385] IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
Oct 24 10:15:36 rhn kernel: [ 0.118775] TCP established hash table entries: 16384 (order: 5, 131072 bytes)
Oct 24 10:15:36 rhn kernel: [ 0.119417] TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
Oct 24 10:15:36 rhn kernel: [ 0.119766] TCP: Hash tables configured (established 16384 bind 16384)
Oct 24 10:15:36 rhn kernel: [ 0.119922] TCP reno registered
Oct 24 10:15:36 rhn kernel: [ 0.119922] Switched to NOHz mode on CPU #0
Oct 24 10:15:36 rhn kernel: [ 0.119922] UDP hash table entries: 256 (order: 0, 4096 bytes)
Oct 24 10:15:36 rhn kernel: [ 0.120045] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
Oct 24 10:15:36 rhn kernel: [ 0.120451] NET: Registered protocol family 1
Oct 24 10:15:36 rhn kernel: [ 0.120709] pci 0000:02:00.0: Boot video device
Oct 24 10:15:36 rhn kernel: [ 0.120750] pci 0000:01:08.0: Firmware left e100 interrupts enabled; disabling
Oct 24 10:15:36 rhn kernel: [ 0.121038] PCI: CLS 32 bytes, default 32
Oct 24 10:15:36 rhn kernel: [ 0.128302] VFS: Disk quotas dquot_6.5.2
Oct 24 10:15:36 rhn kernel: [ 0.128490] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Oct 24 10:15:36 rhn kernel: [ 0.128819] msgmni has been set to 1005
Oct 24 10:15:36 rhn kernel: [ 0.129462] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
Oct 24 10:15:36 rhn kernel: [ 0.129743] io scheduler noop registered
Oct 24 10:15:36 rhn kernel: [ 0.129910] io scheduler cfq registered (default)
Oct 24 10:15:36 rhn kernel: [ 0.130552] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
Oct 24 10:15:36 rhn kernel: [ 0.404079] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Oct 24 10:15:36 rhn kernel: [ 0.680079] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Oct 24 10:15:36 rhn kernel: [ 0.702700] 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Oct 24 10:15:36 rhn kernel: [ 0.723459] 00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Oct 24 10:15:36 rhn kernel: [ 0.724282] ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 10
Oct 24 10:15:36 rhn kernel: [ 0.724442] PCI: setting IRQ 10 as level-triggered
Oct 24 10:15:36 rhn kernel: [ 0.724456] serial 0000:01:0b.0: PCI INT A -> Link[LNKH] -> GSI 10 (level, low) -> IRQ 10
Oct 24 10:15:36 rhn kernel: [ 0.724765] serial 0000:01:0b.0: PCI INT A disabled
Oct 24 10:15:36 rhn kernel: [ 0.725241] Non-volatile memory driver v1.3
Oct 24 10:15:36 rhn kernel: [ 0.725394] Linux agpgart interface v0.103
Oct 24 10:15:36 rhn kernel: [ 0.725663] agpgart-intel 0000:00:00.0: Intel i815 Chipset
Oct 24 10:15:36 rhn kernel: [ 0.730180] agpgart-intel 0000:00:00.0: AGP aperture is 64M @ 0xf8000000
Oct 24 10:15:36 rhn kernel: [ 0.730451] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds).
Oct 24 10:15:36 rhn kernel: [ 0.730733] Hangcheck: Using getrawmonotonic().
Oct 24 10:15:36 rhn kernel: [ 0.731003] [drm] Initialized drm 1.1.0 20060810
Oct 24 10:15:36 rhn kernel: [ 0.731442] Floppy drive(s): fd0 is 1.44M
Oct 24 10:15:36 rhn kernel: [ 0.745770] FDC 0 is a post-1991 82077
Oct 24 10:15:36 rhn kernel: [ 0.747932] ata_piix 0000:00:1f.1: version 2.13
Oct 24 10:15:36 rhn kernel: [ 0.748128] ata_piix 0000:00:1f.1: setting latency timer to 64
Oct 24 10:15:36 rhn kernel: [ 0.749209] scsi0 : ata_piix
Oct 24 10:15:36 rhn kernel: [ 0.749684] scsi1 : ata_piix
Oct 24 10:15:36 rhn kernel: [ 0.752430] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
Oct 24 10:15:36 rhn kernel: [ 0.752596] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
Oct 24 10:15:36 rhn kernel: [ 0.753125] ata2: port disabled--ignoring
Oct 24 10:15:36 rhn kernel: [ 0.753261] e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
Oct 24 10:15:36 rhn kernel: [ 0.753418] e100: Copyright(c) 1999-2006 Intel Corporation
Oct 24 10:15:36 rhn kernel: [ 0.753864] ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 11
Oct 24 10:15:36 rhn kernel: [ 0.754019] PCI: setting IRQ 11 as level-triggered
Oct 24 10:15:36 rhn kernel: [ 0.754032] e100 0000:01:08.0: PCI INT A -> Link[LNKE] -> GSI 11 (level, low) -> IRQ 11
Oct 24 10:15:36 rhn kernel: [ 0.776944] e100 0000:01:08.0: PME# disabled
Oct 24 10:15:36 rhn kernel: [ 0.777297] e100 0000:01:08.0: eth0: addr 0xfc9fe000, irq 11, MAC addr 00:03:47:a4:64:d5
Oct 24 10:15:36 rhn kernel: [ 0.777969] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
Oct 24 10:15:36 rhn kernel: [ 0.781497] serio: i8042 KBD port at 0x60,0x64 irq 1
Oct 24 10:15:36 rhn kernel: [ 0.785027] serio: i8042 AUX port at 0x60,0x64 irq 12
Oct 24 10:15:36 rhn kernel: [ 0.785692] mousedev: PS/2 mouse device common for all mice
Oct 24 10:15:36 rhn kernel: [ 0.786168] rtc_cmos 00:02: RTC can wake from S4
Oct 24 10:15:36 rhn kernel: [ 0.786547] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
Oct 24 10:15:36 rhn kernel: [ 0.786726] rtc0: alarms up to one month, 114 bytes nvram
Oct 24 10:15:36 rhn kernel: [ 0.786970] cpuidle: using governor ladder
Oct 24 10:15:36 rhn kernel: [ 0.787118] cpuidle: using governor menu
Oct 24 10:15:36 rhn kernel: [ 0.788604] TCP cubic registered
Oct 24 10:15:36 rhn kernel: [ 0.788783] NET: Registered protocol family 17
Oct 24 10:15:36 rhn kernel: [ 0.788952] Registering the dns_resolver key type
Oct 24 10:15:36 rhn kernel: [ 0.789123] Using IPI Shortcut mode
Oct 24 10:15:36 rhn kernel: [ 0.789673] registered taskstats version 1
Oct 24 10:15:36 rhn kernel: [ 0.790246] console [netcon0] enabled
Oct 24 10:15:36 rhn kernel: [ 0.790394] netconsole: network logging started
Oct 24 10:15:36 rhn kernel: [ 0.790599] rtc_cmos 00:02: setting system clock to 2011-10-24 10:15:04 UTC (1319451304)
Oct 24 10:15:36 rhn kernel: [ 0.806861] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
Oct 24 10:15:36 rhn kernel: [ 0.972477] ata1.00: ATA-6: ST380011A, 3.06, max UDMA/100
Oct 24 10:15:36 rhn kernel: [ 0.972635] ata1.00: 156301488 sectors, multi 16: LBA48
Oct 24 10:15:36 rhn kernel: [ 0.988352] ata1.00: configured for UDMA/100
Oct 24 10:15:36 rhn kernel: [ 0.988795] scsi 0:0:0:0: Direct-Access ATA ST380011A 3.06 PQ: 0 ANSI: 5
Oct 24 10:15:36 rhn kernel: [ 0.989682] sd 0:0:0:0: [sda] 156301488 512-byte logical blocks: (80.0 GB/74.5 GiB)
Oct 24 10:15:36 rhn kernel: [ 0.990108] sd 0:0:0:0: [sda] Write Protect is off
Oct 24 10:15:36 rhn kernel: [ 0.990262] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
Oct 24 10:15:36 rhn kernel: [ 0.990324] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Oct 24 10:15:36 rhn kernel: [ 1.024153] sda: sda1 sda2 sda3 sda4
Oct 24 10:15:36 rhn kernel: [ 1.025411] sd 0:0:0:0: [sda] Attached SCSI disk
Oct 24 10:15:36 rhn kernel: [ 1.124022] Refined TSC clocksource calibration: 930.314 MHz.
Oct 24 10:15:36 rhn kernel: [ 1.124183] Switching to clocksource tsc
Oct 24 10:15:36 rhn kernel: [ 1.742819] input: ImExPS/2 Logitech Wheel Mouse as /devices/platform/i8042/serio1/input/input1
Oct 24 10:15:36 rhn kernel: [ 1.769504] EXT3-fs (sda3): mounted filesystem with writeback data mode
Oct 24 10:15:36 rhn kernel: [ 1.769690] VFS: Mounted root (ext3 filesystem) readonly on device 8:3.
Oct 24 10:15:36 rhn kernel: [ 1.769912] Freeing unused kernel memory: 284k freed
Oct 24 10:15:36 rhn kernel: [ 1.770728] Write protecting the kernel text: 2368k
Oct 24 10:15:36 rhn kernel: [ 1.770929] Write protecting the kernel read-only data: 1180k
Oct 24 10:15:36 rhn kernel: [ 1.771404] kjournald starting. Commit interval 5 seconds
Oct 24 10:15:36 rhn kernel: [ 4.676506] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input2
Oct 24 10:15:36 rhn kernel: [ 4.676811] ACPI: Power Button [PBTN]
Oct 24 10:15:36 rhn kernel: [ 4.677140] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3
Oct 24 10:15:36 rhn kernel: [ 4.677420] ACPI: Power Button [PWRF]
Oct 24 10:15:36 rhn kernel: [ 4.682527] ACPI: acpi_idle registered with cpuidle
Oct 24 10:15:36 rhn kernel: [ 4.932986] parport_pc 00:0a: reported by Plug and Play ACPI
Oct 24 10:15:36 rhn kernel: [ 4.933199] parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
Oct 24 10:15:36 rhn kernel: [ 4.987916] usbcore: registered new interface driver usbfs
Oct 24 10:15:36 rhn kernel: [ 5.019160] usbcore: registered new interface driver hub
Oct 24 10:15:36 rhn kernel: [ 5.023397] usbcore: registered new device driver usb
Oct 24 10:15:36 rhn kernel: [ 5.069800] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Oct 24 10:15:36 rhn kernel: [ 5.091429] uhci_hcd: USB Universal Host Controller Interface driver
Oct 24 10:15:36 rhn kernel: [ 5.091972] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 11
Oct 24 10:15:36 rhn kernel: [ 5.092175] uhci_hcd 0000:00:1f.2: PCI INT D -> Link[LNKD] -> GSI 11 (level, low) -> IRQ 11
Oct 24 10:15:36 rhn kernel: [ 5.092468] uhci_hcd 0000:00:1f.2: setting latency timer to 64
Oct 24 10:15:36 rhn kernel: [ 5.092477] uhci_hcd 0000:00:1f.2: UHCI Host Controller
Oct 24 10:15:36 rhn kernel: [ 5.092643] uhci_hcd 0000:00:1f.2: new USB bus registered, assigned bus number 1
Oct 24 10:15:36 rhn kernel: [ 5.092962] uhci_hcd 0000:00:1f.2: irq 11, io base 0x0000ef40
Oct 24 10:15:36 rhn kernel: [ 5.093208] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
Oct 24 10:15:36 rhn kernel: [ 5.093367] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Oct 24 10:15:36 rhn kernel: [ 5.093651] usb usb1: Product: UHCI Host Controller
Oct 24 10:15:36 rhn kernel: [ 5.093801] usb usb1: Manufacturer: Linux 3.1.0-rc10-dirty uhci_hcd
Oct 24 10:15:36 rhn kernel: [ 5.093956] usb usb1: SerialNumber: 0000:00:1f.2
Oct 24 10:15:36 rhn kernel: [ 5.094351] hub 1-0:1.0: USB hub found
Oct 24 10:15:36 rhn kernel: [ 5.094510] hub 1-0:1.0: 2 ports detected
Oct 24 10:15:36 rhn kernel: [ 5.094774] uhci_hcd 0000:00:1f.4: PCI INT C -> Link[LNKH] -> GSI 10 (level, low) -> IRQ 10
Oct 24 10:15:36 rhn kernel: [ 5.095070] uhci_hcd 0000:00:1f.4: setting latency timer to 64
Oct 24 10:15:36 rhn kernel: [ 5.095079] uhci_hcd 0000:00:1f.4: UHCI Host Controller
Oct 24 10:15:36 rhn kernel: [ 5.095239] uhci_hcd 0000:00:1f.4: new USB bus registered, assigned bus number 2
Oct 24 10:15:36 rhn kernel: [ 5.095551] uhci_hcd 0000:00:1f.4: irq 10, io base 0x0000ef80
Oct 24 10:15:36 rhn kernel: [ 5.095776] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
Oct 24 10:15:36 rhn kernel: [ 5.095935] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
Oct 24 10:15:36 rhn kernel: [ 5.108434] usb usb2: Product: UHCI Host Controller
Oct 24 10:15:36 rhn kernel: [ 5.108601] usb usb2: Manufacturer: Linux 3.1.0-rc10-dirty uhci_hcd
Oct 24 10:15:36 rhn kernel: [ 5.108756] usb usb2: SerialNumber: 0000:00:1f.4
Oct 24 10:15:36 rhn kernel: [ 5.109483] hub 2-0:1.0: USB hub found
Oct 24 10:15:36 rhn kernel: [ 5.109645] hub 2-0:1.0: 2 ports detected
Oct 24 10:15:36 rhn kernel: [ 5.342984] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 9
Oct 24 10:15:36 rhn kernel: [ 5.343155] PCI: setting IRQ 9 as level-triggered
Oct 24 10:15:36 rhn kernel: [ 5.343168] i801_smbus 0000:00:1f.3: PCI INT B -> Link[LNKB] -> GSI 9 (level, low) -> IRQ 9
Oct 24 10:15:36 rhn kernel: [ 5.588141] wmi: Mapper loaded
Oct 24 10:15:36 rhn kernel: [ 6.113920] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
Oct 24 10:15:36 rhn kernel: [ 6.114095] nouveau 0000:02:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11
Oct 24 10:15:36 rhn kernel: [ 6.118358] [drm] nouveau 0000:02:00.0: Detected an NV 0 generation card (0x20154000)
Oct 24 10:15:36 rhn kernel: [ 6.119076] [drm] nouveau 0000:02:00.0: Attempting to load BIOS image from PRAMIN
Oct 24 10:15:36 rhn kernel: [ 6.193308] [drm] nouveau 0000:02:00.0: ... appears to be valid
Oct 24 10:15:36 rhn kernel: [ 6.194347] [drm] nouveau 0000:02:00.0: BMP BIOS found
Oct 24 10:15:36 rhn kernel: [ 6.194501] [drm] nouveau 0000:02:00.0: BMP version 5.1
Oct 24 10:15:36 rhn kernel: [ 6.194656] [drm] nouveau 0000:02:00.0: Bios version 02.05.19.03
Oct 24 10:15:36 rhn kernel: [ 6.229158] [drm] nouveau 0000:02:00.0: 0 available performance level(s)
Oct 24 10:15:36 rhn kernel: [ 6.229343] [drm] nouveau 0000:02:00.0: c: memory 143MHz core 125MHz
Oct 24 10:15:36 rhn kernel: [ 6.229730] [TTM] Zone kernel: Available graphics memory: 257504 kiB.
Oct 24 10:15:36 rhn kernel: [ 6.229885] [TTM] Initializing pool allocator.
Oct 24 10:15:36 rhn kernel: [ 6.230062] [drm] nouveau 0000:02:00.0: Detected 32MiB VRAM
Oct 24 10:15:36 rhn kernel: [ 6.230420] agpgart-intel 0000:00:00.0: AGP 2.0 bridge
Oct 24 10:15:36 rhn kernel: [ 6.230610] agpgart-intel 0000:00:00.0: putting AGP V2 device into 4x mode
Oct 24 10:15:36 rhn kernel: [ 6.230794] nouveau 0000:02:00.0: putting AGP V2 device into 4x mode
Oct 24 10:15:36 rhn kernel: [ 6.230960] [drm] nouveau 0000:02:00.0: 64 MiB GART (aperture)
Oct 24 10:15:36 rhn kernel: [ 6.231192] [drm] nouveau 0000:02:00.0: Saving VGA fonts
Oct 24 10:15:36 rhn kernel: [ 6.276381] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
Oct 24 10:15:36 rhn kernel: [ 6.276548] [drm] No driver support for vblank timestamp query.
Oct 24 10:15:36 rhn kernel: [ 6.281474] [drm] nouveau 0000:02:00.0: Setting dpms mode 3 on vga encoder (output 0)
Oct 24 10:15:36 rhn kernel: [ 6.344132] snd_intel8x0 0000:00:1f.5: PCI INT B -> Link[LNKB] -> GSI 9 (level, low) -> IRQ 9
Oct 24 10:15:36 rhn kernel: [ 6.344457] snd_intel8x0 0000:00:1f.5: setting latency timer to 64
Oct 24 10:15:36 rhn kernel: [ 6.411324] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: DATA_ERROR nstatus: BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.411692] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/2 class 0x0042 mthd 0x0304 data 0x20002000
Oct 24 10:15:36 rhn kernel: [ 6.411976] [drm] nouveau 0000:02:00.0: allocated 2048x1536 fb: 0x44000, bo df645200
Oct 24 10:15:36 rhn kernel: [ 6.412004] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.412004] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0404 data 0x08000600
Oct 24 10:15:36 rhn kernel: [ 6.413344] fbcon: nouveaufb (fb0) is primary device
Oct 24 10:15:36 rhn kernel: [ 6.472073] [drm] nouveau 0000:02:00.0: Could not find a compatible set of PLL values
Oct 24 10:15:36 rhn kernel: [ 6.550154] [drm] nouveau 0000:02:00.0: Setting dpms mode 0 on vga encoder (output 0)
Oct 24 10:15:36 rhn kernel: [ 6.550168] [drm] nouveau 0000:02:00.0: Output VGA-1 is running on CRTC 0 using output A
Oct 24 10:15:36 rhn kernel: [ 6.550500] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.550517] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c00 data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.550526] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.550540] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c04 data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.550549] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.550562] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c08 data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.550571] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.550585] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c0c data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.550990] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.551004] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c00 data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.551014] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.551027] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c04 data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.551036] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.551049] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c08 data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.551058] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.551072] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c0c data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.551081] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.551094] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c10 data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.551103] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.551116] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c14 data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.551126] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.551139] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c18 data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.551148] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.551161] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c1c data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.551170] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.551183] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c20 data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.551193] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.551206] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c24 data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.551215] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.551228] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c28 data 0x00000000
Oct 24 10:15:36 rhn kernel: [ 6.551237] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:36 rhn kernel: [ 6.551251] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c2c data 0x00000000
Oct 24 10:15:37 rhn kernel: [ 6.551260] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:37 rhn kernel: [ 6.551273] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c30 data 0x00000000
Oct 24 10:15:37 rhn kernel: [ 6.551282] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:37 rhn kernel: [ 6.551295] [drm] nouveau 0000:02:00.0: PGRAPH - ch 0/3 class 0x004a mthd 0x0c34 data 0x00000000
Oct 24 10:15:37 rhn kernel: [ 6.959568] Console: switching to colour frame buffer device 256x96
Oct 24 10:15:37 rhn kernel: [ 6.989990] intel8x0_measure_ac97_clock: measured 57023 usecs (3192 samples)
Oct 24 10:15:37 rhn kernel: [ 6.989999] intel8x0: clocking to 41159
Oct 24 10:15:37 rhn kernel: [ 7.388778] [drm] nouveau 0000:02:00.0: GPU lockup - switching to software fbcon
Oct 24 10:15:37 rhn kernel: [ 7.491162] fb0: nouveaufb frame buffer device
Oct 24 10:15:37 rhn kernel: [ 7.491299] drm: registered panic notifier
Oct 24 10:15:37 rhn kernel: [ 7.491448] [drm] Initialized nouveau 0.0.16 20090420 for 0000:02:00.0 on minor 0
Oct 24 10:15:37 rhn kernel: [ 8.579524] Adding 1004056k swap on /dev/sda2. Priority:-1 extents:1 across:1004056k
Oct 24 10:15:37 rhn kernel: [ 8.922670] EXT3-fs (sda3): using internal journal
Oct 24 10:15:37 rhn kernel: [ 9.049874] NTFS driver 2.1.30 [Flags: R/W MODULE].
Oct 24 10:15:37 rhn kernel: [ 9.267336] usbcore: registered new interface driver libusual
Oct 24 10:15:37 rhn kernel: [ 9.273492] Initializing USB Mass Storage driver...
Oct 24 10:15:37 rhn kernel: [ 9.274487] usbcore: registered new interface driver usb-storage
Oct 24 10:15:37 rhn kernel: [ 9.274701] USB Mass Storage support registered.
Oct 24 10:15:37 rhn kernel: [ 9.340665] smsc47m1: Found SMSC LPC47M10x/LPC47M112/LPC47M13x
Oct 24 10:15:37 rhn kernel: [ 10.712719] kjournald starting. Commit interval 5 seconds
Oct 24 10:15:37 rhn kernel: [ 10.726569] EXT3-fs (sda4): using internal journal
Oct 24 10:15:37 rhn kernel: [ 10.740223] EXT3-fs (sda4): mounted filesystem with writeback data mode
Oct 24 10:15:37 rhn kernel: [ 11.580186] NET: Registered protocol family 8
Oct 24 10:15:37 rhn kernel: [ 11.593559] NET: Registered protocol family 20
Oct 24 10:15:37 rhn kernel: [ 12.703108] NET: Registered protocol family 10
Oct 24 10:15:37 rhn kernel: [ 13.037192] ADDRCONF(NETDEV_UP): eth0: link is not ready
Oct 24 10:15:37 rhn kernel: [ 13.050493] e100 0000:01:08.0: eth0: NIC Link is Up 100 Mbps Full Duplex
Oct 24 10:15:37 rhn kernel: [ 13.063787] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Oct 24 10:15:37 rhn kernel: [ 17.177677] RPC: Registered named UNIX socket transport module.
Oct 24 10:15:37 rhn kernel: [ 17.190795] RPC: Registered udp transport module.
Oct 24 10:15:37 rhn kernel: [ 17.203745] RPC: Registered tcp transport module.
Oct 24 10:15:37 rhn kernel: [ 17.216538] RPC: Registered tcp NFSv4.1 backchannel transport module.
Oct 24 10:15:37 rhn kernel: [ 17.307746] Registering the id_resolver key type
Oct 24 10:15:37 rhn kernel: [ 17.354657] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Oct 24 10:15:37 rhn kernel: [ 18.324697] fuse init (API version 7.17)
Oct 24 10:15:37 rhn kernel: [ 19.768635] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
Oct 24 10:15:37 rhn kernel: [ 19.808415] NFSD: starting 90-second grace period
Oct 24 10:15:37 rhn kernel: [ 20.329615] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input4
Oct 24 10:15:37 rhn kernel: [ 23.480028] eth0: no IPv6 routers present
Oct 24 10:15:37 rhn kernel: [ 25.644613] nouveau_ratelimit: 211782 callbacks suppressed
Oct 24 10:15:37 rhn kernel: [ 25.644628] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: DATA_ERROR nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:37 rhn kernel: [ 25.644648] [drm] nouveau 0000:02:00.0: PGRAPH - ch 1/7 class 0x0042 mthd 0x0304 data 0x20002000
Oct 24 10:15:37 rhn kernel: [ 25.644658] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:37 rhn kernel: [ 25.644676] [drm] nouveau 0000:02:00.0: PGRAPH - ch 1/2 class 0x005f mthd 0x0308 data 0x06000800
Oct 24 10:15:37 rhn kernel: [ 25.670888] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: DATA_ERROR nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:37 rhn kernel: [ 25.670908] [drm] nouveau 0000:02:00.0: PGRAPH - ch 1/7 class 0x0042 mthd 0x0304 data 0x20002000
Oct 24 10:15:37 rhn kernel: [ 26.068702] lp0: using parport0 (interrupt-driven).
Oct 24 10:15:37 rhn kernel: [ 26.183787] ppdev: user-space parallel port driver
Oct 24 10:15:37 rhn kernel: [ 27.130516] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: DATA_ERROR nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:37 rhn kernel: [ 27.130547] [drm] nouveau 0000:02:00.0: PGRAPH - ch 1/7 class 0x0042 mthd 0x0304 data 0x20002000
Oct 24 10:15:37 rhn kernel: [ 27.130558] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:37 rhn kernel: [ 27.130576] [drm] nouveau 0000:02:00.0: PGRAPH - ch 1/3 class 0x004a mthd 0x0404 data 0x08000600
Oct 24 10:15:37 rhn kernel: [ 28.732658] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: DATA_ERROR nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:37 rhn kernel: [ 28.732688] [drm] nouveau 0000:02:00.0: PGRAPH - ch 1/7 class 0x0042 mthd 0x0304 data 0x20002000
Oct 24 10:15:37 rhn kernel: [ 28.872199] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: DATA_ERROR nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:37 rhn kernel: [ 28.872230] [drm] nouveau 0000:02:00.0: PGRAPH - ch 1/7 class 0x0042 mthd 0x0304 data 0x20002000
Oct 24 10:15:37 rhn kernel: [ 28.872240] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:37 rhn kernel: [ 28.872258] [drm] nouveau 0000:02:00.0: PGRAPH - ch 1/3 class 0x004a mthd 0x0404 data 0x08000600
Oct 24 10:15:37 rhn kernel: [ 28.885315] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: DATA_ERROR nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:37 rhn kernel: [ 28.885344] [drm] nouveau 0000:02:00.0: PGRAPH - ch 1/7 class 0x0042 mthd 0x0304 data 0x20002000
Oct 24 10:15:53 rhn kernel: [ 49.724653] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: DATA_ERROR nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:53 rhn kernel: [ 49.724684] [drm] nouveau 0000:02:00.0: PGRAPH - ch 1/7 class 0x0042 mthd 0x0304 data 0x20002000
Oct 24 10:15:53 rhn kernel: [ 49.724694] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:53 rhn kernel: [ 49.724712] [drm] nouveau 0000:02:00.0: PGRAPH - ch 1/3 class 0x004a mthd 0x0404 data 0x00010011
Oct 24 10:15:53 rhn kernel: [ 49.730472] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: DATA_ERROR nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:53 rhn kernel: [ 49.730502] [drm] nouveau 0000:02:00.0: PGRAPH - ch 1/7 class 0x0042 mthd 0x0304 data 0x20002000
Oct 24 10:15:53 rhn kernel: [ 49.730512] [drm] nouveau 0000:02:00.0: PGRAPH - NOTIFY nsource: STATE_INVALID nstatus: INVALID_STATE BAD_ARGUMENT
Oct 24 10:15:53 rhn kernel: [ 49.730530] [drm] nouveau 0000:02:00.0: PGRAPH - ch 1/3 class 0x004a mthd 0x0404 data 0x00010011
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: Vanilla-Kernel 3 - page allocation failure
From: Eric Dumazet @ 2011-10-24 8:01 UTC (permalink / raw)
To: p.herz; +Cc: David Rientjes, Andi Kleen, s.priebe, linux-kernel
In-Reply-To: <4EA51210.9070209@profihost.ag>
Le lundi 24 octobre 2011 à 09:21 +0200, Philipp Herz - Profihost AG a
écrit :
> does that mean that there was no firmware limitation with kernel 2.6.32
> or that the tg3 module has any "disable warnings" flag matching
> __GFP_NOWARN?
>
There is no __GFP_NOWARN trick on tg3.
We tend to prefer to be notified of a memory problem, instead of
hide ...
By the way, apparently this driver drops the frame and doesnt increase
tx_dropped device counter. A patch will follow.
Could you post your full dmesg ?
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe
From: Kevin Wolf @ 2011-10-24 8:05 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: Alexander Graf, qemu-devel, avi
In-Reply-To: <4EA425B7.2030708@redhat.com>
Am 23.10.2011 16:33, schrieb Paolo Bonzini:
> On 10/22/2011 05:07 PM, Alexander Graf wrote:
>>
>> On 21.10.2011, at 11:44, Paolo Bonzini wrote:
>>
>>> On 10/21/2011 07:08 PM, Kevin Wolf wrote:
>>>> Avi complained that not even writing out qcow2's cache on
>>>> bdrv_flush() made cache=unsafe too unsafe to be useful. He's got
>>>> a point.
>>>
>>> Why? cache=unsafe is explicitly allowing to s/data/manure/ on
>>> crash.
>>
>> Exactly, but not on kill. By not flushing internal caches you're
>> almost guaranteed to get an inconsistent qcow2 image.
>
> This should be covered already by termsig_handler. bdrv_close_all
> closes all block devices, and qcow2_close does flush the caches.
>
> SIGKILL doesn't give any guarantee of course but it does not in general,
> even without cache=unsafe; you might get a SIGKILL "a moment before" a
> bdrv_flush even without cache=unsafe, and get unclean qcow2 metadata.
Unclean yes, in the sense that you may get cluster leaks. If getting
SIGKILL "a moment before" the flush led to real corruption however,
cache=none would be broken as well.
>> By not flushing internal caches you're almost guaranteed to get an
>> inconsistent qcow2 image.
>
> Of course the inconsistencies with cache=unsafe will be massive if you
> don't have a clean exit, but that's expected. If in some cases you want
> a clean exit, but right now you don't, the place to fix those cases
> doesn't seem to be the block layer, but the main loop.
I don't think there's much the main loop can do against SIGKILL,
segfaults or abort().
> Also,
>
> 1) why should cache=unsafe differentiate an OS that sends a flush from
> one that doesn't (e.g. MS-DOS), from the point of view of image metadata?
>
> 2) why should the guest actually send a flush if cache=unsafe? Currently
>
> if (flags & BDRV_O_CACHE_WB)
> bs->enable_write_cache = 1;
>
> covers cache=unsafe. However, in the end write cache enable means "do I
> need to flush data", and the answer is "no" when cache=unsafe, because
> the flushes are useless and guests are free to reorder requests.
>
> <shot-in-the-dark>Perhaps what you want is to make qcow2 caches
> writethrough in cache=unsafe mode, so that at least a try is made to
> write the metadata</shot-in-the-dark> (even though the underlying raw
> protocol won't flush it)? I'm not sure that is particularly useful, but
> maybe it can help me understanding the benefit of this change.
Yes, this is the intention. It's about flushing metadata, not guest
data. The semantics that I think cache=unsafe should have is that after
a bdrv_flush() we have flushed all caches in qemu (so that the image
survives a qemu crash), but we don't care about flushing the host page
cache.
Kevin
^ permalink raw reply
* Re: [PATCH v2 6/6] slub: only preallocate cpus_with_slabs if offstack
From: Gilad Ben-Yossef @ 2011-10-24 8:02 UTC (permalink / raw)
To: Andi Kleen
Cc: lkml, Peter Zijlstra, Frederic Weisbecker, Russell King, linux-mm,
Christoph Lameter, Pekka Enberg, Matt Mackall, Sasha Levin
In-Reply-To: <m2obx755md.fsf@firstfloor.org>
On Mon, Oct 24, 2011 at 7:19 AM, Andi Kleen <andi@firstfloor.org> wrote:
>
> Gilad Ben-Yossef <gilad@benyossef.com> writes:
>
> > We need a cpumask to track cpus with per cpu cache pages
> > to know which cpu to whack during flush_all. For
> > CONFIG_CPUMASK_OFFSTACK=n we allocate the mask on stack.
> > For CONFIG_CPUMASK_OFFSTACK=y we don't want to call kmalloc
> > on the flush_all path, so we preallocate per kmem_cache
> > on cache creation and use it in flush_all.
>
> What's the problem with calling kmalloc in flush_all?
> That's a slow path anyways, isn't it?
>
> I believe the IPI functions usually allocate anyways.
>
> So maybe you can do that much simpler.
That was what the first version of the patch did (use
alloc_cpumask_var in flush_all).
Pekka Enberg pointed out that calling kmalloc on the kmem_cache
shrinking code path is not a good idea
and it does sound like a deadlock waiting to happen.
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
gilad@benyossef.com
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com
"I've seen things you people wouldn't believe. Goto statements used to
implement co-routines. I watched C structures being stored in
registers. All those moments will be lost in time... like tears in
rain... Time to die. "
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* RE: No linkage from /sys entries for a given scsi_host to its PCI device details?
From: James Bottomley @ 2011-10-24 8:03 UTC (permalink / raw)
To: Sampathkumar, Kishore; +Cc: linux-scsi@vger.kernel.org
In-Reply-To: <E4D7778E36CF944ABD2F7E18D2DB9666271B897A1B@inbmail02.lsi.com>
On Mon, 2011-10-24 at 13:20 +0530, Sampathkumar, Kishore wrote:
> From the above, there is no linkage to the PCI device corresponding to
> the above host controller. The only way I could establish the linkage
> was to actually start from the PCI device ID for this controller, and
> then, doing the following:
I do
ls -l /sys/class/scsi_host
To get this:
lrwxrwxrwx 1 root root 0 Oct 24 09:25 host0
-> ../../devices/pci0000:00/0000:00:1f.2/host0/scsi_host/host0/
lrwxrwxrwx 1 root root 0 Oct 24 09:25 host1
-> ../../devices/pci0000:00/0000:00:1f.2/host1/scsi_host/host1/
lrwxrwxrwx 1 root root 0 Oct 24 09:25 host2
-> ../../devices/pci0000:00/0000:00:1f.2/host2/scsi_host/host2/
lrwxrwxrwx 1 root root 0 Oct 24 09:25 host3
-> ../../devices/pci0000:00/0000:00:1f.2/host3/scsi_host/host3/
lrwxrwxrwx 1 root root 0 Oct 24 09:25 host4
-> ../../devices/pci0000:00/0000:00:1f.2/host4/scsi_host/host4/
lrwxrwxrwx 1 root root 0 Oct 24 09:25 host5
-> ../../devices/pci0000:00/0000:00:1f.2/host5/scsi_host/host5/
Which allows an easy link back.
James
^ permalink raw reply
* Re: [systemd-devel] systemd kills mdmon if it was started manually by user
From: Thomas Jarosch @ 2011-10-24 8:04 UTC (permalink / raw)
To: Dan Williams
Cc: Lennart Poettering, Andrey Borzenkov, Tomasz Torcz, systemd-devel,
linux-raid, NeilBrown
In-Reply-To: <CAA9_cmfhUyenz2B1=wDsUtKcrj-5uOURproUemje37bPpM4-Qw@mail.gmail.com>
On Sunday, 23. October 2011 10:00:36 Dan Williams wrote:
> Is it time for a libmd.so, so systemd can invoke the "--wait-clean --scan"
> process itself? Probably simpler to just SIGTERM mdmon and wait for it.
The mdadm code makes good use of non-reentrant functions like ctime(),
readdir() and others. Luckily systemd is single threaded.
If we provide a "public" interface, that would need fixing though.
Cheers,
Thomas
^ permalink raw reply
* Fwd: [PATCH v2 6/6] slub: only preallocate cpus_with_slabs if offstack
From: Gilad Ben-Yossef @ 2011-10-24 8:05 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <CAOtvUMfVFV3_2wtT-qNpcHxzsTW-1j3wGUqt+O5GhayZHxW1mg@mail.gmail.com>
[Re-sending to the list due to some foul up with LKML address on my part]
On Mon, Oct 24, 2011 at 7:19 AM, Andi Kleen <andi@firstfloor.org> wrote:
>
> Gilad Ben-Yossef <gilad@benyossef.com> writes:
>
> > We need a cpumask to track cpus with per cpu cache pages
> > to know which cpu to whack during flush_all. For
> > CONFIG_CPUMASK_OFFSTACK=n we allocate the mask on stack.
> > For CONFIG_CPUMASK_OFFSTACK=y we don't want to call kmalloc
> > on the flush_all path, so we preallocate per kmem_cache
> > on cache creation and use it in flush_all.
>
> What's the problem with calling kmalloc in flush_all?
> That's a slow path anyways, isn't it?
>
> I believe the IPI functions usually allocate anyways.
>
> So maybe you can do that much simpler.
That was what the first version of the patch did (use
alloc_cpumask_var in flush_all).
Pekka Enberg pointed out that calling kmalloc on the kmem_cache
shrinking code path is not a good idea
and it does sound like a deadlock waiting to happen.
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
gilad@benyossef.com
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com
"I've seen things you people wouldn't believe. Goto statements used to
implement co-routines. I watched C structures being stored in
registers. All those moments will be lost in time... like tears in
rain... Time to die. "
--
Gilad Ben-Yossef
Chief Coffee Drinker
gilad@benyossef.com
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com
"I've seen things you people wouldn't believe. Goto statements used to
implement co-routines. I watched C structures being stored in
registers. All those moments will be lost in time... like tears in
rain... Time to die. "
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Ulf Hansson @ 2011-10-24 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAgDR1OT=+xgQTNwmTz=9XwzpbhjeZ6F-mxnVGhOAPSAR3JiFQ@mail.gmail.com>
Sebastian Rasmussen wrote:
> Hi!
>
>> Err, no. You're not allowed to power down the card between commands
>> unless the card has been removed or been has finished with.
>>
>> If you power down the card (which you _are_ doing by writing zero to
>> the MMCIPOWER register), then you have to do a full setup of the card
>> when you resume.
>
> MCIPower is according to ARM PL180 TRM signalling to an external power
> supply to turn on/off (MCIPWR), whether to use open-drain (MCIROD),
> what voltage to use (MCIVDD) and whether the card is clocked (MCICLK).
>
> According ST-Ericsson's public PL180 derivative spec[1] it seems to work
> roughly in same way (but renaming the register SDI_PWR and the signals
> SDIPWR & SDICLK). However, there is no SDIVDD as the derivative can not
> signal desired voltage level externally (there are no bits in SDI_PWR for this).
> This makes it plausible that SDIPWR may not be routed externally either.
> Can you verify this as there are no signal routing diagrams in the spec..?
>
The hole idea with this PM patch is to make sure the vcore regulator and
the clock are disabled in runtime_suspend to be able to save a huge
amount of current in "idle" mode.
Disabling the vcore regulator will sooner or later (depending on your
regulator tree) mean that that power to the controller is actually cut,
which then means that all registers will be "cleared" including the
MCIPWR. So the actual reason for clearing the registers in the
runtime_suspend function is because of two reasons.
1. Set the controller in a known state so no "magic" things happens when
we are runtime suspended, for example getting an IRQ.
2. Save power by disabling the clock etc. The actual power to the
controller does not have to be cut just because we have disabled the
vore regulator.
If the ARM PL180 TRM prevent us from from doing this kind of operations
in runtime_suspend, we must think of an alternative solution which just
apply for ST-Ericssons derivative of PL180. THIS IS VERY IMPORTANT to be
able to implement a proper power management solution.
Please check this Russell, this is VERY IMPORTANT!
> This leads me to believe that writing 0 to SDI_PWR/MMC in actual practice
> doesn't really do much but disabling the clock to the card (and for
> ST-Ericsson's PL180, disable direction signalling to the external level
> shifter). Clearing bit 8 of MCIClock/SDI_CLKCR also disables the clock.
>
> I guess the patch would appeal more to Russell if mmci_runtime_suspend()
> only cleared MCIMask0/SDI_MASK0 and MCIClock/SDI_CLKCR and left
> MCIPower/SDI_PWR unchanged. It may be the case that the signal direction
> bits need to be cleared for the ST-Ericsson PL180, but I haven't yet verified
> this on my Snowball dev board yet.
This is according the comment above not feasible, since the vcore
regulator to the controller is disabled all registers will be "cleared"
anyway.
>
> / Sebastian
>
> [1] http://www.stericsson.com/developers/DM00030004_AP9500_reference_manual_rev1.pdf
>
BR
Ulf Hansson
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.