* kerneloops.org report for the week of October 11th 2009
From: Arjan van de Ven @ 2009-10-11 23:21 UTC (permalink / raw)
To: linux-kernel; +Cc: tytso, netdev, jbarnes, linux-acpi, dri-devel, torvalds
A very clear distribution this time: the number one is almost 4 times
more frequently reported than the number 2. It's also an old time favorite,
with over *56 thousand* total reports..... time for the graphics team to fix the issue!
Other old timers are the ct_vm_map() function (over 11 thousand reports) as well as
various "your bios is broken" warnings.
There's also some recurring networking issues, with tcp_recvmsg and inet_sock_destruct
as main functions there.
New this time is a warning in the cpufreq code, which somehow now gets called
with interrupts off just when it wants to do a smp_call_function() during suspend resume;
also new is an interaction between ext4 and the quota code. Also new is an ioremap leak check
that might be a Fedora-only issue.
This week, a total of 16542 oopses and warnings have been reported,
compared to 14309 reports in the previous week.
Per file statistics
3779 drivers/gpu/drm/i915/i915_gem_tiling.c
844 drivers/pci/dmar.c
665 arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c
576 pci/ctxfi/ctvmem.c
426 arch/x86/kernel/cpu/mtrr/generic.c
347 net/ipv4/af_inet.c
263 net/ipv4/tcp.c
262 kernel/time.c
259 arch/x86/mm/ioremap.c
244 drivers/net/sis900.c
215 drivers/net/wireless/iwlwifi/iwl-sta.c
208 drivers/parport/procfs.c
Rank 1: i915_gem_set_tiling (warning)
Reported 3779 times (56835 total reports)
[gem] Failure in the tiling code
This warning was last seen in version 2.6.31, and first seen in 2.6.29-rc2.
More info: http://www.kerneloops.org/searchweek.php?search=i915_gem_set_tiling
Rank 2: suspend_test_finish(resume devices) (oops)
Reported 1022 times (7869 total reports)
This oops was last seen in version 2.6.31.1, and first seen in 2.6.28-rc6.
More info: http://www.kerneloops.org/searchweek.php?search=suspend_test_finish(resume devices)
Rank 3: dmar_table_init (warning)
Reported 845 times (8224 total reports)
BIOS bug exposed via a WARN_ON
This warning was last seen in version 2.6.31, and first seen in 2.6.29.
More info: http://www.kerneloops.org/searchweek.php?search=dmar_table_init
Rank 4: get_cur_val (warning)
Reported 665 times (2585 total reports)
cpufreq gets called during suspend/resume and ends up calling smp_call_function with irqs off
This warning was last seen in version 2.6.31, and first seen in 2.6.29-rc1.
More info: http://www.kerneloops.org/searchweek.php?search=get_cur_val
Rank 5: ct_vm_map (warning)
Reported 576 times (11868 total reports)
Bug in the creative XFI driver (backported to Fedora)
This warning was last seen in version 2.6.30.8, and first seen in 2.6.29-rc4-git1.
More info: http://www.kerneloops.org/searchweek.php?search=ct_vm_map
Rank 6: dquot_claim_space (oops)
Reported 437 times (3257 total reports)
Interaction between EXT4 and the quota code
This oops was last seen in version 2.6.31, and first seen in 2.6.30.
More info: http://www.kerneloops.org/searchweek.php?search=dquot_claim_space
Rank 7: generic_get_mtrr (warning)
Reported 426 times (9303 total reports)
BIOS bug where the MTRRs are not set up correctly
This warning was last seen in version 2.6.31, and first seen in 2.6.25.3.
More info: http://www.kerneloops.org/searchweek.php?search=generic_get_mtrr
Rank 8: inet_sock_destruct (warning)
Reported 347 times (5453 total reports)
This warning was last seen in version 2.6.31, and first seen in 2.6.27-rc2.
More info: http://www.kerneloops.org/searchweek.php?search=inet_sock_destruct
Rank 9: tcp_recvmsg (oops)
Reported 263 times (6206 total reports)
fixed in 2.6.30 (commit 775273131810caa41dfc7f9e552ea5d8508caf40)
This oops was last seen in version 2.6.31.3, and first seen in 2.6.25.
More info: http://www.kerneloops.org/searchweek.php?search=tcp_recvmsg
Rank 10: getnstimeofday (warning)
Reported 262 times (18624 total reports)
[suspend resume] getnstimeofday() is called before timekeeping is resumed
This warning was last seen in version 2.6.31, and first seen in 2.6.24.
More info: http://www.kerneloops.org/searchweek.php?search=getnstimeofday
Rank 11: check_early_ioremap_leak (warning)
Reported 256 times (1101 total reports)
This warning was last seen in version 2.6.31, and first seen in 2.6.24-rc8.
More info: http://www.kerneloops.org/searchweek.php?search=check_early_ioremap_leak
Rank 12: dev_watchdog(sis900) (oops)
Reported 244 times (11843 total reports)
This oops was last seen in version 2.6.30.8, and first seen in 2.6.26-rc4-git2.
More info: http://www.kerneloops.org/searchweek.php?search=dev_watchdog(sis900)
Rank 13: iwl_set_dynamic_key (warning)
Reported 215 times (21737 total reports)
no space for new kew"
This warning was last seen in version 2.6.30, and first seen in 2.6.27.35.
More info: http://www.kerneloops.org/searchweek.php?search=iwl_set_dynamic_key
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
^ permalink raw reply
* Re: 2.6.32-rc4: Reported regressions 2.6.30 -> 2.6.31
From: Larry Finger @ 2009-10-11 23:24 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: DRI, Linux SCSI List, Network Development, Linux Wireless List,
Linux Kernel Mailing List, Natalie Protasevich, Linux ACPI,
Andrew Morton, Kernel Testers List, Linus Torvalds, Linux PM List
In-Reply-To: <56acieJJ2fF.A.nEB.Hzl0KB@chimera>
On 10/11/2009 05:41 PM, Rafael J. Wysocki wrote:
> [Note:
> 10 new reports in the last 10 days, but fortunately we're fixing them faster
> than they're being reported.]
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14181
> Subject : b43 causes panic at ifconfig down / shutdown
> Submitter : Jeremy Huddleston <jeremyhu@freedesktop.org>
> Date : 2009-09-15 18:34 (27 days old)
A patch to fix this one is in the hands of the OP. It should be tested
within the next couple of days.
Larry
^ permalink raw reply
* [PATCH] acenic: Pass up error code from ace_load_firmware()
From: Ben Hutchings @ 2009-10-12 1:34 UTC (permalink / raw)
To: David Miller; +Cc: Jes Sorensen, linux-acenic, netdev
If ace_load_firmware() fails, ace_init() cleans up but still returns
0, leading to an oops as seen in <http://bugs.debian.org/521383>.
It should pass the error code up.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: stable@kernel.org
---
Compile-tested only.
Ben.
drivers/net/acenic.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/acenic.c b/drivers/net/acenic.c
index 08419ee..12bfc44 100644
--- a/drivers/net/acenic.c
+++ b/drivers/net/acenic.c
@@ -1209,7 +1209,8 @@ static int __devinit ace_init(struct net_device *dev)
memset(ap->info, 0, sizeof(struct ace_info));
memset(ap->skb, 0, sizeof(struct ace_skb));
- if (ace_load_firmware(dev))
+ ecode = ace_load_firmware(dev);
+ if (ecode)
goto init_error;
ap->fw_running = 0;
--
1.6.4.3
^ permalink raw reply related
* [PATCH] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 2:43 UTC (permalink / raw)
To: davem; +Cc: netdev
Use phys_addr_t data type for pci resource address
instead of unsigned long. This fixes mapping of
pci resources where resource addresses can be larger
than word size (e.g. PAE).
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 9b9eab1..194b3e3 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -595,7 +595,8 @@ netxen_setup_pci_map(struct netxen_adapter *adapter)
void __iomem *mem_ptr2 = NULL;
void __iomem *db_ptr = NULL;
- unsigned long mem_base, mem_len, db_base, db_len = 0, pci_len0 = 0;
+ phys_addr_t mem_base, db_base;
+ unsigned long mem_len, db_len = 0, pci_len0 = 0;
struct pci_dev *pdev = adapter->pdev;
int pci_func = adapter->ahw.pci_func;
--
1.6.0.2
^ permalink raw reply related
* [PATCH -mm] connector: Passing required parameter for function cn_add_callback.
From: Rakib Mullick @ 2009-10-12 2:44 UTC (permalink / raw)
To: netdev; +Cc: Andrew Morton, zbr, LKML
We need to pass struct netlink_skb_parms as parameter for
cn_proc_mcast_ctl, which
is a callback function supposed to take two parameter. Fixes the
following warning and
a kernel-doc notation of the function.
CC drivers/connector/cn_proc.o
drivers/connector/cn_proc.c: In function `cn_proc_init':
drivers/connector/cn_proc.c:263: warning: passing arg 3 of
`cn_add_callback' from incompatible pointer type
----
Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
--- linus/drivers/connector/cn_proc.c 2009-10-09 17:38:22.000000000 +0600
+++ rakib/drivers/connector/cn_proc.c 2009-10-12 09:45:33.000000000 +0600
@@ -225,9 +225,10 @@ static void cn_proc_ack(int err, int rcv
/**
* cn_proc_mcast_ctl
- * @data: message sent from userspace via the connector
+ * @msg: message sent from userspace via the connector
+ * @nsp: remains unused but we need it to keep it
*/
-static void cn_proc_mcast_ctl(struct cn_msg *msg)
+static void cn_proc_mcast_ctl(struct cn_msg *msg, struct
netlink_skb_parms *nsp)
{
enum proc_cn_mcast_op *mc_op = NULL;
int err = 0;
^ permalink raw reply
* Re: Occasional crashes with sky2
From: Bernd Schmidt @ 2009-10-12 3:48 UTC (permalink / raw)
To: Mike McCormack; +Cc: netdev, Stephen Hemminger, shemminger
In-Reply-To: <392fb48f0910111606x7bb70e6u1c805ce00b78ce12@mail.gmail.com>
Mike McCormack wrote:
>
> 2009/10/11 Bernd Schmidt <bernds_cb1@t-online.de
> <mailto:bernds_cb1@t-online.de>>
>
> For a few months now, I've been seeing occasional kernel panics that
> would happen every few weeks. I'm not exactly sure when they started,
> but I definitely see them in 2.6.29 and 2.6.30, and never saw them in
> 2.6.25 and earlier. They happen with 32 bit and 64 bit kernels.
>
>
> Does this happen with 2.6.31 or 2.6.32-rcX?
No idea. So far I've avoided 2.6.31. I'd have to run the kernel for a
few weeks and even if there were no crashes it wouldn't really prove
that the problem is fixed.
Bernd
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Greg KH @ 2009-10-12 3:00 UTC (permalink / raw)
To: Rob Townley
Cc: Matt Domsch, Stephen Hemminger, netdev, linux-hotplug, Narendra_K,
jordan_hargrave
In-Reply-To: <7e84ed60910111410g52ffd52bjec62576570d4b460@mail.gmail.com>
On Sun, Oct 11, 2009 at 04:10:03PM -0500, Rob Townley wrote:
> So when an add-in PCI NIC has a lower MAC than the motherboard NICs,
> the add-in cards will come before the motherboard NICs. i don't like it.
Huh? Have you used the MAC persistant rules? If you add a new card,
what does it pick for it?
> But please whatever is done, make sure ping and tracert still works when
> telling it to use a ethX source interface:
>
> eth0 = 4.3.2.8, the default gateway is thru eth1.
> ping -I eth0 208.67.222.222 FAILS
> ping -I 4.3.2.8 208.67.222.222 WORKS
> tracert -i eth0 -I 208.67.222.222 FAILS
> tracert -s 4.3.2.8 -I 208.67.222.222 WORKS
> tracert -i eth0 208.67.222.222 FAILS
> tracert -s 4.3.2.8 208.67.222.222 WORKS
Again, is what we currently have broken? I am confused as to what this
is referring to.
greg k-h
^ permalink raw reply
* Re: [PATCH] Generalize socket rx gap / receive queue overflow cmsg (v4)
From: Eric Dumazet @ 2009-10-12 4:38 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, davem, socketcan
In-Reply-To: <20091010123522.GA24193@localhost.localdomain>
Neil Horman a écrit :
> Version 4
>
> Change Notes:
>
> 1) Remove the superfolous put_cmsg that I missed in the last version
>
> =======================================================================
>
> Create a new socket level option to report number of queue overflows
>
> Recently I augmented the AF_PACKET protocol to report the number of frames lost
> on the socket receive queue between any two enqueued frames. This value was
> exported via a SOL_PACKET level cmsg. AFter I completed that work it was
> requested that this feature be generalized so that any datagram oriented socket
> could make use of this option. As such I've created this patch, It creates a
> new SOL_SOCKET level option called SO_RXQ_OVFL, which when enabled exports a
> SOL_SOCKET level cmsg that reports the nubmer of times the sk_receive_queue
> overflowed between any two given frames. It also augments the AF_PACKET
> protocol to take advantage of this new feature (as it previously did not touch
> sk->sk_drops, which this patch uses to record the overflow count). Tested
> successfully by me.
>
> Notes:
>
> 1) Unlike my previous patch, this patch simply records the sk_drops value, which
> is not a number of drops between packets, but rather a total number of drops.
> Deltas must be computed in user space.
>
> 2) While this patch currently works with datagram oriented protocols, it will
> also be accepted by non-datagram oriented protocols. I'm not sure if thats
> agreeable to everyone, but my argument in favor of doing so is that, for those
> protocols which aren't applicable to this option, sk_drops will always be zero,
> and reporting no drops on a receive queue that isn't used for those
> non-participating protocols seems reasonable to me. This also saves us having
> to code in a per-protocol opt in mechanism.
>
> 3) This applies cleanly to net-next assuming that commit
> 977750076d98c7ff6cbda51858bb5a5894a9d9ab (my af packet cmsg patch) is reverted
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Thanks Neil
I found no obvious error in this v4, except two long lines.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH -mm] connector: Passing required parameter for function cn_add_callback.
From: David Miller @ 2009-10-12 5:35 UTC (permalink / raw)
To: rakib.mullick; +Cc: netdev, akpm, zbr, linux-kernel
In-Reply-To: <b9df5fa10910111944s274207aica39c0e646c10f7a@mail.gmail.com>
From: Rakib Mullick <rakib.mullick@gmail.com>
Date: Mon, 12 Oct 2009 08:44:33 +0600
> */
> -static void cn_proc_mcast_ctl(struct cn_msg *msg)
> +static void cn_proc_mcast_ctl(struct cn_msg *msg, struct
> netlink_skb_parms *nsp)
Your patches are unusable because your email client corrupts the
patch, here you can see it is splitting up long lines.
Please fix this up and resubmit.
^ permalink raw reply
* Re: [PATCH] Generalize socket rx gap / receive queue overflow cmsg (v4)
From: Oliver Hartkopp @ 2009-10-12 5:48 UTC (permalink / raw)
To: Eric Dumazet, Neil Horman; +Cc: netdev, davem
In-Reply-To: <4AD2B2BF.8040706@gmail.com>
Eric Dumazet wrote:
> Neil Horman a écrit :
>>
>> (..)
>>
>> =======================================================================
>>
>> Create a new socket level option to report number of queue overflows
>>
>> (..)
>>
>> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
>
> Thanks Neil
>
> I found no obvious error in this v4, except two long lines.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks for this nice solution to both of you!
I'm very happy to be able to use this generalized socket option with can-raw
sockets now and that it has been possible to find an efficient and clear patch
for that.
Best regards,
Oliver
^ permalink raw reply
* Re: [PATCH] pkt_sched: pedit use proper struct
From: David Miller @ 2009-10-12 6:04 UTC (permalink / raw)
To: hadi; +Cc: netdev
In-Reply-To: <1255270898.5406.6.camel@dogo.mojatatu.com>
From: jamal <hadi@cyberus.ca>
Date: Sun, 11 Oct 2009 10:21:38 -0400
> This probably deserves to go into -stable.
Applied, thanks Jamal, I'll queue this up for -stable.
^ permalink raw reply
* Re: [PATCH] netxen: fix pci bar mapping
From: David Miller @ 2009-10-12 6:06 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1255315402-1578-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 11 Oct 2009 19:43:22 -0700
> Use phys_addr_t data type for pci resource address
> instead of unsigned long. This fixes mapping of
> pci resources where resource addresses can be larger
> than word size (e.g. PAE).
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
The correct type to use is 'resource_size_t' not 'phys_addr_t'.
Look at the "struct resource" member types in linux/ioport.h, that's
what these pci_resource_start() et al. routines return.
Please fix this up and resubmit.
^ permalink raw reply
* Re: [PATCH] net: Fix struct sock bitfield annotation
From: David Miller @ 2009-10-12 6:07 UTC (permalink / raw)
To: eric.dumazet; +Cc: vegard.nossum, netdev, mingo
In-Reply-To: <4ACEF951.7030104@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 09 Oct 2009 10:50:25 +0200
> [PATCH] net: Fix struct sock bitfield annotation
>
> Since commit a98b65a3 (net: annotate struct sock bitfield), we lost
> 8 bytes in struct sock on 64bit arches because of
> kmemcheck_bitfield_end(flags) misplacement.
>
> Fix this by putting together sk_shutdown, sk_no_check, sk_userlocks,
> sk_protocol and sk_type in the 'flags' 32bits bitfield
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 1/3] iwmc3200top: Add Intel Wireless MultiCom 3200 top driver.
From: David Miller @ 2009-10-12 6:07 UTC (permalink / raw)
To: eric.dumazet
Cc: tomasw, linville, netdev, linux-wireless, linux-mmc, yi.zhu,
inaky.perez-gonzalez, cindy.h.kao, guy.cohen, ron.rindjunsky,
tomas.winkler, joe
In-Reply-To: <4AD18C06.8040002@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 11 Oct 2009 09:40:54 +0200
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e1da925..18244ad 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3654,6 +3654,7 @@ NETWORKING [GENERAL]
> M: "David S. Miller" <davem@davemloft.net>
> L: netdev@vger.kernel.org
> W: http://www.linuxfoundation.org/en/Net
> +W: http://patchwork.ozlabs.org/project/netdev/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
> S: Maintained
> F: net/
I've applied this, thanks Eric.
^ permalink raw reply
* Re: [net-next PATCH 1/8] qlge: Remove explicit setting of PCI Dev CTL reg.
From: David Miller @ 2009-10-12 6:10 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev, root
In-Reply-To: <1255203310-18114-2-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Sat, 10 Oct 2009 12:35:03 -0700
> From: root <root@localhost.localdomain>
Ron I'm fixing this up by hand as I go through these qlge patches, but
please fix your config to emit a correct From: line in your patches.
Thanks.
^ permalink raw reply
* Re: [PATCH] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 6:12 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20091011.230656.245420067.davem@davemloft.net>
Ok, I am resending the patch.
Thanks,
Dhananjay
David Miller wrote:
> From: Dhananjay Phadke <dhananjay@netxen.com>
> Date: Sun, 11 Oct 2009 19:43:22 -0700
>
>> Use phys_addr_t data type for pci resource address
>> instead of unsigned long. This fixes mapping of
>> pci resources where resource addresses can be larger
>> than word size (e.g. PAE).
>>
>> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
>
> The correct type to use is 'resource_size_t' not 'phys_addr_t'.
>
> Look at the "struct resource" member types in linux/ioport.h, that's
> what these pci_resource_start() et al. routines return.
>
> Please fix this up and resubmit.
^ permalink raw reply
* [PATCHv2] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 6:13 UTC (permalink / raw)
To: davem; +Cc: netdev
Use phys_addr_t data type for pci resource address
instead of unsigned long. This fixes mapping of
pci resources where resource addresses can be larger
than word size (e.g. PAE).
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 9b9eab1..7fc15e9 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -595,7 +595,8 @@ netxen_setup_pci_map(struct netxen_adapter *adapter)
void __iomem *mem_ptr2 = NULL;
void __iomem *db_ptr = NULL;
- unsigned long mem_base, mem_len, db_base, db_len = 0, pci_len0 = 0;
+ resource_size_t mem_base, db_base;
+ unsigned long mem_len, db_len = 0, pci_len0 = 0;
struct pci_dev *pdev = adapter->pdev;
int pci_func = adapter->ahw.pci_func;
--
1.6.0.2
^ permalink raw reply related
* Re: PATCH: Network Device Naming mechanism and policy
From: Bryan Kadzban @ 2009-10-12 6:21 UTC (permalink / raw)
To: Greg KH
Cc: Matt Domsch, Stephen Hemminger, netdev, linux-hotplug, Narendra_K,
jordan_hargrave
In-Reply-To: <20091010211352.GC1927@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 3285 bytes --]
Greg KH wrote:
> On Sat, Oct 10, 2009 at 10:34:16AM -0700, Bryan Kadzban wrote:
>> Greg KH wrote:
>>> On Sat, Oct 10, 2009 at 07:47:32AM -0500, Matt Domsch wrote:
>>>> On Fri, Oct 09, 2009 at 10:23:08PM -0700, Greg KH wrote:
>>>>> On Fri, Oct 09, 2009 at 11:40:57PM -0500, Matt Domsch wrote:
>>>>>> The fundamental roadblock to this is that enumeration !=
>>>>>> naming, except that it is for network devices, and we keep
>>>>>> changing the enumeration order.
>>>>> No, the hardware changes the enumeration order, it places
>>>>> _no_ guarantees on what order stuff will be found in. So
>>>>> this is not the kernel changing, just to be clear.
>>>> Over time the kernel has changed its enumeration mechanisms,
>>>> and introduced parallelism into the process (which is a good
>>>> thing), which, from a user perspective, makes names
>>>> nondeterministic. Yes, fixing this up by hard-coding MAC
>>>> addresses after install has been the traditional mechanism to
>>>> address this. I think there's a better way.
>>> Ok, but that way can be done in userspace, without the need for
>>> this char device, right?
>> For the record -- when I tried to send a patch that did exactly
>> this (provided an option to use by-path persistence for network
>> drivers), it was rejected because "that doesn't work for USB".
>>
>> True, it doesn't. But by-mac (what we have today) doesn't work for
>> replacing motherboards in a random home system (that can't override
>> the MAC address in the BIOS), either.
>
> If you replace a motherboard, you honestly expect no configuration to
> be needed to be changed? If so, then don't use the MAC naming scheme
> for your systems.
What else is there? biosdevname doesn't work with this BIOS. It looks
like at least path_id has been updated to work with NICs now, so that
might work, with a bit of custom rule hacking.
Or at least, it won't work any more poorly than for disks, which seem to
work pretty well... :-)
>>> But this code is not a requirement to "solve" the fact that
>>> network devices can show up in different order, that problem can
>>> be solved as long as the user picks a single way to name the
>>> devices, using tools that are already present today in distros.
>> This code is not a requirement, no. But -- as you say -- it does
>> provide a halfway-decent way to assign multiple names to a NIC.
>> And that provides admins the choice to use a couple different
>> persistence schemes, depending on how they expect their hardware to
>> work.
>
> But the names need to then be resolved back to a "real" kernel name
> in order to do anything with that network connection, as the char
> devices are not real ones. So that adds an additional layer of
> complexity on all of the system configuration tools.
Yes, that is true -- and no, this change isn't perfect. But it lets me
have multiple "names" per interface, and have "names" that are longer
than IFNAMSIZ, though, which is why I like it.
(Now, if open() would return effectively a netlink socket bound to that
ifindex already, such that the program didn't need to fill in the
various ifindex fields for e.g. rtnetlink... but it's probably really
hard to do that, so this isn't a serious suggestion.)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* Re: [PATCHv2] netxen: fix pci bar mapping
From: David Miller @ 2009-10-12 6:22 UTC (permalink / raw)
To: dhananjay; +Cc: netdev
In-Reply-To: <1255328031-17189-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Sun, 11 Oct 2009 23:13:51 -0700
> Use phys_addr_t data type for pci resource address
> instead of unsigned long. This fixes mapping of
> pci resources where resource addresses can be larger
> than word size (e.g. PAE).
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Lazy, you didn't update the commit log message to match the
change you made to the patch.
I think I'll just ignore your patches for a while until
you start to be a little bit less careless.
Thanks.
^ permalink raw reply
* Re: [net-next PATCH 0/8] qlge: Cleanup and additions for qlge.
From: David Miller @ 2009-10-12 6:26 UTC (permalink / raw)
To: ron.mercer; +Cc: netdev
In-Reply-To: <1255203310-18114-1-git-send-email-ron.mercer@qlogic.com>
From: Ron Mercer <ron.mercer@qlogic.com>
Date: Sat, 10 Oct 2009 12:35:02 -0700
>
> Cleanup and a couple of small performance tweeks for qlge.
All applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: [PATCHv2] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 6:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20091011.232203.41690616.davem@davemloft.net>
Huh, okay I was impatient. I will make one more attempt to pass the test.
Thanks.
David Miller wrote:
> I think I'll just ignore your patches for a while until
> you start to be a little bit less careless.
>
> Thanks.
>
^ permalink raw reply
* [PATCHv3] netxen: fix pci bar mapping
From: Dhananjay Phadke @ 2009-10-12 6:39 UTC (permalink / raw)
To: davem; +Cc: netdev
Use resource_size_t for PCI resource remapping instead
of unsigned long. Physical addresses can exceed range of
long data type (e.g with PAE).
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
---
drivers/net/netxen/netxen_nic_main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/netxen/netxen_nic_main.c b/drivers/net/netxen/netxen_nic_main.c
index 9b9eab1..7fc15e9 100644
--- a/drivers/net/netxen/netxen_nic_main.c
+++ b/drivers/net/netxen/netxen_nic_main.c
@@ -595,7 +595,8 @@ netxen_setup_pci_map(struct netxen_adapter *adapter)
void __iomem *mem_ptr2 = NULL;
void __iomem *db_ptr = NULL;
- unsigned long mem_base, mem_len, db_base, db_len = 0, pci_len0 = 0;
+ resource_size_t mem_base, db_base;
+ unsigned long mem_len, db_len = 0, pci_len0 = 0;
struct pci_dev *pdev = adapter->pdev;
int pci_func = adapter->ahw.pci_func;
--
1.6.0.2
^ permalink raw reply related
* Re: PATCH: Network Device Naming mechanism and policy
From: Kurt Van Dijck @ 2009-10-12 7:30 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Matt Domsch, netdev, linux-hotplug, Narendra_K, jordan_hargrave
In-Reply-To: <20091010113219.3136fb8b@s6510>
On Sat, Oct 10, 2009 at 11:32:19AM -0700, Stephen Hemminger wrote:
> > On Fri, Oct 09, 2009 at 07:44:01PM -0700, Stephen Hemminger wrote:
[...]
>
> Why isn't the available through sysfs enough, if not why not
> add the necessary attributes there.
True. If sysfs is not sufficient, what exact naming scheme could be
applied that the chardev based naming could use?
>
[...]
Kurt
^ permalink raw reply
* Re: [RESEND PATCH net-next-2.6 3/3] ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
From: Eric Dumazet @ 2009-10-12 7:32 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: davem, netdev
In-Reply-To: <4AD1E169.6090705@linux-ipv6.org>
YOSHIFUJI Hideaki a écrit :
> ipv6 sit: Set relay to 0.0.0.0 directly if relay_prefixlen == 0.
>
> Do not use bit-shift if relay_prefixlen == 0;
> relay_prefix << 32 does not result in 0.
>
> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> ---
> net/ipv6/sit.c | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
> index 193d0c6..510d31f 100644
> --- a/net/ipv6/sit.c
> +++ b/net/ipv6/sit.c
> @@ -1014,9 +1014,12 @@ ipip6_tunnel_ioctl (struct net_device *dev, struct ifreq *ifr, int cmd)
> ip6rd.prefixlen);
> if (!ipv6_addr_equal(&prefix, &ip6rd.prefix))
> goto done;
> - relay_prefix = ip6rd.relay_prefix &
> - htonl(0xffffffffUL <<
> - (32 - ip6rd.relay_prefixlen));
> + if (ip6rd.relay_prefixlen)
> + relay_prefix = ip6rd.relay_prefix &
> + htonl(0xffffffffUL <<
> + (32 - ip6rd.relay_prefixlen));
> + else
> + relay_prefix = 0;
> if (relay_prefix != ip6rd.relay_prefix)
> goto done;
>
Sorry I dont get it
u32 val = any_value ;
u32 relay_prefix = val & htonl(0xffffffffUL << 32) should give 0
If not, something is broken and should be fixed.
^ permalink raw reply
* Re: bisect results of MSI-X related panic (help!)
From: Tejun Heo @ 2009-10-12 7:52 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: Frans Pop, Jesse Brandeburg, linux-kernel, netdev, Ingo Molnar,
hpa
In-Reply-To: <4807377b0910091724k2a332e90i9941971f6032663c@mail.gmail.com>
Jesse Brandeburg wrote:
> Kernel stack is corrupted in: ffffffff810b5b31
>
> I've built with a full debug kernel before this crash, so I did:
>
> (gdb) l *0xffffffff810b5b31
> 0xffffffff810b5b31 is in move_native_irq (kernel/irq/migration.c:67).
> 62 return;
> 63
> 64 desc->chip->mask(irq);
> 65 move_masked_irq(irq);
> 66 desc->chip->unmask(irq);
>>>> 67 }
> 68
> (gdb) l move_native_irq
> 54 void move_native_irq(int irq)
> 55 {
> 56 struct irq_desc *desc = irq_to_desc(irq);
> 57
> 58 if (likely(!(desc->status & IRQ_MOVE_PENDING)))
> 59 return;
> 60
> 61 if (unlikely(desc->status & IRQ_DISABLED))
> 62 return;
> 63
> 64 desc->chip->mask(irq);
> 65 move_masked_irq(irq);
> 66 desc->chip->unmask(irq);
> 67 }
>
> So, this seems very related to my panic, as it is likely that
> irqbalance or something else might try to move my interrupt from one
> core to another and this seems likely related, and the original issue
> as well as this one reproduce with LOTS of MSI-X vectors active.
>
> - I tried connecting after the panic with kgdboc, no connection
> - I tried kdump, but the same kernel I am using panics/hangs during
> boot right after udev during the kexec() kernel boot (should I try
> harder to get this working given it got so far?)
> - I have ftrace function tracer running but no way to get at the log
> post panic (wouldn't it be great if the kernel just dumped the ftrace
> log on __stack_chk_fail?)
>
> any other debugging tricks/ideas?
Hmm... stackprotector adds considerable amount of stack usage and it
could be you're seeing stack overflow which would also explain the
random crashes you've been seeing. Do you have DEBUG_STACKOVERFLOW
turned on? This is on x86_64, right?
--
tejun
^ 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