I am running FreeBSD 4.3 on a P3 1GMHz PC. While I am doing
some testing, I saw the kernel complained about "too many
stray irq 7's." The system runs ok, but I am concerned.
What could cause the warning? Thanks!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
On Thu, Jan 18, 2001 at 10:38:31PM +, Josef Karthauser wrote:
> At the risk of being dragged into this, I've see this kind of behaviour
> on RELENG_3 also in the past.
I have vague memories of it in 386BSD. It's really nothing new at all.
- mark
--
Mark Newton
> Hi
>
> This message popped up infrequently on my FreeBSD 3.x as well. It is not
> specific to 4.x. Now that I run 4.2, I still get the message once in a
> while.
This isn't Dennis' issue; it's simply that he's seeing it on 4.x with
hardware that doesn't do it under 3.x. There are so many var
Hi
This message popped up infrequently on my FreeBSD 3.x as well. It is not
specific to 4.x. Now that I run 4.2, I still get the message once in a
while.
The fact that other OSs don't report the condition does not mean it does
not occur. I had a NT box that was slow as hell. I eventually put Fre
On Thu, Jan 18, 2001 at 02:45:34PM -0800, Mike Smith wrote:
> > Ok, so why is this only a problem in FreeBSD 4.x, or better yet, since its
> > a well known problem, why arent they handled more eloquently?
>
> I have no idea why it only happens to you with 4.x; the code that does
> that has been
> > > What exactly is the hardware problem..and if you've identified it why is
> > > there no simple workaround after all this time (or is there)?
> >
> >You should read the i8259 datasheet, or the datasheet for any device
> >embedding a macrocell which emulates it, and once you read the section o
>
>
> > What exactly is the hardware problem..and if you've identified it why is
> > there no simple workaround after all this time (or is there)?
>
>You should read the i8259 datasheet, or the datasheet for any device
>embedding a macrocell which emulates it, and once you read the section on
>sp
>
> I know we've discussed this before. But I cant believe its a "hardware
> problem".
Then you're not going to believe the answer.
> Enabling any ISA interrupt causes the problem. Rather than the standard "
> your hardware is defective", perhaps someone can explain how a masked
> interrupt
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
m writes:
>
>I know we've discussed this before. But I cant believe its a "hardware
>problem".
Standard PIC behavior is to assert IRQ7 when an IRQ line is deasserted before
it can be properly latched in.
>and if you've identified it why is ther
I know we've discussed this before. But I cant believe its a "hardware
problem".
Enabling any ISA interrupt causes the problem. Rather than the standard "
your hardware is defective", perhaps someone can explain how a masked
interrupt can be generated without being enabled.
It seems as if t
Hi!
Could someone please comment on the following info from the Intel:
: 8259/82C59
: Spurious IRQ7
:
: In some applications, problem with a spurious IRQ7 might exist.
: For example, a spurios IRQ7 will occur under the following condition:
:
: While the device is performing extensive I/O operati
11 matches
Mail list logo
