Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51
[The full log for this bug is at http://bugs.debian.org/677472]
On Thu, 2012-06-14 at 09:28 -0700, Octavio Alvarez wrote:
> Under normal circumstances the system simply does not suspend. It appears
> to go all the way to suspension (screen off, disks off, etc.) but when it
> appears that it is going to go off, something prevents it. System doesn't
> hang, it just fails at the very last moment of suspension.
>
> I tried debugging using pm_test. I set it to "core" but suspend_stats
> doesn't catch anything:
>
> # cat /sys/kernel/debug/suspend_stats
> success: 12
> fail: 0
> failed_freeze: 0
> failed_prepare: 0
> failed_suspend: 0
> failed_suspend_noirq: 0
> failed_resume: 0
> failed_resume_noirq: 0
> failures:
> last_failed_dev:
>
> last_failed_errno: 0
> 0
> last_failed_step:
>
> Even with pm_test set to "none", suspend_stats increases the "success"
> value.
This indicates that the system is woken up immediately after it
suspends. From the kernel point of view (but not a practical point of
view!) this is different from failing to suspend.
> As I said earlier, removing ohci_hcd lets suspend work again.
So the USB controller (OHCI) has for some reason started waking up the
system. As I suspected, this system has an Nvidia chipset:
00:0b.0 USB controller [0c03]: NVIDIA Corporation MCP51 USB Controller [10de:026d] (rev a2) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc. A8N-VM CSM Mainboard [1043:81bc]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 23
Region 0: Memory at d5006000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <access denied>
Kernel driver in use: ohci_hcd
The Nvidia implementation of OHCI is unusual in some ways and has
prompted a number of changes to power management. The last one was:
commit c61875977458637226ab093a35d200f2d5789787
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Thu Nov 17 16:41:45 2011 -0500
OHCI: final fix for NVIDIA problems (I hope)
But it looks like we have to disappoint Alan again.
Ben.
> Also, I didn't find anything wrong in /var/log/pm-suspend.log. I may paste
> it in another message if you want because it's 4000 lines long.
--
Ben Hutchings
I say we take off; nuke the site from orbit. It's the only way to be sure.
06-25-2012, 02:33 PM
Alan Stern
Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51
On Sun, 24 Jun 2012, Ben Hutchings wrote:
> [The full log for this bug is at http://bugs.debian.org/677472]
>
> On Thu, 2012-06-14 at 09:28 -0700, Octavio Alvarez wrote:
> > Under normal circumstances the system simply does not suspend. It appears
> > to go all the way to suspension (screen off, disks off, etc.) but when it
> > appears that it is going to go off, something prevents it. System doesn't
> > hang, it just fails at the very last moment of suspension.
> >
> > I tried debugging using pm_test. I set it to "core" but suspend_stats
> > doesn't catch anything:
> >
> > # cat /sys/kernel/debug/suspend_stats
> > success: 12
> > fail: 0
> > failed_freeze: 0
> > failed_prepare: 0
> > failed_suspend: 0
> > failed_suspend_noirq: 0
> > failed_resume: 0
> > failed_resume_noirq: 0
> > failures:
> > last_failed_dev:
> >
> > last_failed_errno: 0
> > 0
> > last_failed_step:
> >
> > Even with pm_test set to "none", suspend_stats increases the "success"
> > value.
>
> This indicates that the system is woken up immediately after it
> suspends. From the kernel point of view (but not a practical point of
> view!) this is different from failing to suspend.
>
> > As I said earlier, removing ohci_hcd lets suspend work again.
>
> So the USB controller (OHCI) has for some reason started waking up the
> system. As I suspected, this system has an Nvidia chipset:
>
> 00:0b.0 USB controller [0c03]: NVIDIA Corporation MCP51 USB Controller [10de:026d] (rev a2) (prog-if 10 [OHCI])
> Subsystem: ASUSTeK Computer Inc. A8N-VM CSM Mainboard [1043:81bc]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0 (750ns min, 250ns max)
> Interrupt: pin A routed to IRQ 23
> Region 0: Memory at d5006000 (32-bit, non-prefetchable) [size=4K]
> Capabilities: <access denied>
> Kernel driver in use: ohci_hcd
>
> The Nvidia implementation of OHCI is unusual in some ways and has
> prompted a number of changes to power management. The last one was:
>
> commit c61875977458637226ab093a35d200f2d5789787
> Author: Alan Stern <stern@rowland.harvard.edu>
> Date: Thu Nov 17 16:41:45 2011 -0500
>
> OHCI: final fix for NVIDIA problems (I hope)
Actually that wasn't exactly a power management change, although it was
vaguely related. It really was more concerned with initialization and
shutdown.
> But it looks like we have to disappoint Alan again.
Well, this sounds like a different problem.
What happens if Octavio disables wakeup for that controller before
suspending?
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.LNX.4.44L0.1206251025280.1770-100000@iolanthe.rowland.org">http://lists.debian.org/Pine.LNX.4.44L0.1206251025280.1770-100000@iolanthe.rowland.org
06-25-2012, 05:33 PM
"Octavio Alvarez"
Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51
On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern <stern@rowland.harvard.edu>
wrote:
What happens if Octavio disables wakeup for that controller before
suspending?
For kernel 3.4, I'll break it into two parts: the going asleep and the
wakening back.
For the going asleep part, it works just like 3.2. It previously went
"almost" asleep, but with "echo disabled > wakeup" it suspends correctly.
For the wakening back part, with both settings the PC locks up requiring a
mechanical (power supply switch) power cycle to bring the computer back.
Not even the 5-sec power button cycle helps. I guess this is a different
bug, so I'll try to troubleshoot it and open a different one.
--
Octavio.
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/op.wggy1mix6g6bxc@alvarezp-ws
06-25-2012, 06:41 PM
Alan Stern
Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51
On Mon, 25 Jun 2012, Octavio Alvarez wrote:
> On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern <stern@rowland.harvard.edu>
> wrote:
>
> > What happens if Octavio disables wakeup for that controller before
> > suspending?
> >
> > echo disabled >/sys/bus/pci/devices/0000:00:0b.0/power/wakeup
>
> On kernel 3.2, it lets suspend work again.
It might be worthwhile tracking down the reason for the immediate
wakeup. If you build a kernel with CONFIG_USB_DEBUG enabled, what
shows up in /sys/kernel/debug/usb/ohci/*/registers? And what shows up
in /sys/kernel/debug/usb/devices?
Also, what does the "lspci -vv" output show for the controller if you
run it with superuser permissions?
> For kernel 3.4, I'll break it into two parts: the going asleep and the
> wakening back.
>
> For the going asleep part, it works just like 3.2. It previously went
> "almost" asleep, but with "echo disabled > wakeup" it suspends correctly.
>
> For the wakening back part, with both settings the PC locks up requiring a
> mechanical (power supply switch) power cycle to bring the computer back.
> Not even the 5-sec power button cycle helps. I guess this is a different
> bug, so I'll try to troubleshoot it and open a different one.
And yet the PC doesn't lock up if you unbind ohci-hcd before
suspending?
Maybe you can do a git bisection to find what changed between 3.2 and
3.4 to cause this behavior.
Alan Stern
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.LNX.4.44L0.1206251437040.1770-100000@iolanthe.rowland.org">http://lists.debian.org/Pine.LNX.4.44L0.1206251437040.1770-100000@iolanthe.rowland.org
06-28-2012, 03:27 AM
Jonathan Nieder
Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51
Hi Octavio,
Quick instructions:
Alan Stern wrote:
> It might be worthwhile tracking down the reason for the immediate
> wakeup. If you build a kernel with CONFIG_USB_DEBUG enabled, what
> shows up in /sys/kernel/debug/usb/ohci/*/registers? And what shows up
> in /sys/kernel/debug/usb/devices?
0. prerequisites:
apt-get install git build-essential
1. get the kernel history, if you don't already have it:
cd linux
git remote add stable
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git fetch stable
3. configure, build:
git checkout stable/linux-3.2.y
cp /boot/config-$(uname -r) .config; # current configuration
scripts/config --disable DEBUG_INFO
make localmodconfig; # optional: minimize configuration
scripts/config --enable USB_DEBUG
make deb-pkg; # optionally with -j<num> for parallel build
4. test:
dpkg -i ../<name of package>; # as root
reboot
mount -t debugfs debugfs /sys/kernel/debug
grep .
/sys/kernel/debug/usb/ohci/*/registers
/sys/kernel/debug/usb/devices
> Also, what does the "lspci -vv" output show for the controller if you
> run it with superuser permissions?
This one's easier (no rebuild necessary).
>> For kernel 3.4, I'll break it into two parts: the going asleep and the
>> wakening back.
[...]
>> For the wakening back part, with both settings the PC locks up requiring a
>> mechanical (power supply switch) power cycle to bring the computer back.
>> Not even the 5-sec power button cycle helps. I guess this is a different
>> bug, so I'll try to troubleshoot it and open a different one.
[...]
> Maybe you can do a git bisection to find what changed between 3.2 and
> 3.4 to cause this behavior.
This works like so:
cd linux
git bisect start v3.4.1 stable/linux-3.2.y
# git checkouts out a version halfway between to test, so try it:
make deb-pkg; # maybe with -j4
dpkg -i ../<name of package>; # as root
reboot
... test test test ...
cd linux
git bisect bad; # if resume locks up
git bisect good; # if it resumes fine
git bisect skip; # if some other bug makes it hard to test
# git checks out a version halfway between to test, so:
make deb-pkg; # maybe with -j4
dpkg -i ../<name of package>; # as root
... and so on ...
After enough cycles it will find the "first bad commit". If you get
bored before then:
# if the gitk package is installed,
# to see the current regression range narrowing at any step
git bisect visualize
# to print a log of tests you've run so far, which lets someone
# else pick up where you left off
git bisect log
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120628032731.GB3657@burratino
07-07-2012, 08:18 PM
"Octavio Alvarez"
Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51
Hi, Alan!
So, after about more than a week of bisecting, and thanks to Jonathan
Nieder's
more-than-precise instructions, the results are in.
On Mon, 25 Jun 2012 11:41:31 -0700, Alan Stern <stern@rowland.harvard.edu>
wrote:
On Mon, 25 Jun 2012, Octavio Alvarez wrote:
On Mon, 25 Jun 2012 07:33:11 -0700, Alan Stern
<stern@rowland.harvard.edu>
wrote:
> What happens if Octavio disables wakeup for that controller before
> suspending?
>
> echo disabled >/sys/bus/pci/devices/0000:00:0b.0/power/wakeup
On kernel 3.2, it lets suspend work again.
If you build a kernel with CONFIG_USB_DEBUG enabled, what
shows up in /sys/kernel/debug/usb/ohci/*/registers?
This patch (as1486) implements the kernel's new wakeup policy for USB
host controllers. Since they don't generate wakeup requests on their
but merely forward requests from their root hubs toward the CPU, they
should be enabled for wakeup by default.
Also, to be compliant with both the old and new policies, root hubs
should not be enabled for remote wakeup by default. Userspace must
enable it explicitly if it is desired.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
For the [3.4] wakening back part, with both settings the PC locks up
requiring a
mechanical (power supply switch) power cycle to bring the computer back.
Not even the 5-sec power button cycle helps. I guess this is a different
bug, so I'll try to troubleshoot it and open a different one.
And yet the PC doesn't lock up if you unbind ohci-hcd before
suspending?
It suspends but it locks-up while waking up.
Maybe you can do a git bisection to find what changed between 3.2 and
3.4 to cause this behavior.
commit 2feec47d4c5f80b05f1650f5a24865718978eea4
Author: Bob Moore <robert.moore@intel.com>
Date: Tue Feb 14 15:00:53 2012 +0800
ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl
registers
Adds sleep and wake support for systems with these registers.
One new file, hwxfsleep.c
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
--
Octavio.
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/op.wg3en6ij6g6bxc@localhost.localdomain
07-08-2012, 02:23 AM
Alan Stern
Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51
On Sat, 7 Jul 2012, Octavio Alvarez wrote:
> > If you build a kernel with CONFIG_USB_DEBUG enabled, what
> > shows up in /sys/kernel/debug/usb/ohci/*/registers?
>
> [Sat Jul 07 12:49:27 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
> $ grep . ohci/*/registers
> bus pci, device 0000:00:0b.0
> OHCI Host Controller
> ohci_hcd
> OHCI 1.0, NO legacy support registers, rh state running
> control 0x68f RWE RWC HCFS=operational IE PLE CBSR=3
> cmdstatus 0x00000 SOC=0
> intrstatus 0x00000024 FNO SF
> intrenable 0x8000004a MIE RHSC RD WDH
> ed_controlhead 2edac040
> hcca frame 0x5fce
> fmintvl 0xa7782edf FIT FSMPS=0xa778 FI=0x2edf
> fmremaining 0x80002e53 FRT FR=0x2e53
> periodicstart 0x2a2f
> lsthresh 0x0628
> hub poll timer off
> roothub.a 01000208 POTPGT=1 NPS NDP=8(8)
> roothub.b 00000000 PPCM=0000 DR=0000
> roothub.status 00008000 DRWE
> roothub.portstatus [0] 0x00000100 PPS
> roothub.portstatus [1] 0x00000100 PPS
> roothub.portstatus [2] 0x00000100 PPS
> roothub.portstatus [3] 0x00000100 PPS
> roothub.portstatus [4] 0x00000303 LSDA PPS PES CCS
> roothub.portstatus [5] 0x00000303 LSDA PPS PES CCS
> roothub.portstatus [6] 0x00000101 PPS CCS
> roothub.portstatus [7] 0x00000100 PPS
That's normal, except for the status of port 6 (which actually is port
7, since we normally count ports starting from 1). The port shows
Current Connect Status, so something is connected to it -- but what?
Can you post a complete dmesg log showing bootup with CONFIG_USB_DEBUG
enabled?
> > And what shows up in /sys/kernel/debug/usb/devices?
>
> [Sat Jul 07 12:49:54 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
> $ cat devices
...
Pretty much normal.
> > Also, what does the "lspci -vv" output show for the controller if you
> > run it with superuser permissions?
>
> [Sat Jul 07 12:50:10 -0700 -- alvarezp@octavio:/sys/kernel/debug/usb]
> $ sudo lspci -vv -s 0000:00:0b.1
0b.1 is the EHCI controller. We want to see the OHCI controller, 0b.0.
> I also bisected the "3.2 doesn't sleep due to ohci" problem and found this:
>
> commit a6eeeb9f45b5a417f574f3bc799b7122270bf59b
> Author: Alan Stern <stern@rowland.harvard.edu>
> Date: Mon Sep 26 11:23:38 2011 -0400
>
> USB: Update USB default wakeup settings
Yes, that commit enables wakeup for USB host controllers by default.
Before that, you had to enable wakeup by hand. The question is: Why
does the controller think it needs to wake up the system?
Can you also post a dmesg log showing a full suspend/immediate-resume
cycle with CONFIG_USB_DEBUG enabled?
> > And yet the PC doesn't lock up if you unbind ohci-hcd before
> > suspending?
>
> It suspends but it locks-up while waking up.
>
> > Maybe you can do a git bisection to find what changed between 3.2 and
> > 3.4 to cause this behavior.
>
> commit 2feec47d4c5f80b05f1650f5a24865718978eea4
> Author: Bob Moore <robert.moore@intel.com>
> Date: Tue Feb 14 15:00:53 2012 +0800
>
> ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl
> registers
>
> Adds sleep and wake support for systems with these registers.
> One new file, hwxfsleep.c
>
> Signed-off-by: Bob Moore <robert.moore@intel.com>
> Signed-off-by: Len Brown <len.brown@intel.com>
Yes, okay, that is indeed totally separate. You should bring that
issue up with Bob Moore and Len Brown on the linux-acpi mailing list.
Alan Stern
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: Pine.LNX.4.44L0.1207072208270.508-100000@netrider.rowland.org">http://lists.debian.org/Pine.LNX.4.44L0.1207072208270.508-100000@netrider.rowland.org
07-08-2012, 02:57 AM
Jonathan Nieder
Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51
Hi,
Quick administrivia.
Alan Stern wrote:
> Yes, that commit enables wakeup for USB host controllers by default.
> Before that, you had to enable wakeup by hand. The question is: Why
> does the controller think it needs to wake up the system?
Yotam Benshalom from https://bugzilla.kernel.org/show_bug.cgi?id=43081
(cc-ed) is experiencing the same symptoms (Nvidia MCP79 OHCI
controller producing immediate wakeups when he tries to resume,
bisects to a6eeeb9f45b5).
> On Sat, 7 Jul 2012, Octavio Alvarez wrote:
>> commit 2feec47d4c5f80b05f1650f5a24865718978eea4
>> Author: Bob Moore <robert.moore@intel.com>
>> Date: Tue Feb 14 15:00:53 2012 +0800
>>
>> ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl
>> registers
[...]
> Yes, okay, that is indeed totally separate. You should bring that
> issue up with Bob Moore and Len Brown on the linux-acpi mailing list.
The Debian bug for this one is <http://bugs.debian.org/680707>.
Please cc me or 680707@bugs.debian.org if bringing it up with ACPI
folks so we can track the discussion.
Thanks again for your hard work.
Ciao,
Jonathan
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20120708025730.GE2961@burratino
07-08-2012, 03:47 AM
"Octavio Alvarez"
Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51
On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern <stern@rowland.harvard.edu>
wrote:
> Also, what does the "lspci -vv" output show for the controller if you
> run it with superuser permissions?
Yes, that commit enables wakeup for USB host controllers by default.
Before that, you had to enable wakeup by hand. The question is: Why
does the controller think it needs to wake up the system?
Can you also post a dmesg log showing a full suspend/immediate-resume
cycle with CONFIG_USB_DEBUG enabled?
Will do as soon as I reboot into a suitable kernel.
Thanks for your help.
--
Octavio.
--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/op.wg3zgrst6g6bxc@localhost.localdomain
07-08-2012, 06:36 AM
"Octavio Alvarez"
Bug#677472: Immediate wake on suspend, associated with OHCI on MCP51
On Sat, 07 Jul 2012 19:23:08 -0700, Alan Stern <stern@rowland.harvard.edu>
wrote:
roothub.portstatus [4] 0x00000303 LSDA PPS PES CCS
roothub.portstatus [5] 0x00000303 LSDA PPS PES CCS
roothub.portstatus [6] 0x00000101 PPS CCS
That's normal, except for the status of port 6 (which actually is port
7, since we normally count ports starting from 1). The port shows
Current Connect Status, so something is connected to it -- but what?
It looks like it was my pendrive. Disconnecting the mouse and keyboard
cleared CCS on [4] and [5] (not necesariliy in that order).
[ 0.088604] ACPI: Interpreter enabled
[ 0.088621] ACPI: (supports S0 S1 S3 S4 S5)
[ 0.088648] ACPI: Using IOAPIC for interrupt routing
[ 0.096193] ACPI: No dock devices found.
[ 0.096202] PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug
[ 0.174609] pnp 00:01: [io 0x4000-0x407f]
[ 0.174612] pnp 00:01: [io 0x4080-0x40ff]
[ 0.174614] pnp 00:01: [io 0x4400-0x447f]
[ 0.174617] pnp 00:01: [io 0x4480-0x44ff]
[ 0.174619] pnp 00:01: [io 0x4800-0x487f]
[ 0.174622] pnp 00:01: [io 0x4880-0x48ff]
[ 0.174695] system 00:01: [io 0x4000-0x407f] has been reserved
[ 0.174699] system 00:01: [io 0x4080-0x40ff] has been reserved
[ 0.174702] system 00:01: [io 0x4400-0x447f] has been reserved
[ 0.174706] system 00:01: [io 0x4480-0x44ff] has been reserved
[ 0.174709] system 00:01: [io 0x4800-0x487f] has been reserved
[ 0.174713] system 00:01: [io 0x4880-0x48ff] has been reserved
[ 0.174717] system 00:01: Plug and Play ACPI device, IDs PNP0c02
(active)
[ 0.174787] pnp 00:02: [io 0x0010-0x001f]
[ 0.174790] pnp 00:02: [io 0x0022-0x003f]
[ 0.174792] pnp 00:02: [io 0x0044-0x005f]
[ 0.174794] pnp 00:02: [io 0x0062-0x0063]
[ 0.174797] pnp 00:02: [io 0x0065-0x006f]
[ 0.174799] pnp 00:02: [io 0x0074-0x007f]
[ 0.174802] pnp 00:02: [io 0x0091-0x0093]
[ 0.174804] pnp 00:02: [io 0x00a2-0x00bf]
[ 0.174807] pnp 00:02: [io 0x00e0-0x00ef]
[ 0.174809] pnp 00:02: [io 0x04d0-0x04d1]
[ 0.174812] pnp 00:02: [io 0x0800-0x087f]
[ 0.174814] pnp 00:02: [io 0x0290-0x0297]
[ 0.174817] pnp 00:02: [io 0x0880-0x088f]
[ 0.174899] system 00:02: [io 0x04d0-0x04d1] has been reserved
[ 0.174903] system 00:02: [io 0x0800-0x087f] has been reserved
[ 0.174907] system 00:02: [io 0x0290-0x0297] has been reserved
[ 0.174911] system 00:02: [io 0x0880-0x088f] has been reserved
[ 0.174915] system 00:02: Plug and Play ACPI device, IDs PNP0c02
(active)
[ 0.177337] pnp 00:0b: [mem 0x000f0000-0x000f3fff]
[ 0.177340] pnp 00:0b: [mem 0x000f4000-0x000f7fff]
[ 0.177343] pnp 00:0b: [mem 0x000f8000-0x000fbfff]
[ 0.177346] pnp 00:0b: [mem 0x000fc000-0x000fffff]
[ 0.177348] pnp 00:0b: [mem 0xfeff0000-0xfeff00ff]
[ 0.177351] pnp 00:0b: [mem 0xbfef0000-0xbfefffff]
[ 0.177354] pnp 00:0b: [mem 0xffff0000-0xffffffff]
[ 0.177356] pnp 00:0b: [mem 0x00000000-0x0009ffff]
[ 0.177359] pnp 00:0b: [mem 0x00100000-0xbfeeffff]
[ 0.177362] pnp 00:0b: [mem 0xfec00000-0xfec00fff]
[ 0.177365] pnp 00:0b: [mem 0xfee00000-0xfee00fff]
[ 0.177367] pnp 00:0b: [mem 0xfeff0000-0xfeff03ff]
[ 0.177471] system 00:0b: [mem 0x000f0000-0x000f3fff] could not be
reserved
[ 0.177475] system 00:0b: [mem 0x000f4000-0x000f7fff] could not be
reserved
[ 0.177479] system 00:0b: [mem 0x000f8000-0x000fbfff] could not be
reserved
[ 0.177483] system 00:0b: [mem 0x000fc000-0x000fffff] could not be
reserved
[ 0.177487] system 00:0b: [mem 0xfeff0000-0xfeff00ff] has been reserved
[ 0.177490] system 00:0b: [mem 0xbfef0000-0xbfefffff] could not be
reserved
[ 0.177494] system 00:0b: [mem 0xffff0000-0xffffffff] has been reserved
[ 0.177498] system 00:0b: [mem 0x00000000-0x0009ffff] could not be
reserved
[ 0.177502] system 00:0b: [mem 0x00100000-0xbfeeffff] could not be
reserved
[ 0.177506] system 00:0b: [mem 0xfec00000-0xfec00fff] could not be
reserved
[ 0.177509] system 00:0b: [mem 0xfee00000-0xfee00fff] has been reserved
[ 0.177513] system 00:0b: [mem 0xfeff0000-0xfeff03ff] could not be
reserved
[ 0.177517] system 00:0b: Plug and Play ACPI device, IDs PNP0c01
(active)
[ 0.177530] pnp: PnP ACPI: found 12 devices
[ 0.177533] ACPI: ACPI bus type pnp unregistered
[ 0.177537] PnPBIOS: Disabled by ACPI PNP
[ 0.215344] PCI: max bus depth: 1 pci_try_num: 2
[ 0.215380] pci 0000:00:02.0: PCI bridge to [bus 01-01]
[ 0.215384] pci 0000:00:02.0: bridge window [io 0xa000-0xafff]
[ 0.215389] pci 0000:00:02.0: bridge window [mem
0xd0000000-0xd1ffffff]
[ 0.215394] pci 0000:00:02.0: bridge window [mem
0xc0000000-0xcfffffff 64bit pref]
[ 0.631936] io scheduler noop registered
[ 0.631938] io scheduler deadline registered
[ 0.631963] io scheduler cfq registered (default)
[ 0.632146] pcieport 0000:00:02.0: irq 40 for MSI/MSI-X
[ 0.632233] pcieport 0000:00:04.0: irq 41 for MSI/MSI-X
[ 0.632315] pcieport 0000:00:05.0: irq 42 for MSI/MSI-X
[ 0.632399] pcieport 0000:00:06.0: irq 43 for MSI/MSI-X
[ 0.632480] pcieport 0000:00:07.0: irq 44 for MSI/MSI-X
[ 0.632572] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 0.632600] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[ 0.632603] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 0.633084] nvidiafb_setup START
[ 0.633190] intel_idle: MWAIT substates: 0x20
[ 0.633192] intel_idle: does not run on family 6 model 15
[ 0.633236] GHES: HEST is not enabled!
[ 0.633254] isapnp: Scanning for PnP cards...
[ 0.986305] isapnp: No Plug & Play device found
[ 0.986387] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 1.006842] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 1.027725] 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 1.028068] Linux agpgart interface v0.103
[ 1.028351] i8042: PNP: No PS/2 controller found. Probing ports
directly.
[ 1.031691] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 1.031699] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 1.031852] mousedev: PS/2 mouse device common for all mice
[ 1.031919] rtc_cmos 00:05: RTC can wake from S4
[ 1.032070] rtc_cmos 00:05: rtc core: registered rtc_cmos as rtc0
[ 1.032104] rtc0: alarms up to one year, y3k, 242 bytes nvram, hpet irqs
[ 1.032116] cpuidle: using governor ladder
[ 1.032119] cpuidle: using governor menu
[ 1.032373] TCP cubic registered
[ 1.032425] NET: Registered protocol family 10
[ 1.033029] Mobile IPv6
[ 1.033033] NET: Registered protocol family 17
[ 1.033038] Registering the dns_resolver key type
[ 1.033058] Using IPI No-Shortcut mode
[ 1.033205] PM: Hibernation image not present or could not be loaded.
[ 1.033216] registered taskstats version 1
[ 1.033876] rtc_cmos 00:05: setting system clock to 2012-07-08 06:21:33
UTC (1341728493)
[ 1.033919] Initializing network drop monitor service
[ 1.034023] Freeing unused kernel memory: 408k freed
[ 1.034254] Write protecting the kernel text: 2912k
[ 1.034296] Write protecting the kernel read-only data: 1100k
[ 1.034298] NX-protecting the kernel data: 3232k
[ 1.091810] udevd[52]: starting version 175
[ 1.147454] usbcore: registered new interface driver usbfs
[ 1.147484] usbcore: registered new interface driver hub
[ 1.155304] SCSI subsystem initialized
[ 1.157254] usbcore: registered new device driver usb
[ 1.157955] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 1.157960] ehci_hcd: block sizes: qh 68 qtd 96 itd 160 sitd 96
[ 1.158057] ehci_hcd 0000:00:0b.1: setting latency timer to 64
[ 1.158061] ehci_hcd 0000:00:0b.1: EHCI Host Controller
[ 1.158089] drivers/usb/core/inode.c: creating file 'devices'
[ 1.158094] drivers/usb/core/inode.c: creating file '001'
[ 1.158099] ehci_hcd 0000:00:0b.1: new USB bus registered, assigned bus
number 1
[ 1.158111] ehci_hcd 0000:00:0b.1: reset hcs_params 0x101888 dbg=1 cc=1
pcc=8 !ppc ports=8
[ 1.158142] ehci_hcd 0000:00:0b.1: park 0
[ 1.158150] ehci_hcd 0000:00:0b.1: debug port 1
[ 1.158156] ehci_hcd 0000:00:0b.1: reset command 0080b02 park=3
ithresh=8 period=1024 Reset HALT
[ 1.158166] ehci_hcd 0000:00:0b.1: cache line size of 32 is not
supported
[ 1.158169] ehci_hcd 0000:00:0b.1: supports USB remote wakeup
[ 1.158196] ehci_hcd 0000:00:0b.1: irq 22, io mem 0xd5007000
[ 1.158202] ehci_hcd 0000:00:0b.1: init command 0010005 (park)=0
ithresh=1 period=512 RUN
[ 1.167291] input: Power Button as
/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
[ 1.167301] ACPI: Power Button [PWRB]
[ 1.167414] input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[ 1.167419] ACPI: Power Button [PWRF]
[ 1.168098] ehci_hcd 0000:00:0b.1: USB 2.0 started, EHCI 1.00
[ 1.168152] usb usb1: default language 0x0409
[ 1.168161] usb usb1: udev 1, busnum 1, minor = 0
[ 1.168164] usb usb1: New USB device found, idVendor=1d6b,
idProduct=0002
[ 1.168168] usb usb1: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[ 1.168171] usb usb1: Product: EHCI Host Controller
[ 1.168173] usb usb1: Manufacturer: Linux 3.3.0+ ehci_hcd
[ 1.168176] usb usb1: SerialNumber: 0000:00:0b.1
[ 1.170962] usb usb1: usb_probe_device
[ 1.170969] usb usb1: configuration #1 chosen from 1 choice
[ 1.170989] usb usb1: adding 1-0:1.0 (config #1, interface 0)
[ 1.171027] hub 1-0:1.0: usb_probe_interface
[ 1.171031] hub 1-0:1.0: usb_probe_interface - got id
[ 1.171035] hub 1-0:1.0: USB hub found
[ 1.171042] hub 1-0:1.0: 8 ports detected
[ 1.171044] hub 1-0:1.0: standalone hub
[ 1.171047] hub 1-0:1.0: no power switching (usb 1.0)
[ 1.171049] hub 1-0:1.0: individual port over-current protection
[ 1.171053] hub 1-0:1.0: power on to power good time: 20ms
[ 1.171058] hub 1-0:1.0: local power source is good
[ 1.171061] hub 1-0:1.0: trying to enable port power on non-switchable
hub
[ 1.171107] drivers/usb/core/inode.c: creating file '001'
[ 1.173776] libata version 3.00 loaded.
[ 1.174296] sata_nv 0000:00:0e.0: version 3.5
[ 1.174532] ACPI: PCI Interrupt Link [APSI] enabled at IRQ 21
[ 1.174549] sata_nv 0000:00:0e.0: Using SWNCQ mode
[ 1.174604] sata_nv 0000:00:0e.0: setting latency timer to 64
[ 1.175782] ACPI: Fan [FAN] (on)
[ 1.176845] scsi0 : sata_nv
[ 1.178890] 8139too: 8139too Fast Ethernet driver 0.9.28
[ 1.179184] ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
[ 1.180086] scsi1 : sata_nv
[ 1.180256] ata1: SATA max UDMA/133 cmd 0x9f0 ctl 0xbf0 bmdma 0xd400
irq 21
[ 1.180260] ata2: SATA max UDMA/133 cmd 0x970 ctl 0xb70 bmdma 0xd408
irq 21
[ 1.180487] ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 20
[ 1.180506] sata_nv 0000:00:0f.0: Using SWNCQ mode
[ 1.180578] sata_nv 0000:00:0f.0: setting latency timer to 64
[ 1.184032] scsi2 : sata_nv
[ 1.187692] scsi3 : sata_nv
[ 1.187911] ata3: SATA max UDMA/133 cmd 0x9e0 ctl 0xbe0 bmdma 0xe800
irq 20
[ 1.187916] ata4: SATA max UDMA/133 cmd 0x960 ctl 0xb60 bmdma 0xe808
irq 20
[ 1.188568] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 1.188572] ohci_hcd: block sizes: ed 64 td 64
[ 1.188639] ohci_hcd 0000:00:0b.0: setting latency timer to 64
[ 1.188643] ohci_hcd 0000:00:0b.0: OHCI Host Controller
[ 1.188655] drivers/usb/core/inode.c: creating file '002'
[ 1.188661] ohci_hcd 0000:00:0b.0: new USB bus registered, assigned bus
number 2
[ 1.188681] ohci_hcd 0000:00:0b.0: created debug files
[ 1.188684] ohci_hcd 0000:00:0b.0: supports USB remote wakeup
[ 1.188712] ohci_hcd 0000:00:0b.0: irq 23, io mem 0xd5006000
[ 1.194304] thermal LNXTHERM:00: registered as thermal_zone0
[ 1.194308] ACPI: Thermal Zone [THRM] (40 C)
[ 1.204417] 8139too 0000:06:07.0: eth0: RealTek RTL8139 at 0xb000,
00:40:05:00:39:88, IRQ 17
[ 1.204777] ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
[ 1.204868] skge: 1.14 addr 0xd4000000 irq 18 chip Yukon-Lite rev 9
[ 1.205514] skge 0000:06:0c.0: eth1: addr 00:24:8c:02:b7:12
[ 1.246021] ohci_hcd 0000:00:0b.0: OHCI controller state
[ 1.246027] ohci_hcd 0000:00:0b.0: OHCI 1.0, NO legacy support
registers, rh state running
[ 1.246033] ohci_hcd 0000:00:0b.0: control 0x683 RWE RWC
HCFS=operational CBSR=3
[ 1.246143] usb usb2: Product: OHCI Host Controller
[ 1.246145] usb usb2: Manufacturer: Linux 3.3.0+ ohci_hcd
[ 1.246148] usb usb2: SerialNumber: 0000:00:0b.0
[ 1.246839] usb usb2: usb_probe_device
[ 1.246844] usb usb2: configuration #1 chosen from 1 choice
[ 1.246855] usb usb2: adding 2-0:1.0 (config #1, interface 0)
[ 1.246904] hub 2-0:1.0: usb_probe_interface
[ 1.246907] hub 2-0:1.0: usb_probe_interface - got id
[ 1.246911] hub 2-0:1.0: USB hub found
[ 1.246918] hub 2-0:1.0: 8 ports detected
[ 1.246921] hub 2-0:1.0: standalone hub
[ 1.246923] hub 2-0:1.0: no power switching (usb 1.0)
[ 1.246926] hub 2-0:1.0: global over-current protection
[ 1.246928] hub 2-0:1.0: power on to power good time: 2ms
[ 1.246935] hub 2-0:1.0: local power source is good
[ 1.246937] hub 2-0:1.0: no over-current condition exists
[ 1.246940] hub 2-0:1.0: trying to enable port power on non-switchable
hub
[ 1.480108] hub 2-0:1.0: port 5, status 0301, change 0001, 1.5 Mb/s
[ 1.492051] ata1: SATA link down (SStatus 0 SControl 300)
[ 1.504052] ata3: SATA link down (SStatus 0 SControl 300)
[ 1.608044] hub 2-0:1.0: debounce: port 5: total 100ms stable 100ms
status 0x301
[ 1.784135] usb 2-5: new low-speed USB device number 2 using ohci_hcd
[ 1.804036] ata2: SATA link down (SStatus 0 SControl 300)
[ 1.904036] ohci_hcd 0000:00:0b.0: GetStatus roothub.portstatus [4] =
0x00100303 PRSC LSDA PPS PES CCS
[ 1.987050] usb 2-5: skipped 1 descriptor after interface
[ 1.990048] usb 2-5: default language 0x0409
[ 1.996050] usb 2-5: udev 2, busnum 2, minor = 129
[ 1.996054] usb 2-5: New USB device found, idVendor=046d, idProduct=c05a
[ 1.996059] usb 2-5: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 1.996063] usb 2-5: Product: USB Optical Mouse
[ 1.996067] usb 2-5: Manufacturer: Logitech
[ 1.996211] usb 2-5: usb_probe_device
[ 1.996217] usb 2-5: configuration #1 chosen from 1 choice
[ 1.999066] usb 2-5: adding 2-5:1.0 (config #1, interface 0)
[ 1.999152] drivers/usb/core/inode.c: creating file '002'
[ 1.999196] ohci_hcd 0000:00:0b.0: GetStatus roothub.portstatus [5] =
0x00010301 CSC LSDA PPS CCS
[ 1.999206] hub 2-0:1.0: port 6, status 0301, change 0001, 1.5 Mb/s
[ 2.116018] ata4: SATA link down (SStatus 0 SControl 300)
[ 2.116255] scsi 4:0:0:0: Direct-Access ATA HDT722516DLAT80
V43O PQ: 0 ANSI: 5
[ 2.116520] scsi 4:0:1:0: Direct-Access ATA WDC WD800BB-00JH
05.0 PQ: 0 ANSI: 5
[ 2.124033] hub 2-0:1.0: debounce: port 6: total 100ms stable 100ms
status 0x301
[ 2.244033] ohci_hcd 0000:00:0b.0: GetStatus roothub.portstatus [5] =
0x00100303 PRSC LSDA PPS PES CCS
[ 2.291595] sd 4:0:0:0: [sda] 321670847 512-byte logical blocks: (164
GB/153 GiB)
[ 2.291622] sd 4:0:1:0: [sdb] 156299375 512-byte logical blocks: (80.0
GB/74.5 GiB)
[ 2.291707] sd 4:0:0:0: [sda] Write Protect is off
[ 2.291711] sd 4:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 2.291756] sd 4:0:1:0: [sdb] Write Protect is off
[ 2.291761] sd 4:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 2.300057] usb 2-6: new low-speed USB device number 3 using ohci_hcd
[ 2.326840] sdb: sdb1 sdb2
[ 2.350967] sda: sda1 sda2 sda4 < sda5 sda6 sda7 >
[ 2.351214] sda: p7 size 37047500 extends beyond EOD, enabling native
capacity
[ 2.351748] ata5: soft resetting link
[ 2.420038] ohci_hcd 0000:00:0b.0: GetStatus roothub.portstatus [5] =
0x00100303 PRSC LSDA PPS PES CCS
[ 2.505052] usb 2-6: skipped 1 descriptor after interface
[ 2.505058] usb 2-6: skipped 1 descriptor after interface
[ 2.508047] usb 2-6: default language 0x0409
[ 2.514051] usb 2-6: udev 3, busnum 2, minor = 130
[ 2.514056] usb 2-6: New USB device found, idVendor=046d, idProduct=c31d
[ 2.514061] usb 2-6: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[ 2.514065] usb 2-6: Product: USB Keyboard
[ 2.514069] usb 2-6: Manufacturer: Logitech
[ 2.514216] usb 2-6: usb_probe_device
[ 2.514222] usb 2-6: configuration #1 chosen from 1 choice
[ 2.520050] usb 2-6: adding 2-6:1.0 (config #1, interface 0)
[ 2.523104] usb 2-6: adding 2-6:1.1 (config #1, interface 1)
[ 2.526105] drivers/usb/core/inode.c: creating file '003'
[ 2.526151] hub 2-0:1.0: state 7 ports 8 chg 0000 evt 0040
[ 2.529498] ata5.00: n_sectors mismatch 321670847 != 321672960
[ 2.529502] ata5.00: new n_sectors matches native, probably late HPA
unlock, n_sectors updated
[ 2.529514] ata5: nv_mode_filter: 0x7f39f&0x7f39f->0x7f39f,
BIOS=0x7f000 (0xc7c60000) ACPI=0x7f01f (15:20:0x1f)
[ 2.529520] ata5: nv_mode_filter: 0x3f39f&0x3f39f->0x3f39f,
BIOS=0x3f000 (0xc7c60000) ACPI=0x3f01f (15:20:0x1f)
[ 2.533120] usbhid 2-5:1.0: usb_probe_interface
[ 2.533125] usbhid 2-5:1.0: usb_probe_interface - got id
[ 2.539385] input: Logitech USB Optical Mouse as
/devices/pci0000:00/0000:00:0b.0/usb2/2-5/2-5:1.0/input/input2
[ 2.539505] generic-usb 0003:046D:C05A.0001: input,hidraw0: USB HID
v1.11 Mouse [Logitech USB Optical Mouse] on usb-0000:00:0b.0-5/input0
[ 2.539517] usbhid 2-6:1.0: usb_probe_interface
[ 2.539521] usbhid 2-6:1.0: usb_probe_interface - got id
[ 2.544436] input: Logitech USB Keyboard as
/devices/pci0000:00/0000:00:0b.0/usb2/2-6/2-6:1.0/input/input3
[ 2.544477] ata5.00: configured for UDMA/133
[ 2.544518] generic-usb 0003:046D:C31D.0002: input,hidraw1: USB HID
v1.10 Keyboard [Logitech USB Keyboard] on usb-0000:00:0b.0-6/input0
[ 2.552570] sd 4:0:1:0: [sdb] Attached SCSI disk
[ 2.553114] sda: detected capacity change from 164695473664 to
164696555520
[ 2.558181] input: Logitech USB Keyboard as
/devices/pci0000:00/0000:00:0b.0/usb2/2-6/2-6:1.1/input/input4
[ 2.558276] generic-usb 0003:046D:C31D.0003: input,hidraw2: USB HID
v1.10 Device [Logitech USB Keyboard] on usb-0000:00:0b.0-6/input1
[ 2.558310] usbcore: registered new interface driver usbhid
[ 2.558312] usbhid: USB HID core driver
[ 2.682848] sda: sda1 sda2 sda4 < sda5 sda6 sda7 >
[ 2.688433] sd 4:0:0:0: [sda] Attached SCSI disk
[ 2.688504] sda: detected capacity change from 0 to 164696555520
[ 3.318799] [drm] Initialized drm 1.1.0 20060810
[ 3.325599] [drm:i915_init] *ERROR* drm/i915 can't work without
intel_agp module!
[ 8.333725] [drm] Encoders:
[ 8.333726] [drm] CRT2: INTERNAL_KLDSCP_DAC2
[ 8.333766] [drm] Internal thermal controller with fan control
[ 8.333819] [drm] radeon: power management initialized
[ 8.486888] [drm] fb mappable at 0xC0142000
[ 8.486891] [drm] vram apper at 0xC0000000
[ 8.486893] [drm] size 8294400
[ 8.486895] [drm] fb depth is 24
[ 8.486897] [drm] pitch is 7680
[ 8.487001] fbcon: radeondrmfb (fb0) is primary device
[ 8.696036] ACPI: PCI Interrupt Link [AAZA] enabled at IRQ 23
[ 8.696041] hda_intel: Disabling MSI
[ 8.696069] snd_hda_intel 0000:00:10.1: setting latency timer to 64
[ 8.745425] Console: switching to colour frame buffer device 160x64
[ 8.754312] fb0: radeondrmfb frame buffer device
[ 8.754314] drm: registered panic notifier
[ 8.754383] [drm] Initialized radeon 2.13.0 20080528 for 0000:01:00.0
on minor 0
[ 9.410229] input: HDA Digital PCBeep as
/devices/pci0000:00/0000:00:10.1/input/input6
[ 9.560458] ACPI: PCI Interrupt Link [APC6] enabled at IRQ 16
[ 9.560532] snd_hda_intel 0000:01:00.1: irq 46 for MSI/MSI-X
[ 9.820569] HDMI status: Codec=0 Pin=3 Presence_Detect=0 ELD_Valid=0
[ 9.820688] input: HD-Audio Generic HDMI/DP,pcm=3 as
/devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card1/input7
[ 11.365474] Adding 1956180k swap on /dev/sda6. Priority:-1 extents:1
across:1956180k
[ 12.045301] EXT3-fs (sda5): using internal journal
[ 18.987361] kjournald starting. Commit interval 5 seconds
[ 18.987627] EXT3-fs (sda2): using internal journal
[ 18.987632] EXT3-fs (sda2): mounted filesystem with ordered data mode
[ 19.062655] FAT-fs (sdb2): utf8 is not a recommended IO charset for FAT
filesystems, filesystem will be case sensitive!
[ 19.131619] kjournald starting. Commit interval 5 seconds
[ 19.131821] EXT3-fs (sda1): using internal journal
[ 19.131827] EXT3-fs (sda1): mounted filesystem with ordered data mode
[ 19.311846] EXT4-fs (sda7): mounted filesystem with ordered data mode.
Opts: (null)
[ 34.024643] lp0: using parport0 (interrupt-driven).
[ 34.407696] ppdev: user-space parallel port driver
[ 37.138306] 8139too 0000:06:07.0: eth0: link down
[ 37.138588] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 37.152262] skge 0000:06:0c.0: eth1: enabling interface
[ 37.155659] ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 38.839136] skge 0000:06:0c.0: eth1: Link is up at 100 Mbps, full
duplex, flow control both
[ 38.839372] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 45.535376] Ebtables v2.0 registered
[ 45.988565] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 46.028436] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 46.893649] usb usb1: usb auto-resume
[ 46.893655] ehci_hcd 0000:00:0b.1: resume root hub
[ 46.944153] hub 1-0:1.0: hub_resume
[ 46.944199] hub 1-0:1.0: state 7 ports 8 chg 0000 evt 0000
[ 65.804040] hub 1-0:1.0: hub_suspend
[ 65.804053] usb usb1: bus auto-suspend, wakeup 1
[ 65.804058] ehci_hcd 0000:00:0b.1: suspend root hub
[ 81.642706] postgres (4166): /proc/4166/oom_adj is deprecated, please
use /proc/4166/oom_score_adj instead.
> Also, what does the "lspci -vv" output show for the controller if you
> run it with superuser permissions?