On Wed, Mar 26, 2008 at 10:20:35AM -0600, Grant Grundler wrote: > Another gcc problem report: > > That past weekend I built the latest parisc-2.6-25-rc6 kernel from > Kyle's tree using gcc-4.1, gcc-4.2, and gcc-4.3. All three kernels > booted but the networking only worked for gcc-4.1 kernel.
Followup: gcc-42 is working too now and I'm not sure why. I upgraded gcc-4.3 package from 4.3.0-rcX to 4.3.1 AND all of it's dependencies as well. I looked at gcc-43 build output to check warnings related to networking as suggest by John David Anglin. I ignored the couple of warnings in drivers/net/wireless/. CC [M] drivers/net/fealnx.o drivers/net/fealnx.c:896:2: warning: #warning Processor architecture undefined! No clue what this driver is for. Ignored. CC [M] drivers/net/lasi_82596.o drivers/net/lasi_82596.c: In function ???lan_init_chip???: drivers/net/lasi_82596.c:164: warning: format ???%lx??? expects type ???long unsigned int???, but argument 3 has type ???resource_size_t??? drivers/net/lasi_82596.c:169: warning: format ???%lx??? expects type ???long unsigned int???, but argument 2 has type ???resource_size_t??? That's just printk format strings. overshot and found this one in drivers/scsi/ interesting too: drivers/scsi/initio.c:2585: warning: large integer implicitly truncated to unsigned type matching code is: cblk->senselen = cpu_to_le32(SENSE_SIZE); [EMAIL PROTECTED]:~/parisc-2.6-gcc43$ fgrep senselen drivers/scsi/*.h drivers/scsi/aha1740.h: u8 senselen; /* Sense Length */ drivers/scsi/initio.h: u8 senselen; /*31 Sense Allocation Length */ drivers/scsi/megaraid.h: u8 reqsenselen; The code at first glance looks wrong here. Patch submitted to linux-scsi and Alan Cox (who appears to have taken on this driver last year). Nothing else in the drivers/net. A bit more in net/ though: CC net/sunrpc/svc.o net/sunrpc/svc.c: In function ???__svc_create_thread???: net/sunrpc/svc.c:587: warning: ???oldmask.bits[0u]??? may be used uninitialized in this function Don't care since I'm not using rpc. This is probably a false positive anyway. I've found several. And that was it. So no warnings that seem to be related to this networking problem. It was worth checking though. > I just realized it's possible the 100BT switch is dropping the packets. > I'll try to capture a tcpdump from the omnibook 500 side using a > crossover cable tonight or tomorrow since without that, I don't see > how this can be debugged. Still need to try the cross-over cable. grant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]