Re: [BUG] powerpc does not save msi state [was Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
On Fri, 2007-10-19 at 17:53 -0700, David Miller wrote:
From: [EMAIL PROTECTED] (Linas Vepstas)
Date: Fri, 19 Oct 2007 19:46:10 -0500
FWIW, it looks like not all that many arches do this; the output
for grep -r address_hi * is pretty thin. Then, looking at
i386/kernel/io_apic.c as an example, one can see that the
msi state save happens by accident if CONFIG_SMP is enabled;
and so its surely broekn on uniprocesor machines.
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.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
Re: linux kernel networking code review request
On Fri, 19 Oct 2007, Dmitry Torokhov wrote: On Friday 19 October 2007, Templin, Fred L wrote: Hello, I would like to get a review on some new Linux kernel networking code. The code is based on the 2.6.23 source tree and touches three files - two in ./net/ipv6 and one in ./include/net. What is the proper procedure for requesting a review? Just don your flameproof pants and post the changes here ;) In addition, check what is being said in Documentation/SubmittingPatches :-) -- i. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
hello!
Dear Sir/Madam, I am looking for a patch or a new code for Fast Ethernet Controller physical driver located at drivers/net/e100.c, Linux kernel 2.6.23, with Large Send Support(TCP Segmentation Offload), adaptor: Intel PRO/100 M,82551QM. I wonder if you know such driver exist and where to obtain its source code. Thank you to read my email, Am Kara. PS. My email is: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: oops, Linus tree: 2.6.23-g4fa4d23f, BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
added some relevant CCs On Sat, 20 Oct 2007, Dave Haywood wrote: BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 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 PPP2.4.4 Linux C Library2.6.1 Dynamic linker (ldd) 2.6.1 Procps 3.2.7 Net-tools 1.60 Kbd1.13 Sh-utils 6.9 udev 115 Linux version 2.6.23-g4fa4d23f ([EMAIL PROTECTED]) (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: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 0fed (usable) BIOS-e820: 0fed - 0fef (ACPI NVS) BIOS-e820: 0fef - 0ff0 (usable) BIOS-e820: feea - 0001 (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 DSDT1 MSFT 10D) ACPI: FACS 000E0040, 0040 ACPI: SSDT 000E0EEA, 0174 (r1 COMPAQ CORE_UTL1 MSFT 10D) ACPI: SSDT 000E105E, 0D3D (r1 COMPAQ VILLTBL11 MSFT 10D) ACPI: APIC 000E01A4, 0060 (r1 COMPAQ SOLANO 1 0) ACPI: SSDT 000E2D4F, 0076 (r1 COMPAQ APIC1 MSFT 10D) ACPI: SSDT 000E1D9B, 06AD (r1 COMPAQ PNP_PRSS1 MSFT 10D) ACPI: SSDT 000E24A6, 01A4 (r1 COMPAQ S31 MSFT 10D) ACPI: SSDT 000E264A, 0158 (r1 COMPAQ PIDETM1 MSFT 10D) ACPI: SSDT 000E28FF, 010B (r1 COMPAQ GTF01 MSFT 10D) ACPI: SSDT 000E27A2, 015D (r1 COMPAQ SIDETM1 MSFT 10D) ACPI: SSDT 000E2B21, 0117 (r1 COMPAQ GTF21 MSFT 10D) ACPI: SSDT 000E2EAD, 004E (r1 COMPAQFINIS1 MSFT 10D) ACPI: PM-Timer IO Port: 0xf808 ACPI: Local APIC address 0xfee0 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[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 8, version 32, address 0xfec0, 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 1000 (gap: 0ff0:eefa) swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000e swsusp: Registered nosave memory region: 000e - 0010 swsusp: Registered nosave memory region: 0fed - 0fef Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64770 Kernel command line: root=/dev/md4 mapped APIC to b000 (fee0) mapped IOAPIC to a000 (fec0) 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 - 0xf000 ( 352 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xd080 - 0xff7fe000 ( 751 MB)
Re: [RFD] iptables: mangle table obsoletes filter table
On Oct 20 2007 00:47, [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: oops, Linus tree: 2.6.23-g4fa4d23f, BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Bluetooth patches for 2.6.24
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Commit: c0c9360deb699f4647b901611af73d2935f4d16a Author: Marcel Holtmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Commit: 9f73edf6556372b2ca308a90b6e86c42c299572c Author: Marcel Holtmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Commit: 8ede11da710c41c82c15e706985a557b8925d412 Author: Dave Young [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Signed-off-by: Marcel Holtmann [EMAIL PROTECTED] Commit: 40f8ebd22f42a2590983bfb44f79e2b8c0f8bbd3 Author: Marcel Holtmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Commit: 7206aecb43d34e533722b10619878aa073fd20c0 Author: Marcel Holtmann [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Signed-off-by: Marcel Holtmann [EMAIL PROTECTED] Commit: bcce038d8f2cfe0bb6d470d6029aa239fc1b5d73 Author: Jeff Garzik [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Signed-off-by: Marcel Holtmann [EMAIL PROTECTED] Commit:
ISNs and 2.6.22, Was: Re: haproxy linux firewall (netfilter)
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. 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. 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. 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. 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. 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. 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. 212.77.100.101.80: S 3303295586:3303295586(0) win 5840 mss 1460,sackOK,timestamp 842 0,nop,wscale 6 18:59:34.942104 IP 192.168.0.7. 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. 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. 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. 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. 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. 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
Re: ISNs and 2.6.22, Was: Re: haproxy linux firewall (netfilter)
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. 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. 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. 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. 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. 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. 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. 212.77.100.101.80: S 3303295586:3303295586(0) win 5840 mss 1460,sackOK,timestamp 842 0,nop,wscale 6 18:59:34.942104 IP 192.168.0.7. 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. 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. 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. 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. 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. 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
[PATCH] niu: Cleanup PAGE_SIZE checks a bit
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 [EMAIL PROTECTED]
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);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pasemi_mac: fix typo
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 [EMAIL PROTECTED]
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);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] niu: Cleanup PAGE_SIZE checks a bit
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 [EMAIL PROTECTED]
--
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);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ISNs and 2.6.22, Was: Re: haproxy linux firewall (netfilter)
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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bluetooth patches for 2.6.24
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Signed-off-by: Marcel Holtmann [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
net: alignment problem in icmp code
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 [EMAIL PROTECTED]
---
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;
signature.asc
Description: PGP signature
Re: [RFD] iptables: mangle table obsoletes filter table
[EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFD] iptables: mangle table obsoletes filter table
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. pgpqsKaExhIYs.pgp Description: PGP signature
Re: Fw: [Bug 9189] New: Oops in kernel 2.6.21-rc4 through 2.6.23, page allocation failure
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 [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
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))
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: net: alignment problem in icmp code
From: Pierre Ossman [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROBLEM: oops, Linus tree: 2.6.23-g4fa4d23f, BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
Guillaume Chazarain wrote: BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 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 0004 [ 4327.550047] printing eip: c02ad991 *pdpt = 06062001 1*pde = [ 4327.550061] Oops: [#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: ecx: 0003 edx: [ 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 0002 0001 c02adaff 0068 c60d97c0 0058 [ 4327.550356] c614f738 c61e2f24 c65c63f0 c61e2f48 c029c87f c61e2fb0 c030642f [ 4327.550374]0001 0246 001a 8005000b fff2 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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
