* Re: iproute2: git pull request from debian repo.
From: Patrick McHardy @ 2007-10-21 17:48 UTC (permalink / raw)
To: Andreas Henriksson; +Cc: maximilian attems, shemminger, netdev
In-Reply-To: <20071019144815.GB30444@scream.fatal.se>
Andreas Henriksson wrote:
> - for (;;) {
> + while (round < MAX_ROUNDS) {
> if (rtnl_wilddump_request(&rth, filter.family, RTM_GETADDR) < 0) {
> perror("Cannot send dump request");
> exit(1);
> @@ -694,6 +696,8 @@ int ipaddr_list_or_flush(int argc, char **argv, int flush)
> fflush(stdout);
> }
> }
> + fprintf(stderr, "*** Flush remains incomplete after %d rounds. ***\n", MAX_ROUNDS); fflush(stderr);
Again, please make this optional. People might want to make
sure the cache is flushed even if it takes a bit longer.
^ permalink raw reply
* how to set pppoe source mac address?
From: Joakim Tjernlund @ 2007-10-21 13:33 UTC (permalink / raw)
To: netdev
I have several pppoe i/f's over one eth i/f and I want to set the
source mac address used by each pppoe i/f to a unique mac address from
user space.
Is this possible? If so, how do I do that?
Jocke
^ permalink raw reply
* Re: PROBLEM: oops, Linus tree: 2.6.23-g4fa4d23f, BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
From: Guillaume Chazarain @ 2007-10-21 10:17 UTC (permalink / raw)
To: Coly Li; +Cc: Jiri Kosina, Dave Haywood, linux-kernel, netdev, Pavel Emelyanov
In-Reply-To: <471AE0B0.4060600@suse.de>
Le Sun, 21 Oct 2007 13:16:32 +0800,
Coly Li <coyli@suse.de> a écrit :
> > This should be fixed in recent git by
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9b013e05e0289c190a53d78ca029e2f21c0e4485
> >
> Maybe we encounter same condition, at least the symbol name is same -- sock_setsockopt.
> [ 4327.550291] EFLAGS: 00010282 (2.6.23-bigsmp-g4fa4d23f #6)
You are testing a kernel that does not contain the aforementioned fix,
so you should update your git checkout (using a kernel that can connect
to the Internet ;-) ) and test the new kernel.
Thanks.
--
Guillaume
^ permalink raw reply
* RE: [PATCH] Fix ethernet multicast for ucc_geth.
From: Joakim Tjernlund @ 2007-10-21 9:45 UTC (permalink / raw)
To: 'Li Yang-r58472', 'Netdev', linuxppc-dev
In-Reply-To: <989B956029373F45A0B8AF0297081890019B5BD2@zch01exm26.fsl.freescale.net>
> -----Original Message-----
> From: Li Yang-r58472 [mailto:LeoLi@freescale.com]
> Sent: den 18 oktober 2007 16:24
> To: joakim.tjernlund@transmode.se; Netdev; linuxppc-dev@ozlabs.org
> Subject: RE: [PATCH] Fix ethernet multicast for ucc_geth.
>
> > -----Original Message-----
> > From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> > Sent: Wednesday, October 17, 2007 5:06 PM
> > To: Netdev; Li Yang-r58472
> > Subject: [PATCH] Fix ethernet multicast for ucc_geth.
> >
> > >From 5761a9e5924b34615c748fba2dcb977ed04c1243 Mon Sep 17
> > 00:00:00 2001
> > From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> > Date: Wed, 17 Oct 2007 11:01:44 +0200
> > Subject: [PATCH] Fix ethernet multicast for ucc_geth.
> > hw_add_addr_in_hash() already swaps byte order, don't do it
> > in ucc_geth_set_multi() too.
> >
> >
> > Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
>
> Acked-by: Li Yang <leoli@freescale.com>
>
Ping? Did this make into a someones tree?
Jocke
^ permalink raw reply
* Re: net: alignment problem in icmp code
From: Pierre Ossman @ 2007-10-21 9:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20071020.221257.78359286.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]
On Sat, 20 Oct 2007 22:12:57 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Pierre Ossman <drzeus@drzeus.cx>
> Date: Sat, 20 Oct 2007 23:35:40 +0200
>
> > Structure assignment have to be aligned just like any assignment, and the skb could point to anything. So take the safe route and use a memcpy().
> >
> > Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
>
> Unfortunately this doesn't work, GCC can inline the memcpy just like
> the assignment.
>
> I tried to use a similar trick in the net/xfrm/xfrm_user.c code
> but in the end it doesn't work at all.
Inlining isn't the problem, but the defined semantics of assignment versus memcpy(). memcpy() must work on any region of memory, whilst assignment must only work on a properly aligned object. Since icmphdr contains a u32, the compiler "knows" the object will always be 32-bit aligned and generates assembly based on this assumption. Of course this is incorrect if the lower layers didn't have a multiple of 4 bytes of headers.
Anyway, I discovered the hard way that there are lots and lots of places in the IP code that assumes alignment, so this seems to be a rather daunting task to fix. So this patch will just be one very small piece of the puzzle. :/
(Perhaps something for kernel newbies, to track down and fix all the alignment assumptions in the IP stack?)
Rgds
Pierre
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [ofa-general] Re: [ewg] [PATCH 0/14 v2] nes: NetEffect 10Gb RNIC Driver
From: Tziporet Koren @ 2007-10-21 8:22 UTC (permalink / raw)
To: ggrundstrom; +Cc: netdev, rdreier, ewg, general
In-Reply-To: <200710191957.l9JJvAgC021662@neteffect.com>
ggrundstrom@neteffect.com wrote:
> This is the second posting for the series of patches containing the source code
> for the NetEffect 10Gb RNIC adapter. The driver is split into two components - a
> kernel driver module and a userspace library.
>
> The code can also be found in the following git trees.
>
> git.openfabrics.org/~glenn/libnes.git
> git.openfabrics.org/~glenn/linux-2.6.git
>
> Thanks,
> Glenn.
>
Can you review the release notes of OFED 1.3 and send me update
regarding name of cards you support or anything that should be documented
Thanks,
Tziporet
^ permalink raw reply
* [PATCH 13/17] netdrvr irq handler cleanups
From: Jeff Garzik @ 2007-10-21 7:52 UTC (permalink / raw)
To: LKML; +Cc: netdev
In-Reply-To: <lkjvxcz09835mnsdfv0983q4m1234m@havoc.gtf.org>
commit a9f06dc9fb3caea2c4e9b387974c9f4956434e28
Author: Jeff Garzik <jeff@garzik.org>
Date: Fri Oct 19 19:33:31 2007 -0400
[netdrvr] driver irq handler cleanups
* no need to use 'irq' function arg, its already stored in a data struct
* whitespace cleanups
* delete tests for impossible conditions
* remove pointless casts from void*
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
drivers/net/eexpress.c | 11 ++++++-----
drivers/net/irda/smsc-ircc2.c | 17 ++++-------------
drivers/net/irda/via-ircc.c | 12 +++---------
drivers/net/pcmcia/fmvj18x_cs.c | 7 +------
drivers/net/wan/sdla.c | 5 +++--
5 files changed, 17 insertions(+), 35 deletions(-)
a9f06dc9fb3caea2c4e9b387974c9f4956434e28
diff --git a/drivers/net/eexpress.c b/drivers/net/eexpress.c
index 9c85e50..007de3b 100644
--- a/drivers/net/eexpress.c
+++ b/drivers/net/eexpress.c
@@ -456,8 +456,9 @@ static int eexp_open(struct net_device *dev)
if (!dev->irq || !irqrmap[dev->irq])
return -ENXIO;
- ret = request_irq(dev->irq,&eexp_irq,0,dev->name,dev);
- if (ret) return ret;
+ ret = request_irq(dev->irq, &eexp_irq, 0, dev->name, dev);
+ if (ret)
+ return ret;
if (!request_region(ioaddr, EEXP_IO_EXTENT, "EtherExpress")) {
printk(KERN_WARNING "EtherExpress io port %x, is busy.\n"
@@ -768,7 +769,7 @@ static void eexp_cmd_clear(struct net_device *dev)
}
}
-static irqreturn_t eexp_irq(int irq, void *dev_info)
+static irqreturn_t eexp_irq(int dummy, void *dev_info)
{
struct net_device *dev = dev_info;
struct net_local *lp;
@@ -783,7 +784,7 @@ static irqreturn_t eexp_irq(int irq, void *dev_info)
old_read_ptr = inw(ioaddr+READ_PTR);
old_write_ptr = inw(ioaddr+WRITE_PTR);
- outb(SIRQ_dis|irqrmap[irq],ioaddr+SET_IRQ);
+ outb(SIRQ_dis|irqrmap[dev->irq],ioaddr+SET_IRQ);
status = scb_status(dev);
@@ -851,7 +852,7 @@ static irqreturn_t eexp_irq(int irq, void *dev_info)
eexp_cmd_clear(dev);
- outb(SIRQ_en|irqrmap[irq],ioaddr+SET_IRQ);
+ outb(SIRQ_en|irqrmap[dev->irq],ioaddr+SET_IRQ);
#if NET_DEBUG > 6
printk("%s: leaving eexp_irq()\n", dev->name);
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index 7e7b582..1f26da7 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -1505,22 +1505,13 @@ static void smsc_ircc_sir_receive(struct smsc_ircc_cb *self)
* An interrupt from the chip has arrived. Time to do some work
*
*/
-static irqreturn_t smsc_ircc_interrupt(int irq, void *dev_id)
+static irqreturn_t smsc_ircc_interrupt(int dummy, void *dev_id)
{
- struct net_device *dev = (struct net_device *) dev_id;
- struct smsc_ircc_cb *self;
+ struct net_device *dev = dev_id;
+ struct smsc_ircc_cb *self = netdev_priv(dev);
int iobase, iir, lcra, lsr;
irqreturn_t ret = IRQ_NONE;
- if (dev == NULL) {
- printk(KERN_WARNING "%s: irq %d for unknown device.\n",
- driver_name, irq);
- goto irq_ret;
- }
-
- self = netdev_priv(dev);
- IRDA_ASSERT(self != NULL, return IRQ_NONE;);
-
/* Serialise the interrupt handler in various CPUs, stop Tx path */
spin_lock(&self->lock);
@@ -1565,7 +1556,7 @@ static irqreturn_t smsc_ircc_interrupt(int irq, void *dev_id)
irq_ret_unlock:
spin_unlock(&self->lock);
- irq_ret:
+
return ret;
}
diff --git a/drivers/net/irda/via-ircc.c b/drivers/net/irda/via-ircc.c
index 126ec7c..58e1287 100644
--- a/drivers/net/irda/via-ircc.c
+++ b/drivers/net/irda/via-ircc.c
@@ -1346,19 +1346,13 @@ static int RxTimerHandler(struct via_ircc_cb *self, int iobase)
* An interrupt from the chip has arrived. Time to do some work
*
*/
-static irqreturn_t via_ircc_interrupt(int irq, void *dev_id)
+static irqreturn_t via_ircc_interrupt(int dummy, void *dev_id)
{
- struct net_device *dev = (struct net_device *) dev_id;
- struct via_ircc_cb *self;
+ struct net_device *dev = dev_id;
+ struct via_ircc_cb *self = dev->priv;
int iobase;
u8 iHostIntType, iRxIntType, iTxIntType;
- if (!dev) {
- IRDA_WARNING("%s: irq %d for unknown device.\n", driver_name,
- irq);
- return IRQ_NONE;
- }
- self = (struct via_ircc_cb *) dev->priv;
iobase = self->io.fir_base;
spin_lock(&self->lock);
iHostIntType = GetHostStatus(iobase);
diff --git a/drivers/net/pcmcia/fmvj18x_cs.c b/drivers/net/pcmcia/fmvj18x_cs.c
index 6284467..d251bd1 100644
--- a/drivers/net/pcmcia/fmvj18x_cs.c
+++ b/drivers/net/pcmcia/fmvj18x_cs.c
@@ -731,18 +731,13 @@ module_exit(exit_fmvj18x_cs);
/*====================================================================*/
-static irqreturn_t fjn_interrupt(int irq, void *dev_id)
+static irqreturn_t fjn_interrupt(int dummy, void *dev_id)
{
struct net_device *dev = dev_id;
local_info_t *lp = netdev_priv(dev);
kio_addr_t ioaddr;
unsigned short tx_stat, rx_stat;
- if (lp == NULL) {
- printk(KERN_NOTICE "fjn_interrupt(): irq %d for "
- "unknown device.\n", irq);
- return IRQ_NONE;
- }
ioaddr = dev->base_addr;
/* avoid multiple interrupts */
diff --git a/drivers/net/wan/sdla.c b/drivers/net/wan/sdla.c
index 05df0a3..73e2f27 100644
--- a/drivers/net/wan/sdla.c
+++ b/drivers/net/wan/sdla.c
@@ -867,7 +867,7 @@ static void sdla_receive(struct net_device *dev)
spin_unlock_irqrestore(&sdla_lock, flags);
}
-static irqreturn_t sdla_isr(int irq, void *dev_id)
+static irqreturn_t sdla_isr(int dummy, void *dev_id)
{
struct net_device *dev;
struct frad_local *flp;
@@ -879,7 +879,8 @@ static irqreturn_t sdla_isr(int irq, void *dev_id)
if (!flp->initialized)
{
- printk(KERN_WARNING "%s: irq %d for uninitialized device.\n", dev->name, irq);
+ printk(KERN_WARNING "%s: irq %d for uninitialized device.\n",
+ dev->name, dev->irq);
return IRQ_NONE;
}
^ permalink raw reply related
* Re: PROBLEM: oops, Linus tree: 2.6.23-g4fa4d23f, BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
From: Coly Li @ 2007-10-21 5:16 UTC (permalink / raw)
To: Guillaume Chazarain
Cc: Jiri Kosina, Dave Haywood, linux-kernel, netdev, Pavel Emelyanov
In-Reply-To: <3d8471ca0710200432h3607b0a0i9169884ebec3b940@mail.gmail.com>
Guillaume Chazarain wrote:
>>> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
>
> This should be fixed in recent git by
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9b013e05e0289c190a53d78ca029e2f21c0e4485
>
Maybe we encounter same condition, at least the symbol name is same -- sock_setsockopt.
This happens in kernel bootup and makes network can not work properly -- I can not connect to
internet the whole weekend. Same as you, I am not a network guy, I tried to understand what
happened, but it seems not so easy for me ^_^.
Here is the oops message:
[ 4327.550035] BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
[ 4327.550047] printing eip: c02ad991 *pdpt = 0000000006062001 <1>*pde = 0000000000000000
[ 4327.550061] Oops: 0000 [#1] SMP
[ 4327.550071] Modules linked in: arc4 ieee80211_crypt_wep af_packet ip6t_LOG nf_conntrack_ipv6
xt_pkttype ipt_LOG xt_limit deflate zlib_deflate twofish twofish_common camellia serpent blowfish
des_generic cbc ecb geode_aes blkcipher aes_i586 aes_generic xcbc sha256_generic sha1_generic
crypto_null af_key snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device microcode ip6t_REJECT xt_tcpudp
ipt_REJECT xt_state iptable_mangle iptable_nat nf_nat iptable_filter ip6table_mangle
nf_conntrack_ipv4 nf_conntrack ip_tables ip6table_filter ip6_tables x_tables ipv6
cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq speedstep_lib loop dm_mod
pcmcia nsc_ircc parport_pc irda parport ipw2200 rtc_cmos ieee80211 yenta_socket rsrc_nonstatic
crc_ccitt pcmcia_core thinkpad_acpi hwmon nvram rtc_core ieee80211_crypt firmware_class snd_intel8x0
sdhci rtc_lib battery snd_intel8x0m snd_ac97_codec ac97_bus output ac mmc_core snd_pcm snd_timer snd
soundcore sr_mod i2c_i801 i2c_core iTCO_wdt button snd_page_alloc iTCO_vendor_support cdrom
intel_agp agpgart tg3 uinput sg ehci_hcd uhci_hcd sd_mod usbcore edd ext3 mbcache jbd fan ata_piix
ahci libata scsi_mod thermal processor
[ 4327.550286] CPU: 0
[ 4327.550288] EIP: 0060:[<c02ad991>] Not tainted VLI
[ 4327.550291] EFLAGS: 00010282 (2.6.23-bigsmp-g4fa4d23f #6)
[ 4327.550305] EIP is at sk_filter_delayed_uncharge+0x1/0x23
[ 4327.550312] eax: c614f738 ebx: 00000000 ecx: 00000003 edx: 00000000
[ 4327.550319] esi: c60d97b0 edi: c614f738 ebp: c61e2ef8 esp: c61e2ec8
[ 4327.550326] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
[ 4327.550333] Process dhclient (pid: 7024, ti=c61e2000 task=c61e5120 task.ti=c61e2000)
[ 4327.550338] Stack: c61e2ef8 c02adb57 00000002 00000001 c02adaff 00000068 c60d97c0 00000058
[ 4327.550356] 00000000 c614f738 c61e2f24 c65c63f0 c61e2f48 c029c87f c61e2fb0 c030642f
[ 4327.550374] 00000001 00000246 0000001a 8005000b fffffff2 8005000b c03042ae 8005000b
[ 4327.550391] Call Trace:
[ 4327.550396] [<c010680b>] show_trace_log_lvl+0x1a/0x2f
[ 4327.550409] [<c01068bb>] show_stack_log_lvl+0x9b/0xa3
[ 4327.550419] [<c0106a7b>] show_registers+0x1b8/0x28a
[ 4327.550429] [<c0106c58>] die+0x10b/0x1ee
[ 4327.550438] [<c030679a>] do_page_fault+0x7d4/0x8b9
[ 4327.550449] [<c0304b72>] error_code+0x72/0x80
[ 4327.550458] [<c029c87f>] sock_setsockopt+0x46f/0x4c2
[ 4327.550469] [<c029952a>] sys_setsockopt+0x5a/0x90
[ 4327.550478] [<c029abba>] sys_socketcall+0x1e8/0x241
[ 4327.550486] [<c0105112>] syscall_call+0x7/0xb
[ 4327.550495] =======================
[ 4327.550499] Code: 43 4e 39 d3 0f 8c 36 fe ff ff 0f b7 44 d1 f8 83 e0 07 83 f8 06 0f 94 c0 0f b6
c0 48 83 e0 ea eb 05 b8 ea ff ff ff 5b 5e 5d c3 55 <8b> 4a 04 89 e5 8d 0c cd 10 00 00 00 90 29 88 cc
00 00 00 8d 42
[ 4327.550590] EIP: [<c02ad991>] sk_filter_delayed_uncharge+0x1/0x23 SS:ESP 0068:c61e2ec8
> HTH.
>
^ permalink raw reply
* Re: net: alignment problem in icmp code
From: David Miller @ 2007-10-21 5:12 UTC (permalink / raw)
To: drzeus; +Cc: netdev
In-Reply-To: <20071020233540.43d2f103@poseidon.drzeus.cx>
From: Pierre Ossman <drzeus@drzeus.cx>
Date: Sat, 20 Oct 2007 23:35:40 +0200
> Structure assignment have to be aligned just like any assignment, and the skb could point to anything. So take the safe route and use a memcpy().
>
> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Unfortunately this doesn't work, GCC can inline the memcpy just like
the assignment.
I tried to use a similar trick in the net/xfrm/xfrm_user.c code
but in the end it doesn't work at all.
^ permalink raw reply
* Re: Fw: [Bug 9189] New: Oops in kernel 2.6.21-rc4 through 2.6.23, page allocation failure
From: Herbert Xu @ 2007-10-21 4:56 UTC (permalink / raw)
To: John Heffner; +Cc: shemminger, davem, netdev, bugme-daemon
In-Reply-To: <E1IiuGl-000482-00@gondolin.me.apana.org.au>
On Sat, Oct 20, 2007 at 12:00:15AM +0800, Herbert Xu wrote:
> >>
> >> Backtrace #1:
> >> page allocation failure. order:1, mode:0x20
> >> [<c0131581>] __alloc_pages+0x2e1/0x300
> >> [<c0144bee>] cache_alloc_refill+0x29e/0x4b0
> >> [<c0144e6e>] __kmalloc+0x6e/0x80
> >> [<c0227103>] __alloc_skb+0x53/0x110
> >> [<c024de5c>] tcp_collapse+0x1ac/0x370
> >> [<c024e11d>] tcp_prune_queue+0xfd/0x2c0
> >> [<c024eaad>] tcp_data_queue+0x7cd/0xbb0
> >> [<c0225c2d>] skb_checksum+0x4d/0x2a0
> >> [<c02504ee>] tcp_rcv_established+0x36e/0x6a0
> >> [<c02561e4>] tcp_v4_do_rcv+0xb4/0x2a0
> >> [<c0131379>] __alloc_pages+0xd9/0x300
> >> [<c0258269>] tcp_v4_rcv+0x6a9/0x6c0
> >> [<c023ddb1>] ip_local_deliver+0x91/0x110
> >> [<c023e130>] ip_rcv+0x230/0x3c0
> >> [<c0227103>] __alloc_skb+0x53/0x110
> >> [<c022b742>] netif_receive_skb+0x152/0x1e0
> >> [<c022ce6f>] process_backlog+0x6f/0xe0
> >> [<c022cf3c>] net_rx_action+0x5c/0xf0
> >> [<c0115af2>] __do_softirq+0x42/0x90
> >> [<c0115b67>] do_softirq+0x27/0x30
> >> [<c01044fd>] do_IRQ+0x3d/0x70
> >> [<c0115818>] sys_gettimeofday+0x28/0x80
> >> [<c0102967>] common_interrupt+0x23/0x28
> >> =======================
I knew this looked familiar. In fact I'd already sent a patch
to fix this back in June 2006 but it seems to have been lost.
Here it is again rediffed against today's kernel:
[NET]: Fix SKB_WITH_OVERHEAD calculation
The calculation in SKB_WITH_OVERHEAD is incorrect in that it can cause
an overflow across a page boundary which is what it's meant to prevent.
In particular, the header length (X) should not be lumped together with
skb_shared_info. The latter needs to be aligned properly while the header
has no choice but to sit in front of wherever the payload is.
Therefore the correct calculation is to take away the aligned size of
skb_shared_info, and then subtract the header length. The resulting
quantity L satisfies the following inequality:
SKB_DATA_ALIGN(L + X) + sizeof(struct skb_shared_info) <= PAGE_SIZE
This is the quantity used by alloc_skb to do the actual allocation.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index f93f22b..369f60a 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -41,8 +41,7 @@
#define SKB_DATA_ALIGN(X) (((X) + (SMP_CACHE_BYTES - 1)) & \
~(SMP_CACHE_BYTES - 1))
#define SKB_WITH_OVERHEAD(X) \
- (((X) - sizeof(struct skb_shared_info)) & \
- ~(SMP_CACHE_BYTES - 1))
+ ((X) - SKB_DATA_ALIGN(sizeof(struct skb_shared_info)))
#define SKB_MAX_ORDER(X, ORDER) \
SKB_WITH_OVERHEAD((PAGE_SIZE << (ORDER)) - (X))
#define SKB_MAX_HEAD(X) (SKB_MAX_ORDER((X), 0))
^ permalink raw reply related
* Re: [RFD] iptables: mangle table obsoletes filter table
From: Valdis.Kletnieks @ 2007-10-21 4:53 UTC (permalink / raw)
To: Al Boldi
Cc: Bill Davidsen, Patrick McHardy, netfilter-devel, netdev,
linux-net, linux-kernel
In-Reply-To: <200710210731.58959.a1426z@gawab.com>
[-- Attachment #1: Type: text/plain, Size: 723 bytes --]
On Sun, 21 Oct 2007 07:31:58 +0300, Al Boldi said:
> > Well, for example to stop any transient packets being forwarded. You could
> > probably hack around this using mark's, but you can't stop the implied
> > route lookup, unless you stop it in prerouting.
>
> Basically, you have one big unintended gaping whole in your firewall, that
> could easily be exploited for DoS attacks at the least, unless you put in
> specific rules to limit this.
OK, the light bulb just went on... ;)
We actually *do* have an issue with the flip side of that - it's a frikking
pain to make packets that show up on eth0 with a destination of 127.0.0.1
go away un-noticed - or at least I'm assuming it's the flip side of the same
issue.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [RFD] iptables: mangle table obsoletes filter table
From: Al Boldi @ 2007-10-21 4:31 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Bill Davidsen, Patrick McHardy, netfilter-devel, netdev,
linux-net, linux-kernel
In-Reply-To: <26556.1192855654@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu wrote:
> On Sat, 20 Oct 2007 06:40:02 +0300, Al Boldi said:
> > Sure, the idea was to mark the filter table obsolete as to make people
> > start using the mangle table to do their filtering for new setups. The
> > filter table would then still be available for legacy/special setups.
> > But this would only be possible if we at least ported the REJECT target
> > to mangle.
>
> That's *half* the battle. The other half is explaining why I should move
> from a perfectly functional setup that uses the filter table. What gains
> do I get from doing so? What isn't working that I don't know about? etc?
>
> In other words - why do I want to move from filter to mangle?
This has already been explained in this thread; here it is again:
Al Boldi wrote:
>>>The problem is that people think they are safe with the filter table,
>>>when in fact they need the prerouting chain to seal things. Right now
>>>this is only possible in the mangle table.
>>
>>Why do they need PREROUTING?
>
> Well, for example to stop any transient packets being forwarded. You could
> probably hack around this using mark's, but you can't stop the implied
> route lookup, unless you stop it in prerouting.
Basically, you have one big unintended gaping whole in your firewall, that
could easily be exploited for DoS attacks at the least, unless you put in
specific rules to limit this.
Plus, it's outrageously incorrect to accept invalid packets, just because
your filtering infrastructure can only reject packets after they have been
prerouted.
Thanks!
--
Al
^ permalink raw reply
* net: alignment problem in icmp code
From: Pierre Ossman @ 2007-10-20 21:35 UTC (permalink / raw)
To: davem, netdev
[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]
Structure assignment have to be aligned just like any assignment, and the skb could point to anything. So take the safe route and use a memcpy().
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
---
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 272c69e..a7e2ec9 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -783,7 +783,7 @@ static void icmp_echo(struct sk_buff *skb)
if (!sysctl_icmp_echo_ignore_all) {
struct icmp_bxm icmp_param;
- icmp_param.data.icmph = *icmp_hdr(skb);
+ memcpy(&icmp_param.data.icmph, icmp_hdr(skb), sizeof(struct icmphdr));
icmp_param.data.icmph.type = ICMP_ECHOREPLY;
icmp_param.skb = skb;
icmp_param.offset = 0;
@@ -819,7 +819,7 @@ static void icmp_timestamp(struct sk_buff *skb)
icmp_param.data.times[2] = icmp_param.data.times[1];
if (skb_copy_bits(skb, 0, &icmp_param.data.times[0], 4))
BUG();
- icmp_param.data.icmph = *icmp_hdr(skb);
+ memcpy(&icmp_param.data.icmph, icmp_hdr(skb), sizeof(struct icmphdr));
icmp_param.data.icmph.type = ICMP_TIMESTAMPREPLY;
icmp_param.data.icmph.code = 0;
icmp_param.skb = skb;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: Bluetooth patches for 2.6.24
From: Marcel Holtmann @ 2007-10-20 20:01 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
In-Reply-To: <1192888816.6184.117.camel@violet>
Hi Dave,
> these are the Bluetooth patches for the 2.6.24 kernel release. Please
> pull and send them to Linus.
one of the cleanup patches slipped through the net. If you already
pulled my tree, then please re-pull. I pushed it on top of it.
Regards
Marcel
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git
This will update the following files:
net/bluetooth/rfcomm/core.c | 60 +++++++++++++++-----------------------------
1 file changed, 21 insertions(+), 39 deletions(-)
through these ChangeSets:
Commit: 58876e6a3dac244ca8d61f3b9750a3fb63875eff
Author: Marcel Holtmann <marcel@holtmann.org> Sat, 20 Oct 2007 21:37:20 +0200
[Bluetooth] Convert RFCOMM to use kthread API
This patch does the full kthread conversion for the RFCOMM protocol. It
makes the code slightly simpler and more maintainable.
Based on a patch from Christoph Hellwig <hch@lst.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
^ permalink raw reply
* Re: ISNs and 2.6.22, Was: Re: haproxy & linux firewall (netfilter)
From: Willy Tarreau @ 2007-10-20 21:52 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: haproxy, netdev
In-Reply-To: <Pine.LNX.4.64.0710201921000.19637@bizon.gios.gov.pl>
On Sat, Oct 20, 2007 at 07:23:25PM +0200, Krzysztof Oledzki wrote:
(...)
> >So it seems that ISNs are not randomly incremented but rather randomly
> >generated. Adding netdev@vger.kernel.org to the CC list.
>
> Eh, I was little to hurry this time. There were not randomly generated but
> incremented with to big value. This patch fixes my problem:
>
> http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob;f=queue-2.6.22/fix-tcp-initial-sequence-number-selection.patch;h=05b9167d68ecde1e6088f58c55e2906b768420ed;hb=HEAD
Good catch Krzysztof ! I've already noticed that one on LKML but did not
make the connection with your problem!
Please also tell Jozsef so that if he gets other reports, he knows where
to point the reporters.
Regards,
Willy
^ permalink raw reply
* Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Michael Chan @ 2007-10-20 22:50 UTC (permalink / raw)
To: michael; +Cc: netdev, mcarlson, linuxppc-dev, linux-pci, David Miller
In-Reply-To: <1192862606.7688.4.camel@concordia>
On Sat, 2007-10-20 at 16:43 +1000, Michael Ellerman wrote:
> On Fri, 2007-10-19 at 17:53 -0700, David Miller wrote:
> > I don't see this, in all cases write_msi_msg() will transfer
> > the given "*msg" to entry->msg by this assignment in
> > drivers/pci/msi.c:
> >
> > void write_msi_msg(unsigned int irq, struct msi_msg *msg)
> > {
> > ...
> > entry->msg = *msg;
> > }
> >
> > So as long as write_msi_msg() is invoked, it will be saved
> > properly.
> >
> > Platforms need not do this explicitly.
>
> I'm short on context here, and it's Saturday, so excuse me if I'm
> missing the point somewhere.
>
> On pseries machines we don't call write_msi_msg(), because we don't
> control the contents of the message, firmware does. So entry->msg will
> be bogus.
>
> That's a pity, but AFAIK it shouldn't be a problem because we don't
> enable CONFIG_PM on those machines anyway. If we ever want to we'll need
> to sort out with firmware how that will work WRT restoring MSI state.
>
The PCI error recovery that Linas is working on requires the MSI state
to be restored after we do PCI reset to recover from PCI errors.
^ permalink raw reply
* [PATCH v2] niu: Cleanup PAGE_SIZE checks a bit
From: Olof Johansson @ 2007-10-20 19:33 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20071020190649.GA30034@lixom.net>
Hi Dave,
I get the following warning from a powerpc allyesconfig of current
mainline:
drivers/net/niu.c: In function 'niu_size_rbr':
drivers/net/niu.c:3113: warning: large integer implicitly truncated to unsigned type
PAGE_SIZE in this case is 64KB, so I don't quite get why gcc can't tell
that the line in question will never be reached.
I suggest the following instead, but I can unfortunately not do anything but
build test it.
Also, the driver does some other checks to make sure that PAGE_SIZE is a
power of two (BUILD_BUG_ON() in niu_init()), doesn't seem like that could
ever be untrue? Or are there really archs with non-power-of-two PAGE_SIZE?
Signed-off-by: Olof Johansson <olof@lixom.net>
--
Ack! It should obviously use min(), not max()!
-Olof
diff --git a/drivers/net/niu.c b/drivers/net/niu.c
index ed1f9bb..795cc68 100644
--- a/drivers/net/niu.c
+++ b/drivers/net/niu.c
@@ -3103,31 +3103,12 @@ static int niu_alloc_tx_ring_info(struct niu *np,
static void niu_size_rbr(struct niu *np, struct rx_ring_info *rp)
{
- u16 bs;
+ u16 bss;
- switch (PAGE_SIZE) {
- case 4 * 1024:
- case 8 * 1024:
- case 16 * 1024:
- case 32 * 1024:
- rp->rbr_block_size = PAGE_SIZE;
- rp->rbr_blocks_per_page = 1;
- break;
+ bss = min(PAGE_SHIFT, 15);
- default:
- if (PAGE_SIZE % (32 * 1024) == 0)
- bs = 32 * 1024;
- else if (PAGE_SIZE % (16 * 1024) == 0)
- bs = 16 * 1024;
- else if (PAGE_SIZE % (8 * 1024) == 0)
- bs = 8 * 1024;
- else if (PAGE_SIZE % (4 * 1024) == 0)
- bs = 4 * 1024;
- else
- BUG();
- rp->rbr_block_size = bs;
- rp->rbr_blocks_per_page = PAGE_SIZE / bs;
- }
+ rp->rbr_block_size = 1 << bss;
+ rp->rbr_blocks_per_page = 1 << (PAGE_SHIFT-bss);
rp->rbr_sizes[0] = 256;
rp->rbr_sizes[1] = 1024;
@@ -7902,12 +7883,7 @@ static int __init niu_init(void)
{
int err = 0;
- BUILD_BUG_ON((PAGE_SIZE < 4 * 1024) ||
- ((PAGE_SIZE > 32 * 1024) &&
- ((PAGE_SIZE % (32 * 1024)) != 0 &&
- (PAGE_SIZE % (16 * 1024)) != 0 &&
- (PAGE_SIZE % (8 * 1024)) != 0 &&
- (PAGE_SIZE % (4 * 1024)) != 0)));
+ BUILD_BUG_ON(PAGE_SIZE < 4 * 1024);
niu_debug = netif_msg_init(debug, NIU_MSG_DEFAULT);
^ permalink raw reply related
* [PATCH] pasemi_mac: fix typo
From: Olof Johansson @ 2007-10-20 19:10 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-dev
Add missing &:
drivers/net/pasemi_mac.c: In function 'pasemi_mac_clean_rx':
drivers/net/pasemi_mac.c:553: warning: passing argument 1 of 'prefetch'
makes pointer from integer without a cast
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/drivers/net/pasemi_mac.c b/drivers/net/pasemi_mac.c
index 9f9a421..ab4d309 100644
--- a/drivers/net/pasemi_mac.c
+++ b/drivers/net/pasemi_mac.c
@@ -550,7 +550,7 @@ static int pasemi_mac_clean_rx(struct pasemi_mac *mac, int limit)
n = mac->rx->next_to_clean;
- prefetch(RX_RING(mac, n));
+ prefetch(&RX_RING(mac, n));
for (count = 0; count < limit; count++) {
macrx = RX_RING(mac, n);
^ permalink raw reply related
* [PATCH] niu: Cleanup PAGE_SIZE checks a bit
From: Olof Johansson @ 2007-10-20 19:06 UTC (permalink / raw)
To: davem; +Cc: netdev
Hi Dave,
I get the following warning from a powerpc allyesconfig of current
mainline:
drivers/net/niu.c: In function 'niu_size_rbr':
drivers/net/niu.c:3113: warning: large integer implicitly truncated to unsigned type
PAGE_SIZE in this case is 64KB, so I don't quite get why gcc can't tell
that the line in question will never be reached.
I suggest the following instead, but I can unfortunately not do anything but
build test it.
Also, the driver does some other checks to make sure that PAGE_SIZE is a
power of two (BUILD_BUG_ON() in niu_init()), doesn't seem like that could
ever be untrue? Or are there really archs with non-power-of-two PAGE_SIZE?
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/drivers/net/niu.c b/drivers/net/niu.c
index ed1f9bb..795cc68 100644
--- a/drivers/net/niu.c
+++ b/drivers/net/niu.c
@@ -3103,31 +3103,12 @@ static int niu_alloc_tx_ring_info(struct niu *np,
static void niu_size_rbr(struct niu *np, struct rx_ring_info *rp)
{
- u16 bs;
+ u16 bss;
- switch (PAGE_SIZE) {
- case 4 * 1024:
- case 8 * 1024:
- case 16 * 1024:
- case 32 * 1024:
- rp->rbr_block_size = PAGE_SIZE;
- rp->rbr_blocks_per_page = 1;
- break;
+ bss = max(PAGE_SHIFT, 15);
- default:
- if (PAGE_SIZE % (32 * 1024) == 0)
- bs = 32 * 1024;
- else if (PAGE_SIZE % (16 * 1024) == 0)
- bs = 16 * 1024;
- else if (PAGE_SIZE % (8 * 1024) == 0)
- bs = 8 * 1024;
- else if (PAGE_SIZE % (4 * 1024) == 0)
- bs = 4 * 1024;
- else
- BUG();
- rp->rbr_block_size = bs;
- rp->rbr_blocks_per_page = PAGE_SIZE / bs;
- }
+ rp->rbr_block_size = 1 << bss;
+ rp->rbr_blocks_per_page = 1 << (PAGE_SHIFT-bss);
rp->rbr_sizes[0] = 256;
rp->rbr_sizes[1] = 1024;
@@ -7902,12 +7883,7 @@ static int __init niu_init(void)
{
int err = 0;
- BUILD_BUG_ON((PAGE_SIZE < 4 * 1024) ||
- ((PAGE_SIZE > 32 * 1024) &&
- ((PAGE_SIZE % (32 * 1024)) != 0 &&
- (PAGE_SIZE % (16 * 1024)) != 0 &&
- (PAGE_SIZE % (8 * 1024)) != 0 &&
- (PAGE_SIZE % (4 * 1024)) != 0)));
+ BUILD_BUG_ON(PAGE_SIZE < 4 * 1024);
niu_debug = netif_msg_init(debug, NIU_MSG_DEFAULT);
^ permalink raw reply related
* Re: ISNs and 2.6.22, Was: Re: haproxy & linux firewall (netfilter)
From: Krzysztof Oledzki @ 2007-10-20 17:23 UTC (permalink / raw)
To: Willy Tarreau; +Cc: haproxy, netdev
In-Reply-To: <Pine.LNX.4.64.0710201853070.19637@bizon.gios.gov.pl>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3275 bytes --]
On Sat, 20 Oct 2007, Krzysztof Oledzki wrote:
>
>
> On Sat, 20 Oct 2007, Willy Tarreau wrote:
> <CUT>
>
>>>> What is very strange is that linux uses random increments, so your ISNs
>>>> should not wrap in a matter of a few seconds.
>>>
>>> Good point. I need to investigate this.
>>
>> netcat is very convenient for such tests. It's easy to bind it to a
>> source port for consecutive tests while you run tcpdump in the background :
>>
>> $ echo bla | nc -p 1234 192.168.1.2 80
>> $ echo bla | nc -p 1234 192.168.1.2 80
>>
>> Also, please try this with tcp_timestamps enabled and disabled to see if it
>> changes anything.
>
> Interesting... :|
>
> 2.6.20:
> 18:52:33.558379 IP 192.168.0.33.3333 > 212.77.100.101.80: S
> 3708509816:3708509816(0) win 5840 <mss 1460,sackOK,timestamp 1884090256
> 0,nop,wscale 1>
> 18:52:33.882129 IP 192.168.0.33.3333 > 212.77.100.101.80: S
> 3708833567:3708833567(0) win 5840 <mss 1460,sackOK,timestamp 1884090580
> 0,nop,wscale 1>
> 18:52:34.084000 IP 192.168.0.33.3333 > 212.77.100.101.80: S
> 3709035437:3709035437(0) win 5840 <mss 1460,sackOK,timestamp 1884090782
> 0,nop,wscale 1>
>
> 2.6.21:
> 18:58:36.074969 IP 192.168.0.66.3333 > 212.77.100.101.80: S
> 110585153:110585153(0) win 5840 <mss 1460,sackOK,timestamp 112007046
> 0,nop,wscale 5>
> 18:58:36.440084 IP 192.168.0.66.3333 > 212.77.100.101.80: S
> 110950271:110950271(0) win 5840 <mss 1460,sackOK,timestamp 112007412
> 0,nop,wscale 5>
> 18:58:36.830141 IP 192.168.0.66.3333 > 212.77.100.101.80: S
> 111340328:111340328(0) win 5840 <mss 1460,sackOK,timestamp 112007802
> 0,nop,wscale 5>
>
> 2.6.22:
> 18:59:34.525097 IP 192.168.0.7.3333 > 212.77.100.101.80: S
> 3303295586:3303295586(0) win 5840 <mss 1460,sackOK,timestamp 1111842
> 0,nop,wscale 6>
> 18:59:34.942104 IP 192.168.0.7.3333 > 212.77.100.101.80: S
> 3720303240:3720303240(0) win 5840 <mss 1460,sackOK,timestamp 1112259
> 0,nop,wscale 6>
> 18:59:35.412229 IP 192.168.0.7.3333 > 212.77.100.101.80: S
> 4190427367:4190427367(0) win 5840 <mss 1460,sackOK,timestamp 1112729
> 0,nop,wscale 6>
>
> 2.6.22+tcp_timestamps=0:
> 19:00:38.285554 IP 192.168.0.7.3333 > 212.77.100.101.80: S
> 2639244549:2639244549(0) win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
> 19:00:39.448675 IP 192.168.0.7.3333 > 212.77.100.101.80: S
> 3802363348:3802363348(0) win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
> 19:00:43.003850 IP 192.168.0.7.3333 > 212.77.100.101.80: S
> 3062574559:3062574559(0) win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
> 19:00:45.950863 IP 192.168.0.7.3333 > 212.77.100.101.80: S
> 1714619373:1714619373(0) win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
>
> So it seems that ISNs are not randomly incremented but rather randomly
> generated. Adding netdev@vger.kernel.org to the CC list.
Eh, I was little to hurry this time. There were not randomly generated but
incremented with to big value. This patch fixes my problem:
http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob;f=queue-2.6.22/fix-tcp-initial-sequence-number-selection.patch;h=05b9167d68ecde1e6088f58c55e2906b768420ed;hb=HEAD
Looking forward for a next -stable release. ;)
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* ISNs and 2.6.22, Was: Re: haproxy & linux firewall (netfilter)
From: Krzysztof Oledzki @ 2007-10-20 17:08 UTC (permalink / raw)
To: Willy Tarreau; +Cc: haproxy, netdev
In-Reply-To: <20071020150035.GA12878@1wt.eu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2685 bytes --]
On Sat, 20 Oct 2007, Willy Tarreau wrote:
<CUT>
>>> What is very strange is that linux uses random increments, so your ISNs
>>> should not wrap in a matter of a few seconds.
>>
>> Good point. I need to investigate this.
>
> netcat is very convenient for such tests. It's easy to bind it to a
> source port for consecutive tests while you run tcpdump in the background :
>
> $ echo bla | nc -p 1234 192.168.1.2 80
> $ echo bla | nc -p 1234 192.168.1.2 80
>
> Also, please try this with tcp_timestamps enabled and disabled to see if it
> changes anything.
Interesting... :|
2.6.20:
18:52:33.558379 IP 192.168.0.33.3333 > 212.77.100.101.80: S 3708509816:3708509816(0) win 5840 <mss 1460,sackOK,timestamp 1884090256 0,nop,wscale 1>
18:52:33.882129 IP 192.168.0.33.3333 > 212.77.100.101.80: S 3708833567:3708833567(0) win 5840 <mss 1460,sackOK,timestamp 1884090580 0,nop,wscale 1>
18:52:34.084000 IP 192.168.0.33.3333 > 212.77.100.101.80: S 3709035437:3709035437(0) win 5840 <mss 1460,sackOK,timestamp 1884090782 0,nop,wscale 1>
2.6.21:
18:58:36.074969 IP 192.168.0.66.3333 > 212.77.100.101.80: S 110585153:110585153(0) win 5840 <mss 1460,sackOK,timestamp 112007046 0,nop,wscale 5>
18:58:36.440084 IP 192.168.0.66.3333 > 212.77.100.101.80: S 110950271:110950271(0) win 5840 <mss 1460,sackOK,timestamp 112007412 0,nop,wscale 5>
18:58:36.830141 IP 192.168.0.66.3333 > 212.77.100.101.80: S 111340328:111340328(0) win 5840 <mss 1460,sackOK,timestamp 112007802 0,nop,wscale 5>
2.6.22:
18:59:34.525097 IP 192.168.0.7.3333 > 212.77.100.101.80: S 3303295586:3303295586(0) win 5840 <mss 1460,sackOK,timestamp 1111842 0,nop,wscale 6>
18:59:34.942104 IP 192.168.0.7.3333 > 212.77.100.101.80: S 3720303240:3720303240(0) win 5840 <mss 1460,sackOK,timestamp 1112259 0,nop,wscale 6>
18:59:35.412229 IP 192.168.0.7.3333 > 212.77.100.101.80: S 4190427367:4190427367(0) win 5840 <mss 1460,sackOK,timestamp 1112729 0,nop,wscale 6>
2.6.22+tcp_timestamps=0:
19:00:38.285554 IP 192.168.0.7.3333 > 212.77.100.101.80: S 2639244549:2639244549(0) win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
19:00:39.448675 IP 192.168.0.7.3333 > 212.77.100.101.80: S 3802363348:3802363348(0) win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
19:00:43.003850 IP 192.168.0.7.3333 > 212.77.100.101.80: S 3062574559:3062574559(0) win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
19:00:45.950863 IP 192.168.0.7.3333 > 212.77.100.101.80: S 1714619373:1714619373(0) win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
So it seems that ISNs are not randomly incremented but rather randomly
generated. Adding netdev@vger.kernel.org to the CC list.
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* Bluetooth patches for 2.6.24
From: Marcel Holtmann @ 2007-10-20 14:00 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev
Hi Dave,
these are the Bluetooth patches for the 2.6.24 kernel release. Please
pull and send them to Linus.
I assigned the next free constant for SOL_BLUETOOTH which will be used
to consolidate all the new socket options that are work in progress.
Regards
Marcel
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git
This will update the following files:
drivers/bluetooth/Kconfig | 35
drivers/bluetooth/Makefile | 4
drivers/bluetooth/bluecard_cs.c | 5
drivers/bluetooth/bpa10x.c | 624 ++++++--------
drivers/bluetooth/bt3c_cs.c | 5
drivers/bluetooth/btsdio.c | 406 +++++++++
drivers/bluetooth/btuart_cs.c | 5
drivers/bluetooth/btusb.c | 564 +++++++++++++
drivers/bluetooth/dtl1_cs.c | 5
drivers/bluetooth/hci_bcsp.c | 3
drivers/bluetooth/hci_ldisc.c | 8
drivers/bluetooth/hci_ll.c | 531 ++++++++++++
drivers/bluetooth/hci_uart.h | 8
include/linux/socket.h | 1
include/net/bluetooth/hci.h | 604 ++++++++------
include/net/bluetooth/hci_core.h | 13
include/net/bluetooth/l2cap.h | 37
net/bluetooth/hci_conn.c | 82 +
net/bluetooth/hci_core.c | 70 +
net/bluetooth/hci_event.c | 1651 +++++++++++++++++++++------------------
net/bluetooth/hci_sock.c | 2
net/bluetooth/hci_sysfs.c | 37
net/bluetooth/hidp/core.c | 2
net/bluetooth/l2cap.c | 306 ++++---
net/bluetooth/rfcomm/tty.c | 25
net/bluetooth/sco.c | 12
26 files changed, 3524 insertions(+), 1521 deletions(-)
through these ChangeSets:
Commit: 4c5534cce0c2be513ee071b41536d91180a775e2
Author: Marcel Holtmann <marcel@holtmann.org> Sat, 20 Oct 2007 15:28:08 +0200
[Bluetooth] Add constant for Bluetooth socket options level
Assign the next free socket options level to be used by the Bluetooth
protocol and address family.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: c0c9360deb699f4647b901611af73d2935f4d16a
Author: Marcel Holtmann <marcel@holtmann.org> Sat, 20 Oct 2007 14:55:10 +0200
[Bluetooth] Add support for handling simple eSCO links
With the Bluetooth 1.2 specification the Extended SCO feature for
better audio connections was introduced. So far the Bluetooth core
wasn't able to handle any eSCO connections correctly. This patch
adds simple eSCO support while keeping backward compatibility with
older devices.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: 9f73edf6556372b2ca308a90b6e86c42c299572c
Author: Marcel Holtmann <marcel@holtmann.org> Sat, 20 Oct 2007 14:52:38 +0200
[Bluetooth] Add address and channel attribute to RFCOMM TTY device
Export the remote device address and channel of RFCOMM TTY device
via sysfs attributes. This allows udev to create better naming rules
for configured RFCOMM devices.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: 8ede11da710c41c82c15e706985a557b8925d412
Author: Dave Young <hidave.darkstar@gmail.com> Sat, 20 Oct 2007 14:15:39 +0200
[Bluetooth] Fix wrong argument in debug code of HIDP
In the debug code of the hidp_queue_report function, the device
variable does not exist, replace it with session->hid.
Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: 40f8ebd22f42a2590983bfb44f79e2b8c0f8bbd3
Author: Marcel Holtmann <marcel@holtmann.org> Sat, 20 Oct 2007 14:12:34 +0200
[Bluetooth] Add generic driver for Bluetooth USB devices
This patch adds a new generic driver for Bluetooth USB devices. This
driver is still experimental at this point, but it is cleaner and
easier to maintain than the current Bluetooth USB driver. It is a
much better starting point for power management improvements.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: 7206aecb43d34e533722b10619878aa073fd20c0
Author: Marcel Holtmann <marcel@holtmann.org> Sat, 20 Oct 2007 14:02:04 +0200
[Bluetooth] Add generic driver for Bluetooth SDIO devices
This patch adds a generic driver for Bluetooth SDIO devices. It
supports Type-A and Type-B devices.
Signed-off-by: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: bcce038d8f2cfe0bb6d470d6029aa239fc1b5d73
Author: Jeff Garzik <jeff@garzik.org> Sat, 20 Oct 2007 13:45:57 +0200
[Bluetooth] Eliminate checks for impossible conditions in IRQ handler
Our info structure and info->hdev is always passed to the IRQ handler,
so we don't have to worry about these checks in every interrupt.
Leave a BUG_ON() just to help unwary programmers, but these could
probably be removed as well.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: d9f2f1b6273c089aeeed183c77eb0d1837942438
Author: Ohad Ben-Cohen <ohad@bencohen.org> Sat, 20 Oct 2007 13:42:36 +0200
[Bluetooth] Add UART driver for Texas Instruments' BRF63xx chips
Add support for Texas Instruments' HCI Low Level (HCILL) Bluetooth
protocol, which is a power management extension to H4. The HCILL is
widely used by TI's BRF63xx Bluetooth chips.
Signed-off-by: Ohad Ben-Cohen <ohad@bencohen.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: 2bee5dbd7663fb87ad7c4dc3e5e738ecfb5df1e2
Author: Marcel Holtmann <marcel@holtmann.org> Sat, 20 Oct 2007 13:41:33 +0200
[Bluetooth] Change BPA 100/105 driver to use USB anchors
With the new support for USB anchors the driver can become more
simpler and also cleaner. This patch switches to the usage of USB
anchors for all URBs.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: 127a0a7997329bf68ee966cde4fb58ac691d66c9
Author: Marcel Holtmann <marcel@holtmann.org> Sat, 20 Oct 2007 13:39:51 +0200
[Bluetooth] Fall back to L2CAP in basic mode
In case the remote entity tries to negogiate retransmission or flow
control mode, reject it and fall back to basic mode.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: a57044011679d14754b258b329a8138bbb9f547e
Author: Marcel Holtmann <marcel@holtmann.org> Sat, 20 Oct 2007 13:38:51 +0200
[Bluetooth] Advertise L2CAP features mask support
Indicate the support for the L2CAP features mask value when the remote
entity tries to negotiate Bluetooth 1.2 specific features.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: 28f5cb488d346fd700803900aea084d85914e5a5
Author: Marcel Holtmann <marcel@holtmann.org> Sat, 20 Oct 2007 13:37:56 +0200
[Bluetooth] Retrieve L2CAP features mask on connection setup
The Bluetooth 1.2 specification introduced a specific features mask
value to interoperate with newer versions of the specification. So far
this piece of information was never needed, but future extensions will
rely on it. This patch adds a generic way to retrieve this information
only once per connection setup.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: 24d08d292235803b93938727181491c2a2fe1782
Author: Marcel Holtmann <marcel@holtmann.org> Sat, 20 Oct 2007 13:37:06 +0200
[Bluetooth] Remove global conf_mtu variable from L2CAP
After the change to the L2CAP configuration parameter handling the
global conf_mtu variable is no longer needed and so remove it.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: 938eb4feb80112b7b3bae0e958dc1d3573a6d926
Author: Marcel Holtmann <marcel@holtmann.org> Sat, 20 Oct 2007 13:35:42 +0200
[Bluetooth] Finish L2CAP configuration only with acceptable settings
The parameters of the L2CAP output configuration might not be accepted
after the first configuration round. So only indicate a finished output
configuration when acceptable settings are provided.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Commit: 12389548391560538f19455ddec0fd7d8d10c8be
Author: Marcel Holtmann <marcel@holtmann.org> Sat, 20 Oct 2007 13:33:56 +0200
[Bluetooth] Switch from OGF+OCF to using only opcodes
The Bluetooth HCI commands are divided into logical OGF groups for
easier identification of their purposes. While this still makes sense
for the written specification, its makes the code only more complex
and harder to read. So instead of using separate OGF and OCF values
to identify the commands, use a common 16-bit opcode that combines
both values. As a side effect this also reduces the complexity of
OGF and OCF calculations during command header parsing.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
^ permalink raw reply
* Re: PROBLEM: oops, Linus tree: 2.6.23-g4fa4d23f, BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
From: Guillaume Chazarain @ 2007-10-20 11:32 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Dave Haywood, linux-kernel, netdev, Pavel Emelyanov
In-Reply-To: <Pine.LNX.4.64.0710201246540.18815@twin.jikos.cz>
> > BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
This should be fixed in recent git by
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=9b013e05e0289c190a53d78ca029e2f21c0e4485
HTH.
--
Guillaume
^ permalink raw reply
* Re: [RFD] iptables: mangle table obsoletes filter table
From: Jan Engelhardt @ 2007-10-20 11:10 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Al Boldi, Bill Davidsen, Patrick McHardy, netfilter-devel, netdev,
linux-net, linux-kernel
In-Reply-To: <26556.1192855654@turing-police.cc.vt.edu>
On Oct 20 2007 00:47, Valdis.Kletnieks@vt.edu wrote:
>> Sure, the idea was to mark the filter table obsolete as to make people start
>> using the mangle table to do their filtering for new setups. The filter
>> table would then still be available for legacy/special setups. But this
>> would only be possible if we at least ported the REJECT target to mangle.
>
>That's *half* the battle. The other half is explaining why I should move
>from a perfectly functional setup that uses the filter table. What gains
>do I get from doing so? What isn't working that I don't know about? etc?
>
>In other words - why do I want to move from filter to mangle?
Packet processing time.
Compare previous:
packet goes through mangle, then is dropped in filter
Compare afterwards:
packet is already dropped in mangle
=> less code to run through
^ permalink raw reply
* Re: PROBLEM: oops, Linus tree: 2.6.23-g4fa4d23f, BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
From: Jiri Kosina @ 2007-10-20 10:54 UTC (permalink / raw)
To: Dave Haywood; +Cc: linux-kernel, netdev, Pavel Emelyanov
In-Reply-To: <4719B727.7090908@oak.selfip.net>
added some relevant CCs
On Sat, 20 Oct 2007, Dave Haywood wrote:
> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
>
> Linux s1 2.6.23-g4fa4d23f #4 Fri Oct 19 10:15:50 BST 2007 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
>
> Gnu C 4.2.0
> Gnu make 3.81
> binutils 2.18
> util-linux 2.12r
> mount 2.12r
> module-init-tools 3.2.2
> e2fsprogs 1.40.2
> PPP 2.4.4
> Linux C Library 2.6.1
> Dynamic linker (ldd) 2.6.1
> Procps 3.2.7
> Net-tools 1.60
> Kbd 1.13
> Sh-utils 6.9
> udev 115
>
> Linux version 2.6.23-g4fa4d23f (tla@s1) (gcc version 4.2.0 (Gentoo 4.2.0 p1.4)) #4 Fri Oct 19 10:15:50 BST 2007
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 000000000fed0000 (usable)
> BIOS-e820: 000000000fed0000 - 000000000fef0000 (ACPI NVS)
> BIOS-e820: 000000000fef0000 - 000000000ff00000 (usable)
> BIOS-e820: 00000000feea0000 - 0000000100000000 (reserved)
> 0MB HIGHMEM available.
> 255MB LOWMEM available.
> found SMP MP-table at 000f9bf0
> Entering add_active_range(0, 0, 65280) 0 entries of 256 used
> Zone PFN ranges:
> DMA 0 -> 4096
> Normal 4096 -> 65280
> HighMem 65280 -> 65280
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0 -> 65280
> On node 0 totalpages: 65280
> DMA zone: 32 pages used for memmap
> DMA zone: 0 pages reserved
> DMA zone: 4064 pages, LIFO batch:0
> Normal zone: 478 pages used for memmap
> Normal zone: 60706 pages, LIFO batch:15
> HighMem zone: 0 pages used for memmap
> Movable zone: 0 pages used for memmap
> DMI 2.3 present.
> Using APIC driver default
> ACPI: RSDP 000E0010, 0014 (r0 COMPAQ)
> ACPI: RSDT 000E0080, 0054 (r1 COMPAQ CPQ0014 20010612 0)
> ACPI: FACP 000E0130, 0074 (r1 COMPAQ SOLANO 1 0)
> ACPI: DSDT 000E0204, 0CE6 (r1 COMPAQ DSDT 1 MSFT 100000D)
> ACPI: FACS 000E0040, 0040
> ACPI: SSDT 000E0EEA, 0174 (r1 COMPAQ CORE_UTL 1 MSFT 100000D)
> ACPI: SSDT 000E105E, 0D3D (r1 COMPAQ VILLTBL1 1 MSFT 100000D)
> ACPI: APIC 000E01A4, 0060 (r1 COMPAQ SOLANO 1 0)
> ACPI: SSDT 000E2D4F, 0076 (r1 COMPAQ APIC 1 MSFT 100000D)
> ACPI: SSDT 000E1D9B, 06AD (r1 COMPAQ PNP_PRSS 1 MSFT 100000D)
> ACPI: SSDT 000E24A6, 01A4 (r1 COMPAQ S3 1 MSFT 100000D)
> ACPI: SSDT 000E264A, 0158 (r1 COMPAQ PIDETM 1 MSFT 100000D)
> ACPI: SSDT 000E28FF, 010B (r1 COMPAQ GTF0 1 MSFT 100000D)
> ACPI: SSDT 000E27A2, 015D (r1 COMPAQ SIDETM 1 MSFT 100000D)
> ACPI: SSDT 000E2B21, 0117 (r1 COMPAQ GTF2 1 MSFT 100000D)
> ACPI: SSDT 000E2EAD, 004E (r1 COMPAQ FINIS 1 MSFT 100000D)
> ACPI: PM-Timer IO Port: 0xf808
> ACPI: Local APIC address 0xfee00000
> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
> Processor #0 6:8 APIC version 17
> ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
> ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
> ACPI: IOAPIC (id[0x08] address[0xfec00000] gsi_base[0])
> IOAPIC[0]: apic_id 8, version 32, address 0xfec00000, GSI 0-23
> ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
> ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
> ACPI: IRQ0 used by override.
> ACPI: IRQ2 used by override.
> ACPI: IRQ9 used by override.
> Enabling APIC mode: Flat. Using 1 I/O APICs
> Using ACPI (MADT) for SMP configuration information
> Allocating PCI resources starting at 10000000 (gap: 0ff00000:eefa0000)
> swsusp: Registered nosave memory region: 000000000009f000 - 00000000000a0000
> swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000e0000
> swsusp: Registered nosave memory region: 00000000000e0000 - 0000000000100000
> swsusp: Registered nosave memory region: 000000000fed0000 - 000000000fef0000
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64770
> Kernel command line: root=/dev/md4
> mapped APIC to ffffb000 (fee00000)
> mapped IOAPIC to ffffa000 (fec00000)
> Enabling fast FPU save and restore... done.
> Enabling unmasked SIMD FPU exception support... done.
> Initializing CPU#0
> PID hash table entries: 1024 (order: 10, 4096 bytes)
> Detected 930.368 MHz processor.
> Console: colour VGA+ 80x25
> console [tty0] enabled
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 252820k/261120k available (3213k kernel code, 7612k reserved, 1274k data, 264k init, 0k highmem)
> virtual kernel memory layout:
> fixmap : 0xfffa7000 - 0xfffff000 ( 352 kB)
> pkmap : 0xff800000 - 0xffc00000 (4096 kB)
> vmalloc : 0xd0800000 - 0xff7fe000 ( 751 MB)
> lowmem : 0xc0000000 - 0xcff00000 ( 255 MB)
> .init : 0xc0564000 - 0xc05a6000 ( 264 kB)
> .data : 0xc04236bc - 0xc0561f08 (1274 kB)
> .text : 0xc0100000 - 0xc04236bc (3213 kB)
> Checking if this processor honours the WP bit even in supervisor mode... Ok.
> SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
> Calibrating delay using timer specific routine.. 1862.06 BogoMIPS (lpj=3724128)
> Mount-cache hash table entries: 512
> CPU: After generic identify, caps: 0383fbff 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> CPU: L1 I cache: 16K, L1 D cache: 16K
> CPU: L2 cache: 256K
> CPU: After all inits, caps: 0383fbff 00000000 00000000 00000040 00000000 00000000 00000000 00000000
> Intel machine check architecture supported.
> Intel machine check reporting enabled on CPU#0.
> Compat vDSO mapped to ffffe000.
> CPU: Intel Pentium III (Coppermine) stepping 06
> Checking 'hlt' instruction... OK.
> Freeing SMP alternatives: 0k freed
> ACPI: Core revision 20070126
> Parsing all Control Methods:
> Table [DSDT](id 0001) - 147 Objects with 18 Devices 32 Methods 2 Regions
> Parsing all Control Methods:
> Table [SSDT](id 0002) - 3 Objects with 0 Devices 3 Methods 0 Regions
> Parsing all Control Methods:
> Table [SSDT](id 0003) - 100 Objects with 9 Devices 23 Methods 5 Regions
> Parsing all Control Methods:
> Table [SSDT](id 0004) - 4 Objects with 1 Devices 1 Methods 0 Regions
> Parsing all Control Methods:
> Table [SSDT](id 0005) - 21 Objects with 0 Devices 10 Methods 1 Regions
> Parsing all Control Methods:
> Table [SSDT](id 0006) - 11 Objects with 0 Devices 8 Methods 0 Regions
> Parsing all Control Methods:
> Table [SSDT](id 0007) - 19 Objects with 1 Devices 5 Methods 2 Regions
> Parsing all Control Methods:
> Table [SSDT](id 0008) - 5 Objects with 1 Devices 3 Methods 0 Regions
> Parsing all Control Methods:
> Table [SSDT](id 0009) - 19 Objects with 1 Devices 5 Methods 2 Regions
> Parsing all Control Methods:
> Table [SSDT](id 000A) - 5 Objects with 1 Devices 3 Methods 0 Regions
> Parsing all Control Methods:
> Table [SSDT](id 000B) - 2 Objects with 0 Devices 2 Methods 0 Regions
> tbxface-0598 [00] tb_load_namespace : ACPI Tables successfully acquired
> evxfevnt-0091 [00] enable : Transition to ACPI mode successful
> ENABLING IO-APIC IRQs
> ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
> net_namespace: 64 bytes
> NET: Registered protocol family 16
> ACPI: bus type pci registered
> PCI: PCI BIOS revision 2.10 entry at 0xe8316, last bus=2
> PCI: Using configuration type 1
> Setting up standard PCI resources
> evgpeblk-0956 [00] ev_create_gpe_block : GPE 00 to 0F [_GPE] 2 regs on int 0x9
> evgpeblk-1052 [00] ev_initialize_gpe_bloc: Found 4 Wake, Enabled 0 Runtime GPEs in this block
> ACPI: EC: Look up EC in DSDT
> Completing Region/Field/Buffer/Package initialization:............................................
> Initialized 8/12 Regions 0/0 Fields 31/31 Buffers 5/12 Packages (345 nodes)
> Initializing Device/Processor/Thermal objects by executing _INI methods:.
> Executed 1 _INI methods requiring 0 _STA executions (examined 35 objects)
> ACPI: Interpreter enabled
> ACPI: (supports S0 S1 S3 S4 S5)
> ACPI: Using IOAPIC for interrupt routing
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> PCI quirk: region f800-f87f claimed by ICH4 ACPI/GPIO/TCO
> PCI quirk: region fa00-fa3f claimed by ICH4 GPIO
> PCI: Transparent bridge - 0000:00:1e.0
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
> ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB_._PRT]
> ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 6 7 10 11 14 15)
> ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 14 15) *9
> ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 *10 11 14 15)
> ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 *11 14 15)
> Linux Plug and Play Support v0.97 (c) Adam Belay
> pnp: PnP ACPI init
> ACPI: bus type pnp registered
> pnp: PnP ACPI: found 15 devices
> ACPI: ACPI bus type pnp unregistered
> SCSI subsystem initialized
> libata version 3.00 loaded.
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> PCI: Using ACPI for IRQ routing
> PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
> Time: tsc clocksource has been installed.
> system 00:0c: ioport range 0x4d0-0x4d1 has been reserved
> system 00:0d: ioport range 0x400-0x41f has been reserved
> system 00:0d: ioport range 0x420-0x43f has been reserved
> system 00:0d: ioport range 0x440-0x45f has been reserved
> system 00:0d: ioport range 0x460-0x47f has been reserved
> system 00:0d: ioport range 0xf800-0xf81f has been reserved
> system 00:0d: ioport range 0xf820-0xf83f has been reserved
> system 00:0d: ioport range 0xf840-0xf85f has been reserved
> system 00:0d: ioport range 0xf860-0xf87f has been reserved
> system 00:0e: iomem range 0x0-0x9ffff could not be reserved
> system 00:0e: iomem range 0xe0000-0xfffff could not be reserved
> system 00:0e: iomem range 0x100000-0xfefffff could not be reserved
> system 00:0e: iomem range 0xfff80000-0xffffffff could not be reserved
> PCI: Bridge: 0000:00:1e.0
> IO window: 1000-1fff
> MEM window: 40000000-407fffff
> PREFETCH window: disabled.
> PCI: Setting latency timer of device 0000:00:1e.0 to 64
> NET: Registered protocol family 2
> IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> TCP reno registered
> Machine check exception polling timer started.
> IA-32 Microcode Update Driver: v1.14a <tigran@aivazian.fsnet.co.uk>
> Total HugeTLB memory allocated, 0
> io scheduler noop registered
> io scheduler cfq registered (default)
> Boot video device is 0000:00:02.0
> input: Power Button (FF) as /devices/virtual/input/input0
> ACPI: Power Button (FF) [PWRF]
> input: Power Button (CM) as /devices/virtual/input/input1
> ACPI: Power Button (CM) [PBTN]
> ACPI: Processor [CPU0] (supports 8 throttling states)
> Real Time Clock Driver v1.12ac
> intel_rng: FWH not detected
> Linux agpgart interface v0.102
> agpgart: Detected an Intel i815 Chipset.
> agpgart: AGP aperture is 64M @ 0x44000000
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
> serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> 00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> FDC 0 is a post-1991 82077
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: module loaded
> Intel(R) PRO/1000 Network Driver - version 7.3.20-k2
> Copyright (c) 1999-2006 Intel Corporation.
> e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
> e100: Copyright(c) 1999-2006 Intel Corporation
> 8139too Fast Ethernet driver 0.9.28
> ACPI: PCI Interrupt 0000:02:09.0[A] -> GSI 17 (level, low) -> IRQ 16
> eth0: RealTek RTL8139 at 0xd0816000, 00:05:5d:49:eb:21, IRQ 16
> eth0: Identified 8139 chip type 'RTL-8139C'
> ACPI: PCI Interrupt 0000:02:0a.0[A] -> GSI 18 (level, low) -> IRQ 17
> eth1: RealTek RTL8139 at 0xd0818000, 00:10:b5:ac:ea:7d, IRQ 17
> eth1: Identified 8139 chip type 'RTL-8139B'
> console [netcon0] enabled
> netconsole: network logging started
> Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ICH: IDE controller at PCI slot 0000:00:1f.1
> ICH: chipset revision 2
> ICH: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0x2460-0x2467, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0x2468-0x246f, BIOS settings: hdc:DMA, hdd:pio
> Probing IDE interface ide0...
> Switched to high resolution mode on CPU 0
> hda: Maxtor 6G160P0, ATA DISK drive
> hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> hda: selected mode 0x44
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> Probing IDE interface ide1...
> hdc: Maxtor 6G160P0, ATA DISK drive
> hdc: host max PIO4 wanted PIO255(auto-tune) selected PIO4
> hdc: selected mode 0x44
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: max request size: 512KiB
> hda: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63, UDMA(66)
> hda: cache flushes supported
> hda: hda1 hda2 hda3 hda4
> hdc: max request size: 512KiB
> hdc: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63, UDMA(66)
> hdc: cache flushes supported
> hdc: hdc1 hdc2 hdc3 hdc4
> Fusion MPT base driver 3.04.06
> Copyright (c) 1999-2007 LSI Corporation
> Fusion MPT SPI Host driver 3.04.06
> ieee1394: raw1394: /dev/raw1394 device initialized
> usbmon: debugfs is not available
> ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
> USB Universal Host Controller Interface driver v3.0
> ACPI: PCI Interrupt 0000:00:1f.2[D] -> GSI 19 (level, low) -> IRQ 18
> PCI: Setting latency timer of device 0000:00:1f.2 to 64
> uhci_hcd 0000:00:1f.2: UHCI Host Controller
> uhci_hcd 0000:00:1f.2: new USB bus registered, assigned bus number 1
> uhci_hcd 0000:00:1f.2: irq 18, io base 0x00002440
> usb usb1: configuration #1 chosen from 1 choice
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 2 ports detected
> usbcore: registered new interface driver usblp
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> PNP: PS/2 Controller [PNP0303:KBD,PNP0f0e:PS2M] at 0x60,0x64 irq 1,12
> serio: i8042 KBD port at 0x60,0x64 irq 1
> serio: i8042 AUX port at 0x60,0x64 irq 12
> mice: PS/2 mouse device common for all mice
> input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
> md: raid1 personality registered for level 1
> usbcore: registered new interface driver usbhid
> drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
> Netfilter messages via NETLINK v0.30.
> nf_conntrack version 0.5.0 (4096 buckets, 16384 max)
> ctnetlink v0.93: registering with nfnetlink.
> ip_tables: (C) 2000-2006 Netfilter Core Team
> ClusterIP Version 0.8 loaded successfully
> arp_tables: (C) 2002 David S. Miller
> TCP cubic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 10
> ip6_tables: (C) 2000-2006 Netfilter Core Team
> IPv6 over IPv4 tunneling driver
> NET: Registered protocol family 17
> Using IPI Shortcut mode
> input: ImPS/2 Logitech Wheel Mouse as /devices/platform/i8042/serio1/input/input3
> md: Autodetecting RAID arrays.
> md: Scanned 8 and added 8 devices.
> md: autorun ...
> md: considering hdc4 ...
> md: adding hdc4 ...
> md: hdc3 has different UUID to hdc4
> md: hdc2 has different UUID to hdc4
> md: hdc1 has different UUID to hdc4
> md: adding hda4 ...
> md: hda3 has different UUID to hdc4
> md: hda2 has different UUID to hdc4
> md: hda1 has different UUID to hdc4
> md: created md4
> md: bind<hda4>
> md: bind<hdc4>
> md: running: <hdc4><hda4>
> raid1: raid set md4 active with 2 out of 2 mirrors
> md4: bitmap initialized from disk: read 11/11 pages, set 6 bits
> created bitmap (169 pages) for device md4
> md: considering hdc3 ...
> md: adding hdc3 ...
> md: hdc2 has different UUID to hdc3
> md: hdc1 has different UUID to hdc3
> md: adding hda3 ...
> md: hda2 has different UUID to hdc3
> md: hda1 has different UUID to hdc3
> md: created md3
> md: bind<hda3>
> md: bind<hdc3>
> md: running: <hdc3><hda3>
> raid1: raid set md3 active with 2 out of 2 mirrors
> md3: bitmap initialized from disk: read 15/15 pages, set 0 bits
> created bitmap (233 pages) for device md3
> md: considering hdc2 ...
> md: adding hdc2 ...
> md: hdc1 has different UUID to hdc2
> md: adding hda2 ...
> md: hda1 has different UUID to hdc2
> md: created md2
> md: bind<hda2>
> md: bind<hdc2>
> md: running: <hdc2><hda2>
> raid1: raid set md2 active with 2 out of 2 mirrors
> md2: bitmap initialized from disk: read 8/8 pages, set 0 bits
> created bitmap (123 pages) for device md2
> md: considering hdc1 ...
> md: adding hdc1 ...
> md: adding hda1 ...
> md: created md1
> md: bind<hda1>
> md: bind<hdc1>
> md: running: <hdc1><hda1>
> raid1: raid set md1 active with 2 out of 2 mirrors
> md1: bitmap initialized from disk: read 10/10 pages, set 0 bits
> created bitmap (153 pages) for device md1
> md: ... autorun DONE.
> EXT3-fs: INFO: recovery required on readonly filesystem.
> EXT3-fs: write access will be enabled during recovery.
> kjournald starting. Commit interval 5 seconds
> EXT3-fs: recovery complete.
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem) readonly.
> Freeing unused kernel memory: 264k freed
> EXT3 FS on md4, internal journal
> kjournald starting. Commit interval 5 seconds
> EXT3 FS on md3, internal journal
> EXT3-fs: mounted filesystem with ordered data mode.
> Adding 1999992k swap on /dev/md2. Priority:-1 extents:1 across:1999992k
> eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
> eth1: link up, 100Mbps, full-duplex, lpa 0x45E1
> eth0: no IPv6 routers present
> eth1: no IPv6 routers present
> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
> printing eip: c0383fa0 *pde = 00000000
> Oops: 0000 [#1]
> CPU: 0
> EIP: 0060:[<c0383fa0>] Not tainted VLI
> EFLAGS: 00010282 (2.6.23-g4fa4d23f #4)
> EIP is at sk_filter_delayed_uncharge+0x0/0x20
> eax: c5dfb600 ebx: 00000000 ecx: 00000000 edx: 00000000
> esi: c5dfb600 edi: 00000000 ebp: c170d300 esp: c5dcbef8
> ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068
> Process dhcpd (pid: 5380, ti=c5dca000 task=c47f0520 task.ti=c5dca000)
> Stack: c038410f 00000068 00000058 c5dcbf34 b7fd000b c1b75000 c5dfb600 c0371d19
> c1b70fd8 c180d300 c1b70f80 00000007 00000001 b7fd000b c170d900 b7fd000b
> 080c9fa0 0000000e 00000000 c5dcbf6c c036dbc2 0000000e c1b75000 00000008
> Call Trace:
> [<c038410f>] sk_attach_filter+0xdf/0x100
> [<c0371d19>] sock_setsockopt+0x509/0x590
> [<c036dbc2>] sockfd_lookup_light+0x32/0x60
> [<c036dd8b>] sys_setsockopt+0x9b/0xb0
> [<c036f705>] sys_socketcall+0xd5/0x280
> [<c010503e>] sysenter_past_esp+0x5f/0x85
> =======================
> Code: cb 04 76 c7 83 c1 01 83 ee 01 39 d1 75 8d eb d7 83 7c cb 04 0f 77 b4 83 c1 01 83 ee 01 39 d1 0f 85 76 ff ff ff eb c0 8d 74 26 00 <8b> 4a 04 8d 0c cd 10 00 00 00 29 48 5c 8d 42 08 ba 10 40 38 c0
> EIP: [<c0383fa0>] sk_filter_delayed_uncharge+0x0/0x20 SS:ESP 0068:c5dcbef8
>
>
>
--
Jiri Kosina
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox