RE: How to optimize routing performance
On Fri, 16 Mar 2001, Mårten Wikström wrote: [much text] > Thanks! I'll try that out. How can I tell if the driver supports > CONFIG_NET_HW_FLOWCONTROL? I'm not sure, but I think the cards are > tulip-based, can I then use Robert & Jamal's optimised drivers? > It'll probably take some time before I can do further testing. (My employer > thinks I've spent too much time on it already...). I don't really know how to tell except 'grep CONFIG_NET_HW_FLOWCONTROL driverfiles' You said that the cards where 100Mbit DEC cards, I assumed that by that you meant that the cards use DECchip 21143 or similar chips. If that's true you can use Robert & Jamal's optimised drivers. Sorry to hear that your employer doesn't see the importance in such a test :) > FYI, Linux had _much_ better delay variation characteristics than FreeBSD. > Typically no packet was delayed more than 100usec, whereas FreeBSD had some > packets delayed about 2-3 msec. This sounds promising. So Linux had nice variations until it broke down completely and stopped routing because of all the interrupts. I can almost guarantee that with the optimised driver and CONFIG_NET_HW_FLOWCONTROL you'll see a _big_ improvement in routingperformance. /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/
Re: Patch(2.4.2): serial.c timedia oneliner (Resend)
On Fri, Mar 16, 2001 at 09:47:14AM +0100, Gunther Mayer wrote: > I'm sending this since 3 months to the maintainer ([EMAIL PROTECTED]) > and even submitted to serial.sourceforge.net but never got a reaction. > Anybody knows if Ted is still active? Sorry, life's been a bit busy lately, what with the kernel workshop organization and other things chewing up huge amounts of my time. I'll try to get an updated serial driver with the various patches that I've received integrated together soon. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Patch(2.4.2): serial.c timedia oneliner (Resend)
Hi,
please apply this oneliner to fix the Timedia/Sunix series PCI cards.
Regards, Gunther
P.S.
I'm sending this since 3 months to the maintainer ([EMAIL PROTECTED])
and even submitted to serial.sourceforge.net but never got a reaction.
Anybody knows if Ted is still active?
--- linux/drivers/char/serial.c-242-origFri Mar 16 09:32:22 2001
+++ linux/drivers/char/serial.c Fri Mar 16 09:34:32 2001
@@ -4175,7 +4175,7 @@
for (i=0; timedia_data[i].num; i++) {
ids = timedia_data[i].ids;
for (j=0; ids[j]; j++) {
- if (pci_get_subvendor(dev) == ids[j]) {
+ if (pci_get_subdevice(dev) == ids[j]) {
board->num_ports = timedia_data[i].num;
return 0;
}
gmdiff-lx242-serialc-timedia-oneliner
Patch(2.4.2): isapnp detect fix (wrong checksum)
Hi,
this fix lets linux detect cards which don't
have a correct checksum.
These are probably common, it seems isapnptools _silently_
fixes this up !
Please apply if you like, comments welcome.
Regards, Gunther
--- linux/drivers/pnp/isapnp.c-2.4.2-orig Fri Mar 16 09:08:47 2001
+++ linux/drivers/pnp/isapnp.c Fri Mar 16 09:21:45 2001
@@ -993,10 +993,15 @@
header[4], header[5], header[6], header[7], header[8]);
printk("checksum = 0x%x\n", checksum);
#endif
- if (checksum == 0x00 || checksum != header[8]) /* not valid CSN */
+ /* Don't be strict on the checksum, here !
+ e.g. 'SCM SwapBox Plug and Play' has header[8]==0 (should be: b7)*/
+ if (header[8] == 0)
+ ;
+ else if (checksum == 0x00 || checksum != header[8]) /* not valid
+CSN */
continue;
if ((card = isapnp_alloc(sizeof(struct pci_bus))) == NULL)
continue;
+
card->number = csn;
card->vendor = (header[1] << 8) | header[0];
card->device = (header[3] << 8) | header[2];
gmdiff-242-isapnp-checksum-swapbox
Re: [CHECKER] 9 potential copy_*_user bugs in 2.4.1
> Looks like you've missed at least one place. Have you marked pointer > arguments of syscalls as tainted? Path in question looks so: In the exokernel param checker we do, but not for the one in linux --- most of the pointers seemed to be devices, so I never added it. Afer your for bug example, I'll go hack the checker ;-) > * if method's argument is ever tainted - all instances of that > method have that argument tainted. > > Is it possible to implement? The last rule may be tricky - we need to > remember that field foo of structure bar has tainted nth argument and > keep track of all functions assigned to foo, either by initialization > or by direct assignment. Could that be done? It should be. We're using a trick similar to this one to build up equivalence classes of interrupt handlers tracking which functions are assigned to struct fields, or passed as the same parameter to a function (request_irq being the prime example). You'd expect that if any function passed/assigned to a given function/field is an interrupt handler then the rest are too. The big win will be when checkers can get at global data structure initializers. From an outsiders view, it seems like most device methods are registered that way. Dawson Dawson - 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 and AMD-760MP I/O APIC
On Thu, Mar 15, 2001 at 05:34:18PM -0800, Johannes Erdfelt wrote: > The I/O APIC code for 2.2 contains a little trick which sets the destination > to 0 to disable an I/O APIC entry. This apparently trips up the I/O APIC > on AMD-760MP systems causing a lockup during boot. [snip] I'd love you test your patch! What does it take to become equipt with such a motherboard? - 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?
Hi David, David Wragg writes: +> [EMAIL PROTECTED] (Bob_Tracy) writes: +>> Unfortunately, when I execute +>> +>> 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. Indeed, it does. XFree 4 does create a region with the right size and even setting the mtrr manually works perfectly. Although only tested one evening, there were no 'no mtrr found for...' messages in the syslog anymore. Thankx a lot, /J"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
> > 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 Thanks! I'll try that out. How can I tell if the driver supports CONFIG_NET_HW_FLOWCONTROL? I'm not sure, but I think the cards are tulip-based, can I then use Robert & Jamal's optimised drivers? It'll probably take some time before I can do further testing. (My employer thinks I've spent too much time on it already...). FYI, Linux had _much_ better delay variation characteristics than FreeBSD. Typically no packet was delayed more than 100usec, whereas FreeBSD had some packets delayed about 2-3 msec. /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/
Re: [CHECKER] big stack variables
> [EMAIL PROTECTED] said: > > As usual, please report any false positives so we can fix our > > checkers. > > Not a false positive, but a false negative: > > the tty_struct locals at lines 1994 and 2029 in tty_register_devfs and > tty_unregister_devfs, respectively, in the 2.4.2 drivers/char/tty_io.c. Turns out we didn't have CONFIG_DEVFS_FS defined. Big time fun when it is: /u2/engler/mc/2.4.1/drivers/char/tty_io.c:1996:tty_register_devfs: ERROR:VAR:1996:1996: suspicious var 'tty' = 3112 bytes /u2/engler/mc/2.4.1/drivers/char/tty_io.c:2007:tty_register_devfs: ERROR:FN:2007:2007: function stack consumes = 3146 bytes /u2/engler/mc/2.4.1/drivers/char/tty_io.c:2031:tty_unregister_devfs: ERROR:VAR:2031:2031: suspicious var 'tty' = 3112 bytes /u2/engler/mc/2.4.1/drivers/char/tty_io.c:2042:tty_unregister_devfs: ERROR:FN:2042:2042: function stack consumes = 3148 bytes Right now we've just gone in and put =y for all options in .config --- is there a more principled approach that will get more coverage? > Nice work, BTW. Thanks! If you have any other ideas of things to check for, do let us know. We're mainly just going after things we've found in comments and code. We have about another 600 potential bugs to report, but are going over them to try to make sure they are reasonable. Dawson - 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: [CHECKER] 9 potential copy_*_user bugs in 2.4.1
Dawson Engler writes: > - > [UNKNOWN] I'm not sure about this: "csum_partial_*" calls the generic > cksum routine which does guard against user pointers --- > is this redundant paranoia in this case? > > /u2/engler/mc/oses/linux/2.4.1/net/ipv4/tcp_output.c:643:tcp_retrans_try_collapse: >ERROR:PARAM:651:643: tainted var 'skb_put' (from line 651) used as arg 0 to >'__constant_memcpy' csum_partial_copy_nocheck works on kernel pointers. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2 sparc64 patch for LVM
Patrick Caulfield writes: > The patch below fixes the ioctl32.c file so that LVM 0.9 will work > on UltraSPARC machines. I've added this patch to my tree, thanks. Later, David S. Miller [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: [OOPS] report
On Friday, March 16, 2001 01:03:20 AM -0500 Alexander Viro <[EMAIL PROTECTED]> wrote: >> Ok, I was more talking about the ugliness that is reiserfs_panic (how >> many times do we need a commented out for(;;)?). For panic() calling >> sys_sync, I think there non-filesystem related panics where we do want >> to sync. > > panic doesn't sync if called from interrupt (thanks $DEITY). > It is pointless to sync during boot. > sync from driver panic is not better than one from fs. > > What does it leave? I hadn't checked each panic(), but it seems that > if we ever want syncing upon panic() it's safer to do sys_sync() by > hands before calling panic(). If it is actually ever needed, that is. > > A quick grep -r shows over 700 panic callers (outside reiserfs). Most look like init messages, or things that generally happen during interrupts. But, I think there are too many to assume that nobody could benefit from a sync. Does that mean they _need_ the sync? Probably not. -chris - 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] report
On Fri, 16 Mar 2001, Chris Mason wrote: > > I suspect that the right fix is to drop the ->s_lock bogosity along with > > sys_sync() call in panic()... > > Ok, I was more talking about the ugliness that is reiserfs_panic (how many > times do we need a commented out for(;;)?). For panic() calling sys_sync, > I think there non-filesystem related panics where we do want to sync. panic doesn't sync if called from interrupt (thanks $DEITY). It is pointless to sync during boot. sync from driver panic is not better than one from fs. What does it leave? I hadn't checked each panic(), but it seems that if we ever want syncing upon panic() it's safer to do sys_sync() by hands before calling panic(). If it is actually ever needed, that is. - 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: [CHECKER] 9 potential copy_*_user bugs in 2.4.1
On Thu, Mar 15, 2001 at 06:24:51PM -0800, Dawson Engler wrote:
> Hi,
>
> I wrote an extension to gcc that does global analysis to determine
> which pointers in 2.4.1 are ever treated as user space pointers (i.e,
> passed to copy_*_user, verify_area, etc) and then makes sure they are
> always treated that way.
>
> It found what looks to be 9 errors, and 3 cases I'm not sure about.
> I've tried to eliminate false positives, but if any remain, please let
> me know.
> -
> [BUG] Looks like a bug where the memcpy forgets to use the user_buf pointer.
>
> /u2/engler/mc/oses/linux/2.4.1/drivers/usb/serial/digi_acceleport.c:1288:digi_write:
>ERROR:PARAM:1271:1288: tainted var 'buf' (from line 1271) used as arg 1 to
>'__constant_memcpy'
>
> /* copy user data (which can sleep) before getting spin lock */
> count = MIN( 64, MIN( count, port->bulk_out_size-2 ) );
> Start --->
> if( from_user && copy_from_user( user_buf, buf, count ) ) {
> return( -EFAULT );
> }
>
> /* be sure only one write proceeds at a time */
> /* there are races on the port private buffer */
> /* and races to check write_urb->status */
>
> /* wait for urb status clear to submit another urb */
> if( port->write_urb->status == -EINPROGRESS
> || priv->dp_write_urb_in_use ) {
>
> /* buffer data if count is 1 (probably put_char) if possible */
> if( count == 1 ) {
> new_len = MIN( count,
> DIGI_OUT_BUF_SIZE-priv->dp_out_buf_len );
> Error --->
> memcpy( priv->dp_out_buf+priv->dp_out_buf_len, buf,
> new_len );
> priv->dp_out_buf_len += new_len;
> } else {
> new_len = 0;
>
> -
Al, Pete, does this patch look good to fix this problem?
(I'll send a separate patch for the other usb-serial problems.)
thanks,
greg k-h
--
greg@(kroah|wirex).com
--- digi_acceleport.c.original Thu Mar 15 21:38:10 2001
+++ digi_acceleport.c Thu Mar 15 21:38:46 2001
@@ -1285,8 +1285,8 @@
if( count == 1 ) {
new_len = MIN( count,
DIGI_OUT_BUF_SIZE-priv->dp_out_buf_len );
- memcpy( priv->dp_out_buf+priv->dp_out_buf_len, buf,
- new_len );
+ memcpy( priv->dp_out_buf+priv->dp_out_buf_len,
+ from_user ? user_buf : buf, new_len );
priv->dp_out_buf_len += new_len;
} else {
new_len = 0;
Re: [OOPS] report
On Friday, March 16, 2001 12:32:56 AM -0500 Alexander Viro <[EMAIL PROTECTED]> wrote: > > > On Fri, 16 Mar 2001, Chris Mason wrote: > >> > ObReiserfs_panic: what the hell is that ->s_lock bit about? panic() >> > _never_ tries to do any block IO. It looks like a rudiment of something >> > that hadn't been there for 5 years, if not longer. The same goes for >> > ext2_panic() and ufs_panic(), BTW... I would suggest crapectomey here. >> >> Ugh, that should have been dragged out and shot...patch will come in the >> AM. >> > Unfortunately it's nastier than I thought. panic() does sys_sync(). And > IMO it really shouldn't. Notice that ->s_lock doesn't prevent > ->write_inode() and friends from being called. > > I suspect that the right fix is to drop the ->s_lock bogosity along with > sys_sync() call in panic()... Ok, I was more talking about the ugliness that is reiserfs_panic (how many times do we need a commented out for(;;)?). For panic() calling sys_sync, I think there non-filesystem related panics where we do want to sync. -chris - 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] report
On Thursday, March 15, 2001 09:44:48 PM -0500 Alexander Viro
<[EMAIL PROTECTED]> wrote:
>
>
> On Thu, 15 Mar 2001, David wrote:
>
>> 2.4.2-ac4
>>
>> Mar 15 18:02:49 Huntington-Beach kernel: end_request: I/O error, dev
>> 16:41 (hdd), sector 9512
>> Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
>> Mar 15 18:02:48 Huntington-Beach kernel: hdd: drive not ready for command
>> Mar 15 18:02:49 Huntington-Beach kernel: hdd: status error: status=0x00
>> { } Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for
>> command Mar 15 18:02:49 Huntington-Beach kernel: journal-601, buffer
>> write failed Mar 15 18:02:49 Huntington-Beach kernel: kernel BUG at
>> prints.c:332!
>
> Umm... Chris, I really don't think that panic() (or BUG(), for that
> matter) is an appropriate reaction to IO errors. They are expected
> events, after all...
>
Nods. It needs to force a readonly mount instead.
> ObReiserfs_panic: what the hell is that ->s_lock bit about? panic()
> _never_ tries to do any block IO. It looks like a rudiment of something
> that hadn't been there for 5 years, if not longer. The same goes for
> ext2_panic() and ufs_panic(), BTW... I would suggest crapectomey here.
Ugh, that should have been dragged out and shot...patch will come in the AM.
-chris
-
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] report
On Fri, 16 Mar 2001, Chris Mason wrote: > > ObReiserfs_panic: what the hell is that ->s_lock bit about? panic() > > _never_ tries to do any block IO. It looks like a rudiment of something > > that hadn't been there for 5 years, if not longer. The same goes for > > ext2_panic() and ufs_panic(), BTW... I would suggest crapectomey here. > > Ugh, that should have been dragged out and shot...patch will come in the AM. > Unfortunately it's nastier than I thought. panic() does sys_sync(). And IMO it really shouldn't. Notice that ->s_lock doesn't prevent ->write_inode() and friends from being called. I suspect that the right fix is to drop the ->s_lock bogosity along with sys_sync() call in panic()... - 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 paging oops on massive vfs activity
On Wed, 14 Mar 2001, Donald J. Barry wrote: > Hey kernel developers, > > I'm getting repeated oopses and occasional freezes on a server I've > set up to host a giant (180G) reiserfs system atop lvm, served by nfs(v2). > (I've applied the reiserfs and nfs patches to the vanilla kernel, > which is otherwise pretty minimally compiled). They seem to be > correlated by massive disk activity. Because this file system has > many huge directories (2+ files in some) and also many long names > (some of those giant directories are filled with 40+ character > filenames) I'm beginning to wonder whether the vfs layer is at fault. > I got some of the same behavior with an earlier ext2 instance atop > lvm. In this case I triggered the result by doing a find atop the > tree. Generally things that access many directory entries trigger it. > > Of course, it could be a remaining hardware glitch on this new tbird > 1100 system on GA59X motherboard (latest firmware, but it has the > troublesome VIA kt133 chipset). > > What use is a server when it oopses when trying to serve? > > Any thoughts? Seems to be inode hash list corruption. Maybe bad memory. Can you use the "memtest86" utility to check if your memory is OK? (you can find it at www.freshmeat.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: Oops 0000 and 0002 on dual PIII 750 2.4.2 SMP platform
On Thu, 15 Mar 2001, Shane Y. Gibson wrote:
> Marcelo Tosatti wrote:
> >
> > Did'nt you get a message similar to
> >
> > "kernel BUG at page_alloc.c line xxx!"
>
> Marcelo,
>
> Yes there was. I'm pasting the total sum of the /var/log/messages
> output. Note that I'm only able to locate details for the first
> crash, the second didn't seem to log a whole lot. Originally,
> just pasted the output of what "ksymops" regurgitated, which seems
> to have pulled out that "kernel BUG" reference. Here goes...
Can you please try to reproduce it with the following patch against 2.4.2?
With the patch applied it gets easier to find the problem.
Thanks
--- linux/include/linux/swap.h.orig Fri Mar 16 06:31:51 2001
+++ linux/include/linux/swap.h Fri Mar 16 06:33:41 2001
@@ -201,7 +201,15 @@
*/
#define DEBUG_ADD_PAGE \
if (PageActive(page) || PageInactiveDirty(page) || \
- PageInactiveClean(page)) BUG();
+ PageInactiveClean(page)) { \
+ if (PageActive(page)) \
+ printk (KERN_ERR "Active page on free list!\n"); \
+ if (PageInactiveDirty(page)) \
+ printk (KERN_ERR "Inactive dirty page on free list!\n"); \
+ if (PageInactiveClean(page)) \
+ printk (KERN_ERR "Inactive clean page on free list!\n"); \
+ BUG(); \
+ }
#define ZERO_PAGE_BUG \
if (page_count(page) == 0) BUG();
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Oops 0000 and 0002 on dual PIII 750 2.4.2 SMP platform
"Shane Y. Gibson" wrote: > > 2.4.2 ... > dual PIII 750s ... > panicing, and freezing up. Try using the `nmi_watchdog=0' LILO option. - 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: [CHECKER] 9 potential copy_*_user bugs in 2.4.1
On Thu, 15 Mar 2001, Dawson Engler wrote: > Hi, > > I wrote an extension to gcc that does global analysis to determine > which pointers in 2.4.1 are ever treated as user space pointers (i.e, > passed to copy_*_user, verify_area, etc) and then makes sure they are > always treated that way. > > It found what looks to be 9 errors, and 3 cases I'm not sure about. > I've tried to eliminate false positives, but if any remain, please let > me know. Looks like you've missed at least one place. Have you marked pointer arguments of syscalls as tainted? Path in question looks so: * 2nd argument of sys_write() (buf) is tainted [SYSCALL] * sys_write() passes buf as 2nd argument to file_operations::write() (fs/read_write.c:159-160) * proc_file_write() is an instance of the above (buffer is the 2nd argument) (fs/proc/generic.c:36--40) * proc_file_write() passes buffer as 2nd argument to proc_dir_entry::write_proc() (fs/proc/generic.c:136) * proc_write_register() is an instance of the above (buffer is the 2nd argument) (fs/binfmt_misc.c:494) * proc_write_register() directly dereferences buffer. (fs/binfmt_misc.c:298) (line numbers as per 2.4.2, 2.4.1 is essentially the same) And yes, that's an oopsable bug (fixed in more or less recent -ac). Since a lot of code is only accessed as methods... If you could add support for that kind of checks you'd probably find much more. Relevant rules: * all arguments of syscalls are tainted. Casting can't change that. * verify_area() cleans the value, but you'll be better off considering these as dangerous - it only checks that range is OK and if pointer arithmetics moves you out of that range or you access piece longer than range in question... * if method's argument is ever tainted - all instances of that method have that argument tainted. Is it possible to implement? The last rule may be tricky - we need to remember that field foo of structure bar has tainted nth argument and keep track of all functions assigned to foo, either by initialization or by direct assignment. Could that be done? Cheers, Al - 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: [CHECKER] big stack variables
Jeff Dike wrote: > > [EMAIL PROTECTED] said: > > As usual, please report any false positives so we can fix our > > checkers. > > Not a false positive, but a false negative: > > the tty_struct locals at lines 1994 and 2029 in tty_register_devfs and > tty_unregister_devfs, respectively, in the 2.4.2 drivers/char/tty_io.c. and sanitize_e820_map() > Nice work, BTW. Yep. - - 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: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
In article <[EMAIL PROTECTED]> you wrote: > The real problem is that our disks usually do not have a volume label. > Outside of all file systems. > The "signatures" that we rely on today are located in different places, > so that a filesystem can have several valid signatures at the same time. > And we first know where to look when we know the type already. > > Design a Linux partition table format, where a partition descriptor > has fields start, end, fstype, fslabel, and the whole disk has a vollabel. > Put it in sector 0-N for an all-Linux disk, and in sectors pointed at > by a classical DOS-type partition table entry when the disk is shared. I don't understand that. Do you propose something like *BSD or Solaris disklabels? In that case a whole new set of user utilities would be needed to create your new tables as well as maintaining the old style partition tables. The process of copying or moving fs around disks seems to be quite common as tools like partition magic or parted suggest. Your idea would make that process more difficult and less user-friendly. It should imho always be simple to backup an fs to tape from a dying disk and restore it to a new one without losing the label etc. Perhaps putting this kind of information into a generalized start sector for all Linux fs would be a better idea (is that what you meant?). Copying an fs would again be as easy as using dd or cp. Of course this means that most Linux fs types including swap partitions should leave this start sector alone. A common mkfs would create that leading block after the mkfs. successfully created the fs meta-contents. It would be optimal imho if the partition table entry contains the start sector and size only, and all other information like type, uuid, label etc. is within the fs disk space. No out-of-band fs information anymore. The disk volume label should be located outside all fs as you mentioned but separated from the actual fs labels. -- Michail Brzitwa <[EMAIL PROTECTED]>+49-511-343215 - 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: [CHECKER] big stack variables
[EMAIL PROTECTED] said: > As usual, please report any false positives so we can fix our > checkers. Not a false positive, but a false negative: the tty_struct locals at lines 1994 and 2029 in tty_register_devfs and tty_unregister_devfs, respectively, in the 2.4.2 drivers/char/tty_io.c. Nice work, BTW. Jeff - 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 benchmark
Hi,
I use kernprof+gprof to measure the 2.2.16 kernel,
but the scale is mini-second.
So I use do_gettimeofday( ) kernel function call to measure
the latency. (This function support micro-second scale.)
Moreover, I use SmartBits packet generator to generate
the specific network traffic load. The environment is
as follows. However, the result are very funny. I think
that latency should increase progressively when load
increase, but the result are unable explaining.
Could you give me some hint? Thanks a lot.
1518byte packet
loadlatency(us)
1%13.1284
10%14.1629
20%12.6558
30%11.1056
40%10.7510
50%10.4148
60%10.3337
70%10.1038
80%10.1103
90%10.3634
100%11.2367
64byte packet
loadlatency(us)
1%3.6767
10%2.7696
20%4.3926
30%2.8135
40%8.2552
50%5.3088
60%9.3744
70%23.6247
80%8.5351
90%9.7217
100%13.065
Benchmark Environment:
+---smartbits<---+
| |
+>Linux-+
* The do_gettimeofday function call is as follows:
--
do_gettimeofday();
...
(kernel do something)
...
do_gettimeofday();
if (end.tv_usec < begin.tv_usec) {
end.tv_usec += 100; end.tv_sec--;
}
end.tv_sedc -= begin.tv_sec;
end.tv_usec -= begin.tv_usec;
return ((end.tv_sec*100) + end.tv_usec);
-
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) -> results
On Thu, 15 Mar 2001, Manfred Spraul wrote: > 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. On 2.4.2: Before: ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013 atm -> 0.90 ttcp-t: socket ttcp-t: 16777216 bytes in 3.829257 real seconds = 4278.636822 KB/sec (35.050593 Mb/sec) After either of your patches, the result was the same, sorry. I tried to apply the patch to 2.4.3 and still got the better result with it, altought compiling kernel still improved the performance. First: [root@ropogw 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 1.994121 real seconds = 8216.151377 KB/sec (67.306712 Mb/sec) [root@ropogw 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 1.995773 real seconds = 8209.350462 KB/sec (67.250999 Mb/sec) [root@ropogw 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 1.989680 real seconds = 8234.489968 KB/sec (67.456942 Mb/sec) (start to compile kernel on other console) [root@ropogw 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 1.072744 real seconds = 15272.982184 KB/sec (125.116270 Mb/sec) [root@ropogw 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 1.140261 real seconds = 14368.640162 KB/sec (117.70790 I also applied it the test to the 3com card: Before kernel compiling, patch applied or not: ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013 udp -> not.for.your.eyes ttcp-t: socket ttcp-t: 16777216 bytes in 2.218013 real seconds = 7386.791691 KB/sec (60.512598 Mb/sec) ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5013 udp -> not.for.your.eyes ttcp-t: socket ttcp-t: 16777216 bytes in 1.428264 real seconds = 11471.268617 KB/sec (93.972633 Mb/sec) Thanks, Sampsa Ranta [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: [OOPS] report
On Thu, 15 Mar 2001, David wrote:
> 2.4.2-ac4
>
> Mar 15 18:02:49 Huntington-Beach kernel: end_request: I/O error, dev
> 16:41 (hdd), sector 9512
> Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
> Mar 15 18:02:48 Huntington-Beach kernel: hdd: drive not ready for command
> Mar 15 18:02:49 Huntington-Beach kernel: hdd: status error: status=0x00 { }
> Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
> Mar 15 18:02:49 Huntington-Beach kernel: journal-601, buffer write failed
> Mar 15 18:02:49 Huntington-Beach kernel: kernel BUG at prints.c:332!
Umm... Chris, I really don't think that panic() (or BUG(), for that matter)
is an appropriate reaction to IO errors. They are expected events, after
all...
ObReiserfs_panic: what the hell is that ->s_lock bit about? panic() _never_
tries to do any block IO. It looks like a rudiment of something that hadn't
been there for 5 years, if not longer. The same goes for ext2_panic() and
ufs_panic(), BTW... I would suggest crapectomey here.
Cheers,
Al
-
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/
Reserved memory for highmem bouncing (fwd)
Ingo, Any comments? -- Forwarded message -- Date: Wed, 28 Feb 2001 02:02:16 -0300 (BRT) From: Marcelo Tosatti <[EMAIL PROTECTED]> To: Ingo Molnar <[EMAIL PROTECTED]> Cc: lkml <[EMAIL PROTECTED]> Subject: Reserved memory for highmem bouncing Hi Ingo, I have a question about the highmem page IO deadlock fix which is in 2.4.2-ac. (the emergency memory thing) The old create_bounce code used to set PF_MEMALLOC on the task flags and call wakeup_bdflush(1) in case GFP_BUFFER page allocation failed. That was broken because flush_dirty_buffers() could try to flush a buffer pointing to highmem page, which would end up in create_bounce again, but with PF_MEMALLOC. Have you tried to make flush_dirty_buffers() only flush buffers pointing to lowmem pages in case the caller wants it to do so? This way you can call flush_dirty_buffers() with the guarantee you're going to free useful (lowmem) memory. This also throttles high mem writes giving priority to low mem ones. - 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/
[CHECKER] big stack variables
Hi, enclosed are 22 functions in 2.4.1 that appear to allocate stack variables >= 1024 bytes. As usual, please report any false positives so we can fix our checkers. Dawson --- /u2/engler/mc/2.4.1/drivers/isdn/sc/message.c:52:dump_messages: ERROR:VAR: suspicious sized variable: 'dpm' = 4112 bytes /u2/engler/mc/2.4.1/drivers/sound/emu10k1/audio.c:906:emu10k1_audio_ioctl: ERROR:VAR: suspicious sized variable: 'buf' = 4016 bytes /u2/engler/mc/2.4.1/drivers/i2o/i2o_proc.c:955:i2o_proc_read_drivers_stored: ERROR:VAR: suspicious sized variable: 'result' = 3596 bytes /u2/engler/mc/2.4.1/drivers/scsi/qlogicfc.c:861:isp2x00_make_portdb: ERROR:VAR: suspicious sized variable: 'temp' = 3072 bytes /u2/engler/mc/2.4.1/drivers/i2o/i2o_proc.c:840:i2o_proc_read_ddm_table: ERROR:VAR: suspicious sized variable: 'result' = 2828 bytes /u2/engler/mc/2.4.1/drivers/cdrom/optcd.c:1625:cdromread: ERROR:VAR: suspicious sized variable: 'buf' = 2646 bytes /u2/engler/mc/2.4.1/drivers/i2o/i2o_proc.c:2261:i2o_proc_read_lan_mcast_addr: ERROR:VAR: suspicious sized variable: 'result' = 2060 bytes /u2/engler/mc/2.4.1/drivers/i2o/i2o_proc.c:2492:i2o_proc_read_lan_alt_addr: ERROR:VAR: suspicious sized variable: 'result' = 2060 bytes /u2/engler/mc/2.4.1/drivers/i2o/i2o_proc.c:1044:i2o_proc_read_groups: ERROR:VAR: suspicious sized variable: 'result' = 2060 bytes /u2/engler/mc/2.4.1/fs/ntfs/super.c:335:ntfs_get_free_cluster_count: ERROR:VAR: suspicious sized variable: 'bits' = 2048 bytes /u2/engler/mc/2.4.1/drivers/atm/iphase.c:2760:ia_ioctl: ERROR:VAR: suspicious sized variable: 'regs_local' = 2048 bytes /u2/engler/mc/2.4.1/drivers/block/cpqarray.c:1156:ida_ioctl: ERROR:VAR: suspicious sized variable: 'my_io' = 1296 bytes /u2/engler/mc/2.4.1/net/wanrouter/wanmain.c:578:device_new_if: ERROR:VAR: suspicious sized variable: 'conf' = 1220 bytes /u2/engler/mc/2.4.1/drivers/net/zlib.c:4216:huft_build: ERROR:VAR: suspicious sized variable: 'v' = 1152 bytes /u2/engler/mc/2.4.1/drivers/net/zlib.c:4501:inflate_trees_fixed: ERROR:VAR: suspicious sized variable: 'c' = 1152 bytes /u2/engler/mc/2.4.1/drivers/cdrom/cdrom.c:734:cdrom_slot_status: ERROR:VAR: suspicious sized variable: 'info' = 1032 bytes /u2/engler/mc/2.4.1/drivers/cdrom/cdrom.c:800:cdrom_select_disc: ERROR:VAR: suspicious sized variable: 'info' = 1032 bytes /u2/engler/mc/2.4.1/drivers/cdrom/cdrom.c:758:cdrom_number_of_slots: ERROR:VAR: suspicious sized variable: 'info' = 1032 bytes /u2/engler/mc/2.4.1/drivers/cdrom/cdrom.c:1538:cdrom_ioctl: ERROR:VAR: suspicious sized variable: 'info' = 1032 bytes /u2/engler/mc/2.4.1/fs/nfs/nfsroot.c:238:root_nfs_name: ERROR:VAR: suspicious sized variable: 'buf' = 1024 bytes /u2/engler/mc/2.4.1/net/bridge/br_ioctl.c:86:br_ioctl_device: ERROR:VAR: suspicious sized variable: 'indices' = 1024 bytes /u2/engler/mc/2.4.1/drivers/isdn/pcbit/drv.c:444:pcbit_writecmd: ERROR:VAR: suspicious sized variable: 'cbuf' = 1024 bytes - 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/
[CHECKER] 9 potential copy_*_user bugs in 2.4.1
Hi,
I wrote an extension to gcc that does global analysis to determine
which pointers in 2.4.1 are ever treated as user space pointers (i.e,
passed to copy_*_user, verify_area, etc) and then makes sure they are
always treated that way.
It found what looks to be 9 errors, and 3 cases I'm not sure about.
I've tried to eliminate false positives, but if any remain, please let
me know.
Two questions:
1. if a verify_area is done to a pointer, can the pointer then
be manipulated raw? E.g., is this ok?
if(!verify_area(VERIFY_READ, p, sizeof *p)))
tmp = *p;
2. And, unrelated: given the current locking discipline, is
it bad to hold any type of lock (not just a spin lock) when you
call a potentially blocking function? (It at least seems bad
for performance, since you'll hold the lock for milliseconds.)
Dawson
-
[BUG] sends 'rt' as the user pointer to copy_to_user, but ipddp_find_route
derferences it directly.
ipddp_find derefs this struct.
struct at_addr
{
__u16 s_net;
__u8s_node;
};
/u2/engler/mc/oses/linux/2.4.1/drivers/net/appletalk/ipddp.c:274:ipddp_ioctl:
ERROR:PARAM:277:274: tainted var 'rt' (from line 277) used as arg 0 to 'ipddp_create'
{
case SIOCADDIPDDPRT:
Error --->
return (ipddp_create(rt));
case SIOCFINDIPDDPRT:
Start --->
if(copy_to_user(rt, ipddp_find_route(rt), sizeof(struct
ipddp_route)))
return -EFAULT;
-
[BUG] sends 'rt' as the user pointer to copy_to_user, but ipddp_find_route
derferences it directly.
/u2/engler/mc/oses/linux/2.4.1/drivers/net/appletalk/ipddp.c:277:ipddp_ioctl:
ERROR:PARAM:277:277: tainted var 'rt' (from line 277) used as arg 0 to
'ipddp_find_route'
case SIOCFINDIPDDPRT:
Start --->
Error --->
if(copy_to_user(rt, ipddp_find_route(rt), sizeof(struct
ipddp_route)))
return -EFAULT;
-
[BUG] sends 'rt' as the user pointer to copy_to_user, but ipddp_find_route
derferences it directly.
/u2/engler/mc/oses/linux/2.4.1/drivers/net/appletalk/ipddp.c:282:ipddp_ioctl:
ERROR:PARAM:277:282: tainted var 'rt' (from line 277) used as arg 0 to 'ipddp_delete'
case SIOCFINDIPDDPRT:
Start --->
if(copy_to_user(rt, ipddp_find_route(rt), sizeof(struct
ipddp_route)))
return -EFAULT;
return 0;
case SIOCDELIPDDPRT:
Error --->
return (ipddp_delete(rt));
-
[BUG] copy_to_user taints "arg" on one switch branch, but
capabilities check derefs it w/o checks on another
/u2/engler/mc/oses/linux/2.4.1/drivers/telephony/ixj.c:5046:ixj_ioctl:
ERROR:PARAM:4687:5046: tainted var 'arg' (from line 4687) used as arg 1 to
'capabilities_check'
break;
case IXJCTL_VERSION:
Start --->
if (copy_to_user((char *) arg, ixj_c_revision, strlen(ixj_c_revision)))
return -EFAULT;
break;
case PHONE_RING_CADENCE:
j->ring_cadence = arg;
break;
case IXJCTL_CIDCW:
... DELETED 345 lines ...
case PHONE_CAPABILITIES:
retval = j->caps;
break;
case PHONE_CAPABILITIES_LIST:
if (copy_to_user((char *) arg, j->caplist, sizeof(struct
phone_capability) * j->caps))
return -EFAULT;
break;
case PHONE_CAPABILITIES_CHECK:
Error --->
retval = capabilities_check(board, (struct phone_capability *) arg);
break;
case PHONE_PSTN_SET_STATE:
daa_set_mode(board, arg);
break;
static int capabilities_check(int board, struct phone_capability *pcreq)
{
int cnt;
IXJ *j = [board];
int retval = 0;
for (cnt = 0; cnt < j->caps; cnt++) {
if (pcreq->captype == j->caplist[cnt].captype
&& pcreq->cap == j->caplist[cnt].cap) {
retval = 1;
break;
}
}
return retval;
}
-
[BUG] Looks like a bug where the memcpy forgets to use the user_buf pointer.
/u2/engler/mc/oses/linux/2.4.1/drivers/usb/serial/digi_acceleport.c:1288:digi_write:
ERROR:PARAM:1271:1288: tainted var 'buf' (from line 1271) used as arg 1 to
'__constant_memcpy'
/* copy user data (which can sleep) before getting spin lock */
[OOPS] report
2.4.2-ac4
Mar 15 18:02:49 Huntington-Beach kernel: end_request: I/O error, dev
16:41 (hdd), sector 9512
Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
Mar 15 18:02:48 Huntington-Beach kernel: hdd: drive not ready for command
Mar 15 18:02:49 Huntington-Beach kernel: hdd: status error: status=0x00 { }
Mar 15 18:02:49 Huntington-Beach kernel: hdd: drive not ready for command
Mar 15 18:02:49 Huntington-Beach kernel: journal-601, buffer write failed
Mar 15 18:02:49 Huntington-Beach kernel: kernel BUG at prints.c:332!
Mar 15 18:02:49 Huntington-Beach kernel: invalid operand:
Mar 15 18:02:49 Huntington-Beach kernel: CPU:0
Mar 15 18:02:49 Huntington-Beach kernel: EIP:
0010:[reiserfs_panic+357/440]
Mar 15 18:02:49 Huntington-Beach kernel: EFLAGS: 00010282
Mar 15 18:02:49 Huntington-Beach kernel: eax: 001c ebx: c0420e40
ecx: cf19 edx: c03a4008
Mar 15 18:02:49 Huntington-Beach kernel: esi: c39a5ecc edi: c39a5ebc
ebp: esp: c39a5e90
Mar 15 18:02:49 Huntington-Beach kernel: ds: 0018 es: 0018 ss: 0018
Mar 15 18:02:49 Huntington-Beach kernel: Process sync (pid: 30559,
stackpage=c39a5000)
Mar 15 18:02:49 Huntington-Beach kernel: Stack: c031a785 c031aa74
014c d1526154 0002 cfeb0c00 c0421240
Mar 15 18:02:49 Huntington-Beach kernel:c39a5ebc c39a5eb8
c39a4000 c0193a6f cfeb0c00 c031cd20 0002
Mar 15 18:02:49 Huntington-Beach kernel:0012 0010
d1526188 d152617c 0003 0003
Mar 15 18:02:49 Huntington-Beach kernel: Call Trace: []
[flush_commit_list+659/908] [] []
[do_journal_end+1935/2652] [] []
Mar 15 18:02:50 Huntington-Beach kernel:
[flush_old_commits+391/420] [reiserfs_write_super+21/32]
[sync_supers+118/172] [fsync_dev+23/48] [sys_sync+7/16] [system_call+51/56]
Mar 15 18:02:50 Huntington-Beach kernel:
Mar 15 18:02:50 Huntington-Beach kernel: Code: 0f 0b 83 c4 0c 83 7c 24
28 00 74 17 8b 7c 24 28 80 7f 11 00
-
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: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
Andries writes: > > I've implemented a patch for util-linux-2.11a > > which adds LABEL support to mkswap(8) and swapon/swapoff(8). > > But I would prefer a somewhat more ambitious approach. > > My first thought was: why label individual swap partitions? > I almost never want to distinguish swap partitions, and just do > "swapon -a". In case one wants to guard against changing device names, > why not add an option -A so that "swapon -A" does swapon on each > partition with a swap signature? > > However, that would greatly increase the risk that exists already > today: someone has a swap partition, and does mkfs.foo, and > it so happens that foofs does not use the sector with the swapsignature. > Now this foofs partition has a swap signature, but we would be very > unhappy if it were used as swap space. I think the LABEL is a good intermediate step for people not using LVM. It basically allows your /etc/fstab to not have _any_ device names in it. I'm not sure I would be happy with auto-mounting swap partitions, especially because this would overwrite any data in the partition. Bad. > The real problem is that our disks usually do not have a volume label. > Outside of all file systems. > The "signatures" that we rely on today are located in different places, > so that a filesystem can have several valid signatures at the same time. > And we first know where to look when we know the type already. > > Design a Linux partition table format, where a partition descriptor > has fields start, end, fstype, fslabel, and the whole disk has a vollabel. > Put it in sector 0-N for an all-Linux disk, and in sectors pointed at > by a classical DOS-type partition table entry when the disk is shared. > > (Maybe I already did that once - it sounds so familiar now that I write > this. Then why was it not pursued? Maybe LVM already does these things?) LVM will handle the disk and "partition" naming and size issues. It does NOT currently handle the fstype names, but this _could_ be determined via magic numbers, as now. In the "(struct dentry *)->vfsmnt" thread, I was trying to work out a way to get mountpoint information for LVM. In the end, I think I will store most of the /etc/fstab line into a field in the LV header, so it is easily retrievable. This would also include the fstype, and mount/dump/fsck options. It would _not_ store the device name. The proposed solution would be to have mount(8) write the mount info to the disk (for logical volumes only, of course) at mount time. I suppose the fs type, options, mountpoint could come from either /etc/fstab or from the command-line, since mount(8) is already parsing all of this info. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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 and AMD-760MP I/O APIC
The I/O APIC code for 2.2 contains a little trick which sets the destination
to 0 to disable an I/O APIC entry. This apparently trips up the I/O APIC
on AMD-760MP systems causing a lockup during boot.
This patch removes that trick in favor of doing what 2.4 does, masking out
the entries.
This patch is relative to 2.2.18, but should apply cleanly to 2.2.19-pre
since -pre17 doesn't touch this code at all.
JE
--- linux-2.2.18.orig/arch/i386/kernel/io_apic.cMon Sep 4 13:39:16 2000
+++ linux-2.2.18/arch/i386/kernel/io_apic.c Thu Mar 15 17:23:46 2001
@@ -200,8 +200,6 @@
* We disable IO-APIC IRQs by setting their 'destination CPU mask' to
* zero. Trick by Ramesh Nalluri.
*/
-DO_ACTION( disable, 1, &= 0x00ff, io_apic_sync(entry->apic))/* destination = 0x00
*/
-DO_ACTION( enable, 1, |= 0xff00, )/* destination
= 0xff */
DO_ACTION( mask,0, |= 0x0001, io_apic_sync(entry->apic))/* mask = 1 */
DO_ACTION( unmask, 0, &= 0xfffe, )/* mask = 0 */
@@ -612,7 +610,7 @@
entry.delivery_mode = dest_LowestPrio;
entry.dest_mode = 1;/* logical delivery */
entry.mask = 0; /* enable IRQ */
- entry.dest.logical.logical_dest = 0;/* but no route */
+ entry.dest.logical.logical_dest = 0xff; /* but no route */
idx = find_irq_entry(apic,pin,mp_INT);
if (idx == -1) {
@@ -1017,13 +1015,10 @@
static void enable_edge_ioapic_irq(unsigned int irq)
{
self_IPI(irq);
- enable_IO_APIC_irq(irq);
+ unmask_IO_APIC_irq(irq);
}
-static void disable_edge_ioapic_irq(unsigned int irq)
-{
- disable_IO_APIC_irq(irq);
-}
+static void disable_edge_ioapic_irq(unsigned int irq) { /* nothing */ }
/*
* Starting up a edge-triggered IO-APIC interrupt is
@@ -1239,7 +1234,7 @@
pin1 = find_timer_pin(mp_INT);
pin2 = find_timer_pin(mp_ExtINT);
- enable_IO_APIC_irq(0);
+ unmask_IO_APIC_irq(0);
if (!timer_irq_works()) {
if (pin1 != -1)
-
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.4.3-pre3 and further ate PCMCIA serial cardbus support
In fact this -pre4 works only after reverting the changes to Config.in, Makefile and serial_cb.c in drivers/char/pcmcia, otherwise my Xircom modem wouldn't be seen (tulip Ethernet is okay). -pre2 is fine. So - was there any announcement about something like serial_cs engulfing serial_cb or is it just a bad patch that slipped in ? Thanks & ciao, --alessandro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Linux: kernel 2.2.19p16/2.4.3p4 glibc-2.2 gcc-2.96-69 binutils-2.10.91.0.4 Oracle: Oracle8i 8.1.7.0.1 Enterprise Edition for Linux motto: Tell the truth, there's less to remember. - 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: [util-linux] Re: magic device renumbering was -- Re: Linux2.4.2ac20
On Fri, 16 Mar 2001 [EMAIL PROTECTED] wrote: > Design a Linux partition table format, where a partition descriptor > has fields start, end, fstype, fslabel, and the whole disk has a vollabel. > Put it in sector 0-N for an all-Linux disk, and in sectors pointed at > by a classical DOS-type partition table entry when the disk is shared. Yes, but for $DEITY sake, let's make it text. Something along the lines of Linux partition table\n(START,LENGTH,TYPE(,LABEL)?n)*End\0 START: NUMBER LENGTH: NUMBER TYPE: [^,\n\0]+ LABEL: [^\n\0]+ NUMBER: Will make life much simpler when one needs to recover the bloody thing... - 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 0000 and 0002 on dual PIII 750 2.4.2 SMP platform
Marcelo Tosatti wrote: > > Did'nt you get a message similar to > > "kernel BUG at page_alloc.c line xxx!" Marcelo, Yes there was. I'm pasting the total sum of the /var/log/messages output. Note that I'm only able to locate details for the first crash, the second didn't seem to log a whole lot. Originally, just pasted the output of what "ksymops" regurgitated, which seems to have pulled out that "kernel BUG" reference. Here goes... v/r Shane Mar 14 22:05:12 walker kernel: kernel BUG at page_alloc.c:203! Mar 14 22:05:12 walker kernel: invalid operand: Mar 14 22:05:12 walker kernel: CPU:0 Mar 14 22:05:12 walker kernel: EIP:0010:[rmqueue+581/640] Mar 14 22:05:12 walker kernel: EFLAGS: 00010286 Mar 14 22:05:12 walker kernel: eax: 0020 ebx: c1537448 ecx: 0002 edx: 0200 Mar 14 22:05:12 walker kernel: esi: 0001efe0 edi: c110 ebp: 0001efe0 esp: c28e3e2c Mar 14 22:05:12 walker kernel: ds: 0018 es: 0018 ss: 0018 Mar 14 22:05:12 walker kernel: Process indexmaker (pid: 24392, stackpage=c28e3000) Mar 14 22:05:12 walker kernel: Stack: c024deeb c024e099 00cb 00012a2e 0282 c029dff8 c029dff8 Mar 14 22:05:12 walker kernel:c029e1d0 c029e1cc c012e664 0005 0001 cc187220 c19cde40 Mar 14 22:05:12 walker kernel:0025 c7c85bac c0123a32 cc187220 c19cde40 0001 c0123ab0 c19cde40 Mar 14 22:05:12 walker kernel: Call Trace: [__alloc_pages+228/720] [do_anonymous_page+50/128] [do_no_page+48/160] [handle_mm_fault+276/400] [do_page_fault+349/1088] [file_read_actor+0/96] [do_brk+186/368] Mar 14 22:05:12 walker kernel:[sys_brk+181/224] [do_page_fault+0/1088] [error_code+52/60] Mar 14 22:05:12 walker kernel: Mar 14 22:05:12 walker kernel: Code: 0f 0b 83 c4 0c 89 d8 eb 1d 89 f6 47 83 c6 0c 83 ff 09 0f 86 Mar 14 22:05:25 walker kernel: Unable to handle kernel NULL pointer dereference at virtual address 0051 Mar 14 22:05:25 walker kernel: printing eip: Mar 14 22:05:25 walker kernel: c013f010 Mar 14 22:05:25 walker kernel: *pde = Mar 14 22:05:25 walker kernel: Oops: Mar 14 22:05:25 walker kernel: CPU:1 Mar 14 22:05:25 walker kernel: EIP:0010:[path_walk+2032/2400] Mar 14 22:05:25 walker kernel: EFLAGS: 00010202 Mar 14 22:05:25 walker kernel: eax: 0029 ebx: d6474240 ecx: d9080ee0 edx: c1c8bf10 Mar 14 22:05:25 walker kernel: esi: c1c8bf10 edi: d3a2f060 ebp: c54e3013 esp: c1c8bef4 Mar 14 22:05:25 walker kernel: ds: 0018 es: 0018 ss: 0018 Mar 14 22:05:25 walker kernel: Process rateup (pid: 24715, stackpage=c1c8b000) Mar 14 22:05:25 walker kernel: Stack: dff005a0 0001 d6474240 40174700 dbda2ea0 c011481d dbda2ea0 c54e3000 Mar 14 22:05:25 walker kernel:0013 d45ced21 c1c8bf50 c54e3000 c1c8bf7c 0001 c013f832 Mar 14 22:05:25 walker kernel:c54e3000 c1c8bf7c 0004 c0146b1c db1123a0 c1c8a000 d05596e0 Mar 14 22:05:25 walker kernel: Call Trace: [do_page_fault+349/1088] [open_namei+130/1472] [dput+28/368] [filp_open+54/96] [getname+91/160] [sys_open+58/224] [system_call+51/56] Mar 14 22:05:25 walker kernel: Mar 14 22:05:25 walker kernel: Code: 8b 40 28 85 c0 74 79 be 00 e0 ff ff 21 e6 8b 86 3c 03 00 00 Mar 14 22:05:29 walker kdm[789]: Server for display :0 terminated unexpectedly: 2816 Mar 14 22:05:29 walker kernel: kernel BUG at page_alloc.c:203! Mar 14 22:05:29 walker kernel: invalid operand: Mar 14 22:05:29 walker kernel: CPU:1 Mar 14 22:05:29 walker kernel: EIP:0010:[rmqueue+581/640] Mar 14 22:05:29 walker kernel: EFLAGS: 00013286 Mar 14 22:05:29 walker kernel: eax: 0020 ebx: c154ec24 ecx: edx: 0002 Mar 14 22:05:29 walker kernel: esi: 0001efe0 edi: c110 ebp: 0001efe0 esp: d886be8c Mar 14 22:05:29 walker kernel: ds: 0018 es: 0018 ss: 0018 Mar 14 22:05:29 walker kernel: Process X (pid: 13530, stackpage=d886b000) Mar 14 22:05:29 walker kernel: Stack: c024deeb c024e099 00cb 00012fb5 3282 c029dff8 c029dff8 Mar 14 22:05:29 walker kernel:c029e1f8 c029e1f4 c012e664 0007 0001 d886bf5c Mar 14 22:05:29 walker kernel:cc23a1a0 d4f6aca0 c012e868 c0143123 cfbc5cc0 cc23a1a0 cfbc5d90 Mar 14 22:05:29 walker kernel: Call Trace: [__alloc_pages+228/720] [__get_free_pages+24/48] [__pollwait+51/144] [tcp_poll+46/352] [do_readv_writev+396/608] [sock_poll+33/48] [do_select+295/576] Mar 14 22:05:29 walker kernel:[sys_select+809/1136] [system_call+51/56] Mar 14 22:05:29 walker kernel: Mar 14 22:05:29 walker kernel: Code: 0f 0b 83 c4 0c 89 d8 eb 1d 89 f6 47 83 c6 0c 83 ff 09 0f 86 Mar 14 22:05:30 walker PAM_unix[13534]: (kde) session closed for user sgibson Mar 14 22:05:31 walker kdm[789]: server unexpectedly died Mar 14 22:05:31 walker mysqld: Starting MySQL: succeeded Mar 14 22:05:31 walker linuxconf: Running Linuxconf hooks: succeeded Mar 14 22:05:32 walker kernel: kernel BUG at page_alloc.c:203! Mar 14 22:05:32 walker
Re[4]: VIA686A chipset crash under 2.4.2-ac20
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
>> >> kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
>>
>> MH> this can only be caused by bad cable/config. is it 18", with both ends
>> MH> plugged in?
>>
>>
>> Do you mean 40-pin E-IDE cable?
MH> 40-conductor cables are only valid to use up to udma33, but 80c cables
MH> will *always* help, and can be used in any mode. but equally important
MH> is that the cable must never be longer than 18", with both ends plugged in
MH> (no stub).
Forgot one think!
When I recompiled the kernel with DMA support I got speed on HDD only
16Mb/sec according to hdparm.
-BEGIN PGP SIGNATURE-
Version: 2.6
iQCVAwUAOrFgcD5SQymVx3NvAQFz8gP/XRXrfuFLdds2neck7RiNPPFjcrunEmnL
KAXQBPCr+IT4E8hKZ+IxYjMZooBO68jnNMM4NqzuxDs0bcS4pWwVjln4X2ZQC/vu
iKUWLaeOzGcR7oM9a53h8xFkZTgLYJuChPFxdTyug7ZjPKMbKoOzln/5ShI1Cepn
VdyMwLGb56M=
=nome
-END PGP SIGNATURE-
-
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 0000 and 0002 on dual PIII 750 2.4.2 SMP platform
"Shane Y. Gibson" wrote: > > All, > > I just compiled 2.4.2 and installed it on a otherwise stock > Redhat 7.0 platform. The system is a SuperMicro PIIISME, > running dual PIII 750s, with 256 cache. It appears that about > every 10 to 18 hours, the system is panicing, and freezing > up. The first time, I got an oops , the second time an > oops 0002. Both crashes have occured only when the systems is > at 100% cpu utlization; processing several hundred MRTG > indexmaker operations. > > I ran ksymoops on both outputs, and the results are pasted > below. Note, I compiled the kernel without loadable module > support. Please let me know if there is anything else I can > do/provide to help. Unfortunately, the second didn't output > enough for ksymoops to extract anything usefull. > > v/r > Shane > > Code; Before first symbol >0: 0f 0b ud2a There should be a line just before the oops saying "kernel BUG at..." -- Brian Gerst - 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 0000 and 0002 on dual PIII 750 2.4.2 SMP platform
On Thu, 15 Mar 2001, Shane Y. Gibson wrote: > > All, > > I just compiled 2.4.2 and installed it on a otherwise stock > Redhat 7.0 platform. The system is a SuperMicro PIIISME, > running dual PIII 750s, with 256 cache. It appears that about > every 10 to 18 hours, the system is panicing, and freezing > up. The first time, I got an oops , the second time an > oops 0002. Both crashes have occured only when the systems is > at 100% cpu utlization; processing several hundred MRTG > indexmaker operations. > > I ran ksymoops on both outputs, and the results are pasted > below. Note, I compiled the kernel without loadable module > support. Please let me know if there is anything else I can > do/provide to help. Unfortunately, the second didn't output > enough for ksymoops to extract anything usefull. > > v/r > Shane > > --- first ksymoops output --- > > ksymoops 2.3.4 on i686 2.4.2. Options used > -V (default) > -K (specified) > -l /proc/modules (default) > -o /lib/modules/2.4.2/ (default) > -m /boot/System.map (specified) > > No modules in ksyms, skipping objects > No ksyms, skipping lsmod > Mar 14 22:05:12 walker kernel: invalid operand: > Mar 14 22:05:12 walker kernel: CPU:0 Hi Shane, Did'nt you get a message similar to "kernel BUG at page_alloc.c line xxx!" Before the first oops ? It looks like this oops was triggered by a "BUG()" call, and in this case this message should be printed before the oops. Thanks - 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/
Write throttling problem in 2.4.2?
Dear Developers: More on my 2.4.2 oopses concerning the "Unable to handle kernel paging request" These only take place during ENORMOUS write pressure, and I'm curious as to whether write throttling is an issue here. Since this is on a reiserfs atop lvm, some of the previously conceived solutions may not apply. It's not a major problem, as it only occurs I can start a tars transferring tens of gigabytes. But if I also then launch a task doing enormous activity on the vfs, such as a simultaneous "du -s ." on the directories in question, I can pretty reliably create the kernel paging fault. Cheers, Don Barry Cornell Astronomy -- 2.4.2 vanilla kernel + Brown's NFS patches, pretty minimal otherwise -- problem first seen on 256M ram, still persists at 392M ram -- LVM atop hda/hdb (60g) (motherboard via kt133 chipset) plus promise ultra66 controller driving 80 gig drive on hde - 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/
About DC-315U SCSI driver
Hi all, At last night, I changed my scsi card from a pci slot to another,to avoided the IRQ sharing between on-board USB and SCSI. And burned a cdr to test. It's so magic. The burned files which are not the same with origin ones is much less than before. Why? Can not use IRQ sharing between SCSI? I used Win98 & kernel 2.2.x,and no errors. I burned two cdr with kernel insmoded dc395x_trm.o and another scsi driver integrated kernel. CDR burned with the former has two different files with origin ones. And the latter has six ones. I have no idea about the difference. Maybe I can burn more cdr to test. When I have time, I would like to testing with lowered syncspeed. I hope it will be a temp solution. Best Regards,cwz - 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[4]: VIA686A chipset crash under 2.4.2-ac20
-BEGIN PGP SIGNED MESSAGE-
Hash: MD5
>> >> kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
>>
>> MH> this can only be caused by bad cable/config. is it 18", with both ends
>> MH> plugged in?
>>
>>
>> Do you mean 40-pin E-IDE cable?
MH> 40-conductor cables are only valid to use up to udma33, but 80c cables
MH> will *always* help, and can be used in any mode. but equally important
MH> is that the cable must never be longer than 18", with both ends plugged in
MH> (no stub).
I measured the cable and it is aprox. 45cm (18") and it is 80c.
It has also 3 connectors, two of them are in use (on the ends), and
one is free (in the middle). I also checked the connections on
motherboard and on disk, they are both ok.
-BEGIN PGP SIGNATURE-
Version: 2.6
iQCVAwUAOrFfcT5SQymVx3NvAQEmwQP/bMQYXekwlUDKPdQ80khqfkv45TCY8lVd
r6lXb82s60vvbEpCTyF16E4TwQkwirsPf5virJ0jZO+EBFRVwOhDFitbaF9PdHhG
MdSFtST6JrhwozsoU3LgkdMZb3Mnnw7YsV9ctOZij+4WN5SDd5IO5YNXgeWgrdLb
c+jZzBpmLK8=
=PvVG
-END PGP SIGNATURE-
-
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/
Oops 0000 and 0002 on dual PIII 750 2.4.2 SMP platform
All, I just compiled 2.4.2 and installed it on a otherwise stock Redhat 7.0 platform. The system is a SuperMicro PIIISME, running dual PIII 750s, with 256 cache. It appears that about every 10 to 18 hours, the system is panicing, and freezing up. The first time, I got an oops , the second time an oops 0002. Both crashes have occured only when the systems is at 100% cpu utlization; processing several hundred MRTG indexmaker operations. I ran ksymoops on both outputs, and the results are pasted below. Note, I compiled the kernel without loadable module support. Please let me know if there is anything else I can do/provide to help. Unfortunately, the second didn't output enough for ksymoops to extract anything usefull. v/r Shane --- first ksymoops output --- ksymoops 2.3.4 on i686 2.4.2. Options used -V (default) -K (specified) -l /proc/modules (default) -o /lib/modules/2.4.2/ (default) -m /boot/System.map (specified) No modules in ksyms, skipping objects No ksyms, skipping lsmod Mar 14 22:05:12 walker kernel: invalid operand: Mar 14 22:05:12 walker kernel: CPU:0 Mar 14 22:05:12 walker kernel: EIP:0010:[rmqueue+581/640] Mar 14 22:05:12 walker kernel: EFLAGS: 00010286 Mar 14 22:05:12 walker kernel: eax: 0020 ebx: c1537448 ecx: 0002 edx: 0200 Mar 14 22:05:12 walker kernel: esi: 0001efe0 edi: c110 ebp: 0001efe0 esp: c28e3e2c Mar 14 22:05:12 walker kernel: ds: 0018 es: 0018 ss: 0018 Mar 14 22:05:12 walker kernel: Process indexmaker (pid: 24392, stackpage=c28e3000) Mar 14 22:05:12 walker kernel: Stack: c024deeb c024e099 00cb 00012a2e 0282 c029dff8 c029dff8 Mar 14 22:05:12 walker kernel:c029e1d0 c029e1cc c012e664 0005 0001 cc187220 c19cde40 Mar 14 22:05:12 walker kernel:0025 c7c85bac c0123a32 cc187220 c19cde40 0001 c0123ab0 c19cde40 Mar 14 22:05:12 walker kernel: Call Trace: [__alloc_pages+228/720] [do_anonymous_page+50/128] [do_no_page+48/160] [handle_mm_fault+276/400] [do_page_fault+349/1088] [file_read_actor+0/96] [do_brk+186/368] Mar 14 22:05:12 walker kernel: Code: 0f 0b 83 c4 0c 89 d8 eb 1d 89 f6 47 83 c6 0c 83 ff 09 0f 86 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 0f 0b ud2a Code; 0002 Before first symbol 2: 83 c4 0c add$0xc,%esp Code; 0005 Before first symbol 5: 89 d8 mov%ebx,%eax Code; 0007 Before first symbol 7: eb 1d jmp26 <_EIP+0x26> 0026 Before first symbol Code; 0009 Before first symbol 9: 89 f6 mov%esi,%esi Code; 000b Before first symbol b: 47inc%edi Code; 000c Before first symbol c: 83 c6 0c add$0xc,%esi Code; 000f Before first symbol f: 83 ff 09 cmp$0x9,%edi Code; 0012 Before first symbol 12: 0f 86 00 00 00 00 jbe18 <_EIP+0x18> 0018 Before first symbol Mar 14 22:05:25 walker kernel: Unable to handle kernel NULL pointer dereference at virtual address 0051 Mar 14 22:05:25 walker kernel: c013f010 Mar 14 22:05:25 walker kernel: *pde = Mar 14 22:05:25 walker kernel: Oops: Mar 14 22:05:25 walker kernel: CPU:1 Mar 14 22:05:25 walker kernel: EIP:0010:[path_walk+2032/2400] Mar 14 22:05:25 walker kernel: EFLAGS: 00010202 Mar 14 22:05:25 walker kernel: eax: 0029 ebx: d6474240 ecx: d9080ee0 edx: c1c8bf10 Mar 14 22:05:25 walker kernel: esi: c1c8bf10 edi: d3a2f060 ebp: c54e3013 esp: c1c8bef4 Mar 14 22:05:25 walker kernel: ds: 0018 es: 0018 ss: 0018 Mar 14 22:05:25 walker kernel: Process rateup (pid: 24715, stackpage=c1c8b000) Mar 14 22:05:25 walker kernel: Stack: dff005a0 0001 d6474240 40174700 dbda2ea0 c011481d dbda2ea0 c54e3000 Mar 14 22:05:25 walker kernel:0013 d45ced21 c1c8bf50 c54e3000 c1c8bf7c 0001 c013f832 Mar 14 22:05:25 walker kernel:c54e3000 c1c8bf7c 0004 c0146b1c db1123a0 c1c8a000 d05596e0 Mar 14 22:05:25 walker kernel: Call Trace: [do_page_fault+349/1088] [open_namei+130/1472] [dput+28/368] [filp_open+54/96] [getname+91/160] [sys_open+58/224] [system_call+51/56] Mar 14 22:05:25 walker kernel: Code: 8b 40 28 85 c0 74 79 be 00 e0 ff ff 21 e6 8b 86 3c 03 00 00 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 8b 40 28 mov0x28(%eax),%eax Code; 0003 Before first symbol 3: 85 c0 test %eax,%eax Code; 0005 Before first symbol 5: 74 79 je 80 <_EIP+0x80> 0080 Before first symbol Code; 0007 Before first symbol 7: be 00 e0 ff ffmov$0xe000,%esi Code; 000c Before first
Re: Kernel 2.4.2and 8139too
> "Ted" == Ted Gervais <[EMAIL PROTECTED]> writes: Ted> A simple question for you guru's.. I just installed kernel Ted> 2.4.2 on a slackware system and have a problem with loading a Ted> module. It is the 8139too.o module previously the rtl8139.o. Ted> It seems that this new driver is not being loaded with this Ted> new kernel. Obviously something has changed but I can't seem Ted> to see where that is. I noticed though that the directories Ted> in /lib/modules for this kernel is different than 2.2.18. Sorry, this is not related to your problem... However, I have just put a 8139 based card into my Linux 2.4.2 system. At one stage, these lines were logged: Mar 15 09:42:56 snoopy kernel: eth0: Abnormal interrupt, status 0020. Mar 15 09:43:04 snoopy kernel: eth0: Abnormal interrupt, status 2020. Mar 15 10:06:52 snoopy kernel: eth0: Abnormal interrupt, status 0020. Mar 15 10:06:58 snoopy kernel: eth0: Abnormal interrupt, status 2020. The card seems to be reliable apart from these messages. It could be that I was playing around with the network cable or something at the time... However, any messages "Abnormal interrupt" make me slightly nervous. Anyway, further information: Mar 14 16:10:22 snoopy kernel: 8139too Fast Ethernet driver 0.9.13 loaded Mar 14 16:10:22 snoopy kernel: PCI: Found IRQ 12 for device 00:0a.0 Mar 14 16:10:22 snoopy kernel: eth0: RealTek RTL8139 Fast Ethernet at 0xc880, 00:48:54:1d:b2:85, IRQ 12 Mar 14 16:10:22 snoopy kernel: eth0: Identified 8139 chip type 'RTL-8139C' [...] Mar 14 16:10:23 snoopy kernel: eth0: Setting full-duplex based on MII #32 link partner ability of 45e1. (sorry if this problem has already been reported...) -- Brian May <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 pre13 doesn't like retransmitted SYN ACK packets
On Thu, Mar 15, 2001 at 05:09:47PM -0300, Henrique de Moraes Holschuh wrote: > 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. 2.2.19pre17 works. Thank you. 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: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
> I've implemented a patch for util-linux-2.11a > which adds LABEL support to mkswap(8) and swapon/swapoff(8). Yes, maybe a reasonable idea. But I would prefer a somewhat more ambitious approach. My first thought was: why label individual swap partitions? I almost never want to distinguish swap partitions, and just do "swapon -a". In case one wants to guard against changing device names, why not add an option -A so that "swapon -A" does swapon on each partition with a swap signature? However, that would greatly increase the risk that exists already today: someone has a swap partition, and does mkfs.foo, and it so happens that foofs does not use the sector with the swapsignature. Now this foofs partition has a swap signature, but we would be very unhappy if it were used as swap space. The real problem is that our disks usually do not have a volume label. Outside of all file systems. The "signatures" that we rely on today are located in different places, so that a filesystem can have several valid signatures at the same time. And we first know where to look when we know the type already. Design a Linux partition table format, where a partition descriptor has fields start, end, fstype, fslabel, and the whole disk has a vollabel. Put it in sector 0-N for an all-Linux disk, and in sectors pointed at by a classical DOS-type partition table entry when the disk is shared. (Maybe I already did that once - it sounds so familiar now that I write this. Then why was it not pursued? Maybe LVM already does these things?) 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/
Re: pivot_root & linuxrc problem
On Thu, Mar 15, 2001 at 10:11:55PM +0100, Mike Galbraith wrote: > 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. Linux always forks from PID1 before executing /linuxrc automagically. Check init/main.c. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - 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
On Thu, Mar 15, 2001 at 06:20:24AM -0800, Peter DeVries wrote: > 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. Do you notice any programs getting SEGVs? If they do, it could be bad RAM. Personally, when I come across a machine which behaves oddly, the first thing I'd try is checking the memory. You can get a copy of memtest86 for doing this. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - 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 12:34:06 -0700 (MST), Andreas Dilger wrote in LKML: >Lars writes: >> > Put LABEL= in you fstab in place of the device name. >> >> Which is great, for filesystems that support labels. Unfortunately, >> this isn't universally available -- for instance, you cannot mount >> a swap partition by label or uuid, so it is not possible to completely >> isolate yourself from the problems of disk device renumbering. > >There is room for a LABEL and/or UUID in the swap superblock, if you >would want to implement support for this. Despair no more! I've implemented a patch for util-linux-2.11a which adds LABEL support to mkswap(8) and swapon/swapoff(8). - I shrunk the padding field in the new-style swap_header to make room for 16 bytes worth of volume label (same as ext2) - mkswap -L label also sets the volume label - swapon -L label looks for a swap partition with the given label (using a clone of mount(8)'s LABEL/UUID= support code) - swapon/swapoff -a also handles swap fstab entries where the device is specified as LABEL= The patch is available at http://www.csd.uu.se/~mikpe/linux/swap-label/ /Mikael - 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, Andrzej Krzysztofowicz wrote: > "Rik van Riel wrote:" > > total usage == maximum(swap, ram) > > Does it mean that having swaphttp://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?
"Rik van Riel wrote:" > total usage == maximum(swap, ram) Does it mean that having swaphttp://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to optimize routing performance
Manfred Spraul writes: > > > > http://Linux/net-development/experiments/010313 > > > The link is broken, and I couldn't find it at www.linux.com. Did you > forget the host? Yes Sir! The profile data from the Linux production router is at: http://robur.slu.se/Linux/net-development/experiments/010313 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: Kernel 2.4.2
I do have the latest version of modutils (at least, the one required by Documentation/Changes - 2.4.2), but I still have to all the line add path=/lib/modules/`uname -r`/kernel/* to /etc/modules.conf. ONLY then it works. At least it worked until yesterday... Yesterday I found out that I can't use CD-ROM on one of the machines, and, in particular, when I am trying to access it - together with ide.o, iso9660.o, also get loaded lp.o, parport.o and parport-pc.o... with no visible reason... But I am not sure if this should be associated with modutils or whatever... Why did I need that line? Thanks Guennadi On Thu, 15 Mar 2001, John Jasen wrote: > 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/ > ___ Dr. Guennadi V. Liakhovetski Department of Applied Mathematics University of Sheffield, U.K. 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: 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/
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
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: 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/
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
> > 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/
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
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: 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: 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: 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: 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: 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: 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(_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(_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(>wait, );
do {
- sync_page(page);
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
if (!PageLocked(page))
break;
- run_task_queue(_disk);
+
+ sync_page(page);
schedule();
} while (PageLocked(page));
tsk->state = TASK_RUNNING;
@@ -633,10 +633,9 @@
add_wait_queue_exclusive(>wait, );
for (;;) {
- sync_page(page);
set_task_state(tsk, TASK_UNINTERRUPTIBLE);
if (PageLocked(page)) {
- run_task_queue(_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(>wait, );
~> for (;;) {
> sync_page(page);
> set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> if (PageLocked(page)) {
> run_task_queue(_disk);
> schedule();
> continue;
> }
> if (!TryLockPage(page))
> break;
> }
> tsk->state = TASK_RUNNING;
> remove_wait_queue(>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(_disk)).
>
> I don't see any problem if we remove the run_task_queue(_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: 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
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: 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/
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: 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/
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: 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: 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/
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: 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/
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: 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?
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/
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/
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
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/
