Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
On Sun, Apr 10, 2005 at 11:51:24PM -0700, Andrew Morton ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote: > > > I based my listen program on the fclisten.c posted by Kaigai Kohei > > > with my own modification. Unfortunately i lost my test machine in the > > > lab. I will recreate the listen program Monday. The original listener > > > did not validate sequence number. It also prints length of data and > > > sequence number of every message it receives. My listener prints > > > only out-of-sequence error messages. > > > > > > The fork generator fork-test.c was yours? I called it fork-test > > > and let it run continuously in while-loop: > > > > > > # while 1 > > > # ./fork-test 1000 > > > # sleep 1 > > > # end > > > > > > I let it do 10,000,000 times of fork continuously while the system > > > is running AIM7 and/or ubench. > > > > > > The original fclisten.c and fork-test.c are attached for your reference. > > > > It is pretty normal to see duplicated numbers in a fork test - > > I observed it too, since counter is incremented without locks > > we can catch situation when it is incremented simultaneously > > on both processors, the latest version of the fork connector > > from Guillaume contains processor id in the message and per cpu counters, > > so one can destinguish messages which sequence numbers will flow > > in a very similar way now. > > Oh come on, that's just daft. Evgeniy, put a lock in there and fix it up. #ifndef FAST_AND_SUSPICIOUS spin_lock(_lock); #endif seq++; #ifndef FAST_AND_SUSPICIOUS spin_unlock(_lock); #endif :) -- Evgeniy Polyakov ( s0mbre ) - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote: > > I based my listen program on the fclisten.c posted by Kaigai Kohei > > with my own modification. Unfortunately i lost my test machine in the > > lab. I will recreate the listen program Monday. The original listener > > did not validate sequence number. It also prints length of data and > > sequence number of every message it receives. My listener prints > > only out-of-sequence error messages. > > > > The fork generator fork-test.c was yours? I called it fork-test > > and let it run continuously in while-loop: > > > > # while 1 > > # ./fork-test 1000 > > # sleep 1 > > # end > > > > I let it do 10,000,000 times of fork continuously while the system > > is running AIM7 and/or ubench. > > > > The original fclisten.c and fork-test.c are attached for your reference. > > It is pretty normal to see duplicated numbers in a fork test - > I observed it too, since counter is incremented without locks > we can catch situation when it is incremented simultaneously > on both processors, the latest version of the fork connector > from Guillaume contains processor id in the message and per cpu counters, > so one can destinguish messages which sequence numbers will flow > in a very similar way now. Oh come on, that's just daft. Evgeniy, put a lock in there and fix it up. - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote: > I based my listen program on the fclisten.c posted by Kaigai Kohei > with my own modification. Unfortunately i lost my test machine in the > lab. I will recreate the listen program Monday. The original listener > did not validate sequence number. It also prints length of data and > sequence number of every message it receives. My listener prints > only out-of-sequence error messages. > > The fork generator fork-test.c was yours? I called it fork-test > and let it run continuously in while-loop: > > # while 1 > # ./fork-test 1000 > # sleep 1 > # end > > I let it do 10,000,000 times of fork continuously while the system > is running AIM7 and/or ubench. > > The original fclisten.c and fork-test.c are attached for your reference. It is pretty normal to see duplicated numbers in a fork test - I observed it too, since counter is incremented without locks we can catch situation when it is incremented simultaneously on both processors, the latest version of the fork connector from Guillaume contains processor id in the message and per cpu counters, so one can destinguish messages which sequence numbers will flow in a very similar way now. > - jay > -- Evgeniy Polyakov - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote: I based my listen program on the fclisten.c posted by Kaigai Kohei with my own modification. Unfortunately i lost my test machine in the lab. I will recreate the listen program Monday. The original listener did not validate sequence number. It also prints length of data and sequence number of every message it receives. My listener prints only out-of-sequence error messages. The fork generator fork-test.c was yours? I called it fork-test and let it run continuously in while-loop: # while 1 # ./fork-test 1000 # sleep 1 # end I let it do 10,000,000 times of fork continuously while the system is running AIM7 and/or ubench. The original fclisten.c and fork-test.c are attached for your reference. It is pretty normal to see duplicated numbers in a fork test - I observed it too, since counter is incremented without locks we can catch situation when it is incremented simultaneously on both processors, the latest version of the fork connector from Guillaume contains processor id in the message and per cpu counters, so one can destinguish messages which sequence numbers will flow in a very similar way now. - jay -- Evgeniy Polyakov - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote: I based my listen program on the fclisten.c posted by Kaigai Kohei with my own modification. Unfortunately i lost my test machine in the lab. I will recreate the listen program Monday. The original listener did not validate sequence number. It also prints length of data and sequence number of every message it receives. My listener prints only out-of-sequence error messages. The fork generator fork-test.c was yours? I called it fork-test and let it run continuously in while-loop: # while 1 # ./fork-test 1000 # sleep 1 # end I let it do 10,000,000 times of fork continuously while the system is running AIM7 and/or ubench. The original fclisten.c and fork-test.c are attached for your reference. It is pretty normal to see duplicated numbers in a fork test - I observed it too, since counter is incremented without locks we can catch situation when it is incremented simultaneously on both processors, the latest version of the fork connector from Guillaume contains processor id in the message and per cpu counters, so one can destinguish messages which sequence numbers will flow in a very similar way now. Oh come on, that's just daft. Evgeniy, put a lock in there and fix it up. - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
On Sun, Apr 10, 2005 at 11:51:24PM -0700, Andrew Morton ([EMAIL PROTECTED]) wrote: Evgeniy Polyakov [EMAIL PROTECTED] wrote: On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote: I based my listen program on the fclisten.c posted by Kaigai Kohei with my own modification. Unfortunately i lost my test machine in the lab. I will recreate the listen program Monday. The original listener did not validate sequence number. It also prints length of data and sequence number of every message it receives. My listener prints only out-of-sequence error messages. The fork generator fork-test.c was yours? I called it fork-test and let it run continuously in while-loop: # while 1 # ./fork-test 1000 # sleep 1 # end I let it do 10,000,000 times of fork continuously while the system is running AIM7 and/or ubench. The original fclisten.c and fork-test.c are attached for your reference. It is pretty normal to see duplicated numbers in a fork test - I observed it too, since counter is incremented without locks we can catch situation when it is incremented simultaneously on both processors, the latest version of the fork connector from Guillaume contains processor id in the message and per cpu counters, so one can destinguish messages which sequence numbers will flow in a very similar way now. Oh come on, that's just daft. Evgeniy, put a lock in there and fix it up. #ifndef FAST_AND_SUSPICIOUS spin_lock(fork_lock); #endif seq++; #ifndef FAST_AND_SUSPICIOUS spin_unlock(fork_lock); #endif :) -- Evgeniy Polyakov ( s0mbre ) - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
I based my listen program on the fclisten.c posted by Kaigai Kohei
with my own modification. Unfortunately i lost my test machine in the
lab. I will recreate the listen program Monday. The original listener
did not validate sequence number. It also prints length of data and
sequence number of every message it receives. My listener prints
only out-of-sequence error messages.
The fork generator fork-test.c was yours? I called it fork-test
and let it run continuously in while-loop:
# while 1
# ./fork-test 1000
# sleep 1
# end
I let it do 10,000,000 times of fork continuously while the system
is running AIM7 and/or ubench.
The original fclisten.c and fork-test.c are attached for your reference.
- jay
Evgeniy Polyakov wrote:
On Fri, 08 Apr 2005 20:31:20 -0700
Jay Lan <[EMAIL PROTECTED]> wrote:
With the patch you provide to me, i did not see the bugcheck
at cn_queue_wrapper() at the console.
Unmatched sequence number messages still happened. We expect
to lose packets under system stressed situation, but i still
observed duplicate messages, which concerned me.
What tool and what version do you use
as message generator and receiver?
Thanks,
- jay
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
#include
#include
#include
#include
#include
#include
#include
void usage(){
puts("usage: fclisten ");
puts(" Default -> listening fork-connector");
puts(" on -> fork-connector Enable");
puts(" off -> fork-connector Disable");
exit(0);
}
#define MODE_LISTEN (1)
#define MODE_ENABLE (2)
#define MODE_DISABLE (3)
struct cb_id
{
__u32 idx;
__u32 val;
};
struct cn_msg
{
struct cb_idid;
__u32 seq;
__u32 ack;
__u32 len;/* Length of the following data */
__u8data[0];
};
int main(int argc, char *argv[]){
char buf[4096];
int mode, sockfd, len;
struct sockaddr_nl ad;
struct nlmsghdr *hdr = (struct nlmsghdr *)buf;
struct cn_msg *msg = (struct cn_msg *)(buf+sizeof(struct nlmsghdr));
switch(argc){
case 1:
mode = MODE_LISTEN;
break;
case 2:
if (strcasecmp("on",argv[1])==0) {
mode = MODE_ENABLE;
}else if (strcasecmp("off",argv[1])==0){
mode = MODE_DISABLE;
}else{
usage();
}
break;
default:
usage();
break;
}
if( (sockfd=socket(PF_NETLINK, SOCK_RAW, NETLINK_NFLOG)) < 0 ){
fprintf(stderr, "Fault on socket().\n");
return( 1 );
}
ad.nl_family = AF_NETLINK;
ad.nl_pad = 0;
ad.nl_pid = getpid();
ad.nl_groups = CN_IDX_FORK;
if( bind(sockfd, (struct sockaddr *), sizeof(ad)) ){
fprintf(stderr, "Fault on bind to netlink.\n");
return( 2 );
}
if (mode==MODE_LISTEN) {
while(-1){
len = recvfrom(sockfd, buf, 4096, 0, NULL, NULL);
printf("%d-byte recv Seq=%d\n", len, hdr->nlmsg_seq);
}
}else{
ad.nl_family = AF_NETLINK;
ad.nl_pad = 0;
ad.nl_pid = 0;
ad.nl_groups = 1;
hdr->nlmsg_len = sizeof(struct nlmsghdr) + sizeof(struct cn_msg) +
sizeof(int);
hdr->nlmsg_type = 0;
hdr->nlmsg_flags = 0;
hdr->nlmsg_seq = 0;
hdr->nlmsg_pid = getpid();
msg->id.idx = 0xfeed;
msg->id.val = 0xbeef;
msg->seq = msg->ack = 0;
msg->len = sizeof(int);
if (mode==MODE_ENABLE){
(*(int *)(msg->data)) = 1;
} else {
(*(int *)(msg->data)) = 0;
}
sendto(sockfd, buf, sizeof(struct nlmsghdr)+sizeof(struct
cn_msg)+sizeof(int),
0, (struct sockaddr *), sizeof(ad));
}
}
#include
#include
int main(int argc, char *argv[])
{
int pid;
int i = 0, max = 10;
struct timeval tv0, tv1;
struct timezone tz;
long diff;
if (argc >= 2)
max = atoi(argv[1]);
signal(SIGCHLD, SIG_IGN);
gettimeofday(, );
while (i++ < max) {
pid = fork();
if (pid == 0) {
sleep(1);
exit (0);
}
}
gettimeofday(, );
diff = (tv1.tv_sec - tv0.tv_sec)*100 + (tv1.tv_usec - tv0.tv_usec);
printf("Average per process fork+exit time is %ld usecs [diff=%lu,
max=%d].\n", diff/max, diff, max);
return 0;
}
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
I based my listen program on the fclisten.c posted by Kaigai Kohei
with my own modification. Unfortunately i lost my test machine in the
lab. I will recreate the listen program Monday. The original listener
did not validate sequence number. It also prints length of data and
sequence number of every message it receives. My listener prints
only out-of-sequence error messages.
The fork generator fork-test.c was yours? I called it fork-test
and let it run continuously in while-loop:
# while 1
# ./fork-test 1000
# sleep 1
# end
I let it do 10,000,000 times of fork continuously while the system
is running AIM7 and/or ubench.
The original fclisten.c and fork-test.c are attached for your reference.
- jay
Evgeniy Polyakov wrote:
On Fri, 08 Apr 2005 20:31:20 -0700
Jay Lan [EMAIL PROTECTED] wrote:
With the patch you provide to me, i did not see the bugcheck
at cn_queue_wrapper() at the console.
Unmatched sequence number messages still happened. We expect
to lose packets under system stressed situation, but i still
observed duplicate messages, which concerned me.
What tool and what version do you use
as message generator and receiver?
Thanks,
- jay
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
#include stdio.h
#include stdlib.h
#include string.h
#include asm/types.h
#include sys/types.h
#include sys/socket.h
#include linux/netlink.h
void usage(){
puts(usage: fclisten on|off);
puts( Default - listening fork-connector);
puts( on - fork-connector Enable);
puts( off - fork-connector Disable);
exit(0);
}
#define MODE_LISTEN (1)
#define MODE_ENABLE (2)
#define MODE_DISABLE (3)
struct cb_id
{
__u32 idx;
__u32 val;
};
struct cn_msg
{
struct cb_idid;
__u32 seq;
__u32 ack;
__u32 len;/* Length of the following data */
__u8data[0];
};
int main(int argc, char *argv[]){
char buf[4096];
int mode, sockfd, len;
struct sockaddr_nl ad;
struct nlmsghdr *hdr = (struct nlmsghdr *)buf;
struct cn_msg *msg = (struct cn_msg *)(buf+sizeof(struct nlmsghdr));
switch(argc){
case 1:
mode = MODE_LISTEN;
break;
case 2:
if (strcasecmp(on,argv[1])==0) {
mode = MODE_ENABLE;
}else if (strcasecmp(off,argv[1])==0){
mode = MODE_DISABLE;
}else{
usage();
}
break;
default:
usage();
break;
}
if( (sockfd=socket(PF_NETLINK, SOCK_RAW, NETLINK_NFLOG)) 0 ){
fprintf(stderr, Fault on socket().\n);
return( 1 );
}
ad.nl_family = AF_NETLINK;
ad.nl_pad = 0;
ad.nl_pid = getpid();
ad.nl_groups = CN_IDX_FORK;
if( bind(sockfd, (struct sockaddr *)ad, sizeof(ad)) ){
fprintf(stderr, Fault on bind to netlink.\n);
return( 2 );
}
if (mode==MODE_LISTEN) {
while(-1){
len = recvfrom(sockfd, buf, 4096, 0, NULL, NULL);
printf(%d-byte recv Seq=%d\n, len, hdr-nlmsg_seq);
}
}else{
ad.nl_family = AF_NETLINK;
ad.nl_pad = 0;
ad.nl_pid = 0;
ad.nl_groups = 1;
hdr-nlmsg_len = sizeof(struct nlmsghdr) + sizeof(struct cn_msg) +
sizeof(int);
hdr-nlmsg_type = 0;
hdr-nlmsg_flags = 0;
hdr-nlmsg_seq = 0;
hdr-nlmsg_pid = getpid();
msg-id.idx = 0xfeed;
msg-id.val = 0xbeef;
msg-seq = msg-ack = 0;
msg-len = sizeof(int);
if (mode==MODE_ENABLE){
(*(int *)(msg-data)) = 1;
} else {
(*(int *)(msg-data)) = 0;
}
sendto(sockfd, buf, sizeof(struct nlmsghdr)+sizeof(struct
cn_msg)+sizeof(int),
0, (struct sockaddr *)ad, sizeof(ad));
}
}
#include sys/signal.h
#include sys/time.h
int main(int argc, char *argv[])
{
int pid;
int i = 0, max = 10;
struct timeval tv0, tv1;
struct timezone tz;
long diff;
if (argc = 2)
max = atoi(argv[1]);
signal(SIGCHLD, SIG_IGN);
gettimeofday(tv0, tz);
while (i++ max) {
pid = fork();
if (pid == 0) {
sleep(1);
exit (0);
}
}
gettimeofday(tv1, tz);
diff = (tv1.tv_sec - tv0.tv_sec)*100 + (tv1.tv_usec - tv0.tv_usec);
printf(Average per process fork+exit time is %ld usecs [diff=%lu,
max=%d].\n, diff/max, diff, max);
return 0;
}
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
On Fri, 08 Apr 2005 20:31:20 -0700 Jay Lan <[EMAIL PROTECTED]> wrote: > With the patch you provide to me, i did not see the bugcheck > at cn_queue_wrapper() at the console. > > Unmatched sequence number messages still happened. We expect > to lose packets under system stressed situation, but i still > observed duplicate messages, which concerned me. What tool and what version do you use as message generator and receiver? > Thanks, > - jay Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
On Fri, 08 Apr 2005 20:31:20 -0700 Jay Lan [EMAIL PROTECTED] wrote: With the patch you provide to me, i did not see the bugcheck at cn_queue_wrapper() at the console. Unmatched sequence number messages still happened. We expect to lose packets under system stressed situation, but i still observed duplicate messages, which concerned me. What tool and what version do you use as message generator and receiver? Thanks, - jay Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
With the patch you provide to me, i did not see the bugcheck
at cn_queue_wrapper() at the console.
Unmatched sequence number messages still happened. We expect
to lose packets under system stressed situation, but i still
observed duplicate messages, which concerned me.
Unmatched seq. Rcvd=79477, expected=79478 <=== duplicate
Unmatched seq. Rcvd=713823, expected=713422 * loss of 401 msgs
Unmatched seq. Rcvd=80024, expected=79901 * loss of 123 msgs
Unmatched seq. Rcvd=93632, expected=93633 <=== duplicate
Unmatched seq. Rcvd=94718, expected=93970
Unmatched seq. Rcvd=743576, expected=743502
Unmatched seq. Rcvd=123506, expected=123507 <=== duplicate
Unmatched seq. Rcvd=773753, expected=773503
Unmatched seq. Rcvd=124111, expected=123938
Unmatched seq. Rcvd=157172, expected=157173 <=== duplicate
Unmatched seq. Rcvd=813024, expected=812913 <=== duplicate
Unmatched seq. Rcvd=813024, expected=813025 <=== duplicate
Unmatched seq. Rcvd=157830, expected=157501
Unmatched seq. Rcvd=158408, expected=158145
Unmatched seq. Rcvd=813678, expected=813438
The test system was a two cpu ia64.
Thanks,
- jay
Evgeniy Polyakov wrote:
On Fri, 08 Apr 2005 15:08:13 -0700
Jay Lan <[EMAIL PROTECTED]> wrote:
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
Ok.
The latest sources are always awailable at
http://tservice.net.ru/~s0mbre/archive/connector
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Evgeniy Polyakov wrote:
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask, I will send
updated sources with Andrew's comments resolved too.
I do not know exactly your connector version, so patch will probably
be applied with fuzz.
feel free to contact if it does not apply, I will send
the whole sources.
Thank you.
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to
compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
M connector.h
M cbus.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -70,7 +70,7 @@
* then it is new message.
*
*/
-void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
{
struct cn_callback_entry *n, *__cbq;
unsigned int size;
@@ -102,7 +102,7 @@
size = NLMSG_SPACE(sizeof(*msg) + msg->len);
-skb = alloc_skb(size, GFP_ATOMIC);
+skb = alloc_skb(size, gfp_mask);
if (!skb) {
printk(KERN_ERR "Failed to allocate new skb with size=%u.\n",
size);
return;
@@ -119,11 +119,11 @@
#endif
NETLINK_CB(skb).dst_groups = groups;
-
-uskb = skb_clone(skb, GFP_ATOMIC);
-if (uskb)
+#if 0
+uskb = skb_clone(skb, gfp_mask);
+if (uskb && 0)
netlink_unicast(dev->nls, uskb, 0, 0);
-
+#endif
netlink_broadcast(dev->nls, skb, 0, groups, GFP_ATOMIC);
return;
@@ -158,7 +158,7 @@
}
spin_unlock_bh(>cbdev->queue_lock);
-return found;
+return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
"requested msg->len=%u[%u], nlh->nlmsg_len=%u,
skb->len=%u.\n",
msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)),
nlh->nlmsg_len, skb->len);
-kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb->len, skb->data_len, skb->truesize, skb->protocol,
skb_cloned(skb), skb_shared(skb));
#endif
-while (skb->len >= NLMSG_SPACE(0)) {
+if (skb->len >= NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb->data;
+
if (nlh->nlmsg_len < sizeof(struct cn_msg) ||
skb->len < nlh->nlmsg_len ||
nlh->nlmsg_len > CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO "nlmsg_len=%u, sizeof(*nlh)=%u\n",
nlh->nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
-break;
+goto out;
}
len = NLMSG_ALIGN(nlh->nlmsg_len);
@@ -233,22 +233,11 @@
len = skb->len;
err = __cn_rx_skb(skb, nlh);
-if (err) {
-#if 0
-if (err < 0 && (nlh->nlmsg_flags & NLM_F_ACK))
-netlink_ack(skb, nlh, -err);
-#endif
-break;
-} else {
-#if 0
-if (nlh->nlmsg_flags & NLM_F_ACK)
-netlink_ack(skb, nlh, 0);
-#endif
-break;
-}
-skb_pull(skb, len);
+if (
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
On Fri, 08 Apr 2005 15:08:13 -0700
Jay Lan <[EMAIL PROTECTED]> wrote:
> Hi Evgeniy,
>
> Forget about my previous request of a new patch.
>
> The failures were straight forward enough to figure out.
Ok.
The latest sources are always awailable at
http://tservice.net.ru/~s0mbre/archive/connector
> - jay
>
> Jay Lan wrote:
> > My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
> >
> > Your patch caused 5 out of 8 hunks failure at connector.c
> > and one failure at connector.h.
> >
> > Could you generate a new patch based on my version? A tar
> > file of complete source of drivers/connector would work
> > also. :)
> >
> > Thanks!
> > - jay
> >
> > Evgeniy Polyakov wrote:
> >
> >> Could you give attached patch a try instead of previous one.
> >> It adds gfp mask into cn_netlink_send() call also.
> >> If you need updated CBUS sources, feel free to ask, I will send
> >> updated sources with Andrew's comments resolved too.
> >>
> >> I do not know exactly your connector version, so patch will probably
> >> be applied with fuzz.
> >>
> >> feel free to contact if it does not apply, I will send
> >> the whole sources.
> >>
> >> Thank you.
> >>
> >> * looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to
> >> compare with
> >> * comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
> >> M connector.c
> >> M connector.h
> >> M cbus.c
> >>
> >> * modified files
> >>
> >> --- orig/drivers/connector/connector.c
> >> +++ mod/drivers/connector/connector.c
> >> @@ -70,7 +70,7 @@
> >> * then it is new message.
> >> *
> >> */
> >> -void cn_netlink_send(struct cn_msg *msg, u32 __groups)
> >> +void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
> >> {
> >> struct cn_callback_entry *n, *__cbq;
> >> unsigned int size;
> >> @@ -102,7 +102,7 @@
> >>
> >> size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> >>
> >> -skb = alloc_skb(size, GFP_ATOMIC);
> >> +skb = alloc_skb(size, gfp_mask);
> >> if (!skb) {
> >> printk(KERN_ERR "Failed to allocate new skb with size=%u.\n",
> >> size);
> >> return;
> >> @@ -119,11 +119,11 @@
> >> #endif
> >>
> >> NETLINK_CB(skb).dst_groups = groups;
> >> -
> >> -uskb = skb_clone(skb, GFP_ATOMIC);
> >> -if (uskb)
> >> +#if 0
> >> +uskb = skb_clone(skb, gfp_mask);
> >> +if (uskb && 0)
> >> netlink_unicast(dev->nls, uskb, 0, 0);
> >> -
> >> +#endif
> >> netlink_broadcast(dev->nls, skb, 0, groups, GFP_ATOMIC);
> >>
> >> return;
> >> @@ -158,7 +158,7 @@
> >> }
> >> spin_unlock_bh(>cbdev->queue_lock);
> >>
> >> -return found;
> >> +return (found)?0:-ENODEV;
> >> }
> >>
> >> /*
> >> @@ -181,7 +181,6 @@
> >> "requested msg->len=%u[%u], nlh->nlmsg_len=%u,
> >> skb->len=%u.\n",
> >> msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)),
> >> nlh->nlmsg_len, skb->len);
> >> -kfree_skb(skb);
> >> return -EINVAL;
> >> }
> >> #if 0
> >> @@ -215,17 +214,18 @@
> >> skb->len, skb->data_len, skb->truesize, skb->protocol,
> >> skb_cloned(skb), skb_shared(skb));
> >> #endif
> >> -while (skb->len >= NLMSG_SPACE(0)) {
> >> +if (skb->len >= NLMSG_SPACE(0)) {
> >> nlh = (struct nlmsghdr *)skb->data;
> >> +
> >> if (nlh->nlmsg_len < sizeof(struct cn_msg) ||
> >> skb->len < nlh->nlmsg_len ||
> >> nlh->nlmsg_len > CONNECTOR_MAX_MSG_SIZE) {
> >> -#if 0
> >> +#if 1
> >> printk(KERN_INFO "nlmsg_len=%u, sizeof(*nlh)=%u\n",
> >> nlh->nlmsg_len, sizeof(*nlh));
> >> #endif
> >> kfree_skb(skb);
> >> -break;
> >> +goto out;
> >> }
> >>
> >> len = NLMSG_ALIGN(nlh->nlmsg_len);
> >> @@ -233,22 +
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Evgeniy Polyakov wrote:
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask, I will send
updated sources with Andrew's comments resolved too.
I do not know exactly your connector version, so patch will probably
be applied with fuzz.
feel free to contact if it does not apply, I will send
the whole sources.
Thank you.
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to
compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
M connector.h
M cbus.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -70,7 +70,7 @@
* then it is new message.
*
*/
-void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
{
struct cn_callback_entry *n, *__cbq;
unsigned int size;
@@ -102,7 +102,7 @@
size = NLMSG_SPACE(sizeof(*msg) + msg->len);
-skb = alloc_skb(size, GFP_ATOMIC);
+skb = alloc_skb(size, gfp_mask);
if (!skb) {
printk(KERN_ERR "Failed to allocate new skb with size=%u.\n",
size);
return;
@@ -119,11 +119,11 @@
#endif
NETLINK_CB(skb).dst_groups = groups;
-
-uskb = skb_clone(skb, GFP_ATOMIC);
-if (uskb)
+#if 0
+uskb = skb_clone(skb, gfp_mask);
+if (uskb && 0)
netlink_unicast(dev->nls, uskb, 0, 0);
-
+#endif
netlink_broadcast(dev->nls, skb, 0, groups, GFP_ATOMIC);
return;
@@ -158,7 +158,7 @@
}
spin_unlock_bh(>cbdev->queue_lock);
-return found;
+return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
"requested msg->len=%u[%u], nlh->nlmsg_len=%u,
skb->len=%u.\n",
msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)),
nlh->nlmsg_len, skb->len);
-kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb->len, skb->data_len, skb->truesize, skb->protocol,
skb_cloned(skb), skb_shared(skb));
#endif
-while (skb->len >= NLMSG_SPACE(0)) {
+if (skb->len >= NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb->data;
+
if (nlh->nlmsg_len < sizeof(struct cn_msg) ||
skb->len < nlh->nlmsg_len ||
nlh->nlmsg_len > CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO "nlmsg_len=%u, sizeof(*nlh)=%u\n",
nlh->nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
-break;
+goto out;
}
len = NLMSG_ALIGN(nlh->nlmsg_len);
@@ -233,22 +233,11 @@
len = skb->len;
err = __cn_rx_skb(skb, nlh);
-if (err) {
-#if 0
-if (err < 0 && (nlh->nlmsg_flags & NLM_F_ACK))
-netlink_ack(skb, nlh, -err);
-#endif
-break;
-} else {
-#if 0
-if (nlh->nlmsg_flags & NLM_F_ACK)
-netlink_ack(skb, nlh, 0);
-#endif
-break;
-}
-skb_pull(skb, len);
+if (err < 0)
+kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
@@ -310,7 +299,7 @@
m.ack = notify_event;
memcpy(, id, sizeof(m.id));
-cn_netlink_send(, ctl->group);
+cn_netlink_send(, ctl->group, GFP_ATOMIC);
}
}
spin_unlock_bh(_lock);
--- orig/include/linux/connector.h
+++ mod/include/linux/connector.h
@@ -148,7 +148,7 @@
int cn_add_callback(struct cb_id *, char *, void (* callback)(void *));
void cn_del_callback(struct cb_id *);
-void cn_netlink_send(struct cn_msg *, u32);
+void cn_netlink_send(struct cn_msg *, u32, int);
int cn_queue_add_callback(struct cn_queue_dev *dev, struct
cn_callback *cb);
void cn_queue_del_callback(struct cn_queue_dev *dev, struct cb_id *id);
-
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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Evgeniy Polyakov wrote:
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask,
I will send updated sources with Andrew's comments resolved too.
I do not know exactly your connector version,
so patch will probably be applied with fuzz.
feel free to contact if it does not apply, I will send
the whole sources.
Thank you.
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
M connector.h
M cbus.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -70,7 +70,7 @@
* then it is new message.
*
*/
-void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
{
struct cn_callback_entry *n, *__cbq;
unsigned int size;
@@ -102,7 +102,7 @@
size = NLMSG_SPACE(sizeof(*msg) + msg->len);
- skb = alloc_skb(size, GFP_ATOMIC);
+ skb = alloc_skb(size, gfp_mask);
if (!skb) {
printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", size);
return;
@@ -119,11 +119,11 @@
#endif
NETLINK_CB(skb).dst_groups = groups;
-
- uskb = skb_clone(skb, GFP_ATOMIC);
- if (uskb)
+#if 0
+ uskb = skb_clone(skb, gfp_mask);
+ if (uskb && 0)
netlink_unicast(dev->nls, uskb, 0, 0);
-
+#endif
netlink_broadcast(dev->nls, skb, 0, groups, GFP_ATOMIC);
return;
@@ -158,7 +158,7 @@
}
spin_unlock_bh(>cbdev->queue_lock);
- return found;
+ return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
"requested msg->len=%u[%u], nlh->nlmsg_len=%u, skb->len=%u.\n",
msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)),
nlh->nlmsg_len, skb->len);
- kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb->len, skb->data_len, skb->truesize, skb->protocol,
skb_cloned(skb), skb_shared(skb));
#endif
- while (skb->len >= NLMSG_SPACE(0)) {
+ if (skb->len >= NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb->data;
+
if (nlh->nlmsg_len < sizeof(struct cn_msg) ||
skb->len < nlh->nlmsg_len ||
nlh->nlmsg_len > CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO "nlmsg_len=%u, sizeof(*nlh)=%u\n",
nlh->nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
- break;
+ goto out;
}
len = NLMSG_ALIGN(nlh->nlmsg_len);
@@ -233,22 +233,11 @@
len = skb->len;
err = __cn_rx_skb(skb, nlh);
- if (err) {
-#if 0
- if (err < 0 && (nlh->nlmsg_flags & NLM_F_ACK))
-netlink_ack(skb, nlh, -err);
-#endif
- break;
- } else {
-#if 0
- if (nlh->nlmsg_flags & NLM_F_ACK)
-netlink_ack(skb, nlh, 0);
-#endif
- break;
- }
- skb_pull(skb, len);
+ if (err < 0)
+ kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
@@ -310,7 +299,7 @@
m.ack = notify_event;
memcpy(, id, sizeof(m.id));
- cn_netlink_send(, ctl->group);
+ cn_netlink_send(, ctl->group, GFP_ATOMIC);
}
}
spin_unlock_bh(_lock);
--- orig/include/linux/connector.h
+++ mod/include/linux/connector.h
@@ -148,7 +148,7 @@
int cn_add_callback(struct cb_id *, char *, void (* callback)(void *));
void cn_del_callback(struct cb_id *);
-void cn_netlink_send(struct cn_msg *, u32);
+void cn_netlink_send(struct cn_msg *, u32, int);
int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb);
void cn_queue_del_callback(struct cn_queue_dev *dev, struct cb_id *id);
-
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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask,
I will send updated sources with Andrew's comments resolved too.
I do not know exactly your connector version,
so patch will probably be applied with fuzz.
feel free to contact if it does not apply, I will send
the whole sources.
Thank you.
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
M connector.h
M cbus.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -70,7 +70,7 @@
* then it is new message.
*
*/
-void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
{
struct cn_callback_entry *n, *__cbq;
unsigned int size;
@@ -102,7 +102,7 @@
size = NLMSG_SPACE(sizeof(*msg) + msg->len);
- skb = alloc_skb(size, GFP_ATOMIC);
+ skb = alloc_skb(size, gfp_mask);
if (!skb) {
printk(KERN_ERR "Failed to allocate new skb with size=%u.\n",
size);
return;
@@ -119,11 +119,11 @@
#endif
NETLINK_CB(skb).dst_groups = groups;
-
- uskb = skb_clone(skb, GFP_ATOMIC);
- if (uskb)
+#if 0
+ uskb = skb_clone(skb, gfp_mask);
+ if (uskb && 0)
netlink_unicast(dev->nls, uskb, 0, 0);
-
+#endif
netlink_broadcast(dev->nls, skb, 0, groups, GFP_ATOMIC);
return;
@@ -158,7 +158,7 @@
}
spin_unlock_bh(>cbdev->queue_lock);
- return found;
+ return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
"requested msg->len=%u[%u], nlh->nlmsg_len=%u,
skb->len=%u.\n",
msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)),
nlh->nlmsg_len, skb->len);
- kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb->len, skb->data_len, skb->truesize, skb->protocol,
skb_cloned(skb), skb_shared(skb));
#endif
- while (skb->len >= NLMSG_SPACE(0)) {
+ if (skb->len >= NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb->data;
+
if (nlh->nlmsg_len < sizeof(struct cn_msg) ||
skb->len < nlh->nlmsg_len ||
nlh->nlmsg_len > CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO "nlmsg_len=%u, sizeof(*nlh)=%u\n",
nlh->nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
- break;
+ goto out;
}
len = NLMSG_ALIGN(nlh->nlmsg_len);
@@ -233,22 +233,11 @@
len = skb->len;
err = __cn_rx_skb(skb, nlh);
- if (err) {
-#if 0
- if (err < 0 && (nlh->nlmsg_flags & NLM_F_ACK))
- netlink_ack(skb, nlh, -err);
-#endif
- break;
- } else {
-#if 0
- if (nlh->nlmsg_flags & NLM_F_ACK)
- netlink_ack(skb, nlh, 0);
-#endif
- break;
- }
- skb_pull(skb, len);
+ if (err < 0)
+ kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
@@ -310,7 +299,7 @@
m.ack = notify_event;
memcpy(, id, sizeof(m.id));
- cn_netlink_send(, ctl->group);
+ cn_netlink_send(, ctl->group, GFP_ATOMIC);
}
}
spin_unlock_bh(_lock);
--- orig/include/linux/connector.h
+++ mod/include/linux/connector.h
@@ -148,7 +148,7 @@
int cn_add_callback(struct cb_id *, char *, void (* callback)(void *));
void cn_del_callback(struct cb_id *);
-void cn_netlink_send(struct cn_msg *, u32);
+void cn_netlink_send(struct cn_msg *, u32, int);
int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb);
void cn_queue_del_callback(struct cn_queue_dev *dev, struct cb_id *id);
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
On Thu, 2005-04-07 at 15:47 -0700, Jay Lan wrote:
> BTW, when it happened last time, my program listening to the socket
> complained about duplicate messages received.
>
> Unmatched seq. Rcvd=1824062, expected=1824061 <===
> Unmatched seq. Rcvd=1824062, expected=1824063 <===
> Unmatched seq. Rcvd=1824348, expected=1824307
>
> When my program received 1824062 while expecting 1824061
> it adjusted itself to expect the next one being 1824063. But instead
> the message of 1824062 arrived the second time.
Thank you for your report.
Could you reproduce a bug with the attached patch?
> - jay
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -121,7 +121,7 @@
NETLINK_CB(skb).dst_groups = groups;
uskb = skb_clone(skb, GFP_ATOMIC);
- if (uskb)
+ if (uskb && 0)
netlink_unicast(dev->nls, uskb, 0, 0);
netlink_broadcast(dev->nls, skb, 0, groups, GFP_ATOMIC);
@@ -158,7 +158,7 @@
}
spin_unlock_bh(>cbdev->queue_lock);
- return found;
+ return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
"requested msg->len=%u[%u], nlh->nlmsg_len=%u,
skb->len=%u.\n",
msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)),
nlh->nlmsg_len, skb->len);
- kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb->len, skb->data_len, skb->truesize, skb->protocol,
skb_cloned(skb), skb_shared(skb));
#endif
- while (skb->len >= NLMSG_SPACE(0)) {
+ if (skb->len >= NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb->data;
+
if (nlh->nlmsg_len < sizeof(struct cn_msg) ||
skb->len < nlh->nlmsg_len ||
nlh->nlmsg_len > CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO "nlmsg_len=%u, sizeof(*nlh)=%u\n",
nlh->nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
- break;
+ goto out;
}
len = NLMSG_ALIGN(nlh->nlmsg_len);
@@ -233,22 +233,11 @@
len = skb->len;
err = __cn_rx_skb(skb, nlh);
- if (err) {
-#if 0
- if (err < 0 && (nlh->nlmsg_flags & NLM_F_ACK))
- netlink_ack(skb, nlh, -err);
-#endif
- break;
- } else {
-#if 0
- if (nlh->nlmsg_flags & NLM_F_ACK)
- netlink_ack(skb, nlh, 0);
-#endif
- break;
- }
- skb_pull(skb, len);
+ if (err < 0)
+ kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
On Thu, 2005-04-07 at 15:47 -0700, Jay Lan wrote:
BTW, when it happened last time, my program listening to the socket
complained about duplicate messages received.
Unmatched seq. Rcvd=1824062, expected=1824061 ===
Unmatched seq. Rcvd=1824062, expected=1824063 ===
Unmatched seq. Rcvd=1824348, expected=1824307
When my program received 1824062 while expecting 1824061
it adjusted itself to expect the next one being 1824063. But instead
the message of 1824062 arrived the second time.
Thank you for your report.
Could you reproduce a bug with the attached patch?
- jay
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -121,7 +121,7 @@
NETLINK_CB(skb).dst_groups = groups;
uskb = skb_clone(skb, GFP_ATOMIC);
- if (uskb)
+ if (uskb 0)
netlink_unicast(dev-nls, uskb, 0, 0);
netlink_broadcast(dev-nls, skb, 0, groups, GFP_ATOMIC);
@@ -158,7 +158,7 @@
}
spin_unlock_bh(dev-cbdev-queue_lock);
- return found;
+ return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
requested msg-len=%u[%u], nlh-nlmsg_len=%u,
skb-len=%u.\n,
msg-len, NLMSG_SPACE(msg-len + sizeof(*msg)),
nlh-nlmsg_len, skb-len);
- kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb-len, skb-data_len, skb-truesize, skb-protocol,
skb_cloned(skb), skb_shared(skb));
#endif
- while (skb-len = NLMSG_SPACE(0)) {
+ if (skb-len = NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb-data;
+
if (nlh-nlmsg_len sizeof(struct cn_msg) ||
skb-len nlh-nlmsg_len ||
nlh-nlmsg_len CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO nlmsg_len=%u, sizeof(*nlh)=%u\n,
nlh-nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
- break;
+ goto out;
}
len = NLMSG_ALIGN(nlh-nlmsg_len);
@@ -233,22 +233,11 @@
len = skb-len;
err = __cn_rx_skb(skb, nlh);
- if (err) {
-#if 0
- if (err 0 (nlh-nlmsg_flags NLM_F_ACK))
- netlink_ack(skb, nlh, -err);
-#endif
- break;
- } else {
-#if 0
- if (nlh-nlmsg_flags NLM_F_ACK)
- netlink_ack(skb, nlh, 0);
-#endif
- break;
- }
- skb_pull(skb, len);
+ if (err 0)
+ kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask,
I will send updated sources with Andrew's comments resolved too.
I do not know exactly your connector version,
so patch will probably be applied with fuzz.
feel free to contact if it does not apply, I will send
the whole sources.
Thank you.
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
M connector.h
M cbus.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -70,7 +70,7 @@
* then it is new message.
*
*/
-void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
{
struct cn_callback_entry *n, *__cbq;
unsigned int size;
@@ -102,7 +102,7 @@
size = NLMSG_SPACE(sizeof(*msg) + msg-len);
- skb = alloc_skb(size, GFP_ATOMIC);
+ skb = alloc_skb(size, gfp_mask);
if (!skb) {
printk(KERN_ERR Failed to allocate new skb with size=%u.\n,
size);
return;
@@ -119,11 +119,11 @@
#endif
NETLINK_CB(skb).dst_groups = groups;
-
- uskb = skb_clone(skb, GFP_ATOMIC);
- if (uskb)
+#if 0
+ uskb = skb_clone(skb, gfp_mask);
+ if (uskb 0)
netlink_unicast(dev-nls, uskb, 0, 0);
-
+#endif
netlink_broadcast(dev-nls, skb, 0, groups, GFP_ATOMIC);
return;
@@ -158,7 +158,7 @@
}
spin_unlock_bh(dev-cbdev-queue_lock);
- return found;
+ return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
requested msg-len=%u[%u], nlh-nlmsg_len=%u,
skb-len=%u.\n,
msg-len, NLMSG_SPACE(msg-len + sizeof(*msg)),
nlh-nlmsg_len, skb-len);
- kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb-len, skb-data_len, skb-truesize, skb-protocol,
skb_cloned(skb), skb_shared(skb));
#endif
- while (skb-len = NLMSG_SPACE(0)) {
+ if (skb-len = NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb-data;
+
if (nlh-nlmsg_len sizeof(struct cn_msg) ||
skb-len nlh-nlmsg_len ||
nlh-nlmsg_len CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO nlmsg_len=%u, sizeof(*nlh)=%u\n,
nlh-nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
- break;
+ goto out;
}
len = NLMSG_ALIGN(nlh-nlmsg_len);
@@ -233,22 +233,11 @@
len = skb-len;
err = __cn_rx_skb(skb, nlh);
- if (err) {
-#if 0
- if (err 0 (nlh-nlmsg_flags NLM_F_ACK))
- netlink_ack(skb, nlh, -err);
-#endif
- break;
- } else {
-#if 0
- if (nlh-nlmsg_flags NLM_F_ACK)
- netlink_ack(skb, nlh, 0);
-#endif
- break;
- }
- skb_pull(skb, len);
+ if (err 0)
+ kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
@@ -310,7 +299,7 @@
m.ack = notify_event;
memcpy(m.id, id, sizeof(m.id));
- cn_netlink_send(m, ctl-group);
+ cn_netlink_send(m, ctl-group, GFP_ATOMIC);
}
}
spin_unlock_bh(notify_lock);
--- orig/include/linux/connector.h
+++ mod/include/linux/connector.h
@@ -148,7 +148,7 @@
int cn_add_callback(struct cb_id *, char *, void (* callback)(void *));
void cn_del_callback(struct cb_id *);
-void cn_netlink_send(struct cn_msg *, u32);
+void cn_netlink_send(struct cn_msg *, u32, int);
int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb);
void cn_queue_del_callback(struct cn_queue_dev *dev, struct cb_id *id);
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Evgeniy Polyakov wrote:
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask,
I will send updated sources with Andrew's comments resolved too.
I do not know exactly your connector version,
so patch will probably be applied with fuzz.
feel free to contact if it does not apply, I will send
the whole sources.
Thank you.
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
M connector.h
M cbus.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -70,7 +70,7 @@
* then it is new message.
*
*/
-void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
{
struct cn_callback_entry *n, *__cbq;
unsigned int size;
@@ -102,7 +102,7 @@
size = NLMSG_SPACE(sizeof(*msg) + msg-len);
- skb = alloc_skb(size, GFP_ATOMIC);
+ skb = alloc_skb(size, gfp_mask);
if (!skb) {
printk(KERN_ERR Failed to allocate new skb with size=%u.\n, size);
return;
@@ -119,11 +119,11 @@
#endif
NETLINK_CB(skb).dst_groups = groups;
-
- uskb = skb_clone(skb, GFP_ATOMIC);
- if (uskb)
+#if 0
+ uskb = skb_clone(skb, gfp_mask);
+ if (uskb 0)
netlink_unicast(dev-nls, uskb, 0, 0);
-
+#endif
netlink_broadcast(dev-nls, skb, 0, groups, GFP_ATOMIC);
return;
@@ -158,7 +158,7 @@
}
spin_unlock_bh(dev-cbdev-queue_lock);
- return found;
+ return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
requested msg-len=%u[%u], nlh-nlmsg_len=%u, skb-len=%u.\n,
msg-len, NLMSG_SPACE(msg-len + sizeof(*msg)),
nlh-nlmsg_len, skb-len);
- kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb-len, skb-data_len, skb-truesize, skb-protocol,
skb_cloned(skb), skb_shared(skb));
#endif
- while (skb-len = NLMSG_SPACE(0)) {
+ if (skb-len = NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb-data;
+
if (nlh-nlmsg_len sizeof(struct cn_msg) ||
skb-len nlh-nlmsg_len ||
nlh-nlmsg_len CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO nlmsg_len=%u, sizeof(*nlh)=%u\n,
nlh-nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
- break;
+ goto out;
}
len = NLMSG_ALIGN(nlh-nlmsg_len);
@@ -233,22 +233,11 @@
len = skb-len;
err = __cn_rx_skb(skb, nlh);
- if (err) {
-#if 0
- if (err 0 (nlh-nlmsg_flags NLM_F_ACK))
-netlink_ack(skb, nlh, -err);
-#endif
- break;
- } else {
-#if 0
- if (nlh-nlmsg_flags NLM_F_ACK)
-netlink_ack(skb, nlh, 0);
-#endif
- break;
- }
- skb_pull(skb, len);
+ if (err 0)
+ kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
@@ -310,7 +299,7 @@
m.ack = notify_event;
memcpy(m.id, id, sizeof(m.id));
- cn_netlink_send(m, ctl-group);
+ cn_netlink_send(m, ctl-group, GFP_ATOMIC);
}
}
spin_unlock_bh(notify_lock);
--- orig/include/linux/connector.h
+++ mod/include/linux/connector.h
@@ -148,7 +148,7 @@
int cn_add_callback(struct cb_id *, char *, void (* callback)(void *));
void cn_del_callback(struct cb_id *);
-void cn_netlink_send(struct cn_msg *, u32);
+void cn_netlink_send(struct cn_msg *, u32, int);
int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb);
void cn_queue_del_callback(struct cn_queue_dev *dev, struct cb_id *id);
-
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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Evgeniy Polyakov wrote:
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask, I will send
updated sources with Andrew's comments resolved too.
I do not know exactly your connector version, so patch will probably
be applied with fuzz.
feel free to contact if it does not apply, I will send
the whole sources.
Thank you.
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to
compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
M connector.h
M cbus.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -70,7 +70,7 @@
* then it is new message.
*
*/
-void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
{
struct cn_callback_entry *n, *__cbq;
unsigned int size;
@@ -102,7 +102,7 @@
size = NLMSG_SPACE(sizeof(*msg) + msg-len);
-skb = alloc_skb(size, GFP_ATOMIC);
+skb = alloc_skb(size, gfp_mask);
if (!skb) {
printk(KERN_ERR Failed to allocate new skb with size=%u.\n,
size);
return;
@@ -119,11 +119,11 @@
#endif
NETLINK_CB(skb).dst_groups = groups;
-
-uskb = skb_clone(skb, GFP_ATOMIC);
-if (uskb)
+#if 0
+uskb = skb_clone(skb, gfp_mask);
+if (uskb 0)
netlink_unicast(dev-nls, uskb, 0, 0);
-
+#endif
netlink_broadcast(dev-nls, skb, 0, groups, GFP_ATOMIC);
return;
@@ -158,7 +158,7 @@
}
spin_unlock_bh(dev-cbdev-queue_lock);
-return found;
+return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
requested msg-len=%u[%u], nlh-nlmsg_len=%u,
skb-len=%u.\n,
msg-len, NLMSG_SPACE(msg-len + sizeof(*msg)),
nlh-nlmsg_len, skb-len);
-kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb-len, skb-data_len, skb-truesize, skb-protocol,
skb_cloned(skb), skb_shared(skb));
#endif
-while (skb-len = NLMSG_SPACE(0)) {
+if (skb-len = NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb-data;
+
if (nlh-nlmsg_len sizeof(struct cn_msg) ||
skb-len nlh-nlmsg_len ||
nlh-nlmsg_len CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO nlmsg_len=%u, sizeof(*nlh)=%u\n,
nlh-nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
-break;
+goto out;
}
len = NLMSG_ALIGN(nlh-nlmsg_len);
@@ -233,22 +233,11 @@
len = skb-len;
err = __cn_rx_skb(skb, nlh);
-if (err) {
-#if 0
-if (err 0 (nlh-nlmsg_flags NLM_F_ACK))
-netlink_ack(skb, nlh, -err);
-#endif
-break;
-} else {
-#if 0
-if (nlh-nlmsg_flags NLM_F_ACK)
-netlink_ack(skb, nlh, 0);
-#endif
-break;
-}
-skb_pull(skb, len);
+if (err 0)
+kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
@@ -310,7 +299,7 @@
m.ack = notify_event;
memcpy(m.id, id, sizeof(m.id));
-cn_netlink_send(m, ctl-group);
+cn_netlink_send(m, ctl-group, GFP_ATOMIC);
}
}
spin_unlock_bh(notify_lock);
--- orig/include/linux/connector.h
+++ mod/include/linux/connector.h
@@ -148,7 +148,7 @@
int cn_add_callback(struct cb_id *, char *, void (* callback)(void *));
void cn_del_callback(struct cb_id *);
-void cn_netlink_send(struct cn_msg *, u32);
+void cn_netlink_send(struct cn_msg *, u32, int);
int cn_queue_add_callback(struct cn_queue_dev *dev, struct
cn_callback *cb);
void cn_queue_del_callback(struct cn_queue_dev *dev, struct cb_id *id);
-
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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
On Fri, 08 Apr 2005 15:08:13 -0700
Jay Lan [EMAIL PROTECTED] wrote:
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
Ok.
The latest sources are always awailable at
http://tservice.net.ru/~s0mbre/archive/connector
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Evgeniy Polyakov wrote:
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask, I will send
updated sources with Andrew's comments resolved too.
I do not know exactly your connector version, so patch will probably
be applied with fuzz.
feel free to contact if it does not apply, I will send
the whole sources.
Thank you.
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to
compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
M connector.h
M cbus.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -70,7 +70,7 @@
* then it is new message.
*
*/
-void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
{
struct cn_callback_entry *n, *__cbq;
unsigned int size;
@@ -102,7 +102,7 @@
size = NLMSG_SPACE(sizeof(*msg) + msg-len);
-skb = alloc_skb(size, GFP_ATOMIC);
+skb = alloc_skb(size, gfp_mask);
if (!skb) {
printk(KERN_ERR Failed to allocate new skb with size=%u.\n,
size);
return;
@@ -119,11 +119,11 @@
#endif
NETLINK_CB(skb).dst_groups = groups;
-
-uskb = skb_clone(skb, GFP_ATOMIC);
-if (uskb)
+#if 0
+uskb = skb_clone(skb, gfp_mask);
+if (uskb 0)
netlink_unicast(dev-nls, uskb, 0, 0);
-
+#endif
netlink_broadcast(dev-nls, skb, 0, groups, GFP_ATOMIC);
return;
@@ -158,7 +158,7 @@
}
spin_unlock_bh(dev-cbdev-queue_lock);
-return found;
+return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
requested msg-len=%u[%u], nlh-nlmsg_len=%u,
skb-len=%u.\n,
msg-len, NLMSG_SPACE(msg-len + sizeof(*msg)),
nlh-nlmsg_len, skb-len);
-kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb-len, skb-data_len, skb-truesize, skb-protocol,
skb_cloned(skb), skb_shared(skb));
#endif
-while (skb-len = NLMSG_SPACE(0)) {
+if (skb-len = NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb-data;
+
if (nlh-nlmsg_len sizeof(struct cn_msg) ||
skb-len nlh-nlmsg_len ||
nlh-nlmsg_len CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO nlmsg_len=%u, sizeof(*nlh)=%u\n,
nlh-nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
-break;
+goto out;
}
len = NLMSG_ALIGN(nlh-nlmsg_len);
@@ -233,22 +233,11 @@
len = skb-len;
err = __cn_rx_skb(skb, nlh);
-if (err) {
-#if 0
-if (err 0 (nlh-nlmsg_flags NLM_F_ACK))
-netlink_ack(skb, nlh, -err);
-#endif
-break;
-} else {
-#if 0
-if (nlh-nlmsg_flags NLM_F_ACK)
-netlink_ack(skb, nlh, 0);
-#endif
-break;
-}
-skb_pull(skb, len);
+if (err 0)
+kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
@@ -310,7 +299,7 @@
m.ack = notify_event;
memcpy(m.id, id, sizeof(m.id));
-cn_netlink_send(m, ctl-group);
+cn_netlink_send(m, ctl-group, GFP_ATOMIC);
}
}
spin_unlock_bh(notify_lock);
--- orig/include/linux/connector.h
+++ mod/include/linux/connector.h
@@ -148,7 +148,7 @@
int cn_add_callback(struct cb_id *, char *, void (* callback)(void *));
void cn_del_callback(struct cb_id *);
-void cn_netlink_send(struct cn_msg *, u32);
+void cn_netlink_send(struct cn_msg *, u32, int);
int cn_queue_add_callback(struct cn_queue_dev *dev, struct
cn_callback *cb);
void cn_queue_del_callback(struct cn_queue_dev *dev, struct cb_id *id);
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
With the patch you provide to me, i did not see the bugcheck
at cn_queue_wrapper() at the console.
Unmatched sequence number messages still happened. We expect
to lose packets under system stressed situation, but i still
observed duplicate messages, which concerned me.
Unmatched seq. Rcvd=79477, expected=79478 === duplicate
Unmatched seq. Rcvd=713823, expected=713422 * loss of 401 msgs
Unmatched seq. Rcvd=80024, expected=79901 * loss of 123 msgs
Unmatched seq. Rcvd=93632, expected=93633 === duplicate
Unmatched seq. Rcvd=94718, expected=93970
Unmatched seq. Rcvd=743576, expected=743502
Unmatched seq. Rcvd=123506, expected=123507 === duplicate
Unmatched seq. Rcvd=773753, expected=773503
Unmatched seq. Rcvd=124111, expected=123938
Unmatched seq. Rcvd=157172, expected=157173 === duplicate
Unmatched seq. Rcvd=813024, expected=812913 === duplicate
Unmatched seq. Rcvd=813024, expected=813025 === duplicate
Unmatched seq. Rcvd=157830, expected=157501
Unmatched seq. Rcvd=158408, expected=158145
Unmatched seq. Rcvd=813678, expected=813438
The test system was a two cpu ia64.
Thanks,
- jay
Evgeniy Polyakov wrote:
On Fri, 08 Apr 2005 15:08:13 -0700
Jay Lan [EMAIL PROTECTED] wrote:
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
Ok.
The latest sources are always awailable at
http://tservice.net.ru/~s0mbre/archive/connector
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Evgeniy Polyakov wrote:
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask, I will send
updated sources with Andrew's comments resolved too.
I do not know exactly your connector version, so patch will probably
be applied with fuzz.
feel free to contact if it does not apply, I will send
the whole sources.
Thank you.
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to
compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
M connector.h
M cbus.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -70,7 +70,7 @@
* then it is new message.
*
*/
-void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
{
struct cn_callback_entry *n, *__cbq;
unsigned int size;
@@ -102,7 +102,7 @@
size = NLMSG_SPACE(sizeof(*msg) + msg-len);
-skb = alloc_skb(size, GFP_ATOMIC);
+skb = alloc_skb(size, gfp_mask);
if (!skb) {
printk(KERN_ERR Failed to allocate new skb with size=%u.\n,
size);
return;
@@ -119,11 +119,11 @@
#endif
NETLINK_CB(skb).dst_groups = groups;
-
-uskb = skb_clone(skb, GFP_ATOMIC);
-if (uskb)
+#if 0
+uskb = skb_clone(skb, gfp_mask);
+if (uskb 0)
netlink_unicast(dev-nls, uskb, 0, 0);
-
+#endif
netlink_broadcast(dev-nls, skb, 0, groups, GFP_ATOMIC);
return;
@@ -158,7 +158,7 @@
}
spin_unlock_bh(dev-cbdev-queue_lock);
-return found;
+return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
requested msg-len=%u[%u], nlh-nlmsg_len=%u,
skb-len=%u.\n,
msg-len, NLMSG_SPACE(msg-len + sizeof(*msg)),
nlh-nlmsg_len, skb-len);
-kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb-len, skb-data_len, skb-truesize, skb-protocol,
skb_cloned(skb), skb_shared(skb));
#endif
-while (skb-len = NLMSG_SPACE(0)) {
+if (skb-len = NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb-data;
+
if (nlh-nlmsg_len sizeof(struct cn_msg) ||
skb-len nlh-nlmsg_len ||
nlh-nlmsg_len CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO nlmsg_len=%u, sizeof(*nlh)=%u\n,
nlh-nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
-break;
+goto out;
}
len = NLMSG_ALIGN(nlh-nlmsg_len);
@@ -233,22 +233,11 @@
len = skb-len;
err = __cn_rx_skb(skb, nlh);
-if (err) {
-#if 0
-if (err 0 (nlh-nlmsg_flags NLM_F_ACK))
-netlink_ack(skb, nlh, -err);
-#endif
-break;
-} else {
-#if 0
-if (nlh-nlmsg_flags NLM_F_ACK)
-netlink_ack(skb, nlh, 0);
-#endif
-break;
-}
-skb_pull(skb, len);
+if (err 0)
+kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
@@ -310,7 +299,7 @@
m.ack = notify_event;
memcpy(m.id, id, sizeof(m.id));
-cn_netlink_send(m, ctl-group
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
BTW, when it happened last time, my program listening to the socket complained about duplicate messages received. Unmatched seq. Rcvd=1824062, expected=1824061 <=== Unmatched seq. Rcvd=1824062, expected=1824063 <=== Unmatched seq. Rcvd=1824348, expected=1824307 When my program received 1824062 while expecting 1824061 it adjusted itself to expect the next one being 1824063. But instead the message of 1824062 arrived the second time. - jay Jay Lan wrote: Hi Evgeniy, Should i be concerned about this bugcheck? I have seen this happening a number of times, all with the same signature in my testing. I ran a mix of AIM7, ubench, fork-test (continuously fork new processes), and another program reading from the fork connector socket. Thanks, - jay cqueue/1[656]: bugcheck! 0 [1] Modules linked in: nfs lockd sunrpc sg st sr_mod ipv6 usbcore Pid: 656, CPU 1, comm: cqueue/1 psr : 1010085a6010 ifs : 8289 ip : []Not tainted ip is at __kfree_skb+0x1b0/0x220 unat: pfs : 0289 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001005cee50 b6 : a001e7e0 b7 : a001003ae440 f6 : 0fffbc8c0 f7 : 0ffdaa200 f8 : 18000 f9 : 10002a000 f10 : 0fffcc8c0 f11 : 1003e r1 : a00100c0ec00 r2 : 4000 r3 : 4000 r8 : 0028 r9 : a001008eaac8 r10 : 0004 r11 : 0028 r12 : e0307a99fd60 r13 : e0307a998000 r14 : a00100887c00 r15 : a00100a24b18 r16 : a00100a22e18 r17 : r18 : a00100887bec r19 : a00100a9080f r20 : 3517 r21 : 000f r22 : 0034 r23 : 0034 r24 : a00100a90810 r25 : 3518 r26 : 3518 r27 : 0010085a6010 r28 : a00100a90811 r29 : 3519 r30 : r31 : a00100a24ae8 Call Trace: [] show_stack+0x80/0xa0 sp=e0307a99f920 bsp=e0307a999078 [] show_regs+0x840/0x880 sp=e0307a99faf0 bsp=e0307a999018 [] die+0x150/0x1c0 sp=e0307a99fb00 bsp=e0307a998fd0 [] die_if_kernel+0x40/0x60 sp=e0307a99fb00 bsp=e0307a998fa0 [] ia64_bad_break+0x300/0x380 sp=e0307a99fb00 bsp=e0307a998f78 [] ia64_leave_kernel+0x0/0x280 sp=e0307a99fb90 bsp=e0307a998f78 [] __kfree_skb+0x1b0/0x220 sp=e0307a99fd60 bsp=e0307a998f30 [] kfree_skb+0x50/0xa0 sp=e0307a99fd60 bsp=e0307a998f10 [] cn_queue_wrapper+0xe0/0x100 sp=e0307a99fd60 bsp=e0307a998ee8 [] worker_thread+0x3e0/0x520 sp=e0307a99fd60 bsp=e0307a998e60 [] kthread+0x290/0x300 sp=e0307a99fdd0 bsp=e0307a998e20 [] kernel_thread_helper+0xe0/0x100 sp=e0307a99fe30 bsp=e0307a998df0 [] start_kernel_thread+0x20/0x40 sp=e0307a99fe30 bsp=e0307a998df0 - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
Hi Evgeniy, Should i be concerned about this bugcheck? I have seen this happening a number of times, all with the same signature in my testing. I ran a mix of AIM7, ubench, fork-test (continuously fork new processes), and another program reading from the fork connector socket. Thanks, - jay cqueue/1[656]: bugcheck! 0 [1] Modules linked in: nfs lockd sunrpc sg st sr_mod ipv6 usbcore Pid: 656, CPU 1, comm: cqueue/1 psr : 1010085a6010 ifs : 8289 ip : []Not tainted ip is at __kfree_skb+0x1b0/0x220 unat: pfs : 0289 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001005cee50 b6 : a001e7e0 b7 : a001003ae440 f6 : 0fffbc8c0 f7 : 0ffdaa200 f8 : 18000 f9 : 10002a000 f10 : 0fffcc8c0 f11 : 1003e r1 : a00100c0ec00 r2 : 4000 r3 : 4000 r8 : 0028 r9 : a001008eaac8 r10 : 0004 r11 : 0028 r12 : e0307a99fd60 r13 : e0307a998000 r14 : a00100887c00 r15 : a00100a24b18 r16 : a00100a22e18 r17 : r18 : a00100887bec r19 : a00100a9080f r20 : 3517 r21 : 000f r22 : 0034 r23 : 0034 r24 : a00100a90810 r25 : 3518 r26 : 3518 r27 : 0010085a6010 r28 : a00100a90811 r29 : 3519 r30 : r31 : a00100a24ae8 Call Trace: [] show_stack+0x80/0xa0 sp=e0307a99f920 bsp=e0307a999078 [] show_regs+0x840/0x880 sp=e0307a99faf0 bsp=e0307a999018 [] die+0x150/0x1c0 sp=e0307a99fb00 bsp=e0307a998fd0 [] die_if_kernel+0x40/0x60 sp=e0307a99fb00 bsp=e0307a998fa0 [] ia64_bad_break+0x300/0x380 sp=e0307a99fb00 bsp=e0307a998f78 [] ia64_leave_kernel+0x0/0x280 sp=e0307a99fb90 bsp=e0307a998f78 [] __kfree_skb+0x1b0/0x220 sp=e0307a99fd60 bsp=e0307a998f30 [] kfree_skb+0x50/0xa0 sp=e0307a99fd60 bsp=e0307a998f10 [] cn_queue_wrapper+0xe0/0x100 sp=e0307a99fd60 bsp=e0307a998ee8 [] worker_thread+0x3e0/0x520 sp=e0307a99fd60 bsp=e0307a998e60 [] kthread+0x290/0x300 sp=e0307a99fdd0 bsp=e0307a998e20 [] kernel_thread_helper+0xe0/0x100 sp=e0307a99fe30 bsp=e0307a998df0 [] start_kernel_thread+0x20/0x40 sp=e0307a99fe30 bsp=e0307a998df0 - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
Hi Evgeniy, Should i be concerned about this bugcheck? I have seen this happening a number of times, all with the same signature in my testing. I ran a mix of AIM7, ubench, fork-test (continuously fork new processes), and another program reading from the fork connector socket. Thanks, - jay cqueue/1[656]: bugcheck! 0 [1] Modules linked in: nfs lockd sunrpc sg st sr_mod ipv6 usbcore Pid: 656, CPU 1, comm: cqueue/1 psr : 1010085a6010 ifs : 8289 ip : [a001005cee50]Not tainted ip is at __kfree_skb+0x1b0/0x220 unat: pfs : 0289 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001005cee50 b6 : a001e7e0 b7 : a001003ae440 f6 : 0fffbc8c0 f7 : 0ffdaa200 f8 : 18000 f9 : 10002a000 f10 : 0fffcc8c0 f11 : 1003e r1 : a00100c0ec00 r2 : 4000 r3 : 4000 r8 : 0028 r9 : a001008eaac8 r10 : 0004 r11 : 0028 r12 : e0307a99fd60 r13 : e0307a998000 r14 : a00100887c00 r15 : a00100a24b18 r16 : a00100a22e18 r17 : r18 : a00100887bec r19 : a00100a9080f r20 : 3517 r21 : 000f r22 : 0034 r23 : 0034 r24 : a00100a90810 r25 : 3518 r26 : 3518 r27 : 0010085a6010 r28 : a00100a90811 r29 : 3519 r30 : r31 : a00100a24ae8 Call Trace: [a001000126a0] show_stack+0x80/0xa0 sp=e0307a99f920 bsp=e0307a999078 [a00100012f00] show_regs+0x840/0x880 sp=e0307a99faf0 bsp=e0307a999018 [a00100034890] die+0x150/0x1c0 sp=e0307a99fb00 bsp=e0307a998fd0 [a00100034940] die_if_kernel+0x40/0x60 sp=e0307a99fb00 bsp=e0307a998fa0 [a00100035d20] ia64_bad_break+0x300/0x380 sp=e0307a99fb00 bsp=e0307a998f78 [a001b5e0] ia64_leave_kernel+0x0/0x280 sp=e0307a99fb90 bsp=e0307a998f78 [a001005cee50] __kfree_skb+0x1b0/0x220 sp=e0307a99fd60 bsp=e0307a998f30 [a0010044f630] kfree_skb+0x50/0xa0 sp=e0307a99fd60 bsp=e0307a998f10 [a0010044e400] cn_queue_wrapper+0xe0/0x100 sp=e0307a99fd60 bsp=e0307a998ee8 [a001000cb880] worker_thread+0x3e0/0x520 sp=e0307a99fd60 bsp=e0307a998e60 [a001000d7210] kthread+0x290/0x300 sp=e0307a99fdd0 bsp=e0307a998e20 [a00100010a00] kernel_thread_helper+0xe0/0x100 sp=e0307a99fe30 bsp=e0307a998df0 [a0019120] start_kernel_thread+0x20/0x40 sp=e0307a99fe30 bsp=e0307a998df0 - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
BTW, when it happened last time, my program listening to the socket complained about duplicate messages received. Unmatched seq. Rcvd=1824062, expected=1824061 === Unmatched seq. Rcvd=1824062, expected=1824063 === Unmatched seq. Rcvd=1824348, expected=1824307 When my program received 1824062 while expecting 1824061 it adjusted itself to expect the next one being 1824063. But instead the message of 1824062 arrived the second time. - jay Jay Lan wrote: Hi Evgeniy, Should i be concerned about this bugcheck? I have seen this happening a number of times, all with the same signature in my testing. I ran a mix of AIM7, ubench, fork-test (continuously fork new processes), and another program reading from the fork connector socket. Thanks, - jay cqueue/1[656]: bugcheck! 0 [1] Modules linked in: nfs lockd sunrpc sg st sr_mod ipv6 usbcore Pid: 656, CPU 1, comm: cqueue/1 psr : 1010085a6010 ifs : 8289 ip : [a001005cee50]Not tainted ip is at __kfree_skb+0x1b0/0x220 unat: pfs : 0289 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001005cee50 b6 : a001e7e0 b7 : a001003ae440 f6 : 0fffbc8c0 f7 : 0ffdaa200 f8 : 18000 f9 : 10002a000 f10 : 0fffcc8c0 f11 : 1003e r1 : a00100c0ec00 r2 : 4000 r3 : 4000 r8 : 0028 r9 : a001008eaac8 r10 : 0004 r11 : 0028 r12 : e0307a99fd60 r13 : e0307a998000 r14 : a00100887c00 r15 : a00100a24b18 r16 : a00100a22e18 r17 : r18 : a00100887bec r19 : a00100a9080f r20 : 3517 r21 : 000f r22 : 0034 r23 : 0034 r24 : a00100a90810 r25 : 3518 r26 : 3518 r27 : 0010085a6010 r28 : a00100a90811 r29 : 3519 r30 : r31 : a00100a24ae8 Call Trace: [a001000126a0] show_stack+0x80/0xa0 sp=e0307a99f920 bsp=e0307a999078 [a00100012f00] show_regs+0x840/0x880 sp=e0307a99faf0 bsp=e0307a999018 [a00100034890] die+0x150/0x1c0 sp=e0307a99fb00 bsp=e0307a998fd0 [a00100034940] die_if_kernel+0x40/0x60 sp=e0307a99fb00 bsp=e0307a998fa0 [a00100035d20] ia64_bad_break+0x300/0x380 sp=e0307a99fb00 bsp=e0307a998f78 [a001b5e0] ia64_leave_kernel+0x0/0x280 sp=e0307a99fb90 bsp=e0307a998f78 [a001005cee50] __kfree_skb+0x1b0/0x220 sp=e0307a99fd60 bsp=e0307a998f30 [a0010044f630] kfree_skb+0x50/0xa0 sp=e0307a99fd60 bsp=e0307a998f10 [a0010044e400] cn_queue_wrapper+0xe0/0x100 sp=e0307a99fd60 bsp=e0307a998ee8 [a001000cb880] worker_thread+0x3e0/0x520 sp=e0307a99fd60 bsp=e0307a998e60 [a001000d7210] kthread+0x290/0x300 sp=e0307a99fdd0 bsp=e0307a998e20 [a00100010a00] kernel_thread_helper+0xe0/0x100 sp=e0307a99fe30 bsp=e0307a998df0 [a0019120] start_kernel_thread+0x20/0x40 sp=e0307a99fe30 bsp=e0307a998df0 - 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/
Re: 2.6.12-rc1-mm4 crash while mounting a reiserfs3 filesystem
Bartlomiej Zolnierkiewicz a écrit : On Apr 3, 2005 11:56 PM, Andrew Morton <[EMAIL PROTECTED]> wrote: Mathieu Bérard <[EMAIL PROTECTED]> wrote: Hi, I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4. (Everyting run smoothly using 2.6.11-mm1) It seems to be related with mounting a reiserfs3 filesystem. It looks more like an IDE bug. ReiserFS: hdg1: checking transaction log (hdg1) Unable to handle kernel paging request at virtual address 0a373138 printing eip: df6d1211 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: ext2 mbcache w83627hf i2c_sensor i2c_isa ppp_generic slhc w83627hf_wdt msr cpuid rtc CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010202 (2.6.12-rc1-mm4) EIP is at 0xdf6d1211 eax: c9393266 ebx: df6d1c84 ecx: d84eab1e edx: c155ccf8 esi: c039242c edi: c039239c ebp: 700d580a esp: df6d1c80 ds: 007b es: 007b ss: 0068 Process mount (pid: 1132, threadinfo=df6d1000 task=df711a50) Stack: c039242c c0229945 c039239c df6d1000 df6d1000 c039242c c155ccf8 c0223051 0088 1388 c159ae28 df6d1000 c039242c c155ccf8 c039239c c022333e df6d1d1c c153d6e0 c155bd78 df6d1d1c c14007f0 c0212260 Call Trace: [] flagged_taskfile+0x125/0x380 [] start_request+0x1f1/0x2a0 [] ide_do_request+0x20e/0x3c0 [] __generic_unplug_device+0x20/0x30 [] generic_unplug_device+0x11/0x30 [] blk_backing_dev_unplug+0xc/0x10 [] sync_buffer+0x26/0x40 [] __wait_on_bit+0x42/0x70 [] sync_buffer+0x0/0x40 [] sync_buffer+0x0/0x40 [] out_of_line_wait_on_bit+0x7d/0x90 [] wake_bit_function+0x0/0x60 [] __wait_on_buffer+0x29/0x30 [] _update_journal_header_block+0xf7/0x140 [] journal_read+0x31d/0x470 [] journal_init+0x4e1/0x650 [] printk+0x1b/0x20 [] reiserfs_fill_super+0x34d/0x770 [] snprintf+0x20/0x30 [] disk_name+0x96/0xf0 [] get_sb_bdev+0xe5/0x130 [] link_path_walk+0x65/0x140 [] get_super_block+0x18/0x20 [] reiserfs_fill_super+0x0/0x770 [] do_kern_mount+0x44/0xf020 30 20 30 20 30 20 30 20 30 20 30 20 30 20 30 20 <1>general p It appears that we might have jumped from flagged_taskfile into something at 0xdf6d1211, which is rather odd. It is very odd, we shouldn't hit flagged_taskfile() in the first place. This function currently is executed only for special HDIO_DRIVE_TASKFILE ioctl requests. Whatever the explanation was, This oops is fixed in 2.6.12-rc2-mm1... -- Mathieu Bérard - 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/
Re: [PATCH] 2.6.12-rc1-mm4 x86_64 genapic update
On Fri, Apr 01, 2005 at 12:37:27PM -0500, Jason Davis wrote: > Hello, > > x86_64 genapic mechanism should be aware of machines that use physical APIC > mode regardless of how many clusters/processors are detected. ACPI 3.0 FADT > makes this determination very simple by providing a feature flag > "force_apic_physical_destination_mode" to state whether the machine > unconditionally uses physical APIC mode. Unisys' next generation x86_64 > ES7000 will need to utilize this FADT feature flag in order to boot the > x86_64 kernel in the correct APIC mode. This patch has been tested on both > x86_64 commodity and ES7000 boxes. Patch is ok for me. -Andi - 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/
Re: [2.6.12-rc1-mm4] swapped memset arguments
On Sunday 03 April 2005 01:38, Jesper Juhl wrote:
> On Sat, 2 Apr 2005, Maciej Soltysiak wrote:
>
> > Hi,
> >
> > out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments.
> > I found one:
> >
> > # grep -nr "memset.*\,\(\ \|\)0\(\ \|\));" *
> > net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct
> > ieee80211_txb), 0);
> >
> And here's a patch :
>
>
> Fix swapped memset() arguments in net/ieee80211/ieee80211_tx.c
> found by Maciej Soltysiak.
This one will stop these from happening again.
(Well, at least on i386)...
--
vda
--- linux-2.6.11.src/include/asm-i386/string.h.orig Thu Mar 3 09:31:08 2005
+++ linux-2.6.11.src/include/asm-i386/string.h Tue Apr 5 18:34:28 2005
@@ -316,8 +345,16 @@ __asm__ __volatile__(
return s;
}
-/* we might want to write optimized versions of these later */
-#define __constant_count_memset(s,c,count) __memset_generic((s),(c),(count))
+/*
+ * we might want to write optimized versions of this later
+ * for mow, just prevent common mistake of memset(a,c,0)
+ */
+void BUG_memset_with_zero_length(void);
+static inline void * __constant_count_memset(void * s, int c, size_t count)
+{
+ if(!count) BUG_memset_with_zero_length();
+ return __memset_generic(s,c,count);
+}
/*
* memset(x,0,y) is a reasonably common thing to do, so we want to fill
@@ -376,6 +413,7 @@ static inline void * __constant_c_and_co
{
switch (count) {
case 0:
+ BUG_memset_with_zero_length();
return s;
case 1:
*(unsigned char *)s = pattern;
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Hi, On Tuesday, 5 of April 2005 17:01, Romano Giannetti wrote: > > > > Same way to debug it, then try minimal drivers. > > Yes, the lifer of a kernel debugger is hard... > > Pavel, one question (maybe stupid, I am not at all an expert). Wouldn't be > possible to add a printk when invoking and returning from suspend/resume > methods of drivers, telling if they are specific or generic on? Maybe with > the help of the serial console could be an aid to detect wich drivers are > failing in that case. The serial sonsole itself is disabled during suspend/resume, so you have to hack the serial driver's suspend/resume routines to get any output on it at that time. :-) Anyway, if you want to put some debug printks somewhere, IMO a good place to start is in resume_device() in drivers/base/power/resume.c or in suspend_device() in drivers/base/power/suspend.c (actually, there already is one, you only need to enable it). Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
> > Same way to debug it, then try minimal drivers. Yes, the lifer of a kernel debugger is hard... Pavel, one question (maybe stupid, I am not at all an expert). Wouldn't be possible to add a printk when invoking and returning from suspend/resume methods of drivers, telling if they are specific or generic on? Maybe with the help of the serial console could be an aid to detect wich drivers are failing in that case. It could have helped the ALPS case, methinks. Obviously, under a "kernel hacking" config. I'd love to be able to make it myself, but I do not know where to start... Romano -- Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain) Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569 - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Hi! > Same issue here. > > Suspend-to-ram works perfectly fine with kernel 2.6.12-rc1-mm1, in > mm2,3 and mm4 it is broken. > > It suspends properly but does not resume. Just a blackscreen and no > reaction on keypress/usb plug-in/network/power button. > Same way to debug it, then try minimal drivers. -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
On Die, 05 Apr 2005, Pavel Machek wrote: > > It's b44. It *was* working with b44 insmod-ed and up and running, but > > now as soon as b44-eth0 is ifup-ed while suspending, the resume freezes. > > If I do a ifdown eth0 before suspending, it works. > > Does this one help? With 2.6.12-rc1-mm4 it did help. For 2.6.12-rc2-mm1 see previous email. Thanks. Best wishes Norbert --- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- KITMURVY (n.) Man who owns all the latest sporting gadgetry and clothing (gold trolley, tee cosies, ventilated shoes, Gary Player- autographed tracksuit top, American navy cap, mirror sunglasses) but is still only on his second gold lesson. --- Douglas Adams, The Meaning of Liff - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
On Die, 05 Apr 2005, Pavel Machek wrote: > > It's b44. It *was* working with b44 insmod-ed and up and running, but > > now as soon as b44-eth0 is ifup-ed while suspending, the resume freezes. > > If I do a ifdown eth0 before suspending, it works. > > Does this one help? I compiled it into 2.6.12-rc2-mm1, and first wanted to try it with module removed etc, but 2.6.12-rc2-mm1 not even freezes after resuming, but immediately reboots! So, more to track down. I will recreate my 2.6.12-rc1-mm4 tree, and try your fix. Then I will try to find out *why* the hell 2.6.12-rc2-mm1 is not resuming at all. Any ideas? Best wishes Norbert --- Dr. Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- QUENBY (n.) A stubborn spot on a window which you spend twenty minutes trying to clean off before discovering it's on the other side of the glass. --- Douglas Adams, The Meaning of Liff - 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/
Re: 2.6.12-rc1-mm4 crash while mounting a reiserfs3 filesystem
On Apr 3, 2005 11:56 PM, Andrew Morton <[EMAIL PROTECTED]> wrote: > Mathieu Bérard <[EMAIL PROTECTED]> wrote: > > > > Hi, > > I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4. > > (Everyting run smoothly using 2.6.11-mm1) > > It seems to be related with mounting a reiserfs3 filesystem. > > It looks more like an IDE bug. > > > ReiserFS: hdg1: checking transaction log (hdg1) > > Unable to handle kernel paging request at virtual address 0a373138 > > printing eip: > > df6d1211 > > *pde = > > Oops: 0002 [#1] > > PREEMPT > > Modules linked in: ext2 mbcache w83627hf i2c_sensor i2c_isa ppp_generic > > slhc w83627hf_wdt msr cpuid > > rtc > > CPU:0 > > EIP:0060:[]Not tainted VLI > > EFLAGS: 00010202 (2.6.12-rc1-mm4) > > EIP is at 0xdf6d1211 > > eax: c9393266 ebx: df6d1c84 ecx: d84eab1e edx: c155ccf8 > > esi: c039242c edi: c039239c ebp: 700d580a esp: df6d1c80 > > ds: 007b es: 007b ss: 0068 > > Process mount (pid: 1132, threadinfo=df6d1000 task=df711a50) > > Stack: c039242c c0229945 c039239c df6d1000 df6d1000 c039242c c155ccf8 > > c0223051 > > 0088 1388 c159ae28 df6d1000 c039242c c155ccf8 c039239c > > c022333e > > df6d1d1c c153d6e0 c155bd78 df6d1d1c c14007f0 > > c0212260 > > Call Trace: > > [] flagged_taskfile+0x125/0x380 > > [] start_request+0x1f1/0x2a0 > > [] ide_do_request+0x20e/0x3c0 > > [] __generic_unplug_device+0x20/0x30 > > [] generic_unplug_device+0x11/0x30 > > [] blk_backing_dev_unplug+0xc/0x10 > > [] sync_buffer+0x26/0x40 > > [] __wait_on_bit+0x42/0x70 > > [] sync_buffer+0x0/0x40 > > [] sync_buffer+0x0/0x40 > > [] out_of_line_wait_on_bit+0x7d/0x90 > > [] wake_bit_function+0x0/0x60 > > [] __wait_on_buffer+0x29/0x30 > > [] _update_journal_header_block+0xf7/0x140 > > [] journal_read+0x31d/0x470 > > [] journal_init+0x4e1/0x650 > > [] printk+0x1b/0x20 > > [] reiserfs_fill_super+0x34d/0x770 > > [] snprintf+0x20/0x30 > > [] disk_name+0x96/0xf0 > > [] get_sb_bdev+0xe5/0x130 > > [] link_path_walk+0x65/0x140 > > [] get_super_block+0x18/0x20 > > [] reiserfs_fill_super+0x0/0x770 > > [] do_kern_mount+0x44/0xf020 30 20 30 20 30 20 30 20 30 20 > > 30 20 30 20 30 20 <1>general p > > It appears that we might have jumped from flagged_taskfile into something > at 0xdf6d1211, which is rather odd. It is very odd, we shouldn't hit flagged_taskfile() in the first place. This function currently is executed only for special HDIO_DRIVE_TASKFILE ioctl requests. - 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/
Re: [PATCH] 2.6.12-rc1-mm4 x86_64 genapic update
On Fri, Apr 01, 2005 at 12:37:27PM -0500, Jason Davis wrote: Hello, x86_64 genapic mechanism should be aware of machines that use physical APIC mode regardless of how many clusters/processors are detected. ACPI 3.0 FADT makes this determination very simple by providing a feature flag force_apic_physical_destination_mode to state whether the machine unconditionally uses physical APIC mode. Unisys' next generation x86_64 ES7000 will need to utilize this FADT feature flag in order to boot the x86_64 kernel in the correct APIC mode. This patch has been tested on both x86_64 commodity and ES7000 boxes. Patch is ok for me. -Andi - 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/
Re: 2.6.12-rc1-mm4 crash while mounting a reiserfs3 filesystem
Bartlomiej Zolnierkiewicz a écrit : On Apr 3, 2005 11:56 PM, Andrew Morton [EMAIL PROTECTED] wrote: Mathieu Bérard [EMAIL PROTECTED] wrote: Hi, I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4. (Everyting run smoothly using 2.6.11-mm1) It seems to be related with mounting a reiserfs3 filesystem. It looks more like an IDE bug. ReiserFS: hdg1: checking transaction log (hdg1) Unable to handle kernel paging request at virtual address 0a373138 printing eip: df6d1211 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: ext2 mbcache w83627hf i2c_sensor i2c_isa ppp_generic slhc w83627hf_wdt msr cpuid rtc CPU:0 EIP:0060:[df6d1211]Not tainted VLI EFLAGS: 00010202 (2.6.12-rc1-mm4) EIP is at 0xdf6d1211 eax: c9393266 ebx: df6d1c84 ecx: d84eab1e edx: c155ccf8 esi: c039242c edi: c039239c ebp: 700d580a esp: df6d1c80 ds: 007b es: 007b ss: 0068 Process mount (pid: 1132, threadinfo=df6d1000 task=df711a50) Stack: c039242c c0229945 c039239c df6d1000 df6d1000 c039242c c155ccf8 c0223051 0088 1388 c159ae28 df6d1000 c039242c c155ccf8 c039239c c022333e df6d1d1c c153d6e0 c155bd78 df6d1d1c c14007f0 c0212260 Call Trace: [c0229945] flagged_taskfile+0x125/0x380 [c0223051] start_request+0x1f1/0x2a0 [c022333e] ide_do_request+0x20e/0x3c0 [c0212260] __generic_unplug_device+0x20/0x30 [c0212281] generic_unplug_device+0x11/0x30 [c02122ac] blk_backing_dev_unplug+0xc/0x10 [c0156336] sync_buffer+0x26/0x40 [c02a0b22] __wait_on_bit+0x42/0x70 [c0156310] sync_buffer+0x0/0x40 [c0156310] sync_buffer+0x0/0x40 [c02a0bcd] out_of_line_wait_on_bit+0x7d/0x90 [c012bf80] wake_bit_function+0x0/0x60 [c01563c9] __wait_on_buffer+0x29/0x30 [c01b0dd7] _update_journal_header_block+0xf7/0x140 [c01b290d] journal_read+0x31d/0x470 [c01b3241] journal_init+0x4e1/0x650 [c011748b] printk+0x1b/0x20 [c01a3ced] reiserfs_fill_super+0x34d/0x770 [c01c9470] snprintf+0x20/0x30 [c0189ab6] disk_name+0x96/0xf0 [c015bf75] get_sb_bdev+0xe5/0x130 [c0163945] link_path_walk+0x65/0x140 [c01a4168] get_super_block+0x18/0x20 [c01a39a0] reiserfs_fill_super+0x0/0x770 [c015c194] do_kern_mount+0x44/0xf020 30 20 30 20 30 20 30 20 30 20 30 20 30 20 30 20 1general p It appears that we might have jumped from flagged_taskfile into something at 0xdf6d1211, which is rather odd. It is very odd, we shouldn't hit flagged_taskfile() in the first place. This function currently is executed only for special HDIO_DRIVE_TASKFILE ioctl requests. Whatever the explanation was, This oops is fixed in 2.6.12-rc2-mm1... -- Mathieu Bérard - 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/
Re: 2.6.12-rc1-mm4 crash while mounting a reiserfs3 filesystem
On Apr 3, 2005 11:56 PM, Andrew Morton [EMAIL PROTECTED] wrote: Mathieu Bérard [EMAIL PROTECTED] wrote: Hi, I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4. (Everyting run smoothly using 2.6.11-mm1) It seems to be related with mounting a reiserfs3 filesystem. It looks more like an IDE bug. ReiserFS: hdg1: checking transaction log (hdg1) Unable to handle kernel paging request at virtual address 0a373138 printing eip: df6d1211 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: ext2 mbcache w83627hf i2c_sensor i2c_isa ppp_generic slhc w83627hf_wdt msr cpuid rtc CPU:0 EIP:0060:[df6d1211]Not tainted VLI EFLAGS: 00010202 (2.6.12-rc1-mm4) EIP is at 0xdf6d1211 eax: c9393266 ebx: df6d1c84 ecx: d84eab1e edx: c155ccf8 esi: c039242c edi: c039239c ebp: 700d580a esp: df6d1c80 ds: 007b es: 007b ss: 0068 Process mount (pid: 1132, threadinfo=df6d1000 task=df711a50) Stack: c039242c c0229945 c039239c df6d1000 df6d1000 c039242c c155ccf8 c0223051 0088 1388 c159ae28 df6d1000 c039242c c155ccf8 c039239c c022333e df6d1d1c c153d6e0 c155bd78 df6d1d1c c14007f0 c0212260 Call Trace: [c0229945] flagged_taskfile+0x125/0x380 [c0223051] start_request+0x1f1/0x2a0 [c022333e] ide_do_request+0x20e/0x3c0 [c0212260] __generic_unplug_device+0x20/0x30 [c0212281] generic_unplug_device+0x11/0x30 [c02122ac] blk_backing_dev_unplug+0xc/0x10 [c0156336] sync_buffer+0x26/0x40 [c02a0b22] __wait_on_bit+0x42/0x70 [c0156310] sync_buffer+0x0/0x40 [c0156310] sync_buffer+0x0/0x40 [c02a0bcd] out_of_line_wait_on_bit+0x7d/0x90 [c012bf80] wake_bit_function+0x0/0x60 [c01563c9] __wait_on_buffer+0x29/0x30 [c01b0dd7] _update_journal_header_block+0xf7/0x140 [c01b290d] journal_read+0x31d/0x470 [c01b3241] journal_init+0x4e1/0x650 [c011748b] printk+0x1b/0x20 [c01a3ced] reiserfs_fill_super+0x34d/0x770 [c01c9470] snprintf+0x20/0x30 [c0189ab6] disk_name+0x96/0xf0 [c015bf75] get_sb_bdev+0xe5/0x130 [c0163945] link_path_walk+0x65/0x140 [c01a4168] get_super_block+0x18/0x20 [c01a39a0] reiserfs_fill_super+0x0/0x770 [c015c194] do_kern_mount+0x44/0xf020 30 20 30 20 30 20 30 20 30 20 30 20 30 20 30 20 1general p It appears that we might have jumped from flagged_taskfile into something at 0xdf6d1211, which is rather odd. It is very odd, we shouldn't hit flagged_taskfile() in the first place. This function currently is executed only for special HDIO_DRIVE_TASKFILE ioctl requests. - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
On Die, 05 Apr 2005, Pavel Machek wrote: It's b44. It *was* working with b44 insmod-ed and up and running, but now as soon as b44-eth0 is ifup-ed while suspending, the resume freezes. If I do a ifdown eth0 before suspending, it works. Does this one help? I compiled it into 2.6.12-rc2-mm1, and first wanted to try it with module removed etc, but 2.6.12-rc2-mm1 not even freezes after resuming, but immediately reboots! So, more to track down. I will recreate my 2.6.12-rc1-mm4 tree, and try your fix. Then I will try to find out *why* the hell 2.6.12-rc2-mm1 is not resuming at all. Any ideas? Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- QUENBY (n.) A stubborn spot on a window which you spend twenty minutes trying to clean off before discovering it's on the other side of the glass. --- Douglas Adams, The Meaning of Liff - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
On Die, 05 Apr 2005, Pavel Machek wrote: It's b44. It *was* working with b44 insmod-ed and up and running, but now as soon as b44-eth0 is ifup-ed while suspending, the resume freezes. If I do a ifdown eth0 before suspending, it works. Does this one help? With 2.6.12-rc1-mm4 it did help. For 2.6.12-rc2-mm1 see previous email. Thanks. Best wishes Norbert --- Dr. Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- KITMURVY (n.) Man who owns all the latest sporting gadgetry and clothing (gold trolley, tee cosies, ventilated shoes, Gary Player- autographed tracksuit top, American navy cap, mirror sunglasses) but is still only on his second gold lesson. --- Douglas Adams, The Meaning of Liff - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Hi! Same issue here. Suspend-to-ram works perfectly fine with kernel 2.6.12-rc1-mm1, in mm2,3 and mm4 it is broken. It suspends properly but does not resume. Just a blackscreen and no reaction on keypress/usb plug-in/network/power button. Same way to debug it, then try minimal drivers. -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Same way to debug it, then try minimal drivers. Yes, the lifer of a kernel debugger is hard... Pavel, one question (maybe stupid, I am not at all an expert). Wouldn't be possible to add a printk when invoking and returning from suspend/resume methods of drivers, telling if they are specific or generic on? Maybe with the help of the serial console could be an aid to detect wich drivers are failing in that case. It could have helped the ALPS case, methinks. Obviously, under a kernel hacking config. I'd love to be able to make it myself, but I do not know where to start... Romano -- Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain) Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569 - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Hi, On Tuesday, 5 of April 2005 17:01, Romano Giannetti wrote: Same way to debug it, then try minimal drivers. Yes, the lifer of a kernel debugger is hard... Pavel, one question (maybe stupid, I am not at all an expert). Wouldn't be possible to add a printk when invoking and returning from suspend/resume methods of drivers, telling if they are specific or generic on? Maybe with the help of the serial console could be an aid to detect wich drivers are failing in that case. The serial sonsole itself is disabled during suspend/resume, so you have to hack the serial driver's suspend/resume routines to get any output on it at that time. :-) Anyway, if you want to put some debug printks somewhere, IMO a good place to start is in resume_device() in drivers/base/power/resume.c or in suspend_device() in drivers/base/power/suspend.c (actually, there already is one, you only need to enable it). Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - 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/
Re: [2.6.12-rc1-mm4] swapped memset arguments
On Sunday 03 April 2005 01:38, Jesper Juhl wrote:
On Sat, 2 Apr 2005, Maciej Soltysiak wrote:
Hi,
out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments.
I found one:
# grep -nr memset.*\,\(\ \|\)0\(\ \|\)); *
net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct
ieee80211_txb), 0);
And here's a patch :
Fix swapped memset() arguments in net/ieee80211/ieee80211_tx.c
found by Maciej Soltysiak.
This one will stop these from happening again.
(Well, at least on i386)...
--
vda
--- linux-2.6.11.src/include/asm-i386/string.h.orig Thu Mar 3 09:31:08 2005
+++ linux-2.6.11.src/include/asm-i386/string.h Tue Apr 5 18:34:28 2005
@@ -316,8 +345,16 @@ __asm__ __volatile__(
return s;
}
-/* we might want to write optimized versions of these later */
-#define __constant_count_memset(s,c,count) __memset_generic((s),(c),(count))
+/*
+ * we might want to write optimized versions of this later
+ * for mow, just prevent common mistake of memset(a,c,0)
+ */
+void BUG_memset_with_zero_length(void);
+static inline void * __constant_count_memset(void * s, int c, size_t count)
+{
+ if(!count) BUG_memset_with_zero_length();
+ return __memset_generic(s,c,count);
+}
/*
* memset(x,0,y) is a reasonably common thing to do, so we want to fill
@@ -376,6 +413,7 @@ static inline void * __constant_c_and_co
{
switch (count) {
case 0:
+ BUG_memset_with_zero_length();
return s;
case 1:
*(unsigned char *)s = pattern;
Re: [PATCH 2.6.12-rc1-mm4] mips: update VR41xx CPU-PCI bridge support
Hello Andrew,
I received a comment from Mita-san.
On Tue, 5 Apr 2005 00:45:24 +0900
Yoichi Yuasa <[EMAIL PROTECTED]> wrote:
> This patch updates NEC VR4100 series CPU-PCI bridge support.
> This patch already had applied to Ralf's cvs.
>
> + if (request_mem_region(PCIU_BASE, PCIU_SIZE, "PCIU") == NULL)
> + return -EBUSY;
> +
> + pciu_base = ioremap(PCIU_BASE, PCIU_SIZE);
> + if (pciu_base == NULL)
> + return -EBUSY;
> +
I forgot to put release_mem_region() in here.
I update this patch.
Please apply new one.
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/pci/ops-vr41xx.c
rc1-mm4/arch/mips/pci/ops-vr41xx.c
--- rc1-mm4-orig/arch/mips/pci/ops-vr41xx.c Wed Mar 2 16:38:17 2005
+++ rc1-mm4/arch/mips/pci/ops-vr41xx.c Mon Apr 4 22:46:44 2005
@@ -3,7 +3,7 @@
*
* Copyright (C) 2001-2003 MontaVista Software Inc.
*Author: Yoichi Yuasa <[EMAIL PROTECTED] or [EMAIL PROTECTED]>
- * Copyright (C) 2004 Yoichi Yuasa <[EMAIL PROTECTED]>
+ * Copyright (C) 2004-2005 Yoichi Yuasa <[EMAIL PROTECTED]>
*
* 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
@@ -29,8 +29,8 @@
#include
-#define PCICONFDREGKSEG1ADDR(0x0f000c14)
-#define PCICONFAREGKSEG1ADDR(0x0f000c18)
+#define PCICONFDREG(void __iomem *)KSEG1ADDR(0x0f000c14)
+#define PCICONFAREG(void __iomem *)KSEG1ADDR(0x0f000c18)
static inline int set_pci_configuration_address(unsigned char number,
unsigned int devfn, int where)
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/pci/pci-vr41xx.c
rc1-mm4/arch/mips/pci/pci-vr41xx.c
--- rc1-mm4-orig/arch/mips/pci/pci-vr41xx.c Fri Apr 1 21:17:30 2005
+++ rc1-mm4/arch/mips/pci/pci-vr41xx.c Tue Apr 5 07:47:17 2005
@@ -3,8 +3,8 @@
*
* Copyright (C) 2001-2003 MontaVista Software Inc.
*Author: Yoichi Yuasa <[EMAIL PROTECTED] or [EMAIL PROTECTED]>
- * Copyright (C) 2004 Yoichi Yuasa <[EMAIL PROTECTED]>
- * Copyright (C) 2004 by Ralf Baechle ([EMAIL PROTECTED])
+ * Copyright (C) 2004-2005 Yoichi Yuasa <[EMAIL PROTECTED]>
+ * Copyright (C) 2004 by Ralf Baechle ([EMAIL PROTECTED])
*
* 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
@@ -31,12 +31,18 @@
#include
#include
+#include
#include
#include "pci-vr41xx.h"
extern struct pci_ops vr41xx_pci_ops;
+static void __iomem *pciu_base;
+
+#define pciu_read(offset) readl(pciu_base + (offset))
+#define pciu_write(offset, value) writel((value), pciu_base + (offset))
+
static struct pci_master_address_conversion pci_master_memory1 = {
.bus_base_address = PCI_MASTER_MEM1_BUS_BASE_ADDRESS,
.address_mask = PCI_MASTER_MEM1_ADDRESS_MASK,
@@ -113,6 +119,15 @@
setup = _pci_controller_unit_setup;
+ if (request_mem_region(PCIU_BASE, PCIU_SIZE, "PCIU") == NULL)
+ return -EBUSY;
+
+ pciu_base = ioremap(PCIU_BASE, PCIU_SIZE);
+ if (pciu_base == NULL) {
+ release_mem_region(PCIU_BASE, PCIU_SIZE);
+ return -EBUSY;
+ }
+
/* Disable PCI interrupt */
vr41xx_disable_pciint();
@@ -129,14 +144,14 @@
pci_clock_max = PCI_CLOCK_MAX;
vtclock = vr41xx_get_vtclock_frequency();
if (vtclock < pci_clock_max)
- writel(EQUAL_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, EQUAL_VTCLOCK);
else if ((vtclock / 2) < pci_clock_max)
- writel(HALF_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, HALF_VTCLOCK);
else if (current_cpu_data.processor_id >= PRID_VR4131_REV2_1 &&
(vtclock / 3) < pci_clock_max)
- writel(ONE_THIRD_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, ONE_THIRD_VTCLOCK);
else if ((vtclock / 4) < pci_clock_max)
- writel(QUARTER_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, QUARTER_VTCLOCK);
else {
printk(KERN_ERR "PCI Clock is over 33MHz.\n");
return -EINVAL;
@@ -151,11 +166,11 @@
MASTER_MSK(master->address_mask) |
WINEN |
PCIA(master->pci_base_address);
- writel(val, PCIMMAW1REG);
+ pciu_write(PCIMMAW1REG, val);
} else {
- val = readl(PCIMMAW1REG);
+ val = pciu_read(PCIMMAW1REG);
val &= ~WINEN;
- writel(val, PCIMMAW1REG);
+ pciu_write(PCIMMAW1REG, val);
}
if (setup->master_memory2 != NULL) {
@@ -164,11 +179,11 @@
MASTER_MSK(master->address_mask) |
WINEN |
[patch] inotify 0.22 for 2.6.12-rc1-mm4
On Mon, 2005-04-04 at 16:02 -0400, Robert Love wrote:
Greetings, Mr Morton.
> Below, find inotify 0.22, against 2.6.12-rc1.
>
> This release introduces a conversion in our primary locking from
> spinlocks to semaphores. Semaphores are a more natural fit for our
> code, which synchronizes with user-space, thus we clean up a bit of code
> with a net reduction of 63 lines. Also, I was able to remove the
> GFP_ATOMIC allocation.
>
> I did this as a bit of an experiment, not to fix any specific problem,
> and I now think it is the right way to go.
>
> This release also fixes a small bug in the coalescing code, which could
> of mistakenly dropped a move event. We now verify that the cookies
> match before coalescing.
And a patch for 2.6.12-rc1-mm4.
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says "the filesystem that the item
you were watching is on was unmounted."
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love <[EMAIL PROTECTED]>
Documentation/filesystems/inotify.txt | 81 ++
fs/Kconfig| 13
fs/Makefile |1
fs/attr.c | 33 -
fs/compat.c | 12
fs/file_table.c |3
fs/inode.c|6
fs/inotify.c | 979 ++
fs/namei.c| 30 -
fs/open.c |6
fs/read_write.c | 15
include/linux/fs.h|6
include/linux/fsnotify.h | 228 +++
include/linux/inotify.h | 113 +++
include/linux/sched.h |4
kernel/user.c |4
16 files changed, 1478 insertions(+), 56 deletions(-)
diff -urN linux-2.6.12-rc1-mm4/Documentation/filesystems/inotify.txt
linux/Documentation/filesystems/inotify.txt
--- linux-2.6.12-rc1-mm4/Documentation/filesystems/inotify.txt 1969-12-31
19:00:00.0 -0500
+++ linux/Documentation/filesystems/inotify.txt 2005-04-04 13:32:02.0
-0400
@@ -0,0 +1,81 @@
+ inotify
+a powerful yet simple file change notification system
+
+
+
+Document started 15 Mar 2005 by Robert Love <[EMAIL PROTECTED]>
+
+(i) User Interface
+
+Inotify is controlled by a device node, /dev/inotify. If you do not use udev,
+this device may need to be created manually. First step, open it
+
+ int dev_fd = open ("/dev/inotify", O_RDONLY);
+
+Change events are managed by "watches". A watch is an (object,mask) pair where
+the object is a file or directory and the mask is a bitmask of one or more
+inotify events that the application wishes to receive. See
+for valid events. A watch is referenced by a watch descriptor, or wd.
+
+Watches are added via a file descriptor.
+
+Watches on a directory will return events on any files inside of the directory.
+
+Adding a watch is simple,
+
+ /* 'wd' represents the watch on fd with mask */
+ struct inotify_request req = { fd, mask };
+ int wd = ioctl (dev_fd, INOTIFY_WATCH, );
+
+You can add a large number of files via something like
+
+ for each file to watch {
+ struct inotify_request req;
+ int file_fd;
+
+ file_fd = open (file, O_RDONLY);
+ if (fd < 0) {
+ perror ("open");
+ break;
+ }
+
+ req.fd = file_fd;
+ req.mask = mask;
+
+ wd = ioctl (dev_fd, INOTIFY_WATCH, );
+
+ close (fd);
+ }
+
+You can update an existing watch in the same manner, by passing in a new mask.
+
+An existing watch is removed via the INOTIFY_IGNORE ioctl, for example
+
+ ioctl (dev_fd, INOTIFY_IGNORE, wd);
+
+Events are provided in the f
Re: linux-2.6.12-rc1-mm4-RT-V0.7.42-08
On Mon, 2005-04-04 at 19:40 +0200, Ingo Molnar wrote:
> * Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > Hi Ingo,
> >
> > I need the following two patches to keep my system alive and avoid
> > the BUGs in the log send to you earlier (private mail).
>
> hm, the second patch does not apply (and the merge didnt look trivial) -
> maybe it depends on some patch in -mm that is not yet upstream?
>
I messed it up; apparently I type :wa to often and forgot to keep a
decent base file (yes I'm a vim user). I also seem to have gotten the
patch base dir wrong.
The two patches again; now hopefully with correct patch level and proper
base. They apply to my tree in order 2.6.12-rc1-icmp{,-rt}.patch.
Not ran nor compile tested on vanilla; just made then apply cleanly.
Could you please comment on the patches since I'm learning this stuff as
I go; and validation of my ideas would be most welcome. For instance;
was I right to convert the per cpu var __icmp_socket to a _LOCKED?
I think so since without the extra lock one could have race conditions
within the spin_trylock arguments double dereference.
Kind regards,
Peter Zijlstra
Since there is no lock held yet we are still preemptable; and since
icmp_socket is a per cpu variable switching cpus gives weird results.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-RT-V0.7.42-08/net/ipv4/icmp_base.c 2005-04-04 20:26:23.0 +0200
+++ linux-2.6.12-rc1-RT-V0.7.42-08/net/ipv4/icmp.c 2005-04-04 20:26:38.0 +0200
@@ -376,8 +376,8 @@
static void icmp_reply(struct icmp_bxm *icmp_param, struct sk_buff *skb)
{
- struct sock *sk = icmp_socket->sk;
- struct inet_sock *inet = inet_sk(sk);
+ struct sock *sk;
+ struct inet_sock *inet;
struct ipcm_cookie ipc;
struct rtable *rt = (struct rtable *)skb->dst;
u32 daddr;
@@ -388,6 +388,9 @@
if (icmp_xmit_lock())
return;
+ sk = icmp_socket->sk;
+ inet = inet_sk(sk);
+
icmp_param->data.icmph.checksum = 0;
icmp_out_count(icmp_param->data.icmph.type);
Since on PREEMPT_RT spinlocks allow preemption, it's possible to
change cpu at (almost) any point in time. Make sure we stick to
the per cpu variable we started with.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-RT-V0.7.42-08/net/ipv4/icmp_p1.c 2005-04-04 20:26:38.0 +0200
+++ linux-2.6.12-rc1-RT-V0.7.42-08/net/ipv4/icmp.c 2005-04-04 20:27:54.0 +0200
@@ -228,26 +228,32 @@
*
* On SMP we have one ICMP socket per-cpu.
*/
-static DEFINE_PER_CPU(struct socket *, __icmp_socket) = NULL;
-#define icmp_socket __get_cpu_var(__icmp_socket)
+static DEFINE_PER_CPU_LOCKED(struct socket *, __icmp_socket) = NULL;
-static __inline__ int icmp_xmit_lock(void)
+static __inline__ struct socket * icmp_xmit_lock(int cpu)
{
+ struct socket *icmp_socket;
+
local_bh_disable();
+ icmp_socket = get_cpu_var_locked(__icmp_socket, cpu);
if (unlikely(!spin_trylock(_socket->sk->sk_lock.slock))) {
/* This can happen if the output path signals a
* dst_link_failure() for an outgoing ICMP packet.
*/
+ put_cpu_var_locked(__icmp_socket, cpu);
local_bh_enable();
- return 1;
+ return NULL;
}
- return 0;
+
+ return icmp_socket;
}
-static void icmp_xmit_unlock(void)
+static void icmp_xmit_unlock(int cpu)
{
+ struct socket *icmp_socket = __get_cpu_var_locked(__icmp_socket, cpu);
spin_unlock_bh(_socket->sk->sk_lock.slock);
+ put_cpu_var_locked(__icmp_socket, cpu);
}
/*
@@ -344,7 +350,8 @@
}
static void icmp_push_reply(struct icmp_bxm *icmp_param,
- struct ipcm_cookie *ipc, struct rtable *rt)
+ struct ipcm_cookie *ipc, struct rtable *rt,
+struct socket *icmp_socket)
{
struct sk_buff *skb;
@@ -376,16 +383,19 @@
static void icmp_reply(struct icmp_bxm *icmp_param, struct sk_buff *skb)
{
+ struct socket *icmp_socket;
struct sock *sk;
struct inet_sock *inet;
struct ipcm_cookie ipc;
struct rtable *rt = (struct rtable *)skb->dst;
u32 daddr;
+ int cpu;
if (ip_options_echo(_param->replyopts, skb))
goto out;
- if (icmp_xmit_lock())
+ cpu = _smp_processor_id();
+ if (!(icmp_socket = icmp_xmit_lock(cpu)))
return;
sk = icmp_socket->sk;
@@ -413,10 +423,10 @@
}
if (icmpv4_xrlim_allow(rt, icmp_param->data.icmph.type,
icmp_param->data.icmph.code))
- icmp_push_reply(icmp_param, , rt);
+ icmp_push_reply(icmp_param, , rt, icmp_socket);
ip_rt_put(rt);
out_unlock:
- icmp_xmit_unlock();
+ icmp_xmit_unlock(cpu);
out:;
}
@@ -434,8 +444,9 @@
void icmp_send(struct sk_buff *skb_in, int type, int code, u32 info)
{
+ struct socket *icmp_socket;
struct iphdr *iph;
- int room;
+ int room, cpu;
struct icmp_bxm icmp_param;
struct rtable *rt = (struct rtable *)skb_in->dst;
struct ipcm_cookie ipc;
@@ -506,7 +517,8 @@
}
}
- if (icmp_xmit_lock())
+ cpu = _smp_processor_id();
+ if (!(icmp_socket = icmp_xmit_lock(cpu)))
return;
/*
@@ -579,11 +591,11 @@
icmp_param.data_len = room;
icmp_param.head_len = sizeof(struct
kernel BUG at fs/sysfs/symlink.c:87 on 2.6.12-rc1-mm4
Hi,
This just jumped on my dmesg. It happens when you take the usb
'network' cable out of the machine and then plug it back in. The usb0
interface is up.
On earlier kernels it just wouldn't accept the usb address given, but
on -mm4 this bug comes out.
This also has the side-effect of killing USB until reboot.
[ cut here ]
kernel BUG at fs/sysfs/symlink.c:87!
invalid operand: [#1]
PREEMPT
Modules linked in: usbnet ntfs nls_iso8859_1 nls_cp437 vfat fat sd_mod
usb_storage scsi_mod ipv6 eth1394 natsemi ohci1394 ieee1394 ehci_hcd
yenta_socket rsrc_nonstatic pcmcia_core 8250_pci 8250 serial_core
snd_ali5451 snd_ac97_codec snd_pcm snd_timer snd soundcore
snd_page_alloc ext3 jbd mbcache
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202 (2.6.12-rc1-mm4)
EIP is at sysfs_create_link+0x5f/0x69
eax: e8babf01 ebx: c710cbb4 ecx: edx: c8322600
esi: edi: c8322674 ebp: c4e09ebc esp: c1557d90
ds: 007b es: 007b ss: 0068
Process khubd (pid: 82, threadinfo=c1556000 task=c1496540)
Stack: c8322614 c8322674 c023cd37 c8322614 e0aabb80 c0260a9c de752da9
e0aa847e c0296ad1 4b87ad6e c4e09c00 c23eee00 c4e09e20
c4e09e20 e0aaa812 c4e09c06 c4e09c00 e0aaa0d2 de6f5664 c0169395 0286
Call Trace:
[] device_bind_driver+0x33/0x52
[] usb_driver_claim_interface+0x53/0x55
[] generic_cdc_bind+0xce/0x2be [usbnet]
[] alloc_netdev+0x70/0xa7
[] usbnet_probe+0x2ee/0x456 [usbnet]
[] d_lookup+0x19/0x39
[] sysfs_lookup+0x6f/0xc7
[] sysfs_new_dirent+0x25/0x72
[] usb_probe_interface+0x55/0x75
[] driver_probe_device+0x30/0x7f
[] __device_attach+0x5/0x8
[] bus_for_each_drv+0x39/0x57
[] dput+0x8a/0x284
[] device_attach+0x35/0x39
[] __device_attach+0x0/0x8
[] bus_add_device+0x2b/0x7b
[] device_add+0xbb/0x137
[] usb_set_configuration+0x2d9/0x45e
[] usb_new_device+0x91/0x1b1
[] check_highspeed+0x47/0xbd
[] hub_port_connect_change+0x1d4/0x3b3
[] hub_events+0x1de/0x3ad
[] hub_thread+0x35/0xf9
[] autoremove_wake_function+0x0/0x43
[] ret_from_fork+0x6/0x14
[] autoremove_wake_function+0x0/0x43
[] hub_thread+0x0/0xf9
[] kernel_thread_helper+0x5/0xb
Code: 00 89 f9 89 f2 89 d8 e8 f5 fe ff ff 8b 53 08 89 c1 ff 42 70 0f
8e 57 02 00 00 89 c8 8b 1c 24 8b 74 24 04 8b 7c 24 08 83 c4 0c c3 <0f>
0b 57 00 e2 bb 30 c0 eb c0 8b 40 30 e9 1b e6 ff ff 55 57 56
--
Carlos Martín http://www.cmartin.tk
"I'll wager it's the most extraordinary thing to happen round here
since Queen Elizabeth's handmaid got hit by lightning and sprouted a
beard"
-- T. C. Boyle, "Water Music"
-
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/
Re: linux-2.6.12-rc1-mm4-RT-V0.7.42-08
* Peter Zijlstra <[EMAIL PROTECTED]> wrote: > Hi Ingo, > > I need the following two patches to keep my system alive and avoid > the BUGs in the log send to you earlier (private mail). hm, the second patch does not apply (and the merge didnt look trivial) - maybe it depends on some patch in -mm that is not yet upstream? Ingo - 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/
[PATCH 2.6.12-rc1-mm4] mips: update VR41xx CPU-PCI bridge support
This patch updates NEC VR4100 series CPU-PCI bridge support.
This patch already had applied to Ralf's cvs.
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/pci/ops-vr41xx.c
rc1-mm4/arch/mips/pci/ops-vr41xx.c
--- rc1-mm4-orig/arch/mips/pci/ops-vr41xx.c Wed Mar 2 16:38:17 2005
+++ rc1-mm4/arch/mips/pci/ops-vr41xx.c Mon Apr 4 22:46:44 2005
@@ -3,7 +3,7 @@
*
* Copyright (C) 2001-2003 MontaVista Software Inc.
*Author: Yoichi Yuasa <[EMAIL PROTECTED] or [EMAIL PROTECTED]>
- * Copyright (C) 2004 Yoichi Yuasa <[EMAIL PROTECTED]>
+ * Copyright (C) 2004-2005 Yoichi Yuasa <[EMAIL PROTECTED]>
*
* 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
@@ -29,8 +29,8 @@
#include
-#define PCICONFDREGKSEG1ADDR(0x0f000c14)
-#define PCICONFAREGKSEG1ADDR(0x0f000c18)
+#define PCICONFDREG(void __iomem *)KSEG1ADDR(0x0f000c14)
+#define PCICONFAREG(void __iomem *)KSEG1ADDR(0x0f000c18)
static inline int set_pci_configuration_address(unsigned char number,
unsigned int devfn, int where)
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/pci/pci-vr41xx.c
rc1-mm4/arch/mips/pci/pci-vr41xx.c
--- rc1-mm4-orig/arch/mips/pci/pci-vr41xx.c Fri Apr 1 21:17:30 2005
+++ rc1-mm4/arch/mips/pci/pci-vr41xx.c Mon Apr 4 22:46:44 2005
@@ -3,8 +3,8 @@
*
* Copyright (C) 2001-2003 MontaVista Software Inc.
*Author: Yoichi Yuasa <[EMAIL PROTECTED] or [EMAIL PROTECTED]>
- * Copyright (C) 2004 Yoichi Yuasa <[EMAIL PROTECTED]>
- * Copyright (C) 2004 by Ralf Baechle ([EMAIL PROTECTED])
+ * Copyright (C) 2004-2005 Yoichi Yuasa <[EMAIL PROTECTED]>
+ * Copyright (C) 2004 by Ralf Baechle ([EMAIL PROTECTED])
*
* 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
@@ -31,12 +31,18 @@
#include
#include
+#include
#include
#include "pci-vr41xx.h"
extern struct pci_ops vr41xx_pci_ops;
+static void __iomem *pciu_base;
+
+#define pciu_read(offset) readl(pciu_base + (offset))
+#define pciu_write(offset, value) writel((value), pciu_base + (offset))
+
static struct pci_master_address_conversion pci_master_memory1 = {
.bus_base_address = PCI_MASTER_MEM1_BUS_BASE_ADDRESS,
.address_mask = PCI_MASTER_MEM1_ADDRESS_MASK,
@@ -113,6 +119,13 @@
setup = _pci_controller_unit_setup;
+ if (request_mem_region(PCIU_BASE, PCIU_SIZE, "PCIU") == NULL)
+ return -EBUSY;
+
+ pciu_base = ioremap(PCIU_BASE, PCIU_SIZE);
+ if (pciu_base == NULL)
+ return -EBUSY;
+
/* Disable PCI interrupt */
vr41xx_disable_pciint();
@@ -129,14 +142,14 @@
pci_clock_max = PCI_CLOCK_MAX;
vtclock = vr41xx_get_vtclock_frequency();
if (vtclock < pci_clock_max)
- writel(EQUAL_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, EQUAL_VTCLOCK);
else if ((vtclock / 2) < pci_clock_max)
- writel(HALF_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, HALF_VTCLOCK);
else if (current_cpu_data.processor_id >= PRID_VR4131_REV2_1 &&
(vtclock / 3) < pci_clock_max)
- writel(ONE_THIRD_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, ONE_THIRD_VTCLOCK);
else if ((vtclock / 4) < pci_clock_max)
- writel(QUARTER_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, QUARTER_VTCLOCK);
else {
printk(KERN_ERR "PCI Clock is over 33MHz.\n");
return -EINVAL;
@@ -151,11 +164,11 @@
MASTER_MSK(master->address_mask) |
WINEN |
PCIA(master->pci_base_address);
- writel(val, PCIMMAW1REG);
+ pciu_write(PCIMMAW1REG, val);
} else {
- val = readl(PCIMMAW1REG);
+ val = pciu_read(PCIMMAW1REG);
val &= ~WINEN;
- writel(val, PCIMMAW1REG);
+ pciu_write(PCIMMAW1REG, val);
}
if (setup->master_memory2 != NULL) {
@@ -164,11 +177,11 @@
MASTER_MSK(master->address_mask) |
WINEN |
PCIA(master->pci_base_address);
- writel(val, PCIMMAW2REG);
+ pciu_write(PCIMMAW2REG, val);
} else {
- val = readl(PCIMMAW2REG);
+ val = pciu_read(PCIMMAW2REG);
val &= ~WINEN;
- writel(val, PCIMMAW2REG);
+ pciu_write(PCIMMAW2REG, val);
}
if (setup->target_memory1 != NULL) {
@@ -176,11 +189,11 @@
val = TARGET_MSK(target->address_mask) |
WINEN |
Re: 2.6.12-rc1-mm4
On Thursday 31 March 2005 12:25, Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.
>6.12-rc1-mm4/
Hello Andrew,
I finally managed connecting the target machine over a serial console and run
gdb debugging session as explained in Documentation/i386/kgdb/kgdb.txt. This
time I think I'm in the right direction but ... Here's the output:
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...Using host libthread_db library
"/lib/tls/libthread_db.so.1".
breakpoint () at arch/i386/kernel/traps.c:128
128 }
warning: shared library handler failed to enable breakpoint
(gdb) list
123 set_intr_usr_gate(3,); /* disable ints on trap */
124 set_intr_gate(1,);
125 set_intr_gate(14,_fault);
126
127 BREAKPOINT;
128 }
129 #define CHK_REMOTE_DEBUG(trapnr,signr,error_code,regs,after)
\
130
{ \
131 if (!user_mode(regs) ) \
132
{ \
(gdb) s
kgdb_console_write (co=0xc03c8000, s=0x603d1c "k", count=6307100) at
arch/i386/kernel/kgdb_stub.c:2230
2230kgdb_gdb_message(s, count);
(gdb) s
kgdb_gdb_message (
s=0xc04e07c3 "[4294667.296000] Linux version 2.6.12-rc1-mm4 ([EMAIL
PROTECTED])
(gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 SMP PREEMPT Mon Apr 4 12:07:40
CEST 2005\n<6>[4294667.296000] BIOS-provided physical RAM map:\n<4>[4"...,
count=143) at arch/i386/kernel/kgdb_stub.c:2173
2173IF_SMP(in_kgdb_console = 1);
(gdb) s
2174gdbconbuf[0] = 'O';
(gdb) s
2175bufptr = gdbconbuf + 1;
(gdb) cont
Continuing.
[4294667.296000] Linux version 2.6.12-rc1-mm4 ([EMAIL PROTECTED]) (gcc version
3.3.5
(Debian 1:3.3.5-12)) #1 SMP PREEMPT Mon Apr 4 12:07:40 CEST 2005
[4294667.296000] BIOS-provided physical RAM map:
[4294667.296000] BIOS-e820: - 0009fc00 (usable)
[4294667.296000] BIOS-e820: 0009fc00 - 000a (reserved)
[4294667.296000] BIOS-e820: 000ce000 - 000d60ac (reserved)
[4294667.296000] BIOS-e820: 000f - 0010 (reserved)
[4294667.296000] BIOS-e820: 0010 - 1fff (usable)
[4294667.296000] BIOS-e820: 1fff - 1fff8000 (ACPI data)
[4294667.296000] BIOS-e820: 1fff8000 - 2000 (ACPI NVS)
[4294667.296000] BIOS-e820: fec0 - fec01000 (reserved)
[4294667.296000] BIOS-e820: fee0 - fee01000 (reserved)
[4294667.296000] BIOS-e820: ffb0 - ffc0 (reserved)
[4294667.296000] BIOS-e820: fff0 - 0001 (reserved)
[4294667.296000] 511MB LOWMEM available.
[4294667.296000] found SMP MP-table at 000fbad0
[4294667.296000] DMI 2.3 present.
[4294667.296000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[4294667.296000] Processor #0 15:2 APIC version 20
[4294667.296000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[4294667.296000] Processor #1 15:2 APIC version 20
[4294667.296000] Using ACPI for processor (LAPIC) configuration information
[4294667.296000] Intel MultiProcessor Specification v1.4
[4294667.296000] Virtual Wire compatibility mode.
[4294667.296000] OEM ID: INTELProduct ID: I845GL APIC at: 0xFEE0
[4294667.296000] I/O APIC #2 Version 32 at 0xFEC0.
[4294667.296000] Enabling APIC mode: Flat. Using 1 I/O APICs
[4294667.296000] Processors: 2
[4294667.296000] Allocating PCI resources starting at 2000 (gap:
2000:dec0)
[4294667.296000] Built 1 zonelists
[4294667.296000] Initializing CPU#0
[4294667.296000] Kernel command line: root=/dev/hda1 vga=0 kgdb console=kgdb
[4294667.296000] CPU 0 irqstacks, hard=c04d9000 soft=c04d7000
[4294667.296000] PID hash table entries: 2048 (order: 11, 32768 bytes)
[0.00] Detected 2606.669 MHz processor.
[ 108.755619] Using tsc for high-res timesource
[ 108.791515] Console: colour VGA+ 80x25
[ 108.817195] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[ 108.850172] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 108.892496] Memory: 514608k/524224k available (2444k kernel code, 9128k
reserved, 1269k data, 192k init, 0k highmem)
[ 108.932244] Checking if this processor honours the WP bit even in
supervisor mode... Ok.
[ 109.008290] Security Framework v1.0.0 initialized
[ 109.035947] Capability LSM initialized
[ 109.061900] Mount-cache hash table entries: 512
[ 109.089161]
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Hi Pavel! On Mon, 04 Apr 2005, Pavel Machek wrote: > I'd like to fix the problem, but first I need to know where the > problem is. If it works with minimal config, I know that it is one of > drivers you deselected. It's b44. It *was* working with b44 insmod-ed and up and running, but now as soon as b44-eth0 is ifup-ed while suspending, the resume freezes. If I do a ifdown eth0 before suspending, it works. Best wishes Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- PUDSEY (n.) The curious-shaped flat wads of dough left on a kitchen table after someone has been cutting scones out of it. --- Douglas Adams, The Meaning of Liff - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Hi Pavel! On Mon, 04 Apr 2005, Pavel Machek wrote: I'd like to fix the problem, but first I need to know where the problem is. If it works with minimal config, I know that it is one of drivers you deselected. It's b44. It *was* working with b44 insmod-ed and up and running, but now as soon as b44-eth0 is ifup-ed while suspending, the resume freezes. If I do a ifdown eth0 before suspending, it works. Best wishes Norbert --- Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- PUDSEY (n.) The curious-shaped flat wads of dough left on a kitchen table after someone has been cutting scones out of it. --- Douglas Adams, The Meaning of Liff - 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/
Re: 2.6.12-rc1-mm4
On Thursday 31 March 2005 12:25, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.
6.12-rc1-mm4/
snip
Hello Andrew,
I finally managed connecting the target machine over a serial console and run
gdb debugging session as explained in Documentation/i386/kgdb/kgdb.txt. This
time I think I'm in the right direction but ... Here's the output:
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-linux...Using host libthread_db library
/lib/tls/libthread_db.so.1.
breakpoint () at arch/i386/kernel/traps.c:128
128 }
warning: shared library handler failed to enable breakpoint
(gdb) list
123 set_intr_usr_gate(3,int3); /* disable ints on trap */
124 set_intr_gate(1,debug);
125 set_intr_gate(14,page_fault);
126
127 BREAKPOINT;
128 }
129 #define CHK_REMOTE_DEBUG(trapnr,signr,error_code,regs,after)
\
130
{ \
131 if (!user_mode(regs) ) \
132
{ \
(gdb) s
kgdb_console_write (co=0xc03c8000, s=0x603d1c k, count=6307100) at
arch/i386/kernel/kgdb_stub.c:2230
2230kgdb_gdb_message(s, count);
(gdb) s
kgdb_gdb_message (
s=0xc04e07c3 [4294667.296000] Linux version 2.6.12-rc1-mm4 ([EMAIL
PROTECTED])
(gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 SMP PREEMPT Mon Apr 4 12:07:40
CEST 2005\n6[4294667.296000] BIOS-provided physical RAM map:\n4[4...,
count=143) at arch/i386/kernel/kgdb_stub.c:2173
2173IF_SMP(in_kgdb_console = 1);
(gdb) s
2174gdbconbuf[0] = 'O';
(gdb) s
2175bufptr = gdbconbuf + 1;
(gdb) cont
Continuing.
[4294667.296000] Linux version 2.6.12-rc1-mm4 ([EMAIL PROTECTED]) (gcc version
3.3.5
(Debian 1:3.3.5-12)) #1 SMP PREEMPT Mon Apr 4 12:07:40 CEST 2005
[4294667.296000] BIOS-provided physical RAM map:
[4294667.296000] BIOS-e820: - 0009fc00 (usable)
[4294667.296000] BIOS-e820: 0009fc00 - 000a (reserved)
[4294667.296000] BIOS-e820: 000ce000 - 000d60ac (reserved)
[4294667.296000] BIOS-e820: 000f - 0010 (reserved)
[4294667.296000] BIOS-e820: 0010 - 1fff (usable)
[4294667.296000] BIOS-e820: 1fff - 1fff8000 (ACPI data)
[4294667.296000] BIOS-e820: 1fff8000 - 2000 (ACPI NVS)
[4294667.296000] BIOS-e820: fec0 - fec01000 (reserved)
[4294667.296000] BIOS-e820: fee0 - fee01000 (reserved)
[4294667.296000] BIOS-e820: ffb0 - ffc0 (reserved)
[4294667.296000] BIOS-e820: fff0 - 0001 (reserved)
[4294667.296000] 511MB LOWMEM available.
[4294667.296000] found SMP MP-table at 000fbad0
[4294667.296000] DMI 2.3 present.
[4294667.296000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[4294667.296000] Processor #0 15:2 APIC version 20
[4294667.296000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[4294667.296000] Processor #1 15:2 APIC version 20
[4294667.296000] Using ACPI for processor (LAPIC) configuration information
[4294667.296000] Intel MultiProcessor Specification v1.4
[4294667.296000] Virtual Wire compatibility mode.
[4294667.296000] OEM ID: INTELProduct ID: I845GL APIC at: 0xFEE0
[4294667.296000] I/O APIC #2 Version 32 at 0xFEC0.
[4294667.296000] Enabling APIC mode: Flat. Using 1 I/O APICs
[4294667.296000] Processors: 2
[4294667.296000] Allocating PCI resources starting at 2000 (gap:
2000:dec0)
[4294667.296000] Built 1 zonelists
[4294667.296000] Initializing CPU#0
[4294667.296000] Kernel command line: root=/dev/hda1 vga=0 kgdb console=kgdb
[4294667.296000] CPU 0 irqstacks, hard=c04d9000 soft=c04d7000
[4294667.296000] PID hash table entries: 2048 (order: 11, 32768 bytes)
[0.00] Detected 2606.669 MHz processor.
[ 108.755619] Using tsc for high-res timesource
[ 108.791515] Console: colour VGA+ 80x25
[ 108.817195] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[ 108.850172] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 108.892496] Memory: 514608k/524224k available (2444k kernel code, 9128k
reserved, 1269k data, 192k init, 0k highmem)
[ 108.932244] Checking if this processor honours the WP bit even in
supervisor mode... Ok.
[ 109.008290] Security Framework v1.0.0 initialized
[ 109.035947] Capability LSM initialized
[ 109.061900] Mount-cache hash table entries: 512
[ 109.089161] CPU: Trace cache: 12K uops, L1 D cache: 8K
[ 109.135687] CPU: L2 cache: 512K
[PATCH 2.6.12-rc1-mm4] mips: update VR41xx CPU-PCI bridge support
This patch updates NEC VR4100 series CPU-PCI bridge support.
This patch already had applied to Ralf's cvs.
Yoichi
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/pci/ops-vr41xx.c
rc1-mm4/arch/mips/pci/ops-vr41xx.c
--- rc1-mm4-orig/arch/mips/pci/ops-vr41xx.c Wed Mar 2 16:38:17 2005
+++ rc1-mm4/arch/mips/pci/ops-vr41xx.c Mon Apr 4 22:46:44 2005
@@ -3,7 +3,7 @@
*
* Copyright (C) 2001-2003 MontaVista Software Inc.
*Author: Yoichi Yuasa [EMAIL PROTECTED] or [EMAIL PROTECTED]
- * Copyright (C) 2004 Yoichi Yuasa [EMAIL PROTECTED]
+ * Copyright (C) 2004-2005 Yoichi Yuasa [EMAIL PROTECTED]
*
* 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
@@ -29,8 +29,8 @@
#include asm/io.h
-#define PCICONFDREGKSEG1ADDR(0x0f000c14)
-#define PCICONFAREGKSEG1ADDR(0x0f000c18)
+#define PCICONFDREG(void __iomem *)KSEG1ADDR(0x0f000c14)
+#define PCICONFAREG(void __iomem *)KSEG1ADDR(0x0f000c18)
static inline int set_pci_configuration_address(unsigned char number,
unsigned int devfn, int where)
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/pci/pci-vr41xx.c
rc1-mm4/arch/mips/pci/pci-vr41xx.c
--- rc1-mm4-orig/arch/mips/pci/pci-vr41xx.c Fri Apr 1 21:17:30 2005
+++ rc1-mm4/arch/mips/pci/pci-vr41xx.c Mon Apr 4 22:46:44 2005
@@ -3,8 +3,8 @@
*
* Copyright (C) 2001-2003 MontaVista Software Inc.
*Author: Yoichi Yuasa [EMAIL PROTECTED] or [EMAIL PROTECTED]
- * Copyright (C) 2004 Yoichi Yuasa [EMAIL PROTECTED]
- * Copyright (C) 2004 by Ralf Baechle ([EMAIL PROTECTED])
+ * Copyright (C) 2004-2005 Yoichi Yuasa [EMAIL PROTECTED]
+ * Copyright (C) 2004 by Ralf Baechle ([EMAIL PROTECTED])
*
* 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
@@ -31,12 +31,18 @@
#include asm/cpu.h
#include asm/io.h
+#include asm/vr41xx/pci.h
#include asm/vr41xx/vr41xx.h
#include pci-vr41xx.h
extern struct pci_ops vr41xx_pci_ops;
+static void __iomem *pciu_base;
+
+#define pciu_read(offset) readl(pciu_base + (offset))
+#define pciu_write(offset, value) writel((value), pciu_base + (offset))
+
static struct pci_master_address_conversion pci_master_memory1 = {
.bus_base_address = PCI_MASTER_MEM1_BUS_BASE_ADDRESS,
.address_mask = PCI_MASTER_MEM1_ADDRESS_MASK,
@@ -113,6 +119,13 @@
setup = vr41xx_pci_controller_unit_setup;
+ if (request_mem_region(PCIU_BASE, PCIU_SIZE, PCIU) == NULL)
+ return -EBUSY;
+
+ pciu_base = ioremap(PCIU_BASE, PCIU_SIZE);
+ if (pciu_base == NULL)
+ return -EBUSY;
+
/* Disable PCI interrupt */
vr41xx_disable_pciint();
@@ -129,14 +142,14 @@
pci_clock_max = PCI_CLOCK_MAX;
vtclock = vr41xx_get_vtclock_frequency();
if (vtclock pci_clock_max)
- writel(EQUAL_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, EQUAL_VTCLOCK);
else if ((vtclock / 2) pci_clock_max)
- writel(HALF_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, HALF_VTCLOCK);
else if (current_cpu_data.processor_id = PRID_VR4131_REV2_1
(vtclock / 3) pci_clock_max)
- writel(ONE_THIRD_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, ONE_THIRD_VTCLOCK);
else if ((vtclock / 4) pci_clock_max)
- writel(QUARTER_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, QUARTER_VTCLOCK);
else {
printk(KERN_ERR PCI Clock is over 33MHz.\n);
return -EINVAL;
@@ -151,11 +164,11 @@
MASTER_MSK(master-address_mask) |
WINEN |
PCIA(master-pci_base_address);
- writel(val, PCIMMAW1REG);
+ pciu_write(PCIMMAW1REG, val);
} else {
- val = readl(PCIMMAW1REG);
+ val = pciu_read(PCIMMAW1REG);
val = ~WINEN;
- writel(val, PCIMMAW1REG);
+ pciu_write(PCIMMAW1REG, val);
}
if (setup-master_memory2 != NULL) {
@@ -164,11 +177,11 @@
MASTER_MSK(master-address_mask) |
WINEN |
PCIA(master-pci_base_address);
- writel(val, PCIMMAW2REG);
+ pciu_write(PCIMMAW2REG, val);
} else {
- val = readl(PCIMMAW2REG);
+ val = pciu_read(PCIMMAW2REG);
val = ~WINEN;
- writel(val, PCIMMAW2REG);
+ pciu_write(PCIMMAW2REG, val);
}
if (setup-target_memory1 != NULL) {
@@ -176,11 +189,11 @@
val = TARGET_MSK(target-address_mask) |
Re: linux-2.6.12-rc1-mm4-RT-V0.7.42-08
* Peter Zijlstra [EMAIL PROTECTED] wrote: Hi Ingo, I need the following two patches to keep my system alive and avoid the BUGs in the log send to you earlier (private mail). hm, the second patch does not apply (and the merge didnt look trivial) - maybe it depends on some patch in -mm that is not yet upstream? Ingo - 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/
Re: linux-2.6.12-rc1-mm4-RT-V0.7.42-08
On Mon, 2005-04-04 at 19:40 +0200, Ingo Molnar wrote:
* Peter Zijlstra [EMAIL PROTECTED] wrote:
Hi Ingo,
I need the following two patches to keep my system alive and avoid
the BUGs in the log send to you earlier (private mail).
hm, the second patch does not apply (and the merge didnt look trivial) -
maybe it depends on some patch in -mm that is not yet upstream?
I messed it up; apparently I type :wa to often and forgot to keep a
decent base file (yes I'm a vim user). I also seem to have gotten the
patch base dir wrong.
The two patches again; now hopefully with correct patch level and proper
base. They apply to my tree in order 2.6.12-rc1-icmp{,-rt}.patch.
Not ran nor compile tested on vanilla; just made then apply cleanly.
Could you please comment on the patches since I'm learning this stuff as
I go; and validation of my ideas would be most welcome. For instance;
was I right to convert the per cpu var __icmp_socket to a _LOCKED?
I think so since without the extra lock one could have race conditions
within the spin_trylock arguments double dereference.
Kind regards,
Peter Zijlstra
Since there is no lock held yet we are still preemptable; and since
icmp_socket is a per cpu variable switching cpus gives weird results.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
--- linux-2.6.12-rc1-RT-V0.7.42-08/net/ipv4/icmp_base.c 2005-04-04 20:26:23.0 +0200
+++ linux-2.6.12-rc1-RT-V0.7.42-08/net/ipv4/icmp.c 2005-04-04 20:26:38.0 +0200
@@ -376,8 +376,8 @@
static void icmp_reply(struct icmp_bxm *icmp_param, struct sk_buff *skb)
{
- struct sock *sk = icmp_socket-sk;
- struct inet_sock *inet = inet_sk(sk);
+ struct sock *sk;
+ struct inet_sock *inet;
struct ipcm_cookie ipc;
struct rtable *rt = (struct rtable *)skb-dst;
u32 daddr;
@@ -388,6 +388,9 @@
if (icmp_xmit_lock())
return;
+ sk = icmp_socket-sk;
+ inet = inet_sk(sk);
+
icmp_param-data.icmph.checksum = 0;
icmp_out_count(icmp_param-data.icmph.type);
Since on PREEMPT_RT spinlocks allow preemption, it's possible to
change cpu at (almost) any point in time. Make sure we stick to
the per cpu variable we started with.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
--- linux-2.6.12-rc1-RT-V0.7.42-08/net/ipv4/icmp_p1.c 2005-04-04 20:26:38.0 +0200
+++ linux-2.6.12-rc1-RT-V0.7.42-08/net/ipv4/icmp.c 2005-04-04 20:27:54.0 +0200
@@ -228,26 +228,32 @@
*
* On SMP we have one ICMP socket per-cpu.
*/
-static DEFINE_PER_CPU(struct socket *, __icmp_socket) = NULL;
-#define icmp_socket __get_cpu_var(__icmp_socket)
+static DEFINE_PER_CPU_LOCKED(struct socket *, __icmp_socket) = NULL;
-static __inline__ int icmp_xmit_lock(void)
+static __inline__ struct socket * icmp_xmit_lock(int cpu)
{
+ struct socket *icmp_socket;
+
local_bh_disable();
+ icmp_socket = get_cpu_var_locked(__icmp_socket, cpu);
if (unlikely(!spin_trylock(icmp_socket-sk-sk_lock.slock))) {
/* This can happen if the output path signals a
* dst_link_failure() for an outgoing ICMP packet.
*/
+ put_cpu_var_locked(__icmp_socket, cpu);
local_bh_enable();
- return 1;
+ return NULL;
}
- return 0;
+
+ return icmp_socket;
}
-static void icmp_xmit_unlock(void)
+static void icmp_xmit_unlock(int cpu)
{
+ struct socket *icmp_socket = __get_cpu_var_locked(__icmp_socket, cpu);
spin_unlock_bh(icmp_socket-sk-sk_lock.slock);
+ put_cpu_var_locked(__icmp_socket, cpu);
}
/*
@@ -344,7 +350,8 @@
}
static void icmp_push_reply(struct icmp_bxm *icmp_param,
- struct ipcm_cookie *ipc, struct rtable *rt)
+ struct ipcm_cookie *ipc, struct rtable *rt,
+struct socket *icmp_socket)
{
struct sk_buff *skb;
@@ -376,16 +383,19 @@
static void icmp_reply(struct icmp_bxm *icmp_param, struct sk_buff *skb)
{
+ struct socket *icmp_socket;
struct sock *sk;
struct inet_sock *inet;
struct ipcm_cookie ipc;
struct rtable *rt = (struct rtable *)skb-dst;
u32 daddr;
+ int cpu;
if (ip_options_echo(icmp_param-replyopts, skb))
goto out;
- if (icmp_xmit_lock())
+ cpu = _smp_processor_id();
+ if (!(icmp_socket = icmp_xmit_lock(cpu)))
return;
sk = icmp_socket-sk;
@@ -413,10 +423,10 @@
}
if (icmpv4_xrlim_allow(rt, icmp_param-data.icmph.type,
icmp_param-data.icmph.code))
- icmp_push_reply(icmp_param, ipc, rt);
+ icmp_push_reply(icmp_param, ipc, rt, icmp_socket);
ip_rt_put(rt);
out_unlock:
- icmp_xmit_unlock();
+ icmp_xmit_unlock(cpu);
out:;
}
@@ -434,8 +444,9 @@
void icmp_send(struct sk_buff *skb_in, int type, int code, u32 info)
{
+ struct socket *icmp_socket;
struct iphdr *iph;
- int room;
+ int room, cpu;
struct icmp_bxm icmp_param;
struct rtable *rt = (struct rtable *)skb_in-dst;
struct ipcm_cookie ipc;
@@ -506,7 +517,8 @@
}
}
- if (icmp_xmit_lock())
+ cpu = _smp_processor_id();
+ if (!(icmp_socket = icmp_xmit_lock(cpu)))
return;
/*
@@ -579,11 +591,11 @@
icmp_param.data_len = room;
icmp_param.head_len = sizeof(struct icmphdr);
-
[patch] inotify 0.22 for 2.6.12-rc1-mm4
On Mon, 2005-04-04 at 16:02 -0400, Robert Love wrote:
Greetings, Mr Morton.
Below, find inotify 0.22, against 2.6.12-rc1.
This release introduces a conversion in our primary locking from
spinlocks to semaphores. Semaphores are a more natural fit for our
code, which synchronizes with user-space, thus we clean up a bit of code
with a net reduction of 63 lines. Also, I was able to remove the
GFP_ATOMIC allocation.
I did this as a bit of an experiment, not to fix any specific problem,
and I now think it is the right way to go.
This release also fixes a small bug in the coalescing code, which could
of mistakenly dropped a move event. We now verify that the cookies
match before coalescing.
And a patch for 2.6.12-rc1-mm4.
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user interface:
* dnotify requires the opening of one fd per each directory
that you intend to watch. This quickly results in too many
open files and pins removable media, preventing unmount.
* dnotify is directory-based. You only learn about changes to
directories. Sure, a change to a file in a directory affects
the directory, but you are then forced to keep a cache of
stat structures.
* dnotify's interface to user-space is awful. Signals?
inotify provides a more usable, simple, powerful solution to file change
notification:
* inotify's interface is a device node, not SIGIO. You open a
single fd to the device node, which is select()-able.
* inotify has an event that says the filesystem that the item
you were watching is on was unmounted.
* inotify can watch directories or files.
Inotify is currently used by Beagle (a desktop search infrastructure)
and Gamin (a FAM replacement).
Signed-off-by: Robert Love [EMAIL PROTECTED]
Documentation/filesystems/inotify.txt | 81 ++
fs/Kconfig| 13
fs/Makefile |1
fs/attr.c | 33 -
fs/compat.c | 12
fs/file_table.c |3
fs/inode.c|6
fs/inotify.c | 979 ++
fs/namei.c| 30 -
fs/open.c |6
fs/read_write.c | 15
include/linux/fs.h|6
include/linux/fsnotify.h | 228 +++
include/linux/inotify.h | 113 +++
include/linux/sched.h |4
kernel/user.c |4
16 files changed, 1478 insertions(+), 56 deletions(-)
diff -urN linux-2.6.12-rc1-mm4/Documentation/filesystems/inotify.txt
linux/Documentation/filesystems/inotify.txt
--- linux-2.6.12-rc1-mm4/Documentation/filesystems/inotify.txt 1969-12-31
19:00:00.0 -0500
+++ linux/Documentation/filesystems/inotify.txt 2005-04-04 13:32:02.0
-0400
@@ -0,0 +1,81 @@
+ inotify
+a powerful yet simple file change notification system
+
+
+
+Document started 15 Mar 2005 by Robert Love [EMAIL PROTECTED]
+
+(i) User Interface
+
+Inotify is controlled by a device node, /dev/inotify. If you do not use udev,
+this device may need to be created manually. First step, open it
+
+ int dev_fd = open (/dev/inotify, O_RDONLY);
+
+Change events are managed by watches. A watch is an (object,mask) pair where
+the object is a file or directory and the mask is a bitmask of one or more
+inotify events that the application wishes to receive. See linux/inotify.h
+for valid events. A watch is referenced by a watch descriptor, or wd.
+
+Watches are added via a file descriptor.
+
+Watches on a directory will return events on any files inside of the directory.
+
+Adding a watch is simple,
+
+ /* 'wd' represents the watch on fd with mask */
+ struct inotify_request req = { fd, mask };
+ int wd = ioctl (dev_fd, INOTIFY_WATCH, req);
+
+You can add a large number of files via something like
+
+ for each file to watch {
+ struct inotify_request req;
+ int file_fd;
+
+ file_fd = open (file, O_RDONLY);
+ if (fd 0) {
+ perror (open);
+ break;
+ }
+
+ req.fd = file_fd;
+ req.mask = mask;
+
+ wd = ioctl (dev_fd, INOTIFY_WATCH, req);
+
+ close (fd);
+ }
+
+You can update an existing watch in the same manner, by passing in a new mask.
+
+An existing watch is removed via the INOTIFY_IGNORE ioctl, for example
+
+ ioctl (dev_fd, INOTIFY_IGNORE, wd);
+
+Events are provided in the form of an inotify_event structure that is read(2)
+from /dev/inotify. The filename is of dynamic
Re: [PATCH 2.6.12-rc1-mm4] mips: update VR41xx CPU-PCI bridge support
Hello Andrew,
I received a comment from Mita-san.
On Tue, 5 Apr 2005 00:45:24 +0900
Yoichi Yuasa [EMAIL PROTECTED] wrote:
This patch updates NEC VR4100 series CPU-PCI bridge support.
This patch already had applied to Ralf's cvs.
snip
+ if (request_mem_region(PCIU_BASE, PCIU_SIZE, PCIU) == NULL)
+ return -EBUSY;
+
+ pciu_base = ioremap(PCIU_BASE, PCIU_SIZE);
+ if (pciu_base == NULL)
+ return -EBUSY;
+
I forgot to put release_mem_region() in here.
I update this patch.
Please apply new one.
Yoichi
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/pci/ops-vr41xx.c
rc1-mm4/arch/mips/pci/ops-vr41xx.c
--- rc1-mm4-orig/arch/mips/pci/ops-vr41xx.c Wed Mar 2 16:38:17 2005
+++ rc1-mm4/arch/mips/pci/ops-vr41xx.c Mon Apr 4 22:46:44 2005
@@ -3,7 +3,7 @@
*
* Copyright (C) 2001-2003 MontaVista Software Inc.
*Author: Yoichi Yuasa [EMAIL PROTECTED] or [EMAIL PROTECTED]
- * Copyright (C) 2004 Yoichi Yuasa [EMAIL PROTECTED]
+ * Copyright (C) 2004-2005 Yoichi Yuasa [EMAIL PROTECTED]
*
* 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
@@ -29,8 +29,8 @@
#include asm/io.h
-#define PCICONFDREGKSEG1ADDR(0x0f000c14)
-#define PCICONFAREGKSEG1ADDR(0x0f000c18)
+#define PCICONFDREG(void __iomem *)KSEG1ADDR(0x0f000c14)
+#define PCICONFAREG(void __iomem *)KSEG1ADDR(0x0f000c18)
static inline int set_pci_configuration_address(unsigned char number,
unsigned int devfn, int where)
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/pci/pci-vr41xx.c
rc1-mm4/arch/mips/pci/pci-vr41xx.c
--- rc1-mm4-orig/arch/mips/pci/pci-vr41xx.c Fri Apr 1 21:17:30 2005
+++ rc1-mm4/arch/mips/pci/pci-vr41xx.c Tue Apr 5 07:47:17 2005
@@ -3,8 +3,8 @@
*
* Copyright (C) 2001-2003 MontaVista Software Inc.
*Author: Yoichi Yuasa [EMAIL PROTECTED] or [EMAIL PROTECTED]
- * Copyright (C) 2004 Yoichi Yuasa [EMAIL PROTECTED]
- * Copyright (C) 2004 by Ralf Baechle ([EMAIL PROTECTED])
+ * Copyright (C) 2004-2005 Yoichi Yuasa [EMAIL PROTECTED]
+ * Copyright (C) 2004 by Ralf Baechle ([EMAIL PROTECTED])
*
* 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
@@ -31,12 +31,18 @@
#include asm/cpu.h
#include asm/io.h
+#include asm/vr41xx/pci.h
#include asm/vr41xx/vr41xx.h
#include pci-vr41xx.h
extern struct pci_ops vr41xx_pci_ops;
+static void __iomem *pciu_base;
+
+#define pciu_read(offset) readl(pciu_base + (offset))
+#define pciu_write(offset, value) writel((value), pciu_base + (offset))
+
static struct pci_master_address_conversion pci_master_memory1 = {
.bus_base_address = PCI_MASTER_MEM1_BUS_BASE_ADDRESS,
.address_mask = PCI_MASTER_MEM1_ADDRESS_MASK,
@@ -113,6 +119,15 @@
setup = vr41xx_pci_controller_unit_setup;
+ if (request_mem_region(PCIU_BASE, PCIU_SIZE, PCIU) == NULL)
+ return -EBUSY;
+
+ pciu_base = ioremap(PCIU_BASE, PCIU_SIZE);
+ if (pciu_base == NULL) {
+ release_mem_region(PCIU_BASE, PCIU_SIZE);
+ return -EBUSY;
+ }
+
/* Disable PCI interrupt */
vr41xx_disable_pciint();
@@ -129,14 +144,14 @@
pci_clock_max = PCI_CLOCK_MAX;
vtclock = vr41xx_get_vtclock_frequency();
if (vtclock pci_clock_max)
- writel(EQUAL_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, EQUAL_VTCLOCK);
else if ((vtclock / 2) pci_clock_max)
- writel(HALF_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, HALF_VTCLOCK);
else if (current_cpu_data.processor_id = PRID_VR4131_REV2_1
(vtclock / 3) pci_clock_max)
- writel(ONE_THIRD_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, ONE_THIRD_VTCLOCK);
else if ((vtclock / 4) pci_clock_max)
- writel(QUARTER_VTCLOCK, PCICLKSELREG);
+ pciu_write(PCICLKSELREG, QUARTER_VTCLOCK);
else {
printk(KERN_ERR PCI Clock is over 33MHz.\n);
return -EINVAL;
@@ -151,11 +166,11 @@
MASTER_MSK(master-address_mask) |
WINEN |
PCIA(master-pci_base_address);
- writel(val, PCIMMAW1REG);
+ pciu_write(PCIMMAW1REG, val);
} else {
- val = readl(PCIMMAW1REG);
+ val = pciu_read(PCIMMAW1REG);
val = ~WINEN;
- writel(val, PCIMMAW1REG);
+ pciu_write(PCIMMAW1REG, val);
}
if (setup-master_memory2 != NULL) {
@@ -164,11 +179,11 @@
MASTER_MSK(master-address_mask) |
WINEN |
Re: 2.6.12-rc1-mm4 crash while mounting a reiserfs3 filesystem
Andrew Morton a écrit : It appears that we might have jumped from flagged_taskfile into something at 0xdf6d1211, which is rather odd. You have two different low-level IDE drivers configured. Which one is driving that filesystem? VIA or Promise? hdg is connected to my Promise PDC20268 (Ultra100 TX2) -- Mathieu Bérard - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Hi! > it is only suspend2ram which stopped working after 2.6.11-mm4 (at least > in 2.6.12-rc1-mm3,4). > > Concerning tests with minimal kernel config: I guess since it *was* > working there should not be a change necessary -- but well, from > 2.6.11-mm2 to 2.6.11-mm4 I had to stop hotplug/usb to get ot working, so > maybe now I have to stop all the other things. G. This is not what I > want! > > Isn't there a different way? I'd like to fix the problem, but first I need to know where the problem is. If it works with minimal config, I know that it is one of drivers you deselected. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
On Fre, 01 Apr 2005, Pavel Machek wrote: > > I suspends fine, but never resumes. No CapsLock, no sysrq, no network is > > working. Nothing in the log files. Is there anything which may cause > > these troubles when compiled into the kernel and not loaded as module? > > (as it was with my usb stuff until 2.6.11-mm2, after this I had to stop > > hotplug, before I could go with usb running). > > Try suspend2disk, first, and try suspend2ram with minimal kernel > config. suspend2disk runs without any problem, even with X running. it is only suspend2ram which stopped working after 2.6.11-mm4 (at least in 2.6.12-rc1-mm3,4). Concerning tests with minimal kernel config: I guess since it *was* working there should not be a change necessary -- but well, from 2.6.11-mm2 to 2.6.11-mm4 I had to stop hotplug/usb to get ot working, so maybe now I have to stop all the other things. G. This is not what I want! Isn't there a different way? Best wishes Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- DORRIDGE (n.) Technical term for one of the lame excuses written in very small print on the side of packets of food or washing powder to explain why there's hardly anything inside. Examples include 'Contents may have settled in transit' and 'To keep each biscuit fresh they have been individually wrapped in silver paper and cellophane and separated with corrugated lining, a cardboard flap, and heavy industrial tyres'. --- Douglas Adams, The Meaning of Liff - 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/
Re: 2.6.12-rc1-mm4 crash while mounting a reiserfs3 filesystem
Mathieu Bérard <[EMAIL PROTECTED]> wrote: > > Hi, > I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4. > (Everyting run smoothly using 2.6.11-mm1) > It seems to be related with mounting a reiserfs3 filesystem. It looks more like an IDE bug. > ReiserFS: hdg1: checking transaction log (hdg1) > Unable to handle kernel paging request at virtual address 0a373138 > printing eip: > df6d1211 > *pde = > Oops: 0002 [#1] > PREEMPT > Modules linked in: ext2 mbcache w83627hf i2c_sensor i2c_isa ppp_generic > slhc w83627hf_wdt msr cpuid > rtc > CPU:0 > EIP: 0060:[]Not tainted VLI > EFLAGS: 00010202 (2.6.12-rc1-mm4) > EIP is at 0xdf6d1211 > eax: c9393266 ebx: df6d1c84 ecx: d84eab1e edx: c155ccf8 > esi: c039242c edi: c039239c ebp: 700d580a esp: df6d1c80 > ds: 007b es: 007b ss: 0068 > Process mount (pid: 1132, threadinfo=df6d1000 task=df711a50) > Stack: c039242c c0229945 c039239c df6d1000 df6d1000 c039242c c155ccf8 > c0223051 > 0088 1388 c159ae28 df6d1000 c039242c c155ccf8 c039239c > c022333e > df6d1d1c c153d6e0 c155bd78 df6d1d1c c14007f0 > c0212260 > Call Trace: > [] flagged_taskfile+0x125/0x380 > [] start_request+0x1f1/0x2a0 > [] ide_do_request+0x20e/0x3c0 > [] __generic_unplug_device+0x20/0x30 > [] generic_unplug_device+0x11/0x30 > [] blk_backing_dev_unplug+0xc/0x10 > [] sync_buffer+0x26/0x40 > [] __wait_on_bit+0x42/0x70 > [] sync_buffer+0x0/0x40 > [] sync_buffer+0x0/0x40 > [] out_of_line_wait_on_bit+0x7d/0x90 > [] wake_bit_function+0x0/0x60 > [] __wait_on_buffer+0x29/0x30 > [] _update_journal_header_block+0xf7/0x140 > [] journal_read+0x31d/0x470 > [] journal_init+0x4e1/0x650 > [] printk+0x1b/0x20 > [] reiserfs_fill_super+0x34d/0x770 > [] snprintf+0x20/0x30 > [] disk_name+0x96/0xf0 > [] get_sb_bdev+0xe5/0x130 > [] link_path_walk+0x65/0x140 > [] get_super_block+0x18/0x20 > [] reiserfs_fill_super+0x0/0x770 > [] do_kern_mount+0x44/0xf020 30 20 30 20 30 20 30 20 30 20 > 30 20 30 20 30 20 <1>general p It appears that we might have jumped from flagged_taskfile into something at 0xdf6d1211, which is rather odd. You have two different low-level IDE drivers configured. Which one is driving that filesystem? VIA or Promise? - 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/
2.6.12-rc1-mm4 crash while mounting a reiserfs3 filesystem
Hi, I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4. (Everyting run smoothly using 2.6.11-mm1) It seems to be related with mounting a reiserfs3 filesystem. Please also note that this kernel was compiled using gcc-4.0-0pre9 (from Debian) I'm using mount 2.12p Please CC: me. Here the OOPs (netconsole captured): input: AT Translated Set 2 keyboard on isa0060/serio0 ReiserFS: hda5: using ordered data mode ReiserFS: hda5: journal params: device hda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda5: checking transaction log (hda5) ReiserFS: hda5: Using r5 hash to sort names VFS: Mounted root (reiserfs filesystem) readonly. Freeing unused kernel memory: 136k freed Adding 497972k swap on /dev/hda6. Priority:-1 extents:1 reiserfs: enabling write barrier flush mode reiserfs: disabling flush barriers on hda5 Real Time Clock Driver v1.12 WDT driver for the Winbond(TM) W83627HF Super I/O chip initialising. w83627hf WDT: initialized. timeout=60 sec (nowayout=0) CSLIP: code copyright 1989 Regents of the University of California PPP generic driver version 2.4.2 ACPI: No ACPI bus support for 0-0290 ReiserFS: hda7: found reiserfs format "3.6" with standard journal ReiserFS: hda7: using ordered data mode reiserfs: using flush barriers ReiserFS: hda7: journal params: device hda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda7: checking transaction log (hda7) reiserfs: disabling flush barriers on hda7 ReiserFS: hda7: Using r5 hash to sort names ReiserFS: hda8: found reiserfs format "3.6" with standard journal ReiserFS: hda8: using ordered data mode reiserfs: using flush barriers ReiserFS: hda8: journal params: device hda8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda8: checking transaction log (hda8) reiserfs: disabling flush barriers on hda8 ReiserFS: hda8: Using r5 hash to sort names ReiserFS: hdg1: found reiserfs format "3.6" with standard journal ReiserFS: hdg1: using ordered data mode reiserfs: using flush barriers ReiserFS: hdg1: journal params: device hdg1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hdg1: checking transaction log (hdg1) Unable to handle kernel paging request at virtual address 0a373138 printing eip: df6d1211 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: ext2 mbcache w83627hf i2c_sensor i2c_isa ppp_generic slhc w83627hf_wdt msr cpuid rtc CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010202 (2.6.12-rc1-mm4) EIP is at 0xdf6d1211 eax: c9393266 ebx: df6d1c84 ecx: d84eab1e edx: c155ccf8 esi: c039242c edi: c039239c ebp: 700d580a esp: df6d1c80 ds: 007b es: 007b ss: 0068 Process mount (pid: 1132, threadinfo=df6d1000 task=df711a50) Stack: c039242c c0229945 c039239c df6d1000 df6d1000 c039242c c155ccf8 c0223051 0088 1388 c159ae28 df6d1000 c039242c c155ccf8 c039239c c022333e df6d1d1c c153d6e0 c155bd78 df6d1d1c c14007f0 c0212260 Call Trace: [] flagged_taskfile+0x125/0x380 [] start_request+0x1f1/0x2a0 [] ide_do_request+0x20e/0x3c0 [] __generic_unplug_device+0x20/0x30 [] generic_unplug_device+0x11/0x30 [] blk_backing_dev_unplug+0xc/0x10 [] sync_buffer+0x26/0x40 [] __wait_on_bit+0x42/0x70 [] sync_buffer+0x0/0x40 [] sync_buffer+0x0/0x40 [] out_of_line_wait_on_bit+0x7d/0x90 [] wake_bit_function+0x0/0x60 [] __wait_on_buffer+0x29/0x30 [] _update_journal_header_block+0xf7/0x140 [] journal_read+0x31d/0x470 [] journal_init+0x4e1/0x650 [] printk+0x1b/0x20 [] reiserfs_fill_super+0x34d/0x770 [] snprintf+0x20/0x30 [] disk_name+0x96/0xf0 [] get_sb_bdev+0xe5/0x130 [] link_path_walk+0x65/0x140 [] get_super_block+0x18/0x20 [] reiserfs_fill_super+0x0/0x770 [] do_kern_mount+0x44/0xf020 30 20 30 20 30 20 30 20 30 20 30 20 30 20 30 20 <1>general p rotection fault: [#2] PREEMPT Modules linked in: ext2 mbcache w83627hf i2c_sensor i2c_isa ppp_generic slhc w83627hf_wdt msr cpuid rtc CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010012 (2.6.12-rc1-mm4) EIP is at 0xdf6d1dae eax: df6d1d54 ebx: df6d1d1c ecx: edx: 0003 esi: df62190c edi: ebp: df7a3e80 esp: df7a3e60 ds: 007b es: 007b ss: 0068 Process fsck.reiserfs (pid: 1126, threadinfo=df7a3000 task=df711030) Stack: c0113849 df7a3ea8 0001 0003 c14007f0 df7a3000 df7a3ea8 0286 df7a3e9c c011389f df7a3ea8 c14007f0 c138be00 dfd36330 da0db42c c012c00a df7a3ea8 c138be00 0001 c0145b47 0054 000f Call Trace: [] __wake_up_common+0x39/0x60 [] __wake_up+0x2f/0x60 [] __wake_up_bit+0x2a/0x30 [] do_wp_page+0x1e7/0x340 [] handle_mm_fault+0x184/0x1c0 [] do_page_fault+0x268/0x657 [] free_pgtables+0x82/0xb0 [] unmap_region+0xb2/0x120 [] u
[PATCH 2.6.12-rc1-mm4] mips: remove obsolete VR41xx RTC function from vr41xx.h
This patch had removed obsolete VR41xx RTC function from vr41xx.h .
I forgot to put this change in "update VR41xx RTC support".
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff rc1-mm4-orig/include/asm-mips/vr41xx/vr41xx.h
rc1-mm4/include/asm-mips/vr41xx/vr41xx.h
--- rc1-mm4-orig/include/asm-mips/vr41xx/vr41xx.h Fri Apr 1 21:21:37 2005
+++ rc1-mm4/include/asm-mips/vr41xx/vr41xx.hSat Apr 2 19:26:58 2005
@@ -198,22 +198,6 @@
extern void vr41xx_disable_bcuint(void);
/*
- * Power Management Unit
- */
-
-/*
- * RTC
- */
-extern void vr41xx_set_rtclong1_cycle(uint32_t cycles);
-extern uint32_t vr41xx_read_rtclong1_counter(void);
-
-extern void vr41xx_set_rtclong2_cycle(uint32_t cycles);
-extern uint32_t vr41xx_read_rtclong2_counter(void);
-
-extern void vr41xx_set_tclock_cycle(uint32_t cycles);
-extern uint32_t vr41xx_read_tclock_counter(void);
-
-/*
* General-Purpose I/O Unit
*/
enum {
-
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/
[PATCH 2.6.12-rc1-mm4] mips: remove obsolete VR41xx RTC function from vr41xx.h
This patch had removed obsolete VR41xx RTC function from vr41xx.h .
I forgot to put this change in update VR41xx RTC support.
Yoichi
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
diff -urN -X dontdiff rc1-mm4-orig/include/asm-mips/vr41xx/vr41xx.h
rc1-mm4/include/asm-mips/vr41xx/vr41xx.h
--- rc1-mm4-orig/include/asm-mips/vr41xx/vr41xx.h Fri Apr 1 21:21:37 2005
+++ rc1-mm4/include/asm-mips/vr41xx/vr41xx.hSat Apr 2 19:26:58 2005
@@ -198,22 +198,6 @@
extern void vr41xx_disable_bcuint(void);
/*
- * Power Management Unit
- */
-
-/*
- * RTC
- */
-extern void vr41xx_set_rtclong1_cycle(uint32_t cycles);
-extern uint32_t vr41xx_read_rtclong1_counter(void);
-
-extern void vr41xx_set_rtclong2_cycle(uint32_t cycles);
-extern uint32_t vr41xx_read_rtclong2_counter(void);
-
-extern void vr41xx_set_tclock_cycle(uint32_t cycles);
-extern uint32_t vr41xx_read_tclock_counter(void);
-
-/*
* General-Purpose I/O Unit
*/
enum {
-
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/
2.6.12-rc1-mm4 crash while mounting a reiserfs3 filesystem
Hi, I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4. (Everyting run smoothly using 2.6.11-mm1) It seems to be related with mounting a reiserfs3 filesystem. Please also note that this kernel was compiled using gcc-4.0-0pre9 (from Debian) I'm using mount 2.12p Please CC: me. Here the OOPs (netconsole captured): input: AT Translated Set 2 keyboard on isa0060/serio0 ReiserFS: hda5: using ordered data mode ReiserFS: hda5: journal params: device hda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda5: checking transaction log (hda5) ReiserFS: hda5: Using r5 hash to sort names VFS: Mounted root (reiserfs filesystem) readonly. Freeing unused kernel memory: 136k freed Adding 497972k swap on /dev/hda6. Priority:-1 extents:1 reiserfs: enabling write barrier flush mode reiserfs: disabling flush barriers on hda5 Real Time Clock Driver v1.12 WDT driver for the Winbond(TM) W83627HF Super I/O chip initialising. w83627hf WDT: initialized. timeout=60 sec (nowayout=0) CSLIP: code copyright 1989 Regents of the University of California PPP generic driver version 2.4.2 ACPI: No ACPI bus support for 0-0290 ReiserFS: hda7: found reiserfs format 3.6 with standard journal ReiserFS: hda7: using ordered data mode reiserfs: using flush barriers ReiserFS: hda7: journal params: device hda7, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda7: checking transaction log (hda7) reiserfs: disabling flush barriers on hda7 ReiserFS: hda7: Using r5 hash to sort names ReiserFS: hda8: found reiserfs format 3.6 with standard journal ReiserFS: hda8: using ordered data mode reiserfs: using flush barriers ReiserFS: hda8: journal params: device hda8, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hda8: checking transaction log (hda8) reiserfs: disabling flush barriers on hda8 ReiserFS: hda8: Using r5 hash to sort names ReiserFS: hdg1: found reiserfs format 3.6 with standard journal ReiserFS: hdg1: using ordered data mode reiserfs: using flush barriers ReiserFS: hdg1: journal params: device hdg1, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 ReiserFS: hdg1: checking transaction log (hdg1) Unable to handle kernel paging request at virtual address 0a373138 printing eip: df6d1211 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: ext2 mbcache w83627hf i2c_sensor i2c_isa ppp_generic slhc w83627hf_wdt msr cpuid rtc CPU:0 EIP:0060:[df6d1211]Not tainted VLI EFLAGS: 00010202 (2.6.12-rc1-mm4) EIP is at 0xdf6d1211 eax: c9393266 ebx: df6d1c84 ecx: d84eab1e edx: c155ccf8 esi: c039242c edi: c039239c ebp: 700d580a esp: df6d1c80 ds: 007b es: 007b ss: 0068 Process mount (pid: 1132, threadinfo=df6d1000 task=df711a50) Stack: c039242c c0229945 c039239c df6d1000 df6d1000 c039242c c155ccf8 c0223051 0088 1388 c159ae28 df6d1000 c039242c c155ccf8 c039239c c022333e df6d1d1c c153d6e0 c155bd78 df6d1d1c c14007f0 c0212260 Call Trace: [c0229945] flagged_taskfile+0x125/0x380 [c0223051] start_request+0x1f1/0x2a0 [c022333e] ide_do_request+0x20e/0x3c0 [c0212260] __generic_unplug_device+0x20/0x30 [c0212281] generic_unplug_device+0x11/0x30 [c02122ac] blk_backing_dev_unplug+0xc/0x10 [c0156336] sync_buffer+0x26/0x40 [c02a0b22] __wait_on_bit+0x42/0x70 [c0156310] sync_buffer+0x0/0x40 [c0156310] sync_buffer+0x0/0x40 [c02a0bcd] out_of_line_wait_on_bit+0x7d/0x90 [c012bf80] wake_bit_function+0x0/0x60 [c01563c9] __wait_on_buffer+0x29/0x30 [c01b0dd7] _update_journal_header_block+0xf7/0x140 [c01b290d] journal_read+0x31d/0x470 [c01b3241] journal_init+0x4e1/0x650 [c011748b] printk+0x1b/0x20 [c01a3ced] reiserfs_fill_super+0x34d/0x770 [c01c9470] snprintf+0x20/0x30 [c0189ab6] disk_name+0x96/0xf0 [c015bf75] get_sb_bdev+0xe5/0x130 [c0163945] link_path_walk+0x65/0x140 [c01a4168] get_super_block+0x18/0x20 [c01a39a0] reiserfs_fill_super+0x0/0x770 [c015c194] do_kern_mount+0x44/0xf020 30 20 30 20 30 20 30 20 30 20 30 20 30 20 30 20 1general p rotection fault: [#2] PREEMPT Modules linked in: ext2 mbcache w83627hf i2c_sensor i2c_isa ppp_generic slhc w83627hf_wdt msr cpuid rtc CPU:0 EIP:0060:[df6d1dae]Not tainted VLI EFLAGS: 00010012 (2.6.12-rc1-mm4) EIP is at 0xdf6d1dae eax: df6d1d54 ebx: df6d1d1c ecx: edx: 0003 esi: df62190c edi: ebp: df7a3e80 esp: df7a3e60 ds: 007b es: 007b ss: 0068 Process fsck.reiserfs (pid: 1126, threadinfo=df7a3000 task=df711030) Stack: c0113849 df7a3ea8 0001 0003 c14007f0 df7a3000 df7a3ea8 0286 df7a3e9c c011389f df7a3ea8 c14007f0 c138be00 dfd36330 da0db42c c012c00a df7a3ea8 c138be00 0001 c0145b47 0054 000f Call Trace: [c0113849] __wake_up_common+0x39/0x60 [c011389f] __wake_up
Re: 2.6.12-rc1-mm4 crash while mounting a reiserfs3 filesystem
Mathieu Bérard [EMAIL PROTECTED] wrote: Hi, I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4. (Everyting run smoothly using 2.6.11-mm1) It seems to be related with mounting a reiserfs3 filesystem. It looks more like an IDE bug. ReiserFS: hdg1: checking transaction log (hdg1) Unable to handle kernel paging request at virtual address 0a373138 printing eip: df6d1211 *pde = Oops: 0002 [#1] PREEMPT Modules linked in: ext2 mbcache w83627hf i2c_sensor i2c_isa ppp_generic slhc w83627hf_wdt msr cpuid rtc CPU:0 EIP:0060:[df6d1211]Not tainted VLI EFLAGS: 00010202 (2.6.12-rc1-mm4) EIP is at 0xdf6d1211 eax: c9393266 ebx: df6d1c84 ecx: d84eab1e edx: c155ccf8 esi: c039242c edi: c039239c ebp: 700d580a esp: df6d1c80 ds: 007b es: 007b ss: 0068 Process mount (pid: 1132, threadinfo=df6d1000 task=df711a50) Stack: c039242c c0229945 c039239c df6d1000 df6d1000 c039242c c155ccf8 c0223051 0088 1388 c159ae28 df6d1000 c039242c c155ccf8 c039239c c022333e df6d1d1c c153d6e0 c155bd78 df6d1d1c c14007f0 c0212260 Call Trace: [c0229945] flagged_taskfile+0x125/0x380 [c0223051] start_request+0x1f1/0x2a0 [c022333e] ide_do_request+0x20e/0x3c0 [c0212260] __generic_unplug_device+0x20/0x30 [c0212281] generic_unplug_device+0x11/0x30 [c02122ac] blk_backing_dev_unplug+0xc/0x10 [c0156336] sync_buffer+0x26/0x40 [c02a0b22] __wait_on_bit+0x42/0x70 [c0156310] sync_buffer+0x0/0x40 [c0156310] sync_buffer+0x0/0x40 [c02a0bcd] out_of_line_wait_on_bit+0x7d/0x90 [c012bf80] wake_bit_function+0x0/0x60 [c01563c9] __wait_on_buffer+0x29/0x30 [c01b0dd7] _update_journal_header_block+0xf7/0x140 [c01b290d] journal_read+0x31d/0x470 [c01b3241] journal_init+0x4e1/0x650 [c011748b] printk+0x1b/0x20 [c01a3ced] reiserfs_fill_super+0x34d/0x770 [c01c9470] snprintf+0x20/0x30 [c0189ab6] disk_name+0x96/0xf0 [c015bf75] get_sb_bdev+0xe5/0x130 [c0163945] link_path_walk+0x65/0x140 [c01a4168] get_super_block+0x18/0x20 [c01a39a0] reiserfs_fill_super+0x0/0x770 [c015c194] do_kern_mount+0x44/0xf020 30 20 30 20 30 20 30 20 30 20 30 20 30 20 30 20 1general p It appears that we might have jumped from flagged_taskfile into something at 0xdf6d1211, which is rather odd. You have two different low-level IDE drivers configured. Which one is driving that filesystem? VIA or Promise? - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
On Fre, 01 Apr 2005, Pavel Machek wrote: I suspends fine, but never resumes. No CapsLock, no sysrq, no network is working. Nothing in the log files. Is there anything which may cause these troubles when compiled into the kernel and not loaded as module? (as it was with my usb stuff until 2.6.11-mm2, after this I had to stop hotplug, before I could go with usb running). Try suspend2disk, first, and try suspend2ram with minimal kernel config. suspend2disk runs without any problem, even with X running. it is only suspend2ram which stopped working after 2.6.11-mm4 (at least in 2.6.12-rc1-mm3,4). Concerning tests with minimal kernel config: I guess since it *was* working there should not be a change necessary -- but well, from 2.6.11-mm2 to 2.6.11-mm4 I had to stop hotplug/usb to get ot working, so maybe now I have to stop all the other things. G. This is not what I want! Isn't there a different way? Best wishes Norbert --- Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- DORRIDGE (n.) Technical term for one of the lame excuses written in very small print on the side of packets of food or washing powder to explain why there's hardly anything inside. Examples include 'Contents may have settled in transit' and 'To keep each biscuit fresh they have been individually wrapped in silver paper and cellophane and separated with corrugated lining, a cardboard flap, and heavy industrial tyres'. --- Douglas Adams, The Meaning of Liff - 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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Hi! it is only suspend2ram which stopped working after 2.6.11-mm4 (at least in 2.6.12-rc1-mm3,4). Concerning tests with minimal kernel config: I guess since it *was* working there should not be a change necessary -- but well, from 2.6.11-mm2 to 2.6.11-mm4 I had to stop hotplug/usb to get ot working, so maybe now I have to stop all the other things. G. This is not what I want! Isn't there a different way? I'd like to fix the problem, but first I need to know where the problem is. If it works with minimal config, I know that it is one of drivers you deselected. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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/
Re: 2.6.12-rc1-mm4 crash while mounting a reiserfs3 filesystem
Andrew Morton a écrit : It appears that we might have jumped from flagged_taskfile into something at 0xdf6d1211, which is rather odd. You have two different low-level IDE drivers configured. Which one is driving that filesystem? VIA or Promise? hdg is connected to my Promise PDC20268 (Ultra100 TX2) -- Mathieu Bérard - 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/
Re: linux-2.6.12-rc1-mm4-RT-V0.7.42-08
Hi Ingo,
I need the following two patches to keep my system alive and avoid
the BUGs in the log send to you earlier (private mail).
--- example BUG
BUG: using smp_processor_id() in preemptible [0001] code: java/16460
caller is icmp_send+0x9b/0x3d0
[] smp_processor_id+0x9b/0xb0 (8)
[] icmp_send+0x9b/0x3d0 (28)
[] check_wakeup_timing+0x47/0x160 (8)
[] _raw_spin_unlock+0xd/0x30 (40)
[] kmem_cache_free+0x39/0x120 (8)
[] _raw_spin_unlock+0xd/0x30 (12)
[] kmem_cache_free+0x39/0x120 (8)
[] _raw_spin_unlock+0xd/0x30 (24)
[] _raw_spin_unlock+0xd/0x30 (28)
[] rtl8139_start_xmit+0x86/0x1d0 (8)
[] _raw_spin_unlock+0xd/0x30 (40)
[] qdisc_restart+0x1b9/0x230 (8)
[] qdisc_restart+0x1b9/0x230 (36)
[] _raw_spin_unlock+0xd/0x30 (8)
[] rtl8139_start_xmit+0xce/0x1d0 (16)
[] _raw_spin_unlock+0xd/0x30 (32)
[] ip_fragment+0x663/0x7f0 (60)
[] rcu_read_unlock+0x5f/0x70 (32)
[] __ip_route_output_key+0xba/0xe0 (8)
[] ip_finish_output+0x0/0x2f0 (16)
[] ip_queue_xmit+0x263/0x590 (24)
[] ip_queue_xmit+0x263/0x590 (20)
[] tcp_transmit_skb+0x38b/0x750 (196)
[] tcp_write_xmit+0x10e/0x2f0 (56)
[] tcp_sendmsg+0xffb/0x1050 (52)
[] _raw_spin_unlock+0xd/0x30 (12)
[] unqueue_me+0x25/0x130 (8)
[] inet_sendmsg+0x4a/0x70 (92)
[] sock_aio_write+0x135/0x150 (24)
[] _raw_spin_unlock+0xd/0x30 (88)
[] do_sync_write+0xb9/0x110 (20)
[] _raw_spin_unlock+0xd/0x30 (44)
[] fget_light+0x62/0x90 (8)
[] _raw_spin_unlock+0xd/0x30 (44)
[] autoremove_wake_function+0x0/0x50 (8)
[] vfs_write+0xdb/0x170 (52)
[] sys_write+0x41/0x70 (24)
[] sysenter_past_esp+0x54/0x75 (28)
---
| preempt count: 0002 ]
| 2-level deep critical section nesting:
.. [] _raw_spin_lock+0x16/0x90
.[<>] .. ( <= 0x0)
.. [] _raw_spin_lock+0x16/0x90
.[<>] .. ( <= 0x0)
--
Peter Zijlstra <[EMAIL PROTECTED]>
Since there is no lock held yet we are still preemptable; and since
icmp_socket is a per cpu variable switching cpus gives weird results.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
--- /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp.c~ 2005-03-25 10:14:32.0 +0100
+++ /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp.c 2005-04-02 18:58:19.0 +0200
@@ -376,8 +376,8 @@
static void icmp_reply(struct icmp_bxm *icmp_param, struct sk_buff *skb)
{
- struct sock *sk = icmp_socket->sk;
- struct inet_sock *inet = inet_sk(sk);
+ struct sock *sk;
+ struct inet_sock *inet;
struct ipcm_cookie ipc;
struct rtable *rt = (struct rtable *)skb->dst;
u32 daddr;
@@ -388,6 +388,9 @@
if (icmp_xmit_lock())
return;
+ sk = icmp_socket->sk;
+ inet = inet_sk(sk);
+
icmp_param->data.icmph.checksum = 0;
icmp_out_count(icmp_param->data.icmph.type);
Since on PREEMPT_RT spinlocks allow preemption, it's possible to
change cpu at (almost) any point in time. Make sure we stick to
the per cpu variable we started with.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
--- /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp_orig.c 2005-04-03 00:09:08.0 +0200
+++ /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp.c 2005-04-03 00:20:22.0 +0200
@@ -228,27 +228,32 @@
*
* On SMP we have one ICMP socket per-cpu.
*/
-static DEFINE_PER_CPU(struct socket *, __icmp_socket) = NULL;
-#define icmp_socket __get_cpu_var(__icmp_socket)
+static DEFINE_PER_CPU_LOCKED(struct socket *, __icmp_socket) = NULL;
static __inline__ struct socket * icmp_xmit_lock(int cpu)
{
+ struct socket *icmp_socket;
+
local_bh_disable();
+ icmp_socket = get_cpu_var_locked(__icmp_socket, cpu);
if (unlikely(!spin_trylock(_socket->sk->sk_lock.slock))) {
/* This can happen if the output path signals a
* dst_link_failure() for an outgoing ICMP packet.
*/
+ put_cpu_var_locked(__icmp_socket, cpu);
local_bh_enable();
- return 1;
+ return NULL;
}
- return 0;
+ return icmp_socket;
}
static void icmp_xmit_unlock(int cpu)
{
+ struct socket *icmp_socket = __get_cpu_var_locked(__icmp_socket, cpu);
spin_unlock_bh(_socket->sk->sk_lock.slock);
+ put_cpu_var_locked(__icmp_socket, cpu);
}
/*
@@ -345,7 +350,8 @@
}
static void icmp_push_reply(struct icmp_bxm *icmp_param,
- struct ipcm_cookie *ipc, struct rtable *rt)
+ struct ipcm_cookie *ipc, struct rtable *rt,
+struct socket *icmp_socket)
{
struct sk_buff *skb;
@@ -377,16 +383,19 @@
static void icmp_reply(struct icmp_bxm *icmp_param, struct sk_buff *skb)
{
+ struct socket *icmp_socket;
struct sock *sk;
struct inet_sock *inet;
struct ipcm_cookie ipc;
struct rtable *rt = (struct rtable *)skb->dst;
u32 daddr;
+ int cpu;
if (ip_options_echo(_param->replyopts, skb))
goto out;
- if (icmp_xmit_lock())
+ cpu = _smp_processor_id();
+ if (!(icmp_socket = icmp_xmit_lock(cpu)))
return;
sk = i
Re: [2.6.12-rc1-mm4] swapped memset arguments
On Sat, 2 Apr 2005, Maciej Soltysiak wrote: > Hi, > > out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments. > I found one: > > # grep -nr "memset.*\,\(\ \|\)0\(\ \|\));" * > net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct > ieee80211_txb), 0); > And here's a patch : Fix swapped memset() arguments in net/ieee80211/ieee80211_tx.c found by Maciej Soltysiak. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- linux-2.6.12-rc1-mm4-orig/net/ieee80211/ieee80211_tx.c 2005-03-31 21:20:08.0 +0200 +++ linux-2.6.12-rc1-mm4/net/ieee80211/ieee80211_tx.c 2005-04-03 00:34:22.0 +0200 @@ -223,7 +223,7 @@ struct ieee80211_txb *ieee80211_alloc_tx if (!txb) return NULL; - memset(txb, sizeof(struct ieee80211_txb), 0); + memset(txb, 0, sizeof(struct ieee80211_txb)); txb->nr_frags = nr_frags; txb->frag_size = txb_size; - 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/
[2.6.12-rc1-mm4] swapped memset arguments
Hi, out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments. I found one: # grep -nr "memset.*\,\(\ \|\)0\(\ \|\));" * net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct ieee80211_txb), 0); I found none in Linus' bk. Regards, Maciej - 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/
Re: 2.6.12-rc1-mm4: oops in sysfs/symlink.c
Howdy, I get the following oops when I switch a Logitech USB Bluetooth Hub into HCI mode (hid2hci utility): usb 1-2.1.1: new low speed USB device using uhci_hcd and address 5 input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-:00:04.2-2.1.1 hiddev0: USB HID v1.10 Device [Logitech USB Receiver] on usb-:00:04.2-2.1.1 run hid2hci: usb 1-2.1.2: new full speed USB device using uhci_hcd and address 6 [ cut here ] kernel BUG at fs/sysfs/symlink.c:87! invalid operand: [#1] Modules linked in: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010202 (2.6.12-rc1-mm4) EIP is at sysfs_create_link+0x60/0x70 eax: d5fdba01 ebx: d78182ac ecx: edx: d5b8b201 esi: edi: d5b8b274 ebp: d65003e0 esp: d7e9adb8 ds: 007b es: 007b ss: 0068 Process khubd (pid: 23, threadinfo=d7e9a000 task=d7e99a50) Stack: d5b8b214 d5b8b274 0002 c0279163 d5b8b214 c0458840 c02e6cd7 0002 d76112e0 c0314d27 d7ff8b70 d7ff414c 0005 00d0 d76112d0 0002 0292 d65004c0 d65004a0 0002 0011 d5b8b200 d71517e0 Call Trace: [] device_bind_driver+0x33/0x60 [] usb_driver_claim_interface+0x57/0x60 [] hci_usb_probe+0x477/0x560 [] usb_probe_interface+0x58/0x80 [] driver_probe_device+0x30/0x90 [] __device_attach+0x5/0x10 [] bus_for_each_drv+0x3a/0x60 [] populate_dir+0x3d/0x60 [] device_attach+0x36/0x40 [] __device_attach+0x0/0x10 [] bus_add_device+0x2b/0x80 [] device_add+0xb1/0x150 [] usb_set_configuration+0x2e0/0x470 [] usb_new_device+0x91/0x1c0 [] hub_port_connect_change+0x19f/0x360 [] hub_events+0x1bd/0x360 [] sigprocmask+0x4c/0xc0 [] hub_thread+0x45/0x100 [] autoremove_wake_function+0x0/0x50 [] ret_from_fork+0x6/0x14 [] autoremove_wake_function+0x0/0x50 [] hub_thread+0x0/0x100 [] kernel_thread_helper+0x5/0x18 Code: 89 f9 89 f2 89 d8 e8 f0 fe ff ff 89 c1 8b 53 08 ff 42 70 0f 8e 35 02 00 00 8b 1c 24 89 c8 8b 74 24 04 8b 7c 24 08 83 c4 0c c3 90 <0f> 0b 57 00 f4 f6 3d c0 eb bf 8d b6 00 00 00 00 8b 40 30 e9 c8 -mm3 works fine, I'll try to find the culprit patch... Thanks, -- Manuel Lauss - 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/
Re: 2.6.12-rc1-mm4: oops in sysfs/symlink.c
Howdy, I get the following oops when I switch a Logitech USB Bluetooth Hub into HCI mode (hid2hci utility): usb 1-2.1.1: new low speed USB device using uhci_hcd and address 5 input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-:00:04.2-2.1.1 hiddev0: USB HID v1.10 Device [Logitech USB Receiver] on usb-:00:04.2-2.1.1 run hid2hci: usb 1-2.1.2: new full speed USB device using uhci_hcd and address 6 [ cut here ] kernel BUG at fs/sysfs/symlink.c:87! invalid operand: [#1] Modules linked in: CPU:0 EIP:0060:[c017afb0]Not tainted VLI EFLAGS: 00010202 (2.6.12-rc1-mm4) EIP is at sysfs_create_link+0x60/0x70 eax: d5fdba01 ebx: d78182ac ecx: edx: d5b8b201 esi: edi: d5b8b274 ebp: d65003e0 esp: d7e9adb8 ds: 007b es: 007b ss: 0068 Process khubd (pid: 23, threadinfo=d7e9a000 task=d7e99a50) Stack: d5b8b214 d5b8b274 0002 c0279163 d5b8b214 c0458840 c02e6cd7 0002 d76112e0 c0314d27 d7ff8b70 d7ff414c 0005 00d0 d76112d0 0002 0292 d65004c0 d65004a0 0002 0011 d5b8b200 d71517e0 Call Trace: [c0279163] device_bind_driver+0x33/0x60 [c02e6cd7] usb_driver_claim_interface+0x57/0x60 [c0314d27] hci_usb_probe+0x477/0x560 [c02e6a38] usb_probe_interface+0x58/0x80 [c02791c0] driver_probe_device+0x30/0x90 [c0279225] __device_attach+0x5/0x10 [c02789ca] bus_for_each_drv+0x3a/0x60 [c0210a8d] populate_dir+0x3d/0x60 [c0279266] device_attach+0x36/0x40 [c0279220] __device_attach+0x0/0x10 [c0278b4b] bus_add_device+0x2b/0x80 [c0277d81] device_add+0xb1/0x150 [c02ee3f0] usb_set_configuration+0x2e0/0x470 [c02e90e1] usb_new_device+0x91/0x1c0 [c02ea02f] hub_port_connect_change+0x19f/0x360 [c02ea3ad] hub_events+0x1bd/0x360 [c011c91c] sigprocmask+0x4c/0xc0 [c02ea595] hub_thread+0x45/0x100 [c0124340] autoremove_wake_function+0x0/0x50 [c0102812] ret_from_fork+0x6/0x14 [c0124340] autoremove_wake_function+0x0/0x50 [c02ea550] hub_thread+0x0/0x100 [c0100d5d] kernel_thread_helper+0x5/0x18 Code: 89 f9 89 f2 89 d8 e8 f0 fe ff ff 89 c1 8b 53 08 ff 42 70 0f 8e 35 02 00 00 8b 1c 24 89 c8 8b 74 24 04 8b 7c 24 08 83 c4 0c c3 90 0f 0b 57 00 f4 f6 3d c0 eb bf 8d b6 00 00 00 00 8b 40 30 e9 c8 -mm3 works fine, I'll try to find the culprit patch... Thanks, -- Manuel Lauss - 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/
[2.6.12-rc1-mm4] swapped memset arguments
Hi, out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments. I found one: # grep -nr memset.*\,\(\ \|\)0\(\ \|\)); * net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct ieee80211_txb), 0); I found none in Linus' bk. Regards, Maciej - 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/
Re: [2.6.12-rc1-mm4] swapped memset arguments
On Sat, 2 Apr 2005, Maciej Soltysiak wrote: Hi, out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments. I found one: # grep -nr memset.*\,\(\ \|\)0\(\ \|\)); * net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct ieee80211_txb), 0); And here's a patch : Fix swapped memset() arguments in net/ieee80211/ieee80211_tx.c found by Maciej Soltysiak. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- linux-2.6.12-rc1-mm4-orig/net/ieee80211/ieee80211_tx.c 2005-03-31 21:20:08.0 +0200 +++ linux-2.6.12-rc1-mm4/net/ieee80211/ieee80211_tx.c 2005-04-03 00:34:22.0 +0200 @@ -223,7 +223,7 @@ struct ieee80211_txb *ieee80211_alloc_tx if (!txb) return NULL; - memset(txb, sizeof(struct ieee80211_txb), 0); + memset(txb, 0, sizeof(struct ieee80211_txb)); txb-nr_frags = nr_frags; txb-frag_size = txb_size; - 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/
Re: linux-2.6.12-rc1-mm4-RT-V0.7.42-08
Hi Ingo,
I need the following two patches to keep my system alive and avoid
the BUGs in the log send to you earlier (private mail).
--- example BUG
BUG: using smp_processor_id() in preemptible [0001] code: java/16460
caller is icmp_send+0x9b/0x3d0
[c020b1db] smp_processor_id+0x9b/0xb0 (8)
[c032246b] icmp_send+0x9b/0x3d0 (28)
[c013ae67] check_wakeup_timing+0x47/0x160 (8)
[c034269d] _raw_spin_unlock+0xd/0x30 (40)
[c014d159] kmem_cache_free+0x39/0x120 (8)
[c034269d] _raw_spin_unlock+0xd/0x30 (12)
[c014d159] kmem_cache_free+0x39/0x120 (8)
[c034269d] _raw_spin_unlock+0xd/0x30 (24)
[c034269d] _raw_spin_unlock+0xd/0x30 (28)
[c0276066] rtl8139_start_xmit+0x86/0x1d0 (8)
[c034269d] _raw_spin_unlock+0xd/0x30 (40)
[c02f3259] qdisc_restart+0x1b9/0x230 (8)
[c02f3259] qdisc_restart+0x1b9/0x230 (36)
[c034269d] _raw_spin_unlock+0xd/0x30 (8)
[c02760ae] rtl8139_start_xmit+0xce/0x1d0 (16)
[c034269d] _raw_spin_unlock+0xd/0x30 (32)
[c02ffe33] ip_fragment+0x663/0x7f0 (60)
[c013138f] rcu_read_unlock+0x5f/0x70 (32)
[c02f9d2a] __ip_route_output_key+0xba/0xe0 (8)
[c02fe950] ip_finish_output+0x0/0x2f0 (16)
[c02ff383] ip_queue_xmit+0x263/0x590 (24)
[c02ff383] ip_queue_xmit+0x263/0x590 (20)
[c03102eb] tcp_transmit_skb+0x38b/0x750 (196)
[c031113e] tcp_write_xmit+0x10e/0x2f0 (56)
[c03054ab] tcp_sendmsg+0xffb/0x1050 (52)
[c034269d] _raw_spin_unlock+0xd/0x30 (12)
[c013b9c5] unqueue_me+0x25/0x130 (8)
[c0325f4a] inet_sendmsg+0x4a/0x70 (92)
[c02dd795] sock_aio_write+0x135/0x150 (24)
[c034269d] _raw_spin_unlock+0xd/0x30 (88)
[c0163c69] do_sync_write+0xb9/0x110 (20)
[c034269d] _raw_spin_unlock+0xd/0x30 (44)
[c0164d52] fget_light+0x62/0x90 (8)
[c034269d] _raw_spin_unlock+0xd/0x30 (44)
[c0134c50] autoremove_wake_function+0x0/0x50 (8)
[c0163d9b] vfs_write+0xdb/0x170 (52)
[c0163ee1] sys_write+0x41/0x70 (24)
[c0102f0b] sysenter_past_esp+0x54/0x75 (28)
---
| preempt count: 0002 ]
| 2-level deep critical section nesting:
.. [c03422e6] _raw_spin_lock+0x16/0x90
.[] .. ( = 0x0)
.. [c03422e6] _raw_spin_lock+0x16/0x90
.[] .. ( = 0x0)
--
Peter Zijlstra [EMAIL PROTECTED]
Since there is no lock held yet we are still preemptable; and since
icmp_socket is a per cpu variable switching cpus gives weird results.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
--- /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp.c~ 2005-03-25 10:14:32.0 +0100
+++ /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp.c 2005-04-02 18:58:19.0 +0200
@@ -376,8 +376,8 @@
static void icmp_reply(struct icmp_bxm *icmp_param, struct sk_buff *skb)
{
- struct sock *sk = icmp_socket-sk;
- struct inet_sock *inet = inet_sk(sk);
+ struct sock *sk;
+ struct inet_sock *inet;
struct ipcm_cookie ipc;
struct rtable *rt = (struct rtable *)skb-dst;
u32 daddr;
@@ -388,6 +388,9 @@
if (icmp_xmit_lock())
return;
+ sk = icmp_socket-sk;
+ inet = inet_sk(sk);
+
icmp_param-data.icmph.checksum = 0;
icmp_out_count(icmp_param-data.icmph.type);
Since on PREEMPT_RT spinlocks allow preemption, it's possible to
change cpu at (almost) any point in time. Make sure we stick to
the per cpu variable we started with.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
--- /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp_orig.c 2005-04-03 00:09:08.0 +0200
+++ /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp.c 2005-04-03 00:20:22.0 +0200
@@ -228,27 +228,32 @@
*
* On SMP we have one ICMP socket per-cpu.
*/
-static DEFINE_PER_CPU(struct socket *, __icmp_socket) = NULL;
-#define icmp_socket __get_cpu_var(__icmp_socket)
+static DEFINE_PER_CPU_LOCKED(struct socket *, __icmp_socket) = NULL;
static __inline__ struct socket * icmp_xmit_lock(int cpu)
{
+ struct socket *icmp_socket;
+
local_bh_disable();
+ icmp_socket = get_cpu_var_locked(__icmp_socket, cpu);
if (unlikely(!spin_trylock(icmp_socket-sk-sk_lock.slock))) {
/* This can happen if the output path signals a
* dst_link_failure() for an outgoing ICMP packet.
*/
+ put_cpu_var_locked(__icmp_socket, cpu);
local_bh_enable();
- return 1;
+ return NULL;
}
- return 0;
+ return icmp_socket;
}
static void icmp_xmit_unlock(int cpu)
{
+ struct socket *icmp_socket = __get_cpu_var_locked(__icmp_socket, cpu);
spin_unlock_bh(icmp_socket-sk-sk_lock.slock);
+ put_cpu_var_locked(__icmp_socket, cpu);
}
/*
@@ -345,7 +350,8 @@
}
static void icmp_push_reply(struct icmp_bxm *icmp_param,
- struct ipcm_cookie *ipc, struct rtable *rt)
+ struct ipcm_cookie *ipc, struct rtable *rt,
+struct socket *icmp_socket)
{
struct sk_buff *skb;
@@ -377,16 +383,19 @@
static void icmp_reply(struct icmp_bxm *icmp_param, struct sk_buff *skb)
{
+ struct socket *icmp_socket;
struct sock *sk;
struct inet_sock *inet;
struct ipcm_cookie ipc;
struct rtable *rt
[PATCH 2.6.12-rc1-mm4] mips: warning fix audit_arch()
This patch had fixed the following warning about audit_arch().
ptrace.o
arch/mips/kernel/ptrace.c:305: warning: function declaration isn't a prototype
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/kernel/ptrace.c
rc1-mm4/arch/mips/kernel/ptrace.c
--- rc1-mm4-orig/arch/mips/kernel/ptrace.c Fri Apr 1 21:22:15 2005
+++ rc1-mm4/arch/mips/kernel/ptrace.c Sat Apr 2 13:30:09 2005
@@ -301,7 +301,7 @@
return ret;
}
-static inline int audit_arch()
+static inline int audit_arch(void)
{
#ifdef CONFIG_CPU_LITTLE_ENDIAN
#ifdef CONFIG_MIPS64
-
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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Same issue here. Suspend-to-ram works perfectly fine with kernel 2.6.12-rc1-mm1, in mm2,3 and mm4 it is broken. It suspends properly but does not resume. Just a blackscreen and no reaction on keypress/usb plug-in/network/power button. regards, Stefan - 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/
[PATCH] 2.6.12-rc1-mm4 x86_64 genapic update
Hello,
x86_64 genapic mechanism should be aware of machines that use physical APIC mode
regardless of how many clusters/processors are detected. ACPI 3.0 FADT makes this
determination very simple by providing a feature flag
"force_apic_physical_destination_mode" to state whether the machine
unconditionally uses physical APIC mode. Unisys' next generation x86_64 ES7000 will need
to utilize this FADT feature flag in order to boot the x86_64 kernel in the correct APIC
mode. This patch has been tested on both x86_64 commodity and ES7000 boxes.
Signed-off-by: Jason Davis <[EMAIL PROTECTED]>
diff -Naurp linux-2.6.12-rc1-mm4/arch/i386/kernel/acpi/boot.c
linux-2.6.12-rc1-mm4-genapic/arch/i386/kernel/acpi/boot.c
--- linux-2.6.12-rc1-mm4/arch/i386/kernel/acpi/boot.c 2005-03-02
02:38:25.0 -0500
+++ linux-2.6.12-rc1-mm4-genapic/arch/i386/kernel/acpi/boot.c 2005-03-31
18:15:09.606679144 -0500
@@ -608,6 +608,10 @@ static int __init acpi_parse_fadt(unsign
acpi_fadt.sci_int = fadt->sci_int;
#endif
+ /* initialize rev and apic_phys_dest_mode for x86_64 genapic */
+ acpi_fadt.revision = fadt->revision;
+ acpi_fadt.force_apic_physical_destination_mode =
fadt->force_apic_physical_destination_mode;
+
#ifdef CONFIG_X86_PM_TIMER
/* detect the location of the ACPI PM Timer */
if (fadt->revision >= FADT2_REVISION_ID) {
diff -Naurp linux-2.6.12-rc1-mm4/arch/x86_64/kernel/genapic.c
linux-2.6.12-rc1-mm4-genapic/arch/x86_64/kernel/genapic.c
--- linux-2.6.12-rc1-mm4/arch/x86_64/kernel/genapic.c 2005-03-02
02:38:37.000000000 -0500
+++ linux-2.6.12-rc1-mm4-genapic/arch/x86_64/kernel/genapic.c 2005-03-31
18:15:09.607678992 -0500
@@ -20,6 +20,10 @@
#include
#include
+#if defined(CONFIG_ACPI_BUS)
+#include
+#endif
+
/* which logical CPU number maps to which CPU (physical APIC ID) */
u8 x86_cpu_to_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
EXPORT_SYMBOL(x86_cpu_to_apicid);
@@ -47,6 +51,18 @@ void __init clustered_apic_check(void)
goto print;
}
+#if defined(CONFIG_ACPI_BUS)
+ /*
+* Some x86_64 machines use physical APIC mode regardless of how many
+* procs/clusters are present (x86_64 ES7000 is an example).
+*/
+ if (acpi_fadt.revision > FADT2_REVISION_ID)
+ if (acpi_fadt.force_apic_physical_destination_mode) {
+ genapic = _cluster;
+ goto print;
+ }
+#endif
+
memset(cluster_cnt, 0, sizeof(cluster_cnt));
for (i = 0; i < NR_CPUS; i++) {
-
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/
Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Hi! > Since 2.6.12-rc1-mmX I cannot get suspend2ram working again as it was > with 2.6.11-mm4 with the same .config. > > I suspends fine, but never resumes. No CapsLock, no sysrq, no network is > working. Nothing in the log files. Is there anything which may cause > these troubles when compiled into the kernel and not loaded as module? > (as it was with my usb stuff until 2.6.11-mm2, after this I had to stop > hotplug, before I could go with usb running). Try suspend2disk, first, and try suspend2ram with minimal kernel config. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
ChangeLog:
- Remove unnecessary catch in cn_fork_callback().
- Use reverse dependencies in Kconfig. By doing this, if fork
connector is enabled, the connector will be automatically
selected as built-in. It's the what we need.
- Move the cn_fork_enable and cb_fork_id declarations inside
CONFIG_FORK_CONNECTOR.
- Use DECLARE_PER_CPU in connector.h and DEFINE_PER_CPU in fork.c
to avoid fork_counts to be defined in each compilation unit which
includes include/linux/connector.h
- Add a description of the fork connector in the beginning of the
cn_fork.c
This patch applies to 2.6.12-rc1-mm4
Many thanks to Andrew for the great help,
Best regards,
Guillaume
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
---
drivers/connector/Kconfig | 11
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 113
include/linux/connector.h | 54 +
kernel/fork.c | 11
5 files changed, 190 insertions(+)
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Kconfig 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig 2005-04-01
08:02:25.0 +0200
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool "Enable fork connector"
+ select CONNECTOR
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Makefile 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile 2005-03-31
14:57:52.0 +0200
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/cn_fork.c
2003-01-30 11:24:37.0 +0100
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c 2005-04-01
12:48:47.0 +0200
@@ -0,0 +1,113 @@
+/*
+ * cn_fork.c - Fork connector
+ *
+ * Copyright (C) 2005 Guillaume Thouvenin <[EMAIL PROTECTED]>
+ *
+ * This module implements the fork connector. It allows to send a
+ * netlink datagram, when enabled, from the do_fork() routine. The
+ * message can be read by a user space application. By this way,
+ * the user space application is alerted when a fork occurs.
+ *
+ * It uses the userspace <-> kernelspace connector that works on top of
+ * the netlink protocol. The fork connector is enabled or disabled by
+ * sending a message to the connector. The unique sequence number of
+ * messages can be used to check if a message is lost.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Guillaume Thouvenin <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Enable or disable the usage of the fork connector");
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+static inline void cn_fork_send_status(void)
+{
+ /* TODO: An informational line in log is maybe not enough... */
+ printk(KERN_INFO "cn_fork_enable == %d\n", cn_fork_enable);
+}
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
ChangeLog:
- Remove unnecessary catch in cn_fork_callback().
- Use reverse dependencies in Kconfig. By doing this, if fork
connector is enabled, the connector will be automatically
selected as built-in. It's the what we need.
- Move the cn_fork_enable and cb_fork_id declarations inside
CONFIG_FORK_CONNECTOR.
- Use DECLARE_PER_CPU in connector.h and DEFINE_PER_CPU in fork.c
to avoid fork_counts to be defined in each compilation unit which
includes include/linux/connector.h
- Add a description of the fork connector in the beginning of the
cn_fork.c
This patch applies to 2.6.12-rc1-mm4
Many thanks to Andrew for the great help,
Best regards,
Guillaume
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/connector/Kconfig | 11
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 113
include/linux/connector.h | 54 +
kernel/fork.c | 11
5 files changed, 190 insertions(+)
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Kconfig 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig 2005-04-01
08:02:25.0 +0200
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool Enable fork connector
+ select CONNECTOR
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Makefile 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile 2005-03-31
14:57:52.0 +0200
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/cn_fork.c
2003-01-30 11:24:37.0 +0100
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c 2005-04-01
12:48:47.0 +0200
@@ -0,0 +1,113 @@
+/*
+ * cn_fork.c - Fork connector
+ *
+ * Copyright (C) 2005 Guillaume Thouvenin [EMAIL PROTECTED]
+ *
+ * This module implements the fork connector. It allows to send a
+ * netlink datagram, when enabled, from the do_fork() routine. The
+ * message can be read by a user space application. By this way,
+ * the user space application is alerted when a fork occurs.
+ *
+ * It uses the userspace - kernelspace connector that works on top of
+ * the netlink protocol. The fork connector is enabled or disabled by
+ * sending a message to the connector. The unique sequence number of
+ * messages can be used to check if a message is lost.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+
+#include linux/connector.h
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Guillaume Thouvenin [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Enable or disable the usage of the fork connector);
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+static inline void cn_fork_send_status(void)
+{
+ /* TODO: An informational line in log is maybe not enough... */
+ printk(KERN_INFO cn_fork_enable == %d\n, cn_fork_enable);
+}
+
+/**
+ * cn_fork_callback - enable or disable the fork connector
+ * @data: message send by the connector
+ *
+ * The callback allows to enable or disable the sending of information
Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Hi! Since 2.6.12-rc1-mmX I cannot get suspend2ram working again as it was with 2.6.11-mm4 with the same .config. I suspends fine, but never resumes. No CapsLock, no sysrq, no network is working. Nothing in the log files. Is there anything which may cause these troubles when compiled into the kernel and not loaded as module? (as it was with my usb stuff until 2.6.11-mm2, after this I had to stop hotplug, before I could go with usb running). Try suspend2disk, first, and try suspend2ram with minimal kernel config. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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/
[PATCH] 2.6.12-rc1-mm4 x86_64 genapic update
Hello,
x86_64 genapic mechanism should be aware of machines that use physical APIC mode
regardless of how many clusters/processors are detected. ACPI 3.0 FADT makes this
determination very simple by providing a feature flag
force_apic_physical_destination_mode to state whether the machine
unconditionally uses physical APIC mode. Unisys' next generation x86_64 ES7000 will need
to utilize this FADT feature flag in order to boot the x86_64 kernel in the correct APIC
mode. This patch has been tested on both x86_64 commodity and ES7000 boxes.
Signed-off-by: Jason Davis [EMAIL PROTECTED]
diff -Naurp linux-2.6.12-rc1-mm4/arch/i386/kernel/acpi/boot.c
linux-2.6.12-rc1-mm4-genapic/arch/i386/kernel/acpi/boot.c
--- linux-2.6.12-rc1-mm4/arch/i386/kernel/acpi/boot.c 2005-03-02
02:38:25.0 -0500
+++ linux-2.6.12-rc1-mm4-genapic/arch/i386/kernel/acpi/boot.c 2005-03-31
18:15:09.606679144 -0500
@@ -608,6 +608,10 @@ static int __init acpi_parse_fadt(unsign
acpi_fadt.sci_int = fadt-sci_int;
#endif
+ /* initialize rev and apic_phys_dest_mode for x86_64 genapic */
+ acpi_fadt.revision = fadt-revision;
+ acpi_fadt.force_apic_physical_destination_mode =
fadt-force_apic_physical_destination_mode;
+
#ifdef CONFIG_X86_PM_TIMER
/* detect the location of the ACPI PM Timer */
if (fadt-revision = FADT2_REVISION_ID) {
diff -Naurp linux-2.6.12-rc1-mm4/arch/x86_64/kernel/genapic.c
linux-2.6.12-rc1-mm4-genapic/arch/x86_64/kernel/genapic.c
--- linux-2.6.12-rc1-mm4/arch/x86_64/kernel/genapic.c 2005-03-02
02:38:37.0 -0500
+++ linux-2.6.12-rc1-mm4-genapic/arch/x86_64/kernel/genapic.c 2005-03-31
18:15:09.607678992 -0500
@@ -20,6 +20,10 @@
#include asm/smp.h
#include asm/ipi.h
+#if defined(CONFIG_ACPI_BUS)
+#include acpi/acpi_bus.h
+#endif
+
/* which logical CPU number maps to which CPU (physical APIC ID) */
u8 x86_cpu_to_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
EXPORT_SYMBOL(x86_cpu_to_apicid);
@@ -47,6 +51,18 @@ void __init clustered_apic_check(void)
goto print;
}
+#if defined(CONFIG_ACPI_BUS)
+ /*
+* Some x86_64 machines use physical APIC mode regardless of how many
+* procs/clusters are present (x86_64 ES7000 is an example).
+*/
+ if (acpi_fadt.revision FADT2_REVISION_ID)
+ if (acpi_fadt.force_apic_physical_destination_mode) {
+ genapic = apic_cluster;
+ goto print;
+ }
+#endif
+
memset(cluster_cnt, 0, sizeof(cluster_cnt));
for (i = 0; i NR_CPUS; i++) {
-
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/
Re: [ACPI] Re: 2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Same issue here. Suspend-to-ram works perfectly fine with kernel 2.6.12-rc1-mm1, in mm2,3 and mm4 it is broken. It suspends properly but does not resume. Just a blackscreen and no reaction on keypress/usb plug-in/network/power button. regards, Stefan - 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/
[PATCH 2.6.12-rc1-mm4] mips: warning fix audit_arch()
This patch had fixed the following warning about audit_arch().
ptrace.o
arch/mips/kernel/ptrace.c:305: warning: function declaration isn't a prototype
Yoichi
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/kernel/ptrace.c
rc1-mm4/arch/mips/kernel/ptrace.c
--- rc1-mm4-orig/arch/mips/kernel/ptrace.c Fri Apr 1 21:22:15 2005
+++ rc1-mm4/arch/mips/kernel/ptrace.c Sat Apr 2 13:30:09 2005
@@ -301,7 +301,7 @@
return ret;
}
-static inline int audit_arch()
+static inline int audit_arch(void)
{
#ifdef CONFIG_CPU_LITTLE_ENDIAN
#ifdef CONFIG_MIPS64
-
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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
On Thu, 2005-03-31 at 16:10 -0800, Jay Lan wrote: > Andrew Morton wrote: > > >Guillaume Thouvenin <[EMAIL PROTECTED]> wrote: > > > > > >> This patch adds a fork connector in the do_fork() routine. > >>... > >> > >> The fork connector is used by the Enhanced Linux System Accounting > >>project http://elsa.sourceforge.net > >> > >> > > > >Does it also meet all the in-kernel requirements for other accounting > >projects? > > > >If not, what else do those other projects need? > > > > > Hi Andrew, > > As the discussion in this thread of the past few days showed, this > patch intends to take care of process grouping, but not the > accounting data collection. Besides my concern of possibility of > data loss, this patch also provides CSA information to handle process > grouping as it intends to do. I plan to run some testing to see percentage > of data loss when system is under stress test, but improvement at > CBUS as Evgeniy indicated should help! > > Please be advised that i still need an do_exit handling to save accounting > data. But, it is a separate issue. My five copecks [or two cents]: fork connector with CBUS [with theirs upto 2.5 % degradation with huge disk writes per fork] are still much faster than any existing accounting models. But it is purely accounting project author to think about accounting design though... > Thanks, > - jay -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: 2.6.12-rc1-mm4
Andrew Morton wrote: > bk-audit.patch This seems to have broken compile for uml: CC arch/um/kernel/ptrace.o arch/um/kernel/ptrace.c:345:74: macro "audit_syscall_entry" requires 7 arguments, but only 6 given arch/um/kernel/ptrace.c: In function `syscall_trace': arch/um/kernel/ptrace.c:340: error: `audit_syscall_entry' undeclared (first use in this function) arch/um/kernel/ptrace.c:340: error: (Each undeclared identifier is reported only once arch/um/kernel/ptrace.c:340: error: for each function it appears in.) arch/um/kernel/ptrace.c:348:72: macro "audit_syscall_exit" requires 3 arguments, but only 2 given arch/um/kernel/ptrace.c:347: error: `audit_syscall_exit' undeclared (first use in this function) make[1]: *** [arch/um/kernel/ptrace.o] Error 1 make: *** [arch/um/kernel] Error 2 Fri, 01 Apr 2005 09:08:16 +0200 in particular I suspect: # include/linux/audit.h # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +44 -4 # Add AUDIT_ARCH and its definitions # Add arch to audit_syscall_entry() # Add success/failure to audit_syscall_exit() # # arch/x86_64/kernel/ptrace.c # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +8 -5 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/s390/kernel/ptrace.c # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +11 -10 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/ppc64/kernel/ptrace.c # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +10 -6 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/mips/kernel/ptrace.c # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +28 -10 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/ia64/kernel/ptrace.c # 2005/03/25 13:53:14+00:00 [EMAIL PROTECTED] +13 -8 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/i386/kernel/ptrace.c # 2005/03/25 13:53:14+00:00 [EMAIL PROTECTED] +9 -10 # Reorder audit w.r.t ptrace, provide arch and success. defconfig, gcc 3.3.5, see http://l4x.org/k/?d=3004 for details. Jan - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
Andrew Morton wrote: Guillaume Thouvenin <[EMAIL PROTECTED]> wrote: This patch adds a fork connector in the do_fork() routine. ... The fork connector is used by the Enhanced Linux System Accounting project http://elsa.sourceforge.net Does it also meet all the in-kernel requirements for other accounting projects? If not, what else do those other projects need? Hi Andrew, As the discussion in this thread of the past few days showed, this patch intends to take care of process grouping, but not the accounting data collection. Besides my concern of possibility of data loss, this patch also provides CSA information to handle process grouping as it intends to do. I plan to run some testing to see percentage of data loss when system is under stress test, but improvement at CBUS as Evgeniy indicated should help! Please be advised that i still need an do_exit handling to save accounting data. But, it is a separate issue. Thanks, - jay - 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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
>
> This patch adds a fork connector in the do_fork() routine.
>
> +config FORK_CONNECTOR
> + bool "Enable fork connector"
> + depends on CONNECTOR=y
This kind of defeats connector's ability to be built as a module. Doing
select CONNECTOR
may be better here.
> +static void cn_fork_callback(void *data)
> +{
> + struct cn_msg *msg = (struct cn_msg *)data;
The cast is unnecessary.
>
> extern int cn_already_initialized;
> +extern int cn_fork_enable;
> +extern struct cb_id cb_fork_id;
Should these declarations be inside CONFIG_FORK_CONNECTOR?
> +
> +static DEFINE_PER_CPU(unsigned long, fork_counts);
> +
This will cause fork_counts to be defined in each compilation unit which
includes this header file. You should use DEFINE_PER_CPU in .c and
DECLARE_PER_CPU in .h.
-
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/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote: > > This patch adds a fork connector in the do_fork() routine. > ... > > The fork connector is used by the Enhanced Linux System Accounting > project http://elsa.sourceforge.net Does it also meet all the in-kernel requirements for other accounting projects? If not, what else do those other projects need? - 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/
2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Dear Andrew, dear developers! Since 2.6.12-rc1-mmX I cannot get suspend2ram working again as it was with 2.6.11-mm4 with the same .config. I suspends fine, but never resumes. No CapsLock, no sysrq, no network is working. Nothing in the log files. Is there anything which may cause these troubles when compiled into the kernel and not loaded as module? (as it was with my usb stuff until 2.6.11-mm2, after this I had to stop hotplug, before I could go with usb running). On a side node: Once suspend2ram couldn't stop all tasks, in fact cpufreq, although it was stopped with /etc/init.d/cpufreqd stop, was mentioned in syslog as not being able to be stopped, and after this halfway through suspend, my touchpad (synaptics) and kbd wasn't working anymore. After resume the touchpad is somehow behaving strange. THe touchpad is not working at all, the keyboard seems to react to some events (Sysrq is working, but normal typing not, nor power button/acpi stuff). In the syslog I find: vmunix: psmouse.c: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away. vmunix: psmouse.c: TouchPad at isa0060/serio1/input0 lot sync at byte 1 I would be happy to test some stuff to get S2R back to work! Thanks a lot and all the best Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HARBLEDOWN (vb.) To manoeuvre a double mattress down a winding staircase. --- Douglas Adams, The Meaning of Liff - 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/
[patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
This patch adds a fork connector in the do_fork() routine. It sends a
netlink datagram when enabled. The message can be read by a user space
application. By this way, the user space application is alerted when a
fork occurs.
It uses the userspace <-> kernelspace connector that works on top of
the netlink protocol. The fork connector is enabled or disabled by
sending a message to the connector. The unique sequence number of
messages can be used to check if a message is lost. In this patch we use
a cn_fork_msg structure (thanks to Dean Gaudet) rather than zeroing 64
bytes of memory and doing conversions to decimal ascii as done before.
Also we move the fork_connector() inline code in the header file
include/linux/connector.h as suggested by Paul Jackson (thanks).
The fork connector is used by the Enhanced Linux System Accounting
project http://elsa.sourceforge.net
When the fork connector is disabled, the "lat_proc fork" test returns
a value equal to:
Process fork+exit: 150.2076 microseconds
When the fork connector is enabled, the same test returns:
Process fork+exit: 153.7778 microseconds
So the overhead (the construction and the sending of the message) is
around 2%. If we use the CBUS patch http://lkml.org/lkml/2005/3/20/14
instead of cn_netlink_send() routine we can reduce this overhead near to
0%. We're waiting for the inclusion of the CBUS in the -mm tree.
This patch applies to 2.6.12-rc1-mm4.
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
---
drivers/connector/Kconfig | 11
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 104
include/linux/connector.h | 53 ++
kernel/fork.c |3 +
5 files changed, 172 insertions(+)
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig
=======
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Kconfig 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig 2005-03-31
14:57:52.0 +0200
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool "Enable fork connector"
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile
===============
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Makefile 2005-03-31
14:56:02.000000000 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile 2005-03-31
14:57:52.0 +0200
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c
===============
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/cn_fork.c
2003-01-30 11:24:37.000000000 +0100
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c 2005-03-31
14:57:52.0 +0200
@@ -0,0 +1,104 @@
+/*
+ * cn_fork.c
+ *
+ * 2005 Copyright (c) Guillaume Thouvenin <[EMAIL PROTECTED]>
+ * All rights reserved.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Guillaume Thouvenin <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("Enable or disable the usage of the fork connector");
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+static inline void cn_fork_send_status(void)
+{
+ /* TODO */
+ printk(KERN_INFO "cn_fork_enable == %d\n
Re: 2.6.12-rc1-mm4
Andrew Morton wrote: ... make-sysrq-f-call-oom_kill.patch make sysrq-F call oom_kill() Glad to see it fixed. :) - 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/
Re: 2.6.12-rc1-mm4
Andrew Morton wrote: ... make-sysrq-f-call-oom_kill.patch make sysrq-F call oom_kill() Glad to see it fixed. :) - 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/
[patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
This patch adds a fork connector in the do_fork() routine. It sends a
netlink datagram when enabled. The message can be read by a user space
application. By this way, the user space application is alerted when a
fork occurs.
It uses the userspace - kernelspace connector that works on top of
the netlink protocol. The fork connector is enabled or disabled by
sending a message to the connector. The unique sequence number of
messages can be used to check if a message is lost. In this patch we use
a cn_fork_msg structure (thanks to Dean Gaudet) rather than zeroing 64
bytes of memory and doing conversions to decimal ascii as done before.
Also we move the fork_connector() inline code in the header file
include/linux/connector.h as suggested by Paul Jackson (thanks).
The fork connector is used by the Enhanced Linux System Accounting
project http://elsa.sourceforge.net
When the fork connector is disabled, the lat_proc fork test returns
a value equal to:
Process fork+exit: 150.2076 microseconds
When the fork connector is enabled, the same test returns:
Process fork+exit: 153.7778 microseconds
So the overhead (the construction and the sending of the message) is
around 2%. If we use the CBUS patch http://lkml.org/lkml/2005/3/20/14
instead of cn_netlink_send() routine we can reduce this overhead near to
0%. We're waiting for the inclusion of the CBUS in the -mm tree.
This patch applies to 2.6.12-rc1-mm4.
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/connector/Kconfig | 11
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 104
include/linux/connector.h | 53 ++
kernel/fork.c |3 +
5 files changed, 172 insertions(+)
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Kconfig 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Kconfig 2005-03-31
14:57:52.0 +0200
@@ -10,4 +10,15 @@ config CONNECTOR
Connector support can also be built as a module. If so, the module
will be called cn.ko.
+config FORK_CONNECTOR
+ bool Enable fork connector
+ depends on CONNECTOR=y
+ default y
+ ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and
+ its child. This information can be used by a user space application.
+ The fork connector can be enable/disable by sending a message to the
+ connector with the corresponding group id.
+
endmenu
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/Makefile 2005-03-31
14:56:02.0 +0200
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/Makefile 2005-03-31
14:57:52.0 +0200
@@ -1,2 +1,3 @@
obj-$(CONFIG_CONNECTOR)+= cn.o
+obj-$(CONFIG_FORK_CONNECTOR) += cn_fork.o
cn-objs:= cn_queue.o connector.o
Index: linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c
===
--- linux-2.6.12-rc1-mm4-cnfork.orig/drivers/connector/cn_fork.c
2003-01-30 11:24:37.0 +0100
+++ linux-2.6.12-rc1-mm4-cnfork/drivers/connector/cn_fork.c 2005-03-31
14:57:52.0 +0200
@@ -0,0 +1,104 @@
+/*
+ * cn_fork.c
+ *
+ * 2005 Copyright (c) Guillaume Thouvenin [EMAIL PROTECTED]
+ * All rights reserved.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+
+#include linux/connector.h
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Guillaume Thouvenin [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Enable or disable the usage of the fork connector);
+
+int cn_fork_enable = 0;
+struct cb_id cb_fork_id = { CN_IDX_FORK, CN_VAL_FORK };
+
+static inline void cn_fork_send_status(void)
+{
+ /* TODO */
+ printk(KERN_INFO cn_fork_enable == %d\n, cn_fork_enable
2.6.12-rc1-mm4 and suspend2ram (and synaptics)
Dear Andrew, dear developers! Since 2.6.12-rc1-mmX I cannot get suspend2ram working again as it was with 2.6.11-mm4 with the same .config. I suspends fine, but never resumes. No CapsLock, no sysrq, no network is working. Nothing in the log files. Is there anything which may cause these troubles when compiled into the kernel and not loaded as module? (as it was with my usb stuff until 2.6.11-mm2, after this I had to stop hotplug, before I could go with usb running). On a side node: Once suspend2ram couldn't stop all tasks, in fact cpufreq, although it was stopped with /etc/init.d/cpufreqd stop, was mentioned in syslog as not being able to be stopped, and after this halfway through suspend, my touchpad (synaptics) and kbd wasn't working anymore. After resume the touchpad is somehow behaving strange. THe touchpad is not working at all, the keyboard seems to react to some events (Sysrq is working, but normal typing not, nor power button/acpi stuff). In the syslog I find: vmunix: psmouse.c: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away. vmunix: psmouse.c: TouchPad at isa0060/serio1/input0 lot sync at byte 1 I would be happy to test some stuff to get S2R back to work! Thanks a lot and all the best Norbert --- Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HARBLEDOWN (vb.) To manoeuvre a double mattress down a winding staircase. --- Douglas Adams, The Meaning of Liff - 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/
