On Mon, 11 Aug 2008 07:45:53 +0200 Pierre Ossman <drzeus@xxxxxxxxx> wrote: > On Sun, 10 Aug 2008 13:53:44 -0700 > Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > (switched to email. Please respond via emailed reply-to-all, not via the > > bugzilla web interface). > > > > On Sun, 10 Aug 2008 13:45:49 -0700 (PDT) bugme-daemon@xxxxxxxxxxxxxxxxxxx wrote: > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=11302 > > > > > > Summary: I get a kernel OOPS! If I try to attach an usb card > > > reader, SD, MMC, ecc.. to my Slamd64 > > > Product: IO/Storage > > > Version: 2.5 > > > KernelVersion: 2.6.26.2 > > > Platform: All > > > OS/Version: Linux > > > Tree: Mainline > > > Status: NEW > > > Severity: blocking > > > Priority: P1 > > > Component: SCSI > > > AssignedTo: linux-scsi@xxxxxxxxxxxxxxx > > > ReportedBy: pinc_o@xxxxxxxx > > > > Is this a scsi regresion, or an mmc regression? > > OK. There have been some regressions in the scsi area but I thought that a) they were fixed and b) none manifested as an oops in slave_alloc(). Perhaps James can take a look please? > There are no USB based "real" MMC controllers, so I'd say SCSI. > > > > If attach my usb card reader, without load mmc_block an mmc_core modules, then > > > the follow OOPS appear(If first load them, simply doesn't mount the SD. Please > > > note: I always use "automatic loading kernel modules" compiled in "my" kernelS. > > > But from many time, the recent kernelS not load the mmc_block module): > > I don't know what kind of weird ass scripts loaded them for USB mass > storage to begin with. As for the claimed lack of crashes when loaded; > no idea as there is no interaction between the SCSI and MMC layer. > > > > Modules linked in: nvidia(P) [last unloaded: nvidia] > > This is always a good start.. I very much doubt it. Paolo, can you please check to see if the crash happens in a kernel into which the nvidia driver has never been loaded? -- 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
