RE: Interrupt doesn't make it to the 8259 on a ASUS P4PE mobo

RE: Interrupt doesn't make it to the 8259 on a ASUS P4PE mobo

[Kathy Frazier]

Thanks for your reply, Andi.

>> We have a proprietary PCI board installed in a (UP) system with an ASUS
P4PE
>> motherboard (uses Intel 845PE chipset). This system is running Red Hat
9.0

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

>>
>> /* 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

RE: Interrupt doesn't make it to the 8259 on a ASUS P4PE mobo

[Richard B. Johnson]

On Tue, 15 Jul 2003, Kathy Frazier wrote:

> Thanks for your reply, Andi.
>
> >> We have a proprietary PCI board installed in a (UP) system with an ASUS
> P4PE
> >> motherboard (uses Intel 845PE chipset). This system is running Red Hat
> 9.0
>
> >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.
>
> >>
> >> /* 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?

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

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

[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?


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 ?

[Jeff Garzik]

On Tue, Jul 15, 2003 at 08:58:16AM -0700, Jeff Mock wrote:
> 
> 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 :))


> By the way, if you name your child libata, some say the name has
> some nice qualities:
> 
>    http://www.kabalarians.com/male/libata.htm

That rules ;-)

	Jeff

Re: Interrupt doesn't make it to the 8259 on a ASUS P4PE mobo

[Brian Gerst]

Kathy Frazier wrote:
> Thanks for your reply, Andi.
> 
> 
>>>We have a proprietary PCI board installed in a (UP) system with an ASUS
> 
> P4PE
> 
>>>motherboard (uses Intel 845PE chipset). This system is running Red Hat
> 
> 9.0
> 
> 
>>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.
> 
> 
>>>/* 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.

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

Re: Interrupt doesn't make it to the 8259 on a ASUS P4PE mobo

[Jamie Lokier]

Brian Gerst wrote:
> >>>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.
> 
> 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

Re: Interrupt doesn't make it to the 8259 on a ASUS P4PE mobo

[Luciano Miguel Ferreira Rocha]

On Tue, Jul 15, 2003 at 01:06:19PM -0400, Brian Gerst wrote:
> 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

Re: Interrupt doesn't make it to the 8259 on a ASUS P4PE mobo

[Brian Gerst]

Luciano Miguel Ferreira Rocha wrote:
> On Tue, Jul 15, 2003 at 01:06:19PM -0400, Brian Gerst wrote:
> 
>>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

Re: Interrupt doesn't make it to the 8259 on a ASUS P4PE mobo

[Alan Cox]

On Maw, 2003-07-15 at 19:24, Brian Gerst wrote:
> Luciano Miguel Ferreira Rocha wrote:
> > On Tue, Jul 15, 2003 at 01:06:19PM -0400, Brian Gerst wrote:
> > 
> >>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

Re: Interrupt doesn't make it to the 8259 on a ASUS P4PE mobo

[Jamie Lokier]

Alan Cox wrote:
> > > 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

Re: Interrupt doesn't make it to the 8259 on a ASUS P4PE mobo

[Riley Williams]

Hi Alan.

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

Re: Interrupt doesn't make it to the 8259 on a ASUS P4PE mobo

[Jeremy Fitzhardinge]

On Sun, 2003-07-20 at 14:04, Riley Williams wrote:
> 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