Sorry, Yinghai. I decided to shutdown for a time because of bad thunderstorms. Here is the requested output: $ dmesg Linux version 2.6.27-rc4.080823.hpet+bar1 (dawitbro@fileserver) (gcc version 4.3.1 (Debian 4.3.1-2) ) #1 SMP Sat Aug 23 15:40:47 EDT 2008 Command line: root=/dev/hda1 ro video=uvesafb:1280x1024-16@60,mtrr:3 fbcon=scrollback:256k,font:10x18 debug initcall_debug hpet=disable KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD Centaur CentaurHauls BIOS-provided ...

This adds USB device IDs for MosChip 7730 and Sitecom LN030 to the mcs7830 driver. The IDs have been reported to work without further modifications. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: David Brownell <david-b@pacbell.net> Cc: Viktor Horvath <ViktorHorvath@gmx.net> Cc: Robbert Wethmar <robbert@wethmar.nl> Cc: Bart van der Klip <bklip@xs4all.nl> --- a/drivers/net/usb/mcs7830.c +++ b/drivers/net/usb/mcs7830.c @@ -46,6 +46,10 @@ #define MCS7830_VENDOR_ID 0x9710 ...

Hello David, and I find the present post to try solving this regression. Regards. --

I found that your patch was supposed to apply beginning at line 1918, but the code in v2.6.27-rc4 that corresponded to the patch actually was located at line 1790. I also found that it would not compile, but was able to fix it... hopefully somewhat as you intended: ======================== diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 9236e7f..7853a05 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -1790,6 +1790,22 @@ ...

Implement set_mac_address for mcs7830. This enables me to use it with my cable modem. Tested (and using it right now) with 2.6.26, tested to compile with 2.6.27-rc4 Signed-off-by: Oliver Martin <oliver.martin@student.tuwien.ac.at> --- linux-2.6.26/drivers/net/usb/mcs7830.c.orig 2008-08-23 01:44:26.000000000 +0200 +++ linux-2.6.26/drivers/net/usb/mcs7830.c 2008-08-23 02:26:28.000000000 +0200 @@ -442,6 +442,29 @@ static struct ethtool_ops mcs7830_ethtoo .nway_reset = usbnet_nway_reset, ...

The conventional usage is to use __u8 for parameters that are being used in a kernel to user ABI interface (like ioctl), and u8 for elements in a structure in a device driver. Most device drivers no longer add entries to pci_ids.h for each device type. This used to be done, but the file was getting too big and the id's only get used in one place. --

tcp: fix tcp header size miscalculation when window scale is unused The size of the TCP header is miscalculated when the window scale ends up being 0. Additionally, this can be induced by sending a SYN to a passive open port with a window scale option with value 0. Signed-off-by: Philip Love <love_phil@emc.com> --- net/ipv4/tcp_output.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index a00532d..71eea00 ...

Oops! My fault. I was composing my reply a bit at a time, adding stuff with each reboot, and couldn't see my inbox had this followup ACK. Personally, if I had champagne here, I'd have popped the cork already. This is the first 2.6.2[67] kernel I've had that can boot without "hpet=ignore" or reverting the 2 commits from February. Here are the messages about ignoring conflicts. The full 'dmesg' output is attached -- gzip'ed because it was over 100K (I used kernel parameters "debug ...

Hi, Sorry for the delay. Yes, no additional patches in both cases: - stock 2.6.27-rc4 from kernel.org - freshly cloned net-next-2.6 after David's announcement Cheers, a+ ps: if you have various ideas you want to test on that issue (additional debug, printks, ...), don't hesitate to send me patches ... --

Hi, Hence the note on hardware similarities of both device outside All Linux 2.6.26 (initial and stable releases) are not affected. I am As I wrote in my previous email, bisecting net-2.6 lead me to 9043476f726802f4b00c96d0c4f418dde48d1304 ([PATCH] sanitize proc_sysctl) which is in the middle of a set of fs/sysctl related patches. I think I am missing the point on what you want me to do. Can you clarify? Thanks for your work. Cheers, a+ --

sorry about that, my first patch was more broken than i thought (it will basically hang on _any_ box), please try the second patch. Note how the above hack code does a stupid goto, and 'p' is updated for the next loop iteration already. The second version of the debug patch only updates 'p' in the 'continue' case and will hopefully get you much further into bootup! Ingo --

Here are some bug fixes: 1) Zebra routing daemon is confused because ipv6 netlink event messages don't set the protocol field properly like ipv4 ones do. Fix from Stephen Hemminger. 2) Insufficient qdisc list locking leads to Qdisc corruption and oops. Fix from Jarek Poplawski. 3) Qdisc watchdog timer can race with dev_deactivate(), put state tests in the slow path to prevent this. Also from Jarek Poplawski. 4) Several SCTP-AUTH sock options are user OOPS'able. Fix ...

