Every time I insert my (new) microdrive, I get this "kernel BUG at sched.c 1141" message and a kernel panic (process swapper, invalid operand 0000). The magic SysReq key works (except sync), but otherwise the system is completely frozen. Unfortunately, kern.log is incomprehensible. Some random junk gets dumped there (different every time; I tried 6-7 times...). I'm not quite sure who's at fault, because I get this error /sbin/runscript.sh: line 527: 1018 Segmentation fault /sbin/modprobe pcmcia_core $CORE_OPTS 2>/dev/null when I run "/etc/init.d/pcmcia start" the first time after boot. Interestingly, there are no error messages when I insert the modules and start cardmgr by hand. Neither do I get this message on restart (i.e. "/etc/init.d/pcmcia restart"). On the other hand, irrespective of how I start the pcmcia daemon (i.e. modprobe pcmcia_core; modprobe i82365; modprobe ds; cardmgr or /etc/init.d/pcmcia start), I always get the kernel BUG/panic when I insert the microdrive. The hardware itself is OK. The microdrive works in my camera, and in the same pcmcia slots using the original OS on the laptop. (-; Also, I had a cdrom drive attached via the same pccard slot, and that works without a hitch. I don't know. Perhaps, something's odd with the hotplug and/or the pcmcia scripts; but those are original "Gentoo", IIRC. Reproducible: Always Steps to Reproduce: 1./etc/init.d/pcmcia start (or insert modules and start cardmgr "manually") 2.insert microdrive (with or without pccard adapter) in the pcmcia or cf slot 3. Actual Results: The builtin WLAN "pccard" usually registers OK. The microdrive is correctly identified, but the kernel panics during the ide attach procedure. Expected Results: Well... work as usual. (-;
*** This bug has been marked as a duplicate of 26967 ***
Created attachment 16741 [details] ksymoops analysis for pcmcia-related kernel oops
This does *not* appear to me a duplicate to me. Not only are the symptoms significantly different (i.e. note that the other guys get the Oops when they _remove_ an ide_cs device), but the resolution doesn't help in my case, either. With the fix in sched.c, the machine freezes without an explicit kernel panic. I do, however, get a non-fatal kernel Oops when I start pcmcia (no ide card inserted). Ill create an attachment with the ksymoops output.
I assume this doesn't happen with a vanilla kernel...? What random junk do you get? ... Can you please take a photo of it or something? The kernel oops will be different and might lead somewhere else. The attached ksymoops output doesn't look like a scheduler bug but a kernel PCMCIA bug. Can you check if you have any conflicting IRQs? I assume you are using gentoo-sources -r6?
Hmm... maybe I'm just being too quick (and stupid). I should probably re-emerge pcmcia-cs... BTW, what's wrong with the kernel's own pcmcia support? Why does Gentoo suggests not to use it?
Nothing's wrong with the support. From what I've seen and just debugged, it looks like you are using external pcmcia-cs. The internal support is fine as far as I know, try that instead. Ideally, you should use the kernel PCMCIA support and use pcmcia-cs to manage the PCMCIA devices... Try the latest pcmcia-cs...
Yes, I'm using gentoo-r6. I'll try with the vanilla sources. The "random junk" that lands in /var/log/kern.log has no relation to the actual kernel panic displayed on the screen. I can include an instance for your viewing pleasure, but I think you'd really be more interested in getting the actual kernel oops output. I'll get back with that tomorrow (it's 1:41am right here). As far as conflicting IRQs are considered, I'll try to check, but that will require a bit of research...
Created attachment 16783 [details] kernel oops from 2.4.20-gentoo-r6 with kernel-based pcmcia and original sched.c OK. Now, I've tried using the builtin pccard support from the kernel. The results are pretty much the same: - with the original sched.c I get a kernel oops (see the attached ksymoops output for the oops I transcribed from a photo); - with the "patch" at 1140/1141 there's no kernel oops output (nothing in kern.log either unfortunately), but the system freezes up all the same. The only difference is that the pcmcia modules now load without a problem (no core dump, no kernel oops). I've also tried playing around with irq, memory, and ioport settings in /etc/pcmcia/config.opts, but I haven't managed to get a working configuration. At one point I happened to disable all the ioports, and then inserting and ejecting cards worked fine, but that's because they didn't get assigned any resource. This would seem to indicate that the problem may indeed relate to irq/io/memory settings (or rather probing odd ranges), but I have no desire to experiment with this any longer, because I also tried the vanilla-sources (with the kernel-based pcmcia modules), and everything works fine. I guess, I'll stick with that for now. BTW, originally I was going to use the kernel pcmcia drivers, but when I emerged pcmcia-cs, the post-install blurp said that I should disable pcmcia support in the kernel and use the drivers from that package (at least that's how I understood)...
Just added an attachment with a long comment. It did show up on the web, but Bugzilla complained (see below), and I never got a mail about it; hence, this comment. (^; -------------------------------------- Attachment #16783 [details] to Bug #27448 Created Status: 400 Bad request (malformed multipart POST) Content-type: text/html Software error: Undefined subroutine &main::ThrowCodeError called at Bugzilla/CGI.pm line 78. For help, please send mail to the webmaster (webmaster@gentoo.org), giving this error message and the time and date of the error. Content-type: text/html Software error: [Fri Aug 29 14:16:23 2003] processmail: Undefined subroutine &main::ThrowCodeError called at Bugzilla/CGI.pm line 78. Compilation failed in require at ./processmail line 31. For help, please send mail to the webmaster (webmaster@gentoo.org), giving this error message and the time and date of the error. --------------------------------------
See if disabling preemptive kernel and adding that patch helps.
Disabling preemptible kernel works; no need for the patch.
Resolving as fixed.
