[PATCH]: Only one memory zone for sparc64
Hi,
On sparc64 we dont care about the different memory zones and iterating
through them all over the place only serves to waste CPU. I suspect this
would be the case with some other architectures but for the moment I
have just enabled it for sparc64.
With this patch I get close to a 1% improvement in dbench on the dual
ultra60.
Anton
diff -ru linux/include/linux/mmzone.h linux_work/include/linux/mmzone.h
--- linux/include/linux/mmzone.hThu Mar 15 19:03:47 2001
+++ linux_work/include/linux/mmzone.h Tue Mar 13 18:46:59 2001
@@ -63,7 +63,19 @@
#define ZONE_DMA 0
#define ZONE_NORMAL1
#define ZONE_HIGHMEM 2
+#ifdef __sparc_v9__
+#define MAX_NR_ZONES 1
+#define ZONE_NAMES { "DMA" }
+#define ZONE_BALANCE_RATIO { 32 }
+#define ZONE_BALANCE_MIN { 10 }
+#define ZONE_BALANCE_MAX { 255 }
+#else
#define MAX_NR_ZONES 3
+#define ZONE_NAMES { "DMA", "Normal", "HighMem" }
+#define ZONE_BALANCE_RATIO { 32, 128, 128 }
+#define ZONE_BALANCE_MIN { 10, 10, 10 }
+#define ZONE_BALANCE_MAX { 255, 255, 255 }
+#endif
/*
* One allocation request operates on a zonelist. A zonelist
diff -ru linux/mm/page_alloc.c linux_work/mm/page_alloc.c
--- linux/mm/page_alloc.c Mon Mar 12 13:33:02 2001
+++ linux_work/mm/page_alloc.c Mon Mar 12 13:00:08 2001
@@ -23,10 +23,10 @@
int nr_inactive_dirty_pages;
pg_data_t *pgdat_list;
-static char *zone_names[MAX_NR_ZONES] = { "DMA", "Normal", "HighMem" };
-static int zone_balance_ratio[MAX_NR_ZONES] = { 32, 128, 128, };
-static int zone_balance_min[MAX_NR_ZONES] = { 10 , 10, 10, };
-static int zone_balance_max[MAX_NR_ZONES] = { 255 , 255, 255, };
+static char *zone_names[MAX_NR_ZONES] = ZONE_NAMES;
+static int zone_balance_ratio[MAX_NR_ZONES] = ZONE_BALANCE_RATIO;
+static int zone_balance_min[MAX_NR_ZONES] = ZONE_BALANCE_MIN;
+static int zone_balance_max[MAX_NR_ZONES] = ZONE_BALANCE_MAX;
struct list_head active_list;
struct list_head inactive_dirty_list;
-
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] add missing KERN_xxx to /linux/fs
Hi all,
IMHO subject is self explaining :)
Best regards.
--
Andrey Panin| Embedded systems software engineer
[EMAIL PROTECTED]| PGP key: http://www.orbita1.ru/~pazke/AndreyPanin.asc
diff -ur linux.vanilla/fs/buffer.c linux/fs/buffer.c
--- linux.vanilla/fs/buffer.c Thu Mar 15 22:06:19 2001
+++ linux/fs/buffer.c Thu Mar 15 20:52:49 2001
@@ -1122,7 +1122,7 @@
atomic_dec(&buf->b_count);
return;
}
- printk("VFS: brelse: Trying to free free buffer\n");
+ printk(KERN_ERR "VFS: brelse: Trying to free free buffer\n");
}
/*
@@ -2269,7 +2269,7 @@
int isize;
if ((size & 511) || (size > PAGE_SIZE)) {
- printk("VFS: grow_buffers: size = %d\n",size);
+ printk(KERN_ERR "VFS: grow_buffers: size = %d\n",size);
return 0;
}
@@ -2444,7 +2444,7 @@
static char *buf_types[NR_LIST] = { "CLEAN", "LOCKED", "DIRTY", "PROTECTED", };
#endif
- printk("Buffer memory: %6dkB\n",
+ printk(KERN_DEBUG "Buffer memory: %6dkB\n",
atomic_read(&buffermem_pages) << (PAGE_SHIFT-10));
#ifdef CONFIG_SMP /* trylock does nothing on UP and so we could deadlock */
@@ -2470,10 +2470,10 @@
{
int tmp = nr_buffers_type[nlist];
if (found != tmp)
- printk("%9s: BUG -> found %d, reported %d\n",
+ printk(KERN_DEBUG "%9s: BUG -> found %d, reported
+%d\n",
buf_types[nlist], found, tmp);
}
- printk("%9s: %d buffers, %lu kbyte, %d used (last=%d), "
+ printk(KERN_DEBUG "%9s: %d buffers, %lu kbyte, %d used (last=%d), "
"%d locked, %d protected, %d dirty\n",
buf_types[nlist], found, size_buffers_type[nlist]>>10,
used, lastused, locked, protected, dirty);
@@ -2521,7 +2521,7 @@
hash_table = (struct buffer_head **)
__get_free_pages(GFP_ATOMIC, order);
} while (hash_table == NULL && --order > 0);
- printk("Buffer-cache hash table entries: %d (order: %d, %ld bytes)\n",
+ printk(KERN_INFO "Buffer-cache hash table entries: %d (order: %d, %ld
+bytes)\n",
nr_hash, order, (PAGE_SIZE << order));
if (!hash_table)
@@ -2801,7 +2801,7 @@
goto stop_kupdate;
}
#ifdef DEBUG
- printk("kupdate() activated...\n");
+ printk(KERN_DEBUG "kupdate() activated...\n");
#endif
sync_old_buffers();
}
diff -ur linux.vanilla/fs/dquot.c linux/fs/dquot.c
--- linux.vanilla/fs/dquot.cThu Mar 15 22:06:19 2001
+++ linux/fs/dquot.cThu Mar 15 21:30:40 2001
@@ -186,7 +186,7 @@
{
#ifdef __DQUOT_PARANOIA
if (list_empty(&dquot->dq_free)) {
- printk("remove_free_dquot: dquot not on the free list??\n");
+ printk(KERN_ERR "remove_free_dquot: dquot not on the free list??\n");
return; /* J.K. Just don't do anything */
}
#endif
@@ -1006,8 +1006,8 @@
if (!dquot)
return;
if (!dquot->dq_count) {
- printk("VFS: dqput: trying to free free dquot\n");
- printk("VFS: device %s, dquot of %s %d\n",
+ printk(KERN_ERR "VFS: dqput: trying to free free dquot\n");
+ printk(KERN_ERR "VFS: device %s, dquot of %s %d\n",
kdevname(dquot->dq_dev), quotatypes[dquot->dq_type],
dquot->dq_id);
return;
diff -ur linux.vanilla/fs/exec.c linux/fs/exec.c
--- linux.vanilla/fs/exec.c Thu Mar 15 22:06:20 2001
+++ linux/fs/exec.c Thu Mar 15 21:11:18 2001
@@ -260,7 +260,7 @@
pte_t * pte;
if (page_count(page) != 1)
- printk("mem_map disagrees with %p at %08lx\n", page, address);
+ printk(KERN_WARNING "mem_map disagrees with %p at %08lx\n", page,
+address);
pgd = pgd_offset(tsk->mm, address);
pmd = pmd_alloc(pgd, address);
if (!pmd) {
diff -ur linux.vanilla/fs/file_table.c linux/fs/file_table.c
--- linux.vanilla/fs/file_table.c Tue Dec 5 21:27:31 2000
+++ linux/fs/file_table.c Thu Mar 15 21:05:43 2001
@@ -66,10 +66,11 @@
goto new_one;
}
/* Big problems... */
- printk("VFS: filp allocation failed\n");
+ printk(KERN_ERR "VFS: filp allocation failed\n");
} else if (files_stat.max_files > old_max) {
- printk("VFS: file-max limit %d reached\n", files_stat.max_files);
+ printk(KERN_ERR "VFS: file-max limit %d reached\n",
+ files_stat.max_files);
old_max = files_stat.max_files;
}
file_list_unlock();
diff -ur linux
Re: [Linux-fbdev-devel] [RFC] fbdev & power management
On Wed, 14 Mar 2001, James Simmons wrote:
> >>So the fbdev drivers would register PM with fbcon, not PCI, correct?
> >
> >Either that, or the fbdev would register with PCI (or whatever), _and_
> >fbcon would too independently. In that scenario, fbcon would only handle
> >things like disabling the cursor timer, while fbdev's would handle HW
> >issues. THe only problem is for fbcon to know that a given fbdev is
> >asleep, this could be an exported per-fbdev flag, an error code, or
> >whatever. In this case, fbcon can either buffer text input, or fallback
> >to the cfb working on the backed up fb image (that last thing can be
> >handled entirely within the fbdev I guess).
[...]
> As for fbcon knowing when it is asleep. Hum. We could have a flags to
> tell it to have text data updates to be placed in the shadow buffer
> (struct vc_datas->vc_screenbuffer) only;
Very simple to implement in the fbdev itself: just replace the drawing ops by
dummy drawing ops.
This can already be done now, by providing a dummy struct display_switch, and
in the future by providing dummy accels.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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] console and bust_spinlocks() fixes
Three things.
- Adds lib/bust_spinlocks.c for architectures which don't
provide bust_spinlocks() .
- Closes a race between tioclinux() and console scrolling
which was leaving bits of stuff on the screen when the
mouse was used with gpm.
- Added a missing break statement in do_syslog() (James Simmons)
Patch against -ac20 is here. The full `remove console_lock' patch
against 2.4.3-pre4 is at http://www.uow.edu.au/~andrewm/linux/console.html
--- linux-2.4.2-ac20/drivers/char/console.c Tue Mar 13 20:29:21 2001
+++ ac/drivers/char/console.c Tue Mar 13 21:12:47 2001
@@ -69,6 +69,9 @@
*
* Removed old-style timers, introduced console_timer, made timer
* deletion SMP-safe. 17Jun00, Andrew Morton <[EMAIL PROTECTED]>
+ *
+ * Removed console_lock, enabled interrupts across all console operations
+ * 13 March 2001, Andrew Morton
*/
#include
@@ -1034,6 +1037,7 @@
color = def_color;
}
+/* console_sem is held */
static void csi_m(int currcons)
{
int i;
@@ -1173,6 +1177,7 @@
return report_mouse;
}
+/* console_sem is held */
static void set_mode(int currcons, int on_off)
{
int i;
@@ -1238,6 +1243,7 @@
}
}
+/* console_sem is held */
static void setterm_command(int currcons)
{
switch(par[0]) {
@@ -1292,19 +1298,7 @@
}
}
-static void insert_line(int currcons, unsigned int nr)
-{
- scrdown(currcons,y,bottom,nr);
- need_wrap = 0;
-}
-
-
-static void delete_line(int currcons, unsigned int nr)
-{
- scrup(currcons,y,bottom,nr);
- need_wrap = 0;
-}
-
+/* console_sem is held */
static void csi_at(int currcons, unsigned int nr)
{
if (nr > video_num_columns - x)
@@ -1314,15 +1308,18 @@
insert_char(currcons, nr);
}
+/* console_sem is held */
static void csi_L(int currcons, unsigned int nr)
{
if (nr > video_num_lines - y)
nr = video_num_lines - y;
else if (!nr)
nr = 1;
- insert_line(currcons, nr);
+ scrdown(currcons,y,bottom,nr);
+ need_wrap = 0;
}
+/* console_sem is held */
static void csi_P(int currcons, unsigned int nr)
{
if (nr > video_num_columns - x)
@@ -1332,15 +1329,18 @@
delete_char(currcons, nr);
}
+/* console_sem is held */
static void csi_M(int currcons, unsigned int nr)
{
if (nr > video_num_lines - y)
nr = video_num_lines - y;
else if (!nr)
nr=1;
- delete_line(currcons, nr);
+ scrup(currcons,y,bottom,nr);
+ need_wrap = 0;
}
+/* console_sem is held (except via vc_init->reset_terminal */
static void save_cur(int currcons)
{
saved_x = x;
@@ -1355,6 +1355,7 @@
saved_G1= G1_charset;
}
+/* console_sem is held */
static void restore_cur(int currcons)
{
gotoxy(currcons,saved_x,saved_y);
@@ -1375,6 +1376,7 @@
EShash, ESsetG0, ESsetG1, ESpercent, ESignore, ESnonstd,
ESpalette };
+/* console_sem is held (except via vc_init()) */
static void reset_terminal(int currcons, int do_clear)
{
top = 0;
@@ -1430,6 +1432,7 @@
csi_J(currcons,2);
}
+/* console_sem is held */
static void do_con_trol(struct tty_struct *tty, unsigned int currcons, int c)
{
/*
@@ -1810,6 +1813,7 @@
#define CON_BUF_SIZE PAGE_SIZE
DECLARE_MUTEX(con_buf_sem);
+/* acquires console_sem */
static int do_con_write(struct tty_struct * tty, int from_user,
const unsigned char *buf, int count)
{
@@ -2049,7 +2053,7 @@
void set_console(int nr)
{
want_console = nr;
- schedule_task(&console_callback_tq);
+ schedule_console_callback();
}
#ifdef CONFIG_VT_CONSOLE
@@ -2171,9 +2175,21 @@
* Handling of Linux-specific VC ioctls
*/
+/*
+ * Generally a bit racy with respect to console_sem().
+ *
+ * There are some functions which don't need it.
+ *
+ * There are some functions which can sleep for arbitrary periods (paste_selection)
+ * but we don't need the lock there anyway.
+ *
+ * set_selection has locking, and definitely needs it
+ */
+
int tioclinux(struct tty_struct *tty, unsigned long arg)
{
char type, data;
+ int ret;
if (tty->driver.type != TTY_DRIVER_TYPE_CONSOLE)
return -EINVAL;
@@ -2181,17 +2197,23 @@
return -EPERM;
if (get_user(type, (char *)arg))
return -EFAULT;
+ ret = 0;
switch (type)
{
case 2:
- return set_selection(arg, tty, 1);
+ acquire_console_sem();
+ ret = set_selection(arg, tty, 1);
+ release_console_sem();
+ break;
case 3:
- return paste_selection(tty);
+ ret = paste_selection(tty);
+ break;
case 4:
unblank_screen();
-
Re: [OOPS] 8139too
On Wed, 14 Mar 2001, Manfred Spraul wrote: > > after APM laptop suspend to disk > > 8139too is build-in, not pcmcia > > I often get hangups after suspend-to-disk if I'm connected to a > > hub/switch. > > This is the first oops I've actually seen and copied it by hand: > Was the nic connected or not? The network was pluged in, but eth0 was not yet ifconfig'ed up. > It seems that rtl8139_resume() unconditionally enables the nic, even if > it wasn't open()'ed. Then an interrupt arrives and crashes because some > memory structures were not allocated. Will take a look myself after my exams. BYtE Philipp -- / / (_)__ __ __ Philipp Hahn / /__/ / _ \/ // /\ \/ / //_/_//_/\_,_/ /_/\_\ [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: [PATCH] Improved version reporting
From: "Albert D. Cahalan" <[EMAIL PROTECTED]> > On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote: >>> +o Console Tools # 0.3.3# loadkeys -V >>> +o Mount # 2.10e# mount --version >> >> Concerning mount: (i) the version mentioned is too old, Exactly why? Mere missing features don't make for a required upgrade. Version number inflation should be resisted. These days you can mount filesystems several places. That means that the choice one used to have -- after # mount dev dir both # umount dev and # umount dir would unmount -- has disappeared, and only # umount dir is (guaranteed to be) right today. These days you can mount several filesystems at the same mount point. The old mount does not understand this at all. Recent versions of mount act better in this respect, even though it is still easy to confuse them. Such things mean that it is best to have a really recent mount (although, of course, if you only want the mount(2) system call executed some five year old version will also do that for you). On the other hand, there are no important changes between mount-2.10d and 2.10e, so I see no justification for writing 2.10e. It is difficult to say what the "right" version is. There is a long series of minor improvements. Probably I would write 2.10r. Andries - 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] fbdev init sequence
Another patch from FISPET (The Fbdev Initialization Sequence Policy Enforcement
Team :-).
The following frame buffer devices do not use resource management yet:
- radeonfb (ATI Radeon): resource management calls are commented out (why?
Got no response from Ani)
- pmag-ba-fb (PMAG-BA TurboChannel framebuffer card): no resource management
- pmagb-b-fb (PMAGB-B TurboChannel framebuffer card): no resource management
- maxinefb (DECstation 5000/xx onboard framebuffer): no resource management
Thus their initialization calls must be moved to the section marked with the
comment:
/*
* Chipset specific drivers that don't use resource management (yet)
*/
--- linux-2.4.2-ac20/drivers/video/fbmem.c Tue Mar 13 14:28:34 2001
+++ fispet-2.4.2-ac20/drivers/video/fbmem.c Thu Mar 15 11:11:55 2001
@@ -178,9 +178,6 @@
#ifdef CONFIG_FB_RIVA
{ "riva", rivafb_init, rivafb_setup },
#endif
-#ifdef CONFIG_FB_RADEON
- { "radeon", radeonfb_init, radeonfb_setup },
-#endif
#ifdef CONFIG_FB_CONTROL
{ "controlfb", control_init, control_setup },
#endif
@@ -270,6 +267,18 @@
#ifdef CONFIG_FB_HIT
{ "hitfb", hitfb_init, NULL },
#endif
+#ifdef CONFIG_FB_RADEON
+ { "radeon", radeonfb_init, radeonfb_setup },
+#endif
+#ifdef CONFIG_FB_PMAG_BA
+ { "pmagbafb", pmagbafb_init, pmagbafb_setup },
+#endif
+#ifdef CONFIG_FB_PMAGB_B
+ { "pmagbbfb", pmagbbfb_init, pmagbbfb_setup },
+#endif
+#ifdef CONFIG_FB_MAXINE
+ { "maxinefb", maxinefb_init, maxinefb_setup },
+#endif
/*
* Generic drivers that don't use resource management (yet)
@@ -287,16 +296,6 @@
{ "resolver", NULL, resolver_video_setup },
#endif
-#ifdef CONFIG_FB_PMAG_BA
- { "pmagbafb", pmagbafb_init, pmagbafb_setup },
-#endif
-#ifdef CONFIG_FB_PMAGB_B
-{ "pmagbbfb", pmagbbfb_init, pmagbbfb_setup },
-#endif
-
-#ifdef CONFIG_FB_MAXINE
-{ "maxinefb", maxinefb_init, maxinefb_setup },
-#endif
#ifdef CONFIG_FB_VIRTUAL
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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/
Utility for re-patritioning
Since Linus has said that we need Swap = 2xRAM, and I bought some RAM, I need to enlarge my swap partition. Which utility should I use to resize my (ext2) partitions (possibly without data corruption:) ? -- Dragan - 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/
kernel 2.4.2 network performances
Hello, i have a problem with the network layer of linux kernel 2.4.2
I wrote a minimalist program which basically sends UDP datagrams over
the network in an infinite loop.
Under Linux 2.2.x, this program floods the network and my xosview prints
that 12 MB/s are sent over my 100Mbit ethernet.
Under Linux 2.4.2, this program can't flood the network because my
xosview (the same ;-) ) tells me that 4.6MB/s are sent over my ethernet
although my cpu is not overloaded.
I think that Linux 2.4.2 limits the rate of packets sent over the
network with some soft parameters.
*Does anyone have any idea ?
*Could someone explains me the new
/proc/sys/net/core/{hot_list_length|no_cong|no_cong_thresh|mod_cong|lo_cong}
parameters ?
*Where could i see in the code this soft limits ?
Thanks for your help.
Please CC me your response while i didn't subscribed to the mailing
list.
Jerome Tollet
[EMAIL PROTECTED]
www.qosmos.net
-
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 in 2.2.19pre16 : bad interaction between sound and APM
In ens.mailing-lists.linux-kernel, I wrote: >A friend of mine has a toshiba 320CDT laptop, with a redhat 6.1 >installed. In order to be able to use the USB port, I have compiled on it >a 2.2.19pre16 kernel. It all works very well except that I cannot get >sound working after the laptop has been in suspend mode. > Nobody can help me to understand where this bug comes from and how I could fix it or get around it ? (For instance by reinitializing the sound subsystem, knowing that it is not a module but built inside the kernel.) Thank you very much by advance Éric Brunet End of original message: >After a resume from suspend mode, if I try to play a mp3 sample, I only >get some hashed, repetitive and disconnected fragments of the original >tune. In the logs, I get the message > >Sound: DMA (output) timed out --- IRQ/DRQ config error ? > >The sound subsystem is compiled in the kernel (not as a module). Here is >some relevant part of /proc/sound (copied by hand, so there might be some >typos or omissions) > >OSS/Free: 3.8s2++-971130 > >drivers >Type 42: OPL3SA2 >Type 45: OPL3SA2 MSS >Type 43: OPL3SA2 MIDI >Type 1: OPL-2/OPL-3 FM >Type 5: Roland MPU-401 >Type 26: MPU-401 (UART) > >OPL3SA2at 0x370 irq 5 drq 1,0 >OPL3SA2 MSSat 0x530 drq 1,0 >OPL3SA2 MIDI at 0x330 irq 9 drq 1 >OPL-2/OPL-3 FM at 0x388 irq 9 drq 0 > >Audio devices: > 0: MS Sound System (CS4321) DUPLEX > >apm version is 3.0beta9. > >I remember I had some similar problem with sound on this machine with the >previous kernel (standard redhat 6.1 kernel), but I never really paid >attention: as the sound was a module, I could reinitialize everything by >unloading and reloading the module. So it is quite probable that this >problem is an old one which has nothing to do in particular with >2.2.19pre16. > >If there is some missing information, or if you want me to try something, >please don't hesitate. And by the way, is there a way to reinitialize the >sound subsystem when it is not compiled as a module ? - 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/
pthread support!!
Hi all,
I try to run the test program which created the thread on
MIPS machine.
But It always halt on call libpthread.so.0.
It was suspended when run into the thread
function.
Even, "printf" didn't work.
I use the following for the case.
After the kernel load libpthread.so.0, process
stopped.
This line "printf("---> FirstThread\n");" didn't
run.
What kind of resource does the pthread need?
Any reply is welcome.
Thanks in advance.
Green
_
#include #include
int FirstThread(void){ printf("test
thread!!"); return 1;}
int main(void){ pthread_t MyThread;
/* Call Thread
*/ printf("--->
FirstThread\n"); pthread_create(
&MyThread, (pthread_attr_t *)
NULL,
(void*)FirstThread, NULL
); pthread_join( MyThread, NULL); return
1;}
Re: [PATCH] Improved version reporting
[EMAIL PROTECTED] wrote: > > On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote: > > >>> +o Console Tools # 0.3.3# loadkeys -V > >>> +o Mount # 2.10e# mount --version > >> > >> Concerning mount: (i) the version mentioned is too old, > On the other hand, there are no important changes between > mount-2.10d and 2.10e, so I see no justification for writing 2.10e. > It is difficult to say what the "right" version is. There is a > long series of minor improvements. Probably I would write 2.10r. Guys, How about making a column that says: "recommended". So in this case we'd see 2.10r as recommended, but 2.10e as required. An explanation could state that: if you happen to have the version under "required", but a higher version is listed under "recommended", then that newer version is available, and but it is likely that one you have will work for you. There is no urgent reason to upgrade. But if you happen to be upgrading, you are advised upgrade to at least the version in the "recommended" column, as that has fixes over the one mentioned in the "required" column. Best regards, Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - 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: Utility for re-patritioning
At 10:17 15/03/01, Dragan Milenkovic wrote: >Since Linus has said that we need Swap = 2xRAM, >and I bought some RAM, I need to enlarge my swap partition. >Which utility should I use to resize my (ext2) partitions >(possibly without data corruption:) ? Have a look at gnu parted (ftp.gnu.org/gnu/parted/) Regards, Anton >-- >Dragan > >- >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/ -- Anton Altaparmakov (replace at with @) Linux NTFS Maintainer / WWW: http://sourceforge.net/projects/linux-ntfs/ ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ - 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-fbdev-devel] [RFC] fbdev & power management
> Now for fbcon its simpler. Things get writing to the shadow buffer >(vc_screenbuf). When the console gets woken up update_screen is called. >While power down the shadow buffer can be written to which is much faster >than saving a image of the framebuffer. Of course if you still want to do >this such in the case of the X server then copy the image of the >framebuffer to regular ram. Then power down /dev/fb using some ioctl calls >provide. Ok, I see. Currently, the sleep process is started from an ioctl sent to another driver, which will in turn call various notifier functions to shut down bits of hardware and finally put the machine to sleep. It's not a direct ioctl to the /dev/fb (which may not be opened). One problem I have is that my fbdev sleep routine will restore the mode on wakeup, but that of course doesn't work with X when not using useFBDev as fbdev have no knowledge of the current mode or register settings used by X. I'm wondering if it would be possible to make X think there's a console switch (without actually switching to an active console, as we don't know if we even have one of those available for us), wait for it to reply, and then start the sleep process. One other possibility would be to implement APM-like events, I still have to study those more in details as our sleep process is currently quite different from APM (and definitely not BIOS-based). For now, I have my hooks in fbcon that suspend/restart the cursor timer, that's enough to make sleep stable on 2.4 since we take care of shutting down the display very last (after any other driver) to make sure no printk will end up trying to display something while the chip is powered down. I'll digest your various comments look into all this in more depth with 2.5 console codebase. I beleive some solution must be found for x86 laptops too. Ben. - 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/
Core dumps for threads: Request for your patch (hack)
> >(I have a complimentary hack that will dump the stacks of all the >rest of the threads as well (though its a good trick to get gdb to >interpret this). Available upon request.) > Hello Adam, Could I take a look at your patch ? Regards Suparna Suparna Bhattacharya IBM Software Lab, India E-mail : [EMAIL PROTECTED] Phone : 91-80-5267117, Extn : 2525 - 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-fbdev-devel] [RFC] fbdev & power management
On Thu, 15 Mar 2001, Benjamin Herrenschmidt wrote:
> One problem I have is that my fbdev sleep routine will restore the mode
> on wakeup,
> but that of course doesn't work with X when not using useFBDev as fbdev
> have no
> knowledge of the current mode or register settings used by X.
That's a bug in X: one must not change the video mode by banging the hardware
when running on a fbdev system.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
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/
Glenn Herrin's IP Networking document
I have had many people asking after an HTML version of this document. Glenn finally contacted me and a full HTML version with the diagrams is now available at http://www.kernelnewbies.org/ john -- "24-hour boredom I'm convicted instantly" - Manic Street Preachers - 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: Kernel stress testing coverage
Hi, > Are you talking about the same posix test suite that LSB is using? I've > looked into that a little, but here are the two problems I'm wanting to > address: > > 1. How much of the kernel is getting hit on a run of any given test? Even > an approximate percentage is fine as long as I can prove it. > > 2. I could run many many copies simultaneously I suppose and get some > stress, but I'd prefer to stress individual pieces one at a time. Those > pieces could then be mixed together in later runs for mixed load stress. > Additional mixed load tests will be performed with general applications > (web servers, databases, etc) for more of a "real world" environment, but I > want to have focused tests as well. The POSIX tests are good for regression testing not necessarily for stress testing, obviously both are important. The person to talk to about this is Chris Yeoh <[EMAIL PROTECTED]>. > I'm betting that there are probably a LOT of quick and dirty test programs > that kernel hackers have written to expose a problem or thoroughly test a > piece of the kernel that they modified. These type of things would be > FYI this project will be going on sourceforge very soon. I want to have a > little more to start out with though and finish putting together a good > project description, testplans, etc. to post as soon as we put it on there. > I hate it when people start projects and you don't see any good information > about it for weeks. Yes for example I have a set of scripts I use to test software raid, loopback, ramdisk etc for sparc because there is a tendency for these things to break and not get found until long afterwards. Anton - 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.4.2 + aic7xxx still broken
Doug Ledford writes: > Either one should work. Try it with the UP_IOAPIC support enabled and see if > that helps. If it doesn't, then I would try Justin's driver and see if it > works. Thanks, the machine now boots. I'm using 2.4.3-pre3 + linux-aic7xxx-6.1.7 (UP on SMP board) with the following APIC support enabled: CONFIG_X86_GOOD_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y -Igor Mozetic - 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/
Is swap == 2 * RAM a permanent thing?
Is the fact that we're supposed to use double the RAM size as swap a permanent thing or a temporary annoyance that will get tweaked/fixed in the future at some point during 2.4.x perhaps? What are the technical reasons behind this change? Just curious as I see a lot of people are complaining about having to repartition (although a slower swap file could be used also). I'm curious because I currently have 96Mb of RAM and 256Mb of swap, but swap rarely if ever gets used, and performance is very good. This is with 2.2.18 I'm speaking. I'm planning on upping my RAM to 256Mb or more in the near future however, and going to 2.4.3 or 2.4.4 when released, and since 96Mb does the job for me already it would suck to have to increase swap at the same time when it never gets used as it is right now. Would it be better to make part of RAM a ramdisk and swap to that? Sounds like we're going backwards IMHO, but I don't understand the details, so I'll let someone that does explain them to me. Thanks in advance. -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- If it weren't for C, we'd all be programming in BASI and OBOL. - 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: (struct dentry *)->vfsmnt;
>Actually, I'm pretty sure you _never_ need to exportvg in order to have >it work on another system. That's one of the great things about AIX LVM, >because it means you can move a VG to another system after a hardware >problem, and not have any problems importing it (journaled fs also helps). >AFAIK, the only think exportvg does is remove VG information from the >ODM and /etc/filesystems. > Yes that's correct as far as I know too. The VGDA and LVCB contain all the information required for import even without an exportvg. >I suppose it is possible that because AIX is so tied into the ODM and >SMIT, that it updates the VGDA mountpoint info whenever a filesystem >mountpoint is changed, but this will _never_ work on Linux because of >different tools versions, distributions, etc. Also, it would mean on >AIX that anyone editing /etc/filesystems might have a broken system at >vgimport time (wouldn't be the first time that not using ODM/SMIT caused >such a problem). Yes, you can think of crfs (or chfs) as a composite command that handles this (writing to LVCB. These are more like administrative/setup/configuration commands -- one time, or occasional system configuration changes. On the other hand a mount doesn't cause a persistent configuration information change. You can issue a mount even if an entry doesn't exist in /etc/filesystems. > >> ... I do think that the LVM is a reasonable place to store this kind of >> information. > >Yes, even though it would tie the user into using a specific version of >mount(), I suppose it is a better solution than storing it inside the >filesystem. It will work with non-ext2 filesystems, and it also allows >you to store more information than simply the mountpoint (e.g. mount >options, dump + fsck info, etc). In the end, I will probably just >save the whole /etc/fstab line into the LV header somewhere, and extract >it at importvg time (possibly with modifications for vgname and mountpoint). > >Cheers, Andreas Is mount the right time to do this ? A mount happens on every boot of the system. And then, one can issue a mount by explicitly specifying all the parameters without having an entry in fstab. [Doesn't that also mean that you have a possibility of inconsistency even here ?] - 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]: Only one memory zone for sparc64
On Thu, 15 Mar 2001, Anton Blanchard wrote:
> On sparc64 we dont care about the different memory zones and iterating
> through them all over the place only serves to waste CPU. I suspect
> this would be the case with some other architectures but for the
> moment I have just enabled it for sparc64.
>
> With this patch I get close to a 1% improvement in dbench on the dual
> ultra60.
1% ... I didn't expect Linux to take THIS much of a hit due to
not using the zones on some architectures ...
I guess this is enough of a difference to make sure we don't do
these extra iterations when they're not needed.
> +#ifdef __sparc_v9__
> +#define MAX_NR_ZONES 1
> +#define ZONE_NAMES { "DMA" }
> +#define ZONE_BALANCE_RATIO { 32 }
> +#define ZONE_BALANCE_MIN { 10 }
> +#define ZONE_BALANCE_MAX { 255 }
> +#else
I guess it may be better to just have include/asm-/mmzone.h
files for each architecture. Maybe even optionally behind an
IFNDEF so we could start with almost empty files for each
architecture and only fill in something when the values really
need to be different ...
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
-
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 on the Unisys ES7000 and CMP2 machines?
On Wed, 14 Mar 2001, Dan Kegel wrote: > (When the two people he was talking to asked about Linux on the > machine, he said "We feel Linux can't do enterprise-level stuff like > this." He got a little defensive when we questioned his judgement.) Heh. If Linux 2.2 was his only experience with the system I could actually understand his opinion. Good thing that the core parts of the kernel have gotten somewhat more robust with 2.4 ... Too bad there probably won't be anyone giving away (or loaning out) such machines for test machines to port Linux to ;)) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: How to optimize routing performance
On Thu, 15 Mar 2001, [ISO-8859-1] Mårten Wikström wrote: > I've performed a test on the routing capacity of a Linux 2.4.2 box > versus a FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with > 64Mb memory, and two DEC 100Mbit ethernet cards. I used a Smartbits > test-tool to measure the packet throughput and the packet size was set > to 64 bytes. Linux dropped no packets up to about 27000 packets/s, but > then it started to drop packets at higher rates. Worse yet, the output > rate actually decreased, so at the input rate of 4 packets/s > almost no packets got through. The behaviour of FreeBSD was different, > it showed a steadily increased output rate up to about 7 packets/s > before the output rate decreased. (Then the output rate was apprx. > 4 packets/s). > So, my question is: are these figures true, or is it possible to > optimize the kernel somehow? The only changes I have made to the > kernel config was to disable advanced routing. There are some flow control options in the kernel which should help. From your description, it looks like they aren't enabled by default ... At the NordU/USENIX conference in Stockholm (this february) I saw a nice presentation on the flow control code in the Linux networking code and how it improved networking performance. I'm pretty convinced that flow control _should_ be saving your system in this case. OTOH, if they _are_ enabled, the networking people seem to have a new item for their TODO list. ;) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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/
changing mm->mmap_sem (was: Re: system call for process information?)
On Wed, 14 Mar 2001, Rik van Riel wrote: > On Wed, 14 Mar 2001, george anzinger wrote: > > > Is it REALLY necessary to prevent them from seeing an > > inconsistent state? Seems to me that in the total picture (i.e. > > system wide) they will never see a consistent state, so why be > > concerned with a small corner of the system. > > You're right. Mmmm, I've looked at the code today and it turned out that we're NOT right ;) The mmap_sem is used in procfs to prevent the list of VMAs from changing. In the page fault code it seems to be used to prevent other page faults to happen at the same time with the current page fault (and to prevent VMAs from changing while a page fault is underway). Maybe we should change the mmap_sem into a R/W semaphore ? Since page faults seem to be the "common cause" of blocking procfs access *and* since both page faults and procfs only need to prevent the VMA list from changing, a read lock would help here. Write locks would be used in the code where we actually want to change the VMA list and page faults would use an extra lock to protect against each other (possibly a per-pagetable lock so multithreaded apps can pagefault in different memory regions at the same time ???). regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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/
DMA Speed Select Problem (a bug ?)
Hi,
First of all I'm using linux-2.4.2.
After various reboots and frustration I finally found
out, why my machine did hang, as soon as I tried to burn
a CD on my ATAPI CD Burner.
Now I know why:
A look at /proc/ide/hdc relveals that
init_speed = 66
Which is wrong, because my CDBurner is only capable of
Multiword2 DMA transfers (speed 34).
Calling "hdparm -d1 -X34 /dev/hdc" fixes the problem.
I even found these messages in /var/log/messages:
Mar 14 18:01:48 pcrohloff kernel: hdc: set_drive_speed_status: status=0x51 {
DriveReady SeekComplete Error }
Mar 14 18:01:48 pcrohloff kernel: hdc: set_drive_speed_status: error=0x04
Which basically means that the linux driver even finds out that my
drive doesn't like UDMA66, but doesn't react to it.
I think that's a bug yes ?
I got a PIIX chipset, so this might be a problem of this specific
chipset driver (piix.c). Then again probably not ...
so long
Ingo Rohloff
PS: Burning a CD was only one trigger for the problem. In fact
accessing my CDBurner in any way (like mounting a CD, or reading
from it) will lock up my whole computer, as long as
"hdparm -d1 -X34" isn't called.
It also doesn't depend on "ide-scsi" or "ide-cd" it will lock
up with both modules.
Also after unloading "ide-cd" and then reloading it, it is
necessary to call "hdparm" again, because ide-cd will initialize
the drive again with init_speed=66...
-
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] fix a bug in ioctl(CDROMREADAUDIO) in cdrom.c in 2.2
Le 14-Mar-2001, Jani Jaakkola écrivait : > > Using ioctl(CDROMREADAUDIO) with nframes argument being larger than 8 and > not divisible by 8 causes kernel to read and return more audio data than > was requested. This is bad since it clobbers up processes memory > (I noticed this when my patched cdparanoia segfaulted). Same thing for 2.4.2. Is my allocation loop "over engineering", or just plain bad thing to do ? Regards, Pierre. -- Linux blade.concept-micro.com 2.4.3-pre4 #1 Wed Mar 14 22:19:14 CET 2001 i686 unknown 2:04pm up 11:29, 4 users, load average: 2.66, 2.80, 2.26 myreadaudio.patch
OOPS when switching consoles while closing X.
Hi. I've had a semi-reproducable oops with the kernel. It happens when I'm shutting down X (Xfree86 4.02 cvs), while it is closing all open apps (KDE 2.1.1 cvs). I switch to a text console (ctrl-alt-F2 etc), and it crashes almost as soon as the text console is there. I've noticed it with 2.4.2ac17 and 2.4.2ac20, the problem might have existed in earlier versions but I haven't noticed it. However I think it is probably recent, as I often switch to text mode while X is shutting down, so I would have noticed it. I have recently recompiled KDE, though that shouldn't cause a kernel OOPS should it?? I'm not sure what information would be helpful, I've included the ksymoops output for 2.4.2ac17, and my dmesg. Tell me if more is needed. Cheers, Matt Johnston. Linux version 2.4.2-ac17 ([EMAIL PROTECTED]) (gcc version 2.95.2 19991024 (release)) #1 Sat Mar 10 19:24:46 WST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: 03ef @ 0010 (usable) BIOS-e820: 8000 @ 03ff (ACPI data) BIOS-e820: 8000 @ 03ff8000 (ACPI NVS) BIOS-e820: 1000 @ fec0 (reserved) BIOS-e820: 1000 @ fee0 (reserved) BIOS-e820: 0008 @ fff8 (reserved) On node 0 totalpages: 16368 zone(0): 4096 pages. zone(1): 12272 pages. zone(2): 0 pages. Kernel command line: root=/dev/hda6 ro BOOT_IMAGE=242ac17 Initializing CPU#0 Detected 398.202 MHz processor. Console: colour VGA+ 80x30 Calibrating delay loop... 794.62 BogoMIPS Memory: 62576k/65472k available (839k kernel code, 2508k reserved, 204k data, 168k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) CPU: Before vendor init, caps: 0183fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 128K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0183fbff CPU: After generic, caps: 0183fbff CPU: Common caps: 0183fbff CPU: Intel Celeron (Mendocino) stepping 00 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfdb91, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router PIIX [8086/7110] at 00:07.0 Limiting direct PCI/PCI transfers. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 41514kB/13838kB, 128 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: chipset revision 1 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio hda: QUANTUM FIREBALL EX6.4A, ATA DISK drive hdc: TOSHIBA DVD-ROM SD-M1202, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 12594960 sectors (6449 MB) w/418KiB Cache, CHS=784/255/63, UDMA(33) Partition check: hda: hda1 hda2 < hda5 hda6 hda7 > NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 168k freed Adding Swap: 128484k swap-space (priority -1) IA-32 Microcode Update Driver: v1.08 <[EMAIL PROTECTED]> microcode: CPU0 updated from revision 4 to 10, date=05051999 microcode: freed 2048 bytes es1371: version v0.27 time 19:33:18 Mar 10 2001 es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x04 PCI: Found IRQ 9 for device 00:0c.0 es1371: found es1371 rev 4 at io 0xef00 irq 9 es1371: features: joystick 0x0 ac97_codec: AC97 Audio codec, id: 0x4352:0x5903 (Cirrus Logic CS4297) Detected Parameters Irq=11 BaseAddress=0xe800 ComAddress=0xeff0 Lucent Modem driver version 5.78e (2000-08-09) with SERIAL_PCI enabled ttyS00 at 0xe800 (irq = 11) is a Lucent es1371: unloading IA-32 Microcode Update Driver v1.08 unregistered CSLIP: code copyright 1989 Regents of the University of California PPP g
reiserfs-oops; kernel 2.4.3-pre4
hello, I got the following oops: ksymoops 2.4.0 on i686 2.4.3-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3-pre4/ (default) -m /boot/System.map-2.4.3-pre4 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Mar 15 00:56:10 wptx99 kernel: Unable to handle kernel NULL pointer dereference at virtual address 0108 Mar 15 00:56:10 wptx99 kernel: c016f090 Mar 15 00:56:10 wptx99 kernel: *pde = Mar 15 00:56:10 wptx99 kernel: Oops: Mar 15 00:56:10 wptx99 kernel: CPU:1 Mar 15 00:56:10 wptx99 kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Mar 15 00:56:10 wptx99 kernel: EFLAGS: 00010286 Mar 15 00:56:10 wptx99 kernel: eax: 0108 ebx: 0108 ecx: de785ebc edx: ce09d488 Mar 15 00:56:10 wptx99 kernel: esi: 0001 edi: de785e58 ebp: d13c17c0 esp: de785e1c Mar 15 00:56:10 wptx99 kernel: ds: 0018 es: 0018 ss: 0018 Mar 15 00:56:10 wptx99 kernel: Process nfsd (pid: 712, stackpage=de785000) Mar 15 00:56:10 wptx99 kernel: Stack: de785ebc c0160046 0108 de785ebc 0001 0002 Mar 15 00:56:10 wptx99 kernel:c015c8a8 c18ec400 de785ebc fff4 de784000 d13c17c0 df6ee060 0001 Mar 15 00:56:10 wptx99 kernel: cf73dc60 cf73d6c0 Mar 15 00:56:10 wptx99 kernel: Call Trace: [] [] [] [] [] [] [] Mar 15 00:56:10 wptx99 kernel:[] [] [] [] [] [] [] [] Mar 15 00:56:10 wptx99 kernel: Code: 8b 13 8b 01 39 c2 73 08 b8 ff ff ff ff eb 1e 90 39 c2 76 0c >>EIP; c016f090<= Trace; c0160046 Trace; c015c8a8 Trace; c013e39d Trace; e0e039b1 <[nfsd].rodata.start+1771/3913> Trace; c013e43f Trace; e0df8f8b <[nfsd]nfsd_lookup+3cb/528> Trace; e0df6c8c <[nfsd]nfsd_proc_lookup+8c/a0> Trace; e0e05c80 <[nfsd]nfsd_procedures2+80/240> Trace; e0df6593 <[nfsd]nfsd_dispatch+cb/168> Trace; e0e05c80 <[nfsd]nfsd_procedures2+80/240> Trace; e0ddd52f <[sunrpc]svc_process+297/4d8> Trace; e0e05b68 <[nfsd]nfsd_version2+0/10> Trace; e0df63ad <[nfsd]nfsd+225/340> Trace; e0e05b60 <[nfsd]nfsd_list+0/0> Trace; c01074c4 Code; c016f090 <_EIP>: Code; c016f090<= 0: 8b 13 mov(%ebx),%edx <= Code; c016f092 2: 8b 01 mov(%ecx),%eax Code; c016f094 4: 39 c2 cmp%eax,%edx Code; c016f096 6: 73 08 jae10 <_EIP+0x10> c016f0a0 Code; c016f098 8: b8 ff ff ff ffmov$0x,%eax Code; c016f09d d: eb 1e jmp2d <_EIP+0x2d> c016f0bd Code; c016f09f f: 90nop Code; c016f0a0 10: 39 c2 cmp%eax,%edx Code; c016f0a2 12: 76 0c jbe20 <_EIP+0x20> c016f0b0 1 warning issued. Results may not be reliable. The machine is running linux-2.4.3-pre4 including the reiserfs-patches from Alexander Zarochentcev. The filesystem was created with mkreiserfs 3.x.0h Bye, -- Andreas Klein [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: (struct dentry *)->vfsmnt;
>Because this is totally filesystem specific - why put extra knowledge >of filesystem internals into mount? I personally don't want it writing >into the ext2 or ext3 superblock. How can it possibly know what to do, >without embedding a lot of knowledge there? Yes, mount(8) can _read_ >the UUID and LABEL for ext2 filesystems, but I would rather not have it >_write_ into the superblock. Also, InterMezzo and SnapFS have the same >on-disk format as ext2, but would mount(8) know that? > >There are other filesystems (at least IBM JFS) that could also take >advantage of this feature, should we make mount(8) have code for each >and every filesystem? Yuck. Sort of ruins the whole modularity thing. >Yes, I know mount(8) does funny stuff for SMB and NFS, but that is a >reason to _not_ put more filesystem-specific information into mount(8). > Since you've brought up this point. I have wondered why Linux doesn't seem to yet have the option of a generic user space filesystem type specific mount helper command. I recall having seen code in mount(8) implementation to call mount., but its still under an ifdef isn't it, except for smb or ncp perhaps ? (Hope I'm not out-of-date on this) Having something like that lets one stream-line userland filesystem specific stuff like this, without having the generic part of mount(8) know about it. For example, in AIX, the association between type and the program for mount helpers (and also for filesystem helpers for things like mkfs, fsck etc) is configured in /etc/vfs, while SUN and HP look for them under particular directory locations (by fstype name). Actually, it'd be good to have this in such a way that if a specific helper doesn't exist, default mount processing continues. This avoids the extra work of writing such helpers for every new filesystem, unless we need specialized behaviour there. Suparna Bhattacharya IBM Software Lab, India E-mail : [EMAIL PROTECTED] Phone : 91-80-5267117, Extn : 2525 - 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: kernel 2.4.2 network performances
On Thu, 15 Mar 2001, Jerome Tollet wrote:
> Hello, i have a problem with the network layer of linux kernel 2.4.2
> I wrote a minimalist program which basically sends UDP datagrams over
> the network in an infinite loop.
> Under Linux 2.2.x, this program floods the network and my xosview prints
> that 12 MB/s are sent over my 100Mbit ethernet.
>
> Under Linux 2.4.2, this program can't flood the network because my
> xosview (the same ;-) ) tells me that 4.6MB/s are sent over my ethernet
> although my cpu is not overloaded.
>
> I think that Linux 2.4.2 limits the rate of packets sent over the
> network with some soft parameters.
> *Does anyone have any idea ?
> *Could someone explains me the new
> /proc/sys/net/core/{hot_list_length|no_cong|no_cong_thresh|mod_cong|lo_cong}
> parameters ?
> *Where could i see in the code this soft limits ?
Yesterday I discovered that the load I can throw out to network seems to
depend on other activities running on machine. I was able to get
throughput of 33M/s with ATM when machine was idle, while I compiled
kernel at same time, the throughput was 135M/s.
So, I suggest you try to compile kernel while running your UDP stream!
- Sampsa Ranta
-
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: another Cyrix/mtrr problem?
David Wragg wrote: > [EMAIL PROTECTED] (Bob_Tracy) writes: > > echo "base=0xd800 size=0x10 type=write-combining" >| /proc/mtrr > > > > I get a 2MB region instead of the 1MB region I expected... > > Oops, it got broken by the MTRR >32-bit support in 2.4.0-testX. The > patch below should fix it. > > Joerg, I think this might well fix your Cyrix mtrr problem also. > > Let me know how it goes, That fixed the "wrong size" problem nicely. Thanks! AGP support on this beast (Tyan S1590S / Apollo MVP3) is still broken, however. I'll try the new NVIDIA driver (as someone suggested -- thanks for the steer!) and see if that helps. If there's an NVIDIA person reading this that would like to work this issue off-line, your help would be appreciated. Thanks! -- Bob Tracy [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: IDE poweroff -> hangup
On Thu, 15 Mar 2001, Pozsar Balazs wrote: > > Hi all, > > I was courious, and I tried what happens if I power down my harddisk (ie > manually pull the power plug out), and then power it on again after a few > secs (put the plug back). > > I do not know if the system should survive happily such an 'accident', but > it hadn't: > A few secs after the next access to the disc, I got the following on the > console: > hdg: timeout waiting for DMA > ide_dmaproc: chipset supported ide_dma_timeout func only: 14 > and the machine froze the hard way (no respond to sysrq). > > Tell me if this shouldn't be honoured by the kernel, but if there's a bug > around, here's some info: With IDE, the entire state of the drive is in the drive. There is no 'controller' on the board like SCSI, just an interface port. So, when you kill the power to the drive, you kill any information, including pending operations, that the drive has stored. The only way to recover is to go through an entire initialization sequence just like the BIOS did upon power up. If the IDE code didn't do this the drive will not be accessible. The IDE code doesn't have any way of knowing that you destroyed its current state. Error recovery code could be more robust and perform the entire startup sequence if it had a way of "knowing" when to do this. This is entirely different than what occurs when the IDE drive is powered off by the IDE/APM software (for laptops). In this case, the IDE code "knows" that the motor is being turned off. It also knows how to wait for any pending writes to complete. It also knows how to restart the motor and to not attempt reads/writes until the state of the drive has stabilized and the heads have been recalibrated. Turning off the power to a device that can do any kind of DMA operation is just like changing RAM with the power on. It's an interesting experiment in chaos theory. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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/
A simple question on buffer/cache
Hi, Just wonder what exactly the difference between buffer and cache in linux memory management is. Cache is used for filesystems, so that files read from a fs are kept in memory in order to provide faster access next time. Then what is buffer used for? As executables are also kept in memory, are they in cache or buffer? Can somebody give any details on this? Many thanks! -- Cheers! --Zou Min - "Any technology indistinguishable from magic is insufficiently advanced." - 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: Is swap == 2 * RAM a permanent thing?
On Thu, 15 Mar 2001, Mike A. Harris wrote: > Is the fact that we're supposed to use double the RAM size as > swap a permanent thing or a temporary annoyance that will get > tweaked/fixed in the future at some point during 2.4.x perhaps? You're not supposed to do anything, that's just a general rule of thumb. If your system hardly ever swaps, use a swapfile, because speed doesn't matter a lot anyway. > Would it be better to make part of RAM a ramdisk and swap to > that? No, don't do that. Physical memory is better than swap. Swap is a backup for physical memory, so that you can run programs that use more memory than you have. You don't really *need* swap, linux works fine without. Ketil - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Richard B. Johnson wrote: > This used to even be the way disks were located by the kernel > drivers. Now, these are found in some "random" order. > > If whatever is causing the "random" order was fixed, put back like > it used to be, etc., we wouldn't have these problems. Another alternative to path2inst or a database, I suppose, would be to use bus/pci slot information (like in /proc/pci?) to order multiple devices, so at least there's some consistency. You might have a serious headache, however, when adding a device, under that scheme. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Is swap == 2 * RAM a permanent thing?
On Thu, 15 Mar 2001, Mike A. Harris wrote: > Is the fact that we're supposed to use double the RAM size as > swap a permanent thing or a temporary annoyance that will get > tweaked/fixed in the future at some point during 2.4.x perhaps? > > What are the technical reasons behind this change? The reason is that the Linux 2.4 kernel no longer reclaims swap space on swapin (2.2 reclaimed swap space on write access, which lead to fragmented swap space in lots of workloads). This means that a lot of memory ends up "duplicated" in RAM and in swap. I plan on doing some code to reclaim swap space when we run out, but Linus doesn't seem to like that idea very much. His argument (when you're OOM, you should just fail instead of limp along) makes a lot of sense, however, and the reclaiming of swap space isn't really high on my TODO list ... OTOH, for people who have swap < RAM and use it just as a small overflow area, Linus' argument falls short, so I guess some time in the future we will have code to reclaim swap space when needed. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: OOPS when switching consoles while closing X.
Matt Johnston wrote: > > Hi. > > I've had a semi-reproducable oops with the kernel. It happens when I'm > shutting down X (Xfree86 4.02 cvs), while it is closing all open apps (KDE > 2.1.1 cvs). I switch to a text console (ctrl-alt-F2 etc), and it crashes > almost as soon as the text console is there. > Someone is calling console functions from interrupt context. Unfortunately your backtrace looks wrong. Could you please rerun ksymoops and send me the output? Make sure you're using the correct System.map (ksymoops -m). It should be pretty straightforward to fix. While we're there we'll do something about do_SAK(), which is acquiring the tasklist_lock from interrupt context. For heaven's sake. - - 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/
ide-scsi: CoD != 0 in idescsi_pc_intr... -- what is this?
Hi all,
While copying a CD into harddisk, I got the following in the syslog (and
on the console):
Mar 15 14:36:23 brefatox kernel: ide-scsi: CoD != 0 in idescsi_pc_intr
Mar 15 14:36:23 brefatox kernel: hde: ATAPI reset complete
Mar 15 14:36:23 brefatox kernel: hde: status error: status=0x51 {
DriveReady SeekComplete Error }
Mar 15 14:36:23 brefatox kernel: hde: status error: error=0x00
Mar 15 14:36:23 brefatox kernel: ide-scsi: Strange, packet command
initiated yet DRQ isn't asserted
Mar 15 14:36:46 brefatox kernel: ide-scsi: CoD != 0 in idescsi_pc_intr
Mar 15 14:36:46 brefatox kernel: hde: ATAPI reset complete
Mar 15 14:36:46 brefatox kernel: hde: status error: status=0x51 {
DriveReady SeekComplete Error }
Mar 15 14:36:46 brefatox kernel: hde: status error: error=0x00
Mar 15 14:36:46 brefatox kernel: ide-scsi: Strange, packet command
initiated yet DRQ isn't asserted
Mar 15 14:37:02 brefatox kernel: ide-scsi: CoD != 0 in idescsi_pc_intr
Mar 15 14:37:02 brefatox kernel: hde: ATAPI reset complete
Mar 15 14:37:02 brefatox kernel: hde: status error: status=0x51 {
DriveReady SeekComplete Error }
Mar 15 14:37:02 brefatox kernel: hde: status error: error=0x00
Mar 15 14:37:02 brefatox kernel: ide-scsi: Strange, packet command
initiated yet DRQ isn't asserted
Mar 15 14:37:17 brefatox kernel: ide-scsi: CoD != 0 in idescsi_pc_intr
Mar 15 14:37:17 brefatox kernel: hde: ATAPI reset complete
Mar 15 14:37:17 brefatox kernel: hde: status error: status=0x51 {
DriveReady SeekComplete Error }
Mar 15 14:37:17 brefatox kernel: hde: status error: error=0x00
Mar 15 14:37:17 brefatox kernel: ide-scsi: Strange, packet command
initiated yet DRQ isn't asserted
Mar 15 14:37:27 brefatox kernel: ide-scsi: CoD != 0 in idescsi_pc_intr
Mar 15 14:37:27 brefatox kernel: hde: ATAPI reset complete
Mar 15 14:37:27 brefatox kernel: hde: status error: status=0x51 {
DriveReady SeekComplete Error }
Mar 15 14:37:27 brefatox kernel: hde: status error: error=0x00
Mar 15 14:37:27 brefatox kernel: ide-scsi: Strange, packet command
initiated yet DRQ isn't asserted
Mar 15 14:37:28 brefatox kernel: ide-scsi: CoD != 0 in idescsi_pc_intr
Mar 15 14:37:29 brefatox kernel: hde: ATAPI reset complete
Mar 15 14:37:29 brefatox kernel: hde: status error: status=0x51 {
DriveReady SeekComplete Error }
Mar 15 14:37:29 brefatox kernel: hde: status error: error=0x00
Mar 15 14:37:29 brefatox kernel: ide-scsi: Strange, packet command
initiated yet DRQ isn't asserted
Mar 15 14:37:32 brefatox kernel: ide-scsi: CoD != 0 in idescsi_pc_intr
Mar 15 14:37:32 brefatox kernel: hde: ATAPI reset complete
Mar 15 14:37:32 brefatox kernel: hde: status error: status=0x08 {
DataRequest }
Mar 15 14:37:32 brefatox kernel: hde: drive not ready for command
Mar 15 14:37:42 brefatox kernel: spurious 8259A interrupt: IRQ7.
Mar 15 14:37:49 brefatox kernel: ide-scsi: CoD != 0 in idescsi_pc_intr
Mar 15 14:37:49 brefatox kernel: hde: ATAPI reset complete
Mar 15 14:37:49 brefatox kernel: hde: status error: status=0x51 {
DriveReady SeekComplete Error }
Mar 15 14:37:49 brefatox kernel: hde: status error: error=0x00
Mar 15 14:37:49 brefatox kernel: ide-scsi: Strange, packet command
initiated yet DRQ isn't asserted
Mar 15 14:38:23 brefatox kernel: ide-scsi: CoD != 0 in idescsi_pc_intr
Mar 15 14:38:23 brefatox kernel: hde: ATAPI reset complete
Mar 15 14:38:23 brefatox kernel: hde: status error: status=0x51 {
DriveReady SeekComplete Error }
Mar 15 14:38:23 brefatox kernel: hde: status error: error=0x00
Mar 15 14:38:23 brefatox kernel: ide-scsi: Strange, packet command
initiated yet DRQ isn't asserted
The copy finished successfully. What is this? Should I care about it? Why
is it? :) (so many questions...)
I was copying copying from hde to hdg. dmesg is at the end.
The cdrom is connected to via a 80c udma66 cable to the first port of the
HPT370 on my Abit VP6 motherboard.
dmesg:
Linux version 2.4.2 ([EMAIL PROTECTED]) (gcc version 2.95.3 19991030 (prerelease)) #1
SMP Wed Mar 7 22:58:36 CET 2001
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
BIOS-e820: 0001 @ 000f (reserved)
BIOS-e820: 1000 @ fec0 (reserved)
BIOS-e820: 1000 @ fee0 (reserved)
BIOS-e820: 0001 @ (reserved)
BIOS-e820: 17ef @ 0010 (usable)
BIOS-e820: d000 @ 17ff3000 (ACPI data)
BIOS-e820: 3000 @ 17ff (ACPI NVS)
Scan SMP from c000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f for 65536 bytes.
found SMP MP-table at 000f5770
hm, page 000f5000 reserved twice.
hm, page 000f6000 reserved twice.
hm, page 000f1000 reserved twice.
hm, page 000f2000 reserved twice.
On node 0 totalpages: 98288
zone(0): 4096 pages.
zone(1): 94192 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.1
Virtual Wire compatibility mode.
OEM ID: OEM
Re: How to optimize routing performance
Rik van Riel writes: > On Thu, 15 Mar 2001, [ISO-8859-1] Mårten Wikström wrote: > > > I've performed a test on the routing capacity of a Linux 2.4.2 box > > versus a FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with > > 64Mb memory, and two DEC 100Mbit ethernet cards. I used a Smartbits > > test-tool to measure the packet throughput and the packet size was set > > to 64 bytes. Linux dropped no packets up to about 27000 packets/s, but > > then it started to drop packets at higher rates. Worse yet, the output > > rate actually decreased, so at the input rate of 4 packets/s It is a known problem yes. And just as Rik says its has been adressed in 2.1.x by Alexey for first time. > > almost no packets got through. The behaviour of FreeBSD was different, > > it showed a steadily increased output rate up to about 7 packets/s > > before the output rate decreased. (Then the output rate was apprx. > > 4 packets/s). > > > So, my question is: are these figures true, or is it possible to > > optimize the kernel somehow? The only changes I have made to the > > kernel config was to disable advanced routing. > > There are some flow control options in the kernel which should > help. From your description, it looks like they aren't enabled > by default ... CONFIG_NET_HW_FLOWCONTROL enables kernel code for it. But device drivers has to have support for it. But unfortunely very few drivers has support for it. Also we done experiments were we move the device RX processing to SoftIRQ rather than IRQ. With this RX is in better balance with other kernel tasks and TX. Under very high load and under DoS attacks the system is now manageable. It's in practical use already. > At the NordU/USENIX conference in Stockholm (this february) I > saw a nice presentation on the flow control code in the Linux > networking code and how it improved networking performance. > I'm pretty convinced that flow control _should_ be saving your > system in this case. Thanks Rik. This is work/experiments by Jamal and me with support from Gurus. :-) Jamal did this presentation at OLS 2000. At NordU/USENIX I gave an updated presentation of it. The presentation is not yet available form the usenix webb I think. It can ftp from robur.slu.se: /pub/Linux/tmp/FF-NordUSENIX.pdf or .ps In summary Linux is very decent router. Wire speed small packets @ 100 Mbps and capable of Gigabit routing (1440 pkts tested) we used. Also if people are interested we have done profiling on a Linux production router with full BGP at pretty loaded site. This to give us costs for route lookup, skb malloc/free, interrupts etc. http://Linux/net-development/experiments/010313 I'm on netdev but not the kernel list. Cheers. --ro - 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: Is swap == 2 * RAM a permanent thing?
> The reason is that the Linux 2.4 kernel no longer reclaims swap > space on swapin (2.2 reclaimed swap space on write access, which > lead to fragmented swap space in lots of workloads). > > This means that a lot of memory ends up "duplicated" in RAM and > in swap. > > I plan on doing some code to reclaim swap space when we run out, > but Linus doesn't seem to like that idea very much. His argument > (when you're OOM, you should just fail instead of limp along) > makes a lot of sense, however, and the reclaiming of swap space > isn't really high on my TODO list ... > > OTOH, for people who have swap < RAM and use it just as a small > overflow area, Linus' argument falls short, so I guess some time > in the future we will have code to reclaim swap space when needed. I have some questions on this. 1) If a process uses swap space and then later (after being paged into memory -- or even not) it completes, is killed, etc., is the swap space reclaimed then? 2) If a process uses swap, is paged into memory, and is then swapped out again, does it re-use the same swap as before? If the answer to either question is no, then IMHO, that's a pretty serious design flaw. Regards, /Mike - 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/
Drvie Corruption CONSTANTLY with Linux and KT7-RAID
Please help.. I'm at the end of my rope with this now. I have rebuilt this system and corupted my drive at least 30 times now. I have a ABIT KT7-RAID and no matter what I do with any kernel 2.2.16 - 2.4.2-ac19 as soon as I turn on DMA mode the drive starts to corrupt and becomes useless. The corruption happens alot faster in 2.4xxx than the 2.2.xxx kernels. The system DOES work flawlessly running windows in DMA mode, which leads me to believe that I am not experiencing a Hardware problem. I have tried every suggestion concerning the via chipset on this site. I've heard of many success stories with this board. what am i doing wrong?!?! At this point I am 100% lost. any help would be greatly appreciated. I am willing to do any testing of the system that anyone may need. Currently I have no working copy of linux on the sytem. My normal process to get running is to install slackware. download 2.4.2 and the latest ac patch. Compile, add ide=reverse to lilo, switch the hd over to the highpoint hpt366 controller and reboot. As soon as I boot corruption begins and drive will be useless within 10 minutes. I have also tried leaving the HD on the VIA82686a controller witht the same results. Also note I have tried IBM & MAXTOR UDMA100 drives as well as IBM & WD UDMA66 Drives. I have tried both 40 & 80 pin cables on the drives. Please cc me in your replies as I am not subscribed to the list. Thank you in advance for any help - 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: reiserfs-oops; kernel 2.4.3-pre4
On Thursday, March 15, 2001 02:00:11 PM +0100 Andreas Klein
<[EMAIL PROTECTED]> wrote:
[ oops ]
>>> EIP; c016f090<=
> Trace; c0160046
> Trace; c015c8a8
>
> The machine is running linux-2.4.3-pre4 including the reiserfs-patches
> from Alexander Zarochentcev.
Ah, I see. objectid-sharing.diff will pass a null inode to comp_short_keys
if iget4 returns a bad_inode.
Looks like you were using NFS, you'll want to look through the docs on
www.reiserfs.org for the additional patches required to make NFS and
reiserfs play nice.
The attached patch replaces objectid-sharing.diff. The bug was not present
in pure 2.4.x or 2.4.x-ac kernels.
-chris
--- diff/linux/fs/reiserfs/inode.c Thu Mar 15 09:47:18 2001
+++ linux/fs/reiserfs/inode.c Thu Mar 15 09:39:06 2001
@@ -1159,11 +1159,17 @@
if (!inode)
return inode ;
-//if (comp_short_keys (INODE_PKEY (inode), key)) {
if (is_bad_inode (inode)) {
reiserfs_warning ("vs-13048: reiserfs_iget: "
"bad_inode. Stat data of (%lu %lu) not found\n",
key->on_disk_key.k_dir_id, key->on_disk_key.k_objectid);
+ iput (inode);
+ inode = 0;
+} else if (comp_short_keys (INODE_PKEY (inode), key)) {
+ reiserfs_warning ("vs-13049: reiserfs_iget: "
+ "Looking for (%lu %lu), found inode of (%lu %lu)\n",
+ key->on_disk_key.k_dir_id, key->on_disk_key.k_objectid,
+ INODE_PKEY (inode)->k_dir_id, INODE_PKEY
+(inode)->k_objectid);
iput (inode);
inode = 0;
}
Re: Core dumps for threads: Request for your patch (hack)
Hello, Can I get a copy of your patch, too? On Thu, 15 Mar 2001 [EMAIL PROTECTED] wrote: > > > > >(I have a complimentary hack that will dump the stacks of all the > >rest of the threads as well (though its a good trick to get gdb to > >interpret this). Available upon request.) > > > > Hello Adam, > > Could I take a look at your patch ? > > Regards > Suparna > > Suparna Bhattacharya > IBM Software Lab, India > E-mail : [EMAIL PROTECTED] > Phone : 91-80-5267117, Extn : 2525 > > > - > 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/ > -- Otto Fung Tel (Mobile) : +852 9871 6871 Email (Work): [EMAIL PROTECTED] Email (Personal): [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/
Performance is weird (fwd)
-- Subject: Performance is weird The following message was first posted to linux-atm mailing list, it is followed with one of the replies I got, thanks Werner Almesberger <[EMAIL PROTECTED]>. Actually, with 2.4.3pre4 kernel I got something like 66Mbit/s which were better than the 2.4.2 results. -- Hello, I am running a set of ForeRunner LE 155 cards on two Athlon 900 machines. The cards are currently back to back connected. I am having problems with performance and this problem seems a bit curious to me. The boxes are running kernel versions 2.4.2 with the builtin ATM functionality. First when the machine is idle and i run ttcp_atm, the record is: [root@akvagw test]# ./ttcp_atm -t -a -s 0.90 ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013 atm -> 0.90 ttcp-t: socket ttcp-t: 16777216 bytes in 3.805066 real seconds = 4305.838585 KB/sec (35.273430 Mb/sec) I can get the same result when I run it as many times as I want when the machine is idle, however, the performance of the increases a lot when I give the processor something to do, for example compile the kernel, when gcc is compiling the kernel, I get better results: [root@akvagw test]# ./ttcp_atm -t -a -s 0.90 ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013 atm -> 0.90 ttcp-t: socket ttcp-t: 16777216 bytes in 0.997561 real seconds = 16424.058278 KB/sec (134.545885 Mb/sec) For the record, the remote machine does not affect the tests, because the machine just sends data even when none listens. Can someone explain, and maybe do something, please? Or am I supposed to compile kernel all the time on my production ATM routers. Same seems to apply when I stream UDP via my 3C905C card to one of my routers, first I get 60Mbytes / s, then 94Mbytes/s when I start to compile the kernel. Thanks, Sampsa Ranta [EMAIL PROTECTED] " Don't know where those "negative CPU cycles" come from. It's probably a driver problem. Could be that either you're triggering scheduling of a softirq or such, where there normally wouldn't be one (but should be), or that there's a race condition leading to the loss of an event (softirq, tasklet, wait queue, etc.), and background activity makes this happen in the correct order. " - 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/
Need help with allocating a 2M buffer size
I have a real picky tape drive (DLT series) that likes to be fed large chunks of data at once, otherwise after every 2-4KB of data it halts and rewinds itself because its cache for writing to the tape is empty. My best solution to this problem was to use 'tar -b 4096', which sends 4096 x 512-byte blocks at once for a total of a 2MB buffer size. This worked fine for several weeks, until 2 days ago I got this message (and the backup fails): st: failed to enlarge buffer to 2097152 bytes. Free memory shows: total used free sharedbuffers cached Mem:517036 514468 2568 751908 47804 189488 -/+ buffers/cache: 277176 239860 Swap: 136544452 136092 Unfortunately, all of the "free" memory right now is eaten up using cache. Is there a way I can just tell the kernel to allocate memory from the cache for the buffer? I'm sure there's gotta be a 2MB-sized chunk in that 189MB cache -somewhere-. Why doesn't the kernel's get_free_pages() function support moving data around in memory to get larger chunks for what it needs? I see this same problem happening in SVGATextMode where allocating space for a NxM character screen (where NxM >= 16384) fails because there is no contiguous memory space. I think at least it should be able to use some cache. Suggestions? -Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [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: Drvie Corruption CONSTANTLY with Linux and KT7-RAID
>At this point I am 100% lost. any help would be >greatly appreciated. I am willing to do any testing >of the system that anyone may need. Currently I have >no working copy of linux on the sytem. My normal >process to get running is to install slackware. >download 2.4.2 and the latest ac patch. Compile, add >ide=reverse to lilo, switch the hd over to the >highpoint hpt366 controller and reboot. As soon as I >boot corruption begins and drive will be useless >within 10 minutes. I have also tried leaving the HD >on the VIA82686a controller witht the same results. >Also note I have tried IBM & MAXTOR UDMA100 drives as >well as IBM & WD UDMA66 Drives. I have tried both 40 >& 80 pin cables on the drives. I suggest using the 82686-based controller rather than the HPT one. Also, try running with DMA mode disabled. Personally, I'm running fine with the 82686-based controller in DMA mode with a Seagate UDMA/66 drive. You might also want to look at the BIOS settings, which Windows drivers might "adjust" at runtime to saner values. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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/
task switch hook - crashes
I am experimenting with adding a few hooks to the kernel. One of the hooks gets invoked every time the kernel switches two tasks. To do this I added a single line to schedule() right before the tasks are switched: ... if (task_switch_hook) task_switch_hook(prev, next) switch_to(prev, next, prev); ... I then wrote a module that attaches a function to this hook in its init_module() function. The problem is that if I do this, the kernel crashes. Sometimes, the hooks are invoked a few times, other times, the machine locks up immediately. I previous version that compiled everything into the kernel worked fine. I don't quite understand why this does not work. Is this due to some virtual memory interactions? Maybe the problem is that modules are vmalloc-ed and the hook function should be kmalloc-ed? Any insights? Thanks, -- Kris - 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: Is swap == 2 * RAM a permanent thing?
Please Rik, could you explain what you mean with "reclaim swap space when we run out". In my (limited) understanding, when there's no more free memory (ram and swap space), the kernel starts to kill process (and the choice is a difficult point). Are you proposing to add an API to reclaim swap instead of killing process ? Other thing (certainly related) what is supposed to have changed between 2.2 and 2.4. Thanks, Christophe On jeu, 15 mar 2001 14:08:50 Rik van Riel wrote: > On Thu, 15 Mar 2001, Mike A. Harris wrote: > > > Is the fact that we're supposed to use double the RAM size as > > swap a permanent thing or a temporary annoyance that will get > > tweaked/fixed in the future at some point during 2.4.x perhaps? > > > > What are the technical reasons behind this change? > > The reason is that the Linux 2.4 kernel no longer reclaims swap > space on swapin (2.2 reclaimed swap space on write access, which > lead to fragmented swap space in lots of workloads). > > This means that a lot of memory ends up "duplicated" in RAM and > in swap. > > I plan on doing some code to reclaim swap space when we run out, > but Linus doesn't seem to like that idea very much. His argument > (when you're OOM, you should just fail instead of limp along) > makes a lot of sense, however, and the reclaiming of swap space > isn't really high on my TODO list ... > > OTOH, for people who have swap < RAM and use it just as a small > overflow area, Linus' argument falls short, so I guess some time > in the future we will have code to reclaim swap space when needed. > > regards, > > Rik > -- > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ > http://www.conectiva.com/ http://distro.conectiva.com.br/ > > - > 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/ > -- Christophe Barbé Software Engineer Lineo High Availability Group 42-46, rue Médéric 92110 Clichy - France phone (33).1.41.40.02.12 fax (33).1.41.40.02.01 www.lineo.com - 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: Is swap == 2 * RAM a permanent thing?
On Thu, 15 Mar 2001, christophe barbe wrote: > Please Rik, could you explain what you mean with "reclaim swap > space when we run out". In my (limited) understanding, when > there's no more free memory (ram and swap space), the kernel > starts to kill process (and the choice is a difficult point). > Are you proposing to add an API to reclaim swap instead of > killing process ? When we swap something in from swap, it is in effect "duplicated" in memory and swap. Freeing the swap space of these duplicates will mean we have, effectively, more swap space. Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - 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/
VIA686A chipset crash under 2.4.2-ac20
Kernel 2.4.2 with ac20 patch seems doesn't like my motherboard
I have FIC SD11 with VIA686A chipset. I compiled it with support of
VIA82Cxxx and DMA support by default. First it seemed like work but
after a while I started to get errors like these:
kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Before I compiled kernel 2.4.2 without ac patches and got the same errors.
HDD Fujitsu MPE3136AT.
Here is a part of config file for kernel (only set variables)
#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y
#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
#
# IDE chipset support/bugfixes
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y
-
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: OOPS when switching consoles while closing X.
Ok. I had -ac20 sources installed, but was using -ac17 results, so I guess it would look wrong... Attached now is the -ac20 ksymoops output, using correct System.map, though I'm not sure about: "Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry" Is this normal? I've also attached the -ac20 dmesg. The oops seems to occur most often when X has heavy disk activity, probably swapping (64 megs RAM here). Cheers, Matt Johnston On Thu, 15 Mar 2001 22:10, you wrote: > Matt Johnston wrote: > > Hi. > > > > I've had a semi-reproducable oops with the kernel. It happens when I'm > > shutting down X (Xfree86 4.02 cvs), while it is closing all open apps > > (KDE 2.1.1 cvs). I switch to a text console (ctrl-alt-F2 etc), and it > > crashes almost as soon as the text console is there. > > Someone is calling console functions from interrupt context. > Unfortunately your backtrace looks wrong. Could you > please rerun ksymoops and send me the output? Make > sure you're using the correct System.map (ksymoops -m). > > It should be pretty straightforward to fix. While we're there > we'll do something about do_SAK(), which is acquiring the > tasklist_lock from interrupt context. For heaven's sake. > > - ksymoops 2.3.7 on i686 2.4.2-ac20. Options used -V (default) -k /proc/ksyms (specified) -l /proc/modules (specified) -o /lib/modules/2.4.2-ac20/ (specified) -m /usr/src/linux/System.map (specified) Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry invalid operand: CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010213 eax: ebx: c120 ecx: 0264 edx: c3d8a000 esi: c3d8a000 edi: c3d8a169 ebp: esp: c0207e68 ds: 0018 es: 0018 ss: 0018 Stack: c0189060 c3d8a073 c017d3bf c3d8a000 c3d8a568 c3d8a168 c0207fa4 0016 c112c000 7318c4a1 ffa0 c3d8a569 c3d8a169 c0190fe5 c0258360 c0190930 03e8 c0190e48 01f6 c112bc00 c0258360 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b b9 00 95 1f c0 ff 0d 00 95 1f c0 0f 88 a2 c0 0b 00 c7 >>EIP; c011520f<= Trace; c0189060 Trace; c017d3bf Trace; c0190fe5 Trace; c0190930 Trace; c0190e48 Trace; c01cec28 <__const_udelay+1c/24> Trace; c01943dd Trace; c018d450 Trace; c018d4a9 Trace; c017b895 Trace; c0118914 <__run_task_queue+4c/68> Trace; c011ac56 Trace; c011883f Trace; c0118778 Trace; c011867f Trace; c010a051 Trace; c0107120 Trace; c0107120 Trace; c0108db0 Trace; c0107120 Trace; c0107120 Trace; c0100018 Trace; c0107143 Trace; c01071a9 Trace; c0105000 Trace; c0100191 Code; c011520f <_EIP>: Code; c011520f<= 0: 0f 0b ud2a <= Code; c0115211 2: b9 00 95 1f c0mov$0xc01f9500,%ecx Code; c0115216 7: ff 0d 00 95 1f c0 decl 0xc01f9500 Code; c011521c d: 0f 88 a2 c0 0b 00 js bc0b5 <_EIP+0xbc0b5> c01d12c4 Code; c0115222 13: c7 00 00 00 00 00 movl $0x0,(%eax) <0> Kernel panic: Aiee, killing interrupt handler! 1 warning issued. Results may not be reliable. Linux version 2.4.2-ac20 ([EMAIL PROTECTED]) (gcc version 2.95.2 19991024 (release)) #3 Thu Mar 15 22:30:08 WST 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 0002 @ 000e (reserved) BIOS-e820: 03ef @ 0010 (usable) BIOS-e820: 8000 @ 03ff (ACPI data) BIOS-e820: 8000 @ 03ff8000 (ACPI NVS) BIOS-e820: 1000 @ fec0 (reserved) BIOS-e820: 1000 @ fee0 (reserved) BIOS-e820: 0008 @ fff8 (reserved) On node 0 totalpages: 16368 zone(0): 4096 pages. zone(1): 12272 pages. zone(2): 0 pages. Kernel command line: root=/dev/hda6 ro BOOT_IMAGE=242ac20 Initializing CPU#0 Detected 398.207 MHz processor. Console: colour VGA+ 80x30 Calibrating delay loop... 794.62 BogoMIPS Memory: 62576k/65472k available (840k kernel code, 2508k reserved, 204k data, 168k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) CPU: Before vendor init, caps: 0183fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 128K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0183fbff CPU: After generic, caps: 0183fbff CPU: Common caps: 0183fbff 00
Re: Need help with allocating a 2M buffer size
On Thu, 15 Mar 2001, Byron Stanoszek wrote: > I have a real picky tape drive (DLT series) that likes to be fed large chunks > of data at once, otherwise after every 2-4KB of data it halts and rewinds > itself because its cache for writing to the tape is empty. > > My best solution to this problem was to use 'tar -b 4096', which sends 4096 x > 512-byte blocks at once for a total of a 2MB buffer size. This worked fine for > several weeks, until 2 days ago I got this message (and the backup fails): > > st: failed to enlarge buffer to 2097152 bytes. > Look at ../linux/drivers/scsi/st_options.h . You might want to set ST_MAX_BUFFERS to a higher value. This wastes some memory when the driver is not in-use, but you can reduce the tendency to need to allocate more space at run-time. You can also lower the ST_WRITE_THRESHOLD. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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/
pivot_root & linuxrc problem
Hi, may be thats a bug, or I'm doing something really wrong :) from Documentation/initrd.txt: "# cd /new-root # mkdir initrd # pivot_root . initrd Now, the linuxrc process may still access the old root via its executable, shared libraries, standard input/output/error, and its current root directory. All these references are dropped by the following command: # exec chroot . what-follows dev/console 2>&1 Where what-follows is a program under the new root, e.g. /sbin/init" How can I "exec /sbin/init" from "/linuxrc", whatever it is, if "linuxrc" does not get PID=1? Actually, why does NOT "linuxrc" get PID=1? A task list after booting with "root=/dev/rd/0" and "init=/linuxurc", where "linuxrc" is simply "bash", shows that: "swapper" got PID=1, next come other kernel threads with a parent PID=1, and "linuxrc" got PID=7 and a parent PID=1. "init" sees it does not have PID=1 and simply bails out, next happens this: "Note: if linuxrc or any program exec'ed from it terminates for some reason, the old change_root mechanism is invoked (see section "Obsolete root change mechanism")." I probably misunderstand something here, but could you please help? In summary: What is "swapper" and why does it get PID=1 and "linuxrc" does not? If it is supposed to be that way, how do I "exec /sbin/init" from "linuxrc" then? Also why "/linuxrc" is hardcoded in init/main.c, so telling kernel "root=/dev/rd/0 init=/sbin/whatever" does still invoke "/linuxrc"? Thanks a lot, Art. - 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: How to optimize routing performance
On Thu, 15 Mar 2001, Rik van Riel wrote: > On Thu, 15 Mar 2001, [ISO-8859-1] Mårten Wikström wrote: > > > I've performed a test on the routing capacity of a Linux 2.4.2 box > > versus a FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with > > 64Mb memory, and two DEC 100Mbit ethernet cards. I used a Smartbits > > test-tool to measure the packet throughput and the packet size was set > > to 64 bytes. Linux dropped no packets up to about 27000 packets/s, but > > then it started to drop packets at higher rates. Worse yet, the output > > rate actually decreased, so at the input rate of 4 packets/s > > almost no packets got through. The behaviour of FreeBSD was different, > > it showed a steadily increased output rate up to about 7 packets/s > > before the output rate decreased. (Then the output rate was apprx. > > 4 packets/s). > > > So, my question is: are these figures true, or is it possible to > > optimize the kernel somehow? The only changes I have made to the > > kernel config was to disable advanced routing. > > There are some flow control options in the kernel which should > help. From your description, it looks like they aren't enabled > by default ... You want to have CONFIG_NET_HW_FLOWCONTROL enabled. If you don't the kernel gets _alot_ of interrupts from the NIC and dosn't have any cycles left to do anything. So you want to turn this on! > At the NordU/USENIX conference in Stockholm (this february) I > saw a nice presentation on the flow control code in the Linux > networking code and how it improved networking performance. > I'm pretty convinced that flow control _should_ be saving your > system in this case. That was probably Jamal Hadi and Robert Olsson. They have been optimizing the tulip driver. These optimizations havn't been integrated with the "vanilla" driver yet, but I hope the can integrate it soon. They have one version that is very optimized and then they have one version that have even more optimizations, ie. it uses polling at high interruptload. you will find these drivers here: ftp://robur.slu.se/pub/Linux/net-development/ The latest versions are: tulip-ss010111.tar.gz and tulip-ss010116-poll.tar.gz > OTOH, if they _are_ enabled, the networking people seem to have > a new item for their TODO list. ;) Yup. You can take a look here too: http://robur.slu.se/Linux/net-development/jamal/FF-html/ This is the presentation they gave at OLS (IIRC) And this is the final result: http://robur.slu.se/Linux/net-development/jamal/FF-html/img26.htm As you can see the throughput is a _lot_ higher with this driver. One final note: The makefile in at least tulip-ss010111.tar.gz is in the old format (not the new as 2.4.0-testX introduced), but you can copy the makefile from the "vanilla" driver and It'lll work like a charm. Please redo your tests with this driver and report the results to me and this list. I really want to know how it compares against FreeBSD. /Martin - 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/
Hardware problem detection? Linux 2.4.3-pre4 lockups.
I am at a total loss, But I have found some interesting anomalies with my hardware. My Current Setup: Supermicro S370DE6 (Serverworks Chipset) Dual PIII 866 2 x 256 MB PC133 ECC SDRAM onboard AIC 7899 SCSI Controller. 36G,73GB Seagate Cheetah Drive. Voodoo4 4500 AGP video, Fore PCA 200e ATM Problem, I have a program the can read a file(large, or small) it will then transmit the data over atm, ethernet, localhost,or write to a file. I have noticed that the machine will consistently crash(hard lockup) when I do a read loop of the File. It never locks up at the same place, and I have changed it so that it never actually does anything with the data after it reads. Still, same result. Things that have "fixed" the problem. Setting the FSB to 100(jumpered) will allow me to run forever. Also, Setting the L1 Cache to Write-through instead of write back will allow me to run forever at 133, but the performance hit is worse than setting the FSB to 100. Another note. When I have attempted to compile the kernel for Uni processor. I started getting segmentation faults with gcc. Now this tells me it might be the processor. But I have nothing overclocked, so I would think that it might be some kind of timing issue in the kernel. I have two machines set up this way. One is much more stable. But I do observe the occasional crash.(hard lockup) I have also seen fsck crash as well. when the system was not shut down correctly. ( as a hard lockup happens very frequently.) Here are some things that I have tried, but Have not fixed it. 1) SMP Kernel with "noapic" at lilo prompt ( and without the noapic) 2) Uni Kernel w/ & w/out apic I am at a total loss. Is there anything I can do(other than run at 100 FSB)? Nathan P.S. I have enclosed the dmesg output for my Uniprocessor kernel <> dmesg.out.uni
Network init script causes 2.2.18 kernel oops (tulip driver)
Greetings,
This is a reproducible oops, and my guess is that it's related to
the tulip driver included in the 2.2.18 source tree. We're using
a D-Link 4 port NIC, and it appears that it doesn't work well with
IPV6 interfaces.
Keywords: linux kernel-2.2.18 tulip D-Link 4-port NIC DFE-570 TX
Relevant Software
-
kernel 2.2.18 i686
modutils-2.3.21
glibc-2.1.3-22
ipv6 enabled
net-tools 1.54
ifconfig 1.39 (1999-03-18)
tulip module (static const char version[] = "tulip.c:v0.91g-ppc 7/16/99
[EMAIL PROTECTED]\n";) from the kernel src.rpm.
initscripts-5.00-1.i386.rpm (with the addition below)
Relevant Hardware
-
NIC: D-Link DFE-570 TX 4-port
Cause of the Oops
-
I had included IPV6 support into the kernel without really wanting
it, so my intention was to turn off the IPV6 interfaces until I could
replace the kernel. I created the following script to be called by
ifup-post. The inclusion of the script cause the oops every time.
Note that simply issuing the "ifconfig" command line would not always
cause the oops. It seemed to happen 100% of the time only if it
was immediately called by ifup-post, as if timing had something to
do with the problem.
It is also odd to me that the IPV6 interfaces came up automatically,
even though the init scripts do not specify an IP address for them,
or bring them up specifically. /sbin/ifconfig just makes a guess and
does it.
/etc/sysconfig/network-scripts/ifup-local:
#! /bin/sh
DEVICE=$1
# turn off inet6 IFs
if [ ! -z "${DEVICE}" ]; then
INET6ADDR=$( ifconfig ${DEVICE} |grep inet6 |awk '{print $3}' )
if [ ! -z "${INET6ADDR}" ]; then
ifconfig ${DEVICE} del ${INET6ADDR}
fi
fi
Oops Info (copied by hand, klogd didn't catch it)
-
Call Trace: [] [] []
[] [] []
[] [] []
[] [] []
Code: 8b 40 34 89 42 04 8b 86 88 00 00 00 2b 86 84 00 00 00 83 f8
ksymoops output
---
ksymoops -m /boot/System.map -v vmlinux oops.txt
ksymoops 0.7c on i686 2.2.18. Options used
-v vmlinux (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.18/ (default)
-m /boot/System.map-spc-2.2.18-6 (specified)
Call Trace: [] [] []
[] [] []
[] [] []
[] [] []
Code: 8b 40 34 89 42 04 8b 86 88 00 00 00 2b 86 84 00 00 00 83 f8
Using defaults from ksymoops -t elf32-i386 -a i386
Trace; c0109f4d
Trace; c0117ca1
Trace; c010a2a3
Trace; c0109f70
Trace; c010796d
Trace; c0106000
Trace; c0107990
Trace; c01090ec
Trace; c0106000
Trace; c010607b
Trace; c0106000
Trace; c0100175
Code; Before first symbol
<_EIP>:
Code; Before first symbol
0: 8b 40 34 mov0x34(%eax),%eax
Code; 0003 Before first symbol
3: 89 42 04 mov%eax,0x4(%edx)
Code; 0006 Before first symbol
6: 8b 86 88 00 00 00 mov0x88(%esi),%eax
Code; 000c Before first symbol
c: 2b 86 84 00 00 00 sub0x84(%esi),%eax
Code; 0012 Before first symbol
12: 83 f8 00 cmp$0x0,%eax
I hope this is enough to find the problem. I can reproduce it at will,
so if you need more information, contact me and I will be glad to help.
Matthew Callaway
-
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: Is swap == 2 * RAM a permanent thing?
Ok I understand better now. So when we swap in, the place is still reserved in swap for the next time we swap off the same memory part. The swap is freed only when the owner terminates. Then when we need more memory, we need to swap off but we don't use the duplicated part. I understand that it is to avoid fragmentation but this can lead to false OOM situation (false because we have free memory in swap but it's reserved to avoid fragmentation). Christophe On ven, 16 mar 2001 00:26:35 Rik van Riel wrote: > On Thu, 15 Mar 2001, christophe barbe wrote: > > > Please Rik, could you explain what you mean with "reclaim swap > > space when we run out". In my (limited) understanding, when > > there's no more free memory (ram and swap space), the kernel > > starts to kill process (and the choice is a difficult point). > > Are you proposing to add an API to reclaim swap instead of > > killing process ? > > When we swap something in from swap, it is in effect "duplicated" > in memory and swap. Freeing the swap space of these duplicates > will mean we have, effectively, more swap space. > > Rik > -- > Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml > > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ > http://www.conectiva.com/ http://distro.conectiva.com/ > > - > 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/ > -- Christophe Barbé Software Engineer Lineo High Availability Group 42-46, rue Médéric 92110 Clichy - France phone (33).1.41.40.02.12 fax (33).1.41.40.02.01 www.lineo.com - 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: Is swap == 2 * RAM a permanent thing?
IIRC, when this discussion of swap size first came up, the general conclusion was NOT that you should have swap = 2 * RAM, but that you should have swap(2.4.x) = 2 * swap(2.2.x), that is, twice as much swap as you did under 2.2.x. So if you never swapped at all under 2.2.x, you should not need any swap space in 2.4.x either. Is this correct? Also, what would be the consequences of not having "enough" swap? Just OOM faster? Or more serious than that? I have 512MB of RAM and rarely swap, so normally have just a 256MB swap partition. Is this bad? It seems to work fine... Thanks! Torrey Hoffman - 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: How to optimize routing performance
On Thu, 15 Mar 2001, Robert Olsson wrote: > CONFIG_NET_HW_FLOWCONTROL enables kernel code for it. But device > drivers has to have support for it. But unfortunely very few drivers > has support for it. Isn't it possible to put something like this in the layer just above the driver ? It probably won't work as well as putting it directly in the driver, but it'll at least keep Linux from collapsing under really heavy loads ... regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - 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: Hardware problem detection? Linux 2.4.3-pre4 lockups.
On Thu, 15 Mar 2001, Nathan Black wrote: > I am at a total loss, But I have found some interesting anomalies with my > hardware. That is about how I was feeling when I had similar problems. > My Current Setup: > Supermicro S370DE6 (Serverworks Chipset) > Dual PIII 866 > 2 x 256 MB PC133 ECC SDRAM > onboard AIC 7899 SCSI Controller. > 36G,73GB Seagate Cheetah Drive. > Voodoo4 4500 AGP video, > Fore PCA 200e ATM My setup was (is): Tyan Thunder 2500 (Serverworks) Dual PIII 667s 2 x 512 MB PC133 ECC SDRAM Onboard dual SYM53C896 controller 5 18.2 GB Seagate Cheetahs nVideo Vanta Onboard Intel 10/100 > Problem, I have a program the can read a file(large, or small) it will then > transmit the data over atm, ethernet, localhost,or write to a file. I could move a lot of network traffic as long as I wasn't hitting the disk too hard. > I have noticed that the machine will consistently crash(hard lockup) when I > do a read loop of the File. It never locks up at the same place, and I have > changed it so that it never actually does anything with the data after it > reads. Still, same result. Any time I pushed the disk subsystem hard I would get a lockup. Sometimes the kernel would oops, the program writing to the disk would segfault, but always the machine locked hard. > Things that have "fixed" the problem. Setting the FSB to 100(jumpered) will > allow me to run forever. > Also, Setting the L1 Cache to Write-through instead of write back will allow > me to run forever at 133, but the performance hit is worse than setting the > FSB to 100. If I forced things to run slower I could run longer, like changing the cache setting, never tried the FSB setting. But even with the machine slowed down I could eventually lock it up if I pushed the disks hard enough (12 bonnies at the same time would always do it). > Another note. When I have attempted to compile the kernel for Uni processor. > I started getting segmentation faults with gcc. > Now this tells me it might be the processor. But I have nothing overclocked, > so I would think that it might be some kind of timing issue in the kernel. I saw so much strange stuff I couldn't pin it down to one thing, except perhaps the processor. > I have two machines set up this way. One is much more stable. But I do > observe the occasional crash.(hard lockup) I too had two identical machines. I was doing all my work on one, and was planning on copying the finished product over to the second when I was done. After I started suspecting the hardware, I started up the other machine. It ran perfectly. I could push it as hard as I wanted with no trouble at all. > I have also seen fsck crash as well. when the system was not shut down > correctly. ( as a hard lockup happens very frequently.) > > Here are some things that I have tried, but Have not fixed it. > 1) SMP Kernel with "noapic" at lilo prompt ( and without the noapic) > 2) Uni Kernel w/ & w/out apic > > I am at a total loss. > Is there anything I can do(other than run at 100 FSB)? > > Nathan > > P.S. I have enclosed the dmesg output for my Uniprocessor kernel > <> In the end I started swapping processors between the two machines. I found the problem followed 1 of my processors. I called Intel and after 2 days of convincing they RMAed my old processor and sent me a replacement. Both machines have been running perfectly since then. If you have any more processors I'd try swapping them around. But since you are seeing problems with 2 similar machines, I wouldn't get my hopes up as to this being the solution. -Chris -- Two penguins were walking on an iceberg. The first penguin said to the second, "you look like you are wearing a tuxedo." The second penguin said, "I might be..." --David Lynch, Twin Peaks - 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: Is swap == 2 * RAM a permanent thing?
On Thu, 15 Mar 2001, Mike Harrold wrote: > 1) If a process uses swap space and then later (after being paged >into memory -- or even not) it completes, is killed, etc., is >the swap space reclaimed then? > > 2) If a process uses swap, is paged into memory, and is then swapped >out again, does it re-use the same swap as before? Yes and yes. Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - 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: Is swap == 2 * RAM a permanent thing?
On Thu, Mar 15, 2001 at 08:26:35PM -0300, Rik van Riel wrote: > When we swap something in from swap, it is in effect "duplicated" > in memory and swap. Freeing the swap space of these duplicates > will mean we have, effectively, more swap space. Hi Rik, Thanks for the explanation. It brings another question to mind. Lets assume that I have two 16M processes and 32M of swap space. Both the processes have been swapped out at some point in time so the swap space is full. A third process is running and tries to allocate some memory, and the kernel has no free pages. Since swap is full, will the kernel kill my process, or will it try and page out one of the processes that does have space on swap? Thanks, Jim - 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.2.19 pre13 doesn't like retransmitted SYN ACK packets
2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which arrives after we've sent out the final ACK of the handshake. For example: tcpdump: listening on eth0 15:15:15.075670 wolery.Stanford.EDU.1341 > plan9.bell-labs.com.www: S 1057306555:1057306555(0) win 32120 (DF) [tos 0x10] 15:15:15.156320 plan9.bell-labs.com.www > wolery.Stanford.EDU.1341: S 1042976132:1042976132(0) ack 1057306556 win 1460 15:15:15.156364 wolery.Stanford.EDU.1341 > plan9.bell-labs.com.www: . ack 1 win 32120 (DF) [tos 0x10] 15:15:15.204186 plan9.bell-labs.com.www > wolery.Stanford.EDU.1341: S 1042976132:1042976132(0) ack 1057306556 win 1460 15:15:15.204232 wolery.Stanford.EDU.1341 > plan9.bell-labs.com.www: R 1057306556:1057306556(0) win 0 I do not know if this behavior is correct or not from the TCP spec. It seems unlikely to me, given that duplicate packets are expected and ignored just about everywhere else. As a practical matter, this behavior makes it close to impossible to communicate with a host that commonly sends duplicate SYN ACKs. plan9.bell-labs.com is just such; I estimate I get past the initial handshake one connection in twenty. This kernel does not have SYN cookies compiled in. rp_filter is 1, all other TCP and IP tunables are at their defaults. zw - 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: Network init script causes 2.2.18 kernel oops (tulip driver)
Matthew Callaway wrote: > Greetings, > > This is a reproducible oops, and my guess is that it's related to > the tulip driver included in the 2.2.18 source tree. We're using > a D-Link 4 port NIC, and it appears that it doesn't work well with > IPV6 interfaces. I have had problems with this NIC as well... Redhat's installer/kudzu tries to use de4x5 (sp?) module ... bad news. But it works fine using old_tulip module with only IPv4. Same with 2.2 series and 2.4 series kernels. FYI > > > Keywords: linux kernel-2.2.18 tulip D-Link 4-port NIC DFE-570 TX - 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: poll() behaves differently in Linux 2.4.1 vs. Linux 2.2.14 (POLLHUP)
Hello! > Sure, workarounds exist, but they just complicates > things. Working around --- what? An example of application hitting the case is enough to make me completely agreed. But genarally we are not going to match any os and even yourselves yesterday or tomorrow in the cases when behaviour is truly undefined and the answer is meaningless. For me any solution from retunring 0 or returning POLLHUO to killing offending application or generating an answer using random number generator look equally good, acceptable and 100% compatible in this case. 8) Alexey - 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: How to optimize routing performance
Just my .02 - There are some scheduler patches that are not part of the main kernel tree at this point (mostly since they have yet to be optimized for the common case) which make quite a big difference under heavy load - you might want to check out: http://lse.sourceforge.net/scheduling/ cu Jup Mårten Wikström wrote: > I've performed a test on the routing capacity of a Linux 2.4.2 box versus a > FreeBSD 4.2 box. I used two Pentium Pro 200Mhz computers with 64Mb memory, > and two DEC 100Mbit ethernet cards. I used a Smartbits test-tool to measure > the packet throughput and the packet size was set to 64 bytes. Linux dropped > no packets up to about 27000 packets/s, but then it started to drop packets > at higher rates. Worse yet, the output rate actually decreased, so at the > input rate of 4 packets/s almost no packets got through. The behaviour > of FreeBSD was different, it showed a steadily increased output rate up to > about 7 packets/s before the output rate decreased. (Then the output > rate was apprx. 4 packets/s). > I have not made any special optimizations, aside from not having any > background processes running. > > So, my question is: are these figures true, or is it possible to optimize > the kernel somehow? The only changes I have made to the kernel config was to > disable advanced routing. > > Thanks, > > Mårten > > - > 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/ - 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: Is swap == 2 * RAM a permanent thing?
On Thu, 15 Mar 2001, James Lewis Nance wrote: > On Thu, Mar 15, 2001 at 08:26:35PM -0300, Rik van Riel wrote: > > When we swap something in from swap, it is in effect "duplicated" > > in memory and swap. Freeing the swap space of these duplicates > > will mean we have, effectively, more swap space. > > Thanks for the explanation. It brings another question to > mind. Lets assume that I have two 16M processes and 32M of swap > space. Both the processes have been swapped out at some point > in time so the swap space is full. A third process is running > and tries to allocate some memory, and the kernel has no free > pages. Since swap is full, will the kernel kill my process, or > will it try and page out one of the processes that does have > space on swap? It will end up swapping out the two processes which already have space in swap ... even if the 3rd process is idle. In that situation you could argue for 2 things: 1) the kernel should reclaim space when swap is full 2) you need more swap I guess we'll want a bit of both, possibly with 1) being an optional thing (since swap fragmentation could well be as bad for performance as swapping out the wrong thing). regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - 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: Performance is weird (fwd)
One difference between idle and a running user space app is that the kernel->user space return path checks for pending softirqs, but the ide thread doesn't. Perhaps cpu_idle() should also check for pending softirq's before hlt'ing? idle thread is running. * hw interrupt * * hw interrupt handler * * * packet arrives * * * softirq marked * * hw interrupt handler returns * do_softirq * * net_rx called * * * an hw interrupt interrupts net_rx * * * * a second packet arrives, softirq marked again. * * * hw interrupt returns * * net_rx returns * do_softirq notices that net_rx is queued again, but doesn't process it immediately (otherwise it would cause an endless loop) * hw interrupt returns idle thread sleeps again. !! one packet is waiting unprocessed What about adding if(softirq_active...) do_softirq() into default_idle? -- Manfred - 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 in 2.2 update_vm_cache_conditional?
On Wed, Mar 14, 2001 at 06:49:33PM +0100, [EMAIL PROTECTED] wrote: > that manifests itself only on S/390: I guess it could trigger also on sparc. > Do you agree that this is a bug? What do you think of this fix: That's a severe bug, fix is obviously right. Andrea - 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: Remote Management (was Re: Alert on LAN)
[Chip Salzenberg] > IBM says, as quoted by Terje Malmedal: >> With the latest release, Alert on LAN 2 now extends IT >> capabilities to remotely manage and control their >> networked PCs: >> >> Remote system reboot upon report of a critical failure >> Repair Operating System >> Update BIOS image >> Perform other diagnostic procedures > OK, fine... but: Where are the authentication and authorization?! > Surely I'm not the only person to see in this "Alert On LAN 2" the > potential for a security disaster. I know I will never buy anything > that supports AOL2 until its security features are openly documented > and testable. Definitely scary possibilites there. I think the best we can realistically hope for is that you can require a password to be sent with each packet. >> The feature I really need is to be able to reset the machine >> remotely when Linux is hung. > Some current PC motherboards support remote management via a serial > line. Of course, you'll need software: The VA Cluster Manager (GPL'd > - http://sourceforge.net/projects/vacm) can monitor and control any > number of clients, limited only by the number of serial ports you can > give it. VACM also includes optional client support for enhanced > monitoring, e.g. of temperatures. I'm not sure which motherboards it > supports, but I'm sure you can find current documentation. :-) I am aware of some motherboards where you can configure the BIOS via RS232. What I want is some way to actually reset a machine that is hung. Currently we are using power-strips where we can switch on and off individual plugs by telneting to the strip. We also use Netra T1's from SUN. They have a small microprosessor listening on the serial port. If you send the escape sequence #. it will take over and allow you to reset or power-cycle the real computer. Very cool stuff: lom>version LOM version: 2.1 LOM checksum: 7CA3 LOM firmware build Aug 6 1999 09:46:27 lom>help The following commands are supported: alarmon alarmoff check console environment faulton faultoff help poweron poweroff reset show version lom>environment LEDs: faultled OFF Alarm1 = OFF Alarm2 = OFF Alarm3 = OFF Fans: 1 = OK speed = 74% 2 = OK speed = 74% 3 = OK speed = 74% PSUs: 1 = OK This functionality is what I hope Alert on LAN2 can give me. -- - Terje [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/
VIA audio and parport in 2.4.2
I have a Asus K7V motherboard and a SB 128 PCI soundcard. The motherboard is vt82c686a based. The SB is a ES1371/AC97 card, seemingly identical to the onboard sound on this type of motherboard. However, the sound rarely works, and there are problems with the parport too. Sound does not work (usually, I have had it work, but I can't reproduce it). The parport behaves strangely. Here is dmesg output: Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ... SMSC Super-IO detection, now testing Ports 2F0, 370 ... 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 8 0x378: readIntrThreshold is 8 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: possible IRQ conflict! 0x378: ECP port cfgA=0x10 cfgB=0x00 0x378: ECP settings irq= dma= parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA] parport0: cpp_mux: aa55f00f52ad51(80) parport0: cpp_daisy: aa5500ff(80) parport0: assign_addrs: aa5500ff(80) parport0: cpp_mux: aa55f00f52ad51(80) parport0: cpp_daisy: aa5500ff(80) parport0: assign_addrs: aa5500ff(80) parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3 Winbond Super-IO detection, now testing ports 3F0,370,250,4E,2E ... SMSC Super-IO detection, now testing Ports 2F0, 370 ... 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 8 0x378: readIntrThreshold is 8 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: possible IRQ conflict! 0x378: ECP port cfgA=0x10 cfgB=0x00 0x378: ECP settings irq= dma= parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA] parport0: cpp_mux: aa55f00f52ad51(80) parport0: cpp_daisy: aa5500ff(80) parport0: assign_addrs: aa5500ff(80) parport0: cpp_mux: aa55f00f52ad51(80) parport0: cpp_daisy: aa5500ff(80) parport0: assign_addrs: aa5500ff(80) parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3 lp0: using parport0 (interrupt-driven). I don't know why it prints it twice. When printing errors are printed (buffer overrun or something like that, it seems RedHat only logs these damn things to console). Also if I try to disbale interrupt driven printing I get an error: [root@dogfox log]# /usr/sbin/tunelp /dev/printers/0 -i 0 tunelp: ioctl: Invalid argument /dev/printers/0 using IRQ 7 With sound, I get: es1371: version v0.27 time 00:47:56 Mar 7 2001 es1371: found chip, vendor id 0x1274 device id 0x1371 revision 0x08 PCI: Found IRQ 10 for device 00:0b.0 es1371: found es1371 rev 8 at io 0xa400 irq 10 es1371: features: joystick 0x0 ac97_codec: AC97 codec, id: 0x:0x (Unknown) Where the id field obviously should not be zero. The IRQ, DMA, I/O ports etc. are all the same as they are in Windows, but in Linux the sound doesn't work and the printer keeps hanging. I also get spurios interrupts on 7 when the parport is not loaded. I know other people are seeing similar effects with sinilar hardware, but to my knowledge there have been no solutions put forward. If anyone has any ideas I can try to diagnose this problem more clearly or wants any specific information, please ask. - 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: How to optimize routing performance
[Sorry for the length] Rik van Riel writes: > On Thu, 15 Mar 2001, Robert Olsson wrote: > > > CONFIG_NET_HW_FLOWCONTROL enables kernel code for it. But device > > drivers has to have support for it. But unfortunely very few drivers > > has support for it. > > Isn't it possible to put something like this in the layer just > above the driver ? There is a dropping point in netif_rx. The problem is that knowledge of congestion has to be pushed back to the devices that is causing this. Alexey added netdev_dropping for drivers to check. And via netdev_wakeup() the drivers xon_metod can be called when the backlog below a certain threshold. So from here the driver has do the work. Not investing any resources and interrupts in packets we still have to drop. This what happens at very high load a kind of livelock. For routers routing protocols will time out and we loose conetivity. But I would say its important for all apps. In 2.4.0-test10 Jamal added sampling of the backlog queue so device drivers get the current congestion level. This opens new possiblities. > It probably won't work as well as putting it directly in the > driver, but it'll at least keep Linux from collapsing under > really heavy loads ... And we have done experiments with controlling interrupts and running the RX at "lower" priority. The idea is take RX-interrupt and immediately postponing the RX process to tasklet. The tasklet opens for new RX-ints. when its done. This way dropping now occurs outside the box since and dropping becomes very undramatically. As little example of this. I monitored a DoS attack on Linux router equipped with this RX-tasklet driver. Admin up6 day(s) 13 hour(s) 37 min 54 sec Last input NOW Last output NOW 5min RX bit/s 22.4 M 5min TX bit/s 1.3 M 5min RX pkts/s 44079< 5min TX pkts/s 877 5min TX errors 0 5min RX errors 0 5min RX dropped 49913< Fb: no 3127894088 low 154133938 mod 6 high 0 drp 0 < Congestion levels Polling: ON starts/pkts/tasklet_count 96545881/2768574948/1850259980 HW_flowcontrol xon's 0 A bit of explanation. Above is output from tulip driver. We are forwarding 44079 and we are dropping 49913 packets per second! This box has full BGP. The DoS attack was going on for about 30 minutes BGP survived and the box was manageable. Under a heavy attack it still performs well. Cheers. --ro - 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: How to optimize routing performance
On Thu, 15 Mar 2001, J Sloan wrote: > There are some scheduler patches that are not part of the > main kernel tree at this point (mostly since they have yet to > be optimized for the common case) which make quite a big > difference under heavy load - you might want to check out: > > http://lse.sourceforge.net/scheduling/ Unrelated. Fun, but unrelated to networking... Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - 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: Remote Management (was Re: Alert on LAN)
According to Terje Malmedal: > I am aware of some motherboards where you can configure the BIOS via > RS232. What I want is some way to actually reset a machine that is > hung. That's possible with VACM-style management. It's not just for BIOS. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "We have no fuel on board, plus or minus 8 kilograms." -- NEAR tech - 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: How to optimize routing performance
Rik van Riel wrote: > On Thu, 15 Mar 2001, J Sloan wrote: > > > There are some scheduler patches that are not part of the > > main kernel tree at this point (mostly since they have yet to > > be optimized for the common case) which make quite a big > > difference under heavy load - you might want to check out: > > > > http://lse.sourceforge.net/scheduling/ > > Unrelated. Fun, but unrelated to networking... Fun, yes, and perhaps not directly related, however under high load, where the sheer numbet of interrupts per second begins to overwhelm the kernel, might it not be relevant? After all, the benchmarks do point to tangible improvements in the performance of network server apps. Or are you saying that the bottleneck is somewhere else completely, or that there wouldn't be a bottleneck in this case if certain kernel parameters were correctly set? Just curious, Jup - 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: __lock_page calls run_task_queue(&tq_disk) unecessarily? (fwd)
Linus,
I never got I answer from you, so I'm going to ask again.
Do you want this patches for 2.4 or not ?
Yes, I tested them.
-- Forwarded message --
Date: Mon, 19 Feb 2001 23:05:23 -0200 (BRST)
From: Marcelo Tosatti <[EMAIL PROTECTED]>
To: Linus Torvalds <[EMAIL PROTECTED]>
Cc: lkml <[EMAIL PROTECTED]>
Subject: Re: __lock_page calls run_task_queue(&tq_disk) unecessarily?
Btw ___wait_on_page() does something similar.
Here goes the patch for both __lock_page() and ___wait_on_page().
--- linux/mm/filemap.c.orig Mon Feb 19 23:51:02 2001
+++ linux/mm/filemap.c Mon Feb 19 23:51:33 2001
@@ -611,11 +611,11 @@
add_wait_queue(&page->wait, &wait);
do {
- sync_page(page);
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
if (!PageLocked(page))
break;
- run_task_queue(&tq_disk);
+
+ sync_page(page);
schedule();
} while (PageLocked(page));
tsk->state = TASK_RUNNING;
@@ -633,10 +633,9 @@
add_wait_queue_exclusive(&page->wait, &wait);
for (;;) {
- sync_page(page);
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
if (PageLocked(page)) {
- run_task_queue(&tq_disk);
+ sync_page(page);
schedule();
continue;
}
On Mon, 19 Feb 2001, Marcelo Tosatti wrote:
>
> Hi Linus,
>
> Take a look at __lock_page:
>
> static void __lock_page(struct page *page)
> {
> struct task_struct *tsk = current;
> DECLARE_WAITQUEUE(wait, tsk);
>
> add_wait_queue_exclusive(&page->wait, &wait);
~> for (;;) {
> sync_page(page);
> set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> if (PageLocked(page)) {
> run_task_queue(&tq_disk);
> schedule();
> continue;
> }
> if (!TryLockPage(page))
> break;
> }
> tsk->state = TASK_RUNNING;
> remove_wait_queue(&page->wait, &wait);
> }
>
>
> Af a process sleeps in __lock_page, sync_page() will be called even if the
> page is already unlocked. (block_sync_page(), the sync_page routine for
> generic block based filesystem calls run_task_queue(&tq_disk)).
>
> I don't see any problem if we remove the run_task_queue(&tq_disk) and put
> sync_page(page) there instead, removing the other sync_page(page) at the
> beginning of the loop.
>
> Comments?
>
> -
> 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/
>
-
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: How to optimize routing performance
On Thu, 15 Mar 2001, J Sloan wrote: > Rik van Riel wrote: > > On Thu, 15 Mar 2001, J Sloan wrote: > > > > > http://lse.sourceforge.net/scheduling/ > > > > Unrelated. Fun, but unrelated to networking... > > Fun, yes, and perhaps not directly related, however > under high load, where the sheer numbet of interrupts > per second begins to overwhelm the kernel, might it > not be relevant? No. > Or are you saying that the bottleneck is somewhere > else completely, Indeed. The bottleneck is with processing the incoming network packets, at the interrupt level. Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - 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: Is swap == 2 * RAM a permanent thing?
On Thu, 15 Mar 2001, William T Wilson wrote: > it seems to me that in 2.2.x it looks like this: > > total usage == swap + RAM > under 2.4.x it looks like: > total usage == swap total usage == maximum(swap, ram) Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - 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: Need help with allocating a 2M buffer size
On Thu, 15 Mar 2001, Byron Stanoszek wrote: > I have a real picky tape drive (DLT series) that likes to be fed large chunks > of data at once, otherwise after every 2-4KB of data it halts and rewinds > itself because its cache for writing to the tape is empty. > > My best solution to this problem was to use 'tar -b 4096', which sends 4096 x > 512-byte blocks at once for a total of a 2MB buffer size. This worked fine for > several weeks, until 2 days ago I got this message (and the backup fails): > > st: failed to enlarge buffer to 2097152 bytes. > The default maximum number of scatter/gather segments in the tape driver is 16. This means that big chunks of memory are needed to allocate a 2 MB buffer. You can increase the number of segments up to, e.g., 128. This means that only 16 kB chunks are needed to make up a 2 MB buffer. The number of scatter/gather segments is also limited by your SCSI adapter driver. Note that even with 16 kB segments you may find problems at some time because multi-page allocations are needed. You can increase the number of scatter/gather segments at system startup/module loading or when compiling the driver. See the file linux/drivers/scsi/README.st for the syntax and st_options.h for the compile-time definition. Kai - 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: How to optimize routing performance
> And we have done experiments with controlling interrupts and running > the RX at "lower" priority. The idea is take RX-interrupt and immediately > postponing the RX process to tasklet. The tasklet opens for new RX-ints. > when its done. This way dropping now occurs outside the box since and > dropping becomes very undramatically. > A bit of explanation. Above is output from tulip driver. We are forwarding > 44079 and we are dropping 49913 packets per second! This box has > full BGP. The DoS attack was going on for about 30 minutes BGP survived > and the box was manageable. Under a heavy attack it still performs well. Nice. Any chance of similar functionality finding its' way outside the Tulip driver, eg. to 3c509 or via-rhine? I'd find those useful, since one or two of my Macs appear to be capable of generating pseudo-DoS levels of traffic under certain circumstances which totally lock a 486 (for the duration) and heavily load a P166 - even though said Macs "only" have 10baseT Ethernet. OTOH, proper management of the circumstances under which this flooding occurs (it's an interaction bug which occurs when the Linux machine ends up with a zero-sized TCP receive window) would also be rather helpful. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - 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: How to optimize routing performance
Rik van Riel wrote: > On Thu, 15 Mar 2001, J Sloan wrote: > > > Fun, yes, and perhaps not directly related, however > > under high load, where the sheer numbet of interrupts > > per second begins to overwhelm the kernel, might it > > not be relevant? > > No. > > > Or are you saying that the bottleneck is somewhere > > else completely, > > Indeed. The bottleneck is with processing the incoming network > packets, at the interrupt level. OK, I'll take this to kernel newbies! :-) Jup - 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: Is swap == 2 * RAM a permanent thing?
On Thu, 15 Mar 2001, Torrey Hoffman wrote: > IIRC, when this discussion of swap size first came up, the general > conclusion was NOT that you should have swap = 2 * RAM, but that you > should have swap(2.4.x) = 2 * swap(2.2.x), that is, twice as much swap > as you did under 2.2.x. it seems to me that in 2.2.x it looks like this: total usage == swap + RAM under 2.4.x it looks like: total usage == swap > So if you never swapped at all under 2.2.x, you should not need any > swap space in 2.4.x either. Right. - 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/
Kernel 2.4.2
A simple question for you guru's.. I just installed kernel 2.4.2 on a slackware system and have a problem with loading a module. It is the 8139too.o module previously the rtl8139.o. It seems that this new driver is not being loaded with this new kernel. Obviously something has changed but I can't seem to see where that is. I noticed though that the directories in /lib/modules for this kernel is different than 2.2.18. Anyways - to get things to work, I have put added this statement to the top of my /etc/rc.d/rc.inet1 file: insmod /usr/src/linux/drivers/net/8139too.o. That seems to get things working but why should I do that. By the way - I do have 'alias eth0 8139too.o' in my /etc/modules.conf file. Any thoughts on where I might be going wrong. And I do have 'CONFIG_KMOD=y' in my kernel configuration.. --- Earth is a beta site. Ted Gervais <[EMAIL PROTECTED]> 44.135.34.201 linux.ve1drg.ampr.org - 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: How to optimize routing performance
On Thu, Mar 15, 2001 at 11:17:19AM -0800, J Sloan wrote: > Rik van Riel wrote: > > On Thu, 15 Mar 2001, J Sloan wrote: > > > > > There are some scheduler patches that are not part of the > > > main kernel tree at this point (mostly since they have yet to > > > be optimized for the common case) which make quite a big > > > difference under heavy load - you might want to check out: > > > > > > http://lse.sourceforge.net/scheduling/ > > > > Unrelated. Fun, but unrelated to networking... > > under high load, where the sheer numbet of interrupts > per second begins to overwhelm the kernel, might it [snip] > Or are you saying that the bottleneck is somewhere > else completely, or that there wouldn't be a bottleneck > in this case if certain kernel parameters were correctly > set? The scheduler schedules tasks not interrupts. Unless it manages to thrash the cache, the scheduler can not affect routing performance. - 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: How to optimize routing performance
Gregory Maxwell wrote: > The scheduler schedules tasks not interrupts. Unless it manages to thrash the > cache, the scheduler can not affect routing performance. OK, thanks for the clarification - I need to get into the source. cu Jup - 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: How to optimize routing performance
On Thu, Mar 15, 2001 at 11:17:19AM -0800, J Sloan wrote: > Rik van Riel wrote: > > > On Thu, 15 Mar 2001, J Sloan wrote: > > > > > There are some scheduler patches that are not part of the > > > main kernel tree at this point (mostly since they have yet to > > > be optimized for the common case) which make quite a big > > > difference under heavy load - you might want to check out: > > > > > > http://lse.sourceforge.net/scheduling/ > > > > Unrelated. Fun, but unrelated to networking... > > Fun, yes, and perhaps not directly related, however > under high load, where the sheer numbet of interrupts > per second begins to overwhelm the kernel, might it > not be relevant? After all, the benchmarks do point to > tangible improvements in the performance of network > server apps. I'm not sure if these patches would be of any use here. One benefit of the multi-queue scheduling patches is that they allow multiple 'wakeups' to run in parallel instead of being serialized by the global runqueue lock. Now if you are getting lots of interrupts which result in task wakeups that could potentially be run in parallel (on separate CPUS with no other serialization in the way) then you 'might' see some benefit. Those are some big IFs. I know little about the networking stack or this workload. Just wanted to explain how this scheduling work 'could' be related to interrupt load. -- Mike Kravetz [EMAIL PROTECTED] IBM Linux Technology Center - 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: Kernel 2.4.2
On Thu, 15 Mar 2001, Ted Gervais wrote: > Anyways - to get things to work, I have put added this statement to the > top of my /etc/rc.d/rc.inet1 file: > > insmod /usr/src/linux/drivers/net/8139too.o. install a later version of modutils, as the /lib/modules directory tree has changed between 2.2.x and 2.4.x - 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: Performance is weird (fwd)
I've attached a patch.
I tried to trigger the problem with my 10 MBit ne2k-pci connection, but
without success.
Could you try it?
I've tested it with -ac17, and it applies to 2.4.2 cleanly.
--
Manfred
--- 2.4/arch/i386/kernel/process.c Thu Feb 22 22:28:52 2001
+++ build-2.4/arch/i386/kernel/process.cThu Mar 15 20:35:12 2001
@@ -81,6 +81,11 @@
{
if (current_cpu_data.hlt_works_ok && !hlt_counter) {
__cli();
+ if (softirq_active(smp_processor_id()) &
+softirq_mask(smp_processor_id())) {
+ __sti();
+ do_softirq();
+ return;
+ }
if (!current->need_resched)
safe_halt();
else
Re: How to optimize routing performance
Jonathan Morton writes: > Nice. Any chance of similar functionality finding its' way outside the > Tulip driver, eg. to 3c509 or via-rhine? I'd find those useful, since one > or two of my Macs appear to be capable of generating pseudo-DoS levels of > traffic under certain circumstances which totally lock a 486 (for the > duration) and heavily load a P166 - even though said Macs "only" have > 10baseT Ethernet. I'm not the one to tell. :-) First its kind of experimental. Jamal has talked about putting together a proposal for enhancing RX-process for inclusion in the 2.5 kernels. There is meeting soon for this. But why not experiment a bit? Cheers. --ro - 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: Is swap == 2 * RAM a permanent thing?
The not reclaiming swap space is flawed in more than once instance. Suppose my P1 and P2 have their swap reserved -- now both grow. P3 is idle but can't fit in swap. This is going to result in fragmentation no? How is this fragmentation less worse than just freeing swap. Ever since Ram sizes got to about 256M, I've tended toward using swap spaces about half my RAM size -- thinking of swap as an 'overflow' place that really shouldn't get used much if at all. As you mention, not reclaiming swap space, but having 'double-reservations' for previously swapped programs becomes a problem fast in this situation. Makes the swap much less flexible. -- L A Walsh| Trust Technology, Core Linux, SGI [EMAIL PROTECTED] | Voice: (650) 933-5338 - 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.2.19 pre13 doesn't like retransmitted SYN ACK packets
On Thu, 15 Mar 2001, Zack Weinberg wrote: > 2.2.19 pre13 sends an RST in response to a retransmitted SYN ACK which > arrives after we've sent out the final ACK of the handshake. For > example: Ah, that would explain the extremely crappy network conectivity I observed with 2.2.19preX, X < 17 (15 and 16 were better, but not as good as 17 or 2.2.18). Please try 2.2.19pre17, it is handling itself just as well as 2.2.18 here. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - 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: How to optimize routing performance
> > Or are you saying that the bottleneck is somewhere > > else completely, > > Indeed. The bottleneck is with processing the incoming network > packets, at the interrupt level. Where is the counter for these dropped packets? If we run a few mbit of traffic through the box, we see noticeble percentages of lost packets (via stats from the Ixia traffic generator). But where in Linux are these counts stored? ifconfig does not appear to have the #. Cheers! Jon - 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/
ANNOUNCE: Journalling Flash File System, v2.
Well, it's been almost a week since the latest stupid bug was found in the JFFS2 code, so I suppose it's time to admit to the world that it exists. JFFS2, developed by Red Hat, is a complete reimplementation of a journalling filesystem for FLASH devices, based on the original JFFS from Axis Communications AB. Improvements of JFFS2 over the original JFFS include: - Improved wear levelling and garbage collection performance. - Compression - Improved RAM footprint and response to system memory pressure. - Improved concurrency and support for suspending flash erases - Support for hard links. You can get it from anonymous CVS: cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs login (password: anoncvs) cvs -d :pserver:[EMAIL PROTECTED]:/home/cvs co mtd The only platform currently supported is Linux 2.4. A port to eCos is likely to happen quite soon. JFFS2 filesystem images of the current 'Familiar' distribution for the Compaq iPAQ, along with appropriate kernels, are available at ftp://ftp.uk.linux.org/pub/people/dwmw2/familiar-0.3/ -- dwmw2 - 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: Is swap == 2 * RAM a permanent thing?
On Thu, 15 Mar 2001, LA Walsh wrote: > The not reclaiming swap space is flawed in more than once > instance. I want it fixed, but don't have much time for it now. Patches are welcome, though. regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - 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: How to optimize routing performance
On Thu, 15 Mar 2001, Robert Olsson wrote: > > > Jonathan Morton writes: > > > Nice. Any chance of similar functionality finding its' way outside the > > Tulip driver, eg. to 3c509 or via-rhine? I'd find those useful, since one > > or two of my Macs appear to be capable of generating pseudo-DoS levels of > > traffic under certain circumstances which totally lock a 486 (for the > > duration) and heavily load a P166 - even though said Macs "only" have > > 10baseT Ethernet. > > I'm not the one to tell. :-) > > First its kind of experimental. Jamal has talked about putting together > a proposal for enhancing RX-process for inclusion in the 2.5 kernels. > There is meeting soon for this. > > > But why not experiment a bit? I think one of the immediate things usable to drivers is to check the netif_rx() return value and yield the CPU if the system is congested. This is hardware independent. For the Tulip, since it knows how to do mitigation, it infact reduces it's interupt rate. An even simpler thing is to use HW_FLOW_CONTROL where you shutdown rx_interupt based on system congestion (and get worken up later when things get better). For 2.5 the plan is to work around any hardware dependencies. cheers, jamal - 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: State of RAID (and the infamous FastTrak100 card)
Jakob Østergaard wrote: > > So... am I just begging for pain if I try to install, say, a stock RH7 > > on a machine with the FastTrak100 doing it's little RAID0/JBOD thing? > > If it requires this machine to always boot from a floppy because the driver > > cannot be linked into the kernel, well, I'm okay with that. > > I don't know about the state of the FastTrak100 IDE drivers - but if you can > get that running, putting software RAID on top of that should be a simple > matter. I do not think that would work. These IDE RAID use a slightly different layout that someone would expect. This means that you cannot map it 1:1 to any RAID personality, therefore you cannot boot from it. (Free)BSD supports this IDE RAID controller with the RAID functionality. Maybe you want to check it out. I want to write a kernel module for 2.4 which supports the HPT370 RAID. You can be sure that I will peek at the FreeBSD code. In fact that is the only documentation I have. Wilfried - 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/
Linux Patch 2.4.2 for AVM A1 PCMCIA
Hello,
this patch includes the ISDN driver for AVM A1 PCMCIA from Carsten Paeth
into the linux kernel sources. Without the patch, it might be confusing
for a user to be able to select AVM A1 PCMCIA support for the kernel, but
it still doesn't work (because the PCMCIA part is missing).
Cheers,
Jochen
diff -u -r -N linux/drivers/isdn/Makefile linux-2.4.2/drivers/isdn/Makefile
--- linux/drivers/isdn/Makefile Fri Dec 29 23:40:54 2000
+++ linux-2.4.2/drivers/isdn/Makefile Sat Mar 10 15:55:59 2001
@@ -45,6 +45,15 @@
subdir-$(CONFIG_ISDN_DRV_EICON)+= eicon
subdir-$(CONFIG_HYSDN) += hysdn
+ifeq ($(CONFIG_PCMCIA),y)
+ subdir-y += pcmcia
+ subdir-m += pcmcia
+else
+ ifeq ($(CONFIG_PCMCIA),m)
+subdir-m += pcmcia
+ endif
+endif
+
obj-y += $(addsuffix /vmlinux-obj.o, $(subdir-y))
# The global Rules.make.
diff -u -r -N linux/drivers/isdn/pcmcia/Makefile
linux-2.4.2/drivers/isdn/pcmcia/Makefile
--- linux/drivers/isdn/pcmcia/Makefile Thu Jan 1 01:00:00 1970
+++ linux-2.4.2/drivers/isdn/pcmcia/MakefileSat Mar 10 15:55:30 2001
@@ -0,0 +1,20 @@
+#
+# Makefile for drivers/isdn/pcmcia
+#
+# Note! Dependencies are done automagically by 'make dep', which also
+# removes any old dependencies. DON'T put your own dependencies here
+# unless it's something special (ie not a .c file).
+#
+
+obj-y :=
+obj-n :=
+obj-m :=
+obj-:=
+
+ifeq ($(CONFIG_ISDN_DRV_HISAX),m)
+ ifeq ($(CONFIG_HISAX_AVM_A1_PCMCIA),y)
+obj-m += avma1_cs.o
+ endif
+endif
+
+include $(TOPDIR)/Rules.make
diff -u -r -N linux/drivers/isdn/pcmcia/avma1_cs.c
linux-2.4.2/drivers/isdn/pcmcia/avma1_cs.c
--- linux/drivers/isdn/pcmcia/avma1_cs.cThu Jan 1 01:00:00 1970
+++ linux-2.4.2/drivers/isdn/pcmcia/avma1_cs.c Sat Mar 10 15:55:30 2001
@@ -0,0 +1,541 @@
+/*==
+
+A PCMCIA client driver for AVM B1/M1/M2
+
+Written by Carsten Paeth, [EMAIL PROTECTED]
+
+==*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+int avm_a1_init_pcmcia(void *pcm_iob, int pcm_irq, int *busy_flag, int prot);
+void HiSax_closecard(int cardnr);
+
+
+/*
+ All the PCMCIA modules use PCMCIA_DEBUG to control debugging. If
+ you do not define PCMCIA_DEBUG at all, all the debug code will be
+ left out. If you compile with PCMCIA_DEBUG=0, the debug code will
+ be present but disabled -- but it can then be enabled for specific
+ modules at load time with a 'pc_debug=#' option to insmod.
+*/
+#ifdef PCMCIA_DEBUG
+static int pc_debug = PCMCIA_DEBUG;
+MODULE_PARM(pc_debug, "i");
+#define DEBUG(n, args...) if (pc_debug>(n)) printk(KERN_DEBUG args);
+static char *version =
+"avma1_cs.c 1.00 1998/01/23 10:00:00 (Carsten Paeth)";
+#else
+#define DEBUG(n, args...)
+#endif
+
+/**/
+
+/* Parameters that can be set with 'insmod' */
+
+static int default_irq_list[11] = { 15, 13, 12, 11, 10, 9, 7, 5, 4, 3, -1 };
+static int irq_list[11] = { -1 };
+static int isdnprot = 2;
+
+MODULE_PARM(irq_list, "1-11i");
+MODULE_PARM(isdnprot, "1-4");
+
+/**/
+
+/*
+ The event() function is this driver's Card Services event handler.
+ It will be called by Card Services when an appropriate card status
+ event is received. The config() and release() entry points are
+ used to configure or release a socket, in response to card insertion
+ and ejection events. They are invoked from the skeleton event
+ handler.
+*/
+
+static void avma1cs_config(dev_link_t *link);
+static void avma1cs_release(u_long arg);
+static int avma1cs_event(event_t event, int priority,
+ event_callback_args_t *args);
+
+/*
+ The attach() and detach() entry points are used to create and destroy
+ "instances" of the driver, where each instance represents everything
+ needed to manage one actual PCMCIA card.
+*/
+
+static dev_link_t *avma1cs_attach(void);
+static void avma1cs_detach(dev_link_t *);
+
+/*
+ The dev_info variable is the "key" that is used to match up this
+ device driver with appropriate cards, through the card configuration
+ database.
+*/
+
+static dev_info_t dev_info = "avma1_cs";
+
+/*
+ A linked list of "instances" of the skeleton device. Each actual
+ PCMCIA card corresponds to one device instance, and is described
+ by one dev_link_t structure (defined in ds.h).
+
+ You may not want to use a linked list for this -- for example, the
+ memory card driver uses an array of dev_link_t pointers, where minor
+ device numbers are used to derive the corresponding array ind
Re: State of RAID (and the infamous FastTrak100 card)
Wilfried Weissmann wrote: > > Jakob Østergaard wrote: > > > So... am I just begging for pain if I try to install, say, a stock RH7 > > > on a machine with the FastTrak100 doing it's little RAID0/JBOD thing? > > > If it requires this machine to always boot from a floppy because the driver > > > cannot be linked into the kernel, well, I'm okay with that. > > > > I don't know about the state of the FastTrak100 IDE drivers - but if you can > > get that running, putting software RAID on top of that should be a simple > > matter. > > I do not think that would work. These IDE RAID use a slightly different layout that >someone would > expect. This means that you cannot map it 1:1 to any RAID personality, therefore you >cannot boot > from it. > > (Free)BSD supports this IDE RAID controller with the RAID functionality. Maybe you >want to check it > out. Jakob ment the kernel software-RAID, md.0, raid0.o, raid1.o, raid5.o, and linear.o Not the Promise RAID software. -Thomas - 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: pivot_root & linuxrc problem
On Thu, 15 Mar 2001, Art Boulatov wrote: > How can I "exec /sbin/init" from "/linuxrc", whatever it is, > if "linuxrc" does not get PID=1? > > Actually, why does NOT "linuxrc" get PID=1? That's the question.. the first task started gets pid=1, and when that is true, exec /sbin/init has no problem. What else is your system starting?.. it must be starting something. -Mike - 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/
