Re: Git archive now available
On Fri, 15 Apr 2005, Darren Williams wrote: > Hi All > > Thanks to the team at [EMAIL PROTECTED] we now have a > no so complete Git archive at > http://www.gelato.unsw.edu.au/archives/git/ > > If somebody could send me a complete Git mbox I will > update the archive with it. Apparently gmane.org have archived the list here is the link. http://dir.gmane.org/gmane.comp.version-control.git Sorry Kenneth for the previous spam. - dsw > > - dsw > > ------ > Darren Williams > [EMAIL PROTECTED] > -- > - > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams [EMAIL PROTECTED] -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Git archive now available
On Fri, 15 Apr 2005, Darren Williams wrote: Hi All Thanks to the team at [EMAIL PROTECTED] we now have a no so complete Git archive at http://www.gelato.unsw.edu.au/archives/git/ If somebody could send me a complete Git mbox I will update the archive with it. Apparently gmane.org have archived the list here is the link. http://dir.gmane.org/gmane.comp.version-control.git Sorry Kenneth for the previous spam. - dsw - dsw -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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: Git archive now available
Hi David On Thu, 14 Apr 2005, David S. Miller wrote: > On Fri, 15 Apr 2005 10:01:47 +1000 > Darren Williams <[EMAIL PROTECTED]> wrote: > > > Thanks to the team at [EMAIL PROTECTED] we now have a > > no so complete Git archive at > > http://www.gelato.unsw.edu.au/archives/git/ > > > > If somebody could send me a complete Git mbox I will > > update the archive with it. > > I just had to unsubscribe [EMAIL PROTECTED] > because it was bouncing with errors like "hypermail: ... > this archive looks non-empty but there it no gdbm file" > > So don't get too excited about your archive just yet :-) Sorry permissions problem should be OK now:) > - > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams [EMAIL PROTECTED] -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Git archive now available
Hi All Thanks to the team at [EMAIL PROTECTED] we now have a no so complete Git archive at http://www.gelato.unsw.edu.au/archives/git/ If somebody could send me a complete Git mbox I will update the archive with it. - dsw -- Darren Williams [EMAIL PROTECTED] -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Git archive now available
Hi All Thanks to the team at [EMAIL PROTECTED] we now have a no so complete Git archive at http://www.gelato.unsw.edu.au/archives/git/ If somebody could send me a complete Git mbox I will update the archive with it. - dsw -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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: ext3 journalling BUG on full filesystem
Hi Mark Looks like you need to apply the attached patch (for the current bk kernel or see the link below for an earlier version (which will require some modification to remove implicit warnings, see to extern and prototype declarations for __journal_temp_unlink_buffer in attached patch). Looking at Anton reply this may not be true but worth a try. Darren -- Stephen I am still seeing this Oops on ext3 journal with current bk tree, this patch: http://lkml.org/lkml/2005/3/8/147 fixes the problem though required changes to remove implicit declaration warnings updated patch attached. Unable to handle kernel NULL pointer dereference (address 0018) kjournald[16894]: Oops 8821862825984 [1] Pid: 16894, CPU 0, comm:kjournald psr : 101008026018 ifs : 8e21 ip : []Not tainted ip is at journal_commit_transaction+0x840/0x2700 unat: pfs : 0e21 rsc : 0003 rnat: bsps: pr : 1641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001001ce300 b6 : a00100633000 b7 : a001a9d0 f6 : 0fffbc8c0 f7 : 0ffea9877e000 f8 : 1000ff0f0 f9 : 10002a000 f10 : 1000cc0bffc303400 f11 : 1003e3030 r1 : a00100a8c830 r2 : 0286 r3 : r8 : 0001 r9 : e70062f40d50 r10 : e70062f40d60 r11 : r12 : e70062f47d10 r13 : e70062f4 r14 : e70062f47cb0 r15 : e7005c2632f8 r16 : 4000 r17 : e7005c263338 r18 : r19 : 0009804c8a70433f r20 : 070062f4 r21 : a0010062f9d0 r22 : r23 : r24 : r25 : r26 : r27 : r28 : 5a41 r29 : r30 : r31 : e70079ab18dc Call Trace: [] show_stack+0x80/0xa0 sp=e70062f478d0 bsp=e70062f41060 [] show_regs+0x7e0/0x800 sp=e70062f47aa0 bsp=e70062f41000 [] die+0x150/0x1c0 sp=e70062f47ab0 bsp=e70062f40fb8 [] ia64_do_page_fault+0x370/0x980 sp=e70062f47ab0 bsp=e70062f40f50 [] ia64_leave_kernel+0x0/0x260 sp=e70062f47b40 bsp=e70062f40f50 [] journal_commit_transaction+0x840/0x2700 sp=e70062f47d10 bsp=e70062f40e48 [] kjournald+0x180/0x4e0 sp=e70062f47d80 bsp=e70062f40dd8 [] kernel_thread_helper+0xd0/0x100 sp=e70062f47e30 bsp=e70062f40db0 [] start_kernel_thread+0x20/0x40 sp=e70062f47e30 bsp=e70062f40db0 > On Wed, 23 Mar 2005, Mark Wong wrote: > I originally reported this to the linuxppc64-dev list, since I made it > happen on a POWER system. I'm told this might be more generic... > > Anyone run into something like this? > > Mark > > - Forwarded message from Mark Wong <[EMAIL PROTECTED]> - > > Date: Wed, 23 Mar 2005 08:05:30 -0800 > To: [EMAIL PROTECTED] > From: Mark Wong <[EMAIL PROTECTED]> > Subject: ext3 journalling BUG on full filesystem > > Hi, > > I'm running 2.6.11 and I'm suspecting that a full ext3 filesystem is > causing the following problem when performing some journaling > operation. Let me know if I can provide more details: > > cpu 0x6: Vector: 700 (Program Check) at [c002e4f3f6d0] > pc: c00a5fbc: .submit_bh+0x64/0x1fc > lr: c00a62b4: .ll_rw_block+0x160/0x164 > sp: c002e4f3f950 >msr: 80029032 > current = 0xc0038ff5c7c0 > paca= 0xc0612000 > pid = 1376, comm = kjournald > kernel BUG in submit_bh at fs/buffer.c:2706! > enter ? for help > 6:mon> t > [c002e4f3f9f0] c00a62b4 .ll_rw_block+0x160/0x164 > [c002e4f3fab0] c0151ac4 .journal_commit_transaction+0xd88/0x16d4 > [c002e4f3fe30] c0155590 .kjournald+0x114/0x308 > [c002e4f3ff90] c0013ec0 .kernel_thread+0x4c/0x6c > - > 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/ -- Darren Williams [EMAIL PROTECTED] -- Fix destruction of in-use journal_head journal_put_journal_head() can destroy a journal_head at any time as long as the jh's b_jcount is zero and b_transaction is NULL. It has no locking
Re: ext3 journalling BUG on full filesystem
Hi Mark Looks like you need to apply the attached patch (for the current bk kernel or see the link below for an earlier version (which will require some modification to remove implicit warnings, see to extern and prototype declarations for __journal_temp_unlink_buffer in attached patch). Looking at Anton reply this may not be true but worth a try. Darren -- Stephen I am still seeing this Oops on ext3 journal with current bk tree, this patch: http://lkml.org/lkml/2005/3/8/147 fixes the problem though required changes to remove implicit declaration warnings updated patch attached. Unable to handle kernel NULL pointer dereference (address 0018) kjournald[16894]: Oops 8821862825984 [1] Pid: 16894, CPU 0, comm:kjournald psr : 101008026018 ifs : 8e21 ip : [a001001ce1e0]Not tainted ip is at journal_commit_transaction+0x840/0x2700 unat: pfs : 0e21 rsc : 0003 rnat: bsps: pr : 1641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001001ce300 b6 : a00100633000 b7 : a001a9d0 f6 : 0fffbc8c0 f7 : 0ffea9877e000 f8 : 1000ff0f0 f9 : 10002a000 f10 : 1000cc0bffc303400 f11 : 1003e3030 r1 : a00100a8c830 r2 : 0286 r3 : r8 : 0001 r9 : e70062f40d50 r10 : e70062f40d60 r11 : r12 : e70062f47d10 r13 : e70062f4 r14 : e70062f47cb0 r15 : e7005c2632f8 r16 : 4000 r17 : e7005c263338 r18 : r19 : 0009804c8a70433f r20 : 070062f4 r21 : a0010062f9d0 r22 : r23 : r24 : r25 : r26 : r27 : r28 : 5a41 r29 : r30 : r31 : e70079ab18dc Call Trace: [a001fd80] show_stack+0x80/0xa0 sp=e70062f478d0 bsp=e70062f41060 [a001000105e0] show_regs+0x7e0/0x800 sp=e70062f47aa0 bsp=e70062f41000 [a00100033f90] die+0x150/0x1c0 sp=e70062f47ab0 bsp=e70062f40fb8 [a00100052d50] ia64_do_page_fault+0x370/0x980 sp=e70062f47ab0 bsp=e70062f40f50 [a001b160] ia64_leave_kernel+0x0/0x260 sp=e70062f47b40 bsp=e70062f40f50 [a001001ce1e0] journal_commit_transaction+0x840/0x2700 sp=e70062f47d10 bsp=e70062f40e48 [a001001d5260] kjournald+0x180/0x4e0 sp=e70062f47d80 bsp=e70062f40dd8 [a00100011df0] kernel_thread_helper+0xd0/0x100 sp=e70062f47e30 bsp=e70062f40db0 [a00190e0] start_kernel_thread+0x20/0x40 sp=e70062f47e30 bsp=e70062f40db0 On Wed, 23 Mar 2005, Mark Wong wrote: I originally reported this to the linuxppc64-dev list, since I made it happen on a POWER system. I'm told this might be more generic... Anyone run into something like this? Mark - Forwarded message from Mark Wong [EMAIL PROTECTED] - Date: Wed, 23 Mar 2005 08:05:30 -0800 To: [EMAIL PROTECTED] From: Mark Wong [EMAIL PROTECTED] Subject: ext3 journalling BUG on full filesystem Hi, I'm running 2.6.11 and I'm suspecting that a full ext3 filesystem is causing the following problem when performing some journaling operation. Let me know if I can provide more details: cpu 0x6: Vector: 700 (Program Check) at [c002e4f3f6d0] pc: c00a5fbc: .submit_bh+0x64/0x1fc lr: c00a62b4: .ll_rw_block+0x160/0x164 sp: c002e4f3f950 msr: 80029032 current = 0xc0038ff5c7c0 paca= 0xc0612000 pid = 1376, comm = kjournald kernel BUG in submit_bh at fs/buffer.c:2706! enter ? for help 6:mon t [c002e4f3f9f0] c00a62b4 .ll_rw_block+0x160/0x164 [c002e4f3fab0] c0151ac4 .journal_commit_transaction+0xd88/0x16d4 [c002e4f3fe30] c0155590 .kjournald+0x114/0x308 [c002e4f3ff90] c0013ec0 .kernel_thread+0x4c/0x6c - 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/ -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- Fix destruction of in-use journal_head journal_put_journal_head() can destroy a journal_head at any time as long as the jh's b_jcount is zero and b_transaction is NULL. It has
[PATCH] 2.6.11-bk Stallion driver module clean up
These two patches continue the work that Wayne Meissner
started and are against the current bk tree.
These patches allow the stallion driver to be built-in and
loaded at boot time, the current #ifdef MODULE only allows
the init code to be included if compiled as a module.
Tested for compile, boot and running on our console server
as module and built-in.
Signed-off-by Darren Williams <[EMAIL PROTECTED]>
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/25 15:17:25+11:00 [EMAIL PROTECTED]
# stallion serial driver module clean up
#
# drivers/char/stallion.c
# 2005/02/25 15:17:16+11:00 [EMAIL PROTECTED] +5 -18
# Remove #define MODULE, and update module parameter declarations
#
Index: linux-2.5-import/drivers/char/stallion.c
===
--- linux-2.5-import.orig/drivers/char/stallion.c 2005-03-10
21:09:13.0 +1100
+++ linux-2.5-import/drivers/char/stallion.c2005-03-10 21:36:00.0
+1100
@@ -232,13 +232,12 @@
/*/
-#ifdef MODULE
/*
* Define some string labels for arguments passed from the module
* load line. These allow for easy board definitions, and easy
* modification of the io, memory and irq resoucres.
*/
-
+static int stl_nargs = 0;
static char*board0[4];
static char*board1[4];
static char*board2[4];
@@ -299,17 +298,15 @@
MODULE_DESCRIPTION("Stallion Multiport Serial Driver");
MODULE_LICENSE("GPL");
-MODULE_PARM(board0, "1-4s");
+module_param_array(board0, charp, _nargs, 0);
MODULE_PARM_DESC(board0, "Board 0 config -> name[,ioaddr[,ioaddr2][,irq]]");
-MODULE_PARM(board1, "1-4s");
+module_param_array(board1, charp, _nargs, 0);
MODULE_PARM_DESC(board1, "Board 1 config -> name[,ioaddr[,ioaddr2][,irq]]");
-MODULE_PARM(board2, "1-4s");
+module_param_array(board2, charp, _nargs, 0);
MODULE_PARM_DESC(board2, "Board 2 config -> name[,ioaddr[,ioaddr2][,irq]]");
-MODULE_PARM(board3, "1-4s");
+module_param_array(board3, charp, _nargs, 0);
MODULE_PARM_DESC(board3, "Board 3 config -> name[,ioaddr[,ioaddr2][,irq]]");
-#endif
-
/*/
/*
@@ -464,12 +461,10 @@
* Declare all those functions in this driver!
*/
-#ifdef MODULE
static voidstl_argbrds(void);
static int stl_parsebrd(stlconf_t *confp, char **argp);
static unsigned long stl_atol(char *str);
-#endif
intstl_init(void);
static int stl_open(struct tty_struct *tty, struct file *filp);
@@ -726,8 +721,6 @@
static struct class_simple *stallion_class;
-#ifdef MODULE
-
/*
* Loadable module initialization stuff.
*/
@@ -950,8 +943,6 @@
return(1);
}
-#endif
-
/*/
/*
@@ -2787,9 +2778,7 @@
*/
for (i = 0; (i < stl_nrbrds); i++) {
confp = _brdconf[i];
-#ifdef MODULE
stl_parsebrd(confp, stl_brdsp[i]);
-#endif
if ((brdp = stl_allocbrd()) == (stlbrd_t *) NULL)
return(-ENOMEM);
brdp->brdnr = i;
@@ -2805,9 +2794,7 @@
* Find any dynamically supported boards. That is via module load
* line options or auto-detected on the PCI bus.
*/
-#ifdef MODULE
stl_argbrds();
-#endif
#ifdef CONFIG_PCI
stl_findpcibrds();
#endif
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/25 15:22:21+11:00 [EMAIL PROTECTED]
# remove old 'nrargs' module argument count
#
# drivers/char/stallion.c
# 2005/02/25 15:22:12+11:00 [EMAIL PROTECTED] +2 -4
# module arguments are now declared with module paramater declarations
#
Index: linux-2.5-import/drivers/char/stallion.c
===
--- linux-2.5-import.orig/drivers/char/stallion.c 2005-03-10
21:36:00.0 +1100
+++ linux-2.5-import/drivers/char/stallion.c2005-03-10 21:36:41.0
+1100
@@ -835,15 +835,13 @@
{
stlconf_t conf;
stlbrd_t*brdp;
- int nrargs, i;
+ int i;
#ifdef DEBUG
printk("stl_argbrds()\n");
#endif
- nrargs = sizeof(stl_brdsp) / sizeof(char **);
-
- for (i = stl_nrbrds; (i < nrargs); i++) {
+ for (i = stl_nrbrds; (i < stl_nargs); i++) {
memset(, 0, sizeof(conf));
if (stl_parsebrd(, stl_brdsp[i]) == 0)
continue;
--
Darren Williams
[EMAIL PROTECTED]
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.6.11-bk Stallion driver module clean up
These two patches continue the work that Wayne Meissner
started and are against the current bk tree.
These patches allow the stallion driver to be built-in and
loaded at boot time, the current #ifdef MODULE only allows
the init code to be included if compiled as a module.
Tested for compile, boot and running on our console server
as module and built-in.
Signed-off-by Darren Williams [EMAIL PROTECTED]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/25 15:17:25+11:00 [EMAIL PROTECTED]
# stallion serial driver module clean up
#
# drivers/char/stallion.c
# 2005/02/25 15:17:16+11:00 [EMAIL PROTECTED] +5 -18
# Remove #define MODULE, and update module parameter declarations
#
Index: linux-2.5-import/drivers/char/stallion.c
===
--- linux-2.5-import.orig/drivers/char/stallion.c 2005-03-10
21:09:13.0 +1100
+++ linux-2.5-import/drivers/char/stallion.c2005-03-10 21:36:00.0
+1100
@@ -232,13 +232,12 @@
/*/
-#ifdef MODULE
/*
* Define some string labels for arguments passed from the module
* load line. These allow for easy board definitions, and easy
* modification of the io, memory and irq resoucres.
*/
-
+static int stl_nargs = 0;
static char*board0[4];
static char*board1[4];
static char*board2[4];
@@ -299,17 +298,15 @@
MODULE_DESCRIPTION(Stallion Multiport Serial Driver);
MODULE_LICENSE(GPL);
-MODULE_PARM(board0, 1-4s);
+module_param_array(board0, charp, stl_nargs, 0);
MODULE_PARM_DESC(board0, Board 0 config - name[,ioaddr[,ioaddr2][,irq]]);
-MODULE_PARM(board1, 1-4s);
+module_param_array(board1, charp, stl_nargs, 0);
MODULE_PARM_DESC(board1, Board 1 config - name[,ioaddr[,ioaddr2][,irq]]);
-MODULE_PARM(board2, 1-4s);
+module_param_array(board2, charp, stl_nargs, 0);
MODULE_PARM_DESC(board2, Board 2 config - name[,ioaddr[,ioaddr2][,irq]]);
-MODULE_PARM(board3, 1-4s);
+module_param_array(board3, charp, stl_nargs, 0);
MODULE_PARM_DESC(board3, Board 3 config - name[,ioaddr[,ioaddr2][,irq]]);
-#endif
-
/*/
/*
@@ -464,12 +461,10 @@
* Declare all those functions in this driver!
*/
-#ifdef MODULE
static voidstl_argbrds(void);
static int stl_parsebrd(stlconf_t *confp, char **argp);
static unsigned long stl_atol(char *str);
-#endif
intstl_init(void);
static int stl_open(struct tty_struct *tty, struct file *filp);
@@ -726,8 +721,6 @@
static struct class_simple *stallion_class;
-#ifdef MODULE
-
/*
* Loadable module initialization stuff.
*/
@@ -950,8 +943,6 @@
return(1);
}
-#endif
-
/*/
/*
@@ -2787,9 +2778,7 @@
*/
for (i = 0; (i stl_nrbrds); i++) {
confp = stl_brdconf[i];
-#ifdef MODULE
stl_parsebrd(confp, stl_brdsp[i]);
-#endif
if ((brdp = stl_allocbrd()) == (stlbrd_t *) NULL)
return(-ENOMEM);
brdp-brdnr = i;
@@ -2805,9 +2794,7 @@
* Find any dynamically supported boards. That is via module load
* line options or auto-detected on the PCI bus.
*/
-#ifdef MODULE
stl_argbrds();
-#endif
#ifdef CONFIG_PCI
stl_findpcibrds();
#endif
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/25 15:22:21+11:00 [EMAIL PROTECTED]
# remove old 'nrargs' module argument count
#
# drivers/char/stallion.c
# 2005/02/25 15:22:12+11:00 [EMAIL PROTECTED] +2 -4
# module arguments are now declared with module paramater declarations
#
Index: linux-2.5-import/drivers/char/stallion.c
===
--- linux-2.5-import.orig/drivers/char/stallion.c 2005-03-10
21:36:00.0 +1100
+++ linux-2.5-import/drivers/char/stallion.c2005-03-10 21:36:41.0
+1100
@@ -835,15 +835,13 @@
{
stlconf_t conf;
stlbrd_t*brdp;
- int nrargs, i;
+ int i;
#ifdef DEBUG
printk(stl_argbrds()\n);
#endif
- nrargs = sizeof(stl_brdsp) / sizeof(char **);
-
- for (i = stl_nrbrds; (i nrargs); i++) {
+ for (i = stl_nrbrds; (i stl_nargs); i++) {
memset(conf, 0, sizeof(conf));
if (stl_parsebrd(conf, stl_brdsp[i]) == 0)
continue;
--
Darren Williams dsw AT gelato.unsw.edu.au
[EMAIL PROTECTED] www.gelato.unsw.edu.au
--
-
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
Re: Page fault scalability patch V18: Overview
Hi Christoph On Sun, 06 Mar 2005, Christoph Lameter wrote: > On Mon, 7 Mar 2005, Darren Williams wrote: > > > Hi Christoph > > > > On Fri, 04 Mar 2005, Christoph Lameter wrote: > > > > > Make sure that scrubd_stop on startup is set to 2 and no zero in > > > mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. > > > > > unsigned int sysctl_scrub_stop = 2; /* Mininum order of page to zero */ > > > > This is the assignment when page zero fails. > > Could you just test this with the prezeroing patches alone? > Include a dmesg from a successful boot and then tell me what > you changed and where the boot failed. Which version of the patches did > you apply? > PATCHES: ftp://oss.sgi.com/projects/page_fault_performance/download/prezero/patch/patchset-2.6.11/ No scrubd_stop cat /proc/sys/vm/scrub_stop 2 /etc/sysctl.conf vm.scrub_stop=2 CONFIG_SCRUBD =N=Y Boots OK FAILED Oops of failed prezero boot: /dev/sdb4 has been mounted 31 times without being checked, check forced.Unable to handle kernel NULL pointer dereference (address )% kscrubd0[362]: Oops 11012296146944 [1] Pid: 362, CPU 0, comm: kscrubd0 psr : 121008022038 ifs : 8308 ip : []Not tainted ip is at scrubd_rmpage+0x61/0x140 unat: pfs : 0308 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001000cf7f0 b6 : a0012d70 b7 : a0019ff0 f6 : 1003e6db6db6db6db6db7 f7 : 0fff4847277b8 f8 : 1003e1c07c8b4 f9 : 1003ec4367cec f10 : 10017a77079199649f035 f11 : 1003e014ee0f2 r1 : a00100a53d80 r2 : 00100100 r3 : e721fe04fdd0 r8 : 001008026038 r9 : e70020041070 r10 : 0008 r11 : 00200200 r12 : e721fe04fdc0 r13 : e721fe048000 r14 : r15 : fffd r16 : r17 : a0007fffabf48000 r18 : c000 r19 : r20 : efff r21 : 0001 r22 : 0002 r23 : r24 : r25 : r26 : r27 : 001008026038 r28 : e721fe04fdd0 r29 : a0007fffabf4a7e0 r30 : r31 : e70020041080 Call Trace: [] show_stack+0x80/0xa0 sp=e721fe04f980 bsp=e721fe049010 [] show_regs+0x7e0/0x800 sp=e721fe04fb50 bsp=e721fe048fa8 [] die+0x150/0x1c0 sp=e721fe04fb60 bsp=e721fe048f68 [] ia64_do_page_fault+0x370/0x980 sp=e721fe04fb60 bsp=e721fe048f00 [] ia64_leave_kernel+0x0/0x260 sp=e721fe04fbf0 bsp=e721fe048f00 [] scrubd_rmpage+0x60/0x140 sp=e721fe04fdc0 bsp=e721fe048ec0 [] zero_highest_order_page+0x120/0x2c0 sp=e721fe04fdc0 bsp=e721fe048e68 [] scrub_pgdat+0x110/0x1c0 sp=e721fe04fdd0 bsp=e721fe048e30 [] kscrubd+0x220/0x240 sp=e721fe04fdd0 bsp=e721fe048e00 [] kernel_thread_helper+0xd0/0x100 sp=e721fe04fe30 bsp=e721fe048dd0 [] start_kernel_thread+0x20/0x40 sp=e721fe04fe30 bsp=e721fe048dd0 <1>Unable to handle kernel NULL pointer dereference (address ) kscrubd1[363]: Oops 11012296146944 [2] Pid: 363, CPU 6, comm: kscrubd1 psr : 121008022018 ifs : 8308 ip : []Not tainted ip is at scrubd_rmpage+0x61/0x140 unat: pfs : 0308 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001000cf7f0 b6 : a0012d70 b7 : a0019ff0 f6 : 1003e6db6db6db6db6db7 f7 : 0fff68a476010 f8 : 1003e1c87f85a f9 : 1003ec7b7ca76 f10 : 100188a47600ff75b89ff f11 : 1003e02291d80 r1 : a00100a53d80 r2 : 00100100 r3 : e741fe427dd0 r8 : 001008026018 r9 : e72510f0 r10 : 0008 r11 : 00200200 r12 : e741fe427dc0 r13 : e741fe42 r14 : r15 : fffd r16 : r17 : a0007fffc7ff r18 : c000 r19 : r20 : efff r21 : 0001 r22 : 0001 r23 : r24 : r25 : r26 : r27 : 001008026018 r28 : e741fe427dd0 r29 : a
Re: Page fault scalability patch V18: Overview
Hi Christoph On Fri, 04 Mar 2005, Christoph Lameter wrote: > Make sure that scrubd_stop on startup is set to 2 and no zero in > mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. > unsigned int sysctl_scrub_stop = 2; /* Mininum order of page to zero */ This is the assignment when page zero fails. Darren > On Fri, 4 Mar 2005, Darren Williams wrote: > > > Hi Darren > > > > On Fri, 04 Mar 2005, Darren Williams wrote: > > > > > Hi Christoph > > > > > > On Tue, 01 Mar 2005, Christoph Lameter wrote: > > > > > > > Is there any chance that this patchset could go into mm now? This has > > > > been > > > > discussed since last August > > > > > > > > Changelog: > > > > > > > > V17->V18 Rediff against 2.6.11-rc5-bk4 > > > > > > Just applied this patch against 2.6.11, however with the patch applied > > > and all the aditional config options not set, the kernel hangs at > > > Freeing unused kernel memory: 240kB freed > > > FYI: > > > > > > bootatomic prezero > > > OKon on > > > fail off on > > > fail off off > > > OKon off > > > > A bit extra info on the system: > > HP rx8620 Itanium(R) 2 16way > > > > > > > > > V16->V17 Do not increment page_count in do_wp_page. Performance data > > > > posted. > > > > V15->V16 of this patch: Redesign to allow full backback > > > > for architectures that do not supporting atomic operations. > > > > > > > > An introduction to what this patch does and a patch archive can be > > > > found on > > > > http://oss.sgi.com/projects/page_fault_performance. The archive also > > > > has the > > > > result of various performance tests (LMBench, Microbenchmark and > > > > kernel compiles). > > > > > > > > The basic approach in this patchset is the same as used in SGI's 2.4.X > > > > based kernels which have been in production use in ProPack 3 for a long > > > > time. > > > > > > > > The patchset is composed of 4 patches (and was tested against > > > > 2.6.11-rc5-bk4): > > > > > > > [SNIP] > > > > > > > - > > > > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in > > > > the body of a message to [EMAIL PROTECTED] > > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- > > > Darren Williams > > > [EMAIL PROTECTED] > > > -- > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > -- > > Darren Williams > > [EMAIL PROTECTED] > > -- > > > - > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams [EMAIL PROTECTED] -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Overview
Hi Christoph On Fri, 04 Mar 2005, Christoph Lameter wrote: Make sure that scrubd_stop on startup is set to 2 and no zero in mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. unsigned int sysctl_scrub_stop = 2; /* Mininum order of page to zero */ This is the assignment when page zero fails. Darren On Fri, 4 Mar 2005, Darren Williams wrote: Hi Darren On Fri, 04 Mar 2005, Darren Williams wrote: Hi Christoph On Tue, 01 Mar 2005, Christoph Lameter wrote: Is there any chance that this patchset could go into mm now? This has been discussed since last August Changelog: V17-V18 Rediff against 2.6.11-rc5-bk4 Just applied this patch against 2.6.11, however with the patch applied and all the aditional config options not set, the kernel hangs at Freeing unused kernel memory: 240kB freed FYI: bootatomic prezero OKon on fail off on fail off off OKon off A bit extra info on the system: HP rx8620 Itanium(R) 2 16way V16-V17 Do not increment page_count in do_wp_page. Performance data posted. V15-V16 of this patch: Redesign to allow full backback for architectures that do not supporting atomic operations. An introduction to what this patch does and a patch archive can be found on http://oss.sgi.com/projects/page_fault_performance. The archive also has the result of various performance tests (LMBench, Microbenchmark and kernel compiles). The basic approach in this patchset is the same as used in SGI's 2.4.X based kernels which have been in production use in ProPack 3 for a long time. The patchset is composed of 4 patches (and was tested against 2.6.11-rc5-bk4): [SNIP] - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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/ -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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: Page fault scalability patch V18: Overview
Hi Christoph On Sun, 06 Mar 2005, Christoph Lameter wrote: On Mon, 7 Mar 2005, Darren Williams wrote: Hi Christoph On Fri, 04 Mar 2005, Christoph Lameter wrote: Make sure that scrubd_stop on startup is set to 2 and no zero in mm/scrubd.c. The current patch on oss.sgi.com may have that set to zero. unsigned int sysctl_scrub_stop = 2; /* Mininum order of page to zero */ This is the assignment when page zero fails. Could you just test this with the prezeroing patches alone? Include a dmesg from a successful boot and then tell me what you changed and where the boot failed. Which version of the patches did you apply? PATCHES: ftp://oss.sgi.com/projects/page_fault_performance/download/prezero/patch/patchset-2.6.11/ No scrubd_stop cat /proc/sys/vm/scrub_stop 2 /etc/sysctl.conf vm.scrub_stop=2 CONFIG_SCRUBD =N=Y Boots OK FAILED Oops of failed prezero boot: /dev/sdb4 has been mounted 31 times without being checked, check forced.Unable to handle kernel NULL pointer dereference (address )% kscrubd0[362]: Oops 11012296146944 [1] Pid: 362, CPU 0, comm: kscrubd0 psr : 121008022038 ifs : 8308 ip : [a001000cf821]Not tainted ip is at scrubd_rmpage+0x61/0x140 unat: pfs : 0308 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001000cf7f0 b6 : a0012d70 b7 : a0019ff0 f6 : 1003e6db6db6db6db6db7 f7 : 0fff4847277b8 f8 : 1003e1c07c8b4 f9 : 1003ec4367cec f10 : 10017a77079199649f035 f11 : 1003e014ee0f2 r1 : a00100a53d80 r2 : 00100100 r3 : e721fe04fdd0 r8 : 001008026038 r9 : e70020041070 r10 : 0008 r11 : 00200200 r12 : e721fe04fdc0 r13 : e721fe048000 r14 : r15 : fffd r16 : r17 : a0007fffabf48000 r18 : c000 r19 : r20 : efff r21 : 0001 r22 : 0002 r23 : r24 : r25 : r26 : r27 : 001008026038 r28 : e721fe04fdd0 r29 : a0007fffabf4a7e0 r30 : r31 : e70020041080 Call Trace: [a001f3a0] show_stack+0x80/0xa0 sp=e721fe04f980 bsp=e721fe049010 [a001fc00] show_regs+0x7e0/0x800 sp=e721fe04fb50 bsp=e721fe048fa8 [a001000335f0] die+0x150/0x1c0 sp=e721fe04fb60 bsp=e721fe048f68 [a00100052430] ia64_do_page_fault+0x370/0x980 sp=e721fe04fb60 bsp=e721fe048f00 [a001a780] ia64_leave_kernel+0x0/0x260 sp=e721fe04fbf0 bsp=e721fe048f00 [a001000cf820] scrubd_rmpage+0x60/0x140 sp=e721fe04fdc0 bsp=e721fe048ec0 [a0010010e080] zero_highest_order_page+0x120/0x2c0 sp=e721fe04fdc0 bsp=e721fe048e68 [a0010010e330] scrub_pgdat+0x110/0x1c0 sp=e721fe04fdd0 bsp=e721fe048e30 [a0010010e600] kscrubd+0x220/0x240 sp=e721fe04fdd0 bsp=e721fe048e00 [a00100011410] kernel_thread_helper+0xd0/0x100 sp=e721fe04fe30 bsp=e721fe048dd0 [a00190e0] start_kernel_thread+0x20/0x40 sp=e721fe04fe30 bsp=e721fe048dd0 1Unable to handle kernel NULL pointer dereference (address ) kscrubd1[363]: Oops 11012296146944 [2] Pid: 363, CPU 6, comm: kscrubd1 psr : 121008022018 ifs : 8308 ip : [a001000cf821]Not tainted ip is at scrubd_rmpage+0x61/0x140 unat: pfs : 0308 rsc : 0003 rnat: bsps: pr : 9641 ldrs: ccv : fpsr: 0009804c8a70433f csd : ssd : b0 : a001000cf7f0 b6 : a0012d70 b7 : a0019ff0 f6 : 1003e6db6db6db6db6db7 f7 : 0fff68a476010 f8 : 1003e1c87f85a f9 : 1003ec7b7ca76 f10 : 100188a47600ff75b89ff f11 : 1003e02291d80 r1 : a00100a53d80 r2 : 00100100 r3 : e741fe427dd0 r8 : 001008026018 r9 : e72510f0 r10 : 0008 r11 : 00200200 r12 : e741fe427dc0 r13 : e741fe42 r14 : r15 : fffd r16 : r17 : a0007fffc7ff r18 : c000 r19 : r20 : efff r21 : 0001 r22 : 0001 r23 : r24 : r25 : r26 : r27
Re: Page fault scalability patch V18: Overview
Hi Darren On Fri, 04 Mar 2005, Darren Williams wrote: > Hi Christoph > > On Tue, 01 Mar 2005, Christoph Lameter wrote: > > > Is there any chance that this patchset could go into mm now? This has been > > discussed since last August > > > > Changelog: > > > > V17->V18 Rediff against 2.6.11-rc5-bk4 > > Just applied this patch against 2.6.11, however with the patch applied > and all the aditional config options not set, the kernel hangs at > Freeing unused kernel memory: 240kB freed > FYI: > > bootatomic prezero > OKon on > fail off on > fail off off > OKon off A bit extra info on the system: HP rx8620 Itanium(R) 2 16way > > > V16->V17 Do not increment page_count in do_wp_page. Performance data > > posted. > > V15->V16 of this patch: Redesign to allow full backback > > for architectures that do not supporting atomic operations. > > > > An introduction to what this patch does and a patch archive can be found on > > http://oss.sgi.com/projects/page_fault_performance. The archive also has the > > result of various performance tests (LMBench, Microbenchmark and > > kernel compiles). > > > > The basic approach in this patchset is the same as used in SGI's 2.4.X > > based kernels which have been in production use in ProPack 3 for a long > > time. > > > > The patchset is composed of 4 patches (and was tested against > > 2.6.11-rc5-bk4): > > > [SNIP] > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > Darren Williams > [EMAIL PROTECTED] > -- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Darren Williams [EMAIL PROTECTED] -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Overview
Hi Christoph On Tue, 01 Mar 2005, Christoph Lameter wrote: > Is there any chance that this patchset could go into mm now? This has been > discussed since last August > > Changelog: > > V17->V18 Rediff against 2.6.11-rc5-bk4 Just applied this patch against 2.6.11, however with the patch applied and all the aditional config options not set, the kernel hangs at Freeing unused kernel memory: 240kB freed FYI: bootatomic prezero OKon on fail off on fail off off OKon off > V16->V17 Do not increment page_count in do_wp_page. Performance data > posted. > V15->V16 of this patch: Redesign to allow full backback > for architectures that do not supporting atomic operations. > > An introduction to what this patch does and a patch archive can be found on > http://oss.sgi.com/projects/page_fault_performance. The archive also has the > result of various performance tests (LMBench, Microbenchmark and > kernel compiles). > > The basic approach in this patchset is the same as used in SGI's 2.4.X > based kernels which have been in production use in ProPack 3 for a long time. > > The patchset is composed of 4 patches (and was tested against 2.6.11-rc5-bk4): > [SNIP] > - > To unsubscribe from this list: send the line "unsubscribe linux-ia64" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams [EMAIL PROTECTED] -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Page fault scalability patch V18: Overview
Hi Christoph On Tue, 01 Mar 2005, Christoph Lameter wrote: Is there any chance that this patchset could go into mm now? This has been discussed since last August Changelog: V17-V18 Rediff against 2.6.11-rc5-bk4 Just applied this patch against 2.6.11, however with the patch applied and all the aditional config options not set, the kernel hangs at Freeing unused kernel memory: 240kB freed FYI: bootatomic prezero OKon on fail off on fail off off OKon off V16-V17 Do not increment page_count in do_wp_page. Performance data posted. V15-V16 of this patch: Redesign to allow full backback for architectures that do not supporting atomic operations. An introduction to what this patch does and a patch archive can be found on http://oss.sgi.com/projects/page_fault_performance. The archive also has the result of various performance tests (LMBench, Microbenchmark and kernel compiles). The basic approach in this patchset is the same as used in SGI's 2.4.X based kernels which have been in production use in ProPack 3 for a long time. The patchset is composed of 4 patches (and was tested against 2.6.11-rc5-bk4): [SNIP] - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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: Page fault scalability patch V18: Overview
Hi Darren On Fri, 04 Mar 2005, Darren Williams wrote: Hi Christoph On Tue, 01 Mar 2005, Christoph Lameter wrote: Is there any chance that this patchset could go into mm now? This has been discussed since last August Changelog: V17-V18 Rediff against 2.6.11-rc5-bk4 Just applied this patch against 2.6.11, however with the patch applied and all the aditional config options not set, the kernel hangs at Freeing unused kernel memory: 240kB freed FYI: bootatomic prezero OKon on fail off on fail off off OKon off A bit extra info on the system: HP rx8620 Itanium(R) 2 16way V16-V17 Do not increment page_count in do_wp_page. Performance data posted. V15-V16 of this patch: Redesign to allow full backback for architectures that do not supporting atomic operations. An introduction to what this patch does and a patch archive can be found on http://oss.sgi.com/projects/page_fault_performance. The archive also has the result of various performance tests (LMBench, Microbenchmark and kernel compiles). The basic approach in this patchset is the same as used in SGI's 2.4.X based kernels which have been in production use in ProPack 3 for a long time. The patchset is composed of 4 patches (and was tested against 2.6.11-rc5-bk4): [SNIP] - To unsubscribe from this list: send the line unsubscribe linux-ia64 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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/ -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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: BUG: stallion module cannot register it's ISR in a 2.6.10 kernel on a FC3 system
Hi Burn
Could you try the attached patch
It solved the same problem for me, it is NOT SMP safe due
to cli() calls, though will run fine on your system. I have been
running a console box for about 1mth non-stop with these applied.
The patch does two things it allows the driver to be built-in and
updates the call to request_irq, which is what is causing the
problem.
On Fri, 18 Feb 2005, Burn Alting wrote:
> Here is the bug report. Stallion was purchased by Lantronix and they
> don't really care about this bug.
>
>
>
> -
> 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/
------
Darren Williams
[EMAIL PROTECTED]
--
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/12/08 13:37:06+11:00 [EMAIL PROTECTED]
# Allow stallion console driver to be built-in, and register irqs correctly
with dev_id != NULL
#
# Signed-off Darren Williams
# drivers/char/stallion.c
# 2004/12/08 13:36:57+11:00 [EMAIL PROTECTED] +12 -15
# Pass non NULL dev_id to request_irq to allow correct irq registration. We
use the board pointer as the dev_id
# to allow unique identification across shared interupts.
#
# Remove remaining #ifdef MODULES to allow for built-in support.
#
# Signed-off Darren Williams
#
diff -Nru a/drivers/char/stallion.c b/drivers/char/stallion.c
--- a/drivers/char/stallion.c 2004-12-08 13:44:57 +11:00
+++ b/drivers/char/stallion.c 2004-12-08 13:44:57 +11:00
@@ -240,7 +240,6 @@
/*/
-#ifdef MODULE
/*
* Define some string labels for arguments passed from the module
* load line. These allow for easy board definitions, and easy
@@ -316,7 +315,6 @@
MODULE_PARM(board3, "1-4s");
MODULE_PARM_DESC(board3, "Board 3 config -> name[,ioaddr[,ioaddr2][,irq]]");
-#endif
/*/
@@ -472,12 +470,10 @@
* Declare all those functions in this driver!
*/
-#ifdef MODULE
static voidstl_argbrds(void);
static int stl_parsebrd(stlconf_t *confp, char **argp);
static unsigned long stl_atol(char *str);
-#endif
intstl_init(void);
static int stl_open(struct tty_struct *tty, struct file *filp);
@@ -504,7 +500,7 @@
static int stl_brdinit(stlbrd_t *brdp);
static int stl_initports(stlbrd_t *brdp, stlpanel_t *panelp);
-static int stl_mapirq(int irq, char *name);
+static int stl_mapirq(stlbrd_t *brdp, char *name);
static int stl_getserial(stlport_t *portp, struct serial_struct __user
*sp);
static int stl_setserial(stlport_t *portp, struct serial_struct __user
*sp);
static int stl_getbrdstats(combrd_t __user *bp);
@@ -735,7 +731,6 @@
static struct class_simple *stallion_class;
-#ifdef MODULE
/*
* Loadable module initialization stuff.
@@ -959,7 +954,6 @@
return(1);
}
-#endif
/*/
@@ -2179,26 +2173,27 @@
* interrupt across multiple boards.
*/
-static int __init stl_mapirq(int irq, char *name)
+static int __init stl_mapirq(stlbrd_t *brdp, char *name)
{
int rc, i;
#ifdef DEBUG
- printk("stl_mapirq(irq=%d,name=%s)\n", irq, name);
+ printk("stl_mapirq(irq=%d,name=%s)\n", brdp->irq, name);
#endif
rc = 0;
for (i = 0; (i < stl_numintrs); i++) {
- if (stl_gotintrs[i] == irq)
+ if (stl_gotintrs[i] == brdp->irq)
break;
}
if (i >= stl_numintrs) {
- if (request_irq(irq, stl_intr, SA_SHIRQ, name, NULL) != 0) {
+ /* pass the unique board pointer for shared interrupt dev_id */
+ if ( request_irq(brdp->irq, stl_intr, SA_SHIRQ, name, brdp) !=
0) {
printk("STALLION: failed to register interrupt "
- "routine for %s irq=%d\n", name, irq);
+ "routine for %s irq=%d\n", name, brdp->irq);
rc = -ENODEV;
} else {
- stl_gotintrs[stl_numintrs++] = irq;
+ stl_gotintrs[stl_numintrs++] = brdp->irq;
}
}
return(rc);
@@ -2389,7 +2384,7 @@
brdp->nrpanels = 1;
brdp->state |= BRD_FOUND;
brdp->hwid = status;
- rc = stl_mapirq(brdp->irq, name);
+ rc = stl_mapirq(brdp, name);
return(rc);
}
@@ -2594,7 +2589,7 @@
outb((brdp->ioctr
Re: BUG: stallion module cannot register it's ISR in a 2.6.10 kernel on a FC3 system
Hi Burn
Could you try the attached patch
It solved the same problem for me, it is NOT SMP safe due
to cli() calls, though will run fine on your system. I have been
running a console box for about 1mth non-stop with these applied.
The patch does two things it allows the driver to be built-in and
updates the call to request_irq, which is what is causing the
problem.
On Fri, 18 Feb 2005, Burn Alting wrote:
Here is the bug report. Stallion was purchased by Lantronix and they
don't really care about this bug.
-
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/
--
Darren Williams dsw AT gelato.unsw.edu.au
[EMAIL PROTECTED] www.gelato.unsw.edu.au
--
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/12/08 13:37:06+11:00 [EMAIL PROTECTED]
# Allow stallion console driver to be built-in, and register irqs correctly
with dev_id != NULL
#
# Signed-off Darren Williams dswATgelato.unsw.edu.au
# drivers/char/stallion.c
# 2004/12/08 13:36:57+11:00 [EMAIL PROTECTED] +12 -15
# Pass non NULL dev_id to request_irq to allow correct irq registration. We
use the board pointer as the dev_id
# to allow unique identification across shared interupts.
#
# Remove remaining #ifdef MODULES to allow for built-in support.
#
# Signed-off Darren Williams dswATgelato.unsw.edu.au
#
diff -Nru a/drivers/char/stallion.c b/drivers/char/stallion.c
--- a/drivers/char/stallion.c 2004-12-08 13:44:57 +11:00
+++ b/drivers/char/stallion.c 2004-12-08 13:44:57 +11:00
@@ -240,7 +240,6 @@
/*/
-#ifdef MODULE
/*
* Define some string labels for arguments passed from the module
* load line. These allow for easy board definitions, and easy
@@ -316,7 +315,6 @@
MODULE_PARM(board3, 1-4s);
MODULE_PARM_DESC(board3, Board 3 config - name[,ioaddr[,ioaddr2][,irq]]);
-#endif
/*/
@@ -472,12 +470,10 @@
* Declare all those functions in this driver!
*/
-#ifdef MODULE
static voidstl_argbrds(void);
static int stl_parsebrd(stlconf_t *confp, char **argp);
static unsigned long stl_atol(char *str);
-#endif
intstl_init(void);
static int stl_open(struct tty_struct *tty, struct file *filp);
@@ -504,7 +500,7 @@
static int stl_brdinit(stlbrd_t *brdp);
static int stl_initports(stlbrd_t *brdp, stlpanel_t *panelp);
-static int stl_mapirq(int irq, char *name);
+static int stl_mapirq(stlbrd_t *brdp, char *name);
static int stl_getserial(stlport_t *portp, struct serial_struct __user
*sp);
static int stl_setserial(stlport_t *portp, struct serial_struct __user
*sp);
static int stl_getbrdstats(combrd_t __user *bp);
@@ -735,7 +731,6 @@
static struct class_simple *stallion_class;
-#ifdef MODULE
/*
* Loadable module initialization stuff.
@@ -959,7 +954,6 @@
return(1);
}
-#endif
/*/
@@ -2179,26 +2173,27 @@
* interrupt across multiple boards.
*/
-static int __init stl_mapirq(int irq, char *name)
+static int __init stl_mapirq(stlbrd_t *brdp, char *name)
{
int rc, i;
#ifdef DEBUG
- printk(stl_mapirq(irq=%d,name=%s)\n, irq, name);
+ printk(stl_mapirq(irq=%d,name=%s)\n, brdp-irq, name);
#endif
rc = 0;
for (i = 0; (i stl_numintrs); i++) {
- if (stl_gotintrs[i] == irq)
+ if (stl_gotintrs[i] == brdp-irq)
break;
}
if (i = stl_numintrs) {
- if (request_irq(irq, stl_intr, SA_SHIRQ, name, NULL) != 0) {
+ /* pass the unique board pointer for shared interrupt dev_id */
+ if ( request_irq(brdp-irq, stl_intr, SA_SHIRQ, name, brdp) !=
0) {
printk(STALLION: failed to register interrupt
- routine for %s irq=%d\n, name, irq);
+ routine for %s irq=%d\n, name, brdp-irq);
rc = -ENODEV;
} else {
- stl_gotintrs[stl_numintrs++] = irq;
+ stl_gotintrs[stl_numintrs++] = brdp-irq;
}
}
return(rc);
@@ -2389,7 +2384,7 @@
brdp-nrpanels = 1;
brdp-state |= BRD_FOUND;
brdp-hwid = status;
- rc = stl_mapirq(brdp-irq, name);
+ rc = stl_mapirq(brdp, name);
return(rc);
}
@@ -2594,7 +2589,7 @@
outb((brdp-ioctrlval | ECH_BRDDISABLE), brdp-ioctrl);
brdp-state |= BRD_FOUND;
- i = stl_mapirq(brdp-irq
Re: 2.6.11-rc3-bk5: XFS: fcron: could not write() buf to disk: Resource temporarily unavailable
CK_SHARED)) {
> if (xfs_ipincount(ip) || !xfs_iflock_nowait(ip)) {
> xfs_iunlock(ip, XFS_ILOCK_SHARED);
> - return EAGAIN;
> + return error;
> }
> } else {
> - return EAGAIN;
> + return error;
> }
>
> if (flags & FLUSH_SYNC)
> Index: test/fs/xfs/linux-2.6/xfs_lrw.c
> ===
> --- test.orig/fs/xfs/linux-2.6/xfs_lrw.c
> +++ test/fs/xfs/linux-2.6/xfs_lrw.c
> @@ -962,9 +962,9 @@
> xfs_trans_set_sync(tp);
> error = xfs_trans_commit(tp, 0, NULL);
> xfs_iunlock(xip, XFS_ILOCK_EXCL);
> - if (error)
> - goto out_unlock_internal;
> }
> + if (error)
> + goto out_unlock_internal;
> }
>
> xfs_rwunlock(bdp, locktype);
> -
> 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/
--
Darren Williams
[EMAIL PROTECTED]
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-bk5: XFS: fcron: could not write() buf to disk: Resource temporarily unavailable
@@ xfs_trans_set_sync(tp); error = xfs_trans_commit(tp, 0, NULL); xfs_iunlock(xip, XFS_ILOCK_EXCL); - if (error) - goto out_unlock_internal; } + if (error) + goto out_unlock_internal; } xfs_rwunlock(bdp, locktype); - 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/ -- Darren Williams dsw AT gelato.unsw.edu.au [EMAIL PROTECTED] www.gelato.unsw.edu.au -- - 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: Horrible regression with -CURRENT from "Don't busy-lock-loop in preemptable spinlocks" patch
On Tue, 18 Jan 2005, Darren Williams wrote:
> Hi Ingo
>
> On Mon, 17 Jan 2005, Ingo Molnar wrote:
>
> >
> > * Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > > +BUILD_LOCK_OPS(spin, spinlock_t, spin_is_locked);
> > > > +BUILD_LOCK_OPS(read, rwlock_t, rwlock_is_locked);
> > > > +BUILD_LOCK_OPS(write, rwlock_t, spin_is_locked);
> > >
> > > If you replace the last line with
> > >
> > > BUILD_LOCK_OPS(write, rwlock_t, rwlock_is_locked);
> > >
> > > does it help?
> >
> > this is not enough - the proper solution should be the patch below,
> > which i sent earlier today as a reply to Paul Mackerras' comments.
> >
> > Ingo
> >
> > --
> > the first fix is that there was no compiler warning on x86 because it
> > uses macros - i fixed this by changing the spinlock field to be
> > '->slock'. (we could also use inline functions to get type protection, i
> > chose this solution because it was the easiest to do.)
> >
> > the second fix is to split rwlock_is_locked() into two functions:
> >
> > +/**
> > + * read_is_locked - would read_trylock() fail?
> > + * @lock: the rwlock in question.
> > + */
> > +#define read_is_locked(x) (atomic_read((atomic_t *)&(x)->lock) <= 0)
> > +
> > +/**
> > + * write_is_locked - would write_trylock() fail?
> > + * @lock: the rwlock in question.
> > + */
> > +#define write_is_locked(x) ((x)->lock != RW_LOCK_BIAS)
> >
> > this canonical naming of them also enabled the elimination of the newly
> > added 'is_locked_fn' argument to the BUILD_LOCK_OPS macro.
> >
> > the third change was to change the other user of rwlock_is_locked(), and
> > to put a migration helper there: architectures that dont have
> > read/write_is_locked defined yet will get a #warning message but the
> > build will succeed. (except if PREEMPT is enabled - there we really
> > need.)
> >
> > compile and boot-tested on x86, on SMP and UP, PREEMPT and !PREEMPT.
> > Non-x86 architectures should work fine, except PREEMPT+SMP builds which
> > will need the read_is_locked()/write_is_locked() definitions.
> > !PREEMPT+SMP builds will work fine and will produce a #warning.
> >
> > Ingo
> This may fix some archs however ia64 is still broken, with:
>
> kernel/built-in.o(.spinlock.text+0x8b2): In function `sched_init_smp':
> kernel/sched.c:650: undefined reference to `read_is_locked'
> kernel/built-in.o(.spinlock.text+0xa52): In function `sched_init':
> kernel/sched.c:687: undefined reference to `read_is_locked'
> kernel/built-in.o(.spinlock.text+0xcb2): In function `schedule':
> include/asm/bitops.h:279: undefined reference to `write_is_locked'
> kernel/built-in.o(.spinlock.text+0xe72): In function `schedule':
> include/linux/sched.h:1122: undefined reference to `write_is_locked'
> make: *** [.tmp_vmlinux1] Error 1
>
> include/asm-ia64/spinflock.h needs to define:
> read_is_locked(x)
> write_is_locked(x)
>
> someone who knows the locking code will need to fill in
> the blanks.
>
On top of Ingo's patch I attempt a solution that failed:
include/asm-ia64/spinlock.h: 1.23 1.24 dsw 05/01/18 10:22:35 (modified, needs
delta)
@@ -126,7 +126,8 @@
#define RW_LOCK_UNLOCKED (rwlock_t) { 0, 0 }
#define rwlock_init(x) do { *(x) = RW_LOCK_UNLOCKED; } while(0)
-#define rwlock_is_locked(x)(*(volatile int *) (x) != 0)
+#define read_is_locked(x) (*(volatile int *) (x) > 0)
+#define write_is_locked(x) (*(volatile int *) (x) < 0)
#define _raw_read_lock(rw)
\
do {
However this breaks on the simulator with:
Freeing unused kernel memory: 192kB freed
INIT: version 2.78 booting
kernel BUG at kernel/exit.c:870
> Darren
>
> >
> > Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
> >
> > --- linux/kernel/spinlock.c.orig
> > +++ linux/kernel/spinlock.c
> > @@ -173,7 +173,7 @@ EXPORT_SYMBOL(_write_lock);
> > * (We do this in a function because inlining it would be excessive.)
> > */
> >
> > -#define BUILD_LOCK_OPS(op, locktype, is_locked_fn) \
> > +#define BUILD_LOCK_OPS(op, locktype)
> > \
> > void __lockfunc _##op##_lock(locktype *lock)
> > \
> > { \
> > preempt_disable();
Re: Horrible regression with -CURRENT from "Don't busy-lock-loop in preemptable spinlocks" patch
\
> } \
> @@ -246,9 +246,9 @@ EXPORT_SYMBOL(_##op##_lock_bh)
> * _[spin|read|write]_lock_irqsave()
> * _[spin|read|write]_lock_bh()
> */
> -BUILD_LOCK_OPS(spin, spinlock_t, spin_is_locked);
> -BUILD_LOCK_OPS(read, rwlock_t, rwlock_is_locked);
> -BUILD_LOCK_OPS(write, rwlock_t, spin_is_locked);
> +BUILD_LOCK_OPS(spin, spinlock_t);
> +BUILD_LOCK_OPS(read, rwlock_t);
> +BUILD_LOCK_OPS(write, rwlock_t);
>
> #endif /* CONFIG_PREEMPT */
>
> --- linux/include/asm-i386/spinlock.h.orig
> +++ linux/include/asm-i386/spinlock.h
> @@ -15,7 +15,7 @@ asmlinkage int printk(const char * fmt,
> */
>
> typedef struct {
> - volatile unsigned int lock;
> + volatile unsigned int slock;
> #ifdef CONFIG_DEBUG_SPINLOCK
> unsigned magic;
> #endif
> @@ -43,7 +43,7 @@ typedef struct {
> * We make no fairness assumptions. They have a cost.
> */
>
> -#define spin_is_locked(x)(*(volatile signed char *)(&(x)->lock) <= 0)
> +#define spin_is_locked(x)(*(volatile signed char *)(&(x)->slock) <= 0)
> #define spin_unlock_wait(x) do { barrier(); } while(spin_is_locked(x))
>
> #define spin_lock_string \
> @@ -83,7 +83,7 @@ typedef struct {
>
> #define spin_unlock_string \
> "movb $1,%0" \
> - :"=m" (lock->lock) : : "memory"
> + :"=m" (lock->slock) : : "memory"
>
>
> static inline void _raw_spin_unlock(spinlock_t *lock)
> @@ -101,7 +101,7 @@ static inline void _raw_spin_unlock(spin
>
> #define spin_unlock_string \
> "xchgb %b0, %1" \
> - :"=q" (oldval), "=m" (lock->lock) \
> + :"=q" (oldval), "=m" (lock->slock) \
> :"0" (oldval) : "memory"
>
> static inline void _raw_spin_unlock(spinlock_t *lock)
> @@ -123,7 +123,7 @@ static inline int _raw_spin_trylock(spin
> char oldval;
> __asm__ __volatile__(
> "xchgb %b0,%1"
> - :"=q" (oldval), "=m" (lock->lock)
> + :"=q" (oldval), "=m" (lock->slock)
> :"0" (0) : "memory");
> return oldval > 0;
> }
> @@ -138,7 +138,7 @@ static inline void _raw_spin_lock(spinlo
> #endif
> __asm__ __volatile__(
>
spin_lock_string
> - :"=m" (lock->lock) : : "memory");
> + :"=m" (lock->slock) : : "memory");
> }
>
> static inline void _raw_spin_lock_flags (spinlock_t *lock, unsigned long
> flags)
> @@ -151,7 +151,7 @@ static inline void _raw_spin_lock_flags
> #endif
> __asm__ __volatile__(
> spin_lock_string_flags
> - :"=m" (lock->lock) : "r" (flags) : "memory");
> + :"=m" (lock->slock) : "r" (flags) : "memory");
> }
>
> /*
> @@ -186,7 +186,17 @@ typedef struct {
>
> #define rwlock_init(x) do { *(x) = RW_LOCK_UNLOCKED; } while(0)
>
> -#define rwlock_is_locked(x) ((x)->lock != RW_LOCK_BIAS)
> +/**
> + * read_is_locked - would read_trylock() fail?
> + * @lock: the rwlock in question.
> + */
> +#define read_is_locked(x) (atomic_read((atomic_t *)&(x)->lock) <= 0)
> +
> +/**
> + * write_is_locked - would write_trylock() fail?
> + * @lock: the rwlock in question.
> + */
> +#define write_is_locked(x) ((x)->lock != RW_LOCK_BIAS)
>
> /*
> * On x86, we implement read-write locks as a 32-bit counter
> --- linux/kernel/exit.c.orig
> +++ linux/kernel/exit.c
> @@ -861,8 +861,12 @@ task_t fastcall *next_thread(const task_
> #ifdef CONFIG_SMP
> if (!p->sighand)
> BUG();
> +#ifndef write_is_locked
> +# warning please implement read_is_locked()/write_is_locked()!
> +# define write_is_locked rwlock_is_locked
> +#endif
> if (!spin_is_locked(>sighand->siglock) &&
> - !rwlock_is_locked(_lock))
> + !write_is_locked(_lock))
> BUG();
> #endif
> return pid_task(p->pids[PIDTYPE_TGID].pid_list.next, PIDTYPE_TGID);
>
> -
> 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/
--
Darren Williams
[EMAIL PROTECTED]
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Horrible regression with -CURRENT from Don't busy-lock-loop in preemptable spinlocks patch
/* CONFIG_PREEMPT */
--- linux/include/asm-i386/spinlock.h.orig
+++ linux/include/asm-i386/spinlock.h
@@ -15,7 +15,7 @@ asmlinkage int printk(const char * fmt,
*/
typedef struct {
- volatile unsigned int lock;
+ volatile unsigned int slock;
#ifdef CONFIG_DEBUG_SPINLOCK
unsigned magic;
#endif
@@ -43,7 +43,7 @@ typedef struct {
* We make no fairness assumptions. They have a cost.
*/
-#define spin_is_locked(x)(*(volatile signed char *)((x)-lock) = 0)
+#define spin_is_locked(x)(*(volatile signed char *)((x)-slock) = 0)
#define spin_unlock_wait(x) do { barrier(); } while(spin_is_locked(x))
#define spin_lock_string \
@@ -83,7 +83,7 @@ typedef struct {
#define spin_unlock_string \
movb $1,%0 \
- :=m (lock-lock) : : memory
+ :=m (lock-slock) : : memory
static inline void _raw_spin_unlock(spinlock_t *lock)
@@ -101,7 +101,7 @@ static inline void _raw_spin_unlock(spin
#define spin_unlock_string \
xchgb %b0, %1 \
- :=q (oldval), =m (lock-lock) \
+ :=q (oldval), =m (lock-slock) \
:0 (oldval) : memory
static inline void _raw_spin_unlock(spinlock_t *lock)
@@ -123,7 +123,7 @@ static inline int _raw_spin_trylock(spin
char oldval;
__asm__ __volatile__(
xchgb %b0,%1
- :=q (oldval), =m (lock-lock)
+ :=q (oldval), =m (lock-slock)
:0 (0) : memory);
return oldval 0;
}
@@ -138,7 +138,7 @@ static inline void _raw_spin_lock(spinlo
#endif
__asm__ __volatile__(
spin_lock_string
- :=m (lock-lock) : : memory);
+ :=m (lock-slock) : : memory);
}
static inline void _raw_spin_lock_flags (spinlock_t *lock, unsigned long
flags)
@@ -151,7 +151,7 @@ static inline void _raw_spin_lock_flags
#endif
__asm__ __volatile__(
spin_lock_string_flags
- :=m (lock-lock) : r (flags) : memory);
+ :=m (lock-slock) : r (flags) : memory);
}
/*
@@ -186,7 +186,17 @@ typedef struct {
#define rwlock_init(x) do { *(x) = RW_LOCK_UNLOCKED; } while(0)
-#define rwlock_is_locked(x) ((x)-lock != RW_LOCK_BIAS)
+/**
+ * read_is_locked - would read_trylock() fail?
+ * @lock: the rwlock in question.
+ */
+#define read_is_locked(x) (atomic_read((atomic_t *)(x)-lock) = 0)
+
+/**
+ * write_is_locked - would write_trylock() fail?
+ * @lock: the rwlock in question.
+ */
+#define write_is_locked(x) ((x)-lock != RW_LOCK_BIAS)
/*
* On x86, we implement read-write locks as a 32-bit counter
--- linux/kernel/exit.c.orig
+++ linux/kernel/exit.c
@@ -861,8 +861,12 @@ task_t fastcall *next_thread(const task_
#ifdef CONFIG_SMP
if (!p-sighand)
BUG();
+#ifndef write_is_locked
+# warning please implement read_is_locked()/write_is_locked()!
+# define write_is_locked rwlock_is_locked
+#endif
if (!spin_is_locked(p-sighand-siglock)
- !rwlock_is_locked(tasklist_lock))
+ !write_is_locked(tasklist_lock))
BUG();
#endif
return pid_task(p-pids[PIDTYPE_TGID].pid_list.next, PIDTYPE_TGID);
-
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/
--
Darren Williams dsw AT gelato.unsw.edu.au
[EMAIL PROTECTED] www.gelato.unsw.edu.au
--
-
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: Horrible regression with -CURRENT from Don't busy-lock-loop in preemptable spinlocks patch
On Tue, 18 Jan 2005, Darren Williams wrote:
Hi Ingo
On Mon, 17 Jan 2005, Ingo Molnar wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
+BUILD_LOCK_OPS(spin, spinlock_t, spin_is_locked);
+BUILD_LOCK_OPS(read, rwlock_t, rwlock_is_locked);
+BUILD_LOCK_OPS(write, rwlock_t, spin_is_locked);
If you replace the last line with
BUILD_LOCK_OPS(write, rwlock_t, rwlock_is_locked);
does it help?
this is not enough - the proper solution should be the patch below,
which i sent earlier today as a reply to Paul Mackerras' comments.
Ingo
--
the first fix is that there was no compiler warning on x86 because it
uses macros - i fixed this by changing the spinlock field to be
'-slock'. (we could also use inline functions to get type protection, i
chose this solution because it was the easiest to do.)
the second fix is to split rwlock_is_locked() into two functions:
+/**
+ * read_is_locked - would read_trylock() fail?
+ * @lock: the rwlock in question.
+ */
+#define read_is_locked(x) (atomic_read((atomic_t *)(x)-lock) = 0)
+
+/**
+ * write_is_locked - would write_trylock() fail?
+ * @lock: the rwlock in question.
+ */
+#define write_is_locked(x) ((x)-lock != RW_LOCK_BIAS)
this canonical naming of them also enabled the elimination of the newly
added 'is_locked_fn' argument to the BUILD_LOCK_OPS macro.
the third change was to change the other user of rwlock_is_locked(), and
to put a migration helper there: architectures that dont have
read/write_is_locked defined yet will get a #warning message but the
build will succeed. (except if PREEMPT is enabled - there we really
need.)
compile and boot-tested on x86, on SMP and UP, PREEMPT and !PREEMPT.
Non-x86 architectures should work fine, except PREEMPT+SMP builds which
will need the read_is_locked()/write_is_locked() definitions.
!PREEMPT+SMP builds will work fine and will produce a #warning.
Ingo
This may fix some archs however ia64 is still broken, with:
kernel/built-in.o(.spinlock.text+0x8b2): In function `sched_init_smp':
kernel/sched.c:650: undefined reference to `read_is_locked'
kernel/built-in.o(.spinlock.text+0xa52): In function `sched_init':
kernel/sched.c:687: undefined reference to `read_is_locked'
kernel/built-in.o(.spinlock.text+0xcb2): In function `schedule':
include/asm/bitops.h:279: undefined reference to `write_is_locked'
kernel/built-in.o(.spinlock.text+0xe72): In function `schedule':
include/linux/sched.h:1122: undefined reference to `write_is_locked'
make: *** [.tmp_vmlinux1] Error 1
include/asm-ia64/spinflock.h needs to define:
read_is_locked(x)
write_is_locked(x)
someone who knows the locking code will need to fill in
the blanks.
On top of Ingo's patch I attempt a solution that failed:
include/asm-ia64/spinlock.h: 1.23 1.24 dsw 05/01/18 10:22:35 (modified, needs
delta)
@@ -126,7 +126,8 @@
#define RW_LOCK_UNLOCKED (rwlock_t) { 0, 0 }
#define rwlock_init(x) do { *(x) = RW_LOCK_UNLOCKED; } while(0)
-#define rwlock_is_locked(x)(*(volatile int *) (x) != 0)
+#define read_is_locked(x) (*(volatile int *) (x) 0)
+#define write_is_locked(x) (*(volatile int *) (x) 0)
#define _raw_read_lock(rw)
\
do {
However this breaks on the simulator with:
Freeing unused kernel memory: 192kB freed
INIT: version 2.78 booting
kernel BUG at kernel/exit.c:870
Darren
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
--- linux/kernel/spinlock.c.orig
+++ linux/kernel/spinlock.c
@@ -173,7 +173,7 @@ EXPORT_SYMBOL(_write_lock);
* (We do this in a function because inlining it would be excessive.)
*/
-#define BUILD_LOCK_OPS(op, locktype, is_locked_fn) \
+#define BUILD_LOCK_OPS(op, locktype)
\
void __lockfunc _##op##_lock(locktype *lock)
\
{ \
preempt_disable(); \
@@ -183,7 +183,7 @@ void __lockfunc _##op##_lock(locktype *l
preempt_enable(); \
if (!(lock)-break_lock)\
(lock)-break_lock = 1; \
- while (is_locked_fn(lock) (lock)-break_lock)\
+ while (op##_is_locked(lock) (lock)-break_lock) \
cpu_relax();\
preempt_disable(); \
} \
@@ -205,7 +205,7 @@ unsigned long __lockfunc _##op##_lock_ir
preempt_enable
