Which Bind version..
Hi!! I wanna install Bind on my DNS. Which Bind version is most stabel and secure. Regards, Nauman Ansari - 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: 2.4.0-ac3 write() to tcp socket returning errno of -3 (ESRCH:"No such process")
On Mon, 8 Jan 2001, Andi Kleen wrote:
> On Sun, Jan 07, 2001 at 11:55:28PM -0600, Paul Cassella wrote:
> > write() returns -1 and sets errno non-sensically. 2.4.0{,-ac[23]}
> Would it be possible to provide a compiling test case that shows these
> errors ?
The CVS version (perhaps even version 0.12) of gtk-gnutella should do it,
though it's not exactly what I'm running. After the crash I posted about,
I've been running it for another three and a half hours under similar
load, and it hasn't crashed again yet; nor have I seen any other
unexpected ret's (besides those noted below) get logged.
http://gtk-gnutella.sourceforge.net/cvs/
Though I don't think gtk-gnutella is special. It doesn't do anything
programmatically unusual with sockets, it just has a bunch of connections
to a bunch of different machines, which are probably running a bunch of
different os's, etc. And it aborts when write() returns unexpected
values.
I've appended the actual kernel diffs that I'm using; I'd just pasted them
from an xterm before. I probably should have added ECONNREFUSED and
ERESTARTSYS to the list.
> Also over what interface do you run it?
eth0 (tulip):
01:08.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 21)
In answer to David's questions, I don't think I'm doing anything out of
the ordinary. I'm running over DSL with the above card on an external DSL
router. No netfilter, no tunneling, just IP.
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=m
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
CONFIG_IPV6=m
# CONFIG_IPV6_EUI64 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
CONFIG_DUMMY=m
CONFIG_TULIP=y
I have these set, but I haven't used them:
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_ASYNC=m
# CONFIG_PPP_SYNC_TTY is not set
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
eth0 Link encap:Ethernet HWaddr 00:A0:CC:3E:E6:63
inet addr:64.81.146.215 Bcast:64.81.146.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:674842 errors:0 dropped:0 overruns:0 frame:0
TX packets:791977 errors:0 dropped:0 overruns:0 carrier:0
collisions:490 txqueuelen:100
Interrupt:11 Base address:0xd800
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3856 Metric:1
RX packets:1138 errors:0 dropped:0 overruns:0 frame:0
TX packets:1138 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
Destination Gateway Genmask Flags Metric RefUse Iface
64.81.146.0 0.0.0.0 255.255.255.0 U 0 00 eth0
0.0.0.0 64.81.146.1 0.0.0.0 UG0 00 eth0
Is there a list somewhere of network options I should report (such as
filtering and tunneling)?
Should one of linux-kernel or linux-net be pruned from the Cc: list?
--
Paul Cassella
--- fs/read_write.c~Sat Nov 11 18:07:38 2000
+++ fs/read_write.c Sun Jan 7 14:00:25 2001
@@ -146,6 +146,8 @@
ssize_t ret;
struct file * file;
+extern struct file_operations socket_file_ops;
+
ret = -EBADF;
file = fget(fd);
if (file) {
@@ -165,6 +167,18 @@
DN_MODIFY);
fput(file);
}
+ if(ret < 0 && file && file->f_op == &socket_file_ops ) {
+ switch(-ret) {
+ case EAGAIN: case EBADF: case EPIPE: case ENOSPC: case EIO: case
+ECONNRESET:
+ case EINTR: case ETIMEDOUT: case EFAULT: case EINVAL: case EMSGSIZE:
+case ENOMEM:
+ case ENOBUFS: case ENOTCONN:
+ break;
+
+ default:
+ printk(KERN_ERR "sys_write: ret is unexpectedly %d.\n", ret);
+ }
+ }
+
return ret;
}
--- net/socket.c~ Mon Jan 8 01:26:55 2001
+++ net/socket.cSun Jan 7 13:58:55 2001
@@ -111,7 +111,7 @@
* in the operation structures but are done directly via the socketcall()
multiplexor.
*/
-static struct file_operations socket_file_ops = {
+struct file_operations socket_file_ops = {
llseek:sock_lseek,
read: sock_read,
write: sock_write,
-
To unsubscribe from this list: send the line "unsubscribe linu
Re: ramfs problem... (unlink of sparse file in "D" state)
On Sun, 7 Jan 2001, Chris Wedgwood wrote: > On Sat, Jan 06, 2001 at 03:35:32PM +, Alan Cox wrote: > > BTW Al: We have another general vfs/fs problem to handle - which > is exceeding max file sizes on limited file systems. Pretty much > nobody is getting it right. Ext2 can be tricked to go past the > limit, sys5 1k sits there emitting printk messages etc. > > Which filesystems have limits other than 2^31 bytes? Plenty. ext2, for one - e.g. with 4Kb blocks you have limit at 0x4010040c000 for files and 0x1 for directories. With 1Kb blocks the limit for files is 0x404043000. Notice that the latter is not a multiple of page size on Alpha. - 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: ramfs problem... (unlink of sparse file in "D" state)
On Sat, 6 Jan 2001, Alan Cox wrote: > > > > Add UnlockPage(page) at the end of ramfs_writepage(). > > > Shit. You are quite fast. Works. > > > > Sure, especially considering the fact that patch was sent to > > Linus about a month ago (several times, actually)... ;-/ > > Its in all the -ac trees 8) > > BTW Al: We have another general vfs/fs problem to handle - which is exceeding > max file sizes on limited file systems. Pretty much nobody is getting it > right. Ext2 can be tricked to go past the limit, sys5 1k sits there emitting > printk messages etc. > Any objections to me putting max file size for an fs (in pages) into the > superblock ? An fs can still implement weird rules by putting large values > in that and doing its own checks. Alan, it doesn't work that way. Maximal size depends on the type of object, for one thing. Moreover, it's not always a multiple of page size, so you still need foo_get_block() to be aware of the problem (it should return -EFBIG). Besides, we need to take care of the situations when some of get_block() calls fail in prepare_write() - that can happen due to other problems. I've fixed all that stuff for ext2 (check the patches posted on l-k after 12-pre6). We need to propagate it into other filesystems, but I don't think that max size in pages is really worth the trouble. I can pull these patches out of the mix and send them to you. ACK? - 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: devfs breakage in 2.4.0 release
On Sat, 6 Jan 2001, Adam J. Richter wrote: > On my Sony PictureBook PCG-C1VN, 2.4.0 hangs in the boot > process while 2.4.0-prerelease boots just fine. At first I thought > the problem was devfs-related, but skipping devfsd just caused the > hang to occur a little later, this time in ifconfig. The kernel > call trace looked something like this: > > neigh_ifdown > sys_ioctl > sock_ioctl > [some addresses in modules] > stext_lock > __down_failed > __down > > What surprised me more was that attempting to remount the > root filesystem for writing just before this (to record the module > kernel symbols) caused a kenel BUG() in slab.c:1542 becuase kmalloc > was being called with a huge negative number. > > I know I could run ksymoops to get this trace, but I now > think the cause of the problem probably happens much earlier than > the symptoms. So, I trying backing out different 2.4.0 changes. > So far, I can tell you that reverting the linux/mm subdirectory to > its 2.4.0-prerelease contents had no effect. I will let you know > if I diagnose or fix the problem, as I think you may be experiencing > the same problem. I think it's a different problem. I reproduced the same with 2.4.0-test12 but not 2.4.0-test10. There are changes (not very large) in fs/devfs/base.c between these versions. I tried to take 2.4.0 and change back these updates and saw that it doesn't fix the problem. Trying all prerelaeses between 2.4.0-test10 and 2.4.0-test12 perhaps would take too much time ... There is no hanging (or crashes) at all for me. All these versions boots Ok for me, but what I have is devfsd quitting with error message that it cannot state /dev/vcc/[1-6] after some relooging from the same terminal. Andris - 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/
Are PCI add-on Cardbus Readers supported by the 2.4.0 kernel?
I would like to perform more PCMCIA/Cardbus testing on a wider array of systems. I am considering buying a Ratoc Cardbus PC Adapter (model number CBS51U). Here are the specs: PCI-CardBus Bridge adapter board Allows CardBus PC Cards to be shared by both portable and desktop PC. Supplied ISA-IRQ routing board allows you to use 16-bit PC Cards. Automatic detection between 16-bit and CardBus PC Card. ACPI support for PC with PCI slot/ISA slot Bus type : Type II CardBus Bus mastering : Yes Data Transfer Rate Compression : (Native/Uncompressed) The specs mention Win98 support. Hopefully that doesn't mean this is some sort of "WinCardbus Reader" heap of junk. Has anyone gotten this board or a similar one from another manufacturer to work? Thanks, 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/
[PATCH] wrong stat of NTFS volume in linux-kernel 2.4.0
I tested the 2.4.0 kernel and it reported a wrong volume size for
ntfs partitions. The size of the partition (as reported by df -k) was
a factor of 8 too high. After some searching I found that
super.c in /usr/src/linux/fs/ntfs was changed. In my previous kernel
2.2.16 a division by the number of blocks in a cluster was made although
it included a remark about the 64 bit division routine, and thus used only a
32 bit division.
In the latest kernel (2.4.0) the division is completly removed, and thus the
volume size is incorrect.
I included a patch for the situation. This routine presupposes that the
number of blocks in a cluster is always a power of 2, and uses right shifts.
As far as I know all NTFS cluster sizes are a power of two, which is confirmed
by the options of the format command in NT and some knowledgebase articles
of Microsoft. If not an message will appear in the syslog. (printk)
Willem Dekker
Patch to adapt super.c of the ntfs filesystem. On a stock linux
2.4.0 kernel.
>>>
--- fs/ntfs/super.orig Tue Nov 7 20:22:35 2000
+++ fs/ntfs/super.c Sun Jan 7 22:34:43 2001
@@ -300,6 +300,82 @@
return 0;
}
+static ntfs_u64 div_by_power_of_2(ntfs_u64 numerator, int denominator)
+{
+ switch(denominator) {
+ case 0 :
+ printk("Division by zero error at div_by_power_of_2");
+ return 0;
+ case 1 :
+ return numerator ;
+ case 2 :
+ return numerator >> 1;
+ case 4 :
+ return numerator >> 2;
+ case 8 :
+ return numerator >> 3;
+ case 16 :
+ return numerator >> 4;
+ case 32 :
+ return numerator >> 5;
+ case 64 :
+ return numerator >> 6;
+ case 128 :
+ return numerator >> 7;
+ case 256 :
+ return numerator >> 8;
+ case 512 :
+ return numerator >> 9;
+ case 1024 :
+ return numerator >> 10;
+ case 2048 :
+ return numerator >> 11;
+ case 4096 :
+ return numerator >> 12;
+ case 8192 :
+ return numerator >> 13;
+ case 16384 :
+ return numerator >> 14;
+ case 32768 :
+ return numerator >> 15;
+ case 65536 :
+ return numerator >> 16;
+ case 131072 :
+ return numerator >> 17;
+ case 262144 :
+ return numerator >> 18;
+ case 524288 :
+ return numerator >> 19;
+ case 1048576 :
+ return numerator >> 20;
+ case 2097152 :
+ return numerator >> 21;
+ case 4194304 :
+ return numerator >> 22;
+ case 8388608 :
+ return numerator >> 23;
+ case 16777216 :
+ return numerator >> 24;
+ case 33554432 :
+ return numerator >> 25;
+ case 67108864 :
+ return numerator >> 26;
+ case 134217728 :
+ return numerator >> 27;
+ case 268435456 :
+ return numerator >> 28;
+ case 536870912 :
+ return numerator >> 29;
+ case 1073741824 :
+ return numerator >> 30;
+ case 2147483648U :
+ return numerator >> 31;
+ default :
+ printk("Not dividing by power of 2 in div_by_power_of_2!!");
+ return 0;
+ }
+ return 0;
+}
/*
* Writes the volume size into vol_size. Returns 0 if successful
* or error.
@@ -323,6 +399,7 @@
io.size=vol->clustersize;
ntfs_getput_clusters(vol,0,0,&io);
*vol_size = NTFS_GETU64(cluster0+0x28);
+*vol_size = div_by_power_of_2(*vol_size,(vol->clusterfactor));
ntfs_free(cluster0);
return 0;
}
-
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: 2.4.0-ac3 write() to tcp socket returning errno of -3 (ESRCH:"No such process")
Date: Mon, 8 Jan 2001 01:16:27 -0600 (CST) From: Paul Cassella <[EMAIL PROTECTED]> Would it be more helpful if I were to check something like socki_lookup(file->f_dentry->f_inode)->ops == tcp_prot instead? No, helpful would be for you to present us with a test case program and the network device configuration you are using. Are you using netfilter? Are you using tunneling, these sorts of things. Basically, the things we would need need to know to be able to duplicate your precise setup here locally in hopes of triggering the problem ourselves. 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: 2.4.0-ac3 write() to tcp socket returning errno of -3 (ESRCH:"No such process")
On Sun, 7 Jan 2001, David S. Miller wrote:
>Date: Sun, 7 Jan 2001 23:55:28 -0600 (CST)
>From: Paul Cassella <[EMAIL PROTECTED]>
>
>[1.] One line summary of the problem:
>
>write() returns -1 and sets errno non-sensically. 2.4.0{,-ac[23]}
>
> What you describe I can only say is "impossible".
Right. That's why the code g_error()'s there. :)
> None of them can occur via TCP socket writes (only netlink socket
> operations or socket control calls).
I didn't imagine that a TCP write could return any of these errors, which
is why I guessed that something's returning a value it thinks is positive,
but turns out to be negative in this case, for example, "return a - b;"
where due to, maybe, (but I guess not,) the peer shrunk window thing, a < b.
> Therefore I suspect you are perhaps getting rather some form of memory
> corruption or similar, really, please search the networking code for
> ESRCH value usage, you will see.
I believe that the tcp_sendmsg() path never tries to return -ESRCH, but I
don't see how userland memory corruption could cause the app to (1) open
such a socket instead of a TCP socket, and (2) get ESRCH or ENOEXEC
instead of EPERM or whatever a non-root process would get when it tried
such a thing.
I have seen no signs of bad memory on this machine, and of a fairly small
sample set, one (I was wrong when I said several) person is seeing the
same thing, with 2.4.0-test13-pre4, and I didn't see it with
2.4.0-test11-pre2.
The change I made to linux/fs/read_write.c:sys_write() checks
file->f_op == &socket_file_ops
and then finds ret == -3; presumably this is the same 3 that my app gets.
Would it be more helpful if I were to check something like
socki_lookup(file->f_dentry->f_inode)->ops == tcp_prot
instead? Or do the check in tcp_sendmsg()?
--
Paul Cassella
-
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] hashed device lookup (New Benchmarks)
Date:Mon, 08 Jan 2001 01:12:21 -0700 From: Ben Greear <[EMAIL PROTECTED]> http://grok.yi.org/~greear/hashed_dev.png (If you can't get to it, let me know and I'll email it to you...some cable modem networks have I firewalled.) It just seems that this shows that the implementation of ifconfig can be improved, since "ip" can do the same thing several orders of magnitude better (ie. non-quadratic system time complexity). This is the argument I started with when this thread began, so my position hasn't changed, it has in fact been well supported by your tests :-) 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/
3CCFE575CT problem in 2.4.0, Maybe a PCI subsystem bug
I've a 3CCFE575CT card. It is work fine in 2.2.18 kernel. But when I change to kernel 2.4.0, I found it could not detect as 2.2.18. I've report to pcmcia-cs maintainer, he suggest me to report this to here. #-- By: dahinds ( David Hinds ) Maybe a PCI subsystem bug [ reply ] 2001-Jan-08 13:24 I think you should try reporting it to Martin Mares, [EMAIL PROTECTED], or post the problem on linux-kernel. He is the PCI subsystem maintainer. Point out to him that the bus numbering for the CardBus bridge is bogus; I'm not sure if your BIOS or the kernel is at fault, but the kernel should correct this. With 2.2.18, the PCMCIA drivers detected the problem and made up new bus numbers. You could also try configuring your kernel to have PCMCIA support built in. Those drivers are somewhat different from the drivers in the standalone PCMCIA package and might behave differently. -- Dave #-- Here is my option.opts #-- # System resources available for PCMCIA devices include port 0x100-0x4ff, port 0x800-0x8ff, port 0xc00-0xcff include memory 0xc-0xf include memory 0xa000-0xa0ff, memory 0x6000-0x60ff # High port numbers do not always work... # include port 0x1000-0x17ff # Extra port range for IBM Token Ring include port 0xa00-0xaff #-- and here is my syslog for 2.4.0 kernel #-- Jan 7 13:37:36 tp240 kernel: Linux PCMCIA Card Services 3.1.22 Jan 7 13:37:36 tp240 kernel: kernel build: 2.4.0 #1 Sun Jan 7 12:13:36 CST 2001 Jan 7 13:37:36 tp240 kernel: options: [pci] [cardbus] [apm] Jan 7 13:37:36 tp240 kernel: Intel PCIC probe: PCI: Found IRQ 11 for device 00:0a.0 Jan 7 13:37:36 tp240 kernel: Jan 7 13:37:36 tp240 kernel: TI 1211 rev 00 PCI-to-CardBus at slot 00:0a, mem 0x1000 Jan 7 13:37:36 tp240 kernel: host opts [0]: [ring] [pci + serial irq] [pci irq 11] [lat 168/176] [bus 0/1] Jan 7 13:37:36 tp240 kernel: ISA irqs (scanned) = 3,4,7,9,10,15 PCI status changes Jan 7 13:37:36 tp240 cardmgr[177]: watching 1 sockets Jan 7 13:37:36 tp240 kernel: cs: IO port probe 0x0c00-0x0cff: clean. Jan 7 13:37:36 tp240 kernel: cs: IO port probe 0x0800-0x08ff: clean. Jan 7 13:37:36 tp240 kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177 0x370-0x377 0x398-0x39f 0x3b8-0x3df 0x4d0-0x4d7 Jan 7 13:37:36 tp240 kernel: cs: IO port probe 0x0a00-0x0aff: clean. Jan 7 13:37:36 tp240 kernel: cs: cb_alloc(bus 0): vendor 0x8086, device 0x7192 Jan 7 13:37:36 tp240 cardmgr[177]: initializing socket 0 Jan 7 13:37:36 tp240 cardmgr[177]: socket 0: Anonymous Memory Jan 7 13:37:36 tp240 anacron[186]: Anacron 2.1 started on 2001-01-07 Jan 7 13:37:36 tp240 cardmgr[177]: executing: 'modprobe memory_cs' #-- and here is my syslog for 2.2.18 kernel #-- Jan 7 14:24:04 tp240 kernel: Linux PCMCIA Card Services 3.1.22 Jan 7 14:24:04 tp240 kernel: kernel build: 2.2.18 #1 Sun Jan 7 13:15:14 CST 2001 Jan 7 14:24:04 tp240 kernel: options: [pci] [cardbus] [apm] Jan 7 14:24:04 tp240 kernel: PCI routing table version 1.0 at 0xfdf60 Jan 7 14:24:04 tp240 kernel: 00:0a.0 -> irq 11 Jan 7 14:24:04 tp240 kernel: Intel PCIC probe: Jan 7 14:24:04 tp240 kernel: TI 1211 rev 00 PCI-to-CardBus at slot 00:0a, mem 0x6800 Jan 7 14:24:04 tp240 kernel: host opts [0]: [ring] [pci + serial irq] [pci irq 11] [lat 168/176] [bus 32/34] Jan 7 14:24:04 tp240 kernel: ISA irqs (scanned) = 3,4,7,9,10,15 PCI status changes Jan 7 14:24:05 tp240 cardmgr[1752]: starting, version is 3.1.22 Jan 7 14:24:05 tp240 cardmgr[1752]: watching 1 sockets Jan 7 14:24:05 tp240 kernel: cs: IO port probe 0x0c00-0x0cff: excluding 0xcf8-0xcff Jan 7 14:24:05 tp240 kernel: cs: IO port probe 0x0800-0x08ff: clean. Jan 7 14:24:05 tp240 kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177 0x370-0x377 0x398-0x39f 0x3b8-0x3df 0x4d0-0x4d7 Jan 7 14:24:05 tp240 kernel: cs: IO port probe 0x0a00-0x0aff: clean. Jan 7 14:24:05 tp240 kernel: cs: cb_alloc(bus 32): vendor 0x10b7, device 0x5257 Jan 7 14:24:05 tp240 cardmgr[1752]: initializing socket 0 Jan 7 14:24:05 tp240 cardmgr[1752]: socket 0: 3Com 3CCFE575CT/3CXFE575CT Fast EtherLink XL Jan 7 14:24:05 tp240 cardmgr[1752]: executing: 'modprobe cb_enabler' Jan 7 14:24:05 tp240 cardmgr[1752]: + modprobe: Can't locate module cb_enabler Jan 7 14:24:05 tp240 cardmgr[1752]: modprobe exited with status 255 Jan 7 14:24:05 tp240 cardmgr[1752]: executing: 'insmod /lib/modules/2.2.18/pcmcia/cb_enabler.o' Jan 7 14:24:05 tp240 cardmgr[1752]: executing: 'modprobe 3c575_cb' Ja
Re: PROBLEM: SCSI hangs with aic7xxx in 2.4.0 SMP
Hello, On Sat, 6 Jan 2001 16:43:03 -0800, mull wrote: >On Sat, Jan 06, 2001 at 09:26:55PM -, Craig Freeze wrote: >> [1.] One line summary of the problem: >> SCSI hangs with aic7xxx in 2.4.0 SMP >> >> [2.] Full description of the problem/report: >> SCSI device errors and bus resets observed in 2.4.0 that do not occur in >> 2.2.13. Sysrq keys have no effect (ie hard reset required to recover) >> >I've noticed pretty much the same situation on my uniproc box, aic7xxx driver, >adaptec 2940uw card since going to 2.4.0-prerelease. haven't had to hard reset, but >have seen a LOT of scsi timeout errors. i did not notice this on 2.4.0-test12 or test13pre2. when i'm at home i'll see if i can find any pattern or more info, and also test with 2.4.0 final. >mullein >- >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/ > I have noticed nearly the same. When I try to backup (with BRU) from a SCSI disk to my SCSI HP DDS2 DAT the system hangs (SCSI LED on) no disc access possible. System: 2.4.0 / 2.4.0-ac3 driver: aic7xxx from 2.4.0 and aic7xxx from adaptec (lates version) compiler: kgcc (egcs) - 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 (repost): cramfs memory corruption fix
Rik van Riel <[EMAIL PROTECTED]> writes: > On Sun, 7 Jan 2001, Linus Torvalds wrote: > > On Sun, 7 Jan 2001, Alan Cox wrote: > > > > > -ac has the rather extended ramfs with resource limits and stuff. That one > > > also has rather more extended bugs 8). AFAIK none of those are in the > vanilla > > > > ramfs code > > > This is actually where I agree with whoever it was that said that ramfs as > > it stands now (without the limit checking etc) is much nicer simply > > because it can act as an example of how to do a simple filesystem. > > > > I wonder what to do about this - the limits are obviously useful, as would > > the "use swap-space as a backing store" thing be. At the same time I'd > > really hate to lose the lean-mean-clean ramfs. > > Sounds like a job for ... ... tmpfs!! If you need tmpfs the VFS layer is broken. For 99% of everything performance is determined by VFS layer caching. A fs that uses swap space as a backing store is not a big win. You just have a fs that doesn't support sync and you can add a mount option to a normal fs if you want that. I've written the filesystem and it was a dumb idea. Ramfs with (maybe) some basic limits has a place. tmpfs is just extra code to maintain. Eric - 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] hashed device lookup (New Benchmarks)
See a pretty graph showing performance of ifconfig and ip both with and without my device-hashed-lookup patch: http://grok.yi.org/~greear/hashed_dev.png (If you can't get to it, let me know and I'll email it to you...some cable modem networks have I firewalled.) I ran ifconfig -a and ip addr show every 50 interfaces, as I added 4000 interfaces, and used the 'time -p' program to find the system and user times. Summary: ifconfig scales badly, ip is better. Both ip and ifconfig work better with the hash patch, at least when the number of interfaces grows past 1000. If anyone wants the raw numbers, I can provide them and the script that generated them. NOTE: I stopped the non-hashed test after 3000 interfaces because it was just going too slow (ifconfig was killing me!) So, is this good enough reason to add the hashed patch? If not, I feel sure I can write a program that binds to a specific interface 10k times, and my assumption is that the hash will help significantly if there are lots of interfaces. However, I'd rather not go to the hassle if the ifconfig/ip numbers are sufficient. If no amount of benchmarking will change key player's minds, then go ahead and tell me now so that I can go back to hacking code and just include this patch with my VLAN patch. Thanks, Ben -- Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com Author of ScryMUD: scry.wanfear.com (Released under GPL) http://scry.wanfear.com http://scry.wanfear.com/~greear - 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.4.0test12: problems timing events
Hi, I tried to time events inside the kernel in 2.4.0test12: Basically the same code works fine in 2.2.18 with about 1us jitter. However in 2.4.0test12 the jitter is around 600ms! What I did is this: I modified the interrupt routine of the serial driver to get a precision time-stamp via do_gettimeofday(). So I guess either interrupts are delayed significantly from time to time, or the time routine has been changed to be no longer useful within interrupt routines. If anybody can enlighen me on this, I'd be happy. I'm not subscribed to linux-kernel, so maybe please CC: Regards, Ulrich - 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: DHCP Problems with 3com 3c905C Tornado
Sounds somewhat familiar. The pump that came with RedHat 6.2 never worked correctly at work, but dhcpcd worked just fine (we don't have static IP addresses, but there are fewer machines than there are addresses in the pool, so effectively, we do :-). The odd thing is that I (mis?)understood in this case that dhcpcd was not working either (unless I'm confusing this with a different thread). Suffice to say that newer versions of pump seem to work much better, at least for me. Tim On Mon, Jan 08, 2001 at 12:42:55AM +1100, Andrew Morton wrote: > Christian Loth wrote: > > > > Hello all, > > > > I recently installed a system with the 3c905C > > NIC on RedHat 6.2. In our network, IP adresses > > are granted via DHCP, although every host has > > a fixed IP instead of a dynamic IP pool. The IP > > is statically coupled with the MAC adresses of > > our network. > > Christian, > > I was able to reproduce this. All sorts of wierd stuff. > > All the problems magically disappeared after upgrading > to pump-0.8.6. > > You wouldn't *believe* how hard it is to find a pump > tarball, so I've put one at > > http://www.uow.edu.au/~andrewm/pump-0.8.6.tar.gz > > - > - > 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/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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] hashed device lookup (Does NOT meet Linus' sumissionpolicy!)
On Mon, 8 Jan 2001, Andi Kleen wrote: > Who says that it names a device? It names interfaces. > There are good reasons to have names for ifas, and I see no really good > convincing reasons not to put these names into the interface name space. > (in addition it'll save a lot of people a lot of grief) > When you're proposing a change that breaks thousands of configuration you > need a really good reason for it, and so far I cannot see one. It would > be different if the older way needed lots of hard to maintain fragile code in > the kernel, but that's really not the case. If people are upgrading to things like 2.6, then one must expect some changes. The eth0:0 style has already been whittled down, it has nothing now but the IP and mask info. It's a something between two styles. It encourages a non-scalable use. I.e. eth0:2342, or eth0:http. It came up because listing w/ ifconfig -a in it's current form wasn't satisfactorily fast. Distributions should be encouraged to use ip rather than ifconfig/route. It works better and does more, the output is more informative, more concise, and less confusing. It doesn't take that much more disk space than ifconfig and route does, ifconfig and route take 74K, ip takes 89K. I don't think 15k of disk space is sufficient concern, given that inodes are probably page size. That comes out to three pages difference. Even on a floppy that's not much. I didn't even compile optimized for size either. Due to that, 'eth0:n' becomes a byproduct without much merit. People who insist on eth0:n are probably people who also will insist on 1.2.13 for their router simply because they don't want or need to change it. The new form with the new tool is easier, especially if you have any cisco background. You can't beat 'ip a a 10.1.1.1/24 brd + dev eth0' for the netmask and figuring out the broadcast properly without error. It's shorter and less prone to error and more easily scriptable because you don't need a changing label. It's also more easily parsed by scripts. -d -- ---NOTICE--- fwd: fwd: fwd: type emails will be deleted automatically. "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President - 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: 2.4.0-ac3 write() to tcp socket returning errno of -3 (ESRCH: "No such process")
On Sun, Jan 07, 2001 at 11:55:28PM -0600, Paul Cassella wrote:
> [1.] One line summary of the problem:
>
> write() returns -1 and sets errno non-sensically. 2.4.0{,-ac[23]}
Would it be possible to provide a compiling test case that shows these
errors ?
Also over what interface do you run 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: [PATCH] hashed device lookup (Does NOT meet Linus' sumission policy!)
On Mon, Jan 08, 2001 at 07:12:09PM +1300, Chris Wedgwood wrote: > On Mon, Jan 08, 2001 at 06:32:14AM +0100, Andi Kleen wrote: > > I think it would be better to keep it. The ifa based alias > interface emulation adds minor overhead (currently it's only a > few lines of code, assuming we need named if addresses for other > reasons too, which we do) and removing it it would break a lot of > configuration scripts etc., for no really good gain. > > It's ugly and deceptive -- eth0:0 is _not_ a separate device to eth0, > so why pretend it is? Who says that it names a device? It names interfaces. There are good reasons to have names for ifas, and I see no really good convincing reasons not to put these names into the interface name space. (in addition it'll save a lot of people a lot of grief) When you're proposing a change that breaks thousands of configuration you need a really good reason for it, and so far I cannot see one. It would be different if the older way needed lots of hard to maintain fragile code in the kernel, but that's really not the case. -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: [OT] Re: [OT] Re: .br blacklisted ?
On Sun, 7 Jan 2001, Dmitri Pogosyan wrote: > Dan Hollis wrote: > > See Rowan v. United States Post Office. > Why necessarily should I care about United States Post Office > or United States in general ? I suspect canadian law has similar precedents. > > *Your* right to free speech stops at *my* property. > > Under no circumstances does your right to free speech trump the rights of > > the unwilling recipient. Full Stop. End of story. > Maybe in US, but still is it that clear ? Yep. If religious fuckwits show up on my doorstep pandering their salvation du jour and I point to the "no solicitation" sign, they can either leave voluntarily on their own, or involuntarily in police handcuffs. > What about TV commercials ? Can I request cable company not to transmit > them onto my property ? You can change the channel or turn off the TV. > If not, can your ISP require you to recieve spam/advertisement as > condition of service ? Perhaps, but I can always find another ISP. Of course, you could accept spam/advertisements as a condition of service (eg free ISPs like netzero). The key issue though is that you can always stop using the service and you won't receive any more spam from them. Spammers on the other hand continue sending pr0n/make-money-fast/fraud-schemes even when told to stop. And most relay-rape in order to send their spams. That's trespass. And you're condoning this? -Dan - 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: 2.4.0-ac3 write() to tcp socket returning errno of -3 (ESRCH: "Nosuch process")
Date:Sun, 7 Jan 2001 23:55:28 -0600 (CST)
From: Paul Cassella <[EMAIL PROTECTED]>
[1.] One line summary of the problem:
write() returns -1 and sets errno non-sensically. 2.4.0{,-ac[23]}
What you describe I can only say is "impossible".
There are only four cases when _ANY_ part of the ipv4 networking stack
can return ESRCH. These four cases are:
1) Adding a route
2) Deleting a route
3) Adding a FIB routing rule
3) Removing a FIB routing rule
None of them can occur via TCP socket writes (only netlink socket
operations or socket control calls).
Therefore I suspect you are perhaps getting rather some form of memory
corruption or similar, really, please search the networking code for
ESRCH value usage, you will see.
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/
[OT] Re: performance boost from merging linux-2.4.0, xfree86-4.02
On Sun, 7 Jan 2001, dep wrote: > for what it's worth: > > this afternoon i conducted an experiment: i copied everything that > was newer from > [xfree-4.02-sourcedir]/xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel > to my [linux-2.4.0-sourcedir]/drivers/char/drm and then built a > monolithic kernel containing agpgart, dri, and mga support. the > performance improvement is simply tremendous -- gears, for instance, > in the XscreenSavers module form, is running at at least 75 fps at > 1280x1024. really screaming. > > obviously, anybody wanting to play with this needs to backup > everything first. but i think the experiment is well worth it for > anyone competent to build a kernel and who is interested in the > potential of the dri stuff in X. > > this also suggests that probably the kernel dri stuff could stand an > update. Greetings, Can you (or anyone) point me to a clue-x-4 to get rid of this? (II) R128(0): Acceleration enabled (II) R128(0): Using hardware cursor (scanline 3606) (II) R128(0): Largest offscreen area available: 1600 x 5787 (**) Option "dpms" (**) R128(0): DPMS enabled (II) R128(0): Direct rendering disabled I've been wanting to see what X can do with dri for a while now, but alas the bugger isn't being cooperative. Any replies off list please. -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: [PATCH] hashed device lookup (Does NOT meet Linus' sumissionpolicy!)
On Mon, 8 Jan 2001, Andi Kleen wrote: > > If this is really true, 2.5.x is an appropriate time to make > > this, no sooner. > > I think it would be better to keep it. The ifa based alias interface > emulation adds minor overhead (currently it's only a few lines of code, > assuming we need named if addresses for other reasons too, which we do) > and removing it it would break a lot of configuration scripts etc., for > no really good gain. How about turning it out with a legacy/deprecated CONFIG_ option so we can prepare people. For now it can default to enabled. -d - 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: [OT] Re: [OT] Re: .br blacklisted ?
On Sun, 7 Jan 2001, Matt Beland wrote: > On Sunday 07 January 2001 21:24, Dan Hollis wrote: > > *This message was transferred with a trial version of CommuniGate(tm) Pro* > > On Sun, 7 Jan 2001, Gregory Maxwell wrote: > > > You are suggesting that it is acceptable to implement technological > > > barriers to a minority expressing speech that is unacceptable to the > > > majority. This is not acceptable. > > See Rowan v. United States Post Office. > > *Your* right to free speech stops at *my* property. > Does it now? How interesting. You can prohibit people from saying things you > don't like. No, I can prohibit people from forcing their drivel down my throat on my own property. Your right to spam doesn't give you the right to trespass. I'm sorry if that's too hard for you to comprehend. -Dan - 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: posix_types.h error
On Sun, 7 Jan 2001, Barry K. Nathan wrote: > Richard is asking for source code. Documentation/Changes only gives the > location of binaries. > > This is a bit of a problem IMO (I also tried, and failed, to find the egcs > 1.1.2 source code). Now that I know where it is, I'll soon post a patch > for Documentation/Changes... > ftp://egcs.cygnus.com/pub/gcc/old-releases/egcs/egcs-1.1.2.tar.bz2 -- Niels Kristian Bech Jensen -- [EMAIL PROTECTED] -- http://www.image.dk/~nkbj/ --->> Stop software piracy --- use free software! <<--- - 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] 2.4.0-ac4 : fs/qnx4/inode.c
Hello, While compiling 2.4.0-ac4, I receivied the following..Looks like a typo...Patch is also below. Regards, Frank inode.c: In function `qnx4_read_super':inode.c:372: `sb' undeclared (first use in this function)inode.c:372: (Each undeclared identifier is reported only onceinode.c:372: for each function it appears in.)make[2]: *** [inode.o] Error 1make[2]: Leaving directory `/usr/src/linux/fs/qnx4'make[1]: *** [_modsubdir_qnx4] Error 2make[1]: Leaving directory `/usr/src/linux/fs'make: *** [_mod_fs] Error 2 --- fs/qnx4/inode.c.old Mon Jan 8 00:00:35 2001+++ fs/qnx4/inode.c Mon Jan 8 00:38:51 2001@@ -369,7 +369,7 @@ } s->s_op = &qnx4_sops; s->s_magic = QNX4_SUPER_MAGIC;- sb->s_maxbytes = 0x7FFF;+ s->s_maxbytes = 0x7FFF; #ifndef CONFIG_QNX4FS_RW s->s_flags |= MS_RDONLY; /* Yup, read-only yet */ #endif
Broken tty handling
Every once in a while I have a very frustrating problem develop. All tty handling stops. Packets flow in and out of the machine fine, but anything with a tty halts. I don't know exactly what is happening but I have found that killing the last user that logged in (all his processes) usually fixes everything. It just happened to me and I realize this is vague but there's nothing I have been able to attribute it to other than a problem in tty handling. I know it isn't ssh v.s. telnet v.s. xyz because it doesn't matter, they all stall. Here's the data I had. Aaron was the last person to log in when it broke, I was the first after it broke. # grep aaron brokettyspseo aaron22843 do_adj -bash aaron22865 write_ pine aaron23211 do_adj -bash aaron23228 tty_wa stty icanon echo aaron23277 read_c -bash # w|grep aaron .aaronpts/13 dur-cas1-cs-26.d 9:12pm 26:44 0.14s 0.10s pine .aaronpts/14 dur-cas1-cs-26.d 9:28pm 15:09 0.01s 0.01s -bash .aaronpts/15 dur-cas1-cs-26.d 9:29pm 14:26 0.06s 0.06s -bash An 'skill aaron' didn't solve it but 'skill -9 aaron' did. Here's a snippet from my /etc/profile which the stty from above comes into play: # does the user want his titlebar set? if [ "x$TITLEBAR" = "xyes" ]; then echo -ne Checking for titlebar capability stty -icanon -echo min 0 time 20 echo -ne '\033[7n' read term_id display=$(echo $term_id|sed '/.*:0/!d') if [ x$display != x ]; then PS1='\[\033]2; ($(date +%l:%M%p)) \u@\h \w\007\033]1;\u@\h\007\]\$ ' else PS1='\h:\w\$ ' fi echo -ne '\033[2K\r' stty icanon echo else PS1='\h:\w\$ ' fi # uname -r 2.4.0-test11 # sed '/C [lL]ibrary /!d; s/[^0-9]*\([0-9.]*\).*/\1/' /lib/libc.so.6 2.1.3 # mount|grep pts none on /dev/pts type devpts (rw,gid=5,mode=640) Any suggestions? Should this be addressed elsewhere? The reason I bring it up here is because ALL ttys halt except those on the console. -d -- ---NOTICE--- fwd: fwd: fwd: type emails will be deleted automatically. "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President - 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: Subtle MM bug
In article <[EMAIL PROTECTED]>, Andi Kleen <[EMAIL PROTECTED]> wrote: >On Sun, Jan 07, 2001 at 09:29:29PM -0800, Wayne Whitney wrote: >> The application is some mathematics computations (modular symbols) using a >> package called MAGMA; at times this requires very large matrices. The >> RSS can get up to 870MB; for some reason a MAGMA process under linux >> thinks it has run out of memory at 870MB, regardless of the actual >> memory/swap in the machine. MAGMA is single-threaded. > >I think it's caused by the way malloc maps its memory. >Newer glibc should work a bit better by falling back to mmap even for smaller >allocations (older does it only for very big ones) That doesn't resolve the "2.4.x behaves badly" thing, though. I've seen that one myself, and it seems to be simply due to the fact that we're usually so good at gettign memory from page_launder() that we never bother to try to swap stuff out. And when we _do_ start swapping stuff out it just moves to the dirty list, and page_launder() will take care of it. So far so good. The problem appears to be that we don't swap stuff out smoothly: we start doing the VM scanning, but when we get enough dirty pages, we'll let it be, and go back to page_launder() again. Which means that we don't walk theough the whole VM space, we just do some "spot cleaning". 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: [OT] Re: [OT] Re: .br blacklisted ?
On Sun, 7 Jan 2001, Gregory Maxwell wrote: > On Sun, Jan 07, 2001 at 08:24:16PM -0800, Dan Hollis wrote: > > On Sun, 7 Jan 2001, Gregory Maxwell wrote: > > > You are suggesting that it is acceptable to implement technological > > > barriers to a minority expressing speech that is unacceptable to the > > > majority. This is not acceptable. > > See Rowan v. United States Post Office. > > *Your* right to free speech stops at *my* property. > > Under no circumstances does your right to free speech trump the rights of > > the unwilling recipient. Full Stop. End of story. > Your right to 'not listen' ends when it becomes attempt to manipulate > companies and government to immorally limit speech of mine which does not > affect you in any way. I have a "no solicitation" and "no trespassing" sign on my property. Tough noogies if you think it's immoral. Doesn't give you the right to trespass on my property to stuff my mailbox with your stupid drivel. -Dan - 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.4.0-ac3 write() to tcp socket returning errno of -3 (ESRCH: "Nosuch process")
[1.] One line summary of the problem:
write() returns -1 and sets errno non-sensically. 2.4.0{,-ac[23]}
[2.] Full description of the problem/report:
write() sometimes returns -1 and sets errno to one of
1 (EPERM: "Operation not permitted")
3 (ESRCH: "No such process")
8 (ENOEXEC: "Exec format error")
1 seems to be the most common.
I have verified that at least the ESRCH case is caused by the kernel.
With the following patch to sys_write(),
--- fs/read_write.c~ Sat Nov 11 18:07:38 2000
+++ fs/read_write.cSun Jan 7 14:00:25 2001
@@ -146,6 +146,8 @@
ssize_t ret;
struct file * file;
+extern struct file_operations socket_file_ops;
+
ret = -EBADF;
file = fget(fd);
if (file) {
@@ -165,6 +167,18 @@
DN_MODIFY);
fput(file);
}
+ if(ret < 0 && file && file->f_op == &socket_file_ops ) {
+ switch(-ret) {
+ case EAGAIN: case EBADF: case EPIPE: case ENOSPC: case EIO: case
+ECONNRESET:
+ case EINTR: case ETIMEDOUT: case EFAULT: case EINVAL: case EMSGSIZE:
+case ENOMEM:
+ case ENOBUFS: case ENOTCONN:
+ break;
+
+ default:
+ printk(KERN_ERR "sys_write: ret is unexpectedly %d.\n", ret);
+ }
+ }
+
return ret;
}
and socket_file_ops made non-static, I eventually got this logged:
Jan 7 22:15:29 localhost kernel: sys_write: ret is unexpectedly -3.
And this user code:
r = write(fd_that_is_a_tcp_socket, ...);
if (r > 0) { ...
} else if(r == 0) { ...
} else if (errno == EAGAIN || errno == EINTR) { ...
} else if (errno == EPIPE || errno == ENOSPC || errno == EIO || errno == ECONNRESET ||
errno == ETIMEDOUT) { ...
} else {
g_error("node_write: write failed with unexpected errno: %d (%s)\n", errno,
g_strerror(errno));
}
at the same time produced
** ERROR **: node_write: write failed with unexpected errno: 3 (No such process)
aborting...
This socket is O_NONBLOCK'd, as well as SO_KEEPALIVE'd and SO_REUSEADDR'd,
and was an outgoing connection.
TCP ECN is on. Syncookies are compiled in but turned off.
This app has previously failed with the same thing for errno's 1 and 8,
but without the kernel change to verify that those values are actually
coming from the kernel.
That had happened on 2.4.0, 2.4.0-ac2, and 2.4.0-ac3. I didn't notice it
on 2.4.0-test11-pre2, which was the last kernel I'd been running. But
the problem's not particularly deterministic, and I may not have been
running it long enough. At least two other people are seeing the same
thing on 2.4 kernels.
My guess is that something mistakenly thinks it's returning a positive
number.
[3.] Keywords (i.e., modules, networking, kernel):
networking
[4.] Kernel version (from /proc/version):
Linux version 2.4.0-ac3 (fortytwo@manetheren) (gcc version 2.95.2 2220 (Debian
GNU/Linux)) #4 Sun Jan 7 16:18:26 CST 2001
The machine and kernel are UP.
[6.] A small shell script or example program which triggers the
problem (if possible)
This happens after the app runs usually for several hours with lots of
outgoing and incoming TCP connections to lots of different hosts.
[7.1.] Software (add the output of the ver_linux script here)
Linux manetheren 2.4.0-ac3 #4 Sun Jan 7 16:18:26 CST 2001 i686 unknown
Kernel modules 2.3.23
Gnu C 2.95.2
Gnu Make 3.79.1
Binutils 2.10.1.0.2
Linux C Library> libc.2.2
Dynamic linker ldd (GNU libc) 2.2
Procps 2.0.6
Mount 2.10q
Net-tools 2.05
Console-tools 0.2.3
Sh-utils 2.0.11
Modules Loaded parport_pc lp parport rtc usbcore
[7.2.] Processor information (from /proc/cpuinfo):
[7.3.] Module information (from /proc/modules):
[7.5.] PCI information ('lspci -vvv' as root)
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
These doesn't seem particularly relevant, so I'm putting them, as well as
.config, at
http://manetheren.eigenray.com/~fortytwo/bad_write_info
Don't hesitate to ask me for more info or to try a patch or something.
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
In 2.4.0 and -ac2, I was getting the reset_xmit_timer() messages that -ac3
fixed. I'm also getting TCP peer shrinks window messages, but had none
this boot before this error.
--
Paul Cassella
-
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: Subtle MM bug
On Sun, Jan 07, 2001 at 09:29:29PM -0800, Wayne Whitney wrote: > The application is some mathematics computations (modular symbols) using a > package called MAGMA; at times this requires very large matrices. The > RSS can get up to 870MB; for some reason a MAGMA process under linux > thinks it has run out of memory at 870MB, regardless of the actual > memory/swap in the machine. MAGMA is single-threaded. I think it's caused by the way malloc maps its memory. Newer glibc should work a bit better by falling back to mmap even for smaller allocations (older does it only for very big ones) -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: [PATCH] mm/mmap.c find_vma(), kernel 2.4.0
> > > On Mon, 8 Jan 2001, Robert Wienholt, Jr. wrote: > > > Gentlemen, > > > > I was looking through some of the memory management code today and > > came across something that may provide a minor performance boost. I have > > included a patch below for the 2.4.0 source. > > > > In the find_vma function a cached vma is checked and if that is > > not the requested vma, the linked list (unless there's an avl tree) is > > traversed from the beginning. My thought was that if the cached vma is > > somewhere in the middle of a "long" list, and the memory address we are > ^^ > No such thing. If you get many VMAs you get AVL tree and that's what is > used for search. > Well, that's why I put the "long" in quotes. If the cached vma is the 10th in the list and we're looking for the 12th... we'll go through the traversal loop twice instead of 12 times. That's the point I was trying to make. But if we're looking for the 3rd... we'll just start at the beginning and no harm was done. - 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] hashed device lookup (Does NOT meet Linus' sumission policy!)
On Sun, Jan 07, 2001 at 04:01:04AM -0800, David S. Miller wrote: >Date: Mon, 8 Jan 2001 01:13:08 +1300 >From: Chris Wedgwood <[EMAIL PROTECTED]> > >OK, I'm a liar -- bind does handle this. Cool. > > Standard BSD allows it, what do you expect :-) > >This is good news, because it means there is a precedent for multiple >addresses on a single interface so we can kill the : >syntax in favor of the above which is cleaner of more accurately >represents what is happening. > > If this is really true, 2.5.x is an appropriate time to make > this, no sooner. I think it would be better to keep it. The ifa based alias interface emulation adds minor overhead (currently it's only a few lines of code, assuming we need named if addresses for other reasons too, which we do) and removing it it would break a lot of configuration scripts etc., for no really good gain. -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: Subtle MM bug
On Sunday, January 7, 20001, Rik van Riel <[EMAIL PROTECTED]> wrote: > Now if 2.4 has worse _performance_ than 2.2 due to one reason or > another, that I'd like to hear about ;) Well, here is a workload that performs worse on 2.4.0 than on 2.2.19pre, and as it is the usual workload on my little cluster of 3 machines, they are all running 2.2.19pre: The application is some mathematics computations (modular symbols) using a package called MAGMA; at times this requires very large matrices. The RSS can get up to 870MB; for some reason a MAGMA process under linux thinks it has run out of memory at 870MB, regardless of the actual memory/swap in the machine. MAGMA is single-threaded. The typical machine is a dual Intel box with 512MB RAM and 512MB swap. There is no problem with just one MAGMA process, it just hits that 870MB barrier and gracefully exits. But if I do the following test, I notice very different behaviour under 2.2 and 2.4: while running 'top d 1' I simultaneously launch two instances of a job which actually requires more than 870MB of memory to complete. So each instance will slowly grow in RSS until it gets killed by OOM or hits that 870MB limit. Under 2.2, everything proceeds smoothly: before physical RAM is exhausted, top updates every second, and the jobs have all the CPU. When swapping kicks in, top updates every 1-2 seconds and lists most of the CPU as 'system' (kswapd), but I perceive not much loss of interactivity. Eventually the 1GB of virtual memory is exhausted, the OOM killer kills one of the MAGMA's, and the other runs till it hits the 870MB barrier and exits. But under 2.4, interactivity suffers as soon as physical RAM is exhausted. Top only updates every 2-10 seconds, the load average hits 3-4, and top reports the CPUs are 90% idle. Eventually, the OOM killer kicks in and all returns to normal. For practical purposes, the machine is unusual while swapping like this. I have heard 'vmstat' mentioned here, so below is the output of a 'vmstat 1' concommitant with the test above (top and the two MAGMA jobs). I would be more than happy to provide any other relevant information about this. I read the LKML via an archive that updates once a day, so please cc: me if you would like a speedier response. I wish I knew of a newsgroup interface to the LKML, then I could read it more often :-). Cheers, Wayne procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 0 0 0 49180 447840840 54104 269 96984 244 76 236 10 4 86 1 0 0 49180 443276852 55972 0 0 470 0 163 150 15 2 83 2 0 0 49180 440060852 56292 0 080 0 11560 93 1 6 2 0 0 49180 438236856 56292 0 0 1 0 10753 99 1 0 2 0 0 49180 429468856 56392 0 025 0 10916 99 0 0 2 0 0 49180 421296856 56392 0 0 0 0 10413 98 2 0 2 0 0 49180 421132856 56392 0 0 0 0 10853 100 0 0 2 0 0 49180 421128856 56392 0 0 0 0 10847 100 0 0 2 0 0 49180 397520856 56392 0 0 0 1 10749 96 4 0 2 0 0 49180 364860856 56392 0 0 0 0 10647 95 5 0 2 0 0 49180 332244856 56392 0 0 0 0 10649 95 5 0 2 0 0 49180 299660856 56392 0 0 0 0 10654 92 8 0 2 0 0 49180 267076856 56392 0 0 0 0 10956 95 5 0 2 0 0 49180 234632856 56392 0 0 0 0 11057 94 6 0 2 0 0 49180 202096872 56448 32 018 0 11770 95 5 0 2 0 0 49180 169544872 56448 0 0 0 0 10313 96 4 0 2 0 0 49180 137108872 56448 0 0 0 0 10749 93 7 0 2 0 0 49180 104600872 56448 0 0 0 0 10751 94 6 0 2 0 0 49180 72368872 56448 0 0 052 13654 93 7 0 2 0 0 49180 39964872 56448 0 0 0 0 11059 92 8 0 2 0 2 7296 1576 96 13072 0 720 0 184 130 465 74 22 4 procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 1 2 2 53620 1564116 23512 1012 31876 565 7969 883 3802 1 8 92 2 1 2 68800 1560 96 20128 68 1539617 3850 291 2775 1 7 92 3 0 1 99484 1556 96 26096 84 2955221 7388 594 3832 1 4 95 1 3 2 114708 1560104 32528 284 14696 161 3674 374 3125 0 4 96 1 4 2 175484 1560124 31112 360 63000 237 15753 1404 14952 1 5 94 1 2 2 205900 1560 96 32748 12 30080 3 7520 606 8356 1 5 94 2 1 2 221156 1560 96 17848 412 14256 103 3564 308 8450 1 10 89 1 2 2 222128 1564 96 12736 0 1
Re: posix_types.h error
On Sun, 7 Jan 2001, Barry K. Nathan wrote: > Mike Galbraith wrote: > > On Sun, 7 Jan 2001, Richard B. Johnson wrote: > [snip] > > > None of the named compilers gripe? Where, prey tell, do I get the source- > > > code of a compiler that works? The only source provided in the site > > > listed in the Documentation does not. > > > > It's not the only source there.. egcs-1.1.2 is there as well. You can > > also try egcs.cygnus.com/pub/egcs or a mirror. > > Richard is asking for source code. Documentation/Changes only gives the > location of binaries. Oops.. didn't notice that there was no source in the egcs-1.1.2 directory. > This is a bit of a problem IMO (I also tried, and failed, to find the egcs > 1.1.2 source code). Now that I know where it is, I'll soon post a patch > for Documentation/Changes... Good idea. -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: Change of policy for future 2.2 driver submissions
Actually, I have another reason for using patch-kernel, besides being inexperienced or lazy: being weird. :-) For some reason, I have an aversion to downloading complete kernels, and just grab the patches. That's usually OK, because I apply each patch one at a time, within a few hours after it comes out. But once in a while I mess up and have to start over -- like a few days ago, when I forgot to reverse prelease-diff before trying to apply 2.4.0-prelease-to-final. I got the kernel source tree hosed up so badly that I decided to blow it all away and get a clean copy. Instead of doing the sensible thing -- getting a fresh copy of 2.4.0 -- I untarred 2.2.16 (the most recent tarball I had), reverse-patched it down to 2.2.8, applied patch-2.2.8-to-2.3.0, used patch-kernel to get up to 2.3.51, then applied the patches for 2.3.99-pre1 through -pre9 and 2.4.0-test1 through -test12, and finally 2.4.0-prelease and 2.4.0-prerelease-to-final. Sure, it's insane, but it's not as tedious as it sounds, since I put together a script to do all this (and it doesn't take all that long on my Pentium III, especially if I shut down X first). Anyway, I've kind of been hoping that now that 2.4.0 is out, maybe future patches will go back to the x.y.z format so I could just let patch-kernel do everything. Wayne [EMAIL PROTECTED] (Nick Holloway) on 01/06/2001 04:15:53 AM To: [EMAIL PROTECTED] cc:(bcc: Wayne Brown/Corporate/Altec) Subject: Re: Change of policy for future 2.2 driver submissions In <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes: > Either I'm blind, or especially dense today, or both (quite possible :-) but I > don't see any reference in patch-kernel to the extra version information. > EXTRAVERSION is defined in the kernel Makefile, and I tried using the script > found in the 2.4.0-test1 source like this: > > patch-kernel /usr/src/linux /pub/linux/kernel/v2.4/test-kernels > > but the test-2 and following patches are not applied. All I get is "Current > kernel version is 2.4.0." What am I missing? The distributed version of patch-kernel has only ever known about the "standard" progression x.y.z => x.y.z+1. This all gets horribly broken when Linus gets imaginative with his kernel numbering. I have said before that I thought this was OK, because the people that need to cope with the EXTRAVERSION guff are people on the development branch, and should be able to patch the kernel themselves. The main users of patch-kernel are less experienced people. However, this does conflict with the aim of getting users into testing kernels late in the development branch cycle. It also affects people like me who are lazy. I don't think that getting the kernel version to support the naming scheme du-jour will work, as this would require Linus to update patch-kernel when he dreams up a new scheme -- and Linus is the one person I'm fairly sure does not use it! For myself, I have a version of patch-kernel that does know how to deal with the wacky naming versions (because I'm lazy). In future I'll make this available to anyone that wants to download it for their own use, but I won't push to get it included. A (temporary) location for the current version is: http://www.alfie.demon.co.uk/download/patch-kernel -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.uk/ - 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: [PATCH] mm/mmap.c find_vma(), kernel 2.4.0
On Mon, 8 Jan 2001, Robert Wienholt, Jr. wrote: > Gentlemen, > > I was looking through some of the memory management code today and > came across something that may provide a minor performance boost. I have > included a patch below for the 2.4.0 source. > > In the find_vma function a cached vma is checked and if that is > not the requested vma, the linked list (unless there's an avl tree) is > traversed from the beginning. My thought was that if the cached vma is > somewhere in the middle of a "long" list, and the memory address we are ^^ No such thing. If you get many VMAs you get AVL tree and that's what is used for search. - 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/
Normal Response Mode of HDLC for linux
Hi all, Has anybody written any support for HDLC normal response mode. I could only find the support of HDLC asynchronous balanced mode (LAPB). Any pointers will highly be appreciated. Thanks, Anil - 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] mm/mmap.c find_vma(), kernel 2.4.0
Gentlemen,
I was looking through some of the memory management code today and
came across something that may provide a minor performance boost. I have
included a patch below for the 2.4.0 source.
In the find_vma function a cached vma is checked and if that is
not the requested vma, the linked list (unless there's an avl tree) is
traversed from the beginning. My thought was that if the cached vma is
somewhere in the middle of a "long" list, and the memory address we are
looking for is past the vm_end of the cached vma, well, the traversal can
just start at the next vma after the one that was cached.
I put in some code to count the number of times my change took the
vma after the cached one and the number of times it went the other way.
Through these simple counts I determined that the requested vma was after
the cached one about 46% of the time.
Anyway, this is a simple patch and may not make that much of a
difference in performance but hey, this is my first time submitting a
patch and I decided to start small. I would be interested in hearing any
feedback from the mm gurus out there.
--
+--+--+
| Robert Wienholt, Jr. | Legion Technologies, LLC |
| Lead Programmer | 8910 Whitetail Ct. |
| [EMAIL PROTECTED] | Perry Hall, MD 21128 |
+--+--+
--- linux-2.4.0/mm/mmap.c Sat Dec 30 12:35:19 2000
+++ linux/mm/mmap.c Sun Jan 7 20:35:59 2001
@@ -413,7 +413,20 @@
if (!(vma && vma->vm_end > addr && vma->vm_start <= addr))
{
if (!mm->mmap_avl) {
/* Go through the linear list. */
- vma = mm->mmap;
+
+ /*
+ If we missed the cache, check to see if the
+memory area
+ would be after the cached one and start the
+list walk
+ from there.
+
+ RGW -- 01/07/2001
+ */
+
+ if (vma && vma->vm_end <= addr)
+ vma = vma->vm_next;
+ else
+ vma = mm->mmap;
+
while (vma && vma->vm_end <= addr)
vma = vma->vm_next;
} 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: [PATCH] More Configure.help fixes
As per usual, when sending a mail with an attachment, I forgot to
attach it after I :wq'd.
--
Jeremy M. Dolan <[EMAIL PROTECTED]>
OpenPGP key = http://turbogeek.org/openpgp-key
OpenPGP fingerprint = 494C 7A6E 19FB 026A 1F52 E0D5 5C5D 6228 DC43 3DEE
diff -rub 2.4.0/Documentation/Configure.help linux/Documentation/Configure.help
--- 2.4.0/Documentation/Configure.help Fri Jan 5 09:19:30 2001
+++ linux/Documentation/Configure.help Sun Jan 7 22:13:09 2001
@@ -1,7 +1,7 @@
# Maintained by Axel Boldt ([EMAIL PROTECTED])
#
# This version of the Linux kernel configuration help texts
-# corresponds to the kernel versions 2.3.x.
+# corresponds to the kernel versions 2.4.x.
#
# Translations of this file available on the WWW:
#
@@ -13,8 +13,10 @@
# http://www.traduc.org/kernelfr
# - Spanish, by Carlos Perelló Marín ([EMAIL PROTECTED]), at
# http://visar.csustan.edu/~carlos/
+# XXX: Site has moved, new location has no Configure.help trans.
# - Italian, by Alessandro Rubini ([EMAIL PROTECTED]), at
# ftp://ftp-pavia1.linux.it/pub/linux/Configure.help
+# XXX: ftp-pavia1.linux.it: Non-existent host/domain
# - Polish, by Cezar Cichocki ([EMAIL PROTECTED]), at
# http://www.cs.net.pl/~cezar/Kernel
# - German, by SuSE, at http://www.suse.de/~ke/kernel . This patch
@@ -113,8 +115,8 @@
Management" code will be disabled if you say Y here.
See also the files Documentation/smp.tex, Documentation/smp.txt,
- Documentation/i386/IO-APIC.txt, Documentation/nmi_watchdog.txt and the
- SMP-FAQ on the WWW at http://www.irisa.fr/prive/mentre/smp-faq/ .
+ Documentation/i386/IO-APIC.txt, Documentation/nmi_watchdog.txt and
+ the SMP-FAQ on the WWW at http://www.irisa.fr/prive/mentre/smp-faq/
If you don't know what to do here, say N.
@@ -1514,7 +1516,7 @@
CONFIG_RAID15_DANGEROUS
This new RAID1/RAID5 code has been freshly merged, and has not seen
enough testing yet. While there are no known bugs in it, it might
- destroy your filesystems, eat your data and start World War III.
+ destroy your file systems, eat your data and start World War III.
You have been warned.
If unsure, say N.
@@ -1879,8 +1881,8 @@
MAC address match support
CONFIG_IP_NF_MATCH_MAC
- mac matching allows you to match packets based on the source
- ethernet address of the packet.
+ MAC matching allows you to match packets based on the source
+ Ethernet address of the packet.
If you want to compile it as a module, say M here and read
Documentation/modules.txt. If unsure, say `N'.
@@ -4175,7 +4177,7 @@
packets with different FWMARK ("firewalling mark") values
(see ipchains(8), "-m" argument).
-Appletalk interfaces support
+AppleTalk interfaces support
CONFIG_APPLETALK
AppleTalk is the way Apple computers speak to each other on a
network. If your Linux box is connected to such a network and you
@@ -4790,7 +4792,7 @@
Routing messages
CONFIG_RTNETLINK
- If you say Y here, userspace programs can receive some network
+ If you say Y here, user space programs can receive some network
related routing information over the netlink. 'rtmon', supplied
with the iproute2 package (ftp://ftp.inr.ac.ru), can read and
interpret this data. Information sent to the kernel over this link
@@ -6880,7 +6882,7 @@
PPP (Point to Point Protocol) is a newer and better SLIP. It serves
the same purpose: sending Internet traffic over telephone (and other
serial) lines. Ask your access provider if they support it, because
- otherwise you can't use it; most internet access providers these
+ otherwise you can't use it; most Internet access providers these
days support PPP rather than SLIP.
To use PPP, you need an additional program called pppd as described
@@ -9883,7 +9885,7 @@
Memory Technology Device (MTD) support
CONFIG_MTD
Memory Technology Devices are flash, RAM and similar chips, often
- used for solid state filesystems on embedded devices. This option
+ used for solid state file systems on embedded devices. This option
will provide the generic support for MTD drivers to register
themselves with the kernel and for potential users of MTD devices
to enumerate the devices which are present and obtain a handle on
@@ -9900,14 +9902,14 @@
This provides an MTD device driver for the M-Systems DiskOnChip
2000 devices. If you use this, you probably also want the NFTL
'NAND Flash Translation Layer' below, which is used to emulate
- a block device by using a kind of filesystem on the flash chips.
+ a block device by using a kind of file system on the flash chips.
M-Systems Disk-On-Chip Millennium support
CONFIG_MTD_DOC2001
This provides an MTD device driver for the M-Systems DiskOnChip
Millennium devices. If you use this, you probably also want the
NFTL 'NAND Flash Translation Layer' below, which is used to emulate
- a block device by using a kind of filesystem on the flash chips.
+ a block device by using a kind of file
Re: [OT] Re: [OT] Re: .br blacklisted ?
On Sunday 07 January 2001 21:24, Dan Hollis wrote: > *This message was transferred with a trial version of CommuniGate(tm) Pro* > > On Sun, 7 Jan 2001, Gregory Maxwell wrote: > > You are suggesting that it is acceptable to implement technological > > barriers to a minority expressing speech that is unacceptable to the > > majority. This is not acceptable. > > See Rowan v. United States Post Office. > > *Your* right to free speech stops at *my* property. Does it now? How interesting. You can prohibit people from saying things you don't like. Hmmm. I suppose that could be useful. I don't like (just as an example) any speech from or about people named Dan. Please cease and desist immediately or I will blackhole you, your server, your domain, and everyone and everything associated with it until the people rise up and kill everyone named Dan, or as an acceptable compromise, remove their ability to speak and or type, or force them to change their names. That's my right, it's my property. Morally wrong? Bah. Your right to prattle on about morality stops at my property. Point 1: Laws mean jack squat in this case. The lawmakers know little about the internet, and until they learn, the laws they pass will continue to be irrelevant, confusing, or contradictory. Even when they aren't, no society has ever managed a foolproof "unjust law filter". The existence of a law does not make that law good, correct, or even legal; reference prohibition, slave ownership, women's sufferage or the lack thereof, and roughly 40% of the US Tax Code referencing income tax. Point 2: Either "information wants to be free", has no physical existence or worth, and cannot be controlled, or it has existense, worth, and can be controlled as property. You can't have it both ways; either Spam is an undesirable side effect of the free flow of information, or information is not free and can be controlled. Isn't it amazing how some of the people who are so quick to yell when Microsoft or Oracle or the government of infringes on their rights/privacy/information are the first to block the flow of information in the name of the same? > > Under no circumstances does your right to free speech trump the rights of > the unwilling recipient. Full Stop. End of story. > > -Dan > > - > 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: [OT] Re: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 08:24:16PM -0800, Dan Hollis wrote: > On Sun, 7 Jan 2001, Gregory Maxwell wrote: > > You are suggesting that it is acceptable to implement technological > > barriers to a minority expressing speech that is unacceptable to the > > majority. This is not acceptable. > > See Rowan v. United States Post Office. > > *Your* right to free speech stops at *my* property. > > Under no circumstances does your right to free speech trump the rights of > the unwilling recipient. Full Stop. End of story. Your right to 'not listen' ends when it becomes attempt to manipulate companies and government to immorally limit speech of mine which does not affect you in any way. - 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] More Configure.help fixes
Dag Wieers caught all the double word's in Configure.help (from the looks of the patch we're quite a bunch of stutterers), here's another patch that catches mainly some combined words, a '2.3' -> '2.4', and inproper capitalizations. Also, two of the translation's for Configure.help have stale URL's... I've XXX'd them, and sent a mail to the addresses for the maintainers of the Spanish and Italian translation to see if there is a new URL. The patch applies to 2.4.0 clean and to -ac4 with a bunch of offset warnings, but manages to match all the hunks. (go, patch!) -- Jeremy M. Dolan <[EMAIL PROTECTED]> OpenPGP key = http://turbogeek.org/openpgp-key OpenPGP fingerprint = 494C 7A6E 19FB 026A 1F52 E0D5 5C5D 6228 DC43 3DEE - 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: Network Performance?
On Sat, Jan 06, 2001 at 10:11:40PM +1100, Andrew Morton wrote: > this issue was discussed on the netdev mailing list a few weeks > back. > > It's very unfortunate that the web archives of netdev > stopped working several months ago and there now appears > to be no web archive of [EMAIL PROTECTED] > > Go to http://oss.sgi.com/projects/netdev/archive/ and > pull down the November and December archives. > > The subject was "linux to solaris tcp issues on WAN". > > The conclusion was "The problem is also fixed with > 2.4.0-test12pre3". Dunno about kernel 2.2 though. Well, on Friday, we pulled down the 'official' 2.4.0, and had the same experience... nothing better. Should I get the -test12-pre3 kernel and try that one specifically? Tim -- Tim Sailer <[EMAIL PROTECTED]> Cyber Security Operations Brookhaven National Laboratory (631) 344-3001 - 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] VM fixes + RSS limits 2.4.0-test13-pre5
Ingo wrote: > On Wed, Jan 03, 2001 at 09:43:54AM -0200, Rik van Riel wrote: > > On Fri, 28 Dec 2000, Mike Sklar wrote: > > > If I wanted to adjust the rlim_cur value of a running > > > processes, is there any sort of interface for that? > > > > Hmmm, I don't think there is an interface to adjust the > > per-process ulimit settings on-the-fly ... > > > > Does anybody know if there's an interface for this ? > If you don't mean "kill -TERM", no there isn't. It would be evil > to the process anyway. The RSS limits patch I sent to linux-kernel some time ago provided an experimental /proc interface to allow exactly this. The patch against 2.2.16 is still on our FTP server at ftp://ftp-au.aurema.com/private/aurpjc31/linux-2216-rsslimit.diff.bz2 Here's the patch against 2.4.0. The main differences between this and Rik's patch are: -- you choose soft or hard limits at kernel config time with my patch; with Rik's you get both (rlim_cur is `soft' rlim_max is `hard') -- Rik's patch does some extra stuff to the VM code as well as the RSS limits -- Rik's patch doesn't affect swap behaviour (except in so far as processes over their RSS limit will tend to swap, which reduces memory pressure on all other processes); my patch means that processes over RSS limit suffer somewhat -- My patch puts the limit into the struct mm for slightly more cache-friendly behaviour, and to allow later interfacing with per-user resource-management software (it should be possible to write a kernel module to adjust RSS limits to implement per-user limits without affecting per-process RLIMIT values) -- My patch has a /proc interface to allow setting rlimit[RLIMIT_RSS] -- my patch implements the rss accounting fields so that time -v gives reasonable output Index: linux-2.4.0/CREDITS === RCS file: /wrk/CVSROOT/linux-2.4/CREDITS,v retrieving revision 1.1.1.5 diff -u -b -u -r1.1.1.5 CREDITS --- linux-2.4.0/CREDITS 2001/01/04 23:02:54 1.1.1.5 +++ linux-2.4.0/CREDITS 2001/01/08 04:41:41 @@ -491,6 +491,24 @@ S: Stanford, California 94305 S: USA +N: Kingsley Cheung +E: [EMAIL PROTECTED] +D: Page fault calculation +D: /proc//rss support +D: kswapd improvements regarding process RSS limits +S: Aurema Pty Limited +S: PO Box 305, Strawberry Hills NSW 2012, +S: Australia + +N: Peter Chubb +E: [EMAIL PROTECTED] +D: Page fault calculation +D: /proc//rss support +D: kswapd improvements regarding process RSS limits +S: Aurema Pty Limited +S: PO Box 305, Strawberry Hills NSW 2012, +S: Australia + N: Juan Jose Ciarlante W: http://juanjox.kernelnotes.org/ E: [EMAIL PROTECTED] Index: linux-2.4.0/Documentation/Configure.help === RCS file: /wrk/CVSROOT/linux-2.4/Documentation/Configure.help,v retrieving revision 1.1.1.6 diff -u -b -u -r1.1.1.6 Configure.help --- linux-2.4.0/Documentation/Configure.help2001/01/07 21:44:33 1.1.1.6 +++ linux-2.4.0/Documentation/Configure.help2001/01/08 04:41:41 @@ -16955,6 +16955,50 @@ another UltraSPARC-IIi-cEngine boardset with a 7-segment display, you should say N to this option. +RSS Softlimits (EXPERIMENTAL) +CONFIG_RSS_SOFTLIMIT + If you want the setrlimit(RLIMIT_RSS, ...) system call to work, say + Y either here or for RSS Hardlimits. If you don't understand this + you don't need it, so say N. + + RSS Softlimits will make it more likely that pages will be stolen + from processes that have a resident set size (i.e., real memory + footprint) greater than their limit. Processes with a limit set + that is below their actual need may still exceed their limits, and + in this instance kswapd may work excessively hard. + + Because of the way that RSS is measured and controlled, the limit is + approximate only. + + It is harmless to have RSS Softlimits and RSS Hardlimits both set. + +RSS Hardlimits (EXPERIMENTAL) +CONFIG_RSS_HARDLIMIT + If you want the setrlimit(RLIMIT_RSS, ...) system call to work, say + Y either here or for RSS Softlimits. If you don't understand this + you don't need it, so say N. + + RSS Hardlimits changes the behaviour of the kernel at page-fault + time. If a process is over its RSS limit when it wants to get a new + page, then with this configuration option enabled the process's + memory space will be reduced before the page-fault continues. + + Because of the way that RSS is measured and controlled, the actual + memory footprint of a process may exceed the set limit for a short + time. + + It is harmless to have RSS Softlimits and RSS Hardlimits both set. + +Support for /proc/pid/rss (EXPERIMENTAL) +CONFIG_PROC_RSS + Saying Y here adds an extra file inside each process directory in the + /proc file system that allows measurement and control of resident + set size (real m
Re: PROBLEM: 2.4.0: not loading fore200e
On Mon, Jan 08, 2001 at 02:56:56AM +0100, Rafal Maszkowski wrote: > Pure 2.4.0 on sparc32 with RedHat 6.2: > root@etest:/usr/src/6,0# modprobe fore200e > /lib/modules/2.4.0lt/kernel/drivers/atm/fore200e_sba_fw.o: couldn't find the kernel >version the module was compiled for > /lib/modules/2.4.0lt/kernel/drivers/atm/fore200e_sba_fw.o: insmod >/lib/modules/2.4.0lt/kernel/drivers/atm/fore200e_sba_fw.o failed > /lib/modules/2.4.0lt/kernel/drivers/atm/fore200e_sba_fw.o: insmod fore200e failed Linking error, Makefile was fixed by 2.4.0-ac2. R. -- W iskier krzesaniu żywem/Materiał to rzecz główna - 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: [OT] Re: [OT] Re: .br blacklisted ?
Even not specifically disagreeing, but Dan Hollis wrote: > > See Rowan v. United States Post Office. Why necessarily should I care about United States Post Office or United States in general ? > > > *Your* right to free speech stops at *my* property. > > Under no circumstances does your right to free speech trump the rights of > the unwilling recipient. Full Stop. End of story. > Maybe in US, but still is it that clear ? What about TV commercials ? Can I request cable company not to transmit them onto my property ? If not, can your ISP require you to recieve spam/advertisement as condition of service ?-- CITA, University of Toronto [EMAIL PROTECTED] 60. St. George Street tel: 1-416-978-7616 (o) Toronto, Ontario, M5S 3H8 tel: 1-416-466-4028 (h) Canada fax: 1-416-978-3921 - 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: routable interfaces WAS( Re: [PATCH] hashed device lookup(DoesNOTmeet Linus' sumission policy!)
jamal wrote: > > On Sun, 7 Jan 2001, Ben Greear wrote: > > > Hrm, what if they just made each IP-SEC interface a net_device? If they > > are a routable entity, with it's own IP address, it starts to look a lot > > like an interface/net_device. > > As in my response to Matti, i thing a netdevice is a generalized link > layer structure and should remain that way. Yes, but VLANs are a link-layer structure too, and things like tunnels are really link-layer too, as far as protocols using them are concerned. With tunneling and virtual interfaces, you could conceivably do something like: OC3 - ATM - Ethernet - VLAN - IP - IP-Sec - IP as well as plain old: Ethernet - IP Which of these are netdevices? (I argue that at least the Ethernet-over-ATM, VLAN, and IP-Sec entities could profit from being a net_device at it's core.) You argue that we should split the net_device into physical and virtual portions. Perhaps you could give an idea of the data members that would belong in the new structures? I argue that you lose the minute you need one in both structures :) > > This has seeming worked well for VLANs: Maybe net_device is already > > general enough?? > > I think it is not proper to generalize netdevices for IP. I am not > thinking of dead protocols like IPX, more of other newer encapsulations > such as MPLS etc. MPLS can run over FrameRelay, Ethernet, and ATM, at the moment (right?). What if you want to run MPLS over an IP-Sec link? If you want it to magically work, IP-Sec could be a net_device with it's own particular member methods and private data that let it do the right thing. > > So, what would be the down-side of having VLANs and other virtual interfaces > > be net_devices? The only thing I ever thought of was the linear lookups, > > which is why I wrote the hash code. The beauty of working with existing > > user-space tools should not be over-looked! > > > > IP configuration tools you mean. Fine, they should be used to configure > "interfaces" in the way i defined them above. Think also of creating sockets with SOCK_RAW and other lower-level (but user-space) access to the net_device's methods. > It makes sense from an abstraction and management perspective to have all > virtual interfaces which run on top of a physical interface to be > managed in conjuction with the device. What if you had an inverse-MUX type of device that spanned two different physical interfaces. Then, one can go down, but the virtual interface is still up. So, there is not a one-to-one coorespondence. At a higher level, what if your interface is some tunnel running over IP. IP in turn can be routed out any physical interface (and may dynamically change due to routing protocols.) > Device goes down, you destroy them > or send them to a shutdown state (instead of messaging) etc. > > cheers, > jamal -- Ben Greear ([EMAIL PROTECTED]) http://www.candelatech.com Author of ScryMUD: scry.wanfear.com (Released under GPL) http://scry.wanfear.com http://scry.wanfear.com/~greear - 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: [OT] Re: [OT] Re: .br blacklisted ?
On Sun, 7 Jan 2001, Gregory Maxwell wrote: > You are suggesting that it is acceptable to implement technological > barriers to a minority expressing speech that is unacceptable to the > majority. This is not acceptable. See Rowan v. United States Post Office. *Your* right to free speech stops at *my* property. Under no circumstances does your right to free speech trump the rights of the unwilling recipient. Full Stop. End of story. -Dan - 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: 2.4.0: __alloc_pages: 3-order allocation failed.
On Sun, Jan 07 2001, Rik van Riel wrote: > > __alloc_pages: 3-order allocation failed. > > This debugging check should probably be removed around > 2.4.5, in the mean time it is much too useful to track > down badly behaving device drivers ;) It need not be a badly written driver, it could be a fine one just trying to see if it can get 2^3 successive pages for performance reasons. As long as it continues on its merry way when this fails it would be fine, and this message just confuses users. Plus, for this to be really useful as a catch-bad-guys tool it would be nice with a hint as what causes it (EIP or even a call trace). -- * 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/
2.4.0 APM w/ Compaq 16xx laptop...
Anyone get this working? If so please tell me the version of you APM utilities and what Power Management options you have on in the kernel. Ever since I started trying 2.3.x, as soon as the box gets a change in it's power status (even just an update of the % battery) Linux locks solid. It's 100% repeatable. In particular this is a Compaq Presario 1670. If I remove APM from the kernel it runs perfectly... but no APM on a laptop really sucks. Brian Macy - 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/
Ooops on 2.4.0 SMP Sparc32...
This is very easily repeated... happens a few minutes after boot. After it
happens one CPU gets stuck on a spin lock owned by the other.
This kernel was built from code pulled down from [EMAIL PROTECTED]:/vger on Jan
5th. Looked like the first merge of the 2.4.0 released code... but the Ooops
happened on the CVS 2.4.0-prerelease also.
Brian Macy
job:~# cat ~bmacy/sparc.oops | ksymoops -K -m /boot/System.map-2.4.0
ksymoops 2.3.4 on sparc 2.2.18. Options used
-V (default)
-K (specified)
-l /proc/modules (default)
-o /lib/modules/2.2.18/ (default)
-m /boot/System.map-2.4.0 (specified)
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel NULL pointer
dereference<1>tsk->{mm,active_mm}->context
= 0185
tsk->{mm,active_mm}->pgd = fc074400
\|/ \|/
"@'/ ,. \`@"
/_| \__/ |_\
\__U_/
apache(408): Oops
PSR: 1e101fc5 PC: f004804c NPC: f0048050 Y:
Using defaults from ksymoops -t elf32-sparc -a sparc
g0: f01adc00 g1: 1e401fe7 g2: g3: 1e4010e1 g4: f0063848 g5: f015f944
g6: f07e6000 g7:
o0: 0400 o1: f4860040 o2: f48604c0 o3: 0006 o4: 0018 o5: fd004000
sp: f07e7bf0 o7: f0048018
l0: f4860020 l1: 007d l2: l3: 0020 l4: 1e401fc6 l5: f01a6dc4
l6: l7: f018e0e0
i0: f053e278 i1: 0007 i2: f056c400 i3: f0138c00 i4: f0138c00 i5: 1e4010e6
fp: f07e7c58 i7: f0048270
Caller[f0048270]
Caller[f006f9f0]
Caller[f0063904]
Caller[f006467c]
Caller[f0065594]
Caller[f005380c]
Caller[f0053ca4]
Caller[f0015360]
Caller[501a3914]
Instruction DUMP: d6242014 d004 d0262008 a2047fff
912a6002
90020012 d4222008 92026001
>>PC; f004804c <=
>>O7; f0048018 >>I7; f0048270
Trace; f0048270 Trace;
f006f9f0 Trace; f0063904 Trace; f006467c
Trace; f0065594 Trace; f005380c
Trace; f0053ca4 Trace; f0015360
Trace; 501a3914 Before first symbol
Code; f0048040 <_PC>:
Code; f0048040 0: d6 24 20 14 st %o3, [
%l0 + 0x14 ]
Code; f0048044 4: d0 04 00 00 ld [ %l0
], %o0
Code; f0048048 8: d0 26 20 08 st %o0, [
%i0 + 8 ]
Code; f004804c <=
c: d2 04 80 00 ld [ %l2 ], %o1 <=
Code; f0048050 10: a2 04 7f ff add %l1,
-1, %l1
Code; f0048054 14: 91 2a 60 02 sll %o1,
2, %o0
Code; f0048058 18: 90 02 00 12 add %o0,
%l2, %o0
Code; f004805c 1c: d4 22 20 08 st %o2,
[ %o0 + 8 ]
Code; f0048060 20: 92 02 60 01 inc %o1
-
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 (repost): cramfs memory corruption fix
On Sat, 6 Jan 2001, Adam J. Richter wrote: > > This sounds like a bug that I posted a fix for a long time ago. > cramfs calls bforget on the superblock area, destroying that block of > the ramdisk, even when the ramdisk does not contain a cramfs file system. > Normally, bforget is called on block that really can be trashed, > such as blocks release by truncate or unlink. I'd really prefer just not letting bforget() touch BH_Protected buffers. bforget() is also used by other things than unlink/truncate: it's used by various partition codes etc, and it's used by the raid logic. Now, nobody wants to use RAID on a ramdisk, but the fact is that "bforget()" does not mean "forget the contents of this buffer", but it really means "you can forget this cached copy even if it is dirty, we're not likely to need it in the near future and can read it back in". Also, if you care about memory usage, you're likely to be much better off using ramfs rather than something like "ext2 on ramdisk". You won't get the double buffering. 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: [OT] Re: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 10:30:14PM -0500, Gregory Maxwell wrote:
> On Sun, Jan 07, 2001 at 08:22:28PM -0500, Michael H. Warfield wrote:
> > I already run several sugarplum sites with teergrubes. I also use
> > various blackhole lists and take other action against spammers, including
> > blocking entire rogue domains. If that rogue domain happens to be a two
> > letter TLD, so be it. If it gets bad enough, maybe they'll fix it.
> You are suggesting that it is acceptable to implement technological
> barriers to a minority expressing speech that is unacceptable to the
> majority. This is not acceptable.
No... I'm say that their right to free speech does not trump
my right to not have to listen to it or download it and I determine
the criterion, they don't. I have, in my right to free speech, the
right to say screw off, I don't want to hear it.
> When you subscript your mailbox to list of 'spammers' to avoid associating
> with them, with the knowledge that you may lose some valuable mail, that is
> fine.
Excuse me??? Clue alert! I'm not subscribing anything to any
spam mailbox. I'm not doing jack shit to subscribe myself to anything
to do with them. I am leaving bait around for them to screw themselves,
but I certainly have the free speech right to do that, now don't I?
I don't go to them and say "subscribe all these addresses". I don't
say to them, send E-Mail here. They are trespassing on my systems,
clearly stepping over well delineated boundries.
I'm really lost by your reasoning on this one. "Subscribing my
mailbox to a list of 'spammers' to avoid associating with them, with the
knowledge that you loose some valuable mail" makes absolutely no sense
what so ever. The legitimate mail I may or may not loose has no bearing
on the sugarplum or teergrube systems (which is what I'm assuming that
you are elluding to).
> The situation is similar to not visiting a gay bar if you don't like
> homosexual people. However, that is not what you are doing blocking whole
> countries. That is like building concrete barriers around cites to punish
> them for not oppressing their own minority citizen ("I'm going to block your
> whole country until you outlaw this class of speech I find offensive").
Tough... I find the speech offensive, I don't have to listen
to it. If I find that the level of offensive speech from a particular
source exceeds all value, then I have the right to block it. They don't
like it, they have a right to change. Like I said... I don't take
active action against them. They have to come to me. They come to
my web site and step over my limits and contact my systems. I'm not
going to them.
> Spam is not good, but destroying freedom is worse. I suggest that every
> person who is eager to use oppressive technological measures to stop spammers
> please consider the potential wider consequences.
Destroying my freedom is just as bad. I have the freedom to
choose and I have the freedom not to be plagued by the vermin who have
harvested my addresses and are using them in a way that violates my
acceptable use on my addresses.
> Today the majority thinks spam is wrong, today you are a part of the
> majority. The Internet should always avoid the tyranny of the masses, even
> when it's operators are a part of the 'mass' today. Tomorrow the issue will
> not be spam, and you might not be in the majority.
Not a problem. Won't be the first time and won't be the last time.
I deal and so shall they.
Mike
--
Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of 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/
understanding gunzip
hi,
i tried 2.4.0 kernel with rmk and np patches in my brutus board. (Brutus
is a StrongArm based development environment)
my patched kernel is 2.4.0-rmk1-np1
the kernel uncompresses fine. but uncompressing the ramdisk fails. In
this instance my uncompressed ramdisk is about 3.5mb.
i looked in to gunzip() routine. in inflate() (inflate.c)
i found following,
do {
hufts = 0;
gzip_mark(&ptr);
if ((r = inflate_block(&e)) != 0) {
gzip_release(&ptr);
return r;
}
gzip_release(&ptr);
if (hufts > h)
h = hufts;
} while (!e);
and gzip_mark() and gzip_release() are defined in rd.c as,
static void __init gzip_mark(void **ptr)
{
}
static void __init gzip_release(void **ptr)
{
}
now if i comment these gzip_mark and gzip_release lines then the kernel
would complain,
Out of memory
-- System halted
then i tried to see where ptr is poinitng to, according to the
System.map it points to a variable called insize,
it's defined as
./arch/arm/boot/compressed/misc.c : static unsigned insize = 0;
/* valid bytes in inbuf */
i don't understand what is happening here!! or did i miss anything??
tia
dhammika
-
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/
[OT] Re: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 08:22:28PM -0500, Michael H. Warfield wrote:
> I already run several sugarplum sites with teergrubes. I also use
> various blackhole lists and take other action against spammers, including
> blocking entire rogue domains. If that rogue domain happens to be a two
> letter TLD, so be it. If it gets bad enough, maybe they'll fix it.
You are suggesting that it is acceptable to implement technological
barriers to a minority expressing speech that is unacceptable to the
majority. This is not acceptable.
When you subscript your mailbox to list of 'spammers' to avoid associating
with them, with the knowledge that you may lose some valuable mail, that is
fine.
The situation is similar to not visiting a gay bar if you don't like
homosexual people. However, that is not what you are doing blocking whole
countries. That is like building concrete barriers around cites to punish
them for not oppressing their own minority citizen ("I'm going to block your
whole country until you outlaw this class of speech I find offensive").
Spam is not good, but destroying freedom is worse. I suggest that every
person who is eager to use oppressive technological measures to stop spammers
please consider the potential wider consequences.
Today the majority thinks spam is wrong, today you are a part of the
majority. The Internet should always avoid the tyranny of the masses, even
when it's operators are a part of the 'mass' today. Tomorrow the issue will
not be spam, and you might not be in the majority.
-
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/
IDE HD DMA not being enabled in 2.4.0
Hello, this is my first post to Linux-Kernel so I hope I get this right. On my Pentium 200 system with Intel i430VX chipset and PIIX3, my Maxtor 3.5GB IDE HD would always have DMA enabled even in 2.4.0-test10, but then sometime between 2.4.0-test12 and 2.4.0 (final), DMA was not being enabled anymore upon boot. Here is my relevant "dmesg" from 2.4.0-test10: Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX3: IDE controller on PCI bus 00 dev 39 PIIX3: chipset revision 0 PIIX3: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio hda: Maxtor 83500A4, ATA DISK drive hdb: ST31220A, ATA DISK drive hdc: ATAPI CDROM, ATAPI CDROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 6839440 sectors (3502 MB) w/256KiB Cache, CHS=848/128/63, (U)DMA hdb: 2116296 sectors (1084 MB) w/256KiB Cache, CHS=524/64/63, DMA Notice the drive being picked up as (U)DMA, and the Seagate 1.2GB being picked up as DMA. Now look at my 2.4.0 dmesg: Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx PIIX3: IDE controller on PCI bus 00 dev 39 PIIX3: chipset revision 0 PIIX3: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio hda: Maxtor 83500A4, ATA DISK drive hdb: ST31220A, ATA DISK drive hdc: ATAPI CDROM, ATAPI CDROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 6839440 sectors (3502 MB) w/256KiB Cache, CHS=848/128/63 hdb: 2116296 sectors (1084 MB) w/256KiB Cache, CHS=524/64/63, DMA Here you can see that DMA is still configured, because the Seagate retains DMA. But for some reason the Maxtor is now getting no DMA at all. I can use "hdparm" to enable it manually and I did an "updatedb" to generate some heavy test disk activity, and it worked fine. So I cannot assume that DMA is being disabled on my Maxtor on purpose, because of some bad hardware or something, and I am guessing something changed in the IDE driver recently that buggered the DMA enabling. Please CC all correspondence to my email, since I don't subscribe to Linux-Kernel. Thanks! x Josh Straub ô¿ô [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: Related VIA PCI crazyness?
On Sun, 7 Jan 2001, Albert Cranford wrote: > > Could anybody with a VIA chip who has the energy please do something for > > me: > > - enable DEBUG in arch/i386/kernel/pci-i386.h > > - do a "/sbin/lspci -xxvvv" on the interrupt routing chip (it's the > >"ISA bridge" chip - the VIA numbers are 82c586, 82c596, the PCI > >numbers for them are 1106:0586 and 1106:0596, I think) > > - do a cat /proc/pci > > > > Does this help. Ahh, no. A SMP kernel (or one with UP IO-APIC) is not going to be helpful for this, actually. SMP will take the irq data from the MP block, not the pirq table (that can be considered something of a misfeature right now, but getting the mixture of PCI irq redirection from the MP tables and the pirq irq routing information right together is probably not worth it - especially as I don't think any MS OS has ever done that either, so the BIOS writers have never experienced that combination - so it's almost guaranteed to result in strange results). 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/
setfsuid on ext2 weirdness (2.4)
Ok.. I'm going bananas. It could be a 4am braindeath or a rh7.0 bungholio
but this is annoying:
main(int argc, char **argv)
{
int fd;
setfsuid(atoi(argv[1]));
fd = open("/etc/passwd", O_RDONLY);
printf("got fd %d\n", fd);
}
[root@wizball /root]# ./setfstest 0
got fd 3
[root@wizball /root]# ./setfstest 500
got fd 3
[root@wizball /root]# ./setfstest 501
got fd -1
0 is obviously my root user and 500 is my standard user i log-in with. 501
exists (not that that has anything to do with this)
in fact, 0 and 500 are the ONLY ones who let a filesystem op through after
the setfsuid call. all other cause an EACCESS error on the open (or any
other fs op). and yes, the actual filepermissions on /etc and /etc/passwd
are correct.
consequence is that i can't login as any other user (or ftp, or anything
that needs to change the uid's) :(
so... the quick question is... is there anything in EXT2 or VFS that can
cause a quite normal ext2 filesystem on a 2.4.0 kernel to behave remotely
like this ?
strace shows the setfsuid call succeeds and nothing funny happens.
[root@wizball /root]# strace ./setfstest 501
execve("./setfstest", ["./setfstest", "501"], [/* 38 vars */]) = 0
uname({sys="Linux", node="wizball.xxx.yyy.zzz", ...}) = 0
brk(0) = 0x80496c8
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=32172, ...}) = 0
old_mmap(NULL, 32172, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\301\1"...,
1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=4851725, ...}) = 0
old_mmap(NULL, 1217864, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x4002
mprotect(0x4014, 38216, PROT_NONE) = 0
old_mmap(0x4014, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x11f000) = 0x4014
old_mmap(0x40146000, 13640, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40146000
close(3)= 0
munmap(0x40018000, 32172) = 0
getpid()= 1739
setfsuid32(0x1f5) = 0
open("/etc/passwd", O_RDONLY) = -1 EACCES (Permission denied)
-
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: FW: compile problem in 2.4.0-ac3
On Mon, Jan 08, 2001 at 11:42:12AM +1100, Keith Owens wrote: > On Sun, 7 Jan 2001 15:02:40 -0800, > A Guy Called Tyketto <[EMAIL PROTECTED]> wrote: > >I'm still seeing > > > >#include > > > >at line 25 of acpi_ksyms.c. This is also the same line, in > >patch-2.4.0-ac2 (counted the lines of each). Neither patches compile from this. > > Not happening here. -ac2 and -ac3 have the same text. > > diff -u --new-file --recursive --exclude-from /usr/src/exclude >linux-2.4.0/drivers/acpi/acpi_ksyms.c linux.ac/drivers/acpi/acpi_ksyms.c > --- linux-2.4.0/drivers/acpi/acpi_ksyms.c Thu Jan 1 01:00:00 1970 > +++ linux.ac/drivers/acpi/acpi_ksyms.c Wed Jan 3 16:49:59 2001 > @@ -0,0 +1,91 @@ > +/* > + * ksyms.c - ACPI exported symbols > + * > + * Copyright (C) 2000 Andrew Grover > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > + */ > + > +#include > +#include > +#include > +#include > +#include <== line 25 > +#include "acpi.h" > > You have corrupted your patch and/or source. yep.. you were right. patch was corrupted. Just grabbed -ac4, and it cleanly applied and compiled. Thanks for the help! :) BL. -- Brad Littlejohn | Email:[EMAIL PROTECTED] Unix Systems Administrator, | [EMAIL PROTECTED] Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF - 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: Bug: Frame-buffer (icon) rotates right in 2.4.0 when SMP
when you use SMP there's suppOsed to be one icon that shows up for every CPU you have. 2 cpu = 2 icons, 4 cpu = 4 icon. That's what the for loop in fbcon_show_logo(). So this really isnt a bug, depending on how you look at it. It's definitely something the lpp author needs to account for. On Sun, 7 Jan 2001, Karl O. Pinc wrote: > When displaying a screen-wide icon in the frame buffer for the > graphics console: > > Linux version 2.4.0 > > Console Drivers > Video mode selection support > Support for frame buffer devices (EXPERMENTAL) > VESA VGA graphics console > > I found the right edge of the image to be displayed on the left edge > -- perhaps 8 pixels worth? > > I compiled for a pentium III, SMP on. I've a dual processor Pentium > III with a Matrox Graphics, Inc. MGA G400 AGP video card. I > discovered this using the lpp-0.2.0 patch at http://lpp.freelords.org, > which displays a startup screen. > > Fix: turning SMP off fixed the problem. > > FYI: fbcon_show_logo() in drivers/video/fbcon.c seems to have a for > loop with an odd smp_num_cpus reference. > -- = 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: Software requirements in Changes document
On Mon, 8 Jan 2001, Matthias Juchem wrote: > Hi Chris, > > Comparing the Changes document for 2.4.0 against the one from 2.3.11 one > can see that many requirements were removed. Nine out of 22 are still > there. > Have the removed ones been unnecessary or only less important than the > remaining ones? I've not dug up 2.3.11 to double-check, but I'd imagine that's when it was trimmed so that only requirements which are new to 2.4 (ie, which aren't also true for 2.2) are listed later, chris -- Chris Ricker [EMAIL PROTECTED] [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/
How to boot linux kernel from floppy
Hi, all, I am new to this maillist. I want to boot my system from a single floppy. If I use 1.44MB, the space is too small. So I format my floppy to 1.6MB. I do the following things, #fdformat /dev/fd0H1600 #cp /usr/src/linux/arch/i386/boot/zImage /dev/fd0 #rdev /dev/fd0 /dev/fd0 #rdev -r /dev/fd0 49552 When I boot from floppy, the console print: Loading... But then not print other things, then system reboot again. I read arch/i386/boot/bootsect.S file and find no support for 1.6MB floppy. How can I support this floppy in kernel? If someone knows, please help me. Thanks in advance! Qingbo __ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.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: Paket counters for aliased interfaces ?
Patrick Mau wrote: [...] > And here's the question: > I would like to collect statistics for eth0:0 but obviously the > pakets are only counted for the real interface. If I had enough time > and knowledge, how should I implement paket counters for aliased > interfaces ? > > PS: Am I right that it isn't possible ? tcpdump doesn't 'work right' > either. Correct. "eth0" is only a label. You need to use a userland process such as firewalling and count the packets. For tcpdump, specify 'src or dst ' -d begin:vcard n:Ford;David x-mozilla-html:TRUE url:www.blue-labs.org adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer note;quoted-printable:GPG key: http:[EMAIL PROTECTED]=0D=0A x-mozilla-cpt:;9952 fn:David Ford end:vcard
Re: Related VIA PCI crazyness?
On 7 Jan 2001, Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, > Philip Armstrong <[EMAIL PROTECTED]> wrote: > >In supplement to Evan Thompson's emails with the subject "Additional > >info. for PCI VIA IDE crazyness. Please read." I've noticed the > >following message with recent 2.4.0 test + release kernels: > > > >IRQ routing conflict in pirq table! Try 'pci=autoirq' > > But the machine still works fine, ie the SCSI driver and the network > driver still seem happy? >... > Christian Engstler seems to have a problem much like yours, where it > gets a different irq line than the one that is apparently in use. It > looks like Christian, too, has a working machine, and that the only bad > result of this all is an annoying printk message. Can you confirm that > things actually work for you too, and you'd just like to get rid of the > unnerving message? Philip wrote in a PM to me that he has no problems with his machine (same as for me). I don't know if it's related, but has anyone with a card not manufactored by RealTek the same problem? Philip and Albert have a RTL8139 and I have a RTL-8029. >... > Could anybody with a VIA chip who has the energy please do something for > me: > - enable DEBUG in arch/i386/kernel/pci-i386.h Output of dmesg: Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version 2.95.2 222 0 (Debian GNU/Linux)) #1 Mon Jan 8 02:49:37 CET 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0001 @ (reserved) BIOS-e820: 03f0 @ 0010 (usable) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c000 for 4096 bytes. On node 0 totalpages: 16384 zone(0): 4096 pages. zone(1): 12288 pages. zone(2): 0 pages. mapped APIC to e000 (01112000) Kernel command line: BOOT_IMAGE=test ro root=306 BOOT_FILE=/boot/test reserve=0x 340,0x20 reserve=0x800,0x20 ether=10,0x340,eth1 ether=0,0x800,eth0 Initializing CPU#0 Detected 299.753 MHz processor. Console: colour VGA+ 132x43 Calibrating delay loop... 598.01 BogoMIPS Memory: 62304k/65536k available (957k kernel code, 2844k reserved, 369k data, 20 4k init, 0k highmem) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) CPU: Before vendor init, caps: 008001bf 008005bf , vendor = 2 CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: After vendor init, caps: 008001bf 008005bf CPU: After generic, caps: 008001bf 008005bf CPU: Common caps: 008001bf 008005bf CPU: AMD-K6tm w/ multimedia extensions stepping 00 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: BIOS32 Service Directory structure at 0xc00fafb0 PCI: BIOS32 Service Directory entry at 0xfb430 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=01 PCI: PCI BIOS revision 2.10 entry at 0xfb460, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: IDE base address fixup for 00:07.1 PCI: Scanning for ghost devices on bus 0 PCI: Scanning for ghost devices on bus 1 Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fde50 00:08 slot=01 0:01/deb8 1:02/deb8 2:03/deb8 3:05/deb8 00:09 slot=02 0:02/deb8 1:03/deb8 2:05/deb8 3:01/deb8 00:0a slot=03 0:03/deb8 1:05/deb8 2:01/deb8 3:02/deb8 00:0b slot=04 0:05/deb8 1:01/deb8 2:02/deb8 3:03/deb8 00:07 slot=00 0:01/deb8 1:02/deb8 2:03/deb8 3:05/deb8 00:01 slot=00 0:01/deb8 1:02/deb8 2:03/deb8 3:05/deb8 PCI: Using IRQ router VIA [1106/0586] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e7ff (f=1208, d=0, p=0) PCI: Resource e000-e00f (f=101, d=0, p=0) PCI: Resource e800-ebff (f=200, d=0, p=0) PCI: Resource e800-e81f (f=101, d=0, p=0) PCI: Sorting device list... Activating ISA DMA hang workarounds. isapnp: Scanning for Pnp cards... isapnp: Card 'HIGHSCREEN SOUND-BOOSTAR 16 3D' isapnp: 1 Plug & Play card detected total Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket DMI 2.0 present. 30 structures occupying 836 bytes. DMI table at 0x000F0800. BIOS Vendor: Award Software International, Inc. BIOS Version: BIOS VER:1.0 03 GS BIOS Release: 10/18/99 System Vendor: A-Trend. Product Name: ATC-5220. Version BIOS VER:1.0 03 GS. Serial Number ATC52201003GS. Board Vendor: A-Trend. Board Name: VP3-586B-SMC669. Board Version: VER:1.0 03 GS. apm: BIOS version 1.2 Flags 0x07 (Driver version 1.14) Starting kswapd v1.8 parport0: PC-style at 0x378 [PCSPP(,
Linux 2.4.0-ac4
Handle with care. I think the fs updates are right but I don't guarantee it. ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 2.4.0-ac4 o Fix dereference of freed skbuff in iphase (Hans Grobler) o Fix dereference of freed skbuff in isdn_ppp (Hans Grobler) o Fix dereference of freed skbuff in comx (Hans Grobler) o Fix dereference of freed skbuff in atarilance (Arnaldo Carvalho de Melo) o Fix missing NULL check of dev_alloc_skb in (Hans Grobler) hdlc layer o Fix vesafb typo (Dag Wieers) o Z85230 driver cleanup (Hans Grobler) o Remove spare restore_flags in de600 (Hans Grobler) o Catch failed kmallocs in ppc ethernet (Hans Grobler) o AF_PACKET socket cleanup(Hans Grobler) o ATAPI IDE format facility (Sam Varshavchik) | Don't rely on the abi or anything yet, Gadi | the maintainer has yet to comment on it o Fix smc9194 crash on out of memory (Hans Grobler) o Documentation fixes (Dag Wieers) o Fusion driver updates (Steve Ralston, Eddie Dost, Arnaldo Carvalho de Melo) o Fix ramfs hangs (me) o Fix assorted LFS problems and missing rlimit(me) checks. In theory file size rules are now right and properly enforced except for those folks not using generic_file_write who need to do their homework 8) 2.4.0-ac3 o Add support for the newer 3c905 cards (Andrew Morton) o Drop unused field from scc.h(Hans Grobler) o Remove dead sysctl stuff from econet(Hans Grobler) o Fix documentation indexes (Paul Gortmaker) o Fix post free reference of an skb in lance (Paul Gortmaker) o Tidy appletalk code (Hans Grobler) o Fix bootup vesafb hang (David Wragg) o TCP 'reset_xmit_timer' fix (Dave Miller) o Tidy up cursor positioning on menuconfig(Kirk Reiser) o Add missing wait.h includes to some asm/semaphore (Hans Grobler) o AF_UNIX socket cleanup (Hans Grobler) o Update sd locking fixes (Oliver Neukum) o Add module locking to audio coprocessor calls (Chris Rankin) o Minor further X.25 tidy (Hans Grobler) o Fix scsi ioctl/scan crash on out of memory (Douglas Gilbert) o Soundscape patches (Chris Rankin) o M68K fixes for mem stats and stram (Geert Uytterhoeven) o Set MSG_TRUNC correctly on atm sockets (Matti Aarnio) o Add infrastructure for parport autoloading (Adam J Richter) o Make lp driver use capable not old suser() (Tim Waugh) o Fix thread/unload race on i2o block (me) o Fix drivers that use asm/delay not linux/delay (Geert Uytterhoeven) o Further warning fixes (Rich Baum) o Netfilter config/Makefile fixes (Dave Miller) o Merge updated cs4281 driver and tidy it (Tom Woller) | some cleanups by me, possibly broken it ;) o Fix bagetlance reference of freed buffer (Arnaldo Carvalho de Melo) o ISDN small fixes(Andrea Baldoni, Daniel Stodden) o ESS Maestro 3 driver(Zach Brown) 2.4.0-ac2 o Clean up strip driver (Hans Grobler) o Fix fore atm makefile (Jan Rekorajski) o Fix m68k lance mismerge (Geert Uytterhoeven) o Fix tty documentation typos (Hans Grobler) o Fix ohci1394 build (Arjan van de Ven) o Remove dead lapbether inits (Hans Grobler) o Workaround the acpi recursive variable name (Bill Wendling) Makefile problem o Further minor S/390 merge (Ulrich Weigand) o Fix DRM build problem on ATI Rage 120/no AGP(Gareth Hughes) o Fix mac address setting in 8139too (Ben Greear) o AGP oops fix/ALi cleanup(Bill Crawford) o Further DECnet cleanups (Hans Grobler) o S/390 last fixes
[PATCH] Fix typo in drivers/video/amifb.c in 2.4.0
This fixes a comment at the end of an #endif. This should fix all of the warnings about tokens at the end of #endifs. Please disregard the parts of my earlier patch which made changes to comments and .S files. I should have reviewed the patch the script made more closely. diff -urN -X dontdiff linux/drivers/video/amifb.c rb/drivers/video/amifb.c --- linux/drivers/video/amifb.c Fri Dec 29 17:07:23 2000 +++ rb/drivers/video/amifb.cSun Jan 7 13:33:28 2001 @@ -1534,7 +1534,7 @@ } return i; } -#endif */ DEBUG */ +#endif /* DEBUG */ } return -EINVAL; } - 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] hashed device lookup (Does NOT meet Linus' sumission
Alan Cox wrote: > > Um, what about people running their box as just a VLAN router/firewall? > > That seems to be one of the principle uses so far. Actually, in that case > > both VLAN and IP traffic would come through, so it would be a tie if VLAN > > came first, but non-vlan traffic would suffer worse. > > Why would someone filter between vlans when any node on each vlan can happily > ignore the vlan partitioning ports 137-139 blather. -d begin:vcard n:Ford;David x-mozilla-html:TRUE url:www.blue-labs.org adr:;; version:2.1 email;internet:[EMAIL PROTECTED] title:Blue Labs Developer note;quoted-printable:GPG key: http:[EMAIL PROTECTED]=0D=0A x-mozilla-cpt:;9952 fn:David Ford end:vcard
Re: Related VIA PCI crazyness?
Linus Torvalds wrote: > Could anybody with a VIA chip who has the energy please do something for > me: > - enable DEBUG in arch/i386/kernel/pci-i386.h > - do a "/sbin/lspci -xxvvv" on the interrupt routing chip (it's the >"ISA bridge" chip - the VIA numbers are 82c586, 82c596, the PCI >numbers for them are 1106:0586 and 1106:0596, I think) > - do a cat /proc/pci > Does this help. dmesg Linux version 2.4.0 (root@home1) (gcc version pgcc-2.95.2 19991024 (release)) #2 Sun Jan 7 11:22:02 GMT 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (usable) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0001 @ (reserved) BIOS-e820: 07ef @ 0010 (usable) BIOS-e820: f800 @ 07ff0800 (ACPI data) BIOS-e820: 0800 @ 07ff (ACPI NVS) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c000 for 4096 bytes. On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 28672 pages. zone(2): 0 pages. Local APIC is hardware-disabled. mapped APIC to e000 (01223000) Kernel command line: BOOT_IMAGE=linux ro root=804 ramdisk_size=8192k mem=131072K apm=on,power-off mpu401=0x300 sb=0x220,5,1,5 adlib=0x300 parport=0x378,7 lp=parport0 penguin=1 pirq=0 nohlt PIRQ redirection, working around broken MP-BIOS. ... PIRQ0 -> IRQ 0 Initializing CPU#0 Detected 400.916 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 799.53 BogoMIPS Memory: 126424k/131072k available (1137k kernel code, 4260k reserved, 432k data, 240k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Before vendor init, caps: 008021bf 808029bf , vendor = 2 CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: L2 Cache: 256K (32 bytes/line) CPU: After vendor init, caps: 008021bf 808029bf 0002 CPU: After generic, caps: 008021bf 808029bf 0002 CPU: Common caps: 008021bf 808029bf 0002 CPU: AMD-K6(tm) 3D+ Processor stepping 01 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: AMD K6 PCI: PCI BIOS revision 2.10 entry at 0xfb4e0, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: 00:07.3: class 604 doesn't match header type 00. Ignoring class. PCI: Using IRQ router VIA [1106/0586] at 00:07.0 Activating ISA DMA hang workarounds. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 DMI 2.1 present. 25 structures occupying 843 bytes. DMI table at 0x000F0800. BIOS Vendor: Award Software International, Inc. BIOS Version: 4.51 PG BIOS Release: 06/09/99 System Vendor: System Manufacturer. Product Name: Product Name. Version SYS-xx. Serial Number Serial Number xx. Board Vendor: First International Computer, Inc.. Board Name: PA-2013. Board Version: PCB 2.X. Asset Tag: Asset Tag Number xx. apm: BIOS version 1.2 Flags 0x07 (Driver version 1.14) Starting kswapd v1.8 parport0: PC-style at 0x378, irq 7 [PCSPP(,...)] pty: 256 Unix98 ptys configured lp0: using parport0 (interrupt-driven). RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c586b IDE UDMA33 controller on pci0:7.1 ide0: BM-DMA at 0xe400-0xe407, BIOS settings: hda:DMA, hdb:DMA hda: ATAPI CDROM, ATAPI CDROM drive ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: ATAPI 212X CD-ROM drive, 128kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.12 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS03 at 0x02e8 (irq = 3) is a 16550A Real Time Clock Driver v1.10d Non-volatile memory driver v1.1 PPP generic driver version 2.4.1 PPP Deflate Compression module registered 8139too Fast Ethernet driver 0.9.13 loaded IRQ routing conflict in pirq table! Try 'pci=autoirq' eth0: RealTek RTL8139 Fast Ethernet at 0xc880, 00:e0:7d:72:07:43, IRQ 11 eth0: Identified 8139 chip type 'RTL-8139A' eth0: Setting full-duplex based on MII #32 link partner ability of 41e1.] lspci --xxvvv 00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04) Control: I/O- Mem+ BusMaster+ SpecCycle-
PROBLEM: 2.4.0: not loading fore200e
Pure 2.4.0 on sparc32 with RedHat 6.2: root@etest:/usr/src/6,0# modprobe fore200e /lib/modules/2.4.0lt/kernel/drivers/atm/fore200e_sba_fw.o: couldn't find the kernel version the module was compiled for /lib/modules/2.4.0lt/kernel/drivers/atm/fore200e_sba_fw.o: insmod /lib/modules/2.4.0lt/kernel/drivers/atm/fore200e_sba_fw.o failed /lib/modules/2.4.0lt/kernel/drivers/atm/fore200e_sba_fw.o: insmod fore200e failed root@etest:/usr/src/6,255# insmod /lib/modules/2.4.0lt/kernel/drivers/atm/fore200e_sba_fw.o /lib/modules/2.4.0lt/kernel/drivers/atm/fore200e_sba_fw.o: couldn't find the kernel version the module was compiled for The other, already known problem is that memory detection is broken. I managed to start with mem=192mb and use 48 of total 64 MB this way. Linux version 2.4.0lt ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Mon Jan 8 01:31:34 MET 2001 Linux etest.icm.edu.pl 2.4.0lt #1 Mon Jan 8 01:31:34 MET 2001 sparc unknown Kernel modules 2.4.0 Gnu C egcs-2.91.66 Gnu Make 3.78.1 Binutils 2.9.5.0.22 Linux C Library2.1.3 Dynamic linker ldd (GNU libc) 2.1.3 Procps 2.0.6 Mount 2.10f Net-tools 1.54 Console-tools 0.3.3 Sh-utils 2.0 Modules Loaded openprom R. -- W iskier krzesaniu żywem/Materiał to rzecz główna - 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: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 06:31:11PM -0700, Matt Beland wrote: > Thereby killing how many hundreds of innocent people? China doesn't much > believe in fining minor offenders, remember. > You don't like Spam? Join the club. Blacklisting any domain - ANY domain - > for spamming, unless you can absolutely prove that no legitimate email has > ever been sent from that server, is completely unacceptable. You complain > about the wasted time and bandwidth caused by Spam messages - how much time > do you waste every year blocking legitimate messages? Not nearly as much time wasted as the time and bandwidth that gets wasted for doing nothing. The problem is bad enough. Letting them run wild will make the cesspool stink even worse. The sites that get blocked are misconfigured and need to be fixed. They're just getting a little more incentive. Most of the spam I reject gets rejected before the data transfered (blackhole tagged). That preserves my resources. Spot checking indicates that I'm loosing very little legitimate mail. Example... By using DULS RBL, I block the majority of directed mail from dialup sites. Spot checking reveals that my kill ratio is better than 100:1 on that (100 spam to less than 1 legit). Only site I have ever needed to code an exception for was Bruce Peren's Map site when he had to move it to a personal connection. (BTW... I spot check by running some sites configured to drop rejected mail in spam cans and occasionally do this on my main server. I also check logs for legit traffic being rejected.) Anyone who hits one of my teergrubes has absolutely no legitimate business what so ever! There is not a single legitimate address on those tarpits. Oh! The poor sucky spammer got stuck talking to a few thousand addresses on a machine that takes three minutes to tell him "OK". Sorry, no tears... They get exactly what they deserve. They got the addresses by violating the robots.txt rules and harvesting poisoned pages. That's the only way they will find those addresses. Tough. BTW... I'm seeing several spam address harvestors chewing on my sugarplums every week. It's getting close to seeing more spam address harvestors than seeing legitimate search engines through my web sites. Mind you... What I do is actually pretty minor. The potential for real damage really exists. Several anti-spam sites jokingly suggest that rejection codes should be "4xx" codes instead of "5xx" codes. Think about that for a second... They haven't transferred any data to you but you tell them to hold that data and try back later (4xx codes signify temporary errors that may be retried). So that data sits on their system until their final retries time out several days (5 days typical) later. Now... Take that and take advantage of the old "percent hack" that thousands of servers around the net still support (and are vulnerable open relays in and of their own right). Send a message to each of those servers pecent hacking a huge message at the chump you want to target with a final address of a system that blocks him with a 4xx code. With little effort you can totally shut down his mail spool and backup mail onto the percent hackable servers. Even if he manually cleans his spool, he's got another shit load or two waiting for him. Sites which permit open relaying are vulnerable to the 4xx code attacks. They have an open death trap DoS security vulnerability on them. The fact that we don't take advantage of it, means we're the nice guys. We only give them 5xx codes and tell them to go away... I have the right to decide, based on what ever criterion I chose, to accept or reject E-Mail. For the sites that I administer for a large E-Mail base, that needs to be in accordance with the established policies. In most cases, I have a hard time coming up with rules strict enough to adhere to those policies while still keeping the mail flowing. The owners of those sites have a right to dictate those policies. Not the senders. > Matt Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of 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: [PATCH] new bug report script
Matthias Juchem wrote: > BTW, lots of version dependencies found in older Changes document (i.e. > for 2.3.11) were removed now (2.4.0 shows only 9 where the old one had > 22). Have the removed ones been completely unnecessary? Quoting from 2.4.0's Changes file: [snip] > trying life on the Bleeding Edge. If upgrading from a pre-2.2.x > kernel, please consult the Changes file included with 2.2.x kernels for > additional information; most of that information will not be repeated > here. Basically, this document assumes that your system is already > functional and running at least 2.2.x kernels. Perhaps that accounts for the missing version dependencies... -Barry K. Nathan <[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/
Software requirements in Changes document
Hi Chris, Comparing the Changes document for 2.4.0 against the one from 2.3.11 one can see that many requirements were removed. Nine out of 22 are still there. Have the removed ones been unnecessary or only less important than the remaining ones? Regards, Matthias - 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: Related VIA PCI crazyness?
> Could anybody with a VIA chip who has the energy please do something for > me: > - enable DEBUG in arch/i386/kernel/pci-i386.h > - do a "/sbin/lspci -xxvvv" on the interrupt routing chip (it's the >"ISA bridge" chip - the VIA numbers are 82c586, 82c596, the PCI >numbers for them are 1106:0586 and 1106:0596, I think) > - do a cat /proc/pci Do you want any output from the enabling of DEBUG, or will doing that give more info in the other two steps? Once I get a reply, and once either you release 2.4.1 or Alan releases -ac4, I'll do that for you (I have a policy of not recompiling the same kernel twice...I'm just odd that way. Everybody needs a way to be odd, and this is mine. Odd is good). I like helping people. Kernels are fun! -- +--+---+ | Evan Thompson|POWERED BY:| | [EMAIL PROTECTED] | Linux cd168990-a 2.4.0-ac3 #1 Sat | | Freelance Computer Nerd | Jan 6 19:40:43 CST 2001 i686 | | http://evaner.penguinpowered.com | unknown (w/version number fix) | +--+---+ - 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/
[PLEASE-TESTME] Zerocopy networking patch, 2.4.0-1
I've put a patch up for testing on the kernel.org mirrors: /pub/linux/kernel/people/davem/zerocopy-2.4.0-1.diff.gz It provides a framework for zerocopy transmits and delayed receive fragment coalescing. TUX-1.01 uses this framework. Zerocopy transmit requires some driver support, things run as they did before for drivers which do not have the support added. Currently sg+csum driver support has been added to Acenic, 3c59x, sunhme, and loopback drivers. We had eepro100 support coded at one point, but it was removed because we didn't know how to identify the cards which support hw csum assist vs. ones which could not. I would like people to test this hard and report bugs they may discover. _PLEASE_ try to see if 2.4.0 without this patch produces the same problem, and if so report it is a 2.4.0 bug _not_ as a bug in the zerocopy patch. Thank you. In particular, I am interested in hearing about any new breakage caused by the zerocopy patches when using netfilter. When reporting bugs, please note what networking cards you are using as whether the card actually is using hw csum assist and sg support is an important data point. Finally, regardless of networking card, there should be a measurable performance boost for NFS clients with this patch due to the delayed fragment coalescing. KNFSD does not take full advantage of this facility yet. 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: [PATCH] new bug report script
On 7 Jan 2001, Ulrich Drepper wrote: > Why don't you, as the other script suggested, execute libc.so.6? > Symlinks can be missing or can be wrong. I'll have a look at this shell script and take the best out of both to make a new one. BTW, lots of version dependencies found in older Changes document (i.e. for 2.3.11) were removed now (2.4.0 shows only 9 where the old one had 22). Have the removed ones been completely unnecessary? - 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: [OT] Re: .br blacklisted ?
On Sunday 07 January 2001 18:22, Michael H. Warfield wrote: > > On Sun, Jan 07, 2001 at 07:27:45PM -0500, Gregory Maxwell wrote: > > On Sun, Jan 07, 2001 at 06:16:15PM -0500, Michael H. Warfield wrote: > > > 99% of mine is from China (either *.cn or 163.com or some other > > > numbering .com or .net. The .org is frowned upon in China - the TLD of > > > protestors and disidents). Half of what's left comes from either .kr > > > or .br. I'm fully in favor of an Internet Death Penalty against those > > > TLD's and associated domains till they clean up their acts. > > > > Yea! > > Next we'll take care of those subversive linux bastards that clog up our > > big pipes with their communist kernel downloads! > > > > Unsolicited commercial email is a problem. However, many of the > > 'solutions' are worse. Search for teergrube for a less subvertible aid. > > I already run several sugarplum sites with teergrubes. I also use > various blackhole lists and take other action against spammers, including > blocking entire rogue domains. If that rogue domain happens to be a two > letter TLD, so be it. If it gets bad enough, maybe they'll fix it. Hang 'em all and let God and the Devil sort them out? How enlightened... > > > You can pile on technological 'fixes' as much as you want, but no > > technological measure that does not totally oppress free use of the > > Internet will be affective. Education is the only solution, spam will > > continue as long as it is profitable. > > Actually, the most fun with the Chinese is to take advantage > of their "four horsemen of the Infocalypse". Ours (in the US and many > other western countries) is "Drug Dealing", "Money Laundering", > "Pedophiles", and "Terrorists". In China it's "Taiwan", "Tibet", > "Dissidents", and "Pornography". > > In discussing the Spam problem with some Chinese officials in > Beijing back in June of last year, they were really ho hum about the > whole thing till I mentioned that a lot of the spam being relayed out > of the Phillipeans through Chinese sites was promoting pornography. > That got some people sitting up real tight. They didn't care that > their pipeline in and out of China was oversubscribed by an order > of magnitude and spammers were clogging it with trash, but they > damn well did care if that trash had anything to do with pornography. > > I've heard some people suggest that they mail message back to > spam sites in China thanking them for their mail and including some > propaganda on Taiwan or Tibet. Maybe some Falun Gong literature would > be nice... Thereby killing how many hundreds of innocent people? China doesn't much believe in fining minor offenders, remember. You don't like Spam? Join the club. Blacklisting any domain - ANY domain - for spamming, unless you can absolutely prove that no legitimate email has ever been sent from that server, is completely unacceptable. You complain about the wasted time and bandwidth caused by Spam messages - how much time do you waste every year blocking legitimate messages? Matt - 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] new bug report script
Keith Owens <[EMAIL PROTECTED]> writes: > 5) > # glibc versions. Take the last symbolic link, > # extract the version number from the file it points to. > if [ `expr "X$1" : 'Xl'` -eq 2 ] > then > while [ "X$2" != "X->" ] > do > shift > done > version2=`echo "$3" | tr -cd '[.0-9]' | \ > sed -e 's/\.\.*/./g' | > sed -e 's/^\.//g' | > sed -e 's/\.$//g'` > fi > ;; Why don't you, as the other script suggested, execute libc.so.6? Symlinks can be missing or can be wrong. -- ---. ,-. 1325 Chesapeake Terrace Ulrich Drepper \,---' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.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: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 07:27:45PM -0500, Gregory Maxwell wrote: > On Sun, Jan 07, 2001 at 06:16:15PM -0500, Michael H. Warfield wrote: > > 99% of mine is from China (either *.cn or 163.com or some other > > numbering .com or .net. The .org is frowned upon in China - the TLD of > > protestors and disidents). Half of what's left comes from either .kr > > or .br. I'm fully in favor of an Internet Death Penalty against those > > TLD's and associated domains till they clean up their acts. > Yea! > Next we'll take care of those subversive linux bastards that clog up our big > pipes with their communist kernel downloads! > Unsolicited commercial email is a problem. However, many of the 'solutions' > are worse. Search for teergrube for a less subvertible aid. I already run several sugarplum sites with teergrubes. I also use various blackhole lists and take other action against spammers, including blocking entire rogue domains. If that rogue domain happens to be a two letter TLD, so be it. If it gets bad enough, maybe they'll fix it. > You can pile on technological 'fixes' as much as you want, but no > technological measure that does not totally oppress free use of the Internet > will be affective. Education is the only solution, spam will continue as > long as it is profitable. Actually, the most fun with the Chinese is to take advantage of their "four horsemen of the Infocalypse". Ours (in the US and many other western countries) is "Drug Dealing", "Money Laundering", "Pedophiles", and "Terrorists". In China it's "Taiwan", "Tibet", "Dissidents", and "Pornography". In discussing the Spam problem with some Chinese officials in Beijing back in June of last year, they were really ho hum about the whole thing till I mentioned that a lot of the spam being relayed out of the Phillipeans through Chinese sites was promoting pornography. That got some people sitting up real tight. They didn't care that their pipeline in and out of China was oversubscribed by an order of magnitude and spammers were clogging it with trash, but they damn well did care if that trash had anything to do with pornography. I've heard some people suggest that they mail message back to spam sites in China thanking them for their mail and including some propaganda on Taiwan or Tibet. Maybe some Falun Gong literature would be nice... Attack a social problem by turning another social problem loose... :-) Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of 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/
Bug: Frame-buffer (icon) rotates right in 2.4.0 when SMP
Hi, Apoligies in advance if this is not the right place to send this report. When displaying a screen-wide icon in the frame buffer for the graphics console: Linux version 2.4.0 Console Drivers Video mode selection support Support for frame buffer devices (EXPERMENTAL) VESA VGA graphics console I found the right edge of the image to be displayed on the left edge -- perhaps 8 pixels worth? I compiled for a pentium III, SMP on. I've a dual processor Pentium III with a Matrox Graphics, Inc. MGA G400 AGP video card. I discovered this using the lpp-0.2.0 patch at http://lpp.freelords.org, which displays a startup screen. Fix: turning SMP off fixed the problem. FYI: fbcon_show_logo() in drivers/video/fbcon.c seems to have a for loop with an odd smp_num_cpus reference. Please contact me if you need any more information or wish to tell me where to send this report. Regards, Karl <[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: [PATCH] Fix compile warnings in 2.4.0
On Sun, 7 Jan 2001 16:19:50 -0500, "Rich Baum" <[EMAIL PROTECTED]> wrote: >This patch should fix the rest of the warnings about #endif >statements when using the 20001225 gcc snapshot. Thanks to >Keith Owens for providing a script to automate this process. It got >the job done sooner and found warnings to fix for non x86 platforms. As reported by Neil Booth, your patch contains errors which do not appear in my patched system using my script. You probably skipped the leading '^' in the regexp. It also turns out that there are a couple of m68k assembler lines which have a trailing '#' which starts a comment on that assembler. So treat '#' as a comment marker as well. Whatever you used, it was not my script. It should be (with '#' added) find -type f -name '*.[chS]' | \ xargs perl -lpi -e 's:^(\s*#\s*endif)\s+([^/\s#].*)$:\1\t/* \2 */:;' BTW, until the patch is correct do not bother sending it to Alan Cox or Linus, just to linux-kernel.. - 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: FW: compile problem in 2.4.0-ac3
On Sun, 7 Jan 2001 15:02:40 -0800, A Guy Called Tyketto <[EMAIL PROTECTED]> wrote: >I'm still seeing > >#include > >at line 25 of acpi_ksyms.c. This is also the same line, in >patch-2.4.0-ac2 (counted the lines of each). Neither patches compile from this. Not happening here. -ac2 and -ac3 have the same text. diff -u --new-file --recursive --exclude-from /usr/src/exclude linux-2.4.0/drivers/acpi/acpi_ksyms.c linux.ac/drivers/acpi/acpi_ksyms.c --- linux-2.4.0/drivers/acpi/acpi_ksyms.c Thu Jan 1 01:00:00 1970 +++ linux.ac/drivers/acpi/acpi_ksyms.c Wed Jan 3 16:49:59 2001 @@ -0,0 +1,91 @@ +/* + * ksyms.c - ACPI exported symbols + * + * Copyright (C) 2000 Andrew Grover + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include <== line 25 +#include "acpi.h" You have corrupted your patch and/or source. - 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/
Paket counters for aliased interfaces ?
Hello, I would like to use IP-Aliasing to create a private network between a few machines without buying more hardware. That's easy, but ifconfig tells me: eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:x.x.x.x Bcast:x.x.x.x Mask:x.x.x.x UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:126810 errors:0 dropped:0 overruns:0 frame:1426 TX packets:49286 errors:0 dropped:0 overruns:0 carrier:0 collisions:15942 txqueuelen:100 Interrupt:17 eth0:0Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:10.1.1.1 Bcast:10.1.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:17 And here's the question: I would like to collect statistics for eth0:0 but obviously the pakets are only counted for the real interface. If I had enough time and knowledge, how should I implement paket counters for aliased interfaces ? PS: Am I right that it isn't possible ? tcpdump doesn't 'work right' either. - 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: routable interfaces WAS( Re: [PATCH] hashed device lookup(DoesNOT meet Linus' sumission policy!)
On Sun, 7 Jan 2001, Ben Greear wrote: > Hrm, what if they just made each IP-SEC interface a net_device? If they > are a routable entity, with it's own IP address, it starts to look a lot > like an interface/net_device. As in my response to Matti, i thing a netdevice is a generalized link layer structure and should remain that way. To add a new naming convention a "link" or maybe an "interface" is what the protocol aware part should be. Define a routable "interface" to be one that (from an abstraction perspective) sits on top of a netdevice and has a ifindex, name, and IP address (v4 or V6) I think the goals of the author of that IPSEC article are served with this scheme. I need to read that article, i just schemed through it. > > This has seeming worked well for VLANs: Maybe net_device is already > general enough?? I think it is not proper to generalize netdevices for IP. I am not thinking of dead protocols like IPX, more of other newer encapsulations such as MPLS etc. > > So, what would be the down-side of having VLANs and other virtual interfaces > be net_devices? The only thing I ever thought of was the linear lookups, > which is why I wrote the hash code. The beauty of working with existing > user-space tools should not be over-looked! > IP configuration tools you mean. Fine, they should be used to configure "interfaces" in the way i defined them above. > It may be easier to fix other problems with many interface/net_devices > than cram a whole other virtual net_device structure (with many duplicate > functionalities found in the current net_device). > It makes sense from an abstraction and management perspective to have all virtual interfaces which run on top of a physical interface to be managed in conjuction with the device. Device goes down, you destroy them or send them to a shutdown state (instead of messaging) etc. cheers, jamal - 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: [OT] Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 06:16:15PM -0500, Michael H. Warfield wrote: > 99% of mine is from China (either *.cn or 163.com or some other > numbering .com or .net. The .org is frowned upon in China - the TLD of > protestors and disidents). Half of what's left comes from either .kr > or .br. I'm fully in favor of an Internet Death Penalty against those > TLD's and associated domains till they clean up their acts. Yea! Next we'll take care of those subversive linux bastards that clog up our big pipes with their communist kernel downloads! Unsolicited commercial email is a problem. However, many of the 'solutions' are worse. Search for teergrube for a less subvertible aid. You can pile on technological 'fixes' as much as you want, but no technological measure that does not totally oppress free use of the Internet will be affective. Education is the only solution, spam will continue as long as it is profitable. - 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] new bug report script
On Sun, 07 Jan 2001 06:43:14 -0800,
David Ford <[EMAIL PROTECTED]> wrote:
>Matthias Juchem wrote:
>> My script is intended for the one who likes to provide bug reports but is
>> too lazy to look up all the information or simply is not sure about what
>> to include.
>
>Why can't it be done in sh?
In the dim, distant past I did a shell script that reads Changes,
extracts the lines which identify software versions and verifies that
your installed products were up to date. I sent it to Linus several
times and got no response so I dropped it. It was last run against
2.1.107, this is a quick and dirty upgrade against 2.4.0. A lot of the
entries are there for historical reasons but are probably worth keeping
for reference.
The tricky bit with shell is handling the different output when the
script is run as sh -x script. Use this script as a starting point if
you like it, if not, fold spindle and mutilate it.
--- check_linux_requirements ---
#!/bin/bash
#
# Read Documentation/Changes, extract the required software levels
# and check that the current system is up to date. Developed for
# 2.1.107. Will not work on 2.0.x because the Documentation/Changes
# on 2.0.x systems does not include commands, at least up to 2.0.34.
#
# Takes one optional parameter, the path to Documentation/Changes,
# default is /usr/src/linux/Documentation/Changes.
#
# This would be a lot easier in perl but users are not required to
# have perl to install Linux. awk was a possibility but some versions
# of awk have been known to break on readline which I needed. So shell
# it is.
#
# Keith Owens <[EMAIL PROTECTED]>. GPL. Sun Jun 28 21:20:10 EST 1998
#
# Updated for 2.4.0 Keith Owens <[EMAIL PROTECTED]>. Mon Jan 8 10:39:07 EST 2001
#
PATH=$PATH:/sbin:/bin:/usr/sbin:/usr/bin# may not have root's path
required() {
state=0
confirm=0
# NOTE: This code expects to see a line containing
# "Current Minimal Requirements" on its own, followed by '==='
# fillowed by each requirement on its own line starting with 'o',
# terminated by any line starting with at least ''.
# Requirement lines must start with "o ".
# The command to get the version (if any) must be preceded by '#'.
# The version number must appear just before '#' or as the last field
# if there is no command.
while read line
do
if [ $state -eq 0 -a "$line" = "Current Minimal Requirements" ]
then
state=1
fi
if [ $state -ge 1 ]
then
if ( expr "$line" : "" > /dev/null )
then
state=$[$state + 1]
if [ $state -eq 3 ]
then
break # end of requirements
fi
fi
if ( ! expr "$line" : "o" > /dev/null )
then
continue
fi
line=${line#"o "}
set -- $line
text=$1
version1=
command=
shift
while [ -n "$2" -a "$2" != "#" ]
do
text="$text $1"
shift
done
version1="$1"
shift
if [ "$1" = "#" ]
then
shift
fi
if [ -n "$1" ]
then
# pppd checks for device or tty before printing
version.
# < /dev/null causes an error.
if [ "$text" = "PPP" ]
then
command="$1 < /dev/ttyS0"
else
command="$1 < /dev/null"
fi
fi
while [ -n "$2" ]
do
if [ "X$2" = "Xor" ]
then
command="$command ;"
else
command="$command $2"
fi
shift
done
eval "($command)" 2>&1 | \
verify "$text" "$version1" "$command"
if [ $? -ne 0 ]
then
Re: .br blacklisted ?
On Sun, Jan 07, 2001 at 05:53:16PM -0500, John O'Donnell wrote: > Only on my company's e-mail server. My company typically gets "zero" > emails from outside the US. If I get a piece of spam (sorry they are > typically from outside the US), I just block the entire .com.br domain. > I get far less SPAM now! I cannot express how much I loathe SPAM! > I have taken this one in particular out just for you :-) > I am the only one at my company really active on the internet.. > apologies > Johnny O You are very luckey, I almost never get spam from outside of the US. :( - 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] hashed device lookup (Does NOT meet Linus' sumission
On Sun, 7 Jan 2001, Matti Aarnio wrote: > On Sun, Jan 07, 2001 at 02:10:52PM -0500, jamal wrote: > > OK. I suppose an skb->vlan_tag is passed to the driver and it will know > > what to do with it (pass it on a descriptor etc). > > Sure, nice. WHY SHOULD THERE BE MORE LAYER-2 STUFF ADDED TO > SKB OBJECTS ? > > One of important abstraction issues is to isolate device specific > new things (like what VLAN/PVC/SVC is used at your favourtite > 802.1Q/ATM/X.25/FrameRelay connection). > > The less we leak that kind of things to SKB, the better, IMO. > They are net_device issues, after all. You are right, the IP-ization information should be a "device" specific. What "device" means is the other discussion [I think we need new naming conventions and abstractions] > Tell me (if you can), why packet sender calls hardware-header > generation for packet, if the card can insert it for you ? > Consider the structure of Ethernet MAC header, where is source > address ? Where is the destination address ? If you write the > destination, why should you not write the source there too ? > It doesnt cost that much to do in s/ware if it is contigous and you have the information. some form of neighbor discovery protocol gathers all that info for you it is pretty cheap to insert the dst/src/etherype which you already have. Linux already has the 14 bytes link layer header cached today based on ARP for example. Works very nicely on the transmit path. Now consider trying to insert the VLAN header after all this work (it goes between the src MAC and the ethertype). If the hardware knows what to do with the tag, you dont need the hardware header rebuilder function. cheers, jamal - 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: [OT] Re: .br blacklisted ?
On Sun, 7 Jan 2001, Michael H. Warfield wrote: > 99% of mine is from China (either *.cn or 163.com or some other > numbering .com or .net. The .org is frowned upon in China - the TLD of > protestors and disidents). Half of what's left comes from either .kr > or .br. I'm fully in favor of an Internet Death Penalty against those > TLD's and associated domains till they clean up their acts. Don't forget .tw and .hk, a favorite of spammers. They seem to have abandoned .jp and moved on. There's also the sudden hurricane of spam in the past few months from .ar for inexplicable reasons. So that gets blocked too. Anyone know why the sudden burst of .ar spam? Some country-wide government endorsed spamming program? -Dan - 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] typo in vesafb.c (against 2.4.0-ac3)
[EMAIL PROTECTED] said: > > this looks like a typo and fixes a compile error in > 2.4.0-ac3. (replacing temp_sze with temp_size in drivers/video/vesafb.c) I had this problem too. For some reason this patch kept getting rejected by the patch program when I tried to apply it, but editing the file by hand to do what the patch does fixed the problem. Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ [EMAIL PROTECTED] Tilting at Windmills for a Better Tomorrow. - 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: Related VIA PCI crazyness?
In article <[EMAIL PROTECTED]>, Philip Armstrong <[EMAIL PROTECTED]> wrote: >In supplement to Evan Thompson's emails with the subject "Additional >info. for PCI VIA IDE crazyness. Please read." I've noticed the >following message with recent 2.4.0 test + release kernels: > >IRQ routing conflict in pirq table! Try 'pci=autoirq' But the machine still works fine, ie the SCSI driver and the network driver still seem happy? If so, it sounds like maybe the VIA pirq router functions are buggy (it looks like the sense of pirq 01 and pirq 03 are reversed). The problem Evan Thompson saw was apparently simply due to the magic meaning of the 0xfe and 0xff pirq entries, and has apparently been fixed by handling those correctly in the final 2.4.0. Christian Engstler seems to have a problem much like yours, where it gets a different irq line than the one that is apparently in use. It looks like Christian, too, has a working machine, and that the only bad result of this all is an annoying printk message. Can you confirm that things actually work for you too, and you'd just like to get rid of the unnerving message? If the VIA logic for getting/setting the irq is wrong, it should only be a problem if there are devices that _haven't_ been routed by the BIOS. Usually these devices are limited to things like USB, ACPI and CardBus controllers, and getting the irq routing wrong in that case can be deadly (infinite irq streams on the wrong irq line). The case where you get an annoying message are the cases where Linux knows something is wrong, but decides to take the safe approach - it seems to be working for you, as far as I can tell, but that message _does_ mean that we may have problems on other machines with the VIA chipset. I _think_ the VIA routing functions were done by Jeff Garzik, Cc'd. Looking at the VIA irq routing, it looks a bit strange. We have pirqa in the high nybble of config sparce port 55h, then we have pirqb and c in 56h (low and high nybbles respectively), and then we have pirqd in the high nybble of 57h. The reason this is strange is that it's not consecutive nybbles. I'd have expected pirqd to show up in the _low_ nybble of 57h. But as the pirq routing fields are pure software convention, it's hard to know whether this is already taken into account in the pirq routing table or what the magic is. Could anybody with a VIA chip who has the energy please do something for me: - enable DEBUG in arch/i386/kernel/pci-i386.h - do a "/sbin/lspci -xxvvv" on the interrupt routing chip (it's the "ISA bridge" chip - the VIA numbers are 82c586, 82c596, the PCI numbers for them are 1106:0586 and 1106:0596, I think) - do a cat /proc/pci With that, I and Jeff can probably match up the interrupt routing table entries with the devices, and check what the routing information in the config space of the actual router chip is, to verify what the pirq translation really should be. It's entirely possible that the Linux irq routing is already correct, and that the warning is due to a bug in the pirq table itself (and nobody has cared, because Windows works fine and picks up the value that the BIOS wrote to the device config spaces the same way Linux does - and Windows probably doesn't warn about the pirq table issue at all). Linus >PCI: Interrupt Routing Table found at 0xc00fdf00 >00:08 slot=01 0:01/deb8 1:02/deb8 2:03/deb8 3:05/deb8 >00:09 slot=02 0:02/deb8 1:03/deb8 2:05/deb8 3:01/deb8 >00:0a slot=03 0:03/deb8 1:05/deb8 2:01/deb8 3:02/deb8 >00:0b slot=04 0:05/deb8 1:01/deb8 2:02/deb8 3:03/deb8 >00:0c slot=05 0:01/deb8 1:02/deb8 2:03/deb8 3:05/deb8 >00:07 slot=00 0:00/deb8 1:00/deb8 2:00/deb8 3:00/deb8 >PCI: Using IRQ router VIA [1106/0586] at 00:07.0 >... >SCSI subsystem driver Revision: 1.00 >IRQ for 00:08.0:0 -> PIRQ 01, mask deb8, excl 0e00 -> newirq=11 -> got IRQ 9 >IRQ routing conflict in pirq table! Try 'pci=autoirq' >scsi0 : AdvanSys SCSI 3.2M: PCI Ultra 240 CDB: IO E800/F, IRQ 11 >... >8139too Fast Ethernet driver 0.9.13 loaded >IRQ for 00:0a.0:0 -> PIRQ 03, mask deb8, excl 0e00 -> newirq=9 -> got IRQ 11 >IRQ routing conflict in pirq table! Try 'pci=autoirq' >eth0: RealTek RTL8139 Fast Ethernet at 0xc8c39000, 00:40:95:33:7a:51, IRQ 9 >eth0: Identified 8139 chip type 'RTL-8139B' - 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_conntrack locks up hard on 2.4.0 after about 10 hours
In message <[EMAIL PROTECTED]> you write: > It seems that for one reason or another, ip_conntrack totally locks (not > removeable) after about 10 hours of continued use. All i found were > these messages in my dmesg output What was the contents of /proc/net/ip_conntrack? Being unremovable can happen if someone is holding a packet, which the below fix (by Xuan Baldauf) will often alleviate, but connection tracking doesn't DROP packets (NAT and packet filtering do). Hope that helps, Rusty. -- http://linux.conf.au The Linux conference Australia needed. diff -urN -I \$.*\$ -X /tmp/kerndiff.RnRDbE --minimal linux-2.4.0-test13-3/net/ipv4/ip_input.c working-2.4.0-test13-3/net/ipv4/ip_input.c --- linux-2.4.0-test13-3/net/ipv4/ip_input.cTue Dec 12 14:28:06 2000 +++ working-2.4.0-test13-3/net/ipv4/ip_input.c Mon Dec 18 17:07:06 2000 @@ -225,6 +225,13 @@ nf_debug_ip_local_deliver(skb); #endif /*CONFIG_NETFILTER_DEBUG*/ +#ifdef CONFIG_NETFILTER + /* Free reference early: we don't need it any more, and it may + hold ip_conntrack module loaded indefinitely. */ + nf_conntrack_put(skb->nfct); + skb->nfct = NULL; +#endif /*CONFIG_NETFILTER*/ + /* Point into the IP datagram, just past the header. */ skb->h.raw = skb->nh.raw + iph->ihl*4; - 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/
CML2 0.9.1 is available
The latest version is always available at http://www.tuxedo.org/~esr/cml2/ Release 0.9.1: Sun Jan 7 18:05:36 EST 2001 * Synchronized with 2.4.0 final. * Fixed bugs in handling of -W and -D flags. * "source" pathnames are now evaluated relative relative to the directory of the including file, so it's now possible to compile in a directory other than that of the rules file. Special thanks to Giacomo Catenazzi, whose persistence about reporting front-end bugs finally pushed me in the right direction to find some obscure problems I had never been able to reproduce before. -- http://www.tuxedo.org/~esr/">Eric S. Raymond To stay young requires the unceasing cultivation of the ability to unlearn old falsehoods. -- Lazarus Long - 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: [OT] Re: .br blacklisted ?
On Mon, Jan 08, 2001 at 12:03:19AM +0100, Pedro M. Rodrigues wrote: >Lucky b*st*rd! ;-) My spam is mostly from USA. Just deleted 78 > of those, and only 7 seemed to be from abroad. I wish i could block > .com ... ;-) 99% of mine is from China (either *.cn or 163.com or some other numbering .com or .net. The .org is frowned upon in China - the TLD of protestors and disidents). Half of what's left comes from either .kr or .br. I'm fully in favor of an Internet Death Penalty against those TLD's and associated domains till they clean up their acts. > Pedro > On 7 Jan 2001, at 17:53, John O'Donnell wrote: > > Only on my company's e-mail server. My company typically gets "zero" > > emails from outside the US. If I get a piece of spam (sorry they are > > typically from outside the US), I just block the entire .com.br > > domain. I get far less SPAM now! I cannot express how much I loathe > > SPAM! I have taken this one in particular out just for you :-) I > > am the only one at my company really active on the internet.. > > apologies Johnny O Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of 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: FW: compile problem in 2.4.0-ac3
On Sun, Jan 07, 2001 at 11:57:08PM +1100, Keith Owens wrote: > On Sun, 7 Jan 2001 04:32:25 -0800, > A Guy Called Tyketto <[EMAIL PROTECTED]> wrote: > >make[3]: Entering directory `/usr/src/linux/drivers/acpi' > >gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 > >-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 > >-march=k6 > >-I./include -D_LINUX -DEXPORT_SYMTAB -c acpi_ksyms.c > >acpi_ksyms.c:25: linuxpi.h: No such file or directory > > Line 25 in patch-2.4.0-ac3.bz2 says > > #include > > You have corrupted your source. This is what I get for trying this at 4am in the morning! *g* This isn't happening to acpi_ksyms.c, but actually drivers/acpi/ksyms.c (the assume -R bit, I mean). I still get the above error with. I'm still seeing #include at line 25 of acpi_ksyms.c. This is also the same line, in patch-2.4.0-ac2 (counted the lines of each). Neither patches compile from this. I've gone through the -ac2 patch, and there's only 2 places where is located: added to the newly-created acpi_ksyms.c from the patch, and being backed out of drivers/acpi/ksyms.c. Other than that, there is no mention of it in the source. Only saying no to CONFIG_ACPI gets around it. BL. -- Brad Littlejohn | Email:[EMAIL PROTECTED] Unix Systems Administrator, | [EMAIL PROTECTED] Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF - 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: xfs mount opts (was: More better in mount(2))
hi, On Jan 5, 3:51pm, Daniel Phillips wrote: > Subject: Re: More better in mount(2) > Nathan Scott wrote: > > On Jan 5, 3:26am, Daniel Phillips wrote: > > > ... > > > This filesystem mount option parsing code is completely ad hoc, and uses > > > strtok which is horribly horribly broken. (Do man strtok and read the > > > 'Bugs' section.) > > > > > > It would be worth thinking about how to do this better. > > > > hmm ... can't claim I wrote this code, just looked at it. > > are you saying the kernel strtok is horribly broken or just > > the way its being used here? (and why?) > > >From the man page: > ... yup, I did see that. I've gone through the code and I can't see anything wrong with it (tell me if I've missed something). If the problem is simply that its using strtok, then this must just be a perceived problem rather than an actual problem (the data is copied, and noone uses it other than the parsing code, afaict). >From a look through how the other filesystems do this, it seems most use strtok (including ext2). cheers. -- Nathan - 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/
[OT] Re: .br blacklisted ?
Lucky b*st*rd! ;-) My spam is mostly from USA. Just deleted 78 of those, and only 7 seemed to be from abroad. I wish i could block .com ... ;-) Pedro On 7 Jan 2001, at 17:53, John O'Donnell wrote: > Only on my company's e-mail server. My company typically gets "zero" > emails from outside the US. If I get a piece of spam (sorry they are > typically from outside the US), I just block the entire .com.br > domain. I get far less SPAM now! I cannot express how much I loathe > SPAM! I have taken this one in particular out just for you :-) I > am the only one at my company really active on the internet.. > apologies Johnny O > - 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: .br blacklisted ?
Only on my company's e-mail server. My company typically gets "zero" emails from outside the US. If I get a piece of spam (sorry they are typically from outside the US), I just block the entire .com.br domain. I get far less SPAM now! I cannot express how much I loathe SPAM! I have taken this one in particular out just for you :-) I am the only one at my company really active on the internet.. apologies Johnny O Rik van Riel wrote: > Hi, > > I just got this bounce message when sending my response > to [EMAIL PROTECTED] his question. John, could you set > your spam filters to something more reasonable and make > sure you don't include whole countries ??? > > [or ... why are you asking questions here if you don't > want an answer?] > > > (my message) > Date: Sun, 7 Jan 2001 20:07:52 -0200 (BRDT) > From: Rik van Riel <[EMAIL PROTECTED]> > To: John O'Donnell <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: 2.4.0: __alloc_pages: 3-order allocation failed. > > (the bounce) >- The following addresses had permanent fatal errors - > <[EMAIL PROTECTED]> > (reason: 550 5.0.0 We don't accept mail from spammers) > >- Transcript of session follows - > while talking to linsrv.voicefx.com.: > MAIL From:<[EMAIL PROTECTED]> >>> > <<< 550 5.0.0 We don't accept mail from spammers > 554 5.0.0 <[EMAIL PROTECTED]>... Service unavailable > > > Rik > -- > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ > http://www.conectiva.com/ http://distro.conectiva.com.br/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- what's the difference between chattr and chmod? SomeLamer: man chattr > 1; man chmod > 2; diff -u 1 2 | less -- Seen on #linux on irc === Never ask a geek why, just nod your head and slowly back away.=== +==++ | John O'Donnell (Sr. Systems Engineer, Net Admin, Webmaster, etc.) | | Voice FX Corporation (a subsidiary of Student Advantage) | | One Plymouth Meeting | E-Mail: [EMAIL PROTECTED] | | Suite 610| www.voicefx.com | | Plymouth Meeting, PA 19462 | www.campusdirect.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: posix_types.h error
Mike Galbraith wrote: > On Sun, 7 Jan 2001, Richard B. Johnson wrote: [snip] > > None of the named compilers gripe? Where, prey tell, do I get the source- > > code of a compiler that works? The only source provided in the site > > listed in the Documentation does not. > > It's not the only source there.. egcs-1.1.2 is there as well. You can > also try egcs.cygnus.com/pub/egcs or a mirror. Richard is asking for source code. Documentation/Changes only gives the location of binaries. This is a bit of a problem IMO (I also tried, and failed, to find the egcs 1.1.2 source code). Now that I know where it is, I'll soon post a patch for Documentation/Changes... -Barry K. Nathan <[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: [PATCH] hashed device lookup (Does NOT meet Linus' sumission
On 7 Jan, Alan Cox wrote: >> Um, what about people running their box as just a VLAN router/firewall? >> That seems to be one of the principle uses so far. Actually, in that case >> both VLAN and IP traffic would come through, so it would be a tie if VLAN >> came first, but non-vlan traffic would suffer worse. > > Why would someone filter between vlans when any node on each vlan can happily > ignore the vlan partitioning > You might be connected to a vlan capable switch which will only feed the `right' vlan to a certain port... In this case an one-armed firewall might make sense. /Daniel -- - 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/
