RE: Linus's include file strategy redux
> Huh? > % ls -ld /usr/include/linux > drwxr-xr-x6 root root18432 Sep 2 22:35 > /usr/include/linux/ > > > So if we create a separate /usr/src/linux/include/kernel dir, does that > > imply that we'll have a 2nd link: > > What 2nd link? There should be _no_ links from /usr/include to the > kernel tree. Period. Case closed. --- > ll -d /usr/include/linux lrwxrwxrwx 1 root root 26 Dec 25 1999 /usr/include/linux -> ../src/linux/include/linux/ --- I've seen this setup on RH, SuSE and Mandrake systems. I thought this was somehow normal practice? > Stuff in /usr/include is private libc copy extracted from some kernel > version. Which may have _nothing_ to the kernel you are developing for. > In the situation above they should have > -I/include > in CFLAGS. Always had to. No links, no pain in ass, no interference with > userland compiles. > > IOW, let them fix their Makefiles. --- Why would Linus want two separate directories -- one for 'kernel-only' include files and one for kernel files that may be included in user land? It seems to me, if /usr/include/linux was normally a separate directory there would be no need for him to mention a desire to create a separate kernel-only include directory, so my assumption was the linked behavior was somehow 'normal'. I think many source packages only use "-I /usr/include" and make no provision for compiling against kernel header files in different locations that need to be entered by hand. It is difficult to create an automatic package regeneration mechanism like RPM if such details need to be entered for each package. So what you seem to be saying, if I may rephrase, is that the idea of automatic package generation for some given kernel is impractical because users should be expected to edit each package makefile for their own setup with no expectation from the packages designers of a standard kernel include location? I'm not convinced this is a desirable goal. :-/ -linda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
userlink
I am trying to port the Userlink driver (used for IPsec) to 2.4.0-test10. I
have 2 questions:
Firstly has anyone already done this?
Secondly, how do I re-write the following code to work with 2.4.0?
static int
net_ul_start(struct net_device *dev)
{
dev->start = 1;
dev->tbusy = 0;
return(0);
}
Thanks.
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: cramfs filesystem patch
On Saturday 09 December 2000 06:39, Tim Riker wrote:
> I'd like to see these patches as well. They may be useful on the iPAQ
> (and similar hardware like my Yopy here... ;-)
>
> I wish some hardware vendor out there would build an x86 box that used
> memory addressable flash from 0 up and RAM up higher. A simple Linux
> kernel boot loader could then replace the BIOS. Flash would be less
> expensive than 8086 lower memory windowed flash hacks.
>
> Has any work been done on e2compr in 2.4 yet?
>
Patch inserted. It's not ready for kernel inclusion or anything..., there are some
remaining issues to fix that I haven't figured out good ways to handle yet.
For instance, we still use a /dev/rom to bootstrap the kernel as to which
file system module to pull up. Then all the read/writes completely by pass
/dev/rom. Silly, I know, but I haven't figured out a smart way to deal with
this particular problem.
Sorry for the late reply..., your message got lost in a sea of mail. You might
find some other interesting stuff on the ftp.agendacomputing.com ftp site.
XIP MTD flash read/write, which I haven't forward ported to MTDs CVS yet.
(Working on it) But that would allow if you guys can get XIP kernel working
in ARM like we have in MIPS to read and write to flash. Other randomn stuff,
and things get added with a slightly normal frequency. One benefit with this
patch is copying, the other is dumping that 32k buffer, and giving it back to
pageable memory.
Thanks,
Shane.
diff -urN linux.orig/fs/Config.in linux/fs/Config.in
--- linux.orig/fs/Config.in Fri Oct 27 04:23:18 2000
+++ linux/fs/Config.in Fri Oct 27 03:57:52 2000
@@ -29,6 +29,10 @@
int 'JFFS debugging verbosity (0 = quiet, 3 = noisy)' CONFIG_JFFS_FS_VERBOSE 0
fi
tristate 'Compressed ROM file system support' CONFIG_CRAMFS
+dep_mbool 'Linear addressing for CRAMFS' CONFIG_CRAMFS_LINEAR_ADDRESSING
+$CONFIG_CRAMFS
+if [ "$CONFIG_CRAMFS_LINEAR_ADDRESSING" != "n" ] ; then
+ hex 'Starting address for CRAMFS filesystem' CONFIG_CRAMFS_LA_ADDRESS bf28
+fi
tristate 'Simple RAM-based file system support' CONFIG_RAMFS
tristate 'ISO 9660 CDROM file system support' CONFIG_ISO9660_FS
diff -urN linux.orig/fs/cramfs/inode.c linux/fs/cramfs/inode.c
--- linux.orig/fs/cramfs/inode.cFri Oct 27 04:22:36 2000
+++ linux/fs/cramfs/inode.c Fri Oct 27 04:30:18 2000
@@ -11,6 +11,20 @@
* The actual compression is based on zlib, see the other files.
*/
+/* Linear Addressing code
+ *
+ * Copyright (C) 2000 Shane Nay.
+ *
+ * Allows you to have a linearly addressed cramfs filesystem.
+ * Saves the need for buffer, and the munging of the buffer.
+ * Savings a bit over 32k with default PAGE_SIZE, BUFFER_SIZE
+ * etc. Usefull on embedded platform with ROM :-).
+ *
+ * Downsides- Currently linear addressed cramfs partitions
+ * don't co-exist with block cramfs partitions.
+ *
+ */
+
#include
#include
#include
@@ -68,6 +82,23 @@
return inode;
}
+#if defined(CONFIG_CRAMFS_CRAMFS_LINEAR_ADDRESSING) && defined
+(CONFIG_CRAMFS_LA_ADDRESS)
+
+/*
+ * Returns a pointer to the linearly addressed filesystem.
+ * Simple byte size pointer addition.
+ */
+static unsigned char* romdisk_top=(unsigned char*) CONFIG_CRAMFS_LA_ADDRESS;
+
+static void *cramfs_read(struct super_block *sb, unsigned int offset, unsigned int
+len)
+{
+ if (!len)
+ return NULL;
+ return romdisk_top + offset;
+}
+
+#else /* !CONFIG_CRAMFS_LINEAR_ADDRESSING aka Regular block mode */
+
/*
* We have our own block cache: don't fill up the buffer cache
* with the rom-image, because the way the filesystem is set
@@ -149,6 +180,8 @@
}
return read_buffers[buffer] + offset;
}
+
+#endif
static struct super_block * cramfs_read_super(struct super_block *sb, void *data, int
silent)
@@ -161,10 +194,11 @@
set_blocksize(sb->s_dev, PAGE_CACHE_SIZE);
sb->s_blocksize = PAGE_CACHE_SIZE;
sb->s_blocksize_bits = PAGE_CACHE_SHIFT;
+#if !( defined(CONFIG_CRAMFS_CRAMFS_LINEAR_ADDRESSING) && defined
+(CONFIG_CRAMFS_LA_ADDRESS) )
/* Invalidate the read buffers on mount: think disk change.. */
for (i = 0; i < READ_BUFFERS; i++)
buffer_blocknr[i] = -1;
+#endif
/* Read the first block and get the superblock from it */
memcpy(, cramfs_read(sb, 0, sizeof(super)), sizeof(super));
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: fix FAT32 filesystems on 64-bit platforms
> This fixes FAT32 on 64-bit platforms (notably, IA-64 and Alpha); > without this you can't mount any FAT32 filesystems. A similar patch > is already in 2.2.18. ... > - next = CF_LE_L(((unsigned long *) bh->b_data)[(first & > + next = CF_LE_L(((__u32 *) bh->b_data)[(first & ... > - next = CF_LE_W(((unsigned short *) bh->b_data)[(first & > + next = CF_LE_W(((__u16 *) bh->b_data)[(first & These macros really ought to be replaced with the standard le32_to_cpu() and le16_to_cpu() ones. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Test12 ll_rw_block error.
On Thu, 14 Dec 2000, Linus Torvalds wrote: > Good point. > > This actually looks fairly nasty to fix. The obvious fix would be to not > put such buffers on the dirty list at all, and instead rely on the VM > layer calling "writepage()" when it wants to push out the pages. > That would be the nice behaviour from a VM standpoint. > > However, that assumes that you don't have any "anonymous" buffers, which > is probably an unrealistic assumption. > > The problem is that we don't have any per-buffer "writebuffer()" function, > the way we have them per-page. It was never needed for any of the normal > filesystems, and XFS just happened to be able to take advantage of the > b_end_io behaviour. > > Suggestions welcome. Just one: any fs that really cares about completion callback is very likely to be picky about the requests ordering. So sync_buffers() is very unlikely to be useful anyway. In that sense we really don't have anonymous buffers here. I seriously suspect that "unrealistic" assumption is not unrealistic at all. I'm not sufficiently familiar with XFS code to say for sure, but... What we really need is a way for VFS/VM to pass the pressure on filesystem. That's it. If fs wants unusual completions for requests - let it have its own queueing mechanism and submit these requests when it finds that convenient. Stephen, you probably already thought about that area. Could you comment on that? Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Anyone having trouble compiling test13-pre1?
I'm having some problems with unresolved symbols in my modules with test13-pre1. This worked just fine before, and the symbols are all stuff that I'm sure it there. It looks like the modules were compiled for non-versioned symbols, while my kernel uses versioned symbols. The modules are looking for things like daemonize, kmalloc, try_inc_mod_count, and other things I'd fully expect to be there. /proc/ksyms shows them as __VERSIONED_SYMBOL(daemonize), so I'm not sure what to expect. And yes, I'm running modutils 2.3.18. Is anyone else seeing this, or am I insane? Matt P.S. The test13-pre1 is still compiling (and installing modules, etc) as 2.4.0-test12. -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver Pitr! That's brilliant! Funded by Microsoft refunds. What sweet irony! -- A.J. User Friendly, 2/15/1999 PGP signature
Re: failed in BUG() at fs/buffer.c:765
Neil Brown wrote: > The simplest fix for this is the patch below. Exactly what will get > into test13 has not yet been decided. > > NeilBrown Thanks for your advice. I will try it soon, maybe tonight or tomorrow. --- Atsuhiro Kojima Library & Science Information Center, Osaka Prefecture University. E-mail: [EMAIL PROTECTED] http://cuvier.center.osakafu-u.ac.jp/ark/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Test12 ll_rw_block error.
On Thu, 14 Dec 2000, Russell Cattelan wrote: > > Ok one more wrinkle. > sync_buffers calls ll_rw_block, this is going to have the same problem as > calling ll_rw_block directly. Good point. This actually looks fairly nasty to fix. The obvious fix would be to not put such buffers on the dirty list at all, and instead rely on the VM layer calling "writepage()" when it wants to push out the pages. That would be the nice behaviour from a VM standpoint. However, that assumes that you don't have any "anonymous" buffers, which is probably an unrealistic assumption. The problem is that we don't have any per-buffer "writebuffer()" function, the way we have them per-page. It was never needed for any of the normal filesystems, and XFS just happened to be able to take advantage of the b_end_io behaviour. Suggestions welcome. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
user-mode port 0.35-2.4.0-test12
The user-mode port of 2.4.0-test12 is finally available. It has been in CVS for a couple of days, but SourceForge only today fixed up the site enough to allow projects to make releases. hostfs now mostly works. It's still somewhat buggy. It is also possible to specify what host directory you want mounted inside the virtual machine. The problem with linking a profiling kernel was fixed. Several crashes were fixed. uname -m no longer returns 'um'. It returns the underlying arch. The reason for this is that some builds (not least the UML build itself) get confused when they see an 'um' machine. I see no advantages to having UML returning a different arch, so it doesn't any more. Several bugs in the block driver were fixed. 'dd if=ubd/0 of=/dev/null' no longer hangs, and dbench no longer produces filesystem corruption. The project's home page is http://user-mode-linux.sourceforge.net The project's download page is http://sourceforge.net/project/filelist.php?grou p_id=429 Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
On Thu, 14 Dec 2000, Linus Torvalds wrote: > On Thu, 14 Dec 2000, Stephen Frost wrote: > > > > Any idea if these issues would cause a general slow-down of a > > machine? For no apparent reason after 5 days running 2.4.0test12 > > everything going through my firewall (set up using iptables) I got about > > 100ms time added on to pings and traceroutes. > > Probably not related to that particular bug - the netfilter issue has > apparently been around forever, and it was just some changes in IP > fragmentation that just made it show up as an oops. > > A 100ms delay sounds like some interrupt shut up or similar (and then > timer handling makes it limp along). Possibly related datapoint: after several days of uptime, my 2.4.0-test10pre? machine went into some sort of slow mode after coming back from suspend (and doing an /etc/init.d/networking restart). Symptoms seemed to be extra second or so setting up a TCP connection. Ping, etc., appeared to work just fine, no packet loss apparent, bandwidth looked good too. Sadly I had to do actual work that required zippy web access, so I rebooted rather than doing a thorough diagnostic. This is a VAIO with compiled in eepro100, no special networking options. Oh, and btw, test12-pre7 seems to have broken my USB camera, which worked with the aforementioned kernel. My build of gphoto2 downloads images via usbdevfs (ugh) and quietly created a bunch of .jpgs that were almost entirely 0s.. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Will the large corporate contributors to Linux like IBM help us get more device specifications?
Hi, There seems to be an ongoing need for a stronger relationship between the kernel development community and the various hardware vendors. Specifically, the current situation seems to often be that individuals from the community are banging on random doors and sending e-mail to support staff asking whether they can be given access to device specs under NDA or, preferably, with no restrictions for the purposes of driver development. It seems to me that IBM's commitment to spend $1B this coming year on Linux development, combined with IBM's considerable influence in the general computing space might enable them to help the Linux kernel community forge new and much closer relationships with IHVs. Ideally, these new relationships would involve more information being pushed to us rather than pulled by us. An area in of great need of access to specifications is USB development. Things are going well with reverse engingeering for many devices, but this is slow, prone to error and probably misses taking advantage of proprietary speedups available from intimate specification knowledge. This is particularly true when we come up against vendor-specific USB protocol implementations. Would it make any sense to ask these large corporate participants whether they would be willing to put together some sort of device specification collection group along with members of the Linux kernel community? A group including representatives of these many groups might have more leverage with IHVs than the Linux kernel community has now. I hope this helps, Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
On Thu, 14 Dec 2000, Alexander Viro wrote: > > > On Thu, 14 Dec 2000, David Riley wrote: > > > Alexander Viro wrote: > > > > > > Actually, I suspect that quite a few of us had done that since long - > > > IIRC I've got burned on 1.2/1.3 and decided that I had enough. Bugger if I > > > remember what exactly it was - ISTR that it was restore(8) built with > > > 1.3. headers and playing funny games on 1.2, but it might be > > > something else... > > > > So then what's the correct header tree to put in /usr/include/linux? I > > could use the stock 2.2.14-patched headers that came with the dist, but > > how often does it need to be updated? Or should I use the latest 2.2? > > Whatever your libc was built against. It shouldn't matter that much, > but when shit hits the fan... you really don't want to be there. > > Look at it that way: you don't want to build some object files with one > set of headers, some - with another and link them together. Now, > s/some object files/libc/. With a minimal luck you will be OK, but > it's easier not to ask for trouble in the first place. Yep. At one point, about six months ago, I recompiled glibc 2.0.7(?) against 2.2.15(?) with USB backport due to occational USB v4l device-related bus locks, recompiled the v4l app I was using (w3cam package I think) and the problems mostly went away. As far as I understand it's a matter of a kernel/userland seperation. But again, sometimes you just have to update your libc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: fix for nfs on 64 bit archs.
Hi, Since we use bitops on wb_flags it needs to be unsigned long. With this fix nfs works on sparc64 again. Anton --- linux/include/linux/nfs_page.h Wed Dec 6 22:19:17 2000 +++ linux_work/include/linux/nfs_page.h Fri Dec 15 14:38:18 2000 @@ -33,8 +33,8 @@ unsigned long wb_timeout; /* when to read/write/commit */ unsigned intwb_offset, /* Offset of read/write */ wb_bytes, /* Length of request */ - wb_count, /* reference count */ - wb_flags; + wb_count; /* reference count */ + unsigned long wb_flags; struct nfs_writeverfwb_verf;/* Commit cookie */ }; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Question about RTC interrupts on i386
I'm reading the book Linux Internals by Moshe Bar. Early on he describes the use of the real time clock to generate an interrupt 100 times a second. He explains that this value was chosen early in the development cycle of the linux kernel and is therefore relatively low compared to what current hardware can make good use of. He mentions that the alpha port of linux uses a 1024Hz interrupt rate and that patches have been made for the Intel kernel to give it the same rate while maintaining the interrupt rate that appears to userland programs such as top at 100Hz. I'm just wondering what the benefits of increasing this value are and whether these patches are going to be included in 2.4? Thanks, Lee Reynolds __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Test12 ll_rw_block error.
On Thu, 14 Dec 2000, Russell Cattelan wrote: > > So one more observation in > filemap_sync_pte > > lock_page(page); > error = filemap_write_page(page, 1); > -> UnlockPage(page); > This unlock page was removed? is that correct? Yes. The "writepage" thing changed: "struct file" disappeared (as I'm sure you also noticed), and the page writer is supposed to unlock the page itself. Which it may do at any time, of course. There are some reasons to do it only after the IO has actually completed: this way the VM layer won't try to write it out _again_ before the first IO hasn't even finished yet, and the writing logic can possibly be simplified if you know that nobody else will be touching that page. But that is up to you: you can do the UnlockPage before even returning from your "->writepage()" function, if you choose to do so. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
loop device length
losetup allows for setting a starting offset within a file for the loop block device. There however is no length parameter to permit setting the length. Adding a length parameter would allow for multiple fs images in a single file (or device) and would correctly handle programs like resize2fs. What do you think? We could add a lo_length to struct loop_device and return that if it was non-zero and less than the physical length calculated normally by figure_loop_size(). While I'm at it why are loop_sizes[] and loop_blksizes[] not part of struct loop_device now? -- Tim Riker - http://rikers.org/ - short SIGs! All I need to know I could have learned in Kindergarten ... if I'd just been paying attention. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test12 + initrd = swapper at 99.8% CPU timer
On Thu, 14 Dec 2000, Joseph Cheek wrote:
> hi,
>
> ps axufw shows it as pid 1.
Interesting.. init running out of control. I've seen that, and it
was init taking endless page faults.
I wager (one virtual brew) that you'll see an endless stream of output
if you apply this.
--- kernel/signal.c.org Fri Dec 15 03:36:59 2000
+++ kernel/signal.c Fri Dec 15 03:39:36 2000
@@ -564,6 +564,9 @@
{
unsigned long int flags;
+ if (sig == SIGSEGV)
+ printk(KERN_ERR "SIGSEGV pid %d\n", t->pid);
+
spin_lock_irqsave(>sigmask_lock, flags);
if (t->sig == NULL) {
spin_unlock_irqrestore(>sigmask_lock, flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Test12 ll_rw_block error.
In article <[EMAIL PROTECTED]>, Russell Cattelan <[EMAIL PROTECTED]> wrote: >This would seem to be an error on the part of ll_rw_block. >Setting b_end_io to a default handler without checking to see >a callback has already been defined defeats the purpose of having >a function op. No. It just means that if you have your own function op, you had better not call "ll_rw_block()". The problem is that as it was done before, people would set the function op without actually holding the buffer lock. Which meant that you could have two unrelated users setting the function op to two different things, and it would be only a matter of the purest luck which one happened to "win". If you want to set your own end-operation, you now need to lock the buffer _first_, then set "b_end_io" to your operation, and then do a "submit_bh()". You cannot use ll_rw_block(). Yes, this is different than before. Sorry about that. But yes, this way actually happens to work reliably. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Is there a Linux trademark issue with sun?
Heads up everybody. Scott McNealy has apparently been calling Solaris Sun's implementation of Linux. Trademark violation time. The article's here: http://linuxtoday.com/news_story.php3?ltsn=2000-12-14-020-04-NW-CY Quick quote: >When asked by a reporter why Sun's new clustering >software was restricted to Solaris and not available >on Linux, McNealy's aggravation seemed to peak. "You >people just don't get it, do you? All Linux >applications run on Solaris, which is our >implementation of Linux. Now ask the question again," Assuming the quote is accurate (which, being ZD, is iffy), this strikes me as a mondo trademark violation, and exactly the sort of thing the Linux trademark was designed to prevent. Solaris is NOT Linux. That's just my opinion, of course, but I wanted to make sure everybody was aware of the situation... Rob (Yes, it finally happened. The Unix idiots have now "protected" the trademark "Unix" to the point where Linux is now a more valuable name to be associated with. But turnabout IS fair play. And they know the rules if they want to participate. Add in the MS profit warning and IBM's billion dollar pledge to our little PBS station and it's been a good week...) __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
"David S. Miller" wrote: > >Date: Thu, 14 Dec 2000 15:35:48 -0500 (EST) >From: "Mohammad A. Haque" <[EMAIL PROTECTED]> > >I'll be trying in a few hours. > > Meanwhile for people wanting the crashes to be fixed, please > apply this patch. > > This was _always_ broken, and really what netfilter is doing > should have never worked. The only theory I have right now > is that people using netfilter never had IP fragments timeout. > :-) > > So the patch below restores previous behavior exactly. > Ie. netfilter sources fragments cannot send ICMP errors > on frag queue timeout :-) > Hello, I posted one of these generated by nfs earlier. This one is from $ ping -c 1 -s 1478 <2.4.0-t12-host> from peer. kdb over serial console -- the module addresses are accurate. Lightly edited for readability. Hope this helps, Tom Unable to handle kernel NULL pointer dereference at virtual address 003c printing eip: c01c0c32 *pde = Entering kdb (current=0xc02c, pid 0) Panic: Oops due to panic @ 0xc01c0c32 eax = 0x ebx = 0x ecx = 0xc11a6fa0 edx = 0x0006 esi = 0xc1376be0 edi = 0x esp = 0xc02c1bac eip = 0xc01c0c32 ebp = 0xc02c1bc8 xss = 0x0018 xcs = 0xc11a0010 eflags = 0x00010246 xds = 0x31010018 xes = 0x0018 origeax = 0x = 0xc02c1b78 kdb> bt EBP EIP Function(args) 0xc02c1bc8 0xc01c0c32 ip_frag_queue+0x222 (0xc11a6fa0, 0xc1376be0) kernel .text 0xc010 0xc01c0a10 0xc01c0c90 0xc02c1bf4 0xc01c1004 ip_defrag+0xc4 (0xc1376be0) kernel .text 0xc010 0xc01c0f40 0xc01c1070 0xc02c1c0c 0xc4093365 [ip_conntrack]ip_ct_gather_frags+0x25 (0xc1376be0) ip_conntrack .text 0xc4091060 0xc4093340 0xc40933e0 0xc02c1c54 0xc40924cd [ip_conntrack]ip_conntrack_in+0x3d (0x3, 0xc02c1cdc, 0x0, 0xc3104800, 0xc01c3560) ip_conntrack .text 0xc4091060 0xc4092490 0xc40927b0 0xc02c1c70 0xc4094666 [ip_conntrack]ip_conntrack_local+0x56 (0x3, 0xc02c1cdc, 0x0, 0xc3104800, 0xc01c3560) ip_conntrack .text 0xc4091060 0xc4094610 0xc4094670 0xc02c1c98 0xc01b2d98 nf_iterate+0x28 (0xc0320cd8, 0xc02c1cdc, 0x3, 0x0, 0xc3104800) kernel .text 0xc010 0xc01b2d70 0xc01b2e00 0xc02c1ccc 0xc01b3001 nf_hook_slow+0x71 (0x2, 0x3, 0xc1376be0, 0x0, 0xc3104800) kernel .text 0xc010 0xc01b2f90 0xc01b3080 0xc02c1d3c 0xc01c2c27 ip_build_xmit_slow+0x387 (0xc11d2730, 0xc01d9a00, 0xc02c1dfc, 0x5e2, 0xc02c1de0) kernel .text 0xc010 0xc01c28a0 0xc01c2d00 0xc02c1d7c 0xc01c2d4b ip_build_xmit+0x4b (0xc11d2730, 0xc01d9a00, 0xc02c1dfc, 0x5e2, 0xc02c1de0) kernel .text 0xc010 0xc01c2d00 0xc01c2ff0 0xc02c1dec 0xc01d9c03 icmp_reply+0x173 (0xc02c1dfc, 0xc136aab0) kernel .text 0xc010 0xc01d9a90 0xc01d9c20 0xc02c1e44 0xc01da1aa icmp_echo+0x3a (0xc0aad824, 0xc136aab0, 0x5c6) more> kernel .text 0xc010 0xc01da170 0xc01da1b0 0xc02c1e68 0xc01da459 icmp_rcv+0xa9 (0xc136aab0, 0x5ce) kernel .text 0xc010 0xc01da3b0 0xc01da490 0xc02c1e88 0xc01c04a4 ip_local_deliver_finish+0x94 (0xc136aab0, 0xc136aab0) kernel .text 0xc010 0xc01c0410 0xc01c0520 0xc02c1ea4 0xc01b3048 nf_hook_slow+0xb8 (0x2, 0x1, 0xc136aab0, 0xc3104800, 0x0) kernel .text 0xc010 0xc01b2f90 0xc01b3080 0xc02c1ec4 0xc01c02d5 ip_local_deliver+0x45 (0xc136aab0) kernel .text 0xc010 0xc01c0290 0xc01c02e0 0xc02c1ee8 0xc01c06dc ip_rcv_finish+0x1bc (0xc136aab0, 0xc08bd210) kernel .text 0xc010 0xc01c0520 0xc01c0710 0xc02c1f04 0xc01b3048 nf_hook_slow+0xb8 (0x2, 0x0, 0xc136aab0, 0xc3104800, 0x0) kernel .text 0xc010 0xc01b2f90 0xc01b3080 0xc02c1f38 0xc01c03dc ip_rcv+0xfc (0xc08bd210, 0xc3104800, 0xc02bca84) kernel .text 0xc010 0xc01c02e0 0xc01c0410 0xc02c1f68 0xc01b703d net_rx_action+0x12d (0xc02facf0) kernel .text 0xc010 0xc01b6f10 0xc01b7160 0xc02c1f80 0xc011bd7e do_softirq+0x4e kernel .text 0xc010 0xc011bd30 0xc011bdb0 0xc02c1f98 0xc010ad13 do_IRQ+0xa3 (0xc01074f0, 0xc2532260, 0xc02c, 0xc02c, 0xc02c) kernel .text 0xc010 0xc010ac70 0xc010ad30 0xc01093f0 ret_from_intr kernel .text 0xc010 0xc01093f0 0xc0109410 Interrupt registers: eax = 0x ebx = 0xc01074f0 ecx = 0xc2532260 edx = 0xc02c esi = 0xc02c edi = 0xc02c esp = 0xc02c1fd4 eip = 0xc0107516 ebp = 0xc02c1fd4 xss = 0x0018 xcs = 0x0010 eflags = 0x0246 xds = 0xc0100018 xes = 0xc02c0018 origeax = 0xff0c = 0xc02c1fa0
[PATCH] Makefile fix
This patch should be obviously correct. diff -urN linux-2.4.0t13p1/arch/i386/Makefile linux/arch/i386/Makefile --- linux-2.4.0t13p1/arch/i386/Makefile Thu Dec 14 20:54:41 2000 +++ linux/arch/i386/MakefileThu Dec 14 21:04:34 2000 @@ -91,7 +91,7 @@ ifdef CONFIG_MATH_EMULATION SUBDIRS += arch/i386/math-emu -SUBDIRS += arch/i386/math-emu/math.o +DRIVERS += arch/i386/math-emu/math.o endif arch/i386/kernel: dummy -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Lockup at boot with HPT370 and 2.4.0-test12
I have an Abit KT7-RAID mobo which sports an HPT370 ATA-100 IDE controller. When I configure support for the 370 into a 2.4.0-test12 kernel, the resulting kernel will hang at boot time. The ide2 and ide3 channels are detected, but when the kernel gets to the part where it usually displays info on the disks attached to those channels, it locks hard with the only sign of life being a constantly illuminated HDD LED. 2.2.18 + ide.2.2.18.1209.patch works fine, however. 2.2 boots fine and the attached disks are perfectly usable. Hardware RAID (rather, Highpoint's approximation of it) is not configured in the BIOS of the 370. Looking through linux-kernel archives, I noticed that someone ran into this last month sometime. I didn't see a reply so this is my 'me too' post. If more info or testing is needed, lemme know. /ryan/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Is there a Linux power management mailing list?
Is there? If not, I think there may be a need for one, and I will start it. -- Andy Andrew Grover Intel/TRL/MAL [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Test12 ll_rw_block error.
This would seem to be an error on the part of ll_rw_block.
Setting b_end_io to a default handler without checking to see
a callback has already been defined defeats the purpose of having
a function op.
void ll_rw_block(int rw, int nr, struct buffer_head * bhs[])
{
@@ -928,7 +1046,8 @@
if (test_and_set_bit(BH_Lock, >b_state))
continue;
- set_bit(BH_Req, >b_state);
+ /* We have the buffer lock */
+ bh->b_end_io = end_buffer_io_sync;
switch(rw) {
case WRITE:
-Russell Cattelan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Netfilter is broken (was Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback))
On Fri, Dec 15, 2000 at 01:48:32AM +0100, Andi Kleen wrote: > > Also is it sure that the backtrace involves ip_rcv ? A more likely > guess is that it happens during the IP_LOCAL_OUT hook, when skb->dev > isn't set yet, but conntrack already has to already reassemble fragments. Oh, thanks Andi. This is the key, of course. I'm always way too focused on forwarded packets ;) This is definitely the problem. We could set skb->dev to skb->dst->dev, but this sounds more like a hack than a real solution... > -Andi -- Live long and prosper - Harald Welte / [EMAIL PROTECTED]http://www.gnumonks.org GCS/E/IT d- s-: a-- 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+(*) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
No Subject
On my newly installed 2 CPU server with redhat-7.0 I have two Adaptec quartet64 (ANA-62044) ethernet cards. Using the 2.4.0-testxx kernel I get this kernel error for something that looks like every single packet passing the network interface, providing vast syslog files, and makes i t impossible to use the console terminal to anything usefull, also featuring unreliable network connection. kernel: eth0: Internal fault: The skbuff addresses do not match in netdev_rx: 922368017 vs. f6fa3800 / f6fa3810. The numbers changes as the errors keep coming rapidly. I have tried the preview "2.4.0-26" kernel provided on the redhat cd-drom, and selfcompiled versions of 2.4.0-test11 and 2.4.0-test12 kernels using gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) glibc-2.2-5. The network itself is kind of working, providing speed from 11.5Mbytes/ to 3-4Mbytes/s on one tp cable, but sometimes hangs for a while, providing lousy and unreliable network performance. The nic is currently connected with a single cat5 tp cable to a switch, with auto-negotiation for speed and duplex enabled, showing no errors either on the switch side nor from the output of ifconfig. Since the network seems to be working almost fine, I believe it's just a small bug that needs to be located and fixed. It seems to be working fairly ok the the few hours I've been running on 2.2.18 with Donald Becker's starfire.c driver. Regards Vidar Haugsvær - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
> > o We tell vendors to build RPMv3 , glibc 2.1.x > Curious HOW do you tell vendors?? When they ask. More usefully Dan Quinlann and most vendors put together a recommended set of things to build with and use. It warns about library pitfalls, kernel changes and what packaging is supported. It is far from perfect and nothing like the LSB goals but its a start and following it does give you applications that with a bit of care run on everything. > > o Vendors not being stupid understand that they have a bigger market > > share if they do that. > Ummm.. I remember Oracle's first release... wasn't it JUST redhat?? I believe so, and Adabas was SuSE only, and I doubt either vendor wanted it that way. Both actually ran fine on the other but were not supported. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
On Thu, 14 Dec 2000, David Riley wrote: > Alexander Viro wrote: > > > > Actually, I suspect that quite a few of us had done that since long - > > IIRC I've got burned on 1.2/1.3 and decided that I had enough. Bugger if I > > remember what exactly it was - ISTR that it was restore(8) built with > > 1.3. headers and playing funny games on 1.2, but it might be > > something else... > > So then what's the correct header tree to put in /usr/include/linux? I > could use the stock 2.2.14-patched headers that came with the dist, but > how often does it need to be updated? Or should I use the latest 2.2? Whatever your libc was built against. It shouldn't matter that much, but when shit hits the fan... you really don't want to be there. Look at it that way: you don't want to build some object files with one set of headers, some - with another and link them together. Now, s/some object files/libc/. With a minimal luck you will be OK, but it's easier not to ask for trouble in the first place. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
Sticking my nose where it doesn't belong... On Thu, 14 Dec 2000, Alan Cox wrote: > > Yes, but 2.96 is also binary incompatible with all non-redhat distro's. > > And since redhat is _the_ distro that commercial entities use to > > release software for, this was very arguably a bad move. > o We tell vendors to build RPMv3 , glibc 2.1.x Curious HOW do you tell vendors?? > o Vendors not being stupid understand that they have a bigger market > share if they do that. Ummm.. I remember Oracle's first release... wasn't it JUST redhat?? -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
Alexander Viro wrote: > > Actually, I suspect that quite a few of us had done that since long - > IIRC I've got burned on 1.2/1.3 and decided that I had enough. Bugger if I > remember what exactly it was - ISTR that it was restore(8) built with > 1.3. headers and playing funny games on 1.2, but it might be > something else... So then what's the correct header tree to put in /usr/include/linux? I could use the stock 2.2.14-patched headers that came with the dist, but how often does it need to be updated? Or should I use the latest 2.2? -- "Windows for Dummies? Isn't that redundant?" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
On Fri, 15 Dec 2000, Alan Cox wrote: > > >Which works because in a normal compile environment they have /usr/include > > >in their include path and /usr/include/linux points to the directory > > >under /usr/src/linux/include. > > > > No, that a redhat-ism. > > Umm, its a most people except Debianism. People relied on it despite it > being wrong. RH7 ships with a matching library set of headers. I got to close > a lot of bug reports explaining to people that the new setup was in fact > right 8( Actually, I suspect that quite a few of us had done that since long - IIRC I've got burned on 1.2/1.3 and decided that I had enough. Bugger if I remember what exactly it was - ISTR that it was restore(8) built with 1.3. headers and playing funny games on 1.2, but it might be something else... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Netfilter is broken (was Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback))
On Thu, Dec 14, 2000 at 04:11:10PM -0800, David S. Miller wrote: >Date: Fri, 15 Dec 2000 01:20:00 +0100 >From: Harald Welte <[EMAIL PROTECTED]> > >Or is there something wrong with: > >- packet arrives in net/ipv4/ip_input.c:ip_rcv() >- netfilter hook NF_IP_PRE_ROUTING is called >- net/ipv4/netfilter/ip_conntrack_core.c:ip_conntrack_in() is called >- net/ipv4/netfilter/ip_conntrack_core.c:ip_ct_gather_frags() is called >- net/ipv4/ip_input.c:ip_defrag() is called > >Isn't the skb->dev member supposed to still point to the receiving >device? > > No, once you submit the packet to the defrag layer, that SKB > instance is owned by the defrag layer. > > One way to do what netfilter wants to do, but legally, is to > simply skb_clone() the SKB before passing it into the > defragmentation code. What should it do with the uncloned, not defragmented copy ? It makes not much sense to clone it. Also is it sure that the backtrace involves ip_rcv ? A more likely guess is that it happens during the IP_LOCAL_OUT hook, when skb->dev isn't set yet, but conntrack already has to already reassemble fragments. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
In article <[EMAIL PROTECTED]>, Alan Cox <[EMAIL PROTECTED]> wrote: >> Yes, but 2.96 is also binary incompatible with all non-redhat distro's. >> And since redhat is _the_ distro that commercial entities use to >> release software for, this was very arguably a bad move. > >Except you conveniently ignore a few facts Doesn't everyone. I should have included a smiley with as comment that I was only half-joking. Anyway this is the kernel list, and as such this is becoming off-topic. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
In article <[EMAIL PROTECTED]>, Alexander Viro <[EMAIL PROTECTED]> wrote: >On 15 Dec 2000, Miquel van Smoorenburg wrote: > >> In article <[EMAIL PROTECTED]>, >> LA Walsh <[EMAIL PROTECTED]> wrote: >> >Which works because in a normal compile environment they have /usr/include >> >in their include path and /usr/include/linux points to the directory >> >under /usr/src/linux/include. >> >> No, that a redhat-ism. > >Not even all versions of redhat do that. If that has been fixed recently, that is a very Good Thing (tm). Now if in 2.5 /include/net would be moved to /linux/net so that user-level code that uses can be compiled with -I/usr/src/some/kernel/42.42/include/ I'd be even happier Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
> >Which works because in a normal compile environment they have /usr/include > >in their include path and /usr/include/linux points to the directory > >under /usr/src/linux/include. > > No, that a redhat-ism. Umm, its a most people except Debianism. People relied on it despite it being wrong. RH7 ships with a matching library set of headers. I got to close a lot of bug reports explaining to people that the new setup was in fact right 8( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
> Yes, but 2.96 is also binary incompatible with all non-redhat distro's. > And since redhat is _the_ distro that commercial entities use to > release software for, this was very arguably a bad move. Except you conveniently ignore a few facts o Someone else moved to 2.95 not RH . In fact some of us felt 2.95 wasnt fit to ship at the time. o We tell vendors to build RPMv3 , glibc 2.1.x o Vendors not being stupid understand that they have a bigger market share if they do that. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Netfilter is broken (was Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback))
Date: Fri, 15 Dec 2000 01:20:00 +0100 From: Harald Welte <[EMAIL PROTECTED]> Or is there something wrong with: - packet arrives in net/ipv4/ip_input.c:ip_rcv() - netfilter hook NF_IP_PRE_ROUTING is called - net/ipv4/netfilter/ip_conntrack_core.c:ip_conntrack_in() is called - net/ipv4/netfilter/ip_conntrack_core.c:ip_ct_gather_frags() is called - net/ipv4/ip_input.c:ip_defrag() is called Isn't the skb->dev member supposed to still point to the receiving device? No, once you submit the packet to the defrag layer, that SKB instance is owned by the defrag layer. One way to do what netfilter wants to do, but legally, is to simply skb_clone() the SKB before passing it into the defragmentation code. I'm still deciding whether this is the best fix. 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] Please read the FAQ at http://www.tux.org/lkml/
Re: ORBit speed measure
On Thu, Dec 14, 2000 at 03:44:01PM -0600, Mike Castle wrote: > Then again, isn't Jim some how involved in ORBit and GNOME? Or just a big > supporter? :-> Jim works on XFree86 (among other things). So yes, he is indeed *somehow* involved in GNOME ;-) Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: D-LINK DFE-530-TX [patch]
On Wed, 13 Dec 2000, Alan Cox wrote: > > > > Becker's site http://www.scyld.com/network. > > > 2.4.x-test has some fixes for via-rhine which don't appear to have made > > > it into the Becker driver yet... > > > > Is either of these likely to make it into the stock 2.2 via-rhine? > > If someone ports them over for an earlyish 2.2.19pre Your wish ... Below a patch that updates the 2.2 via-rhine driver from Becker's 1.08b, except for the pci probing that is unchanged, compatibility macros and dead code that are not needed in 2.2 removed (removing ifdef CARDBUS is from 1.08b) and "clear_tally_counters" from 2.4. It would be nice if people using 2.2 and one of these cards could test this too. Patch includes: + new VT6102 pci id & supporting non-aligned data buffers for that chip + completely untested (by me, that is) big<->little endian stuff + free allocated memory on driver unload + no more writel to 0x7c. + 2 16bit values accessed as one 32bit (why? not sure, pci optimization?) + change transmit ring size and some other more or less minor changes/cleanups. This is mostly a copy operation. If you'd rather get a smaller change for just supporting the VT6102 that is easy to do. However, this is very similar to the 2.4 driver (locking is a major diff) so I hope it is ok. Also, if I don't include most of the 1.08b driver I'm not sure what version name to give it ... :) /Urban diff -ur -X exclude linux-2.2.18-orig/drivers/net/via-rhine.c linux/drivers/net/via-rhine.c --- linux-2.2.18-orig/drivers/net/via-rhine.c Wed Dec 13 21:27:37 2000 +++ linux/drivers/net/via-rhine.c Fri Dec 15 00:03:59 2000 @@ -1,35 +1,44 @@ /* via-rhine.c: A Linux Ethernet device driver for VIA Rhine family chips. */ /* - Written 1998-1999 by Donald Becker. + Written 1998-2000 by Donald Becker. - This software may be used and distributed according to the terms - of the GNU Public License (GPL), incorporated herein by reference. - Drivers derived from this code also fall under the GPL and must retain - this authorship and copyright notice. + This software may be used and distributed according to the terms of + the GNU General Public License (GPL), incorporated herein by reference. + Drivers based on or derived from this code fall under the GPL and must + retain the authorship, copyright and license notice. This file is not + a complete program and may only be used when the entire operating + system is licensed under the GPL. This driver is designed for the VIA VT86c100A Rhine-II PCI Fast Ethernet controller. It also works with the older 3043 Rhine-I chip. - The author may be reached as [EMAIL PROTECTED], or - Donald Becker - 312 Severn Ave. #W302 + The author may be reached as [EMAIL PROTECTED], or C/O + Scyld Computing Corporation + 410 Severn Ave., Suite 210 Annapolis MD 21403 Support and updates available at - http://cesdis.gsfc.nasa.gov/linux/drivers/via-rhine.html + http://www.scyld.com/network/via-rhine.html + + + Linux kernel version history: + + LK1.0.0: + - Urban Widmark: merges from Beckers 1.08b version and 2.4.0 (VT6102) */ -static const char *versionA = -"via-rhine.c:v1.01 2/27/99 Written by Donald Becker\n"; -static const char *versionB = -" http://cesdis.gsfc.nasa.gov/linux/drivers/via-rhine.html\n"; +/* These identify the driver base version and may not be removed. */ +static const char version1[] = +"via-rhine.c:v1.08b-LK1.0.0 12/14/2000 Written by Donald Becker\n"; +static const char version2[] = +" http://www.scyld.com/network/via-rhine.html\n"; -/* A few user-configurable values. These may be modified when a driver - module is loaded.*/ +/* The user-configurable values. + These may be modified when a driver module is loaded.*/ static int debug = 1; /* 1 normal messages, 0 quiet .. 7 verbose. */ static int max_interrupt_work = 20; -static int min_pci_latency = 64; +static int min_pci_latency = 32; /* Set the copy breakpoint for the copy-only-tiny-frames scheme. Setting to > 1518 effectively disables this feature. */ @@ -55,7 +64,8 @@ Making the Tx ring too large decreases the effectiveness of channel bonding and packet priority. There are no ill effects from too-large receive rings. */ -#define TX_RING_SIZE 8 +#define TX_RING_SIZE 16 +#define TX_QUEUE_LEN 10 /* Limit ring entries actually used. */ #define RX_RING_SIZE 16 /* Operational parameters that usually are not changed. */ @@ -64,9 +74,15 @@ #define PKT_BUF_SZ 1536/* Size of each temporary Rx buffer.*/ + +#if !defined(__OPTIMIZE__) +#warning You must compile this file with the correct options! +#warning See the last lines of the source file. +#error You must compile this driver with "-O". +#endif + #include #include -#include #include
Re: Netfilter is broken (was Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback))
On Thu, Dec 14, 2000 at 11:55:43AM -0800, David S. Miller wrote: >Date: Thu, 14 Dec 2000 12:07:38 -0800 (PST) >From: Ion Badulescu <[EMAIL PROTECTED]> > >I'm afraid I won't be able to answer this question, since I'm >leaving for a 3-week vacation in about 50 minutes and I need my >firewall functional until then. :-) Maybe other people who have >seen this problem can experiment further. > > Ok, regardless I'm very confident netfilter is doing something > very bad. > > Essentially it is feeding SKBs into IPv4 receive processing which > have a NULL skb->dev, that has always been illegal. Now it OOPSs > so we can spot such violations. mmh... After checking some of my assumptions with the code again, I don't think that netfilter does something wrong. Referring to some of the other messages in this thread, ip_conntrack seems to be blamed. Conntrack is registered at the NF_IP_PRE_ROUTING hook and calls ip_defrag for all skb's it receives. But we don't touch the dev member of the skb at all... Or is there something wrong with: - packet arrives in net/ipv4/ip_input.c:ip_rcv() - netfilter hook NF_IP_PRE_ROUTING is called - net/ipv4/netfilter/ip_conntrack_core.c:ip_conntrack_in() is called - net/ipv4/netfilter/ip_conntrack_core.c:ip_ct_gather_frags() is called - net/ipv4/ip_input.c:ip_defrag() is called Isn't the skb->dev member supposed to still point to the receiving device? > David S. Miller -- Live long and prosper - Harald Welte / [EMAIL PROTECTED]http://www.gnumonks.org GCS/E/IT d- s-: a-- 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+(*) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
On Thu, 14 Dec 2000, Stephen Frost wrote: > * Linus Torvalds ([EMAIL PROTECTED]) wrote: > > > > A 100ms delay sounds like some interrupt shut up or similar (and then > > timer handling makes it limp along). > > Hmm, it's happening on all interfaces. Ok, never mind me then. It's not an interrupt getting masked, the likelihood of three different interrupts having trouble is basically zero (it would be even smaller if it wasn't for the fact that they are all the same typ eof device and are all handled by the same driver - but there shouldn't be any shared data even so). > No oops or anything in > the logs/dmesg. I can check console when I get home, but I doubt there's > anything of interest. If dmesg doesn't say anything, then the console will say even less. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
* Linus Torvalds ([EMAIL PROTECTED]) wrote: > > > On Thu, 14 Dec 2000, Stephen Frost wrote: > > > > This go around I compiled everything into the kernel, actually. > > If it would be useful I can compile them as modules reboot and then see > > what happens... > > Even when compiled into the kernel, you might just ifdown/ifup the device. > That will re-initialize most of the driver state. I'll give that a shot... ifdown -a/ifup -a, no change in behaviour. > Is this ppp over serial.c, or what? There is a ppp connection, but the slowdown is on *all* interfaces, of which there are a total of 4; eth0, eth1, eth2, ppp0. Stephen PGP signature
Re: Linus's include file strategy redux
On Thu, 14 Dec 2000, LA Walsh wrote: > So I ran into a snag with that scenario. Let's suppose we have > a module developer or a company developing a driver in their own > /home/nvidia/video/drivers/newcard directory. Now they need to include > kernel > development files and are used to just doing the: > #include > > Which works because in a normal compile environment they have /usr/include > in their include path and /usr/include/linux points to the directory > under /usr/src/linux/include. Huh? % ls -ld /usr/include/linux drwxr-xr-x6 root root18432 Sep 2 22:35 /usr/include/linux/ > So if we create a separate /usr/src/linux/include/kernel dir, does that > imply that we'll have a 2nd link: What 2nd link? There should be _no_ links from /usr/include to the kernel tree. Period. Case closed. Stuff in /usr/include is private libc copy extracted from some kernel version. Which may have _nothing_ to the kernel you are developing for. In the situation above they should have -I/include in CFLAGS. Always had to. No links, no pain in ass, no interference with userland compiles. IOW, let them fix their Makefiles. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linus's include file strategy redux
On 15 Dec 2000, Miquel van Smoorenburg wrote: > In article <[EMAIL PROTECTED]>, > LA Walsh <[EMAIL PROTECTED]> wrote: > >Which works because in a normal compile environment they have /usr/include > >in their include path and /usr/include/linux points to the directory > >under /usr/src/linux/include. > > No, that a redhat-ism. Not even all versions of redhat do that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
* Linus Torvalds ([EMAIL PROTECTED]) wrote: > > > On Thu, 14 Dec 2000, Stephen Frost wrote: > > > > Any idea if these issues would cause a general slow-down of a > > machine? For no apparent reason after 5 days running 2.4.0test12 > > everything going through my firewall (set up using iptables) I got about > > 100ms time added on to pings and traceroutes. > > Probably not related to that particular bug - the netfilter issue has > apparently been around forever, and it was just some changes in IP > fragmentation that just made it show up as an oops. > > A 100ms delay sounds like some interrupt shut up or similar (and then > timer handling makes it limp along). Hmm, it's happening on all interfaces. No oops or anything in the logs/dmesg. I can check console when I get home, but I doubt there's anything of interest. All cards are 3com 3c905's. Does this info help any? ===# cat /proc/interrupts CPU0 CPU1 0: 29170703 23315160IO-APIC-edge timer 1: 2 0IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 3: 258815 247131IO-APIC-edge serial 4:101120IO-APIC-edge serial 5:17480961692143 IO-APIC-level usb-uhci, eth0 8: 1 0IO-APIC-edge rtc 10:11992271146776 IO-APIC-level eth2 12:23672392389531 IO-APIC-level eth1 14: 210804 193050IO-APIC-edge ide0 15: 7052 6391IO-APIC-edge ide1 NMI: 52509191 52509191 LOC: 52472090 52472489 ERR: 0 ===# sleep 10 ===# cat /proc/interrupts CPU0 CPU1 0: 29171536 23315741IO-APIC-edge timer 1: 2 0IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 3: 258818 247134IO-APIC-edge serial 4:101120IO-APIC-edge serial 5:17482951692372 IO-APIC-level usb-uhci, eth0 8: 1 0IO-APIC-edge rtc 10:11992301146777 IO-APIC-level eth2 12:23672442389534 IO-APIC-level eth1 14: 210833 193050IO-APIC-edge ide0 15: 7052 6391IO-APIC-edge ide1 NMI: 52510605 52510605 LOC: 52473504 52473902 ERR: 0 ===# Boot log: Linux version 2.4.0-test12 (root@whitegryphon) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #1 SMP Wed Dec 6 01:53:29 EST 2000 BIOS-provided physical RAM map: BIOS-e820: 000a @ (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0fefd000 @ 0010 (usable) BIOS-e820: 2000 @ 0fffd000 (ACPI data) BIOS-e820: 1000 @ 0000 (ACPI NVS) BIOS-e820: 1000 @ fec0 (reserved) BIOS-e820: 1000 @ fee0 (reserved) BIOS-e820: 0001 @ (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. found SMP MP-table at 000f6e80 hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f7000 reserved twice. On node 0 totalpages: 65533 zone(0): 4096 pages. zone(1): 61437 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #1 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. Bootup CPU Processor #0 Pentium(tm) Pro APIC version 17 Floating point unit present. Machine Exception supported. 64 bit compare & exchange supported. Internal APIC present. SEP present. MTRR present. PGE present. MCA present. CMOV present. PAT present. PSE present. MMX present. FXSR present. Bus #0 is PCI Bus #1 is ISA I/O APIC #2 Version 17 at 0xFEC0. Int: type 3, pol 0, trig 0, bus 1, IRQ 00, APIC ID 2, APIC INT 00 Int: type 0, pol 0, trig 0, bus 1, IRQ 01, APIC ID 2, APIC INT 01 Int: type 0, pol 0, trig 0, bus 1, IRQ 00, APIC ID 2, APIC INT 02 Int: type 0, pol 0, trig 0, bus 1, IRQ 03, APIC ID 2, APIC INT 03 Int: type 0, pol 0, trig 0, bus 1, IRQ 04, APIC ID 2, APIC INT 04 Int: type 0, pol 0, trig 0, bus 1, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 0, trig 0, bus 1, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 0, trig 0, bus 1, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 0, trig 0, bus 1, IRQ 09, APIC ID 2, APIC INT 09 Int: type 0, pol 0, trig 0, bus 1, IRQ 0e, APIC ID 2, APIC INT 0e Int: type 0, pol 0, trig 0, bus 1, IRQ 0f, APIC ID 2, APIC INT 0f Int: type 0, pol
Re: Linus's include file strategy redux
In article <[EMAIL PROTECTED]>,
LA Walsh <[EMAIL PROTECTED]> wrote:
>Which works because in a normal compile environment they have /usr/include
>in their include path and /usr/include/linux points to the directory
>under /usr/src/linux/include.
No, that a redhat-ism.
Sane distributions simply include a known good copy of
/usr/src/linux/include/{asm,linux} verbatim in their libc6-dev package.
Debian has done that for a long, long time.
Several core glibc developers use Debian, are even Debian developers...
Mike.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
I had tons of problems with K6III/450s in ASUS P5A motherboards with various kinds of 128MB SIMMs. There were multiple different symptoms, including just sig11s on compiles, corrupted input (leading to syntax error) in compiles, and corrupted input in the buffer cache (same crash over and over, but dd if=/dev/hda of=/dev/null bs=1024k count=128 fixed it). Swapping the memory would sometimes get rid of the problem, but then it would come back weeks-months later. I saw a bizzare problem once in an Tyan dual proc PIII/500 box with 2x256MB ECC RAM that one of the ECC RAM sticks was bad and that repeated kernel compiles would hang after about 24 hours. Strange problem, but found that in troubleshooting it, the problem followed this stick of RAM around to different machines. Blamed the RAM but don't understand what the underlying problem was... On Fri, 8 Dec 2000 [EMAIL PROTECTED] wrote: > On Thu, 7 Dec 2000, Jeff V. Merkey wrote: > > > It's related to some change in 2.4 vs. 2.2. There are other programs > > affected other than X, SSH also get's spurious signal 11's now and again > > with 2.4 and glibc <= 2.1 and it does not occur on 2.2. > > > > I've begun to get a bit paranoid about my K6-2 500 box. > > Various processes have been getting random signals after heavy CPU usage. > Playing an MPEG movie, kernel compile, or even just some small apps > compiling sometimes. Just for the record, this isn't an OOM situation, > I've watched this box with half its memory free or in buffers left > unattended, and suddenly a compile will just die. > > I replaced the CPU with a brand new K6-2. Problem remained. > Next suspect was faulty RAM. Despite having passed a memtest, I > swapped out the DIMMs for some known good ones. > Suspecting cooling problems, I added some case fans. > Next came a bigger power supply. Still the problems. > The latest last ditch attempt to make this box stable has been > to attach the biggest fan I could find that would fit a socket 7 CPU. > > And still the problems are there. > The only remaining suspect would be a flaky motherboard. > But then comes the real killer : This box is rock solid under 2.2 > > *boggle* > > I'm not sure exactly when this started, but I think I first noticed > it around test5 or so, but didn't suspect the kernel at the time. > > I've tried kernels compiled with everything from 2.91.66 when this > was a Redhat box, to gcc 2.95.2 (from Debian woody) when I installed > debian on it. If this is a compiler bug, it's one that no compiler > I've tried seems to be immune from. > > regards, > > Davej. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PATCH: fix FAT32 filesystems on 64-bit platforms
This fixes FAT32 on 64-bit platforms (notably, IA-64 and Alpha);
without this you can't mount any FAT32 filesystems. A similar patch
is already in 2.2.18.
Bill
--- linux/fs/fat/cache.c.fooSat Nov 25 16:30:47 2000
+++ linux/fs/fat/cache.cSat Nov 25 16:32:29 2000
@@ -70,7 +70,7 @@
}
if (MSDOS_SB(sb)->fat_bits == 32) {
p_first = p_last = NULL; /* GCC needs that stuff */
- next = CF_LE_L(((unsigned long *) bh->b_data)[(first &
+ next = CF_LE_L(((__u32 *) bh->b_data)[(first &
(SECTOR_SIZE-1)) >> 2]);
/* Fscking Microsoft marketing department. Their "32" is 28. */
next &= 0xfff;
@@ -79,12 +79,12 @@
} else if (MSDOS_SB(sb)->fat_bits == 16) {
p_first = p_last = NULL; /* GCC needs that stuff */
- next = CF_LE_W(((unsigned short *) bh->b_data)[(first &
+ next = CF_LE_W(((__u16 *) bh->b_data)[(first &
(SECTOR_SIZE-1)) >> 1]);
if (next >= 0xfff7) next = -1;
} else {
- p_first = &((unsigned char *) bh->b_data)[first & (SECTOR_SIZE-1)];
- p_last = &((unsigned char *) bh2->b_data)[(first+1) &
+ p_first = &((__u8 *) bh->b_data)[first & (SECTOR_SIZE-1)];
+ p_last = &((__u8 *) bh2->b_data)[(first+1) &
(SECTOR_SIZE-1)];
if (nr & 1) next = ((*p_first >> 4) | (*p_last << 4)) & 0xfff;
else next = (*p_first+(*p_last << 8)) & 0xfff;
@@ -92,10 +92,10 @@
}
if (new_value != -1) {
if (MSDOS_SB(sb)->fat_bits == 32) {
- ((unsigned long *) bh->b_data)[(first & (SECTOR_SIZE-1)) >>
+ ((__u32 *) bh->b_data)[(first & (SECTOR_SIZE-1)) >>
2] = CT_LE_L(new_value);
} else if (MSDOS_SB(sb)->fat_bits == 16) {
- ((unsigned short *) bh->b_data)[(first & (SECTOR_SIZE-1)) >>
+ ((__u16 *) bh->b_data)[(first & (SECTOR_SIZE-1)) >>
1] = CT_LE_W(new_value);
} else {
if (nr & 1) {
Re: Signal 11
In article <[EMAIL PROTECTED]>, Bernhard Rosenkraenzer <[EMAIL PROTECTED]> wrote: >The same thing is true of *any* gcc release. >For example, C++-ABI wise, 2.95.x is incompatible BOTH with egcs 1.1.x >_and_ the upcoming 3.0 release. Yes, but 2.96 is also binary incompatible with all non-redhat distro's. And since redhat is _the_ distro that commercial entities use to release software for, this was very arguably a bad move. There's simply no excuse. It's too obvious. Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
On Thu, 14 Dec 2000, Stephen Frost wrote: > > This go around I compiled everything into the kernel, actually. > If it would be useful I can compile them as modules reboot and then see > what happens... Even when compiled into the kernel, you might just ifdown/ifup the device. That will re-initialize most of the driver state. Is this ppp over serial.c, or what? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Non-Blocking socket (SOCK_STREAM send)
On Thu, Dec 14, 2000 at 03:54:16PM -0800, Adam Scislowicz wrote: > > From your subject you seem not to. > > > Im sorry for the subject I just wanted to give the environmental factors, and it is a > non-blocking socket. At this point I am not sure if that is relavent or not. > > > To the best of my knowledge the receiver side EPIPE reporting has not changed, > > so it must be something in the sender that causes it to close the connection > > earlier. What you have to find out. > > > We simply rerun the same binary in the same environment, first with 2.2.x, and then > with 2.4.x. We have verified that socket(), and connect() calls are successfull, and > all of our problems arise when we go to send(). > We do not send() until our main select() loop sets the writeable flag on our socket > descriptor, so our problem should not be related to a pre-mature send(). > I dont expect this to be a kernel bug, but I was hopeing from the pseudo-code I >posted > to get a "you are doing this wrong" response. It is hard to be sure with a tcpdump log of the incident. If you send me one I'll look at it. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
* Alan Cox ([EMAIL PROTECTED]) wrote: > > machine? For no apparent reason after 5 days running 2.4.0test12 > > everything going through my firewall (set up using iptables) I got about > > 100ms time added on to pings and traceroutes. I'll probably reboot the > > machine tonight and see if that helps. > > Before you do that can you see if ifconfig down, rmmod, insmod, ifconfig up > fixes it. This go around I compiled everything into the kernel, actually. If it would be useful I can compile them as modules reboot and then see what happens... ===# cat /proc/modules ppp_deflate39200 0 (autoclean) bsd_comp4160 0 (autoclean) ppp_async 6512 1 (autoclean) ppp_generic15232 3 (autoclean) [ppp_deflate bsd_comp ppp_async] slhc4528 0 (autoclean) [ppp_generic] ===# I can say that cleaning out all my firewall rules and adding them back didn't change behaviour any. Also, I'm sure that this was not happening until today or maybe yesterday. Earlier in the week the machine was doing fine and I was getting reasonable response times. Now, out *every* interface, I get something close to 100ms additional time. Also of note, traceroutes appear to be more lagged than pings, for what that's worth (traceroute using udp, ping using icmp, dunno if it makes a difference). Stephen PGP signature
Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
Problem only happens when ip_conntrack is loaded. On Thu, 14 Dec 2000, Mohammad A. Haque wrote: > I do the following > > sudo modprobe iptable_nat > > Module Size Used by > iptable_nat17440 0 (unused) > ip_conntrack 19808 1 [iptable_nat] > ip_tables 12320 3 [iptable_nat] > > > Oops start flying by when I access via NFS. > > If you need the actual Oops messages we're gonna have to get someone > who can setup a serial console. > -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Linus's include file strategy redux
So, I brought up the idea of a linux/sys for kernel level include files. A few other people came up with a desire of a 'kernel' dir under include, parallel w/linux. So I ran into a snag with that scenario. Let's suppose we have a module developer or a company developing a driver in their own /home/nvidia/video/drivers/newcard directory. Now they need to include kernel development files and are used to just doing the: #include Which works because in a normal compile environment they have /usr/include in their include path and /usr/include/linux points to the directory under /usr/src/linux/include. So if we create a separate /usr/src/linux/include/kernel dir, does that imply that we'll have a 2nd link: /usr/include/kernel ==> /usr/src/linux/include/kernel ? If the idea was to 'hide' kernel interfaces and make them not 'easy' to include doesn't providing a 2nd link defeat that? If we don't provide a 2nd link, how do module writers access kernel includes? If the kernel directory is under 'linux' (as in linux/sys), then the link is already there and we can just say 'don't use sys in apps'. If we create 'kernel' under 'include', it seems we'll still end up having to tell users "don't include files under directory "x"' (either kernel/ or linux/sys/) Note that putting kernel as a new directory parallel to linux requires adding another symlink -- so is that solving anything or adding more administrative "gotcha's"? -linda -- L A Walsh| Trust Technology, Core Linux, SGI [EMAIL PROTECTED] | Voice/Vmail: (650) 933-5338 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
On Thu, 14 Dec 2000, Stephen Frost wrote: > > Any idea if these issues would cause a general slow-down of a > machine? For no apparent reason after 5 days running 2.4.0test12 > everything going through my firewall (set up using iptables) I got about > 100ms time added on to pings and traceroutes. Probably not related to that particular bug - the netfilter issue has apparently been around forever, and it was just some changes in IP fragmentation that just made it show up as an oops. A 100ms delay sounds like some interrupt shut up or similar (and then timer handling makes it limp along). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Non-Blocking socket (SOCK_STREAM send)
> From your subject you seem not to. > Im sorry for the subject I just wanted to give the environmental factors, and it is a non-blocking socket. At this point I am not sure if that is relavent or not. > To the best of my knowledge the receiver side EPIPE reporting has not changed, > so it must be something in the sender that causes it to close the connection > earlier. What you have to find out. > We simply rerun the same binary in the same environment, first with 2.2.x, and then with 2.4.x. We have verified that socket(), and connect() calls are successfull, and all of our problems arise when we go to send(). We do not send() until our main select() loop sets the writeable flag on our socket descriptor, so our problem should not be related to a pre-mature send(). I dont expect this to be a kernel bug, but I was hopeing from the pseudo-code I posted to get a "you are doing this wrong" response. Again, everything is working in 2.2.x, but not in 2.4.x. It may be that our coding error is only expressed in combination with the 2.4.x kernel, thats why I asked in this mailing list. > No system call ever sets errno = 0. Oh, something else in our system was doing this then. Thanx for the info. -Adam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
On Thu, 14 Dec 2000, Jakub Jelinek wrote: > On Thu, Dec 14, 2000 at 11:11:28AM -0800, Linus Torvalds wrote: > > user applications and (b) gcc-2.96 is so broken that it requires special > > libraries for C++ vtable chunks handling that is different, so the > > _working_ gcc can only be used with programs that do not need such > > library support. > > Every major g++ release had incompatible libstdc++, even g++ 2.95.2 if > bootstrapped under glibc 2.1.x is binary incompatible with g++ 2.95.2 > bootstrapped under glibc 2.2.x (libstdc++ uses different soname then; > even if we used g++ 2.95.2 we would not have C++ binary compatible with > other distributions). Yes. And I realize that somebody inside RedHat really wanted to use a snapshot in order to get some C++ code to compile right. But it at the same time threw C stability out the window, by using a not-very-widely-tested snapshot for a major new release. Are you seriously saying that you think it was a good trade-off? Or are you just ashamed of admitting that RH did something stupid? > > compiler to something that works better RSN. It apparently has problems > > compiling stuff like the CVS snapshots of X etc too (and obviously, > > anything you compile under gcc-2.96 is not likely to work anywhere else > > except with the broken libraries). > > Can you point to things in X which were actually miscompiled because of bugs > in gcc 2.96? I have a report from a Sony VAIO user that couldn't compile the CVS X at all on his picturebook (and you need to compile the CVS tree in order to get required fixes for the ATI Rage Mobility in that machine). I don't know the details, but they were apparently due to RH 7 issues. > So far I was aware about X bugs (already fixed in X CVS) which > were triggered with -fstrict-aliasing which is now the default while > gcc 2.95.2 had -fstrict-aliasing disabled by default. I hope that's another thing that the gcc people fix by the time they do a _real_ release. Anobody who thinks that "-fstrict-aliasing" being on by default is a good idea is probably a compiler person who hasn't seen real code. > That is not to say there were not bugs in the gcc we shipped, but the bugs > which were reported against it have been fixed already. That's good. It's even better if you don't play quite as fast-and-lose with your shipping compiler. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
> machine? For no apparent reason after 5 days running 2.4.0test12 > everything going through my firewall (set up using iptables) I got about > 100ms time added on to pings and traceroutes. I'll probably reboot the > machine tonight and see if that helps. Before you do that can you see if ifconfig down, rmmod, insmod, ifconfig up fixes it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
* Linus Torvalds ([EMAIL PROTECTED]) wrote: > > Especially if we get that netfilter problem sorted out (see the other > thread about the IP fragmentation issues associated with that one), and > if we figure out why apparently some people have trouble with external > modules (at least one person has trouble with loading alsa modules). Any idea if these issues would cause a general slow-down of a machine? For no apparent reason after 5 days running 2.4.0test12 everything going through my firewall (set up using iptables) I got about 100ms time added on to pings and traceroutes. I'll probably reboot the machine tonight and see if that helps. Stephen PGP signature
Re: Signal 11
On Thu, Dec 14, 2000 at 11:11:28AM -0800, Linus Torvalds wrote: > user applications and (b) gcc-2.96 is so broken that it requires special > libraries for C++ vtable chunks handling that is different, so the > _working_ gcc can only be used with programs that do not need such > library support. Every major g++ release had incompatible libstdc++, even g++ 2.95.2 if bootstrapped under glibc 2.1.x is binary incompatible with g++ 2.95.2 bootstrapped under glibc 2.2.x (libstdc++ uses different soname then; even if we used g++ 2.95.2 we would not have C++ binary compatible with other distributions). This will change once 3.0 is out, but it will still take some time. > compiler to something that works better RSN. It apparently has problems > compiling stuff like the CVS snapshots of X etc too (and obviously, > anything you compile under gcc-2.96 is not likely to work anywhere else > except with the broken libraries). Can you point to things in X which were actually miscompiled because of bugs in gcc 2.96? So far I was aware about X bugs (already fixed in X CVS) which were triggered with -fstrict-aliasing which is now the default while gcc 2.95.2 had -fstrict-aliasing disabled by default. That is not to say there were not bugs in the gcc we shipped, but the bugs which were reported against it have been fixed already. Jakub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: NFS v2 attribute problem with 2.2.18?
On Tue, Dec 12, 2000 at 12:03:35PM +0100, Jens-Uwe Mager wrote: > ramses$ /bin/mkdir yyy; /bin/touch yyy/xxx > /bin/touch: yyy/xxx: Permission denied I've had similar problems with previous kernels, altough not at the same situation. If I try to touch a file which is on NFS mounted directory, I get "Permission denied" despite group I belong to has full access to this file. I can edit and remove the file with no problems, but touch doesn't work. This is rather tricky situation, as compiling code gets quite difficult for this group, as only the owned can touch the file despite the effective permissions on file (and previous directories). -Tuoppi- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Non-Blocking socket (SOCK_STREAM send)
On Thu, Dec 14, 2000 at 03:26:53PM -0800, Adam Scislowicz wrote: > We understand the meaning of EPIPE, the question is why 2.4.x is returning EPIPE, > while 2.2.x is succeeding in sending > the data to thttpd. Using the 2.2.x kernel our proxy functions, and I can access > thttpd directly. In 2.4.x I can access thttpd >From your subject you seem not to. To the best of my knowledge the receiver side EPIPE reporting has not changed, so it must be something in the sender that causes it to close the connection earlier. What you have to find out. > I have already noticed that the 2.4.x kernel does not set errno = 0 in many places > where the 2.2.x kernel did, so there are > differences. No system call ever sets errno = 0. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
In article <[EMAIL PROTECTED]>, David Riley <[EMAIL PROTECTED]> wrote: >Did I miss a post from Linus on the list, or is there no posted >changelog for test13-pre1? Nothing's posted at kernel.org yet, either. The test13-pre1 changes are almost exclusively a radical Makefile cleanup, and it's been discussed mainly on the kbuild mailing list. It doesn't actually contain any actual _code_ changes apart from some very minor details (one of which was the "swapoff()" fix, but I doubt "swapoff()" not working is all that big of an issue) I'm hoping that most of the fall-out from switching over exclusively to the new-style Makefiles will be over in a day or two, at which point I'll make a pre2 that is worth announcing. Especially if we get that netfilter problem sorted out (see the other thread about the IP fragmentation issues associated with that one), and if we figure out why apparently some people have trouble with external modules (at least one person has trouble with loading alsa modules). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Non-Blocking socket (SOCK_STREAM send)
We understand the meaning of EPIPE, the question is why 2.4.x is returning EPIPE, while 2.2.x is succeeding in sending the data to thttpd. Using the 2.2.x kernel our proxy functions, and I can access thttpd directly. In 2.4.x I can access thttpd directly but the proxy does not function. I have already noticed that the 2.4.x kernel does not set errno = 0 in many places where the 2.2.x kernel did, so there are differences. -Adam Andi wrote: > EPIPE means that the other end or you have closed the connection. It has nothing > to do with the socket's non blockingness. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
> If you ask any gcc folks, the main reason they think this was a really > stupid thing to do was exactly that the 2.96 thing is incompatible BOTH > with the 2.95.x release _and_ the upcoming 3.0 release. And with egcs 1.1.2. So egcs is a different format to all others 2.95 is a different format to all others 2.96 is a different format to all others and 2.96 is a C++ compiler > gcc-2.95.2 is at least a real release, from a branch that is actively > maintained - so a 2.95.3 is likely to happen reasonably soon, fixing as > many problems as possible _without_ being incompatible like the snapshots > are. The 2.96 tree is maintained actively. Updates for the Red Hat 7 packages are being worked on and CygnusHat people are working on both that maintenance and on feeding all they find back to the core gcc team. In fact we have sufficient faith in it we sell packages and support based around that and our preparedness to support it. > As to X compile problems - neither egcs nor 2.95.2 appears to have any > trouble with the CVS tree. Possibly because they got fixed, because, after > all, at least those were real releases. I asked Jakub. He's confused as to your report. As far as he is aware the only X problems in the CVS tree were related to XFree86 source code bugs misusing type punning. If you have a case to lookat Jakub would love to hear about it and fix either X or gcc. > I'd applaud RedHat for making snapshots available, but they should be > marked as SNAPSHOTS, and not as the main compiler with no way to fix the > damn problems it causes. That it was confusing and mistaken by some as an official GNU group release is something we never intended and have already apologised for. It was done without malice or ill intent. > As it is, anybody doing development is probably better off at RH-6.2. > That is doubly true if they intend to release binaries. We strongly recommend that people use 6.2 for developing binaries for general release unless they have specific requirements for glibc 2.2. Thats the same guidelines the LSB 'oops we havent finished yet here is a quickie for now' documentation recommends. Similarly RPM packaging using RPMv3 is recommended. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Non-Blocking socket (SOCK_STREAM send)
On Thu, Dec 14, 2000 at 03:12:27PM -0800, Adam Scislowicz wrote:
> Could someone explain why send is failing with EPIPE on the 2.4.x
> kernel, while it is working with the 2.2.x kernels.
>
> The PsuedoCode:
> sock = socket(AF_INET, SOCK_STREAM, 0)
> buf = fcntl(sock, F_GETFL)
> fcntl(sock, F_SETFL, buf | O_NONBLOCK) // we check the SETFL return
> value, it succeeds
> while ((retval = connect(sock, addr, sizeof(struct sockaddr_in))) < 0)
> {
> if (retval < 0) {
>if (errno != EINPROGRESS) return -1; // return failure
> }
> } // the connect succeeds during first iteration with return value of 0.
>
> send(sock, msg, msg_length, 0) // this connection is to the thttpd web
> server on the same host. XXX
> XXX: send fails with EPIPE on the 2.4.0-test11-ac 4 and 2.4.0-test12
> kernels, whereas it does not fail on 2.2.14-5.0(redhat kernel)
EPIPE means that the other end or you have closed the connection. It has nothing
to do with the socket's non blockingness.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Re: VM problems still in 2.2.18
> > I think Andrea just earned his official God status ;) > So, maybe his divine VM patches will make it into 2.2.19? The question is merely 'in what form' . I wanted to keep them seperate from the other large changes in 2.2.18 for obvious reasons. Andrea - can we have the core VM changes you did without adopting the change in semaphore semantics for file system locking which will give third party fs maintainers headaches and doesnt match 2.4 behaviour either ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Non-Blocking socket (SOCK_STREAM send)
Could someone explain why send is failing with EPIPE on the 2.4.x
kernel, while it is working with the 2.2.x kernels.
The PsuedoCode:
sock = socket(AF_INET, SOCK_STREAM, 0)
buf = fcntl(sock, F_GETFL)
fcntl(sock, F_SETFL, buf | O_NONBLOCK) // we check the SETFL return
value, it succeeds
while ((retval = connect(sock, addr, sizeof(struct sockaddr_in))) < 0)
{
if (retval < 0) {
if (errno != EINPROGRESS) return -1; // return failure
}
} // the connect succeeds during first iteration with return value of 0.
send(sock, msg, msg_length, 0) // this connection is to the thttpd web
server on the same host. XXX
XXX: send fails with EPIPE on the 2.4.0-test11-ac 4 and 2.4.0-test12
kernels, whereas it does not fail on 2.2.14-5.0(redhat kernel)
More Info:
thttpd is working properly on the 2.4.x machine, I can access it via
Netscape, our software is a proxy.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Re: VM problems still in 2.2.18
On 2000/12/14 Alan Cox wrote: > > slrnpull --expire on a news-spool of about 600 Mb in 200,000 files gave > > a lot of 'trying_to_free..' errors. > > > > 2.2.18 + VM-global, booted with mem=32M: > > > > slrnpull --expire on the same spool worked fine. > > I think Andrea just earned his official God status ;) > How about a 2.2.19-pre1 == 2.2.18-aa2 ? -- Juan Antonio Magallon Lacarta #> cd /pub mailto:[EMAIL PROTECTED] #> more beer Linux werewolf 2.2.18-aa2 #1 SMP Thu Dec 14 21:22:40 CET 2000 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
On Thu, 14 Dec 2000, Bernhard Rosenkraenzer wrote: > > > > gcc-2.95.2 is at least a real release, from a branch that is actively > > maintained > > Not very actively. > Please take the time to compare the activity in gcc_2_95_branch with the > patches in the current "2.96" version in rawhide. Take a look at the differences in linux-2.2.x and linux-2.3.x. linux-2.3.x is was a h*ll of a lot more "actively maintained". But nobody really considers that to be an argument for RedHat (or anybody else) to installa 2.3.x kernel by default. Sure, most distributions have a "hacker kernel", but it's NOT installed by default, and it is clearly marked as experimental. Your arguments make no sense. The compiler is often _more_ important to system stability than the kernel. A "real release" implies that it at least had testing, and that people know what the problem spots tend to be. Note that the "know what the problem spots tend to be" is important. > > As to X compile problems - neither egcs nor 2.95.2 appears to have any > > trouble with the CVS tree. > > Neither does 2.96-68. Good. Maybe you'd make it clearer to everybody who installed from your CD's that they had better upgrade. Pronto. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
On Thu, 14 Dec 2000, Linus Torvalds wrote: > If you ask any gcc folks, the main reason they think this was a really > stupid thing to do was exactly that the 2.96 thing is incompatible BOTH > with the 2.95.x release _and_ the upcoming 3.0 release. The same thing is true of *any* gcc release. For example, C++-ABI wise, 2.95.x is incompatible BOTH with egcs 1.1.x _and_ the upcoming 3.0 release. > > Like what - gcc 2.5.8 ? The problem is not in general that the snapshot is any > > buggier than before, but that the bugs are in different places. egcs and gcc295 > > both caused X compile problems too. > > gcc-2.95.2 is at least a real release, from a branch that is actively > maintained Not very actively. Please take the time to compare the activity in gcc_2_95_branch with the patches in the current "2.96" version in rawhide. > - so a 2.95.3 is likely to happen reasonably soon, fixing as > many problems as possible _without_ being incompatible like the snapshots > are. It will be incompatible with any non-2.95.x-version, and I don't think 2.96-68 is any more buggy than the current 2.95 branch. The initial 2.96 "release" did have some odd bugs; all the known ones have been fixed. > Or just stay at 2.91.66 (egcs). This may be good for the kernel, but it's not acceptable for C++. Also, there's no support for some of the platforms we have to work with, such as ia64 and S/390 - using different compilers for different architectures isn't a real solution either. > As to X compile problems - neither egcs nor 2.95.2 appears to have any > trouble with the CVS tree. Neither does 2.96-68. LLaP bero - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: parport1 gone in 2.2.18
On Thu, Dec 14, 2000 at 08:43:18PM +0100, Peter Bornemann wrote: > Any hint is welcome, for I would prefer a really stable kernel for this > machine. The problem isn't that the kernel is not stable, but that it doesn't support your parallel port card. ;-) I'll look at backporting the 2.4.x card table and keep you posted. Tim. */ PGP signature
Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
I do the following sudo modprobe iptable_nat Module Size Used by iptable_nat17440 0 (unused) ip_conntrack 19808 1 [iptable_nat] ip_tables 12320 3 [iptable_nat] Oops start flying by when I access via NFS. If you need the actual Oops messages we're gonna have to get someone who can setup a serial console. On Thu, 14 Dec 2000, Mohammad A. Haque wrote: > Just quick feedback. > > Test 1: > Netfilter compiled into kernel. Netfilter configuration options > as modules. Modules loaded. Using NFS, I got Oops (in fact I've > never seen an Oops output infinitely before. Maybe it would have > stopped if I waited.) > > Test 2: > Netfilter compiled into kernel. Netfilter configuration options > as modules. Modules _NOT_ loaded. Can use NFS just fine. Did a > couple of 100 MB transfers w/o problems. > > > I'll continue narrowing it down. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
On Thu, 14 Dec 2000, Alan Cox wrote: > > > user applications and (b) gcc-2.96 is so broken that it requires special > > libraries for C++ vtable chunks handling that is different, so the > > Wrong - the C++ vtable format change is part of the intended progression of the > compiler and needed to meet standards compliance. gcc 295 also changed the > internal formats. Unfortunately the gcc295 and 296 formats are both probably > not the final format. The compiler folks are not willing to guarantee anything > untill gcc 3.0, which may actually be out by the time 2.4 is stable. If you ask any gcc folks, the main reason they think this was a really stupid thing to do was exactly that the 2.96 thing is incompatible BOTH with the 2.95.x release _and_ the upcoming 3.0 release. Nobody asked the people who knew this, apparently. > > unusable as a development platform, and I hope RH downgrades their > > compiler to something that works better RSN. It apparently has problems > > Like what - gcc 2.5.8 ? The problem is not in general that the snapshot is any > buggier than before, but that the bugs are in different places. egcs and gcc295 > both caused X compile problems too. gcc-2.95.2 is at least a real release, from a branch that is actively maintained - so a 2.95.3 is likely to happen reasonably soon, fixing as many problems as possible _without_ being incompatible like the snapshots are. Or just stay at 2.91.66 (egcs). As to X compile problems - neither egcs nor 2.95.2 appears to have any trouble with the CVS tree. Possibly because they got fixed, because, after all, at least those were real releases. I'd applaud RedHat for making snapshots available, but they should be marked as SNAPSHOTS, and not as the main compiler with no way to fix the damn problems it causes. As it is, anybody doing development is probably better off at RH-6.2. That is doubly true if they intend to release binaries. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
On Thu, Dec 14, 2000 at 04:42:03AM -0800, Clayton Weaver wrote: > There has a been a thread on the teTeX mailing list the last few days > about a (RedHat, but probably more general than just their rpms) > gcc-2.9.6 w/glibc-2.2.x bug. At -O2, it can miscompile > > unsigned varname; /* "unsigned int varname;" is ok */ > > (no problem at -O or no optimization at all, and doesn't happen if teTeX > is compiled with kgcc). That one is fixed already for some time, it was a bug in loop unrolling (that patch is still pending review for the mainline CVS though). Jakub - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
"No rule to make target `irlan/irlan.o " in 2.4.0-test12pre1
Hallo, compiling a fresh patched 2.4.0.13pre1 and make modules shows me following error: make[2]: *** No rule to make target `irlan/irlan.o', needed by `modules'. Stop.make[2]: Leaving directory `/usr/src/linux-2.4.0.13pre1/net/irda' make[1]: *** [_modsubdir_irda] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.0.13pre1/net' make: *** [_mod_net] Error 2 make modules_install shows: depmod: *** Unresolved symbols in /lib/modules/2.4.0-test12/kernel/fs/nfs/nfs.o depmod: lockd_up_Rsmp_f6933c48 depmod: nlmclnt_proc_Rsmp_0f4e5e85 depmod: lockd_down_Rsmp_a7b91a7b depmod: *** Unresolved symbols in /lib/modules/2.4.0-test12/kernel/fs/nfsd/nfsd.o depmod: lockd_up_Rsmp_f6933c48 depmod: nlmsvc_ops_Rsmp_d56c4cfc depmod: nlmsvc_invalidate_client_Rsmp_b1c3f825 depmod: lockd_down_Rsmp_a7b91a7b using 2.4.0.12 seems o.K. to me (installed a patch for 8139.too manually.) kind regards Norbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Re: VM problems still in 2.2.18
Alan Cox wrote: > > slrnpull --expire on a news-spool of about 600 Mb in 200,000 files gave > > a lot of 'trying_to_free..' errors. > > > > 2.2.18 + VM-global, booted with mem=32M: > > > > slrnpull --expire on the same spool worked fine. > > I think Andrea just earned his official God status ;) So, maybe his divine VM patches will make it into 2.2.19? jjs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Is this a compromise and how?
> > I'm guessing that your ls was also hijacked. You're using RedHat, so try > > the rpm -V command > Once hacked you can't trust anything. A malicious person might just > install RPMs for example. There is a proper way to do this. You boot the rescue CD, then do the rpm verify of each package with the rpm binary on the CD (static) agains the package on the CD. > Re-install is the only option. I would advise this however it is not 'only' but 'very good idea' > Restore backups only after verifying that they do not re-install the (popular one is roots .login) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
Ion Badulescu wrote: > On Thu, 14 Dec 2000 07:15:04 -0500, Mohammad A. Haque <[EMAIL PROTECTED]> wrote: > > Were you connected to a network or receiving/sending anything? > > ip_defrag is broken -- there is an obvious NULL pointer dereference > in it, introduced in test12. It doesn't hit normally, because of > path MTU discovery, but using NFS causes instant death. ...and then I wrote: > This is consistent with the lockup I reported several hours ago. > In the case of my "unstable" 2.4.0-test12 machine where "startx" > worked fine for "root" but not for a normal user, the "root" > account is local. The normal user account home directories are > NFS mounted :-(. I tried the submitted patch for ip_fragment.c, and there's still no joy on that one unstable machine in my sample set. At this point, I should probably go back through all the pre-12 patches and see if the problem scope can be narrowed a bit. -- Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Re: VM problems still in 2.2.18
> slrnpull --expire on a news-spool of about 600 Mb in 200,000 files gave > a lot of 'trying_to_free..' errors. > > 2.2.18 + VM-global, booted with mem=32M: > > slrnpull --expire on the same spool worked fine. I think Andrea just earned his official God status ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Signal 11
> I don't know why RH decided to do their idiotic gcc-2.96 release (it > certainly wasn't approved by any technical gcc people - the gcc people Every single patch in that release barring I believe 2 was accepted into the main tree. So they liked the code. The naming did upset people and was unfortunate, but done talking to the compiler folks at Red Hat with the best of intentions behind it. If we had called it 'Red Hat cc' I think people would have been even more offended at the way they had been discredited. I do understand why they got peeved, I do understand why they feel no urge to support the 296 codebase (nor would I want them to). I hit 'd' when I see 'I have 2.2.18 patched with [reiserfs|ext3|bigmem|lfs]' for the same reasons. > They included another (non-broken) compiler, and called it "kgcc". > "kgcc" stands for "kernel gcc", apparently because (a) they realised kgcc is a convention invented a long time ago by Conectiva. Debian also used to have gcc272. It is done because gcc272 is useless at C++, has lots of bugs egcs is no better at C++ and has lots of bugs gcc295 is a little better at C++ and is _Crawling_ with bugs gcc296(redhat) is a lot better at C++ and doesn't appear to be any buggier. In fact gcc296 is the first compiler that can compiled 2.2.16 correctly. All the previous compilers miscompile the strstr() inline in some cases. Thats why I had to hack the 2.2 kernel tree to make it work. (And the cases where you got compile time errors gcc was right to moan about - like using (...) in traditional > user applications and (b) gcc-2.96 is so broken that it requires special > libraries for C++ vtable chunks handling that is different, so the Wrong - the C++ vtable format change is part of the intended progression of the compiler and needed to meet standards compliance. gcc 295 also changed the internal formats. Unfortunately the gcc295 and 296 formats are both probably not the final format. The compiler folks are not willing to guarantee anything untill gcc 3.0, which may actually be out by the time 2.4 is stable. > unusable as a development platform, and I hope RH downgrades their > compiler to something that works better RSN. It apparently has problems Like what - gcc 2.5.8 ? The problem is not in general that the snapshot is any buggier than before, but that the bugs are in different places. egcs and gcc295 both caused X compile problems too. I still advise people: Use egcs-1.1.2 for Linux 2.2.x. You can build 2.2.18 with gcc 2.9.6 but I personally wouldn't be running production systems on a kernel built that way - but NOT because gcc296 is buggier but because the bugs are going to be in different places and I firmly believe production system people should let the loons find them ;) Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
On Thu, 14 Dec 2000, Dr. Kelsey Hudson wrote: > On Thu, 14 Dec 2000, David Riley wrote: > > > Did I miss a post from Linus on the list, or is there no posted > > changelog for test13-pre1? Nothing's posted at kernel.org yet, either. > > > > I musta missed the post too... But then again I went back and looked for > it and couldnt find it so... > > i'd like to know what changed, anyways :) > Occasionally Linus will put out a 'pre' release that is not for 'public consumption', as was the case in 2.4.0-test12pre1. Subsequent 'pre' releases will show the the change log for test13pre1. We just have to be patient. 8-) -- Marty Pitts Linux Today http://linuxtoday.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [Korbit-cvs] Re: ANNOUNCE: Linux Kernel ORB: kORBit (and ioctl must die!)
Alexander Viro <[EMAIL PROTECTED]> writes: > ioctl() is avoidable. Proof: Plan 9. They don't _have_ that system call. > It doesn't mean that we should (or could) remove it. It _does_ mean that > new APIs do not need it. *I* sure wish we could. From the standpoint of trying to trace system calls, it's a big stinking black hole. All of the other syscalls (I think) have pretty well defined semantics in terms of what they do to a process' memory space, but the semantics of ioctl are "may read or write any memory whatsoever, and if you want to know what, well, it sucks to be you". Even NT does this better, if I'm interpreting this correctly: http://msdn.microsoft.com/library/psdk/winbase/devio_9quk.htm --Mike -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
lock_kernel() / unlock_kernel inconsistency
In an effort to stay consistent with the community, I migrated some code
to a driver to use the daemonize() routine in the function specified by
the kernel_thread() call.
However, in looking at a few drivers in the system (drivers/usb/hub.c ,
drivers/md/md.c, drivers/media/video/msp3400.c), I noticed some
inconsistencies. Specifically with the use of lock_kernel() /
unlock_kernel().
drivers/md/md.c looks like:
int md_thread(void * arg)
{
md_lock_kernel();
daemonize();
.
.
.
//md_unlock_kernel();
}
this is similiar to drivers/usb/hub.c (which doesn't call unlock_kernel
following lock_kernel)
however drivers/media/video/msp3400.c looks like:
static int msp3400c_thread(void *data)
{
.
.
.
#ifdef CONFIG_SMP
lock_kernel();
#endif
daemonize();
.
.
.
#ifdef CONFIG_SMP
unlock_kernel();
#endif
}
The latter example seems logically correct to me. Does this imply that
after the CPU that is responsible for starting the thread in md.c or
hub.c claims the global lock it will never be released to any other CPU?
If I am incorrect here please just point out my error, however, I
figured I would bring this to the mailing list's attention if in fact
this is truely in error.
Thanks,
Jason
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: ORBit speed measure
On Thu, Dec 14, 2000 at 11:10:24AM -0600, Chris Lattner wrote: > There are many other optimizations that one can make the transport faster > that ORBit doesn't implement. For example, you could mmap (shared) data > buffers between the two processes communicating (of course, you still need > to wake processes up, which is why it hasn't been done yet), or you could This is not necessarily faster. I recently came across some discussions on the web from Jim Gettys that discussed similar issues for X (unix sockets vs shared memory). I seem to remember that the over head of synchronizing stuff to keep the shared memory in a sane state ate away at any gains one had with using shared memory. It works ok for large chunks of data (say, things on the order of sizes of pixmaps), but not for smaller pieces, like say, function call arguments. Then again, isn't Jim some how involved in ORBit and GNOME? Or just a big supporter? :-> mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Serial cardbus code.... for testing, please.....
[Apologies if this has been seen already, but as far as I know my first posting to the L-K list apparently never made it out] - Ted OK, so I'm currently at the road (San Diego IETF meeting) so I can't really test this very well; when your compile engine is your Vaio laptop, it's really slow and painful to do test builds and test booting kernels. But I know some people are eager to test it, and would rather have something potentially flaky earlier rather waiting for something more tested later, so here it is. Please note, the only testing that I have done to date is Linus's famous "it builds, ship it" regression test suite. So if you're not willing to test a patch which might crash your machine, come back in a day or two after I and others have had a chance to do some testing. (But hey, Linus has released kernels to the entire world without even doing a test compile, so why can't I do it with something as simple as a serial driver? :-) This version of the patch has a couple of new features over past ones, including sanity check code which should prevent receive_chars() from getting stuck in a tight loop when the serial card is ejected while a port is active. It also has functions correctly labelled with __devinit and __devexit, and will check to see if an entry in the serial pci table isn't necessay, and ask the user to report the information in that case. (mailing list to be active within 24 hours; until then, send the information to me instead of the e-mail adddress listed in the patch). The patch also has changes which Kanoj from SGI has been bugging me about constantly because he needs some changes to support his big-iron MIPS box project which he's working on. I had sat on them because clearly I have a different understanding of "code freeze; critical bugs only" than other folks on the L-K mailing list, but they're included here now. Linus, I can back out some or all of these changes when I feed the patches to use for merging with 2.4; just let me know what you want and don't want. - Ted Release notes = * Add support for PCI hot plugging. - Functions should be correctly labeled with __devinit and __devexit now. - Set a safety check to prevent infinite loops in receive_chars - Added support for removing PCI cards * Added code to test to see if an entry in the serial driver's PCI table is redundant (i.e., could have been deduced using our hueristics) and asks the user to report the information if so. * Add support for flow controled serial console. (Feature desperately requested to be merged into 2.4.0 by Kanoj Sarcar <[EMAIL PROTECTED]> for his big-iron MIPS box) * Add new interface, early_serial_setup() which allows architecture specific code to set up serial consoles for those platforms where the port and bus information must be dynamically determined by the boot. Early_serial_setup() must be called before rs_init(). (Feature desperately requested to be merged into 2.4.0 by Kanoj Sarcar <[EMAIL PROTECTED]> for his big-iron MIPS box) * Fixed fencepost bug which could cause the serial driver to overrun the flip buffer by a single character if the UART reports an overrun when the flip buffer is nearly full. (not really a critical problem because we have slop space in the flip buffer for this purpose, but it really would be good to have this fixed.) * Add support for the DCI PCCOM8 8-port serial board Patch generated: on Wed Dec 13 10:39:41 EST 2000 by tytso@trampoline against Linux version 2.4.0 === RCS file: Documentation/RCS/serial-console.txt,v retrieving revision 1.1 diff -u -r1.1 Documentation/serial-console.txt --- Documentation/serial-console.txt2000/12/13 15:12:57 1.1 +++ Documentation/serial-console.txt2000/12/13 15:13:09 @@ -20,9 +20,11 @@ options:depend on the driver. For the serial port this defines the baudrate/parity/bits of the port, - in the format PN, where is the speed, - P is parity (n/o/e), and N is bits. Default is - 9600n8. The maximum baudrate is 115200. + in the format PNF, where is the speed, + P is parity (n/o/e), N is bits, and F is + flow control (n/r for none/rtscts). P, N, + and F are optional. The default setting is +
Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
Just quick feedback. Test 1: Netfilter compiled into kernel. Netfilter configuration options as modules. Modules loaded. Using NFS, I got Oops (in fact I've never seen an Oops output infinitely before. Maybe it would have stopped if I waited.) Test 2: Netfilter compiled into kernel. Netfilter configuration options as modules. Modules _NOT_ loaded. Can use NFS just fine. Did a couple of 100 MB transfers w/o problems. I'll continue narrowing it down. # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_FILTER=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=m # CONFIG_IP_NF_MATCH_LIMIT is not set # CONFIG_IP_NF_MATCH_MAC is not set # CONFIG_IP_NF_MATCH_MARK is not set # CONFIG_IP_NF_MATCH_MULTIPORT is not set CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_STATE=m # CONFIG_IP_NF_MATCH_UNCLEAN is not set # CONFIG_IP_NF_MATCH_OWNER is not set CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_MIRROR=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m # CONFIG_IP_NF_MANGLE is not set CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_COMPAT_IPCHAINS=m CONFIG_IP_NF_NAT_NEEDED=y # CONFIG_IP_NF_COMPAT_IPFWADM is not set MODULES LOADED: Module Size Used by ipt_state800 13 (autoclean) ipt_tos 720 6 (autoclean) ipt_LOG 3248 4 (autoclean) iptable_filter 1920 0 (autoclean) (unused) ipt_MASQUERADE 1808 1 ip_nat_ftp 3520 0 (unused) ip_conntrack_ftp2336 0 [ip_nat_ftp] iptable_nat17440 1 [ipt_MASQUERADE ip_nat_ftp] ip_conntrack 19808 3 [ipt_state ipt_MASQUERADE ip_nat_ftp ip_conntrack_ftp iptable_nat] ip_tables 12320 8 [ipt_state ipt_tos ipt_LOG iptable_filter ipt_MASQUERADE iptable_nat] On Thu, 14 Dec 2000, David S. Miller wrote: > Meanwhile for people wanting the crashes to be fixed, please > apply this patch. > > This was _always_ broken, and really what netfilter is doing > should have never worked. The only theory I have right now > is that people using netfilter never had IP fragments timeout. > :-) > > So the patch below restores previous behavior exactly. > Ie. netfilter sources fragments cannot send ICMP errors > on frag queue timeout :-) > > (The line numbers may be off a bit, but "patch" should still > eat it). > -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.18 + DHCP + nfsroot
I'm having problems getting my machines to load nfsroot since I went from 2.2.16 -> 2.2.18. I don't have access to the boot messages, as the machines are 2000 miles away, but the DHCP messages aren't showing up anymore, but instead a bunch of RPC messages are. Has anything changed with regards to DHCP or nfs root since 2.2.17? Thanks in advance. ,.;:: : Michael J. Dikkema | Systems / Network Admin - Internet Solutions, Inc. | http://www.moot.ca Work: (204) 982-1060 ; [EMAIL PROTECTED] ',. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
Ion Badulescu wrote: > On Thu, 14 Dec 2000 07:15:04 -0500, Mohammad A. Haque <[EMAIL PROTECTED]> wrote: > > Were you connected to a network or receiving/sending anything? > > ip_defrag is broken -- there is an obvious NULL pointer dereference > in it, introduced in test12. It doesn't hit normally, because of > path MTU discovery, but using NFS causes instant death. This is consistent with the lockup I reported several hours ago. In the case of my "unstable" 2.4.0-test12 machine where "startx" worked fine for "root" but not for a normal user, the "root" account is local. The normal user account home directories are NFS mounted :-(. Good spot! I've done a little mucking around with the networking code, i.e., no promises, but maybe I can come up with a fix. -- Bob Tracy[EMAIL PROTECTED] - "We might not be in hell, but we can see the gates from here." --Phoenix resident, Summer of 2000 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
The test13-pre1 changelog was something along the lines of "alright, I am sick of this Makefile crap. I fixed some, clean up the rest." ;-) -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
Date: Thu, 14 Dec 2000 15:35:48 -0500 (EST)
From: "Mohammad A. Haque" <[EMAIL PROTECTED]>
I'll be trying in a few hours.
Meanwhile for people wanting the crashes to be fixed, please
apply this patch.
This was _always_ broken, and really what netfilter is doing
should have never worked. The only theory I have right now
is that people using netfilter never had IP fragments timeout.
:-)
So the patch below restores previous behavior exactly.
Ie. netfilter sources fragments cannot send ICMP errors
on frag queue timeout :-)
(The line numbers may be off a bit, but "patch" should still
eat it).
--- net/ipv4/ip_fragment.c.~1~ Wed Dec 13 10:31:48 2000
+++ net/ipv4/ip_fragment.c Thu Dec 14 12:20:09 2000
@@ -258,7 +258,8 @@
if ((qp->last_in_IN) && qp->fragments != NULL) {
struct sk_buff *head = qp->fragments;
/* Send an ICMP "Fragment Reassembly Timeout" message. */
- if ((head->dev = dev_get_by_index(qp->iif)) != NULL) {
+ if (qp->iif != -1 &&
+ (head->dev = dev_get_by_index(qp->iif)) != NULL) {
icmp_send(head, ICMP_TIME_EXCEEDED, ICMP_EXC_FRAGTIME, 0);
dev_put(head->dev);
}
@@ -487,8 +488,12 @@
else
qp->fragments = skb;
- qp->iif = skb->dev->ifindex;
- skb->dev = NULL;
+ if (skb->dev != NULL) {
+ qp->iif = skb->dev->ifindex;
+ skb->dev = NULL;
+ } else
+ qp->iif = -1;
+
qp->stamp = skb->stamp;
qp->meat += skb->len;
atomic_add(skb->truesize, _frag_mem);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre1 changelog
Hello, Linus didn't annnounce test13-pre1 as far as I am aware of. Regards, Frank --On Thursday, December 14, 2000 12:11 PM -0800 "Dr. Kelsey Hudson" <[EMAIL PROTECTED]> wrote: > On Thu, 14 Dec 2000, David Riley wrote: > >> Did I miss a post from Linus on the list, or is there no posted >> changelog for test13-pre1? Nothing's posted at kernel.org yet, either. >> > > I musta missed the post too... But then again I went back and looked for > it and couldnt find it so... > > i'd like to know what changed, anyways :) > > Kelsey Hudson > [EMAIL PROTECTED] Software Engineer > Compendium Technologies, Inc (619) 725-0771 > - > -- > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
I'll be trying in a few hours. On Thu, 14 Dec 2000, Ion Badulescu wrote: > On Thu, 14 Dec 2000, David S. Miller wrote: > > > If you turn off netfilter, ip_conntrack, etc. does the OOPS still > > occur? > > I'm afraid I won't be able to answer this question, since I'm leaving for > a 3-week vacation in about 50 minutes and I need my firewall functional > until then. :-) Maybe other people who have seen this problem can > experiment further. > > If I get a few moments, I'll do a quick test before leaving and will let > you know. The chance of that happening is extremely slim, though. > > Thanks, > Ion > > -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: x86 cpu_data
> Hi, I need to check for *only* Intel P6 processors, so no Classic Pentium, > and no Pentium 4. setup.c is a bit obscure; is this check correct : Long answer - you cannot reliably check... Shorter answer x86_vendor == INTEL x86 = 6 is Pentium Pro-> PentiumIII The Pentium IV reports x86 = 15. My opinion on that isnt printable ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [lkml]Re: VM problems still in 2.2.18
On Thu, Dec 14, 2000 at 09:57:28AM +, Alan Cox wrote: > > bug was discovered. Ever since, I have two boxes here > > that keep falling over. Box A will randomly lock without > > warning and box B will die and start printing this message > > repeatedly on the screen until I physically hit reset: > > What are these two boxes doing ? > > > Is there a patch out there that I can apply to 2.2.14 > > against the security bug? The machines were very stable > > on that kernel. > > Andrea's VM-global patch seems to be a wonder cure for those who have tried > it. Give it a shot and let folks know. My experience: 2.2.18pre25 erroneously booted with mem=64M: slrnpull --expire on a news-spool of about 600 Mb in 200,000 files gave a lot of 'trying_to_free..' errors. 2.2.18 + VM-global, booted with mem=32M: slrnpull --expire on the same spool worked fine. Good luck, Jurriaan -- proof by reference to inaccessible literature: The author cites a simple corollary of a theorem to be found in a privately circulated memoir of the Slovenian Philological Society, 1883 (second edition). GNU/Linux 2.2.18 SMP 2x1117 bogomips load av: 0.56 0.15 0.05 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Is this a compromise and how?
On Thu, Dec 14, 2000 at 12:58:26AM -0800, Matthew Dharm wrote: > > I doubt that from this description, you've been hacked. Even if your > /etc/inetd.conf is in good shape, it looks like someone got in. > > I'm guessing that your ls was also hijacked. You're using RedHat, so try > the rpm -V command Once hacked you can't trust anything. A malicious person might just install RPMs for example. Re-install is the only option. Restore backups only after verifying that they do not re-install the backdoors as well. This is where your current hacked system may be useful. Something like the coroners toolkit (?) written by Wietse Venema (and others?) might help you determining at what date your system has been hacked. Don't be suprised if you find multiple break-ins accumulated over the years. If you have (had) a network: attached systems may have been compromised as well. -- Frank - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Adaptec AIC7XXX v 6.0.6 BETA Released
On Wed, 13 Dec 2000, Justin T. Gibbs wrote: > > Date: Wed, 13 Dec 2000 20:56:08 -0700 > > From: "Justin T. Gibbs" <[EMAIL PROTECTED]> > > > > None-the-less, it seems to me that spamming the kernel namespace > > with "current" in at least the way that the 2.2 kernels do (does > > this occur in later kernels?) should be corrected. > > > >Justin, "current" is a pointer to the current thread executing on the > >current processor under Linux. It has existed since day one of the > >Linux kernel and probably will exist till the end of it's life. > > > >I'm sure the BSD kernel has some similar bogosity :-) > > BSD has curproc, but that is considerably less likely to be > used in "inoccent code" than "current". I mean, "current what?". > It could be anything, current privledges, current process, current > thread, the current time... "buf, buffers, type, version" (of what ?) with FreeBSD kernel (if they still exist), but they are global variables, not macros. By the way, SYM-2, that is "FreeBSD sym back to Linux but still in FreeBSD":), clashed on Linux "current" as well. Reason is that the corresponding code was based on yours :) (as indicated in the sym driver source). I have changed "current" by "curr". This is as clear and has the advantage of scaling better with "user" and "goal" (4 characters each). tinfo.goal tinfo.user tinfo.curr Just a suggestion. Gérard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net/802/transit/Makefile (240-test13-pre1)
Hi. I'm not quite sure whom this patch belongs to but I hope that it ends up in the right hands by way of linux-kernel. In order to get 'make dep' to make it through my tree (240-test13-pre1) I need the following patch applied: diff -Naur linux-240-t13-pre1-clean/net/802/transit/Makefile linux/net/802/transit/Makefile --- linux-240-t13-pre1-clean/net/802/transit/Makefile Thu Dec 12 15:54:22 1996 +++ linux/net/802/transit/Makefile Thu Dec 14 21:07:39 2000 @@ -1,3 +1,5 @@ +include $(TOPDIR)/Rules.make + all: pdutr.h timertr.h pdutr.h: pdutr.pre compile.awk -- Regards, Rasmus([EMAIL PROTECTED]) Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Netfilter is broken (was Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback))
Date: Thu, 14 Dec 2000 12:07:38 -0800 (PST) From: Ion Badulescu <[EMAIL PROTECTED]> I'm afraid I won't be able to answer this question, since I'm leaving for a 3-week vacation in about 50 minutes and I need my firewall functional until then. :-) Maybe other people who have seen this problem can experiment further. Ok, regardless I'm very confident netfilter is doing something very bad. Essentially it is feeding SKBs into IPv4 receive processing which have a NULL skb->dev, that has always been illegal. Now it OOPSs so we can spot such violations. 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] Please read the FAQ at http://www.tux.org/lkml/
Re: DVD on Linux
On Thu, Dec 14 2000, Dr. Kelsey Hudson wrote: > nope, DVD discs all use UDF. Ehh, no that is very untrue. Most data dvd's use bridged iso9660/udf, which works fine with Linux iso9660. -- * Jens Axboe <[EMAIL PROTECTED]> * SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
