[9fans] rdbfs

[9fans] rdbfs

[Brantley Coile]

I'm having trouble getting rdbfs to work.  I start the rdbfs as follows:

	term% rdbfs -p 1000 /mnt/consoles/bertha

(I've imported the console to bertha from the console server.)

I then run db 

	db -k /386/9satabwctst 1000

which sends the following out the serial line

	R00000030 4c ca 00 80
	R00000038 a0 58 10 80
	R801058a0 83 c4 08 c3
	R801058a1 c4 08 c3 83
	cpu0: registers for genrandom 2
	FLAGS=10086 TRAP=E ECODE=0 PC=80105855 SS=58A2 USP=80200DE5
	  AX 080058A2  BX 8021554C  CX 080058A2  DX 00000000
	  SI 080058A2  DI 00000010  BP 00000010
	  CS 0010  DS 0008  ES 0008  FS 001B  GS 001B
 	  CR0 80010039 CR2 080058a2 CR3 00002000 CR4 000000d0
	  MCA 00000000 MCT 00000000
	  ur 8000c938 up 8022e9c0

As you can see, I get a trap when trying to access 080058a2?  I'm puzzled by the 0800
instead of 8010.

What am I doing wrong?


 Brantley

Re: [9fans] rdbfs

[Russ Cox]

run rdbfs with -d and maybe the output will be more illuminating.

russ

Re: [9fans] rdbfs

[Brantley Coile]

> run rdbfs with -d and maybe the output will be more illuminating.
> 
> russ
term% rdbfs -d -p 1000 /mnt/consoles/bertha
attach /mnt/consoles/bertha
term% db -k /386/9satabwctst 1000
got Tread tag 29 fid 347 offset 48 count 4: here goes...r00000030...serial [+bwc, bwc, sah, sah]
unknown message
serial R00000030 a8 2e 20 80
got Tread tag 29 fid 347 offset 56 count 4: here goes...r00000038...serial R00000038 a0 58 10 80
got Tread tag 29 fid 327 offset 2148554912 count 1: here goes...r801058a0...serial R801058a0 83 c4 08 c3
got Tread tag 29 fid 327 offset 2148554913 count 1: here goes...r801058a1...serial R801058a1 c4 08 c3 83
got Tread tag 29 fid 327 offset 2148554914 count 1: here goes...r801058a2...serial panic: fault but up is zero; pc 0x80105855 addr 0x001058a2
unknown message
serial 
unknown message
serial rdb...Edebugger reset
unknown message
error interrupted
r801058a2...serial 58a2 08 c3 83 ec
unknown message
error interrupted
r801058a2...serial 1058a2 08 c3 83 ec
unknown message
error interrupted
r801058a2...serial known message
unknown message
error interrupted
r801058a2...serial  08 c3 83 ec
unknown message
error interrupted


On the serial I saw...

rdb...Edebugger reset
[+bwc, bwc, sah, sah]
R00000030 a8 2e 20 80
R00000038 a0 58 10 80
R801058a0 83 c4 08 c3
R801058a1 c4 08 c3 83
panic: fault but up is zero; pc 0x80105855 addr 0x001058a2

rdb...Edebugger reset
R801058a2 08 c3 83 ec
R801058a2 08 c3 83 ec
Eunknown message
R801058a2 08 c3 83 ec



Thanks

Re: [9fans] rdbfs

[Russ Cox]

It doesn't look like the kernel is managing to read the
serial input correctly.  Maybe it's coming in too fast?

Russ

[9fans] rdbfs

[Brantley Coile]

could it be that some other process is stealing bytes
out of the uart?  how do i make sure that's not happening?

 bc

Re: [9fans] rdbfs

[Russ Cox]

> could it be that some other process is stealing bytes
> out of the uart?  how do i make sure that's not happening?

that's really unlikely given that the kernel is splhi
looping to poll the uart.

russ

Re: [9fans] rdbfs

[Sape Mullender]

>> could it be that some other process is stealing bytes
>> out of the uart?  how do i make sure that's not happening?
> 
> that's really unlikely given that the kernel is splhi
> looping to poll the uart.

I don't think another process is stealing bytes but I do sympathize
with anybody having uart problems.  I couldn't read all the bytes
off a GPS when it's baud rate was set higher than 4800.

	Sape

Re: [9fans] rdbfs

[Brantley Coile]

i seem to have it working somewhat now.  i'm just not sure how much i
can do with it.  it doesn't seem to have a stack to backtrace.  does
anyone use this rdb?

regarding serial ports, back in 1982 i wrote my first device driver
for a serial port.  it was a Signetics something.  we connected two of
our systems up with hardware flow control connected and could move
bytes at any speed.  (slow for the day, but still faster than 19200.)
later, we had systems with another chip, a Mot part if i recall, and
everything stopped working.  that Signetics part has been the only one
i have used that can assert/deassert the CTS in 1 byte time.  most of
the other parts just allow software control of these bits.

  bc

>>> could it be that some other process is stealing bytes
>>> out of the uart?  how do i make sure that's not happening?
>> 
>> that's really unlikely given that the kernel is splhi
>> looping to poll the uart.
> 
> I don't think another process is stealing bytes but I do sympathize
> with anybody having uart problems.  I couldn't read all the bytes
> off a GPS when it's baud rate was set higher than 4800.
> 
> 	Sape

Re: [9fans] rdbfs

[Russ Cox]

> i seem to have it working somewhat now.  i'm just not sure how much i
> can do with it.  it doesn't seem to have a stack to backtrace.  does
> anyone use this rdb?

i used to use it all the time.  i expect it should still work.
perhaps you're not invoking acid with -k?

russ

Re: [9fans] rdbfs

[Brantley Coile]

term% acid -k 1000
/386/9pc:386 plan 9 boot image

/sys/lib/acid/port
/sys/lib/acid/386
acid: lstk()
<stdin>:2: (error) no stack frame
acid: 


>> i seem to have it working somewhat now.  i'm just not sure how much i
>> can do with it.  it doesn't seem to have a stack to backtrace.  does
>> anyone use this rdb?
> 
> i used to use it all the time.  i expect it should still work.
> perhaps you're not invoking acid with -k?
> 
> russ

Re: [9fans] rdbfs

[Tim Newsham]

> acid: lstk()
> <stdin>:2: (error) no stack frame

I used rdbfs often when working with sparc, but over tcp (minor
mods to rdbfs to not set baud, and then a small shim to invoke
it on an fd from dial()) since the computer was connected to
the serial port of a non-plan9 computer.

As for the stack frame -- I found it useful to modify the
acid startup files (/sys/lib/acid/*) to allow you to pick
which set of registers to use.  This lets you set the registers
to some ureg location such as the ureg's at the time of
an exception/trap so that you can trace back from that point.
The changes are fairly straightforward -- read registers from
offsets starting at the specified address rather than from
offset zero.  The big change is altering all accesses to registers
to go through the ureg pointer (which would default to zero for
real registers).

You can also try to manually interpret the stack frame, but its
a bit tedious without frame pointers.

Tim Newsham
http://www.lava.net/~newsham/

Re: [9fans] rdbfs

[Steve Simon]

I beleive the uarts still default to FIFOs disabled.

I use rs422 on plan9 (on a 1.6Ghz machine) at 115Kbaud reliably -
as long as the fifo is enabled (the manpage is a bit out of date,
though the source isn't). Having said this I _do_ have trouble at 115K
on my 400Mhz laptop, which is sad as it could be really useful.

Updating the manpage moves one click up the To-do list...

-Steve

Re: [9fans] rdbfs

[Scott Schwartz]

| that's really unlikely given that the kernel is splhi
| looping to poll the uart.

A while back there was a bug where hardware flow control wasn't turned
on, so characters would get dropped.  Is that in good working order now?