[9fans] unable to start plan9 on atom330 in virtualbox

[9fans] unable to start plan9 on atom330 in virtualbox

[Cr0t]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 71 bytes --]

I am unable to load plan9 on the latest version of virtualbox.

  - C

[-- Attachment #2: Type: IMAGE/jpeg, Size: 175088 bytes --]

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Jacob Todd]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

Plan 9 hasn't worked with virtual box for as long as i can remember. Try it
with qemu if you can.
On Jun 11, 2011 5:58 PM, "Cr0t" <cr0txxx@gmail.com> wrote:
> I am unable to load plan9 on the latest version of virtualbox.
>
> - C

[-- Attachment #2: Type: text/html, Size: 375 bytes --]

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Gorka Guardiola]

On Sun, Jun 12, 2011 at 12:15 AM, Jacob Todd <jaketodd422@gmail.com> wrote:
> Plan 9 hasn't worked with virtual box for as long as i can remember. Try it
> with qemu if you can.
>
> On Jun 11, 2011 5:58 PM, "Cr0t" <cr0txxx@gmail.com> wrote:
>> I am unable to load plan9 on the latest version of virtualbox.
>>
>> - C
>

I've been using virtualbox on linux and mac os for a long time.
The only issues I have found have been with the ps/2 mouse emulation
on mac os. You can try the image we have for our students here:
http://lsub.org/plan9alv.tgz

--
- curiosity sKilled the cat

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[blstuart]

> I've been using virtualbox on linux and mac os for a long time.
> The only issues I have found have been with the ps/2 mouse emulation
> on mac os. You can try the image we have for our students here:
> http://lsub.org/plan9alv.tgz

You might give the latest version for mac os a try.  I've noticed some
significant improvement in the mouse behavior in it.

BLS

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Cr0t daywalker]

[-- Attachment #1: Type: text/plain, Size: 349 bytes --]

I saw screenshots that it does work

On Jun 11, 2011, at 6:16 PM, Jacob Todd <jaketodd422@gmail.com> wrote:

Plan 9 hasn't worked with virtual box for as long as i can remember. Try it
with qemu if you can.
On Jun 11, 2011 5:58 PM, "Cr0t" <cr0txxx@gmail.com> wrote:
> I am unable to load plan9 on the latest version of virtualbox.
>
> - C

[-- Attachment #2: Type: text/html, Size: 715 bytes --]

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Gorka Guardiola]

On Sun, Jun 12, 2011 at 1:25 AM, Cr0t daywalker <cr0txxx@gmail.com> wrote:
> I saw screenshots that it does work
>

In case it helps, I use the version you can find here:
http://www.virtualbox.org/wiki/Downloads

and the USB extension pack here:
http://www.virtualbox.org/wiki/Downloads

USB support in MacOs is somewhat flaky, but works most of the time for
mice and usb disks.

G.

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[cinap_lenrek]

just tried vbox 4.0.8-r71778 under windows with 9front and
it seems to install and boot the latest build just fine.
(except that vbox seems to measure its performance in popups
per minute)

i had some wired i/o errors tho when i had the iso image stored
on smb server after some time. maybe a bug in cifsd...

just copying the iso to a windows harddrive fixed it.

where does plan9 fail to work? can it start the kernel?
we use a different bootloader so i would suspect a 9load
problem...

can you make a screenshot?

--
cinap

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Robert Ransom]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

On Sun, 12 Jun 2011 01:40:42 +0200
cinap_lenrek@gmx.de wrote:

> where does plan9 fail to work? can it start the kernel?
> we use a different bootloader so i would suspect a 9load
> problem...
> 
> can you make a screenshot?

He attached one to his original message.


Robert Ransom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 499 bytes --]

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[cinap_lenrek]

oh, got it...

so 9load is not the problem...

sorry for the noise

--
cinap

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Cr0t daywalker]

