* 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
* 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
* 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
* 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
* [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
* [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 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
* 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
* 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: 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
* 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: [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
* 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: 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: 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: 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
* [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
* [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
* 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
* 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: 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
* 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: 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
* Re: how to set pppoe source mac address?
From: Patrick McHardy @ 2007-10-21 17:50 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <005a01c813e6$fdae6610$5267a8c0@Jocke>
Joakim Tjernlund wrote:
> 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?
Try the macvlan driver.
^ permalink raw reply
* Re: [patch] ipv6.7: IPV6_ROUTER_ALERT sockopt correction
From: Andrew McDonald @ 2007-10-21 17:51 UTC (permalink / raw)
To: Pekka Savola; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0710170911360.21784@netcore.fi>
On Wed, Oct 17, 2007 at 09:19:15AM +0300, Pekka Savola wrote:
> Router alert option on a hop-by-hop header means that every router on
> the path should process the option.
I think I understand what you mean by "process the option", but it is
a little ambiguous.
The abstract of RFC2711 says:
This memo describes a new IPv6 Hop-by-Hop Option type that alerts
transit routers to more closely examine the contents of an IP
datagram. This option is useful for situations where a datagram
addressed to a particular destination contains information that may
require special processing by routers along the path.
note the "may require special processing by routers" - there is no
expectation that /every/ router will want to do such "special
processing".
For example, there is no expectation that every router supports RSVP.
Non-RSVP routers are simply expected to look the router alert option,
decide they aren't interested in it and forward it normally.
> You did not mention the rationale why the it would be reasonable for a
> packet that would otherwise be forwarded by the Linux router and
> expected to be processed by every router on the path to be re-created
> at every step, and every user-space application have to do that.
I'm confused by your description.
There is certainly no expectation that every router on the path would
be interested in doing "special processing" on the contents of the
packet.
The purpose of the IPV6_ROUTER_ALERT sockopt is so that a userspace
application can say "I'm here, and I'm interested in packets with a
router alert option with value field X." The default case where no
application has expressed an interest in this way is to forward the
packet normally. Anything else would be horrendously broken (though
that does currently apply to some BSD stacks).
> In the specific case of RSVP packets, AFAIK (e.g., Path and PathTear
> messages), the content of the RSVP packet is expected to be the
> same at every hop.
>
> Your argument might make sense in the case where the payload of the
> packet carrying router-alert option is expected to change at every
> hop. I believe that's not the intent of any router alert options that
> I'm aware of.
The first sentence of the introduction of RFC2711 (IPv6 Router Alert
Option) clearly indicates that modification of packets can occur:
New protocols, such as RSVP, use control datagrams which, while
addressed to a particular destination, contain information that needs
to be examined, and in some case updated, by routers along the path
between the source and destination.
To take a couple of examples in RSVP: The RSVP_HOP (PHOP) in a PATH
message is expected to change at each RSVP-capable node. Its purpose is
to tell the next hop the address of the previous hop, so that the RESV
can be sent hop-by-hop back along the path followed by the PATH
messages. The ADSPEC is designed to gather up information about
available resources along the path, so also has to be mutable along the
path in order to fulfil its purpose.
I hope that helps to clarify things.
--
Andrew McDonald
E-mail: andrew@mcdonald.org.uk
http://www.mcdonald.org.uk/andrew/
^ 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