innofensive BUG and fix: area->map's size is not calculated ok
In a 2.4 kernel, mm/page_alloc.c:free_area_init_core(), in the following assignement... bitmap_size = size >> i; ...makes bitmap_size be the double of the needed size, this calculum assumes that with a 512 byte map size the kernel is mapping 8*512= 4096 chunks of memory, that is: one bit of the map is used for each chunk of memory, and that's not true. Really one bit of area->map is used to map two chunks of memory, so in the example above an area->map of just 256 bytes is really needed, the other 256 bytes are _never accessed_. So the righ thing would be to do is: bitmap_size = size >> (i+1); also I tested it and it works ok, so I believe I'm right... Please CC: your replies to (I'm not subscribed to this list) Ulisses Alonso Camaró <[EMAIL PROTECTED]> PD: my nick on #kernelnewbies is despistao Debian GNU/Linux: a dream come true - "Computers are useless. They can only give answers."Pablo Picasso --->Visita http://www.valux.org/ para saber acerca de la<--- --->Asociación Valenciana de Usuarios de Linux <--- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
BUG and fix: area->map's size is incorrect
Hi the bug doesn't impact stability but wastes memory, when more memory you have more memory you waste. please look this, it's a ONE line patch! this is an email I sent here two weeks ago, since I've got no reply (and neigher from linux-mm) i resend it to again, I've also attached aditional info at the end On Thu, Nov 30, 2000 at 10:17:42AM +0100, ulisses wrote: > > In a 2.4 kernel, mm/page_alloc.c:free_area_init_core(), in the following > assignement... > > bitmap_size = size >> i; > > ...makes bitmap_size be the double of the needed size, this calculum > assumes that with a 512 byte map size the kernel is mapping 8*512= 4096 chunks > of memory, that is: one bit of the map is used for each chunk of memory, > and that's not true. > > Really one bit of area->map is used to map two chunks of memory, so in the > example above an area->map of just 256 bytes is really needed, the other 256 > bytes are _never accessed_. > > So the righ thing would be to do is: > > bitmap_size = size >> (i+1); > > > also I tested it and it works ok, so I believe I'm right... > > > Please CC: your replies to (I'm not subscribed to this list) > > Ulisses Alonso Camaró <[EMAIL PROTECTED]> > > PD: my nick on #kernelnewbies is despistao an easy to understand indicator to see that I am right is to see (for instance) how a page index of area->map is calculated, in __free_pages_ok() we can see the following: page_idx = page - base; index = page_idx >> (1 + order); Imagine the order is 0, that is a continious block of PAGE_SIZE size, we still shift page_idx one bit, that is two blocks of "order" size are maped in each bit of area->map you can also see that MARK_USED macro also makes this shift Please CC: your replies to (I'm not subscribed to this list) Ulisses Alonso Camaró <[EMAIL PROTECTED]> PD: my nick on #kernelnewbies is despistao Debian GNU/Linux: a dream come true - "Computers are useless. They can only give answers."Pablo Picasso --->Visita http://www.valux.org/ para saber acerca de la<--- --->Asociación Valenciana de Usuarios de Linux <--- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[SysRq PATCH]: no more reboots because console freeze
Hi all
I made a very small patch to the SysRq facility that signals
a program with SIGUSR1, the program is registered via sysctl
The signal is launched with Alt+SysRq+X (X stands for eXecute program)
/proc/sys/kernel/sysrq_progid contains pid and start_time
which totally identifies the program to signal
One of the uses of this is restore the console when a X-server
or a SVGAlib program crashes
How many times did you have got to reboot because of that, while your
system may be doing something important??? this hopefully solves the problem
Patch is included below, sample programs/scripts are available at
http://pusa.uv.es/~ulisses/sysrq_X.tar.gz
Comments/sugestions wanted, please e-mail me directly to [EMAIL PROTECTED]
(I'm not subscribed to the linux-kernel mailing list)
Bye!
Ulisses
-
Debian GNU/Linux: a dream come true
-
diff -u -r linux-2.4.0-test8/drivers/char/sysrq.c
linux-2.4.0-test8-modificat2/drivers/char/sysrq.c
--- linux-2.4.0-test8/drivers/char/sysrq.c Tue Aug 1 04:36:10 2000
+++ linux-2.4.0-test8-modificat2/drivers/char/sysrq.c Mon Sep 25 08:58:23 2000
@@ -6,6 +6,8 @@
*
* (c) 1997 Martin Mares <[EMAIL PROTECTED]>
* based on ideas by Pavel Machek <[EMAIL PROTECTED]>
+ *
+ * (c) 2000 Ulisses Alonso Camaró eXecute_program extension
*/
#include
@@ -22,6 +24,7 @@
#include
#include
#include
+#include
#include
@@ -30,9 +33,13 @@
extern int console_loglevel;
extern struct list_head super_blocks;
+void signal_program(void);
+
/* Whether we react on sysrq keys or just ignore them */
int sysrq_enabled = 1;
+unsigned long sysrq_progid[2]= {0, 0}; /* pid and start_time */
+
/* Machine specific power off function */
void (*sysrq_power_off)(void) = NULL;
@@ -53,6 +60,35 @@
}
}
+void signal_program(void)
+{
+ struct task_struct *p;
+ pid_t pid= (pid_t)sysrq_progid[0];
+
+ read_lock(&tasklist_lock);
+
+ if ((p= find_task_by_pid(pid)) == NULL)
+ goto error;
+
+ if (!p->mm || p->pid == 1)
+ goto error;
+
+ if (p->start_time != sysrq_progid[1])
+ goto error;
+
+ send_sig(SIGUSR1, p, 0);
+
+ read_unlock(&tasklist_lock);
+
+ return;
+
+ error:
+ printk(KERN_ERR "SysRq: Could not send signal to pid %d with start_time
+%lu\n",
+ pid, sysrq_progid[1]);
+
+ return;
+}
+
/*
* This function is called by the keyboard handler when SysRq is pressed
* and any other keycode arrives.
@@ -138,6 +174,10 @@
send_sig_all(SIGKILL, 1);
orig_log_level = 8;
break;
+ case 'x':
+ printk("eXecute program\n");
+ signal_program();
+ break;
default:/* Unknown: help */
if (kbd)
printk("unRaw ");
@@ -148,7 +188,7 @@
printk("Boot ");
if (sysrq_power_off)
printk("Off ");
- printk("Sync Unmount showPc showTasks showMem loglevel0-8 tErm kIll
killalL\n");
+ printk("Sync Unmount showPc showTasks showMem loglevel0-8 tErm kIll
+killalL eXec_program\n");
/* Don't use 'A' as it's handled specially on the Sparc */
}
diff -u -r linux-2.4.0-test8/include/linux/sysctl.h
linux-2.4.0-test8-modificat2/include/linux/sysctl.h
--- linux-2.4.0-test8/include/linux/sysctl.hThu Aug 10 22:01:26 2000
+++ linux-2.4.0-test8-modificat2/include/linux/sysctl.h Sun Sep 24 12:39:30 2000
@@ -113,6 +113,7 @@
KERN_OVERFLOWGID=47,/* int: overflow GID */
KERN_SHMPATH=48,/* string: path to shm fs */
KERN_HOTPLUG=49,/* string: path to hotplug policy agent */
+ KERN_SYSRQ_PROGID=50/* string: pid and start_time of the program to signal
+*/
};
diff -u -r linux-2.4.0-test8/kernel/sysctl.c
linux-2.4.0-test8-modificat2/kernel/sysctl.c
--- linux-2.4.0-test8/kernel/sysctl.c Tue Aug 1 04:36:11 2000
+++ linux-2.4.0-test8-modificat2/kernel/sysctl.cMon Sep 25 08:59:24 2000
@@ -83,6 +83,10 @@
extern int acct_parm[];
#endif
+#ifdef CONFIG_MAGIC_SYSRQ
+extern unsigned long sysrq_progid[];
+#endif
+
extern int pgt_cache_water[];
static int parse_table(int *, int, void *, size_t *, void *, size_t,
@@ -220,6 +224,10 @@
#ifdef CONFIG_MAGIC_SYSRQ
{KERN_SYSRQ, "sysrq", &sysrq_enabled, sizeof (int),
0644, NULL, &proc_dointvec},
+ {KERN_SYSRQ_PROGID, "sysrq_progid", &sysrq_progid, 2*sizeof(unsigned long),
+ 0644, NULL, &proc_doulongvec_minmax, NULL,
+ (void *)NULL, (void *)NULL},
+/* (void *)&sysrq_progid_min, (void *)&sysrq_progid_max}, */
#endif
intel8x0: no sound in 2.6.11 rc3 & 4 (fine with 2.6.10)
Hello I have read a post in lkml.org that states that the problem experienced in rc3 has gone (1). That is not the case for me. My audio device is :00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) Subsystem: IBM: Unknown device 0554 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://pusa.uv.es/~ulisses/asound-intel8x0/ the tar files were done while playing pcm audio, (not being eard in rc4). I have found that I had to Mute __both__ "Headphone Jack Sense" and "Line Jack Sense" in order to ear the audio in rc4. Please let me know if you need further info or you want a tester All this is on a IBM Thinkpad R51 - Type 2887 -AVG (tot toc: IBM, we're buying your laptops too) Thanks in advance Ulisses (1) http://lkml.org/lkml/2005/2/18/93 -- Debian GNU/Linux: a dream come true - "Computers are useless. They can only give answers."Pablo Picasso "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - 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/