[-- Attachment #1.1: Type: text/plain, Size: 659 bytes --]

©®0t



On Sat, Jun 11, 2011 at 7:40 PM, <cinap_lenrek@gmx.de> wrote:

> just tried vbox 4.0.8-r71778 under windows with 9front and
> it seems to install and boot the latest build just fine.
> (except that vbox seems to measure its performance in popups
> per minute)
>
> i had some wired i/o errors tho when i had the iso image stored
> on smb server after some time. maybe a bug in cifsd...
>
> just copying the iso to a windows harddrive fixed it.
>
> where does plan9 fail to work? can it start the kernel?
> we use a different bootloader so i would suspect a 9load
> problem...
>
> can you make a screenshot?
>
> --
> cinap
>
>

[-- Attachment #1.2: Type: text/html, Size: 988 bytes --]

[-- Attachment #2: vp.jpg --]
[-- Type: image/jpeg, Size: 110040 bytes --]

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[cinap_lenrek]

i would like to resolve the addresses printed in the screenshot.

is this the plan9 live cd? how do i extract that kernel image from the
cd? (or extract the floppy image) or does anyone have the debug versions
of the kernels that get build into the plan9 cd?

--
cinap

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Cr0t daywalker]

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]

Yes, it is from the latest live cd.

©®0t



On Sat, Jun 11, 2011 at 8:32 PM, <cinap_lenrek@gmx.de> wrote:

> i would like to resolve the addresses printed in the screenshot.
>
> is this the plan9 live cd? how do i extract that kernel image from the
> cd? (or extract the floppy image) or does anyone have the debug versions
> of the kernels that get build into the plan9 cd?
>
> --
> cinap
>
>

[-- Attachment #2: Type: text/html, Size: 719 bytes --]

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Iruatã Souza]

On Sat, Jun 11, 2011 at 9:32 PM,  <cinap_lenrek@gmx.de> wrote:
> i would like to resolve the addresses printed in the screenshot.
>
> is this the plan9 live cd? how do i extract that kernel image from the
> cd? (or extract the floppy image) or does anyone have the debug versions
> of the kernels that get build into the plan9 cd?
>

https://bitbucket.org/iru/depot/src/12ff017cc9c6/cdfpart creates a
cdboot partition for the emulated floppy in the cd.

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[cinap_lenrek]

excellent, thanks

--
cinap

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[cinap_lenrek]

ok, i think i can explain the "unlock of ilock: pc f0140fc5, held by ..." message.

i extracted that 9pcflop kernel with muzgos cdfpart from the current iso and
disassembled with acid arround.

the routine that calls unlock looks like this:

the routine that calls the unlock (shutdown from ether79c970.c)
0xf0140f79 0xf0140f79	SUBL	$0x14,SP
0xf0140f7c 0xf0140f7c	MOVL	0x18(SP),AX
# ctlr = arg->foobar
0xf0140f80 0xf0140f80	MOVL	0x78(AX),CX
0xf0140f83 0xf0140f83	MOVL	CX,0x10(SP)
0xf0140f87 0xf0140f87	MOVL	CX,0x0(SP)
# ilock(ctlr)
0xf0140f8a 0xf0140f8a	CALL	0xf019af31
0xf0140f8f 0xf0140f8f	MOVL	0x10(SP),AX
0xf0140f93 0xf0140f93	MOVL	AX,0x0(SP)
0xf0140f96 0xf0140f96	MOVL	$0x18,AX
0xf0140f9b 0xf0140f9b	MOVL	AX,0x4(SP)
# io32r(ctlr, 0x18) ???
0xf0140f9f 0xf0140f9f	CALL	0xf01409b4
0xf0140fa4 0xf0140fa4	MOVL	0x10(SP),AX
0xf0140fa8 0xf0140fa8	MOVL	AX,0x0(SP)
0xf0140fab 0xf0140fab	MOVL	$0x18,AX
0xf0140fb0 0xf0140fb0	MOVL	AX,0x4(SP)
# io16r(ctlr, 0x18);
0xf0140fb4 0xf0140fb4	CALL	0xf014093f
0xf0140fb9 0xf0140fb9	MOVL	0x10(SP),AX
0xf0140fbd 0xf0140fbd	MOVL	AX,0x0(SP)
# unlock(ctlr)
0xf0140fc0 0xf0140fc0	CALL	0xf019b0be
0xf0140fc5 0xf0140fc5	ADDL	$0x14,SP
0xf0140fc8 0xf0140fc8	RET

it have no debug symbols so i looked for magic numbers
arround (in this case 0x18)

wich turned out to be:

ether79c970.c:31: 	Sreset		= 0x0018,	/* software reset */

# this looks like io32r() from ether79c970.c
acid: asm(0xf01409b4)
0xf01409b4 0xf01409b4	SUBL	$0x8,SP
0xf01409b7 0xf01409b7	MOVL	0xc(SP),CX
# port = arg2
0xf01409bb 0xf01409bb	MOVL	0x1c(CX),CX
# port += arg1
0xf01409be 0xf01409be	ADDL	0x10(SP),CX
0xf01409c2 0xf01409c2	MOVL	CX,0x0(SP)
# inl(port)
0xf01409c5 0xf01409c5	CALL	0xf010036e
0xf01409ca 0xf01409ca	ADDL	$0x8,SP
0xf01409cd 0xf01409cd	RET

# this is inl()
acid: asm(0xf010036e)
0xf010036e 0xf010036e	MOVL	0x4(SP),DX
0xf0100372 0xf0100372	INL	DX,AX
0xf0100373 0xf0100373	RET

so there is your bug!

static void
shutdown(Ether *ether)
{
	Ctlr *ctlr;

	ctlr = ether->ctlr;
	ilock(ctlr);
	io32r(ctlr, Sreset);
	io16r(ctlr, Sreset);
	unlock(ctlr);
}

it was commented out before...

the file just changed... i think they try to fix it right now...

--
cinap

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[cinap_lenrek]

to be clear, the shutdown() code was missing in *current* ether79.... i found it
in history -D, and now its there again.

--
cinap

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[cinap_lenrek]

it would be nice if geoff can keep the kernel versions on the live cd
current and have a unstriped version (with debug symbols) of it on
sources.

--
cinap

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Cr0t]

