From owner-freebsd-...@freebsd.org Thu Aug 23 10:58:03 2012
Delivered-To: freebsd-...@freebsd.org
Date: Wed, 22 Aug 2012 23:52:44 +0200
From: Luigi Rizzo ri...@iet.unipi.it
To: John Baldwin j...@freebsd.org
References: 50324db4.6080...@cabletv.dp.ua
201208220802.14588@freebsd.org
luigi wrote:
On Wed, Aug 22, 2012 at 03:21:06PM -0400, John Baldwin wrote:
On Wednesday, August 22, 2012 2:54:07 pm Adrian Chadd wrote:
On 22 August 2012 05:02, John Baldwin j...@freebsd.org wrote:
On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote:
Hi,
What about
mitya wrote:
22.08.2012 05:07, Bruce Evans íàïèñàë:
On Mon, Aug 20, 2012 at 05:46:12PM +0300, Mitya wrote:
Hi.
I found some overhead code in /src/sys/net/if_ethersubr.c and
/src/sys/netgraph/ng_ether.c
It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN);
When src and dst
On Mon, Aug 20, 2012 at 05:46:12PM +0300, Mitya wrote:
Hi.
I found some overhead code in /src/sys/net/if_ethersubr.c and
/src/sys/netgraph/ng_ether.c
It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN);
When src and dst are struct ether_addr*, and ETHER_ADDR_LEN equal 6.
Only
luigi wrote:
even more orthogonal:
I found that copying 8n + (5, 6 or 7) bytes was much much slower than
copying a multiple of 8 bytes. For n=0, 1,2,4,8 bytes are efficient,
other cases are slow (turned into 2 or 3 different writes).
The netmap code uses a pkt_copy routine that does
jhb wrote:
On Monday, August 20, 2012 10:46:12 am Mitya wrote:
...
I propose this solution.
In file /usr/src/include/net/ethernet.h add this lines:
static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) {
#if defined(__i386__) || defined(__amd64__)
*dst =
and
virtual clock oscillators that may be used to build timestamping and timer
functions (mostly the former).
I am not sure what sort of high resolution you are refering to but maybe
these will lead you in the right direction. Bruce Evans CCd - he may
have quite a bit that could be added to this. I
On Sat, 5 May 2012, Andriy Gapon wrote:
on 04/05/2012 18:25 John Baldwin said the following:
On Thursday, May 03, 2012 11:23:51 am Andriy Gapon wrote:
on 03/05/2012 18:02 Andriy Gapon said the following:
Here's the latest version of the patches:
On Tue, 31 May 2011 m...@freebsd.org wrote:
I am looking into potentially MFC'ing r212367 and related, that adds
drains to sbufs. The reason for MFC is that several pieces of new
code in CURRENT are using the drain functionality and it would make
MFCing those changes much easier.
The problem
On Fri, 8 Apr 2011, Andriy Gapon wrote:
on 08/04/2011 03:00 Jeremy Chadwick said the following:
On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote:
As a generic question / observation, maybe we should just
implement 'errors=remount-ro' (or a reasonable facsimile) like Linux
On Thu, 17 Mar 2011, Jung-uk Kim wrote:
Both get_cyclecount(9) and cpu_ticks() do almost exactly the same
thing now assuming set_cputicker() is called with a correct function
before get_cyclecount() is used, which is true for x86, at least.
The only difference is get_cyclecount() may be inlined
On Fri, 18 Mar 2011, Kostik Belousov wrote:
On Fri, Mar 18, 2011 at 05:26:53PM +1100, Bruce Evans wrote:
...
- set cputicker() has some design bugs. It assumes that the tick frequency
is the same across all CPUs, but the TSC is per-CPU. I have an old SMP
system with CPUs of different
On Sat, 19 Mar 2011, Bruce Evans wrote:
On Fri, 18 Mar 2011, Kostik Belousov wrote:
We definitely do not support configurations with different models of
CPUs in SMP, this is what Simmetric is about. Different as in frequency
or stepping.
...
Now there is even more asymmetry
in core
On Wed, 21 Jul 2010, Jaakko Heinonen wrote:
On 2010-07-20, Garrett Cooper wrote:
I ran into an issue last night where apparently several apps make
faulty assumptions w.r.t. whether or not access(2) returns functional
data when running as a superuser.
New implementations are
On Tue, 20 Jul 2010, Garrett Cooper wrote:
Hi Hackers,
I ran into an issue last night where apparently several apps make
faulty assumptions w.r.t. whether or not access(2) returns functional
data when running as a superuser.
POSIX says:
In early proposals, some inadequacies in the
On Wed, 21 Jul 2010, Garrett Cooper wrote:
On Wed, Jul 21, 2010 at 1:40 AM, Bruce Evans b...@optusnet.com.au wrote:
- See a recent PR about unifdefed CAPABILITIES code in vaccess(). ?(The
?comment says that the code is always ifdefed out, but it now always
?unifdefed in.) ? I don't quite
On Tue, 6 Jul 2010, Sean Bruno wrote:
On Thu, 2010-07-01 at 16:46 -0700, Sean Bruno wrote:
Found this lying around the Yahoo tree this week. Basically it allows
you to activate, reset and deactivate profiling with the '-f flag.
I want something like this, but this implementation has too
On Thu, 6 May 2010, Kostik Belousov wrote:
On Thu, May 06, 2010 at 04:42:39PM +0400, Alexander Krizhanovsky wrote:
...
Indeed, I concerned more about PROC_LOCK/PROC_SLOCK - they are acquired
both in kern_getrusage() and could be a problem in multithreaded process
with intensive performance
On Fri, 24 Oct 2008, Thierry Herbelot wrote:
the [SUBJ] file contains the following extract (around line 705) :
* Default to PAGE_SIZE after much discussion.
* XXX: min(PAGE_SIZE, vp-v_bufobj.bo_bsize) may be more correct.
*/
sb-st_blksize = PAGE_SIZE;
which arrived around
On Tue, 12 Feb 2008, Andriy Gapon wrote:
on 12/02/2008 15:11 Bruce Evans said the following:
On Tue, 12 Feb 2008, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Andriy Gapon writes:
3.1. for a fresh buf getlbk would assign the following:
bsize = bo-bo_bsize;
offset = blkno * bsize
On Tue, 12 Feb 2008, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Andriy Gapon writes:
2.3. this code passes to bread blkno that is calculated as 4*sector,
where sector is a number of a physical 2048-byte sector. [**]
[**] - I think that this is a requirement of buffcache system,
On Tue, 12 Feb 2008, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Andriy Gapon writes:
on 06/02/2008 18:29 Andriy Gapon said the following:
Small summary of the above long description.
For directory reading fs/udf performs bread() on a (underlying) device
vnode. It passes block
On Mon, 4 Feb 2008, Alexander Motin wrote:
Kris Kennaway wrote:
You can look at the raw output from pmcstat, which is a collection of
instruction pointers that you can feed to e.g. addr2line to find out
exactly where in those functions the events are occurring. This will often
help to track
On Fri, 1 Feb 2008, Alexander Motin wrote:
Robert Watson wrote:
It would be very helpful if you could try doing some analysis with hwpmc --
high resolution profiling is of increasingly limited utility with modern
You mean of increasingly greater utility with modern CPUs. Low resolution
On Wed, 31 May 2006, Attilio Rao wrote:
2006/5/31, Suleiman Souhlal [EMAIL PROTECTED]:
Nice work. Any chance you could also port it to amd64? :-)
Not in the near future, I think. :P
It is not useful for amd64. An amd64 has enough instruction bandwidth
to saturate the L1 cache using 64-bit
On Fri, 1 Apr 2005, Matthew Dillon wrote:
:The use of the XMM registers is a cpu optimization. Modern CPUs,
:especially AMD Athlon and Opterons, are more efficient with 128 bit
:moves then with 64 bit moves. I experimented with all sorts of
:configurations, including the use of
On Thu, 31 Mar 2005, Matthew Dillon wrote:
I didn't mean to get into the kernel's use of the FPU, but...
All I really did was implement a comment that DG had made many years
ago in the PCB structure about making the FPU save area a pointer rather
then hardwiring it into the PCB.
ISTR
On Wed, 30 Mar 2005, David Schultz wrote:
On Wed, Mar 30, 2005, Peter Jeremy wrote:
On Tue, 2005-Mar-29 22:57:28 -0500, jason henson wrote:
Later in that thread they discuss skipping the restore state to make
things faster. The minimum buffer size they say this will be good for
is between 2-4k.
On Thu, 31 Mar 2005, Peter Jeremy wrote:
On Thu, 2005-Mar-31 17:17:58 +1000, Bruce Evans wrote:
I still
think fully lazy switching (c2) is the best general method.
I think it depends on the FP workload. It's a definite win if there
is exactly one FP thread - in this case the FPU state never
On Thu, 17 Jun 2004, Cyrille Lefevre wrote:
is there any reasons to hide timeradd() and co in sys/time.h
from the kernel space (! _KERNEL) ?
Yes. This prevents them being used in the kernel. They are compatibility
cruft for NetBSD. In the kernel the corresponding interfaces are
spelled
On Sun, 11 Apr 2004, Roman Kurakin wrote:
I remind you that now I have two problems. First one that FreeBSD uses
wrong assumption about which device should be CHS and which LBA:
if (!ad_version(atadev-param-version_major) ||
!(atadev-param-atavalid ATA_FLAG_54_58) || !lbasize)
atadev-flags
On Tue, 21 Oct 2003, Luigi Rizzo wrote:
both -current and -stable have the following snippet of code in
sys/dev/syscons/syscons.c:scclose():
{
...
int s;
if (SC_VTY(dev) != SC_CONSOLECTL) {
...
s = spltty();
On Wed, 10 Sep 2003, Eno Thereska wrote:
In FreeBSD 4.4, I am noticing a huge number of calls
to ffs_fsync() (in /sys/ufs/ffs/ffs_vnops.c)
when running a benchmark like Postmark.
ffs_fsync() flushes all dirty buffers with an open file
to disk. Normally this function would be called
either
On Tue, 12 Nov 2002, Tomas Pluskal wrote:
I believe that everybody here knows about the slow msdosfs problem, that
is AFAIK caused by implementation without clustering.
Which problem. msdosfs has a number of small problems. Mostly they don't
matter.
For me this is very annoying, because I
On Fri, 11 Oct 2002, Terry Lambert wrote:
Bruce Evans wrote:
I know it's not fashionable to write code that's portable to
compilers other than GCC, but even if FreeBSD is going to ignore
portability for it's own source code, it's probably unreasonable
to expect ACE to ignore
On Thu, 10 Oct 2002, Terry Lambert wrote:
Bruce Evans wrote:
In Standard C, this is equivalent to the non-verbose version:
#if _POSIX_REALTIME_SIGNALS != -1
...
#endif
since if _POSIX_REALTIME_SIGNALS is not defined then it is equivalent to
0 in cpp
On Thu, 10 Oct 2002, Terry Lambert wrote:
Bruce Evans wrote:
_POSIX_REALTIME_SIGNALS is undefined:
Apparently the same as when it is defined to 0, except you cannot assume
that anything related to it works until you call sysconf(), so you must
not reference its interfaces statically
On Thu, 10 Oct 2002, Craig Rodrigues wrote:
On Thu, Oct 10, 2002 at 09:31:56PM +1000, Bruce Evans wrote:
Perhaps because they wanted you to use sysconf() instead of these mistakes.
Well in the case of ACE, it is a C++ library that is compiled on
platforms which may or may not have sysconf
On Wed, 9 Oct 2002, Craig Rodrigues wrote:
On Wed, Oct 09, 2002 at 07:29:48PM -0700, Terry Lambert wrote:
To be totally correct, you will need to:
#ifdef _POSIX_REALTIME_SIGNALS
#if (_POSIX_REALTIME_SIGNALS != -1)
...
#endif
#endif
It's annoying, but
On Wed, 9 Oct 2002, Craig Rodrigues wrote:
Earlier this year on the FreeBSD hackers mailing list:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=278142+0+/usr/local/www/db/text/2002/freebsd-hackers/20020317.freebsd-hackers
I was advised by Terry Lambert to use:
#ifdef _POSIX_REALTIME_SIGNALS
On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:
Worst case you will have the option to use:
options NOGEOM
options vinum
A NOGEOM option would be as acceptable as a NOFFS option for turning off
forcing of the one true file system down everyone's throats.
Bruce
To Unsubscribe:
On Sat, 5 Oct 2002, Peter Wemm wrote:
Bruce Evans wrote:
On Fri, 4 Oct 2002, Poul-Henning Kamp wrote:
Worst case you will have the option to use:
options NOGEOM
options vinum
A NOGEOM option would be as acceptable as a NOFFS option for turning off
forcing of the one
On Thu, 3 Oct 2002, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Bakul Shah writes:
How hard would it be to bring back block devices without GEOM?
Not at all hard, pretty trivial in fact.
The easiest way is to restore the old code and use a minor number hack or
ioctl to enable it.
On Thu, 3 Oct 2002, Mark Santcroos wrote:
I have an almost-ready patch that implements linux_read() syscall. This
will check if we are reading from a raw disk and in that case it will
enlarge the read() to the next sector boundary. I have it working in the
kernel but I have problems
On Thu, 3 Oct 2002, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Mark Santcroos writes:
On Thu, Oct 03, 2002 at 09:50:45PM +1000, Bruce Evans wrote:
Unbreaking block devices would be a better solution. Without buffering,
...
What was the reason for the removal of block devices
On Sat, 17 Aug 2002, Artem 'Zazoobr' Ignatjev wrote:
On Sun, Aug 18, 2002 at 02:12:45AM +1000, Bruce Evans wrote:
[skip]
Fdisk should print these values, at least optionally, since they are needed
for debugging. The magic values might be non-magic on old systems.
Debugging WHAT
On Thu, 15 Aug 2002, Maxim Sobolev wrote:
When implementing ability to switch interface into promisc mode using
ifconfig(8) I've stumbled into the problem with already exhausted
space in the `short if_flags' field in the ifnet structure. I need to
allocate one new flag, while we already have
On Thu, 14 Mar 2002, ozan s. yigit wrote:
Add the -ffloat-store flag to your compilation flags (or
add -msoft-float).
that really means for this compiler on certain platforms, you
can have slow and correct or fast and incorrect, but NOT fast
and correct.
I think fast and correct is
On Mon, 25 Feb 2002, David Malone wrote:
I note that in the footnotes for getgrgid, in the section for issue
6 of the standard:
The requirement to include sys/types.h has been removed.
Although sys/types.h was required for conforming
implementations of previous POSIX
On Tue, 5 Feb 2002, Nik Clayton wrote:
On Tue, Feb 05, 2002 at 05:01:29PM +1100, Bruce Evans wrote:
My patch is not suitable for committing verbatim. It has 2 or 3 XXX's.
Do you make these patches available anywhere, so that other people can
look over them and maybe help you on the XXX'd
On Tue, 5 Feb 2002, Mike Silbersack wrote:
On Tue, 5 Feb 2002, Bruce Evans wrote:
foo:
pushl %ebp
movl %esp,%ebp
subl $8,%esp# - extra instruction for alignment (for foo)
addl $-12,%esp # - extra instruction for alignment (for f1)
What disgusting
On Mon, 4 Feb 2002, Michal Mertl wrote:
Did you look at the patch by Bruce at
http://groups.yahoo.com/group/freebsd-current/message/39605 ?
Bruce, is it still fresh in your memory? Can you comment on the patch -
can it be commited in some form?
I haven't done anything to clean up the
On Mon, 4 Feb 2002, Mike Silbersack wrote:
On Tue, 5 Feb 2002, Bruce Evans wrote:
I haven't done anything to clean up the patch. I hope the problem
will go away in future versions of gcc (align the stack at runtime in
the few routines that actually need it).
Well, if Linux aligns
On Sat, 15 Sep 2001, Matt Dillon wrote:
I'm redirecting this to freebsd-hackers.
Ok, I've comitted a new set of changes to libatm. Please check them out.
When we get a format that enough people are happy with we can start
converting the other libraries. I'm not
On Sat, 8 Sep 2001, Chris Costello wrote:
On Saturday, September 08, 2001, Poul-Henning Kamp wrote:
No actually not, I want something short and predictable like
VT_CODA.
How about my second suggestion: making v_tag point to
mp-mnt_stat.f_fstypename, or a copy thereof?
Good, but I as
On Tue, 4 Sep 2001, Maxim Sobolev wrote:
[neither Maxim Sobolev nor Brent Verner wrote]
In message [EMAIL PROTECTED], Brent Verner writes:
#include newbie_kernel_hacker_warning.h
I've done a /cursory/ look over how this v_tag is used. I'm not sure
this is a simple/clean as you
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
I see (amost).
Please format the macro the same as the other macros in the file.
Index: apic_vector.s
===
RCS file: /home/ncvs/src/sys/i386/isa/apic_vector.s,v
retrieving
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
I wrote:
The problem here is that CPU#1 fails to hold clock_lock while setting
clkintr_pending, causing i8254_offset to be stepped twice, first due
to clkintr_pending, then due to i8254_lastcount being larger than count.
With this patch
On Fri, 31 Aug 2001 [EMAIL PROTECTED] wrote:
For RELENG_4, which uses Xintr0, this problem is reduced by adding the
clkintr_pending variable (cf. revision 1.134 of clock.c and revision
1.38 of apic_vector.s)
Looking more at the code, I now see that clkintr_pending is never set
in -current
On Thu, 30 Aug 2001, Martin Blapp wrote:
Searching the freebsd mailinglists I have seen that you also suffering
under this problem on 4.X. STABLE:
I now remember your old mail about this. I (implicitly) suggested a fix,
but apparently no one tried it:
On Thu, 21 Jun 2001, Martin Blapp
On Mon, 14 May 2001, Dima Dorfman wrote:
Is there a reason the definitions of the MIN() and MAX() macros in
sys/param.h are under an '#ifndef _KERNEL'? Quite a few files in the
It is to inhibit use of these macros. The {i,,l,lu,q}{max,min} inline
functions are supposed to be used instead.
On Sun, 25 Mar 2001, Peter Pentchev wrote:
Only mount_foofs can reasonably know about the options for foofs.
perhaps mount(8) could fork-exec mount_foofs(8) to print options for
foofs.
bikeshed type=question value="mostly stupid"
Or could mount(8) invoke a couple of sysctl's to get a
On Sat, 24 Mar 2001, Dima Dorfman wrote:
I tried to export this stuff in struct statfs, but ran into a problem:
I'd need the complete definitions of fs_args in sys/mount.h, but I
can't include, e.g., nfs/nfs.h because the latter includes the
former (sys/mount.h)!
mount.h used to know too
On Wed, 7 Feb 2001, Josef Karthauser wrote:
On Wed, Feb 07, 2001 at 08:56:14PM +, Josef Karthauser wrote:
On Wed, Feb 07, 2001 at 08:26:15PM +0100, Dag-Erling Smorgrav wrote:
Brian Somers [EMAIL PROTECTED] writes:
Indeed. I've been doing a ``make build'' on an OpenBSD-current vm
On Tue, 6 Feb 2001, Josef Karthauser wrote:
I'm wondering what's changed recently to cause vmware2 running on
the linuxemu to lose a lot of performance with disk I/O.
Use of cmpxchg and possibly other SMP pessimizations.
A couple of weeks ago I could boot win2000 under vmware2 in a matter
On Mon, 18 Sep 2000, Marc Tardif wrote:
0cicuta/home/babolo(9)#dd of=/dev/wd0s2 if=/dev/zero bs=660b
1cicuta/home/babolo(11)#od -b /dev/wd0s2
[ snip ]
Why I use 2.2.7 for test?
Because of my lovely 4.1-STABLE is extremly unstable with content of
ad0s2 (wd0s2) above and silently reboot
On Sun, 17 Sep 2000, Adrian Filipi-Martin wrote:
I recently ran into revelant problem with /dev/stdout, while
working on some software under linux that expected /dev/stdout as an
argument instead of using stdout.
Using the device file breaks, if the process is suid to a
On Thu, 1 Jun 2000, G.B.Naidu wrote:
I am having problems with DDB while setting breakpoints in the kernel. I
entered the DDB by giving kernel -d at boot prompt. After that I tried to
set break point at ip_output() by giving "b ip_output". But it complains
saying that "sumbol not found". I
On Wed, 31 May 2000, Joy Ganguly wrote:
what is the significance of QUEUE_VMIO buffer (struct buf) queue ?? as
far as i could see they are not used at allbut maybe i am wrong.
It signifies bitrot. Its use was removed more than 5 years ago in
rev.1.35 of sys/kern/vfs_bio.c, but its
On Tue, 30 May 2000, Garrett Wollman wrote:
On Tue, 30 May 2000 16:20:53 -0400, "Yevmenkin, Maksim N, CSCIO"
[EMAIL PROTECTED] said:
i know that :) i guess my questions were
1) why the same piece of code duplicated in all ``mount_xxx'' utilities?
Because the original loadable module
On Wed, 26 Jan 2000, Yevmenkin, Maksim N, CSCIO wrote:
I've just found that read from /dev/bpfX never return
EAGAIN/EWOULDBLOCK.
It means that when you do a non blocking read and there is
no data you will
always get 0.
[ untested fix removed :) ]
Yes, it works. But it returns
On Sun, 23 Jan 2000, Warner Losh wrote:
: This is what I asked for, when I asked for "other specification". Could
: you provide the chapter/verse number of where POSIX spec contradicts the
: man pages? It will help me make my case on the TCL forum, since the TCL
: developers remain under
In unistd.h we have definitions for getopt, optarg, optind, opterr, and
optopt.
These are the standard POSIX (.2?) declarations.
The things I propose to add to unistd.h are the following:
struct option
{
char*name;
int has_arg;
int *flag;
int
In file included from
/usr/src/sys/boot/i386/libi386/../../../sys/signal.h:236,
from
/usr/src/sys/boot/i386/libi386/../../../sys/param.h:90,
from
/usr/src/sys/boot/i386/libi386/aout_freebsd.c:29:
There used to be security holes that allowed root to lower `securelevel'
using init. Rev.1.9 defends against any undiscovered holes.
How about following change?
OK.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Once securelevel has been increased, no process can decrease it because
kernel always refuse decreasing it. This is inconsistent with the
manual page of init:
The kernel runs with four different levels of security. Any super-user
process can raise the security level, but only init
Once securelevel has been increased, no process can decrease it because
kernel always refuse decreasing it. This is inconsistent with the
manual page of init:
The kernel runs with four different levels of security. Any super-user
process can raise the security level, but only init can
There used to be security holes that allowed root to lower `securelevel'
using init. Rev.1.9 defends against any undiscovered holes.
How about following change?
OK.
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
/*
* XXX the data is 16-bit due to a historical botch, so we use
* magic 16's instead of ICU_LEN and can't support 24 interrupts
* under SMP.
*/
intr = *(int16_t *)data;
if (cmd != MEM_RETURNIRQ (intr 0 || intr = 16))
/*
* XXX the data is 16-bit due to a historical botch, so we use
* magic 16's instead of ICU_LEN and can't support 24 interrupts
* under SMP.
*/
intr = *(int16_t *)data;
if (cmd != MEM_RETURNIRQ (intr 0 || intr = 16))
Can nohup really prevent processes from trapping SIGHUP? I thought it
just set the SIGUP handler to discard and hoped for the best.
It's normally a bug to catch ignored signals. Daomons that reread config
files when they receive a signal may be counterexamples. OTOH, they
probably shouldn't be
Can nohup really prevent processes from trapping SIGHUP? I thought it
just set the SIGUP handler to discard and hoped for the best.
It's normally a bug to catch ignored signals. Daomons that reread config
files when they receive a signal may be counterexamples. OTOH, they
probably shouldn't be
this is problematic.
you cannot add a new element before the pending firing because you can't
tell how far into the present trigger you are.
This is not a problem for readable counters like the i8254. The problem
for the i8254 is that reading and writing it takes a long time (perhaps
5 usec
dfr If I understand this correctly, you are suggesting that we program timer0
dfr so that we only take interrupts when a finetimer is due to fire? If so,
dfr then it sounds very good. The idea of taking 6000+ interrupts/sec made me
dfr uneasy, even though most would return without doing any work.
I commented out the SMP and FAST code, rebuilt the kernel from scratch and
the panic still occurs. Is there other code that should be disabled? Is
this fixed in 3.2? Why are there evil macro's in my computer? Why am I
asking so many questions?
I committed a proper fix in /sys/i386/isa/cy.c:
There seems to be a problem with nested locks. What was the panic
message?
I have the same problem with my Cyclom Ye cards (both the isa pci
variety)
The kernel panics with:
panic messages:
---
panic: rslock: cpu: 0, addr: 0xf026a15c, lock: 0x0001
mp_lock = 0001; cpuid = 0; lapic.id
I have multiprocessor machine:
matherboard SOYO 5TX2/X5 with 2 intel 166 proceccors
multiport card Cyclades Cyclom 8Yep
Kernel config:
options SMP # Symmetric MultiProcessor Kernel
options APIC_IO # Symmetric (APIC) I/O
options NCPU=2 #
Am I understand this right: if I configure my PCI card to an
exclusive interrupt, and then turn on CY_PCI_FASTINTR, I'll get
rid of ``silo overflows'' on it.
Except in -current, where CY_PCI_FASTINTR is broken (it has no effect).
Just out of curiosity.
What is the ``interrupt latency in the
88 matches
Mail list logo
