Linux NAT questions
what I am trying to do is this. I have a genuine network, say 1.1.1.x, and my Linux host is on it, as 1.1.1.252 (eth0). I also have a second network at the back of the Linux box, 192.168.200.x, and a web server on that network, 192.168.200.2. The Linux address is 192.168.200.1 on eth1. What I want to do is make the web server appear on the 1.1.1.x network as 1.1.1.160. I have done this before with Firewall-1 on NT, by putting an arp entry for 1.1.1.160 to point to the Linux machine eth0. The packets get redirected into the Linux machine, then translated, and then routed out of eth1. The benefit is that there is no routing change to the 1.1.1.x network, and the Linux box isn't even seen as a router. I would appreciate any help with this. Any command to do this? Chee Tong == De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. == The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. == - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Unknown HZ value! (2000) Assume 1024.
Alpha. 2.4.1. Hz = 1024. Uptime > 48.54518 days (low idle). (Subject message from ps and friends.) /proc/uptime: 4400586.27 150439.36 /proc/stat: cpu 371049158 3972370867 8752820 4448994822 (user,nice, system, idle) In .../fs/proc/proc_misc.c:kstat_read_proc(), the cpu line is being computed by: len = sprintf(page, "cpu %u %u %u %lu\n", user, nice, system, jif * smp_num_cpus - (user + nice + system)); The user, nice, and system values add up to 4352172845 > 2^32, and jif is 4400586.27 * 1024 = 4506200340, leading to the incorrect idle time (1 cpu). It should be calculated this way: len = sprintf(page, "cpu %u %u %u %lu\n", user, nice, system, jif * smp_num_cpus - ((unsigned long)user + nice + system)); or just declare those as unsigned longs instead of ints. I notice also that since kstat.per_cpu_nice is an int, it's going to overflow in another 3.6 days anyhow. I'll let you know what blows up then. Any chance of making those guys longs? The ps program, of course, is trying to calculate HZ by inverting the above calculation, and it gets a bogus value. I suppose it could use (uptime[0] - uptime[1]) / (user + nice + system) instead of trying to calculate jif first, but it'll still fail when the ints roll over. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: someody help me out
>I am just a beginner in linux programming and I want to write a >script for disconnecting users in cisco router. This would be the wrong list to ask such a question. It is for the discussion of the inner workings of the Linux kernel, not for questions about applications which can be run on a Linux based system. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
someody help me out
Hello all, I am just a beginner in linux programming and I want to write a script for disconnecting users in cisco router.Could anybody help me out. The scenario is like this. I have been using Cisco router2500 and in that we have users connected to it in async port. when I execute the command. Router#sh users I will get something like this Line User Host(s)Idle location 1 tty 1user async interfacedial-up for ISP now if i execute the command Router#clear line 1 the "user" will be disconnected from the router. Now what I want is to write a script that will disconnect the user from the router. When you telnet to the router the process goes like this telnet ip address then it will ask for password: then you get something like this router>en (you have to type en to enable it) then again it asks for password password: once you give the password Router#show users (you have to execute the following command) then if you want to disconnect particular user then you give command Router#clear line 1 how do i put the whole thing in a script and achieve the above .Could anybody help me out. Thanking you, Ajay Dangol. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.4 breaks VMware
On Tue, 1 May 2001, Mohammad A. Haque wrote: > [EMAIL PROTECTED] wrote: > > This patch replaces a wee bit of code vmware wanted in include/linux/skbuff.h > > although I'm guessing it was removed for a reason and vmware should be patched > > to use the new method. > > > > Better to patch vmware rather than the kernel. Here's a patch thet > should be applied to source files in > /usr/lib/vmware/modules/source/vmnet.tar An even better solution would be getting vmware 2.0.4 which seems to be a bit more 2.4-kernel compliant. It is not yet announced on their web from what I can see but you may already fetch it from p.ex. ftp://download1.vmware.com/pub/software/ -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3 2.4.4pre8: aic7xxx showstopper bug fails to detect sda
>Since the official aic7xxx site doesn't carry a patch against 2.4.4 yet >(just 2.4.3) which has cosmetic issues when being patched, I made a >patch against 2.4.4: I took the 2.4.3-aic7xxx-6.1.12 patch, applied to >2.4.4, bumped the version to read -ma1 in EXTRAVERSION, and made a new >patch against vanilla 2.4.4, to be found at: Version 6.1.13 of my aic7xxx driver is now up. I've included patches to 2.4.4 and 2.4.4-ac2. If this version still causes problems for you, please boot with "aic7xxx=verbose" and send me any diagnostic output the driver prints. I'll try to correct your issue as quickly as I can. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3 2.4.4pre8: aic7xxx showstopper bug fails to detect sda
>I guess we'll just have to wait for Justin to come out with the real patch... It's out. -- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New aic7xxx driver locking disk access
> >1. New aic7xxx driver locking disk access The 6.1.5 version of the aic7xxx driver is quite stale. Can you try 6.1.13 from: http://people.FreeBSD.org/~gibbs/linux/ and see if this clears up your problem? Thanks, Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.3-ac9/4 - NFS corruption
Quoting Trond Myklebust <[EMAIL PROTECTED]> from ml.linux.kernel: :> " " == Raphael Manfredi <[EMAIL PROTECTED]> writes: : > An "ls -l" on the file yields: : : > -rw--- 1 ram users 1642491 May 1 00:00 inbox : : > (on the server, and via NFS), which is *abnormal*, since it's : > 15:18 and I've just updated the file. Therfore, the timestamp : > is corrupted as well in the inode. : :In that case you have some other task that has done a 'touch' or :something to the file. An NFS client does not explicitly set the :timestamp when doing ordinary reading/writing to a file - it leaves it :to the server to do so. Of course, I understand that. It's *abnormal* because I told "mutt" to delete a message from the mailbox, and then re-synchronized it, thereby writing to it. I expected the timestamp to be updated on the server after that operation. It did not happen. :Would you happen to be delivering mail to the same file on the server :or something like that? Yes, mail is delivered on the server by mailagent, so with proper local locking. :If so it's completely normal behaviour: the userland NFS doesn't :support file locking, so there's no way that the client can guarantee :that some task on the server won't write to the file behind its :back... Does kernel-land NFS support file locking? In any case, "mutt" does not lock the file, so yes, I'm perfectly aware there could be a race. But not the kind of race that would NULL-ify 5 bytes on the file when read from the client, whilst those same bytes are perfectly normal when read from the server. Raphael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH: fix mxser driver for MOXA C104/PCI
The attached patch fixes the MOXA driver properly. Indexing is 0 based, so
rather than adjust the enum, don't subtract 1 from each index. Also use a
for loop for the PCI devices, and up the version number.
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
--- drivers/char/mxser.c.orig Tue May 1 21:00:50 2001
+++ drivers/char/mxser.cTue May 1 21:01:06 2001
@@ -27,10 +27,11 @@
*
* Copyright (C) 1999,2000 Moxa Technologies Co., LTD.
*
- * for : LINUX 2.0.X, 2.2.X
- * date: 1999/07/22
- * version : 1.1
+ * for : LINUX 2.0.X, 2.2.X, 2.4.X
+ * date: 2001/05/01
+ * version : 1.2
*
+ *Fixes for C104H/PCI by Tim Hockin <[EMAIL PROTECTED]>
*/
#include
@@ -61,7 +62,7 @@
#include
#include
-#defineMXSER_VERSION "1.1kern"
+#defineMXSER_VERSION "1.2"
#defineMXSERMAJOR 174
#defineMXSERCUMAJOR175
@@ -120,7 +121,7 @@
#define CI104J_ASIC_ID 5
enum {
- MXSER_BOARD_C168_ISA = 1,
+ MXSER_BOARD_C168_ISA = 0,
MXSER_BOARD_C104_ISA,
MXSER_BOARD_CI104J,
MXSER_BOARD_C168_PCI,
@@ -434,7 +425,7 @@
"mxser", info);
if (retval) {
restore_flags(flags);
- printk("Board %d: %s", board, mxser_brdname[hwconf->board_type - 1]);
+ printk("Board %d: %s", board, mxser_brdname[hwconf->board_type]);
printk(" Request irq fail,IRQ (%d) may be conflit with another
device.\n", info->irq);
return (retval);
}
@@ -455,7 +446,7 @@
unsigned int ioaddress;
hwconf->board_type = board_type;
- hwconf->ports = mxser_numports[board_type - 1];
+ hwconf->ports = mxser_numports[board_type];
ioaddress = pci_resource_start (pdev, 2);
for (i = 0; i < hwconf->ports; i++)
hwconf->ioaddr[i] = ioaddress + 8 * i;
@@ -544,7 +535,7 @@
if (retval != 0)
printk("Found MOXA %s board (CAP=0x%x)\n",
- mxser_brdname[hwconf.board_type - 1],
+ mxser_brdname[hwconf.board_type],
ioaddr[b]);
if (retval <= 0) {
@@ -579,7 +570,7 @@
if (retval != 0)
printk("Found MOXA %s board (CAP=0x%x)\n",
- mxser_brdname[hwconf.board_type - 1],
+ mxser_brdname[hwconf.board_type],
ioaddr[b]);
if (retval <= 0) {
@@ -612,21 +603,15 @@
n = sizeof(mxser_pcibrds) / sizeof(mxser_pciinfo);
index = 0;
- b = 0;
- while (b < n) {
+ for (b = 0; b < n; b++) {
pdev = pci_find_device(mxser_pcibrds[b].vendor_id,
mxser_pcibrds[b].device_id, pdev);
- if (!pdev)
- {
- b++;
- continue;
- }
- if (pci_enable_device(pdev))
+ if (!pdev || pci_enable_device(pdev))
continue;
hwconf.pdev = pdev;
printk("Found MOXA %s board(BusNo=%d,DevNo=%d)\n",
- mxser_brdname[mxser_pcibrds[b].board_type - 1],
- pdev->bus->number, PCI_SLOT(pdev->devfn >> 3));
+ mxser_brdname[mxser_pcibrds[b].board_type],
+ pdev->bus->number, PCI_SLOT(pdev->devfn));
if (m >= MXSER_BOARDS) {
printk("Too many Smartio family boards found (maximum
%d),board not configured\n", MXSER_BOARDS);
} else {
@@ -1352,7 +1337,7 @@
return;
if (port == 0)
return;
- max = mxser_numports[mxsercfg[i].board_type - 1];
+ max = mxser_numports[mxsercfg[i].board_type];
while (1) {
irqbits = inb(port->vector) & port->vectormask;
Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability
> > this has nothing to do with the very specific disk corruption > > being discussed (which has to do with the ide controller, according > > to the most recent rumors.). > > Actually, I think there are 2 problems that have been discussed -- the > disk corruption and a general instability resulting in oops'es at > various points shortly after boot up. I don't see this. specifically, there were scattered reports of a via-ide problem a few months ago; this is the issue that's gotten some press, and for which Alan has a fix. and there are reports of via-smp problems at boot (which go away with noapic). I see no reports of the kind of general instability you're talking about. and all the via-users I've heard of have no such stability problems - me included (kt133/duron). the only general issue is that kx133 systems seem to be difficult to configure for stability. ugly things like tweaking Vio. there's no implication that has anything to do with Linux, though. > > My memory system jas been set up very conservitavely and has been > rock solid in my other board (ka7), so I doubt it's that, but I > sure am happy to try a few more cominations of bios settings. Anything > I should look for in particular? how many dimms do you have? interleave settings? Vio jumper? already checked on cooling issues? and that you're not overclocking... > > why resort to silly windows tools, when lspci under Linux does it for you? > > Because lspci does not display all 256 bytes of pci configuration > information. sure it does: (from my kt133 hostbridge) [root@crema /root]# lspci -s 00:00.0 -xxx 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) 00: 06 11 05 03 06 00 10 22 02 00 00 06 00 00 00 00 10: 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 27 a4 0b b4 46 02 08 08 08 00 00 00 04 08 08 08 60: 0c 00 00 00 d5 d6 d5 00 50 5d 86 0d 08 01 00 00 70: c9 88 cc 0c 0e a0 d2 00 01 b4 01 02 00 00 00 00 80: 0f 40 00 00 f0 00 00 00 02 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 02 c0 20 00 07 02 00 1f 00 00 00 00 2b 02 04 00 b0: 7f 63 2a 65 31 33 c0 0c 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 0e 22 00 00 00 00 00 00 00 [root@crema /root]# od -Ax -txC /proc/bus/pci/00/00.0 00 06 11 05 03 06 00 10 22 02 00 00 06 00 00 00 00 10 08 00 00 e0 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50 27 a4 0b b4 46 02 08 08 08 00 00 00 04 08 08 08 60 0c 00 00 00 d5 d6 d5 00 50 5d 86 0d 08 01 00 00 70 c9 88 cc 0c 0e a0 d2 00 01 b4 01 02 00 00 00 00 80 0f 40 00 00 f0 00 00 00 02 00 00 00 00 00 00 00 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0 02 c0 20 00 07 02 00 1f 00 00 00 00 2b 02 04 00 b0 7f 63 2a 65 31 33 c0 0c 00 00 00 00 00 00 00 00 c0 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * f0 00 00 00 00 00 00 00 0e 22 00 00 00 00 00 00 00 000100 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability
In mailing-lists.linux-kernel, Seth wrote: > Because lspci does not display all 256 bytes of pci configuration >information. Umm, "lspci -xxx"? At least, on lspci version 2.1.8 from RedHat 7.1. Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How can do to disable the L1 cache in linux ?
Dear All,
How can do to disable the L1 cache in linux ?
Are there some commands or directives to disable it ??
Thanks
Alex
N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±êçzX§¶¡Ü¨}©²Æ zÚ:+v¨¾«êçzZ+Ê+zf£¢·h§~Ûiÿûàz¹ ®w¥¢¸?¨èÚ&¢)ߢfù^jÇ«y§m
á@A«a¶Úÿ
0¶ìh®åi
Re: Question on including 'math.h' from C runtime...
"Steven J. Hill" <[EMAIL PROTECTED]> said: > I checked in the archives and did not see a discussion of this > anywhere. I have received some Linux kernel code from a project > that I have inherited and a couple of the drivers are including > math.h from the C library. This being the header file from > '/usr/include/math.h' in most cases. There are only two places > in the kernel that also include this header file. They are: > >drivers/atm/iphase.c >drivers/net/hamradio/soundmodem/gentbl.c > > As far as I can tell '/usr/include/math.h' is just full of > defines and the header files it includes are also a bunch > of defines with a few macro functions sprinkled in. Can someone > shed light on if this is bad or not and why it would be done > or necessary? Thanks. Floating point in-kernel is a no-no-no. What you see is use in helper programs that are compiled as part of the kernel build. Check if that is your case too. -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inserting a Forth-like language into the Linux kernel
On Tue, 1 May 2001, Rick Hohensee wrote: > (kspamd) is the Linux-side wrapper for H3sm C|N>K OK, you owe me a new keyboard. And thanks for new .sig. BTW, Rick, out of curiosity - how many Greencard Lawyers does it take to upgrade the thing to full-blown H1 S? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question on including 'math.h' from C runtime...
Greetings. I checked in the archives and did not see a discussion of this anywhere. I have received some Linux kernel code from a project that I have inherited and a couple of the drivers are including math.h from the C library. This being the header file from '/usr/include/math.h' in most cases. There are only two places in the kernel that also include this header file. They are: drivers/atm/iphase.c drivers/net/hamradio/soundmodem/gentbl.c As far as I can tell '/usr/include/math.h' is just full of defines and the header files it includes are also a bunch of defines with a few macro functions sprinkled in. Can someone shed light on if this is bad or not and why it would be done or necessary? Thanks. -Steve -- Steven J. Hill - Embedded SW Engineer Public Key: 'http://www.cotw.com/pubkey.txt' FPR1: E124 6E1C AF8E 7802 A815 FPR2: 7D72 829C 3386 4C4A E17D - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][CFT] (updated) ext2 directories in pagecache
Hello Daniel,
This combination against 2.4.4 won't allow directories to be moved.
Ex: mv a b #fails with I/O error. See attached strace.
But with ext2-dir-patch-S4 by itself, mv works as it should.
Later,
Albert
Daniel Phillips wrote:
>
> > Patch is on ftp.math.psu.edu/pub/viro/ext2-dir-patch-S4.gz
>
> Here is my ext2 directory index as a patch against your patch:
>
> http://kernelnewbies.org/~phillips/htree/dx.pcache-2.4.4
>
> Changes:
>
> - COMBSORT macro replaced by custom sort code
> - Most #ifdef CONFIG_EXT2_INDEX's changed to if ()
>
> To do:
>
> - Split up the split code
> - Finalize hash function
> - Test/debug big endian
> - Fall back to linear search if bad index detected
> - Fail gracefully on random data
> - Remove the tracing and test options
>
> To apply:
>
> cd source/tree
> zcat ext2-dir-patch-S4.gz | patch -p1
> cat dx.pcache-2.4.4 | patch -p0
>
> To create an indexed directory:
>
> mount /dev/hdxxx /test -o index
> mkdir /test/foo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Albert Cranford Deerfield Beach FL USA
[EMAIL PROTECTED]
execve("/bin/mv", ["mv", "a", "b"], [/* 47 vars */]) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40007000
mprotect(0x4000, 21025, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x8048000, 52997, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
stat("/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=44476, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
mmap(NULL, 44476, PROT_READ, MAP_SHARED, 3, 0) = 0x40008000
close(3)= 0
stat("/etc/ld.so.preload", {st_mode=S_IFREG|0644, st_size=1, ...}) = 0
open("/etc/ld.so.preload", O_RDONLY)= 3
mmap(NULL, 2, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x40013000
close(3)= 0
munmap(0x40013000, 2) = 0
open("/lib/libc.so.5", 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\*\1\000"..., 4096) = 4096
mmap(NULL, 786432, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40013000
mmap(0x40013000, 555135, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x40013000
mmap(0x4009b000, 21344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x87000) =
0x4009b000
mmap(0x400a1000, 204364, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x400a1000
close(3)= 0
mprotect(0x40013000, 555135, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
munmap(0x40008000, 44476) = 0
mprotect(0x8048000, 52997, PROT_READ|PROT_EXEC) = 0
mprotect(0x40013000, 555135, PROT_READ|PROT_EXEC) = 0
mprotect(0x4000, 21025, PROT_READ|PROT_EXEC) = 0
personality(PER_LINUX) = 0
geteuid() = 0
getuid()= 0
getgid()= 0
getegid() = 0
brk(0x80568bc) = 0x80568bc
brk(0x8057000) = 0x8057000
geteuid() = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
stat("b", 0xb76c) = -1 ENOENT (No such file or directory)
lstat("a", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("b", 0x8056660) = -1 ENOENT (No such file or directory)
rename("a", "b")= -1 EIO (Input/output error)
write(2, "mv: ", 4mv: ) = 4
write(2, "cannot move `a\' to `b\'", 22cannot move `a' to `b') = 22
stat("/etc/locale/C/libc.cat", 0xb2f0) = -1 ENOENT (No such file or directory)
stat("/usr/share/locale/C/libc.cat", 0xb2f0) = -1 ENOENT (No such file or
directory)
stat("/usr/share/locale/libc/C", 0xb2f0) = -1 ENOENT (No such file or directory)
stat("/usr/share/locale/C/libc.cat", 0xb2f0) = -1 ENOENT (No such file or
directory)
stat("/usr/local/share/locale/C/libc.cat", 0xb2f0) = -1 ENOENT (No such file or
directory)
write(2, ": I/O error", 11: I/O error) = 11
write(2, "\n", 1
) = 1
_exit(1)= ?
How can do to disable the L1 cache in linux ?
Dear All,
How can do to disable the L1 cache in linux ?
Are there some commands or directives to disable it ??
Thanks
Alex
èº{.nÇ+·®+%Ëlzwm
éb맲æìr¸zX§» ®w¥{ayº ÊÚë,j¢f£¢·hàz¹ ®w¥¢¸
¢·¦j:+v¨wèjØm¶ÿ¾«êçzZ+ùÝ¢j"ú!¶iOæ¬z·vØ^¶m§ÿðà nÆàþY&
inserting a Forth-like language into the Linux kernel
( H3sm is my 3-stack Forth variant. ) I have a Linux 2.4.0-test10 kernel building and booting nicely with H3sm partially installed as an in-kernel thread ala kswapd, the virtual memory swapper. This means H3sm runs in cooperative multitasking with the Linux schuduler, i.e. it's something of a co-kernel with Linux. H3sm looks like this from the Linux side in the unix /proc pseudo-filesystem of system information... Name: kspamd State: Z (zombie) Pid:4 PPid: 1 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 0 Groups: SigPnd: SigBlk: SigIgn: SigCgt: SigCgt: CapInh: CapPrm: CapEff: feff H3sm is of course the 4th process ;o) (kspamd) is the Linux-side wrapper for H3sm :;ps PID TTY STATRSS COMMAND 1 0 S 89 (init) 2 0 S 0 (kswapd) 3 0 S 0 (kreclaimd) 4 0 Z 0 (kspamd) 5 0 S 0 (kflushd) 6 0 S 0 (kupdate) 12 1026S 157 (bash) 19 1027S 143 (bash) 20 1028S 141 (bash) 21 1029S 137 (bash) 22 1030S 142 (bash) 23 1031S 137 (bash) 24 1032S 137 (bash) 25 1033S 137 (bash) 26 1034S 137 (bash) 27 1035S 137 (bash) 28 1036S 137 (bash) 44 0 S 83 (mouse) 67 0 S 101 (syslogd) 80 1029S 140 (bash) 81 1029S 339 (browse) 83 1088S 148 (pppd) 85 1028S 84 (irc) 88 1028S 311 (ircii-EPIC4pre2) 89 1028S 63 (in.identd) 91 1027S 1287(slrn) 92 1027S 108 (edit) 94 1030S 345 (browse) 95 1031R 2 (ps) H3sm doesn't yet survive the boot process, and gets killed and becomes a a unix "zombie process" (the Z's in the listings). I just spent 3 days running around in circles at the lowest level to no avail, other than I think I may have arrived at a realization that I badly mis-concieved H3sm's behavior requirements trying to do "file" reads as part of the kernel. H3sm opens the file namespace representation of the first virtual console just fine, namely /dev/tty1. It can beep the console before going zombie, which is a "file" write of one character, ASCII 7. (I've left /dev/tty1 unallocated in the usual init process on the Linux side, so that when H3sm does work it won't be competing with a getty or shell for user input.) For reading user input, the regular userland H3sm was doing a blocking read, i.e. it would call the form of read syscall that pauses the process until the "file" replies somehow. This is asking a bit much of kernel code, to say the least. The userland H3sm lets the console driver provide it with line-wise communications from the user. I just hope it's possible to do a character-wise version from the kernel, or some other work-around. If it is possible to read a virtual terminal from the kernel the possibilities are outrageous. The more general cases of file IO and terminal IO are proven possible. This approach could be applied to various Forths, for those who like thier stacks in matched pairs. H3sm is built into the kernel by sneaking in behind the real in-kernel daemons in mm/vmscan.c. This avoids a lot of #include complexity. A wrapper mimicing the outermost code of kpiod or kreclaimd is what the kspamd is on the Linux side. Playing around in there you see neat examples of the cooperative multi-tasking at the core of Linux. You can hog the CPU, grab it periodically, mark your self runnable and keep CPU use at 100% while still switching to Linux, and so on. You relinquish the CPU from the H3sm/Forth/whatever side with the Linux "schedule" call. Syscalls are as per usual, except with the more fundamental coordination issues. Here's some of H3sm in x86 gas and m4... .. top_loop_of_H3sm: pushf pusha call schedule # exuent to host popa popf call token YES(mozygote) call interpret mov A to 0 [note to c.l.f: This is my debugging hook. Do a Linux "oops" here.] ELL(top_loop_of_H3sm) #zz mozygote: call beep # call Source # call zero # call store # call pdrop #call cr call refill call drop ELL(top_loop_of_H3sm) initialdp:
Re: Linux 2.4.4-ac3
* Miles Lane <[EMAIL PROTECTED]> [May 01. 2001 18:50]: > This patch is not showing up on ftp.kernel.org. > Can you check that you actually got is pushed? > Perhaps something is busted in the mirroring? ftp://ftp.linux.org.uk:/pub/linux/alan/ -- Mads Martin Joergensen, http://mmj.dk "Why make things difficult, when it is possible to make them cryptic and totally illogic, with just a little bit more effort." -- A. P. J. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Followup to previous post: Atlon/VIA Instabilities
Manfred Spraul wrote:
>
> > So it seems that CONFIG_X86_USE_3DNOW is simply used to
> > enable access to the routines in mmx.c (the athlon-optimized
> > routines on CONFIG_K7 kernels), so then it appears that somehow
> > this is corrupting memory / not behaving as it should (very
> > technical, right?) :)...
>
> Do you use any unusual (binary only/with source) kernel modules?
>
> mmx.c stores the current contents on the fpu registers into
> current->thread.i387.f{,x}save.
> If another module modifes the fpu registers and calls memmove it will
> cause fpu corruptions.
>
> I checked that a few months ago, and no module in the main kernel tree
> does that.
No, actually the instability starts right after/when the root
filesystem is mounted (it seems). I have no foreign modules installed
when this error occurs. Even if I did, why would the Abit KA7 with the
same [other] hardware and software NOT show this problem, even with all
opts enabled?
--Seth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Mark Hahn wrote: > > > And that's exactly what I did :)... I found that ONLY the combination > > of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in > > results in this wackiness. I should alos repeat that I *DO* see that > > I doubt that USE_3DNOW is causing the problem, but rather when you > USE_3DNOW, the kernel streams through your northbridge at roughly > twice the bandwidth. if your dram settings are flakey, this could > eaily trigger a problem. > > this has nothing to do with the very specific disk corruption > being discussed (which has to do with the ide controller, according > to the most recent rumors.). Actually, I think there are 2 problems that have been discussed -- the disk corruption and a general instability resulting in oops'es at various points shortly after boot up. My memory system jas been set up very conservitavely and has been rock solid in my other board (ka7), so I doubt it's that, but I sure am happy to try a few more cominations of bios settings. Anything I should look for in particular? Thanks, Seth > > > The other thing i was gunna try is to dump my chipset registers using > > WPCREDIT and WPCRSET and compare them with other people on this list > > why resort to silly windows tools, when lspci under Linux does it for you? > > regards, mark hahn. > Because lspci does not display all 256 bytes of pci configuration information. --S - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac3
On Tue, 01 May 2001 18:42:01 -0700, Miles Lane <[EMAIL PROTECTED]> wrote: >This patch is not showing up on ftp.kernel.org. hpa says it is a bandwidth problem in kernel.org, have patience. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.4.4 breaks VMware
[EMAIL PROTECTED] wrote: > This patch replaces a wee bit of code vmware wanted in include/linux/skbuff.h > although I'm guessing it was removed for a reason and vmware should be patched > to use the new method. > Better to patch vmware rather than the kernel. Here's a patch thet should be applied to source files in /usr/lib/vmware/modules/source/vmnet.tar -- = 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] = diff -urw vmnet-only/vnetInt.h vmnet-only-patched/vnetInt.h --- vmnet-only/vnetInt.hWed Nov 1 20:48:28 2000 +++ vmnet-only-patched/vnetInt.hTue Apr 17 23:29:47 2001 @@ -16,9 +16,15 @@ # define KFREE_SKB(skb, type) kfree_skb(skb) # define DEV_KFREE_SKB(skb, type) dev_kfree_skb(skb) # define SKB_INCREF(skb) atomic_inc(&(skb)->users) +# ifdef KERNEL_2_4_0 +#define SKB_IS_CLONE_OF(clone, skb)( \ + skb_cloned(clone) \ + ) +# else # define SKB_IS_CLONE_OF(clone, skb) ( \ skb_datarefp(clone) == skb_datarefp(skb) \ ) +# endif # define SK_ALLOC(pri)sk_alloc(0, pri, 1) # define DEV_QUEUE_XMIT(skb, dev, pri)( \ (skb)->dev = (dev), \
Re: [PATCH] 2.4.4 breaks VMware
[EMAIL PROTECTED] writes:
> --- skbuff.h.orig Tue May 1 18:41:50 2001
> +++ skbuff.hTue May 1 18:41:55 2001
> @@ -244,6 +244,11 @@
>
> /* Internal */
> #define skb_shinfo(SKB)((struct skb_shared_info *)((SKB)->end))
> +/* for vmware */
> +static inline atomic_t *skb_datarefp(struct sk_buff *skb)
> +{
> +return (atomic_t *)(skb->end);
> +}
No, the equivalent is _shinfo(skb)->dataref
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.4 breaks VMware
Despite VMware's webpage claiming compatibility issues with 2.4.x kernels I'd
been using it without any problem until I upgraded to 2.4.4. I couldn't use
their precompiled modules of course but compiling to match the running kernel
worked fine previously.
This patch replaces a wee bit of code vmware wanted in include/linux/skbuff.h
although I'm guessing it was removed for a reason and vmware should be patched
to use the new method.
--- skbuff.h.orig Tue May 1 18:41:50 2001
+++ skbuff.hTue May 1 18:41:55 2001
@@ -244,6 +244,11 @@
/* Internal */
#define skb_shinfo(SKB)((struct skb_shared_info *)((SKB)->end))
+/* for vmware */
+static inline atomic_t *skb_datarefp(struct sk_buff *skb)
+{
+ return (atomic_t *)(skb->end);
+}
/**
* skb_queue_empty - check if a queue is empty
Tim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac3
Hi Alan, This patch is not showing up on ftp.kernel.org. Can you check that you actually got is pushed? Perhaps something is busted in the mirroring? Thanks, Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and 2GB swap partition limit
On Wed, 2 May 2001, Roger Larsson wrote: > On Wednesday 02 May 2001 02:43, Rik van Riel wrote: > > On Tue, 1 May 2001, David S. Miller wrote: > > > Rik van Riel writes: > > > > Then we will be scanning through memory looking for something to > > > > swap out (otherwise we'd not be in need of swap space, right?). > > > > At this point we can simply free up swap entries while scanning > We could reclaim swap space for dirty pages. They have to be > rewritten anyway... > > Or would the fragmentation risk be too high? I guess the fragmentation would get worse. Also, when you've got more than enough swap left there's absolutely no reason to reclaim the swap when pages get dirtied. I just guess we should start reclaiming swap space as soon as the free swap space gets below, say, 5%. We could go for a more complex system of only reclaiming the swap space of dirty pages from a lower threshold on, but I doubt that's worth the complexity. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and 2GB swap partition limit
On Wednesday 02 May 2001 02:43, Rik van Riel wrote: > On Tue, 1 May 2001, David S. Miller wrote: > > Rik van Riel writes: > > > Then we will be scanning through memory looking for something to > > > swap out (otherwise we'd not be in need of swap space, right?). > > > At this point we can simply free up swap entries while scanning > > > through memory looking for stuff to swap out. > > > > Sounds a lot like my patch I posted a few weeks ago: > > Not really. Your patch only reclaims swap cache pages that > hang around after a process exit()s. What I want to do is > reclaim swap space of pages which have been swapped in so > we can use that swap space to swap something else out. > We could reclaim swap space for dirty pages. They have to be rewritten anyway... Or would the fragmentation risk be too high? /RogerL -- Roger Larsson Skellefteå Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How can do to turn off the L1 cache in linux
Dear All,
How can do to turn off the L1 cache in linux ?
Are there some commands or directives to turn off it ??
Thanks
Alex
èº{.nÇ+·®+%Ëlzwm
éb맲æìr¸zX§» ®w¥{ayº ÊÚë,j¢f£¢·hàz¹ ®w¥¢¸
¢·¦j:+v¨wèjØm¶ÿ¾«êçzZ+ùÝ¢j"ú!¶iOæ¬z·vØ^¶m§ÿðà nÆàþY&
Re: isa_read/write not available on ppc - solution suggestions ??
Linus Torvalds writes: > I would suggest the opposite approach instead: make the PPC just support > isa_readx/isa_writex instead. We can certainly do that, no problem. BUT that won't get a token ring pcmcia card working in the newer powerbooks, such as the titanium G4 powerbook, because the PCI host bridge doesn't map any cpu addresses to the bottom 16MB of PCI memory space. This is not a problem as far as pcmcia cards are concerned - the pcmcia stuff just picks an appropriate address (typically in the range 0x9000 - 0x9fff) and sets the pcmcia/cardbus bridge to map that to the card. But it means that the physical addresses for the card's memory space will be above the 16MB point, so it is essential to do the ioremap. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
APM idle behaviour
Hi, all. I've been staring at the APM code and trying to figure out some things related to idle behaviour. I'm staring at the code for 2.2.19. My first question is why does cpu_idle() wait for 0.33 seconds of idling before calling acpi_idle() (apm_cpu_idle() in fact)? Why not wait less time, or more? Another question is why do PS/2 mouse events break out of apm_cpu_idle() whereas keyboard events do not? I've hacked apm_cpu_idle() to increment a global counter, and then I can run a programme to show the value of this counter. I can type in commands and even switched between windows using a keyboard shortcut, and the global counter doesn't increment. As soon as I move the mouse or press a mouse key, the counter will increment. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Compiling modules for kernel 2.4
On 1 May 2001 13:11:33 CDT, shreenivasa H V <[EMAIL PROTECTED]> wrote: >I am having trouble compiling the modules for kernel 2.4. The compilation >doesn't go through, it just goes into each directory and says "nothing to do" >and comes out. The object files are not created. Does your 2.4.4 .config define any modules? grep '=m' .config. The default i386 config only has one module, drivers/net/dummy.o. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and 2GB swap partition limit
On Tue, 1 May 2001, David S. Miller wrote: > Rik van Riel writes: > > Then we will be scanning through memory looking for something to > > swap out (otherwise we'd not be in need of swap space, right?). > > At this point we can simply free up swap entries while scanning > > through memory looking for stuff to swap out. > > Sounds a lot like my patch I posted a few weeks ago: Not really. Your patch only reclaims swap cache pages that hang around after a process exit()s. What I want to do is reclaim swap space of pages which have been swapped in so we can use that swap space to swap something else out. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and 2GB swap partition limit
Rik van Riel writes:
> Then we will be scanning through memory looking for something to
> swap out (otherwise we'd not be in need of swap space, right?).
> At this point we can simply free up swap entries while scanning
> through memory looking for stuff to swap out.
Sounds a lot like my patch I posted a few weeks ago:
--- mm/vmscan.c.~1~ Wed Apr 11 19:05:59 2001
+++ mm/vmscan.c Thu Apr 12 17:19:51 2001
@@ -441,8 +441,14 @@
maxscan = nr_inactive_dirty_pages;
while ((page_lru = inactive_dirty_list.prev) != _dirty_list &&
maxscan-- > 0) {
+ int dead_swap_page;
+
page = list_entry(page_lru, struct page, lru);
+ dead_swap_page =
+ (PageSwapCache(page) &&
+page_count(page) == (1 + !!page->buffers));
+
/* Wrong page on list?! (list corruption, should not happen) */
if (!PageInactiveDirty(page)) {
printk("VM: page_launder, wrong page on list.\n");
@@ -453,9 +459,10 @@
}
/* Page is or was in use? Move it to the active list. */
- if (PageTestandClearReferenced(page) || page->age > 0 ||
- (!page->buffers && page_count(page) > 1) ||
- page_ramdisk(page)) {
+ if (!dead_swap_page &&
+ (PageTestandClearReferenced(page) || page->age > 0 ||
+(!page->buffers && page_count(page) > 1) ||
+page_ramdisk(page))) {
del_page_from_inactive_dirty_list(page);
add_page_to_active_list(page);
continue;
@@ -481,8 +488,11 @@
if (!writepage)
goto page_active;
- /* First time through? Move it to the back of the list */
- if (!launder_loop) {
+ /* First time through? Move it to the back of the list,
+* but not if it is a dead swap page. We want to reap
+* those as fast as possible.
+*/
+ if (!launder_loop && !dead_swap_page) {
list_del(page_lru);
list_add(page_lru, _dirty_list);
UnlockPage(page);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and 2GB swap partition limit
On Tue, 1 May 2001, Stephen C. Tweedie wrote: > The right fix is to reclaim such pages only when we need to. To > disable swap caching when we still have enough swap free would hurt > users who have the spare swap to cope with it. That's easy enough. When we are: 1. almost out of swap and 2. need swap space Then we will be scanning through memory looking for something to swap out (otherwise we'd not be in need of swap space, right?). At this point we can simply free up swap entries while scanning through memory looking for stuff to swap out. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Meaning of major kernel version number
Oliver Neukum wrote: > > On Tuesday, 1. May 2001 22:49, Erik Hensema wrote: > > Hi, > > > > A little question which may be a FAQ: what does the major version number > > [1] of the Linux kernel (still) mean? What is the policy on increasing the > > major version (eg. on what basis it is decided the next kernel isn't going > > to be 2.6 but 3.0)? > > Our great fearless leader will talk with the penguin beyond the sky. > > HTH > Oliver > - One definition might be that it changes when user code must be relinked to work with the next version. George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.19 locks up on SMP
On Tue, 1 May 2001, Trond Myklebust wrote: > > I'll give your patch a spin tomorrow, after I catch some > > zzz's. :-) > > Right you are. And indeed, the tcp-hang patch fixed the problem! Thanks a lot! > FYI I've now put up those patches of which I am aware against 2.2.19 > on > > http://www.fys.uio.no/~trondmy/src/2.2.19 > > I'll try to keep that area updated with a brief explanation for each > patch... That's where I tried looking first, two days ago, but couldn't find anything, and I must have overlooked the patch you sent to the list. Thanks for crediting me, btw. :-) Just one little nit: the readdir() problem appears only when using glibc-2.0, glibc-2.1 seems to be fine. Thanks again to everybody, Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
reason for VIA performance drop since 2.4.2-ac21
I have motherboard with VIA MVP3 chipset. I noticed big video slowdown since 2.4.2-ac21. Watching "divx" by avifile with new kernels is impossible, becouse very bad performance. Now, after few hours - I found the reason, and I don't understand it. It has nothing to do with mtrr or K6. In file arch/i386/kernel/pci-pc.c there is a pci_fixup_via691_2 function. It appeared in 2.4.2-ac21. And it works for my chipset - VIA_82C598. When I put "return" in body of this function, recompile and start kernel 2.4.4 - "x11perf -putimage100" shows that video works fast again. I see two possibilities: 1) this is just a debug code, and kernels >2.4.2-ac20 shouldn't be used by VIA MVP3 owners 2) this code fix crash possibility, and all kernels without it (including 2.2.19) are buggy with VIA MVP3 What is true, and is it safe to skip that function if I need 2.4 and fast video? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Dead keys
* At 2001-05-02T01:12+0200, [EMAIL PROTECTED] wrote: : | The first line makes unadorned [no Shift, Ctrl, Alt] slash | (on my keyboard the key with keytop / has keycode 53 as showkey tells me) | into a dead ASCII slash. The 0d part is for "dead". Well, if I had known this, I could've saved us all some time. Sorry about that, ignore the patch -- doesn't matter that the default is weird when I can change it. :) Thanks for the info. -- Stian Sletner, gets to work on his keymap again - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Aironet doesn't work
I tried 2.4.4-ac2 this morning. The warning about rx_queue_len is gone :-) but I have one about tx_full_rate: May 1 12:37:25 oleron cardmgr[150]: + Warning: /lib/modules/2.4.4-ac2/kernel/drivers/net/aironet4500_core.o symbol for parameter tx_full_rate not found That's easily solved by applying the following: --- cut here --- --- aironet4500_core.c.orig Mon Apr 30 19:14:38 2001 +++ aironet4500_core.c Mon Apr 30 19:14:47 2001 @@ -2568,7 +2568,7 @@ MODULE_PARM(awc_debug,"i"); MODULE_PARM(tx_rate,"i"); MODULE_PARM(channel,"i"); -MODULE_PARM(tx_full_rate,"i"); +//MODULE_PARM(tx_full_rate,"i"); MODULE_PARM(adhoc,"i"); MODULE_PARM(master,"i"); MODULE_PARM(slave,"i"); --- cut here --- On Tue, 1 May 2001, Keith Owens wrote: > >> Apr 30 13:19:35 oleron cardmgr[148]: get dev info on socket 0 > >> failed: Resource temporarily unavailable > > Separate problem, the aironet4500_cs driver could not get its > resources. I still get this message but I didn't have much time to play with the irq / ioport allocations. That's what you meant by 'resources', right? Unfortunately I don't have access to the card anymore (well, I'll try to borrow it again) so I won't be able to do more tests. Since it looks like a hardware resource issue here are some more details about my config for future cross-referencing. The laptop is a Sony Vaio F560. lspci says the following: 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 03) 00:08.0 FireWire (IEEE 1394): Sony Corporation CXD3222 i.LINK Controller (rev 02) 00:09.0 Multimedia audio controller: Yamaha Corporation YMF-744B [DS-1S Audio Controller] (rev 02) 00:0a.0 Communication controller: CONEXANT: Unknown device 2443 (rev 01) 00:0c.0 CardBus bridge: Ricoh Co Ltd RL5c478 (rev 80) 00:0c.1 CardBus bridge: Ricoh Co Ltd RL5c478 (rev 80) 01:00.0 VGA compatible controller: Neomagic Corporation: Unknown device 0016 (rev 10) On another laptop the card was using interrupt 15 and ioports 0140-017f which on this one would conflict with ide1. But there's other ranges available. 0170-0177 : ide1 15: 0 XT-PIC ide1 -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DHCP comiling issues under sparc linux
Leif Sawyer writes: > Below is the end of a thread between myself and Ted Lemon > regarding building DHCP under Sparc Linux. > > I'm not well versed in parsing the kernel code to know > what the subtle differences in the different implementations > of this IOCtl, and am looking for some guidance from the > appropriate maintainers. > > Please read below for the summary. I'll be happy to fill > in the blanks off-list. It is a bug if it behaves differently, without question. Can you give a trace of a bad case? The code looks fine to me, but if I am shown a specific trace I may be able to see the bug. Please, this is an issue I have with many bug reports. The text of the report uses a lot of non-specific wording, "SIOCGIFCONF with NULL arg gives different results on sparc64 than i386" That is great and gives me the gist of the problem, but without a specific trace of arguments and results and a description of what is specifically expected in this traced case compared to what actually happened, I do a lot of guessing to work on a fix. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Breakage of opl3sax cards since 2.4.3 (at least)
On Tue, 1 May 2001, David Bronaugh wrote: > opl3sax cards have refused to init in Linux with the in-kernel OSS driver > since 2.4.3 at least (last I tested and worked was 2.4.1). I'm pretty sure > this is a kernel issue as it's happened on 2 different machines, one of > which I never goofed around with. My card [I should say chipset - built in to mobo] initialised partially. [Running 2.4.3-ac5] > Usually message is something like: > > opl3sa2: Control I/O port 0x220 (or whatever is tried) is not a YMF7xx > chipset! I believe I saw something like this, but the sound subsystem initialised, it was just the gameport that was dead. I resurrected it by cat'ing the following into /proc/isapnp card 0 YMH0802 dev 0 YMH0022 port 0 0x201 activate What does your /proc/isapnp say? -- Nobody wants constructive criticism. It's all we can do to put up with constructive praise. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4 and 2GB swap partition limit
On 1 May 2001, Christoph Rohland wrote: > On Mon, 30 Apr 2001, Alan Cox wrote: > >> paging in just released 2.4.4, but in previuos kernel, a page that > >> was paged-out, reserves its place in swap even if it is paged-in > >> again, so once you have paged-out all your ram at least once, you > >> can't get any more memory, even if swap is 'empty'. > > > > This is a bug in the 2.4 VM, nothing more or less. It and the > > horrible bounce buffer bugs are forcing large machines to remain on > > 2.2. So it has to get fixed > > Yes, it is a bug. and thanks for stating this so clearly. I finished my USENIX paper (yeah I know, exactly on the deadline ;)) so now I have time again. This bug is one of the more important ones on my TODO list. Let me see if I can cook up a race-free way of fixing this one. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: * Re: Severe trashing in 2.4.4
On Tue, May 01, 2001 at 04:00:53PM -0700, David S. Miller wrote:
>
> Frank, thanks for doing all the legwork to resolve the networking
> side of this problem.
No problem...
I just diff'd the 'old' and 'new' kernel trees. The one which produced the
ravenous skb_hungry kernels was for all intents and purposed identical to the
one which produced the (working, bug_free(tm)) kernel I'm currently running...
Must be the weather...
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est." ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Dead keys
> The issue here is that the dead keys themselves > are producing the wrong characters. No. If someone without diaeresis key uses the double quote, and attaches dead_diaeresis to it, she probably wants that double quote when it is followed by a space. When programming one needs quotes etc. When writing text one needs a-umlaut and c-cedilla etc. Very few people need a lone diaeresis. I do not mind if most people would need an additional keystroke to obtain that. > the dead_* are wrong, and I can't change them with a keymap, afaik? Yes, you can. Linux keyboard handling is very flexible. You can change the table of compose definitions with loadkeys, and there is no restriction of what is combined with what. You can also make any symbol into a dead symbol. Example: % loadkeys plain keycode 53 = 0x0d2f compose '/' 'o' to '\370' % This makes the slash (on my keyboard) into a dead slash: when followed by an o I get the Danish oslash (ø), and otherwise it remains a slash. Explanation of the loadkeys input: The first line makes unadorned [no Shift, Ctrl, Alt] slash (on my keyboard the key with keytop / has keycode 53 as showkey tells me) into a dead ASCII slash. The 0d part is for "dead". The 2f part is hex for the ASCII slash (octal 057). The combine statement adds a combination to the compose table. (Maybe it was there already - didnt check.) For 2f and 370, see ascii(7) and iso_8859-1(7). Andries [Yes, a very small example, and the input contains numbers in decimal, octal and hexadecimal.] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] pdc20267 and dma timeouts
Hi,
I am running 2.4.4 with the lvm -0.91 beta7 patches applied on a debian
sid base. When I checked my box this morning the follow greeted me on
the serial console. The reiserfs errors are caused by the DMA timeout.
Note this is a ultra100 controller not supporting raid.
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
is_tree_node: node level 15360 does not match to the expected one 1
vs-5150: search_by_key: invalid format found in block 40470. Fsck?
vs-13070: reiserfs_read_inode2: i/o failure occurred trying to find stat data
o]vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
vs-13048: reiserfs_iget: bad_inode. Stat data of (112833 113085) not found
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hde: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: DMA disabled
ide2: reset: success
hdg: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdg: irq timeout: status=0x50 { DriveReady pmlete }
hde: lost interrupt
hdg: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdg: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: lost interrupt
hdg: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdg: irq timeout: status=0x50 { DriveReady SeekComplete }
hde: lost interrupt
hdg: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdg: irq timeout: status=0x50 { DriveReady SeekComplete }
hdg: DMA disabled
ide3: reset: success
hde: lost interrupt
hde: lost interrupt
hde: lost interrupt
hde: lost interrupt
hde: lost interrupt
hde: lost interrupt
hde: lost interrupt
with another lost interrupt entry added every couple of seconds. Looks like
the reset is not working... Here is a lspci -vv of the device
00:0a.0 Unknown mass storage controller: Promise Technology, Inc. 20267 (rev 02)
Subsystem: Promise Technology, Inc.: Unknown device 4d33
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
DHCP comiling issues under sparc linux
Below is the end of a thread between myself and Ted Lemon regarding building DHCP under Sparc Linux. I'm not well versed in parsing the kernel code to know what the subtle differences in the different implementations of this IOCtl, and am looking for some guidance from the appropriate maintainers. Please read below for the summary. I'll be happy to fill in the blanks off-list. Thanks, Leif -Original Message- Ted Lemon responds to: > Leif Sawyer who wrote: > Under Kernel 2.4.3, at least for Sparc64, the following > define in includes/cf/linux.h creates the problem: > > 154: #define SIOCGIFCONF_NULL_BUF_GIVES_CORRECT_LEN > > undef'ing this out allows the server to build correctly > and initialize properly. > > #if !(defined(__sparc__) && (LINUX_MAJOR >= 2 && LINUX_MINOR >= 4)) > #define SIOCGIFCONF_NULL_BUF_GIVES_CORRECT_LEN > #endif Hm. So Linux 2.4 on Sparc provides a different API than Linux 2.4 on Intel. That's lame. But I would like to think that this would be considered a bug, and therefore fixed. > I'll try this on my i386 box at home and see if it compiles correctly > as well. That won't be until late tonight, if i'm lucky. Cool, thanks. The code *should* work unmodified on Linux 2.4/i386. Really, it should work for the sparc version as well - I don't suppose I could talk you into reporting this to the Linux/sparc people as a bug? The deal is that you're supposed to be able to call SIOCGIFCONF with a length of zero, and SIOCGIFCONF will return the length of the buffer needed to record all the interface configuration information, and then you allocate a buffer that size and call SIOCGIFCONF again. This supposedly works on 2.4 for intel, and on 2.2 for intel, so it makes sense that it should work on 2.2 and 2.4 for sparc as well. :'} _MelloN_ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IP Acounting Idea for 2.5
On Fri, Apr 20, 2001 at 02:51:55AM +, Ton Hospel wrote: > Resettable counters are evil. Perhaps "evil" should be reserved to describe counters which automatically reset as a side effect of being read. > I really think cisco got this right: from the commandline interface > you can reset counters, and watch them, the SNMP counters however just > keep going and going and going independently from this. Except for the IP accounting table? The 'checkpoint' operation copies and *clears* the table ... I don't really need snapshots, just hazard-free reads. It's quite easy to work out deltas in userspace, but I'd hate for things to be unnecessarily painful for multiple readers. Mark. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Actual patch for next gen PM interface
This is an attempt at a generic PM event interface for the kernel.
The design is more or less obvious and was laid out in a previous
message. Comments appreciated.
Alan Cox <[EMAIL PROTECTED]> writes:
> > > The entire PM layer for the embedded board I worked on was
> > > 3Kbytes. How small will yours be 8)
> >
> > The generic event interface will be under 3kB, I hope. Would you
> > accept it if so? ;-)
>
> We shall see. I've played with several ideas and never really been
> happy with them so maybe you can solve it
The fruits of today's labour are here. Unfortunately it *is* just over
3kB (but if I understand correctly under 4kB) mostly due to the
generous buffer sizes.
Note that this is prelim work. (Particularly the changes to the APM
stuff need to be looked at, and are not strictly relevant to the patch
at hand.) At the moment, APM events are printed to /dev/pmevent and
kmsg. Suspend requests are no longer acted on by the kernel. This
breaks backward compatibility.
The /dev/pmevent stuff is hopefully pretty feature complete. The
device numbers for it are 10 137. Multiple listeners are allowed etc.
diff --new-file -u --recursive --exclude *~ linux-2.4.4-orig/arch/i386/kernel/apm.c linux-2.4.4-pmevent/arch/i386/kernel/apm.c
--- linux-2.4.4-orig/arch/i386/kernel/apm.c Tue May 1 14:33:34 2001
+++ linux-2.4.4-pmevent/arch/i386/kernel/apm.c Tue May 1 23:47:18 2001
@@ -186,6 +186,7 @@
#include
#include
#include
+#include
#include
#include
@@ -327,7 +328,6 @@
#endif
static int suspends_pending;
static int standbys_pending;
-static int waiting_for_resume;
static int ignore_normal_resume;
static int bounce_interval = DEFAULT_BOUNCE_INTERVAL;
@@ -886,33 +886,6 @@
#endif
}
-static int send_event(apm_event_t event)
-{
- switch (event) {
- case APM_SYS_SUSPEND:
- case APM_CRITICAL_SUSPEND:
- case APM_USER_SUSPEND:
- /* map all suspends to ACPI D3 */
- if (pm_send_all(PM_SUSPEND, (void *)3)) {
- if (event == APM_CRITICAL_SUSPEND) {
-printk(KERN_CRIT "apm: Critical suspend was vetoed, expect armageddon\n" );
-return 0;
- }
- if (apm_info.connection_version > 0x100)
-apm_set_power_state(APM_STATE_REJECT);
- return 0;
- }
- break;
- case APM_NORMAL_RESUME:
- case APM_CRITICAL_RESUME:
- /* map all resumes to ACPI D0 */
- (void) pm_send_all(PM_RESUME, (void *)0);
- break;
- }
-
- return 1;
-}
-
static int suspend(void)
{
int err;
@@ -927,7 +900,6 @@
err = APM_SUCCESS;
if (err != APM_SUCCESS)
apm_error("suspend", err);
- send_event(APM_NORMAL_RESUME);
sti();
queue_event(APM_NORMAL_RESUME, NULL);
for (as = user_list; as != NULL; as = as->next) {
@@ -968,6 +940,43 @@
return 0;
}
+static void announce_event(apm_event_t event)
+{
+ char*type = PME_NOTIFY;
+ char*name;
+
+ if (event <= NR_APM_EVENT_NAME)
+ name = apm_event_name[event - 1];
+ else name = "unknown event";
+
+ switch(event){
+ case APM_SYS_STANDBY:
+ case APM_USER_STANDBY:
+ case APM_SYS_SUSPEND:
+ case APM_USER_SUSPEND:
+ case APM_CRITICAL_SUSPEND:
+ type = PME_SLEEP;
+ break;
+ case APM_NORMAL_RESUME:
+ case APM_CRITICAL_RESUME:
+ case APM_STANDBY_RESUME:
+ type = PME_WAKE;
+ break;
+ case APM_CAPABILITY_CHANGE:
+ type = PME_NOTIFY;
+ break;
+ case APM_LOW_BATTERY:
+ type = PME_EMERGENCY;
+ break;
+ case APM_POWER_STATUS_CHANGE:
+ type = PME_POWERCHANGE;
+ break;
+ default:
+ type = PME_NOTIFY;
+ }
+ pme_announce(type,"APM",name);
+}
+
static void check_events(void)
{
apm_event_t event;
@@ -989,56 +998,35 @@
if (ignore_normal_resume && (event != APM_NORMAL_RESUME))
ignore_normal_resume = 0;
+ announce_event(event);
+
switch (event) {
case APM_SYS_STANDBY:
case APM_USER_STANDBY:
- if (send_event(event)) {
-queue_event(event, NULL);
-if (standbys_pending <= 0)
- standby();
- }
+ queue_event(event, NULL);
+ if (standbys_pending <= 0)
+standby();
break;
case APM_USER_SUSPEND:
-#ifdef CONFIG_APM_IGNORE_USER_SUSPEND
- if (apm_info.connection_version > 0x100)
-apm_set_power_state(APM_STATE_REJECT);
- break;
-#endif
case APM_SYS_SUSPEND:
- if (ignore_bounce) {
-if (apm_info.connection_version > 0x100)
- apm_set_power_state(APM_STATE_REJECT);
-break;
- }
- /*
- * If we are already processing a SUSPEND,
- * then further SUSPEND events from the BIOS
- * will be ignored. We also return here to
- * cope with the fact that the Thinkpads keep
- * sending a SUSPEND event until something else
- * happens!
+ /* Reject all suspend requests and let
+ * userspace call suspend if they want to
*/
- if (waiting_for_resume)
-return;
- if (send_event(event)) {
-queue_event(event, NULL);
-waiting_for_resume = 1;
-if (suspends_pending <= 0)
- (void) suspend();
- }
+ if (apm_info.connection_version > 0x100)
+apm_set_power_state(APM_STATE_REJECT);
+
+ queue_event(event, NULL);
break;
case APM_NORMAL_RESUME:
case
Re: 2.4.4: Kernel crash, possibly tcp related
[EMAIL PROTECTED] writes: > > See? > > I see! Dave, please, take the second Andrea's patch (appended). > It is really the cleanest one. Thanks a lot Andrea and Alexey. I've applied the patch. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: * Re: Severe trashing in 2.4.4
Frank, thanks for doing all the legwork to resolve the networking side of this problem. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Maximum files per Directory
H. Peter Anvin writes: > Not correct, there can't be more than 2^15 *directories* in a single > directory. I belive this is an ext2 limitation. This is imposed by a number of issues: - EXT2_LINK_MAX=32000 is checked for new subdirectories - ext2 bg_used_dirs_count is a __u16 - inode->i_nlink (__kernel_nlink_t) is an unsigned short for some platforms For stat (old interface) the st_nlinks count is also an unsigned short, so we _should_ be able to increase EXT2_LINK_MAX to 65500 or so safely. The VFS will have problems if you increase the max link count over 65535 because __kernel_nlink_t is __u16. I see that reiserfs plays some tricks with the directory i_nlink count. If you exceed 64536 links in a directory, it reverts to "1" and no longer tracks the link count. You will have problems with performance for directories this large on stock ext2, unless you use Daniel Phillips' indexed directory patch. I have tested 100k+ _files_ in a single directory without problems (Daniel has tested 1M _files_ without problems). I would NOT reccommend doing this on your production mail server at this time, but it may be worth testing at least... It does not (yet) address the issue of lots of subdirectories, but that is something that can be worked on at least. http://kernelnewbies.org/~phillips/htree/ Cheers, Andreas -- Andreas Dilger Turbolinux filesystem development http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: * Re: Severe trashing in 2.4.4
On Tuesday, May 01, 2001 03:11:58 PM -0700 David <[EMAIL PROTECTED]> wrote: > Can't say for a definite fact that it was reiserfs but I can say for a > definite fact that something fishy happens sometimes. > > If I have a text file open, something.html comes to mind, If I edit it > and save it in one rxvt and open it in another rxvt, my changes may not > be there. If I save it *again* or exit the editing process, I will see > the changes in the second term. No, I'm not accidently forgetting to > save it, I know for a fact that I saved it and the first terminal shows > the non-modified state with the changes and the second term shows the > previous data. > > Somewhere something is stuck in cache and what's on disk isn't what's in > cache and a second process for some reason gets what is on disk and not > what is in cache. > > It happens infrequently but it -does- happen. Does it happen with -o notail? Which editor? -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs+lndir problem [was: 2.4.4 SMP: spurious EOVERFLOW"Value too large for defined data type"]
On Wednesday, May 02, 2001 12:41:52 AM +0200 Daniel Elstner <[EMAIL PROTECTED]> wrote: > Hi, > > On Mon, 30 Apr 2001 21:03:47 -0400 Chris Mason <[EMAIL PROTECTED]> wrote: > >> > Apparently it's a reiserfs/symlink problem. >> > I tried doing the lndir on an ext2 partition, sources still >> > on reiserfs. And it worked just fine! >> >> Neat, thanks for the extra details. Does that mean you can consistently >> repeat on reiserfs now? What happens when you do the lndir on reiserfs >> and diff the directories? > > I just played around a bit with the following results: > > sources on reiserfs, lndir on reiserfs -> make fails, diff ok > sources on reiserfs, lndir on ext2 -> make ok > sources on ext2, lndir on reiserfs -> make fails, diff ok > > Doing the diff against a second copy of the tree shows no errors, too. > Always the same behaviour: You have to run lndir at least twice to > get the error. If the link tree was already set up after a boot, the > error occurs only after rm + lndir + rm + lndir. > > There's a strange way to get things working just like after a reboot. > After diff'ing the link tree with the 2nd copy (both on reiserfs), > make World won't fail - at least once. Ok, can you reproduce with a set of sources other than X? I would leave glibc alone for now, unless you can reproduce on ext2. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: isa_read/write not available on ppc - solution suggestions ??
On Tue, 1 May 2001, Russell King wrote: > > In which case, can we change the following in IO-mapping.txt please? Oh, sorry. I misread your question. The _return_ value is a cookie. The first argument should basically be the start of a "struct pci_dev" resource entry, but obviously architecture-specific code can (and does) know what the thing means. And the ISA space (ie 0xA-0x10) has been considered an acceptable special case. So the only usage that is "portable" is to do something like cookie = ioremap(pdev->resource[0].start, pdev->resource[0].len); and I guess we should actually create some helper functions for that too. You can use ioremap in other ways, but there's nothing to say that they will work reliably across multiple PCI buses etc. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reiserfs+lndir problem [was: 2.4.4 SMP: spurious EOVERFLOW "Value too large for defined data type"]
Hi,
On Mon, 30 Apr 2001 21:03:47 -0400 Chris Mason <[EMAIL PROTECTED]> wrote:
> > Apparently it's a reiserfs/symlink problem.
> > I tried doing the lndir on an ext2 partition, sources still
> > on reiserfs. And it worked just fine!
>
> Neat, thanks for the extra details. Does that mean you can consistently
> repeat on reiserfs now? What happens when you do the lndir on reiserfs and
> diff the directories?
I just played around a bit with the following results:
sources on reiserfs, lndir on reiserfs -> make fails, diff ok
sources on reiserfs, lndir on ext2 -> make ok
sources on ext2, lndir on reiserfs -> make fails, diff ok
Doing the diff against a second copy of the tree shows no errors, too.
Always the same behaviour: You have to run lndir at least twice to
get the error. If the link tree was already set up after a boot, the
error occurs only after rm + lndir + rm + lndir.
There's a strange way to get things working just like after a reboot.
After diff'ing the link tree with the 2nd copy (both on reiserfs),
make World won't fail - at least once.
I also tried in the link tree:
find ! -type d -exec cat '{}' \; >/dev/null
And it seems to have the same effect as the diff.
> Any useful messages in /var/log/messages?
Nope, not any single message (except the usual ones).
The error on shutdown (when umounting /proc) appeared once again,
with the the same error message. Though I have no clue how that
could be related to reiserfs.
Two missed details: the reiserfs partion exists on a software
raid0 device. I configured glibc-2.2.3 with --enable-kernel=2.4.1.
Shall I try moving back to glibc-2.2.2 / configuring for lower kernel?
-- Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Breakage of opl3sax cards since 2.4.3 (at least)
OK, cutting to chase:
opl3sax cards have refused to init in Linux with the in-kernel OSS driver
since 2.4.3 at least (last I tested and worked was 2.4.1). I'm pretty sure
this is a kernel issue as it's happened on 2 different machines, one of
which I never goofed around with.
Usually message is something like:
opl3sa2: Control I/O port 0x220 (or whatever is tried) is not a YMF7xx
chipset!
I'm not sure why this occurs, but here is the code block where the error
probably occurs:
/* SNIP */
opl3sa2_read(hw_config->io_base, OPL3SA2_MISC, );
opl3sa2_write(hw_config->io_base, OPL3SA2_MISC, misc ^ 0x07);
opl3sa2_read(hw_config->io_base, OPL3SA2_MISC, );
if(tmp != misc) {
printk(KERN_ERR "opl3sa2: Control I/O port %#x is not a
YMF7xx chipset!\n",
hw_config->io_base);
return 0;
}
/*
* Check if the MIC register is accessible.
*/
opl3sa2_read(hw_config->io_base, OPL3SA2_MIC, );
opl3sa2_write(hw_config->io_base, OPL3SA2_MIC, 0x8a);
opl3sa2_read(hw_config->io_base, OPL3SA2_MIC, );
if((tmp & 0x9f) != 0x8a) {
printk(KERN_ERR
"opl3sa2: Control I/O port %#x is not a YMF7xx
chipset!\n",
hw_config->io_base);
return 0;
}
/* SNIP */
Maybe this is a dumb check because there's an anomaly with the OPL3SAx
chip. I don't know.
I'm not on the list, so please forward any mail sent about this to me.
David Bronaugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: * Re: Severe trashing in 2.4.4
Can't say for a definite fact that it was reiserfs but I can say for a definite fact that something fishy happens sometimes. If I have a text file open, something.html comes to mind, If I edit it and save it in one rxvt and open it in another rxvt, my changes may not be there. If I save it *again* or exit the editing process, I will see the changes in the second term. No, I'm not accidently forgetting to save it, I know for a fact that I saved it and the first terminal shows the non-modified state with the changes and the second term shows the previous data. Somewhere something is stuck in cache and what's on disk isn't what's in cache and a second process for some reason gets what is on disk and not what is in cache. It happens infrequently but it -does- happen. David Frank de Lange wrote: >Well, > >When a puzzled Alexey wondered whether the problems I was seeing with 2.4.4 >might be related to a failure to execute 'make clean' before compiling the >kernel, I replied in the negative as I *always* clean up before compiling >anything. Yet, for the sake of science and such I moved the kernel tree and >started from scratch. > >The problems I was seeing are no more, 2.4.4 behaves like a good kernel should. > >Was it me? Was it reiserfs? Was is divine intervention? I will probably never >find out, but for now this thread, and the accompanying scare, can Resquiam In >Paces. > >Cheers//Frank > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]
On Tue, May 01, 2001 at 05:35:12PM -0400, Olivier Galibert wrote: > On Tue, May 01, 2001 at 12:31:12PM -0400, Eric S. Raymond wrote: > > You are proposing an interface that will handle easy cases but blow > > up in the user's face in any hard one. That's poor design, frustrating > > the user exactly when he/she most needs help. > > Yeah, but what is the current method, vi? If you edit a .config (current or CML2'ed) and fix a problem, it works. What was the question again? (And, if you edit an old .config, %s/^# CONFIG/CONFIG and %s/ is not set/=n, oldconfig works like you would expect, and can help point out places where CML2 is slightly off). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Followup to previous post: Atlon/VIA Instabilities
> So it seems that CONFIG_X86_USE_3DNOW is simply used to
> enable access to the routines in mmx.c (the athlon-optimized
> routines on CONFIG_K7 kernels), so then it appears that somehow
> this is corrupting memory / not behaving as it should (very
> technical, right?) :)...
Do you use any unusual (binary only/with source) kernel modules?
mmx.c stores the current contents on the fpu registers into
current->thread.i387.f{,x}save.
If another module modifes the fpu registers and calls memmove it will
cause fpu corruptions.
I checked that a few months ago, and no module in the main kernel tree
does that.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: OnStream USB
On Tue, May 01, 2001 at 02:58:59PM -0400, Geoffrey Gallaway wrote: > I see that the SCSI version of the drive seems to be supported in linux > but I can only find tidbits of information that don't confirm or deny > this. Listed below are two sites that have some information which seem > to confirm that the drive does indeed work, but I simply want to be > sure. The README on the webpage has been updated finally. Compile usb-storage with Freecom support, load it and osst. Access the device via /dev/(n)osst0. Use a blocksize of 32k. (pipe over buffer -s 32k or use tar -b 64, see README.) Newer versions of osst overcome this block size limitation, but those have not yet been merged to the mainstream kernel. If you find trouble, please also report to [EMAIL PROTECTED] Enjoy! -- Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security PGP signature
Re: Maximum files per Directory
Followup to: <[EMAIL PROTECTED]> By author:Alan Cox <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > cyrus-imapd i ran into problems. > > At about 2^15 files the filesystem gave up, telling me that there cannot be > > more files in a directory. > > > > Is this a vfs-Issue or an ext2-issue? > > Bit of both. You exceeded the max link count, and your performance would have > been abominable too. cyrus should be using heirarchies of directories for > very large amounts of stuff. > But also showing, once again, that this particular scalability problem really is a headache for some people. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
* Re: Severe trashing in 2.4.4
Well,
When a puzzled Alexey wondered whether the problems I was seeing with 2.4.4
might be related to a failure to execute 'make clean' before compiling the
kernel, I replied in the negative as I *always* clean up before compiling
anything. Yet, for the sake of science and such I moved the kernel tree and
started from scratch.
The problems I was seeing are no more, 2.4.4 behaves like a good kernel should.
Was it me? Was it reiserfs? Was is divine intervention? I will probably never
find out, but for now this thread, and the accompanying scare, can Resquiam In
Paces.
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est." ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Requirement of make oldconfig [was: Re: [kbuild-devel] Re: CML2 1.3.1, aka ...]
On Tue, May 01, 2001 at 12:31:12PM -0400, Eric S. Raymond wrote: > You are proposing an interface that will handle easy cases but blow > up in the user's face in any hard one. That's poor design, frustrating > the user exactly when he/she most needs help. Yeah, but what is the current method, vi? OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: isa_read/write not available on ppc - solution suggestions ??
On Tue, May 01, 2001 at 02:19:33PM -0700, Linus Torvalds wrote:
> On Tue, 1 May 2001, Russell King wrote:
> > Talking around this issue, is there any chance of getting the
> > official use of the first parameter to ioremap documented in
> > Documentation/IO-mapping.txt please? There appears to be
> > confusion as to whether it is:
> >
> > a) PCI bus address
> > b) CPU untranslated address
>
> It's neither.
>
> It's a cookie that you can do arithmetic off and pass on to the
> readx/writex, and nothing more. You cannot make any assumptions at all
> about what it means.
>
> In particular, you can _not_ assume that it is a PCI bus address ("WHICH
> bus?") and you can absolutely not assume that it is a CPU address (many
> CPU's do not "memory map" PCI at all).
In which case, can we change the following in IO-mapping.txt please?
/*
* remap framebuffer PCI memory area at 0xFC00,
* size 1MB, so that we can access it: We can directly
* access only the 640k-1MB area, so anything else
* has to be remapped.
*/
char * baseptr = ioremap(0xFC00, 1024*1024);
since its not true? (since 0xfc00 is a cookie).
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Cluster using shared scsi
> reserved.But if you did such a hot swap you would have "bigger > fish to fry" in a HA application... I mean, none of your data would be > there! You need to realise this has happened and do the right thing. Since it could be an md raid array the hotswap is not fatal. If its fatal you need to realise promptly before you either damage the disk contents inserted in error (if possible) and so the HA system can take countermeasures > if the kernel (by this I mean the scsi midlayer) was maintaining > reservations, that there would be some logic activated to "handle" > this problem, whether it be re-reserving the device, or the ability to Suppose the cluster nodes don't agree on the reservation table ? > Bus resets in the Linux drivers also tend to happen frequently when a > disk is failing, which has tended to leave the system in a somewhat > functional but often an unusable state, (but that's a different story...) The new scsi EH code in 2.4 for the drivers that use it is a lot better. Real problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.4-ac3
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org 2.4.4-ac3 o Fix hang on boot with SMP (Andrea Arcangeli) | and fixes a few more uglies too o freevxfs module name was wrong (should be (me) freevxfs.o) o Update alloc_etherdev docs (Erik Mouw) o Remove dead funcs, put back ip_set_manually (David Miller, in the ipconfig code(Arnaldo Carvalho de Melo) o Fix SA_ONSTACK standards violation (for x86)(Christian Ehrhardt) | Other arch maintainers should check.. o Add another species of SB AWE 32(Bill Nottingham) o SE401 USB camera driver (Jeroen Vreeken) o Correct MAX_HD and make stuff static in ps2esdi (Hal Duston) o Fix inode-nr corruption (Al Viro) o Fix pgd_alloc for user mode linux (Jeff Dike) o Fix UML hostfs for get_hardsect_size(Jeff Dike) o Tidy up APM options setting, add module opts(Stephen Rothwell) o Fix acm open race (Oliver Neukum) o Further bounce buffer fixes (Arjan van de Ven) o ACPI updates(Andrew Grover) o Move pci_enable_device earlier on via audio (Arjan van de Ven) 2.4.4-ac2 o Remove some spurious whitespace differences (me) between trees o Make the VIA timer reload check test avoid (me) tripping on a timer as it rolls back to zero o Drop dasdfmt man page changes (dos ^M noise)(me) o Drop experimental iee1284 pnp module loading(me) o Revert pcnet32 chance causing compile errors(me) o Remove wrong __init in sunhme (Dave Miller) o Fix overlarge udely in aironet4500 (Arjan van de Ven) o Remove non existant parameter from aironet4500 (Keith Owens) o Kill duplicate aic7xxx include (Andrzej Krzysztofowicz) o Fix pci2220i scsi compile bug (Matt Domsch) o Fix module exception race on Alpha (Andrea Arcangeli) o Disable broken large vmalloc support on Alpha (Andrea Arcangeli) o Remove dead ia64 config entries (Steven Cole) o Add kbuild list info to MAINTAINERS (Steven Cole) o linux appletalk list has moved (Arnaldo Carvalho de Melo) o Revert wrong mount changes in 2.4.4 (Andries Brouwer) o Revert drivers/scsi/scsi.c change in 2.4.4 (me) that subtly broke about 15 drivers o Fix typo in slab.h (Pavel Machek) o More correct child favouring fork behaviour (Peter Österlund) o Only apply pci fixups if there is a VIA 686B(Charl Botha) o Fix GDT padding error introduced by PnPBIOS (Brian Gerst) support o Fix UML build without CONFIG_PT_PROXY (Jeff Dike) o dmfe wasnt calling dev_alloc_skb(Tobias Ringstrom) o Further Configure.help fixups (Steven Cole) o Move pci_enable_device earlier in trident (Marcus Meissner) 2.4.4-ac1 o Merge with Linus 2.4.4 | This wasnt entirely trivial so this is the only | stuff in this patch | The following stuff has been switched to the Linus branch | in the merge: uhci, dcache atomicity, raw I/O 2.4.3-ac14 o Merge read-only vxfs reading support(Christoph Hellwig) o Fix missing return in broken_apm_power (Alex Riesen) o Remove bogus rwsem hacks from usbdevice_fs.h(Alex Riesen) o Fix umount/sync_inodes race (Al Viro) o Make new xircom driver report when promisc used (Arjan van de Ven) o Fix acenic PCI flag set up (Phil Copeland) o Make nfs smart about passing max file sizes (Trond Myklebust) o Add initrd support to User Mode Linux (Jeff Dike) o Fix timer irq race in User Mode Linux (Jeff Dike) o Fix UML for semaphore changes (Jeff Dike) o Update thw W9966 parallel port camera driver(Jakob Kemi) o Further dmfe SMP fixups (Tobias Ringstrom) o Kernel manual pages in man9 (Tim Waugh) o Work around BIOSes that implement E801 sizing but don't implement the CX/DX values part (Michael Miller) o Fix atp driver build(Arjan van de Ven) o Fix irda poll handling (Dag Brattli) o Remove unused buggy pdc202xx code (Arjan van de Ven) o Clean up iphase ATM (Arnaldo Carvalho
Re: isa_read/write not available on ppc - solution suggestions ??
On Tue, 1 May 2001, Russell King wrote:
>
> Talking around this issue, is there any chance of getting the
> official use of the first parameter to ioremap documented in
> Documentation/IO-mapping.txt please? There appears to be
> confusion as to whether it is:
>
> a) PCI bus address
> b) CPU untranslated address
It's neither.
It's a cookie that you can do arithmetic off and pass on to the
readx/writex, and nothing more. You cannot make any assumptions at all
about what it means.
In particular, you can _not_ assume that it is a PCI bus address ("WHICH
bus?") and you can absolutely not assume that it is a CPU address (many
CPU's do not "memory map" PCI at all).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Maximum files per Directory
> cyrus-imapd i ran into problems. > At about 2^15 files the filesystem gave up, telling me that there cannot be > more files in a directory. > > Is this a vfs-Issue or an ext2-issue? Bit of both. You exceeded the max link count, and your performance would have been abominable too. cyrus should be using heirarchies of directories for very large amounts of stuff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Cluster using shared scsi
Alan Cox writes: > > Does this package also tell the kernel to "re-establish" a > > reservation for all devices after a bus reset, or at least inform a > > user level program? Finding out when there has been a bus reset has > > been a stumbling block for me. > > You cannot rely on a bus reset. Imagine hot swap disks on an FC fabric. I > suspect the controller itself needs to call back for problem events > I'm not an SCSI expert by any stretch of the imagination. I think that what you are saying is that you cannot rely that a bus reset is as only thing that will remove a reservation. For example, if a device is 'hot replaced', the device will (clearly) no longer be reserved.But if you did such a hot swap you would have "bigger fish to fry" in a HA application... I mean, none of your data would be there! My understanding is that specifically, when a bus reset occurs, all SCSI reservations for devices on that bus are lost. I was hoping that if the kernel (by this I mean the scsi midlayer) was maintaining reservations, that there would be some logic activated to "handle" this problem, whether it be re-reserving the device, or the ability to pass notification of a reset (or another problem event as you point out) up to the application that's handling reservations. In my experience, the most common reason for a bus reset in parallel SCSI is that a peer host on the bus is rebooting. Since this happens under normal operation and well in advance of any attempt to acess the device, it would be nice if there were some sort of asyncronous notification instead of a polling process with an interval of 2-3 minutes, where it's conceivable that the peer system could have booted and attempted to take-over the disk out from under a running system. Bus resets in the Linux drivers also tend to happen frequently when a disk is failing, which has tended to leave the system in a somewhat functional but often an unusable state, (but that's a different story...) James Bottomley <[EMAIL PROTECTED]> writes: > Essentially, there are many conditions which cause a quiet loss of a SCSI-2 > reservation. Even in parallel SCSI: Reservations can be silently lost because >of LUN reset, device reset or even simple powering off the device. ... James mentions that even handling a bus reset still leaves a window where a peer could grab the reservation out from underneath an un-suspecting host. I agree that this could happen, and the old host might perform writes to an 'unreserved' disk, but once the second system suceeded in obtaining the reservation, any read/write commands from the "old" host would return SCSI errors (this is my layman's understanding - the commands would return a UNIT_RESERVED error) , so I believe you would have the desired behavior in this kind of cluster - only one machine in the cluster can access the disk at the same time. The data on the disk should be in a state where the second system in the cluster could start a recovery task and begin to provide the service hosted on the disk. -Eric. -- Eric Z. Ayers Lead Software Engineer Phone: +1 404-705-2864Computer Generation, Incorporated Fax:+1 404-705-2805 an Intec Telecom Systems Company Web:http://www.intec-telecom-systems.com/ Email: [EMAIL PROTECTED] Postal: Bldg G 4th Floor, 5775 Peachtree-Dunwoody Rd, Atlanta, GA 30342 USA - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 endianness cleanup patch
Linus Torvalds wrote: > > On Tue, 1 May 2001, H. Peter Anvin wrote: > > > > Oh bother, you're right of course. We need some kind of standardized > > macro for indirecting through a potentially unaligned pointer. > > No we don't - because it already exists. > > It's called "get_unaligned()". > Well, we presumably do need it since it's there. I *did* correct this brain fault of mine a few hours ago. Note that it might still be an idea to have get_unaligned_le32() & co... on some machines le32_to_cpu(get_unaligned()) could potentially be a lot more painful than it needs to be. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Maximum files per Directory
Followup to: <27280.988750082@hades> By author:Andreas Rogge <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > While trying to create 100.000 (in words: one hundred thousand) Mailboxes > with > cyrus-imapd i ran into problems. > At about 2^15 files the filesystem gave up, telling me that there cannot be > more files in a directory. > > Is this a vfs-Issue or an ext2-issue? > Not correct, there can't be more than 2^15 *directories* in a single directory. I belive this is an ext2 limitation. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Meaning of major kernel version number
On Tuesday, 1. May 2001 22:49, Erik Hensema wrote: > Hi, > > A little question which may be a FAQ: what does the major version number > [1] of the Linux kernel (still) mean? What is the policy on increasing the > major version (eg. on what basis it is decided the next kernel isn't going > to be 2.6 but 3.0)? Our great fearless leader will talk with the penguin beyond the sky. HTH Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 endianness cleanup patch
On Tue, 1 May 2001, H. Peter Anvin wrote: > > Oh bother, you're right of course. We need some kind of standardized > macro for indirecting through a potentially unaligned pointer. No we don't - because it already exists. It's called "get_unaligned()". Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Cluster using shared scsi
[EMAIL PROTECTED] said: > Does this package also tell the kernel to "re-establish" a reservation > for all devices after a bus reset, or at least inform a user level > program? Finding out when there has been a bus reset has been a > stumbling block for me. [EMAIL PROTECTED] said: > You cannot rely on a bus reset. Imagine hot swap disks on an FC > fabric. I suspect the controller itself needs to call back for > problem events Essentially, there are many conditions which cause a quiet loss of a SCSI-2 reservation. Even in parallel SCSI: Reservations can be silently lost because of LUN reset, device reset or even simple powering off the device. The way we maintain reservations for LifeKeeper is to have a user level daemon ping the device with a reservation command every few minutes. If you get a RESERVATION_CONFLICT return you know that something else stole your reservation, otherwise you maintain it. There is a window in this scheme where the device may be accessible by other initiators but that's the price you pay for using SCSI-2 reservations instead of the more cluster friendly SCSI-3 ones. In a kernel scheme, you may get early notification of reservation loss by putting a hook into the processing of CHECK_CONDITION/UNIT_ATTENTION, but it won't close the window entirely. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Maximum files per Directory
While trying to create 100.000 (in words: one hundred thousand) Mailboxes with cyrus-imapd i ran into problems. At about 2^15 files the filesystem gave up, telling me that there cannot be more files in a directory. Is this a vfs-Issue or an ext2-issue? Andreas Rogge <[EMAIL PROTECTED]> Available on IRCnet:#linux.de as Dyson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Meaning of major kernel version number
Hi, A little question which may be a FAQ: what does the major version number [1] of the Linux kernel (still) mean? What is the policy on increasing the major version (eg. on what basis it is decided the next kernel isn't going to be 2.6 but 3.0)? I'm asking this question because I think there isn't going to be a kernel which is as different from the previous one as 2.0 compared to 1.2. As a little reminder: 2.0 brought us SMP, modules, multi-platform support (did 1.2 support Alpha? I don't remember), quota support, MD support, loop device, to name a few. If this is true, may have to rethink the current versioning scheme, or we'll stick to 2.x.y forever... -- Erik Hensema ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DPT I2O RAID and Linux I2O
> Is this I2O implementation supporting PCI devices ? Yes > Yesterday I post something about that, I have a CompactPCI computer with 2 > computers in it. One master and one slave. The slave one, is has a non > transparent pci-to-pci bridge : DEC (INTEL) 21554, wich support I2O > messaging, I want both computer to communicate by this mean, but I cant seam I2O messaging and I2O protocol are two things. Most sane vendors use I2O messaging hardware to implement something that looks a little more like a device control protocol than SNA. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: iso9660 endianness cleanup patch
> Oh bother, you're right of course. We need some kind of standardized > macro for indirecting through a potentially unaligned pointer. It can get_unaligned() - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.4 sluggish under fork load
> OK I found the explanation now. The reason ksoftirqd was deadlocking on > me without the explicit clear of SCHED_YIELD in p->policy is because a > softirq event was pending at the time of the first kernel_thread() and > then while returning from the syscall it was so taking the ret_from_irq Oh boy. > > + current->policy |= SCHED_YIELD; > > + current->need_resched = 1; > > + } > > Alan, the patch you merged in 2.4.4ac2 can fail like mine, but it may fail in > a much more subtle way, while I notice if ksoftirqd never get scheduled > because I synchronize on it and I deadlock, your kupdate/bdflush/kswapd > may be forked off correctly but they can all have SCHED_YIELD set and > they will *never* get scheduled. You know what can happen if kupdate > never gets scheduled... I recommend to be careful with 2.4.4ac2. Change merged for -ac3. Nice debugging - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Cluster using shared scsi
> Does this package also tell the kernel to "re-establish" a > reservation for all devices after a bus reset, or at least inform a > user level program? Finding out when there has been a bus reset has > been a stumbling block for me. You cannot rely on a bus reset. Imagine hot swap disks on an FC fabric. I suspect the controller itself needs to call back for problem events - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] adding PCI bus information to SCSI layer
> I'm wary of this, because Linus has stated that the current "struct
> pci_dev" is really meant to be a generic thing, and it might change to
> "struct dev" (now that we've renamed the old "struct dev" to "struct
> netdev").
It is already being (ab)used this way. Its an isa pnp device in 2.4.*. Its
also a bios pnp device in 2.4-ac
> However, it's my understanding that Linus isn't trying to push
> existing drivers, which work well with devfs, into implementing their
> own FS. He just wants the option left open for new drivers where a
> driver-specific FS makes more sense.
Having thought over the issues I plan to maintain a 32bit dev_t kernel with
conventional mknod behaviour, even if Linus won't. One very interesting item
that Peter Anvin noted is that its not clear in POSIX that
mknod /dev/ttyF00 c 100 100
open("/dev/ttyF00/speed=9600,clocal");
is illegal. That may be a nice way to get much of the desired behaviour without
totally breaking compatibility
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Still hudge sound problem on 2.4.4-ac2
Hello, I don't know what have changed since 2.4.4-pre6 or 2.4.3-ac13 which are the last kernel I had tested before 2.4.4 which introduced that sound problem... I have a sound card, but I don't load the modules for it: I just use my DVB-s card from Hauppauge to watch TV or playing DVD. It seems that's watching TV works, but I haven't tested it more than 20 minutes long, but when playing a DVD, in the best case, one could hear a good sound during ten minutes, and then there is so much noise that one could not hear anything at all? What could I say more? Maybe lspci: 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 02) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 02) 00:04.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:04.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:04.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:04.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:06.0 SCSI storage controller: Adaptec AHA-2940U2/W / 7890 00:07.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 05) 00:0a.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02) 00:0a.1 Multimedia controller: Brooktree Corporation Bt878 (rev 02) 00:0b.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) 00:0c.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 06) 00:0c.1 Input device controller: Creative Labs SB Live! (rev 06) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) And gcc -v: Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.96/specs gcc version 2.96 2731 (Linux-Mandrake 8.0 2.96-0.49mdk) Greg http://ulima.unil.ch/greg ICQ:16624071 mailto:[EMAIL PROTECTED] PGP signature
Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability
> And that's exactly what I did :)... I found that ONLY the combination > of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in > results in this wackiness. I should alos repeat that I *DO* see that I doubt that USE_3DNOW is causing the problem, but rather when you USE_3DNOW, the kernel streams through your northbridge at roughly twice the bandwidth. if your dram settings are flakey, this could eaily trigger a problem. this has nothing to do with the very specific disk corruption being discussed (which has to do with the ide controller, according to the most recent rumors.). > The other thing i was gunna try is to dump my chipset registers using > WPCREDIT and WPCRSET and compare them with other people on this list why resort to silly windows tools, when lspci under Linux does it for you? regards, mark hahn. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OnStream USB
I'm the owner of that first URL. The driver works for me. Make sure you enable the "Freecom USB/ATAPI" support under the USB Mass Storage option in the kernel configuration. Note that this is only supported for 2.4.x series kernels. Matt On Tue, May 01, 2001 at 02:58:59PM -0400, Geoffrey Gallaway wrote: > Hello, > > I am considering getting an OnStream USB tape backup drive. I want the > USB version because I have about 4 machines all on different networks > that need to be backed up. Using USB would allow me to move the unit > from one machine to another without rebooting the machine. > > I see that the SCSI version of the drive seems to be supported in linux > but I can only find tidbits of information that don't confirm or deny > this. Listed below are two sites that have some information which seem > to confirm that the drive does indeed work, but I simply want to be > sure. > > http://www2.one-eyed-alien.net/~mdharm/linux-usb/ > http://linux1.onstream.nl/test/ > > Thank you, > Geoff > > -- > Geoffrey Gallaway || > [EMAIL PROTECTED] || Clones are people two. > D e v o r z h u n || > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver It was a new hope. -- Dust Puppy User Friendly, 12/25/1998 PGP signature
Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Hi :) And that's exactly what I did :)... I found that ONLY the combination of USE_3DNOW and forcing the athlon mmx stuff in (by doing #if 1 in mmx.c) results in this wackiness. I should alos repeat that I *DO* see that wierdness you described with 3DNOW (in my case, it was that kde locks up when i try to do something). This is damn weird... Who thought channging motherboards would result in this? The other thing i was gunna try is to dump my chipset registers using WPCREDIT and WPCRSET and compare them with other people on this list who have been having the problem. Maybe our BIOS'es are not initting/are initting something they should/should not be :). It this point, I haven't ruled anything out... --Seth Lawrence Gold wrote: > > Hi, Seth, > > Just wanted to let you know that I got similar results to yours with my > Epox 8KTA3 motherboard + Thunderbird. (If you've already seen the thread > on the kernel mailing list, then please ignore this. ;) > > If I leave the 3DNOW stuff enabled in arch/i386/config.in, but disable the > K7-specific MMX optimizations, then the system doesn't panic on startup or > oops continually, but I do get odd behavior, such as awk breaking. > > If I disable just the 3DNOW stuff, then everything works really smoothly. > I was planning on disabling one-by-one the parts of the code which use > 3DNOW optimizations to see if there's a particular one that brings about > instability. > > I'll be sure to cc you on anything I find... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: isa_read/write not available on ppc - solution suggestions ??
On Tue, May 01, 2001 at 10:22:39AM -0700, Linus Torvalds wrote: > I bet that the patch will be smaller too. It's a simple case of > - do the ioremap() _once_ at bootup, save the result in a static >variable somewhere. > - implement the (one-liner) isa_readx/isa_writex functions. > > On many architectures you don't even need to do the ioremap, as it's > always available (same as on x86). Talking around this issue, is there any chance of getting the official use of the first parameter to ioremap documented in Documentation/IO-mapping.txt please? There appears to be confusion as to whether it is: a) PCI bus address b) CPU untranslated address Currently, IO-mapping.txt seems to imply (a), but I believe that a lot of people on lkml will disagree with that. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Dan Hollis wrote: > > On Tue, 1 May 2001, Seth Goldberg wrote: > > I Should clarify that this is the KX133A chipset. > > No such thing. Surely you mean KT133A. No X. > Surely :)... That's what sleep deprivation does to you ;). --S - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Test. Please ignore.
Wow. My very first pseudo-flame. Thank you for making me feel welcome ;). --S Jesper Juhl wrote: > > Seth Goldberg wrote: > > > Test. > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ > > Let me quote from the linux-kernel FAQ section 3-14 ( > http://www.tux.org/lkml/#s3-14 ) : > > 14.I am not getting any mail anymore from the list! Is it down or what? > ... > Don't post "Just testing: Is the list working? > ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bandwidth
On Tue, May 01, 2001 at 05:53:12PM +0200, J . A . Magallon wrote: > What you have todo is to learn how to configure your mailer to display > headers you want. elm and balsa can do it. Do not know about Outlook... > (btw, it is curious, mailing to lkml with outlook...) Outlook express is different from outlook. Outlook doesn't let you look at the mail headers. Outlook express doesn't, but doesn't display them by default (iirc, you need to look at the message properties). PS, you can't remove Received: headers at source - they are added by each hop on the mails journey across the Internet. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability
On Tue, 1 May 2001, Seth Goldberg wrote: > I Should clarify that this is the KX133A chipset. No such thing. Surely you mean KT133A. No X. -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Dead keys
* At 2001-05-01T21:20+0200, [EMAIL PROTECTED] wrote: : | I think the main reason why it shouldn't be applied is that it changes | something. This keyboard stuff is unbelievably complicated. Many people | and distributions have wrestled with it and have got it working for them. | When you change stuff, you force people to start worrying about this again. | | [In other words, a global rewrite may be allowed, but non-compatible changes | in a few details only is really a bad idea.] Won't comment on this argument, it might outweigh my point (but that's not for me to say). | But there are other reasons why your patch is a bad idea. Everybody has | a double quote in his keymap, so using that to create umlauts is easy. | Only few people have a diaeresis in their keymap, so requiring a diaeresis | makes life more difficult for most people. It doesn't require anyone to use the ISO characters. The defkeymap.map still contains compose rules for the ASCII sequences. | (In other words, composing ASCII to make ISO 8859-1 is better than composing | ISO 8859-1 to make ISO 8859-1.) This is just a matter of adding compose rules. The issue here is that the dead keys themselves are producing the wrong characters. | Finally, you have loadkeys. If you change your private keymap | you achieve what you desire for yourself without disturbing others. No, this doesn't seem to be the case, unless I've missed something important. Because the dead_* are wrong, and I can't change them with a keymap, afaik? If I'm wrong, shoot me, then the patch is pointless. -- Stian Sletner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: isa_read/write not available on ppc - solution suggestions ??
Em Tue, May 01, 2001 at 09:52:30AM -0400, [EMAIL PROTECTED] escreveu: > Personally I'd rather not have arch dependent macros in the driver, but I > know there is a good reason why the isa_read/write functions were > introduced in the first place. I did that because I was lazy to use ioremap in my driver, but I found time and fixed it properly eventually, too late, lots of other drivers started using it, now its in the janitor's TODO list to get rid of that and use ioremap, then we'll be able to get rid of that hack 8) - Arnaldo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Dead keys
From [EMAIL PROTECTED] Tue May 1 20:05:26 2001 Normally, you wouldn't notice this too much, since the compose rules are set up in such a way that you can use the dead keys to compose what you would expect, anyway. However, if you were to press a dead key and then space, or some un-composable key (to get the dead key character by itself), you would get the wrong character. Instead of '¨' (ISO 8859-1 decimal 168: DIAERESIS), you would get '"' (ASCII decimal 34); instead of '´' (ISO 8859-1 decimal 180: ACUTE ACCENT), you would get '\'' (ASCII decimal 39); and instead of '¸' (ISO 8859-1 decimal 184: CEDILLA), you would get ',' (ASCII decimal 44). I took the liberty of creating a patch that changes this in keyboard.c, and also adds compose rules to defkeymap.map so they can be used properly. If there is some reason why this shouldn't be applied, I'd like to know what, since this makes my console life easier. :) I think the main reason why it shouldn't be applied is that it changes something. This keyboard stuff is unbelievably complicated. Many people and distributions have wrestled with it and have got it working for them. When you change stuff, you force people to start worrying about this again. [In other words, a global rewrite may be allowed, but non-compatible changes in a few details only is really a bad idea.] But there are other reasons why your patch is a bad idea. Everybody has a double quote in his keymap, so using that to create umlauts is easy. Only few people have a diaeresis in their keymap, so requiring a diaeresis makes life more difficult for most people. (In other words, composing ASCII to make ISO 8859-1 is better than composing ISO 8859-1 to make ISO 8859-1.) Finally, you have loadkeys. If you change your private keymap you achieve what you desire for yourself without disturbing others. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Linux 2.4.4-ac2
> + * Make sure the child gets the SCHED_YIELD flag cleared, even if > + * it inherited it, to avoid deadlocks. can anyone think of a reason that SCHED_YIELD *should* be inherited? I think it's just oversight that fork doesn't clear it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OnStream USB
Hello, I am considering getting an OnStream USB tape backup drive. I want the USB version because I have about 4 machines all on different networks that need to be backed up. Using USB would allow me to move the unit from one machine to another without rebooting the machine. I see that the SCSI version of the drive seems to be supported in linux but I can only find tidbits of information that don't confirm or deny this. Listed below are two sites that have some information which seem to confirm that the drive does indeed work, but I simply want to be sure. http://www2.one-eyed-alien.net/~mdharm/linux-usb/ http://linux1.onstream.nl/test/ Thank you, Geoff -- Geoffrey Gallaway || [EMAIL PROTECTED] || Clones are people two. D e v o r z h u n || - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] strtok -> strsep (The Easy Cases)
Hello,
the patch at the bottom does the bulk job of strtok replacement. It's a
very boring patch, containing easy cases, only. It became a bit big, too,
but I trust you can digest it nevertheless. It's made against kernel
version 2.4.4.
What is the benefit of getting rid of strtok? It is for cutting strings
into pieces and it's used in argument parsing code of most file
systems and framebuffers. The problem is: strtok is not reentrant and its
manpage tells you to stop using it. There is a replacement function:
strsep. strsep has the added benefit of returning empty tokens, too. We
don't need strtok, it's a bug - do you need any more reasons for replacing
it? In the longer run I want the kernel to be completely cleaned from
strtok - expect more patches to come.
Please apply this patch to the official version of the kernel.
René
diff -ur linux-2.4.4/arch/m68k/atari/config.c linux-2.4.4-rs/arch/m68k/atari/config.c
--- linux-2.4.4/arch/m68k/atari/config.cTue Nov 28 02:57:34 2000
+++ linux-2.4.4-rs/arch/m68k/atari/config.c Tue May 1 17:03:46 2001
@@ -206,13 +206,15 @@
char *p;
int ovsc_shift;
-/* copy string to local array, strtok works destructively... */
+/* copy string to local array, strsep works destructively... */
strncpy( switches, str, len );
switches[len] = 0;
atari_switches = 0;
/* parse the options */
-for( p = strtok( switches, "," ); p; p = strtok( NULL, "," ) ) {
+while( p = strsep( , "," ) ) {
+ if (!*p)
+ continue;
ovsc_shift = 0;
if (strncmp( p, "ov_", 3 ) == 0) {
p += 3;
diff -ur linux-2.4.4/drivers/scsi/ibmmca.c linux-2.4.4-rs/drivers/scsi/ibmmca.c
--- linux-2.4.4/drivers/scsi/ibmmca.c Sat Mar 3 03:38:38 2001
+++ linux-2.4.4-rs/drivers/scsi/ibmmca.cTue May 1 17:48:14 2001
@@ -1406,9 +1406,9 @@
io_base = 0;
id_base = 0;
if (str) {
- token = strtok(str,",");
j = 0;
- while (token) {
+ while (token = strsep(,",")) {
+if (!*token) continue;
if (!strcmp(token,"activity")) display_mode |= LED_ACTIVITY;
if (!strcmp(token,"display")) display_mode |= LED_DISP;
if (!strcmp(token,"adisplay")) display_mode |= LED_ADISP;
@@ -1424,7 +1424,6 @@
scsi_id[id_base++] = simple_strtoul(token,NULL,0);
j++;
}
-token = strtok(NULL,",");
}
} else if (ints) {
for (i = 0; i < IM_MAX_HOSTS && 2*i+2 < ints[0]; i++) {
diff -ur linux-2.4.4/drivers/video/acornfb.c linux-2.4.4-rs/drivers/video/acornfb.c
--- linux-2.4.4/drivers/video/acornfb.c Sat Apr 28 12:23:20 2001
+++ linux-2.4.4-rs/drivers/video/acornfb.c Tue May 1 17:03:46 2001
@@ -1527,7 +1527,7 @@
acornfb_init_fbinfo();
- for (opt = strtok(options, ","); opt; opt = strtok(NULL, ",")) {
+ while (opt = strsep(, ",")) {
if (!*opt)
continue;
diff -ur linux-2.4.4/drivers/video/amifb.c linux-2.4.4-rs/drivers/video/amifb.c
--- linux-2.4.4/drivers/video/amifb.c Sat Apr 28 12:23:20 2001
+++ linux-2.4.4-rs/drivers/video/amifb.cTue May 1 17:03:46 2001
@@ -1195,7 +1195,9 @@
if (!options || !*options)
return 0;
- for (this_opt = strtok(options, ","); this_opt; this_opt = strtok(NULL, ",")) {
+ while (this_opt = strsep(, ",")) {
+ if (!*this_opt)
+ continue;
if (!strcmp(this_opt, "inverse")) {
amifb_inverse = 1;
fb_invert_cmaps();
diff -ur linux-2.4.4/drivers/video/atafb.c linux-2.4.4-rs/drivers/video/atafb.c
--- linux-2.4.4/drivers/video/atafb.c Sat Apr 28 12:23:20 2001
+++ linux-2.4.4-rs/drivers/video/atafb.cTue May 1 17:03:46 2001
@@ -2899,7 +2899,7 @@
if (!options || !*options)
return 0;
-for(this_opt=strtok(options,","); this_opt; this_opt=strtok(NULL,",")) {
+while (this_opt = strsep(, ",")) {
if (!*this_opt) continue;
if ((temp=get_video_mode(this_opt)))
default_par=temp;
diff -ur linux-2.4.4/drivers/video/aty128fb.c linux-2.4.4-rs/drivers/video/aty128fb.c
--- linux-2.4.4/drivers/video/aty128fb.cFri Feb 9 20:30:23 2001
+++ linux-2.4.4-rs/drivers/video/aty128fb.c Tue May 1 17:03:46 2001
@@ -1614,8 +1614,9 @@
if (!options || !*options)
return 0;
-for (this_opt = strtok(options, ","); this_opt;
-this_opt = strtok(NULL, ",")) {
+while (this_opt = strsep(, ",")) {
+ if (!*this_opt)
+ continue;
if (!strncmp(this_opt, "font:", 5)) {
char *p;
int i;
diff -ur linux-2.4.4/drivers/video/atyfb.c linux-2.4.4-rs/drivers/video/atyfb.c
--- linux-2.4.4/drivers/video/atyfb.c Sat Apr 28 12:23:20 2001
+++ linux-2.4.4-rs/drivers/video/atyfb.cTue May 1 17:03:46 2001
@@ -4062,8 +4062,9 @@
if (!options || !*options)
return 0;
Re: DISCOVERED! Cause of Athlon/VIA KX133 Instability
Will Newton wrote: I Should clarify that this is the KX133A chipset. In any event, there are a bunch of people having this problem (check out the list archives). I just upgraded to this IWILL board from an Abit KA7-RAID (which worked with no problem), so I'm just trying tofgure it out :) -Seth > > > is exhibiting weird behavior under K7 optimizations. The jist of my > > research is that compiling a kernel for ANY CPU with the Athlon MMX > > optimization > > *AND* 3DNOW results in massive amounts of oops'es and total system > > instability. The following is what I've tried: > > With: > > Athlon 700 > Asus K7V (KX133 based) > > I have been running Athlon based kernels for months, no problems (well, > none like you mention). > > gcc 2.96-81 BTW > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: Linux 2.4.4-ac2
On 05.01 Hugh Dickins wrote: > On Tue, 1 May 2001, J . A . Magallon wrote: > > > > > > OK works here ... > > > > Me too. > > > > Perhaps this reschedules ok in UP but kinda fails in SMP... > > Great. And see Andrea's SCHED_YIELD explanation in the "sluggish" > mail thread. Well, I didn't try to understand it in full, and I > think he was expecting another thread to hang, rather than the main > startup itself; but no doubt deeper thought would make sense of it all. > I saw it. Minimal change to make 2.4.4-ac2 work: == patch-fork-yield --- linux/kernel/fork.c.origTue May 1 20:03:12 2001 +++ linux/kernel/fork.c Tue May 1 20:52:18 2001 @@ -677,8 +677,11 @@ * few simple things and then exec(). This is only important in the * first timeslice. In the long run, the scheduling behavior is * unchanged. +* Make sure the child gets the SCHED_YIELD flag cleared, even if +* it inherited it, to avoid deadlocks. */ p->counter = (current->counter + 1) >> 1; + p->policy &= ~SCHED_YIELD; current->counter >>= 1; current->policy |= SCHED_YIELD; current->need_resched = 1; Is this enough (Andrea?) or just "works for me" ?. -- J.A. Magallon # Let the source mailto:[EMAIL PROTECTED] # be with you, Luke... Linux werewolf 2.4.4-ac1 #1 SMP Tue May 1 11:35:17 CEST 2001 i686 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
