Getting closer: On 8/19/07, Florian Boelstler <[EMAIL PROTECTED]> wrote: > The actual problem lies in the NuBus slot probing code in > drivers/nubus/nubus.c > (which is way more down in the initialization process). > The system turns off, when the first NuBus slot (i.e. #9) is probed. > When the kernel is booted with nubus=off it shows the usual > frame-buffer-based boot messages. Though fails later on, when the > hardware is used (I guess).
Well, I fooled myself :) Since the PB1400 is still running Debian Sarge I was just using the native gcc/binutils (v3.3.5 / 2.15) to build a working kernel with debug outputs. I realized by comparing both outputs that even in that case no "cards" in the NuBus slots are found. This seems to be alright for a PB1400 (or a PB5300 I guess). Eventually it's the same if nubus=off is set for a working kernel. > Funny enough it's also related to some calls around hwreg_present() again. > It seems that hwreg_present() returns without error. It tries to > access the NuBus slot address with interrupts disabled. The > corresponding read operation on the register returns 0 (Is this is a > proper result? E.g. on PCI I would otherwise expect 0xFFFFFFFF. > NuBus-gurus, please come forward:). > The same read operation is done again on return of hwreg_present() > with interrupts enabled as part of the NuBus probing code. > This seems to be the trigger of system shutdown on my PB1400. The usual flow of operation doesn't expect that hwreg_present() returns true for any address of the given NuBus slots in driver/nubus/nubus.c on a PB1400 at all. Actually the exception handler is supposed to handle the invalid access. Using a special setjmp/longjmp implementation the code in hwreg_present() is tricked into returning 0 for any invalid access. The Nubus-PowerMac-specific handler is actually called by the central Machine Check Exception handler, however it never succeeds to jump back into hwreg_present() using nbpmac_longjmp(). Therefore I assume that either nbpmac_setjmp() or nbpmac_longjmp() is broken. Since it makes use of some tricky assembler code to jump back, I won't be surprised if both compilers generate different code. Cheers, Florian ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Nubus-pmac-users mailing list Nubus-pmac-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nubus-pmac-users
