Re: [9fans] breakpoint and single step on ARM
On Sat Aug 3 16:28:26 EDT 2013, 9f...@hamnavoe.com wrote: > A couple of patches applied yesterday should make debugging on ARM a > bit more reliable. Using db or acid on ARM, you may have noticed that > a program being debugged would sometimes execute through a breakpoint > without stopping, or run away while being single stepped. It turns out, > as often happens, that one symptom had two separate causes. For details: > /n/sources/patch/applied/5db-condcode/readme > /n/sources/patch/applied/arm-bkpt-cond/readme > > To take advantage of the patches, rebuild libmach.a, then acid and db. > On machines with a kw kernel (sheevaplug et al), you'll also want to > rebuild /arm/9plug; otherwise breakpoints will stop working at all. > The new 9plug will, however, still work with the old libmach; and > the bcm and teg2 kernels are already compatible with the new libmach. thanks! - erik
[9fans] mips bug
i'm unable to compile tojpg (which you may not have, but most any program should do) for amd64 on mips. here's an example: ; objtype=amd64 mk tojpg.install 6c -FTVw writejpg.c 6c -FTVw multichan.c 6c -FTVw tojpg.c 6l -o 6.tojpg writejpg.6 multichan.6 tojpg.6 cp 6.tojpg /amd64/bin/tojpg ; cpu -h ladd ladd; png -t9 < amd64.png|tojpg>amd64.jpg tojpg 277878: suicide: sys: trap: #SS pc=0x215014 acid says that imagmem is 0, and so is mainmem. this must mean that the data segment is clobbered. can other folks reproduce this? i'm guessing that there is a segment rounding issue? i was actually looking at a different bug when i tripped on this. they always hide out in bunches. - erik
Re: [9fans] mips bug
> i'm unable to compile tojpg (which you may not have, but most any > program should do) for amd64 on mips. here's an example: > > ; objtype=amd64 mk tojpg.install > 6c -FTVw writejpg.c > 6c -FTVw multichan.c > 6c -FTVw tojpg.c > 6l -o 6.tojpg writejpg.6 multichan.6 tojpg.6 > cp 6.tojpg /amd64/bin/tojpg > ; cpu -h ladd > ladd; png -t9 < amd64.png|tojpg>amd64.jpg > tojpg 277878: suicide: sys: trap: #SS pc=0x215014 > > acid says that imagmem is 0, and so is mainmem. this must > mean that the data segment is clobbered. can other folks reproduce > this? > > i'm guessing that there is a segment rounding issue? i was > actually looking at a different bug when i tripped on this. > they always hide out in bunches. Yes, I think you're right. I can reproduce the same problem here. cpu% 6c /sys/src/cmd/ls.c && 6l ls.6 cpu% cpu -h radium cpu% 6.out 6.out 367: suicide: sys: trap: #SS pc=0x209d56 -- David du Colombier
[9fans] Installing from the live environment
Hi! I'm installing Plan 9 on an Acer Aspire 5610-2273. When I boot the Plan 9 CD and choose the boot option, it works perfectly (including rio) but when I choose the install option, there's a kernel panic (at least that's what it looks like to me). Therefore I'm wondering if there's a way to start the installer from the live environment. Any ideas? I'm using an image from 7/30/13. Thanks, Alex Jordan
[9fans] it's all about the ethernet
ladd & comer are essentially the same machine (1.6ghz atom vs 1.8ghz atom). the difference between the 8169 and the 82574 is 2x. mikro0.57u 0.20s 1.20r wc -l historyrb450g ar71xx kw 0.26u 0.12s 0.77r wc -l historykirkwoodmarvell yukon-style ladd 0.05u 0.03s 1.01r wc -l historypc/atom 8169 comer0.02u 0.01s 0.53r wc -l historypc/atom 82574 minooka 0.00u 0.00s 0.52r wc -l historypc 82598→82563 (gbe)* minooka 0.04u 0.00s 0.15r wc -l historypc 82598→myricom (10gbe) - erik * some measurement error due to the slow fs used for this test.
Re: [9fans] Installing from the live environment
On Sun Aug 4 18:38:36 EDT 2013, alexander3223...@gmail.com wrote: > Hi! > I'm installing Plan 9 on an Acer Aspire 5610-2273. When I boot the > Plan 9 CD and choose the boot option, it works perfectly (including > rio) but when I choose the install option, there's a kernel panic (at > least that's what it looks like to me). Therefore I'm wondering if > there's a way to start the installer from the live environment. Any > ideas? > I'm using an image from 7/30/13. i think you have three options. 1. certainly. there's nothing magic about the installer. the steps are in broad terms - prepare the disk with the proper partions, etc. - create the boot 9fat. fill with a boot loader, plan9.ini and kernel - create the file system you wish to use - copy the files from the cd to the newly minted fs. - if you've done a few nonstandard things, you may need to also build a new kernel. the instructions for these things should be covered in booting(8), prep(8), fdisk(8), format(8). 2. you could try the 9atom cd. 3. richard miller's sd image for the rasberry pi "just works". that might be the easiest way to bootstrap your environment. building a pc from a raspberry pi would be easier than starting from scratch. by the way, any votes for a raspberry pi install/hack session at iwp9? - erik
[9fans] rb kernel vs acid
if i type src(main) when debugging a routerboard kernel, i get rather puzzling output ; acid 9rb 9rb:mips ELF32 executable /sys/lib/acid/port /sys/lib/acid/mips acid; src(main) no source for ?file?# fileline (see symbol(2)) this is especially odd since ktrace does work, acid does appear to disassemble correctly, map() appears to be reasonable and e.g., /bin/cat works as expected. does anyone else see this, too? by the way there is a patch for the type skew in symbol(2): /n/sources/patch/mach-man-type - erik
Re: [9fans] Installing from the live environment
> I'm using an image from 7/30/13. This issue has been fixed. Please download a current CD image. -- David du Colombier
Re: [9fans] rb kernel vs acid
> if i type src(main) when debugging a routerboard > kernel, i get rather puzzling output > > ; acid 9rb > 9rb:mips ELF32 executable > /sys/lib/acid/port > /sys/lib/acid/mips > acid; src(main) > no source for ?file?# fileline (see symbol(2)) > > this is especially odd since ktrace does work, acid > does appear to disassemble correctly, map() appears > to be reasonable and e.g., /bin/cat works as expected. > > does anyone else see this, too? Yes, I have the same issue here. -- David du Colombier
Re: [9fans] rb kernel vs acid
> > does anyone else see this, too? > > Yes, I have the same issue here. i've found part of the problem is machbytype doesn't get the joke with the type is 0x7f E L F. supposing machbytype did the right thing when faced with an elf header (with richer arguments), it's an open question for me if libmach could then figure it out. - erik