[9fans] Bad Karma with old kit

[9fans] Bad Karma with old kit

[lucio]

I'm trying to resurrect a 386 IDEFS that holds a lot of useful
information, but it seems some of the grit has found its way into the
software.  I append the details below.

What I have not noticed in the past, is the
	hd0: LBA 26712000 sectors
message, which may have something in common with the other anomaly:
	wdev changed size 0 to 625870

I include the stack dump because (a) somebody may make sense of it and
(b) it seems that the *nostackdump= instructions is overlooked by the
FS kernel, which is fine if unexpected.

Note I'd been running an ancient (2002) IDEFS straight from España :-)
I have been able to reproduce the kernel (the original was lost on a
damaged floppy disk), but I may have the wrong raw buffer size.

Any suggestions welcome.

It's also a little publicised truth that the FS kernels off sources
are IDE capable, in fact, they incorporate a lot of new features, I'm
not sure if Geoff's recent 64-bit enhancements are included, but
certainly a lot of exciting bits have found their way into emelie and
choline.

++L

	entry: 0x80100020
	cpu0: 334MHz GenuineIntel PentiumII/Xeon (cpuid: AX 0x0652 DX 0x183f9ff)
	ether0: elnk3: 100Mbps port 0xe400 irq 12: 00105a45cb55
	iobufinit
	        10389 buffers; 1301 hashes
	        mem left = 16777215
	                out of = 201326592
	nvr read
	found plan9.nvr attr 0x0 start 0x1a9 len 512
	for config mode hit a key within 5 seconds
	        no config
	sysinit
	config p(h0)50.1
	        devinit p50.1
	        devinit D14
	hd0: LBA 26712000 sectors
	service    boggle
	ipauth  192.96.32.69
	ipsntp  192.96.32.66
	ip0     192.96.32.68
	ipgw0   192.96.32.66
	ipmask0 255.255.255.192
	filsys main cp(h0)50.25f[p(h0)0.25p(h0)25.25p(h0)75.25]
	filsys dump o
	sysinit: main
	        devinit cp50.25D5
	        devinit p50.25
	        devinit D14
	        devinit D5
	fworm init
	        devinit [p0.25-p75.25]
	        devinit p0.25
	        devinit D14
	        devinit p25.25
	        devinit D14
	        devinit p75.25
	        devinit D14
	wdev changed size 0 to 625870
	sysinit: dump
	        devinit op50.25D5
	ether0o: 00105a45cb55 192.96.32.68
	ether0i: 00105a45cb55 192.96.32.68
	next dump at Sun Jun  5 05:00:00 2005
	FLAGS=10246 TRAP=0 ECODE=0 CS=10 PC=801233f2
	  AX 00000000  BX 8a0cc000  CX 42a19465  DX 00000000
	  SI 80d9de40  DI 8003920c  BP 800381c8
	  DS 0008  ES 0008  FS 0008  GS 0008
	  CR0 80010011 CR2 00000000
	  ur 80038fe4
	FLAGS=282 TRAP=1b ECODE=0 CS=10 PC=80100396
	  AX 00000286  BX 00000000  CX 8014dd58  DX 80038eb0
	  SI 80038eb9  DI 8014e146  BP 0000000a
	  DS 0008  ES 0008  FS 0008  GS 0008
	  CR0 80010011 CR2 00000000
	  lastur 80038e00
	stack trace of 2
	0x8011d11f 0x8011d25b 0x8013ae98 0x80116b0a 0x8010789a 0x801183e6 0x801188d3 0x801171da 
	0x801172d1 0x8013c9e3 0x801171da 0x80106551 0x801066a9 0x8010636e 0x8013cc32 0x801171f5 
	0x80116ded 0x80118123 0x8011dd4d 0x801171f5 0x8013cc32 0x801171f5 0x80106775 0x8010a10a 
	0x8010636e 0x8011df19 0x8011deed 0x80100008 0x8011aa35 0x8011a8d1 0x80100658 0x8011bd59 
	0x8010a740 0x8011dd4d 0x8013eb1e 0x8011c568 0x8010648e 0x8011f9c9 0x801231cb 0x801066a9 
	0x8010636e 0x8010636e 0x8013e025 0x801233f2 0x8010024f 0x8013eb1e 0x80109c57 0x80109de5 
	0x80109d99 0x8011ebe7 0x8013eb1e 0x8014204e 0x8013e562 0x8013e025 0x8013ec25 0x8013ddea 
	0x8011c086 0x8011c04e 0x8011c04e 0x80109ed3 0x80100396 0x80140008 0x80110008 0x8010024f 
	0x80101111 0x80109ba9 0x80100396 0x80100b65 0x8011d689 0x8013ddea 0x80116a25 0x80106438 
	0x80116744 0x80106438 0x80116818 0x8010000a 0x8011c04e 0x8011bd03 0x80107936 0x8011bb7c 
	0x8010024f 0x80101111 0x8013ec25 0x8013ddea 0x8011d689 0x80100658 0x8011bd59 0x80116744 
	0x8010636e 0x8013ee3c 0x8013e562 2000 stack used out of 4000
	
	panic: divide error
	cpu 0 exiting
	halted. press a key to reboot.

