The latest version is always available at <http://www.tuxedo.org/~esr/cml2/>.
Release 2.1.4: Wed Jan 16 14:42:57 EST 2002
* Resync with 2.4.18-pre4 and 2.5.3-pre1.
* Fixed a nasty little bug in property computation.
* Fixed another nasty little bug in display of constraint violations.
I fat-fingered some display code in 2.1.3 while trying to do a better job of
passing rulesfile line number information back in error popups. This patch
fixes that problem.
The autoconfigurator is progressing nicely. It now generates a
correct configuration in "Look, ma! No hands." mode on three different
Intel boxes -- my all-PCI SCSI custom monster machine, an IDE-based IBM
Thinkpad laptop, and a hybrid PCI/ISA VA box from late '97.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The conclusion is thus inescapable that the history, concept, and
wording of the second amendment to the Constitution of the United
States, as well as its interpretation by every major commentator and
court in the first half-century after its ratification, indicates
that what is protected is an individual right of a private citizen
to own and carry firearms in a peaceful manner.
-- Report of the Subcommittee On The Constitution of the Committee On
The Judiciary, United States Senate, 97th Congress, second session
(February, 1982), SuDoc# Y4.J 89/2: Ar 5/5
On Wed, Jan 16, 2002 at 02:56:05PM -0500, Eric S. Raymond wrote:
> The latest version is always available at <http://www.tuxedo.org/~esr/cml2/>.
>
> Release 2.1.4: Wed Jan 16 14:42:57 EST 2002
I've verified that the lockup I reported earlier still happens with 2.1.4.
Ross Vandegrift
[email protected]
On Wed, Jan 16, 2002 at 05:43:40PM -0500, Eric S. Raymond wrote:
> Ross Vandegrift <[email protected]>:
> > On Wed, Jan 16, 2002 at 02:56:05PM -0500, Eric S. Raymond wrote:
> > I've verified that the lockup I reported earlier still happens with 2.1.4.
>
> Keystroke sequence to reproduce, please?
<ENTER>
> --
> <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
>
> "Taking my gun away because I might shoot someone is like cutting my tongue
> out because I might yell `Fire!' in a crowded theater."
> -- Peter Venetoklis
Ross Vandegrift <[email protected]>:
> On Wed, Jan 16, 2002 at 02:56:05PM -0500, Eric S. Raymond wrote:
> I've verified that the lockup I reported earlier still happens with 2.1.4.
Keystroke sequence to reproduce, please?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
"Taking my gun away because I might shoot someone is like cutting my tongue
out because I might yell `Fire!' in a crowded theater."
-- Peter Venetoklis
Ross Vandegrift <[email protected]>:
> On Wed, Jan 16, 2002 at 05:43:40PM -0500, Eric S. Raymond wrote:
> > Ross Vandegrift <[email protected]>:
> > > On Wed, Jan 16, 2002 at 02:56:05PM -0500, Eric S. Raymond wrote:
> > > I've verified that the lockup I reported earlier still happens with 2.1.4.
> >
> > Keystroke sequence to reproduce, please?
>
> <ENTER>
On what screen? With the tool invoked how?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
No matter how one approaches the figures, one is forced to the rather
startling conclusion that the use of firearms in crime was very much
less when there were no controls of any sort and when anyone,
convicted criminal or lunatic, could buy any type of firearm without
restriction. Half a century of strict controls on pistols has ended,
perversely, with a far greater use of this weapon in crime than ever
before.
-- Colin Greenwood, in the study "Firearms Control", 1972
I'd love to have a run-time tuneable kernel parameter that lets me use
do_gettimeofday() instead of get_fast_time for received packet
timestamping. Does this seem reasonable?
This is especially useful for me when I perform round trip time
measurements (despite the affects of interrupt latency).
Here's a patch against the 2.4.17. Modified files are
include/linux/sysctl.h, net/core/dev.c, and net/core/sysctrl_net_core.c.
The sysctl tuneable parameter is /proc/sys/net/core/hires_rx_timestamp,
which is set to 0 by default.
Feedback, advice would be appreciated.
Patch follows:
diff -urN -X dontdiff linux-2.4.17/include/linux/sysctl.h linux-2.4.17-wilson/include/linux/sysctl.h
--- linux-2.4.17/include/linux/sysctl.h Mon Nov 26 05:29:17 2001
+++ linux-2.4.17-wilson/include/linux/sysctl.h Wed Jan 16 11:54:00 2002
@@ -204,7 +204,8 @@
NET_CORE_NO_CONG_THRESH=13,
NET_CORE_NO_CONG=14,
NET_CORE_LO_CONG=15,
- NET_CORE_MOD_CONG=16
+ NET_CORE_MOD_CONG=16,
+ NET_CORE_HIRES_RX_TIMESTAMP=17
};
/* /proc/sys/net/ethernet */
diff -urN -X dontdiff linux-2.4.17/net/core/dev.c linux-2.4.17-wilson/net/core/dev.c
--- linux-2.4.17/net/core/dev.c Wed Nov 7 14:39:36 2001
+++ linux-2.4.17-wilson/net/core/dev.c Wed Jan 16 11:53:30 2002
@@ -1069,7 +1069,6 @@
/*=======================================================================
Receiver routines
=======================================================================*/
-
int netdev_max_backlog = 300;
/* These numbers are selected based on intuition and some
* experimentatiom, if you have more scientific way of doing this
@@ -1082,6 +1081,7 @@
struct netif_rx_stats netdev_rx_stat[NR_CPUS];
+int hires_rx_timestamp;
#ifdef CONFIG_NET_HW_FLOWCONTROL
atomic_t netdev_dropping = ATOMIC_INIT(0);
@@ -1217,8 +1217,12 @@
struct softnet_data *queue;
unsigned long flags;
- if (skb->stamp.tv_sec == 0)
- get_fast_time(&skb->stamp);
+ if (skb->stamp.tv_sec == 0) {
+ if (hires_rx_timestamp)
+ do_gettimeofday(&skb->stamp);
+ else
+ get_fast_time(&skb->stamp);
+ }
/* The code is rearranged so that the path is the most
short when CPU is congested, but is still operating.
diff -urN -X dontdiff linux-2.4.17/net/core/sysctl_net_core.c linux-2.4.17-wilson/net/core/sysctl_net_core.c
--- linux-2.4.17/net/core/sysctl_net_core.c Tue Oct 10 10:33:52 2000
+++ linux-2.4.17-wilson/net/core/sysctl_net_core.c Wed Jan 16 11:52:39 2002
@@ -19,6 +19,7 @@
extern int netdev_fastroute;
extern int net_msg_cost;
extern int net_msg_burst;
+extern int hires_rx_timestamp;
extern __u32 sysctl_wmem_max;
extern __u32 sysctl_rmem_max;
@@ -62,6 +63,9 @@
{NET_CORE_MOD_CONG, "mod_cong",
&mod_cong, sizeof(int), 0644, NULL,
&proc_dointvec},
+ {NET_CORE_HIRES_RX_TIMESTAMP, "hires_rx_timestamp",
+ &hires_rx_timestamp, sizeof(int), 0644, NULL,
+ &proc_dointvec},
#ifdef CONFIG_NET_FASTROUTE
{NET_CORE_FASTROUTE, "netdev_fastroute",
&netdev_fastroute, sizeof(int), 0644, NULL,
From: Wilson Yeung <[email protected]>
Date: Wed, 16 Jan 2002 15:33:04 -0800 (PST)
I'd love to have a run-time tuneable kernel parameter that lets me use
do_gettimeofday() instead of get_fast_time for received packet
timestamping. Does this seem reasonable?
Can you demonstrate a difference in accurace between these two
routines on any architecture :-)
> > > > I've verified that the lockup I reported earlier still happens with 2.1.4.
> > >
> > > Keystroke sequence to reproduce, please?
> >
> > <ENTER>
>
> On what screen? With the tool invoked how?
Sorry, didn't mean to be so terse. Same as before - 'make config' or 'make
menuconfig', press enter upon being shown the main menu while the default
selection is "Intel or Processor type (FROZEN)".
Ross Vandegrift
[email protected]
On Wed, 16 Jan 2002, David S. Miller wrote:
> I'd love to have a run-time tuneable kernel parameter that lets me use
> do_gettimeofday() instead of get_fast_time for received packet
> timestamping. Does this seem reasonable?
>
> Can you demonstrate a difference in accurace between these two
> routines on any architecture :-)
The discreprency is that get_fast_time() returns the current value of
xtime, while do_gettimeofday() may actually calculate the time and
consider both xtime and the jiffies.
From: Wilson Yeung <[email protected]>
Date: Wed, 16 Jan 2002 17:03:58 -0800 (PST)
The discreprency is that get_fast_time() returns the current value of
xtime, while do_gettimeofday() may actually calculate the time and
consider both xtime and the jiffies.
Look at the x86 implementation of do_fast_time, it equals
do_gettimeofday() when TSC is present which is the only time
that do_gettimeofday is going to be more accurate than xtime.
Franks a lot,
David S. Miller
[email protected]
On Wed, Jan 16, 2002 at 03:33:04PM -0800, Wilson Yeung wrote:
> I'd love to have a run-time tuneable kernel parameter that lets me use
> do_gettimeofday() instead of get_fast_time for received packet
> timestamping. Does this seem reasonable?
Both functions should just access the TSC of your CPU and be equivalent.
-Andi
Ross Vandegrift <[email protected]>:
> Sorry, didn't mean to be so terse. Same as before - 'make config' or 'make
> menuconfig', press enter upon being shown the main menu while the default
> selection is "Intel or Processor type (FROZEN)".
Got it. Looks like a bug I introduced when I filled someone else's request
to make frozen symbols invisible two point releases ago. I should have it
fixed tonight.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The danger (where there is any) from armed citizens, is only to the
*government*, not to *society*; and as long as they have nothing to
revenge in the government (which they cannot have while it is in their
own hands) there are many advantages in their being accustomed to the
use of arms, and no possible disadvantage.
-- Joel Barlow, "Advice to the Privileged Orders", 1792-93
Taking linux-net out of the distribution.
On Wed, 16 Jan 2002, David S. Miller wrote:
> From: Wilson Yeung <[email protected]>
> Date: Wed, 16 Jan 2002 17:03:58 -0800 (PST)
>
> The discreprency is that get_fast_time() returns the current value of
> xtime, while do_gettimeofday() may actually calculate the time and
> consider both xtime and the jiffies.
>
> Look at the x86 implementation of do_fast_time, it equals
> do_gettimeofday() when TSC is present which is the only time
> that do_gettimeofday is going to be more accurate than xtime.
That's interesting, because when I call do_gettimeofday() instead of
get_fast_time(), I get different kinds of results that imply that these
are not equivalent. I'm running the kernel on a PIII.
I'm looking at arch/i386/kernel/time.c, and I see the definition
you're talking about. I'm also looking at kernel/time.c, and I'm not sure
how these things are interacting yet.
Anyway...
I did a ping flood from a host on the LAN, and ran tcpdump.
Here is a sequence of timestamps when netif_rx() uses do_gettimeofday()
directly:
18:26:01.658704
18:26:01.658844
18:26:01.658851
18:26:01.658992
18:26:01.658998
Here is a sequence of timestamps when netif_rx() uses get_fast_time():
18:40:17.614165
18:40:17.614165
18:40:17.614165
18:40:17.614165
18:40:17.614165
Notice that all the timestamps are the same, which led me to believe that
xtime was being gotten directly.
But if they're defined to be the same, then my call to do_gettimeofday()
should have gotten similar results.
Wilson
Ross Vandegrift <[email protected]>:
> Sorry, didn't mean to be so terse. Same as before - 'make config' or 'make
> menuconfig', press enter upon being shown the main menu while the default
> selection is "Intel or Processor type (FROZEN)".
Thanks. Found and fixed. See 2.1.5
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
What if you were an idiot, and what if you were a member of Congress?
But I repeat myself. -- Mark Twain
From: Wilson Yeung <[email protected]>
Date: Wed, 16 Jan 2002 18:45:02 -0800 (PST)
Notice that all the timestamps are the same, which led me to believe that
xtime was being gotten directly.
This is what happens only if your CPU lacks a timestamp counter
(TSC on x86). What kind of CPU are you performing this experiment
on?
Good day!
I have the same problems with C-Media 8338A soundchip and the problem still exists with
linux kerner 2.4.17 and even with 2.4.18-pre3. Only wav files can be played with
no noise, mp3 and ogg files produce noisy hissing sound covering a somewhat
delayed music. I believe this is a kernel related problem.
Anybody find a solution to the problem? I found out that not only me have the
same problem. I have tried testing several releases of the linux kernel hoping someone
got it fixed with each release but still have hissing noise.
I've tried the generic 2.4.17 linux kernel, one with rml and another with mjc patches
and still have the same hissing noise every time I played mp3, ogg files using mpg123 or
xmms. I can only play .wav files with no noise using xmms or the command line "play" program.
The system is a PII 400MHz 440BX with an Audio Excel PCI soundcard (C-Media 8338A chip, using the
cmpci kernel module), with bt848 tv tuner (works fine with it's own audio out),
Mandrake 8.1 distribution (all required software by kernel to compile are installed).
--
Vernie
> From: CuPoTKa ([email protected])
> Subject: Kernel 2.4.6 bug - problems with CM8338A soundchip.
> Newsgroups: mlist.linux.kernel
> Date: 2001-07-16 00:40:32 PST
>
>
> Part of kernel.log:
> kernel: cm: version $Revision: 5.64 $ time 01:44:06 Jul 16 2001
> kernel: PCI: Found IRQ 10 for device 00:0f.0
> kernel: cm: found CM8338A adapter at io 0xdc00 irq 10
> Problem: Sound isn't smooth. It makes strange noise instead music.
> I use:
> Linux version 2.4.6 (gcc version 2.95.4 20010703 (Debian prerelease)).
> Debian testing/unstable linux.
> Single PII, 400Mhz CPU.
> M748MR PCCHIPS motherboard.
> Usefull information: I compiled 2 kernels with CMedia 8338 chip support.
> One is kernel 2.4.5 and another 2.4.6. It works with 2.4.5 and dosn't with
> 2.4.6.
> Thanks.
In article <[email protected]> you write:
| From: Wilson Yeung <[email protected]>
| Date: Wed, 16 Jan 2002 18:45:02 -0800 (PST)
|
| Notice that all the timestamps are the same, which led me to believe that
| xtime was being gotten directly.
|
| This is what happens only if your CPU lacks a timestamp counter
| (TSC on x86). What kind of CPU are you performing this experiment
| on?
In the part of the message you snipped:
> That's interesting, because when I call do_gettimeofday() instead of
> get_fast_time(), I get different kinds of results that imply that these
> are not equivalent. I'm running the kernel on a PIII.
I would think that was short for "Pentium-III" which should have TSC.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Thu, 2002-01-17 at 06:48, [email protected] wrote:
>
>
> Good day!
>
> I have the same problems with C-Media 8338A soundchip and the problem still exists with
> linux kerner 2.4.17 and even with 2.4.18-pre3. Only wav files can be played with
> no noise, mp3 and ogg files produce noisy hissing sound covering a somewhat
> delayed music. I believe this is a kernel related problem.
Same problem here, the sound driver is completely unusable as the music
(mp3) seems to play ten times slower than what it should.
My workaround is to use the alsa driver.
I think the driver broke near the beginning of the 2.4 stable series.
00:0c.0 Multimedia audio controller: C-Media Electronics Inc CM8338A
(rev 10)
Subsystem: C-Media Electronics Inc CMI8338/C3DX PCI Audio Device
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (500ns min, 6000ns max)
Interrupt: pin A routed to IRQ 18
Region 0: I/O ports at dc00 [size=256]
Capabilities: [c0] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-