* Re: [NETFILTER]: Fix skb->nf_bridge lifetime issues
From: David S. Miller @ 2006-02-21 4:21 UTC (permalink / raw)
To: kaber; +Cc: netdev, netfilter-devel, bdschuym
In-Reply-To: <43FA9440.6070103@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 21 Feb 2006 05:17:04 +0100
> I think net-2.6.17 is better, the bridging stuff is really to
> fragile for this to be sure it won't break anything and this
> has never worked so far.
Ok, done.
^ permalink raw reply
* Re: Re: [PATCH RESEND] net: Move destructor from neigh->ops to neigh_params
From: Roland Dreier @ 2006-02-21 4:48 UTC (permalink / raw)
To: David S. Miller; +Cc: yoshfuji, netdev, openib-general
In-Reply-To: <20060220.200152.00014728.davem@davemloft.net>
David> Not yet, it's very low on the priority list at the moment,
David> but I do still have it in my inbox so don't worry.
Do you think you'll get a chance to look at it for 2.6.17? If not we
can work around things in the IPoIB driver in a slightly uglier way
for 2.6.17.
Thanks,
Roland
^ permalink raw reply
* Re: Re: [PATCH RESEND] net: Move destructor from neigh->ops to neigh_params
From: David S. Miller @ 2006-02-21 4:55 UTC (permalink / raw)
To: rdreier; +Cc: yoshfuji, netdev, openib-general
In-Reply-To: <adahd6t5nc1.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Mon, 20 Feb 2006 20:48:30 -0800
> Do you think you'll get a chance to look at it for 2.6.17?
Yes I will.
^ permalink raw reply
* Re: From: Carlos Martц╜n <carlos@cmartin.tk>
From: Denis Vlasenko @ 2006-02-21 6:17 UTC (permalink / raw)
To: acx100-devel; +Cc: Carlos Martín, netdev
In-Reply-To: <200602201956.07340.carlos@cmartin.tk>
[-- Attachment #1: Type: text/plain, Size: 971 bytes --]
On Monday 20 February 2006 20:56, Carlos Martín wrote:
> On Monday 20 February 2006 16:30, Denis Vlasenko wrote:
> > On Sunday 19 February 2006 00:35, Carlos Martin wrote:
> > > [PATCH] acxsm: Fix Kconfig option check
> > >
> > > This check never actually worked because CONFIG_ACX_{ACX,USB} are
> > > tristate. With Adrian Bunk's patch to the Kconfig, this works with the
> > > _BOOL hidden Kconfig options.
> > > Also update error message adding that this shouldn't happen anymore.
> >
> > Carlos, I didn't apply Adrian's patch to my tree.
> >
> > I am not sure we want to support every imaginable .config.
> > Realistic goal is:
> > * allnoconfig must compile
> > * allyesconfig must compile
> > * allmodconfig must compile
> Which doesn't work with your #error condition.
allmodconfig for acx is:
CONFIG_ACX=m
CONFIG_ACX_PCI=y
CONFIG_ACX_USB=y
and it compiles for me just fine. Please send me your .config.
Mine is attached.
--
vda
[-- Attachment #2: .config.bz2 --]
[-- Type: application/x-bzip2, Size: 9085 bytes --]
^ permalink raw reply
* Re: From: Carlos Martц╜n <carlos@cmartin.tk>
From: Carlos Martín @ 2006-02-21 14:31 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: acx100-devel, netdev
In-Reply-To: <200602210817.19138.vda@ilport.com.ua>
On Tuesday 21 February 2006 07:17, Denis Vlasenko wrote:
>
> allmodconfig for acx is:
>
> CONFIG_ACX=m
> CONFIG_ACX_PCI=y
> CONFIG_ACX_USB=y
>
> and it compiles for me just fine. Please send me your .config.
> Mine is attached.
My bad, sorry. I forgot to copy the Kconfig file over, so I was getting
tristate ACX_{PCI,USB} instead of bools.
I had
CONFIG_ACX=m
CONFIG_ACX_PCI=m
CONFIG_ACX_PCI_BOOL=y
CONFIG_ACX_USB=m
CONFIG_ACX_USB_BOOL=y
So of course it was failing. Once I copied Kconfig over, all goes according to
plan.
cmn
--
Carlos Martín Nieto | http://www.cmartin.tk
Hobbyist programmer |
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
^ permalink raw reply
* Re: [PATCH] tg3: netif_carrier_off runs too early; could still be queued when init fails
From: Michael Chan @ 2006-02-21 16:44 UTC (permalink / raw)
To: Jeff Mahoney
Cc: Andrew Morton, Linus Torvalds, Linux Kernel Mailing List,
Jeff Garzik, netdev
In-Reply-To: <20060220194337.GA21719@locomotive.unixthugs.org>
On Mon, 2006-02-20 at 14:43 -0500, Jeff Mahoney wrote:
> This patch moves the netif_carrier_off() call from tg3_init_one()->
> tg3_init_link_config() to tg3_open() as is the convention for most
> other network drivers.
I think moving netif_carrier_off() later is the right thing to do. We
can also move it to the end of tg3_init_one() just before returning 0.
>
> I was getting a panic after a tg3 device failed to initialize due to DMA
> failure. The oops pointed to the link watch queue with spinlock debugging
> enabled. Without spinlock debugging, the Oops didn't occur.
>
> I suspect that the link event was getting queued but not executed until
> after the DMA test had failed and the device was freed. The link event
> was then operating on freed memory, which could contain anything. With this
> patch applied, the Oops no longer occurs.
DMA test failed? What NIC device do you have? How did it fail?
Thanks.
^ permalink raw reply
* Re: From: Carlos Mart??n <carlos@cmartin.tk>
From: Christoph Hellwig @ 2006-02-21 19:26 UTC (permalink / raw)
To: Carlos Martin; +Cc: netdev, acx100-devel
In-Reply-To: <11403021213131-git-send-email-carlos@cmartin.tk>
On Sat, Feb 18, 2006 at 11:35:21PM +0100, Carlos Martin wrote:
> [PATCH] acxsm: Fix Kconfig option check
>
> This check never actually worked because CONFIG_ACX_{ACX,USB} are
> tristate. With Adrian Bunk's patch to the Kconfig, this works with the
> _BOOL hidden Kconfig options.
> Also update error message adding that this shouldn't happen anymore.
All the fixes discussed so far are not very nice at all. The right
fix is the following:
- split the module into three:
acx-common.ko
acx-pci.ko
acx-usb.ko
- make CONFIG_ACX_PCI and CONFIG_ACX_USB user-visible tristate
varibles in the Kconfig.
- build acx-common.ko when either of those is selected, with the
following makefile:
---- snip ----
acx-common-y += wlan.o conv.o ioctl.o common.o
acx-pci-y += pci.o
acx-usb-y += usb.o
obj-$(CONFIG_ACX_PCI) += acx-common.o acx-pci.o
obj-$(CONFIG_ACX_USB) += acx-common.o acx-usb.o
---- snip ----
- kill the IS_PCI/IS_USB macros and add a acx_operations structure that
handles the different hardware without branches all over and allows
the hw-specific code to be in separate modules.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* Re: From: Carlos Mart??n <carlos@cmartin.tk>
From: Carlos Martín @ 2006-02-21 20:24 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: netdev, acx100-devel
In-Reply-To: <20060221192601.GA28560@infradead.org>
On Tuesday 21 February 2006 20:26, Christoph Hellwig wrote:
> On Sat, Feb 18, 2006 at 11:35:21PM +0100, Carlos Martin wrote:
> > [PATCH] acxsm: Fix Kconfig option check
> >
> > This check never actually worked because CONFIG_ACX_{ACX,USB} are
> > tristate. With Adrian Bunk's patch to the Kconfig, this works with the
> > _BOOL hidden Kconfig options.
> > Also update error message adding that this shouldn't happen anymore.
>
> All the fixes discussed so far are not very nice at all. The right
> fix is the following:
>
>
> - split the module into three:
> acx-common.ko
> acx-pci.ko
> acx-usb.ko
I don't really like this method. It's not for any real reason though, so I'll
go with it if people want it. I've used this for the rt2x00 driver by loading
it manually, which was really annoying, but I suppose when it's properly
installed it works well.
>
> - make CONFIG_ACX_PCI and CONFIG_ACX_USB user-visible tristate
> varibles in the Kconfig.
> - build acx-common.ko when either of those is selected, with the
> following makefile:
>
> ---- snip ----
> acx-common-y += wlan.o conv.o ioctl.o common.o
> acx-pci-y += pci.o
> acx-usb-y += usb.o
>
> obj-$(CONFIG_ACX_PCI) += acx-common.o acx-pci.o
> obj-$(CONFIG_ACX_USB) += acx-common.o acx-usb.o
This is how we had it before, which leads to having a lot of the same code on
both modules. The unified driver is not much larger so it was made this way,
and that's where all the problem comes from.
Wouldn't this lead to duplicated function definitions at link time if both are
compiled-in? From your module split above I understood you wanted acx-common
to be another module, but here I see it goes into the modules.
> ---- snip ----
>
> - kill the IS_PCI/IS_USB macros and add a acx_operations structure that
> handles the different hardware without branches all over and allows
> the hw-specific code to be in separate modules.
There aren't that many IS_{PCI,USB} uses and most if not all are justified
(extra step for one case). It might be a good idea to do that for the
IS_ACX{100,111} macros instead of calling the generic function which then
calls the chip-specific one.
cmn
--
Carlos Martín Nieto | http://www.cmartin.tk
Hobbyist programmer |
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
^ permalink raw reply
* Re: From: Carlos Mart??n <carlos@cmartin.tk>
From: Christoph Hellwig @ 2006-02-21 20:32 UTC (permalink / raw)
To: Carlos Mart?n; +Cc: Christoph Hellwig, netdev, acx100-devel
In-Reply-To: <200602212124.23572.carlos@cmartin.tk>
On Tue, Feb 21, 2006 at 09:24:23PM +0100, Carlos Mart?n wrote:
> > acx-common-y += wlan.o conv.o ioctl.o common.o
> > acx-pci-y += pci.o
> > acx-usb-y += usb.o
> >
> > obj-$(CONFIG_ACX_PCI) += acx-common.o acx-pci.o
> > obj-$(CONFIG_ACX_USB) += acx-common.o acx-usb.o
>
> This is how we had it before, which leads to having a lot of the same code on
> both modules. The unified driver is not much larger so it was made this way,
> and that's where all the problem comes from.
> Wouldn't this lead to duplicated function definitions at link time if both are
> compiled-in? From your module split above I understood you wanted acx-common
> to be another module, but here I see it goes into the modules.
>
No. The above makefile fragment builds three modules: acx-common.o,
acx-pci.o and acx-usb.o as mentioned above. The magic here is that with
that makefile fragment is that the kbuild systems builds acx-common.o if
either CONFIG_ACX_PCI or CONFIG_ACX_USB is set, and even makes sure to
do the right thing if either is builtin. There is not code duplication
at all.
> > ---- snip ----
> >
> > - kill the IS_PCI/IS_USB macros and add a acx_operations structure that
> > handles the different hardware without branches all over and allows
> > the hw-specific code to be in separate modules.
>
> There aren't that many IS_{PCI,USB} uses and most if not all are justified
> (extra step for one case). It might be a good idea to do that for the
> IS_ACX{100,111} macros instead of calling the generic function which then
> calls the chip-specific one.
The important bit is that you need the pointers with the above module
spit, because you can't call usb- or pci-specific routines from acx-common.ko
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* Re: From: Carlos Mart??n <carlos@cmartin.tk>
From: Carlos Martín @ 2006-02-21 21:03 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: netdev, acx100-devel
In-Reply-To: <20060221203211.GA29627@infradead.org>
On Tuesday 21 February 2006 21:32, Christoph Hellwig wrote:
> On Tue, Feb 21, 2006 at 09:24:23PM +0100, Carlos Mart?n wrote:
> > Wouldn't this lead to duplicated function definitions at link time if both
are
> > compiled-in? From your module split above I understood you wanted
acx-common
> > to be another module, but here I see it goes into the modules.
> >
>
> No. The above makefile fragment builds three modules: acx-common.o,
> acx-pci.o and acx-usb.o as mentioned above. The magic here is that with
> that makefile fragment is that the kbuild systems builds acx-common.o if
> either CONFIG_ACX_PCI or CONFIG_ACX_USB is set, and even makes sure to
> do the right thing if either is builtin. There is not code duplication
> at all.
Then all is good.
>
> > > ---- snip ----
> > >
> > > - kill the IS_PCI/IS_USB macros and add a acx_operations structure that
> > > handles the different hardware without branches all over and allows
> > > the hw-specific code to be in separate modules.
> >
> > There aren't that many IS_{PCI,USB} uses and most if not all are justified
> > (extra step for one case). It might be a good idea to do that for the
> > IS_ACX{100,111} macros instead of calling the generic function which then
> > calls the chip-specific one.
>
> The important bit is that you need the pointers with the above module
> spit, because you can't call usb- or pci-specific routines from
> acx-common.ko
Yes, I realise that (unless you export them, but I don't think we want that).
I've started this, but I think it'll probably be next week before I have time
to really work on it.
This approach is probably better even if the driver is unified. Pointer
dereferences are cheaper than branches/jumping, aren't they?
cmn
--
Carlos Martín Nieto | http://www.cmartin.tk
Hobbyist programmer |
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
^ permalink raw reply
* Re: [PATCH] tg3: netif_carrier_off runs too early; could still be queued when init fails
From: David S. Miller @ 2006-02-21 21:39 UTC (permalink / raw)
To: mchan; +Cc: jeffm, akpm, torvalds, linux-kernel, jgarzik, netdev
In-Reply-To: <1140540260.20584.6.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 21 Feb 2006 08:44:20 -0800
> On Mon, 2006-02-20 at 14:43 -0500, Jeff Mahoney wrote:
> > This patch moves the netif_carrier_off() call from tg3_init_one()->
> > tg3_init_link_config() to tg3_open() as is the convention for most
> > other network drivers.
>
> I think moving netif_carrier_off() later is the right thing to do. We
> can also move it to the end of tg3_init_one() just before returning 0.
Agreed.
> > I was getting a panic after a tg3 device failed to initialize due to DMA
> > failure. The oops pointed to the link watch queue with spinlock debugging
> > enabled. Without spinlock debugging, the Oops didn't occur.
> >
> > I suspect that the link event was getting queued but not executed until
> > after the DMA test had failed and the device was freed. The link event
> > was then operating on freed memory, which could contain anything. With this
> > patch applied, the Oops no longer occurs.
>
> DMA test failed? What NIC device do you have? How did it fail?
I get this too with an old 5700 3COM card on sparc64. I'll get
you some more detailed info later today, hopefully.
Jeff, please get some details for Michael about your failure
case. Thanks.
^ permalink raw reply
* Re: [PATCH] tg3: netif_carrier_off runs too early; could still be queued when init fails
From: Michael Chan @ 2006-02-21 21:57 UTC (permalink / raw)
To: Jeff Mahoney
Cc: David S. Miller, akpm, torvalds, linux-kernel, jgarzik, netdev
In-Reply-To: <43FB9718.4050606@suse.com>
On Tue, 2006-02-21 at 17:41 -0500, Jeff Mahoney wrote:
>
> dmesg after modprobe tg3:
> tg3.c:v3.49 (Feb 2, 2006)
> ACPI: PCI Interrupt 0000:0a:02.0[A] -> GSI 24 (level, low) -> IRQ 201
> Uhhuh. NMI received for unknown reason 21 on CPU 0.
> Dazed and confused, but trying to continue
> Do you have a strange power saving mode enabled?
> tg3_test_dma() Write the buffer failed -19
> tg3: DMA engine test failed, aborting.
>
You're getting an NMI during tg3_init_one() which means that the NIC is
probably bad. I did a quick test on the same version of the 5701 NIC
with the same tg3 driver and it worked fine.
Please find out if the NIC is known to be bad. Thanks.
^ permalink raw reply
* Re: [PATCH] tg3: netif_carrier_off runs too early; could still be queued when init fails
From: Jeff Mahoney @ 2006-02-21 22:41 UTC (permalink / raw)
To: David S. Miller; +Cc: mchan, akpm, torvalds, linux-kernel, jgarzik, netdev
In-Reply-To: <20060221.133947.05470613.davem@davemloft.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David S. Miller wrote:
> From: "Michael Chan" <mchan@broadcom.com>
> Date: Tue, 21 Feb 2006 08:44:20 -0800
>
>> On Mon, 2006-02-20 at 14:43 -0500, Jeff Mahoney wrote:
>>> This patch moves the netif_carrier_off() call from tg3_init_one()->
>>> tg3_init_link_config() to tg3_open() as is the convention for most
>>> other network drivers.
>> I think moving netif_carrier_off() later is the right thing to do. We
>> can also move it to the end of tg3_init_one() just before returning 0.
>
> Agreed.
>
>>> I was getting a panic after a tg3 device failed to initialize due to DMA
>>> failure. The oops pointed to the link watch queue with spinlock debugging
>>> enabled. Without spinlock debugging, the Oops didn't occur.
>>>
>>> I suspect that the link event was getting queued but not executed until
>>> after the DMA test had failed and the device was freed. The link event
>>> was then operating on freed memory, which could contain anything. With this
>>> patch applied, the Oops no longer occurs.
>> DMA test failed? What NIC device do you have? How did it fail?
>
> I get this too with an old 5700 3COM card on sparc64. I'll get
> you some more detailed info later today, hopefully.
>
> Jeff, please get some details for Michael about your failure
> case. Thanks.
dmesg after modprobe tg3:
tg3.c:v3.49 (Feb 2, 2006)
ACPI: PCI Interrupt 0000:0a:02.0[A] -> GSI 24 (level, low) -> IRQ 201
Uhhuh. NMI received for unknown reason 21 on CPU 0.
Dazed and confused, but trying to continue
Do you have a strange power saving mode enabled?
tg3_test_dma() Write the buffer failed -19
tg3: DMA engine test failed, aborting.
relevant lspci output:
0000:0a:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701
Gigabit Ethernet (rev 15)
Subsystem: Compaq Computer Corporation NC7770 Gigabit Server
Adapter (PCI-X, 10/100/1000-T)
Flags: 66Mhz, medium devsel, IRQ 201
Memory at f7df0000 (64-bit, non-prefetchable) [size=64K]
Expansion ROM at dc080000 [disabled] [size=64K]
Capabilities: [40] PCI-X non-bridge device.
Capabilities: [48] Power Management version 2
Capabilities: [50] Vital Product Data
Capabilities: [58] Message Signalled Interrupts: 64bit+
Queue=0/3 Enable-
If you need more details, I can try to dig them up. This is a machine
I've only been using for a few days for some testing and I'm not yet
familiar with all the hardware details.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD+5cXLPWxlyuTD7IRArVcAJ4nEwx2b1j50dJp1uLBbqKJp9UlGwCfbE9N
P9iCdmB7IvGXDsuxTyjRj5M=
=5QzB
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] tg3: netif_carrier_off runs too early; could still be queued when init fails
From: David S. Miller @ 2006-02-22 0:35 UTC (permalink / raw)
To: mchan; +Cc: jeffm, akpm, torvalds, linux-kernel, jgarzik, netdev
In-Reply-To: <1140559048.20584.20.camel@rh4>
From: "Michael Chan" <mchan@broadcom.com>
Date: Tue, 21 Feb 2006 13:57:28 -0800
> On Tue, 2006-02-21 at 17:41 -0500, Jeff Mahoney wrote:
>
> > dmesg after modprobe tg3:
> > tg3.c:v3.49 (Feb 2, 2006)
> > ACPI: PCI Interrupt 0000:0a:02.0[A] -> GSI 24 (level, low) -> IRQ 201
> > Uhhuh. NMI received for unknown reason 21 on CPU 0.
> > Dazed and confused, but trying to continue
> > Do you have a strange power saving mode enabled?
> > tg3_test_dma() Write the buffer failed -19
> > tg3: DMA engine test failed, aborting.
>
> You're getting an NMI during tg3_init_one() which means that the NIC is
> probably bad. I did a quick test on the same version of the 5701 NIC
> with the same tg3 driver and it worked fine.
>
> Please find out if the NIC is known to be bad. Thanks.
I wonder if this is how this platform informs the cpu of master-abort
or target-abort cycles? It could maybe also be an IRQ routing
problem...
^ permalink raw reply
* Re: From: Carlos Mart??n <carlos@cmartin.tk>
From: Christoph Hellwig @ 2006-02-22 14:36 UTC (permalink / raw)
To: Carlos Mart?n; +Cc: netdev, acx100-devel
In-Reply-To: <200602212203.58216.carlos@cmartin.tk>
On Tue, Feb 21, 2006 at 10:03:58PM +0100, Carlos Mart?n wrote:
> > The important bit is that you need the pointers with the above module
> > spit, because you can't call usb- or pci-specific routines from
> > acx-common.ko
>
> Yes, I realise that (unless you export them, but I don't think we want that).
even that wouldn't work with current module because the usb and pci modules
call into the common code and thus we'd have recursive module depency.
> This approach is probably better even if the driver is unified. Pointer
> dereferences are cheaper than branches/jumping, aren't they?
It shouldn't matter these days as cpus have nice branch prediction.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply
* Re: From: Carlos Mart??n <carlos@cmartin.tk>
From: Carlos Martín @ 2006-02-22 15:06 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: netdev, acx100-devel
In-Reply-To: <20060222143604.GA16269@infradead.org>
On Wednesday 22 February 2006 15:36, Christoph Hellwig wrote:
> On Tue, Feb 21, 2006 at 10:03:58PM +0100, Carlos Mart?n wrote:
> > > The important bit is that you need the pointers with the above module
> > > spit, because you can't call usb- or pci-specific routines from
> > > acx-common.ko
> >
> > Yes, I realise that (unless you export them, but I don't think we want
that).
>
> even that wouldn't work with current module because the usb and pci modules
> call into the common code and thus we'd have recursive module depency.
And you may not build both modules, so acx-common.ko would never be satisfied.
Function pointers all the way then.
>
> > This approach is probably better even if the driver is unified. Pointer
> > dereferences are cheaper than branches/jumping, aren't they?
>
> It shouldn't matter these days as cpus have nice branch prediction.
I remember reading P4s have problems with this because they had really long
branch pipes (the proper name escapes me at the moment) and if they got it
wrong, it took quite a bit of time (in CPU terms, of course) to flush them. I
don't use them personally, but I believe the trend is to do that.
cmn
--
Carlos Martín Nieto | http://www.cmartin.tk
Hobbyist programmer |
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
^ permalink raw reply
* Re: no carrier detection after resume from swsusp (8139too)
From: Nikolaus Filus @ 2006-02-22 15:12 UTC (permalink / raw)
To: netdev; +Cc: networkmanager-list, Francois Romieu
In-Reply-To: <20060221234947.GA29806@electric-eye.fr.zoreil.com>
Cc: networkamanger-list, as it seems now to be related to nm
On Wednesday 22 February 2006 00:49, Francois Romieu wrote:
> (owner of http://bugzilla.kernel.org/show_bug.cgi?id=5681 Cc:ed)
>
> Nikolaus Filus <nfilus@gmx.net> :
> [...]
>
> > I'm using linux 2.6.14.3 with swsusp2 2.2rc14 (not the most new
> > ones). Since I'm using NetworkManager, which switches and manages my
> > wired and wireless devices, I have to reload 8139too after resume,
> > before plugin events of wired network are recognized. Some other
> > users of NM are reporting similar problems.
>
> May I assume that your 8139too device does not need to be reloaded when
> you suspend/resume and NM is not used ?
I didn't look enough on this issue before.
After resume, I get "invalid argument" from
/sys/class/net/eth1/carrier. Reloading the driver *OR* restarting
networkmanager solves the problem! Is it possible a process like nm blocks
some ressources, which are re-initialised by reloading the driver or
restarting nm? Notice, that just stopping nm is not enough.
Thanks in advance,
Nikolaus
^ permalink raw reply
* Re: no carrier detection after resume from swsusp (8139too)
From: Robert Love @ 2006-02-22 15:19 UTC (permalink / raw)
To: Nikolaus Filus; +Cc: netdev, networkmanager-list, Francois Romieu
In-Reply-To: <200602221612.14631.nfilus@gmx.net>
On Wed, 2006-02-22 at 16:12 +0100, Nikolaus Filus wrote:
> I didn't look enough on this issue before.
>
> After resume, I get "invalid argument" from
> /sys/class/net/eth1/carrier. Reloading the driver *OR* restarting
> networkmanager solves the problem! Is it possible a process like nm blocks
> some ressources, which are re-initialised by reloading the driver or
> restarting nm? Notice, that just stopping nm is not enough.
>
> Thanks in advance,
e100 or e1000?
`carrier' returns EINVAL if the device is not UP. It might be a bug in
NM if the device is not UP after a resume. What does `ifconfig eth1`
show before and after a resume?
Robert Love
^ permalink raw reply
* Re: [PATCH] tg3: netif_carrier_off runs too early; could still be queued when init fails
From: Jeff Mahoney @ 2006-02-22 16:48 UTC (permalink / raw)
To: Michael Chan
Cc: David S. Miller, akpm, torvalds, linux-kernel, jgarzik, netdev
In-Reply-To: <1140559048.20584.20.camel@rh4>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Chan wrote:
> On Tue, 2006-02-21 at 17:41 -0500, Jeff Mahoney wrote:
>
>> dmesg after modprobe tg3:
>> tg3.c:v3.49 (Feb 2, 2006)
>> ACPI: PCI Interrupt 0000:0a:02.0[A] -> GSI 24 (level, low) -> IRQ 201
>> Uhhuh. NMI received for unknown reason 21 on CPU 0.
>> Dazed and confused, but trying to continue
>> Do you have a strange power saving mode enabled?
>> tg3_test_dma() Write the buffer failed -19
>> tg3: DMA engine test failed, aborting.
>>
>
> You're getting an NMI during tg3_init_one() which means that the NIC is
> probably bad. I did a quick test on the same version of the 5701 NIC
> with the same tg3 driver and it worked fine.
>
> Please find out if the NIC is known to be bad. Thanks.
Up until recently, this NIC was reported to work. I booted our
2.6.5-based SLES9 kernel on it. This is the kernel the machine has been
running for a while with the NIC working, and when I booted it, I got
the same DMA failure messages as with 2.6.16-rc4.
I suspect that the hardware has just recently failed, and I figured it
was a hardware problem when I saw the NMI/DMA messages, but since I
don't have physical access to the hardware, immediate removal wasn't an
option.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD/JX2LPWxlyuTD7IRAiKOAKCmFcjKzmyJEVF63hsm5zxPFVwNBACdHTR7
CghdO/WCfh4mwCaH1uwh1fc=
=Z5Ey
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: no carrier detection after resume from swsusp (8139too)
From: Will Stephenson @ 2006-02-23 9:20 UTC (permalink / raw)
To: networkmanager-list, James Ettle; +Cc: netdev, Francois Romieu
In-Reply-To: <1140621599.6269.10.camel@betsy.boston.ximian.com>
[-- Attachment #1: Type: text/plain, Size: 962 bytes --]
On Wednesday 22 February 2006 16:19, Robert Love wrote:
> e100 or e1000?
8139cp here. Seems to have picked up this behaviour since SL10.1beta2 or so,
still in beta4.
See https://bugzilla.novell.com/show_bug.cgi?id=151892
> `carrier' returns EINVAL if the device is not UP. It might be a bug in
> NM if the device is not UP after a resume. What does `ifconfig eth1`
> show before and after a resume?
carrier is 1 before and after, eth0 is UP before and after, restarting NM
doesn't help, nor does stopping NM, rmmod, modprobe, and starting NM.
I didn't think it is NM related, as I could not configure the network by hand
after resume. However, I just switched my network config to SUSE
traditional ifup+ifplugd (joys of flexibility), and although eth0 does not
work on resume, rcnetwork restart fixes it, whereas when NM is in charge,
this does not help. So my understanding is NM is not the direct cause but is
a contributing factor.
Will
[-- Attachment #2: ifconfig.after.resume --]
[-- Type: text/plain, Size: 1312 bytes --]
eth0 Link encap:Ethernet HWaddr 00:02:3F:67:0A:E3
inet addr:169.254.137.164 Bcast:169.254.255.255 Mask:255.255.0.0
inet6 addr: fe80::202:3fff:fe67:ae3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2769 errors:0 dropped:3144 overruns:0 frame:0
TX packets:180 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:285833 (279.1 Kb) TX bytes:14752 (14.4 Kb)
Interrupt:10 Base address:0x2000
eth1 Link encap:Ethernet HWaddr 00:0C:F1:13:76:CB
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:5 Memory:90000000-90000fff
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:277 errors:0 dropped:0 overruns:0 frame:0
TX packets:277 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:21838 (21.3 Kb) TX bytes:21838 (21.3 Kb)
[-- Attachment #3: ifconfig.before.suspend --]
[-- Type: text/plain, Size: 1378 bytes --]
eth0 Link encap:Ethernet HWaddr 00:02:3F:67:0A:E3
inet addr:10.10.101.143 Bcast:10.10.255.255 Mask:255.255.0.0
inet6 addr: 2001:780:101:a00:202:3fff:fe67:ae3/64 Scope:Global
inet6 addr: fe80::202:3fff:fe67:ae3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2210 errors:0 dropped:0 overruns:0 frame:0
TX packets:177 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:251842 (245.9 Kb) TX bytes:14494 (14.1 Kb)
Interrupt:10 Base address:0x2000
eth1 Link encap:Ethernet HWaddr 00:0C:F1:13:76:CB
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:5 Memory:90000000-90000fff
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:149 errors:0 dropped:0 overruns:0 frame:0
TX packets:149 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:12784 (12.4 Kb) TX bytes:12784 (12.4 Kb)
[-- Attachment #4: Type: text/plain, Size: 170 bytes --]
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
^ permalink raw reply
* Re: [PATCH 02/02] add mask options to fwmark masking code
From: Michael Richardson @ 2006-02-23 19:36 UTC (permalink / raw)
To: Patrick McHardy; +Cc: kuznet, netfilter-devel, Jamal Hadi Salim, netdev
In-Reply-To: <43F9F4E7.5000708@trash.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Patrick" == Patrick McHardy <kaber@trash.net> writes:
>> #define RTA_FWMARK RTA_PROTOINFO +#define RTA_FWMARK_MASK
>> RTA_CACHEINFO
Patrick> Please introduce a new attribute for this instead of
Patrick> overloading RTA_CACHEINFO.
I would be happy to do that.
Should I also un-overload FWMARK, with backwards compatibility?
>> diff --git a/net/ipv4/fib_rules.c b/net/ipv4/fib_rules.c index
>> de327b3..69eed89 100644 --- a/net/ipv4/fib_rules.c +++
>> b/net/ipv4/fib_rules.c @@ -68,6 +68,7 @@ struct fib_rule u8
>> r_tos; #ifdef CONFIG_IP_ROUTE_FWMARK u32 r_fwmark; + u32
>> r_fwmark_mask;
Patrick> Both patches have whitespace issues. You should also change
uhm. okay.
I'm surprised, since I produced it with git-format-patch. Maybe there
are tabs that emacs screwed up.
- --
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Finger me for keys
iQEVAwUBQ/4O2ICLcPvd0N1lAQK/egf6A0iQ1hvecR4BeaCrQiu53beGZd6zHldk
o6logfar94kPP/H/D/kMcNeAvL2a3cJ8wyfyP02Cav8gP1C3X+XV+yLtA9jHIrdK
nqQ1gw7F4Cj2+v7du/jS8GxNMWevXhJ7f9hvnzh8+DHMUCjqiksgsuIgcRQYrqOQ
vxYERvR5TojEIaJfg8kH/lJRn3sm/APuMphM6c6SAeqrWpAdijbZb4LSNpGH50ci
nNhUp+FxoP8vVFTMTu7M1MK4fpCIWA/PxBkmy3YDhcQx1+mE2nrEqHdbKfx9uY+t
0mxR8UC5sthhn94/VCjcqWOoHe3S/Gi+WWoPtwN1sFe5BujwU7Vcfw==
=yKIA
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] iproute2 -- add fwmarkmask
From: Michael Richardson @ 2006-02-23 19:39 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, netfilter-devel, shemminger
In-Reply-To: <43F9F648.1060803@trash.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Patrick" == Patrick McHardy <kaber@trash.net> writes:
Patrick> The normal way to display masks is with a "/". Also I think
Patrick> it shouldn't display the default mask to avoid breaking
Patrick> scripts that parse the output.
I generally dislike the /VALUE, since I expect /PREFIX-LEN.
I agree that it shouldn't show if it is default.
Patrick> ip should be able to parse its own output, and it would
Patrick> also look nicer if I could just say "fwmark
Patrick> 0x1/32". fwmarkmask is really an incredible ugly expression
Patrick> :)
Sure. Is that a 32-bit long mask (0xfffffff), or is it a 0x00000020?
fwmark is not an address.
Or would you like /32 to be a prefix-based mask, and &value and/or
fwmarkmask to be a value?
- --
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[
] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Finger me for keys
iQEUAwUBQ/4PcoCLcPvd0N1lAQIHhQf3XzPLA91QEx2+XpmYIm8RyB1oKmUUXDP+
s2UrhOKbQwipcq8/hk1t4FKx8J5j/dFHzVXbgPK+ZUwX4+IjHmM3r0sCIcK08xwU
/ZZjf0wqwUI+RcPRFw3zC0+hnwRUIAUxhl3p7h3PigDpPu7AY5tQ1dXc6WNwRjTi
fS7Yozbo225dzvVLKHhSIqOQ4eJFJcPPQdTKQLxnc3gtVoSe41DKMM+x6uix6fG8
se9dngJRbhye1Xgws9AGnBQT9f7JVmCSv7V4SHnNynmnRw3cra8++QEnLZ/vhm5C
JdeVSeDGxAPuKEj6HA2RZu/UOG6RkYNZGPovGKzuPn403x0HNBuf
=BzfV
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 00/01] pktgen: Lindent run.
From: David S. Miller @ 2006-02-24 1:17 UTC (permalink / raw)
To: lcapitulino; +Cc: linux-kernel, netdev, robert.olsson
In-Reply-To: <20060123134419.efc0c80e.lcapitulino@mandriva.com.br>
From: Luiz Fernando Capitulino <lcapitulino@mandriva.com.br>
Date: Mon, 23 Jan 2006 13:44:19 -0200
>
> This patch is not in-lined because it's 120K bytes long, you can found it at:
>
> http://www.cpu.eti.br/patches/pktgen_lindent_1.patch
Not found:
davem@sunset:~/src/GIT/net-2.6.17$ wget http://www.cpu.eti.br/patches/pktgen_lindent_1.patch
--17:16:50-- http://www.cpu.eti.br/patches/pktgen_lindent_1.patch
=> `pktgen_lindent_1.patch'
Resolving www.cpu.eti.br... 209.59.143.183
Connecting to www.cpu.eti.br|209.59.143.183|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
17:16:50 ERROR 404: Not Found.
Anyways, can you please regenerate these 4 patches against
net-2.6.17, as I put in Arthur's race fix and it will certainly
conflict with these.
Sorry for taking so long to get to this :-(
^ permalink raw reply
* Re: [PATCH 02/02] add mask options to fwmark masking code
From: Patrick McHardy @ 2006-02-24 4:58 UTC (permalink / raw)
To: Michael Richardson; +Cc: kuznet, netfilter-devel, Jamal Hadi Salim, netdev
In-Reply-To: <16464.1140723418@sandelman.ottawa.on.ca>
Michael Richardson wrote:
>
>
>>>>>>>"Patrick" == Patrick McHardy <kaber@trash.net> writes:
>
> >> #define RTA_FWMARK RTA_PROTOINFO +#define RTA_FWMARK_MASK
> >> RTA_CACHEINFO
>
> Patrick> Please introduce a new attribute for this instead of
> Patrick> overloading RTA_CACHEINFO.
>
> I would be happy to do that.
> Should I also un-overload FWMARK, with backwards compatibility?
No, that one is fine since it doesn't already have a different meaning.
^ permalink raw reply
* Re: [PATCH] iproute2 -- add fwmarkmask
From: Patrick McHardy @ 2006-02-24 4:59 UTC (permalink / raw)
To: Michael Richardson; +Cc: netdev, netfilter-devel, shemminger
In-Reply-To: <18992.1140723572@sandelman.ottawa.on.ca>
Michael Richardson wrote:
>
>
>>>>>>>"Patrick" == Patrick McHardy <kaber@trash.net> writes:
>
> Patrick> The normal way to display masks is with a "/". Also I think
> Patrick> it shouldn't display the default mask to avoid breaking
> Patrick> scripts that parse the output.
>
> I generally dislike the /VALUE, since I expect /PREFIX-LEN.
> I agree that it shouldn't show if it is default.
>
> Patrick> ip should be able to parse its own output, and it would
> Patrick> also look nicer if I could just say "fwmark
> Patrick> 0x1/32". fwmarkmask is really an incredible ugly expression
> Patrick> :)
>
> Sure. Is that a 32-bit long mask (0xfffffff), or is it a 0x00000020?
> fwmark is not an address.
>
> Or would you like /32 to be a prefix-based mask, and &value and/or
> fwmarkmask to be a value?
That was not the greatest example :) I think it should be a bitmask.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox