* Re: [PATCH 2.6.24-mm1] error compiling net driver NE2000/NE1000
From: Pierre Peiffer @ 2008-02-18 15:04 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev, Alan Cox
In-Reply-To: <20080204131038.699c28c1.akpm@linux-foundation.org>
Hi,
I don't know if I have to warn on this or not, but as I didn't find any
discussion, it's probably better to mention it: the compiling error reported
below (or here: http://lkml.org/lkml/2008/2/4/173 ) does not seem to be
corrected in 2.6.25-rc2.mm1... So, I don't know if a fix is going on somewhere
or if the bug has fallen in a black hole.
(In the original mail, I've proposed a patch as a quick fix, but I don't know if
it can be considered as a definitive correction or not)
Thanks,
P.
Andrew Morton wrote:
> On Mon, 4 Feb 2008 16:29:21 +0100
> Pierre Peiffer <pierre.peiffer@bull.net> wrote:
>
>> Hi,
>>
>> When I compile the kernel 2.6.24-mm1 with:
>> CONFIG_NET_ISA=y
>> CONFIG_NE2000=y
>>
>> I have the following compile error:
>> ...
>> GEN .version
>> CHK include/linux/compile.h
>> UPD include/linux/compile.h
>> CC init/version.o
>> LD init/built-in.o
>> LD .tmp_vmlinux1
>> drivers/built-in.o: In function `ne_block_output':
>> linux-2.6.24-mm1/drivers/net/ne.c:797: undefined reference to `NS8390_init'
>> drivers/built-in.o: In function `ne_drv_resume':
>> linux-2.6.24-mm1/drivers/net/ne.c:858: undefined reference to `NS8390_init'
>> drivers/built-in.o: In function `ne_probe1':
>> linux-2.6.24-mm1/drivers/net/ne.c:539: undefined reference to `NS8390_init'
>> make[1]: *** [.tmp_vmlinux1] Error 1
>> make: *** [sub-make] Error 2
>
> Thanks for reporting this.
>
>> As I saw that the file 8390p.c is compiled for this driver, but not the file
>> 8390.c which contains this function NS8390_init(), I fixed this error with
>> the following patch.
>
> Alan's
> 8390-split-8390-support-into-a-pausing-and-a-non-pausing-driver-core.patch
> would be a prime suspect. I assume this bug isn't present ing mainline or
> in 2.6.24?
>
>> As NS8390p_init() does the same thing than NS8390_init(), I suppose that this is the right fix ?
>>
>> Signed-off-by: Pierre Peiffer <pierre.peiffer@bull.net>
>> ---
>> drivers/net/ne.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> Index: b/drivers/net/ne.c
>> ===================================================================
>> --- a/drivers/net/ne.c
>> +++ b/drivers/net/ne.c
>> @@ -536,7 +536,7 @@ static int __init ne_probe1(struct net_d
>> #ifdef CONFIG_NET_POLL_CONTROLLER
>> dev->poll_controller = eip_poll;
>> #endif
>> - NS8390_init(dev, 0);
>> + NS8390p_init(dev, 0);
>>
>> ret = register_netdev(dev);
>> if (ret)
>> @@ -794,7 +794,7 @@ retry:
>> if (time_after(jiffies, dma_start + 2*HZ/100)) { /* 20ms */
>> printk(KERN_WARNING "%s: timeout waiting for Tx RDC.\n", dev->name);
>> ne_reset_8390(dev);
>> - NS8390_init(dev,1);
>> + NS8390p_init(dev,1);
>> break;
>> }
>>
>> @@ -855,7 +855,7 @@ static int ne_drv_resume(struct platform
>>
>> if (netif_running(dev)) {
>> ne_reset_8390(dev);
>> - NS8390_init(dev, 1);
>> + NS8390p_init(dev, 1);
>> netif_device_attach(dev);
>> }
>> return 0;
>
>
>
>
--
Pierre Peiffer
^ permalink raw reply
* Re: ipv6 debugging
From: Jorge Boncompte [DTI2] @ 2008-02-18 15:02 UTC (permalink / raw)
To: Ferenc Wagner, netdev
In-Reply-To: <87zltyjr50.fsf@tac.ki.iif.hu>
This sounds to me like the same problem that I was having with OSPF, I
think ARP(6) uses multicast ethernet address too. Can you try if the patch
below, that I sent Patrick McHardy some days ago, fixes your problem?
Regards,
Jorge
---
Hi Patrick,
Commit a0a400d79e3dd7843e7e81baa3ef2957bdc292d0 from you
introduced a new field "da_synced" to struct dev_addr_list that is
not properly initialized to 0. So when any of the current users (8021q,
macvlan, mac80211) calls dev_mc_sync/unsync they mess the address
list for both devices.
The attached patch fixed it for me and avoid future problems.
Regards,
Jorge
Signed-off-by: Jorge Boncompte [DTI2] jorge@dti2.net
---
diff --git a/net/core/dev.c b/net/core/dev.c
index 9549417..f1b6708 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2900,7 +2900,7 @@ int __dev_addr_add(struct dev_addr_list **list, int
*count,
}
}
- da = kmalloc(sizeof(*da), GFP_ATOMIC);
+ da = kzalloc(sizeof(*da), GFP_ATOMIC);
if (da == NULL)
return -ENOMEM;
memcpy(da->da_addr, addr, alen);
----- Original Message -----
From: "Ferenc Wagner" <wferi@niif.hu>
To: <netdev@vger.kernel.org>
Sent: Monday, February 18, 2008 3:06 PM
Subject: ipv6 debugging
> Hi,
>
> I'm kindly asking for some debugging tips with the following problem:
> a machine is running Linux 2.6.24.2, several 802.1q VLAN-s over
> active/backup bonding over two physical interfaces. Everything is
> allright, except for after a reboot, there's no IPv6, while IPv4
> works. The router's ARP(6) table is empty, the machine doesn't answer
> ping6. However, if I start tcpdump -i bond0 ip6, everything is
> allright again. There are some indications that after some period
> without IPv6 traffic, the same can happen again. Are there known
> issues which can exhibit themselves like this? Other very similar
> setups don't show this erratic behaviour.
>
> I know that the above doesn't give a fully detailed picture, but
> thought that I'd better ask before taking the setup into pieces.
> --
> Thanks for your thoughts,
> Feri.
> --
> 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
>
^ permalink raw reply related
* Re: [2.6 patch] remove include/linux/netfilter_ipv4/ipt_SAME.h
From: Patrick McHardy @ 2008-02-18 15:10 UTC (permalink / raw)
To: Adrian Bunk; +Cc: David S. Miller, linux-kernel, netdev
In-Reply-To: <20080217083031.GY3848@cs181133002.pp.htv.fi>
Adrian Bunk wrote:
> This patch removes the no longer used include/linux/netfilter_ipv4/ipt_SAME.h
We kept it around because old iptables binaries need it to build.
The kernel no longer supports it, but people might still wish to
use a distributor-built iptables binary with old kernels. It will
be removed with a number of other headers kept for compatibility
in 1-2 years.
^ permalink raw reply
* Re: [PATCH] net/8021q/vlan_dev.c - Use print_mac
From: Patrick McHardy @ 2008-02-18 15:19 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, bruno, netdev, jgarzik, linux-wireless, linville
In-Reply-To: <1203097370.21308.18.camel@localhost>
Joe Perches wrote:
> On Fri, 2008-02-15 at 02:58 -0800, David Miller wrote:
>> From: Bruno Randolf <bruno@thinktube.com>
>> Date: Fri, 15 Feb 2008 19:48:05 +0900
>>> is there any chance to include a macro like this for printing mac
>> addresses?
>>> its advantage is that it can be used without the need to declare
>> buffers for
>>> print_mac(), for example:
>> We specifically removed this sort of thing, please don't
>> add it back.
Why?
> @@ -404,11 +405,8 @@ static int vlan_dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
>
> pr_debug("%s: about to send skb: %p to dev: %s\n",
> __FUNCTION__, skb, skb->dev->name);
> - pr_debug(" " MAC_FMT " " MAC_FMT " %4hx %4hx %4hx\n",
> - veth->h_dest[0], veth->h_dest[1], veth->h_dest[2],
> - veth->h_dest[3], veth->h_dest[4], veth->h_dest[5],
> - veth->h_source[0], veth->h_source[1], veth->h_source[2],
> - veth->h_source[3], veth->h_source[4], veth->h_source[5],
> + pr_debug(" %s %s %4hx %4hx %4hx\n",
> + print_mac(mac, veth->h_dest), print_mac(mac2, veth->h_source),
This results in print_mac getting called twice per packet even without
debugging. Whats the problem with MAC_FMT?
^ permalink raw reply
* "protocol 0300 is buggy" spam in dmesg when injecting&capturing on same interface
From: Pekka Pietikainen @ 2008-02-18 15:39 UTC (permalink / raw)
To: netdev
When playing with some L2 level fuzzing I started getting lots of
"protocol 0300 is buggy, dev eth3" spew in dmesg. That interface is also
capturing the traffic that's being sent, that's probably why the
dev_queue_xmit_nit codepath is getting called in the first place.
Tested on 2.6.23-as-shipped-in-F8. didn't spot any relevant changes in .24
but can pretty easily verify there too.
Oh. That printk wasn't very easy to find:
if (net_ratelimit())
printk(KERN_CRIT "protocol %04x is "
"buggy, dev %s\n",
and I naturally grepped for "is buggy".
Any ideas? Add a "If it came from AF_PACKET, don't print out anything" to
that if-statement?
^ permalink raw reply
* Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x
From: Ondrej Zary @ 2008-02-18 16:40 UTC (permalink / raw)
To: Grant Grundler; +Cc: jgarzik, Linux Kernel, netdev
In-Reply-To: <20080218032111.GA7970@colo.lackof.org>
On Monday 18 February 2008 04:21:11 Grant Grundler wrote:
> On Wed, Jan 30, 2008 at 09:23:06PM +0100, Ondrej Zary wrote:
> > On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:
> > > Hello,
> > > I was having problems with these FreedomLine cards with Linux before
> > > but tested it thoroughly today. This card uses DEC 21041 chip and has
> > > TP and BNC connectors:
> > >
> > > 00:12.0 Ethernet controller [0200]: Digital Equipment Corporation
> > > DECchip 21041 [Tulip Pass 3] [1011:0014] (rev 21)
> > >
> > >
> > > de2104x driver was loaded automatically by udev and card seemed to
> > > work. Until I disconnected the TP cable and putting it back after a
> > > while. The driver then switched to (non-existing) AUI port and remained
> > > there. I tried to set media to TP using ethtool - and the whole kernel
> > > crashed because of BUG_ON(de_is_running(de));
> > > in de_set_media(). Seems that the driver is unable to stop the DMA in
> > > de_stop_rxtx().
>
> The BUG_ON() is probably fine normally. But the media selection sounds
> broken. It's possible to select the wrong media type with 21040 chip but
> shouldn't be possible with 21041. For 21040 support, see
> de21040_get_media_info(). But de21041_get_srom_info() is expected to
> determine which media
> types are supported from SEPROM "media blocks". My guess is that code
> is broken since it seems to work with de405 driver. If you care to
> work the difference, I'd be happy to make a patch to fix that up.
I don't think that BUG_ON() should be there. It should probably printk a
warning but certainly not crash the whole machine.
> Also, from code review, DE2104X driver still has a few places with
> potential PCI MMIO Write posting issues. Specifically, I was looking
> in de_stop_hw() and de_set_media(). Several other bits of code correctly
> flush MMIO writes: e.g. tulip_read_eeprom().
>
> > > I commented out AUI detection in the driver - this time it switched to
> > > BNC after unplugging the cable and remained there. I also attempted to
> > > reset the chip when de_stop_rxtx failed but failed to do it.
>
> You'd have to basically hardcode only one media type and it's corresponding
> parameters.
That's bad. It just works with de4x5 with any cable at any time.
> > > Then I found that there's de4x5 driver which supports the same cards as
> > > de2104x (and some other too) - and this one works fine! I can plug and
> > > unplug the cable and even change between TP and BNC ports just by
> > > unplugging one and plugging the other cable in. Unfortunately, this
> > > driver is blacklisted by default - at least in Slackware and Debian.
>
> ISTR there was a time when tulip would compete with de4x5 for devices.
> tulip is the preferred driver. That's clearly no longer the case
> and perhaps both distro's need to revisit this.
de4x5 has no MODULE_DEVICE_TABLE for PCI devices anymore, so no conflicts.
That's probably good for cards that work with tulip driver but bad for mine
card and also probably for some other cards that (should) work with de2104x.
>
> > > The question is: why does de2104x exist? Does it work better with some
> > > hardware?
>
> de2104x is a "work in progress".
> That's why it's marked "EXPERIMENTAL" in the Kconfig file.
Great, it looks to be 6 years old and it's still experimental. Probably
because it never worked properly.
I think that de2104x driver should be removed (or at least its
MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041 PCI
IDs added to de4x5.
I can send a patch if this is acceptable.
>
> > > BTW. Found that the problem exist at least since 2003:
> > > http://oss.sgi.com/archives/netdev/2003-08/msg00951.html
> >
> > Does the de2104x driver work correctly for anyone?
>
> No idea. I've only used tulip driver.
>
> thanks for the bug report,
> grant
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Ondrej Zary
^ permalink raw reply
* Re: [PATCH 1/3] fib_trie: move statistics to debugfs
From: Stephen Hemminger @ 2008-02-18 16:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20080217.222655.262637827.davem@davemloft.net>
On Sun, 17 Feb 2008 22:26:55 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Wed, 13 Feb 2008 11:58:06 -0800
>
> > Don't want /proc/net/fib_trie and /proc/net/fib_triestat to become
> > permanent kernel space ABI issues, so move to the safer confines of debugfs.
> >
> > Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> Stephen, the cat is already out of the bag. We already export this
> thing so if you want to export different stuff you'll have to provide
> it via some other means, somewhere else.
>
> Thanks.
Are we stuck with the format problems?
* crappy tree printout
* not printing other tables
^ permalink raw reply
* Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
From: Stephen Hemminger @ 2008-02-18 16:53 UTC (permalink / raw)
To: Andrew Morton; +Cc: Chris Rankin, linux-acpi, linux-kernel, netdev
In-Reply-To: <20080218050049.12bcc596.akpm@linux-foundation.org>
On Mon, 18 Feb 2008 05:00:49 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Sun, 17 Feb 2008 00:54:08 +0000 (GMT) Chris Rankin <rankincj@yahoo.com> wrote:
>
> > [Try this again, except this time I'll force the attachment as inline text!]
> >
> > Hi,
> >
> > I have managed to boot 2.6.24.1 on this machine, with the NMI watchdog enabled, by using the
> > "acpi=noirq" option. (There does seem to be some unhappiness with bridge symlinks in sysfs,
> > though.)
> >
> > ...
> >
> > sysfs: duplicate filename 'bridge' can not be created
> > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> > [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> > [<c0105990>] show_trace+0x12/0x14
> > [<c010613d>] dump_stack+0x6c/0x72
> > [<c01991bf>] sysfs_add_one+0x57/0xbc
> > [<c0199e41>] sysfs_create_link+0xc2/0x10d
> > [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> > [<c034016c>] pci_legacy_init+0x56/0xe3
> > [<c03274e1>] kernel_init+0x157/0x2c3
> > [<c0104c83>] kernel_thread_helper+0x7/0x10
> > =======================
> > pci 0000:00:01.0: Error creating sysfs bridge symlink, continuing...
> > sysfs: duplicate filename 'bridge' can not be created
> > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> > [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> > [<c0105990>] show_trace+0x12/0x14
> > [<c010613d>] dump_stack+0x6c/0x72
> > [<c01991bf>] sysfs_add_one+0x57/0xbc
> > [<c0199e41>] sysfs_create_link+0xc2/0x10d
> > [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> > [<c01bae82>] pci_bus_add_devices+0xa5/0x103
> > [<c034016c>] pci_legacy_init+0x56/0xe3
> > [<c03274e1>] kernel_init+0x157/0x2c3
> > [<c0104c83>] kernel_thread_helper+0x7/0x10
> > =======================
>
> I have a vague feeling that this was fixed, perhaps in 2.6.24.x?
Never heard of this, what is the initialization script that causes this?
Also do you have the SYSFS_DEPRECATED option configured? that caused issues
with regular network drivers.
^ permalink raw reply
* Re: tbench regression in 2.6.25-rc1
From: Valdis.Kletnieks @ 2008-02-18 17:33 UTC (permalink / raw)
To: Zhang, Yanmin; +Cc: David Miller, dada1, herbert, linux-kernel, netdev
In-Reply-To: <1203322358.3027.200.camel@ymzhang>
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
On Mon, 18 Feb 2008 16:12:38 +0800, "Zhang, Yanmin" said:
> I also think __refcnt is the key. I did a new testing by adding 2 unsigned long
> pading before lastuse, so the 3 members are moved to next cache line. The performance is
> recovered.
>
> How about below patch? Almost all performance is recovered with the new patch.
>
> Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>
Could you add a comment someplace that says "refcnt wants to be on a different
cache line from input/output/ops or performance tanks badly", to warn some
future kernel hacker who starts adding new fields to the structure?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* keyboard dead with 45b5035
From: Pierre Ossman @ 2008-02-18 17:53 UTC (permalink / raw)
To: Laszlo Attila Toth, netdev, LKML
The patch "[RTNETLINK]: Send a single notification on device state changes." kills (at least) the keyboard here. Everything seems to work fine in single user mode, but when init starts spawning of logins, the keyboard goes bye-bye. Even the power button is ignored. :/
I've tried just creating another vt with "chvt 2", but that is insufficient to trigger the bug.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
^ permalink raw reply
* Re: [PATHCH 1/16] ServerEngines 10Gb NIC driver
From: Subbu Seetharaman @ 2008-02-18 18:00 UTC (permalink / raw)
To: netdev; +Cc: shemminger, jacliburn, sam
Thanks for all comments.
I had run checkpatch and corrected all errors excepting a
few errors about some macros and the warning about the
typedefs. The mail client I used to send the patch folded
lines at arbitrary points introduced several trailing white
space. This was also the reason for one of the patch not
applying clean. We will use git to generate the patches
as suggested.
Our desire to share common code across drivers for other
OSes has been a cause for some ugliness in coding styles.
I have one question about bit fields. Several of
headers in the common code are generated by
srcgen from f/w source files. Some of the structures
in these headers have bit fields (with separate definitions
for little endian and big endian hosts). Are these un-acceptable
in Linux driver submissions ?
Thanks.
Subbu
--------------------------------------
From: Stephen Hemminger [mailto:shemminger@linux-foundation.org]
To: netdev@vger.kernel.org
Sent: Sun, 17 Feb 2008 09:44:45 -0800
Subject: Re: [PATHCH 1/16] ServerEngines 10Gb NIC driver
Do all vendor drivers have to come in with the same mistakes.
Where is the vendor driver ugly school, and how can the Linux
developers teach there?
Run this through checkpatch script or just read some of the
things that a quick scan shows.
<snip>
___________________________________________________________________________________
This message, together with any attachment(s), contains confidential and proprietary information of
ServerEngines Corporation and is intended only for the designated recipient(s) named above. Any unauthorized
review, printing, retention, copying, disclosure or distribution is strictly prohibited. If you are not the
intended recipient of this message, please immediately advise the sender by reply email message and
delete all copies of this message and any attachment(s). Thank you.
^ permalink raw reply
* Re: [2.6.25-rc2] e100: Trying to free already-free IRQ 11 during suspend ...
From: Andrey Borzenkov @ 2008-02-18 18:01 UTC (permalink / raw)
To: Andrew Morton; +Cc: e1000-devel, netdev, linux-kernel
In-Reply-To: <20080218050113.1b4b0897.akpm@linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 3128 bytes --]
On Monday 18 February 2008, Andrew Morton wrote:
> On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov <arvidjaar@mail.ru> wrote:
>
> > ... and possibly reboot/poweroff (it flows by too fast to be legible).
> >
> > [ 8803.850634] ACPI: Preparing to enter system sleep state S3
> > [ 8803.853141] Suspending console(s)
> > [ 8805.287505] serial 00:09: disabled
> > [ 8805.291564] Trying to free already-free IRQ 11
> > [ 8805.291579] Pid: 6920, comm: pm-suspend Not tainted 2.6.25-rc2-1avb #2
> > [ 8805.291628] [<c0152127>] free_irq+0xb7/0x130
> > [ 8805.291675] [<c024bd80>] e100_suspend+0xc0/0x100
> > [ 8805.291724] [<c01eaa36>] pci_device_suspend+0x26/0x70
> > [ 8805.291747] [<c0243674>] suspend_device+0x94/0xd0
> > [ 8805.291763] [<c02439a3>] device_suspend+0x153/0x240
> > [ 8805.291784] [<c014314f>] suspend_devices_and_enter+0x4f/0xf0
> > [ 8805.291808] [<c0143a5f>] ? freeze_processes+0x3f/0x80
> > [ 8805.291825] [<c01432fa>] enter_state+0xaa/0x140
> > [ 8805.291840] [<c014341f>] state_store+0x8f/0xd0
> > [ 8805.291852] [<c0143390>] ? state_store+0x0/0xd0
> > [ 8805.291866] [<c01d3404>] kobj_attr_store+0x24/0x30
> > [ 8805.291901] [<c01b547b>] sysfs_write_file+0xbb/0x110
> > [ 8805.291936] [<c0177d79>] vfs_write+0x99/0x130
> > [ 8805.291963] [<c01b53c0>] ? sysfs_write_file+0x0/0x110
> > [ 8805.291979] [<c01782fd>] sys_write+0x3d/0x70
> > [ 8805.291998] [<c010409a>] sysenter_past_esp+0x5f/0xa5
> > [ 8805.292038] =======================
> > [ 8805.347640] ACPI: PCI interrupt for device 0000:00:06.0 disabled
> > [ 8805.361128] ACPI: PCI interrupt for device 0000:00:02.0 disabled
> > [ 8805.376670] hwsleep-0322 [00] enter_sleep_state : Entering sleep state [S3]
> > [ 8805.376670] Back to C!
> >
> > Interface is unused normally (only for netconsole sometimes). dmesg and config
> > attached.
>
> Does reverting this:
>
> commit 8543da6672b0994921f014f2250e27ae81645580
[...]
> fix it?
>
no
> > Hmm ... after resume device has disappeared at all ...
> >
> > {pts/1}% cat /proc/interrupts
> > CPU0
> > 0: 1290492 XT-PIC-XT timer
> > 1: 6675 XT-PIC-XT i8042
> > 2: 0 XT-PIC-XT cascade
> > 3: 2 XT-PIC-XT
> > 4: 2 XT-PIC-XT
> > 5: 3 XT-PIC-XT
> > 7: 4 XT-PIC-XT irda0
> > 8: 0 XT-PIC-XT rtc0
> > 9: 583 XT-PIC-XT acpi
> > 10: 2 XT-PIC-XT
> > 11: 31483 XT-PIC-XT yenta, yenta, yenta, ohci_hcd:usb1, ALI 5451, pcmcia0.0
> > 12: 28070 XT-PIC-XT i8042
> > 14: 21705 XT-PIC-XT ide0
> > 15: 82123 XT-PIC-XT ide1
> > NMI: 0 Non-maskable interrupts
> > TRM: 0 Thermal event interrupts
> > SPU: 0 Spurious interrupts
> > ERR: 0
>
> I hope that's not a separate bug...
>
>
this is red herring. pm-utils restart network across suspend; eth0 is not
activated automatically so it "disappears". ifconfig eth0 up brings it back.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] tlan: add static to function definitions
From: Harvey Harrison @ 2008-02-18 18:04 UTC (permalink / raw)
To: Jeff Garzik, Samuel Chessman; +Cc: LKML, linux-netdev
The forward declarations were already marked static, make the definitions
be static as well. Fixes the sparse warnings as well.
drivers/net/tlan.c:1403:5: warning: symbol 'TLan_HandleInvalid' was not declared. Should it be static?
drivers/net/tlan.c:1435:5: warning: symbol 'TLan_HandleTxEOF' was not declared. Should it be static?
drivers/net/tlan.c:1521:5: warning: symbol 'TLan_HandleStatOverflow' was not declared. Should it be static?
drivers/net/tlan.c:1557:5: warning: symbol 'TLan_HandleRxEOF' was not declared. Should it be static?
drivers/net/tlan.c:1692:5: warning: symbol 'TLan_HandleDummy' was not declared. Should it be static?
drivers/net/tlan.c:1722:5: warning: symbol 'TLan_HandleTxEOC' was not declared. Should it be static?
drivers/net/tlan.c:1770:5: warning: symbol 'TLan_HandleStatusCheck' was not declared. Should it be static?
drivers/net/tlan.c:1845:5: warning: symbol 'TLan_HandleRxEOC' was not declared. Should it be static?
drivers/net/tlan.c:1905:6: warning: symbol 'TLan_Timer' was not declared. Should it be static?
drivers/net/tlan.c:1986:6: warning: symbol 'TLan_ResetLists' was not declared. Should it be static?
drivers/net/tlan.c:2046:6: warning: symbol 'TLan_FreeLists' was not declared. Should it be static?
drivers/net/tlan.c:2095:6: warning: symbol 'TLan_PrintDio' was not declared. Should it be static?
drivers/net/tlan.c:2130:6: warning: symbol 'TLan_PrintList' was not declared. Should it be static?
drivers/net/tlan.c:2166:6: warning: symbol 'TLan_ReadAndClearStats' was not declared. Should it be static?
drivers/net/tlan.c:2242:1: warning: symbol 'TLan_ResetAdapter' was not declared. Should it be static?
drivers/net/tlan.c:2328:1: warning: symbol 'TLan_FinishReset' was not declared. Should it be static?
drivers/net/tlan.c:2451:6: warning: symbol 'TLan_SetMac' was not declared. Should it be static?
drivers/net/tlan.c:2493:6: warning: symbol 'TLan_PhyPrint' was not declared. Should it be static?
drivers/net/tlan.c:2542:6: warning: symbol 'TLan_PhyDetect' was not declared. Should it be static?
drivers/net/tlan.c:2589:6: warning: symbol 'TLan_PhyPowerDown' was not declared. Should it be static?
drivers/net/tlan.c:2614:6: warning: symbol 'TLan_PhyPowerUp' was not declared. Should it be static?
drivers/net/tlan.c:2635:6: warning: symbol 'TLan_PhyReset' was not declared. Should it be static?
drivers/net/tlan.c:2663:6: warning: symbol 'TLan_PhyStartLink' was not declared. Should it be static?
drivers/net/tlan.c:2750:6: warning: symbol 'TLan_PhyFinishAutoNeg' was not declared. Should it be static?
drivers/net/tlan.c:2906:5: warning: symbol 'TLan_MiiReadReg' was not declared. Should it be static?
drivers/net/tlan.c:2996:6: warning: symbol 'TLan_MiiSendData' was not declared. Should it be static?
drivers/net/tlan.c:3038:6: warning: symbol 'TLan_MiiSync' was not declared. Should it be static?
drivers/net/tlan.c:3077:6: warning: symbol 'TLan_MiiWriteReg' was not declared. Should it be static?
drivers/net/tlan.c:3147:6: warning: symbol 'TLan_EeSendStart' was not declared. Should it be static?
drivers/net/tlan.c:3187:5: warning: symbol 'TLan_EeSendByte' was not declared. Should it be static?
drivers/net/tlan.c:3248:6: warning: symbol 'TLan_EeReceiveByte' was not declared. Should it be static?
drivers/net/tlan.c:3306:5: warning: symbol 'TLan_EeReadByte' was not declared. Should it be static?
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
---
Kept the style consistent with the rest of the file, checkpatch will complain.
drivers/net/tlan.c | 64 ++++++++++++++++++++++++++--------------------------
1 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/net/tlan.c b/drivers/net/tlan.c
index 3af5b92..0166407 100644
--- a/drivers/net/tlan.c
+++ b/drivers/net/tlan.c
@@ -1400,7 +1400,7 @@ static void TLan_SetMulticastList( struct net_device *dev )
*
**************************************************************/
-u32 TLan_HandleInvalid( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleInvalid( struct net_device *dev, u16 host_int )
{
/* printk( "TLAN: Invalid interrupt on %s.\n", dev->name ); */
return 0;
@@ -1432,7 +1432,7 @@ u32 TLan_HandleInvalid( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleTxEOF( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleTxEOF( struct net_device *dev, u16 host_int )
{
TLanPrivateInfo *priv = netdev_priv(dev);
int eoc = 0;
@@ -1518,7 +1518,7 @@ u32 TLan_HandleTxEOF( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleStatOverflow( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleStatOverflow( struct net_device *dev, u16 host_int )
{
TLan_ReadAndClearStats( dev, TLAN_RECORD );
@@ -1554,7 +1554,7 @@ u32 TLan_HandleStatOverflow( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleRxEOF( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleRxEOF( struct net_device *dev, u16 host_int )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u32 ack = 0;
@@ -1689,7 +1689,7 @@ u32 TLan_HandleRxEOF( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleDummy( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleDummy( struct net_device *dev, u16 host_int )
{
printk( "TLAN: Test interrupt on %s.\n", dev->name );
return 1;
@@ -1719,7 +1719,7 @@ u32 TLan_HandleDummy( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleTxEOC( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleTxEOC( struct net_device *dev, u16 host_int )
{
TLanPrivateInfo *priv = netdev_priv(dev);
TLanList *head_list;
@@ -1767,7 +1767,7 @@ u32 TLan_HandleTxEOC( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleStatusCheck( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleStatusCheck( struct net_device *dev, u16 host_int )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u32 ack;
@@ -1842,7 +1842,7 @@ u32 TLan_HandleStatusCheck( struct net_device *dev, u16 host_int )
*
**************************************************************/
-u32 TLan_HandleRxEOC( struct net_device *dev, u16 host_int )
+static u32 TLan_HandleRxEOC( struct net_device *dev, u16 host_int )
{
TLanPrivateInfo *priv = netdev_priv(dev);
dma_addr_t head_list_phys;
@@ -1902,7 +1902,7 @@ u32 TLan_HandleRxEOC( struct net_device *dev, u16 host_int )
*
**************************************************************/
-void TLan_Timer( unsigned long data )
+static void TLan_Timer( unsigned long data )
{
struct net_device *dev = (struct net_device *) data;
TLanPrivateInfo *priv = netdev_priv(dev);
@@ -1983,7 +1983,7 @@ void TLan_Timer( unsigned long data )
*
**************************************************************/
-void TLan_ResetLists( struct net_device *dev )
+static void TLan_ResetLists( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
int i;
@@ -2043,7 +2043,7 @@ void TLan_ResetLists( struct net_device *dev )
} /* TLan_ResetLists */
-void TLan_FreeLists( struct net_device *dev )
+static void TLan_FreeLists( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
int i;
@@ -2092,7 +2092,7 @@ void TLan_FreeLists( struct net_device *dev )
*
**************************************************************/
-void TLan_PrintDio( u16 io_base )
+static void TLan_PrintDio( u16 io_base )
{
u32 data0, data1;
int i;
@@ -2127,7 +2127,7 @@ void TLan_PrintDio( u16 io_base )
*
**************************************************************/
-void TLan_PrintList( TLanList *list, char *type, int num)
+static void TLan_PrintList( TLanList *list, char *type, int num)
{
int i;
@@ -2163,7 +2163,7 @@ void TLan_PrintList( TLanList *list, char *type, int num)
*
**************************************************************/
-void TLan_ReadAndClearStats( struct net_device *dev, int record )
+static void TLan_ReadAndClearStats( struct net_device *dev, int record )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u32 tx_good, tx_under;
@@ -2238,7 +2238,7 @@ void TLan_ReadAndClearStats( struct net_device *dev, int record )
*
**************************************************************/
-void
+static void
TLan_ResetAdapter( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
@@ -2324,7 +2324,7 @@ TLan_ResetAdapter( struct net_device *dev )
-void
+static void
TLan_FinishReset( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
@@ -2448,7 +2448,7 @@ TLan_FinishReset( struct net_device *dev )
*
**************************************************************/
-void TLan_SetMac( struct net_device *dev, int areg, char *mac )
+static void TLan_SetMac( struct net_device *dev, int areg, char *mac )
{
int i;
@@ -2490,7 +2490,7 @@ void TLan_SetMac( struct net_device *dev, int areg, char *mac )
*
********************************************************************/
-void TLan_PhyPrint( struct net_device *dev )
+static void TLan_PhyPrint( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 i, data0, data1, data2, data3, phy;
@@ -2539,7 +2539,7 @@ void TLan_PhyPrint( struct net_device *dev )
*
********************************************************************/
-void TLan_PhyDetect( struct net_device *dev )
+static void TLan_PhyDetect( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 control;
@@ -2586,7 +2586,7 @@ void TLan_PhyDetect( struct net_device *dev )
-void TLan_PhyPowerDown( struct net_device *dev )
+static void TLan_PhyPowerDown( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 value;
@@ -2611,7 +2611,7 @@ void TLan_PhyPowerDown( struct net_device *dev )
-void TLan_PhyPowerUp( struct net_device *dev )
+static void TLan_PhyPowerUp( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 value;
@@ -2632,7 +2632,7 @@ void TLan_PhyPowerUp( struct net_device *dev )
-void TLan_PhyReset( struct net_device *dev )
+static void TLan_PhyReset( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 phy;
@@ -2660,7 +2660,7 @@ void TLan_PhyReset( struct net_device *dev )
-void TLan_PhyStartLink( struct net_device *dev )
+static void TLan_PhyStartLink( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 ability;
@@ -2747,7 +2747,7 @@ void TLan_PhyStartLink( struct net_device *dev )
-void TLan_PhyFinishAutoNeg( struct net_device *dev )
+static void TLan_PhyFinishAutoNeg( struct net_device *dev )
{
TLanPrivateInfo *priv = netdev_priv(dev);
u16 an_adv;
@@ -2903,7 +2903,7 @@ void TLan_PhyMonitor( struct net_device *dev )
*
**************************************************************/
-int TLan_MiiReadReg( struct net_device *dev, u16 phy, u16 reg, u16 *val )
+static int TLan_MiiReadReg( struct net_device *dev, u16 phy, u16 reg, u16 *val )
{
u8 nack;
u16 sio, tmp;
@@ -2993,7 +2993,7 @@ int TLan_MiiReadReg( struct net_device *dev, u16 phy, u16 reg, u16 *val )
*
**************************************************************/
-void TLan_MiiSendData( u16 base_port, u32 data, unsigned num_bits )
+static void TLan_MiiSendData( u16 base_port, u32 data, unsigned num_bits )
{
u16 sio;
u32 i;
@@ -3035,7 +3035,7 @@ void TLan_MiiSendData( u16 base_port, u32 data, unsigned num_bits )
*
**************************************************************/
-void TLan_MiiSync( u16 base_port )
+static void TLan_MiiSync( u16 base_port )
{
int i;
u16 sio;
@@ -3074,7 +3074,7 @@ void TLan_MiiSync( u16 base_port )
*
**************************************************************/
-void TLan_MiiWriteReg( struct net_device *dev, u16 phy, u16 reg, u16 val )
+static void TLan_MiiWriteReg( struct net_device *dev, u16 phy, u16 reg, u16 val )
{
u16 sio;
int minten;
@@ -3144,7 +3144,7 @@ void TLan_MiiWriteReg( struct net_device *dev, u16 phy, u16 reg, u16 val )
*
**************************************************************/
-void TLan_EeSendStart( u16 io_base )
+static void TLan_EeSendStart( u16 io_base )
{
u16 sio;
@@ -3184,7 +3184,7 @@ void TLan_EeSendStart( u16 io_base )
*
**************************************************************/
-int TLan_EeSendByte( u16 io_base, u8 data, int stop )
+static int TLan_EeSendByte( u16 io_base, u8 data, int stop )
{
int err;
u8 place;
@@ -3245,7 +3245,7 @@ int TLan_EeSendByte( u16 io_base, u8 data, int stop )
*
**************************************************************/
-void TLan_EeReceiveByte( u16 io_base, u8 *data, int stop )
+static void TLan_EeReceiveByte( u16 io_base, u8 *data, int stop )
{
u8 place;
u16 sio;
@@ -3303,7 +3303,7 @@ void TLan_EeReceiveByte( u16 io_base, u8 *data, int stop )
*
**************************************************************/
-int TLan_EeReadByte( struct net_device *dev, u8 ee_addr, u8 *data )
+static int TLan_EeReadByte( struct net_device *dev, u8 ee_addr, u8 *data )
{
int err;
TLanPrivateInfo *priv = netdev_priv(dev);
--
1.5.4.1.1278.gc75be
^ permalink raw reply related
* Re: [PATCH] net/8021q/vlan_dev.c - Use print_mac
From: Joe Perches @ 2008-02-18 18:31 UTC (permalink / raw)
To: Patrick McHardy
Cc: David Miller, bruno-L9ZBdB2wSWtl57MIdRCFDg,
netdev-u79uwXL29TY76Z2rM5mHXA, jgarzik-e+AXbWqSrlAAvxtiuMwx3w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <47B9A20C.10304-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
On Mon, 2008-02-18 at 16:19 +0100, Patrick McHardy wrote:
> > @@ -404,11 +405,8 @@ static int vlan_dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
> >
> > pr_debug("%s: about to send skb: %p to dev: %s\n",
> > __FUNCTION__, skb, skb->dev->name);
> > - pr_debug(" " MAC_FMT " " MAC_FMT " %4hx %4hx %4hx\n",
> > - veth->h_dest[0], veth->h_dest[1], veth->h_dest[2],
> > - veth->h_dest[3], veth->h_dest[4], veth->h_dest[5],
> > - veth->h_source[0], veth->h_source[1], veth->h_source[2],
> > - veth->h_source[3], veth->h_source[4], veth->h_source[5],
> > + pr_debug(" %s %s %4hx %4hx %4hx\n",
> > + print_mac(mac, veth->h_dest), print_mac(mac2, veth->h_source),
> This results in print_mac getting called twice per packet even without
> debugging. Whats the problem with MAC_FMT?
It's just a consistency thing.
It identifies code where MAC addresses are used.
an allyesconfig is a bit smaller (~.1%).
pr_debug is a noop when not debugging, print_mac is optimized away.
^ permalink raw reply
* Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
From: Chris Rankin @ 2008-02-18 19:42 UTC (permalink / raw)
To: Stephen Hemminger, Andrew Morton; +Cc: linux-acpi, linux-kernel, netdev
In-Reply-To: <20080218085333.3d32b626@extreme>
--- Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> > > sysfs: duplicate filename 'bridge' can not be created
> > > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > > Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> > > [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> > > [<c0105990>] show_trace+0x12/0x14
> > > [<c010613d>] dump_stack+0x6c/0x72
> > > [<c01991bf>] sysfs_add_one+0x57/0xbc
> > > [<c0199e41>] sysfs_create_link+0xc2/0x10d
> > > [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> > > [<c034016c>] pci_legacy_init+0x56/0xe3
> > > [<c03274e1>] kernel_init+0x157/0x2c3
> > > [<c0104c83>] kernel_thread_helper+0x7/0x10
> > > =======================
> > > pci 0000:00:01.0: Error creating sysfs bridge symlink, continuing...
> > > sysfs: duplicate filename 'bridge' can not be created
> > > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > > Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> > > [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> > > [<c0105990>] show_trace+0x12/0x14
> > > [<c010613d>] dump_stack+0x6c/0x72
> > > [<c01991bf>] sysfs_add_one+0x57/0xbc
> > > [<c0199e41>] sysfs_create_link+0xc2/0x10d
> > > [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> > > [<c01bae82>] pci_bus_add_devices+0xa5/0x103
> > > [<c034016c>] pci_legacy_init+0x56/0xe3
> > > [<c03274e1>] kernel_init+0x157/0x2c3
> > > [<c0104c83>] kernel_thread_helper+0x7/0x10
> > > =======================
> >
> > I have a vague feeling that this was fixed, perhaps in 2.6.24.x?
>
> Never heard of this, what is the initialization script that causes this?
> Also do you have the SYSFS_DEPRECATED option configured? that caused issues
> with regular network drivers.
Yes, SYSFS_DEPRECATED is enabled. And the init scripts are from Fedora 8.
Cheers,
Chris
__________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com
^ permalink raw reply
* Re: keyboard dead with 45b5035
From: Rafael J. Wysocki @ 2008-02-18 19:50 UTC (permalink / raw)
To: Pierre Ossman; +Cc: Laszlo Attila Toth, netdev, LKML
In-Reply-To: <20080218185305.48a67587@mjolnir.drzeus.cx>
On Monday, 18 of February 2008, Pierre Ossman wrote:
> The patch "[RTNETLINK]: Send a single notification on device state changes." kills (at least)
> the keyboard here. Everything seems to work fine in single user mode, but when init starts
> spawning of logins, the keyboard goes bye-bye. Even the power button is ignored. :/
Please try with the patch from http://lkml.org/lkml/2008/2/18/331 .
Thanks,
Rafael
^ permalink raw reply
* Re: Linux 2.6.24.1 - kernel does not boot; IRQ trouble?
From: Stephen Hemminger @ 2008-02-18 20:06 UTC (permalink / raw)
To: Chris Rankin; +Cc: Andrew Morton, linux-acpi, linux-kernel, netdev
In-Reply-To: <395400.45093.qm@web52907.mail.re2.yahoo.com>
On Mon, 18 Feb 2008 19:42:25 +0000 (GMT)
Chris Rankin <rankincj@yahoo.com> wrote:
> --- Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> > > > sysfs: duplicate filename 'bridge' can not be created
> > > > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > > > Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> > > > [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> > > > [<c0105990>] show_trace+0x12/0x14
> > > > [<c010613d>] dump_stack+0x6c/0x72
> > > > [<c01991bf>] sysfs_add_one+0x57/0xbc
> > > > [<c0199e41>] sysfs_create_link+0xc2/0x10d
> > > > [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> > > > [<c034016c>] pci_legacy_init+0x56/0xe3
> > > > [<c03274e1>] kernel_init+0x157/0x2c3
> > > > [<c0104c83>] kernel_thread_helper+0x7/0x10
> > > > =======================
> > > > pci 0000:00:01.0: Error creating sysfs bridge symlink, continuing...
> > > > sysfs: duplicate filename 'bridge' can not be created
> > > > WARNING: at fs/sysfs/dir.c:424 sysfs_add_one()
> > > > Pid: 1, comm: swapper Not tainted 2.6.24.1 #1
> > > > [<c0105020>] show_trace_log_lvl+0x1a/0x2f
> > > > [<c0105990>] show_trace+0x12/0x14
> > > > [<c010613d>] dump_stack+0x6c/0x72
> > > > [<c01991bf>] sysfs_add_one+0x57/0xbc
> > > > [<c0199e41>] sysfs_create_link+0xc2/0x10d
> > > > [<c01bae9a>] pci_bus_add_devices+0xbd/0x103
> > > > [<c01bae82>] pci_bus_add_devices+0xa5/0x103
> > > > [<c034016c>] pci_legacy_init+0x56/0xe3
> > > > [<c03274e1>] kernel_init+0x157/0x2c3
> > > > [<c0104c83>] kernel_thread_helper+0x7/0x10
> > > > =======================
> > >
> > > I have a vague feeling that this was fixed, perhaps in 2.6.24.x?
> >
> > Never heard of this, what is the initialization script that causes this?
> > Also do you have the SYSFS_DEPRECATED option configured? that caused issues
> > with regular network drivers.
>
> Yes, SYSFS_DEPRECATED is enabled. And the init scripts are from Fedora 8.
There was a bug (fixed in 2.6.24) that had to do with sysfs_create_link
and SYSFS_DEPRECATED probably there is a similar problem with directories.
^ permalink raw reply
* [PATCH 1/1] sis190: read the mac address from the eeprom first
From: Francois Romieu @ 2008-02-18 20:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Andrew Morton, dsd, Gabriel A. Devenyi
Reading a serie of zero from the cmos sram area do not work
well with is_valid_ether_addr(). Let's read the mac address
from the eeprom first as it seems more reliable.
Fix for http://bugzilla.kernel.org/show_bug.cgi?id=9831
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
---
drivers/net/sis190.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/sis190.c b/drivers/net/sis190.c
index 202fdf3..20745fd 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -1633,13 +1633,18 @@ static inline void sis190_init_rxfilter(struct net_device *dev)
static int __devinit sis190_get_mac_addr(struct pci_dev *pdev,
struct net_device *dev)
{
- u8 from;
+ int rc;
+
+ rc = sis190_get_mac_addr_from_eeprom(pdev, dev);
+ if (rc < 0) {
+ u8 reg;
- pci_read_config_byte(pdev, 0x73, &from);
+ pci_read_config_byte(pdev, 0x73, ®);
- return (from & 0x00000001) ?
- sis190_get_mac_addr_from_apc(pdev, dev) :
- sis190_get_mac_addr_from_eeprom(pdev, dev);
+ if (reg & 0x00000001)
+ rc = sis190_get_mac_addr_from_apc(pdev, dev);
+ }
+ return rc;
}
static void sis190_set_speed_auto(struct net_device *dev)
--
1.5.3.3
^ permalink raw reply related
* Re: keyboard dead with 45b5035
From: Pierre Ossman @ 2008-02-18 20:50 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Laszlo Attila Toth, netdev, LKML
In-Reply-To: <200802182050.01964.rjw@sisk.pl>
On Mon, 18 Feb 2008 20:50:01 +0100
"Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> On Monday, 18 of February 2008, Pierre Ossman wrote:
> > The patch "[RTNETLINK]: Send a single notification on device state changes." kills (at least)
> > the keyboard here. Everything seems to work fine in single user mode, but when init starts
> > spawning of logins, the keyboard goes bye-bye. Even the power button is ignored. :/
>
> Please try with the patch from http://lkml.org/lkml/2008/2/18/331 .
>
That solved it.
I wonder if that's also why modprobe tends to wedge up with the new USB announce thingy... Tomorrow's debugging will tell.
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
^ permalink raw reply
* Re: [PATCH] net/8021q/vlan_dev.c - Use print_mac
From: David Miller @ 2008-02-18 20:55 UTC (permalink / raw)
To: kaber; +Cc: joe, bruno, netdev, jgarzik, linux-wireless, linville
In-Reply-To: <47B9A20C.10304@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Mon, 18 Feb 2008 16:19:40 +0100
> Joe Perches wrote:
> > On Fri, 2008-02-15 at 02:58 -0800, David Miller wrote:
> >> From: Bruno Randolf <bruno@thinktube.com>
> >> Date: Fri, 15 Feb 2008 19:48:05 +0900
> >>> is there any chance to include a macro like this for printing mac
> >> addresses?
> >>> its advantage is that it can be used without the need to declare
> >> buffers for
> >>> print_mac(), for example:
> >> We specifically removed this sort of thing, please don't
> >> add it back.
>
> Why?
We converted the entire tree over the print_mac(), and since
the MAC_FMT stuff was therefore no longer used we could
remove it.
Some references slipped back in somehow, and thus MAC_FMT
did too.
There is no reason to keep around a global interface for
_one_ user when that user can use the recommended interface
just as equally as the rest of the tree which we converted.
This is a pr_debug() statement we're talking about here.
:-)
^ permalink raw reply
* Re: [PATCH] net/8021q/vlan_dev.c - Use print_mac
From: Patrick McHardy @ 2008-02-18 21:17 UTC (permalink / raw)
To: David Miller
Cc: joe-6d6DIl74uiNBDgjK7y7TUQ, bruno-L9ZBdB2wSWtl57MIdRCFDg,
netdev-u79uwXL29TY76Z2rM5mHXA, jgarzik-e+AXbWqSrlAAvxtiuMwx3w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <20080218.125525.192686382.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller wrote:
> From: Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
> Date: Mon, 18 Feb 2008 16:19:40 +0100
>
>
>> Joe Perches wrote:
>>
>>>
>>>> We specifically removed this sort of thing, please don't
>>>> add it back.
>>>>
>> Why?
>>
>
> We converted the entire tree over the print_mac(), and since
> the MAC_FMT stuff was therefore no longer used we could
> remove it.
>
> Some references slipped back in somehow, and thus MAC_FMT
> did too.
>
> There is no reason to keep around a global interface for
> _one_ user when that user can use the recommended interface
> just as equally as the rest of the tree which we converted.
>
> This is a pr_debug() statement we're talking about here.
> :-)
>
The way pr_debug is implemented it still results in two function
calls per packet since the compiler doesn't know that it doesn't
have visible side-effects besides modifying the (unused) buffer.
I confirmed this using codiff.
^ permalink raw reply
* [PATCH] net: fix kernel-doc warnings in header files
From: Randy Dunlap @ 2008-02-18 21:26 UTC (permalink / raw)
To: netdev; +Cc: davem
From: Randy Dunlap <randy.dunlap@oracle.com>
Add missing structure kernel-doc descriptions to sock.h & skbuff.h
to fix kernel-doc warnings.
(I think that Stephen H. sent a similar patch, but I can't find it.
I just want to kill the warnings, with either patch.)
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
include/linux/skbuff.h | 2 ++
include/net/sock.h | 1 +
2 files changed, 3 insertions(+)
--- linux-2625-rc1g4-kdoc.orig/include/linux/skbuff.h
+++ linux-2625-rc1g4-kdoc/include/linux/skbuff.h
@@ -232,6 +232,8 @@ typedef unsigned char *sk_buff_data_t;
* @mark: Generic packet mark
* @nfct: Associated connection, if any
* @ipvs_property: skbuff is owned by ipvs
+ * @peeked: this packet has been seen already, so stats have been
+ * done for it, don't do them again
* @nf_trace: netfilter packet trace flag
* @nfctinfo: Relationship of this skb to the connection
* @nfct_reasm: netfilter conntrack re-assembly pointer
--- linux-2625-rc1g4-kdoc.orig/include/net/sock.h
+++ linux-2625-rc1g4-kdoc/include/net/sock.h
@@ -180,6 +180,7 @@ struct sock_common {
* @sk_sndmsg_off: cached offset for sendmsg
* @sk_send_head: front of stuff to transmit
* @sk_security: used by security modules
+ * @sk_mark: generic packet mark
* @sk_write_pending: a write to stream socket waits to start
* @sk_state_change: callback to indicate change in the state of the sock
* @sk_data_ready: callback to indicate there is data to be processed
^ permalink raw reply
* Re: [PATCH] net/8021q/vlan_dev.c - Use print_mac
From: Patrick McHardy @ 2008-02-18 21:31 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, bruno-L9ZBdB2wSWtl57MIdRCFDg,
netdev-u79uwXL29TY76Z2rM5mHXA, jgarzik-e+AXbWqSrlAAvxtiuMwx3w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <1203359462.7181.80.camel@localhost>
Joe Perches wrote:
> On Mon, 2008-02-18 at 16:19 +0100, Patrick McHardy wrote:
>
>>> @@ -404,11 +405,8 @@ static int vlan_dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev)
>>>
>>> pr_debug("%s: about to send skb: %p to dev: %s\n",
>>> __FUNCTION__, skb, skb->dev->name);
>>> - pr_debug(" " MAC_FMT " " MAC_FMT " %4hx %4hx %4hx\n",
>>> - veth->h_dest[0], veth->h_dest[1], veth->h_dest[2],
>>> - veth->h_dest[3], veth->h_dest[4], veth->h_dest[5],
>>> - veth->h_source[0], veth->h_source[1], veth->h_source[2],
>>> - veth->h_source[3], veth->h_source[4], veth->h_source[5],
>>> + pr_debug(" %s %s %4hx %4hx %4hx\n",
>>> + print_mac(mac, veth->h_dest), print_mac(mac2, veth->h_source),
>>>
>> This results in print_mac getting called twice per packet even without
>> debugging. Whats the problem with MAC_FMT?
>>
>
> It's just a consistency thing.
> It identifies code where MAC addresses are used.
>
> an allyesconfig is a bit smaller (~.1%).
> pr_debug is a noop when not debugging, print_mac is optimized away.
>
No its not, which I also stated in the commit message that restored
it.
0x0000000060244313 <vlan_dev_hard_start_xmit+433>: callq
0x60161dbd <print_mac>
0x0000000060244318 <vlan_dev_hard_start_xmit+438>: lea
-0x50(%rbp),%rdi
0x000000006024431c <vlan_dev_hard_start_xmit+442>: mov %r15,%rsi
0x000000006024431f <vlan_dev_hard_start_xmit+445>: callq
0x60161dbd <print_mac>
^ permalink raw reply
* Re: ipv6 debugging
From: Ferenc Wagner @ 2008-02-18 21:46 UTC (permalink / raw)
To: Jorge Boncompte [DTI2]; +Cc: netdev
In-Reply-To: <3740A925537C481CAA40DE393FA0D00E@intranet.dti2.net>
"Jorge Boncompte [DTI2]" <jorge@dti2.net> writes:
> Ferenc Wagner <wferi@niif.hu> writes:
>
>> I'm kindly asking for some debugging tips with the following problem:
>> a machine is running Linux 2.6.24.2, several 802.1q VLAN-s over
>> active/backup bonding over two physical interfaces. Everything is
>> allright, except for after a reboot, there's no IPv6, while IPv4
>> works. The router's ARP(6) table is empty, the machine doesn't answer
>> ping6. However, if I start tcpdump -i bond0 ip6, everything is
>> allright again. There are some indications that after some period
>> without IPv6 traffic, the same can happen again. Are there known
>> issues which can exhibit themselves like this? Other very similar
>> setups don't show this erratic behaviour.
>>
>> I know that the above doesn't give a fully detailed picture, but
>> thought that I'd better ask before taking the setup into pieces.
>
> This sounds to me like the same problem that I was having with
> OSPF, I think ARP(6) uses multicast ethernet address too. Can you try
> if the patch below, that I sent Patrick McHardy some days ago, fixes
> your problem?
Hi Jorge,
Thank you very much! Your patch indeed fixes my problem. I hope the
fix will make it into a stable release soon!
--
Regards,
Feri.
^ permalink raw reply
* [PATCH][IPROUTE] tc filters usage fixes
From: Jarek Poplawski @ 2008-02-18 22:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
A few usage description fixes of tc filters for some minimal
consistency (FILTER_KIND because of QDISC_KIND).
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
tc/f_basic.c | 4 ++--
tc/f_rsvp.c | 2 +-
tc/f_u32.c | 2 +-
tc/tc_filter.c | 6 +++---
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/tc/f_basic.c b/tc/f_basic.c
index ad41633..cf2650b 100644
--- a/tc/f_basic.c
+++ b/tc/f_basic.c
@@ -30,8 +30,8 @@ static void explain(void)
fprintf(stderr, "Usage: ... basic [ match EMATCH_TREE ] [ police POLICE_SPEC ]\n");
fprintf(stderr, " [ action ACTION_SPEC ] [ classid CLASSID ]\n");
fprintf(stderr, "\n");
- fprintf(stderr, "Where: SELECTOR := SAMPLE SAMPLE ...\n");
- fprintf(stderr, " FILTERID := X:Y:Z\n");
+ fprintf(stderr, "Where:\n");
+ fprintf(stderr, " CLASSID := X:Y:Z\n");
fprintf(stderr, "\nNOTE: CLASSID is parsed as hexadecimal input.\n");
}
diff --git a/tc/f_rsvp.c b/tc/f_rsvp.c
index 7e1e6d9..8f92e8f 100644
--- a/tc/f_rsvp.c
+++ b/tc/f_rsvp.c
@@ -33,7 +33,7 @@ static void explain(void)
fprintf(stderr, "Where: GPI := { flowlabel NUMBER | spi/ah SPI | spi/esp SPI |\n");
fprintf(stderr, " u{8|16|32} NUMBER mask MASK at OFFSET}\n");
fprintf(stderr, " POLICE_SPEC := ... look at TBF\n");
- fprintf(stderr, " FILTERID := X:Y\n");
+ fprintf(stderr, " CLASSID := X:Y\n");
fprintf(stderr, "\nNOTE: CLASSID is parsed as hexadecimal input.\n");
}
diff --git a/tc/f_u32.c b/tc/f_u32.c
index 9bc4bb5..957b1b1 100644
--- a/tc/f_u32.c
+++ b/tc/f_u32.c
@@ -38,7 +38,7 @@ static void explain(void)
fprintf(stderr, "Where: SELECTOR := SAMPLE SAMPLE ...\n");
fprintf(stderr, " SAMPLE := { ip | ip6 | udp | tcp | icmp |"
" u{32|16|8} | mark } SAMPLE_ARGS [divisor DIVISOR]\n");
- fprintf(stderr, " FILTERID := X:Y:Z\n");
+ fprintf(stderr, " CLASSID := X:Y:Z\n");
fprintf(stderr, "\nNOTE: CLASSID is parsed at hexadecimal input.\n");
}
diff --git a/tc/tc_filter.c b/tc/tc_filter.c
index d70c656..eb74f89 100644
--- a/tc/tc_filter.c
+++ b/tc/tc_filter.c
@@ -33,12 +33,12 @@ static void usage(void)
fprintf(stderr, "Usage: tc filter [ add | del | change | replace | show ] dev STRING\n");
fprintf(stderr, " [ pref PRIO ] protocol PROTO\n");
fprintf(stderr, " [ estimator INTERVAL TIME_CONSTANT ]\n");
- fprintf(stderr, " [ root | classid CLASSID ] [ handle FILTERID ]\n");
- fprintf(stderr, " [ [ FILTER_TYPE ] [ help | OPTIONS ] ]\n");
+ fprintf(stderr, " [ root | parent CLASSID ] [ handle FILTERID ]\n");
+ fprintf(stderr, " [ [ FILTER_KIND ] [ help | OPTIONS ] ]\n");
fprintf(stderr, "\n");
fprintf(stderr, " tc filter show [ dev STRING ] [ root | parent CLASSID ]\n");
fprintf(stderr, "Where:\n");
- fprintf(stderr, "FILTER_TYPE := { rsvp | u32 | fw | route | etc. }\n");
+ fprintf(stderr, "FILTER_KIND := { rsvp | u32 | fw | route | etc. }\n");
fprintf(stderr, "FILTERID := ... format depends on classifier, see there\n");
fprintf(stderr, "OPTIONS := ... try tc filter add <desired FILTER_KIND> help\n");
return;
^ 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