You are right. Neither one of the AMD nics are working!


On Mon, 13 Jun 2011, cinap_lenrek@gmx.de wrote:

> ok, i think i can explain the "unlock of ilock: pc f0140fc5, held by ..." message.
>
> i extracted that 9pcflop kernel with muzgos cdfpart from the current iso and
> disassembled with acid arround.
>
> the routine that calls unlock looks like this:
>
> the routine that calls the unlock (shutdown from ether79c970.c)
> 0xf0140f79 0xf0140f79	SUBL	$0x14,SP
> 0xf0140f7c 0xf0140f7c	MOVL	0x18(SP),AX
> # ctlr = arg->foobar
> 0xf0140f80 0xf0140f80	MOVL	0x78(AX),CX
> 0xf0140f83 0xf0140f83	MOVL	CX,0x10(SP)
> 0xf0140f87 0xf0140f87	MOVL	CX,0x0(SP)
> # ilock(ctlr)
> 0xf0140f8a 0xf0140f8a	CALL	0xf019af31
> 0xf0140f8f 0xf0140f8f	MOVL	0x10(SP),AX
> 0xf0140f93 0xf0140f93	MOVL	AX,0x0(SP)
> 0xf0140f96 0xf0140f96	MOVL	$0x18,AX
> 0xf0140f9b 0xf0140f9b	MOVL	AX,0x4(SP)
> # io32r(ctlr, 0x18) ???
> 0xf0140f9f 0xf0140f9f	CALL	0xf01409b4
> 0xf0140fa4 0xf0140fa4	MOVL	0x10(SP),AX
> 0xf0140fa8 0xf0140fa8	MOVL	AX,0x0(SP)
> 0xf0140fab 0xf0140fab	MOVL	$0x18,AX
> 0xf0140fb0 0xf0140fb0	MOVL	AX,0x4(SP)
> # io16r(ctlr, 0x18);
> 0xf0140fb4 0xf0140fb4	CALL	0xf014093f
> 0xf0140fb9 0xf0140fb9	MOVL	0x10(SP),AX
> 0xf0140fbd 0xf0140fbd	MOVL	AX,0x0(SP)
> # unlock(ctlr)
> 0xf0140fc0 0xf0140fc0	CALL	0xf019b0be
> 0xf0140fc5 0xf0140fc5	ADDL	$0x14,SP
> 0xf0140fc8 0xf0140fc8	RET
>
> it have no debug symbols so i looked for magic numbers
> arround (in this case 0x18)
>
> wich turned out to be:
>
> ether79c970.c:31: 	Sreset		= 0x0018,	/* software reset */
>
> # this looks like io32r() from ether79c970.c
> acid: asm(0xf01409b4)
> 0xf01409b4 0xf01409b4	SUBL	$0x8,SP
> 0xf01409b7 0xf01409b7	MOVL	0xc(SP),CX
> # port = arg2
> 0xf01409bb 0xf01409bb	MOVL	0x1c(CX),CX
> # port += arg1
> 0xf01409be 0xf01409be	ADDL	0x10(SP),CX
> 0xf01409c2 0xf01409c2	MOVL	CX,0x0(SP)
> # inl(port)
> 0xf01409c5 0xf01409c5	CALL	0xf010036e
> 0xf01409ca 0xf01409ca	ADDL	$0x8,SP
> 0xf01409cd 0xf01409cd	RET
>
> # this is inl()
> acid: asm(0xf010036e)
> 0xf010036e 0xf010036e	MOVL	0x4(SP),DX
> 0xf0100372 0xf0100372	INL	DX,AX
> 0xf0100373 0xf0100373	RET
>
> so there is your bug!
>
> static void
> shutdown(Ether *ether)
> {
> 	Ctlr *ctlr;
>
> 	ctlr = ether->ctlr;
> 	ilock(ctlr);
> 	io32r(ctlr, Sreset);
> 	io16r(ctlr, Sreset);
> 	unlock(ctlr);
> }
>
> it was commented out before...
>
> the file just changed... i think they try to fix it right now...
>
> --
> cinap
>
>

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Josh Marshall]

