* [9fans] Bad Karma with old kit
@ 2005-06-04 13:18 lucio
2005-06-04 22:26 ` geoff
0 siblings, 1 reply; 4+ messages in thread
From: lucio @ 2005-06-04 13:18 UTC (permalink / raw)
To: 9fans
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9fans] Bad Karma with old kit
2005-06-04 13:18 [9fans] Bad Karma with old kit lucio
@ 2005-06-04 22:26 ` geoff
2005-06-05 11:18 ` lucio
0 siblings, 1 reply; 4+ messages in thread
From: geoff @ 2005-06-04 22:26 UTC (permalink / raw)
To: 9fans
[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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9fans] Bad Karma with old kit
2005-06-04 22:26 ` geoff
@ 2005-06-05 11:18 ` lucio
2005-06-05 21:49 ` geoff
0 siblings, 1 reply; 4+ messages in thread
From: lucio @ 2005-06-05 11:18 UTC (permalink / raw)
To: 9fans
> [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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9fans] Bad Karma with old kit
2005-06-05 11:18 ` lucio
@ 2005-06-05 21:49 ` geoff
0 siblings, 0 replies; 4+ messages in thread
From: geoff @ 2005-06-05 21:49 UTC (permalink / raw)
To: 9fans
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-06-05 21:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-06-04 13:18 [9fans] Bad Karma with old kit lucio
2005-06-04 22:26 ` geoff
2005-06-05 11:18 ` lucio
2005-06-05 21:49 ` geoff
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).