Info attached:

David, could you try the debug patch below ontop of latest tip/master: http://people.redhat.com/mingo/tip.git/README the patch forcibly ignores resource conflicts and reports them. This will likely break some system - but if your hpet troubles are due to resource conflicts then this patch would make the kernel boot up fine on your system by default, with a working hpet. You should also be getting a printout and a warning in the dmesg in that case. Ingo ------------> From ...

Very nice and clean and feature-complete! Comments: * the definition of jwrite32() and jread32(): writel() and readl() are defined in terms of the little-endian PCI bus, and therefore automatically handle byteswapping (or not) as defined by the platform API. You should be able to just remove those le32_to_cpu() and the reverse, to obtain proper behavior. * The atomic values rx_cleaning and tx_cleaning look problematic and potentially racy, though I admit not having completely ...

Should I add privilege check, or should(could?) I send a patch that add ethtool interface for flash(For storing PXE code) read/write? Thank you for super-fast reply. --

Attached is a patch against the latest 2.6.27-rc4 kernel. When window scaling is enabled, but the tcp buffer sizes are small, then the tcp SYN packet created will have an incorrect tcp header length. The tcp length is calculated assuming that the window scale option will be inserted into the tcp header, but since the buffer sizes are too small the window scale is not used. Therefore the last 4 bytes of the options in the tcp header are left uninitialized. This can be reproduced by ...

From: Philip Love <love_phil@emc.com> Please submit unified diffs. It's the very first item in linux/Documentation/SubmittingPatches --

please send out after booting with hpet=disable lspci -tv lspci -vvxxx YH --

From: "John W. Linville" <linville@tuxdriver.com> Pulled and pushed out to kernel.org, thanks John! --

From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi> Also applied, thanks a lot Ilpo. --

From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi> Applied. --

On Fri, 22 Aug 2008 17:36:25 -0700 (PDT) And braindead for any other uses (like filtering or forwarding). --

From: Stephen Hemminger <shemminger@vyatta.com> I don't think they want this for performance, they want to not have to compute the IP header checksum in their HW LRO implementation, which is just as silly :-) --

meaningless (and often misleading) once a driver is in the mainline kernel. People will >update the driver without changing the version It gives us a stick to ask vendors to maintain upstream versions of driver code in the distros. While we are at this. I believe that there is not much of a standard for driver versioning. If we automatically get a driver version from the kernel version then it solves both problems. Thoughts ?? Thanks, Shyam --

From: <Shyam_Iyer@Dell.com> It should not be standardized because every driver maintainer works differently, and every driver is developed differently, and therefore has different needs and desires for the version number. All that matters is that the driver version makes sense to the person maintaining the driver, and works for them when reviewing bug reports. Look, what you're suggesting is to change existing practice and that doesn't belong in the discussion of the review of a specific ...

From: <Shyam_Iyer@Dell.com> I totally disagree. I find it very useful when I get a debugging dump from the user and they have no idea where their kernel came from nor can figure out how to determine the kernel version. Sure it might sometimes not get updated for trivial patches that bypass the maintainer, but the maintainer is always going to bump it after non-trivial changes. --

