Created attachment 7949 [details]
colon separated package listing

Created attachment 7950 [details]
lshw output

Created attachment 7951 [details]
lspci -vvv output

Created attachment 7952 [details]
kernel config with bug

(please reply via reply-to-all, rather than via bugzilla web forms)

bugme-daemon@bugzilla.kernel.org wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6439
> 
>            Summary: apic network smp problems
>     Kernel Version: 2.6.16.11
>             Status: NEW
>           Severity: normal
>              Owner: other_other@kernel-bugs.osdl.org
>          Submitter: dmlb2000@gmail.com
> 
> 
> Most recent kernel where this bug did not occur: 2.6.16.2
> Distribution: Source Mage GNU/Linux
> Hardware Environment: 
> dmlb2000@dmlb2000:~$ lspci
> 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4)
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP]
> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
> 00:07.1 IDE interface: VIA Technologies, Inc.
> VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
> 00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
> (rev 16)
> 00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
> (rev 16)
> 00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
> 00:09.0 Ethernet controller: Linksys NC100 Network Everywhere Fast Ethernet
> 10/100 (rev 11)
> 00:0a.0 Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 10)
> 00:0b.0 Mass storage controller: Silicon Image, Inc. PCI0680 Ultra ATA-133 Host
> Controller (rev 02)
> 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400]
> (rev a1)
> dmlb2000@dmlb2000:~$ lsmod
> Module                  Size  Used by
> ipt_MASQUERADE          3072  1 
> ipt_REJECT              4096  4 
> ipt_LOG                 5376  7 
> xt_tcpudp               3072  13 
> xt_state                1920  11 
> xt_pkttype              1792  4 
> iptable_raw             1792  0 
> xt_CLASSIFY             2048  0 
> xt_CONNMARK             2176  0 
> xt_connmark             1792  0 
> ipt_owner               1920  0 
> ipt_recent              8716  0 
> ipt_iprange             1792  0 
> xt_physdev              2192  0 
> ipt_policy              2816  7 
> ipt_multiport           2304  4 
> xt_conntrack            2176  0 
> iptable_mangle          2304  1 
> ip_nat_irc              2176  0 
> ip_nat_tftp             1664  0 
> ip_nat_ftp              2816  0 
> iptable_nat             6916  1 
> ip_nat                 13588  5 ipt_MASQUERADE,ip_nat_irc,ip_nat_tftp,ip_nat_ftp
> ,iptable_nat
> ip_conntrack_irc        5144  1 ip_nat_irc
> ip_conntrack_tftp       3348  1 ip_nat_tftp
> ip_conntrack_ftp        5660  1 ip_nat_ftp
> ip_conntrack           40280  13 ipt_MASQUERADE,xt_state,xt_CONNMARK,xt_connmark
> ,xt_conntrack,ip_nat_irc,ip_nat_tftp,ip_nat_ftp,iptable_nat,ip_nat,ip_conntrack_
> irc,ip_conntrack_tftp,ip_conntrack_ftp
> nfnetlink               4888  2 ip_nat,ip_conntrack
> iptable_filter          2432  1 
> ip_tables              10204  4 iptable_raw,iptable_mangle,iptable_nat,iptable_f
> ilter
> x_tables                9348  18 ipt_MASQUERADE,ipt_REJECT,ipt_LOG,xt_tcpudp,xt_
> state,xt_pkttype,xt_CLASSIFY,xt_CONNMARK,xt_connmark,ipt_owner,ipt_recent,ipt_ip
> range,xt_physdev,ipt_policy,ipt_multiport,xt_conntrack,iptable_nat,ip_tables
> nfsd                  182788  1 
> exportfs                4352  1 nfsd
> lockd                  49640  2 nfsd
> sunrpc                116516  2 nfsd,lockd
> ipv6                  203584  14 
> ext2                   49416  1 
> mbcache                 6404  1 ext2
> i2c_viapro              6932  0 
> via_agp                 7680  1 
> uhci_hcd               24848  0 
> 8139too                21248  0 
> 8250_pnp                8448  0 
> evbug                   2560  0 
> mii                     4352  1 8139too
> shpchp                 35552  0 
> pci_hotplug            21180  1 shpchp
> usbcore                95904  2 uhci_hcd
> evdev                   7040  0 
> tulip                  43424  0 
> agpgart                23240  1 via_agp
> psmouse                31496  0 
> serio_raw               5380  0 
> via686a                13448  0 
> hwmon                   2308  1 via686a
> i2c_isa                 3584  1 via686a
> i2c_core               15232  3 i2c_viapro,via686a,i2c_isa
> pcspkr                  2692  0 
> rtc                     9524  0 
> parport_pc             31728  0 
> parport                27848  1 parport_pc
> siimage                 9216  0 [permanent]
> floppy                 51920  0 
> 8250                   19180  1 8250_pnp
> serial_core            15104  1 8250
> I'll create more attachments with better output of hardware
> Software Environment:
> pretty standard basesystem gnu/linux distro...
> I'll attach a list of all packages and their versions
> 
> Problem Description:
> network doesn't send or recieve with 2.6.16.11 the other kernel I checked it
> with is 2.6.16.9 and the problems exists there too
> 
> dmlb2000@dmlb2000:~$ cat /proc/cmdline 
> root=/dev/hdb3 ro vga=791 noapic
> 
> I've tried removing the noapic but then the network devices don't even show up
> in ifconfig -a on any of the kernels including the one I'm running now.
> 
> The problem with 2.6.16.9 and above seems (when passing noapic) that there isn't
> any traffic sent over my network sending or recieving on any interface (there's
> two). I can assign ip addresses and create routes but no traffic is sent.
> 
> all these problems disapear when I remove smp, apic and local apic.
> 
> Steps to reproduce:
> 1) compile smp kernel 2.6.16.9 or above on my hardware
> 2) boot the new kernel
> 
> I'm kind of disapointed that a 'maintenance/security fix' crippled my system,
> how did this happen?
> 

