Linux 2.4.18-pre1

Hello all,

Culianu)

I tested this patch and unfortunately, I have to say, it is not working (if it should prevent the suddenly changing time on VIA-boards). I have the same problem with suddenly changing time as without this patch.

Furthermore, there are these entries in messages. They came in while printing via parport to printer HP6P.

Dec 28 18:34:09 athlon kernel: DMA write timed out
Dec 28 18:34:35 athlon kernel: DMA write timed out
Dec 28 18:35:01 athlon kernel: DMA write timed out
Dec 28 18:35:52 athlon last message repeated 2 times
Dec 28 18:36:17 athlon kernel: DMA write timed out
Dec 28 18:37:09 athlon last message repeated 2 times
Dec 28 18:37:32 athlon kernel: DMA write timed out
Dec 28 18:37:59 athlon kernel: DMA write timed out
Dec 28 18:38:25 athlon kernel: DMA write timed out
Dec 28 18:38:51 athlon kernel: DMA write timed out

Kernel tells that lp0 uses
"lp0: ECP mode".

I configured in modules.conf:

	alias parport_lowlevel  parport_pc
	options parport_pc      io=0x278 irq=5 dma=3

which should be correct regarding bios configurations.

Unfortunately I can't say, if these entries came in before or after the problem with the changing time.

The entries in messages and the time changing problem appeared during a lot of diskusage (io).

Regards,
Andreas Hartmann

(if it should prevent the

suddenly changing time as

Nope, the change is related to a bug in the VIA Northbridge memory write queue timer causing oopses on Athlon optimised linux kernels.

I believe the patch you're looking for is last seen in the ac series, and not merged with 2.4 mainline due to triggering on unaffected motherboards.

Troels Walsted Hansen

Sorry - I thought there could be a dependence between both problems.

Thank you for your hint!

Regards,
Andreas Hartmann

The -ac change is mostly a workaround. There is missing locking on the timer chip handling. Until someone (else) fixes that and we prove that there are hardware locking issues too, I won't be submitting the workaround because that'll just stop people fixing the bug

Hi All,

I've researched this question and haven't been able to find a suitable answer. The answer may be "it's painless as-is, just go for it". It might also be "give up now while you still have your pants".

I'd like to use the software watchdog timer, softdog.c, on the Sparc architecture, using kernel 2.2.17. I used this to build the module:
cd /usr/src/linux-2.2.17/drivers/char
gcc -c -DMODVERSIONS -D__KERNEL__ -DMODULE -Wall -Wstrict-prototypes softdog.c

The module builds fine with some warnings. After copying it over to /lib/modules/2.2.17/misc/softdog.o and running depmod -a, I get
modprobe: ELF file not for this architecture

I haven't tried modprobe'ing the module yet, the above message frightens me.

Is this driver safe for the sparc architecture? If not, what would it take? Or did I screw up somwehere along the way?

Please CC: me as I am not on the list.

Thanks in advance,
Josh Wyatt

Why are you building it manually? It'd be better to turn it on using the configuration tools, and build it in the normal way?

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Please CC: me as I am not on the list.

I built the module manually precisely because I did not want to rebuild the entire kernel and module set just to get this one module.

Perhaps I do not understand the correct approach to building individual modules, on an existing tree.

What's the documented, correct approach to only building a single module, starting with menuconfig, such that it will happily fit in with the currently running kernel and modules? I notice that many drivers/modules happily include the correct gcc incantation (in comment) for doing exactly this, and many do not.

And finally, back to my original question, is it a mute point? Is the softdog an Intel-only thing?

Thanks,
josh

It doesn't thats a seperate bug that nobody has bothered to fix yet. It probably also explains the occasional wild time jumps a few people have seen.

These messages are not actually errors, despite appearances. (However DMA printing is known to be buggy currently, under some circumstances.)

Tim.
*/