* Re: 2.4.19 -- ac97_codec failure ALi 5451
From: Alan Cox @ 2003-01-10 13:36 UTC (permalink / raw)
To: Peter; +Cc: linux-kernel, Alan Cox
In-Reply-To: <1042204553.3e1ec789564b6@webmail.cogweb.net>
> I've downloaded the latest driver and am running 2.4.20 (yea!) -- the trident.c here
> is actually more recent than 2.5.55. It now loads fast and with no protest from
> ac97_codec, which has a new ID (ADS114). However, there's still not a peep (I try
> cat test.mp3 > /dev/dsp) -- and when KDE Control Center tries to restart the arts
> sound server, it alarmingly fails on "CPU overload" or just freezes the whole
> system. Is there anything I can do to get more information about what is not
> happening?
No but the info is very useful. The key change involving ac97 is that the
new code in 2.4.x waits much longer for the codec reset to finish. I'm not
sure where the audio has gone however 8(
^ permalink raw reply
* Re: [patch] R4k cache code synchronization
From: Juan Quintela @ 2003-01-10 13:36 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Maciej W. Rozycki, linux-mips
In-Reply-To: <20030110140326.B7699@linux-mips.org>
>>>>> "ralf" == Ralf Baechle <ralf@linux-mips.org> writes:
ralf> On Fri, Jan 10, 2003 at 01:37:12PM +0100, Maciej W. Rozycki wrote:
>> I can't see any need for flush_cache_l1() and flush_cache_l2(). I'd like
>> to remove them. A single flush_cache_all() seems sufficient for our
>> needs. Any objections?
ralf> The reason for the existance of flush_cache_l1 and flush_cache_l2 is the
ralf> Origin. An empty flush_cache_all() is sufficient on the Origin because
ralf> it's R10000 processor doesn't suffer from cache aliases. During bootup
ralf> we have to flush all caches or the cache coherence logic will send crazy
ralf> exceptions at us. For all other occasions just a flush of the primary
ralf> caches is sufficient which is why there is flush_cache_l1.
ralf> So I think we want to wrap things a bit nicer but basically we have to
ralf> keep those cacheops for the sake of the Origin.
Humm, I thought that there wasn't origins with R4400 processors :)
Anyways, I think that the change is the good direction, at least:
- unsigned int flags -> unsigned long flags
&& under proper #ifdefs
and the mips64 port just now should work only in R4400MC & R4400PC (to me
knowlegge the most unusual ones), and broke in the R4400SC :(
Once talking about caches, why do we _allways_ do the writeback,
indeed if they asked us to do a invalidate?
Something like that?
Later, Juan.
Index: arch/mips64/mm/c-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/mm/c-r4k.c,v
retrieving revision 1.1.2.11
diff -u -r1.1.2.11 c-r4k.c
--- arch/mips64/mm/c-r4k.c 8 Jan 2003 14:16:31 -0000 1.1.2.11
+++ arch/mips64/mm/c-r4k.c 9 Jan 2003 23:16:41 -0000
@@ -979,7 +979,7 @@
unsigned long end, a;
if (size >= scache_size) {
- flush_cache_l1();
+ flush_cache_all();
return;
}
@@ -1010,7 +1010,7 @@
a = addr & ~(dc_lsize - 1);
end = (addr + size - 1) & ~(dc_lsize - 1);
while (1) {
- flush_dcache_line(a); /* Hit_Writeback_Inv_D */
+ invalidate_dcache_line(a); /* Hit_Invalidate_D */
if (a == end) break;
a += dc_lsize;
}
@@ -1027,14 +1027,14 @@
unsigned long end, a;
if (size >= scache_size) {
- flush_cache_l1();
+ flush_cache_all();
return;
}
a = addr & ~(sc_lsize - 1);
end = (addr + size - 1) & ~(sc_lsize - 1);
while (1) {
- flush_scache_line(a); /* Hit_Writeback_Inv_SD */
+ invalidate_scache_line(a); /* Hit_Invalidate_SD */
if (a == end) break;
a += sc_lsize;
}
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: Problem of undefined reference
From: Richard B. Johnson @ 2003-01-10 13:39 UTC (permalink / raw)
To: sakib mondal; +Cc: linux-kernel
In-Reply-To: <F1550VnkB4ltFlmmlQ00000384c@hotmail.com>
On Fri, 10 Jan 2003, sakib mondal wrote:
> Hi,
>
> Wish you all a happy new year.
>
> I appologize in case you are getting multiple copies of this message.
>
> I am facing the problem of "undefined reference" for my task of using
> extended functionality of linux kernel (2.4.18) as detailed below. I shall
> appreciate any suggestion to solve the problem.
>
>
> I would like to incorporate new functions into linux kernel. Therefore I
> created a file f.c with function "void foo()". Source f.c uses header file
> f.h. The header file "f.h" has declaration "extern void foo(void);". I
> included f.o in the obj-y in the Makefile in the corresponding directory. I
> could build the new kernel without any error or warning.
>
> Now, I intended to use the extended functionality of the kernel from my
> program. I wrote g.c which calls foo(); I have included header f.h in g.c.
> However when I build g, I get the error:
>
> "g.o(.text+ox35): undefined reference to `foo`".
>
> I am unable to understand why "foo" is not resolved as the resident kernel
> ius built with object f.o. To diagonose the problem further I did the
> follwing things which could neither solve my problem.
First, you don't resolve external references by including a header file.
External references are resolved by the linker which doesn't read header
files. The prototype(s) in header files just tell the 'C' compiler what
it needs to know about the function parameters.
Second, a user program cannot call a kernel function. That's not how an
operating system works. The general-purpose method of having the kernel
execute something on behalf of the user is through the open()/close()
read()/write()/ioctl() mechanism(s). You make a module containing the
required functionality. The user-mode code opens the device, which in
your case would be a virtual device. The result is a file-descriptor that
the user-mode code uses to communicate with the device.
User-mode code normally communicates with the kernel through the
'C' runtime library. This library translates user-mode calls into
kernel function numbers. After putting the required parameters into
registers, depending upon the specific function number, the 'C' runtime
library code generates a software interrupt (on Intel machines, other
methods exist for other architectures). This signals the kernel
that the user wants it to do something for it.
In principle, you could modify the kernel to add another function number.
But, this is not the correct way to add kernel functionality. The
correct way is to use modules.
>
> i) Used "EXPORT_SYMBOL(foo);" in f.c and had f.o included in export-objs in
> the Makefile. ==> I still get the problem of undefined reference
>
See above.
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: SB 16 driver OSS emulation
From: Bernard Urban @ 2003-01-10 13:29 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Bernard Urban, alsa-devel
In-Reply-To: <87heci1i73.fsf@merceron.meteo.fr>
This gives additional details about the blocking with the sb16 driver:
Bernard Urban <Bernard.Urban@meteo.fr> writes:
[...]
> quakeforge with alsa sound output and alsa driver has the time lag
> (nearly 0.5 second).
> quakeforge with OSS sound output and OSS 'sb' driver works well.
> quakeforge with OSS sound output and alsa OSS emulation driver
> works well, using:
>
> echo "nq-glx 0 0 direct" > /proc/asound/card0/pcm0p/oss
>
> but when you quit, the program locks itself (no machine crash, only
> the program is blocked, you need to kill it).
>
> Using quake2forge (a quake2 port, without alsa support) under alsa
> OSS emulation driver with:
>
> echo "quake2 0 0 direct" > /proc/asound/card0/pcm0p/oss
>
> it works also well, but same program lock when quitting as with quakeforge.
> I will try to investigate where it blocks (last message is about DMA
> buffer release).
quake2forge obtains an 'audio_fd' file descriptor by opening
"/dev/dsp". There is a DMA buffer mmaped associated.
At shutdown of the program, the DMA buffer is un-mmaped, and
the following close(audio_fd) blocks. This seems really weird !!!
A 'close' system call cannot block ???
Actually, doing or not
echo "quake2 0 0 direct" > /proc/asound/card0/pcm0p/oss
makes no difference.
(By Monday, I hope I can send you the results of the CMI8330 patches.)
Regards.
--
Bernard Urban
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Ivan Kokshaysky @ 2003-01-10 13:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Benjamin Herrenschmidt, Alan Cox, Grant Grundler, Paul Mackerras,
Eric W. Biederman, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <Pine.LNX.4.44.0301091531260.1506-100000@penguin.transmeta.com>
On Thu, Jan 09, 2003 at 03:35:32PM -0800, Linus Torvalds wrote:
>
> On Fri, 10 Jan 2003, Ivan Kokshaysky wrote:
> >
> > PCI-PCI, PCI-ISA bridges - probably, but not host bridges. On x86 they
> > often have quite a few BARs, like AGP window, AGP MMIO, power management
> > etc., which we cannot ignore.
>
> Oh, but we _can_ ignore it.
>
> All those things are stuff that if the kernel doesn't use them, the kernel
> doesn't even need to know they are there.
It does - even if we don't use it, this stuff occupies regions in the bus
address space. If we ignore it we'll end up with incomplete resource
tree and pci_assign_resource() won't work anymore. Especially with AGP
aperture window, which tends to be large (32-128M), we'd have very good
chances to allocate a new resource (either by hotplug drivers or just
working around BIOS allocation bugs) in the middle of this window. Ouch.
> Sure, if we support AGP, we need to see the aperture size etc, but then
> we'd have the AGP driver just do the "pci_enable_dev()" thing to work it
> out.
>
> The only real reason to worry about BAR sizing is really to do resource
> discovery in order to make sure that out bridges have sufficiently big
> windows for the IO regions. Agreed?
Yes, and as Grant already pointed out, to deal with overlapping (or just
incorrectly allocated) regions.
> And that should be a non-issue especially on a host bridge, since we
> almost certainly don't want to reprogram the bridge windows there anyway.
[Hmm, on alpha we're doing that for years. :-)]
But even if we don't reprogram the bridge, we need to know about the
ranges that it decodes as we don't want to step on them accidentally.
> So I'd like to make the _default_ be to probe the minimal possible,
> _especially_ for host bridges. Then, the PCI quirks could be used to
> expand on that default.
I agree in general. Reasonable probing policy certainly is a good thing.
"Don't probe by default" would work wonderfully for PCI and ISA bridges -
I've yet to see one with normal BARs.
I'm just afraid that with the default "don't probe northbridges" we'll end
up with a lot more quirks than with "probe by default".
In either case, all of this can be trivially implemented on the top of
that patch. I'd suggest another pci_dev bit - "force_probe", to override
default policy:
static inline int default_probing_policy(struct pci_dev *dev)
{
switch (dev->class >> 8) {
case PCI_CLASS_BRIDGE_ISA:
case PCI_CLASS_BRIDGE_EISA:
case PCI_CLASS_BRIDGE_PCI:
return 0; /* Don't probe */
case PCI_CLASS_BRIDGE_HOST:
return ???
default:
return 1; /* Do probe */
}
}
static void pci_read_bases(struct pci_dev *dev, unsigned int howmany, int rom)
{
...
if (dev->skip_probe ||
(!dev->force_probe && !default_probing_policy(dev)))
return;
/* Disable I/O & memory decoding while we size the BARs. */
pci_read_config_word(dev, PCI_COMMAND, &cmd);
...
Ivan.
^ permalink raw reply
* Re: [patch] R4k cache code synchronization
From: Maciej W. Rozycki @ 2003-01-10 13:30 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20030110140326.B7699@linux-mips.org>
On Fri, 10 Jan 2003, Ralf Baechle wrote:
> The reason for the existance of flush_cache_l1 and flush_cache_l2 is the
> Origin. An empty flush_cache_all() is sufficient on the Origin because
> it's R10000 processor doesn't suffer from cache aliases. During bootup
> we have to flush all caches or the cache coherence logic will send crazy
> exceptions at us. For all other occasions just a flush of the primary
> caches is sufficient which is why there is flush_cache_l1.
So flush_cache_l1() as currently defined is sufficient for DMA coherency
on the R10000, isn't it?
> So I think we want to wrap things a bit nicer but basically we have to
> keep those cacheops for the sake of the Origin.
The naming is grossly incorrect. If the R10000 has such a cache
semantics, then it should use flush_cache_all() (targetting L1) for
coherency and __flush_cache_all() (targetting L2; I assume L2 operations
imply L1 ones, otherwise the function should explicitly operate on L1,
too) for a maintenance flush. Just like it's done for the 32-bit port.
There was a patch attached -- what about it?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* [2.4.20] e1000 as module gives unresolved symbol _mmx_memcpy
From: Jurgen Kramer @ 2003-01-10 13:45 UTC (permalink / raw)
To: linux-kernel
Hi,
While trying to use the e1000 as a module with kernel 2.4.20 it gives
me a unresolved symbol while trying to insmod the module. The offending
symbol is _mmx_memcpy. When the driver is compiled into the kernel
there's no problem.
I am running the kernel on a VIA Eden with 800MHz C3. Does this have
something to do with the fact that kernels for the VIA C3 are now
compiled with i486 optimisations (so maybe no MMX support?)?
Cheers,
Jurgen
^ permalink raw reply
* Re: [patch] R4k cache code synchronization
From: Maciej W. Rozycki @ 2003-01-10 13:33 UTC (permalink / raw)
To: Juan Quintela; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <m24r8h6se8.fsf@demo.mitica>
On 10 Jan 2003, Juan Quintela wrote:
> The only thing that could be controversial is the _l1() thing, and as
> current thing is broken, I vote for insclusion.
>
> maciej> diff -up --recursive --new-file linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c
> maciej> --- linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c 2002-12-20 03:56:52.000000000 +0000
> maciej> +++ linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c 2003-01-09 23:21:39.000000000 +0000
> @@ -979,7 +980,7 @@ static void r4k_dma_cache_wback_inv_sc(u
> unsigned long end, a;
>
> if (size >= scache_size) {
> - flush_cache_l1();
> + flush_cache_all();
> return;
> }
>
> This one is fixing a bug, we are talking about a chip with Secondary
> cache and don't touch the secondary cache at all :(
That bug is inactive -- both function pointers are defined to the same
value as surprisinly enough "l1" means "both caches" for the R4k. Anyway,
I for removing flush_cache_l1() altogether in the next step.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: aal_assert()
From: Andrew Clausen @ 2003-01-10 13:36 UTC (permalink / raw)
To: Yury Umanets; +Cc: reiserfs-list
In-Reply-To: <3E1E74C3.8050707@namesys.com>
On Fri, Jan 10, 2003 at 10:22:43AM +0300, Yura Umanets wrote:
> Actually there was the code earlier like you have proposed. And it was
> changed to the current state due to the following reasons:
>
> * there are two developers working on reiser4progs currentry (Vitaly
> Fertman and Yury Umanets). And our parts is much different. So, each of
> us should work on own code.
> * there is not neccessary an assertion is corect and only the author can
> decide is it correct.
Well, that decision is made by the developers, not the users.
Presumebly, you know who wrote what code. If an assertion is
contentious (and 99.9% of them aren't), you should document *why*,
anyway.
> * NAMESYS has some development policies. And hints is the one of them.
Why?
Cheers,
Andrew
^ permalink raw reply
* [2.5 patch] #include interrupt.h in epca.c and generic_serial.c
From: Adrian Bunk @ 2003-01-10 13:46 UTC (permalink / raw)
To: R.E.Wolff; +Cc: linux-kernel
The patch below #include's interrupt.h in epca.c and generic_serial.c to
fix the compilation for !SMP. The proper fix is to remove cli/sti/...
but until fixes are available I consider it better to have this
workaround included.
cu
Adrian
--- linux-2.5.55/drivers/char/epca.c.old 2003-01-10 14:31:20.000000000 +0100
+++ linux-2.5.55/drivers/char/epca.c 2003-01-10 14:32:05.000000000 +0100
@@ -40,6 +40,7 @@
#include <linux/tty_flip.h>
#include <linux/slab.h>
#include <linux/ioport.h>
+#include <linux/interrupt.h> /* for cli/sti/... on !SMP */
#include <asm/uaccess.h>
#include <asm/io.h>
--- linux-2.5.55/drivers/char/generic_serial.c.old 2003-01-10 14:32:13.000000000 +0100
+++ linux-2.5.55/drivers/char/generic_serial.c 2003-01-10 14:32:35.000000000 +0100
@@ -25,6 +25,7 @@
#include <linux/serial.h>
#include <linux/mm.h>
#include <linux/generic_serial.h>
+#include <linux/interrupt.h> /* for cli/sti/... on !SMP */
#include <asm/semaphore.h>
#include <asm/uaccess.h>
^ permalink raw reply
* Re: reiserfsck --rebuild-tree aborted
From: Vitaly Fertman @ 2003-01-10 13:40 UTC (permalink / raw)
To: John Fettig, reiserfs-list
In-Reply-To: <20030110005346.A24040@ux13.cso.uiuc.edu>
Hi,
> build_the_tree: Nothing but leaves are expected. Block 8532-??22683
> build_the_tree: Nothing but leaves are expected. Block 8580-??22660
> pass1.c 405 pass1_correct_leaf
> pass1_correct_leaf: block 8581, item 0, pointer 22: The wrong pointer
> (944715855) in the file [7471218 636]. Must be fixed on pass0.
> Aborted
All this looks like an fsck bug, but could be some kind of hardware
problem also. I would like to have a look at the metadata of your
partition. Could you run debugreiserfs -p /dev/xxx | bzip2 -c > xxx.bz2
and make it available for downloading.
--
Thanks,
Vitaly Fertman
^ permalink raw reply
* Re: [patch] R4k cache code synchronization
From: Juan Quintela @ 2003-01-10 13:51 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <Pine.GSO.3.96.1030110143030.23678F-100000@delta.ds2.pg.gda.pl>
>>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:
maciej> On 10 Jan 2003, Juan Quintela wrote:
>> The only thing that could be controversial is the _l1() thing, and as
>> current thing is broken, I vote for insclusion.
>>
maciej> diff -up --recursive --new-file linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c
maciej> --- linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c 2002-12-20 03:56:52.000000000 +0000
maciej> +++ linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c 2003-01-09 23:21:39.000000000 +0000
>> @@ -979,7 +980,7 @@ static void r4k_dma_cache_wback_inv_sc(u
>> unsigned long end, a;
>>
>> if (size >= scache_size) {
>> - flush_cache_l1();
>> + flush_cache_all();
>> return;
>> }
>>
>> This one is fixing a bug, we are talking about a chip with Secondary
>> cache and don't touch the secondary cache at all :(
maciej> That bug is inactive -- both function pointers are defined to the same
maciej> value as surprisinly enough "l1" means "both caches" for the R4k. Anyway,
maciej> I for removing flush_cache_l1() altogether in the next step.
Yep, you are right, only 2 weeks since I looked at that file and
already forgot it.
Ralf, current code (as Maciej tolds), just have _l1 & _l2 variants,
but at least in that file, they are defined to be the same :(
I also vote to unify the mips & mips64 versions of that file, they are
the same :(
Maciej, in the other hand, you didn't coment in the other part, that
we writeback & invalidate when we are asked only to invalidate?
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: [PATCH] RPC match and conntrack modules v2.1
From: Harald Welte @ 2003-01-10 13:45 UTC (permalink / raw)
To: Ian Latter; +Cc: netfilter-devel, marcelo.lima
In-Reply-To: <200301100926.h0A9QwA05558@singularity.tronunltd.com>
[-- Attachment #1.1: Type: text/plain, Size: 2001 bytes --]
On Fri, Jan 10, 2003 at 07:26:57PM +1100, Ian Latter wrote:
> Hello all,
> I have uploaded, to the ftp.netfilter.org site, a copy of the new patch-
> o-matic ready code. Let me know what you think of it ... I don't have a
> lot of need for RPC traffic filtering, but when I realised that the Linux
> kernel filtering for RPCs was limited to the old "record-rpc" modules, I
> had to upgrade them ... I wanted some of that CheckPoint functionality
> in my favourite filtering API :oP
This is cool stuff. Thanks a lot. The kind of contribution I really
like :)
> Also note that I've updated the module for newnat, and it compiles
> cleanly against 2.4.20. I was half tempted to author the NAT module
> to go with the conntrack and match, but this code has taken too
> much time already.
Sorry, I didn't understand the part about the NAT module. Are you
saying that NAT support is not functional right now?
> Comments welcome and appreciated.
See attached patch. Mostly CodingStyle updates (you seem to like 8 spaces
instead of tab), but also a minor fix:
- when unloading, only unregister up to ports_n_c ports
btw: I'd really love to see the large chunk of code in the switch
statement of the match() function in ipt_rpc.c be split up in seperate
functions (thus reducing indentation and improving readability).
I don't know, but I think esp. in cases where you have lots of rpc
activity (NFS?, I'm not an RPC expert) it might be wise to use a slab
cache for the 'struct request_p' list items.
Please integrate my patch [and maybe consider my suggestions, that's of
course up to you], test it and resubmit it.
Thanks!
> Regards,
> Ian Latter
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #1.2: rpc.patch.update --]
[-- Type: text/plain, Size: 23771 bytes --]
--- rpc.patch Fri Jan 10 14:24:58 2003
+++ rpc.patch.new Fri Jan 10 14:40:40 2003
@@ -1,6 +1,6 @@
--- linux/net/ipv4/netfilter/ip_conntrack_rpc_tcp.c.old Thu Jan 1 10:00:00 1970
+++ linux/net/ipv4/netfilter/ip_conntrack_rpc_tcp.c Fri Jan 10 18:53:15 2003
-@@ -0,0 +1,477 @@
+@@ -0,0 +1,482 @@
+/* RPC extension for IP (TCP) connection tracking, Version 2.1
+ * (C) 2000 by Marcelo Barbosa Lima <marcelo.lima@dcc.unicamp.br>
+ * - original rpc tracking module
@@ -28,20 +28,20 @@
+ **
+ * Note to all:
+ *
-+ * RPCs should not be exposed to the internet - ask the Pentagon;
++ * RPCs should not be exposed to the internet - ask the Pentagon;
+ *
-+ * "The unidentified crackers pleaded guilty in July to charges
-+ * of juvenile delinquency stemming from a string of Pentagon
-+ * network intrusions in February.
-+ *
-+ * The youths, going by the names TooShort and Makaveli, used
-+ * a common server security hole to break in, according to
-+ * Dane Jasper, owner of the California Internet service
-+ * provider, Sonic. They used the hole, known as the 'statd'
-+ * exploit, to attempt more than 800 break-ins, Jasper said."
++ * "The unidentified crackers pleaded guilty in July to charges
++ * of juvenile delinquency stemming from a string of Pentagon
++ * network intrusions in February.
++ *
++ * The youths, going by the names TooShort and Makaveli, used
++ * a common server security hole to break in, according to
++ * Dane Jasper, owner of the California Internet service
++ * provider, Sonic. They used the hole, known as the 'statd'
++ * exploit, to attempt more than 800 break-ins, Jasper said."
+ *
-+ * From: Wired News; "Pentagon Kids Kicked Off Grid" - Nov 6, 1998
-+ * URL: http://www.wired.com/news/politics/0,1283,16098,00.html
++ * From: Wired News; "Pentagon Kids Kicked Off Grid" - Nov 6, 1998
++ * URL: http://www.wired.com/news/politics/0,1283,16098,00.html
+ **
+ */
+
@@ -88,12 +88,13 @@
+#include <linux/netfilter_ipv4/listhelp.h>
+
+/* For future conections RPC, using client's cache bindings
-+ * I'll use ip_conntrack_lock to lock these lists */
++ * I'll use ip_conntrack_lock to lock these lists */
+
+LIST_HEAD(request_p_list_tcp);
+
+
-+static void delete_request_p(unsigned long request_p_ul) {
++static void delete_request_p(unsigned long request_p_ul)
++{
+ struct request_p *p = (void *)request_p_ul;
+
+ WRITE_LOCK(&ipct_rpc_tcp_lock);
@@ -104,7 +105,8 @@
+}
+
+
-+static void req_cl(struct request_p * r){
++static void req_cl(struct request_p * r)
++{
+ WRITE_LOCK(&ipct_rpc_tcp_lock);
+ del_timer(&r->timeout);
+ LIST_DELETE(&request_p_list_tcp, r);
@@ -114,38 +116,41 @@
+}
+
+
-+static void clean_request(struct list_head *list){
++static void clean_request(struct list_head *list)
++{
+ struct list_head *first = list->prev;
+ struct list_head *temp = list->next;
+ struct list_head *aux;
+
-+ if(list_empty(list)) return;
++ if (list_empty(list))
++ return;
+
-+ while(first != temp) {
++ while (first != temp) {
+ aux = temp->next;
+ req_cl((struct request_p *)temp);
+ temp = aux;
-+ }
++ }
+ req_cl((struct request_p *)temp);
+ return;
+}
+
+
+static void alloc_request_p(u_int32_t xid, u_int16_t proto, u_int32_t ip,
-+ u_int16_t port){
++ u_int16_t port)
++{
+ struct request_p *req_p;
-+
-+ /* Verifies if entry already exists */
-+ WRITE_LOCK(&ipct_rpc_tcp_lock);
-+ req_p = LIST_FIND(&request_p_list_tcp, request_p_cmp,
++
++ /* Verifies if entry already exists */
++ WRITE_LOCK(&ipct_rpc_tcp_lock);
++ req_p = LIST_FIND(&request_p_list_tcp, request_p_cmp,
+ struct request_p *, xid, ip, port);
+
-+ if(req_p){
++ if (req_p) {
+ /* Refresh timeout */
+ if (del_timer(&req_p->timeout)) {
-+ req_p->timeout.expires = jiffies + EXP;
-+ add_timer(&req_p->timeout);
-+ }
++ req_p->timeout.expires = jiffies + EXP;
++ add_timer(&req_p->timeout);
++ }
+ WRITE_UNLOCK(&ipct_rpc_tcp_lock);
+ return;
+
@@ -154,7 +159,7 @@
+
+ /* Allocate new request_p */
+ req_p = (struct request_p *) kmalloc(sizeof(struct request_p), GFP_ATOMIC);
-+ if(!req_p) {
++ if (!req_p) {
+ DEBUGP("can't allocate request_p\n");
+ return;
+ }
@@ -162,10 +167,10 @@
+ { { NULL, NULL }, jiffies + EXP, (unsigned long)req_p,
+ NULL }});
+
-+ /*Initialize timer */
++ /* Initialize timer */
+ init_timer(&req_p->timeout);
+ req_p->timeout.function = delete_request_p;
-+ add_timer(&req_p->timeout);
++ add_timer(&req_p->timeout);
+
+ /* Put in list */
+ WRITE_LOCK(&ipct_rpc_tcp_lock);
@@ -194,8 +199,8 @@
+
+ DEBUGP("new packet to evaluate ..\n");
+
-+ /* This works for packets like handshake packets, ignore */
-+ if (len == ((tcph->doff + iph->ihl) * 4)) {
++ /* This works for packets like handshake packets, ignore */
++ if (len == ((tcph->doff + iph->ihl) * 4)) {
+ DEBUGP("packet has no data (may still be handshaking). [skip]\n");
+ return NF_ACCEPT;
+ }
@@ -228,13 +233,13 @@
+ }
+
+
-+ /* If packet is client packet */
++ /* If packet is client packet */
+ if (dir == IP_CT_DIR_ORIGINAL) {
+
+ DEBUGP("packet is from the initiator. [cont]\n");
+
+ /* Tests if packet len is ok */
-+ if((tcplen - (tcph->doff * 4)) != 60) {
++ if ((tcplen - (tcph->doff * 4)) != 60) {
+ DEBUGP("packet length is not correct. [skip]\n");
+ return NF_ACCEPT;
+ }
@@ -249,7 +254,7 @@
+ data = data + 5;
+
+ /* Is one get port procedure? */
-+ if(IXDR_GET_INT32(data) == 3) {
++ if (IXDR_GET_INT32(data) == 3) {
+
+ data++;
+
@@ -285,7 +290,7 @@
+ DEBUGP("packet is from the receiver. [cont]\n");
+
+ /* Tests if packet len is ok */
-+ if((tcplen - (tcph->doff * 4)) != 32) {
++ if ((tcplen - (tcph->doff * 4)) != 32) {
+ DEBUGP("packet length is not correct. [skip]\n");
+ return NF_ACCEPT;
+ }
@@ -299,21 +304,21 @@
+ ct->tuplehash[!dir].tuple.src.u.all);
+
+ /* Drop unexpected packets */
-+ if(!req_p) {
++ if (!req_p) {
+ DEBUGP("packet is not expected. [skip]\n");
+ return NF_ACCEPT;
+ }
+ data = data++;
+
+ /* Verifies if packet is really a reply packet */
-+ if(IXDR_GET_INT32(data) != 1) {
++ if (IXDR_GET_INT32(data) != 1) {
+ DEBUGP("packet is not a valid RPC reply. [skip]\n");
+ return NF_ACCEPT;
+ }
+ data++;
+
+ /* Is status accept? */
-+ if(IXDR_GET_INT32(data)) {
++ if (IXDR_GET_INT32(data)) {
+ DEBUGP("packet is not an RPC accept. [skip]\n");
+ return NF_ACCEPT;
+ }
@@ -323,18 +328,18 @@
+ data = data + IXDR_GET_INT32(data) + 2;
+
+ /* Is accpet status "success"? */
-+ if(IXDR_GET_INT32(data)) {
++ if (IXDR_GET_INT32(data)) {
+ DEBUGP("packet is not an RPC accept status of success. [skip]\n");
+ return NF_ACCEPT;
+ }
+ data++;
+
-+ /* Get server port number */
++ /* Get server port number */
+ port_buf = (u_int16_t) IXDR_GET_INT32(data);
+
+ /* Alright. This binding must be in internal expect list;
+ * If port == 0, then this service is not registred. */
-+ if(port_buf) {
++ if (port_buf) {
+ DEBUGP("port found: %u\n", port_buf);
+
+ memset(&expect, 0, sizeof(expect));
@@ -345,7 +350,7 @@
+ exp->mask.src.ip = 0xffffffff;
+ exp->mask.dst.ip = 0xffffffff;
+
-+ switch(req_p->proto) {
++ switch (req_p->proto) {
+ case IPPROTO_UDP:
+ exp->tuple.src.u.udp.port = 0;
+ exp->tuple.dst.u.udp.port = htons(port_buf);
@@ -463,7 +468,7 @@
+ DEBUGP("cleaning request list\n");
+ clean_request(&request_p_list_tcp);
+
-+ for (port = 0; (port < MAX_PORTS) && ports[port]; port++) {
++ for (port = 0; (port < ports_n_c) && ports[port]; port++) {
+ DEBUGP("unregistering port %d\n", ports[port]);
+ ip_conntrack_helper_unregister(&rpc_helpers[port]);
+ }
@@ -480,7 +485,7 @@
+
--- linux/net/ipv4/netfilter/ip_conntrack_rpc_udp.c.old Thu Jan 1 10:00:00 1970
+++ linux/net/ipv4/netfilter/ip_conntrack_rpc_udp.c Fri Jan 10 18:53:09 2003
-@@ -0,0 +1,466 @@
+@@ -0,0 +1,471 @@
+/* RPC extension for IP (UDP) connection tracking, Version 2.1
+ * (C) 2000 by Marcelo Barbosa Lima <marcelo.lima@dcc.unicamp.br>
+ * - original rpc tracking module
@@ -508,20 +513,20 @@
+ **
+ * Note to all:
+ *
-+ * RPCs should not be exposed to the internet - ask the Pentagon;
++ * RPCs should not be exposed to the internet - ask the Pentagon;
+ *
-+ * "The unidentified crackers pleaded guilty in July to charges
-+ * of juvenile delinquency stemming from a string of Pentagon
-+ * network intrusions in February.
-+ *
-+ * The youths, going by the names TooShort and Makaveli, used
-+ * a common server security hole to break in, according to
-+ * Dane Jasper, owner of the California Internet service
-+ * provider, Sonic. They used the hole, known as the 'statd'
-+ * exploit, to attempt more than 800 break-ins, Jasper said."
++ * "The unidentified crackers pleaded guilty in July to charges
++ * of juvenile delinquency stemming from a string of Pentagon
++ * network intrusions in February.
++ *
++ * The youths, going by the names TooShort and Makaveli, used
++ * a common server security hole to break in, according to
++ * Dane Jasper, owner of the California Internet service
++ * provider, Sonic. They used the hole, known as the 'statd'
++ * exploit, to attempt more than 800 break-ins, Jasper said."
+ *
-+ * From: Wired News; "Pentagon Kids Kicked Off Grid" - Nov 6, 1998
-+ * URL: http://www.wired.com/news/politics/0,1283,16098,00.html
++ * From: Wired News; "Pentagon Kids Kicked Off Grid" - Nov 6, 1998
++ * URL: http://www.wired.com/news/politics/0,1283,16098,00.html
+ **
+ */
+
@@ -573,7 +578,8 @@
+LIST_HEAD(request_p_list_udp);
+
+
-+static void delete_request_p(unsigned long request_p_ul) {
++static void delete_request_p(unsigned long request_p_ul)
++{
+ struct request_p *p = (void *)request_p_ul;
+
+ WRITE_LOCK(&ipct_rpc_udp_lock);
@@ -584,7 +590,8 @@
+}
+
+
-+static void req_cl(struct request_p * r){
++static void req_cl(struct request_p * r)
++{
+ WRITE_LOCK(&ipct_rpc_udp_lock);
+ del_timer(&r->timeout);
+ LIST_DELETE(&request_p_list_udp, r);
@@ -594,25 +601,28 @@
+}
+
+
-+static void clean_request(struct list_head *list){
++static void clean_request(struct list_head *list)
++{
+ struct list_head *first = list->prev;
+ struct list_head *temp = list->next;
+ struct list_head *aux;
+
-+ if(list_empty(list)) return;
++ if (list_empty(list))
++ return;
+
-+ while(first != temp) {
++ while (first != temp) {
+ aux = temp->next;
+ req_cl((struct request_p *)temp);
+ temp = aux;
-+ }
++ }
+ req_cl((struct request_p *)temp);
+ return;
+}
+
+
+static void alloc_request_p(u_int32_t xid, u_int16_t proto, u_int32_t ip,
-+ u_int16_t port){
++ u_int16_t port)
++{
+ struct request_p *req_p;
+
+ /* Verifies if entry already exists */
@@ -620,7 +630,7 @@
+ req_p = LIST_FIND(&request_p_list_udp, request_p_cmp,
+ struct request_p *, xid, ip, port);
+
-+ if(req_p) {
++ if (req_p) {
+ /* Refresh timeout */
+ if (del_timer(&req_p->timeout)) {
+ req_p->timeout.expires = jiffies + EXP;
@@ -634,7 +644,7 @@
+
+ /* Allocate new request_p */
+ req_p = (struct request_p *) kmalloc(sizeof(struct request_p), GFP_ATOMIC);
-+ if(!req_p) {
++ if (!req_p) {
+ DEBUGP("can't allocate request_p\n");
+ return;
+ }
@@ -686,7 +696,7 @@
+
+
+ /* FIXME: Source route IP option packets --RR */
-+ if(*chsm){
++ if (*chsm) {
+ if (csum_tcpudp_magic(iph->saddr, iph->daddr, udplen, IPPROTO_UDP,
+ csum_partial((char *)udph, udplen, 0))) {
+ DEBUGP("[note: failure to get past this error may indicate source routing]\n");
@@ -757,7 +767,7 @@
+ }
+
+ /* Tests if packet len is ok */
-+ if((udplen - sizeof(struct udphdr)) != 28) {
++ if ((udplen - sizeof(struct udphdr)) != 28) {
+ DEBUGP("packet length is not correct. [skip]\n");
+ return NF_ACCEPT;
+ }
@@ -768,21 +778,21 @@
+ ct->tuplehash[!dir].tuple.src.u.all);
+
+ /* Drop unexpected packets */
-+ if(!req_p) {
++ if (!req_p) {
+ DEBUGP("packet is not expected. [skip]\n");
+ return NF_ACCEPT;
+ }
+ data = data++;
+
+ /* Verifies if packet is really a reply packet */
-+ if(IXDR_GET_INT32(data) != 1) {
++ if (IXDR_GET_INT32(data) != 1) {
+ DEBUGP("packet is not a valid RPC reply. [skip]\n");
+ return NF_ACCEPT;
+ }
+ data++;
+
+ /* Is status accept? */
-+ if(IXDR_GET_INT32(data)) {
++ if (IXDR_GET_INT32(data)) {
+ DEBUGP("packet is not an RPC accept. [skip]\n");
+ return NF_ACCEPT;
+ }
@@ -792,7 +802,7 @@
+ data = data + IXDR_GET_INT32(data) + 2;
+
+ /* Is accpet status "success"? */
-+ if(IXDR_GET_INT32(data)) {
++ if (IXDR_GET_INT32(data)) {
+ DEBUGP("packet is not an RPC accept status of success. [skip]\n");
+ return NF_ACCEPT;
+ }
@@ -803,7 +813,7 @@
+
+ /* Alright. This binding must be in internal expect list;
+ * If port == 0, then this service is not registred. */
-+ if(port_buf) {
++ if (port_buf) {
+ DEBUGP("port found: %u\n", port_buf);
+
+ memset(&expect, 0, sizeof(expect));
@@ -932,7 +942,7 @@
+ DEBUGP("cleaning request list\n");
+ clean_request(&request_p_list_udp);
+
-+ for (port = 0; (port < MAX_PORTS) && ports[port]; port++) {
++ for (port = 0; (port < ports_n_c) && ports[port]; port++) {
+ DEBUGP("unregistering port %d\n", ports[port]);
+ ip_conntrack_helper_unregister(&rpc_helpers[port]);
+ }
@@ -977,20 +987,20 @@
+ **
+ * Note to all:
+ *
-+ * RPCs should not be exposed to the internet - ask the Pentagon;
++ * RPCs should not be exposed to the internet - ask the Pentagon;
+ *
-+ * "The unidentified crackers pleaded guilty in July to charges
-+ * of juvenile delinquency stemming from a string of Pentagon
-+ * network intrusions in February.
-+ *
-+ * The youths, going by the names TooShort and Makaveli, used
-+ * a common server security hole to break in, according to
-+ * Dane Jasper, owner of the California Internet service
-+ * provider, Sonic. They used the hole, known as the 'statd'
-+ * exploit, to attempt more than 800 break-ins, Jasper said."
++ * "The unidentified crackers pleaded guilty in July to charges
++ * of juvenile delinquency stemming from a string of Pentagon
++ * network intrusions in February.
++ *
++ * The youths, going by the names TooShort and Makaveli, used
++ * a common server security hole to break in, according to
++ * Dane Jasper, owner of the California Internet service
++ * provider, Sonic. They used the hole, known as the 'statd'
++ * exploit, to attempt more than 800 break-ins, Jasper said."
+ *
-+ * From: Wired News; "Pentagon Kids Kicked Off Grid" - Nov 6, 1998
-+ * URL: http://www.wired.com/news/politics/0,1283,16098,00.html
++ * From: Wired News; "Pentagon Kids Kicked Off Grid" - Nov 6, 1998
++ * URL: http://www.wired.com/news/politics/0,1283,16098,00.html
+ **
+ */
+
@@ -1082,22 +1092,22 @@
+{
+ int proc_ctr;
+ char *proc_ptr;
-+ unsigned int proc_num;
++ unsigned int proc_num;
+
+ DEBUGP("entered match_rpcs [%i] [%i] ..\n", i_procs, proc);
+
-+ if(i_procs == -1)
++ if (i_procs == -1)
+ return 1;
+
-+ for (proc_ctr=0; proc_ctr <= i_procs; proc_ctr++) {
++ for (proc_ctr=0; proc_ctr <= i_procs; proc_ctr++) {
+
-+ proc_ptr = c_procs;
-+ proc_ptr += proc_ctr * IPT_RPC_CHAR_LEN;
-+ proc_num = k_atoi(proc_ptr);
++ proc_ptr = c_procs;
++ proc_ptr += proc_ctr * IPT_RPC_CHAR_LEN;
++ proc_num = k_atoi(proc_ptr);
+
-+ if(proc_num == proc)
++ if (proc_num == proc)
+ return 1;
-+ }
++ }
+ return 0;
+}
+
@@ -1111,7 +1121,7 @@
+ const u_int32_t *data;
+ enum ip_conntrack_dir dir;
+ const struct tcphdr *tcp;
-+ const struct ipt_rpc_info *rpcinfo = matchinfo;
++ const struct ipt_rpc_info *rpcinfo = matchinfo;
+ struct request_p *req_p;
+ u_int32_t xid;
+ int port, portsok;
@@ -1125,7 +1135,7 @@
+ dir = CTINFO2DIR(ctinfo);
+
+ /* we only want the client to server packets for matching */
-+ if(dir != IP_CT_DIR_ORIGINAL)
++ if (dir != IP_CT_DIR_ORIGINAL)
+ return 0;
+
+ /* This does sanity checking on UDP or TCP packets,
@@ -1134,24 +1144,24 @@
+ * communications with the portmapper.
+ */
+
-+ switch(ct->tuplehash[0].tuple.dst.protonum) {
++ switch (ct->tuplehash[0].tuple.dst.protonum) {
+
+ case IPPROTO_UDP:
+ DEBUGP("PROTO_UDP [cont]\n");
-+ if(offset == 0 && datalen < sizeof(struct udphdr)) {
++ if (offset == 0 && datalen < sizeof(struct udphdr)) {
+ DEBUGP("UDP packet does not contain a complete UDP header. [drop]\n");
+ return 0;
+ }
-+ for(port=0,portsok=0; port <= ports_n_c; port++) {
-+ if(ntohs(ct->tuplehash[dir].tuple.dst.u.all) == ports[port]) {
++ for (port=0,portsok=0; port <= ports_n_c; port++) {
++ if (ntohs(ct->tuplehash[dir].tuple.dst.u.all) == ports[port]) {
+ portsok++;
+ break;
+ }
+ }
-+ if(portsok == 1) {
-+ if((datalen - sizeof(struct udphdr)) != 56) {
++ if (portsok == 1) {
++ if ((datalen - sizeof(struct udphdr)) != 56) {
+ DEBUGP("UDP packet length is not correct for RPC content. [skip]\n");
-+ if(rpcinfo->strict == 1)
++ if (rpcinfo->strict == 1)
+ *hotdrop = 1;
+ return 0;
+ }
@@ -1165,7 +1175,7 @@
+
+ /* Get RPC requestor */
+ data = (const u_int32_t *)hdr + 7;
-+ if(IXDR_GET_INT32(data) != 3) {
++ if (IXDR_GET_INT32(data) != 3) {
+ DEBUGP("UDP packet contains an invalid (non \"get\") requestor. [skip]\n");
+ if(rpcinfo->strict == 1)
+ *hotdrop = 1;
@@ -1175,8 +1185,8 @@
+
+ /* Get RPC procedure */
+ data = (const u_int32_t *)hdr + 12;
-+ if(match_rpcs((char *)&rpcinfo->c_procs,
-+ rpcinfo->i_procs, IXDR_GET_INT32(data)) == 0) {
++ if (match_rpcs((char *)&rpcinfo->c_procs,
++ rpcinfo->i_procs, IXDR_GET_INT32(data)) == 0) {
+ DEBUGP("UDP packet contains illegal procedure request [%u]. [drop]\n",
+ (unsigned int)IXDR_GET_INT32(data));
+
@@ -1187,7 +1197,7 @@
+ ct->tuplehash[dir].tuple.src.ip,
+ ct->tuplehash[dir].tuple.src.u.all);
+
-+ if(req_p){
++ if (req_p) {
+ DEBUGP("found req_p for xid=%u proto=17 %u.%u.%u.%u:%u\n", xid,
+ NIPQUAD(ct->tuplehash[dir].tuple.src.ip),
+ ntohs(ct->tuplehash[dir].tuple.src.u.all));
@@ -1217,20 +1227,20 @@
+
+ case IPPROTO_TCP:
+ DEBUGP("PROTO_TCP [cont]\n");
-+ if(offset == 0 && datalen < sizeof(struct tcphdr)) {
++ if (offset == 0 && datalen < sizeof(struct tcphdr)) {
+ DEBUGP("TCP packet does not contain a complete TCP header. [drop]\n");
+ return 0;
+ }
-+ if(ntohs(ct->tuplehash[dir].tuple.dst.u.all) == 111) {
++ if (ntohs(ct->tuplehash[dir].tuple.dst.u.all) == 111) {
+
+ tcp = hdr;
-+ if(datalen == (tcp->doff * 4)) {
++ if (datalen == (tcp->doff * 4)) {
+ DEBUGP("TCP packet does not contain any data. [match]\n");
+ return (1 && (!offset));
+ }
+
+ /* Tests if packet len is ok */
-+ if((datalen - (tcp->doff * 4)) != 60) {
++ if ((datalen - (tcp->doff * 4)) != 60) {
+ DEBUGP("TCP packet length is not correct for RPC content. [skip]\n");
+ if(rpcinfo->strict == 1)
+ *hotdrop = 1;
@@ -1246,9 +1256,9 @@
+
+ /* Get RPC requestor */
+ data = (const u_int32_t *)tcp + tcp->doff + 6;
-+ if(IXDR_GET_INT32(data) != 3) {
++ if (IXDR_GET_INT32(data) != 3) {
+ DEBUGP("TCP packet contains an invalid (non \"get\") requestor. [skip]\n");
-+ if(rpcinfo->strict == 1)
++ if (rpcinfo->strict == 1)
+ *hotdrop = 1;
+ return 0;
+ }
@@ -1256,8 +1266,8 @@
+
+ /* Get RPC procedure */
+ data = (const u_int32_t *)tcp + tcp->doff + 11;
-+ if(match_rpcs((char *)&rpcinfo->c_procs,
-+ rpcinfo->i_procs, IXDR_GET_INT32(data)) == 0) {
++ if (match_rpcs((char *)&rpcinfo->c_procs,
++ rpcinfo->i_procs, IXDR_GET_INT32(data)) == 0) {
+ DEBUGP("TCP packet contains illegal procedure request [%u]. [drop]\n",
+ (unsigned int)IXDR_GET_INT32(data));
+
@@ -1267,7 +1277,7 @@
+ ct->tuplehash[dir].tuple.src.ip,
+ ct->tuplehash[dir].tuple.src.u.all);
+
-+ if(req_p){
++ if (req_p) {
+ DEBUGP("found req_p for xid=%u proto=6 %u.%u.%u.%u:%u\n", xid,
+ NIPQUAD(ct->tuplehash[dir].tuple.src.ip),
+ ntohs(ct->tuplehash[dir].tuple.src.u.all));
@@ -1306,19 +1316,19 @@
+
+
+static int checkentry(const char *tablename, const struct ipt_ip *ip, void *matchinfo,
-+ unsigned int matchsize, unsigned int hook_mask)
++ unsigned int matchsize, unsigned int hook_mask)
+{
-+ if (hook_mask
-+ & ~((1 << NF_IP_PRE_ROUTING) | (1 << NF_IP_FORWARD) | (1 << NF_IP_POST_ROUTING)
++ if (hook_mask
++ & ~((1 << NF_IP_PRE_ROUTING) | (1 << NF_IP_FORWARD) | (1 << NF_IP_POST_ROUTING)
+ | (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_LOCAL_OUT))) {
+ printk("ipt_rpc: only valid for PRE_ROUTING, FORWARD, POST_ROUTING, LOCAL_IN and/or LOCAL_OUT targets.\n");
-+ return 0;
-+ }
++ return 0;
++ }
+
-+ if (matchsize != IPT_ALIGN(sizeof(struct ipt_rpc_info)))
-+ return 0;
++ if (matchsize != IPT_ALIGN(sizeof(struct ipt_rpc_info)))
++ return 0;
+
-+ return 1;
++ return 1;
+}
+
+
@@ -1331,7 +1341,7 @@
+{
+ int port;
+
-+ DEBUGP("incrementing usage counts\n");
++ DEBUGP("incrementing usage counts\n");
+ __MOD_INC_USE_COUNT(ip_conntrack_rpc_udp);
+ __MOD_INC_USE_COUNT(ip_conntrack_rpc_tcp);
+
@@ -1354,7 +1364,7 @@
+ DEBUGP("unregistering match\n");
+ ipt_unregister_match(&rpc_match);
+
-+ DEBUGP("decrementing usage counts\n");
++ DEBUGP("decrementing usage counts\n");
+ __MOD_DEC_USE_COUNT(ip_conntrack_rpc_tcp);
+ __MOD_DEC_USE_COUNT(ip_conntrack_rpc_udp);
+}
@@ -1411,25 +1421,25 @@
+#define EXPIRES (180 * HZ)
+
+/* For future conections RPC, using client's cache bindings
-+ * I'll use ip_conntrack_lock to lock these lists */
++ * I'll use ip_conntrack_lock to lock these lists */
+
+/* This identifies each request and stores protocol */
+struct request_p {
-+ struct list_head list;
++ struct list_head list;
+
-+ u_int32_t xid;
-+ u_int32_t ip;
-+ u_int16_t port;
++ u_int32_t xid;
++ u_int32_t ip;
++ u_int16_t port;
+
-+ /* Protocol */
-+ u_int16_t proto;
++ /* Protocol */
++ u_int16_t proto;
+
-+ struct timer_list timeout;
++ struct timer_list timeout;
+};
+
+static inline int request_p_cmp(const struct request_p *p, u_int32_t xid,
+ u_int32_t ip, u_int32_t port) {
-+ return(p->xid == xid && p->ip == ip && p->port);
++ return (p->xid == xid && p->ip == ip && p->port);
+
+}
+
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: [parisc-linux] unaligned accesses
From: jsoe0708 @ 2003-01-10 13:45 UTC (permalink / raw)
To: Randolph Chung; +Cc: parisc-linux
In-Reply-To: <3E1AA8D500000877@ocpmta8.freegates.net>
>-- Original Message --
>From: jsoe0708@tiscali.be
>Subject: Re: [parisc-linux] unaligned accesses
>To: "Randolph Chung" <randolph@tausq.org>
>Cc: parisc-linux@lists.parisc-linux.org
>Date: Fri, 10 Jan 2003 09:24:40 +0100
>
>
>
>>-- Original Message --
>>Date: Thu, 9 Jan 2003 23:36:59 -0800
>>From: Randolph Chung <randolph@tausq.org>
>>To: jsoe0708@tiscali.be
>>Cc: parisc-linux@lists.parisc-linux.org
>>Subject: Re: [parisc-linux] unaligned accesses
>>Reply-To: Randolph Chung <randolph@tausq.org>
>>
>>
>...
>>> hmmm buggy: not always, the triky case is when you have to access to
>those
>>> kind of data encapsulated into a structure. I do not yet find any wor=
karound
>>> or how to fix this kind of pb. Any idea (gcc-3.3?)?
>>
>>eh? what do you mean?
>>
>well I will try to find back the example I encounter (somewhere in jfs-1=
.0.23
>IIRC)
>
Yes here it was in evms(1.1.0 since the bug was fix but it is still a sam=
ple
:-)
[this small example was composed of code coming from evms-1.1.0]
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
typedef u_int8_t BOOLEAN;
#ifndef TRUE
#define TRUE 1
#endif
#ifndef FALSE
#define FALSE 0
#endif
struct partition {
unsigned char boot_ind; /* 0x80 - active */
unsigned char head; /* starting head */
unsigned char sector; /* starting sector */
unsigned char cyl; /* starting cylinder */
unsigned char sys_ind; /* What partition type */
unsigned char end_head; /* end head */
unsigned char end_sector; /* end sector */
unsigned char end_cyl; /* end cylinder */
unsigned int start_sect; /* starting sector counting from 0 */
unsigned int nr_sects; /* nr of sectors in partition */
};
BOOLEAN isa_null_partition_record(struct partition *p)
{
int i;
u_int32_t *uip =3D (u_int32_t *) p;
for (i=3D0; i<4; i++) {
if (*uip!=3D0x00) return FALSE;
}
return TRUE;
}
int main(int argc, char * * argv, char * * env) {
struct partition p1, p2;
p1.boot_ind=3D0;
p1.head=3D0;
p1.sector=3D0;
p1.cyl=3D0;
p1.sys_ind=3D0;
p1.end_head=3D0;
p1.end_sector=3D0;
p1.end_cyl=3D0;
p1.start_sect=3D0;
p1.nr_sects=3D0;
printf("Is that p1 is a null partition: %u\n", isa_null_partition_rec=
ord(&p1));
p2.boot_ind=3D1;
p2.head=3D2;
p2.sector=3D3;
p2.cyl=3D4;
p2.sys_ind=3D5;
p2.end_head=3D6;
p2.end_sector=3D7;
p2.end_cyl=3D8;
p2.start_sect=3D9;
p2.nr_sects=3D10;
printf("Is that p2 is a null partition: %u\n", isa_null_partition_rec=
ord(&p2));
return 0;
}
Unfortunately this doesn't reproduce the actual problem of which I save
the following traces (from the evms_vgscan 1.1.0: once again this was fix=
since next release):
...
(isa_valid_partition_record) file checks.c
part.start_sect add: 0x27116
part.start_sect : 0
part.nr_sects add: 0x2711a
part.nr_sects : 0
p add: 0x2710e
p.boot_ind add: 0x2710e
p.head add: 0x2710f
p.sector add: 0x27110
p.cyl add: 0x27111
p.sys_ind add: 0x27112
p.end_head add: 0x27113
p.end_sector add: 0x27114
p.end_cyl add: 0x27115
p.start_sect add: 0x27116
p.start_sect : 0
p.nr_sects add: 0x2711a
p.nr_sects : 0
p add: 0x2710e
p.boot_ind add: 0x2710e
p.head add: 0x2710f
p.sector add: 0x27110
p.cyl add: 0x27111
p.sys_ind add: 0x27112
p.end_head add: 0x27113
p.end_sector add: 0x27114
p.end_cyl add: 0x27115
p.start_sect add: 0x27116
p.start_sect : 0
p.nr_sects add: 0x2711a
p.nr_sects : 0
...
in which we can see that p.start_sect (an int) address (0x27166 =3D=3D 16=
0102)
is not well align (160102/4=3D40025.5).
HTH,
Joel
********************************************
Promo Tiscali ADSL: 35 Euros/mois, 1er mois et activation =3D 0 Euro http=
://adsl.tiscali.be
^ permalink raw reply
* Re: remove usage of __MOD_XXX_USAGE_COUNT and derivatives
From: Anders Fugmann @ 2003-01-10 13:49 UTC (permalink / raw)
To: Harald Welte; +Cc: netfilter-devel
In-Reply-To: <20030110131315.GS1353@sunbeam.de.gnumonks.org>
Harald Welte wrote:
> On Thu, Jan 09, 2003 at 10:52:45PM +0100, Anders Fugmann wrote:
>
> Ok, this seems to be some new 2.5.x api changes - I first need to get
> familiar with this.
Most of the documentation I found in include/linux/module.h.
>
>
>>Conversion enables module unloading on 2.5 kernels.
>>The patch is against 2.5.55. I have only tested ipv4 functionality, and
>>I see no reason that ipv6 shound not work also.
One thing I have noticed is that the module usage count for 'ip_tables'
gets incremented twice when loading a module that depends on the
ip_tables module. Unloading the module again also decrements usage count
on ip_tables with 2. This happens both on vanilla 2.5.55 and 2.5.55 with
the patch applied. It does not happen on 2.4.20 though.
One question. Why is the module count increased (code wise) whenever a
new module is loaded, that depends on the current module? Eg. When
loading ipt_MARK, the module count for ip_tables is increased. The
dependancies are still kept by the kernel so ip_tables cannot be
unloaded anyhow.
> So if the patch is accepted (still need to look at it), I will submit it
> for kernel inclusion.
Then I send it to the right place it seems.
Regards
Anders Fugmann.
^ permalink raw reply
* Re: remove usage of __MOD_XXX_USAGE_COUNT and derivatives
From: Harald Welte @ 2003-01-10 13:49 UTC (permalink / raw)
To: Anders Fugmann; +Cc: netfilter-devel
In-Reply-To: <3E1ECF6B.5080109@fugmann.dhs.org>
[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]
On Fri, Jan 10, 2003 at 02:49:31PM +0100, Anders Fugmann wrote:
> Harald Welte wrote:
> >On Thu, Jan 09, 2003 at 10:52:45PM +0100, Anders Fugmann wrote:
> >
> >Ok, this seems to be some new 2.5.x api changes - I first need to get
> >familiar with this.
> Most of the documentation I found in include/linux/module.h.
Ok, will read it when I have some time...
> One thing I have noticed is that the module usage count for 'ip_tables'
> gets incremented twice when loading a module that depends on the
> ip_tables module. Unloading the module again also decrements usage count
> on ip_tables with 2. This happens both on vanilla 2.5.55 and 2.5.55 with
> the patch applied. It does not happen on 2.4.20 though.
Mh, strange. Maybe also related to the new module code. Seems like I
should follow 2.5.x development a bit more closely.
> One question. Why is the module count increased (code wise) whenever a
> new module is loaded, that depends on the current module? Eg. When
> loading ipt_MARK, the module count for ip_tables is increased. The
> dependancies are still kept by the kernel so ip_tables cannot be
> unloaded anyhow.
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.
> >So if the patch is accepted (still need to look at it), I will submit it
> >for kernel inclusion.
> Then I send it to the right place it seems.
yup :)
> Regards
> Anders Fugmann.
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* 2.5.55: static compilation of mxser.c doesn't work
From: Adrian Bunk @ 2003-01-10 14:03 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: linux-kernel, support
Hi Arnaldo,
the 2.5 Linux kernel contains your patch
o mxser: add module_exit/module_init
This fixes the compilation problem in 2.5
This patch renames mxser_init to mxser_module_init causing a compile
error when trying to compile this driver statically into the kernel
since mxser_init is still called from drivers/char/tty_io.c.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: XFree86 vs. 2.5.54 - reboot
From: Bob_Tracy(0000) @ 2003-01-10 14:06 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.
2.5.55 appears to work fine with CONFIG_AGP and CONFIG_DRM undefined.
I'll retry with CONFIG_AGP_MODULE next...
--
-----------------------------------------------------------------------
Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------
^ permalink raw reply
* Re: Fixed proken MARK target in POM.
From: Harald Welte @ 2003-01-10 14:00 UTC (permalink / raw)
To: Anders Fugmann; +Cc: netfilter-devel
In-Reply-To: <3E1D7419.1060502@fugmann.dhs.org>
[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]
On Thu, Jan 09, 2003 at 02:07:37PM +0100, Anders Fugmann wrote:
> The patch maintains backward compability, and I request that this patch
> is applied to mainstream (and pushed to the Andrea for kernel
> inclusion),
1) Where is the compatibility? I cannot see how this code change would
ensure that
a) old, unpatched kernel works with new, patched userspace
b) new, patched kernel works with old, unpatched userspace
Those two conditions need to be fulfilled, otherwise we cannot make a
change during the stable kernel series.
2) Which Andrea are you talking about? Therer is no Andrea involved in
netfilter/iptabls updates.
> as I as a software developer of a firewall cannot ask users
> of the software to appliy patches to POM.
I regard this as critic to my recent patch-o-matic announcement, where I
was asking people to use patch-o-matic. I was talking about
bugfixes/updates which are in 2.4.20 (or 2.4.21-preX)... but people are
still running older kernels than that... and they should indeed use
patch-o-matic for the netfilter fixes.
Apart from that, everything in patch-o-matic are new features or
extensions, which are either not fully stable or we strongly doubt that
they are useful for the big public. And if somebody wants to test one
of those non-standard extensions, we can ask people to use patch-o-matic.
> Regards
> Anders Fugmann
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: [patch] R4k cache code synchronization
From: Maciej W. Rozycki @ 2003-01-10 14:02 UTC (permalink / raw)
To: Juan Quintela; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <m2smw15d0n.fsf@demo.mitica>
On 10 Jan 2003, Juan Quintela wrote:
> Maciej, in the other hand, you didn't coment in the other part, that
> we writeback & invalidate when we are asked only to invalidate?
I did some investigation now and I think dma_cache_wback_inv(),
dma_cache_wback() and dma_cache_inv() all should do what the name implies.
I'll make a fix.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: Reg iptables Connection tracking
From: Athan @ 2003-01-10 14:02 UTC (permalink / raw)
To: Amit Kumar Gupta; +Cc: netfilter
In-Reply-To: <4223A04BF7D1B941A25246ADD0462FF5647695@blr-m3-msg.wipro.com>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
On Fri, Jan 10, 2003 at 10:33:48AM +0530, Amit Kumar Gupta wrote:
> As soon as somebody pings to my m/c , that fellow doesn't get the reply
> and on my m/c , kernel keeps dumping certain messages which are like
> this :-
>
> Ip_contrack: maximum limit of 1016 entries exceeded.
echo 32760 > /proc/sys/net/ipv4/ip_conntrack_max
Works to increase the size of the table. I had a problem with a default
of ~4092 for this when I was copying LOTS of files between machines
using "get -R directory" in ncftp. The above cured it.
HTH,
-Ath
--
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
Finger athan(at)fysh.org for PGP key
"And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]
^ permalink raw reply
* Re: [PATCH] ipt_mask
From: Harald Welte @ 2003-01-10 14:05 UTC (permalink / raw)
To: Luciano Ruete; +Cc: netfilter-devel
In-Reply-To: <3DEBA04C.7080606@myrealbox.com>
[-- Attachment #1: Type: text/plain, Size: 1080 bytes --]
On Mon, Dec 02, 2002 at 03:02:52PM -0300, Luciano Ruete wrote:
> Hi, i've made a netfilter match module called ipt_mask. Basically it
> provides arbitrary mask syntax to do a match whit the destination address.
> ie:
Hi, sorry for my late reply.
> will logical AND the first parameter(and_mask) whit the daddress and
> then compare the result whit the second parameter(cmpr_mask)
> As result it is MARKing whit 6900 the even daddress and whit 6901 the
> odd daddress.
>
> It works for me to do a dirty ;-) load balancing between to or more
> providers.
Due to the experimental nature of this match (and the lack of practical
use, from my point of view), I will not integrate it into patch-o-matic.
I hope you will understand this,
Harald.
> Luciano
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: [RESEND] clipping
From: Antonino Daplas @ 2003-01-10 13:55 UTC (permalink / raw)
To: James Simmons; +Cc: Linux Fbdev development list
In-Reply-To: <Pine.GSO.4.21.0301092242210.8148-100000@vervain.sonytel.be>
On Fri, 2003-01-10 at 05:46, Geert Uytterhoeven wrote:
> On Thu, 9 Jan 2003, James Simmons wrote:
> > > So perhaps, a function something like this:
> > >
> > > void fb_clip(struct fb_fillrect *region, struct fb_fillrect *clip);
> > >
> > > This should not be difficult to implement, and I'll code it if everyone
> > > agrees.
> >
> > I thought about this. Originally I did have this function but removed it.
> > WHat do you think Geert?
>
> Yes, that's OK.
>
> But I was most concerned about fb_ops.fb_imageblit(), since clipping impacts
> fb_image.data as well. IIRC, all (most?) current clipping implementations
> modify fb_image.{dx,dy,width,height} only, without updating fb_image.data.
>
> > > The other option (which I don't like) is just to check the passed
> > > fb_var_screeninfo in the put_var ioctl against the current console
> > > window size. But this is not foolproof as we will not be sure of the
> > > resulting window size _after_ the fb_set_var() call.
> >
> > Yuck!!! The other way is better.
>
> Well, in between the calls to fb_ops.fb_check_var() and fb_ops.set_par() you
> can still perform that check. But it's indeed ugly.
>
Geert, James
I've attached a patch that implements clipping in the fbcon layer using
2 generic clipping functions:
fb_clip_region() - one area to clip; and
fb_clip_region2() - two areas to clip (source and destination) as in
copyarea()
The above functions use this:
struct fb_region {
__u32 dx;
__u32 dy;
__u32 width;
__u32 height;
};
which is just a subset of fb_{image,copyarea,fillrect}. Good thing that
you arranged those fields in the right order :-).
fb_clip_region() is a standard clipping implementation, whereas
fb_clip_region2() is a bit trickier because it has to clip _both_ the
source and destination against each other. Most of 2 operand clipping
operations always assume that the source area need not be clipped.
For putcs and putc, I just made it mandatory that when one character is
to be out of bounds, it just won't get drawn. A cleaner implementation
is, of course, to clip the destination window + the passed bitmap.
For accel_cursor(), if it's going out of bounds, I place it at
screenpos(0,0) and hide it. Hopefully no one notices :-)
Do we need to clip the fb_set_logo() too?
I've also modified the cfb_{fillrect,copyarea,imageblit}: removed
clipping code and so it does not modify the passed parameters.
The patch may be a bit difficult to swallow because it is pretty much
invasive and not so clean :-(, so it's okay if you don't take it.
But it has the advantage of clipping the coordinates for hardware that
does not support clipping (like the i810fb). For hardware that does
support clipping, or wants to implement its own clipping code, we require
a 'caps' (capabilities) field in fb_info or fb_fix_screeninfo. This is
checked first and if set, the default clipping code is bypassed.
Here's how it currently works in my system:
1. reduce xres_virtual - works as expected, the tail end of the chars
are truncated.
2. reduce yres_virtual - works as expected but display is useless as the
screen is located deep down towards the end of yres_virtual.
In all cases, the screen can be restored when switching from another
console and back.
Tony
diff -Naur linux-2.5.54/drivers/video/cfbcopyarea.c linux/drivers/video/cfbcopyarea.c
--- linux-2.5.54/drivers/video/cfbcopyarea.c 2003-01-09 13:58:14.000000000 +0000
+++ linux/drivers/video/cfbcopyarea.c 2003-01-09 13:57:43.000000000 +0000
@@ -321,7 +321,6 @@
void cfb_copyarea(struct fb_info *p, struct fb_copyarea *area)
{
- int x2, y2, old_dx, old_dy, vxres, vyres;
unsigned long next_line = p->fix.line_length;
int dst_idx = 0, src_idx = 0, rev_copy = 0;
unsigned long *dst = NULL, *src = NULL;
@@ -330,40 +329,6 @@
if (!p->fbops->fb_rotate && p->var.rotate) {
}
- vxres = p->var.xres_virtual;
- vyres = p->var.yres_virtual;
-
- if (area->dx > vxres || area->sx > vxres ||
- area->dy > vyres || area->sy > vyres)
- return;
-
- /* clip the destination */
- old_dx = area->dx;
- old_dy = area->dy;
-
- /*
- * We could use hardware clipping but on many cards you get around
- * hardware clipping by writing to framebuffer directly.
- */
- x2 = area->dx + area->width;
- y2 = area->dy + area->height;
- area->dx = area->dx > 0 ? area->dx : 0;
- area->dy = area->dy > 0 ? area->dy : 0;
- x2 = x2 < vxres ? x2 : vxres;
- y2 = y2 < vyres ? y2 : vyres;
- area->width = x2 - area->dx;
- area->height = y2 - area->dy;
-
- /* update sx1,sy1 */
- area->sx += (area->dx - old_dx);
- area->sy += (area->dy - old_dy);
-
- /* the source must be completely inside the virtual screen */
- if (area->sx < 0 || area->sy < 0 ||
- (area->sx + area->width) > vxres ||
- (area->sy + area->height) > vyres)
- return;
-
if (area->dy > area->sy || (area->dy == area->sy && area->dx > area->sx)) {
area->dy += area->height;
area->sy += area->height;
diff -Naur linux-2.5.54/drivers/video/cfbfillrect.c linux/drivers/video/cfbfillrect.c
--- linux-2.5.54/drivers/video/cfbfillrect.c 2003-01-09 13:58:10.000000000 +0000
+++ linux/drivers/video/cfbfillrect.c 2003-01-09 13:57:44.000000000 +0000
@@ -361,7 +361,6 @@
void cfb_fillrect(struct fb_info *p, struct fb_fillrect *rect)
{
unsigned long height, fg;
- unsigned long x2, y2, vxres, vyres;
unsigned long *dst;
int dst_idx, left;
u32 bpp = p->var.bits_per_pixel;
@@ -370,21 +369,7 @@
if (!p->fbops->fb_rotate && p->var.rotate) {
}
- vxres = p->var.xres_virtual;
- vyres = p->var.yres_virtual;
-
- if (!rect->width || !rect->height || rect->dx > vxres || rect->dy > vyres)
- return;
-
- /* We could use hardware clipping but on many cards you get around
- * hardware clipping by writing to framebuffer directly. */
-
- x2 = rect->dx + rect->width;
- y2 = rect->dy + rect->height;
- x2 = x2 < vxres ? x2 : vxres;
- y2 = y2 < vyres ? y2 : vyres;
- rect->width = x2 - rect->dx;
- height = y2 - rect->dy;
+ height = rect->height;
if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
p->fix.visual == FB_VISUAL_DIRECTCOLOR )
diff -Naur linux-2.5.54/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.54/drivers/video/cfbimgblt.c 2003-01-09 13:58:19.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c 2003-01-09 15:52:14.000000000 +0000
@@ -88,11 +88,13 @@
#if defined (__BIG_ENDIAN)
#define LEFT_POS(bpp) (BITS_PER_LONG - bpp)
+#define LEFT_POS32(bpp) (32 - bpp)
#define NEXT_POS(pos, bpp) ((pos) -= (bpp))
#define SHIFT_HIGH(val, bits) ((val) >> (bits))
#define SHIFT_LOW(val, bits) ((val) << (bits))
#else
#define LEFT_POS(bpp) (0)
+#define LEFT_POS32(bpp) (0)
#define NEXT_POS(pos, bpp) ((pos) += (bpp))
#define SHIFT_HIGH(val, bits) ((val) << (bits))
#define SHIFT_LOW(val, bits) ((val) >> (bits))
@@ -224,25 +226,25 @@
}
static inline void fast_imageblit(struct fb_image *image, struct fb_info *p, u8 *dst1,
- unsigned long fgcolor, unsigned long bgcolor)
+ u32 fgcolor, u32 bgcolor)
{
int i, j, k, l = 8, n;
- unsigned long bit_mask, end_mask, eorx;
- unsigned long fgx = fgcolor, bgx = bgcolor, pad, bpp = p->var.bits_per_pixel;
- unsigned long tmp = (1 << bpp) - 1;
- unsigned long ppw = BITS_PER_LONG/bpp, ppos;
- unsigned long *dst;
+ u32 bit_mask, end_mask, eorx;
+ u32 fgx = fgcolor, bgx = bgcolor, pad, bpp = p->var.bits_per_pixel;
+ u32 tmp = (1 << bpp) - 1;
+ u32 ppw = 32/bpp, ppos;
+ u32 *dst;
u32 *tab = NULL;
char *src = image->data;
- switch (ppw) {
- case 4:
+ switch (bpp) {
+ case 8:
tab = cfb_tab8;
break;
- case 2:
+ case 16:
tab = cfb_tab16;
break;
- case 1:
+ case 32:
tab = cfb_tab32;
break;
}
@@ -264,17 +266,17 @@
k = image->width/ppw;
for (i = image->height; i--; ) {
- dst = (unsigned long *) dst1;
+ dst = (u32 *) dst1;
for (j = k; j--; ) {
l -= ppw;
end_mask = tab[(*src >> l) & bit_mask];
- FB_WRITEL((end_mask & eorx)^bgx, dst++);
+ fb_writel((end_mask & eorx)^bgx, dst++);
if (!l) { l = 8; src++; }
}
if (n) {
end_mask = 0;
- ppos = LEFT_POS(bpp);
+ ppos = LEFT_POS32(bpp);
for (j = n; j > 0; j--) {
l--;
if (*src & (1 << l))
@@ -282,7 +284,7 @@
NEXT_POS(ppos, bpp);
if (!l) { l = 8; src++; }
}
- FB_WRITEL((end_mask & eorx)^bgx, dst++);
+ fb_writel((end_mask & eorx)^bgx, dst++);
}
l -= pad;
dst1 += p->fix.line_length;
@@ -291,30 +293,10 @@
void cfb_imageblit(struct fb_info *p, struct fb_image *image)
{
- int x2, y2, vxres, vyres;
unsigned long fgcolor, bgcolor, start_index, bitstart, pitch_index = 0;
unsigned long bpl = sizeof(unsigned long), bpp = p->var.bits_per_pixel;
u8 *dst1;
- vxres = p->var.xres_virtual;
- vyres = p->var.yres_virtual;
- /*
- * We could use hardware clipping but on many cards you get around hardware
- * clipping by writing to framebuffer directly like we are doing here.
- */
- if (image->dx > vxres ||
- image->dy > vyres)
- return;
-
- x2 = image->dx + image->width;
- y2 = image->dy + image->height;
- image->dx = image->dx > 0 ? image->dx : 0;
- image->dy = image->dy > 0 ? image->dy : 0;
- x2 = x2 < vxres ? x2 : vxres;
- y2 = y2 < vyres ? y2 : vyres;
- image->width = x2 - image->dx;
- image->height = y2 - image->dy;
-
bitstart = (image->dy * p->fix.line_length * 8) + (image->dx * bpp);
start_index = bitstart & (BITS_PER_LONG - 1);
pitch_index = (p->fix.line_length & (bpl - 1)) * 8;
@@ -337,7 +319,8 @@
bpp >= 8 && bpp <= 32 && (image->width & 7) == 0)
fast_imageblit(image, p, dst1, fgcolor, bgcolor);
else
- slow_imageblit(image, p, dst1, fgcolor, bgcolor, start_index, pitch_index);
+ slow_imageblit(image, p, dst1, (u32) fgcolor, (u32) bgcolor,
+ start_index, pitch_index);
}
else if (image->depth == bpp)
color_imageblit(image, p, dst1, start_index, pitch_index);
diff -Naur linux-2.5.54/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.54/drivers/video/console/fbcon.c 2003-01-09 13:52:34.000000000 +0000
+++ linux/drivers/video/console/fbcon.c 2003-01-10 02:50:37.000000000 +0000
@@ -351,6 +351,7 @@
struct fb_info *info = p->fb_info;
struct vc_data *vc = p->conp;
struct fb_copyarea area;
+ struct fb_region clip, s_region, d_region;
area.sx = sx * vc->vc_font.width;
area.sy = sy * vc->vc_font.height;
@@ -359,6 +360,33 @@
area.height = height * vc->vc_font.height;
area.width = width * vc->vc_font.width;
+ if (!(info->caps & FB_CAPS_CLIPPING) &&
+ (vc->vc_cols * vc->vc_font.width > info->var.xres_virtual ||
+ vc->vc_rows * vc->vc_font.height > info->var.yres_virtual)) {
+ clip.dx = clip.dy = 0;
+ clip.width = info->var.xres_virtual;
+ clip.height = info->var.yres_virtual;
+
+ s_region.dx = area.sx;
+ s_region.dy = area.sy;
+ d_region.dx = area.dx;
+ d_region.dy = area.dy;
+ s_region.width = d_region.width = area.width;
+ s_region.height = d_region.height = area.height;
+
+ fb_clip_region2(&d_region, &s_region, &clip);
+
+ if (!d_region.width || !d_region.height)
+ return;
+
+ area.dx = d_region.dx;
+ area.dy = d_region.dy;
+ area.sx = s_region.dx;
+ area.sy = s_region.dy;
+ area.width = d_region.width;
+ area.height = d_region.height;
+ }
+
info->fbops->fb_copyarea(info, &area);
}
@@ -367,6 +395,7 @@
{
struct fb_info *info = p->fb_info;
struct fb_fillrect region;
+ struct fb_region clip;
region.color = attr_bgcol_ec(p, vc);
region.dx = sx * vc->vc_font.width;
@@ -375,9 +404,36 @@
region.height = height * vc->vc_font.height;
region.rop = ROP_COPY;
+ if (!(info->caps & FB_CAPS_CLIPPING) &&
+ (vc->vc_cols * vc->vc_font.width > info->var.xres_virtual ||
+ vc->vc_rows * vc->vc_font.height > info->var.yres_virtual)) {
+ clip.dx = clip.dy = 0;
+ clip.width = info->var.xres_virtual;
+ clip.height = info->var.yres_virtual;
+ fb_clip_region((struct fb_region *) ®ion, &clip);
+ if (!region.width || !region.height)
+ return;
+ }
+
info->fbops->fb_fillrect(info, ®ion);
}
+static int test_clip(struct fb_region *clip,
+ struct fb_region *src)
+{
+ struct fb_region region = *src;
+
+ fb_clip_region(®ion, clip);
+
+ if (region.dx != src->dx ||
+ region.dy != src->dy ||
+ region.width != src->width ||
+ region.height != src->height)
+ return 1;
+
+ return 0;
+}
+
#define FB_PIXMAPSIZE 8192
void accel_putcs(struct vc_data *vc, struct display *p,
const unsigned short *s, int count, int yy, int xx)
@@ -386,7 +442,9 @@
unsigned short charmask = p->charmask;
unsigned int width = ((vc->vc_font.width + 7)/8);
unsigned int cellsize = vc->vc_font.height * width;
+ unsigned int do_clip = 0;
struct fb_image image;
+ struct fb_region clip;
u16 c = scr_readw(s);
static u8 pixmap[FB_PIXMAPSIZE];
@@ -397,7 +455,26 @@
image.height = vc->vc_font.height;
image.depth = 1;
- if (!(vc->vc_font.width & 7)) {
+ if (!(info->caps & FB_CAPS_CLIPPING) &&
+ (vc->vc_cols * vc->vc_font.width > info->var.xres_virtual ||
+ vc->vc_rows * vc->vc_font.height > info->var.yres_virtual)) {
+ clip.dx = clip.dy = 0;
+ clip.width = info->var.xres_virtual;
+ clip.height = info->var.yres_virtual;
+ do_clip = 1;
+ /* we do some cheating here... If the bitmap will
+ * be clipped, we just pass it to the slower method
+ * of 1 imageblit per character.
+ */
+ if (!(vc->vc_font.width & 7)) {
+ struct fb_region *region = (struct fb_region *) ℑ
+
+ image.width = count * vc->vc_font.width;
+ do_clip = (test_clip(&clip, region)) ? 2 : do_clip;
+ }
+ }
+
+ if (!(vc->vc_font.width & 7) && do_clip != 2) {
unsigned int pitch, cnt, i, j, k;
unsigned int maxcnt = FB_PIXMAPSIZE/(vc->vc_font.height * width);
char *src, *dst, *dst0;
@@ -429,11 +506,14 @@
count -= cnt;
}
} else {
+ struct fb_region *region = (struct fb_region *) ℑ
image.width = vc->vc_font.width;
while (count--) {
image.data = p->fontdata +
(scr_readw(s++) & charmask) *
vc->vc_font.height * width;
+ if (do_clip && test_clip(&clip, region))
+ return;
info->fbops->fb_imageblit(info, &image);
image.dx += vc->vc_font.width;
}
@@ -450,16 +530,32 @@
unsigned int bh = info->var.yres % ch;
unsigned int rs = info->var.xres - rw;
unsigned int bs = info->var.yres - bh;
+ unsigned int do_clip = 0;
struct fb_fillrect region;
+ struct fb_region clip;
region.color = attr_bgcol_ec(p, vc);
region.rop = ROP_COPY;
+ if (!(info->caps & FB_CAPS_CLIPPING) &&
+ (vc->vc_cols * vc->vc_font.width > info->var.xres_virtual ||
+ vc->vc_rows * vc->vc_font.height > info->var.yres_virtual)) {
+ clip.dx = clip.dy = 0;
+ clip.width = info->var.xres_virtual;
+ clip.height = info->var.yres_virtual;
+ do_clip = 1;
+ }
+
if (rw & !bottom_only) {
region.dx = info->var.xoffset + rs;
region.dy = 0;
region.width = rw;
region.height = info->var.yres_virtual;
+ if (do_clip) {
+ fb_clip_region((struct fb_region *) ®ion, &clip);
+ if (!region.width || !region.height)
+ return;
+ }
info->fbops->fb_fillrect(info, ®ion);
}
@@ -468,6 +564,11 @@
region.dy = info->var.yoffset + bs;
region.width = rs;
region.height = bh;
+ if (do_clip) {
+ fb_clip_region((struct fb_region *) ®ion, &clip);
+ if (!region.width || !region.height)
+ return;
+ }
info->fbops->fb_fillrect(info, ®ion);
}
}
@@ -490,6 +591,28 @@
cursor.set |= FB_CUR_SETSIZE;
}
+ if (!(info->caps & FB_CAPS_CLIPPING) &&
+ (vc->vc_cols * vc->vc_font.width > info->var.xres_virtual ||
+ vc->vc_rows * vc->vc_font.height > info->var.yres_virtual)) {
+ struct fb_region clip, test;
+
+ clip.dx = clip.dy = 0;
+ clip.width = info->var.xres_virtual;
+ clip.height = info->var.yres_virtual;
+ test.dx = xx * width;
+ test.dy = yy * height;
+ test.width = width;
+ test.height = height;
+
+ /*
+ * we place cursor at screenpos(0,0) and hide it :-)
+ */
+ if (test_clip(&clip, &test)) {
+ xx = 0; yy = 0;
+ flags &= ~FB_CUR_SETCUR;
+ }
+ }
+
if ((vc->vc_cursor_type & 0x0f) != shape) {
shape = vc->vc_cursor_type & 0x0f;
cursor.set |= FB_CUR_SETSHAPE;
@@ -1173,6 +1296,18 @@
image.depth = 1;
image.data = p->fontdata + (c & charmask) * vc->vc_font.height * width;
+ if (!(info->caps & FB_CAPS_CLIPPING) &&
+ (vc->vc_cols * vc->vc_font.width > info->var.xres_virtual ||
+ vc->vc_rows * vc->vc_font.height > info->var.yres_virtual)) {
+ struct fb_region clip;
+
+ clip.dx = clip.dy = 0;
+ clip.width = info->var.xres_virtual;
+ clip.height = info->var.yres_virtual;
+ if (test_clip(&clip, (struct fb_region *) &image))
+ return;
+ }
+
info->fbops->fb_imageblit(info, &image);
if (redraw_cursor)
@@ -1917,7 +2052,9 @@
conp2->vc_top = 0;
logo_shown = -1;
}
- if (info)
+ fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
+ p->vrows = info->var.yres_virtual/vc->vc_font.height;
+ if (info)
info->var.yoffset = p->yscroll = 0;
switch (p->scrollmode & __SCROLL_YMASK) {
case __SCROLL_YWRAP:
@@ -1937,7 +2074,6 @@
info->currcon = unit;
- fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
update_var(unit, info);
fbcon_set_palette(vc, color_table);
diff -Naur linux-2.5.54/drivers/video/fbmem.c linux/drivers/video/fbmem.c
--- linux-2.5.54/drivers/video/fbmem.c 2003-01-09 13:52:13.000000000 +0000
+++ linux/drivers/video/fbmem.c 2003-01-10 03:40:17.000000000 +0000
@@ -368,6 +368,134 @@
#define LOGO_H 80
#define LOGO_W 80
+/**
+ * fb_clip_region: software clipping
+ * @region: area to clip
+ * @clip: clipping coordinates
+ */
+void fb_clip_region(struct fb_region *region,
+ const struct fb_region *clip)
+{
+ u32 clipx2 = clip->dx + clip->width;
+ u32 clipy2 = clip->dy + clip->height;
+
+ if (region->dx > clipx2) {
+ region->dx = clipx2;
+ region->width = 0;
+ }
+
+ if (region->dy > clipy2) {
+ region->dy = clipy2;
+ region->height = 0;
+ }
+
+ if (region->dx < clip->dx)
+ region->dx = clip->dx;
+
+ if (clipx2 < region->dx + region->width)
+ region->width = clipx2 - region->dx;
+
+ if (region->dy < clip->dy)
+ region->dy = clip->dy - region->dy;
+
+ if (clipy2 < region->dy + region->height)
+ region->height = clipy2 - clip->dy;
+}
+
+/**
+ * fb_clip_region2: software clipping
+ * @d_region: dst area to clip
+ * @s_region: src area to clip
+ * @clip: clipping coordinates
+ */
+void fb_clip_region2(struct fb_region *d_region,
+ struct fb_region *s_region,
+ const struct fb_region *clip)
+{
+ u32 clipx2 = clip->dx + clip->width;
+ u32 clipy2 = clip->dy + clip->height;
+ u32 dx2, dy2, sx2, sy2;
+
+ if (d_region->dx > clipx2) {
+ d_region->dx = clipx2;
+ d_region->width = 0;
+ }
+
+ if (d_region->dy > clipy2) {
+ d_region->dy = clipy2;
+ d_region->height = 0;
+ }
+
+ if (s_region->dx > clipx2) {
+ s_region->dx = clipx2;
+ s_region->width = 0;
+ }
+
+ if (s_region->dy > clipy2) {
+ s_region->dy = clipy2;
+ s_region->height = 0;
+ }
+
+ /* clip source, against destination */
+ if (d_region->dx < clip->dx) {
+ dx2 = d_region->dx + d_region->width;
+ s_region->width = (clip->width < dx2 - clip->dx) ?
+ clip->width : dx2 - clip->dx;
+ s_region->dx += clip->dx - d_region->dx;
+ d_region->dx = clip->dx;
+ }
+
+ dx2 = d_region->dx + s_region->width;
+ if (clipx2 < dx2)
+ s_region->width = clipx2 - d_region->dx;
+
+ d_region->width = s_region->width;
+
+ if (d_region->dy < clip->dy) {
+ dy2 = d_region->dy + d_region->height;
+ s_region->height = (clip->height < dy2 - clip->dy) ?
+ clip->height : dy2 - clip->dy;
+ s_region->dy += clip->dy - d_region->dy;
+ d_region->dy = clip->dy;
+ }
+
+ dy2 = d_region->dy + s_region->height;
+ if (clipy2 < dy2)
+ s_region->height = clipx2 - d_region->dy;
+
+ d_region->height = s_region->height;
+
+ /* not guaranteed that source is within bounds, so... */
+ /* clip destination, against source */
+ if (s_region->dx < clip->dx) {
+ sx2 = s_region->dx + s_region->width;
+ d_region->width = (clip->width < sx2 - clip->dx) ?
+ clip->width : sx2 - clip->dx;
+ d_region->dx += clip->dx - s_region->dx;
+ s_region->dx = clip->dx;
+ }
+
+ sx2 = s_region->dx + d_region->width;
+ if (clipx2 < sx2)
+ d_region->width = clipx2 - s_region->dx;
+
+ s_region->width = d_region->width;
+
+ if (s_region->dy < clip->dy) {
+ sy2 = s_region->dy + s_region->height;
+ d_region->height = (clip->height < sy2 - clip->dy) ?
+ clip->height : sy2 - clip->dy;
+ d_region->dy += clip->dy - s_region->dy;
+ s_region->dy = clip->dy;
+ }
+
+ sy2 = s_region->dy + d_region->height;
+ if (clipy2 < sy2)
+ d_region->height = clipx2 - s_region->dy;
+
+ s_region->height = d_region->height;
+}
+
static inline unsigned safe_shift(unsigned d, int n)
{
return n < 0 ? d >> -n : d << n;
@@ -1189,5 +1317,7 @@
EXPORT_SYMBOL(fb_set_var);
EXPORT_SYMBOL(fb_blank);
EXPORT_SYMBOL(fb_pan_display);
+EXPORT_SYMBOL(fb_clip_region);
+EXPORT_SYMBOL(fb_clip_region2);
MODULE_LICENSE("GPL");
diff -Naur linux-2.5.54/include/linux/fb.h linux/include/linux/fb.h
--- linux-2.5.54/include/linux/fb.h 2003-01-09 13:52:49.000000000 +0000
+++ linux/include/linux/fb.h 2003-01-09 13:51:41.000000000 +0000
@@ -173,6 +173,9 @@
#define FB_VMODE_SMOOTH_XPAN 512 /* smooth xpan possible (internally used) */
#define FB_VMODE_CONUPDATE 512 /* don't update x/yoffset */
+/* Driver Capability */
+#define FB_CAPS_CLIPPING 1 /* hardware can do clipping */
+
#define PICOS2KHZ(a) (1000000000UL/(a))
#define KHZ2PICOS(a) (1000000000UL/(a))
@@ -394,6 +397,7 @@
void *pseudo_palette; /* Fake palette of 16 colors and
the cursor's color for non
palette mode */
+ int caps; /* Driver capability, see FB_CAPS_* */
/* From here on everything is device dependent */
void *par;
};
@@ -461,6 +465,11 @@
extern int register_framebuffer(struct fb_info *fb_info);
extern int unregister_framebuffer(struct fb_info *fb_info);
extern int fb_show_logo(struct fb_info *fb_info);
+extern void fb_clip_region(struct fb_region *region,
+ const struct fb_region *clip);
+extern void fb_clip_region2(struct fb_region *s_region,
+ struct fb_region *d_region,
+ const struct fb_region *clip);
extern struct fb_info *registered_fb[FB_MAX];
extern int num_registered_fb;
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Nvidia and its choice to read the GPL "differently"
From: Charles Cazabon @ 2003-01-10 14:17 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20030110053305.GD14778@waste.org>
Oliver Xymoron <oxymoron@waste.org> wrote:
> On Thu, Jan 09, 2003 at 06:14:37PM -0500, Richard Stallman wrote:
> [GNU/Linux stuff deleted]
>
> Can we all agree that this is indeed the kernel list and that the
> kernel is indeed known as simply 'Linux' and that therefore the
> GNU/Linux debate is off-topic here?
Or perhaps we should start a long, boring discussion of how to best rearrange
the drivers portion of the tree on <gnu-misc-discuss@gnu.org> .
I once had quite a lot of respect for RMS. That has faded somewhat over the
last year due to this crap.
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <linux@discworld.dyndns.org>
GPL'ed software available at: http://www.qcc.ca/~charlesc/software/
-----------------------------------------------------------------------
^ permalink raw reply
* Re: Linux 2.4.21pre3-ac2
From: Ralf Hildebrandt @ 2003-01-10 14:17 UTC (permalink / raw)
To: Linux Kernel Mailing List
In-Reply-To: <20030110133028.GB12071@charite.de>
* Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>:
> Backing out of mm/shmem.c makess thee bug disappear.
Not really. I rebooted and then the ac2 crashed DURING a fsck that was
caused by reaching the maximum mount count.
I'm outta here and back to 2.4.21pre3 :)
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt@charite.de
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
^ 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.