Linux 2.6.21-rc1

Linux 2.6.21-rc1

[Linus Torvalds]

Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.

There's a lot of changes, as is usual for an -rc1 thing, but at least so 
far it would seem that 2.6.20 has been a good base, and I don't think we 
have anything *really* scary here.

The most interesting core change may be the dyntick/nohz one, where timer 
ticks will only happen when needed. It's been brewing for a _loong_ time, 
but it's in the standard kernel now as an option. 

But there's a ton of architecture updates (arm, mips, powerpc, x86, you 
name it), ACPI updates, and lots of driver work. And just a lot of 
cleanups.

Have fun,

			Linus

Re: Linux 2.6.21-rc1

[Faik Uygur]

Hi,

21 Şub 2007 Çar 06:53 tarihinde, Linus Torvalds şunları yazmıştı: 
> Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.

  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CHK     include/linux/compile.h
  CC [M]  drivers/char/ip2/ip2main.o
In file included from drivers/char/ip2/ip2main.c:285:
drivers/char/ip2/i2lib.c: In function `iiSendPendingMail_t':
drivers/char/ip2/i2lib.c:83: sorry, unimplemented: inlining failed in call 
to 'iiSendPendingMail': function body not available
drivers/char/ip2/i2lib.c:157: sorry, unimplemented: called from here
make[3]: *** [drivers/char/ip2/ip2main.o] Error 1
make[2]: *** [drivers/char/ip2] Error 2
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

With cleanup changes in commit 40565f1962c5be9b9e285e05af01ab7771534868 
compilation fails.

Regards,
- Faik

Re: Linux 2.6.21-rc1

[Jiri Slaby]

Faik Uygur napsal(a):
> Hi,

Hi.

> 21 Şub 2007 Çar 06:53 tarihinde, Linus Torvalds şunları yazmıştı: 
>> Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
> 
>   CHK     include/linux/version.h
>   CHK     include/linux/utsrelease.h
>   CHK     include/linux/compile.h
>   CC [M]  drivers/char/ip2/ip2main.o
> In file included from drivers/char/ip2/ip2main.c:285:
> drivers/char/ip2/i2lib.c: In function `iiSendPendingMail_t':
> drivers/char/ip2/i2lib.c:83: sorry, unimplemented: inlining failed in call 
> to 'iiSendPendingMail': function body not available
> drivers/char/ip2/i2lib.c:157: sorry, unimplemented: called from here
> make[3]: *** [drivers/char/ip2/ip2main.o] Error 1
> make[2]: *** [drivers/char/ip2] Error 2
> make[1]: *** [drivers/char] Error 2
> make: *** [drivers] Error 2
> 
> With cleanup changes in commit 40565f1962c5be9b9e285e05af01ab7771534868 
> compilation fails.

What compiler?

thanks,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: Linux 2.6.21-rc1

[Jiri Slaby]

Jiri Slaby napsal(a):
> Faik Uygur napsal(a):
>> Hi,
> 
> Hi.
> 
>> 21 Şub 2007 Çar 06:53 tarihinde, Linus Torvalds şunları yazmıştı:
>>> Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
>>
>>   CHK     include/linux/version.h
>>   CHK     include/linux/utsrelease.h
>>   CHK     include/linux/compile.h
>>   CC [M]  drivers/char/ip2/ip2main.o
>> In file included from drivers/char/ip2/ip2main.c:285:
>> drivers/char/ip2/i2lib.c: In function `iiSendPendingMail_t':
>> drivers/char/ip2/i2lib.c:83: sorry, unimplemented: inlining failed in 
>> call to 'iiSendPendingMail': function body not available
>> drivers/char/ip2/i2lib.c:157: sorry, unimplemented: called from here
>> make[3]: *** [drivers/char/ip2/ip2main.o] Error 1
>> make[2]: *** [drivers/char/ip2] Error 2
>> make[1]: *** [drivers/char] Error 2
>> make: *** [drivers] Error 2
>>
>> With cleanup changes in commit 
>> 40565f1962c5be9b9e285e05af01ab7771534868 compilation fails.
> 
> What compiler?

Oh, I can reproduce with gcc 3.4. Going to fix it.

thanks,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: Linux 2.6.21-rc1

[Linus Torvalds]

On Wed, 21 Feb 2007, Faik Uygur wrote:
> 
>   CHK     include/linux/version.h
>   CHK     include/linux/utsrelease.h
>   CHK     include/linux/compile.h
>   CC [M]  drivers/char/ip2/ip2main.o
> In file included from drivers/char/ip2/ip2main.c:285:
> drivers/char/ip2/i2lib.c: In function `iiSendPendingMail_t':
> drivers/char/ip2/i2lib.c:83: sorry, unimplemented: inlining failed in call 
> to 'iiSendPendingMail': function body not available
> drivers/char/ip2/i2lib.c:157: sorry, unimplemented: called from here
> make[3]: *** [drivers/char/ip2/ip2main.o] Error 1
> make[2]: *** [drivers/char/ip2] Error 2
> make[1]: *** [drivers/char] Error 2
> make: *** [drivers] Error 2

Yeah, that thing was crud.

		Linus

---
commit 5fc7e655a50b0a19229a6b4a8a5e23bfedf700a4
Author: Linus Torvalds <torvalds@woody.linux-foundation.org>
Date:   Wed Feb 21 11:18:26 2007 -0800

    Fix bogus 'inline' in drivers/char/ip2/i2lib.c
    
    Not only was the function way too big to be inlined in the first place,
    it was used before it was even defined.
    
    Noted-by: Faik Uygur <faik@pardus.org.tr>
    Cc: Jiri Slaby <jirislaby@gmail.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/drivers/char/ip2/i2lib.c b/drivers/char/ip2/i2lib.c
index f86fa0c..e46120d 100644
--- a/drivers/char/ip2/i2lib.c
+++ b/drivers/char/ip2/i2lib.c
@@ -80,7 +80,7 @@ static int i2RetryFlushOutput(i2ChanStrPtr);
 // Not a documented part of the library routines (careful...) but the Diagnostic
 // i2diag.c finds them useful to help the throughput in certain limited
 // single-threaded operations.
-static inline void iiSendPendingMail(i2eBordStrPtr);
+static void iiSendPendingMail(i2eBordStrPtr);
 static void serviceOutgoingFifo(i2eBordStrPtr);
 
 // Functions defined in ip2.c as part of interrupt handling
@@ -166,7 +166,7 @@ static void iiSendPendingMail_t(unsigned long data)
 // If any outgoing mail bits are set and there is outgoing mailbox is empty,
 // send the mail and clear the bits.
 //******************************************************************************
-static inline void
+static void
 iiSendPendingMail(i2eBordStrPtr pB)
 {
 	if (pB->i2eOutMailWaiting && (!pB->i2eWaitingForEmptyFifo) )

Re: Linux 2.6.21-rc1

[Thomas Gleixner]

On Tue, 2007-02-20 at 20:53 -0800, Linus Torvalds wrote:
> But there's a ton of architecture updates (arm, mips, powerpc, x86, you 
> name it), ACPI updates, and lots of driver work. And just a lot of 
> cleanups.
> 
> Have fun,

Yup. Fun starts in drivers/net/e1000

e1000 is not working anymore. ifup fails permanentely.
 ADDRCONF(NETDEV_UP): eth0: link is not ready
nothing else

bisect identifies:

d2ed16356ff4fb9de23fbc5e5d582ce580390106 is first bad commit
commit d2ed16356ff4fb9de23fbc5e5d582ce580390106
Author: Kok, Auke <auke-jan.h.kok@intel.com>
Date:   Fri Feb 16 14:39:26 2007 -0800

    e1000: fix shared interrupt warning message

    Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Jeff Garzik <jeff@garzik.org>

Reverting this patch on top of -rc1 helps as well.

	tglx


lspci output:

04:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller
        Subsystem: Intel Corporation Unknown device 30a5
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 218
        Region 0: Memory at 90100000 (32-bit, non-prefetchable) [size=128K]
        Region 2: I/O ports at 2000 [size=32]
        Capabilities: [c8] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [d0] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable+
                Address: 00000000fee0100c  Data: 414a
        Capabilities: [e0] Express Endpoint IRQ 0
                Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag-
                Device: Latency L0s <512ns, L1 <64us
                Device: AtnBtn- AtnInd- PwrInd-
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
                Link: Supported Speed 2.5Gb/s, Width x1, ASPM unknown, Port 0
                Link: Latency L0s <128ns, L1 <64us
                Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
                Link: Speed 2.5Gb/s, Width x1

Re: Linux 2.6.21-rc1

[Kok, Auke]

Thomas Gleixner wrote:
> On Tue, 2007-02-20 at 20:53 -0800, Linus Torvalds wrote:
>> But there's a ton of architecture updates (arm, mips, powerpc, x86, you 
>> name it), ACPI updates, and lots of driver work. And just a lot of 
>> cleanups.
>>
>> Have fun,
> 
> Yup. Fun starts in drivers/net/e1000
> 
> e1000 is not working anymore. ifup fails permanentely.
>  ADDRCONF(NETDEV_UP): eth0: link is not ready
> nothing else
> 
> bisect identifies:
> 
> d2ed16356ff4fb9de23fbc5e5d582ce580390106 is first bad commit
 > commit d2ed16356ff4fb9de23fbc5e5d582ce580390106

I think we need to drop this now. The report that says that this *fixes* 
something might have been on regular interrupts only. I currently suspect that 
it breaks all MSI interrupts, which would make sense if I look a the code. Very 
bad indeed.

I'll try to come up with something else or send a patch that reverts it.

Auke

Re: Linux 2.6.21-rc1

[Linus Torvalds]

On Wed, 21 Feb 2007, Kok, Auke wrote:
> 
> I think we need to drop this now. The report that says that this *fixes*
> something might have been on regular interrupts only. I currently suspect that
> it breaks all MSI interrupts, which would make sense if I look a the code.
> Very bad indeed.
> 
> I'll try to come up with something else or send a patch that reverts it.

I'm going to be off-line for a couple of days, so I just reverted it.

		Linus

---
commit b5bf28cde894b3bb3bd25c13a7647020562f9ea0
Author: Linus Torvalds <torvalds@woody.linux-foundation.org>
Date:   Wed Feb 21 11:21:44 2007 -0800

    Revert "e1000: fix shared interrupt warning message"
    
    This reverts commit d2ed16356ff4fb9de23fbc5e5d582ce580390106.
    
    As Thomas Gleixner reports:
      "e1000 is not working anymore. ifup fails permanentely.
        ADDRCONF(NETDEV_UP): eth0: link is not ready
       nothing else"
    
    The broken commit was identified with "git bisect".
    
    Auke Kok says:
      "I think we need to drop this now.  The report that says that this
       *fixes* something might have been on regular interrupts only.  I
       currently suspect that it breaks all MSI interrupts, which would make
       sense if I look a the code.  Very bad indeed."
    
    Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
    Acked-by: Auke Kok <auke-jan.h.kok@intel.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Jeff Garzik <jeff@garzik.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index a710237..98215fd 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1417,6 +1417,10 @@ e1000_open(struct net_device *netdev)
 	if ((err = e1000_setup_all_rx_resources(adapter)))
 		goto err_setup_rx;
 
+	err = e1000_request_irq(adapter);
+	if (err)
+		goto err_req_irq;
+
 	e1000_power_up_phy(adapter);
 
 	if ((err = e1000_up(adapter)))
@@ -1427,10 +1431,6 @@ e1000_open(struct net_device *netdev)
 		e1000_update_mng_vlan(adapter);
 	}
 
-	err = e1000_request_irq(adapter);
-	if (err)
-		goto err_req_irq;
-
 	/* If AMT is enabled, let the firmware know that the network
 	 * interface is now open */
 	if (adapter->hw.mac_type == e1000_82573 &&
@@ -1439,10 +1439,10 @@ e1000_open(struct net_device *netdev)
 
 	return E1000_SUCCESS;
 
-err_req_irq:
-	e1000_down(adapter);
 err_up:
 	e1000_power_down_phy(adapter);
+	e1000_free_irq(adapter);
+err_req_irq:
 	e1000_free_all_rx_resources(adapter);
 err_setup_rx:
 	e1000_free_all_tx_resources(adapter);

Re: Linux 2.6.21-rc1

[Andrew Morton]

On Wed, 21 Feb 2007 11:24:33 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> 
> On Wed, 21 Feb 2007, Kok, Auke wrote:
> > 
> > I think we need to drop this now. The report that says that this *fixes*
> > something might have been on regular interrupts only. I currently suspect that
> > it breaks all MSI interrupts, which would make sense if I look a the code.
> > Very bad indeed.
> > 
> > I'll try to come up with something else or send a patch that reverts it.
> 
> I'm going to be off-line for a couple of days,

And I'll be offline for five or six days.

> so I just reverted it.

OK, but this change was needed because the new IRQ-debugging code reliably
causes e1000 to explode.

So perhaps until e1000 gets sorted out we should disable the debug code:

--- a/lib/Kconfig.debug~a
+++ a/lib/Kconfig.debug
@@ -79,7 +79,7 @@ config DEBUG_KERNEL
 
 config DEBUG_SHIRQ
 	bool "Debug shared IRQ handlers"
-	depends on DEBUG_KERNEL && GENERIC_HARDIRQS
+	depends on DEBUG_KERNEL && GENERIC_HARDIRQS && BROKEN
 	help
 	  Enable this to generate a spurious interrupt as soon as a shared
 	  interrupt handler is registered, and just before one is deregistered.
_

request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1)

[YOSHIFUJI Hideaki / 吉藤英明]

Hello.

In article <Pine.LNX.4.64.0702202043280.4043@woody.linux-foundation.org> (at Tue, 20 Feb 2007 20:53:45 -0800 (PST)), Linus Torvalds <torvalds@linux-foundation.org> says:

> But there's a ton of architecture updates (arm, mips, powerpc, x86, you 
> name it), ACPI updates, and lots of driver work. And just a lot of 
> cleanups.

I cannot boot 2.6.21-rc1; it falls into OOM-Killer.

Interesting error message I can see is:
   request_module: runaway loop modprobe net-pf-1

After bisecting, the commit
  Driver core: let request_module() send a /sys/modules/kmod/-uevent
(id c353c3fb0700a3c17ea2b0237710a184232ccd7f) is to blame.

Reverting it fixes the issue to me.

Regards,

--yoshfuji

Re: request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1)

[Greg KH]

On Thu, Feb 22, 2007 at 04:12:04AM +0900, OGAWA Hirofumi wrote:
> YOSHIFUJI Hideaki / ?$B5HF#1QL@ <yoshfuji@linux-ipv6.org> writes:
> 
> > In article <Pine.LNX.4.64.0702202043280.4043@woody.linux-foundation.org> (at Tue, 20 Feb 2007 20:53:45 -0800 (PST)), Linus Torvalds <torvalds@linux-foundation.org> says:
> >
> >> But there's a ton of architecture updates (arm, mips, powerpc, x86, you 
> >> name it), ACPI updates, and lots of driver work. And just a lot of 
> >> cleanups.
> >
> > I cannot boot 2.6.21-rc1; it falls into OOM-Killer.
> >
> > Interesting error message I can see is:
> >    request_module: runaway loop modprobe net-pf-1
> >
> > After bisecting, the commit
> >   Driver core: let request_module() send a /sys/modules/kmod/-uevent
> > (id c353c3fb0700a3c17ea2b0237710a184232ccd7f) is to blame.
> >
> > Reverting it fixes the issue to me.
> 
> /sbin/hotplug needs some module, but request_module() call /sbin/hotplug loop?
> Hm.. does the patch fix the problem?

How does it loop?

> BTW, mod_request_helper alias of /proc/sys/kernel/modprobe is really needed?

What do you mean?

> -- 
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> 
> 
> Don't use uevent until udevd or something like other setup done.
> 
> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> ---
> 
>  kernel/kmod.c |    8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff -puN kernel/kmod.c~kmod-uevent-fix kernel/kmod.c
> --- linux-2.6/kernel/kmod.c~kmod-uevent-fix	2007-02-22 03:42:37.000000000 +0900
> +++ linux-2.6-hirofumi/kernel/kmod.c	2007-02-22 03:42:48.000000000 +0900
> @@ -90,11 +90,11 @@ int request_module(const char *fmt, ...)
>  	if (ret >= MODULE_NAME_LEN)
>  		return -ENAMETOOLONG;
>  
> -	strcpy(&modalias[strlen("MODALIAS=")], module_name);
> -	kobject_uevent_env(&kmod_mk.kobj, KOBJ_CHANGE, uevent_envp);
> -
> -	if (modprobe_path[0] == '\0')
> +	if (modprobe_path[0] == '\0') {
> +		strcpy(&modalias[strlen("MODALIAS=")], module_name);
> +		kobject_uevent_env(&kmod_mk.kobj, KOBJ_CHANGE, uevent_envp);
>  		goto out;
> +	}

No, we want to still emit these messgages, even if we have a real
"helper" application.  I don't see how this would fix the problem.

thanks,

greg k-h

Re: request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1)

[OGAWA Hirofumi]

Greg KH <greg@kroah.com> writes:

> On Thu, Feb 22, 2007 at 04:12:04AM +0900, OGAWA Hirofumi wrote:
>> YOSHIFUJI Hideaki / ?$B5HF#1QL@ <yoshfuji@linux-ipv6.org> writes:
>> 
>> > In article <Pine.LNX.4.64.0702202043280.4043@woody.linux-foundation.org> (at Tue, 20 Feb 2007 20:53:45 -0800 (PST)), Linus Torvalds <torvalds@linux-foundation.org> says:
>> >
>> >> But there's a ton of architecture updates (arm, mips, powerpc, x86, you 
>> >> name it), ACPI updates, and lots of driver work. And just a lot of 
>> >> cleanups.
>> >
>> > I cannot boot 2.6.21-rc1; it falls into OOM-Killer.
>> >
>> > Interesting error message I can see is:
>> >    request_module: runaway loop modprobe net-pf-1
>> >
>> > After bisecting, the commit
>> >   Driver core: let request_module() send a /sys/modules/kmod/-uevent
>> > (id c353c3fb0700a3c17ea2b0237710a184232ccd7f) is to blame.
>> >
>> > Reverting it fixes the issue to me.
>> 
>> /sbin/hotplug needs some module, but request_module() call /sbin/hotplug loop?
>> Hm.. does the patch fix the problem?
>
> How does it loop?

E.g. something calls the request_modle(), and if hotplug is using
socket(PF_UNIX) and af_unix is module, it also calls request_modle()?

Just my guess though...
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Re: request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1)

[Greg KH]

On Thu, Feb 22, 2007 at 06:16:23AM +0900, OGAWA Hirofumi wrote:
> Greg KH <greg@kroah.com> writes:
> 
> > On Thu, Feb 22, 2007 at 04:12:04AM +0900, OGAWA Hirofumi wrote:
> >> YOSHIFUJI Hideaki / ?$B5HF#1QL@ <yoshfuji@linux-ipv6.org> writes:
> >> 
> >> > In article <Pine.LNX.4.64.0702202043280.4043@woody.linux-foundation.org> (at Tue, 20 Feb 2007 20:53:45 -0800 (PST)), Linus Torvalds <torvalds@linux-foundation.org> says:
> >> >
> >> >> But there's a ton of architecture updates (arm, mips, powerpc, x86, you 
> >> >> name it), ACPI updates, and lots of driver work. And just a lot of 
> >> >> cleanups.
> >> >
> >> > I cannot boot 2.6.21-rc1; it falls into OOM-Killer.
> >> >
> >> > Interesting error message I can see is:
> >> >    request_module: runaway loop modprobe net-pf-1
> >> >
> >> > After bisecting, the commit
> >> >   Driver core: let request_module() send a /sys/modules/kmod/-uevent
> >> > (id c353c3fb0700a3c17ea2b0237710a184232ccd7f) is to blame.
> >> >
> >> > Reverting it fixes the issue to me.
> >> 
> >> /sbin/hotplug needs some module, but request_module() call /sbin/hotplug loop?
> >> Hm.. does the patch fix the problem?
> >
> > How does it loop?
> 
> E.g. something calls the request_modle(), and if hotplug is using
> socket(PF_UNIX) and af_unix is module, it also calls request_modle()?
> 
> Just my guess though...

Ugh, why does anyone make af_unix a module these days.  I thought only
Debian was that foolish...  :)

It will be interesting to see if this fixes the issue or not.

thanks,

greg k-h

Re: request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1)

[Anders Larsen]

On 2007-02-22 01:18:09, Greg KH wrote:
> On Thu, Feb 22, 2007 at 06:16:23AM +0900, OGAWA Hirofumi wrote:
> > E.g. something calls the request_modle(), and if hotplug is using
> > socket(PF_UNIX) and af_unix is module, it also calls request_modle()?
> > 
> > Just my guess though...
> 
> Ugh, why does anyone make af_unix a module these days.  I thought only
> Debian was that foolish...  :)

Then how about making CONFIG_UNIX bool instead of tristate?

Cheers
 Anders

diff --git a/net/unix/Kconfig b/net/unix/Kconfig
index 5a69733..b589254 100644
--- a/net/unix/Kconfig
+++ b/net/unix/Kconfig
@@ -3,7 +3,7 @@
 #

 config UNIX
-       tristate "Unix domain sockets"
+       bool "Unix domain sockets"
        ---help---
          If you say Y here, you will include support for Unix domain sockets;
          sockets are the standard Unix mechanism for establishing and
@@ -13,9 +13,5 @@ config UNIX
          an embedded system or something similar, you therefore definitely
          want to say Y here.

-         To compile this driver as a module, choose M here: the module will be
-         called unix.  Note that several important services won't work
-         correctly if you say M here and then neglect to load the module.
-
          Say Y unless you know what you are doing.

Re: request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1)

[David Miller]

From: Anders Larsen <al@alarsen.net>
Date: Thu, 22 Feb 2007 10:57:47 +0100

> On 2007-02-22 01:18:09, Greg KH wrote:
> > On Thu, Feb 22, 2007 at 06:16:23AM +0900, OGAWA Hirofumi wrote:
> > > E.g. something calls the request_modle(), and if hotplug is using
> > > socket(PF_UNIX) and af_unix is module, it also calls request_modle()?
> > > 
> > > Just my guess though...
> > 
> > Ugh, why does anyone make af_unix a module these days.  I thought only
> > Debian was that foolish...  :)
> 
> Then how about making CONFIG_UNIX bool instead of tristate?

Please see the archives, there have been discussions about this
kind of suggestion before.

We should not dis-allow AF_UNIX being modular just because it
now becomes inconvenient.

Re: request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1)

[Greg KH]

On Thu, Feb 22, 2007 at 12:34:17PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> In article <20070222.110440.47345562.yoshfuji@linux-ipv6.org> (at Thu, 22 Feb 2007 11:04:40 +0900 (JST)), YOSHIFUJI Hideaki / ?$B5HF#1QL@ <yoshfuji@linux-ipv6.org> says:
> 
> > In article <87ps8372bf.fsf@duaron.myhome.or.jp> (at Thu, 22 Feb 2007 04:12:04 +0900), OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> says:
> > 
> > > YOSHIFUJI Hideaki / ?$B5HF#1QL@ <yoshfuji@linux-ipv6.org> writes:
> > > 
> > > > In article <Pine.LNX.4.64.0702202043280.4043@woody.linux-foundation.org> (at Tue, 20 Feb 2007 20:53:45 -0800 (PST)), Linus Torvalds <torvalds@linux-foundation.org> says:
> > > >
> > > >> But there's a ton of architecture updates (arm, mips, powerpc, x86, you 
> > > >> name it), ACPI updates, and lots of driver work. And just a lot of 
> > > >> cleanups.
> > > >
> > > > I cannot boot 2.6.21-rc1; it falls into OOM-Killer.
> > > >
> > > > Interesting error message I can see is:
> > > >    request_module: runaway loop modprobe net-pf-1
> > > >
> > > > After bisecting, the commit
> > > >   Driver core: let request_module() send a /sys/modules/kmod/-uevent
> > > > (id c353c3fb0700a3c17ea2b0237710a184232ccd7f) is to blame.
> > > >
> > > > Reverting it fixes the issue to me.
> > > 
> > > /sbin/hotplug needs some module, but request_module() call /sbin/hotplug loop?
> > > Hm.. does the patch fix the problem?
> > 
> > Yes, it absolutely fixes the issue.
> 
> Several options:
> 
> - To revert the changeset to blame

No.

> - To apply Ogawa-san's (or other appropriate) patch

His patch just avoids the issue, but isn't correct.

> - To select UNIX in init/Kconfig:KMOD

I like this one, but some people might still want it as a module (I
really don't know why, does anyone else???)

> I think it would be a good idea to rate-limit frequency of requesing a
> single module, anyway.

Yes, if we can detect the loop, that would be best.

Or, maybe the easiest thing is to just not do the netlink call if it's
asking for the network module?  :)

Any other suggestions or thoughts?

thanks,

greg k-h

Re: Linux 2.6.21-rc1

[Daniel Walker]

On Tue, 2007-02-20 at 20:53 -0800, Linus Torvalds wrote:
> Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
> 
> There's a lot of changes, as is usual for an -rc1 thing, but at least so 
> far it would seem that 2.6.20 has been a good base, and I don't think we 
> have anything *really* scary here.
> 
> The most interesting core change may be the dyntick/nohz one, where timer 
> ticks will only happen when needed. It's been brewing for a _loong_ time, 
> but it's in the standard kernel now as an option. 

On i386 I get the following,

TCP cubic registered                                                            
NET: Registered protocol family 1                                               
NET: Registered protocol family 17                                              
Testing NMI watchdog ... CPU#0: NMI appears to be stuck (24->24)!               
CPU#1: NMI appears to be stuck (0->0)!                                          
CPU#2: NMI appears to be stuck (0->0)!                                          
CPU#3: NMI appears to be stuck (0->0)!              

when I add nmi_watchdog=1 to my boot args which worked on prior kernels.
On closer inspection it looks like arch/i386/kernel/io_apic.c :
check_timer() --> timer_irq_works() depends on IRQ0 incrementing jiffies
which is no longer the case AFAIK.

I'm not sure exactly how that relates to the NMI, but the check_timer()
function disabled the NMI through the io-apic if it can't get the
"timer" working through the io-apic.

Daniel

Re: Linux 2.6.21-rc1

[Thomas Gleixner]

On Wed, 2007-02-21 at 08:24 -0800, Daniel Walker wrote:
> > The most interesting core change may be the dyntick/nohz one, where timer 
> > ticks will only happen when needed. It's been brewing for a _loong_ time, 
> > but it's in the standard kernel now as an option. 
> 
> On i386 I get the following,
> 
> TCP cubic registered                                                            
> NET: Registered protocol family 1                                               
> NET: Registered protocol family 17                                              
> Testing NMI watchdog ... CPU#0: NMI appears to be stuck (24->24)!               
> CPU#1: NMI appears to be stuck (0->0)!                                          
> CPU#2: NMI appears to be stuck (0->0)!                                          
> CPU#3: NMI appears to be stuck (0->0)!              
> 
> when I add nmi_watchdog=1 to my boot args which worked on prior kernels.
> On closer inspection it looks like arch/i386/kernel/io_apic.c :
> check_timer() --> timer_irq_works() depends on IRQ0 incrementing jiffies
> which is no longer the case AFAIK.

At this point the PIT / HPET _is_ active and incrementing jiffies. The
switch to local apic timers happens afterwards. 

> I'm not sure exactly how that relates to the NMI, but the check_timer()
> function disabled the NMI through the io-apic if it can't get the
> "timer" working through the io-apic.

Boot log please.

	tglx

Re: Linux 2.6.21-rc1

[Daniel Walker]

On Wed, 2007-02-21 at 18:07 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 08:24 -0800, Daniel Walker wrote:
> > > The most interesting core change may be the dyntick/nohz one, where timer 
> > > ticks will only happen when needed. It's been brewing for a _loong_ time, 
> > > but it's in the standard kernel now as an option. 
> > 
> > On i386 I get the following,
> > 
> > TCP cubic registered                                                            
> > NET: Registered protocol family 1                                               
> > NET: Registered protocol family 17                                              
> > Testing NMI watchdog ... CPU#0: NMI appears to be stuck (24->24)!               
> > CPU#1: NMI appears to be stuck (0->0)!                                          
> > CPU#2: NMI appears to be stuck (0->0)!                                          
> > CPU#3: NMI appears to be stuck (0->0)!              
> > 
> > when I add nmi_watchdog=1 to my boot args which worked on prior kernels.
> > On closer inspection it looks like arch/i386/kernel/io_apic.c :
> > check_timer() --> timer_irq_works() depends on IRQ0 incrementing jiffies
> > which is no longer the case AFAIK.
> 
> At this point the PIT / HPET _is_ active and incrementing jiffies. The
> switch to local apic timers happens afterwards. 

Could be the switch over then which confuses the NMI . 

> > I'm not sure exactly how that relates to the NMI, but the check_timer()
> > function disabled the NMI through the io-apic if it can't get the
> > "timer" working through the io-apic.
> 
> Boot log please.
> 
> 	tglx
> 

.config is in there too .

ftp://source.mvista.com/pub/dwalker/tglx/

Re: Linux 2.6.21-rc1

[Thomas Gleixner]

On Wed, 2007-02-21 at 09:19 -0800, Daniel Walker wrote:
> > At this point the PIT / HPET _is_ active and incrementing jiffies. The
> > switch to local apic timers happens afterwards. 
> 
> Could be the switch over then which confuses the NMI . 

Why? The switch just stops the PIT/HPET. It does not fiddle with IO_APIC
and friends at all.

> ftp://source.mvista.com/pub/dwalker/tglx/

Nothing obvious. Bisect time :(

	tglx

Re: Linux 2.6.21-rc1

[Daniel Walker]

On Wed, 2007-02-21 at 18:41 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 09:19 -0800, Daniel Walker wrote:
> > > At this point the PIT / HPET _is_ active and incrementing jiffies. The
> > > switch to local apic timers happens afterwards. 
> > 
> > Could be the switch over then which confuses the NMI . 
> 
> Why? The switch just stops the PIT/HPET. It does not fiddle with IO_APIC
> and friends at all.

I'm not an expert on the io-apic, but the check_timer() function seemed
to assume IRQ0 was happening regularly ..

> > ftp://source.mvista.com/pub/dwalker/tglx/
> 
> Nothing obvious. Bisect time :(

Well, I'm pretty sure it's HRT, cause in prior versions this only
happened when HRT is enabled. Then you guys went to the lapic all the
time, and now this is happening all the time ..

You can't reproduce this?

Daniel

Re: Linux 2.6.21-rc1

[Thomas Gleixner]

On Wed, 2007-02-21 at 09:38 -0800, Daniel Walker wrote:
> > > 
> > > Could be the switch over then which confuses the NMI . 
> > 
> > Why? The switch just stops the PIT/HPET. It does not fiddle with IO_APIC
> > and friends at all.
> 
> I'm not an expert on the io-apic, but the check_timer() function seemed
> to assume IRQ0 was happening regularly ..

Again: 

check_timer() is called _BEFORE_ we even touch the local APIC timers. At
this point PIT/HPET _IS_ firing IRQ0 with HZ frequency.

> Well, I'm pretty sure it's HRT, cause in prior versions this only
> happened when HRT is enabled. Then you guys went to the lapic all the
> time, and now this is happening all the time ..

The NMI is stuck:

                if (nmi_count(cpu) - prev_nmi_count[cpu] <= 5) {
                        printk("CPU#%d: NMI appears to be stuck (%d->%d)!\n",
                                cpu,
                                prev_nmi_count[cpu],
                                nmi_count(cpu));

This has nothing to do with jiffies.

There have been a bunch of changes in arch/i386/kernel/nmi.c as well. 

> You can't reproduce this?

Nope.

Also all my machines emit something like:
"ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])"

In your boot log nothing to see.

	tglx

Re: Linux 2.6.21-rc1

[Daniel Walker]

On Wed, 2007-02-21 at 19:18 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 09:38 -0800, Daniel Walker wrote:
> > > > 
> > > > Could be the switch over then which confuses the NMI . 
> > > 
> > > Why? The switch just stops the PIT/HPET. It does not fiddle with IO_APIC
> > > and friends at all.
> > 
> > I'm not an expert on the io-apic, but the check_timer() function seemed
> > to assume IRQ0 was happening regularly ..
> 
> Again: 
> 
> check_timer() is called _BEFORE_ we even touch the local APIC timers. At
> this point PIT/HPET _IS_ firing IRQ0 with HZ frequency.

Right, but eventually there isn't a regular timer interrupt through the
io-apic. I don't think in the past IRQ0 stops without the system
crashing, so check_timer() could assume the timer (IRQ0) is _always_
regular.

do you know what the requirement are for routing the NMI through the
io-apic? 

> > Well, I'm pretty sure it's HRT, cause in prior versions this only
> > happened when HRT is enabled. Then you guys went to the lapic all the
> > time, and now this is happening all the time ..
> 
> The NMI is stuck:
> 
>                 if (nmi_count(cpu) - prev_nmi_count[cpu] <= 5) {
>                         printk("CPU#%d: NMI appears to be stuck (%d->%d)!\n",
>                                 cpu,
>                                 prev_nmi_count[cpu],
>                                 nmi_count(cpu));
> 
> This has nothing to do with jiffies.

I think it has to do with IRQ0 . Did I mention this doesn't happen in
2.6.20 .

> There have been a bunch of changes in arch/i386/kernel/nmi.c as well. 
> 
> > You can't reproduce this?
> 
> Nope.

Do you use nmi_watchdog=1 ?

Daniel

Re: Linux 2.6.21-rc1

[Thomas Gleixner]

On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
> Right, but eventually there isn't a regular timer interrupt through the
> io-apic. I don't think in the past IRQ0 stops without the system
> crashing, so check_timer() could assume the timer (IRQ0) is _always_
> regular.
> 
> do you know what the requirement are for routing the NMI through the
> io-apic? 

Sorry. I checked. switching PIT off really breaks nmi_watchdog=1, as
this just mirrors IRQ#0 to the NMI. No IRQ#0 from PIT, no NMI

We could keep PIT running with an empty interrupt handler when
nmi_watchdog=1 is set, but this interferes nicely with broadcasting.

Does nmi_watchdog=2 work ? We might switch to that, when a local APIC is
available. 

	tglx

Re: Linux 2.6.21-rc1

[Daniel Walker]

On Wed, 2007-02-21 at 20:23 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
> > Right, but eventually there isn't a regular timer interrupt through the
> > io-apic. I don't think in the past IRQ0 stops without the system
> > crashing, so check_timer() could assume the timer (IRQ0) is _always_
> > regular.
> > 
> > do you know what the requirement are for routing the NMI through the
> > io-apic? 
> 
> Sorry. I checked. switching PIT off really breaks nmi_watchdog=1, as
> this just mirrors IRQ#0 to the NMI. No IRQ#0 from PIT, no NMI

That's what I suspected ..

> We could keep PIT running with an empty interrupt handler when
> nmi_watchdog=1 is set, but this interferes nicely with broadcasting.
> 
> Does nmi_watchdog=2 work ? We might switch to that, when a local APIC is
> available. 

Oddly, nmi_watchdog=2 doesn't work in 2.6.21-rc1, but it works in
2.6.20-rt8 however I'm not sure of the config could have been PREEMPT_RT
was on.

Daniel

Re: Linux 2.6.21-rc1

[Daniel Walker]

On Wed, 2007-02-21 at 20:23 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 10:23 -0800, Daniel Walker wrote:
> > Right, but eventually there isn't a regular timer interrupt through the
> > io-apic. I don't think in the past IRQ0 stops without the system
> > crashing, so check_timer() could assume the timer (IRQ0) is _always_
> > regular.
> > 
> > do you know what the requirement are for routing the NMI through the
> > io-apic? 
> 
> Sorry. I checked. switching PIT off really breaks nmi_watchdog=1, as
> this just mirrors IRQ#0 to the NMI. No IRQ#0 from PIT, no NMI
> 
> We could keep PIT running with an empty interrupt handler when
> nmi_watchdog=1 is set, but this interferes nicely with broadcasting.
> 
> Does nmi_watchdog=2 work ? We might switch to that, when a local APIC is
> available. 
> 
> 	tglx
> 
> 


There's a compile failure during my bisect.

distcc[3863] ERROR: compile /tmp//hrtimer.tmp.dwalker1.3795.i on dwalker3/120 failed
kernel/hrtimer.c: In function 'hrtimer_cpu_notify':
kernel/hrtimer.c:884: warning: implicit declaration of function 'clockevents_notify'
kernel/hrtimer.c:884: error: 'CLOCK_EVT_NOTIFY_CPU_DEAD' undeclared (first use in this function)
kernel/hrtimer.c:884: error: (Each undeclared identifier is reported only once 
kernel/hrtimer.c:884: error: for each function it appears in.)
drivers/ide/setup-pci.c: In function 'ide_scan_pcibus':
drivers/ide/setup-pci.c:866: warning: ignoring return value of '__pci_register_driver', declared with attribute warn_unused_result
make[1]: *** [kernel/hrtimer.o] Error 1


from this commit,

commit f8381cba04ba8173fd5a2b8e5cd8b3290ee13a98
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Feb 16 01:28:02 2007 -0800

    [PATCH] tick-management: broadcast functionality
    
    With Ingo Molnar <mingo@elte.hu>
    
    Add broadcast functionality, so per cpu clock event devices can be registere
    as dummy devices or switched from/to broadcast on demand.  The broadcast
    function distributes the events via the broadcast function of the clock even
    device.  This is primarily designed to replace the switch apic timer to / fr
    IPI in power states, where the apic stops.
    

Re: Linux 2.6.21-rc1

[Linus Torvalds]

On Wed, 21 Feb 2007, Daniel Walker wrote:
> 
> There's a compile failure during my bisect.

When that happens, you need to pick another commit to try than the one git 
selected for you automatically. You can do that by doing

	git bisect visualize

and select another commit somewhere fairly close to a mid-point, and try 
that with

	git reset --hard <commit-sha1>

instead.

		Linus

Re: Linux 2.6.21-rc1

[Thomas Gleixner]

On Wed, 2007-02-21 at 12:00 -0800, Daniel Walker wrote:
> There's a compile failure during my bisect.
> 
> distcc[3863] ERROR: compile /tmp//hrtimer.tmp.dwalker1.3795.i on dwalker3/120 failed
> kernel/hrtimer.c: In function 'hrtimer_cpu_notify':
> kernel/hrtimer.c:884: warning: implicit declaration of function 'clockevents_notify'
> kernel/hrtimer.c:884: error: 'CLOCK_EVT_NOTIFY_CPU_DEAD' undeclared (first use in this function)
> kernel/hrtimer.c:884: error: (Each undeclared identifier is reported only once 
> kernel/hrtimer.c:884: error: for each function it appears in.)
> drivers/ide/setup-pci.c: In function 'ide_scan_pcibus':
> drivers/ide/setup-pci.c:866: warning: ignoring return value of '__pci_register_driver', declared with attribute warn_unused_result
> make[1]: *** [kernel/hrtimer.o] Error 1

hrmpf. we made it bisectable at some point.

	tglx

Re: Linux 2.6.21-rc1

[Daniel Walker]

On Wed, 2007-02-21 at 21:43 +0100, Thomas Gleixner wrote:
> On Wed, 2007-02-21 at 12:00 -0800, Daniel Walker wrote:
> > There's a compile failure during my bisect.
> > 
> > distcc[3863] ERROR: compile /tmp//hrtimer.tmp.dwalker1.3795.i on dwalker3/120 failed
> > kernel/hrtimer.c: In function 'hrtimer_cpu_notify':
> > kernel/hrtimer.c:884: warning: implicit declaration of function 'clockevents_notify'
> > kernel/hrtimer.c:884: error: 'CLOCK_EVT_NOTIFY_CPU_DEAD' undeclared (first use in this function)
> > kernel/hrtimer.c:884: error: (Each undeclared identifier is reported only once 
> > kernel/hrtimer.c:884: error: for each function it appears in.)
> > drivers/ide/setup-pci.c: In function 'ide_scan_pcibus':
> > drivers/ide/setup-pci.c:866: warning: ignoring return value of '__pci_register_driver', declared with attribute warn_unused_result
> > make[1]: *** [kernel/hrtimer.o] Error 1
> 
> hrmpf. we made it bisectable at some point.

It was related some code under a hot plug ifdef ..

Here's the final commit from the bisect which caused it . It says "No
changes to existing functionality" ?

e9e2cdb412412326c4827fc78ba27f410d837e6e is first bad commit
commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Fri Feb 16 01:28:04 2007 -0800

    [PATCH] clockevents: i386 drivers

    Add clockevent drivers for i386: lapic (local) and PIT/HPET (global).  Update
    the timer IRQ to call into the PIT/HPET driver's event handler and the
    lapic-timer IRQ to call into the lapic clockevent driver.  The assignement of
    timer functionality is delegated to the core framework code and replaces the
    compile and runtime evalution in do_timer_interrupt_hook()

    Use the clockevents broadcast support and implement the lapic_broadcast
    function for ACPI.

    No changes to existing functionality.

Re: Linux 2.6.21-rc1

[Linus Torvalds]

On Wed, 21 Feb 2007, Daniel Walker wrote:
> 
> Here's the final commit from the bisect which caused it . It says "No
> changes to existing functionality" ?

Ok, it wouldn't be the first time some change that is supposed to change 
nothing does actually change something.

That said, one thing to worry about when doing bisection: the kernel 
configuration.

If you always just do "make oldconfig" or something, the kernel config for 
the thing you test will depend on the _previous_ kernel you compiled, and 
that is not always what you want. I've once had a failing kernel, did 
bisection, and it turned out that since I had gone back in time to before 
the option that caused the failure even existed, I had (by mistake) then 
compiled some of the later kernels without that option enabled, and called 
them "good". 

The end result: "git bisect" didn't actually end up pointing to the right 
commit, just because I had effectively lied to it.

That said, considering that you did get a commit that doesn't look 
entirely unlikely (and that clearly changes things that are relevant), I 
suspect you did actually find the right one.

		Linus
---
> commit e9e2cdb412412326c4827fc78ba27f410d837e6e
> Author: Thomas Gleixner <tglx@linutronix.de>
> Date:   Fri Feb 16 01:28:04 2007 -0800
> 
>     [PATCH] clockevents: i386 drivers
> 
>     Add clockevent drivers for i386: lapic (local) and PIT/HPET (global).  Update
>     the timer IRQ to call into the PIT/HPET driver's event handler and the
>     lapic-timer IRQ to call into the lapic clockevent driver.  The assignement of
>     timer functionality is delegated to the core framework code and replaces the
>     compile and runtime evalution in do_timer_interrupt_hook()
> 
>     Use the clockevents broadcast support and implement the lapic_broadcast
>     function for ACPI.
> 
>     No changes to existing functionality.
> 
> 

Re: Linux 2.6.21-rc1

[Thomas Gleixner]

On Wed, 2007-02-21 at 13:06 -0800, Linus Torvalds wrote:
> That said, considering that you did get a commit that doesn't look 
> entirely unlikely (and that clearly changes things that are relevant), I 
> suspect you did actually find the right one.

Yup, thats the one which switches off PIT after we have the local APIC
timers up and running. Which turns out to cause the nmi_watchdog not
working anymore.

	tglx

Re: Linux 2.6.21-rc1

[Daniel Walker]

On Wed, 2007-02-21 at 13:06 -0800, Linus Torvalds wrote:
> 
> On Wed, 21 Feb 2007, Daniel Walker wrote:
> > 
> > Here's the final commit from the bisect which caused it . It says "No
> > changes to existing functionality" ?
> 
> Ok, it wouldn't be the first time some change that is supposed to change 
> nothing does actually change something.

Yeah , maybe I screwed something up. First time I've done a git bisect.

> That said, one thing to worry about when doing bisection: the kernel 
> configuration.
> 
> If you always just do "make oldconfig" or something, the kernel config for 
> the thing you test will depend on the _previous_ kernel you compiled, and 
> that is not always what you want. I've once had a failing kernel, did 
> bisection, and it turned out that since I had gone back in time to before 
> the option that caused the failure even existed, I had (by mistake) then 
> compiled some of the later kernels without that option enabled, and called 
> them "good". 

In this case I don't think anything was specifically turned on, beyond
SMP. For instance HRT/dynamic tick was off.

I didn't run "make oldconfig", but just running "make" asked for options
that just got added, which was nice.

> The end result: "git bisect" didn't actually end up pointing to the right 
> commit, just because I had effectively lied to it.
> 
> That said, considering that you did get a commit that doesn't look 
> entirely unlikely (and that clearly changes things that are relevant), I 
> suspect you did actually find the right one.

I think if it's not that exact commit it's still one in that set. I
mainly wanted to confirm that it was an hrt/dynamic tick issue , and not
some left field patches..

Daniel

Re: Linux 2.6.21-rc1 [git bisect]

[Pete Harlan]

On Wed, Feb 21, 2007 at 01:06:17PM -0800, Linus Torvalds wrote:
> That said, one thing to worry about when doing bisection: the kernel 
> configuration.

This bit me badly the one time I did a git bisect; it kept ping-
ponging around a big change (sata? xtables?) that required me to
answer the same two dozen questions about ten different times.

If git-bisect itself could manage .config as part of the process,
reverting to the one used with the most-recently-in-the-past try when
it backs up to a revision, that would be, you know, wonderful.

--Pete

----------------------------------
Pete Harlan
ArtSelect, Inc.
harlan@artselect.com
http://www.artselect.com
ArtSelect is a subsidiary of a21, Inc.

Re: Linux 2.6.21-rc1

[Andrew Morton]

> On Wed, 21 Feb 2007 18:41:11 +0100 Thomas Gleixner <tglx@linutronix.de> wrote:
> On Wed, 2007-02-21 at 09:19 -0800, Daniel Walker wrote:
> > > At this point the PIT / HPET _is_ active and incrementing jiffies. The
> > > switch to local apic timers happens afterwards. 
> > 
> > Could be the switch over then which confuses the NMI . 
> 
> Why? The switch just stops the PIT/HPET. It does not fiddle with IO_APIC
> and friends at all.
> 
> > ftp://source.mvista.com/pub/dwalker/tglx/
> 
> Nothing obvious. Bisect time :(
> 

I already bisected this on my old pIII, which has the same problem:
clockevents-i386-drivers.patch

Re: Linux 2.6.21-rc1

[Ingo Molnar]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> I already bisected this on my old pIII, which has the same problem: 
> clockevents-i386-drivers.patch

yes - we know what the problem is (and will fix it): the stopping of the 
PIT - nmi_watchdog=1 is hack to use the IO-APIC's PIT pin to also signal 
NMIs.

Just to clarify, this problem does not occur if HIGH_RES_TIMERS is off, 
correct?

	Ingo

Re: Linux 2.6.21-rc1

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > I already bisected this on my old pIII, which has the same problem: 
> > clockevents-i386-drivers.patch
> 
> yes - we know what the problem is (and will fix it): the stopping of the 
> PIT - nmi_watchdog=1 is hack to use the IO-APIC's PIT pin to also signal 
> NMIs.
> 
> Just to clarify, this problem does not occur if HIGH_RES_TIMERS is 
> off, correct?

s/does not occur/does occur/

we switch off the PIT whenever we can.

	Ingo

Re: Linux 2.6.21-rc1

[Thomas Gleixner]

On Fri, 2007-02-23 at 12:35 +0100, Ingo Molnar wrote:
> * Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > I already bisected this on my old pIII, which has the same problem: 
> > clockevents-i386-drivers.patch
> 
> yes - we know what the problem is (and will fix it): the stopping of the 
> PIT - nmi_watchdog=1 is hack to use the IO-APIC's PIT pin to also signal 
> NMIs.
> 
> Just to clarify, this problem does not occur if HIGH_RES_TIMERS is off, 
> correct?

It does, as we switch off PIT when lapic is available in any case.

	tglx

Re: Linux 2.6.21-rc1

[Andreas Schwab]

I'm getting an undefined symbol with CONFIG_AGP=m:

WARNING: "compat_agp_ioctl" [drivers/char/agp/agpgart.ko] undefined!

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Linux 2.6.21-rc1

[Dave Jones]

On Wed, Feb 21, 2007 at 07:34:01PM +0100, Andreas Schwab wrote:
 > I'm getting an undefined symbol with CONFIG_AGP=m:
 > 
 > WARNING: "compat_agp_ioctl" [drivers/char/agp/agpgart.ko] undefined!

Fix went to Linus an hour ago.
It's been in -mm for a week, and agpgart.git for a day or so.

		Dave

-- 
http://www.codemonkey.org.uk

NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Luca Tettamanti]

Linus Torvalds <torvalds@linux-foundation.org> ha scritto:
> Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
> 
> There's a lot of changes, as is usual for an -rc1 thing, but at least so 
> far it would seem that 2.6.20 has been a good base, and I don't think we 
> have anything *really* scary here.
> 
> The most interesting core change may be the dyntick/nohz one, where timer 
> ticks will only happen when needed. It's been brewing for a _loong_ time, 
> but it's in the standard kernel now as an option. 

Hi Thomas,
I'm testing NO_HZ on my machines. On the laptop I see that the timer
interrupt counter is incremented (though slower than HZ). This machine
is running UP kernel.

On my desktop I see this:

           CPU0       CPU1       
  0:        114          0   IO-APIC-edge      timer
  1:       1624      10771   IO-APIC-edge      i8042
  6:          3          0   IO-APIC-edge      floppy
  7:          0          0   IO-APIC-edge      parport0
  9:          0          0   IO-APIC-fasteoi   acpi
 12:      40111     184047   IO-APIC-edge      i8042
 16:      75624     998858   IO-APIC-fasteoi   radeon@pci:0000:01:00.0, uhci_hcd:usb1
 17:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
 18:        711       5487   IO-APIC-fasteoi   ide1, libata, ehci_hcd:usb7, uhci_hcd:usb3
 19:        617       2254   IO-APIC-fasteoi   libata, uhci_hcd:usb2
 20:          0          0   IO-APIC-fasteoi   ehci_hcd:usb6, uhci_hcd:usb5
 21:    2483869          0   IO-APIC-fasteoi   eth0
 22:          2          0   IO-APIC-fasteoi   ohci1394
218:      28872     360643   PCI-MSI-edge      HDA Intel
219:      32932     138196   PCI-MSI-edge      libata
NMI:          0          0 
LOC:    2761191    2827539 
ERR:          0
MIS:          0

Interrupt 0 is stuck at 114 (the number is consistent across reboots). I
don't experience any problem, time is running fine. Still it's strange
that the timer is doing nothing; maybe something other than the PIT is
used for time keeping?

This is the dmesg of the "abnormal" machine (dual core, SMP kernel):

Linux version 2.6.20-ge696268a-dirty (kronos@dreamland.darkstar.lan) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #33 SMP PREEMPT Tue Feb 20 23:24:24 CET 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 000000000009c800 end: 000000000009c800 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000000009c800 size: 0000000000003800 end: 00000000000a0000 type: 2
copy_e820_map() start: 00000000000e4000 size: 000000000001c000 end: 0000000000100000 type: 2
copy_e820_map() start: 0000000000100000 size: 000000003fe90000 end: 000000003ff90000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000003ff90000 size: 000000000000e000 end: 000000003ff9e000 type: 3
copy_e820_map() start: 000000003ff9e000 size: 0000000000042000 end: 000000003ffe0000 type: 4
copy_e820_map() start: 000000003ffe0000 size: 0000000000020000 end: 0000000040000000 type: 2
copy_e820_map() start: 00000000fee00000 size: 0000000000001000 end: 00000000fee01000 type: 2
copy_e820_map() start: 00000000ffb00000 size: 0000000000500000 end: 0000000100000000 type: 2
 BIOS-e820: 0000000000000000 - 000000000009c800 (usable)
 BIOS-e820: 000000000009c800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003ff90000 (usable)
 BIOS-e820: 000000003ff90000 - 000000003ff9e000 (ACPI data)
 BIOS-e820: 000000003ff9e000 - 000000003ffe0000 (ACPI NVS)
 BIOS-e820: 000000003ffe0000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
1023MB LOWMEM available.
found SMP MP-table at 000ff780
Entering add_active_range(0, 0, 262032) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   262032
early_node_map[1] active PFN ranges
    0:        0 ->   262032
On node 0 totalpages: 262032
  DMA zone: 32 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4064 pages, LIFO batch:0
  Normal zone: 2015 pages used for memmap
  Normal zone: 255921 pages, LIFO batch:31
DMI 2.4 present.
ACPI: RSDP 000FA980, 0024 (r2 ACPIAM)
ACPI: XSDT 3FF90100, 0054 (r1 KOZIRO FRONTIER 12000611 MSFT       97)
ACPI: FACP 3FF90290, 00F4 (r3 MSTEST OEMFACP  12000611 MSFT       97)
ACPI: DSDT 3FF905C0, 8F8C (r1  A0637 A0637000        0 INTL 20060113)
ACPI: FACS 3FF9E000, 0040
ACPI: APIC 3FF90390, 006C (r1 MSTEST OEMAPIC  12000611 MSFT       97)
ACPI: MCFG 3FF90400, 003C (r1 MSTEST OEMMCFG  12000611 MSFT       97)
ACPI: SLIC 3FF90440, 0176 (r1 KOZIRO FRONTIER 12000611 MSFT       97)
ACPI: OEMB 3FF9E040, 007B (r1 MSTEST AMI_OEM  12000611 MSFT       97)
ACPI: HPET 3FF99550, 0038 (r1 MSTEST OEMHPET  12000611 MSFT       97)
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:15 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 6:15 APIC version 20
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
ACPI: HPET id: 0x8086a202 base: 0xfed00000
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 50000000 (gap: 40000000:bee00000)
Detected 2135.184 MHz processor.
Built 1 zonelists.  Total pages: 259985
Kernel command line: BOOT_IMAGE=linux-2.6.20g ro video=radeonfb:1024x768-8@60 lapic apic=verbose root=/dev/mapper/main_vol-root
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=b042f000 soft=b042d000
PID hash table entries: 4096 (order: 12, 16384 bytes)
Console: colour VGA+ 80x25
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:    8
... MAX_LOCK_DEPTH:          30
... MAX_LOCKDEP_KEYS:        2048
... CLASSHASH_SIZE:           1024
... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      16384
... CHAINHASH_SIZE:          8192
 memory used by lock dependency info: 1096 kB
 per task-struct memory footprint: 1200 bytes
------------------------
| Locking API testsuite:
[cut, everything is ok]
-------------------------------------------------------
Good, all 218 testcases passed! |
---------------------------------
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1029640k/1048128k available (2028k kernel code, 17904k reserved, 985k data, 200k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xfffb7000 - 0xfffff000   ( 288 kB)
    vmalloc : 0xf0800000 - 0xfffb5000   ( 247 MB)
    lowmem  : 0xb0000000 - 0xeff90000   (1023 MB)
      .init : 0xb03f6000 - 0xb0428000   ( 200 kB)
      .data : 0xb02fb094 - 0xb03f1814   ( 985 kB)
      .text : 0xb0100000 - 0xb02fb094   (2028 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
hpet0: 3 64-bit timers, 14318180 Hz
Calibrating delay using timer specific routine.. 4273.73 BogoMIPS (lpj=8547462)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff 20100000 00000000 00000000 0000e3bd 00000000 00000001
monitor/mwait feature present.
using mwait in idle threads.
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU: After all inits, caps: bfebfbff 20100000 00000000 00003940 0000e3bd 00000000 00000001
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
lockdep: not fixing up alternatives.
ACPI: Core revision 20070126
Parsing all Control Methods:
Table [DSDT](id 0001) - 1008 Objects with 75 Devices 286 Methods 36 Regions
 tbxface-0587 [02] tb_load_namespace     : ACPI Tables successfully acquired
evxfevnt-0091 [02] enable                : Transition to ACPI mode successful
CPU0: Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz stepping 06
enabled ExtINT on CPU#0
lockdep: not fixing up alternatives.
Booting processor 1/1 eip 3000
CPU 1 irqstacks, hard=b0430000 soft=b042e000
Initializing CPU#1
masked ExtINT on CPU#1
Calibrating delay using timer specific routine.. 4270.09 BogoMIPS (lpj=8540188)
CPU: After generic identify, caps: bfebfbff 20100000 00000000 00000000 0000e3bd 00000000 00000001
monitor/mwait feature present.
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU: After all inits, caps: bfebfbff 20100000 00000000 00003940 0000e3bd 00000000 00000001
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel(R) Core(TM)2 CPU          6400  @ 2.13GHz stepping 06
Total of 2 processors activated (8543.82 BogoMIPS).
ENABLING IO-APIC IRQs
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
Using local APIC timer interrupts.
calibrating APIC timer ...
... lapic delta = 1667977
... PM timer delta = 357949
... PM timer result ok
..... delta 1667977
..... mult: 71634589
..... calibration result: 1067505
..... CPU clock speed is 2135.0043 MHz.
..... host bus clock speed is 266.3505 MHz.
... verify APIC timer
... jiffies delta = 25
... PM timer delta = 357949
... PM timer result ok
checking TSC synchronization [CPU#0 -> CPU#1]: passed.
Brought up 2 CPUs
migration_cost=21
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved
PCI: Not using MMCONFIG.
PCI: PCI BIOS revision 3.00 entry at 0xf0031, last bus=5
PCI: Using configuration type 1
Setting up standard PCI resources
evgpeblk-0952 [04] ev_create_gpe_block   : GPE 00 to 1F [_GPE] 4 regs on int 0x9
evgpeblk-1049 [03] ev_initialize_gpe_bloc: Found 11 Wake, Enabled 2 Runtime GPEs in this block
Completing Region/Field/Buffer/Package initialization:.....................................................................................................................................................................................................................................
Initialized 35/36 Regions 44/44 Fields 51/51 Buffers 99/100 Packages (1017 nodes)
Initializing Device/Processor/Thermal objects by executing _INI methods:.
Executed 1 _INI methods requiring 1 _STA executions (examined 81 objects)
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 0480-04bf claimed by ICH6 GPIO
Boot video device is 0000:01:00.0
PCI: Firmware left 0000:05:01.0 e100 interrupts enabled, disabling
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P7._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P8._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 14 *15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 11 12 *14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 17 devices
SCSI subsystem initialized
libata version 2.10 loaded.
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
number of MP IRQ sources: 15.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
.......    : physical APIC id: 02
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00170020
.......     : max redirection entries: 0017
.......     : PRQ implemented: 0
.......     : IO APIC version: 0020
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 003 03  1    0    0   0   0    1    1    39
 02 003 03  0    0    0   0   0    1    1    31
 03 003 03  0    0    0   0   0    1    1    41
 04 003 03  1    0    0   0   0    1    1    49
 05 003 03  0    0    0   0   0    1    1    51
 06 003 03  1    0    0   0   0    1    1    59
 07 003 03  1    0    0   0   0    1    1    61
 08 003 03  1    0    0   0   0    1    1    69
 09 003 03  0    1    0   0   0    1    1    71
 0a 003 03  0    0    0   0   0    1    1    79
 0b 003 03  0    0    0   0   0    1    1    81
 0c 003 03  1    0    0   0   0    1    1    89
 0d 003 03  1    0    0   0   0    1    1    91
 0e 003 03  0    0    0   0   0    1    1    99
 0f 003 03  0    0    0   0   0    1    1    A1
 10 000 00  1    0    0   0   0    0    0    00
 11 000 00  1    0    0   0   0    0    0    00
 12 000 00  1    0    0   0   0    0    0    00
 13 000 00  1    0    0   0   0    0    0    00
 14 000 00  1    0    0   0   0    0    0    00
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
PCI: Cannot allocate resource region 2 of device 0000:02:00.0
PCI: Cannot allocate resource region 3 of device 0000:02:00.0
pnp: 00:01: iomem range 0xfed14000-0xfed19fff has been reserved
pnp: 00:08: ioport range 0x290-0x297 has been reserved
pnp: 00:09: iomem range 0xffafe000-0xffb0cbff has been reserved
pnp: 00:09: iomem range 0xffb00000-0xffbfffff could not be reserved
pnp: 00:09: iomem range 0xfed1c000-0xfed1ffff has been reserved
pnp: 00:09: iomem range 0xfed20000-0xfed8ffff has been reserved
pnp: 00:0c: iomem range 0xfec00000-0xfec00fff has been reserved
pnp: 00:0c: iomem range 0xfee00000-0xfee00fff has been reserved
pnp: 00:0f: iomem range 0xe0000000-0xefffffff has been reserved
pnp: 00:10: iomem range 0x0-0x9ffff could not be reserved
pnp: 00:10: iomem range 0xc0000-0xcffff could not be reserved
pnp: 00:10: iomem range 0xe0000-0xfffff could not be reserved
pnp: 00:10: iomem range 0x100000-0x3fffffff could not be reserved
PCI: Bridge: 0000:00:01.0
  IO window: 7000-9fff
  MEM window: ff200000-ff2fffff
  PREFETCH window: bfd00000-dfcfffff
PCI: Bridge: 0000:00:1c.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: dfd00000-dfdfffff
PCI: Bridge: 0000:00:1c.3
  IO window: disabled.
  MEM window: ff400000-ff4fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.4
  IO window: a000-afff
  MEM window: ff300000-ff3fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
  IO window: b000-cfff
  MEM window: ff500000-ff9fffff
  PREFETCH window: dfe00000-dfefffff
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.0 to 64
ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.3 to 64
ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.4 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 65536 (order: 9, 2621440 bytes)
TCP bind hash table entries: 65536 (order: 9, 2359296 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
TCP reno registered
checking if image is initramfs... it is
Freeing initrd memory: 2718k freed
Machine check exception polling timer started.
Total HugeTLB memory allocated, 0
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:01.0:pcie00]
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie00]
Allocate Port Service[0000:00:1c.0:pcie02]
PCI: Setting latency timer of device 0000:00:1c.3 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.3:pcie00]
Allocate Port Service[0000:00:1c.3:pcie02]
PCI: Setting latency timer of device 0000:00:1c.4 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.4:pcie00]
Allocate Port Service[0000:00:1c.4:pcie02]
radeonfb_pci_register BEGIN
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
radeonfb (0000:01:00.0): Found 131072k of DDR 256 bits wide videoram
radeonfb (0000:01:00.0): mapped 16384k videoram
radeonfb: Found Intel x86 BIOS ROM Image
Retrieved PLL infos from ATOM BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=540.00 Mhz, System=520.00 MHz
PLL min 20000 max 50000
TMDS PLL from BIOS: 16500 b011c
index 3 port 2 conn 2 dac -1 ddc 0 tmds 0
index 4 port 2 conn 2 dac 1 ddc 0 tmds -1
index 7 port 1 conn 2 dac -1 ddc 1 tmds 1
Starting monitor auto detection...
i2c_adapter i2c-1: unable to read EDID block.
i2c_adapter i2c-1: unable to read EDID block.
i2c_adapter i2c-1: unable to read EDID block.
radeonfb: I2C (port 1) ... not found
radeonfb: I2C (port 0) ... found CRT display
 * Connector 1 is DVI-I. Head -1, Monitor: None 
   ddc port: 1, dac: -1, tmds: 1
 * Connector 2 is DVI-I. Head 0, Monitor: CRT (EDID probed)
   ddc port: 0, dac: 1, tmds: 0
hStart = 1048, hEnd = 1184, hTotal = 1344
vStart = 771, vEnd = 777, vTotal = 806
h_total_disp = 0x7f00a7	   hsync_strt_wid = 0x910422
v_total_disp = 0x2ff0325	   vsync_strt_wid = 0x860302
pixclock = 15384
freq = 6500
freq = 6500, PLL min = 20000, PLL max = 50000
ref_div = 12, ref_clk = 2700, output_freq = 26000
ref_div = 12, ref_clk = 2700, output_freq = 26000
post div = 0x2
fb_div = 0x74
ppll_div_3 = 0x20074
Console: switching to colour frame buffer device 128x48
radeonfb: Backlight initialized (radeonbl0)
radeonfb (0000:01:00.0): ATI Radeon ]R 
radeonfb_pci_register END
hpet_resources: 0xfed00000 is busy
ACPI Error (utglobal-0128): Unknown exception code: 0xFFFFFFF0 [20070126]
Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
Hangcheck: Using get_cycles().
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:06: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
netconsole: not configured, aborting
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ALI15X3: IDE controller at PCI slot 0000:05:02.1
ACPI: PCI Interrupt 0000:05:02.1[A] -> GSI 23 (level, low) -> IRQ 18
ALI15X3: chipset revision 198
ALI15X3: 100% native mode on irq 18
    ide0: BM-DMA at 0xc080-0xc087, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xc088-0xc08f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
Probing IDE interface ide1...
hdc: Maxtor 6Y120L0, ATA DISK drive
hdd: QUANTUM FIREBALLlct10 10, ATA DISK drive
ide1 at 0xc480-0xc487,0xc402 on irq 18
hdc: max request size: 128KiB
hdc: 240121728 sectors (122942 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(133)
hdc: cache flushes supported
 hdc: hdc1 hdc2 < hdc5 > hdc3
hdd: max request size: 128KiB
hdd: 20044080 sectors (10262 MB) w/418KiB Cache, CHS=19885/16/63, UDMA(33)
hdd: cache flushes not supported
 hdd: hdd1 hdd2
ahci 0000:00:1f.2: version 2.0
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq ilck stag pm led clo pmp pio slum part 
ata1: SATA max UDMA/133 cmd 0xf080c900 ctl 0x00000000 bmdma 0x00000000 irq 219
ata2: SATA max UDMA/133 cmd 0xf080c980 ctl 0x00000000 bmdma 0x00000000 irq 219
ata3: SATA max UDMA/133 cmd 0xf080ca00 ctl 0x00000000 bmdma 0x00000000 irq 219
ata4: SATA max UDMA/133 cmd 0xf080ca80 ctl 0x00000000 bmdma 0x00000000 irq 219
ata5: SATA max UDMA/133 cmd 0xf080cb00 ctl 0x00000000 bmdma 0x00000000 irq 219
ata6: SATA max UDMA/133 cmd 0xf080cb80 ctl 0x00000000 bmdma 0x00000000 irq 219
scsi0 : ahci
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7: ST3250820AS, 3.AAE, max UDMA/133
ata1.00: 488397168 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
scsi1 : ahci
ata2: SATA link down (SStatus 0 SControl 300)
scsi2 : ahci
ata3: SATA link down (SStatus 0 SControl 300)
scsi3 : ahci
ata4: SATA link down (SStatus 0 SControl 300)
scsi4 : ahci
ata5: SATA link down (SStatus 0 SControl 300)
scsi5 : ahci
ata6: SATA link down (SStatus 0 SControl 300)
scsi 0:0:0:0: Direct-Access     ATA      ST3250820AS      3.AA PQ: 0 ANSI: 5
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: [LDM] sda1 sda2
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
PCI: Device 0000:02:00.0 not available because of resource collisions
ahci: probe of 0000:02:00.0 failed with error -22
sata_uli 0000:05:02.0: version 1.0
ACPI: PCI Interrupt 0000:05:02.0[A] -> GSI 23 (level, low) -> IRQ 18
ata7: SATA max UDMA/133 cmd 0x0001c000 ctl 0x0001bc02 bmdma 0x0001b480 irq 18
ata8: SATA max UDMA/133 cmd 0x0001b880 ctl 0x0001b802 bmdma 0x0001b488 irq 18
scsi6 : sata_uli
ata7: SATA link down (SStatus 0 SControl 310)
scsi7 : sata_uli
ata8: SATA link down (SStatus 0 SControl 310)
PCI: Enabling device 0000:02:00.1 (0000 -> 0001)
ACPI: PCI Interrupt 0000:02:00.1[B] -> GSI 17 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:02:00.1 to 64
ata9: PATA max UDMA/100 cmd 0x0001ac00 ctl 0x0001a882 bmdma 0x0001a400 irq 19
ata10: PATA max UDMA/100 cmd 0x0001a800 ctl 0x0001a482 bmdma 0x0001a408 irq 19
scsi8 : pata_jmicron
ata9.00: ATAPI, max UDMA/33
ata9.01: ATAPI, max UDMA/33
ata9.00: configured for UDMA/33
ata9.01: configured for UDMA/33
scsi9 : pata_jmicron
ATA: abnormal status 0x7F on port 0x0001a807
scsi 8:0:0:0: CD-ROM            HL-DT-ST DVDRAM GSA-4167B DL13 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 8:0:0:0: Attached scsi CD-ROM sr0
sr 8:0:0:0: Attached scsi generic sg1 type 5
scsi 8:0:1:0: CD-ROM            WAITEC   ALADAR/1         B1.5 PQ: 0 ANSI: 5
sr1: scsi3-mmc drive: 16x/40x writer cd/rw xa/form2 cdda tray
sr 8:0:1:0: Attached scsi CD-ROM sr1
sr 8:0:1:0: Attached scsi generic sg2 type 5
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input0
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI No-Shortcut mode
Freeing unused kernel memory: 200k freed
Write protecting the kernel read-only data: 767k
Time: tsc clocksource has been installed.
Switched to high resolution mode on CPU 0
Switched to high resolution mode on CPU 1
SGI XFS with ACLs, large block numbers, no debug enabled
ACPI Warning (tbutils-0158): Incorrect checksum in table [OEMB] -  1F, should be 12 [20070126]
ACPI: SSDT 3FF9E0C0, 01C6 (r1    AMI   CPU1PM        1 INTL 20060113)
Parsing all Control Methods:
Table [SSDT](id 00EC) - 9 Objects with 0 Devices 3 Methods 0 Regions
ACPI: SSDT 3FF9E290, 013A (r1    AMI   CPU2PM        1 INTL 20060113)
Parsing all Control Methods:
Table [SSDT](id 00EF) - 7 Objects with 0 Devices 4 Methods 0 Regions
ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126]
ACPI Exception (processor_core-0783): AE_NOT_FOUND, Processor Device is not present [20070126]
input: ImPS/2 Generic Wheel Mouse as /class/input/input1
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with journal data mode.
Linux agpgart interface v0.102 (c) Dave Jones
agpgart: Detected an Intel 965G Chipset.
agpgart: AGP aperture is 256M @ 0x0
PCI: Enabling device 0000:00:1f.3 (0001 -> 0003)
ACPI: PCI Interrupt 0000:00:1f.3[C] -> GSI 18 (level, low) -> IRQ 20
parport: PnPBIOS parport detected.
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Attansic L1 Ethernet Network Driver - version 2.0.7
Copyright(c) 2005-2006 Attansic Corporation.
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 19 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:03:00.0 to 64
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1a.0[A] -> <6>ACPI: PCI Interrupt 0000:05:01.0[A] -> GSI 22 (level, low) -> IRQ 21
GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1a.0 to 64
uhci_hcd 0000:00:1a.0: UHCI Host Controller
uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:1a.0: irq 16, io base 0x0000e000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
e100: eth1: e100_probe: addr 0xdfeff000, irq 21, MAC addr 00:50:8B:5C:21:8B
hub 1-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1a.1[B] -> GSI 17 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1a.1 to 64
uhci_hcd 0000:00:1a.1: UHCI Host Controller
uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1a.1: irq 19, io base 0x0000e080
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.0: irq 18, io base 0x0000d800
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.1: irq 17, io base 0x0000d880
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.2: irq 20, io base 0x0000dc00
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1a.7[C] -> GSI 18 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:1a.7 to 64
ehci_hcd 0000:00:1a.7: EHCI Host Controller
ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 6
ehci_hcd 0000:00:1a.7: debug port 1
PCI: cache line size of 32 is not supported by device 0000:00:1a.7
ehci_hcd 0000:00:1a.7: irq 20, io mem 0xffaff400
ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb6: configuration #1 chosen from 1 choice
hub 6-0:1.0: USB hub found
hub 6-0:1.0: 4 ports detected
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:1b.0 to 64
hda_codec: Unknown model for AD1988, trying auto-probe from BIOS...
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 7
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 18, io mem 0xffaff000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb7: configuration #1 chosen from 1 choice
hub 7-0:1.0: USB hub found
hub 7-0:1.0: 6 ports detected
ACPI: PCI Interrupt 0000:05:03.0[A] -> GSI 21 (level, low) -> IRQ 22
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[22]  MMIO=[ff7ef800-ff7effff]  Max Packet=[2048]  IR/IT contexts=[4/8]
Adding 787176k swap on /dev/hdd2.  Priority:9 extents:1 across:787176k
EXT3 FS on dm-0, internal journal
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[0011d80000e56e6e]
NET: Registered protocol family 10
processor_perflib-0563 [00] processor_get_psd     : Invalid _PSD data
processor_perflib-0563 [00] processor_get_psd     : Invalid _PSD data
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
kjournald starting.  Commit interval 5 seconds
EXT3 FS on dm-2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on dm-3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on dm-1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
CBQ: class 00010001 has bad quantum==0, repaired.
u32 classifier
    input device check on 
    Actions configured 
input: Power Button (FF) as /class/input/input2
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input3
ACPI: Power Button (CM) [PWRB]
fuse init (API version 7.8)
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized radeon 1.25.0 20060524 on minor 0
[drm] Setting GART location based on new memory map
[drm] Loading R300 Microcode
[drm] writeback test succeeded in 1 usecs


Luca
-- 
"La vita potrebbe non avere alcun significato. Oppure, ancora peggio,
 potrebbe averne uno che disapprovo". -- Ashleigh Brilliant

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Thomas Gleixner]

On Thu, 2007-02-22 at 00:04 +0100, Luca Tettamanti wrote:
> Hi Thomas,
> I'm testing NO_HZ on my machines. On the laptop I see that the timer
> interrupt counter is incremented (though slower than HZ). This machine
> is running UP kernel.
> 
> On my desktop I see this:
> 
>            CPU0       CPU1       
>   0:        114          0   IO-APIC-edge      timer
>   1:       1624      10771   IO-APIC-edge      i8042
>   6:          3          0   IO-APIC-edge      floppy
>   7:          0          0   IO-APIC-edge      parport0
>   9:          0          0   IO-APIC-fasteoi   acpi
>  12:      40111     184047   IO-APIC-edge      i8042
>  16:      75624     998858   IO-APIC-fasteoi   radeon@pci:0000:01:00.0, uhci_hcd:usb1
>  17:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
>  18:        711       5487   IO-APIC-fasteoi   ide1, libata, ehci_hcd:usb7, uhci_hcd:usb3
>  19:        617       2254   IO-APIC-fasteoi   libata, uhci_hcd:usb2
>  20:          0          0   IO-APIC-fasteoi   ehci_hcd:usb6, uhci_hcd:usb5
>  21:    2483869          0   IO-APIC-fasteoi   eth0
>  22:          2          0   IO-APIC-fasteoi   ohci1394
> 218:      28872     360643   PCI-MSI-edge      HDA Intel
> 219:      32932     138196   PCI-MSI-edge      libata
> NMI:          0          0 
> LOC:    2761191    2827539 
> ERR:          0
> MIS:          0
> 
> Interrupt 0 is stuck at 114 (the number is consistent across reboots). I
> don't experience any problem, time is running fine. Still it's strange
> that the timer is doing nothing; maybe something other than the PIT is
> used for time keeping?

Yes, we switch away from PIT and use the local APIC timer. (LOC)

	tglx

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Luca Tettamanti]

On 2/22/07, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Thu, 2007-02-22 at 00:04 +0100, Luca Tettamanti wrote:
> > Hi Thomas,
> > I'm testing NO_HZ on my machines. On the laptop I see that the timer
> > interrupt counter is incremented (though slower than HZ). This machine
> > is running UP kernel.
> >
> > On my desktop I see this:
> >
> >            CPU0       CPU1
> >   0:        114          0   IO-APIC-edge      timer
> >   1:       1624      10771   IO-APIC-edge      i8042
> >   6:          3          0   IO-APIC-edge      floppy
> >   7:          0          0   IO-APIC-edge      parport0
> >   9:          0          0   IO-APIC-fasteoi   acpi
> >  12:      40111     184047   IO-APIC-edge      i8042
> >  16:      75624     998858   IO-APIC-fasteoi   radeon@pci:0000:01:00.0, uhci_hcd:usb1
> >  17:          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
> >  18:        711       5487   IO-APIC-fasteoi   ide1, libata, ehci_hcd:usb7, uhci_hcd:usb3
> >  19:        617       2254   IO-APIC-fasteoi   libata, uhci_hcd:usb2
> >  20:          0          0   IO-APIC-fasteoi   ehci_hcd:usb6, uhci_hcd:usb5
> >  21:    2483869          0   IO-APIC-fasteoi   eth0
> >  22:          2          0   IO-APIC-fasteoi   ohci1394
> > 218:      28872     360643   PCI-MSI-edge      HDA Intel
> > 219:      32932     138196   PCI-MSI-edge      libata
> > NMI:          0          0
> > LOC:    2761191    2827539
> > ERR:          0
> > MIS:          0
> >
> > Interrupt 0 is stuck at 114 (the number is consistent across reboots). I
> > don't experience any problem, time is running fine. Still it's strange
> > that the timer is doing nothing; maybe something other than the PIT is
> > used for time keeping?
>
> Yes, we switch away from PIT and use the local APIC timer. (LOC)

Ok, thanks for the clarification.

Luca

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Jan Engelhardt]

On Feb 22 2007 00:17, Thomas Gleixner wrote:
>On Thu, 2007-02-22 at 00:04 +0100, Luca Tettamanti wrote:
>> 
>> Interrupt 0 is stuck at 114 (the number is consistent across reboots). I
>> don't experience any problem, time is running fine. Still it's strange
>> that the timer is doing nothing; maybe something other than the PIT is
>> used for time keeping?
>
>Yes, we switch away from PIT and use the local APIC timer. (LOC)

What's the benefit of doing so - and why has not it been done before?
I mean, I run a regular 2.6.18.6,
/sys/devices/system/clocksource/clocksource0/current_clocksource (is this
related?) shows "acpi_pm", but the IRQ0 counter increases at HZ. Maybe I
am confusing things, but why the need for PIT when clocksource is acpi_pm
anyway?


Jan
-- 

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Arjan van de Ven]

> What's the benefit of doing so - and why has not it been done before?
> I mean, I run a regular 2.6.18.6,
> /sys/devices/system/clocksource/clocksource0/current_clocksource (is this
> related?) shows "acpi_pm", but the IRQ0 counter increases at HZ. Maybe I
> am confusing things, but why the need for PIT when clocksource is acpi_pm
> anyway?

you're mixing up 2 concepts:
1) clocksource
2) eventsource

1) is for "what time is it now", and acpi_pm is useful for that, as are
several other things such as rdtsc
2) is for "I need THIS to happen X miliseconds from now". acpi_pm is not
useful for that, nor is rdtsc.

some can be used for both (PIT), but on a concept level the uses are
independent. The advantage of local apic over PIT is that local apic is
cheap to do "one shot" future events with, while the PIT will tick
periodic at a fixed frequency. With tickless idle.. that's not what you
want.


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Pierre Ossman]

Arjan van de Ven wrote:
> 
> some can be used for both (PIT), but on a concept level the uses are
> independent. The advantage of local apic over PIT is that local apic is
> cheap to do "one shot" future events with, while the PIT will tick
> periodic at a fixed frequency. With tickless idle.. that's not what you
> want.
> 

So with a local apic, and acpi_pm as clocksource, I shouldn't be getting timer
interrupts? Yet I do. Which I assume means that the kernel will still get woken
up very often.

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Arjan van de Ven]

On Thu, 2007-02-22 at 15:10 +0100, Pierre Ossman wrote:
> Arjan van de Ven wrote:
> > 
> > some can be used for both (PIT), but on a concept level the uses are
> > independent. The advantage of local apic over PIT is that local apic is
> > cheap to do "one shot" future events with, while the PIT will tick
> > periodic at a fixed frequency. With tickless idle.. that's not what you
> > want.
> > 
> 
> So with a local apic, and acpi_pm as clocksource, I shouldn't be getting timer
> interrupts? 

timer interrupts as in "irq0"?

you shouldn't if you use the hrtimers/tickless stuff...

can you get us a dmesg somewhere? maybe the kernel mentions why ;)

> Yet I do. Which I assume means that the kernel will still get woken
> up very often.

if irq0 keeps increasing at 100Hz or 1000Hz or so.. then yes
-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Pierre Ossman]

Arjan van de Ven wrote:
> On Thu, 2007-02-22 at 15:10 +0100, Pierre Ossman wrote:
>   
>>
>> So with a local apic, and acpi_pm as clocksource, I shouldn't be getting timer
>> interrupts? 
>>     
>
> timer interrupts as in "irq0"?
>
>   

Yes:

  0:    9786349    XT-PIC-XT        timer

> you shouldn't if you use the hrtimers/tickless stuff...
>   

CONFIG_HIGH_RES_TIMERS=y
CONFIG_NO_HZ=y

> can you get us a dmesg somewhere? maybe the kernel mentions why ;)
>
>   

Sure. My dmesg is full of mmc debug crud right now, but I'll just reboot
and I'll have a clean one for you.

Rgds

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

Pierre Ossman wrote:
> Arjan van de Ven wrote:
>> can you get us a dmesg somewhere? maybe the kernel mentions why ;)
>>
>>   
> 
> Sure. My dmesg is full of mmc debug crud right now, but I'll just reboot
> and I'll have a clean one for you.
> 

Here we go.

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

[-- Attachment #2: badtick.dmesg --]
[-- Type: text/plain, Size: 73679 bytes --]

[    0.000000] Linux version 2.6.21-rc1 (root@poseidon.drzeus.cx) (gcc version 4.1.2 20070214 (Red Hat 4.1.2-1)) #383 PREEMPT Thu Feb 22 08:34:36 CET 2007
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] sanitize start
[    0.000000] sanitize end
[    0.000000] copy_e820_map() start: 0000000000000000 size: 000000000009fc00 end: 000000000009fc00 type: 1
[    0.000000] copy_e820_map() type is E820_RAM
[    0.000000] copy_e820_map() start: 000000000009fc00 size: 0000000000000400 end: 00000000000a0000 type: 2
[    0.000000] copy_e820_map() start: 00000000000e0000 size: 0000000000020000 end: 0000000000100000 type: 2
[    0.000000] copy_e820_map() start: 0000000000100000 size: 000000001fed0000 end: 000000001ffd0000 type: 1
[    0.000000] copy_e820_map() type is E820_RAM
[    0.000000] copy_e820_map() start: 000000001ffd0000 size: 0000000000020c00 end: 000000001fff0c00 type: 2
[    0.000000] copy_e820_map() start: 000000001fff0c00 size: 000000000000b400 end: 000000001fffc000 type: 4
[    0.000000] copy_e820_map() start: 000000001fffc000 size: 0000000000004000 end: 0000000020000000 type: 2
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
[    0.000000]  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 000000001ffd0000 (usable)
[    0.000000]  BIOS-e820: 000000001ffd0000 - 000000001fff0c00 (reserved)
[    0.000000]  BIOS-e820: 000000001fff0c00 - 000000001fffc000 (ACPI NVS)
[    0.000000]  BIOS-e820: 000000001fffc000 - 0000000020000000 (reserved)
[    0.000000] 511MB LOWMEM available.
[    0.000000] Entering add_active_range(0, 0, 131024) 0 entries of 256 used
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA             0 ->     4096
[    0.000000]   Normal       4096 ->   131024
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0:        0 ->   131024
[    0.000000] On node 0 totalpages: 131024
[    0.000000]   DMA zone: 32 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 4064 pages, LIFO batch:0
[    0.000000]   Normal zone: 991 pages used for memmap
[    0.000000]   Normal zone: 125937 pages, LIFO batch:31
[    0.000000] DMI 2.3 present.
[    0.000000] ACPI: RSDP 000F6560, 0014 (r0 COMPAQ)
[    0.000000] ACPI: RSDT 1FFF0C84, 002C (r1 HP     CPQ0860  13090420 CPQ         1)
[    0.000000] ACPI: FACP 1FFF0C00, 0084 (r2 HP     CPQ0860         2 CPQ         1)
[    0.000000] ACPI: DSDT 1FFF0CB0, 4F8C (r1 HP       nx7000    10000 MSFT  100000E)
[    0.000000] ACPI: FACS 1FFFBE80, 0040
[    0.000000] ACPI: SSDT 1FFF5C3C, 028A (r1 COMPAQ  CPQGysr     1001 MSFT  100000E)
[    0.000000] ACPI: PM-Timer IO Port: 0x1008
[    0.000000] Allocating PCI resources starting at 30000000 (gap: 20000000:e0000000)
[    0.000000] Detected 1594.954 MHz processor.
[   14.448059] Built 1 zonelists.  Total pages: 130001
[   14.448062] Kernel command line: ro root=/dev/sda5 rhgb lapic quiet
[   14.448282] Local APIC disabled by BIOS -- reenabling.
[   14.448285] Found and enabled local APIC!
[   14.448289] mapped APIC to ffffd000 (fee00000)
[   14.448292] Enabling fast FPU save and restore... done.
[   14.448295] Enabling unmasked SIMD FPU exception support... done.
[   14.448306] Initializing CPU#0
[   14.448386] CPU 0 irqstacks, hard=c0409000 soft=c0408000
[   14.448390] PID hash table entries: 2048 (order: 11, 8192 bytes)
[   14.449530] Console: colour VGA+ 80x25
[   14.449549] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[   14.449552] ... MAX_LOCKDEP_SUBCLASSES:    8
[   14.449554] ... MAX_LOCK_DEPTH:          30
[   14.449556] ... MAX_LOCKDEP_KEYS:        2048
[   14.449558] ... CLASSHASH_SIZE:           1024
[   14.449560] ... MAX_LOCKDEP_ENTRIES:     8192
[   14.449563] ... MAX_LOCKDEP_CHAINS:      16384
[   14.449565] ... CHAINHASH_SIZE:          8192
[   14.449567]  memory used by lock dependency info: 1096 kB
[   14.449569]  per task-struct memory footprint: 1200 bytes
[   14.449840] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[   14.450174] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[   14.465505] Memory: 510664k/524096k available (2021k kernel code, 12812k reserved, 861k data, 196k init, 0k highmem)
[   14.465516] virtual kernel memory layout:
[   14.465517]     fixmap  : 0xfffb7000 - 0xfffff000   ( 288 kB)
[   14.465519]     vmalloc : 0xe0800000 - 0xfffb5000   ( 503 MB)
[   14.465520]     lowmem  : 0xc0000000 - 0xdffd0000   ( 511 MB)
[   14.465522]       .init : 0xc03d2000 - 0xc0403000   ( 196 kB)
[   14.465523]       .data : 0xc02f9796 - 0xc03d0c34   ( 861 kB)
[   14.465525]       .text : 0xc0100000 - 0xc02f9796   (2021 kB)
[   14.465528] Checking if this processor honours the WP bit even in supervisor mode... Ok.
[   14.545754] Calibrating delay using timer specific routine.. 3192.49 BogoMIPS (lpj=6384997)
[   14.545859] Mount-cache hash table entries: 512
[   14.546172] CPU: After generic identify, caps: a7e9fbbf 00000000 00000000 00000000 00000180 00000000 00000000
[   14.546184] CPU: L1 I cache: 32K, L1 D cache: 32K
[   14.546187] CPU: L2 cache: 1024K
[   14.546189] CPU: After all inits, caps: a7e9fbbf 00000000 00000000 00002040 00000180 00000000 00000000
[   14.546197] Intel machine check architecture supported.
[   14.546201] Intel machine check reporting enabled on CPU#0.
[   14.546212] CPU: Intel(R) Pentium(R) M processor 1600MHz stepping 05
[   14.546219] Checking 'hlt' instruction... OK.
[   14.561817] ACPI: Core revision 20070126
[   14.565737] ACPI: setting ELCR to 0200 (from 0c20)
[   14.841876] PM: Adding info for No Bus:platform
[   14.842084] NET: Registered protocol family 16
[   14.842201] PM: Adding info for No Bus:vtcon0
[   14.842321] ACPI: bus type pci registered
[   14.843667] PCI: PCI BIOS revision 2.10 entry at 0xf031f, last bus=3
[   14.843669] PCI: Using configuration type 1
[   14.843672] Setting up standard PCI resources
[   14.856589] ACPI: Interpreter enabled
[   14.856594] ACPI: (supports S0 S3 S4 S5)
[   14.856624] ACPI: Using PIC for interrupt routing
[   14.856672] PM: Adding info for acpi:acpi_system:00
[   14.856761] PM: Adding info for acpi:button_power:00
[   14.856830] PM: Adding info for acpi:ACPI0007:00
[   14.856923] PM: Adding info for acpi:device:00
[   14.857012] PM: Adding info for acpi:PNP0C01:00
[   14.857101] PM: Adding info for acpi:PNP0A03:00
[   14.857179] PM: Adding info for acpi:device:01
[   14.857274] PM: Adding info for acpi:video:00
[   14.857354] PM: Adding info for acpi:device:02
[   14.857434] PM: Adding info for acpi:device:03
[   14.857529] PM: Adding info for acpi:device:04
[   14.857613] PM: Adding info for acpi:device:05
[   14.857700] PM: Adding info for acpi:device:06
[   14.857798] PM: Adding info for acpi:device:07
[   14.857955] PM: Adding info for acpi:device:08
[   14.858039] PM: Adding info for acpi:device:09
[   14.858135] PM: Adding info for acpi:device:0a
[   14.858230] PM: Adding info for acpi:device:0b
[   14.858389] PM: Adding info for acpi:PNP0C09:00
[   14.858798] PM: Adding info for acpi:WEC0518:00
[   14.858889] PM: Adding info for acpi:PNP0A06:00
[   14.859583] PM: Adding info for acpi:PNP0501:00
[   14.859677] PM: Adding info for acpi:power_resource:00
[   14.860356] PM: Adding info for acpi:SMCF010:00
[   14.860433] PM: Adding info for acpi:power_resource:01
[   14.861360] PM: Adding info for acpi:PNP0401:00
[   14.861442] PM: Adding info for acpi:power_resource:02
[   14.861530] PM: Adding info for acpi:PNP0C04:00
[   14.861629] PM: Adding info for acpi:PNP0100:00
[   14.861715] PM: Adding info for acpi:PNP0200:00
[   14.861810] PM: Adding info for acpi:PNP0800:00
[   14.861905] PM: Adding info for acpi:PNP0B00:00
[   14.861992] PM: Adding info for acpi:PNP0303:00
[   14.862108] PM: Adding info for acpi:SYN0107:00
[   14.862198] PM: Adding info for acpi:power_resource:03
[   14.862286] PM: Adding info for acpi:PNP0000:00
[   14.862369] PM: Adding info for acpi:PNP0C02:00
[   14.862473] PM: Adding info for acpi:device:0c
[   14.862562] PM: Adding info for acpi:device:0d
[   14.862646] PM: Adding info for acpi:device:0e
[   14.862744] PM: Adding info for acpi:device:0f
[   14.862841] PM: Adding info for acpi:device:10
[   14.862927] PM: Adding info for acpi:device:11
[   14.863033] PM: Adding info for acpi:device:12
[   14.863121] PM: Adding info for acpi:device:13
[   14.863208] PM: Adding info for acpi:device:14
[   14.863310] PM: Adding info for acpi:device:15
[   14.863408] PM: Adding info for acpi:device:16
[   14.863493] PM: Adding info for acpi:device:17
[   14.863594] PM: Adding info for acpi:device:18
[   14.863680] PM: Adding info for acpi:device:19
[   14.863774] PM: Adding info for acpi:device:1a
[   14.863873] PM: Adding info for acpi:device:1b
[   14.863960] PM: Adding info for acpi:device:1c
[   14.864045] PM: Adding info for acpi:device:1d
[   14.864152] PM: Adding info for acpi:device:1e
[   14.864242] PM: Adding info for acpi:device:1f
[   14.864333] PM: Adding info for acpi:device:20
[   14.864432] PM: Adding info for acpi:device:21
[   14.864522] PM: Adding info for acpi:device:22
[   14.864608] PM: Adding info for acpi:device:23
[   14.864715] PM: Adding info for acpi:device:24
[   14.864802] PM: Adding info for acpi:device:25
[   14.865109] PM: Adding info for acpi:PNP0C0F:00
[   14.865402] PM: Adding info for acpi:PNP0C0F:01
[   14.865681] PM: Adding info for acpi:PNP0C0F:02
[   14.865966] PM: Adding info for acpi:PNP0C0F:03
[   14.866259] PM: Adding info for acpi:PNP0C0F:04
[   14.866537] PM: Adding info for acpi:PNP0C0F:05
[   14.866819] PM: Adding info for acpi:PNP0C0F:06
[   14.867109] PM: Adding info for acpi:PNP0C0F:07
[   14.867205] PM: Adding info for acpi:device:26
[   14.867398] PM: Adding info for acpi:device:27
[   14.867503] PM: Adding info for acpi:PNP0C02:01
[   14.867988] PM: Adding info for acpi:PNP0C0A:00
[   14.868085] PM: Adding info for acpi:ACPI0003:00
[   14.868188] PM: Adding info for acpi:PNP0C0C:00
[   14.868286] PM: Adding info for acpi:PNP0C0D:00
[   14.868602] PM: Adding info for acpi:PNP0C02:02
[   14.868701] PM: Adding info for acpi:thermal:00
[   14.888562] ACPI: PCI Root Bridge [C046] (0000:00)
[   14.888582] PCI: Probing PCI hardware (bus 00)
[   14.888600] PM: Adding info for No Bus:pci0000:00
[   14.889160] PCI quirk: region 1000-107f claimed by ICH4 ACPI/GPIO/TCO
[   14.889166] PCI quirk: region 1100-113f claimed by ICH4 GPIO
[   14.889542] Boot video device is 0000:01:00.0
[   14.889926] PCI: Transparent bridge - 0000:00:1e.0
[   14.890017] PCI: Bus #03 (-#06) is hidden behind transparent bridge #02 (-#03) (try 'pci=assign-busses')
[   14.890020] Please report the result to linux-kernel to fix this permanently
[   14.890046] ACPI: PCI Interrupt Routing Table [\_SB_.C046._PRT]
[   14.890134] ACPI: PCI Interrupt Routing Table [\_SB_.C046.C047._PRT]
[   14.890159] ACPI: PCI Interrupt Routing Table [\_SB_.C046.C058._PRT]
[   14.891226] PM: Adding info for pci:0000:00:00.0
[   14.892273] PM: Adding info for pci:0000:00:01.0
[   14.893301] PM: Adding info for pci:0000:00:1d.0
[   14.894334] PM: Adding info for pci:0000:00:1d.1
[   14.895374] PM: Adding info for pci:0000:00:1d.2
[   14.896400] PM: Adding info for pci:0000:00:1d.7
[   14.897426] PM: Adding info for pci:0000:00:1e.0
[   14.898489] PM: Adding info for pci:0000:00:1f.0
[   14.899515] PM: Adding info for pci:0000:00:1f.1
[   14.900540] PM: Adding info for pci:0000:00:1f.3
[   14.901584] PM: Adding info for pci:0000:00:1f.5
[   14.902616] PM: Adding info for pci:0000:00:1f.6
[   14.902707] PM: Adding info for pci:0000:01:00.0
[   14.902866] PM: Adding info for pci:0000:02:00.0
[   14.903010] PM: Adding info for pci:0000:02:01.0
[   14.903154] PM: Adding info for pci:0000:02:02.0
[   14.903315] PM: Adding info for pci:0000:02:04.0
[   14.903675] ACPI: PCI Interrupt Link [C0C2] (IRQs 5 *10)
[   14.903920] ACPI: PCI Interrupt Link [C0C3] (IRQs 5 *10)
[   14.904159] ACPI: PCI Interrupt Link [C0C4] (IRQs *5 10)
[   14.904398] ACPI: PCI Interrupt Link [C0C5] (IRQs *5 10)
[   14.904622] ACPI: PCI Interrupt Link [C0C6] (IRQs 5 10) *0, disabled.
[   14.904865] ACPI: PCI Interrupt Link [C0C7] (IRQs 5 10) *11
[   14.905089] ACPI: PCI Interrupt Link [C0C8] (IRQs 5 10) *0, disabled.
[   14.905329] ACPI: PCI Interrupt Link [C0C9] (IRQs *5 10)
[   14.905696] ACPI: Power Resource [C18D] (on)
[   14.905914] ACPI: Power Resource [C195] (on)
[   14.906095] ACPI: Power Resource [C19C] (on)
[   14.906149] ACPI: Power Resource [C1A6] (on)
[   14.906181] Linux Plug and Play Support v0.97 (c) Adam Belay
[   14.906215] pnp: PnP ACPI init
[   14.906231] PM: Adding info for No Bus:pnp0
[   14.906407] PM: Adding info for pnp:00:00
[   14.913640] PM: Adding info for pnp:00:01
[   14.914004] PM: Adding info for pnp:00:02
[   14.915128] PM: Adding info for pnp:00:03
[   14.916340] PM: Adding info for pnp:00:04
[   14.917556] PM: Adding info for pnp:00:05
[   14.917633] PM: Adding info for pnp:00:06
[   14.917708] PM: Adding info for pnp:00:07
[   14.917800] PM: Adding info for pnp:00:08
[   14.917870] PM: Adding info for pnp:00:09
[   14.917943] PM: Adding info for pnp:00:0a
[   14.918034] PM: Adding info for pnp:00:0b
[   14.918251] PM: Adding info for pnp:00:0c
[   14.919198] PM: Adding info for pnp:00:0d
[   14.920447] PM: Adding info for pnp:00:0e
[   14.920504] pnp: PnP ACPI: found 15 devices
[   14.920698] PCI: Using ACPI for IRQ routing
[   14.920701] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[   14.978391] pnp: 00:00: iomem range 0x0-0x9ffff could not be reserved
[   14.978396] pnp: 00:00: iomem range 0xe0000-0xfffff could not be reserved
[   14.978400] pnp: 00:00: iomem range 0x100000-0x1fffffff could not be reserved
[   14.978417] pnp: 00:0c: iomem range 0xffb00000-0xffbfffff has been reserved
[   14.978421] pnp: 00:0c: iomem range 0xfff00000-0xffffffff has been reserved
[   14.978430] pnp: 00:0d: ioport range 0x4d0-0x4d1 has been reserved
[   14.978434] pnp: 00:0d: ioport range 0x1000-0x107f has been reserved
[   14.978438] pnp: 00:0d: ioport range 0x1100-0x113f has been reserved
[   14.978441] pnp: 00:0d: ioport range 0x1200-0x121f has been reserved
[   14.978445] pnp: 00:0d: iomem range 0xfec00000-0xfec000ff has been reserved
[   14.978454] pnp: 00:0e: iomem range 0xd5000-0xd7fff has been reserved
[   14.978458] pnp: 00:0e: iomem range 0xfec01000-0xfec01fff has been reserved
[   14.978506] PM: Adding info for No Bus:mem
[   14.978563] PM: Adding info for No Bus:kmem
[   14.978618] PM: Adding info for No Bus:null
[   14.978687] PM: Adding info for No Bus:port
[   14.978750] PM: Adding info for No Bus:zero
[   14.978805] PM: Adding info for No Bus:full
[   14.978873] PM: Adding info for No Bus:random
[   14.978927] PM: Adding info for No Bus:urandom
[   14.978983] PM: Adding info for No Bus:kmsg
[   14.979082] PCI: Bridge: 0000:00:01.0
[   14.979086]   IO window: 3000-3fff
[   14.979091]   MEM window: 90400000-904fffff
[   14.979096]   PREFETCH window: 98000000-9fffffff
[   14.979106] PCI: Bus 3, cardbus bridge: 0000:02:04.0
[   14.979109]   IO window: 00002800-000028ff
[   14.979114]   IO window: 00002c00-00002cff
[   14.979120]   PREFETCH window: 30000000-33ffffff
[   14.979125]   MEM window: 38000000-3bffffff
[   14.979130] PCI: Bridge: 0000:00:1e.0
[   14.979134]   IO window: 2000-2fff
[   14.979141]   MEM window: 90000000-903fffff
[   14.979146]   PREFETCH window: 30000000-33ffffff
[   14.979167] PCI: Setting latency timer of device 0000:00:1e.0 to 64
[   14.979545] ACPI: PCI Interrupt Link [C0C4] enabled at IRQ 5
[   14.979549] PCI: setting IRQ 5 as level-triggered
[   14.979553] ACPI: PCI Interrupt 0000:02:04.0[A] -> Link [C0C4] -> GSI 5 (level, low) -> IRQ 5
[   14.979600] NET: Registered protocol family 2
[   15.013809] IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
[   15.013972] TCP established hash table entries: 16384 (order: 7, 720896 bytes)
[   15.016348] TCP bind hash table entries: 16384 (order: 7, 720896 bytes)
[   15.018857] TCP: Hash tables configured (established 16384 bind 16384)
[   15.018869] TCP reno registered
[   15.030033] checking if image is initramfs... it is
[   15.312865] Freeing initrd memory: 2727k freed
[   15.313192] Machine check exception polling timer started.
[   15.313295] PM: Adding info for platform:pcspkr
[   15.313697] PM: Adding info for No Bus:snapshot
[   15.313774] audit: initializing netlink socket (disabled)
[   15.313806] audit(1172159879.500:1): initialized
[   15.314097] VFS: Disk quotas dquot_6.5.1
[   15.314117] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[   15.314321] io scheduler noop registered
[   15.314325] io scheduler anticipatory registered
[   15.314328] io scheduler deadline registered
[   15.314351] io scheduler cfq registered (default)
[   15.315217] ACPI: PCI Interrupt Link [C0C2] enabled at IRQ 10
[   15.315222] PCI: setting IRQ 10 as level-triggered
[   15.315226] ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [C0C2] -> GSI 10 (level, low) -> IRQ 10
[   15.315274] radeonfb: Retrieved PLL infos from BIOS
[   15.315278] radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=250.00 Mhz, System=220.00 MHz
[   15.315282] radeonfb: PLL min 20000 max 35000
[   15.315359] PM: Adding info for No Bus:i2c-0
[   15.315505] PM: Adding info for No Bus:i2c-1
[   15.315600] PM: Adding info for No Bus:i2c-2
[   15.315711] PM: Adding info for No Bus:i2c-3
[   15.415165] i2c_adapter i2c-1: unable to read EDID block.
[   15.571135] i2c_adapter i2c-1: unable to read EDID block.
[   15.727123] i2c_adapter i2c-1: unable to read EDID block.
[   15.883109] i2c_adapter i2c-3: unable to read EDID block.
[   16.039095] i2c_adapter i2c-3: unable to read EDID block.
[   16.195082] i2c_adapter i2c-3: unable to read EDID block.
[   16.249641] Non-DDC laptop panel detected
[   16.351069] i2c_adapter i2c-2: unable to read EDID block.
[   16.507056] i2c_adapter i2c-2: unable to read EDID block.
[   16.663042] i2c_adapter i2c-2: unable to read EDID block.
[   16.819029] i2c_adapter i2c-3: unable to read EDID block.
[   16.975016] i2c_adapter i2c-3: unable to read EDID block.
[   17.131002] i2c_adapter i2c-3: unable to read EDID block.
[   17.186560] radeonfb: Monitor 1 type LCD found
[   17.186562] radeonfb: Monitor 2 type no found
[   17.186569] radeonfb: panel ID string: SEC                     
[   17.186572] radeonfb: detected LVDS panel size from BIOS: 1680x1050
[   17.186576] radeondb: BIOS provided dividers will be used
[   17.305548] radeonfb: Dynamic Clock Power Management enabled
[   17.305566] PM: Adding info for No Bus:fb0
[   17.306919] PM: Adding info for No Bus:vtcon1
[   17.345666] Console: switching to colour frame buffer device 210x65
[   17.379016] radeonfb: Backlight initialized (radeonbl0)
[   17.379021] radeonfb (0000:01:00.0): ATI Radeon Lf 
[   17.379179] PM: Adding info for No Bus:tty
[   17.379246] PM: Adding info for No Bus:console
[   17.379323] PM: Adding info for No Bus:ptmx
[   17.379388] PM: Adding info for No Bus:tty0
[   17.379473] PM: Adding info for No Bus:vcs
[   17.379545] PM: Adding info for No Bus:vcsa
[   17.379602] PM: Adding info for No Bus:tty1
[   17.379685] PM: Adding info for No Bus:tty2
[   17.379739] PM: Adding info for No Bus:tty3
[   17.379804] PM: Adding info for No Bus:tty4
[   17.379870] PM: Adding info for No Bus:tty5
[   17.379935] PM: Adding info for No Bus:tty6
[   17.379995] PM: Adding info for No Bus:tty7
[   17.380068] PM: Adding info for No Bus:tty8
[   17.380127] PM: Adding info for No Bus:tty9
[   17.380189] PM: Adding info for No Bus:tty10
[   17.380266] PM: Adding info for No Bus:tty11
[   17.380327] PM: Adding info for No Bus:tty12
[   17.380386] PM: Adding info for No Bus:tty13
[   17.380463] PM: Adding info for No Bus:tty14
[   17.380525] PM: Adding info for No Bus:tty15
[   17.380585] PM: Adding info for No Bus:tty16
[   17.380659] PM: Adding info for No Bus:tty17
[   17.380719] PM: Adding info for No Bus:tty18
[   17.380781] PM: Adding info for No Bus:tty19
[   17.380859] PM: Adding info for No Bus:tty20
[   17.380920] PM: Adding info for No Bus:tty21
[   17.380986] PM: Adding info for No Bus:tty22
[   17.381063] PM: Adding info for No Bus:tty23
[   17.381124] PM: Adding info for No Bus:tty24
[   17.381185] PM: Adding info for No Bus:tty25
[   17.381263] PM: Adding info for No Bus:tty26
[   17.381328] PM: Adding info for No Bus:tty27
[   17.381390] PM: Adding info for No Bus:tty28
[   17.381465] PM: Adding info for No Bus:tty29
[   17.381527] PM: Adding info for No Bus:tty30
[   17.381604] PM: Adding info for No Bus:tty31
[   17.381680] PM: Adding info for No Bus:tty32
[   17.381742] PM: Adding info for No Bus:tty33
[   17.381806] PM: Adding info for No Bus:tty34
[   17.381888] PM: Adding info for No Bus:tty35
[   17.381952] PM: Adding info for No Bus:tty36
[   17.382017] PM: Adding info for No Bus:tty37
[   17.382101] PM: Adding info for No Bus:tty38
[   17.382169] PM: Adding info for No Bus:tty39
[   17.382233] PM: Adding info for No Bus:tty40
[   17.382313] PM: Adding info for No Bus:tty41
[   17.382378] PM: Adding info for No Bus:tty42
[   17.382450] PM: Adding info for No Bus:tty43
[   17.382532] PM: Adding info for No Bus:tty44
[   17.382597] PM: Adding info for No Bus:tty45
[   17.382663] PM: Adding info for No Bus:tty46
[   17.382746] PM: Adding info for No Bus:tty47
[   17.382812] PM: Adding info for No Bus:tty48
[   17.382878] PM: Adding info for No Bus:tty49
[   17.382966] PM: Adding info for No Bus:tty50
[   17.383033] PM: Adding info for No Bus:tty51
[   17.383099] PM: Adding info for No Bus:tty52
[   17.383182] PM: Adding info for No Bus:tty53
[   17.383248] PM: Adding info for No Bus:tty54
[   17.383316] PM: Adding info for No Bus:tty55
[   17.383399] PM: Adding info for No Bus:tty56
[   17.383467] PM: Adding info for No Bus:tty57
[   17.383537] PM: Adding info for No Bus:tty58
[   17.383622] PM: Adding info for No Bus:tty59
[   17.383690] PM: Adding info for No Bus:tty60
[   17.383756] PM: Adding info for No Bus:tty61
[   17.383846] PM: Adding info for No Bus:tty62
[   17.383916] PM: Adding info for No Bus:tty63
[   17.384003] PM: Adding info for No Bus:ptyp0
[   17.384085] PM: Adding info for No Bus:ptyp1
[   17.384153] PM: Adding info for No Bus:ptyp2
[   17.384220] PM: Adding info for No Bus:ptyp3
[   17.384303] PM: Adding info for No Bus:ptyp4
[   17.384370] PM: Adding info for No Bus:ptyp5
[   17.384436] PM: Adding info for No Bus:ptyp6
[   17.384519] PM: Adding info for No Bus:ptyp7
[   17.384589] PM: Adding info for No Bus:ptyp8
[   17.384656] PM: Adding info for No Bus:ptyp9
[   17.384742] PM: Adding info for No Bus:ptypa
[   17.384810] PM: Adding info for No Bus:ptypb
[   17.384878] PM: Adding info for No Bus:ptypc
[   17.384961] PM: Adding info for No Bus:ptypd
[   17.385029] PM: Adding info for No Bus:ptype
[   17.385099] PM: Adding info for No Bus:ptypf
[   17.385183] PM: Adding info for No Bus:ptyq0
[   17.385255] PM: Adding info for No Bus:ptyq1
[   17.385328] PM: Adding info for No Bus:ptyq2
[   17.385416] PM: Adding info for No Bus:ptyq3
[   17.385488] PM: Adding info for No Bus:ptyq4
[   17.385563] PM: Adding info for No Bus:ptyq5
[   17.385658] PM: Adding info for No Bus:ptyq6
[   17.385729] PM: Adding info for No Bus:ptyq7
[   17.385799] PM: Adding info for No Bus:ptyq8
[   17.385889] PM: Adding info for No Bus:ptyq9
[   17.385959] PM: Adding info for No Bus:ptyqa
[   17.386032] PM: Adding info for No Bus:ptyqb
[   17.386118] PM: Adding info for No Bus:ptyqc
[   17.386189] PM: Adding info for No Bus:ptyqd
[   17.386260] PM: Adding info for No Bus:ptyqe
[   17.386349] PM: Adding info for No Bus:ptyqf
[   17.386421] PM: Adding info for No Bus:ptyr0
[   17.386491] PM: Adding info for No Bus:ptyr1
[   17.386583] PM: Adding info for No Bus:ptyr2
[   17.386662] PM: Adding info for No Bus:ptyr3
[   17.386734] PM: Adding info for No Bus:ptyr4
[   17.386822] PM: Adding info for No Bus:ptyr5
[   17.386896] PM: Adding info for No Bus:ptyr6
[   17.386968] PM: Adding info for No Bus:ptyr7
[   17.387059] PM: Adding info for No Bus:ptyr8
[   17.387132] PM: Adding info for No Bus:ptyr9
[   17.387204] PM: Adding info for No Bus:ptyra
[   17.387296] PM: Adding info for No Bus:ptyrb
[   17.387370] PM: Adding info for No Bus:ptyrc
[   17.387444] PM: Adding info for No Bus:ptyrd
[   17.387537] PM: Adding info for No Bus:ptyre
[   17.387613] PM: Adding info for No Bus:ptyrf
[   17.387689] PM: Adding info for No Bus:ptys0
[   17.387781] PM: Adding info for No Bus:ptys1
[   17.387859] PM: Adding info for No Bus:ptys2
[   17.387937] PM: Adding info for No Bus:ptys3
[   17.388028] PM: Adding info for No Bus:ptys4
[   17.388102] PM: Adding info for No Bus:ptys5
[   17.388187] PM: Adding info for No Bus:ptys6
[   17.388283] PM: Adding info for No Bus:ptys7
[   17.388362] PM: Adding info for No Bus:ptys8
[   17.388438] PM: Adding info for No Bus:ptys9
[   17.388536] PM: Adding info for No Bus:ptysa
[   17.388617] PM: Adding info for No Bus:ptysb
[   17.388695] PM: Adding info for No Bus:ptysc
[   17.388794] PM: Adding info for No Bus:ptysd
[   17.388877] PM: Adding info for No Bus:ptyse
[   17.388961] PM: Adding info for No Bus:ptysf
[   17.389060] PM: Adding info for No Bus:ptyt0
[   17.389143] PM: Adding info for No Bus:ptyt1
[   17.389222] PM: Adding info for No Bus:ptyt2
[   17.389321] PM: Adding info for No Bus:ptyt3
[   17.389404] PM: Adding info for No Bus:ptyt4
[   17.389487] PM: Adding info for No Bus:ptyt5
[   17.389653] PM: Adding info for No Bus:ptyt6
[   17.389737] PM: Adding info for No Bus:ptyt7
[   17.389817] PM: Adding info for No Bus:ptyt8
[   17.389913] PM: Adding info for No Bus:ptyt9
[   17.389996] PM: Adding info for No Bus:ptyta
[   17.390076] PM: Adding info for No Bus:ptytb
[   17.390170] PM: Adding info for No Bus:ptytc
[   17.390254] PM: Adding info for No Bus:ptytd
[   17.390335] PM: Adding info for No Bus:ptyte
[   17.390432] PM: Adding info for No Bus:ptytf
[   17.390513] PM: Adding info for No Bus:ptyu0
[   17.390595] PM: Adding info for No Bus:ptyu1
[   17.390695] PM: Adding info for No Bus:ptyu2
[   17.390777] PM: Adding info for No Bus:ptyu3
[   17.390859] PM: Adding info for No Bus:ptyu4
[   17.390958] PM: Adding info for No Bus:ptyu5
[   17.391040] PM: Adding info for No Bus:ptyu6
[   17.391124] PM: Adding info for No Bus:ptyu7
[   17.391221] PM: Adding info for No Bus:ptyu8
[   17.391304] PM: Adding info for No Bus:ptyu9
[   17.391387] PM: Adding info for No Bus:ptyua
[   17.391490] PM: Adding info for No Bus:ptyub
[   17.391583] PM: Adding info for No Bus:ptyuc
[   17.391675] PM: Adding info for No Bus:ptyud
[   17.391782] PM: Adding info for No Bus:ptyue
[   17.391875] PM: Adding info for No Bus:ptyuf
[   17.391969] PM: Adding info for No Bus:ptyv0
[   17.392072] PM: Adding info for No Bus:ptyv1
[   17.392163] PM: Adding info for No Bus:ptyv2
[   17.392259] PM: Adding info for No Bus:ptyv3
[   17.392368] PM: Adding info for No Bus:ptyv4
[   17.392457] PM: Adding info for No Bus:ptyv5
[   17.392549] PM: Adding info for No Bus:ptyv6
[   17.392656] PM: Adding info for No Bus:ptyv7
[   17.392747] PM: Adding info for No Bus:ptyv8
[   17.392838] PM: Adding info for No Bus:ptyv9
[   17.392950] PM: Adding info for No Bus:ptyva
[   17.393043] PM: Adding info for No Bus:ptyvb
[   17.393137] PM: Adding info for No Bus:ptyvc
[   17.393246] PM: Adding info for No Bus:ptyvd
[   17.393335] PM: Adding info for No Bus:ptyve
[   17.393430] PM: Adding info for No Bus:ptyvf
[   17.393605] PM: Adding info for No Bus:ptyw0
[   17.393699] PM: Adding info for No Bus:ptyw1
[   17.393792] PM: Adding info for No Bus:ptyw2
[   17.393898] PM: Adding info for No Bus:ptyw3
[   17.393989] PM: Adding info for No Bus:ptyw4
[   17.394077] PM: Adding info for No Bus:ptyw5
[   17.394185] PM: Adding info for No Bus:ptyw6
[   17.394277] PM: Adding info for No Bus:ptyw7
[   17.394367] PM: Adding info for No Bus:ptyw8
[   17.394472] PM: Adding info for No Bus:ptyw9
[   17.394565] PM: Adding info for No Bus:ptywa
[   17.394658] PM: Adding info for No Bus:ptywb
[   17.394764] PM: Adding info for No Bus:ptywc
[   17.394855] PM: Adding info for No Bus:ptywd
[   17.394948] PM: Adding info for No Bus:ptywe
[   17.395058] PM: Adding info for No Bus:ptywf
[   17.395150] PM: Adding info for No Bus:ptyx0
[   17.395241] PM: Adding info for No Bus:ptyx1
[   17.395355] PM: Adding info for No Bus:ptyx2
[   17.395449] PM: Adding info for No Bus:ptyx3
[   17.395540] PM: Adding info for No Bus:ptyx4
[   17.395649] PM: Adding info for No Bus:ptyx5
[   17.395750] PM: Adding info for No Bus:ptyx6
[   17.395849] PM: Adding info for No Bus:ptyx7
[   17.395963] PM: Adding info for No Bus:ptyx8
[   17.396064] PM: Adding info for No Bus:ptyx9
[   17.396165] PM: Adding info for No Bus:ptyxa
[   17.396280] PM: Adding info for No Bus:ptyxb
[   17.396383] PM: Adding info for No Bus:ptyxc
[   17.396481] PM: Adding info for No Bus:ptyxd
[   17.396596] PM: Adding info for No Bus:ptyxe
[   17.396697] PM: Adding info for No Bus:ptyxf
[   17.396796] PM: Adding info for No Bus:ptyy0
[   17.396913] PM: Adding info for No Bus:ptyy1
[   17.397013] PM: Adding info for No Bus:ptyy2
[   17.397113] PM: Adding info for No Bus:ptyy3
[   17.397225] PM: Adding info for No Bus:ptyy4
[   17.397329] PM: Adding info for No Bus:ptyy5
[   17.397430] PM: Adding info for No Bus:ptyy6
[   17.397603] PM: Adding info for No Bus:ptyy7
[   17.397703] PM: Adding info for No Bus:ptyy8
[   17.397798] PM: Adding info for No Bus:ptyy9
[   17.397913] PM: Adding info for No Bus:ptyya
[   17.398012] PM: Adding info for No Bus:ptyyb
[   17.398113] PM: Adding info for No Bus:ptyyc
[   17.398225] PM: Adding info for No Bus:ptyyd
[   17.398324] PM: Adding info for No Bus:ptyye
[   17.398425] PM: Adding info for No Bus:ptyyf
[   17.398541] PM: Adding info for No Bus:ptyz0
[   17.398640] PM: Adding info for No Bus:ptyz1
[   17.398738] PM: Adding info for No Bus:ptyz2
[   17.398853] PM: Adding info for No Bus:ptyz3
[   17.398954] PM: Adding info for No Bus:ptyz4
[   17.399054] PM: Adding info for No Bus:ptyz5
[   17.399173] PM: Adding info for No Bus:ptyz6
[   17.399277] PM: Adding info for No Bus:ptyz7
[   17.399377] PM: Adding info for No Bus:ptyz8
[   17.399492] PM: Adding info for No Bus:ptyz9
[   17.399594] PM: Adding info for No Bus:ptyza
[   17.399695] PM: Adding info for No Bus:ptyzb
[   17.399819] PM: Adding info for No Bus:ptyzc
[   17.399923] PM: Adding info for No Bus:ptyzd
[   17.400027] PM: Adding info for No Bus:ptyze
[   17.400154] PM: Adding info for No Bus:ptyzf
[   17.400260] PM: Adding info for No Bus:ptya0
[   17.400368] PM: Adding info for No Bus:ptya1
[   17.400494] PM: Adding info for No Bus:ptya2
[   17.400606] PM: Adding info for No Bus:ptya3
[   17.400712] PM: Adding info for No Bus:ptya4
[   17.400836] PM: Adding info for No Bus:ptya5
[   17.400949] PM: Adding info for No Bus:ptya6
[   17.401059] PM: Adding info for No Bus:ptya7
[   17.401184] PM: Adding info for No Bus:ptya8
[   17.401293] PM: Adding info for No Bus:ptya9
[   17.401401] PM: Adding info for No Bus:ptyaa
[   17.401528] PM: Adding info for No Bus:ptyab
[   17.401694] PM: Adding info for No Bus:ptyac
[   17.401799] PM: Adding info for No Bus:ptyad
[   17.401922] PM: Adding info for No Bus:ptyae
[   17.402029] PM: Adding info for No Bus:ptyaf
[   17.402133] PM: Adding info for No Bus:ptyb0
[   17.402255] PM: Adding info for No Bus:ptyb1
[   17.402360] PM: Adding info for No Bus:ptyb2
[   17.402469] PM: Adding info for No Bus:ptyb3
[   17.402590] PM: Adding info for No Bus:ptyb4
[   17.402701] PM: Adding info for No Bus:ptyb5
[   17.402812] PM: Adding info for No Bus:ptyb6
[   17.402936] PM: Adding info for No Bus:ptyb7
[   17.403045] PM: Adding info for No Bus:ptyb8
[   17.403154] PM: Adding info for No Bus:ptyb9
[   17.403281] PM: Adding info for No Bus:ptyba
[   17.403392] PM: Adding info for No Bus:ptybb
[   17.403502] PM: Adding info for No Bus:ptybc
[   17.403630] PM: Adding info for No Bus:ptybd
[   17.403740] PM: Adding info for No Bus:ptybe
[   17.403854] PM: Adding info for No Bus:ptybf
[   17.403984] PM: Adding info for No Bus:ptyc0
[   17.404103] PM: Adding info for No Bus:ptyc1
[   17.404221] PM: Adding info for No Bus:ptyc2
[   17.404353] PM: Adding info for No Bus:ptyc3
[   17.404472] PM: Adding info for No Bus:ptyc4
[   17.404589] PM: Adding info for No Bus:ptyc5
[   17.404723] PM: Adding info for No Bus:ptyc6
[   17.404840] PM: Adding info for No Bus:ptyc7
[   17.404962] PM: Adding info for No Bus:ptyc8
[   17.405094] PM: Adding info for No Bus:ptyc9
[   17.405216] PM: Adding info for No Bus:ptyca
[   17.405338] PM: Adding info for No Bus:ptycb
[   17.405476] PM: Adding info for No Bus:ptycc
[   17.405658] PM: Adding info for No Bus:ptycd
[   17.405777] PM: Adding info for No Bus:ptyce
[   17.405908] PM: Adding info for No Bus:ptycf
[   17.406025] PM: Adding info for No Bus:ptyd0
[   17.406138] PM: Adding info for No Bus:ptyd1
[   17.406271] PM: Adding info for No Bus:ptyd2
[   17.406388] PM: Adding info for No Bus:ptyd3
[   17.406502] PM: Adding info for No Bus:ptyd4
[   17.406636] PM: Adding info for No Bus:ptyd5
[   17.406752] PM: Adding info for No Bus:ptyd6
[   17.406870] PM: Adding info for No Bus:ptyd7
[   17.406999] PM: Adding info for No Bus:ptyd8
[   17.407116] PM: Adding info for No Bus:ptyd9
[   17.407234] PM: Adding info for No Bus:ptyda
[   17.407367] PM: Adding info for No Bus:ptydb
[   17.407486] PM: Adding info for No Bus:ptydc
[   17.407602] PM: Adding info for No Bus:ptydd
[   17.407741] PM: Adding info for No Bus:ptyde
[   17.407862] PM: Adding info for No Bus:ptydf
[   17.407984] PM: Adding info for No Bus:ptye0
[   17.408120] PM: Adding info for No Bus:ptye1
[   17.408248] PM: Adding info for No Bus:ptye2
[   17.408373] PM: Adding info for No Bus:ptye3
[   17.408510] PM: Adding info for No Bus:ptye4
[   17.408635] PM: Adding info for No Bus:ptye5
[   17.408764] PM: Adding info for No Bus:ptye6
[   17.408908] PM: Adding info for No Bus:ptye7
[   17.409038] PM: Adding info for No Bus:ptye8
[   17.409163] PM: Adding info for No Bus:ptye9
[   17.409310] PM: Adding info for No Bus:ptyea
[   17.409442] PM: Adding info for No Bus:ptyeb
[   17.409634] PM: Adding info for No Bus:ptyec
[   17.409777] PM: Adding info for No Bus:ptyed
[   17.409901] PM: Adding info for No Bus:ptyee
[   17.410027] PM: Adding info for No Bus:ptyef
[   17.410173] PM: Adding info for No Bus:ttyp0
[   17.410293] PM: Adding info for No Bus:ttyp1
[   17.410412] PM: Adding info for No Bus:ttyp2
[   17.410548] PM: Adding info for No Bus:ttyp3
[   17.410672] PM: Adding info for No Bus:ttyp4
[   17.410792] PM: Adding info for No Bus:ttyp5
[   17.410932] PM: Adding info for No Bus:ttyp6
[   17.411053] PM: Adding info for No Bus:ttyp7
[   17.411176] PM: Adding info for No Bus:ttyp8
[   17.411313] PM: Adding info for No Bus:ttyp9
[   17.411435] PM: Adding info for No Bus:ttypa
[   17.411559] PM: Adding info for No Bus:ttypb
[   17.411698] PM: Adding info for No Bus:ttypc
[   17.411822] PM: Adding info for No Bus:ttypd
[   17.411947] PM: Adding info for No Bus:ttype
[   17.412089] PM: Adding info for No Bus:ttypf
[   17.412217] PM: Adding info for No Bus:ttyq0
[   17.412345] PM: Adding info for No Bus:ttyq1
[   17.412495] PM: Adding info for No Bus:ttyq2
[   17.412628] PM: Adding info for No Bus:ttyq3
[   17.412755] PM: Adding info for No Bus:ttyq4
[   17.412906] PM: Adding info for No Bus:ttyq5
[   17.413041] PM: Adding info for No Bus:ttyq6
[   17.413180] PM: Adding info for No Bus:ttyq7
[   17.413327] PM: Adding info for No Bus:ttyq8
[   17.413464] PM: Adding info for No Bus:ttyq9
[   17.413655] PM: Adding info for No Bus:ttyqa
[   17.413802] PM: Adding info for No Bus:ttyqb
[   17.413931] PM: Adding info for No Bus:ttyqc
[   17.414060] PM: Adding info for No Bus:ttyqd
[   17.414208] PM: Adding info for No Bus:ttyqe
[   17.414342] PM: Adding info for No Bus:ttyqf
[   17.414471] PM: Adding info for No Bus:ttyr0
[   17.414614] PM: Adding info for No Bus:ttyr1
[   17.414746] PM: Adding info for No Bus:ttyr2
[   17.414877] PM: Adding info for No Bus:ttyr3
[   17.415022] PM: Adding info for No Bus:ttyr4
[   17.415154] PM: Adding info for No Bus:ttyr5
[   17.415290] PM: Adding info for No Bus:ttyr6
[   17.415438] PM: Adding info for No Bus:ttyr7
[   17.415569] PM: Adding info for No Bus:ttyr8
[   17.415702] PM: Adding info for No Bus:ttyr9
[   17.415854] PM: Adding info for No Bus:ttyra
[   17.415987] PM: Adding info for No Bus:ttyrb
[   17.416119] PM: Adding info for No Bus:ttyrc
[   17.416270] PM: Adding info for No Bus:ttyrd
[   17.416405] PM: Adding info for No Bus:ttyre
[   17.416548] PM: Adding info for No Bus:ttyrf
[   17.416700] PM: Adding info for No Bus:ttys0
[   17.416838] PM: Adding info for No Bus:ttys1
[   17.416980] PM: Adding info for No Bus:ttys2
[   17.417139] PM: Adding info for No Bus:ttys3
[   17.417276] PM: Adding info for No Bus:ttys4
[   17.417420] PM: Adding info for No Bus:ttys5
[   17.417645] PM: Adding info for No Bus:ttys6
[   17.417790] PM: Adding info for No Bus:ttys7
[   17.417925] PM: Adding info for No Bus:ttys8
[   17.418076] PM: Adding info for No Bus:ttys9
[   17.418213] PM: Adding info for No Bus:ttysa
[   17.418352] PM: Adding info for No Bus:ttysb
[   17.418506] PM: Adding info for No Bus:ttysc
[   17.418645] PM: Adding info for No Bus:ttysd
[   17.418782] PM: Adding info for No Bus:ttyse
[   17.418938] PM: Adding info for No Bus:ttysf
[   17.419076] PM: Adding info for No Bus:ttyt0
[   17.419213] PM: Adding info for No Bus:ttyt1
[   17.419370] PM: Adding info for No Bus:ttyt2
[   17.419515] PM: Adding info for No Bus:ttyt3
[   17.419657] PM: Adding info for No Bus:ttyt4
[   17.419814] PM: Adding info for No Bus:ttyt5
[   17.419954] PM: Adding info for No Bus:ttyt6
[   17.420096] PM: Adding info for No Bus:ttyt7
[   17.420256] PM: Adding info for No Bus:ttyt8
[   17.420399] PM: Adding info for No Bus:ttyt9
[   17.420540] PM: Adding info for No Bus:ttyta
[   17.420704] PM: Adding info for No Bus:ttytb
[   17.420856] PM: Adding info for No Bus:ttytc
[   17.421003] PM: Adding info for No Bus:ttytd
[   17.421171] PM: Adding info for No Bus:ttyte
[   17.421323] PM: Adding info for No Bus:ttytf
[   17.421470] PM: Adding info for No Bus:ttyu0
[   17.421695] PM: Adding info for No Bus:ttyu1
[   17.421842] PM: Adding info for No Bus:ttyu2
[   17.421986] PM: Adding info for No Bus:ttyu3
[   17.422145] PM: Adding info for No Bus:ttyu4
[   17.422289] PM: Adding info for No Bus:ttyu5
[   17.422431] PM: Adding info for No Bus:ttyu6
[   17.422593] PM: Adding info for No Bus:ttyu7
[   17.422737] PM: Adding info for No Bus:ttyu8
[   17.422885] PM: Adding info for No Bus:ttyu9
[   17.423054] PM: Adding info for No Bus:ttyua
[   17.423203] PM: Adding info for No Bus:ttyub
[   17.423350] PM: Adding info for No Bus:ttyuc
[   17.423514] PM: Adding info for No Bus:ttyud
[   17.423664] PM: Adding info for No Bus:ttyue
[   17.423814] PM: Adding info for No Bus:ttyuf
[   17.423976] PM: Adding info for No Bus:ttyv0
[   17.424129] PM: Adding info for No Bus:ttyv1
[   17.424276] PM: Adding info for No Bus:ttyv2
[   17.424441] PM: Adding info for No Bus:ttyv3
[   17.424589] PM: Adding info for No Bus:ttyv4
[   17.424738] PM: Adding info for No Bus:ttyv5
[   17.424918] PM: Adding info for No Bus:ttyv6
[   17.425075] PM: Adding info for No Bus:ttyv7
[   17.425227] PM: Adding info for No Bus:ttyv8
[   17.425403] PM: Adding info for No Bus:ttyv9
[   17.425621] PM: Adding info for No Bus:ttyva
[   17.425779] PM: Adding info for No Bus:ttyvb
[   17.425945] PM: Adding info for No Bus:ttyvc
[   17.426096] PM: Adding info for No Bus:ttyvd
[   17.426247] PM: Adding info for No Bus:ttyve
[   17.426421] PM: Adding info for No Bus:ttyvf
[   17.426574] PM: Adding info for No Bus:ttyw0
[   17.426727] PM: Adding info for No Bus:ttyw1
[   17.426900] PM: Adding info for No Bus:ttyw2
[   17.427057] PM: Adding info for No Bus:ttyw3
[   17.427211] PM: Adding info for No Bus:ttyw4
[   17.427380] PM: Adding info for No Bus:ttyw5
[   17.427536] PM: Adding info for No Bus:ttyw6
[   17.427696] PM: Adding info for No Bus:ttyw7
[   17.427868] PM: Adding info for No Bus:ttyw8
[   17.428025] PM: Adding info for No Bus:ttyw9
[   17.428181] PM: Adding info for No Bus:ttywa
[   17.428357] PM: Adding info for No Bus:ttywb
[   17.428516] PM: Adding info for No Bus:ttywc
[   17.428672] PM: Adding info for No Bus:ttywd
[   17.428848] PM: Adding info for No Bus:ttywe
[   17.429017] PM: Adding info for No Bus:ttywf
[   17.429182] PM: Adding info for No Bus:ttyx0
[   17.429361] PM: Adding info for No Bus:ttyx1
[   17.429523] PM: Adding info for No Bus:ttyx2
[   17.429745] PM: Adding info for No Bus:ttyx3
[   17.429919] PM: Adding info for No Bus:ttyx4
[   17.430084] PM: Adding info for No Bus:ttyx5
[   17.430244] PM: Adding info for No Bus:ttyx6
[   17.430423] PM: Adding info for No Bus:ttyx7
[   17.430585] PM: Adding info for No Bus:ttyx8
[   17.430744] PM: Adding info for No Bus:ttyx9
[   17.430924] PM: Adding info for No Bus:ttyxa
[   17.431087] PM: Adding info for No Bus:ttyxb
[   17.431249] PM: Adding info for No Bus:ttyxc
[   17.431430] PM: Adding info for No Bus:ttyxd
[   17.431593] PM: Adding info for No Bus:ttyxe
[   17.431759] PM: Adding info for No Bus:ttyxf
[   17.431936] PM: Adding info for No Bus:ttyy0
[   17.432102] PM: Adding info for No Bus:ttyy1
[   17.432265] PM: Adding info for No Bus:ttyy2
[   17.432446] PM: Adding info for No Bus:ttyy3
[   17.432611] PM: Adding info for No Bus:ttyy4
[   17.432777] PM: Adding info for No Bus:ttyy5
[   17.432963] PM: Adding info for No Bus:ttyy6
[   17.433137] PM: Adding info for No Bus:ttyy7
[   17.433304] PM: Adding info for No Bus:ttyy8
[   17.433488] PM: Adding info for No Bus:ttyy9
[   17.433723] PM: Adding info for No Bus:ttyya
[   17.433896] PM: Adding info for No Bus:ttyyb
[   17.434080] PM: Adding info for No Bus:ttyyc
[   17.434249] PM: Adding info for No Bus:ttyyd
[   17.434418] PM: Adding info for No Bus:ttyye
[   17.434602] PM: Adding info for No Bus:ttyyf
[   17.434771] PM: Adding info for No Bus:ttyz0
[   17.434937] PM: Adding info for No Bus:ttyz1
[   17.435125] PM: Adding info for No Bus:ttyz2
[   17.435299] PM: Adding info for No Bus:ttyz3
[   17.435465] PM: Adding info for No Bus:ttyz4
[   17.435647] PM: Adding info for No Bus:ttyz5
[   17.435817] PM: Adding info for No Bus:ttyz6
[   17.435988] PM: Adding info for No Bus:ttyz7
[   17.436171] PM: Adding info for No Bus:ttyz8
[   17.436342] PM: Adding info for No Bus:ttyz9
[   17.436511] PM: Adding info for No Bus:ttyza
[   17.436703] PM: Adding info for No Bus:ttyzb
[   17.436875] PM: Adding info for No Bus:ttyzc
[   17.437045] PM: Adding info for No Bus:ttyzd
[   17.437237] PM: Adding info for No Bus:ttyze
[   17.437413] PM: Adding info for No Bus:ttyzf
[   17.437651] PM: Adding info for No Bus:ttya0
[   17.437849] PM: Adding info for No Bus:ttya1
[   17.438024] PM: Adding info for No Bus:ttya2
[   17.438198] PM: Adding info for No Bus:ttya3
[   17.438386] PM: Adding info for No Bus:ttya4
[   17.438562] PM: Adding info for No Bus:ttya5
[   17.438736] PM: Adding info for No Bus:ttya6
[   17.438926] PM: Adding info for No Bus:ttya7
[   17.439103] PM: Adding info for No Bus:ttya8
[   17.439281] PM: Adding info for No Bus:ttya9
[   17.439474] PM: Adding info for No Bus:ttyaa
[   17.439651] PM: Adding info for No Bus:ttyab
[   17.439826] PM: Adding info for No Bus:ttyac
[   17.440016] PM: Adding info for No Bus:ttyad
[   17.440195] PM: Adding info for No Bus:ttyae
[   17.440374] PM: Adding info for No Bus:ttyaf
[   17.440564] PM: Adding info for No Bus:ttyb0
[   17.440746] PM: Adding info for No Bus:ttyb1
[   17.440926] PM: Adding info for No Bus:ttyb2
[   17.441123] PM: Adding info for No Bus:ttyb3
[   17.441302] PM: Adding info for No Bus:ttyb4
[   17.441486] PM: Adding info for No Bus:ttyb5
[   17.441746] PM: Adding info for No Bus:ttyb6
[   17.441933] PM: Adding info for No Bus:ttyb7
[   17.442111] PM: Adding info for No Bus:ttyb8
[   17.442311] PM: Adding info for No Bus:ttyb9
[   17.442493] PM: Adding info for No Bus:ttyba
[   17.442677] PM: Adding info for No Bus:ttybb
[   17.442872] PM: Adding info for No Bus:ttybc
[   17.443054] PM: Adding info for No Bus:ttybd
[   17.443234] PM: Adding info for No Bus:ttybe
[   17.443436] PM: Adding info for No Bus:ttybf
[   17.443618] PM: Adding info for No Bus:ttyc0
[   17.443800] PM: Adding info for No Bus:ttyc1
[   17.444003] PM: Adding info for No Bus:ttyc2
[   17.444193] PM: Adding info for No Bus:ttyc3
[   17.444375] PM: Adding info for No Bus:ttyc4
[   17.444573] PM: Adding info for No Bus:ttyc5
[   17.444757] PM: Adding info for No Bus:ttyc6
[   17.444949] PM: Adding info for No Bus:ttyc7
[   17.445149] PM: Adding info for No Bus:ttyc8
[   17.445335] PM: Adding info for No Bus:ttyc9
[   17.445520] PM: Adding info for No Bus:ttyca
[   17.445785] PM: Adding info for No Bus:ttycb
[   17.445974] PM: Adding info for No Bus:ttycc
[   17.446160] PM: Adding info for No Bus:ttycd
[   17.446369] PM: Adding info for No Bus:ttyce
[   17.446559] PM: Adding info for No Bus:ttycf
[   17.446748] PM: Adding info for No Bus:ttyd0
[   17.446950] PM: Adding info for No Bus:ttyd1
[   17.447138] PM: Adding info for No Bus:ttyd2
[   17.447326] PM: Adding info for No Bus:ttyd3
[   17.447528] PM: Adding info for No Bus:ttyd4
[   17.447719] PM: Adding info for No Bus:ttyd5
[   17.447909] PM: Adding info for No Bus:ttyd6
[   17.448117] PM: Adding info for No Bus:ttyd7
[   17.448306] PM: Adding info for No Bus:ttyd8
[   17.448493] PM: Adding info for No Bus:ttyd9
[   17.448701] PM: Adding info for No Bus:ttyda
[   17.448896] PM: Adding info for No Bus:ttydb
[   17.449084] PM: Adding info for No Bus:ttydc
[   17.449294] PM: Adding info for No Bus:ttydd
[   17.449482] PM: Adding info for No Bus:ttyde
[   17.449737] PM: Adding info for No Bus:ttydf
[   17.449944] PM: Adding info for No Bus:ttye0
[   17.450134] PM: Adding info for No Bus:ttye1
[   17.450324] PM: Adding info for No Bus:ttye2
[   17.450533] PM: Adding info for No Bus:ttye3
[   17.450729] PM: Adding info for No Bus:ttye4
[   17.450921] PM: Adding info for No Bus:ttye5
[   17.451131] PM: Adding info for No Bus:ttye6
[   17.451325] PM: Adding info for No Bus:ttye7
[   17.451519] PM: Adding info for No Bus:ttye8
[   17.451730] PM: Adding info for No Bus:ttye9
[   17.451926] PM: Adding info for No Bus:ttyea
[   17.452126] PM: Adding info for No Bus:ttyeb
[   17.452339] PM: Adding info for No Bus:ttyec
[   17.452536] PM: Adding info for No Bus:ttyed
[   17.452733] PM: Adding info for No Bus:ttyee
[   17.452950] PM: Adding info for No Bus:ttyef
[   17.453041] PM: Adding info for No Bus:rtc
[   17.453112] Real Time Clock Driver v1.12ac
[   17.453127] PM: Adding info for No Bus:hpet
[   17.453349] PM: Adding info for No Bus:nvram
[   17.453410] Non-volatile memory driver v1.2
[   17.453414] Linux agpgart interface v0.102 (c) Dave Jones
[   17.453491] agpgart: Detected an Intel 855PM Chipset.
[   17.467082] PM: Adding info for No Bus:agpgart
[   17.467185] agpgart: AGP aperture is 256M @ 0xb0000000
[   17.467259] [drm] Initialized drm 1.1.0 20060810
[   17.467262] Hangcheck: starting hangcheck timer 0.9.0 (tick is 180 seconds, margin is 60 seconds).
[   17.467265] Hangcheck: Using get_cycles().
[   17.467295] PM: Adding info for No Bus:isa
[   17.468471] RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
[   17.468583] PM: Adding info for No Bus:lo
[   17.469040] PNP: PS/2 Controller [PNP0303:C1A3,PNP0f13:C1A4] at 0x60,0x64 irq 1,12
[   17.469143] PM: Adding info for platform:i8042
[   17.479662] i8042.c: Detected active multiplexing controller, rev 1.1.
[   17.484951] serio: i8042 KBD port at 0x60,0x64 irq 1
[   17.484981] PM: Adding info for serio:serio0
[   17.485019] serio: i8042 AUX0 port at 0x60,0x64 irq 12
[   17.485023] serio: i8042 AUX1 port at 0x60,0x64 irq 12
[   17.485028] serio: i8042 AUX2 port at 0x60,0x64 irq 12
[   17.485032] serio: i8042 AUX3 port at 0x60,0x64 irq 12
[   17.485134] PM: Adding info for serio:serio1
[   17.485191] mice: PS/2 mouse device common for all mice
[   17.485257] PM: Adding info for serio:serio2
[   17.485976] input: PC Speaker as /class/input/input0
[   17.489176] PM: Adding info for serio:serio3
[   17.516161] NET: Registered protocol family 1
[   17.516168] NET: Registered protocol family 17
[   17.516437] Testing NMI watchdog ... <7>PM: Adding info for serio:serio4
[   17.556788] OK.
[   17.556791] Using IPI Shortcut mode
[   17.556923] swsusp: Resume From Partition /dev/hda2
[   17.556925] PM: Checking swsusp image.
[   17.556942] swsusp: Error -6 check for resume file
[   17.556944] PM: Resume from disk failed.
[   17.557449] Freeing unused kernel memory: 196k freed
[   17.557515] Write protecting the kernel read-only data: 646k
[   17.557524] Time: tsc clocksource has been installed.
[   17.557605] PM: Adding info for No Bus:vcs1
[   17.557674] PM: Adding info for No Bus:vcsa1
[   17.833716] usbcore: registered new interface driver usbfs
[   17.833786] usbcore: registered new interface driver hub
[   17.833871] usbcore: registered new device driver usb
[   17.836138] USB Universal Host Controller Interface driver v3.0
[   17.836237] ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [C0C2] -> GSI 10 (level, low) -> IRQ 10
[   17.836253] PCI: Setting latency timer of device 0000:00:1d.0 to 64
[   17.836258] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[   17.836502] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 1
[   17.836533] uhci_hcd 0000:00:1d.0: irq 10, io base 0x000048c0
[   17.836648] PM: Adding info for usb:usb1
[   17.836812] PM: Adding info for No Bus:usbdev1.1_ep00
[   17.836864] usb usb1: configuration #1 chosen from 1 choice
[   17.836901] PM: Adding info for usb:1-0:1.0
[   17.836970] hub 1-0:1.0: USB hub found
[   17.836995] hub 1-0:1.0: 2 ports detected
[   17.937548] PM: Adding info for No Bus:usbdev1.1_ep81
[   17.937647] PM: Adding info for No Bus:usbdev1.1
[   17.938191] ACPI: PCI Interrupt Link [C0C5] enabled at IRQ 5
[   17.938194] ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [C0C5] -> GSI 5 (level, low) -> IRQ 5
[   17.938206] PCI: Setting latency timer of device 0000:00:1d.1 to 64
[   17.938210] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[   17.938263] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 2
[   17.938289] uhci_hcd 0000:00:1d.1: irq 5, io base 0x000048e0
[   17.938380] PM: Adding info for usb:usb2
[   17.938473] PM: Adding info for No Bus:usbdev2.1_ep00
[   17.938519] usb usb2: configuration #1 chosen from 1 choice
[   17.938538] PM: Adding info for usb:2-0:1.0
[   17.938585] hub 2-0:1.0: USB hub found
[   17.938597] hub 2-0:1.0: 2 ports detected
[   18.017509] Switched to high resolution mode on CPU 0
[   18.041396] PM: Adding info for No Bus:usbdev2.1_ep81
[   18.041461] PM: Adding info for No Bus:usbdev2.1
[   18.041546] ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [C0C4] -> GSI 5 (level, low) -> IRQ 5
[   18.041561] PCI: Setting latency timer of device 0000:00:1d.2 to 64
[   18.041565] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[   18.041633] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 3
[   18.041656] uhci_hcd 0000:00:1d.2: irq 5, io base 0x00004c00
[   18.041734] PM: Adding info for usb:usb3
[   18.041821] PM: Adding info for No Bus:usbdev3.1_ep00
[   18.041866] usb usb3: configuration #1 chosen from 1 choice
[   18.041885] PM: Adding info for usb:3-0:1.0
[   18.041948] hub 3-0:1.0: USB hub found
[   18.041959] hub 3-0:1.0: 2 ports detected
[   18.145369] PM: Adding info for No Bus:usbdev3.1_ep81
[   18.145436] PM: Adding info for No Bus:usbdev3.1
[   18.147639] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
[   18.151112] ACPI: PCI Interrupt Link [C0C9] enabled at IRQ 5
[   18.151117] ACPI: PCI Interrupt 0000:00:1d.7[D] -> Link [C0C9] -> GSI 5 (level, low) -> IRQ 5
[   18.151133] PCI: Setting latency timer of device 0000:00:1d.7 to 64
[   18.151138] ehci_hcd 0000:00:1d.7: EHCI Host Controller
[   18.151199] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 4
[   18.151239] ehci_hcd 0000:00:1d.7: debug port 1
[   18.151248] PCI: cache line size of 32 is not supported by device 0000:00:1d.7
[   18.151257] ehci_hcd 0000:00:1d.7: irq 5, io mem 0xa0000000
[   18.155131] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[   18.155193] PM: Adding info for usb:usb4
[   18.155277] PM: Adding info for No Bus:usbdev4.1_ep00
[   18.155308] usb usb4: configuration #1 chosen from 1 choice
[   18.155330] PM: Adding info for usb:4-0:1.0
[   18.155377] hub 4-0:1.0: USB hub found
[   18.155436] hub 4-0:1.0: 6 ports detected
[   18.257358] PM: Adding info for No Bus:usbdev4.1_ep81
[   18.257424] PM: Adding info for No Bus:usbdev4.1
[   18.274141] SCSI subsystem initialized
[   18.289005] libata version 2.10 loaded.
[   18.292848] ata_piix 0000:00:1f.1: version 2.00ac7
[   18.292871] PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
[   18.292884] ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [C0C4] -> GSI 5 (level, low) -> IRQ 5
[   18.292912] PCI: Setting latency timer of device 0000:00:1f.1 to 64
[   18.293061] ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x00014c40 irq 14
[   18.293109] ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x00014c48 irq 15
[   18.293143] scsi0 : ata_piix
[   18.293158] PM: Adding info for No Bus:host0
[   18.317733] Synaptics Touchpad, model: 1, fw: 5.9, id: 0x236eb3, caps: 0x904713/0x10008
[   18.375112] input: SynPS/2 Synaptics TouchPad as /class/input/input1
[   18.403567] input: AT Translated Set 2 keyboard as /class/input/input2
[   18.457965] ata1.00: ATA-6: FUJITSU MHT2080AH PL, 006C, max UDMA/100
[   18.457969] ata1.00: 156301488 sectors, multi 16: LBA 
[   18.469868] ata1.00: configured for UDMA/100
[   18.469878] scsi1 : ata_piix
[   18.469907] PM: Adding info for No Bus:host1
[   18.789870] ata2.00: ATAPI, max MWDMA2
[   18.889270] usb 3-2: new full speed USB device using uhci_hcd and address 2
[   18.953823] ata2.00: configured for MWDMA2
[   18.953843] PM: Adding info for No Bus:target0:0:0
[   18.954047] scsi 0:0:0:0: Direct-Access     ATA      FUJITSU MHT2080A 006C PQ: 0 ANSI: 5
[   18.954076] PM: Adding info for scsi:0:0:0:0
[   18.954276] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
[   18.954296] sda: Write Protect is off
[   18.954298] sda: Mode Sense: 00 3a 00 00
[   18.954331] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   18.954458] SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
[   18.954477] sda: Write Protect is off
[   18.954479] sda: Mode Sense: 00 3a 00 00
[   18.954512] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   18.954516]  sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
[   18.998407] sd 0:0:0:0: Attached scsi disk sda
[   18.998481] PM: Adding info for No Bus:target1:0:0
[   19.003578] scsi 1:0:0:0: CD-ROM            HL-DT-ST RW/DVD GCC-4241N 0C29 PQ: 0 ANSI: 5
[   19.003590] PM: Adding info for scsi:1:0:0:0
[   19.121408] PM: Adding info for usb:3-2
[   19.121488] PM: Adding info for No Bus:usbdev3.2_ep00
[   19.121520] usb 3-2: configuration #1 chosen from 1 choice
[   19.125419] PM: Adding info for usb:3-2:1.0
[   19.125473] PM: Adding info for No Bus:usbdev3.2_ep81
[   19.125513] PM: Adding info for No Bus:usbdev3.2_ep02
[   19.125567] PM: Adding info for No Bus:usbdev3.2_ep82
[   19.125601] PM: Adding info for usb:3-2:1.1
[   19.125649] PM: Adding info for No Bus:usbdev3.2_ep03
[   19.125701] PM: Adding info for No Bus:usbdev3.2_ep83
[   19.125737] PM: Adding info for usb:3-2:1.2
[   19.125807] PM: Adding info for No Bus:usbdev3.2
[   22.019963] EXT3-fs: mounted filesystem with ordered data mode.
[   22.020261] kjournald starting.  Commit interval 5 seconds
[   22.745062] PM: Removing info for No Bus:vcs1
[   22.745148] PM: Removing info for No Bus:vcsa1
[   22.745238] PM: Adding info for No Bus:vcs1
[   22.745264] PM: Adding info for No Bus:vcsa1
[   22.745307] PM: Removing info for No Bus:vcs1
[   22.745337] PM: Removing info for No Bus:vcsa1
[   22.853108] PM: Adding info for No Bus:vcs1
[   22.853136] PM: Adding info for No Bus:vcsa1
[   29.827217] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   29.827249] scsi 1:0:0:0: Attached scsi generic sg1 type 5
[   30.101069] ieee80211_crypt: registered algorithm 'NULL'
[   30.182908] ACPI: PCI Interrupt Link [C0C3] enabled at IRQ 10
[   30.182914] ACPI: PCI Interrupt 0000:00:1f.3[B] -> Link [C0C3] -> GSI 10 (level, low) -> IRQ 10
[   30.182966] PM: Adding info for No Bus:i2c-4
[   30.344355] ieee80211: 802.11 data/management/control stack, git-1.1.13
[   30.344361] ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
[   30.481651] ieee1394: Initialized config rom entry `ip1394'
[   30.531451] intel_rng: FWH not detected
[   30.578518] sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
[   30.578526] Uniform CD-ROM driver Revision: 3.20
[   30.578720] sr 1:0:0:0: Attached scsi CD-ROM sr0
[   30.598491] 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
[   30.598576] ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [C0C3] -> GSI 10 (level, low) -> IRQ 10
[   30.598941] PM: Adding info for No Bus:eth0
[   30.599142] eth0: RTL-8139C+ at 0xe18e8000, 00:02:3f:22:db:8c, IRQ 10
[   30.727508] Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
[   30.727636] PM: Adding info for platform:serial8250
[   30.727840] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   30.728078] PM: Adding info for No Bus:ttyS0
[   30.728232] PM: Adding info for No Bus:ttyS1
[   30.749708] PM: Removing info for No Bus:ttyS0
[   30.749880] 00:03: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[   30.750112] PM: Adding info for No Bus:ttyS0
[   30.890646] parport: PnPBIOS parport detected.
[   30.890771] parport0: PC-style at 0x378 (0x778), irq 7, dma 1 [PCSPP,TRISTATE,COMPAT,ECP,DMA]
[   30.924586] ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [C0C2] -> GSI 10 (level, low) -> IRQ 10
[   30.924707] PM: Adding info for ieee1394:fw-host0
[   30.977898] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[10]  MMIO=[90200000-902007ff]  Max Packet=[1024]  IR/IT contexts=[4/8]
[   31.317914] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.2.0kmprq
[   31.317919] ipw2200: Copyright(c) 2003-2006 Intel Corporation
[   31.318059] ACPI: PCI Interrupt 0000:02:02.0[A] -> Link [C0C5] -> GSI 5 (level, low) -> IRQ 5
[   31.318128] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
[   31.318341] PM: Adding info for No Bus:0000:02:02.0
[   31.521036] rtc_cmos 00:09: rtc core: registered rtc_cmos as rtc0
[   31.521090] pnp: Device 00:09 does not support disabling.
[   31.521098] rtc_cmos: probe of 00:09 failed with error -16
[   31.567553] Bluetooth: Core ver 2.11
[   31.567578] PM: Adding info for platform:bluetooth
[   31.567672] NET: Registered protocol family 31
[   31.567674] Bluetooth: HCI device and connection manager initialized
[   31.567776] Bluetooth: HCI socket layer initialized
[   31.809583] NET: Registered protocol family 23
[   31.890511] PM: Adding info for No Bus:timer
[   31.923764] wbsd: Winbond W83L51xD SD/MMC card interface driver
[   31.923768] wbsd: Copyright(c) Pierre Ossman
[   31.924599] pnp: Device 00:02 activated.
[   31.924603] wbsd [wbsd_pnp_probe()]: PnP resources: port 248 irq 6 dma 0
[   31.929771] PM: Adding info for No Bus:mmc0
[   31.929793] mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0
[   31.929862] mmc0: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 21 width 0 timing 0
[   31.930866] mmc0: clock 375000Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 timing 0
[   31.932863] mmc0: clock 375000Hz busmode 1 powermode 2 cs 1 Vdd 21 width 0 timing 0
[   31.933867] mmc0: starting CMD0 arg 00000000 flags 00000040
[   31.933870] wbsd [wbsd_request_end()]: Ending request, cmd (0)
[   31.933894] mmc0: req done (CMD0): 1/0/0: 00000000 00000000 00000000 00000000
[   31.934892] mmc0: clock 375000Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 timing 0
[   31.935898] mmc0: starting CMD8 arg 000001aa flags 00000075
[   31.935901] wbsd [wbsd_request_end()]: Ending request, cmd (8)
[   31.935909] mmc0: req done (CMD8): 1/0/0: 00000000 00000000 00000000 00000000
[   31.935914] mmc0: starting CMD55 arg 00000000 flags 00000015
[   31.935917] wbsd [wbsd_request_end()]: Ending request, cmd (37)
[   31.935925] mmc0: req done (CMD55): 1/0/0: 00000000 00000000 00000000 00000000
[   31.935930] mmc0: starting CMD55 arg 00000000 flags 00000015
[   31.935932] wbsd [wbsd_request_end()]: Ending request, cmd (37)
[   31.935940] mmc0: req done (CMD55): 1/0/0: 00000000 00000000 00000000 00000000
[   31.935945] mmc0: starting CMD55 arg 00000000 flags 00000015
[   31.935948] wbsd [wbsd_request_end()]: Ending request, cmd (37)
[   31.935956] mmc0: req done (CMD55): 1/0/0: 00000000 00000000 00000000 00000000
[   31.935960] mmc0: starting CMD55 arg 00000000 flags 00000015
[   31.935963] wbsd [wbsd_request_end()]: Ending request, cmd (37)
[   31.935971] mmc0: req done (CMD55): 1/0/0: 00000000 00000000 00000000 00000000
[   31.935975] mmc0: starting CMD1 arg 00000000 flags 00000061
[   31.935978] wbsd [wbsd_request_end()]: Ending request, cmd (1)
[   31.935986] mmc0: req done (CMD1): 1/0/0: 00000000 00000000 00000000 00000000
[   31.935991] mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0
[   31.936317] mmc0: W83L51xD id 7112 at 0x248 irq 6 dma 0 PnP
[   31.940026] wbsd: Resetting card detection ignore
[   31.946630] Bluetooth: HCI USB driver ver 2.9
[   31.991096] Detected unconfigured Compaq x1000 family SMSC IrDA chip, pre-configuring device.
[   31.991101] Setting up Intel 82801 controller and SMSC device
[   31.991232] found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
[   31.991248] smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x0e
[   31.991264] SMsC IrDA Controller found
[   31.991266]  IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7
[   31.991329] No transceiver found. Defaulting to Fast pin select
[   32.037151] PM: Removing info for No Bus:usbdev3.2_ep03
[   32.037226] PM: Removing info for No Bus:usbdev3.2_ep83
[   32.037305] PM: Adding info for No Bus:usbdev3.2_ep03
[   32.037347] PM: Adding info for No Bus:usbdev3.2_ep83
[   32.037430] PM: Adding info for No Bus:hci0
[   32.037518] usbcore: registered new interface driver hci_usb
[   32.108177] PM: Removing info for No Bus:0000:02:02.0
[   32.227503] PM: Adding info for No Bus:eth1
[   32.227593] ipw2200: Detected geography ZZR (14 802.11bg channels, 0 802.11a channels)
[   32.228010] PM: Adding info for No Bus:irda0
[   32.228064] PM: Adding info for platform:smsc-ircc2.0
[   32.228098] IrDA: Registered device irda0
[   32.228317] Yenta: CardBus bridge found at 0000:02:04.0 [0e11:0860]
[   32.228341] Yenta: Using CSCINT to route CSC interrupts to PCI
[   32.228344] Yenta: Routing CardBus interrupts to PCI
[   32.228350] Yenta TI: socket 0000:02:04.0, mfunc 0x001c1112, devctl 0x44
[   32.252311] PM: Adding info for ieee1394:00023f454a000284
[   32.252452] ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00023f454a000284]
[   32.252486] PM: Adding info for ieee1394:00023f454a000284-0
[   32.435247] PM: Adding info for No Bus:seq
[   32.464486] Yenta: ISA IRQ mask 0x0818, PCI irq 5
[   32.464491] Socket status: 30000006
[   32.464495] Yenta: Raising subordinate bus# of parent bus (#02) from #03 to #06
[   32.464511] pcmcia: parent PCI bridge I/O window: 0x2000 - 0x2fff
[   32.464595] cs: IO port probe 0x2000-0x2fff: clean.
[   32.465321] pcmcia: parent PCI bridge Memory window: 0x90000000 - 0x903fffff
[   32.465325] pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x33ffffff
[   32.465507] PM: Adding info for No Bus:pcmcia_socket0
[   32.521484] PM: Adding info for No Bus:sequencer
[   32.521601] PM: Adding info for No Bus:sequencer2
[   32.665760] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [C0C3] -> GSI 10 (level, low) -> IRQ 10
[   32.665798] PCI: Setting latency timer of device 0000:00:1f.5 to 64
[   32.912227] cs: IO port probe 0x100-0x3af: excluding 0x140-0x14f 0x200-0x20f
[   32.914055] cs: IO port probe 0x3e0-0x4ff: clean.
[   32.914883] cs: IO port probe 0x820-0x8ff: clean.
[   32.915596] cs: IO port probe 0xc00-0xcf7: clean.
[   32.916632] cs: IO port probe 0xa00-0xaff: clean.
[   33.591857] intel8x0_measure_ac97_clock: measured 55258 usecs
[   33.591861] intel8x0: clocking to 48000
[   33.591899] PM: Adding info for No Bus:card0
[   33.592421] PM: Adding info for No Bus:pcmC0D4p
[   33.592727] PM: Adding info for No Bus:pcmC0D3c
[   33.592902] PM: Adding info for No Bus:pcmC0D2c
[   33.593082] PM: Adding info for No Bus:pcmC0D1c
[   33.593321] PM: Adding info for No Bus:adsp
[   33.593545] PM: Adding info for No Bus:pcmC0D0p
[   33.593716] PM: Adding info for No Bus:pcmC0D0c
[   33.593911] PM: Adding info for No Bus:dsp
[   33.594085] PM: Adding info for No Bus:audio
[   33.594275] PM: Adding info for ac97:0-0:AD1981B
[   33.594644] PM: Adding info for No Bus:controlC0
[   33.594905] PM: Adding info for No Bus:mixer
[   33.758500] ACPI: PCI Interrupt 0000:00:1f.6[B] -> Link [C0C3] -> GSI 10 (level, low) -> IRQ 10
[   33.758524] PCI: Setting latency timer of device 0000:00:1f.6 to 64
[   33.764207] PM: Adding info for No Bus:card1
[   33.764266] PM: Adding info for No Bus:pcmC1D0p
[   33.764315] PM: Adding info for No Bus:pcmC1D0c
[   33.764395] PM: Adding info for No Bus:dsp1
[   33.764430] PM: Adding info for No Bus:audio1
[   33.764476] PM: Adding info for ac97:1-1:Si3036,8
[   33.764537] PM: Adding info for No Bus:controlC1
[   33.764589] PM: Adding info for No Bus:mixer1
[   34.259958] lp0: using parport0 (interrupt-driven).
[   36.009355] PM: Adding info for No Bus:vcs8
[   36.009578] PM: Adding info for No Bus:vcsa8
[   36.010233] PM: Removing info for No Bus:vcs8
[   36.010430] PM: Removing info for No Bus:vcsa8
[   36.011992] PM: Adding info for No Bus:vcs8
[   36.012128] PM: Adding info for No Bus:vcsa8
[   36.016604] PM: Removing info for No Bus:vcs8
[   36.016788] PM: Removing info for No Bus:vcsa8
[   36.746895] NET: Registered protocol family 10
[   36.747096] lo: Disabled Privacy Extensions
[   36.747345] Mobile IPv6
[   37.069451] PM: Adding info for No Bus:vcs8
[   37.069650] PM: Adding info for No Bus:vcsa8
[   37.508858] [drm] Initialized radeon 1.25.0 20060524 on minor 0
[   44.424120] ACPI: AC Adapter [C134] (on-line)
[   44.445177] ACPI: Battery Slot [C11F] (battery absent)
[   44.472180] input: Power Button (FF) as /class/input/input3
[   44.487990] ACPI: Power Button (FF) [PWRF]
[   44.497199] input: Power Button (CM) as /class/input/input4
[   44.497648] ACPI: Power Button (CM) [C1BE]
[   44.498073] input: Lid Switch as /class/input/input5
[   44.498253] ACPI: Lid Switch [C136]
[   44.577672] No dock devices found.
[   44.714156] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
[   44.714165] ACPI: Processor [CPU0] (supports 8 throttling states)
[   44.738813] Time: acpi_pm clocksource has been installed.
[   44.754662] ACPI: Video Device [C0D0] (multi-head: yes  rom: no  post: no)
[   48.399426] EXT3 FS on sda5, internal journal
[   48.516847] kjournald starting.  Commit interval 5 seconds
[   48.517208] EXT3 FS on sda1, internal journal
[   48.517218] EXT3-fs: mounted filesystem with ordered data mode.
[   48.616915] FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[   48.642486] FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
[   49.233012] Adding 1000432k swap on /dev/sda2.  Priority:-1 extents:1 across:1000432k
[   49.396740] PM: Removing info for No Bus:vcs1
[   49.396980] PM: Removing info for No Bus:vcsa1
[   49.656687] PM: Adding info for No Bus:microcode
[   49.672342] PM: Adding info for platform:microcode
[   49.677982] PM: Adding info for No Bus:microcode
[   49.680015] PM: Removing info for No Bus:microcode
[   49.680983] IA-32 Microcode Update Driver: v1.14a <tigran@aivazian.fsnet.co.uk>
[   49.821236] PM: Removing info for No Bus:microcode
[   49.822660] PM: Removing info for platform:microcode
[   50.859647] Clocksource tsc unstable (delta = -150132146 ns)
[   54.182545] audit(1172156319.053:2): audit_pid=2713 old=0 by auid=4294967295
[   76.598140] Bluetooth: L2CAP ver 2.8
[   76.598147] Bluetooth: L2CAP socket layer initialized
[   76.780339] Bluetooth: RFCOMM socket layer initialized
[   76.780360] Bluetooth: RFCOMM TTY layer initialized
[   76.780363] Bluetooth: RFCOMM ver 1.8
[   93.468314] Bluetooth: HIDP (Human Interface Emulation) ver 1.1
[   94.821804] IrCOMM protocol (Dag Brattli)
[   94.971210] PM: Adding info for No Bus:ircomm0
[  118.771468] PM: Adding info for No Bus:ircomm1
[  118.806250] PM: Adding info for No Bus:ircomm2
[  118.807503] PM: Adding info for No Bus:ircomm3
[  118.808667] PM: Adding info for No Bus:ircomm4
[  118.809714] PM: Adding info for No Bus:ircomm5
[  118.810773] PM: Adding info for No Bus:ircomm6
[  118.811908] PM: Adding info for No Bus:ircomm7
[  118.812755] PM: Adding info for No Bus:ircomm8
[  118.813158] PM: Adding info for No Bus:ircomm9
[  118.813566] PM: Adding info for No Bus:ircomm10
[  118.813952] PM: Adding info for No Bus:ircomm11
[  118.814330] PM: Adding info for No Bus:ircomm12
[  118.814732] PM: Adding info for No Bus:ircomm13
[  118.815110] PM: Adding info for No Bus:ircomm14
[  118.815576] PM: Adding info for No Bus:ircomm15
[  118.815983] PM: Adding info for No Bus:ircomm16
[  118.816365] PM: Adding info for No Bus:ircomm17
[  118.816742] PM: Adding info for No Bus:ircomm18
[  118.817152] PM: Adding info for No Bus:ircomm19
[  118.817531] PM: Adding info for No Bus:ircomm20
[  118.817916] PM: Adding info for No Bus:ircomm21
[  118.818384] PM: Adding info for No Bus:ircomm22
[  118.818772] PM: Adding info for No Bus:ircomm23
[  118.819154] PM: Adding info for No Bus:ircomm24
[  118.819578] PM: Adding info for No Bus:ircomm25
[  118.819963] PM: Adding info for No Bus:ircomm26
[  118.820351] PM: Adding info for No Bus:ircomm27
[  118.820766] PM: Adding info for No Bus:ircomm28
[  118.821158] PM: Adding info for No Bus:ircomm29
[  118.821545] PM: Adding info for No Bus:ircomm30
[  118.821961] PM: Adding info for No Bus:ircomm31
[  119.961500] PPP generic driver version 2.4.2
[  119.961812] PM: Adding info for No Bus:ppp
[  120.114758] PM: Adding info for No Bus:irnet
[  120.397247] PM: Adding info for No Bus:irda1
[  120.398141] IrDA: Registered device irda1 (irport io=0x3E8 irq=3)
[  123.513058] tun: Universal TUN/TAP device driver, 1.6
[  123.513303] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[  123.513505] PM: Adding info for No Bus:tun
[   86.581310] eth0: link down
[   86.581521] ADDRCONF(NETDEV_UP): eth0: link is not ready
[  148.171216] PM: Adding info for No Bus:vcs1
[  148.171292] PM: Adding info for No Bus:vcsa1
[  148.171409] PM: Removing info for No Bus:vcs1
[  148.171482] PM: Removing info for No Bus:vcsa1
[  148.171601] PM: Adding info for No Bus:vcs1
[  148.171652] PM: Adding info for No Bus:vcsa1
[  148.231785] PM: Adding info for No Bus:vcs2
[  148.232003] PM: Adding info for No Bus:vcsa2
[  148.232204] PM: Removing info for No Bus:vcs2
[  148.232369] PM: Removing info for No Bus:vcsa2
[  148.232753] PM: Adding info for No Bus:vcs2
[  148.232896] PM: Adding info for No Bus:vcsa2
[  148.235379] PM: Adding info for No Bus:vcs3
[  148.235559] PM: Adding info for No Bus:vcsa3
[  148.235776] PM: Removing info for No Bus:vcs3
[  148.235936] PM: Removing info for No Bus:vcsa3
[  148.236147] PM: Adding info for No Bus:vcs3
[  148.236287] PM: Adding info for No Bus:vcsa3
[  148.263994] PM: Adding info for No Bus:vcs4
[  148.264245] PM: Adding info for No Bus:vcsa4
[  148.264832] PM: Removing info for No Bus:vcs4
[  148.264998] PM: Removing info for No Bus:vcsa4
[  148.267191] PM: Adding info for No Bus:vcs5
[  148.267367] PM: Adding info for No Bus:vcsa5
[  148.267556] PM: Removing info for No Bus:vcs5
[  148.267711] PM: Removing info for No Bus:vcsa5
[  148.267920] PM: Adding info for No Bus:vcs5
[  148.268059] PM: Adding info for No Bus:vcsa5
[  148.270719] PM: Adding info for No Bus:vcs6
[  148.270896] PM: Adding info for No Bus:vcsa6
[  148.271110] PM: Removing info for No Bus:vcs6
[  148.271266] PM: Removing info for No Bus:vcsa6
[  148.271474] PM: Adding info for No Bus:vcs6
[  148.271614] PM: Adding info for No Bus:vcsa6
[  148.280530] PM: Adding info for No Bus:vcs4
[  148.280901] PM: Adding info for No Bus:vcsa4
[  119.929036] mtrr: no MTRR for 98000000,4000000 found
[  120.515772] PM: Adding info for No Bus:vcs7
[  120.516152] PM: Adding info for No Bus:vcsa7
[  101.915202] agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
[  101.915228] agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
[  101.915284] agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode
[  102.236240] [drm] Setting GART location based on new memory map
[  102.236253] [drm] Loading R200 Microcode
[  102.236346] [drm] writeback test succeeded in 2 usecs
[  157.770700] ieee80211_crypt: registered algorithm 'WEP'
[  158.285463] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  151.274779] eth1: no IPv6 routers present

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Thomas Gleixner]

On Thu, 2007-02-22 at 16:13 +0100, Pierre Ossman wrote:
> > Sure. My dmesg is full of mmc debug crud right now, but I'll just reboot
> > and I'll have a clean one for you.
> > 
> 
> Here we go.

> [   44.498253] ACPI: Lid Switch [C136]
> [   44.577672] No dock devices found.
> [   44.714156] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])

---------------------------------------------------------^^^^^

Here is the reason. The local APIC stops working in C3 state and we fall
back to the PIT in that case. Not really exciting for dynticks, but the
only way to keep the system alive. There is a patch coming up from
Intel, which finds out how to use HPET even if it is not enabled by the
BIOS. This will still end up on IRQ#0, but will give way longer idle
sleeps than the PIT.

	tglx

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Pierre Ossman]

Thomas Gleixner wrote:
>
> Here is the reason. The local APIC stops working in C3 state and we fall
> back to the PIT in that case. Not really exciting for dynticks, but the
> only way to keep the system alive. There is a patch coming up from
> Intel, which finds out how to use HPET even if it is not enabled by the
> BIOS. This will still end up on IRQ#0, but will give way longer idle
> sleeps than the PIT.
>
>   

So then the next two questions are; is it possible to disable C3 and is
it a net power gain to get rid of the wakeups in favor of having C3.

Rgds

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Arjan van de Ven]

On Thu, 2007-02-22 at 17:27 +0100, Pierre Ossman wrote:
> Thomas Gleixner wrote:
> >
> > Here is the reason. The local APIC stops working in C3 state and we fall
> > back to the PIT in that case. Not really exciting for dynticks, but the
> > only way to keep the system alive. There is a patch coming up from
> > Intel, which finds out how to use HPET even if it is not enabled by the
> > BIOS. This will still end up on IRQ#0, but will give way longer idle
> > sleeps than the PIT.
> >
> >   
> 
> So then the next two questions are; is it possible to disable C3 

yeah there is a commandline thingy for it
> and is
> it a net power gain to get rid of the wakeups in favor of having C3.

no; c3 saves a TON more power. 

you can try enabling HPET in your BIOS...

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Pierre Ossman]

Arjan van de Ven wrote:
> no; c3 saves a TON more power. 
>
> you can try enabling HPET in your BIOS...
>
>   

Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken
as is humanly possible.

Can I determine if I have the required hardware? So I can tell if I'm
permanently screwed, or just temporarily.

Rgds

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Andreas Mohr]

Hi,

On Thu, Feb 22, 2007 at 10:07:19PM +0100, Pierre Ossman wrote:
> Arjan van de Ven wrote:
> > no; c3 saves a TON more power. 
> >
> > you can try enabling HPET in your BIOS...
> >
> >   
> 
> Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken
> as is humanly possible.
> 
> Can I determine if I have the required hardware? So I can tell if I'm
> permanently screwed, or just temporarily.

http://lkml.org/lkml/2006/11/14/153

and related posts in this older thread
("CONFIG_NO_HZ: missed ticks, stall (keyb IRQ required) [2.6.18-rc4-mm1]")
should help.

Andreas Mohr

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Arjan van de Ven]

On Thu, 2007-02-22 at 22:07 +0100, Pierre Ossman wrote:
> Arjan van de Ven wrote:
> > no; c3 saves a TON more power. 
> >
> > you can try enabling HPET in your BIOS...
> >
> >   
> 
> Hah, I wish! This is a laptop, so the BIOS is as brain dead and broken
> as is humanly possible.
> 
> Can I determine if I have the required hardware? So I can tell if I'm
> permanently screwed, or just temporarily.

if it's something built in the last year or two you have the hw.

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Pierre Ossman]

Arjan van de Ven wrote:
> if it's something built in the last year or two you have the hw.
>
>   

I have an ICH4-M, and from Intel's datasheets it looks like I got the
short straw..

-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org

RE: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org 
>[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of 
>Thomas Gleixner
>Sent: Thursday, February 22, 2007 8:00 AM
>To: Pierre Ossman
>Cc: Arjan van de Ven; Jan Engelhardt; Luca Tettamanti; 
>linux-kernel@vger.kernel.org
>Subject: Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]
>
>On Thu, 2007-02-22 at 16:13 +0100, Pierre Ossman wrote:
>> > Sure. My dmesg is full of mmc debug crud right now, but 
>I'll just reboot
>> > and I'll have a clean one for you.
>> > 
>> 
>> Here we go.
>
>> [   44.498253] ACPI: Lid Switch [C136]
>> [   44.577672] No dock devices found.
>> [   44.714156] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
>
>---------------------------------------------------------^^^^^
>
>Here is the reason. The local APIC stops working in C3 state 
>and we fall
>back to the PIT in that case. Not really exciting for dynticks, but the
>only way to keep the system alive. There is a patch coming up from
>Intel, which finds out how to use HPET even if it is not enabled by the
>BIOS. This will still end up on IRQ#0, but will give way longer idle
>sleeps than the PIT.
>
>	tglx
>
>

Thomas,

I have the patchset for this HPET part ready to roll out. But, looks
like 
NO_HZ and lapic eventsource support is only in i386 and not in x86-64 in
2.6.21-rc1.
Do you know the state of NO_HZ x86-64 support?

Will it get into git soon? In which case I can rebase my patches against
git
and send it out for review/testing.

Otherwise, I will send out my patches, which are against rt (and my
initial
implementation of this HPET part is only for x86-64).

Thanks,
Venki

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Thomas Gleixner]

On Thu, 2007-02-22 at 13:36 +0100, Jan Engelhardt wrote:
> >
> >Yes, we switch away from PIT and use the local APIC timer. (LOC)
> 
> What's the benefit of doing so - and why has not it been done before?
> I mean, I run a regular 2.6.18.6,
> /sys/devices/system/clocksource/clocksource0/current_clocksource (is this
> related?) shows "acpi_pm", but the IRQ0 counter increases at HZ. Maybe I
> am confusing things, but why the need for PIT when clocksource is acpi_pm
> anyway?

acpi_pm is only a readout device to keep track of current time.

PIT and local APIC timer are used to provide either periodic or one shot
programmable timer events.

Up to now the kernel started PIT and local APIC timer in parallel with
the same period where PIT incremented jiffies and local APIC timer
called update_process_times() and profile_tick. We changed this to let
the boot cpu increment jiffies inside the local apic timer interrupt
after PIT has been stopped. A whole interrupt for jiffies64++ is waste.

Also when we switch to nohz / high resolution mode, we want to use the
local APIC, as it is much faster to access. The maximum delta to program
is 27ms for the pit and ~1sec for the local APIC. This is important for
dynticks, as we can achieve longer idle sleeps w/o reprogramming the
timer.

	tglx

Re: NO_HZ: timer interrupt stuck

[David Miller]

From: Thomas Gleixner <tglx@linutronix.de>
Date: Thu, 22 Feb 2007 16:51:41 +0100

> PIT and local APIC timer are used to provide either periodic or one shot
> programmable timer events.
> 
> Up to now the kernel started PIT and local APIC timer in parallel with
> the same period where PIT incremented jiffies and local APIC timer
> called update_process_times() and profile_tick. We changed this to let
> the boot cpu increment jiffies inside the local apic timer interrupt
> after PIT has been stopped. A whole interrupt for jiffies64++ is waste.

BTW, I'm adding support for sparc64, and before I get much further
will the code handle a oneshot-only device?  That's basically what I
have (sparc64 basically has a TSC and a "comparison" register, you
write the "comparison" register with the TSC value at which you'd like
the timer interrupt to occur, so it's one-shot and you have to write
it again to get the next timer).

I see logic in the generic code to do periodic events when the
timer only provides one-shot ticks.  But as far as I can tell
both the HPET and the local APIC support periodic timers so
I can't tell how much testing that code has gotten :-)

I, in fact, don't see any clockevent device in the current tree that
does not set CLOCK_EVT_FEAT_PERIODIC.

I guess you could clear that bit just to test those generic code
paths. :-)

BTW, sparc64 always did the trick where the do_timer() work was done
by one of the per-cpu local timer interrupts, I'm glad the idea gained
traction generically. :-)))

Re: NO_HZ: timer interrupt stuck

[Thomas Gleixner]

On Thu, 2007-02-22 at 09:26 -0800, David Miller wrote:
> BTW, I'm adding support for sparc64, and before I get much further
> will the code handle a oneshot-only device?  That's basically what I
> have (sparc64 basically has a TSC and a "comparison" register, you
> write the "comparison" register with the TSC value at which you'd like
> the timer interrupt to occur, so it's one-shot and you have to write
> it again to get the next timer).

Yes, all you need is to omit the CLOCK_EVT_FEAT_PERIODIC flag when you
register your device.

> I see logic in the generic code to do periodic events when the
> timer only provides one-shot ticks.  But as far as I can tell
> both the HPET and the local APIC support periodic timers so
> I can't tell how much testing that code has gotten :-)

Not much :)

> I, in fact, don't see any clockevent device in the current tree that
> does not set CLOCK_EVT_FEAT_PERIODIC.

There is an ARM patch which makes use of it.

> I guess you could clear that bit just to test those generic code
> paths. :-)

yep.

> BTW, sparc64 always did the trick where the do_timer() work was done
> by one of the per-cpu local timer interrupts, I'm glad the idea gained
> traction generically. :-)))

:)

	tglx

Re: NO_HZ: timer interrupt stuck

[David Miller]

From: Thomas Gleixner <tglx@linutronix.de>
Date: Thu, 22 Feb 2007 18:39:19 +0100

> On Thu, 2007-02-22 at 09:26 -0800, David Miller wrote:
> > BTW, I'm adding support for sparc64, and before I get much further
> > will the code handle a oneshot-only device?  That's basically what I
> > have (sparc64 basically has a TSC and a "comparison" register, you
> > write the "comparison" register with the TSC value at which you'd like
> > the timer interrupt to occur, so it's one-shot and you have to write
> > it again to get the next timer).
> 
> Yes, all you need is to omit the CLOCK_EVT_FEAT_PERIODIC flag when you
> register your device.

Thanks a lot Thomas.

I noticed while doing this work that the generic clock code is
incompatible with the time interpolator, since both provide a
do_{get,set}timeofday() implementation.  Just FYI...

sparc generic time / clockevents [ was Re: NO_HZ: timer interrupt stuck ]

[Thomas Gleixner]

David,

<trimmed CC due to sparcness, added John instaed >

On Fri, 2007-02-23 at 01:25 -0800, David Miller wrote:
> > Yes, all you need is to omit the CLOCK_EVT_FEAT_PERIODIC flag when you
> > register your device.
> 
> Thanks a lot Thomas.
> 
> I noticed while doing this work that the generic clock code is
> incompatible with the time interpolator, since both provide a
> do_{get,set}timeofday() implementation.  Just FYI...

John, can you have a look at this ?

	tglx

Re: sparc generic time / clockevents

[David Miller]

From: Thomas Gleixner <tglx@linutronix.de>
Date: Fri, 23 Feb 2007 10:56:18 +0100

> On Fri, 2007-02-23 at 01:25 -0800, David Miller wrote:
> > > Yes, all you need is to omit the CLOCK_EVT_FEAT_PERIODIC flag when you
> > > register your device.
> > 
> > Thanks a lot Thomas.
> > 
> > I noticed while doing this work that the generic clock code is
> > incompatible with the time interpolator, since both provide a
> > do_{get,set}timeofday() implementation.  Just FYI...
> 
> John, can you have a look at this ?

Note we may not care :-)  All the interpolator does is provide
a generic tick based gettimeofday implementation, and the generic
clock code does essentially the same thing.

And the generic clock code must in fact provide the implementations
in order to deal with dyntick issues.

The only other platform using the time interpolator is IA64,
and after my dyntick implementation on sparc64 the one and
only user will be IA64 :-)

Re: sparc generic time / clockevents

[john stultz]

On Fri, 2007-02-23 at 01:55 -0800, David Miller wrote:
> From: Thomas Gleixner <tglx@linutronix.de>
> Date: Fri, 23 Feb 2007 10:56:18 +0100
> 
> > On Fri, 2007-02-23 at 01:25 -0800, David Miller wrote:
> > > > Yes, all you need is to omit the CLOCK_EVT_FEAT_PERIODIC flag when you
> > > > register your device.
> > > 
> > > Thanks a lot Thomas.
> > > 
> > > I noticed while doing this work that the generic clock code is
> > > incompatible with the time interpolator, since both provide a
> > > do_{get,set}timeofday() implementation.  Just FYI...
> > 
> > John, can you have a look at this ?
> 
> Note we may not care :-)  All the interpolator does is provide
> a generic tick based gettimeofday implementation, and the generic
> clock code does essentially the same thing.
> 
> And the generic clock code must in fact provide the implementations
> in order to deal with dyntick issues.
> 
> The only other platform using the time interpolator is IA64,
> and after my dyntick implementation on sparc64 the one and
> only user will be IA64 :-)

Yea. I actually have some in-progress patches from Peter Keilty that
convert ia64 and sparc64 time_interpolators to clocksources, then
removes the time_interpolator code.

The ia64 conversion is more complicated due to the fsyscall asm, but I
think the sparc64 conversion (below) is pretty straight forward. I've
only built tested this, so I have no clue if it actually works. 

Any thoughts?

thanks
-john


From: Peter Keilty <peter.keilty@hp.com>

Initial sparc64 conversion to generic clocksource/timekeeping code.

Signed-off-by: Peter Keilty <peter.keilty@hp.com>
Signed-off-by: John Stultz <johnstul@us.ibm.com>


 Kconfig       |    2 +-
 defconfig     |    2 +-
 kernel/time.c |   34 +++++++++++++++++++++++-----------
 3 files changed, 25 insertions(+), 13 deletions(-)

linux-2.6.21-rc1_timeofday-arch-sparc64_C7.patch
============================================
diff --git a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig
index f75a686..13a4547 100644
--- a/arch/sparc64/Kconfig
+++ b/arch/sparc64/Kconfig
@@ -34,7 +34,7 @@ config LOCKDEP_SUPPORT
 	bool
 	default y
 
-config TIME_INTERPOLATION
+config GENERIC_TIME
 	bool
 	default y
 
diff --git a/arch/sparc64/defconfig b/arch/sparc64/defconfig
index 0f44a6a..33e061a 100644
--- a/arch/sparc64/defconfig
+++ b/arch/sparc64/defconfig
@@ -9,7 +9,7 @@ CONFIG_64BIT=y
 CONFIG_MMU=y
 CONFIG_STACKTRACE_SUPPORT=y
 CONFIG_LOCKDEP_SUPPORT=y
-CONFIG_TIME_INTERPOLATION=y
+CONFIG_GENERIC_TIME=y
 CONFIG_ARCH_MAY_HAVE_PC_FDC=y
 # CONFIG_ARCH_HAS_ILOG2_U32 is not set
 # CONFIG_ARCH_HAS_ILOG2_U64 is not set
diff --git a/arch/sparc64/kernel/time.c b/arch/sparc64/kernel/time.c
index f84da4f..497b29b 100644
--- a/arch/sparc64/kernel/time.c
+++ b/arch/sparc64/kernel/time.c
@@ -31,6 +31,7 @@ #include <linux/percpu.h>
 #include <linux/profile.h>
 #include <linux/miscdevice.h>
 #include <linux/rtc.h>
+#include <linux/clocksource.h>
 
 #include <asm/oplib.h>
 #include <asm/mostek.h>
@@ -620,7 +621,7 @@ #endif
 	if (!mregs && !dregs) {
 		prom_printf("Something wrong, clock regs not mapped yet.\n");
 		prom_halt();
-	}		
+	}
 
 	if (mregs) {
 		spin_lock_irq(&mostek_lock);
@@ -820,7 +821,7 @@ #endif
 	}
 
 	set_system_time();
-	
+
 	local_irq_restore(flags);
 
 	return 0;
@@ -975,22 +976,33 @@ static struct notifier_block sparc64_cpu
 
 #endif /* CONFIG_CPU_FREQ */
 
-static struct time_interpolator sparc64_cpu_interpolator = {
-	.source		=	TIME_SOURCE_CPU,
-	.shift		=	16,
-	.mask		=	0xffffffffffffffffLL
+static cycle_t read_sparc64_cpuclock(void)
+{
+        return (cycle_t)get_cycles();
+}
+
+static struct clocksource clocksource_sparc64_cpuclock = {
+	.name           = "sparc64_cpuclock",
+	.rating         = 300,
+	.read           = read_sparc64_cpuclock,
+	.mask           = 0xffffffffffffffffLL,
+	.mult           = 0, /*to be caluclated*/
+	.shift          = 16,
+	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
+
 /* The quotient formula is taken from the IA64 port. */
 #define SPARC64_NSEC_PER_CYC_SHIFT	10UL
 void __init time_init(void)
 {
 	unsigned long clock = sparc64_init_timers();
 
-	sparc64_cpu_interpolator.frequency = clock;
-	register_time_interpolator(&sparc64_cpu_interpolator);
+	clocksource_sparc64_cpuclock.mult = clocksource_hz2mult(clock,
+					clocksource_sparc64_cpuclock.shift);
+	clocksource_register(&clocksource_sparc64_cpuclock);
 
-	/* Now that the interpolator is registered, it is
+	/* Now that the clocksource is registered, it is
 	 * safe to start the timer ticking.
 	 */
 	sparc64_start_timers();
@@ -1025,11 +1037,11 @@ #endif
 	unsigned long flags;
 	u8 tmp;
 
-	/* 
+	/*
 	 * Not having a register set can lead to trouble.
 	 * Also starfire doesn't have a tod clock.
 	 */
-	if (!mregs && !dregs) 
+	if (!mregs && !dregs)
 		return -1;
 
 	if (mregs) {

Re: sparc generic time / clockevents

[Peter Keilty]

john stultz wrote:

>On Fri, 2007-02-23 at 01:55 -0800, David Miller wrote:
>  
>
>>From: Thomas Gleixner <tglx@linutronix.de>
>>Date: Fri, 23 Feb 2007 10:56:18 +0100
>>
>>    
>>
>>>On Fri, 2007-02-23 at 01:25 -0800, David Miller wrote:
>>>      
>>>
>>>>>Yes, all you need is to omit the CLOCK_EVT_FEAT_PERIODIC flag when you
>>>>>register your device.
>>>>>          
>>>>>
>>>>Thanks a lot Thomas.
>>>>
>>>>I noticed while doing this work that the generic clock code is
>>>>incompatible with the time interpolator, since both provide a
>>>>do_{get,set}timeofday() implementation.  Just FYI...
>>>>        
>>>>
>>>John, can you have a look at this ?
>>>      
>>>
>>Note we may not care :-)  All the interpolator does is provide
>>a generic tick based gettimeofday implementation, and the generic
>>clock code does essentially the same thing.
>>
>>And the generic clock code must in fact provide the implementations
>>in order to deal with dyntick issues.
>>
>>The only other platform using the time interpolator is IA64,
>>and after my dyntick implementation on sparc64 the one and
>>only user will be IA64 :-)
>>    
>>
>
>Yea. I actually have some in-progress patches from Peter Keilty that
>convert ia64 and sparc64 time_interpolators to clocksources, then
>removes the time_interpolator code.
>
>The ia64 conversion is more complicated due to the fsyscall asm, but I
>think the sparc64 conversion (below) is pretty straight forward. I've
>only built tested this, so I have no clue if it actually works. 
>
>Any thoughts?
>  
>
I have only build tested also, I thought it was pretty straight forward.

>thanks
>-john
>
>
>From: Peter Keilty <peter.keilty@hp.com>
>
>Initial sparc64 conversion to generic clocksource/timekeeping code.
>
>Signed-off-by: Peter Keilty <peter.keilty@hp.com>
>Signed-off-by: John Stultz <johnstul@us.ibm.com>
>
>
> Kconfig       |    2 +-
> defconfig     |    2 +-
> kernel/time.c |   34 +++++++++++++++++++++++-----------
> 3 files changed, 25 insertions(+), 13 deletions(-)
>
>linux-2.6.21-rc1_timeofday-arch-sparc64_C7.patch
>============================================
>diff --git a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig
>index f75a686..13a4547 100644
>--- a/arch/sparc64/Kconfig
>+++ b/arch/sparc64/Kconfig
>@@ -34,7 +34,7 @@ config LOCKDEP_SUPPORT
> 	bool
> 	default y
> 
>-config TIME_INTERPOLATION
>+config GENERIC_TIME
> 	bool
> 	default y
> 
>diff --git a/arch/sparc64/defconfig b/arch/sparc64/defconfig
>index 0f44a6a..33e061a 100644
>--- a/arch/sparc64/defconfig
>+++ b/arch/sparc64/defconfig
>@@ -9,7 +9,7 @@ CONFIG_64BIT=y
> CONFIG_MMU=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_LOCKDEP_SUPPORT=y
>-CONFIG_TIME_INTERPOLATION=y
>+CONFIG_GENERIC_TIME=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> # CONFIG_ARCH_HAS_ILOG2_U32 is not set
> # CONFIG_ARCH_HAS_ILOG2_U64 is not set
>diff --git a/arch/sparc64/kernel/time.c b/arch/sparc64/kernel/time.c
>index f84da4f..497b29b 100644
>--- a/arch/sparc64/kernel/time.c
>+++ b/arch/sparc64/kernel/time.c
>@@ -31,6 +31,7 @@ #include <linux/percpu.h>
> #include <linux/profile.h>
> #include <linux/miscdevice.h>
> #include <linux/rtc.h>
>+#include <linux/clocksource.h>
> 
> #include <asm/oplib.h>
> #include <asm/mostek.h>
>@@ -620,7 +621,7 @@ #endif
> 	if (!mregs && !dregs) {
> 		prom_printf("Something wrong, clock regs not mapped yet.\n");
> 		prom_halt();
>-	}		
>+	}
> 
> 	if (mregs) {
> 		spin_lock_irq(&mostek_lock);
>@@ -820,7 +821,7 @@ #endif
> 	}
> 
> 	set_system_time();
>-	
>+
> 	local_irq_restore(flags);
> 
> 	return 0;
>@@ -975,22 +976,33 @@ static struct notifier_block sparc64_cpu
> 
> #endif /* CONFIG_CPU_FREQ */
> 
>-static struct time_interpolator sparc64_cpu_interpolator = {
>-	.source		=	TIME_SOURCE_CPU,
>-	.shift		=	16,
>-	.mask		=	0xffffffffffffffffLL
>+static cycle_t read_sparc64_cpuclock(void)
>+{
>+        return (cycle_t)get_cycles();
>+}
>+
>+static struct clocksource clocksource_sparc64_cpuclock = {
>+	.name           = "sparc64_cpuclock",
>+	.rating         = 300,
>+	.read           = read_sparc64_cpuclock,
>+	.mask           = 0xffffffffffffffffLL,
>+	.mult           = 0, /*to be caluclated*/
>+	.shift          = 16,
>+	.flags		= CLOCK_SOURCE_IS_CONTINUOUS,
> };
> 
>+
> /* The quotient formula is taken from the IA64 port. */
> #define SPARC64_NSEC_PER_CYC_SHIFT	10UL
> void __init time_init(void)
> {
> 	unsigned long clock = sparc64_init_timers();
> 
>-	sparc64_cpu_interpolator.frequency = clock;
>-	register_time_interpolator(&sparc64_cpu_interpolator);
>+	clocksource_sparc64_cpuclock.mult = clocksource_hz2mult(clock,
>+					clocksource_sparc64_cpuclock.shift);
>+	clocksource_register(&clocksource_sparc64_cpuclock);
> 
>-	/* Now that the interpolator is registered, it is
>+	/* Now that the clocksource is registered, it is
> 	 * safe to start the timer ticking.
> 	 */
> 	sparc64_start_timers();
>@@ -1025,11 +1037,11 @@ #endif
> 	unsigned long flags;
> 	u8 tmp;
> 
>-	/* 
>+	/*
> 	 * Not having a register set can lead to trouble.
> 	 * Also starfire doesn't have a tod clock.
> 	 */
>-	if (!mregs && !dregs) 
>+	if (!mregs && !dregs)
> 		return -1;
> 
> 	if (mregs) {
>
>
>  
>

Re: sparc generic time / clockevents

[David Miller]

From: john stultz <johnstul@us.ibm.com>
Date: Fri, 23 Feb 2007 11:51:18 -0800

> Yea. I actually have some in-progress patches from Peter Keilty that
> convert ia64 and sparc64 time_interpolators to clocksources, then
> removes the time_interpolator code.
> 
> The ia64 conversion is more complicated due to the fsyscall asm, but I
> think the sparc64 conversion (below) is pretty straight forward. I've
> only built tested this, so I have no clue if it actually works. 
> 
> Any thoughts?

Hey John, I had to do this already in order to do the dynticks
port to sparc64, but nice to see another attempt :-)

Two things I did on my side:

+	.mask           = 0xffffffffffffffffLL,

I used CLOCKSOURCE_MASK(64) here.

+static cycle_t read_sparc64_cpuclock(void)
+{
+        return (cycle_t)get_cycles();
+}
 ...
+	.read           = read_sparc64_cpuclock,

You can just directly assign tick_ops->get_tick to .read at run-time
to avoid a stack frame and function call/return.

+	.shift          = 16,

These shift selections all seem rather arbitrary.

If it's not an arbitrary selection, it would be nice to have some
comments about how to go about choosing an appropriate shift.
I imagine the selections has to do with the possible range of
the frequencies the clocksource supports, and how much
accuracy you get for certain shift selections given that range.

Re: sparc generic time / clockevents

[john stultz]

On Fri, 2007-02-23 at 16:34 -0800, David Miller wrote:
> From: john stultz <johnstul@us.ibm.com>
> Date: Fri, 23 Feb 2007 11:51:18 -0800
> 
> > Yea. I actually have some in-progress patches from Peter Keilty that
> > convert ia64 and sparc64 time_interpolators to clocksources, then
> > removes the time_interpolator code.
> > 
> > The ia64 conversion is more complicated due to the fsyscall asm, but I
> > think the sparc64 conversion (below) is pretty straight forward. I've
> > only built tested this, so I have no clue if it actually works. 
> > 
> > Any thoughts?
> 
> Hey John, I had to do this already in order to do the dynticks
> port to sparc64, but nice to see another attempt :-)

Oh! Well, sorry for not sending it out earlier, then!

> Two things I did on my side:
> 
> +	.mask           = 0xffffffffffffffffLL,
> 
> I used CLOCKSOURCE_MASK(64) here.

Yep. That's better.

> +static cycle_t read_sparc64_cpuclock(void)
> +{
> +        return (cycle_t)get_cycles();
> +}
>  ...
> +	.read           = read_sparc64_cpuclock,
> 
> You can just directly assign tick_ops->get_tick to .read at run-time
> to avoid a stack frame and function call/return.

Cool.

> +	.shift          = 16,
> 
> These shift selections all seem rather arbitrary.
> 
> If it's not an arbitrary selection, it would be nice to have some
> comments about how to go about choosing an appropriate shift.
> I imagine the selections has to do with the possible range of
> the frequencies the clocksource supports, and how much
> accuracy you get for certain shift selections given that range.

Correct. The higher the shift value, the more precise NTP multiplier
adjustment we can make.  However, too large w/ a high frequency
clocksource and you'll risk overflowing 64bits on the mult.

Although that's not super critical anymore since Roman implemented the
high-res error accounting, the net effect should be the same over the
long term(we just have to work harder w/ courser adjustments - resulting
in very small clock frequency oscillations).

I do need to get some documentation going. I had some back when I first
started pushing the changes, but so much was revised and rewritten it
stopped being correct.

-john

Re: sparc generic time / clockevents

[David Miller]

From: john stultz <johnstul@us.ibm.com>
Date: Fri, 23 Feb 2007 16:53:27 -0800

> On Fri, 2007-02-23 at 16:34 -0800, David Miller wrote:
> > +	.shift          = 16,
> > 
> > These shift selections all seem rather arbitrary.
> > 
> > If it's not an arbitrary selection, it would be nice to have some
> > comments about how to go about choosing an appropriate shift.
> > I imagine the selections has to do with the possible range of
> > the frequencies the clocksource supports, and how much
> > accuracy you get for certain shift selections given that range.
> 
> Correct. The higher the shift value, the more precise NTP multiplier
> adjustment we can make.  However, too large w/ a high frequency
> clocksource and you'll risk overflowing 64bits on the mult.
> 
> Although that's not super critical anymore since Roman implemented the
> high-res error accounting, the net effect should be the same over the
> long term(we just have to work harder w/ courser adjustments - resulting
> in very small clock frequency oscillations).

While we were discussing this I was debugging my clocksource sparc64
implementation, a shift of 32 didn't work whereas one of 16 (as
in your version of sparc64 support) did. :-)

There is also a very unfortunate inconsistency between how the shift
and multiplier are used in clock sources vs. clock events.

You can initialize your clocksource multiplier using:

	mult = clocksource_hz2mult(ticks_per_hz, SHIFT);

but WOE BE TO HE who tries to use that for clockevents (like I
did initially) :-)  You have to instead use something like:

	mult = div_sc(ticks_per_hz, NSEC_PER_SEC, SHIFT);

I would have been done with the sparc64 dynticks support yesterday if
I didn't trip over all this stuff.

It also isn't clear from the comments that the first argument
to clocksource_hz2mult() and div_sc() is indeed "ticks_per_hz".
I had to gleen over the hpet and LAPIC drivers to kind of figure
this out.  Another potential improvement for the comments :-)

generic one-shot bug (was Re: sparc generic time / clockevents)

[David Miller]

As I suspected, the one-shot code wasn't very well tested and I'd be
the one to debug this thing on sparc64 :-)

When a timer exceeds the timer period, the one-shot handling code does
the following loop:

	for (;;) {
		ktime_t next = ktime_add(dev->next_event, tick_period);

		if (!clockevents_program_event(dev, next, ktime_get()))
			return;
		tick_periodic(cpu);
	}

So it just keeps running tick_periodic() until we "catch up".

Problem is, if clockevents_program_event() gets a "next" time in the
past, the very case where we'll loop, it DOES NOT update
dev->next_event.  It returns the error before doing so.

As a result of this, we'll loop forever here, the softlockup watchdog
will trigger, and the system will wedge completely.

I was getting a softlockup and immediate system hang, so to debug this
I kept a history of the last 8 TSC values when tick_periodic() was
invoked.  At softlockup trigger, I'd dump the log.  And what I saw
were TSC deltas that we so tiny as to be just enough to indicate
tick_periodic() was running in a tight loop :-)

I propose the following fix, which I'm about to test.

Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 4500e34..0986a2b 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -77,6 +77,7 @@ static void tick_periodic(int cpu)
 void tick_handle_periodic(struct clock_event_device *dev)
 {
 	int cpu = smp_processor_id();
+	ktime_t next;
 
 	tick_periodic(cpu);
 
@@ -86,12 +87,12 @@ void tick_handle_periodic(struct clock_event_device *dev)
 	 * Setup the next period for devices, which do not have
 	 * periodic mode:
 	 */
+	next = ktime_add(dev->next_event, tick_period);
 	for (;;) {
-		ktime_t next = ktime_add(dev->next_event, tick_period);
-
 		if (!clockevents_program_event(dev, next, ktime_get()))
 			return;
 		tick_periodic(cpu);
+		next = ktime_add(next, tick_period);
 	}
 }
 

Re: generic one-shot bug (was Re: sparc generic time / clockevents)

[Thomas Gleixner]

On Sat, 2007-02-24 at 21:13 -0800, David Miller wrote:
> As I suspected, the one-shot code wasn't very well tested and I'd be
> the one to debug this thing on sparc64 :-)
> 
> When a timer exceeds the timer period, the one-shot handling code does
> the following loop:
> 
> 	for (;;) {
> 		ktime_t next = ktime_add(dev->next_event, tick_period);
> 
> 		if (!clockevents_program_event(dev, next, ktime_get()))
> 			return;
> 		tick_periodic(cpu);
> 	}
> 
> So it just keeps running tick_periodic() until we "catch up".
>
> Problem is, if clockevents_program_event() gets a "next" time in the
> past, the very case where we'll loop, it DOES NOT update
> dev->next_event.  It returns the error before doing so.

Yep, that's caused by a late change for the *!&#ed broadcast stuff for
x86.

> As a result of this, we'll loop forever here, the softlockup watchdog
> will trigger, and the system will wedge completely.
> 
> I was getting a softlockup and immediate system hang, so to debug this
> I kept a history of the last 8 TSC values when tick_periodic() was
> invoked.  At softlockup trigger, I'd dump the log.  And what I saw
> were TSC deltas that we so tiny as to be just enough to indicate
> tick_periodic() was running in a tight loop :-)
> 
> I propose the following fix, which I'm about to test.

Yep

> Signed-off-by: David S. Miller <davem@davemloft.net>

Acked-by: Thomas Gleixner <tglx@linutronix.de>

> diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
> index 4500e34..0986a2b 100644
> --- a/kernel/time/tick-common.c
> +++ b/kernel/time/tick-common.c
> @@ -77,6 +77,7 @@ static void tick_periodic(int cpu)
>  void tick_handle_periodic(struct clock_event_device *dev)
>  {
>  	int cpu = smp_processor_id();
> +	ktime_t next;
>  
>  	tick_periodic(cpu);
>  
> @@ -86,12 +87,12 @@ void tick_handle_periodic(struct clock_event_device *dev)
>  	 * Setup the next period for devices, which do not have
>  	 * periodic mode:
>  	 */
> +	next = ktime_add(dev->next_event, tick_period);
>  	for (;;) {
> -		ktime_t next = ktime_add(dev->next_event, tick_period);
> -
>  		if (!clockevents_program_event(dev, next, ktime_get()))
>  			return;
>  		tick_periodic(cpu);
> +		next = ktime_add(next, tick_period);
>  	}
>  }
>  

Re: NO_HZ: timer interrupt stuck

[Andi Kleen]

David Miller <davem@davemloft.net> writes:
> 
> BTW, sparc64 always did the trick where the do_timer() work was done
> by one of the per-cpu local timer interrupts, I'm glad the idea gained
> traction generically. :-)))

It was already implemented before for x86-64, but disabled 
by default because it ran into some platform issues. The new code
hopefully knows now how to work around them.

-Andi

Re: NO_HZ: timer interrupt stuck [Re: Linux 2.6.21-rc1]

[Andi Kleen]

Thomas Gleixner <tglx@linutronix.de> writes:
> > 
> > Interrupt 0 is stuck at 114 (the number is consistent across reboots). I
> > don't experience any problem, time is running fine. Still it's strange
> > that the timer is doing nothing; maybe something other than the PIT is
> > used for time keeping?
> 
> Yes, we switch away from PIT and use the local APIC timer. (LOC)

Before this becomes a FAQ. Would anybody mind if I just renamed "timer"
to "pit" to make this clear? 

-Andi

Re: Linux 2.6.21-rc1 -- suspend

[Pavel Machek]

Hi!


> Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.
> 
> There's a lot of changes, as is usual for an -rc1 thing, but at least so 
> far it would seem that 2.6.20 has been a good base, and I don't think we 
> have anything *really* scary here.

And lot of acpi/suspend changes, which seem to break my machine in
weird and not really reproducible way. I'm looking onto that.

(Yep, that should teach me to test -mm a bit more).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

2.6.21-rc1: known regressions (part 1)

[Adrian Bunk]

This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : resume: slab error in verify_redzone_free(): cache `size-512':
                     memory outside object was overwritten
References : http://lkml.org/lkml/2007/2/24/41
Submitter  : Pavel Machek <pavel@ucw.cz>
Handled-By : Marcel Holtmann <marcel@holtmann.org>
Status     : unknown


Subject    : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Ingo Molnar <mingo@elte.hu>
Status     : unknown


Subject    : HP nx6325 notebook: usb mouse stops working after suspend to ram
References : http://lkml.org/lkml/2007/2/21/413
Submitter  : Arkadiusz Miskiewicz <arekm@maven.pl>
Caused-By  : Konstantin Karasyov <konstantin.a.karasyov@intel.com>
             commit 0a6139027f3986162233adc17285151e78b39cac
Status     : unknown


Subject    : MacBook: AE_NOT_FOUND ACPI messages
References : http://bugzilla.kernel.org/show_bug.cgi?id=8066
Submitter  : Thomas Meyer <thomas.mey@web.de>
Status     : unknown


Subject    : Asus A8N-VM motherboard: boot failure (ACPI related)
References : http://lkml.org/lkml/2007/2/23/132
Submitter  : Andrew <andrew@nelless.net>
Status     : unknown


Subject    : Asus M6Ne notebook: ACPI: First battery is not detected
References : http://bugzilla.kernel.org/show_bug.cgi?id=8080
Submitter  : Janosch Machowinski <jmachowinski@gmx.de>
Status     : unknown


Subject    : Asus M6Ne/M6A notebooks: SATA_ACPI errors during kernel boot
References : http://bugzilla.kernel.org/show_bug.cgi?id=8080
             http://bugzilla.kernel.org/show_bug.cgi?id=8046
Submitter  : Janosch Machowinski <jmachowinski@gmx.de>
             Lukas Hejtmanek <xhejtman@fi.muni.cz>
Status     : unknown


Subject    : ata-piix ACPI errors (40/80 pin cable mix)
References : http://lkml.org/lkml/2007/2/22/159
Submitter  : Meelis Roos <mroos@linux.ee>
Handled-By : Alan Cox <alan@lxorguk.ukuu.org.uk>
Status     : unknown


Subject    : ata_piix: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294
Submitter  : Fabio Comolli <fabio.comolli@gmail.com>
Status     : unknown


Subject    : sata_via failure
References : http://bugzilla.kernel.org/show_bug.cgi?id=8025
Submitter  : Jean-Luc Coulon <jean.luc.coulon@gmail.com>
             Markus Trippelsdorf <markus@trippelsdorf.de>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://www.mail-archive.com/linux-ide@vger.kernel.org/msg03945.html
Status     : patch available


Subject    : BUG: at drivers/pci/pci.c:817 pcim_enable_device() (suspend, ata)
References : http://lkml.org/lkml/2007/2/14/275
             http://lkml.org/lkml/2007/2/22/367
Submitter  : Rafael J. Wysocki <rjw@sisk.pl>
             Lukas Hejtmanek <xhejtman@mail.muni.cz>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://lkml.org/lkml/2007/2/25/102
Status     : patch available

2.6.21-rc1: known regressions (part 1)

[Adrian Bunk]

This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : resume: slab error in verify_redzone_free(): cache `size-512':
                     memory outside object was overwritten
References : http://lkml.org/lkml/2007/2/24/41
Submitter  : Pavel Machek <pavel@ucw.cz>
Handled-By : Marcel Holtmann <marcel@holtmann.org>
Status     : unknown


Subject    : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Ingo Molnar <mingo@elte.hu>
Status     : unknown


Subject    : HP nx6325 notebook: usb mouse stops working after suspend to ram
References : http://lkml.org/lkml/2007/2/21/413
Submitter  : Arkadiusz Miskiewicz <arekm@maven.pl>
Caused-By  : Konstantin Karasyov <konstantin.a.karasyov@intel.com>
             commit 0a6139027f3986162233adc17285151e78b39cac
Status     : unknown


Subject    : MacBook: AE_NOT_FOUND ACPI messages
References : http://bugzilla.kernel.org/show_bug.cgi?id=8066
Submitter  : Thomas Meyer <thomas.mey@web.de>
Status     : unknown


Subject    : Asus A8N-VM motherboard: boot failure (ACPI related)
References : http://lkml.org/lkml/2007/2/23/132
Submitter  : Andrew <andrew@nelless.net>
Status     : unknown


Subject    : Asus M6Ne notebook: ACPI: First battery is not detected
References : http://bugzilla.kernel.org/show_bug.cgi?id=8080
Submitter  : Janosch Machowinski <jmachowinski@gmx.de>
Status     : unknown


Subject    : Asus M6Ne/M6A notebooks: SATA_ACPI errors during kernel boot
References : http://bugzilla.kernel.org/show_bug.cgi?id=8080
             http://bugzilla.kernel.org/show_bug.cgi?id=8046
Submitter  : Janosch Machowinski <jmachowinski@gmx.de>
             Lukas Hejtmanek <xhejtman@fi.muni.cz>
Status     : unknown


Subject    : ata-piix ACPI errors (40/80 pin cable mix)
References : http://lkml.org/lkml/2007/2/22/159
Submitter  : Meelis Roos <mroos@linux.ee>
Handled-By : Alan Cox <alan@lxorguk.ukuu.org.uk>
Status     : unknown


Subject    : ata_piix: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294
Submitter  : Fabio Comolli <fabio.comolli@gmail.com>
Status     : unknown


Subject    : sata_via failure
References : http://bugzilla.kernel.org/show_bug.cgi?id=8025
Submitter  : Jean-Luc Coulon <jean.luc.coulon@gmail.com>
             Markus Trippelsdorf <markus@trippelsdorf.de>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://www.mail-archive.com/linux-ide@vger.kernel.org/msg03945.html
Status     : patch available


Subject    : BUG: at drivers/pci/pci.c:817 pcim_enable_device() (suspend, ata)
References : http://lkml.org/lkml/2007/2/14/275
             http://lkml.org/lkml/2007/2/22/367
Submitter  : Rafael J. Wysocki <rjw@sisk.pl>
             Lukas Hejtmanek <xhejtman@mail.muni.cz>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://lkml.org/lkml/2007/2/25/102
Status     : patch available

regression: forcedeth.c hang

[Ingo Molnar]

* Adrian Bunk <bunk@stusta.de> wrote:

> This email lists some known regressions in 2.6.21-rc1 compared to 
> 2.6.20 that are not yet fixed in Linus' tree.

just found a new one: forcedeth.c broke since v2.6.20. It generates a 
few irqs after ifup and then stops dead (no in/out packets). Undoing all 
of these commits fixes the problem:

 commit 21828163b2b31e0675cb3e66a2a4a231dec06236
 commit 57fff6986b6daae13947c565786757c05303f0f6
 commit 4e16ed1b0e17a3832310031e2ddaeb0914eb837d
 commit f0734ab658390380079369f7090dcf7aa226f394
 commit b01867cbd1853995946c8c838eff93a0885d8bc6
 commit 445583b89d71b48cf8c64e26acc5a710248feed7
 commit aaa37d2d099f97ced415546e285ac901e47a2437
 commit 86b22b0dfbf462e6ed75e54fc83575dae01e3c69
 commit 0d63fb32b2b8c3464d9c1afc3ce3fd3ceec025b6
 commit 164a86e40e6c74ec5a91c364ccf7b1a2295b0a52
 commit 761fcd9e3e0aa2a02231d1631f31409be5e890d2
 commit d2f7841277d8613a780ab28d04d8f31a31816153
 commit 1d39ed565cfcc7c4fe586de621aef495c4f94ffb

that's 75K of delta - i'll bisect it some more. Hardware in question:

 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)

config options:

 CONFIG_FORCEDETH=y
 CONFIG_FORCEDETH_NAPI=y

	Ingo

Re: regression: forcedeth.c hang

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > This email lists some known regressions in 2.6.21-rc1 compared to 
> > 2.6.20 that are not yet fixed in Linus' tree.
> 
> just found a new one: forcedeth.c broke since v2.6.20. It generates a 
> few irqs after ifup and then stops dead (no in/out packets). Undoing 
> all of these commits fixes the problem:
> 
>  commit 21828163b2b31e0675cb3e66a2a4a231dec06236
>  commit 57fff6986b6daae13947c565786757c05303f0f6
>  commit 4e16ed1b0e17a3832310031e2ddaeb0914eb837d
>  commit f0734ab658390380079369f7090dcf7aa226f394
>  commit b01867cbd1853995946c8c838eff93a0885d8bc6
>  commit 445583b89d71b48cf8c64e26acc5a710248feed7
>  commit aaa37d2d099f97ced415546e285ac901e47a2437
>  commit 86b22b0dfbf462e6ed75e54fc83575dae01e3c69
>  commit 0d63fb32b2b8c3464d9c1afc3ce3fd3ceec025b6
>  commit 164a86e40e6c74ec5a91c364ccf7b1a2295b0a52
>  commit 761fcd9e3e0aa2a02231d1631f31409be5e890d2
>  commit d2f7841277d8613a780ab28d04d8f31a31816153
>  commit 1d39ed565cfcc7c4fe586de621aef495c4f94ffb
> 
> that's 75K of delta - i'll bisect it some more. Hardware in question:
> 
>  00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
> 
> config options:
> 
>  CONFIG_FORCEDETH=y
>  CONFIG_FORCEDETH_NAPI=y

git bisection gives:

| 0d63fb32b2b8c3464d9c1afc3ce3fd3ceec025b6 is first bad commit
| commit 0d63fb32b2b8c3464d9c1afc3ce3fd3ceec025b6
| Author: Ayaz Abdulla <aabdulla@nvidia.com>
| Date:   Tue Jan 9 13:30:13 2007 -0500
|
|    forcedeth: rx skb recycle
|
|    This patch removes the code that recycled the skb on error. This will
|    help in reducing the branches in the main data paths.
|
|    Signed-Off-By: Ayaz Abdulla <aabdulla@nvidia.com>
|
|    Signed-off-by: Jeff Garzik <jeff@garzik.org>
|
| :040000 040000 0e4cb0aa12ba1df6a7ca84da697c75082b449ece b70edcf390d63ac9e0b35d2aea7b59efe2bfeaea M      drivers

but i think this is simply the first commit that makes the driver 
essentially non-bisectable - the failures in interim iterations changed 
from 'interface unusable' to boot hangs that were either forcedeth tx 
ring timeouts, or hangs after nv_sata initialization. I've attached the 
full .config below.

	Ingo

-------------------------->
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21-rc1-syslet-v5
# Tue Feb 27 09:46:29 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_ASYNC_SUPPORT=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set
# CONFIG_UTS_NS is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
# CONFIG_IKCONFIG is not set
CONFIG_CPUSETS=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Block layer
#
CONFIG_BLOCK=y
CONFIG_LBD=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_LSF=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="deadline"

#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_SMP=y
# CONFIG_X86_PC is not set
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
CONFIG_X86_GENERICARCH=y
# CONFIG_X86_ES7000 is not set
CONFIG_PARAVIRT=y
# CONFIG_VMI is not set
CONFIG_X86_CYCLONE_TIMER=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MCORE2 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_NR_CPUS=32
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
CONFIG_TOSHIBA=m
CONFIG_I8K=m
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=m
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
CONFIG_EDD=m
CONFIG_EFI_VARS=y
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_EFI=y
# CONFIG_IRQBALANCE is not set
CONFIG_BOOT_IOREMAP=y
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_HOTPLUG_CPU=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SYSFS_DEPRECATED=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=""
CONFIG_SUSPEND_SMP=y

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_SLEEP_PROC_SLEEP is not set
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=m
# CONFIG_ACPI_BAY is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_IBM=m
CONFIG_ACPI_TOSHIBA=m
CONFIG_ACPI_BLACKLIST_YEAR=1999
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_SBS=m

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
CONFIG_APM_RTC_IS_GMT=y
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_DEBUG=y
CONFIG_CPU_FREQ_STAT=m
CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_POWERNOW_K6 is not set
CONFIG_X86_POWERNOW_K7=y
CONFIG_X86_POWERNOW_K7_ACPI=y
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_POWERNOW_K8_ACPI=y
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=y
CONFIG_X86_SPEEDSTEP_SMI=y
CONFIG_X86_P4_CLOCKMOD=m
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
CONFIG_X86_LONGRUN=y
# CONFIG_X86_LONGHAUL is not set
# CONFIG_X86_E_POWERSAVER is not set

#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_X86_SPEEDSTEP_LIB=y
# CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=m
# CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set
CONFIG_PCIEAER=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_DEBUG is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_K8_NB=y

#
# PCCARD (PCMCIA/CardBus) support
#
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
CONFIG_PD6729=m
CONFIG_I82092=m
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set
CONFIG_PCMCIA_PROBE=y
CONFIG_PCCARD_NONSTATIC=y

#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_FAKE=m
CONFIG_HOTPLUG_PCI_COMPAQ=m
# CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
CONFIG_HOTPLUG_PCI_IBM=m
CONFIG_HOTPLUG_PCI_ACPI=m
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=y
CONFIG_TCP_CONG_CUBIC=m
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_DEFAULT_BIC=y
# CONFIG_DEFAULT_CUBIC is not set
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="bic"
CONFIG_TCP_MD5SIG=y

#
# IP: Virtual Server Configuration
#
CONFIG_IP_VS=m
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12

#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m

#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
# CONFIG_IPV6_MIP6 is not set
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_SIT=m
CONFIG_IPV6_TUNNEL=m
# CONFIG_IPV6_MULTIPLE_TABLES is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CONNTRACK_ENABLED=m
CONFIG_NF_CONNTRACK_SUPPORT=y
# CONFIG_IP_NF_CONNTRACK_SUPPORT is not set
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CT_ACCT=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=m
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_PPTP=m
# CONFIG_NF_CONNTRACK_SANE is not set
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m

#
# IP: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_GRE=m
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_TFTP=m
CONFIG_NF_NAT_AMANDA=m
CONFIG_NF_NAT_PPTP=m
CONFIG_NF_NAT_H323=m
CONFIG_NF_NAT_SIP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
CONFIG_NF_CONNTRACK_IPV6=m
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AH=m
# CONFIG_IP6_NF_MATCH_MH is not set
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_RAW=m

#
# DECnet: Netfilter Configuration
#
# CONFIG_DECNET_NF_GRABULATOR is not set

#
# Bridge: Netfilter Configuration
#
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_ULOG=m

#
# DCCP Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m
CONFIG_IP_DCCP_ACKVEC=y

#
# DCCP CCIDs Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP_CCID2=m
# CONFIG_IP_DCCP_CCID2_DEBUG is not set
CONFIG_IP_DCCP_CCID3=m
CONFIG_IP_DCCP_TFRC_LIB=m
# CONFIG_IP_DCCP_CCID3_DEBUG is not set
CONFIG_IP_DCCP_CCID3_RTO=100

#
# DCCP Kernel Hacking
#
# CONFIG_IP_DCCP_DEBUG is not set
# CONFIG_NET_DCCPPROBE is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y

#
# TIPC Configuration (EXPERIMENTAL)
#
CONFIG_TIPC=m
# CONFIG_TIPC_ADVANCED is not set
# CONFIG_TIPC_DEBUG is not set
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
# CONFIG_ATM_MPOA is not set
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
CONFIG_DECNET=m
CONFIG_DECNET_ROUTER=y
CONFIG_LLC=y
# CONFIG_LLC2 is not set
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=m
# CONFIG_LTPC is not set
# CONFIG_COPS is not set
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
CONFIG_WAN_ROUTER=m

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_FIFO=y
# CONFIG_NET_SCH_CLK_JIFFIES is not set
CONFIG_NET_SCH_CLK_GETTIMEOFDAY=y
# CONFIG_NET_SCH_CLK_CPU is not set

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_ATM=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
CONFIG_NET_EMATCH_U32=m
CONFIG_NET_EMATCH_META=m
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=m
CONFIG_NET_ACT_IPT=m
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m
CONFIG_NET_CLS_IND=y
CONFIG_NET_ESTIMATOR=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_NET_TCPPROBE is not set
# CONFIG_HAMRADIO is not set
CONFIG_IRDA=m

#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
# CONFIG_IRDA_ULTRA is not set

#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
# CONFIG_IRDA_DEBUG is not set

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m

#
# Dongle support
#
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
CONFIG_TOIM3232_DONGLE=m
CONFIG_LITELINK_DONGLE=m
CONFIG_MA600_DONGLE=m
CONFIG_GIRBIL_DONGLE=m
CONFIG_MCP2120_DONGLE=m
CONFIG_OLD_BELKIN_DONGLE=m
CONFIG_ACT200L_DONGLE=m

#
# Old SIR device drivers
#

#
# Old Serial dongle support
#

#
# FIR device drivers
#
CONFIG_USB_IRDA=m
CONFIG_SIGMATEL_FIR=m
CONFIG_NSC_FIR=m
CONFIG_WINBOND_FIR=m
CONFIG_TOSHIBA_FIR=m
CONFIG_SMC_IRCC_FIR=m
CONFIG_ALI_FIR=m
CONFIG_VLSI_FIR=m
CONFIG_VIA_FIR=m
CONFIG_MCS_FIR=m
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_CMTP=m
CONFIG_BT_HIDP=m

#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m
CONFIG_IEEE80211=m
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=m
CONFIG_IEEE80211_CRYPT_CCMP=m
CONFIG_IEEE80211_CRYPT_TKIP=m
CONFIG_IEEE80211_SOFTMAC=m
CONFIG_IEEE80211_SOFTMAC_DEBUG=y
CONFIG_WIRELESS_EXT=y
CONFIG_FIB_RULES=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set

#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_CONCAT=m
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1
# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set
# CONFIG_MTD_REDBOOT_PARTS_READONLY is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLKDEVS=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_BLOCK_RO=m
CONFIG_FTL=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y
CONFIG_INFTL=m
CONFIG_RFD_FTL=m
# CONFIG_SSFDC is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_GEN_PROBE=m
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=m
CONFIG_MTD_CFI_AMDSTD=m
CONFIG_MTD_CFI_STAA=m
CONFIG_MTD_CFI_UTIL=m
CONFIG_MTD_RAM=m
CONFIG_MTD_ROM=m
CONFIG_MTD_ABSENT=m
# CONFIG_MTD_OBSOLETE_CHIPS is not set

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PNC2000 is not set
CONFIG_MTD_SC520CDP=m
CONFIG_MTD_NETSC520=m
CONFIG_MTD_TS5500=m
# CONFIG_MTD_SBC_GXX is not set
# CONFIG_MTD_AMD76XROM is not set
# CONFIG_MTD_ICHXROM is not set
# CONFIG_MTD_ESB2ROM is not set
# CONFIG_MTD_CK804XROM is not set
CONFIG_MTD_SCB2_FLASH=m
# CONFIG_MTD_NETtel is not set
# CONFIG_MTD_DILNETPC is not set
# CONFIG_MTD_L440GX is not set
CONFIG_MTD_PCI=m
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
CONFIG_MTD_PMC551=m
# CONFIG_MTD_PMC551_BUGFIX is not set
# CONFIG_MTD_PMC551_DEBUG is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
CONFIG_MTD_MTDRAM=m
CONFIG_MTDRAM_TOTAL_SIZE=4096
CONFIG_MTDRAM_ERASE_SIZE=128
CONFIG_MTD_BLOCK2MTD=m

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
CONFIG_MTD_NAND_ECC_SMC=y
CONFIG_MTD_NAND_IDS=m
CONFIG_MTD_NAND_DISKONCHIP=m
# CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set
CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0
# CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set
# CONFIG_MTD_NAND_CAFE is not set
CONFIG_MTD_NAND_CS553X=m
CONFIG_MTD_NAND_NANDSIM=m

#
# OneNAND Flash Device Drivers
#
# CONFIG_MTD_ONENAND is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
CONFIG_PARPORT_PC_PCMCIA=m
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_ISAPNP=y
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
CONFIG_PARIDE=m

#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m

#
# Parallel IDE protocol modules
#
CONFIG_PARIDE_ATEN=m
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_BPCK6=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
CONFIG_PARIDE_EPATC8=y
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_SX8=m
CONFIG_BLK_DEV_UB=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_BLK_DEV_RAM_BLOCKSIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
CONFIG_ATA_OVER_ETH=m

#
# Misc devices
#
CONFIG_IBM_ASM=m
# CONFIG_SGI_IOC4 is not set
CONFIG_TIFM_CORE=m
CONFIG_TIFM_7XX1=m
# CONFIG_ASUS_LAPTOP is not set
CONFIG_MSI_LAPTOP=m
# CONFIG_SONY_LAPTOP is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECS=m
# CONFIG_BLK_DEV_DELKIN is not set
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_BLK_DEV_IDEACPI is not set
CONFIG_IDE_TASK_IOCTL=y

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_CMD640_ENHANCED=y
CONFIG_BLK_DEV_IDEPNP=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
CONFIG_BLK_DEV_ATIIXP=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_TRIFLEX=y
# CONFIG_BLK_DEV_CY82C693 is not set
CONFIG_BLK_DEV_CS5520=y
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_CS5535=y
CONFIG_BLK_DEV_HPT34X=y
# CONFIG_HPT34X_AUTODMA is not set
CONFIG_BLK_DEV_HPT366=y
CONFIG_BLK_DEV_JMICRON=m
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT8213 is not set
CONFIG_BLK_DEV_IT821X=y
# CONFIG_BLK_DEV_NS87415 is not set
CONFIG_BLK_DEV_PDC202XX_OLD=y
# CONFIG_PDC202XX_BURST is not set
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_BLK_DEV_SVWKS=y
CONFIG_BLK_DEV_SIIMAGE=y
CONFIG_BLK_DEV_SIS5513=y
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
CONFIG_SCSI_TGT=m
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=y
CONFIG_SCSI_SAS_LIBSAS=y
# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set

#
# SCSI low-level drivers
#
CONFIG_ISCSI_TCP=m
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_3W_9XXX=m
# CONFIG_SCSI_7000FASST is not set
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=4
CONFIG_AIC7XXX_RESET_DELAY_MS=1000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_SCSI_AIC79XX=y
CONFIG_AIC79XX_CMDS_PER_DEVICE=4
CONFIG_AIC79XX_RESET_DELAY_MS=1000
# CONFIG_AIC79XX_ENABLE_RD_STRM is not set
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC94XX=y
# CONFIG_AIC94XX_DEBUG is not set
# CONFIG_SCSI_DPT_I2O is not set
CONFIG_SCSI_ADVANSYS=m
# CONFIG_SCSI_IN2000 is not set
CONFIG_SCSI_ARCMSR=m
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
CONFIG_MEGARAID_MAILBOX=m
CONFIG_MEGARAID_LEGACY=m
CONFIG_MEGARAID_SAS=m
CONFIG_SCSI_HPTIOP=m
CONFIG_SCSI_BUSLOGIC=m
# CONFIG_SCSI_OMIT_FLASHPOINT is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INITIO=m
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
# CONFIG_SCSI_NCR53C406A is not set
CONFIG_SCSI_STEX=m
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_MMIO=y
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_QLA_FC=m
CONFIG_SCSI_QLA_ISCSI=m
CONFIG_SCSI_LPFC=m
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SYM53C416 is not set
CONFIG_SCSI_DC395x=m
CONFIG_SCSI_DC390T=m
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
CONFIG_SCSI_SRP=m

#
# PCMCIA SCSI adapter support
#
CONFIG_PCMCIA_AHA152X=m
CONFIG_PCMCIA_FDOMAIN=m
CONFIG_PCMCIA_NINJA_SCSI=m
CONFIG_PCMCIA_QLOGIC=m
CONFIG_PCMCIA_SYM53C500=m

#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_SATA_AHCI=y
CONFIG_SATA_SVW=y
CONFIG_ATA_PIIX=y
CONFIG_SATA_MV=y
CONFIG_SATA_NV=y
CONFIG_PDC_ADMA=y
CONFIG_SATA_QSTOR=y
CONFIG_SATA_PROMISE=y
CONFIG_SATA_SX4=y
CONFIG_SATA_SIL=y
CONFIG_SATA_SIL24=y
CONFIG_SATA_SIS=y
CONFIG_SATA_ULI=y
CONFIG_SATA_VIA=y
CONFIG_SATA_VITESSE=y
# CONFIG_SATA_INIC162X is not set
CONFIG_SATA_INTEL_COMBINED=y
CONFIG_SATA_ACPI=y
CONFIG_PATA_ALI=y
CONFIG_PATA_AMD=y
CONFIG_PATA_ARTOP=y
CONFIG_PATA_ATIIXP=y
CONFIG_PATA_CMD64X=y
CONFIG_PATA_CS5520=y
CONFIG_PATA_CS5530=y
CONFIG_PATA_CS5535=y
CONFIG_PATA_CYPRESS=y
CONFIG_PATA_EFAR=y
CONFIG_ATA_GENERIC=y
CONFIG_PATA_HPT366=y
CONFIG_PATA_HPT37X=y
CONFIG_PATA_HPT3X2N=y
CONFIG_PATA_HPT3X3=y
CONFIG_PATA_ISAPNP=y
CONFIG_PATA_IT821X=y
# CONFIG_PATA_IT8213 is not set
CONFIG_PATA_JMICRON=y
CONFIG_PATA_LEGACY=m
CONFIG_PATA_TRIFLEX=y
CONFIG_PATA_MARVELL=y
CONFIG_PATA_MPIIX=y
CONFIG_PATA_OLDPIIX=y
CONFIG_PATA_NETCELL=y
CONFIG_PATA_NS87410=y
CONFIG_PATA_OPTI=y
CONFIG_PATA_OPTIDMA=y
CONFIG_PATA_PCMCIA=y
CONFIG_PATA_PDC_OLD=y
CONFIG_PATA_QDI=y
CONFIG_PATA_RADISYS=y
CONFIG_PATA_RZ1000=y
CONFIG_PATA_SC1200=y
CONFIG_PATA_SERVERWORKS=y
CONFIG_PATA_PDC2027X=y
CONFIG_PATA_SIL680=y
CONFIG_PATA_SIS=y
CONFIG_PATA_VIA=y
CONFIG_PATA_WINBOND=y
CONFIG_PATA_WINBOND_VLB=y

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_RAID5_RESHAPE=y
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
CONFIG_DM_MULTIPATH_EMC=m

#
# Fusion MPT device support
#
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
CONFIG_FUSION_FC=m
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=40
CONFIG_FUSION_CTL=m
CONFIG_FUSION_LAN=m

#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=m

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
CONFIG_IEEE1394_CONFIG_ROM_IP1394=y

#
# Device Drivers
#
CONFIG_IEEE1394_PCILYNX=m
CONFIG_IEEE1394_OHCI1394=m

#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m

#
# I2O device support
#
CONFIG_I2O=m
# CONFIG_I2O_LCT_NOTIFY_ON_CHANGES is not set
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_CONFIG=m
CONFIG_I2O_CONFIG_OLD_IOCTL=y
CONFIG_I2O_BUS=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m

#
# Macintosh device drivers
#
# CONFIG_MAC_EMUMOUSEBTN is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_IFB=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_NET_SB1000=m

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
CONFIG_PHYLIB=m

#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_BROADCOM_PHY=m
CONFIG_FIXED_PHY=m
CONFIG_FIXED_MII_10_FDX=y
CONFIG_FIXED_MII_100_FDX=y

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_CASSINI=m
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
CONFIG_EL3=m
# CONFIG_3C515 is not set
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
# CONFIG_LANCE is not set
CONFIG_NET_VENDOR_SMC=y
# CONFIG_WD80x3 is not set
CONFIG_ULTRA=m
# CONFIG_SMC9194 is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
CONFIG_TULIP_MMIO=y
# CONFIG_TULIP_NAPI is not set
CONFIG_DE4X5=m
CONFIG_WINBOND_840=m
CONFIG_DM9102=m
CONFIG_ULI526X=m
CONFIG_PCMCIA_XIRCOM=m
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
CONFIG_NET_ISA=y
# CONFIG_E2100 is not set
CONFIG_EWRK3=m
# CONFIG_EEXPRESS is not set
# CONFIG_EEXPRESS_PRO is not set
# CONFIG_HPLAN_PLUS is not set
# CONFIG_HPLAN is not set
# CONFIG_LP486E is not set
# CONFIG_ETH16I is not set
CONFIG_NE2000=m
# CONFIG_ZNET is not set
# CONFIG_SEEQ8005 is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_PCNET32_NAPI=y
CONFIG_AMD8111_ETH=m
CONFIG_AMD8111E_NAPI=y
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_ADAPTEC_STARFIRE_NAPI=y
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
CONFIG_B44=m
CONFIG_FORCEDETH=y
CONFIG_FORCEDETH_NAPI=y
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_8139CP=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
# CONFIG_SUNDANCE_MMIO is not set
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
CONFIG_VIA_RHINE_MMIO=y
CONFIG_VIA_RHINE_NAPI=y
# CONFIG_SC92031 is not set
CONFIG_NET_POCKET=y
CONFIG_ATP=m
CONFIG_DE600=m
CONFIG_DE620=m

#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
CONFIG_E1000=y
CONFIG_E1000_NAPI=y
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_R8169=m
CONFIG_R8169_NAPI=y
CONFIG_R8169_VLAN=y
CONFIG_SIS190=m
CONFIG_SKGE=y
CONFIG_SKY2=m
# CONFIG_SK98LIN is not set
CONFIG_VIA_VELOCITY=m
CONFIG_TIGON3=y
CONFIG_BNX2=m
CONFIG_QLA3XXX=m
# CONFIG_ATL1 is not set

#
# Ethernet (10000 Mbit)
#
CONFIG_CHELSIO_T1=m
CONFIG_CHELSIO_T1_1G=y
CONFIG_CHELSIO_T1_NAPI=y
# CONFIG_CHELSIO_T3 is not set
CONFIG_IXGB=m
CONFIG_IXGB_NAPI=y
CONFIG_S2IO=m
CONFIG_S2IO_NAPI=y
CONFIG_MYRI10GE=m
CONFIG_NETXEN_NIC=m

#
# Token Ring devices
#
CONFIG_TR=y
# CONFIG_IBMTR is not set
CONFIG_IBMOL=m
CONFIG_IBMLS=m
CONFIG_3C359=m
# CONFIG_TMS380TR is not set
# CONFIG_SMCTR is not set

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
CONFIG_NET_WIRELESS_RTNETLINK=y

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
# CONFIG_ARLAN is not set
# CONFIG_WAVELAN is not set
CONFIG_PCMCIA_WAVELAN=m
CONFIG_PCMCIA_NETWAVE=m

#
# Wireless 802.11 Frequency Hopping cards support
#
# CONFIG_PCMCIA_RAYCS is not set

#
# Wireless 802.11b ISA/PCI cards support
#
CONFIG_IPW2100=m
CONFIG_IPW2100_MONITOR=y
# CONFIG_IPW2100_DEBUG is not set
CONFIG_IPW2200=m
CONFIG_IPW2200_MONITOR=y
CONFIG_IPW2200_RADIOTAP=y
CONFIG_IPW2200_PROMISCUOUS=y
CONFIG_IPW2200_QOS=y
# CONFIG_IPW2200_DEBUG is not set
CONFIG_AIRO=m
CONFIG_HERMES=m
CONFIG_PLX_HERMES=m
CONFIG_TMD_HERMES=m
CONFIG_NORTEL_HERMES=m
CONFIG_PCI_HERMES=m
CONFIG_ATMEL=m
CONFIG_PCI_ATMEL=m

#
# Wireless 802.11b Pcmcia/Cardbus cards support
#
CONFIG_PCMCIA_HERMES=m
CONFIG_PCMCIA_SPECTRUM=m
CONFIG_AIRO_CS=m
CONFIG_PCMCIA_ATMEL=m
CONFIG_PCMCIA_WL3501=m

#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
CONFIG_PRISM54=m
CONFIG_USB_ZD1201=m
CONFIG_HOSTAP=m
CONFIG_HOSTAP_FIRMWARE=y
CONFIG_HOSTAP_FIRMWARE_NVRAM=y
CONFIG_HOSTAP_PLX=m
CONFIG_HOSTAP_PCI=m
CONFIG_HOSTAP_CS=m
CONFIG_BCM43XX=m
CONFIG_BCM43XX_DEBUG=y
CONFIG_BCM43XX_DMA=y
CONFIG_BCM43XX_PIO=y
CONFIG_BCM43XX_DMA_AND_PIO_MODE=y
# CONFIG_BCM43XX_DMA_MODE is not set
# CONFIG_BCM43XX_PIO_MODE is not set
CONFIG_ZD1211RW=m
# CONFIG_ZD1211RW_DEBUG is not set
CONFIG_NET_WIRELESS=y

#
# PCMCIA network device support
#
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_3C589=m
CONFIG_PCMCIA_3C574=m
CONFIG_PCMCIA_FMVJ18X=m
CONFIG_PCMCIA_PCNET=m
CONFIG_PCMCIA_NMCLAN=m
CONFIG_PCMCIA_SMC91C92=m
CONFIG_PCMCIA_XIRC2PS=m
CONFIG_PCMCIA_AXNET=m
CONFIG_PCMCIA_IBMTR=m

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# ATM drivers
#
# CONFIG_ATM_DUMMY is not set
CONFIG_ATM_TCP=m
CONFIG_ATM_LANAI=m
CONFIG_ATM_ENI=m
# CONFIG_ATM_ENI_DEBUG is not set
# CONFIG_ATM_ENI_TUNE_BURST is not set
CONFIG_ATM_FIRESTREAM=m
# CONFIG_ATM_ZATM is not set
CONFIG_ATM_NICSTAR=m
# CONFIG_ATM_NICSTAR_USE_SUNI is not set
# CONFIG_ATM_NICSTAR_USE_IDT77105 is not set
CONFIG_ATM_IDT77252=m
# CONFIG_ATM_IDT77252_DEBUG is not set
# CONFIG_ATM_IDT77252_RCV_ALL is not set
CONFIG_ATM_IDT77252_USE_SUNI=y
CONFIG_ATM_AMBASSADOR=m
# CONFIG_ATM_AMBASSADOR_DEBUG is not set
CONFIG_ATM_HORIZON=m
# CONFIG_ATM_HORIZON_DEBUG is not set
# CONFIG_ATM_IA is not set
CONFIG_ATM_FORE200E_MAYBE=m
# CONFIG_ATM_FORE200E_PCA is not set
CONFIG_ATM_HE=m
# CONFIG_ATM_HE_USE_SUNI is not set
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
CONFIG_SKFP=m
# CONFIG_HIPPI is not set
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
# CONFIG_PPP_BSDCOMP is not set
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLHC=m
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 is not set
CONFIG_NET_FC=y
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
CONFIG_ISDN=m

#
# Old ISDN4Linux
#
CONFIG_ISDN_I4L=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_MPP=y
CONFIG_IPPP_FILTER=y
# CONFIG_ISDN_PPP_BSDCOMP is not set
CONFIG_ISDN_AUDIO=y
CONFIG_ISDN_TTY_FAX=y

#
# ISDN feature submodules
#
CONFIG_ISDN_DIVERSION=m

#
# ISDN4Linux hardware drivers
#

#
# Passive cards
#
CONFIG_ISDN_DRV_HISAX=m

#
# D-channel protocol features
#
CONFIG_HISAX_EURO=y
CONFIG_DE_AOC=y
CONFIG_HISAX_NO_SENDCOMPLETE=y
CONFIG_HISAX_NO_LLC=y
CONFIG_HISAX_NO_KEYPAD=y
CONFIG_HISAX_1TR6=y
CONFIG_HISAX_NI1=y
CONFIG_HISAX_MAX_CARDS=8

#
# HiSax supported cards
#
# CONFIG_HISAX_16_0 is not set
CONFIG_HISAX_16_3=y
CONFIG_HISAX_TELESPCI=y
CONFIG_HISAX_S0BOX=y
# CONFIG_HISAX_AVM_A1 is not set
CONFIG_HISAX_FRITZPCI=y
CONFIG_HISAX_AVM_A1_PCMCIA=y
CONFIG_HISAX_ELSA=y
# CONFIG_HISAX_IX1MICROR2 is not set
CONFIG_HISAX_DIEHLDIVA=y
# CONFIG_HISAX_ASUSCOM is not set
# CONFIG_HISAX_TELEINT is not set
# CONFIG_HISAX_HFCS is not set
CONFIG_HISAX_SEDLBAUER=y
# CONFIG_HISAX_SPORTSTER is not set
# CONFIG_HISAX_MIC is not set
CONFIG_HISAX_NETJET=y
CONFIG_HISAX_NETJET_U=y
CONFIG_HISAX_NICCY=y
# CONFIG_HISAX_ISURF is not set
# CONFIG_HISAX_HSTSAPHIR is not set
CONFIG_HISAX_BKM_A4T=y
CONFIG_HISAX_SCT_QUADRO=y
CONFIG_HISAX_GAZEL=y
CONFIG_HISAX_HFC_PCI=y
CONFIG_HISAX_W6692=y
CONFIG_HISAX_HFC_SX=y
CONFIG_HISAX_ENTERNOW_PCI=y
# CONFIG_HISAX_DEBUG is not set

#
# HiSax PCMCIA card service modules
#
CONFIG_HISAX_SEDLBAUER_CS=m
CONFIG_HISAX_ELSA_CS=m
CONFIG_HISAX_AVM_A1_CS=m
CONFIG_HISAX_TELES_CS=m

#
# HiSax sub driver modules
#
CONFIG_HISAX_ST5481=m
# CONFIG_HISAX_HFCUSB is not set
CONFIG_HISAX_HFC4S8S=m
CONFIG_HISAX_FRITZ_PCIPNP=m
CONFIG_HISAX_HDLC=y

#
# Active cards
#
# CONFIG_ISDN_DRV_ICN is not set
# CONFIG_ISDN_DRV_PCBIT is not set
# CONFIG_ISDN_DRV_SC is not set
# CONFIG_ISDN_DRV_ACT2000 is not set

#
# Siemens Gigaset
#
CONFIG_ISDN_DRV_GIGASET=m
CONFIG_GIGASET_BASE=m
CONFIG_GIGASET_M105=m
# CONFIG_GIGASET_M101 is not set
# CONFIG_GIGASET_DEBUG is not set
# CONFIG_GIGASET_UNDOCREQ is not set

#
# CAPI subsystem
#
CONFIG_ISDN_CAPI=m
CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPI20=m
CONFIG_ISDN_CAPI_CAPIFS_BOOL=y
CONFIG_ISDN_CAPI_CAPIFS=m
CONFIG_ISDN_CAPI_CAPIDRV=m

#
# CAPI hardware drivers
#

#
# Active AVM cards
#
CONFIG_CAPI_AVM=y
# CONFIG_ISDN_DRV_AVMB1_B1ISA is not set
CONFIG_ISDN_DRV_AVMB1_B1PCI=m
CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y
# CONFIG_ISDN_DRV_AVMB1_T1ISA is not set
CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m
CONFIG_ISDN_DRV_AVMB1_AVM_CS=m
CONFIG_ISDN_DRV_AVMB1_T1PCI=m
CONFIG_ISDN_DRV_AVMB1_C4=m

#
# Active Eicon DIVA Server cards
#
CONFIG_CAPI_EICON=y
CONFIG_ISDN_DIVAS=m
CONFIG_ISDN_DIVAS_BRIPCI=y
CONFIG_ISDN_DIVAS_PRIPCI=y
CONFIG_ISDN_DIVAS_DIVACAPI=m
CONFIG_ISDN_DIVAS_USERIDI=m
CONFIG_ISDN_DIVAS_MAINT=m

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_KEYBOARD_STOWAWAY=m
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_SERIAL=m
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
CONFIG_MOUSE_VSXXXAA=m
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_A3D=m
CONFIG_JOYSTICK_ADI=m
CONFIG_JOYSTICK_COBRA=m
CONFIG_JOYSTICK_GF2K=m
CONFIG_JOYSTICK_GRIP=m
CONFIG_JOYSTICK_GRIP_MP=m
CONFIG_JOYSTICK_GUILLEMOT=m
CONFIG_JOYSTICK_INTERACT=m
CONFIG_JOYSTICK_SIDEWINDER=m
CONFIG_JOYSTICK_TMDC=m
CONFIG_JOYSTICK_IFORCE=m
CONFIG_JOYSTICK_IFORCE_USB=y
CONFIG_JOYSTICK_IFORCE_232=y
CONFIG_JOYSTICK_WARRIOR=m
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
CONFIG_JOYSTICK_STINGER=m
CONFIG_JOYSTICK_TWIDJOY=m
CONFIG_JOYSTICK_DB9=m
CONFIG_JOYSTICK_GAMECON=m
CONFIG_JOYSTICK_TURBOGRAFX=m
CONFIG_JOYSTICK_JOYDUMP=m
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_TOUCHSCREEN_ELO=m
CONFIG_TOUCHSCREEN_MTOUCH=m
CONFIG_TOUCHSCREEN_MK712=m
CONFIG_TOUCHSCREEN_PENMOUNT=m
CONFIG_TOUCHSCREEN_TOUCHRIGHT=m
CONFIG_TOUCHSCREEN_TOUCHWIN=m
CONFIG_TOUCHSCREEN_UCB1400=m
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_WISTRON_BTNS=m
# CONFIG_INPUT_ATLAS_BTNS is not set
CONFIG_INPUT_UINPUT=m

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
CONFIG_GAMEPORT_FM801=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_ESPSERIAL is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
CONFIG_MOXA_SMARTIO_NEW=m
# CONFIG_ISI is not set
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_SYNCLINK_GT=m
CONFIG_N_HDLC=m
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
# CONFIG_SERIAL_8250_FOURPORT is not set
# CONFIG_SERIAL_8250_ACCENT is not set
# CONFIG_SERIAL_8250_BOCA is not set
CONFIG_SERIAL_8250_EXAR_ST16C554=m
# CONFIG_SERIAL_8250_HUB6 is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=m
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
CONFIG_TIPAR=m

#
# IPMI
#
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
CONFIG_IBMASR=m
# CONFIG_WAFER_WDT is not set
CONFIG_I6300ESB_WDT=m
CONFIG_I8XX_TCO=m
CONFIG_ITCO_WDT=m
CONFIG_ITCO_VENDOR_SUPPORT=y
# CONFIG_SC1200_WDT is not set
CONFIG_PC87413_WDT=m
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
CONFIG_W83627HF_WDT=m
CONFIG_W83697HF_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_W83977F_WDT=m
CONFIG_MACHZ_WDT=m
# CONFIG_SBC_EPX_C3_WATCHDOG is not set

#
# ISA-based Watchdog Cards
#
# CONFIG_PCWATCHDOG is not set
# CONFIG_MIXCOMWD is not set
# CONFIG_WDT is not set

#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m
CONFIG_WDT_501_PCI=y

#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_GEODE=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_NVRAM=y
CONFIG_RTC=y
CONFIG_DTLK=m
CONFIG_R3964=m
# CONFIG_APPLICOM is not set
CONFIG_SONYPI=m
CONFIG_AGP=y
CONFIG_AGP_ALI=y
CONFIG_AGP_ATI=y
CONFIG_AGP_AMD=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_NVIDIA=y
CONFIG_AGP_SIS=y
CONFIG_AGP_SWORKS=y
CONFIG_AGP_VIA=y
CONFIG_AGP_EFFICEON=y
CONFIG_DRM=m
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_I915=m
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=m

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
CONFIG_CARDMAN_4000=m
CONFIG_CARDMAN_4040=m
CONFIG_MWAVE=m
CONFIG_PC8736x_GPIO=m
CONFIG_NSC_GPIO=m
CONFIG_CS5535_GPIO=m
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
# CONFIG_HPET_MMAP is not set
CONFIG_HANGCHECK_TIMER=m

#
# TPM devices
#
CONFIG_TCG_TPM=m
CONFIG_TCG_TIS=m
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
CONFIG_TCG_INFINEON=m
# CONFIG_TELCLOCK is not set

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_ISA=m
CONFIG_I2C_NFORCE2=m
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_PASEMI is not set
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
# CONFIG_SCx200_ACB is not set
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
CONFIG_I2C_STUB=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
CONFIG_I2C_PCA_ISA=m

#
# Miscellaneous I2C Chip support
#
CONFIG_SENSORS_DS1337=m
CONFIG_SENSORS_DS1374=m
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCA9539=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_MAX6875=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#
CONFIG_W1=m
CONFIG_W1_CON=y

#
# 1-wire Bus Masters
#
CONFIG_W1_MASTER_MATROX=m
CONFIG_W1_MASTER_DS2490=m
CONFIG_W1_MASTER_DS2482=m

#
# 1-wire Slaves
#
CONFIG_W1_SLAVE_THERM=m
CONFIG_W1_SLAVE_SMEM=m
CONFIG_W1_SLAVE_DS2433=m
CONFIG_W1_SLAVE_DS2433_CRC=y

#
# Hardware Monitoring support
#
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
CONFIG_SENSORS_ABITUGURU=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
# CONFIG_SENSORS_ADM1029 is not set
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_F71805F=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_FSCPOS=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM63=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
CONFIG_SENSORS_MAX1619=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_SIS5595=m
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_SMSC47M192=m
CONFIG_SENSORS_SMSC47B397=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_VT1211=m
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83791D=m
CONFIG_SENSORS_W83792D=m
CONFIG_SENSORS_W83793=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m
CONFIG_SENSORS_W83627EHF=m
CONFIG_SENSORS_HDAPS=m
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y

#
# Video Capture Adapters
#

#
# Video Capture Adapters
#
# CONFIG_VIDEO_ADV_DEBUG is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
CONFIG_VIDEO_TVAUDIO=m
CONFIG_VIDEO_TDA7432=m
CONFIG_VIDEO_TDA9840=m
CONFIG_VIDEO_TDA9875=m
CONFIG_VIDEO_TEA6415C=m
CONFIG_VIDEO_TEA6420=m
CONFIG_VIDEO_MSP3400=m
CONFIG_VIDEO_WM8775=m
CONFIG_VIDEO_BT819=m
CONFIG_VIDEO_BT856=m
CONFIG_VIDEO_KS0127=m
CONFIG_VIDEO_OV7670=m
CONFIG_VIDEO_SAA7110=m
CONFIG_VIDEO_SAA7111=m
CONFIG_VIDEO_SAA7114=m
CONFIG_VIDEO_SAA711X=m
CONFIG_VIDEO_TVP5150=m
CONFIG_VIDEO_VPX3220=m
CONFIG_VIDEO_CX25840=m
CONFIG_VIDEO_CX2341X=m
CONFIG_VIDEO_SAA7185=m
CONFIG_VIDEO_ADV7170=m
CONFIG_VIDEO_ADV7175=m
# CONFIG_VIDEO_VIVI is not set
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_BT848_DVB=y
CONFIG_VIDEO_SAA6588=m
# CONFIG_VIDEO_PMS is not set
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_CPIA2=m
CONFIG_VIDEO_SAA5246A=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN_ZR36060=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_DC30=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZORAN_LML33R10=m
CONFIG_VIDEO_ZORAN_AVS6EYES=m
CONFIG_VIDEO_MEYE=m
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_SAA7134_ALSA=m
CONFIG_VIDEO_SAA7134_DVB=m
CONFIG_VIDEO_MXB=m
CONFIG_VIDEO_DPC=m
CONFIG_VIDEO_HEXIUM_ORION=m
CONFIG_VIDEO_HEXIUM_GEMINI=m
CONFIG_VIDEO_CX88=m
CONFIG_VIDEO_CX88_ALSA=m
CONFIG_VIDEO_CX88_BLACKBIRD=m
CONFIG_VIDEO_CX88_DVB=m
CONFIG_VIDEO_CX88_VP3054=m
CONFIG_VIDEO_CAFE_CCIC=m

#
# V4L USB devices
#
CONFIG_VIDEO_PVRUSB2=m
# CONFIG_VIDEO_PVRUSB2_29XXX is not set
CONFIG_VIDEO_PVRUSB2_24XXX=y
CONFIG_VIDEO_PVRUSB2_SYSFS=y
# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set
CONFIG_VIDEO_EM28XX=m
CONFIG_VIDEO_USBVISION=m
CONFIG_VIDEO_USBVIDEO=m
CONFIG_USB_VICAM=m
CONFIG_USB_IBMCAM=m
CONFIG_USB_KONICAWC=m
CONFIG_USB_QUICKCAM_MESSENGER=m
CONFIG_USB_ET61X251=m
CONFIG_VIDEO_OVCAMCHIP=m
CONFIG_USB_W9968CF=m
CONFIG_USB_OV511=m
CONFIG_USB_SE401=m
CONFIG_USB_SN9C102=m
CONFIG_USB_STV680=m
CONFIG_USB_ZC0301=m
CONFIG_USB_PWC=m
# CONFIG_USB_PWC_DEBUG is not set

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
CONFIG_RADIO_GEMTEK_PCI=m
CONFIG_RADIO_MAXIRADIO=m
CONFIG_RADIO_MAESTRO=m
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set
CONFIG_USB_DSBR=m

#
# Digital Video Broadcasting Devices
#
CONFIG_DVB=y
CONFIG_DVB_CORE=m
# CONFIG_DVB_CORE_ATTACH is not set

#
# Supported SAA7146 based PCI Adapters
#
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET=m
CONFIG_DVB_BUDGET_CI=m
CONFIG_DVB_BUDGET_AV=m
CONFIG_DVB_BUDGET_PATCH=m

#
# Supported USB Adapters
#
CONFIG_DVB_USB=m
# CONFIG_DVB_USB_DEBUG is not set
CONFIG_DVB_USB_A800=m
CONFIG_DVB_USB_DIBUSB_MB=m
# CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set
CONFIG_DVB_USB_DIBUSB_MC=m
CONFIG_DVB_USB_DIB0700=m
CONFIG_DVB_USB_UMT_010=m
CONFIG_DVB_USB_CXUSB=m
# CONFIG_DVB_USB_M920X is not set
# CONFIG_DVB_USB_GL861 is not set
# CONFIG_DVB_USB_AU6610 is not set
CONFIG_DVB_USB_DIGITV=m
CONFIG_DVB_USB_VP7045=m
CONFIG_DVB_USB_VP702X=m
CONFIG_DVB_USB_GP8PSK=m
CONFIG_DVB_USB_NOVA_T_USB2=m
CONFIG_DVB_USB_TTUSB2=m
CONFIG_DVB_USB_DTT200U=m
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_DVB_CINERGYT2=m
CONFIG_DVB_CINERGYT2_TUNING=y
CONFIG_DVB_CINERGYT2_STREAM_URB_COUNT=32
CONFIG_DVB_CINERGYT2_STREAM_BUF_SIZE=512
CONFIG_DVB_CINERGYT2_QUERY_INTERVAL=250
CONFIG_DVB_CINERGYT2_ENABLE_RC_INPUT_DEVICE=y
CONFIG_DVB_CINERGYT2_RC_QUERY_INTERVAL=100

#
# Supported FlexCopII (B2C2) Adapters
#
CONFIG_DVB_B2C2_FLEXCOP=m
CONFIG_DVB_B2C2_FLEXCOP_PCI=m
CONFIG_DVB_B2C2_FLEXCOP_USB=m
# CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set

#
# Supported BT878 Adapters
#
CONFIG_DVB_BT8XX=m

#
# Supported Pluto2 Adapters
#
CONFIG_DVB_PLUTO2=m

#
# Supported DVB Frontends
#

#
# Customise DVB Frontends
#
# CONFIG_DVB_FE_CUSTOMISE is not set

#
# DVB-S (satellite) frontends
#
CONFIG_DVB_STV0299=m
CONFIG_DVB_CX24110=m
CONFIG_DVB_CX24123=m
CONFIG_DVB_TDA8083=m
CONFIG_DVB_MT312=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_S5H1420=m
CONFIG_DVB_TDA10086=m

#
# DVB-T (terrestrial) frontends
#
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
CONFIG_DVB_CX22702=m
CONFIG_DVB_L64781=m
CONFIG_DVB_TDA1004X=m
CONFIG_DVB_NXT6000=m
CONFIG_DVB_MT352=m
CONFIG_DVB_ZL10353=m
CONFIG_DVB_DIB3000MB=m
CONFIG_DVB_DIB3000MC=m
CONFIG_DVB_DIB7000M=m
CONFIG_DVB_DIB7000P=m

#
# DVB-C (cable) frontends
#
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
CONFIG_DVB_STV0297=m

#
# ATSC (North American/Korean Terrestrial/Cable DTV) frontends
#
CONFIG_DVB_NXT200X=m
CONFIG_DVB_OR51211=m
CONFIG_DVB_OR51132=m
CONFIG_DVB_BCM3510=m
CONFIG_DVB_LGDT330X=m

#
# Tuners/PLL support
#
CONFIG_DVB_PLL=m
CONFIG_DVB_TDA826X=m
# CONFIG_DVB_TUNER_QT1010 is not set
CONFIG_DVB_TUNER_MT2060=m
CONFIG_DVB_TUNER_LGH06XF=m

#
# Miscellaneous devices
#
CONFIG_DVB_LNBP21=m
CONFIG_DVB_ISL6421=m
CONFIG_DVB_TUA6100=m
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_BUF_DVB=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_IR=m
CONFIG_VIDEO_TVEEPROM=m
CONFIG_USB_DABUSB=m

#
# Graphics support
#
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_BACKLIGHT_PROGEAR is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frambuffer hardware drivers
#
CONFIG_FB_CIRRUS=m
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
# CONFIG_FB_IMAC is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
CONFIG_FB_NVIDIA=m
CONFIG_FB_NVIDIA_I2C=y
CONFIG_FB_NVIDIA_BACKLIGHT=y
CONFIG_FB_RIVA=m
# CONFIG_FB_RIVA_I2C is not set
# CONFIG_FB_RIVA_DEBUG is not set
CONFIG_FB_RIVA_BACKLIGHT=y
CONFIG_FB_I810=m
CONFIG_FB_I810_GTF=y
CONFIG_FB_I810_I2C=y
CONFIG_FB_INTEL=m
# CONFIG_FB_INTEL_DEBUG is not set
CONFIG_FB_INTEL_I2C=y
CONFIG_FB_MATROX=m
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G=y
CONFIG_FB_MATROX_I2C=m
CONFIG_FB_MATROX_MAVEN=m
CONFIG_FB_MATROX_MULTIHEAD=y
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
CONFIG_FB_ATY128=m
CONFIG_FB_ATY128_BACKLIGHT=y
CONFIG_FB_ATY=m
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GENERIC_LCD=y
CONFIG_FB_ATY_GX=y
CONFIG_FB_ATY_BACKLIGHT=y
# CONFIG_FB_S3 is not set
CONFIG_FB_SAVAGE=m
CONFIG_FB_SAVAGE_I2C=y
CONFIG_FB_SAVAGE_ACCEL=y
# CONFIG_FB_SIS is not set
CONFIG_FB_NEOMAGIC=m
CONFIG_FB_KYRO=m
CONFIG_FB_3DFX=m
CONFIG_FB_3DFX_ACCEL=y
CONFIG_FB_VOODOO1=m
CONFIG_FB_CYBLA=m
CONFIG_FB_TRIDENT=m
CONFIG_FB_TRIDENT_ACCEL=y
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_VIDEO_SELECT=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Logo configuration
#
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_OPL4_LIB=m
CONFIG_SND_VX_LIB=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_MTS64=m
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=m
# CONFIG_SND_PORTMAN2X4 is not set

#
# ISA devices
#
CONFIG_SND_CS4231_LIB=m
CONFIG_SND_ADLIB=m
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
CONFIG_SND_CS4236=m
# CONFIG_SND_DT019X is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
CONFIG_SND_ES18XX=m
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
CONFIG_SND_OPL3SA2=m
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
CONFIG_SND_MIRO=m
# CONFIG_SND_SB8 is not set
CONFIG_SND_SB16=m
CONFIG_SND_SBAWE=m
# CONFIG_SND_SB16_CSP is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set

#
# PCI devices
#
CONFIG_SND_AD1889=m
CONFIG_SND_ALS300=m
CONFIG_SND_ALS4000=m
CONFIG_SND_ALI5451=m
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
CONFIG_SND_AU8810=m
CONFIG_SND_AU8820=m
CONFIG_SND_AU8830=m
CONFIG_SND_AZT3328=m
CONFIG_SND_BT87X=m
# CONFIG_SND_BT87X_OVERCLOCK is not set
CONFIG_SND_CA0106=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_CS4281=m
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_CS5535AUDIO=m
CONFIG_SND_DARLA20=m
CONFIG_SND_GINA20=m
CONFIG_SND_LAYLA20=m
CONFIG_SND_DARLA24=m
CONFIG_SND_GINA24=m
CONFIG_SND_LAYLA24=m
CONFIG_SND_MONA=m
CONFIG_SND_MIA=m
CONFIG_SND_ECHO3G=m
CONFIG_SND_INDIGO=m
CONFIG_SND_INDIGOIO=m
CONFIG_SND_INDIGODJ=m
CONFIG_SND_EMU10K1=m
CONFIG_SND_EMU10K1X=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
CONFIG_SND_ES1938=m
CONFIG_SND_ES1968=m
CONFIG_SND_FM801=m
CONFIG_SND_FM801_TEA575X_BOOL=y
CONFIG_SND_FM801_TEA575X=m
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDSP=m
CONFIG_SND_HDSPM=m
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
CONFIG_SND_PCXHR=m
CONFIG_SND_RIPTIDE=m
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
CONFIG_SND_SONICVIBES=m
CONFIG_SND_TRIDENT=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VX222=m
CONFIG_SND_YMFPCI=m
CONFIG_SND_AC97_POWER_SAVE=y

#
# USB devices
#
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_USX2Y=m

#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_PDAUDIOCF is not set

#
# SoC audio support
#
# CONFIG_SND_SOC is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=m

#
# HID Devices
#
CONFIG_HID=m
# CONFIG_HID_DEBUG is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_EHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_ISP116X_HCD=m
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_U132_HCD=m
CONFIG_USB_SL811_HCD=m
CONFIG_USB_SL811_CS=m

#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_USBAT=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_STORAGE_ALAUDA=y
CONFIG_USB_STORAGE_KARMA=y
CONFIG_USB_LIBUSUAL=y

#
# USB Input Devices
#
CONFIG_USB_HID=m
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
CONFIG_HID_FF=y
CONFIG_HID_PID=y
CONFIG_LOGITECH_FF=y
# CONFIG_PANTHERLORD_FF is not set
CONFIG_THRUSTMASTER_FF=y
CONFIG_ZEROPLUS_FF=y
CONFIG_USB_HIDDEV=y

#
# USB HID Boot Protocol drivers
#
CONFIG_USB_KBD=m
CONFIG_USB_MOUSE=m
CONFIG_USB_AIPTEK=m
CONFIG_USB_WACOM=m
CONFIG_USB_ACECAD=m
CONFIG_USB_KBTAB=m
CONFIG_USB_POWERMATE=m
CONFIG_USB_TOUCHSCREEN=m
CONFIG_USB_TOUCHSCREEN_EGALAX=y
CONFIG_USB_TOUCHSCREEN_PANJIT=y
CONFIG_USB_TOUCHSCREEN_3M=y
CONFIG_USB_TOUCHSCREEN_ITM=y
CONFIG_USB_TOUCHSCREEN_ETURBO=y
CONFIG_USB_TOUCHSCREEN_GUNZE=y
CONFIG_USB_TOUCHSCREEN_DMC_TSC10=y
# CONFIG_USB_YEALINK is not set
CONFIG_USB_XPAD=m
CONFIG_USB_ATI_REMOTE=m
CONFIG_USB_ATI_REMOTE2=m
CONFIG_USB_KEYSPAN_REMOTE=m
CONFIG_USB_APPLETOUCH=m
# CONFIG_USB_GTCO is not set

#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m

#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET_MII=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_CDCETHER=m
# CONFIG_USB_NET_DM9601 is not set
CONFIG_USB_NET_GL620A=m
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_PLUSB=m
CONFIG_USB_NET_MCS7830=m
CONFIG_USB_NET_RNDIS_HOST=m
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
# CONFIG_USB_KC2190 is not set
CONFIG_USB_NET_ZAURUS=m
CONFIG_USB_MON=y

#
# USB port drivers
#
CONFIG_USB_USS720=m

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_AIRCABLE=m
CONFIG_USB_SERIAL_AIRPRIME=m
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CP2101=m
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_FUNSOFT=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_GARMIN=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KEYSPAN_MPR=y
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_MOS7720=m
CONFIG_USB_SERIAL_MOS7840=m
CONFIG_USB_SERIAL_NAVMAN=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_HP4X=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
CONFIG_USB_SERIAL_TI=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_SERIAL_DEBUG=m
CONFIG_USB_EZUSB=y

#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_ADUTUX=m
CONFIG_USB_AUERSWALD=m
CONFIG_USB_RIO500=m
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
# CONFIG_USB_BERRY_CHARGE is not set
CONFIG_USB_LED=m
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
CONFIG_USB_PHIDGET=m
CONFIG_USB_PHIDGETKIT=m
CONFIG_USB_PHIDGETMOTORCONTROL=m
CONFIG_USB_PHIDGETSERVO=m
CONFIG_USB_IDMOUSE=m
CONFIG_USB_FTDI_ELAN=m
CONFIG_USB_APPLEDISPLAY=m
CONFIG_USB_SISUSBVGA=m
CONFIG_USB_SISUSBVGA_CON=y
CONFIG_USB_LD=m
CONFIG_USB_TRANCEVIBRATOR=m
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=m

#
# USB DSL modem support
#
CONFIG_USB_ATM=m
CONFIG_USB_SPEEDTOUCH=m
CONFIG_USB_CXACRU=m
CONFIG_USB_UEAGLEATM=m
CONFIG_USB_XUSBATM=m

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_BLOCK=m
CONFIG_MMC_SDHCI=m
CONFIG_MMC_WBSD=m
CONFIG_MMC_TIFM_SD=m

#
# LED devices
#
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_IDE_DISK=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=m

#
# InfiniBand support
#
CONFIG_INFINIBAND=m
CONFIG_INFINIBAND_USER_MAD=m
CONFIG_INFINIBAND_USER_ACCESS=m
CONFIG_INFINIBAND_ADDR_TRANS=y
CONFIG_INFINIBAND_MTHCA=m
CONFIG_INFINIBAND_MTHCA_DEBUG=y
# CONFIG_INFINIBAND_AMSO1100 is not set
CONFIG_INFINIBAND_IPOIB=m
# CONFIG_INFINIBAND_IPOIB_CM is not set
CONFIG_INFINIBAND_IPOIB_DEBUG=y
CONFIG_INFINIBAND_IPOIB_DEBUG_DATA=y
CONFIG_INFINIBAND_SRP=m
CONFIG_INFINIBAND_ISER=m

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=m
CONFIG_EDAC_AMD76X=m
CONFIG_EDAC_E7XXX=m
CONFIG_EDAC_E752X=m
CONFIG_EDAC_I82875P=m
CONFIG_EDAC_I82860=m
CONFIG_EDAC_R82600=m
CONFIG_EDAC_POLL=y

#
# Real Time Clock
#
CONFIG_RTC_LIB=m
CONFIG_RTC_CLASS=m

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=m
CONFIG_RTC_INTF_PROC=m
CONFIG_RTC_INTF_DEV=m
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set

#
# RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1553=m
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_DS1672=m
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_RS5C372=m
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_TEST is not set
CONFIG_RTC_DRV_V3020=m

#
# DMA Engine support
#
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y

#
# DMA Devices
#
CONFIG_INTEL_IOATDMA=m

#
# Auxiliary Display support
#
# CONFIG_KS0108 is not set

#
# Virtualization
#
CONFIG_KVM=y
CONFIG_KVM_INTEL=y
CONFIG_KVM_AMD=y

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT2_FS_XIP=y
CONFIG_FS_XIP=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
CONFIG_JFS_FS=m
CONFIG_JFS_POSIX_ACL=y
CONFIG_JFS_SECURITY=y
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
CONFIG_XFS_SECURITY=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
CONFIG_GFS2_FS=m
CONFIG_GFS2_FS_LOCKING_NOLOCK=m
CONFIG_GFS2_FS_LOCKING_DLM=m
CONFIG_OCFS2_FS=m
# CONFIG_OCFS2_DEBUG_MASKLOG is not set
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_GENERIC_ACL=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=m

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
CONFIG_AFFS_FS=m
CONFIG_ECRYPT_FS=m
CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
CONFIG_BEFS_FS=m
# CONFIG_BEFS_DEBUG is not set
CONFIG_BFS_FS=m
CONFIG_EFS_FS=m
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
CONFIG_JFFS2_SUMMARY=y
# CONFIG_JFFS2_FS_XATTR is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
CONFIG_CRAMFS=m
CONFIG_VXFS_FS=m
# CONFIG_HPFS_FS is not set
CONFIG_QNX4FS_FS=m
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_UFS_DEBUG is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_RPCSEC_GSS_SPKM3=m
# CONFIG_SMB_FS is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_CODA_FS=m
# CONFIG_CODA_FS_OLD_API is not set
# CONFIG_AFS_FS is not set
CONFIG_9P_FS=m

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m

#
# Distributed Lock Manager
#
CONFIG_DLM=m
CONFIG_DLM_TCP=y
# CONFIG_DLM_SCTP is not set
CONFIG_DLM_DEBUG=y

#
# Instrumentation Support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=m
CONFIG_KPROBES=y

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOG_BUF_SHIFT=20
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_SCHEDSTATS=y
# CONFIG_TIMER_STATS is not set
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_PREEMPT=y
# CONFIG_DEBUG_RT_MUTEXES is not set
CONFIG_RT_MUTEX_TESTER=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_LIST=y
CONFIG_FRAME_POINTER=y
# CONFIG_FORCED_INLINING is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_LKDTM is not set
CONFIG_FAULT_INJECTION=y
CONFIG_FAILSLAB=y
CONFIG_FAIL_PAGE_ALLOC=y
CONFIG_FAIL_MAKE_REQUEST=y
CONFIG_FAULT_INJECTION_DEBUG_FS=y
# CONFIG_FAULT_INJECTION_STACKTRACE_FILTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set

#
# Page alloc debug is incompatible with Software Suspend on i386
#
CONFIG_DEBUG_RODATA=y
CONFIG_4KSTACKS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y
# CONFIG_DEBUG_PARAVIRT is not set

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT is not set
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_WP512=y
CONFIG_CRYPTO_TGR192=y
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_LRW=y
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_TWOFISH_COMMON=y
# CONFIG_CRYPTO_TWOFISH_586 is not set
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_586 is not set
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_KHAZAD=y
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_CRYPTO_DEV_GEODE=m

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_REED_SOLOMON=m
CONFIG_REED_SOLOMON_DEC16=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y
CONFIG_NO_IDLE_HZ=y

Re: regression: forcedeth.c hang

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> git bisection gives:
> 
> | 0d63fb32b2b8c3464d9c1afc3ce3fd3ceec025b6 is first bad commit

> but i think this is simply the first commit that makes the driver 
> essentially non-bisectable - the failures in interim iterations 
> changed from 'interface unusable' to boot hangs that were either 
> forcedeth tx ring timeouts, or hangs after nv_sata initialization.

here's the boot log of the tx_ring timeout that happens at the following 
commit in the first step of bisection:

 commit aaa37d2d099f97ced415546e285ac901e47a2437
 Author: Ayaz Abdulla <aabdulla@nvidia.com>
 Date:   Sun Jan 21 18:10:42 2007 -0500

     forcedeth: tx limiting

(eth0/eth1 gets flipped during network startup, so eth1 is the forcedeth 
driver)

	Ingo

---------------------->
Linux version 2.6.21-rc1-syslet-v5 (mingo@dione) (gcc version 4.0.2) #8 SMP PREEMPT Tue Feb 27 10:33:37 CET 2007
BIOS-provided physical RAM map:
sanitize start
sanitize end
copy_e820_map() start: 0000000000000000 size: 000000000009f800 end: 000000000009f800 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000000009f800 size: 0000000000000800 end: 00000000000a0000 type: 2
copy_e820_map() start: 00000000000f0000 size: 0000000000010000 end: 0000000000100000 type: 2
copy_e820_map() start: 0000000000100000 size: 000000003fef0000 end: 000000003fff0000 type: 1
copy_e820_map() type is E820_RAM
copy_e820_map() start: 000000003fff0000 size: 0000000000003000 end: 000000003fff3000 type: 4
copy_e820_map() start: 000000003fff3000 size: 000000000000d000 end: 0000000040000000 type: 3
copy_e820_map() start: 00000000e0000000 size: 0000000010000000 end: 00000000f0000000 type: 2
copy_e820_map() start: 00000000fec00000 size: 0000000001400000 end: 0000000100000000 type: 2
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
 BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
 BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f5680
Entering add_active_range(0, 0, 262128) 0 entries of 256 used
Zone PFN ranges:
  DMA             0 ->     4096
  Normal       4096 ->   229376
  HighMem    229376 ->   262128
early_node_map[1] active PFN ranges
    0:        0 ->   262128
On node 0 totalpages: 262128
  DMA zone: 56 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 4040 pages, LIFO batch:0
  Normal zone: 3080 pages used for memmap
  Normal zone: 222200 pages, LIFO batch:31
  HighMem zone: 447 pages used for memmap
  HighMem zone: 32305 pages, LIFO batch:7
DMI 2.3 present.
Using APIC driver default
ACPI: RSDP 000F76F0, 0014 (r0 Nvidia)
ACPI: RSDT 3FFF3040, 0034 (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
ACPI: FACP 3FFF30C0, 0074 (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
ACPI: DSDT 3FFF3180, 6264 (r1 NVIDIA AWRDACPI     1000 MSFT  100000E)
ACPI: FACS 3FFF0000, 0040
ACPI: SRAT 3FFF9500, 00A0 (r1 AMD    HAMMER          1 AMD         1)
ACPI: MCFG 3FFF9600, 003C (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
ACPI: APIC 3FFF9440, 007C (r1 Nvidia AWRDACPI 42302E31 AWRD        0)
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:3 APIC version 16
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1 15:3 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
ACPI: IRQ9 used by override.
ACPI: IRQ14 used by override.
ACPI: IRQ15 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000)
Detected 2160.240 MHz processor.
Built 1 zonelists.  Total pages: 258545
Kernel command line: root=/dev/hda1 console=ttyS0,115200 console=tty 3 debug idle=poll profile=schedule initcall_debug maxcpus=2 selinux=1 enforcing=0 apic=verbose ignore_loglevel
using polling idle threads.
kernel schedule profiling enabled (shift: 0)
debug: ignoring loglevel setting.
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
CPU 0 irqstacks, hard=c0638000 soft=c0658000
PID hash table entries: 4096 (order: 12, 16384 bytes)
spurious 8259A interrupt: IRQ7.
Console: colour VGA+ 80x25
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:    8
... MAX_LOCK_DEPTH:          30
... MAX_LOCKDEP_KEYS:        2048
... CLASSHASH_SIZE:           1024
... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      16384
... CHAINHASH_SIZE:          8192
 memory used by lock dependency info: 1096 kB
 per task-struct memory footprint: 1200 bytes
------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
                                 | spin |wlock |rlock |mutex | wsem | rsem |
  --------------------------------------------------------------------------
                     A-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                 A-B-B-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
             A-B-B-C-C-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
             A-B-C-A-B-C deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
         A-B-B-C-C-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
         A-B-C-D-B-D-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
         A-B-C-D-B-C-D-A deadlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                    double unlock:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                  initialize held:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
                 bad unlock order:  ok  |  ok  |  ok  |  ok  |  ok  |  ok  |
  --------------------------------------------------------------------------
              recursive read-lock:             |  ok  |             |  ok  |
           recursive read-lock #2:             |  ok  |             |  ok  |
            mixed read-write-lock:             |  ok  |             |  ok  |
            mixed write-read-lock:             |  ok  |             |  ok  |
  --------------------------------------------------------------------------
     hard-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
     soft-irqs-on + irq-safe-A/12:  ok  |  ok  |  ok  |
     hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
     soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
       sirq-safe-A => hirqs-on/12:  ok  |  ok  |  ok  |
       sirq-safe-A => hirqs-on/21:  ok  |  ok  |  ok  |
         hard-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
         soft-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
         hard-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
         soft-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #1/132:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #1/213:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #1/231:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #1/312:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #1/321:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #2/123:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #2/132:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #2/213:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #2/231:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #2/312:  ok  |  ok  |  ok  |
    hard-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
    soft-safe-A + unsafe-B #2/321:  ok  |  ok  |  ok  |
      hard-irq lock-inversion/123:  ok  |  ok  |  ok  |
      soft-irq lock-inversion/123:  ok  |  ok  |  ok  |
      hard-irq lock-inversion/132:  ok  |  ok  |  ok  |
      soft-irq lock-inversion/132:  ok  |  ok  |  ok  |
      hard-irq lock-inversion/213:  ok  |  ok  |  ok  |
      soft-irq lock-inversion/213:  ok  |  ok  |  ok  |
      hard-irq lock-inversion/231:  ok  |  ok  |  ok  |
      soft-irq lock-inversion/231:  ok  |  ok  |  ok  |
      hard-irq lock-inversion/312:  ok  |  ok  |  ok  |
      soft-irq lock-inversion/312:  ok  |  ok  |  ok  |
      hard-irq lock-inversion/321:  ok  |  ok  |  ok  |
      soft-irq lock-inversion/321:  ok  |  ok  |  ok  |
      hard-irq read-recursion/123:  ok  |
      soft-irq read-recursion/123:  ok  |
      hard-irq read-recursion/132:  ok  |
      soft-irq read-recursion/132:  ok  |
      hard-irq read-recursion/213:  ok  |
      soft-irq read-recursion/213:  ok  |
      hard-irq read-recursion/231:  ok  |
      soft-irq read-recursion/231:  ok  |
      hard-irq read-recursion/312:  ok  |
      soft-irq read-recursion/312:  ok  |
      hard-irq read-recursion/321:  ok  |
      soft-irq read-recursion/321:  ok  |
-------------------------------------------------------
Good, all 218 testcases passed! |
---------------------------------
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1010344k/1048512k available (3282k kernel code, 37492k reserved, 1710k data, 308k init, 131008k highmem)
virtual kernel memory layout:
    fixmap  : 0xffc56000 - 0xfffff000   (3748 kB)
    pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
    vmalloc : 0xf8800000 - 0xff7fe000   ( 111 MB)
    lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
      .init : 0xc05e6000 - 0xc0633000   ( 308 kB)
      .data : 0xc0434b9a - 0xc05e04f0   (1710 kB)
      .text : 0xc0100000 - 0xc0434b9a   (3282 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 4322.31 BogoMIPS (lpj=2161157)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 0(2) -> Core 0
CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000003
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Checking 'hlt' instruction... OK.
lockdep: not fixing up alternatives.
ACPI: Core revision 20070126
CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
enabled ExtINT on CPU#0
lockdep: not fixing up alternatives.
Booting processor 1/1 eip 3000
CPU 1 irqstacks, hard=c0639000 soft=c0659000
Initializing CPU#1
masked ExtINT on CPU#1
Calibrating delay using timer specific routine.. 4319.78 BogoMIPS (lpj=2159892)
CPU: After generic identify, caps: 178bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000003
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU 1(2) -> Core 1
CPU: After all inits, caps: 178bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000003
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
Total of 2 processors activated (8642.09 BogoMIPS).
ENABLING IO-APIC IRQs
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
Using local APIC timer interrupts.
calibrating APIC timer ...
... lapic delta = 1349919
... PM timer delta = 357899
... PM timer result ok
..... delta 1349919
..... mult: 57987393
..... calibration result: 215987
..... CPU clock speed is 2159.0869 MHz.
..... host bus clock speed is 215.0987 MHz.
... verify APIC timer
... jiffies delta = 100
... PM timer delta = 357896
... PM timer result ok
Brought up 2 CPUs
migration_cost=151
Calling initcall 0xc06069f6: init_cpufreq_transition_notifier_list+0x0/0x11()
Calling initcall 0xc05ee584: cpufreq_tsc+0x0/0x11()
Calling initcall 0xc05f0ec1: acpisleep_dmi_init+0x0/0x11()
Calling initcall 0xc05f1097: reboot_init+0x0/0x11()
Calling initcall 0xc05f618a: print_banner+0x0/0xd()
Booting paravirtualized kernel on bare hardware
Calling initcall 0xc05f7973: sysctl_init+0x0/0x13()
Calling initcall 0xc05f7fda: helper_init+0x0/0x25()
Calling initcall 0xc05f83ef: pm_init+0x0/0x22()
Calling initcall 0xc05f8411: pm_disk_init+0x0/0x14()
Calling initcall 0xc05f883b: ksysfs_init+0x0/0x22()
Calling initcall 0xc05faa40: filelock_init+0x0/0x37()
Calling initcall 0xc05fb3d1: init_misc_binfmt+0x0/0x33()
Calling initcall 0xc05fb404: init_script_binfmt+0x0/0xf()
Calling initcall 0xc05fb413: init_elf_binfmt+0x0/0xf()
Calling initcall 0xc05fbdb5: debugfs_init+0x0/0x3d()
Calling initcall 0xc05fc2aa: securityfs_init+0x0/0x3d()
Calling initcall 0xc05fd128: random32_init+0x0/0x42()
Calling initcall 0xc0606a07: cpufreq_core_init+0x0/0x56()
Calling initcall 0xc0608c0e: sock_init+0x0/0x5f()
Calling initcall 0xc06094bc: netlink_proto_init+0x0/0x12a()
NET: Registered protocol family 16
Calling initcall 0xc05fd04f: kobject_uevent_init+0x0/0x3c()
Calling initcall 0xc05fd280: pcibus_class_init+0x0/0xf()
Calling initcall 0xc05fd7ea: pci_driver_init+0x0/0xf()
Calling initcall 0xc05fde19: backlight_class_init+0x0/0xf()
Calling initcall 0xc06013dd: tty_class_init+0x0/0x23()
Calling initcall 0xc0601a90: vtconsole_class_init+0x0/0xb5()
Calling initcall 0xc05eedeb: mtrr_if_init+0x0/0x57()
Calling initcall 0xc05f0f87: ffh_cstate_init+0x0/0x2c()
initcall at 0xc05f0f87: ffh_cstate_init+0x0/0x2c(): returned with error code -1
Calling initcall 0xc05fd985: acpi_pci_init+0x0/0x29()
ACPI: bus type pci registered
Calling initcall 0xc05ff37b: init_acpi_device_notify+0x0/0x45()
Calling initcall 0xc06076b3: pci_access_init+0x0/0x41()
PCI: Using MMCONFIG
PCI: No mmconfig possible on device 00:18
Calling initcall 0xc05edea0: request_standard_resources+0x0/0x2d0()
Setting up standard PCI resources
Calling initcall 0xc05ee25a: topology_init+0x0/0x2f()
Calling initcall 0xc05eeb91: mtrr_init_finialize+0x0/0x2c()
Calling initcall 0xc05f7de0: param_sysfs_init+0x0/0x175()
Calling initcall 0xc0151535: pm_sysrq_init+0x0/0x17()
Calling initcall 0xc05fb0bb: init_bio+0x0/0xfc()
Calling initcall 0xc05fce58: genhd_device_init+0x0/0x50()
Calling initcall 0xc05fd9ae: fbmem_init+0x0/0x87()
Calling initcall 0xc05ff17c: acpi_init+0x0/0x1ff()
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
Calling initcall 0xc05ff3c0: acpi_scan_init+0x0/0xfc()
Calling initcall 0xc05ff561: acpi_ec_init+0x0/0x55()
Calling initcall 0xc05ff8a5: acpi_pci_root_init+0x0/0x25()
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI: Transparent bridge - 0000:00:09.0
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
Calling initcall 0xc05ff99e: acpi_pci_link_init+0x0/0x43()
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK2] (IRQs *3 4 5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LMAC] (IRQs *3 4 5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LSID] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LFID] (IRQs 3 4 *5 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LPCA] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled.
ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0
ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0
ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled.
ACPI: PCI Interrupt Link [APC5] (IRQs *16), disabled.
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0
ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22 23) *0
ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled.
ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0
ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0
ACPI: PCI Interrupt Link [APCP] (IRQs 20 21 22 23) *0, disabled.
Calling initcall 0xc05ffa78: acpi_power_init+0x0/0x69()
Calling initcall 0xc05ffc44: acpi_system_init+0x0/0xad()
Calling initcall 0xc05ffcf1: acpi_event_init+0x0/0x38()
Calling initcall 0xc05ffd29: acpi_cm_sbs_init+0x0/0x7()
Calling initcall 0xc05ffd30: pnp_init+0x0/0x1c()
Linux Plug and Play Support v0.97 (c) Adam Belay
Calling initcall 0xc05ffe83: pnpacpi_init+0x0/0x69()
pnp: PnP ACPI init
pnp: PnP ACPI: found 16 devices
Calling initcall 0xc06017f8: misc_init+0x0/0x79()
Calling initcall 0xc02a5eb4: cn_init+0x0/0xb8()
Calling initcall 0xc0604701: init_scsi+0x0/0x8f()
SCSI subsystem initialized
Calling initcall 0xc0604e63: ata_init+0x0/0x6c()
libata version 2.20 loaded.
Calling initcall 0xc0605aa5: init_pcmcia_cs+0x0/0x31()
Calling initcall 0xc0605f76: usb_init+0x0/0x103()
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Calling initcall 0xc0606309: serio_init+0x0/0x8d()
Calling initcall 0xc06066e3: input_init+0x0/0x101()
Calling initcall 0xc0606a87: leds_init+0x0/0x23()
Calling initcall 0xc060740d: dma_bus_init+0x0/0x23()
Calling initcall 0xc060820c: pci_acpi_init+0x0/0x9b()
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
number of MP IRQ sources: 16.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 00000000
.......    : physical APIC id: 00
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00170011
.......     : max redirection entries: 0017
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 003 03  0    0    0   0   0    1    1    31
 01 003 03  1    0    0   0   0    1    1    39
 02 003 03  0    0    0   0   0    1    1    41
 03 003 03  1    0    0   0   0    1    1    49
 04 003 03  1    0    0   0   0    1    1    51
 05 003 03  1    0    0   0   0    1    1    59
 06 003 03  1    0    0   0   0    1    1    61
 07 003 03  1    0    0   0   0    1    1    69
 08 003 03  1    0    0   0   0    1    1    71
 09 003 03  0    1    0   0   0    1    1    79
 0a 003 03  1    0    0   0   0    1    1    81
 0b 003 03  1    0    0   0   0    1    1    89
 0c 003 03  1    0    0   0   0    1    1    91
 0d 003 03  1    0    0   0   0    1    1    99
 0e 003 03  0    0    0   0   0    1    1    A1
 0f 003 03  0    0    0   0   0    1    1    A9
 10 000 00  1    0    0   0   0    0    0    00
 11 000 00  1    0    0   0   0    0    0    00
 12 000 00  1    0    0   0   0    0    0    00
 13 000 00  1    0    0   0   0    0    0    00
 14 000 00  1    0    0   0   0    0    0    00
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ0 -> 0:0
IRQ1 -> 0:1
IRQ2 -> 0:2
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
Calling initcall 0xc06082a7: pci_legacy_init+0x0/0x105()
Calling initcall 0xc0608740: pcibios_irq_init+0x0/0x452()
Calling initcall 0xc0608b92: pcibios_init+0x0/0x7c()
Calling initcall 0xc0608cc3: proto_init+0x0/0x2e()
Calling initcall 0xc0608e13: net_dev_init+0x0/0x200()
Calling initcall 0xc060927d: wireless_nlevent_init+0x0/0x39()
Calling initcall 0xc06092b6: fib_rules_init+0x0/0xf()
Calling initcall 0xc06093ac: pktsched_init+0x0/0x91()
Calling initcall 0xc060944c: tc_filter_init+0x0/0x38()
Calling initcall 0xc0609484: tc_action_init+0x0/0x38()
Calling initcall 0xc06095e6: genl_init+0x0/0x9f()
Calling initcall 0xc060a7a9: cipso_v4_init+0x0/0x76()
Calling initcall 0xc060ab56: netlbl_init+0x0/0x71()
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
Calling initcall 0xc05fa9ca: init_pipe_fs+0x0/0x3f()
Calling initcall 0xc05ffe0c: pnp_system_init+0x0/0xf()
pnp: 00:01: ioport range 0x4000-0x407f has been reserved
pnp: 00:01: ioport range 0x4080-0x40ff has been reserved
pnp: 00:01: ioport range 0x4400-0x447f has been reserved
pnp: 00:01: ioport range 0x4480-0x44ff has been reserved
pnp: 00:01: ioport range 0x4800-0x487f has been reserved
pnp: 00:01: ioport range 0x4880-0x48ff has been reserved
pnp: 00:0e: iomem range 0xe0000000-0xefffffff has been reserved
pnp: 00:0f: iomem range 0xf0000-0xf3fff could not be reserved
pnp: 00:0f: iomem range 0xf4000-0xf7fff could not be reserved
pnp: 00:0f: iomem range 0xf8000-0xfbfff could not be reserved
pnp: 00:0f: iomem range 0xfc000-0xfffff could not be reserved
Calling initcall 0xc06012f8: chr_dev_init+0x0/0x86()
Calling initcall 0xc0602e67: firmware_class_init+0x0/0x66()
Calling initcall 0xc0605ad6: init_pcmcia_bus+0x0/0x76()
Calling initcall 0xc0606a5d: cpufreq_gov_performance_init+0x0/0xf()
Calling initcall 0xc0606a6c: cpufreq_gov_userspace_init+0x0/0x1b()
Calling initcall 0xc0607430: pcibios_assign_resources+0x0/0x92()
PCI: Bridge: 0000:00:09.0
  IO window: a000-afff
  MEM window: da000000-da0fffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0b.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0c.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0d.0
  IO window: disabled.
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:0e.0
  IO window: 9000-9fff
  MEM window: d8000000-d9ffffff
  PREFETCH window: d0000000-d7ffffff
PCI: Setting latency timer of device 0000:00:09.0 to 64
PCI: Setting latency timer of device 0000:00:0b.0 to 64
PCI: Setting latency timer of device 0000:00:0c.0 to 64
PCI: Setting latency timer of device 0000:00:0d.0 to 64
PCI: Setting latency timer of device 0000:00:0e.0 to 64
Calling initcall 0xc060a1ae: inet_init+0x0/0x390()
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 65536 (order: 9, 2621440 bytes)
TCP bind hash table entries: 65536 (order: 9, 2359296 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
TCP reno registered
Calling initcall 0xc05ec1a0: populate_rootfs+0x0/0xe4()
Calling initcall 0xc05ed0fd: i8259A_init_sysfs+0x0/0x1d()
Calling initcall 0xc05ed1fd: sbf_init+0x0/0xd7()
Calling initcall 0xc05ee23d: i8237A_init_sysfs+0x0/0x1d()
Calling initcall 0xc05ee50a: init_pit_clocksource+0x0/0x63()
Calling initcall 0xc05ee5bb: init_tsc_clocksource+0x0/0xd1()
Calling initcall 0xc010ded3: cache_sysfs_init+0x0/0x4d()
Calling initcall 0xc05eeb03: thermal_throttle_init_device+0x0/0x8e()
Calling initcall 0xc05ef94b: longrun_init+0x0/0x28()
Calling initcall 0xc05efce7: speedstep_init+0x0/0x24d()
Calling initcall 0xc05eff34: speedstep_init+0x0/0x107()
Calling initcall 0xc05f15ff: apm_init+0x0/0x3c7()
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
apm: disabled - APM is not SMP safe.
Calling initcall 0xc05f2c99: init_lapic_sysfs+0x0/0x28()
Calling initcall 0xc05f3d40: ioapic_init_sysfs+0x0/0xb6()
Calling initcall 0xc05f5eb9: init_hpet_clocksource+0x0/0x5f()
Calling initcall 0xc05f6197: add_pcspkr+0x0/0x35()
Calling initcall 0xc05f7696: create_proc_profile+0x0/0x176()
Calling initcall 0xc05f7880: ioresources_init+0x0/0x39()
Calling initcall 0xc05f7986: timekeeping_init_device+0x0/0x1d()
Calling initcall 0xc05f7b4c: uid_cache_init+0x0/0x6e()
Calling initcall 0xc05f7f55: init_posix_timers+0x0/0x85()
Calling initcall 0xc05f7fff: init_posix_cpu_timers+0x0/0x51()
Calling initcall 0xc05f8075: latency_init+0x0/0x20()
Calling initcall 0xc05f80a6: init_clocksource_sysfs+0x0/0x43()
Calling initcall 0xc05f8176: init_jiffies_clocksource+0x0/0xf()
Calling initcall 0xc05f8185: init_timer_list_procfs+0x0/0x2a()
Calling initcall 0xc05f81af: clockevents_sysfs_init+0x0/0x30()
Calling initcall 0xc05f82f9: lockdep_proc_init+0x0/0x3f()
Calling initcall 0xc05f8338: init+0x0/0x74()
Calling initcall 0xc014929e: init_rttest+0x0/0x10c()
Initializing RT-Tester: OK
Calling initcall 0xc05f83ac: proc_dma_init+0x0/0x20()
Calling initcall 0xc014a405: percpu_modinit+0x0/0x65()
Calling initcall 0xc05f83cc: kallsyms_init+0x0/0x23()
Calling initcall 0xc05f84aa: snapshot_device_init+0x0/0xf()
Calling initcall 0xc05f84b9: crash_notes_memory_init+0x0/0x38()
Calling initcall 0xc05f8676: audit_init+0x0/0x10d()
audit: initializing netlink socket (disabled)
audit(1172571348.203:1): initialized
Calling initcall 0xc05f87f8: init_kprobes+0x0/0x43()
Calling initcall 0xc05f890b: relay_init+0x0/0x11()
Calling initcall 0xc05f891c: utsname_sysctl_init+0x0/0x11()
Calling initcall 0xc05f97ec: init_per_zone_pages_min+0x0/0x3c()
Calling initcall 0xc05fa169: pdflush_init+0x0/0x16()
Calling initcall 0xc05fa1a3: kswapd_init+0x0/0x26()
Calling initcall 0xc05fa1c9: setup_vmstat+0x0/0x16()
Calling initcall 0xc05fa2a9: init_emergency_pool+0x0/0x62()
highmem bounce pool size: 64 pages
Calling initcall 0xc05fa30b: procswaps_init+0x0/0x20()
Calling initcall 0xc05fa32b: hugetlb_init+0x0/0x59()
Total HugeTLB memory allocated, 0
Calling initcall 0xc05fa3ba: init_tmpfs+0x0/0xbf()
Calling initcall 0xc05fa48d: cpucache_init+0x0/0x2f()
Calling initcall 0xc05faa09: fasync_init+0x0/0x37()
Calling initcall 0xc05fafea: aio_setup+0x0/0x77()
Calling initcall 0xc05fb22d: inotify_setup+0x0/0x11()
Calling initcall 0xc05fb23e: inotify_user_setup+0x0/0xc3()
Calling initcall 0xc05fb301: eventpoll_init+0x0/0xd0()
Calling initcall 0xc05fb422: init_mbcache+0x0/0x1b()
Calling initcall 0xc05fb43d: dquot_init+0x0/0xf2()
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Calling initcall 0xc05fb52f: init_v2_quota_format+0x0/0xf()
Calling initcall 0xc05fb53e: dnotify_init+0x0/0x37()
Calling initcall 0xc05fb953: init_devpts_fs+0x0/0x30()
Calling initcall 0xc05fb983: init_ext3_fs+0x0/0x6e()
Calling initcall 0xc05fbab1: journal_init+0x0/0xd8()
Calling initcall 0xc05fbb89: init_ext2_fs+0x0/0x6e()
Calling initcall 0xc05fbc2b: init_ramfs_fs+0x0/0xf()
Calling initcall 0xc05fbc49: init_hugetlbfs_fs+0x0/0x7d()
Calling initcall 0xc05fbcc6: init_iso9660_fs+0x0/0x70()
Calling initcall 0xc05fbd97: init_nls_cp437+0x0/0xf()
Calling initcall 0xc05fbda6: init_nls_ascii+0x0/0xf()
Calling initcall 0xc05fbdf2: ipc_init+0x0/0x16()
Calling initcall 0xc05fc013: ipc_sysctl_init+0x0/0x11()
Calling initcall 0xc05fc024: init_mqueue_fs+0x0/0xc2()
Calling initcall 0xc05fc21c: key_proc_init+0x0/0x4f()
Calling initcall 0xc05fc3c8: selinux_nf_ip_init+0x0/0x57()
SELinux:  Registering netfilter hooks
Calling initcall 0xc05fc573: init_sel_fs+0x0/0x52()
Calling initcall 0xc05fc5c5: selnl_init+0x0/0x44()
Calling initcall 0xc05fc609: sel_netif_init+0x0/0x6d()
Calling initcall 0xc05fc676: aurule_init+0x0/0x46()
Calling initcall 0xc05fc6bc: crypto_algapi_init+0x0/0xc()
Calling initcall 0xc05fc6e6: cryptomgr_init+0x0/0xf()
Calling initcall 0xc05fc6f5: hmac_module_init+0x0/0xf()
Calling initcall 0xc05fc704: crypto_xcbc_module_init+0x0/0xf()
Calling initcall 0xc05fc713: init+0x0/0x4d()
Calling initcall 0xc05fc760: init+0x0/0xf()
Calling initcall 0xc05fc76f: init+0x0/0xf()
Calling initcall 0xc05fc77e: init+0x0/0xf()
Calling initcall 0xc05fc78d: init+0x0/0xf()
Calling initcall 0xc05fc79c: init+0x0/0x33()
Calling initcall 0xc05fc7cf: init+0x0/0x52()
Calling initcall 0xc05fc821: init+0x0/0x52()
Calling initcall 0xc05fc873: crypto_ecb_module_init+0x0/0xf()
Calling initcall 0xc05fc882: crypto_cbc_module_init+0x0/0xf()
Calling initcall 0xc05fc891: crypto_module_init+0x0/0xf()
Calling initcall 0xc05fc8a0: init+0x0/0x33()
Calling initcall 0xc05fc8d3: init+0x0/0xf()
Calling initcall 0xc05fc8e2: init+0x0/0xf()
Calling initcall 0xc05fc8f1: init+0x0/0x33()
Calling initcall 0xc05fc924: aes_init+0x0/0x2db()
Calling initcall 0xc05fcbff: init+0x0/0xf()
Calling initcall 0xc05fcc0e: init+0x0/0xf()
Calling initcall 0xc05fcc1d: arc4_init+0x0/0xf()
Calling initcall 0xc05fcc2c: init+0x0/0x52()
Calling initcall 0xc05fcc7e: init+0x0/0xf()
Calling initcall 0xc05fcc8d: init+0x0/0xf()
Calling initcall 0xc05fcc9c: init+0x0/0xf()
Calling initcall 0xc05fccab: michael_mic_init+0x0/0xf()
Calling initcall 0xc05fccba: init+0x0/0xf()
Calling initcall 0xc05fcea8: noop_init+0x0/0xf()
io scheduler noop registered
Calling initcall 0xc05fceb7: as_init+0x0/0xf()
io scheduler anticipatory registered
Calling initcall 0xc05fcec6: deadline_init+0x0/0xf()
io scheduler deadline registered (default)
Calling initcall 0xc05fced5: cfq_init+0x0/0xb6()
io scheduler cfq registered
Calling initcall 0xc05fcf8b: blk_trace_init+0x0/0xc4()
Calling initcall 0xc05fd1d4: audit_classes_init+0x0/0x40()
Calling initcall 0xc024643c: pci_init+0x0/0x2c()
PCI: Found disabled HT MSI Mapping on 0000:00:0b.0
PCI: Found enabled HT MSI Mapping on 0000:00:00.0
PCI: Linking AER extended capability on 0000:00:0b.0
PCI: Found disabled HT MSI Mapping on 0000:00:0c.0
PCI: Found enabled HT MSI Mapping on 0000:00:00.0
PCI: Linking AER extended capability on 0000:00:0c.0
PCI: Found disabled HT MSI Mapping on 0000:00:0d.0
PCI: Found enabled HT MSI Mapping on 0000:00:00.0
PCI: Linking AER extended capability on 0000:00:0d.0
PCI: Found disabled HT MSI Mapping on 0000:00:0e.0
PCI: Found enabled HT MSI Mapping on 0000:00:00.0
PCI: Linking AER extended capability on 0000:00:0e.0
Calling initcall 0xc05fd7f9: pci_sysfs_init+0x0/0x35()
Calling initcall 0xc05fd82e: pci_proc_init+0x0/0x5f()
Calling initcall 0xc05fd88d: pcie_portdrv_init+0x0/0x46()
PCI: Setting latency timer of device 0000:00:0b.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0b.0:pcie00]
Allocate Port Service[0000:00:0b.0:pcie03]
PCI: Setting latency timer of device 0000:00:0c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0c.0:pcie00]
Allocate Port Service[0000:00:0c.0:pcie03]
PCI: Setting latency timer of device 0000:00:0d.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0d.0:pcie00]
Allocate Port Service[0000:00:0d.0:pcie03]
PCI: Setting latency timer of device 0000:00:0e.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:0e.0:pcie00]
Allocate Port Service[0000:00:0e.0:pcie03]
Calling initcall 0xc05fd8d3: aer_service_init+0x0/0xf()
Calling initcall 0xc05fd8e2: pci_hotplug_init+0x0/0x57()
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Calling initcall 0xc05fdaca: fb_console_init+0x0/0x113()
Calling initcall 0xc05fe4de: vesafb_init+0x0/0x271()
Calling initcall 0xc05fea9c: acpi_reserve_resources+0x0/0xc8()
Calling initcall 0xc05ff854: acpi_fan_init+0x0/0x51()
ACPI: Fan [FAN] (on)
Calling initcall 0xc05ff96b: irqrouter_init_sysfs+0x0/0x33()
Calling initcall 0xc05ffae1: acpi_processor_init+0x0/0xcd()
Calling initcall 0xc05ffbae: acpi_container_init+0x0/0x45()
Calling initcall 0xc05ffbf3: acpi_thermal_init+0x0/0x51()
ACPI: Thermal Zone [THRM] (40 C)
Calling initcall 0xc0600dcc: isapnp_init+0x0/0x43f()
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Calling initcall 0xc060138c: rand_initialize+0x0/0x25()
Calling initcall 0xc0601400: tty_init+0x0/0x1c9()
Calling initcall 0xc06015c9: pty_init+0x0/0x22f()
Calling initcall 0xc0601d7e: rtc_init+0x0/0x1b7()
Real Time Clock Driver v1.12ac
Calling initcall 0xc0601f35: hpet_init+0x0/0x57()
Calling initcall 0xc0601f8c: nvram_init+0x0/0x7c()
Non-volatile memory driver v1.2
Calling initcall 0xc0602008: agp_init+0x0/0x2f()
Linux agpgart interface v0.102 (c) Dave Jones
Calling initcall 0xc060209b: agp_ali_init+0x0/0x24()
Calling initcall 0xc06020bf: agp_ati_init+0x0/0x24()
Calling initcall 0xc06020e3: agp_amdk7_init+0x0/0x24()
Calling initcall 0xc0602107: agp_amd64_init+0x0/0xa7()
Calling initcall 0xc06021ae: agp_efficeon_init+0x0/0x39()
Calling initcall 0xc06021e7: agp_intel_init+0x0/0x24()
Calling initcall 0xc060220b: agp_nvidia_init+0x0/0x24()
Calling initcall 0xc060222f: agp_sis_init+0x0/0x24()
Calling initcall 0xc0602253: agp_serverworks_init+0x0/0x24()
Calling initcall 0xc0602277: agp_via_init+0x0/0x24()
Calling initcall 0xc060229b: cn_proc_init+0x0/0x31()
Calling initcall 0xc0602714: serial8250_init+0x0/0x112()
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
�serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Calling initcall 0xc0602826: serial8250_pnp_init+0x0/0xf()
00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Calling initcall 0xc0602835: serial8250_pci_init+0x0/0x16()
Calling initcall 0xc0602e34: isa_bus_init+0x0/0x33()
Calling initcall 0xc02b39d9: topology_sysfs_init+0x0/0x3d()
Calling initcall 0xc0602ecd: rd_init+0x0/0x18d()
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
Calling initcall 0xc06030ac: loop_init+0x0/0x27a()
loop: loaded (max 8 devices)
Calling initcall 0xc0603326: init_cryptoloop+0x0/0x27()
Calling initcall 0xc060334d: e1000_init_module+0x0/0x80()
Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI
Copyright (c) 1999-2006 Intel Corporation.
Calling initcall 0xc06033cd: e100_init_module+0x0/0x5a()
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
Calling initcall 0xc0603427: tg3_init+0x0/0x16()
Calling initcall 0xc060343d: skge_init_module+0x0/0x16()
Calling initcall 0xc0603494: net_olddevs_init+0x0/0x89()
Calling initcall 0xc060351d: loopback_init+0x0/0xf()
Calling initcall 0xc060352c: init_nic+0x0/0x2c()
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.59.
ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [APCH] -> GSI 23 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:0a.0 to 64
forcedeth: using HIGHDMA
eth0: forcedeth.c: subsystem: 01043:8141 bound to 0000:00:0a.0
Calling initcall 0xc0603558: cp_init+0x0/0x16()
8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
8139cp 0000:05:07.0: This (id 10ec:8139 rev 10) is not an 8139C+ compatible chip
8139cp 0000:05:07.0: Try the "8139too" driver instead.
Calling initcall 0xc060356e: rtl8139_init_module+0x0/0x16()
8139too Fast Ethernet driver 0.9.28
ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
ACPI: PCI Interrupt 0000:05:07.0[A] -> Link [APC2] -> GSI 17 (level, low) -> IRQ 17
eth1: RealTek RTL8139 at 0xa000, 00:c0:df:03:68:5d, IRQ 17
eth1:  Identified 8139 chip type 'RTL-8139B'
Calling initcall 0xc0603584: aec62xx_ide_init+0x0/0x16()
Calling initcall 0xc060359a: ali15x3_ide_init+0x0/0x16()
Calling initcall 0xc06035b0: amd74xx_ide_init+0x0/0x16()
Calling initcall 0xc06035c6: atiixp_ide_init+0x0/0x16()
Calling initcall 0xc06035dc: cmd64x_ide_init+0x0/0x16()
Calling initcall 0xc06035f2: cs5520_ide_init+0x0/0x16()
Calling initcall 0xc0603608: cs5530_ide_init+0x0/0x16()
Calling initcall 0xc060361e: cs5535_ide_init+0x0/0x16()
Calling initcall 0xc0603634: hpt34x_ide_init+0x0/0x16()
Calling initcall 0xc060364a: hpt366_ide_init+0x0/0x16()
Calling initcall 0xc0603660: it821x_ide_init+0x0/0x16()
Calling initcall 0xc0603676: pdc202xx_ide_init+0x0/0x16()
Calling initcall 0xc060368c: pdc202new_ide_init+0x0/0x16()
Calling initcall 0xc06036a2: piix_ide_init+0x0/0xba()
Calling initcall 0xc060375c: rz1000_ide_init+0x0/0x16()
Calling initcall 0xc0603772: svwks_ide_init+0x0/0x16()
Calling initcall 0xc0603788: siimage_ide_init+0x0/0x16()
Calling initcall 0xc060379e: sis5513_ide_init+0x0/0x16()
Calling initcall 0xc06037b4: triflex_ide_init+0x0/0x16()
Calling initcall 0xc06037ca: via_ide_init+0x0/0x16()
Calling initcall 0xc0603801: generic_ide_init+0x0/0x16()
Calling initcall 0xc0603f0a: ide_init+0x0/0x8a()
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE-CK804: IDE controller at PCI slot 0000:00:06.0
NFORCE-CK804: chipset revision 242
NFORCE-CK804: not 100% native mode: will probe irqs later
NFORCE-CK804: 0000:00:06.0 (rev f2) UDMA133 controller
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: MAXTOR 6L040J2, ATA DISK drive
hdb: ST380011A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
Calling initcall 0xc06046c5: ide_generic_init+0x0/0x11()
Probing IDE interface ide1...
Calling initcall 0xc06046d6: idedisk_init+0x0/0xf()
hda: max request size: 128KiB
hda: 78177792 sectors (40027 MB) w/1818KiB Cache, CHS=65535/16/63, UDMA(133)
hda: cache flushes supported
 hda: hda1 hda2 hda3 hda4 < hda5 >
hdb: max request size: 512KiB
hdb: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hdb: cache flushes supported
 hdb: hdb1 hdb2 hdb3 < hdb5 >
Calling initcall 0xc06046e5: idefloppy_init+0x0/0x1c()
ide-floppy driver 0.99.newide
Calling initcall 0xc060495c: spi_transport_init+0x0/0x27()
Calling initcall 0xc0604983: sas_transport_init+0x0/0x9f()
Calling initcall 0xc0604a22: sas_class_init+0x0/0x3d()
Calling initcall 0xc0604a5f: ahc_linux_init+0x0/0x5c()
Calling initcall 0xc0604abb: ahd_linux_init+0x0/0x6e()
Calling initcall 0xc0604b29: aic94xx_init+0x0/0x12e()
aic94xx: Adaptec aic94xx SAS/SATA driver version 1.0.3 loaded
Calling initcall 0xc0604c57: init_sd+0x0/0xd6()
Calling initcall 0xc0604d2d: init_sg+0x0/0x12a()
Calling initcall 0xc0604ecf: ahci_init+0x0/0x16()
Calling initcall 0xc0604ee5: k2_sata_init+0x0/0x16()
Calling initcall 0xc0604efb: piix_init+0x0/0x27()
Calling initcall 0xc0604f22: pdc_ata_init+0x0/0x16()
Calling initcall 0xc0604f38: qs_ata_init+0x0/0x16()
Calling initcall 0xc0604f4e: sil_init+0x0/0x16()
Calling initcall 0xc0604f64: sil24_init+0x0/0x16()
Calling initcall 0xc0604f7a: svia_init+0x0/0x16()
Calling initcall 0xc0604f90: vsc_sata_init+0x0/0x16()
Calling initcall 0xc0604fa6: sis_init+0x0/0x16()
Calling initcall 0xc0604fbc: pdc_sata_init+0x0/0x16()
Calling initcall 0xc0604fd2: nv_init+0x0/0x16()
sata_nv 0000:00:07.0: version 3.3
ACPI: PCI Interrupt Link [APSI] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APSI] -> GSI 22 (level, low) -> IRQ 18
sata_nv 0000:00:07.0: Using ADMA mode
PCI: Setting latency timer of device 0000:00:07.0 to 64
ata1: SATA max UDMA/133 cmd 0xf881c480 ctl 0xf881c4a0 bmdma 0x0001d800 irq 18
ata2: SATA max UDMA/133 cmd 0xf881c580 ctl 0xf881c5a0 bmdma 0x0001d808 irq 18
scsi0 : sata_nv
ata1: SATA link down (SStatus 0 SControl 300)
scsi1 : sata_nv
ata2: SATA link down (SStatus 0 SControl 300)
ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 21
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [APSJ] -> GSI 21 (level, low) -> IRQ 19
sata_nv 0000:00:08.0: Using ADMA mode
PCI: Setting latency timer of device 0000:00:08.0 to 64
ata3: SATA max UDMA/133 cmd 0xf881e480 ctl 0xf881e4a0 bmdma 0x0001c400 irq 19
ata4: SATA max UDMA/133 cmd 0xf881e580 ctl 0xf881e5a0 bmdma 0x0001c408 irq 19
scsi2 : sata_nv
ata3: SATA link down (SStatus 0 SControl 300)
scsi3 : sata_nv
ata4: SATA link down (SStatus 0 SControl 300)
Calling initcall 0xc0604fe8: uli_init+0x0/0x16()
Calling initcall 0xc0604ffe: mv_init+0x0/0x16()
Calling initcall 0xc0605014: adma_ata_init+0x0/0x16()
Calling initcall 0xc060502a: ali_init+0x0/0x16()
Calling initcall 0xc0605040: amd_init+0x0/0x16()
Calling initcall 0xc0605056: artop_init+0x0/0x16()
Calling initcall 0xc060506c: atiixp_init+0x0/0x16()
Calling initcall 0xc0605082: cmd64x_init+0x0/0x16()
Calling initcall 0xc0605098: cs5520_init+0x0/0x16()
Calling initcall 0xc06050ae: cs5530_init+0x0/0x16()
Calling initcall 0xc06050c4: cs5535_init+0x0/0x16()
Calling initcall 0xc06050da: cy82c693_init+0x0/0x16()
Calling initcall 0xc06050f0: efar_init+0x0/0x16()
Calling initcall 0xc0605106: hpt36x_init+0x0/0x16()
Calling initcall 0xc060511c: hpt37x_init+0x0/0x16()
Calling initcall 0xc0605132: hpt3x2n_init+0x0/0x16()
Calling initcall 0xc0605148: hpt3x3_init+0x0/0x16()
Calling initcall 0xc060515e: isapnp_init+0x0/0xf()
Calling initcall 0xc060516d: it821x_init+0x0/0x16()
Calling initcall 0xc0605183: jmicron_init+0x0/0x16()
Calling initcall 0xc0605199: netcell_init+0x0/0x16()
Calling initcall 0xc06051af: ns87410_init+0x0/0x16()
Calling initcall 0xc06051c5: opti_init+0x0/0x16()
Calling initcall 0xc06051db: optidma_init+0x0/0x16()
Calling initcall 0xc06051f1: marvell_init+0x0/0x16()
Calling initcall 0xc0605207: mpiix_init+0x0/0x16()
Calling initcall 0xc060521d: oldpiix_init+0x0/0x16()
Calling initcall 0xc0605233: pcmcia_init+0x0/0xf()
Calling initcall 0xc0605242: pdc2027x_init+0x0/0x16()
Calling initcall 0xc0605258: pdc202xx_init+0x0/0x16()
Calling initcall 0xc0605451: qdi_init+0x0/0x247()
Calling initcall 0xc0605698: radisys_init+0x0/0x16()
Calling initcall 0xc06056ae: rz1000_init+0x0/0x16()
Calling initcall 0xc06056c4: sc1200_init+0x0/0x16()
Calling initcall 0xc06056da: serverworks_init+0x0/0x16()
Calling initcall 0xc06056f0: sil680_init+0x0/0x16()
Calling initcall 0xc0605706: via_init+0x0/0x16()
Calling initcall 0xc060571c: sl82c105_init+0x0/0x16()
Calling initcall 0xc0605732: winbond_init+0x0/0x331()
Calling initcall 0xc0605a63: sis_init+0x0/0x16()
Calling initcall 0xc0605a79: triflex_init+0x0/0x16()
Calling initcall 0xc0605a8f: ata_generic_init+0x0/0x16()
Calling initcall 0xc0605bb8: nonstatic_sysfs_init+0x0/0xf()
Calling initcall 0xc0605bc7: yenta_socket_init+0x0/0x16()
Calling initcall 0xc0605bdd: kvm_init+0x0/0xd6()
Calling initcall 0xc0605cd7: vmx_init+0x0/0x11()
kvm: no hardware support
initcall at 0xc0605cd7: vmx_init+0x0/0x11(): returned with error code -95
Calling initcall 0xc0605dad: svm_init+0x0/0x11()
has_svm: svm not available
kvm: no hardware support
initcall at 0xc0605dad: svm_init+0x0/0x11(): returned with error code -95
Calling initcall 0xc060619b: mon_init+0x0/0x90()
Calling initcall 0xc06062db: usb_usual_init+0x0/0x2e()
usbcore: registered new interface driver libusual
Calling initcall 0xc0606396: i8042_init+0x0/0x321()
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
Calling initcall 0xc06066b7: serport_init+0x0/0x2c()
Calling initcall 0xc06067e4: mousedev_init+0x0/0xbc()
mice: PS/2 mouse device common for all mice
Calling initcall 0xc06068a0: evdev_init+0x0/0xf()
Calling initcall 0xc06068af: atkbd_init+0x0/0x16()
Calling initcall 0xc06068c5: psmouse_init+0x0/0x59()
input: AT Translated Set 2 keyboard as /class/input/input0
Calling initcall 0xc060691e: md_init+0x0/0xd8()
Calling initcall 0xc0606aaa: ledtrig_ide_init+0x0/0x16()
Calling initcall 0xc0606f79: efivars_init+0x0/0x191()
Calling initcall 0xc060710a: init_cyclone_clocksource+0x0/0x17c()
Calling initcall 0xc060729a: init_acpi_pm_clocksource+0x0/0x173()
Calling initcall 0xc06090ef: flow_cache_init+0x0/0x160()
Calling initcall 0xc06092c5: llc_init+0x0/0x53()
Calling initcall 0xc0609318: snap_init+0x0/0x2c()
Calling initcall 0xc0609344: rif_init+0x0/0x68()
Calling initcall 0xc060943d: blackhole_module_init+0x0/0xf()
Calling initcall 0xc060974e: nfnetlink_init+0x0/0x52()
Netfilter messages via NETLINK v0.30.
Calling initcall 0xc06097a0: nfnetlink_queue_init+0x0/0x88()
Calling initcall 0xc0609828: nfnetlink_log_init+0x0/0x8d()
Calling initcall 0xc060a784: init_syncookies+0x0/0x16()
Calling initcall 0xc0414dd7: ipv4_netfilter_init+0x0/0xf()
Calling initcall 0xc060a79a: bictcp_register+0x0/0xf()
TCP bic registered
Calling initcall 0xc060a9dd: xfrm_user_init+0x0/0x49()
Initializing XFRM netlink socket
Calling initcall 0xc060aa26: af_unix_init+0x0/0x64()
NET: Registered protocol family 1
Calling initcall 0xc060aa8a: packet_init+0x0/0x4c()
NET: Registered protocol family 17
Calling initcall 0xc060aad6: ipsec_pfkey_init+0x0/0x80()
NET: Registered protocol family 15
Calling initcall 0xc05ee9cb: amd_exit_cpu+0x0/0x11()
Calling initcall 0xc05eea0f: nsc_exit_cpu+0x0/0x11()
Calling initcall 0xc05ee9ed: cyrix_exit_cpu+0x0/0x11()
Calling initcall 0xc05eea31: centaur_exit_cpu+0x0/0x11()
Calling initcall 0xc05eea53: transmeta_exit_cpu+0x0/0x11()
Calling initcall 0xc05eea86: rise_exit_cpu+0x0/0x11()
Calling initcall 0xc05eeaa8: nexgen_exit_cpu+0x0/0x11()
Calling initcall 0xc05eeaca: umc_exit_cpu+0x0/0x11()
Calling initcall 0xc05ef229: powernow_init+0x0/0x10a()
Calling initcall 0xc011191d: powernowk8_init+0x0/0x78()
powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ processors (version 2.00.00)
powernow-k8: MP systems not supported by PSB BIOS structure
powernow-k8: MP systems not supported by PSB BIOS structure
Calling initcall 0xc05f003b: centrino_init+0x0/0x9e()
Calling initcall 0xc05f3aac: init_lapic_nmi_sysfs+0x0/0x33()
Calling initcall 0xc05f387b: check_nmi_watchdog+0x0/0x20a()
Calling initcall 0xc05f3d26: io_apic_bug_finalize+0x0/0x1a()
Calling initcall 0xc05f6bd4: print_ipi_mode+0x0/0x2d()
Using IPI No-Shortcut mode
Calling initcall 0xc05f8095: clocksource_done_booting+0x0/0x11()
Calling initcall 0xc014e8aa<6>Time: acpi_pm clocksource has been installed.
: software_resume+0x0/0x123()
initcall at 0xc014e8aa: software_resume+0x0/0x123(): returned with error code -2
Calling initcall 0xc0433184: debugfs_kprobe_init+0x0/0x56()
Calling initcall 0xc05f8941: taskstats_init+0x0/0x46()
Calling initcall 0xc05f9175: fail_page_alloc_debugfs+0x0/0x8f()
Calling initcall 0xc05fa4cd: failslab_debugfs+0x0/0x59()
Calling initcall 0xc05fcd31: fail_make_request_debugfs+0x0/0x14()
Calling initcall 0xc05fd16a: random32_reseed+0x0/0x4f()
Calling initcall 0xc0278ff8: acpi_poweroff_init+0x0/0x50()
Calling initcall 0xc05fef2e: acpi_wakeup_device_init+0x0/0x9c()
Calling initcall 0xc0279e25: acpi_sleep_proc_init+0x0/0x61()
Calling initcall 0xc060137e: seqgen_init+0x0/0xe()
Calling initcall 0xc0602949: early_uart_console_switch+0x0/0x7d()
Calling initcall 0xc0604e57: wait_scan_init+0x0/0xc()
Calling initcall 0xc0609f5c: tcp_congestion_default+0x0/0xf()
input: ImPS/2 Generic Wheel Mouse as /class/input/input1
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 308k freed
Write protecting the kernel read-only data: 1254k
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
EXT3 FS on hda1, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
audit(1172567767.742:2): audit_pid=1725 old=0 by auid=4294967295 subj=kernel

Fedora Core release 4 (Stentz)
Kernel 2.6.21-rc1-syslet-v5 on an i686

neptune login: NETDEV WATCHDOG: eth1: transmit timed out
eth1: Got tx_timeout. irq: 00000000
eth1: Ring at 37f82000
eth1: Dumping tx registers
  0: 00000000 000000ff 00000003 020a03ca 00000000 00000000 00000000 00000000
 20: 06255300 ff701365 00000000 00000000 00000000 00000000 00000000 00000000
 40: 0420e20e 0000a855 00002e20 00000000 00000000 00000000 00000000 00000000
 60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 80: 003b0f3c 00000001 00000000 007f0028 0000061c 00000001 00000000 00007fb4
 a0: 0014050f 00000016 dcd41300 00001241 005e0001 00000100 ffffffff 0000ffff
 c0: 10000002 00000001 00000001 00000001 00000001 00000001 00000001 00000001
 e0: 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001
100: 37f82800 37f82000 007f00ff 00008000 00010032 00000000 0000000b 37f82800
120: 37f820e0 00000000 00000000 37f87494 8000061c 37f8280c 37f8200c 0fe08000
140: 00304120 80002600 00000000 00000000 00000000 00000000 00000000 00000000
160: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
180: 00000016 00000008 0994796d 00008103 0000012a 00007800 0994000f 00000003
1a0: 00000016 00000008 0994796d 00008103 0000012a 00007800 0994000f 00000003
1c0: 00000016 00000008 0994796d 00008103 0000012a 00007800 0994000f 00000003
1e0: 00000016 00000008 0994796d 00008103 0000012a 00007800 0994000f 00000003
200: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
220: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
240: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
260: 00000000 00000000 fe020001 00000100 00000000 00000000 7e020001 00000100
eth1: Dumping tx ring
000: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
004: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
008: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
00c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
010: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
014: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
018: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
01c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
020: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
024: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
028: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
02c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
030: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
034: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
038: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
03c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
040: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
044: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
048: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
04c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
050: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
054: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
058: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
05c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
060: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
064: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
068: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
06c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
070: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
074: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
078: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
07c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
080: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
084: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
088: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
08c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
090: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
094: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
098: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
09c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0a0: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0a4: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0a8: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0ac: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0b0: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0b4: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0b8: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0bc: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0c0: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0c4: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0c8: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0cc: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0d0: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0d4: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0d8: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0dc: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0e0: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0e4: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0e8: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0ec: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0f0: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0f4: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0f8: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0fc: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
eth1: tx_timeout: dead entries!
NETDEV WATCHDOG: eth1: transmit timed out
eth1: Got tx_timeout. irq: 00000000
eth1: Ring at 37f82000
eth1: Dumping tx registers
  0: 00000000 000000ff 00000003 007903ca 00000000 00000000 00000000 00000000
 20: 06255300 ff701365 00000000 00000000 00000000 00000000 00000000 00000000
 40: 0420e20e 0000a855 00002e20 00000000 00000000 00000000 00000000 00000000
 60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 80: 003b0f3c 00000001 00000000 007f0028 0000061c 00000001 00000000 00007fb4
 a0: 0014050f 00000016 dcd41300 00001241 005e0001 00000100 ffffffff 0000ffff
 c0: 10000002 00000001 00000001 00000001 00000001 00000001 00000001 00000001
 e0: 00000001 00000001 00000001 00000001 00000001 00000001 00000001 00000001
100: 37f82800 37f82000 007f00ff 00008000 00010032 00000000 00000022 37f82800
120: 37f820e0 00000000 00000000 37f87494 8000061c 37f8280c 37f8200c 0fe08000
140: 00304120 80002600 00000000 00000000 00000000 00000000 00000000 00000000
160: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
180: 00000016 00000008 0994796d 00008103 0000012a 00007800 0994000f 00000003
1a0: 00000016 00000008 0994796d 00008103 0000012a 00007800 0994000f 00000003
1c0: 00000016 00000008 0994796d 00008103 0000012a 00007800 0994000f 00000003
1e0: 00000016 00000008 0994796d 00008103 0000012a 00007800 0994000f 00000003
200: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
220: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
240: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
260: 00000000 00000000 fe020001 00000100 00000000 00000000 7e020001 00000100
eth1: Dumping tx ring
000: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
004: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
008: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
00c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
010: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
014: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
018: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
01c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
020: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
024: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
028: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
02c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
030: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
034: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
038: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
03c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
040: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
044: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
048: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
04c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
050: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
054: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
058: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
05c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
060: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
064: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
068: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
06c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
070: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
074: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
078: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
07c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
080: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
084: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
088: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
08c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
090: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
094: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
098: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
09c: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0a0: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0a4: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0a8: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0ac: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0b0: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0b4: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0b8: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0bc: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0c0: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0c4: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0c8: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0cc: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0d0: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0d4: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0d8: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0dc: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0e0: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0e4: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0e8: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0ec: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0f0: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0f4: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0f8: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
0fc: 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000 // 00000000 00000000 00000000
eth1: tx_timeout: dead entries!

Re: regression: forcedeth.c hang

[Ingo Molnar]

update: Jeff sent me 3 pending forcedeth.c fixes, and they indeed fix 
the regression. The one that fixed it is:

----------------->
The napi poll routine was missing the call to the optimized rx process 
routine. This patch adds the missing call for the optimized path.

Signed-Off-By: Ayaz Abdulla <aabdulla@nvidia.com>

--- orig/drivers/net/forcedeth.c	2007-02-20 03:17:21.000000000 -0500
+++ new/drivers/net/forcedeth.c	2007-02-20 03:28:31.000000000 -0500
@@ -3104,13 +3104,17 @@
 	struct fe_priv *np = netdev_priv(dev);
 	u8 __iomem *base = get_hwbase(dev);
 	unsigned long flags;
+	int retcode;
 
-	if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2)
+	if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
 		pkts = nv_rx_process(dev, limit);
-	else
+		retcode = nv_alloc_rx(dev);
+	} else {
 		pkts = nv_rx_process_optimized(dev, limit);
+		retcode = nv_alloc_rx_optimized(dev);
+	}
 
-	if (nv_alloc_rx(dev)) {
+	if (retcode) {
 		spin_lock_irqsave(&np->lock, flags);
 		if (!np->in_shutdown)
 			mod_timer(&np->oom_kick, jiffies + OOM_REFILL);

Re: regression: forcedeth.c hang

[Linus Torvalds]

On Tue, 27 Feb 2007, Ingo Molnar wrote:
> 
> update: Jeff sent me 3 pending forcedeth.c fixes, and they indeed fix 
> the regression. The one that fixed it is:

Ok, that was included in the bunch I just pulled and pushed out, so 
hopefully this one is resolved. Pls verify.

		Linus

Re: regression: forcedeth.c hang

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, 27 Feb 2007, Ingo Molnar wrote:
> > 
> > update: Jeff sent me 3 pending forcedeth.c fixes, and they indeed 
> > fix the regression. The one that fixed it is:
> 
> Ok, that was included in the bunch I just pulled and pushed out, so 
> hopefully this one is resolved. Pls verify.

yep, can confirm that it's now fixed upstream too.

	Ingo

RE: 2.6.21-rc1: known regressions (part 1)

[Karasyov, Konstantin A]

[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]

Arkadiusz,

Could try the attached patch to see if it solves the problem?
If not, please send the output of acpidump command and log.

Regards.
Konstantin.

>-----Original Message-----
>From: Adrian Bunk [mailto:bunk@stusta.de]
>Sent: Sunday, February 25, 2007 8:53 PM
>To: Linus Torvalds; Andrew Morton
>Cc: Linux Kernel Mailing List; Pavel Machek; Marcel Holtmann; linux-
>pm@lists.osdl.org; Michael S. Tsirkin; Ingo Molnar; lenb@kernel.org;
linux-
>acpi@vger.kernel.org; Yu, Luming; Arkadiusz Miskiewicz; Karasyov,
>Konstantin A; linux-usb-devel@lists.sourceforge.net; Thomas Meyer;
Andrew;
>Janosch Machowinski; Lebedev, Vladimir P; Lukas Hejtmanek;
>jgarzik@pobox.com; linux-ide@vger.kernel.org; Meelis Roos; Alan Cox;
Fabio
>Comolli; Jean-Luc Coulon; Markus Trippelsdorf; Tejun Heo; Rafael J.
Wysocki
>Subject: 2.6.21-rc1: known regressions (part 1)
>
>This email lists some known regressions in 2.6.21-rc1 compared to
2.6.20
>that are not yet fixed in Linus' tree.
>
>If you find your name in the Cc header, you are either submitter of one
>of the bugs, maintainer of an affectected subsystem or driver, a patch
>of you caused a breakage or I'm considering you in any other way
possibly
>involved with one or more of these issues.
>
>Due to the huge amount of recipients, please trim the Cc when
answering.
>
>
>Subject    : HP nx6325 notebook: usb mouse stops working after suspend
to
>ram
>References : http://lkml.org/lkml/2007/2/21/413
>Submitter  : Arkadiusz Miskiewicz <arekm@maven.pl>
>Caused-By  : Konstantin Karasyov <konstantin.a.karasyov@intel.com>
>             commit 0a6139027f3986162233adc17285151e78b39cac
>Status     : unknown
>
>


[-- Attachment #2: usb_power.patch --]
[-- Type: application/octet-stream, Size: 1443 bytes --]

diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index 1ef3385..866c8e7 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -436,8 +436,6 @@ int acpi_power_transition(struct acpi_device *device, int state)
 	cl = &device->power.states[device->power.state].resources;
 	tl = &device->power.states[state].resources;
 
-	device->power.state = ACPI_STATE_UNKNOWN;
-
 	if (!cl->count && !tl->count) {
 		result = -ENODEV;
 		goto end;
@@ -468,12 +466,15 @@ int acpi_power_transition(struct acpi_device *device, int state)
 			goto end;
 	}
 
-	/* We shouldn't change the state till all above operations succeed */
-	device->power.state = state;
-      end:
-	if (result)
+     end:
+	if (result) {
+		device->power.state = ACPI_STATE_UNKNOWN;
 		printk(KERN_WARNING PREFIX "Transitioning device [%s] to D%d\n",
 			      device->pnp.bus_id, state);
+	} else {
+	/* We shouldn't change the state till all above operations succeed */
+ 		device->power.state = state;
+	}
 
 	return result;
 }
@@ -690,7 +691,8 @@ static int acpi_power_resume(struct acpi_device *device)
 	if ((resource->state == ACPI_POWER_RESOURCE_STATE_ON) &&
 	    list_empty(&resource->reference)) {
 		mutex_unlock(&resource->resource_lock);
-		result = acpi_power_off_device(device->handle, NULL);
+//		result = acpi_power_off_device(device->handle, NULL);
+printk("RESUME: power resource %s found to be OFF\n", device->pnp.bus_id);
 		return result;
 	}
 

RE: 2.6.21-rc1: known regressions (part 1)

[Karasyov, Konstantin A]

[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]

Arkadiusz,

Could try the attached patch to see if it solves the problem?
If not, please send the output of acpidump command and log.

Regards.
Konstantin.

>-----Original Message-----
>From: Adrian Bunk [mailto:bunk@stusta.de]
>Sent: Sunday, February 25, 2007 8:53 PM
>To: Linus Torvalds; Andrew Morton
>Cc: Linux Kernel Mailing List; Pavel Machek; Marcel Holtmann; linux-
>pm@lists.osdl.org; Michael S. Tsirkin; Ingo Molnar; lenb@kernel.org;
linux-
>acpi@vger.kernel.org; Yu, Luming; Arkadiusz Miskiewicz; Karasyov,
>Konstantin A; linux-usb-devel@lists.sourceforge.net; Thomas Meyer;
Andrew;
>Janosch Machowinski; Lebedev, Vladimir P; Lukas Hejtmanek;
>jgarzik@pobox.com; linux-ide@vger.kernel.org; Meelis Roos; Alan Cox;
Fabio
>Comolli; Jean-Luc Coulon; Markus Trippelsdorf; Tejun Heo; Rafael J.
Wysocki
>Subject: 2.6.21-rc1: known regressions (part 1)
>
>This email lists some known regressions in 2.6.21-rc1 compared to
2.6.20
>that are not yet fixed in Linus' tree.
>
>If you find your name in the Cc header, you are either submitter of one
>of the bugs, maintainer of an affectected subsystem or driver, a patch
>of you caused a breakage or I'm considering you in any other way
possibly
>involved with one or more of these issues.
>
>Due to the huge amount of recipients, please trim the Cc when
answering.
>
>
>Subject    : HP nx6325 notebook: usb mouse stops working after suspend
to
>ram
>References : http://lkml.org/lkml/2007/2/21/413
>Submitter  : Arkadiusz Miskiewicz <arekm@maven.pl>
>Caused-By  : Konstantin Karasyov <konstantin.a.karasyov@intel.com>
>             commit 0a6139027f3986162233adc17285151e78b39cac
>Status     : unknown
>
>


[-- Attachment #2: usb_power.patch --]
[-- Type: application/octet-stream, Size: 1443 bytes --]

diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index 1ef3385..866c8e7 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -436,8 +436,6 @@ int acpi_power_transition(struct acpi_device *device, int state)
 	cl = &device->power.states[device->power.state].resources;
 	tl = &device->power.states[state].resources;
 
-	device->power.state = ACPI_STATE_UNKNOWN;
-
 	if (!cl->count && !tl->count) {
 		result = -ENODEV;
 		goto end;
@@ -468,12 +466,15 @@ int acpi_power_transition(struct acpi_device *device, int state)
 			goto end;
 	}
 
-	/* We shouldn't change the state till all above operations succeed */
-	device->power.state = state;
-      end:
-	if (result)
+     end:
+	if (result) {
+		device->power.state = ACPI_STATE_UNKNOWN;
 		printk(KERN_WARNING PREFIX "Transitioning device [%s] to D%d\n",
 			      device->pnp.bus_id, state);
+	} else {
+	/* We shouldn't change the state till all above operations succeed */
+ 		device->power.state = state;
+	}
 
 	return result;
 }
@@ -690,7 +691,8 @@ static int acpi_power_resume(struct acpi_device *device)
 	if ((resource->state == ACPI_POWER_RESOURCE_STATE_ON) &&
 	    list_empty(&resource->reference)) {
 		mutex_unlock(&resource->resource_lock);
-		result = acpi_power_off_device(device->handle, NULL);
+//		result = acpi_power_off_device(device->handle, NULL);
+printk("RESUME: power resource %s found to be OFF\n", device->pnp.bus_id);
 		return result;
 	}
 

2.6.21-rc1: known regressions (part 2)

[Adrian Bunk]

This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
             (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
             Thomas Gleixner <tglx@linutronix.de>
Handled-By : Ingo Molnar <mingo@elte.hu>
Status     : unknown


Subject    : kernel BUG at kernel/time/tick-sched.c:168  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged


Subject    : BUG: soft lockup detected on CPU#0
             NOHZ: local_softirq_pending 20
References : http://lkml.org/lkml/2007/2/20/257
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
Status     : problem is being debugged


Subject    : i386: no boot with nmi_watchdog=1  (clockevents)
References : http://lkml.org/lkml/2007/2/21/208
Submitter  : Daniel Walker <dwalker@mvista.com>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged

2.6.21-rc1: known regressions (part 2)

[Adrian Bunk]

This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
             (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
             Thomas Gleixner <tglx@linutronix.de>
Handled-By : Ingo Molnar <mingo@elte.hu>
Status     : unknown


Subject    : kernel BUG at kernel/time/tick-sched.c:168  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged


Subject    : BUG: soft lockup detected on CPU#0
             NOHZ: local_softirq_pending 20
References : http://lkml.org/lkml/2007/2/20/257
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
Status     : problem is being debugged


Subject    : i386: no boot with nmi_watchdog=1  (clockevents)
References : http://lkml.org/lkml/2007/2/21/208
Submitter  : Daniel Walker <dwalker@mvista.com>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged

Re: 2.6.21-rc1: known regressions (part 2)

[Jens Axboe]

On Sun, Feb 25 2007, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> that are not yet fixed in Linus' tree.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way possibly
> involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.
> 
> 
> Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
>              (CONFIG_NO_HZ)
> References : http://lkml.org/lkml/2007/2/22/391
> Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
>              Thomas Gleixner <tglx@linutronix.de>
> Handled-By : Ingo Molnar <mingo@elte.hu>
> Status     : unknown

x60 doesn't resume from S2R either, it doesn't matter if CONFIG_NO_HZ is
set or not though. 2.6.20 worked fine.

-- 
Jens Axboe

Re: 2.6.21-rc1: known regressions (part 2)

[Jens Axboe]

On Sun, Feb 25 2007, Adrian Bunk wrote:
> This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> that are not yet fixed in Linus' tree.
> 
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way possibly
> involved with one or more of these issues.
> 
> Due to the huge amount of recipients, please trim the Cc when answering.
> 
> 
> Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
>              (CONFIG_NO_HZ)
> References : http://lkml.org/lkml/2007/2/22/391
> Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
>              Thomas Gleixner <tglx@linutronix.de>
> Handled-By : Ingo Molnar <mingo@elte.hu>
> Status     : unknown

x60 doesn't resume from S2R either, it doesn't matter if CONFIG_NO_HZ is
set or not though. 2.6.20 worked fine.

-- 
Jens Axboe

Re: 2.6.21-rc1: known regressions (part 2)

[Pavel Machek]

Hi!

> > This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> > that are not yet fixed in Linus' tree.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way possibly
> > involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
> >              (CONFIG_NO_HZ)
> > References : http://lkml.org/lkml/2007/2/22/391
> > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> >              Thomas Gleixner <tglx@linutronix.de>
> > Handled-By : Ingo Molnar <mingo@elte.hu>
> > Status     : unknown
> 
> x60 doesn't resume from S2R either, it doesn't matter if CONFIG_NO_HZ is
> set or not though. 2.6.20 worked fine.

It somehow works for me. As long as I do not play with bluetooth and
suspend to disk...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.21-rc1: known regressions (part 2)

[Pavel Machek]

Hi!

> > This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> > that are not yet fixed in Linus' tree.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way possibly
> > involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
> >              (CONFIG_NO_HZ)
> > References : http://lkml.org/lkml/2007/2/22/391
> > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> >              Thomas Gleixner <tglx@linutronix.de>
> > Handled-By : Ingo Molnar <mingo@elte.hu>
> > Status     : unknown
> 
> x60 doesn't resume from S2R either, it doesn't matter if CONFIG_NO_HZ is
> set or not though. 2.6.20 worked fine.

It somehow works for me. As long as I do not play with bluetooth and
suspend to disk...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.21-rc1: known regressions (part 2)

[Jens Axboe]

On Tue, Feb 27 2007, Pavel Machek wrote:
> Hi!
> 
> > > This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> > > that are not yet fixed in Linus' tree.
> > > 
> > > If you find your name in the Cc header, you are either submitter of one
> > > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > > of you caused a breakage or I'm considering you in any other way possibly
> > > involved with one or more of these issues.
> > > 
> > > Due to the huge amount of recipients, please trim the Cc when answering.
> > > 
> > > 
> > > Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
> > >              (CONFIG_NO_HZ)
> > > References : http://lkml.org/lkml/2007/2/22/391
> > > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> > >              Thomas Gleixner <tglx@linutronix.de>
> > > Handled-By : Ingo Molnar <mingo@elte.hu>
> > > Status     : unknown
> > 
> > x60 doesn't resume from S2R either, it doesn't matter if CONFIG_NO_HZ is
> > set or not though. 2.6.20 worked fine.
> 
> It somehow works for me. As long as I do not play with bluetooth and
> suspend to disk...

It locks solid here on resume, going back to 2.6.20 makes it work
perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change broke
resume, but that got fixed. Some other change later snuck in that broke
it AGAIN for me, sigh.

I don't use bluetooth nor suspend to disk.

-- 
Jens Axboe

Re: 2.6.21-rc1: known regressions (part 2)

[Jens Axboe]

On Tue, Feb 27 2007, Pavel Machek wrote:
> Hi!
> 
> > > This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> > > that are not yet fixed in Linus' tree.
> > > 
> > > If you find your name in the Cc header, you are either submitter of one
> > > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > > of you caused a breakage or I'm considering you in any other way possibly
> > > involved with one or more of these issues.
> > > 
> > > Due to the huge amount of recipients, please trim the Cc when answering.
> > > 
> > > 
> > > Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
> > >              (CONFIG_NO_HZ)
> > > References : http://lkml.org/lkml/2007/2/22/391
> > > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> > >              Thomas Gleixner <tglx@linutronix.de>
> > > Handled-By : Ingo Molnar <mingo@elte.hu>
> > > Status     : unknown
> > 
> > x60 doesn't resume from S2R either, it doesn't matter if CONFIG_NO_HZ is
> > set or not though. 2.6.20 worked fine.
> 
> It somehow works for me. As long as I do not play with bluetooth and
> suspend to disk...

It locks solid here on resume, going back to 2.6.20 makes it work
perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change broke
resume, but that got fixed. Some other change later snuck in that broke
it AGAIN for me, sigh.

I don't use bluetooth nor suspend to disk.

-- 
Jens Axboe

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Jens Axboe <jens.axboe@oracle.com> wrote:

> > > x60 doesn't resume from S2R either, it doesn't matter if 
> > > CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
> > 
> > It somehow works for me. As long as I do not play with bluetooth and 
> > suspend to disk...
> 
> It locks solid here on resume, going back to 2.6.20 makes it work 
> perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change 
> broke resume, but that got fixed. Some other change later snuck in 
> that broke it AGAIN for me, sigh.
> 
> I don't use bluetooth nor suspend to disk.

resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works 
fine? Do you know a commit ID that works for sure? I'd like to bisect 
this, but this way i might just find that ACPI change that got already 
fixed later on (and then got re-broken).

	Ingo

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Jens Axboe <jens.axboe@oracle.com> wrote:

> > > x60 doesn't resume from S2R either, it doesn't matter if 
> > > CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
> > 
> > It somehow works for me. As long as I do not play with bluetooth and 
> > suspend to disk...
> 
> It locks solid here on resume, going back to 2.6.20 makes it work 
> perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change 
> broke resume, but that got fixed. Some other change later snuck in 
> that broke it AGAIN for me, sigh.
> 
> I don't use bluetooth nor suspend to disk.

resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works 
fine? Do you know a commit ID that works for sure? I'd like to bisect 
this, but this way i might just find that ACPI change that got already 
fixed later on (and then got re-broken).

	Ingo

Re: 2.6.21-rc1: known regressions (part 2)

[Jens Axboe]

On Tue, Feb 27 2007, Ingo Molnar wrote:
> 
> * Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > > > x60 doesn't resume from S2R either, it doesn't matter if 
> > > > CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
> > > 
> > > It somehow works for me. As long as I do not play with bluetooth and 
> > > suspend to disk...
> > 
> > It locks solid here on resume, going back to 2.6.20 makes it work 
> > perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change 
> > broke resume, but that got fixed. Some other change later snuck in 
> > that broke it AGAIN for me, sigh.
> > 
> > I don't use bluetooth nor suspend to disk.
> 
> resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works 
> fine? Do you know a commit ID that works for sure? I'd like to bisect 

Nope, 2.6.21-rc1 vanilla does not work. 2.6.20 works. 2.6.20-gitX worked
until some acpi change broke it, the below patch fixed that for me. That
got merged in a later 2.6.20-gitY, but then some other patch broke it
again so that 2.6.21-rc1 is broken. Not much luck there :-)

So it looks like:

- c5a7156959e89b32260ad6072bbf5077bcdfbeee broke 2.6.20-git
- f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 should fix that.
- Something later than f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 broke it
  again.

> this, but this way i might just find that ACPI change that got already 
> fixed later on (and then got re-broken).

Yeah, it gets trickier. I'll try
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 now and see if that works, then
bisect to 2.6.21-rc1 to find the other offender. I hope the other
offender didn't get added before
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38, we'll see :-)

-- 
Jens Axboe

Re: 2.6.21-rc1: known regressions (part 2)

[Jens Axboe]

On Tue, Feb 27 2007, Ingo Molnar wrote:
> 
> * Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > > > x60 doesn't resume from S2R either, it doesn't matter if 
> > > > CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
> > > 
> > > It somehow works for me. As long as I do not play with bluetooth and 
> > > suspend to disk...
> > 
> > It locks solid here on resume, going back to 2.6.20 makes it work 
> > perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change 
> > broke resume, but that got fixed. Some other change later snuck in 
> > that broke it AGAIN for me, sigh.
> > 
> > I don't use bluetooth nor suspend to disk.
> 
> resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works 
> fine? Do you know a commit ID that works for sure? I'd like to bisect 

Nope, 2.6.21-rc1 vanilla does not work. 2.6.20 works. 2.6.20-gitX worked
until some acpi change broke it, the below patch fixed that for me. That
got merged in a later 2.6.20-gitY, but then some other patch broke it
again so that 2.6.21-rc1 is broken. Not much luck there :-)

So it looks like:

- c5a7156959e89b32260ad6072bbf5077bcdfbeee broke 2.6.20-git
- f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 should fix that.
- Something later than f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 broke it
  again.

> this, but this way i might just find that ACPI change that got already 
> fixed later on (and then got re-broken).

Yeah, it gets trickier. I'll try
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 now and see if that works, then
bisect to 2.6.21-rc1 to find the other offender. I hope the other
offender didn't get added before
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38, we'll see :-)

-- 
Jens Axboe

Re: 2.6.21-rc1: known regressions (part 2)

[Jens Axboe]

On Tue, Feb 27 2007, Jens Axboe wrote:
> On Tue, Feb 27 2007, Ingo Molnar wrote:
> > 
> > * Jens Axboe <jens.axboe@oracle.com> wrote:
> > 
> > > > > x60 doesn't resume from S2R either, it doesn't matter if 
> > > > > CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
> > > > 
> > > > It somehow works for me. As long as I do not play with bluetooth and 
> > > > suspend to disk...
> > > 
> > > It locks solid here on resume, going back to 2.6.20 makes it work 
> > > perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change 
> > > broke resume, but that got fixed. Some other change later snuck in 
> > > that broke it AGAIN for me, sigh.
> > > 
> > > I don't use bluetooth nor suspend to disk.
> > 
> > resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works 
> > fine? Do you know a commit ID that works for sure? I'd like to bisect 
> 
> Nope, 2.6.21-rc1 vanilla does not work. 2.6.20 works. 2.6.20-gitX worked
> until some acpi change broke it, the below patch fixed that for me. That
> got merged in a later 2.6.20-gitY, but then some other patch broke it
> again so that 2.6.21-rc1 is broken. Not much luck there :-)
> 
> So it looks like:
> 
> - c5a7156959e89b32260ad6072bbf5077bcdfbeee broke 2.6.20-git
> - f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 should fix that.
> - Something later than f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 broke it
>   again.
> 
> > this, but this way i might just find that ACPI change that got already 
> > fixed later on (and then got re-broken).
> 
> Yeah, it gets trickier. I'll try
> f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 now and see if that works, then
> bisect to 2.6.21-rc1 to find the other offender. I hope the other
> offender didn't get added before
> f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38, we'll see :-)

f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, starting bisect.

-- 
Jens Axboe

Re: 2.6.21-rc1: known regressions (part 2)

[Jens Axboe]

On Tue, Feb 27 2007, Jens Axboe wrote:
> On Tue, Feb 27 2007, Ingo Molnar wrote:
> > 
> > * Jens Axboe <jens.axboe@oracle.com> wrote:
> > 
> > > > > x60 doesn't resume from S2R either, it doesn't matter if 
> > > > > CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
> > > > 
> > > > It somehow works for me. As long as I do not play with bluetooth and 
> > > > suspend to disk...
> > > 
> > > It locks solid here on resume, going back to 2.6.20 makes it work 
> > > perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change 
> > > broke resume, but that got fixed. Some other change later snuck in 
> > > that broke it AGAIN for me, sigh.
> > > 
> > > I don't use bluetooth nor suspend to disk.
> > 
> > resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works 
> > fine? Do you know a commit ID that works for sure? I'd like to bisect 
> 
> Nope, 2.6.21-rc1 vanilla does not work. 2.6.20 works. 2.6.20-gitX worked
> until some acpi change broke it, the below patch fixed that for me. That
> got merged in a later 2.6.20-gitY, but then some other patch broke it
> again so that 2.6.21-rc1 is broken. Not much luck there :-)
> 
> So it looks like:
> 
> - c5a7156959e89b32260ad6072bbf5077bcdfbeee broke 2.6.20-git
> - f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 should fix that.
> - Something later than f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 broke it
>   again.
> 
> > this, but this way i might just find that ACPI change that got already 
> > fixed later on (and then got re-broken).
> 
> Yeah, it gets trickier. I'll try
> f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 now and see if that works, then
> bisect to 2.6.21-rc1 to find the other offender. I hope the other
> offender didn't get added before
> f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38, we'll see :-)

f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, starting bisect.

-- 
Jens Axboe

Re: 2.6.21-rc1: known regressions (part 2)

[Jens Axboe]

On Tue, Feb 27 2007, Jens Axboe wrote:
> On Tue, Feb 27 2007, Jens Axboe wrote:
> > On Tue, Feb 27 2007, Ingo Molnar wrote:
> > > 
> > > * Jens Axboe <jens.axboe@oracle.com> wrote:
> > > 
> > > > > > x60 doesn't resume from S2R either, it doesn't matter if 
> > > > > > CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
> > > > > 
> > > > > It somehow works for me. As long as I do not play with bluetooth and 
> > > > > suspend to disk...
> > > > 
> > > > It locks solid here on resume, going back to 2.6.20 makes it work 
> > > > perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change 
> > > > broke resume, but that got fixed. Some other change later snuck in 
> > > > that broke it AGAIN for me, sigh.
> > > > 
> > > > I don't use bluetooth nor suspend to disk.
> > > 
> > > resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works 
> > > fine? Do you know a commit ID that works for sure? I'd like to bisect 
> > 
> > Nope, 2.6.21-rc1 vanilla does not work. 2.6.20 works. 2.6.20-gitX worked
> > until some acpi change broke it, the below patch fixed that for me. That
> > got merged in a later 2.6.20-gitY, but then some other patch broke it
> > again so that 2.6.21-rc1 is broken. Not much luck there :-)
> > 
> > So it looks like:
> > 
> > - c5a7156959e89b32260ad6072bbf5077bcdfbeee broke 2.6.20-git
> > - f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 should fix that.
> > - Something later than f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 broke it
> >   again.
> > 
> > > this, but this way i might just find that ACPI change that got already 
> > > fixed later on (and then got re-broken).
> > 
> > Yeah, it gets trickier. I'll try
> > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 now and see if that works, then
> > bisect to 2.6.21-rc1 to find the other offender. I hope the other
> > offender didn't get added before
> > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38, we'll see :-)
> 
> f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, starting bisect.

Which got me nowhere, after bisecting down from 1213 revisions to
nothing. f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 certainly works, just
verified again. Trying only acpi related changes now...

-- 
Jens Axboe

Re: 2.6.21-rc1: known regressions (part 2)

[Jens Axboe]

On Tue, Feb 27 2007, Jens Axboe wrote:
> On Tue, Feb 27 2007, Jens Axboe wrote:
> > On Tue, Feb 27 2007, Ingo Molnar wrote:
> > > 
> > > * Jens Axboe <jens.axboe@oracle.com> wrote:
> > > 
> > > > > > x60 doesn't resume from S2R either, it doesn't matter if 
> > > > > > CONFIG_NO_HZ is set or not though. 2.6.20 worked fine.
> > > > > 
> > > > > It somehow works for me. As long as I do not play with bluetooth and 
> > > > > suspend to disk...
> > > > 
> > > > It locks solid here on resume, going back to 2.6.20 makes it work 
> > > > perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change 
> > > > broke resume, but that got fixed. Some other change later snuck in 
> > > > that broke it AGAIN for me, sigh.
> > > > 
> > > > I don't use bluetooth nor suspend to disk.
> > > 
> > > resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works 
> > > fine? Do you know a commit ID that works for sure? I'd like to bisect 
> > 
> > Nope, 2.6.21-rc1 vanilla does not work. 2.6.20 works. 2.6.20-gitX worked
> > until some acpi change broke it, the below patch fixed that for me. That
> > got merged in a later 2.6.20-gitY, but then some other patch broke it
> > again so that 2.6.21-rc1 is broken. Not much luck there :-)
> > 
> > So it looks like:
> > 
> > - c5a7156959e89b32260ad6072bbf5077bcdfbeee broke 2.6.20-git
> > - f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 should fix that.
> > - Something later than f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 broke it
> >   again.
> > 
> > > this, but this way i might just find that ACPI change that got already 
> > > fixed later on (and then got re-broken).
> > 
> > Yeah, it gets trickier. I'll try
> > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 now and see if that works, then
> > bisect to 2.6.21-rc1 to find the other offender. I hope the other
> > offender didn't get added before
> > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38, we'll see :-)
> 
> f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, starting bisect.

Which got me nowhere, after bisecting down from 1213 revisions to
nothing. f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 certainly works, just
verified again. Trying only acpi related changes now...

-- 
Jens Axboe

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Jens Axboe <jens.axboe@oracle.com> wrote:

> f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]

update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and 
01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt 
to bisect this.

	Ingo

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Jens Axboe <jens.axboe@oracle.com> wrote:

> f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]

update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and 
01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt 
to bisect this.

	Ingo

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and 
> 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt 
> to bisect this.

hm. There's some weird bisection artifact here. Here are the commits i 
tested, in git-log order:

#1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
#2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad
#3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good
#4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad

if i tell git-bisect that #1 is bad and #3 is good, then it offers me #2 
- that's OK. But when i tell it that #2 is bad, it offers #4 - which is 
out of order! The bisection goes off into la-la land after that and 
never gets back to a commit that is /after/ the good commit. How is this 
possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure this isnt 
some git bug that's already fixed.)

i'll try to straighten this out manually, perhaps #3 is in some merge 
branch that confuses bisection. Or maybe i misunderstood how git-bisect 
works.

	Ingo

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and 
> 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt 
> to bisect this.

hm. There's some weird bisection artifact here. Here are the commits i 
tested, in git-log order:

#1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
#2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad
#3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good
#4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad

if i tell git-bisect that #1 is bad and #3 is good, then it offers me #2 
- that's OK. But when i tell it that #2 is bad, it offers #4 - which is 
out of order! The bisection goes off into la-la land after that and 
never gets back to a commit that is /after/ the good commit. How is this 
possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure this isnt 
some git bug that's already fixed.)

i'll try to straighten this out manually, perhaps #3 is in some merge 
branch that confuses bisection. Or maybe i misunderstood how git-bisect 
works.

	Ingo

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> hm. There's some weird bisection artifact here. Here are the commits i 
> tested, in git-log order:
> 
> #1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
> #2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad
> #3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good
> #4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad
> 
> if i tell git-bisect that #1 is bad and #3 is good, then it offers me 
> #2 - that's OK. But when i tell it that #2 is bad, it offers #4 - 
> which is out of order! The bisection goes off into la-la land after 
> that and never gets back to a commit that is /after/ the good commit. 
> How is this possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure 
> this isnt some git bug that's already fixed.)
> 
> i'll try to straighten this out manually, perhaps #3 is in some merge 
> branch that confuses bisection. Or maybe i misunderstood how 
> git-bisect works.

git-bisect gets royally confused on those ACPI merge branches around 
commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe. Here are my test 
results so far:

 commit 01363220f5d23ef68276db8974e46a502e43d01d: bad
 commit 255f0385c8e0d6b9005c0e09fffb5bd852f3b506: bad
 commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe: bad
 commit c24e912b61b1ab2301c59777134194066b06465c: good
 commit e9e2cdb412412326c4827fc78ba27f410d837e6e: bad
 commit 79bf2bb335b85db25d27421c798595a2fa2a0e82: bad
 commit fc955f670c0a66aca965605dae797e747b2bef7d: good
 commit 70c0846e430881967776582e13aefb81407919f1: good
 commit 414f827c46973ba39320cfb43feb55a0eeb9b4e8: bad
 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38: good
 commit 5f0b1437e0708772b6fecae5900c01c3b5f9b512: bad
 commit b878ca5d37953ad1c4578b225a13a3c3e7e743b7: bad
 commit c2902c8ae06762d941fab64198467f78cab6f8cd: bad
 commit 12e74f7d430655f541b85018ea62bcd669094bd7: bad
 commit 3388c37e04ec0e35ebc1b4c732fdefc9ea938f3b: bad
 commit 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff: bad

the results are totally reproducible (i re-tried a few of both the good 
and the bad commits), i.e. it's not a sporadic condition. Also, a number 
of the 'bad' commits have no dynticks stuff in them at all, so i'd 
exclude dynticks.

could someone suggest a sane way to go with this? Perhaps suggest 
specific commit IDs to test?

	Ingo

Re: 2.6.21-rc1: known regressions (part 2)

[Rafael J. Wysocki]

On Thursday, 1 March 2007 15:52, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > hm. There's some weird bisection artifact here. Here are the commits i 
> > tested, in git-log order:
> > 
> > #1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
> > #2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad
> > #3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good
> > #4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad
> > 
> > if i tell git-bisect that #1 is bad and #3 is good, then it offers me 
> > #2 - that's OK. But when i tell it that #2 is bad, it offers #4 - 
> > which is out of order! The bisection goes off into la-la land after 
> > that and never gets back to a commit that is /after/ the good commit. 
> > How is this possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure 
> > this isnt some git bug that's already fixed.)
> > 
> > i'll try to straighten this out manually, perhaps #3 is in some merge 
> > branch that confuses bisection. Or maybe i misunderstood how 
> > git-bisect works.
> 
> git-bisect gets royally confused on those ACPI merge branches around 
> commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe. Here are my test 
> results so far:
> 
>  commit 01363220f5d23ef68276db8974e46a502e43d01d: bad
>  commit 255f0385c8e0d6b9005c0e09fffb5bd852f3b506: bad
>  commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe: bad
>  commit c24e912b61b1ab2301c59777134194066b06465c: good
>  commit e9e2cdb412412326c4827fc78ba27f410d837e6e: bad
>  commit 79bf2bb335b85db25d27421c798595a2fa2a0e82: bad
>  commit fc955f670c0a66aca965605dae797e747b2bef7d: good
>  commit 70c0846e430881967776582e13aefb81407919f1: good
>  commit 414f827c46973ba39320cfb43feb55a0eeb9b4e8: bad
>  commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38: good
>  commit 5f0b1437e0708772b6fecae5900c01c3b5f9b512: bad
>  commit b878ca5d37953ad1c4578b225a13a3c3e7e743b7: bad
>  commit c2902c8ae06762d941fab64198467f78cab6f8cd: bad
>  commit 12e74f7d430655f541b85018ea62bcd669094bd7: bad
>  commit 3388c37e04ec0e35ebc1b4c732fdefc9ea938f3b: bad
>  commit 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff: bad
> 
> the results are totally reproducible (i re-tried a few of both the good 
> and the bad commits), i.e. it's not a sporadic condition. Also, a number 
> of the 'bad' commits have no dynticks stuff in them at all, so i'd 
> exclude dynticks.
> 
> could someone suggest a sane way to go with this? Perhaps suggest 
> specific commit IDs to test?

Hm, does 2.6.20-mm2 work?  If not, you can bisect the broken-out sereis
with quilt.

Rafael

Re: 2.6.21-rc1: known regressions (part 2)

[Rafael J. Wysocki]

On Thursday, 1 March 2007 15:52, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > hm. There's some weird bisection artifact here. Here are the commits i 
> > tested, in git-log order:
> > 
> > #1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
> > #2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad
> > #3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good
> > #4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad
> > 
> > if i tell git-bisect that #1 is bad and #3 is good, then it offers me 
> > #2 - that's OK. But when i tell it that #2 is bad, it offers #4 - 
> > which is out of order! The bisection goes off into la-la land after 
> > that and never gets back to a commit that is /after/ the good commit. 
> > How is this possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure 
> > this isnt some git bug that's already fixed.)
> > 
> > i'll try to straighten this out manually, perhaps #3 is in some merge 
> > branch that confuses bisection. Or maybe i misunderstood how 
> > git-bisect works.
> 
> git-bisect gets royally confused on those ACPI merge branches around 
> commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe. Here are my test 
> results so far:
> 
>  commit 01363220f5d23ef68276db8974e46a502e43d01d: bad
>  commit 255f0385c8e0d6b9005c0e09fffb5bd852f3b506: bad
>  commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe: bad
>  commit c24e912b61b1ab2301c59777134194066b06465c: good
>  commit e9e2cdb412412326c4827fc78ba27f410d837e6e: bad
>  commit 79bf2bb335b85db25d27421c798595a2fa2a0e82: bad
>  commit fc955f670c0a66aca965605dae797e747b2bef7d: good
>  commit 70c0846e430881967776582e13aefb81407919f1: good
>  commit 414f827c46973ba39320cfb43feb55a0eeb9b4e8: bad
>  commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38: good
>  commit 5f0b1437e0708772b6fecae5900c01c3b5f9b512: bad
>  commit b878ca5d37953ad1c4578b225a13a3c3e7e743b7: bad
>  commit c2902c8ae06762d941fab64198467f78cab6f8cd: bad
>  commit 12e74f7d430655f541b85018ea62bcd669094bd7: bad
>  commit 3388c37e04ec0e35ebc1b4c732fdefc9ea938f3b: bad
>  commit 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff: bad
> 
> the results are totally reproducible (i re-tried a few of both the good 
> and the bad commits), i.e. it's not a sporadic condition. Also, a number 
> of the 'bad' commits have no dynticks stuff in them at all, so i'd 
> exclude dynticks.
> 
> could someone suggest a sane way to go with this? Perhaps suggest 
> specific commit IDs to test?

Hm, does 2.6.20-mm2 work?  If not, you can bisect the broken-out sereis
with quilt.

Rafael

Re: 2.6.21-rc1: known regressions (part 2)

[Linus Torvalds]

On Thu, 1 Mar 2007, Ingo Molnar wrote:
> 
> git-bisect gets royally confused on those ACPI merge branches around 
> commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe. Here are my test 
> results so far:

Looks like git bisect worked for you, and wasn't confused at all. You 
started out with 2931 commits between your first known-bad and known-good 
commits, which means that you usually end up having to check "log2(n)+1" 
kernels, ie I'd have expected you to have to do 12-13 bisection attempts 
to cut it down to one.

You seem to have done 14 (you list 16 commits, two of which are the 
starting points), which is right in that range. The reason you sometimes 
get more is:

 - you "help" git bisect by choosing other commits than the optimal ones. 

 - with bad luck, it can be hard to get really close to "half the commits" 
   in the reachability analysis, especially if you have lots of merges 
   (and *especially* if you have octopus merges that merge more than two 
   branches of development). For example, say that you have something like

	           a
	           |
	   +---+---+---+---+
	   |   |   |   |   |
	   b   c   d   e   f

   where you have six commits - you can't test any "combinations" at all, 
   since they are all independent, so "git bisect" cannot test them three 
   and three to cut down the time, so if you don't know which one is bad, 
   you'll basically end up testing them all.

The bad luck case never really happens to that extreme in practice, and 
even when it does you can sometimes be lucky and just hit on the bug early 
(so "bad luck" may end up being "good luck" after all), but it explains 
why you can get more - or less - than log2(n)+1 attempts. More commonly 
one more.

A much *bigger* problem is if you mark something good or bad that isn't 
really. Ie if the bug comes and goes (it might be timing-dependent, for 
example), the problem will be that you'll always narrow things down 
(that's what bisection does), but you may not narrow it down to the right 
thing!

We've had that happen several times. If the bug (for example) means that 
suspend *often* breaks, but sometimes works just by luck, you might mark a 
kernel "good" when it really wasn't and then "git bisect" will *really* go 
out in the weeds, and won't even try to test the commits that may have 
introduced the bug, because you told it that those commits resulted in a 
good kernel..

>  commit 01363220f5d23ef68276db8974e46a502e43d01d: bad
>  commit 255f0385c8e0d6b9005c0e09fffb5bd852f3b506: bad
>  commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe: bad
>  commit c24e912b61b1ab2301c59777134194066b06465c: good
>  commit e9e2cdb412412326c4827fc78ba27f410d837e6e: bad
>  commit 79bf2bb335b85db25d27421c798595a2fa2a0e82: bad
>  commit fc955f670c0a66aca965605dae797e747b2bef7d: good
>  commit 70c0846e430881967776582e13aefb81407919f1: good
>  commit 414f827c46973ba39320cfb43feb55a0eeb9b4e8: bad
>  commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38: good
>  commit 5f0b1437e0708772b6fecae5900c01c3b5f9b512: bad
>  commit b878ca5d37953ad1c4578b225a13a3c3e7e743b7: bad
>  commit c2902c8ae06762d941fab64198467f78cab6f8cd: bad
>  commit 12e74f7d430655f541b85018ea62bcd669094bd7: bad
>  commit 3388c37e04ec0e35ebc1b4c732fdefc9ea938f3b: bad
>  commit 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff: bad

Looks like it's claiming that 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff is 
the bad commit. Which is extremely unlikely, since it only seems to affect 
the emu10k sound driver, which I don't think even exists on any ThinkPad 
laptops (correct me if I'm wrong). 

Btw, you seem to have re-ordered the commits - the above is not the order 
you did the bisection in. The known-good commit (f3ccb06..) is in the 
middle. That's totally bogus. Please use the git bisection log (see 
.git/BISECT_LOG), and don't think that you know some "better" order. You 
really don't.

> the results are totally reproducible (i re-tried a few of both the good 
> and the bad commits), i.e. it's not a sporadic condition. Also, a number 
> of the 'bad' commits have no dynticks stuff in them at all, so i'd 
> exclude dynticks.
> 
> could someone suggest a sane way to go with this? Perhaps suggest 
> specific commit IDs to test?

You claim that 9f4bd5dd is bad, but you indirectly claim that its direct 
parent (5986a2ec) is good by saying that f3ccb06f is good. This is why 
"git bisect" will claim that 9f4bd5dd must be the bad commit.

I would suggest testing commit 5986a2ec explicitly. If that one is good, 
then, since you claim that 9f4bd5dd is bad, then yes, 9f4bd5dd *is* the 
bad commit (because 5986a2ec is its direct parent).

But most likely, 9f4bd5dd is actually already bad, and what you are seeing 
is two *different* bugs that just have the same symptoms ("suspend doesn't 
work").

What happens is that you've chased them *both*, and you cannot bisect that 
kind of behaviour totally automatically and mindlessly, simply because 
when you say "git bisect bad", that means that *one* of the bugs is 
active, but not necessarily both of them. So you may well be marking 
kernels that are "good" (as far as the other bug is concerned) as bad - 
and that just means that bisection won't even test them.

When that happens, you need to basically

 - be able to separate the bugs out some way (so that you can still mark a 
   non-working kernel "good" if it's good *with*respect*to* the particular 
   bug you're chasing)

   This is often practically impossible, _especially_ with suspend, where 
   the behaviour is so unhelpful that it's usually not possible to 
   separate out "ACPI is broken" from "one particular device driver is 
   broken", because they both have exactly the same symptoms: the machine 
   doesn't resume.

HOWEVER. Even if you can't actually separate the bugs out, you can usually 
find where *one* of the bugs starts, and that point you can generally find 
the fix for it too. In this case, we already know one of the bugs: it's 
the ACPI bug that was apparently fixed by f3ccb06f3 (or maybe another one 
in that series).

Once you have that, you now actually have a way to "correct" for that 
known bug, and by correcting for the known bug, you now *can* separate the 
behaviour of the two bugs:

 - You can now re-do a totally mindless git bisection for the *other* bug, 
   but what you now need to do is that at each bisection step, you look at 
   whether the bisection point has the known bug, and if so, you apply the 
   known fix for that known bug, and thus you can test the kernel 
   *without* the interaction of the bug you already found.

This makes bisection a lot less automated (you have to apply the "fix" for 
the other bug at each step), but it still allows "total automation" in the 
sense that you don't actually need to know at all what you're looking for: 
you're just following a known pattern, and you're basically just 
correcting for the effects of another bug that you're no longer interested 
in, since you already know what the fix for that bug was.

The other alternative is to actually have a clue what you're searching 
for, and/or look deeply at where the fix was merged, and trying to narrow 
things down by actually understanding the problem. But at that point, 
bisection won't much help you, except perhaps as a way to find a mid-way 
point to test out theories with ("which drivers that I actually use have 
changed in between" kinds of experiments where you simply undo part of 
the changes entirely, and bisection ends up being just a way to pick 
points that are hopefully "interestingly far apart").

			Linus

Re: 2.6.21-rc1: known regressions (part 2)

[Linus Torvalds]

On Thu, 1 Mar 2007, Ingo Molnar wrote:
> 
> git-bisect gets royally confused on those ACPI merge branches around 
> commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe. Here are my test 
> results so far:

Looks like git bisect worked for you, and wasn't confused at all. You 
started out with 2931 commits between your first known-bad and known-good 
commits, which means that you usually end up having to check "log2(n)+1" 
kernels, ie I'd have expected you to have to do 12-13 bisection attempts 
to cut it down to one.

You seem to have done 14 (you list 16 commits, two of which are the 
starting points), which is right in that range. The reason you sometimes 
get more is:

 - you "help" git bisect by choosing other commits than the optimal ones. 

 - with bad luck, it can be hard to get really close to "half the commits" 
   in the reachability analysis, especially if you have lots of merges 
   (and *especially* if you have octopus merges that merge more than two 
   branches of development). For example, say that you have something like

	           a
	           |
	   +---+---+---+---+
	   |   |   |   |   |
	   b   c   d   e   f

   where you have six commits - you can't test any "combinations" at all, 
   since they are all independent, so "git bisect" cannot test them three 
   and three to cut down the time, so if you don't know which one is bad, 
   you'll basically end up testing them all.

The bad luck case never really happens to that extreme in practice, and 
even when it does you can sometimes be lucky and just hit on the bug early 
(so "bad luck" may end up being "good luck" after all), but it explains 
why you can get more - or less - than log2(n)+1 attempts. More commonly 
one more.

A much *bigger* problem is if you mark something good or bad that isn't 
really. Ie if the bug comes and goes (it might be timing-dependent, for 
example), the problem will be that you'll always narrow things down 
(that's what bisection does), but you may not narrow it down to the right 
thing!

We've had that happen several times. If the bug (for example) means that 
suspend *often* breaks, but sometimes works just by luck, you might mark a 
kernel "good" when it really wasn't and then "git bisect" will *really* go 
out in the weeds, and won't even try to test the commits that may have 
introduced the bug, because you told it that those commits resulted in a 
good kernel..

>  commit 01363220f5d23ef68276db8974e46a502e43d01d: bad
>  commit 255f0385c8e0d6b9005c0e09fffb5bd852f3b506: bad
>  commit c0cd79d11412969b6b8fa1624cdc1277db82e2fe: bad
>  commit c24e912b61b1ab2301c59777134194066b06465c: good
>  commit e9e2cdb412412326c4827fc78ba27f410d837e6e: bad
>  commit 79bf2bb335b85db25d27421c798595a2fa2a0e82: bad
>  commit fc955f670c0a66aca965605dae797e747b2bef7d: good
>  commit 70c0846e430881967776582e13aefb81407919f1: good
>  commit 414f827c46973ba39320cfb43feb55a0eeb9b4e8: bad
>  commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38: good
>  commit 5f0b1437e0708772b6fecae5900c01c3b5f9b512: bad
>  commit b878ca5d37953ad1c4578b225a13a3c3e7e743b7: bad
>  commit c2902c8ae06762d941fab64198467f78cab6f8cd: bad
>  commit 12e74f7d430655f541b85018ea62bcd669094bd7: bad
>  commit 3388c37e04ec0e35ebc1b4c732fdefc9ea938f3b: bad
>  commit 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff: bad

Looks like it's claiming that 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff is 
the bad commit. Which is extremely unlikely, since it only seems to affect 
the emu10k sound driver, which I don't think even exists on any ThinkPad 
laptops (correct me if I'm wrong). 

Btw, you seem to have re-ordered the commits - the above is not the order 
you did the bisection in. The known-good commit (f3ccb06..) is in the 
middle. That's totally bogus. Please use the git bisection log (see 
.git/BISECT_LOG), and don't think that you know some "better" order. You 
really don't.

> the results are totally reproducible (i re-tried a few of both the good 
> and the bad commits), i.e. it's not a sporadic condition. Also, a number 
> of the 'bad' commits have no dynticks stuff in them at all, so i'd 
> exclude dynticks.
> 
> could someone suggest a sane way to go with this? Perhaps suggest 
> specific commit IDs to test?

You claim that 9f4bd5dd is bad, but you indirectly claim that its direct 
parent (5986a2ec) is good by saying that f3ccb06f is good. This is why 
"git bisect" will claim that 9f4bd5dd must be the bad commit.

I would suggest testing commit 5986a2ec explicitly. If that one is good, 
then, since you claim that 9f4bd5dd is bad, then yes, 9f4bd5dd *is* the 
bad commit (because 5986a2ec is its direct parent).

But most likely, 9f4bd5dd is actually already bad, and what you are seeing 
is two *different* bugs that just have the same symptoms ("suspend doesn't 
work").

What happens is that you've chased them *both*, and you cannot bisect that 
kind of behaviour totally automatically and mindlessly, simply because 
when you say "git bisect bad", that means that *one* of the bugs is 
active, but not necessarily both of them. So you may well be marking 
kernels that are "good" (as far as the other bug is concerned) as bad - 
and that just means that bisection won't even test them.

When that happens, you need to basically

 - be able to separate the bugs out some way (so that you can still mark a 
   non-working kernel "good" if it's good *with*respect*to* the particular 
   bug you're chasing)

   This is often practically impossible, _especially_ with suspend, where 
   the behaviour is so unhelpful that it's usually not possible to 
   separate out "ACPI is broken" from "one particular device driver is 
   broken", because they both have exactly the same symptoms: the machine 
   doesn't resume.

HOWEVER. Even if you can't actually separate the bugs out, you can usually 
find where *one* of the bugs starts, and that point you can generally find 
the fix for it too. In this case, we already know one of the bugs: it's 
the ACPI bug that was apparently fixed by f3ccb06f3 (or maybe another one 
in that series).

Once you have that, you now actually have a way to "correct" for that 
known bug, and by correcting for the known bug, you now *can* separate the 
behaviour of the two bugs:

 - You can now re-do a totally mindless git bisection for the *other* bug, 
   but what you now need to do is that at each bisection step, you look at 
   whether the bisection point has the known bug, and if so, you apply the 
   known fix for that known bug, and thus you can test the kernel 
   *without* the interaction of the bug you already found.

This makes bisection a lot less automated (you have to apply the "fix" for 
the other bug at each step), but it still allows "total automation" in the 
sense that you don't actually need to know at all what you're looking for: 
you're just following a known pattern, and you're basically just 
correcting for the effects of another bug that you're no longer interested 
in, since you already know what the fix for that bug was.

The other alternative is to actually have a clue what you're searching 
for, and/or look deeply at where the fix was merged, and trying to narrow 
things down by actually understanding the problem. But at that point, 
bisection won't much help you, except perhaps as a way to find a mid-way 
point to test out theories with ("which drivers that I actually use have 
changed in between" kinds of experiments where you simply undo part of 
the changes entirely, and bisection ends up being just a way to pick 
points that are hopefully "interestingly far apart").

			Linus

Re: 2.6.21-rc1: known regressions (part 2)

[Linus Torvalds]

On Thu, 1 Mar 2007, Linus Torvalds wrote:
> 
> Once you have that, you now actually have a way to "correct" for that 
> known bug, and by correcting for the known bug, you now *can* separate the 
> behaviour of the two bugs:
> 
>  - You can now re-do a totally mindless git bisection for the *other* bug, 
>    but what you now need to do is that at each bisection step, you look at 
>    whether the bisection point has the known bug, and if so, you apply the 
>    known fix for that known bug, and thus you can test the kernel 
>    *without* the interaction of the bug you already found.
> 
> This makes bisection a lot less automated (you have to apply the "fix" for 
> the other bug at each step)

Side note: it's still usually fairly easy. Especially if you have a known 
fix for the other bug, you can usually just do the equivalent of

	git cherry-pick <fixcommit>

at each point during this bisect (or just have a known patch that you keep 
applying and un-applying), and you're largely done.

Of course, if the area with the fix keeps changing, or if the fix is 
really intrusive and nasty, this gets hairy, but at least in this case the 
patch is fairly trivial and it shouldn't cause any trouble at all to do 
this.

The only real down-side is just the mindless extra work, and the possible 
added confusion you get from modifying the history at the points you're 
testing. "git bisect" is not necessarily happy about auto-picking a new 
bisection point with a dirty tree, for example, so before you mark 
something "good" or "bad", you should generally try to do so with a clean 
git tree (ie if you apply a patch at each stage, do "git reset --hard" to 
remove the patch before you do the "git bisect bad/good" stage).

Similarly, especially at the end of the bisection run, if you actually use 
"git cherry-pick" to *add* a commit, the bisection will now take that 
added commit into account when trying to pick the next commit to check, 
which is not what you really want. It probably doesn't matter that much 
during the early stages (when bisection is really jumping around wildly 
anyway, and one commit more or less doesn't really matter), but again, it 
might be a good idea to make a habit of undoing the cherry-pick, the same 
way you'd undo a patch (eg "git reset --hard HEAD^" would do it, if you 
have exactly one cherry-pick that you tested).

		Linus

Re: 2.6.21-rc1: known regressions (part 2)

[Linus Torvalds]

On Thu, 1 Mar 2007, Linus Torvalds wrote:
> 
> Once you have that, you now actually have a way to "correct" for that 
> known bug, and by correcting for the known bug, you now *can* separate the 
> behaviour of the two bugs:
> 
>  - You can now re-do a totally mindless git bisection for the *other* bug, 
>    but what you now need to do is that at each bisection step, you look at 
>    whether the bisection point has the known bug, and if so, you apply the 
>    known fix for that known bug, and thus you can test the kernel 
>    *without* the interaction of the bug you already found.
> 
> This makes bisection a lot less automated (you have to apply the "fix" for 
> the other bug at each step)

Side note: it's still usually fairly easy. Especially if you have a known 
fix for the other bug, you can usually just do the equivalent of

	git cherry-pick <fixcommit>

at each point during this bisect (or just have a known patch that you keep 
applying and un-applying), and you're largely done.

Of course, if the area with the fix keeps changing, or if the fix is 
really intrusive and nasty, this gets hairy, but at least in this case the 
patch is fairly trivial and it shouldn't cause any trouble at all to do 
this.

The only real down-side is just the mindless extra work, and the possible 
added confusion you get from modifying the history at the points you're 
testing. "git bisect" is not necessarily happy about auto-picking a new 
bisection point with a dirty tree, for example, so before you mark 
something "good" or "bad", you should generally try to do so with a clean 
git tree (ie if you apply a patch at each stage, do "git reset --hard" to 
remove the patch before you do the "git bisect bad/good" stage).

Similarly, especially at the end of the bisection run, if you actually use 
"git cherry-pick" to *add* a commit, the bisection will now take that 
added commit into account when trying to pick the next commit to check, 
which is not what you really want. It probably doesn't matter that much 
during the early stages (when bisection is really jumping around wildly 
anyway, and one commit more or less doesn't really matter), but again, it 
might be a good idea to make a habit of undoing the cherry-pick, the same 
way you'd undo a patch (eg "git reset --hard HEAD^" would do it, if you 
have exactly one cherry-pick that you tested).

		Linus

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Btw, you seem to have re-ordered the commits - the above is not the 
> order you did the bisection in. The known-good commit (f3ccb06..) is 
> in the middle. [...]

no - i simply picked them by hand, based on looking at gittk output, 
because bisection did not appear to find anything useful:

  9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff is first bad commit

And via that method i found a couple of more 'good' points - which 
git-bisect never picked up by itself. (and i did 3-4 separate git-bisect 
sessions, one of them was a "git-bisect start drivers/acpi/" - which is 
the main area of suspicion). I looked at git-bisect visualize more than 
once, and i've attached one of the bisection logs below.

i also think i know what happens. Firstly, my testing is reliable, as i 
mentioned it in the other mail i frequently re-visited commits to make 
sure that none of my bad/good decisions is spurios - but no, the test 
results are extremely reproducable: either the laptop resumes properly 
after flashing its disk light or it does not.

the problem i think is that i simply took git-bisect's behavior for 
granted (i used it many times already) but forgot about a very basic 
precondition: git-bisect will find only a /single/ good->bad transition.

If there is a bad->good transition combined with a good->bad transition 
then git-bisect will think it's the same 'badness', while it's a 
/former/ badness that it is honing in on - totally sending the bisection 
off into la-la-land.

so as i mentioned it in the first mail: i /know/ that this commit is a 
bad->good transition point:

  f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38

/and i only want to test commits that include this commit/ - because i 
know that without this commit git-bisect confuses the /other/ breakage 
with the new breakage. In the bisection log below, this choice of 
git-bisect:

  ee404566f97f9254433399fbbcfa05390c7c55f7

is 'bad' according to testing, but that's 'another' badness - and i 
missed it.

Now, having slept on it, the solution is very simple: whenever 
git-bisect picks a commit for which the following command comes up 
empty:
 
  git-log | grep f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38

then i'll mark it "git-bisect good" - artificially marking the older 
badness as a 'good' area. That way git-bisect will find the right 
good->bad transition point.

btw., that's why i tried to pick up commits by hand, making sure that 
commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 is always included - but 
got lost in the maze of the commit graph, and didnt realize that there 
is a simple solution. Nevertheless i wanted to dump the information i 
already gathered. Those commits were totally out of order, etc. - they 
were picked by a poor human who is much worse at walking graphs than 
git-bisect ;-)

	Ingo

git-bisect start
# bad: [01363220f5d23ef68276db8974e46a502e43d01d] [PARISC] clocksource: Move update_cr16_clocksource later in boot
git-bisect bad 01363220f5d23ef68276db8974e46a502e43d01d
# good: [f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38] ACPI: Disable wake GPEs only once.
git-bisect good f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38
# bad: [ee404566f97f9254433399fbbcfa05390c7c55f7] sysctl: mips/au1000: remove sys_sysctl support
git-bisect bad ee404566f97f9254433399fbbcfa05390c7c55f7
# bad: [c827ba4cb49a30ce581201fd0ba2be77cde412c7] Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6
git-bisect bad c827ba4cb49a30ce581201fd0ba2be77cde412c7
# bad: [68a696a01f482859a9fe937249e8b3d44252b610] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-tc
git-bisect bad 68a696a01f482859a9fe937249e8b3d44252b610
# bad: [1c433fbda4896a6455d97b66a4f2646cbdd52a8c] [ALSA] soc - 0.13 ASoC headers
git-bisect bad 1c433fbda4896a6455d97b66a4f2646cbdd52a8c
# bad: [048b945077bdc7e8dff5d5810ff2a0ced3590ca9] [ALSA] echoaudio, add TLV support
git-bisect bad 048b945077bdc7e8dff5d5810ff2a0ced3590ca9
# bad: [c07584c83287ae5a13cc836f69a1d824ad068c66] [ALSA] hda-codec - Add support for Medion laptops
git-bisect bad c07584c83287ae5a13cc836f69a1d824ad068c66
# bad: [dbc6b6ad767c86907db373e85139b0e975ba7599] [ALSA] ASoC codecs: generic AC97 support
git-bisect bad dbc6b6ad767c86907db373e85139b0e975ba7599
# bad: [b66b3cfe6c2f6560f351278883a325b6ebc478f5] [ALSA] hda_intel: increase maximum DMA buffer size to 1024MB
git-bisect bad b66b3cfe6c2f6560f351278883a325b6ebc478f5
# bad: [12b131c4cf3eb1dc8a60082a434b7b100774c2e7] [ALSA] allow registering an alsa device with struct device pointer
git-bisect bad 12b131c4cf3eb1dc8a60082a434b7b100774c2e7
# bad: [e4f8e656d8c152c08cd44d0e3c21f009fab09952] [ALSA] usb-audio: allow pausing
git-bisect bad e4f8e656d8c152c08cd44d0e3c21f009fab09952
# bad: [1700f3080d98323e91864d67cb9f6d46f818ccf0] [ALSA] usb-audio: merge playback/capture hardware information structs
git-bisect bad 1700f3080d98323e91864d67cb9f6d46f818ccf0
# bad: [9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff] [ALSA] snd-emu10k1: Added support for emu1010, including E-Mu 1212m and E-Mu 1820m
git-bisect bad 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Btw, you seem to have re-ordered the commits - the above is not the 
> order you did the bisection in. The known-good commit (f3ccb06..) is 
> in the middle. [...]

no - i simply picked them by hand, based on looking at gittk output, 
because bisection did not appear to find anything useful:

  9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff is first bad commit

And via that method i found a couple of more 'good' points - which 
git-bisect never picked up by itself. (and i did 3-4 separate git-bisect 
sessions, one of them was a "git-bisect start drivers/acpi/" - which is 
the main area of suspicion). I looked at git-bisect visualize more than 
once, and i've attached one of the bisection logs below.

i also think i know what happens. Firstly, my testing is reliable, as i 
mentioned it in the other mail i frequently re-visited commits to make 
sure that none of my bad/good decisions is spurios - but no, the test 
results are extremely reproducable: either the laptop resumes properly 
after flashing its disk light or it does not.

the problem i think is that i simply took git-bisect's behavior for 
granted (i used it many times already) but forgot about a very basic 
precondition: git-bisect will find only a /single/ good->bad transition.

If there is a bad->good transition combined with a good->bad transition 
then git-bisect will think it's the same 'badness', while it's a 
/former/ badness that it is honing in on - totally sending the bisection 
off into la-la-land.

so as i mentioned it in the first mail: i /know/ that this commit is a 
bad->good transition point:

  f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38

/and i only want to test commits that include this commit/ - because i 
know that without this commit git-bisect confuses the /other/ breakage 
with the new breakage. In the bisection log below, this choice of 
git-bisect:

  ee404566f97f9254433399fbbcfa05390c7c55f7

is 'bad' according to testing, but that's 'another' badness - and i 
missed it.

Now, having slept on it, the solution is very simple: whenever 
git-bisect picks a commit for which the following command comes up 
empty:
 
  git-log | grep f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38

then i'll mark it "git-bisect good" - artificially marking the older 
badness as a 'good' area. That way git-bisect will find the right 
good->bad transition point.

btw., that's why i tried to pick up commits by hand, making sure that 
commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 is always included - but 
got lost in the maze of the commit graph, and didnt realize that there 
is a simple solution. Nevertheless i wanted to dump the information i 
already gathered. Those commits were totally out of order, etc. - they 
were picked by a poor human who is much worse at walking graphs than 
git-bisect ;-)

	Ingo

git-bisect start
# bad: [01363220f5d23ef68276db8974e46a502e43d01d] [PARISC] clocksource: Move update_cr16_clocksource later in boot
git-bisect bad 01363220f5d23ef68276db8974e46a502e43d01d
# good: [f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38] ACPI: Disable wake GPEs only once.
git-bisect good f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38
# bad: [ee404566f97f9254433399fbbcfa05390c7c55f7] sysctl: mips/au1000: remove sys_sysctl support
git-bisect bad ee404566f97f9254433399fbbcfa05390c7c55f7
# bad: [c827ba4cb49a30ce581201fd0ba2be77cde412c7] Merge master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6
git-bisect bad c827ba4cb49a30ce581201fd0ba2be77cde412c7
# bad: [68a696a01f482859a9fe937249e8b3d44252b610] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-tc
git-bisect bad 68a696a01f482859a9fe937249e8b3d44252b610
# bad: [1c433fbda4896a6455d97b66a4f2646cbdd52a8c] [ALSA] soc - 0.13 ASoC headers
git-bisect bad 1c433fbda4896a6455d97b66a4f2646cbdd52a8c
# bad: [048b945077bdc7e8dff5d5810ff2a0ced3590ca9] [ALSA] echoaudio, add TLV support
git-bisect bad 048b945077bdc7e8dff5d5810ff2a0ced3590ca9
# bad: [c07584c83287ae5a13cc836f69a1d824ad068c66] [ALSA] hda-codec - Add support for Medion laptops
git-bisect bad c07584c83287ae5a13cc836f69a1d824ad068c66
# bad: [dbc6b6ad767c86907db373e85139b0e975ba7599] [ALSA] ASoC codecs: generic AC97 support
git-bisect bad dbc6b6ad767c86907db373e85139b0e975ba7599
# bad: [b66b3cfe6c2f6560f351278883a325b6ebc478f5] [ALSA] hda_intel: increase maximum DMA buffer size to 1024MB
git-bisect bad b66b3cfe6c2f6560f351278883a325b6ebc478f5
# bad: [12b131c4cf3eb1dc8a60082a434b7b100774c2e7] [ALSA] allow registering an alsa device with struct device pointer
git-bisect bad 12b131c4cf3eb1dc8a60082a434b7b100774c2e7
# bad: [e4f8e656d8c152c08cd44d0e3c21f009fab09952] [ALSA] usb-audio: allow pausing
git-bisect bad e4f8e656d8c152c08cd44d0e3c21f009fab09952
# bad: [1700f3080d98323e91864d67cb9f6d46f818ccf0] [ALSA] usb-audio: merge playback/capture hardware information structs
git-bisect bad 1700f3080d98323e91864d67cb9f6d46f818ccf0
# bad: [9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff] [ALSA] snd-emu10k1: Added support for emu1010, including E-Mu 1212m and E-Mu 1820m
git-bisect bad 9f4bd5dde81b5cb94e4f52f2f05825aa0422f1ff

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> But most likely, 9f4bd5dd is actually already bad, and what you are 
> seeing is two *different* bugs that just have the same symptoms 
> ("suspend doesn't work").

the situation is simpler than that: there is a /known/ bug, and i marked 
the bugfix commit as 'good'. I never met such a multiple-bugs scenario 
before and forgot that git-bisect could easily pick a tree without this 
essential bugfix and would not be able to make a distinction between the 
two types of badness.

I'll try what i've described in the previous mail: mark all bisection 
points that do not include f3ccb06f as 'good' - thus 'merging' the 
known-bad area with the first known-good commit, and thus eliminating it 
from the bisection space.

(but it might also be useful to have a "git-bisect must-include" kind of 
command that would allow this to be automated: mark a particular tree as 
an essential component of the search space.)

	Ingo

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> But most likely, 9f4bd5dd is actually already bad, and what you are 
> seeing is two *different* bugs that just have the same symptoms 
> ("suspend doesn't work").

the situation is simpler than that: there is a /known/ bug, and i marked 
the bugfix commit as 'good'. I never met such a multiple-bugs scenario 
before and forgot that git-bisect could easily pick a tree without this 
essential bugfix and would not be able to make a distinction between the 
two types of badness.

I'll try what i've described in the previous mail: mark all bisection 
points that do not include f3ccb06f as 'good' - thus 'merging' the 
known-bad area with the first known-good commit, and thus eliminating it 
from the bisection space.

(but it might also be useful to have a "git-bisect must-include" kind of 
command that would allow this to be automated: mark a particular tree as 
an essential component of the search space.)

	Ingo

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> I'll try what i've described in the previous mail: mark all bisection 
> points that do not include f3ccb06f as 'good' - thus 'merging' the 
> known-bad area with the first known-good commit, and thus eliminating 
> it from the bisection space.

this got me quite a bit further:

 git-bisect start
 git-bisect bad       01363220f5d23ef68276db8974e46a502e43d01d
 git-bisect good      f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 
 git-bisect fake-good ee404566f97f9254433399fbbcfa05390c7c55f7
 git-bisect bad       d43a338e395371733a80ec473b40baac5f74d768
 git-bisect bad       255f0385c8e0d6b9005c0e09fffb5bd852f3b506
 git-bisect fake-good f99c6bb6e2e9c35bd3dc0b1d0faa28bd6970930d
 git-bisect fake-good 0187f221e96e3436d552c0c7143f183eb82fb658
 git-bisect bad       81450b73dde07f473a4a7208b209b4c8b7251d90
 git-bisect fake-good ef29498655b18d2bfd69048e20835d19333981ab
 git-bisect fake-good 8a03d9a498eaf02c8a118752050a5154852c13bf
 git-bisect good      5c95d3f5783ab184f64b7848f0a871352c35c3cf
 git-bisect good      ecb5f7521a309cb9c5fc0832b9705cd2a03d7d45
 git-bisect good      0539771d7236b425f285652f6f297cc7939c8f9a

 81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit

[ note: by having the "git-bisect must-have-bugfix f3ccb06f" 
  functionality i mentioned in the previous mail git-bisect could
  have eliminated the fake-good steps. ]

it's not a resolution of this regression yet, because this commit is a 
merge with upstream:

|  commit 81450b73dde07f473a4a7208b209b4c8b7251d90
|  Merge: 8a03d9a... 0539771...
|  Author: Len Brown <len.brown@intel.com>
|  Date:   Fri Feb 16 18:52:41 2007 -0500
|
|      Pull misc-for-upstream into release branch

which means that the fix in Len's tree got broken by merging with 
upstream. Note: this 'upstream' in isolation is broken too, due to not 
having that essential fix from Len's tree!

So we quite likely have /two/ bugs, any of which breaks resume (which 
breakage looks the same, so no way to isolate them via testing).

I'll now try the following: i'll try to manually apply Len's fix to 
every tree that git-bisect offers me, in the hope of being able to 
isolate the /other/ bug.

[ But really, i'm not expecting any miracles because this is way out of
  league for git-bisect which really depends on only having a binary 
  space to search for. ]

	Ingo

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> I'll try what i've described in the previous mail: mark all bisection 
> points that do not include f3ccb06f as 'good' - thus 'merging' the 
> known-bad area with the first known-good commit, and thus eliminating 
> it from the bisection space.

this got me quite a bit further:

 git-bisect start
 git-bisect bad       01363220f5d23ef68276db8974e46a502e43d01d
 git-bisect good      f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 
 git-bisect fake-good ee404566f97f9254433399fbbcfa05390c7c55f7
 git-bisect bad       d43a338e395371733a80ec473b40baac5f74d768
 git-bisect bad       255f0385c8e0d6b9005c0e09fffb5bd852f3b506
 git-bisect fake-good f99c6bb6e2e9c35bd3dc0b1d0faa28bd6970930d
 git-bisect fake-good 0187f221e96e3436d552c0c7143f183eb82fb658
 git-bisect bad       81450b73dde07f473a4a7208b209b4c8b7251d90
 git-bisect fake-good ef29498655b18d2bfd69048e20835d19333981ab
 git-bisect fake-good 8a03d9a498eaf02c8a118752050a5154852c13bf
 git-bisect good      5c95d3f5783ab184f64b7848f0a871352c35c3cf
 git-bisect good      ecb5f7521a309cb9c5fc0832b9705cd2a03d7d45
 git-bisect good      0539771d7236b425f285652f6f297cc7939c8f9a

 81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit

[ note: by having the "git-bisect must-have-bugfix f3ccb06f" 
  functionality i mentioned in the previous mail git-bisect could
  have eliminated the fake-good steps. ]

it's not a resolution of this regression yet, because this commit is a 
merge with upstream:

|  commit 81450b73dde07f473a4a7208b209b4c8b7251d90
|  Merge: 8a03d9a... 0539771...
|  Author: Len Brown <len.brown@intel.com>
|  Date:   Fri Feb 16 18:52:41 2007 -0500
|
|      Pull misc-for-upstream into release branch

which means that the fix in Len's tree got broken by merging with 
upstream. Note: this 'upstream' in isolation is broken too, due to not 
having that essential fix from Len's tree!

So we quite likely have /two/ bugs, any of which breaks resume (which 
breakage looks the same, so no way to isolate them via testing).

I'll now try the following: i'll try to manually apply Len's fix to 
every tree that git-bisect offers me, in the hope of being able to 
isolate the /other/ bug.

[ But really, i'm not expecting any miracles because this is way out of
  league for git-bisect which really depends on only having a binary 
  space to search for. ]

	Ingo

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> I'll now try the following: i'll try to manually apply Len's fix to 
> every tree that git-bisect offers me, in the hope of being able to 
> isolate the /other/ bug.
> 
> [ But really, i'm not expecting any miracles because this is way out of
>   league for git-bisect which really depends on only having a binary 
>   space to search for. ]

this method pointed out the real bug that we are interested in:

| 774c47f1d78e373a6bd2964f4e278d1ce26c21cb is first bad commit
| commit 774c47f1d78e373a6bd2964f4e278d1ce26c21cb
| Author: Avi Kivity <avi@qumranet.com>
| Date:   Mon Feb 12 00:54:47 2007 -0800
|     [PATCH] KVM: cpu hotplug support

undoing the 774c47f1 patch from HEAD gave me a working resume. I'll send 
a fix for this KVM breakage in a separate mail.

here's how the bisection went:

 bad:   [01363220f5d23ef68276db8974e46a502e43d01d] [PARISC] clocksource:
 good:  [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20
 +good: [bcdb81ae29091f6a66369aabfd8324e4a53d05dc] knfsd: SUNRPC: add a
 bad:   [920841d8d1d61bc12b43f95a579a5374f6d98f81] Merge branch 'for-linus'
 +bad:  [86a71dbd3e81e8870d0f0e56b87875f57e58222b] sysctl: hide the sysctl
 +bad:  [719c91ccadd3ed26570dbb29d54166914832eee9] [POWERPC] Use udbg_early
 +bad:  [ebaf0c6032f525ddb0158fb59848d41899dce8cd] Merge branch 'for-linus'
 +good: [8cd133073f9b5cd335c0b2e4740aceb025d50ca9] kvm: Fix mismatch between
 +bad:  [5b8e8ee6c65a34d8aafaeb8e2eaa97e496c2567c] ps3: add shutdown to
 +bad:  [a524d946bdced73c5fbe60170fb33611491c4211] tgafb: sync-on-green
 +bad:  [a268422de8bf1b4c0cb97987b6c329c9f6a3da4b] fbdev driver for S3
 +good: [8d0be2b3bf4a55606967d7d84e56c52521e94333] KVM: VMX: add vcpu_clear()
 +bad:  [59ae6c6b87711ceb2d1ea5f9e08bb13aee947a29] KVM: Host suspend/resume
 +bad:  [774c47f1d78e373a6bd2964f4e278d1ce26c21cb] KVM: cpu hotplug support

the commits prefixed with '+' were the ones where i had to hand-merge 
the f3ccb06f commit to. Near the end of the bisection it nicely honed in 
on the group of KVM changes that included the bad commit.

but the conclusion is clear: if multiple bugs are present in the search 
area then it gets quite difficult to sort it out via git-bisect - but 
it's not impossible either. The following git-bisect enhancement could 
have made things easier for me:

   git-bisect mark-must-have <tree>

which would mark <tree> as a must-have fix and would attempt to merge it 
to whatever bisection point it ends up with - if that bisection point 
does not have <tree> included already. (Maybe not even the full tree but 
only one particular commit ID.) In this particular case that merge, when 
it had to be done, was always 'clean'.

	Ingo

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> I'll now try the following: i'll try to manually apply Len's fix to 
> every tree that git-bisect offers me, in the hope of being able to 
> isolate the /other/ bug.
> 
> [ But really, i'm not expecting any miracles because this is way out of
>   league for git-bisect which really depends on only having a binary 
>   space to search for. ]

this method pointed out the real bug that we are interested in:

| 774c47f1d78e373a6bd2964f4e278d1ce26c21cb is first bad commit
| commit 774c47f1d78e373a6bd2964f4e278d1ce26c21cb
| Author: Avi Kivity <avi@qumranet.com>
| Date:   Mon Feb 12 00:54:47 2007 -0800
|     [PATCH] KVM: cpu hotplug support

undoing the 774c47f1 patch from HEAD gave me a working resume. I'll send 
a fix for this KVM breakage in a separate mail.

here's how the bisection went:

 bad:   [01363220f5d23ef68276db8974e46a502e43d01d] [PARISC] clocksource:
 good:  [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20
 +good: [bcdb81ae29091f6a66369aabfd8324e4a53d05dc] knfsd: SUNRPC: add a
 bad:   [920841d8d1d61bc12b43f95a579a5374f6d98f81] Merge branch 'for-linus'
 +bad:  [86a71dbd3e81e8870d0f0e56b87875f57e58222b] sysctl: hide the sysctl
 +bad:  [719c91ccadd3ed26570dbb29d54166914832eee9] [POWERPC] Use udbg_early
 +bad:  [ebaf0c6032f525ddb0158fb59848d41899dce8cd] Merge branch 'for-linus'
 +good: [8cd133073f9b5cd335c0b2e4740aceb025d50ca9] kvm: Fix mismatch between
 +bad:  [5b8e8ee6c65a34d8aafaeb8e2eaa97e496c2567c] ps3: add shutdown to
 +bad:  [a524d946bdced73c5fbe60170fb33611491c4211] tgafb: sync-on-green
 +bad:  [a268422de8bf1b4c0cb97987b6c329c9f6a3da4b] fbdev driver for S3
 +good: [8d0be2b3bf4a55606967d7d84e56c52521e94333] KVM: VMX: add vcpu_clear()
 +bad:  [59ae6c6b87711ceb2d1ea5f9e08bb13aee947a29] KVM: Host suspend/resume
 +bad:  [774c47f1d78e373a6bd2964f4e278d1ce26c21cb] KVM: cpu hotplug support

the commits prefixed with '+' were the ones where i had to hand-merge 
the f3ccb06f commit to. Near the end of the bisection it nicely honed in 
on the group of KVM changes that included the bad commit.

but the conclusion is clear: if multiple bugs are present in the search 
area then it gets quite difficult to sort it out via git-bisect - but 
it's not impossible either. The following git-bisect enhancement could 
have made things easier for me:

   git-bisect mark-must-have <tree>

which would mark <tree> as a must-have fix and would attempt to merge it 
to whatever bisection point it ends up with - if that bisection point 
does not have <tree> included already. (Maybe not even the full tree but 
only one particular commit ID.) In this particular case that merge, when 
it had to be done, was always 'clean'.

	Ingo

[patch] KVM: T60 resume fix

[Ingo Molnar]

Subject: [patch] KVM: T60 resume fix
From: Ingo Molnar <mingo@elte.hu>

my T60 laptop does not resume correctly due to KVM attempting to send an 
IPI to a CPU that might be down (or not up yet). (Doing so also triggers 
the send_IPI_mask_bitmask() warning in arch/i386/kernel/smp.c, line 
732.)

with this fix applied my laptop does not hang during resume.

[ KVM will have to disable/enable virtualization on the CPU itself that
  goes down / comes up, not via an IPI sent from the requesting CPU. ]

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 drivers/kvm/kvm_main.c |    6 ------
 1 file changed, 6 deletions(-)

Index: linux/drivers/kvm/kvm_main.c
===================================================================
--- linux.orig/drivers/kvm/kvm_main.c
+++ linux/drivers/kvm/kvm_main.c
@@ -2083,12 +2083,6 @@ static int kvm_cpu_hotplug(struct notifi
 	case CPU_DEAD:
 	case CPU_UP_CANCELED:
 		decache_vcpus_on_cpu(cpu);
-		smp_call_function_single(cpu, kvm_arch_ops->hardware_disable,
-					 NULL, 0, 1);
-		break;
-	case CPU_UP_PREPARE:
-		smp_call_function_single(cpu, kvm_arch_ops->hardware_enable,
-					 NULL, 0, 1);
 		break;
 	}
 	return NOTIFY_OK;

[patch] KVM: T60 resume fix

[Ingo Molnar]

Subject: [patch] KVM: T60 resume fix
From: Ingo Molnar <mingo@elte.hu>

my T60 laptop does not resume correctly due to KVM attempting to send an 
IPI to a CPU that might be down (or not up yet). (Doing so also triggers 
the send_IPI_mask_bitmask() warning in arch/i386/kernel/smp.c, line 
732.)

with this fix applied my laptop does not hang during resume.

[ KVM will have to disable/enable virtualization on the CPU itself that
  goes down / comes up, not via an IPI sent from the requesting CPU. ]

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 drivers/kvm/kvm_main.c |    6 ------
 1 file changed, 6 deletions(-)

Index: linux/drivers/kvm/kvm_main.c
===================================================================
--- linux.orig/drivers/kvm/kvm_main.c
+++ linux/drivers/kvm/kvm_main.c
@@ -2083,12 +2083,6 @@ static int kvm_cpu_hotplug(struct notifi
 	case CPU_DEAD:
 	case CPU_UP_CANCELED:
 		decache_vcpus_on_cpu(cpu);
-		smp_call_function_single(cpu, kvm_arch_ops->hardware_disable,
-					 NULL, 0, 1);
-		break;
-	case CPU_UP_PREPARE:
-		smp_call_function_single(cpu, kvm_arch_ops->hardware_enable,
-					 NULL, 0, 1);
 		break;
 	}
 	return NOTIFY_OK;

Re: [patch] KVM: T60 resume fix

[Michael S. Tsirkin]

> Quoting Ingo Molnar <mingo@elte.hu>:
> Subject: [patch] KVM: T60 resume fix
> From: Ingo Molnar <mingo@elte.hu>
> 
> my T60 laptop does not resume correctly due to KVM attempting to send an 
> IPI to a CPU that might be down (or not up yet). (Doing so also triggers 
> the send_IPI_mask_bitmask() warning in arch/i386/kernel/smp.c, line 
> 732.)
> 
> with this fix applied my laptop does not hang during resume.
> 
> [ KVM will have to disable/enable virtualization on the CPU itself that
>   goes down / comes up, not via an IPI sent from the requesting CPU. ]
> 
> Signed-off-by: Ingo Molnar <mingo@elte.hu>

Since I don't normally have kvm loaded, this patch is unlikely
to help me, is that right?

-- 
MST

Re: [patch] KVM: T60 resume fix

[Avi Kivity]

Michael S. Tsirkin wrote:
>> Quoting Ingo Molnar <mingo@elte.hu>:
>> Subject: [patch] KVM: T60 resume fix
>> From: Ingo Molnar <mingo@elte.hu>
>>
>> my T60 laptop does not resume correctly due to KVM attempting to send an 
>> IPI to a CPU that might be down (or not up yet). (Doing so also triggers 
>> the send_IPI_mask_bitmask() warning in arch/i386/kernel/smp.c, line 
>> 732.)
>>
>> with this fix applied my laptop does not hang during resume.
>>
>> [ KVM will have to disable/enable virtualization on the CPU itself that
>>   goes down / comes up, not via an IPI sent from the requesting CPU. ]
>>
>> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>>     
>
> Since I don't normally have kvm loaded, this patch is unlikely
> to help me, is that right?
>
>   

That is correct.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [patch] KVM: T60 resume fix

[Avi Kivity]

Michael S. Tsirkin wrote:
>> Quoting Ingo Molnar <mingo@elte.hu>:
>> Subject: [patch] KVM: T60 resume fix
>> From: Ingo Molnar <mingo@elte.hu>
>>
>> my T60 laptop does not resume correctly due to KVM attempting to send an 
>> IPI to a CPU that might be down (or not up yet). (Doing so also triggers 
>> the send_IPI_mask_bitmask() warning in arch/i386/kernel/smp.c, line 
>> 732.)
>>
>> with this fix applied my laptop does not hang during resume.
>>
>> [ KVM will have to disable/enable virtualization on the CPU itself that
>>   goes down / comes up, not via an IPI sent from the requesting CPU. ]
>>
>> Signed-off-by: Ingo Molnar <mingo@elte.hu>
>>     
>
> Since I don't normally have kvm loaded, this patch is unlikely
> to help me, is that right?
>
>   

That is correct.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [patch] KVM: T60 resume fix

[Avi Kivity]

Ingo Molnar wrote:
> Subject: [patch] KVM: T60 resume fix
> From: Ingo Molnar <mingo@elte.hu>
>
> my T60 laptop does not resume correctly due to KVM attempting to send an 
> IPI to a CPU that might be down (or not up yet). (Doing so also triggers 
> the send_IPI_mask_bitmask() warning in arch/i386/kernel/smp.c, line 
> 732.)
>
> with this fix applied my laptop does not hang during resume.
>
> [ KVM will have to disable/enable virtualization on the CPU itself that
>   goes down / comes up, not via an IPI sent from the requesting CPU. ]
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  drivers/kvm/kvm_main.c |    6 ------
>  1 file changed, 6 deletions(-)
>
> Index: linux/drivers/kvm/kvm_main.c
> ===================================================================
> --- linux.orig/drivers/kvm/kvm_main.c
> +++ linux/drivers/kvm/kvm_main.c
> @@ -2083,12 +2083,6 @@ static int kvm_cpu_hotplug(struct notifi
>  	case CPU_DEAD:
>  	case CPU_UP_CANCELED:
>  		decache_vcpus_on_cpu(cpu);
> -		smp_call_function_single(cpu, kvm_arch_ops->hardware_disable,
> -					 NULL, 0, 1);
> -		break;
> -	case CPU_UP_PREPARE:
> -		smp_call_function_single(cpu, kvm_arch_ops->hardware_enable,
> -					 NULL, 0, 1);
>  		break;
>  	}
>  	return NOTIFY_OK;
>   

That is already CPU_ONLINE in my tree (and in the pull request sent to 
Linus a couple of days ago).



-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [patch] KVM: T60 resume fix

[Avi Kivity]

Ingo Molnar wrote:
> Subject: [patch] KVM: T60 resume fix
> From: Ingo Molnar <mingo@elte.hu>
>
> my T60 laptop does not resume correctly due to KVM attempting to send an 
> IPI to a CPU that might be down (or not up yet). (Doing so also triggers 
> the send_IPI_mask_bitmask() warning in arch/i386/kernel/smp.c, line 
> 732.)
>
> with this fix applied my laptop does not hang during resume.
>
> [ KVM will have to disable/enable virtualization on the CPU itself that
>   goes down / comes up, not via an IPI sent from the requesting CPU. ]
>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  drivers/kvm/kvm_main.c |    6 ------
>  1 file changed, 6 deletions(-)
>
> Index: linux/drivers/kvm/kvm_main.c
> ===================================================================
> --- linux.orig/drivers/kvm/kvm_main.c
> +++ linux/drivers/kvm/kvm_main.c
> @@ -2083,12 +2083,6 @@ static int kvm_cpu_hotplug(struct notifi
>  	case CPU_DEAD:
>  	case CPU_UP_CANCELED:
>  		decache_vcpus_on_cpu(cpu);
> -		smp_call_function_single(cpu, kvm_arch_ops->hardware_disable,
> -					 NULL, 0, 1);
> -		break;
> -	case CPU_UP_PREPARE:
> -		smp_call_function_single(cpu, kvm_arch_ops->hardware_enable,
> -					 NULL, 0, 1);
>  		break;
>  	}
>  	return NOTIFY_OK;
>   

That is already CPU_ONLINE in my tree (and in the pull request sent to 
Linus a couple of days ago).



-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [patch] KVM: T60 resume fix

[Andrew Morton]

On Sat, 03 Mar 2007 10:21:38 +0200 Avi Kivity <avi@qumranet.com> wrote:

> Ingo Molnar wrote:
> > Subject: [patch] KVM: T60 resume fix
> > From: Ingo Molnar <mingo@elte.hu>
> >
> > my T60 laptop does not resume correctly due to KVM attempting to send an 
> > IPI to a CPU that might be down (or not up yet). (Doing so also triggers 
> > the send_IPI_mask_bitmask() warning in arch/i386/kernel/smp.c, line 
> > 732.)
> >
> > with this fix applied my laptop does not hang during resume.
> >
> > [ KVM will have to disable/enable virtualization on the CPU itself that
> >   goes down / comes up, not via an IPI sent from the requesting CPU. ]
> >
> > Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > ---
> >  drivers/kvm/kvm_main.c |    6 ------
> >  1 file changed, 6 deletions(-)
> >
> > Index: linux/drivers/kvm/kvm_main.c
> > ===================================================================
> > --- linux.orig/drivers/kvm/kvm_main.c
> > +++ linux/drivers/kvm/kvm_main.c
> > @@ -2083,12 +2083,6 @@ static int kvm_cpu_hotplug(struct notifi
> >  	case CPU_DEAD:
> >  	case CPU_UP_CANCELED:
> >  		decache_vcpus_on_cpu(cpu);
> > -		smp_call_function_single(cpu, kvm_arch_ops->hardware_disable,
> > -					 NULL, 0, 1);
> > -		break;
> > -	case CPU_UP_PREPARE:
> > -		smp_call_function_single(cpu, kvm_arch_ops->hardware_enable,
> > -					 NULL, 0, 1);
> >  		break;
> >  	}
> >  	return NOTIFY_OK;
> >   
> 
> That is already CPU_ONLINE in my tree

I noticed ;)

So this mean that Ingo's bug should already be fixed there.  And in rc2-mm1.

> (and in the pull request sent to 
> Linus a couple of days ago).

Resend, please.

Re: [patch] KVM: T60 resume fix

[Andrew Morton]

On Sat, 03 Mar 2007 10:21:38 +0200 Avi Kivity <avi@qumranet.com> wrote:

> Ingo Molnar wrote:
> > Subject: [patch] KVM: T60 resume fix
> > From: Ingo Molnar <mingo@elte.hu>
> >
> > my T60 laptop does not resume correctly due to KVM attempting to send an 
> > IPI to a CPU that might be down (or not up yet). (Doing so also triggers 
> > the send_IPI_mask_bitmask() warning in arch/i386/kernel/smp.c, line 
> > 732.)
> >
> > with this fix applied my laptop does not hang during resume.
> >
> > [ KVM will have to disable/enable virtualization on the CPU itself that
> >   goes down / comes up, not via an IPI sent from the requesting CPU. ]
> >
> > Signed-off-by: Ingo Molnar <mingo@elte.hu>
> > ---
> >  drivers/kvm/kvm_main.c |    6 ------
> >  1 file changed, 6 deletions(-)
> >
> > Index: linux/drivers/kvm/kvm_main.c
> > ===================================================================
> > --- linux.orig/drivers/kvm/kvm_main.c
> > +++ linux/drivers/kvm/kvm_main.c
> > @@ -2083,12 +2083,6 @@ static int kvm_cpu_hotplug(struct notifi
> >  	case CPU_DEAD:
> >  	case CPU_UP_CANCELED:
> >  		decache_vcpus_on_cpu(cpu);
> > -		smp_call_function_single(cpu, kvm_arch_ops->hardware_disable,
> > -					 NULL, 0, 1);
> > -		break;
> > -	case CPU_UP_PREPARE:
> > -		smp_call_function_single(cpu, kvm_arch_ops->hardware_enable,
> > -					 NULL, 0, 1);
> >  		break;
> >  	}
> >  	return NOTIFY_OK;
> >   
> 
> That is already CPU_ONLINE in my tree

I noticed ;)

So this mean that Ingo's bug should already be fixed there.  And in rc2-mm1.

> (and in the pull request sent to 
> Linus a couple of days ago).

Resend, please.

Re: [patch] KVM: T60 resume fix

[Junio C Hamano]

Could you un-CC: git@vger.kernel.org from this thread, please?

Re: [patch] KVM: T60 resume fix

[Junio C Hamano]

Could you un-CC: git@vger.kernel.org from this thread, please?

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Avi Kivity <avi@qumranet.com> wrote:

> > my T60 laptop does not resume correctly due to KVM attempting to 
> > send an IPI to a CPU that might be down (or not up yet). (Doing so 
> > also triggers the send_IPI_mask_bitmask() warning in 
> > arch/i386/kernel/smp.c, line 732.)
> >
> >with this fix applied my laptop does not hang during resume.
> >
> >[ KVM will have to disable/enable virtualization on the CPU itself 
> >  that goes down / comes up, not via an IPI sent from the requesting
> > CPU. ]

> That is already CPU_ONLINE in my tree (and in the pull request sent to 
> Linus a couple of days ago).

that solves the resume problem - but doesnt solve the CPU_DEAD issue of 
sending an IPI to an already offline CPU. Might be a better idea to do 
it in CPU_DOWN_PREPARE? (and then to also add a CPU_DOWN_FAILED branch?)

	Ingo

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Avi Kivity <avi@qumranet.com> wrote:

> > my T60 laptop does not resume correctly due to KVM attempting to 
> > send an IPI to a CPU that might be down (or not up yet). (Doing so 
> > also triggers the send_IPI_mask_bitmask() warning in 
> > arch/i386/kernel/smp.c, line 732.)
> >
> >with this fix applied my laptop does not hang during resume.
> >
> >[ KVM will have to disable/enable virtualization on the CPU itself 
> >  that goes down / comes up, not via an IPI sent from the requesting
> > CPU. ]

> That is already CPU_ONLINE in my tree (and in the pull request sent to 
> Linus a couple of days ago).

that solves the resume problem - but doesnt solve the CPU_DEAD issue of 
sending an IPI to an already offline CPU. Might be a better idea to do 
it in CPU_DOWN_PREPARE? (and then to also add a CPU_DOWN_FAILED branch?)

	Ingo

Re: [patch] KVM: T60 resume fix

[Avi Kivity]

Ingo Molnar wrote:
> * Avi Kivity <avi@qumranet.com> wrote:
>
>   
>>> my T60 laptop does not resume correctly due to KVM attempting to 
>>> send an IPI to a CPU that might be down (or not up yet). (Doing so 
>>> also triggers the send_IPI_mask_bitmask() warning in 
>>> arch/i386/kernel/smp.c, line 732.)
>>>
>>> with this fix applied my laptop does not hang during resume.
>>>
>>> [ KVM will have to disable/enable virtualization on the CPU itself 
>>>  that goes down / comes up, not via an IPI sent from the requesting
>>> CPU. ]
>>>       
>
>   
>> That is already CPU_ONLINE in my tree (and in the pull request sent to 
>> Linus a couple of days ago).
>>     
>
> that solves the resume problem - but doesnt solve the CPU_DEAD issue of 
> sending an IPI to an already offline CPU. Might be a better idea to do 
> it in CPU_DOWN_PREPARE? (and then to also add a CPU_DOWN_FAILED branch?)
>
> 	

Mainline now has DOWN_PREPARE and UP_CANCELED calling 
->hardware_disable(), and ONLINE calling ->hardware_enabled().  What 
tree are you looking at?

[but I do see the need for DOWN_FAILED now. Off to find a resumable 
machine...]


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [patch] KVM: T60 resume fix

[Avi Kivity]

Ingo Molnar wrote:
> * Avi Kivity <avi@qumranet.com> wrote:
>
>   
>>> my T60 laptop does not resume correctly due to KVM attempting to 
>>> send an IPI to a CPU that might be down (or not up yet). (Doing so 
>>> also triggers the send_IPI_mask_bitmask() warning in 
>>> arch/i386/kernel/smp.c, line 732.)
>>>
>>> with this fix applied my laptop does not hang during resume.
>>>
>>> [ KVM will have to disable/enable virtualization on the CPU itself 
>>>  that goes down / comes up, not via an IPI sent from the requesting
>>> CPU. ]
>>>       
>
>   
>> That is already CPU_ONLINE in my tree (and in the pull request sent to 
>> Linus a couple of days ago).
>>     
>
> that solves the resume problem - but doesnt solve the CPU_DEAD issue of 
> sending an IPI to an already offline CPU. Might be a better idea to do 
> it in CPU_DOWN_PREPARE? (and then to also add a CPU_DOWN_FAILED branch?)
>
> 	

Mainline now has DOWN_PREPARE and UP_CANCELED calling 
->hardware_disable(), and ONLINE calling ->hardware_enabled().  What 
tree are you looking at?

[but I do see the need for DOWN_FAILED now. Off to find a resumable 
machine...]


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Avi Kivity <avi@qumranet.com> wrote:

> >> That is already CPU_ONLINE in my tree (and in the pull request sent 
> >> to Linus a couple of days ago).
> >
> > that solves the resume problem - but doesnt solve the CPU_DEAD issue 
> > of sending an IPI to an already offline CPU. Might be a better idea 
> > to do it in CPU_DOWN_PREPARE? (and then to also add a 
> > CPU_DOWN_FAILED branch?)
> 
> Mainline now has DOWN_PREPARE and UP_CANCELED calling 
> ->hardware_disable(), and ONLINE calling ->hardware_enabled().  What 
> tree are you looking at?

oh, i just hand-fixed it. I'll check current-git now.

> [but I do see the need for DOWN_FAILED now. Off to find a resumable 
> machine...]

yeah, both DOWN_FAILED and UP_FAILED might trigger when some other bug 
prevents a resume.

	Ingo

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Avi Kivity <avi@qumranet.com> wrote:

> >> That is already CPU_ONLINE in my tree (and in the pull request sent 
> >> to Linus a couple of days ago).
> >
> > that solves the resume problem - but doesnt solve the CPU_DEAD issue 
> > of sending an IPI to an already offline CPU. Might be a better idea 
> > to do it in CPU_DOWN_PREPARE? (and then to also add a 
> > CPU_DOWN_FAILED branch?)
> 
> Mainline now has DOWN_PREPARE and UP_CANCELED calling 
> ->hardware_disable(), and ONLINE calling ->hardware_enabled().  What 
> tree are you looking at?

oh, i just hand-fixed it. I'll check current-git now.

> [but I do see the need for DOWN_FAILED now. Off to find a resumable 
> machine...]

yeah, both DOWN_FAILED and UP_FAILED might trigger when some other bug 
prevents a resume.

	Ingo

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > Mainline now has DOWN_PREPARE and UP_CANCELED calling 
> > ->hardware_disable(), and ONLINE calling ->hardware_enabled().  What 
> > tree are you looking at?
> 
> oh, i just hand-fixed it. I'll check current-git now.

suspend/resume works fine now and there are no warning messages 
whatsoever (with suspend simulation). Thanks Avi!

	Ingo

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > Mainline now has DOWN_PREPARE and UP_CANCELED calling 
> > ->hardware_disable(), and ONLINE calling ->hardware_enabled().  What 
> > tree are you looking at?
> 
> oh, i just hand-fixed it. I'll check current-git now.

suspend/resume works fine now and there are no warning messages 
whatsoever (with suspend simulation). Thanks Avi!

	Ingo

Re: [patch] KVM: T60 resume fix

[Avi Kivity]

Ingo Molnar wrote:
> suspend/resume works fine now and there are no warning messages 
> whatsoever (with suspend simulation). Thanks Avi!
>
>   

Where do I find this suspend simulation?  Sounds like a great suspend 
debugging tool.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [patch] KVM: T60 resume fix

[Avi Kivity]

Ingo Molnar wrote:
> suspend/resume works fine now and there are no warning messages 
> whatsoever (with suspend simulation). Thanks Avi!
>
>   

Where do I find this suspend simulation?  Sounds like a great suspend 
debugging tool.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Avi Kivity <avi@qumranet.com> wrote:

> > suspend/resume works fine now and there are no warning messages 
> > whatsoever (with suspend simulation). Thanks Avi!
> 
> Where do I find this suspend simulation?  Sounds like a great suspend 
> debugging tool.

it's just the simple hack below.

	Ingo

------------------------>
Subject: [patch] suspend debugging: simulate suspend-to-RAM
From: Ingo Molnar <mingo@elte.hu>

most resume bugs are due to the kernel hanging or crashing while trying 
to resume a specific device. It is extremely hard to debug such hangs 
because often when the hang happens there's no console available yet.

Make debugging such bugs easier by offering a resume mode that does not 
actually call into the BIOS to turn off the machine. This, in 
combination with earlyprintk=serial,ttyS0,115200,keep , 
CONFIG_PM_DEBUG=y, CONFIG_DISABLE_CONSOLE_SUSPEND=y and 
/sys/power/filter enables me to have a fully functional serial console 
during the full suspend/resume cycle.

I debugged two suspend bugs in the -rt kernel this way already, so it's 
pretty useful.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 Documentation/kernel-parameters.txt |    4 ++++
 drivers/acpi/sleep/main.c           |   15 ++++++++++++++-
 include/linux/acpi.h                |    1 +
 kernel/sysctl.c                     |    8 ++++++++
 4 files changed, 27 insertions(+), 1 deletion(-)

Index: linux/Documentation/kernel-parameters.txt
===================================================================
--- linux.orig/Documentation/kernel-parameters.txt
+++ linux/Documentation/kernel-parameters.txt
@@ -163,6 +163,10 @@ and is between 256 and 4096 characters. 
 
 	acpi_osi=	[HW,ACPI] empty param disables _OSI
 
+	acpi_simulate_suspend_to_ram
+			[KNL] Do not call into BIOS to do suspend-to-RAM
+			Format: <0/1>
+
 	acpi_serialize	[HW,ACPI] force serialization of AML methods
 
 	acpi_skip_timer_override [HW,ACPI]
Index: linux/drivers/acpi/sleep/main.c
===================================================================
--- linux.orig/drivers/acpi/sleep/main.c
+++ linux/drivers/acpi/sleep/main.c
@@ -35,6 +35,14 @@ static u32 acpi_suspend_states[] = {
 
 static int init_8259A_after_S1;
 
+/*
+ * simulate entry into the BIOS - this way the system will not
+ * be turned off for real, and the kernel's resume functionality
+ * can be debugged while still having some system capabilities
+ * left. This is especially useful in combination with /sys/power/filter.
+ */
+int acpi_simulate_suspend_to_ram;
+
 /**
  *	acpi_pm_prepare - Do preliminary suspend work.
  *	@pm_state:		suspend state we're entering.
@@ -91,7 +99,12 @@ static int acpi_pm_enter(suspend_state_t
 		break;
 
 	case PM_SUSPEND_MEM:
-		do_suspend_lowlevel();
+		if (unlikely(acpi_simulate_suspend_to_ram)) {
+			printk(KERN_INFO "ACPI: simulating suspend-to-RAM: "
+					 "not calling BIOS.\n");
+		} else {
+			do_suspend_lowlevel();
+		}
 		break;
 
 	case PM_SUSPEND_DISK:
Index: linux/include/linux/acpi.h
===================================================================
--- linux.orig/include/linux/acpi.h
+++ linux/include/linux/acpi.h
@@ -123,6 +123,7 @@ extern int pci_mmcfg_config_num;
 
 extern int sbf_port;
 extern unsigned long acpi_video_flags;
+extern int acpi_simulate_suspend_to_ram;
 
 #else	/* !CONFIG_ACPI */
 
Index: linux/kernel/sysctl.c
===================================================================
--- linux.orig/kernel/sysctl.c
+++ linux/kernel/sysctl.c
@@ -581,6 +581,14 @@ static ctl_table kern_table[] = {
 		.mode		= 0644,
 		.proc_handler	= &proc_doulongvec_minmax,
 	},
+	{
+		.ctl_name	= CTL_UNNUMBERED,
+		.procname	= "acpi_simulate_suspend_to_ram",
+		.data		= &acpi_simulate_suspend_to_ram,
+		.maxlen		= sizeof (int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec,
+	},
 #endif
 #ifdef CONFIG_IA64
 	{

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Avi Kivity <avi@qumranet.com> wrote:

> > suspend/resume works fine now and there are no warning messages 
> > whatsoever (with suspend simulation). Thanks Avi!
> 
> Where do I find this suspend simulation?  Sounds like a great suspend 
> debugging tool.

it's just the simple hack below.

	Ingo

------------------------>
Subject: [patch] suspend debugging: simulate suspend-to-RAM
From: Ingo Molnar <mingo@elte.hu>

most resume bugs are due to the kernel hanging or crashing while trying 
to resume a specific device. It is extremely hard to debug such hangs 
because often when the hang happens there's no console available yet.

Make debugging such bugs easier by offering a resume mode that does not 
actually call into the BIOS to turn off the machine. This, in 
combination with earlyprintk=serial,ttyS0,115200,keep , 
CONFIG_PM_DEBUG=y, CONFIG_DISABLE_CONSOLE_SUSPEND=y and 
/sys/power/filter enables me to have a fully functional serial console 
during the full suspend/resume cycle.

I debugged two suspend bugs in the -rt kernel this way already, so it's 
pretty useful.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 Documentation/kernel-parameters.txt |    4 ++++
 drivers/acpi/sleep/main.c           |   15 ++++++++++++++-
 include/linux/acpi.h                |    1 +
 kernel/sysctl.c                     |    8 ++++++++
 4 files changed, 27 insertions(+), 1 deletion(-)

Index: linux/Documentation/kernel-parameters.txt
===================================================================
--- linux.orig/Documentation/kernel-parameters.txt
+++ linux/Documentation/kernel-parameters.txt
@@ -163,6 +163,10 @@ and is between 256 and 4096 characters. 
 
 	acpi_osi=	[HW,ACPI] empty param disables _OSI
 
+	acpi_simulate_suspend_to_ram
+			[KNL] Do not call into BIOS to do suspend-to-RAM
+			Format: <0/1>
+
 	acpi_serialize	[HW,ACPI] force serialization of AML methods
 
 	acpi_skip_timer_override [HW,ACPI]
Index: linux/drivers/acpi/sleep/main.c
===================================================================
--- linux.orig/drivers/acpi/sleep/main.c
+++ linux/drivers/acpi/sleep/main.c
@@ -35,6 +35,14 @@ static u32 acpi_suspend_states[] = {
 
 static int init_8259A_after_S1;
 
+/*
+ * simulate entry into the BIOS - this way the system will not
+ * be turned off for real, and the kernel's resume functionality
+ * can be debugged while still having some system capabilities
+ * left. This is especially useful in combination with /sys/power/filter.
+ */
+int acpi_simulate_suspend_to_ram;
+
 /**
  *	acpi_pm_prepare - Do preliminary suspend work.
  *	@pm_state:		suspend state we're entering.
@@ -91,7 +99,12 @@ static int acpi_pm_enter(suspend_state_t
 		break;
 
 	case PM_SUSPEND_MEM:
-		do_suspend_lowlevel();
+		if (unlikely(acpi_simulate_suspend_to_ram)) {
+			printk(KERN_INFO "ACPI: simulating suspend-to-RAM: "
+					 "not calling BIOS.\n");
+		} else {
+			do_suspend_lowlevel();
+		}
 		break;
 
 	case PM_SUSPEND_DISK:
Index: linux/include/linux/acpi.h
===================================================================
--- linux.orig/include/linux/acpi.h
+++ linux/include/linux/acpi.h
@@ -123,6 +123,7 @@ extern int pci_mmcfg_config_num;
 
 extern int sbf_port;
 extern unsigned long acpi_video_flags;
+extern int acpi_simulate_suspend_to_ram;
 
 #else	/* !CONFIG_ACPI */
 
Index: linux/kernel/sysctl.c
===================================================================
--- linux.orig/kernel/sysctl.c
+++ linux/kernel/sysctl.c
@@ -581,6 +581,14 @@ static ctl_table kern_table[] = {
 		.mode		= 0644,
 		.proc_handler	= &proc_doulongvec_minmax,
 	},
+	{
+		.ctl_name	= CTL_UNNUMBERED,
+		.procname	= "acpi_simulate_suspend_to_ram",
+		.data		= &acpi_simulate_suspend_to_ram,
+		.maxlen		= sizeof (int),
+		.mode		= 0644,
+		.proc_handler	= &proc_dointvec,
+	},
 #endif
 #ifdef CONFIG_IA64
 	{

Re: [patch] KVM: T60 resume fix

[Avi Kivity]

Ingo Molnar wrote:
> * Avi Kivity <avi@qumranet.com> wrote:
>
>   
>>> suspend/resume works fine now and there are no warning messages 
>>> whatsoever (with suspend simulation). Thanks Avi!
>>>       
>> Where do I find this suspend simulation?  Sounds like a great suspend 
>> debugging tool.
>>     
>
> it's just the simple hack below.
>
>
>   

Thanks, I'll put it to good use.  Are you planning to upstream it?  Not 
for 2.6.21, presumably ;)



-- 
error compiling committee.c: too many arguments to function

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Avi Kivity <avi@qumranet.com> wrote:

> >it's just the simple hack below.
> 
> Thanks, I'll put it to good use.  Are you planning to upstream it?  
> Not for 2.6.21, presumably ;)

it needs an essential cleanup: instead of modifying 'mem' behavior, it 
should be a 'testmem' thing and no acpi_ flag.

	Ingo

Re: [patch] KVM: T60 resume fix

[Michael S. Tsirkin]

> Quoting Avi Kivity <avi@qumranet.com>:
> Subject: Re: [patch] KVM: T60 resume fix
> 
> Ingo Molnar wrote:
> > * Avi Kivity <avi@qumranet.com> wrote:
> >
> >   
> >>> suspend/resume works fine now and there are no warning messages 
> >>> whatsoever (with suspend simulation). Thanks Avi!
> >>>       
> >> Where do I find this suspend simulation?  Sounds like a great suspend 
> >> debugging tool.
> >>     
> >
> > it's just the simple hack below.
> >
> >
> >   
> 
> Thanks, I'll put it to good use.  Are you planning to upstream it?  Not 
> for 2.6.21, presumably ;)

I think Pavel wants it triggerable through /sys/power/state:
http://lkml.org/lkml/2007/1/25/99

-- 
MST

Re: [patch] KVM: T60 resume fix

[Michael S. Tsirkin]

> Quoting Avi Kivity <avi@qumranet.com>:
> Subject: Re: [patch] KVM: T60 resume fix
> 
> Ingo Molnar wrote:
> > * Avi Kivity <avi@qumranet.com> wrote:
> >
> >   
> >>> suspend/resume works fine now and there are no warning messages 
> >>> whatsoever (with suspend simulation). Thanks Avi!
> >>>       
> >> Where do I find this suspend simulation?  Sounds like a great suspend 
> >> debugging tool.
> >>     
> >
> > it's just the simple hack below.
> >
> >
> >   
> 
> Thanks, I'll put it to good use.  Are you planning to upstream it?  Not 
> for 2.6.21, presumably ;)

I think Pavel wants it triggerable through /sys/power/state:
http://lkml.org/lkml/2007/1/25/99

-- 
MST

Re: [patch] KVM: T60 resume fix

[Michael S. Tsirkin]

> suspend/resume works fine now and there are no warning messages 
> whatsoever (with suspend simulation). Thanks Avi!

I just tried Ingo's .config and it hangs on resume for me (with suspend to memory).

-- 
MST

Re: [patch] KVM: T60 resume fix

[Michael S. Tsirkin]

> suspend/resume works fine now and there are no warning messages 
> whatsoever (with suspend simulation). Thanks Avi!

I just tried Ingo's .config and it hangs on resume for me (with suspend to memory).

-- 
MST

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> > suspend/resume works fine now and there are no warning messages 
> > whatsoever (with suspend simulation). Thanks Avi!
> 
> I just tried Ingo's .config and it hangs on resume for me (with 
> suspend to memory).

could you try 's2ram' from http://suspend.sf.net ? It's basically 
equivalent to 'echo mem > /sys/power/state', but you can usually also 
see the reason why it doesnt resume, on the vga console. (by default the 
kernel doesnt resume the t60's vga properly)

on my box resume works, but it's incredibly slow. Takes a few minutes to 
have total effect.

	Ingo

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> > suspend/resume works fine now and there are no warning messages 
> > whatsoever (with suspend simulation). Thanks Avi!
> 
> I just tried Ingo's .config and it hangs on resume for me (with 
> suspend to memory).

could you try 's2ram' from http://suspend.sf.net ? It's basically 
equivalent to 'echo mem > /sys/power/state', but you can usually also 
see the reason why it doesnt resume, on the vga console. (by default the 
kernel doesnt resume the t60's vga properly)

on my box resume works, but it's incredibly slow. Takes a few minutes to 
have total effect.

	Ingo

Re: [patch] KVM: T60 resume fix

[Michael S. Tsirkin]

> Quoting Ingo Molnar <mingo@elte.hu>:
> Subject: Re: [patch] KVM: T60 resume fix
> 
> 
> * Michael S. Tsirkin <mst@mellanox.co.il> wrote:
> 
> > > suspend/resume works fine now and there are no warning messages 
> > > whatsoever (with suspend simulation). Thanks Avi!
> > 
> > I just tried Ingo's .config and it hangs on resume for me (with 
> > suspend to memory).
> 
> could you try 's2ram' from http://suspend.sf.net ? It's basically 
> equivalent to 'echo mem > /sys/power/state', but you can usually also 
> see the reason why it doesnt resume, on the vga console. (by default the 
> kernel doesnt resume the t60's vga properly)

OK, I'll give it a try. Do I have to shut down X or is it enough to
switch to another VT?

> on my box resume works, but it's incredibly slow.

I guess it is possible that what I mistook for a hang was actually an incredibly
slow system, and that it would resume, eventually. I waited for 5 min and gave
up.

> Takes a few minutes to have total effect.

I have same here with my old .config (2-3 min).

However, after resume was completed, system would hang on the *next* suspend to
ram.

Ingo, do you see this behaviour, or can you suspend/resume any number of times?

-- 
MST

Re: [patch] KVM: T60 resume fix

[Michael S. Tsirkin]

> Quoting Ingo Molnar <mingo@elte.hu>:
> Subject: Re: [patch] KVM: T60 resume fix
> 
> 
> * Michael S. Tsirkin <mst@mellanox.co.il> wrote:
> 
> > > suspend/resume works fine now and there are no warning messages 
> > > whatsoever (with suspend simulation). Thanks Avi!
> > 
> > I just tried Ingo's .config and it hangs on resume for me (with 
> > suspend to memory).
> 
> could you try 's2ram' from http://suspend.sf.net ? It's basically 
> equivalent to 'echo mem > /sys/power/state', but you can usually also 
> see the reason why it doesnt resume, on the vga console. (by default the 
> kernel doesnt resume the t60's vga properly)

OK, I'll give it a try. Do I have to shut down X or is it enough to
switch to another VT?

> on my box resume works, but it's incredibly slow.

I guess it is possible that what I mistook for a hang was actually an incredibly
slow system, and that it would resume, eventually. I waited for 5 min and gave
up.

> Takes a few minutes to have total effect.

I have same here with my old .config (2-3 min).

However, after resume was completed, system would hang on the *next* suspend to
ram.

Ingo, do you see this behaviour, or can you suspend/resume any number of times?

-- 
MST

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> > could you try 's2ram' from http://suspend.sf.net ? It's basically 
> > equivalent to 'echo mem > /sys/power/state', but you can usually also 
> > see the reason why it doesnt resume, on the vga console. (by default the 
> > kernel doesnt resume the t60's vga properly)
> 
> OK, I'll give it a try. Do I have to shut down X or is it enough to 
> switch to another VT?

s2ram takes care of that on your behalf.

> > on my box resume works, but it's incredibly slow.
> 
> I guess it is possible that what I mistook for a hang was actually an 
> incredibly slow system, and that it would resume, eventually. I waited 
> for 5 min and gave up.

5 min should be enough to have the box pingable again.

> However, after resume was completed, system would hang on the *next* 
> suspend to ram.
> 
> Ingo, do you see this behaviour, or can you suspend/resume any number 
> of times?

havent tried that yet - first trying to figure out why the first resume 
misbehaves ;)

	Ingo

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> > could you try 's2ram' from http://suspend.sf.net ? It's basically 
> > equivalent to 'echo mem > /sys/power/state', but you can usually also 
> > see the reason why it doesnt resume, on the vga console. (by default the 
> > kernel doesnt resume the t60's vga properly)
> 
> OK, I'll give it a try. Do I have to shut down X or is it enough to 
> switch to another VT?

s2ram takes care of that on your behalf.

> > on my box resume works, but it's incredibly slow.
> 
> I guess it is possible that what I mistook for a hang was actually an 
> incredibly slow system, and that it would resume, eventually. I waited 
> for 5 min and gave up.

5 min should be enough to have the box pingable again.

> However, after resume was completed, system would hang on the *next* 
> suspend to ram.
> 
> Ingo, do you see this behaviour, or can you suspend/resume any number 
> of times?

havent tried that yet - first trying to figure out why the first resume 
misbehaves ;)

	Ingo

Re: [patch] KVM: T60 resume fix

[Michael S. Tsirkin]

> with this fix applied my laptop does not hang during resume.

On the off chance that this is relevant, could you post
your .config please?

-- 
MST

Re: [patch] KVM: T60 resume fix

[Michael S. Tsirkin]

> with this fix applied my laptop does not hang during resume.

On the off chance that this is relevant, could you post
your .config please?

-- 
MST

Re: [patch] KVM: T60 resume fix

[Ingo Molnar]

* Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> > with this fix applied my laptop does not hang during resume.
> 
> On the off chance that this is relevant, could you post your .config 
> please?

sure - find it below.

	Ingo

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21
# Mon Mar  5 11:15:42 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_ASYNC_SUPPORT=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
# CONFIG_TASK_XACCT is not set
# CONFIG_UTS_NS is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
# CONFIG_IKCONFIG is not set
CONFIG_CPUSETS=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_RELAY=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y

#
# Block layer
#
CONFIG_BLOCK=y
CONFIG_LBD=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_LSF=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="deadline"

#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_SMP=y
# CONFIG_X86_PC is not set
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
CONFIG_X86_GENERICARCH=y
# CONFIG_X86_ES7000 is not set
CONFIG_PARAVIRT=y
CONFIG_VMI=y
CONFIG_X86_CYCLONE_TIMER=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MCORE2 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_PPRO_FENCE=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_NR_CPUS=32
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
# CONFIG_X86_MCE_NONFATAL is not set
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
CONFIG_TOSHIBA=m
CONFIG_I8K=m
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=m
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m

#
# Firmware Drivers
#
CONFIG_EDD=m
CONFIG_EFI_VARS=y
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_EFI=y
# CONFIG_IRQBALANCE is not set
CONFIG_BOOT_IOREMAP=y
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_KEXEC=y
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_HOTPLUG_CPU=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
CONFIG_PM_DEBUG=y
CONFIG_DISABLE_CONSOLE_SUSPEND=y
CONFIG_PM_TRACE=y
CONFIG_PM_SYSFS_DEPRECATED=y
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=""
CONFIG_SUSPEND_SMP=y

#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_SLEEP_PROC_SLEEP is not set
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=m
# CONFIG_ACPI_BAY is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_ASUS=m
CONFIG_ACPI_IBM=m
CONFIG_ACPI_TOSHIBA=m
CONFIG_ACPI_BLACKLIST_YEAR=1999
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_SBS=m

#
# APM (Advanced Power Management) BIOS Support
#
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
# CONFIG_APM_DO_ENABLE is not set
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
CONFIG_APM_RTC_IS_GMT=y
# CONFIG_APM_ALLOW_INTS is not set
# CONFIG_APM_REAL_MODE_POWER_OFF is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_DEBUG=y
CONFIG_CPU_FREQ_STAT=m
CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m

#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_POWERNOW_K6 is not set
CONFIG_X86_POWERNOW_K7=y
CONFIG_X86_POWERNOW_K7_ACPI=y
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_POWERNOW_K8_ACPI=y
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=y
CONFIG_X86_SPEEDSTEP_SMI=y
CONFIG_X86_P4_CLOCKMOD=m
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
CONFIG_X86_LONGRUN=y
# CONFIG_X86_LONGHAUL is not set
# CONFIG_X86_E_POWERSAVER is not set

#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_X86_SPEEDSTEP_LIB=y
# CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set

#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=m
# CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set
CONFIG_PCIEAER=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_DEBUG is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_K8_NB=y

#
# PCCARD (PCMCIA/CardBus) support
#
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
CONFIG_PD6729=m
CONFIG_I82092=m
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set
CONFIG_PCMCIA_PROBE=y
CONFIG_PCCARD_NONSTATIC=y

#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_FAKE=m
CONFIG_HOTPLUG_PCI_COMPAQ=m
# CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
CONFIG_HOTPLUG_PCI_IBM=m
CONFIG_HOTPLUG_PCI_ACPI=m
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
CONFIG_NET_KEY=y
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
# CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=y
CONFIG_TCP_CONG_CUBIC=m
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_DEFAULT_BIC=y
# CONFIG_DEFAULT_CUBIC is not set
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="bic"
CONFIG_TCP_MD5SIG=y

#
# IP: Virtual Server Configuration
#
CONFIG_IP_VS=m
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12

#
# IPVS transport protocol load balancing support
#
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y

#
# IPVS scheduler
#
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m

#
# IPVS application helper
#
CONFIG_IP_VS_FTP=m
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
# CONFIG_IPV6_MIP6 is not set
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m
CONFIG_IPV6_SIT=m
CONFIG_IPV6_TUNNEL=m
# CONFIG_IPV6_MULTIPLE_TABLES is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CONNTRACK_ENABLED=m
CONFIG_NF_CONNTRACK_SUPPORT=y
# CONFIG_IP_NF_CONNTRACK_SUPPORT is not set
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CT_ACCT=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=m
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_PPTP=m
# CONFIG_NF_CONNTRACK_SANE is not set
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m

#
# IP: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_IPRANGE=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_RECENT=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_SAME=m
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_GRE=m
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_TFTP=m
CONFIG_NF_NAT_AMANDA=m
CONFIG_NF_NAT_PPTP=m
CONFIG_NF_NAT_H323=m
CONFIG_NF_NAT_SIP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
CONFIG_NF_CONNTRACK_IPV6=m
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_AH=m
# CONFIG_IP6_NF_MATCH_MH is not set
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_RAW=m

#
# DECnet: Netfilter Configuration
#
# CONFIG_DECNET_NF_GRABULATOR is not set

#
# Bridge: Netfilter Configuration
#
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_ULOG=m

#
# DCCP Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m
CONFIG_IP_DCCP_ACKVEC=y

#
# DCCP CCIDs Configuration (EXPERIMENTAL)
#
CONFIG_IP_DCCP_CCID2=m
# CONFIG_IP_DCCP_CCID2_DEBUG is not set
CONFIG_IP_DCCP_CCID3=m
CONFIG_IP_DCCP_TFRC_LIB=m
# CONFIG_IP_DCCP_CCID3_DEBUG is not set
CONFIG_IP_DCCP_CCID3_RTO=100

#
# DCCP Kernel Hacking
#
# CONFIG_IP_DCCP_DEBUG is not set
# CONFIG_NET_DCCPPROBE is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not set
CONFIG_SCTP_HMAC_MD5=y

#
# TIPC Configuration (EXPERIMENTAL)
#
CONFIG_TIPC=m
# CONFIG_TIPC_ADVANCED is not set
# CONFIG_TIPC_DEBUG is not set
CONFIG_ATM=m
CONFIG_ATM_CLIP=m
# CONFIG_ATM_CLIP_NO_ICMP is not set
CONFIG_ATM_LANE=m
# CONFIG_ATM_MPOA is not set
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
CONFIG_DECNET=m
CONFIG_DECNET_ROUTER=y
CONFIG_LLC=y
# CONFIG_LLC2 is not set
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m
CONFIG_DEV_APPLETALK=m
# CONFIG_LTPC is not set
# CONFIG_COPS is not set
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
CONFIG_WAN_ROUTER=m

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_FIFO=y
# CONFIG_NET_SCH_CLK_JIFFIES is not set
CONFIG_NET_SCH_CLK_GETTIMEOFDAY=y
# CONFIG_NET_SCH_CLK_CPU is not set

#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_ATM=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_INGRESS=m

#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
CONFIG_NET_EMATCH_U32=m
CONFIG_NET_EMATCH_META=m
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=m
CONFIG_NET_ACT_IPT=m
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m
CONFIG_NET_CLS_IND=y
CONFIG_NET_ESTIMATOR=y

#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_NET_TCPPROBE is not set
# CONFIG_HAMRADIO is not set
CONFIG_IRDA=m

#
# IrDA protocols
#
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
# CONFIG_IRDA_ULTRA is not set

#
# IrDA options
#
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
# CONFIG_IRDA_DEBUG is not set

#
# Infrared-port device drivers
#

#
# SIR device drivers
#
CONFIG_IRTTY_SIR=m

#
# Dongle support
#
CONFIG_DONGLE=y
CONFIG_ESI_DONGLE=m
CONFIG_ACTISYS_DONGLE=m
CONFIG_TEKRAM_DONGLE=m
CONFIG_TOIM3232_DONGLE=m
CONFIG_LITELINK_DONGLE=m
CONFIG_MA600_DONGLE=m
CONFIG_GIRBIL_DONGLE=m
CONFIG_MCP2120_DONGLE=m
CONFIG_OLD_BELKIN_DONGLE=m
CONFIG_ACT200L_DONGLE=m

#
# Old SIR device drivers
#

#
# Old Serial dongle support
#

#
# FIR device drivers
#
CONFIG_USB_IRDA=m
CONFIG_SIGMATEL_FIR=m
CONFIG_NSC_FIR=m
CONFIG_WINBOND_FIR=m
CONFIG_TOSHIBA_FIR=m
CONFIG_SMC_IRCC_FIR=m
CONFIG_ALI_FIR=m
CONFIG_VLSI_FIR=m
CONFIG_VIA_FIR=m
CONFIG_MCS_FIR=m
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_CMTP=m
CONFIG_BT_HIDP=m

#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m
CONFIG_IEEE80211=m
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=m
CONFIG_IEEE80211_CRYPT_CCMP=m
CONFIG_IEEE80211_CRYPT_TKIP=m
CONFIG_IEEE80211_SOFTMAC=m
CONFIG_IEEE80211_SOFTMAC_DEBUG=y
CONFIG_WIRELESS_EXT=y
CONFIG_FIB_RULES=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set

#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_CONCAT=m
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_REDBOOT_PARTS=m
CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1
# CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set
# CONFIG_MTD_REDBOOT_PARTS_READONLY is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLKDEVS=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_BLOCK_RO=m
CONFIG_FTL=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y
CONFIG_INFTL=m
CONFIG_RFD_FTL=m
# CONFIG_SSFDC is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_GEN_PROBE=m
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=m
CONFIG_MTD_CFI_AMDSTD=m
CONFIG_MTD_CFI_STAA=m
CONFIG_MTD_CFI_UTIL=m
CONFIG_MTD_RAM=m
CONFIG_MTD_ROM=m
CONFIG_MTD_ABSENT=m
# CONFIG_MTD_OBSOLETE_CHIPS is not set

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PNC2000 is not set
CONFIG_MTD_SC520CDP=m
CONFIG_MTD_NETSC520=m
CONFIG_MTD_TS5500=m
# CONFIG_MTD_SBC_GXX is not set
# CONFIG_MTD_AMD76XROM is not set
# CONFIG_MTD_ICHXROM is not set
# CONFIG_MTD_ESB2ROM is not set
# CONFIG_MTD_CK804XROM is not set
CONFIG_MTD_SCB2_FLASH=m
# CONFIG_MTD_NETtel is not set
# CONFIG_MTD_DILNETPC is not set
# CONFIG_MTD_L440GX is not set
CONFIG_MTD_PCI=m
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
CONFIG_MTD_PMC551=m
# CONFIG_MTD_PMC551_BUGFIX is not set
# CONFIG_MTD_PMC551_DEBUG is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
CONFIG_MTD_MTDRAM=m
CONFIG_MTDRAM_TOTAL_SIZE=4096
CONFIG_MTDRAM_ERASE_SIZE=128
CONFIG_MTD_BLOCK2MTD=m

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set

#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
CONFIG_MTD_NAND_ECC_SMC=y
CONFIG_MTD_NAND_IDS=m
CONFIG_MTD_NAND_DISKONCHIP=m
# CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set
CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0
# CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set
# CONFIG_MTD_NAND_CAFE is not set
CONFIG_MTD_NAND_CS553X=m
CONFIG_MTD_NAND_NANDSIM=m

#
# OneNAND Flash Device Drivers
#
# CONFIG_MTD_ONENAND is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
# CONFIG_PARPORT_PC_FIFO is not set
# CONFIG_PARPORT_PC_SUPERIO is not set
CONFIG_PARPORT_PC_PCMCIA=m
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PARPORT_NOT_PC=y

#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_ISAPNP=y
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y

#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
CONFIG_PARIDE=m

#
# Parallel IDE high-level drivers
#
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m

#
# Parallel IDE protocol modules
#
CONFIG_PARIDE_ATEN=m
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_BPCK6=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
CONFIG_PARIDE_EPATC8=y
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_CRYPTOLOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_SX8=m
CONFIG_BLK_DEV_UB=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_BLK_DEV_RAM_BLOCKSIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
CONFIG_ATA_OVER_ETH=m

#
# Misc devices
#
CONFIG_IBM_ASM=m
# CONFIG_SGI_IOC4 is not set
CONFIG_TIFM_CORE=m
CONFIG_TIFM_7XX1=m
# CONFIG_ASUS_LAPTOP is not set
CONFIG_MSI_LAPTOP=m
# CONFIG_SONY_LAPTOP is not set

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECS=m
# CONFIG_BLK_DEV_DELKIN is not set
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_BLK_DEV_IDEACPI is not set
CONFIG_IDE_TASK_IOCTL=y

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_CMD640=y
CONFIG_BLK_DEV_CMD640_ENHANCED=y
CONFIG_BLK_DEV_IDEPNP=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_AEC62XX=y
CONFIG_BLK_DEV_ALI15X3=y
# CONFIG_WDC_ALI15X3 is not set
CONFIG_BLK_DEV_AMD74XX=y
CONFIG_BLK_DEV_ATIIXP=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_TRIFLEX=y
# CONFIG_BLK_DEV_CY82C693 is not set
CONFIG_BLK_DEV_CS5520=y
CONFIG_BLK_DEV_CS5530=y
CONFIG_BLK_DEV_CS5535=y
CONFIG_BLK_DEV_HPT34X=y
# CONFIG_HPT34X_AUTODMA is not set
CONFIG_BLK_DEV_HPT366=y
CONFIG_BLK_DEV_JMICRON=m
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT8213 is not set
CONFIG_BLK_DEV_IT821X=y
# CONFIG_BLK_DEV_NS87415 is not set
CONFIG_BLK_DEV_PDC202XX_OLD=y
# CONFIG_PDC202XX_BURST is not set
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_BLK_DEV_SVWKS=y
CONFIG_BLK_DEV_SIIMAGE=y
CONFIG_BLK_DEV_SIS5513=y
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=y
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_IVB is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
CONFIG_SCSI_TGT=m
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=m

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=y
CONFIG_SCSI_SAS_LIBSAS=y
# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set

#
# SCSI low-level drivers
#
CONFIG_ISCSI_TCP=m
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_3W_9XXX=m
# CONFIG_SCSI_7000FASST is not set
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=y
CONFIG_AIC7XXX_CMDS_PER_DEVICE=4
CONFIG_AIC7XXX_RESET_DELAY_MS=1000
# CONFIG_AIC7XXX_DEBUG_ENABLE is not set
CONFIG_AIC7XXX_DEBUG_MASK=0
# CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_SCSI_AIC79XX=y
CONFIG_AIC79XX_CMDS_PER_DEVICE=4
CONFIG_AIC79XX_RESET_DELAY_MS=1000
# CONFIG_AIC79XX_ENABLE_RD_STRM is not set
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC94XX=y
# CONFIG_AIC94XX_DEBUG is not set
# CONFIG_SCSI_DPT_I2O is not set
CONFIG_SCSI_ADVANSYS=m
# CONFIG_SCSI_IN2000 is not set
CONFIG_SCSI_ARCMSR=m
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
CONFIG_MEGARAID_MAILBOX=m
CONFIG_MEGARAID_LEGACY=m
CONFIG_MEGARAID_SAS=m
CONFIG_SCSI_HPTIOP=m
CONFIG_SCSI_BUSLOGIC=m
# CONFIG_SCSI_OMIT_FLASHPOINT is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INITIO=m
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
# CONFIG_SCSI_NCR53C406A is not set
CONFIG_SCSI_STEX=m
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
CONFIG_SCSI_SYM53C8XX_MMIO=y
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_QLA_FC=m
CONFIG_SCSI_QLA_ISCSI=m
CONFIG_SCSI_LPFC=m
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_SYM53C416 is not set
CONFIG_SCSI_DC395x=m
CONFIG_SCSI_DC390T=m
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
CONFIG_SCSI_SRP=m

#
# PCMCIA SCSI adapter support
#
CONFIG_PCMCIA_AHA152X=m
CONFIG_PCMCIA_FDOMAIN=m
CONFIG_PCMCIA_NINJA_SCSI=m
CONFIG_PCMCIA_QLOGIC=m
CONFIG_PCMCIA_SYM53C500=m

#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_SATA_AHCI=y
CONFIG_SATA_SVW=y
CONFIG_ATA_PIIX=y
CONFIG_SATA_MV=y
CONFIG_SATA_NV=y
CONFIG_PDC_ADMA=y
CONFIG_SATA_QSTOR=y
CONFIG_SATA_PROMISE=y
CONFIG_SATA_SX4=y
CONFIG_SATA_SIL=y
CONFIG_SATA_SIL24=y
CONFIG_SATA_SIS=y
CONFIG_SATA_ULI=y
CONFIG_SATA_VIA=y
CONFIG_SATA_VITESSE=y
# CONFIG_SATA_INIC162X is not set
CONFIG_SATA_INTEL_COMBINED=y
CONFIG_SATA_ACPI=y
CONFIG_PATA_ALI=y
CONFIG_PATA_AMD=y
CONFIG_PATA_ARTOP=y
CONFIG_PATA_ATIIXP=y
CONFIG_PATA_CMD64X=y
CONFIG_PATA_CS5520=y
CONFIG_PATA_CS5530=y
CONFIG_PATA_CS5535=y
CONFIG_PATA_CYPRESS=y
CONFIG_PATA_EFAR=y
CONFIG_ATA_GENERIC=y
CONFIG_PATA_HPT366=y
CONFIG_PATA_HPT37X=y
CONFIG_PATA_HPT3X2N=y
CONFIG_PATA_HPT3X3=y
CONFIG_PATA_ISAPNP=y
CONFIG_PATA_IT821X=y
# CONFIG_PATA_IT8213 is not set
CONFIG_PATA_JMICRON=y
CONFIG_PATA_LEGACY=m
CONFIG_PATA_TRIFLEX=y
CONFIG_PATA_MARVELL=y
CONFIG_PATA_MPIIX=y
CONFIG_PATA_OLDPIIX=y
CONFIG_PATA_NETCELL=y
CONFIG_PATA_NS87410=y
CONFIG_PATA_OPTI=y
CONFIG_PATA_OPTIDMA=y
CONFIG_PATA_PCMCIA=y
CONFIG_PATA_PDC_OLD=y
CONFIG_PATA_QDI=y
CONFIG_PATA_RADISYS=y
CONFIG_PATA_RZ1000=y
CONFIG_PATA_SC1200=y
CONFIG_PATA_SERVERWORKS=y
CONFIG_PATA_PDC2027X=y
CONFIG_PATA_SIL680=y
CONFIG_PATA_SIS=y
CONFIG_PATA_VIA=y
CONFIG_PATA_WINBOND=y
CONFIG_PATA_WINBOND_VLB=y

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_RAID5_RESHAPE=y
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
CONFIG_DM_ZERO=m
CONFIG_DM_MULTIPATH=m
CONFIG_DM_MULTIPATH_EMC=m

#
# Fusion MPT device support
#
CONFIG_FUSION=y
CONFIG_FUSION_SPI=m
CONFIG_FUSION_FC=m
CONFIG_FUSION_SAS=m
CONFIG_FUSION_MAX_SGE=40
CONFIG_FUSION_CTL=m
CONFIG_FUSION_LAN=m

#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=m

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
CONFIG_IEEE1394_CONFIG_ROM_IP1394=y

#
# Device Drivers
#
CONFIG_IEEE1394_PCILYNX=m
CONFIG_IEEE1394_OHCI1394=m

#
# Protocol Drivers
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_DV1394=m
CONFIG_IEEE1394_RAWIO=m

#
# I2O device support
#
CONFIG_I2O=m
# CONFIG_I2O_LCT_NOTIFY_ON_CHANGES is not set
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_CONFIG=m
CONFIG_I2O_CONFIG_OLD_IOCTL=y
CONFIG_I2O_BUS=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m

#
# Macintosh device drivers
#
# CONFIG_MAC_EMUMOUSEBTN is not set

#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_IFB=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_NET_SB1000=m

#
# ARCnet devices
#
# CONFIG_ARCNET is not set

#
# PHY device support
#
CONFIG_PHYLIB=m

#
# MII PHY device drivers
#
CONFIG_MARVELL_PHY=m
CONFIG_DAVICOM_PHY=m
CONFIG_QSEMI_PHY=m
CONFIG_LXT_PHY=m
CONFIG_CICADA_PHY=m
CONFIG_VITESSE_PHY=m
CONFIG_SMSC_PHY=m
CONFIG_BROADCOM_PHY=m
CONFIG_FIXED_PHY=m
CONFIG_FIXED_MII_10_FDX=y
CONFIG_FIXED_MII_100_FDX=y

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_HAPPYMEAL=m
CONFIG_SUNGEM=m
CONFIG_CASSINI=m
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
CONFIG_EL3=m
# CONFIG_3C515 is not set
CONFIG_VORTEX=m
CONFIG_TYPHOON=m
# CONFIG_LANCE is not set
CONFIG_NET_VENDOR_SMC=y
# CONFIG_WD80x3 is not set
CONFIG_ULTRA=m
# CONFIG_SMC9194 is not set
# CONFIG_NET_VENDOR_RACAL is not set

#
# Tulip family network device support
#
CONFIG_NET_TULIP=y
CONFIG_DE2104X=m
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
CONFIG_TULIP_MMIO=y
# CONFIG_TULIP_NAPI is not set
CONFIG_DE4X5=m
CONFIG_WINBOND_840=m
CONFIG_DM9102=m
CONFIG_ULI526X=m
CONFIG_PCMCIA_XIRCOM=m
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
CONFIG_NET_ISA=y
# CONFIG_E2100 is not set
CONFIG_EWRK3=m
# CONFIG_EEXPRESS is not set
# CONFIG_EEXPRESS_PRO is not set
# CONFIG_HPLAN_PLUS is not set
# CONFIG_HPLAN is not set
# CONFIG_LP486E is not set
# CONFIG_ETH16I is not set
CONFIG_NE2000=m
# CONFIG_ZNET is not set
# CONFIG_SEEQ8005 is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_PCNET32_NAPI=y
CONFIG_AMD8111_ETH=m
CONFIG_AMD8111E_NAPI=y
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_ADAPTEC_STARFIRE_NAPI=y
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
CONFIG_B44=m
CONFIG_FORCEDETH=y
CONFIG_FORCEDETH_NAPI=y
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_8139CP=y
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
# CONFIG_SUNDANCE_MMIO is not set
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
CONFIG_VIA_RHINE_MMIO=y
CONFIG_VIA_RHINE_NAPI=y
# CONFIG_SC92031 is not set
CONFIG_NET_POCKET=y
CONFIG_ATP=m
CONFIG_DE600=m
CONFIG_DE620=m

#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
CONFIG_E1000=y
CONFIG_E1000_NAPI=y
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_R8169=m
CONFIG_R8169_NAPI=y
CONFIG_R8169_VLAN=y
CONFIG_SIS190=m
CONFIG_SKGE=y
CONFIG_SKY2=m
# CONFIG_SK98LIN is not set
CONFIG_VIA_VELOCITY=m
CONFIG_TIGON3=y
CONFIG_BNX2=m
CONFIG_QLA3XXX=m
# CONFIG_ATL1 is not set

#
# Ethernet (10000 Mbit)
#
CONFIG_CHELSIO_T1=m
CONFIG_CHELSIO_T1_1G=y
CONFIG_CHELSIO_T1_NAPI=y
# CONFIG_CHELSIO_T3 is not set
CONFIG_IXGB=m
CONFIG_IXGB_NAPI=y
CONFIG_S2IO=m
CONFIG_S2IO_NAPI=y
CONFIG_MYRI10GE=m
CONFIG_NETXEN_NIC=m

#
# Token Ring devices
#
CONFIG_TR=y
# CONFIG_IBMTR is not set
CONFIG_IBMOL=m
CONFIG_IBMLS=m
CONFIG_3C359=m
# CONFIG_TMS380TR is not set
# CONFIG_SMCTR is not set

#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
CONFIG_NET_WIRELESS_RTNETLINK=y

#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
# CONFIG_ARLAN is not set
# CONFIG_WAVELAN is not set
CONFIG_PCMCIA_WAVELAN=m
CONFIG_PCMCIA_NETWAVE=m

#
# Wireless 802.11 Frequency Hopping cards support
#
# CONFIG_PCMCIA_RAYCS is not set

#
# Wireless 802.11b ISA/PCI cards support
#
CONFIG_IPW2100=m
CONFIG_IPW2100_MONITOR=y
# CONFIG_IPW2100_DEBUG is not set
CONFIG_IPW2200=m
CONFIG_IPW2200_MONITOR=y
CONFIG_IPW2200_RADIOTAP=y
CONFIG_IPW2200_PROMISCUOUS=y
CONFIG_IPW2200_QOS=y
# CONFIG_IPW2200_DEBUG is not set
CONFIG_AIRO=m
CONFIG_HERMES=m
CONFIG_PLX_HERMES=m
CONFIG_TMD_HERMES=m
CONFIG_NORTEL_HERMES=m
CONFIG_PCI_HERMES=m
CONFIG_ATMEL=m
CONFIG_PCI_ATMEL=m

#
# Wireless 802.11b Pcmcia/Cardbus cards support
#
CONFIG_PCMCIA_HERMES=m
CONFIG_PCMCIA_SPECTRUM=m
CONFIG_AIRO_CS=m
CONFIG_PCMCIA_ATMEL=m
CONFIG_PCMCIA_WL3501=m

#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
CONFIG_PRISM54=m
CONFIG_USB_ZD1201=m
CONFIG_HOSTAP=m
CONFIG_HOSTAP_FIRMWARE=y
CONFIG_HOSTAP_FIRMWARE_NVRAM=y
CONFIG_HOSTAP_PLX=m
CONFIG_HOSTAP_PCI=m
CONFIG_HOSTAP_CS=m
CONFIG_BCM43XX=m
CONFIG_BCM43XX_DEBUG=y
CONFIG_BCM43XX_DMA=y
CONFIG_BCM43XX_PIO=y
CONFIG_BCM43XX_DMA_AND_PIO_MODE=y
# CONFIG_BCM43XX_DMA_MODE is not set
# CONFIG_BCM43XX_PIO_MODE is not set
CONFIG_ZD1211RW=m
# CONFIG_ZD1211RW_DEBUG is not set
CONFIG_NET_WIRELESS=y

#
# PCMCIA network device support
#
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_3C589=m
CONFIG_PCMCIA_3C574=m
CONFIG_PCMCIA_FMVJ18X=m
CONFIG_PCMCIA_PCNET=m
CONFIG_PCMCIA_NMCLAN=m
CONFIG_PCMCIA_SMC91C92=m
CONFIG_PCMCIA_XIRC2PS=m
CONFIG_PCMCIA_AXNET=m
CONFIG_PCMCIA_IBMTR=m

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# ATM drivers
#
# CONFIG_ATM_DUMMY is not set
CONFIG_ATM_TCP=m
CONFIG_ATM_LANAI=m
CONFIG_ATM_ENI=m
# CONFIG_ATM_ENI_DEBUG is not set
# CONFIG_ATM_ENI_TUNE_BURST is not set
CONFIG_ATM_FIRESTREAM=m
# CONFIG_ATM_ZATM is not set
CONFIG_ATM_NICSTAR=m
# CONFIG_ATM_NICSTAR_USE_SUNI is not set
# CONFIG_ATM_NICSTAR_USE_IDT77105 is not set
CONFIG_ATM_IDT77252=m
# CONFIG_ATM_IDT77252_DEBUG is not set
# CONFIG_ATM_IDT77252_RCV_ALL is not set
CONFIG_ATM_IDT77252_USE_SUNI=y
CONFIG_ATM_AMBASSADOR=m
# CONFIG_ATM_AMBASSADOR_DEBUG is not set
CONFIG_ATM_HORIZON=m
# CONFIG_ATM_HORIZON_DEBUG is not set
# CONFIG_ATM_IA is not set
CONFIG_ATM_FORE200E_MAYBE=m
# CONFIG_ATM_FORE200E_PCA is not set
CONFIG_ATM_HE=m
# CONFIG_ATM_HE_USE_SUNI is not set
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
CONFIG_SKFP=m
# CONFIG_HIPPI is not set
CONFIG_PLIP=m
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
# CONFIG_PPP_BSDCOMP is not set
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLHC=m
CONFIG_SLIP_SMART=y
# CONFIG_SLIP_MODE_SLIP6 is not set
CONFIG_NET_FC=y
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set

#
# ISDN subsystem
#
CONFIG_ISDN=m

#
# Old ISDN4Linux
#
CONFIG_ISDN_I4L=m
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_MPP=y
CONFIG_IPPP_FILTER=y
# CONFIG_ISDN_PPP_BSDCOMP is not set
CONFIG_ISDN_AUDIO=y
CONFIG_ISDN_TTY_FAX=y

#
# ISDN feature submodules
#
CONFIG_ISDN_DIVERSION=m

#
# ISDN4Linux hardware drivers
#

#
# Passive cards
#
CONFIG_ISDN_DRV_HISAX=m

#
# D-channel protocol features
#
CONFIG_HISAX_EURO=y
CONFIG_DE_AOC=y
CONFIG_HISAX_NO_SENDCOMPLETE=y
CONFIG_HISAX_NO_LLC=y
CONFIG_HISAX_NO_KEYPAD=y
CONFIG_HISAX_1TR6=y
CONFIG_HISAX_NI1=y
CONFIG_HISAX_MAX_CARDS=8

#
# HiSax supported cards
#
# CONFIG_HISAX_16_0 is not set
CONFIG_HISAX_16_3=y
CONFIG_HISAX_TELESPCI=y
CONFIG_HISAX_S0BOX=y
# CONFIG_HISAX_AVM_A1 is not set
CONFIG_HISAX_FRITZPCI=y
CONFIG_HISAX_AVM_A1_PCMCIA=y
CONFIG_HISAX_ELSA=y
# CONFIG_HISAX_IX1MICROR2 is not set
CONFIG_HISAX_DIEHLDIVA=y
# CONFIG_HISAX_ASUSCOM is not set
# CONFIG_HISAX_TELEINT is not set
# CONFIG_HISAX_HFCS is not set
CONFIG_HISAX_SEDLBAUER=y
# CONFIG_HISAX_SPORTSTER is not set
# CONFIG_HISAX_MIC is not set
CONFIG_HISAX_NETJET=y
CONFIG_HISAX_NETJET_U=y
CONFIG_HISAX_NICCY=y
# CONFIG_HISAX_ISURF is not set
# CONFIG_HISAX_HSTSAPHIR is not set
CONFIG_HISAX_BKM_A4T=y
CONFIG_HISAX_SCT_QUADRO=y
CONFIG_HISAX_GAZEL=y
CONFIG_HISAX_HFC_PCI=y
CONFIG_HISAX_W6692=y
CONFIG_HISAX_HFC_SX=y
CONFIG_HISAX_ENTERNOW_PCI=y
# CONFIG_HISAX_DEBUG is not set

#
# HiSax PCMCIA card service modules
#
CONFIG_HISAX_SEDLBAUER_CS=m
CONFIG_HISAX_ELSA_CS=m
CONFIG_HISAX_AVM_A1_CS=m
CONFIG_HISAX_TELES_CS=m

#
# HiSax sub driver modules
#
CONFIG_HISAX_ST5481=m
# CONFIG_HISAX_HFCUSB is not set
CONFIG_HISAX_HFC4S8S=m
CONFIG_HISAX_FRITZ_PCIPNP=m
CONFIG_HISAX_HDLC=y

#
# Active cards
#
# CONFIG_ISDN_DRV_ICN is not set
# CONFIG_ISDN_DRV_PCBIT is not set
# CONFIG_ISDN_DRV_SC is not set
# CONFIG_ISDN_DRV_ACT2000 is not set

#
# Siemens Gigaset
#
CONFIG_ISDN_DRV_GIGASET=m
CONFIG_GIGASET_BASE=m
CONFIG_GIGASET_M105=m
# CONFIG_GIGASET_M101 is not set
# CONFIG_GIGASET_DEBUG is not set
# CONFIG_GIGASET_UNDOCREQ is not set

#
# CAPI subsystem
#
CONFIG_ISDN_CAPI=m
CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPI20=m
CONFIG_ISDN_CAPI_CAPIFS_BOOL=y
CONFIG_ISDN_CAPI_CAPIFS=m
CONFIG_ISDN_CAPI_CAPIDRV=m

#
# CAPI hardware drivers
#

#
# Active AVM cards
#
CONFIG_CAPI_AVM=y
# CONFIG_ISDN_DRV_AVMB1_B1ISA is not set
CONFIG_ISDN_DRV_AVMB1_B1PCI=m
CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y
# CONFIG_ISDN_DRV_AVMB1_T1ISA is not set
CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m
CONFIG_ISDN_DRV_AVMB1_AVM_CS=m
CONFIG_ISDN_DRV_AVMB1_T1PCI=m
CONFIG_ISDN_DRV_AVMB1_C4=m

#
# Active Eicon DIVA Server cards
#
CONFIG_CAPI_EICON=y
CONFIG_ISDN_DIVAS=m
CONFIG_ISDN_DIVAS_BRIPCI=y
CONFIG_ISDN_DIVAS_PRIPCI=y
CONFIG_ISDN_DIVAS_DIVACAPI=m
CONFIG_ISDN_DIVAS_USERIDI=m
CONFIG_ISDN_DIVAS_MAINT=m

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
# CONFIG_INPUT_TSDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
CONFIG_KEYBOARD_STOWAWAY=m
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_SERIAL=m
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
CONFIG_MOUSE_VSXXXAA=m
CONFIG_INPUT_JOYSTICK=y
CONFIG_JOYSTICK_ANALOG=m
CONFIG_JOYSTICK_A3D=m
CONFIG_JOYSTICK_ADI=m
CONFIG_JOYSTICK_COBRA=m
CONFIG_JOYSTICK_GF2K=m
CONFIG_JOYSTICK_GRIP=m
CONFIG_JOYSTICK_GRIP_MP=m
CONFIG_JOYSTICK_GUILLEMOT=m
CONFIG_JOYSTICK_INTERACT=m
CONFIG_JOYSTICK_SIDEWINDER=m
CONFIG_JOYSTICK_TMDC=m
CONFIG_JOYSTICK_IFORCE=m
CONFIG_JOYSTICK_IFORCE_USB=y
CONFIG_JOYSTICK_IFORCE_232=y
CONFIG_JOYSTICK_WARRIOR=m
CONFIG_JOYSTICK_MAGELLAN=m
CONFIG_JOYSTICK_SPACEORB=m
CONFIG_JOYSTICK_SPACEBALL=m
CONFIG_JOYSTICK_STINGER=m
CONFIG_JOYSTICK_TWIDJOY=m
CONFIG_JOYSTICK_DB9=m
CONFIG_JOYSTICK_GAMECON=m
CONFIG_JOYSTICK_TURBOGRAFX=m
CONFIG_JOYSTICK_JOYDUMP=m
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_TOUCHSCREEN_ELO=m
CONFIG_TOUCHSCREEN_MTOUCH=m
CONFIG_TOUCHSCREEN_MK712=m
CONFIG_TOUCHSCREEN_PENMOUNT=m
CONFIG_TOUCHSCREEN_TOUCHRIGHT=m
CONFIG_TOUCHSCREEN_TOUCHWIN=m
CONFIG_TOUCHSCREEN_UCB1400=m
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_WISTRON_BTNS=m
# CONFIG_INPUT_ATLAS_BTNS is not set
CONFIG_INPUT_UINPUT=m

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
CONFIG_SERIO_RAW=m
CONFIG_GAMEPORT=m
CONFIG_GAMEPORT_NS558=m
CONFIG_GAMEPORT_L4=m
CONFIG_GAMEPORT_EMU10K1=m
CONFIG_GAMEPORT_FM801=m

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
# CONFIG_ROCKETPORT is not set
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_ESPSERIAL is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
CONFIG_MOXA_SMARTIO_NEW=m
# CONFIG_ISI is not set
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_SYNCLINK_GT=m
CONFIG_N_HDLC=m
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
# CONFIG_SERIAL_8250_FOURPORT is not set
# CONFIG_SERIAL_8250_ACCENT is not set
# CONFIG_SERIAL_8250_BOCA is not set
CONFIG_SERIAL_8250_EXAR_ST16C554=m
# CONFIG_SERIAL_8250_HUB6 is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_SERIAL_JSM=m
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
CONFIG_TIPAR=m

#
# IPMI
#
CONFIG_IPMI_HANDLER=m
# CONFIG_IPMI_PANIC_EVENT is not set
CONFIG_IPMI_DEVICE_INTERFACE=m
CONFIG_IPMI_SI=m
CONFIG_IPMI_WATCHDOG=m
CONFIG_IPMI_POWEROFF=m

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
CONFIG_SOFT_WATCHDOG=m
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
CONFIG_ALIM1535_WDT=m
CONFIG_ALIM7101_WDT=m
# CONFIG_SC520_WDT is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
CONFIG_IBMASR=m
# CONFIG_WAFER_WDT is not set
CONFIG_I6300ESB_WDT=m
CONFIG_I8XX_TCO=m
CONFIG_ITCO_WDT=m
CONFIG_ITCO_VENDOR_SUPPORT=y
# CONFIG_SC1200_WDT is not set
CONFIG_PC87413_WDT=m
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
CONFIG_W83627HF_WDT=m
CONFIG_W83697HF_WDT=m
CONFIG_W83877F_WDT=m
CONFIG_W83977F_WDT=m
CONFIG_MACHZ_WDT=m
# CONFIG_SBC_EPX_C3_WATCHDOG is not set

#
# ISA-based Watchdog Cards
#
# CONFIG_PCWATCHDOG is not set
# CONFIG_MIXCOMWD is not set
# CONFIG_WDT is not set

#
# PCI-based Watchdog Cards
#
CONFIG_PCIPCWATCHDOG=m
CONFIG_WDTPCI=m
CONFIG_WDT_501_PCI=y

#
# USB-based Watchdog Cards
#
CONFIG_USBPCWATCHDOG=m
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_GEODE=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_NVRAM=y
CONFIG_RTC=y
CONFIG_DTLK=m
CONFIG_R3964=m
# CONFIG_APPLICOM is not set
CONFIG_SONYPI=m
CONFIG_AGP=y
CONFIG_AGP_ALI=y
CONFIG_AGP_ATI=y
CONFIG_AGP_AMD=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_NVIDIA=y
CONFIG_AGP_SIS=y
CONFIG_AGP_SWORKS=y
CONFIG_AGP_VIA=y
CONFIG_AGP_EFFICEON=y
CONFIG_DRM=m
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
CONFIG_DRM_I830=m
CONFIG_DRM_I915=m
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=m

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
CONFIG_CARDMAN_4000=m
CONFIG_CARDMAN_4040=m
CONFIG_MWAVE=m
CONFIG_PC8736x_GPIO=m
CONFIG_NSC_GPIO=m
CONFIG_CS5535_GPIO=m
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
# CONFIG_HPET_MMAP is not set
CONFIG_HANGCHECK_TIMER=m

#
# TPM devices
#
CONFIG_TCG_TPM=m
CONFIG_TCG_TIS=m
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
CONFIG_TCG_INFINEON=m
# CONFIG_TELCLOCK is not set

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD756_S4882=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_I810=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_ISA=m
CONFIG_I2C_NFORCE2=m
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_PASEMI is not set
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
# CONFIG_SCx200_ACB is not set
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
CONFIG_I2C_STUB=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_I2C_VOODOO3=m
CONFIG_I2C_PCA_ISA=m

#
# Miscellaneous I2C Chip support
#
CONFIG_SENSORS_DS1337=m
CONFIG_SENSORS_DS1374=m
CONFIG_SENSORS_EEPROM=m
CONFIG_SENSORS_PCF8574=m
CONFIG_SENSORS_PCA9539=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_MAX6875=m
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set

#
# Dallas's 1-wire bus
#
CONFIG_W1=m
CONFIG_W1_CON=y

#
# 1-wire Bus Masters
#
CONFIG_W1_MASTER_MATROX=m
CONFIG_W1_MASTER_DS2490=m
CONFIG_W1_MASTER_DS2482=m

#
# 1-wire Slaves
#
CONFIG_W1_SLAVE_THERM=m
CONFIG_W1_SLAVE_SMEM=m
CONFIG_W1_SLAVE_DS2433=m
CONFIG_W1_SLAVE_DS2433_CRC=y

#
# Hardware Monitoring support
#
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
CONFIG_SENSORS_ABITUGURU=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
# CONFIG_SENSORS_ADM1029 is not set
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_F71805F=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_FSCPOS=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
CONFIG_SENSORS_IT87=m
CONFIG_SENSORS_LM63=m
CONFIG_SENSORS_LM75=m
CONFIG_SENSORS_LM77=m
CONFIG_SENSORS_LM78=m
CONFIG_SENSORS_LM80=m
CONFIG_SENSORS_LM83=m
CONFIG_SENSORS_LM85=m
CONFIG_SENSORS_LM87=m
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_LM92=m
CONFIG_SENSORS_MAX1619=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_SIS5595=m
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_SMSC47M192=m
CONFIG_SENSORS_SMSC47B397=m
CONFIG_SENSORS_VIA686A=m
CONFIG_SENSORS_VT1211=m
CONFIG_SENSORS_VT8231=m
CONFIG_SENSORS_W83781D=m
CONFIG_SENSORS_W83791D=m
CONFIG_SENSORS_W83792D=m
CONFIG_SENSORS_W83793=m
CONFIG_SENSORS_W83L785TS=m
CONFIG_SENSORS_W83627HF=m
CONFIG_SENSORS_W83627EHF=m
CONFIG_SENSORS_HDAPS=m
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y

#
# Video Capture Adapters
#

#
# Video Capture Adapters
#
# CONFIG_VIDEO_ADV_DEBUG is not set
CONFIG_VIDEO_HELPER_CHIPS_AUTO=y
CONFIG_VIDEO_TVAUDIO=m
CONFIG_VIDEO_TDA7432=m
CONFIG_VIDEO_TDA9840=m
CONFIG_VIDEO_TDA9875=m
CONFIG_VIDEO_TEA6415C=m
CONFIG_VIDEO_TEA6420=m
CONFIG_VIDEO_MSP3400=m
CONFIG_VIDEO_WM8775=m
CONFIG_VIDEO_BT819=m
CONFIG_VIDEO_BT856=m
CONFIG_VIDEO_KS0127=m
CONFIG_VIDEO_OV7670=m
CONFIG_VIDEO_SAA7110=m
CONFIG_VIDEO_SAA7111=m
CONFIG_VIDEO_SAA7114=m
CONFIG_VIDEO_SAA711X=m
CONFIG_VIDEO_TVP5150=m
CONFIG_VIDEO_VPX3220=m
CONFIG_VIDEO_CX25840=m
CONFIG_VIDEO_CX2341X=m
CONFIG_VIDEO_SAA7185=m
CONFIG_VIDEO_ADV7170=m
CONFIG_VIDEO_ADV7175=m
# CONFIG_VIDEO_VIVI is not set
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_BT848_DVB=y
CONFIG_VIDEO_SAA6588=m
# CONFIG_VIDEO_PMS is not set
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_CPIA2=m
CONFIG_VIDEO_SAA5246A=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN_ZR36060=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_DC30=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZORAN_LML33R10=m
CONFIG_VIDEO_ZORAN_AVS6EYES=m
CONFIG_VIDEO_MEYE=m
CONFIG_VIDEO_SAA7134=m
CONFIG_VIDEO_SAA7134_ALSA=m
CONFIG_VIDEO_SAA7134_DVB=m
CONFIG_VIDEO_MXB=m
CONFIG_VIDEO_DPC=m
CONFIG_VIDEO_HEXIUM_ORION=m
CONFIG_VIDEO_HEXIUM_GEMINI=m
CONFIG_VIDEO_CX88=m
CONFIG_VIDEO_CX88_ALSA=m
CONFIG_VIDEO_CX88_BLACKBIRD=m
CONFIG_VIDEO_CX88_DVB=m
CONFIG_VIDEO_CX88_VP3054=m
CONFIG_VIDEO_CAFE_CCIC=m

#
# V4L USB devices
#
CONFIG_VIDEO_PVRUSB2=m
# CONFIG_VIDEO_PVRUSB2_29XXX is not set
CONFIG_VIDEO_PVRUSB2_24XXX=y
CONFIG_VIDEO_PVRUSB2_SYSFS=y
# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set
CONFIG_VIDEO_EM28XX=m
CONFIG_VIDEO_USBVISION=m
CONFIG_VIDEO_USBVIDEO=m
CONFIG_USB_VICAM=m
CONFIG_USB_IBMCAM=m
CONFIG_USB_KONICAWC=m
CONFIG_USB_QUICKCAM_MESSENGER=m
CONFIG_USB_ET61X251=m
CONFIG_VIDEO_OVCAMCHIP=m
CONFIG_USB_W9968CF=m
CONFIG_USB_OV511=m
CONFIG_USB_SE401=m
CONFIG_USB_SN9C102=m
CONFIG_USB_STV680=m
CONFIG_USB_ZC0301=m
CONFIG_USB_PWC=m
# CONFIG_USB_PWC_DEBUG is not set

#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
CONFIG_RADIO_GEMTEK_PCI=m
CONFIG_RADIO_MAXIRADIO=m
CONFIG_RADIO_MAESTRO=m
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set
CONFIG_USB_DSBR=m

#
# Digital Video Broadcasting Devices
#
CONFIG_DVB=y
CONFIG_DVB_CORE=m
# CONFIG_DVB_CORE_ATTACH is not set

#
# Supported SAA7146 based PCI Adapters
#
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET=m
CONFIG_DVB_BUDGET_CI=m
CONFIG_DVB_BUDGET_AV=m
CONFIG_DVB_BUDGET_PATCH=m

#
# Supported USB Adapters
#
CONFIG_DVB_USB=m
# CONFIG_DVB_USB_DEBUG is not set
CONFIG_DVB_USB_A800=m
CONFIG_DVB_USB_DIBUSB_MB=m
# CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set
CONFIG_DVB_USB_DIBUSB_MC=m
CONFIG_DVB_USB_DIB0700=m
CONFIG_DVB_USB_UMT_010=m
CONFIG_DVB_USB_CXUSB=m
# CONFIG_DVB_USB_M920X is not set
# CONFIG_DVB_USB_GL861 is not set
# CONFIG_DVB_USB_AU6610 is not set
CONFIG_DVB_USB_DIGITV=m
CONFIG_DVB_USB_VP7045=m
CONFIG_DVB_USB_VP702X=m
CONFIG_DVB_USB_GP8PSK=m
CONFIG_DVB_USB_NOVA_T_USB2=m
CONFIG_DVB_USB_TTUSB2=m
CONFIG_DVB_USB_DTT200U=m
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_DVB_CINERGYT2=m
CONFIG_DVB_CINERGYT2_TUNING=y
CONFIG_DVB_CINERGYT2_STREAM_URB_COUNT=32
CONFIG_DVB_CINERGYT2_STREAM_BUF_SIZE=512
CONFIG_DVB_CINERGYT2_QUERY_INTERVAL=250
CONFIG_DVB_CINERGYT2_ENABLE_RC_INPUT_DEVICE=y
CONFIG_DVB_CINERGYT2_RC_QUERY_INTERVAL=100

#
# Supported FlexCopII (B2C2) Adapters
#
CONFIG_DVB_B2C2_FLEXCOP=m
CONFIG_DVB_B2C2_FLEXCOP_PCI=m
CONFIG_DVB_B2C2_FLEXCOP_USB=m
# CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set

#
# Supported BT878 Adapters
#
CONFIG_DVB_BT8XX=m

#
# Supported Pluto2 Adapters
#
CONFIG_DVB_PLUTO2=m

#
# Supported DVB Frontends
#

#
# Customise DVB Frontends
#
# CONFIG_DVB_FE_CUSTOMISE is not set

#
# DVB-S (satellite) frontends
#
CONFIG_DVB_STV0299=m
CONFIG_DVB_CX24110=m
CONFIG_DVB_CX24123=m
CONFIG_DVB_TDA8083=m
CONFIG_DVB_MT312=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_S5H1420=m
CONFIG_DVB_TDA10086=m

#
# DVB-T (terrestrial) frontends
#
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
CONFIG_DVB_CX22702=m
CONFIG_DVB_L64781=m
CONFIG_DVB_TDA1004X=m
CONFIG_DVB_NXT6000=m
CONFIG_DVB_MT352=m
CONFIG_DVB_ZL10353=m
CONFIG_DVB_DIB3000MB=m
CONFIG_DVB_DIB3000MC=m
CONFIG_DVB_DIB7000M=m
CONFIG_DVB_DIB7000P=m

#
# DVB-C (cable) frontends
#
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
CONFIG_DVB_STV0297=m

#
# ATSC (North American/Korean Terrestrial/Cable DTV) frontends
#
CONFIG_DVB_NXT200X=m
CONFIG_DVB_OR51211=m
CONFIG_DVB_OR51132=m
CONFIG_DVB_BCM3510=m
CONFIG_DVB_LGDT330X=m

#
# Tuners/PLL support
#
CONFIG_DVB_PLL=m
CONFIG_DVB_TDA826X=m
# CONFIG_DVB_TUNER_QT1010 is not set
CONFIG_DVB_TUNER_MT2060=m
CONFIG_DVB_TUNER_LGH06XF=m

#
# Miscellaneous devices
#
CONFIG_DVB_LNBP21=m
CONFIG_DVB_ISL6421=m
CONFIG_DVB_TUA6100=m
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_BUF=m
CONFIG_VIDEO_BUF_DVB=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_IR=m
CONFIG_VIDEO_TVEEPROM=m
CONFIG_USB_DABUSB=m

#
# Graphics support
#
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_BACKLIGHT_PROGEAR is not set
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frambuffer hardware drivers
#
CONFIG_FB_CIRRUS=m
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
CONFIG_FB_VGA16=m
CONFIG_FB_VESA=y
# CONFIG_FB_IMAC is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
CONFIG_FB_NVIDIA=m
CONFIG_FB_NVIDIA_I2C=y
CONFIG_FB_NVIDIA_BACKLIGHT=y
CONFIG_FB_RIVA=m
# CONFIG_FB_RIVA_I2C is not set
# CONFIG_FB_RIVA_DEBUG is not set
CONFIG_FB_RIVA_BACKLIGHT=y
CONFIG_FB_I810=m
CONFIG_FB_I810_GTF=y
CONFIG_FB_I810_I2C=y
CONFIG_FB_INTEL=m
# CONFIG_FB_INTEL_DEBUG is not set
CONFIG_FB_INTEL_I2C=y
CONFIG_FB_MATROX=m
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G=y
CONFIG_FB_MATROX_I2C=m
CONFIG_FB_MATROX_MAVEN=m
CONFIG_FB_MATROX_MULTIHEAD=y
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
CONFIG_FB_ATY128=m
CONFIG_FB_ATY128_BACKLIGHT=y
CONFIG_FB_ATY=m
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GENERIC_LCD=y
CONFIG_FB_ATY_GX=y
CONFIG_FB_ATY_BACKLIGHT=y
# CONFIG_FB_S3 is not set
CONFIG_FB_SAVAGE=m
CONFIG_FB_SAVAGE_I2C=y
CONFIG_FB_SAVAGE_ACCEL=y
# CONFIG_FB_SIS is not set
CONFIG_FB_NEOMAGIC=m
CONFIG_FB_KYRO=m
CONFIG_FB_3DFX=m
CONFIG_FB_3DFX_ACCEL=y
CONFIG_FB_VOODOO1=m
CONFIG_FB_CYBLA=m
CONFIG_FB_TRIDENT=m
CONFIG_FB_TRIDENT_ACCEL=y
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_VIDEO_SELECT=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

#
# Logo configuration
#
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y

#
# Sound
#
CONFIG_SOUND=m

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_RTCTIMER=m
CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_MPU401_UART=m
CONFIG_SND_OPL3_LIB=m
CONFIG_SND_OPL4_LIB=m
CONFIG_SND_VX_LIB=m
CONFIG_SND_AC97_CODEC=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTPAV=m
CONFIG_SND_MTS64=m
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=m
# CONFIG_SND_PORTMAN2X4 is not set

#
# ISA devices
#
CONFIG_SND_CS4231_LIB=m
CONFIG_SND_ADLIB=m
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
CONFIG_SND_CS4236=m
# CONFIG_SND_DT019X is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
CONFIG_SND_ES18XX=m
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
CONFIG_SND_OPL3SA2=m
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
CONFIG_SND_MIRO=m
# CONFIG_SND_SB8 is not set
CONFIG_SND_SB16=m
CONFIG_SND_SBAWE=m
# CONFIG_SND_SB16_CSP is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set

#
# PCI devices
#
CONFIG_SND_AD1889=m
CONFIG_SND_ALS300=m
CONFIG_SND_ALS4000=m
CONFIG_SND_ALI5451=m
CONFIG_SND_ATIIXP=m
CONFIG_SND_ATIIXP_MODEM=m
CONFIG_SND_AU8810=m
CONFIG_SND_AU8820=m
CONFIG_SND_AU8830=m
CONFIG_SND_AZT3328=m
CONFIG_SND_BT87X=m
# CONFIG_SND_BT87X_OVERCLOCK is not set
CONFIG_SND_CA0106=m
CONFIG_SND_CMIPCI=m
CONFIG_SND_CS4281=m
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_CS5535AUDIO=m
CONFIG_SND_DARLA20=m
CONFIG_SND_GINA20=m
CONFIG_SND_LAYLA20=m
CONFIG_SND_DARLA24=m
CONFIG_SND_GINA24=m
CONFIG_SND_LAYLA24=m
CONFIG_SND_MONA=m
CONFIG_SND_MIA=m
CONFIG_SND_ECHO3G=m
CONFIG_SND_INDIGO=m
CONFIG_SND_INDIGOIO=m
CONFIG_SND_INDIGODJ=m
CONFIG_SND_EMU10K1=m
CONFIG_SND_EMU10K1X=m
CONFIG_SND_ENS1370=m
CONFIG_SND_ENS1371=m
CONFIG_SND_ES1938=m
CONFIG_SND_ES1968=m
CONFIG_SND_FM801=m
CONFIG_SND_FM801_TEA575X_BOOL=y
CONFIG_SND_FM801_TEA575X=m
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDSP=m
CONFIG_SND_HDSPM=m
CONFIG_SND_ICE1712=m
CONFIG_SND_ICE1724=m
CONFIG_SND_INTEL8X0=m
CONFIG_SND_INTEL8X0M=m
CONFIG_SND_KORG1212=m
CONFIG_SND_MAESTRO3=m
CONFIG_SND_MIXART=m
CONFIG_SND_NM256=m
CONFIG_SND_PCXHR=m
CONFIG_SND_RIPTIDE=m
CONFIG_SND_RME32=m
CONFIG_SND_RME96=m
CONFIG_SND_RME9652=m
CONFIG_SND_SONICVIBES=m
CONFIG_SND_TRIDENT=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VX222=m
CONFIG_SND_YMFPCI=m
CONFIG_SND_AC97_POWER_SAVE=y

#
# USB devices
#
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_USX2Y=m

#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_PDAUDIOCF is not set

#
# SoC audio support
#
# CONFIG_SND_SOC is not set

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=m

#
# HID Devices
#
CONFIG_HID=m
# CONFIG_HID_DEBUG is not set

#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_EHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_ISP116X_HCD=m
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_U132_HCD=m
CONFIG_USB_SL811_HCD=m
CONFIG_USB_SL811_CS=m

#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=y
CONFIG_USB_STORAGE_FREECOM=y
CONFIG_USB_STORAGE_ISD200=y
CONFIG_USB_STORAGE_DPCM=y
CONFIG_USB_STORAGE_USBAT=y
CONFIG_USB_STORAGE_SDDR09=y
CONFIG_USB_STORAGE_SDDR55=y
CONFIG_USB_STORAGE_JUMPSHOT=y
CONFIG_USB_STORAGE_ALAUDA=y
CONFIG_USB_STORAGE_KARMA=y
CONFIG_USB_LIBUSUAL=y

#
# USB Input Devices
#
CONFIG_USB_HID=m
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
CONFIG_HID_FF=y
CONFIG_HID_PID=y
CONFIG_LOGITECH_FF=y
# CONFIG_PANTHERLORD_FF is not set
CONFIG_THRUSTMASTER_FF=y
CONFIG_ZEROPLUS_FF=y
CONFIG_USB_HIDDEV=y

#
# USB HID Boot Protocol drivers
#
CONFIG_USB_KBD=m
CONFIG_USB_MOUSE=m
CONFIG_USB_AIPTEK=m
CONFIG_USB_WACOM=m
CONFIG_USB_ACECAD=m
CONFIG_USB_KBTAB=m
CONFIG_USB_POWERMATE=m
CONFIG_USB_TOUCHSCREEN=m
CONFIG_USB_TOUCHSCREEN_EGALAX=y
CONFIG_USB_TOUCHSCREEN_PANJIT=y
CONFIG_USB_TOUCHSCREEN_3M=y
CONFIG_USB_TOUCHSCREEN_ITM=y
CONFIG_USB_TOUCHSCREEN_ETURBO=y
CONFIG_USB_TOUCHSCREEN_GUNZE=y
CONFIG_USB_TOUCHSCREEN_DMC_TSC10=y
# CONFIG_USB_YEALINK is not set
CONFIG_USB_XPAD=m
CONFIG_USB_ATI_REMOTE=m
CONFIG_USB_ATI_REMOTE2=m
CONFIG_USB_KEYSPAN_REMOTE=m
CONFIG_USB_APPLETOUCH=m
# CONFIG_USB_GTCO is not set

#
# USB Imaging devices
#
CONFIG_USB_MDC800=m
CONFIG_USB_MICROTEK=m

#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET_MII=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_CDCETHER=m
# CONFIG_USB_NET_DM9601 is not set
CONFIG_USB_NET_GL620A=m
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_PLUSB=m
CONFIG_USB_NET_MCS7830=m
CONFIG_USB_NET_RNDIS_HOST=m
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
# CONFIG_USB_KC2190 is not set
CONFIG_USB_NET_ZAURUS=m
CONFIG_USB_MON=y

#
# USB port drivers
#
CONFIG_USB_USS720=m

#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_AIRCABLE=m
CONFIG_USB_SERIAL_AIRPRIME=m
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CP2101=m
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_FUNSOFT=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_GARMIN=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KEYSPAN_MPR=y
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_MOS7720=m
CONFIG_USB_SERIAL_MOS7840=m
CONFIG_USB_SERIAL_NAVMAN=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_HP4X=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
CONFIG_USB_SERIAL_TI=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_SERIAL_OMNINET=m
CONFIG_USB_SERIAL_DEBUG=m
CONFIG_USB_EZUSB=y

#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_ADUTUX=m
CONFIG_USB_AUERSWALD=m
CONFIG_USB_RIO500=m
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
# CONFIG_USB_BERRY_CHARGE is not set
CONFIG_USB_LED=m
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
CONFIG_USB_PHIDGET=m
CONFIG_USB_PHIDGETKIT=m
CONFIG_USB_PHIDGETMOTORCONTROL=m
CONFIG_USB_PHIDGETSERVO=m
CONFIG_USB_IDMOUSE=m
CONFIG_USB_FTDI_ELAN=m
CONFIG_USB_APPLEDISPLAY=m
CONFIG_USB_SISUSBVGA=m
CONFIG_USB_SISUSBVGA_CON=y
CONFIG_USB_LD=m
CONFIG_USB_TRANCEVIBRATOR=m
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=m

#
# USB DSL modem support
#
CONFIG_USB_ATM=m
CONFIG_USB_SPEEDTOUCH=m
CONFIG_USB_CXACRU=m
CONFIG_USB_UEAGLEATM=m
CONFIG_USB_XUSBATM=m

#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set

#
# MMC/SD Card support
#
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
CONFIG_MMC_BLOCK=m
CONFIG_MMC_SDHCI=m
CONFIG_MMC_WBSD=m
CONFIG_MMC_TIFM_SD=m

#
# LED devices
#
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_IDE_DISK=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=m

#
# InfiniBand support
#
CONFIG_INFINIBAND=m
CONFIG_INFINIBAND_USER_MAD=m
CONFIG_INFINIBAND_USER_ACCESS=m
CONFIG_INFINIBAND_ADDR_TRANS=y
CONFIG_INFINIBAND_MTHCA=m
CONFIG_INFINIBAND_MTHCA_DEBUG=y
# CONFIG_INFINIBAND_AMSO1100 is not set
CONFIG_INFINIBAND_IPOIB=m
# CONFIG_INFINIBAND_IPOIB_CM is not set
CONFIG_INFINIBAND_IPOIB_DEBUG=y
CONFIG_INFINIBAND_IPOIB_DEBUG_DATA=y
CONFIG_INFINIBAND_SRP=m
CONFIG_INFINIBAND_ISER=m

#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=m
CONFIG_EDAC_AMD76X=m
CONFIG_EDAC_E7XXX=m
CONFIG_EDAC_E752X=m
CONFIG_EDAC_I82875P=m
CONFIG_EDAC_I82860=m
CONFIG_EDAC_R82600=m
CONFIG_EDAC_POLL=y

#
# Real Time Clock
#
CONFIG_RTC_LIB=m
CONFIG_RTC_CLASS=m

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=m
CONFIG_RTC_INTF_PROC=m
CONFIG_RTC_INTF_DEV=m
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set

#
# RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1553=m
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_DS1672=m
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_RS5C372=m
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_TEST is not set
CONFIG_RTC_DRV_V3020=m

#
# DMA Engine support
#
CONFIG_DMA_ENGINE=y

#
# DMA Clients
#
CONFIG_NET_DMA=y

#
# DMA Devices
#
CONFIG_INTEL_IOATDMA=m

#
# Auxiliary Display support
#
# CONFIG_KS0108 is not set

#
# Virtualization
#
CONFIG_KVM=y
CONFIG_KVM_INTEL=y
CONFIG_KVM_AMD=y

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT2_FS_XIP=y
CONFIG_FS_XIP=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
CONFIG_REISERFS_PROC_INFO=y
CONFIG_REISERFS_FS_XATTR=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_SECURITY=y
CONFIG_JFS_FS=m
CONFIG_JFS_POSIX_ACL=y
CONFIG_JFS_SECURITY=y
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
CONFIG_XFS_SECURITY=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
CONFIG_GFS2_FS=m
CONFIG_GFS2_FS_LOCKING_NOLOCK=m
CONFIG_GFS2_FS_LOCKING_DLM=m
CONFIG_OCFS2_FS=m
# CONFIG_OCFS2_DEBUG_MASKLOG is not set
CONFIG_MINIX_FS=m
CONFIG_ROMFS_FS=m
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_DNOTIFY=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_GENERIC_ACL=y

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="ascii"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=m

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
CONFIG_AFFS_FS=m
CONFIG_ECRYPT_FS=m
CONFIG_HFS_FS=m
CONFIG_HFSPLUS_FS=m
CONFIG_BEFS_FS=m
# CONFIG_BEFS_DEBUG is not set
CONFIG_BFS_FS=m
CONFIG_EFS_FS=m
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
CONFIG_JFFS2_SUMMARY=y
# CONFIG_JFFS2_FS_XATTR is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
CONFIG_CRAMFS=m
CONFIG_VXFS_FS=m
# CONFIG_HPFS_FS is not set
CONFIG_QNX4FS_FS=m
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_UFS_DEBUG is not set

#
# Network File Systems
#
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_RPCSEC_GSS_SPKM3=m
# CONFIG_SMB_FS is not set
CONFIG_CIFS=m
# CONFIG_CIFS_STATS is not set
CONFIG_CIFS_WEAK_PW_HASH=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_CODA_FS=m
# CONFIG_CODA_FS_OLD_API is not set
# CONFIG_AFS_FS is not set
CONFIG_9P_FS=m

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y

#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m

#
# Distributed Lock Manager
#
CONFIG_DLM=m
CONFIG_DLM_TCP=y
# CONFIG_DLM_SCTP is not set
CONFIG_DLM_DEBUG=y

#
# Instrumentation Support
#
CONFIG_PROFILING=y
CONFIG_OPROFILE=m
CONFIG_KPROBES=y

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOG_BUF_SHIFT=20
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
CONFIG_DEBUG_SLAB=y
CONFIG_DEBUG_SLAB_LEAK=y
CONFIG_DEBUG_PREEMPT=y
# CONFIG_DEBUG_RT_MUTEXES is not set
CONFIG_RT_MUTEX_TESTER=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_TRACE_IRQFLAGS=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_LIST=y
CONFIG_FRAME_POINTER=y
# CONFIG_FORCED_INLINING is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_LKDTM is not set
CONFIG_FAULT_INJECTION=y
CONFIG_FAILSLAB=y
CONFIG_FAIL_PAGE_ALLOC=y
CONFIG_FAIL_MAKE_REQUEST=y
CONFIG_FAULT_INJECTION_DEBUG_FS=y
# CONFIG_FAULT_INJECTION_STACKTRACE_FILTER is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set

#
# Page alloc debug is incompatible with Software Suspend on i386
#
CONFIG_DEBUG_RODATA=y
CONFIG_4KSTACKS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y
# CONFIG_DEBUG_PARAVIRT is not set

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
CONFIG_SECURITY_CAPABILITIES=m
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT is not set
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set

#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=y
CONFIG_CRYPTO_WP512=y
CONFIG_CRYPTO_TGR192=y
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_LRW=y
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
CONFIG_CRYPTO_BLOWFISH=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_TWOFISH_COMMON=y
# CONFIG_CRYPTO_TWOFISH_586 is not set
CONFIG_CRYPTO_SERPENT=y
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_586 is not set
CONFIG_CRYPTO_CAST5=y
CONFIG_CRYPTO_CAST6=y
CONFIG_CRYPTO_TEA=y
CONFIG_CRYPTO_ARC4=y
CONFIG_CRYPTO_KHAZAD=y
CONFIG_CRYPTO_ANUBIS=y
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_MICHAEL_MIC=y
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set

#
# Hardware crypto devices
#
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_CRYPTO_DEV_GEODE=m

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC32=y
CONFIG_LIBCRC32C=y
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_REED_SOLOMON=m
CONFIG_REED_SOLOMON_DEC16=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y
CONFIG_NO_IDLE_HZ=y

Re: 2.6.21-rc1: known regressions (part 2)

[Linus Torvalds]

(Ok, removed the kernel people, since this is just about the git part...)

On Fri, 2 Mar 2007, Ingo Molnar wrote:
> 
> but the conclusion is clear: if multiple bugs are present in the search 
> area then it gets quite difficult to sort it out via git-bisect - but 
> it's not impossible either. The following git-bisect enhancement could 
> have made things easier for me:
> 
>    git-bisect mark-must-have <tree>

It's not quite that easy.

In _your_ case, you always just wanted to try to apply a particular patch 
if it applied cleanly.

But in other cases, what you really want is:

 - *if* commit X is included, apply patch Y

because quite often you might have a "fix" that applies quite cleanly, but 
is totally the wrong thing to do unless the code that actually _needs_ the 
fix is already merged.

It's just that in this case, if the bug didn't exist, the fix wouldn't 
apply either, so it just didn't matter..

Also, even if we had something that git did automatically after it 
selected a commit to bisect on, it still wouldn't really be enough: we'd 
need to 

 (a) handle the failure case cleanly (again, in your case it didn't 
     matter, because it either applied cleanly or wasn't needed at all)

 (b) also handle the case where the user chooses a different point to try 
     because the automatic bisection picked a commit that was untestable. 
     Right now people do that by using "git reset --hard XYZ"

 (c) It's quite possible that the fix to be applied isn't a git commit at 
     all. Again, in your case there happened to be one well-defined commit 
     that did nothing but fix the known bug, but you could easily have had 
     a situation where - if the bug wasn't as obvious, for example - you 
     had a fix being done over _multiple_ commits, or the other way, the 
     fix you actually want to merge is just a part of a commit that does a 
     lot of other things too (that may not be appropriate at other places, 
     and you know will just cause merge errors)

The (b) case could be supplied by having a "git bisect try <XYZ>" 
subcommand instead of having people use "git reset --hard". That might be 
a good thing to do anyway, since it can also do added sanity testing (ie 
testing that the commit to try actually is *inside* the current bisection 
set, because otherwise the bisection simply won't work).

			Linus

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, 2 Mar 2007, Ingo Molnar wrote:
> > 
> > but the conclusion is clear: if multiple bugs are present in the 
> > search area then it gets quite difficult to sort it out via 
> > git-bisect - but it's not impossible either. The following 
> > git-bisect enhancement could have made things easier for me:
> > 
> >    git-bisect mark-must-have <tree>
> 
> It's not quite that easy.
> 
> In _your_ case, you always just wanted to try to apply a particular 
> patch if it applied cleanly.

ok, agreed.

Suspend/resume bugs are a bit special anyway because so much stuff 
happens in an 'invisible' way during suspend/resume that any 
problem/hang during that 'looks like' the same bug symtpom: a hung 
resume.

so i'll put more effort into providing more suspend/resume debugging 
facilities - we have way too few tools of directly debugging them.

	Ingo

Re: 2.6.21-rc1: known regressions (part 2)

[Michael S. Tsirkin]

> Quoting Ingo Molnar <mingo@elte.hu>:
> Subject: Re: 2.6.21-rc1: known regressions (part 2)
> 
> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > I'll try what i've described in the previous mail: mark all bisection 
> > points that do not include f3ccb06f as 'good' - thus 'merging' the 
> > known-bad area with the first known-good commit, and thus eliminating 
> > it from the bisection space.
> 
> this got me quite a bit further:
> 
>  git-bisect start
>  git-bisect bad       01363220f5d23ef68276db8974e46a502e43d01d
>  git-bisect good      f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 
>  git-bisect fake-good ee404566f97f9254433399fbbcfa05390c7c55f7
>  git-bisect bad       d43a338e395371733a80ec473b40baac5f74d768
>  git-bisect bad       255f0385c8e0d6b9005c0e09fffb5bd852f3b506
>  git-bisect fake-good f99c6bb6e2e9c35bd3dc0b1d0faa28bd6970930d
>  git-bisect fake-good 0187f221e96e3436d552c0c7143f183eb82fb658
>  git-bisect bad       81450b73dde07f473a4a7208b209b4c8b7251d90
>  git-bisect fake-good ef29498655b18d2bfd69048e20835d19333981ab
>  git-bisect fake-good 8a03d9a498eaf02c8a118752050a5154852c13bf
>  git-bisect good      5c95d3f5783ab184f64b7848f0a871352c35c3cf
>  git-bisect good      ecb5f7521a309cb9c5fc0832b9705cd2a03d7d45
>  git-bisect good      0539771d7236b425f285652f6f297cc7939c8f9a

I just confirmed that 0539771d7236b425f285652f6f297cc7939c8f9a
is good for me, too.

>  81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit

Going to test that now.

-- 
MST

Re: 2.6.21-rc1: known regressions (part 2)

[Michael S. Tsirkin]

> Quoting Ingo Molnar <mingo@elte.hu>:
> Subject: Re: 2.6.21-rc1: known regressions (part 2)
> 
> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > I'll try what i've described in the previous mail: mark all bisection 
> > points that do not include f3ccb06f as 'good' - thus 'merging' the 
> > known-bad area with the first known-good commit, and thus eliminating 
> > it from the bisection space.
> 
> this got me quite a bit further:
> 
>  git-bisect start
>  git-bisect bad       01363220f5d23ef68276db8974e46a502e43d01d
>  git-bisect good      f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 
>  git-bisect fake-good ee404566f97f9254433399fbbcfa05390c7c55f7
>  git-bisect bad       d43a338e395371733a80ec473b40baac5f74d768
>  git-bisect bad       255f0385c8e0d6b9005c0e09fffb5bd852f3b506
>  git-bisect fake-good f99c6bb6e2e9c35bd3dc0b1d0faa28bd6970930d
>  git-bisect fake-good 0187f221e96e3436d552c0c7143f183eb82fb658
>  git-bisect bad       81450b73dde07f473a4a7208b209b4c8b7251d90
>  git-bisect fake-good ef29498655b18d2bfd69048e20835d19333981ab
>  git-bisect fake-good 8a03d9a498eaf02c8a118752050a5154852c13bf
>  git-bisect good      5c95d3f5783ab184f64b7848f0a871352c35c3cf
>  git-bisect good      ecb5f7521a309cb9c5fc0832b9705cd2a03d7d45
>  git-bisect good      0539771d7236b425f285652f6f297cc7939c8f9a

I just confirmed that 0539771d7236b425f285652f6f297cc7939c8f9a
is good for me, too.

>  81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit

Going to test that now.

-- 
MST

Re: 2.6.21-rc1: known regressions (part 2)

[Michael S. Tsirkin]

> Quoting Ingo Molnar <mingo@elte.hu>:
>  git-bisect good      0539771d7236b425f285652f6f297cc7939c8f9a
> 
>  81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit

I have confirmed these two on my system.

-- 
MST

Re: 2.6.21-rc1: known regressions (part 2)

[Michael S. Tsirkin]

> Quoting Ingo Molnar <mingo@elte.hu>:
>  git-bisect good      0539771d7236b425f285652f6f297cc7939c8f9a
> 
>  81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit

I have confirmed these two on my system.

-- 
MST

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> > Quoting Ingo Molnar <mingo@elte.hu>:
> >  git-bisect good      0539771d7236b425f285652f6f297cc7939c8f9a
> > 
> >  81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit
> 
> I have confirmed these two on my system.

you could probably get quite a bit further in bisecting the other 
breakage, by using the following method:

manully apply the patch below to 81450b73dde and retest. It will most 
likely work. Then FIRST unapply the patch and mark the tree via 
'git-bisect good' and continue the bisection. Then try to apply the 
patch again. If it's already included - ignore the rejected patch. 
Whenever git-bisect offers you a new commit, just try to apply the 
patch. Ok? This way you'll be able to avoid the known ACPI breakage, and 
zoom in on the unknown breakage.

	Ingo

---------------->
commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38
Author: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Date:   Tue Feb 13 02:35:50 2007 -0500

    ACPI: Disable wake GPEs only once.
    
    fixes Suspend/Resume regressions due to recent ACPICA update.
    
    Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

diff --git a/drivers/acpi/events/evgpe.c b/drivers/acpi/events/evgpe.c
index dfac3ec..635ba44 100644
--- a/drivers/acpi/events/evgpe.c
+++ b/drivers/acpi/events/evgpe.c
@@ -636,17 +636,6 @@ acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number)
 		}
 	}
 
-	if (!acpi_gbl_system_awake_and_running) {
-		/*
-		 * We just woke up because of a wake GPE. Disable any further GPEs
-		 * until we are fully up and running (Only wake GPEs should be enabled
-		 * at this time, but we just brute-force disable them all.)
-		 * 1) We must disable this particular wake GPE so it won't fire again
-		 * 2) We want to disable all wake GPEs, since we are now awake
-		 */
-		(void)acpi_hw_disable_all_gpes();
-	}
-
 	/*
 	 * Dispatch the GPE to either an installed handler, or the control method
 	 * associated with this GPE (_Lxx or _Exx). If a handler exists, we invoke

Re: 2.6.21-rc1: known regressions (part 2)

[Ingo Molnar]

* Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> > Quoting Ingo Molnar <mingo@elte.hu>:
> >  git-bisect good      0539771d7236b425f285652f6f297cc7939c8f9a
> > 
> >  81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit
> 
> I have confirmed these two on my system.

you could probably get quite a bit further in bisecting the other 
breakage, by using the following method:

manully apply the patch below to 81450b73dde and retest. It will most 
likely work. Then FIRST unapply the patch and mark the tree via 
'git-bisect good' and continue the bisection. Then try to apply the 
patch again. If it's already included - ignore the rejected patch. 
Whenever git-bisect offers you a new commit, just try to apply the 
patch. Ok? This way you'll be able to avoid the known ACPI breakage, and 
zoom in on the unknown breakage.

	Ingo

---------------->
commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38
Author: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Date:   Tue Feb 13 02:35:50 2007 -0500

    ACPI: Disable wake GPEs only once.
    
    fixes Suspend/Resume regressions due to recent ACPICA update.
    
    Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

diff --git a/drivers/acpi/events/evgpe.c b/drivers/acpi/events/evgpe.c
index dfac3ec..635ba44 100644
--- a/drivers/acpi/events/evgpe.c
+++ b/drivers/acpi/events/evgpe.c
@@ -636,17 +636,6 @@ acpi_ev_gpe_dispatch(struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number)
 		}
 	}
 
-	if (!acpi_gbl_system_awake_and_running) {
-		/*
-		 * We just woke up because of a wake GPE. Disable any further GPEs
-		 * until we are fully up and running (Only wake GPEs should be enabled
-		 * at this time, but we just brute-force disable them all.)
-		 * 1) We must disable this particular wake GPE so it won't fire again
-		 * 2) We want to disable all wake GPEs, since we are now awake
-		 */
-		(void)acpi_hw_disable_all_gpes();
-	}
-
 	/*
 	 * Dispatch the GPE to either an installed handler, or the control method
 	 * associated with this GPE (_Lxx or _Exx). If a handler exists, we invoke

Re: 2.6.21-rc1: known regressions (part 2)

[Jens Axboe]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

On Mon, Mar 05 2007, Michael S. Tsirkin wrote:
> > Quoting Ingo Molnar <mingo@elte.hu>:
> >  git-bisect good      0539771d7236b425f285652f6f297cc7939c8f9a
> > 
> >  81450b73dde07f473a4a7208b209b4c8b7251d90 is first bad commit
> 
> I have confirmed these two on my system.

BTW, the key here seems to be CONFIG_CC_OPTIMIZE_FOR_SIZE, at least that
is my current guess looking at the config options I still need to test
whether they make a difference. Either that, or the vmsplit option got
broken again. I'm attaching my x60 config that works for me.

-- 
Jens Axboe


[-- Attachment #2: .config --]
[-- Type: application/x-config, Size: 37392 bytes --]

Re: 2.6.21-rc1: known regressions (part 2)

[Linus Torvalds]

On Thu, 1 Mar 2007, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and 
> > 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt 
> > to bisect this.
> 
> hm. There's some weird bisection artifact here. Here are the commits i 
> tested, in git-log order:
> 
> #1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
> #2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad
> #3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good
> #4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad

Use "git bisect visualize" to see what bisect ends up doing.

> if i tell git-bisect that #1 is bad and #3 is good, then it offers me #2 
> - that's OK. But when i tell it that #2 is bad, it offers #4 - which is 
> out of order!

No it's not. "git bisect" does exactly the right thing. There is no simple 
ordering in a complex branch-merge schenario, you can't just put the 
commits in some "ordering" and test things in time order. That would be 
totally broken, and idiotic. It doesn't give the right results.

What git bisect does is to find the commit that most closely *bisects* the 
history of commits, so that if it is marked good/bad, it will leave you 
with about 50% of the commits left. But if you are looking at date order, 
you're entirely confused.

For example, let's take a really simple case

	    a <- bad
	   / \
          b   c
	  |   |
	  d   e
	  |   |
	  f   g
	   \ /
	    h
            |
	    * <-good

and if you are looking to find something "in the middle", you might thing 
that "d" or "e" are the best choices, since time-wise, they are in the 
middle.

But that's not true AT ALL.

If you actually want to bisect that kind of history, you need to choose 
"b" or "c", even though they may both be *much* more "recent" than the 
others. Why? Because if you pick "d", you're really only testing three 
commits ('d' 'f' and 'h') out of the 8 commits you have to test.

In contrast, if you pick 'b', you are testing the effects of *four* 
commits ('b', 'd', 'f' and 'h') and you have thus neatly bisected the 
commits into two equal groups for testing (one group _with_ those four 
commits, and one group _without_) instead of having partitioned them as 3 
commits vs 5 commits.

So please realize that non-linear history very much means that you MUST 
NOT think that you just pick a commit "in the middle". No, git bisect is a 
LOT smarter than that - it picks a commit that *reaches* about half the 
commits you have left to test.

> The bisection goes off into la-la land after that and 
> never gets back to a commit that is /after/ the good commit. How is this 
> possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure this isnt 
> some git bug that's already fixed.)

It's possible because git knows what it is doing, and you didn't think 
things through.

The commits that "git bisect" picked out are the right ones. Quite often, 
there may be two or more "equally good" commits (in my example above, you 
can choose either "b" or "c", and it will bisect the set of untested 
commits equally well - in two groups of four, but two *different* groups 
of four commits), and yes, it's possible that git has a bug that makes it 
pick the wrong ones, but quite frankly, I seriously doubt it. "git bisect" 
has been very successful indeed, and is generally a *lot* better at 
picking a commit "in the middle" than people are, exactly because it's 
quite hard to see which commit "reaches" half the commits if you have lots 
of merges and branches.

Try out

	git bisect visualize

and it will literally show you what it is doing.

What can be confusing is that if the "good" and "bad" markers are ON 
DIFFERENT BRANCHES OF DEVELOPMENT, you may not even *see* the "good" 
marker, because you may well have something like this:


	a <- bad
	|
	b   * <- good
	|   |
	c   d
	 \ /
	  e
	  |
	  f
	  |
	 ...

and what do you think "git bisect visualize" will actually show you?

Since 'd', 'e' and 'f' are all in the "good" set (they both exist as 
commits in something leading up to a commit that has already been deemed 
fine), they aren't *interesting* - they can't be introducing the bug, 
since if that was the case, the good commit wouldn't have been good. So as 
far as bisection is concerned, the tree actually looks like

	 a <- bad
	 |
	 b
	 |
	 c
	 |
	...

and you have just three commits that are potentially interesting: 'a', 'b' 
and 'c'.

Now, with three commits, you cannot test them half-and-half, so you have 
to test it in groups of 1 vs 2 commits, so it's arbitrary whether you 
choose 'b' or 'c' to test, but you'd test one of them. Say that you choose 
'b', and it turns out to be good. If so, you're done: 'a' is bad and 'b' 
is good, so the bug was introduced in 'a'. But if it turns out to be bad, 
you'll still have to test 'c' too, since you don't know if the bug was 
*introduced* in 'b' or not.

See? 

> i'll try to straighten this out manually

Don't. You're just going to make your bisection much less effective. The 
whole point of bisection is that you can usually cut the number of commits 
to test pretty exactly in half.  If you start mucking with the commits to 
test, and you don't understand about the reachability graph, you'll just 
choose a much worse set of commits to test than "git bisect" will do.

So learn to trust "git bisect". It really does know what it is doing.

		Linus

Re: 2.6.21-rc1: known regressions (part 2)

[Linus Torvalds]

On Thu, 1 Mar 2007, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and 
> > 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt 
> > to bisect this.
> 
> hm. There's some weird bisection artifact here. Here are the commits i 
> tested, in git-log order:
> 
> #1 commit 01363220f5d23ef68276db8974e46a502e43d01d bad
> #2 commit ee404566f97f9254433399fbbcfa05390c7c55f7 bad
> #3 commit f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 good
> #4 commit c827ba4cb49a30ce581201fd0ba2be77cde412c7 bad

Use "git bisect visualize" to see what bisect ends up doing.

> if i tell git-bisect that #1 is bad and #3 is good, then it offers me #2 
> - that's OK. But when i tell it that #2 is bad, it offers #4 - which is 
> out of order!

No it's not. "git bisect" does exactly the right thing. There is no simple 
ordering in a complex branch-merge schenario, you can't just put the 
commits in some "ordering" and test things in time order. That would be 
totally broken, and idiotic. It doesn't give the right results.

What git bisect does is to find the commit that most closely *bisects* the 
history of commits, so that if it is marked good/bad, it will leave you 
with about 50% of the commits left. But if you are looking at date order, 
you're entirely confused.

For example, let's take a really simple case

	    a <- bad
	   / \
          b   c
	  |   |
	  d   e
	  |   |
	  f   g
	   \ /
	    h
            |
	    * <-good

and if you are looking to find something "in the middle", you might thing 
that "d" or "e" are the best choices, since time-wise, they are in the 
middle.

But that's not true AT ALL.

If you actually want to bisect that kind of history, you need to choose 
"b" or "c", even though they may both be *much* more "recent" than the 
others. Why? Because if you pick "d", you're really only testing three 
commits ('d' 'f' and 'h') out of the 8 commits you have to test.

In contrast, if you pick 'b', you are testing the effects of *four* 
commits ('b', 'd', 'f' and 'h') and you have thus neatly bisected the 
commits into two equal groups for testing (one group _with_ those four 
commits, and one group _without_) instead of having partitioned them as 3 
commits vs 5 commits.

So please realize that non-linear history very much means that you MUST 
NOT think that you just pick a commit "in the middle". No, git bisect is a 
LOT smarter than that - it picks a commit that *reaches* about half the 
commits you have left to test.

> The bisection goes off into la-la land after that and 
> never gets back to a commit that is /after/ the good commit. How is this 
> possible? (I upgraded from git-1.4.4 to 1.5.0 to make sure this isnt 
> some git bug that's already fixed.)

It's possible because git knows what it is doing, and you didn't think 
things through.

The commits that "git bisect" picked out are the right ones. Quite often, 
there may be two or more "equally good" commits (in my example above, you 
can choose either "b" or "c", and it will bisect the set of untested 
commits equally well - in two groups of four, but two *different* groups 
of four commits), and yes, it's possible that git has a bug that makes it 
pick the wrong ones, but quite frankly, I seriously doubt it. "git bisect" 
has been very successful indeed, and is generally a *lot* better at 
picking a commit "in the middle" than people are, exactly because it's 
quite hard to see which commit "reaches" half the commits if you have lots 
of merges and branches.

Try out

	git bisect visualize

and it will literally show you what it is doing.

What can be confusing is that if the "good" and "bad" markers are ON 
DIFFERENT BRANCHES OF DEVELOPMENT, you may not even *see* the "good" 
marker, because you may well have something like this:


	a <- bad
	|
	b   * <- good
	|   |
	c   d
	 \ /
	  e
	  |
	  f
	  |
	 ...

and what do you think "git bisect visualize" will actually show you?

Since 'd', 'e' and 'f' are all in the "good" set (they both exist as 
commits in something leading up to a commit that has already been deemed 
fine), they aren't *interesting* - they can't be introducing the bug, 
since if that was the case, the good commit wouldn't have been good. So as 
far as bisection is concerned, the tree actually looks like

	 a <- bad
	 |
	 b
	 |
	 c
	 |
	...

and you have just three commits that are potentially interesting: 'a', 'b' 
and 'c'.

Now, with three commits, you cannot test them half-and-half, so you have 
to test it in groups of 1 vs 2 commits, so it's arbitrary whether you 
choose 'b' or 'c' to test, but you'd test one of them. Say that you choose 
'b', and it turns out to be good. If so, you're done: 'a' is bad and 'b' 
is good, so the bug was introduced in 'a'. But if it turns out to be bad, 
you'll still have to test 'c' too, since you don't know if the bug was 
*introduced* in 'b' or not.

See? 

> i'll try to straighten this out manually

Don't. You're just going to make your bisection much less effective. The 
whole point of bisection is that you can usually cut the number of commits 
to test pretty exactly in half.  If you start mucking with the commits to 
test, and you don't understand about the reachability graph, you'll just 
choose a much worse set of commits to test than "git bisect" will do.

So learn to trust "git bisect". It really does know what it is doing.

		Linus

Re: 2.6.21-rc1: known regressions (part 2)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

Hi!

> * Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
> 
> update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and 
> 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt 
> to bisect this.

Strange; on my x60, suspend to ram works okay.

(Resume is very slow, because disks are not spinned up properly; and
there's something wrong with timers; console beeps take way too long).

dmesg attached.

That's with

commit 7b965e0884cee430ffe5dc81cdb117b9316b0549
tree 754dce6432258e0a8c3a758e13a34eb3a1d22ee1
parent 5a39e8c6d655b4fe8305ef8cc2d9bbe782bfee5f
author Trond Myklebust <Trond.Myklebust@netapp.com> Wed, 28 Feb 2007
20:13:55 -0800
committer Linus Torvalds <torvalds@woody.linux-foundation.org> Thu, 01
Mar 2007 14:53:39 -0800

    [PATCH] VM: invalidate_inode_pages2_range() should not exit early

    Fix invalidate_inode_pages2_range() so that it does not
immediately exit
    just because a single page in the specified range could not be
removed.

    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: delme.gz --]
[-- Type: application/octet-stream, Size: 10027 bytes --]

[-- Attachment #3: delme_config.gz --]
[-- Type: application/octet-stream, Size: 14804 bytes --]

Re: 2.6.21-rc1: known regressions (part 2)

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

Hi!

> * Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
> 
> update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and 
> 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt 
> to bisect this.

Strange; on my x60, suspend to ram works okay.

(Resume is very slow, because disks are not spinned up properly; and
there's something wrong with timers; console beeps take way too long).

dmesg attached.

That's with

commit 7b965e0884cee430ffe5dc81cdb117b9316b0549
tree 754dce6432258e0a8c3a758e13a34eb3a1d22ee1
parent 5a39e8c6d655b4fe8305ef8cc2d9bbe782bfee5f
author Trond Myklebust <Trond.Myklebust@netapp.com> Wed, 28 Feb 2007
20:13:55 -0800
committer Linus Torvalds <torvalds@woody.linux-foundation.org> Thu, 01
Mar 2007 14:53:39 -0800

    [PATCH] VM: invalidate_inode_pages2_range() should not exit early

    Fix invalidate_inode_pages2_range() so that it does not
immediately exit
    just because a single page in the specified range could not be
removed.

    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: delme.gz --]
[-- Type: application/octet-stream, Size: 10027 bytes --]

[-- Attachment #3: delme_config.gz --]
[-- Type: application/octet-stream, Size: 14804 bytes --]

[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

Re: 2.6.21-rc1: known regressions (part 2)

[Michael S. Tsirkin]

> Quoting Pavel Machek <pavel@ucw.cz>:
> Subject: Re: 2.6.21-rc1: known regressions (part 2)
> 
> Hi!
> 
> > * Jens Axboe <jens.axboe@oracle.com> wrote:
> > 
> > > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
> > 
> > update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and 
> > 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt 
> > to bisect this.
> 
> Strange; on my x60, suspend to ram works okay.
> 
> (Resume is very slow, because disks are not spinned up properly; and
> there's something wrong with timers; console beeps take way too long).
> 
> dmesg attached.
> 
> That's with
> 
> commit 7b965e0884cee430ffe5dc81cdb117b9316b0549
> tree 754dce6432258e0a8c3a758e13a34eb3a1d22ee1
> parent 5a39e8c6d655b4fe8305ef8cc2d9bbe782bfee5f
> author Trond Myklebust <Trond.Myklebust@netapp.com> Wed, 28 Feb 2007
> 20:13:55 -0800
> committer Linus Torvalds <torvalds@woody.linux-foundation.org> Thu, 01
> Mar 2007 14:53:39 -0800
> 
>     [PATCH] VM: invalidate_inode_pages2_range() should not exit early
> 
>     Fix invalidate_inode_pages2_range() so that it does not
> immediately exit
>     just because a single page in the specified range could not be
> removed.
> 
>     Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pavel, I tried with your .config, and indeed the system came back to life after
2-3 minutes after I press Fn/F4, indeed the issue seems to be with the disk.
It could be that the same takes place with my original .config - maybe
I just wasn't patient enough. I'll need to re-test that.

However, I noticed that, after resume, when the system is presumably functional,
if I try to suspend to ram again, this second suspend hangs, displaying
the following on screen:

[   17.170000] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20
[   17.170000] PCI: Setting latency timer of device 0000:02:00.0 to 64
[   17.250000] e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:41:5
4:6c:47
[   17.330000] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection

the crescent LED starts blinking and does not seem to stop for at lest 10 min,
I've run out of patience after that. It could be that it's just very slow again.

Pavel, did you try suspend to RAM after a successfull resume from RAM?

Under 2.6.20, the system suspends/resumes to memory within about 20 sec
any number of times.

-- 
MST

Re: 2.6.21-rc1: known regressions (part 2)

[Michael S. Tsirkin]

> Quoting Pavel Machek <pavel@ucw.cz>:
> Subject: Re: 2.6.21-rc1: known regressions (part 2)
> 
> Hi!
> 
> > * Jens Axboe <jens.axboe@oracle.com> wrote:
> > 
> > > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
> > 
> > update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and 
> > 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt 
> > to bisect this.
> 
> Strange; on my x60, suspend to ram works okay.
> 
> (Resume is very slow, because disks are not spinned up properly; and
> there's something wrong with timers; console beeps take way too long).
> 
> dmesg attached.
> 
> That's with
> 
> commit 7b965e0884cee430ffe5dc81cdb117b9316b0549
> tree 754dce6432258e0a8c3a758e13a34eb3a1d22ee1
> parent 5a39e8c6d655b4fe8305ef8cc2d9bbe782bfee5f
> author Trond Myklebust <Trond.Myklebust@netapp.com> Wed, 28 Feb 2007
> 20:13:55 -0800
> committer Linus Torvalds <torvalds@woody.linux-foundation.org> Thu, 01
> Mar 2007 14:53:39 -0800
> 
>     [PATCH] VM: invalidate_inode_pages2_range() should not exit early
> 
>     Fix invalidate_inode_pages2_range() so that it does not
> immediately exit
>     just because a single page in the specified range could not be
> removed.
> 
>     Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
>     Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pavel, I tried with your .config, and indeed the system came back to life after
2-3 minutes after I press Fn/F4, indeed the issue seems to be with the disk.
It could be that the same takes place with my original .config - maybe
I just wasn't patient enough. I'll need to re-test that.

However, I noticed that, after resume, when the system is presumably functional,
if I try to suspend to ram again, this second suspend hangs, displaying
the following on screen:

[   17.170000] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20
[   17.170000] PCI: Setting latency timer of device 0000:02:00.0 to 64
[   17.250000] e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:41:5
4:6c:47
[   17.330000] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection

the crescent LED starts blinking and does not seem to stop for at lest 10 min,
I've run out of patience after that. It could be that it's just very slow again.

Pavel, did you try suspend to RAM after a successfull resume from RAM?

Under 2.6.20, the system suspends/resumes to memory within about 20 sec
any number of times.

-- 
MST

SATA resume slowness, e1000 MSI warning

[Ingo Molnar]

* Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> > (Resume is very slow, because disks are not spinned up properly; and
> > there's something wrong with timers; console beeps take way too long).

> Pavel, I tried with your .config, and indeed the system came back to 
> life after 2-3 minutes after I press Fn/F4, indeed the issue seems to 
> be with the disk. It could be that the same takes place with my 
> original .config - maybe I just wasn't patient enough. I'll need to 
> re-test that.

the spin-up takes a few seconds here under suspend/resume simulation:

 | ata1: waiting for device to spin up (7 secs)
 | Restarting tasks ... done.

 [5-10 seconds pass]

 | ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
 | ata1.00: configured for UDMA/100
 | SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
 | sda: Write Protect is off
 | sda: Mode Sense: 00 3a 00 00
 | SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA

with real resume it takes even longer time - but i dont see where the 
delays come from in that case - i suspect it's SATA.

i'm also getting this WARN_ON() from e1000:

BUG: at drivers/pci/msi.c:611 pci_enable_msi()
 [<c01061bd>] show_trace_log_lvl+0x19/0x2e
 [<c01062b6>] show_trace+0x12/0x14
 [<c01062cc>] dump_stack+0x14/0x16
 [<c024fcc4>] pci_enable_msi+0x6d/0x203
 [<c02b709e>] e1000_request_irq+0x2e/0xe2
 [<c02bb742>] e1000_resume+0x7f/0xef
 [<c0249a68>] pci_device_resume+0x1a/0x44
 [<c02b39ec>] resume_device+0xf7/0x16f
 [<c02b3adb>] dpm_resume+0x77/0xcb
 [<c02b3b69>] device_resume+0x3a/0x51
 [<c014e669>] enter_state+0x193/0x1bb
 [<c014e712>] state_store+0x81/0x97
 [<c01b68bc>] subsys_attr_store+0x20/0x25
 [<c01b6feb>] sysfs_write_file+0xce/0xf6
 [<c017e16b>] vfs_write+0xb1/0x13a
 [<c017e899>] sys_write+0x3d/0x61
 [<c0105220>] syscall_call+0x7/0xb

seems harmless because it seems to work fine.

	Ingo

SATA resume slowness, e1000 MSI warning

[Ingo Molnar]

* Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> > (Resume is very slow, because disks are not spinned up properly; and
> > there's something wrong with timers; console beeps take way too long).

> Pavel, I tried with your .config, and indeed the system came back to 
> life after 2-3 minutes after I press Fn/F4, indeed the issue seems to 
> be with the disk. It could be that the same takes place with my 
> original .config - maybe I just wasn't patient enough. I'll need to 
> re-test that.

the spin-up takes a few seconds here under suspend/resume simulation:

 | ata1: waiting for device to spin up (7 secs)
 | Restarting tasks ... done.

 [5-10 seconds pass]

 | ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
 | ata1.00: configured for UDMA/100
 | SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
 | sda: Write Protect is off
 | sda: Mode Sense: 00 3a 00 00
 | SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA

with real resume it takes even longer time - but i dont see where the 
delays come from in that case - i suspect it's SATA.

i'm also getting this WARN_ON() from e1000:

BUG: at drivers/pci/msi.c:611 pci_enable_msi()
 [<c01061bd>] show_trace_log_lvl+0x19/0x2e
 [<c01062b6>] show_trace+0x12/0x14
 [<c01062cc>] dump_stack+0x14/0x16
 [<c024fcc4>] pci_enable_msi+0x6d/0x203
 [<c02b709e>] e1000_request_irq+0x2e/0xe2
 [<c02bb742>] e1000_resume+0x7f/0xef
 [<c0249a68>] pci_device_resume+0x1a/0x44
 [<c02b39ec>] resume_device+0xf7/0x16f
 [<c02b3adb>] dpm_resume+0x77/0xcb
 [<c02b3b69>] device_resume+0x3a/0x51
 [<c014e669>] enter_state+0x193/0x1bb
 [<c014e712>] state_store+0x81/0x97
 [<c01b68bc>] subsys_attr_store+0x20/0x25
 [<c01b6feb>] sysfs_write_file+0xce/0xf6
 [<c017e16b>] vfs_write+0xb1/0x13a
 [<c017e899>] sys_write+0x3d/0x61
 [<c0105220>] syscall_call+0x7/0xb

seems harmless because it seems to work fine.

	Ingo

Re: SATA resume slowness, e1000 MSI warning

[Jeff Garzik]

Ingo Molnar wrote:
> i'm also getting this WARN_ON() from e1000:
> 
> BUG: at drivers/pci/msi.c:611 pci_enable_msi()
>  [<c01061bd>] show_trace_log_lvl+0x19/0x2e
>  [<c01062b6>] show_trace+0x12/0x14
>  [<c01062cc>] dump_stack+0x14/0x16
>  [<c024fcc4>] pci_enable_msi+0x6d/0x203
>  [<c02b709e>] e1000_request_irq+0x2e/0xe2
>  [<c02bb742>] e1000_resume+0x7f/0xef
>  [<c0249a68>] pci_device_resume+0x1a/0x44
>  [<c02b39ec>] resume_device+0xf7/0x16f
>  [<c02b3adb>] dpm_resume+0x77/0xcb
>  [<c02b3b69>] device_resume+0x3a/0x51
>  [<c014e669>] enter_state+0x193/0x1bb
>  [<c014e712>] state_store+0x81/0x97
>  [<c01b68bc>] subsys_attr_store+0x20/0x25
>  [<c01b6feb>] sysfs_write_file+0xce/0xf6
>  [<c017e16b>] vfs_write+0xb1/0x13a
>  [<c017e899>] sys_write+0x3d/0x61
>  [<c0105220>] syscall_call+0x7/0xb
> 
> seems harmless because it seems to work fine.


I would poke Eric Biederman(sp?) about this one.  Maybe its even solved 
by the MSI-enable-related patch he posted in the past 24-48 hours.

	Jeff

Re: SATA resume slowness, e1000 MSI warning

[Jeff Garzik]

Ingo Molnar wrote:
> i'm also getting this WARN_ON() from e1000:
> 
> BUG: at drivers/pci/msi.c:611 pci_enable_msi()
>  [<c01061bd>] show_trace_log_lvl+0x19/0x2e
>  [<c01062b6>] show_trace+0x12/0x14
>  [<c01062cc>] dump_stack+0x14/0x16
>  [<c024fcc4>] pci_enable_msi+0x6d/0x203
>  [<c02b709e>] e1000_request_irq+0x2e/0xe2
>  [<c02bb742>] e1000_resume+0x7f/0xef
>  [<c0249a68>] pci_device_resume+0x1a/0x44
>  [<c02b39ec>] resume_device+0xf7/0x16f
>  [<c02b3adb>] dpm_resume+0x77/0xcb
>  [<c02b3b69>] device_resume+0x3a/0x51
>  [<c014e669>] enter_state+0x193/0x1bb
>  [<c014e712>] state_store+0x81/0x97
>  [<c01b68bc>] subsys_attr_store+0x20/0x25
>  [<c01b6feb>] sysfs_write_file+0xce/0xf6
>  [<c017e16b>] vfs_write+0xb1/0x13a
>  [<c017e899>] sys_write+0x3d/0x61
>  [<c0105220>] syscall_call+0x7/0xb
> 
> seems harmless because it seems to work fine.


I would poke Eric Biederman(sp?) about this one.  Maybe its even solved 
by the MSI-enable-related patch he posted in the past 24-48 hours.

	Jeff

Re: SATA resume slowness, e1000 MSI warning

[Kok, Auke]

Jeff Garzik wrote:
> Ingo Molnar wrote:
>> i'm also getting this WARN_ON() from e1000:
>>
>> BUG: at drivers/pci/msi.c:611 pci_enable_msi()
>>  [<c01061bd>] show_trace_log_lvl+0x19/0x2e
>>  [<c01062b6>] show_trace+0x12/0x14
>>  [<c01062cc>] dump_stack+0x14/0x16
>>  [<c024fcc4>] pci_enable_msi+0x6d/0x203
>>  [<c02b709e>] e1000_request_irq+0x2e/0xe2
>>  [<c02bb742>] e1000_resume+0x7f/0xef
>>  [<c0249a68>] pci_device_resume+0x1a/0x44
>>  [<c02b39ec>] resume_device+0xf7/0x16f
>>  [<c02b3adb>] dpm_resume+0x77/0xcb
>>  [<c02b3b69>] device_resume+0x3a/0x51
>>  [<c014e669>] enter_state+0x193/0x1bb
>>  [<c014e712>] state_store+0x81/0x97
>>  [<c01b68bc>] subsys_attr_store+0x20/0x25
>>  [<c01b6feb>] sysfs_write_file+0xce/0xf6
>>  [<c017e16b>] vfs_write+0xb1/0x13a
>>  [<c017e899>] sys_write+0x3d/0x61
>>  [<c0105220>] syscall_call+0x7/0xb
>>
>> seems harmless because it seems to work fine.
> 
> I would poke Eric Biederman(sp?) about this one.  Maybe its even solved 
> by the MSI-enable-related patch he posted in the past 24-48 hours.


Eric, Linus,

I tried the 3-patch series "[PATCH 0/3] Basic msi bug fixes.." and they fix this 
problem for me. Were you expecting the OOPS in the first place? In any case, it 
survived several suspend/resume cycles on both enabled (irq alloc'd and enabled) 
and disabled devices (only initialized).

Jens Axboe was seeing the same problem, perhaps he can confirm the fix as well.

In any case, the patches have my blessing :)

Please add my:

   Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>


Cheers,

Auke

Re: SATA resume slowness, e1000 MSI warning

[Kok, Auke]

Jeff Garzik wrote:
> Ingo Molnar wrote:
>> i'm also getting this WARN_ON() from e1000:
>>
>> BUG: at drivers/pci/msi.c:611 pci_enable_msi()
>>  [<c01061bd>] show_trace_log_lvl+0x19/0x2e
>>  [<c01062b6>] show_trace+0x12/0x14
>>  [<c01062cc>] dump_stack+0x14/0x16
>>  [<c024fcc4>] pci_enable_msi+0x6d/0x203
>>  [<c02b709e>] e1000_request_irq+0x2e/0xe2
>>  [<c02bb742>] e1000_resume+0x7f/0xef
>>  [<c0249a68>] pci_device_resume+0x1a/0x44
>>  [<c02b39ec>] resume_device+0xf7/0x16f
>>  [<c02b3adb>] dpm_resume+0x77/0xcb
>>  [<c02b3b69>] device_resume+0x3a/0x51
>>  [<c014e669>] enter_state+0x193/0x1bb
>>  [<c014e712>] state_store+0x81/0x97
>>  [<c01b68bc>] subsys_attr_store+0x20/0x25
>>  [<c01b6feb>] sysfs_write_file+0xce/0xf6
>>  [<c017e16b>] vfs_write+0xb1/0x13a
>>  [<c017e899>] sys_write+0x3d/0x61
>>  [<c0105220>] syscall_call+0x7/0xb
>>
>> seems harmless because it seems to work fine.
> 
> I would poke Eric Biederman(sp?) about this one.  Maybe its even solved 
> by the MSI-enable-related patch he posted in the past 24-48 hours.


Eric, Linus,

I tried the 3-patch series "[PATCH 0/3] Basic msi bug fixes.." and they fix this 
problem for me. Were you expecting the OOPS in the first place? In any case, it 
survived several suspend/resume cycles on both enabled (irq alloc'd and enabled) 
and disabled devices (only initialized).

Jens Axboe was seeing the same problem, perhaps he can confirm the fix as well.

In any case, the patches have my blessing :)

Please add my:

   Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>


Cheers,

Auke

Re: SATA resume slowness, e1000 MSI warning

[Ingo Molnar]

* Kok, Auke <auke-jan.h.kok@intel.com> wrote:

> >>BUG: at drivers/pci/msi.c:611 pci_enable_msi()

> >I would poke Eric Biederman(sp?) about this one.  Maybe its even 
> >solved by the MSI-enable-related patch he posted in the past 24-48 
> >hours.
> 
> I tried the 3-patch series "[PATCH 0/3] Basic msi bug fixes.." and 
> they fix this problem for me. Were you expecting the OOPS in the first 
> place? [...]

the bug was the warning message (a WARN_ON()) above - not an oops. So 
that warning message is gone in your testing?

	Ingo

Re: SATA resume slowness, e1000 MSI warning

[Ingo Molnar]

* Kok, Auke <auke-jan.h.kok@intel.com> wrote:

> >>BUG: at drivers/pci/msi.c:611 pci_enable_msi()

> >I would poke Eric Biederman(sp?) about this one.  Maybe its even 
> >solved by the MSI-enable-related patch he posted in the past 24-48 
> >hours.
> 
> I tried the 3-patch series "[PATCH 0/3] Basic msi bug fixes.." and 
> they fix this problem for me. Were you expecting the OOPS in the first 
> place? [...]

the bug was the warning message (a WARN_ON()) above - not an oops. So 
that warning message is gone in your testing?

	Ingo

Re: SATA resume slowness, e1000 MSI warning

[Kok, Auke]

Ingo Molnar wrote:
> * Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> 
>>>> BUG: at drivers/pci/msi.c:611 pci_enable_msi()
> 
>>> I would poke Eric Biederman(sp?) about this one.  Maybe its even 
>>> solved by the MSI-enable-related patch he posted in the past 24-48 
>>> hours.
>> I tried the 3-patch series "[PATCH 0/3] Basic msi bug fixes.." and 
>> they fix this problem for me. Were you expecting the OOPS in the first 
>> place? [...]
> 
> the bug was the warning message (a WARN_ON()) above - not an oops. So 
> that warning message is gone in your testing?

yes.

Auke

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Kok, Auke" <auke-jan.h.kok@intel.com> writes:

> Ingo Molnar wrote:
>> * Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>>
>>>>> BUG: at drivers/pci/msi.c:611 pci_enable_msi()
>>
>>>> I would poke Eric Biederman(sp?) about this one.  Maybe its even solved by
>>>> the MSI-enable-related patch he posted in the past 24-48 hours.
>>> I tried the 3-patch series "[PATCH 0/3] Basic msi bug fixes.." and they fix
>>> this problem for me. Were you expecting the OOPS in the first place? [...]
>>
>> the bug was the warning message (a WARN_ON()) above - not an oops. So that
>> warning message is gone in your testing?
>
> yes.

Sorry for the slow delay.  I was out of town for my brothers wedding the last few
days.

I wasn't exactly expecting the WARN_ON to trigger.  What I fixed was
an inconsistency in handling our state bits.  Fixing that
inconsistency appears to have fixed the e1000 usage scenario mostly by
accident.

The basic issue is that pci_save_state saves the current msi state
along with other registers, and then the e1000 driver goes and
disables the msi irq after we have saved the irq state as on.

My code notices that the msi irq was disabled before restore time, so
it skips the restore.  However we now have a leak of the msi saved cap
because we are not freeing it. 

This leaves with some basic questions.
- Does it make sense for suspend/resume methods to request/free irqs?
- Does it make sense for suspend/resume methods to allocate/free msi irqs?
- Do we want pci_save/restore_cap to save/restore msi state?

The path of least resistance is to just free the extra state and we
are good.  I'm just not quite certain that is sane and it has been a
long day.

Eric

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Kok, Auke" <auke-jan.h.kok@intel.com> writes:

> Ingo Molnar wrote:
>> * Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>>
>>>>> BUG: at drivers/pci/msi.c:611 pci_enable_msi()
>>
>>>> I would poke Eric Biederman(sp?) about this one.  Maybe its even solved by
>>>> the MSI-enable-related patch he posted in the past 24-48 hours.
>>> I tried the 3-patch series "[PATCH 0/3] Basic msi bug fixes.." and they fix
>>> this problem for me. Were you expecting the OOPS in the first place? [...]
>>
>> the bug was the warning message (a WARN_ON()) above - not an oops. So that
>> warning message is gone in your testing?
>
> yes.

Sorry for the slow delay.  I was out of town for my brothers wedding the last few
days.

I wasn't exactly expecting the WARN_ON to trigger.  What I fixed was
an inconsistency in handling our state bits.  Fixing that
inconsistency appears to have fixed the e1000 usage scenario mostly by
accident.

The basic issue is that pci_save_state saves the current msi state
along with other registers, and then the e1000 driver goes and
disables the msi irq after we have saved the irq state as on.

My code notices that the msi irq was disabled before restore time, so
it skips the restore.  However we now have a leak of the msi saved cap
because we are not freeing it. 

This leaves with some basic questions.
- Does it make sense for suspend/resume methods to request/free irqs?
- Does it make sense for suspend/resume methods to allocate/free msi irqs?
- Do we want pci_save/restore_cap to save/restore msi state?

The path of least resistance is to just free the extra state and we
are good.  I'm just not quite certain that is sane and it has been a
long day.

Eric

Re: SATA resume slowness, e1000 MSI warning

[Kok, Auke]

Eric W. Biederman wrote:
> "Kok, Auke" <auke-jan.h.kok@intel.com> writes:
> 
>> Ingo Molnar wrote:
>>> * Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>>>
>>>>>> BUG: at drivers/pci/msi.c:611 pci_enable_msi()
>>>>> I would poke Eric Biederman(sp?) about this one.  Maybe its even solved by
>>>>> the MSI-enable-related patch he posted in the past 24-48 hours.
>>>> I tried the 3-patch series "[PATCH 0/3] Basic msi bug fixes.." and they fix
>>>> this problem for me. Were you expecting the OOPS in the first place? [...]
>>> the bug was the warning message (a WARN_ON()) above - not an oops. So that
>>> warning message is gone in your testing?
>> yes.
> 
> Sorry for the slow delay.  I was out of town for my brothers wedding the last few
> days.
> 
> I wasn't exactly expecting the WARN_ON to trigger.  What I fixed was
> an inconsistency in handling our state bits.  Fixing that
> inconsistency appears to have fixed the e1000 usage scenario mostly by
> accident.
> 
> The basic issue is that pci_save_state saves the current msi state
> along with other registers, and then the e1000 driver goes and
> disables the msi irq after we have saved the irq state as on.
> 
> My code notices that the msi irq was disabled before restore time, so
> it skips the restore.  However we now have a leak of the msi saved cap
> because we are not freeing it. 
> 
> This leaves with some basic questions.
> - Does it make sense for suspend/resume methods to request/free irqs?
> - Does it make sense for suspend/resume methods to allocate/free msi irqs?
> - Do we want pci_save/restore_cap to save/restore msi state?
> 
> The path of least resistance is to just free the extra state and we
> are good.  I'm just not quite certain that is sane and it has been a
> long day.

we used to have a lengthy e1000_pci_save|restore_state in our code, which is now 
gone, so I'm all for that. A separate pci_save_pxie|msi(x)_state for every 
driver seems completely unnecessary. I can't think of a use case where 
saving+restoring everything hurts. That's what you want I presume.

We currently free all irq's and msi before going into suspend in e1000, and I 
think that is probably a good thing, somehow I can think of bad things happening 
if we dont, but I admit that I haven't tried it without alloc/free. We do this 
in e100 as well and it works.

Another motivation would be to leave this up to the driver: if the driver 
chooses to free/alloc interrupts because it makes sense, you probably would want 
to keep that choice available. Devices that don't need this can skip the 
alloc/free, but leave the choice open for others.

hth

Auke

Re: SATA resume slowness, e1000 MSI warning

[Kok, Auke]

Eric W. Biederman wrote:
> "Kok, Auke" <auke-jan.h.kok@intel.com> writes:
> 
>> Ingo Molnar wrote:
>>> * Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>>>
>>>>>> BUG: at drivers/pci/msi.c:611 pci_enable_msi()
>>>>> I would poke Eric Biederman(sp?) about this one.  Maybe its even solved by
>>>>> the MSI-enable-related patch he posted in the past 24-48 hours.
>>>> I tried the 3-patch series "[PATCH 0/3] Basic msi bug fixes.." and they fix
>>>> this problem for me. Were you expecting the OOPS in the first place? [...]
>>> the bug was the warning message (a WARN_ON()) above - not an oops. So that
>>> warning message is gone in your testing?
>> yes.
> 
> Sorry for the slow delay.  I was out of town for my brothers wedding the last few
> days.
> 
> I wasn't exactly expecting the WARN_ON to trigger.  What I fixed was
> an inconsistency in handling our state bits.  Fixing that
> inconsistency appears to have fixed the e1000 usage scenario mostly by
> accident.
> 
> The basic issue is that pci_save_state saves the current msi state
> along with other registers, and then the e1000 driver goes and
> disables the msi irq after we have saved the irq state as on.
> 
> My code notices that the msi irq was disabled before restore time, so
> it skips the restore.  However we now have a leak of the msi saved cap
> because we are not freeing it. 
> 
> This leaves with some basic questions.
> - Does it make sense for suspend/resume methods to request/free irqs?
> - Does it make sense for suspend/resume methods to allocate/free msi irqs?
> - Do we want pci_save/restore_cap to save/restore msi state?
> 
> The path of least resistance is to just free the extra state and we
> are good.  I'm just not quite certain that is sane and it has been a
> long day.

we used to have a lengthy e1000_pci_save|restore_state in our code, which is now 
gone, so I'm all for that. A separate pci_save_pxie|msi(x)_state for every 
driver seems completely unnecessary. I can't think of a use case where 
saving+restoring everything hurts. That's what you want I presume.

We currently free all irq's and msi before going into suspend in e1000, and I 
think that is probably a good thing, somehow I can think of bad things happening 
if we dont, but I admit that I haven't tried it without alloc/free. We do this 
in e100 as well and it works.

Another motivation would be to leave this up to the driver: if the driver 
chooses to free/alloc interrupts because it makes sense, you probably would want 
to keep that choice available. Devices that don't need this can skip the 
alloc/free, but leave the choice open for others.

hth

Auke

Re: SATA resume slowness, e1000 MSI warning

[Kok, Auke]

Kok, Auke wrote:
> Eric W. Biederman wrote:
>> "Kok, Auke" <auke-jan.h.kok@intel.com> writes:
>>
>>> Ingo Molnar wrote:
>>>> * Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>>>>
>>>>>>> BUG: at drivers/pci/msi.c:611 pci_enable_msi()
>>>>>> I would poke Eric Biederman(sp?) about this one.  Maybe its even solved by
>>>>>> the MSI-enable-related patch he posted in the past 24-48 hours.
>>>>> I tried the 3-patch series "[PATCH 0/3] Basic msi bug fixes.." and they fix
>>>>> this problem for me. Were you expecting the OOPS in the first place? [...]
>>>> the bug was the warning message (a WARN_ON()) above - not an oops. So that
>>>> warning message is gone in your testing?
>>> yes.
>> Sorry for the slow delay.  I was out of town for my brothers wedding the last few
>> days.
>>
>> I wasn't exactly expecting the WARN_ON to trigger.  What I fixed was
>> an inconsistency in handling our state bits.  Fixing that
>> inconsistency appears to have fixed the e1000 usage scenario mostly by
>> accident.
>>
>> The basic issue is that pci_save_state saves the current msi state
>> along with other registers, and then the e1000 driver goes and
>> disables the msi irq after we have saved the irq state as on.
>>
>> My code notices that the msi irq was disabled before restore time, so
>> it skips the restore.  However we now have a leak of the msi saved cap
>> because we are not freeing it. 
>>
>> This leaves with some basic questions.
>> - Does it make sense for suspend/resume methods to request/free irqs?
>> - Does it make sense for suspend/resume methods to allocate/free msi irqs?
>> - Do we want pci_save/restore_cap to save/restore msi state?
>>
>> The path of least resistance is to just free the extra state and we
>> are good.  I'm just not quite certain that is sane and it has been a
>> long day.
> 
> we used to have a lengthy e1000_pci_save|restore_state in our code, which is now 
> gone, so I'm all for that. A separate pci_save_pxie|msi(x)_state for every 
> driver seems completely unnecessary. I can't think of a use case where 
> saving+restoring everything hurts. That's what you want I presume.
> 
> We currently free all irq's and msi before going into suspend in e1000, and I 
> think that is probably a good thing, somehow I can think of bad things happening 
> if we dont, but I admit that I haven't tried it without alloc/free. We do this 
> in e100 as well and it works.
> 
> Another motivation would be to leave this up to the driver: if the driver 
> chooses to free/alloc interrupts because it makes sense, you probably would want 
> to keep that choice available. Devices that don't need this can skip the 
> alloc/free, but leave the choice open for others.

ah, looking at the code in e1000 we do:

_suspend:
	pci_save_state();
	free_irq()

_resume:
	pci_restore_state();
	alloc_irq();

I suppose that's not good either, and the major cause of the warning in the 
first place.

Maybe I can rollback your latest patches and try to fix that mess by postponing 
the pci_save_state until after we free'd the irq's.

Auke

Re: SATA resume slowness, e1000 MSI warning

[Kok, Auke]

Kok, Auke wrote:
> Eric W. Biederman wrote:
>> "Kok, Auke" <auke-jan.h.kok@intel.com> writes:
>>
>>> Ingo Molnar wrote:
>>>> * Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>>>>
>>>>>>> BUG: at drivers/pci/msi.c:611 pci_enable_msi()
>>>>>> I would poke Eric Biederman(sp?) about this one.  Maybe its even solved by
>>>>>> the MSI-enable-related patch he posted in the past 24-48 hours.
>>>>> I tried the 3-patch series "[PATCH 0/3] Basic msi bug fixes.." and they fix
>>>>> this problem for me. Were you expecting the OOPS in the first place? [...]
>>>> the bug was the warning message (a WARN_ON()) above - not an oops. So that
>>>> warning message is gone in your testing?
>>> yes.
>> Sorry for the slow delay.  I was out of town for my brothers wedding the last few
>> days.
>>
>> I wasn't exactly expecting the WARN_ON to trigger.  What I fixed was
>> an inconsistency in handling our state bits.  Fixing that
>> inconsistency appears to have fixed the e1000 usage scenario mostly by
>> accident.
>>
>> The basic issue is that pci_save_state saves the current msi state
>> along with other registers, and then the e1000 driver goes and
>> disables the msi irq after we have saved the irq state as on.
>>
>> My code notices that the msi irq was disabled before restore time, so
>> it skips the restore.  However we now have a leak of the msi saved cap
>> because we are not freeing it. 
>>
>> This leaves with some basic questions.
>> - Does it make sense for suspend/resume methods to request/free irqs?
>> - Does it make sense for suspend/resume methods to allocate/free msi irqs?
>> - Do we want pci_save/restore_cap to save/restore msi state?
>>
>> The path of least resistance is to just free the extra state and we
>> are good.  I'm just not quite certain that is sane and it has been a
>> long day.
> 
> we used to have a lengthy e1000_pci_save|restore_state in our code, which is now 
> gone, so I'm all for that. A separate pci_save_pxie|msi(x)_state for every 
> driver seems completely unnecessary. I can't think of a use case where 
> saving+restoring everything hurts. That's what you want I presume.
> 
> We currently free all irq's and msi before going into suspend in e1000, and I 
> think that is probably a good thing, somehow I can think of bad things happening 
> if we dont, but I admit that I haven't tried it without alloc/free. We do this 
> in e100 as well and it works.
> 
> Another motivation would be to leave this up to the driver: if the driver 
> chooses to free/alloc interrupts because it makes sense, you probably would want 
> to keep that choice available. Devices that don't need this can skip the 
> alloc/free, but leave the choice open for others.

ah, looking at the code in e1000 we do:

_suspend:
	pci_save_state();
	free_irq()

_resume:
	pci_restore_state();
	alloc_irq();

I suppose that's not good either, and the major cause of the warning in the 
first place.

Maybe I can rollback your latest patches and try to fix that mess by postponing 
the pci_save_state until after we free'd the irq's.

Auke

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Kok, Auke" <auke-jan.h.kok@intel.com> writes:

> Kok, Auke wrote:
>> Eric W. Biederman wrote:

>>> This leaves with some basic questions.
>>> - Does it make sense for suspend/resume methods to request/free irqs?
>>> - Does it make sense for suspend/resume methods to allocate/free msi irqs?
>>> - Do we want pci_save/restore_cap to save/restore msi state?
>>>
>>> The path of least resistance is to just free the extra state and we
>>> are good.  I'm just not quite certain that is sane and it has been a
>>> long day.
>>
>> we used to have a lengthy e1000_pci_save|restore_state in our code, which is
>> now gone, so I'm all for that. A separate pci_save_pxie|msi(x)_state for every
>> driver seems completely unnecessary. I can't think of a use case where
>> saving+restoring everything hurts. That's what you want I presume.

I just want to understand why we have issues and to see if how we have
organized the suspend/resume path for dealing with msi irqs makes sense.

That is I haven't looked much at the suspend/resume path so I don't know it
well and I am afraid that your problem might be a symptom of a deeper
problem.

>> We currently free all irq's and msi before going into suspend in e1000, and I
>> think that is probably a good thing, somehow I can think of bad things
>> happening if we dont, but I admit that I haven't tried it without
>> alloc/free. We do this in e100 as well and it works.

Currently the irq code supports operation without the
free_irq/request_irq.  Since the numbers given are pure linux
abstractions things should it is really a matter of just
saving/restoring the appropriate state.

>> Another motivation would be to leave this up to the driver: if the driver
>> chooses to free/alloc interrupts because it makes sense, you probably would
>> want to keep that choice available. Devices that don't need this can skip the
>> alloc/free, but leave the choice open for others.
>
> ah, looking at the code in e1000 we do:
>
> _suspend:
> 	pci_save_state();
> 	free_irq()
>
> _resume:
> 	pci_restore_state();
> 	alloc_irq();
>
> I suppose that's not good either, and the major cause of the warning in the
> first place.

Yep. 

> Maybe I can rollback your latest patches and try to fix that mess by postponing
> the pci_save_state until after we free'd the irq's.

Below is an additional set of warnings that should help debug this.
The old code just got lucky that it triggered a warning when this happens.

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 01869b1..5113913 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -613,6 +613,7 @@ int pci_enable_msi(struct pci_dev* dev)
 		return -EINVAL;
 
 	WARN_ON(!!dev->msi_enabled);
+	WARN_ON(!hlist_empty(&dev->saved_cap_space));
 
 	/* Check whether driver already requested for MSI-X irqs */
 	if (dev->msix_enabled) {
@@ -638,6 +639,8 @@ void pci_disable_msi(struct pci_dev* dev)
 	if (!dev->msi_enabled)
 		return;
 
+	WARN_ON(!hlist_empty(&dev->saved_cap_space));
+
 	msi_set_enable(dev, 0);
 	pci_intx(dev, 1);		/* enable intx */
 	dev->msi_enabled = 0;
@@ -739,6 +742,7 @@ int pci_enable_msix(struct pci_dev* dev, struct msix_entry *entries, int nvec)
 		}
 	}
 	WARN_ON(!!dev->msix_enabled);
+	WARN_ON(!hlist_empty(&dev->saved_cap_space));
 
 	/* Check whether driver already requested for MSI irq */
    	if (dev->msi_enabled) {
@@ -763,6 +767,8 @@ void pci_disable_msix(struct pci_dev* dev)
 	if (!dev->msix_enabled)
 		return;
 
+	WARN_ON(!hlist_empty(&dev->saved_cap_space));
+
 	msix_set_enable(dev, 0);
 	pci_intx(dev, 1);		/* enable intx */
 	dev->msix_enabled = 0;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index bd44a48..4418839 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -677,6 +677,7 @@ pci_restore_state(struct pci_dev *dev)
 	}
 	pci_restore_pcix_state(dev);
 	pci_restore_msi_state(dev);
+	WARN_ON(!hlist_empty(&dev->saved_cap_space));
 
 	return 0;
 }

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Kok, Auke" <auke-jan.h.kok@intel.com> writes:

> Kok, Auke wrote:
>> Eric W. Biederman wrote:

>>> This leaves with some basic questions.
>>> - Does it make sense for suspend/resume methods to request/free irqs?
>>> - Does it make sense for suspend/resume methods to allocate/free msi irqs?
>>> - Do we want pci_save/restore_cap to save/restore msi state?
>>>
>>> The path of least resistance is to just free the extra state and we
>>> are good.  I'm just not quite certain that is sane and it has been a
>>> long day.
>>
>> we used to have a lengthy e1000_pci_save|restore_state in our code, which is
>> now gone, so I'm all for that. A separate pci_save_pxie|msi(x)_state for every
>> driver seems completely unnecessary. I can't think of a use case where
>> saving+restoring everything hurts. That's what you want I presume.

I just want to understand why we have issues and to see if how we have
organized the suspend/resume path for dealing with msi irqs makes sense.

That is I haven't looked much at the suspend/resume path so I don't know it
well and I am afraid that your problem might be a symptom of a deeper
problem.

>> We currently free all irq's and msi before going into suspend in e1000, and I
>> think that is probably a good thing, somehow I can think of bad things
>> happening if we dont, but I admit that I haven't tried it without
>> alloc/free. We do this in e100 as well and it works.

Currently the irq code supports operation without the
free_irq/request_irq.  Since the numbers given are pure linux
abstractions things should it is really a matter of just
saving/restoring the appropriate state.

>> Another motivation would be to leave this up to the driver: if the driver
>> chooses to free/alloc interrupts because it makes sense, you probably would
>> want to keep that choice available. Devices that don't need this can skip the
>> alloc/free, but leave the choice open for others.
>
> ah, looking at the code in e1000 we do:
>
> _suspend:
> 	pci_save_state();
> 	free_irq()
>
> _resume:
> 	pci_restore_state();
> 	alloc_irq();
>
> I suppose that's not good either, and the major cause of the warning in the
> first place.

Yep. 

> Maybe I can rollback your latest patches and try to fix that mess by postponing
> the pci_save_state until after we free'd the irq's.

Below is an additional set of warnings that should help debug this.
The old code just got lucky that it triggered a warning when this happens.

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 01869b1..5113913 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -613,6 +613,7 @@ int pci_enable_msi(struct pci_dev* dev)
 		return -EINVAL;
 
 	WARN_ON(!!dev->msi_enabled);
+	WARN_ON(!hlist_empty(&dev->saved_cap_space));
 
 	/* Check whether driver already requested for MSI-X irqs */
 	if (dev->msix_enabled) {
@@ -638,6 +639,8 @@ void pci_disable_msi(struct pci_dev* dev)
 	if (!dev->msi_enabled)
 		return;
 
+	WARN_ON(!hlist_empty(&dev->saved_cap_space));
+
 	msi_set_enable(dev, 0);
 	pci_intx(dev, 1);		/* enable intx */
 	dev->msi_enabled = 0;
@@ -739,6 +742,7 @@ int pci_enable_msix(struct pci_dev* dev, struct msix_entry *entries, int nvec)
 		}
 	}
 	WARN_ON(!!dev->msix_enabled);
+	WARN_ON(!hlist_empty(&dev->saved_cap_space));
 
 	/* Check whether driver already requested for MSI irq */
    	if (dev->msi_enabled) {
@@ -763,6 +767,8 @@ void pci_disable_msix(struct pci_dev* dev)
 	if (!dev->msix_enabled)
 		return;
 
+	WARN_ON(!hlist_empty(&dev->saved_cap_space));
+
 	msix_set_enable(dev, 0);
 	pci_intx(dev, 1);		/* enable intx */
 	dev->msix_enabled = 0;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index bd44a48..4418839 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -677,6 +677,7 @@ pci_restore_state(struct pci_dev *dev)
 	}
 	pci_restore_pcix_state(dev);
 	pci_restore_msi_state(dev);
+	WARN_ON(!hlist_empty(&dev->saved_cap_space));
 
 	return 0;
 }

Re: SATA resume slowness, e1000 MSI warning

[Andrew Morton]

On Wed, 07 Mar 2007 12:28:11 -0700 ebiederm@xmission.com (Eric W. Biederman) wrote:

> Below is an additional set of warnings that should help debug this.
> The old code just got lucky that it triggered a warning when this happens.
> 
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 01869b1..5113913 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -613,6 +613,7 @@ int pci_enable_msi(struct pci_dev* dev)
>  		return -EINVAL;
>  
>  	WARN_ON(!!dev->msi_enabled);
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
>  
>  	/* Check whether driver already requested for MSI-X irqs */
>  	if (dev->msix_enabled) {
> @@ -638,6 +639,8 @@ void pci_disable_msi(struct pci_dev* dev)
>  	if (!dev->msi_enabled)
>  		return;
>  
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
> +
>  	msi_set_enable(dev, 0);
>  	pci_intx(dev, 1);		/* enable intx */
>  	dev->msi_enabled = 0;
> @@ -739,6 +742,7 @@ int pci_enable_msix(struct pci_dev* dev, struct msix_entry *entries, int nvec)
>  		}
>  	}
>  	WARN_ON(!!dev->msix_enabled);
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
>  
>  	/* Check whether driver already requested for MSI irq */
>     	if (dev->msi_enabled) {
> @@ -763,6 +767,8 @@ void pci_disable_msix(struct pci_dev* dev)
>  	if (!dev->msix_enabled)
>  		return;
>  
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
> +
>  	msix_set_enable(dev, 0);
>  	pci_intx(dev, 1);		/* enable intx */
>  	dev->msix_enabled = 0;
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index bd44a48..4418839 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -677,6 +677,7 @@ pci_restore_state(struct pci_dev *dev)
>  	}
>  	pci_restore_pcix_state(dev);
>  	pci_restore_msi_state(dev);
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
>  
>  	return 0;
>  }

Got a hit on a powerpc g5:

PM: Writing back config space on device 0001:05:04.0 at offset 1 (was 2b00000, writing 2b00006)
------------[ cut here ]------------
Badness at drivers/pci/pci.c:679
Call Trace:
[C0000000080F7410] [C000000000011EFC] .show_stack+0x50/0x1cc (unreliable)
[C0000000080F74C0] [C0000000001AD610] .report_bug+0xa0/0x110
[C0000000080F7550] [C0000000000256E4] .program_check_exception+0xb4/0x670
[C0000000080F7630] [C0000000000046F4] program_check_common+0xf4/0x100
--- Exception: 700 at .pci_restore_state+0x310/0x340
    LR = .pci_restore_state+0x2e0/0x340
[C0000000080F79D0] [C00000000026A174] .tg3_chip_reset+0x19c/0xa04
[C0000000080F7A90] [C00000000026D948] .tg3_reset_hw+0xa4/0x2718
[C0000000080F7BA0] [C000000000270030] .tg3_init_hw+0x74/0x94
[C0000000080F7C30] [C000000000270BE0] .tg3_open+0x4c8/0x854
[C0000000080F7CF0] [C0000000003A74A4] .dev_open+0x100/0x12c
[C0000000080F7D90] [C0000000003BAEA8] .netpoll_setup+0x2dc/0x3ec
[C0000000080F7E40] [C000000000283450] .init_netconsole+0x64/0x8c
[C0000000080F7EC0] [C0000000005C0BE4] .init+0x1d0/0x390
[C0000000080F7F90] [C0000000000271F8] .kernel_thread+0x4c/0x68
tg3: eth0: Link is up at 1000 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
Scheduler bitmap error - bitmap being reconstructed..
netconsole: network logging started
Calling initcall 0xc0000000006bd180: .macio_module_init+0x0/0x3c()

That's:

        pci_restore_pcix_state(dev);
        pci_restore_msi_state(dev);
        WARN_ON(!hlist_empty(&dev->saved_cap_space));

        return 0;

Re: SATA resume slowness, e1000 MSI warning

[Andrew Morton]

On Wed, 07 Mar 2007 12:28:11 -0700 ebiederm@xmission.com (Eric W. Biederman) wrote:

> Below is an additional set of warnings that should help debug this.
> The old code just got lucky that it triggered a warning when this happens.
> 
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 01869b1..5113913 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -613,6 +613,7 @@ int pci_enable_msi(struct pci_dev* dev)
>  		return -EINVAL;
>  
>  	WARN_ON(!!dev->msi_enabled);
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
>  
>  	/* Check whether driver already requested for MSI-X irqs */
>  	if (dev->msix_enabled) {
> @@ -638,6 +639,8 @@ void pci_disable_msi(struct pci_dev* dev)
>  	if (!dev->msi_enabled)
>  		return;
>  
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
> +
>  	msi_set_enable(dev, 0);
>  	pci_intx(dev, 1);		/* enable intx */
>  	dev->msi_enabled = 0;
> @@ -739,6 +742,7 @@ int pci_enable_msix(struct pci_dev* dev, struct msix_entry *entries, int nvec)
>  		}
>  	}
>  	WARN_ON(!!dev->msix_enabled);
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
>  
>  	/* Check whether driver already requested for MSI irq */
>     	if (dev->msi_enabled) {
> @@ -763,6 +767,8 @@ void pci_disable_msix(struct pci_dev* dev)
>  	if (!dev->msix_enabled)
>  		return;
>  
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
> +
>  	msix_set_enable(dev, 0);
>  	pci_intx(dev, 1);		/* enable intx */
>  	dev->msix_enabled = 0;
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index bd44a48..4418839 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -677,6 +677,7 @@ pci_restore_state(struct pci_dev *dev)
>  	}
>  	pci_restore_pcix_state(dev);
>  	pci_restore_msi_state(dev);
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
>  
>  	return 0;
>  }

Got a hit on a powerpc g5:

PM: Writing back config space on device 0001:05:04.0 at offset 1 (was 2b00000, writing 2b00006)
------------[ cut here ]------------
Badness at drivers/pci/pci.c:679
Call Trace:
[C0000000080F7410] [C000000000011EFC] .show_stack+0x50/0x1cc (unreliable)
[C0000000080F74C0] [C0000000001AD610] .report_bug+0xa0/0x110
[C0000000080F7550] [C0000000000256E4] .program_check_exception+0xb4/0x670
[C0000000080F7630] [C0000000000046F4] program_check_common+0xf4/0x100
--- Exception: 700 at .pci_restore_state+0x310/0x340
    LR = .pci_restore_state+0x2e0/0x340
[C0000000080F79D0] [C00000000026A174] .tg3_chip_reset+0x19c/0xa04
[C0000000080F7A90] [C00000000026D948] .tg3_reset_hw+0xa4/0x2718
[C0000000080F7BA0] [C000000000270030] .tg3_init_hw+0x74/0x94
[C0000000080F7C30] [C000000000270BE0] .tg3_open+0x4c8/0x854
[C0000000080F7CF0] [C0000000003A74A4] .dev_open+0x100/0x12c
[C0000000080F7D90] [C0000000003BAEA8] .netpoll_setup+0x2dc/0x3ec
[C0000000080F7E40] [C000000000283450] .init_netconsole+0x64/0x8c
[C0000000080F7EC0] [C0000000005C0BE4] .init+0x1d0/0x390
[C0000000080F7F90] [C0000000000271F8] .kernel_thread+0x4c/0x68
tg3: eth0: Link is up at 1000 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
Scheduler bitmap error - bitmap being reconstructed..
netconsole: network logging started
Calling initcall 0xc0000000006bd180: .macio_module_init+0x0/0x3c()

That's:

        pci_restore_pcix_state(dev);
        pci_restore_msi_state(dev);
        WARN_ON(!hlist_empty(&dev->saved_cap_space));

        return 0;

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

Andrew Morton <akpm@linux-foundation.org> writes:

>
> That's:
>
>         pci_restore_pcix_state(dev);
>         pci_restore_msi_state(dev);
>         WARN_ON(!hlist_empty(&dev->saved_cap_space));
>
>         return 0;

Hmm.  Either I am confused of I just found an unanticipated leak.

pci_restore_msi_state should be out of the picture as we don't yet
have ppc msi support and I don't think the g5 generation hardware
supported it either.

The only case I can see which might trigger this is if we saved
pci-X state and then didn't restore it because we could not find
the capability on restore.

Any chance you could walk that list and find the cap_nr of the remaining
element?  

Something like:
{
	struct pci_cap_saved_state *tmp;
	struct hlist_node *pos;

	hlist_for_each_entry(tmp, pos, &pci_dev->saved_cap_space, next)
        	printk(KERN_INFO "saved_cap: 0x%02x\n", tmp->cap_nr);
}

Until I get the best scenario I can come up with is a tg3 hardware bug
that doesn't renable the pci-X capability after a restore of power state.

Getting that cap_nr will at least allow me to be certain if I am dealing
with msi, pci-X or pci-e.

Unanticipated bugs aren't supposed to be this easy to find!

Eric

Re: SATA resume slowness, e1000 MSI warning

[Jeff Garzik]

Eric W. Biederman wrote:
> Until I get the best scenario I can come up with is a tg3 hardware bug
> that doesn't renable the pci-X capability after a restore of power state.


Speaking of tg3, make sure you are aware that the number of calls to 
save-state functions may not match the number of calls to the 
restore-state functions.  ISTR seeing some memleak bugs in PCI related 
to this.

	Jeff

Re: SATA resume slowness, e1000 MSI warning

[Jeff Garzik]

Eric W. Biederman wrote:
> Until I get the best scenario I can come up with is a tg3 hardware bug
> that doesn't renable the pci-X capability after a restore of power state.


Speaking of tg3, make sure you are aware that the number of calls to 
save-state functions may not match the number of calls to the 
restore-state functions.  ISTR seeing some memleak bugs in PCI related 
to this.

	Jeff

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

Jeff Garzik <jeff@garzik.org> writes:

> Eric W. Biederman wrote:
>> Until I get the best scenario I can come up with is a tg3 hardware bug
>> that doesn't renable the pci-X capability after a restore of power state.
>
>
> Speaking of tg3, make sure you are aware that the number of calls to save-state
> functions may not match the number of calls to the restore-state functions.
> ISTR seeing some memleak bugs in PCI related to this.

Thanks that looks like the problem, multiple calls to save before one
call to restore when you have a pci-x capability would easily trigger
this problem.  I just surveyed a bunch of the pci_save_state and
pci_restore_state users and this appears to be a common idiom not just
a tg3 thing....

It looks like when code was added to save/restore the msi capability
was added to pci_save/restore_state that an assumption was added that
pci_save_state and pci_restore state were only used for suspend and
only used in pairs.  There is even a partial bug fix that removed the
worst of the symptoms of that assumption from the msi code but failed
to recognize the core problem.

Now that we have code to work with pcie and pcix capabilities as well
as msi this problem is much easier to hit.

All of pci_save_state and pci_restore_state is going to have to be
restructured to fix this, and it is late in the game.  Ugh.
Oh well, better to fix it now 

At least I get my answer about if what pci_save_state is doing
is reasonable. It is not.  pci_save_state no longer supports being
used in conjunction with hardware reset and has become a
suspend/resume specific function.

Now I'm off to wite some patches to fix this.

Eric

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

Jeff Garzik <jeff@garzik.org> writes:

> Eric W. Biederman wrote:
>> Until I get the best scenario I can come up with is a tg3 hardware bug
>> that doesn't renable the pci-X capability after a restore of power state.
>
>
> Speaking of tg3, make sure you are aware that the number of calls to save-state
> functions may not match the number of calls to the restore-state functions.
> ISTR seeing some memleak bugs in PCI related to this.

Thanks that looks like the problem, multiple calls to save before one
call to restore when you have a pci-x capability would easily trigger
this problem.  I just surveyed a bunch of the pci_save_state and
pci_restore_state users and this appears to be a common idiom not just
a tg3 thing....

It looks like when code was added to save/restore the msi capability
was added to pci_save/restore_state that an assumption was added that
pci_save_state and pci_restore state were only used for suspend and
only used in pairs.  There is even a partial bug fix that removed the
worst of the symptoms of that assumption from the msi code but failed
to recognize the core problem.

Now that we have code to work with pcie and pcix capabilities as well
as msi this problem is much easier to hit.

All of pci_save_state and pci_restore_state is going to have to be
restructured to fix this, and it is late in the game.  Ugh.
Oh well, better to fix it now 

At least I get my answer about if what pci_save_state is doing
is reasonable. It is not.  pci_save_state no longer supports being
used in conjunction with hardware reset and has become a
suspend/resume specific function.

Now I'm off to wite some patches to fix this.

Eric

[PATCH 0/2] Repair pci_restore_state when used with device resets

[Eric W. Biederman]

Well this is clearly a weird tangent from the topic of this thread but
it looks to have found some real bugs even if they aren't the ones we
are looking for.

In short pci_save_state and pci_restore_state are used to two primary
was:  As a pair called from the suspend and restore routines.  One save
to multiple restores usually present in hardware reset routines.

The additions to save/restore msi, pci-e and pci-x state failed to take
this second usage scenario into account.

The next two patches address this problem.

This should directly fix the issue observed with the tg3, with multiple
saves and a single restore.

It happens that to handle the reset case cleanly we also need to support
the odd usage model of the current e1000 driver.  

I have never have figured out how to get suspend/resume actually
working on any of my machines so the code path is untested.   But the
patches are trivial and pretty much obviously correct.

So if a couple people could do a quick suspend/resume test on these
patches to confirm I'm not blind that would be great.

Eric

[PATCH 0/2] Repair pci_restore_state when used with device resets

[Eric W. Biederman]

Well this is clearly a weird tangent from the topic of this thread but
it looks to have found some real bugs even if they aren't the ones we
are looking for.

In short pci_save_state and pci_restore_state are used to two primary
was:  As a pair called from the suspend and restore routines.  One save
to multiple restores usually present in hardware reset routines.

The additions to save/restore msi, pci-e and pci-x state failed to take
this second usage scenario into account.

The next two patches address this problem.

This should directly fix the issue observed with the tg3, with multiple
saves and a single restore.

It happens that to handle the reset case cleanly we also need to support
the odd usage model of the current e1000 driver.  

I have never have figured out how to get suspend/resume actually
working on any of my machines so the code path is untested.   But the
patches are trivial and pretty much obviously correct.

So if a couple people could do a quick suspend/resume test on these
patches to confirm I'm not blind that would be great.

Eric

[PATCH 1/2] msi: Safer state caching.

[Eric W. Biederman]

There are two ways pci_save_state and pci_restore_state are used.  As
helper functions during suspend/resume, and as helper functions around
a hardware reset event.  When used as helper functions around a hardware
reset event there is no reason to believe the calls will be paired, nor
is there a good reason to believe that if we restore the msi state from
before the reset that it will match the current msi state.  Since arch
code may change the msi message without going through the driver, drivers
currently do not have enough information to even know when to call
pci_save_state to ensure they will have msi state in sync with the other
kernel irq reception data structures.

It turns out the solution is straight forward, cache the state in the
existing msi data structures (not the magic pci saved things) and
have the msi code update the cached state each time we write to the hardware.
This means we never need to read the hardware to figure out what the hardware
state should be.

By modifying the caching in this manner we get to remove our save_state
routines and only need to provide restore_state routines.

The only fields that were at all tricky to regenerate were the msi and msi-x
control registers and the way we regenerate them currently is a bit dependent
upon assumptions on how we use the allow msi registers to be configured and used
making the code a little bit brittle.  If we ever change what cases we allow
or how we configure the msi bits we can address the fragility then.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 drivers/pci/msi.c        |  150 ++++++++--------------------------------------
 drivers/pci/pci.c        |    2 -
 drivers/pci/pci.h        |    2 -
 include/linux/msi.h      |    8 +--
 include/linux/pci_regs.h |    1 +
 5 files changed, 29 insertions(+), 134 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 01869b1..ad33e01 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -100,6 +100,7 @@ static void msi_set_mask_bit(unsigned int irq, int flag)
 		BUG();
 		break;
 	}
+	entry->msi_attrib.masked = !!flag;
 }
 
 void read_msi_msg(unsigned int irq, struct msi_msg *msg)
@@ -179,6 +180,7 @@ void write_msi_msg(unsigned int irq, struct msi_msg *msg)
 	default:
 		BUG();
 	}
+	entry->msg = *msg;
 }
 
 void mask_msi_irq(unsigned int irq)
@@ -225,164 +227,60 @@ static struct msi_desc* alloc_msi_entry(void)
 }
 
 #ifdef CONFIG_PM
-static int __pci_save_msi_state(struct pci_dev *dev)
-{
-	int pos, i = 0;
-	u16 control;
-	struct pci_cap_saved_state *save_state;
-	u32 *cap;
-
-	if (!dev->msi_enabled)
-		return 0;
-
-	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
-	if (pos <= 0)
-		return 0;
-
-	save_state = kzalloc(sizeof(struct pci_cap_saved_state) + sizeof(u32) * 5,
-		GFP_KERNEL);
-	if (!save_state) {
-		printk(KERN_ERR "Out of memory in pci_save_msi_state\n");
-		return -ENOMEM;
-	}
-	cap = &save_state->data[0];
-
-	pci_read_config_dword(dev, pos, &cap[i++]);
-	control = cap[0] >> 16;
-	pci_read_config_dword(dev, pos + PCI_MSI_ADDRESS_LO, &cap[i++]);
-	if (control & PCI_MSI_FLAGS_64BIT) {
-		pci_read_config_dword(dev, pos + PCI_MSI_ADDRESS_HI, &cap[i++]);
-		pci_read_config_dword(dev, pos + PCI_MSI_DATA_64, &cap[i++]);
-	} else
-		pci_read_config_dword(dev, pos + PCI_MSI_DATA_32, &cap[i++]);
-	if (control & PCI_MSI_FLAGS_MASKBIT)
-		pci_read_config_dword(dev, pos + PCI_MSI_MASK_BIT, &cap[i++]);
-	save_state->cap_nr = PCI_CAP_ID_MSI;
-	pci_add_saved_cap(dev, save_state);
-	return 0;
-}
-
 static void __pci_restore_msi_state(struct pci_dev *dev)
 {
-	int i = 0, pos;
+	int pos;
 	u16 control;
-	struct pci_cap_saved_state *save_state;
-	u32 *cap;
+	struct msi_desc *entry;
 
 	if (!dev->msi_enabled)
 		return;
 
-	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_MSI);
-	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
-	if (!save_state || pos <= 0)
-		return;
-	cap = &save_state->data[0];
+	entry = get_irq_msi(dev->irq);
+	pos = entry->msi_attrib.pos;
 
 	pci_intx(dev, 0);		/* disable intx */
-	control = cap[i++] >> 16;
 	msi_set_enable(dev, 0);
-	pci_write_config_dword(dev, pos + PCI_MSI_ADDRESS_LO, cap[i++]);
-	if (control & PCI_MSI_FLAGS_64BIT) {
-		pci_write_config_dword(dev, pos + PCI_MSI_ADDRESS_HI, cap[i++]);
-		pci_write_config_dword(dev, pos + PCI_MSI_DATA_64, cap[i++]);
-	} else
-		pci_write_config_dword(dev, pos + PCI_MSI_DATA_32, cap[i++]);
-	if (control & PCI_MSI_FLAGS_MASKBIT)
-		pci_write_config_dword(dev, pos + PCI_MSI_MASK_BIT, cap[i++]);
+	write_msi_msg(dev->irq, &entry->msg);
+	if (entry->msi_attrib.maskbit)
+		msi_set_mask_bit(dev->irq, entry->msi_attrib.masked);
+
+	pci_read_config_word(dev, pos + PCI_MSI_FLAGS, &control);
+	control &= ~(PCI_MSI_FLAGS_QSIZE | PCI_MSI_FLAGS_ENABLE);
+	if (entry->msi_attrib.maskbit || !entry->msi_attrib.masked)
+		control |= PCI_MSI_FLAGS_ENABLE;
 	pci_write_config_word(dev, pos + PCI_MSI_FLAGS, control);
-	pci_remove_saved_cap(save_state);
-	kfree(save_state);
-}
-
-static int __pci_save_msix_state(struct pci_dev *dev)
-{
-	int pos;
-	int irq, head, tail = 0;
-	u16 control;
-	struct pci_cap_saved_state *save_state;
-
-	if (!dev->msix_enabled)
-		return 0;
-
-	pos = pci_find_capability(dev, PCI_CAP_ID_MSIX);
-	if (pos <= 0)
-		return 0;
-
-	/* save the capability */
-	pci_read_config_word(dev, msi_control_reg(pos), &control);
-	save_state = kzalloc(sizeof(struct pci_cap_saved_state) + sizeof(u16),
-		GFP_KERNEL);
-	if (!save_state) {
-		printk(KERN_ERR "Out of memory in pci_save_msix_state\n");
-		return -ENOMEM;
-	}
-	*((u16 *)&save_state->data[0]) = control;
-
-	/* save the table */
-	irq = head = dev->first_msi_irq;
-	while (head != tail) {
-		struct msi_desc *entry;
-
-		entry = get_irq_msi(irq);
-		read_msi_msg(irq, &entry->msg_save);
-
-		tail = entry->link.tail;
-		irq = tail;
-	}
-
-	save_state->cap_nr = PCI_CAP_ID_MSIX;
-	pci_add_saved_cap(dev, save_state);
-	return 0;
-}
-
-int pci_save_msi_state(struct pci_dev *dev)
-{
-	int rc;
-
-	rc = __pci_save_msi_state(dev);
-	if (rc)
-		return rc;
-
-	rc = __pci_save_msix_state(dev);
-
-	return rc;
 }
 
 static void __pci_restore_msix_state(struct pci_dev *dev)
 {
-	u16 save;
 	int pos;
 	int irq, head, tail = 0;
 	struct msi_desc *entry;
-	struct pci_cap_saved_state *save_state;
+	u16 control;
 
 	if (!dev->msix_enabled)
 		return;
 
-	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_MSIX);
-	if (!save_state)
-		return;
-	save = *((u16 *)&save_state->data[0]);
-	pci_remove_saved_cap(save_state);
-	kfree(save_state);
-
-	pos = pci_find_capability(dev, PCI_CAP_ID_MSIX);
-	if (pos <= 0)
-		return;
-
 	/* route the table */
 	pci_intx(dev, 0);		/* disable intx */
 	msix_set_enable(dev, 0);
 	irq = head = dev->first_msi_irq;
+	entry = get_irq_msi(irq);
+	pos = entry->msi_attrib.pos;
 	while (head != tail) {
 		entry = get_irq_msi(irq);
-		write_msi_msg(irq, &entry->msg_save);
+		write_msi_msg(irq, &entry->msg);
+		msi_set_mask_bit(irq, entry->msi_attrib.masked);
 
 		tail = entry->link.tail;
 		irq = tail;
 	}
 
-	pci_write_config_word(dev, msi_control_reg(pos), save);
+	pci_read_config_word(dev, pos + PCI_MSIX_FLAGS, &control);
+	control &= ~PCI_MSIX_FLAGS_MASKALL;
+	control |= PCI_MSIX_FLAGS_ENABLE;
+	pci_write_config_word(dev, pos + PCI_MSIX_FLAGS, control);
 }
 
 void pci_restore_msi_state(struct pci_dev *dev)
@@ -420,6 +318,7 @@ static int msi_capability_init(struct pci_dev *dev)
 	entry->msi_attrib.is_64 = is_64bit_address(control);
 	entry->msi_attrib.entry_nr = 0;
 	entry->msi_attrib.maskbit = is_mask_bit_support(control);
+	entry->msi_attrib.masked = 1;
 	entry->msi_attrib.default_irq = dev->irq;	/* Save IOAPIC IRQ */
 	entry->msi_attrib.pos = pos;
 	if (is_mask_bit_support(control)) {
@@ -507,6 +406,7 @@ static int msix_capability_init(struct pci_dev *dev,
 		entry->msi_attrib.is_64 = 1;
 		entry->msi_attrib.entry_nr = j;
 		entry->msi_attrib.maskbit = 1;
+		entry->msi_attrib.masked = 1;
 		entry->msi_attrib.default_irq = dev->irq;
 		entry->msi_attrib.pos = pos;
 		entry->dev = dev;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index df49530..6fb78df 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -638,8 +638,6 @@ pci_save_state(struct pci_dev *dev)
 	/* XXX: 100% dword access ok here? */
 	for (i = 0; i < 16; i++)
 		pci_read_config_dword(dev, i * 4,&dev->saved_config_space[i]);
-	if ((i = pci_save_msi_state(dev)) != 0)
-		return i;
 	if ((i = pci_save_pcie_state(dev)) != 0)
 		return i;
 	if ((i = pci_save_pcix_state(dev)) != 0)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index ae7a975..62ea04c 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -52,10 +52,8 @@ static inline void pci_no_msi(void) { }
 #endif
 
 #if defined(CONFIG_PCI_MSI) && defined(CONFIG_PM)
-int pci_save_msi_state(struct pci_dev *dev);
 void pci_restore_msi_state(struct pci_dev *dev);
 #else
-static inline int pci_save_msi_state(struct pci_dev *dev) { return 0; }
 static inline void pci_restore_msi_state(struct pci_dev *dev) {}
 #endif
 
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 74c8a2e..e38fe68 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -17,7 +17,7 @@ struct msi_desc {
 	struct {
 		__u8	type	: 5; 	/* {0: unused, 5h:MSI, 11h:MSI-X} */
 		__u8	maskbit	: 1; 	/* mask-pending bit supported ?   */
-		__u8	unused	: 1;
+		__u8	masked	: 1;
 		__u8	is_64	: 1;	/* Address size: 0=32bit 1=64bit  */
 		__u8	pos;	 	/* Location of the msi capability */
 		__u16	entry_nr;    	/* specific enabled entry 	  */
@@ -32,10 +32,8 @@ struct msi_desc {
 	void __iomem *mask_base;
 	struct pci_dev *dev;
 
-#ifdef CONFIG_PM
-	/* PM save area for MSIX address/data */
-	struct msi_msg msg_save;
-#endif
+	/* Last set MSI message */
+	struct msi_msg msg;
 };
 
 /*
diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
index f09cce2..495d368 100644
--- a/include/linux/pci_regs.h
+++ b/include/linux/pci_regs.h
@@ -296,6 +296,7 @@
 #define PCI_MSIX_FLAGS		2
 #define  PCI_MSIX_FLAGS_QSIZE	0x7FF
 #define  PCI_MSIX_FLAGS_ENABLE	(1 << 15)
+#define  PCI_MSIX_FLAGS_MASKALL	(1 << 14)
 #define PCI_MSIX_FLAGS_BIRMASK	(7 << 0)
 #define PCI_MSIX_FLAGS_BITMASK	(1 << 0)
 
-- 
1.5.0.g53756

[PATCH 1/2] msi: Safer state caching.

[Eric W. Biederman]

There are two ways pci_save_state and pci_restore_state are used.  As
helper functions during suspend/resume, and as helper functions around
a hardware reset event.  When used as helper functions around a hardware
reset event there is no reason to believe the calls will be paired, nor
is there a good reason to believe that if we restore the msi state from
before the reset that it will match the current msi state.  Since arch
code may change the msi message without going through the driver, drivers
currently do not have enough information to even know when to call
pci_save_state to ensure they will have msi state in sync with the other
kernel irq reception data structures.

It turns out the solution is straight forward, cache the state in the
existing msi data structures (not the magic pci saved things) and
have the msi code update the cached state each time we write to the hardware.
This means we never need to read the hardware to figure out what the hardware
state should be.

By modifying the caching in this manner we get to remove our save_state
routines and only need to provide restore_state routines.

The only fields that were at all tricky to regenerate were the msi and msi-x
control registers and the way we regenerate them currently is a bit dependent
upon assumptions on how we use the allow msi registers to be configured and used
making the code a little bit brittle.  If we ever change what cases we allow
or how we configure the msi bits we can address the fragility then.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 drivers/pci/msi.c        |  150 ++++++++--------------------------------------
 drivers/pci/pci.c        |    2 -
 drivers/pci/pci.h        |    2 -
 include/linux/msi.h      |    8 +--
 include/linux/pci_regs.h |    1 +
 5 files changed, 29 insertions(+), 134 deletions(-)

diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 01869b1..ad33e01 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -100,6 +100,7 @@ static void msi_set_mask_bit(unsigned int irq, int flag)
 		BUG();
 		break;
 	}
+	entry->msi_attrib.masked = !!flag;
 }
 
 void read_msi_msg(unsigned int irq, struct msi_msg *msg)
@@ -179,6 +180,7 @@ void write_msi_msg(unsigned int irq, struct msi_msg *msg)
 	default:
 		BUG();
 	}
+	entry->msg = *msg;
 }
 
 void mask_msi_irq(unsigned int irq)
@@ -225,164 +227,60 @@ static struct msi_desc* alloc_msi_entry(void)
 }
 
 #ifdef CONFIG_PM
-static int __pci_save_msi_state(struct pci_dev *dev)
-{
-	int pos, i = 0;
-	u16 control;
-	struct pci_cap_saved_state *save_state;
-	u32 *cap;
-
-	if (!dev->msi_enabled)
-		return 0;
-
-	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
-	if (pos <= 0)
-		return 0;
-
-	save_state = kzalloc(sizeof(struct pci_cap_saved_state) + sizeof(u32) * 5,
-		GFP_KERNEL);
-	if (!save_state) {
-		printk(KERN_ERR "Out of memory in pci_save_msi_state\n");
-		return -ENOMEM;
-	}
-	cap = &save_state->data[0];
-
-	pci_read_config_dword(dev, pos, &cap[i++]);
-	control = cap[0] >> 16;
-	pci_read_config_dword(dev, pos + PCI_MSI_ADDRESS_LO, &cap[i++]);
-	if (control & PCI_MSI_FLAGS_64BIT) {
-		pci_read_config_dword(dev, pos + PCI_MSI_ADDRESS_HI, &cap[i++]);
-		pci_read_config_dword(dev, pos + PCI_MSI_DATA_64, &cap[i++]);
-	} else
-		pci_read_config_dword(dev, pos + PCI_MSI_DATA_32, &cap[i++]);
-	if (control & PCI_MSI_FLAGS_MASKBIT)
-		pci_read_config_dword(dev, pos + PCI_MSI_MASK_BIT, &cap[i++]);
-	save_state->cap_nr = PCI_CAP_ID_MSI;
-	pci_add_saved_cap(dev, save_state);
-	return 0;
-}
-
 static void __pci_restore_msi_state(struct pci_dev *dev)
 {
-	int i = 0, pos;
+	int pos;
 	u16 control;
-	struct pci_cap_saved_state *save_state;
-	u32 *cap;
+	struct msi_desc *entry;
 
 	if (!dev->msi_enabled)
 		return;
 
-	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_MSI);
-	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
-	if (!save_state || pos <= 0)
-		return;
-	cap = &save_state->data[0];
+	entry = get_irq_msi(dev->irq);
+	pos = entry->msi_attrib.pos;
 
 	pci_intx(dev, 0);		/* disable intx */
-	control = cap[i++] >> 16;
 	msi_set_enable(dev, 0);
-	pci_write_config_dword(dev, pos + PCI_MSI_ADDRESS_LO, cap[i++]);
-	if (control & PCI_MSI_FLAGS_64BIT) {
-		pci_write_config_dword(dev, pos + PCI_MSI_ADDRESS_HI, cap[i++]);
-		pci_write_config_dword(dev, pos + PCI_MSI_DATA_64, cap[i++]);
-	} else
-		pci_write_config_dword(dev, pos + PCI_MSI_DATA_32, cap[i++]);
-	if (control & PCI_MSI_FLAGS_MASKBIT)
-		pci_write_config_dword(dev, pos + PCI_MSI_MASK_BIT, cap[i++]);
+	write_msi_msg(dev->irq, &entry->msg);
+	if (entry->msi_attrib.maskbit)
+		msi_set_mask_bit(dev->irq, entry->msi_attrib.masked);
+
+	pci_read_config_word(dev, pos + PCI_MSI_FLAGS, &control);
+	control &= ~(PCI_MSI_FLAGS_QSIZE | PCI_MSI_FLAGS_ENABLE);
+	if (entry->msi_attrib.maskbit || !entry->msi_attrib.masked)
+		control |= PCI_MSI_FLAGS_ENABLE;
 	pci_write_config_word(dev, pos + PCI_MSI_FLAGS, control);
-	pci_remove_saved_cap(save_state);
-	kfree(save_state);
-}
-
-static int __pci_save_msix_state(struct pci_dev *dev)
-{
-	int pos;
-	int irq, head, tail = 0;
-	u16 control;
-	struct pci_cap_saved_state *save_state;
-
-	if (!dev->msix_enabled)
-		return 0;
-
-	pos = pci_find_capability(dev, PCI_CAP_ID_MSIX);
-	if (pos <= 0)
-		return 0;
-
-	/* save the capability */
-	pci_read_config_word(dev, msi_control_reg(pos), &control);
-	save_state = kzalloc(sizeof(struct pci_cap_saved_state) + sizeof(u16),
-		GFP_KERNEL);
-	if (!save_state) {
-		printk(KERN_ERR "Out of memory in pci_save_msix_state\n");
-		return -ENOMEM;
-	}
-	*((u16 *)&save_state->data[0]) = control;
-
-	/* save the table */
-	irq = head = dev->first_msi_irq;
-	while (head != tail) {
-		struct msi_desc *entry;
-
-		entry = get_irq_msi(irq);
-		read_msi_msg(irq, &entry->msg_save);
-
-		tail = entry->link.tail;
-		irq = tail;
-	}
-
-	save_state->cap_nr = PCI_CAP_ID_MSIX;
-	pci_add_saved_cap(dev, save_state);
-	return 0;
-}
-
-int pci_save_msi_state(struct pci_dev *dev)
-{
-	int rc;
-
-	rc = __pci_save_msi_state(dev);
-	if (rc)
-		return rc;
-
-	rc = __pci_save_msix_state(dev);
-
-	return rc;
 }
 
 static void __pci_restore_msix_state(struct pci_dev *dev)
 {
-	u16 save;
 	int pos;
 	int irq, head, tail = 0;
 	struct msi_desc *entry;
-	struct pci_cap_saved_state *save_state;
+	u16 control;
 
 	if (!dev->msix_enabled)
 		return;
 
-	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_MSIX);
-	if (!save_state)
-		return;
-	save = *((u16 *)&save_state->data[0]);
-	pci_remove_saved_cap(save_state);
-	kfree(save_state);
-
-	pos = pci_find_capability(dev, PCI_CAP_ID_MSIX);
-	if (pos <= 0)
-		return;
-
 	/* route the table */
 	pci_intx(dev, 0);		/* disable intx */
 	msix_set_enable(dev, 0);
 	irq = head = dev->first_msi_irq;
+	entry = get_irq_msi(irq);
+	pos = entry->msi_attrib.pos;
 	while (head != tail) {
 		entry = get_irq_msi(irq);
-		write_msi_msg(irq, &entry->msg_save);
+		write_msi_msg(irq, &entry->msg);
+		msi_set_mask_bit(irq, entry->msi_attrib.masked);
 
 		tail = entry->link.tail;
 		irq = tail;
 	}
 
-	pci_write_config_word(dev, msi_control_reg(pos), save);
+	pci_read_config_word(dev, pos + PCI_MSIX_FLAGS, &control);
+	control &= ~PCI_MSIX_FLAGS_MASKALL;
+	control |= PCI_MSIX_FLAGS_ENABLE;
+	pci_write_config_word(dev, pos + PCI_MSIX_FLAGS, control);
 }
 
 void pci_restore_msi_state(struct pci_dev *dev)
@@ -420,6 +318,7 @@ static int msi_capability_init(struct pci_dev *dev)
 	entry->msi_attrib.is_64 = is_64bit_address(control);
 	entry->msi_attrib.entry_nr = 0;
 	entry->msi_attrib.maskbit = is_mask_bit_support(control);
+	entry->msi_attrib.masked = 1;
 	entry->msi_attrib.default_irq = dev->irq;	/* Save IOAPIC IRQ */
 	entry->msi_attrib.pos = pos;
 	if (is_mask_bit_support(control)) {
@@ -507,6 +406,7 @@ static int msix_capability_init(struct pci_dev *dev,
 		entry->msi_attrib.is_64 = 1;
 		entry->msi_attrib.entry_nr = j;
 		entry->msi_attrib.maskbit = 1;
+		entry->msi_attrib.masked = 1;
 		entry->msi_attrib.default_irq = dev->irq;
 		entry->msi_attrib.pos = pos;
 		entry->dev = dev;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index df49530..6fb78df 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -638,8 +638,6 @@ pci_save_state(struct pci_dev *dev)
 	/* XXX: 100% dword access ok here? */
 	for (i = 0; i < 16; i++)
 		pci_read_config_dword(dev, i * 4,&dev->saved_config_space[i]);
-	if ((i = pci_save_msi_state(dev)) != 0)
-		return i;
 	if ((i = pci_save_pcie_state(dev)) != 0)
 		return i;
 	if ((i = pci_save_pcix_state(dev)) != 0)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index ae7a975..62ea04c 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -52,10 +52,8 @@ static inline void pci_no_msi(void) { }
 #endif
 
 #if defined(CONFIG_PCI_MSI) && defined(CONFIG_PM)
-int pci_save_msi_state(struct pci_dev *dev);
 void pci_restore_msi_state(struct pci_dev *dev);
 #else
-static inline int pci_save_msi_state(struct pci_dev *dev) { return 0; }
 static inline void pci_restore_msi_state(struct pci_dev *dev) {}
 #endif
 
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 74c8a2e..e38fe68 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -17,7 +17,7 @@ struct msi_desc {
 	struct {
 		__u8	type	: 5; 	/* {0: unused, 5h:MSI, 11h:MSI-X} */
 		__u8	maskbit	: 1; 	/* mask-pending bit supported ?   */
-		__u8	unused	: 1;
+		__u8	masked	: 1;
 		__u8	is_64	: 1;	/* Address size: 0=32bit 1=64bit  */
 		__u8	pos;	 	/* Location of the msi capability */
 		__u16	entry_nr;    	/* specific enabled entry 	  */
@@ -32,10 +32,8 @@ struct msi_desc {
 	void __iomem *mask_base;
 	struct pci_dev *dev;
 
-#ifdef CONFIG_PM
-	/* PM save area for MSIX address/data */
-	struct msi_msg msg_save;
-#endif
+	/* Last set MSI message */
+	struct msi_msg msg;
 };
 
 /*
diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
index f09cce2..495d368 100644
--- a/include/linux/pci_regs.h
+++ b/include/linux/pci_regs.h
@@ -296,6 +296,7 @@
 #define PCI_MSIX_FLAGS		2
 #define  PCI_MSIX_FLAGS_QSIZE	0x7FF
 #define  PCI_MSIX_FLAGS_ENABLE	(1 << 15)
+#define  PCI_MSIX_FLAGS_MASKALL	(1 << 14)
 #define PCI_MSIX_FLAGS_BIRMASK	(7 << 0)
 #define PCI_MSIX_FLAGS_BITMASK	(1 << 0)
 
-- 
1.5.0.g53756

[PATCH 2/2] pci: Repair pci_save/restore_state so we can restore one save many times.

[Eric W. Biederman]

Because we do not reserve space for the pci-x and pci-e state in struct
pci dev we need to dynamically allocate it.  However because we need
to support restore being called multiple times after a single save
it is never safe to free the buffers we have allocated to hold the
state.

So this patch modifies the save routines to first check to see
if we have already allocated a state buffer before allocating
a new one.  Then the restore routines are modified to not free
the state after restoring it.  Simple and it fixes some subtle
error path handling bugs, that are hard to test for.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 drivers/pci/pci.c   |   12 ++++++------
 include/linux/pci.h |    5 -----
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 6fb78df..b292c9a 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -551,7 +551,9 @@ static int pci_save_pcie_state(struct pci_dev *dev)
 	if (pos <= 0)
 		return 0;
 
-	save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4, GFP_KERNEL);
+	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
+	if (!save_state)
+		save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4, GFP_KERNEL);
 	if (!save_state) {
 		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
 		return -ENOMEM;
@@ -582,8 +584,6 @@ static void pci_restore_pcie_state(struct pci_dev *dev)
 	pci_write_config_word(dev, pos + PCI_EXP_LNKCTL, cap[i++]);
 	pci_write_config_word(dev, pos + PCI_EXP_SLTCTL, cap[i++]);
 	pci_write_config_word(dev, pos + PCI_EXP_RTCTL, cap[i++]);
-	pci_remove_saved_cap(save_state);
-	kfree(save_state);
 }
 
 
@@ -597,7 +597,9 @@ static int pci_save_pcix_state(struct pci_dev *dev)
 	if (pos <= 0)
 		return 0;
 
-	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
+	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
+	if (!save_state)
+		save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
 	if (!save_state) {
 		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
 		return -ENOMEM;
@@ -622,8 +624,6 @@ static void pci_restore_pcix_state(struct pci_dev *dev)
 	cap = (u16 *)&save_state->data[0];
 
 	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
-	pci_remove_saved_cap(save_state);
-	kfree(save_state);
 }
 
 
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 78417e4..481ea06 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -209,11 +209,6 @@ static inline void pci_add_saved_cap(struct pci_dev *pci_dev,
 	hlist_add_head(&new_cap->next, &pci_dev->saved_cap_space);
 }
 
-static inline void pci_remove_saved_cap(struct pci_cap_saved_state *cap)
-{
-	hlist_del(&cap->next);
-}
-
 /*
  *  For PCI devices, the region numbers are assigned this way:
  *
-- 
1.5.0.g53756

[PATCH 2/2] pci: Repair pci_save/restore_state so we can restore one save many times.

[Eric W. Biederman]

Because we do not reserve space for the pci-x and pci-e state in struct
pci dev we need to dynamically allocate it.  However because we need
to support restore being called multiple times after a single save
it is never safe to free the buffers we have allocated to hold the
state.

So this patch modifies the save routines to first check to see
if we have already allocated a state buffer before allocating
a new one.  Then the restore routines are modified to not free
the state after restoring it.  Simple and it fixes some subtle
error path handling bugs, that are hard to test for.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
 drivers/pci/pci.c   |   12 ++++++------
 include/linux/pci.h |    5 -----
 2 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 6fb78df..b292c9a 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -551,7 +551,9 @@ static int pci_save_pcie_state(struct pci_dev *dev)
 	if (pos <= 0)
 		return 0;
 
-	save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4, GFP_KERNEL);
+	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
+	if (!save_state)
+		save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4, GFP_KERNEL);
 	if (!save_state) {
 		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
 		return -ENOMEM;
@@ -582,8 +584,6 @@ static void pci_restore_pcie_state(struct pci_dev *dev)
 	pci_write_config_word(dev, pos + PCI_EXP_LNKCTL, cap[i++]);
 	pci_write_config_word(dev, pos + PCI_EXP_SLTCTL, cap[i++]);
 	pci_write_config_word(dev, pos + PCI_EXP_RTCTL, cap[i++]);
-	pci_remove_saved_cap(save_state);
-	kfree(save_state);
 }
 
 
@@ -597,7 +597,9 @@ static int pci_save_pcix_state(struct pci_dev *dev)
 	if (pos <= 0)
 		return 0;
 
-	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
+	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
+	if (!save_state)
+		save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
 	if (!save_state) {
 		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
 		return -ENOMEM;
@@ -622,8 +624,6 @@ static void pci_restore_pcix_state(struct pci_dev *dev)
 	cap = (u16 *)&save_state->data[0];
 
 	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
-	pci_remove_saved_cap(save_state);
-	kfree(save_state);
 }
 
 
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 78417e4..481ea06 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -209,11 +209,6 @@ static inline void pci_add_saved_cap(struct pci_dev *pci_dev,
 	hlist_add_head(&new_cap->next, &pci_dev->saved_cap_space);
 }
 
-static inline void pci_remove_saved_cap(struct pci_cap_saved_state *cap)
-{
-	hlist_del(&cap->next);
-}
-
 /*
  *  For PCI devices, the region numbers are assigned this way:
  *
-- 
1.5.0.g53756

patch pci-repair-pci_save-restore_state-so-we-can-restore-one-save-many-times.patch added to gregkh-2.6 tree

[gregkh]

This is a note to let you know that I've just added the patch titled

     Subject: pci: Repair pci_save/restore_state so we can restore one save many times.

to my gregkh-2.6 tree.  Its filename is

     pci-repair-pci_save-restore_state-so-we-can-restore-one-save-many-times.patch

This tree can be found at 
    http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/


>From owner-linux-pci@atrey.karlin.mff.cuni.cz Thu Mar  8 12:06:39 2007
From: Eric W. Biederman <ebiederm@xmission.com>
Date: Thu, 08 Mar 2007 13:06:13 -0700
Subject: pci: Repair pci_save/restore_state so we can restore one save many times.
To: Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jeff Garzik <jeff@garzik.org>, "Kok, Auke" <auke-jan.h.kok@intel.com>, Ingo Molnar <mingo@elte.hu>, "Michael S. Tsirkin" <mst@mellanox.co.il>, Pavel Machek <pavel@ucw.cz>, Jens Axboe <jens.axboe@oracle.com>, Adrian Bunk <bunk@stusta.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, linux-pm@lists.osdl.org, Michal Piotrowski <michal.k.k.piotrowski@gmail.com>, Greg Kroah-Hartman <gregkh@suse.de>, <linux-pci@atrey.karlin.mff.cuni.cz>, michael@ellerman.id.au
Message-ID: <m1lki75wlm.fsf_-_@ebiederm.dsl.xmission.com>


From: Eric W. Biederman <ebiederm@xmission.com>

Because we do not reserve space for the pci-x and pci-e state in struct
pci dev we need to dynamically allocate it.  However because we need
to support restore being called multiple times after a single save
it is never safe to free the buffers we have allocated to hold the
state.

So this patch modifies the save routines to first check to see
if we have already allocated a state buffer before allocating
a new one.  Then the restore routines are modified to not free
the state after restoring it.  Simple and it fixes some subtle
error path handling bugs, that are hard to test for.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/pci/pci.c   |   12 ++++++------
 include/linux/pci.h |    5 -----
 2 files changed, 6 insertions(+), 11 deletions(-)

--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -551,7 +551,9 @@ static int pci_save_pcie_state(struct pc
 	if (pos <= 0)
 		return 0;
 
-	save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4, GFP_KERNEL);
+	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
+	if (!save_state)
+		save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4, GFP_KERNEL);
 	if (!save_state) {
 		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
 		return -ENOMEM;
@@ -582,8 +584,6 @@ static void pci_restore_pcie_state(struc
 	pci_write_config_word(dev, pos + PCI_EXP_LNKCTL, cap[i++]);
 	pci_write_config_word(dev, pos + PCI_EXP_SLTCTL, cap[i++]);
 	pci_write_config_word(dev, pos + PCI_EXP_RTCTL, cap[i++]);
-	pci_remove_saved_cap(save_state);
-	kfree(save_state);
 }
 
 
@@ -597,7 +597,9 @@ static int pci_save_pcix_state(struct pc
 	if (pos <= 0)
 		return 0;
 
-	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
+	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
+	if (!save_state)
+		save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
 	if (!save_state) {
 		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
 		return -ENOMEM;
@@ -622,8 +624,6 @@ static void pci_restore_pcix_state(struc
 	cap = (u16 *)&save_state->data[0];
 
 	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
-	pci_remove_saved_cap(save_state);
-	kfree(save_state);
 }
 
 
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -222,11 +222,6 @@ static inline void pci_add_saved_cap(str
 	hlist_add_head(&new_cap->next, &pci_dev->saved_cap_space);
 }
 
-static inline void pci_remove_saved_cap(struct pci_cap_saved_state *cap)
-{
-	hlist_del(&cap->next);
-}
-
 /*
  *  For PCI devices, the region numbers are assigned this way:
  *


Patches currently in gregkh-2.6 which might be from ebiederm@xmission.com are

Re: [PATCH 2/2] pci: Repair pci_save/restore_state so we can restore one save many times.

[Kok, Auke]

Eric W. Biederman wrote:
> Because we do not reserve space for the pci-x and pci-e state in struct
> pci dev we need to dynamically allocate it.  However because we need
> to support restore being called multiple times after a single save
> it is never safe to free the buffers we have allocated to hold the
> state.
> 
> So this patch modifies the save routines to first check to see
> if we have already allocated a state buffer before allocating
> a new one.  Then the restore routines are modified to not free
> the state after restoring it.  Simple and it fixes some subtle
> error path handling bugs, that are hard to test for.
> 
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>


I tested this patch and the other 2 in this series:

[PATCH 0/2] Repair pci_restore_state when used with device resets
[PATCH 1/2] msi: Safer state caching.

against e1000 with suspend/resume functionality. Apart from a minor symmetry 
violation in e1000 for which I will send a patch later, these patches appear to 
work fine on my ich8 with 5 msi capable e1000 ports.

Feel free to add my Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>

Cheers,

Auke



> ---
>  drivers/pci/pci.c   |   12 ++++++------
>  include/linux/pci.h |    5 -----
>  2 files changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 6fb78df..b292c9a 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -551,7 +551,9 @@ static int pci_save_pcie_state(struct pci_dev *dev)
>  	if (pos <= 0)
>  		return 0;
>  
> -	save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4, GFP_KERNEL);
> +	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
> +	if (!save_state)
> +		save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4, GFP_KERNEL);
>  	if (!save_state) {
>  		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
>  		return -ENOMEM;
> @@ -582,8 +584,6 @@ static void pci_restore_pcie_state(struct pci_dev *dev)
>  	pci_write_config_word(dev, pos + PCI_EXP_LNKCTL, cap[i++]);
>  	pci_write_config_word(dev, pos + PCI_EXP_SLTCTL, cap[i++]);
>  	pci_write_config_word(dev, pos + PCI_EXP_RTCTL, cap[i++]);
> -	pci_remove_saved_cap(save_state);
> -	kfree(save_state);
>  }
>  
>  
> @@ -597,7 +597,9 @@ static int pci_save_pcix_state(struct pci_dev *dev)
>  	if (pos <= 0)
>  		return 0;
>  
> -	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
> +	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
> +	if (!save_state)
> +		save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
>  	if (!save_state) {
>  		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
>  		return -ENOMEM;
> @@ -622,8 +624,6 @@ static void pci_restore_pcix_state(struct pci_dev *dev)
>  	cap = (u16 *)&save_state->data[0];
>  
>  	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
> -	pci_remove_saved_cap(save_state);
> -	kfree(save_state);
>  }
>  
>  
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 78417e4..481ea06 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -209,11 +209,6 @@ static inline void pci_add_saved_cap(struct pci_dev *pci_dev,
>  	hlist_add_head(&new_cap->next, &pci_dev->saved_cap_space);
>  }
>  
> -static inline void pci_remove_saved_cap(struct pci_cap_saved_state *cap)
> -{
> -	hlist_del(&cap->next);
> -}
> -
>  /*
>   *  For PCI devices, the region numbers are assigned this way:
>   *

Re: [PATCH 2/2] pci: Repair pci_save/restore_state so we can restore one save many times.

[Kok, Auke]

Eric W. Biederman wrote:
> Because we do not reserve space for the pci-x and pci-e state in struct
> pci dev we need to dynamically allocate it.  However because we need
> to support restore being called multiple times after a single save
> it is never safe to free the buffers we have allocated to hold the
> state.
> 
> So this patch modifies the save routines to first check to see
> if we have already allocated a state buffer before allocating
> a new one.  Then the restore routines are modified to not free
> the state after restoring it.  Simple and it fixes some subtle
> error path handling bugs, that are hard to test for.
> 
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>


I tested this patch and the other 2 in this series:

[PATCH 0/2] Repair pci_restore_state when used with device resets
[PATCH 1/2] msi: Safer state caching.

against e1000 with suspend/resume functionality. Apart from a minor symmetry 
violation in e1000 for which I will send a patch later, these patches appear to 
work fine on my ich8 with 5 msi capable e1000 ports.

Feel free to add my Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>

Cheers,

Auke



> ---
>  drivers/pci/pci.c   |   12 ++++++------
>  include/linux/pci.h |    5 -----
>  2 files changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 6fb78df..b292c9a 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -551,7 +551,9 @@ static int pci_save_pcie_state(struct pci_dev *dev)
>  	if (pos <= 0)
>  		return 0;
>  
> -	save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4, GFP_KERNEL);
> +	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
> +	if (!save_state)
> +		save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 4, GFP_KERNEL);
>  	if (!save_state) {
>  		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
>  		return -ENOMEM;
> @@ -582,8 +584,6 @@ static void pci_restore_pcie_state(struct pci_dev *dev)
>  	pci_write_config_word(dev, pos + PCI_EXP_LNKCTL, cap[i++]);
>  	pci_write_config_word(dev, pos + PCI_EXP_SLTCTL, cap[i++]);
>  	pci_write_config_word(dev, pos + PCI_EXP_RTCTL, cap[i++]);
> -	pci_remove_saved_cap(save_state);
> -	kfree(save_state);
>  }
>  
>  
> @@ -597,7 +597,9 @@ static int pci_save_pcix_state(struct pci_dev *dev)
>  	if (pos <= 0)
>  		return 0;
>  
> -	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
> +	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_EXP);
> +	if (!save_state)
> +		save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
>  	if (!save_state) {
>  		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
>  		return -ENOMEM;
> @@ -622,8 +624,6 @@ static void pci_restore_pcix_state(struct pci_dev *dev)
>  	cap = (u16 *)&save_state->data[0];
>  
>  	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
> -	pci_remove_saved_cap(save_state);
> -	kfree(save_state);
>  }
>  
>  
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 78417e4..481ea06 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -209,11 +209,6 @@ static inline void pci_add_saved_cap(struct pci_dev *pci_dev,
>  	hlist_add_head(&new_cap->next, &pci_dev->saved_cap_space);
>  }
>  
> -static inline void pci_remove_saved_cap(struct pci_cap_saved_state *cap)
> -{
> -	hlist_del(&cap->next);
> -}
> -
>  /*
>   *  For PCI devices, the region numbers are assigned this way:
>   *

patch msi-safer-state-caching.patch added to gregkh-2.6 tree

[gregkh]

This is a note to let you know that I've just added the patch titled

     Subject: msi: Safer state caching.

to my gregkh-2.6 tree.  Its filename is

     msi-safer-state-caching.patch

This tree can be found at 
    http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/


>From owner-linux-pci@atrey.karlin.mff.cuni.cz Thu Mar  8 12:05:21 2007
From: Eric W. Biederman <ebiederm@xmission.com>
Date: Thu, 08 Mar 2007 13:04:57 -0700
Subject: msi: Safer state caching.
To: Andrew Morton <akpm@linux-foundation.org>, Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jeff Garzik <jeff@garzik.org>, "Kok, Auke" <auke-jan.h.kok@intel.com>, Ingo Molnar <mingo@elte.hu>, "Michael S. Tsirkin" <mst@mellanox.co.il>, Pavel Machek <pavel@ucw.cz>, Jens Axboe <jens.axboe@oracle.com>, Adrian Bunk <bunk@stusta.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, linux-pm@lists.osdl.org, Michal Piotrowski <michal.k.k.piotrowski@gmail.com>, Greg Kroah-Hartman <gregkh@suse.de>, <linux-pci@atrey.karlin.mff.cuni.cz>, michael@ellerman.id.au
Message-ID: <m1ps7j5wnq.fsf_-_@ebiederm.dsl.xmission.com>

From: Eric W. Biederman <ebiederm@xmission.com>


There are two ways pci_save_state and pci_restore_state are used.  As
helper functions during suspend/resume, and as helper functions around
a hardware reset event.  When used as helper functions around a hardware
reset event there is no reason to believe the calls will be paired, nor
is there a good reason to believe that if we restore the msi state from
before the reset that it will match the current msi state.  Since arch
code may change the msi message without going through the driver, drivers
currently do not have enough information to even know when to call
pci_save_state to ensure they will have msi state in sync with the other
kernel irq reception data structures.

It turns out the solution is straight forward, cache the state in the
existing msi data structures (not the magic pci saved things) and
have the msi code update the cached state each time we write to the hardware.
This means we never need to read the hardware to figure out what the hardware
state should be.

By modifying the caching in this manner we get to remove our save_state
routines and only need to provide restore_state routines.

The only fields that were at all tricky to regenerate were the msi and msi-x
control registers and the way we regenerate them currently is a bit dependent
upon assumptions on how we use the allow msi registers to be configured and used
making the code a little bit brittle.  If we ever change what cases we allow
or how we configure the msi bits we can address the fragility then.

Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/pci/msi.c        |  150 +++++++----------------------------------------
 drivers/pci/pci.c        |    2 
 drivers/pci/pci.h        |    2 
 include/linux/msi.h      |    8 --
 include/linux/pci_regs.h |    1 
 5 files changed, 29 insertions(+), 134 deletions(-)

--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -100,6 +100,7 @@ static void msi_set_mask_bit(unsigned in
 		BUG();
 		break;
 	}
+	entry->msi_attrib.masked = !!flag;
 }
 
 void read_msi_msg(unsigned int irq, struct msi_msg *msg)
@@ -179,6 +180,7 @@ void write_msi_msg(unsigned int irq, str
 	default:
 		BUG();
 	}
+	entry->msg = *msg;
 }
 
 void mask_msi_irq(unsigned int irq)
@@ -225,164 +227,60 @@ static struct msi_desc* alloc_msi_entry(
 }
 
 #ifdef CONFIG_PM
-static int __pci_save_msi_state(struct pci_dev *dev)
-{
-	int pos, i = 0;
-	u16 control;
-	struct pci_cap_saved_state *save_state;
-	u32 *cap;
-
-	if (!dev->msi_enabled)
-		return 0;
-
-	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
-	if (pos <= 0)
-		return 0;
-
-	save_state = kzalloc(sizeof(struct pci_cap_saved_state) + sizeof(u32) * 5,
-		GFP_KERNEL);
-	if (!save_state) {
-		printk(KERN_ERR "Out of memory in pci_save_msi_state\n");
-		return -ENOMEM;
-	}
-	cap = &save_state->data[0];
-
-	pci_read_config_dword(dev, pos, &cap[i++]);
-	control = cap[0] >> 16;
-	pci_read_config_dword(dev, pos + PCI_MSI_ADDRESS_LO, &cap[i++]);
-	if (control & PCI_MSI_FLAGS_64BIT) {
-		pci_read_config_dword(dev, pos + PCI_MSI_ADDRESS_HI, &cap[i++]);
-		pci_read_config_dword(dev, pos + PCI_MSI_DATA_64, &cap[i++]);
-	} else
-		pci_read_config_dword(dev, pos + PCI_MSI_DATA_32, &cap[i++]);
-	if (control & PCI_MSI_FLAGS_MASKBIT)
-		pci_read_config_dword(dev, pos + PCI_MSI_MASK_BIT, &cap[i++]);
-	save_state->cap_nr = PCI_CAP_ID_MSI;
-	pci_add_saved_cap(dev, save_state);
-	return 0;
-}
-
 static void __pci_restore_msi_state(struct pci_dev *dev)
 {
-	int i = 0, pos;
+	int pos;
 	u16 control;
-	struct pci_cap_saved_state *save_state;
-	u32 *cap;
+	struct msi_desc *entry;
 
 	if (!dev->msi_enabled)
 		return;
 
-	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_MSI);
-	pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
-	if (!save_state || pos <= 0)
-		return;
-	cap = &save_state->data[0];
+	entry = get_irq_msi(dev->irq);
+	pos = entry->msi_attrib.pos;
 
 	pci_intx(dev, 0);		/* disable intx */
-	control = cap[i++] >> 16;
 	msi_set_enable(dev, 0);
-	pci_write_config_dword(dev, pos + PCI_MSI_ADDRESS_LO, cap[i++]);
-	if (control & PCI_MSI_FLAGS_64BIT) {
-		pci_write_config_dword(dev, pos + PCI_MSI_ADDRESS_HI, cap[i++]);
-		pci_write_config_dword(dev, pos + PCI_MSI_DATA_64, cap[i++]);
-	} else
-		pci_write_config_dword(dev, pos + PCI_MSI_DATA_32, cap[i++]);
-	if (control & PCI_MSI_FLAGS_MASKBIT)
-		pci_write_config_dword(dev, pos + PCI_MSI_MASK_BIT, cap[i++]);
+	write_msi_msg(dev->irq, &entry->msg);
+	if (entry->msi_attrib.maskbit)
+		msi_set_mask_bit(dev->irq, entry->msi_attrib.masked);
+
+	pci_read_config_word(dev, pos + PCI_MSI_FLAGS, &control);
+	control &= ~(PCI_MSI_FLAGS_QSIZE | PCI_MSI_FLAGS_ENABLE);
+	if (entry->msi_attrib.maskbit || !entry->msi_attrib.masked)
+		control |= PCI_MSI_FLAGS_ENABLE;
 	pci_write_config_word(dev, pos + PCI_MSI_FLAGS, control);
-	pci_remove_saved_cap(save_state);
-	kfree(save_state);
-}
-
-static int __pci_save_msix_state(struct pci_dev *dev)
-{
-	int pos;
-	int irq, head, tail = 0;
-	u16 control;
-	struct pci_cap_saved_state *save_state;
-
-	if (!dev->msix_enabled)
-		return 0;
-
-	pos = pci_find_capability(dev, PCI_CAP_ID_MSIX);
-	if (pos <= 0)
-		return 0;
-
-	/* save the capability */
-	pci_read_config_word(dev, msi_control_reg(pos), &control);
-	save_state = kzalloc(sizeof(struct pci_cap_saved_state) + sizeof(u16),
-		GFP_KERNEL);
-	if (!save_state) {
-		printk(KERN_ERR "Out of memory in pci_save_msix_state\n");
-		return -ENOMEM;
-	}
-	*((u16 *)&save_state->data[0]) = control;
-
-	/* save the table */
-	irq = head = dev->first_msi_irq;
-	while (head != tail) {
-		struct msi_desc *entry;
-
-		entry = get_irq_msi(irq);
-		read_msi_msg(irq, &entry->msg_save);
-
-		tail = entry->link.tail;
-		irq = tail;
-	}
-
-	save_state->cap_nr = PCI_CAP_ID_MSIX;
-	pci_add_saved_cap(dev, save_state);
-	return 0;
-}
-
-int pci_save_msi_state(struct pci_dev *dev)
-{
-	int rc;
-
-	rc = __pci_save_msi_state(dev);
-	if (rc)
-		return rc;
-
-	rc = __pci_save_msix_state(dev);
-
-	return rc;
 }
 
 static void __pci_restore_msix_state(struct pci_dev *dev)
 {
-	u16 save;
 	int pos;
 	int irq, head, tail = 0;
 	struct msi_desc *entry;
-	struct pci_cap_saved_state *save_state;
+	u16 control;
 
 	if (!dev->msix_enabled)
 		return;
 
-	save_state = pci_find_saved_cap(dev, PCI_CAP_ID_MSIX);
-	if (!save_state)
-		return;
-	save = *((u16 *)&save_state->data[0]);
-	pci_remove_saved_cap(save_state);
-	kfree(save_state);
-
-	pos = pci_find_capability(dev, PCI_CAP_ID_MSIX);
-	if (pos <= 0)
-		return;
-
 	/* route the table */
 	pci_intx(dev, 0);		/* disable intx */
 	msix_set_enable(dev, 0);
 	irq = head = dev->first_msi_irq;
+	entry = get_irq_msi(irq);
+	pos = entry->msi_attrib.pos;
 	while (head != tail) {
 		entry = get_irq_msi(irq);
-		write_msi_msg(irq, &entry->msg_save);
+		write_msi_msg(irq, &entry->msg);
+		msi_set_mask_bit(irq, entry->msi_attrib.masked);
 
 		tail = entry->link.tail;
 		irq = tail;
 	}
 
-	pci_write_config_word(dev, msi_control_reg(pos), save);
+	pci_read_config_word(dev, pos + PCI_MSIX_FLAGS, &control);
+	control &= ~PCI_MSIX_FLAGS_MASKALL;
+	control |= PCI_MSIX_FLAGS_ENABLE;
+	pci_write_config_word(dev, pos + PCI_MSIX_FLAGS, control);
 }
 
 void pci_restore_msi_state(struct pci_dev *dev)
@@ -420,6 +318,7 @@ static int msi_capability_init(struct pc
 	entry->msi_attrib.is_64 = is_64bit_address(control);
 	entry->msi_attrib.entry_nr = 0;
 	entry->msi_attrib.maskbit = is_mask_bit_support(control);
+	entry->msi_attrib.masked = 1;
 	entry->msi_attrib.default_irq = dev->irq;	/* Save IOAPIC IRQ */
 	entry->msi_attrib.pos = pos;
 	if (is_mask_bit_support(control)) {
@@ -507,6 +406,7 @@ static int msix_capability_init(struct p
 		entry->msi_attrib.is_64 = 1;
 		entry->msi_attrib.entry_nr = j;
 		entry->msi_attrib.maskbit = 1;
+		entry->msi_attrib.masked = 1;
 		entry->msi_attrib.default_irq = dev->irq;
 		entry->msi_attrib.pos = pos;
 		entry->dev = dev;
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -638,8 +638,6 @@ pci_save_state(struct pci_dev *dev)
 	/* XXX: 100% dword access ok here? */
 	for (i = 0; i < 16; i++)
 		pci_read_config_dword(dev, i * 4,&dev->saved_config_space[i]);
-	if ((i = pci_save_msi_state(dev)) != 0)
-		return i;
 	if ((i = pci_save_pcie_state(dev)) != 0)
 		return i;
 	if ((i = pci_save_pcix_state(dev)) != 0)
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -52,10 +52,8 @@ static inline void pci_no_msi(void) { }
 #endif
 
 #if defined(CONFIG_PCI_MSI) && defined(CONFIG_PM)
-int pci_save_msi_state(struct pci_dev *dev);
 void pci_restore_msi_state(struct pci_dev *dev);
 #else
-static inline int pci_save_msi_state(struct pci_dev *dev) { return 0; }
 static inline void pci_restore_msi_state(struct pci_dev *dev) {}
 #endif
 
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -17,7 +17,7 @@ struct msi_desc {
 	struct {
 		__u8	type	: 5; 	/* {0: unused, 5h:MSI, 11h:MSI-X} */
 		__u8	maskbit	: 1; 	/* mask-pending bit supported ?   */
-		__u8	unused	: 1;
+		__u8	masked	: 1;
 		__u8	is_64	: 1;	/* Address size: 0=32bit 1=64bit  */
 		__u8	pos;	 	/* Location of the msi capability */
 		__u16	entry_nr;    	/* specific enabled entry 	  */
@@ -32,10 +32,8 @@ struct msi_desc {
 	void __iomem *mask_base;
 	struct pci_dev *dev;
 
-#ifdef CONFIG_PM
-	/* PM save area for MSIX address/data */
-	struct msi_msg msg_save;
-#endif
+	/* Last set MSI message */
+	struct msi_msg msg;
 };
 
 /*
--- a/include/linux/pci_regs.h
+++ b/include/linux/pci_regs.h
@@ -296,6 +296,7 @@
 #define PCI_MSIX_FLAGS		2
 #define  PCI_MSIX_FLAGS_QSIZE	0x7FF
 #define  PCI_MSIX_FLAGS_ENABLE	(1 << 15)
+#define  PCI_MSIX_FLAGS_MASKALL	(1 << 14)
 #define PCI_MSIX_FLAGS_BIRMASK	(7 << 0)
 #define PCI_MSIX_FLAGS_BITMASK	(1 << 0)
 


Patches currently in gregkh-2.6 which might be from ebiederm@xmission.com are

Re: [PATCH 0/2] Repair pci_restore_state when used with device resets

[Ingo Molnar]

* Eric W. Biederman <ebiederm@xmission.com> wrote:

> I have never have figured out how to get suspend/resume actually 
> working on any of my machines [...]

ouch! Are you interested in getting it work?

	Ingo

Re: [PATCH 0/2] Repair pci_restore_state when used with device resets

[Ingo Molnar]

* Eric W. Biederman <ebiederm@xmission.com> wrote:

> I have never have figured out how to get suspend/resume actually 
> working on any of my machines [...]

ouch! Are you interested in getting it work?

	Ingo

Re: [PATCH 0/2] Repair pci_restore_state when used with device resets

[Eric W. Biederman]

Ingo Molnar <mingo@elte.hu> writes:

> * Eric W. Biederman <ebiederm@xmission.com> wrote:
>
>> I have never have figured out how to get suspend/resume actually 
>> working on any of my machines [...]
>
> ouch! Are you interested in getting it work?

I haven't even seriously tried. I don't yet have a laptop and I like
staying logged.  The first time I rolled the jiffie counter it was a
happened after I had realized that if I kept my machine up for another
couple of months my jiffie counter would roll and I said why not  So
basically suspend hasn't been a feature I'm been interested in using.
I get more annoyed at my UPS failing..

I will probably get around to figuring out the whole suspend/resume
thing one of these days and it will probably take me a day or two.
But that doesn't result in bug fixes being delivered in a timely manner.

Eric

Re: [PATCH 0/2] Repair pci_restore_state when used with device resets

[Eric W. Biederman]

Ingo Molnar <mingo@elte.hu> writes:

> * Eric W. Biederman <ebiederm@xmission.com> wrote:
>
>> I have never have figured out how to get suspend/resume actually 
>> working on any of my machines [...]
>
> ouch! Are you interested in getting it work?

I haven't even seriously tried. I don't yet have a laptop and I like
staying logged.  The first time I rolled the jiffie counter it was a
happened after I had realized that if I kept my machine up for another
couple of months my jiffie counter would roll and I said why not  So
basically suspend hasn't been a feature I'm been interested in using.
I get more annoyed at my UPS failing..

I will probably get around to figuring out the whole suspend/resume
thing one of these days and it will probably take me a day or two.
But that doesn't result in bug fixes being delivered in a timely manner.

Eric

Re: SATA resume slowness, e1000 MSI warning

[Michael S. Tsirkin]

> The only case I can see which might trigger this is if we saved
> pci-X state and then didn't restore it because we could not find
> the capability on restore.

Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle
regular devices and seem to ignore the fact that for bridge PCI-X
capability has a different structure.

Is this intentional? If not, here's a patch to fix this.
Warning: completely untested.


PCI: restore bridge PCI-X capability registers after PM event

Restore PCI-X bridge up/downstream capability registers
after PM event.  This includes maxumum split transaction
commitment limit which might be vital for PCI X.

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index df49530..4b788ef 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -597,14 +597,19 @@ static int pci_save_pcix_state(struct pci_dev *dev)
 	if (pos <= 0)
 		return 0;
 
-	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
+	save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 2, GFP_KERNEL);
 	if (!save_state) {
-		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
+		dev_err(&dev->dev, "Out of memory in pci_save_pcix_state\n");
 		return -ENOMEM;
 	}
 	cap = (u16 *)&save_state->data[0];
 
-	pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
+	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+		pci_read_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, &cap[i++]);
+		pci_read_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, &cap[i++]);
+	} else
+		pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
+
 	pci_add_saved_cap(dev, save_state);
 	return 0;
 }
@@ -621,7 +626,11 @@ static void pci_restore_pcix_state(struct pci_dev *dev)
 		return;
 	cap = (u16 *)&save_state->data[0];
 
-	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
+	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+		pci_write_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, cap[i++]);
+		pci_write_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, cap[i++]);
+	} else
+		pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
 	pci_remove_saved_cap(save_state);
 	kfree(save_state);
 }
diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
index f09cce2..fb7eefd 100644
--- a/include/linux/pci_regs.h
+++ b/include/linux/pci_regs.h
@@ -332,6 +332,8 @@
 #define  PCI_X_STATUS_SPL_ERR	0x20000000	/* Rcvd Split Completion Error Msg */
 #define  PCI_X_STATUS_266MHZ	0x40000000	/* 266 MHz capable */
 #define  PCI_X_STATUS_533MHZ	0x80000000	/* 533 MHz capable */
+#define PCI_X_BRIDGE_UP_SPL_CTL 10	/* PCI-X upstream split transaction limit */
+#define PCI_X_BRIDGE_DN_SPL_CTL 14	/* PCI-X downstream split transaction limit */
 
 /* PCI Express capability registers */
 


-- 
MST

Re: SATA resume slowness, e1000 MSI warning

[Michael S. Tsirkin]

> The only case I can see which might trigger this is if we saved
> pci-X state and then didn't restore it because we could not find
> the capability on restore.

Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle
regular devices and seem to ignore the fact that for bridge PCI-X
capability has a different structure.

Is this intentional? If not, here's a patch to fix this.
Warning: completely untested.


PCI: restore bridge PCI-X capability registers after PM event

Restore PCI-X bridge up/downstream capability registers
after PM event.  This includes maxumum split transaction
commitment limit which might be vital for PCI X.

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index df49530..4b788ef 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -597,14 +597,19 @@ static int pci_save_pcix_state(struct pci_dev *dev)
 	if (pos <= 0)
 		return 0;
 
-	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
+	save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 2, GFP_KERNEL);
 	if (!save_state) {
-		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
+		dev_err(&dev->dev, "Out of memory in pci_save_pcix_state\n");
 		return -ENOMEM;
 	}
 	cap = (u16 *)&save_state->data[0];
 
-	pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
+	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+		pci_read_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, &cap[i++]);
+		pci_read_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, &cap[i++]);
+	} else
+		pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
+
 	pci_add_saved_cap(dev, save_state);
 	return 0;
 }
@@ -621,7 +626,11 @@ static void pci_restore_pcix_state(struct pci_dev *dev)
 		return;
 	cap = (u16 *)&save_state->data[0];
 
-	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
+	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
+		pci_write_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, cap[i++]);
+		pci_write_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, cap[i++]);
+	} else
+		pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
 	pci_remove_saved_cap(save_state);
 	kfree(save_state);
 }
diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
index f09cce2..fb7eefd 100644
--- a/include/linux/pci_regs.h
+++ b/include/linux/pci_regs.h
@@ -332,6 +332,8 @@
 #define  PCI_X_STATUS_SPL_ERR	0x20000000	/* Rcvd Split Completion Error Msg */
 #define  PCI_X_STATUS_266MHZ	0x40000000	/* 266 MHz capable */
 #define  PCI_X_STATUS_533MHZ	0x80000000	/* 533 MHz capable */
+#define PCI_X_BRIDGE_UP_SPL_CTL 10	/* PCI-X upstream split transaction limit */
+#define PCI_X_BRIDGE_DN_SPL_CTL 14	/* PCI-X downstream split transaction limit */
 
 /* PCI Express capability registers */
 


-- 
MST

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:

>> The only case I can see which might trigger this is if we saved
>> pci-X state and then didn't restore it because we could not find
>> the capability on restore.
>
> Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle
> regular devices and seem to ignore the fact that for bridge PCI-X
> capability has a different structure.
>
> Is this intentional? 

Probably not a such.  I don't think we have any drivers for bridge
devices so I don't think it matters.  It likely wouldn't hurt to fix
it just in case though.

Do any of the mellanox cards do anything with the bridge on the card?

> If not, here's a patch to fix this. Warning: completely untested.

If you fix the offsets and diff this against my last fix (to never
free the buffer) I think your patch makes sense.

> PCI: restore bridge PCI-X capability registers after PM event
>
> Restore PCI-X bridge up/downstream capability registers
> after PM event.  This includes maxumum split transaction
> commitment limit which might be vital for PCI X.
>
> Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index df49530..4b788ef 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -597,14 +597,19 @@ static int pci_save_pcix_state(struct pci_dev *dev)
>  	if (pos <= 0)
>  		return 0;
>  
> -	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
> + save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 2, GFP_KERNEL);
>  	if (!save_state) {
> -		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
> +		dev_err(&dev->dev, "Out of memory in pci_save_pcix_state\n");
>  		return -ENOMEM;
>  	}
>  	cap = (u16 *)&save_state->data[0];
>  
> -	pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
> +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {

This appears to be the proper test.

> + pci_read_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, &cap[i++]);
> + pci_read_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, &cap[i++]);
> +	} else
> +		pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
> +
>  	pci_add_saved_cap(dev, save_state);
>  	return 0;
>  }
> @@ -621,7 +626,11 @@ static void pci_restore_pcix_state(struct pci_dev *dev)
>  		return;
>  	cap = (u16 *)&save_state->data[0];
>  
> -	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
> +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> + pci_write_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, cap[i++]);
> + pci_write_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, cap[i++]);

These look like the proper two registers to save.

> +	} else
> +		pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
>  	pci_remove_saved_cap(save_state);
>  	kfree(save_state);
>  }
> diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
> index f09cce2..fb7eefd 100644
> --- a/include/linux/pci_regs.h
> +++ b/include/linux/pci_regs.h
> @@ -332,6 +332,8 @@
>  #define PCI_X_STATUS_SPL_ERR 0x20000000 /* Rcvd Split Completion Error Msg */
>  #define  PCI_X_STATUS_266MHZ	0x40000000	/* 266 MHz capable */
>  #define  PCI_X_STATUS_533MHZ	0x80000000	/* 533 MHz capable */
> +#define PCI_X_BRIDGE_UP_SPL_CTL 10 /* PCI-X upstream split transaction limit */
> +#define PCI_X_BRIDGE_DN_SPL_CTL 14 /* PCI-X downstream split transaction limit */

Unless I am completely misreading the spec. While you have picked the
right register to save the offsets should be 0x08 and 0x0c or 8 and 12....

Eric

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:

>> The only case I can see which might trigger this is if we saved
>> pci-X state and then didn't restore it because we could not find
>> the capability on restore.
>
> Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle
> regular devices and seem to ignore the fact that for bridge PCI-X
> capability has a different structure.
>
> Is this intentional? 

Probably not a such.  I don't think we have any drivers for bridge
devices so I don't think it matters.  It likely wouldn't hurt to fix
it just in case though.

Do any of the mellanox cards do anything with the bridge on the card?

> If not, here's a patch to fix this. Warning: completely untested.

If you fix the offsets and diff this against my last fix (to never
free the buffer) I think your patch makes sense.

> PCI: restore bridge PCI-X capability registers after PM event
>
> Restore PCI-X bridge up/downstream capability registers
> after PM event.  This includes maxumum split transaction
> commitment limit which might be vital for PCI X.
>
> Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index df49530..4b788ef 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -597,14 +597,19 @@ static int pci_save_pcix_state(struct pci_dev *dev)
>  	if (pos <= 0)
>  		return 0;
>  
> -	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
> + save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 2, GFP_KERNEL);
>  	if (!save_state) {
> -		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
> +		dev_err(&dev->dev, "Out of memory in pci_save_pcix_state\n");
>  		return -ENOMEM;
>  	}
>  	cap = (u16 *)&save_state->data[0];
>  
> -	pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
> +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {

This appears to be the proper test.

> + pci_read_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, &cap[i++]);
> + pci_read_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, &cap[i++]);
> +	} else
> +		pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
> +
>  	pci_add_saved_cap(dev, save_state);
>  	return 0;
>  }
> @@ -621,7 +626,11 @@ static void pci_restore_pcix_state(struct pci_dev *dev)
>  		return;
>  	cap = (u16 *)&save_state->data[0];
>  
> -	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
> +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> + pci_write_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, cap[i++]);
> + pci_write_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, cap[i++]);

These look like the proper two registers to save.

> +	} else
> +		pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
>  	pci_remove_saved_cap(save_state);
>  	kfree(save_state);
>  }
> diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
> index f09cce2..fb7eefd 100644
> --- a/include/linux/pci_regs.h
> +++ b/include/linux/pci_regs.h
> @@ -332,6 +332,8 @@
>  #define PCI_X_STATUS_SPL_ERR 0x20000000 /* Rcvd Split Completion Error Msg */
>  #define  PCI_X_STATUS_266MHZ	0x40000000	/* 266 MHz capable */
>  #define  PCI_X_STATUS_533MHZ	0x80000000	/* 533 MHz capable */
> +#define PCI_X_BRIDGE_UP_SPL_CTL 10 /* PCI-X upstream split transaction limit */
> +#define PCI_X_BRIDGE_DN_SPL_CTL 14 /* PCI-X downstream split transaction limit */

Unless I am completely misreading the spec. While you have picked the
right register to save the offsets should be 0x08 and 0x0c or 8 and 12....

Eric

Re: SATA resume slowness, e1000 MSI warning

[Michael S. Tsirkin]

> Quoting Eric W. Biederman <ebiederm@xmission.com>:
> Subject: Re: SATA resume slowness, e1000 MSI warning
> 
> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> 
> >> The only case I can see which might trigger this is if we saved
> >> pci-X state and then didn't restore it because we could not find
> >> the capability on restore.
> >
> > Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle
> > regular devices and seem to ignore the fact that for bridge PCI-X
> > capability has a different structure.
> >
> > Is this intentional? 
> 
> Probably not a such.  I don't think we have any drivers for bridge
> devices so I don't think it matters.  It likely wouldn't hurt to fix
> it just in case though.
> 
> Do any of the mellanox cards do anything with the bridge on the card?

Yes but they do their own thing wrt saving/restoring registers.
Look at drivers/infiniband/hw/mthca/mthca_reset.c

> > If not, here's a patch to fix this. Warning: completely untested.
> 
> If you fix the offsets and diff this against my last fix (to never
> free the buffer) I think your patch makes sense.

Let's agree what the correct offsets are.

> > PCI: restore bridge PCI-X capability registers after PM event
> >
> > Restore PCI-X bridge up/downstream capability registers
> > after PM event.  This includes maxumum split transaction
> > commitment limit which might be vital for PCI X.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
> >
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index df49530..4b788ef 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -597,14 +597,19 @@ static int pci_save_pcix_state(struct pci_dev *dev)
> >  	if (pos <= 0)
> >  		return 0;
> >  
> > -	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
> > + save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 2, GFP_KERNEL);
> >  	if (!save_state) {
> > -		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
> > +		dev_err(&dev->dev, "Out of memory in pci_save_pcix_state\n");
> >  		return -ENOMEM;
> >  	}
> >  	cap = (u16 *)&save_state->data[0];
> >  
> > -	pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
> > +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> 
> This appears to be the proper test.
> 
> > + pci_read_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, &cap[i++]);
> > + pci_read_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, &cap[i++]);
> > +	} else
> > +		pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
> > +
> >  	pci_add_saved_cap(dev, save_state);
> >  	return 0;
> >  }
> > @@ -621,7 +626,11 @@ static void pci_restore_pcix_state(struct pci_dev *dev)
> >  		return;
> >  	cap = (u16 *)&save_state->data[0];
> >  
> > -	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
> > +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> > + pci_write_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, cap[i++]);
> > + pci_write_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, cap[i++]);
> 
> These look like the proper two registers to save.
> 
> > +	} else
> > +		pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
> >  	pci_remove_saved_cap(save_state);
> >  	kfree(save_state);
> >  }
> > diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
> > index f09cce2..fb7eefd 100644
> > --- a/include/linux/pci_regs.h
> > +++ b/include/linux/pci_regs.h
> > @@ -332,6 +332,8 @@
> >  #define PCI_X_STATUS_SPL_ERR 0x20000000 /* Rcvd Split Completion Error Msg */
> >  #define  PCI_X_STATUS_266MHZ	0x40000000	/* 266 MHz capable */
> >  #define  PCI_X_STATUS_533MHZ	0x80000000	/* 533 MHz capable */
> > +#define PCI_X_BRIDGE_UP_SPL_CTL 10 /* PCI-X upstream split transaction limit */
> > +#define PCI_X_BRIDGE_DN_SPL_CTL 14 /* PCI-X downstream split transaction limit */
> 
> Unless I am completely misreading the spec. While you have picked the
> right register to save the offsets should be 0x08 and 0x0c or 8 and 12....

No, the spec is written in terms of dwords (32 bit), we are storing words (16 bits).
The data at offsets 8 and 12 is read-only split transaction capacity.
Split transaction limit starts at bit 16 so you need to add 2 to byte offset.

Right?


-- 
MST

Re: SATA resume slowness, e1000 MSI warning

[Michael S. Tsirkin]

> Quoting Eric W. Biederman <ebiederm@xmission.com>:
> Subject: Re: SATA resume slowness, e1000 MSI warning
> 
> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> 
> >> The only case I can see which might trigger this is if we saved
> >> pci-X state and then didn't restore it because we could not find
> >> the capability on restore.
> >
> > Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle
> > regular devices and seem to ignore the fact that for bridge PCI-X
> > capability has a different structure.
> >
> > Is this intentional? 
> 
> Probably not a such.  I don't think we have any drivers for bridge
> devices so I don't think it matters.  It likely wouldn't hurt to fix
> it just in case though.
> 
> Do any of the mellanox cards do anything with the bridge on the card?

Yes but they do their own thing wrt saving/restoring registers.
Look at drivers/infiniband/hw/mthca/mthca_reset.c

> > If not, here's a patch to fix this. Warning: completely untested.
> 
> If you fix the offsets and diff this against my last fix (to never
> free the buffer) I think your patch makes sense.

Let's agree what the correct offsets are.

> > PCI: restore bridge PCI-X capability registers after PM event
> >
> > Restore PCI-X bridge up/downstream capability registers
> > after PM event.  This includes maxumum split transaction
> > commitment limit which might be vital for PCI X.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
> >
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index df49530..4b788ef 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -597,14 +597,19 @@ static int pci_save_pcix_state(struct pci_dev *dev)
> >  	if (pos <= 0)
> >  		return 0;
> >  
> > -	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
> > + save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 2, GFP_KERNEL);
> >  	if (!save_state) {
> > -		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
> > +		dev_err(&dev->dev, "Out of memory in pci_save_pcix_state\n");
> >  		return -ENOMEM;
> >  	}
> >  	cap = (u16 *)&save_state->data[0];
> >  
> > -	pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
> > +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> 
> This appears to be the proper test.
> 
> > + pci_read_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, &cap[i++]);
> > + pci_read_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, &cap[i++]);
> > +	} else
> > +		pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
> > +
> >  	pci_add_saved_cap(dev, save_state);
> >  	return 0;
> >  }
> > @@ -621,7 +626,11 @@ static void pci_restore_pcix_state(struct pci_dev *dev)
> >  		return;
> >  	cap = (u16 *)&save_state->data[0];
> >  
> > -	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
> > +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> > + pci_write_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, cap[i++]);
> > + pci_write_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, cap[i++]);
> 
> These look like the proper two registers to save.
> 
> > +	} else
> > +		pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
> >  	pci_remove_saved_cap(save_state);
> >  	kfree(save_state);
> >  }
> > diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
> > index f09cce2..fb7eefd 100644
> > --- a/include/linux/pci_regs.h
> > +++ b/include/linux/pci_regs.h
> > @@ -332,6 +332,8 @@
> >  #define PCI_X_STATUS_SPL_ERR 0x20000000 /* Rcvd Split Completion Error Msg */
> >  #define  PCI_X_STATUS_266MHZ	0x40000000	/* 266 MHz capable */
> >  #define  PCI_X_STATUS_533MHZ	0x80000000	/* 533 MHz capable */
> > +#define PCI_X_BRIDGE_UP_SPL_CTL 10 /* PCI-X upstream split transaction limit */
> > +#define PCI_X_BRIDGE_DN_SPL_CTL 14 /* PCI-X downstream split transaction limit */
> 
> Unless I am completely misreading the spec. While you have picked the
> right register to save the offsets should be 0x08 and 0x0c or 8 and 12....

No, the spec is written in terms of dwords (32 bit), we are storing words (16 bits).
The data at offsets 8 and 12 is read-only split transaction capacity.
Split transaction limit starts at bit 16 so you need to add 2 to byte offset.

Right?


-- 
MST

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:

>> Quoting Eric W. Biederman <ebiederm@xmission.com>:
>> Subject: Re: SATA resume slowness, e1000 MSI warning
>> 
>> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
>> 
>> >> The only case I can see which might trigger this is if we saved
>> >> pci-X state and then didn't restore it because we could not find
>> >> the capability on restore.
>> >
>> > Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle
>> > regular devices and seem to ignore the fact that for bridge PCI-X
>> > capability has a different structure.
>> >
>> > Is this intentional? 
>> 
>> Probably not a such.  I don't think we have any drivers for bridge
>> devices so I don't think it matters.  It likely wouldn't hurt to fix
>> it just in case though.
>> 
>> Do any of the mellanox cards do anything with the bridge on the card?
>
> Yes but they do their own thing wrt saving/restoring registers.
> Look at drivers/infiniband/hw/mthca/mthca_reset.c
>
>> > If not, here's a patch to fix this. Warning: completely untested.
>> 
>> If you fix the offsets and diff this against my last fix (to never
>> free the buffer) I think your patch makes sense.
>
> Let's agree what the correct offsets are.
>
>> > PCI: restore bridge PCI-X capability registers after PM event
>> >
>> > Restore PCI-X bridge up/downstream capability registers
>> > after PM event.  This includes maxumum split transaction
>> > commitment limit which might be vital for PCI X.
>> >
>> > Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
>> >
>> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> > index df49530..4b788ef 100644
>> > --- a/drivers/pci/pci.c
>> > +++ b/drivers/pci/pci.c
>> > @@ -597,14 +597,19 @@ static int pci_save_pcix_state(struct pci_dev *dev)
>> >  	if (pos <= 0)
>> >  		return 0;
>> >  
>> > -	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
>> > + save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 2, GFP_KERNEL);
>> >  	if (!save_state) {
>> > -		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
>> > +		dev_err(&dev->dev, "Out of memory in pci_save_pcix_state\n");
>> >  		return -ENOMEM;
>> >  	}
>> >  	cap = (u16 *)&save_state->data[0];
>> >  
>> > -	pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
>> > +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
>> 
>> This appears to be the proper test.
>> 
>> > + pci_read_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, &cap[i++]);
>> > + pci_read_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, &cap[i++]);
>> > +	} else
>> > +		pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
>> > +
>> >  	pci_add_saved_cap(dev, save_state);
>> >  	return 0;
>> >  }
>> > @@ -621,7 +626,11 @@ static void pci_restore_pcix_state(struct pci_dev *dev)
>> >  		return;
>> >  	cap = (u16 *)&save_state->data[0];
>> >  
>> > -	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
>> > +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
>> > + pci_write_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, cap[i++]);
>> > + pci_write_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, cap[i++]);
>> 
>> These look like the proper two registers to save.
>> 
>> > +	} else
>> > +		pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
>> >  	pci_remove_saved_cap(save_state);
>> >  	kfree(save_state);
>> >  }
>> > diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
>> > index f09cce2..fb7eefd 100644
>> > --- a/include/linux/pci_regs.h
>> > +++ b/include/linux/pci_regs.h
>> > @@ -332,6 +332,8 @@
>> > #define PCI_X_STATUS_SPL_ERR 0x20000000 /* Rcvd Split Completion Error Msg
> */
>> >  #define  PCI_X_STATUS_266MHZ	0x40000000	/* 266 MHz capable */
>> >  #define  PCI_X_STATUS_533MHZ	0x80000000	/* 533 MHz capable */
>> > +#define PCI_X_BRIDGE_UP_SPL_CTL 10 /* PCI-X upstream split transaction
> limit */
>> > +#define PCI_X_BRIDGE_DN_SPL_CTL 14 /* PCI-X downstream split transaction
> limit */
>> 
>> Unless I am completely misreading the spec. While you have picked the
>> right register to save the offsets should be 0x08 and 0x0c or 8 and 12....
>
> No, the spec is written in terms of dwords (32 bit), we are storing words (16
> bits).
> The data at offsets 8 and 12 is read-only split transaction capacity.
> Split transaction limit starts at bit 16 so you need to add 2 to byte offset.
>
> Right?

>From that perspective it makes sense.  So I will agree with the way you are
thinking the code works.

The read-only and the read-write part are all defined as part of the
same register so I didn't expect them to be separate.  And I hadn't
paid attention enough to see that the code was only saving 16bit
values.

Rumor has it that some pci devices can't tolerate < 32bit accesses.
Although I have never met one.  The two factors together suggest that
for generic code it probably makes sense to operate on 32bit
quantities, and just to ignore the read-only portion.

Eric

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:

>> Quoting Eric W. Biederman <ebiederm@xmission.com>:
>> Subject: Re: SATA resume slowness, e1000 MSI warning
>> 
>> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
>> 
>> >> The only case I can see which might trigger this is if we saved
>> >> pci-X state and then didn't restore it because we could not find
>> >> the capability on restore.
>> >
>> > Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle
>> > regular devices and seem to ignore the fact that for bridge PCI-X
>> > capability has a different structure.
>> >
>> > Is this intentional? 
>> 
>> Probably not a such.  I don't think we have any drivers for bridge
>> devices so I don't think it matters.  It likely wouldn't hurt to fix
>> it just in case though.
>> 
>> Do any of the mellanox cards do anything with the bridge on the card?
>
> Yes but they do their own thing wrt saving/restoring registers.
> Look at drivers/infiniband/hw/mthca/mthca_reset.c
>
>> > If not, here's a patch to fix this. Warning: completely untested.
>> 
>> If you fix the offsets and diff this against my last fix (to never
>> free the buffer) I think your patch makes sense.
>
> Let's agree what the correct offsets are.
>
>> > PCI: restore bridge PCI-X capability registers after PM event
>> >
>> > Restore PCI-X bridge up/downstream capability registers
>> > after PM event.  This includes maxumum split transaction
>> > commitment limit which might be vital for PCI X.
>> >
>> > Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
>> >
>> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> > index df49530..4b788ef 100644
>> > --- a/drivers/pci/pci.c
>> > +++ b/drivers/pci/pci.c
>> > @@ -597,14 +597,19 @@ static int pci_save_pcix_state(struct pci_dev *dev)
>> >  	if (pos <= 0)
>> >  		return 0;
>> >  
>> > -	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
>> > + save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 2, GFP_KERNEL);
>> >  	if (!save_state) {
>> > -		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
>> > +		dev_err(&dev->dev, "Out of memory in pci_save_pcix_state\n");
>> >  		return -ENOMEM;
>> >  	}
>> >  	cap = (u16 *)&save_state->data[0];
>> >  
>> > -	pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
>> > +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
>> 
>> This appears to be the proper test.
>> 
>> > + pci_read_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, &cap[i++]);
>> > + pci_read_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, &cap[i++]);
>> > +	} else
>> > +		pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
>> > +
>> >  	pci_add_saved_cap(dev, save_state);
>> >  	return 0;
>> >  }
>> > @@ -621,7 +626,11 @@ static void pci_restore_pcix_state(struct pci_dev *dev)
>> >  		return;
>> >  	cap = (u16 *)&save_state->data[0];
>> >  
>> > -	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
>> > +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
>> > + pci_write_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, cap[i++]);
>> > + pci_write_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, cap[i++]);
>> 
>> These look like the proper two registers to save.
>> 
>> > +	} else
>> > +		pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
>> >  	pci_remove_saved_cap(save_state);
>> >  	kfree(save_state);
>> >  }
>> > diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
>> > index f09cce2..fb7eefd 100644
>> > --- a/include/linux/pci_regs.h
>> > +++ b/include/linux/pci_regs.h
>> > @@ -332,6 +332,8 @@
>> > #define PCI_X_STATUS_SPL_ERR 0x20000000 /* Rcvd Split Completion Error Msg
> */
>> >  #define  PCI_X_STATUS_266MHZ	0x40000000	/* 266 MHz capable */
>> >  #define  PCI_X_STATUS_533MHZ	0x80000000	/* 533 MHz capable */
>> > +#define PCI_X_BRIDGE_UP_SPL_CTL 10 /* PCI-X upstream split transaction
> limit */
>> > +#define PCI_X_BRIDGE_DN_SPL_CTL 14 /* PCI-X downstream split transaction
> limit */
>> 
>> Unless I am completely misreading the spec. While you have picked the
>> right register to save the offsets should be 0x08 and 0x0c or 8 and 12....
>
> No, the spec is written in terms of dwords (32 bit), we are storing words (16
> bits).
> The data at offsets 8 and 12 is read-only split transaction capacity.
> Split transaction limit starts at bit 16 so you need to add 2 to byte offset.
>
> Right?

>From that perspective it makes sense.  So I will agree with the way you are
thinking the code works.

The read-only and the read-write part are all defined as part of the
same register so I didn't expect them to be separate.  And I hadn't
paid attention enough to see that the code was only saving 16bit
values.

Rumor has it that some pci devices can't tolerate < 32bit accesses.
Although I have never met one.  The two factors together suggest that
for generic code it probably makes sense to operate on 32bit
quantities, and just to ignore the read-only portion.

Eric

Re: SATA resume slowness, e1000 MSI warning

[Michael S. Tsirkin]

> Rumor has it that some pci devices can't tolerate < 32bit accesses.
> Although I have never met one.

hopefully not bridge devices?

> The two factors together suggest that
> for generic code it probably makes sense to operate on 32bit
> quantities, and just to ignore the read-only portion.

The code for regular devices seems to use 16-bit accesses, so
I think it's best to stay consistent. Or do you want to change this too?

-- 
MST

Re: SATA resume slowness, e1000 MSI warning

[Michael S. Tsirkin]

> Rumor has it that some pci devices can't tolerate < 32bit accesses.
> Although I have never met one.

hopefully not bridge devices?

> The two factors together suggest that
> for generic code it probably makes sense to operate on 32bit
> quantities, and just to ignore the read-only portion.

The code for regular devices seems to use 16-bit accesses, so
I think it's best to stay consistent. Or do you want to change this too?

-- 
MST

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:

>> Rumor has it that some pci devices can't tolerate < 32bit accesses.
>> Although I have never met one.
>
> hopefully not bridge devices?
>
>> The two factors together suggest that
>> for generic code it probably makes sense to operate on 32bit
>> quantities, and just to ignore the read-only portion.
>
> The code for regular devices seems to use 16-bit accesses, so
> I think it's best to stay consistent. Or do you want to change this too?

If we are stomping rare probabilities we might as well change that too.
The code to save pci-x state is relatively recent.  So it probably just
hasn't met a problem device yet (assuming they exist).

Eric

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:

>> Rumor has it that some pci devices can't tolerate < 32bit accesses.
>> Although I have never met one.
>
> hopefully not bridge devices?
>
>> The two factors together suggest that
>> for generic code it probably makes sense to operate on 32bit
>> quantities, and just to ignore the read-only portion.
>
> The code for regular devices seems to use 16-bit accesses, so
> I think it's best to stay consistent. Or do you want to change this too?

If we are stomping rare probabilities we might as well change that too.
The code to save pci-x state is relatively recent.  So it probably just
hasn't met a problem device yet (assuming they exist).

Eric

Re: SATA resume slowness, e1000 MSI warning

[Michael S. Tsirkin]

> Quoting Eric W. Biederman <ebiederm@xmission.com>:
> Subject: Re: SATA resume slowness, e1000 MSI warning
> 
> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> 
> >> Rumor has it that some pci devices can't tolerate < 32bit accesses.
> >> Although I have never met one.
> >
> > hopefully not bridge devices?
> >
> >> The two factors together suggest that
> >> for generic code it probably makes sense to operate on 32bit
> >> quantities, and just to ignore the read-only portion.
> >
> > The code for regular devices seems to use 16-bit accesses, so
> > I think it's best to stay consistent. Or do you want to change this too?
> 
> If we are stomping rare probabilities we might as well change that too.
> The code to save pci-x state is relatively recent.  So it probably just
> hasn't met a problem device yet (assuming they exist).

OK I guess. I gather we assume writing read-only registers has no side effects?
Are there rumors circulating wrt to these?

-- 
MST

Re: SATA resume slowness, e1000 MSI warning

[Michael S. Tsirkin]

> Quoting Eric W. Biederman <ebiederm@xmission.com>:
> Subject: Re: SATA resume slowness, e1000 MSI warning
> 
> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> 
> >> Rumor has it that some pci devices can't tolerate < 32bit accesses.
> >> Although I have never met one.
> >
> > hopefully not bridge devices?
> >
> >> The two factors together suggest that
> >> for generic code it probably makes sense to operate on 32bit
> >> quantities, and just to ignore the read-only portion.
> >
> > The code for regular devices seems to use 16-bit accesses, so
> > I think it's best to stay consistent. Or do you want to change this too?
> 
> If we are stomping rare probabilities we might as well change that too.
> The code to save pci-x state is relatively recent.  So it probably just
> hasn't met a problem device yet (assuming they exist).

OK I guess. I gather we assume writing read-only registers has no side effects?
Are there rumors circulating wrt to these?

-- 
MST

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:

> OK I guess. I gather we assume writing read-only registers has no side effects?
> Are there rumors circulating wrt to these?

I haven't heard anything about that, and if we are writing the same value back
it should be pretty safe.

I have heard it asserted that at least one version of the pci spec
only required 32bit accesses to be supported by the hardware.  One of
these days I will have to look that and see if it is true.  I do know
it can be weird for hardware developers to support multiple kinds of
decode.   As I recall for pci and pci-x at the hardware level the only
difference in between 32bit transactions and smaller ones is the state
of the byte-enable lines.

Eric

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Michael S. Tsirkin" <mst@mellanox.co.il> writes:

> OK I guess. I gather we assume writing read-only registers has no side effects?
> Are there rumors circulating wrt to these?

I haven't heard anything about that, and if we are writing the same value back
it should be pretty safe.

I have heard it asserted that at least one version of the pci spec
only required 32bit accesses to be supported by the hardware.  One of
these days I will have to look that and see if it is true.  I do know
it can be weird for hardware developers to support multiple kinds of
decode.   As I recall for pci and pci-x at the hardware level the only
difference in between 32bit transactions and smaller ones is the state
of the byte-enable lines.

Eric

Re: SATA resume slowness, e1000 MSI warning

[Michael S. Tsirkin]

> Quoting Eric W. Biederman <ebiederm@xmission.com>:
> Subject: Re: SATA resume slowness, e1000 MSI warning
> 
> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> 
> > OK I guess. I gather we assume writing read-only registers has no side effects?
> > Are there rumors circulating wrt to these?
> 
> I haven't heard anything about that, and if we are writing the same value back
> it should be pretty safe.
> 
> I have heard it asserted that at least one version of the pci spec
> only required 32bit accesses to be supported by the hardware.  One of
> these days I will have to look that and see if it is true.

Maybe. But surely before the PCI-X days.

> I do know
> it can be weird for hardware developers to support multiple kinds of
> decode.

Is this the only place where Linux uses pci_read_config_word/pci_read_config_dword?
I think such hardware will be pretty much DOA on all OS-es.  Why don't we wait
and see whether someone reports a broken config?

> As I recall for pci and pci-x at the hardware level the only
> difference in between 32bit transactions and smaller ones is the state
> of the byte-enable lines.

True, and same holds for PCI-Express.

So let's assume hardware implements RO correctly but ignores the BE bits -
nothing bad happens then, right?

-- 
MST

Re: SATA resume slowness, e1000 MSI warning

[Michael S. Tsirkin]

> Quoting Eric W. Biederman <ebiederm@xmission.com>:
> Subject: Re: SATA resume slowness, e1000 MSI warning
> 
> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
> 
> > OK I guess. I gather we assume writing read-only registers has no side effects?
> > Are there rumors circulating wrt to these?
> 
> I haven't heard anything about that, and if we are writing the same value back
> it should be pretty safe.
> 
> I have heard it asserted that at least one version of the pci spec
> only required 32bit accesses to be supported by the hardware.  One of
> these days I will have to look that and see if it is true.

Maybe. But surely before the PCI-X days.

> I do know
> it can be weird for hardware developers to support multiple kinds of
> decode.

Is this the only place where Linux uses pci_read_config_word/pci_read_config_dword?
I think such hardware will be pretty much DOA on all OS-es.  Why don't we wait
and see whether someone reports a broken config?

> As I recall for pci and pci-x at the hardware level the only
> difference in between 32bit transactions and smaller ones is the state
> of the byte-enable lines.

True, and same holds for PCI-Express.

So let's assume hardware implements RO correctly but ignores the BE bits -
nothing bad happens then, right?

-- 
MST

Re: SATA resume slowness, e1000 MSI warning

[Michael S. Tsirkin]

> > > Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle
> > > regular devices and seem to ignore the fact that for bridge PCI-X
> > > capability has a different structure.
> > >
> > > Is this intentional? 
> > 
> > Probably not a such.  I don't think we have any drivers for bridge
> > devices so I don't think it matters.  It likely wouldn't hurt to fix
> > it just in case though.
> > 
> > Do any of the mellanox cards do anything with the bridge on the card?
> 
> Yes but they do their own thing wrt saving/restoring registers.
> Look at drivers/infiniband/hw/mthca/mthca_reset.c
> 
> > > If not, here's a patch to fix this. Warning: completely untested.
> > 
> > If you fix the offsets and diff this against my last fix (to never
> > free the buffer) I think your patch makes sense.
> 
> Let's agree what the correct offsets are.
> 
> > > PCI: restore bridge PCI-X capability registers after PM event
> > >
> > > Restore PCI-X bridge up/downstream capability registers
> > > after PM event.  This includes maxumum split transaction
> > > commitment limit which might be vital for PCI X.
> > >
> > > Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
> > >
> > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > index df49530..4b788ef 100644
> > > --- a/drivers/pci/pci.c
> > > +++ b/drivers/pci/pci.c
> > > @@ -597,14 +597,19 @@ static int pci_save_pcix_state(struct pci_dev *dev)
> > >  	if (pos <= 0)
> > >  		return 0;
> > >  
> > > -	save_state = kzalloc(sizeof(*save_state) + sizeof(u16), GFP_KERNEL);
> > > + save_state = kzalloc(sizeof(*save_state) + sizeof(u16) * 2, GFP_KERNEL);
> > >  	if (!save_state) {
> > > -		dev_err(&dev->dev, "Out of memory in pci_save_pcie_state\n");
> > > +		dev_err(&dev->dev, "Out of memory in pci_save_pcix_state\n");
> > >  		return -ENOMEM;
> > >  	}
> > >  	cap = (u16 *)&save_state->data[0];
> > >  
> > > -	pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
> > > +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> > 
> > This appears to be the proper test.
> > 
> > > + pci_read_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, &cap[i++]);
> > > + pci_read_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, &cap[i++]);
> > > +	} else
> > > +		pci_read_config_word(dev, pos + PCI_X_CMD, &cap[i++]);
> > > +
> > >  	pci_add_saved_cap(dev, save_state);
> > >  	return 0;
> > >  }
> > > @@ -621,7 +626,11 @@ static void pci_restore_pcix_state(struct pci_dev *dev)
> > >  		return;
> > >  	cap = (u16 *)&save_state->data[0];
> > >  
> > > -	pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
> > > +	if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) {
> > > + pci_write_config_word(dev, pos + PCI_X_BRIDGE_UP_SPL_CTL, cap[i++]);
> > > + pci_write_config_word(dev, pos + PCI_X_BRIDGE_DN_SPL_CTL, cap[i++]);
> > 
> > These look like the proper two registers to save.
> > 
> > > +	} else
> > > +		pci_write_config_word(dev, pos + PCI_X_CMD, cap[i++]);
> > >  	pci_remove_saved_cap(save_state);
> > >  	kfree(save_state);
> > >  }
> > > diff --git a/include/linux/pci_regs.h b/include/linux/pci_regs.h
> > > index f09cce2..fb7eefd 100644
> > > --- a/include/linux/pci_regs.h
> > > +++ b/include/linux/pci_regs.h
> > > @@ -332,6 +332,8 @@
> > >  #define PCI_X_STATUS_SPL_ERR 0x20000000 /* Rcvd Split Completion Error Msg */
> > >  #define  PCI_X_STATUS_266MHZ	0x40000000	/* 266 MHz capable */
> > >  #define  PCI_X_STATUS_533MHZ	0x80000000	/* 533 MHz capable */
> > > +#define PCI_X_BRIDGE_UP_SPL_CTL 10 /* PCI-X upstream split transaction limit */
> > > +#define PCI_X_BRIDGE_DN_SPL_CTL 14 /* PCI-X downstream split transaction limit */
> > 
> > Unless I am completely misreading the spec. While you have picked the
> > right register to save the offsets should be 0x08 and 0x0c or 8 and 12....
> 
> No, the spec is written in terms of dwords (32 bit), we are storing words (16 bits).
> The data at offsets 8 and 12 is read-only split transaction capacity.
> Split transaction limit starts at bit 16 so you need to add 2 to byte offset.

So, Eric, what are your thoughts on this patch (probably wrt 2.6.22)?
Since the rest of the save/restore code uses 16 bit transactions,
it should be safe here too?

-- 
MST

Re: SATA resume slowness, e1000 MSI warning

[Kok, Auke]

Eric W. Biederman wrote:

[CHOP]

> Below is an additional set of warnings that should help debug this.
> The old code just got lucky that it triggered a warning when this happens.


I'm trying this patch together with the other 2 that you sent out a few days 
ago. I'm seeing some minor issues with this and lots of bogus warnings as far as 
I can see.

If I suspend/resume and unload e1000, then reinsert e1000.ko, I immediately hit 
the WARN_ON at `msi.c:516: WARN_ON(!hlist_empty(&dev->saved_cap_space));`

I'm not sure that's useful debugging information. even though saved state exists 
the module has been removed, so you might want to purge the state table when the 
driver gets removed?


anyway, back to testing.

Auke

> 
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 01869b1..5113913 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -613,6 +613,7 @@ int pci_enable_msi(struct pci_dev* dev)
>  		return -EINVAL;
>  
>  	WARN_ON(!!dev->msi_enabled);
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
>  
>  	/* Check whether driver already requested for MSI-X irqs */
>  	if (dev->msix_enabled) {
> @@ -638,6 +639,8 @@ void pci_disable_msi(struct pci_dev* dev)
>  	if (!dev->msi_enabled)
>  		return;
>  
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
> +
>  	msi_set_enable(dev, 0);
>  	pci_intx(dev, 1);		/* enable intx */
>  	dev->msi_enabled = 0;
> @@ -739,6 +742,7 @@ int pci_enable_msix(struct pci_dev* dev, struct msix_entry *entries, int nvec)
>  		}
>  	}
>  	WARN_ON(!!dev->msix_enabled);
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
>  
>  	/* Check whether driver already requested for MSI irq */
>     	if (dev->msi_enabled) {
> @@ -763,6 +767,8 @@ void pci_disable_msix(struct pci_dev* dev)
>  	if (!dev->msix_enabled)
>  		return;
>  
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
> +
>  	msix_set_enable(dev, 0);
>  	pci_intx(dev, 1);		/* enable intx */
>  	dev->msix_enabled = 0;
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index bd44a48..4418839 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -677,6 +677,7 @@ pci_restore_state(struct pci_dev *dev)
>  	}
>  	pci_restore_pcix_state(dev);
>  	pci_restore_msi_state(dev);
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
>  
>  	return 0;
>  }

Re: SATA resume slowness, e1000 MSI warning

[Kok, Auke]

Eric W. Biederman wrote:

[CHOP]

> Below is an additional set of warnings that should help debug this.
> The old code just got lucky that it triggered a warning when this happens.


I'm trying this patch together with the other 2 that you sent out a few days 
ago. I'm seeing some minor issues with this and lots of bogus warnings as far as 
I can see.

If I suspend/resume and unload e1000, then reinsert e1000.ko, I immediately hit 
the WARN_ON at `msi.c:516: WARN_ON(!hlist_empty(&dev->saved_cap_space));`

I'm not sure that's useful debugging information. even though saved state exists 
the module has been removed, so you might want to purge the state table when the 
driver gets removed?


anyway, back to testing.

Auke

> 
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 01869b1..5113913 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -613,6 +613,7 @@ int pci_enable_msi(struct pci_dev* dev)
>  		return -EINVAL;
>  
>  	WARN_ON(!!dev->msi_enabled);
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
>  
>  	/* Check whether driver already requested for MSI-X irqs */
>  	if (dev->msix_enabled) {
> @@ -638,6 +639,8 @@ void pci_disable_msi(struct pci_dev* dev)
>  	if (!dev->msi_enabled)
>  		return;
>  
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
> +
>  	msi_set_enable(dev, 0);
>  	pci_intx(dev, 1);		/* enable intx */
>  	dev->msi_enabled = 0;
> @@ -739,6 +742,7 @@ int pci_enable_msix(struct pci_dev* dev, struct msix_entry *entries, int nvec)
>  		}
>  	}
>  	WARN_ON(!!dev->msix_enabled);
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
>  
>  	/* Check whether driver already requested for MSI irq */
>     	if (dev->msi_enabled) {
> @@ -763,6 +767,8 @@ void pci_disable_msix(struct pci_dev* dev)
>  	if (!dev->msix_enabled)
>  		return;
>  
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
> +
>  	msix_set_enable(dev, 0);
>  	pci_intx(dev, 1);		/* enable intx */
>  	dev->msix_enabled = 0;
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index bd44a48..4418839 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -677,6 +677,7 @@ pci_restore_state(struct pci_dev *dev)
>  	}
>  	pci_restore_pcix_state(dev);
>  	pci_restore_msi_state(dev);
> +	WARN_ON(!hlist_empty(&dev->saved_cap_space));
>  
>  	return 0;
>  }

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Kok, Auke" <auke-jan.h.kok@intel.com> writes:

> Eric W. Biederman wrote:
>
> [CHOP]
>
>> Below is an additional set of warnings that should help debug this.
>> The old code just got lucky that it triggered a warning when this happens.
>
>
> I'm trying this patch together with the other 2 that you sent out a few days
> ago. I'm seeing some minor issues with this and lots of bogus warnings as far as
> I can see.
>
> If I suspend/resume and unload e1000, then reinsert e1000.ko, I immediately hit
> the WARN_ON at `msi.c:516: WARN_ON(!hlist_empty(&dev->saved_cap_space));`
>
> I'm not sure that's useful debugging information. even though saved state exists
> the module has been removed, so you might want to purge the state table when the
> driver gets removed?
>
>
> anyway, back to testing.

Sorry I should have been clear.

With the last two patches I sent out:
pci: Repair pci_save/restore_state so we can restore one save many times.
msi: Safer state caching.

Those WARN_ON's are now totally bogus.  

In essence the WARN_ON's were testing to ensure pci_save_state and
pci_restore_state were paired.

The assumptions was that pci_restore_state would remove everything
from the list that pci_save_state placed on it.

When I reworked the code and removed the bogus pairing requirement it meant
that if we ever save state and have a pci-e or pci-x capability we will have
a state structure on the list until the kernel reboots. 

In summary:
pci_save_state and pci_restore_state were making a wrong assumption
about the world.  The WARN_ON patch tested to ensure the world matched
those functions.  When I fixed those functions to match the world the
WARN_ON's became completely bogus.

Eric

Re: SATA resume slowness, e1000 MSI warning

[Eric W. Biederman]

"Kok, Auke" <auke-jan.h.kok@intel.com> writes:

> Eric W. Biederman wrote:
>
> [CHOP]
>
>> Below is an additional set of warnings that should help debug this.
>> The old code just got lucky that it triggered a warning when this happens.
>
>
> I'm trying this patch together with the other 2 that you sent out a few days
> ago. I'm seeing some minor issues with this and lots of bogus warnings as far as
> I can see.
>
> If I suspend/resume and unload e1000, then reinsert e1000.ko, I immediately hit
> the WARN_ON at `msi.c:516: WARN_ON(!hlist_empty(&dev->saved_cap_space));`
>
> I'm not sure that's useful debugging information. even though saved state exists
> the module has been removed, so you might want to purge the state table when the
> driver gets removed?
>
>
> anyway, back to testing.

Sorry I should have been clear.

With the last two patches I sent out:
pci: Repair pci_save/restore_state so we can restore one save many times.
msi: Safer state caching.

Those WARN_ON's are now totally bogus.  

In essence the WARN_ON's were testing to ensure pci_save_state and
pci_restore_state were paired.

The assumptions was that pci_restore_state would remove everything
from the list that pci_save_state placed on it.

When I reworked the code and removed the bogus pairing requirement it meant
that if we ever save state and have a pci-e or pci-x capability we will have
a state structure on the list until the kernel reboots. 

In summary:
pci_save_state and pci_restore_state were making a wrong assumption
about the world.  The WARN_ON patch tested to ensure the world matched
those functions.  When I fixed those functions to match the world the
WARN_ON's became completely bogus.

Eric

Re: SATA resume slowness, e1000 MSI warning

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> with real resume it takes even longer time - but i dont see where the 
> delays come from in that case - i suspect it's SATA.

update: Thomas' PIT/HPET resume-fix patch fixed the delay for me.

	Ingo

Re: SATA resume slowness, e1000 MSI warning

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> with real resume it takes even longer time - but i dont see where the 
> delays come from in that case - i suspect it's SATA.

update: Thomas' PIT/HPET resume-fix patch fixed the delay for me.

	Ingo

Re: SATA resume slowness, e1000 MSI warning

[Thomas Gleixner]

On Mon, 2007-03-05 at 11:11 +0100, Ingo Molnar wrote:
> the spin-up takes a few seconds here under suspend/resume simulation:
> 
>  | ata1: waiting for device to spin up (7 secs)
>  | Restarting tasks ... done.
> 
>  [5-10 seconds pass]
> 
>  | ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>  | ata1.00: configured for UDMA/100
>  | SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
>  | sda: Write Protect is off
>  | sda: Mode Sense: 00 3a 00 00
>  | SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> 
> with real resume it takes even longer time - but i dont see where the 
> delays come from in that case - i suspect it's SATA.

SATA has another nice feature. Somehow there is an interrupt pending on
the SATA controller, which comes in somewhere in the middle of resume.
If it happens before the SATA code resumed, the SATA code ignores the
interrupt and the interrupt is disabled due to "nobody cared", which in
turn prevents SATA to ever become functional again.

Any idea on that one ?

	tglx

Re: SATA resume slowness, e1000 MSI warning

[Thomas Gleixner]

On Mon, 2007-03-05 at 11:11 +0100, Ingo Molnar wrote:
> the spin-up takes a few seconds here under suspend/resume simulation:
> 
>  | ata1: waiting for device to spin up (7 secs)
>  | Restarting tasks ... done.
> 
>  [5-10 seconds pass]
> 
>  | ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>  | ata1.00: configured for UDMA/100
>  | SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
>  | sda: Write Protect is off
>  | sda: Mode Sense: 00 3a 00 00
>  | SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> 
> with real resume it takes even longer time - but i dont see where the 
> delays come from in that case - i suspect it's SATA.

SATA has another nice feature. Somehow there is an interrupt pending on
the SATA controller, which comes in somewhere in the middle of resume.
If it happens before the SATA code resumed, the SATA code ignores the
interrupt and the interrupt is disabled due to "nobody cared", which in
turn prevents SATA to ever become functional again.

Any idea on that one ?

	tglx

Re: SATA resume slowness, e1000 MSI warning

[Linus Torvalds]

On Tue, 6 Mar 2007, Thomas Gleixner wrote:
> 
> SATA has another nice feature. Somehow there is an interrupt pending on
> the SATA controller, which comes in somewhere in the middle of resume.
> If it happens before the SATA code resumed, the SATA code ignores the
> interrupt and the interrupt is disabled due to "nobody cared", which in
> turn prevents SATA to ever become functional again.

Jeff - that sounds like a SATA bug.

If you have an interrupt handler registered, you'd better handle the 
interrupt regardless of whether you think the hardware might be gone or 
not.

It's generally *not* ok to do

	if (device_offline())
		return IRQ_NONE;

at the top of an interrupt handler. 

Of course, if you think the hardware is supposed to be quiescent, then the 
only thing you should do is generally just do the "shut up" operation (ie 
read status, write it back or whatever). You must generally *not* try to 
pass any data upwards (ie if the higher layers have told you to shut up, 
you may need to handle the hardware, but you must not involve the higher 
layers themselves any more, because they expect you to be quiet).

And if you cannot do that because you need to resume in order to have the 
status register mapped, then you need to have an "early_resume()" function 
which gets called *before* interrupts are enabled. That's what 
early-resume (and late-suspend) are designed for: doing things that happen 
very early in the resume sequence before everything is up.

And if you don't want to do any of these things (or are unable to, because 
of some ordering constraint or bad design), then you simply need to 
unregister and re-register the interrupt handler over sleep.

> Any idea on that one ?

Jeff, Auke, does this ring any bells?

		Linus

Re: SATA resume slowness, e1000 MSI warning

[Linus Torvalds]

On Tue, 6 Mar 2007, Thomas Gleixner wrote:
> 
> SATA has another nice feature. Somehow there is an interrupt pending on
> the SATA controller, which comes in somewhere in the middle of resume.
> If it happens before the SATA code resumed, the SATA code ignores the
> interrupt and the interrupt is disabled due to "nobody cared", which in
> turn prevents SATA to ever become functional again.

Jeff - that sounds like a SATA bug.

If you have an interrupt handler registered, you'd better handle the 
interrupt regardless of whether you think the hardware might be gone or 
not.

It's generally *not* ok to do

	if (device_offline())
		return IRQ_NONE;

at the top of an interrupt handler. 

Of course, if you think the hardware is supposed to be quiescent, then the 
only thing you should do is generally just do the "shut up" operation (ie 
read status, write it back or whatever). You must generally *not* try to 
pass any data upwards (ie if the higher layers have told you to shut up, 
you may need to handle the hardware, but you must not involve the higher 
layers themselves any more, because they expect you to be quiet).

And if you cannot do that because you need to resume in order to have the 
status register mapped, then you need to have an "early_resume()" function 
which gets called *before* interrupts are enabled. That's what 
early-resume (and late-suspend) are designed for: doing things that happen 
very early in the resume sequence before everything is up.

And if you don't want to do any of these things (or are unable to, because 
of some ordering constraint or bad design), then you simply need to 
unregister and re-register the interrupt handler over sleep.

> Any idea on that one ?

Jeff, Auke, does this ring any bells?

		Linus

Re: SATA resume slowness, e1000 MSI warning

[Kok, Auke]

Linus Torvalds wrote:
> 
> On Tue, 6 Mar 2007, Thomas Gleixner wrote:
>> SATA has another nice feature. Somehow there is an interrupt pending on
>> the SATA controller, which comes in somewhere in the middle of resume.
>> If it happens before the SATA code resumed, the SATA code ignores the
>> interrupt and the interrupt is disabled due to "nobody cared", which in
>> turn prevents SATA to ever become functional again. >

> And if you don't want to do any of these things (or are unable to, because 
> of some ordering constraint or bad design), then you simply need to 
> unregister and re-register the interrupt handler over sleep.
> 
>> Any idea on that one ?
> 
> Jeff, Auke, does this ring any bells?

For the e1000 issue, the problem is solved with Eric Biederman's 3-patch msi 
cleanups. You should have another message in your mailbox confirming that I 
tested his patches and the MSI warning for e1000 suspend-resume is gone with them.

Cheers,

Auke

Re: SATA resume slowness, e1000 MSI warning

[Kok, Auke]

Linus Torvalds wrote:
> 
> On Tue, 6 Mar 2007, Thomas Gleixner wrote:
>> SATA has another nice feature. Somehow there is an interrupt pending on
>> the SATA controller, which comes in somewhere in the middle of resume.
>> If it happens before the SATA code resumed, the SATA code ignores the
>> interrupt and the interrupt is disabled due to "nobody cared", which in
>> turn prevents SATA to ever become functional again. >

> And if you don't want to do any of these things (or are unable to, because 
> of some ordering constraint or bad design), then you simply need to 
> unregister and re-register the interrupt handler over sleep.
> 
>> Any idea on that one ?
> 
> Jeff, Auke, does this ring any bells?

For the e1000 issue, the problem is solved with Eric Biederman's 3-patch msi 
cleanups. You should have another message in your mailbox confirming that I 
tested his patches and the MSI warning for e1000 suspend-resume is gone with them.

Cheers,

Auke

Re: [linux-pm] 2.6.21-rc1: known regressions (part 2)

[Pavel Machek]

Hi!

> Pavel, I tried with your .config, and indeed the system came back to life after
> 2-3 minutes after I press Fn/F4, indeed the issue seems to be with the disk.
> It could be that the same takes place with my original .config - maybe
> I just wasn't patient enough. I'll need to re-test that.
> 
> However, I noticed that, after resume, when the system is presumably functional,
> if I try to suspend to ram again, this second suspend hangs, displaying
> the following on screen:
> 
> [   17.170000] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20
> [   17.170000] PCI: Setting latency timer of device 0000:02:00.0 to 64
> [   17.250000] e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:41:5
> 4:6c:47
> [   17.330000] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
> 
> the crescent LED starts blinking and does not seem to stop for at lest 10 min,
> I've run out of patience after that. It could be that it's just very slow again.
> 
> Pavel, did you try suspend to RAM after a successfull resume from
> RAM?

Seems to work ok in -rc3... as long as I do not mix s2ram with s2disk.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.21-rc1: known regressions (part 2)

[Pavel Machek]

Hi!

> Pavel, I tried with your .config, and indeed the system came back to life after
> 2-3 minutes after I press Fn/F4, indeed the issue seems to be with the disk.
> It could be that the same takes place with my original .config - maybe
> I just wasn't patient enough. I'll need to re-test that.
> 
> However, I noticed that, after resume, when the system is presumably functional,
> if I try to suspend to ram again, this second suspend hangs, displaying
> the following on screen:
> 
> [   17.170000] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20
> [   17.170000] PCI: Setting latency timer of device 0000:02:00.0 to 64
> [   17.250000] e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:41:5
> 4:6c:47
> [   17.330000] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
> 
> the crescent LED starts blinking and does not seem to stop for at lest 10 min,
> I've run out of patience after that. It could be that it's just very slow again.
> 
> Pavel, did you try suspend to RAM after a successfull resume from
> RAM?

Seems to work ok in -rc3... as long as I do not mix s2ram with s2disk.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.21-rc1: known regressions (part 2)

[Michael S. Tsirkin]

> Quoting Ingo Molnar <mingo@elte.hu>:
> Subject: Re: 2.6.21-rc1: known regressions (part 2)
> 
> 
> * Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
> 
> update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and 
> 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt 
> to bisect this.

f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, too.

-- 
MST

Re: 2.6.21-rc1: known regressions (part 2)

[Michael S. Tsirkin]

> Quoting Ingo Molnar <mingo@elte.hu>:
> Subject: Re: 2.6.21-rc1: known regressions (part 2)
> 
> 
> * Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, [...]
> 
> update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and 
> 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt 
> to bisect this.

f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, too.

-- 
MST

Re: 2.6.21-rc1: known regressions (part 2)

[Adrian Bunk]

On Tue, Feb 27, 2007 at 11:02:02AM +0100, Jens Axboe wrote:
> On Sun, Feb 25 2007, Adrian Bunk wrote:
> > This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> > that are not yet fixed in Linus' tree.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way possibly
> > involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
> >              (CONFIG_NO_HZ)
> > References : http://lkml.org/lkml/2007/2/22/391
> > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> >              Thomas Gleixner <tglx@linutronix.de>
> > Handled-By : Ingo Molnar <mingo@elte.hu>
> > Status     : unknown
> 
> x60 doesn't resume from S2R either, it doesn't matter if CONFIG_NO_HZ is
> set or not though. 2.6.20 worked fine.

Is this

Subject    : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
             Ingo Molnar <mingo@elte.hu>
Handled-By : Ingo Molnar <mingo@elte.hu>
Status     : unknown

or doesn't it resume at all?

> Jens Axboe

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.21-rc1: known regressions (part 2)

[Adrian Bunk]

On Tue, Feb 27, 2007 at 11:02:02AM +0100, Jens Axboe wrote:
> On Sun, Feb 25 2007, Adrian Bunk wrote:
> > This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> > that are not yet fixed in Linus' tree.
> > 
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way possibly
> > involved with one or more of these issues.
> > 
> > Due to the huge amount of recipients, please trim the Cc when answering.
> > 
> > 
> > Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
> >              (CONFIG_NO_HZ)
> > References : http://lkml.org/lkml/2007/2/22/391
> > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> >              Thomas Gleixner <tglx@linutronix.de>
> > Handled-By : Ingo Molnar <mingo@elte.hu>
> > Status     : unknown
> 
> x60 doesn't resume from S2R either, it doesn't matter if CONFIG_NO_HZ is
> set or not though. 2.6.20 worked fine.

Is this

Subject    : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
             Ingo Molnar <mingo@elte.hu>
Handled-By : Ingo Molnar <mingo@elte.hu>
Status     : unknown

or doesn't it resume at all?

> Jens Axboe

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.21-rc1: known regressions (part 2)

[Jens Axboe]

On Tue, Feb 27 2007, Adrian Bunk wrote:
> On Tue, Feb 27, 2007 at 11:02:02AM +0100, Jens Axboe wrote:
> > On Sun, Feb 25 2007, Adrian Bunk wrote:
> > > This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> > > that are not yet fixed in Linus' tree.
> > > 
> > > If you find your name in the Cc header, you are either submitter of one
> > > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > > of you caused a breakage or I'm considering you in any other way possibly
> > > involved with one or more of these issues.
> > > 
> > > Due to the huge amount of recipients, please trim the Cc when answering.
> > > 
> > > 
> > > Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
> > >              (CONFIG_NO_HZ)
> > > References : http://lkml.org/lkml/2007/2/22/391
> > > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> > >              Thomas Gleixner <tglx@linutronix.de>
> > > Handled-By : Ingo Molnar <mingo@elte.hu>
> > > Status     : unknown
> > 
> > x60 doesn't resume from S2R either, it doesn't matter if CONFIG_NO_HZ is
> > set or not though. 2.6.20 worked fine.
> 
> Is this
> 
> Subject    : ThinkPad T60: no screen after suspend to RAM
> References : http://lkml.org/lkml/2007/2/22/391
> Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
>              Ingo Molnar <mingo@elte.hu>
> Handled-By : Ingo Molnar <mingo@elte.hu>
> Status     : unknown
> 
> or doesn't it resume at all?

It doesn't resume at all.

-- 
Jens Axboe

Re: 2.6.21-rc1: known regressions (part 2)

[Jens Axboe]

On Tue, Feb 27 2007, Adrian Bunk wrote:
> On Tue, Feb 27, 2007 at 11:02:02AM +0100, Jens Axboe wrote:
> > On Sun, Feb 25 2007, Adrian Bunk wrote:
> > > This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> > > that are not yet fixed in Linus' tree.
> > > 
> > > If you find your name in the Cc header, you are either submitter of one
> > > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > > of you caused a breakage or I'm considering you in any other way possibly
> > > involved with one or more of these issues.
> > > 
> > > Due to the huge amount of recipients, please trim the Cc when answering.
> > > 
> > > 
> > > Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
> > >              (CONFIG_NO_HZ)
> > > References : http://lkml.org/lkml/2007/2/22/391
> > > Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> > >              Thomas Gleixner <tglx@linutronix.de>
> > > Handled-By : Ingo Molnar <mingo@elte.hu>
> > > Status     : unknown
> > 
> > x60 doesn't resume from S2R either, it doesn't matter if CONFIG_NO_HZ is
> > set or not though. 2.6.20 worked fine.
> 
> Is this
> 
> Subject    : ThinkPad T60: no screen after suspend to RAM
> References : http://lkml.org/lkml/2007/2/22/391
> Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
>              Ingo Molnar <mingo@elte.hu>
> Handled-By : Ingo Molnar <mingo@elte.hu>
> Status     : unknown
> 
> or doesn't it resume at all?

It doesn't resume at all.

-- 
Jens Axboe

2.6.21-rc1: known regressions (part 3)

[Adrian Bunk]

This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : forcedeth: skb_over_panic
References : http://bugzilla.kernel.org/show_bug.cgi?id=8058
Submitter  : Albert Hopkins <kernel@marduk.letterboxes.org>
Status     : unknown


Subject    : natsemi ethernet card not detected correctly
References : http://lkml.org/lkml/2007/2/23/4
             http://lkml.org/lkml/2007/2/23/7
Submitter  : Bob Tracy <rct@gherkin.frus.com>
Caused-By  : Mark Brown <broonie@sirena.org.uk>
Handled-By : Mark Brown <broonie@sirena.org.uk>
Patch      : http://lkml.org/lkml/2007/2/23/142
Status     : patch available


Subject    : request_module: runaway loop modprobe net-pf-1
References : http://lkml.org/lkml/2007/2/21/206
Submitter  : YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
Caused-By  : Kay Sievers <kay.sievers@vrfy.org>
             commit c353c3fb0700a3c17ea2b0237710a184232ccd7f
Handled-By : Greg KH <greg@kroah.com>
Status     : problem is being discussed


Subject    : IPV6=m, SUNRPC=y compile error
References : http://bugzilla.kernel.org/show_bug.cgi?id=8050
             http://lkml.org/lkml/2007/2/12/442
             http://lkml.org/lkml/2007/2/20/384
Submitter  : Michael-Luke Jones <mlj28@cam.ac.uk>
             Pete Clements <clem@clem.clem-digital.net>
             Sid Boyce <g3vbv@blueyonder.co.uk>
Caused-By  : Chuck Lever <chuck.lever@oracle.com>
Handled-By : YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org>
Status     : patch available


Subject    : WARNING: "compat_agp_ioctl" undefined!
References : http://lkml.org/lkml/2007/2/21/272
Submitter  : Andreas Schwab <schwab@suse.de>
Handled-By : Dave Jones <davej@redhat.com>
Status     : patch available

Re: 2.6.21-rc1: known regressions (part 3)

[Greg KH]

On Sun, Feb 25, 2007 at 07:02:51PM +0100, Adrian Bunk wrote:
> 
> 
> Subject    : request_module: runaway loop modprobe net-pf-1
> References : http://lkml.org/lkml/2007/2/21/206
> Submitter  : YOSHIFUJI Hideaki / ???????????? <yoshfuji@linux-ipv6.org>
> Caused-By  : Kay Sievers <kay.sievers@vrfy.org>
>              commit c353c3fb0700a3c17ea2b0237710a184232ccd7f
> Handled-By : Greg KH <greg@kroah.com>
> Status     : problem is being discussed

Patch has been reverted and submitted to Linus to pull, but he's out of
town right now...

thanks,

greg k-h

2.6.21-rc1: known regressions (v2) (part 1)

[Adrian Bunk]

This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : resume: slab error in verify_redzone_free(): cache `size-512':
                     memory outside object was overwritten
References : http://lkml.org/lkml/2007/2/24/41
Submitter  : Pavel Machek <pavel@ucw.cz>
Handled-By : Marcel Holtmann <marcel@holtmann.org>
Status     : unknown


Subject    : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Ingo Molnar <mingo@elte.hu>
Status     : unknown


Subject    : HP nx6325 notebook: usb mouse stops working after suspend to ram
References : http://lkml.org/lkml/2007/2/21/413
Submitter  : Arkadiusz Miskiewicz <arekm@maven.pl>
Caused-By  : Konstantin Karasyov <konstantin.a.karasyov@intel.com>
             commit 0a6139027f3986162233adc17285151e78b39cac
Status     : unknown


Subject    : ACPI update breaks kpowersave
References : http://lkml.org/lkml/2007/2/10/7
Submitter  : Ismail Dönmez <ismail@pardus.org.tr>
             Fabio Comolli <fabio.comolli@gmail.com>
Status     : unknown


Subject    : MacBook: AE_NOT_FOUND ACPI messages
References : http://bugzilla.kernel.org/show_bug.cgi?id=8066
Submitter  : Thomas Meyer <thomas.mey@web.de>
Status     : unknown


Subject    : Asus A8N-VM motherboard:
             framebuffer/console boot failure boot failure (ACPI related)
References : http://lkml.org/lkml/2007/2/23/132
Submitter  : Andrew Nelless <andrew@nelless.net>
Handled-By : Antonino A. Daplas <adaplas@gmail.com>
Status     : problem is being debugged


Subject    : Asus M6Ne notebook: ACPI: First battery is not detected
References : http://bugzilla.kernel.org/show_bug.cgi?id=8080
Submitter  : Janosch Machowinski <jmachowinski@gmx.de>
Status     : unknown


Subject    : Asus M6Ne/M6A notebooks: SATA_ACPI errors during kernel boot
References : http://bugzilla.kernel.org/show_bug.cgi?id=8080
             http://bugzilla.kernel.org/show_bug.cgi?id=8046
Submitter  : Janosch Machowinski <jmachowinski@gmx.de>
             Lukas Hejtmanek <xhejtman@fi.muni.cz>
Status     : unknown


Subject    : ata-piix ACPI errors (40/80 pin cable mix)
References : http://lkml.org/lkml/2007/2/22/159
Submitter  : Meelis Roos <mroos@linux.ee>
Status     : unknown


Subject    : libata: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294
             http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html
Submitter  : Fabio Comolli <fabio.comolli@gmail.com>
Handled-By : Tejun Heo <htejun@gmail.com>
Status     : problem is being discussed


Subject    : sata_via failure
References : http://bugzilla.kernel.org/show_bug.cgi?id=8025
Submitter  : Jean-Luc Coulon <jean.luc.coulon@gmail.com>
             Markus Trippelsdorf <markus@trippelsdorf.de>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://www.mail-archive.com/linux-ide@vger.kernel.org/msg03945.html
Status     : patch available


Subject    : BUG: at drivers/pci/pci.c:817 pcim_enable_device() (libata)
References : http://lkml.org/lkml/2007/2/14/275
             http://lkml.org/lkml/2007/2/22/367
Submitter  : Rafael J. Wysocki <rjw@sisk.pl>
             Lukas Hejtmanek <xhejtman@mail.muni.cz>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://lkml.org/lkml/2007/2/25/102
Status     : patch available


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

2.6.21-rc1: known regressions (v2) (part 1)

[Adrian Bunk]

This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : resume: slab error in verify_redzone_free(): cache `size-512':
                     memory outside object was overwritten
References : http://lkml.org/lkml/2007/2/24/41
Submitter  : Pavel Machek <pavel@ucw.cz>
Handled-By : Marcel Holtmann <marcel@holtmann.org>
Status     : unknown


Subject    : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Ingo Molnar <mingo@elte.hu>
Status     : unknown


Subject    : HP nx6325 notebook: usb mouse stops working after suspend to ram
References : http://lkml.org/lkml/2007/2/21/413
Submitter  : Arkadiusz Miskiewicz <arekm@maven.pl>
Caused-By  : Konstantin Karasyov <konstantin.a.karasyov@intel.com>
             commit 0a6139027f3986162233adc17285151e78b39cac
Status     : unknown


Subject    : ACPI update breaks kpowersave
References : http://lkml.org/lkml/2007/2/10/7
Submitter  : Ismail Dönmez <ismail@pardus.org.tr>
             Fabio Comolli <fabio.comolli@gmail.com>
Status     : unknown


Subject    : MacBook: AE_NOT_FOUND ACPI messages
References : http://bugzilla.kernel.org/show_bug.cgi?id=8066
Submitter  : Thomas Meyer <thomas.mey@web.de>
Status     : unknown


Subject    : Asus A8N-VM motherboard:
             framebuffer/console boot failure boot failure (ACPI related)
References : http://lkml.org/lkml/2007/2/23/132
Submitter  : Andrew Nelless <andrew@nelless.net>
Handled-By : Antonino A. Daplas <adaplas@gmail.com>
Status     : problem is being debugged


Subject    : Asus M6Ne notebook: ACPI: First battery is not detected
References : http://bugzilla.kernel.org/show_bug.cgi?id=8080
Submitter  : Janosch Machowinski <jmachowinski@gmx.de>
Status     : unknown


Subject    : Asus M6Ne/M6A notebooks: SATA_ACPI errors during kernel boot
References : http://bugzilla.kernel.org/show_bug.cgi?id=8080
             http://bugzilla.kernel.org/show_bug.cgi?id=8046
Submitter  : Janosch Machowinski <jmachowinski@gmx.de>
             Lukas Hejtmanek <xhejtman@fi.muni.cz>
Status     : unknown


Subject    : ata-piix ACPI errors (40/80 pin cable mix)
References : http://lkml.org/lkml/2007/2/22/159
Submitter  : Meelis Roos <mroos@linux.ee>
Status     : unknown


Subject    : libata: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294
             http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html
Submitter  : Fabio Comolli <fabio.comolli@gmail.com>
Handled-By : Tejun Heo <htejun@gmail.com>
Status     : problem is being discussed


Subject    : sata_via failure
References : http://bugzilla.kernel.org/show_bug.cgi?id=8025
Submitter  : Jean-Luc Coulon <jean.luc.coulon@gmail.com>
             Markus Trippelsdorf <markus@trippelsdorf.de>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://www.mail-archive.com/linux-ide@vger.kernel.org/msg03945.html
Status     : patch available


Subject    : BUG: at drivers/pci/pci.c:817 pcim_enable_device() (libata)
References : http://lkml.org/lkml/2007/2/14/275
             http://lkml.org/lkml/2007/2/22/367
Submitter  : Rafael J. Wysocki <rjw@sisk.pl>
             Lukas Hejtmanek <xhejtman@mail.muni.cz>
Handled-By : Tejun Heo <htejun@gmail.com>
Patch      : http://lkml.org/lkml/2007/2/25/102
Status     : patch available

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Sergio Monteiro Basto]

[-- Attachment #1.1: Type: text/plain, Size: 354 bytes --]

On Mon, 2007-02-26 at 23:01 +0100, Adrian Bunk wrote:
> Subject    : MacBook: AE_NOT_FOUND ACPI messages
> References : http://bugzilla.kernel.org/show_bug.cgi?id=8066
> Submitter  : Thomas Meyer <thomas.mey@web.de>
> Status     : unknown 

I think , Messages is not a regression 
Appears AE_NOT_FOUND messages could be good 

-- 
Sérgio M.B.

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2192 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[S.Çağlar Onur]

[-- Attachment #1.1: Type: text/plain, Size: 998 bytes --]

27 Şub 2007 Sal tarihinde, Adrian Bunk şunları yazmıştı: 
> This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> that are not yet fixed in Linus' tree.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a patch
> of you caused a breakage or I'm considering you in any other way possibly
> involved with one or more of these issues.
...
> Subject    : ACPI update breaks kpowersave
> References : http://lkml.org/lkml/2007/2/10/7
> Submitter  : Ismail Dönmez <ismail@pardus.org.tr>
>              Fabio Comolli <fabio.comolli@gmail.com>
> Status     : unknown

That regression fixed by c2b6705b75d9c7aff98a4602a32230639e10891c according to 
İsmail [1] 

[1] http://lkml.org/lkml/2007/2/13/105
-- 
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Ismail Dönmez]

On Tuesday 27 February 2007 14:50:17 S.Çağlar Onur wrote:
> 27 Şub 2007 Sal tarihinde, Adrian Bunk şunları yazmıştı:
> > This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
> > that are not yet fixed in Linus' tree.
> >
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, maintainer of an affectected subsystem or driver, a patch
> > of you caused a breakage or I'm considering you in any other way possibly
> > involved with one or more of these issues.
>
> ...
>
> > Subject    : ACPI update breaks kpowersave
> > References : http://lkml.org/lkml/2007/2/10/7
> > Submitter  : Ismail Dönmez <ismail@pardus.org.tr>
> >              Fabio Comolli <fabio.comolli@gmail.com>
> > Status     : unknown
>
> That regression fixed by c2b6705b75d9c7aff98a4602a32230639e10891c according
> to İsmail [1]
>
> [1] http://lkml.org/lkml/2007/2/13/105

Not quite, my laptop died the same day. So I can't do any reliable test. Also 
Fabio seems to reproduce it with 2.6.21-rc1.

Regards,
ismail


-- 
In God We Trust Others We Monitor

_______________________________________________
linux-pm mailing list
linux-pm@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/linux-pm

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[S.Çağlar Onur]

[-- Attachment #1.1: Type: text/plain, Size: 960 bytes --]

27 Şub 2007 Sal tarihinde, Fabio Comolli şunları yazmıştı: 
> Confirmed, although the problem I see is probably different from
> Ismael's one: in my case /proc/acpi/adapter/AC is present but
> kpowersave does not work (it works in 2.6.20).
>
> The only file I seem to be missing is /proc/acpi/info, but I don't
> know it is important or not.

Then these problems are not same, İsmail's problem was an ACPI one and im sure 
that solved but yours seems a userspace problem (hal checks /proc/acpi/info 
and kpowersave uses hal) introduced by "/proc/acpi/info deprecated 
by /sys/firmware/acpi/info" [1]. You can try untested attached patch against 
hal-git tree, so i'm adding hal list into CC also.

[1] http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg04285.html
-- 
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!

[-- Attachment #1.2: hal_acpi.patch --]
[-- Type: text/x-diff, Size: 1286 bytes --]

diff --git a/hald/linux/acpi.c b/hald/linux/acpi.c
index 30e5fdf..1714627 100644
--- a/hald/linux/acpi.c
+++ b/hald/linux/acpi.c
@@ -1055,7 +1055,7 @@ acpi_synthesize_hotplug_events (void)
 	HalDevice *computer;
 	gchar path[HAL_PATH_MAX];
 
-	if (!g_file_test ("/proc/acpi/info", G_FILE_TEST_EXISTS))
+	if (!g_file_test ("/proc/acpi/", G_FILE_TEST_IS_DIR))
 		return FALSE;
 
 	if ((computer = hal_device_store_find (hald_get_gdl (), "/org/freedesktop/Hal/devices/computer")) == NULL &&
@@ -1066,8 +1066,14 @@ acpi_synthesize_hotplug_events (void)
 
 	/* Set appropriate properties on the computer object */
 	hal_device_property_set_string (computer, "power_management.type", "acpi");
-	hal_util_set_string_elem_from_file (computer, "power_management.acpi.linux.version",
+	if (g_file_test ("/proc/acpi/info", G_FILE_TEST_EXISTS)) {
+		hal_util_set_string_elem_from_file (computer, "power_management.acpi.linux.version",
 					    "/proc/acpi", "info", "version", 0, FALSE);
+	}
+	else {
+		hal_util_set_string_elem_from_file (computer, "power_management.acpi.linux.version",
+					    "%s/firmware/acpi", sysfs_path, "info", "version", 0, FALSE);
+	}
 
 	/* collect batteries */
 	snprintf (path, sizeof (path), "%s/acpi/battery", get_hal_proc_path ());

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[S.Çağlar Onur]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

27 Şub 2007 Sal tarihinde, S.Çağlar Onur şunları yazmıştı: 
> 27 Şub 2007 Sal tarihinde, Fabio Comolli şunları yazmıştı:
> > Confirmed, although the problem I see is probably different from
> > Ismael's one: in my case /proc/acpi/adapter/AC is present but
> > kpowersave does not work (it works in 2.6.20).
> >
> > The only file I seem to be missing is /proc/acpi/info, but I don't
> > know it is important or not.
>
> Then these problems are not same, İsmail's problem was an ACPI one and im
> sure that solved but yours seems a userspace problem (hal checks
> /proc/acpi/info and kpowersave uses hal) introduced by "/proc/acpi/info
> deprecated by /sys/firmware/acpi/info" [1]. You can try untested attached
> patch against hal-git tree, so i'm adding hal list into CC also.
>
> [1] http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg04285.html

Try that one (thas one at least compiles :P) [1] instead of previous one 
please...

[1] http://cekirdek.pardus.org.tr/~caglar/hal_acpi.patch
-- 
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Meelis Roos]

> Subject    : ata-piix ACPI errors (40/80 pin cable mix)
> References : http://lkml.org/lkml/2007/2/22/159
> Submitter  : Meelis Roos <mroos@linux.ee>
> Status     : unknown

Still appears, but this does not seem to be 40/80 pin cable problem to 
be but rather ata-piix calling some acpi methods and this rulsts in acpi 
errors.

-- 
Meelis Roos (mroos@linux.ee)

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Alan]

On Tue, 27 Feb 2007 15:00:29 +0200 (EET)
Meelis Roos <mroos@linux.ee> wrote:

> > Subject    : ata-piix ACPI errors (40/80 pin cable mix)
> > References : http://lkml.org/lkml/2007/2/22/159
> > Submitter  : Meelis Roos <mroos@linux.ee>
> > Status     : unknown
> 
> Still appears, but this does not seem to be 40/80 pin cable problem to 
> be but rather ata-piix calling some acpi methods and this rulsts in acpi 
> errors.

There are two separate problems showing up in the one trace - broken ACPI
spew and wrong cable detect. I don't think they are related

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Michael S. Tsirkin]

>Subject    : ThinkPad T60: no screen after suspend to RAM
>References : http://lkml.org/lkml/2007/2/22/391
>Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
>Handled-By : Ingo Molnar <mingo@elte.hu>
>Status     : unknown

Just reproduced this in -rc2.
Another thing I noticed:
with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.

On 2.6.21-rc2, after resume (when the box is accessible from network),
pressing Fn/F4 again does not seem to have any effect.


-- 
MST

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Thomas Gleixner]

On Wed, 2007-02-28 at 23:13 +0200, Michael S. Tsirkin wrote:
> >Subject    : ThinkPad T60: no screen after suspend to RAM
> >References : http://lkml.org/lkml/2007/2/22/391
> >Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
> >Handled-By : Ingo Molnar <mingo@elte.hu>
> >Status     : unknown
> 
> Just reproduced this in -rc2.
> Another thing I noticed:
> with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
> 
> On 2.6.21-rc2, after resume (when the box is accessible from network),
> pressing Fn/F4 again does not seem to have any effect.

Can you please get the dmesg output after resume via the network ?

	tglx

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Michael S. Tsirkin]

>Quoting Thomas Gleixner <tglx@linutronix.de>:
>Subject: Re: 2.6.21-rc1: known regressions (v2) (part 1)
>
>On Wed, 2007-02-28 at 23:13 +0200, Michael S. Tsirkin wrote:
>> >Subject    : ThinkPad T60: no screen after suspend to RAM
>> >References : http://lkml.org/lkml/2007/2/22/391
>> >Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
>> >Handled-By : Ingo Molnar <mingo@elte.hu>
>> >Status     : unknown
>> 
>> Just reproduced this in -rc2.
>> Another thing I noticed:
>> with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
>> 
>> On 2.6.21-rc2, after resume (when the box is accessible from network),
>> pressing Fn/F4 again does not seem to have any effect.
>
>Can you please get the dmesg output after resume via the network ?

The link above has it.

-- 
MST

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Michael S. Tsirkin]

>Quoting Thomas Gleixner <tglx@linutronix.de>:
>Subject: Re: 2.6.21-rc1: known regressions (v2) (part 1)
>
>On Wed, 2007-02-28 at 23:13 +0200, Michael S. Tsirkin wrote:
>> >Subject    : ThinkPad T60: no screen after suspend to RAM
>> >References : http://lkml.org/lkml/2007/2/22/391
>> >Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
>> >Handled-By : Ingo Molnar <mingo@elte.hu>
>> >Status     : unknown
>> 
>> Just reproduced this in -rc2.
>> Another thing I noticed:
>> with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
>> 
>> On 2.6.21-rc2, after resume (when the box is accessible from network),
>> pressing Fn/F4 again does not seem to have any effect.
>
>Can you please get the dmesg output after resume via the network ?

The link above has it.

-- 
MST

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Jeff Chua]

On 3/1/07, Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
>
> On 2.6.21-rc2, after resume (when the box is accessible from network),
> pressing Fn/F4 again does not seem to have any effect.

I have the same problem on my IBM X60s on rc1 and rc2. Can't resume
from RAM, can't suspend to disk. It is possible to revert all the
changes to ACPI and test it?

Jeff.

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Jeff Chua]

On 3/1/07, Michael S. Tsirkin <mst@mellanox.co.il> wrote:

> with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
>
> On 2.6.21-rc2, after resume (when the box is accessible from network),
> pressing Fn/F4 again does not seem to have any effect.

I have the same problem on my IBM X60s on rc1 and rc2. Can't resume
from RAM, can't suspend to disk. It is possible to revert all the
changes to ACPI and test it?

Jeff.

Re: [linux-pm] 2.6.21-rc1: known regressions (v2) (part 1)

[Pavel Machek]

On Thu 2007-03-01 11:45:35, Jeff Chua wrote:
> On 3/1/07, Michael S. Tsirkin <mst@mellanox.co.il> wrote:
> 
> > with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
> >
> > On 2.6.21-rc2, after resume (when the box is accessible from network),
> > pressing Fn/F4 again does not seem to have any effect.
> 
> I have the same problem on my IBM X60s on rc1 and rc2. Can't resume
> from RAM, can't suspend to disk. It is possible to revert all the
> changes to ACPI and test it?

As I said elsewhere in the thread, suspend/resume to RAM works ok on
my thinkpad x60. I posted my .config there, perhaps difference is in
it? Ingo identified KVM as possible culprit.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] 2.6.21-rc1: known regressions (v2) (part 1)

[Jens Axboe]

On Fri, Mar 02 2007, Pavel Machek wrote:
> On Thu 2007-03-01 11:45:35, Jeff Chua wrote:
> > On 3/1/07, Michael S. Tsirkin <mst@mellanox.co.il> wrote:
> > 
> > > with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
> > >
> > > On 2.6.21-rc2, after resume (when the box is accessible from network),
> > > pressing Fn/F4 again does not seem to have any effect.
> > 
> > I have the same problem on my IBM X60s on rc1 and rc2. Can't resume
> > from RAM, can't suspend to disk. It is possible to revert all the
> > changes to ACPI and test it?
> 
> As I said elsewhere in the thread, suspend/resume to RAM works ok on
> my thinkpad x60. I posted my .config there, perhaps difference is in
> it? Ingo identified KVM as possible culprit.

I'll try your .config for kicks, the problem that Ingo pin pointed is
not what is affecting me.

-- 
Jens Axboe

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Adrian Bunk]

On Thu, Mar 01, 2007 at 11:45:35AM +0800, Jeff Chua wrote:
> On 3/1/07, Michael S. Tsirkin <mst@mellanox.co.il> wrote:
> 
> >with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend 
> >to RAM.
> >
> >On 2.6.21-rc2, after resume (when the box is accessible from network),
> >pressing Fn/F4 again does not seem to have any effect.
> 
> I have the same problem on my IBM X60s on rc1 and rc2. Can't resume
> from RAM, can't suspend to disk. It is possible to revert all the
> changes to ACPI and test it?

This is with CONFIG_KVM=n?

> Jeff.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Jeff Chua]

On 3/5/07, Adrian Bunk <bunk@stusta.de> wrote:

> > I have the same problem on my IBM X60s on rc1 and rc2. Can't resume
> > from RAM, can't suspend to disk. It is possible to revert all the
> > changes to ACPI and test it?
>
> This is with CONFIG_KVM=n?

Yes.

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Jeff Chua]

On 3/6/07, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
> On 3/5/07, Adrian Bunk <bunk@stusta.de> wrote:
>
> > > I have the same problem on my IBM X60s on rc1 and rc2. Can't resume
> > > from RAM, can't suspend to disk. It is possible to revert all the
> > > changes to ACPI and test it?
> >
> > This is with CONFIG_KVM=n?
>
> Yes.

I've tried with CONFIG_KVM=n and CONFIG_KVM=y and both does not suspend.

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Michael S. Tsirkin]

> Quoting Jeff Chua <jeff.chua.linux@gmail.com>:
> Subject: Re: 2.6.21-rc1: known regressions (v2) (part 1)
> 
> On 3/6/07, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
> > On 3/5/07, Adrian Bunk <bunk@stusta.de> wrote:
> >
> > > > I have the same problem on my IBM X60s on rc1 and rc2. Can't resume
> > > > from RAM, can't suspend to disk. It is possible to revert all the
> > > > changes to ACPI and test it?
> > >
> > > This is with CONFIG_KVM=n?
> >
> > Yes.
> 
> I've tried with CONFIG_KVM=n and CONFIG_KVM=y and both does not suspend.

Do you mean that they "do not resume after suspend"?

-- 
MST

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Michael S. Tsirkin]

> Quoting Jeff Chua <jeff.chua.linux@gmail.com>:
> Subject: Re: 2.6.21-rc1: known regressions (v2) (part 1)
> 
> On 3/6/07, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
> > On 3/5/07, Adrian Bunk <bunk@stusta.de> wrote:
> >
> > > > I have the same problem on my IBM X60s on rc1 and rc2. Can't resume
> > > > from RAM, can't suspend to disk. It is possible to revert all the
> > > > changes to ACPI and test it?
> > >
> > > This is with CONFIG_KVM=n?
> >
> > Yes.
> 
> I've tried with CONFIG_KVM=n and CONFIG_KVM=y and both does not suspend.

Do you mean that they "do not resume after suspend"?

-- 
MST

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Jeff Chua]

On 3/6/07, Michael S. Tsirkin <mst@mellanox.co.il> wrote:
> > Quoting Jeff Chua <jeff.chua.linux@gmail.com>:
> > Subject: Re: 2.6.21-rc1: known regressions (v2) (part 1)
> >
> > On 3/6/07, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
> > > On 3/5/07, Adrian Bunk <bunk@stusta.de> wrote:
> > >
> > > > > I have the same problem on my IBM X60s on rc1 and rc2. Can't resume
> > > > > from RAM, can't suspend to disk. It is possible to revert all the
> > > > > changes to ACPI and test it?
> > > >
> > > > This is with CONFIG_KVM=n?
> > >
> > > Yes.
> >
> > I've tried with CONFIG_KVM=n and CONFIG_KVM=y and both does not suspend.
>
> Do you mean that they "do not resume after suspend"?

I can't even suspend to disk/ram. It just hangs and the lights just
blink and everything else hangs. With 2.6.20, it works fine.

Jeff.

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Pavel Machek]

> >> > > > I have the same problem on my IBM X60s on rc1 and rc2. Can't resume
> >> > > > from RAM, can't suspend to disk. It is possible to revert all the
> >> > > > changes to ACPI and test it?
> >> > >
> >> > > This is with CONFIG_KVM=n?
> >> >
> >> > Yes.
> >>
> >> I've tried with CONFIG_KVM=n and CONFIG_KVM=y and both does not suspend.
> >
> >Do you mean that they "do not resume after suspend"?
> 
> I can't even suspend to disk/ram. It just hangs and the lights just
> blink and everything else hangs. With 2.6.20, it works fine.

Turn up console loglevel, and see where it hangs...

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.21-rc1: known regressions (v2) (part 1)

[Rafael J. Wysocki]

On Monday, 19 March 2007 16:32, Pavel Machek wrote:
> 
> > >> > > > I have the same problem on my IBM X60s on rc1 and rc2. Can't resume
> > >> > > > from RAM, can't suspend to disk. It is possible to revert all the
> > >> > > > changes to ACPI and test it?
> > >> > >
> > >> > > This is with CONFIG_KVM=n?
> > >> >
> > >> > Yes.
> > >>
> > >> I've tried with CONFIG_KVM=n and CONFIG_KVM=y and both does not suspend.
> > >
> > >Do you mean that they "do not resume after suspend"?
> > 
> > I can't even suspend to disk/ram. It just hangs and the lights just
> > blink and everything else hangs. With 2.6.20, it works fine.
> 
> Turn up console loglevel, and see where it hangs...

I think CONFIG_DISABLE_CONSOLE_SUSPEND would have to be set for this purpose
too.

Greetings,
Rafael

2.6.21-rc1: known regressions (v2) (part 2)

[Adrian Bunk]

This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.

If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.

Due to the huge amount of recipients, please trim the Cc when answering.


Subject    : forcedeth no longer works
References : http://bugzilla.kernel.org/show_bug.cgi?id=8090
Submitter  : David P. Reed <dpreed@reed.com>
Caused-By  : Ayaz Abdulla <aabdulla@nvidia.com>
Status     : unknown


Subject    : forcedeth: skb_over_panic
References : http://bugzilla.kernel.org/show_bug.cgi?id=8058
Submitter  : Albert Hopkins <kernel@marduk.letterboxes.org>
Status     : unknown


Subject    : natsemi ethernet card not detected correctly
References : http://lkml.org/lkml/2007/2/23/4
             http://lkml.org/lkml/2007/2/23/7
Submitter  : Bob Tracy <rct@gherkin.frus.com>
Caused-By  : Mark Brown <broonie@sirena.org.uk>
Handled-By : Mark Brown <broonie@sirena.org.uk>
Patch      : http://lkml.org/lkml/2007/2/23/142
Status     : patch available


Subject    : ThinkPad T60: system doesn't come out of suspend to RAM
             (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter  : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
Status     : unknown


Subject    : kernel BUG at kernel/time/tick-sched.c:168  (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged


Subject    : BUG: soft lockup detected on CPU#0
             NOHZ: local_softirq_pending 20  (SMT scheduler)
References : http://lkml.org/lkml/2007/2/20/257
Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
             Ingo Molnar <mingo@elte.hu>
Status     : problem is being debugged


Subject    : i386: no boot with nmi_watchdog=1  (clockevents)
References : http://lkml.org/lkml/2007/2/21/208
Submitter  : Daniel Walker <dwalker@mvista.com>
Caused-By  : Thomas Gleixner <tglx@linutronix.de>
             commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status     : problem is being debugged

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Thomas Gleixner]

Adrian,

On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
> Subject    : kernel BUG at kernel/time/tick-sched.c:168  (CONFIG_NO_HZ)
> References : http://lkml.org/lkml/2007/2/16/346
> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> Status     : problem is being debugged

The BUG_ON() was replaced by a warning printk(). The BUG_ON() exposed a
problem with the SMT scheduler. See below.

> Subject    : BUG: soft lockup detected on CPU#0
>              NOHZ: local_softirq_pending 20  (SMT scheduler)
> References : http://lkml.org/lkml/2007/2/20/257
> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> Handled-By : Thomas Gleixner <tglx@linutronix.de>
>              Ingo Molnar <mingo@elte.hu>
> Status     : problem is being debugged

Patch available, not confirmed yet.

	tglx

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Michal Piotrowski]

Thomas Gleixner napisał(a):
> Adrian,
> 
> On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
>> Subject    : kernel BUG at kernel/time/tick-sched.c:168  (CONFIG_NO_HZ)
>> References : http://lkml.org/lkml/2007/2/16/346
>> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
>> Handled-By : Thomas Gleixner <tglx@linutronix.de>
>> Status     : problem is being debugged
> 
> The BUG_ON() was replaced by a warning printk(). The BUG_ON() exposed a
> problem with the SMT scheduler. See below.
> 
>> Subject    : BUG: soft lockup detected on CPU#0
>>              NOHZ: local_softirq_pending 20  (SMT scheduler)
>> References : http://lkml.org/lkml/2007/2/20/257
>> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
>> Handled-By : Thomas Gleixner <tglx@linutronix.de>
>>              Ingo Molnar <mingo@elte.hu>
>> Status     : problem is being debugged
> 
> Patch available, not confirmed yet.
> 

I can confirm that the bug is fixed (over 20 hours of testing should be enough).

Huge thanks!

Regards,
Michal

-- 
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Ingo Molnar]

* Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:

> Thomas Gleixner napisał(a):
> > Adrian,
> > 
> > On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
> >> Subject    : kernel BUG at kernel/time/tick-sched.c:168  (CONFIG_NO_HZ)
> >> References : http://lkml.org/lkml/2007/2/16/346
> >> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> >> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> >> Status     : problem is being debugged
> > 
> > The BUG_ON() was replaced by a warning printk(). The BUG_ON() exposed a
> > problem with the SMT scheduler. See below.
> > 
> >> Subject    : BUG: soft lockup detected on CPU#0
> >>              NOHZ: local_softirq_pending 20  (SMT scheduler)
> >> References : http://lkml.org/lkml/2007/2/20/257
> >> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> >> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> >>              Ingo Molnar <mingo@elte.hu>
> >> Status     : problem is being debugged
> > 
> > Patch available, not confirmed yet.
> > 
> 
> I can confirm that the bug is fixed (over 20 hours of testing should 
> be enough).

thanks alot! I think this thing was a long-term performance/latency 
regression in HT scheduling as well.

	Ingo

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Mike Galbraith]

On Tue, 2007-02-27 at 09:33 +0100, Ingo Molnar wrote:
> * Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> 
> > Thomas Gleixner napisał(a):
> > > Adrian,
> > > 
> > > On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
> > >> Subject    : kernel BUG at kernel/time/tick-sched.c:168  (CONFIG_NO_HZ)
> > >> References : http://lkml.org/lkml/2007/2/16/346
> > >> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> > >> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> > >> Status     : problem is being debugged
> > > 
> > > The BUG_ON() was replaced by a warning printk(). The BUG_ON() exposed a
> > > problem with the SMT scheduler. See below.
> > > 
> > >> Subject    : BUG: soft lockup detected on CPU#0
> > >>              NOHZ: local_softirq_pending 20  (SMT scheduler)
> > >> References : http://lkml.org/lkml/2007/2/20/257
> > >> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> > >> Handled-By : Thomas Gleixner <tglx@linutronix.de>
> > >>              Ingo Molnar <mingo@elte.hu>
> > >> Status     : problem is being debugged
> > > 
> > > Patch available, not confirmed yet.
> > > 
> > 
> > I can confirm that the bug is fixed (over 20 hours of testing should 
> > be enough).
> 
> thanks alot! I think this thing was a long-term performance/latency 
> regression in HT scheduling as well.

Agreed.

I was recently looking at that spot because I found that niced tasks
were taking latency hits, and disabled it, which helped a bunch.  I also
can't understand why it would be OK to interleave a normal task with an
RT task sometimes, but not others.. that's meaningless to the RT task.

IMHO, SMT scheduling should be a buyer beware thing.  Maximizing your
core utilization comes at a price, but so does disabling it, so I think
letting the user decide what he wants is the right thing to do.

	-Mike

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Con Kolivas]

Apologies for the resend, lkml address got mangled...

On Tuesday 27 February 2007 19:54, Mike Galbraith wrote:
> On Tue, 2007-02-27 at 09:33 +0100, Ingo Molnar wrote:
> > * Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote:
> > > Thomas Gleixner napisał(a):
> > > > Adrian,
> > > >
> > > > On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
> > > >> Subject    : kernel BUG at kernel/time/tick-sched.c:168 
> > > >> (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/16/346
> > > >> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
> > > I can confirm that the bug is fixed (over 20 hours of testing should
> > > be enough).
> >
> > thanks alot! I think this thing was a long-term performance/latency
> > regression in HT scheduling as well.

Ingo I'm going to have to partially disagree with you on this. 

This has only become a problem because of what happens with dynticks now when 
rq->curr == rq->idle. Prior to this, that particular SMT code only leads to 
relative delays in scheduling for lower priority tasks. Whether or not that 
task is ksoftirqd should not matter because it is not like they are starved 
indefinitely, it is only that nice 19 tasks are relatively delayed, which by 
definition is implied with the usage of nice as a scheduler hint wouldn't you 
say? I know it has been discussed many times before as to whether 'nice' 
means less cpu and/or more latency, but in our current implementation, nice 
means both less cpu and more latency. So to me, the kernels without dynticks 
do not have a regression. This seems to only be a problem in the setting of 
the new dynticks code IMHO. That's not to say it isn't a bug! Nor am I saying 
that dynticks is a problem! Please don't misinterpret that.

The second issue is that this is a problem because of the fuzzy definition of 
what idle is for a runqueue in the setting of this SMT code. Normally, 
rq->curr==rq->idle means the runqueue is idle, but not with this code since 
there are still rq->nr_running on that runqueue. What dynticks in this 
implementation is doing is trying to idle a hyperthread sibling on a cpu 
whose logical partner is busy. I did not find that added any power saving on 
my earlier dynticks implementation, and found it easier to keep that sibling 
ticking at the same rate as its partner. Of course you may have found 
something different, and I definitely agree with what you are likely to say 
in response to this- we shouldn't have to special case logical siblings as 
having a different definition of idle than any other smp case. Ultimately, 
that leaves us with your simple patch as a reasonable solution for the 
dynticks case even though it does change the behaviour dramatically for a 
more loaded cpu. I don't see this code as presenting a problem without or 
prior to the dynticks implementation. You being the scheduler maintainer 
means you get to choose what is the best way to tackle this problem. 

> Agreed.
>
> I was recently looking at that spot because I found that niced tasks
> were taking latency hits, and disabled it, which helped a bunch.

Ok... as I said above to Ingo, nice means more latency too, and there is no 
doubt that if we disable nice as a working feature then the niced tasks will 
have less latency. Of course, this ends up meaning that un-niced tasks no 
longer receive their better cpu performance..  You're basically saying that 
you prefer nice not to work in the setting of HT.

> I also 
> can't understand why it would be OK to interleave a normal task with an
> RT task sometimes, but not others.. that's meaningless to the RT task.

Clearly there would be a reason that code is there... The whole problem with 
HT is that as soon as you load up a sibling, you slow down the logical 
sibling, hence why this code is there in the first place. Since I know you're 
one to test things for yourself, I will put it to you this way:

Boot into UP. Time how long it takes to do a million of these in a real time 
task:
 asm volatile("" : : : "memory");

Then start up a SCHED_NORMAL task fully cpu bound such as "yes > /dev/null" 
and time that again. Obviously the former being a realtime task will take the 
same amount of time and the SCHED_NORMAL task will be starved until the 
realtime task finishes.

Now try the same experiment with hyperthreading enabled and an ordinary SMP 
kernel. You'll find the realtime task runs at only ~60% performance. That's a 
serious performance hit for realtime tasks considering you're running a 
SCHED_NORMAL task. The SMT code that you seem to dislike fixes this problem. 
The reason for interleaving is that there are a few cycles to be gained by 
using the second core for a separate SCHED_NORMAL task, and you don't want to 
disable access to the second core entirely for the duration the realtime task 
is running. Since there is no simple relationship between SCHED_NORMAL 
timeslices and realtime timeslices, we have to use some form of interleaving 
based on the expected extra cycles and HZ is the obvious choice.

> IMHO, SMT scheduling should be a buyer beware thing.  Maximizing your
> core utilization comes at a price, but so does disabling it, so I think
> letting the user decide what he wants is the right thing to do.

To me this is like arguing that we should not implement 'nice' within the cpu 
scheduler at all and only allow nice to work on the few architectures that 
support hardware priorities in the cpu (like power5). Now there is no doubt 
that if we do away with nice entirely everywhere in the scheduler we'll gain 
some throughput. However, nice is a basic unix/linux function and if hardware 
comes along that breaks it working we should be working to make sure that it 
keeps working in software. That is why smt nice and smp nice was implemented. 
Of course it is our duty to ensure we do that at minimal overhead at all 
times. That's a different argument to what you are debating here. The 
throughput should not be adversely affected by this SMT priority code because 
although the nice 19 task gets less throughput, the higher priority task gets 
more as a result, which is essentially what nice is meant to do.

-- 
-ck

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Mike Galbraith]

(hrmph.  having to copy/paste/try again.  evolution seems to be broken..
RCPT TO <linux-kernel@vg.kolivas.org> failed: Cannot resolve your domain {mp049}
..caused me to be unable to send despite receipts being disabled)

On Wed, 2007-02-28 at 09:58 +1100, Con Kolivas wrote:
> On Tuesday 27 February 2007 19:54, Mike Galbraith wrote:

> > Agreed.
> >
> > I was recently looking at that spot because I found that niced tasks
> > were taking latency hits, and disabled it, which helped a bunch.
> 
> Ok... as I said above to Ingo, nice means more latency too, and there is no 
> doubt that if we disable nice as a working feature then the niced tasks will 
> have less latency. Of course, this ends up meaning that un-niced tasks no 
> longer receive their better cpu performance..  You're basically saying that 
> you prefer nice not to work in the setting of HT.

No I'm not, but let's go further in that direction just for the sake of
argument.  You're then saying that you prefer realtime priorities to not
work in the HT setting, given that realtime tasks don't participate in
the 'single stream me' program.
 
I'm saying only that we're defeating the purpose of HT, and overriding a
user decision every time we force a sibling idle.

> > I also 
> > can't understand why it would be OK to interleave a normal task with an
> > RT task sometimes, but not others.. that's meaningless to the RT task.
> 
> Clearly there would be a reason that code is there... The whole problem with 
> HT is that as soon as you load up a sibling, you slow down the logical 
> sibling, hence why this code is there in the first place. Since I know you're 
> one to test things for yourself, I will put it to you this way:
> 
> Boot into UP. Time how long it takes to do a million of these in a real time 
> task:
>  asm volatile("" : : : "memory");
> 
> Then start up a SCHED_NORMAL task fully cpu bound such as "yes > /dev/null" 
> and time that again. Obviously the former being a realtime task will take the 
> same amount of time and the SCHED_NORMAL task will be starved until the 
> realtime task finishes.

Sure.

> Now try the same experiment with hyperthreading enabled and an ordinary SMP 
> kernel. You'll find the realtime task runs at only ~60% performance.

So?  User asked for HT.  That's hardware multiplexing. It ain't free.
Buyer beware.

>  That's a 
> serious performance hit for realtime tasks considering you're running a 
> SCHED_NORMAL task. The SMT code that you seem to dislike fixes this problem.

I don't think it does actually. Let your RT task sleep regularly, and
ever so briefly.  We don't evict lower priority tasks from siblings upon
wakeup, we only prevent entry... sometimes.
 
> The reason for interleaving is that there are a few cycles to be gained by 
> using the second core for a separate SCHED_NORMAL task, and you don't want to 
> disable access to the second core entirely for the duration the realtime task 
> is running. Since there is no simple relationship between SCHED_NORMAL 
> timeslices and realtime timeslices, we have to use some form of interleaving 
> based on the expected extra cycles and HZ is the obvious choice.

To me, the reason for interleaving is solely about keeping the core
busy .  It has nothing to do with SCHED_POLICY_X what so ever.

> > IMHO, SMT scheduling should be a buyer beware thing.  Maximizing your
> > core utilization comes at a price, but so does disabling it, so I think
> > letting the user decide what he wants is the right thing to do.
> 
> To me this is like arguing that we should not implement 'nice' within the cpu 
> scheduler at all and only allow nice to work on the few architectures that 
> support hardware priorities in the cpu (like power5). Now there is no doubt 
> that if we do away with nice entirely everywhere in the scheduler we'll gain 
> some throughput. However, nice is a basic unix/linux function and if hardware 
> comes along that breaks it working we should be working to make sure that it 
> keeps working in software. That is why smt nice and smp nice was implemented. 
> Of course it is our duty to ensure we do that at minimal overhead at all 
> times. That's a different argument to what you are debating here. The 
> throughput should not be adversely affected by this SMT priority code because 
> although the nice 19 task gets less throughput, the higher priority task gets 
> more as a result, which is essentially what nice is meant to do.

Re-read this paragraph with realtime task priorities in mind, or for
that matter, dynamic priorities.  If you carry your priority/throughput
argument to it's logical conclusion, only instruction streams of
absolutely equal priority should be able to share the core at any given
time.  You may as well just disable HT and be done with it.

To me, siblings are logically separate units, and should be treated as
such (as they mostly are).  They share an important resource, but so do
physically discrete units.

	-Mike

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Con Kolivas]

On Wednesday 28 February 2007 15:21, Mike Galbraith wrote:
> (hrmph.  having to copy/paste/try again.  evolution seems to be broken..
> RCPT TO <linux-kernel@vg.kolivas.org> failed: Cannot resolve your domain
> {mp049} ..caused me to be unable to send despite receipts being disabled)

Apologies for mangling the email address as I said :-(

> On Wed, 2007-02-28 at 09:58 +1100, Con Kolivas wrote:
> > On Tuesday 27 February 2007 19:54, Mike Galbraith wrote:
> > > Agreed.
> > >
> > > I was recently looking at that spot because I found that niced tasks
> > > were taking latency hits, and disabled it, which helped a bunch.
> >
> > Ok... as I said above to Ingo, nice means more latency too, and there is
> > no doubt that if we disable nice as a working feature then the niced
> > tasks will have less latency. Of course, this ends up meaning that
> > un-niced tasks no longer receive their better cpu performance..  You're
> > basically saying that you prefer nice not to work in the setting of HT.
>
> No I'm not, but let's go further in that direction just for the sake of
> argument.  You're then saying that you prefer realtime priorities to not
> work in the HT setting, given that realtime tasks don't participate in
> the 'single stream me' program.

Where do I say that? I do not presume to manage realtime priorities in any 
way. You're turning my argument about nice levels around and somehow saying 
that because hyperthreading breaks the single stream me semantics by 
parallelising them that I would want to stop that happening. Nowhere have I 
argued that realtime semantics should be changed to somehow work around 
hyperthreading. SMT nice is about managing nice only, and not realtime 
priorities which are independent entities.

> I'm saying only that we're defeating the purpose of HT, and overriding a
> user decision every time we force a sibling idle.
>
> > > I also
> > > can't understand why it would be OK to interleave a normal task with an
> > > RT task sometimes, but not others.. that's meaningless to the RT task.
> >
> > Clearly there would be a reason that code is there... The whole problem
> > with HT is that as soon as you load up a sibling, you slow down the
> > logical sibling, hence why this code is there in the first place. Since I
> > know you're one to test things for yourself, I will put it to you this
> > way:
> >
> > Boot into UP. Time how long it takes to do a million of these in a real
> > time task:
> >  asm volatile("" : : : "memory");
> >
> > Then start up a SCHED_NORMAL task fully cpu bound such as "yes >
> > /dev/null" and time that again. Obviously the former being a realtime
> > task will take the same amount of time and the SCHED_NORMAL task will be
> > starved until the realtime task finishes.
>
> Sure.
>
> > Now try the same experiment with hyperthreading enabled and an ordinary
> > SMP kernel. You'll find the realtime task runs at only ~60% performance.
>
> So?  User asked for HT.  That's hardware multiplexing. It ain't free.
> Buyer beware.

But the buyer is not aware. You are aware because you tinker, but the vast 
majority of users who enable hyperthreading in their shiny pcs are not aware. 
The only thing they know is that if they enable hyperthreading their programs 
run slower in multitasking environments no matter how much they nice the 
other processes. Buyers do not buy hardware knowing that the internal design 
breaks something as fundamental as 'nice'. You seem to presume that most 
people who get hyperthreading are happy to compromise 'nice' in order to get 
their second core working and I put it to you that they do not make that 
decision.

> >  That's a
> > serious performance hit for realtime tasks considering you're running a
> > SCHED_NORMAL task. The SMT code that you seem to dislike fixes this
> > problem.
>
> I don't think it does actually. Let your RT task sleep regularly, and
> ever so briefly.  We don't evict lower priority tasks from siblings upon
> wakeup, we only prevent entry... sometimes.

Well you know as well as I do that you're selecting out the exception rather 
than the rule, and statistically overall, it does work.

> > The reason for interleaving is that there are a few cycles to be gained
> > by using the second core for a separate SCHED_NORMAL task, and you don't
> > want to disable access to the second core entirely for the duration the
> > realtime task is running. Since there is no simple relationship between
> > SCHED_NORMAL timeslices and realtime timeslices, we have to use some form
> > of interleaving based on the expected extra cycles and HZ is the obvious
> > choice.
>
> To me, the reason for interleaving is solely about keeping the core
> busy .  It has nothing to do with SCHED_POLICY_X what so ever.
>
> > > IMHO, SMT scheduling should be a buyer beware thing.  Maximizing your
> > > core utilization comes at a price, but so does disabling it, so I think
> > > letting the user decide what he wants is the right thing to do.
> >
> > To me this is like arguing that we should not implement 'nice' within the
> > cpu scheduler at all and only allow nice to work on the few architectures
> > that support hardware priorities in the cpu (like power5). Now there is
> > no doubt that if we do away with nice entirely everywhere in the
> > scheduler we'll gain some throughput. However, nice is a basic unix/linux
> > function and if hardware comes along that breaks it working we should be
> > working to make sure that it keeps working in software. That is why smt
> > nice and smp nice was implemented. Of course it is our duty to ensure we
> > do that at minimal overhead at all times. That's a different argument to
> > what you are debating here. The throughput should not be adversely
> > affected by this SMT priority code because although the nice 19 task gets
> > less throughput, the higher priority task gets more as a result, which is
> > essentially what nice is meant to do.
>
> Re-read this paragraph with realtime task priorities in mind, or for
> that matter, dynamic priorities.  If you carry your priority/throughput
> argument to it's logical conclusion, only instruction streams of
> absolutely equal priority should be able to share the core at any given
> time.  You may as well just disable HT and be done with it.

Well that's certainly taking my logic for a ride. This is about managing 
_nice_ and _only_ nice. Nice specifies fixed interval static priorities where 
(in the risk of repeating myself) you are specifying that higher nice values 
tasks you wish to receive less cpu and more latency. Dynamic priorities have 
absolutely no effect on what the discrepancies are between the static 
priorities of differing nice values. As for realtime priorities, again, I do 
not presume to be managing them with SMT nice. They are unique entities 
unrelated to nice values. The only thing they have in common with nice levels 
is that if something is running without a realtime priority, it should be 
preempted by the realtime task as you have specified that the realtime task 
should receive all the cpu over the non-realtime task. I don't pretend that 
there is some cpu percentage relationship between different _realtime 
priorities_ and do not try to manage them in any way.

> To me, siblings are logically separate units, and should be treated as
> such (as they mostly are).  They share an important resource, but so do
> physically discrete units.

Again you're saying here that if the hardware breaks nice levels we should not 
bother trying to enforce them. As I said before, this is an extension of 
arguing that we should not try to enforce nice except on hardware that has 
priority support within the cpu.

We're going to have to agree to disagree, but feel free to have the final word 
of course.

--
-ck
--

'In general this practice is meant to exhaust the opposition in some debate, 
and when they fail to respond, claim the silence as assent, to prevent 
an "unfavorable" conclusion of a debate from being reached by refusing to 
allow the discussion to conclude so long as its conclusion is unfavorable, 
and to discourage future "challenges".' -wli

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Mike Galbraith]

On Thu, 2007-03-01 at 09:01 +1100, Con Kolivas wrote:
> On Wednesday 28 February 2007 15:21, Mike Galbraith wrote:

> > On Wed, 2007-02-28 at 09:58 +1100, Con Kolivas wrote:
> > > On Tuesday 27 February 2007 19:54, Mike Galbraith wrote:
> > > > Agreed.
> > > >
> > > > I was recently looking at that spot because I found that niced tasks
> > > > were taking latency hits, and disabled it, which helped a bunch.
> > >
> > > Ok... as I said above to Ingo, nice means more latency too, and there is
> > > no doubt that if we disable nice as a working feature then the niced
> > > tasks will have less latency. Of course, this ends up meaning that
> > > un-niced tasks no longer receive their better cpu performance..  You're
> > > basically saying that you prefer nice not to work in the setting of HT.
> >
> > No I'm not, but let's go further in that direction just for the sake of
> > argument.  You're then saying that you prefer realtime priorities to not
> > work in the HT setting, given that realtime tasks don't participate in
> > the 'single stream me' program.
> 
> Where do I say that? I do not presume to manage realtime priorities in any 
> way. You're turning my argument about nice levels around and somehow saying 
> that because hyperthreading breaks the single stream me semantics by 
> parallelising them that I would want to stop that happening. Nowhere have I 
> argued that realtime semantics should be changed to somehow work around 
> hyperthreading. SMT nice is about managing nice only, and not realtime 
> priorities which are independent entities.

I see no real difference between the two assertions.  Nice is just a
mechanism to set priority, so I applied your assertion to a different
range of priorities than nice covers, and returned it to show that the
code contradicts itself.  It can't be bad for a nice 1 task to run with
a nice 0 task, but OK for a minimum RT task to run with a maximum RT
task.  Iff HT without corrective measures breaks nice, then it breaks
realtime priorities as well.

> > I'm saying only that we're defeating the purpose of HT, and overriding a
> > user decision every time we force a sibling idle.
> >
> > > > I also
> > > > can't understand why it would be OK to interleave a normal task with an
> > > > RT task sometimes, but not others.. that's meaningless to the RT task.
> > >
> > > Clearly there would be a reason that code is there... The whole problem
> > > with HT is that as soon as you load up a sibling, you slow down the
> > > logical sibling, hence why this code is there in the first place. Since I
> > > know you're one to test things for yourself, I will put it to you this
> > > way:
> > >
> > > Boot into UP. Time how long it takes to do a million of these in a real
> > > time task:
> > >  asm volatile("" : : : "memory");
> > >
> > > Then start up a SCHED_NORMAL task fully cpu bound such as "yes >
> > > /dev/null" and time that again. Obviously the former being a realtime
> > > task will take the same amount of time and the SCHED_NORMAL task will be
> > > starved until the realtime task finishes.
> >
> > Sure.
> >
> > > Now try the same experiment with hyperthreading enabled and an ordinary
> > > SMP kernel. You'll find the realtime task runs at only ~60% performance.
> >
> > So?  User asked for HT.  That's hardware multiplexing. It ain't free.
> > Buyer beware.
> 
> But the buyer is not aware. You are aware because you tinker, but the vast 
> majority of users who enable hyperthreading in their shiny pcs are not aware.

Then we need to make them aware of what they're enabling?
 
> The only thing they know is that if they enable hyperthreading their programs 
> run slower in multitasking environments no matter how much they nice the 
> other processes. Buyers do not buy hardware knowing that the internal design 
> breaks something as fundamental as 'nice'. You seem to presume that most 
> people who get hyperthreading are happy to compromise 'nice' in order to get 
> their second core working and I put it to you that they do not make that 
> decision.

To me it's pretty much black and white.  Either you want to split your
cpu into logical units, which means each has less to offer than the
total, or you want all your processing power in one bucket.

> > >  That's a
> > > serious performance hit for realtime tasks considering you're running a
> > > SCHED_NORMAL task. The SMT code that you seem to dislike fixes this
> > > problem.
> >
> > I don't think it does actually. Let your RT task sleep regularly, and
> > ever so briefly.  We don't evict lower priority tasks from siblings upon
> > wakeup, we only prevent entry... sometimes.
> 
> Well you know as well as I do that you're selecting out the exception rather 
> than the rule, and statistically overall, it does work.

I don't agree that it's the exception, and if you look at this HT thing
from the split cpu perspective, I'm not sure there's even a problem.

Scrolling down, I see that this is getting too long, and we aren't
communicating anyway, so I'll cut it off here.

> We're going to have to agree to disagree, but feel free to have the final word 
> of course.

The above will have to do.

	-Mike

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Ingo Molnar]

* Mike Galbraith <efault@gmx.de> wrote:

> I see no real difference between the two assertions.  Nice is just a 
> mechanism to set priority, so I applied your assertion to a different 
> range of priorities than nice covers, and returned it to show that the 
> code contradicts itself.  It can't be bad for a nice 1 task to run 
> with a nice 0 task, but OK for a minimum RT task to run with a maximum 
> RT task.  Iff HT without corrective measures breaks nice, then it 
> breaks realtime priorities as well.

i'm starting to lean towards your view that we should not artificially 
keep tasks from running, when there's a free CPU available. We should 
still keep the 'other half' of SMT scheduling: the immediate pushing of 
tasks to a related core, but this bit of 'do not run tasks on this CPU' 
dependent-sleeper logic is i think a bit fragile. Plus these days SMT 
siblings do not tend to influence each other in such a negative way as 
older P4 ones where a HT sibling would slow down the other sibling 
significantly.

plus with an increasing number of siblings (which seems like an 
inevitable thing on the hardware side), the dependent-sleeper logic 
becomes less and less scalable. We'd have to cross-check every other 
'related' CPU's current priority to decide what to run.

if then there should be a mechanism /in the hardware/ to set the 
priority of a CPU - and then the hardware could decide how to prioritize 
between siblings. Doing this in software is really hard.

	Ingo

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Con Kolivas]

On Thursday 01 March 2007 19:46, Ingo Molnar wrote:
> * Mike Galbraith <efault@gmx.de> wrote:
> > I see no real difference between the two assertions.  Nice is just a
> > mechanism to set priority, so I applied your assertion to a different
> > range of priorities than nice covers, and returned it to show that the
> > code contradicts itself.  It can't be bad for a nice 1 task to run
> > with a nice 0 task, but OK for a minimum RT task to run with a maximum
> > RT task.  Iff HT without corrective measures breaks nice, then it
> > breaks realtime priorities as well.
>
> i'm starting to lean towards your view that we should not artificially
> keep tasks from running, when there's a free CPU available. We should
> still keep the 'other half' of SMT scheduling: the immediate pushing of
> tasks to a related core, but this bit of 'do not run tasks on this CPU'
> dependent-sleeper logic is i think a bit fragile. Plus these days SMT
> siblings do not tend to influence each other in such a negative way as
> older P4 ones where a HT sibling would slow down the other sibling
> significantly.

Well it is meant to be tuned to the cpu type in per_cpu_gain. So it should be 
easy to be set to the appropriate scaling. It was never meant to be a one 
value fits all as the processors changed.

> plus with an increasing number of siblings (which seems like an
> inevitable thing on the hardware side), the dependent-sleeper logic
> becomes less and less scalable. We'd have to cross-check every other
> 'related' CPU's current priority to decide what to run.

Yes even I've commented before that this current system is unworkable come 
multiple shared power threads. This I do see as a real problem with it - in 
the future.

> if then there should be a mechanism /in the hardware/ to set the
> priority of a CPU - and then the hardware could decide how to prioritize
> between siblings. Doing this in software is really hard.

And that's the depressing part because of course I was interested in that as 
the original approach to the problem (and it was a big problem). When I spoke 
to Intel and AMD (of course to date no SMT AMD chip exists) at kernel summit 
they said it was too hard to implement hardware priorities well. Which is 
real odd since IBM have already done it with Power...

Still I think it has been working fine in software till now, but now it has to 
deal with the added confusion of dynticks, so I already know what will happen 
to it.

Hrm it's been a good time for my code all round... I think I'll just swap 
prefetch myself up the staircase to some pluggable scheduler that would 
hyperthread me to sleep as an idle priority task.

-- 
-ck

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Thomas Gleixner]

On Thu, 2007-03-01 at 22:13 +1100, Con Kolivas wrote:
> > if then there should be a mechanism /in the hardware/ to set the
> > priority of a CPU - and then the hardware could decide how to prioritize
> > between siblings. Doing this in software is really hard.
> 
> And that's the depressing part because of course I was interested in that as 
> the original approach to the problem (and it was a big problem). When I spoke 
> to Intel and AMD (of course to date no SMT AMD chip exists) at kernel summit 
> they said it was too hard to implement hardware priorities well. Which is 
> real odd since IBM have already done it with Power...
> 
> Still I think it has been working fine in software till now, but now it has to 
> deal with the added confusion of dynticks, so I already know what will happen 
> to it.

Well, it's not a dyntick problem in the first place. Even w/o dynticks
we go idle with local_softirq_pending(). Dynticks contains an explicit
check for that, which makes it visible.

	tglx


	

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Con Kolivas]

On Thursday 01 March 2007 22:33, Thomas Gleixner wrote:
> On Thu, 2007-03-01 at 22:13 +1100, Con Kolivas wrote:
> > > if then there should be a mechanism /in the hardware/ to set the
> > > priority of a CPU - and then the hardware could decide how to
> > > prioritize between siblings. Doing this in software is really hard.
> >
> > And that's the depressing part because of course I was interested in that
> > as the original approach to the problem (and it was a big problem). When
> > I spoke to Intel and AMD (of course to date no SMT AMD chip exists) at
> > kernel summit they said it was too hard to implement hardware priorities
> > well. Which is real odd since IBM have already done it with Power...
> >
> > Still I think it has been working fine in software till now, but now it
> > has to deal with the added confusion of dynticks, so I already know what
> > will happen to it.
>
> Well, it's not a dyntick problem in the first place. Even w/o dynticks
> we go idle with local_softirq_pending(). Dynticks contains an explicit
> check for that, which makes it visible.

Oops I'm sorry if I made it sound like there's a dynticks problem. That was 
not my intent and I said as much in an earlier email. Even though I'm finding 
myself defending code that has already been softly tagged for redundancy, 
let's be clear here; we're talking about at most a further 70ms delay in 
scheduling a niced task in the presence of a nice 0 task, which is a 
reasonable delay for ksoftirqd which we nice the eyeballs out of in mainline. 
Considering under load our scheduler has been known to cause scheduling 
delays of 10 seconds I still don't see this as a bug. Dynticks just "points 
it out to us".

-- 
-ck

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Thomas Gleixner]

On Thu, 2007-03-01 at 23:05 +1100, Con Kolivas wrote:
> > > And that's the depressing part because of course I was interested in that
> > > as the original approach to the problem (and it was a big problem). When
> > > I spoke to Intel and AMD (of course to date no SMT AMD chip exists) at
> > > kernel summit they said it was too hard to implement hardware priorities
> > > well. Which is real odd since IBM have already done it with Power...
> > >
> > > Still I think it has been working fine in software till now, but now it
> > > has to deal with the added confusion of dynticks, so I already know what
> > > will happen to it.
> >
> > Well, it's not a dyntick problem in the first place. Even w/o dynticks
> > we go idle with local_softirq_pending(). Dynticks contains an explicit
> > check for that, which makes it visible.
> 
> Oops I'm sorry if I made it sound like there's a dynticks problem. That was 
> not my intent and I said as much in an earlier email. Even though I'm finding 
> myself defending code that has already been softly tagged for redundancy, 
> let's be clear here; we're talking about at most a further 70ms delay in 
> scheduling a niced task in the presence of a nice 0 task, which is a 
> reasonable delay for ksoftirqd which we nice the eyeballs out of in mainline. 
> Considering under load our scheduler has been known to cause scheduling 
> delays of 10 seconds I still don't see this as a bug. Dynticks just "points 
> it out to us".

Well, dyntick might end up to delay it for X seconds as well, which _is_
observable and that's why the check was put there in the first place.

	tglx

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Ingo Molnar]

* Con Kolivas <kernel@kolivas.org> wrote:

> [...] Even though I'm finding myself defending code that has already 
> been softly tagged for redundancy, let's be clear here; we're talking 
> about at most a further 70ms delay in scheduling a niced task in the 
> presence of a nice 0 task, which is a reasonable delay for ksoftirqd 
> which we nice the eyeballs out of in mainline. Considering under load 
> our scheduler has been known to cause scheduling delays of 10 seconds 
> I still don't see this as a bug. Dynticks just "points it out to us".

well, not running softirqs when we could is a bug. It's not a big bug, 
but it's a bug nevertheless. It doesnt matter that softirqs could be 
delayed even worse under high load - there was no 'high load' here.

	Ingo

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Con Kolivas]

On Friday 02 March 2007 00:30, Ingo Molnar wrote:
> * Con Kolivas <kernel@kolivas.org> wrote:
> > [...] Even though I'm finding myself defending code that has already
> > been softly tagged for redundancy, let's be clear here; we're talking
> > about at most a further 70ms delay in scheduling a niced task in the
> > presence of a nice 0 task, which is a reasonable delay for ksoftirqd
> > which we nice the eyeballs out of in mainline. Considering under load
> > our scheduler has been known to cause scheduling delays of 10 seconds
> > I still don't see this as a bug. Dynticks just "points it out to us".
>
> well, not running softirqs when we could is a bug. It's not a big bug,
> but it's a bug nevertheless. It doesnt matter that softirqs could be
> delayed even worse under high load - there was no 'high load' here.

Gotcha. I'll prepare a smt-nice removal patch shortly. 

-- 
-ck

[PATCH] sched: remove SMT nice

[Con Kolivas]

Remove the SMT-nice feature which idles sibling cpus on SMT cpus to
facilitiate nice working properly where cpu power is shared. The idling
of cpus in the presence of runnable tasks is considered too fragile, easy
to break with outside code, and the complexity of managing this system if an
architecture comes along with many logical cores sharing cpu power will be
unworkable.

Remove the associated per_cpu_gain variable in sched_domains used only by
this code.

Signed-off-by: Con Kolivas <kernel@kolivas.org>

---
 include/asm-i386/topology.h           |    1 
 include/asm-ia64/topology.h           |    2 
 include/asm-mips/mach-ip27/topology.h |    1 
 include/asm-powerpc/topology.h        |    1 
 include/asm-x86_64/topology.h         |    1 
 include/linux/sched.h                 |    1 
 include/linux/topology.h              |    4 
 kernel/sched.c                        |  155 ----------------------------------
 8 files changed, 1 insertion(+), 165 deletions(-)

Index: linux-2.6.21-rc2/kernel/sched.c
===================================================================
--- linux-2.6.21-rc2.orig/kernel/sched.c	2007-03-02 08:56:45.000000000 +1100
+++ linux-2.6.21-rc2/kernel/sched.c	2007-03-02 08:58:40.000000000 +1100
@@ -3006,23 +3006,6 @@ static inline void idle_balance(int cpu,
 }
 #endif
 
-static inline void wake_priority_sleeper(struct rq *rq)
-{
-#ifdef CONFIG_SCHED_SMT
-	if (!rq->nr_running)
-		return;
-
-	spin_lock(&rq->lock);
-	/*
-	 * If an SMT sibling task has been put to sleep for priority
-	 * reasons reschedule the idle task to see if it can now run.
-	 */
-	if (rq->nr_running)
-		resched_task(rq->idle);
-	spin_unlock(&rq->lock);
-#endif
-}
-
 DEFINE_PER_CPU(struct kernel_stat, kstat);
 
 EXPORT_PER_CPU_SYMBOL(kstat);
@@ -3239,10 +3222,7 @@ void scheduler_tick(void)
 
 	update_cpu_clock(p, rq, now);
 
-	if (p == rq->idle)
-		/* Task on the idle queue */
-		wake_priority_sleeper(rq);
-	else
+	if (p != rq->idle)
 		task_running_tick(rq, p);
 #ifdef CONFIG_SMP
 	update_load(rq);
@@ -3251,136 +3231,6 @@ void scheduler_tick(void)
 #endif
 }
 
-#ifdef CONFIG_SCHED_SMT
-static inline void wakeup_busy_runqueue(struct rq *rq)
-{
-	/* If an SMT runqueue is sleeping due to priority reasons wake it up */
-	if (rq->curr == rq->idle && rq->nr_running)
-		resched_task(rq->idle);
-}
-
-/*
- * Called with interrupt disabled and this_rq's runqueue locked.
- */
-static void wake_sleeping_dependent(int this_cpu)
-{
-	struct sched_domain *tmp, *sd = NULL;
-	int i;
-
-	for_each_domain(this_cpu, tmp) {
-		if (tmp->flags & SD_SHARE_CPUPOWER) {
-			sd = tmp;
-			break;
-		}
-	}
-
-	if (!sd)
-		return;
-
-	for_each_cpu_mask(i, sd->span) {
-		struct rq *smt_rq = cpu_rq(i);
-
-		if (i == this_cpu)
-			continue;
-		if (unlikely(!spin_trylock(&smt_rq->lock)))
-			continue;
-
-		wakeup_busy_runqueue(smt_rq);
-		spin_unlock(&smt_rq->lock);
-	}
-}
-
-/*
- * number of 'lost' timeslices this task wont be able to fully
- * utilize, if another task runs on a sibling. This models the
- * slowdown effect of other tasks running on siblings:
- */
-static inline unsigned long
-smt_slice(struct task_struct *p, struct sched_domain *sd)
-{
-	return p->time_slice * (100 - sd->per_cpu_gain) / 100;
-}
-
-/*
- * To minimise lock contention and not have to drop this_rq's runlock we only
- * trylock the sibling runqueues and bypass those runqueues if we fail to
- * acquire their lock. As we only trylock the normal locking order does not
- * need to be obeyed.
- */
-static int
-dependent_sleeper(int this_cpu, struct rq *this_rq, struct task_struct *p)
-{
-	struct sched_domain *tmp, *sd = NULL;
-	int ret = 0, i;
-
-	/* kernel/rt threads do not participate in dependent sleeping */
-	if (!p->mm || rt_task(p))
-		return 0;
-
-	for_each_domain(this_cpu, tmp) {
-		if (tmp->flags & SD_SHARE_CPUPOWER) {
-			sd = tmp;
-			break;
-		}
-	}
-
-	if (!sd)
-		return 0;
-
-	for_each_cpu_mask(i, sd->span) {
-		struct task_struct *smt_curr;
-		struct rq *smt_rq;
-
-		if (i == this_cpu)
-			continue;
-
-		smt_rq = cpu_rq(i);
-		if (unlikely(!spin_trylock(&smt_rq->lock)))
-			continue;
-
-		smt_curr = smt_rq->curr;
-
-		if (!smt_curr->mm)
-			goto unlock;
-
-		/*
-		 * If a user task with lower static priority than the
-		 * running task on the SMT sibling is trying to schedule,
-		 * delay it till there is proportionately less timeslice
-		 * left of the sibling task to prevent a lower priority
-		 * task from using an unfair proportion of the
-		 * physical cpu's resources. -ck
-		 */
-		if (rt_task(smt_curr)) {
-			/*
-			 * With real time tasks we run non-rt tasks only
-			 * per_cpu_gain% of the time.
-			 */
-			if ((jiffies % DEF_TIMESLICE) >
-				(sd->per_cpu_gain * DEF_TIMESLICE / 100))
-					ret = 1;
-		} else {
-			if (smt_curr->static_prio < p->static_prio &&
-				!TASK_PREEMPTS_CURR(p, smt_rq) &&
-				smt_slice(smt_curr, sd) > task_timeslice(p))
-					ret = 1;
-		}
-unlock:
-		spin_unlock(&smt_rq->lock);
-	}
-	return ret;
-}
-#else
-static inline void wake_sleeping_dependent(int this_cpu)
-{
-}
-static inline int
-dependent_sleeper(int this_cpu, struct rq *this_rq, struct task_struct *p)
-{
-	return 0;
-}
-#endif
-
 #if defined(CONFIG_PREEMPT) && defined(CONFIG_DEBUG_PREEMPT)
 
 void fastcall add_preempt_count(int val)
@@ -3507,7 +3357,6 @@ need_resched_nonpreemptible:
 		if (!rq->nr_running) {
 			next = rq->idle;
 			rq->expired_timestamp = 0;
-			wake_sleeping_dependent(cpu);
 			goto switch_tasks;
 		}
 	}
@@ -3547,8 +3396,6 @@ need_resched_nonpreemptible:
 		}
 	}
 	next->sleep_type = SLEEP_NORMAL;
-	if (dependent_sleeper(cpu, rq, next))
-		next = rq->idle;
 switch_tasks:
 	if (next == rq->idle)
 		schedstat_inc(rq, sched_goidle);
Index: linux-2.6.21-rc2/include/asm-i386/topology.h
===================================================================
--- linux-2.6.21-rc2.orig/include/asm-i386/topology.h	2007-03-02 09:02:01.000000000 +1100
+++ linux-2.6.21-rc2/include/asm-i386/topology.h	2007-03-02 09:02:58.000000000 +1100
@@ -85,7 +85,6 @@ static inline int node_to_first_cpu(int 
 	.idle_idx		= 1,			\
 	.newidle_idx		= 2,			\
 	.wake_idx		= 1,			\
-	.per_cpu_gain		= 100,			\
 	.flags			= SD_LOAD_BALANCE	\
 				| SD_BALANCE_EXEC	\
 				| SD_BALANCE_FORK	\
Index: linux-2.6.21-rc2/include/asm-ia64/topology.h
===================================================================
--- linux-2.6.21-rc2.orig/include/asm-ia64/topology.h	2007-03-02 09:02:01.000000000 +1100
+++ linux-2.6.21-rc2/include/asm-ia64/topology.h	2007-03-02 09:02:33.000000000 +1100
@@ -65,7 +65,6 @@ void build_cpu_to_node_map(void);
 	.max_interval		= 4,			\
 	.busy_factor		= 64,			\
 	.imbalance_pct		= 125,			\
-	.per_cpu_gain		= 100,			\
 	.cache_nice_tries	= 2,			\
 	.busy_idx		= 2,			\
 	.idle_idx		= 1,			\
@@ -97,7 +96,6 @@ void build_cpu_to_node_map(void);
 	.newidle_idx		= 0, /* unused */	\
 	.wake_idx		= 1,			\
 	.forkexec_idx		= 1,			\
-	.per_cpu_gain		= 100,			\
 	.flags			= SD_LOAD_BALANCE	\
 				| SD_BALANCE_EXEC	\
 				| SD_BALANCE_FORK	\
Index: linux-2.6.21-rc2/include/asm-mips/mach-ip27/topology.h
===================================================================
--- linux-2.6.21-rc2.orig/include/asm-mips/mach-ip27/topology.h	2007-03-02 09:02:01.000000000 +1100
+++ linux-2.6.21-rc2/include/asm-mips/mach-ip27/topology.h	2007-03-02 09:02:38.000000000 +1100
@@ -28,7 +28,6 @@ extern unsigned char __node_distances[MA
 	.busy_factor		= 32,			\
 	.imbalance_pct		= 125,			\
 	.cache_nice_tries	= 1,			\
-	.per_cpu_gain		= 100,			\
 	.flags			= SD_LOAD_BALANCE	\
 				| SD_BALANCE_EXEC	\
 				| SD_WAKE_BALANCE,	\
Index: linux-2.6.21-rc2/include/asm-powerpc/topology.h
===================================================================
--- linux-2.6.21-rc2.orig/include/asm-powerpc/topology.h	2007-03-02 09:02:01.000000000 +1100
+++ linux-2.6.21-rc2/include/asm-powerpc/topology.h	2007-03-02 09:02:44.000000000 +1100
@@ -57,7 +57,6 @@ static inline int pcibus_to_node(struct 
 	.busy_factor		= 32,			\
 	.imbalance_pct		= 125,			\
 	.cache_nice_tries	= 1,			\
-	.per_cpu_gain		= 100,			\
 	.busy_idx		= 3,			\
 	.idle_idx		= 1,			\
 	.newidle_idx		= 2,			\
Index: linux-2.6.21-rc2/include/asm-x86_64/topology.h
===================================================================
--- linux-2.6.21-rc2.orig/include/asm-x86_64/topology.h	2007-03-02 09:02:01.000000000 +1100
+++ linux-2.6.21-rc2/include/asm-x86_64/topology.h	2007-03-02 09:02:50.000000000 +1100
@@ -43,7 +43,6 @@ extern int __node_distance(int, int);
 	.newidle_idx		= 0, 			\
 	.wake_idx		= 1,			\
 	.forkexec_idx		= 1,			\
-	.per_cpu_gain		= 100,			\
 	.flags			= SD_LOAD_BALANCE	\
 				| SD_BALANCE_FORK	\
 				| SD_BALANCE_EXEC	\
Index: linux-2.6.21-rc2/include/linux/sched.h
===================================================================
--- linux-2.6.21-rc2.orig/include/linux/sched.h	2007-03-02 09:02:01.000000000 +1100
+++ linux-2.6.21-rc2/include/linux/sched.h	2007-03-02 09:02:27.000000000 +1100
@@ -684,7 +684,6 @@ struct sched_domain {
 	unsigned int imbalance_pct;	/* No balance until over watermark */
 	unsigned long long cache_hot_time; /* Task considered cache hot (ns) */
 	unsigned int cache_nice_tries;	/* Leave cache hot tasks for # tries */
-	unsigned int per_cpu_gain;	/* CPU % gained by adding domain cpus */
 	unsigned int busy_idx;
 	unsigned int idle_idx;
 	unsigned int newidle_idx;
Index: linux-2.6.21-rc2/include/linux/topology.h
===================================================================
--- linux-2.6.21-rc2.orig/include/linux/topology.h	2007-03-02 09:02:01.000000000 +1100
+++ linux-2.6.21-rc2/include/linux/topology.h	2007-03-02 09:02:19.000000000 +1100
@@ -96,7 +96,6 @@
 	.busy_factor		= 64,			\
 	.imbalance_pct		= 110,			\
 	.cache_nice_tries	= 0,			\
-	.per_cpu_gain		= 25,			\
 	.busy_idx		= 0,			\
 	.idle_idx		= 0,			\
 	.newidle_idx		= 1,			\
@@ -128,7 +127,6 @@
 	.busy_factor		= 64,			\
 	.imbalance_pct		= 125,			\
 	.cache_nice_tries	= 1,			\
-	.per_cpu_gain		= 100,			\
 	.busy_idx		= 2,			\
 	.idle_idx		= 1,			\
 	.newidle_idx		= 2,			\
@@ -159,7 +157,6 @@
 	.busy_factor		= 64,			\
 	.imbalance_pct		= 125,			\
 	.cache_nice_tries	= 1,			\
-	.per_cpu_gain		= 100,			\
 	.busy_idx		= 2,			\
 	.idle_idx		= 1,			\
 	.newidle_idx		= 2,			\
@@ -193,7 +190,6 @@
 	.newidle_idx		= 0, /* unused */	\
 	.wake_idx		= 0, /* unused */	\
 	.forkexec_idx		= 0, /* unused */	\
-	.per_cpu_gain		= 100,			\
 	.flags			= SD_LOAD_BALANCE	\
 				| SD_SERIALIZE,	\
 	.last_balance		= jiffies,		\

-- 
-ck

Re: [PATCH] sched: remove SMT nice

[Con Kolivas]

On Friday 02 March 2007 12:30, Andrew Morton wrote:
> On Fri, 2 Mar 2007 09:33:37 +1100
>
> Con Kolivas <kernel@kolivas.org> wrote:
> > Remove the SMT-nice feature which idles sibling cpus on SMT cpus to
> > facilitiate nice working properly where cpu power is shared. The idling
> > of cpus in the presence of runnable tasks is considered too fragile, easy
> > to break with outside code, and the complexity of managing this system if
> > an architecture comes along with many logical cores sharing cpu power
> > will be unworkable.
> >
> > Remove the associated per_cpu_gain variable in sched_domains used only by
> > this code.
>
> Seems like a somewhat serious step.  Is this urgent enough for 2.6.21?
> If so, why?  The mysql thing?

No, Nish showed improvement in fact with SCHED_SMT enabled so this is 
unrelated. 

The reason is that with dynticks enabled, this code breaks without yet further 
tweaks so dynticks brought on the rapid demise of this code. So either we 
tweak this code or kill it off entirely. It was Ingo's preference to kill it 
off. Either way this needs to happen for 2.6.21 since dynticks has gone in.

-- 
-ck

Re: 2.6.21-rc1: known regressions (v2) (part 2)

[Michal Piotrowski]

Michal Piotrowski napisał(a):
> Thomas Gleixner napisał(a):
>> Adrian,
>>
>> On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
>>> Subject    : kernel BUG at kernel/time/tick-sched.c:168  (CONFIG_NO_HZ)
>>> References : http://lkml.org/lkml/2007/2/16/346
>>> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
>>> Handled-By : Thomas Gleixner <tglx@linutronix.de>
>>> Status     : problem is being debugged
>> The BUG_ON() was replaced by a warning printk(). The BUG_ON() exposed a
>> problem with the SMT scheduler. See below.
>>
>>> Subject    : BUG: soft lockup detected on CPU#0
>>>              NOHZ: local_softirq_pending 20  (SMT scheduler)
>>> References : http://lkml.org/lkml/2007/2/20/257
>>> Submitter  : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
>>> Handled-By : Thomas Gleixner <tglx@linutronix.de>
>>>              Ingo Molnar <mingo@elte.hu>
>>> Status     : problem is being debugged
>> Patch available, not confirmed yet.
>>
> 
> I can confirm that the bug is fixed (over 20 hours of testing should be enough).
                                       ^^^^ almost ;)

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)