http://bugzilla.kernel.org/show_bug.cgi?id=10374 ------- Comment #8 from anonymous@xxxxxxxxxxxxxxxxxxxx 2008-04-01 14:14 ------- Reply-To: James.Bottomley@xxxxxxxxxxxxxxxxxxxxx On Tue, 2008-04-01 at 22:57 +0200, Jos van der Ende wrote: > On Tue, 01 Apr 2008 15:19:29 -0500 > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > That's odd ... it's behaving like a resource conflict. However, the > > ports and interrupt trace didn't betray anything. What does lspci -vv > > say for each of the devices? > > Output from lspci -vv attached. Thanks ... unfortunately looks normal too. The gem has a single memory region; the sym2 has 2 mem and one IO region, all of which show up in the /proc/iomem|ports. > > Also, if you remove the sym2 module in the > > problem case, does the sungem come back to life? > > No, once it is hosed it stays hosed until the next boot. Fiddling with the wrong ioports maybe? Yes ... that's what I guess. Just as one last grasp at a straw, is there any difference in /proc/iomem or /proc/ioports for the working case (sungem loaded first followed by sym2)? > > I'm afraid I can't see anything relevant looking over the sym2 changes, > > so you might need to bisect this to identify the culprit. > > Working on that, but it is a hassle as this bitty-box needs some time to compile a kernel. 2.6.23-rc1 didn't boot, for starters. Sorry ... can't think of much else that will help. James -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
