linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Barry K. Nathan" <barryn@pobox.com>
To: "Barry K. Nathan" <barryn@pobox.com>
Cc: lindqvist@netstar.se, pavel@ucw.cz, edi@gmx.de, john@hjsoft.com,
	linux-kernel@vger.kernel.org
Subject: Re: 2.6.10: e100 network broken after swsusp/resume
Date: Mon, 3 Jan 2005 00:31:55 -0800	[thread overview]
Message-ID: <20050103083154.GA4460@ip68-4-98-123.oc.oc.cox.net> (raw)
In-Reply-To: <20050103051018.GA4413@ip68-4-98-123.oc.oc.cox.net>

On Sun, Jan 02, 2005 at 09:10:18PM -0800, Barry K. Nathan wrote:
> So, I think this bug probably lies in ACPI or swsusp. I highly *highly*
> doubt it's driver bugs. Hopefully I'll have time later tonight or
> tomorrow morning to see if I can figure anything else out...

The following patch is a ridiculously dirty kludge which (very arguably)
improves the situation somewhat:

--- linux-2.6.10-bk4/arch/i386/kernel/mpparse.c	2004-12-14 03:17:21.723010806 -0800
+++ linux-2.6.10-bk4-bkn1/arch/i386/kernel/mpparse.c	2005-01-02 23:43:13.647613575 -0800
@@ -1091,9 +1091,10 @@
 		return gsi;
 	}
 	if ((1<<bit) & mp_ioapic_routing[ioapic].pin_programmed[idx]) {
-		Dprintk(KERN_DEBUG "Pin %d-%d already programmed\n",
+		printk(KERN_DEBUG "Pin %d-%d already programmed\n",
 			mp_ioapic_routing[ioapic].apic_id, ioapic_pin);
-		return gsi;
+		/* return gsi; */
+		printk(KERN_DEBUG "However, I will reprogram it anyway.\n");
 	}
 
 	mp_ioapic_routing[ioapic].pin_programmed[idx] |= (1<<bit);


With this patch, unloading and reloading 8139too will make it work again
after a resume -- as long as I boot *without* "noapic". This doesn't fix
the actual problem (it's still broken after resume, and reloading the
module still doesn't work for "noapic") but it might provide clues.

More specifically, this shows that the 
mp_ioapic_routing[ioapic].pin_programmed[] array is inconsistent with
the IO-APIC's real configuration after the resume.

I think the reason that "pci=routeirq" works is that, with that option,
the kernel sets up everything on the IO-APIC early in bootup and leaves
nothing to be done later on -- that way, the IO-APIC ends up having the
same setup after the resume that it did at suspend time. At leas, that's
what I suspect; I don't think I've proven it yet. I wouldn't be
surprised if a similar phenomenon is happening with acpi=off.

Anyway, I'm going to keep working on this and see if I can figure it out
some more...

-Barry K. Nathan <barryn@pobox.com>


  reply	other threads:[~2005-01-03  8:32 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-28 14:47 2.6.10: e100 network broken after swsusp/resume John M Flinchbaugh
2004-12-28 21:25 ` Håkan Lindqvist
2005-01-01 23:41   ` Eduard Bloch
2005-01-01 17:23 ` Pavel Machek
2005-01-01 22:17   ` John M Flinchbaugh
2005-01-01 22:52     ` Pavel Machek
2005-01-01 23:14     ` Matthew Garrett
2005-01-02  3:46       ` Barry K. Nathan
2005-01-02  5:57   ` Barry K. Nathan
2005-01-02 18:42     ` John M Flinchbaugh
2005-01-02 20:09       ` Håkan Lindqvist
2005-01-03  5:10         ` Barry K. Nathan
2005-01-03  8:31           ` Barry K. Nathan [this message]
2005-01-03  8:53             ` Pavel Machek
2005-01-03  8:47           ` Pavel Machek
2005-01-03 10:14             ` Barry K. Nathan
2005-01-03 15:05               ` [PATCH] swsusp: properly suspend and resume *all* devices Barry K. Nathan
2005-01-03 17:08                 ` Pavel Machek
2005-01-03 18:33                   ` Pavel Machek
2005-01-04  5:15                     ` Barry K. Nathan
2005-01-04  5:18                       ` Barry K. Nathan
2005-01-04  8:44                 ` Martin Lucina
2005-01-04 10:30                   ` 2.6.10 suspend/resume bustage (was Re: [PATCH] swsusp: properly suspend and resume *all* devices) Martin Lucina
2005-01-04 21:43                   ` [PATCH] swsusp: properly suspend and resume *all* devices Pavel Machek
2005-01-05 15:57                     ` Lion Vollnhals
2005-01-06 22:29                       ` Pavel Machek
2005-01-07 13:47                         ` Takashi Iwai
2005-01-07 13:54                           ` Pavel Machek
2005-01-07 14:48                             ` Dmitry Torokhov
2005-01-07 15:35                             ` Vojtech Pavlik
2005-01-07 15:59                         ` Lion Vollnhals

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=20050103083154.GA4460@ip68-4-98-123.oc.oc.cox.net \
    --to=barryn@pobox.com \
    --cc=edi@gmx.de \
    --cc=john@hjsoft.com \
    --cc=lindqvist@netstar.se \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).