re: pegasosII crash at boot with -current
matthew green <[email protected]> Thu, 25 Nov 2010 06:32:58 +1100
| Newsgroups | gmane.os.netbsd.ports.ofppc |
|---|---|
| Message-ID | <[email protected]> |
> Matthew Green wrote: > > > i finally got around to trying my pegasosII with -current and it fails > > to boot. > > How current is your current? Mine is 6 days old, and a generic ofppc kernel > boots on my Pegasos2/G3 with 512MB. it was only a couple of hours old at that point. i tried with both 1GB and 512MB installed, and also by disabling the hack to find all the memory that the prom didn't tell us about. same problem. > > i get this: > > > >>> NetBSD/ofppc OpenFirmware Boot, Revision 1.8 > > It probably isn't important, but the recent revision is 1.11. i'll try updating this. > Did you boot the kernel from disk or over the net (100MBit or GBit-port?)? both. didn't matter. > > anyone have any ideas what is up? > > Not really. The only difference between our systems is that you have a G4 > and I have a G3. > > It worked for you in the past? i haven't booted this system since april 2008, but yeah, it very much worked in the past, and the old install works (netboot or disk boot.) > Did you already test a kernel after the switch from pegasospci to gtpci? nope. > Since the last months I get kernel panics when an USB device is plugged in. > I don't know if there was a modification in some USB code or whether it is > caused by a problem with gtpci: > > 0xa9f26bd0: at panic+0x25c > 0xa9f26c20: at trap+0x128 > 0xa9f26cb0: kernel DSI read trap @ 0xba938101 by usb_allocmem+0xb0: > srr1=0x9032 > r1=0xa9f26d70 cr=0x84000088 xer=0 ctr=0x3fe620 dsisr=0x40000000 > 0xa9f26d70: at usbd_do_request_flags_pipe+0xe8 > 0xa9f26da0: at uhci_open+0x5f4 > 0xa9f26de0: at usbd_setup_pipe+0xbc > 0xa9f26e10: at usbd_new_device+0x480 > 0xa9f26eb0: at uhub_explore+0x1f4 > 0xa9f26f00: at usb_discover+0x60 > 0xa9f26f20: at usb_event_thread+0x38 > 0xa9f26f40: at emptyidlespin+0x10 > > Kiyohara-san wanted to have a look at it... ;) i've seen panics like this on my netbsd-5 amd64 desktop. my netbsd-5 tree has extra instrumentation around the code here, it shows that an alloc fails, and then the code goes bad.. but i haven't figured out much more than this about it yet. thanks. .mrg.