> I see. Note that AFAIK enabling power management features in the BIOS, and then
> using a linux kernel without APM means you don' t get any power management at
> all, except for the hard disk time-out feature which is controlled by the hard
> disk embedded microprocessor itself (which is probably sent a command by the
> BIOS at boot time). I would advise you to completely turn off the BIOS power
> management, and setup the hard disk spin down timeout using hdparm, called from
> your rc.local file.
>
Hmm could try that can it hurt to use the old hdparm or do I need one
that's udma aware? Although I don't think it's my bios code messign up
things but you never know.
> You are probably making too many file requests during disk spin-up. Perhaps a
> queue overflows, either in the drive firmware or in the kernel code.
>
Nope, I can hit it as hard as I want to in any other way as long as I
don't do the login -> spinup -> switch to X thingie
besides that it's just making one request for the login,
I can switch to X without waking the hd. I think your off here.
> Important
> =======
> Note that _exactly_ the same identical code runs in the kernel, if you use DMA
> mode 2 or UDMA. Since you only get a problem when using UDMA, the Jumbo-9 kernel
> code can't be the source of the problem, so we have to look elsewhere.
>
Yes I know but it seems to be timing related and remember I need X
to reproduce it so it could be that X is hitting pci which screws up some
udma timing. udma timing might be more strict.
> OK, I guess we are having some complex interaction between a UDMA timing and
> the hard disk spin-up delay.
>
I agree
> David's problem _is_ APM related, but your problem is just hard disk spin
> down/up + UDMA related.
>
Yes Well to verify that the new do_fast_time_of_day isn't involved, didn't
you have a patch for just udma somewhere?
> If you _really_ want to find out where the problem is, the first step would be
> to get a different UDMA hard disk model/brand, and test it in exactly the same
> circumstances/hardware setup. Since you now have a repeatable crash, it will be
> immediately obvious whether the hard disk microcontroller firmware or the kernel
> code is guilty.
>
I would ,like to but ...
*** Hans looks in his wallet
*** Mhm awfully empty hmm
Get the drift?
> My present guess is a problem with the hard disk firmware, but the Quantum
> Fireball series is an exceptionally reliable drive, so I guess I am wrong on
> this too. Still, changing the hard disk would be a good thing to try. The next
> step is changing the motherboard against a newer VIA motherboard. If the
> problem disappears, then we know we have a problem in your present
> motherboard/BIOS combination.
>
I think you might be right here, since when I press reset the hd shows
instant activity before the vga-bios even it blinks rattles a bit as if
it's flushing it's cache.
> I will try to repeat exactly your crash procedure here on one of my systems,
> and see what happens. (I am using IBM UDMA hard disks and SiS5598 motherboards).
>
Could this have anything todo at all with my cyrix? I do use
set6x86 to setup some params like fast-loop and stuff.
I can try disabling it.
Regards,
Hans
p.s.
Thanks a lott for your time I find jumbo a great patch put when my machine
died suddenly (while I was using it remotly grrr) I was not happy.
This was the first time my machine abondened me since I switched from
<censorship> 95. And as you probably have noticed I've spend ours
afterwards to trace the cause. I'm happy though I've come this close.
I've disabled hd sleeping for now and I'm pretty happy again.
I'll try disabling bios pm and enabling hdsleep through hdparm
I'll also try the #define VERBOSe and cat /proc/via
I'm afraid I can't switch hd's or mobo's just now. But besides
that I'm more then willing to try out anything ;)
Even if I have to wait for a 6.5 gig fsck ;(
One luck though linux has always swapped out all dirty pages
before the hd falls a sleep so I haven't lost any data, atleast not
acording to fsck. Not even uncleared inodes ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html