Am 05.06.2008 um 16:31 schrieb Andrew Doran:
Didn't help much - now it waits longer (actually until the KITT phase), but still reset rejected. Could this be an endian issue despite the letoh32/htole32 conversion? Anyway, since the exit code is 0x0 and not IOP_RESET_REJECTED, I changed iop.c to ignore the status if it's 0...On Wed, Jun 04, 2008 at 07:55:06PM +0200, Jan-Hinrich Fessel wrote:during reset: 8+7+5+3+2 8+7+3+2 IRQ+8+2+1 IRQ+1 (8 or IRQ)+5+4+1 OFF (8 or IRQ)+5 (8 or IRQ)+5+3+2+1 3+2+1 5+4+3+2+1 ALL ALL-1 KITT (until powerdown) Legend: (8 or IRQ) means, i couldnt determine wether it is LED 8 or LED IRQ. But always the same is lit. KITT is like Knight Riders Carswinging from left to right and back. Correlation is a bit difficult,but I think only the first two or threee states occur before the kernel returns the reset rejected. So it looks like the kernel doesn't wait for the board to reset...It looks like the board actually did reset OK. Can you give this patch a try? http://www.netbsd.org/~ad/iop.c.diff Andrew
Now I get:Distributed Processing Technology Memory Controller (miscellaneous memory, revision 0x02) at pci2 dev 3 function 0 not configured iop0 at pci2 dev 4 function 0: I2O adapteriop0: reset rejected, status 0x0
iop0: STATUS_GET timed out iop0: not responding (get status) which doesn't really bring us that much progress.What next - and I already exchanged the controller for a known good unit...
Cheers
Oskar
Attachment:
PGP.sig
Description: This is a digitally signed message part