I've looked back through the 2.6.16.3->2.6.16.9 changelogs and cannot
immediately see anything which could have caused this.

Are you really sure that 2.6.16.3 worked OK?  If so, are you able to
pinpoint a particular release which caused the regression?

Thanks.

On Tue, Apr 25, 2006 at 03:25:24PM -0700, Andrew Morton wrote:
> I've looked back through the 2.6.16.3->2.6.16.9 changelogs and cannot
> immediately see anything which could have caused this.

I don't either.  Any way you can use git to bisect the different patches
between 2.6.16.3 and 2.6.16.11?  There are not many at all so it
shouldn't take very long to narrow it down.

Andrew, so I'm supposed to reply via email? and not use the fine bugzilla web
interface? ;)

Also I narrowed it down to between 16.8-9... so 2.6.16.8 works and 2.6.16.9
doesn't work.

There's a lot in that patch where should I start ripping it apart?

> I've looked back through the 2.6.16.3->2.6.16.9 changelogs and cannot
> immediately see anything which could have caused this.
>
> Are you really sure that 2.6.16.3 worked OK?  If so, are you able to
> pinpoint a particular release which caused the regression?

Okay, after about 20+ kernel compiles of differing versions and
differing reverse patches 2.6.16.11 seems to work okay, just as it is,
meaning this bug is invalid.

I compiled manually instead of using the package manager to make the
tests faster and it seems that's what was making everything work.

I'm testing this very thing now.

In the package there are several environmental vars set when going
through the compile (LDFLAGS, CFLAGS, CPPFLAGS, CXXFLAGS, etc).  These
are the only things I can figure breaking the kernel.  These flags
also change and can various user defined options.  I know compiling
for a ppc the kernel will not link if LDFLAGS has -s in it.

Since, I'm also the maintainer of this package, should the package
just unset all those variables for every arch just to be safe?

- David Brown

Okay now I can't reproduce the problem...
and since everything works no sense in keeping the bug around...
/me is thoroughly confused...