Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Mike Smith writes:
> >> >Use a watchdog timeout like you should for any device that may hang.
> >> >Don't waste time running it every clock tick.
> >> >
> >> >ISTR that we thought that the bug might be caused by a bug in unwanted
> >> >SMI
Hi,
> Use a watchdog timeout like you should for any device that may hang.
> Don't waste time running it every clock tick.
>
> ISTR that we thought that the bug might be caused by a bug in unwanted
> SMI interrupt handling.
Upgrading the BIOS to Rev. 1010 does solve the problem for me without the
In message <[EMAIL PROTECTED]>, Mike Smith writes:
>> >Use a watchdog timeout like you should for any device that may hang.
>> >Don't waste time running it every clock tick.
>> >
>> >ISTR that we thought that the bug might be caused by a bug in unwanted
>> >SMI interrupt handling.
>>
>> If anybod
> >Use a watchdog timeout like you should for any device that may hang.
> >Don't waste time running it every clock tick.
> >
> >ISTR that we thought that the bug might be caused by a bug in unwanted
> >SMI interrupt handling.
>
> If anybody can reproduce this reliably on a *BX chipset I have
> co
In message <[EMAIL PROTECTED]>, Bruce E
vans writes:
>> I remember this one too. I think the problem is that we fail to
>> service the RTC intr for some reason. This patch was only a
>> workaround, and received a verbal broadside from Bruce if I
>> remember right.
>>
>> Maybe it should be add
> I remember this one too. I think the problem is that we fail to
> service the RTC intr for some reason. This patch was only a
> workaround, and received a verbal broadside from Bruce if I
> remember right.
>
> Maybe it should be added under a sysctl until a better solution
> is know.
>
> -
On Sun, 19 Sep 1999, Adam Strohl wrote:
> OK, Upgraded my Asus P2B-D machien from BIOS version 1008 to 1010, the
> problem disappeared. Popped back to my old 1008 BIOS, problem came back.
>
> Looks like there was some wierd issue that got resolved in 1009 or 1010.
Good! Thanks for the info. No
On Sat, 18 Sep 1999, Rodney W. Grimes wrote:
> So far about alls I have confirmed is that the problem does not exists
> with BIOS 1009 when the apm code is not compiled into the kernel. I'll
> have a full matrix of with/without apm 1008/1009/1010 some time tomarrow,
> as the machines are buildin
> OK, Upgraded my Asus P2B-D machien from BIOS version 1008 to 1010, the
> problem disappeared. Popped back to my old 1008 BIOS, problem came back.
So far about alls I have confirmed is that the problem does not exists
with BIOS 1009 when the apm code is not compiled into the kernel. I'll
have
OK, Upgraded my Asus P2B-D machien from BIOS version 1008 to 1010, the
problem disappeared. Popped back to my old 1008 BIOS, problem came back.
Looks like there was some wierd issue that got resolved in 1009 or 1010.
- ( Adam Strohl ) -
- UNI
On Friday, 17 September 1999 at 11:17:48 -0700, Matthew Dillon wrote:
> : Might I then request that you help rewrite it so that it performs
> :a much more comprehensive testing of OS/filesystem throughput?
> :Myself, I'd really love to see something that lets you seriously
> :stress your syste
Mike Smith wrote:
> > Matthew Dillon wrote:> thereabouts. Patches have been posted to several ma
iling lists, I was
> > wondering whether they've been committed somewhere along the line, and
> > whether APM was safe for inclusion into a 4.0-CURRENT SMP kernel again.
>
> APM and SMP are not f
> Matthew Dillon wrote:> thereabouts. Patches have been posted to several mailing
>lists, I was
> wondering whether they've been committed somewhere along the line, and
> whether APM was safe for inclusion into a 4.0-CURRENT SMP kernel again.
APM and SMP are not functional in -current; this bro
Hi,
> We're seenig it too in the 19990815ish time frame. This is both with
> the 3.2R binaries AND the ones rebuilt and reinstalled.
Saw it too on my ASUS P2B-DS (F.Rev.1008)
Solved by a patch flooding around to /sys/i386/isa/clock.c But why?
The patch is attached.
Bye!
Michael Reifenberge
In message <[EMAIL PROTECTED]>, Michael R
eifenberger writes:
>Hi,
>> We're seenig it too in the 19990815ish time frame. This is both with
>> the 3.2R binaries AND the ones rebuilt and reinstalled.
>Saw it too on my ASUS P2B-DS (F.Rev.1008)
>Solved by a patch flooding around to /sys/i386/isa/cl
In message <[EMAIL PROTECTED]> Andrzej
Bialecki writes:
: The problem seems to occur reliably on ASUS boards - perhaps a
: coincidence, but I have several machines here which behave this way. And
: yes, libkvm is in perfect sync with the rest of the system (3.3-RC)
We're seenig it too in the 199
> <
>said:
>
> > I've been getting this too on 4.0-C, just rebuild last night, still there.
> > top displays:
> > CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0%
> > idle
>
> On my dual-PPro Intel BB440FX system I am not seeing this.
Do you have apm compiled in or not?
On Sat, 18 Sep 1999, Jaye Mathisen wrote:
>
> Yes, it definitely seems ASUS related... I dropped back to uni processor
> ASUS boards, and it's fine. didn't need the SMP anyway, just wanted to
> play with it some more.
Now, here's the difference - I don't play, I NEED SMP, and the machines in
< said:
> I've been getting this too on 4.0-C, just rebuild last night, still there.
> top displays:
> CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0%
> idle
On my dual-PPro Intel BB440FX system I am not seeing this.
-GAWollman
--
Garrett A. Wollman | O Siem / We are
Yes, it definitely seems ASUS related... I dropped back to uni processor
ASUS boards, and it's fine. didn't need the SMP anyway, just wanted to
play with it some more.
On Sat, 18 Sep 1999, Andrzej Bialecki wrote:
> On Fri, 17 Sep 1999, Rodney W. Grimes wrote:
>
> > > :> I/O, and then clo
Matthew Dillon wrote:
>> 4.0-CURRENT (SMP on an ASUS P2B-DS with two CPU's installed; BIOS revision
>> 1008.A, running `systat -vm 1' gives the normal display but without any
>> numbers filled in, then switches over to an empty screen that says:
[..]
> Whenever systat or top do weird things i
On Fri, 17 Sep 1999, Rodney W. Grimes wrote:
> > :> I/O, and then closing it.
> > :
> > :4.0-CURRENT (SMP on an ASUS P2B-DS with two CPU's installed; BIOS revision
> > :1008.A, running `systat -vm 1' gives the normal display but without any
> > :numbers filled in, then switches over to an emp
I've been getting this too on 4.0-C, just rebuild last night, still there.
top displays:
CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0%
idle
AND loads > 2 make the machine very unresponsive, its like SMP was before
that pci_support.c patch a month or two ago.
- ( A
> :> I/O, and then closing it.
> :
> :4.0-CURRENT (SMP on an ASUS P2B-DS with two CPU's installed; BIOS revision
> :1008.A, running `systat -vm 1' gives the normal display but without any
> :numbers filled in, then switches over to an empty screen that says:
> :...
>
> Whenever systat or
:> I/O, and then closing it.
:
:4.0-CURRENT (SMP on an ASUS P2B-DS with two CPU's installed; BIOS revision
:1008.A, running `systat -vm 1' gives the normal display but without any
:numbers filled in, then switches over to an empty screen that says:
:...
Whenever systat or top do weird thi
Matthew Dillon wrote:
[..]
> One thing of interest to note, especially as it relates to the
> performance degredation with a larger number of files, is that
> 'systat -vm 1' reports an approximately 50% name-cache hit no
> matter what postmark is doing. In otherwords, postmark is
: Note that with a mail server, this is precisely the sort of thing
:that happens with /var/spool/mqueue. In particular, with sendmail, a
:qf/df pair of files get created, the message is received, the sender
:is told "250 Ok", then sendmail goes to deliver the message in the
:background
Ok, these are on duel P3 450 boxes running -CURRENT, with the NFS
performance enhancements. Local disk is an 18G seacrate on an LVD/W
scsi bus.
UFS tests: on 1G duel P3-450 machine, 1x18G seagate SCSI-LW bus
NFS tests: 1G duel P3-450 client, 512M duel P3-450 server, 100Base
:The program should dynamically mess with all the variables until it
:gets a statistically relevant curve.
Clarification: My definition of 'curve' is actually 'N dimensional
surface' where N is the number of variables... 5 or 6 or so. Don't
ask me how it could be represented
: Might I then request that you help rewrite it so that it performs
:a much more comprehensive testing of OS/filesystem throughput?
:Myself, I'd really love to see something that lets you seriously
:stress your system along the lines of Greg Lehey's rawio, but instead
:at a higher level.
At 1:02 PM -0700 1999/9/17, Matthew Dillon wrote:
> Sendmail does not get into trouble with queue files it is able to retire
> quickly. Where sendmail gets into trouble is with queue files it ISN'T
> able to retire quickly. This is why you *see* 10,000+ files in mqueue
> at time
At 11:56 AM -0700 1999/9/17, Matthew Dillon wrote:
> In real-life... for example, with a mail or web server, the namecache
> tends to be somewhat more effective then 50%. The web servers at BEST
> generally had a 95%+ name cache hit rate. The name cache misses are
> what are cau
At 11:17 AM -0700 1999/9/17, Matthew Dillon wrote:
> What we really need is something that generates a performance
> curve based on several variables, including block size, locality of
> reference (seek randomosity), amount of parallelism, locality of
> parallelism (i.e. operating
At 9:58 AM -0700 1999/9/17, Matthew Dillon wrote:
> It seems pretty clear to me that this benchmark has been designed
> to show-off the netapp in the best possible light and its competitors
> in the worst possible light. Well, ok, that may be an overly-harsh
> assessment, but it
34 matches
Mail list logo
