r though), I think your series should be good to
go if the STATE_DEACTIVATED fix has been verified independently.
Thanks!
--
Jiri Kosina
SUSE Labs
am still planning to have Yunsheng Lin's (CCing) fix [1] tested in the
coming days. If it works, then we can consider proceeding with it,
otherwise I am all for reverting the whole NOLOCK stuff.
[1]
https://lore.kernel.org/linux-can/1616641991-14847-1-git-send-email-linyunsh...@huawei.com/T/#u
--
Jiri Kosina
SUSE Labs
n
with back in 2019.
Unless there are
(a) any nice ideas how to solve this in an elegant way without
(re-)introducing extra spinlock (Cong's fix) or
(b) any objections to revert as per the argumentation above
I'll be happy to send a revert of the whole NOLOCK implementation next
week.
Thanks,
--
Jiri Kosina
SUSE Labs
e ringbuffer sizes to be at least 2 * PAGE_SIZE when
> using vmbus_open() to establish the vmbus connection.
>
> Signed-off-by: Boqun Feng
Acked-by: Jiri Kosina
--
Jiri Kosina
SUSE Labs
nduced, it's almost certainly a
completely bogus collection. So we are surely missing sanity check that
there exists a collection with idx -1.
> Need to page this back in to figure out what could be happening here.
Thanks,
--
Jiri Kosina
SUSE Labs
drivers/usb/core/hub.c:2554
> > hub_port_connect drivers/usb/core/hub.c:5208 [inline]
> > hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
> > port_event drivers/usb/core/hub.c:5494 [inline]
> > hub_event+0x2823/0x4cb0 drivers/usb/core/hub.c:5576
> > process_one_work+0x76e/0xfd0 kernel/workqueue.c:2268
> > worker_thread+0xa7f/0x1450 kernel/workqueue.c:2414
> > kthread+0x353/0x380 kernel/kthread.c:268
> > ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:351
> >
> >
> > ---
> > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkal...@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> > syzbot can test patches for this bug, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
>
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
ixgbe_reset_hw_82599() resets the value of hw->mac.num_rar_entries to
pre-defined value of 128. Let's get rid of that hardcoded literal, and use
IXGBE_82599_RAR_ENTRIES instead, the same way the normal initialization
path does.
Signed-off-by: Jiri Kosina
---
dri
he above issue moving qdisc_hash_add() right
> after the child qdisc creation. It additionally removes unneeded checks
> for noop_qdisc.
>
> Reported-by: Hangbin Liu
> Fixes: 49b499718fa1 ("net: sched: make default fifo qdiscs appear in the
> dump")
Acked-by: Jiri Kosina
Thanks for fixing this Paolo.
--
Jiri Kosina
SUSE Labs
On Tue, 9 Jan 2018, Josh Poimboeuf wrote:
> On Tue, Jan 09, 2018 at 11:44:05AM -0800, Dan Williams wrote:
> > On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina wrote:
> > > On Fri, 5 Jan 2018, Dan Williams wrote:
> > >
> > > [ ... snip ... ]
> > >>
OP, and something comparable for eBPF JIT?
Is this going to be handled in eBPF in some other way?
Without that in place, and considering Jann Horn's paper, it would seem
like PTI doesn't really lock it down fully, right?
[1] https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=287305
--
Jiri Kosina
SUSE Labs
tatic bool hid_hiddev(struct hid_device *hdev)
> .size = HID_MAX_DESCRIPTOR_SIZE,
> };
>
> -static struct device_attribute dev_attr_country = {
> +static const struct device_attribute dev_attr_country = {
> .attr = { .name = "country", .mode = 0444 },
> .show = show_country,
Applied, thanks.
--
Jiri Kosina
SUSE Labs
it is the default qdisc
> at this point.
>
> Fixes: 59cc1f61f09c ("net: sched: convert qdisc linked list to hashtable")
> Reported-by: Dmitry Vyukov
> Cc: Jiri Kosina
> Signed-off-by: Cong Wang
Acked-by: Jiri Kosina
Thanks.
> ---
> net/sched/sch_generic.c
ticular case to catch cases where
singleton qdisc would make it there from other places by mistake. By
putting this test there we'll effectively giving up on this warning should
it ever point to a bug.
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
The original reason [1] for having hidden qdiscs (potential scalability
issues in qdisc_match_from_root() with single linked list in case of large
amount of qdiscs) has been invalidated by 59cc1f61f0 ("net: sched: convert
qdisc linked list to hashtable").
This all
From: Jiri Kosina
The original reason [1] for having hidden qdiscs (potential scalability
issues in qdisc_match_from_root() with single linked list in case of large
amount of qdiscs) has been invalidated by 59cc1f61f0 ("net: sched: convert
qdisc linked list to hashtable").
This all
From: Jiri Kosina
Support the new TCA_DUMP_INVISIBLE netlink attribute that allows asking
kernel to perform 'full qdisc dump', as for historical reasons some of the
default qdiscs are being hidden by the kernel.
The command syntax is being extended by voluntary 'invisible&#
The command syntax is being extended by voluntary 'invisible' argument to
> > 'tc qdisc show'.
> >
> > Signed-off-by: Jiri Kosina
> > ---
> > tc/tc_qdisc.c | 25 +++--
> > 1 file changed, 23 insertions(+), 2 deletions
so simply any more.
Fully agreed.
I'd be inclined to just live with the fact that noop qdisc would never
ever be visible in the dump. I think that in this particular case this can
be easily justified, as the behavior is consistent with what is seen in
the dump ("nothing happens to the packets"). All other cases will be
covered.
If there are no objections to this, I'll send out v2 shortly.
Thanks,
--
Jiri Kosina
SUSE Labs
sc as well
- I extend this patchset to handle noop qdisc from the very beginning;
I am unlikely to find time for this during coming weeks though. But OTOH
this whole thing is very low priority anyway
What do you think?
Thanks,
--
Jiri Kosina
SUSE Labs
On Sat, 25 Feb 2017, Jiri Kosina wrote:
> This is a followup to a patchset submitted back in October 2016
No idea what happened that my usual patchset sending process broke and
there is no 'References/In-reply-to' in the actual patches :/ I will
investigate that. Please let me
From: Jiri Kosina
The original reason [1] for having hidden qdiscs (potential scalability
issues in qdisc_match_from_root() with single linked list in case of large
amount of qdiscs) has been invalidated by 59cc1f61f0 ("net: sched: convert
qdisc linked list to hashtable").
This all
From: Jiri Kosina
Support the new TCA_DUMP_INVISIBLE netlink attribute that allows asking
kernel to perform 'full qdisc dump', as for historical reasons some of the
default qdiscs are being hidden by the kernel.
The command syntax is being extended by voluntary 'invisible&#
. First patch adds the new
TCA_DUMP_INVISIBLE netlink attribute and its handling in the kernel, the
second one adds the iproute2 counterpart.
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
Rebuilding libnetlink doesn't trigger rebuild of tc, which is wrong
(especially so for builds where libnetlink.a gets statically linked into
tc). Fix that by introducing an explicit dependency.
Signed-off-by: Jiri Kosina
---
tc/Makefile | 2 +-
1 file changed, 1 inse
fault qdiscs, it makes little sense to be
inconsistent in this way.
Random shot into darkness -- how about making this a
CONFIG/sysctl-selectable?
Thanks,
--
Jiri Kosina
SUSE Labs
nging more clarity and determinism into the dump by
making default pfifo qdiscs visible.
[1]
http://lkml.kernel.org/r/1460732328.10638.74.ca...@edumazet-glaptop3.roam.corp.google.com
Signed-off-by: Jiri Kosina
---
Tested for cbq, htb and tbf.
net/sched/sch_cbq.c| 4
net/sched/sch_dr
ch that'd add ingress qdisc to the hashtable whenever it
materializes should be enough to get rid of the "we have to walk two
linked lists" heritage and the ingress special-casing for dumps.
Will look into it next week unless someone is faster.
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
tc_dump_qdisc() performs dumping of the per-device qdiscs in two phases;
first, the "standard" dev->qdisc is being dumped. Second, if there is/are
ingress queue(s), they are being dumped as well.
After conversion of netdevice's qdisc linked-list into has
From: Jiri Kosina
qdisc_match_from_root() is now iterating over per-netdevice qdisc
hashtable instead of going through a linked-list of qdiscs (independently
on the actual underlying netdev), which was the case before the switch to
hashtable for qdiscs.
For singleton qdiscs, there is no
of scope of this patchset (but already on my todo).
Thanks a lot to Daniel Borkmann and David Ahern for reporting the issues
and testing the patches promptly.
Jiri Kosina (2):
net: sched: fix handling of singleton qdiscs with qdisc_hash
net: sched: avoid duplicates in qdisc d
On Tue, 16 Aug 2016, Jiri Kosina wrote:
> > I am hitting a kernel panic with '/etc/init.d/openvswitch-switch
> > restart' Stack trace below. Reverting 59cc1f61f09c ("net: sched: convert
> > qdisc linked list to hashtable") clears the problem.
>
> T
t back to me whether it
fixes any issues you are seeing? Applying the attached patches on top of
net-next or testing with the git branch above should be equivalent test
wrt. qdiscs.
Thanks,
--
Jiri Kosina
SUSE Labs
On Tue, 16 Aug 2016, Jiri Kosina wrote:
> From: Jiri Kosina
>
> qdisc_match_from_root() is now iterating over per-netdevice qdisc
> hashtable instead of going through a linked-list of qdiscs (independently
> on the actual underlying netdev), which used to be the case before t
From: Jiri Kosina
qdisc_match_from_root() is now iterating over per-netdevice qdisc
hashtable instead of going through a linked-list of qdiscs (independently
on the actual underlying netdev), which used to be the case before the
switch to hashtable for qdiscs.
For singleton qdiscs, there is
is correct handling of singletons. I've been
completely off the grid for the past three days, but I plan to submit this
as a proper followup fix tomorrow if noone has any objections.
> I will try to work on a patch tomorrow.
What still needs to be looked into are the duplicate clsact entries for
multiqueue.
Thanks,
--
Jiri Kosina
SUSE Labs
isc pfifo_fast 0: parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Hmm, no immediate idea where those are coming from, we'll have to figure
it out. The mq device used here has 4 queues, right?
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
There are a couple of leftover symbol conflicts caused by hashtable.h
being included by netdevice.h; those were not caught as build failure
(they're "only" a warning, but in fact real bugs). Fix those up.
Fixes: e87a8f24c ("net: resolve symbol co
@@ static struct Qdisc *qdisc_match_from_root(struct Qdisc
*root, u32 handle)
{
struct Qdisc *q;
+ if (!qdisc_dev(root))
+ return (root->handle == handle ? root : NULL);
+
if (!(root->flags & TCQ_F_BUILTIN) &&
root->handle == handle)
return root;
Thanks!
--
Jiri Kosina
SUSE Labs
#x27;s Reviewed-by:, as code-wise this series is identical
to the original v6 of the patch.
[1] lkml.kernel.org/r/alpine.lnx.2.00.1608011220580.22...@cbobk.fhfr.pm
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
Convert the per-device linked list into a hashtable. The primary
motivation for this change is that currently, we're not tracking all the
qdiscs in hierarchy (e.g. excluding default qdiscs), as the lookup
performed over the linked list by qdisc_match_from_root() is r
From: Jiri Kosina
This is a preparatory patch for converting qdisc linked list into a
hashtable. As we'll need to include hashtable.h in netdevice.h, we first
have to make sure that this will not introduce symbol conflicts for any of
the netdevice.h users.
Reviewed-by: Cong Wang
Signe
w-stopper for the qdisc hash
conversion, given the fact that the whole tree is building properly?
> Thank you.
Thanks,
--
Jiri Kosina
SUSE Labs
(i.e. the
code in question doesn't indirectly pull in netdevice.h)?
I just did allmodconfig build with v6, and it passed. Fengguang's 0-day
bot didn't report any failures either.
> Then we can add the qdisc hash facility.
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
Convert the per-device linked list into a hashtable. The primary
motivation for this change is that currently, we're not tracking all the
qdiscs in hierarchy (e.g. excluding default qdiscs), as the lookup
performed over the linked list by qdisc_match_from_root() is r
afterwards. This is fixed in v5 of
the patch.
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
Convert the per-device linked list into a hashtable. The primary
motivation for this change is that currently, we're not tracking all the
qdiscs in hierarchy (e.g. excluding default qdiscs), as the lookup
performed over the linked list by qdisc_match_from_root() is r
rove the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Jiri-Kosina/net-sched-convert-qdisc-linked-list-to-hashtable/20160728-182303
> config: i386-randconfig-s0-201630 (attached as .config)
> compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
>
From: Jiri Kosina
Convert the per-device linked list into a hashtable. The primary
motivation for this change is that currently, we're not tracking all the
qdiscs in hierarchy (e.g. excluding default qdiscs), as the lookup
performed over the linked list by qdisc_match_from_root() is r
;
> url:
> https://github.com/0day-ci/linux/commits/Jiri-Kosina/net-sched-convert-qdisc-linked-list-to-hashtable/20160711-220527
> config: arm-tct_hammer_defconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 5.3.1-8) 5.3.1 20160205
> reproduce:
> wget
>
be surrounded by CONFIG_NET_SCHED?
> To save several bytes for !CONFIG_NET_SCHED case.
Makes sense. I'll wait a bit for more feedback (if there is any) before
including this in potential v4.
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
Convert the per-device linked list into a hashtable. The primary
motivation for this change is that currently, we're not tracking all the
qdiscs in hierarchy (e.g. excluding default qdiscs), as the lookup
performed over the linked list by qdisc_match_from_root() is r
ning to struct net_device's Qdisc pointer is
enough to "initialize" the linked list and have it contain one (root)
item. With hashtable, this is not the case, it needs to be explicitly
added.
Hmm, dev_init_scheduler() (and perhaps also dev_shutdown()) would possibly
need similar treatment in order to have accurate data there 100% of the
time even during initialization.
--
Jiri Kosina
SUSE Labs
e; however the primary goal here is not to actually ultimately
improve speed of qdisc lookup per se, but rather to make it possible to
unhide the qdiscs which are currently omitted as the linked list takes too
long to walk. The static hashtable is going help here.
Thanks,
--
Jiri Kosina
SUSE Labs
From: Jiri Kosina
Convert the per-device linked list into a hashtable. The primary
motivation for this change is that currently, we're not tracking all the
qdiscs in hierarchy (e.g. excluding default qdiscs), as the lookup
performed over the linked list by qdisc_match_from_root() is r
v2 of the patch (there is also a conflict on HASH_SIZE
definition in ip6_tunnel.c, ip6_gre.c and sit.c due to hashtable.h include
in netdevice.h that needs to be resolved as well) that'd make RCU usage
consistent.
Any other objections/comments? I was namely curious about any opinions
regarding the hashtable size.
Thanks,
--
Jiri Kosina
SUSE Labs
of qdiscs.
So how about something like the patch below? I already have preliminary
patches on top which unhide the default qdiscs, but let's make this one
step after the other.
Thanks.
From: Jiri Kosina
Subject: [PATCH] net: sched: convert qdisc linked list to hashtable
Convert the pe
we may break some existing script if we change that.
While I do understand that reasoning, I'd argue that unpredictable and
unexpected behavior of TBF causing systems with non-working networking is
much more likely than any userspace having hard dependency on the fact
that default (*) qdisc
like to bring the patch below up for consideration.
Thanks.
From: Jiri Kosina
Subject: [PATCH] sch_tbf: avoid silent fallback to noop_qdisc
TBF started its life as a classless qdisc with a single builtin FIFO queue
which was being shaped.
When it got later turned into classful qdisc, it was wr
Whenever an interface is created, the pfifo_fast qdisc is
automatically used as a queue. If another qdisc is
attached, it preempts the default pfifo_fast, which automatically
returns to function when an existing qdisc is detached.
In this sense this q
HFSC, HTB, QFQ) assign the default
> one upon deletion instead of noop_qdisc, hence I would describe
> the situation using the words 'inconsistent' and 'accident' rather than
> 'expected'. :)
Would a patch that'd unify this in a sense that all qdiscs would assign
the default one upon deletion acceptable?
Thanks,
--
Jiri Kosina
SUSE Labs
disc show
qdisc tbf 10: dev eth0 root refcnt 2 rate 800Mbit burst 131000b lat
1.0ms
It's hard to spot a difference (hint: there is none).
Thanks,
--
Jiri Kosina
SUSE Labs
On Thu, 14 Apr 2016, Jiri Kosina wrote:
> In a nutshell, is this expected behavior or bug?
Just to clarify what seems to suggest to me that this is rather a bug that
needs to be fixed (but apparently one that has been there for quite a long
time) can be demonstrated by t
ING nix.cz (195.47.235.3) 56(84) bytes of data.
[ ... nothing happens ... ]
^C
jikos:~ # tc qdisc add dev eth0 parent 10:1 sfq
jikos:~ # ping -c 1 nix.cz | head -2
PING nix.cz (195.47.235.3) 56(84) bytes of data.
64 bytes from info.nix.cz (195.47.235.3): icmp_seq=1 ttl=89 time=1.66 ms
=
Thanks,
either have both (i.e accept this
patchset) or have neither of them (i.e. drop list_is_last()).
Otherwise people are likely to be confused by such an asymetric API and
will keep posting patches for it over and over again.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the l
ock.
But I am not able to see anything like that in the code. Dave, do you have
any idea? (the thread started at http://lkml.org/lkml/2008/2/22/105).
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 22 Feb 2008, Anders Eriksson wrote:
> > This needs to be CCed to netdev.
> > Any chance that
> > git revert 69cc64d8d92
> > makes this report go away?
> I'll have to install a git repo to check, or maybe you can send me the diff
> to
> reverse vs. 2.6.25-rc2?
diff --git a/net/core/
ippex [] do_IRQ+0x47/0x80
> Feb 21 20:46:33 tippex [] common_interrupt+0x23/0x28
> Feb 21 20:46:33 tippex ===
This needs to be CCed to netdev.
Any chance that
git revert 69cc64d8d92
makes this report go away?
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send t
This reverts commit 45b503548210fe6f23e92b856421c2a3f05fd034.
It contains deadlock, and breaks userspace applications (wpa_supplicant,
networkmanager). References:
http://bugzilla.kernel.org/show_bug.cgi?id=10002
http://bugzilla.kernel.org/show_bug.cgi?id=10002
---
net/core/rtnetlink.c | 36 ++
.23.1
> > Looks like this is a regression
> No response from developers
Hi,
it is assigned to '[EMAIL PROTECTED]', so I didn't
notice, it's as simple as that.
--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
th
ble to handle kernel NULL pointer dereference at virtual address
> 0004
> printing eip: c0383fa0 *pde =
> Oops: [#1]
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00010282 (2.6.23-g4fa4d23f #4)
> EIP is at sk_filter_delayed_uncharge+0x0/0x20
> eax: c5dfb600 ebx: ecx: edx:
> esi: c5dfb600 edi: ebp: c170d300 esp: c5dcbef8
> ds: 007b es: 007b fs: gs: 0033 ss: 0068
> Process dhcpd (pid: 5380, ti=c5dca000 task=c47f0520 task.ti=c5dca000)
> Stack: c038410f 0068 0058 c5dcbf34 b7fd000b c1b75000 c5dfb600
> c0371d19
>c1b70fd8 c180d300 c1b70f80 0007 0001 b7fd000b c170d900
> b7fd000b
>080c9fa0 000e c5dcbf6c c036dbc2 000e c1b75000
> 0008
> Call Trace:
> [] sk_attach_filter+0xdf/0x100
> [] sock_setsockopt+0x509/0x590
> [] sockfd_lookup_light+0x32/0x60
> [] sys_setsockopt+0x9b/0xb0
> [] sys_socketcall+0xd5/0x280
> [] sysenter_past_esp+0x5f/0x85
> ===
> Code: cb 04 76 c7 83 c1 01 83 ee 01 39 d1 75 8d eb d7 83 7c cb 04 0f 77 b4 83
> c1 01 83 ee 01 39 d1 0f 85 76 ff ff ff eb c0 8d 74 26 00 <8b> 4a 04 8d 0c cd
> 10 00 00 00 29 48 5c 8d 42 08 ba 10 40 38 c0
> EIP: [] sk_filter_delayed_uncharge+0x0/0x20 SS:ESP 0068:c5dcbef8
>
>
>
--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
the very
same mouse and network card in a different machine, etc.
Otherwise I am afraid this is going to be just a totally wild guessing.
Thanks,
--
Jiri Kosina
From: Jiri Kosina <[EMAIL PROTECTED]>
[PATCH] IPV6: fix source address selection
The commit 95c385 broke proper source address selection for cases in which
there is a address which is makred 'deprecated'. The commit mistakenly
changed ifa->flags to ifa_result->flags (pro
it's not possible to nuke it at once in an usual
way.
--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
27;ing the interfaces fixes things, temporarily.
>
> Reverting to 2.6.22, everything seems to be running fine (but no lguest,
> which is what I came for :( )
>
> I've also tried with the latest code from git, the behaviour is the same
> as 2.6.23-rc2.
This needs to go to
o cause a new entry in regressions list, as at
least Chris Stromsoe has reported bonding-related problems with skge that
don't happen with sklin -
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0707.1/1158.html
--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsu
On Wed, 16 May 2007, David Miller wrote:
> > I have just verified that this locking scheme is indeed correct. So you
> > can add
> >
> > Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
> >
> > if you wish to, and submit the patch to Andrew.
> I
On Wed, 16 May 2007, Jiri Kosina wrote:
> > since Jiri has a good test case for it, I leave it to him for testing.
> > If he confirms that this fixes the locking issues, then this is
> > Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]>
> I will verify later this eveni
you know. I am however
pretty convinced now that this is the right fix.
Thanks,
--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
to be proper solution also for our case, thanks for
pointing this out. I will think about it once again, do some more tests
with this locking scheme, and will let you know.
Thanks,
--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body o
3 quirk present in usb hid
(extra control URB is required to make it operational), probably something
similar will be needed for BT version too.
> > From: Jiri Kosina <[EMAIL PROTECTED]>
> > [Bluetooth] HIDP - don't initialize force feedback
> > The current imple
are you aware of any devices currently supported by USB HID
force-feedback code, which have a bluetooth version, please?
I'd propose the patch below, until I make the usbhid force-feedback code
transport independent. Thanks.
From: Jiri Kosina <[EMAIL PROTECTED]>
[Bluetooth] HIDP
27;t "unprivileged app sending packet through raw socket" an oxymoron? As
Patrick pointed out, the message is there for a reason, I'd suggest using
printk_ratelimit() in this case.
--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
alling hid_ff_init() is
presently not enough anyway, as the force feedback drivers for HID devices
are currently USB-transport specific.
--
Jiri Kosina
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
(as it was racy with
l2cap_connect_cfm()).
> Does this need to occur immediately when an event occurs? If not I'd
> suggest moving this into a workqueue.
Will have to check whether this will be processed properly in time when
going to suspend.
Thanks,
--
Jiri Kosina
-
To unsubs
ave confirmed that the bug is reproducible on *any*
> laptop with 8168, not only Asus. I guess the disk-usage-crash was some
> other bug.
Confusing ... the other day you stated that r1000 has the exactly same
problem?
Thanks,
--
Jiri Kosina
SUSE Labs
-
To unsubscribe from this list:
Russell King).
This I believe is the correct one for the sk98lin case.
[PATCH] fix sk98lin driver, ignoring return value from pci_enable_device()
add check of return value to _resume() function of sk98lin driver.
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
---
drivers/net/sk98lin/skge.c
his case, as it can easily
happen.
> > > Why put condtional on same line?
> > Pardon me?
> I prefer:
> ret = pci_enable_device(pdev);
As you wish.
[PATCH] fix sk98lin driver, ignoring return value from pci_enable_device()
add check of return value to _resume() functio
rom pci_enable_device()
add check of return value to _resume() function of sk98lin driver.
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
---
drivers/net/sk98lin/skge.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sk98lin/skge.c b/drivers/net/sk
[PATCH] sk98lin: handle pci_enable_device() return value in skge_resume()
properly
Fix missing handling of pci_enable_device() return value in skge_resume()
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
---
drivers/net/sk98lin/skge.c |6 +-
1 files changed, 5 insertions
89 matches
Mail list logo
