* Re: rcu_sched_state detected stall on CPU 0, 3.0-rc2
From: Ben Hutchings @ 2011-06-13 2:30 UTC (permalink / raw)
To: Andy Isaacson; +Cc: Paul E. McKenney, linux-kernel, netdev, linux-pm
In-Reply-To: <20110612235555.GD11580@hexapodia.org>
On Sun, 2011-06-12 at 16:55 -0700, Andy Isaacson wrote:
> Let's CC netdev and linux-pm since this is obviously a suspend issue,
> and may have something to do with ethtool.
>
> On Sun, Jun 12, 2011 at 04:11:43PM -0700, Andy Isaacson wrote:
> > On Sun, Jun 12, 2011 at 12:58:56PM -0700, Andy Isaacson wrote:
> > > My Thinkpad x201s threw some errors (?) a few minutes after resuming
> > > from suspend-to-ram this morning.
> > >
> > > [56415.672140] INFO: rcu_sched_state detected stall on CPU 0 (t=15000 jiffies)
> > >
> > > Nothing jumps out of the backtraces at me. Full dmesg and config
> > > attached. This was my first StR since upgrading from 2.6.39, let's see
> > > if it fails again when I suspend after sending this email. :)
> >
> > I haven't had a fully successful StR cycle yet (in 5 tries), although I
> > can't pin them all on RCU. On try 2 it hung completely about 10 seconds
> > after I unlocked the screensaver, on try 3 it came back to a black
> > console, and on try 4 it didn't suspend at all (blinking moon LED but
> > battery LED and CPU fan still on).
>
> Of course now that I'm trying to debug, I am seeing many successful
> suspend-resume cycles. I don't see any signs of difference between the
> cases that hung and the cases that are now succeeding.
>
> CCing netdev, because I suspend by running pm-suspend, and in at least
> one failure, an ethtool running under pm-suspend seemed to be the
> problem:
>
> root 11558 pts/8 S+ \_ /bin/sh /usr/lib/pm-utils/sleep.d/00powers
> root 11559 pts/8 S+ \_ /bin/sh /usr/sbin/pm-powersave
> root 11576 pts/8 S+ \_ /bin/sh /usr/lib/pm-utils/power.d/
> root 11577 pts/8 D+ \_ ethtool -s eth0 wol g
[...]
Wake-on-LAN configuration is entirely handled by the relevant driver;
the ethtool core just copies the parameters in and out. It looks like
there is some sort of deadlock or missing unlock in the driver. So my
question would be which driver is running eth0?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
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: rcu_sched_state detected stall on CPU 0, 3.0-rc2
From: Andy Isaacson @ 2011-06-12 23:55 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: linux-kernel, netdev, linux-pm
In-Reply-To: <20110612231143.GC11580@hexapodia.org>
[-- Attachment #1: Type: text/plain, Size: 2414 bytes --]
Let's CC netdev and linux-pm since this is obviously a suspend issue,
and may have something to do with ethtool.
On Sun, Jun 12, 2011 at 04:11:43PM -0700, Andy Isaacson wrote:
> On Sun, Jun 12, 2011 at 12:58:56PM -0700, Andy Isaacson wrote:
> > My Thinkpad x201s threw some errors (?) a few minutes after resuming
> > from suspend-to-ram this morning.
> >
> > [56415.672140] INFO: rcu_sched_state detected stall on CPU 0 (t=15000 jiffies)
> >
> > Nothing jumps out of the backtraces at me. Full dmesg and config
> > attached. This was my first StR since upgrading from 2.6.39, let's see
> > if it fails again when I suspend after sending this email. :)
>
> I haven't had a fully successful StR cycle yet (in 5 tries), although I
> can't pin them all on RCU. On try 2 it hung completely about 10 seconds
> after I unlocked the screensaver, on try 3 it came back to a black
> console, and on try 4 it didn't suspend at all (blinking moon LED but
> battery LED and CPU fan still on).
Of course now that I'm trying to debug, I am seeing many successful
suspend-resume cycles. I don't see any signs of difference between the
cases that hung and the cases that are now succeeding.
CCing netdev, because I suspend by running pm-suspend, and in at least
one failure, an ethtool running under pm-suspend seemed to be the
problem:
root 11558 pts/8 S+ \_ /bin/sh /usr/lib/pm-utils/sleep.d/00powers
root 11559 pts/8 S+ \_ /bin/sh /usr/sbin/pm-powersave
root 11576 pts/8 S+ \_ /bin/sh /usr/lib/pm-utils/power.d/
root 11577 pts/8 D+ \_ ethtool -s eth0 wol g
many processes were stuck in D:
USER PID VSZ RSS STAT START COMMAND
root 11493 0 0 D 16:11 \_ [kworker/u:15]
nobody 1707 21472 992 D 14:31 dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listen-address 192.168.122.1 --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases --dhcp-lease-max=253 --dhcp-no-override
adi 11606 41004 2424 D+ 16:13 | \_ ssh hex
root 11577 4092 324 D+ 16:11 | \_ ethtool -s eth0 wol g
root 11595 22108 892 D+ 16:12 | \_ sudo cat /proc/11577/stack
root 11604 22108 900 D+ 16:13 | \_ sudo cat /proc/11577/stack
==> /proc/11577/wchan <==
synchronize_sched
-andy
[-- Attachment #2: trace.gz --]
[-- Type: application/octet-stream, Size: 27327 bytes --]
[-- Attachment #3: config-trim.gz --]
[-- Type: application/octet-stream, Size: 8350 bytes --]
^ permalink raw reply
* Re: 3c503: fix broken IRQ autoprobing
From: Ben Hutchings @ 2011-06-12 21:45 UTC (permalink / raw)
To: Ondrej Zary; +Cc: netdev, Kernel development list
In-Reply-To: <201106122140.51776.linux@rainbow-software.org>
[-- Attachment #1: Type: text/plain, Size: 669 bytes --]
On Sun, 2011-06-12 at 21:40 +0200, Ondrej Zary wrote:
> Fix broken IRQ autoprobing in 3c503 driver:
> - improper IRQ freeing (does not free IRQs causes WARN)
> - missing break when an working IRQ is found
>
> The driver works with this patch.
I made a previous attempt to fix autoprobing (commit
b0cf4dfb7cd21556efd9a6a67edcba0840b4d98d), but didn't have any hardware
to test on. In the process I introduced these new bugs. Sorry about
that.
> Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
[...]
Reviewed-by: Ben Hutchings <ben@decadent.org.uk>
Ben.
--
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* 3.0-rc2: Reported regressions 2.6.38 -> 2.6.39
From: Rafael J. Wysocki @ 2011-06-12 21:06 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, DRI, Florian Mickler, Andrew Morton,
Kernel Testers List, Linus Torvalds, Linux PM List,
Maciej Rutecki
This message contains a list of some post-2.6.38 regressions introduced before
2.6.39, 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.38 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
----------------------------------------
2011-06-12 81 21 18
2011-05-15 50 12 11
2011-04-30 38 17 16
2011-04-17 17 11 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=37132
Subject : Random crashes on resume from hibernate on ASUS F6A
Submitter : Dmitry Nezhevenko <dion@inhex.net>
Date : 2011-06-10 11:00 (3 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36962
Subject : [Regression 2.6.39][nouveau][bisected?] leaving fullscreen XV "crashes" with KDE desktop effects enabled
Submitter : Jan Seiffert <kaffeemonster@googlemail.com>
Date : 2011-05-25 2:32 (19 days old)
Message-ID : <BANLkTimd6nvXTbn2hM+cKDNKFpxzsQLHog@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=130629073407685&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36952
Subject : [2.6.39] CIFS write failures where 2.6.38 works
Submitter : Helge Hafting <helge.hafting@hist.no>
Date : 2011-06-01 10:11 (12 days old)
Message-ID : <4DE6103E.6010100@hist.no>
References : http://marc.info/?l=linux-kernel&m=130692387613423&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36712
Subject : 2.6.39 - crash when plugging in a usb memory stick
Submitter : Chris Clayton <chris2553@googlemail.com>
Date : 2011-05-27 8:09 (17 days old)
Message-ID : <201105270909.00183.chris2553@googlemail.com>
References : http://marc.info/?l=linux-kernel&m=130648376531197&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36702
Subject : 2.6.39 kernel panic w/screenshots & kernel cfg link provided
Submitter : Justin Piszcz <jpiszcz@lucidpixels.com>
Date : 2011-05-28 12:01 (16 days old)
Message-ID : <alpine.DEB.2.02.1105280755050.4345@p34.internal.lan>
References : http://marc.info/?l=linux-kernel&m=130658411008127&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36392
Subject : 2.6.39, 3.0-rc2 Intel DRI Regression: Black Screen after trying to play video
Submitter : Dennis Jansen <dennis.jansen@web.de>
Date : 2011-06-01 04:41 (12 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36332
Subject : Intel gpu turns external monitor off when X starts
Submitter : rocko <rockorequin@hotmail.com>
Date : 2011-05-31 02:53 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36182
Subject : Erroneous package power limit notification since kernel 2.6.39
Submitter : Olaf Freyer <aaron667@gmx.net>
Date : 2011-05-22 13:01 (22 days old)
Message-ID : <4DD9092A.4080507@gmx.net>
References : http://marc.info/?l=linux-kernel&m=130606930631131&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36092
Subject : Filesystem lockup on USB HDD plug-in
Submitter : Arno Wagner <arno@wagner.name>
Date : 2011-05-28 12:34 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36012
Subject : Kernel oops in __pskb_pull_tail
Submitter : Steinar H. Gunderson <sgunderson@bigfoot.com>
Date : 2011-05-27 18:21 (17 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=35922
Subject : SND_USB_AUDIO recording device not initializing correctly
Submitter : <bjoern.online@gmail.com>
Date : 2011-05-26 10:30 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=35662
Subject : softlockup with kernel 2.6.39
Submitter : Hussam Al-Tayeb <hussam@visp.net.lb>
Date : 2011-05-23 08:13 (21 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=35642
Subject : On resume, I sometimes get a kernel oops with led_trigger_unregister_simple
Submitter : Sven-Hendrik Haase <sh@lutzhaase.com>
Date : 2011-05-23 00:15 (21 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=35242
Subject : NULL pointer dereference in intel_sdvo_write_cmd (was Black screen after boot)
Submitter : Ko Mi <chaostya.test@hotmail.com>
Date : 2011-05-17 10:27 (27 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=35142
Subject : 2.6.39-rc7-git1 boot error message (no crash)
Submitter : werner <w.landgraf@ru.ru>
Date : 2011-05-11 4:58 (33 days old)
Message-ID : <web-520830057@zbackend1.aha.ru>
References : http://marc.info/?l=linux-kernel&m=130512952706444&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=34942
Subject : [Bug] Kdump does not work when panic triggered due to MCE
Submitter : K.Prasad <prasad@linux.vnet.ibm.com>
Date : 2011-05-06 16:54 (38 days old)
Message-ID : <20110506165412.GB2719@in.ibm.com>
References : http://marc.info/?l=linux-kernel&m=130470087226270&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=34002
Subject : [REGRESSION] [2.6.39-rc3] Wrong resolution in framebuffer and X Window
Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
Date : 2011-04-17 16:04 (57 days old)
Message-ID : <201104171804.04664.maciej.rutecki@gmail.com>
References : http://marc.info/?l=linux-fbdev&m=130305625114863&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33842
Subject : NULL pointer dereference in ip_fragment
Submitter : Tomas Carnecky <tom@dbservice.com>
Date : 2011-04-23 07:51 (51 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=35572
Subject : eeprom module: modprobing hangs
Submitter : Mark <markotahal@gmail.com>
Date : 2011-05-21 20:17 (23 days old)
Handled-By : Jean Delvare <khali@linux-fr.org>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=60812
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=34662
Subject : Warning at block/genhd.c:1556 disk_clear_events
Submitter : Meelis Roos <mroos@linux.ee>
Date : 2011-05-02 9:59 (42 days old)
Message-ID : <alpine.SOC.1.00.1105021255400.6200@math.ut.ee>
References : http://marc.info/?l=linux-kernel&m=130433037002610&w=2
Patch : https://bugzilla.kernel.org/attachment.cgi?id=58262
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=33242
Subject : Lockdep splat in autofs with 2.6.39-rc2
Submitter : Nick Bowler <nbowler@elliptictech.com>
Date : 2011-04-07 19:44 (67 days old)
Message-ID : <20110407194403.GA29404@elliptictech.com>
References : http://marc.info/?l=linux-kernel&m=130220545614682&w=2
Patch : http://marc.info/?l=linux-kernel&m=130342115008659&w=2
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.38 and 2.6.39, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=32012
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* 3.0-rc2: Reported regressions from 2.6.39
From: Rafael J. Wysocki @ 2011-06-12 20:23 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, 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 regressions from 2.6.39,
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 regressions from 2.6.39, 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
----------------------------------------
2011-06-12 8 7 7
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=37242
Subject : lockdep deadlock warning in shutdown
Submitter : Shaohua Li <shaohua.li-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Date : 2011-06-03 3:24 (10 days old)
Message-ID : <1307071472.15392.60.camel@sli10-conroe>
References : http://marc.info/?l=linux-acpi&m=130707148811930&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=37232
Subject : [3.0-rc1][NMI/DMAR][iwlagn] errors - PCI system error (SERR) for reason a1 on CPU 0
Submitter : Shawn Starr <shawn.starr-bJEeYj9oJeDQT0dZR+AlfA@public.gmane.org>
Date : 2011-06-03 4:56 (10 days old)
Message-ID : <4478124.OuFNgaPiHS-RRHT56Q3PSMGBMjmSbuoWl6hYfS7NtTn@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=130707737616116&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=37222
Subject : 3.0.0-rc1-git3 -- kernel/sched.c:619 invoked rcu_dereference_check() without protection!
Submitter : Miles Lane <miles.lane-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-06-04 3:22 (9 days old)
Message-ID : <BANLkTikHS7TuFhm3cfJ+Y=erWDaAwuE_TA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=130715775803343&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36982
Subject : 3.0-rc1 problem with usb, cdrom
Submitter : werner <w.landgraf-ow1r9FSYgO0@public.gmane.org>
Date : 2011-06-01 16:43 (12 days old)
Message-ID : <web-538043386-zcyLqNHFQq3Ee+7He9zlJw@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=130694663410114&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36972
Subject : 3.0-rc1: DMAR errors from iwlagn
Submitter : Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>
Date : 2011-05-31 21:14 (13 days old)
Message-ID : <4DE55A26.6040702-TSDbQ3PG+2Y@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=130687723213857&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36452
Subject : Artifacts with 3.0-rc1 on SandyBridge
Submitter : Alex Zhavnerchik <alex.vizor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-06-01 13:55 (12 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=36302
Subject : SandyBridge can't do s2disk with linux 3.0-rc1
Submitter : Alex Zhavnerchik <alex.vizor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2011-05-30 23:10 (14 days old)
Regressions with patches
------------------------
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 from 2.6.39,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=36912
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* 3c503: fix broken IRQ autoprobing
From: Ondrej Zary @ 2011-06-12 19:40 UTC (permalink / raw)
To: netdev; +Cc: Kernel development list
Fix broken IRQ autoprobing in 3c503 driver:
- improper IRQ freeing (does not free IRQs causes WARN)
- missing break when an working IRQ is found
The driver works with this patch.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
--- linux-2.6.39-rc2-orig/drivers/net/3c503.c 2011-04-06 03:30:43.000000000 +0200
+++ linux-2.6.39-rc2/drivers/net/3c503.c 2011-06-12 21:29:47.000000000 +0200
@@ -412,7 +412,7 @@ el2_open(struct net_device *dev)
outb_p(0x04 << ((*irqp == 9) ? 2 : *irqp), E33G_IDCFR);
outb_p(0x00, E33G_IDCFR);
msleep(1);
- free_irq(*irqp, el2_probe_interrupt);
+ free_irq(*irqp, &seen);
if (!seen)
continue;
@@ -422,6 +422,7 @@ el2_open(struct net_device *dev)
continue;
if (retval < 0)
goto err_disable;
+ break;
} while (*++irqp);
if (*irqp == 0) {
--
Ondrej Zary
^ permalink raw reply
* Re: Question about LRO/GRO and TCP acknowledgements
From: Joris van Rantwijk @ 2011-06-12 19:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1307890657.2872.158.camel@edumazet-laptop>
On 2011-06-12, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Think of GRO being a receiver facility against stress/load, typically
> in datacenter.
>
> Only when receiver is overloaded, GRO kicks in and can coalesce
> several frames before being handled in TCP stack in one run.
Ok, it now becomes clear to me that I have a different scenario in mind
than GRO was designed to handle. I'm interested in LRO as a method
to sustain 1 Gbit through a single TCP connection on a slow embedded
computer.
> If receiver is so loaded that more than 2 frames are coalesced in a
> NAPI run, it certainly helps to not allow sender to increase its cwnd
> more than one SMSS. We probably are right before packet drops anyway.
Right. So unlike TSO, GRO is not a transparent, generally applicable
performance improvement. It's more like a form of graceful degradation,
helping a server to sustain overall throughput when it is already
swamped in TCP traffic.
Thanks for your clarification. This has certainly solved some confusion
on my side.
Joris.
^ permalink raw reply
* Re: [RFC] breakage in sysfs_readdir() and s_instances abuse in sysfs
From: Al Viro @ 2011-06-12 18:35 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-fsdevel, Linus Torvalds, netdev, Linux Containers
In-Reply-To: <m1y617wmeb.fsf@fess.ebiederm.org>
On Sun, Jun 12, 2011 at 12:15:40AM -0700, Eric W. Biederman wrote:
> I honestly hate the pattern that is being used here. Holding a
> reference count because we can't be bothered to free things reliably
> when we actually stop using them. It does look less error prone than
> what I am doing today, and 2.5KiB for struct net isn't that much memory
> to pin.
What pattern? Dual refcounts, one for tearing the contents down and another
for keeping the structure allocated (and it address not reused)? We are
using that kind of stuff for many things. Sure, we have cases when there
are pointers to object not contributing to refcount, to be removed on
object destruction. But if you look at those you'll see that normally
it's done for something like "this object can be found in cyclic list/hash
chain/etc.; those references are not affecting refcount and we simply remove
the object from those lists when refcount hits zero". The thing is, those
references are trivially found starting at the object. In case of non-counting
references from sysfs superblocks it's nowhere near that. And in cases of
that kind the use of dual refcounts is normal.
BTW, speaking of refcounts - I have a pending patch fixing a pid_namespace
leak in proc_set_super(); will be in the next pull request. anon_set_super()
can fail...
> Will pinning an extra 2.5KiB be a problem when we get to the point where
> unprivileged mounts are safe? I expect there are easier ways to pin more
> memory so I doubt this is worth worrying about.
*snort*
chdir deep enough into sysfs tree and you've got it.
> It isn't clear what is taking or putting what kind of refcount from the
> names. If we don't correct the bad naming your patch will be worse for
> maintenance than what we already have.
Agreed. Suggestions of better names are welcome. In particular, I considered
s/count/active/ and calling new refcount "count".
> We need to rename kobj_ns_current so it is clear we get a ref count.
Agreed. Suggestions?
> > + for (type = KOBJ_NS_TYPE_NONE; type < KOBJ_NS_TYPES; type++)
> > + kobj_ns_put(type, info->ns[type]);
>
> This loop and the kfree probably deserve a small function of their own.
OK.
> I really don't like removing const here. It made it very clear that
> what we are messing with is a token and not something that we ever will
> deference.
But we will - when we drop the reference, refcount is going to change...
> > +static void *net_current_ns(void)
> > {
> > - return current->nsproxy->net_ns;
> > + struct net *ns = current->nsproxy->net_ns;
> > +#ifdef CONFIG_NET_NS
> > + if (ns)
> > + atomic_inc(&ns->passive);
> > +#endif
> This code doesn't need to be #ifdef'd
> > + return ns;
> > }
It does, unless we want to make net_put_ns() non-NULL in !NET_NS case...
> > +void net_put_ns(void *p)
> > +{
> There has got to be a better name. We already have put and get net
> methods.
Um... Suggestions? hold_current_ns/drop_ns?
^ permalink raw reply
* Re: [RFC] breakage in sysfs_readdir() and s_instances abuse in sysfs
From: Al Viro @ 2011-06-12 18:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric W. Biederman, linux-fsdevel, netdev, Linux Containers
In-Reply-To: <BANLkTi=AfYH1eg_O1N2M9BfcF=UmBFPy6w@mail.gmail.com>
On Sun, Jun 12, 2011 at 10:59:42AM -0700, Linus Torvalds wrote:
> On Sun, Jun 12, 2011 at 12:15 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
> >
> > I honestly hate the pattern that is being used here. ?Holding a
> > reference count because we can't be bothered to free things reliably
> > when we actually stop using them.
>
> WHAT?
>
> That's what a reference count *is*. It's all about "free things
> reliably when we actually stop using them".
>
> Your comment makes zero sense.
>
> EVERY SINGLE kernel data structure should be reference counted. Read
> Documentation/CodingStyle, or look at any of the good code in the
> kernel (ie core process or VFS code). A non-refcounted data structure
> that is used by more than one entity IS A BUG!
>
> Quite frankly, your objection sounds moronic. If there is more than
> one user, then a reference count is _always_ the right thing. Nothing
> else ever works, and trust me, people have tried. They've tried
> locking, they've tried luck, they've tried crazy things. Nothing but
> refcounts works.
No, what the current code is trying to do is to have two kinds of references -
contributing to refcount (they do have one, all right) and non-contributing.
*AND* it attempts to hunt non-contributing ones down and replace them with
NULL when refcount hits zero. And fscks up in dealing with the results.
What this patch does is pretty much the same thing we do for mm_struct and
superblocks - two refcounts, one controlling the shutdown of object and another
controlling the actual freeing of memory. The second kind of references
contributes to the "memory" refcount and so does having non-zero "active"
refcount. No games with replacing references with NULL, no races around those,
etc.
Eric's objection is that sysfs superblock would pin the memory occupied by
struct net down until it's unmounted. Frankly, I think it's a BS -
aforementioned 2.5K are trivial to pin down *anyway*. Just chdir deep
enough into that instance of sysfs tree and inodes/dentries you've pinned
down by that will easily eat this much.
^ permalink raw reply
* Re: [RFC] breakage in sysfs_readdir() and s_instances abuse in sysfs
From: Linus Torvalds @ 2011-06-12 17:59 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Al Viro, linux-fsdevel, netdev, Linux Containers
In-Reply-To: <m1y617wmeb.fsf@fess.ebiederm.org>
On Sun, Jun 12, 2011 at 12:15 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
>
> I honestly hate the pattern that is being used here. Holding a
> reference count because we can't be bothered to free things reliably
> when we actually stop using them.
WHAT?
That's what a reference count *is*. It's all about "free things
reliably when we actually stop using them".
Your comment makes zero sense.
EVERY SINGLE kernel data structure should be reference counted. Read
Documentation/CodingStyle, or look at any of the good code in the
kernel (ie core process or VFS code). A non-refcounted data structure
that is used by more than one entity IS A BUG!
Quite frankly, your objection sounds moronic. If there is more than
one user, then a reference count is _always_ the right thing. Nothing
else ever works, and trust me, people have tried. They've tried
locking, they've tried luck, they've tried crazy things. Nothing but
refcounts works.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" 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: KVM induced panic on 2.6.38[2367] & 2.6.39
From: Avi Kivity @ 2011-06-12 15:38 UTC (permalink / raw)
To: Simon Horman
Cc: Brad Campbell, Eric Dumazet, Patrick McHardy, Bart De Schuymer,
kvm, linux-mm, linux-kernel, netdev, netfilter-devel
In-Reply-To: <20110610025249.GD643@verge.net.au>
On 06/10/2011 05:52 AM, Simon Horman wrote:
> At one point I would have need an 8000km long wire to the reset switch :-)
Even more off-topic, there has been a case when a 200,000,000 km long
wire to the reset button was needed. IIRC they got away with a watchdog.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Question about LRO/GRO and TCP acknowledgements
From: Eric Dumazet @ 2011-06-12 14:57 UTC (permalink / raw)
To: Joris van Rantwijk; +Cc: netdev
In-Reply-To: <20110612132428.3e1a4593@konijn>
Le dimanche 12 juin 2011 à 13:24 +0200, Joris van Rantwijk a écrit :
> On 2011-06-12, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > So your concern is more a Sender side implementation missing this
> > recommendation, not GRO per se...
>
> Not really. The same RFC says:
> Specifically, an ACK SHOULD be generated for at least every
> second full-sized segment, ...
>
Well, SHOULD is not MUST.
> I can see how the world may have been a better place if every sender
> implemented Appropriate Byte Counting and TCP receivers were allowed to
> send fewer ACKs. However, current reality is that ABC is optional,
> disabled by default in Linux, and receivers are recommended to send one
> ACK per two segments.
>
ABC might be nice for stacks that use byte counters for cwnd. We use
segments.
> I suspect that GRO currently hurts throughput of isolated TCP
> connections. This is based on a purely theoretic argument. I may be
> wrong and I have absolutely no data to confirm my suspicion.
>
> If you can point out the flaw in my reasoning, I would be greatly
> relieved. Until then, I remain concerned that there may be something
> wrong with GRO and TCP ACKs.
Think of GRO being a receiver facility against stress/load, typically in
datacenter.
Only when receiver is overloaded, GRO kicks in and can coalesce several
frames before being handled in TCP stack in one run.
If receiver is so loaded that more than 2 frames are coalesced in a NAPI
run, it certainly helps to not allow sender to increase its cwnd more
than one SMSS. We probably are right before packet drops anyway.
^ permalink raw reply
* [RFC v2 01/04] net: make net_create() globally visible
From: Vasiliy Kulikov @ 2011-06-12 14:43 UTC (permalink / raw)
To: linux-kernel
Cc: kernel-hardening, Andrew Morton, Greg Kroah-Hartman,
David S. Miller, Eric Dumazet, netdev
Make net_create() visible outside of net/core/net_namespace.c to be able
to create additional network namespaces inside of fs/proc/proc_net.c.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
include/net/net_namespace.h | 2 ++
net/core/net_namespace.c | 2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index 1bf812b..d40c61c 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -113,6 +113,8 @@ static inline struct net *copy_net_ns(unsigned long flags, struct net *net_ns)
}
#endif /* CONFIG_NET */
+extern struct net *net_create(void);
+
extern struct list_head net_namespace_list;
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 3f86026..c7c7310 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -216,7 +216,7 @@ static void net_free(struct net *net)
kmem_cache_free(net_cachep, net);
}
-static struct net *net_create(void)
+struct net *net_create(void)
{
struct net *net;
int rv;
^ permalink raw reply related
* [PATCH] ieee802154: Don't leak memory in ieee802154_nl_fill_phy
From: Jesper Juhl @ 2011-06-12 14:28 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, linux-zigbee-devel, David S. Miller, Sergey Lapin,
Dmitry Eremin-Solenikov, Maxim Osipov
In net/ieee802154/nl-phy.c::ieee802154_nl_fill_phy() I see two small
issues.
1) If the allocation of 'buf' fails we may just as well return -EMSGSIZE
directly rather than jumping to 'out:' and do a pointless kfree(0).
2) We do not free 'buf' unless we jump to one of the error labels and this
leaks memory.
This patch should address both.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
nl-phy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
I have no way to properly test this patch, so it's compile tested only.
diff --git a/net/ieee802154/nl-phy.c b/net/ieee802154/nl-phy.c
index ed0eab3..02548b2 100644
--- a/net/ieee802154/nl-phy.c
+++ b/net/ieee802154/nl-phy.c
@@ -44,7 +44,7 @@ static int ieee802154_nl_fill_phy(struct sk_buff *msg, u32 pid,
pr_debug("%s\n", __func__);
if (!buf)
- goto out;
+ return -EMSGSIZE;
hdr = genlmsg_put(msg, 0, seq, &nl802154_family, flags,
IEEE802154_LIST_PHY);
@@ -65,6 +65,7 @@ static int ieee802154_nl_fill_phy(struct sk_buff *msg, u32 pid,
pages * sizeof(uint32_t), buf);
mutex_unlock(&phy->pib_lock);
+ kfree(buf);
return genlmsg_end(msg, hdr);
nla_put_failure:
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* Re: [RFC] procfs: add hidepid and hidenet modes
From: Vasiliy Kulikov @ 2011-06-12 12:43 UTC (permalink / raw)
To: Alexey Dobriyan
Cc: linux-kernel, David S. Miller, Andrew Morton, Linus Torvalds,
Nikanth Karthikesan, David Rientjes, Greg Kroah-Hartman, Al Viro,
Eric Dumazet, netdev, kernel-hardening
In-Reply-To: <20110612111222.GA23467@p183.telecom.by>
On Sun, Jun 12, 2011 at 14:12 +0300, Alexey Dobriyan wrote:
> On Sun, Jun 12, 2011 at 11:51:01AM +0400, Vasiliy Kulikov wrote:
> > hidenet means /proc/PID/net will be accessible to processes with
> > CAP_NET_ADMIN capability or to members of a special group.
> >
> > gid=XXX defines a group that will be able to gather all processes' info
> > and network connections info.
> >
> > Similar features are implemented for old kernels in -ow patches (for
> > Linux 2.2 and 2.4) and for Linux 2.6 in -grsecurity (but both of them
> > are implemented as configure options, not cofigurable in runtime).
> >
> >
> > In current version hidenet works for CONFIG_NET_NS=y via creating a
> > "fake" net namespace and slipping it to nonauthorized users, resulting
> > in users observing blank net files (like nobody use the network). If
> > CONFIG_NET_NS=n I don't see anything better than just fully denying
> > access to /proc/<pid>/net. More elegant ideas are welcome.
>
> This fake netns concept is ugly.
> If you wan't deny something, why don't you return -E?
Sorry, I should have mentioned it. It's a workaround. The thing is
that /proc/net/* is so core and existed for a long time that some
programs might be confused if these files are missing or if open()
returns -EXXX. netstat handles this and outputs smth like "Networking
was disabled in your kernel", which is a bit confusing. Also I saw some
programs didn't handle missing files at all, I recall brctl sigfaulted
when he couldn't access some sysfs file.
As fake_net doesn't break something, but instead keeps some
compatibility with old programs, why don't use it?
BTW, there is no fake_net in -ow or -grsecurity. I thought it might be
helpful for upstream in sense of compatibility.
> Regardless, these should be separate patch from PID stuff.
No problem.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: [PATCH] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: Marius Kotsbak @ 2011-06-12 12:36 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110611.162942.1706711069327005315.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 12. juni 2011 01:29, David Miller wrote:
> From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Date: Sat, 11 Jun 2011 16:27:11 -0700 (PDT)
>
>> From: "Marius B. Kotsbak" <marius.kotsbak-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> Date: Sat, 11 Jun 2011 23:55:18 +0200
>>
>>> Introducing driver for the network port of Samsung Kalmia based USB LTE modems.
>>> It has also an ACM interface that previous patches associates with the "option"
>>> module. To access those interfaces, the modem must first be switched from modem
>>> mode using a tool like usb_modeswitch.
>>>
>>> As the proprietary protocol has been discovered by watching the MS Windows driver
>>> behavior, there might be errors in the protocol handling, but stable and fast
>>> connection has been established for hours with Norwegian operator NetCom that
>>> distributes this modem with their LTE/4G subscription.
>>>
>>> More and updated information about how to use this driver is available here:
>>>
>>> http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=465
>>> https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver
>>>
>>> Signed-off-by: Marius B. Kotsbak <marius-iy5w9mehe2BBDgjK7y7TUQ@public.gmane.org>
>> Applied, thanks.
> Actually, reverted.
>
> There's a typo in your Makefile patch, and because of this it
> won't even build the new driver.
Oh sorry, I did make on the actual kalmia.ko to avoid building all
modules, so I did not notice. Sending a fixed patch. Ben, thanks for
pointing out.
> People are so damn anxious to get this backported into stable
> and various distributions,
Japp, people keeps asking for a version that compiles with kernel 2.6.32
for the Ubuntu LTS...
> yet this patch wasn't even tested
> properly.
We were compiling it out of the kernel tree until now.
--
Marius
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] net/usb: Add Samsung Kalmia driver for Samsung GT-B3730
From: Marius B. Kotsbak @ 2011-06-12 12:35 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Marius B. Kotsbak
In-Reply-To: <20110611.162942.1706711069327005315.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Introducing driver for the network port of Samsung Kalmia based USB LTE modems.
It has also an ACM interface that previous patches associates with the "option"
module. To access those interfaces, the modem must first be switched from modem
mode using a tool like usb_modeswitch.
As the proprietary protocol has been discovered by watching the MS Windows driver
behavior, there might be errors in the protocol handling, but stable and fast
connection has been established for hours with Norwegian operator NetCom that
distributes this modem with their LTE/4G subscription.
More and updated information about how to use this driver is available here:
http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=465
https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver
Signed-off-by: Marius B. Kotsbak <marius-iy5w9mehe2BBDgjK7y7TUQ@public.gmane.org>
---
drivers/net/usb/Kconfig | 10 ++
drivers/net/usb/Makefile | 1 +
drivers/net/usb/kalmia.c | 384 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 395 insertions(+), 0 deletions(-)
create mode 100644 drivers/net/usb/kalmia.c
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 9d4f911..84d4608 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -385,6 +385,16 @@ config USB_NET_CX82310_ETH
router with USB ethernet port. This driver is for routers only,
it will not work with ADSL modems (use cxacru driver instead).
+config USB_NET_KALMIA
+ tristate "Samsung Kalmia based LTE USB modem"
+ depends on USB_USBNET
+ help
+ Choose this option if you have a Samsung Kalmia based USB modem
+ as Samsung GT-B3730.
+
+ To compile this driver as a module, choose M here: the
+ module will be called kalmia.
+
config USB_HSO
tristate "Option USB High Speed Mobile Devices"
depends on USB && RFKILL
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index c7ec8a5..c203fa2 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_USB_NET_MCS7830) += mcs7830.o
obj-$(CONFIG_USB_USBNET) += usbnet.o
obj-$(CONFIG_USB_NET_INT51X1) += int51x1.o
obj-$(CONFIG_USB_CDC_PHONET) += cdc-phonet.o
+obj-$(CONFIG_USB_NET_KALMIA) += kalmia.o
obj-$(CONFIG_USB_IPHETH) += ipheth.o
obj-$(CONFIG_USB_SIERRA_NET) += sierra_net.o
obj-$(CONFIG_USB_NET_CX82310_ETH) += cx82310_eth.o
diff --git a/drivers/net/usb/kalmia.c b/drivers/net/usb/kalmia.c
new file mode 100644
index 0000000..d965fb1
--- /dev/null
+++ b/drivers/net/usb/kalmia.c
@@ -0,0 +1,384 @@
+/*
+ * USB network interface driver for Samsung Kalmia based LTE USB modem like the
+ * Samsung GT-B3730 and GT-B3710.
+ *
+ * Copyright (C) 2011 Marius Bjoernstad Kotsbak <marius-iy5w9mehe2BBDgjK7y7TUQ@public.gmane.org>
+ *
+ * Sponsored by Quicklink Video Distribution Services Ltd.
+ *
+ * Based on the cdc_eem module.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/ctype.h>
+#include <linux/ethtool.h>
+#include <linux/workqueue.h>
+#include <linux/mii.h>
+#include <linux/usb.h>
+#include <linux/crc32.h>
+#include <linux/usb/cdc.h>
+#include <linux/usb/usbnet.h>
+#include <linux/gfp.h>
+
+/*
+ * The Samsung Kalmia based LTE USB modems have a CDC ACM port for modem control
+ * handled by the "option" module and an ethernet data port handled by this
+ * module.
+ *
+ * The stick must first be switched into modem mode by usb_modeswitch
+ * or similar tool. Then the modem gets sent two initialization packets by
+ * this module, which gives the MAC address of the device. User space can then
+ * connect the modem using AT commands through the ACM port and then use
+ * DHCP on the network interface exposed by this module. Network packets are
+ * sent to and from the modem in a proprietary format discovered after watching
+ * the behavior of the windows driver for the modem.
+ *
+ * More information about the use of the modem is available in usb_modeswitch
+ * forum and the project page:
+ *
+ * http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=465
+ * https://github.com/mkotsbak/Samsung-GT-B3730-linux-driver
+ */
+
+/* #define DEBUG */
+/* #define VERBOSE */
+
+#define KALMIA_HEADER_LENGTH 6
+#define KALMIA_ALIGN_SIZE 4
+#define KALMIA_USB_TIMEOUT 10000
+
+/*-------------------------------------------------------------------------*/
+
+static int
+kalmia_send_init_packet(struct usbnet *dev, u8 *init_msg, u8 init_msg_len,
+ u8 *buffer, u8 expected_len)
+{
+ int act_len;
+ int status;
+
+ netdev_dbg(dev->net, "Sending init packet");
+
+ status = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 0x02),
+ init_msg, init_msg_len, &act_len, KALMIA_USB_TIMEOUT);
+ if (status != 0) {
+ netdev_err(dev->net,
+ "Error sending init packet. Status %i, length %i\n",
+ status, act_len);
+ return status;
+ }
+ else if (act_len != init_msg_len) {
+ netdev_err(dev->net,
+ "Did not send all of init packet. Bytes sent: %i",
+ act_len);
+ }
+ else {
+ netdev_dbg(dev->net, "Successfully sent init packet.");
+ }
+
+ status = usb_bulk_msg(dev->udev, usb_rcvbulkpipe(dev->udev, 0x81),
+ buffer, expected_len, &act_len, KALMIA_USB_TIMEOUT);
+
+ if (status != 0)
+ netdev_err(dev->net,
+ "Error receiving init result. Status %i, length %i\n",
+ status, act_len);
+ else if (act_len != expected_len)
+ netdev_err(dev->net, "Unexpected init result length: %i\n",
+ act_len);
+
+ return status;
+}
+
+static int
+kalmia_init_and_get_ethernet_addr(struct usbnet *dev, u8 *ethernet_addr)
+{
+ char init_msg_1[] =
+ { 0x57, 0x50, 0x04, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x00,
+ 0x00, 0x00 };
+ char init_msg_2[] =
+ { 0x57, 0x50, 0x04, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0xf4,
+ 0x00, 0x00 };
+ char receive_buf[28];
+ int status;
+
+ status = kalmia_send_init_packet(dev, init_msg_1, sizeof(init_msg_1)
+ / sizeof(init_msg_1[0]), receive_buf, 24);
+ if (status != 0)
+ return status;
+
+ status = kalmia_send_init_packet(dev, init_msg_2, sizeof(init_msg_2)
+ / sizeof(init_msg_2[0]), receive_buf, 28);
+ if (status != 0)
+ return status;
+
+ memcpy(ethernet_addr, receive_buf + 10, ETH_ALEN);
+
+ return status;
+}
+
+static int
+kalmia_bind(struct usbnet *dev, struct usb_interface *intf)
+{
+ u8 status;
+ u8 ethernet_addr[ETH_ALEN];
+
+ /* Don't bind to AT command interface */
+ if (intf->cur_altsetting->desc.bInterfaceClass != USB_CLASS_VENDOR_SPEC)
+ return -EINVAL;
+
+ dev->in = usb_rcvbulkpipe(dev->udev, 0x81 & USB_ENDPOINT_NUMBER_MASK);
+ dev->out = usb_sndbulkpipe(dev->udev, 0x02 & USB_ENDPOINT_NUMBER_MASK);
+ dev->status = NULL;
+
+ dev->net->hard_header_len += KALMIA_HEADER_LENGTH;
+ dev->hard_mtu = 1400;
+ dev->rx_urb_size = dev->hard_mtu * 10; // Found as optimal after testing
+
+ status = kalmia_init_and_get_ethernet_addr(dev, ethernet_addr);
+
+ if (status < 0) {
+ usb_set_intfdata(intf, NULL);
+ usb_driver_release_interface(driver_of(intf), intf);
+ return status;
+ }
+
+ memcpy(dev->net->dev_addr, ethernet_addr, ETH_ALEN);
+ memcpy(dev->net->perm_addr, ethernet_addr, ETH_ALEN);
+
+ return status;
+}
+
+static struct sk_buff *
+kalmia_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
+{
+ struct sk_buff *skb2 = NULL;
+ u16 content_len;
+ unsigned char *header_start;
+ unsigned char ether_type_1, ether_type_2;
+ u8 remainder, padlen = 0;
+
+ if (!skb_cloned(skb)) {
+ int headroom = skb_headroom(skb);
+ int tailroom = skb_tailroom(skb);
+
+ if ((tailroom >= KALMIA_ALIGN_SIZE) && (headroom
+ >= KALMIA_HEADER_LENGTH))
+ goto done;
+
+ if ((headroom + tailroom) > (KALMIA_HEADER_LENGTH
+ + KALMIA_ALIGN_SIZE)) {
+ skb->data = memmove(skb->head + KALMIA_HEADER_LENGTH,
+ skb->data, skb->len);
+ skb_set_tail_pointer(skb, skb->len);
+ goto done;
+ }
+ }
+
+ skb2 = skb_copy_expand(skb, KALMIA_HEADER_LENGTH,
+ KALMIA_ALIGN_SIZE, flags);
+ if (!skb2)
+ return NULL;
+
+ dev_kfree_skb_any(skb);
+ skb = skb2;
+
+ done: header_start = skb_push(skb, KALMIA_HEADER_LENGTH);
+ ether_type_1 = header_start[KALMIA_HEADER_LENGTH + 12];
+ ether_type_2 = header_start[KALMIA_HEADER_LENGTH + 13];
+
+ netdev_dbg(dev->net, "Sending etherType: %02x%02x", ether_type_1,
+ ether_type_2);
+
+ /* According to empiric data for data packages */
+ header_start[0] = 0x57;
+ header_start[1] = 0x44;
+ content_len = skb->len - KALMIA_HEADER_LENGTH;
+ header_start[2] = (content_len & 0xff); /* low byte */
+ header_start[3] = (content_len >> 8); /* high byte */
+
+ header_start[4] = ether_type_1;
+ header_start[5] = ether_type_2;
+
+ /* Align to 4 bytes by padding with zeros */
+ remainder = skb->len % KALMIA_ALIGN_SIZE;
+ if (remainder > 0) {
+ padlen = KALMIA_ALIGN_SIZE - remainder;
+ memset(skb_put(skb, padlen), 0, padlen);
+ }
+
+ netdev_dbg(
+ dev->net,
+ "Sending package with length %i and padding %i. Header: %02x:%02x:%02x:%02x:%02x:%02x.",
+ content_len, padlen, header_start[0], header_start[1],
+ header_start[2], header_start[3], header_start[4],
+ header_start[5]);
+
+ return skb;
+}
+
+static int
+kalmia_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+{
+ /*
+ * Our task here is to strip off framing, leaving skb with one
+ * data frame for the usbnet framework code to process.
+ */
+ const u8 HEADER_END_OF_USB_PACKET[] =
+ { 0x57, 0x5a, 0x00, 0x00, 0x08, 0x00 };
+ const u8 EXPECTED_UNKNOWN_HEADER_1[] =
+ { 0x57, 0x43, 0x1e, 0x00, 0x15, 0x02 };
+ const u8 EXPECTED_UNKNOWN_HEADER_2[] =
+ { 0x57, 0x50, 0x0e, 0x00, 0x00, 0x00 };
+ u8 i = 0;
+
+ /* incomplete header? */
+ if (skb->len < KALMIA_HEADER_LENGTH)
+ return 0;
+
+ do {
+ struct sk_buff *skb2 = NULL;
+ u8 *header_start;
+ u16 usb_packet_length, ether_packet_length;
+ int is_last;
+
+ header_start = skb->data;
+
+ if (unlikely(header_start[0] != 0x57 || header_start[1] != 0x44)) {
+ if (!memcmp(header_start, EXPECTED_UNKNOWN_HEADER_1,
+ sizeof(EXPECTED_UNKNOWN_HEADER_1)) || !memcmp(
+ header_start, EXPECTED_UNKNOWN_HEADER_2,
+ sizeof(EXPECTED_UNKNOWN_HEADER_2))) {
+ netdev_dbg(
+ dev->net,
+ "Received expected unknown frame header: %02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n",
+ header_start[0], header_start[1],
+ header_start[2], header_start[3],
+ header_start[4], header_start[5],
+ skb->len - KALMIA_HEADER_LENGTH);
+ }
+ else {
+ netdev_err(
+ dev->net,
+ "Received unknown frame header: %02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n",
+ header_start[0], header_start[1],
+ header_start[2], header_start[3],
+ header_start[4], header_start[5],
+ skb->len - KALMIA_HEADER_LENGTH);
+ return 0;
+ }
+ }
+ else
+ netdev_dbg(
+ dev->net,
+ "Received header: %02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n",
+ header_start[0], header_start[1], header_start[2],
+ header_start[3], header_start[4], header_start[5],
+ skb->len - KALMIA_HEADER_LENGTH);
+
+ /* subtract start header and end header */
+ usb_packet_length = skb->len - (2 * KALMIA_HEADER_LENGTH);
+ ether_packet_length = header_start[2] + (header_start[3] << 8);
+ skb_pull(skb, KALMIA_HEADER_LENGTH);
+
+ /* Some small packets misses end marker */
+ if (usb_packet_length < ether_packet_length) {
+ ether_packet_length = usb_packet_length
+ + KALMIA_HEADER_LENGTH;
+ is_last = true;
+ }
+ else {
+ netdev_dbg(dev->net, "Correct package length #%i", i
+ + 1);
+
+ is_last = (memcmp(skb->data + ether_packet_length,
+ HEADER_END_OF_USB_PACKET,
+ sizeof(HEADER_END_OF_USB_PACKET)) == 0);
+ if (!is_last) {
+ header_start = skb->data + ether_packet_length;
+ netdev_dbg(
+ dev->net,
+ "End header: %02x:%02x:%02x:%02x:%02x:%02x. Package length: %i\n",
+ header_start[0], header_start[1],
+ header_start[2], header_start[3],
+ header_start[4], header_start[5],
+ skb->len - KALMIA_HEADER_LENGTH);
+ }
+ }
+
+ if (is_last) {
+ skb2 = skb;
+ }
+ else {
+ skb2 = skb_clone(skb, GFP_ATOMIC);
+ if (unlikely(!skb2))
+ return 0;
+ }
+
+ skb_trim(skb2, ether_packet_length);
+
+ if (is_last) {
+ return 1;
+ }
+ else {
+ usbnet_skb_return(dev, skb2);
+ skb_pull(skb, ether_packet_length);
+ }
+
+ i++;
+ }
+ while (skb->len);
+
+ return 1;
+}
+
+static const struct driver_info kalmia_info = {
+ .description = "Samsung Kalmia LTE USB dongle",
+ .flags = FLAG_WWAN,
+ .bind = kalmia_bind,
+ .rx_fixup = kalmia_rx_fixup,
+ .tx_fixup = kalmia_tx_fixup
+};
+
+/*-------------------------------------------------------------------------*/
+
+static const struct usb_device_id products[] = {
+ /* The unswitched USB ID, to get the module auto loaded: */
+ { USB_DEVICE(0x04e8, 0x689a) },
+ /* The stick swithed into modem (by e.g. usb_modeswitch): */
+ { USB_DEVICE(0x04e8, 0x6889),
+ .driver_info = (unsigned long) &kalmia_info, },
+ { /* EMPTY == end of list */} };
+MODULE_DEVICE_TABLE( usb, products);
+
+static struct usb_driver kalmia_driver = {
+ .name = "kalmia",
+ .id_table = products,
+ .probe = usbnet_probe,
+ .disconnect = usbnet_disconnect,
+ .suspend = usbnet_suspend,
+ .resume = usbnet_resume
+};
+
+static int __init kalmia_init(void)
+{
+ return usb_register(&kalmia_driver);
+}
+module_init( kalmia_init);
+
+static void __exit kalmia_exit(void)
+{
+ usb_deregister(&kalmia_driver);
+}
+module_exit( kalmia_exit);
+
+MODULE_AUTHOR("Marius Bjoernstad Kotsbak <marius-iy5w9mehe2BBDgjK7y7TUQ@public.gmane.org>");
+MODULE_DESCRIPTION("Samsung Kalmia USB network driver");
+MODULE_LICENSE("GPL");
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V3 10/10] smsc9420: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Steve Glendinning
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
for the smsc9420. Compile tested only.
Cc: Steve Glendinning <steve.glendinning@smsc.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/smsc9420.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smsc9420.c b/drivers/net/smsc9420.c
index 4c92ad8..2d84f92 100644
--- a/drivers/net/smsc9420.c
+++ b/drivers/net/smsc9420.c
@@ -1034,6 +1034,8 @@ static netdev_tx_t smsc9420_hard_start_xmit(struct sk_buff *skb,
smsc9420_reg_write(pd, TX_POLL_DEMAND, 1);
smsc9420_pci_flush_write(pd);
+ skb_tx_timestamp(skb);
+
return NETDEV_TX_OK;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 09/10] stmmac: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Giuseppe Cavallaro
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
for the STMicroelectronics Ethernet driver. Compile tested only.
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/stmmac/stmmac_main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
index e25e44a..5b85f4c 100644
--- a/drivers/net/stmmac/stmmac_main.c
+++ b/drivers/net/stmmac/stmmac_main.c
@@ -1081,6 +1081,8 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
priv->hw->dma->enable_dma_transmission(priv->ioaddr);
+ skb_tx_timestamp(skb);
+
return NETDEV_TX_OK;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 08/10] r6040: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Florian Fainelli
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
for the RDC R6040 Fast Ethernet MAC. Compile tested only.
Cc: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/r6040.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c
index 200a363..5ee5f8f 100644
--- a/drivers/net/r6040.c
+++ b/drivers/net/r6040.c
@@ -846,6 +846,8 @@ static netdev_tx_t r6040_start_xmit(struct sk_buff *skb,
spin_unlock_irqrestore(&lp->lock, flags);
+ skb_tx_timestamp(skb);
+
return NETDEV_TX_OK;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 07/10] ethoc: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Thierry Reding
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
for the OpenCores 10/100 MAC driver. Compile tested only.
Cc: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/ethoc.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethoc.c b/drivers/net/ethoc.c
index a83dd31..8645ec8 100644
--- a/drivers/net/ethoc.c
+++ b/drivers/net/ethoc.c
@@ -874,6 +874,7 @@ static netdev_tx_t ethoc_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
spin_unlock_irq(&priv->lock);
+ skb_tx_timestamp(skb);
out:
dev_kfree_skb(skb);
return NETDEV_TX_OK;
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 06/10] dnet: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Ilya Yanok
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
in the "Dave ethernet interface." Compile tested only.
Cc: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/dnet.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/dnet.c b/drivers/net/dnet.c
index 8318ea0..c36763c 100644
--- a/drivers/net/dnet.c
+++ b/drivers/net/dnet.c
@@ -587,6 +587,8 @@ static netdev_tx_t dnet_start_xmit(struct sk_buff *skb, struct net_device *dev)
dnet_writel(bp, irq_enable, INTR_ENB);
}
+ skb_tx_timestamp(skb);
+
/* free the buffer */
dev_kfree_skb(skb);
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 05/10] tg3: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Matt Carlson, Michael Chan
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
for the TIGON3 driver. Compile tested only.
Cc: Matt Carlson <mcarlson@broadcom.com>
Cc: Michael Chan <mchan@broadcom.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/tg3.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a1f9f9e..743d997 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6091,6 +6091,8 @@ static netdev_tx_t tg3_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* Packets are ready, update Tx producer idx local and on card. */
tw32_tx_mbox(tnapi->prodmbox, entry);
+ skb_tx_timestamp(skb);
+
tnapi->tx_prod = entry;
if (unlikely(tg3_tx_avail(tnapi) <= (MAX_SKB_FRAGS + 1))) {
netif_tx_stop_queue(txq);
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 04/10] davinci_emac: enable transmit time stamping.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Anant Gole, Kevin Hilman
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
This patch enables software (and phy device) transmit time stamping
for the DaVinci EMAC driver. Tested together with the dp83640 PHY.
Cc: Anant Gole <anantgole@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/davinci_emac.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 5c2baa4..f5688ff 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1090,6 +1090,7 @@ static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
dev_err(emac_dev, "DaVinci EMAC: desc submit failed");
goto fail_tx;
}
+ skb_tx_timestamp(skb);
return NETDEV_TX_OK;
--
1.7.0.4
^ permalink raw reply related
* [PATCH V3 03/10] davinci_emac: pass ioctls through to phy device.
From: Richard Cochran @ 2011-06-12 12:19 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Anant Gole, Kevin Hilman
In-Reply-To: <cover.1307880494.git.richard.cochran@omicron.at>
The DaVinci EMAC driver does not implement any ioctls, but still it can
pass them through to the phy device. This makes it possible for a phy
to offer PHC capabilities.
Cc: Anant Gole <anantgole@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Richard Cochran <richard.cochran@omicron.at>
---
drivers/net/davinci_emac.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index dcc4a17..5c2baa4 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1489,14 +1489,14 @@ static void emac_adjust_link(struct net_device *ndev)
*/
static int emac_devioctl(struct net_device *ndev, struct ifreq *ifrq, int cmd)
{
- dev_warn(&ndev->dev, "DaVinci EMAC: ioctl not supported\n");
+ struct emac_priv *priv = netdev_priv(ndev);
if (!(netif_running(ndev)))
return -EINVAL;
/* TODO: Add phy read and write and private statistics get feature */
- return -EOPNOTSUPP;
+ return phy_mii_ioctl(priv->phydev, ifrq, cmd);
}
static int match_first_device(struct device *dev, void *data)
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox