From: Kevin Fenzi <kevin-linux-kernel@scrye.com>
To: linux-kernel@vger.kernel.org, bjorn.helgaas@hp.com, pavel@ucw.cz
Subject: Re: FYI: my current bigdiff
Date: Thu, 9 Sep 2004 22:13:16 -0600 [thread overview]
Message-ID: <20040910041320.DF700E7504@voldemort.scrye.com> (raw)
In-Reply-To: 20040909134421.GA12204@elf.ucw.cz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Pavel" == Pavel Machek <pavel@ucw.cz> writes:
Pavel> Hi! This is my bigdiff. It is not for inclusion (I'll have to
Pavel> split it), but it contains some usefull code (I believe :-).
Pavel> Oh, it speeds up swsusp quite a lot.
Indeed it does.
After 42 days of uptime with 2.6.8-rc2-mm1 I decided to upgrade.
swsusp was very stable, but was getting slower and slower. Eariler
tonight I suspended and it took about 15min to finish suspending.
So, I built a new 2.6.9-rc1-mm4 + this bigdiff for swsusp.
First suspend worked.
First resume came back, but all kinds of problems with my network,
with my usb, and with sound.
After looking around a bit it seems this is the issue:
Sep 9 21:32:27 voldemort kernel: ** PCI interrupts are no longer routed automatically. If this
Sep 9 21:32:27 voldemort kernel: ** causes a device to stop working, it is probably because the
Sep 9 21:32:27 voldemort kernel: ** driver failed to call pci_enable_device(). As a temporary
Sep 9 21:32:27 voldemort kernel: ** workaround, the "pci=routeirq" argument restores the old
Sep 9 21:32:27 voldemort kernel: ** behavior. If this argument makes the device work again,
Sep 9 21:32:27 voldemort kernel: ** please email the output of "lspci" to bjorn.helgaas@hp.com
Sep 9 21:32:27 voldemort kernel: ** so I can fix the driver.
After that first suspend/resume:
Sep 9 21:35:28 voldemort kernel: Stopping tasks: ====================================|
Sep 9 21:35:28 voldemort kernel: Freeing memory... ^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H
\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-
^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^
H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^H\^H|^H/^H-^Hdone (44436 pages freed)
(BTW, that looks pretty nasty in the logs, even though it's very nice
to watch)
Sep 9 21:35:28 voldemort kernel: swsusp: Need to copy 13410 pages
Sep 9 21:35:28 voldemort kernel: ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 11 (level, low) -> IRQ 11
Sep 9 21:35:28 voldemort kernel: ACPI: PCI interrupt 0000:02:0e.0[A] -> GSI 10 (level, low) -> IRQ 10
Sep 9 21:35:28 voldemort kernel: ACPI: PCI interrupt 0000:02:0e.1[B] -> GSI 10 (level, low) -> IRQ 10
Sep 9 21:35:28 voldemort kernel: Restarting tasks... done
Sep 9 21:35:30 voldemort kernel: usbcore: registered new driver usbfs
Sep 9 21:35:30 voldemort kernel: usbcore: registered new driver hub
Sep 9 21:35:30 voldemort kernel: ohci_hcd: 2004 Feb 02 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
Sep 9 21:35:30 voldemort kernel: ACPI: PCI interrupt 0000:02:0e.0[A] -> GSI 10 (level, low) -> IRQ 10
Sep 9 21:35:30 voldemort kernel: ohci_hcd 0000:02:0e.0: NEC Corporation USB
Sep 9 21:35:31 voldemort kernel: irq 10: nobody cared!
Sep 9 21:35:31 voldemort kernel: [<c01083ef>] __report_bad_irq+0x2a/0x8b
Sep 9 21:35:31 voldemort kernel: [<c01085e1>] note_interrupt+0x7c/0xde
Sep 9 21:35:31 voldemort kernel: [<c0108847>] do_IRQ+0xf7/0x116
Sep 9 21:35:31 voldemort kernel: [<c010678c>] common_interrupt+0x18/0x20
Sep 9 21:35:31 voldemort kernel: [<c011fa5f>] __do_softirq+0x2f/0x87
Sep 9 21:35:31 voldemort kernel: [<c011fadd>] do_softirq+0x26/0x28
Sep 9 21:35:31 voldemort kernel: [<c0108826>] do_IRQ+0xd6/0x116
Sep 9 21:35:31 voldemort kernel: [<c010678c>] common_interrupt+0x18/0x20
Sep 9 21:35:31 voldemort kernel: [<c0108c71>] setup_irq+0x69/0xaa
Sep 9 21:35:31 voldemort kernel: [<f88b68aa>] usb_hcd_irq+0x0/0x67 [usbcore]
Sep 9 21:35:31 voldemort kernel: [<c010891c>] request_irq+0x83/0xc5
Sep 9 21:35:31 voldemort kernel: [<f88ba6af>] usb_hcd_pci_probe+0x1f5/0x4dc [usbcore]
Sep 9 21:35:31 voldemort kernel: [<f88b68aa>] usb_hcd_irq+0x0/0x67 [usbcore]
Sep 9 21:35:31 voldemort kernel: [<c01863e1>] sysfs_make_dirent+0x2b/0x97
Sep 9 21:35:31 voldemort kernel: [<c01e3e58>] pci_device_probe_static+0x52/0x61
Sep 9 21:35:31 voldemort kernel: [<c01e3ea2>] __pci_device_probe+0x3b/0x4e
Sep 9 21:35:31 voldemort kernel: [<c01e3ee1>] pci_device_probe+0x2c/0x4a
Sep 9 21:35:31 voldemort kernel: [<c0229acd>] bus_match+0x3f/0x6a
Sep 9 21:35:31 voldemort kernel: [<c0229bdf>] driver_attach+0x56/0x80
Sep 9 21:35:31 voldemort kernel: [<c022a032>] bus_add_driver+0x91/0xaf
Sep 9 21:35:31 voldemort kernel: [<c022a54d>] driver_register+0x2f/0x33
Sep 9 21:35:31 voldemort kernel: [<c01e4120>] pci_register_driver+0x5c/0x84
Sep 9 21:35:31 voldemort kernel: [<f887e037>] ohci_hcd_pci_init+0x37/0x44 [ohci_hcd]
Sep 9 21:35:31 voldemort kernel: [<c0130ea8>] sys_init_module+0x135/0x1ba
Sep 9 21:35:31 voldemort kernel: [<c0105dcd>] sysenter_past_esp+0x52/0x71
Sep 9 21:35:31 voldemort kernel: handlers:
Sep 9 21:35:31 voldemort kernel: [<f88b68aa>] (usb_hcd_irq+0x0/0x67 [usbcore])
Sep 9 21:35:31 voldemort kernel: Disabling IRQ #10
Sep 9 21:35:31 voldemort kernel: ohci_hcd 0000:02:0e.0: irq 10, pci mem 0x40180000
Sep 9 21:35:31 voldemort kernel: ohci_hcd 0000:02:0e.0: new USB bus registered, assigned bus number 1
Sep 9 21:35:32 voldemort kernel: hub 1-0:1.0: USB hub found
Sep 9 21:35:32 voldemort kernel: hub 1-0:1.0: 3 ports detected
Sep 9 21:35:32 voldemort kernel: ACPI: PCI interrupt 0000:02:0e.1[B] -> GSI 10 (level, low) -> IRQ 10
Sep 9 21:35:32 voldemort kernel: ohci_hcd 0000:02:0e.1: NEC Corporation USB (#2)
Sep 9 21:35:32 voldemort kernel: ohci_hcd 0000:02:0e.1: irq 10, pci mem 0x40200000
Sep 9 21:35:32 voldemort kernel: ohci_hcd 0000:02:0e.1: new USB bus registered, assigned bus number 2
Sep 9 21:35:33 voldemort kernel: hub 2-0:1.0: USB hub found
Sep 9 21:35:33 voldemort kernel: hub 2-0:1.0: 2 ports detected
Sep 9 21:35:33 voldemort kernel: Loaded prism54 driver, version 1.2
Sep 9 21:35:33 voldemort kernel: ACPI: PCI interrupt 0000:03:00.0[A] -> GSI 11 (level, low) -> IRQ 11
Sep 9 21:35:33 voldemort kernel: divert: allocating divert_blk for eth1
Sep 9 21:36:07 voldemort kernel: eth1: resetting device...
Sep 9 21:36:07 voldemort kernel: eth1: uploading firmware...
Sep 9 21:36:08 voldemort kernel: eth1: firmware upload complete
Sep 9 21:36:09 voldemort kernel: eth1: reset problem: no 'reset complete' IRQ seen
Sep 9 21:36:09 voldemort kernel: eth1: timeout waiting for mgmt response 1000, triggering device
Sep 9 21:36:10 voldemort kernel: eth1: timeout waiting for mgmt response
Sep 9 21:36:10 voldemort kernel: eth1: mgt_commit_list: failure. oid=ff020008 err=-110
Sep 9 21:36:10 voldemort kernel: eth1: timeout waiting for mgmt response 1000, triggering device
Sep 9 21:36:11 voldemort kernel: eth1: timeout waiting for mgmt response
Sep 9 21:36:11 voldemort kernel: eth1: mgt_commit_list: failure. oid=ff020003 err=-110
Sep 9 21:36:11 voldemort kernel: eth1: timeout waiting for mgmt response 1000, triggering device
Sep 9 21:36:12 voldemort kernel: eth1: timeout waiting for mgmt response
Sep 9 21:36:12 voldemort kernel: eth1: mgt_commit_list: failure. oid=10000000 err=-110
Sep 9 21:36:12 voldemort kernel: eth1: timeout waiting for mgmt response 1000, triggering device
Sep 9 21:36:13 voldemort kernel: eth1: timeout waiting for mgmt response
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=17000007 err=-110
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=19000001 err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=10000002 err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=19000004 err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=12000000 err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=12000001 err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=12000002 err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=12000004 err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=12000005 err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=12000006 err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=12000007 err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=12000003 err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=150007e0 err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=ff02000c err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit_list: failure. oid=ff020003 err=-12
Sep 9 21:36:13 voldemort kernel: eth1: mgmt tx queue is still full
Sep 9 21:36:13 voldemort kernel: eth1: mgt_update_addr: failure
Sep 9 21:36:13 voldemort kernel: eth1: mgt_commit: failure
Sep 9 21:36:13 voldemort kernel: eth1: interface reset complete
Seems the usb and prism54 didn't play nice.
After booting with the pci=routeirq as suggested wireless and usb
played nice on suspend resume again.
I am copying this to the email address that is mentioned.
So, after that glitch:
- - The display is much nicer. Congrats.
- - Speed does seem to be nicer. It's taking me 40 seconds to do a
complete suspend/resume cycle.
- - Should PREEMPT and/or HIMEM work with this version? I can test them
if support has been added/fixed/tweaked for them.
I have only done a few cycles, but it looks nice and stable. I would
suggest you break it into smaller patches and get it applied.
Being applied to the main tree would be nice.
kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFBQSng3imCezTjY0ERAjT0AJwNvCL3WbN2ypJQedPOjL3nlF8DMwCeJYss
WNY5zEepODMsOoq2GNrWhfI=
=vFww
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2004-09-10 4:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-09 13:44 FYI: my current bigdiff Pavel Machek
2004-09-10 4:13 ` Kevin Fenzi [this message]
2004-09-10 9:44 ` Pavel Machek
2004-09-10 17:27 ` Kevin Fenzi
2004-09-10 22:46 ` Bjorn Helgaas
2004-09-11 16:41 ` Stefan Seyfried
2004-09-11 18:55 ` Kevin Fenzi
2004-09-11 18:50 ` Kevin Fenzi
2004-09-13 22:06 ` Bjorn Helgaas
2004-09-12 8:54 ` Stefan Schweizer
2004-09-12 9:23 ` Stefan Seyfried
2004-09-12 9:32 ` Stefan Schweizer
2004-09-12 11:39 ` Stefan Seyfried
2004-09-12 21:03 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040910041320.DF700E7504@voldemort.scrye.com \
--to=kevin-linux-kernel@scrye.com \
--cc=bjorn.helgaas@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.