Interrupt doesn't make it to the 8259 on a ASUS P4PE mobo
A message that is not in the archive (sent off-list or not yet received): [email protected]
Thanks for your reply, Andi.
Quoted 1 line
Quoted 1 line
We have a proprietary PCI board installed in a (UP) system with an ASUS
P4PE
Quoted 1 line
Quoted 1 line
motherboard (uses Intel 845PE chipset). This system is running Red Hat
9.0
Quoted 5 lines
Have you checked the 845 errata sheets on the Intel website? Perhaps it is some known hardware bug.
One thing you could try is to use Local APIC / IO APIC interrupt processing instead of 8259.
Our hardware engineer has combed the Intel and ASUS websites, but found nothing. I'll give the APIC a try and see if I get different results and let you know.
Quoted 6 lines
Quoted 3 lines
/* start timer */
dmatimer.expires = jiffies + 0.5*HZ;That's a serious bug. You cannot use floating point in the kernel. It will corrupt the FP state of the user process.
HZ on the INTEL platform is 100, so this should simply add 50 to the current value of jiffies. Besides, assigning the value to the unsigned int field (expires) will truncate it to an integer anyway. Is there a more appropriate way to handle a short timeout?
Thanks,
Kathy
Quoted 21 lines · Kathy Frazier
Thanks for your reply, Andi.
Quoted 1 line
Quoted 1 line
We have a proprietary PCI board installed in a (UP) system with an ASUS
P4PE
Quoted 1 line
Quoted 1 line
motherboard (uses Intel 845PE chipset). This system is running Red Hat
9.0
Quoted 5 lines
Have you checked the 845 errata sheets on the Intel website? Perhaps it is some known hardware bug.
One thing you could try is to use Local APIC / IO APIC interrupt processing instead of 8259.
Our hardware engineer has combed the Intel and ASUS websites, but found nothing. I'll give the APIC a try and see if I get different results and let you know.
Quoted 3 lines
Quoted 3 lines
/* start timer */
dmatimer.expires = jiffies + 0.5*HZ;
Quoted 7 lines
Quoted 2 lines
That's a serious bug. You cannot use floating point in the kernel. It will corrupt the FP state of the user process.
HZ on the INTEL platform is 100, so this should simply add 50 to the current value of jiffies. Besides, assigning the value to the unsigned int field (expires) will truncate it to an integer anyway. Is there a more appropriate way to handle a short timeout?
It will truncate it at runtime.
I suggest
dmatimer.expires = jiffies + HZ/2;
Also, you you need to use the time_before() macro, like
while ( time_before(jiffies, dmatimer.expires) )
do_something();... so you don't have a timer-wrap problem during jiffie rollover if you haven't already done so (I don't have your source here).
Quoted 3 lines
Thanks,
Kathy
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.
SCSI ATA driver in 2.4.22 ?
Is Jeff Garzik's SCSI ATA driver going in 2.4.22? I've been using it with great success with 2.4.21-ac4, but I haven't seen it in any of the 2.4.22-pre kernels.
If it's not going in, is there an alternative for accessing serial ATA devices in native/enhanced mode rather than legacy mode?
By the way, if you name your child libata, some say the name has some nice qualities:
http://www.kabalarians.com/male/libata.htm
jeff
Re: SCSI ATA driver in 2.4.22 ?
Quoted 7 lines · Jeff Mock
Is Jeff Garzik's SCSI ATA driver going in 2.4.22? I've been using it with great success with 2.4.21-ac4, but I haven't seen it in any of the 2.4.22-pre kernels.
If it's not going in, is there an alternative for accessing serial ATA devices in native/enhanced mode rather than legacy mode?
My preference would be to merge into 2.6.0-test first, then send it to Marcelo after that. Otherwise, people upgrading 2.4->2.6 would get shafted.
Besides that, I certainly would not object to it being in 2.4.22. (but I'm biased :))
Quoted 4 lines
By the way, if you name your child libata, some say the name has some nice qualities:
That rules ;-)
Jeff
Quoted 29 lines · Kathy Frazier
Thanks for your reply, Andi.
Quoted 1 line
Quoted 1 line
We have a proprietary PCI board installed in a (UP) system with an ASUS
P4PE
Quoted 1 line
Quoted 1 line
motherboard (uses Intel 845PE chipset). This system is running Red Hat
9.0
Quoted 6 lines
Have you checked the 845 errata sheets on the Intel website? Perhaps it is some known hardware bug.
One thing you could try is to use Local APIC / IO APIC interrupt processing instead of 8259.
Our hardware engineer has combed the Intel and ASUS websites, but found nothing. I'll give the APIC a try and see if I get different results and let you know.
Quoted 2 lines
Quoted 2 lines
/* start timer */
dmatimer.expires = jiffies + 0.5*HZ;
Quoted 7 lines
Quoted 2 lines
That's a serious bug. You cannot use floating point in the kernel. It will corrupt the FP state of the user process.
HZ on the INTEL platform is 100, so this should simply add 50 to the current value of jiffies. Besides, assigning the value to the unsigned int field (expires) will truncate it to an integer anyway.
Use HZ/2 instead. GCC doesn't optimize floating point constants to the same degree it does integers, because it doesn't know what mode (rounding, precision) the FPU is in.
--
Brian Gerst
Quoted 5 lines · Brian Gerst
Quoted 5 lines
Quoted 4 lines
Quoted 1 line
dmatimer.expires = jiffies + 0.5*HZ;
That's a serious bug. You cannot use floating point in the kernel. It will corrupt the FP state of the user process.
Quoted 8 lines
Quoted 4 lines
HZ on the INTEL platform is 100, so this should simply add 50 to the current
value of jiffies. Besides, assigning the value to the unsigned int field (expires) will truncate it to an integer anyway.Use HZ/2 instead. GCC doesn't optimize floating point constants to the same degree it does integers, because it doesn't know what mode (rounding, precision) the FPU is in.
Optimising this to an integer add of 50 would be incorrect anyway. Think about jiffies == 0xfffffffe.
The first statement is equivalent to:
dmatimer.expires = (unsigned long) ((double) + 50)
and would set dmatimer.expires to 0xffffffff.
Whereas the HZ/2 form is correct!
Have a nice day,
-- Jamie
Quoted 3 lines · Brian Gerst
Use HZ/2 instead. GCC doesn't optimize floating point constants to the same degree it does integers, because it doesn't know what mode (rounding, precision) the FPU is in.
Isn't (HZ >> 1) better?
Regards,
Luciano Rocha
Quoted 6 lines · Luciano Miguel Ferreira Rocha
Quoted 1 line · Brian Gerst
Use HZ/2 instead. GCC doesn't optimize floating point constants to the same degree it does integers, because it doesn't know what mode (rounding, precision) the FPU is in.
Isn't (HZ >> 1) better?
Same thing. GCC knows that division by a power of 2 is just a shift.
--
Brian Gerst
Quoted 11 lines · Brian Gerst
Quoted 8 lines · Luciano Miguel Ferreira Rocha
Quoted 3 lines · Brian Gerst
Use HZ/2 instead. GCC doesn't optimize floating point constants to the same degree it does integers, because it doesn't know what mode (rounding, precision) the FPU is in.
Isn't (HZ >> 1) better?
Same thing. GCC knows that division by a power of 2 is just a shift.
Only for unsigned
Quoted 5 lines · Alan Cox
Quoted 3 lines
Quoted 1 line
Isn't (HZ >> 1) better?
Same thing. GCC knows that division by a power of 2 is just a shift.
Only for unsigned
Or when HZ is constant :)
-- J?amie
Hi Alan.
Quoted 9 lines
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Use HZ/2 instead. GCC doesn't optimize floating point constants to the same degree it does integers, because it doesn't know what mode (rounding, precision) the FPU is in.
Isn't (HZ >> 1) better?
Same thing. GCC knows that division by a power of 2 is just a shift.
Only for unsigned
When I did the "Assembler Language Maths Logic" module for my degree, we learned that processors used SRL (Shift Right Logical) to divide unsigned numbers by powers of 2, and SRA (Shift Right Arithmetic) to divide signed numbers by powers of 2. Can't GCC handle that?
Best wishes from Riley.
---
* Nothing as pretty as a smile, nothing as ugly as a frown.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.502 / Virus Database: 300 - Release Date: 18-Jul-2003
Quoted 4 lines · Riley Williams
When I did the "Assembler Language Maths Logic" module for my degree, we learned that processors used SRL (Shift Right Logical) to divide unsigned numbers by powers of 2, and SRA (Shift Right Arithmetic) to divide signed numbers by powers of 2. Can't GCC handle that?
Sure it can, but >>1 isn't the same as /2 for signed numbers.
(Hint: -1 / 2 != -1)
J