Re: UltraSPARC T3 kernel patches
On Sun, Aug 14, 2011 at 07:23:28PM +0100, Jurij Smakov wrote: Thanks. I've built a test source package including all necessary patches and a test build is running now. Ben tells me, however, that 3.0.2 which includes all these patches and fixes is expected to come out on Monday, and will be uploaded to unstable shortly after that, so I don't think it makes sense to commit them as a separate patch set anymore. It took a while, but the daily installer images [0] now include a kernel which should support Niagara T3. David, if you could try it out and report your findings, it would be greatly appreciated. I would like to use this opportunity to thank Ben and the rest of the kernel team for their efforts on making installer udebs built directly from Debian kernel package source. That means that in the future new kernels will be available in the daily installer builds pretty much immediately after the new Debian kernel package is uploaded. [0] http://www.debian.org/devel/debian-installer/ Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012103904.ga13...@wooyd.org
Bug#648477: ath9k wireless: frequent connection drops (TKIP MIC failure)
On 11/11/11 23:26, Jonathan Nieder wrote: Hi Christoph, Christoph Wiedemann wrote: I observe frequent (1 per minute) connection drops with a new SONY VAIO notebook. [...] 02:00.0 Network controller [0280]: Atheros Communications Inc. AR9485 Wireless Network Adapter [168c:0032] (rev 01) Disabling hwcrypt as suggested in http://www.mail-archive.com/ath9k- de...@lists.ath9k.org/msg04221.html seems to fix the problem Thanks. There have been some AR9485 fixes upstream recently. Could you test v3.1 from experimental? If that fails, please report it upstream to ath9k-de...@lists.ath9k.org, cc-ing linux-wirel...@vger.kernel.org and either me or this bug log so we can track it. Hi Jonathan, linux-image-3.1.0-1-amd64 indeed seems to fix the problem. I tested for half an hour now without any connection drop issues. Thanks and sorry for bothering you... Best Regards Christoph -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ebe565a.3060...@gmx.net
Bug#648477: ath9k wireless: frequent connection drops (TKIP MIC failure)
Christoph Wiedemann wrote: Tried it, but it looks like 2.6.32-39 doesn't recognize the chip Thanks. I should have remembered; sorry to waste your time. (So I don't forget: commits squeeze is missing include - v2.6.38-rc1~476^2~169^2^2~53 (ath9k_hw: Define hw version macros for AR9485, 2010-12-06) .. v2.6.38-rc1~476^2~169^2^2~28 (ath9k: Add device id of AR9485 to pci table, 2010-12-06) - [v2.6.38-rc1~476^2~169^2^2~22 (ath9k_htc: Fix panic on FW download failure, 2010-12-07) doesn't seem to be related but should probably also go in the stable tree] - v2.6.38-rc1~476^2~14^2~3^2~62 (ath9k_hw: Fix bug in eeprom data length validation for AR9485, 2010-12-21) - v2.6.39-rc1~468^2~417^2~42 (ath9k: Fix a PLL hang issue observed with AR9485, 2011-01-27) .. v2.6.39-rc1~468^2~417^2~39 (ath9k_hw: Update PMU setting to improve ripple issue for AR9485, 2011-01-27) - v2.6.39-rc1~468^2~25^2^2~170 (ath9k_hw: Updates for AR9485 1.1 chipsets, 2011-02-18) [wow, is the commit message unhelpful] and some other commits from the same merge ... and so on. Grepping for AR9485 and for ath9k_hw should hopefully find everything.) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2012122101.ga29...@elie.hsd1.il.comcast.net
[PATCH] ia64: Add accept4() syscall
From: Émeric Maschino emeric.masch...@gmail.com
Subject: ia64: Add accept4() syscall
While debugging udev 170 failure on Debian Wheezy
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648325), it appears
that the issue was in fact due to missing accept4() in ia64.
This patch simply adds accept4() to ia64. The
arch/ia64/include/asm/unistd.h and arch/ia64/kernel/entry.S diffs
apply cleanly against 3.2-rc1.
Patch has been successfully tested running an ia64-targeted version of
test_accept4.c (modified from x86/x86_64-centric original version from
http://git.kernel.org/linus/de11defebf7677fb7ee91d9b089b78786fbb):
/* test_accept4.c
Copyright (C) 2008, Linux Foundation, written by Michael Kerrisk
mtk.manpa...@gmail.com
Licensed under the GNU GPLv2 or later.
*/
#define _GNU_SOURCE
#include unistd.h
#include sys/syscall.h
#include sys/socket.h
#include netinet/in.h
#include stdlib.h
#include fcntl.h
#include stdio.h
#include string.h
#define PORT_NUM 3
#define die(msg) do { perror(msg); exit(EXIT_FAILURE); } while (0)
/**/
/* The following is what we need until glibc gets a wrapper for
accept4() */
/* Flags for socket(), socketpair(), accept4() */
#ifndef SOCK_CLOEXEC
#define SOCK_CLOEXECO_CLOEXEC
#endif
#ifndef SOCK_NONBLOCK
#define SOCK_NONBLOCK O_NONBLOCK
#endif
#define __NR_accept4 1334
static int
__accept4(int fd, struct sockaddr *sockaddr, socklen_t *addrlen, int flags)
{
printf(Calling accept4(): flags = %x, flags);
if (flags != 0) {
printf( ();
if (flags SOCK_CLOEXEC)
printf(SOCK_CLOEXEC);
if ((flags SOCK_CLOEXEC) (flags SOCK_NONBLOCK))
printf( );
if (flags SOCK_NONBLOCK)
printf(SOCK_NONBLOCK);
printf());
}
printf(\n);
return syscall(__NR_accept4, fd, sockaddr, addrlen, flags);
}
/**/
static int
do_test(int lfd, struct sockaddr_in *conn_addr,
int closeonexec_flag, int nonblock_flag)
{
int connfd, acceptfd;
int fdf, flf, fdf_pass, flf_pass;
struct sockaddr_in claddr;
socklen_t addrlen;
printf(===\n);
connfd = socket(AF_INET, SOCK_STREAM, 0);
if (connfd == -1)
die(socket);
if (connect(connfd, (struct sockaddr *) conn_addr,
sizeof(struct sockaddr_in)) == -1)
die(connect);
addrlen = sizeof(struct sockaddr_in);
acceptfd = __accept4(lfd, (struct sockaddr *) claddr, addrlen,
closeonexec_flag | nonblock_flag);
if (acceptfd == -1) {
perror(accept4());
close(connfd);
return 0;
}
fdf = fcntl(acceptfd, F_GETFD);
if (fdf == -1)
die(fcntl:F_GETFD);
fdf_pass = ((fdf FD_CLOEXEC) != 0) ==
((closeonexec_flag SOCK_CLOEXEC) != 0);
printf(Close-on-exec flag is %sset (%s); ,
(fdf FD_CLOEXEC) ? : not ,
fdf_pass ? OK : failed);
flf = fcntl(acceptfd, F_GETFL);
if (flf == -1)
die(fcntl:F_GETFD);
flf_pass = ((flf O_NONBLOCK) != 0) ==
((nonblock_flag SOCK_NONBLOCK) !=0);
printf(nonblock flag is %sset (%s)\n,
(flf O_NONBLOCK) ? : not ,
flf_pass ? OK : failed);
close(acceptfd);
close(connfd);
printf(Test result: %s\n, (fdf_pass flf_pass) ? PASS : FAIL);
return fdf_pass flf_pass;
}
static int
create_listening_socket(int port_num)
{
struct sockaddr_in svaddr;
int lfd;
int optval;
memset(svaddr, 0, sizeof(struct sockaddr_in));
svaddr.sin_family = AF_INET;
svaddr.sin_addr.s_addr = htonl(INADDR_ANY);
svaddr.sin_port = htons(port_num);
lfd = socket(AF_INET, SOCK_STREAM, 0);
if (lfd == -1)
die(socket);
optval = 1;
if (setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, optval,
sizeof(optval)) == -1)
die(setsockopt);
if (bind(lfd, (struct sockaddr *) svaddr,
sizeof(struct sockaddr_in)) == -1)
die(bind);
if (listen(lfd, 5) == -1)
die(listen);
return lfd;
}
int
main(int argc, char *argv[])
{
struct sockaddr_in conn_addr;
int lfd;
int port_num;
int passed;
passed = 1;
port_num = (argc 1) ? atoi(argv[1]) : PORT_NUM;
memset(conn_addr, 0, sizeof(struct sockaddr_in));
conn_addr.sin_family = AF_INET;
conn_addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
conn_addr.sin_port = htons(port_num);
lfd = create_listening_socket(port_num);
if (!do_test(lfd, conn_addr, 0, 0))
passed = 0;
if (!do_test(lfd, conn_addr, SOCK_CLOEXEC, 0))
passed = 0;
if (!do_test(lfd, conn_addr, 0, SOCK_NONBLOCK))
passed = 0;
if (!do_test(lfd, conn_addr, SOCK_CLOEXEC, SOCK_NONBLOCK))
passed = 0;
close(lfd);
exit(passed ? EXIT_SUCCESS : EXIT_FAILURE);
}
Signed-off-by: Émeric Maschino emeric.masch...@gmail.com
---
diff -uprN -X
