* 2.6.34-rc3-git8: Reported regressions 2.6.32 -> 2.6.33
From: Rafael J. Wysocki @ 2010-04-08 22:54 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some post-2.6.32 regressions introduced before
2.6.33, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.32 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-04-09 140 34 33
2010-03-21 133 38 34
2010-02-21 115 34 27
2010-02-15 112 34 31
2010-02-07 97 27 20
2010-02-01 85 26 21
2010-01-24 75 29 23
2010-01-10 55 33 21
2009-12-29 36 34 27
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15733
Subject : Crash when accessing nonexistent GTT entries in i915
Submitter : Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Date : 2010-03-10 22:09 (30 days old)
Message-ID : <1268258994.2183.14.camel@carter>
References : http://marc.info/?l=linux-kernel&m=126825901326111&w=4
Handled-By : Zhenyu Wang <zhenyuw@linux.intel.com>
Andrew Morton <akpm@linux-foundation.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15714
Subject : PROBLEM: intelfb driver causes trace
Submitter : Troilo, Domenic <Domenic.Troilo@gwl.ca>
Date : 2010-04-01 14:52 (8 days old)
Message-ID : <CBF11783AA883E41A86C009F3AE5D47F0CAE08C1@GWCORPMAIL4.gwl.bz>
References : http://marc.info/?l=linux-kernel&m=127013359722664&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15710
Subject : NumLock LED stays on after PC poweroff.
Submitter : aceman <acelists@atlas.sk>
Date : 2010-04-07 15:13 (2 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15699
Subject : rt2500usb driver cannot remain connected
Submitter : <abcd@gentoo.org>
Date : 2010-04-05 19:30 (4 days old)
Handled-By : Ivo van Doorn <IvDoorn@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15695
Subject : calling pm-suspend freezes system
Submitter : Werner Lemberg <wl@gnu.org>
Date : 2010-04-05 05:13 (4 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15693
Subject : Plugging or unplugging notebook charger renders Atheros card unusable
Submitter : <registosites1@hotmail.com>
Date : 2010-04-04 21:03 (5 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15604
Subject : r8169: Reports incorrect link information
Submitter : Michael B. Trausch <mike@trausch.us>
Date : 2010-03-22 04:19 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15585
Subject : [Bisected Regression in 2.6.32.8] i915 with KMS enabled causes memorycorruption when resuming from suspend-to-disk
Submitter : M. Vefa Bicakci <bicave@superonline.com>
Date : 2010-03-13 5:11 (27 days old)
First-Bad-Commit: http://git.kernel.org/git/linus/d8e0902806c0bd2ccc4f6a267ff52565a3ec933b
Message-ID : <4B9B1E8F.5090806@superonline.com>
References : http://marc.info/?l=linux-kernel&m=126845754409543&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15544
Subject : black screen upon S3 resume, syslog has "render error" and "page table error"
Submitter : Sanjoy Mahajan <sanjoy@mit.edu>
Date : 2010-03-16 00:45 (24 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15534
Subject : 07ca:b808 crashing and breaking usb's
Submitter : Alex Fiestas <alex@eyeos.org>
Date : 2010-03-14 15:56 (26 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15525
Subject : Blank screen after some time, after hibernation/suspend
Submitter : <capsel@matrix.inten.pl>
Date : 2010-03-12 17:24 (28 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15502
Subject : render error detected, EIR: 0x00000010
Submitter : Artem Anisimov <aanisimov@inbox.ru>
Date : 2010-03-10 05:45 (30 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15466
Subject : 2.6.33 dies on modprobe
Submitter : M G Berberich <berberic@fmi.uni-passau.de>
Date : 2010-02-28 22:12 (40 days old)
Message-ID : <20100228221257.GA8858@invalid>
References : http://marc.info/?l=linux-kernel&m=126739570819208&w=2
Handled-By : Américo Wang <xiyou.wangcong@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15465
Subject : 2.6.33 problems
Submitter : werner@guyane.dyn-o-saur.com
Date : 2010-02-27 17:09 (41 days old)
Message-ID : <1267290551.13148@guyane.dyn-o-saur.com>
References : http://marc.info/?l=linux-kernel&m=126729183719672&w=2
Handled-By : Tejun Heo <tj@kernel.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15454
Subject : r8169 exits with error -22 since 2.6.33
Submitter : Conrad Kostecki <ConiKost@gmx.de>
Date : 2010-03-05 22:32 (35 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15439
Subject : Laptop does consume more power when booted "cold" -- Thinkpad X200s
Submitter : <johannes.schlatow@googlemail.com>
Date : 2010-03-03 23:09 (37 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15418
Subject : battery status info broken; missing entry in ec_dmi_table for specific MSI hardware (notebook)
Submitter : Tom-Steve Watzke <tswatzke@arcor.de>
Date : 2010-03-01 07:25 (39 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15392
Subject : The kernel does not start up.
Submitter : Kristóf Ralovich <kristof.ralovich@gmail.com>
Date : 2010-02-25 06:52 (43 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15376
Subject : regression (oops) with usb in 2.6.33-rc8
Submitter : Christophe Fergeau <cfergeau@mandriva.com>
Date : 2010-02-23 10:58 (45 days old)
Handled-By : Sarah Sharp <sarah.a.sharp@linux.intel.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15317
Subject : Lockdep report while running aplay with pulse as the default
Submitter : Ed Tomlinson <edt@aei.ca>
Date : 2010-02-13 17:17 (55 days old)
Message-ID : <201002131217.10579.edt@aei.ca>
References : http://marc.info/?l=linux-kernel&m=126608146427546&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15311
Subject : Starting pulseaudio causes a NULL pointer hit
Submitter : Ed Tomlinson <edt@aei.ca>
Date : 2010-02-14 23:41 (54 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15305
Subject : Dell video dies when booting
Submitter : David Ronis <ronis@ronispc.chem.mcgill.ca>
Date : 2010-02-14 1:07 (54 days old)
Message-ID : <1266109622.11290.10.camel@montroll.chem.mcgill.ca>
References : http://marc.info/?l=linux-kernel&m=126611098225127&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15278
Subject : lockdep warning for iscsi in 2.6.33-rc6
Submitter : Tao Ma <tao.ma@oracle.com>
Date : 2010-02-09 6:59 (59 days old)
Message-ID : <4B7107CF.3060703@oracle.com>
References : http://marc.info/?l=linux-kernel&m=126569884330200&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15277
Subject : 2.6.33-rc6 crashes on resume
Submitter : Bill Davidsen <davidsen@roadwarrior3.tmr.com>
Date : 2010-02-08 23:03 (60 days old)
Message-ID : <4B70982F.8090208@roadwarrior3.tmr.com>
References : http://marc.info/?l=linux-kernel&m=126567021801935&w=2
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15276
Subject : latest git kernel: general protection fault: 0000 [#1]
Submitter : Markus Trippelsdorf <markus@trippelsdorf.de>
Date : 2010-02-09 8:36 (59 days old)
Message-ID : <20100209083605.GA1766@arch.tripp.de>
References : http://marc.info/?l=linux-kernel&m=126570498804223&w=2
Handled-By : Jérôme Glisse <glisse@freedesktop.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15259
Subject : Corruption with OpenGL since Intel's big DRM push on i945
Submitter : Alexandre Demers <papouta@hotmail.com>
Date : 2010-02-08 13:19 (60 days old)
First-Bad-Commit: http://git.kernel.org/git/linus/76446cac68568fc7f5168a27deaf803ed22a4360
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15246
Subject : BUG: Bad page state in process portageq
Submitter : Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
Date : 2010-02-07 0:45 (61 days old)
References : http://marc.info/?l=linux-kernel&m=126550356515887&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15244
Subject : PROBLEM: hda-intel divide by zero kernel crash in azx_position_ok()
Submitter : Jody Bruchon <jody@nctritech.com>
Date : 2010-02-06 0:32 (62 days old)
References : http://marc.info/?l=linux-kernel&m=126541276028173&w=2
Handled-By : Takashi Iwai <tiwai@suse.de>
Jody Bruchon <jody@nctritech.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15076
Subject : System panic under load with clockevents_program_event
Submitter : okias <d.okias@gmail.com>
Date : 2010-01-17 13:03 (82 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15036
Subject : soft lockup in dmesg after suspend/resume
Submitter : ykzhao <yakui.zhao@intel.com>
Date : 2010-01-04 5:36 (95 days old)
References : http://marc.info/?l=linux-kernel&m=126258356202722&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14950
Subject : tbench regression with 2.6.33-rc1
Submitter : Lin Ming <ming.m.lin@intel.com>
Date : 2009-12-25 11:11 (105 days old)
References : http://marc.info/?l=linux-kernel&m=126174044213172&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14937
Subject : WARNING: at kernel/lockdep.c:2830
Submitter : Grant Wilson <grant.wilson@zen.co.uk>
Date : 2009-12-27 13:35 (103 days old)
References : http://marc.info/?l=linux-kernel&m=126192220404829&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14792
Subject : Misdetection of the TV output
Submitter : Santi <santi@agolina.net>
Date : 2009-12-12 13:28 (118 days old)
First-Bad-Commit: http://git.kernel.org/git/linus/27dfaf4f5825a119305db1bc63bef30ed400e376
Handled-By : Zhao Yakui <yakui.zhao@intel.com>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15328
Subject : high load avg, extreme sluggishness on T41 w/ Radeon Mobility M7
Submitter : John W. Linville <linville@tuxdriver.com>
Date : 2010-02-16 20:25 (52 days old)
Handled-By : Francisco Jerez <currojerez@riseup.net>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=25118
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.32 and 2.6.33, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=14885
Please let the tracking teak know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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
* Re: [PATCH 1/1] add ethtool loopback support
From: Laurent Chavey @ 2010-04-08 22:43 UTC (permalink / raw)
To: Ben Hutchings; +Cc: davem, netdev, therbert
In-Reply-To: <1270755356.5055.23.camel@achroite.uk.solarflarecom.com>
On Thu, Apr 8, 2010 at 12:35 PM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> On Thu, 2010-04-08 at 12:17 -0700, Laurent Chavey wrote:
>> On Thu, Apr 8, 2010 at 11:29 AM, Ben Hutchings
>> <bhutchings@solarflare.com> wrote:
>> > On Thu, 2010-04-08 at 10:35 -0700, chavey@google.com wrote:
> [...]
>> >> +enum ethtool_loopback_type {
>> >> + ETH_MAC = 0x00000001,
>> >> + ETH_PHY_INT = 0x00000002,
>> >> + ETH_PHY_EXT = 0x00000004
>> >> +};
>> > [...]
>> >
>> > There are many different places you can loop back within a MAC or PHY,
>> > not to mention bypassing the MAC altogether. See
>> > drivers/net/sfc/mcdi_pcol.h, starting from the line
>> > '#define MC_CMD_LOOPBACK_NONE 0'. I believe we implement all of those
>> > loopback modes on at least one board.
>> >
>> > Also are these supposed to be an enumeration or flags? In theory you
>> those are enums that can be or together.
>
> I.e. they are flags. So how do you answer this:
>
>> > could use wire-side and host-side loopback at the same time if they
>> > don't overlap, but it's probably too much trouble to bother with. Any
>> > other combination is meaningless.
since the intent is to enable the sending and receiving of packets at
the hw/driver interfaces, a simple loopback mode on/off is sufficient
and the ethtool_loopback_type are not necessary. the implementor can choose
how to implement the loopback. From drivers/net/sfc/mcdi_pcol.h it is clear
that unless ethtool_loopback_type as defined are meaningless.
> Ben.
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
>
^ permalink raw reply
* [PATCH] cnic: Give a chance for the uio device to be opened before failing the path request
From: Benjamin Li @ 2010-04-08 21:34 UTC (permalink / raw)
To: netdev@vger.kernel.org, Michael Chan; +Cc: Benjamin Li, Eddie Wai
There is a timing condition; where the time between the CNIC's
/dev/uio* device registration and then the issuing of path requests
messages is faster the brcm_iscsiuio daemon initializing.
This can be seen if one sets the machine to automatically login into
iSCSI targets. Then reset the network and iscsi daemons in quick
succession. The login will fail because iscsid will only try
a couple of times in quick succession. This patch will allow some
additional needed time for the brcm_iscsiuio daemon to initialize
before failing the path request call.
Signed-off-by: Benjamin Li <benli@broadcom.com>
Signed-off-by: Eddie Wai <waie@broadcom.com>
---
drivers/net/cnic.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/net/cnic.c b/drivers/net/cnic.c
index 9781942..897f171 100644
--- a/drivers/net/cnic.c
+++ b/drivers/net/cnic.c
@@ -274,9 +274,17 @@ static int cnic_send_nlmsg(struct cnic_local *cp, u32 type,
u16 len = 0;
u32 msg_type = ISCSI_KEVENT_IF_DOWN;
struct cnic_ulp_ops *ulp_ops;
+ int count = 0;
- if (cp->uio_dev == -1)
+ while (count < 40 && cp->uio_dev == -1) {
+ msleep(50);
+ count++;
+ }
+
+ if (cp->uio_dev == -1) {
+ netdev_warn(cp->dev->netdev, "no uio dev to send nl request\n");
return -ENODEV;
+ }
if (csk) {
len = sizeof(path_req);
--
1.6.1.2
^ permalink raw reply related
* Re: HTB - What's the minimal value for 'rate' parameter?
From: Jarek Poplawski @ 2010-04-08 21:33 UTC (permalink / raw)
To: Antonio Almeida; +Cc: netdev, kaber, davem, devik
In-Reply-To: <z2q298f5c051004080407r5dfb27fai74c5cf74d0048ca5@mail.gmail.com>
Antonio Almeida wrote, On 04/08/2010 01:07 PM:
> Hi!
Hi!
> I've been using HTB for a while, and we've already sent some e-mails
> each other when resolving HTB accuracy issue.
> When using HTB, I realised that for some configurations the rate limit
> doesn't work.
> I suspect that the problem is the minimum value of rate parameter,
> which I cant figure out what is.
>
> I simple configuration that turns out to be wrong is as fallows: The
> root (1:1) gets the link bandwidth configuration; the second (1:2) is
> set to 4096Kbit; then I have two branches (1:10 and 1:11) with rate
> 1024Kbit and ceil 4096Kbit; and finally a leaf class in each branch
> (1:111 below 1:11, and 1:101 below 1:10) with rate 8bit and ceil
> 4096Kbit, and the same priority.
> I don't want to have sustained rate, and since I must configure 'rate'
> parameter I decide to set it to 8bits - which is the minimal accepted
> value. My cue goes for 'rate' parameter. If I set 'rate' parameter to
> 1Kbit for instance, the problem disappears and the shaping is done
> perfectly.
>
> So, I'm looking for help to find out if the problem is actually in
> this parameter configuration or if it's just coincidence and I'll get
> the same problem ahead :(
> What's the minimal value for 'rate' parameter using HTB qdisc?
I think "reasonable" or "minimally useful" (for common use) should be
enough, and 8bits meaning one 1500 byte packet per 25 minutes or
something, doesn't look like this to me.
This changelog:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a4a710c4a7490587406462bf1d54504b7783d7d7
mentions ~2 minutes as max time for accounting, so 1 max packet
per 2 minutes should give such a minimal rate, I guess, but I'd
still multiply it a few times to call it useful.
Regards,
Jarek P.
^ permalink raw reply
* Re: [PATCH 1/1] add ethtool loopback support
From: Laurent Chavey @ 2010-04-08 21:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Ben Hutchings, davem, netdev, therbert
In-Reply-To: <4BBE33C9.5000507@garzik.org>
On Thu, Apr 8, 2010 at 12:51 PM, Jeff Garzik <jeff@garzik.org> wrote:
> On 04/08/2010 02:29 PM, Ben Hutchings wrote:
>>
>> On Thu, 2010-04-08 at 10:35 -0700, chavey@google.com wrote:
>>>
>>> From: Ranjit Manomohan<ranjitm@google.com>
>>> Date: Wed, 7 Apr 2010 15:19:48 -0700
>>>
>>> Add an ethtool option to use internal loopback mode for testing.
>>> This feature is used for component and driver test coverage by putting
>>> the device in hardware loopback mode and sending / receiving network
>>> traffic from a user application to test the hardware and driver
>>> transmit / receive paths.
>>>
>>> Signed-off-by: laurent chavey<chavey@google.com>
>>> ---
>>> include/linux/ethtool.h | 16 ++++++++++++++++
>>> net/core/ethtool.c | 40 ++++++++++++++++++++++++++++++++++++++++
>>> 2 files changed, 56 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>>> index b33f316..df1dcc7 100644
>>> --- a/include/linux/ethtool.h
>>> +++ b/include/linux/ethtool.h
>>> @@ -292,6 +292,18 @@ struct ethtool_stats {
>>> __u64 data[0];
>>> };
>>>
>>> +/* for setting the NIC into loopback mode */
>>> +struct ethtool_loopback {
>>> + u32 cmd; /* ETHTOOL_SLOOPBACK */
>>> + u32 type; /* ethtool_loopback_type */
>>> +};
>>> +
>>> +enum ethtool_loopback_type {
>>> + ETH_MAC = 0x00000001,
>>> + ETH_PHY_INT = 0x00000002,
>>> + ETH_PHY_EXT = 0x00000004
>>> +};
>>
>> [...]
>>
>> There are many different places you can loop back within a MAC or PHY,
>> not to mention bypassing the MAC altogether. See
>> drivers/net/sfc/mcdi_pcol.h, starting from the line
>> '#define MC_CMD_LOOPBACK_NONE 0'. I believe we implement all of those
>> loopback modes on at least one board.
>>
>> Also are these supposed to be an enumeration or flags? In theory you
>> could use wire-side and host-side loopback at the same time if they
>> don't overlap, but it's probably too much trouble to bother with. Any
>> other combination is meaningless.
>
>
> Additionally, ethtool is intended as an interface that exports capabilities
> generally useful to users. Is this feature really something that users will
> make use of? It seems more in the realm of design validation
>
> The existing ETHTOOL_TEST ioctl was intended as a coarse-grained method of
> verifying that the NIC is working, because fine-grained tests are inevitably
> both NIC-specific, and too involved for all but the most sophisticated users
> (read: the designers who built the NIC).
>
> So, consider this a _weak_ objection. Sure we could implement this, but
> will it really be useful to most users?
we have some autotests that make use of this feature for e1000(e), forcedeth and
tg3 that we would like to share with the community to do perf / functional tests
regression.
>
> Jeff
>
>
>
^ permalink raw reply
* Re: 2.6.34-rc3-git6: Reported regressions from 2.6.33
From: Rafael J. Wysocki @ 2010-04-08 20:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI, Al Viro
In-Reply-To: <alpine.LFD.2.00.1004071444440.3586-GpypE611fyS63QaFMGN2QEqCLAeBNdoH@public.gmane.org>
On Thursday 08 April 2010, Linus Torvalds wrote:
>
> On Wed, 7 Apr 2010, Rafael J. Wysocki wrote:
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15718
> > Subject : File corruption regression on NFS related to commit 1f36f774
> > Submitter : Boaz Harrosh <bharrosh-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
> > Date : 2010-03-24 15:49 (15 days old)
> > First-Bad-Commit: http://git.kernel.org/git/linus/1f36f774b22a0ceb7dd33eca626746c81a97b6a5
> > Message-ID : <4BAA3493.1030802-C4P08NqkoRlBDgjK7y7TUQ@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=126944579810350&w=4
> > Handled-By : Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
>
> I think this one is fixed by commit 3e297b61349.
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15716
> > Subject : ata2: lost interrupt with kernel 2.6.34-rc1
> > Submitter : Andrew Benton <b3nton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-03-11 16:57 (28 days old)
> > Message-ID : <4B992110.2090300-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=126832670609705&w=4
> > Handled-By : Jeff Garzik <jeff-o2qLIJkoznsdnm+yROfE0A@public.gmane.org>
>
> And isn't this the already long-fixed commit 332ac7ff77cd?
>
> That bugzilla entry is a duplicate of
>
> https://bugzilla.kernel.org/show_bug.cgi?id=15537
>
> as far as I can see.
Yes, my bad, sorry. Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15715
> > Subject : vmscan: underflow for get_scan_ratio
> > Submitter : Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Date : 2010-03-30 5:53 (9 days old)
> > First-Bad-Commit: http://git.kernel.org/git/linus/84b18490d1f1bc7ed5095c929f78bc002eb70f26
> > Message-ID : <20100330055304.GA2983-U5EdaLXB8smDugQYiPIPGdh3ngVCH38I@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=126992842105754&w=4
> > Handled-By : KOSAKI Motohiro <kosaki.motohiro-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> > Wu Fengguang <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> That commit got reverted. See commit d6da1a5abc.
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15674
> > Subject : [2.6.34-rc2 NFS4 oops] open error path failure...
> > Submitter : Daniel J Blueman <daniel.blueman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Date : 2010-03-29 18:36 (10 days old)
> > Message-ID : <6278d2221003291136p6481fe8emfb039403343c082-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=126988782722711&w=2
>
> This smells like the same LOOKUP_DIRECTORY thing as the first entry, but..
>
> Al?
This one has been fixed too, I see, so closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15600
> > Subject : CONFIG_NO_BOOTMEM woes, 2.6.34-rc1
> > Submitter : Avi Kivity <avi-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Date : 2010-03-15 15:28 (24 days old)
> > Message-ID : <4B9E5211.9000204-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > References : http://marc.info/?l=linux-kernel&m=126866691701926&w=2
>
> These should hopefully be all fixed. There was some confusion over this,
> but the report that said it wasn't fixed in -rc3 was apparently not true
> after all. Several commits, but mainly commit eed63519e, iirc.
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15518
> > Subject : CONFIG_NO_BOOTMEM=y breaks boot on 32bit
> > Submitter : Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
> > Date : 2010-03-11 15:37 (28 days old)
>
> Duplicate entry. See above.
Closed.
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15480
> > Subject : [regression] Fails to boot properly unless given pci=nocrs
> > Submitter : Yanko Kaneti <yaneti-jUE9FD3ILm5BDgjK7y7TUQ@public.gmane.org>
> > Date : 2010-03-09 01:24 (30 days old)
> > Handled-By : Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
> > Patch : http://lkml.org/lkml/2010/3/11/512
>
> These are merged already. Commits d558b483d5, eb9fc8ef7cb etc.
Closed.
Thanks,
Rafael
^ permalink raw reply
* Re: linux-next: powerpc boot failure
From: David Miller @ 2010-04-08 20:13 UTC (permalink / raw)
To: tony.luck; +Cc: timo.teras, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <o2s12c511ca1004081155o9b28c9f5hdfadd075913f1fcf@mail.gmail.com>
From: Tony Luck <tony.luck@intel.com>
Date: Thu, 8 Apr 2010 11:55:34 -0700
> I tried the patch you just posted. Compiling with it gave this warning:
>
> net/xfrm/xfrm_policy.c: In function ‘__xfrm_lookup’:
> net/xfrm/xfrm_policy.c:1735: warning: ‘num_xfrms’ may be used
> uninitialized in this function
This is just because gcc is stupid, you can ignore this.
It can't see that when a real 'err' error is returned we never end up
referencing the num_xfrms value.
> but the patched kernel booted ok.
Thanks for testing, I pushed Timo's fix to net-next-2.6 earlier today
so it'll hopefully show up in the next linux-next.
^ permalink raw reply
* Re: [PATCH 1/1] add ethtool loopback support
From: Rick Jones @ 2010-04-08 20:03 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Ben Hutchings, chavey, davem, netdev, therbert
In-Reply-To: <4BBE33C9.5000507@garzik.org>
> Additionally, ethtool is intended as an interface that exports
> capabilities generally useful to users. Is this feature really
> something that users will make use of? It seems more in the realm of
> design validation
In enterprise days gone by, performing loopback tests were a part of hardware
problem diagnosis in the field - either by SEs or customers.
rick jones
^ permalink raw reply
* Re: [PATCH 1/1] add ethtool loopback support
From: Jeff Garzik @ 2010-04-08 19:51 UTC (permalink / raw)
To: Ben Hutchings, chavey; +Cc: davem, netdev, therbert
In-Reply-To: <1270751373.5055.22.camel@achroite.uk.solarflarecom.com>
On 04/08/2010 02:29 PM, Ben Hutchings wrote:
> On Thu, 2010-04-08 at 10:35 -0700, chavey@google.com wrote:
>> From: Ranjit Manomohan<ranjitm@google.com>
>> Date: Wed, 7 Apr 2010 15:19:48 -0700
>>
>> Add an ethtool option to use internal loopback mode for testing.
>> This feature is used for component and driver test coverage by putting
>> the device in hardware loopback mode and sending / receiving network
>> traffic from a user application to test the hardware and driver
>> transmit / receive paths.
>>
>> Signed-off-by: laurent chavey<chavey@google.com>
>> ---
>> include/linux/ethtool.h | 16 ++++++++++++++++
>> net/core/ethtool.c | 40 ++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 56 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> index b33f316..df1dcc7 100644
>> --- a/include/linux/ethtool.h
>> +++ b/include/linux/ethtool.h
>> @@ -292,6 +292,18 @@ struct ethtool_stats {
>> __u64 data[0];
>> };
>>
>> +/* for setting the NIC into loopback mode */
>> +struct ethtool_loopback {
>> + u32 cmd; /* ETHTOOL_SLOOPBACK */
>> + u32 type; /* ethtool_loopback_type */
>> +};
>> +
>> +enum ethtool_loopback_type {
>> + ETH_MAC = 0x00000001,
>> + ETH_PHY_INT = 0x00000002,
>> + ETH_PHY_EXT = 0x00000004
>> +};
> [...]
>
> There are many different places you can loop back within a MAC or PHY,
> not to mention bypassing the MAC altogether. See
> drivers/net/sfc/mcdi_pcol.h, starting from the line
> '#define MC_CMD_LOOPBACK_NONE 0'. I believe we implement all of those
> loopback modes on at least one board.
>
> Also are these supposed to be an enumeration or flags? In theory you
> could use wire-side and host-side loopback at the same time if they
> don't overlap, but it's probably too much trouble to bother with. Any
> other combination is meaningless.
Additionally, ethtool is intended as an interface that exports
capabilities generally useful to users. Is this feature really
something that users will make use of? It seems more in the realm of
design validation
The existing ETHTOOL_TEST ioctl was intended as a coarse-grained method
of verifying that the NIC is working, because fine-grained tests are
inevitably both NIC-specific, and too involved for all but the most
sophisticated users (read: the designers who built the NIC).
So, consider this a _weak_ objection. Sure we could implement this, but
will it really be useful to most users?
Jeff
^ permalink raw reply
* Re: [PATCH 1/1] add ethtool loopback support
From: Ben Hutchings @ 2010-04-08 19:35 UTC (permalink / raw)
To: Laurent Chavey; +Cc: davem, netdev, therbert
In-Reply-To: <w2i97949e3e1004081217jdeca953dz162c62b61c0e8f72@mail.gmail.com>
On Thu, 2010-04-08 at 12:17 -0700, Laurent Chavey wrote:
> On Thu, Apr 8, 2010 at 11:29 AM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
> > On Thu, 2010-04-08 at 10:35 -0700, chavey@google.com wrote:
[...]
> >> +enum ethtool_loopback_type {
> >> + ETH_MAC = 0x00000001,
> >> + ETH_PHY_INT = 0x00000002,
> >> + ETH_PHY_EXT = 0x00000004
> >> +};
> > [...]
> >
> > There are many different places you can loop back within a MAC or PHY,
> > not to mention bypassing the MAC altogether. See
> > drivers/net/sfc/mcdi_pcol.h, starting from the line
> > '#define MC_CMD_LOOPBACK_NONE 0'. I believe we implement all of those
> > loopback modes on at least one board.
> >
> > Also are these supposed to be an enumeration or flags? In theory you
> those are enums that can be or together.
I.e. they are flags. So how do you answer this:
> > could use wire-side and host-side loopback at the same time if they
> > don't overlap, but it's probably too much trouble to bother with. Any
> > other combination is meaningless.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH] Fix some #includes in CAN drivers
From: Hans J. Koch @ 2010-04-08 19:25 UTC (permalink / raw)
To: socketcan-core
Cc: netdev, kernel, Barry Song, Chris Elston, Christian Pellegrin,
Wolfgang Grandegger, Sebastian Haas, Per Dalen, Pavel Cheblakov,
Oliver Hartkopp, Anant Gole
In the current implementation, CAN drivers need to #include <linux/can.h>
_before_ they #include <linux/can/dev.h>, which is both ugly and
unnecessary.
Fix this by including <linux/can.h> in <linux/can/dev.h> and remove the
#include <linux/can.h> lines from drivers.
Signed-off-by: Hans J. Koch <hjk@linutronix.de>
---
drivers/net/can/at91_can.c | 1 -
drivers/net/can/bfin_can.c | 1 -
drivers/net/can/mcp251x.c | 1 -
drivers/net/can/mscan/mpc5xxx_can.c | 1 -
drivers/net/can/mscan/mscan.c | 1 -
drivers/net/can/sja1000/ems_pci.c | 1 -
drivers/net/can/sja1000/kvaser_pci.c | 1 -
drivers/net/can/sja1000/plx_pci.c | 1 -
drivers/net/can/sja1000/sja1000.c | 1 -
drivers/net/can/sja1000/sja1000_isa.c | 1 -
drivers/net/can/sja1000/sja1000_of_platform.c | 1 -
drivers/net/can/sja1000/sja1000_platform.c | 1 -
drivers/net/can/ti_hecc.c | 1 -
include/linux/can/dev.h | 1 +
14 files changed, 1 insertion(+), 13 deletions(-)
Index: linux-2.6.34-rc/include/linux/can/dev.h
===================================================================
--- linux-2.6.34-rc.orig/include/linux/can/dev.h 2010-04-08 19:37:34.000000000 +0200
+++ linux-2.6.34-rc/include/linux/can/dev.h 2010-04-08 19:37:50.000000000 +0200
@@ -14,6 +14,7 @@
#ifndef CAN_DEV_H
#define CAN_DEV_H
+#include <linux/can.h>
#include <linux/can/netlink.h>
#include <linux/can/error.h>
Index: linux-2.6.34-rc/drivers/net/can/at91_can.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/at91_can.c 2010-04-08 20:52:22.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/at91_can.c 2010-04-08 20:52:47.000000000 +0200
@@ -35,7 +35,6 @@
#include <linux/string.h>
#include <linux/types.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/error.h>
Index: linux-2.6.34-rc/drivers/net/can/bfin_can.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/bfin_can.c 2010-04-08 20:53:15.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/bfin_can.c 2010-04-08 20:53:25.000000000 +0200
@@ -18,7 +18,6 @@
#include <linux/skbuff.h>
#include <linux/platform_device.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/error.h>
Index: linux-2.6.34-rc/drivers/net/can/mcp251x.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/mcp251x.c 2010-04-08 20:53:47.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/mcp251x.c 2010-04-08 20:54:04.000000000 +0200
@@ -58,7 +58,6 @@
*
*/
-#include <linux/can.h>
#include <linux/can/core.h>
#include <linux/can/dev.h>
#include <linux/can/platform/mcp251x.h>
Index: linux-2.6.34-rc/drivers/net/can/ti_hecc.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/ti_hecc.c 2010-04-08 20:54:35.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/ti_hecc.c 2010-04-08 20:54:45.000000000 +0200
@@ -47,7 +47,6 @@
#include <linux/platform_device.h>
#include <linux/clk.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/error.h>
#include <linux/can/platform/ti_hecc.h>
Index: linux-2.6.34-rc/drivers/net/can/mscan/mpc5xxx_can.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/mscan/mpc5xxx_can.c 2010-04-08 20:55:16.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/mscan/mpc5xxx_can.c 2010-04-08 20:55:26.000000000 +0200
@@ -25,7 +25,6 @@
#include <linux/interrupt.h>
#include <linux/platform_device.h>
#include <linux/netdevice.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/of_platform.h>
#include <sysdev/fsl_soc.h>
Index: linux-2.6.34-rc/drivers/net/can/mscan/mscan.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/mscan/mscan.c 2010-04-08 20:55:55.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/mscan/mscan.c 2010-04-08 20:56:08.000000000 +0200
@@ -28,7 +28,6 @@
#include <linux/if_arp.h>
#include <linux/if_ether.h>
#include <linux/list.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/error.h>
#include <linux/io.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/ems_pci.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/ems_pci.c 2010-04-08 20:56:48.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/ems_pci.c 2010-04-08 20:57:17.000000000 +0200
@@ -23,7 +23,6 @@
#include <linux/netdevice.h>
#include <linux/delay.h>
#include <linux/pci.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/io.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/kvaser_pci.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/kvaser_pci.c 2010-04-08 20:57:39.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/kvaser_pci.c 2010-04-08 20:57:49.000000000 +0200
@@ -36,7 +36,6 @@
#include <linux/netdevice.h>
#include <linux/delay.h>
#include <linux/pci.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/io.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/plx_pci.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/plx_pci.c 2010-04-08 20:58:00.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/plx_pci.c 2010-04-08 20:58:09.000000000 +0200
@@ -26,7 +26,6 @@
#include <linux/netdevice.h>
#include <linux/delay.h>
#include <linux/pci.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/io.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/sja1000.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/sja1000.c 2010-04-08 20:59:31.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/sja1000.c 2010-04-08 20:59:50.000000000 +0200
@@ -60,7 +60,6 @@
#include <linux/skbuff.h>
#include <linux/delay.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/error.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/sja1000_isa.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/sja1000_isa.c 2010-04-08 20:59:55.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/sja1000_isa.c 2010-04-08 21:00:06.000000000 +0200
@@ -23,7 +23,6 @@
#include <linux/delay.h>
#include <linux/irq.h>
#include <linux/io.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/platform/sja1000.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/sja1000_of_platform.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/sja1000_of_platform.c 2010-04-08 20:58:44.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/sja1000_of_platform.c 2010-04-08 20:58:52.000000000 +0200
@@ -38,7 +38,6 @@
#include <linux/interrupt.h>
#include <linux/netdevice.h>
#include <linux/delay.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/of_platform.h>
Index: linux-2.6.34-rc/drivers/net/can/sja1000/sja1000_platform.c
===================================================================
--- linux-2.6.34-rc.orig/drivers/net/can/sja1000/sja1000_platform.c 2010-04-08 20:59:04.000000000 +0200
+++ linux-2.6.34-rc/drivers/net/can/sja1000/sja1000_platform.c 2010-04-08 20:59:11.000000000 +0200
@@ -24,7 +24,6 @@
#include <linux/pci.h>
#include <linux/platform_device.h>
#include <linux/irq.h>
-#include <linux/can.h>
#include <linux/can/dev.h>
#include <linux/can/platform/sja1000.h>
#include <linux/io.h>
^ permalink raw reply
* Re: [PATCH 1/1] add ethtool loopback support
From: Laurent Chavey @ 2010-04-08 19:17 UTC (permalink / raw)
To: Ben Hutchings; +Cc: davem, netdev, therbert
In-Reply-To: <1270751373.5055.22.camel@achroite.uk.solarflarecom.com>
On Thu, Apr 8, 2010 at 11:29 AM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> On Thu, 2010-04-08 at 10:35 -0700, chavey@google.com wrote:
>> From: Ranjit Manomohan <ranjitm@google.com>
>> Date: Wed, 7 Apr 2010 15:19:48 -0700
>>
>> Add an ethtool option to use internal loopback mode for testing.
>> This feature is used for component and driver test coverage by putting
>> the device in hardware loopback mode and sending / receiving network
>> traffic from a user application to test the hardware and driver
>> transmit / receive paths.
>>
>> Signed-off-by: laurent chavey <chavey@google.com>
>> ---
>> include/linux/ethtool.h | 16 ++++++++++++++++
>> net/core/ethtool.c | 40 ++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 56 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> index b33f316..df1dcc7 100644
>> --- a/include/linux/ethtool.h
>> +++ b/include/linux/ethtool.h
>> @@ -292,6 +292,18 @@ struct ethtool_stats {
>> __u64 data[0];
>> };
>>
>> +/* for setting the NIC into loopback mode */
>> +struct ethtool_loopback {
>> + u32 cmd; /* ETHTOOL_SLOOPBACK */
>> + u32 type; /* ethtool_loopback_type */
>> +};
>> +
>> +enum ethtool_loopback_type {
>> + ETH_MAC = 0x00000001,
>> + ETH_PHY_INT = 0x00000002,
>> + ETH_PHY_EXT = 0x00000004
>> +};
> [...]
>
> There are many different places you can loop back within a MAC or PHY,
> not to mention bypassing the MAC altogether. See
> drivers/net/sfc/mcdi_pcol.h, starting from the line
> '#define MC_CMD_LOOPBACK_NONE 0'. I believe we implement all of those
> loopback modes on at least one board.
>
> Also are these supposed to be an enumeration or flags? In theory you
those are enums that can be or together.
> could use wire-side and host-side loopback at the same time if they
> don't overlap, but it's probably too much trouble to bother with. Any
> other combination is meaningless.
>
> Ben.
>
> --
> Ben Hutchings, Senior Software Engineer, Solarflare Communications
> Not speaking for my employer; that's the marketing department's job.
> They asked us to note that Solarflare product names are trademarked.
>
>
^ permalink raw reply
* Re: [PATCH 3/3] cxgb4i: iscsi and pdu processing part
From: Mike Christie @ 2010-04-08 19:15 UTC (permalink / raw)
To: open-iscsi-/JYPxA39Uh5TLH3MbocFFw
Cc: Rakesh Ranjan, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, kxie-ut6Up61K2wZBDgjK7y7TUQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk
In-Reply-To: <1270728855-20951-4-git-send-email-rakesh-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
On 04/08/2010 07:14 AM, Rakesh Ranjan wrote:
> From: Rakesh Ranjan<rakesh-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
>
>
> Signed-off-by: Rakesh Ranjan<rakesh-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
> ---
> drivers/scsi/cxgb4i/cxgb4i_iscsi.c | 715 ++++++++++++++++++++++++++++++++++++
> drivers/scsi/cxgb4i/cxgb4i_pdu.c | 475 ++++++++++++++++++++++++
> drivers/scsi/cxgb4i/cxgb4i_pdu.h | 61 +++
> 3 files changed, 1251 insertions(+), 0 deletions(-)
> create mode 100644 drivers/scsi/cxgb4i/cxgb4i_iscsi.c
> create mode 100644 drivers/scsi/cxgb4i/cxgb4i_pdu.c
> create mode 100644 drivers/scsi/cxgb4i/cxgb4i_pdu.h
>
The code in these files looks like the code is the cxgb3i iscsi and pdu
code. Can you just make a common cxgb3i iscsi/pdu layer and add some
callouts?
Something similar to what qla2xxx or lpfc has done to support multiple
cards. In their case they have common fc and driver stuff and then
callouts for hw specifics?
--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
^ permalink raw reply
* Re: [PATCH] net/wireless/libertas: do not call wiphy_unregister() w/o wiphy_register()
From: John W. Linville @ 2010-04-08 19:03 UTC (permalink / raw)
To: Dan Williams
Cc: Holger Schurig, Daniel Mack, libertas-dev, netdev, linux-wireless,
linux-kernel
In-Reply-To: <20100330172008.GD13120@tuxdriver.com>
On Tue, Mar 30, 2010 at 01:20:08PM -0400, John W. Linville wrote:
> On Tue, Mar 30, 2010 at 10:04:33AM -0700, Dan Williams wrote:
> > On Tue, 2010-03-30 at 12:59 +0200, Holger Schurig wrote:
> > > > I don't get your point. The patch I submitted fixes an Ooops in the
> > > > driver, due to wrong handling of an API. What does that have to do with
> > > > principle discussions about the frameworks in use?
> > >
> > > I asked if there is a better method, and you said that you would test a better
> > > solution. That means that someone else should make a better solution.
> > >
> > > I just pointed out that I won't be the one who creates the better solution,
> > > because for fundamental reasons I don't see the libertas+cfg80211 approach
> > > going forward. That issue has nothing to do with you or your patch, so please
> > > don't feel offended or confused.
> >
> > Fine; just rip out the mesh code and do the vanilla cfg80211 conversion
> > for infra & adhoc, and we'll add the mesh code back later. I don't have
> > time to do the cfg80211 bits, neither do the OLPC guys (AFAIK), so lets
> > take advantage of your willingness to do this and just move the driver
> > forward.
>
> Someone post a feature removal patch, please?
Ping?
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* panic in net-next almost immediately on ifup
From: Tantilov, Emil S @ 2010-04-08 18:57 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: David Miller, yoshfuji@linux-ipv6.org
I am seeing the following panic on a fresh net-next pull.
Seems like ipv6/mcast related issue? Panic points to /net/ipv6/mcast.c:1490
[ 49.375726] BUG: unable to handle kernel paging request at fffffffe81bf1048
[ 49.382833] IP: [<ffffffff8143971b>] mld_sendpack+0x2bd/0x2f1
[ 49.388668] PGD 1a0a067 PUD 0
[ 49.391858] Oops: 0000 [#1] SMP
[ 49.395228] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/devnum
[ 49.403251] CPU 2
[ 49.405124] Modules linked in: e1000 [last unloaded: scsi_wait_scan]
[ 49.411883]
[ 49.413416] Pid: 2235, comm: grep Not tainted 2.6.34-rc2-net-next-master #7 X8SIL/X8SIL
[ 49.421442] RIP: 0010:[<ffffffff8143971b>] [<ffffffff8143971b>] mld_sendpack+0x2bd/0x2f1
[ 49.429689] RSP: 0000:ffff880001e83d50 EFLAGS: 00010202
[ 49.435220] RAX: 000060fffde056e8 RBX: ffff8801b605fc00 RCX: ffff8801b605ff00
[ 49.442565] RDX: ffff880001e90880 RSI: ffff880001e83aa0 RDI: ffffffff8139e741
[ 49.449913] RBP: ffff880001e83de0 R08: ffffffff81a63f9c R09: 000000000000004c
[ 49.457258] R10: 000000000947d5de R11: ffff880180000000 R12: ffff8801bce62800
[ 49.464606] R13: fffffffe81bf0ee0 R14: 000000000000004c R15: 000000000000001c
[ 49.471953] FS: 0000000000000000(0000) GS:ffff880001e80000(0000) knlGS:0000000000000000
[ 49.480440] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 49.486403] CR2: fffffffe81bf1048 CR3: 00000001b61d1000 CR4: 00000000000006e0
[ 49.493750] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 49.501097] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 49.508444] Process grep (pid: 2235, threadinfo ffff8801b609e000, task ffff8801bcda6320)
[ 49.516928] Stack:
[ 49.519168] ffff8801b61cd010 0000004000000002 0000000000000003 000002ff00000000
[ 49.526773] <0> 0000000000000000 0000000016000000 0000000000000000 0000000000000000
[ 49.535106] <0> 0000008f0000003a 0000000000000000 ffff880001e83db0 ffff8801b6024500
[ 49.543851] Call Trace:
[ 49.546522] <IRQ>
[ 49.548902] [<ffffffff81439e3f>] mld_ifc_timer_expire+0x236/0x26f
[ 49.555301] [<ffffffff8102ad26>] ? task_tick_fair+0x28/0x108
[ 49.561261] [<ffffffff81439c09>] ? mld_ifc_timer_expire+0x0/0x26f
[ 49.567661] [<ffffffff81042f71>] run_timer_softirq+0x1b3/0x250
[ 49.573805] [<ffffffff810177e4>] ? apic_write+0x11/0x13
[ 49.579335] [<ffffffff8103c87d>] __do_softirq+0xda/0x195
[ 49.584954] [<ffffffff8105b3b9>] ? tick_program_event+0x25/0x27
[ 49.591183] [<ffffffff8100384c>] call_softirq+0x1c/0x28
[ 49.596714] [<ffffffff81004e47>] do_softirq+0x33/0x68
[ 49.602074] [<ffffffff8103c6fd>] irq_exit+0x36/0x78
[ 49.607261] [<ffffffff81018028>] smp_apic_timer_interrupt+0x80/0x8e
[ 49.613830] [<ffffffff81003313>] apic_timer_interrupt+0x13/0x20
[ 49.620049] <EOI>
[ 49.622011] Code: 25 80 d1 00 00 48 8d 04 02 48 ff 80 b0 00 00 00 4c 01 b0 e0 00 00 00 eb 1e 4d 85 e4 74 0d 49 8b 84 24 68 01 00 00 65 48 ff 40 60 <49> 8b 85 68 01 00 00 65 48 ff 40 60 4d 85 e4 74 14 4c 89 e7 e8
[ 49.645200] RIP [<ffffffff8143971b>] mld_sendpack+0x2bd/0x2f1
[ 49.651310] RSP <ffff880001e83d50>
[ 49.655018] CR2: fffffffe81bf1048
[ 49.658556] ---[ end trace be71aeb787ca2f3b ]---
[ 49.663395] Kernel panic - not syncing: Fatal exception in interrupt
[ 49.669964] Pid: 2235, comm: grep Tainted: G D 2.6.34-rc2-net-next-master #7
[ 49.678104] Call Trace:
[ 49.680775] <IRQ> [<ffffffff814b25f7>] panic+0x73/0xe8
[ 49.686361] [<ffffffff814b5268>] oops_end+0xa9/0xb9
[ 49.691547] [<ffffffff810208e5>] no_context+0x1f7/0x206
[ 49.697077] [<ffffffff81020a6d>] __bad_area_nosemaphore+0x179/0x19c
[ 49.703647] [<ffffffff81020a9e>] bad_area_nosemaphore+0xe/0x10
[ 49.709783] [<ffffffff814b70f1>] do_page_fault+0x135/0x273
[ 49.715574] [<ffffffff814b479f>] page_fault+0x1f/0x30
[ 49.720935] [<ffffffff8139e741>] ? dev_queue_xmit+0x403/0x437
[ 49.726982] [<ffffffff8143971b>] ? mld_sendpack+0x2bd/0x2f1
[ 49.732858] [<ffffffff81439e3f>] mld_ifc_timer_expire+0x236/0x26f
[ 49.739255] [<ffffffff8102ad26>] ? task_tick_fair+0x28/0x108
[ 49.745219] [<ffffffff81439c09>] ? mld_ifc_timer_expire+0x0/0x26f
[ 49.751615] [<ffffffff81042f71>] run_timer_softirq+0x1b3/0x250
[ 49.757752] [<ffffffff810177e4>] ? apic_write+0x11/0x13
[ 49.763281] [<ffffffff8103c87d>] __do_softirq+0xda/0x195
[ 49.768901] [<ffffffff8105b3b9>] ? tick_program_event+0x25/0x27
[ 49.775124] [<ffffffff8100384c>] call_softirq+0x1c/0x28
[ 49.780653] [<ffffffff81004e47>] do_softirq+0x33/0x68
[ 49.786014] [<ffffffff8103c6fd>] irq_exit+0x36/0x78
[ 49.791200] [<ffffffff81018028>] smp_apic_timer_interrupt+0x80/0x8e
[ 49.797767] [<ffffffff81003313>] apic_timer_interrupt+0x13/0x20
[ 49.803987] <EOI>
Emil
^ permalink raw reply
* Re: linux-next: powerpc boot failure
From: Tony Luck @ 2010-04-08 18:55 UTC (permalink / raw)
To: Timo Teräs; +Cc: Stephen Rothwell, David Miller, netdev, linux-next, LKML
In-Reply-To: <4BBD966D.8020404@iki.fi>
I'm seeing an oops in the same routine on ia64 built from next-20100408
My setup is a SLES11 installation. next-20100407 booted with no problems.
I'm also clueless about xfrm_policy.
Here's an abbreviated copy of the first (of several) oops. The code
dereferences a bad pointer:
Unable to handle kernel paging request at virtual address 480cb78f00000024
mount.nfs[7289]: Oops 8821862825984 [1]
Modules linked in: nfs lockd auth_rpcgss sunrpc binfmt_misc loop
dm_mod sr_mod usb_storage sg button container usbhid uhci_hcd ehci_hcd
usbcore fan processor thermal thermal_sys
Pid: 7289, CPU 16, comm: mount.nfs
psr : 0000101008526030 ifs : 8000000000000e22 ip :
[<a000000100888f10>] Not tainted
(2.6.34-rc3-generic-smp-next-20100408)
ip is at __xfrm_lookup+0x650/0x760
Call Trace:
[<a000000100015950>] show_stack+0x50/0xa0
[<a0000001000161c0>] show_regs+0x820/0x860
[<a00000010003ac00>] die+0x1a0/0x300
[<a000000100068b40>] ia64_do_page_fault+0x8c0/0x9e0
[<a00000010000bb00>] ia64_native_leave_kernel+0x0/0x270
[<a000000100888f10>] __xfrm_lookup+0x650/0x760
[<a0000001007ec410>] ip_route_output_flow+0xf0/0x480
[<a000000100846c30>] ip4_datagram_connect+0x330/0x5e0
[<a00000010085f420>] inet_dgram_connect+0x140/0x180
[<a0000001007854f0>] sys_connect+0xf0/0x1a0
[<a00000010000b980>] ia64_ret_from_syscall+0x0/0x20
[<a000000000010720>] __kernel_syscall_via_break+0x0/0x20
I tried the patch you just posted. Compiling with it gave this warning:
net/xfrm/xfrm_policy.c: In function ‘__xfrm_lookup’:
net/xfrm/xfrm_policy.c:1735: warning: ‘num_xfrms’ may be used
uninitialized in this function
but the patched kernel booted ok.
-Tony
^ permalink raw reply
* Re: [PATCH] tcp: Set CHECKSUM_UNNECESSARY in tcp_init_nondata_skb
From: David Miller @ 2010-04-08 18:34 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20100408153906.GA26376@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 8 Apr 2010 23:39:06 +0800
> On Thu, Apr 08, 2010 at 09:57:15PM +0800, Herbert Xu wrote:
>>
>> The problem here is that for non-data packets CHECKSUM_PARTIAL
>> can actually end up being worse if we wind up going out through
>> an interface that doesn't support checksums.
>
> I don't know what I was thinking but the above is totally wrong.
> CHECKSUM_PARTIAL should be just fine on non-checksuming interfaces
> as we'll checksum everything once just as the CHECKSUM_NONE case
> would.
>
> So with that in mind, we don't need my CHECKSUM_UNNECESSARY patch
> at all and your CHECKSUM_PARTIAL path is the right solution after
> all :)
Ok, thanks for doing all of the analysis :)
That still leaves that MC loopback code in ip_dev_loopback_xmit()
which still sets CHECKSUM_UNNECESSARY unconditionally.
Should it do like the loopback driver and just leave the ip_summed
value alone?
^ permalink raw reply
* Re: [PATCH] udp: fix for unicast RX path optimization
From: David Miller @ 2010-04-08 18:30 UTC (permalink / raw)
To: eric.dumazet; +Cc: jorge, netdev
In-Reply-To: <1270739547.2215.61.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 08 Apr 2010 17:12:27 +0200
> Le jeudi 08 avril 2010 à 16:56 +0200, Jorge Boncompte [DTI2] a écrit :
>> Commits 5051ebd275de672b807c28d93002c2fb0514a3c9 and
>> 5051ebd275de672b807c28d93002c2fb0514a3c9 ("ipv[46]: udp: optimize unicast RX
>> path") broke some programs.
>>
>> After upgrading a L2TP server to 2.6.33 it started to fail, tunnels going up an
>> down, after the 10th tunnel came up. My modified rp-l2tp uses a global
>> unconnected socket bound to (INADDR_ANY, 1701) and one connected socket per
>> tunnel after parameter negotiation.
>>
>> After ten sockets were open and due to mixed parameters to
>> udp[46]_lib_lookup2() kernel started to drop packets.
>>
>> Signed-off-by: Jorge Boncompte [DTI2] <jorge@dti2.net>
...
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH 1/1] add ethtool loopback support
From: Ben Hutchings @ 2010-04-08 18:29 UTC (permalink / raw)
To: chavey; +Cc: davem, netdev, therbert
In-Reply-To: <pvmbpdtn8yh.fsf@chavey.mtv.corp.google.com>
On Thu, 2010-04-08 at 10:35 -0700, chavey@google.com wrote:
> From: Ranjit Manomohan <ranjitm@google.com>
> Date: Wed, 7 Apr 2010 15:19:48 -0700
>
> Add an ethtool option to use internal loopback mode for testing.
> This feature is used for component and driver test coverage by putting
> the device in hardware loopback mode and sending / receiving network
> traffic from a user application to test the hardware and driver
> transmit / receive paths.
>
> Signed-off-by: laurent chavey <chavey@google.com>
> ---
> include/linux/ethtool.h | 16 ++++++++++++++++
> net/core/ethtool.c | 40 ++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 56 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index b33f316..df1dcc7 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -292,6 +292,18 @@ struct ethtool_stats {
> __u64 data[0];
> };
>
> +/* for setting the NIC into loopback mode */
> +struct ethtool_loopback {
> + u32 cmd; /* ETHTOOL_SLOOPBACK */
> + u32 type; /* ethtool_loopback_type */
> +};
> +
> +enum ethtool_loopback_type {
> + ETH_MAC = 0x00000001,
> + ETH_PHY_INT = 0x00000002,
> + ETH_PHY_EXT = 0x00000004
> +};
[...]
There are many different places you can loop back within a MAC or PHY,
not to mention bypassing the MAC altogether. See
drivers/net/sfc/mcdi_pcol.h, starting from the line
'#define MC_CMD_LOOPBACK_NONE 0'. I believe we implement all of those
loopback modes on at least one board.
Also are these supposed to be an enumeration or flags? In theory you
could use wire-side and host-side loopback at the same time if they
don't overlap, but it's probably too much trouble to bother with. Any
other combination is meaningless.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Crashes in xfrm_lookup
From: David Miller @ 2010-04-08 18:28 UTC (permalink / raw)
To: timo.teras; +Cc: broonie, netdev
In-Reply-To: <4BBDBCF9.5060906@iki.fi>
From: Timo Teräs <timo.teras@iki.fi>
Date: Thu, 08 Apr 2010 14:24:41 +0300
> Mark Brown wrote:
>> With -next as of today I'm experiencing crashes in the xfrm_lookup
>> code
>> when attempting to boot from an NFS root on a SMDK6410 (an ARM based
>> development board). I'm currently investigating what's gone wrong,
>> but
>> thought it was better to report early in case it's obvious to someone
>> familiar with the code or there's a fix already.
>
> Probably the same as http://marc.info/?t=127071006600005&r=1&w=2
>
> Happens because CONFIG_XFRM_SUB_POLICY is not enabled, and one of
> the helper functions I used did unexpected things in that case.
>
> Try the following:
Since this fix has been confirmed I'm applying it to net-next-2.6,
thanks!
^ permalink raw reply
* Re: [PATCH] udp: fix for unicast RX path optimization
From: David Miller @ 2010-04-08 18:16 UTC (permalink / raw)
To: eric.dumazet; +Cc: jorge, netdev
In-Reply-To: <1270739547.2215.61.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 08 Apr 2010 17:12:27 +0200
> This is a stable candidate. David, can you catch it even if Jorge didnt
> sent you a copy ?
It went to netdev and thus patchwork and I both have it :-)
^ permalink raw reply
* [PATCH 1/1] add ethtool loopback support
From: chavey @ 2010-04-08 17:35 UTC (permalink / raw)
To: davem; +Cc: netdev, therbert
From: Ranjit Manomohan <ranjitm@google.com>
Date: Wed, 7 Apr 2010 15:19:48 -0700
Add an ethtool option to use internal loopback mode for testing.
This feature is used for component and driver test coverage by putting
the device in hardware loopback mode and sending / receiving network
traffic from a user application to test the hardware and driver
transmit / receive paths.
Signed-off-by: laurent chavey <chavey@google.com>
---
include/linux/ethtool.h | 16 ++++++++++++++++
net/core/ethtool.c | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index b33f316..df1dcc7 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -292,6 +292,18 @@ struct ethtool_stats {
__u64 data[0];
};
+/* for setting the NIC into loopback mode */
+struct ethtool_loopback {
+ u32 cmd; /* ETHTOOL_SLOOPBACK */
+ u32 type; /* ethtool_loopback_type */
+};
+
+enum ethtool_loopback_type {
+ ETH_MAC = 0x00000001,
+ ETH_PHY_INT = 0x00000002,
+ ETH_PHY_EXT = 0x00000004
+};
+
struct ethtool_perm_addr {
__u32 cmd; /* ETHTOOL_GPERMADDR */
__u32 size;
@@ -566,6 +578,8 @@ struct ethtool_ops {
int (*reset)(struct net_device *, u32 *);
int (*set_rx_ntuple)(struct net_device *, struct ethtool_rx_ntuple *);
int (*get_rx_ntuple)(struct net_device *, u32 stringset, void *);
+ int (*set_loopback)(struct net_device *, struct ethtool_loopback *);
+ int (*get_loopback)(struct net_device *, struct ethtool_loopback *);
};
#endif /* __KERNEL__ */
@@ -627,6 +641,8 @@ struct ethtool_ops {
#define ETHTOOL_SRXNTUPLE 0x00000035 /* Add an n-tuple filter to device */
#define ETHTOOL_GRXNTUPLE 0x00000036 /* Get n-tuple filters from device */
#define ETHTOOL_GSSET_INFO 0x00000037 /* Get string set info */
+#define ETHTOOL_SLOOPBACK 0x00000038 /* Set loopback mode on/off */
+#define ETHTOOL_GLOOPBACK 0x00000039 /* Get loopback mode setting */
/* compatibility with older code */
#define SPARC_ETH_GSET ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index f4cb6b6..89b4ecb 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1289,6 +1289,40 @@ static noinline_for_stack int ethtool_flash_device(struct net_device *dev, char
return dev->ethtool_ops->flash_device(dev, &efl);
}
+static int ethtool_set_loopback(struct net_device *dev, void __user *useraddr)
+{
+ struct ethtool_loopback lpbk;
+ const struct ethtool_ops *ops = dev->ethtool_ops;
+
+ if (!ops->set_loopback)
+ return -EOPNOTSUPP;
+
+ if (copy_from_user(&lpbk, useraddr, sizeof(lpbk)))
+ return -EFAULT;
+
+ return ops->set_loopback(dev, &lpbk);
+}
+
+static int ethtool_get_loopback(struct net_device *dev, void __user *useraddr)
+{
+ struct ethtool_loopback lpbk;
+ const struct ethtool_ops *ops = dev->ethtool_ops;
+ int err;
+
+ if (!ops->get_loopback)
+ return -EOPNOTSUPP;
+
+ err = ops->get_loopback(dev, &lpbk);
+
+ if (err)
+ return err;
+
+ if (copy_to_user(useraddr, &lpbk, sizeof(lpbk)))
+ return -EFAULT;
+
+ return 0;
+}
+
/* The main entry point in this file. Called from net/core/dev.c */
int dev_ethtool(struct net *net, struct ifreq *ifr)
@@ -1518,6 +1552,12 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
case ETHTOOL_GSSET_INFO:
rc = ethtool_get_sset_info(dev, useraddr);
break;
+ case ETHTOOL_SLOOPBACK:
+ rc = ethtool_set_loopback(dev, useraddr);
+ break;
+ case ETHTOOL_GLOOPBACK:
+ rc = ethtool_get_loopback(dev, useraddr);
+ break;
default:
rc = -EOPNOTSUPP;
}
--
1.7.0.1
^ permalink raw reply related
* [PATCH 2/2] [V5] Add non-Virtex5 support for LL TEMAC driver
From: John Linn @ 2010-04-08 17:08 UTC (permalink / raw)
To: netdev, linuxppc-dev, grant.likely, jwboyer, eric.dumazet
Cc: john.williams, michal.simek, John Linn, John Tyner
In-Reply-To: <1270746482-29914-1-git-send-email-john.linn@xilinx.com>
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft DMA
registers as if they were memory mapped instead of solely through the
DCR's (available on the Virtex 5).
The patch also updates the driver so that it runs on the MicroBlaze.
The changes were tested on the PowerPC 440, PowerPC 405, and the
MicroBlaze platforms.
Signed-off-by: John Tyner <jtyner@cs.ucr.edu>
Signed-off-by: John Linn <john.linn@xilinx.com>
---
V2 - Incorporated comments from Grant and added more logic to allow the driver
to work on MicroBlaze.
V3 - Only updated it to apply to head, minor change to include slab.h. Also
verified that it now builds for MicroBlaze. Retested on PowerPC and MicroBlaze.
V4 - Removed buffer alignment for skb and called the network functions that
already do the alignment for cache line and word alignment. Added constants
to MicroBlaze system to make sure network alignment is maintained. Also updated
the Kconfig so it depends on Microblaze or PPC based on Grant's comment.
V5 - Respun the patch on top of a new patch to the driver which removed the
call to virt_to_bus as it's now illegal and caused a failure when building
the driver in linux-next. Retested with 440, 405 and Microblaze.
Grant, can you do a build test to verify no build issues?
---
arch/microblaze/include/asm/system.h | 11 +++
drivers/net/Kconfig | 2 +-
drivers/net/ll_temac.h | 14 +++-
drivers/net/ll_temac_main.c | 137 +++++++++++++++++++++++++--------
4 files changed, 126 insertions(+), 38 deletions(-)
diff --git a/arch/microblaze/include/asm/system.h b/arch/microblaze/include/asm/system.h
index 59efb3f..48c4f03 100644
--- a/arch/microblaze/include/asm/system.h
+++ b/arch/microblaze/include/asm/system.h
@@ -12,6 +12,7 @@
#include <asm/registers.h>
#include <asm/setup.h>
#include <asm/irqflags.h>
+#include <asm/cache.h>
#include <asm-generic/cmpxchg.h>
#include <asm-generic/cmpxchg-local.h>
@@ -96,4 +97,14 @@ extern struct dentry *of_debugfs_root;
#define arch_align_stack(x) (x)
+/*
+ * MicroBlaze doesn't handle unaligned accesses in hardware.
+ *
+ * Based on this we force the IP header alignment in network drivers.
+ * We also modify NET_SKB_PAD to be a cacheline in size, thus maintaining
+ * cacheline alignment of buffers.
+ */
+#define NET_IP_ALIGN 2
+#define NET_SKB_PAD L1_CACHE_BYTES
+
#endif /* _ASM_MICROBLAZE_SYSTEM_H */
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 7b832c7..9073741 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2434,8 +2434,8 @@ config MV643XX_ETH
config XILINX_LL_TEMAC
tristate "Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver"
+ depends on PPC || MICROBLAZE
select PHYLIB
- depends on PPC_DCR_NATIVE
help
This driver supports the Xilinx 10/100/1000 LocalLink TEMAC
core used in Xilinx Spartan and Virtex FPGAs
diff --git a/drivers/net/ll_temac.h b/drivers/net/ll_temac.h
index 1af66a1..c033584 100644
--- a/drivers/net/ll_temac.h
+++ b/drivers/net/ll_temac.h
@@ -5,8 +5,11 @@
#include <linux/netdevice.h>
#include <linux/of.h>
#include <linux/spinlock.h>
+
+#ifdef CONFIG_PPC_DCR
#include <asm/dcr.h>
#include <asm/dcr-regs.h>
+#endif
/* packet size info */
#define XTE_HDR_SIZE 14 /* size of Ethernet header */
@@ -290,9 +293,6 @@ This option defaults to enabled (set) */
#define TX_CONTROL_CALC_CSUM_MASK 1
-#define XTE_ALIGN 32
-#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN)
-
#define MULTICAST_CAM_TABLE_NUM 4
/* TX/RX CURDESC_PTR points to first descriptor */
@@ -335,9 +335,15 @@ struct temac_local {
struct mii_bus *mii_bus; /* MII bus reference */
int mdio_irqs[PHY_MAX_ADDR]; /* IRQs table for MDIO bus */
- /* IO registers and IRQs */
+ /* IO registers, dma functions and IRQs */
void __iomem *regs;
+ void __iomem *sdma_regs;
+#ifdef CONFIG_PPC_DCR
dcr_host_t sdma_dcrs;
+#endif
+ u32 (*dma_in)(struct temac_local *, int);
+ void (*dma_out)(struct temac_local *, int, u32);
+
int tx_irq;
int rx_irq;
int emac_num;
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index ce9aa78..2b69d6c 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -20,9 +20,6 @@
* or rx, so this should be okay.
*
* TODO:
- * - Fix driver to work on more than just Virtex5. Right now the driver
- * assumes that the locallink DMA registers are accessed via DCR
- * instructions.
* - Factor out locallink DMA code into separate driver
* - Fix multicast assignment.
* - Fix support for hardware checksumming.
@@ -116,17 +113,86 @@ void temac_indirect_out32(struct temac_local *lp, int reg, u32 value)
temac_iow(lp, XTE_CTL0_OFFSET, CNTLREG_WRITE_ENABLE_MASK | reg);
}
+/**
+ * temac_dma_in32 - Memory mapped DMA read, this function expects a
+ * register input that is based on DCR word addresses which
+ * are then converted to memory mapped byte addresses
+ */
static u32 temac_dma_in32(struct temac_local *lp, int reg)
{
- return dcr_read(lp->sdma_dcrs, reg);
+ return in_be32((u32 *)(lp->sdma_regs + (reg << 2)));
}
+/**
+ * temac_dma_out32 - Memory mapped DMA read, this function expects a
+ * register input that is based on DCR word addresses which
+ * are then converted to memory mapped byte addresses
+ */
static void temac_dma_out32(struct temac_local *lp, int reg, u32 value)
{
+ out_be32((u32 *)(lp->sdma_regs + (reg << 2)), value);
+}
+
+/* DMA register access functions can be DCR based or memory mapped.
+ * The PowerPC 440 is DCR based, the PowerPC 405 and MicroBlaze are both
+ * memory mapped.
+ */
+#ifdef CONFIG_PPC_DCR
+
+/**
+ * temac_dma_dcr_in32 - DCR based DMA read
+ */
+static u32 temac_dma_dcr_in(struct temac_local *lp, int reg)
+{
+ return dcr_read(lp->sdma_dcrs, reg);
+}
+
+/**
+ * temac_dma_dcr_out32 - DCR based DMA write
+ */
+static void temac_dma_dcr_out(struct temac_local *lp, int reg, u32 value)
+{
dcr_write(lp->sdma_dcrs, reg, value);
}
/**
+ * temac_dcr_setup - If the DMA is DCR based, then setup the address and
+ * I/O functions
+ */
+static int temac_dcr_setup(struct temac_local *lp, struct of_device *op,
+ struct device_node *np)
+{
+ unsigned int dcrs;
+
+ /* setup the dcr address mapping if it's in the device tree */
+
+ dcrs = dcr_resource_start(np, 0);
+ if (dcrs != 0) {
+ lp->sdma_dcrs = dcr_map(np, dcrs, dcr_resource_len(np, 0));
+ lp->dma_in = temac_dma_dcr_in;
+ lp->dma_out = temac_dma_dcr_out;
+ dev_dbg(&op->dev, "DCR base: %x\n", dcrs);
+ return 0;
+ }
+ /* no DCR in the device tree, indicate a failure */
+ return -1;
+}
+
+#else
+
+/*
+ * temac_dcr_setup - This is a stub for when DCR is not supported,
+ * such as with MicroBlaze
+ */
+static int temac_dcr_setup(struct temac_local *lp, struct of_device *op,
+ struct device_node *np)
+{
+ return -1;
+}
+
+#endif
+
+/**
* temac_dma_bd_init - Setup buffer descriptor rings
*/
static int temac_dma_bd_init(struct net_device *ndev)
@@ -156,14 +222,14 @@ static int temac_dma_bd_init(struct net_device *ndev)
lp->rx_bd_v[i].next = lp->rx_bd_p +
sizeof(*lp->rx_bd_v) * ((i + 1) % RX_BD_NUM);
- skb = alloc_skb(XTE_MAX_JUMBO_FRAME_SIZE
- + XTE_ALIGN, GFP_ATOMIC);
+ skb = netdev_alloc_skb_ip_align(ndev,
+ XTE_MAX_JUMBO_FRAME_SIZE);
+
if (skb == 0) {
dev_err(&ndev->dev, "alloc_skb error %d\n", i);
return -1;
}
lp->rx_skb[i] = skb;
- skb_reserve(skb, BUFFER_ALIGN(skb->data));
/* returns physical address of skb->data */
lp->rx_bd_v[i].phys = dma_map_single(ndev->dev.parent,
skb->data,
@@ -173,23 +239,23 @@ static int temac_dma_bd_init(struct net_device *ndev)
lp->rx_bd_v[i].app0 = STS_CTRL_APP0_IRQONEND;
}
- temac_dma_out32(lp, TX_CHNL_CTRL, 0x10220400 |
+ lp->dma_out(lp, TX_CHNL_CTRL, 0x10220400 |
CHNL_CTRL_IRQ_EN |
CHNL_CTRL_IRQ_DLY_EN |
CHNL_CTRL_IRQ_COAL_EN);
/* 0x10220483 */
/* 0x00100483 */
- temac_dma_out32(lp, RX_CHNL_CTRL, 0xff010000 |
+ lp->dma_out(lp, RX_CHNL_CTRL, 0xff010000 |
CHNL_CTRL_IRQ_EN |
CHNL_CTRL_IRQ_DLY_EN |
CHNL_CTRL_IRQ_COAL_EN |
CHNL_CTRL_IRQ_IOE);
/* 0xff010283 */
- temac_dma_out32(lp, RX_CURDESC_PTR, lp->rx_bd_p);
- temac_dma_out32(lp, RX_TAILDESC_PTR,
+ lp->dma_out(lp, RX_CURDESC_PTR, lp->rx_bd_p);
+ lp->dma_out(lp, RX_TAILDESC_PTR,
lp->rx_bd_p + (sizeof(*lp->rx_bd_v) * (RX_BD_NUM - 1)));
- temac_dma_out32(lp, TX_CURDESC_PTR, lp->tx_bd_p);
+ lp->dma_out(lp, TX_CURDESC_PTR, lp->tx_bd_p);
return 0;
}
@@ -427,9 +493,9 @@ static void temac_device_reset(struct net_device *ndev)
temac_indirect_out32(lp, XTE_RXC1_OFFSET, val & ~XTE_RXC1_RXEN_MASK);
/* Reset Local Link (DMA) */
- temac_dma_out32(lp, DMA_CONTROL_REG, DMA_CONTROL_RST);
+ lp->dma_out(lp, DMA_CONTROL_REG, DMA_CONTROL_RST);
timeout = 1000;
- while (temac_dma_in32(lp, DMA_CONTROL_REG) & DMA_CONTROL_RST) {
+ while (lp->dma_in(lp, DMA_CONTROL_REG) & DMA_CONTROL_RST) {
udelay(1);
if (--timeout == 0) {
dev_err(&ndev->dev,
@@ -437,7 +503,7 @@ static void temac_device_reset(struct net_device *ndev)
break;
}
}
- temac_dma_out32(lp, DMA_CONTROL_REG, DMA_TAIL_ENABLE);
+ lp->dma_out(lp, DMA_CONTROL_REG, DMA_TAIL_ENABLE);
temac_dma_bd_init(ndev);
@@ -598,7 +664,7 @@ static int temac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
lp->tx_bd_tail = 0;
/* Kick off the transfer */
- temac_dma_out32(lp, TX_TAILDESC_PTR, tail_p); /* DMA start */
+ lp->dma_out(lp, TX_TAILDESC_PTR, tail_p); /* DMA start */
return NETDEV_TX_OK;
}
@@ -638,16 +704,15 @@ static void ll_temac_recv(struct net_device *ndev)
ndev->stats.rx_packets++;
ndev->stats.rx_bytes += length;
- new_skb = alloc_skb(XTE_MAX_JUMBO_FRAME_SIZE + XTE_ALIGN,
- GFP_ATOMIC);
+ new_skb = netdev_alloc_skb_ip_align(ndev,
+ XTE_MAX_JUMBO_FRAME_SIZE);
+
if (new_skb == 0) {
dev_err(&ndev->dev, "no memory for new sk_buff\n");
spin_unlock_irqrestore(&lp->rx_lock, flags);
return;
}
- skb_reserve(new_skb, BUFFER_ALIGN(new_skb->data));
-
cur_p->app0 = STS_CTRL_APP0_IRQONEND;
cur_p->phys = dma_map_single(ndev->dev.parent, new_skb->data,
XTE_MAX_JUMBO_FRAME_SIZE,
@@ -662,7 +727,7 @@ static void ll_temac_recv(struct net_device *ndev)
cur_p = &lp->rx_bd_v[lp->rx_bd_ci];
bdstat = cur_p->app0;
}
- temac_dma_out32(lp, RX_TAILDESC_PTR, tail_p);
+ lp->dma_out(lp, RX_TAILDESC_PTR, tail_p);
spin_unlock_irqrestore(&lp->rx_lock, flags);
}
@@ -673,8 +738,8 @@ static irqreturn_t ll_temac_tx_irq(int irq, void *_ndev)
struct temac_local *lp = netdev_priv(ndev);
unsigned int status;
- status = temac_dma_in32(lp, TX_IRQ_REG);
- temac_dma_out32(lp, TX_IRQ_REG, status);
+ status = lp->dma_in(lp, TX_IRQ_REG);
+ lp->dma_out(lp, TX_IRQ_REG, status);
if (status & (IRQ_COAL | IRQ_DLY))
temac_start_xmit_done(lp->ndev);
@@ -691,8 +756,8 @@ static irqreturn_t ll_temac_rx_irq(int irq, void *_ndev)
unsigned int status;
/* Read and clear the status registers */
- status = temac_dma_in32(lp, RX_IRQ_REG);
- temac_dma_out32(lp, RX_IRQ_REG, status);
+ status = lp->dma_in(lp, RX_IRQ_REG);
+ lp->dma_out(lp, RX_IRQ_REG, status);
if (status & (IRQ_COAL | IRQ_DLY))
ll_temac_recv(lp->ndev);
@@ -793,7 +858,7 @@ static ssize_t temac_show_llink_regs(struct device *dev,
int i, len = 0;
for (i = 0; i < 0x11; i++)
- len += sprintf(buf + len, "%.8x%s", temac_dma_in32(lp, i),
+ len += sprintf(buf + len, "%.8x%s", lp->dma_in(lp, i),
(i % 8) == 7 ? "\n" : " ");
len += sprintf(buf + len, "\n");
@@ -819,7 +884,6 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
struct net_device *ndev;
const void *addr;
int size, rc = 0;
- unsigned int dcrs;
/* Init network device structure */
ndev = alloc_etherdev(sizeof(*lp));
@@ -869,13 +933,20 @@ temac_of_probe(struct of_device *op, const struct of_device_id *match)
goto nodev;
}
- dcrs = dcr_resource_start(np, 0);
- if (dcrs == 0) {
- dev_err(&op->dev, "could not get DMA register address\n");
- goto nodev;
+ /* Setup the DMA register accesses, could be DCR or memory mapped */
+ if (temac_dcr_setup(lp, op, np)) {
+
+ /* no DCR in the device tree, try non-DCR */
+ lp->sdma_regs = of_iomap(np, 0);
+ if (lp->sdma_regs) {
+ lp->dma_in = temac_dma_in32;
+ lp->dma_out = temac_dma_out32;
+ dev_dbg(&op->dev, "MEM base: %p\n", lp->sdma_regs);
+ } else {
+ dev_err(&op->dev, "unable to map DMA registers\n");
+ goto nodev;
+ }
}
- lp->sdma_dcrs = dcr_map(np, dcrs, dcr_resource_len(np, 0));
- dev_dbg(&op->dev, "DCR base: %x\n", dcrs);
lp->rx_irq = irq_of_parse_and_map(np, 0);
lp->tx_irq = irq_of_parse_and_map(np, 1);
--
1.6.2.1
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* [PATCH 1/2] net: ll_temac: remove virt_to_bus call
From: John Linn @ 2010-04-08 17:08 UTC (permalink / raw)
To: netdev, linuxppc-dev, grant.likely, jwboyer, eric.dumazet
Cc: john.williams, michal.simek, John Linn
The virt_to_bus call should not be used any longer as it's
considered illegal. The driver has the physical address of
the buffer in the descriptor such that it's not necessary
anyway.
Signed-off-by: John Linn <john.linn@xilinx.com>
---
drivers/net/ll_temac_main.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ll_temac_main.c b/drivers/net/ll_temac_main.c
index ba617e3..ce9aa78 100644
--- a/drivers/net/ll_temac_main.c
+++ b/drivers/net/ll_temac_main.c
@@ -612,7 +612,6 @@ static void ll_temac_recv(struct net_device *ndev)
struct cdmac_bd *cur_p;
dma_addr_t tail_p;
int length;
- unsigned long skb_vaddr;
unsigned long flags;
spin_lock_irqsave(&lp->rx_lock, flags);
@@ -626,8 +625,7 @@ static void ll_temac_recv(struct net_device *ndev)
skb = lp->rx_skb[lp->rx_bd_ci];
length = cur_p->app4 & 0x3FFF;
- skb_vaddr = virt_to_bus(skb->data);
- dma_unmap_single(ndev->dev.parent, skb_vaddr, length,
+ dma_unmap_single(ndev->dev.parent, cur_p->phys, length,
DMA_FROM_DEVICE);
skb_put(skb, length);
--
1.6.2.1
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
^ permalink raw reply related
* Re: [PATCH net-next-2.6 1/3 (TAKE 3 RESENT)] ipv6 mcast: Introduce include/net/mld.h for MLD definitions.
From: Stephen Hemminger @ 2010-04-08 16:47 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: davem, netdev
In-Reply-To: <201004080659.o386xIXP019382@94.43.138.210.xn.2iij.net>
Is there a piece missing. I tried this against net-next-2.6
--
CC [M] net/ipv6/mcast.o
net/ipv6/mcast.c: In function ‘igmp6_event_query’:
net/ipv6/mcast.c:1134: error: implicit declaration of function ‘mld_msg’
net/ipv6/mcast.c:1134: warning: assignment makes pointer from integer without a cast
net/ipv6/mcast.c: In function ‘igmp6_event_report’:
net/ipv6/mcast.c:1254: warning: assignment makes pointer from integer without a cast
^ 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