That looks like a problem but it isn't. When you're overriding the default queue selection you're breaking CPU affinity. As such cache-line bouncing is clearly not a concern or you wouldn't be doing this (that is, you're doing this for QOS rather than CPU scalability). So having everything go through a single qdisc shouldn't be a problem. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: ...

As it is if you create a custom qdisc then there will only be a single qdisc no matter how many hardware queues you have. So you can safely dequeue from the qdisc into any hardware queue you want. 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 --

In the case of this scheduler our main focus is QOS and then performance. Basically I was trying to achieve the goal of setting up the queues as needed without forcing a serious change in the current transmit path or seriously impacting performance. I figure since all I am doing is restoring part of what was there for 2.6.26 the I am almost certain that David's approach using the hash will show better performance than the multiqueue prio qdisc would. The multiqueue prio qdisc is meant to ...

I thought about doing just that but then I realized that there would be a number of issues. First if I just set the skb->queue_mapping for the packet without moving it to a qdisc dedicated to that tx queue I run into head-of-line issues since multiple qdiscs will stop if holding packets for a single tx queue that is full. That is over come in this patch by the fact that each qdisc has a specific fifo per tx queue. That issue led me to the thought of creating a redirect action that would ...

We have to modify the existing prio qdisc or create a new qdisc in order to resolve the head-of-line blocking once any of the queues have stopped. The new one wouldn't make any changes to the priority of the packet but instead would only switch it to a separate qdisc based on the queue_mapping of the skb. I get the fact that all we would need is a new action to handle the queue mapping, but in order for that to be an acceptable solution I I think you missed the email from Dave earlier, ...

On Fri, Aug 22, 2008 at 10:12 PM, Herbert Xu It isn't the performance aspect of running everything through one queue that I am concerned about since that is how it was working before. My concern is that the action could cause a dead lock if simple_tx_hash places traffic on 2 queues and then the tc rule tried to swap the traffic between those queues while they are each holding their own queue locks. The tc rule would have to receive all traffic onto a single qdisc to prevent this, which would ...

From: "Alexander Duyck" <alexander.duyck@gmail.com> You really should look at how the current code works before coming to conclusions like this ;-) When you configure any qdisc onto a device using tc, you get a single qdisc which is shared by all of the TXQ objects of the device. The per-TXQ qdisc thing only happens for the default qdisc. --

That case is simple. We never allowed overlapping leaves, and all of the directories had essentially the same permissions. Beyond that I added checks in sysctl_check to make certain we are never out of sync. As for the walking and rewalking I was never fond of it but it was simple and worked. Thanks for looking. The ordering problem is self inflicted as you introduced an ordering constraint where none existed previously, and it seems unnecessary. I'm currently tearing my hair out ...

This is a revision of [PATCH 3/3] submitted a few days ago, correcting the use of a jump label - the control wrongly went to invalid_option when feature negotiation failed. Also tidied the patch up a little to make it easier to review. ----------------------------> Patch v3 <----------------------------- dccp: Process incoming Change feature-negotiation options This adds/replaces code for processing incoming ChangeL/R options. The main difference is that: * mandatory FN options are now ...

Obviously :) Thanks Herbert. --

Endianness is very unlikely to be the cause of that. Order of initialization, OTOH... Can you reproduce it on mainline kernel or bisect between the mainline and net-2.6 if mainline is OK? --

we aren't a commercial shop. This is all being done by volunteers. In which case features arrive in the time and order that the coder(s) do it. Joe -- Joseph Mack NA3T EME(B,D), FM05lw North Carolina jmack (at) wm7d (dot) net - azimuthal equidistant map generator at http://www.wm7d.net/azproj.shtml Homepage http://www.austintek.com/ It's GNU/Linux! --

I agree - having a new sync daemon which can deal with v6 entries aswell as v4 entries would be a good way to work; the legacy code can then be Well, as someone else mentioned on lvs-users recently "I couldn't code my way out of a wet paper bag in C" so I'm not much help on that front, however I feel that getting the minimal working feature set going first and then adding the sync code later is probably a good way to proceed. This also gives us a development timeline that we can offer ...

From: Jarek Poplawski <jarkao2@gmail.com> Yes, I designed it for the future. Nothing really uses this capability currently. --

On Sat, 23 Aug 2008, D