Re: [9fans] Bad Karma with old kit

[geoff]

[Lucio, I tried to mail this to you privately, but keep getting

	Sat Jun  4 15:16:22 PDT 2005 connect to tcp!proxima.alt.za:
	550 5.0.0 Access denied ]

You can compile the 64-bit fs to be compatible on-disk with the 32-bit
fs by adding -DOLD to CFLAGS in the mkfile for that system.  It might
be worth trying the newer code.  The old IDE code was a little weak on
error checks.

Bad block size sounds like a good guess, but aren't you booting the
same fs kernel that you used to run on this machine?  The block size
is compiled in, so I'm not sure how it could have changed.

I'm a little puzzled by the references in the devinit lines to D5 and
D14; those don't look like valid file server device strings, which is
worrisome.  It looks like `D' is a `can't happen' condition, in Zfmt()
at /sys/src/fs/port/sub.c:602.

Re: [9fans] Bad Karma with old kit

[lucio]

> [Lucio, I tried to mail this to you privately, but keep getting
> 
> 	Sat Jun  4 15:16:22 PDT 2005 connect to tcp!proxima.alt.za:
> 	550 5.0.0 Access denied ]
> 
If you tell me the IP address this is happening on, I may be able to
fix it.  My exchanger is (intentionally) ridiculously strict, most
likely there are no PTR records for your end of the connection.  Sorry
about it, I can fix it this side if you can't/won't fix it on yours.
<lucio@iba.co.za> or <lucio@hivemind.net> are possible alternatives
for private mail, but they have their own mailboxes and I only inspect
them infrequently :-(

> You can compile the 64-bit fs to be compatible on-disk with the 32-bit
> fs by adding -DOLD to CFLAGS in the mkfile for that system.  It might
> be worth trying the newer code.  The old IDE code was a little weak on
> error checks.
> 
Yep, I can do that.

> Bad block size sounds like a good guess, but aren't you booting the
> same fs kernel that you used to run on this machine?  The block size
> is compiled in, so I'm not sure how it could have changed.
> 
No, I lost the original, I rebuilt it from source and I can't recall
whether originally I had changed the raw block size or not.  It won't
hurt (much) to try a few options, it did work for the 4/3/2ed server I
needed to revive (I'm on a binge of repairing equipment so it can lie
idle a little longer :-)

> I'm a little puzzled by the references in the devinit lines to D5 and
> D14; those don't look like valid file server device strings, which is
> worrisome.  It looks like `D' is a `can't happen' condition, in Zfmt()
> at /sys/src/fs/port/sub.c:602.

I thought as much, too.  But I'm totally unfamiliar with the FS code
and it used to scroll past too quickly for me to take proper notice,
specially when everything worked just fine.  I wonder if the block
size is not messing up the configuration as read off the disk.

Unusually, coming so close to recovering the filesystem, I'm willing
to go to some trouble to get back a number of useful items on that FS
for which I have no backup.  Normally I'd just give up.  I'll try
varying the raw block size first, but it's very tempting to use your
newer FS for everything.  Does it use the same dat.h entry for the
block size?  Any chance that that could be a config parameter?  Or,
even better, a detected value on existing filesystems?

++L

Re: [9fans] Bad Karma with old kit

[geoff]

Usually if the block size is wrong, the magic number for the
configuration block is also wrong (since the configuration block is
then looked for at the wrong offset), which should cause a panic or
other drastic failure.

dat.h looks pretty much the same in the 64-bit fs.  The block size is
a truly fundamental constant of the file server implementation;
changing it currently requires recompilation because the block size,
and constants derived from it, are used in array declarations and the
like.  There are ways that one could work around it, with some
contortions in the code.  kfs does, after all, but kfs had to (or at
least did) change the on-disk representation to make this feasible.