Re: Linux 2.4.18-pre1

Re: Linux 2.4.18-pre1

[Andreas Hartmann]

Hello all,


Marcelo Tosatti wrote:


 > - Update Athlon/VIA PCI quirks			(Calin A.
 > 		 
				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

RE: Linux 2.4.18-pre1

[Troels Walsted Hansen]

> > - Update Athlon/VIA PCI quirks			(Calin A.
>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.

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

Re: Linux 2.4.18-pre1

[Andreas Hartmann]

Troels Walsted Hansen wrote:

>>>- Update Athlon/VIA PCI quirks			(Calin A.
>>>
>>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.
>>
> 
> Nope, the change is related to a bug in the VIA Northbridge memory write
> queue timer causing oopses on Athlon optimised linux kernels.

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

Thank you for your hint!


Regards,
Andreas Hartmann

Re: Linux 2.4.18-pre1

[Alan Cox]

> 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.

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.

Re: Linux 2.4.18-pre1

[Alan Cox]

> 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.

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

Re: Linux 2.4.18-pre1

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

On Fri, Dec 28, 2001 at 08:44:02PM +0100, Andreas Hartmann wrote:

> Dec 28 18:34:09 athlon kernel: DMA write timed out

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

Tim.
*/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Softdog support on non-x86

[Josh Wyatt]

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

Re: Softdog support on non-x86

[Russell King]

On Thu, Jan 10, 2002 at 09:49:00AM -0500, Josh Wyatt wrote:
> 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

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: Softdog support on non-x86

[Josh Wyatt]

Russell King wrote:
> 
> On Thu, Jan 10, 2002 at 09:49:00AM -0500, Josh Wyatt wrote:
> > 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
> 
> 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?

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


> 
> --
> Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
>              http://www.arm.linux.org.uk/personal/aboutme.html