than Dec 28th 2015, use previous patch!
Signed-off-by: Piotr Sawuk
---
add support for mad catz r.a.t.5
add a file in sysfs called "mode" exposing the integer of that name.
diff -rup linux-4.2.6-gentoo/drivers/hid/hid-core.c
linux-4.2.6-gentoo-rat5/drivers/hid/hid-core.c
--- linux-4.
On Di, 26.01.2016, 15:29, Jiri Kosina wrote:
> On Sat, 9 Jan 2016, Piotr Sawuk wrote:
>
>> Signed-off-by: Piotr Sawuk
>
> The patch has been damaged by your mail client, and as such can't be
> applied. Could you please fix that up and resend?
thanks, I fixed that by an
On Di, 26.01.2016, 15:29, Jiri Kosina wrote:
> On Sat, 9 Jan 2016, Piotr Sawuk wrote:
>
>> Signed-off-by: Piotr Sawuk <pio...@users.sf.net>
>
> The patch has been damaged by your mail client, and as such can't be
> applied. Could you please fix that up a
than Dec 28th 2015, use previous patch!
Signed-off-by: Piotr Sawuk <pio...@users.sf.net>
---
add support for mad catz r.a.t.5
add a file in sysfs called "mode" exposing the integer of that name.
diff -rup linux-4.2.6-gentoo/drivers/hid/hid-core.c
linux-4.2.6-gentoo-rat5/driver
I repeat my question:
the driver for lsm303dlh in the 3.5 kernel calls regulator_get(>dev,
"vdd");
from that it got the return-value fdfb triggering IS_ERR().
but I cannot find any errorcode for -0x205.
does anyone know the meaning of this error-code?
P
--
To unsubscribe from this list: send
I repeat my question:
the driver for lsm303dlh in the 3.5 kernel calls regulator_get(client-dev,
vdd);
from that it got the return-value fdfb triggering IS_ERR().
but I cannot find any errorcode for -0x205.
does anyone know the meaning of this error-code?
P
--
To unsubscribe from this list:
I have a gpl driver for lsm202dlh which worked with 2.6 kernels. now in 3.5
I can modprobe it (after some include-changes), but after the echo command
to new_device dmesg tells me
[ 1147.549042] lsm303dlh_a 6-0019: failed to get regulator
[ 1147.549055] lsm303dlh_a 6-0019: probe function fails
I have a gpl driver for lsm202dlh which worked with 2.6 kernels. now in 3.5
I can modprobe it (after some include-changes), but after the echo command
to new_device dmesg tells me
[ 1147.549042] lsm303dlh_a 6-0019: failed to get regulator
[ 1147.549055] lsm303dlh_a 6-0019: probe function fails
On Fr, 20.07.2012, 16:06, Yuchung Cheng wrote:
> On Mon, Jul 16, 2012 at 6:03 AM, Piotr Sawuk
> wrote:
>> On Mo, 16.07.2012, 13:46, Eric Dumazet wrote:
>>> On Mon, 2012-07-16 at 13:33 +0200, Piotr Sawuk wrote:
>>>> On Sa, 14.07.2012, 01:55, Stephen Hemm
On Fr, 20.07.2012, 16:06, Yuchung Cheng wrote:
On Mon, Jul 16, 2012 at 6:03 AM, Piotr Sawuk a9702...@unet.univie.ac.at
wrote:
On Mo, 16.07.2012, 13:46, Eric Dumazet wrote:
On Mon, 2012-07-16 at 13:33 +0200, Piotr Sawuk wrote:
On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
I am not sure
On Mo, 16.07.2012, 17:24, Christoph Paasch wrote:
> You should do jiffies_to_msecs(tp->srtt) >> 3.
>
> The RTT is already exposed by tcp_info anyway... (see tcp_get_info() - where
> you also see the bitshift)
thanks a lot. rtt is output for completion's sake, it helps in diagnosis.
here my
On Mo, 16.07.2012, 17:24, Christoph Paasch wrote:
You should do jiffies_to_msecs(tp-srtt) 3.
The RTT is already exposed by tcp_info anyway... (see tcp_get_info() - where
you also see the bitshift)
thanks a lot. rtt is output for completion's sake, it helps in diagnosis.
here my hopefully
On Mo, 16.07.2012, 15:32, Ben Hutchings wrote:
> On Sat, 2012-07-14 at 09:56 +0200, Piotr Sawuk wrote:
>> On Sa, 14.07.2012, 03:31, valdis.kletni...@vt.edu wrote:
>> > On Fri, 13 Jul 2012 16:55:44 -0700, Stephen Hemminger said:
>> >
>> >> >+
On Mo, 16.07.2012, 13:46, Eric Dumazet wrote:
> On Mon, 2012-07-16 at 13:33 +0200, Piotr Sawuk wrote:
>> On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
>> > I am not sure if the is really necessary since the most
>> > of the stats are available elsewhere.
>>
On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
> I am not sure if the is really necessary since the most
> of the stats are available elsewhere.
if by "most" you mean address and port then you're right.
but even the rtt reported by "ss -i" seems to differ from tcphealth.
however, if instead
On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
I am not sure if the is really necessary since the most
of the stats are available elsewhere.
if by most you mean address and port then you're right.
but even the rtt reported by ss -i seems to differ from tcphealth.
however, if instead by
On Mo, 16.07.2012, 13:46, Eric Dumazet wrote:
On Mon, 2012-07-16 at 13:33 +0200, Piotr Sawuk wrote:
On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
I am not sure if the is really necessary since the most
of the stats are available elsewhere.
if by most you mean address and port
On Mo, 16.07.2012, 15:32, Ben Hutchings wrote:
On Sat, 2012-07-14 at 09:56 +0200, Piotr Sawuk wrote:
On Sa, 14.07.2012, 03:31, valdis.kletni...@vt.edu wrote:
On Fri, 13 Jul 2012 16:55:44 -0700, Stephen Hemminger said:
+/* Course retransmit inefficiency- this packet
On So, 15.07.2012, 11:53, Eric Dumazet wrote:
> On Sun, 2012-07-15 at 11:17 +0200, Piotr Sawuk wrote:
>> On So, 15.07.2012, 09:16, Eric Dumazet wrote:
>> > On Sun, 2012-07-15 at 01:43 +0200, Piotr Sawuk wrote:
>> >
>> >> oh, and again I recommend th
On So, 15.07.2012, 09:16, Eric Dumazet wrote:
> On Sun, 2012-07-15 at 01:43 +0200, Piotr Sawuk wrote:
>
>> oh, and again I recommend the really short although outdated thesis
>>
>> [1] https://sacerdoti.org/tcphealth/tcphealth-paper.pdf
>
> A thesis saying SACK ar
On So, 15.07.2012, 09:16, Eric Dumazet wrote:
On Sun, 2012-07-15 at 01:43 +0200, Piotr Sawuk wrote:
oh, and again I recommend the really short although outdated thesis
[1] https://sacerdoti.org/tcphealth/tcphealth-paper.pdf
A thesis saying SACK are not useful is highly suspect.
Instead
On So, 15.07.2012, 11:53, Eric Dumazet wrote:
On Sun, 2012-07-15 at 11:17 +0200, Piotr Sawuk wrote:
On So, 15.07.2012, 09:16, Eric Dumazet wrote:
On Sun, 2012-07-15 at 01:43 +0200, Piotr Sawuk wrote:
oh, and again I recommend the really short although outdated thesis
[1] https
On Sa, 14.07.2012, 23:48, Stephen Hemminger wrote:
> Maybe it would be better to use netlink info (for ss command)
> rather than a /proc/net interface.
> See how existing TCP values and MEMINFO are handled.
>
I'm confused, what exactly do you mean?
of course a library-interface might be more
On Sa, 14.07.2012, 03:31, valdis.kletni...@vt.edu wrote:
> On Fri, 13 Jul 2012 16:55:44 -0700, Stephen Hemminger said:
>
>> >+ /* Course retransmit inefficiency- this packet has been
>> >received
>> twice. */
>> >+ tp->dup_pkts_recv++;
>> I don't understand
On Sa, 14.07.2012, 03:31, valdis.kletni...@vt.edu wrote:
On Fri, 13 Jul 2012 16:55:44 -0700, Stephen Hemminger said:
+ /* Course retransmit inefficiency- this packet has been
received
twice. */
+ tp-dup_pkts_recv++;
I don't understand that comment, could
On Sa, 14.07.2012, 23:48, Stephen Hemminger wrote:
Maybe it would be better to use netlink info (for ss command)
rather than a /proc/net interface.
See how existing TCP values and MEMINFO are handled.
I'm confused, what exactly do you mean?
of course a library-interface might be more
On Do, 12.07.2012, 23:35, Stephen Hemminger wrote:
> On Thu, 12 Jul 2012 22:55:57 +0200
> "Piotr Sawuk" wrote:
>
>> + * Federico D. Sacerdoti: Added TCP health monitoring.
>
> Please don't do this.
> The kernel community no longer maintains a list
On Do, 12.07.2012, 23:35, Stephen Hemminger wrote:
On Thu, 12 Jul 2012 22:55:57 +0200
Piotr Sawuk a9702...@unet.univie.ac.at wrote:
+ * Federico D. Sacerdoti: Added TCP health monitoring.
Please don't do this.
The kernel community no longer maintains a list of contributors
hello! I haven't done any kernel-hacking before, so be patient.
I got as far as to make tcphealth run, but now I need some help:
how does read-locking work in the tcp_sock struct?
the original code (for 2.5.1) made a read_lock(>lock) with
struct tcp_ehash_bucket *head = _ehash[i];
at the
hello! I haven't done any kernel-hacking before, so be patient.
I got as far as to make tcphealth run, but now I need some help:
how does read-locking work in the tcp_sock struct?
the original code (for 2.5.1) made a read_lock(head-lock) with
struct tcp_ehash_bucket *head = tcp_ehash[i];
at the
30 matches
Mail list logo