[-- Attachment #1: Type: text/plain, Size: 2802 bytes --]

Is there a resource whereby I could pickup this kind of debug skill, or is
this experience, and assembly knowledge?

On Mon, Jun 13, 2011 at 3:01 AM, <cinap_lenrek@gmx.de> wrote:

> ok, i think i can explain the "unlock of ilock: pc f0140fc5, held by ..."
> message.
>
> i extracted that 9pcflop kernel with muzgos cdfpart from the current iso
> and
> disassembled with acid arround.
>
> the routine that calls unlock looks like this:
>
> the routine that calls the unlock (shutdown from ether79c970.c)
> 0xf0140f79 0xf0140f79   SUBL    $0x14,SP
> 0xf0140f7c 0xf0140f7c   MOVL    0x18(SP),AX
> # ctlr = arg->foobar
> 0xf0140f80 0xf0140f80   MOVL    0x78(AX),CX
> 0xf0140f83 0xf0140f83   MOVL    CX,0x10(SP)
> 0xf0140f87 0xf0140f87   MOVL    CX,0x0(SP)
> # ilock(ctlr)
> 0xf0140f8a 0xf0140f8a   CALL    0xf019af31
> 0xf0140f8f 0xf0140f8f   MOVL    0x10(SP),AX
> 0xf0140f93 0xf0140f93   MOVL    AX,0x0(SP)
> 0xf0140f96 0xf0140f96   MOVL    $0x18,AX
> 0xf0140f9b 0xf0140f9b   MOVL    AX,0x4(SP)
> # io32r(ctlr, 0x18) ???
> 0xf0140f9f 0xf0140f9f   CALL    0xf01409b4
> 0xf0140fa4 0xf0140fa4   MOVL    0x10(SP),AX
> 0xf0140fa8 0xf0140fa8   MOVL    AX,0x0(SP)
> 0xf0140fab 0xf0140fab   MOVL    $0x18,AX
> 0xf0140fb0 0xf0140fb0   MOVL    AX,0x4(SP)
> # io16r(ctlr, 0x18);
> 0xf0140fb4 0xf0140fb4   CALL    0xf014093f
> 0xf0140fb9 0xf0140fb9   MOVL    0x10(SP),AX
> 0xf0140fbd 0xf0140fbd   MOVL    AX,0x0(SP)
> # unlock(ctlr)
> 0xf0140fc0 0xf0140fc0   CALL    0xf019b0be
> 0xf0140fc5 0xf0140fc5   ADDL    $0x14,SP
> 0xf0140fc8 0xf0140fc8   RET
>
> it have no debug symbols so i looked for magic numbers
> arround (in this case 0x18)
>
> wich turned out to be:
>
> ether79c970.c:31:       Sreset          = 0x0018,       /* software reset
> */
>
> # this looks like io32r() from ether79c970.c
> acid: asm(0xf01409b4)
> 0xf01409b4 0xf01409b4   SUBL    $0x8,SP
> 0xf01409b7 0xf01409b7   MOVL    0xc(SP),CX
> # port = arg2
> 0xf01409bb 0xf01409bb   MOVL    0x1c(CX),CX
> # port += arg1
> 0xf01409be 0xf01409be   ADDL    0x10(SP),CX
> 0xf01409c2 0xf01409c2   MOVL    CX,0x0(SP)
> # inl(port)
> 0xf01409c5 0xf01409c5   CALL    0xf010036e
> 0xf01409ca 0xf01409ca   ADDL    $0x8,SP
> 0xf01409cd 0xf01409cd   RET
>
> # this is inl()
> acid: asm(0xf010036e)
> 0xf010036e 0xf010036e   MOVL    0x4(SP),DX
> 0xf0100372 0xf0100372   INL     DX,AX
> 0xf0100373 0xf0100373   RET
>
> so there is your bug!
>
> static void
> shutdown(Ether *ether)
> {
>        Ctlr *ctlr;
>
>        ctlr = ether->ctlr;
>        ilock(ctlr);
>        io32r(ctlr, Sreset);
>        io16r(ctlr, Sreset);
>        unlock(ctlr);
> }
>
> it was commented out before...
>
> the file just changed... i think they try to fix it right now...
>
> --
> cinap
>
>

[-- Attachment #2: Type: text/html, Size: 3376 bytes --]

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Cr0t daywalker]

[-- Attachment #1: Type: text/plain, Size: 2943 bytes --]

I have to admit that was pretty awesome.

Alex

On Jun 14, 2011, at 2:46 PM, Josh Marshall <joshua.r.marshall.1991@gmail.com>
wrote:

Is there a resource whereby I could pickup this kind of debug skill, or is
this experience, and assembly knowledge?

On Mon, Jun 13, 2011 at 3:01 AM, <cinap_lenrek@gmx.de> wrote:

> ok, i think i can explain the "unlock of ilock: pc f0140fc5, held by ..."
> message.
>
> i extracted that 9pcflop kernel with muzgos cdfpart from the current iso
> and
> disassembled with acid arround.
>
> the routine that calls unlock looks like this:
>
> the routine that calls the unlock (shutdown from ether79c970.c)
> 0xf0140f79 0xf0140f79   SUBL    $0x14,SP
> 0xf0140f7c 0xf0140f7c   MOVL    0x18(SP),AX
> # ctlr = arg->foobar
> 0xf0140f80 0xf0140f80   MOVL    0x78(AX),CX
> 0xf0140f83 0xf0140f83   MOVL    CX,0x10(SP)
> 0xf0140f87 0xf0140f87   MOVL    CX,0x0(SP)
> # ilock(ctlr)
> 0xf0140f8a 0xf0140f8a   CALL    0xf019af31
> 0xf0140f8f 0xf0140f8f   MOVL    0x10(SP),AX
> 0xf0140f93 0xf0140f93   MOVL    AX,0x0(SP)
> 0xf0140f96 0xf0140f96   MOVL    $0x18,AX
> 0xf0140f9b 0xf0140f9b   MOVL    AX,0x4(SP)
> # io32r(ctlr, 0x18) ???
> 0xf0140f9f 0xf0140f9f   CALL    0xf01409b4
> 0xf0140fa4 0xf0140fa4   MOVL    0x10(SP),AX
> 0xf0140fa8 0xf0140fa8   MOVL    AX,0x0(SP)
> 0xf0140fab 0xf0140fab   MOVL    $0x18,AX
> 0xf0140fb0 0xf0140fb0   MOVL    AX,0x4(SP)
> # io16r(ctlr, 0x18);
> 0xf0140fb4 0xf0140fb4   CALL    0xf014093f
> 0xf0140fb9 0xf0140fb9   MOVL    0x10(SP),AX
> 0xf0140fbd 0xf0140fbd   MOVL    AX,0x0(SP)
> # unlock(ctlr)
> 0xf0140fc0 0xf0140fc0   CALL    0xf019b0be
> 0xf0140fc5 0xf0140fc5   ADDL    $0x14,SP
> 0xf0140fc8 0xf0140fc8   RET
>
> it have no debug symbols so i looked for magic numbers
> arround (in this case 0x18)
>
> wich turned out to be:
>
> ether79c970.c:31:       Sreset          = 0x0018,       /* software reset
> */
>
> # this looks like io32r() from ether79c970.c
> acid: asm(0xf01409b4)
> 0xf01409b4 0xf01409b4   SUBL    $0x8,SP
> 0xf01409b7 0xf01409b7   MOVL    0xc(SP),CX
> # port = arg2
> 0xf01409bb 0xf01409bb   MOVL    0x1c(CX),CX
> # port += arg1
> 0xf01409be 0xf01409be   ADDL    0x10(SP),CX
> 0xf01409c2 0xf01409c2   MOVL    CX,0x0(SP)
> # inl(port)
> 0xf01409c5 0xf01409c5   CALL    0xf010036e
> 0xf01409ca 0xf01409ca   ADDL    $0x8,SP
> 0xf01409cd 0xf01409cd   RET
>
> # this is inl()
> acid: asm(0xf010036e)
> 0xf010036e 0xf010036e   MOVL    0x4(SP),DX
> 0xf0100372 0xf0100372   INL     DX,AX
> 0xf0100373 0xf0100373   RET
>
> so there is your bug!
>
> static void
> shutdown(Ether *ether)
> {
>        Ctlr *ctlr;
>
>        ctlr = ether->ctlr;
>        ilock(ctlr);
>        io32r(ctlr, Sreset);
>        io16r(ctlr, Sreset);
>        unlock(ctlr);
> }
>
> it was commented out before...
>
> the file just changed... i think they try to fix it right now...
>
> --
> cinap
>
>

[-- Attachment #2: Type: text/html, Size: 3631 bytes --]

Re: [9fans] unable to start plan9 on atom330 in virtualbox

[Cr0t daywalker]

[-- Attachment #1: Type: text/plain, Size: 3069 bytes --]

http://www.vitanuova.com/inferno/papers/acidpaper.html


©®0t



On Tue, Jun 14, 2011 at 2:43 PM, Josh Marshall <
joshua.r.marshall.1991@gmail.com> wrote:

> Is there a resource whereby I could pickup this kind of debug skill, or is
> this experience, and assembly knowledge?
>
>
> On Mon, Jun 13, 2011 at 3:01 AM, <cinap_lenrek@gmx.de> wrote:
>
>> ok, i think i can explain the "unlock of ilock: pc f0140fc5, held by ..."
>> message.
>>
>> i extracted that 9pcflop kernel with muzgos cdfpart from the current iso
>> and
>> disassembled with acid arround.
>>
>> the routine that calls unlock looks like this:
>>
>> the routine that calls the unlock (shutdown from ether79c970.c)
>> 0xf0140f79 0xf0140f79   SUBL    $0x14,SP
>> 0xf0140f7c 0xf0140f7c   MOVL    0x18(SP),AX
>> # ctlr = arg->foobar
>> 0xf0140f80 0xf0140f80   MOVL    0x78(AX),CX
>> 0xf0140f83 0xf0140f83   MOVL    CX,0x10(SP)
>> 0xf0140f87 0xf0140f87   MOVL    CX,0x0(SP)
>> # ilock(ctlr)
>> 0xf0140f8a 0xf0140f8a   CALL    0xf019af31
>> 0xf0140f8f 0xf0140f8f   MOVL    0x10(SP),AX
>> 0xf0140f93 0xf0140f93   MOVL    AX,0x0(SP)
>> 0xf0140f96 0xf0140f96   MOVL    $0x18,AX
>> 0xf0140f9b 0xf0140f9b   MOVL    AX,0x4(SP)
>> # io32r(ctlr, 0x18) ???
>> 0xf0140f9f 0xf0140f9f   CALL    0xf01409b4
>> 0xf0140fa4 0xf0140fa4   MOVL    0x10(SP),AX
>> 0xf0140fa8 0xf0140fa8   MOVL    AX,0x0(SP)
>> 0xf0140fab 0xf0140fab   MOVL    $0x18,AX
>> 0xf0140fb0 0xf0140fb0   MOVL    AX,0x4(SP)
>> # io16r(ctlr, 0x18);
>> 0xf0140fb4 0xf0140fb4   CALL    0xf014093f
>> 0xf0140fb9 0xf0140fb9   MOVL    0x10(SP),AX
>> 0xf0140fbd 0xf0140fbd   MOVL    AX,0x0(SP)
>> # unlock(ctlr)
>> 0xf0140fc0 0xf0140fc0   CALL    0xf019b0be
>> 0xf0140fc5 0xf0140fc5   ADDL    $0x14,SP
>> 0xf0140fc8 0xf0140fc8   RET
>>
>> it have no debug symbols so i looked for magic numbers
>> arround (in this case 0x18)
>>
>> wich turned out to be:
>>
>> ether79c970.c:31:       Sreset          = 0x0018,       /* software reset
>> */
>>
>> # this looks like io32r() from ether79c970.c
>> acid: asm(0xf01409b4)
>> 0xf01409b4 0xf01409b4   SUBL    $0x8,SP
>> 0xf01409b7 0xf01409b7   MOVL    0xc(SP),CX
>> # port = arg2
>> 0xf01409bb 0xf01409bb   MOVL    0x1c(CX),CX
>> # port += arg1
>> 0xf01409be 0xf01409be   ADDL    0x10(SP),CX
>> 0xf01409c2 0xf01409c2   MOVL    CX,0x0(SP)
>> # inl(port)
>> 0xf01409c5 0xf01409c5   CALL    0xf010036e
>> 0xf01409ca 0xf01409ca   ADDL    $0x8,SP
>> 0xf01409cd 0xf01409cd   RET
>>
>> # this is inl()
>> acid: asm(0xf010036e)
>> 0xf010036e 0xf010036e   MOVL    0x4(SP),DX
>> 0xf0100372 0xf0100372   INL     DX,AX
>> 0xf0100373 0xf0100373   RET
>>
>> so there is your bug!
>>
>> static void
>> shutdown(Ether *ether)
>> {
>>        Ctlr *ctlr;
>>
>>        ctlr = ether->ctlr;
>>        ilock(ctlr);
>>        io32r(ctlr, Sreset);
>>        io16r(ctlr, Sreset);
>>        unlock(ctlr);
>> }
>>
>> it was commented out before...
>>
>> the file just changed... i think they try to fix it right now...
>>
>> --
>> cinap
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 3714 bytes --]