RE: [Xen-devel] Badness in local_bh_enable (e1000???)

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

I notice you have the e1000 module loaded. In my configuration I am
using linux-iscsi to run the root device over an e1000 card, which seems
to work fine until the moment a domain > 0 tries to access the exported
iscsi device and then dom0 immediately crashes and burns (dom>0
segfaults too but probably as a result of the error being inherited from
dom0)

If I use a non-e1000 network card it all works fine.

Can you try another network adapter?

In my configuration, only dom0 uses the e1000. I have another adapter in
the machine with vlans (3 interfaces including the network that the
e1000 is on, none of which have ip addresses in dom0) bridged for use by
other domains.

James

Btw, I call dom0 'dom0', but I don't have a good name for any other
domain that gets created. domU might make sense but sometimes other
domains are privileged too aren't they?

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Nick Craig-Wood
> Sent: Monday, 11 April 2005 21:11
> To: Ian Pratt
> Cc: Nicholas Lee; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Badness in local_bh_enable
> 
> (re-opening an old thread)
> 
> On Tue, Mar 08, 2005 at 11:05:01AM -0000, Ian Pratt wrote:
> >  > nic@stateless:~$ strings
> > > /lib/modules/2.6.10-xen0/kernel/net/rxrpc/rxrpc.ko | grep
vermagic=
> > > vermagic=2.6.10-xen0 preempt PENTIUM4 gcc-3.3
> > >
> > > These seems to be compiled with ARCH=xen.
> >
> > Not necessarily. You may have used that -xen0 tree, but not
specified
> > ARCH=xen. There's no way to tell :-(
> >
> > > nic@stateless:~$ strings
> > > /lib/modules/2.6.10-xenU/kernel/net/ipv4/netfilter/ipt_REJECT.
> > > ko | grep vermagic=
> > > vermagic=2.6.10-xenU preempt PENTIUM4 gcc-3.3
> > > nic@stateless:~$ objdump -d
> > > /lib/modules/2.6.10-xenU/kernel/net/ipv4/netfilter/ipt_REJECT.
> > > ko | egrep  -e sti
> > >  b3f:   fb                      sti
> >
> > Just finding a cli/sti in the disassembled output does not
necessarily
> > indicate a problem -- objdump frequently gets confused and
disassembles
> > things that are data, particularly after an undefined instruction
e.g.
> > the uda2 used for BUG messages.
> >
> > You'll need to look at the instructions around the cli/sti to
determine
> > whether they're real or not.
> 
> Was this problem ever got to the bottom of?
> 
> We are seeing it too.  Lots of
> 
> Badness in local_bh_enable at kernel/softirq.c:140
>  [<c011fb12>] local_bh_enable+0x82/0x90
>  [<c031fcfd>] skb_checksum+0x13d/0x2d0
>  [<c016ac5c>] __pollwait+0x8c/0xd0
>  [<c0360d3a>] udp_poll+0x9a/0x160
>  [<c031af49>] sock_poll+0x29/0x40
>  [<c016b635>] do_pollfd+0x95/0xa0
>  [<c016b6aa>] do_poll+0x6a/0xd0
>  [<c016b871>] sys_poll+0x161/0x240
>  [<c011f14c>] sys_gettimeofday+0x3c/0x90
>  [<c016abd0>] __pollwait+0x0/0xd0
>  [<c0109758>] syscall_call+0x7/0xb
> 
> In the logs.
> 
> I've checked the loaded modules...
> 
> Module                  Size  Used by
> sch_sfq                 4992  88
> cls_u32                 8068  101
> sch_cbq                15616  13
> ipt_state               1664  2
> ipt_REJECT              5888  3
> ipt_LOG                 6528  4
> ipt_limit               2176  4
> iptable_mangle          2432  0
> iptable_filter          3200  1
> ip_nat_ftp              4464  0
> ip_conntrack_ftp       71600  1 ip_nat_ftp
> iptable_nat            23496  1 ip_nat_ftp
> ip_conntrack           41364  4
> ipt_state,ip_nat_ftp,ip_conntrack_ftp,iptable_nat
> ip_tables              17024  7
>
ipt_state,ipt_REJECT,ipt_LOG,ipt_limit,iptable_mangle,iptable_filter,ipt
ab
> le_nat
> e1000                  84788  0
> 
> And these all have the right vermagic
> 
> # strings `cat /tmp/modules` | grep vermagic
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> vermagic=2.6.10-x1d-p4 preempt PENTIUM4 gcc-3.3
> 
> # objdump -d `cat /tmp/modules` | grep -c cli
> 0
> 
> # objdump -d `cat /tmp/modules` | grep -c sti
> 2
> 
> Those two are clearly caused by bodged dissasembly, eg
> 
>  b65:   ff 8b 5c 24 38 85       decl   0x8538245c(%ebx)
>  b6b:   db 0f                   fisttpl (%edi)
>  b6d:   84 d2                   test   %dl,%dl
>  b6f:   fb                      sti
>  b70:   ff                      (bad)
>  b71:   ff 8b 43 04 85 c0       decl   0xc0850443(%ebx)
> 
> I built the kernel using debian's make-kpkg which I wouldn't have
> thought would have made a mistake.
> 
> Any other ideas?
> 
> This is kernel 2.6.10 running with xen 2.04.
> 
> --
> Nick Craig-Wood <nick@xxxxxxxxxxxxxx> --
http://www.craig-wood.com/nick
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


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