* Re: ipv6 stack seems to forget to send ACKs
From: Andrew McGregor @ 2003-01-09 11:55 UTC (permalink / raw)
To: Rogier Wolff, netdev, linux-kernel
In-Reply-To: <20030109123857.A15625@bitwizard.nl>
--On Thursday, January 09, 2003 12:38:58 +0100 Rogier Wolff
<R.E.Wolff@BitWizard.nl> wrote:
> On Wed, Jan 08, 2003 at 02:08:50PM +0100, Wichert Akkerman wrote:
>>
Looked normal and then:
>
>> 13:57:40.282351 2001:968:1::2.8000 > tornado.wiggy.net.33035: .
>> 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369670744 846103>
>
> But now: No ack! Funny.
Might be SACK deciding not to...
>> 13:57:40.284307 2001:968:1::2.8000 > tornado.wiggy.net.33035: .
>> 9360433:9360653(220) ack 1 win 5712 <nop,nop,timestamp 369670744 846103>
>
> Another packet, no ack!
>
>> 13:57:40.297307 2001:968:1::2.8000 > tornado.wiggy.net.33035: .
>> 9360653:9361861(1208) ack 1 win 5712 <nop,nop,timestamp 369670745 846104>
>> 13:57:40.297376 tornado.wiggy.net.33035 > 2001:968:1::2.8000: . ack
>> 9359225 win 32616 <nop,nop,timestamp 846111 369670744,nop,nop,sack sack
>> 1 {9360653:9361861} >
>
> Another packet, but this time it SACKs the just-recieved packet. It looks
> as if the two packets inbetween somehow were not recognized as belonging
> with this connection.
or SACK forgot about them?
> Two more packets, and still more hints towards the other machine that
> we're missing 9359225-9360653
>
>> 13:57:40.568652 2001:968:1::2.8000 > tornado.wiggy.net.33035: .
>> 9359225:9360433(1208) ack 1 win 5712 <nop,nop,timestamp 369670773 846113>
>
> So, it retransmits the first. but we don't see it as beloging to
> this connection or something, so it gets ignored.
or we're waiting for the other one to ACK them both in one go?
> It looks as if somehow those two packets 9359225:9360433 and
> 9360433:9360653 get mangled in a way as to invalidate the checksum. This
> would cause "silent drop" of these packets before they were acked....
Could be data dependant, so there's a pattern in the packet contents that
causes this?
> Can you check the stats counters, to see if they are indeed dropped?
>
> Roger.
^ permalink raw reply
* Re: aic7xxx broken in 2.5.53/54 ?
From: David Lang @ 2003-01-09 11:52 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: dipankar, linux-scsi, linux-kernel
In-Reply-To: <274040000.1041869813@aslan.scsiguy.com>
I just tried 2.5.55 and it still locks up. I will hook up my laptop and
see if I can get aa serial console dump tomorrow night.
messages are
Slave Alloc 0
launching DV thread
begin domain validation
scsi0:2477 going from state 0 to state 1
scsi0:A:0:0: sending INQ
scsi0:timeout while doing DV command 12
scsi0:0:0:0 command completed status=0x90000
scsi0:A:0:0 enntering ahc_linux_dv_transition, state=1 statis=0x14005, cmd->result=0x90000
scsi0:2645 going from state 1 to state 1
at this point all the messages between the 'going to state' messages
repeat exactly, this happens for a couple min and then a whole bunch of
other stuff scrolls by (I don't know if this happens on previous versions,
I had given up before that much time had passed) the final message is
something about a recovery sleep and then the machine stops responding (I
waited 10 min this time to make sure it wasn't going to start working
again)
Daavid Lang
On Mon, 6 Jan 2003, Justin T. Gibbs wrote:
> Date: Mon, 06 Jan 2003 09:16:53 -0700
> From: Justin T. Gibbs <gibbs@scsiguy.com>
> To: dipankar@in.ibm.com
> Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
> Subject: Re: aic7xxx broken in 2.5.53/54 ?
>
> > Hi Justin,
> >
> > On Fri, Jan 03, 2003 at 08:14:06AM -0700, Justin T. Gibbs wrote:
> >> > Looks like the aic7xxx driver in 2.5.53 and 54 are broken on my
> >> > hardware.
> >>
> >> It looks like the driver recovers fine.
> >
> > Not for long. It dies shortly afterwards.
>
> In what fashion?
>
> >> > aic7xxx: PCI Device 0:1:0 failed memory mapped test. Using PIO.
> >> > Uhhuh. NMI received for unknown reason 25 on CPU 0.
> >>
> >> SERR must be enabled by your BIOS. I will change the driver so
> >> that, should the memory mapped I/O test fail, an SERR (and thus an
> >> NMI) is not generated.
> >
> > I guess having to use PIO with aic7xxx is bad. MMIO failure is
> > what we need to investigate.
>
> The only way that I know how to investigate these issues is
> with a PCI bus analyzer. We're in the process of going through
> all of the systems we have in our lab to see which ones fail and
> why, but I certainly don't have one of every failing system on
> the planet. 8-)
>
> >> Just out of curiosity, do you have any strange PCI options enabled
> >> in your BIOS? I remeber seeing memory mapped I/O failures on this
> >> ServerWorks chipset under FreeBSD in the past, but an updated BIOS
> >> resolved the issue for the affected users. It seemed that the BIOS
> >> incorrectly placed the Adaptec controller in a prefetchable region.
> >>
> >
> > I didn't change anything in that box since it was delivered to me. FYI
> > it is an IBM x250. Would it help if I can get a PCI space dump and mtrr
> > dump ? FWIW, the older driver works fine. Does the older driver use
> > only PIO ?
>
> It would be good to know the chipset on the motherboard. As to why
> the old driver worked, for 6.X.X drivers, you may have just been lucky.
> For 5.X.X drivers, they perform a read after every register write to
> "manually" prevent any byte-merging. These reads are actually more
> expensive than just using PIO. Neither of these older drivers included
> a test to try and catch fishy behavior.
>
> --
> Justin
> -
> 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: Accessing DiskonChip
From: Sanal Kumar @ 2003-01-09 12:26 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-arm-kernel, linux-mtd
In-Reply-To: <27941.1041929480@passion.cambridge.redhat.com>
Hi David ,
Sorry for not explaining the problem in detail.
I have read the howto's on the infradead .
But still I dont understand how to create a partition
on Disk on chip
and have filesystem on it.
I have tried with nftl_* .But I could not do anything.
Could you please explain what I need to do for making
the filesystem on DOC.
Boot Messages
--------------
out-of-line wait
_DoC_WaitReady called for out-of-line wait
.
. _DoC_WaitReady called for out-of-line wait
Could not find valid boot record
Could not mount NFTL device
and using nftl_format I tried to format the diskon
chip But I get an error like the following
NFTL_open
ENODEV: thisNFTL = 0, minor = 23808, ip = c94ac4c0, fp
= c965caa0
NFTL_open
ENODEV: thisNFTL = 0, minor = 23809, ip = c94ac6e0, fp
= c965ca20 The only thing I could do was
dd if=XXXX of=/dev/mtd0
I am adding part of my .config here.
-----------------------------------
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=3
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_BOOTLDR_PARTS is not set
# CONFIG_MTD_AFS_PARTS is not set #
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=y
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
# CONFIG_FTL is not set
CONFIG_NFTL=y
CONFIG_NFTL_RW=y #
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
# CONFIG_MTD_GEN_PROBE is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set #
# Mapping drivers for chip access
# #
# Self-contained MTD device drivers
#
#
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set #
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC1000 is not set
CONFIG_MTD_DOC2000=y
CONFIG_MTD_DOC2001=y
CONFIG_MTD_DOCPROBE=y
# CONFIG_MTD_DOCPROBE_ADVANCED is not set
CONFIG_MTD_DOCPROBE_ADDRESS=0
# CONFIG_MTD_DOCPROBE_HIGH is not set
# CONFIG_MTD_DOCPROBE_55AA is not set #
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set
TIA
Best Regards
Sanal
--- David Woodhouse <dwmw2@infradead.org> wrote:
>
> p_sanalk@yahoo.com said:
> > I have added nftl support. So i need to support
> make a filesystem on
> > disk on chip How can I do that.
>
> Might have been useful had you included this
> information in your first
> message. The HOWTO should suffice to get you going
> from that point.
>
> --
> dwmw2
>
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
^ permalink raw reply
* Re: fb_imageblit()
From: Antonino Daplas @ 2003-01-09 11:44 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: James Simmons, Linux Frame Buffer Device Development
In-Reply-To: <Pine.GSO.4.21.0301091038390.25052-100000@vervain.sonytel.be>
On Thu, 2003-01-09 at 17:50, Geert Uytterhoeven wrote:
> On 9 Jan 2003, Antonino Daplas wrote:
> > On Wed, 2003-01-08 at 23:15, Geert Uytterhoeven wrote:
> > > > c. Read color information from pseudopalette if directcolor/truecolor.
> > >
> > > Hoever, pseudopalette has entries for the first 16 colors only!
> > > Hence you are limited to the 16 color for directcolor/truecolor modes.
> >
> > That's why there's an fb_set_logo_directpalette(), for directcolor
> > visuals >= 24bpp, and fb_set_logo_truepalette(), for truecolor, in
> > fb_set_logo(). Basically, it temporarily replaces info->pseudo_palette
> > with one that has 256 entries to match linux_logo. Logo drawing, using
> > cfb_imageblit() has always worked for me in directcolor and truecolor
> > modes.
>
> I see a small inconsistency here, which may cause problems with some exotic
> hardware: info->pseudo_palette is always initialized by the fbdev driver itself
> (which knows the hardware), except for logo drawing, where it's done by the
> generic code in fbmem.
>
> On virtually all hardware that will work fine. But on some hardware the exact
> pixel format cannot be represented by the {red,green,blue,transp} bitfields in
> fb_var_screeninfo.
>
> E.g. the Amiga CyberVision64 card has a S3Trio64. Since Amigas are little
> endian and PCI is big endian, they swapped the data bus to simplify 256-color
> modes. However, this also means that 16-bit pixel values have to be swapped. So
> in depth 15, the pixel format is not ARRRRRGGGGGBBBBB, but GGGBBBBBARRRRRGG.
> This can be handled fine in cyberfb by setting up a byteswapped pseudo palette,
> but the fb_set_logo_{direct,true}palette() don't know about this. And of course
> user space doesn't know about this neither.
>
This will be a problem only for DirectColor at >= 24 bpp. At bpp's less
than that, linux_logo_16 will be used.
Another possible solution (in case it supports 24bpp) is to have 2
pseudo_palettes, one which is 16 entries long and public, and another
256-entries long and private. Then if image.depth is < 24, it's safe to
use cfb_imageblit. Otherwise, it has to use it's own imageblit, one that
will use the private pseudo_palette. The driver will have the
opportunity to build this because fb_set_cmap() is called for
directcolor modes >= 24bpp, and pseudocolor == 8bpp.
Hopefully, exotics such as this will not export their visuals as
truecolor or static pseudocolor because fb_set_cmap() will not be
called. Otherwise, we'll just make it mandatory to call fb_set_cmap()
for all visual modes requiring linux_logo.
> One possible solution is to extend the pseudo palette to 256+1 entries if the
> depth is at least 8. To save memory, we can still use a 16+1 entry pseudo
> palette if depth < 8, but then we have to move the cursor inversion value from
> index 16 to index -1.
>
I believe the cursor inversion value is unused anymore(?), since
fbcon_revc is gone. It has been replaced by the new cursor API which
allows the driver more intimate handling of the cursor.
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: aic7xxx broken in 2.5.53/54 ?
From: David Lang @ 2003-01-09 11:52 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: dipankar, linux-scsi, linux-kernel
In-Reply-To: <274040000.1041869813@aslan.scsiguy.com>
I just tried 2.5.55 and it still locks up. I will hook up my laptop and
see if I can get aa serial console dump tomorrow night.
messages are
Slave Alloc 0
launching DV thread
begin domain validation
scsi0:2477 going from state 0 to state 1
scsi0:A:0:0: sending INQ
scsi0:timeout while doing DV command 12
scsi0:0:0:0 command completed status=0x90000
scsi0:A:0:0 enntering ahc_linux_dv_transition, state=1 statis=0x14005, cmd->result=0x90000
scsi0:2645 going from state 1 to state 1
at this point all the messages between the 'going to state' messages
repeat exactly, this happens for a couple min and then a whole bunch of
other stuff scrolls by (I don't know if this happens on previous versions,
I had given up before that much time had passed) the final message is
something about a recovery sleep and then the machine stops responding (I
waited 10 min this time to make sure it wasn't going to start working
again)
Daavid Lang
On Mon, 6 Jan 2003, Justin T. Gibbs wrote:
> Date: Mon, 06 Jan 2003 09:16:53 -0700
> From: Justin T. Gibbs <gibbs@scsiguy.com>
> To: dipankar@in.ibm.com
> Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
> Subject: Re: aic7xxx broken in 2.5.53/54 ?
>
> > Hi Justin,
> >
> > On Fri, Jan 03, 2003 at 08:14:06AM -0700, Justin T. Gibbs wrote:
> >> > Looks like the aic7xxx driver in 2.5.53 and 54 are broken on my
> >> > hardware.
> >>
> >> It looks like the driver recovers fine.
> >
> > Not for long. It dies shortly afterwards.
>
> In what fashion?
>
> >> > aic7xxx: PCI Device 0:1:0 failed memory mapped test. Using PIO.
> >> > Uhhuh. NMI received for unknown reason 25 on CPU 0.
> >>
> >> SERR must be enabled by your BIOS. I will change the driver so
> >> that, should the memory mapped I/O test fail, an SERR (and thus an
> >> NMI) is not generated.
> >
> > I guess having to use PIO with aic7xxx is bad. MMIO failure is
> > what we need to investigate.
>
> The only way that I know how to investigate these issues is
> with a PCI bus analyzer. We're in the process of going through
> all of the systems we have in our lab to see which ones fail and
> why, but I certainly don't have one of every failing system on
> the planet. 8-)
>
> >> Just out of curiosity, do you have any strange PCI options enabled
> >> in your BIOS? I remeber seeing memory mapped I/O failures on this
> >> ServerWorks chipset under FreeBSD in the past, but an updated BIOS
> >> resolved the issue for the affected users. It seemed that the BIOS
> >> incorrectly placed the Adaptec controller in a prefetchable region.
> >>
> >
> > I didn't change anything in that box since it was delivered to me. FYI
> > it is an IBM x250. Would it help if I can get a PCI space dump and mtrr
> > dump ? FWIW, the older driver works fine. Does the older driver use
> > only PIO ?
>
> It would be good to know the chipset on the motherboard. As to why
> the old driver worked, for 6.X.X drivers, you may have just been lucky.
> For 5.X.X drivers, they perform a read after every register write to
> "manually" prevent any byte-merging. These reads are actually more
> expensive than just using PIO. Neither of these older drivers included
> a test to try and catch fishy behavior.
>
> --
> Justin
> -
> 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: How to route "spdif" to an FXBUS of emu10k1
From: Jaroslav Kysela @ 2003-01-09 12:00 UTC (permalink / raw)
To: Gerard Janssen; +Cc: alsa-devel@alsa-project.org
In-Reply-To: <73972737454@Octopus.et.tudelft.nl>
On Thu, 9 Jan 2003, Gerard Janssen wrote:
> Hi Jaroslav,
>
> Many thanks for your reply. This realy solved my problem.
>
> I have been able to implement a new PCM-stream and send it to empty FXBUS
> registers. However, I could not find .asoundcr (I am using SUSE 8.1 with
> ALSA_rc6). Where is it? In stead, I adapted alsa.conf, emu10k1.conf and
> added a pcm_new.conf in /usr/share/alsa/ and this worked.
It's not necessary. The ~/.asoundrc file is also loaded, so you can store
your local configuration there.
> After having done this, I am stuck with some questions. Why are there no
> "Send Routing" lines in the "front" and "rear" config files, since they are
> routed to FXBUS?
> Why do the lines:
> > /* 22: */ OP(icode, &ptr, iMACINT1, ETRAM_ADDR(ipcm->etram[0]),
> GPR(gpr + 8), GPR_DBAC, C_ffffffff);
> > /* 23: */ OP(icode, &ptr, iMACINT1, ETRAM_ADDR(ipcm->etram[1]),
> GPR(gpr + 9), GPR_DBAC, C_ffffffff);
> have to be removed?
I've a bit overlooked the code. The simplest way is to initialize GPR(8)
and GPR(9) after the direct PCM part over ETRAM, so the 22: and 23: lines
can be replaced with
OP(icode, &ptr, iMACINT0, GPR(8), C_00000000, FXBUS(8), C_00000004);
OP(icode, &ptr, iMACINT0, GPR(9), C_00000000, FXBUS(9), C_00000004);
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* [2.5 patch] correct help text for LOG_BUF_SHIFT
From: Adrian Bunk @ 2003-01-09 12:11 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Andrew Morton, Kernel Mailing List
In-Reply-To: <Pine.GSO.4.21.0301091202511.25052-100000@vervain.sonytel.be>
On Thu, Jan 09, 2003 at 12:04:46PM +0100, Geert Uytterhoeven wrote:
> On Wed, 8 Jan 2003, Linus Torvalds wrote:
> > Andrew Morton <akpm@digeo.com>:
> > o move LOG_BUF_SIZE to header/config
>
> I find the config a bit confusing:
>
> | Kernel log buffer size (128 KB, 64 KB, 32 KB, 16 KB, 8 KB, 4 KB) [16 KB] (NEW) ?
> | Select kernel log buffer size from this list (power of 2).
> | Defaults: 17 (=> 128 KB for S/390)
> | 16 (=> 64 KB for x86 NUMAQ or IA-64)
> | 15 (=> 32 KB for SMP)
> | 14 (=> 16 KB for uniprocessor)
> |
> | Kernel log buffer size (128 KB, 64 KB, 32 KB, 16 KB, 8 KB, 4 KB) [16 KB] (NEW)
>
> E.g. should I enter `14' or `16 KB' (or `16') for `16 KB'?
After reading init/Kconfig it seems the following was intended:
--- linux-2.5.55/init/Kconfig.old 2003-01-09 13:06:43.000000000 +0100
+++ linux-2.5.55/init/Kconfig 2003-01-09 13:08:44.000000000 +0100
@@ -89,11 +89,11 @@
default LOG_BUF_SHIFT_15 if SMP
default LOG_BUF_SHIFT_14
help
- Select kernel log buffer size from this list (power of 2).
- Defaults: 17 (=> 128 KB for S/390)
- 16 (=> 64 KB for x86 NUMAQ or IA-64)
- 15 (=> 32 KB for SMP)
- 14 (=> 16 KB for uniprocessor)
+ Select kernel log buffer size from this list.
+ Defaults: 128 KB for S/390
+ 64 KB for x86 NUMAQ or IA-64
+ 32 KB for SMP
+ 16 KB for uniprocessor
config LOG_BUF_SHIFT_17
bool "128 KB"
> Gr{oetje,eeting}s,
>
> Geert
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: Linux 2.4.21pre3-ac2
From: Adrian Bunk @ 2003-01-09 12:14 UTC (permalink / raw)
To: Alan Cox, Arjan van de Ven; +Cc: linux-kernel
In-Reply-To: <200301090139.h091d9G26412@devserv.devel.redhat.com>
On Wed, Jan 08, 2003 at 08:39:09PM -0500, Alan Cox wrote:
>...
> Linux 2.4.21pre3-ac1
>...
> + IDE Raid support for AMI/SI 'Medley' IDE Raid (Arjan van de Ven)
>...
This causes a compile error if both pdcraid.o and silraid.o are compiled
statically into the kernel:
<-- snip -->
...
gcc -D__KERNEL__ -I/home/bunk/linux/kernel-2.4/linux-2.4.20-ac/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
-fno-common -pipe -mpreferred-stack-boundary=2 -march=k6 -I../
-nostdinc -iwithprefix include -DKBUILD_BASENAME=pdcraid -c -o
pdcraid.o pdcraid.c
...
gcc -D__KERNEL__ -I/home/bunk/linux/kernel-2.4/linux-2.4.20-ac/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
-fno-common -pipe -mpreferred-stack-boundary=2 -march=k6 -I../
-nostdinc -iwithprefix include -DKBUILD_BASENAME=silraid -c -o
silraid.o silraid.c
rm -f idedriver-raid.o
ld -m elf_i386 -r -o idedriver-raid.o ataraid.o pdcraid.o hptraid.o
silraid.o
silraid.o(.text+0x31c): In function `partition_map_normal':
: multiple definition of `partition_map_normal'
pdcraid.o(.text+0x31c): first defined here
make[4]: *** [idedriver-raid.o] Error 1
make[4]: Leaving directory
`/home/bunk/linux/kernel-2.4/linux-2.4.20-ac/drivers/ide/raid'
<-- snip -->
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: Accessing DiskonChip
From: David Woodhouse @ 2003-01-09 12:46 UTC (permalink / raw)
To: Sanal Kumar; +Cc: linux-arm-kernel, linux-mtd
In-Reply-To: <20030109122653.4606.qmail@web10306.mail.yahoo.com>
p_sanalk@yahoo.com said:
> and using nftl_format I tried to format the diskon chip But I get an
> error like the following
> NFTL_open
Show me the command line you used. Compare it with the command line in the
HOWTO.
--
dwmw2
^ permalink raw reply
* RE: Gigabit/SMP performance problem
From: Robert Olsson @ 2003-01-09 12:49 UTC (permalink / raw)
To: Ronciak, John
Cc: 'Robert Olsson', Avery Fay, Anton Blanchard, linux-kernel
In-Reply-To: <D9223EB959A5D511A98F00508B68C20C0AD0F269@orsmsx108.jf.intel.com>
Ronciak, John writes:
> All,
>
> We (Intel - LAN Access Division, e1000 driver) are taking a look at what is
> going on here. We don't have any data yet but we'll keep you posted on what
> we find.
Thanks.
FYI. SuperMicro reported they added a new MB jumper to disable Standby-Power
in order to get systems to boot. I don't think "driver" operation was verfied.
Cheers.
--ro
^ permalink raw reply
* Re: [2.5.54][PATCH] SB16 convertation to new PnP layer.
From: Ruslan U. Zakirov @ 2003-01-09 12:43 UTC (permalink / raw)
To: Adam Belay; +Cc: Zwane Mwaikambo, Jaroslav Kysela, linux-kernel
In-Reply-To: <20030108160939.GA17701@neo.rr.com>
AB> On Wed, Jan 08, 2003 at 08:20:13PM +0300, Ruslan U. Zakirov wrote:
>> Hello Adam and All.
>> Here is patch to sb16.c that makes it posible to compile and use this
>> driver under 2.5.54-vanilla.
>> It working for me as module and built in kernel, but it's need testing.
>> Ruslan.
AB> Hi Ruslan,
AB> I haven't had a chance to test this yet but everything does look ok. I
AB> think it will be ready once the below function is completed. Jaroslav,
AB> any comments? Also, if anyone has a built in wavetable, as previously
AB> mentioned by Zwane, I'd like to hear how this patch works for you. This
AB> patch makes full use of pnp card services, which is prefered for cards
AB> that have several closely related devices, and it would be great to
AB> further test those code paths.
AB> Thanks,
AB> Adam
>>
>> -#endif /* __ISAPNP__ */
>> +static void snd_sb16_isapnp_remove(struct pnp_card * card)
>> +{
>> + /*FIX ME*/
>> +}
>> +
>>
AB> -
AB> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
AB> the body of a message to majordomo@vger.kernel.org
AB> More majordomo info at http://vger.kernel.org/majordomo-info.html
AB> Please read the FAQ at http://www.tux.org/lkml/
Hi All!
I've got only one problem with this driver.
It's appear when I remove module and try to probe it again, then
modprobe oopsing. Problem lays somewhere under PCI_HACK.
It have been repaired in 2.5.55 with this patch
Dave Jones <davej@codemonkey.org.uk>:
o Fix up dma_alloc_coherent with 64bit DMA masks on i386
OK. I've just tested it. It's been fixed.
Ruslan.
^ permalink raw reply
* Re: [Asterisk] DTMF noise
From: David D. Hagood @ 2003-01-09 12:42 UTC (permalink / raw)
To: Thomas Tonino; +Cc: Roy Sigurd Karlsbakk, linux-kernel
In-Reply-To: <3E1C889F.70303@users.sf.net>
Thomas Tonino wrote:
> The original idea does one better by splitting high and low bands first.
<snip>
> But it may be more expensive computationally than doing twice the number
> of Goertzel filters.
Not really - the Goertzel filter is a fairly cheap filter. A filter to
split the low band frequencies off from the high band, then doing the 8
Goertzel filters for tone detection burns more MIPS than just doing the
8 Goertzel filters. Furthurmore, the result is the same - you get the
energies in the 8 tones.
> Harmonics seem like a bad idea. In between frequencies are better, but
> using the total band energy must be the most sure way to detect
> interference.
>
Not really. The problem with the total energy approach is that the least
amount of real noise will prevent tone detection, and if you set the
threshold high enough that white noise does not prevent tone detection
then you get falsing in voice.
If you have 1mW/Hz of white noise, then that is 2700 mW of noise power
across the band. With voice, you get one of two types of "noise" -
either voiced signals with lots of energy at harmonicly related
frequencies, or unvoiced fricatives ("s", "f") that are basically white
noise. A voiced signal with a total power of 2000 mW of power and a
fundemental at one of the tone frequencies might have 1000 mW of power
at the tone energy, and the remaining 1000 mW on the harmonics. Yet, if
your noise threshold is set to not be blocked by the white noise case
(2700 mW of power), then it would accept the voice case (1000 mW of power).
The 16 filter algorithm is the one we use in radio - it lets us pick a
tone out of a staticy signal without falsing on voice.
It helps to think of looking at the signal on an audio spectrum analyzer
- a DTMF tone looks like 2 peaks. If the signal in question has more
than 2 peaks, it isn't DTMF.
^ permalink raw reply
* New Script
From: mdew @ 2003-01-09 12:38 UTC (permalink / raw)
To: netfilter
Ok, after taking a few samples from scripts in the mailing list, Ive
come up with this...hopefully my edonkey problem has been solved with
this script. I havent actually tested this yet, Probably tomorrow (its a
bit late)
current Router setup.
(Internet) 210.54.175.12->eth0---Router--->eth1 10.0.0.6 -=> 10.0.0.x
#!/bin/bash
IPTABLES="/sbin/iptables"
PAUL="10.0.0.9"
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "Executing The Firwall..."
echo ""
echo -n "Loading Modules..."
/sbin/modprobe ip_conntrack_ftp
/sbin/modprobe ip_conntrack_irc
/sbin/modprobe ip_nat_irc
/sbin/modprobe ip_nat_ftp
/sbin/modprobe ipt_state
/sbin/modprobe ipt_limit
/sbin/modprobe ipt_LOG
echo -n "Done"
$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P OUTPUT ACCEPT
echo "Allow unlimited traffic on the loopback interface"
$IPTABLES -A INPUT -i lo -j ACCEPT
$IPTABLES -A OUTPUT -o lo -j ACCEPT
echo "Refusing spoofed packets pretending to be from your IP address"
$IPTABLES -A INPUT -s 210.54.175.12 -j DROP
echo "Allow SSH"
# Is this correct?
$IPTABLES -A INPUT -i eth0 -p tcp --sport 22 -j ACCEPT
$IPTABLES -A INPUT -i eth1 -p tcp --sport 22 -j ACCEPT
$IPTABLES -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
$IPTABLES -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT
echo "Allow ftp"
$IPTABLES -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED -j
ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED
-j ACCEPT
echo "Active ftp"
$IPTABLES -A INPUT -p tcp --sport 20 -m state --state
ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j
ACCEPT
echo "Passive ftp"
$IPTABLES -A INPUT -p tcp --sport 1024:65535 --dport 1024:65535 -m state
--state ESTABLISHED -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 1024:65535 --dport 1024:65535 -m
state --state ESTABLISHED,RELATED -j ACCEPT
echo "Allow DNS"
$IPTABLES -A INPUT -p tcp --sport 53 -j ACCEPT
$IPTABLES -A INPUT -p udp --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --dport 53 -j ACCEPT
echo "Allow SFTP"
$IPTABLES -A OUTPUT -p tcp --dport 115 -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 115 -j ACCEPT
echo "Allow HTTP"
$IPTABLES -A OUTPUT -p tcp --dport 80 -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 80 -j ACCEPT
echo "Allow https"
$IPTABLES -A OUTPUT -p tcp --dport 443 -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 443 -j ACCEPT
echo "Rejecting all connections to 135:139"
$IPTABLES -N NETBIOS
$IPTABLES -A INPUT -p udp --sport 135:139 -j NETBIOS
$IPTABLES -A INPUT -p tcp --sport 135:139 -j NETBIOS
$IPTABLES -A INPUT -p udp --dport 135:139 -j NETBIOS
$IPTABLES -A INPUT -p tcp --dport 135:139 -j NETBIOS
$IPTABLES -A NETBIOS -j LOG --log-prefix "IPTABLES NETBIOS: "
$IPTABLES -A NETBIOS -j DROP
echo "Limit port 4665 traffic to PAUL"
$IPTABLES -N PAULS_STUFF
$IPTABLES -A FORWARD -p tcp -s $PAUL --dport 4665 -m limit --limit
1/hour -j PAULS_STUFF
$IPTABLES -A FORWARD -p udp -s $PAUL --dport 4665 -m limit --limit
1/hour -j PAULS_STUFF
$IPTABLES -A FORWARD -p udp -s $PAUL --sport 4665 -m limit --limit
1/hour -j PAULS_STUFF
$IPTABLES -A FORWARD -p tcp -s $PAUL --sport 4665 -m limit --limit
1/hour -j PAULS_STUFF
$IPTABLES -A PAULS_STUFF -j LOG --log-prefix "IPTABLES PAUL: "
$IPTABLES -A PAULS_STUFF -j ACCEPT
echo "Allowing SMTP"
$IPTABLES -A OUTPUT -p tcp --dport 25 -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 25 -j ACCEPT
echo "Allowing POP3"
$IPTABLES -A OUTPUT -p tcp --dport 110 -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 110 -j ACCEPT
echo "Allowing Ident"
$IPTABLES -A OUTPUT -p tcp --dport 113 -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 113 -j ACCEPT
echo "Allowing Netmeeting/MSN"
$IPTABLES -t nat -A PREROUTING -i eth0 -p tcp --dport 1863 -j \
REDIRECT --to-ports 1863
$IPTABLES -t nat -A PREROUTING -i eth0 -p tcp --dport 389 -j \
REDIRECT --to-ports 389
$IPTABLES -t nat -A PREROUTING -i eth0 -p tcp --dport 522 -j \
REDIRECT --to-ports 522
echo "Allowing EDonkey2k/Emule"
echo "See: http://www.emule-project.net/faq/ports.htm"
# should i use any -A FORWARD or PREROUTING here?
$IPTABLES -A OUTPUT -p tcp --dport 4661 -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 4661 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 4662 -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 4662 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --dport 4665 -j ACCEPT
$IPTABLES -A INPUT -p udp --sport 4665 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --dport 4672 -j ACCEPT
$IPTABLES -A INPUT -p udp --sport 4672 -j ACCEPT
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
^ permalink raw reply
* Are linux network drivers really affected by this?
From: Nils Petter Vaskinn @ 2003-01-09 12:52 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
http://www.kb.cert.org/vuls/id/412115
Summary: Some network drivers don't pad ethernet packets with nulls,
they are filled with "garbage" often from previously sent packets. Linux
is mentioned as vulnerable.
Nils Petter Vaskinn
^ permalink raw reply
* nfsd module undefined symbol in 2.5.55
From: venom @ 2003-01-09 12:50 UTC (permalink / raw)
To: linux-kernel
that is:
nfsd: Unknown symbol hash_mem
Luigi
^ permalink raw reply
* Re: [Asterisk] DTMF noise
From: David D. Hagood @ 2003-01-09 12:51 UTC (permalink / raw)
To: Wolfgang Fritz; +Cc: linux-kernel
In-Reply-To: <3E1C4872.7080508@gmx.net>
Wolfgang Fritz wrote:
> Maybe it would be better to reenable harmonic checks but comparing
> harmonic levels to the level of the fundamental instead of using
> absolute values as in the present implementation.
You mean the code DOESN'T normalize the signal to the total energy
first?!?!? YEEP!
The very FIRST thing you do is compute the total signal energy in the
sample period, trivially reject if Etotal < MinETotal, then normalize
all other signal energies to Etotal - that is a basic tenant of DSP.
> standard test procedure with a lot of test cases which are not available
> to mortal humans (audio tapes from Bellcore IIRC)
I think we may have the test cases as WAVs at work, and I think they are
freely distributable - I'll kick a reminder to my work account off to
check later today.
^ permalink raw reply
* Re: observations on 2.5 config screens
From: Dave Jones @ 2003-01-09 12:50 UTC (permalink / raw)
To: Bill Davidsen
Cc: Robert Love, Adrian Bunk, Robert P. J. Day,
Linux kernel mailing list
In-Reply-To: <Pine.LNX.3.96.1030108164157.23971A-100000@gatekeeper.tmr.com>
On Wed, Jan 08, 2003 at 05:49:54PM -0500, Bill Davidsen wrote:
> > No-one other than kernel hackers should be playing with that option,
> > hence it's in the kernel hacking menu.
> Anyone who wants to be able to debug a problem should be playing with
> that
If someone is debugging a kernel, they are by definition, kernel
hacking. They should know where the kernel hacking menu is.
> > SMP isn't a processor option ?
> Clearly not, it's not processor dependent or even architecture dependent
Of course its arch dependant. Some of the archs we support don't do SMP.
See m68k for one. Sure there may be some boards out there with >1 68k
welded to them, but Linux doesn't run on them.
> generally. It's a characteristic of the os, unlike microcode, mtrr, and
> other stuff not on some architectures.
Absolute nonsense. These are _cpu_ features. If you dispute this,
you have no understanding of what you talking about.
> You can select it for 386/486/P5
> (and it works in 2.4 at least, for P5, have several).
And thats perfectly valid. Although I've not seen an MP compliant
386/486 personally, there were patches I beleive at one time for
some of the strange 486 implementations.
It's also a valid thing to do to do for code coverage reasons.
Although I doubt anyones testing SMP builds on a 386/486 any more.
> I would think that processor options would select the processor and any
> options which are specific to it rather than generally supported. Serial
> numbers, firmware loads, that sort of feature.
serial number stuff is done at run time. Firmware loads. Well, you
mentioned above that microcode wasn't a CPU feature, now you change
your mind ?
> Preempt and smp, are general, I guess not supported on every possible
> hardware
Again, more contradiction. Above you said of SMP:
"Clearly not, it's not processor dependent or even architecture dependent"
Now you're saying it is arch dependant.
Which Bill am I arguing with here ?
>From x86 POV, a preemptive SMP 386 kernel should boot.
Its the only way to guarantee that you get both features in a kernel
that will run on anything from 386 up.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* [ANNOUNCE] Kernel Bug Database V1.10 on-line
From: John Bradford @ 2003-01-09 13:11 UTC (permalink / raw)
To: linux-kernel
Version 1.10 of my kernel bug database is now on-line at:
http://grabjohn.com/kernelbugdatabase/
Main updates:
* Automatic account creation
No need to E-Mail a request for an account to me - there is a link to
create one if you don't have one already.
* Generate a config file with the same options as the one that was uploaded
with the bug report.
If the original submitter of a bug uploaded their config file, you can
download a config file with the same options set.
* Patch database
Patches can be submitted against a bug report, along with comments,
and the facility is in place to automatically test the patch to see if
it applies against any number of kernel trees. This will probably not
be enabled until the bug database is moved on to another machine which
has more disk space for the uncompressed kernel trees.
It's also possible to browse the available patches, search for strings
in patches, and download the patches, (obviously).
* Command line interface improvements
Eventually intended to be accessible via E-Mail, you can currently
test the command line interface via the web. I've added commands
related to patch handling.
* Minor enhancements
Various enhancements, including categorising of drop down lists of
kernel versions and config options.
* Various bugfixes
Various bugfixes and minor enhancaments to improve the bug database
overall.
Important note
========= ====
Bugs in the database are not assigned any kind of status, nor are they
assigned to one or more people, for them to work on.
This is intentional - eventually, the best way to use this database
will be like this:
* A user uploads their config file, (or an oops, or searches using
keywords).
* No bugs are found, or only ones that are nothing to do with the bug
the user is experiencing.
* The user submits a bug report
* That bug report is re-named, re-numbered, commented on, or even
deleted if it is a duplicate, by developers, until eventually a
patch is posted that fixes it.
* The original user uploads their config file, again a week later
and gets a list of bug reports back which match certain options in
it, which the developers have identified as causing the bugs.
* That list now includes the bug that the user is experiencing, and
hopefully also includes a patch to fix it.
* The user downloads the patch, and can also get information about
which new kernel versions it can be applied to, and by going back to
the bug list, can also find out which new kernel versions the bug is
actually fixed in.
Note that if a user's original bug report is actually a duplicate of
an existing bug in the database, the bug report can simply be deleted,
(possibly after moving comments, patches, etc, from it to the original
bug).
As long as the original user does not rely on tracking the bug report
by number, and instead searches via config options, (which can be as
easy as uploading the relevant .config file), they should still find
any applicable comments and patches that the developers have
submitted. A list of kernels that any available patches successfully
apply to can easily be downloaded, saving even more time in cases
where a patch is made against one tree, and the user wants to apply it
to another tree, (for example, because of other bugs preventing the
latest kernel version from being usable on their machine).
Comments, flames, etc, welcome.
John.
^ permalink raw reply
* conntrack question
From: Bart @ 2003-01-09 13:04 UTC (permalink / raw)
To: netfilter-devel
Hi,
E.g. if I want to monitor connections to an FTP-server, I would register
a helper
with destination-port set to 21, but this ain't the way it works,
because I saw that
the ftp/irc contrack helpers register a helper with a source port set,
why ?
Tnx,
greetz
^ permalink raw reply
* Re: "Mother" == "computer-illiterate"
From: Miles Bader @ 2003-01-09 13:14 UTC (permalink / raw)
To: Val Henson; +Cc: dpaun, rms, lm, acahalan, linux-kernel
In-Reply-To: <20030109072043.GE26010@boardwalk>
On Thu, Jan 09, 2003 at 12:20:43AM -0700, Val Henson wrote:
> My own mother has installed more distributions of Linux than I've even
> logged into.
Then I suppose you would probably use a different example. Great.
-miles
--
[|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that
will make every christian in the world foamm at the mouth?
[iddt] nurg, that's the goal
^ permalink raw reply
* Re: Linux 2.4.21pre3-ac2
From: Arjan van de Ven @ 2003-01-09 13:15 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Alan Cox, Arjan van de Ven, linux-kernel
In-Reply-To: <20030109121431.GQ6626@fs.tum.de>
On Thu, Jan 09, 2003 at 01:14:32PM +0100, Adrian Bunk wrote:
> On Wed, Jan 08, 2003 at 08:39:09PM -0500, Alan Cox wrote:
> >...
> > Linux 2.4.21pre3-ac1
> >...
> > + IDE Raid support for AMI/SI 'Medley' IDE Raid (Arjan van de Ven)
> >...
>
> This causes a compile error if both pdcraid.o and silraid.o are compiled
> statically into the kernel:
this ought to fix it:
Alan please apply
diff -urN linux-2.4.20/drivers/ide/raid.org/pdcraid.c linux-2.4.20/drivers/ide/raid/pdcraid.c
--- linux-2.4.20/drivers/ide/raid.org/pdcraid.c 2003-01-09 11:03:11.000000000 +0100
+++ linux-2.4.20/drivers/ide/raid/pdcraid.c 2003-01-09 14:09:21.000000000 +0100
@@ -159,48 +159,11 @@
}
-unsigned long partition_map_normal(unsigned long block, unsigned long partition_off, unsigned long partition_size, int stride)
+static unsigned long partition_map_normal(unsigned long block, unsigned long partition_off, unsigned long partition_size, int stride)
{
return block + partition_off;
}
-unsigned long partition_map_linux(unsigned long block, unsigned long partition_off, unsigned long partition_size, int stride)
-{
- unsigned long newblock;
-
- newblock = stride - (partition_off%stride); if (newblock == stride) newblock = 0;
- newblock += block;
- newblock = newblock % partition_size;
- newblock += partition_off;
-
- return newblock;
-}
-
-static int funky_remap[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
-
-unsigned long partition_map_linux_raid0_4disk(unsigned long block, unsigned long partition_off, unsigned long partition_size, int stride)
-{
- unsigned long newblock,temp,temp2;
-
- newblock = stride - (partition_off%stride); if (newblock == stride) newblock = 0;
-
- if (block < (partition_size / (8*stride))*8*stride ) {
- temp = block % stride;
- temp2 = block / stride;
- temp2 = ((temp2>>3)<<3)|(funky_remap[temp2&7]);
- block = temp2*stride+temp;
- }
-
-
- newblock += block;
- newblock = newblock % partition_size;
- newblock += partition_off;
-
- return newblock;
-}
-
-
-
static int pdcraid0_make_request (request_queue_t *q, int rw, struct buffer_head * bh)
{
unsigned long rsect;
diff -urN linux-2.4.20/drivers/ide/raid.org/silraid.c linux-2.4.20/drivers/ide/raid/silraid.c
--- linux-2.4.20/drivers/ide/raid.org/silraid.c 2003-01-09 11:03:31.000000000 +0100
+++ linux-2.4.20/drivers/ide/raid/silraid.c 2003-01-09 14:09:27.000000000 +0100
@@ -157,7 +157,7 @@
}
-unsigned long partition_map_normal(unsigned long block, unsigned long partition_off, unsigned long partition_size, int stride)
+static unsigned long partition_map_normal(unsigned long block, unsigned long partition_off, unsigned long partition_size, int stride)
{
return block + partition_off;
}
^ permalink raw reply
* Fixed proken MARK target in POM.
From: Anders Fugmann @ 2003-01-09 13:07 UTC (permalink / raw)
To: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 833 bytes --]
Hi.
As I require the BIT-operations provided by the MARK target in POM,
attached is a fixed version of this.
The patch extends the MARK target in mangle chains to allow:
# iptables -t mangle -A PRERPUTING -j MARK --set-mark 0x01
# iptables -t mangle -A PRERPUTING -j MARK --and-mark 0x01
# iptables -t mangle -A PRERPUTING -j MARK --or-mark 0x01
The version is widly based on the current one with only minor code
fixes. The kernel patch applies cleanly to 2.4.20 and 2.5.54. The
userspace patch is against 1.2.7a. The patch has been tested on 2.5.54.
The patch maintains backward compability, and I request that this patch
is applied to mainstream (and pushed to the Andrea for kernel
inclusion), as I as a software developer of a firewall cannot ask users
of the software to appliy patches to POM.
Regards
Anders Fugmann
[-- Attachment #2: MARK_TARGET.patch --]
[-- Type: text/plain, Size: 1559 bytes --]
diff -r -u linux-2.4.20/include/linux/netfilter_ipv4/ipt_MARK.h linux-2.4.20-new/include/linux/netfilter_ipv4/ipt_MARK.h
--- linux-2.4.20/include/linux/netfilter_ipv4/ipt_MARK.h 2000-03-17 19:56:20.000000000 +0100
+++ linux-2.4.20-new/include/linux/netfilter_ipv4/ipt_MARK.h 2003-01-09 11:15:06.000000000 +0100
@@ -1,8 +1,15 @@
#ifndef _IPT_MARK_H_target
#define _IPT_MARK_H_target
+enum {
+ IPT_MARK_SET=0,
+ IPT_MARK_AND,
+ IPT_MARK_OR
+};
+
struct ipt_mark_target_info {
unsigned long mark;
+ u_int8_t mode;
};
#endif /*_IPT_MARK_H_target*/
diff -r -u linux-2.4.20/net/ipv4/netfilter/ipt_MARK.c linux-2.4.20-new/net/ipv4/netfilter/ipt_MARK.c
--- linux-2.4.20/net/ipv4/netfilter/ipt_MARK.c 2001-09-30 21:26:08.000000000 +0200
+++ linux-2.4.20-new/net/ipv4/netfilter/ipt_MARK.c 2003-01-09 11:22:53.000000000 +0100
@@ -16,11 +16,31 @@
void *userinfo)
{
const struct ipt_mark_target_info *markinfo = targinfo;
+ int newmark;
+
+ switch (markinfo->mode) {
+ case IPT_MARK_SET:
+ newmark = markinfo->mark;
+ break;
+
+ case IPT_MARK_AND:
+ newmark = (*pskb)->nfmark & markinfo->mark;
+ break;
+
+ case IPT_MARK_OR:
+ newmark = (*pskb)->nfmark | markinfo->mark;
+ break;
+
+ default:
+ newmark = (*pskb)->nfmark;
+ break;
+ }
- if((*pskb)->nfmark != markinfo->mark) {
- (*pskb)->nfmark = markinfo->mark;
- (*pskb)->nfcache |= NFC_ALTERED;
+ if ((*pskb)->nfmark != newmark) {
+ (*pskb)->nfmark = newmark;
+ (*pskb)->nfcache |= NFC_ALTERED;
}
+
return IPT_CONTINUE;
}
[-- Attachment #3: MARK_operations.patch.userspace --]
[-- Type: text/plain, Size: 3546 bytes --]
diff -u -r iptables-1.2.7a/extensions/libipt_MARK.c iptables-1.2.7a-new/extensions/libipt_MARK.c
--- iptables-1.2.7a/extensions/libipt_MARK.c 2002-08-05 16:26:47.000000000 +0200
+++ iptables-1.2.7a-new/extensions/libipt_MARK.c 2003-01-09 13:29:47.000000000 +0100
@@ -20,12 +20,16 @@
printf(
"MARK target v%s options:\n"
" --set-mark value Set nfmark value\n"
+" --and-mark value Binary AND the nfmark with value\n"
+" --or-mark value Binary OR the nfmark with value\n"
"\n",
IPTABLES_VERSION);
}
static struct option opts[] = {
{ "set-mark", 1, 0, '1' },
+ { "and-mark", 1, 0, '2' },
+ { "or-mark", 1, 0, '3' },
{ 0 }
};
@@ -45,17 +49,29 @@
struct ipt_mark_target_info *markinfo
= (struct ipt_mark_target_info *)(*target)->data;
- switch (c) {
- case '1':
- if (string_to_number(optarg, 0, 0xffffffff,
+ /* Do generic stuff */
+ if (c=='1' || c=='2' || c=='3') {
+ if (string_to_number(optarg, 0, 0xffffffff,
(unsigned int *)&markinfo->mark))
- exit_error(PARAMETER_PROBLEM, "Bad MARK value `%s'", optarg);
+ exit_error(PARAMETER_PROBLEM, "Bad MARK value `%s'", optarg);
+
if (*flags)
- exit_error(PARAMETER_PROBLEM,
- "MARK target: Can't specify --set-mark twice");
+ exit_error(PARAMETER_PROBLEM,
+ "MARK target: Can't specify --set-mark twice");
*flags = 1;
- break;
+ }
+
+ switch (c) {
+ case '1':
+ markinfo->mode = IPT_MARK_SET;
+ break;
+ case '2':
+ markinfo->mode = IPT_MARK_AND;
+ break;
+ case '3':
+ markinfo->mode = IPT_MARK_OR;
+ break;
default:
return 0;
}
@@ -68,7 +84,7 @@
{
if (!flags)
exit_error(PARAMETER_PROBLEM,
- "MARK target: Parameter --set-mark is required");
+ "MARK target: Additional parameter required");
}
static void
@@ -85,7 +101,17 @@
{
const struct ipt_mark_target_info *markinfo =
(const struct ipt_mark_target_info *)target->data;
- printf("MARK set ");
+ switch (markinfo->mode) {
+ case IPT_MARK_SET:
+ printf("MARK set ");
+ break;
+ case IPT_MARK_AND:
+ printf("MARK and ");
+ break;
+ case IPT_MARK_OR:
+ printf("MARK or ");
+ break;
+ }
print_mark(markinfo->mark, numeric);
}
@@ -95,8 +121,19 @@
{
const struct ipt_mark_target_info *markinfo =
(const struct ipt_mark_target_info *)target->data;
+ switch (markinfo->mode) {
+ case IPT_MARK_SET:
+ printf("--set-mark");
+ break;
+ case IPT_MARK_AND:
+ printf("--and-mark");
+ break;
+ case IPT_MARK_OR:
+ printf("--or-mark");
+ break;
+ }
- printf("--set-mark 0x%lx ", markinfo->mark);
+ printf(" 0x%lx ", markinfo->mark);
}
static
diff -u -r iptables-1.2.7a/iptables.8 iptables-1.2.7a-new/iptables.8
--- iptables-1.2.7a/iptables.8 2002-08-07 11:37:40.000000000 +0200
+++ iptables-1.2.7a-new/iptables.8 2003-01-09 12:25:13.000000000 +0100
@@ -690,6 +690,20 @@
table. It can for example be used in conjunction with iproute2.
.TP
.BI "--set-mark " "mark"
+Sets the marking of the packet to
+.I mark
+regardless of the current mark value of the packet.
+.TP
+.BI "--and-mark " "mark"
+Binary AND the current mark value of the packet with the supplied
+.I mark
+value.
+.TP
+.BI "--or-mark " "mark"
+Binary OR the current mark value of the packet with the supplied
+.I mark
+value.
+
.SS REJECT
This is used to send back an error packet in response to the matched
packet: otherwise it is equivalent to
^ permalink raw reply
* Re: [ANNOUNCE] Kernel Bug Database V1.10 on-line
From: Ingo Molnar @ 2003-01-09 13:22 UTC (permalink / raw)
To: John Bradford; +Cc: linux-kernel
In-Reply-To: <200301091311.h09DB4Ka001126@darkstar.example.net>
any reason why it has forced registration with a forced email address?
Makes it hard to just browse the bugs.
Ingo
^ permalink raw reply
* Re: oops while vmware-config.pl with kernel 2.4.21-pre2
From: Petr Vandrovec @ 2003-01-09 13:23 UTC (permalink / raw)
To: Tupshin Harper; +Cc: linux-kernel
On 8 Jan 03 at 22:04, Tupshin Harper wrote:
> I'm going to forward this to the vmware folks, but there's a decent
> chance they are not totally to blame:
> Jan 8 21:40:41 fussbudget kernel: EIP: 0010:[skb_clone+407/448]
> Trace; e4f287e3 <[vmnet]VNetHubReceive+57/a7>
Can you try to update your vmware with
ftp://platan.vc.cvut.cz/pub/vmware/vmware-any-any-update24.tar.gz ?
But I do not think that it will fix your problem. I'm not able to
find how it could happen, except if skb with NULL skb->end (and though
NULL skb_shinfo()) was passed to the callback registered by dev_add_pack()...
But it should not happen...
Thanks,
Petr Vandrovec
vandrove@vc.cvut.cz
^ permalink raw reply
* Re: Linux 2.4.21pre3-ac2
From: Adrian Bunk @ 2003-01-09 13:27 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Alan Cox, linux-kernel
In-Reply-To: <20030109131510.A25566@devserv.devel.redhat.com>
On Thu, Jan 09, 2003 at 01:15:10PM +0000, Arjan van de Ven wrote:
>
> this ought to fix it:
>...
Yes, thanks, I can confirm that this patch fixes the compilation
problem.
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
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.