[9fans] waserror()/nexterror()

[9fans] waserror()/nexterror()

[Lucio De Re]

I remember some exchange here about these, but no official
documentation.  Could somebody point me to a convenient place to
get to grips with these.

++L

Re: [9fans] waserror()/nexterror()

[Fco.J.Ballesteros]

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

Section on error handling in the Plan 9 kernel notes,
or drop me a line off-list and I'll try to explain.

[-- Attachment #2: Type: message/rfc822, Size: 2222 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans mailing list <9fans@cse.psu.edu>
Subject: [9fans] waserror()/nexterror()
Date: Fri, 16 Jan 2004 11:17:30 +0200
Message-ID: <20040116111729.N25947@cackle.proxima.alt.za>

I remember some exchange here about these, but no official
documentation.  Could somebody point me to a convenient place to
get to grips with these.

++L

Re: [9fans] waserror()/nexterror()

[Lucio De Re]

On Fri, Jan 16, 2004 at 10:20:33AM +0100, Fco.J.Ballesteros wrote:
>
> Section on error handling in the Plan 9 kernel notes,
> or drop me a line off-list and I'll try to explain.

4.3 Error handling

Thank you.  That will do for starters.

You may be able to help me with a totally different problem: I have
a set of VXL-Percios, thin client hardware that I'd like to have
running Plan 9.  They are just SiS550s in a box, with the obvious
and not so obvious peripherals (2xUSB and no serial ports).  2ed
plan 9 kernel boots, but can't recognise the realtek ether chip,
whereas something very early in the 4ed kernel startup (before any
printed announcements) causes the kernel to reset the host.

I haven't quite been tempted to boot the 3ed kernel, nor to mess
around with kernel sources as I seem to have a rather confused
distribution on my production server.

It's just that debugging those first few procedures in main() that
precede setting up printing seems a formidable task.  What can you
suggest?

In return, your notes ought to become a proper set of man pages,
the way the NetBSD folks have structured their section 9.  If you
head in that direction, I'd love to help you.

++L

Re: [9fans] waserror()/nexterror()

[Lucio De Re]

On Fri, Jan 16, 2004 at 11:38:45AM +0200, Lucio De Re wrote:
>
> On Fri, Jan 16, 2004 at 10:20:33AM +0100, Fco.J.Ballesteros wrote:
> >
> > Section on error handling in the Plan 9 kernel notes,
> > or drop me a line off-list and I'll try to explain.
>
> 4.3 Error handling
>
> Thank you.  That will do for starters.
>
I ought to delete the Reply-to: header from all incoming mails from
9fans.

++L

Re: [9fans] waserror()/nexterror()

[Charles Forsyth]

>>whereas something very early in the 4ed kernel startup (before any
>>printed announcements) causes the kernel to reset the host.

i noticed that recently on a 486-class device that did run a few months ago.
i'd wondered if it might have been the changes to devarch.c/l.s but
it wasn't urgent enough for me to debug it yet, nor was
i sure until i saw your remark that it wasn't more likely
some blunder of my own (eg, inconsistent mk)

Re: [9fans] waserror()/nexterror()

[jmk]

On Fri Jan 16 06:50:39 EST 2004, forsyth@terzarima.net wrote:
> >>whereas something very early in the 4ed kernel startup (before any
> >>printed announcements) causes the kernel to reset the host.
>
> i noticed that recently on a 486-class device that did run a few months ago.
> i'd wondered if it might have been the changes to devarch.c/l.s but
> it wasn't urgent enough for me to debug it yet, nor was
> i sure until i saw your remark that it wasn't more likely
> some blunder of my own (eg, inconsistent mk)

For some time Plan 9 on sources had the 'coherence' variable in pc/devarch.c
initialised to to something that wouldn't work on an x86 that didn't have the
CPUID instruction, e.g. the 386 and most 486. I attempted to fix it a few weeks
ago, if your kernel has the current devarch.c, fns.h and l.s and still doesn't
work, let me know.

--jim

Re: [9fans] waserror()/nexterror()

[Lucio De Re]

On Fri, Jan 16, 2004 at 10:37:06AM -0500, jmk@plan9.bell-labs.com wrote:
>
> For some time Plan 9 on sources had the 'coherence' variable in pc/devarch.c
> initialised to to something that wouldn't work on an x86 that didn't have the
> CPUID instruction, e.g. the 386 and most 486. I attempted to fix it a few weeks
> ago, if your kernel has the current devarch.c, fns.h and l.s and still doesn't
> work, let me know.
>
Thank, Jim, it helped considerably.  Not enough for a successful
boot, just yet, but definitely the kernel startup has proceeded
much further.

I figure that the SiS is not a properly grown up P5.  Cpuidentify(),
however, seems to think it is, so when it sets "tsc", it blows the
chip out the water.  I added a

	t->family = 4;

to skip that section and I have made good progress.  Let me post here
the last words...

cpu0: 511MHz SiS SiS SiS  P5 (cpuid: AX 0x0505 Dx 0x800111)
ELCR: 8820
pcirouting: BIOS workaround: PCI.0.1.2 at pin 4 link 65 irq 15 -> 5
pcirouting: BIOS workaround: PCI.0.13.0 at pin 1 link 65 irq 5 -> 15
#l0: rtl8139: 10 Mbps port 0xE200 irq 15: 0090DC0276DF
8356 free pages, 33424K bytes, 151824K swap
root is from (il, tcp)[il]:

It fails spectacularly (long stack dump, if there is an error
message, it has been flushed off the screen) as soon as I press
Enter.  Ah, that was because I omitted "ethermedium" in the kernel.
It's better now.

I'd like to know what the BIOS workarounds are, as well as the
later complaint that something isn't a DMA bus mastering device
(just ahead of the VGA complaint that it does not cope with the
SiS chipset :-( And no USB device, apparently, either.  That would
be a real show stopper.

I'll post a few diagnostics tomorrow, I'm losing concentration.
To summarise, I can log in, connect to the file server, read the
IDE drive that oughtn't top be there, really, but I can't really
perform any terribly useful operations just yet.  Without graphics,
however, the device is really a dead duck.

++L

Re: [9fans] waserror()/nexterror()

[jmk]

On Fri Jan 16 13:43:40 EST 2004, lucio@proxima.alt.za wrote:
> ...
>
> I figure that the SiS is not a properly grown up P5.  Cpuidentify(),
> however, seems to think it is, so when it sets "tsc", it blows the
> chip out the water.  I added a
> ...

what would be useful is the output of /bin/pci.

Re: [9fans] waserror()/nexterror()

[Lucio De Re]

On Fri, Jan 16, 2004 at 03:42:51PM -0500, jmk@plan9.bell-labs.com wrote:
>
> what would be useful is the output of /bin/pci.

Here you are:

  0.0.0: 06.00.00 1039/0550   0
  0.0.1: 01.01.80 1039/5513   0 4:00001101 16
  0.1.0: 06.01.00 1039/0008   0
  0.1.1: 05.01.00 1039/7005  15
  0.1.2: 0c.03.10 1039/7001   5 0:f2009000 4096
  0.1.4: 04.01.00 1039/7019  11 0:0000e101 256 1:f200c000 16384
  0.13.0: 02.00.00 10ec/8139 15 0:0000e201 256 1:f2010000 256
  0.2.0: 06.04.00 1039/0001   0
  1.0.0: 03.00.00 1039/5315   0 0:90000008 134217728 1:e0000000 131072 2:0000c001 128

++L

Re: [9fans] waserror()/nexterror()

[ron minnich]

On Fri, 16 Jan 2004, Lucio De Re wrote:

> It's just that debugging those first few procedures in main() that
> precede setting up printing seems a formidable task.  What can you
> suggest?

put in post codes between each function call in  main, assuming these
things have a PCI slot. If not, set up post codes to print post code to
serial. That's how we got linuxbios-based nodes working for R4.