Hi again,
Short summary: using another disk instead of the Quantum Bigfoot 5.25
series 2.1 GB C/H/S: 4095/16/63 disk fixes the problem. The Bigfoot
apparently was broken in some strange way.
On Mon, Jun 10, 2002 at 05:28:25PM +0200, Joost van Baal wrote:
> On Mon, Jun 10, 2002 at 03:04:56PM +0200, Nicos Gollan wrote:
> > On Sunday 09 June 2002 22:36, Joost van Baal wrote:
> > >
> > > [Please Cc me on replies, I'm not subscribed.]
> > >
> > > The short summary: When booting, my box gives up, stating:
> > >
> > > NET4: Unix domain sockets 1.0 for Linux NET4.0.
> > > attempt to access beyond end of device
> > > 03:02: rw=0, want=1023464393, limit=48384
> > > dev 03:02 blocksize=1024 blocknr= ....
> > > ...
> > My shot in the dark: it could be a bad BIOS call that fails to return
> > the correct size of the disk or a bad <insert your choice>. Perhaps
> > post the complete lines that you abbreviated.
> hda: QUANTUM BIGFOOT2100A, ATA DISK drive
> > Perhaps also make sure you don't need an obscure kernel workaround for
> > some strange system component. The BIOSes used for P133 systems are...
> > we.. strange.
>
> Hm, would tweaking CONFIG_PCI_GOBIOS or CONFIG_PCI_QUIRKS possibly help?
> /boot/config-2.2.20 has CONFIG_PCI_GOBIOS unset, and CONFIG_PCI_QUIRKS=y.
> Furthermore,
>
> CONFIG_PCI_GOANY=y
> CONFIG_PCI_BIOS=y
> CONFIG_PCI_DIRECT=y
>
> are set.
>
> Hm, I plan to compile a customized kernel anyway, maybe problems are no
> longer there when running 2.4.18 ...
> BTW, the behaviour during boot is _very_ random: During the last couply of
> days, I've had 7 failed boots and 8 succeeded boots. I didn't notice any
> pattern. BTW, the system crashed never. I just rebooted to peek at the boot
> messages of the day.
> I'll keep you informed (and I welcome any more insight, of course.)
OK, I installed a 2.4.18 kernel, which gave the same results: cold
booting failed, warm booting succeeded (but failed at times too). In
cases the boot succeeded, the system did run fine and stable. Similar
results while booting windoze: cold booting caused windows to give up
and reboot during the bootprocess. This gives a `save mode' boot,
rebooting again succeeds: doing stuff like running IE works.
I experimented with bootparameters like `boot: linux pci=bios'; `boot:
linux pci=nobios' etc., as documented in the kernel-doc's
kernel-parameters.txt. Didn't help at all. Same for passing
hda=1023,64,63 to the kernel commandline, as documented in ide.txt.
(These C/H/S values are the same as in the BIOS, btw.)
The machine has another harddisk now: a QUANTUM FIREBALL EL2.5A, ATA
DISK drive 5008500 sectors (2564 MB) w/418KiB Cache, CHS=1242/64/63,
(U)DMA. Doing a cat /dev/hda > /dev/hdc and swapping ide cables gave a
fine system (later I added another partition running cfdisk in single
user mode.) Yes, indeed, I still could read the filesystem fine from
the buggy disk.
Thanks a lot to Jan Stap, Wessel Dankers and Rudi Sluijtman who've
shared their insights with me.
Bye,
Joost
--
. . http://mdcc.cx/
Joost van Baal . .
. .
. . http://logreport.org/
Attachment:
pgpriK9SiCMUy.pgp
Description: PGP signature