* Re: [BENCHMARKS] Namesys VM patches improve kbuild
From: Nick Piggin @ 2004-01-26 11:25 UTC (permalink / raw)
To: Nikita Danilov; +Cc: Andrew Morton, linux-mm
In-Reply-To: <16404.63446.649110.348477@laputa.namesys.com>
Nikita Danilov wrote:
>Nick Piggin writes:
> >
>
>[...]
>
> >
> > But by clearing the referenced bit when below the reclaim_mapped
> > threshold, you're throwing this information away.
> >
> > Say you have 16 mapped pages on the active list, 8 referenced, 8 not.
> > You do a !reclaim_mapped scan. Your 16 pages are now in the same
> > order and none are referenced. You now do a reclaim_mapped scan and
> > reclaim 8 pages. 4 of them were the referenced ones, 4 were not.
> >
> > With my change, you would reclaim all 8 non referenced pages.
>
>Which is wrong, because none of them was referenced _recently_. These
>pages are cold, according to the VM's notion of hotness. (Long time
>probably has passed between !reclaim_mapped and reclaim_mapped scans in
>your example.)
>
Well you'd have to admit the referenced pages are hotter, but
I guess I can't argue with the numbers: it must not be very
significant.
I just wonder why your patch makes such an improvement. You're
basically putting mapped pages to one side until reclaim_mapped,
which is similar to what my patch does, right?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply
* Re: dxs_support detection or feature broken?
From: Takashi Iwai @ 2004-01-26 11:20 UTC (permalink / raw)
To: John Gotts; +Cc: alsa-devel
In-Reply-To: <200401240440.i0O4eIOv015342@ann-arbor.fmfts.com>
At Fri, 23 Jan 2004 23:40:18 -0500,
John Gotts wrote:
>
> I have an ASUS A7V8X motherboard with a VIA VT8233 audio controller equipped
> with SPDIF. I have a set of digital speakers and use the SPDIF out for
> everything possible. (The speakers will fall back to analog if there is no
> digital signal present.)
>
> 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233 AC97 Audio Controller (rev 50)
>
> For a long time (through 1.0.0rc1) I had been using plug:spdif as my audio
> device and aplay had no problems playing 22,050 Hz WAV files:
>
> aplay -D plug:spdif <filename>.wav
>
> But with 1.0.1 my speakers started playing 22,050 Hz WAV files at 48,000 Hz.
>
> After reading the following thread:
>
> http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg10448.html
>
> I added the following line to my /etc/modules.conf:
>
> options snd-via82xx dxs_support=3
>
> and plug:spdif is working again. One message says "By default snd-via82xx uses
> dxs_support=3 (except for certain known motherboards)." Either my motherboard
> should become unknown or this feature is not working correctly.
well, the dxs_support detection is correct.
the problem is that spdif doesn't support 22.5kHz but the via82xx
driver doesn't restrict the sample rates for spdif.
i guess 44.1khz sample can be played correctly even without "plug".
ok, this bug should be fixed in the future...
a workaround is to define your own pcm such as
pcm.myspdif {
type plug
slave {
pcm "spdif"
rate 48000
}
}
and
% apaly -Dmyspdif 22500hz.wav
Takashi
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: [BENCHMARKS] Namesys VM patches improve kbuild
From: Nikita Danilov @ 2004-01-26 11:19 UTC (permalink / raw)
To: Nick Piggin; +Cc: Andrew Morton, linux-mm
In-Reply-To: <4011C537.8040104@cyberone.com.au>
Nick Piggin writes:
>
[...]
>
> But by clearing the referenced bit when below the reclaim_mapped
> threshold, you're throwing this information away.
>
> Say you have 16 mapped pages on the active list, 8 referenced, 8 not.
> You do a !reclaim_mapped scan. Your 16 pages are now in the same
> order and none are referenced. You now do a reclaim_mapped scan and
> reclaim 8 pages. 4 of them were the referenced ones, 4 were not.
>
> With my change, you would reclaim all 8 non referenced pages.
Which is wrong, because none of them was referenced _recently_. These
pages are cold, according to the VM's notion of hotness. (Long time
probably has passed between !reclaim_mapped and reclaim_mapped scans in
your example.)
It seems correct to make deactivation decision on the basic of recent
accesses to the page rather than by checking whether page was ever
accessed.
>
Nikita.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
^ permalink raw reply
* Re: [2.0.39] drivers/char/baycom.c Zero Sized File
From: David Weinehall @ 2004-01-26 11:18 UTC (permalink / raw)
To: Coywolf Qi Hunt; +Cc: linux-kernel, Alan Cox
In-Reply-To: <4014EE22.9070902@lovecn.org>
On Mon, Jan 26, 2004 at 06:38:26PM +0800, Coywolf Qi Hunt wrote:
> Hello, David
>
> I downloaded 2.0.39 from kernel.org, and find that the file
> drivers/char/baycom.c is a zero sized.
> Also see this http://lxr.linux.no/source/drivers/char/baycom.c?v=2.0.39
>
> Only Documentation/magic-number.txt describes:
>
> BAYCOM_MAGIC 0x3105bac0 struct baycom_state drivers/char/baycom.c
drivers/char/baycom.c is zero-sized in 2.0.38 too, so at least it's not
my fault ;-)
I'm CC:ing Alan, he might have some idea?
Regards: David Weinehall
--
/) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
^ permalink raw reply
* meaning of sizeof(_OS)?
From: Micha Feigin @ 2004-01-26 11:16 UTC (permalink / raw)
To: acpi-devel
Was wondering at least theoretically what is supposed to be done
different by the dsdt if the os is M$ NT/XP since I saw there is an
explicit check of _OS against "Microsoft Windows NT".
Also I saw some people talking about a size check of the _OS variable
against 0x14 to see if its the M$ os. In my dsdt the check is for some
reason against 0x27, any idea what os its looking for? (is LEqual less
then or equall or does the L mean something else?)
Thanx
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* [uml-devel] [PATCH] mconsole fixes
From: Dan Shearer @ 2004-01-26 2:46 UTC (permalink / raw)
To: Jeff Dike; +Cc: user-mode-linux-devel
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
This makes uml_mconsole a bit more useful in scripts:
1. it exits with '1' for an error, '0' for no error. So you can
now tell if you have got a pty for a tty or not without scraping
text
2. has a more sensible error message where the pipe doesn't
exist
3. adds a local command called 'mconsole-version' (which will be
more useful as UML matures and the design of having all the
clever bits inside UML really shows its value.)
SGML docs not modified, because I don't know the convention for changing
them (eg, do you add new ENTITY entries for new authors, or does the
last author overwrite the previous...?)
--
Dan Shearer
dan@shearer.org
[-- Attachment #2: diff.mconsole --]
[-- Type: text/plain, Size: 6022 bytes --]
--- uml_mconsole.c.orig 2004-01-26 11:30:54.000000000 +1030
+++ uml_mconsole.c 2004-01-26 13:00:21.000000000 +1030
@@ -1,5 +1,30 @@
-/* Copyright 2001 Jeff Dike and others
- * Licensed under the GPL
+/* (c) Copyright 2001-2004 Jeff Dike and others
+ * Licensed under the GPL, see file COPYING
+ *
+ * This is uml_console version 2, a tool for querying a User Mode Linux
+ * instance over a local pipe connection. This tool does not
+ * (since uml_mconsole version 1) need to be in sync with the version
+ * of the UML kernel since the commands and their implementation
+ * are within UML. uml_mconsole just displays what UML tells it to.
+ * There are a very few local commands that this program knows
+ * about, but by default everything gets processed by UML.
+ *
+ * The uml_mconsole documentation distributed with covers all mconsole
+ * commands, so the docs have to be kept in sync with the kernel.
+ * In future it should be possible for the docs to come from (or be
+ * in common with) something over in the kernel source.
+ *
+ * If you are looking for the command implementation, go to the
+ * files mconsole_kern.c in the Linux kernel source under arch/um.
+ *
+ * The program exits with error values of:
+ *
+ * 0 No error
+ * 1 Error (need better breakdown of error type in future)
+ *
+ * Future TODO: return commandline results as a shell variable assignment
+ * eg: 'uml_mconsole config con0' might return "UML-CON=fd:0,fd:1"
+ *
*/
#include <stdio.h>
@@ -27,7 +52,7 @@
if(stat(file, &buf) == -1){
fprintf(stderr, "Warning: couldn't stat file: %s - ", file);
perror("");
- return(-1);
+ return(1);
}
sun.sun_family = AF_UNIX;
strncpy(sun.sun_path, file, sizeof(sun.sun_path));
@@ -183,7 +208,7 @@
return(1);
}
-static void default_cmd(int fd, char *command)
+static int default_cmd(int fd, char *command)
{
struct mconsole_request request;
struct mconsole_reply reply;
@@ -192,7 +217,7 @@
if((sscanf(command, "%128[^: \f\n\r\t\v]:", name) == 1) &&
(*(name + 1) == ':')){
- if(switch_common(name)) return;
+ if(switch_common(name)) return(1);
command = strchr(command, ':');
*command++ = '\0';
while(isspace(*command)) command++;
@@ -210,18 +235,21 @@
if(sendto(fd, &request, sizeof(request), 0, (struct sockaddr *) &sun,
sizeof(sun)) < 0){
- fprintf(stderr, "Sending command to '%s' : ", sun.sun_path);
- perror("");
- return;
+ if (strlen(sun.sun_path)==0) {
+ fprintf(stderr, "No connection exists, cannot send command.\n");
+ } else {
+ fprintf(stderr, "While sending command to '%s' : ", sun.sun_path);
+ perror("");
+ }
+ return(1);
}
first = 1;
do {
- int len = sizeof(sun);
n = recvfrom(fd, &reply, sizeof(reply), 0, NULL, 0);
if(n < 0){
perror("recvmsg");
- return;
+ return(1);
}
if(first){
@@ -235,31 +263,35 @@
} while(reply.more);
printf("\n");
+ if (reply.err) return(1); else return(0);
}
char *local_help =
"Additional local mconsole commands:\n\
quit - Quit mconsole\n\
switch <socket-name> - Switch control to the given machine\n\
- log -f <filename> - use contents of <filename> as UML log messages\n";
+ log -f <filename> - use contents of <filename> as UML log messages\n\
+ mconsole-version - version of this mconsole program\n";
-static void help_cmd(int fd, char *command)
+static int help_cmd(int fd, char *command)
{
default_cmd(fd, command);
printf("%s", local_help);
+ return(0);
}
-static void switch_cmd(int fd, char *command)
+static int switch_cmd(int fd, char *command)
{
char *ptr;
ptr = &command[strlen("switch")];
while(isspace(*ptr)) ptr++;
- if(switch_common(ptr)) return;
+ if(switch_common(ptr)) return(1);
printf("Switched to '%s'\n", ptr);
+ return(0);
}
-static void log_cmd(int fd, char *command)
+static int log_cmd(int fd, char *command)
{
int len, max, chunk, input_fd;
char *ptr, buf[sizeof(((struct mconsole_request *) NULL)->data)];
@@ -299,16 +331,23 @@
ptr += chunk;
}
}
+ return(0);
}
-static void quit_cmd(int fd, char *command)
+static int quit_cmd(int fd, char *command)
{
exit(0);
}
+static int mversion_cmd(int fd, char *command)
+{
+ printf("uml_mconsole client version %d\n",MCONSOLE_VERSION);
+ return(0);
+}
+
struct cmd {
char *command;
- void (*proc)(int, char *);
+ int (*proc)(int, char *);
};
static struct cmd cmds[] = {
@@ -316,14 +355,16 @@
{ "help", help_cmd },
{ "switch", switch_cmd },
{ "log", log_cmd },
+ { "mconsole-version", mversion_cmd },
{ NULL, default_cmd }
+ /* default_cmd means "send it to the UML" */
};
/* sends a command */
int issue_command(int fd, char *command)
{
char *ptr;
- int i;
+ int i=0,ret=0;
/* Trim trailing spaces left by readline's filename completion */
ptr = &command[strlen(command) - 1];
@@ -332,20 +373,20 @@
for(i = 0; i < sizeof(cmds)/sizeof(cmds[0]); i++){
if((cmds[i].command == NULL) ||
!strncmp(cmds[i].command, command, strlen(cmds[i].command))){
- (*cmds[i].proc)(fd, command);
+ ret=(int)(*cmds[i].proc)(fd, command);
break;
}
}
- /* in future, return command status */
- return 0;
+ return(ret);
+
}
/* sends a command in argv style array */
int issue_commandv(int fd, char **argv)
{
char *command;
- int len, i, status;
+ int len=-1, i=0, status=-2;
len = 1; /* space for trailing null */
for(i = 0; argv[i] != NULL; i++)
@@ -354,7 +395,7 @@
command = malloc(len);
if(command == NULL){
perror("issue_command");
- return(-1);
+ return(1);
}
command[0] = '\0';
@@ -401,7 +442,7 @@
}
if(argc>2)
- return issue_commandv(fd, argv+2);
+ exit(issue_commandv(fd,argv+2));
while(1){
char *command, prompt[1 + sizeof(uml_name) + 2 + 1];
@@ -416,5 +457,5 @@
free(command);
}
printf("\n");
- return(0);
+ exit(0);
}
^ permalink raw reply
* Re: config bug with sbawe and --with-isapnp=no
From: Takashi Iwai @ 2004-01-26 11:15 UTC (permalink / raw)
To: loritz; +Cc: alsa-devel
In-Reply-To: <200401241557.21770.loritz@fh-furtwangen.de>
At Sat, 24 Jan 2004 15:57:21 +0100,
Mario Loritz wrote:
>
> Am Freitag, 23. Januar 2004 12:49 schrieb Takashi Iwai:
> > i found the bug in adriver.h, which always defines CONFIG_PNP when
> > CONFIG_ISAPNP is set.
> >
> > the attached patches are the fix and clean-up for pnp.
> > please give a try.
> >
> >
> > Takashi
>
> After I applied the patches, something strange is happening:
> The module option "isapnp=yes/no" is not recognized anymore,
> regardless of the configure option "--with-isapnp=yes" or "no".
>
> The driver itself works, even if I compile with pnp. But why? I
> cannot tell the driver, that it shouldn't try pnp. Do you think
> the driver will still work when a pnp-card is used? I can't check
> this, because my sbawe32 is non-pnp.
>
> When those questions are answered and the module option
> "isapnp=yes/no" really isn't needed anymore, then I think the
> driver should be changed in the proposed way.
did you run cvscompile? otherwise it won't work properly.
Takashi
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* [parisc-linux] help installation failed on C240 (fx4) workstation
From: Reinhold Flecke CCF @ 2004-01-26 11:13 UTC (permalink / raw)
To: parisc-linux
[-- Attachment #1: Type: text/plain, Size: 715 bytes --]
I downloaded the "debian-30r2-hppa-binary-1.iso" and burned it to CD.
If I start the installation on my C240 (fx4) workstation with the command:
bo sescsi.2.0
it seems everything ok, until I get the message:
...If this is the last message you see, you may need to switch your console.
This is a common sympton sarch the FAQ and mailing list at
parisc-linux.org
After this nothing happens anymore.
I searched the FAQ and mailing list but I could not find a solution.
Anyone who can help?
Thanks in advance.
Best Regards
Reinhold Flecke
Reinhold Flecke CCF
Auf dem Anger 18
33165 Lichtenau-Husen
Fon: +49 (0)5292 930601 (Office)
+49 (0)700 93000093 (PR)
eMail: <mailto:Reinhold.Flecke@ccf-consulting.de>
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2056 bytes --]
^ permalink raw reply
* Re: [PATCH] Better "Losing Ticks" Error Message
From: Nikita Danilov @ 2004-01-26 11:10 UTC (permalink / raw)
To: timothy parkinson; +Cc: akpm, johnstul, linux-kernel
In-Reply-To: <20040124032147.GA177@h00a0cca1a6cf.ne.client2.attbi.com>
timothy parkinson writes:
>
> Andrew,
>
> Seems like a lot of people see the below error message, but aren't quite sure
> why it happens or how to fix it. I sure didn't.
>
> Here's my attempt at remedying that - Should apply cleanly against 2.6.1.
>
> Thanks,
> Timothy
>
> diff -urN linux-2.6.1-orig/arch/i386/kernel/timers/timer_tsc.c linux-2.6.1/arch/i386/kernel/timers/timer_tsc.c
> --- linux-2.6.1-orig/arch/i386/kernel/timers/timer_tsc.c 2004-01-09 01:59:46.000000000 -0500
> +++ linux-2.6.1/arch/i386/kernel/timers/timer_tsc.c 2004-01-23 21:16:24.000000000 -0500
> @@ -232,9 +232,13 @@
> /* sanity check to ensure we're not always losing ticks */
> if (lost_count++ > 100) {
> printk(KERN_WARNING "Losing too many ticks!\n");
> - printk(KERN_WARNING "TSC cannot be used as a timesource."
> - " (Are you running with SpeedStep?)\n");
> - printk(KERN_WARNING "Falling back to a sane timesource.\n");
> + printk(KERN_WARNING "TSC cannot be used as a timesource. ");
> + printk(KERN_WARNING "Possible reasons for this are:\n");
> + printk(KERN_WARNING " You're running with Speedstep,\n");
> + printk(KERN_WARNING " You don't have DMA enabled for your hard disk (see hdparm),\n");
> + printk(KERN_WARNING " Incorrect TSC synchronization on an SMP system (see dmesg).\n");
+#ifdef CONFIG_KGDB
+ printk(KERN_WARNING " You're single-stepping under kgdb (see what you are doing).\n");
+#endif
Modulo that person debugging kernel with kgdb probably understands this
anyway.
> + printk(KERN_WARNING "Falling back to a sane timesource now.\n");
> +
Nikita.
^ permalink raw reply
* Re: [PATCH] oprofile per-cpu buffer overrun
From: Nick Piggin @ 2004-01-26 11:07 UTC (permalink / raw)
To: John Levon; +Cc: Andrew Morton, Philippe Elie, linux-kernel
In-Reply-To: <20040126103237.GA52771@compsoc.man.ac.uk>
John Levon wrote:
>On Sun, Jan 25, 2004 at 08:07:01PM -0800, Andrew Morton wrote:
>
>
>>When implementing a circular buffer it is better to not constrain the head
>>and tail indices - just let them grow and wrap without bound. You only need
>>to bring them in-bounds when you actually use them to index the buffer.
>>
>
>I'm not sure why that's better.
>
>
>>- head-tail is always the amount of used space, no need to futz around
>> handling the case where one has wrapped and the other hasn't.
>>
>
>I admit I have a hangover, but it seems to me it would actually be more
>complicated to make damn sure that the integer overflow case is
>definitely handled properly.
>
You needn't worry about integer overflow - it is handled properly ;)
^ permalink raw reply
* Re: Test suite?
From: Nikita Danilov @ 2004-01-26 11:04 UTC (permalink / raw)
To: Yusuf Goolamabbas; +Cc: markw, john.l.villalovos, reiserfs-list
In-Reply-To: <20040126093907.GA26428@outblaze.com>
Yusuf Goolamabbas writes:
> Could you also consider fstress which provides for a SPECsfs97 like
> workload
I know about it, but it claims to be NFS-server oriented benchmark.
Probably we should try it anyway, thanks for the pointer.
>
> http://www.cs.duke.edu/ari/fstress/
>
> Regards, Yusuf
Nikita.
^ permalink raw reply
* [parisc-linux] installation failed on C240 (fx4) workstation
From: Reinhold Flecke CCF @ 2004-01-26 10:54 UTC (permalink / raw)
To: parisc-linux
[-- Attachment #1: Type: text/plain, Size: 675 bytes --]
I downloaded the "debian-30r2-hppa-binary-1.iso" and burned it to CD.
If I start the installation on my C240 (fx4) workstation with the command:
bo sescsi.2.0
it seems everything ok, until I get the message:
...If this is the last message you see, you may need to switch your console.
This is a common sympton sarch the FAQ and mailing list at
parisc-linux.org
After this nothing happens anymore.
I searched the FAQ and mailing list but I could not find a solution.
Anyone who can help?
Thanks in advance.
Best Regards
Reinhold Flecke
Reinhold Flecke CCF
Fon: +49 (0)5292 930601 (Office)
+49 (0)700 93000093 (PR)
eMail: <mailto:Reinhold.Flecke@ccf-consulting.de>
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 2008 bytes --]
^ permalink raw reply
* Re: bad dsdt?
From: Sebastian Henschel @ 2004-01-26 10:53 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <200401211345.58192.vherried-rEckef8uG3NTGrOy2lmfZw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
hi vince...
* Vince Herried <vherried-rEckef8uG3NTGrOy2lmfZw@public.gmane.org> [2004-01-25 10:10 +0100]:
> I'm runnin a vanilla 2.6.1 kernel on a Dell Latitude C810
> and have a bunch of issues.
>
> The Fn keys don't work (eg Fn <suspend>, Fn <setup>, Fn .....>
> yes I enabled the acpi fn key option.
>
>
> /proc/acpi has no information about my battery, or temperature, or....
but /proc/acpi/info exists? what does it say?
>
> I'm thinking I should make multiple problem records with bugzilla (and where
> is that?)
http://bugzilla.kernel.org/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&component=ACPI.
> and what kind of doc do I supply besides dsdt and .config file?
please see the front page of http://acpi.sf.net
cheers,
sebastian
--
::: .O.
::: ..O
::: OOO
::: lynx -source http://www.kodeaffe.de/shensche.pub | gpg --import
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: PATCH: Aureal vortex alsa-kernel.
From: Takashi Iwai @ 2004-01-26 10:51 UTC (permalink / raw)
To: manuel.jander; +Cc: alsa-devel
In-Reply-To: <s5hwu7fuhic.wl@alsa2.suse.de>
At Mon, 26 Jan 2004 11:32:59 +0100,
I wrote:
>
> Hi Manuel,
>
> At Sat, 24 Jan 2004 20:19:36 -0400,
> Manuel Jander wrote:
> >
> > Hi,
> >
> > To the ALSA tree maintainers:
> >
> > I have uploaded a patch which moves the current Aureal driver into the
> > alsa-kernel/ directory. Please apply it, because many people are waiting
> > for it since a long time, and the driver is working stable. I really
> > need this to be done, please.
> >
> > Patch location:
> > http://galadriel.mat.utfsm.cl/~mjander/aureal/alsa/patch.gz
> > (about 100KiB)
>
> oh i wanted to ask you today the exactly same thing, but you must have
> seen it via a tarot card :)
>
> the patch looks nice, but please clean up the codes a bit more before
> merging to alsa-kernel, namely,
>
> - use the correct tab width (8) and indentation.
> e.g. the open brace are usually put in the next line.
>
> - remove the unnecessary (and skeptical) codes such as disasembling or
> c++ codes from somewhere else. only your own codes, please.
>
> - put GPL notice to each file.
> ok, we don't need it for au8810.c & co...
>
> - add EXPORT_NO_SYMBOLS; to the main file of alsa-driver (not
> alsa-kernel). apparently we have forgotten that.
also, give the patch for ALSA-Configuration.txt, too.
Takashi
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Bug in virtual console scrollback buffer?
From: goblin @ 2004-01-26 10:49 UTC (permalink / raw)
To: linux-kernel
1. I think I found a bug in linux' 2.6.1 vt scrollback buffer
2. I've noticed some changes in linux 2.6.1 scrollback buffer.
I'm not sure, but I once noticed that Shift-PgUp worked even after
switching a console (Alt-F?). Few days later I wanted to check this
out and test it again. Well, it didn't work. But I noticed a wierd thing:
After switching the console you are normally unable to see the scrollback
buffer. But when program "screen" is run, you may view it's internal
console scrollback buffer using ^A,^[ (and pg-ups). It's nothing unusual
in this, but when you leave the copy mode (eg. with Esc) and use
kernel's internal Shift-PgUp, you are able to see the scrollback buffers
of previously used virtual consoles. I think this may even be a security
violation as you can see what root typed on his console and sometimes
even recent dmesg messages. More to this, sometimes text in scrolled
back buffers is shifted to the right about 16 chars (when you toy
with Shift-PgUp/PgDn you notice it's sometimes normal, sometimes shifted).
I'm not sure whether or not this behavior is intended, but it seems
a bug for me. Well, I wasn't able to get any oops, thrash on screen,
segfault or any error like that, the kernel remained stable all the time.
3. (keywords:) screen, vt, scrollback
4. kernel version:
Linux version 2.6.1 (goblin@goblin) (gcc version 3.2.3) #2
Wed Jan 21 08:42:57 CET 2004
5. No oops message or any kernel destabilization
6. To trigger the problem, use the program screen and it's scrollback
buffer with Ctrl-A, Ctrl-[.
7. Environment:
7.1 software
Screen version 3.09.15 (FAU) 13-Mar-03
sh ver_linux:
Linux goblin 2.6.1 #2 Wed Jan 21 08:42:57 CET 2004 i686 unknown unknown GNU/Linux
Gnu C 3.2.3
Gnu make 3.80
util-linux 2.12
mount 2.12
module-init-tools 0.9.14
e2fsprogs 1.34
jfsutils 1.1.3
xfsprogs 2.5.6
pcmcia-cs 3.2.5
PPP 2.4.1
nfs-utils 1.0.6
Linux C Library 2.3.2
Dynamic linker (ldd) 2.3.2
Linux C++ Library 5.0.3
Procps 2.0.16
Net-tools 1.60
Kbd 1.08
Sh-utils 5.0
(No loaded modules)
Kernel is compiled with framebuffer console as a module, but
this module isn't in use (and wasn't since boot). I use only
text-mode console for this, I haven't tested this bug with
framebuffer device yet.
7.2 processor:
goblin@goblin:/usr/src/linux/scripts$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes) // it's actually a Celeron
stepping : 1
cpu MHz : 300.821
cache size : 32 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr
bogomips : 591.87
7.3
no modules loaded
7.4 and the rest:
Well, I have a 2mb-s3 virge(pci) and temporarily 32mb-s3 savage (agp),
but this shouldn't be relevant as the bug occurs in text mode.
By the way, why in 2.6 I've 8 Bogomips less than in 2.4? ;-)
If possible, I'd like to hear from you about this bug
Thank you and may the penguins be with you :-)
--
Goblin
Robert Goliasz
goblin@ajt.k5.pl
or rgoliasz@poczta.onet.pl
^ permalink raw reply
* Re: Protecting against DoS
From: Pasi Kärkkäinen @ 2004-01-26 10:45 UTC (permalink / raw)
To: Peter Frischknecht; +Cc: netfilter
In-Reply-To: <1073785847.9615.487.camel@peterlaptop>
On Sat, Jan 10, 2004 at 08:50:50PM -0500, Peter Frischknecht wrote:
> Hello,
>
> I wanted to let you know that you are not alone.
> We manage networks in apartment complexes. Hundreds of students use
> their computers simultaneously and we have always been able to deal with
> DoS attacks.
>
Hello!
> The attack you described is identical to the one we have suffered since
> sometime in September. In short: it cannot be stopped. But there are
> many things you can do.
>
> As you may have found in personal research, the worm has the following
> characteristics:
> 1 - It is a Zombie. Computers do NOT automatically start attacking web
> sites. They wait for an instruction from outside.
> 2 - The connection to the outside "master server" is done via IRC.
> 3 - The infected computer attacks 1 to a few web servers at a time. (we
> have never seen more than 3).
> 4 - Completely random spoofed src addresses.
> 5 - The MAC address is (Thank You GOD) not being spoofed.
> 6 - The intensity of the attack deems the offending computer almost
> useless during the attack.
>
Yes, sounds like the same thing.
> It seemed from your description that your network was fairly small.
> In order to save bandwidth, we implement a transparent caching
> strategy. So we redirect port 80 to the cache. Guess what!!! Our
> caching server ends up the target of the attack!!!
>
Hehe.
> I can tell you that I tried every pertinent module in the patch-o-matic
> volume. It was a 3 month ordeal with very frequent lockups. "connlimit"
> does not work because once you enable SYN cookies, there are no
> connections to limit. "limit" draws too much CPU power, eventually
> helping lock up the box.
>
Hmm.. how did you set up the limits? I wrote small application that
calculates the average new connections/sec rates and I then set up the
limits according to that..
> Blocking the foreign IP sources at the FORWARD level (or INPUT in my
> case) stopped the packets, but still kept my server with a very high
> system use.
>
> I have hundreds of rules in the MANGLE and NAT tables, so the bad
> packets were still traveling and being matched against all those rules.
> I placed the drops for the foreign IPs in the MANGLE table. If you look
> at the docs, it is the first table the packet hits.
>
Yep. It seems to be very difficult to protect against these kind of
attacks..
> BTW, to stop foreign IP packets, I created one ACCEP rule for every
> known IP class inside my network. The last line simply DROPs everything
> coming from the internal network.
>
I'm doing this also.
> My networks are basically functional now. But the HIGH CPU use
> persists. It is likely caused by the interrupt handling or the packet
> counters/rules checking. I recently ran accross this page on lowering
> the interrupt handling:
> ftp://robur.slu.se/pub/Linux/net-development/NAPI/NAPI_HOWTO.txt
>
> Feel free to correspond with me. We can trade ideas on the topic.
>
Sorry for the long delay in the answer :)
-- Pasi Kärkkäinen
^
. .
Linux
/ - \
Choice.of.the
.Next.Generation.
^ permalink raw reply
* [linux-lvm] Re: LVM2 + Linux 2.6.1 questions
From: Måns Rullgård @ 2004-01-26 10:44 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <web-216233373@mail01.infosat.net>
"Dale Gallagher" <foobar@mighty.co.za> writes:
> Hi there
>
> I've successfully setup LVM2.2.00.08 and
> device-mapper.1.00.07 on a Slackware 9.1 host with Linux
> 2.6.1. I have a question or two:
>
> 1) Would a shutdown error something like the following, be
> attributed to LVM and/or device-mapper?
>
> /proc/devices: fopen failed - no such file or directory
It's probably caused by LVM. I see them too. Everything works
anyway, so I don't care that much.
> 2) Why do I see, for example, a /dev/mapper/v01-home entry,
> instead of /dev/v01/home, when running 'df' and 'mount'? I
> see that /dev/mapper/v01/home symlinks to
> /dev/mapper/v01-home, which must account for this, though I
> thought that because I'd specified /dev/v01/home, that it'd
> appear as such? Not that this really matters I suppose ;-)
I see the /dev/vg/link name.
> $ df -h | grep v01
> /dev/mapper/v01-home 2.9G 444M 2.4G 16% /home
> /dev/mapper/v01-usr 2.0G 1.1G 760M 60% /usr
> /dev/mapper/v01-var 985M 30M 906M 4% /var
>
> $ mount | grep v01
> /dev/mapper/v01-home on /home type ext3 (rw)
> /dev/mapper/v01-usr on /usr type ext3 (rw)
> /dev/mapper/v01-var on /var type ext3 (rw)
>
> 3) Does anyone know when LVM2 specific docs, such as a
> HOWTO and FAQ will be available?
It doesn't seem like you need one, if you've gotten this far.
--
Måns Rullgård
mru@kth.se
^ permalink raw reply
* Re: Is there a way to keep the 2.6 kjournald from writing to idle disks? (to allow spin-downs)
From: Bart Samwel @ 2004-01-26 10:43 UTC (permalink / raw)
To: Lutz Vieweg; +Cc: Felipe Alfaro Solana, Linux Kernel Mailinglist, adilger
In-Reply-To: <4014E8E6.7050007@isg.de>
Lutz Vieweg wrote:
> It's not a laptop, but a server with an ordinary 3.5" harddisk I'm
> speaking about,
> my goal is not saving power, but spinning down a harddisk that does not
> need to
> spin up the whole day long.
>
> What I'm questioning is whether there's a need to write to idle disks at
> all -
> does anybody know why kjournald writes data even if there is nothing to
> commit at all?
Hmmm. My 2nd HD (that I almost never use) is set to hdparm -S 4 (20
seconds), it has an ext3 filesystem on it, and it spins down some 20
seconds after mounting and never spins up again. I haven't had to set
any options to make this possible. Is it possible that there may still
be something that is dirtying blocks on that disk? (If you want to check
this out, laptop_mode has a /proc/sys/vm/block_dump setting that makes
the kernel log all reads, writes and block dirtyings.)
-- Bart
^ permalink raw reply
* Re: Is there a way to keep the 2.6 kjournald from writing to idle disks? (to allow spin-downs)
From: Nick Piggin @ 2004-01-26 10:43 UTC (permalink / raw)
To: Lutz Vieweg; +Cc: Felipe Alfaro Solana, Linux Kernel Mailinglist, adilger
In-Reply-To: <4014E8E6.7050007@isg.de>
Lutz Vieweg wrote:
> Felipe Alfaro Solana wrote:
>
>> On Sun, 2004-01-25 at 19:29, Lutz Vieweg wrote:
>>
>>> I run a server that usually doesn't have to do anything on the local
>>> filesystems,
>>> it just needs to answer some requests and perform some computations
>>> in RAM.
>>>
>>> So I use the "hdparm -S 123" parameter setting to keep the (IDE)
>>> system disk from
>>> spinning unneccessarily.
>>>
>>> Alas, since an upgrade to kernel 2.6 and ext3 filesystem, I cannot
>>> find a way to
>>> let the harddisk spin down - I found out that "kjournald" writes a
>>> few blocks every
>>> few seconds.
>>>
>>> As I wouldn't like to downgrade to ext2: Is there any way to keep
>>> the 2.6 kjournald
>>> from writing to idle disks?
>>>
>>> I cannot see a good reason why kjournald would write when there are
>>> no dirty buffers -
>>> but still it does.
>>
>>
>>
>> Have you tried playing with the laptop-mode patch? It's already in the
>> -mm kernel tree from Andrew Morton. I've been playing with it a little
>> (just a few minutes) and seems keep the disks spun down for some time.
>
>
> This "laptop-mode" patch would make things far worse than they're now:
> Spinning
> up the disk about every 10min would reduce their lifetime
> significantly instead
> of extending it.
>
> It's not a laptop, but a server with an ordinary 3.5" harddisk I'm
> speaking about,
> my goal is not saving power, but spinning down a harddisk that does
> not need to
> spin up the whole day long.
>
> What I'm questioning is whether there's a need to write to idle disks
> at all -
> does anybody know why kjournald writes data even if there is nothing
> to commit at all?
Because you aren't using the noatime option?
^ permalink raw reply
* [2.0.39] drivers/char/baycom.c Zero Sized File
From: Coywolf Qi Hunt @ 2004-01-26 10:38 UTC (permalink / raw)
To: tao; +Cc: linux-kernel
Hello, David
I downloaded 2.0.39 from kernel.org, and find that the file
drivers/char/baycom.c is a zero sized.
Also see this http://lxr.linux.no/source/drivers/char/baycom.c?v=2.0.39
Only Documentation/magic-number.txt describes:
BAYCOM_MAGIC 0x3105bac0 struct baycom_state drivers/char/baycom.c
also thanks to Segher Boessenkool
Coywolf Q. Hunt
^ permalink raw reply
* Re: Linux v2.6.2-rc2
From: Tim Cambrant @ 2004-01-26 10:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.58.0401251844440.32583@home.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 4404 bytes --]
On Sun, Jan 25, 2004 at 06:48:24PM -0800, Linus Torvalds wrote:
> Summary of changes from v2.6.2-rc1 to v2.6.2-rc2
Hello Linus,
2.6.2-rc2 doesn't compile cleanly with the latest GCC 3.4 with my
configuration, because of several extern inline declarations in
include-files. The same problem existed in 2.6.2-rc1-mm2 and earlier,
and was fixed in -mm3. The fix is to simply remove 'inline' from the
funcion declaration. Andrew Morton has confirmed this and has applied
patches like this into his tree. Here are patches to fix the errors:
--- linux-2.6.2-rc2/include/linux/efi.h.orig Mon Jan 26 11:09:08 2004
+++ linux-2.6.2-rc2/include/linux/efi.h Mon Jan 26 11:09:18 2004
@@ -297,8 +297,8 @@ extern u64 efi_mem_attributes (unsigned
extern void efi_initialize_iomem_resources(struct resource *code_resource,
struct resource *data_resource);
extern efi_status_t phys_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc);
-extern inline unsigned long __init efi_get_time(void);
-extern inline int __init efi_set_rtc_mmss(unsigned long nowtime);
+extern unsigned long __init efi_get_time(void);
+extern int __init efi_set_rtc_mmss(unsigned long nowtime);
extern struct efi_memory_map memmap;
/*
-------
--- linux-2.6.2-rc2/include/linux/sched.h.orig Mon Jan 26 11:17:39 2004
+++ linux-2.6.2-rc2/include/linux/sched.h Mon Jan 26 11:18:35 2004
@@ -670,7 +670,7 @@ static inline int capable(int cap)
extern struct mm_struct * mm_alloc(void);
/* mmdrop drops the mm and the page tables */
-extern inline void FASTCALL(__mmdrop(struct mm_struct *));
+extern void FASTCALL(__mmdrop(struct mm_struct *));
static inline void mmdrop(struct mm_struct * mm)
{
if (atomic_dec_and_test(&mm->mm_count))
-------
--- linux-2.6.2-rc2/include/linux/bio.h.orig Mon Jan 26 11:22:45 2004
+++ linux-2.6.2-rc2/include/linux/bio.h Mon Jan 26 11:23:05 2004
@@ -231,8 +231,8 @@ extern void bio_put(struct bio *);
extern void bio_endio(struct bio *, unsigned int, int);
struct request_queue;
-extern inline int bio_phys_segments(struct request_queue *, struct bio *);
-extern inline int bio_hw_segments(struct request_queue *, struct bio *);
+extern int bio_phys_segments(struct request_queue *, struct bio *);
+extern int bio_hw_segments(struct request_queue *, struct bio *);
extern inline void __bio_clone(struct bio *, struct bio *);
extern struct bio *bio_clone(struct bio *, int);
-------
--- linux-2.6.2-rc2/include/linux/elevator.h.orig Mon Jan 26 11:25:09 2004
+++ linux-2.6.2-rc2/include/linux/elevator.h Mon Jan 26 11:25:30 2004
@@ -96,9 +96,9 @@ extern elevator_t iosched_as;
extern int elevator_init(request_queue_t *, elevator_t *);
extern void elevator_exit(request_queue_t *);
-extern inline int elv_rq_merge_ok(struct request *, struct bio *);
-extern inline int elv_try_merge(struct request *, struct bio *);
-extern inline int elv_try_last_merge(request_queue_t *, struct bio *);
+extern int elv_rq_merge_ok(struct request *, struct bio *);
+extern int elv_try_merge(struct request *, struct bio *);
+extern int elv_try_last_merge(request_queue_t *, struct bio *);
/*
* Return values from elevator merger
-------
--- linux-2.6.2-rc2/include/linux/ide.h.orig Mon Jan 26 11:27:37 2004
+++ linux-2.6.2-rc2/include/linux/ide.h Mon Jan 26 11:28:36 2004
@@ -1417,12 +1417,12 @@ typedef struct pkt_task_s {
void *special;
} pkt_task_t;
-extern inline u32 ide_read_24(ide_drive_t *);
+extern u32 ide_read_24(ide_drive_t *);
-extern inline void SELECT_DRIVE(ide_drive_t *);
-extern inline void SELECT_INTERRUPT(ide_drive_t *);
-extern inline void SELECT_MASK(ide_drive_t *, int);
-extern inline void QUIRK_LIST(ide_drive_t *);
+extern void SELECT_DRIVE(ide_drive_t *);
+extern void SELECT_INTERRUPT(ide_drive_t *);
+extern void SELECT_MASK(ide_drive_t *, int);
+extern void QUIRK_LIST(ide_drive_t *);
extern void ata_input_data(ide_drive_t *, void *, u32);
extern void ata_output_data(ide_drive_t *, void *, u32);
-------
I understand if you won't apply these int your tree. Perhaps the same
fixes are on their way into the vanilla kernel from Andrew's tree. If
that's the case, you can feel free to ignore these patches.
Tim Cambrant
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [LARTC] IMQ Stability
From: Remus @ 2004-01-26 10:36 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-105066408632475@msgid-missing>
Hi Roy,
Excelent Roy!!!
Good job.
Where we can get your IMQ port to test?
Best Regards
Remus
----- Original Message -----
From: "Roy" <roy@xxx.lt>
To: <lartc@mailman.ds9a.nl>
Sent: Sunday, January 25, 2004 3:49 AM
Subject: Re: [LARTC] IMQ Stability
> Internet (eth0) <-> ppp0 ----- ppp1 <-> LAN (eth1) 10.0.0.0/8
>
>
> this way dont seem excelent because it still lacks some functionality
> and what about using LO or dummy type interface instead of ppp?
>
> the new imq driver that i am developing will have unlimited posibilities
> it willbe fake interface wich passes all ip trafic without exception no
> mater which direction, destination and so on
> even localy generated and received trafic should pass it
> I removed iptables module so noo need to configure it just everything is
> catched.
> so you will be able to shape in + out in one
>
> also I am thinking about the chaining functionality
> is there any need to make chain of imq devices ? ( they will get the all
> same trafic)
> you will be able to use few shapers then but it will add latency.
>
> I almost finished my driver , but unfortunately there is no way to avoid
> patching kernel.
>
> I need to export ip_finish_output2 and ip_local_deliver_finish functions
but
> dont know how to do that, and where is the best place.
>
>
>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [2.6.x] e1000: NETDEV WATCHDOG: eth0: transmit timed out
From: Petr Sebor @ 2004-01-26 10:33 UTC (permalink / raw)
To: Feldman, Scott; +Cc: linux-kernel
In-Reply-To: <C6F5CF431189FA4CBAEC9E7DD5441E0102229D92@orsmsx402.jf.intel.com>
Feldman, Scott wrote:
>>since we have upgraded cabling on our network and transfer
>>speeds increased a little bit, we are experiencing very often
>>situations where the Intel PRO/1000 nics just stop responding
>>and network dies for a while. Local console works, there are
>>no more error messages other than (when the eth0 comes to a
>>life again):
>>
>>NETDEV WATCHDOG: eth0: transmit timed out
>>e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex
>>
>>
>
>Petr, I need you to try something. Get ethtool 1.8
>(sf.net/projects/gkernel) and turn off TSO:
>
> # ethtool -K eth0 tso off
>
>If you now longer see NETDEV WATCHDOG's, I have a next step. More on
>that later.
>
>-scott
>
>
Scott,
after a weekend and half of working day (with extra torturing of the
network card)
the NETDEV WATCHDOG's are not barking anymore with the tso's disabled.
Do you want me to do more testing or will you tell me what _the_ next
step is ? :-)
Regards,
Petr
^ permalink raw reply
* Re: PATCH: Aureal vortex alsa-kernel.
From: Takashi Iwai @ 2004-01-26 10:32 UTC (permalink / raw)
To: manuel.jander; +Cc: alsa-devel
In-Reply-To: <1074989976.18361.42.camel@localhost>
Hi Manuel,
At Sat, 24 Jan 2004 20:19:36 -0400,
Manuel Jander wrote:
>
> Hi,
>
> To the ALSA tree maintainers:
>
> I have uploaded a patch which moves the current Aureal driver into the
> alsa-kernel/ directory. Please apply it, because many people are waiting
> for it since a long time, and the driver is working stable. I really
> need this to be done, please.
>
> Patch location:
> http://galadriel.mat.utfsm.cl/~mjander/aureal/alsa/patch.gz
> (about 100KiB)
oh i wanted to ask you today the exactly same thing, but you must have
seen it via a tarot card :)
the patch looks nice, but please clean up the codes a bit more before
merging to alsa-kernel, namely,
- use the correct tab width (8) and indentation.
e.g. the open brace are usually put in the next line.
- remove the unnecessary (and skeptical) codes such as disasembling or
c++ codes from somewhere else. only your own codes, please.
- put GPL notice to each file.
ok, we don't need it for au8810.c & co...
- add EXPORT_NO_SYMBOLS; to the main file of alsa-driver (not
alsa-kernel). apparently we have forgotten that.
thanks,
Takashi
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: [PATCH] oprofile per-cpu buffer overrun
From: John Levon @ 2004-01-26 10:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: Philippe Elie, linux-kernel
In-Reply-To: <20040125200701.3c7b769a.akpm@osdl.org>
On Sun, Jan 25, 2004 at 08:07:01PM -0800, Andrew Morton wrote:
> When implementing a circular buffer it is better to not constrain the head
> and tail indices - just let them grow and wrap without bound. You only need
> to bring them in-bounds when you actually use them to index the buffer.
I'm not sure why that's better.
> - head-tail is always the amount of used space, no need to futz around
> handling the case where one has wrapped and the other hasn't.
I admit I have a hangover, but it seems to me it would actually be more
complicated to make damn sure that the integer overflow case is
definitely handled properly.
I clearly can't write functioning ring buffers :), so I'd prefer it to
stay as simple as possible.
regards,
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.