orrupted packets.
If I'd paid attention to the encryption options when setting up this network
originally, I would have had CCMP the whole time, with no corrupted packets,
and never would have found the iov iterator bug...
--
Alan Curry
}
if (unlikely(skb->ip_summed == CHECKSUM_COMPLETE))
netdev_rx_csum_fault(skb->dev);
}
--
Alan Curry
ct sk_buff *skb,
> if (!chunk)
> return 0;
>
> - if (msg_data_left(msg) < chunk) {
> + if (iov_iter_single_seg_count(&msg->msg_iter) < chunk) {
> if (__skb_checksum_complete(skb))
> goto csum_error;
> if (skb_copy_datagram_msg(skb, hlen, msg, chunk))
>
--
Alan Curry
K
* Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
WMM: * Parameter version 1
* u-APSD
* BE: CW 15-1023, AIFSN 3
* BK: CW 15-1023, AIFSN 7
* VI: CW 7-15, AIFSN 2, TXOP 3008 usec
* VO: CW 3-7, AIFSN 2, TXOP 1504 usec
--
Alan Curry
; 0) {
perror("read from socket");
return 1;
}
copied = 0;
while(copied < r) {
w = write(1, buf+copied, r-copied);
if(w < 0) {
perror("write to stdout");
return 1;
}
copied += w;
}
if(doselect) {
fd_set rfds;
FD_ZERO(&rfds);
FD_SET(sock, &rfds);
select(sock+1, &rfds, 0, 0, 0);
}
}
return 0;
}
--
Alan Curry
n /lib/firmware
> Just one additional question: Is the TL-WN821N connected to a USB3 port?
It never has been before. I tried it today and it made no difference.
--
Alan Curry
[1.] One line summary of the problem:
network data corruption (bisected to e5a4b0bb803b)
[2.] Full description of the problem/report:
Note: although my bisect ended at a commit from before 3.19, I have the
same symptom in all newer kernels I've tried, up to 4.6.4.
The commit was:
>commit e5a4b0b
0 00 00 00 <48> 8b 80 28 03 00 00
48 85 c0 74 0e 8b 90 d0 04 00 00 66 85 d2
RIP [] bd_set_size+0x7/0x5e
RSP
CR2: 0328
---[ end trace 149557d36d01641b ]---
--
Alan Curry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
I'm almost sorry I spoke up...
Matt Sealey writes the following:
>
>Okay before you add to the nvramrc you also need to add probe-all to build the
>device tree first; I assumed this was common knowledge.
Maybe for experienced OpenFirmware developers; this is the first time I've
had to touch the s
encing
an annoying keyboardless boot) and fix it himself. Is that worth the
reduction in kernel clutter?
--
Alan Curry
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
workarounds will function independently of each other.
The first 8042-detection fix was:
db0dbae9d9680bce69fe1ce775709e60c8ee9c29
And mine is:
f5d834fc34e61f1a40435981062000e5d2b2baa8
--
Alan Curry
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
o, it doesn't have one of
those.
For the amusement of all, I offer the entire device-tree as presented in
/proc by my running 2.6.22.1 kernel. Available for a limited time from
http://world.std.com/~pacman/pegasosII_proc_device-tree.tar.gz
--
Alan Curry
[EMAIL PROTECTED]
-
To unsubscribe
dds a secondary detection
which looks for a device whose *name* is "8042" if there is no device whose
*type* is "8042".
Signed-off-by: Alan Curry <[EMAIL PROTECTED]>
--- arch/powerpc/kernel/setup-common.c.orig 2007-07-24 19:04:17.0
-0500
+++ arch/powerpc/k
When I boot 2.6.22.1 on my PegasosPPC, the PS/2 keyboard is not detected. It
works in 2.6.21.5. Both kernels have:
CONFIG_KEYBOARD_ATKBD=y
CONFIG_SERIO_I8042=y
The 2.6.21.5 kernel logs this stuff during boot:
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
1) uses O_NONBLOCK to avoid getting
stuck if a user has paused a tty with ^S, but the kernel doesn't respect the
flag and wall gets stuck anyway. When the user finally hits ^Q -- hours,
days, or weeks later -- he gets the message and so does everyone who was
after him in utmp.)
--
Alan Cu
Dave Jones writes the following:
>
>On Mon, Apr 18, 2005 at 08:46:52PM +0200, Lorenzo Hernández García-Hierro
>wrote:
> > This patch changes the permissions of the following procfs entries to
> > restrict non-root users from accessing them:
[snip]
> > - /proc/uptime
?!
[snip]
Andries Brouwer writes the following:
>
>> "Alan Curry" <[EMAIL PROTECTED]> wrote:
>>> An SVGATextMode
>>> block cursor isn't affected by ^[c -- it truly *becomes* the default
>
>True - it is obtained by hardware reprogramming. But havin
Gene Heskett writes the following:
>
>I'm on the horn with another linux user, and we have a question re the
>setserial command. Its reporting the base baud rate, but not the
>actual. We need to know the actual settings in use at the moment for
>a serial port. How can we discover this?
stty s
cranium2003 writes the following:
>
>when i strace cat /proc/my_file i found message
>printing twice
>Reading a from a /proc file
>Reading a from a /proc file
> Why that happening?
The first read returns some data and returns the number of bytes, and the
second one indicates that EOF
I wrote:
>
>Was SVGATextMode's cursor-setting ability removed as a result of an
>intentional change, or might it get fixed? Or might CUR_DEFAULT become
>tunable? Maybe another control sequence could make the current cursor
>settings the default, like setterm -store does for foreground and backgroun
With 2.6.11, I can no longer change the cursor with SVGATextMode. Previously,
a block cursor could be selected by
echo Cursor 0-31 >> /etc/TextConfig ; SVGATextMode
and the cursor would be a block. On all consoles. Forever.
To accomplish the same thing using the softcursor escape sequences, I mu
Linus Torvalds writes the following:
>
>Does the problem go away if you change the default value of "chunk" (in
>drivers/char/tty_io.c:do_tty_write) from 4096 to 2048? If so, that means
>that the pty code has _claimed_ to have written 4kB, and only ever wrote
>4kB-1 bytes. That in turn implies t
Usually, when I try to connect to a port with nothing listening on it, it
looks like this:
17:11:20.809712 eth0 > MYHOST.2514 > OTHERHOST.auth: S 2807001202:2807001202(0) win
32120 (DF)
17:11:20.819712 eth0 < OTHERHOST.auth > MYHOST.2514: R 0:0(0) ack 2807001203 win 0
MYHOST is my Linux box. T
23 matches
Mail list logo
