* Re: remove usage of __MOD_XXX_USAGE_COUNT and derivatives
From: Anders Fugmann @ 2003-01-10 15:21 UTC (permalink / raw)
To: Harald Welte; +Cc: netfilter-devel
In-Reply-To: <20030110134959.GE9467@sunbeam.de.gnumonks.org>
Harald Welte wrote:
> On Fri, Jan 10, 2003 at 02:49:31PM +0100, Anders Fugmann wrote:
>
> I don't think that this is necessarry. What is in fact necessarry, is
> increasing the module use count for every rule created. Otherwise it
> would state 'iptable_filter:unused' in case you had 10 dropping rules.
> This used to be the old behaviour, but confused a couple of users... so
> we decided to change it.
Ok - I will split my answer up into two parts.
1. It seems that we agree upon modules should not have their module
count increased because a new module is loaded. This is the current case.
2. If the general design goal is to have modules reflect all rules, I
guess that the sum of all module counts should be equal or greater than
the total number of rules. If this is the case, then where which module
should be increased when inserting the rule "iptables -A INPUT". In
general - Should not iptables_filter's module count be incremented for
every inserted rule in the filter tabel (Same goes for NAT and MANGLE).
I'm asking, as I'm willing to spend some time understanding the system,
and make patches for Netfilter.
Regards
Anders Fugmann
^ permalink raw reply
* RE: Nvidia and its choice to read the GPL "differently"
From: Larry Sendlosky @ 2003-01-10 15:29 UTC (permalink / raw)
To: Richard Stallman; +Cc: linux-kernel
Richard,
We all know that "Linux" would not be where it is today without
the GNU software. I don't recall seeing one post in this
looonnngg thread that tries to say otherwise. Myself, and many others,
are very grateful for your and the FSF's work. PLEASE, stop hitting us
over the head with GNU/Linux.
I'm sure there are many other "things" that have gotten broad public
attention and the real people or organizations behind it have not gotten
the credit they deserve either by what the "thing" is called or by
the press, etc. Only the people truly involved with the "thing"
know who is responsible. I think the same applies here.
And, why is it only *you* beating us over the head with GNU/Linux?
Where's the rest for the GNU (non-linux specific) contributors?
Why aren't they bitching/whining too?
Like I said before, we aren't the people you have to educate/convince.
If it really means that much to you (and it seems to me that it does),
then you should be taking out magazine ads and buying time on TV
to reach the uneducated masses.
-----Original Message-----
From: Larry McVoy [mailto:lm@bitmover.com]
Sent: Thursday, January 09, 2003 6:39 PM
To: Richard Stallman
Cc: Vlad@Vlad.geekizoid.com; linux-kernel@vger.kernel.org
Subject: Re: Nvidia and its choice to read the GPL "differently"
On Thu, Jan 09, 2003 at 06:14:20PM -0500, Richard Stallman wrote:
> GNU, the system we were developing, was most of the early GNU/Linux
> system in 1992. GNU in 1992 included non-GNU packages such as X11,
> and TeX.
Wow. That might be one for the quotes file:
"GNU ... was of the early GNU/Linux system. GNU ... included non-GNU"
Well, that certainly explains a lot. If you define GNU as "anything
which might be found on a Linux distro including non-GNU packages",
your position starts to make a certain twisted sense. Only one problem
with that: if it wasn't GNU, it wasn't GNU, which means, Richard, you
are crackin' smoke and may need a vacation. 19 years of hard effort is
a long time, have you considered retirement? You've certainly earned it.
Oh, by the way, have you updated the GNU kernel pages to reflect the new
proper name: Linux/Hurd? I'd really appreciate it if you could get to that.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Kernel hooks just to get rid of copy_[to/from]_user() and syscall overhead?
From: Gianni Tedesco @ 2003-01-10 15:31 UTC (permalink / raw)
To: Mihnea Balta; +Cc: linux-kernel
In-Reply-To: <200301101645.39535.dark_lkml@mymail.ro>
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
On Fri, 2003-01-10 at 14:45, Mihnea Balta wrote:
> Hi,
>
> I have to implement a system which grabs udp packets off a gigabit connection,
> take some basic action based on what they contain, repack their data with a
> custom protocol header and send them through a gigabit ethernet interface on
> broadcast.
>
> I know how to do this in userspace, but I need to know if doing everyting in
> the kernel would show a considerable speed improvement due to removing
> syscall and memory copy overhead. The system will be quite stressed, having
> to deal with around 15-20000 packets/second.
mmap() packet socket interface eliminates the need for system calls when
traffic is coming in at a high rate. The kernel -> user copy is also
eliminated, but its just replaced with a kernel -> kernel copy :P
You could perhaps also use linux socket filters to minimize the number
of packets you need to evaluate...
Check out this sample code: http://www.scaramanga.co.uk/code-fu/lincap.c
HTH
--
// Gianni Tedesco (gianni at scaramanga dot co dot uk)
lynx --source www.scaramanga.co.uk/gianni-at-ecsc.asc | gpg --import
8646BE7D: 6D9F 2287 870E A2C9 8F60 3A3C 91B5 7669 8646 BE7D
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2.5] speedup kallsyms_lookup
From: Hugh Dickins @ 2003-01-10 15:29 UTC (permalink / raw)
To: Daniel Ritz; +Cc: linux-kernel, Andi Kleen, daniel.ritz, Robert Love
In-Reply-To: <1042192419.1415.49.camel@cast2.alcatel.ch>
On 10 Jan 2003, Daniel Ritz wrote:
> [please cc...you know why]
>
> a patch to speed up the kallsyms_lookup() function while still doing
> compression.
> - make 4 sections: addresses, lens, stem, strings
> - only strncpy() when needed
> - no strlen() at all (only in the script)
> - save space we lose for len table by not making strings zero terminated
First impression is that it has good ideas, but seems inelegant
(always easy to make that judgment on others' code! ignore me)
and misses the main point.
In earlier mail, Andi highlighted the performance criticality of top
reading /proc/<pid>/wchan. I think we have to decide which way to
jump on that: either withdraw that functionality as too expensive,
and minimize the table size and code stupidity (all those strncpy's of
nearly 127! include/asm-i386/string.h strncpy seems in the wrong there);
or speed kallsyms_lookup as much as possible (binary chop or whatever
algorithm to locate symbol from address). The current linear search
through 6000(?) addresses is not nice, but of course the strncpy is
making it much worse.
I didn't reply to that part of Andi's mail, not because I thought it
irrelevant, quite the reverse; but because I didn't have an opinion
which way to go, and hoped someone else would chime in. I don't
see how to proceed without deciding that. CC'd rml since I believe
he fathered /proc/<pid>/wchan. Now, I'm inclined to say that anyone
worried about memory occupancy just shouldn't switch CONFIG_KALLSYMS
on, so it's speed we should aim for here.
If maximizing speed, then obviously the values should be sorted by
value (as now, unlike in my patch), and maybe we forget all about
stem compression? If minimizing memory, then a combination of your
patch and mine?
I hope I can leave this discussion to others: I just wanted to get
my symbols printing out right, and noticed the current stem compression
unnecessarily weak there; but I'm no expert on suitable algorithms.
Hugh
^ permalink raw reply
* Re: Definitions for c_cflag etc. in termbits.h???
From: Marius Groeger @ 2003-01-10 15:19 UTC (permalink / raw)
To: Steven Scholz; +Cc: LinuxPPC
In-Reply-To: <3E1EE23F.5BC310F3@imc-berlin.de>
On Fri, 10 Jan 2003, Steven Scholz wrote:
> ./include/asm-ppc/termbits.h:
>
> E.g. the DEFINEs of c_iflags appear to me as decimal values!?
>
> /* c_iflag bits */
> #define IGNBRK 0000001
It's octal (note the leading zero).
Regards,
Marius
-----------------------------------------------------------------------------
Marius Groeger SYSGO Real-Time Solutions AG mgroeger@sysgo.de
Software Engineering Embedded and Real-Time Software www.sysgo.de
Voice: +49-6136-9948-0 Am Pfaffenstein 14 www.osek.de
FAX: +49-6136-9948-10 55270 Klein-Winternheim, Germany www.elinos.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* RE: Definitions for c_cflag etc. in termbits.h???
From: Milliorn Gary-rxcr80 @ 2003-01-10 15:18 UTC (permalink / raw)
To: LinuxPPC
[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]
> -----Original Message-----
> From: Steven Scholz [mailto:steven.scholz@imc-berlin.de]
> Sent: Friday, January 10, 2003 9:10 AM
> To: LinuxPPC
> Subject: Definitions for c_cflag etc. in termbits.h???
>
>
>
> Hi there,
>
> I am playing around with UARTs and got completly confused
> when looking at
> ./include/asm-ppc/termbits.h:
>
> E.g. the DEFINEs of c_iflags appear to me as decimal values!?
>
> /* c_iflag bits */
> #define IGNBRK 0000001
> #define BRKINT 0000002
> #define IGNPAR 0000004
> #define PARMRK 0000010
It's octal, and the values are the same. Octal 10 = Hex 8.
As to why octal, I couldn't hazard a guess...
> #define INPCK 0000020
> #define ISTRIP 0000040
> #define INLCR 0000100
> #define IGNCR 0000200
> #define ICRNL 0000400
> #define IXON 0001000
> #define IXOFF 0002000
> #define IXANY 0004000
> #define IUCLC 0010000
> #define IMAXBEL 0020000
>
> So how could code like
>
> ./arch/ppc/8xx_io/uart.c: if (I_BRKINT(info->tty) ||
> I_PARMRK(info->tty))
> or
> ./arch/ppc/8xx_io/uart.c:#define RELEVANT_IFLAG(iflag) (iflag &
> (IGNBRK|BRKINT|IGNPAR|PARMRK|INPCK))
>
> possibly work?
>
> Shouldn't that be hex values as in ./include/asm-sparc64/termbits.h:
>
> /* c_iflag bits */
> #define IGNBRK 0x00000001
> #define BRKINT 0x00000002
> #define IGNPAR 0x00000004
> #define PARMRK 0x00000008
> #define INPCK 0x00000010
> #define ISTRIP 0x00000020
> #define INLCR 0x00000040
> #define IGNCR 0x00000080
> etc. ???
>
> Thanks,
>
> Steven
>
[-- Attachment #2: Gary Milliorn (E-mail).vcf --]
[-- Type: application/octet-stream, Size: 444 bytes --]
BEGIN:VCARD
VERSION:2.1
N:Milliorn;Gary
FN:Milliorn Gary-rxcr80
ORG:10060985;SD646
TEL;WORK;VOICE:5129667066
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;TX32/PL44;MOTOROLA INC.=0D=0A7700 W. PARMER LANE;AUSTIN;TEXAS;78729;UNITED =
STATES
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:TX32/PL44=0D=0AMOTOROLA INC.=0D=0A7700 W. PARMER LANE=0D=0AAUSTIN, TEXAS 787=
29=0D=0AUNITED STATES
EMAIL;PREF;INTERNET:Gary.Milliorn@motorola.com
REV:20021104T215429Z
END:VCARD
^ permalink raw reply
* Re: Severe reiserfs problems
From: Oleg Drokin @ 2003-01-10 15:27 UTC (permalink / raw)
To: Robert Szentmihalyi; +Cc: Linux Kernel Mailing List
In-Reply-To: <200301101620.42248.robert.szentmihalyi@entracom.de>
Hello!
On Fri, Jan 10, 2003 at 04:20:42PM +0100, Robert Szentmihalyi wrote:
> > > reiserfsck --fix-fixable says that I need to run
> > > reiserfsck --rebuild-tree to fix the errors, but when I do this,
> > > reiserfsck hangs after a few secounds.
> > What's the reiserfsck version you have?
> I have tried tried SuSE 8.0 and 81 rescue systems with kernels 2.4.18.and
> 2.4.19 / reiserfsck 3.x.1b and 3.6.2 with the same result.
> > What do you mean by hangs? Does it eats cpu time or something?
> It just freezes doesn't react to key presses no more.
> All you can do is swith the computer off...
Hm, sounds like you have some hardware problems then.
May be try plugging this hard drive in another system and see what will happen?
Bye,
Oleg
^ permalink raw reply
* Re: XFree86 vs. 2.5.54 - reboot
From: Bob_Tracy(0000) @ 2003-01-10 15:26 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
In-Reply-To: <3E1C9D9A.FD5CA1F6@digeo.com>
Andrew Morton wrote:
> > > "Bob_Tracy(0000)" wrote:
> > > > AMD K6-III 450 running a 2.4.19 kernel with vesafb, XFree86 4.1.0, and
> > > > a USB mouse works fine. Same setup with a 2.5.54 kernel does a cold
> > > > reboot when I type "startx".
>
> Yup. It must be something else then. Perhaps you should try disabling
> various DRM/AGP type things in config, see if that helps.
I wrote:
> 2.5.55 appears to work fine with CONFIG_AGP and CONFIG_DRM undefined.
> I'll retry with CONFIG_AGP_MODULE next...
CONFIG_AGP_MODULE enabled works fine with CONFIG_AGP_VIA_MODULE. I'll try
turning everything back on (AGP 3.0 compliance, DRM) and see what happens.
--
-----------------------------------------------------------------------
Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------
^ permalink raw reply
* Re: [parisc-linux] kernel compilation
From: Thibaut VARENE @ 2003-01-10 15:16 UTC (permalink / raw)
To: FARINATI,LEANDRO (HP-Brazil,ex1); +Cc: Parisc-Linux List (E-mail)
In-Reply-To: <9A0482A7BD2506488AD9417C93F3714F0107AE4C@xsp01.brazil.hp.com>
On vendredi, jan 10, 2003, at 14:12 Europe/Paris, FARINATI,LEANDRO
(HP-Brazil,ex1) wrote:
> Hi people,
>
> I'm trying compile the kernel linux-2.4.20-pa13 in a 64 bit machine
where did you get that kernel source from ?
Thibaut VARENE
The PA/Linux ESIEE Team
http://pateam.esiee.fr/
^ permalink raw reply
* Re: sd_read_cache_type
From: James Bottomley @ 2003-01-10 15:14 UTC (permalink / raw)
To: Andries.Brouwer; +Cc: linux-kernel, linux-scsi, linux-usb-devel
In-Reply-To: <UTC200301101308.h0AD8r021919.aeb@smtp.cwi.nl>
Andries.Brouwer@cwi.nl said:
> Will look a bit more at the details later. For now a question: this
> call does a MODE_SENSE with the DBD (disable block descriptors) bit
> set. Is there a reason for that? Wouldn't the same code work in the
> same way without that bit?
The reason was just least line of resistance. The code doesn't use the block
descriptors, so there's no need to ask for them. The code is written to skip
over the block descriptors, just in case the device returns them, so setting
DBD to zero should have no practical effect.
Andries.Brouwer@cwi.nl said:
> And the reason I ask is that we already have sd_do_mode_sense6(), so
> part of sd_read_cache_type() can be simply replaced by a call of
> sd_do_mode_sense6(), but the latter needs an extra parameter if DBD is
> really needed.
I agree with replacing the functionality with this call. On general
principle, the DBD bit (and any other missing pieces) should be added to
mode_sense6 just to make it as useful as possible (and, I suppose, the call
should be moved into scsi_lib since more than just sd could make use of it).
> And a second question: sd_read_cache_type() is called also when no
> medium is present. Objections against only calling when media are
> present?
Well, the cache is pretty often part of the permanent assembly, not part of
the removable medium, so I think it should still be called for removable
media. That begs the question, of course, what should the cache type be---it
strikes me as rather unsafe to have a removable RW medium with a write back
cache? I suppose at the very least we should to a SYNCHRONIZE on ejection if
it's write back?
James
^ permalink raw reply
* Re: RME96 driver patch
From: Anders Torger @ 2003-01-10 15:13 UTC (permalink / raw)
To: martin-langer; +Cc: alsa-devel
In-Reply-To: <20030110145314.GF20015@tuba.home>
On Friday 10 January 2003 15.53, Martin Langer wrote:
> On Sun, Jan 05, 2003 at 04:46:47PM +0100, Anders Torger wrote:
> > Here is a patch against rme96.c
>
> snd_rme96_capture_spdif_open(snd_pcm_substream_t *substream)
>
> [...]
>
> + runtime->hw = snd_rme96_capture_spdif_info;
> + if ((rate = snd_rme96_capture_getrate(rme96, &isadat)) > 0)
> { + if (isadat) {
> + return -EIO;
> + }
> + runtime->hw.rates = snd_rme96_ratecode(rate);
> + runtime->hw.rate_min = rate;
> + runtime->hw.rate_max = rate;
> + }
>
>
> You were changing sample rates in snd_rme96_capture_spdif_open. Isn't
> it too late there? Looks like capturing with wrong sample rates is
> now possible? Wouldn't this be better placed in the
> snd_rme96_capture_hw_params?
It is done both in open (show capabilities to the user) and hw params
(the user picks a setting from the available capabilities).
That is, open is performed before hw params, so theoretically it would
only be necessary to do it in open, but it is placed in hw params as
well if the input signal has changed between open and hw params (not
likely).
As mentioned before, this driver does not yet handle the cases when
sample rate and other properties is changed in runtime (I don't know if
ALSA is complete in that respect either). Nothing will break though,
but the user will not be notified of the change, and -EIO may be
delivered (changing from SPDIF to ADAT input signal in runtime for
example).
/Anders Torger
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Severe reiserfs problems
From: Robert Szentmihalyi @ 2003-01-10 15:20 UTC (permalink / raw)
To: Oleg Drokin; +Cc: Linux Kernel Mailing List
In-Reply-To: <20030110172115.A9028@namesys.com>
On Friday 10 January 2003 15:21, Oleg Drokin wrote:
> Hello!
Hi Oleg,
>
> On Fri, Jan 10, 2003 at 01:32:50PM +0100, Robert Szentmihalyi wrote:
> > I have severe file system problems on a reiserfs partition.
> > When I try copy files to another filesystem, the kernel panics at
> > certain files.
>
> Can you tell us what the panics were?
> What was the kernel version?
It said "... killing interrupt handler!"
However, the message is not exactly reproduceable.
Meanwhile, when I mount the partition in the rescue system (SuSE Linux
8.1) and access the mountpoint somehow, the machine reboots...
>
> > reiserfsck --fix-fixable says that I need to run
> > reiserfsck --rebuild-tree to fix the errors, but when I do this,
> > reiserfsck hangs after a few secounds.
>
> What's the reiserfsck version you have?
I have tried tried SuSE 8.0 and 81 rescue systems with kernels 2.4.18.and
2.4.19 / reiserfsck 3.x.1b and 3.6.2 with the same result.
> What do you mean by hangs? Does it eats cpu time or something?
It just freezes doesn't react to key presses no more.
All you can do is swith the computer off...
>
> > Is there a way to rescue at least some of the data on the partition?
>
> There is not enough info yet to know the answer.
I am happy to provide any inforamation you might need.
>
> Bye,
> Oleg
Thanks for your help so far,
Robert
--
Where do you want to be tomorrow?
Entracom. Building Linux systems.
http://www.entracom.de
^ permalink raw reply
* Definitions for c_cflag etc. in termbits.h???
From: Steven Scholz @ 2003-01-10 15:09 UTC (permalink / raw)
To: LinuxPPC
Hi there,
I am playing around with UARTs and got completly confused when looking at
./include/asm-ppc/termbits.h:
E.g. the DEFINEs of c_iflags appear to me as decimal values!?
/* c_iflag bits */
#define IGNBRK 0000001
#define BRKINT 0000002
#define IGNPAR 0000004
#define PARMRK 0000010
#define INPCK 0000020
#define ISTRIP 0000040
#define INLCR 0000100
#define IGNCR 0000200
#define ICRNL 0000400
#define IXON 0001000
#define IXOFF 0002000
#define IXANY 0004000
#define IUCLC 0010000
#define IMAXBEL 0020000
So how could code like
./arch/ppc/8xx_io/uart.c: if (I_BRKINT(info->tty) || I_PARMRK(info->tty))
or
./arch/ppc/8xx_io/uart.c:#define RELEVANT_IFLAG(iflag) (iflag &
(IGNBRK|BRKINT|IGNPAR|PARMRK|INPCK))
possibly work?
Shouldn't that be hex values as in ./include/asm-sparc64/termbits.h:
/* c_iflag bits */
#define IGNBRK 0x00000001
#define BRKINT 0x00000002
#define IGNPAR 0x00000004
#define PARMRK 0x00000008
#define INPCK 0x00000010
#define ISTRIP 0x00000020
#define INLCR 0x00000040
#define IGNCR 0x00000080
etc. ???
Thanks,
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: fs errors on thinkpad R31
From: Oleg Drokin @ 2003-01-10 15:07 UTC (permalink / raw)
To: Bernd Schubert; +Cc: ReiserFS
In-Reply-To: <200211101555.52164.bernd-schubert@web.de>
Hello!
On Sun, Nov 10, 2002 at 03:55:51PM +0100, Bernd Schubert wrote:
> > > this is the second time within 14 days after which I had to run
> > > reiserfsck on my IBM Thinkpad R31.
> > > This time I lost a directory with 49 files (it seems it were only kernel
> > > modules, so probably not so important data).
> > > I have attached the error messages from the /var/log/messages file.
> > Hm. Looks like some blocks have unexpected contents.
> > Do you often uncleanly turn-off/run out of battaries prior to
> > corruption?
> > Try to disable write caching in your harddrive then. (hdparm -W0 /dev/hda)
> thanks for your help. When I had to run reiserfsck for the very first time, I
> thought this as well, since there where some unexpected crashes in December
> and I run one day before the first fsck out of batteries. But ever since this
> fsck, nothing like this happend again (I found the reason for the crashes and
> never needed to run on accu since this time).
Still blocks are filled with some garbage it seems.
Do you suspend/resume your laptop? May be that corrupts memory or something?
> Should I enable reiserfs-debugging within the kernel configuration ? Any other
> possibilities to debug this ?
Probably first you need to find out usage pattern that leads to corruption.
Bye,
Oleg
^ permalink raw reply
* Re: SSH doesnt properly logout
From: Carl @ 2003-01-10 15:04 UTC (permalink / raw)
To: linux-admin
In-Reply-To: <20030110140855.GB2417@neon.pearbough.net>
At 15:08 10/01/2003 +0100, axel@pearbough.net wrote:
>Hi linux admins,
>
>I'm observing some strange behaviour concerning ssh and logging out from a
>ssh connection when I put a process in background on the remote side.
>For instance I do the following:
>
>* I start a gcc compilation on the remote terminal
> make bootstrap >& build.log &
> Then it goes into background.
>
>* Now I "logout" but do not return to my local terminal, now there is only a
> blank screen with the cursor in the upper left side.
>
>Can somebody help me please in understand this behaviour or rather help me
>fix it?
>
>
>Best regards,
>Axel Siebenwirth
>-
>To unsubscribe from this list: send the line "unsubscribe linux-admin" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
Try running it with a nohup
nohup make bootstrap >& build.log &
Running it in the background should still stop it when you log out.
--
Carl
^ permalink raw reply
* Re: small migration thread fix
From: William Lee Irwin III @ 2003-01-10 15:12 UTC (permalink / raw)
To: Erich Focht; +Cc: Ingo Molnar, Linus Torvalds, linux-kernel, Robert Love
In-Reply-To: <200301101529.33302.efocht@ess.nec.de>
On Friday 10 January 2003 14:11, William Lee Irwin III wrote:
>> I'm not mingo, but I can say this looks sane. My only question is
>> whether there are more codepaths that need this kind of check, for
>> instance, what happens if someone does set_cpus_allowed() to a cpumask
>> with !(task->cpumask & cpu_online_map) ?
On Fri, Jan 10, 2003 at 03:29:33PM +0100, Erich Focht wrote:
> The piece of code below was intended for that. I agree with Rusty's
> comment, BUG() is too strong for that case.
> #if 0 /* FIXME: Grab cpu_lock, return error on this case. --RR */
> new_mask &= cpu_online_map;
> if (!new_mask)
> BUG();
> #endif
> Anyhow, changing the new_mask in this way is BAD, because the masks
> are inherited. So when more CPUs come online, they remain excluded
> from the mask of the process and it's children.
> The fix suggested in the comments still has to be done...
I don't have much to add but another ack and a "hmm, maybe something
could be done". My prior comments stand. I'd be very much obliged if
you provide a fix for the set_cpus_allowed() issue. I very much rely
upon you now to provide scheduler fixes and optimizations for large
scale and/or NUMA machines these days.
Thanks,
Bill
^ permalink raw reply
* Re: Re: NFS as a Cluster File System.
From: Trond Myklebust @ 2003-01-10 15:01 UTC (permalink / raw)
To: Lorn Kay; +Cc: alanr, nfs, linux-ha
In-Reply-To: <F155FnqdR2xuRoAnbsZ00020983@hotmail.com>
>>>>> " " == Lorn Kay <lorn_kay@hotmail.com> writes:
>> NFS V3 and before have problems with "cache coherency". That
>> is, the different nodes in the cluster are not guaranteed to
>> see the same contents.
> I think this can be resolved with the "noac" mount option
> (prior to V4).
Nope. It can only be resolved using file locking.
Cheers,
Trond
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: [LARTC] HTB and ARP
From: Martin A. Brown @ 2003-01-10 14:58 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104221019215811@msgid-missing>
Eric,
We recently had a discussion here about filtering non-IP traffic. See my
attempt here:
http://mailman.ds9a.nl/pipermail/lartc/2003q1/006656.html
And Julian's follow-up post which closed the thread:
http://mailman.ds9a.nl/pipermail/lartc/2003q1/006663.html
You should be able to select with something like this:
U32="tc filter add dev $DEV parent 1:0 protocol ip u32"
$U32 match u16 0x0806 0xFFFF at -2
where 0x0806 identifies the ethernet frame as an ARP packet, per
$LINUX_SOURCE/include/linux/if_ether.h:
#define ETH_P_ARP 0x0806 /* Address Resolution packet */
Good luck,
-Martin
On Fri, 10 Jan 2003, Eric Leblond wrote:
: Hi,
:
: I discover recently that the arp traffic is managed like any other flow.
: So you get hang after a moment if you don't use a default class.
:
: Is the any means to avoid this ? Not to have a default class is a way to
: filter traffic ...
:
: One would be to managed to class ARP request with tc but I don't know if
: it is possible.
:
: Thanks in advance,
:
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [2.4.20] e1000 as module gives unresolved symbol _mmx_memcpy
From: Jurgen Kramer @ 2003-01-10 15:10 UTC (permalink / raw)
To: Linux Kernel Mailing List
In-Reply-To: <1042211643.31612.2.camel@irongate.swansea.linux.org.uk>
Thanks, I was thinking along the same lines after
discovering that a lot of other modules had the same problem...:-)
After a mrproper everything is working OK now.
But just to get a complete picture, does it mean that
a) a kernel build for a VIA C3 doesn't use MMX, userspace programs can
still use it
or
b) Both kernel and userspace can't use MMX any more
If option b) would be true a lot of people who are using the VIA Eden
platform to view Divx and other multimedia material will be probably be
hurt performance wise. If the MMX implementation on the C3 is any good.
Greetings,
Jurgen
^ permalink raw reply
* Re: [parisc-linux] ibm-disk on a hp 735/125
From: Nahkola Mikko @ 2003-01-10 14:58 UTC (permalink / raw)
To: parisc-linux
In-Reply-To: <1042203531.19627.11.camel@linux>
On Fri, Jan 10, 2003 at 01:58:51PM +0100, ext Joerg Krebs wrote:
> Am Fre, 2003-01-10 um 13.42 schrieb Nahkola Mikko:
> > > im running a hp 735/125 with a st31200wd 1GB harddisk, connected to the
> > > fast-wide scsi-connector, which run's quit nice.
> > > But now I want to replace the disk with a larger 4,3GB ibm dcas-34330
> > I'd say that probably the IBM disk isn't high-voltage. The 735's
> > fast-wide is fast-wide-highvoltage-differential, back then they thought
> Yes you are right, I found the HP 735 Hardware manual on the openpa
> Webside and there i found that the wide-scsi connector is just for HVD
> Do you know if any HVD disk is detected by the hp or are there just some
> special disks for the hp ?
Well, yes on both counts. Any HVD disks should be detected... but at the
time these boxes were made, there were supposed to be certain differences
between HP and regular disks. Or maybe that was just HP marketing.
At any rate, there _was_ (and still is, BTW) a way to recognize a HP disk
by the firmware - and there were differences between "workstation" and
"server" disks too, _and_ IIRC "workstation" disks weren't "expected to
work" in servers, the other way round it was "expected to work" but "unsupported"
or something. Don't remember.
If I only could remember what the exact identification thing was ...
maybe a letter somewhere in the firmware version string.
But since HP-UX 10.20 by the latest, probably earlier too, some people
have been using whatever disks they get as long as the SCSI interfaces
are compatible. I've never heard of problems.
Me? I recycle old HP disks in PCs...
--
Mikko Nahkola <mikko.nahkola@nokia.com>
Tre-IN sysadmin <mnahkola@trein.ntc.nokia.com>
^ permalink raw reply
* Re: Kernel hooks just to get rid of copy_[to/from]_user() and syscall overhead?
From: Richard B. Johnson @ 2003-01-10 15:04 UTC (permalink / raw)
To: Mihnea Balta; +Cc: linux-kernel
In-Reply-To: <200301101645.39535.dark_lkml@mymail.ro>
On Fri, 10 Jan 2003, Mihnea Balta wrote:
> Hi,
>
> I have to implement a system which grabs udp packets off a gigabit connection,
> take some basic action based on what they contain, repack their data with a
> custom protocol header and send them through a gigabit ethernet interface on
> broadcast.
>
> I know how to do this in userspace, but I need to know if doing everyting in
> the kernel would show a considerable speed improvement due to removing
> syscall and memory copy overhead. The system will be quite stressed, having
> to deal with around 15-20000 packets/second.
>
> I didn't want to start this e-mail with an excuse, so I delayed it until here
> :). I appologise if this isn't the right place to ask, it seemed that way to
> me. I wasn't able to find sufficient and coherent information about this
> issue on the internet or on this mailing list's archives, so I decided to ask
> you people directly.
>
> Thanks for your time,
> Mihnea Balta
>
I think you should do everything in kernel space, with a user-mode
interface for non-realtime control, i.e., what characteristics
of UDP packets are being "filtered". You just make a module that
contains what you need, with an ioctl() hook to control it.
That way, data from your gigabit interface(s) never has to get to
"user-space" at all.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* Re: [patch] R4000/R4400 64-bit errata handling
From: Maciej W. Rozycki @ 2003-01-10 14:52 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips, Karsten Merker, Thiemo Seufer
In-Reply-To: <20030110154745.D7699@linux-mips.org>
On Fri, 10 Jan 2003, Ralf Baechle wrote:
> > + __save_and_cli(flags);
>
> > + __restore_flags(flags);
>
> I suggest to replace these with local_irq_save and local_irq_restore.
> They're already deprecated for 2.4 and completly gone in 2.5.
Sure -- sorry for missing it.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: RME96 driver patch
From: Martin Langer @ 2003-01-10 14:53 UTC (permalink / raw)
To: Anders Torger; +Cc: alsa-devel
In-Reply-To: <200301051646.47991.torger@ludd.luth.se>
On Sun, Jan 05, 2003 at 04:46:47PM +0100, Anders Torger wrote:
>
> Here is a patch against rme96.c
>
snd_rme96_capture_spdif_open(snd_pcm_substream_t *substream)
[...]
+ runtime->hw = snd_rme96_capture_spdif_info;
+ if ((rate = snd_rme96_capture_getrate(rme96, &isadat)) > 0) {
+ if (isadat) {
+ return -EIO;
+ }
+ runtime->hw.rates = snd_rme96_ratecode(rate);
+ runtime->hw.rate_min = rate;
+ runtime->hw.rate_max = rate;
+ }
You were changing sample rates in snd_rme96_capture_spdif_open. Isn't it too
late there? Looks like capturing with wrong sample rates is now possible?
Wouldn't this be better placed in the snd_rme96_capture_hw_params?
martin
--
"2b|!2b"
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* RE: Re: NFS as a Cluster File System.
From: Lever, Charles @ 2003-01-10 14:51 UTC (permalink / raw)
To: 'Brian Tinsley', Lorn Kay; +Cc: nfs, linux-ha
> -----Original Message-----
> From: Brian Tinsley [mailto:btinsley@emageon.com]
> Sent: Thursday, January 09, 2003 4:11 PM
> To: Lorn Kay
> Cc: nfs@lists.sourceforge.net; linux-ha@muc.de
> Subject: [NFS] Re: NFS as a Cluster File System.
>
> > Linux clients can use TCP instead of UDP.
>
> Although I haven't had problems with this in our lab, I
> believe the NFS authors still consider this experimental.
the Linux NFS client support for TCP is not experimental.
perhaps less mature than UDP, but definitely not experimental.
the server, OTOH, sports brand new support for TCP. is that
what you were referring to?
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* [LARTC] HTB and ARP
From: Eric Leblond @ 2003-01-10 14:48 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 404 bytes --]
Hi,
I discover recently that the arp traffic is managed like any other flow.
So you get hang after a moment if you don't use a default class.
Is the any means to avoid this ? Not to have a default class is a way to
filter traffic ...
One would be to managed to class ARP request with tc but I don't know if
it is possible.
Thanks in advance,
--
Éric Leblond
courriel : eric@regit.org
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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.