All of lore.kernel.org
 help / color / mirror / Atom feed
* xen.git branch reorg
@ 2009-04-23 17:38 Jeremy Fitzhardinge
  2009-04-23 18:24 ` Pasi Kärkkäinen
                   ` (2 more replies)
  0 siblings, 3 replies; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-04-23 17:38 UTC (permalink / raw)
  To: Xen-devel

I finally fixed the AHCI problem with xen-tip/next and pushed forward 
with the long-threatened xen.git cleanup and reorg.

I've removed a pile of branches on 
git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git:

    * xen/*
    * push2/*
    * for-*/*

aside from some branches which contain some work which I need to look 
over again and work out what to do with.

*PLEASE* tell me if I've accidentally deleted a branch with something 
important, and I'll reinstate it.

All the changesets are still there in the repo, and if you have any 
local branches referring to these branches then they'll stay around 
indefinitely.  The removal just means that the branches won't confuse 
any newcomers, and it makes it clear that no further development is 
going to happen on them.

The new branch structure is similar to the old one in overall layout.  
There are two "merged" branches:

    * xen-tip/master - will try to keep as a known-working branch, with
      only tested changes
    * xen-tip/next - current bleeding edge; should at least compile

My planned workflow is:

   1. new development happens on topic branches
   2. those changes are merged with xen-tip/next until they test OK
   3. the changes are then merged onto master (either directly off next,
      or cleanly re-merged)
   4. upstream branches are merged with next and master like topic
      branches; I'll avoid merging them into xen.git topic branches
      unless its really necessary

I won't generally rebase any of the branches, though the "next" and 
"master" are more likely to be rebased than the topic branches.

The current set of topic branches are:

    * xen-tip/core
          o core Xen stuff; currently all upstream
    * xen-tip/dom0/acpi
          o host S3 suspend/resume (untested, unmerged)
    * xen-tip/dom0/apic
          o apic changes
    * xen-tip/dom0/backend/core
    * xen-tip/dom0/backend/blkback
    * xen-tip/dom0/backend/netback
          o backend devices
    * xen-tip/dom0/core
          o essential dom0 changes
    * xen-tip/dom0/drm
          o drm/dri changes
    * xen-tip/dom0/gntdev
          o /dev/gntdev
    * xen-tip/dom0/microcode
          o CPU microcode driver
    * xen-tip/dom0/mtrr
          o /proc/mtrr stuff
    * xen-tip/dom0/pci
          o general dom0 PCI/device access changes
    * xen-tip/dom0/swiotlb
          o Xen swiotlb changes
    * xen-tip/dom0/xenfs
          o /proc/xen/privcmd


Thanks,
    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-23 17:38 xen.git branch reorg Jeremy Fitzhardinge
@ 2009-04-23 18:24 ` Pasi Kärkkäinen
  2009-04-23 18:32   ` Jeremy Fitzhardinge
  2009-04-24 10:33   ` xen.git branch reorg Boris Derzhavets
  2009-04-24  8:59 ` Alex Zeffertt
  2009-04-26  1:28 ` William Pitcock
  2 siblings, 2 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-04-23 18:24 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Xen-devel

On Thu, Apr 23, 2009 at 10:38:31AM -0700, Jeremy Fitzhardinge wrote:
> I finally fixed the AHCI problem with xen-tip/next and pushed forward 
> with the long-threatened xen.git cleanup and reorg.
> 
> The new branch structure is similar to the old one in overall layout.  
> There are two "merged" branches:
> 
>    * xen-tip/master - will try to keep as a known-working branch, with
>      only tested changes
>    * xen-tip/next - current bleeding edge; should at least compile
> 

I'll try upgrading from dom0/hackery to xen-tip/next and see how it works
for me. 

Btw how does dom0 upstreaming look at the moment? Ingo sent pull request
about some changes, and those got merged, but how about the rest? 

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-23 18:24 ` Pasi Kärkkäinen
@ 2009-04-23 18:32   ` Jeremy Fitzhardinge
  2009-04-25 11:54     ` xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0 Pasi Kärkkäinen
  2009-04-24 10:33   ` xen.git branch reorg Boris Derzhavets
  1 sibling, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-04-23 18:32 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Xen-devel

Pasi Kärkkäinen wrote:
> I'll try upgrading from dom0/hackery to xen-tip/next and see how it works
> for me. 
>   

Thanks.

> Btw how does dom0 upstreaming look at the moment? Ingo sent pull request
> about some changes, and those got merged, but how about the rest? 

Ingo basically ignored all the Xen changes in the leadup to the merge 
window, then stomped on my attempt to get them merged with Linus, which 
was all pretty annoying.  It had the doubly-irritating side-effect of 
casting doubt over the controversy-free domU changes, so they didn't get 
merged in the merge window either; by the time Ingo got around to OKing 
them, the window had closed.  So all that got merged in the end was the 
must-have bug fixes.

Linus isn't going to pull any more major functionality changes in the 
-rc kernels, and certainly isn't going to make an exception for Xen.  So 
we're stuck with waiting for the .31 merge window.

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-23 17:38 xen.git branch reorg Jeremy Fitzhardinge
  2009-04-23 18:24 ` Pasi Kärkkäinen
@ 2009-04-24  8:59 ` Alex Zeffertt
  2009-04-27 15:44   ` Ian Campbell
  2009-04-26  1:28 ` William Pitcock
  2 siblings, 1 reply; 118+ messages in thread
From: Alex Zeffertt @ 2009-04-24  8:59 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Xen-devel

Jeremy Fitzhardinge wrote:
> I finally fixed the AHCI problem with xen-tip/next and pushed forward 
> with the long-threatened xen.git cleanup and reorg.
> 
> I've removed a pile of branches on 
> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git:
> 
>     * xen/*
>     * push2/*
>     * for-*/*
> 


Does this mean we need this patch in xen-unstable.hg?

Update XEN_LINUX_GIT_REMOTEBRANCH to match changes made in upstream repo.
Needed if you want setting KERNELS=linux-2.6-pvops in config/Linux.mk to
work.

diff -r 8b152638adaa buildconfigs/mk.linux-2.6-pvops
--- a/buildconfigs/mk.linux-2.6-pvops	Thu Apr 23 16:22:48 2009 +0100
+++ b/buildconfigs/mk.linux-2.6-pvops	Fri Apr 24 09:53:40 2009 +0100
@@ -7,7 +7,7 @@

  XEN_LINUX_GIT_URL ?= git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
  XEN_LINUX_GIT_REMOTENAME ?= xen
-XEN_LINUX_GIT_REMOTEBRANCH ?= xen/dom0/hackery
+XEN_LINUX_GIT_REMOTEBRANCH ?= xen-tip/master

  EXTRAVERSION ?=

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-23 18:24 ` Pasi Kärkkäinen
  2009-04-23 18:32   ` Jeremy Fitzhardinge
@ 2009-04-24 10:33   ` Boris Derzhavets
  2009-04-24 18:17     ` Jeremy Fitzhardinge
  1 sibling, 1 reply; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-24 10:33 UTC (permalink / raw)
  To: Jeremy Fitzhardinge, Pasi Kärkkäinen; +Cc: Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 1940 bytes --]

Kernel been built based on xen-tip/next  appears to have name 2.6.30-rc2-tip
and behaves under Xen 3.4-rc2-pre as usual. No problems were noticed with PV DomUs
for   CentOS 5.3, F10, Ubuntu Server 9.04. However, remote VNC connection to Ubuntu
Server 9.04 PV DomU seems to be extrtemely slow. VNC connection to same DomU
from Dom0 runs fine. I'll try to test this issue for CentOS and F10 DomUs ASAP. 
I also have to notice that remote VNC connection to Ubuntu 9.04 DomU running at the 
same Xen 3.4 version Dom0 with Suse's 2.6.27.5 xen-ified kernel behaves just fine.
IP6v connection via vinagre (for Ubuntu Server 9.04 DomU) behaves exactly same way as old fashioned. No problems when been established from Dom0 and almost dead remotely.
 
Boris.


--- On Thu, 4/23/09, Pasi Kärkkäinen <pasik@iki.fi> wrote:

From: Pasi Kärkkäinen <pasik@iki.fi>
Subject: Re: [Xen-devel] xen.git branch reorg
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: "Xen-devel" <xen-devel@lists.xensource.com>
Date: Thursday, April 23, 2009, 2:24 PM

On Thu, Apr 23, 2009 at 10:38:31AM -0700, Jeremy Fitzhardinge wrote:
> I finally fixed the AHCI problem with xen-tip/next and pushed forward 
> with the long-threatened xen.git cleanup and reorg.
> 
> The new branch structure is similar to the old one in overall layout.  
> There are two "merged" branches:
> 
>    * xen-tip/master - will try to keep as a known-working branch, with
>      only tested changes
>    * xen-tip/next - current bleeding edge; should at least compile
> 

I'll try upgrading from dom0/hackery to xen-tip/next and see how it works
for me. 

Btw how does dom0 upstreaming look at the moment? Ingo sent pull request
about some changes, and those got merged, but how about the rest? 

-- Pasi

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 2440 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-24 10:33   ` xen.git branch reorg Boris Derzhavets
@ 2009-04-24 18:17     ` Jeremy Fitzhardinge
  2009-04-24 18:50       ` Boris Derzhavets
  2009-04-24 18:56       ` Boris Derzhavets
  0 siblings, 2 replies; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-04-24 18:17 UTC (permalink / raw)
  To: bderzhavets; +Cc: Xen-devel

Boris Derzhavets wrote:
> Kernel been built based on xen-tip/next  appears to have name 
> 2.6.30-rc2-tip
> and behaves under Xen 3.4-rc2-pre as usual. No problems were noticed 
> with PV DomUs
> for   CentOS 5.3, F10, Ubuntu Server 9.04. However, remote VNC 
> connection to Ubuntu
> Server 9.04 PV DomU seems to be extrtemely slow. VNC connection to 
> same DomU
> from Dom0 runs fine. I'll try to test this issue for CentOS and F10 
> DomUs ASAP.
> I also have to notice that remote VNC connection to Ubuntu 9.04 DomU 
> running at the 
> same Xen 3.4 version Dom0 with Suse's 2.6.27.5 xen-ified kernel 
> behaves just fine.
> IP6v connection via vinagre (for Ubuntu Server 9.04 DomU) behaves 
> exactly same way as old fashioned. No problems when been established 
> from Dom0 and almost dead remotely.
>

Is it always consistent with the same kernel, or does it change from 
boot to boot?

Could you try to work out what's actually failing with 
tcpdump/wireshark, both from within the domU, and from dom0?  Are 
packets getting lost on tx or rx, or very delayed, or something else?

Thanks,
    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-24 18:17     ` Jeremy Fitzhardinge
@ 2009-04-24 18:50       ` Boris Derzhavets
  2009-04-24 19:48         ` Jeremy Fitzhardinge
  2009-04-24 18:56       ` Boris Derzhavets
  1 sibling, 1 reply; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-24 18:50 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 2187 bytes --]


 In meantime time i see,  that 2.6.30-rc3&rc2&rc1-tip are affected.
Solution is the same as on Solaris xVM Linux DomUs about one 
year ago -  is  to disable checksum (nothing else) offloading at Linux DomUs ( CentOS 5.3, Ubuntu 9.04)

/usr/local/sbin/ethtool -K etho tx off

It immediately brings remote VNC connections to the nice shape.
Actually , speeds up network.  

I will run "tcpdump" through this weekend to find out what's going 
wrong. To be honest,  i have experience with catching checksum offloading
failure via tcpdump's  capturing only on Solaris Nevada xVM ;)
But, i'll post the logs captured anyway.
Just a brief instruction where to run tcpdump ( and what command line keys are needed ) would help a lot.

Thanks
Boris




--- On Fri, 4/24/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] xen.git branch reorg
To: bderzhavets@yahoo.com
Cc: "Pasi Kärkkäinen" <pasik@iki.fi>, "Xen-devel" <xen-devel@lists.xensource.com>
Date: Friday, April 24, 2009, 2:17 PM

Boris Derzhavets wrote:
> Kernel been built based on xen-tip/next  appears to have name
2.6.30-rc2-tip
> and behaves under Xen 3.4-rc2-pre as usual. No problems were noticed with
PV DomUs
> for   CentOS 5.3, F10, Ubuntu Server 9.04. However, remote VNC connection
to Ubuntu
> Server 9.04 PV DomU seems to be extrtemely slow. VNC connection to same
DomU
> from Dom0 runs fine. I'll try to test this issue for CentOS and F10
DomUs ASAP.
> I also have to notice that remote VNC connection to Ubuntu 9.04 DomU
running at the same Xen 3.4 version Dom0 with Suse's 2.6.27.5 xen-ified
kernel behaves just fine.
> IP6v connection via vinagre (for Ubuntu Server 9.04 DomU) behaves exactly
same way as old fashioned. No problems when been established from Dom0 and
almost dead remotely.
> 

Is it always consistent with the same kernel, or does it change from boot to
boot?

Could you try to work out what's actually failing with tcpdump/wireshark,
both from within the domU, and from dom0?  Are packets getting lost on tx or rx,
or very delayed, or something else?

Thanks,
   J




      

[-- Attachment #1.2: Type: text/html, Size: 2653 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-24 18:17     ` Jeremy Fitzhardinge
  2009-04-24 18:50       ` Boris Derzhavets
@ 2009-04-24 18:56       ` Boris Derzhavets
  1 sibling, 0 replies; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-24 18:56 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 1562 bytes --]

It's also always consistent with each one of rc1,rc2,rc3 kernels

Boris.

--- On Fri, 4/24/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
From: Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [Xen-devel] xen.git branch reorg
To: bderzhavets@yahoo.com
Cc: "Xen-devel" <xen-devel@lists.xensource.com>
Date: Friday, April 24, 2009, 2:17 PM

Boris Derzhavets wrote:
> Kernel been built based on xen-tip/next  appears to have name
2.6.30-rc2-tip
> and behaves under Xen 3.4-rc2-pre as usual. No problems were noticed with
PV DomUs
> for   CentOS 5.3, F10, Ubuntu Server 9.04. However, remote VNC connection
to Ubuntu
> Server 9.04 PV DomU seems to be extrtemely slow. VNC connection to same
DomU
> from Dom0 runs fine. I'll try to test this issue for CentOS and F10
DomUs ASAP.
> I also have to notice that remote VNC connection to Ubuntu 9.04 DomU
running at the same Xen 3.4 version Dom0 with Suse's 2.6.27.5 xen-ified
kernel behaves just fine.
> IP6v connection via vinagre (for Ubuntu Server 9.04 DomU) behaves exactly
same way as old fashioned. No problems when been established from Dom0 and
almost dead remotely.
> 

Is it always consistent with the same kernel, or does it change from boot to
boot?

Could you try to work out what's actually failing with tcpdump/wireshark,
both from within the domU, and from dom0?  Are packets getting lost on tx or rx,
or very delayed, or something else?

Thanks,
   J


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 1997 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-24 18:50       ` Boris Derzhavets
@ 2009-04-24 19:48         ` Jeremy Fitzhardinge
  2009-04-24 22:39           ` Christophe Saout
       [not found]           ` <1240846534.29824.101.camel@zakaz.uk.xensource.com>
  0 siblings, 2 replies; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-04-24 19:48 UTC (permalink / raw)
  To: bderzhavets; +Cc: Xen-devel, Ian Campbell

Boris Derzhavets wrote:
>
>  In meantime time i see,  that 2.6.30-rc3&rc2&rc1-tip are affected.
> Solution is the same as on Solaris xVM Linux DomUs about one
> year ago -  is  to disable checksum (nothing else) offloading at Linux 
> DomUs ( CentOS 5.3, Ubuntu 9.04)
>
> /usr/local/sbin/ethtool -K etho tx off
>

OK, that's a good lead.

Ian, do you remember the story around this checksumming stuff?  Has 
something dropped off netback (or front) that we need?
   
>  
> I will run "tcpdump" through this weekend to find out what's going
> wrong. To be honest,  i have experience with catching checksum offloading
> failure via tcpdump's  capturing only on Solaris Nevada xVM ;)
> But, i'll post the logs captured anyway.
> Just a brief instruction where to run tcpdump ( and what command line 
> keys are needed ) would help a lot.
>

Actually, I think that's enough to go on for now.

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-24 19:48         ` Jeremy Fitzhardinge
@ 2009-04-24 22:39           ` Christophe Saout
  2009-04-25  6:55             ` Boris Derzhavets
  2009-04-25  9:22             ` Boris Derzhavets
       [not found]           ` <1240846534.29824.101.camel@zakaz.uk.xensource.com>
  1 sibling, 2 replies; 118+ messages in thread
From: Christophe Saout @ 2009-04-24 22:39 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: bderzhavets, Xen-devel, Ian Campbell

Hi Jeremy,

> >  In meantime time i see,  that 2.6.30-rc3&rc2&rc1-tip are affected.
> > Solution is the same as on Solaris xVM Linux DomUs about one
> > year ago -  is  to disable checksum (nothing else) offloading at Linux 
> > DomUs ( CentOS 5.3, Ubuntu 9.04)
> >
> > /usr/local/sbin/ethtool -K etho tx off
>
> OK, that's a good lead.

Yes, I've been seeing this too (and meant to investigate it before
claiming there's abug) and I can confirm that turning off segmentation
offloading "cures" the problem here too.

Now the tcpdump on Dom0 looks interesting.  It repeatedly sees a packet
with 2880 byte from DomU coming in, which is then dropped and ICMP
"fragmentation needed" sent back, the DomU resends a 1440 byte packet
(after some delay), which then goes through, but then the next one is a
2880 byte one again, and so on.

FYI: My Dom0 is running NAT, in case this is relevant.

	Christophe

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-24 22:39           ` Christophe Saout
@ 2009-04-25  6:55             ` Boris Derzhavets
  2009-04-25  7:03               ` Venefax
  2009-04-25  8:19               ` Pasi Kärkkäinen
  2009-04-25  9:22             ` Boris Derzhavets
  1 sibling, 2 replies; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-25  6:55 UTC (permalink / raw)
  To: Jeremy Fitzhardinge, Christophe Saout; +Cc: Xen-devel, Ian Campbell


[-- Attachment #1.1: Type: text/plain, Size: 1654 bytes --]

Chris,

I have to apologize. Turning off segmentation offloading may work as well.
Just now it fixed VNC issue on bare metal - CentOS 5.2 with Atansic Gigabit
Ethernet driver (ASUS P5KR) . I gonna try it at DomUs at my earliest convenience.

Boris.

--- On Fri, 4/24/09, Christophe Saout <christophe@saout.de> wrote:
From: Christophe Saout <christophe@saout.de>
Subject: Re: [Xen-devel] xen.git branch reorg
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: bderzhavets@yahoo.com, "Xen-devel" <xen-devel@lists.xensource.com>, "Ian Campbell" <Ian.Campbell@citrix.com>
Date: Friday, April 24, 2009, 6:39 PM

Hi Jeremy,

> >  In meantime time i see,  that 2.6.30-rc3&rc2&rc1-tip are
affected.
> > Solution is the same as on Solaris xVM Linux DomUs about one
> > year ago -  is  to disable checksum (nothing else) offloading at
Linux 
> > DomUs ( CentOS 5.3, Ubuntu 9.04)
> >
> > /usr/local/sbin/ethtool -K etho tx off
>
> OK, that's a good lead.

Yes, I've been seeing this too (and meant to investigate it before
claiming there's abug) and I can confirm that turning off segmentation
offloading "cures" the problem here too.

Now the tcpdump on Dom0 looks interesting.  It repeatedly sees a packet
with 2880 byte from DomU coming in, which is then dropped and ICMP
"fragmentation needed" sent back, the DomU resends a 1440 byte packet
(after some delay), which then goes through, but then the next one is a
2880 byte one again, and so on.

FYI: My Dom0 is running NAT, in case this is relevant.

	Christophe



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 2136 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* RE: xen.git branch reorg
  2009-04-25  6:55             ` Boris Derzhavets
@ 2009-04-25  7:03               ` Venefax
  2009-04-25  8:35                 ` Boris Derzhavets
  2009-04-25  8:19               ` Pasi Kärkkäinen
  1 sibling, 1 reply; 118+ messages in thread
From: Venefax @ 2009-04-25  7:03 UTC (permalink / raw)
  To: bderzhavets, 'Jeremy Fitzhardinge', 'Christophe Saout'
  Cc: 'Xen-devel', 'Ian Campbell'


[-- Attachment #1.1: Type: text/plain, Size: 2263 bytes --]

What are the exact commands to turn off Segmentation Offload and Checksum
Offload?

Also, should this be done only at Dom0 or also at DomU's?

Is this correct or should it be "eth0"?

 

/usr/local/sbin/ethtool -K etho tx off

F.Alves

From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Boris Derzhavets
Sent: Saturday, April 25, 2009 2:55 AM
To: Jeremy Fitzhardinge; Christophe Saout
Cc: Xen-devel; Ian Campbell
Subject: Re: [Xen-devel] xen.git branch reorg

 


Chris,

I have to apologize. Turning off segmentation offloading may work as well.
Just now it fixed VNC issue on bare metal - CentOS 5.2 with Atansic Gigabit
Ethernet driver (ASUS P5KR) . I gonna try it at DomUs at my earliest
convenience.

Boris.

--- On Fri, 4/24/09, Christophe Saout <christophe@saout.de> wrote:

From: Christophe Saout <christophe@saout.de>
Subject: Re: [Xen-devel] xen.git branch reorg
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: bderzhavets@yahoo.com, "Xen-devel" <xen-devel@lists.xensource.com>, "Ian
Campbell" <Ian.Campbell@citrix.com>
Date: Friday, April 24, 2009, 6:39 PM

Hi Jeremy,


  


> >  In meantime time i see,  that
 2.6.30-rc3&rc2&rc1-tip are


affected.


> > Solution is the same as on Solaris xVM Linux DomUs about one


> > year ago -  is  to disable checksum (nothing else) offloading at


Linux 


> > DomUs ( CentOS 5.3, Ubuntu 9.04)


> >


> > /usr/local/sbin/ethtool -K etho tx off


>


> OK, that's a good lead.


  


Yes, I've been seeing this too (and meant to investigate it before


claiming there's abug) and I can confirm that turning off segmentation


offloading "cures" the problem here too.


  


Now the tcpdump on Dom0 looks interesting.  It repeatedly sees a packet


with 2880 byte from DomU coming in, which is then dropped and ICMP


"fragmentation needed" sent back, the DomU resends a 1440 byte packet


(after some delay), which then goes through, but then the next one is a


2880 byte one again, and so on.


  


FYI: My Dom0 is running NAT, in case this is relevant.


  


  


  
        Christophe


  


  


  


_______________________________________________


Xen-devel mailing list


Xen-devel@lists.xensource.com


http://lists.xensource.com/xen-devel

 


[-- Attachment #1.2: Type: text/html, Size: 8762 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-25  6:55             ` Boris Derzhavets
  2009-04-25  7:03               ` Venefax
@ 2009-04-25  8:19               ` Pasi Kärkkäinen
  2009-04-25  8:58                 ` Boris Derzhavets
  1 sibling, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-04-25  8:19 UTC (permalink / raw)
  To: Boris Derzhavets
  Cc: Jeremy Fitzhardinge, Xen-devel, Christophe Saout, Ian Campbell

On Fri, Apr 24, 2009 at 11:55:19PM -0700, Boris Derzhavets wrote:
> Chris,
> 
> I have to apologize. Turning off segmentation offloading may work as well.
> Just now it fixed VNC issue on bare metal - CentOS 5.2 with Atansic Gigabit
> Ethernet driver (ASUS P5KR) . I gonna try it at DomUs at my earliest convenience.
>

Have you tried another NICs? It could be a bug in the driver for that NIC..

-- Pasi

 
> Boris.
> 
> --- On Fri, 4/24/09, Christophe Saout <christophe@saout.de> wrote:
> From: Christophe Saout <christophe@saout.de>
> Subject: Re: [Xen-devel] xen.git branch reorg
> To: "Jeremy Fitzhardinge" <jeremy@goop.org>
> Cc: bderzhavets@yahoo.com, "Xen-devel" <xen-devel@lists.xensource.com>, "Ian Campbell" <Ian.Campbell@citrix.com>
> Date: Friday, April 24, 2009, 6:39 PM
> 
> Hi Jeremy,
> 
> > >  In meantime time i see,  that 2.6.30-rc3&rc2&rc1-tip are
> affected.
> > > Solution is the same as on Solaris xVM Linux DomUs about one
> > > year ago -  is  to disable checksum (nothing else) offloading at
> Linux 
> > > DomUs ( CentOS 5.3, Ubuntu 9.04)
> > >
> > > /usr/local/sbin/ethtool -K etho tx off
> >
> > OK, that's a good lead.
> 
> Yes, I've been seeing this too (and meant to investigate it before
> claiming there's abug) and I can confirm that turning off segmentation
> offloading "cures" the problem here too.
> 
> Now the tcpdump on Dom0 looks interesting.  It repeatedly sees a packet
> with 2880 byte from DomU coming in, which is then dropped and ICMP
> "fragmentation needed" sent back, the DomU resends a 1440 byte packet
> (after some delay), which then goes through, but then the next one is a
> 2880 byte one again, and so on.
> 
> FYI: My Dom0 is running NAT, in case this is relevant.
> 
> 	Christophe
> 
> 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* RE: xen.git branch reorg
  2009-04-25  7:03               ` Venefax
@ 2009-04-25  8:35                 ` Boris Derzhavets
  0 siblings, 0 replies; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-25  8:35 UTC (permalink / raw)
  To: Venefax; +Cc: 'Xen-devel'


[-- Attachment #1.1: Type: text/plain, Size: 3917 bytes --]

I tried at DomU:

1. Specifies whether TX checksumming should be disabled.
# /usr/local/sbin/ethtool -K eth0 tx off

2. Specifies whether TCP segmentation offload should be disabled.
# /usr/local/sbin/ethtool -K eth0 tso off

3.  Specifies whether UDP fragmentation offload should be disabled
# /usr/local/sbin/ethtool -K eth0 ufo off

Second parameter is your Ethernet interface . Might be eth1 or eth2.
Just install ethtool-6 to get  " man ethtool " handy
You can try all of them, just first , second and third.
Whatever provide a relief.

I had to run second to brought up VNC on CentOS 5.2 Dom0 
 (on bare metal ASUS P5KR)
I believe Linux driver for Atansic Gigabit Ethernet is not good.
Regarding DomU access from from the Net and vice versa usually
first one helps (at DomU ). 
I don't know what exactly Chris did. "gso" option fails.
Some network education is obviously required for myself at least ;)
To read and understand tcpdump's captured logs for instance.

Boris.



--- On Sat, 4/25/09, Venefax <venefax@gmail.com> wrote:
From: Venefax <venefax@gmail.com>
Subject: RE: [Xen-devel] xen.git branch reorg
To: bderzhavets@yahoo.com, "'Jeremy Fitzhardinge'" <jeremy@goop.org>, "'Christophe Saout'" <christophe@saout.de>
Cc: "'Xen-devel'" <xen-devel@lists.xensource.com>, "'Ian Campbell'" <Ian.Campbell@citrix.com>
Date: Saturday, April 25, 2009, 3:03 AM




 
 






What are the exact commands to turn off Segmentation Offload and
Checksum Offload? 

Also, should this be done only at Dom0 or also at DomU’s? 

Is this correct or should it be “eth0”? 

   

/usr/local/sbin/ethtool -K etho tx off 

F.Alves 



From:
xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Boris
Derzhavets

Sent: Saturday, April 25, 2009 2:55 AM

To: Jeremy Fitzhardinge; Christophe Saout

Cc: Xen-devel; Ian Campbell

Subject: Re: [Xen-devel] xen.git branch reorg 



   


 
  
  Chris,

  

  I have to apologize. Turning off segmentation offloading may work as well.

  Just now it fixed VNC issue on bare metal - CentOS 5.2 with Atansic Gigabit

  Ethernet driver (ASUS P5KR) . I gonna try it at DomUs at my earliest
  convenience.

  

  Boris.

  

  --- On Fri, 4/24/09, Christophe Saout <christophe@saout.de>
  wrote: 
  From: Christophe Saout
  <christophe@saout.de>

  Subject: Re: [Xen-devel] xen.git branch reorg

  To: "Jeremy Fitzhardinge" <jeremy@goop.org>

  Cc: bderzhavets@yahoo.com, "Xen-devel"
  <xen-devel@lists.xensource.com>, "Ian Campbell"
  <Ian.Campbell@citrix.com>

  Date: Friday, April 24, 2009, 6:39 PM 
  Hi Jeremy,

  

> >  In meantime time i see,  that 2.6.30-rc3&rc2&rc1-tip are

affected.

> > Solution is the same as on Solaris xVM Linux DomUs about one

> > year ago -  is  to disable checksum (nothing else) offloading at

Linux 

> > DomUs ( CentOS 5.3, Ubuntu 9.04)

> >

> > /usr/local/sbin/ethtool -K etho tx off

>

> OK, that's a good lead.

  

Yes, I've been seeing this too (and meant to investigate it before

claiming there's abug) and I can confirm that turning off segmentation

offloading "cures" the problem here too.

  

Now the tcpdump on Dom0 looks interesting.  It repeatedly sees a packet

with 2880 byte from DomU coming in, which is then dropped and ICMP

"fragmentation needed" sent back, the DomU resends a 1440 byte packet

(after some delay), which then goes through, but then the next one is a

2880 byte one again, and so on.

  

FYI: My Dom0 is running NAT, in case this is relevant.

  

  

          Christophe

  

  

  

_______________________________________________

Xen-devel mailing list

Xen-devel@lists.xensource.com

http://lists.xensource.com/xen-devel 
 


   



 




      

[-- Attachment #1.2: Type: text/html, Size: 7534 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-25  8:19               ` Pasi Kärkkäinen
@ 2009-04-25  8:58                 ` Boris Derzhavets
  0 siblings, 0 replies; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-25  8:58 UTC (permalink / raw)
  To: Pasi Kärkkäinen
  Cc: Jeremy Fitzhardinge, Xen-devel, Christophe Saout, Ian Campbell


[-- Attachment #1.1: Type: text/plain, Size: 2525 bytes --]

Pasi,

The most recent boards have integrated Gigabit Ethernet Adapters on
PCI-E as usual. My preference for Linux  is Marvel Yukon 8056 PCI-E.
 It's customers's decision what board to purchase and what OS to install. 
I am just supposed to fix bug , either left customer on his own.

Boris

--- On Sat, 4/25/09, Pasi Kärkkäinen <pasik@iki.fi> wrote:
From: Pasi Kärkkäinen <pasik@iki.fi>
Subject: Re: [Xen-devel] xen.git branch reorg
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>, "Christophe Saout" <christophe@saout.de>, "Xen-devel" <xen-devel@lists.xensource.com>, "Ian Campbell" <Ian.Campbell@citrix.com>
Date: Saturday, April 25, 2009, 4:19 AM

On Fri, Apr 24, 2009 at 11:55:19PM -0700, Boris Derzhavets wrote:
> Chris,
> 
> I have to apologize. Turning off segmentation offloading may work as well.
> Just now it fixed VNC issue on bare metal - CentOS 5.2 with Atansic
Gigabit
> Ethernet driver (ASUS P5KR) . I gonna try it at DomUs at my earliest
convenience.
>

Have you tried another NICs? It could be a bug in the driver for that NIC..

-- Pasi

 
> Boris.
> 
> --- On Fri, 4/24/09, Christophe Saout <christophe@saout.de> wrote:
> From: Christophe Saout <christophe@saout.de>
> Subject: Re: [Xen-devel] xen.git branch reorg
> To: "Jeremy Fitzhardinge" <jeremy@goop.org>
> Cc: bderzhavets@yahoo.com, "Xen-devel"
<xen-devel@lists.xensource.com>, "Ian Campbell"
<Ian.Campbell@citrix.com>
> Date: Friday, April 24, 2009, 6:39 PM
> 
> Hi Jeremy,
> 
> > >  In meantime time i see,  that 2.6.30-rc3&rc2&rc1-tip
are
> affected.
> > > Solution is the same as on Solaris xVM Linux DomUs about one
> > > year ago -  is  to disable checksum (nothing else) offloading at
> Linux 
> > > DomUs ( CentOS 5.3, Ubuntu 9.04)
> > >
> > > /usr/local/sbin/ethtool -K etho tx off
> >
> > OK, that's a good lead.
> 
> Yes, I've been seeing this too (and meant to investigate it before
> claiming there's abug) and I can confirm that turning off segmentation
> offloading "cures" the problem here too.
> 
> Now the tcpdump on Dom0 looks interesting.  It repeatedly sees a packet
> with 2880 byte from DomU coming in, which is then dropped and ICMP
> "fragmentation needed" sent back, the DomU resends a 1440 byte
packet
> (after some delay), which then goes through, but then the next one is a
> 2880 byte one again, and so on.
> 
> FYI: My Dom0 is running NAT, in case this is relevant.
> 
> 	Christophe
> 
> 



      

[-- Attachment #1.2: Type: text/html, Size: 3182 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-24 22:39           ` Christophe Saout
  2009-04-25  6:55             ` Boris Derzhavets
@ 2009-04-25  9:22             ` Boris Derzhavets
  1 sibling, 0 replies; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-25  9:22 UTC (permalink / raw)
  To: Jeremy Fitzhardinge, Christophe Saout; +Cc: Xen-devel, Ian Campbell


[-- Attachment #1.1: Type: text/plain, Size: 1622 bytes --]

I've just tested:-

# /usr/local/sbin/ethtool -K eth0 tso off

at Ubuntu 9.04 Server PV DomU at Xen 3.4-rc3-pre Dom0 ( with 2.6.30-rc3-tip).
This command also fixes remote VNC connections performance to DomU.

Boris.

--- On Fri, 4/24/09, Christophe Saout <christophe@saout.de> wrote:
From: Christophe Saout <christophe@saout.de>
Subject: Re: [Xen-devel] xen.git branch reorg
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: bderzhavets@yahoo.com, "Xen-devel" <xen-devel@lists.xensource.com>, "Ian Campbell" <Ian.Campbell@citrix.com>
Date: Friday, April 24, 2009, 6:39 PM

Hi Jeremy,

> >  In meantime time i see,  that 2.6.30-rc3&rc2&rc1-tip are
affected.
> > Solution is the same as on Solaris xVM Linux DomUs about one
> > year ago -  is  to disable checksum (nothing else) offloading at
Linux 
> > DomUs ( CentOS 5.3, Ubuntu 9.04)
> >
> > /usr/local/sbin/ethtool -K etho tx off
>
> OK, that's a good lead.

Yes, I've been seeing this too (and meant to investigate it before
claiming there's abug) and I can confirm that turning off segmentation
offloading "cures" the problem here too.

Now the tcpdump on Dom0 looks interesting.  It repeatedly sees a packet
with 2880 byte from DomU coming in, which is then dropped and ICMP
"fragmentation needed" sent back, the DomU resends a 1440 byte packet
(after some delay), which then goes through, but then the next one is a
2880 byte one again, and so on.

FYI: My Dom0 is running NAT, in case this is relevant.

	Christophe



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 2109 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-04-23 18:32   ` Jeremy Fitzhardinge
@ 2009-04-25 11:54     ` Pasi Kärkkäinen
  2009-04-25 12:36       ` Pasi Kärkkäinen
                         ` (3 more replies)
  0 siblings, 4 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-04-25 11:54 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Xen-devel

On Thu, Apr 23, 2009 at 11:32:14AM -0700, Jeremy Fitzhardinge wrote:
> Pasi Kärkkäinen wrote:
> >I'll try upgrading from dom0/hackery to xen-tip/next and see how it works
> >for me. 
> >  
> 
> Thanks.
> 

It seems latest tree crashes for me (happened yesterday, and also today, just rebuilt the latest commits):
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-26-xen331-linux-2.6.30-rc3-crash-no-highpte.txt

Zone PFN ranges:
  DMA      0x00000010 -> 0x00001000
  Normal   0x00001000 -> 0x000229fe
  HighMem  0x000229fe -> 0x00040000
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
    0: 0x00000010 -> 0x0000009f
    0: 0x00000100 -> 0x00001167
    0: 0x00001268 -> 0x00040000
(XEN) d0:v0: unhandled page fault (ec=0003)
(XEN) Pagetable walk from c1268000:
(XEN)  L3[0x003] = 000000003c8f0001 000008f0
(XEN)  L2[0x009] = 000000003d276067 00001276 
(XEN)  L1[0x068] = 000000003d268061 00001268
(XEN) domain_crash_sync called from entry.S (ff19f70e)
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-3.3.1-11.fc11  x86_32p  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) EIP:    e019:[<c088adae>]
(XEN) EFLAGS: 00000206   EM: 1   CONTEXT: pv guest
(XEN) eax: 00000000   ebx: 00800000   ecx: 00200000   edx: c1268000
(XEN) esi: 01268000   edi: c1268000   ebp: c086de5c   esp: c086de1c
(XEN) cr0: 8005003b   cr4: 000006f0   cr3: 3c85c000   cr2: c1268000
(XEN) ds: e021   es: e021   fs: e021   gs: e021   ss: e021   cs: e019
(XEN) Guest stack trace from esp=c086de1c:

[root@dom0test linux-2.6-xen]# gdb ./vmlinux
(gdb) x/i 0xc086de1c
0xc086de1c <init_thread_union+3612>:    add    %al,(%eax)

32b PAE dom0, 32b PAE hypervisor. 


> >Btw how does dom0 upstreaming look at the moment? Ingo sent pull request
> >about some changes, and those got merged, but how about the rest? 
> 
> Ingo basically ignored all the Xen changes in the leadup to the merge 
> window, then stomped on my attempt to get them merged with Linus, which 
> was all pretty annoying.  It had the doubly-irritating side-effect of 
> casting doubt over the controversy-free domU changes, so they didn't get 
> merged in the merge window either; by the time Ingo got around to OKing 
> them, the window had closed.  So all that got merged in the end was the 
> must-have bug fixes.
> 

Yeah.. :( I really hope next merge window will be better..

> Linus isn't going to pull any more major functionality changes in the 
> -rc kernels, and certainly isn't going to make an exception for Xen.  So 
> we're stuck with waiting for the .31 merge window.
> 

I think it might be a good idea to start sending the patches already now, so
they get enough review before the .31 merge window.. 

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-04-25 11:54     ` xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0 Pasi Kärkkäinen
@ 2009-04-25 12:36       ` Pasi Kärkkäinen
  2009-04-25 13:59       ` M A Young
                         ` (2 subsequent siblings)
  3 siblings, 0 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-04-25 12:36 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Xen-devel

On Sat, Apr 25, 2009 at 02:54:04PM +0300, Pasi Kärkkäinen wrote:
> On Thu, Apr 23, 2009 at 11:32:14AM -0700, Jeremy Fitzhardinge wrote:
> > Pasi Kärkkäinen wrote:
> > >I'll try upgrading from dom0/hackery to xen-tip/next and see how it works
> > >for me. 
> > >  
> > 
> > Thanks.
> > 
> 
> It seems latest tree crashes for me (happened yesterday, and also today, just rebuilt the latest commits):
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-26-xen331-linux-2.6.30-rc3-crash-no-highpte.txt
> 

Same kernel seems to boot and work OK on baremetal without Xen.

-- Pasi

> Zone PFN ranges:
>   DMA      0x00000010 -> 0x00001000
>   Normal   0x00001000 -> 0x000229fe
>   HighMem  0x000229fe -> 0x00040000
> Movable zone start PFN for each node
> early_node_map[3] active PFN ranges
>     0: 0x00000010 -> 0x0000009f
>     0: 0x00000100 -> 0x00001167
>     0: 0x00001268 -> 0x00040000
> (XEN) d0:v0: unhandled page fault (ec=0003)
> (XEN) Pagetable walk from c1268000:
> (XEN)  L3[0x003] = 000000003c8f0001 000008f0
> (XEN)  L2[0x009] = 000000003d276067 00001276 
> (XEN)  L1[0x068] = 000000003d268061 00001268
> (XEN) domain_crash_sync called from entry.S (ff19f70e)
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-3.3.1-11.fc11  x86_32p  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) EIP:    e019:[<c088adae>]
> (XEN) EFLAGS: 00000206   EM: 1   CONTEXT: pv guest
> (XEN) eax: 00000000   ebx: 00800000   ecx: 00200000   edx: c1268000
> (XEN) esi: 01268000   edi: c1268000   ebp: c086de5c   esp: c086de1c
> (XEN) cr0: 8005003b   cr4: 000006f0   cr3: 3c85c000   cr2: c1268000
> (XEN) ds: e021   es: e021   fs: e021   gs: e021   ss: e021   cs: e019
> (XEN) Guest stack trace from esp=c086de1c:
> 
> [root@dom0test linux-2.6-xen]# gdb ./vmlinux
> (gdb) x/i 0xc086de1c
> 0xc086de1c <init_thread_union+3612>:    add    %al,(%eax)
> 
> 32b PAE dom0, 32b PAE hypervisor. 
> 
> 
> > >Btw how does dom0 upstreaming look at the moment? Ingo sent pull request
> > >about some changes, and those got merged, but how about the rest? 
> > 
> > Ingo basically ignored all the Xen changes in the leadup to the merge 
> > window, then stomped on my attempt to get them merged with Linus, which 
> > was all pretty annoying.  It had the doubly-irritating side-effect of 
> > casting doubt over the controversy-free domU changes, so they didn't get 
> > merged in the merge window either; by the time Ingo got around to OKing 
> > them, the window had closed.  So all that got merged in the end was the 
> > must-have bug fixes.
> > 
> 
> Yeah.. :( I really hope next merge window will be better..
> 
> > Linus isn't going to pull any more major functionality changes in the 
> > -rc kernels, and certainly isn't going to make an exception for Xen.  So 
> > we're stuck with waiting for the .31 merge window.
> > 
> 
> I think it might be a good idea to start sending the patches already now, so
> they get enough review before the .31 merge window.. 
> 
> -- Pasi
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-04-25 11:54     ` xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0 Pasi Kärkkäinen
  2009-04-25 12:36       ` Pasi Kärkkäinen
@ 2009-04-25 13:59       ` M A Young
  2009-04-26 14:50         ` Pasi Kärkkäinen
  2009-04-25 23:34       ` Jeremy Fitzhardinge
  2009-04-27 19:33       ` Jeremy Fitzhardinge
  3 siblings, 1 reply; 118+ messages in thread
From: M A Young @ 2009-04-25 13:59 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Sat, 25 Apr 2009, Pasi K?rkk?inen wrote:

> It seems latest tree crashes for me (happened yesterday, and also today, 
> just rebuilt the latest commits): 
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-26-xen331-linux-2.6.30-rc3-crash-no-highpte.txt

What are your STACKPROTECTOR settings?

 	Michael Young

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-04-25 11:54     ` xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0 Pasi Kärkkäinen
  2009-04-25 12:36       ` Pasi Kärkkäinen
  2009-04-25 13:59       ` M A Young
@ 2009-04-25 23:34       ` Jeremy Fitzhardinge
  2009-04-26 14:51         ` Pasi Kärkkäinen
  2009-04-27 19:33       ` Jeremy Fitzhardinge
  3 siblings, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-04-25 23:34 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Xen-devel

Pasi Kärkkäinen wrote:
> On Thu, Apr 23, 2009 at 11:32:14AM -0700, Jeremy Fitzhardinge wrote:
>   
>> Pasi Kärkkäinen wrote:
>>     
>>> I'll try upgrading from dom0/hackery to xen-tip/next and see how it works
>>> for me. 
>>>  
>>>       
>> Thanks.
>>
>>     
>
> It seems latest tree crashes for me (happened yesterday, and also today, just rebuilt the latest commits):
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-26-xen331-linux-2.6.30-rc3-crash-no-highpte.txt
>   

This is xen-tip/next?  Does master work any better?  How about running 
as domU?

Thanks,
    J

> Zone PFN ranges:
>   DMA      0x00000010 -> 0x00001000
>   Normal   0x00001000 -> 0x000229fe
>   HighMem  0x000229fe -> 0x00040000
> Movable zone start PFN for each node
> early_node_map[3] active PFN ranges
>     0: 0x00000010 -> 0x0000009f
>     0: 0x00000100 -> 0x00001167
>     0: 0x00001268 -> 0x00040000
> (XEN) d0:v0: unhandled page fault (ec=0003)
> (XEN) Pagetable walk from c1268000:
> (XEN)  L3[0x003] = 000000003c8f0001 000008f0
> (XEN)  L2[0x009] = 000000003d276067 00001276 
> (XEN)  L1[0x068] = 000000003d268061 00001268
> (XEN) domain_crash_sync called from entry.S (ff19f70e)
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-3.3.1-11.fc11  x86_32p  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) EIP:    e019:[<c088adae>]
> (XEN) EFLAGS: 00000206   EM: 1   CONTEXT: pv guest
> (XEN) eax: 00000000   ebx: 00800000   ecx: 00200000   edx: c1268000
> (XEN) esi: 01268000   edi: c1268000   ebp: c086de5c   esp: c086de1c
> (XEN) cr0: 8005003b   cr4: 000006f0   cr3: 3c85c000   cr2: c1268000
> (XEN) ds: e021   es: e021   fs: e021   gs: e021   ss: e021   cs: e019
> (XEN) Guest stack trace from esp=c086de1c:
>
> [root@dom0test linux-2.6-xen]# gdb ./vmlinux
> (gdb) x/i 0xc086de1c
> 0xc086de1c <init_thread_union+3612>:    add    %al,(%eax)
>
> 32b PAE dom0, 32b PAE hypervisor. 
>
>
>   
>>> Btw how does dom0 upstreaming look at the moment? Ingo sent pull request
>>> about some changes, and those got merged, but how about the rest? 
>>>       
>> Ingo basically ignored all the Xen changes in the leadup to the merge 
>> window, then stomped on my attempt to get them merged with Linus, which 
>> was all pretty annoying.  It had the doubly-irritating side-effect of 
>> casting doubt over the controversy-free domU changes, so they didn't get 
>> merged in the merge window either; by the time Ingo got around to OKing 
>> them, the window had closed.  So all that got merged in the end was the 
>> must-have bug fixes.
>>
>>     
>
> Yeah.. :( I really hope next merge window will be better..
>
>   
>> Linus isn't going to pull any more major functionality changes in the 
>> -rc kernels, and certainly isn't going to make an exception for Xen.  So 
>> we're stuck with waiting for the .31 merge window.
>>
>>     
>
> I think it might be a good idea to start sending the patches already now, so
> they get enough review before the .31 merge window.. 
>
> -- Pasi
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>   

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-23 17:38 xen.git branch reorg Jeremy Fitzhardinge
  2009-04-23 18:24 ` Pasi Kärkkäinen
  2009-04-24  8:59 ` Alex Zeffertt
@ 2009-04-26  1:28 ` William Pitcock
  2009-04-27 20:50   ` Jeremy Fitzhardinge
  2 siblings, 1 reply; 118+ messages in thread
From: William Pitcock @ 2009-04-26  1:28 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Xen-devel

Cloning git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
gives me the following:

nenolod@petrie:~/dev-src$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-xen-next
Initialized empty Git repository in /home/nenolod/dev-src/linux-xen-next/.git/
remote: Counting objects: 1299853, done.
remote: Compressing objects: 100% (227847/227847), done.
remote: Total 1299853 (delta 1088065), reused 1275536 (delta 1064482)
Receiving objects: 100% (1299853/1299853), 306.99 MiB | 411 KiB/s, done.
Resolving deltas: 100% (1088065/1088065), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

Something seems wrong here.

William

On Thu, 2009-04-23 at 10:38 -0700, Jeremy Fitzhardinge wrote:
> I finally fixed the AHCI problem with xen-tip/next and pushed forward 
> with the long-threatened xen.git cleanup and reorg.
> 
> I've removed a pile of branches on 
> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git:
> 
>     * xen/*
>     * push2/*
>     * for-*/*
> 
> aside from some branches which contain some work which I need to look 
> over again and work out what to do with.
> 
> *PLEASE* tell me if I've accidentally deleted a branch with something 
> important, and I'll reinstate it.
> 
> All the changesets are still there in the repo, and if you have any 
> local branches referring to these branches then they'll stay around 
> indefinitely.  The removal just means that the branches won't confuse 
> any newcomers, and it makes it clear that no further development is 
> going to happen on them.
> 
> The new branch structure is similar to the old one in overall layout.  
> There are two "merged" branches:
> 
>     * xen-tip/master - will try to keep as a known-working branch, with
>       only tested changes
>     * xen-tip/next - current bleeding edge; should at least compile
> 
> My planned workflow is:
> 
>    1. new development happens on topic branches
>    2. those changes are merged with xen-tip/next until they test OK
>    3. the changes are then merged onto master (either directly off next,
>       or cleanly re-merged)
>    4. upstream branches are merged with next and master like topic
>       branches; I'll avoid merging them into xen.git topic branches
>       unless its really necessary
> 
> I won't generally rebase any of the branches, though the "next" and 
> "master" are more likely to be rebased than the topic branches.
> 
> The current set of topic branches are:
> 
>     * xen-tip/core
>           o core Xen stuff; currently all upstream
>     * xen-tip/dom0/acpi
>           o host S3 suspend/resume (untested, unmerged)
>     * xen-tip/dom0/apic
>           o apic changes
>     * xen-tip/dom0/backend/core
>     * xen-tip/dom0/backend/blkback
>     * xen-tip/dom0/backend/netback
>           o backend devices
>     * xen-tip/dom0/core
>           o essential dom0 changes
>     * xen-tip/dom0/drm
>           o drm/dri changes
>     * xen-tip/dom0/gntdev
>           o /dev/gntdev
>     * xen-tip/dom0/microcode
>           o CPU microcode driver
>     * xen-tip/dom0/mtrr
>           o /proc/mtrr stuff
>     * xen-tip/dom0/pci
>           o general dom0 PCI/device access changes
>     * xen-tip/dom0/swiotlb
>           o Xen swiotlb changes
>     * xen-tip/dom0/xenfs
>           o /proc/xen/privcmd
> 
> 
> Thanks,
>     J
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-04-25 13:59       ` M A Young
@ 2009-04-26 14:50         ` Pasi Kärkkäinen
  0 siblings, 0 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-04-26 14:50 UTC (permalink / raw)
  To: M A Young; +Cc: Jeremy Fitzhardinge, Xen-devel

On Sat, Apr 25, 2009 at 02:59:09PM +0100, M A Young wrote:
> On Sat, 25 Apr 2009, Pasi K?rkk?inen wrote:
> 
> >It seems latest tree crashes for me (happened yesterday, and also today, 
> >just rebuilt the latest commits): 
> >http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-26-xen331-linux-2.6.30-rc3-crash-no-highpte.txt
> 
> What are your STACKPROTECTOR settings?
> 

[root@dom0test linux-2.6-xen]# grep -i protector .config
# CONFIG_CC_STACKPROTECTOR is not set

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-04-25 23:34       ` Jeremy Fitzhardinge
@ 2009-04-26 14:51         ` Pasi Kärkkäinen
  2009-04-26 18:38           ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-04-26 14:51 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Xen-devel

On Sat, Apr 25, 2009 at 04:34:00PM -0700, Jeremy Fitzhardinge wrote:
> Pasi Kärkkäinen wrote:
> >On Thu, Apr 23, 2009 at 11:32:14AM -0700, Jeremy Fitzhardinge wrote:
> >  
> >>Pasi Kärkkäinen wrote:
> >>    
> >>>I'll try upgrading from dom0/hackery to xen-tip/next and see how it works
> >>>for me. 
> >>> 
> >>>      
> >>Thanks.
> >>
> >>    
> >
> >It seems latest tree crashes for me (happened yesterday, and also today, 
> >just rebuilt the latest commits):
> >http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-26-xen331-linux-2.6.30-rc3-crash-no-highpte.txt
> >  
> 
> This is xen-tip/next?  Does master work any better?  How about running 
> as domU?
> 

Yep, it's xen-tip/next. I'll try xen-tip/master next.. 

-- Pasi

> Thanks,
>    J
> 
> >Zone PFN ranges:
> >  DMA      0x00000010 -> 0x00001000
> >  Normal   0x00001000 -> 0x000229fe
> >  HighMem  0x000229fe -> 0x00040000
> >Movable zone start PFN for each node
> >early_node_map[3] active PFN ranges
> >    0: 0x00000010 -> 0x0000009f
> >    0: 0x00000100 -> 0x00001167
> >    0: 0x00001268 -> 0x00040000
> >(XEN) d0:v0: unhandled page fault (ec=0003)
> >(XEN) Pagetable walk from c1268000:
> >(XEN)  L3[0x003] = 000000003c8f0001 000008f0
> >(XEN)  L2[0x009] = 000000003d276067 00001276 
> >(XEN)  L1[0x068] = 000000003d268061 00001268
> >(XEN) domain_crash_sync called from entry.S (ff19f70e)
> >(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> >(XEN) ----[ Xen-3.3.1-11.fc11  x86_32p  debug=n  Not tainted ]----
> >(XEN) CPU:    0
> >(XEN) EIP:    e019:[<c088adae>]
> >(XEN) EFLAGS: 00000206   EM: 1   CONTEXT: pv guest
> >(XEN) eax: 00000000   ebx: 00800000   ecx: 00200000   edx: c1268000
> >(XEN) esi: 01268000   edi: c1268000   ebp: c086de5c   esp: c086de1c
> >(XEN) cr0: 8005003b   cr4: 000006f0   cr3: 3c85c000   cr2: c1268000
> >(XEN) ds: e021   es: e021   fs: e021   gs: e021   ss: e021   cs: e019
> >(XEN) Guest stack trace from esp=c086de1c:
> >
> >[root@dom0test linux-2.6-xen]# gdb ./vmlinux
> >(gdb) x/i 0xc086de1c
> >0xc086de1c <init_thread_union+3612>:    add    %al,(%eax)
> >
> >32b PAE dom0, 32b PAE hypervisor. 
> >
> >
> >  
> >>>Btw how does dom0 upstreaming look at the moment? Ingo sent pull request
> >>>about some changes, and those got merged, but how about the rest? 
> >>>      
> >>Ingo basically ignored all the Xen changes in the leadup to the merge 
> >>window, then stomped on my attempt to get them merged with Linus, which 
> >>was all pretty annoying.  It had the doubly-irritating side-effect of 
> >>casting doubt over the controversy-free domU changes, so they didn't get 
> >>merged in the merge window either; by the time Ingo got around to OKing 
> >>them, the window had closed.  So all that got merged in the end was the 
> >>must-have bug fixes.
> >>
> >>    
> >
> >Yeah.. :( I really hope next merge window will be better..
> >
> >  
> >>Linus isn't going to pull any more major functionality changes in the 
> >>-rc kernels, and certainly isn't going to make an exception for Xen.  So 
> >>we're stuck with waiting for the .31 merge window.
> >>
> >>    
> >
> >I think it might be a good idea to start sending the patches already now, 
> >so
> >they get enough review before the .31 merge window.. 
> >
> >-- Pasi
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xensource.com
> >http://lists.xensource.com/xen-devel
> >  
> 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-04-26 14:51         ` Pasi Kärkkäinen
@ 2009-04-26 18:38           ` Pasi Kärkkäinen
  0 siblings, 0 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-04-26 18:38 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Xen-devel

On Sun, Apr 26, 2009 at 05:51:08PM +0300, Pasi Kärkkäinen wrote:
> On Sat, Apr 25, 2009 at 04:34:00PM -0700, Jeremy Fitzhardinge wrote:
> > Pasi Kärkkäinen wrote:
> > >On Thu, Apr 23, 2009 at 11:32:14AM -0700, Jeremy Fitzhardinge wrote:
> > >  
> > >>Pasi Kärkkäinen wrote:
> > >>    
> > >>>I'll try upgrading from dom0/hackery to xen-tip/next and see how it works
> > >>>for me. 
> > >>> 
> > >>>      
> > >>Thanks.
> > >>
> > >>    
> > >
> > >It seems latest tree crashes for me (happened yesterday, and also today, 
> > >just rebuilt the latest commits):
> > >http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-26-xen331-linux-2.6.30-rc3-crash-no-highpte.txt
> > >  
> > 
> > This is xen-tip/next?  Does master work any better?  How about running 
> > as domU?
> > 
> 
> Yep, it's xen-tip/next. I'll try xen-tip/master next.. 
>

xen-tip/master crashes aswell:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-27-xen331-linux-2.6.30-rc3-master-crash-no-highpte.txt

Zone PFN ranges:
  DMA      0x00000010 -> 0x00001000
  Normal   0x00001000 -> 0x000229fe
  HighMem  0x000229fe -> 0x00040000
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
    0: 0x00000010 -> 0x0000009f
    0: 0x00000100 -> 0x00001165
    0: 0x00001266 -> 0x00040000
(XEN) d0:v0: unhandled page fault (ec=0003)
(XEN) Pagetable walk from c1266000:
(XEN)  L3[0x003] = 000000003c8ee001 000008ee
(XEN)  L2[0x009] = 000000003d274067 00001274 
(XEN)  L1[0x066] = 000000003d266061 00001266
(XEN) domain_crash_sync called from entry.S (ff19f70e)
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-3.3.1-11.fc11  x86_32p  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) EIP:    e019:[<c0888d74>]
(XEN) EFLAGS: 00000206   EM: 1   CONTEXT: pv guest
(XEN) eax: 00000000   ebx: 00800000   ecx: 00200000   edx: c1266000
(XEN) esi: 01266000   edi: c1266000   ebp: c086be5c   esp: c086be1c
(XEN) cr0: 8005003b   cr4: 000006f0   cr3: 3c85a000   cr2: c1266000
(XEN) ds: e021   es: e021   fs: e021   gs: e021   ss: e021   cs: e019
(XEN) Guest stack trace from esp=c086be1c:

[root@dom0test linux-2.6-xen]# gdb ./vmlinux
(gdb) x/i 0xc086be1c
0xc086be1c <init_thread_union+3612>:    add    %al,(%eax)

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-24  8:59 ` Alex Zeffertt
@ 2009-04-27 15:44   ` Ian Campbell
  0 siblings, 0 replies; 118+ messages in thread
From: Ian Campbell @ 2009-04-27 15:44 UTC (permalink / raw)
  To: Alex Zeffertt; +Cc: Jeremy Fitzhardinge, Xen-devel

On Fri, 2009-04-24 at 04:59 -0400, Alex Zeffertt wrote:
> Jeremy Fitzhardinge wrote:
> > I finally fixed the AHCI problem with xen-tip/next and pushed forward 
> > with the long-threatened xen.git cleanup and reorg.
> > 
> > I've removed a pile of branches on 
> > git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git:
> > 
> >     * xen/*
> >     * push2/*
> >     * for-*/*
> > 
> 
> 
> Does this mean we need this patch in xen-unstable.hg?

I think so yes.

> Update XEN_LINUX_GIT_REMOTEBRANCH to match changes made in upstream repo.
> Needed if you want setting KERNELS=linux-2.6-pvops in config/Linux.mk to
> work.

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> 
> diff -r 8b152638adaa buildconfigs/mk.linux-2.6-pvops
> --- a/buildconfigs/mk.linux-2.6-pvops	Thu Apr 23 16:22:48 2009 +0100
> +++ b/buildconfigs/mk.linux-2.6-pvops	Fri Apr 24 09:53:40 2009 +0100
> @@ -7,7 +7,7 @@
> 
>   XEN_LINUX_GIT_URL ?= git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
>   XEN_LINUX_GIT_REMOTENAME ?= xen
> -XEN_LINUX_GIT_REMOTEBRANCH ?= xen/dom0/hackery
> +XEN_LINUX_GIT_REMOTEBRANCH ?= xen-tip/master
> 
>   EXTRAVERSION ?=
> 
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-04-25 11:54     ` xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0 Pasi Kärkkäinen
                         ` (2 preceding siblings ...)
  2009-04-25 23:34       ` Jeremy Fitzhardinge
@ 2009-04-27 19:33       ` Jeremy Fitzhardinge
  2009-04-27 19:38         ` Pasi Kärkkäinen
  3 siblings, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-04-27 19:33 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Xen-devel, Ian Campbell

Pasi Kärkkäinen wrote:
> On Thu, Apr 23, 2009 at 11:32:14AM -0700, Jeremy Fitzhardinge wrote:
>   
>> Pasi Kärkkäinen wrote:
>>     
>>> I'll try upgrading from dom0/hackery to xen-tip/next and see how it works
>>> for me. 
>>>  
>>>       
>> Thanks.
>>
>>     
>
> It seems latest tree crashes for me (happened yesterday, and also today, just rebuilt the latest commits):
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-26-xen331-linux-2.6.30-rc3-crash-no-highpte.txt
>
> Zone PFN ranges:
>   DMA      0x00000010 -> 0x00001000
>   Normal   0x00001000 -> 0x000229fe
>   HighMem  0x000229fe -> 0x00040000
> Movable zone start PFN for each node
> early_node_map[3] active PFN ranges
>     0: 0x00000010 -> 0x0000009f
>     0: 0x00000100 -> 0x00001167
>     0: 0x00001268 -> 0x00040000
> (XEN) d0:v0: unhandled page fault (ec=0003)
> (XEN) Pagetable walk from c1268000:
> (XEN)  L3[0x003] = 000000003c8f0001 000008f0
> (XEN)  L2[0x009] = 000000003d276067 00001276 
> (XEN)  L1[0x068] = 000000003d268061 00001268
> (XEN) domain_crash_sync called from entry.S (ff19f70e)
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-3.3.1-11.fc11  x86_32p  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) EIP:    e019:[<c088adae>]
> (XEN) EFLAGS: 00000206   EM: 1   CONTEXT: pv guest
> (XEN) eax: 00000000   ebx: 00800000   ecx: 00200000   edx: c1268000
> (XEN) esi: 01268000   edi: c1268000   ebp: c086de5c   esp: c086de1c
> (XEN) cr0: 8005003b   cr4: 000006f0   cr3: 3c85c000   cr2: c1268000
> (XEN) ds: e021   es: e021   fs: e021   gs: e021   ss: e021   cs: e019
> (XEN) Guest stack trace from esp=c086de1c:
>
> [root@dom0test linux-2.6-xen]# gdb ./vmlinux
> (gdb) x/i 0xc086de1c
> 0xc086de1c <init_thread_union+3612>:    add    %al,(%eax)
>
> 32b PAE dom0, 32b PAE hypervisor. 
>   
"x/i 0xc088adae" would be more useful, as that will show the faulting 
instruction.

I just booted a current xen-tip/next kernel as dom0 on my 32-bit machine 
with no problems, so I'm not sure what's going wrong on your machine.

Ian, have you tried 32-bit boots lately?

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-04-27 19:33       ` Jeremy Fitzhardinge
@ 2009-04-27 19:38         ` Pasi Kärkkäinen
       [not found]           ` <1240931113.22119.11.camel@zakaz.uk.xensource.com>
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-04-27 19:38 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Xen-devel, Ian Campbell

On Mon, Apr 27, 2009 at 12:33:01PM -0700, Jeremy Fitzhardinge wrote:
> Pasi Kärkkäinen wrote:
> >On Thu, Apr 23, 2009 at 11:32:14AM -0700, Jeremy Fitzhardinge wrote:
> >  
> >>Pasi Kärkkäinen wrote:
> >>    
> >>>I'll try upgrading from dom0/hackery to xen-tip/next and see how it works
> >>>for me. 
> >>> 
> >>>      
> >>Thanks.
> >>
> >>    
> >
> >
> >[root@dom0test linux-2.6-xen]# gdb ./vmlinux
> >(gdb) x/i 0xc086de1c
> >0xc086de1c <init_thread_union+3612>:    add    %al,(%eax)
> >
> >32b PAE dom0, 32b PAE hypervisor. 
> >  
> "x/i 0xc088adae" would be more useful, as that will show the faulting 
> instruction.
> 
> I just booted a current xen-tip/next kernel as dom0 on my 32-bit machine 
> with no problems, so I'm not sure what's going wrong on your machine.
> 

This is from xen-tip/master:

(XEN) d0:v0: unhandled page fault (ec=0003)
(XEN) Pagetable walk from c1266000:
(XEN)  L3[0x003] = 000000003c8ee001 000008ee
(XEN)  L2[0x009] = 000000003d274067 00001274 
(XEN)  L1[0x066] = 000000003d266061 00001266
(XEN) domain_crash_sync called from entry.S (ff19f70e)
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-3.3.1-11.fc11  x86_32p  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) EIP:    e019:[<c0888d74>]
(XEN) EFLAGS: 00000206   EM: 1   CONTEXT: pv guest
(XEN) eax: 00000000   ebx: 00800000   ecx: 00200000   edx: c1266000
(XEN) esi: 01266000   edi: c1266000   ebp: c086be5c   esp: c086be1c
(XEN) cr0: 8005003b   cr4: 000006f0   cr3: 3c85a000   cr2: c1266000
(XEN) ds: e021   es: e021   fs: e021   gs: e021   ss: e021   cs: e019
(XEN) Guest stack trace from esp=c086be1c:

[root@dom0test linux-2.6-xen]# gdb vmlinux
(gdb) x/i 0xc0888d74
0xc0888d74 <__constant_c_memset+21>:    rep stos %eax,%es:(%edi)

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
       [not found]           ` <1240846534.29824.101.camel@zakaz.uk.xensource.com>
@ 2009-04-27 19:46             ` Jeremy Fitzhardinge
  2009-04-27 20:18               ` Christophe Saout
  0 siblings, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-04-27 19:46 UTC (permalink / raw)
  To: Ian Campbell; +Cc: bderzhavets, Xen-devel, Christophe Saout

Ian Campbell wrote:
> My guess would be the change from
> CHECKSUM_{HW,etc}+skb->proto_{csum,data}_valid to
> CHECKSUM_{UNNECESSARY,PARTIAL,etc} is incomplete/incorrect. This should
> be taken care of by f4f969ffe1d9326ccaace768bde3b33a5ae49e71. I saw
> checksum offloading issues early on when I did this but I thought I got
> it right eventually, I'm pretty certain it was OK for me at the time at
> least.
>   

It looks like the checksum is a secondary issue.  My understanding is 
that things like TSO, USO, LRO, etc, depend on hardware checksumming, so 
disabling checksumming will implicitly disable the large segment 
features too.  And judging from Christophe's report, it seems that's the 
issue, with unexpectedly large packets appearing in dom0.

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-27 19:46             ` Jeremy Fitzhardinge
@ 2009-04-27 20:18               ` Christophe Saout
  0 siblings, 0 replies; 118+ messages in thread
From: Christophe Saout @ 2009-04-27 20:18 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Ian Campbell, bderzhavets, Xen-devel

Hi Jeremy,

> > My guess would be the change from
> > CHECKSUM_{HW,etc}+skb->proto_{csum,data}_valid to
> > CHECKSUM_{UNNECESSARY,PARTIAL,etc} is incomplete/incorrect. This should
> > be taken care of by f4f969ffe1d9326ccaace768bde3b33a5ae49e71. I saw
> > checksum offloading issues early on when I did this but I thought I got
> > it right eventually, I'm pretty certain it was OK for me at the time at
> > least.
> >   
> 
> It looks like the checksum is a secondary issue.  My understanding is 
> that things like TSO, USO, LRO, etc, depend on hardware checksumming, so 
> disabling checksumming will implicitly disable the large segment 
> features too.  And judging from Christophe's report, it seems that's the 
> issue, with unexpectedly large packets appearing in dom0.

The checksum offloading is fine, I've checked this in a couple of
different ways.  What I find strange, is that with TSO packets should be
chopped on their way out (in software, if the hardware doesn't support
it).  I am wondering who is sending the "fragmentation needed" reply in
the Dom0 network stack.

ip_forward.c for instance has something like this:

        if (unlikely(skb->len > dst_mtu(&rt->u.dst) && !skb_is_gso(skb) &&
                     (ip_hdr(skb)->frag_off & htons(IP_DF))) && !skb->local_df) 
                IP_INC_STATS(dev_net(rt->u.dst.dev), IPSTATS_MIB_FRAGFAILS);
                icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
                          htonl(dst_mtu(&rt->u.dst)));
                goto drop;
        }

So if the packet is *marked* as being segmentation offloaded it should
be passed to the NIC driver where it's handled.  At least that is my
understanding.  Turning on gso/tso support on the outgoing NIC doesn't
make a difference.

It seems that netfront/netback make sure that the GSO bits are passed on
correctly, but I would need to inspect the skbuff's in Dom0 to find out
if this is working correctly.  Because if the GSO bits in skbuff was for
some reason missing, it would explain the behaviour I am seeing.  Or, of
course, there's something else I am missing.

	Christophe

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-26  1:28 ` William Pitcock
@ 2009-04-27 20:50   ` Jeremy Fitzhardinge
  2009-04-27 21:07     ` William Pitcock
  0 siblings, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-04-27 20:50 UTC (permalink / raw)
  To: William Pitcock; +Cc: Xen-devel

William Pitcock wrote:
> Cloning git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> gives me the following:
>
> nenolod@petrie:~/dev-src$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-xen-next
> Initialized empty Git repository in /home/nenolod/dev-src/linux-xen-next/.git/
> remote: Counting objects: 1299853, done.
> remote: Compressing objects: 100% (227847/227847), done.
> remote: Total 1299853 (delta 1088065), reused 1275536 (delta 1064482)
> Receiving objects: 100% (1299853/1299853), 306.99 MiB | 411 KiB/s, done.
> Resolving deltas: 100% (1088065/1088065), done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> Something seems wrong here.
>   

I don't think its terribly significant; it just means the HEAD is 
pointing to a now-deleted branch.  I've re-pointed it to something 
sensible.  But either way, it shouldn't prevent you from checking out 
one of the branches.

Does it work for you now?

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-27 20:50   ` Jeremy Fitzhardinge
@ 2009-04-27 21:07     ` William Pitcock
  2009-04-27 23:48       ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 118+ messages in thread
From: William Pitcock @ 2009-04-27 21:07 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Xen-devel

On Mon, 2009-04-27 at 13:50 -0700, Jeremy Fitzhardinge wrote:
> William Pitcock wrote:
> > Cloning git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git
> > gives me the following:
> >
> > nenolod@petrie:~/dev-src$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git linux-xen-next
> > Initialized empty Git repository in /home/nenolod/dev-src/linux-xen-next/.git/
> > remote: Counting objects: 1299853, done.
> > remote: Compressing objects: 100% (227847/227847), done.
> > remote: Total 1299853 (delta 1088065), reused 1275536 (delta 1064482)
> > Receiving objects: 100% (1299853/1299853), 306.99 MiB | 411 KiB/s, done.
> > Resolving deltas: 100% (1088065/1088065), done.
> > warning: remote HEAD refers to nonexistent ref, unable to checkout.
> >
> > Something seems wrong here.
> >   
> 
> I don't think its terribly significant; it just means the HEAD is 
> pointing to a now-deleted branch.  I've re-pointed it to something 
> sensible.  But either way, it shouldn't prevent you from checking out 
> one of the branches.
> 
> Does it work for you now?

Yeah, it's working here now. Thanks for that.

We intend to start testing the 3.4 release candidate with 2.6.30
paravirt-ops dom0 in our test environment this weekend.

William

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-27 21:07     ` William Pitcock
@ 2009-04-27 23:48       ` Jeremy Fitzhardinge
  2009-04-28  7:13         ` William Pitcock
  0 siblings, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-04-27 23:48 UTC (permalink / raw)
  To: William Pitcock; +Cc: Xen-devel

William Pitcock wrote:
> Yeah, it's working here now. Thanks for that.
>
> We intend to start testing the 3.4 release candidate with 2.6.30
> paravirt-ops dom0 in our test environment this weekend.
>   

OK, that'll be interesting.  What's your test environment?

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-27 23:48       ` Jeremy Fitzhardinge
@ 2009-04-28  7:13         ` William Pitcock
  2009-04-28  9:14           ` Boris Derzhavets
  0 siblings, 1 reply; 118+ messages in thread
From: William Pitcock @ 2009-04-28  7:13 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Xen-devel

On Mon, 2009-04-27 at 16:48 -0700, Jeremy Fitzhardinge wrote:
> William Pitcock wrote:
> > Yeah, it's working here now. Thanks for that.
> >
> > We intend to start testing the 3.4 release candidate with 2.6.30
> > paravirt-ops dom0 in our test environment this weekend.
> >   
> 
> OK, that'll be interesting.  What's your test environment?

Paravirtualization-only nocona-based (early EM64T) Xeon hardware, with
nodes comprising of dual 2.8ghz CPUs with 8GB of memory, on Debian
testing.

Production is presently at 3.2 with XenLinux 2.6.18 patches rebased
against 2.6.26. Production machines are dual opteron 2216 machines with
8GB-16GB of RAM, with both HVM and Paravirtualized domains.

The test and production grids use the same storage backend, which is
presently provided through exporting LVM volumes with AoE and
cluster-lvm.

I could pull a spare server out of the production grid for testing HVM
under 2.6.30 if needed.

William

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-28  7:13         ` William Pitcock
@ 2009-04-28  9:14           ` Boris Derzhavets
  2009-04-28 14:51             ` William Pitcock
  0 siblings, 1 reply; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-28  9:14 UTC (permalink / raw)
  To: Jeremy Fitzhardinge, William Pitcock; +Cc: Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 1657 bytes --]

>I could pull a spare server out of the production 
>grid for testing HVM under 2.6.30 if needed.

As far as to my knowledge Xen 3.4-rc3-pre Dom0 & (2.6.30-rc3-tip)
support only PV DomUs. HVM is still unsolved problem.
If i am wrong about that, please advise.

Boris.


--- On Tue, 4/28/09, William Pitcock <nenolod@dereferenced.org> wrote:
From: William Pitcock <nenolod@dereferenced.org>
Subject: Re: [Xen-devel] xen.git branch reorg
To: "Jeremy Fitzhardinge" <jeremy@goop.org>
Cc: "Xen-devel" <xen-devel@lists.xensource.com>
Date: Tuesday, April 28, 2009, 3:13 AM

On Mon, 2009-04-27 at 16:48 -0700, Jeremy Fitzhardinge wrote:
> William Pitcock wrote:
> > Yeah, it's working here now. Thanks for that.
> >
> > We intend to start testing the 3.4 release candidate with 2.6.30
> > paravirt-ops dom0 in our test environment this weekend.
> >   
> 
> OK, that'll be interesting.  What's your test environment?

Paravirtualization-only nocona-based (early EM64T) Xeon hardware, with
nodes comprising of dual 2.8ghz CPUs with 8GB of memory, on Debian
testing.

Production is presently at 3.2 with XenLinux 2.6.18 patches rebased
against 2.6.26. Production machines are dual opteron 2216 machines with
8GB-16GB of RAM, with both HVM and Paravirtualized domains.

The test and production grids use the same storage backend, which is
presently provided through exporting LVM volumes with AoE and
cluster-lvm.

I could pull a spare server out of the production grid for testing HVM
under 2.6.30 if needed.

William


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 2148 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-28  9:14           ` Boris Derzhavets
@ 2009-04-28 14:51             ` William Pitcock
  2009-04-28 15:01               ` Boris Derzhavets
  0 siblings, 1 reply; 118+ messages in thread
From: William Pitcock @ 2009-04-28 14:51 UTC (permalink / raw)
  To: bderzhavets; +Cc: Jeremy Fitzhardinge, Xen-devel

I think you are talking about HVM PV drivers. HVM itself is no different
than booting a paravirtualized guest as far as the dom0 kernel is
concerned... the only difference is the running qemu-dm process or stub
domain.

William

On Tue, 2009-04-28 at 02:14 -0700, Boris Derzhavets wrote:
> >I could pull a spare server out of the production 
> >grid for testing HVM under 2.6.30 if needed.
> 
> As far as to my knowledge Xen 3.4-rc3-pre Dom0 & (2.6.30-rc3-tip)
> support only PV DomUs. HVM is still unsolved problem.
> If i am wrong about that, please advise.
> 
> Boris.
> 
> 
> --- On Tue, 4/28/09, William Pitcock <nenolod@dereferenced.org> wrote:
>         From: William Pitcock <nenolod@dereferenced.org>
>         Subject: Re: [Xen-devel] xen.git branch reorg
>         To: "Jeremy Fitzhardinge" <jeremy@goop.org>
>         Cc: "Xen-devel" <xen-devel@lists.xensource.com>
>         Date: Tuesday, April 28, 2009, 3:13 AM
>         
>         On Mon, 2009-04-27 at 16:48 -0700, Jeremy Fitzhardinge wrote:
>         > William Pitcock
>          wrote:
>         > > Yeah, it's working here now. Thanks for that.
>         > >
>         > > We intend to start testing the 3.4 release candidate with 2.6.30
>         > > paravirt-ops dom0 in our test environment this weekend.
>         > >   
>         > 
>         > OK, that'll be interesting.  What's your test environment?
>         
>         Paravirtualization-only nocona-based (early EM64T) Xeon hardware, with
>         nodes comprising of dual 2.8ghz CPUs with 8GB of memory, on Debian
>         testing.
>         
>         Production is presently at 3.2 with XenLinux 2.6.18 patches rebased
>         against 2.6.26. Production machines are dual opteron 2216 machines with
>         8GB-16GB of RAM, with both HVM and Paravirtualized domains.
>         
>         The test and production grids use the same storage backend, which is
>         presently provided through exporting LVM volumes with AoE and
>         cluster-lvm.
>         
>         I could pull a spare server out of the production grid for testing HVM
>         under 2.6.30 if
>          needed.
>         
>         William
>         
>         
>         _______________________________________________
>         Xen-devel mailing list
>         Xen-devel@lists.xensource.com
>         http://lists.xensource.com/xen-devel
> 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-28 14:51             ` William Pitcock
@ 2009-04-28 15:01               ` Boris Derzhavets
  2009-04-28 15:33                 ` William Pitcock
  0 siblings, 1 reply; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-28 15:01 UTC (permalink / raw)
  To: William Pitcock; +Cc: Jeremy Fitzhardinge, Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 2949 bytes --]

I am talking about usual HVM DomUs.
>the only difference is the running qemu-dm process or stub
> domain.

That's failing with current 2.6.30-rc3-tip under Xen 3.4-rc3-pre
at least through my experience.
Should be well known issue for Jeremy.

Boris.



--- On Tue, 4/28/09, William Pitcock <nenolod@dereferenced.org> wrote:
From: William Pitcock <nenolod@dereferenced.org>
Subject: Re: [Xen-devel] xen.git branch reorg
To: bderzhavets@yahoo.com
Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>, "Xen-devel" <xen-devel@lists.xensource.com>
Date: Tuesday, April 28, 2009, 10:51 AM

I think you are talking about HVM PV drivers. HVM itself is no different
than booting a paravirtualized guest as far as the dom0 kernel is
concerned... the only difference is the running qemu-dm process or stub
domain.

William

On Tue, 2009-04-28 at 02:14 -0700, Boris Derzhavets wrote:
> >I could pull a spare server out of the production 
> >grid for testing HVM under 2.6.30 if needed.
> 
> As far as to my knowledge Xen 3.4-rc3-pre Dom0 & (2.6.30-rc3-tip)
> support only PV DomUs. HVM is still unsolved problem.
> If i am wrong about that, please advise.
> 
> Boris.
> 
> 
> --- On Tue, 4/28/09, William Pitcock <nenolod@dereferenced.org>
wrote:
>         From: William Pitcock <nenolod@dereferenced.org>
>         Subject: Re: [Xen-devel] xen.git branch reorg
>         To: "Jeremy Fitzhardinge" <jeremy@goop.org>
>         Cc: "Xen-devel" <xen-devel@lists.xensource.com>
>         Date: Tuesday, April 28, 2009, 3:13 AM
>         
>         On Mon, 2009-04-27 at 16:48 -0700, Jeremy Fitzhardinge wrote:
>         > William Pitcock
>          wrote:
>         > > Yeah, it's working here now. Thanks for that.
>         > >
>         > > We intend to start testing the 3.4 release candidate
with 2.6.30
>         > > paravirt-ops dom0 in our test environment this weekend.
>         > >   
>         > 
>         > OK, that'll be interesting.  What's your test
environment?
>         
>         Paravirtualization-only nocona-based (early EM64T) Xeon hardware,
with
>         nodes comprising of dual 2.8ghz CPUs with 8GB of memory, on Debian
>         testing.
>         
>         Production is presently at 3.2 with XenLinux 2.6.18 patches
rebased
>         against 2.6.26. Production machines are dual opteron 2216 machines
with
>         8GB-16GB of RAM, with both HVM and Paravirtualized domains.
>         
>         The test and production grids use the same storage backend, which
is
>         presently provided through exporting LVM volumes with AoE and
>         cluster-lvm.
>         
>         I could pull a spare server out of the production grid for testing
HVM
>         under 2.6.30 if
>          needed.
>         
>         William
>         
>         
>         _______________________________________________
>         Xen-devel mailing list
>         Xen-devel@lists.xensource.com
>         http://lists.xensource.com/xen-devel
> 




      

[-- Attachment #1.2: Type: text/html, Size: 3746 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
       [not found]           ` <1240931113.22119.11.camel@zakaz.uk.xensource.com>
@ 2009-04-28 15:22             ` Pasi Kärkkäinen
  2009-04-28 15:41               ` Yum install xen on F10 Boris Derzhavets
  2009-04-28 16:25             ` xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0 Jeremy Fitzhardinge
  1 sibling, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-04-28 15:22 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Tue, Apr 28, 2009 at 04:05:13PM +0100, Ian Campbell wrote:
> On Mon, 2009-04-27 at 15:38 -0400, Pasi Kärkkäinen wrote:
> > [root@dom0test linux-2.6-xen]# gdb vmlinux
> > (gdb) x/i 0xc0888d74
> > 0xc0888d74 <__constant_c_memset+21>:    rep stos %eax,%es:(%edi)
> 
> I see basically the same thing, except I'm testing current xen-tip/next,
> 

Good to hear it's not only me :)

I also saw similar crash on xen-tip/next.

-- Pasi

> (XEN) d0:v0: unhandled page fault (ec=0003)
> (XEN) Pagetable walk from 00000000c0e5d000:
> (XEN)  L4[0x000] = 000000011b537027 0000000000000537
> (XEN)  L3[0x003] = 000000011b5b9027 00000000000005b9
> (XEN)  L2[0x007] = 000000011be64067 0000000000000e64 
> (XEN)  L1[0x05d] = 000000011be5d001 0000000000000e5d
> (XEN) domain_crash_sync called from entry.S
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-3.4-unstable  x86_64  debug=y  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e019:[<00000000c056bd2f>]
> (XEN) RFLAGS: 0000000000000287   EM: 1   CONTEXT: pv guest
> (XEN) rax: 0000000000000000   rbx: 0000000000000000   rcx: 0000000000000400
> (XEN) rdx: 00000000c0e5d000   rsi: 0000000000000000   rdi: 00000000c0e5d000
> (XEN) rbp: 00000000c0555d84   rsp: 00000000c0555d68   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
> (XEN) cr3: 000000011ffb0000   cr2: 00000000c0e5d000
> (XEN) ds: e021   es: e021   fs: e021   gs: e021   ss: e021   cs: e019
> 
> (gdb) disas 0x00000000c056bd2f
> [...]
> 0xc056bd2f <alloc_low_page+47>:	rep stos %eax,%es:(%edi)
> 
> The rough stack trace seems to be (unabridged version below):
>         c056bd2f: alloc_low_page + 47 in section .init.text
>         c056bda8: one_page_table_init + 88 in section .init.text
>         c056cddb: kernel_physical_mapping_init + 571 in
>         section .init.text
>         c03dae40: init_memory_mapping + 800 in section .text
>         c055f656: setup_arch + 1014 in section .init.text
>         c055a7b6: start_kernel + 118 in section .init.text
>         c055a076: i386_start_kernel + 86 in section .init.text
>         c055d1cb: xen_start_kernel + 955 in section .init.text
> 
> I thought
>         commit 4c76c04421dfe7be3e5a1d8ab1b2a3be0b02558e
>         Author: Yinghai Lu <yinghai@kernel.org>
>         Date:   Fri Mar 6 16:49:00 2009 -0800
>         
>             x86: introduce bootmem_state
> might be at fault but reverting doesn't improve matters. There's some
> other cleanup/unification patches in the recent-ish history of init_32.c
> which might be worth investigating further.
> 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-28 15:01               ` Boris Derzhavets
@ 2009-04-28 15:33                 ` William Pitcock
  2009-04-28 15:51                   ` Boris Derzhavets
  2009-04-28 16:28                   ` Jeremy Fitzhardinge
  0 siblings, 2 replies; 118+ messages in thread
From: William Pitcock @ 2009-04-28 15:33 UTC (permalink / raw)
  To: bderzhavets; +Cc: Jeremy Fitzhardinge, Xen-devel

Hmm.

I'll try to debug it if I have time over the weekend. It shouldn't be
very hard to do.

Do you have any specifics on what is failing?

William

On Tue, 2009-04-28 at 08:01 -0700, Boris Derzhavets wrote:
> I am talking about usual HVM DomUs.
> >the only difference is the running qemu-dm process or stub
> > domain.
> 
> That's failing with current 2.6.30-rc3-tip under Xen 3.4-rc3-pre
> at least through my experience.
> Should be well known issue for Jeremy.
> 
> Boris.
> 
> 
> 
> --- On Tue, 4/28/09, William Pitcock <nenolod@dereferenced.org> wrote:
>         From: William Pitcock <nenolod@dereferenced.org>
>         Subject: Re: [Xen-devel] xen.git branch reorg
>         To: bderzhavets@yahoo.com
>         Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>, "Xen-devel"
>         <xen-devel@lists.xensource.com>
>         Date: Tuesday, April 28, 2009, 10:51 AM
>         
>         I think you are talking about HVM PV drivers. HVM itself is no different
>         than
>          booting a paravirtualized guest as far as the dom0 kernel is
>         concerned... the only difference is the running qemu-dm process or stub
>         domain.
>         
>         William
>         
>         On Tue, 2009-04-28 at 02:14 -0700, Boris Derzhavets wrote:
>         > >I could pull a spare server out of the production 
>         > >grid for testing HVM under 2.6.30 if needed.
>         > 
>         > As far as to my knowledge Xen 3.4-rc3-pre Dom0 & (2.6.30-rc3-tip)
>         > support only PV DomUs. HVM is still unsolved problem.
>         > If i am wrong about that, please advise.
>         > 
>         > Boris.
>         > 
>         > 
>         > --- On Tue, 4/28/09, William Pitcock <nenolod@dereferenced.org>
>         wrote:
>         >         From: William Pitcock <nenolod@dereferenced.org>
>         >         Subject: Re: [Xen-devel] xen.git branch reorg
>         >         To: "Jeremy Fitzhardinge" <jeremy@goop.org>
>         >         Cc: "Xen-devel" <xen-devel@lists.xensource.com>
>         >         Date:
>          Tuesday, April 28, 2009, 3:13 AM
>         >         
>         >         On Mon, 2009-04-27 at 16:48 -0700, Jeremy Fitzhardinge wrote:
>         >         > William Pitcock
>         >          wrote:
>         >         > > Yeah, it's working here now. Thanks for that.
>         >         > >
>         >         > > We intend to start testing the 3.4 release candidate
>         with 2.6.30
>         >         > > paravirt-ops dom0 in our test environment this weekend.
>         >         > >   
>         >         > 
>         >         > OK, that'll be interesting.  What's your test
>         environment?
>         >         
>         >         Paravirtualization-only nocona-based (early EM64T) Xeon hardware,
>         with
>         >         nodes comprising of dual 2.8ghz CPUs with 8GB of memory, on Debian
>         >         testing.
>         >         
>         >         Production is presently at 3.2 with XenLinux 2.6.18 patches
>         rebased
>         >         against 2.6.26. Production machines
>          are dual opteron 2216 machines
>         with
>         >         8GB-16GB of RAM, with both HVM and Paravirtualized domains.
>         >         
>         >         The test and production grids use the same storage backend, which
>         is
>         >         presently provided through exporting LVM volumes with AoE and
>         >         cluster-lvm.
>         >         
>         >         I could pull a spare server out of the production grid for testing
>         HVM
>         >         under 2.6.30 if
>         >          needed.
>         >         
>         >         William
>         >         
>         >         
>         >         _______________________________________________
>         >         Xen-devel mailing list
>         >         Xen-devel@lists.xensource.com
>         >         http://lists.xensource.com/xen-devel
>         > 
>         
> 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Yum install xen on F10
  2009-04-28 15:22             ` Pasi Kärkkäinen
@ 2009-04-28 15:41               ` Boris Derzhavets
  2009-04-28 16:02                 ` M A Young
  2009-04-28 17:38                 ` Pasi Kärkkäinen
  0 siblings, 2 replies; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-28 15:41 UTC (permalink / raw)
  To: Ian Campbell, Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 374 bytes --]

Pasi,

You wrote on Wiki page :-
These features/patches are backported from Xen 3.4 development/unstable version to Fedora's Xen 3.3.x.
As far as i can see now :-
# yum install xen
on Fedora 10 (64-bit) installs Hypervisor which is unable to handle bzImage to load.
So, the only one chance is to wait until F11 GA. ( I want to load bzImage )

Boris.




      

[-- Attachment #1.2: Type: text/html, Size: 511 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-28 15:33                 ` William Pitcock
@ 2009-04-28 15:51                   ` Boris Derzhavets
  2009-04-28 16:28                   ` Jeremy Fitzhardinge
  1 sibling, 0 replies; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-28 15:51 UTC (permalink / raw)
  To: William Pitcock; +Cc: Jeremy Fitzhardinge, Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 7253 bytes --]

I've got a similar results

Boris

-- On Mon, 2/23/09, Jeremy Fitzhardinge <jeremy@goop.org> wrote:

    From: Jeremy Fitzhardinge <jeremy@goop.org>
    Subject: Re: [Xen-devel] HVM pvops failures
    To: "Ian Jackson" <Ian.Jackson@eu.citrix.com>
    Cc: "Andrew Lyon" <andrew.lyon@gmail.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, "Ian Campbell" <Ian.Campbell@citrix.com>
    Date: Monday, February 23, 2009, 7:12 PM

    Ian Jackson wrote:
    > Andrew Lyon writes ("Re: [Xen-devel] HVM guest question (was Re:
    [PATCH] ioemu: Cleanup the code of PCI passthrough.)"):
    >   
    >> On Mon, Feb 23, 2009 at 2:53 PM, Ian
     Jackson
    <Ian.Jackson@eu.citrix.com> wrote:
    >>     
    >>> These messages are not very surprising.  Is it working ?
    >>>       
    >> No, when try to start HVM on Xen unstable with pv_ops kernel I get
    this error:
    >>     
    >
    > Ah.  This is rather odd.  Normally I would hope that xend would report
    > an exit status.  (I haven't tried pvops with qemu.)
    >
    >   
    Hm, I'm getting:
    [2009-02-23 15:26:18 4380] WARNING (image:482) domain win7: device model 
    failure: pid 5409: died due to signal 7; see /var/log/xen/qemu-dm-win7.log

    Hm, signal 7 - SIGBUS.  I wonder if

    Using stub domains doesn't work either.

    > I would suggest running qemu-dm under strace.  This can be done easily
    > enough with a simple wrapper script, something like:
    >   #!/bin/sh
    >   set -e
    >   exec strace -vvs500 -f -o /root/qemu-dm.strace \
    >    
     /usr/lib/xen/bin/qemu-dm "$@"
    > and then give the name of the script as device_model in your config file.
    >   
    I see:

    ...
    5079  ioctl(10, EVIOCGKEYCODE, 0x7fffdfd52b70) = 0
    5079  clock_gettime(CLOCK_MONOTONIC, {1324, 539747423}) = 0
    5079  clock_gettime(CLOCK_MONOTONIC, {1324, 539837298}) = 0
    5079  select(14, [3 6 10 11 13], [], [], {0, 10000}) = 1 (in [10], left {0,
    9995})
    5079  read(10, "\36\0\0\0"..., 4)       = 4
    5079  write(10, "\36\0\0\0"..., 4)      = 4
    5079  ioctl(10, EVIOCGKEYCODE, 0x7fffdfd52b70) = 0
    5079  clock_gettime(CLOCK_MONOTONIC, {1324, 540495964}) = 0
    5079  clock_gettime(CLOCK_MONOTONIC, {1324, 540591278}) = 0
    5079  select(14, [3 6 10 11 13], [], [], {0, 10000}) = 1 (in [10], left {0,
    9995})
    5079  read(10, "\36\0\0\0"..., 4)       = 4
    5079  write(10, "\36\0\0\0"..., 4)      = 4
    5079  mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) =
    0x7f1ad5f2b000
    5079 
     ioctl(4, SNDCTL_DSP_STEREO, 0x7fffdfd52230) = 0
    5079  --- SIGBUS (Bus error) @ 0 (0) ---
    5157  +++ killed by SIGBUS +++


    This mmap and ioctl is from /proc/xen/privcmd.

        J

--- On Tue, 4/28/09, William Pitcock <nenolod@dereferenced.org> wrote:
From: William Pitcock <nenolod@dereferenced.org>
Subject: Re: [Xen-devel] xen.git branch reorg
To: bderzhavets@yahoo.com
Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>, "Xen-devel" <xen-devel@lists.xensource.com>
Date: Tuesday, April 28, 2009, 11:33 AM

Hmm.

I'll try to debug it if I have time over the weekend. It shouldn't be
very hard to do.

Do you have any specifics on what is failing?

William

On Tue, 2009-04-28 at 08:01 -0700, Boris Derzhavets wrote:
> I am talking about usual HVM DomUs.
> >the only difference is the running qemu-dm process or stub
> > domain.
> 
> That's failing with current 2.6.30-rc3-tip under Xen 3.4-rc3-pre
> at least through my experience.
> Should be well known issue for Jeremy.
> 
> Boris.
> 
> 
> 
> --- On Tue, 4/28/09, William Pitcock <nenolod@dereferenced.org>
wrote:
>         From: William Pitcock <nenolod@dereferenced.org>
>         Subject: Re: [Xen-devel] xen.git branch reorg
>         To: bderzhavets@yahoo.com
>         Cc: "Jeremy Fitzhardinge" <jeremy@goop.org>,
"Xen-devel"
>         <xen-devel@lists.xensource.com>
>         Date: Tuesday, April 28, 2009, 10:51 AM
>         
>         I think you are talking about HVM PV drivers. HVM itself is no
different
>         than
>          booting a paravirtualized guest as far as the dom0 kernel is
>         concerned... the only difference is the running qemu-dm process or
stub
>         domain.
>         
>         William
>         
>         On Tue, 2009-04-28 at 02:14 -0700, Boris Derzhavets wrote:
>         > >I could pull a spare server out of the production 
>         > >grid for testing HVM under 2.6.30 if needed.
>         > 
>         > As far as to my knowledge Xen 3.4-rc3-pre Dom0 &
(2.6.30-rc3-tip)
>         > support only PV DomUs. HVM is still unsolved problem.
>         > If i am wrong about that, please advise.
>         > 
>         > Boris.
>         > 
>         > 
>         > --- On Tue, 4/28/09, William Pitcock
<nenolod@dereferenced.org>
>         wrote:
>         >         From: William Pitcock
<nenolod@dereferenced.org>
>         >         Subject: Re: [Xen-devel] xen.git branch reorg
>         >         To: "Jeremy Fitzhardinge"
<jeremy@goop.org>
>         >         Cc: "Xen-devel"
<xen-devel@lists.xensource.com>
>         >         Date:
>          Tuesday, April 28, 2009, 3:13 AM
>         >         
>         >         On Mon, 2009-04-27 at 16:48 -0700, Jeremy
Fitzhardinge wrote:
>         >         > William Pitcock
>         >          wrote:
>         >         > > Yeah, it's working here now. Thanks for
that.
>         >         > >
>         >         > > We intend to start testing the 3.4 release
candidate
>         with 2.6.30
>         >         > > paravirt-ops dom0 in our test environment
this weekend.
>         >         > >   
>         >         > 
>         >         > OK, that'll be interesting.  What's your
test
>         environment?
>         >         
>         >         Paravirtualization-only nocona-based (early EM64T)
Xeon hardware,
>         with
>         >         nodes comprising of dual 2.8ghz CPUs with 8GB of
memory, on Debian
>         >         testing.
>         >         
>         >         Production is presently at 3.2 with XenLinux 2.6.18
patches
>         rebased
>         >         against 2.6.26. Production machines
>          are dual opteron 2216 machines
>         with
>         >         8GB-16GB of RAM, with both HVM and Paravirtualized
domains.
>         >         
>         >         The test and production grids use the same storage
backend, which
>         is
>         >         presently provided through exporting LVM volumes with
AoE and
>         >         cluster-lvm.
>         >         
>         >         I could pull a spare server out of the production
grid for testing
>         HVM
>         >         under 2.6.30 if
>         >          needed.
>         >         
>         >         William
>         >         
>         >         
>         >         _______________________________________________
>         >         Xen-devel mailing list
>         >         Xen-devel@lists.xensource.com
>         >         http://lists.xensource.com/xen-devel
>         > 
>         
> 




      

[-- Attachment #1.2: Type: text/html, Size: 9941 bytes --]

[-- Attachment #2: qemu-dm.strace.gz --]
[-- Type: application/x-gzip, Size: 47658 bytes --]

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: Yum install xen on F10
  2009-04-28 15:41               ` Yum install xen on F10 Boris Derzhavets
@ 2009-04-28 16:02                 ` M A Young
  2009-04-28 17:42                   ` Boris Derzhavets
  2009-05-01  9:13                   ` Boris Derzhavets
  2009-04-28 17:38                 ` Pasi Kärkkäinen
  1 sibling, 2 replies; 118+ messages in thread
From: M A Young @ 2009-04-28 16:02 UTC (permalink / raw)
  To: Boris Derzhavets; +Cc: Ian Campbell, Jeremy Fitzhardinge, Xen-devel

On Tue, 28 Apr 2009, Boris Derzhavets wrote:

> Pasi,
> 
> You wrote on Wiki page :-
> These features/patches are backported from Xen 3.4 development/unstable
> version to Fedora's Xen 3.3.x.
> As far as i can see now :-
> # yum install xen
> on Fedora 10 (64-bit) installs Hypervisor which is unable to handle bzImage
> to load.
> So, the only one chance is to wait until F11 GA. ( I want to load bzImage )

Or get the F11 source rpm and do an rpmbuild --rebuild on Fedora 10. It 
works for me.

 	Michael Young

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
       [not found]           ` <1240931113.22119.11.camel@zakaz.uk.xensource.com>
  2009-04-28 15:22             ` Pasi Kärkkäinen
@ 2009-04-28 16:25             ` Jeremy Fitzhardinge
       [not found]               ` <1240939020.22119.15.camel@zakaz.uk.xensource.com>
  1 sibling, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-04-28 16:25 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Xen-devel

Ian Campbell wrote:
> On Mon, 2009-04-27 at 15:38 -0400, Pasi Kärkkäinen wrote:
>   
>> [root@dom0test linux-2.6-xen]# gdb vmlinux
>> (gdb) x/i 0xc0888d74
>> 0xc0888d74 <__constant_c_memset+21>:    rep stos %eax,%es:(%edi)
>>     
>
> I see basically the same thing, except I'm testing current xen-tip/next,
>
> (XEN) d0:v0: unhandled page fault (ec=0003)
> (XEN) Pagetable walk from 00000000c0e5d000:
> (XEN)  L4[0x000] = 000000011b537027 0000000000000537
> (XEN)  L3[0x003] = 000000011b5b9027 00000000000005b9
> (XEN)  L2[0x007] = 000000011be64067 0000000000000e64 
> (XEN)  L1[0x05d] = 000000011be5d001 0000000000000e5d
> (XEN) domain_crash_sync called from entry.S
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) ----[ Xen-3.4-unstable  x86_64  debug=y  Not tainted ]----
> (XEN) CPU:    0
> (XEN) RIP:    e019:[<00000000c056bd2f>]
> (XEN) RFLAGS: 0000000000000287   EM: 1   CONTEXT: pv guest
> (XEN) rax: 0000000000000000   rbx: 0000000000000000   rcx: 0000000000000400
> (XEN) rdx: 00000000c0e5d000   rsi: 0000000000000000   rdi: 00000000c0e5d000
> (XEN) rbp: 00000000c0555d84   rsp: 00000000c0555d68   r8:  0000000000000000
> (XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
> (XEN) r12: 0000000000000000   r13: 0000000000000000   r14: 0000000000000000
> (XEN) r15: 0000000000000000   cr0: 000000008005003b   cr4: 00000000000006f0
> (XEN) cr3: 000000011ffb0000   cr2: 00000000c0e5d000
> (XEN) ds: e021   es: e021   fs: e021   gs: e021   ss: e021   cs: e019
>
> (gdb) disas 0x00000000c056bd2f
> [...]
> 0xc056bd2f <alloc_low_page+47>:	rep stos %eax,%es:(%edi)
>
> The rough stack trace seems to be (unabridged version below):
>         c056bd2f: alloc_low_page + 47 in section .init.text
>         c056bda8: one_page_table_init + 88 in section .init.text
>         c056cddb: kernel_physical_mapping_init + 571 in
>         section .init.text
>         c03dae40: init_memory_mapping + 800 in section .text
>         c055f656: setup_arch + 1014 in section .init.text
>         c055a7b6: start_kernel + 118 in section .init.text
>         c055a076: i386_start_kernel + 86 in section .init.text
>         c055d1cb: xen_start_kernel + 955 in section .init.text
>   

Interesting.  Curiously its working for me on my machine, but has a 
tendency to crash a bit later with a protection fault on an RO page 
during memory allocation.  I wonder if its related...

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg
  2009-04-28 15:33                 ` William Pitcock
  2009-04-28 15:51                   ` Boris Derzhavets
@ 2009-04-28 16:28                   ` Jeremy Fitzhardinge
  1 sibling, 0 replies; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-04-28 16:28 UTC (permalink / raw)
  To: William Pitcock; +Cc: bderzhavets, Xen-devel

William Pitcock wrote:
> Hmm.
>
> I'll try to debug it if I have time over the weekend. It shouldn't be
> very hard to do.
>
> Do you have any specifics on what is failing?
>   

For some reason the privcmd mappings are either not getting created 
properly, or are disappearing for some reason, causing a SIGBUS on 
qemu's privcmd mapping.  I put a bunch of printks in at one point, and 
couldn't see where it was failing.  I'm planning on having another go 
with all the tracing infrastructure I put in place, but feel free to 
look at it if you're so inclined.

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
       [not found]               ` <1240939020.22119.15.camel@zakaz.uk.xensource.com>
@ 2009-04-28 17:30                 ` Jeremy Fitzhardinge
       [not found]                   ` <1240989350.17173.2096.camel@localhost.localdomain>
  0 siblings, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-04-28 17:30 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Xen-devel

Ian Campbell wrote:
>> Interesting.  Curiously its working for me on my machine, but has a 
>> tendency to crash a bit later with a protection fault on an RO page 
>> during memory allocation.  I wonder if its related...
>>     
>
> Certainly smells similar.
>   

Yeah.  The fault in both cases has an error-code of 3, so a write 
protect fault.  It suggests a pinned page is getting freed into the 
general heap for some reason.  Except there are no complaints from Xen 
about writes into a pagetable, so that makes it look like page is being 
made RO but not (left) pinned.

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: Yum install xen on F10
  2009-04-28 15:41               ` Yum install xen on F10 Boris Derzhavets
  2009-04-28 16:02                 ` M A Young
@ 2009-04-28 17:38                 ` Pasi Kärkkäinen
  1 sibling, 0 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-04-28 17:38 UTC (permalink / raw)
  To: Boris Derzhavets; +Cc: Ian Campbell, Jeremy Fitzhardinge, Xen-devel

On Tue, Apr 28, 2009 at 08:41:55AM -0700, Boris Derzhavets wrote:
> Pasi,
> 
> You wrote on Wiki page :-
> These features/patches are backported from Xen 3.4 development/unstable version to Fedora's Xen 3.3.x.
> As far as i can see now :-
> # yum install xen
> on Fedora 10 (64-bit) installs Hypervisor which is unable to handle bzImage to load.
> So, the only one chance is to wait until F11 GA. ( I want to load bzImage )
> 

Yes, those backported patches are in F11 xen rpms.

I've been rebuilding that F11 (rawhide) xen src.rpm on F10.

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: Yum install xen on F10
  2009-04-28 16:02                 ` M A Young
@ 2009-04-28 17:42                   ` Boris Derzhavets
  2009-04-28 19:33                     ` Pasi Kärkkäinen
  2009-05-01  9:13                   ` Boris Derzhavets
  1 sibling, 1 reply; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-28 17:42 UTC (permalink / raw)
  To: M A Young; +Cc: Ian Campbell, Jeremy Fitzhardinge, Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 1435 bytes --]

Downloaded twice from different mirrors:-

[root@ServerFDR Download]# rpm -iv xen-3.3.1-11.fc11.src.rpm
warning: xen-3.3.1-11.fc11.src.rpm: Header V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2
xen-3.3.1-11.fc11
warning: user mockbuild does not exist - using root
warning: group mockbuild does not exist - using root
error: unpacking of archive failed on file /root/rpmbuild/SOURCES/grub-0.97.tar.gz;49f73923: cpio: MD5 sum mismatch

Same error comes up.

Boris.

--- On Tue, 4/28/09, M A Young <m.a.young@durham.ac.uk> wrote:
From: M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] Yum install xen on F10
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>, "Pasi Kärkkäinen" <pasik@iki.fi>, "Jeremy Fitzhardinge" <jeremy@goop.org>, "Xen-devel" <xen-devel@lists.xensource.com>
Date: Tuesday, April 28, 2009, 12:02 PM

On Tue, 28 Apr 2009, Boris Derzhavets wrote:

> Pasi,
> 
> You wrote on Wiki page :-
> These features/patches are backported from Xen 3.4 development/unstable
> version to Fedora's Xen 3.3.x.
> As far as i can see now :-
> # yum install xen
> on Fedora 10 (64-bit) installs Hypervisor which is unable to handle
bzImage
> to load.
> So, the only one chance is to wait until F11 GA. ( I want to load bzImage
)

Or get the F11 source rpm and do an rpmbuild --rebuild on Fedora 10. It works
for me.

	Michael Young



      

[-- Attachment #1.2: Type: text/html, Size: 1838 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: Yum install xen on F10
  2009-04-28 17:42                   ` Boris Derzhavets
@ 2009-04-28 19:33                     ` Pasi Kärkkäinen
  2009-04-28 19:40                       ` Boris Derzhavets
  2009-04-29  6:40                       ` Boris Derzhavets
  0 siblings, 2 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-04-28 19:33 UTC (permalink / raw)
  To: Boris Derzhavets; +Cc: Ian Campbell, Jeremy Fitzhardinge, Xen-devel, M A Young

On Tue, Apr 28, 2009 at 10:42:48AM -0700, Boris Derzhavets wrote:
> Downloaded twice from different mirrors:-
> 
> [root@ServerFDR Download]# rpm -iv xen-3.3.1-11.fc11.src.rpm
> warning: xen-3.3.1-11.fc11.src.rpm: Header V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2
> xen-3.3.1-11.fc11
> warning: user mockbuild does not exist - using root
> warning: group mockbuild does not exist - using root
> error: unpacking of archive failed on file /root/rpmbuild/SOURCES/grub-0.97.tar.gz;49f73923: cpio: MD5 sum mismatch
> 
> Same error comes up.
> 

Do you have latest updates installed to your F10? F11 switched to new rpm
version, and that new rpm version should be in F10 updates aswell..

-- Pasi

> Boris.
> 
> --- On Tue, 4/28/09, M A Young <m.a.young@durham.ac.uk> wrote:
> From: M A Young <m.a.young@durham.ac.uk>
> Subject: Re: [Xen-devel] Yum install xen on F10
> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>, "Pasi Kärkkäinen" <pasik@iki.fi>, "Jeremy Fitzhardinge" <jeremy@goop.org>, "Xen-devel" <xen-devel@lists.xensource.com>
> Date: Tuesday, April 28, 2009, 12:02 PM
> 
> On Tue, 28 Apr 2009, Boris Derzhavets wrote:
> 
> > Pasi,
> > 
> > You wrote on Wiki page :-
> > These features/patches are backported from Xen 3.4 development/unstable
> > version to Fedora's Xen 3.3.x.
> > As far as i can see now :-
> > # yum install xen
> > on Fedora 10 (64-bit) installs Hypervisor which is unable to handle
> bzImage
> > to load.
> > So, the only one chance is to wait until F11 GA. ( I want to load bzImage
> )
> 
> Or get the F11 source rpm and do an rpmbuild --rebuild on Fedora 10. It works
> for me.
> 
> 	Michael Young
> 
> 
> 
>       

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: Yum install xen on F10
  2009-04-28 19:33                     ` Pasi Kärkkäinen
@ 2009-04-28 19:40                       ` Boris Derzhavets
  2009-04-29  6:40                       ` Boris Derzhavets
  1 sibling, 0 replies; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-28 19:40 UTC (permalink / raw)
  To: Pasi Kärkkäinen
  Cc: Ian Campbell, Jeremy Fitzhardinge, Xen-devel, M A Young


[-- Attachment #1.1: Type: text/plain, Size: 2218 bytes --]

Thank you. Will update F10.
Boris.

--- On Tue, 4/28/09, Pasi Kärkkäinen <pasik@iki.fi> wrote:
From: Pasi Kärkkäinen <pasik@iki.fi>
Subject: Re: [Xen-devel] Yum install xen on F10
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "M A Young" <m.a.young@durham.ac.uk>, "Ian Campbell" <Ian.Campbell@eu.citrix.com>, "Jeremy Fitzhardinge" <jeremy@goop.org>, "Xen-devel" <xen-devel@lists.xensource.com>
Date: Tuesday, April 28, 2009, 3:33 PM

On Tue, Apr 28, 2009 at 10:42:48AM -0700, Boris Derzhavets wrote:
> Downloaded twice from different mirrors:-
> 
> [root@ServerFDR Download]# rpm -iv xen-3.3.1-11.fc11.src.rpm
> warning: xen-3.3.1-11.fc11.src.rpm: Header V3 RSA/SHA256 signature: NOKEY,
key ID d22e77f2
> xen-3.3.1-11.fc11
> warning: user mockbuild does not exist - using root
> warning: group mockbuild does not exist - using root
> error: unpacking of archive failed on file
/root/rpmbuild/SOURCES/grub-0.97.tar.gz;49f73923: cpio: MD5 sum mismatch
> 
> Same error comes up.
> 

Do you have latest updates installed to your F10? F11 switched to new rpm
version, and that new rpm version should be in F10 updates aswell..

-- Pasi

> Boris.
> 
> --- On Tue, 4/28/09, M A Young <m.a.young@durham.ac.uk> wrote:
> From: M A Young <m.a.young@durham.ac.uk>
> Subject: Re: [Xen-devel] Yum install xen on F10
> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
"Pasi Kärkkäinen" <pasik@iki.fi>, "Jeremy
Fitzhardinge" <jeremy@goop.org>, "Xen-devel"
<xen-devel@lists.xensource.com>
> Date: Tuesday, April 28, 2009, 12:02 PM
> 
> On Tue, 28 Apr 2009, Boris Derzhavets wrote:
> 
> > Pasi,
> > 
> > You wrote on Wiki page :-
> > These features/patches are backported from Xen 3.4
development/unstable
> > version to Fedora's Xen 3.3.x.
> > As far as i can see now :-
> > # yum install xen
> > on Fedora 10 (64-bit) installs Hypervisor which is unable to handle
> bzImage
> > to load.
> > So, the only one chance is to wait until F11 GA. ( I want to load
bzImage
> )
> 
> Or get the F11 source rpm and do an rpmbuild --rebuild on Fedora 10. It
works
> for me.
> 
> 	Michael Young
> 
> 
> 
>       



      

[-- Attachment #1.2: Type: text/html, Size: 2852 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: Yum install xen on F10
  2009-04-28 19:33                     ` Pasi Kärkkäinen
  2009-04-28 19:40                       ` Boris Derzhavets
@ 2009-04-29  6:40                       ` Boris Derzhavets
  1 sibling, 0 replies; 118+ messages in thread
From: Boris Derzhavets @ 2009-04-29  6:40 UTC (permalink / raw)
  To: Pasi Kärkkäinen
  Cc: Ian Campbell, Jeremy Fitzhardinge, Xen-devel, M A Young


[-- Attachment #1.1: Type: text/plain, Size: 2743 bytes --]

Pasi,

[root@ServerFDR10 ~]# rpm -qa|grep xen
xen-libs-3.3.0-1.fc10.x86_64
xen-hypervisor-3.3.0-1.fc10.x86_64
jaxen-1.1-1.3.fc10.noarch
xen-runtime-3.3.0-1.fc10.x86_64
xen-3.3.0-1.fc10.x86_64


I've tested "yum update" and "yum upgrade" neither one of packages list had
been obtained before download started showed up xen-packages supposed to be refreshed.

Maybe i was doing something wrong ?

Boris.

--- On Tue, 4/28/09, Pasi Kärkkäinen <pasik@iki.fi> wrote:
From: Pasi Kärkkäinen <pasik@iki.fi>
Subject: Re: [Xen-devel] Yum install xen on F10
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>, "Jeremy Fitzhardinge" <jeremy@goop.org>, "Xen-devel" <xen-devel@lists.xensource.com>, "M A Young" <m.a.young@durham.ac.uk>
Date: Tuesday, April 28, 2009, 3:33 PM

On Tue, Apr 28, 2009 at 10:42:48AM -0700, Boris Derzhavets wrote:
> Downloaded twice from different mirrors:-
> 
> [root@ServerFDR Download]# rpm -iv xen-3.3.1-11.fc11.src.rpm
> warning: xen-3.3.1-11.fc11.src.rpm: Header V3 RSA/SHA256 signature: NOKEY,
key ID d22e77f2
> xen-3.3.1-11.fc11
> warning: user mockbuild does not exist - using root
> warning: group mockbuild does not exist - using root
> error: unpacking of archive failed on file
/root/rpmbuild/SOURCES/grub-0.97.tar.gz;49f73923: cpio: MD5 sum mismatch
> 
> Same error comes up.
> 

Do you have latest updates installed to your F10? F11 switched to new rpm
version, and that new rpm version should be in F10 updates aswell..

-- Pasi

> Boris.
> 
> --- On Tue, 4/28/09, M A Young <m.a.young@durham.ac.uk> wrote:
> From: M A Young <m.a.young@durham.ac.uk>
> Subject: Re: [Xen-devel] Yum install xen on F10
> To: "Boris Derzhavets" <bderzhavets@yahoo.com>
> Cc: "Ian Campbell" <Ian.Campbell@eu.citrix.com>,
"Pasi Kärkkäinen" <pasik@iki.fi>, "Jeremy
Fitzhardinge" <jeremy@goop.org>, "Xen-devel"
<xen-devel@lists.xensource.com>
> Date: Tuesday, April 28, 2009, 12:02 PM
> 
> On Tue, 28 Apr 2009, Boris Derzhavets wrote:
> 
> > Pasi,
> > 
> > You wrote on Wiki page :-
> > These features/patches are backported from Xen 3.4
development/unstable
> > version to Fedora's Xen 3.3.x.
> > As far as i can see now :-
> > # yum install xen
> > on Fedora 10 (64-bit) installs Hypervisor which is unable to handle
> bzImage
> > to load.
> > So, the only one chance is to wait until F11 GA. ( I want to load
bzImage
> )
> 
> Or get the F11 source rpm and do an rpmbuild --rebuild on Fedora 10. It
works
> for me.
> 
> 	Michael Young
> 
> 
> 
>       

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 3417 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
       [not found]                   ` <1240989350.17173.2096.camel@localhost.localdomain>
@ 2009-04-29 16:25                     ` Jeremy Fitzhardinge
  2009-05-01  9:58                       ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-04-29 16:25 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Xen-devel

Ian Campbell wrote:
> On Tue, 2009-04-28 at 13:30 -0400, Jeremy Fitzhardinge wrote:
>   
>> Ian Campbell wrote:
>>     
>>>> Interesting.  Curiously its working for me on my machine, but has a 
>>>> tendency to crash a bit later with a protection fault on an RO page 
>>>> during memory allocation.  I wonder if its related...
>>>>     
>>>>         
>>> Certainly smells similar.
>>>   
>>>       
>> Yeah.  The fault in both cases has an error-code of 3, so a write 
>> protect fault.  It suggests a pinned page is getting freed into the 
>> general heap for some reason.  Except there are no complaints from Xen 
>> about writes into a pagetable, so that makes it look like page is being 
>> made RO but not (left) pinned.
>>     
>
> The crash Pasi and I are seeing is pretty early on though, is there any
> opportunity for a page table page to have been recycled before
> ~kernel_physical_mapping_init()? I'd have thought not.
>   

No, sounds unlikely.

> I was wondering if perhaps e820_table_start (used by alloc_low_page) had
> somehow got initialised to a bogus value such that it was pointing at
> the domain builder supplied page tables (hence RO but not marked as
> pinned yet).

Well, Xen would know they're pinned, even if the kernel's structures 
don't, one would expect to see any completely bogus writes appear on the 
Xen console.

>  There was some unification work in this area around the
> beginning of March although I'm pretty such I've had it work much more
> recently. (I guess it might not have been merged into a visible branch
> until more recently, it's a bit hard to tell with git but I don't think
> that's what happened).

Yeah, I think it has been working properly for some since then, though I 
think Pasi has been reporting problems since 32-bit dom0 first booted.

My symptoms are a bit all over the place.  For a while I was just seeing 
writes-to-RO pages, but since I added some debugging to try and work out 
where that was happening, I'm now seeing more major pagetable corruption 
(like instruction fetches failing because of reserved bits being set in 
the pagetable...).  So something is stomping pagetable, and I think its 
some page being freed.

I think these are somewhat similar to Pasi's symptoms which he said that 
disabling HIGHPTE fixed.   I see problems independent of the HIGHPTE 
setting.

I have best success in causing crashes when scp'ing a 8GB file onto my 
XFS /home filesystem.  XFS does quite a lot of vmapping, so that may 
exacerbate the problem.

I also realized that my Xen doesn't have debug=y set, so I'm probably 
missing some information.

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: Yum install xen on F10
  2009-04-28 16:02                 ` M A Young
  2009-04-28 17:42                   ` Boris Derzhavets
@ 2009-05-01  9:13                   ` Boris Derzhavets
  2009-05-01  9:26                     ` John Haxby
  2009-05-01 10:55                     ` M A Young
  1 sibling, 2 replies; 118+ messages in thread
From: Boris Derzhavets @ 2009-05-01  9:13 UTC (permalink / raw)
  To: M A Young; +Cc: Ian Campbell, Jeremy Fitzhardinge, Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 802 bytes --]

Michael,

I upgraded F10 . Attempt "rpmbuild --rebuild" still failed (on 64-bit system) due to line in xen.spec:-

# so that x86_64 builds pick up glibc32 correctly
BuildRequires: /usr/include/gnu/stubs-32.h

It's not a problem to obtain and install  /usr/include/gnu/stubs-32.h.
I also tried create a symlink to it in SOURCES. No luck.
glibc32 headers rpm cannot be installed on F10. It requires 
all glibc32 rpms install. It conflicts with glibc64 already installed.

Like in previous time i just commented it out and rebuilt
xen 3.3.1 rpms.

# rpmbuild -ba ./xen.spec

PV domus are not affected.  I believe , it might affect HVM at the point 
when pvops kernel will be fixed to support HVM.
On the other side i guess F11 will be out earlier.

Thanks.
Boris.






      

[-- Attachment #1.2: Type: text/html, Size: 979 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: Yum install xen on F10
  2009-05-01  9:13                   ` Boris Derzhavets
@ 2009-05-01  9:26                     ` John Haxby
  2009-05-01 10:51                       ` Boris Derzhavets
  2009-05-01 10:55                     ` M A Young
  1 sibling, 1 reply; 118+ messages in thread
From: John Haxby @ 2009-05-01  9:26 UTC (permalink / raw)
  To: bderzhavets; +Cc: Ian Campbell, Jeremy Fitzhardinge, Xen-devel, M A Young

Boris Derzhavets wrote:
> Michael,
>
> I upgraded F10 . Attempt "rpmbuild --rebuild" still failed (on 64-bit 
> system) due to line in xen.spec:-
>
> # so that x86_64 builds pick up glibc32 correctly
> BuildRequires: /usr/include/gnu/stubs-32.h
>
> It's not a problem to obtain and install  /usr/include/gnu/stubs-32.h.
> I also tried create a symlink to it in SOURCES. No luck.
> glibc32 headers rpm cannot be installed on F10. It requires
> all glibc32 rpms install. It conflicts with glibc64 already installed.
>
I have glibc-devel.i386 and glibc-devel.x86_64 installed on my F10 
machine, no conflicts.

Do you have some other problem?

jch

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-04-29 16:25                     ` Jeremy Fitzhardinge
@ 2009-05-01  9:58                       ` Pasi Kärkkäinen
  2009-05-01 18:35                         ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-05-01  9:58 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Ian Campbell, Xen-devel

On Wed, Apr 29, 2009 at 09:25:24AM -0700, Jeremy Fitzhardinge wrote:
> 
> > There was some unification work in this area around the
> >beginning of March although I'm pretty such I've had it work much more
> >recently. (I guess it might not have been merged into a visible branch
> >until more recently, it's a bit hard to tell with git but I don't think
> >that's what happened).
> 
> Yeah, I think it has been working properly for some since then, though I 
> think Pasi has been reporting problems since 32-bit dom0 first booted.
> 

Yep, I've had problems from the beginning.. 

dom0/hackery was working pretty OK for me before it was removed.. 
I could run and install new PV guests etc.

> My symptoms are a bit all over the place.  For a while I was just seeing 
> writes-to-RO pages, but since I added some debugging to try and work out 
> where that was happening, I'm now seeing more major pagetable corruption 
> (like instruction fetches failing because of reserved bits being set in 
> the pagetable...).  So something is stomping pagetable, and I think its 
> some page being freed.
> 
> I think these are somewhat similar to Pasi's symptoms which he said that 
> disabling HIGHPTE fixed.   I see problems independent of the HIGHPTE 
> setting.
> 

CONFIG_HIGHPTE=n fixed my "dom0 kernel crashes while compiling kernel source in dom0" test.. 
could be the problem still happens with some other tests though.. 

> I have best success in causing crashes when scp'ing a 8GB file onto my 
> XFS /home filesystem.  XFS does quite a lot of vmapping, so that may 
> exacerbate the problem.
> 

I could try scp aswell.. 

> I also realized that my Xen doesn't have debug=y set, so I'm probably 
> missing some information.
> 

Hmm, good point. I don't have debug=y either.. 

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: Yum install xen on F10
  2009-05-01  9:26                     ` John Haxby
@ 2009-05-01 10:51                       ` Boris Derzhavets
  0 siblings, 0 replies; 118+ messages in thread
From: Boris Derzhavets @ 2009-05-01 10:51 UTC (permalink / raw)
  To: John Haxby; +Cc: Ian Campbell, Jeremy Fitzhardinge, Xen-devel, M A Young


[-- Attachment #1.1: Type: text/plain, Size: 2872 bytes --]

I've tried to follow your advise:-

[root@ServerFDR10 Download]# uname -a
Linux ServerFDR10 2.6.27.21-170.2.56.fc10.x86_64 #1 SMP Mon Mar 23 23:08:10 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

[root@ServerFDR10 Download]# ls -l
total 29928
-rw-rw-r-- 1 boris boris  4999329 2009-04-30 12:26 glibc-2.9-2.i386.rpm
-rw-rw-r-- 1 boris boris 22727800 2009-04-30 12:35 glibc-common-2.9-2.i386.rpm
-rw-rw-r-- 1 boris boris  2228772 2009-04-30 12:36 glibc-devel-2.9-2.i386.rpm
-rw-rw-r-- 1 boris boris   630193 2009-04-30 12:31 glibc-headers-2.9-2.i386.rpm
-rwxr--r-- 1 root  root       120 2009-04-30 12:38 inst.sh

[root@ServerFDR10 Download]# rpm -ivh glibc-devel-2.9-2.i386.rpm
error: Failed dependencies:
    glibc = 2.9-2 is needed by glibc-devel-2.9-2.i386
    glibc-headers = 2.9-2 is needed by glibc-devel-2.9-2.i386
    libBrokenLocale.so.1 is needed by glibc-devel-2.9-2.i386
    libanl.so.1 is needed by glibc-devel-2.9-2.i386
    libcidn.so.1 is needed by glibc-devel-2.9-2.i386
    libcrypt.so.1 is needed by glibc-devel-2.9-2.i386
    libdl.so.2 is needed by glibc-devel-2.9-2.i386
    libm.so.6 is needed by glibc-devel-2.9-2.i386
    libnsl.so.1 is needed by glibc-devel-2.9-2.i386
    libnss_compat.so.2 is needed by glibc-devel-2.9-2.i386
    libnss_dns.so.2 is needed by glibc-devel-2.9-2.i386
    libnss_files.so.2 is needed by glibc-devel-2.9-2.i386
    libnss_hesiod.so.2 is needed by glibc-devel-2.9-2.i386
    libnss_nis.so.2 is needed by glibc-devel-2.9-2.i386
    libnss_nisplus.so.2 is needed by glibc-devel-2.9-2.i386
    libresolv.so.2 is needed by glibc-devel-2.9-2.i386
    librt.so.1 is needed by glibc-devel-2.9-2.i386
    libthread_db.so.1 is needed by glibc-devel-2.9-2.i386
    libutil.so.1 is needed by glibc-devel-2.9-2.i386

Boris.

--- On Fri, 5/1/09, John Haxby <john.haxby@oracle.com> wrote:
From: John Haxby <john.haxby@oracle.com>
Subject: Re: [Xen-devel] Yum install xen on F10
To: bderzhavets@yahoo.com
Cc: "M A Young" <m.a.young@durham.ac.uk>, "Ian Campbell" <Ian.Campbell@eu.citrix.com>, "Jeremy Fitzhardinge" <jeremy@goop.org>, "Xen-devel" <xen-devel@lists.xensource.com>
Date: Friday, May 1, 2009, 5:26 AM

Boris Derzhavets wrote:
> Michael,
>
> I upgraded F10 . Attempt "rpmbuild --rebuild" still failed (on
64-bit 
> system) due to line in xen.spec:-
>
> # so that x86_64 builds pick up glibc32 correctly
> BuildRequires: /usr/include/gnu/stubs-32.h
>
> It's not a problem to obtain and install  /usr/include/gnu/stubs-32.h.
> I also tried create a symlink to it in SOURCES. No luck.
> glibc32 headers rpm cannot be installed on F10. It requires
> all glibc32 rpms install. It conflicts with glibc64 already installed.
>
I have glibc-devel.i386 and glibc-devel.x86_64 installed on my F10 
machine, no conflicts.

Do you have some other problem?

jch




      

[-- Attachment #1.2: Type: text/html, Size: 3676 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: Yum install xen on F10
  2009-05-01  9:13                   ` Boris Derzhavets
  2009-05-01  9:26                     ` John Haxby
@ 2009-05-01 10:55                     ` M A Young
  2009-05-01 11:19                       ` Boris Derzhavets
  1 sibling, 1 reply; 118+ messages in thread
From: M A Young @ 2009-05-01 10:55 UTC (permalink / raw)
  To: Boris Derzhavets; +Cc: Xen-devel

On Fri, 1 May 2009, Boris Derzhavets wrote:

> Michael,
> 
> I upgraded F10 . Attempt "rpmbuild --rebuild" still failed (on 64-bit
> system) due to line in xen.spec:-
> 
> # so that x86_64 builds pick up glibc32 correctly
> BuildRequires: /usr/include/gnu/stubs-32.h

yum install glibc-devel.i386

 	Michael Young

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: Yum install xen on F10
  2009-05-01 10:55                     ` M A Young
@ 2009-05-01 11:19                       ` Boris Derzhavets
  0 siblings, 0 replies; 118+ messages in thread
From: Boris Derzhavets @ 2009-05-01 11:19 UTC (permalink / raw)
  To: M A Young; +Cc: Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 770 bytes --]

Thank you, Michael.
Boris

--- On Fri, 5/1/09, M A Young <m.a.young@durham.ac.uk> wrote:
From: M A Young <m.a.young@durham.ac.uk>
Subject: Re: [Xen-devel] Yum install xen on F10
To: "Boris Derzhavets" <bderzhavets@yahoo.com>
Cc: "Xen-devel" <xen-devel@lists.xensource.com>
Date: Friday, May 1, 2009, 6:55 AM

On Fri, 1 May 2009, Boris Derzhavets wrote:

> Michael,
> 
> I upgraded F10 . Attempt "rpmbuild --rebuild" still failed (on
64-bit
> system) due to line in xen.spec:-
> 
> # so that x86_64 builds pick up glibc32 correctly
> BuildRequires: /usr/include/gnu/stubs-32.h

yum install glibc-devel.i386

	Michael Young

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel



      

[-- Attachment #1.2: Type: text/html, Size: 1157 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-05-01  9:58                       ` Pasi Kärkkäinen
@ 2009-05-01 18:35                         ` Jeremy Fitzhardinge
  2009-05-05 17:19                           ` Pasi Kärkkäinen
  2009-05-06  6:48                           ` xen.git branch reorg / crash " Jiang, Yunhong
  0 siblings, 2 replies; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-05-01 18:35 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Ian Campbell, Xen-devel

Pasi Kärkkäinen wrote:
> On Wed, Apr 29, 2009 at 09:25:24AM -0700, Jeremy Fitzhardinge wrote:
>   
>>> There was some unification work in this area around the
>>> beginning of March although I'm pretty such I've had it work much more
>>> recently. (I guess it might not have been merged into a visible branch
>>> until more recently, it's a bit hard to tell with git but I don't think
>>> that's what happened).
>>>       
>> Yeah, I think it has been working properly for some since then, though I 
>> think Pasi has been reporting problems since 32-bit dom0 first booted.
>>
>>     
>
> Yep, I've had problems from the beginning.. 
>
> dom0/hackery was working pretty OK for me before it was removed.. 
> I could run and install new PV guests etc.
>   

Sorry, perhaps I was too hasty in removing the branches.  Though you 
still have references in your own git tree?

You still had problems with HIGHPTE in hackery?  My suspicion is that 
we're seeing the same bug manifesting in a much more obvious way, since 
I'm seeing somewhat similar symptoms, even without HIGHPTE.

>> I also realized that my Xen doesn't have debug=y set, so I'm probably 
>> missing some information.
>>
>>     
>
> Hmm, good point. I don't have debug=y either.. 
>   

That would be useful.  It would be interesting to see if Xen complains 
about any stray pte writes.

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-05-01 18:35                         ` Jeremy Fitzhardinge
@ 2009-05-05 17:19                           ` Pasi Kärkkäinen
  2009-05-05 20:10                             ` Jeremy Fitzhardinge
  2009-05-06  6:48                           ` xen.git branch reorg / crash " Jiang, Yunhong
  1 sibling, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-05-05 17:19 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Ian Campbell, Xen-devel

On Fri, May 01, 2009 at 11:35:19AM -0700, Jeremy Fitzhardinge wrote:
> Pasi Kärkkäinen wrote:
> >On Wed, Apr 29, 2009 at 09:25:24AM -0700, Jeremy Fitzhardinge wrote:
> >  
> >>>There was some unification work in this area around the
> >>>beginning of March although I'm pretty such I've had it work much more
> >>>recently. (I guess it might not have been merged into a visible branch
> >>>until more recently, it's a bit hard to tell with git but I don't think
> >>>that's what happened).
> >>>      
> >>Yeah, I think it has been working properly for some since then, though I 
> >>think Pasi has been reporting problems since 32-bit dom0 first booted.
> >>
> >>    
> >
> >Yep, I've had problems from the beginning.. 
> >
> >dom0/hackery was working pretty OK for me before it was removed.. 
> >I could run and install new PV guests etc.
> >  
> 
> Sorry, perhaps I was too hasty in removing the branches.  Though you 
> still have references in your own git tree?
> 
> You still had problems with HIGHPTE in hackery?  My suspicion is that 
> we're seeing the same bug manifesting in a much more obvious way, since 
> I'm seeing somewhat similar symptoms, even without HIGHPTE.
> 

Actually I didn't try with CONFIG_HIGHPTE=y for some time, since I didn't see 
any notes about it being fixed/changed..

> >>I also realized that my Xen doesn't have debug=y set, so I'm probably 
> >>missing some information.
> >>
> >>    
> >
> >Hmm, good point. I don't have debug=y either.. 
> >  
> 
> That would be useful.  It would be interesting to see if Xen complains 
> about any stray pte writes.
> 

And here we go:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-28-xen331-linux-2.6.30-rc3-next-crash-no-highpte.txt

(XEN) d0:v0: unhandled page fault (ec=0003)
(XEN) Pagetable walk from c1268000:
(XEN)  L3[0x003] = 000000003c8ee001 000008ee
(XEN)  L2[0x009] = 000000003d276067 00001276 
(XEN)  L1[0x068] = 000000003d268061 00001268
(XEN) domain_crash_sync called from entry.S (ff1a5c72)
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-3.3.1-12.0customdebug1.fc11  x86_32p  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) EIP:    e019:[<c0888d87>]

[root@dom0test linux-2.6-xen]# gdb vmlinux
(gdb) x/i 0xc0888d87
0xc0888d87 <__constant_c_memset+21>:    rep stos %eax,%es:(%edi)
(gdb) 

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-05-05 17:19                           ` Pasi Kärkkäinen
@ 2009-05-05 20:10                             ` Jeremy Fitzhardinge
  2009-05-06 18:54                               ` xen.git branch reorg / success " Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-05-05 20:10 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Ian Campbell, Xen-devel

Pasi Kärkkäinen wrote:
> And here we go:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-28-xen331-linux-2.6.30-rc3-next-crash-no-highpte.txt
>
> (XEN) d0:v0: unhandled page fault (ec=0003)
> (XEN) Pagetable walk from c1268000:
>   


Oh, look, we're not reserving the Xen pagetable, and this time we really 
should.  Does this work for you?

>From f26499cadfd057e4377e92ba680e16fa7bdf9422 Mon Sep 17 00:00:00 2001
From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Date: Tue, 5 May 2009 13:08:42 -0700
Subject: [PATCH] xen/i386: reserve Xen pagetables

The Xen pagetables are no longer implicitly reserved as part of the other
i386_start_kernel reservations, so make sure we explicitly reserve them.
This prevents them from being released into the general kernel free page
pool and reused.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 0e13477..801d042 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1799,6 +1799,11 @@ __init pgd_t *xen_setup_kernel_pagetable(pgd_t *pgd,
 
 	pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE, PFN_DOWN(__pa(swapper_pg_dir)));
 
+	reserve_early(__pa(xen_start_info->pt_base),
+		      __pa(xen_start_info->pt_base +
+			   xen_start_info->nr_pt_frames * PAGE_SIZE),
+		      "XEN PAGETABLES");
+
 	return swapper_pg_dir;
 }
 #endif	/* CONFIG_X86_64 */

^ permalink raw reply related	[flat|nested] 118+ messages in thread

* RE: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-05-01 18:35                         ` Jeremy Fitzhardinge
  2009-05-05 17:19                           ` Pasi Kärkkäinen
@ 2009-05-06  6:48                           ` Jiang, Yunhong
  2009-05-06  7:40                             ` Jiang, Yunhong
  1 sibling, 1 reply; 118+ messages in thread
From: Jiang, Yunhong @ 2009-05-06  6:48 UTC (permalink / raw)
  To: Jeremy Fitzhardinge, Pasi Kärkkäinen; +Cc: Ian Campbell, Xen-devel

Are there any recommendation that which branch will work? I meet the same issue in the xen-tip/master tree.

BTW, has anyone tried the xen-tip/dom0/apic branch? It always complains unknow partition type on my system for sda, while the same image works quite well when running as native.


Thanks
Yunhong Jiang

xen-devel-bounces@lists.xensource.com wrote:
> Pasi Kärkkäinen wrote:
>> On Wed, Apr 29, 2009 at 09:25:24AM -0700, Jeremy Fitzhardinge wrote:
>> 
>>>> There was some unification work in this area around the
>>>> beginning of March although I'm pretty such I've had it work much
>>>> more recently. (I guess it might not have been merged into a
>>>> visible branch until more recently, it's a bit hard to tell with
>>>> git but I don't think that's what happened). 
>>>> 
>>> Yeah, I think it has been working properly for some since then,
>>> though I think Pasi has been reporting problems since 32-bit dom0
>>> first booted. 
>>> 
>>> 
>> 
>> Yep, I've had problems from the beginning..
>> 
>> dom0/hackery was working pretty OK for me before it was removed..
>> I could run and install new PV guests etc.
>> 
> 
> Sorry, perhaps I was too hasty in removing the branches.  Though you
> still have references in your own git tree?
> 
> You still had problems with HIGHPTE in hackery?  My suspicion is that
> we're seeing the same bug manifesting in a much more obvious
> way, since
> I'm seeing somewhat similar symptoms, even without HIGHPTE.
> 
>>> I also realized that my Xen doesn't have debug=y set, so I'm
>>> probably missing some information. 
>>> 
>>> 
>> 
>> Hmm, good point. I don't have debug=y either..
>> 
> 
> That would be useful.  It would be interesting to see if Xen
> complains about any stray pte writes. 
> 
>    J
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* RE: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-05-06  6:48                           ` xen.git branch reorg / crash " Jiang, Yunhong
@ 2009-05-06  7:40                             ` Jiang, Yunhong
  2009-05-06 15:54                               ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 118+ messages in thread
From: Jiang, Yunhong @ 2009-05-06  7:40 UTC (permalink / raw)
  To: Jiang, Yunhong, Jeremy Fitzhardinge, Pasi Kärkkäinen
  Cc: Ian Campbell, Xen-devel

After switch to a new build system, seems xen-tip/master can works.

Thanks
Yunhong Jiang

xen-devel-bounces@lists.xensource.com wrote:
> Are there any recommendation that which branch will work? I
> meet the same issue in the xen-tip/master tree.
> 
> BTW, has anyone tried the xen-tip/dom0/apic branch? It always
> complains unknow partition type on my system for sda, while
> the same image works quite well when running as native.
> 
> 
> Thanks
> Yunhong Jiang
> 
> xen-devel-bounces@lists.xensource.com wrote:
>> Pasi Kärkkäinen wrote:
>>> On Wed, Apr 29, 2009 at 09:25:24AM -0700, Jeremy Fitzhardinge wrote:
>>> 
>>>>> There was some unification work in this area around the
>>>>> beginning of March although I'm pretty such I've had it work much
>>>>> more recently. (I guess it might not have been merged into a
>>>>> visible branch until more recently, it's a bit hard to tell with
>>>>> git but I don't think that's what happened).
>>>>> 
>>>> Yeah, I think it has been working properly for some since then,
>>>> though I think Pasi has been reporting problems since 32-bit dom0
>>>> first booted. 
>>>> 
>>>> 
>>> 
>>> Yep, I've had problems from the beginning..
>>> 
>>> dom0/hackery was working pretty OK for me before it was removed..
>>> I could run and install new PV guests etc.
>>> 
>> 
>> Sorry, perhaps I was too hasty in removing the branches.  Though you
>> still have references in your own git tree?
>> 
>> You still had problems with HIGHPTE in hackery?  My suspicion is that
>> we're seeing the same bug manifesting in a much more obvious
>> way, since
>> I'm seeing somewhat similar symptoms, even without HIGHPTE.
>> 
>>>> I also realized that my Xen doesn't have debug=y set, so I'm
>>>> probably missing some information.
>>>> 
>>>> 
>>> 
>>> Hmm, good point. I don't have debug=y either..
>>> 
>> 
>> That would be useful.  It would be interesting to see if Xen
>> complains about any stray pte writes.
>> 
>>    J
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0
  2009-05-06  7:40                             ` Jiang, Yunhong
@ 2009-05-06 15:54                               ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-05-06 15:54 UTC (permalink / raw)
  To: Jiang, Yunhong; +Cc: Ian Campbell, Xen-devel

Jiang, Yunhong wrote:
> After switch to a new build system, seems xen-tip/master can works.
>   

Yes, I committed a fix to xen-tip/master yesterday.

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-05 20:10                             ` Jeremy Fitzhardinge
@ 2009-05-06 18:54                               ` Pasi Kärkkäinen
  2009-05-06 21:51                                 ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-05-06 18:54 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Ian Campbell, Xen-devel

On Tue, May 05, 2009 at 01:10:43PM -0700, Jeremy Fitzhardinge wrote:
> Pasi Kärkkäinen wrote:
> >And here we go:
> >http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-28-xen331-linux-2.6.30-rc3-next-crash-no-highpte.txt
> >
> >(XEN) d0:v0: unhandled page fault (ec=0003)
> >(XEN) Pagetable walk from c1268000:
> >  
> 
> 
> Oh, look, we're not reserving the Xen pagetable, and this time we really 
> should.  Does this work for you?
> 

Yes, this fixes the problem! Now xen-tip/next pv_ops dom0 boots OK for me,
just like dom0/hackery did earlier!

But there's more.. I was pretty surprised when I booted up my testbox, 
using the serial console as usual, and in the end of the boot process login
prompt (getty) appeared on the VGA text console (tty1) !!

It seems this (or some other) patch has fixed the 32bit pv_ops dom0 console problems aswell.. 

Next I tried without the serial console, and yes, now the VGA text console 
works just like it does with the old 2.6.18 xenlinux tree! I can see the
pv_ops dom0 kernel boot messages after Xen boot messages just fine.

My grub.conf:

title Fedora Xen pv_ops dom0-test (2.6.30-rc3-tip)
        root (hd0,0)
        kernel /xen-3.3.gz dom0_mem=1024M loglvl=all guest_loglvl=all
        module /vmlinuz-2.6.30-rc3-tip ro root=/dev/vg00/lv01
        module /initrd-2.6.30-rc3-tip.img

No need to specify console= or earlyprintk= anymore!

Thanks for all the hard work and congratulations!

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-06 18:54                               ` xen.git branch reorg / success " Pasi Kärkkäinen
@ 2009-05-06 21:51                                 ` Jeremy Fitzhardinge
  2009-05-07 17:24                                   ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-05-06 21:51 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Ian Campbell, Xen-devel

Pasi Kärkkäinen wrote:
>> Oh, look, we're not reserving the Xen pagetable, and this time we really 
>> should.  Does this work for you?
>>
>>     
>
> Yes, this fixes the problem! Now xen-tip/next pv_ops dom0 boots OK for me,
> just like dom0/hackery did earlier!
>   

Great!  I'd be interested to know if you're still having HIGHPTE 
problems.  It may or may not have got fixed.

> But there's more.. I was pretty surprised when I booted up my testbox, 
> using the serial console as usual, and in the end of the boot process login
> prompt (getty) appeared on the VGA text console (tty1) !!
>   

Yes, I fixed that separately the other day, but wouldn't have noticed 
without being able to boot ;)

> Next I tried without the serial console, and yes, now the VGA text console 
> works just like it does with the old 2.6.18 xenlinux tree! I can see the
> pv_ops dom0 kernel boot messages after Xen boot messages just fine.
>   

Good.  Have you tried starting X?

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-06 21:51                                 ` Jeremy Fitzhardinge
@ 2009-05-07 17:24                                   ` Pasi Kärkkäinen
  2009-05-07 18:30                                     ` Jeremy Fitzhardinge
  2009-05-18 14:57                                     ` xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0 Ian Campbell
  0 siblings, 2 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-05-07 17:24 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Ian Campbell, Xen-devel

On Wed, May 06, 2009 at 02:51:59PM -0700, Jeremy Fitzhardinge wrote:
> Pasi Kärkkäinen wrote:
> >>Oh, look, we're not reserving the Xen pagetable, and this time we really 
> >>should.  Does this work for you?
> >>
> >>    
> >
> >Yes, this fixes the problem! Now xen-tip/next pv_ops dom0 boots OK for me,
> >just like dom0/hackery did earlier!
> >  
> 
> Great!  I'd be interested to know if you're still having HIGHPTE 
> problems.  It may or may not have got fixed.
> 

I just tried with CONFIG_HIGHPTE=y but that didn't seem to work:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-30-xen331-linux-2.6.30-rc3-next-crash-with-highpte.txt

(XEN) mm.c:2006:d0 Bad type (saw 28000001 != exp e0000000) for mfn 6b0a6 (pfn 2c959)
(XEN) mm.c:707:d0 Error getting mfn 6b0a6 (pfn 2c959) from L1 entry 000000006b0a6063 for dom0
(XEN) mm.c:3640:d0 ptwr_emulate: could not get_page_from_l1e()

BUG: unable to handle kernel paging request at c0207d58
IP: [<c0405bf7>] xen_set_pte+0x89/0x93
*pdpt = 000000003c8ef001 
Oops: 0003 [#1] SMP 
Pid: 323, comm: kswapd0 Not tainted (2.6.30-rc3-tip #34) P8SC8
EIP: 0061:[<c0405bf7>] EFLAGS: 00010296 CPU: 0
EIP is at xen_set_pte+0x89/0x93
EAX: 00000000 EBX: c0207d58 ECX: 00000000 EDX: 6b0a6063
ESI: 00000000 EDI: 000bd778 EBP: e254cd80 ESP: e254cd70
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
Process kswapd0 (pid: 323, ti=e254c000 task=e25c8000 task.ti=e254c000)

[root@dom0test linux-2.6-xen]# gdb vmlinux
(gdb) x/i 0xc0405bf7
0xc0405bf7 <xen_set_pte+137>:   mov    %edx,(%ebx)
(gdb) 


> >Next I tried without the serial console, and yes, now the VGA text console 
> >works just like it does with the old 2.6.18 xenlinux tree! I can see the
> >pv_ops dom0 kernel boot messages after Xen boot messages just fine.
> >  
> 
> Good.  Have you tried starting X?
> 

Nope, not yet. I don't even have X in that box.. I'll try that later :) 

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-07 17:24                                   ` Pasi Kärkkäinen
@ 2009-05-07 18:30                                     ` Jeremy Fitzhardinge
  2009-05-07 18:46                                       ` Pasi Kärkkäinen
  2009-05-18 14:57                                     ` xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0 Ian Campbell
  1 sibling, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-05-07 18:30 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Ian Campbell, Xen-devel

Pasi Kärkkäinen wrote:
> I just tried with CONFIG_HIGHPTE=y but that didn't seem to work:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-30-xen331-linux-2.6.30-rc3-next-crash-with-highpte.txt
>
> (XEN) mm.c:2006:d0 Bad type (saw 28000001 != exp e0000000) for mfn 6b0a6 (pfn 2c959)
> (XEN) mm.c:707:d0 Error getting mfn 6b0a6 (pfn 2c959) from L1 entry 000000006b0a6063 for dom0
> (XEN) mm.c:3640:d0 ptwr_emulate: could not get_page_from_l1e()
>
> BUG: unable to handle kernel paging request at c0207d58
> IP: [<c0405bf7>] xen_set_pte+0x89/0x93
> *pdpt = 000000003c8ef001 
> Oops: 0003 [#1] SMP 
> Pid: 323, comm: kswapd0 Not tainted (2.6.30-rc3-tip #34) P8SC8
> EIP: 0061:[<c0405bf7>] EFLAGS: 00010296 CPU: 0
> EIP is at xen_set_pte+0x89/0x93
> EAX: 00000000 EBX: c0207d58 ECX: 00000000 EDX: 6b0a6063
> ESI: 00000000 EDI: 000bd778 EBP: e254cd80 ESP: e254cd70
>  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
> Process kswapd0 (pid: 323, ti=e254c000 task=e25c8000 task.ti=e254c000)
>   

Hm, can't have everything I suppose...  I wonder what's going on here; I 
haven't seen any problems with highpte at all.  Something .config-specific?

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-07 18:30                                     ` Jeremy Fitzhardinge
@ 2009-05-07 18:46                                       ` Pasi Kärkkäinen
  2009-05-14 11:11                                         ` xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0 / CONFIG_HIGHPTE problems Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-05-07 18:46 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Ian Campbell, Xen-devel

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

On Thu, May 07, 2009 at 11:30:04AM -0700, Jeremy Fitzhardinge wrote:
> Pasi Kärkkäinen wrote:
> >I just tried with CONFIG_HIGHPTE=y but that didn't seem to work:
> >http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-30-xen331-linux-2.6.30-rc3-next-crash-with-highpte.txt
> >
> >(XEN) mm.c:2006:d0 Bad type (saw 28000001 != exp e0000000) for mfn 6b0a6 
> >(pfn 2c959)
> >(XEN) mm.c:707:d0 Error getting mfn 6b0a6 (pfn 2c959) from L1 entry 
> >000000006b0a6063 for dom0
> >(XEN) mm.c:3640:d0 ptwr_emulate: could not get_page_from_l1e()
> >
> >BUG: unable to handle kernel paging request at c0207d58
> >IP: [<c0405bf7>] xen_set_pte+0x89/0x93
> >*pdpt = 000000003c8ef001 
> >Oops: 0003 [#1] SMP 
> >Pid: 323, comm: kswapd0 Not tainted (2.6.30-rc3-tip #34) P8SC8
> >EIP: 0061:[<c0405bf7>] EFLAGS: 00010296 CPU: 0
> >EIP is at xen_set_pte+0x89/0x93
> >EAX: 00000000 EBX: c0207d58 ECX: 00000000 EDX: 6b0a6063
> >ESI: 00000000 EDI: 000bd778 EBP: e254cd80 ESP: e254cd70
> > DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
> >Process kswapd0 (pid: 323, ti=e254c000 task=e25c8000 task.ti=e254c000)
> >  
> 
> Hm, can't have everything I suppose...  I wonder what's going on here; I 
> haven't seen any problems with highpte at all.  Something .config-specific?
> 

Hmm.. it could be my .config.

http://pasik.reaktio.net/xen/pv_ops-dom0-debug/config-2.6.30-rc3-tip-next-with-highpte

Also attached to this mail. It's originally based on Fedora 10 default kernel config.

Anything suspicious?

-- Pasi

[-- Attachment #2: config-2.6.30-rc3-tip-next-with-highpte --]
[-- Type: text/plain, Size: 95813 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.30-rc3
# Wed May  6 17:28:07 2009
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=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_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_HAVE_DYNAMIC_PER_CPU_AREA=y
# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=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=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_TREE=y

#
# RCU Subsystem
#
CONFIG_CLASSIC_RCU=y
# CONFIG_TREE_RCU is not set
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_PREEMPT_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
# CONFIG_USER_SCHED is not set
CONFIG_CGROUP_SCHED=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_NS=y
# CONFIG_CGROUP_FREEZER is not set
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_CGROUP_MEM_RES_CTLR is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
# CONFIG_NET_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=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_STRIP_ASM_SYMS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_COUNTERS=y

#
# Performance Counters
#
CONFIG_PERF_COUNTERS=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_MARKERS=y
# CONFIG_OPROFILE is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_API_DEBUG=y
# CONFIG_SLOW_WORK is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBD=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_INTEGRITY=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 is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
CONFIG_SPARSE_IRQ=y
CONFIG_X86_MPPARSE=y
# CONFIG_X86_BIGSMP is not set
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_RDC321X is not set
# CONFIG_X86_32_NON_STANDARD is not set
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_XEN=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=32
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_XEN_DEBUG_FS=y
CONFIG_XEN_PCI_PASSTHROUGH=y
CONFIG_XEN_DOM0_PCI=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
# CONFIG_XEN_PCI_PASSTHROUGH_DEBUG is not set
CONFIG_MICROCODE_XEN=y
CONFIG_VMI=y
CONFIG_KVM_CLOCK=y
CONFIG_KVM_GUEST=y
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
# CONFIG_MEMTEST is not set
# 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 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# 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_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_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CPU=y
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_CYRIX_32=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_CPU_SUP_UMC_32=y
# CONFIG_X86_DS is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_IOMMU_API is not set
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
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_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
# CONFIG_X86_CPU_DEBUG is not set
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_X86_PAE=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0
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=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_UNEVICTABLE_LRU=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
CONFIG_MMU_NOTIFIER=y
CONFIG_HIGHPTE=y
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW_64K=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_EFI=y
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR 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_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x400000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x400000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_VERBOSE is not set
CONFIG_CAN_PM_TRACE=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_SUSPEND_FREEZER=y
# CONFIG_HIBERNATION is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=1999
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_PCI_SLOT=m
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_SBS=m
CONFIG_X86_APM_BOOT=y
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_ALLOW_INTS 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_POWERSAVE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
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=m
# CONFIG_X86_GX_SUSPMOD is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
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=y

#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=y
# CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
# CONFIG_PCI_GOOLPC is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_OLPC=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
# CONFIG_DMAR is not set
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=m
CONFIG_PCIEAER=y
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
CONFIG_HT_IRQ=y
# CONFIG_PCI_IOV is not set
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_OLPC=y
CONFIG_K8_NB=y
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=m
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=m
# CONFIG_TCIC is not set
CONFIG_PCMCIA_PROBE=y
CONFIG_PCCARD_NONSTATIC=m
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=y
CONFIG_HOTPLUG_PCI_ACPI_IBM=m
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_HAVE_ATOMIC_IOMAP=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=y
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
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_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_LRO=y
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=y
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_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
# CONFIG_DEFAULT_BIC is not set
CONFIG_DEFAULT_CUBIC=y
# 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="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=m
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_IPV6_OPTIMISTIC_DAD=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
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_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_SUBTREES=y
CONFIG_IPV6_MROUTE=y
CONFIG_IPV6_PIMSM_V2=y
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CT_ACCT=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_DCCP=m
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=m
CONFIG_NF_CT_PROTO_UDPLITE=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=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
CONFIG_NETFILTER_TPROXY=m
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_HL=m
# CONFIG_NETFILTER_XT_TARGET_LED is not set
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_RATEEST=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
# CONFIG_NETFILTER_XT_MATCH_CLUSTER is not set
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_HL=m
CONFIG_NETFILTER_XT_MATCH_IPRANGE=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_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_OWNER=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_RATEEST=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_RECENT=m
# CONFIG_NETFILTER_XT_MATCH_RECENT_PROC_COMPAT is not set
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_SOCKET=m
CONFIG_NETFILTER_XT_MATCH_STATE=y
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_TIME=m
CONFIG_NETFILTER_XT_MATCH_U32=m
CONFIG_IP_VS=m
# CONFIG_IP_VS_IPV6 is not set
# 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_AH_ESP=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

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_CONNTRACK_IPV4=y
# CONFIG_NF_CONNTRACK_PROC_COMPAT is not set
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
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_NETMAP=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_DCCP=m
CONFIG_NF_NAT_PROTO_GRE=m
CONFIG_NF_NAT_PROTO_UDPLITE=m
CONFIG_NF_NAT_PROTO_SCTP=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_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_SECURITY=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m

#
# IPv6: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV6=m
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_AH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_MH=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_RAW=m
CONFIG_IP6_NF_SECURITY=m

#
# DECnet: Netfilter Configuration
#
# CONFIG_DECNET_NF_GRABULATOR is not set
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_IP6=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
CONFIG_BRIDGE_EBT_NFLOG=m
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m

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

#
# DCCP Kernel Hacking
#
# CONFIG_IP_DCCP_DEBUG is not set
CONFIG_NET_DCCPPROBE=m
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
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_STP=m
CONFIG_GARP=m
CONFIG_BRIDGE=m
# CONFIG_NET_DSA is not set
CONFIG_VLAN_8021Q=m
CONFIG_VLAN_8021Q_GVRP=y
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
CONFIG_PHONET=m
CONFIG_NET_SCHED=y

#
# 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_MULTIQ=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_DRR is not set
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_CLS_FLOW=m
# CONFIG_NET_CLS_CGROUP is not set
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_NAT=m
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m
CONFIG_NET_ACT_SKBEDIT=m
CONFIG_NET_CLS_IND=y
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set

#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_NET_TCPPROBE is not set
# CONFIG_NET_DROP_MONITOR is not set
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
CONFIG_AX25=m
CONFIG_AX25_DAMA_SLAVE=y
CONFIG_NETROM=m
CONFIG_ROSE=m

#
# AX.25 network device drivers
#
CONFIG_MKISS=m
CONFIG_6PACK=m
CONFIG_BPQETHER=m
CONFIG_SCC=m
# CONFIG_SCC_DELAY is not set
CONFIG_SCC_TRXECHO=y
CONFIG_BAYCOM_SER_FDX=m
CONFIG_BAYCOM_SER_HDX=m
CONFIG_BAYCOM_PAR=m
CONFIG_BAYCOM_EPP=m
CONFIG_YAM=m
CONFIG_CAN=m
CONFIG_CAN_RAW=m
CONFIG_CAN_BCM=m

#
# CAN Device Drivers
#
CONFIG_CAN_VCAN=m
# CONFIG_CAN_DEBUG_DEVICES 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
CONFIG_KINGSUN_DONGLE=m
CONFIG_KSDAZZLE_DONGLE=m
CONFIG_KS959_DONGLE=m

#
# 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_HCIBTUSB=m
CONFIG_BT_HCIBTSDIO=m
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
CONFIG_BT_HCIUART_LL=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_AF_RXRPC is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_CFG80211=m
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
CONFIG_LIB80211=m
CONFIG_LIB80211_CRYPT_WEP=m
CONFIG_LIB80211_CRYPT_CCMP=m
CONFIG_LIB80211_CRYPT_TKIP=m
# CONFIG_LIB80211_DEBUG is not set
CONFIG_MAC80211=m

#
# Rate control algorithm selection
#
CONFIG_MAC80211_RC_MINSTREL=y
# CONFIG_MAC80211_RC_DEFAULT_PID is not set
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel"
CONFIG_MAC80211_MESH=y
CONFIG_MAC80211_LEDS=y
CONFIG_MAC80211_DEBUGFS=y
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=m
CONFIG_RFKILL_INPUT=m
CONFIG_RFKILL_LEDS=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
CONFIG_DEBUG_DEVRES=y
CONFIG_SYS_HYPERVISOR=y
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_CONCAT=m
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_TESTS is not set
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
CONFIG_MTD_AR7_PARTS=m

#
# 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=m
CONFIG_MTD_OOPS=m

#
# 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

#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP 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=m
CONFIG_MTD_CK804XROM=m
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_INTEL_VR_NOR is not set
# 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
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
CONFIG_MTD_NAND_ECC_SMC=y
# CONFIG_MTD_NAND_MUSEUM_IDS is not set
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=m
CONFIG_MTD_NAND_CS553X=m
CONFIG_MTD_NAND_NANDSIM=m
# CONFIG_MTD_NAND_PLATFORM is not set
CONFIG_MTD_ALAUDA=m
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set

#
# UBI - Unsorted block images
#
CONFIG_MTD_UBI=m
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
# CONFIG_MTD_UBI_GLUEBI is not set

#
# UBI debugging options
#
# CONFIG_MTD_UBI_DEBUG is not set
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
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_ISAPNP=y
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
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=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_SX8=m
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
CONFIG_ATA_OVER_ETH=m
CONFIG_XEN_BLKDEV_FRONTEND=y
CONFIG_VIRTIO_BLK=m
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
CONFIG_IBM_ASM=m
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
CONFIG_TIFM_CORE=m
CONFIG_TIFM_7XX1=m
CONFIG_ICS932S401=m
CONFIG_ENCLOSURE_SERVICES=m
CONFIG_HP_ILO=m
# CONFIG_DELL_LAPTOP is not set
# CONFIG_ISL29003 is not set
CONFIG_C2PORT=m
CONFIG_C2PORT_DURAMAR_2150=m

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
CONFIG_EEPROM_93CX6=m
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_RAID_ATTRS=m
CONFIG_SCSI=y
CONFIG_SCSI_DMA=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=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
CONFIG_CHR_DEV_SCH=m
CONFIG_SCSI_ENCLOSURE=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=y
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_FC_TGT_ATTRS=y
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
CONFIG_SCSI_SAS_LIBSAS=m
CONFIG_SCSI_SAS_ATA=y
CONFIG_SCSI_SAS_HOST_SMP=y
# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
CONFIG_SCSI_SRP_ATTRS=m
CONFIG_SCSI_SRP_TGT_ATTRS=y
CONFIG_SCSI_LOWLEVEL=y
CONFIG_ISCSI_TCP=m
# CONFIG_SCSI_CXGB3_ISCSI is not set
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 is not set
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=4
CONFIG_AIC7XXX_RESET_DELAY_MS=15000
# 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=m
CONFIG_AIC79XX_CMDS_PER_DEVICE=4
CONFIG_AIC79XX_RESET_DELAY_MS=15000
# CONFIG_AIC79XX_DEBUG_ENABLE is not set
CONFIG_AIC79XX_DEBUG_MASK=0
# CONFIG_AIC79XX_REG_PRETTY_PRINT is not set
CONFIG_SCSI_AIC94XX=m
# 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_SCSI_ARCMSR_AER=y
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=m
CONFIG_MEGARAID_MAILBOX=m
CONFIG_MEGARAID_LEGACY=m
CONFIG_MEGARAID_SAS=m
CONFIG_SCSI_MPT2SAS=m
CONFIG_SCSI_MPT2SAS_MAX_SGE=128
# CONFIG_SCSI_MPT2SAS_LOGGING is not set
CONFIG_SCSI_HPTIOP=m
CONFIG_SCSI_BUSLOGIC=m
CONFIG_SCSI_FLASHPOINT=y
CONFIG_LIBFC=m
CONFIG_LIBFCOE=m
# CONFIG_FCOE 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_MVSAS=m
# 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_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_LPFC_DEBUG_FS 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_SRP=m
CONFIG_SCSI_LOWLEVEL_PCMCIA=y
CONFIG_PCMCIA_AHA152X=m
CONFIG_PCMCIA_FDOMAIN=m
CONFIG_PCMCIA_NINJA_SCSI=m
CONFIG_PCMCIA_QLOGIC=m
CONFIG_PCMCIA_SYM53C500=m
CONFIG_SCSI_DH=y
CONFIG_SCSI_DH_RDAC=m
CONFIG_SCSI_DH_HP_SW=m
CONFIG_SCSI_DH_EMC=m
CONFIG_SCSI_DH_ALUA=m
CONFIG_SCSI_OSD_INITIATOR=m
CONFIG_SCSI_OSD_ULD=m
CONFIG_SCSI_OSD_DPRINT_SENSE=1
# CONFIG_SCSI_OSD_DEBUG is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y
CONFIG_SATA_AHCI=y
CONFIG_SATA_SIL24=m
CONFIG_ATA_SFF=y
CONFIG_SATA_SVW=m
CONFIG_ATA_PIIX=y
CONFIG_SATA_MV=m
CONFIG_SATA_NV=m
CONFIG_PDC_ADMA=m
CONFIG_SATA_QSTOR=m
CONFIG_SATA_PROMISE=m
CONFIG_SATA_SX4=m
CONFIG_SATA_SIL=m
CONFIG_SATA_SIS=m
CONFIG_SATA_ULI=m
CONFIG_SATA_VIA=m
CONFIG_SATA_VITESSE=m
CONFIG_SATA_INIC162X=m
CONFIG_PATA_ACPI=m
CONFIG_PATA_ALI=m
CONFIG_PATA_AMD=m
CONFIG_PATA_ARTOP=m
CONFIG_PATA_ATIIXP=m
CONFIG_PATA_CMD640_PCI=m
CONFIG_PATA_CMD64X=m
CONFIG_PATA_CS5520=m
CONFIG_PATA_CS5530=m
CONFIG_PATA_CS5535=m
CONFIG_PATA_CS5536=m
CONFIG_PATA_CYPRESS=m
CONFIG_PATA_EFAR=m
CONFIG_ATA_GENERIC=m
CONFIG_PATA_HPT366=m
CONFIG_PATA_HPT37X=m
CONFIG_PATA_HPT3X2N=m
CONFIG_PATA_HPT3X3=m
CONFIG_PATA_HPT3X3_DMA=y
# CONFIG_PATA_ISAPNP is not set
CONFIG_PATA_IT821X=m
CONFIG_PATA_IT8213=m
CONFIG_PATA_JMICRON=m
# CONFIG_PATA_LEGACY is not set
CONFIG_PATA_TRIFLEX=m
CONFIG_PATA_MARVELL=m
CONFIG_PATA_MPIIX=m
CONFIG_PATA_OLDPIIX=m
CONFIG_PATA_NETCELL=m
CONFIG_PATA_NINJA32=m
CONFIG_PATA_NS87410=m
CONFIG_PATA_NS87415=m
CONFIG_PATA_OPTI=m
CONFIG_PATA_OPTIDMA=m
CONFIG_PATA_PCMCIA=m
CONFIG_PATA_PDC_OLD=m
CONFIG_PATA_QDI=m
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
CONFIG_PATA_SERVERWORKS=m
CONFIG_PATA_PDC2027X=m
CONFIG_PATA_SIL680=m
CONFIG_PATA_SIS=m
CONFIG_PATA_VIA=m
CONFIG_PATA_WINBOND=m
# CONFIG_PATA_WINBOND_VLB is not set
CONFIG_PATA_SCH=m
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID10=m
CONFIG_MD_RAID456=m
CONFIG_MD_RAID6_PQ=m
CONFIG_MD_MULTIPATH=m
CONFIG_MD_FAULTY=m
CONFIG_BLK_DEV_DM=y
CONFIG_DM_DEBUG=y
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_MIRROR=y
CONFIG_DM_ZERO=y
CONFIG_DM_MULTIPATH=m
# CONFIG_DM_DELAY is not set
CONFIG_DM_UEVENT=y
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
CONFIG_FUSION_LOGGING=y

#
# IEEE 1394 (FireWire) support
#

#
# Enable only one of the two stacks, unless you know what you are doing
#
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_OHCI_DEBUG=y
CONFIG_FIREWIRE_SBP2=m
# CONFIG_IEEE1394 is not set
CONFIG_I2O=m
# CONFIG_I2O_LCT_NOTIFY_ON_CHANGES is not set
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_EXT_ADAPTEC_DMA64=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
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NETDEVICES=y
CONFIG_COMPAT_NET_DEV_OPS=y
CONFIG_IFB=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_MACVLAN=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_VETH=m
CONFIG_NET_SB1000=m
# CONFIG_ARCNET is not set
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_ICPLUS_PHY=m
CONFIG_REALTEK_PHY=m
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
CONFIG_MDIO_BITBANG=m
CONFIG_NET_ETHERNET=y
CONFIG_MII=m
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_ULTRA=m
# CONFIG_SMC9194 is not set
CONFIG_ETHOC=m
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_DNET is not set
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 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_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
CONFIG_AMD8111_ETH=m
CONFIG_ADAPTEC_STARFIRE=m
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
CONFIG_B44=m
CONFIG_B44_PCI_AUTOSELECT=y
CONFIG_B44_PCICORE_AUTOSELECT=y
CONFIG_B44_PCI=y
CONFIG_FORCEDETH=m
CONFIG_FORCEDETH_NAPI=y
# CONFIG_CS89x0 is not set
CONFIG_E100=m
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_8139CP=m
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_R6040=m
CONFIG_SIS900=m
CONFIG_EPIC100=m
# CONFIG_SMSC9420 is not set
CONFIG_SUNDANCE=m
# CONFIG_SUNDANCE_MMIO is not set
CONFIG_TLAN=m
CONFIG_VIA_RHINE=m
CONFIG_VIA_RHINE_MMIO=y
CONFIG_SC92031=m
CONFIG_NET_POCKET=y
CONFIG_ATP=m
CONFIG_DE600=m
CONFIG_DE620=m
CONFIG_ATL2=m
CONFIG_NETDEV_1000=y
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
CONFIG_E1000=m
CONFIG_E1000E=m
CONFIG_IP1000=m
CONFIG_IGB=m
CONFIG_IGBVF=m
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
CONFIG_R8169=m
CONFIG_R8169_VLAN=y
CONFIG_SIS190=m
CONFIG_SKGE=m
# CONFIG_SKGE_DEBUG is not set
CONFIG_SKY2=m
# CONFIG_SKY2_DEBUG is not set
CONFIG_VIA_VELOCITY=m
CONFIG_TIGON3=m
CONFIG_BNX2=m
CONFIG_QLA3XXX=m
CONFIG_ATL1=m
CONFIG_ATL1E=m
# CONFIG_ATL1C is not set
CONFIG_JME=m
CONFIG_NETDEV_10000=y
CONFIG_CHELSIO_T1=m
CONFIG_CHELSIO_T1_1G=y
CONFIG_CHELSIO_T3_DEPENDS=y
CONFIG_CHELSIO_T3=m
CONFIG_ENIC=m
CONFIG_IXGBE=m
CONFIG_IXGB=m
CONFIG_S2IO=m
CONFIG_MYRI10GE=m
CONFIG_NIU=m
CONFIG_MLX4_EN=m
CONFIG_MLX4_CORE=m
CONFIG_MLX4_DEBUG=y
CONFIG_TEHUTI=m
CONFIG_BNX2X=m
CONFIG_QLGE=m
# CONFIG_SFC is not set
CONFIG_BE2NET=m
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
#
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_PCMCIA_RAYCS is not set
CONFIG_LIBERTAS=m
CONFIG_LIBERTAS_USB=m
CONFIG_LIBERTAS_CS=m
CONFIG_LIBERTAS_SDIO=m
CONFIG_LIBERTAS_DEBUG=y
CONFIG_LIBERTAS_THINFIRM=m
CONFIG_LIBERTAS_THINFIRM_USB=m
CONFIG_AIRO=m
CONFIG_ATMEL=m
CONFIG_PCI_ATMEL=m
CONFIG_PCMCIA_ATMEL=m
CONFIG_AT76C50X_USB=m
CONFIG_AIRO_CS=m
CONFIG_PCMCIA_WL3501=m
CONFIG_PRISM54=m
CONFIG_USB_ZD1201=m
CONFIG_USB_NET_RNDIS_WLAN=m
CONFIG_RTL8180=m
CONFIG_RTL8187=m
CONFIG_ADM8211=m
CONFIG_MAC80211_HWSIM=m
CONFIG_MWL8K=m
CONFIG_P54_COMMON=m
CONFIG_P54_USB=m
CONFIG_P54_PCI=m
CONFIG_P54_LEDS=y
CONFIG_ATH5K=m
CONFIG_ATH5K_DEBUG=y
CONFIG_ATH9K=m
# CONFIG_ATH9K_DEBUG is not set
CONFIG_AR9170_USB=m
CONFIG_AR9170_LEDS=y
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_LIBIPW=m
# CONFIG_LIBIPW_DEBUG is not set
CONFIG_IWLWIFI=m
CONFIG_IWLWIFI_LEDS=y
CONFIG_IWLWIFI_RFKILL=y
# CONFIG_IWLWIFI_SPECTRUM_MEASUREMENT is not set
CONFIG_IWLWIFI_DEBUG=y
CONFIG_IWLWIFI_DEBUGFS=y
CONFIG_IWLAGN=m
CONFIG_IWL4965=y
CONFIG_IWL5000=y
CONFIG_IWL3945=m
CONFIG_IWL3945_SPECTRUM_MEASUREMENT=y
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_B43=m
CONFIG_B43_PCI_AUTOSELECT=y
CONFIG_B43_PCICORE_AUTOSELECT=y
CONFIG_B43_PCMCIA=y
CONFIG_B43_PIO=y
CONFIG_B43_LEDS=y
CONFIG_B43_RFKILL=y
CONFIG_B43_DEBUG=y
# CONFIG_B43_FORCE_PIO is not set
CONFIG_B43LEGACY=m
CONFIG_B43LEGACY_PCI_AUTOSELECT=y
CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y
CONFIG_B43LEGACY_LEDS=y
CONFIG_B43LEGACY_RFKILL=y
CONFIG_B43LEGACY_DEBUG=y
CONFIG_B43LEGACY_DMA=y
CONFIG_B43LEGACY_PIO=y
CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y
# CONFIG_B43LEGACY_DMA_MODE is not set
# CONFIG_B43LEGACY_PIO_MODE is not set
CONFIG_ZD1211RW=m
# CONFIG_ZD1211RW_DEBUG is not set
CONFIG_HERMES=m
CONFIG_HERMES_CACHE_FW_ON_INIT=y
CONFIG_PLX_HERMES=m
CONFIG_TMD_HERMES=m
CONFIG_NORTEL_HERMES=m
CONFIG_PCI_HERMES=m
CONFIG_PCMCIA_HERMES=m
CONFIG_PCMCIA_SPECTRUM=m

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#

#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_CDCETHER=m
CONFIG_USB_NET_DM9601=m
CONFIG_USB_NET_SMSC95XX=m
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=y
CONFIG_USB_NET_ZAURUS=m
CONFIG_USB_HSO=m
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
# CONFIG_WAN is not set
CONFIG_ATM_DRIVERS=y
# 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=m
# CONFIG_ATM_FORE200E_USE_TASKLET is not set
CONFIG_ATM_FORE200E_TX_RETRY=16
CONFIG_ATM_FORE200E_DEBUG=0
CONFIG_ATM_HE=m
# CONFIG_ATM_HE_USE_SUNI is not set
# CONFIG_ATM_SOLOS is not set
CONFIG_XEN_NETDEV_FRONTEND=y
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_PPPOL2TP=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_NETCONSOLE=m
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
CONFIG_NETPOLL_TRAP=y
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_VIRTIO_NET=m
CONFIG_ISDN=y
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
CONFIG_HYSDN=m
CONFIG_HYSDN_CAPI=y
CONFIG_ISDN_DRV_GIGASET=m
CONFIG_GIGASET_BASE=m
CONFIG_GIGASET_M105=m
CONFIG_GIGASET_M101=m
# CONFIG_GIGASET_DEBUG is not set
# CONFIG_GIGASET_UNDOCREQ is not set
CONFIG_ISDN_CAPI=m
CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
# CONFIG_CAPI_TRACE is not set
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
#
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
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
# CONFIG_PHONE is not set

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

#
# 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_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
CONFIG_XEN_KBDDEV_FRONTEND=y

#
# 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 is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_PS2_OLPC=y
CONFIG_MOUSE_SERIAL=m
CONFIG_MOUSE_APPLETOUCH=m
CONFIG_MOUSE_BCM5974=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_ZHENHUA=m
CONFIG_JOYSTICK_DB9=m
CONFIG_JOYSTICK_GAMECON=m
CONFIG_JOYSTICK_TURBOGRAFX=m
CONFIG_JOYSTICK_JOYDUMP=m
CONFIG_JOYSTICK_XPAD=m
CONFIG_JOYSTICK_XPAD_FF=y
CONFIG_JOYSTICK_XPAD_LEDS=y
# CONFIG_JOYSTICK_WALKERA0701 is not set
CONFIG_INPUT_TABLET=y
CONFIG_TABLET_USB_ACECAD=m
CONFIG_TABLET_USB_AIPTEK=m
CONFIG_TABLET_USB_GTCO=m
CONFIG_TABLET_USB_KBTAB=m
CONFIG_TABLET_USB_WACOM=m
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_AD7879_I2C is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
CONFIG_TOUCHSCREEN_FUJITSU=m
CONFIG_TOUCHSCREEN_GUNZE=m
CONFIG_TOUCHSCREEN_ELO=m
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
CONFIG_TOUCHSCREEN_MTOUCH=m
CONFIG_TOUCHSCREEN_INEXIO=m
CONFIG_TOUCHSCREEN_MK712=m
CONFIG_TOUCHSCREEN_HTCPEN=m
CONFIG_TOUCHSCREEN_PENMOUNT=m
CONFIG_TOUCHSCREEN_TOUCHRIGHT=m
CONFIG_TOUCHSCREEN_TOUCHWIN=m
# CONFIG_TOUCHSCREEN_WM97XX is not set
CONFIG_TOUCHSCREEN_USB_COMPOSITE=m
CONFIG_TOUCHSCREEN_USB_EGALAX=y
CONFIG_TOUCHSCREEN_USB_PANJIT=y
CONFIG_TOUCHSCREEN_USB_3M=y
CONFIG_TOUCHSCREEN_USB_ITM=y
CONFIG_TOUCHSCREEN_USB_ETURBO=y
CONFIG_TOUCHSCREEN_USB_GUNZE=y
CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y
CONFIG_TOUCHSCREEN_USB_IRTOUCH=y
CONFIG_TOUCHSCREEN_USB_IDEALTEK=y
CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y
CONFIG_TOUCHSCREEN_USB_GOTOP=y
CONFIG_TOUCHSCREEN_TOUCHIT213=m
# CONFIG_TOUCHSCREEN_TSC2007 is not set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
CONFIG_INPUT_APANEL=m
CONFIG_INPUT_WISTRON_BTNS=m
CONFIG_INPUT_ATLAS_BTNS=m
CONFIG_INPUT_ATI_REMOTE=m
CONFIG_INPUT_ATI_REMOTE2=m
CONFIG_INPUT_KEYSPAN_REMOTE=m
CONFIG_INPUT_POWERMATE=m
CONFIG_INPUT_YEALINK=m
CONFIG_INPUT_CM109=m
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_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_DEVKMEM is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_COMPUTONE is not set
CONFIG_ROCKETPORT=m
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_ISI is not set
CONFIG_SYNCLINK=m
CONFIG_SYNCLINKMP=m
CONFIG_SYNCLINK_GT=m
CONFIG_N_HDLC=m
# CONFIG_RISCOM8 is not set
# CONFIG_SPECIALIX is not set
# CONFIG_SX is not set
# CONFIG_RIO is not set
# CONFIG_STALDRV is not set
CONFIG_NOZOMI=m

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=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 is not set
# 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_CONSOLE_POLL=y
CONFIG_SERIAL_JSM=m
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_VIRTIO_CONSOLE=m
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
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TIMERIOMEM=m
CONFIG_HW_RANDOM_INTEL=m
CONFIG_HW_RANDOM_AMD=m
CONFIG_HW_RANDOM_GEODE=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_NVRAM=y
CONFIG_DTLK=m
CONFIG_R3964=m
# CONFIG_APPLICOM is not set
CONFIG_SONYPI=m

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
CONFIG_CARDMAN_4000=m
CONFIG_CARDMAN_4040=m
CONFIG_IPWIRELESS=m
CONFIG_MWAVE=m
CONFIG_PC8736x_GPIO=m
CONFIG_NSC_GPIO=m
CONFIG_CS5535_GPIO=m
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=8192
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
CONFIG_HANGCHECK_TIMER=m
CONFIG_TCG_TPM=m
CONFIG_TCG_TIS=m
CONFIG_TCG_NSC=m
CONFIG_TCG_ATMEL=m
CONFIG_TCG_INFINEON=m
CONFIG_TELCLOCK=m
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
CONFIG_I2C_ALI1535=m
CONFIG_I2C_ALI1563=m
CONFIG_I2C_ALI15X3=m
CONFIG_I2C_AMD756=m
CONFIG_I2C_AMD8111=m
CONFIG_I2C_I801=m
CONFIG_I2C_ISCH=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_NFORCE2=m
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_SIMTEC=m

#
# External I2C/SMBus adapter drivers
#
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
# CONFIG_I2C_TAOS_EVM is not set
CONFIG_I2C_TINY_USB=m

#
# Graphics adapter I2C/DDC channel drivers
#
CONFIG_I2C_VOODOO3=m

#
# Other I2C/SMBus bus drivers
#
CONFIG_I2C_PCA_ISA=m
CONFIG_I2C_PCA_PLATFORM=m
CONFIG_I2C_STUB=m
# CONFIG_SCx200_ACB is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
CONFIG_SENSORS_PCF8574=m
CONFIG_PCF8575=m
CONFIG_SENSORS_PCA9539=m
CONFIG_SENSORS_MAX6875=m
CONFIG_SENSORS_TSL2550=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
# CONFIG_SPI is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
CONFIG_W1=m
CONFIG_W1_CON=y

#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_MATROX is not set
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_DS2431 is not set
CONFIG_W1_SLAVE_DS2433=m
CONFIG_W1_SLAVE_DS2433_CRC=y
CONFIG_W1_SLAVE_DS2760=m
CONFIG_W1_SLAVE_BQ27000=m
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
CONFIG_BATTERY_OLPC=y
CONFIG_BATTERY_BQ27x00=m
CONFIG_HWMON=m
CONFIG_HWMON_VID=m
CONFIG_SENSORS_ABITUGURU=m
CONFIG_SENSORS_ABITUGURU3=m
CONFIG_SENSORS_AD7414=m
CONFIG_SENSORS_AD7418=m
CONFIG_SENSORS_ADM1021=m
CONFIG_SENSORS_ADM1025=m
CONFIG_SENSORS_ADM1026=m
CONFIG_SENSORS_ADM1029=m
CONFIG_SENSORS_ADM1031=m
CONFIG_SENSORS_ADM9240=m
CONFIG_SENSORS_ADT7462=m
CONFIG_SENSORS_ADT7470=m
CONFIG_SENSORS_ADT7473=m
CONFIG_SENSORS_ADT7475=m
CONFIG_SENSORS_K8TEMP=m
CONFIG_SENSORS_ASB100=m
CONFIG_SENSORS_ATK0110=m
CONFIG_SENSORS_ATXP1=m
CONFIG_SENSORS_DS1621=m
CONFIG_SENSORS_I5K_AMB=m
CONFIG_SENSORS_F71805F=m
CONFIG_SENSORS_F71882FG=m
CONFIG_SENSORS_F75375S=m
CONFIG_SENSORS_FSCHER=m
CONFIG_SENSORS_FSCPOS=m
CONFIG_SENSORS_FSCHMD=m
CONFIG_SENSORS_G760A=m
CONFIG_SENSORS_GL518SM=m
CONFIG_SENSORS_GL520SM=m
CONFIG_SENSORS_CORETEMP=m
CONFIG_SENSORS_IBMAEM=m
CONFIG_SENSORS_IBMPEX=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_LM93=m
CONFIG_SENSORS_LTC4215=m
# CONFIG_SENSORS_LTC4245 is not set
CONFIG_SENSORS_LM95241=m
CONFIG_SENSORS_MAX1619=m
CONFIG_SENSORS_MAX6650=m
CONFIG_SENSORS_PC87360=m
CONFIG_SENSORS_PC87427=m
CONFIG_SENSORS_PCF8591=m
CONFIG_SENSORS_SIS5595=m
CONFIG_SENSORS_DME1737=m
CONFIG_SENSORS_SMSC47M1=m
CONFIG_SENSORS_SMSC47M192=m
CONFIG_SENSORS_SMSC47B397=m
CONFIG_SENSORS_ADS7828=m
CONFIG_SENSORS_THMC50=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_W83L786NG=m
CONFIG_SENSORS_W83627HF=m
CONFIG_SENSORS_W83627EHF=m
CONFIG_SENSORS_HDAPS=m
CONFIG_SENSORS_LIS3LV02D=m
CONFIG_SENSORS_APPLESMC=m
# CONFIG_HWMON_DEBUG_CHIP is not set
CONFIG_THERMAL=y
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_ITCO_WDT=m
CONFIG_ITCO_VENDOR_SUPPORT=y
CONFIG_IT8712F_WDT=m
CONFIG_IT87_WDT=m
CONFIG_HP_WATCHDOG=m
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_SBC7240_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC_SCH311X_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
CONFIG_W83627HF_WDT=m
CONFIG_W83697HF_WDT=m
CONFIG_W83697UG_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_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
CONFIG_SSB=m
CONFIG_SSB_SPROM=y
CONFIG_SSB_BLOCKIO=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
CONFIG_SSB_B43_PCI_BRIDGE=y
CONFIG_SSB_PCMCIAHOST_POSSIBLE=y
CONFIG_SSB_PCMCIAHOST=y
# CONFIG_SSB_DEBUG is not set
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_SSB_DRIVER_PCICORE=y

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=m
CONFIG_MFD_SM501=m
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_TMIO is not set
CONFIG_MFD_WM8400=m
# CONFIG_MFD_PCF50633 is not set
# CONFIG_REGULATOR is not set

#
# Multimedia devices
#

#
# Multimedia core support
#
CONFIG_VIDEO_DEV=m
CONFIG_VIDEO_V4L2_COMMON=m
CONFIG_VIDEO_ALLOW_V4L1=y
CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_DVB_CORE=m
CONFIG_VIDEO_MEDIA=m

#
# Multimedia drivers
#
CONFIG_VIDEO_SAA7146=m
CONFIG_VIDEO_SAA7146_VV=m
CONFIG_MEDIA_ATTACH=y
CONFIG_MEDIA_TUNER=m
# CONFIG_MEDIA_TUNER_CUSTOMISE is not set
CONFIG_MEDIA_TUNER_SIMPLE=m
CONFIG_MEDIA_TUNER_TDA8290=m
CONFIG_MEDIA_TUNER_TDA827X=m
CONFIG_MEDIA_TUNER_TDA18271=m
CONFIG_MEDIA_TUNER_TDA9887=m
CONFIG_MEDIA_TUNER_TEA5761=m
CONFIG_MEDIA_TUNER_TEA5767=m
CONFIG_MEDIA_TUNER_MT20XX=m
CONFIG_MEDIA_TUNER_MT2131=m
CONFIG_MEDIA_TUNER_XC2028=m
CONFIG_MEDIA_TUNER_XC5000=m
CONFIG_MEDIA_TUNER_MXL5005S=m
CONFIG_MEDIA_TUNER_MC44S803=m
CONFIG_VIDEO_V4L2=m
CONFIG_VIDEO_V4L1=m
CONFIG_VIDEOBUF_GEN=m
CONFIG_VIDEOBUF_DMA_SG=m
CONFIG_VIDEOBUF_VMALLOC=m
CONFIG_VIDEOBUF_DVB=m
CONFIG_VIDEO_BTCX=m
CONFIG_VIDEO_IR=m
CONFIG_VIDEO_TVEEPROM=m
CONFIG_VIDEO_TUNER=m
CONFIG_VIDEO_CAPTURE_DRIVERS=y
# CONFIG_VIDEO_ADV_DEBUG is not set
# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
# CONFIG_VIDEO_HELPER_CHIPS_AUTO is not set
CONFIG_VIDEO_IR_I2C=m

#
# Encoders/decoders and other helper chips
#

#
# Audio decoders
#
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_CS5345=m
CONFIG_VIDEO_CS53L32A=m
CONFIG_VIDEO_M52790=m
CONFIG_VIDEO_TLV320AIC23B=m
CONFIG_VIDEO_WM8775=m
CONFIG_VIDEO_WM8739=m
CONFIG_VIDEO_VP27SMPX=m

#
# RDS decoders
#
CONFIG_VIDEO_SAA6588=m

#
# Video decoders
#
CONFIG_VIDEO_BT819=m
CONFIG_VIDEO_BT856=m
CONFIG_VIDEO_BT866=m
CONFIG_VIDEO_KS0127=m
CONFIG_VIDEO_OV7670=m
CONFIG_VIDEO_TCM825X=m
CONFIG_VIDEO_SAA7110=m
CONFIG_VIDEO_SAA711X=m
CONFIG_VIDEO_SAA717X=m
CONFIG_VIDEO_SAA7191=m
# CONFIG_VIDEO_TVP514X is not set
CONFIG_VIDEO_TVP5150=m
CONFIG_VIDEO_VPX3220=m

#
# Video and audio decoders
#
CONFIG_VIDEO_CX25840=m

#
# MPEG video encoders
#
CONFIG_VIDEO_CX2341X=m

#
# Video encoders
#
CONFIG_VIDEO_SAA7127=m
CONFIG_VIDEO_SAA7185=m
CONFIG_VIDEO_ADV7170=m
CONFIG_VIDEO_ADV7175=m

#
# Video improvement chips
#
CONFIG_VIDEO_UPD64031A=m
CONFIG_VIDEO_UPD64083=m
# CONFIG_VIDEO_VIVI is not set
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_BT848_DVB=y
# 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_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_DC30=m
CONFIG_VIDEO_ZORAN_ZR36060=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=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_HEXIUM_ORION=m
CONFIG_VIDEO_HEXIUM_GEMINI=m
CONFIG_VIDEO_CX23885=m
CONFIG_VIDEO_IVTV=m
CONFIG_VIDEO_FB_IVTV=m
CONFIG_VIDEO_CX18=m
CONFIG_VIDEO_CAFE_CCIC=m
CONFIG_SOC_CAMERA=m
CONFIG_SOC_CAMERA_MT9M001=m
CONFIG_SOC_CAMERA_MT9M111=m
# CONFIG_SOC_CAMERA_MT9T031 is not set
CONFIG_SOC_CAMERA_MT9V022=m
# CONFIG_SOC_CAMERA_TW9910 is not set
CONFIG_SOC_CAMERA_PLATFORM=m
# CONFIG_SOC_CAMERA_OV772X is not set
CONFIG_V4L_USB_DRIVERS=y
CONFIG_USB_VIDEO_CLASS=m
CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y
CONFIG_USB_GSPCA=m
CONFIG_USB_M5602=m
# CONFIG_USB_STV06XX is not set
CONFIG_USB_GSPCA_CONEX=m
CONFIG_USB_GSPCA_ETOMS=m
CONFIG_USB_GSPCA_FINEPIX=m
CONFIG_USB_GSPCA_MARS=m
CONFIG_USB_GSPCA_MR97310A=m
CONFIG_USB_GSPCA_OV519=m
# CONFIG_USB_GSPCA_OV534 is not set
CONFIG_USB_GSPCA_PAC207=m
CONFIG_USB_GSPCA_PAC7311=m
CONFIG_USB_GSPCA_SONIXB=m
CONFIG_USB_GSPCA_SONIXJ=m
CONFIG_USB_GSPCA_SPCA500=m
CONFIG_USB_GSPCA_SPCA501=m
CONFIG_USB_GSPCA_SPCA505=m
CONFIG_USB_GSPCA_SPCA506=m
CONFIG_USB_GSPCA_SPCA508=m
CONFIG_USB_GSPCA_SPCA561=m
CONFIG_USB_GSPCA_SQ905=m
CONFIG_USB_GSPCA_SQ905C=m
CONFIG_USB_GSPCA_STK014=m
CONFIG_USB_GSPCA_SUNPLUS=m
CONFIG_USB_GSPCA_T613=m
CONFIG_USB_GSPCA_TV8532=m
CONFIG_USB_GSPCA_VC032X=m
CONFIG_USB_GSPCA_ZC3XX=m
CONFIG_VIDEO_PVRUSB2=m
CONFIG_VIDEO_PVRUSB2_SYSFS=y
CONFIG_VIDEO_PVRUSB2_DVB=y
# CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set
CONFIG_VIDEO_HDPVR=m
CONFIG_VIDEO_EM28XX=m
CONFIG_VIDEO_EM28XX_ALSA=m
CONFIG_VIDEO_EM28XX_DVB=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 is not set
CONFIG_USB_PWC=m
# CONFIG_USB_PWC_DEBUG is not set
CONFIG_USB_PWC_INPUT_EVDEV=y
CONFIG_USB_ZR364XX=m
CONFIG_USB_STKWEBCAM=m
CONFIG_USB_S2255=m
CONFIG_RADIO_ADAPTERS=y
# 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
CONFIG_USB_SI470X=m
CONFIG_USB_MR800=m
# CONFIG_RADIO_TEA5764 is not set
# CONFIG_DVB_DYNAMIC_MINORS is not set
CONFIG_DVB_CAPTURE_DRIVERS=y

#
# Supported SAA7146 based PCI Adapters
#
CONFIG_TTPCI_EEPROM=m
CONFIG_DVB_AV7110=m
CONFIG_DVB_AV7110_OSD=y
CONFIG_DVB_BUDGET_CORE=m
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 is not set
CONFIG_DVB_TTUSB_BUDGET=m
CONFIG_DVB_TTUSB_DEC=m
CONFIG_DVB_SIANO_SMS1XXX=m
CONFIG_DVB_SIANO_SMS1XXX_SMS_IDS=y

#
# 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 SDMC DM1105 Adapters
#
# CONFIG_DVB_DM1105 is not set

#
# Supported DVB Frontends
#
# CONFIG_DVB_FE_CUSTOMISE is not set
CONFIG_DVB_STB0899=m
CONFIG_DVB_STB6100=m
CONFIG_DVB_CX24110=m
CONFIG_DVB_CX24123=m
CONFIG_DVB_MT312=m
CONFIG_DVB_ZL10036=m
CONFIG_DVB_S5H1420=m
CONFIG_DVB_STV0299=m
CONFIG_DVB_STV6110=m
CONFIG_DVB_STV0900=m
CONFIG_DVB_TDA8083=m
CONFIG_DVB_TDA10086=m
CONFIG_DVB_TDA8261=m
CONFIG_DVB_VES1X93=m
CONFIG_DVB_TUNER_ITD1000=m
CONFIG_DVB_TUNER_CX24113=m
CONFIG_DVB_TDA826X=m
CONFIG_DVB_TUA6100=m
CONFIG_DVB_SP8870=m
CONFIG_DVB_SP887X=m
CONFIG_DVB_CX22700=m
CONFIG_DVB_L64781=m
CONFIG_DVB_TDA1004X=m
CONFIG_DVB_NXT6000=m
CONFIG_DVB_MT352=m
CONFIG_DVB_ZL10353=m
CONFIG_DVB_DIB7000P=m
CONFIG_DVB_TDA10048=m
CONFIG_DVB_VES1820=m
CONFIG_DVB_TDA10021=m
CONFIG_DVB_TDA10023=m
CONFIG_DVB_STV0297=m
CONFIG_DVB_NXT200X=m
CONFIG_DVB_OR51211=m
CONFIG_DVB_BCM3510=m
CONFIG_DVB_LGDT330X=m
CONFIG_DVB_LGDT3305=m
CONFIG_DVB_S5H1409=m
CONFIG_DVB_S5H1411=m
CONFIG_DVB_PLL=m
CONFIG_DVB_LNBP21=m
CONFIG_DVB_ISL6405=m
CONFIG_DVB_ISL6421=m
CONFIG_DAB=y
CONFIG_USB_DABUSB=m

#
# Graphics support
#
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_I915_KMS is not set
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
CONFIG_DRM_VIA=m
CONFIG_DRM_SAVAGE=m
CONFIG_VGASTATE=m
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_DDC=m
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_SVGALIB=m
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer 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_UVESA is not set
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
# CONFIG_FB_N411 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_DEBUG is not set
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_LE80578 is not set
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=m
CONFIG_FB_SAVAGE=m
CONFIG_FB_SAVAGE_I2C=y
CONFIG_FB_SAVAGE_ACCEL=y
# CONFIG_FB_SIS is not set
CONFIG_FB_VIA=m
CONFIG_FB_NEOMAGIC=m
CONFIG_FB_KYRO=m
CONFIG_FB_3DFX=m
CONFIG_FB_3DFX_ACCEL=y
CONFIG_FB_3DFX_I2C=y
CONFIG_FB_VOODOO1=m
# CONFIG_FB_VT8623 is not set
CONFIG_FB_TRIDENT=m
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
CONFIG_FB_GEODE=y
CONFIG_FB_GEODE_LX=y
CONFIG_FB_GEODE_GX=y
# CONFIG_FB_GEODE_GX1 is not set
# CONFIG_FB_TMIO is not set
CONFIG_FB_SM501=m
# CONFIG_FB_VIRTUAL is not set
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_FB_METRONOME=m
CONFIG_FB_MB862XX=m
# CONFIG_FB_MB862XX_PCI_GDC is not set
CONFIG_FB_BROADSHEET=m
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_LCD_ILI9320 is not set
CONFIG_LCD_PLATFORM=m
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
CONFIG_BACKLIGHT_PROGEAR=m
CONFIG_BACKLIGHT_MBP_NVIDIA=m
CONFIG_BACKLIGHT_SAHARA=m

#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=m

#
# Display hardware drivers
#

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=m
CONFIG_SOUND_OSS_CORE=y
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_JACK=y
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_HRTIMER is not set
CONFIG_SND_DYNAMIC_MINORS=y
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_VERBOSE_PROCFS=y
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_DEBUG=y
# CONFIG_SND_DEBUG_VERBOSE is not set
CONFIG_SND_PCM_XRUN_DEBUG=y
CONFIG_SND_VMASTER=y
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_DRIVERS=y
CONFIG_SND_PCSP=m
CONFIG_SND_DUMMY=m
CONFIG_SND_VIRMIDI=m
CONFIG_SND_MTS64=m
CONFIG_SND_SERIAL_U16550=m
CONFIG_SND_MPU401=m
CONFIG_SND_PORTMAN2X4=m
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=5
CONFIG_SND_WSS_LIB=m
CONFIG_SND_SB_COMMON=m
CONFIG_SND_SB16_DSP=m
CONFIG_SND_ISA=y
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_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_SC6000=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
CONFIG_SND_MSND_PINNACLE=m
CONFIG_SND_MSND_CLASSIC=m
CONFIG_SND_PCI=y
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_AW2 is not set
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_OXYGEN_LIB=m
CONFIG_SND_OXYGEN=m
CONFIG_SND_CS4281=m
CONFIG_SND_CS46XX=m
CONFIG_SND_CS46XX_NEW_DSP=y
CONFIG_SND_CS5530=m
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_INDIGOIOX=m
CONFIG_SND_INDIGODJX=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_HDA_HWDEP=y
# CONFIG_SND_HDA_RECONFIG is not set
# CONFIG_SND_HDA_INPUT_BEEP is not set
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_ATIHDMI=y
CONFIG_SND_HDA_CODEC_NVHDMI=y
CONFIG_SND_HDA_CODEC_INTELHDMI=y
CONFIG_SND_HDA_ELD=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
CONFIG_SND_HDSP=m
CONFIG_SND_HDSPM=m
CONFIG_SND_HIFIER=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_SIS7019=m
CONFIG_SND_SONICVIBES=m
CONFIG_SND_TRIDENT=m
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
CONFIG_SND_VIRTUOSO=m
CONFIG_SND_VX222=m
CONFIG_SND_YMFPCI=m
CONFIG_SND_USB=y
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_USX2Y=m
CONFIG_SND_USB_CAIAQ=m
CONFIG_SND_USB_CAIAQ_INPUT=y
CONFIG_SND_USB_US122L=m
# CONFIG_SND_PCMCIA is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=m
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_HID_DEBUG=y
CONFIG_HIDRAW=y

#
# USB Input Devices
#
CONFIG_USB_HID=y
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y

#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
CONFIG_DRAGONRISE_FF=m
CONFIG_HID_EZKEY=y
CONFIG_HID_KYE=y
CONFIG_HID_GYRATION=y
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LOGITECH=y
CONFIG_LOGITECH_FF=y
CONFIG_LOGIRUMBLEPAD2_FF=y
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_NTRIG=y
CONFIG_HID_PANTHERLORD=y
CONFIG_PANTHERLORD_FF=y
CONFIG_HID_PETALYNX=y
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_SUNPLUS=y
# CONFIG_GREENASIA_FF is not set
CONFIG_HID_TOPSEED=y
CONFIG_THRUSTMASTER_FF=y
CONFIG_ZEROPLUS_FF=y
CONFIG_USB_SUPPORT=y
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
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
CONFIG_USB_OHCI_HCD=y
# 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=y
CONFIG_USB_U132_HCD=m
CONFIG_USB_SL811_HCD=m
# CONFIG_USB_SL811_CS is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HWA_HCD is not set

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

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
CONFIG_USB_STORAGE_DATAFAB=m
CONFIG_USB_STORAGE_FREECOM=m
CONFIG_USB_STORAGE_ISD200=m
CONFIG_USB_STORAGE_USBAT=m
CONFIG_USB_STORAGE_SDDR09=m
CONFIG_USB_STORAGE_SDDR55=m
CONFIG_USB_STORAGE_JUMPSHOT=m
CONFIG_USB_STORAGE_ALAUDA=m
CONFIG_USB_STORAGE_ONETOUCH=m
CONFIG_USB_STORAGE_KARMA=m
CONFIG_USB_STORAGE_CYPRESS_ATACB=m
# CONFIG_USB_LIBUSUAL is not set

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

#
# USB port drivers
#
CONFIG_USB_USS720=m
CONFIG_USB_SERIAL=m
CONFIG_USB_EZUSB=y
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_AIRCABLE=m
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_CH341=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CP210X=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 is not set
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_IUU=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
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_MOTOROLA=m
CONFIG_USB_SERIAL_NAVMAN=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_OTI6858=m
CONFIG_USB_SERIAL_QUALCOMM=m
CONFIG_USB_SERIAL_SPCP8X5=m
CONFIG_USB_SERIAL_HP4X=m
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
# CONFIG_USB_SERIAL_SIEMENS_MPI is not set
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
CONFIG_USB_SERIAL_SYMBOL=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_OPTICON is not set
CONFIG_USB_SERIAL_DEBUG=m

#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_ADUTUX=m
CONFIG_USB_SEVSEG=m
# CONFIG_USB_RIO500 is not set
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
CONFIG_USB_BERRY_CHARGE=m
CONFIG_USB_LED=m
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
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=m
# CONFIG_USB_TEST is not set
CONFIG_USB_ISIGHTFW=m
CONFIG_USB_VST=m
CONFIG_USB_ATM=m
CONFIG_USB_SPEEDTOUCH=m
CONFIG_USB_CXACRU=m
CONFIG_USB_UEAGLEATM=m
CONFIG_USB_XUSBATM=m

#
# OTG and related infrastructure
#
CONFIG_USB_OTG_UTILS=y
CONFIG_NOP_USB_XCEIV=m
# CONFIG_UWB is not set
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_SDIO_UART=m
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PCI=m
CONFIG_MMC_RICOH_MMC=m
CONFIG_MMC_WBSD=m
CONFIG_MMC_TIFM_SD=m
CONFIG_MMC_SDRICOH_CS=m
CONFIG_MEMSTICK=m
# CONFIG_MEMSTICK_DEBUG is not set

#
# MemoryStick drivers
#
# CONFIG_MEMSTICK_UNSAFE_RESUME is not set
CONFIG_MSPRO_BLOCK=m

#
# MemoryStick Host Controller Drivers
#
CONFIG_MEMSTICK_TIFM_MS=m
CONFIG_MEMSTICK_JMICRON_38X=m
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_ALIX2 is not set
# CONFIG_LEDS_PCA9532 is not set
CONFIG_LEDS_LP5521=m
CONFIG_LEDS_CLEVO_MAIL=m
# CONFIG_LEDS_PCA955X is not set
CONFIG_LEDS_BD2802=m

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_LEDS_TRIGGER_HEARTBEAT=m
CONFIG_LEDS_TRIGGER_BACKLIGHT=m
CONFIG_LEDS_TRIGGER_DEFAULT_ON=m

#
# iptables trigger is under Netfilter config (LED target)
#
CONFIG_ACCESSIBILITY=y
CONFIG_A11Y_BRAILLE_CONSOLE=y
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_I82975X=m
CONFIG_EDAC_I3000=m
CONFIG_EDAC_X38=m
# CONFIG_EDAC_I5400 is not set
CONFIG_EDAC_I82860=m
CONFIG_EDAC_R82600=m
CONFIG_EDAC_I5000=m
CONFIG_EDAC_I5100=m
CONFIG_EDAC_AMD8131=m
CONFIG_EDAC_AMD8111=m
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=m
CONFIG_RTC_DRV_DS1374=m
CONFIG_RTC_DRV_DS1672=m
CONFIG_RTC_DRV_MAX6900=m
CONFIG_RTC_DRV_RS5C372=m
CONFIG_RTC_DRV_ISL1208=m
CONFIG_RTC_DRV_X1205=m
CONFIG_RTC_DRV_PCF8563=m
CONFIG_RTC_DRV_PCF8583=m
CONFIG_RTC_DRV_M41T80=m
CONFIG_RTC_DRV_M41T80_WDT=y
# CONFIG_RTC_DRV_S35390A is not set
CONFIG_RTC_DRV_FM3130=m
CONFIG_RTC_DRV_RX8581=m

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
CONFIG_RTC_DRV_DS1286=m
CONFIG_RTC_DRV_DS1511=m
CONFIG_RTC_DRV_DS1553=m
CONFIG_RTC_DRV_DS1742=m
CONFIG_RTC_DRV_STK17TA8=m
# CONFIG_RTC_DRV_M48T86 is not set
CONFIG_RTC_DRV_M48T35=m
CONFIG_RTC_DRV_M48T59=m
CONFIG_RTC_DRV_BQ4802=m
CONFIG_RTC_DRV_V3020=m

#
# on-CPU RTC drivers
#
CONFIG_AUXDISPLAY=y
CONFIG_KS0108=m
CONFIG_KS0108_PORT=0x378
CONFIG_KS0108_DELAY=2
CONFIG_CFAG12864B=m
CONFIG_CFAG12864B_RATE=20
CONFIG_UIO=m
CONFIG_UIO_CIF=m
CONFIG_UIO_PDRV=m
CONFIG_UIO_PDRV_GENIRQ=m
CONFIG_UIO_SMX=m
CONFIG_UIO_AEC=m
CONFIG_UIO_SERCOS3=m
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
CONFIG_ACER_WMI=m
CONFIG_ASUS_LAPTOP=m
CONFIG_DELL_WMI=m
CONFIG_FUJITSU_LAPTOP=m
# CONFIG_FUJITSU_LAPTOP_DEBUG is not set
CONFIG_TC1100_WMI=m
CONFIG_HP_WMI=m
CONFIG_MSI_LAPTOP=m
CONFIG_PANASONIC_LAPTOP=m
CONFIG_COMPAL_LAPTOP=m
CONFIG_SONY_LAPTOP=m
CONFIG_SONYPI_COMPAT=y
CONFIG_THINKPAD_ACPI=m
# CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set
# CONFIG_THINKPAD_ACPI_DEBUG is not set
# CONFIG_THINKPAD_ACPI_UNSAFE_LEDS is not set
CONFIG_THINKPAD_ACPI_BAY=y
CONFIG_THINKPAD_ACPI_VIDEO=y
CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y
# CONFIG_INTEL_MENLOW is not set
# CONFIG_EEEPC_LAPTOP is not set
CONFIG_ACPI_WMI=m
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_TOSHIBA=m

#
# Firmware Drivers
#
CONFIG_EDD=m
# CONFIG_EDD_OFF is not set
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_EFI_VARS=y
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
CONFIG_DMIID=y
CONFIG_ISCSI_IBFT_FIND=y
CONFIG_ISCSI_IBFT=m

#
# File systems
#
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT2_FS_XIP=y
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS=m
CONFIG_EXT4DEV_COMPAT=y
CONFIG_EXT4_FS_XATTR=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_FS_XIP=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=m
CONFIG_JBD2_DEBUG=y
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_FILE_LOCKING=y
CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_DEBUG is not set
CONFIG_GFS2_FS=m
# CONFIG_GFS2_FS_LOCKING_DLM is not set
CONFIG_OCFS2_FS=m
CONFIG_OCFS2_FS_O2CB=m
CONFIG_OCFS2_FS_USERSPACE_CLUSTER=m
# CONFIG_OCFS2_FS_STATS is not set
# CONFIG_OCFS2_DEBUG_MASKLOG is not set
# CONFIG_OCFS2_DEBUG_FS is not set
# CONFIG_OCFS2_FS_POSIX_ACL is not set
# CONFIG_BTRFS_FS is not set
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
# CONFIG_PRINT_QUOTA_WARNING is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# 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_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_CONFIGFS_FS=m
CONFIG_MISC_FILESYSTEMS=y
# 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_FS_WBUF_VERIFY is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
# CONFIG_JFFS2_LZO is not set
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
CONFIG_UBIFS_FS=m
CONFIG_UBIFS_FS_XATTR=y
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
# CONFIG_UBIFS_FS_DEBUG is not set
CONFIG_CRAMFS=m
# CONFIG_SQUASHFS is not set
CONFIG_VXFS_FS=m
CONFIG_MINIX_FS=m
CONFIG_OMFS_FS=m
# CONFIG_HPFS_FS is not set
CONFIG_QNX4FS_FS=m
CONFIG_ROMFS_FS=m
CONFIG_ROMFS_BACKED_BY_BLOCK=y
# CONFIG_ROMFS_BACKED_BY_MTD is not set
# CONFIG_ROMFS_BACKED_BY_BOTH is not set
CONFIG_ROMFS_ON_BLOCK=y
CONFIG_SYSV_FS=m
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set
# CONFIG_UFS_DEBUG is not set
# CONFIG_EXOFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=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_UPCALL=y
CONFIG_CIFS_XATTR=y
CONFIG_CIFS_POSIX=y
# CONFIG_CIFS_DEBUG2 is not set
CONFIG_CIFS_DFS_UPCALL=y
CONFIG_CIFS_EXPERIMENTAL=y
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_AFS_FS is not set

#
# 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
# CONFIG_SYSV68_PARTITION is not set
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
CONFIG_DLM=m
CONFIG_DLM_DEBUG=y

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ALLOW_WARNINGS=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
CONFIG_UNUSED_SYMBOLS=y
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_SHIRQ=y
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
CONFIG_DEBUG_SPINLOCK_SLEEP=y
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_HIGHMEM=y
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
CONFIG_BOOT_PRINTK_DELAY=y
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
# CONFIG_SYSCTL_SYSCALL_CHECK is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_FTRACE_SYSCALLS=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set
CONFIG_BUILD_DOCSRC=y
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_KGDB_TESTS=y
# CONFIG_KGDB_TESTS_ON_BOOT is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_STRICT_DEVMEM=y
# CONFIG_X86_VERBOSE_BOOTUP is not set
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_X86_PTDUMP is not set
CONFIG_DEBUG_RODATA=y
# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DEBUG_NX_TEST is not set
CONFIG_4KSTACKS=y
CONFIG_DOUBLEFAULT=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_DEBUG_PROC_KEYS=y
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_PATH is not set
CONFIG_SECURITY_FILE_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=65536
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_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_IMA is not set
CONFIG_XOR_BLOCKS=m
CONFIG_ASYNC_CORE=m
CONFIG_ASYNC_MEMCPY=m
CONFIG_ASYNC_XOR=m
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m

#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_SEQIV=m

#
# Block modes
#
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_CTR=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m

#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_CRC32C_INTEL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_RMD128=m
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m

#
# Ciphers
#
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_SALSA20_586=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_586=m

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_ZLIB=m
CONFIG_CRYPTO_LZO=m

#
# Random Number Generation
#
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_PADLOCK is not set
CONFIG_CRYPTO_DEV_GEODE=m
CONFIG_CRYPTO_DEV_HIFN_795X=m
CONFIG_CRYPTO_DEV_HIFN_795X_RNG=y
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
CONFIG_KVM_TRACE=y
CONFIG_VIRTIO=m
CONFIG_VIRTIO_RING=m
CONFIG_VIRTIO_PCI=m
CONFIG_VIRTIO_BALLOON=m
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=m
CONFIG_LZO_DECOMPRESS=m
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=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_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_NLATTR=y

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0 / CONFIG_HIGHPTE problems
  2009-05-07 18:46                                       ` Pasi Kärkkäinen
@ 2009-05-14 11:11                                         ` Pasi Kärkkäinen
  2009-05-15 22:48                                           ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-05-14 11:11 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Ian Campbell, Xen-devel

On Thu, May 07, 2009 at 09:46:24PM +0300, Pasi Kärkkäinen wrote:
> On Thu, May 07, 2009 at 11:30:04AM -0700, Jeremy Fitzhardinge wrote:
> > Pasi Kärkkäinen wrote:
> > >I just tried with CONFIG_HIGHPTE=y but that didn't seem to work:
> > >http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-30-xen331-linux-2.6.30-rc3-next-crash-with-highpte.txt
> > >
> > >(XEN) mm.c:2006:d0 Bad type (saw 28000001 != exp e0000000) for mfn 6b0a6 
> > >(pfn 2c959)
> > >(XEN) mm.c:707:d0 Error getting mfn 6b0a6 (pfn 2c959) from L1 entry 
> > >000000006b0a6063 for dom0
> > >(XEN) mm.c:3640:d0 ptwr_emulate: could not get_page_from_l1e()
> > >
> > >BUG: unable to handle kernel paging request at c0207d58
> > >IP: [<c0405bf7>] xen_set_pte+0x89/0x93
> > >*pdpt = 000000003c8ef001 
> > >Oops: 0003 [#1] SMP 
> > >Pid: 323, comm: kswapd0 Not tainted (2.6.30-rc3-tip #34) P8SC8
> > >EIP: 0061:[<c0405bf7>] EFLAGS: 00010296 CPU: 0
> > >EIP is at xen_set_pte+0x89/0x93
> > >EAX: 00000000 EBX: c0207d58 ECX: 00000000 EDX: 6b0a6063
> > >ESI: 00000000 EDI: 000bd778 EBP: e254cd80 ESP: e254cd70
> > > DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
> > >Process kswapd0 (pid: 323, ti=e254c000 task=e25c8000 task.ti=e254c000)
> > >  
> > 
> > Hm, can't have everything I suppose...  I wonder what's going on here; I 
> > haven't seen any problems with highpte at all.  Something .config-specific?
> > 
> 
> Hmm.. it could be my .config.
> 
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/config-2.6.30-rc3-tip-next-with-highpte
> 
> Also attached to this mail. It's originally based on Fedora 10 default kernel config.
> 
> Anything suspicious?
> 

I can also try with your .config .. 

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0 / CONFIG_HIGHPTE problems
  2009-05-14 11:11                                         ` xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0 / CONFIG_HIGHPTE problems Pasi Kärkkäinen
@ 2009-05-15 22:48                                           ` Jeremy Fitzhardinge
  0 siblings, 0 replies; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-05-15 22:48 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Ian Campbell, Xen-devel

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

Pasi Kärkkäinen wrote:
> I can also try with your .config .. 
>
> -- Pasi
>   

Attached.

    J

[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 63764 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.30-rc3
# Fri May  1 14:36:43 2009
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=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_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_HAVE_DYNAMIC_PER_CPU_AREA=y
# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=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_AUDIT is not set

#
# RCU Subsystem
#
CONFIG_CLASSIC_RCU=y
# CONFIG_TREE_RCU is not set
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_PREEMPT_RCU_TRACE is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not set
# CONFIG_CGROUPS is not set
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_RELAY=y
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=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_STRIP_ASM_SYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_HAVE_PERF_COUNTERS=y

#
# Performance Counters
#
CONFIG_PERF_COUNTERS=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
# CONFIG_MARKERS is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_API_DEBUG=y
# CONFIG_SLOW_WORK is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_INTEGRITY is not set

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

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
# CONFIG_SPARSE_IRQ is not set
# CONFIG_X86_MPPARSE is not set
# CONFIG_X86_BIGSMP is not set
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_RDC321X is not set
# CONFIG_X86_32_NON_STANDARD is not set
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
CONFIG_XEN=y
CONFIG_XEN_MAX_DOMAIN_MEMORY=8
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_XEN_DEBUG_FS=y
CONFIG_XEN_PCI_PASSTHROUGH=y
CONFIG_XEN_DOM0_PCI=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PRIVILEGED_GUEST=y
CONFIG_XEN_PCI_PASSTHROUGH_DEBUG=y
CONFIG_MICROCODE_XEN=y
CONFIG_VMI=y
CONFIG_KVM_CLOCK=y
CONFIG_KVM_GUEST=y
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_PARAVIRT_DEBUG is not set
# CONFIG_MEMTEST is not set
# 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 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUMM=y
# 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_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_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CPU=y
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_CYRIX_32=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_CPU_SUP_UMC_32=y
# CONFIG_X86_DS is not set
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_IOMMU_API is not set
CONFIG_NR_CPUS=8
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
# CONFIG_MICROCODE_AMD is not set
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
# CONFIG_X86_CPU_DEBUG is not set
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_X86_PAE=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ILLEGAL_POINTER_VALUE=0
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=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_UNEVICTABLE_LRU=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
CONFIG_MMU_NOTIFIER=y
CONFIG_HIGHPTE=y
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
# CONFIG_X86_RESERVE_LOW_64K is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
# CONFIG_EFI is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management and ACPI options
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
# CONFIG_HIBERNATION is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
# CONFIG_APM is not set

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

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

#
# shared options
#
# CONFIG_X86_SPEEDSTEP_LIB is not set
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
# CONFIG_PCI_GOOLPC is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
# CONFIG_DMAR is not set
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_LEGACY is not set
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
# CONFIG_HT_IRQ is not set
# CONFIG_PCI_IOV is not set
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_OLPC is not set
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_HAVE_AOUT=y
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_HAVE_ATOMIC_IOMAP=y
CONFIG_NET=y

#
# Networking options
#
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_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=y
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
CONFIG_INET6_IPCOMP=y
# CONFIG_IPV6_MIP6 is not set
CONFIG_INET6_XFRM_TUNNEL=y
CONFIG_INET6_TUNNEL=y
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=y
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=y

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
CONFIG_NF_CONNTRACK=m
# CONFIG_NF_CT_ACCT is not set
# CONFIG_NF_CONNTRACK_MARK is not set
# CONFIG_NF_CONNTRACK_EVENTS is not set
# CONFIG_NF_CT_PROTO_DCCP is not set
# CONFIG_NF_CT_PROTO_SCTP is not set
# CONFIG_NF_CT_PROTO_UDPLITE is not set
# CONFIG_NF_CONNTRACK_AMANDA is not set
CONFIG_NF_CONNTRACK_FTP=m
# CONFIG_NF_CONNTRACK_H323 is not set
# CONFIG_NF_CONNTRACK_IRC is not set
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_CONNTRACK_SANE is not set
# CONFIG_NF_CONNTRACK_SIP is not set
# CONFIG_NF_CONNTRACK_TFTP is not set
# CONFIG_NF_CT_NETLINK is not set
CONFIG_NETFILTER_XTABLES=m
# CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set
# CONFIG_NETFILTER_XT_TARGET_CONNMARK is not set
# CONFIG_NETFILTER_XT_TARGET_LED is not set
# CONFIG_NETFILTER_XT_TARGET_MARK is not set
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
# CONFIG_NETFILTER_XT_TARGET_RATEEST is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_CLUSTER is not set
# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set
# CONFIG_NETFILTER_XT_MATCH_CONNLIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNMARK is not set
# CONFIG_NETFILTER_XT_MATCH_CONNTRACK is not set
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_HELPER is not set
CONFIG_NETFILTER_XT_MATCH_HL=m
# CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
# CONFIG_NETFILTER_XT_MATCH_LIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_MAC is not set
# CONFIG_NETFILTER_XT_MATCH_MARK is not set
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
# CONFIG_NETFILTER_XT_MATCH_POLICY is not set
# CONFIG_NETFILTER_XT_MATCH_PHYSDEV is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_RATEEST is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
# CONFIG_NETFILTER_XT_MATCH_RECENT is not set
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
CONFIG_NETFILTER_XT_MATCH_STATE=m
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
# CONFIG_NETFILTER_XT_MATCH_STRING is not set
# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=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_NETMAP is not set
# CONFIG_IP_NF_TARGET_REDIRECT is not set
# CONFIG_NF_NAT_SNMP_BASIC is not set
CONFIG_NF_NAT_FTP=m
# CONFIG_NF_NAT_IRC is not set
# CONFIG_NF_NAT_TFTP is not set
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
# CONFIG_NF_NAT_SIP is not set
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_NF_TARGET_TTL is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_ARPTABLES is not set

#
# IPv6: Netfilter Configuration
#
# CONFIG_NF_CONNTRACK_IPV6 is not set
# CONFIG_IP6_NF_QUEUE is not set
# CONFIG_IP6_NF_IPTABLES is not set
# CONFIG_BRIDGE_NF_EBTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
CONFIG_STP=m
CONFIG_BRIDGE=m
# CONFIG_NET_DSA is not set
CONFIG_VLAN_8021Q=m
# CONFIG_VLAN_8021Q_GVRP is not set
# CONFIG_DECNET is not set
CONFIG_LLC=m
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
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_HIDP=m

#
# Bluetooth device drivers
#
CONFIG_BT_HCIBTUSB=m
# CONFIG_BT_HCIBTSDIO is not set
CONFIG_BT_HCIUART=m
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_BCSP=y
# CONFIG_BT_HCIUART_LL is not set
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BT_HCIBPA10X is not set
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIVHCI is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
CONFIG_CFG80211=m
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
CONFIG_LIB80211=m
# CONFIG_LIB80211_DEBUG is not set
CONFIG_MAC80211=m

#
# Rate control algorithm selection
#
CONFIG_MAC80211_RC_MINSTREL=y
# CONFIG_MAC80211_RC_DEFAULT_PID is not set
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel"
CONFIG_MAC80211_MESH=y
CONFIG_MAC80211_LEDS=y
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_INPUT=m
CONFIG_RFKILL_LEDS=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
CONFIG_SYS_HYPERVISOR=y
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=16384
# CONFIG_BLK_DEV_XIP is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_XEN_BLKDEV_FRONTEND=y
# CONFIG_VIRTIO_BLK is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_ISL29003 is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_93CX6 is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
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 is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set

#
# 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
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=m
CONFIG_SCSI_FC_ATTRS=m
CONFIG_SCSI_ISCSI_ATTRS=m
CONFIG_SCSI_SAS_ATTRS=m
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_MPT2SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_FCOE is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_SRP is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
CONFIG_SATA_PMP=y
CONFIG_SATA_AHCI=m
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=m
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=m
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
CONFIG_PATA_MPIIX=m
CONFIG_PATA_OLDPIIX=m
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_SCH is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
# CONFIG_DM_CRYPT is not set
CONFIG_DM_SNAPSHOT=y
CONFIG_DM_MIRROR=m
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
CONFIG_DM_UEVENT=y
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#

#
# Enable only one of the two stacks, unless you know what you are doing
#
# CONFIG_FIREWIRE is not set
CONFIG_IEEE1394=m
CONFIG_IEEE1394_OHCI1394=m
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y
CONFIG_IEEE1394_ETH1394=m
CONFIG_IEEE1394_RAWIO=m
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_DV1394=m
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_COMPAT_NET_DEV_OPS=y
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=m
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_ETHOC is not set
# CONFIG_DNET is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
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_R6040 is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SMSC9420 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_NET_POCKET is not set
# CONFIG_ATL2 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=m
CONFIG_E1000E=m
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_JME is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_LIBERTAS is not set
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AIRO is not set
# CONFIG_ATMEL is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
# CONFIG_ADM8211 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_MWL8K is not set
# CONFIG_P54_COMMON is not set
# CONFIG_ATH5K is not set
# CONFIG_ATH9K is not set
# CONFIG_AR9170_USB is not set
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
CONFIG_IWLWIFI=m
# CONFIG_IWLWIFI_LEDS is not set
CONFIG_IWLWIFI_RFKILL=y
# CONFIG_IWLWIFI_SPECTRUM_MEASUREMENT is not set
# CONFIG_IWLWIFI_DEBUG is not set
# CONFIG_IWLAGN is not set
CONFIG_IWL3945=m
CONFIG_IWL3945_SPECTRUM_MEASUREMENT=y
# CONFIG_HOSTAP is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_ZD1211RW is not set
# CONFIG_HERMES is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_HSO is not set
# CONFIG_WAN is not set
CONFIG_XEN_NETDEV_FRONTEND=m
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
CONFIG_PPP_ASYNC=m
# CONFIG_PPP_SYNC_TTY is not set
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
# CONFIG_PPP_MPPE is not set
# CONFIG_PPPOE is not set
# CONFIG_PPPOL2TP is not set
# CONFIG_SLIP is not set
CONFIG_SLHC=m
# CONFIG_NET_FC is not set
CONFIG_NETCONSOLE=y
# CONFIG_NETCONSOLE_DYNAMIC is not set
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_VIRTIO_NET is not set
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set

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

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

#
# 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 is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
CONFIG_INPUT_UINPUT=m

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

#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_DEVKMEM=y
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
CONFIG_LP_CONSOLE=y
CONFIG_PPDEV=m
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
# CONFIG_VIRTIO_CONSOLE is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
CONFIG_HW_RANDOM_INTEL=m
# CONFIG_HW_RANDOM_AMD is not set
# CONFIG_HW_RANDOM_GEODE is not set
# CONFIG_HW_RANDOM_VIA is not set
# CONFIG_HW_RANDOM_VIRTIO is not set
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
CONFIG_HPET_MMAP=y
CONFIG_HANGCHECK_TIMER=m
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_CHARDEV is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=m

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_SIMTEC is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Graphics adapter I2C/DDC channel drivers
#
# CONFIG_I2C_VOODOO3 is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_STUB is not set
# CONFIG_SCx200_ACB is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_PCF8575 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# 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
# CONFIG_SPI is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_BATTERY_BQ27x00 is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7473 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATK0110 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
CONFIG_SENSORS_CORETEMP=m
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_SENSORS_HDAPS=m
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
CONFIG_THERMAL=y
# CONFIG_THERMAL_HWMON is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_REGULATOR is not set

#
# Multimedia devices
#

#
# Multimedia core support
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_VIDEO_MEDIA is not set

#
# Multimedia drivers
#
# CONFIG_DAB is not set

#
# Graphics support
#
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=m
# CONFIG_DRM_I915_KMS is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=m
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_DDC=m
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=m
CONFIG_FB_SYS_COPYAREA=m
CONFIG_FB_SYS_IMAGEBLIT=m
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=m
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# 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 is not set
CONFIG_FB_VESA=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_LE80578 is not set
CONFIG_FB_INTEL=m
CONFIG_FB_INTEL_DEBUG=y
CONFIG_FB_INTEL_I2C=y
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
CONFIG_XEN_FBDEV_FRONTEND=m
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=m
# CONFIG_LCD_ILI9320 is not set
# CONFIG_LCD_PLATFORM is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_PROGEAR is not set
# CONFIG_BACKLIGHT_MBP_NVIDIA is not set
# CONFIG_BACKLIGHT_SAHARA is not set

#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=m

#
# Display hardware drivers
#

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=128
CONFIG_DUMMY_CONSOLE=y
# CONFIG_FRAMEBUFFER_CONSOLE is not set
# CONFIG_LOGO is not set
CONFIG_SOUND=m
CONFIG_SOUND_OSS_CORE=y
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_JACK=y
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_HRTIMER is not set
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
CONFIG_SND_VMASTER=y
CONFIG_SND_MPU401_UART=m
CONFIG_SND_DRIVERS=y
# CONFIG_SND_PCSP is not set
CONFIG_SND_DUMMY=m
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
CONFIG_SND_MPU401=m
# CONFIG_SND_PORTMAN2X4 is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_INDIGOIOX is not set
# CONFIG_SND_INDIGODJX is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=m
# CONFIG_SND_HDA_HWDEP is not set
# CONFIG_SND_HDA_INPUT_BEEP is not set
# CONFIG_SND_HDA_CODEC_REALTEK is not set
CONFIG_SND_HDA_CODEC_ANALOG=y
# CONFIG_SND_HDA_CODEC_SIGMATEL is not set
# CONFIG_SND_HDA_CODEC_VIA is not set
# CONFIG_SND_HDA_CODEC_ATIHDMI is not set
CONFIG_SND_HDA_CODEC_NVHDMI=y
CONFIG_SND_HDA_CODEC_INTELHDMI=y
CONFIG_SND_HDA_ELD=y
# CONFIG_SND_HDA_CODEC_CONEXANT is not set
# CONFIG_SND_HDA_CODEC_CMEDIA is not set
# CONFIG_SND_HDA_CODEC_SI3054 is not set
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=5
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_HIFIER is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SIS7019 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_USB=y
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set
# CONFIG_SND_USB_US122L is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
CONFIG_HIDRAW=y

#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
CONFIG_USB_HIDDEV=y

#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
CONFIG_HID_APPLE=y
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
CONFIG_HID_CYPRESS=y
# CONFIG_DRAGONRISE_FF is not set
CONFIG_HID_EZKEY=y
CONFIG_HID_KYE=y
CONFIG_HID_GYRATION=y
CONFIG_HID_KENSINGTON=y
CONFIG_HID_LOGITECH=y
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
CONFIG_HID_NTRIG=y
CONFIG_HID_PANTHERLORD=y
# CONFIG_PANTHERLORD_FF is not set
CONFIG_HID_PETALYNX=y
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
CONFIG_HID_SUNPLUS=y
# CONFIG_GREENASIA_FF is not set
CONFIG_HID_TOPSEED=y
# CONFIG_THRUSTMASTER_FF is not set
# CONFIG_ZEROPLUS_FF is not set
CONFIG_USB_SUPPORT=y
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
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_DEVICE_CLASS is not set
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
# CONFIG_USB_MON is not set
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HWA_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

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

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set

#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
CONFIG_USB_SERIAL=m
# CONFIG_USB_EZUSB is not set
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_CH341 is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP210X is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
CONFIG_USB_SERIAL_FTDI_SIO=m
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
CONFIG_USB_SERIAL_GARMIN=m
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_IUU is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_MOTOROLA is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_OTI6858 is not set
# CONFIG_USB_SERIAL_QUALCOMM is not set
# CONFIG_USB_SERIAL_SPCP8X5 is not set
# CONFIG_USB_SERIAL_HP4X is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIEMENS_MPI is not set
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
# CONFIG_USB_SERIAL_SYMBOL is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_OPTICON is not set
# CONFIG_USB_SERIAL_DEBUG is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_VST is not set

#
# OTG and related infrastructure
#
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_UWB is not set
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
# CONFIG_MMC_SDHCI_PCI is not set
# CONFIG_MMC_WBSD is not set
# CONFIG_MMC_TIFM_SD is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_ALIX2 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_BD2802 is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y

#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
# CONFIG_RTC_INTF_SYSFS is not set
# CONFIG_RTC_INTF_PROC is not set
# CONFIG_RTC_INTF_DEV is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SCRUB_PAGES=y
CONFIG_XEN_DEV_EVTCHN=y
CONFIG_XEN_BACKEND=y
CONFIG_XEN_BLKDEV_BACKEND=y
CONFIG_XEN_NETDEV_BACKEND=y
CONFIG_XENFS=y
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=y
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACER_WMI is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_TC1100_WMI is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_PANASONIC_LAPTOP is not set
# CONFIG_COMPAL_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
CONFIG_THINKPAD_ACPI=y
# CONFIG_THINKPAD_ACPI_DEBUGFACILITIES is not set
# CONFIG_THINKPAD_ACPI_DEBUG is not set
# CONFIG_THINKPAD_ACPI_UNSAFE_LEDS is not set
CONFIG_THINKPAD_ACPI_BAY=y
CONFIG_THINKPAD_ACPI_VIDEO=y
CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y
# CONFIG_INTEL_MENLOW is not set
# CONFIG_EEEPC_LAPTOP is not set
# CONFIG_ACPI_WMI is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y
# CONFIG_ISCSI_IBFT_FIND is not set

#
# File systems
#
# CONFIG_EXT2_FS is not set
CONFIG_EXT3_FS=y
# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
CONFIG_XFS_FS=y
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_POSIX_ACL is not set
# CONFIG_XFS_RT is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
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=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
CONFIG_HFSPLUS_FS=m
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_V3_ACL is not set
# CONFIG_NFS_V4 is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V3_ACL is not set
CONFIG_NFSD_V4=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set

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

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ALLOW_WARNINGS=y
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
CONFIG_SYSCTL_SYSCALL_CHECK=y
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_FTRACE_SYSCALLS=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
CONFIG_HAVE_ARCH_KMEMCHECK=y
CONFIG_STRICT_DEVMEM=y
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_X86_PTDUMP is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_DEBUG_NX_TEST is not set
# CONFIG_4KSTACKS is not set
CONFIG_DOUBLEFAULT=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_DEBUG_BOOT_PARAMS is not set
# CONFIG_CPA_DEBUG is not set
# CONFIG_OPTIMIZE_INLINING is not set

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
# CONFIG_IMA is not set
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
# CONFIG_CRYPTO_FIPS is not set
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=y
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
CONFIG_CRYPTO_ECB=m
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_CRC32C_INTEL is not set
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=m
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_586 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_HW is not set
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
# CONFIG_KVM_AMD is not set
# CONFIG_KVM_TRACE is not set
CONFIG_VIRTIO=m
CONFIG_VIRTIO_RING=m
CONFIG_VIRTIO_PCI=m
CONFIG_VIRTIO_BALLOON=m
# CONFIG_BINARY_PRINTF is not set

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=m
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-07 17:24                                   ` Pasi Kärkkäinen
  2009-05-07 18:30                                     ` Jeremy Fitzhardinge
@ 2009-05-18 14:57                                     ` Ian Campbell
  2009-05-18 17:06                                       ` Pasi Kärkkäinen
  1 sibling, 1 reply; 118+ messages in thread
From: Ian Campbell @ 2009-05-18 14:57 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

Hi Pasi,

On Thu, 2009-05-07 at 13:24 -0400, Pasi Kärkkäinen wrote:
> On Wed, May 06, 2009 at 02:51:59PM -0700, Jeremy Fitzhardinge wrote:
> > Great!  I'd be interested to know if you're still having HIGHPTE 
> > problems.  It may or may not have got fixed.
> > 
> 
> I just tried with CONFIG_HIGHPTE=y but that didn't seem to work:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-30-xen331-linux-2.6.30-rc3-next-crash-with-highpte.txt
> 
> (XEN) mm.c:2006:d0 Bad type (saw 28000001 != exp e0000000) for mfn 6b0a6 (pfn 2c959)
> (XEN) mm.c:707:d0 Error getting mfn 6b0a6 (pfn 2c959) from L1 entry 000000006b0a6063 for dom0
> (XEN) mm.c:3640:d0 ptwr_emulate: could not get_page_from_l1e()

I thought I might have a poke at this, how do you go about reproducing
it? I've used your .config and it boots OK -- now I'm trying a kernbench
run since I think you mentioned compiling a kernel in domain 0 at one
point.

How much RAM does your host have? Are you running 32 or 64 bit
hypervisor? Which hypervisor version? From your .config I think your
dom0 kernel is 32 bit, right?

Ian.

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-18 14:57                                     ` xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0 Ian Campbell
@ 2009-05-18 17:06                                       ` Pasi Kärkkäinen
  2009-05-18 17:17                                         ` Pasi Kärkkäinen
  2009-05-18 19:09                                         ` Pasi Kärkkäinen
  0 siblings, 2 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-05-18 17:06 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Mon, May 18, 2009 at 03:57:07PM +0100, Ian Campbell wrote:
> Hi Pasi,
> 
> On Thu, 2009-05-07 at 13:24 -0400, Pasi Kärkkäinen wrote:
> > On Wed, May 06, 2009 at 02:51:59PM -0700, Jeremy Fitzhardinge wrote:
> > > Great!  I'd be interested to know if you're still having HIGHPTE 
> > > problems.  It may or may not have got fixed.
> > > 
> > 
> > I just tried with CONFIG_HIGHPTE=y but that didn't seem to work:
> > http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-30-xen331-linux-2.6.30-rc3-next-crash-with-highpte.txt
> > 
> > (XEN) mm.c:2006:d0 Bad type (saw 28000001 != exp e0000000) for mfn 6b0a6 (pfn 2c959)
> > (XEN) mm.c:707:d0 Error getting mfn 6b0a6 (pfn 2c959) from L1 entry 000000006b0a6063 for dom0
> > (XEN) mm.c:3640:d0 ptwr_emulate: could not get_page_from_l1e()
> 
> I thought I might have a poke at this, how do you go about reproducing
> it? I've used your .config and it boots OK -- now I'm trying a kernbench
> run since I think you mentioned compiling a kernel in domain 0 at one
> point.
> 

I can reproduce it every time like this:

- boot into pv_ops dom0 kernel
- run "make bzImage && make modules"
- wait for the kernel compilation to finish..
- *crash*, before the compilation finishes, usually within 15-30mins

> How much RAM does your host have? Are you running 32 or 64 bit
> hypervisor? Which hypervisor version? From your .config I think your
> dom0 kernel is 32 bit, right?
> 

My host has 2GB of RAM.

Hypervisor is 32bit PAE, Fedora 11 Xen 3.3.1-11 rpms.
My dom0 kernel is 32bit PAE aswell.

grub.conf:

kernel /xen-3.3.gz dom0_mem=1024M
module /vmlinuz-2.6.30-rc3-tip root=/dev/sda1 ro
module /boot/initrd.img-2.6.30-rc3-tip

I'm (was) using xen-tip/next.

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-18 17:06                                       ` Pasi Kärkkäinen
@ 2009-05-18 17:17                                         ` Pasi Kärkkäinen
  2009-05-18 17:39                                           ` Jeremy Fitzhardinge
  2009-05-18 19:09                                         ` Pasi Kärkkäinen
  1 sibling, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-05-18 17:17 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Mon, May 18, 2009 at 08:06:26PM +0300, Pasi Kärkkäinen wrote:
> On Mon, May 18, 2009 at 03:57:07PM +0100, Ian Campbell wrote:
> > Hi Pasi,
> > 
> > On Thu, 2009-05-07 at 13:24 -0400, Pasi Kärkkäinen wrote:
> > > On Wed, May 06, 2009 at 02:51:59PM -0700, Jeremy Fitzhardinge wrote:
> > > > Great!  I'd be interested to know if you're still having HIGHPTE 
> > > > problems.  It may or may not have got fixed.
> > > > 
> > > 
> > > I just tried with CONFIG_HIGHPTE=y but that didn't seem to work:
> > > http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-30-xen331-linux-2.6.30-rc3-next-crash-with-highpte.txt
> > > 
> > > (XEN) mm.c:2006:d0 Bad type (saw 28000001 != exp e0000000) for mfn 6b0a6 (pfn 2c959)
> > > (XEN) mm.c:707:d0 Error getting mfn 6b0a6 (pfn 2c959) from L1 entry 000000006b0a6063 for dom0
> > > (XEN) mm.c:3640:d0 ptwr_emulate: could not get_page_from_l1e()
> > 
> > I thought I might have a poke at this, how do you go about reproducing
> > it? I've used your .config and it boots OK -- now I'm trying a kernbench
> > run since I think you mentioned compiling a kernel in domain 0 at one
> > point.
> > 
> 
> I can reproduce it every time like this:
> 
> - boot into pv_ops dom0 kernel
> - run "make bzImage && make modules"
> - wait for the kernel compilation to finish..
> - *crash*, before the compilation finishes, usually within 15-30mins
> 

Oh, and the crash happens only when dom0 kernel is built with CONFIG_HIGHPTE=y.
dom0 kernel compiled with CONFIG_HIGHPTE=n survives this test without crashing.

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-18 17:17                                         ` Pasi Kärkkäinen
@ 2009-05-18 17:39                                           ` Jeremy Fitzhardinge
  2009-05-18 17:50                                             ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-05-18 17:39 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Ian Campbell, Xen-devel

Pasi Kärkkäinen wrote:
> Oh, and the crash happens only when dom0 kernel is built with CONFIG_HIGHPTE=y.
> dom0 kernel compiled with CONFIG_HIGHPTE=n survives this test without crashing.

What distro are you using?  What's the gcc version?

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-18 17:39                                           ` Jeremy Fitzhardinge
@ 2009-05-18 17:50                                             ` Pasi Kärkkäinen
  2009-05-21  9:08                                               ` Ian Campbell
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-05-18 17:50 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Ian Campbell, Xen-devel

On Mon, May 18, 2009 at 10:39:23AM -0700, Jeremy Fitzhardinge wrote:
> Pasi Kärkkäinen wrote:
> >Oh, and the crash happens only when dom0 kernel is built with 
> >CONFIG_HIGHPTE=y.
> >dom0 kernel compiled with CONFIG_HIGHPTE=n survives this test without 
> >crashing.
> 
> What distro are you using?  What's the gcc version?
> 

I've seen that problem with Fedora 10 and Fedora 11 (rawhide). 

Fedora 11 is using:
gcc version 4.4.0 20090427 (Red Hat 4.4.0-3)

Fedora 10 is using:
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7)

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-18 17:06                                       ` Pasi Kärkkäinen
  2009-05-18 17:17                                         ` Pasi Kärkkäinen
@ 2009-05-18 19:09                                         ` Pasi Kärkkäinen
  1 sibling, 0 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-05-18 19:09 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Mon, May 18, 2009 at 08:06:26PM +0300, Pasi Kärkkäinen wrote:
> On Mon, May 18, 2009 at 03:57:07PM +0100, Ian Campbell wrote:
> > Hi Pasi,
> > 
> > On Thu, 2009-05-07 at 13:24 -0400, Pasi Kärkkäinen wrote:
> > > On Wed, May 06, 2009 at 02:51:59PM -0700, Jeremy Fitzhardinge wrote:
> > > > Great!  I'd be interested to know if you're still having HIGHPTE 
> > > > problems.  It may or may not have got fixed.
> > > > 
> > > 
> > > I just tried with CONFIG_HIGHPTE=y but that didn't seem to work:
> > > http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-bootlog-30-xen331-linux-2.6.30-rc3-next-crash-with-highpte.txt
> > > 
> > > (XEN) mm.c:2006:d0 Bad type (saw 28000001 != exp e0000000) for mfn 6b0a6 (pfn 2c959)
> > > (XEN) mm.c:707:d0 Error getting mfn 6b0a6 (pfn 2c959) from L1 entry 000000006b0a6063 for dom0
> > > (XEN) mm.c:3640:d0 ptwr_emulate: could not get_page_from_l1e()
> > 
> > I thought I might have a poke at this, how do you go about reproducing
> > it? I've used your .config and it boots OK -- now I'm trying a kernbench
> > run since I think you mentioned compiling a kernel in domain 0 at one
> > point.
> > 
> 
> I can reproduce it every time like this:
> 
> - boot into pv_ops dom0 kernel
> - run "make bzImage && make modules"
> - wait for the kernel compilation to finish..
> - *crash*, before the compilation finishes, usually within 15-30mins
> 
> > How much RAM does your host have? Are you running 32 or 64 bit
> > hypervisor? Which hypervisor version? From your .config I think your
> > dom0 kernel is 32 bit, right?
> > 
> 
> My host has 2GB of RAM.
> 
> Hypervisor is 32bit PAE, Fedora 11 Xen 3.3.1-11 rpms.
> My dom0 kernel is 32bit PAE aswell.
> 
> grub.conf:
> 
> kernel /xen-3.3.gz dom0_mem=1024M
> module /vmlinuz-2.6.30-rc3-tip root=/dev/sda1 ro
> module /boot/initrd.img-2.6.30-rc3-tip
> 

Hmm, that's the usual grub.conf I use, but for capturing the crash logs I
use:

kernel /xen-3.3.gz dom0_mem=1024M loglvl=all guest_loglvl=all com1=19200,8n1 console=com1
module /vmlinuz-2.6.30-rc3-tip root=/dev/sda1 ro console=hvc0 earlyprintk=xen
module /boot/initrd.img-2.6.30-rc3-tip

And Xen hypervisor is a debug build.

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-18 17:50                                             ` Pasi Kärkkäinen
@ 2009-05-21  9:08                                               ` Ian Campbell
  2009-05-22  8:06                                                 ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Ian Campbell @ 2009-05-21  9:08 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Mon, 2009-05-18 at 13:50 -0400, Pasi Kärkkäinen wrote:
[...]

Thanks for all the info Pasi, I've been trying to repro but not
successfully. I setup an environment similar to yours (32p h/v and
kernel, ~512M dom0 RAM, swap) and managed most of an allmodconfig build
before I ran out of RAM trying to link the final vmlinux.

I haven't yet tried different compiler versions, I'm using 4.1.2.

Is it always kswap<N> which has the issues? (subsequent traces seem to
be from the softlockup caused by the original failure, not repeated
failures). Could you perhaps try reproing with swap disabled?

Have you ever tried with a more recent hypervisor? I'm using
xen-unstable, I guess I should rollback to something based on the FC11
RPMs and try again.

Ian.

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-21  9:08                                               ` Ian Campbell
@ 2009-05-22  8:06                                                 ` Pasi Kärkkäinen
  2009-06-04 20:26                                                   ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-05-22  8:06 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Thu, May 21, 2009 at 10:08:35AM +0100, Ian Campbell wrote:
> On Mon, 2009-05-18 at 13:50 -0400, Pasi Kärkkäinen wrote:
> [...]
> 
> Thanks for all the info Pasi, I've been trying to repro but not
> successfully. I setup an environment similar to yours (32p h/v and
> kernel, ~512M dom0 RAM, swap) and managed most of an allmodconfig build
> before I ran out of RAM trying to link the final vmlinux.
> 

Thanks for looking into it :)

I have dom0_mem=1024M but dunno if that makes any difference..

> I haven't yet tried different compiler versions, I'm using 4.1.2.
> 

gcc version 4.4.0 20090427 (Red Hat 4.4.0-3) - Fedora 11
gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) - Fedora 10

Those were the versions I tried with..

> Is it always kswap<N> which has the issues? (subsequent traces seem to
> be from the softlockup caused by the original failure, not repeated
> failures). Could you perhaps try reproing with swap disabled?
> 

I went through a couple of the logs lately, and yeah, it seems to be kswapd..
I can try without swap.. late next week, I'm away until that..

> Have you ever tried with a more recent hypervisor? I'm using
> xen-unstable, I guess I should rollback to something based on the FC11
> RPMs and try again.
> 

Nope, I haven't tried newer hypervisor yet.. I can try that aswell.

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-05-22  8:06                                                 ` Pasi Kärkkäinen
@ 2009-06-04 20:26                                                   ` Pasi Kärkkäinen
  2009-06-04 20:30                                                     ` Pasi Kärkkäinen
  2009-06-05 10:20                                                     ` Ian Campbell
  0 siblings, 2 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-04 20:26 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Fri, May 22, 2009 at 11:06:56AM +0300, Pasi Kärkkäinen wrote:
> On Thu, May 21, 2009 at 10:08:35AM +0100, Ian Campbell wrote:
> > On Mon, 2009-05-18 at 13:50 -0400, Pasi Kärkkäinen wrote:
> > [...]
> > 
> > Thanks for all the info Pasi, I've been trying to repro but not
> > successfully. I setup an environment similar to yours (32p h/v and
> > kernel, ~512M dom0 RAM, swap) and managed most of an allmodconfig build
> > before I ran out of RAM trying to link the final vmlinux.
> > 
> 
> Thanks for looking into it :)
> 
> I have dom0_mem=1024M but dunno if that makes any difference..
> 
> > I haven't yet tried different compiler versions, I'm using 4.1.2.
> > 
> 
> gcc version 4.4.0 20090427 (Red Hat 4.4.0-3) - Fedora 11
> gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) - Fedora 10
> 
> Those were the versions I tried with..
> 
> > Is it always kswap<N> which has the issues? (subsequent traces seem to
> > be from the softlockup caused by the original failure, not repeated
> > failures). Could you perhaps try reproing with swap disabled?
> > 
> 
> I went through a couple of the logs lately, and yeah, it seems to be kswapd..
> I can try without swap.. late next week, I'm away until that..
> 

I had a HDD crash on my testbox, but now it's up again.. with a fresh
installation of Fedora 11 (rawhide). 

I tried a couple of times with the latest xen-tip/next tree, and pv_ops 
dom0 kernel built with CONFIG_HIGHMEM=y still crashes during the 
"make bzImage && make modules" test.

with swap enabled it takes around 30 minutes to crash.. without swap, the
crash happens in around 15 mins. 

Serial console logs here:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-01-with-highpte.txt
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-02-with-highpte-no-swap.txt

> > Have you ever tried with a more recent hypervisor? I'm using
> > xen-unstable, I guess I should rollback to something based on the FC11
> > RPMs and try again.
> > 
> 
> Nope, I haven't tried newer hypervisor yet.. I can try that aswell.
> 

I was using stock Xen 3.3.1-11 from Fedora 11.

What do you suggest me to try next? 

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-04 20:26                                                   ` Pasi Kärkkäinen
@ 2009-06-04 20:30                                                     ` Pasi Kärkkäinen
  2009-06-05 10:20                                                     ` Ian Campbell
  1 sibling, 0 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-04 20:30 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Thu, Jun 04, 2009 at 11:26:56PM +0300, Pasi Kärkkäinen wrote:
> On Fri, May 22, 2009 at 11:06:56AM +0300, Pasi Kärkkäinen wrote:
> > On Thu, May 21, 2009 at 10:08:35AM +0100, Ian Campbell wrote:
> > > On Mon, 2009-05-18 at 13:50 -0400, Pasi Kärkkäinen wrote:
> > > [...]
> > > 
> > > Thanks for all the info Pasi, I've been trying to repro but not
> > > successfully. I setup an environment similar to yours (32p h/v and
> > > kernel, ~512M dom0 RAM, swap) and managed most of an allmodconfig build
> > > before I ran out of RAM trying to link the final vmlinux.
> > > 
> > 
> > Thanks for looking into it :)
> > 
> > I have dom0_mem=1024M but dunno if that makes any difference..
> > 
> > > I haven't yet tried different compiler versions, I'm using 4.1.2.
> > > 
> > 
> > gcc version 4.4.0 20090427 (Red Hat 4.4.0-3) - Fedora 11
> > gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) - Fedora 10
> > 
> > Those were the versions I tried with..
> > 
> > > Is it always kswap<N> which has the issues? (subsequent traces seem to
> > > be from the softlockup caused by the original failure, not repeated
> > > failures). Could you perhaps try reproing with swap disabled?
> > > 
> > 
> > I went through a couple of the logs lately, and yeah, it seems to be kswapd..
> > I can try without swap.. late next week, I'm away until that..
> > 
> 
> I had a HDD crash on my testbox, but now it's up again.. with a fresh
> installation of Fedora 11 (rawhide). 
> 
> I tried a couple of times with the latest xen-tip/next tree, and pv_ops 
> dom0 kernel built with CONFIG_HIGHMEM=y still crashes during the 
> "make bzImage && make modules" test.
> 
> with swap enabled it takes around 30 minutes to crash.. without swap, the
> crash happens in around 15 mins. 
> 
> Serial console logs here:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-01-with-highpte.txt
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-02-with-highpte-no-swap.txt
> 

Oh, and it seems to be always kswapd<0> having issues..

-- Pasi

> > > Have you ever tried with a more recent hypervisor? I'm using
> > > xen-unstable, I guess I should rollback to something based on the FC11
> > > RPMs and try again.
> > > 
> > 
> > Nope, I haven't tried newer hypervisor yet.. I can try that aswell.
> > 
> 
> I was using stock Xen 3.3.1-11 from Fedora 11.
> 
> What do you suggest me to try next? 
> 
> -- Pasi
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-04 20:26                                                   ` Pasi Kärkkäinen
  2009-06-04 20:30                                                     ` Pasi Kärkkäinen
@ 2009-06-05 10:20                                                     ` Ian Campbell
  2009-06-05 11:23                                                       ` Pasi Kärkkäinen
  1 sibling, 1 reply; 118+ messages in thread
From: Ian Campbell @ 2009-06-05 10:20 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Thu, 2009-06-04 at 16:26 -0400, Pasi Kärkkäinen wrote:
> What do you suggest me to try next? 

I'm at a bit of a loss to be honest...

It's interesting that it's always kswapd0 even in the case with no swap
configured. Were you running with CONFIG_SWAP=n or just with the swap
device turned off?

Judging from the backtrace the sequence of events seems to be roughly:
kswapd<0> runs and calls balance_pgdat which calls shrink_zone who in
turn calls shrink_active_list if inactive_anon_is_low() (so I think we
are dealing with anon pages). shrink_active_list() then iterates over a
list of pages calling page_referenced() on each one. page_referenced()
eventually calls down to page_referenced_one() (presumably via
page_referenced_anon()) and eventually to page_check_address() which
walks the page table and attempts to map the PTE page. This goes via
pte_offset_map() to kmap_atomic_pte() then xen_kmap_atomic_pte(). Here
we check if the page is pinned and then attempt to map it, since we
_think_ the page is not pinned the mapping is writable. However at this
point Xen reports that the page really is pinned (28000001 => Page Type
1 == L1 PT) and we are trying to make a writable mapping (e0000000 =>
Page Type 7 == Writable) which is disallowed.

Do you know which line of xen_set_pte() the fault is occurring at? I
assume either "ptep->pte_high =" or "ptep->pte_low =".

So the question is -- how come we have a page which is pinned but this
fact is not recorded in the struct page information? It might be
interesting to know if the corresponding L3 PT is pinned. If the mm is
active then this should always be the case and I _think_ it would be a
bug for the L3 to be pinned but not all the which L1s which it contains.
Can you try this patch which tries to notice this situation and prints
some potentially interesting information, similarly on the fault it
dumps a little more info. Since I can't repro I've only tested that it
doesn't break normal use, I've not actually seen the debug trigger...

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index abe8e4b..483bad7 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -285,7 +285,7 @@ check_v8086_mode(struct pt_regs *regs, unsigned long address,
 		tsk->thread.screen_bitmap |= 1 << bit;
 }
 
-static void dump_pagetable(unsigned long address)
+void dump_pagetable(unsigned long address)
 {
 	__typeof__(pte_val(__pte(0))) page;
 
@@ -603,6 +603,10 @@ show_fault_oops(struct pt_regs *regs, unsigned long error_code,
 	printk_address(regs->ip, 1);
 
 	dump_pagetable(address);
+	printk(KERN_CRIT "Fixmap KM_PTE0 @ %#lx\n", fix_to_virt(KM_PTE0));
+	dump_pagetable(fix_to_virt(KM_PTE0));
+	printk(KERN_CRIT "Fixmap KM_PTE0 @ %#lx\n", fix_to_virt(KM_PTE1));
+	dump_pagetable(fix_to_virt(KM_PTE1));
 }
 
 static noinline void
diff --git a/include/xen/swiotlb.h b/include/xen/swiotlb.h
index f35183b..5db8659 100644
--- a/include/xen/swiotlb.h
+++ b/include/xen/swiotlb.h
@@ -5,6 +5,10 @@ extern void xen_swiotlb_fixup(void *buf, size_t size, unsigned long nslabs);
 extern phys_addr_t xen_bus_to_phys(dma_addr_t daddr);
 extern dma_addr_t xen_phys_to_bus(phys_addr_t paddr);
 extern int xen_range_needs_mapping(phys_addr_t phys, size_t size);
+#ifdef CONFIG_XEN_PCI
 extern int xen_wants_swiotlb(void);
+#else
+static inline int xen_wants_swiotlb(void) { return 0; }
+#endif
 
 #endif /* _XEN_SWIOTLB_H */
diff --git a/mm/rmap.c b/mm/rmap.c
index 1652166..ae5d5a0 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -267,6 +267,7 @@ unsigned long page_address_in_vma(struct page *page, struct vm_area_struct *vma)
 pte_t *page_check_address(struct page *page, struct mm_struct *mm,
 			  unsigned long address, spinlock_t **ptlp, int sync)
 {
+	struct page *pgd_page, *pte_page;
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
@@ -285,6 +286,22 @@ pte_t *page_check_address(struct page *page, struct mm_struct *mm,
 	if (!pmd_present(*pmd))
 		return NULL;
 
+	pgd_page = virt_to_page(mm->pgd);
+	pte_page = pmd_page(*pmd);
+
+	if (PagePinned(pgd_page) != PagePinned(pte_page)) {
+		extern void dump_pagetable(unsigned long address);
+		printk(KERN_CRIT "L4 at %p is %s contains L2 at %p which points at an L1 which is %s %s\n",
+		       pgd, PagePinned(pgd_page) ? "pinned" : "unpinned",
+		       pmd, PagePinned(pte_page) ? "pinned" : "unpinned",
+		       PageHighMem(pte_page) ? "highmem" : "lowmem");
+		printk(KERN_CRIT "address %#lx\n", address);
+		dump_pagetable(address);
+		printk(KERN_CRIT "Fixmap KM_PTE0 @ %#lx\n", fix_to_virt(KM_PTE0));
+		dump_pagetable(fix_to_virt(KM_PTE0));
+		printk(KERN_CRIT "Fixmap KM_PTE0 @ %#lx\n", fix_to_virt(KM_PTE1));
+		dump_pagetable(fix_to_virt(KM_PTE1));
+	}
 	pte = pte_offset_map(pmd, address);
 	/* Make a quick check before getting the lock */
 	if (!sync && !pte_present(*pte)) {



I'd guess that this would at least work around the issue, I doubt it's a
proper fix and it's going to shaft perf I suspect (not that highpte
won't be doing a pretty good job of that ;-)).

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index fefdeee..4c694e4 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1521,7 +1521,7 @@ static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
 {
 	pgprot_t prot = PAGE_KERNEL;
 
-	if (PagePinned(page))
+	if (1 || PagePinned(page))
 		prot = PAGE_KERNEL_RO;
 
 	if (0 && PageHighMem(page))


Ian.

^ permalink raw reply related	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-05 10:20                                                     ` Ian Campbell
@ 2009-06-05 11:23                                                       ` Pasi Kärkkäinen
  2009-06-05 11:37                                                         ` Ian Campbell
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-05 11:23 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Fri, Jun 05, 2009 at 11:20:17AM +0100, Ian Campbell wrote:
> On Thu, 2009-06-04 at 16:26 -0400, Pasi Kärkkäinen wrote:
> > What do you suggest me to try next? 
> 
> I'm at a bit of a loss to be honest...
> 
> It's interesting that it's always kswapd0 even in the case with no swap
> configured. Were you running with CONFIG_SWAP=n or just with the swap
> device turned off?
> 

I just ran "swapoff -a" before testing..

> Judging from the backtrace the sequence of events seems to be roughly:
> kswapd<0> runs and calls balance_pgdat which calls shrink_zone who in
> turn calls shrink_active_list if inactive_anon_is_low() (so I think we
> are dealing with anon pages). shrink_active_list() then iterates over a
> list of pages calling page_referenced() on each one. page_referenced()
> eventually calls down to page_referenced_one() (presumably via
> page_referenced_anon()) and eventually to page_check_address() which
> walks the page table and attempts to map the PTE page. This goes via
> pte_offset_map() to kmap_atomic_pte() then xen_kmap_atomic_pte(). Here
> we check if the page is pinned and then attempt to map it, since we
> _think_ the page is not pinned the mapping is writable. However at this
> point Xen reports that the page really is pinned (28000001 => Page Type
> 1 == L1 PT) and we are trying to make a writable mapping (e0000000 =>
> Page Type 7 == Writable) which is disallowed.
> 
> Do you know which line of xen_set_pte() the fault is occurring at? I
> assume either "ptep->pte_high =" or "ptep->pte_low =".
> 

I haven't looked for that.. I guess I should compile debug=y Xen build
again.

> So the question is -- how come we have a page which is pinned but this
> fact is not recorded in the struct page information? It might be
> interesting to know if the corresponding L3 PT is pinned. If the mm is
> active then this should always be the case and I _think_ it would be a
> bug for the L3 to be pinned but not all the which L1s which it contains.
> Can you try this patch which tries to notice this situation and prints
> some potentially interesting information, similarly on the fault it
> dumps a little more info. Since I can't repro I've only tested that it
> doesn't break normal use, I've not actually seen the debug trigger...
> 

OK. I'll try later today.. 

> 
> 
> I'd guess that this would at least work around the issue, I doubt it's a
> proper fix and it's going to shaft perf I suspect (not that highpte
> won't be doing a pretty good job of that ;-)).
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index fefdeee..4c694e4 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1521,7 +1521,7 @@ static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
>  {
>  	pgprot_t prot = PAGE_KERNEL;
>  
> -	if (PagePinned(page))
> +	if (1 || PagePinned(page))
>  		prot = PAGE_KERNEL_RO;
>  
>  	if (0 && PageHighMem(page))
> 

I'll try just the first debug-patch first.. so I won't apply this one yet.

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-05 11:23                                                       ` Pasi Kärkkäinen
@ 2009-06-05 11:37                                                         ` Ian Campbell
  2009-06-05 13:38                                                           ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Ian Campbell @ 2009-06-05 11:37 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Fri, 2009-06-05 at 07:23 -0400, Pasi Kärkkäinen wrote:
> > Do you know which line of xen_set_pte() the fault is occurring at? I
> > assume either "ptep->pte_high =" or "ptep->pte_low =".
> > 
> 
> I haven't looked for that.. I guess I should compile debug=y Xen build
> again.

xen_set_pte() is in the kernel rather than Xen so e.g. from
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-01-with-highpte.txt:
[...]
EIP: 0061:[<c0405d63>] EFLAGS: 00010296 CPU: 0
[...]

Can you use gdb to find out what 0xc0405d63 is, e.g. with "list
*0xc0405d63" and/or "disas 0xc0405d63"

Trying a debug=y Xen might be interesting as well though, it does more
checks etc so perhaps we can spot something odd earlier. Also all my
repro attempts were with debug=y so it would be interesting to know what
happens for you.

Ian.

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-05 11:37                                                         ` Ian Campbell
@ 2009-06-05 13:38                                                           ` Pasi Kärkkäinen
  2009-06-05 13:52                                                             ` Ian Campbell
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-05 13:38 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Fri, Jun 05, 2009 at 11:37:44AM +0000, Ian Campbell wrote:
> On Fri, 2009-06-05 at 07:23 -0400, Pasi Kärkkäinen wrote:
> > > Do you know which line of xen_set_pte() the fault is occurring at? I
> > > assume either "ptep->pte_high =" or "ptep->pte_low =".
> > > 
> > 
> > I haven't looked for that.. I guess I should compile debug=y Xen build
> > again.
> 
> xen_set_pte() is in the kernel rather than Xen so e.g. from
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-01-with-highpte.txt:
> [...]
> EIP: 0061:[<c0405d63>] EFLAGS: 00010296 CPU: 0
> [...]
> 
> Can you use gdb to find out what 0xc0405d63 is, e.g. with "list
> *0xc0405d63" and/or "disas 0xc0405d63"
> 

(gdb) list *0xc0405d63
0xc0405d63 is in xen_set_pte (arch/x86/xen/mmu.c:683).
678             ADD_STATS(pte_update_batched, paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU);
679
680     #ifdef CONFIG_X86_PAE
681             ptep->pte_high = pte.pte_high;
682             smp_wmb();
683             ptep->pte_low = pte.pte_low;
684     #else
685             *ptep = pte;
686     #endif
687     }

Dump of assembler code for function xen_set_pte:
0xc0405cda <xen_set_pte+0>:     push   %ebp
0xc0405cdb <xen_set_pte+1>:     mov    %esp,%ebp
0xc0405cdd <xen_set_pte+3>:     push   %edi
0xc0405cde <xen_set_pte+4>:     push   %esi
0xc0405cdf <xen_set_pte+5>:     mov    %ecx,%esi
0xc0405ce1 <xen_set_pte+7>:     push   %ebx
0xc0405ce2 <xen_set_pte+8>:     mov    %eax,%ebx
0xc0405ce4 <xen_set_pte+10>:    mov    %edx,%eax
0xc0405ce6 <xen_set_pte+12>:    sub    $0x4,%esp
0xc0405ce9 <xen_set_pte+15>:    and    $0x400,%eax
0xc0405cee <xen_set_pte+20>:    je     0xc0405cff <check_zero>
0xc0405cf0 <xen_set_iomap_pte+0>:       mov    %ebx,%eax
0xc0405cf2 <xen_set_iomap_pte+2>:       push   $0x7ff1
0xc0405cf7 <xen_set_iomap_pte+7>:       call   0xc0405c35 <xen_set_domain_pte>
0xc0405cfc <xen_set_iomap_pte+12>:      pop    %ebx
0xc0405cfd <xen_set_iomap_pte+13>:      jmp    0xc0405d65 <xen_set_pte+139>
0xc0405cff <check_zero+0>:      cmpb   $0x0,0xc08f334c
0xc0405d06 <check_zero+7>:      je     0xc0405d1b <xen_set_pte+65>
0xc0405d08 <__constant_c_and_count_memset+0>:   mov    $0x33,%ecx
0xc0405d0d <__constant_c_and_count_memset+5>:   mov    $0xc08f3280,%edi
0xc0405d12 <__constant_c_and_count_memset+10>:  rep stos %eax,%es:(%edi)
0xc0405d14 <check_zero+21>:     movb   $0x0,0xc08f334c
0xc0405d1b <xen_set_pte+65>:    incl   0xc08f32a4
0xc0405d21 <check_zero+0>:      cmpb   $0x0,0xc08f334c
0xc0405d28 <check_zero+7>:      je     0xc0405d3f <xen_set_pte+101>
0xc0405d2a <__constant_c_and_count_memset+0>:   mov    $0x33,%ecx
0xc0405d2f <__constant_c_and_count_memset+5>:   mov    $0xc08f3280,%edi
0xc0405d34 <__constant_c_and_count_memset+10>:  xor    %eax,%eax
0xc0405d36 <__constant_c_and_count_memset+12>:  rep stos %eax,%es:(%edi)
0xc0405d38 <check_zero+23>:     movb   $0x0,0xc08f334c
0xc0405d3f <xen_set_pte+101>:   mov    0xc08f32ac,%edi
0xc0405d45 <xen_set_pte+107>:   mov    %edx,-0x10(%ebp)
0xc0405d48 <xen_set_pte+110>:   call   0xc0422f2a <paravirt_get_lazy_mode>
0xc0405d4d <xen_set_pte+115>:   dec    %eax
0xc0405d4e <xen_set_pte+116>:   sete   %al
0xc0405d51 <xen_set_pte+119>:   movzbl %al,%eax
0xc0405d54 <xen_set_pte+122>:   lea    (%eax,%edi,1),%edi
0xc0405d57 <xen_set_pte+125>:   mov    %edi,0xc08f32ac
0xc0405d5d <xen_set_pte+131>:   mov    %esi,0x4(%ebx)
0xc0405d60 <xen_set_pte+134>:   mov    -0x10(%ebp),%edx
0xc0405d63 <xen_set_pte+137>:   mov    %edx,(%ebx)
0xc0405d65 <xen_set_pte+139>:   lea    -0xc(%ebp),%esp
0xc0405d68 <xen_set_pte+142>:   pop    %ebx
0xc0405d69 <xen_set_pte+143>:   pop    %esi
0xc0405d6a <xen_set_pte+144>:   pop    %edi
0xc0405d6b <xen_set_pte+145>:   pop    %ebp
0xc0405d6c <xen_set_pte+146>:   ret
End of assembler dump.
(gdb) 


> Trying a debug=y Xen might be interesting as well though, it does more
> checks etc so perhaps we can spot something odd earlier. Also all my
> repro attempts were with debug=y so it would be interesting to know what
> happens for you.
> 

I'll build debug=y Xen hypervisor, and also new CONFIG_HIGHPTE=y kernel with
the debug patch you sent. 

Btw. I just realized you said earlier that you tested with dom0_mem=512M ..
that doesn't give you any highmem.. ? Maybe that's why you aren't seeing the
problem..

I have dom0_mem=1024M

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-05 13:38                                                           ` Pasi Kärkkäinen
@ 2009-06-05 13:52                                                             ` Ian Campbell
  2009-06-05 15:41                                                               ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Ian Campbell @ 2009-06-05 13:52 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Fri, 2009-06-05 at 09:38 -0400, Pasi Kärkkäinen wrote:
> (gdb) list *0xc0405d63
> 0xc0405d63 is in xen_set_pte (arch/x86/xen/mmu.c:683).
> 678             ADD_STATS(pte_update_batched, paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU);
> 679
> 680     #ifdef CONFIG_X86_PAE
> 681             ptep->pte_high = pte.pte_high;
> 682             smp_wmb();
> 683             ptep->pte_low = pte.pte_low;
> 684     #else
> 685             *ptep = pte;
> 686     #endif
> 687     }

Good that makes most sense. 

> Btw. I just realized you said earlier that you tested with dom0_mem=512M ..
> that doesn't give you any highmem.. ? Maybe that's why you aren't seeing the
> problem..
> 
> I have dom0_mem=1024M

I'm pretty sure I also tried larger amounts, both dom0_mem=1024M and the
default which is ALL-128M or something. I'll try again to make sure
though.

Thanks,
Ian.

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-05 13:52                                                             ` Ian Campbell
@ 2009-06-05 15:41                                                               ` Pasi Kärkkäinen
  2009-06-05 16:05                                                                 ` Ian Campbell
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-05 15:41 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Fri, Jun 05, 2009 at 02:52:59PM +0100, Ian Campbell wrote:
> On Fri, 2009-06-05 at 09:38 -0400, Pasi Kärkkäinen wrote:
> > (gdb) list *0xc0405d63
> > 0xc0405d63 is in xen_set_pte (arch/x86/xen/mmu.c:683).
> > 678             ADD_STATS(pte_update_batched, paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU);
> > 679
> > 680     #ifdef CONFIG_X86_PAE
> > 681             ptep->pte_high = pte.pte_high;
> > 682             smp_wmb();
> > 683             ptep->pte_low = pte.pte_low;
> > 684     #else
> > 685             *ptep = pte;
> > 686     #endif
> > 687     }
> 
> Good that makes most sense. 
> 

I rebuilt my Fedora 11 Xen 3.3.1-11 src.rpm with "debug=y verbose=y crash_debug=y".

And I rebuilt my pv_ops dom0 kernel (CONFIG_HIGHPTE=y) with your
debugging patch applied. (Some hunks to swiotlb.h failed, because the code
was already there.. with different newlines or so).

Serial console log:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-03-with-highpte-no-swap-with-debug.txt

(XEN) mm.c:2006:d0 Bad type (saw 28000001 != exp e0000000) for mfn 683f4 (pfn 29a0b)
(XEN) mm.c:707:d0 Error getting mfn 683f4 (pfn 29a0b) from L1 entry 00000000683f4063 for dom0
(XEN) mm.c:3640:d0 ptwr_emulate: could not get_page_from_l1e()
BUG: unable to handle kernel paging request at c0207c80
IP: [<c0405d63>] xen_set_pte+0x89/0x93
*pdpt = 000000003c8ef001 
Fixmap KM_PTE0 @ 0xf57f0000
*pdpt = 000000003c8ef001 
Fixmap KM_PTE0 @ 0xf57ee000
*pdpt = 000000003c8ef001 
Oops: 0003 [#1] SMP 


(gdb) list *0xc0405d63
0xc0405d63 is in xen_set_pte (arch/x86/xen/mmu.c:683).
678             ADD_STATS(pte_update_batched, paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU);
679
680     #ifdef CONFIG_X86_PAE
681             ptep->pte_high = pte.pte_high;
682             smp_wmb();
683             ptep->pte_low = pte.pte_low;
684     #else
685             *ptep = pte;
686     #endif
687     }


(gdb) disas 0xc0405d63
Dump of assembler code for function xen_set_pte:
0xc0405cda <xen_set_pte+0>:     push   %ebp
0xc0405cdb <xen_set_pte+1>:     mov    %esp,%ebp
0xc0405cdd <xen_set_pte+3>:     push   %edi
0xc0405cde <xen_set_pte+4>:     push   %esi
0xc0405cdf <xen_set_pte+5>:     mov    %ecx,%esi
0xc0405ce1 <xen_set_pte+7>:     push   %ebx
0xc0405ce2 <xen_set_pte+8>:     mov    %eax,%ebx
0xc0405ce4 <xen_set_pte+10>:    mov    %edx,%eax
0xc0405ce6 <xen_set_pte+12>:    sub    $0x4,%esp
0xc0405ce9 <xen_set_pte+15>:    and    $0x400,%eax
0xc0405cee <xen_set_pte+20>:    je     0xc0405cff <check_zero>
0xc0405cf0 <xen_set_iomap_pte+0>:       mov    %ebx,%eax
0xc0405cf2 <xen_set_iomap_pte+2>:       push   $0x7ff1
0xc0405cf7 <xen_set_iomap_pte+7>:       call   0xc0405c35 <xen_set_domain_pte>
0xc0405cfc <xen_set_iomap_pte+12>:      pop    %ebx
0xc0405cfd <xen_set_iomap_pte+13>:      jmp    0xc0405d65 <xen_set_pte+139>
0xc0405cff <check_zero+0>:      cmpb   $0x0,0xc08f334c
0xc0405d06 <check_zero+7>:      je     0xc0405d1b <xen_set_pte+65>
0xc0405d08 <__constant_c_and_count_memset+0>:   mov    $0x33,%ecx
0xc0405d0d <__constant_c_and_count_memset+5>:   mov    $0xc08f3280,%edi
0xc0405d12 <__constant_c_and_count_memset+10>:  rep stos %eax,%es:(%edi)
0xc0405d14 <check_zero+21>:     movb   $0x0,0xc08f334c
0xc0405d1b <xen_set_pte+65>:    incl   0xc08f32a4
0xc0405d21 <check_zero+0>:      cmpb   $0x0,0xc08f334c
0xc0405d28 <check_zero+7>:      je     0xc0405d3f <xen_set_pte+101>
0xc0405d2a <__constant_c_and_count_memset+0>:   mov    $0x33,%ecx
0xc0405d2f <__constant_c_and_count_memset+5>:   mov    $0xc08f3280,%edi
0xc0405d34 <__constant_c_and_count_memset+10>:  xor    %eax,%eax
0xc0405d36 <__constant_c_and_count_memset+12>:  rep stos %eax,%es:(%edi)
0xc0405d38 <check_zero+23>:     movb   $0x0,0xc08f334c
0xc0405d3f <xen_set_pte+101>:   mov    0xc08f32ac,%edi
0xc0405d45 <xen_set_pte+107>:   mov    %edx,-0x10(%ebp)
0xc0405d48 <xen_set_pte+110>:   call   0xc0422f2a <paravirt_get_lazy_mode>
0xc0405d4d <xen_set_pte+115>:   dec    %eax
0xc0405d4e <xen_set_pte+116>:   sete   %al
0xc0405d51 <xen_set_pte+119>:   movzbl %al,%eax
0xc0405d54 <xen_set_pte+122>:   lea    (%eax,%edi,1),%edi
0xc0405d57 <xen_set_pte+125>:   mov    %edi,0xc08f32ac
0xc0405d5d <xen_set_pte+131>:   mov    %esi,0x4(%ebx)
0xc0405d60 <xen_set_pte+134>:   mov    -0x10(%ebp),%edx
0xc0405d63 <xen_set_pte+137>:   mov    %edx,(%ebx)
0xc0405d65 <xen_set_pte+139>:   lea    -0xc(%ebp),%esp
0xc0405d68 <xen_set_pte+142>:   pop    %ebx
0xc0405d69 <xen_set_pte+143>:   pop    %esi
0xc0405d6a <xen_set_pte+144>:   pop    %edi
0xc0405d6b <xen_set_pte+145>:   pop    %ebp
0xc0405d6c <xen_set_pte+146>:   ret    
End of assembler dump.
(gdb) 

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-05 15:41                                                               ` Pasi Kärkkäinen
@ 2009-06-05 16:05                                                                 ` Ian Campbell
  2009-06-05 16:12                                                                   ` Ian Campbell
  0 siblings, 1 reply; 118+ messages in thread
From: Ian Campbell @ 2009-06-05 16:05 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Fri, 2009-06-05 at 11:41 -0400, Pasi Kärkkäinen wrote:
> On Fri, Jun 05, 2009 at 02:52:59PM +0100, Ian Campbell wrote:
> > On Fri, 2009-06-05 at 09:38 -0400, Pasi Kärkkäinen wrote:
> > > (gdb) list *0xc0405d63
> > > 0xc0405d63 is in xen_set_pte (arch/x86/xen/mmu.c:683).
> > > 678             ADD_STATS(pte_update_batched, paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU);
> > > 679
> > > 680     #ifdef CONFIG_X86_PAE
> > > 681             ptep->pte_high = pte.pte_high;
> > > 682             smp_wmb();
> > > 683             ptep->pte_low = pte.pte_low;
> > > 684     #else
> > > 685             *ptep = pte;
> > > 686     #endif
> > > 687     }
> > 
> > Good that makes most sense. 
> > 
> 
> I rebuilt my Fedora 11 Xen 3.3.1-11 src.rpm with "debug=y verbose=y crash_debug=y".
> 
> And I rebuilt my pv_ops dom0 kernel (CONFIG_HIGHPTE=y) with your
> debugging patch applied. (Some hunks to swiotlb.h failed, because the code
> was already there.. with different newlines or so).

I think I included those changes to swiotlb.h by mistake anyway.

> Serial console log:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-03-with-highpte-no-swap-with-debug.txt
> 
> (XEN) mm.c:2006:d0 Bad type (saw 28000001 != exp e0000000) for mfn 683f4 (pfn 29a0b)
> (XEN) mm.c:707:d0 Error getting mfn 683f4 (pfn 29a0b) from L1 entry 00000000683f4063 for dom0
> (XEN) mm.c:3640:d0 ptwr_emulate: could not get_page_from_l1e()
> BUG: unable to handle kernel paging request at c0207c80
> IP: [<c0405d63>] xen_set_pte+0x89/0x93
> *pdpt = 000000003c8ef001 
> Fixmap KM_PTE0 @ 0xf57f0000
> *pdpt = 000000003c8ef001 
> Fixmap KM_PTE0 @ 0xf57ee000
> *pdpt = 000000003c8ef001 
> Oops: 0003 [#1] SMP 

Hmm, this isn't too useful because dump_pagetable() doesn't work for Xen
guests -- it goes direct at the pagetables instead of going via the
normal accessors so it misses the MFN<->PFN translations.

I had some patches to unify the 32 and 64 bit versions of dump page
table at one point, since the 64 bit version does the right thing. I'll
see if I can find or reproduce them.

Ian.

> 
> 
> (gdb) list *0xc0405d63
> 0xc0405d63 is in xen_set_pte (arch/x86/xen/mmu.c:683).
> 678             ADD_STATS(pte_update_batched, paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU);
> 679
> 680     #ifdef CONFIG_X86_PAE
> 681             ptep->pte_high = pte.pte_high;
> 682             smp_wmb();
> 683             ptep->pte_low = pte.pte_low;
> 684     #else
> 685             *ptep = pte;
> 686     #endif
> 687     }
> 
> 
> (gdb) disas 0xc0405d63
> Dump of assembler code for function xen_set_pte:
> 0xc0405cda <xen_set_pte+0>:     push   %ebp
> 0xc0405cdb <xen_set_pte+1>:     mov    %esp,%ebp
> 0xc0405cdd <xen_set_pte+3>:     push   %edi
> 0xc0405cde <xen_set_pte+4>:     push   %esi
> 0xc0405cdf <xen_set_pte+5>:     mov    %ecx,%esi
> 0xc0405ce1 <xen_set_pte+7>:     push   %ebx
> 0xc0405ce2 <xen_set_pte+8>:     mov    %eax,%ebx
> 0xc0405ce4 <xen_set_pte+10>:    mov    %edx,%eax
> 0xc0405ce6 <xen_set_pte+12>:    sub    $0x4,%esp
> 0xc0405ce9 <xen_set_pte+15>:    and    $0x400,%eax
> 0xc0405cee <xen_set_pte+20>:    je     0xc0405cff <check_zero>
> 0xc0405cf0 <xen_set_iomap_pte+0>:       mov    %ebx,%eax
> 0xc0405cf2 <xen_set_iomap_pte+2>:       push   $0x7ff1
> 0xc0405cf7 <xen_set_iomap_pte+7>:       call   0xc0405c35 <xen_set_domain_pte>
> 0xc0405cfc <xen_set_iomap_pte+12>:      pop    %ebx
> 0xc0405cfd <xen_set_iomap_pte+13>:      jmp    0xc0405d65 <xen_set_pte+139>
> 0xc0405cff <check_zero+0>:      cmpb   $0x0,0xc08f334c
> 0xc0405d06 <check_zero+7>:      je     0xc0405d1b <xen_set_pte+65>
> 0xc0405d08 <__constant_c_and_count_memset+0>:   mov    $0x33,%ecx
> 0xc0405d0d <__constant_c_and_count_memset+5>:   mov    $0xc08f3280,%edi
> 0xc0405d12 <__constant_c_and_count_memset+10>:  rep stos %eax,%es:(%edi)
> 0xc0405d14 <check_zero+21>:     movb   $0x0,0xc08f334c
> 0xc0405d1b <xen_set_pte+65>:    incl   0xc08f32a4
> 0xc0405d21 <check_zero+0>:      cmpb   $0x0,0xc08f334c
> 0xc0405d28 <check_zero+7>:      je     0xc0405d3f <xen_set_pte+101>
> 0xc0405d2a <__constant_c_and_count_memset+0>:   mov    $0x33,%ecx
> 0xc0405d2f <__constant_c_and_count_memset+5>:   mov    $0xc08f3280,%edi
> 0xc0405d34 <__constant_c_and_count_memset+10>:  xor    %eax,%eax
> 0xc0405d36 <__constant_c_and_count_memset+12>:  rep stos %eax,%es:(%edi)
> 0xc0405d38 <check_zero+23>:     movb   $0x0,0xc08f334c
> 0xc0405d3f <xen_set_pte+101>:   mov    0xc08f32ac,%edi
> 0xc0405d45 <xen_set_pte+107>:   mov    %edx,-0x10(%ebp)
> 0xc0405d48 <xen_set_pte+110>:   call   0xc0422f2a <paravirt_get_lazy_mode>
> 0xc0405d4d <xen_set_pte+115>:   dec    %eax
> 0xc0405d4e <xen_set_pte+116>:   sete   %al
> 0xc0405d51 <xen_set_pte+119>:   movzbl %al,%eax
> 0xc0405d54 <xen_set_pte+122>:   lea    (%eax,%edi,1),%edi
> 0xc0405d57 <xen_set_pte+125>:   mov    %edi,0xc08f32ac
> 0xc0405d5d <xen_set_pte+131>:   mov    %esi,0x4(%ebx)
> 0xc0405d60 <xen_set_pte+134>:   mov    -0x10(%ebp),%edx
> 0xc0405d63 <xen_set_pte+137>:   mov    %edx,(%ebx)
> 0xc0405d65 <xen_set_pte+139>:   lea    -0xc(%ebp),%esp
> 0xc0405d68 <xen_set_pte+142>:   pop    %ebx
> 0xc0405d69 <xen_set_pte+143>:   pop    %esi
> 0xc0405d6a <xen_set_pte+144>:   pop    %edi
> 0xc0405d6b <xen_set_pte+145>:   pop    %ebp
> 0xc0405d6c <xen_set_pte+146>:   ret    
> End of assembler dump.
> (gdb) 
> 
> -- Pasi
> 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-05 16:05                                                                 ` Ian Campbell
@ 2009-06-05 16:12                                                                   ` Ian Campbell
  2009-06-05 18:19                                                                     ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Ian Campbell @ 2009-06-05 16:12 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Fri, 2009-06-05 at 12:05 -0400, Ian Campbell wrote:
> 
> I had some patches to unify the 32 and 64 bit versions of dump page
> table at one point, since the 64 bit version does the right thing.
> I'll see if I can find or reproduce them.

Couldn't find them but please try this:

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index abe8e4b..e455d56 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -285,46 +285,12 @@ check_v8086_mode(struct pt_regs *regs, unsigned long address,
 		tsk->thread.screen_bitmap |= 1 << bit;
 }
 
-static void dump_pagetable(unsigned long address)
-{
-	__typeof__(pte_val(__pte(0))) page;
-
-	page = read_cr3();
-	page = ((__typeof__(page) *) __va(page))[address >> PGDIR_SHIFT];
-
 #ifdef CONFIG_X86_PAE
-	printk("*pdpt = %016Lx ", page);
-	if ((page >> PAGE_SHIFT) < max_low_pfn
-	    && page & _PAGE_PRESENT) {
-		page &= PAGE_MASK;
-		page = ((__typeof__(page) *) __va(page))[(address >> PMD_SHIFT)
-							& (PTRS_PER_PMD - 1)];
-		printk(KERN_CONT "*pde = %016Lx ", page);
-		page &= ~_PAGE_NX;
-	}
+#define FMTPTE "ll"
 #else
-	printk("*pde = %08lx ", page);
+#define FMTPTE "l"
 #endif
 
-	/*
-	 * We must not directly access the pte in the highpte
-	 * case if the page table is located in highmem.
-	 * And let's rather not kmap-atomic the pte, just in case
-	 * it's allocated already:
-	 */
-	if ((page >> PAGE_SHIFT) < max_low_pfn
-	    && (page & _PAGE_PRESENT)
-	    && !(page & _PAGE_PSE)) {
-
-		page &= PAGE_MASK;
-		page = ((__typeof__(page) *) __va(page))[(address >> PAGE_SHIFT)
-							& (PTRS_PER_PTE - 1)];
-		printk("*pte = %0*Lx ", sizeof(page)*2, (u64)page);
-	}
-
-	printk("\n");
-}
-
 #else /* CONFIG_X86_64: */
 
 void vmalloc_sync_all(void)
@@ -440,6 +406,10 @@ check_v8086_mode(struct pt_regs *regs, unsigned long address,
 {
 }
 
+#define FMTPTE "ll"
+
+#endif /* CONFIG_X86_64 */
+
 static int bad_address(void *p)
 {
 	unsigned long dummy;
@@ -447,7 +417,7 @@ static int bad_address(void *p)
 	return probe_kernel_address((unsigned long *)p, dummy);
 }
 
-static void dump_pagetable(unsigned long address)
+void dump_pagetable(unsigned long address)
 {
 	pgd_t *pgd;
 	pud_t *pud;
@@ -462,7 +432,7 @@ static void dump_pagetable(unsigned long address)
 	if (bad_address(pgd))
 		goto bad;
 
-	printk("PGD %lx ", pgd_val(*pgd));
+	printk("PGD %"FMTPTE"x ", pgd_val(*pgd));
 
 	if (!pgd_present(*pgd))
 		goto out;
@@ -471,7 +441,7 @@ static void dump_pagetable(unsigned long address)
 	if (bad_address(pud))
 		goto bad;
 
-	printk("PUD %lx ", pud_val(*pud));
+	printk("PUD %"FMTPTE"x ", pud_val(*pud));
 	if (!pud_present(*pud) || pud_large(*pud))
 		goto out;
 
@@ -479,7 +449,7 @@ static void dump_pagetable(unsigned long address)
 	if (bad_address(pmd))
 		goto bad;
 
-	printk("PMD %lx ", pmd_val(*pmd));
+	printk("PMD %"FMTPTE"x ", pmd_val(*pmd));
 	if (!pmd_present(*pmd) || pmd_large(*pmd))
 		goto out;
 
@@ -487,7 +457,7 @@ static void dump_pagetable(unsigned long address)
 	if (bad_address(pte))
 		goto bad;
 
-	printk("PTE %lx", pte_val(*pte));
+	printk("PTE %"FMTPTE"x", pte_val(*pte));
 out:
 	printk("\n");
 	return;
@@ -495,8 +465,6 @@ bad:
 	printk("BAD\n");
 }
 
-#endif /* CONFIG_X86_64 */
-
 /*
  * Workaround for K8 erratum #93 & buggy BIOS.
  *
@@ -603,6 +571,10 @@ show_fault_oops(struct pt_regs *regs, unsigned long error_code,
 	printk_address(regs->ip, 1);
 
 	dump_pagetable(address);
+	printk(KERN_CRIT "Fixmap KM_PTE0 @ %#lx\n", fix_to_virt(KM_PTE0));
+	dump_pagetable(fix_to_virt(KM_PTE0));
+	printk(KERN_CRIT "Fixmap KM_PTE1 @ %#lx\n", fix_to_virt(KM_PTE1));
+	dump_pagetable(fix_to_virt(KM_PTE1));
 }
 
 static noinline void
diff --git a/init/main.c b/init/main.c
index 33ce929..fee067e 100644
--- a/init/main.c
+++ b/init/main.c
@@ -807,6 +807,7 @@ static void run_init_process(char *init_filename)
 static noinline int init_post(void)
 	__releases(kernel_lock)
 {
+	extern void dump_pagetable(unsigned long address);
 	/* need to finish all async __init code before freeing the memory */
 	async_synchronize_full();
 	free_initmem();
@@ -815,6 +816,9 @@ static noinline int init_post(void)
 	system_state = SYSTEM_RUNNING;
 	numa_default_policy();
 
+	printk(KERN_CRIT "test dump_pagetable on %#lx\n", (unsigned long)__builtin_return_address(0));
+	dump_pagetable((unsigned long)__builtin_return_address(0));
+
 	if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
 		printk(KERN_WARNING "Warning: unable to open an initial console.\n");
 
diff --git a/mm/rmap.c b/mm/rmap.c
index 1652166..ae5d5a0 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -267,6 +267,7 @@ unsigned long page_address_in_vma(struct page *page, struct vm_area_struct *vma)
 pte_t *page_check_address(struct page *page, struct mm_struct *mm,
 			  unsigned long address, spinlock_t **ptlp, int sync)
 {
+	struct page *pgd_page, *pte_page;
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
@@ -285,6 +286,22 @@ pte_t *page_check_address(struct page *page, struct mm_struct *mm,
 	if (!pmd_present(*pmd))
 		return NULL;
 
+	pgd_page = virt_to_page(mm->pgd);
+	pte_page = pmd_page(*pmd);
+
+	if (PagePinned(pgd_page) != PagePinned(pte_page)) {
+		extern void dump_pagetable(unsigned long address);
+		printk(KERN_CRIT "L4 at %p is %s contains L2 at %p which points at an L1 which is %s %s\n",
+		       pgd, PagePinned(pgd_page) ? "pinned" : "unpinned",
+		       pmd, PagePinned(pte_page) ? "pinned" : "unpinned",
+		       PageHighMem(pte_page) ? "highmem" : "lowmem");
+		printk(KERN_CRIT "address %#lx\n", address);
+		dump_pagetable(address);
+		printk(KERN_CRIT "Fixmap KM_PTE0 @ %#lx\n", fix_to_virt(KM_PTE0));
+		dump_pagetable(fix_to_virt(KM_PTE0));
+		printk(KERN_CRIT "Fixmap KM_PTE0 @ %#lx\n", fix_to_virt(KM_PTE1));
+		dump_pagetable(fix_to_virt(KM_PTE1));
+	}
 	pte = pte_offset_map(pmd, address);
 	/* Make a quick check before getting the lock */
 	if (!sync && !pte_present(*pte)) {

^ permalink raw reply related	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-05 16:12                                                                   ` Ian Campbell
@ 2009-06-05 18:19                                                                     ` Pasi Kärkkäinen
  2009-06-08 15:45                                                                       ` Ian Campbell
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-05 18:19 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Fri, Jun 05, 2009 at 05:12:33PM +0100, Ian Campbell wrote:
> On Fri, 2009-06-05 at 12:05 -0400, Ian Campbell wrote:
> > 
> > I had some patches to unify the 32 and 64 bit versions of dump page
> > table at one point, since the 64 bit version does the right thing.
> > I'll see if I can find or reproduce them.
> 
> Couldn't find them but please try this:
> 

I had some problems applying the patch until I figured out it was supposed
to be applied to a clean tree.. hopefully "git checkout file" restores (or
resets) the file to it's original form and removes any local changes.

Here goes again:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-04-with-highpte-no-swap-with-debug2.txt


L4 at e1822000 is pinned contains L2 at e1977228 which points at an L1 which is unpinned low mem address 0x8bf8000
Fixmap KM_PTE0 @ 0xf57f0000
Fixmap KM_PTE0 @ 0xf57ee000
(XEN) mm.c:2006:d0 Bad type (saw 28000001 != exp e0000000) for mfn 62991 (pfn 2406e)
(XEN) mm.c:707:d0 Error getting mfn 62991 (pfn 2406e) from L1 entry 0000000062991063 for dom0
(XEN) mm.c:3640:d0 ptwr_emulate: could not get_page_from_l1e()
BUG: unable to handle kernel paging request at c0207d58
IP: [<c0405d63>] xen_set_pte+0x89/0x93
PGD 8ef001 PUD 8ef001 PMD 1268067 PTE 207061
Fixmap KM_PTE0 @ 0xf57f0000
PGD 8ef001 PUD 8ef001 PMD 207067 PTE 0
Fixmap KM_PTE1 @ 0xf57ee000
PGD 8ef001 PUD 8ef001 PMD 207067 PTE 0
Oops: 0003 [#1] SMP 


list *0x(gdb) list *0xc0405d63
0xc0405d63 is in xen_set_pte (arch/x86/xen/mmu.c:683).
678             ADD_STATS(pte_update_batched, paravirt_get_lazy_mode() == PARAVIRT_LAZY_MMU);
679
680     #ifdef CONFIG_X86_PAE
681             ptep->pte_high = pte.pte_high;
682             smp_wmb();
683             ptep->pte_low = pte.pte_low;
684     #else
685             *ptep = pte;
686     #endif
687     }


(gdb) disas 0xc0405d63
Dump of assembler code for function xen_set_pte:
0xc0405cda <xen_set_pte+0>:     push   %ebp
0xc0405cdb <xen_set_pte+1>:     mov    %esp,%ebp
0xc0405cdd <xen_set_pte+3>:     push   %edi
0xc0405cde <xen_set_pte+4>:     push   %esi
0xc0405cdf <xen_set_pte+5>:     mov    %ecx,%esi
0xc0405ce1 <xen_set_pte+7>:     push   %ebx
0xc0405ce2 <xen_set_pte+8>:     mov    %eax,%ebx
0xc0405ce4 <xen_set_pte+10>:    mov    %edx,%eax
0xc0405ce6 <xen_set_pte+12>:    sub    $0x4,%esp
0xc0405ce9 <xen_set_pte+15>:    and    $0x400,%eax
0xc0405cee <xen_set_pte+20>:    je     0xc0405cff <check_zero>
0xc0405cf0 <xen_set_iomap_pte+0>:       mov    %ebx,%eax
0xc0405cf2 <xen_set_iomap_pte+2>:       push   $0x7ff1
0xc0405cf7 <xen_set_iomap_pte+7>:       call   0xc0405c35 <xen_set_domain_pte>
0xc0405cfc <xen_set_iomap_pte+12>:      pop    %ebx
0xc0405cfd <xen_set_iomap_pte+13>:      jmp    0xc0405d65 <xen_set_pte+139>
0xc0405cff <check_zero+0>:      cmpb   $0x0,0xc08f334c
0xc0405d06 <check_zero+7>:      je     0xc0405d1b <xen_set_pte+65>
0xc0405d08 <__constant_c_and_count_memset+0>:   mov    $0x33,%ecx
0xc0405d0d <__constant_c_and_count_memset+5>:   mov    $0xc08f3280,%edi
0xc0405d12 <__constant_c_and_count_memset+10>:  rep stos %eax,%es:(%edi)
0xc0405d14 <check_zero+21>:     movb   $0x0,0xc08f334c
0xc0405d1b <xen_set_pte+65>:    incl   0xc08f32a4
0xc0405d21 <check_zero+0>:      cmpb   $0x0,0xc08f334c
0xc0405d28 <check_zero+7>:      je     0xc0405d3f <xen_set_pte+101>
0xc0405d2a <__constant_c_and_count_memset+0>:   mov    $0x33,%ecx
0xc0405d2f <__constant_c_and_count_memset+5>:   mov    $0xc08f3280,%edi
0xc0405d34 <__constant_c_and_count_memset+10>:  xor    %eax,%eax
0xc0405d36 <__constant_c_and_count_memset+12>:  rep stos %eax,%es:(%edi)
0xc0405d38 <check_zero+23>:     movb   $0x0,0xc08f334c
0xc0405d3f <xen_set_pte+101>:   mov    0xc08f32ac,%edi
0xc0405d45 <xen_set_pte+107>:   mov    %edx,-0x10(%ebp)
0xc0405d48 <xen_set_pte+110>:   call   0xc0422f2a <paravirt_get_lazy_mode>
0xc0405d4d <xen_set_pte+115>:   dec    %eax
0xc0405d4e <xen_set_pte+116>:   sete   %al
0xc0405d51 <xen_set_pte+119>:   movzbl %al,%eax
0xc0405d54 <xen_set_pte+122>:   lea    (%eax,%edi,1),%edi
0xc0405d57 <xen_set_pte+125>:   mov    %edi,0xc08f32ac
0xc0405d5d <xen_set_pte+131>:   mov    %esi,0x4(%ebx)
0xc0405d60 <xen_set_pte+134>:   mov    -0x10(%ebp),%edx
0xc0405d63 <xen_set_pte+137>:   mov    %edx,(%ebx)
0xc0405d65 <xen_set_pte+139>:   lea    -0xc(%ebp),%esp
0xc0405d68 <xen_set_pte+142>:   pop    %ebx
0xc0405d69 <xen_set_pte+143>:   pop    %esi
0xc0405d6a <xen_set_pte+144>:   pop    %edi
0xc0405d6b <xen_set_pte+145>:   pop    %ebp
0xc0405d6c <xen_set_pte+146>:   ret    
End of assembler dump.
(gdb) 


-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-05 18:19                                                                     ` Pasi Kärkkäinen
@ 2009-06-08 15:45                                                                       ` Ian Campbell
  2009-06-08 16:00                                                                         ` Ian Campbell
  0 siblings, 1 reply; 118+ messages in thread
From: Ian Campbell @ 2009-06-08 15:45 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Fri, 2009-06-05 at 14:19 -0400, Pasi Kärkkäinen wrote:
> On Fri, Jun 05, 2009 at 05:12:33PM +0100, Ian Campbell wrote:
> > On Fri, 2009-06-05 at 12:05 -0400, Ian Campbell wrote:
> > > 
> > > I had some patches to unify the 32 and 64 bit versions of dump
> page
> > > table at one point, since the 64 bit version does the right thing.
> > > I'll see if I can find or reproduce them.
> > 
> > Couldn't find them but please try this:
> > 
> 
> I had some problems applying the patch until I figured out it was
> supposed
> to be applied to a clean tree.. hopefully "git checkout file" restores
> (or
> resets) the file to it's original form and removes any local changes.

Should work I guess, I usually use "git reset --hard" to undo any local
mods.

> 
> Here goes again:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-04-with-highpte-no-swap-with-debug2.txt
> 
> 
> L4 at e1822000 is pinned contains L2 at e1977228 which points at an L1
> which is unpinned low mem address 0x8bf8000

OK so I think that is interesting. A pinned L4 referencing an unpinned
L1 isn't supposed to happen, I don't think (Jeremy?).

The patch at the end (applies to a clean tree again) walks the lowmem
region of every L4 to ensure that every L1 page is pinned just before
pinning the L4. I hope this will catch the L1 in the act.

> PGD 8ef001 PUD 8ef001 PMD 1268067 PTE 207061

This just tells us that the PT which maps the PTE we were trying to
write is mapped R/O, which is not as interesting as I thought it would
be.

> Fixmap KM_PTE0 @ 0xf57f0000
> PGD 8ef001 PUD 8ef001 PMD 207067 PTE 0
> Fixmap KM_PTE1 @ 0xf57ee000
> PGD 8ef001 PUD 8ef001 PMD 207067 PTE 0

So these guys are not at fault, although we are in the middle of filling
in KM_PTE0, I think.

I've just had another go reproing this with a xen-3.3-testing.hg
hypervisor (both 32 and 64 bit) with a 32 bit kernel and dom0_mem=1024M.
No luck...

Ian.

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index f9b252c..538590a 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -285,46 +285,12 @@ check_v8086_mode(struct pt_regs *regs, unsigned long address,
 		tsk->thread.screen_bitmap |= 1 << bit;
 }
 
-static void dump_pagetable(unsigned long address)
-{
-	__typeof__(pte_val(__pte(0))) page;
-
-	page = read_cr3();
-	page = ((__typeof__(page) *) __va(page))[address >> PGDIR_SHIFT];
-
 #ifdef CONFIG_X86_PAE
-	printk("*pdpt = %016Lx ", page);
-	if ((page >> PAGE_SHIFT) < max_low_pfn
-	    && page & _PAGE_PRESENT) {
-		page &= PAGE_MASK;
-		page = ((__typeof__(page) *) __va(page))[(address >> PMD_SHIFT)
-							& (PTRS_PER_PMD - 1)];
-		printk(KERN_CONT "*pde = %016Lx ", page);
-		page &= ~_PAGE_NX;
-	}
+#define FMTPTE "ll"
 #else
-	printk("*pde = %08lx ", page);
+#define FMTPTE "l"
 #endif
 
-	/*
-	 * We must not directly access the pte in the highpte
-	 * case if the page table is located in highmem.
-	 * And let's rather not kmap-atomic the pte, just in case
-	 * it's allocated already:
-	 */
-	if ((page >> PAGE_SHIFT) < max_low_pfn
-	    && (page & _PAGE_PRESENT)
-	    && !(page & _PAGE_PSE)) {
-
-		page &= PAGE_MASK;
-		page = ((__typeof__(page) *) __va(page))[(address >> PAGE_SHIFT)
-							& (PTRS_PER_PTE - 1)];
-		printk("*pte = %0*Lx ", sizeof(page)*2, (u64)page);
-	}
-
-	printk("\n");
-}
-
 #else /* CONFIG_X86_64: */
 
 void vmalloc_sync_all(void)
@@ -440,6 +406,10 @@ check_v8086_mode(struct pt_regs *regs, unsigned long address,
 {
 }
 
+#define FMTPTE "ll"
+
+#endif /* CONFIG_X86_64 */
+
 static int bad_address(void *p)
 {
 	unsigned long dummy;
@@ -447,7 +417,7 @@ static int bad_address(void *p)
 	return probe_kernel_address((unsigned long *)p, dummy);
 }
 
-static void dump_pagetable(unsigned long address)
+void dump_pagetable(unsigned long address)
 {
 	pgd_t *pgd;
 	pud_t *pud;
@@ -462,7 +432,7 @@ static void dump_pagetable(unsigned long address)
 	if (bad_address(pgd))
 		goto bad;
 
-	printk("PGD %lx ", pgd_val(*pgd));
+	printk("PGD %"FMTPTE"x ", pgd_val(*pgd));
 
 	if (!pgd_present(*pgd))
 		goto out;
@@ -471,7 +441,7 @@ static void dump_pagetable(unsigned long address)
 	if (bad_address(pud))
 		goto bad;
 
-	printk("PUD %lx ", pud_val(*pud));
+	printk("PUD %"FMTPTE"x ", pud_val(*pud));
 	if (!pud_present(*pud) || pud_large(*pud))
 		goto out;
 
@@ -479,7 +449,7 @@ static void dump_pagetable(unsigned long address)
 	if (bad_address(pmd))
 		goto bad;
 
-	printk("PMD %lx ", pmd_val(*pmd));
+	printk("PMD %"FMTPTE"x ", pmd_val(*pmd));
 	if (!pmd_present(*pmd) || pmd_large(*pmd))
 		goto out;
 
@@ -487,7 +457,7 @@ static void dump_pagetable(unsigned long address)
 	if (bad_address(pte))
 		goto bad;
 
-	printk("PTE %lx", pte_val(*pte));
+	printk("PTE %"FMTPTE"x", pte_val(*pte));
 out:
 	printk("\n");
 	return;
@@ -495,8 +465,6 @@ bad:
 	printk("BAD\n");
 }
 
-#endif /* CONFIG_X86_64 */
-
 /*
  * Workaround for K8 erratum #93 & buggy BIOS.
  *
@@ -598,6 +566,10 @@ show_fault_oops(struct pt_regs *regs, unsigned long error_code,
 	printk_address(regs->ip, 1);
 
 	dump_pagetable(address);
+	printk(KERN_CRIT "Fixmap KM_PTE0 @ %#lx\n", fix_to_virt(KM_PTE0));
+	dump_pagetable(fix_to_virt(KM_PTE0));
+	printk(KERN_CRIT "Fixmap KM_PTE1 @ %#lx\n", fix_to_virt(KM_PTE1));
+	dump_pagetable(fix_to_virt(KM_PTE1));
 }
 
 static noinline void
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 1729178..2c427d3 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1015,13 +1015,34 @@ static int xen_pin_page(struct mm_struct *mm, struct page *page,
 	return flush;
 }
 
+static int xen_check_l1_pinned(pte_t *pte, unsigned long s, unsigned long e, struct mm_walk *walk)
+{
+	extern void dump_pagetable(unsigned long address);
+	struct page *pte_page = virt_to_page(pte);
+
+	if (!PagePinned(pte_page)) {
+		printk(KERN_CRIT "PTE @ %p is an L1 page %p covering %#lx-%#lx which is not pinned\n", pte, pte_page, s, e);
+		dump_pagetable((unsigned long)pte);
+		BUG();
+	}
+
+	return 0;
+}
+
 /* This is called just after a mm has been created, but it has not
    been used yet.  We need to make sure that its pagetable is all
    read-only, and can be pinned. */
 static void __xen_pgd_pin(struct mm_struct *mm, pgd_t *pgd)
 {
+	struct mm_walk xen_pin_walk = {
+		.pte_entry = &xen_check_l1_pinned,
+		.mm = mm,
+	};
+
 	vm_unmap_aliases();
 
+	walk_page_range(0xc0000000, FIXADDR_TOP, &xen_pin_walk);
+
 	xen_mc_batch();
 
 	if (__xen_pgd_walk(mm, pgd, xen_pin_page, USER_LIMIT)) {
diff --git a/init/main.c b/init/main.c
index 33ce929..baf4300 100644
--- a/init/main.c
+++ b/init/main.c
@@ -74,6 +74,8 @@
 #include <asm/sections.h>
 #include <asm/cacheflush.h>
 
+#include <asm/xen/page.h>
+
 #ifdef CONFIG_X86_LOCAL_APIC
 #include <asm/smp.h>
 #endif
@@ -815,6 +817,54 @@ static noinline int init_post(void)
 	system_state = SYSTEM_RUNNING;
 	numa_default_policy();
 
+	{
+		extern void dump_pagetable(unsigned long address);
+		struct page *pgd_page, *pte_page;
+		pgd_t *pgd;
+		pud_t *pud;
+		pmd_t *pmd;
+		phys_addr_t pte_phys;
+		unsigned long address = 0xc08ce011UL;//(unsigned long) __builtin_return_address(0);
+
+		pgd = pgd_offset(&init_mm, address);
+		if (!pgd_present(*pgd))
+			goto skip;
+
+		pud = pud_offset(pgd, address);
+		if (!pud_present(*pud))
+			goto skip;
+
+		pmd = pmd_offset(pud, address);
+		if (!pmd_present(*pmd))
+			goto skip;
+
+		pgd_page = virt_to_page(init_mm.pgd);
+		pte_page = pmd_page(*pmd);
+
+		pte_phys = page_to_phys(pte_page) + pte_index(address);
+		printk(KERN_CRIT "Test debug infrastructure on address %#lx:\n", address);
+		printk(KERN_CRIT "L4 at V:%p/P:%#llx/M:%#llx is %s and contains L2 at V:%p/P:%#llx/M:%#llx = %#llx "
+		       "which points to an L1 P:%#llx/M:%#llx which is %s %s\n",
+		       pgd, virt_to_phys(pgd), virt_to_machine(pgd).maddr,
+		       PagePinned(pgd_page) ? "pinned" : "unpinned",
+		       pmd, virt_to_phys(pmd), virt_to_machine(pmd).maddr,
+		       pmd_val(*pmd),
+		       pte_phys, phys_to_machine(XPADDR(pte_phys)).maddr,
+		       PagePinned(pte_page) ? "pinned" : "unpinned",
+		       PageHighMem(pte_page) ? "highmem" : "lowmem");
+		printk(KERN_CRIT "faulting address %#lx\n", address);
+		dump_pagetable(address);
+		if (!PageHighMem(pte_page)) {
+			printk(KERN_CRIT "lowmem mapping of L1 @ P:%#llx is at V:%p\n", pte_phys, phys_to_virt(page_to_phys(pte_page)));
+			dump_pagetable((unsigned long)phys_to_virt(page_to_phys(pte_page)));
+		}
+		printk(KERN_CRIT "Fixmap KM_PTE0 @ %#lx\n", fix_to_virt(KM_PTE0));
+		dump_pagetable(fix_to_virt(KM_PTE0));
+		printk(KERN_CRIT "Fixmap KM_PTE1 @ %#lx\n", fix_to_virt(KM_PTE1));
+		dump_pagetable(fix_to_virt(KM_PTE1));
+	}
+	skip:
+
 	if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
 		printk(KERN_WARNING "Warning: unable to open an initial console.\n");
 
diff --git a/mm/rmap.c b/mm/rmap.c
index 1652166..ced5650 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -52,6 +52,9 @@
 #include <linux/migrate.h>
 
 #include <asm/tlbflush.h>
+#include <asm/io.h>
+
+#include <asm/xen/page.h>
 
 #include "internal.h"
 
@@ -267,6 +270,7 @@ unsigned long page_address_in_vma(struct page *page, struct vm_area_struct *vma)
 pte_t *page_check_address(struct page *page, struct mm_struct *mm,
 			  unsigned long address, spinlock_t **ptlp, int sync)
 {
+	struct page *pgd_page, *pte_page;
 	pgd_t *pgd;
 	pud_t *pud;
 	pmd_t *pmd;
@@ -285,6 +289,32 @@ pte_t *page_check_address(struct page *page, struct mm_struct *mm,
 	if (!pmd_present(*pmd))
 		return NULL;
 
+	pgd_page = virt_to_page(mm->pgd);
+	pte_page = pmd_page(*pmd);
+
+	if (PagePinned(pgd_page) != PagePinned(pte_page)) {
+		extern void dump_pagetable(unsigned long address);
+		phys_addr_t pte_phys = page_to_phys(pte_page) + pte_index(address);
+		printk(KERN_CRIT "L4 at V:%p/P:%#llx/M:%#llx is %s and contains L2 at V:%p/P:%#llx/M:%#llx = %#llx "
+		       "which points to an L1 P:%#llx/M:%#llx which is %s %s\n",
+		       pgd, virt_to_phys(pgd), virt_to_machine(pgd).maddr,
+		       PagePinned(pgd_page) ? "pinned" : "unpinned",
+		       pmd, virt_to_phys(pmd), virt_to_machine(pmd).maddr,
+		       pmd_val(*pmd),
+		       pte_phys, phys_to_machine(XPADDR(pte_phys)).maddr,
+		       PagePinned(pte_page) ? "pinned" : "unpinned",
+		       PageHighMem(pte_page) ? "highmem" : "lowmem");
+		printk(KERN_CRIT "faulting address %#lx\n", address);
+		dump_pagetable(address);
+		if (!PageHighMem(pte_page)) {
+			printk(KERN_CRIT "lowmem mapping of L1 @ P:%#llx is at V:%p\n", pte_phys, phys_to_virt(page_to_phys(pte_page)));
+			dump_pagetable((unsigned long)phys_to_virt(page_to_phys(pte_page)));
+		}
+		printk(KERN_CRIT "Fixmap KM_PTE0 @ %#lx\n", fix_to_virt(KM_PTE0));
+		dump_pagetable(fix_to_virt(KM_PTE0));
+		printk(KERN_CRIT "Fixmap KM_PTE1 @ %#lx\n", fix_to_virt(KM_PTE1));
+		dump_pagetable(fix_to_virt(KM_PTE1));
+	}
 	pte = pte_offset_map(pmd, address);
 	/* Make a quick check before getting the lock */
 	if (!sync && !pte_present(*pte)) {

^ permalink raw reply related	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-08 15:45                                                                       ` Ian Campbell
@ 2009-06-08 16:00                                                                         ` Ian Campbell
  2009-06-08 16:13                                                                           ` Pasi Kärkkäinen
  2009-06-09 17:28                                                                           ` Jeremy Fitzhardinge
  0 siblings, 2 replies; 118+ messages in thread
From: Ian Campbell @ 2009-06-08 16:00 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Mon, 2009-06-08 at 11:45 -0400, Ian Campbell wrote:
> 
> > L4 at e1822000 is pinned contains L2 at e1977228 which points at an
> L1
> > which is unpinned low mem address 0x8bf8000
> 
> OK so I think that is interesting. A pinned L4 referencing an unpinned
> L1 isn't supposed to happen, I don't think (Jeremy?).

Interesting:

        pte_t *page_check_address(struct page *page, struct mm_struct *mm,
        [...]
        	pte = pte_offset_map(pmd, address); /* A */
        	/* Make a quick check before getting the lock */
        	if (!sync && !pte_present(*pte)) {
        		pte_unmap(pte);
        		return NULL;
        	}
        
        	ptl = pte_lockptr(mm, pmd);
        	spin_lock(ptl);
        [...]
        
So at point A we make a new mapping of a PTE without yet holding the
corresponding PTE lock and this is precisely the point at which things
start to go wrong for us... (coincidence? I think not ;-))

I wonder how this interacts with the logic in
arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
the (deferred) pin multicall to occur? Hmm, no this is about the
PagePinned flag on the struct page which is out of date WRT the actual
pinned status as Xen sees it -- we update the PagePinned flag early in
xen_pin_page() long before Xen the pin hypercall so this window is the
other way round to what would be needed to trigger this bug.

On the other hand xen_unpin_page() looks like it sets up something
roughly like what we need for this issue to trigger.

Pasi in additional to my other mad hack could you try this:

diff --git a/mm/Kconfig b/mm/Kconfig
index a5b7781..5663548 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -166,6 +166,7 @@ config SPLIT_PTLOCK_CPUS
 	int
 	default "4096" if ARM && !CPU_CACHE_VIPT
 	default "4096" if PARISC && !PA20
+	default "4096" if XEN
 	default "4"
 
 #


Ian.

^ permalink raw reply related	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-08 16:00                                                                         ` Ian Campbell
@ 2009-06-08 16:13                                                                           ` Pasi Kärkkäinen
  2009-06-08 16:17                                                                             ` Ian Campbell
  2009-06-09 17:28                                                                           ` Jeremy Fitzhardinge
  1 sibling, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-08 16:13 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Mon, Jun 08, 2009 at 05:00:58PM +0100, Ian Campbell wrote:
> On Mon, 2009-06-08 at 11:45 -0400, Ian Campbell wrote:
> > 
> > > L4 at e1822000 is pinned contains L2 at e1977228 which points at an
> > L1
> > > which is unpinned low mem address 0x8bf8000
> > 
> > OK so I think that is interesting. A pinned L4 referencing an unpinned
> > L1 isn't supposed to happen, I don't think (Jeremy?).
> 
> Interesting:
> 
>         pte_t *page_check_address(struct page *page, struct mm_struct *mm,
>         [...]
>         	pte = pte_offset_map(pmd, address); /* A */
>         	/* Make a quick check before getting the lock */
>         	if (!sync && !pte_present(*pte)) {
>         		pte_unmap(pte);
>         		return NULL;
>         	}
>         
>         	ptl = pte_lockptr(mm, pmd);
>         	spin_lock(ptl);
>         [...]
>         
> So at point A we make a new mapping of a PTE without yet holding the
> corresponding PTE lock and this is precisely the point at which things
> start to go wrong for us... (coincidence? I think not ;-))
> 
> I wonder how this interacts with the logic in
> arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
> the (deferred) pin multicall to occur? Hmm, no this is about the
> PagePinned flag on the struct page which is out of date WRT the actual
> pinned status as Xen sees it -- we update the PagePinned flag early in
> xen_pin_page() long before Xen the pin hypercall so this window is the
> other way round to what would be needed to trigger this bug.
> 
> On the other hand xen_unpin_page() looks like it sets up something
> roughly like what we need for this issue to trigger.
> 
> Pasi in additional to my other mad hack could you try this:
> 

Ok.. do you want me to try first without this patch? Or should I cancel my
kernel compilation and apply this aswell? :)

-- Pasi

> diff --git a/mm/Kconfig b/mm/Kconfig
> index a5b7781..5663548 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -166,6 +166,7 @@ config SPLIT_PTLOCK_CPUS
>  	int
>  	default "4096" if ARM && !CPU_CACHE_VIPT
>  	default "4096" if PARISC && !PA20
> +	default "4096" if XEN
>  	default "4"
>  
>  #
> 
> 
> Ian.
> 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-08 16:13                                                                           ` Pasi Kärkkäinen
@ 2009-06-08 16:17                                                                             ` Ian Campbell
  2009-06-08 16:21                                                                               ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Ian Campbell @ 2009-06-08 16:17 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Mon, 2009-06-08 at 12:13 -0400, Pasi Kärkkäinen wrote:
> On Mon, Jun 08, 2009 at 05:00:58PM +0100, Ian Campbell wrote:
> > On Mon, 2009-06-08 at 11:45 -0400, Ian Campbell wrote:
> > > 
> > > > L4 at e1822000 is pinned contains L2 at e1977228 which points at an
> > > L1
> > > > which is unpinned low mem address 0x8bf8000
> > > 
> > > OK so I think that is interesting. A pinned L4 referencing an unpinned
> > > L1 isn't supposed to happen, I don't think (Jeremy?).
> > 
> > Interesting:
> > 
> >         pte_t *page_check_address(struct page *page, struct mm_struct *mm,
> >         [...]
> >         	pte = pte_offset_map(pmd, address); /* A */
> >         	/* Make a quick check before getting the lock */
> >         	if (!sync && !pte_present(*pte)) {
> >         		pte_unmap(pte);
> >         		return NULL;
> >         	}
> >         
> >         	ptl = pte_lockptr(mm, pmd);
> >         	spin_lock(ptl);
> >         [...]
> >         
> > So at point A we make a new mapping of a PTE without yet holding the
> > corresponding PTE lock and this is precisely the point at which things
> > start to go wrong for us... (coincidence? I think not ;-))
> > 
> > I wonder how this interacts with the logic in
> > arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
> > the (deferred) pin multicall to occur? Hmm, no this is about the
> > PagePinned flag on the struct page which is out of date WRT the actual
> > pinned status as Xen sees it -- we update the PagePinned flag early in
> > xen_pin_page() long before Xen the pin hypercall so this window is the
> > other way round to what would be needed to trigger this bug.
> > 
> > On the other hand xen_unpin_page() looks like it sets up something
> > roughly like what we need for this issue to trigger.
> > 
> > Pasi in additional to my other mad hack could you try this:
> > 
> 
> Ok.. do you want me to try first without this patch? Or should I cancel my
> kernel compilation and apply this aswell? :)

Can you try the first patch first then add this one please.

Ian.

> 
> -- Pasi
> 
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index a5b7781..5663548 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -166,6 +166,7 @@ config SPLIT_PTLOCK_CPUS
> >  	int
> >  	default "4096" if ARM && !CPU_CACHE_VIPT
> >  	default "4096" if PARISC && !PA20
> > +	default "4096" if XEN
> >  	default "4"
> >  
> >  #
> > 
> > 
> > Ian.
> > 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-08 16:17                                                                             ` Ian Campbell
@ 2009-06-08 16:21                                                                               ` Pasi Kärkkäinen
  2009-06-08 17:05                                                                                 ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-08 16:21 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Mon, Jun 08, 2009 at 05:17:45PM +0100, Ian Campbell wrote:
> On Mon, 2009-06-08 at 12:13 -0400, Pasi Kärkkäinen wrote:
> > On Mon, Jun 08, 2009 at 05:00:58PM +0100, Ian Campbell wrote:
> > > On Mon, 2009-06-08 at 11:45 -0400, Ian Campbell wrote:
> > > > 
> > > > > L4 at e1822000 is pinned contains L2 at e1977228 which points at an
> > > > L1
> > > > > which is unpinned low mem address 0x8bf8000
> > > > 
> > > > OK so I think that is interesting. A pinned L4 referencing an unpinned
> > > > L1 isn't supposed to happen, I don't think (Jeremy?).
> > > 
> > > Interesting:
> > > 
> > >         pte_t *page_check_address(struct page *page, struct mm_struct *mm,
> > >         [...]
> > >         	pte = pte_offset_map(pmd, address); /* A */
> > >         	/* Make a quick check before getting the lock */
> > >         	if (!sync && !pte_present(*pte)) {
> > >         		pte_unmap(pte);
> > >         		return NULL;
> > >         	}
> > >         
> > >         	ptl = pte_lockptr(mm, pmd);
> > >         	spin_lock(ptl);
> > >         [...]
> > >         
> > > So at point A we make a new mapping of a PTE without yet holding the
> > > corresponding PTE lock and this is precisely the point at which things
> > > start to go wrong for us... (coincidence? I think not ;-))
> > > 
> > > I wonder how this interacts with the logic in
> > > arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
> > > the (deferred) pin multicall to occur? Hmm, no this is about the
> > > PagePinned flag on the struct page which is out of date WRT the actual
> > > pinned status as Xen sees it -- we update the PagePinned flag early in
> > > xen_pin_page() long before Xen the pin hypercall so this window is the
> > > other way round to what would be needed to trigger this bug.
> > > 
> > > On the other hand xen_unpin_page() looks like it sets up something
> > > roughly like what we need for this issue to trigger.
> > > 
> > > Pasi in additional to my other mad hack could you try this:
> > > 
> > 
> > Ok.. do you want me to try first without this patch? Or should I cancel my
> > kernel compilation and apply this aswell? :)
> 
> Can you try the first patch first then add this one please.
> 

Ok. Will do.

I was already starting to feel like 'maybe my hardware is broken' but now that
code looks like it might be an actual bug :)

Let's see.

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-08 16:21                                                                               ` Pasi Kärkkäinen
@ 2009-06-08 17:05                                                                                 ` Pasi Kärkkäinen
  2009-06-08 19:11                                                                                   ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-08 17:05 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Mon, Jun 08, 2009 at 07:21:46PM +0300, Pasi Kärkkäinen wrote:
> On Mon, Jun 08, 2009 at 05:17:45PM +0100, Ian Campbell wrote:
> > On Mon, 2009-06-08 at 12:13 -0400, Pasi Kärkkäinen wrote:
> > > On Mon, Jun 08, 2009 at 05:00:58PM +0100, Ian Campbell wrote:
> > > > On Mon, 2009-06-08 at 11:45 -0400, Ian Campbell wrote:
> > > > > 
> > > > > > L4 at e1822000 is pinned contains L2 at e1977228 which points at an
> > > > > L1
> > > > > > which is unpinned low mem address 0x8bf8000
> > > > > 
> > > > > OK so I think that is interesting. A pinned L4 referencing an unpinned
> > > > > L1 isn't supposed to happen, I don't think (Jeremy?).
> > > > 
> > > > Interesting:
> > > > 
> > > >         pte_t *page_check_address(struct page *page, struct mm_struct *mm,
> > > >         [...]
> > > >         	pte = pte_offset_map(pmd, address); /* A */
> > > >         	/* Make a quick check before getting the lock */
> > > >         	if (!sync && !pte_present(*pte)) {
> > > >         		pte_unmap(pte);
> > > >         		return NULL;
> > > >         	}
> > > >         
> > > >         	ptl = pte_lockptr(mm, pmd);
> > > >         	spin_lock(ptl);
> > > >         [...]
> > > >         
> > > > So at point A we make a new mapping of a PTE without yet holding the
> > > > corresponding PTE lock and this is precisely the point at which things
> > > > start to go wrong for us... (coincidence? I think not ;-))
> > > > 
> > > > I wonder how this interacts with the logic in
> > > > arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
> > > > the (deferred) pin multicall to occur? Hmm, no this is about the
> > > > PagePinned flag on the struct page which is out of date WRT the actual
> > > > pinned status as Xen sees it -- we update the PagePinned flag early in
> > > > xen_pin_page() long before Xen the pin hypercall so this window is the
> > > > other way round to what would be needed to trigger this bug.
> > > > 
> > > > On the other hand xen_unpin_page() looks like it sets up something
> > > > roughly like what we need for this issue to trigger.
> > > > 
> > > > Pasi in additional to my other mad hack could you try this:
> > > > 
> > > 
> > > Ok.. do you want me to try first without this patch? Or should I cancel my
> > > kernel compilation and apply this aswell? :)
> > 
> > Can you try the first patch first then add this one please.
> > 
> 
> Ok. Will do.
> 
> I was already starting to feel like 'maybe my hardware is broken' but now that
> code looks like it might be an actual bug :)
> 
> Let's see.
> 

Crash with only the first patch applied:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-05-with-highpte-no-swap-with-debug3.txt

Now I'll try with the second one included aswell..

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-08 17:05                                                                                 ` Pasi Kärkkäinen
@ 2009-06-08 19:11                                                                                   ` Pasi Kärkkäinen
  2009-06-09 14:53                                                                                     ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-08 19:11 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Mon, Jun 08, 2009 at 08:05:43PM +0300, Pasi Kärkkäinen wrote:
> On Mon, Jun 08, 2009 at 07:21:46PM +0300, Pasi Kärkkäinen wrote:
> > On Mon, Jun 08, 2009 at 05:17:45PM +0100, Ian Campbell wrote:
> > > On Mon, 2009-06-08 at 12:13 -0400, Pasi Kärkkäinen wrote:
> > > > On Mon, Jun 08, 2009 at 05:00:58PM +0100, Ian Campbell wrote:
> > > > > On Mon, 2009-06-08 at 11:45 -0400, Ian Campbell wrote:
> > > > > > 
> > > > > > > L4 at e1822000 is pinned contains L2 at e1977228 which points at an
> > > > > > L1
> > > > > > > which is unpinned low mem address 0x8bf8000
> > > > > > 
> > > > > > OK so I think that is interesting. A pinned L4 referencing an unpinned
> > > > > > L1 isn't supposed to happen, I don't think (Jeremy?).
> > > > > 
> > > > > Interesting:
> > > > > 
> > > > >         pte_t *page_check_address(struct page *page, struct mm_struct *mm,
> > > > >         [...]
> > > > >         	pte = pte_offset_map(pmd, address); /* A */
> > > > >         	/* Make a quick check before getting the lock */
> > > > >         	if (!sync && !pte_present(*pte)) {
> > > > >         		pte_unmap(pte);
> > > > >         		return NULL;
> > > > >         	}
> > > > >         
> > > > >         	ptl = pte_lockptr(mm, pmd);
> > > > >         	spin_lock(ptl);
> > > > >         [...]
> > > > >         
> > > > > So at point A we make a new mapping of a PTE without yet holding the
> > > > > corresponding PTE lock and this is precisely the point at which things
> > > > > start to go wrong for us... (coincidence? I think not ;-))
> > > > > 
> > > > > I wonder how this interacts with the logic in
> > > > > arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
> > > > > the (deferred) pin multicall to occur? Hmm, no this is about the
> > > > > PagePinned flag on the struct page which is out of date WRT the actual
> > > > > pinned status as Xen sees it -- we update the PagePinned flag early in
> > > > > xen_pin_page() long before Xen the pin hypercall so this window is the
> > > > > other way round to what would be needed to trigger this bug.
> > > > > 
> > > > > On the other hand xen_unpin_page() looks like it sets up something
> > > > > roughly like what we need for this issue to trigger.
> > > > > 
> > > > > Pasi in additional to my other mad hack could you try this:
> > > > > 
> > > > 
> > > > Ok.. do you want me to try first without this patch? Or should I cancel my
> > > > kernel compilation and apply this aswell? :)
> > > 
> > > Can you try the first patch first then add this one please.
> > > 
> > 
> > Ok. Will do.
> > 
> > I was already starting to feel like 'maybe my hardware is broken' but now that
> > code looks like it might be an actual bug :)
> > 
> > Let's see.
> > 
> 
> Crash with only the first patch applied:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-05-with-highpte-no-swap-with-debug3.txt
> 
> Now I'll try with the second one included aswell..
> 

And here's one with the second patch applied aswell:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-06-with-highpte-no-swap-with-debug4.txt

Seems to be different.. Xen is not complaining anymore..

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-08 19:11                                                                                   ` Pasi Kärkkäinen
@ 2009-06-09 14:53                                                                                     ` Pasi Kärkkäinen
  2009-06-09 15:37                                                                                       ` Ian Campbell
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-09 14:53 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Mon, Jun 08, 2009 at 10:11:41PM +0300, Pasi Kärkkäinen wrote:
> On Mon, Jun 08, 2009 at 08:05:43PM +0300, Pasi Kärkkäinen wrote:
> > On Mon, Jun 08, 2009 at 07:21:46PM +0300, Pasi Kärkkäinen wrote:
> > > On Mon, Jun 08, 2009 at 05:17:45PM +0100, Ian Campbell wrote:
> > > > On Mon, 2009-06-08 at 12:13 -0400, Pasi Kärkkäinen wrote:
> > > > > On Mon, Jun 08, 2009 at 05:00:58PM +0100, Ian Campbell wrote:
> > > > > > On Mon, 2009-06-08 at 11:45 -0400, Ian Campbell wrote:
> > > > > > > 
> > > > > > > > L4 at e1822000 is pinned contains L2 at e1977228 which points at an
> > > > > > > L1
> > > > > > > > which is unpinned low mem address 0x8bf8000
> > > > > > > 
> > > > > > > OK so I think that is interesting. A pinned L4 referencing an unpinned
> > > > > > > L1 isn't supposed to happen, I don't think (Jeremy?).
> > > > > > 
> > > > > > Interesting:
> > > > > > 
> > > > > >         pte_t *page_check_address(struct page *page, struct mm_struct *mm,
> > > > > >         [...]
> > > > > >         	pte = pte_offset_map(pmd, address); /* A */
> > > > > >         	/* Make a quick check before getting the lock */
> > > > > >         	if (!sync && !pte_present(*pte)) {
> > > > > >         		pte_unmap(pte);
> > > > > >         		return NULL;
> > > > > >         	}
> > > > > >         
> > > > > >         	ptl = pte_lockptr(mm, pmd);
> > > > > >         	spin_lock(ptl);
> > > > > >         [...]
> > > > > >         
> > > > > > So at point A we make a new mapping of a PTE without yet holding the
> > > > > > corresponding PTE lock and this is precisely the point at which things
> > > > > > start to go wrong for us... (coincidence? I think not ;-))
> > > > > > 
> > > > > > I wonder how this interacts with the logic in
> > > > > > arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
> > > > > > the (deferred) pin multicall to occur? Hmm, no this is about the
> > > > > > PagePinned flag on the struct page which is out of date WRT the actual
> > > > > > pinned status as Xen sees it -- we update the PagePinned flag early in
> > > > > > xen_pin_page() long before Xen the pin hypercall so this window is the
> > > > > > other way round to what would be needed to trigger this bug.
> > > > > > 
> > > > > > On the other hand xen_unpin_page() looks like it sets up something
> > > > > > roughly like what we need for this issue to trigger.
> > > > > > 
> > > > > > Pasi in additional to my other mad hack could you try this:
> > > > > > 
> > > > > 
> > > > > Ok.. do you want me to try first without this patch? Or should I cancel my
> > > > > kernel compilation and apply this aswell? :)
> > > > 
> > > > Can you try the first patch first then add this one please.
> > > > 
> > > 
> > > Ok. Will do.
> > > 
> > > I was already starting to feel like 'maybe my hardware is broken' but now that
> > > code looks like it might be an actual bug :)
> > > 
> > > Let's see.
> > > 
> > 
> > Crash with only the first patch applied:
> > http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-05-with-highpte-no-swap-with-debug3.txt
> > 
> > Now I'll try with the second one included aswell..
> > 
> 
> And here's one with the second patch applied aswell:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-06-with-highpte-no-swap-with-debug4.txt
> 
> Seems to be different.. Xen is not complaining anymore..
> 

And here's one with only the second patch applied:
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-07-with-highpte-no-swap-with-debug5.txt

Now Xen is complaining again.. does that sound correct?

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-09 14:53                                                                                     ` Pasi Kärkkäinen
@ 2009-06-09 15:37                                                                                       ` Ian Campbell
  2009-06-09 18:07                                                                                         ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Ian Campbell @ 2009-06-09 15:37 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Tue, 2009-06-09 at 10:53 -0400, Pasi Kärkkäinen wrote:
> 
> 
> And here's one with only the second patch applied:
> http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-07-with-highpte-no-swap-with-debug5.txt
> 
> Now Xen is complaining again.. does that sound correct?

Well, it suggests my theory around pte locking and split pte locks may
be invalid... I guess even without split pte locks the call to
kmap_atomic_pte from page_check_address() is still outside
mm->page_table_lock and hence subject to the race.

Without redoing the core locking rules I'm not sure what we could do
about that. Perhaps as a workaround always doing kmap_atomic_pte as a
read only mapping would be sufficient (it seems to be in this particular
call chain which never writes the pte but I didn't check them all and I
guess some of them must want to write).

Does this patch (without any of the others) make any difference to you?

--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1522,7 +1522,7 @@ static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
 {
 	pgprot_t prot = PAGE_KERNEL;
 
-	if (PagePinned(page))
+	if (1 || PagePinned(page))
 		prot = PAGE_KERNEL_RO;
 
 	if (0 && PageHighMem(page))


Ian.

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-08 16:00                                                                         ` Ian Campbell
  2009-06-08 16:13                                                                           ` Pasi Kärkkäinen
@ 2009-06-09 17:28                                                                           ` Jeremy Fitzhardinge
  2009-06-11  9:02                                                                             ` Ian Campbell
  1 sibling, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-06-09 17:28 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Xen-devel

Ian Campbell wrote:
> I wonder how this interacts with the logic in
> arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
> the (deferred) pin multicall to occur? Hmm, no this is about the
> PagePinned flag on the struct page which is out of date WRT the actual
> pinned status as Xen sees it -- we update the PagePinned flag early in
> xen_pin_page() long before Xen the pin hypercall so this window is the
> other way round to what would be needed to trigger this bug.
>   

Yes, it looks like you could get a bad mapping here.  An obvious fix 
would be to defer clearing the pinned flag in the page struct until 
after the hypercall has issued.  That would make the racy 
kmap_atomic_pte map RO, which would be fine unless it actually tries to 
modify it (but I can't imagine it would do that unlocked).

    J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-09 15:37                                                                                       ` Ian Campbell
@ 2009-06-09 18:07                                                                                         ` Pasi Kärkkäinen
  0 siblings, 0 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-09 18:07 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Tue, Jun 09, 2009 at 04:37:52PM +0100, Ian Campbell wrote:
> On Tue, 2009-06-09 at 10:53 -0400, Pasi Kärkkäinen wrote:
> > 
> > 
> > And here's one with only the second patch applied:
> > http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-07-with-highpte-no-swap-with-debug5.txt
> > 
> > Now Xen is complaining again.. does that sound correct?
> 
> Well, it suggests my theory around pte locking and split pte locks may
> be invalid... I guess even without split pte locks the call to
> kmap_atomic_pte from page_check_address() is still outside
> mm->page_table_lock and hence subject to the race.
> 
> Without redoing the core locking rules I'm not sure what we could do
> about that. Perhaps as a workaround always doing kmap_atomic_pte as a
> read only mapping would be sufficient (it seems to be in this particular
> call chain which never writes the pte but I didn't check them all and I
> guess some of them must want to write).
> 
> Does this patch (without any of the others) make any difference to you?
> 

Yeah, now the kernel crashes very early during system startup :)
http://pasik.reaktio.net/xen/pv_ops-dom0-debug/pv_ops-dom0-log-08-with-highpte-no-swap-with-debug6.txt

-- Pasi

> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1522,7 +1522,7 @@ static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
>  {
>  	pgprot_t prot = PAGE_KERNEL;
>  
> -	if (PagePinned(page))
> +	if (1 || PagePinned(page))
>  		prot = PAGE_KERNEL_RO;
>  
>  	if (0 && PageHighMem(page))
> 
> 
> Ian.
> 
> 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-09 17:28                                                                           ` Jeremy Fitzhardinge
@ 2009-06-11  9:02                                                                             ` Ian Campbell
  2009-06-11  9:14                                                                               ` Pasi Kärkkäinen
                                                                                                 ` (2 more replies)
  0 siblings, 3 replies; 118+ messages in thread
From: Ian Campbell @ 2009-06-11  9:02 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Xen-devel

On Tue, 2009-06-09 at 13:28 -0400, Jeremy Fitzhardinge wrote:
> Ian Campbell wrote:
> > I wonder how this interacts with the logic in
> > arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
> > the (deferred) pin multicall to occur? Hmm, no this is about the
> > PagePinned flag on the struct page which is out of date WRT the actual
> > pinned status as Xen sees it -- we update the PagePinned flag early in
> > xen_pin_page() long before Xen the pin hypercall so this window is the
> > other way round to what would be needed to trigger this bug.
> >   
> 
> Yes, it looks like you could get a bad mapping here.  An obvious fix 
> would be to defer clearing the pinned flag in the page struct until 
> after the hypercall has issued.  That would make the racy 
> kmap_atomic_pte map RO, which would be fine unless it actually tries to 
> modify it (but I can't imagine it would do that unlocked).

But would it redo the mapping after taking the lock? It doesn't look
like it does (why would it). So we could end up writing to an unpinned
pte via a R/O mapping.

As an experiment I tried the simple approach of flushing the multicalls
explicitly in xen_unpin_page and then clearing the Pinned bit and it all
goes a bit wrong. eip is "ptep->pte_low = 0" so I think the unpinned but
R/O theory holds...
        BUG: unable to handle kernel paging request at f57ab240
        IP: [<c0486f8b>] unmap_vmas+0x32e/0x5bb
        *pdpt = 00000001002d6001
        Oops: 0003 [#1] SMP
        last sysfs file:
        Modules linked in:
        
        Pid: 719, comm: init Not tainted (2.6.30-rc6-x86_32p-highpte-tip #15)
        EIP: 0061:[<c0486f8b>] EFLAGS: 00010202 CPU: 0
        EIP is at unmap_vmas+0x32e/0x5bb
        EAX: 1dcfb025 EBX: 00000001 ECX: f57ab240 EDX: 00000001
        ESI: 00000001 EDI: 08048000 EBP: e18d8d54 ESP: e18d8cd4
         DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
        Process init (pid: 719, ti=e18d8000 task=e24d8cc0 task.ti=e18d8000)
        Stack:
         00000002 e18ce000 e3204a50 00000000 00000000 e18ad058 e18d8d70 003ff000
         08048000 00000001 00000000 00000001 e25d3e00 08050000 e18ce000 e25d3e00
         f57ab240 00000000 00000000 c17f03ec 00000000 00000000 008d8d4c e18bf200
        Call Trace:
         [<c048a752>] ? exit_mmap+0x74/0xba
         [<c0436b92>] ? mmput+0x37/0x81
         [<c04a0e69>] ? flush_old_exec+0x3bc/0x635
         [<c04a0274>] ? kernel_read+0x34/0x46
         [<c04c7594>] ? load_elf_binary+0x329/0x1189
         [<c049c2da>] ? fsnotify_access+0x4f/0x5a

kmap_atomic_pte doesn't get passed the mm so there is no way to get at
the ptl we would need to do something like clearing the pinned flag
under the lock in xen_unpin_page and holding the lock in
xen_kmap_atomic_pte. (I don't know if that would be valid anyway under
the locking scheme).

The experimental patch:

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 1729178..e997813 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1108,9 +1108,7 @@ static void __init xen_mark_init_mm_pinned(void)
 static int xen_unpin_page(struct mm_struct *mm, struct page *page,
 			  enum pt_level level)
 {
-	unsigned pgfl = TestClearPagePinned(page);
-
-	if (pgfl && !PageHighMem(page)) {
+	if (PagePinned(page) && !PageHighMem(page)) {
 		void *pt = lowmem_page_address(page);
 		unsigned long pfn = page_to_pfn(page);
 		spinlock_t *ptl = NULL;
@@ -1136,10 +1134,12 @@ static int xen_unpin_page(struct mm_struct *mm, struct page *page,
 					pfn_pte(pfn, PAGE_KERNEL),
 					level == PT_PGD ? UVMF_TLB_FLUSH : 0);
 
-		if (ptl) {
-			/* unlock when batch completed */
-			xen_mc_callback(xen_pte_unlock, ptl);
-		}
+		xen_mc_flush();
+
+		ClearPagePinned(page);
+
+		if (ptl)
+			xen_pte_unlock(ptl);
 	}
 
 	return 0;		/* never need to flush on unpin */

^ permalink raw reply related	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-11  9:02                                                                             ` Ian Campbell
@ 2009-06-11  9:14                                                                               ` Pasi Kärkkäinen
  2009-06-11  9:18                                                                                 ` Ian Campbell
  2009-06-11  9:18                                                                               ` Ian Campbell
  2009-06-11 15:18                                                                               ` Jeremy Fitzhardinge
  2 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-11  9:14 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Thu, Jun 11, 2009 at 10:02:18AM +0100, Ian Campbell wrote:
> On Tue, 2009-06-09 at 13:28 -0400, Jeremy Fitzhardinge wrote:
> > Ian Campbell wrote:
> > > I wonder how this interacts with the logic in
> > > arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
> > > the (deferred) pin multicall to occur? Hmm, no this is about the
> > > PagePinned flag on the struct page which is out of date WRT the actual
> > > pinned status as Xen sees it -- we update the PagePinned flag early in
> > > xen_pin_page() long before Xen the pin hypercall so this window is the
> > > other way round to what would be needed to trigger this bug.
> > >   
> > 
> > Yes, it looks like you could get a bad mapping here.  An obvious fix 
> > would be to defer clearing the pinned flag in the page struct until 
> > after the hypercall has issued.  That would make the racy 
> > kmap_atomic_pte map RO, which would be fine unless it actually tries to 
> > modify it (but I can't imagine it would do that unlocked).
> 
> But would it redo the mapping after taking the lock? It doesn't look
> like it does (why would it). So we could end up writing to an unpinned
> pte via a R/O mapping.
> 
> As an experiment I tried the simple approach of flushing the multicalls
> explicitly in xen_unpin_page and then clearing the Pinned bit and it all
> goes a bit wrong. eip is "ptep->pte_low = 0" so I think the unpinned but
> R/O theory holds...
>         BUG: unable to handle kernel paging request at f57ab240
>         IP: [<c0486f8b>] unmap_vmas+0x32e/0x5bb
>         *pdpt = 00000001002d6001
>         Oops: 0003 [#1] SMP
>         last sysfs file:
>         Modules linked in:
>         
>         Pid: 719, comm: init Not tainted (2.6.30-rc6-x86_32p-highpte-tip #15)
>         EIP: 0061:[<c0486f8b>] EFLAGS: 00010202 CPU: 0
>         EIP is at unmap_vmas+0x32e/0x5bb
>         EAX: 1dcfb025 EBX: 00000001 ECX: f57ab240 EDX: 00000001
>         ESI: 00000001 EDI: 08048000 EBP: e18d8d54 ESP: e18d8cd4
>          DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0069
>         Process init (pid: 719, ti=e18d8000 task=e24d8cc0 task.ti=e18d8000)
>         Stack:
>          00000002 e18ce000 e3204a50 00000000 00000000 e18ad058 e18d8d70 003ff000
>          08048000 00000001 00000000 00000001 e25d3e00 08050000 e18ce000 e25d3e00
>          f57ab240 00000000 00000000 c17f03ec 00000000 00000000 008d8d4c e18bf200
>         Call Trace:
>          [<c048a752>] ? exit_mmap+0x74/0xba
>          [<c0436b92>] ? mmput+0x37/0x81
>          [<c04a0e69>] ? flush_old_exec+0x3bc/0x635
>          [<c04a0274>] ? kernel_read+0x34/0x46
>          [<c04c7594>] ? load_elf_binary+0x329/0x1189
>          [<c049c2da>] ? fsnotify_access+0x4f/0x5a
> 
> kmap_atomic_pte doesn't get passed the mm so there is no way to get at
> the ptl we would need to do something like clearing the pinned flag
> under the lock in xen_unpin_page and holding the lock in
> xen_kmap_atomic_pte. (I don't know if that would be valid anyway under
> the locking scheme).
> 
> The experimental patch:
> 


So should I try with only this patch applied? 

-- Pasi


> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 1729178..e997813 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1108,9 +1108,7 @@ static void __init xen_mark_init_mm_pinned(void)
>  static int xen_unpin_page(struct mm_struct *mm, struct page *page,
>  			  enum pt_level level)
>  {
> -	unsigned pgfl = TestClearPagePinned(page);
> -
> -	if (pgfl && !PageHighMem(page)) {
> +	if (PagePinned(page) && !PageHighMem(page)) {
>  		void *pt = lowmem_page_address(page);
>  		unsigned long pfn = page_to_pfn(page);
>  		spinlock_t *ptl = NULL;
> @@ -1136,10 +1134,12 @@ static int xen_unpin_page(struct mm_struct *mm, struct page *page,
>  					pfn_pte(pfn, PAGE_KERNEL),
>  					level == PT_PGD ? UVMF_TLB_FLUSH : 0);
>  
> -		if (ptl) {
> -			/* unlock when batch completed */
> -			xen_mc_callback(xen_pte_unlock, ptl);
> -		}
> +		xen_mc_flush();
> +
> +		ClearPagePinned(page);
> +
> +		if (ptl)
> +			xen_pte_unlock(ptl);
>  	}
>  
>  	return 0;		/* never need to flush on unpin */
> 
> 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-11  9:14                                                                               ` Pasi Kärkkäinen
@ 2009-06-11  9:18                                                                                 ` Ian Campbell
  0 siblings, 0 replies; 118+ messages in thread
From: Ian Campbell @ 2009-06-11  9:18 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Thu, 2009-06-11 at 05:14 -0400, Pasi Kärkkäinen wrote:

> So should I try with only this patch applied? 

No, it doesn't even work for me ;-) I'm just about to send another patch
I'd like you to try though...

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-11  9:02                                                                             ` Ian Campbell
  2009-06-11  9:14                                                                               ` Pasi Kärkkäinen
@ 2009-06-11  9:18                                                                               ` Ian Campbell
  2009-06-11 18:27                                                                                 ` Pasi Kärkkäinen
  2009-07-22 18:16                                                                                 ` Jeremy Fitzhardinge
  2009-06-11 15:18                                                                               ` Jeremy Fitzhardinge
  2 siblings, 2 replies; 118+ messages in thread
From: Ian Campbell @ 2009-06-11  9:18 UTC (permalink / raw)
  To: Jeremy Fitzhardinge, Pasi Kärkkäinen; +Cc: Xen-devel

Pasi, to validate the theory that you are seeing races between unpinning
and kmap_atomic_pte can you give this biguglystick approach to solving
it a go.

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 1729178..beeb8e8 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1145,9 +1145,12 @@ static int xen_unpin_page(struct mm_struct *mm, struct page *page,
 	return 0;		/* never need to flush on unpin */
 }
 
+static DEFINE_SPINLOCK(hack_lock); /* Hack to sync unpin against kmap_atomic_pte */
+
 /* Release a pagetables pages back as normal RW */
 static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
 {
+	spin_lock(&hack_lock);
 	xen_mc_batch();
 
 	xen_do_pin(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
@@ -1173,6 +1176,7 @@ static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
 	__xen_pgd_walk(mm, pgd, xen_unpin_page, USER_LIMIT);
 
 	xen_mc_issue(0);
+	spin_unlock(&hack_lock);
 }
 
 static void xen_pgd_unpin(struct mm_struct *mm)
@@ -1521,6 +1525,9 @@ static void xen_pgd_free(struct mm_struct *mm, pgd_t *pgd)
 static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
 {
 	pgprot_t prot = PAGE_KERNEL;
+	void *ret;
+
+	spin_lock(&hack_lock);
 
 	if (PagePinned(page))
 		prot = PAGE_KERNEL_RO;
@@ -1530,7 +1537,11 @@ static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
 		       page_to_pfn(page), type,
 		       (unsigned long)pgprot_val(prot) & _PAGE_RW ? "WRITE" : "READ");
 
-	return kmap_atomic_prot(page, type, prot);
+	ret = kmap_atomic_prot(page, type, prot);
+
+	spin_unlock(&hack_lock);
+
+	return ret;
 }
 #endif

^ permalink raw reply related	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-11  9:02                                                                             ` Ian Campbell
  2009-06-11  9:14                                                                               ` Pasi Kärkkäinen
  2009-06-11  9:18                                                                               ` Ian Campbell
@ 2009-06-11 15:18                                                                               ` Jeremy Fitzhardinge
  2009-06-11 17:24                                                                                 ` Pasi Kärkkäinen
  2 siblings, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-06-11 15:18 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Xen-devel

On 06/11/09 02:02, Ian Campbell wrote:
> On Tue, 2009-06-09 at 13:28 -0400, Jeremy Fitzhardinge wrote:
>    
>> Ian Campbell wrote:
>>      
>>> I wonder how this interacts with the logic in
>>> arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
>>> the (deferred) pin multicall to occur? Hmm, no this is about the
>>> PagePinned flag on the struct page which is out of date WRT the actual
>>> pinned status as Xen sees it -- we update the PagePinned flag early in
>>> xen_pin_page() long before Xen the pin hypercall so this window is the
>>> other way round to what would be needed to trigger this bug.
>>>
>>>        
>> Yes, it looks like you could get a bad mapping here.  An obvious fix
>> would be to defer clearing the pinned flag in the page struct until
>> after the hypercall has issued.  That would make the racy
>> kmap_atomic_pte map RO, which would be fine unless it actually tries to
>> modify it (but I can't imagine it would do that unlocked).
>>      
>
> But would it redo the mapping after taking the lock? It doesn't look
> like it does (why would it). So we could end up writing to an unpinned
> pte via a R/O mapping.
>    

Hm, yep.  One thing I noticed is that set_pte() is used very rarely, so 
it would be no cost to always use a hypercall in that case.  But 
xen_set_pte_at() ends up calling xen_set_pte() as well, and I think 
that's more common.  Certainly we need to make sure that we're actually 
taking advantage of late-pin by direct writing unpinned ptes.

I've been thinking of rearranging the set_pte(_at) pvops a little bit 
anyway; its not obvious we're really getting much benefit from using the 
update_va_mapping hypercall, and if we're not using it, then the 
set_pte_at pvop is taking a lot of unused parameters.

If we switch to just using mmu_update, then we can just pass the address 
and pte value.  But we could also pass the struct page * (which makes a 
bit of conceptual sense), so we could easy directly test whether the pte 
is pinned, and either use a direct write or hypercall accordingly.

> As an experiment I tried the simple approach of flushing the multicalls
> explicitly in xen_unpin_page and then clearing the Pinned bit and it all
> goes a bit wrong. eip is "ptep->pte_low = 0" so I think the unpinned but
> R/O theory holds...
>    

Yes, I think the theory is sound.  But I'm curious why Pasi seems to be 
able to hit the race easily, but we have not...

     J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-11 15:18                                                                               ` Jeremy Fitzhardinge
@ 2009-06-11 17:24                                                                                 ` Pasi Kärkkäinen
  2009-06-11 18:56                                                                                   ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-11 17:24 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Ian Campbell, Xen-devel

On Thu, Jun 11, 2009 at 08:18:15AM -0700, Jeremy Fitzhardinge wrote:
> On 06/11/09 02:02, Ian Campbell wrote:
> >On Tue, 2009-06-09 at 13:28 -0400, Jeremy Fitzhardinge wrote:
> >   
> >>Ian Campbell wrote:
> >>     
> >>>I wonder how this interacts with the logic in
> >>>arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
> >>>the (deferred) pin multicall to occur? Hmm, no this is about the
> >>>PagePinned flag on the struct page which is out of date WRT the actual
> >>>pinned status as Xen sees it -- we update the PagePinned flag early in
> >>>xen_pin_page() long before Xen the pin hypercall so this window is the
> >>>other way round to what would be needed to trigger this bug.
> >>>
> >>>       
> >>Yes, it looks like you could get a bad mapping here.  An obvious fix
> >>would be to defer clearing the pinned flag in the page struct until
> >>after the hypercall has issued.  That would make the racy
> >>kmap_atomic_pte map RO, which would be fine unless it actually tries to
> >>modify it (but I can't imagine it would do that unlocked).
> >>     
> >
> >But would it redo the mapping after taking the lock? It doesn't look
> >like it does (why would it). So we could end up writing to an unpinned
> >pte via a R/O mapping.
> >   
> 
> Hm, yep.  One thing I noticed is that set_pte() is used very rarely, so 
> it would be no cost to always use a hypercall in that case.  But 
> xen_set_pte_at() ends up calling xen_set_pte() as well, and I think 
> that's more common.  Certainly we need to make sure that we're actually 
> taking advantage of late-pin by direct writing unpinned ptes.
> 
> I've been thinking of rearranging the set_pte(_at) pvops a little bit 
> anyway; its not obvious we're really getting much benefit from using the 
> update_va_mapping hypercall, and if we're not using it, then the 
> set_pte_at pvop is taking a lot of unused parameters.
> 
> If we switch to just using mmu_update, then we can just pass the address 
> and pte value.  But we could also pass the struct page * (which makes a 
> bit of conceptual sense), so we could easy directly test whether the pte 
> is pinned, and either use a direct write or hypercall accordingly.
> 
> >As an experiment I tried the simple approach of flushing the multicalls
> >explicitly in xen_unpin_page and then clearing the Pinned bit and it all
> >goes a bit wrong. eip is "ptep->pte_low = 0" so I think the unpinned but
> >R/O theory holds...
> >   
> 
> Yes, I think the theory is sound.  But I'm curious why Pasi seems to be 
> able to hit the race easily, but we have not...
> 

Yeah, I've been thinking about that too.. 

My hardware is ~5 years old, but it has been running stable with multiple
distributions and kernel versions, on various types of loads. I think the
hardware should be all fine.

Atm I've been running Fedora 10 and Fedora 11 on it, both seem stable with
the distro-provided kernels.

ie. I'm only seeing the problem on pv_ops dom0 kernel.

My installation is pretty basic/standard.. root-fs on LVM-volume. Can't
really think of anything special.. 

And the problem seems to be _always_ reproducible with a simple 
"make clean && make bzImage && make modules" command on dom0 .. 

Anyway, I'll continue testing. Hopefully we get this hunted down :)

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-11  9:18                                                                               ` Ian Campbell
@ 2009-06-11 18:27                                                                                 ` Pasi Kärkkäinen
  2009-06-11 19:34                                                                                   ` Pasi Kärkkäinen
  2009-07-22 18:16                                                                                 ` Jeremy Fitzhardinge
  1 sibling, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-11 18:27 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Thu, Jun 11, 2009 at 10:18:34AM +0100, Ian Campbell wrote:
> Pasi, to validate the theory that you are seeing races between unpinning
> and kmap_atomic_pte can you give this biguglystick approach to solving
> it a go.
> 

Guess what.. 

Now my dom0 didn't crash !! (with only this patch applied).
It survived kernel compilation just fine.. first time so far with pv_ops dom0.

I'll try again, just in case.

-- Pasi

> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 1729178..beeb8e8 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1145,9 +1145,12 @@ static int xen_unpin_page(struct mm_struct *mm, struct page *page,
>  	return 0;		/* never need to flush on unpin */
>  }
>  
> +static DEFINE_SPINLOCK(hack_lock); /* Hack to sync unpin against kmap_atomic_pte */
> +
>  /* Release a pagetables pages back as normal RW */
>  static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
>  {
> +	spin_lock(&hack_lock);
>  	xen_mc_batch();
>  
>  	xen_do_pin(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
> @@ -1173,6 +1176,7 @@ static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
>  	__xen_pgd_walk(mm, pgd, xen_unpin_page, USER_LIMIT);
>  
>  	xen_mc_issue(0);
> +	spin_unlock(&hack_lock);
>  }
>  
>  static void xen_pgd_unpin(struct mm_struct *mm)
> @@ -1521,6 +1525,9 @@ static void xen_pgd_free(struct mm_struct *mm, pgd_t *pgd)
>  static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
>  {
>  	pgprot_t prot = PAGE_KERNEL;
> +	void *ret;
> +
> +	spin_lock(&hack_lock);
>  
>  	if (PagePinned(page))
>  		prot = PAGE_KERNEL_RO;
> @@ -1530,7 +1537,11 @@ static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
>  		       page_to_pfn(page), type,
>  		       (unsigned long)pgprot_val(prot) & _PAGE_RW ? "WRITE" : "READ");
>  
> -	return kmap_atomic_prot(page, type, prot);
> +	ret = kmap_atomic_prot(page, type, prot);
> +
> +	spin_unlock(&hack_lock);
> +
> +	return ret;
>  }
>  #endif
>  
> 
> 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-11 17:24                                                                                 ` Pasi Kärkkäinen
@ 2009-06-11 18:56                                                                                   ` Jeremy Fitzhardinge
  2009-06-11 19:02                                                                                     ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-06-11 18:56 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Ian Campbell, Xen-devel

On 06/11/09 10:24, Pasi Kärkkäinen wrote:
> Atm I've been running Fedora 10 and Fedora 11 on it, both seem stable with
> the distro-provided kernels.
>    
But not Xen?

> ie. I'm only seeing the problem on pv_ops dom0 kernel.
>
> My installation is pretty basic/standard.. root-fs on LVM-volume. Can't
> really think of anything special..
>    

Any odd (=not ext3) filesystems?

     J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-11 18:56                                                                                   ` Jeremy Fitzhardinge
@ 2009-06-11 19:02                                                                                     ` Pasi Kärkkäinen
  2009-06-11 19:23                                                                                       ` Jeremy Fitzhardinge
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-11 19:02 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Ian Campbell, Xen-devel

On Thu, Jun 11, 2009 at 11:56:56AM -0700, Jeremy Fitzhardinge wrote:
> On 06/11/09 10:24, Pasi Kärkkäinen wrote:
> >Atm I've been running Fedora 10 and Fedora 11 on it, both seem stable with
> >the distro-provided kernels.
> >   
> But not Xen?
> 

I've also been running Xen of CentOS 5.x, and it has been stable aswell..

> >ie. I'm only seeing the problem on pv_ops dom0 kernel.
> >
> >My installation is pretty basic/standard.. root-fs on LVM-volume. Can't
> >really think of anything special..
> >   
> 
> Any odd (=not ext3) filesystems?
> 

Only ext3 in use..

But now with the latest "biguglystick" patch from Ian I was able to
successfully run my kernel-compilation test.. (see the other mail).

so it looks like the problem was found!

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-11 19:02                                                                                     ` Pasi Kärkkäinen
@ 2009-06-11 19:23                                                                                       ` Jeremy Fitzhardinge
  2009-06-29 21:16                                                                                         ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-06-11 19:23 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Ian Campbell, Xen-devel

On 06/11/09 12:02, Pasi Kärkkäinen wrote:
> But now with the latest "biguglystick" patch from Ian I was able to
> successfully run my kernel-compilation test.. (see the other mail).
>
> so it looks like the problem was found!
>    

Yes.  Still mulling a proper fix though.

     J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-11 18:27                                                                                 ` Pasi Kärkkäinen
@ 2009-06-11 19:34                                                                                   ` Pasi Kärkkäinen
  2009-06-15 10:03                                                                                     ` Ian Campbell
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-11 19:34 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Thu, Jun 11, 2009 at 09:27:09PM +0300, Pasi Kärkkäinen wrote:
> On Thu, Jun 11, 2009 at 10:18:34AM +0100, Ian Campbell wrote:
> > Pasi, to validate the theory that you are seeing races between unpinning
> > and kmap_atomic_pte can you give this biguglystick approach to solving
> > it a go.
> > 
> 
> Guess what.. 
> 
> Now my dom0 didn't crash !! (with only this patch applied).
> It survived kernel compilation just fine.. first time so far with pv_ops dom0.
> 
> I'll try again, just in case.
> 

Yep, I tried again, and it still worked. 

No crashes anymore with this patch :) Congratulations and thanks!

-- Pasi

> 
> > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > index 1729178..beeb8e8 100644
> > --- a/arch/x86/xen/mmu.c
> > +++ b/arch/x86/xen/mmu.c
> > @@ -1145,9 +1145,12 @@ static int xen_unpin_page(struct mm_struct *mm, struct page *page,
> >  	return 0;		/* never need to flush on unpin */
> >  }
> >  
> > +static DEFINE_SPINLOCK(hack_lock); /* Hack to sync unpin against kmap_atomic_pte */
> > +
> >  /* Release a pagetables pages back as normal RW */
> >  static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
> >  {
> > +	spin_lock(&hack_lock);
> >  	xen_mc_batch();
> >  
> >  	xen_do_pin(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
> > @@ -1173,6 +1176,7 @@ static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
> >  	__xen_pgd_walk(mm, pgd, xen_unpin_page, USER_LIMIT);
> >  
> >  	xen_mc_issue(0);
> > +	spin_unlock(&hack_lock);
> >  }
> >  
> >  static void xen_pgd_unpin(struct mm_struct *mm)
> > @@ -1521,6 +1525,9 @@ static void xen_pgd_free(struct mm_struct *mm, pgd_t *pgd)
> >  static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
> >  {
> >  	pgprot_t prot = PAGE_KERNEL;
> > +	void *ret;
> > +
> > +	spin_lock(&hack_lock);
> >  
> >  	if (PagePinned(page))
> >  		prot = PAGE_KERNEL_RO;
> > @@ -1530,7 +1537,11 @@ static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
> >  		       page_to_pfn(page), type,
> >  		       (unsigned long)pgprot_val(prot) & _PAGE_RW ? "WRITE" : "READ");
> >  
> > -	return kmap_atomic_prot(page, type, prot);
> > +	ret = kmap_atomic_prot(page, type, prot);
> > +
> > +	spin_unlock(&hack_lock);
> > +
> > +	return ret;
> >  }
> >  #endif
> >  
> > 
> > 
> 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-11 19:34                                                                                   ` Pasi Kärkkäinen
@ 2009-06-15 10:03                                                                                     ` Ian Campbell
  2009-06-15 10:21                                                                                       ` Pasi Kärkkäinen
  0 siblings, 1 reply; 118+ messages in thread
From: Ian Campbell @ 2009-06-15 10:03 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Thu, 2009-06-11 at 15:34 -0400, Pasi Kärkkäinen wrote:
> On Thu, Jun 11, 2009 at 09:27:09PM +0300, Pasi Kärkkäinen wrote:
> > On Thu, Jun 11, 2009 at 10:18:34AM +0100, Ian Campbell wrote:
> > > Pasi, to validate the theory that you are seeing races between unpinning
> > > and kmap_atomic_pte can you give this biguglystick approach to solving
> > > it a go.
> > > 
> > 
> > Guess what.. 
> > 
> > Now my dom0 didn't crash !! (with only this patch applied).
> > It survived kernel compilation just fine.. first time so far with pv_ops dom0.
> > 
> > I'll try again, just in case.
> > 
> 
> Yep, I tried again, and it still worked. 
> 
> No crashes anymore with this patch :) Congratulations and thanks!

Oh good, thanks for testing. The patch is not really a suitable
long-term fix as it is but it sounds like Jeremy has some ideas.

I'm still curious how come you are the only one who sees this issue.  I
don't recall you having lots of processors in your dmesg which might
make the race more common, nor do you have involuntary preempt enabled.
Very strange. Oh well I guess it doesn't matter now ;-)

Ian.


> 
> -- Pasi
> 
> > 
> > > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > > index 1729178..beeb8e8 100644
> > > --- a/arch/x86/xen/mmu.c
> > > +++ b/arch/x86/xen/mmu.c
> > > @@ -1145,9 +1145,12 @@ static int xen_unpin_page(struct mm_struct *mm, struct page *page,
> > >  	return 0;		/* never need to flush on unpin */
> > >  }
> > >  
> > > +static DEFINE_SPINLOCK(hack_lock); /* Hack to sync unpin against kmap_atomic_pte */
> > > +
> > >  /* Release a pagetables pages back as normal RW */
> > >  static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
> > >  {
> > > +	spin_lock(&hack_lock);
> > >  	xen_mc_batch();
> > >  
> > >  	xen_do_pin(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
> > > @@ -1173,6 +1176,7 @@ static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
> > >  	__xen_pgd_walk(mm, pgd, xen_unpin_page, USER_LIMIT);
> > >  
> > >  	xen_mc_issue(0);
> > > +	spin_unlock(&hack_lock);
> > >  }
> > >  
> > >  static void xen_pgd_unpin(struct mm_struct *mm)
> > > @@ -1521,6 +1525,9 @@ static void xen_pgd_free(struct mm_struct *mm, pgd_t *pgd)
> > >  static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
> > >  {
> > >  	pgprot_t prot = PAGE_KERNEL;
> > > +	void *ret;
> > > +
> > > +	spin_lock(&hack_lock);
> > >  
> > >  	if (PagePinned(page))
> > >  		prot = PAGE_KERNEL_RO;
> > > @@ -1530,7 +1537,11 @@ static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
> > >  		       page_to_pfn(page), type,
> > >  		       (unsigned long)pgprot_val(prot) & _PAGE_RW ? "WRITE" : "READ");
> > >  
> > > -	return kmap_atomic_prot(page, type, prot);
> > > +	ret = kmap_atomic_prot(page, type, prot);
> > > +
> > > +	spin_unlock(&hack_lock);
> > > +
> > > +	return ret;
> > >  }
> > >  #endif
> > >  
> > > 
> > > 
> > 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-15 10:03                                                                                     ` Ian Campbell
@ 2009-06-15 10:21                                                                                       ` Pasi Kärkkäinen
  2009-06-16 10:35                                                                                         ` Ian Campbell
  0 siblings, 1 reply; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-15 10:21 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Mon, Jun 15, 2009 at 11:03:17AM +0100, Ian Campbell wrote:
> On Thu, 2009-06-11 at 15:34 -0400, Pasi Kärkkäinen wrote:
> > On Thu, Jun 11, 2009 at 09:27:09PM +0300, Pasi Kärkkäinen wrote:
> > > On Thu, Jun 11, 2009 at 10:18:34AM +0100, Ian Campbell wrote:
> > > > Pasi, to validate the theory that you are seeing races between unpinning
> > > > and kmap_atomic_pte can you give this biguglystick approach to solving
> > > > it a go.
> > > > 
> > > 
> > > Guess what.. 
> > > 
> > > Now my dom0 didn't crash !! (with only this patch applied).
> > > It survived kernel compilation just fine.. first time so far with pv_ops dom0.
> > > 
> > > I'll try again, just in case.
> > > 
> > 
> > Yep, I tried again, and it still worked. 
> > 
> > No crashes anymore with this patch :) Congratulations and thanks!
> 
> Oh good, thanks for testing. The patch is not really a suitable
> long-term fix as it is but it sounds like Jeremy has some ideas.
> 

Yep. I'm only able to test patches until thursday this week, after that
I'll be on summer vacation for a month and I don't know yet how much I'm
able to test patches during that period.. 

> I'm still curious how come you are the only one who sees this issue.  I
> don't recall you having lots of processors in your dmesg which might
> make the race more common, nor do you have involuntary preempt enabled.
> Very strange. Oh well I guess it doesn't matter now ;-)
> 

(XEN) Initializing CPU#0
(XEN) Detected 3000.241 MHz processor.
(XEN) CPU0: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 04

(XEN) Initializing CPU#1
(XEN) CPU1: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 04
(XEN) Total of 2 processors activated.

It's old Intel P4 CPU with hyperthreading, so one physical CPU, seen as two
logical CPUs.

dom0 kernel/domain is seeing both CPUs:

SMP: Allowing 2 CPUs, 0 hotplug CPUs
Initializing CPU#0
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
Initializing CPU#1
CPU1: Intel P4/Xeon Extended MCE MSRs (12) available
Brought up 2 CPUs


But yeah, if the reason for the problem looks valid, I guess it doesn't
really matter then :)

-- Pasi

> Ian.
> 
> 
> > 
> > -- Pasi
> > 
> > > 
> > > > diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> > > > index 1729178..beeb8e8 100644
> > > > --- a/arch/x86/xen/mmu.c
> > > > +++ b/arch/x86/xen/mmu.c
> > > > @@ -1145,9 +1145,12 @@ static int xen_unpin_page(struct mm_struct *mm, struct page *page,
> > > >  	return 0;		/* never need to flush on unpin */
> > > >  }
> > > >  
> > > > +static DEFINE_SPINLOCK(hack_lock); /* Hack to sync unpin against kmap_atomic_pte */
> > > > +
> > > >  /* Release a pagetables pages back as normal RW */
> > > >  static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
> > > >  {
> > > > +	spin_lock(&hack_lock);
> > > >  	xen_mc_batch();
> > > >  
> > > >  	xen_do_pin(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
> > > > @@ -1173,6 +1176,7 @@ static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
> > > >  	__xen_pgd_walk(mm, pgd, xen_unpin_page, USER_LIMIT);
> > > >  
> > > >  	xen_mc_issue(0);
> > > > +	spin_unlock(&hack_lock);
> > > >  }
> > > >  
> > > >  static void xen_pgd_unpin(struct mm_struct *mm)
> > > > @@ -1521,6 +1525,9 @@ static void xen_pgd_free(struct mm_struct *mm, pgd_t *pgd)
> > > >  static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
> > > >  {
> > > >  	pgprot_t prot = PAGE_KERNEL;
> > > > +	void *ret;
> > > > +
> > > > +	spin_lock(&hack_lock);
> > > >  
> > > >  	if (PagePinned(page))
> > > >  		prot = PAGE_KERNEL_RO;
> > > > @@ -1530,7 +1537,11 @@ static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
> > > >  		       page_to_pfn(page), type,
> > > >  		       (unsigned long)pgprot_val(prot) & _PAGE_RW ? "WRITE" : "READ");
> > > >  
> > > > -	return kmap_atomic_prot(page, type, prot);
> > > > +	ret = kmap_atomic_prot(page, type, prot);
> > > > +
> > > > +	spin_unlock(&hack_lock);
> > > > +
> > > > +	return ret;
> > > >  }
> > > >  #endif
> > > >  
> > > > 
> > > > 
> > > 
> 

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-15 10:21                                                                                       ` Pasi Kärkkäinen
@ 2009-06-16 10:35                                                                                         ` Ian Campbell
  2009-06-16 10:56                                                                                           ` Pasi Kärkkäinen
  2009-06-16 19:31                                                                                           ` Jeremy Fitzhardinge
  0 siblings, 2 replies; 118+ messages in thread
From: Ian Campbell @ 2009-06-16 10:35 UTC (permalink / raw)
  To: Pasi Kärkkäinen; +Cc: Jeremy Fitzhardinge, Xen-devel

On Mon, 2009-06-15 at 06:21 -0400, Pasi Kärkkäinen wrote:
> 
> It's old Intel P4 CPU with hyperthreading, so one physical CPU, seen
> as two logical CPUs.

Interesting in the light of a comment from Ingo Molnar this morning on
LKML:
> Plus this system is an old P4 HyperThreading dual-socket system: 
> pretty much the only thing HyperThreading is good for on that box is 
> finding SMP races: that CPU can (and will) yield between 
> hyperthreads on arbitrary instruction boundaries - opening up races 
> wide open.

Ian.

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-16 10:35                                                                                         ` Ian Campbell
@ 2009-06-16 10:56                                                                                           ` Pasi Kärkkäinen
  2009-06-16 19:31                                                                                           ` Jeremy Fitzhardinge
  1 sibling, 0 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-16 10:56 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Jeremy Fitzhardinge, Xen-devel

On Tue, Jun 16, 2009 at 11:35:25AM +0100, Ian Campbell wrote:
> On Mon, 2009-06-15 at 06:21 -0400, Pasi Kärkkäinen wrote:
> > 
> > It's old Intel P4 CPU with hyperthreading, so one physical CPU, seen
> > as two logical CPUs.
> 
> Interesting in the light of a comment from Ingo Molnar this morning on
> LKML:
> > Plus this system is an old P4 HyperThreading dual-socket system: 
> > pretty much the only thing HyperThreading is good for on that box is 
> > finding SMP races: that CPU can (and will) yield between 
> > hyperthreads on arbitrary instruction boundaries - opening up races 
> > wide open.
> 

I knew this box was good for something! :)

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-16 10:35                                                                                         ` Ian Campbell
  2009-06-16 10:56                                                                                           ` Pasi Kärkkäinen
@ 2009-06-16 19:31                                                                                           ` Jeremy Fitzhardinge
  2009-06-29 21:23                                                                                             ` Dulloor
  1 sibling, 1 reply; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-06-16 19:31 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Xen-devel

On 06/16/09 03:35, Ian Campbell wrote:
> Interesting in the light of a comment from Ingo Molnar this morning on
> LKML:
>    
>> Plus this system is an old P4 HyperThreading dual-socket system:
>> pretty much the only thing HyperThreading is good for on that box is
>> finding SMP races: that CPU can (and will) yield between
>> hyperthreads on arbitrary instruction boundaries - opening up races
>> wide open.
>>      

Yes, I was wondering if HT could be a factor here.  My test server is 
HT, but I run it 64-bit...

     J

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-11 19:23                                                                                       ` Jeremy Fitzhardinge
@ 2009-06-29 21:16                                                                                         ` Pasi Kärkkäinen
  0 siblings, 0 replies; 118+ messages in thread
From: Pasi Kärkkäinen @ 2009-06-29 21:16 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Ian Campbell, Xen-devel

On Thu, Jun 11, 2009 at 12:23:52PM -0700, Jeremy Fitzhardinge wrote:
> On 06/11/09 12:02, Pasi Kärkkäinen wrote:
> >But now with the latest "biguglystick" patch from Ian I was able to
> >successfully run my kernel-compilation test.. (see the other mail).
> >
> >so it looks like the problem was found!
> >   
> 
> Yes.  Still mulling a proper fix though.
> 

When there's something to test, let me know..

-- Pasi

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-16 19:31                                                                                           ` Jeremy Fitzhardinge
@ 2009-06-29 21:23                                                                                             ` Dulloor
  0 siblings, 0 replies; 118+ messages in thread
From: Dulloor @ 2009-06-29 21:23 UTC (permalink / raw)
  To: Jeremy Fitzhardinge; +Cc: Ian Campbell, Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 1058 bytes --]

Please check the other thread titled "pvops bug". I ran into issues without
HT (on a core-2 quad machine). My crude fix as well as Ian's crude patch,
both serializing unpin pte call avoids crash. I can look into it once I find
time. If you have any clue, I can try earlier.

-dulloor

On Tue, Jun 16, 2009 at 3:31 PM, Jeremy Fitzhardinge <jeremy@goop.org>wrote:

> On 06/16/09 03:35, Ian Campbell wrote:
>
>> Interesting in the light of a comment from Ingo Molnar this morning on
>> LKML:
>>
>>
>>> Plus this system is an old P4 HyperThreading dual-socket system:
>>> pretty much the only thing HyperThreading is good for on that box is
>>> finding SMP races: that CPU can (and will) yield between
>>> hyperthreads on arbitrary instruction boundaries - opening up races
>>> wide open.
>>>
>>>
>>
> Yes, I was wondering if HT could be a factor here.  My test server is HT,
> but I run it 64-bit...
>
>
>    J
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 1866 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

^ permalink raw reply	[flat|nested] 118+ messages in thread

* Re: xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0
  2009-06-11  9:18                                                                               ` Ian Campbell
  2009-06-11 18:27                                                                                 ` Pasi Kärkkäinen
@ 2009-07-22 18:16                                                                                 ` Jeremy Fitzhardinge
  1 sibling, 0 replies; 118+ messages in thread
From: Jeremy Fitzhardinge @ 2009-07-22 18:16 UTC (permalink / raw)
  To: Ian Campbell; +Cc: Xen-devel

On 06/11/09 02:18, Ian Campbell wrote:
> Pasi, to validate the theory that you are seeing races between unpinning
> and kmap_atomic_pte can you give this biguglystick approach to solving
> it a go.
>   

I gave up trying to solve this in any kind of clever way and just
decided to go with a slightly cleaned-up version of this patch. 
Unfortunately, I don't think it actually solves the problem because it
doesn't prevent unpin from happening while the page is still kmapped; it
just ends up using the spinlock as a barrier to move the race around to
some timing which is presumably mostly avoids the problem.

In principle the fix is to take the lock in xen_kmap_atomic and release
it in xen_kunmap_atomic.  Unfortunately this is pretty ugly and complex
because kmaps are 1) inherently per-cpu, and 2) there can be 2 levels of
kmapping at once.  This means that we'd need 2 per-cpu locks to allow us
to hold these locks for the mapping duration without introducing
deadlocks.  However unpin (and pin, in principle) need to take *all*
these locks to exclude kmap on all cpus.

This is total overkill, since we only really care about excluding kmap
and unpin from a given pagetable, which suggests that the locks should
be part of the mm rather than global.  Unfortunately k(un)map_atomic_pte
don't get the mm of the pagetable they're trying to pin, and I don't
think we can assume its the current mm.

Another (pretty hideous) approach might be to make unpin check the state
of the KMAP_PTE[01] slots in each CPU's kmap fixmaps and see if a
mapping exists for a page that its currently unpinning.  This also has
the problem of being inherently racy; if we unpin the page, there's
going to be a little window after the unpin and before the kmap pte
update (even if they're back-to-back batched hypercalls).

I guess we could have a global rw spinlock; kmap/unmap takes it for
reading, and so can be concurrent with all other kmaps, but pin/unpin
takes it for writing to exclude them.  That would work, but runs the
risk of pin/unpin from being livelocked out (I don't think rwspins will
block new readers if there's a pending writer).  Ugly, but its the only
thing I can think of which actually solves the problem.

Oh, crap, we don't have a kunmap_atomic_pte hook.

Thoughts?  Am I overthinking this and missing something obvious?

(PS: avoid CONFIG_HIGHPTE)

    J

> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 1729178..beeb8e8 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1145,9 +1145,12 @@ static int xen_unpin_page(struct mm_struct *mm, struct page *page,
>  	return 0;		/* never need to flush on unpin */
>  }
>  
> +static DEFINE_SPINLOCK(hack_lock); /* Hack to sync unpin against kmap_atomic_pte */
> +
>  /* Release a pagetables pages back as normal RW */
>  static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
>  {
> +	spin_lock(&hack_lock);
>  	xen_mc_batch();
>  
>  	xen_do_pin(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
> @@ -1173,6 +1176,7 @@ static void __xen_pgd_unpin(struct mm_struct *mm, pgd_t *pgd)
>  	__xen_pgd_walk(mm, pgd, xen_unpin_page, USER_LIMIT);
>  
>  	xen_mc_issue(0);
> +	spin_unlock(&hack_lock);
>  }
>  
>  static void xen_pgd_unpin(struct mm_struct *mm)
> @@ -1521,6 +1525,9 @@ static void xen_pgd_free(struct mm_struct *mm, pgd_t *pgd)
>  static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
>  {
>  	pgprot_t prot = PAGE_KERNEL;
> +	void *ret;
> +
> +	spin_lock(&hack_lock);
>  
>  	if (PagePinned(page))
>  		prot = PAGE_KERNEL_RO;
> @@ -1530,7 +1537,11 @@ static void *xen_kmap_atomic_pte(struct page *page, enum km_type type)
>  		       page_to_pfn(page), type,
>  		       (unsigned long)pgprot_val(prot) & _PAGE_RW ? "WRITE" : "READ");
>  
> -	return kmap_atomic_prot(page, type, prot);
> +	ret = kmap_atomic_prot(page, type, prot);
> +
> +	spin_unlock(&hack_lock);
> +
> +	return ret;
>  }
>  #endif
>  
>
>
>   

^ permalink raw reply	[flat|nested] 118+ messages in thread

end of thread, other threads:[~2009-07-22 18:16 UTC | newest]

Thread overview: 118+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-23 17:38 xen.git branch reorg Jeremy Fitzhardinge
2009-04-23 18:24 ` Pasi Kärkkäinen
2009-04-23 18:32   ` Jeremy Fitzhardinge
2009-04-25 11:54     ` xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0 Pasi Kärkkäinen
2009-04-25 12:36       ` Pasi Kärkkäinen
2009-04-25 13:59       ` M A Young
2009-04-26 14:50         ` Pasi Kärkkäinen
2009-04-25 23:34       ` Jeremy Fitzhardinge
2009-04-26 14:51         ` Pasi Kärkkäinen
2009-04-26 18:38           ` Pasi Kärkkäinen
2009-04-27 19:33       ` Jeremy Fitzhardinge
2009-04-27 19:38         ` Pasi Kärkkäinen
     [not found]           ` <1240931113.22119.11.camel@zakaz.uk.xensource.com>
2009-04-28 15:22             ` Pasi Kärkkäinen
2009-04-28 15:41               ` Yum install xen on F10 Boris Derzhavets
2009-04-28 16:02                 ` M A Young
2009-04-28 17:42                   ` Boris Derzhavets
2009-04-28 19:33                     ` Pasi Kärkkäinen
2009-04-28 19:40                       ` Boris Derzhavets
2009-04-29  6:40                       ` Boris Derzhavets
2009-05-01  9:13                   ` Boris Derzhavets
2009-05-01  9:26                     ` John Haxby
2009-05-01 10:51                       ` Boris Derzhavets
2009-05-01 10:55                     ` M A Young
2009-05-01 11:19                       ` Boris Derzhavets
2009-04-28 17:38                 ` Pasi Kärkkäinen
2009-04-28 16:25             ` xen.git branch reorg / crash with 2.6.30-rc3 pv_ops dom0 Jeremy Fitzhardinge
     [not found]               ` <1240939020.22119.15.camel@zakaz.uk.xensource.com>
2009-04-28 17:30                 ` Jeremy Fitzhardinge
     [not found]                   ` <1240989350.17173.2096.camel@localhost.localdomain>
2009-04-29 16:25                     ` Jeremy Fitzhardinge
2009-05-01  9:58                       ` Pasi Kärkkäinen
2009-05-01 18:35                         ` Jeremy Fitzhardinge
2009-05-05 17:19                           ` Pasi Kärkkäinen
2009-05-05 20:10                             ` Jeremy Fitzhardinge
2009-05-06 18:54                               ` xen.git branch reorg / success " Pasi Kärkkäinen
2009-05-06 21:51                                 ` Jeremy Fitzhardinge
2009-05-07 17:24                                   ` Pasi Kärkkäinen
2009-05-07 18:30                                     ` Jeremy Fitzhardinge
2009-05-07 18:46                                       ` Pasi Kärkkäinen
2009-05-14 11:11                                         ` xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0 / CONFIG_HIGHPTE problems Pasi Kärkkäinen
2009-05-15 22:48                                           ` Jeremy Fitzhardinge
2009-05-18 14:57                                     ` xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0 Ian Campbell
2009-05-18 17:06                                       ` Pasi Kärkkäinen
2009-05-18 17:17                                         ` Pasi Kärkkäinen
2009-05-18 17:39                                           ` Jeremy Fitzhardinge
2009-05-18 17:50                                             ` Pasi Kärkkäinen
2009-05-21  9:08                                               ` Ian Campbell
2009-05-22  8:06                                                 ` Pasi Kärkkäinen
2009-06-04 20:26                                                   ` Pasi Kärkkäinen
2009-06-04 20:30                                                     ` Pasi Kärkkäinen
2009-06-05 10:20                                                     ` Ian Campbell
2009-06-05 11:23                                                       ` Pasi Kärkkäinen
2009-06-05 11:37                                                         ` Ian Campbell
2009-06-05 13:38                                                           ` Pasi Kärkkäinen
2009-06-05 13:52                                                             ` Ian Campbell
2009-06-05 15:41                                                               ` Pasi Kärkkäinen
2009-06-05 16:05                                                                 ` Ian Campbell
2009-06-05 16:12                                                                   ` Ian Campbell
2009-06-05 18:19                                                                     ` Pasi Kärkkäinen
2009-06-08 15:45                                                                       ` Ian Campbell
2009-06-08 16:00                                                                         ` Ian Campbell
2009-06-08 16:13                                                                           ` Pasi Kärkkäinen
2009-06-08 16:17                                                                             ` Ian Campbell
2009-06-08 16:21                                                                               ` Pasi Kärkkäinen
2009-06-08 17:05                                                                                 ` Pasi Kärkkäinen
2009-06-08 19:11                                                                                   ` Pasi Kärkkäinen
2009-06-09 14:53                                                                                     ` Pasi Kärkkäinen
2009-06-09 15:37                                                                                       ` Ian Campbell
2009-06-09 18:07                                                                                         ` Pasi Kärkkäinen
2009-06-09 17:28                                                                           ` Jeremy Fitzhardinge
2009-06-11  9:02                                                                             ` Ian Campbell
2009-06-11  9:14                                                                               ` Pasi Kärkkäinen
2009-06-11  9:18                                                                                 ` Ian Campbell
2009-06-11  9:18                                                                               ` Ian Campbell
2009-06-11 18:27                                                                                 ` Pasi Kärkkäinen
2009-06-11 19:34                                                                                   ` Pasi Kärkkäinen
2009-06-15 10:03                                                                                     ` Ian Campbell
2009-06-15 10:21                                                                                       ` Pasi Kärkkäinen
2009-06-16 10:35                                                                                         ` Ian Campbell
2009-06-16 10:56                                                                                           ` Pasi Kärkkäinen
2009-06-16 19:31                                                                                           ` Jeremy Fitzhardinge
2009-06-29 21:23                                                                                             ` Dulloor
2009-07-22 18:16                                                                                 ` Jeremy Fitzhardinge
2009-06-11 15:18                                                                               ` Jeremy Fitzhardinge
2009-06-11 17:24                                                                                 ` Pasi Kärkkäinen
2009-06-11 18:56                                                                                   ` Jeremy Fitzhardinge
2009-06-11 19:02                                                                                     ` Pasi Kärkkäinen
2009-06-11 19:23                                                                                       ` Jeremy Fitzhardinge
2009-06-29 21:16                                                                                         ` Pasi Kärkkäinen
2009-05-18 19:09                                         ` Pasi Kärkkäinen
2009-05-06  6:48                           ` xen.git branch reorg / crash " Jiang, Yunhong
2009-05-06  7:40                             ` Jiang, Yunhong
2009-05-06 15:54                               ` Jeremy Fitzhardinge
2009-04-24 10:33   ` xen.git branch reorg Boris Derzhavets
2009-04-24 18:17     ` Jeremy Fitzhardinge
2009-04-24 18:50       ` Boris Derzhavets
2009-04-24 19:48         ` Jeremy Fitzhardinge
2009-04-24 22:39           ` Christophe Saout
2009-04-25  6:55             ` Boris Derzhavets
2009-04-25  7:03               ` Venefax
2009-04-25  8:35                 ` Boris Derzhavets
2009-04-25  8:19               ` Pasi Kärkkäinen
2009-04-25  8:58                 ` Boris Derzhavets
2009-04-25  9:22             ` Boris Derzhavets
     [not found]           ` <1240846534.29824.101.camel@zakaz.uk.xensource.com>
2009-04-27 19:46             ` Jeremy Fitzhardinge
2009-04-27 20:18               ` Christophe Saout
2009-04-24 18:56       ` Boris Derzhavets
2009-04-24  8:59 ` Alex Zeffertt
2009-04-27 15:44   ` Ian Campbell
2009-04-26  1:28 ` William Pitcock
2009-04-27 20:50   ` Jeremy Fitzhardinge
2009-04-27 21:07     ` William Pitcock
2009-04-27 23:48       ` Jeremy Fitzhardinge
2009-04-28  7:13         ` William Pitcock
2009-04-28  9:14           ` Boris Derzhavets
2009-04-28 14:51             ` William Pitcock
2009-04-28 15:01               ` Boris Derzhavets
2009-04-28 15:33                 ` William Pitcock
2009-04-28 15:51                   ` Boris Derzhavets
2009-04-28 16:28                   ` Jeremy Fitzhardinge

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.