* [PATCH 2.6.25] compilation fix for drivers/net/wireless/libertas/debugfs.c
From: Denis V. Lunev @ 2007-12-27 10:24 UTC (permalink / raw)
To: davem; +Cc: devel, mchan, netdev
Compilation fix. MAC_FMT is required for
drivers/net/wireless/libertas/debugfs.c
The problem has been introduced by the
commit 4b326fa2167d4ee2d722bff4e241fae299e32442
Author: Michael Chan <mchan@broadcom.com>
Date: Mon Dec 24 21:28:09 2007 -0800
diff --git a/include/linux/if_ether.h b/include/linux/if_ether.h
index 7a1e011..2928586 100644
--- a/include/linux/if_ether.h
+++ b/include/linux/if_ether.h
@@ -129,6 +129,7 @@ extern ssize_t sysfs_format_mac(char *buf, const unsigned char *addr, int len);
/*
* Display a 6 byte device address (MAC) in a readable format.
*/
+#define MAC_FMT "%02x:%02x:%02x:%02x:%02x:%02x"
extern char *print_mac(char *buf, const unsigned char *addr);
#define MAC_BUF_SIZE 18
#define DECLARE_MAC_BUF(var) char var[MAC_BUF_SIZE] __maybe_unused
^ permalink raw reply related
* Re: [git patches] net driver fixes
From: Meelis Roos @ 2007-12-27 11:28 UTC (permalink / raw)
To: netdev, Jeff Garzik; +Cc: Stephen Hemminger
JG> A couple [minorly] notable wireless bug fixes, and plenty of viro fixes
JG> for obscure issues :)
What about the tulip NAPI fix from Stephen Hemminger? Without this, my
tulip is hosed easily.
The thread where I reported it was "Badness at net/core/dev.c:2199",
around Dec 16.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [git patches] net driver fixes
From: Jeff Garzik @ 2007-12-27 11:40 UTC (permalink / raw)
To: Meelis Roos; +Cc: netdev, Stephen Hemminger
In-Reply-To: <Pine.SOC.4.64.0712271327030.20202@math.ut.ee>
Meelis Roos wrote:
> JG> A couple [minorly] notable wireless bug fixes, and plenty of viro fixes
> JG> for obscure issues :)
>
> What about the tulip NAPI fix from Stephen Hemminger? Without this, my
> tulip is hosed easily.
>
> The thread where I reported it was "Badness at net/core/dev.c:2199",
> around Dec 16.
That's going up in the first post-Xmas batch.
Jeff
^ permalink raw reply
* netlink_proto_init and sock_init
From: Octavian Purdila @ 2007-12-27 12:48 UTC (permalink / raw)
To: netdev
Hi,
I've noticed that with some exotic build setups (e.g. mingw)
netlink_proto_init is called before sock_init and subsequently sock_alloc
runs into a NULL sock_mnt. The following patch seems to fix the problem, but
I'm not sure if this is the right thing to do, as there are no _initcall_sync
calls in the kernel yet.
Thanks,
tavi
PS: please keep me on CC as I am not subscribed to the list.
Author: Octavian Purdila <tavi@cs.pub.ro>
Date: Thu Dec 27 14:25:31 2007 +0200
sock_init needs to be called before netlink_proto_init, but both
sock_init and netlink_proto_init share the same init level
(core). Move netlink_proto_init to sync core level.
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 1f15821..f69c126 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1845,7 +1845,7 @@ panic:
panic("netlink_init: Cannot allocate nl_table\n");
}
-core_initcall(netlink_proto_init);
+core_initcall_sync(netlink_proto_init);
EXPORT_SYMBOL(netlink_ack);
EXPORT_SYMBOL(netlink_run_queue);
^ permalink raw reply related
* Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
From: Andreas Mohr @ 2007-12-27 17:40 UTC (permalink / raw)
To: Andrew Morton
Cc: David Woodhouse, Eric W. Biederman, Linus Torvalds,
Rafael J. Wysocki, Pavel Machek, kernel list, netdev,
Pavel Emelyanov, Denis V. Lunev
In-Reply-To: <20071207022342.806ee4ee.akpm@linux-foundation.org>
Hi,
On Fri, Dec 07, 2007 at 02:23:42AM -0800, Andrew Morton wrote:
> > (commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416)
> >
> > This seems to have broken the use of /proc/bus/usb as a mountpoint. It
> > always appears empty now, whatever's supposed to be mounted there.
> >
>
> Yes. Denis and Eric are tossing around competing patches but afaik nobody
> is happy with any of them. Guys, could we get this sorted soonish please?
"Soonish" being rather earlier than 20071227?
'cause it's still throwing a fit for me on 2.6.24-rc6-mm1(!) (plus hotfix),
nothing visible in /proc/bus/usb, thus WLAN driver won't probe
anything.
Side note: later upgraded from hotplug-based setup to udev,
but didn't change status quo of problem of empty mount.
Now back again to a 2.6.19ish kernel, since this is the only one
that I could always fall back on after a sizeable number of attempts
to get to run anything newer trouble-free in this environment.
Frankly I'm slightly getting fed up with the number of regressions
I'm hitting in my smallish environment lately. But that's sorta
what you pay for when going experimental.
Just the same day I also had to discover that e100 doesn't usefully
support (IOW, fatal resource probing error) my Intel BNC combo 645477-004,
as opposed to eepro100. Swapped the card from this ""production""
headless box to an easily accessible one for followup debugging of e100.
K6-3@150 headless, Debian stable.
mount 2.12r-19
usbutils 0.72-7
fstab:
none /proc/bus/usb usbfs defaults 0 0
lsmod (NOTE: from 2.6.19-cks2, sorry):
Module Size Used by
act_police 6980 1
sch_ingress 3712 1
cls_u32 7300 5
sch_tbf 6400 1
sch_sfq 5888 4
sch_htb 16128 1
ppp_async 11648 1
crc_ccitt 2304 1 ppp_async
ipt_ULOG 7940 1
xt_state 2304 4
xt_limit 2816 11
xt_tcpudp 3200 48
xt_multiport 3200 10
iptable_mangle 2944 0
iptable_nat 7044 1
iptable_filter 3200 1
ip_tables 12360 3 iptable_mangle,iptable_nat,iptable_filter
ip_nat_tftp 2048 0
ip_conntrack_tftp 4504 1 ip_nat_tftp
ip_nat_h323 7296 0
ip_conntrack_h323 48028 1 ip_nat_h323
ip_nat_irc 2816 0
ip_nat_ftp 3456 0
ip_conntrack_irc 6928 1 ip_nat_irc
ip_conntrack_ftp 7312 1 ip_nat_ftp
ipt_MASQUERADE 3840 1
ip_nat 16684 6 iptable_nat,ip_nat_tftp,ip_nat_h323,ip_nat_irc,ip_nat_ftp,ipt_MASQUERADE
ip_conntrack 43884 12 xt_state,iptable_nat,ip_nat_tftp,ip_conntrack_tftp,ip_nat_h323,ip_conntrack_h323,ip_nat_irc,ip_nat_ftp,ip_conntrack_irc,ip_conntrack_ftp,ipt_MASQUERADE,ip_nat
ipt_REJECT 4608 0
ipt_LOG 6784 11
x_tables 14468 10 ipt_ULOG,xt_state,xt_limit,xt_tcpudp,xt_multiport,iptable_nat,ip_tables,ipt_MASQUERADE,ipt_REJECT,ipt_LOG
isdn 109920 0
sis5595 14472 0
i2c_isa 6528 1 sis5595
at76c503_rfmd 5900 0
firmware_class 9728 1 at76c503_rfmd
i2c_sis5595 8196 0
at76c503 85856 1 at76c503_rfmd
at76_usbdfu 5636 1 at76c503
i2c_sis630 9100 0
i2c_core 22656 4 sis5595,i2c_isa,i2c_sis5595,i2c_sis630
ohci_hcd 31748 0
usbcore 135044 5 at76c503_rfmd,at76c503,at76_usbdfu,ohci_hcd
e100 33800 0
3c59x 41384 0
lspci -v (2.6.19-cks2):
00:00.0 Host bridge: Silicon Integrated Systems [SiS] 5591/5592 Host (rev 02)
Flags: bus master, medium devsel, latency 64
Memory at e8000000 (32-bit, non-prefetchable) [size=64M]
Capabilities: [c0] AGP version 1.0
00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) (prog-if 8a [Master SecP PriP])
Flags: bus master, fast devsel, latency 64, IRQ 14
I/O ports at <ignored>
I/O ports at <ignored>
I/O ports at <ignored>
I/O ports at <ignored>
I/O ports at 4000 [size=16]
00:01.0 ISA bridge: Silicon Integrated Systems [SiS] SiS85C503/5513 (LPC Bridge) (rev 01)
Flags: bus master, medium devsel, latency 0
00:01.1 Class ff00: Silicon Integrated Systems [SiS] ACPI
Flags: medium devsel
00:01.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 11) (prog-if 10 [OHCI])
Flags: bus master, medium devsel, latency 64, IRQ 12
Memory at f0102000 (32-bit, non-prefetchable) [size=4K]
00:02.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: ec000000-edffffff
Prefetchable memory behind bridge: e0000000-e7ffffff
00:09.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)
Subsystem: Intel Corporation EtherExpress PRO/100+ Management Adapter
Flags: bus master, medium devsel, latency 64, IRQ 11
Memory at f0100000 (32-bit, non-prefetchable) [size=4K]
I/O ports at e000 [size=64]
Memory at f0000000 (32-bit, non-prefetchable) [size=1M]
Expansion ROM at ee000000 [disabled] [size=1M]
Capabilities: [dc] Power Management version 2
00:0f.0 Ethernet controller: 3Com Corporation 3c905B Deluxe Etherlink 10/100/BNC [Cyclone]
Subsystem: 3Com Corporation 3c905B Deluxe Etherlink 10/100/BNC [Cyclone]
Flags: bus master, medium devsel, latency 64, IRQ 10
I/O ports at e400 [size=128]
Memory at f0101000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at ef000000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 1
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] (prog-if 00 [VGA])
Subsystem: ATI Technologies Inc Unknown device 110a
Flags: bus master, stepping, 66MHz, medium devsel, latency 64
Memory at e0000000 (32-bit, prefetchable) [size=128M]
I/O ports at d000 [size=256]
Memory at ed000000 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at ec000000 [disabled] [size=128K]
Capabilities: [58] AGP version 2.0
Capabilities: [50] Power Management version 2
Thanks,
Andreas Mohr
^ permalink raw reply
* Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
From: Alexey Dobriyan @ 2007-12-27 18:41 UTC (permalink / raw)
To: Andreas Mohr
Cc: Andrew Morton, David Woodhouse, Eric W. Biederman, Linus Torvalds,
Rafael J. Wysocki, Pavel Machek, kernel list, netdev,
Pavel Emelyanov, Denis V. Lunev
In-Reply-To: <20071227174056.GA17350@rhlx01.hs-esslingen.de>
On Thu, Dec 27, 2007 at 06:40:56PM +0100, Andreas Mohr wrote:
> On Fri, Dec 07, 2007 at 02:23:42AM -0800, Andrew Morton wrote:
> > > (commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416)
> > >
> > > This seems to have broken the use of /proc/bus/usb as a mountpoint. It
> > > always appears empty now, whatever's supposed to be mounted there.
> > >
> >
> > Yes. Denis and Eric are tossing around competing patches but afaik nobody
> > is happy with any of them. Guys, could we get this sorted soonish please?
>
> "Soonish" being rather earlier than 20071227?
> 'cause it's still throwing a fit for me on 2.6.24-rc6-mm1(!) (plus hotfix),
> nothing visible in /proc/bus/usb, thus WLAN driver won't probe
> anything.
Patch which restores usual behaviour was merged in 2.6.24-rc5
(3790ee4bd86396558eedd86faac1052cb782e4e1 "proc: remove/Fix proc generic d_revalidate")
so no hotfixes are needed. I just checked with bind mounting / to
/proc/bus/usb -- it works.
^ permalink raw reply
* [PATCH] [NET] Fixed a small typo in the loopback driver
From: Emil Medve @ 2007-12-27 14:17 UTC (permalink / raw)
To: davem, jgarzik, netdev; +Cc: Emil Medve
This is probably a result of the changes from commit
854d836 - [NET]: Dynamically allocate the loopback device, part 2
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
linux-2.6> scripts/checkpatch.pl 0001-NET-Fixed-a-small-typo-in-the-loopback-driver.patch
total: 0 errors, 0 warnings, 8 lines checked
Your patch has no obvious style problems and is ready for submission.
drivers/net/loopback.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
index 662b8d1..fa147cd 100644
--- a/drivers/net/loopback.c
+++ b/drivers/net/loopback.c
@@ -242,7 +242,7 @@ static void loopback_setup(struct net_device *dev)
| NETIF_F_NO_CSUM
| NETIF_F_HIGHDMA
| NETIF_F_LLTX
- | NETIF_F_NETNS_LOCAL,
+ | NETIF_F_NETNS_LOCAL;
dev->ethtool_ops = &loopback_ethtool_ops;
dev->header_ops = ð_header_ops;
dev->init = loopback_dev_init;
--
1.5.4-rc1.GIT
^ permalink raw reply related
* Re: [RFC] skge csum problems
From: Stephen Hemminger @ 2007-12-27 19:31 UTC (permalink / raw)
To: Al Viro; +Cc: netdev
In-Reply-To: <20071224194523.GA27894@ZenIV.linux.org.uk>
On Mon, 24 Dec 2007 19:45:23 +0000
Al Viro <viro@ZenIV.linux.org.uk> wrote:
> On Mon, Dec 24, 2007 at 11:36:38AM -0800, Stephen Hemminger wrote:
> > > you will get the same behaviour on big- and little-endian boxen, even though
> > > the intermediate integer values will be of course different.
> > >
> > > skb->csum *must* be stored in the same order on l-e and b-e boxen; that
> > > way you don't need to convert it or raw data when updating the sucker [*].
> > >
> > > [*] it's slightly more complicated since skb->csum is 4-byte, not 2-byte
> > > and the real invariant is "checksum of 4-octet array at &skb->csum must
> > > not depend on host" (so e.g XX YY 00 00 and 00 00 XX YY are equivalent -
> > > checksum doesn't change from reordering octet pairs; XX YY 00 00 and
> > > 00 00 YY XX are very definitely *NOT* equivalent; odd and even bytes
> > > can't be exchanged).
> >
> > Did you test this on real hardware?
>
> Test _what_ on real hardware? That kernel expects skb->csum fixed-endian?
> That csum_add() and friends work? Yes to both.
>
> If you are asking whether I'd tested what skge does to csum in its rx
> descriptors when asked to byteswap - as I've said, all skge-handled stuff
> I have is on-board in little-endian boxen. Thus asking for folks who
> could test it on big-endian and see what does that sucker actually do...
I'll wait for 2.6.25 then. I am just concerned about how real hardware
interprets the byte swap PCI flag. I'll see if I can find some cost
competitive bigendian hardware.
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* [PATCH net-2.6.25] CAN: Add missing Kbuild entries
From: Oliver Hartkopp @ 2007-12-27 20:14 UTC (permalink / raw)
To: David Miller; +Cc: Sam Ravnborg, Urs Thuermann, netdev
[-- Attachment #1: Type: text/plain, Size: 289 bytes --]
This patch adds the missing Kbuild entries and the missing Kbuild file
in include/linux/can for the CAN subsystem.
It applies on the current net-2.6.25 tree.
Tnx & best regards,
Oliver
Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
---
[-- Attachment #2: Kbuild-CAN.patch --]
[-- Type: text/x-diff, Size: 967 bytes --]
diff -uprN -X net-2.6.25/Documentation/dontdiff net-2.6.25/include/linux/can/Kbuild export/net2625-2007-12-27/include/linux/can/Kbuild
--- net-2.6.25/include/linux/can/Kbuild 1970-01-01 01:00:00.000000000 +0100
+++ export/net2625-2007-12-27/include/linux/can/Kbuild 2007-12-27 20:35:22.000000000 +0100
@@ -0,0 +1,3 @@
+header-y += raw.h
+header-y += bcm.h
+header-y += error.h
diff -uprN -X net-2.6.25/Documentation/dontdiff net-2.6.25/include/linux/Kbuild export/net2625-2007-12-27/include/linux/Kbuild
--- net-2.6.25/include/linux/Kbuild 2007-12-15 19:33:20.000000000 +0100
+++ export/net2625-2007-12-27/include/linux/Kbuild 2007-12-27 20:35:22.000000000 +0100
@@ -1,4 +1,5 @@
header-y += byteorder/
+header-y += can/
header-y += dvb/
header-y += hdlc/
header-y += isdn/
@@ -41,6 +42,7 @@ header-y += baycom.h
header-y += bfs_fs.h
header-y += blkpg.h
header-y += bpqether.h
+header-y += can.h
header-y += cdk.h
header-y += chio.h
header-y += coda_psdev.h
^ permalink raw reply
* [PATCH net-2.6.25] CAN: Fix plain integer definitions in userspace header & new CAN version 20071227
From: Oliver Hartkopp @ 2007-12-27 20:14 UTC (permalink / raw)
To: David Miller; +Cc: Sam Ravnborg, Urs Thuermann, netdev
[-- Attachment #1: Type: text/plain, Size: 449 bytes --]
This patch fixes the use of plain integers instead of __u32 in a struct
that is visible from kernel space and user space. As this change is user
visible this patch also updates the CAN version to 20071227.
Thanks to Sam Ravnborg for pointing out the wrong plain int usage.
It applies on the current net-2.6.25 tree.
Tnx & best regards,
Oliver
Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
---
[-- Attachment #2: plain_int.patch --]
[-- Type: text/x-diff, Size: 1136 bytes --]
diff -uprN -X net-2.6.25/Documentation/dontdiff net-2.6.25/include/linux/can/bcm.h export/net2625-2007-12-27/include/linux/can/bcm.h
--- net-2.6.25/include/linux/can/bcm.h 2007-12-15 19:33:20.000000000 +0100
+++ export/net2625-2007-12-27/include/linux/can/bcm.h 2007-12-27 20:35:54.000000000 +0100
@@ -26,12 +26,12 @@
* @frames: array of CAN frames.
*/
struct bcm_msg_head {
- int opcode;
- int flags;
- int count;
+ __u32 opcode;
+ __u32 flags;
+ __u32 count;
struct timeval ival1, ival2;
canid_t can_id;
- int nframes;
+ __u32 nframes;
struct can_frame frames[0];
};
diff -uprN -X net-2.6.25/Documentation/dontdiff net-2.6.25/include/linux/can/core.h export/net2625-2007-12-27/include/linux/can/core.h
--- net-2.6.25/include/linux/can/core.h 2007-12-15 19:33:20.000000000 +0100
+++ export/net2625-2007-12-27/include/linux/can/core.h 2007-12-27 20:35:54.000000000 +0100
@@ -19,7 +19,7 @@
#include <linux/skbuff.h>
#include <linux/netdevice.h>
-#define CAN_VERSION "20071116"
+#define CAN_VERSION "20071227"
/* increment this number each time you change some user-space interface */
#define CAN_ABI_VERSION "8"
^ permalink raw reply
* Re: testing crazy stuff with iproute2
From: Jarek Poplawski @ 2007-12-27 21:09 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev
In-Reply-To: <20071226045037.M75814@visp.net.lb>
Denys Fedoryshchenko wrote, On 12/26/2007 05:57 AM:
...
> But i got few times in dmesg, during tests (probably when i set sfq instead
> pfifo, or etc).
>
> [2090816.116000] htb: class 10003 isn't work conserving ?!
>
> Is it a bug? And does it worth to do such "shaper"?
It's not a bug - htb simply wonders the sub-queue has packets,
but doesn't dequeue any when expected. Probably htb + tbf isn't
the most common configuration, but nothing wrong either. You
should only consider htb could do similar (not exactly) job by
itself, and each additional qdisc adds some latency, so it's only
a question of priorities. But, hmm, ...don't you think this
lartc.org's mailing list is really nice?
Regards,
Jarek P.
PS: BTW, maybe I missed this, but I hoped you'd share here some
impressions from testing this new PSPacer scheduler?
^ permalink raw reply
* Re: testing crazy stuff with iproute2
From: Denys Fedoryshchenko @ 2007-12-27 21:25 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <4774146D.1030502@gmail.com>
I will try to talk in lartc, about HTB i wrote another mail...
It is not acting as TBF with burst, it is even acting weird. Probably it is
bug, when traffic get "blocked" cause of burst.
I will try to use lartc, if it is better to not "spam" my stuff here :-)
I didn't try yet PSPacer yet, as ESFQ things. If it is need i can do that and
write feedback. I can use some of them in real environment after some pre-
testing.
On Thu, 27 Dec 2007 22:09:01 +0100, Jarek Poplawski wrote
> Denys Fedoryshchenko wrote, On 12/26/2007 05:57 AM:
> ....
>
> > But i got few times in dmesg, during tests (probably when i set sfq
instead
> > pfifo, or etc).
> >
> > [2090816.116000] htb: class 10003 isn't work conserving ?!
> >
> > Is it a bug? And does it worth to do such "shaper"?
>
> It's not a bug - htb simply wonders the sub-queue has packets,
> but doesn't dequeue any when expected. Probably htb + tbf isn't
> the most common configuration, but nothing wrong either. You
> should only consider htb could do similar (not exactly) job by
> itself, and each additional qdisc adds some latency, so it's only
> a question of priorities. But, hmm, ...don't you think this
> lartc.org's mailing list is really nice?
>
> Regards,
> Jarek P.
>
> PS: BTW, maybe I missed this, but I hoped you'd share here some
> impressions from testing this new PSPacer scheduler?
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
From: Andreas Mohr @ 2007-12-27 22:17 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: Andreas Mohr, Andrew Morton, David Woodhouse, Eric W. Biederman,
Linus Torvalds, Rafael J. Wysocki, Pavel Machek, kernel list,
netdev, Pavel Emelyanov, Denis V. Lunev
In-Reply-To: <20071227184145.GA1831@martell.zuzino.mipt.ru>
Hi,
On Thu, Dec 27, 2007 at 09:41:45PM +0300, Alexey Dobriyan wrote:
> On Thu, Dec 27, 2007 at 06:40:56PM +0100, Andreas Mohr wrote:
> > On Fri, Dec 07, 2007 at 02:23:42AM -0800, Andrew Morton wrote:
> > > > (commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416)
> > > >
> > > > This seems to have broken the use of /proc/bus/usb as a mountpoint. It
> > > > always appears empty now, whatever's supposed to be mounted there.
> > > >
> > >
> > > Yes. Denis and Eric are tossing around competing patches but afaik nobody
> > > is happy with any of them. Guys, could we get this sorted soonish please?
> >
> > "Soonish" being rather earlier than 20071227?
> > 'cause it's still throwing a fit for me on 2.6.24-rc6-mm1(!) (plus hotfix),
> > nothing visible in /proc/bus/usb, thus WLAN driver won't probe
> > anything.
>
> Patch which restores usual behaviour was merged in 2.6.24-rc5
> (3790ee4bd86396558eedd86faac1052cb782e4e1 "proc: remove/Fix proc generic d_revalidate")
Via a kerneltrap.org article (problematic internet setup here currently,
non-C&P text terminal only) I could see that this is the patch which
removes the d_revalidate member and the corresponding proc_revalidate_dentry().
And this is the state that my 2.6.24-rc_six_-mm1 tree is in already.
So either it didn't help here or it broke again by some later change or
there's some dumb PEBKAC error here.
> so no hotfixes are needed. I just checked with bind mounting / to
> /proc/bus/usb -- it works.
OK, I'll try to re-check manual, raw, bare-metal mounting (bind etc.) soonish.
"CONFIG_NETNS" as mentioned in the patch description actually seems
to be "CONFIG_NET_NS", BTW.
(which I DON'T have set at the moment, if this happens to make a difference)
Thanks,
Andreas Mohr
^ permalink raw reply
* Re: testing crazy stuff with iproute2
From: Jarek Poplawski @ 2007-12-27 22:54 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev
In-Reply-To: <20071227212405.M87764@visp.net.lb>
On Thu, Dec 27, 2007 at 11:25:53PM +0200, Denys Fedoryshchenko wrote:
> I will try to talk in lartc, about HTB i wrote another mail...
> It is not acting as TBF with burst, it is even acting weird. Probably it is
> bug, when traffic get "blocked" cause of burst.
HTB was probably projected to be simple, so it has less knobs than CBQ
or TBF. But it shouldn't act weird, unless you do weird things...
E.g. what do you expect with 'rate 8bit'? I think, you should firstly
do some tests with different rates without touching cburst or even
quantum: HTB usually uses workable defaults if rates and packet sizes
are within some limits. End at the beginning I think it's better to
always use 'default' parameter with qdisc, and add some class for this
to verify all traffic is filtered as expected.
> I will try to use lartc, if it is better to not "spam" my stuff here :-)
Maybe you don't believe it, but I really knew much more about properly
setting HTB parameters 2 years ago, when I read lartc or not worse our
local linux networking news group than now - when, this practical
knowledge was mostly erased by some 'useless' inside details.
> I didn't try yet PSPacer yet, as ESFQ things. If it is need i can do that and
> write feedback. I can use some of them in real environment after some pre-
> testing.
It looked like very interesting, so I'm only a bit curious why so
quiet...
Jarek P.
^ permalink raw reply
* Re: testing crazy stuff with iproute2
From: Denys Fedoryshchenko @ 2007-12-27 23:44 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <20071227225455.GA6672@ami.dom.local>
On Thu, 27 Dec 2007 23:54:55 +0100, Jarek Poplawski wrote
> On Thu, Dec 27, 2007 at 11:25:53PM +0200, Denys Fedoryshchenko wrote:
> > I will try to talk in lartc, about HTB i wrote another mail...
> > It is not acting as TBF with burst, it is even acting weird. Probably it
is
> > bug, when traffic get "blocked" cause of burst.
>
> HTB was probably projected to be simple, so it has less knobs than
> CBQ or TBF. But it shouldn't act weird, unless you do weird things...
> E.g. what do you expect with 'rate 8bit'? I think, you should
> firstly do some tests with different rates without touching cburst
> or even quantum: HTB usually uses workable defaults if rates and
> packet sizes are within some limits. End at the beginning I think
> it's better to always use 'default' parameter with qdisc, and add
> some class for this to verify all traffic is filtered as expected.
It is just to make ceil thing there is no bandwidth available. I know that
parents in theory must be equal or more than childs sum and etc. About
strange cburst/burst i will explain in next part.
>
> > I will try to use lartc, if it is better to not "spam" my stuff here :-)
>
> Maybe you don't believe it, but I really knew much more about
> properly setting HTB parameters 2 years ago, when I read lartc or
> not worse our local linux networking news group than now - when,
> this practical knowledge was mostly erased by some 'useless' inside details.
For bandwidth sharing it is perfect, but i want just to make things, which i
did with TBF - some time bursty speed, and then slow down to lower speed if
customer is using too much. In theory it has to work like this, but in
practice i am hitting wall. I tried it about 1 year ago, it was same thing,
just with another conditions. Seems cburst/burst a bit different thing, just
to make load on CPU by HTB less , at high speeds.
>
> > I didn't try yet PSPacer yet, as ESFQ things. If it is need i can do that
and
> > write feedback. I can use some of them in real environment after some pre-
> > testing.
>
> It looked like very interesting, so I'm only a bit curious why so
> quiet...
On my experience people don't like much talking on mails, sending bug reports
and etc. I know a lot of people who have kernel panic, oops issues, and who
don't know what to do, just to blame "linux". Now i am trying to help them
and also to help improve linux this way.
For me personally more interesting right now ESFQ way. Just i am scared to
put in producting patches not from mainline, cause then on issues i cannot
write proper bugreport.
>
> Jarek P.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.
^ permalink raw reply
* Re: netlink_proto_init and sock_init
From: David Miller @ 2007-12-28 0:41 UTC (permalink / raw)
To: tavi; +Cc: netdev
In-Reply-To: <200712271448.57008.tavi@cs.pub.ro>
From: Octavian Purdila <tavi@cs.pub.ro>
Date: Thu, 27 Dec 2007 14:48:56 +0200
> I've noticed that with some exotic build setups (e.g. mingw)
> netlink_proto_init is called before sock_init and subsequently sock_alloc
> runs into a NULL sock_mnt. The following patch seems to fix the problem, but
> I'm not sure if this is the right thing to do, as there are no _initcall_sync
> calls in the kernel yet.
This means that net/netlink/ got linked before net/socket.o, which
should never happen. net/Makefile reads:
obj-$(CONFIG_NET) := socket.o core/
...
obj-$(CONFIG_NET) += ethernet/ 802/ sched/ netlink/
Which ensures that net/socket.o comes before linking in the
net/netlink/built-in.o object file.
Init call ordering is based upon link ordering, so it looks like
mingw is somehow reordering the object files being linked.
There are many other things that can go wrong if the build environment
does this, please find a way to get your mingw build environment to
not do this.
^ permalink raw reply
* Re: [PATCH 2.6.25] compilation fix for drivers/net/wireless/libertas/debugfs.c
From: David Miller @ 2007-12-28 0:45 UTC (permalink / raw)
To: den; +Cc: devel, mchan, netdev
In-Reply-To: <20071227102454.GA14163@iris.sw.ru>
From: "Denis V. Lunev" <den@openvz.org>
Date: Thu, 27 Dec 2007 13:24:54 +0300
> Compilation fix. MAC_FMT is required for
> drivers/net/wireless/libertas/debugfs.c
Putting this public macro back into a header file just
for one driver's debug handling is just rediculious.
I've checked in the following fix instead, thanks.
commit f7b4d3b86615b95b104ca0a95902ca86373a6548
Author: David S. Miller <davem@davemloft.net>
Date: Thu Dec 27 16:43:38 2007 -0800
[LIBERTAS]: Remove last stray user of MAC_FMT.
Reported by Denis V. Lunev
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/drivers/net/wireless/libertas/debugfs.c b/drivers/net/wireless/libertas/debugfs.c
index 0bda0b5..95dd4ed 100644
--- a/drivers/net/wireless/libertas/debugfs.c
+++ b/drivers/net/wireless/libertas/debugfs.c
@@ -243,7 +243,8 @@ static void libertas_parse_bssid(char *buf, size_t count,
if (!hold)
return;
hold += 6;
- sscanf(hold, MAC_FMT, mac, mac+1, mac+2, mac+3, mac+4, mac+5);
+ sscanf(hold, "%02x:%02x:%02x:%02x:%02x:%02x",
+ mac, mac+1, mac+2, mac+3, mac+4, mac+5);
memcpy(scan_cfg->bssid, mac, ETH_ALEN);
}
^ permalink raw reply related
* Re: [PATCH net-2.6.25] CAN: Fix plain integer definitions in userspace header & new CAN version 20071227
From: David Miller @ 2007-12-28 0:49 UTC (permalink / raw)
To: oliver; +Cc: sam, urs, netdev
In-Reply-To: <477407C1.1050405@hartkopp.net>
From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Thu, 27 Dec 2007 21:14:57 +0100
> This patch fixes the use of plain integers instead of __u32 in a struct
> that is visible from kernel space and user space. As this change is user
> visible this patch also updates the CAN version to 20071227.
>
> Thanks to Sam Ravnborg for pointing out the wrong plain int usage.
>
> It applies on the current net-2.6.25 tree.
The types are exactly the same size regardless of anything.
There is no reason to make such a big fuss about this, changing the
CAN version etc.
Also, since CAN has never shown up in a released kernel, there is
nothing to be incompatible with.
Finally, once CAN is in fact in a released kernel, you can't make
incompatible changes to the userland visible structures. They are
going to be fixed in stone.
Therefore I'm going to check this in without all the version
changes.
Thanks.
^ permalink raw reply
* Re: [PATCH net-2.6.25] CAN: Fix plain integer definitions in userspace header & new CAN version 20071227
From: David Miller @ 2007-12-28 0:50 UTC (permalink / raw)
To: oliver; +Cc: sam, urs, netdev
In-Reply-To: <477407C1.1050405@hartkopp.net>
From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Thu, 27 Dec 2007 21:14:57 +0100
> diff -uprN -X net-2.6.25/Documentation/dontdiff net-2.6.25/include/linux/can/bcm.h export/net2625-2007-12-27/include/linux/can/bcm.h
> --- net-2.6.25/include/linux/can/bcm.h 2007-12-15 19:33:20.000000000 +0100
> +++ export/net2625-2007-12-27/include/linux/can/bcm.h 2007-12-27 20:35:54.000000000 +0100
Also, please properly root your patches in the future:
davem@sunset:~/src/GIT/net-2.6.25$ git apply --check --whitespace=error-all diff
error: net2625-2007-12-27/include/linux/can/bcm.h: No such file or directory
Thanks.
^ permalink raw reply
* Re: [PATCH net-2.6.25] CAN: Add missing Kbuild entries
From: David Miller @ 2007-12-28 0:52 UTC (permalink / raw)
To: oliver; +Cc: sam, urs, netdev
In-Reply-To: <477407BD.1040406@hartkopp.net>
From: Oliver Hartkopp <oliver@hartkopp.net>
Date: Thu, 27 Dec 2007 21:14:53 +0100
> This patch adds the missing Kbuild entries and the missing Kbuild file
> in include/linux/can for the CAN subsystem.
>
> It applies on the current net-2.6.25 tree.
>
> Tnx & best regards,
> Oliver
>
> Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
Applied, but I had to fixup the patch to be rooted properly
like the other one.
Thanks.
^ permalink raw reply
* Re: fib6_del_route has redundant code
From: David Miller @ 2007-12-28 5:18 UTC (permalink / raw)
To: guijianfeng; +Cc: netdev, linux-kernel
In-Reply-To: <477353B6.6000102@cn.fujitsu.com>
From: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Date: Thu, 27 Dec 2007 15:26:46 +0800
> I think the following code in fib6_del_route in the latest kernel is useless.
> 1125 if (fn->leaf == NULL && fn->fn_flags&RTN_TL_ROOT)
> 1126 fn->leaf = &ip6_null_entry;
>
> ip6_null_entry will never be unlinked from fn->leaf now, that is,
> fn->leaf == NULL will never meet.
I think you are right, but if it is true the next block of
code is dead too:
/* If it was last route, expunge its radix tree node */
if (fn->leaf == NULL) {
fn->fn_flags &= ~RTN_RTINFO;
rt6_stats.fib_route_nodes--;
fn = fib6_repair_tree(fn);
}
But I am not completely convinced that all of these lines
of code can be removed :-)
^ permalink raw reply
* (unknown)
From: Li Yewang @ 2007-12-28 5:31 UTC (permalink / raw)
To: netdev
subscribe netdev
^ permalink raw reply
* Re: fib6_del_route has redundant code
From: Gui Jianfeng @ 2007-12-28 5:58 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel
In-Reply-To: <20071227.211808.221171928.davem@davemloft.net>
>> I think the following code in fib6_del_route in the latest kernel is useless.
>> 1125 if (fn->leaf == NULL && fn->fn_flags&RTN_TL_ROOT)
>> 1126 fn->leaf = &ip6_null_entry;
>>
>> ip6_null_entry will never be unlinked from fn->leaf now, that is,
>> fn->leaf == NULL will never meet.
>
> I think you are right, but if it is true the next block of
> code is dead too:
>
> /* If it was last route, expunge its radix tree node */
> if (fn->leaf == NULL) {
> fn->fn_flags &= ~RTN_RTINFO;
> rt6_stats.fib_route_nodes--;
> fn = fib6_repair_tree(fn);
> }
>
Dave,
I think this block of code can't be removed, because just the root(default route)
fn->leaf always has ip6_null_entry on it. The normal fn->leaf becomes NULL when last
route has been deleted, the radix tree should be expunged.
> But I am not completely convinced that all of these lines
> of code can be removed :-)
>
>
--
Regards
Gui Jianfeng
--------------------------------------------------
Gui Jianfeng
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
8/F., Civil Defense Building, No.189 Guangzhou Road,
Nanjing, 210029, China
TEL: +86+25-86630566-838
COINS: 79955-838
FAX: +86+25-83317685
MAIL:guijianfeng@cn.fujitsu.com
--------------------------------------------------
^ permalink raw reply
* Re: [PATCH 2.6.24-rc3] Fix /proc/net breakage
From: Alexey Dobriyan @ 2007-12-28 6:22 UTC (permalink / raw)
To: Andreas Mohr
Cc: Andrew Morton, David Woodhouse, Eric W. Biederman, Linus Torvalds,
Rafael J. Wysocki, Pavel Machek, kernel list, netdev,
Pavel Emelyanov, Denis V. Lunev
In-Reply-To: <20071227221728.GA17379@rhlx01.hs-esslingen.de>
On Thu, Dec 27, 2007 at 11:17:28PM +0100, Andreas Mohr wrote:
> Hi,
>
> On Thu, Dec 27, 2007 at 09:41:45PM +0300, Alexey Dobriyan wrote:
> > On Thu, Dec 27, 2007 at 06:40:56PM +0100, Andreas Mohr wrote:
> > > On Fri, Dec 07, 2007 at 02:23:42AM -0800, Andrew Morton wrote:
> > > > > (commit 2b1e300a9dfc3196ccddf6f1d74b91b7af55e416)
> > > > >
> > > > > This seems to have broken the use of /proc/bus/usb as a mountpoint. It
> > > > > always appears empty now, whatever's supposed to be mounted there.
> > > > >
> > > >
> > > > Yes. Denis and Eric are tossing around competing patches but afaik nobody
> > > > is happy with any of them. Guys, could we get this sorted soonish please?
> > >
> > > "Soonish" being rather earlier than 20071227?
> > > 'cause it's still throwing a fit for me on 2.6.24-rc6-mm1(!) (plus hotfix),
> > > nothing visible in /proc/bus/usb, thus WLAN driver won't probe
> > > anything.
> >
> > Patch which restores usual behaviour was merged in 2.6.24-rc5
> > (3790ee4bd86396558eedd86faac1052cb782e4e1 "proc: remove/Fix proc generic d_revalidate")
>
> Via a kerneltrap.org article (problematic internet setup here currently,
> non-C&P text terminal only) I could see that this is the patch which
> removes the d_revalidate member and the corresponding proc_revalidate_dentry().
> And this is the state that my 2.6.24-rc_six_-mm1 tree is in already.
OK.
> So either it didn't help here or it broke again by some later change or
> there's some dumb PEBKAC error here.
Do you by chance forgot CONFIG_USB_?HCI_HCD=y ? I see empty usbfs here if
they are deselected.
> > so no hotfixes are needed. I just checked with bind mounting / to
> > /proc/bus/usb -- it works.
>
> OK, I'll try to re-check manual, raw, bare-metal mounting (bind etc.) soonish.
>
> "CONFIG_NETNS" as mentioned in the patch description actually seems
> to be "CONFIG_NET_NS", BTW.
> (which I DON'T have set at the moment, if this happens to make a difference)
I shouldn't.
^ permalink raw reply
* [PATCH] remove useless code from fib6_del_route
From: Gui Jianfeng @ 2007-12-28 7:12 UTC (permalink / raw)
To: netdev; +Cc: David Miller
Hi Dave,
There are useless codes in fib6_del_route(). The following patch
has been tested, every thing looks fine, as usual.
Signed-off-by: Gui Jianfeng<guijianfeng@cn.fujitsu.com>
---
net/ipv6/ip6_fib.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ip6_fib.c b/net/ipv6/ip6_fib.c
index 946cf38..5f96eb1 100644
--- a/net/ipv6/ip6_fib.c
+++ b/net/ipv6/ip6_fib.c
@@ -1122,9 +1122,6 @@ static void fib6_del_route(struct fib6_node *fn, struct rt6_info **rtp,
rt->u.dst.rt6_next = NULL;
- if (fn->leaf == NULL && fn->fn_flags&RTN_TL_ROOT)
- fn->leaf = &ip6_null_entry;
-
/* If it was last route, expunge its radix tree node */
if (fn->leaf == NULL) {
fn->fn_flags &= ~RTN_RTINFO;
--
Regards
Gui Jianfeng
^ permalink raw reply related
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