[9fans] panic

[9fans] panic

[Frank Lenaerts]

Hi,

Yesterday, I downloaded the Plan 9 live CD and tried to boot it on a
Fujitsu-Siemens Scenic PC (which is about 2 years old). Unfortunately,
booting from the CD fails:

--- begin ---
...
<menu>
...
Plan 9
E820: ...
<several E820: lines>
panic: vmap: va=0xf0400000 pa=0x00400000 pde=0x00400083
panic: vmap: va=0xf0400000 pa=0x00400000 pde=0x00400083
dumpstack disabled
cpu0: exiting
---  end  ---

Not knowing where to start looking for the possible cause, I just
googled for the panic line and found a post in an old archive[*]. This
person mentions that in his case the everything seemed ok when
*noe820scan is specified. 

As this machine does not have a floppy drive and I do not want to burn
a new CD just to modify plan9.ini, I tried to boot the system using
PXE (from a Linux machine running a dhcp and tftp server). The
intention was to get 9pxeload to load a plan9.ini file from the Linux
machine and to then continue booting from the CD (i.e. trying to pass
the *noe820scan to the kernel).

To do this, I did the following:

- configured the dhcp server (MAC, filename...)
- put 9pxeload in place
- modified plan9.ini so that it contains *noe820scan and renamed it to
  the MAC address of the NIC

Booting the PC using PXE loads 9pxeload but the plan9.ini file is not
found:

--- begin ---
initial probe, to find plan9.ini...pcirouting: ...

Boot devices: fd0
boot from: 
---  end  ---

The 9load manpage says that the file should be put in /cfg/pxe (which
I then created under /tftpboot on the Linux box). I thought that
9pxeload would request /cfg/pxe/<MAC> using TFTP but even that does
not seem to be the case i.e. it seems as if 9pxeload doesn't request
any file using TFTP... Could somebody explain me how it is supposed to
work?

[*] http://lists.cse.psu.edu/archives/9fans/2006-July.txt


Kind regards,

-- 
Frank Lenaerts ---------------------------------------- frank@inua.be

Re: [9fans] panic

[erik quanstrom]

i think this is realted to recient problems with huge kernels.

- erik

Re: [9fans] panic

[Tim Wiess]

> i think this is realted to recient problems with huge kernels.

    actually this looks like something different. i never got a panic
    with the previous issue, the kernel just hung after it was loaded.
    unless Andrey saw something different....

Re: [9fans] panic

[erik quanstrom]

it's a little different symptom, but the same root cause.
i saw this error on my machine yesterday.

- erik

On Wed Nov 21 12:32:22 EST 2007, tim@nop.cx wrote:
> > i think this is realted to recient problems with huge kernels.
> 
>     actually this looks like something different. i never got a panic
>     with the previous issue, the kernel just hung after it was loaded.
>     unless Andrey saw something different....
> 

Re: [9fans] panic

[Frank Lenaerts]

On Wed, Nov 21, 2007 at 05:29:26PM +0100, Frank Lenaerts wrote:
Hi,

Apart from the original problem (the panic), where should I put the
plan9.ini style file when booting via PXE from a non-Plan 9
(e.g. Linux) box. Would 9pxeload look for the file in /cfg/pxe under
the tftp root directory (e.g. /tftpboot)?

> As this machine does not have a floppy drive and I do not want to burn
> a new CD just to modify plan9.ini, I tried to boot the system using
> PXE (from a Linux machine running a dhcp and tftp server). The
> intention was to get 9pxeload to load a plan9.ini file from the Linux
> machine and to then continue booting from the CD (i.e. trying to pass
> the *noe820scan to the kernel).
> 
> To do this, I did the following:
> 
> - configured the dhcp server (MAC, filename...)
> - put 9pxeload in place
> - modified plan9.ini so that it contains *noe820scan and renamed it to
>   the MAC address of the NIC
> 
> Booting the PC using PXE loads 9pxeload but the plan9.ini file is not
> found:
> 
> --- begin ---
> initial probe, to find plan9.ini...pcirouting: ...
> 
> Boot devices: fd0
> boot from: 
> ---  end  ---
> 
> The 9load manpage says that the file should be put in /cfg/pxe (which
> I then created under /tftpboot on the Linux box). I thought that
> 9pxeload would request /cfg/pxe/<MAC> using TFTP but even that does
> not seem to be the case i.e. it seems as if 9pxeload doesn't request
> any file using TFTP... Could somebody explain me how it is supposed to
> work?

-- 
Frank Lenaerts ---------------------------------------- frank@inua.be

Re: [9fans] panic

[erik quanstrom]

> Sorry about that.  We're soaking a version of the kernel that includes
> a reference count in the Block struct.  It's so far used by the
> Ethernet drivers, IP stack and USB code, and usbohci.c escaped a
> little too early.
>
> I've just pushed out a newer allocb.c to sources that initializes the
> refence count at allocation.

the new version of port/allocb.c panics my terminal early in the boot
process.  unfortunately, i'm going to have to buy another serial card
to debug this, so i won't have any information for a while.  what i
do know is the panic is "ref -1" from freeb and the caller is readq.

- erik

[9fans] panic

[Markus Sonderegger]

hi,
i got the following panic in a kernel I compiled today:

	panic: D2B called on non-block f0d72af8 (double-free?)
	panic: D2B called on non-block f0d72af8 (double-free?)
	dumpstack disabled
	cpu0: exiting

it happen evertime i plug a usb device in. i don't know how
to debug this. any suggestions?
with my old kernel(2008-04-30) everthing works fine.

markus

Re: [9fans] panic

[geoff]

Sorry about that.  We're soaking a version of the kernel that includes
a reference count in the Block struct.  It's so far used by the
Ethernet drivers, IP stack and USB code, and usbohci.c escaped a
little too early.

I've just pushed out a newer allocb.c to sources that initializes the
refence count at allocation.

Re: [9fans] panic

[erik quanstrom]

> hi,
> i got the following panic in a kernel I compiled today:
>
> 	panic: D2B called on non-block f0d72af8 (double-free?)
> 	panic: D2B called on non-block f0d72af8 (double-free?)
> 	dumpstack disabled
> 	cpu0: exiting
>
> it happen evertime i plug a usb device in. i don't know how
> to debug this. any suggestions?
> with my old kernel(2008-04-30) everthing works fine.

it's very difficult to say without access to
a) the stack dump and
b) the kernel in question.
this is because it's hard to find this sort of problem without
knowing where the problem occurred.  the stack dump
will provide addresses and the kernel image will be
enough to tie addresses to particular bits of code.

as an unrelated aside, this reference counting updates uninitialized memory.

/n/sources/plan9/sys/src/9/pc/usbohci.c:1454,1455
	if(dirin == Dirout && bp)
		_xinc(&bp->ref);

since the definition for _allocb is so

	if((b = mallocz(sizeof(Block)+size+Hdrspc, 0)) == nil)
		return nil;

	b->next = nil;
	b->list = nil;
	b->free = 0;
	b->flag = 0;
[...]

either the unused reference counting needs to be dropped, usbohci
needs to initialize its own reference count or _allocb needs to initialize
it to 1.  i assume the reason blocks are not zeroed is for performance
reasons.

i'm not sure i understand a reference count for a Block, since i thought
part of deal was that each Block has a unique owner.  am i wrong?

- erik