(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 1 Apr 2008 01:01:22 -0700 (PDT) bugme-daemon@xxxxxxxxxxxxxxxxxxx wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=10374 > > Summary: sym53c8xx: weird behavior with udev > Product: Drivers > Version: 2.5 > KernelVersion: 2.6.24.4 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: drivers_other@xxxxxxxxxxxxxxxxxxxx > ReportedBy: seraph@xxxxxxxxx > > > Latest working kernel version: 2.6.22.9 > Earliest failing kernel version: 2.6.23 > Distribution: Gentoo > Hardware Environment: sparc64 (Sun Blade 100) > Software Environment: > Problem Description: > > Since kernel 2.6.23, I have been having problems getting the sungem network > device working on one of my two Blade 100s, see bug #10273. > > After debugging this, I found that this seems to be somehow related to > sym53c8xx and udev. > > If I allow udev to load sym53c8xx during boot, the attached disks work fine but > the network does not work at all. While the device is up and mii-diag says > there is link beat, no packets can be sent or received, and attempts to use the > network result in "network unreachable" errors. > > If I blacklist sym53c8xx in /etc/modprobe.d/blacklist, let the machine boot > normally and then manually load sym53c8xx after everything is settled, both the > scsi disks and the network appear to work fine. > > None of this happened in kernel versions 2.6.22.9 and earlier, 2.6.23 was the > first to start showing this behavior, and it still persists in 2.6.24. > > I've tried playing with the option CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE as > that is what seems to have changed between kernel versions 2.6.22 and 2.6.23. > The recommended value for my machine is 0, but I have tried the other possible > values without result. I have also tried toggling CONFIG_SCSI_SYM53C8XX_MMIO, > also without result. > > Steps to reproduce: > > Let udev load sym53c8xx in kernel 2.6.23 or newer. urgh. Perhaps it's related to platform IRQ routing or something. I'd suggest that the next step would be to send us the `dmesg -s 1000000' output for both good and bad kernels. A comparison might show where things went bad. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
