Re: [9fans] rdbfs issues
On 3/20/07, Don Bailey [EMAIL PROTECTED] wrote: Hi, I'm attempting to use rdbfs to debug my CPU server via my diskless terminal. The main problem (I'm sure there will be others) is that my serial line seems to be hung up. I get no data in either direction after ^T^TD. I run the typical: rdbfs -p 999 acid -k 999 /path/to/kernel (the above is typed on the term prior to ^T^TD on the CPU) I also tried: echo b9600 '#t/eia0ctl' on both ends before attempting to use rdbfs. Any ideas? Do you have console=0 in your plan9.ini? Russ
Re: [9fans] rdbfs issues
Do you have console=0 in your plan9.ini? Yea, I'm a complete maroon. I forgot all about that. I misinterpreted the manual which says plan9 automatically initializes serial devices on boot into thinking it meant this automatically gives you a console. Thanks, Don
Re: [9fans] rdbfs issues
On 3/25/07, Don Bailey [EMAIL PROTECTED] wrote: Do you have console=0 in your plan9.ini? Yea, I'm a complete maroon. I forgot all about that. I misinterpreted the manual which says plan9 automatically initializes serial devices on boot into thinking it meant this automatically gives you a console. The remote debugger really should tell you when there is no console. It's a bug that it doesn't. Russ
[9fans] rdbfs issues
Hi, I'm attempting to use rdbfs to debug my CPU server via my diskless terminal. The main problem (I'm sure there will be others) is that my serial line seems to be hung up. I get no data in either direction after ^T^TD. I run the typical: rdbfs -p 999 acid -k 999 /path/to/kernel (the above is typed on the term prior to ^T^TD on the CPU) I also tried: echo b9600 '#t/eia0ctl' on both ends before attempting to use rdbfs. Any ideas? Don
[9fans] rdbfs
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 R0030 4c ca 00 80 R0038 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 SI 080058A2 DI 0010 BP 0010 CS 0010 DS 0008 ES 0008 FS 001B GS 001B CR0 80010039 CR2 080058a2 CR3 2000 CR4 00d0 MCA MCT 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
It doesn't look like the kernel is managing to read the serial input correctly. Maybe it's coming in too fast? Russ
Re: [9fans] rdbfs
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
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
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
| 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?
