Crusoe math performance?
So I am fooling around with one of these things: processor : 0 vendor_id : GenuineTMx86 cpu family : 5 model : 4 model name : Transmeta(tm) Crusoe(tm) Processor TM5600 stepping: 3 cpu MHz : 533.348 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr cx8 cmov mmx longrun bogomips: 1032.19 Anyone have any idea of FPU performance? I mean, compared to a Celeron or Pentium in an application running an SSL web server would I expect 80%, 100%, 10%, 110% of the throughput of a Intel chip of the same clock speed? Just thought this thing might be a good alternative to a Pentium SSL server "furnace" and am looking for any comments from anyone that might have tested it. If I don't hear anything, I will post the numbers we come up with when we get around to benchmarking them. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 ...]
Eric> Giacomo Catenazzi <[EMAIL PROTECTED]>: >> No. You propmt only one invalid assertion. After you this prompt >> you continue to validate rules and you will maybe prompt for another >> invalid rules. But these invalid rules are generally infrequent. Eric> I may be having problems with your English. I don't think I Eric> understand this. He's saying that when you find the first invalid assertion, such as not having CONFIG_RTC defined, when reading the .config file, you should prompt for a fix. Then once the input is taken, continue your checks, prompting for each following problem as needed. >> It is very unlikely to have constraint on string or on integer. But >> anyway, where is the problem? You simple ask the new value of this >> symbol. Eric> The problem is that you're now, in effect, telling me to invent Eric> a new interactive configurator with different rules than the Eric> normal one! Eric> This is a horrible swamp to wander into just to avoid making oldconfig Eric> users fire up vi occasionally. No, we're just asking you to make the CML2 parser more tolerant of old and possibly broken configs. I haven't looked at the parser in any detail, but I assume that there are heirarchal configuration settings. When there is a mis-match, where a sub-option conflicts with an upper option, how hard would it be to print a warning, and just reset the sub-option to an acceptable state? Going back to the original CONFIG_RTC bug report I filed, all I had to do was fire up vi and edit the .config file to turn on CONFIG_RTC, which I think is completely bogus. CML2 should be able to say "Hey, you need RTC turned on since you've got SMP on, but it's not. Should I do this for you? Yes/No" For trully broken .configs, maybe it makes sense to just give up and say "Hey! This .config is totally bogus, can I just ignore it and have you redo your config in a sane manner?" Make the computer do the work, not the user. John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Compaq Hotplug PCI driver for 2.4.4
Just to let linux-kernel know: I'm working on the Compaq Hotplug PCI driver. The latest version should work with most Intel motherboards that support Hotplug PCI. The patch is currently available against 2.4.4 at: http://www.kroah.com/linux/hotplug/ Many thanks to Dely Sy at Intel for his help in getting the driver working on my motherboard. There is much more to be done to the driver before it can be included in the kernel tree, but if anyone wants to try it out, please do. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Swap space deallocation speed.
Ever since I've upgraded to the 2.2.17-14 i386 kernel as provided by RedHat, I've had several hard crashes. One allowed "/var/log/messages" to be synced, so I was able to capture those details (which are attached to this message as the file "crash.log"). Once, instead of crashing, the system stayed up but all of the respawn processes in "/etc/inittab" began to respawn to rapidly, I couldn't create a shell process to poke around, and the keyboard eventually became unresponsive. The relevant line in the log, as you can find in the attached "crash.log" file, appears to be: Unable to handle kernel paging request at virtual address 00020024 My guess is that, for whatever reason, I may now be running out of swap space fairly often. If this is true, then either my children have altered their usage habits around the same time that I upgraded the kernel, or something about swap space management has changed between the 2.2.16-3 and 2.2.17-14 kernels. To this end, I've asked my children to be careful about not opening too many windows at the same time, and the system now stays up longer but still, on occasion, without requesting my permission, still goes down hard. I've also been watching the amount of available swap space with the "free" command. It predictably goes down quite quickly when a hog like netscape is started, but, when that same application exits, the available swap space goes back up very slowly. This would seem to make it very easy to inadvertently run out of swap space, i.e. quitting and restarting an application still, without the user realizing it, appears to be a bad thing to do because of the as yet unreclaimed swap space which is still being counted. Do any of you have any ideas? If I'm right about the slow reclamation of the swap space, is there anything I can do, e.g. alter something in "/proc", to speed up swap space reclamation? Thanks. -- Dave Mielke | 2213 Fox Crescent | I believe that the Bible is the Phone: 1-613-726-0014 | Ottawa, Ontario | Word of God. Please contact me EMail: [EMAIL PROTECTED] | Canada K2A 1H7 | if you're concerned about Hell. Apr 16 11:23:06 dave kernel: Unable to handle kernel paging request at virtual address 00020024 Apr 16 11:23:06 dave kernel: current->tss.cr3 = 00101000, %%cr3 = 00101000 Apr 16 11:23:06 dave kernel: *pde = Apr 16 11:23:06 dave kernel: Oops: Apr 16 11:23:06 dave kernel: CPU:0 Apr 16 11:23:06 dave kernel: EIP:0010:[locks_remove_posix+43/140] Apr 16 11:23:06 dave kernel: EFLAGS: 00010206 Apr 16 11:23:06 dave kernel: eax: c3e6a6d0 ebx: c03e5c70 ecx: c3e6a660 edx: c03e5c70 Apr 16 11:23:06 dave kernel: esi: 0002 edi: c14ff5d0 ebp: c3e6a6d0 esp: c142ff30 Apr 16 11:23:06 dave kernel: ds: 0018 es: 0018 ss: 0018 Apr 16 11:23:06 dave kernel: Process ppp-watch (pid: 7528, process nr: 81, stackpage=c142f000) Apr 16 11:23:06 dave kernel: Stack: c14ff5d0 0001 c3e6a6d0 c3e6a660 0001 c011c9a1 0019 0032 Apr 16 11:23:06 dave kernel:c011ca40 bfffc000 c15147c0 0286 c15147c0 1d00 001d Apr 16 11:23:06 dave kernel:bd68 c151483c 1d00 c012768a c03e5c70 c203a280 00100047 0001 Apr 16 11:23:06 dave kernel: Call Trace: [check_pgt_cache+17/24] [clear_page_tables+152/160] [filp_close+70/88] [do_exit+293/624] [sys_exit+14/16] [system_call+52/56] Apr 16 11:23:06 dave kernel: Code: f6 46 24 01 74 49 8b 4c 24 5c 39 4e 14 75 40 8b 4c 24 58 8b
Re: PROBLEM: 2.4.4 oops, will not boot
On Wed, May 02, 2001 at 09:51:39PM +1000, Andrew Morton wrote: > Envelope-to: gbsadler@localhost > From: Andrew Morton <[EMAIL PROTECTED]> > X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-ac13 i686) > To: Gordon Sadler <[EMAIL PROTECTED]> > Subject: Re: PROBLEM: 2.4.4 oops, will not boot > > Gordon Sadler wrote: > > > > Please CC on replies. > > Attached is REPORTING-BUGS template from source, and a hand copied oops > > that I ran through ksymoops. I really hope this is resolved, anything > > further needed, just ask. > > Unfortunately the ksymoops output doesn't show the call trace. > Can you please try again? A reproducable oops is, err, rather > important. The syntax to feed into ksymoops is > > Call Trace: [] [] ... > > Thanks. > Right, I see the problem now.. s/Calltrace/Call Trace/ Reran oops through ksymoops with change to Call Trace, output attached. ksymoops 2.4.1 on i686 2.2.19. Options used -V (default) -K (specified) -L (specified) -o /lib/modules/2.4.4/ (specified) -m /boot/System.map-2.4.4 (specified) No modules in ksyms, skipping objects Unable to handle kernel NULL pointer dereference at virtual address 0014 printing EIP: c01254b5 *pde = Oops: CPU: 0 EIP: 0010: [] Using defaults from ksymoops -t elf32-i386 -a i386 eflags: 00010013 eax: c1227e08 ebx: c1227e08 ecx: c7e3ff68 edx: esi: 0286 edi: 0007 ebp: c12343c0 esp: c7e3feec ds: 0018es: 0018 ss: 0018 stack: c1263080 c12630dc c013ec88 c1277e08 0007 c1263080 c12630dc c12343c0 0005 c01370c8 c12343c0 c7e3ff68 c7e3ff68 c12343c0 c7e3ffa4 c0137819 c12343c0 c7e3ff68 c1265000 Call Trace: [] [] [] [] [] [] [] Code: 8b 42 14 ff 42 10 89 c1 0f af 4b 0c 03 4a 0c 8b 44 82 18 89 >>EIP; c01254b5<= Trace; c013ec88 Trace; c01370c8 Trace; c0137819 Trace; c0136e4a Trace; c0137e3c <__user_walk+3c/60> Trace; c0134f36 Trace; c0106b9b Code; c01254b5 <_EIP>: Code; c01254b5<= 0: 8b 42 14 mov0x14(%edx),%eax <= Code; c01254b8 3: ff 42 10 incl 0x10(%edx) Code; c01254bb 6: 89 c1 mov%eax,%ecx Code; c01254bd 8: 0f af 4b 0c imul 0xc(%ebx),%ecx Code; c01254c1 c: 03 4a 0c add0xc(%edx),%ecx Code; c01254c4 f: 8b 44 82 18 mov0x18(%edx,%eax,4),%eax Code; c01254c8 13: 89 00 mov%eax,(%eax)
Re: [OT] Re: Linux NAT questions- (kernel upgrade??)
"Sim, CT (Chee Tong)" schrieb: > I am using the Red Hat 7, below are my kernel version. I feel Red Hat 7 is > quite new, although RH 7.1 has just come out. How come it still say that my > kernel version is old. Ah, by old is meant the 2.2 version - 7.1 is the first RH release to ship with kernel 2.4. You can certainly run a 2.4 kernel on your 7.0 box - I only ran 2.2.16 on my RH 7.0 boxes for as long as it tool me to pull down the kernel sources and compile a 2.4 kernel. cu jjs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: X15 alpha release: as fast as TUX but in user space
Our intention is to release X15 with an open source license. This will happen as soon as the codebase stabilizes a bit, that is when we go beta (in two - three weeks). At the moment we just don't have the time... The reason why I released the alpha binary version is that several people would not believe that a user-space server with this level of performance would be possible at all and several statements that I made on this list were challenged. Besides I really appreciate the feedback that I received so far from Ingo and others, and I'd be very curious to know if anybody did any performance evaluation at all. - Fabio Zach Brown wrote: > I've always been tempted to go back and take a real swing at a > nice content server, but there's only so many hours in the day, and > apache+thttpd+tux complete the problem space. If X15 isn't released > with an open license, I may be tempted yet 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/
memory and current macro
Hi, I've been trying to write a device driver and I've found two problems. First, the current macro. I wanted to get the uid of the calling process but "current->uid" does NOT work it returns some other number. Same with "current->pid" and many others. I figured these numbers weren't random and decided to print out a particular processes's descriptor and check out what was going on. I found that "&(current->uid)" is 0x1d lower than the address that holds the user id. In addition, adding 0x1d to that address added it twice??? So to get the uid I ended up adding half...or "&(current->uid) + 0x0f". Does anyone know why this is? I have an i686 processor, IBM thinkpad 570e laptop, Debian 2.2, kernel version 2.4.2. Second problem might not have anything to do with my device driver at all. It seems that applications on my laptop know longer free memory they have allocated. I thought it was my module. I check "free" for the memory available, "insmod" my module, check "free" again, "rmmod" it. Each time the amount of free memory goes down. Even when I remove the module. Then I found that all other processes do this also, from ftp to ls or cd. Then I start getting really bad segmentation errors in almost every process I try to run. And at the top, they say, usually, "kernel BUG page_alloc.c line:xx". I'm worried I've corrupted something or I don't know. I looked this up in the source but I don't know why everything is triggering it. Are there any known memory allocation or freeing problems with kernel 2.4.2? - Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 syscall speed -- was X15 rootin-tootin webserver
According to tests performed at IBM: http://www-106.ibm.com/developerworks/linux/library/l-rt1/ Linux's sycalls are a little more than twice as fast as those of Windows 2000. 0.75usec vs 2.0msec. Not too shabby. And this "magic page" idea means it may get faster. -M - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [OT] Re: Linux NAT questions- (kernel upgrade??)
I am using the Red Hat 7, below are my kernel version. I feel Red Hat 7 is quite new, although RH 7.1 has just come out. How come it still say that my kernel version is old. [root@guava simc]# uname -a Linux guava 2.2.16-22 #1 Tue Aug 22 16:16:55 EDT 2000 i586 unknown [root@guava simc]# -Original Message- From: J Sloan [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 03, 2001 1:24 AM To: Sim, CT (Chee Tong) Cc: Linux kernel Subject: [OT] Re: Linux NAT questions- (kernel upgrade??) "Sim, CT (Chee Tong)" schrieb: > Hi.. I follow your instruction, but I encounter this issue, my kernel need > to be upgrade? MAy I know how to determine the current kernel version uname -a > and > how to upgrade it?? Either upgrade to a distro that includes the new kernel (e.g. latest SuSE or Red Hat) or download kernel source and compile. It might be helpful to provide the distribution and version you are using (Red Hat 6.2, Slackware 7, Debian Potato, etc) > [root@guava /root]# iptables -t nat -A PREROUTING -p tcp --dst 1.1.1.160 -i > eth1 -j D > NAT --to-destination 192.168.200.2 > iptables v1.1.1: can't initialize iptables table `nat': iptables who? (do > you need to insm > od?) > Perhaps iptables or your kernel needs to be upgraded. > > [root@guava simc]# rpm -ivh iptables-1_2_0-6_i386.rpm > error: failed dependencies: > kernel >= 2.4.0 is needed by iptables-1.2.0-6 Yes, of course iptables won't work with the old kernel. If you want to stay with the old kernel, you must use ipchains instead. cu Jup == 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/
Re: [PATCH][CFT] (updated) ext2 directories in pagecache
On Thursday 03 May 2001 03:15, you wrote: > 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 Thanks Albert, this was easily reproduceable here but did not show up with 2.4.2 (uml), which I'd used to develop the patch. Analyzing now... -- 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/
Re: [PATCH] 2.4.4 breaks VMware
On Wed, May 02, 2001 at 06:53:49AM +0200, Bjoern A. Zeeb wrote: > 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/ It seems to fix the problem with vmware recognizing older SCSI CDROMs as well. PGP signature
[PATCH] turn device_init() into an initcall
Patch below turns device_init() into initcall. Current tree
calls it from fs/partitions/check.c::partitions_setup() - definitely
odd place for that stuff.
Another thing done by partition_setup() is {init,}rd_load(). I.e.
setting the contents of /dev/ram0 from initrd or floppies. That beast
should be done after _all_ drivers' initialization, indeed - it belongs with
mount_root()/mount_devfs()/etc. I took it to main/init.c - that way
it's guaranteed to be called after all drivers initialization code and
that's where we do the rest of late-boot stuff. partition_setup() is gone
now.
Patch is against 2.4.5-pre1. Please, apply.
Al
diff -urN S5-pre1/drivers/block/genhd.c S5-pre1-device_init/drivers/block/genhd.c
--- S5-pre1/drivers/block/genhd.c Fri Feb 16 18:37:04 2001
+++ S5-pre1-device_init/drivers/block/genhd.c Wed May 2 21:09:30 2001
@@ -31,7 +31,7 @@
extern int cpqarray_init(void);
extern void ieee1394_init(void);
-void __init device_init(void)
+int __init device_init(void)
{
#ifdef CONFIG_PARPORT
parport_init();
@@ -64,4 +64,7 @@
#ifdef CONFIG_VT
console_map_init();
#endif
+ return 0;
}
+
+__initcall(device_init);
diff -urN S5-pre1/fs/partitions/check.c S5-pre1-device_init/fs/partitions/check.c
--- S5-pre1/fs/partitions/check.c Thu Feb 22 06:45:26 2001
+++ S5-pre1-device_init/fs/partitions/check.c Wed May 2 21:09:30 2001
@@ -33,10 +33,7 @@
#include "ibm.h"
#include "ultrix.h"
-extern void device_init(void);
extern int *blk_size[];
-extern void rd_load(void);
-extern void initrd_load(void);
struct gendisk *gendisk_head;
int warn_no_part = 1; /*This is ugly: should make genhd removable media aware*/
@@ -438,19 +435,3 @@
blk_size[dev->major] = dev->sizes;
}
}
-
-int __init partition_setup(void)
-{
- device_init();
-
-#ifdef CONFIG_BLK_DEV_RAM
-#ifdef CONFIG_BLK_DEV_INITRD
- if (initrd_start && mount_initrd) initrd_load();
- else
-#endif
- rd_load();
-#endif
- return 0;
-}
-
-__initcall(partition_setup);
diff -urN S5-pre1/init/main.c S5-pre1-device_init/init/main.c
--- S5-pre1/init/main.c Wed May 2 11:16:38 2001
+++ S5-pre1-device_init/init/main.c Wed May 2 21:09:30 2001
@@ -638,9 +638,6 @@
*/
static void __init do_basic_setup(void)
{
-#ifdef CONFIG_BLK_DEV_INITRD
- int real_root_mountflags;
-#endif
/*
* Tell the world that we're going to be the grim
@@ -707,13 +704,6 @@
/* Networking initialization needs a process context */
sock_init();
-#ifdef CONFIG_BLK_DEV_INITRD
- real_root_dev = ROOT_DEV;
- real_root_mountflags = root_mountflags;
- if (initrd_start && mount_initrd) root_mountflags &= ~MS_RDONLY;
- else mount_initrd =0;
-#endif
-
start_context_thread();
do_initcalls();
@@ -724,6 +714,33 @@
#ifdef CONFIG_PCMCIA
init_pcmcia_ds(); /* Do this last */
#endif
+}
+
+extern void rd_load(void);
+extern void initrd_load(void);
+
+/*
+ * Prepare the namespace - decide what/where to mount, load ramdisks, etc.
+ */
+static void prepare_namespace(void)
+{
+#ifdef CONFIG_BLK_DEV_INITRD
+ int real_root_mountflags = ROOT_DEV;
+ real_root_mountflags = root_mountflags;
+ if (!initrd_start)
+ mount_initrd = 0;
+ if (mount_initrd)
+ root_mountflags &= ~MS_RDONLY;
+#endif
+
+#ifdef CONFIG_BLK_DEV_RAM
+#ifdef CONFIG_BLK_DEV_INITRD
+ if (mount_initrd)
+ initrd_load();
+ else
+#endif
+ rd_load();
+#endif
/* Mount the root filesystem.. */
mount_root();
@@ -755,6 +772,8 @@
{
lock_kernel();
do_basic_setup();
+
+ prepare_namespace();
/*
* Ok, we have completed the initial bootup, and
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 benchmark results
I belong to a small group of students at Northern Michigan University who have spent the last 3 months running LMBench on Linux kernels from 2.0.1 to 2.4.0 we have some interesting results at: http://euclid.nmu.edu/~benchmark On our web site we have graphs for what we thought were the important areas. Including signal handling, mmap latency, lines of code, and context switching. If you would like to email our group directly the address is [EMAIL PROTECTED] I apologize for resubmitting this but I put the wrong email address to contact the group. Thanks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Compiling kernel
On Wed, May 02, 2001 at 06:00:00PM +0530, [EMAIL PROTECTED] wrote: > suppose I am making some change in sched.c and now I want to build my kernel > that reflects the change.. > Is there any way I can avoid answering all the questions when I do make zImage ? > > In short how should I compile the kernel (in very small time) to see my changes. It sounds like you are running "make config" after you make your changes. If you run "make oldconfig" instead of "make config" it will not ask you questions unless you have added config options to the configure scripts. Its probably not necessary to run either on of these if you have just made minor changes to the code. It does not hurt to do it though, and "make oldconfig" is fast. Hope this helps, Jim - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Build problems 2.4.4 on SPARC
> While trying to compile the 2.4.4 kernel on a SPARC-20, I encounter the > following error. > make[1]: Entering directory `/usr/src/linux-2.4.4/mm' > make all_targets > make[2]: Entering directory `/usr/src/linux-2.4.4/mm' > gcc -D__KERNEL__ -I/usr/src/linux-2.4.4/include -Wall -Wstrict-prototypes > -O2 -fomit-frame-pointer -fno-strict-aliasing -m32 -pipe -mno-fpu > -fcall-used-g5 -fcall-used-g7-c -o memory.o memory.c > memory.c:183: macro `pmd_alloc' used with too many (3) args Known problem... For some reason, even current vger CVS has it. You might want to try Eirik's patch, but I have not idea if it is correct. http://marc.theaimsgroup.com/?l=linux-sparc=98731698113169=2 IMHO, sparc needs a port maintainer. Obviously, DaveM has barely enough time to deal with sparc64. Unfortunately it is not a position for weak (like myself). At various times I, Uzi, and Anton tried that crown for size, but it is way too big and heavy. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: your mail
On Wed, 2 May 2001, Duc Vianney wrote: > > Has anyone seen performance degradations between 2.2.19 and 2.4.x Yes. The signal handling one is because 2.4.x will save off the full SSE2 state, which means that the signal stack is almost 700 bytes, as compared to <200 before. This is sadly necessary to be able to take advantage of the SSE2 instructions - and on special applications the win can be quite noticeable. This one you won't be able to avoid, although you shouldn't see it on older hardware that do not have SSE2 (you see it because you have a PIII). You don't say how much memory you have, but the file handling ones might be due to a really unfortunate hash thinko that cause the dentry hash to be pretty much useless on machines that have 512MB of RAM (it can show up in other cases, but 512M is the case that makes the hash really become a non-hash). If so, it should be fixed in 2.4.2. 2.4.4 will give noticeably better numbers for fork and fork+exec. However, the scheduling optimization that does that actually breaks at least "bash", and it appears that we will just undo it during the stable series. Even if the bug is obviously in user land (and a fix is available), stable kernels shouldn't try to hide the problems. 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: Complete support for Intel 815 chipset?
> This may not matter in terms of performance, but many devices on Intel 815 > chipset machines show up as unknown. Any ideas when (or if) full support > for the 815 is planned? Get a newer lspci if there is one yet. It is simply down to the number/name table in lspci not the kernel what is printed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [OT] Interrupting select.
> > [seriously man sigaction]
> Equally seriously .. all signals are unblocked in my code and always
[see man signaction]
> struct sigaction sa =3D { {sighandler}, {{0}}, SA_RESTART, N=
subtle hint> ^^
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [OT] Interrupting select
"Mark Hahn wrote:"
> > while (1) {
> > int res = select(n,rfds,wfds,efds,);
> > if (res > 0)
> > return res;// data or error is expected
> > if (res == 0) {
> > return -ETIME; // timeo in select
> > }
> > }
> >
> > A resounding "no". kill -9 hurts it but it's invulnerable to everything
> > else.
>
> um, shouldn't you be testing for res==-1, as well?
> specifically that condition and errno==EINTR is how I'd expect
> signals to effect the loop...
Possibly .. if so that's the answer. But the man page doesn't say so:
tained in the descriptor sets, which may be zero if the
timeout expires before anything interesting happens. On
error, -1 is returned, and errno is set appropriately;
I assumed that "error" is something like trying to watch for a
negative number or zero descriptors, or having a fd_set that doesn't
contain open fd's. The reason I assumed that is because EINTR is not
listed as a possible:
ERRORS
EBADF An invalid file descriptor was given in one of the
sets.
EINTR A non blocked signal was caught.
EINVAL n is negative.
ENOMEM select was unable to allocate memory for internal
tables.
But I'm willing to give it a try! Thanks!
Now back to your regularly scheduled programs ...
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Processes hanging in D state in 2.4.3 - any findings?
Hi List, I saw this in the archive. And I guess, I am also seeing this problem on 2.4.4. But I am not sure. Has this problem of rw_semaphore been fixed in 2.4.4 ? If not any idea, when will this be fixed ? Regards, -hiren (408)970-3062 [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: X15 alpha release: as fast as TUX but in user space
Hi, At 10:50 AM 2/05/2001 +0200, Ingo Molnar wrote: >i think Zach's phhttpd is an important milestone as well, it's the first >userspace webserver that shows how to use event-based, sigio-based async >networking IO and sendfile() under Linux. (I believe it had some >performance problems related to sigio queue overflow, these issues might >be solved in the latest kernels.) The zerocopy enhancements should help >phhttpd as well. my experience with sigio-based event-handlers is that the net-gain of event-driven i/o is mitigated by the fact that SIGIO is based on signals. the problem with signals for this purpose are: (a) you go thru a syncronization point in the kernel. signals are protected by a spinlock. it doesn't scale with SMP. (b) SI_PAD_SIZE explicitly, (b) means that you have an awful lot of memory-accesses going on for every signal. my experience with the overhead is that it mitigates the advantages when you become bottlenecked on memory-bus-accesses. cheers, lincoln. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Logging kernel oops
On Wed, 02 May 2001 20:57:16 +0100, "Joseph Mathewson" <[EMAIL PROTECTED]> wrote: >What is the preferred what of getting debugging information from a kernel >oops? Is my only way connecting a monitor and getting a pencil and paper? >Is there any conceivable way I can get some useful debugging information >(on reset) without plugging in a keyboard/monitor? Add a serial console (linux/Documentation/serial-console.txt) and install the kernel debugger of your choice. kdb is good ;) http://oss.sgi.com/projects/kdb/download - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Max TenEyck Woodbury wrote: > > Doug Ledford wrote: > > > > Max TenEyck Woodbury wrote: > >> > >> Umm. Reboot? What do you think this is? Windoze? > > > > It's the *only* way to guarantee that the drive is never touched by more > > than one machine at a time (notice, I've not been talking about a shared > > use drive, only one machine in the cluster "owns" the drive at a time, > > and it isn't for single transactions that it owns the drive, it owns > > the drive for as long as it is alive, this is a limitation of the > > filesystes currently available in mainstream kernels). The reservation > > conflict and subsequent reboot also *only* happens when a reservation > > has been forcefully stolen from a machine. In that case, you are talking > > about a machine that has been failed over against its will, and the > > absolute safest thing to do in order to make sure the failed over machine > > doesn't screw the whole cluster up, is to make it reboot itself and > > re-enter the cluster as a new failover slave node instead of as a master > > node. If you want a shared common access device with write locking > > semantics, as you seem to be suggesting later on, then you need a > > different method of locking than what I put in this, I knew that as I > > wrote it and that was intentional. > > That was partly meant to be a joke, but it was also meant to make you stop > and think about what you are doing. From what little context I read, you > seem to be looking for a high availability solution. Rebooting a system, > even if there is a hot backup, should only be used as a last resort. This is something that only happens when a machine has been forcefully failed over against its will. I guess you would need to see the code to tell what I'm talking about, but in the description I gave of the code, if it doesn't get a reservation, it exits. The way the code is intended to be used is something like this: Given machine A as cluster master and machine B as a cluster slave. Machine A starts the reservation program with something like this as the command line: reserve --reserve --hold /dev/sdc This will result in the program grabbing a reservation on drive sdc (or exiting with a non-0 status on failure) and then sitting in a loop where it re-issues the reservation every 2 seconds. Under normal operation, the reserve program is not started at all on machine B. However, machine B does use the normal heartbeat method (be that the heartbeat package or something similar, but not reservations) to check that machine A is still alive. Given a failure in the communications between machine B and machine A, which would typically mean it is time to fail over the cluster, machine B can test the status of machine A by throwing a reset to the drive to break any existing reservations, waiting 4 seconds, then trying to run it's own reservation. This can be accomplished with the command: reserve --reset --reserve --hold /dev/sdc If the program fails to get the reservation then that means machine A was able to resend it's reservation. Obviously then, machine A isn't dead. Machine B can then decide that the heartbeat link is dead but machine A is still fine and not try any further failover actions, or it could decide that machine A has a working reserve program but key services or network connectivity may be dead, in which case a forced failover would be in order. To accomplish that, machine B can issue this command: reserve --preempt --hold /dev/sdc This will break machine A's reservation and take the drive over from machine A. It's at this point, and this point only, that machine A will see a reservation conflict. It has been forcefully failed over, so resetting/rebooting the machine is a perfectly fine alternative (and the reason it is recommended is because at this point in time, machine B may already be engaged in recovering the filesystem on the shared drive, and machine A may still have buffers it is trying to flush to the same drive, so in order to make sure machine A doesn't let some dirty buffer get through a break in machine B's reservation caused by something as inane as another machine on the bus starting up and throwing an initial reset, we should reset machine A *as soon as we know it has been forcefully failed over and is no longer allowed to write to the drive*). Arguments with this can be directed to Stephen Tweedie, who is largely responsible for beating me into doing it this way ;-) > Another problem is that reservations do *not* guarantee ownership over > the long haul. There are too many mechanisms that break reservations to > build a complete strategy on them. See above about the reason for needing to reset the machine ;-) The overall package is cooperative in nature, so we don't rely on reservations except for the actual failover. However, due to this very issue, we need to kill the machine that was failed over as soon as possible after the failover to avoid any possible races with open
Complete support for Intel 815 chipset?
This may not matter in terms of performance, but many devices on Intel 815 chipset machines show up as unknown. Any ideas when (or if) full support for the 815 is planned? -Phil Output of lspci: 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset Graphics Controller] (rev 02) 00:1e.0 PCI bridge: Intel Corporation: Unknown device 244e (rev 02) 00:1f.0 ISA bridge: Intel Corporation: Unknown device 2440 (rev 02) 00:1f.1 IDE interface: Intel Corporation: Unknown device 244b (rev 02) 00:1f.2 USB Controller: Intel Corporation: Unknown device 2442 (rev 02) 00:1f.3 SMBus: Intel Corporation: Unknown device 2443 (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation: Unknown device 2445 (rev 02) 01:08.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Kernel Debuggers, KDB or KGDB?
On Wed, 2 May 2001 16:06:15 -0500, Paul J Albrecht <[EMAIL PROTECTED]> wrote: >I'd like to know more about your plans to enhance KDB with source level debug >capability. Use a combination of gdb and kdb. kdb to support kernel internals, gdb to take the kdb output and add source level data. It needs two machines, one that is running to support gdb, the second machine is being debugged, with a serial console between them. The problem will be stopping gdb from making assumptions about the machine being debugged. Instead of changing gdb code, use a gdb wrapper program to intercept user commands and gdb serial protocol and convert them to kdb commands. >Would you have to boot an unstripped kernel executable whenever you >wanted to debug? Boot, no. But the machine running gdb will need an copy of the unstripped vmlinux and module objects to get the debug information. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [OT] Interrupting select.
"A month of sundays ago Alan Cox wrote:"
> > What IS the magic combination that makes select interruptible
> > by honest-to-goodness non-blocked signals!
> man
>
> [seriously man sigaction]
Equally seriously .. all signals are unblocked in my code and always
have been. The processes receive signals vury happily. Except when
they are in a select-with-timeout loop, when they keep going round the
loop poking their head out of the select every 5s, and taking no notice
of the murderous hail of die die die die die stuff being slammed at
them.
You can see stuff such as the following early on in my code:
// handle every s¡ngle signal in one "sighandler"
for (k = 1; k < 30; k++) {
struct sigaction sa = { {sighandler}, {{0}}, SA_RESTART, NULL };
sigfillset(& sa.sa_mask);
sigaction(k, & sa, NULL);
}
But does select come out of this loop?
while (1) {
int res = select(n,rfds,wfds,efds,);
if (res > 0)
return res;// data or error is expected
if (res == 0) {
return -ETIME; // timeo in select
}
}
A resounding "no". kill -9 hurts it but it's invulnerable to everything
else.
Looking at the kernel code in select.c. I see it's implemented by poll
(I knew that). sys_select calls do_select and I can't for the life of
me see where anyone sets a signal mask. OTOH if all signals are
masked by default when syscalls are made (I don't know, but it seems
possible) then I can't see where interrupts are allowed again.
The man page for select says nothing about it being interruptible, or
not.
This has been in the back of my mind for months. I'm glad somebody
asked about it!
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 Kernel Debuggers, KDB or KGDB?
On Mon, 30 Apr 2001, Keith Owens wrote: > On Mon, 30 Apr 2001 16:17:22 -0500, > Paul J Albrecht <[EMAIL PROTECTED]> wrote: > >Where can I find an analysis of the relative strengths and weaknesses of KDB > >and KGDB for kernel debug? Has the linux community come to any consensus > >regarding the utility one or the other? > > kdb is a really low level debugger which understands the kernel > structures. It does its utmost to stop all kernel activity while it is > running and to use as few kernel services as possible so it can run > even when the kernel is dead. It (currently) has no source level > debugging. > I'd like to know more about your plans to enhance KDB with source level debug capability. What sort of compiler debug output would be supported? STABs or DWARF? Both? What hardware platforms would be supported? What about gui support? KDB is console debugger, i.e., it doesn't support a remote serial protocol so I don't understand how source level debug would work. Would you have to boot an unstripped kernel executable whenever you wanted to debug? KGDB is better because it's a source level debugger and because you get a graphical interface, Data Display Debugger (DDD), for free when you use gdb. KGDB is better because it's more platform agnostic than KDB. The only architecture dependent part in the kernel is the gdb stub which is small and well defined. > kgdb relies on gdb so you loose the knowledge of kernel internals (no, > I am *not* going to teach gdb about kernel stacks, out of line lock > code etc.). kgdb has more of a dependency on a working kernel. It > provides source level debugging, although stack backtrace tends not to > work unless you compile the kernel with frame pointers. > I don't know what you mean when you say "loose knowledge of kernel internals" with KGDB ... I'd rather develop a set of standard gdb user defined commands to expose kernel internals than hard code them in the linux kernel. As for stack frame analysis, both debuggers have problems with backtrace if the kernel is compiled without CONFIG_FRAME_POINTER option. Whether the problem is fixed in gdb for KGDB users or the kernel for KDB users is immaterial in choosing one debugger over the other. -- Paul J Albrecht [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/
[OT] automated remote install of Linux from WinNT4
Apologies for the off topic post. I have searched Google, Freshmeat and Sourceforge without success, and this is where the smart people are... I need to do an automated, remote installation of Linux on a large number of networked computers running Windows NT 4.0. I can place an executable on each of these computers and run it with Admin privileges. These computers are using an NTFS file system and have unpartitioned space available. So, I need a Windows NT program that can create a bootable Linux partition, and then reboot into Linux from that partition. Does anyone know of anything like that? If nothing like this exists, I will have to write it in the next month or two. My hypothetical plan is to (1) port a recent LILO or GRUB to Windows, and then (2) write a Windows NT program that creates a small FAT32 partition, formats it, mounts it, and copies in the kernel, modules, init, and a minimal set of essential files. It would then run the Windows NT port of LILO/GRUB to set up the MBR to boot Linux from the new partition. The minimal Linux install would bootstrap the rest of the Linux install over the network. Thanks for any advice or hints anyone can provide... Torrey Hoffman [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: [RFC] gcc compile-time assertions
David Howells wrote:
>
> I've written a patch for gcc to implement compile-time assertions with an eye
> to making use of this in the kernel in the future (assuming I can get it to be
> accepted into gcc).
>
Brilliant.
It seems that there needs to be a way of detecting the
presence of the feature at compile-time, so you
can do
#ifndef HAVE_CT_ASSERT
#define __builtin_ct_assert(a, b) do{}while(0)
#endif
or whatever.
Apart from that, I'd suggest you fill out the FSF
damage waiver and see if you can make this part of
stock gcc.
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [3com905b freeze Alpha SMP 2.4.2] FullDuplex issue ?
"Cabaniols, Sebastien" wrote: > > [ SMP Alpha dies running TCP Rx+Tx ] > Sebastien, I'd be suspecting the 2.4.2/Alpha kernel more than the ethernet driver. Are you able to reproduce this with more recent kernels? - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
No Subject
Has anyone seen performance degradations between 2.2.19 and 2.4.x when running lmbench? I ran the lmbench benchmark on Linux kernels 2.2.19, 2.4.0, and 2.4.1 and observed performance degradation to be most noticed in signal handling, pipe latency, file deletion, and process creation. Are you aware of any kernel changes introduced in 2.4.x that might cause this performance degradation? The following data are in microseconds, lower is better. Each data point represents the average of at least four runs. Tests Linux 2.2.19 Linux 2.4.0 Linux 2.4.1 Signal handler overhead 1.64 3.77 3.82 Pipe latency 4.58 5.28 5.55 File deletion - 10K 11.48 15.30 15.71 Process fork 114.76 140.45141.98 Process fork+execve763.57 834.40840.39 Notes: 1. The benchmark is lmbench-2beta1. 2. The hardware under test is a 700MHz PIII Xeon. 3. The operating system under test is Red Hat 6.2, running Linux kernels 2.2.19, 2.4.0 and 2.4.1, with 4GB memory support. The following is the summary report generated by the lmbench benchmark. L M B E N C H 2 . 0 S U M M A R Y (Alpha software, do not distribute) Basic system parameters Host OS Description Mhz - - --- biglinux- Linux 2.2.19 i686-pc-linux-gnu 700 biglinux- Linux 2.2.19 i686-pc-linux-gnu 700 biglinux- Linux 2.2.19 i686-pc-linux-gnu 700 biglinux- Linux 2.2.19 i686-pc-linux-gnu 700 biglinux- Linux 2.4.0 i686-pc-linux-gnu 700 biglinux- Linux 2.4.0 i686-pc-linux-gnu 700 biglinux- Linux 2.4.0 i686-pc-linux-gnu 700 biglinux- Linux 2.4.0 i686-pc-linux-gnu 700 biglinux- Linux 2.4.0 i686-pc-linux-gnu 700 biglinux- Linux 2.4.1 i686-pc-linux-gnu 700 biglinux- Linux 2.4.1 i686-pc-linux-gnu 700 biglinux- Linux 2.4.1 i686-pc-linux-gnu 700 biglinux- Linux 2.4.1 i686-pc-linux-gnu 700 Processor, Processes - times in microseconds - smaller is better Host OS Mhz null null open selct sig sig fork exec sh call I/O stat clos TCP inst hndl proc proc proc - - - biglinux- Linux 2.2.19 700 0.43 0.61 3.89 4.8420 1.27 1.64 109 761 2988 biglinux- Linux 2.2.19 700 0.43 0.62 3.91 4.8920 1.27 1.64 108 760 2981 biglinux- Linux 2.2.19 700 0.43 0.62 3.88 4.9320 1.27 1.64 108 764 2986 biglinux- Linux 2.2.19 700 0.43 0.62 3.79 4.7322 1.27 1.64 132 767 3011 biglinux- Linux 2.4.0 700 0.40 0.63 3.37 4.4519 1.21 3.75 139 831 3219 biglinux- Linux 2.4.0 700 0.40 0.60 3.39 4.4619 1.24 3.75 139 831 3269 biglinux- Linux 2.4.0 700 0.43 0.63 3.39 4.4621 1.24 3.82 142 841 3255 biglinux- Linux 2.4.0 700 0.43 0.62 3.37 4.4921 1.24 3.75 140 835 3244 biglinux- Linux 2.4.0 700 0.43 0.62 3.37 4.4719 1.24 3.75 140 832 3263 biglinux- Linux 2.4.1 700 0.40 0.61 3.37 4.3519 1.21 3.80 141 836 3262 biglinux- Linux 2.4.1 700 0.40 0.61 3.39 4.4221 1.21 3.85 142 841 3316 biglinux- Linux 2.4.1 700 0.40 0.59 3.42 4.3821 1.21 3.81 141 841 3306 biglinux- Linux 2.4.1 700 0.40 0.61 3.39 4.3920 1.21 3.81 142 841 3225 Context switching - times in microseconds - smaller is better - Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw - - - -- -- -- -- --- --- biglinux- Linux 2.2.19 0.850 5.0800 21 6.7500 23 8.98000 97 biglinux- Linux 2.2.19 0.860 7.1700 21 6.9200 22 10 138 biglinux- Linux 2.2.19 0.890 6.5100 21 6.5600136 14 155 biglinux- Linux 2.2.19 0.960 6.4200 21 6.7000 22 7.16000 88 biglinux- Linux 2.4.0 1.040 6.5300 21 6.5800 29 19 185 biglinux- Linux 2.4.0 1.170 6.6200 21 6.7000 22 6.72000 102 biglinux- Linux 2.4.0 1.050 6.6100 21 6.5900 22 6.68000 101 biglinux- Linux 2.4.0 1.070 6.5700 21 6.7200 22 6.79000 102 biglinux- Linux 2.4.0 1.100 6.5300 21 6.5900 22 13 107 biglinux- Linux 2.4.1 1.050 6.4400 21 7.2000 23 6.88000 102 biglinux- Linux 2.4.1 1.140 6.6900 21 6.7100 22 6.92000 103 biglinux- Linux 2.4.1 1.130 6.7200 22 6.9300 22 6.85000 110 biglinux- Linux 2.4.1 1.180 6.5000 21 7.1000 22 7.11000 109 *Local* Communication latencies in microseconds - smaller is
Re: [OT] Interrupting select.
> What IS the magic combination that makes select interruptible > by honest-to-goodness non-blocked signals! man [seriously man sigaction] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Build problems 2.4.4 on SPARC
Hello -
While trying to compile the 2.4.4 kernel on a SPARC-20, I encounter the
following error.
[1.] One line summary of the problem:
kernel 2.4.4 won't compile
[2.] Full description of the problem/report:
See item 7.7 for details
[3.] Keywords (i.e., modules, networking, kernel):
kernel
[4.] Kernel version (from /proc/version):
2.4.1
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
[6.] A small shell script or example program which triggers the
problem (if possible)
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Linux SoftwareHackery.Com 2.4.1 #8 SMP Thu Feb 8 09:57:19 EST 2001 sparc unknown
Gnu C 2.95
Gnu make 3.78.1
binutils 2.9.5.0.22
util-linux 2.10f
mount 2.10f
modutils 2.3.10-pre1
e2fsprogs 1.18
PPP2.3.11
Linux C Library2.1.3
Dynamic linker (ldd) 2.1.3
Procps 2.0.6
Net-tools 1.54
Console-tools 0.3.3
Sh-utils 2.0
Modules Loaded
[7.2.] Processor information (from /proc/cpuinfo):
cpu : Texas Instruments, Inc. - SuperSparc-(II)
fpu : SuperSparc on-chip FPU
promlib : Version 3 Revision 2
prom: 2.25
type: sun4m
ncpus probed: 1
ncpus active: 1
Cpu0Bogo: 74.75
MMU type: TI Viking/MXCC
contexts: 65536
nocache total : 1048576
nocache used: 736512
CPU0: online
[7.3.] Module information (from /proc/modules):
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
[7.5.] PCI information ('lspci -vvv' as root)
pcilib: Cannot open /proc/bus/pci
lspci: Cannot find any working access method.
[7.6.] SCSI information (from /proc/scsi/scsi)
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: SEAGATE Model: ST15150N Rev: AV01
Type: Direct-AccessANSI SCSI revision: 02
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
[X.] Other notes, patches, fixes, workarounds:
make[1]: Entering directory `/usr/src/linux-2.4.4/mm'
make all_targets
make[2]: Entering directory `/usr/src/linux-2.4.4/mm'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4/include -Wall -Wstrict-prototypes
-O2 -fomit-frame-pointer -fno-strict-aliasing -m32 -pipe -mno-fpu
-fcall-used-g5 -fcall-used-g7-c -o memory.o memory.c
memory.c:183: macro `pmd_alloc' used with too many (3) args
memory.c:204: macro `pte_alloc' used with too many (3) args
memory.c:725: macro `pte_alloc' used with too many (3) args
memory.c:750: macro `pmd_alloc' used with too many (3) args
memory.c:805: macro `pte_alloc' used with too many (3) args
memory.c:832: macro `pmd_alloc' used with too many (3) args
memory.c:1339: macro `pmd_alloc' used with too many (3) args
memory.c:1342: macro `pte_alloc' used with too many (3) args
memory.c:1392: macro `pte_alloc' used with too many (3) args
memory.c: In function `copy_page_range':
memory.c:183: warning: passing arg 1 of `___f_pmd_alloc' from incompatible pointer type
memory.c:183: warning: passing arg 2 of `___f_pmd_alloc' makes integer from pointer
without a cast
memory.c:204: warning: passing arg 1 of `___f_pte_alloc' from incompatible pointer type
memory.c:204: warning: passing arg 2 of `___f_pte_alloc' makes integer from pointer
without a cast
memory.c: In function `zeromap_pmd_range':
memory.c:725: warning: passing arg 1 of `___f_pte_alloc' from incompatible pointer type
memory.c:725: warning: passing arg 2 of `___f_pte_alloc' makes integer from pointer
without a cast
memory.c: In function `zeromap_page_range':
memory.c:750: warning: passing arg 1 of `___f_pmd_alloc' from incompatible pointer type
memory.c:750: warning: passing arg 2 of `___f_pmd_alloc' makes integer from pointer
without a cast
memory.c: In function `remap_pmd_range':
memory.c:805: warning: passing arg 1 of `___f_pte_alloc' from incompatible pointer type
memory.c:805: warning: passing arg 2 of `___f_pte_alloc' makes integer from pointer
without a cast
memory.c: In function `remap_page_range':
memory.c:832: warning: passing arg 1 of `___f_pmd_alloc' from incompatible pointer type
memory.c:832: warning: passing arg 2 of `___f_pmd_alloc' makes integer from pointer
without a cast
memory.c: In function `handle_mm_fault':
memory.c:1339: warning: passing arg 1 of `___f_pmd_alloc' from incompatible pointer
type
memory.c:1339: warning: passing arg 2 of `___f_pmd_alloc' makes integer from pointer
without a cast
memory.c:1342: warning: passing arg 1 of `___f_pte_alloc' from incompatible pointer
type
memory.c:1342: warning: passing arg 2 of `___f_pte_alloc' makes integer from pointer
without a cast
memory.c: In function `__pmd_alloc':
memory.c:1364: warning: implicit declaration of
[PATCH][RFT] smbfs bugfixes for 2.4.4
Hello all
This patch have been building up for a while, without reaching some
undefined level of readiness. I would like some feedback from other smbfs
users before submitting this for 2.4.4-something. Particularly from people
mounting win9x shares.
* win9x will sometimes not give back the right filesize, this can cause
problems when cp'ing a file over an existing one. When truncating the
file to 0 bytes the server keeps reporting the old size and much
confusion arises.
(reported by Xuan Baldauf, could you verify that this fixes it? If it
does it's a much better fix than the workaround you got before.)
* The timeout for a reconnect was only 5 seconds, which may not be enough.
To make it worse, if there is a timeout the mount will be dead.
umount time.
* Allow smbmount to supply a new connection even if the retry attempt has
timed-out. "dead" mounts can then be resurrected ... this allows you to
replace a smbmount that have crashed, or it would if smbmount supported
that.
* Locking bug in smb_newconn, it modifies the "server" struct without
having the server lock.
* Fix theoretical memory leak and the missing smb malloc debug functions.
* fsync now causes a SMBflush to tell the server that we want the data to
hit the disc. (as suggested by Jochen Dolze)
* Don't zero out the superblock flags to allow readonly mounts to be
readonly. If someone knows why sb->s_flags = 0; is a good idea I'd
like to know. (fix by René Scharfe)
Patch vs 2.4.4, if someone prefers 2.4.4-acX it should work (even if the
patch fails on changes to Configure.help).
/Urban
diff -urN -X exclude linux-2.4.4-orig/Documentation/Configure.help
linux-2.4.4-smbfs/Documentation/Configure.help
--- linux-2.4.4-orig/Documentation/Configure.help Wed May 2 20:01:07 2001
+++ linux-2.4.4-smbfs/Documentation/Configure.help Wed May 2 20:44:43 2001
@@ -12081,10 +12081,7 @@
The nls settings can be changed at mount time, if your smbmount
supports that, using the codepage and iocharset parameters.
- Currently no smbmount distributed with samba supports this, it is
- assumed future versions will. In the meantime you can get an
- unofficial patch for samba 2.0.7 from:
- http://www.hojdpunkten.ac.se/054/samba/index.html
+ smbmount from samba 2.2.0 or later supports this.
nls support setting
CONFIG_SMB_NLS_REMOTE
@@ -12096,10 +12093,7 @@
The nls settings can be changed at mount time, if your smbmount
supports that, using the codepage and iocharset parameters.
- Currently no smbmount distributed with samba supports this, it is
- assumed future versions will. In the meantime you can get an
- unofficial patch for samba 2.0.7 from:
- http://www.hojdpunkten.ac.se/054/samba/index.html
+ smbmount from samba 2.2.0 or later supports this.
Coda file system support (advanced network fs)
CONFIG_CODA_FS
diff -urN -X exclude linux-2.4.4-orig/MAINTAINERS linux-2.4.4-smbfs/MAINTAINERS
--- linux-2.4.4-orig/MAINTAINERSWed May 2 20:01:07 2001
+++ linux-2.4.4-smbfs/MAINTAINERS Wed May 2 20:42:24 2001
@@ -1171,7 +1171,7 @@
SMB FILESYSTEM
P: Urban Widmark
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
W: http://samba.org/
L: [EMAIL PROTECTED]
S: Maintained
diff -urN -X exclude linux-2.4.4-orig/fs/smbfs/ChangeLog
linux-2.4.4-smbfs/fs/smbfs/ChangeLog
--- linux-2.4.4-orig/fs/smbfs/ChangeLog Sat Mar 31 19:11:53 2001
+++ linux-2.4.4-smbfs/fs/smbfs/ChangeLogWed May 2 23:48:56 2001
@@ -1,5 +1,18 @@
ChangeLog for smbfs.
+2001-04-25 René Scharfe <[EMAIL PROTECTED]>
+
+ * inode.c: Don't clear s_flags and allow ro mounts
+
+2001-04-21 Urban Widmark <[EMAIL PROTECTED]>
+
+ * dir.c, proc.c: replace tests on conn_pid with tests on state to
+ fix smbmount reconnect on smb_retry timeout and up the timeout to 30s.
+ * proc.c: smb_newconn must have the server locked while updating it.
+ * inode.c, proc.c: need flush after truncate on some servers (win9x)
+ * file.c: add call to send SMBflush on fsync
+ (as suggested by Jochen Dolze <[EMAIL PROTECTED]>)
+
2001-03-06 Urban Widmark <[EMAIL PROTECTED]>
* cache.c: d_add on hashed dentries corrupts d_hash list and
diff -urN -X exclude linux-2.4.4-orig/fs/smbfs/dir.c linux-2.4.4-smbfs/fs/smbfs/dir.c
--- linux-2.4.4-orig/fs/smbfs/dir.c Thu Feb 22 20:52:03 2001
+++ linux-2.4.4-smbfs/fs/smbfs/dir.cWed May 2 20:42:24 2001
@@ -210,10 +210,6 @@
return result;
}
-/*
- * Note: in order to allow the smbmount process to open the
- * mount point, we don't revalidate if conn_pid is NULL.
- */
static int
smb_dir_open(struct inode *dir, struct file *file)
{
@@ -230,14 +226,18 @@
*/
lock_kernel();
server = server_from_dentry(dentry);
- if (server->opt.protocol < SMB_PROTOCOL_LANMAN2)
- {
+ if (server->opt.protocol <
Re: Disk Performance Measurements
> > In regards to diskr/wblk, drive_stat_acct() increments the number of > > sectors/blocks read based n the values in the request being processed by > > add_request(). But add_request() is only called for requests that can't be > > merged with requests currently on the queue. Thus the counters can't be > > updated for sectors that are read by being added to aqueued > > request. Unless I'm mistaken this makes the diskr/wblk mostly useless. > > Look again, drive_stat_acct is also called for list merges (just with 0 > set for new i/o of course). Ok, this problem must has been fixed in later versions. In my 2.2.16 kernel: [shaunc@ufs block]$ grep -irn "drive_stat_acct" ll_rw_blk.c 307:static inline void drive_stat_acct(int cmd, unsigned long nr_sectors, 318:printk(KERN_ERR "drive_stat_acct: cmd not R/W?\n"); 676: * which is important for drive_stat_acct() above. */ 715:drive_stat_acct(req->cmd, req->nr_sectors, disk_index); [shaunc@ufs block]$ grep -irn "dk_drive_rblk" ll_rw_blk.c 313:kstat.dk_drive_rblk[disk_index] += nr_sectors; > > record the _kilobytes_ read or written to the disks. His code adds > > drive_pg_stat_acct(). This routine increments disk_pgin/out once for each > > call to make_request(). Presumably he has assumed every call to > > make_request will always be for 2 sectors/1 Kilobytes worth of > > data. However I added printk() statements to try to verify this and found > > that the request to the block device need not be 1024 bytes, I frequently > > saw 4096 requests. In fact, the "correct_size" for the block device > > appeared to be changeable from partition to partition on the same > > disk. This "correct_size" appears to be related to the block size for the > > filesystem on the partition/disk? Following from the above logic it would > > appear that the pgin/pgout statistics are also useless since you don't > > know how large the requests were? > > The size of requests will typically vary with the block size set by > ext2. So if you have 1kB block size on your fs, that partition will > receive 1kB buffers. Similar for 4kB. The stats collected in the kernel > are sector based, units of 512 bytes. The proc printed value should be > in kB however for pgpin/out and 512b sectors for rio/rblk wio/wblk. Again, this isn't the case in the 2.2.16 kernel I'm working with. Each call to make_request() causes pgin/pgout to be incremented, since these requests can be of different sizes (even for the same disk) I can't see how a kb value can be deduced. Just as a question though, a disk/partition doesn't need to have a filesystem on it, so why is the "correct_size" for a buffer request on the block device defined based on a filesystem block system? Thanks, Shaun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [OT] Interrupting select.
"A month of sundays ago Laramie Leavitt wrote:" > I think that this is slightly off-topic, but I figure that I'll second this one (waaay off topic for the kernel list, but ...) > someone here knows the answer or where to point me to the > answer. Please respond privately so the entire list is not > spamed by the response. What IS the magic combination that makes select interruptible by honest-to-goodness non-blocked signals! > I am writing a threaded network daemon using a thread per > connection model (I know, it is not the most effective, but Me TOO. > in shared memory. I am looking for a way to send the thread a > signal or event to cause the thread to abort the read or select > call when data is available. Hear hear. :-) (followups to comp.os.linux.system or something like that) Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Doug Ledford wrote: > > Max TenEyck Woodbury wrote: >> >> Umm. Reboot? What do you think this is? Windoze? > > It's the *only* way to guarantee that the drive is never touched by more > than one machine at a time (notice, I've not been talking about a shared > use drive, only one machine in the cluster "owns" the drive at a time, > and it isn't for single transactions that it owns the drive, it owns > the drive for as long as it is alive, this is a limitation of the > filesystes currently available in mainstream kernels). The reservation > conflict and subsequent reboot also *only* happens when a reservation > has been forcefully stolen from a machine. In that case, you are talking > about a machine that has been failed over against its will, and the > absolute safest thing to do in order to make sure the failed over machine > doesn't screw the whole cluster up, is to make it reboot itself and > re-enter the cluster as a new failover slave node instead of as a master > node. If you want a shared common access device with write locking > semantics, as you seem to be suggesting later on, then you need a > different method of locking than what I put in this, I knew that as I > wrote it and that was intentional. That was partly meant to be a joke, but it was also meant to make you stop and think about what you are doing. From what little context I read, you seem to be looking for a high availability solution. Rebooting a system, even if there is a hot backup, should only be used as a last resort. Another problem is that reservations do *not* guarantee ownership over the long haul. There are too many mechanisms that break reservations to build a complete strategy on them. Unfortunately, this ground was covered during the 'cluster wars' between IBM and DEC and the field is strewn with patents, so finding an open source solution may be tough. >> ... >> >> In other words, the reservation acts as a spin-lock to make sure updates >> occur atomically. > > Apples to oranges, as I described above. This is for a failover cluster, not > a shared data, load balancing cluster. Load balancing clusters do need a good locking method, but so do failover clusters. It's been 12 years since I did much with this, but I did do a fine tooth analysis of parts of DECs clustering code looking for ways it could fail. (The results were a few internal SPRs. I'm not at liberty to discuss the details, even if I could remember them. However, I can say without giving anything away that there were places where a hardware locking mechanism, like reservation, would have simplified the code and improved performance.) It was precisely the kinds of things associated with hardware failover that lead DEC to do clusters in the first place. The load balancing stuff was secondary, even if it did sell more systems in the long run. You may be able to get through the patent minefield by retrofitting the load balancing lock mechanisms to failover. It may be that you can make it work, but the tested solution requires software to back up the hardware. Good Luck, you'll probably need a lot of it. (no sarcasm intended.) [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/
[OT] Interrupting select.
I think that this is slightly off-topic, but I figure that someone here knows the answer or where to point me to the answer. Please respond privately so the entire list is not spamed by the response. I am writing a threaded network daemon using a thread per connection model (I know, it is not the most effective, but I can extend it to use a thread per N connections in the future). That thread waits on a socket using select, or possibly merely doing a read. Messages to be written are inserted into a queue in shared memory. I am looking for a way to send the thread a signal or event to cause the thread to abort the read or select call when data is available. I know that it would be possible to create a unix socket and write a byte to that socket whenever data is available, but there should be a simpler message or signal that I can send to the thread to accomplish the same thing. Thanks, Laramie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Bug in kernel/fork.c in 2.4.4 kernel
In working on thread core dumps I've stumbled across a minor bug in the generic `fork' code. The problem code is in routine `copy_mm' in `kernel/fork.c': /* Copy the current MM stuff.. */ memcpy(mm, oldmm, sizeof(*mm)); . . . if (retval) goto free_pt; /* * child gets a private LDT (if there was an LDT in the parent) */ copy_segments(tsk, mm); . . . free_pt: mmput(mm); The new `mm' doesn't get it's own private version of it's `context' field until after the call to `copy_segments'. At the `goto' the pointer `mm' points to a copy of the old `mm_struct', including a copy of the `context' field. `mmput' will call `release_segments' which will free the memory pointed to by the `context' field. Later, when `oldmm' is freed, the kernel will try to free the same memory twice - very bad. Admittedly, this will only occur on an obscure error condition but it should be fixed. The attached patch fixes the problem by zeroing out the `context' field immediately after the `mm' structure is copied. -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale [EMAIL PROTECTED] Ph: 303/938-9838 --- linux-2.4.4-ref/kernel/fork.c Thu Apr 26 07:11:17 2001 +++ linux/kernel/fork.c Wed May 2 14:39:38 2001 @@ -311,6 +311,10 @@ /* Copy the current MM stuff.. */ memcpy(mm, oldmm, sizeof(*mm)); + + /* Clear new context for now */ + memset(>context, 0, sizeof(mm->context)); + if (!mm_init(mm)) goto fail_nomem; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
> If I understand correctly, some vendor would put I2O messaging hardware but > they would use it in a non-standard way ? So, if they dont support the I2O > protocol with their hardware, I will have to do it in another way... > > Is there a simple way to find out if my device support I2O protocol ? Maybe > its written in the BAR or in the CSR, but does linux find those devices > automaticly ? or do I have to do it in my module ? If I must do it myself, > do you know any device that is doing something like I do ? so I could look > at the code. If its running as an I2O device, it will be class I2O PCI and it'll have about 300K+ of firmware (probably vxworks) loaded onto it and a chunk of RAM. WHat sort of device is this ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Its a CompactPCI system from Ziatech. We have 2 computers in it. 1 Master (host) and 1 Slave (local). The master one is a Ziatech 5502 and the slave is a Ziatech 5541. The slave computer is isolated from the pci bus with a non-transparent pci-to-pci bridge : INTEL (DEC) 21554 Basicly I have to transmit data between the host and the local system by the pci bus. > -Message d'origine- > De : Alan Cox [mailto:[EMAIL PROTECTED]] > Envoye : May 2, 2001 5:19 PM > A : Patrick Allaire > Cc : Alan Cox; [EMAIL PROTECTED] > Objet : Re: DPT I2O RAID and Linux I2O > > > > If I understand correctly, some vendor would put I2O messaging > hardware but > > they would use it in a non-standard way ? So, if they dont > support the I2O > > protocol with their hardware, I will have to do it in another way... > > > > Is there a simple way to find out if my device support I2O > protocol ? Maybe > > its written in the BAR or in the CSR, but does linux find those devices > > automaticly ? or do I have to do it in my module ? If I must do > it myself, > > do you know any device that is doing something like I do ? so I > could look > > at the code. > > If its running as an I2O device, it will be class I2O PCI and > it'll have about > 300K+ of firmware (probably vxworks) loaded onto it and a chunk > of RAM. WHat > sort of device is this ? > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
> The slave computer is isolated from the pci bus with a non-transparent > pci-to-pci bridge : INTEL (DEC) 21554 > > Basicly I have to transmit data between the host and the local system by the > pci bus. Ok thats nothing to do with I2O itself. Some hardware has the messaging layer built into it as the messenger is very simple and stuff like the 21554 are using in I2O controllers. You might find i2o_pci.c and the i2o_core message passing code interesting but probably not that much. The I2O 1.5 specification covers the hardware interface briefly and that bit is worth reading. Ignore the rest. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: >2G Files
Bill Wendling <[EMAIL PROTECTED]> writes: > Hi all, > > Question: Does Linux support >2G files and, if so, how do I implement > this? It does in 2.4, for details check: http://www.suse.de/~aj/linux_lfs.html Andreas -- Andreas Jaeger SuSE Labs [EMAIL PROTECTED] private [EMAIL PROTECTED] http://www.suse.de/~aj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: >2G Files
Bill Wendling <[EMAIL PROTECTED]> writes: > Hi all, > > Question: Does Linux support >2G files and, if so, how do I implement > this? check this page : http://www.suse.de/~aj/linux_lfs.html > > Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Logging kernel oops
> What is the preferred what of getting debugging information from a kernel > oops? Is my only way connecting a monitor and getting a pencil and paper? > Is there any conceivable way I can get some useful debugging information > (on reset) without plugging in a keyboard/monitor? You can build and boot a kernel with serial console and run a serial cable to another box - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: xconfig is broken (example ppc 8xx)
> To show the problem do: > > make xconfig ARCH=ppc > > in the "Platform support" menu "Processor Type" select "8xx" then close > the subminue with "MainMenu" > > now select "Save and Exit" > > This produces the following error messages: > > ERROR - Attempting to write value for unconfigured variable > (CONFIG_SCC_ENET). > ERROR - Attempting to write value for unconfigured variable > (CONFIG_FEC_ENET). > I think the problem is that the "wish" script builder does not allow a > CONFIG option to be configured in two different places, even if only one Exactly. > of scripts should be included. xconfig is not an on-line parser as other interpreters. It is a script build as effect of parsing of the whole config tree and includes all possible options. The problem is that xconfig is based on an assumption that an unconfigured/disabled option variable preserves its value (as "hidden") for future reuse. It is in generel contradiction with reusing same option in more than ane place in the config tree. And nobody wants to rewrite xconfig (removing the mentioned above assumption) at the end (hopefully in 2.5) of its life ... Andrzej - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
If I understand correctly, some vendor would put I2O messaging hardware but they would use it in a non-standard way ? So, if they dont support the I2O protocol with their hardware, I will have to do it in another way... Is there a simple way to find out if my device support I2O protocol ? Maybe its written in the BAR or in the CSR, but does linux find those devices automaticly ? or do I have to do it in my module ? If I must do it myself, do you know any device that is doing something like I do ? so I could look at the code. Thank again. > > 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: >2G Files
On Wed, 2 May 2001, Bill Wendling wrote: > Question: Does Linux support >2G files and, if so, how do I implement > this? With kernel 2.4 it does. You will probably need to compile userspace programs against 2.4 headers to get this functionality in userspace programs too. Rasmus -- -- [ Rasmus 'Møffe' Bøg Hansen ] -- I think the sum of intelligence on the internet is constant. Only the number of users grows. - Uwe Ohse in the monastery - [ moffe at amagerkollegiet dot dk ] - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Memory management issues with 2.4.4
On Wed, 2 May 2001, Jorge Nerin wrote: > Short version: > Under very heavy thrashing (about four hours) the system either lockups > or OOM handler kills a task even when there is swap space left. First of all, please try to reproduce the problem with 2.4.5-pre1. If it still happens with pre1, please show us the output of "cat /proc/slabinfo" when the kernel is about to trigger the OOM killer. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel doesn't create core for threads
Zdenek-
Yes, this is a known problem. I sent out a patch last month that
fixed this problem. Unfortunately, the patch caused some kernel
hangs that I just fixed today. I'm testing the fix now so expect
a new patch either this afternoon or tomorrow that will fix this.
On Wed, May 02, 2001 at 08:53:00PM +, Zdenek Kabelac wrote:
> Hello
>
> Looks to me like the latest 2.4.5-pre1 is not creating
> coredump for multithreaded aplications:
>
>
> $ ulimit -a
> core file size (blocks) unlimited
> data seg size (kbytes) unlimited
> file size (blocks) unlimited
> max locked memory (kbytes) unlimited
> max memory size (kbytes)unlimited
> open files 1024
> pipe size (512 bytes) 8
> stack size (kbytes) 8192
> cpu time (seconds) unlimited
> max user processes 6144
> virtual memory (kbytes) unlimited
>
> $ ./testcore
> Segmentation fault
>
>
> --- test program --
>
> #include
> #include
>
> #define TASKS 10
>
> void* thread(void* arg)
> {
> printf("yuk %s\n", 0x);
> return 0;
> }
>
> int main(int argc, char *argv[])
> {
> pthread_t task[TASKS];
> void* ret;
> int i = 0;
> for(i = 0; i < TASKS; i++)
> pthread_create([i], NULL, thread, 0);
> for(i = 0; i < TASKS; i++)
> pthread_join(task[i], );
>
> return 0;
> }
> ---
>
>
> for single threadad apps there is no problem:
> (just put printf after int i declaration)
> $ ./testcore
> Segmentation fault (core dumped)
>
> ---
>
> Am I doing something wrong ???
>
> Also for quite a long time Alan's AC patches were efictively locking
> my machine when threaded application was crashing - resolvin
> almost original behaviour solved this problem - but I like
> per-thread coredump - is there any special reason why this is still
> not present in the current 2.4.4 kernel as I can see this as quite
> usefull.
>
>
> bye
>
>
> [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/
--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[EMAIL PROTECTED]
Ph: 303/938-9838
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Problem with map_user_kiobuf() not mapping to physical memory
> to the driver which performs a map_user_kiobuf() on it, the resulting > kiobuf > structure has all of the pagelist[] physical address entries set to the > same value > and the maplist[] entries set to 0. The devices access to this memory > now > causes system problems. > Is map_user_kiobuf() working correctly ? Yes, it is. You have to lock down the pages for I/O with lock_kiovec() before using the maplist. The locking will also fault the pages if needed. Gerd -- sigfault (core dumped) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Both 2.4.4aa2 and 2.4.4aa3 fail to compile
On Wed, May 02, 2001 at 10:24:18AM +0900, Maintaniner on duty wrote:
>
> With gcc-2.95.2 provided by SuSE-7.0 for Alpha on UP2000 SMP with 2GB memory
>
>
> gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
>-fomit-frame-pointer -fno-strict-aliasing -pipe -mno-fp-regs -ffixed-8 -mcpu=ev6
>-Wa,-mev6-c -o extable.o extable.c
> extable.c: In function `search_exception_table_without_gp':
> extable.c:54: `modlist_lock' undeclared (first use in this function)
> extable.c:54: (Each undeclared identifier is reported only once
> extable.c:54: for each function it appears in.)
> make[2]: *** [extable.o] Error 1
> make[2]: Leaving directory `/usr/src/linux/arch/alpha/mm'
> make[1]: *** [first_rule] Error 2
> make[1]: Leaving directory `/usr/src/linux/arch/alpha/mm'
> make: *** [_dir_arch/alpha/mm] Error 2
Sorry for that, please try this incremental patch (also for Alan) [it
didn't triggered because you know I don't use modules on my 2G alpha]:
--- 2.4.4aa3/arch/alpha/mm/extable.c.~1~Tue May 1 13:30:02 2001
+++ 2.4.4aa3/arch/alpha/mm/extable.cWed May 2 21:40:49 2001
@@ -46,6 +46,7 @@
ret = search_one_table(__start___ex_table, __stop___ex_table - 1,
addr - gp);
#else
+ extern spinlock_t modlist_lock;
unsigned long flags;
/* The kernel is the last "module" -- no need to treat it special. */
struct module *mp;
@@ -76,15 +77,23 @@
addr - exc_gp);
if (ret) return ret;
#else
+ extern spinlock_t modlist_lock;
+ unsigned long flags;
/* The kernel is the last "module" -- no need to treat it special. */
struct module *mp;
+
+ ret = 0;
+ spin_lock_irqsave(_lock, flags);
for (mp = module_list; mp ; mp = mp->next) {
- if (!mp->ex_table_start)
+ if (!mp->ex_table_start || !(mp->flags&(MOD_RUNNING|MOD_INITIALIZING)))
continue;
ret = search_one_table(mp->ex_table_start,
mp->ex_table_end - 1, addr - exc_gp);
- if (ret) return ret;
+ if (ret)
+ break;
}
+ spin_unlock_irqrestore(_lock, flags);
+ if (ret) return ret;
#endif
/*
Also note that none 2.4 kernel will ever run stable on a alpha if
compiled with 2.95.*, you _must_ use egcs 1.1.2 or the very latest 2.96
with two houndred patches if you want to have a chance to run a 2.4
kernel stable on an alpha (NOTE: only on the alpha, x86 and other
architectures are a completly different matter). So I have to reject any
(runtime) bugreport of 2.4 alpha kernels compiled with any 2.95.*, sorry.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Logging kernel oops
I get a kernel oops every few days (even weeks if I'm lucky) with kernel 2.4.2 that I suspect are related to my Speedtouch USB ADSL modem. The box in question is monitor and keyboardless unless strictly necessary, and routes the ADSL internet connection to a local network. What is the preferred what of getting debugging information from a kernel oops? Is my only way connecting a monitor and getting a pencil and paper? Is there any conceivable way I can get some useful debugging information (on reset) without plugging in a keyboard/monitor? +=+ | Joseph Mathewson <[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/
>2G Files
Hi all, Question: Does Linux support >2G files and, if so, how do I implement this? Thanks. -- || Bill Wendling[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: HPNA
On Mon, Apr 30, 2001 at 02:00:49PM +0800, [EMAIL PROTECTED] wrote: > Hello sorry to interupt ur work, i was a subscriber to the kernel mailing > list before and realise how much traffic you get. > > My friend has a DIAMOND homefree network card using HPNA > i was wondering what hte status of HPNA is in the kernel? > to refresh HPNA allows you to network ur machines via the phone lines in > america. The Home-PNA cards look like ethernet cards to the kernel. Does the specification tell something about the PROTOCOLS to be run, that I have not checked. For example, the Tulip driver (www.scyld.com) understands PHY interface called Home-PNA. Comparing to the Ethernet (10/100/1000/more Mbit/sec), the Home-PNA runs at 1 Mbit/sec. (And thus can use in-house CAT-3 telephony cabling.) > Kind Regards > Peter Revilll /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel doesn't create core for threads
Hello
Looks to me like the latest 2.4.5-pre1 is not creating
coredump for multithreaded aplications:
$ ulimit -a
core file size (blocks) unlimited
data seg size (kbytes) unlimited
file size (blocks) unlimited
max locked memory (kbytes) unlimited
max memory size (kbytes)unlimited
open files 1024
pipe size (512 bytes) 8
stack size (kbytes) 8192
cpu time (seconds) unlimited
max user processes 6144
virtual memory (kbytes) unlimited
$ ./testcore
Segmentation fault
--- test program --
#include
#include
#define TASKS 10
void* thread(void* arg)
{
printf("yuk %s\n", 0x);
return 0;
}
int main(int argc, char *argv[])
{
pthread_t task[TASKS];
void* ret;
int i = 0;
for(i = 0; i < TASKS; i++)
pthread_create([i], NULL, thread, 0);
for(i = 0; i < TASKS; i++)
pthread_join(task[i], );
return 0;
}
---
for single threadad apps there is no problem:
(just put printf after int i declaration)
$ ./testcore
Segmentation fault (core dumped)
---
Am I doing something wrong ???
Also for quite a long time Alan's AC patches were efictively locking
my machine when threaded application was crashing - resolvin
almost original behaviour solved this problem - but I like
per-thread coredump - is there any special reason why this is still
not present in the current 2.4.4 kernel as I can see this as quite
usefull.
bye
[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: X15 alpha release: as fast as TUX but in user space (fwd)
>From my experience system calls are not an issue. What costs a lot is moving data around, since modern CPUs spend most of their time in memory/bus wait cycles... - Fabio Linus Torvalds wrote: > >I think that applies to all really high-performance servers. > > Note that it is definitely not always true. > > Linux system calls are reasonably light-weight. And sometimes trying to > avoid them ends up beaing _more_ work - because you might have to worry > about synchronization and cache coherency in user mode. > > So the rule should be "avoid _unnecessary_ system calls". > > 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/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Tue, 01 May 2001 18:48:51 -0400 Chris Mason <[EMAIL PROTECTED]> wrote: > 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. No. I tried building kernel 2.4.4 five times in a row - no errors. Also some diff's after two `make dep' didn't show anything. The xfree-dri sources from cvs failed, too. Something special with imake? -- Daniel > > 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Mike Anderson wrote: > > Doug, > > I guess I worded my question poorly. My question was around multi-path > devices in combination with SCSI-2 reserve vs SCSI-3 persistent reserve which > has not always been easy, but is more difficult is you use a name space that > can slip or can have multiple entries for the same physical device you want > to reserve. The software is independant on each machine, so it is entirely possible that the same disk will be in two different name spaces one two different machines and everything work just fine. For example, maybe it's /dev/sdc on machine A and /dev/sdf on machine B. That's fine, you simply tell the software on machine A to grab /dev/sdc and tell the software on machine B to grab /dev/sdf and all will work properly. Now, as to mixing SCSI-2 and SCSI-3 Persistent Reservations on the same drive, not a chance. The software will automatically use the best alternative available, so it won't fall back to SCSI-2 LUN reservations with SCSI-3 Persistent Reservations available (and if you force it to do so, then you have no one to blame but yourself ;-) > But here is a second try. > > If this is a failover cluster then node A will need to reserve all disks in > shareable space using sg or only a subset if node A has sync'd his sd name > space with the other node and they both wish to do work in disjoint pools of > disks. > > In the scenario of grabbing all the disks. If sda and sdb are the same device > than I can only reserve one of them and ensure IO only goes down through the > one I reserver-ed otherwise I could get a reservation conflict. Correct, if you hold a reservation on a device for which you have multiple paths, you have to use the correct path. > This goes > along with your previous patch on supporting multi-path at "md" and translating this >into the proper device to reserve. The md multipath driver doesn't currently allow the proper ioctls for us to do reservations at the md level. We could only do them by going in and doing reservations on /dev/sg entries behind the back of the md layer, which would be risky at best. > I guess it is up to the caller of > your service to handle this case correct?? For now, yes. And the best method to do so is to configure your failover software to know that a device is a multipath device, only attempt to reserve or mount one path, and fail back on the second path if the first path goes away by issuing a bus reset on the secondary path, then reserving the secondary path, then mounting the secondary path. However, as you will have lost data due to the failed writes on the primary path, I think this is of dubious value. Right now, as I see it, multipath and failover simply don't mix well. There is more work needed to make it work well. > If this not any clearer than my last mail I will just wait to see the code > :-). > > Thanks, > > -Mike > > Doug Ledford [[EMAIL PROTECTED]] wrote: > > > > > > > > To: Mike Anderson <[EMAIL PROTECTED]> > > cc: [EMAIL PROTECTED], James Bottomley > > <[EMAIL PROTECTED]>, "Roets, Chris" > > <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > > [EMAIL PROTECTED] > > > > > > > > > > > > Mike Anderson wrote: > > > > > > Doug, > > > > > > A question on clarification. > > > > > > Is the configuration you are testing have both FC adapters going to the > > same > > > port of the storage device (mutli-path) or to different ports of the > > storage > > > device (mulit-port)? > > > > > > The reason I ask is that I thought if you are using SCSI-2 reserves that > > the > > > reserve was on a per initiator basis. How does one know which path has > > the > > > reserve? > > > > Reservations are global in nature in that a reservation with a device will > > block access to that device from all other initiators, including across > > different ports on multiport devices (or else they are broken and need a > > firmware update). > > > > > On a side note. I thought the GFS project had up leveled there locking / > > fencing > > > into a API called a locking harness to support different kinds of fencing > > > methods. Any thoughts if this capability could be plugged into this > > service so > > > that users could reduce recoding depending on which fencing support they > > > selected. > > > > I wouldn't know about that. > > > > -- > > > > Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford > > Please check my web site for aic7xxx updates/answers before > > e-mailing me about problems > > -- > Michael Anderson > [EMAIL PROTECTED] > > IBM Linux Technology Center - Storage IO > Phone (503) 578-4466 > Tie Line: 775-4466 -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo
Kernel Research Results
I belong to a small group of students at Northern Michigan University who have spent the last 3 months running LMBench on Linux kernels from 2.0.1 to 2.4.0 we have some interesting results at: http://euclid.nmu.edu/~benchmark If you would like to email our group directly the address is [EMAIL PROTECTED] Thanks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bug-report: reboot hangs system
Hi Riley,
I am not sure if I should have send this bug-report to you. I hope you don't
mind.
If you do could you send me the correct email adress.
Many thanks in advance.
Toshio
[1.] One line summary of the problem:
Reboot command hangs system.
[2.] Full description of the problem/report:
After I issue the command "reboot" from the prompt the system closes down
normally.
Then the system says : "Restarting system.. ". The screen becomes black and
system hangs.
init 0 works correctly system shuts down normally.
I already tried possible kernel-parameters : reboot=[c|w],[b|h]
Problems only seems to happen on the IBM's I have here.
IBM GL300
IBM Aptiva (machine in this BUG-REPORT)
The system has the latest patches from RH.
[3.] Keywords (i.e., modules, networking, kernel):
Kernel
[4.] Kernel version (from /proc/version):
Linux version 2.4.3 (root@mysystem) (gcc version 2.96 2731 (Red Hat
Linux 7.0)) #1 Mon Apr 2 14:50:23 CEST 2001
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
N/A
[6.] A small shell script or example program which triggers the
problem (if possible)
#reboot [enter]
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Linux sunspot 2.4.3 #1 Mon Apr 2 14:50:23 CEST 2001 i686 unknown
Gnu C 2.96
Gnu make 3.79.1
binutils 2.10.0.18
util-linux 2.10m
modutils 2.3.21
e2fsprogs 1.18
pcmcia-cs 3.1.19
PPP2.3.11
Linux C Library> libc.2.2
Dynamic linker (ldd) 2.2
Procps 2.0.7
Net-tools 1.56
Console-tools 0.3.3
Sh-utils 2.0
Modules Loaded
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 3
model name : Pentium II (Klamath)
stepping: 3
cpu MHz : 233.346
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
mmx
bogomips: 465.30
[7.3.] Module information (from /proc/modules):
$null
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0213-0213 : isapnp read
02f8-02ff : serial(auto)
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
0a79-0a79 : isapnp write
0cf8-0cff : PCI conf1
1000-100f : Intel Corporation 82371AB PIIX4 IDE
1200-123f : Intel Corporation 82371AB PIIX4 ACPI
1240-125f : Intel Corporation 82371AB PIIX4 ACPI
2000-2fff : PCI Bus #01
2000-20ff : ATI Technologies Inc 3D Rage Pro AGP 1X/2X
3000-307f : 3Com Corporation 3c905C-TX [Fast Etherlink] (#2)
3000-307f : eth1
3080-30ff : 3Com Corporation 3c905C-TX [Fast Etherlink]
3080-30ff : eth0
3100-311f : Intel Corporation 82371AB PIIX4 USB
-0009efff : System RAM
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-07ff : System RAM
0010-00200ceb : Kernel code
00200cec-00256b5b : Kernel data
2000-200f : PCI Bus #01
2000-2fff : ATI Technologies Inc 3D Rage Pro AGP 1X/2X
2010-201f : Cirrus Logic CS 4610/11 [CrystalClear SoundFusion Audio
Accelerator]
2020-20200fff : Cirrus Logic CS 4610/11 [CrystalClear SoundFusion Audio
Accelerator]
20201000-2020107f : 3Com Corporation 3c905C-TX [Fast Etherlink] (#2)
20201080-202010ff : 3Com Corporation 3c905C-TX [Fast Etherlink]
2100-21ff : PCI Bus #01
2100-21ff : ATI Technologies Inc 3D Rage Pro AGP 1X/2X
f800-fbff : Intel Corporation 440LX/EX - 82443LX/EX Host bridge
[7.5.] PCI information ('lspci -vvv' as root)
00:00.0 Host bridge: Intel Corporation 440LX/EX - 82443LX/EX Host bridge
(rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR-
00:01.0 PCI bridge: Intel Corporation 440LX/EX - 82443LX/EX AGP bridge (rev
03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- Reset- FastB2B-
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- [disabled] [size=128K]
Capabilities: [dc] Power Management version
Re: PROBLEM: 2.4.4, 2.4.4-ac1, 2.4.4-ac2, neighbour discovery bug(ipv6)
On Tue, 1 May 2001, Cliff Albert wrote:
>
> When i traceroute6 my 2.4.4 box on my local lan, the 2.4.4 box panic's after about
>10 seconds. The traceroute6 completes on the other box.
>
> 2.4.3-ac14 doesn't experience these problems. Only 2.4.4 (with or without ac{1,2})
>panics
>
> traceroute6 output
> traceroute to neve.oisec.net (3ffe:8114:2000:0:250:bfff:fe21:629a) from
>3ffe:8114:2000:0:210:4bff:feb3:1fb4, 30 hops max, 16 byte packets
> 1 neve.oisec.net (3ffe:8114:2000:0:250:bfff:fe21:629a) 0.583 ms 0.278 ms 0.233
>ms
>
>
[snip]
I am unable to reproduce this, either locally or remotely, I am also using
the 2.4.4 kernel, do you have any more information on this, and is it
possible to reproduce every time?
Matthew S. Hallacy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: PROBLEM: 2.4.4 oops, will not boot
On Wed, May 02, 2001 at 09:51:39PM +1000, Andrew Morton wrote: > Envelope-to: gbsadler@localhost > From: Andrew Morton <[EMAIL PROTECTED]> > X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-ac13 i686) > To: Gordon Sadler <[EMAIL PROTECTED]> > Subject: Re: PROBLEM: 2.4.4 oops, will not boot > > Gordon Sadler wrote: > > > > Please CC on replies. > > Attached is REPORTING-BUGS template from source, and a hand copied oops > > that I ran through ksymoops. I really hope this is resolved, anything > > further needed, just ask. > > Unfortunately the ksymoops output doesn't show the call trace. > Can you please try again? A reproducable oops is, err, rather > important. The syntax to feed into ksymoops is > > Call Trace: [] [] ... > > Thanks. > I see you are right, was late at night... I've attached the file I hand wrote for the oops, which I then fed to ksymoops. Also attached again is the output from ksymoops. If something is inconsistent, and I need to regen the output with ksymoops and my System.map, could someone be so kind as to suggest a proper commandline? I used: ksymoops -K -L -o /lib/modules/2.4.4/ -m /boot/System.map-2.4.4 < oops.txt >ksymresult.out Reformatted for mail, originally one line. Nothing ever made it to /var/log/ksymoops. Gordon Sadler Unable to handle kernel NULL pointer dereference at virtual address 0014 printing EIP: c01254b5 *pde = Oops: CPU: 0 EIP: 0010: [] eflags: 00010013 eax: c1227e08 ebx: c1227e08 ecx: c7e3ff68 edx: esi: 0286 edi: 0007 ebp: c12343c0 esp: c7e3feec ds: 0018es: 0018ss: 0018 Process chmod (pid: 119, stackpage = c7e3f000) stack: c1263080 c12630dc c013ec88 c1277e08 0007 c1263080 c12630dc c12343c0 0005 c01370c8 c12343c0 c7e3ff68 c7e3ff68 c12343c0 c7e3ffa4 c0137819 c12343c0 c7e3ff68 c1265000 Calltrace: [] [] [] [] [] [] [] Code: 8b 42 14 ff 42 10 89 c1 0f af 4b 0c 03 4a 0c 8b 44 82 18 89 Segmentation Fault +30 seconds VM: refill_inactive, wrong page on list ksymoops 2.4.1 on i686 2.2.19. Options used -V (default) -K (specified) -L (specified) -o /lib/modules/2.4.4/ (specified) -m /boot/System.map-2.4.4 (specified) No modules in ksyms, skipping objects Unable to handle kernel NULL pointer dereference at virtual address 0014 printing EIP: c01254b5 *pde = Oops: CPU: 0 EIP: 0010: [] Using defaults from ksymoops -t elf32-i386 -a i386 eflags: 00010013 eax: c1227e08 ebx: c1227e08 ecx: c7e3ff68 edx: esi: 0286 edi: 0007 ebp: c12343c0 esp: c7e3feec ds: 0018es: 0018 ss: 0018 stack: c1263080 c12630dc c013ec88 c1277e08 0007 c1263080 c12630dc c12343c0 0005 c01370c8 c12343c0 c7e3ff68 c7e3ff68 c12343c0 c7e3ffa4 c0137819 c12343c0 c7e3ff68 c1265000 Code: 8b 42 14 ff 42 10 89 c1 0f af 4b 0c 03 4a 0c 8b 44 82 18 89 >>EIP; c01254b5<= Code; c01254b5 <_EIP>: Code; c01254b5<= 0: 8b 42 14 mov0x14(%edx),%eax <= Code; c01254b8 3: ff 42 10 incl 0x10(%edx) Code; c01254bb 6: 89 c1 mov%eax,%ecx Code; c01254bd 8: 0f af 4b 0c imul 0xc(%ebx),%ecx Code; c01254c1 c: 03 4a 0c add0xc(%edx),%ecx Code; c01254c4 f: 8b 44 82 18 mov0x18(%edx,%eax,4),%eax Code; c01254c8 13: 89 00 mov%eax,(%eax)
Re: Linux Cluster using shared scsi
Doug, I guess I worded my question poorly. My question was around multi-path devices in combination with SCSI-2 reserve vs SCSI-3 persistent reserve which has not always been easy, but is more difficult is you use a name space that can slip or can have multiple entries for the same physical device you want to reserve. But here is a second try. If this is a failover cluster then node A will need to reserve all disks in shareable space using sg or only a subset if node A has sync'd his sd name space with the other node and they both wish to do work in disjoint pools of disks. In the scenario of grabbing all the disks. If sda and sdb are the same device than I can only reserve one of them and ensure IO only goes down through the one I reserver-ed otherwise I could get a reservation conflict. This goes along with your previous patch on supporting multi-path at "md" and translating this into the proper device to reserve. I guess it is up to the caller of your service to handle this case correct?? If this not any clearer than my last mail I will just wait to see the code :-). Thanks, -Mike Doug Ledford [[EMAIL PROTECTED]] wrote: > > > > To: Mike Anderson <[EMAIL PROTECTED]> > cc: [EMAIL PROTECTED], James Bottomley > <[EMAIL PROTECTED]>, "Roets, Chris" > <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > [EMAIL PROTECTED] > > > > > > Mike Anderson wrote: > > > > Doug, > > > > A question on clarification. > > > > Is the configuration you are testing have both FC adapters going to the > same > > port of the storage device (mutli-path) or to different ports of the > storage > > device (mulit-port)? > > > > The reason I ask is that I thought if you are using SCSI-2 reserves that > the > > reserve was on a per initiator basis. How does one know which path has > the > > reserve? > > Reservations are global in nature in that a reservation with a device will > block access to that device from all other initiators, including across > different ports on multiport devices (or else they are broken and need a > firmware update). > > > On a side note. I thought the GFS project had up leveled there locking / > fencing > > into a API called a locking harness to support different kinds of fencing > > methods. Any thoughts if this capability could be plugged into this > service so > > that users could reduce recoding depending on which fencing support they > > selected. > > I wouldn't know about that. > > -- > > Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford > Please check my web site for aic7xxx updates/answers before > e-mailing me about problems -- Michael Anderson [EMAIL PROTECTED] IBM Linux Technology Center - Storage IO Phone (503) 578-4466 Tie Line: 775-4466 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: X15 alpha release: as fast as TUX but in user space (fwd)
In article <[EMAIL PROTECTED]>, Matti Aarnio <[EMAIL PROTECTED]> wrote: >On Sun, Apr 29, 2001 at 02:16:43PM -0700, Jim Gettys wrote: >... >> "X is an exercise in avoiding system calls". I think I said this around >> 1984-1985. >> - Jim > >I think that applies to all really high-performance servers. Note that it is definitely not always true. Linux system calls are reasonably light-weight. And sometimes trying to avoid them ends up beaing _more_ work - because you might have to worry about synchronization and cache coherency in user mode. So the rule should be "avoid _unnecessary_ system calls". 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: PROBLEM: 2.4.4{ac2} will not boot
On Wed, May 02, 2001 at 12:28:06PM +0100, Alan Cox wrote:
> Envelope-to: gbsadler@localhost
> Subject: Re: PROBLEM: 2.4.4{ac2} will not boot
> To: [EMAIL PROTECTED] (Gordon Sadler)
> Cc: [EMAIL PROTECTED]
> X-Mailer: ELM [version 2.5 PL1]
> From: Alan Cox <[EMAIL PROTECTED]>
>
> > threads that are indicating the same problem, is there still usefulness
> > in trying to capture an oops from 2.4.4? Bit odd that 2.4.4ac2 just
> > blackens my screen, isn't it?
>
> Capturing the 2.4.4 oops is useful
>
>
Ok, late last night (CST) I followed up with the oops->ksymoops from
2.4.4, PROBLEM: 2.4.4 oops, will not boot.
Then I found, downloaded, compiled 2.4.4ac3, oops again.
I still need to repeat with 2.4.4ac3 as I wasn't up to copying the oops
by hand at the time.
Gordon Sadler
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
I got it
Hey, lu Sorry, it took longer than i expected but I found the site, it's http://www.multiopen.com the site will make your web surfing very convenient. And here goes one more, it's http://www.mysimon.com this one will help your online shopping Get to the site and mail me after bye~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 ??
>> 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. What about isa_ioremap ? Result from it is a token passed to isa_readx/isa_writex and the arch side can be implemented with a couple of #defines on x86. It's easy to change I beleive, and it paves the way for archs to add a notion of "token" in the high bits (as we _know_ an ISA address is small). Those token can be used by arch to route to proper PCI bus when several host bridges exist, to route to PCMCIA when the PCMCIA uses it's own "ISA" memory space like on PPC, etc... Later on, we can see things like ulong pci_get_bus_isa_base(int busno); And the same for PCMCIA & whatever 16 bits busses that can exist on embedded hardware. That way, support for multiple busses (either real ISA, embedded custom busses using legacy devices, several PCI hosts with ISA bridges, ...) can be implemented very easily. In most case adjusting the drivers probe code. I'd like to see the same kind of things for IOs in fact but that's another debate ;) Regards, Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
netperf stream scaling; patches that help?
I'm trying to run a simple test on a pair of Linux 2.4.2 PC's that starts up simultaneous netperf tcp stream tests, and find that I cant invoke more that 800 without running into memory allocation failures. This wouldnt be strange except that I find on the same systems, FreeBSD seems to do twice as well (1600). I complete 500 concurrent netperf tcp stream tests sending 64 byte packets successfully, but again, FreeBSD completes a 1000 successfully. Also, Linux appears to hog around 300MB on the server side, whereas FreeBSD only appears to be using 3MB. Those are the bare numbers, details available, of course, but what I'd like to do is repeat the Linux test with 2.4.4 and include some VM patches that might possibly alleviate any memory management issues I may be running into. This is between a 500MHz PIII Katmai and 333MHz PII Deschutes both with 512MB memory, over a 100Mb (3C905C) private nw. I'd appreciate any pointers to patches that might help, or suggestions in general to improve the Linux numbers. Especially any insight into whether this is a case of apples/oranges or whether I'm missing some trivial element here... I know of Ed Tomlinson's patch posted on this list on 4/12, are there any others? I know Jonathan Morton posted some OOM patches, are those included in 2.4.4? thanks, Nivedita --- Nivedita Singhvi(503) 578-4580 Linux Technology Center [EMAIL PROTECTED] IBM Beaverton, OR [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: Linux Kernel Debuggers, KDB or KGDB?
Jeff Dike ([EMAIL PROTECTED]) said: > > > Is this sufficient to do driver development? TUN/TAP doesn't let me > > > write > > > ethernet drivers inside UML. > > For ISDN not really. For SCSI yes - scsi generic would let you write a > > virtual scsi adapter 'owning' some physical devices > > Fine, so go ahead and write a UML SCSI adapter... > > I would love to see this happen. If you need UML help that's not on the site, > let me know, and I'll be happy to do what I can. There is the simulator SCSI, net, and serial drivers in the ia64 tree. Dunno how similar that would be to what you need. Bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: serial console problems with 2.4.4
On 02 May 2001 10:37:21 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Fabrice Gautier <[EMAIL PROTECTED]> writes:
> > So this this probably a sulogin/mingetty problem. They should set the
> > CREAD flag in your tty c_cflag.
> >
> > the patch for busybox repalced the line
> > tty.c_cflag |= HUPCL|CLOCAL
> > by
> > tty.c_cflag |= CREAD|HUPCL|CLOCAL
> >
> > Hope this help.
>
> This part is correct.
>
> However the kernel sets CREAD by default.
Are your sure? Wasn't this the behaviour for 2.4.2 but changed in 2.4.3
> sysvinit (and possibly other inits) clears CREAD.
In my case I was using busybox as init. So there is no sysinit or any other
init called before this line.
> I wish I knew where the breakage actually occured.
Just look at this diff on serial.c between 2.4.2 and 2.4.3:
--- serial.cSat Apr 21 17:22:53 2001
+++ ../../../linux-2.4.2/drivers/char/serial.c Sat Feb 17 01:02:36 2001
@@ -1764,8 +1765,8 @@
/*
* !!! ignore all characters if CREAD is not set
*/
-// if ((cflag & CREAD) == 0)
-// info->ignore_status_mask |= UART_LSR_DR;
+ if ((cflag & CREAD) == 0)
+ info->ignore_status_mask |= UART_LSR_DR;
save_flags(flags); cli();
if (uart_config[info->state->type].flags & UART_STARTECH) {
serial_outp(info, UART_LCR, 0xBF);
--
Fabrice Gautier <[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: Kernel build problem (2.4.1)...
On Wed, 2 May 2001, Daniel Howe wrote: > ld: cannot open binary: No such file or directory Fairly old problem. http://marc.theaimsgroup.com/?l=linux-kernel=98478655301837=2 Please check list archives to see if issues have previously been addressed. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 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 ??
I wrote this some times ago when playing with caches. Compile cctlmod.c as
a module, insert it to kernel, and use con and coff to enable and disable
caches.
Note that the code is quite old, maybe it doesn't work with 2.4 kernels,
and I don't want support it. If it doesn't work, fix it yourself.
Mikulas
#include
#include
#define __NR_disable_cache 250
#define __NR_enable_cache 251
#define __NR_disable_cache_wt 252
#define __NR_disable_page_cache 253
#define __NR_enable_page_cache 254
_syscall0(int, disable_cache)
_syscall0(int, enable_cache)
_syscall0(int, disable_cache_wt)
_syscall1(int, disable_page_cache, void *, page)
_syscall1(int, enable_page_cache, void *, page)
#define MODULE
#define __KERNEL__
#include
#include
#include
#include
#include
#include
extern void *sys_call_table[];
flush_t()
{
__asm__ __volatile__ (
"movl %%cr3, %%eax\n\t"
"movl %%eax, %%cr3\n\t"
:::"ax", "cc");
}
disable_cache()
{
__asm__ __volatile__ (
"cli\n\t"
"movl %%cr0, %%eax\n\t"
"orl $0x6000, %%eax\n\t"
"movl %%eax, %%cr0\n\t"
"wbinvd\n\t"
"sti\n\t"
:::"ax", "cc");
return 0;
}
enable_cache()
{
__asm__ __volatile__ (
"cli\n\t"
"movl %%cr0, %%eax\n\t"
"andl $0x9fff, %%eax\n\t"
"movl %%eax, %%cr0\n\t"
"wbinvd\n\t"
"sti\n\t"
:::"ax", "cc");
return 0;
}
disable_cache_wt()
{
__asm__ __volatile__ (
"cli\n\t"
"movl %%cr0, %%eax\n\t"
"andl $0xdfff, %%eax\n\t"
"orl $0x4000, %%eax\n\t"
"movl %%eax, %%cr0\n\t"
"wbinvd\n\t"
"sti\n\t"
:::"ax", "cc");
return 0;
}
disable_page_cache(unsigned long pg)
{
pte_t *pte = pte_offset(pmd_offset(pgd_offset(current->mm, pg), pg), pg);
*(unsigned *)pte |= 0x18;
flush_t();
return 0;
}
enable_page_cache(unsigned long pg)
{
pte_t *pte = pte_offset(pmd_offset(pgd_offset(current->mm, pg), pg), pg);
*(unsigned *)pte &= ~0x18;
flush_t();
return 0;
}
init_module()
{
sys_call_table[250] = disable_cache;
sys_call_table[251] = enable_cache;
sys_call_table[252] = disable_cache_wt;
sys_call_table[253] = disable_page_cache;
sys_call_table[254] = enable_page_cache;
return 0;
}
cleanup_module()
{
sys_call_table[250] = sys_call_table[251] = sys_call_table[252] = 0;
sys_call_table[253] = sys_call_table[254] = 0;
}
#include "cctl.h"
main()
{
if (enable_cache()) perror("enable_cache"), exit(1);
return 0;
}
#include "cctl.h"
main()
{
if (disable_cache()) perror("disable_cache"), exit(1);
return 0;
}
Parport_pc compile errors in 2.4.4
All,
I have encountered a compile error in 2.4.4.
The autoirq and autodma parameters that were added (in 2.4.3-ac2)
to parport_pc_init_superio are missing from the else
side of the #ifdef CONFIG_PCI
I _think_ this patch should fix it.
PATCH against 2.4.4
*** linux/drivers/parport/parport_pc.c.orig Wed May 2 13:18:00 2001
--- linux/drivers/parport/parport_pc.cWed May 2 13:19:02 2001
***
*** 2576,2582
}
#else
static struct pci_driver parport_pc_pci_driver;
! static int __init parport_pc_init_superio(void) {return 0;}
#endif /* CONFIG_PCI */
/* This is called by parport_pc_find_nonpci_ports (in asm/parport.h) */
--- 2576,2582
}
#else
static struct pci_driver parport_pc_pci_driver;
! static int __init parport_pc_init_superio (int autoirq, int autodma)
{return 0;}
#endif /* CONFIG_PCI */
/* This is called by parport_pc_find_nonpci_ports (in asm/parport.h) */
PATCH ENDS
Thanks,
Hal Duston
[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/
Kernel build problem (2.4.1)...
Greetings, I'm having a problem with my running kernel (2.4.1) - attempting to make a boot floppy. make bzDisk(& make bzImage) give the error below - any ideas? Seems like bootsec is missing. I'm running Debian on x86... thanks much, /daniel make[1]: Leaving directory `/usr/src/linux-2.4.1/arch/i386/lib' ld -m elf_i386 -T /usr/src/linux-2.4.1/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pcmcia/pcmcia.o drivers/net/pcmcia/pcmcia_net.o drivers/pnp/pnp.o drivers/video/video.o \ net/network.o \ /usr/src/linux-2.4.1/arch/i386/lib/lib.a /usr/src/linux-2.4.1/lib/lib.a /usr/src/linux-2.4.1/arch/i386/lib/lib.a \ --end-group \ -o vmlinux nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw] \)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | sort > System.map make[1]: Entering directory `/usr/src/linux-2.4.1/arch/i386/boot' ld -m elf_i386 -Ttext 0x0 -s -oformat binary bbootsect.o -o bbootsect ld: cannot open binary: No such file or directory make[1]: *** [bbootsect] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.1/arch/i386/boot' make: *** [bzImage] Error 2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Sun, Apr 29, 2001 at 02:16:43PM -0700, Jim Gettys wrote: ... > "X is an exercise in avoiding system calls". I think I said this around > 1984-1985. > - Jim I think that applies to all really high-performance servers. Definitely it applies to ZMailer, which before did do time(2) some 1000-2 times per second during some high activity bursts (limited essentially by the syscall speed). These days there is shared memory segment into which a server process updates the time value some 2-5 times per sec, and the consumer reads that -- likely now the consumer bursts peak beyond 100 000 reads. I think I took the idea from Interactive IX/386, which had magic global segment mapped to all userspaces for few fast common tasks, including gettimeofday() data. That was around 1990, or a bit before (I switched to Linux soon after.)Where they got the idea from, that I haven't checked. The basic algorithms and ideas we employ to do these wonders are also described by Knuth in his "The Art of Computer Programming" series. And usually he is referring to some earlier publications. > -- > Jim Gettys > Technology and Corporate Development > Compaq Computer Corporation > [EMAIL PROTECTED] /Matti Aarnio <[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: Linux 2.4.4-ac3
On Tue, May 01, 2001 at 10:28:35PM +0100, Alan Cox wrote:
>
> 2.4.4-ac3
Does not compile on Alpha. I have a strange feeling that because
of this:-)
> o Fix module exception race on Alpha (Andrea Arcangeli)
A declaration was forgotten and, comparing with i386 equivalent, this
minor correction is required:
--- linux-2.4.4-ac/arch/alpha/mm/extable.c~ Wed May 2 11:08:43 2001
+++ linux-2.4.4-ac/arch/alpha/mm/extable.c Wed May 2 12:08:50 2001
@@ -36,6 +36,8 @@
register unsigned long gp __asm__("$29");
+extern spinlock_t modlist_lock;
+
static unsigned
search_exception_table_without_gp(unsigned long addr)
{
Michal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Memory management issues with 2.4.4
Short version: Under very heavy thrashing (about four hours) the system either lockups or OOM handler kills a task even when there is swap space left. Long version: My system is a dual 2x200MMX in a Gigabyte 586DX with 96Mb and 226Mb of swap this way: [root@quartz ~]# swapon -s FilenameTypeSizeUsedPriority /dev/hda7 partition 96348 64561 /dev/hdc6 partition 130276 64601 Well, I have tried to compile Mozilla 0.8.1 since the day it came out, but I always lockup in the same place, wich it's begining to be a bit frustrating ;-) The problem is that compiling the file content/base/src/nsStyleContext.o makes cc1plus grow up to a size of 141M, at this point the system is in heavy thrashing, kswapd is using about 7-12% of CPU time and cc1plus is using 8-14%. If I use a SMP kernel the system always ends up frozen, some times after about almost one day of uptime and compiling since booting, and another times it gets frozen in much less time, three or four hours. If I use a non SMP kernel the system doesn't lokup but after some hours, it varies between 6-8h, the cc1plus procces get a kill signal by OOM killer, althought there is plenty of swap space left ((96Mb RAM + 226Mb swap) - (140Mb - tiny amount used by the system) = plenty ;-). For this tries I have left the system in single user, so no cron jobs, no network trafic, no etc... I suspect there is a race in the swap handling in SMP, and that the OOM doesn't take into account the swap space left sometimes. I don't know what to try next, suggestions? -- Jorge Nerin <[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: Linux Kernel Debuggers, KDB or KGDB?
[EMAIL PROTECTED] said: > > Is this sufficient to do driver development? TUN/TAP doesn't let me > > write > > ethernet drivers inside UML. > For ISDN not really. For SCSI yes - scsi generic would let you write a > virtual scsi adapter 'owning' some physical devices Fine, so go ahead and write a UML SCSI adapter... I would love to see this happen. If you need UML help that's not on the site, let me know, and I'll be happy to do what I can. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems even with 512 block size MOs
> Copying a 6.5 MByte file with cp returns nearly immediately on the > commandline, but umount nearly takes forever. Maximum rate detected by > xosview during umount was about 30 kByte. > > I have similar behaviour on another machine and with different disk. However > I don't get any "dmesg" output despite the "CONFIG_SCSI_LOGGING=y" option on > both machines. That sounds like it isnt queueing multiple commands at a time. M/O has an erase/write sequence so you want to queue large blocks otherwise its two rotations per I/O > Are all my MO disks rotten? Are the MO drives broken? Are my SCSI adapters > broken? Or is there a bug in the SCSI layer? SCSI layer or scsi driver I suspect. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Mike Anderson wrote: > > Doug, > > A question on clarification. > > Is the configuration you are testing have both FC adapters going to the same > port of the storage device (mutli-path) or to different ports of the storage > device (mulit-port)? > > The reason I ask is that I thought if you are using SCSI-2 reserves that the > reserve was on a per initiator basis. How does one know which path has the > reserve? Reservations are global in nature in that a reservation with a device will block access to that device from all other initiators, including across different ports on multiport devices (or else they are broken and need a firmware update). > On a side note. I thought the GFS project had up leveled there locking / fencing > into a API called a locking harness to support different kinds of fencing > methods. Any thoughts if this capability could be plugged into this service so > that users could reduce recoding depending on which fencing support they > selected. I wouldn't know about that. -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 ...]
Giacomo Catenazzi <[EMAIL PROTECTED]>: > No. You propmt only one invalid assertion. After you this prompt > you continue to validate rules and you will maybe prompt for another > invalid rules. But these invalid rules are generally infrequent. I may be having problems with your English. I don't think I understand this. > It is very unlikely to have constraint on string or on integer. But > anyway, where is the problem? You simple ask the new value of this > symbol. The problem is that you're now, in effect, telling me to invent a new interactive configurator with different rules than the normal one! This is a horrible swamp to wander into just to avoid making oldconfig users fire up vi occasionally. -- http://www.tuxedo.org/~esr/;>Eric S. Raymond "You have taught us much. Come with us and join the movement." "This movement of yours, does it have slogans?" inquired the Chink. "Right on!" they cried. And they quoted him some. "Your movement, does it have a flag?" asked the Chink. "You bet!" and they described their emblem. "And does your movement have leaders?" "Great leaders." "Then shove it up your butts," said the Chink. "I have taught you nothing." -- Tom Robbins, "Even Cowgirls Get The Blues" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Max TenEyck Woodbury wrote: > > Doug Ledford wrote: > > > > ... > > > > If told to hold a reservation, then resend your reservation request once every > > 2 seconds (this actually has very minimal CPU/BUS usage and isn't as big a > > deal as requesting a reservation every 2 seconds might sound). The first time > > the reservation is refused, consider the reservation stolen by another machine > > and exit (or optionally, reboot). > > Umm. Reboot? What do you think this is? Windoze? It's the *only* way to guarantee that the drive is never touched by more than one machine at a time (notice, I've not been talking about a shared use drive, only one machine in the cluster "owns" the drive at a time, and it isn't for single transactions that it owns the drive, it owns the drive for as long as it is alive, this is a limitation of the filesystes currently available in mainstream kernels). The reservation conflict and subsequent reboot also *only* happens when a reservation has been forcefully stolen from a machine. In that case, you are talking about a machine that has been failed over against its will, and the absolute safest thing to do in order to make sure the failed over machine doesn't screw the whole cluster up, is to make it reboot itself and re-enter the cluster as a new failover slave node instead of as a master node. If you want a shared common access device with write locking semantics, as you seem to be suggesting later on, then you need a different method of locking than what I put in this, I knew that as I wrote it and that was intentional. > Really, You can NOT do clustering well if you don't have a consistent locking > mechanism. The use of a hardware locking method like 'reservation' may be a > good way to avoid race conditions, but it should be backed up by the > appropriate exchange of messages to make sure everybody has the same view of > the system. For example, you might use it like this: > > 1. Examine the lock list for conflicts. If a conflict is found, the lock >request fails. > > 2. Reserve the device with the lock on it. If the reservation fails, delay >a short amount of time and return to 1. > > 3. Update the lock list for the device. > > 4. When the list update is complete, release the reservation. > > In other words, the reservation acts as a spin-lock to make sure updates > occur atomically. Apples to oranges, as I described above. This is for a failover cluster, not a shared data, load balancing cluster. -- Doug Ledford <[EMAIL PROTECTED]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problems even with 512 block size MOs
Hallo recent 2.4 kernels have incredible bad performance for me when handling MO drives. Going back 2.2 shows better performance. This is my setup: SCSI subsystem driver Revision: 1.00 ncr53c8xx: at PCI bus 0, device 15, function 0 ncr53c8xx: 53c810 detected ncr53c810-0: rev 0x2 on pci bus 0 device 15 function 0 irq 16 ncr53c810-0: ID 7, Fast-10, Parity Checking scsi0 : ncr53c8xx-3.4.3-20010212 Vendor: FUJITSU Model: M2513ARev: 1500 Type: Optical Device ANSI SCSI revision: 02 Vendor: PIONEER Model: DVD-ROM DVD-303 Rev: 1.10 Type: CD-ROM ANSI SCSI revision: 02 Detected scsi removable disk sda at scsi0, channel 0, id 0, lun 0 ncr53c810-0-<0,*>: FAST-10 SCSI 10.0 MB/s (100 ns, offset 8) SCSI device sda: 248826 512-byte hdwr sectors (127 MB) sda: Write Protect is off sda: unknown partition table on a non-overclocked Dual celeron BP6 machine with 256MByte RAM hertz:~> uname -a Linux hertz 2.4.4-SMP #2 SMP Wed May 2 17:47:22 MEST 2001 i686 unknown (recent kernel from ftp.suse.com/people/mantel/next) Copying a 6.5 MByte file with cp returns nearly immediately on the commandline, but umount nearly takes forever. Maximum rate detected by xosview during umount was about 30 kByte. I have similar behaviour on another machine and with different disk. However I don't get any "dmesg" output despite the "CONFIG_SCSI_LOGGING=y" option on both machines. Are all my MO disks rotten? Are the MO drives broken? Are my SCSI adapters broken? Or is there a bug in the SCSI layer? Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Doug Ledford wrote: > > ... > > If told to hold a reservation, then resend your reservation request once every > 2 seconds (this actually has very minimal CPU/BUS usage and isn't as big a > deal as requesting a reservation every 2 seconds might sound). The first time > the reservation is refused, consider the reservation stolen by another machine > and exit (or optionally, reboot). Umm. Reboot? What do you think this is? Windoze? Really, You can NOT do clustering well if you don't have a consistent locking mechanism. The use of a hardware locking method like 'reservation' may be a good way to avoid race conditions, but it should be backed up by the appropriate exchange of messages to make sure everybody has the same view of the system. For example, you might use it like this: 1. Examine the lock list for conflicts. If a conflict is found, the lock request fails. 2. Reserve the device with the lock on it. If the reservation fails, delay a short amount of time and return to 1. 3. Update the lock list for the device. 4. When the list update is complete, release the reservation. In other words, the reservation acts as a spin-lock to make sure updates occur atomically. [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: DISCOVERED! Cause of Athlon/VIA KX133 Instability
On Tue, 1 May 2001, Seth Goldberg wrote: > > > 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? > Because lspci does not display all 256 bytes of pci configuration > information. Say what? Try lspci -vvxxx -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/
bug: can't mount -o loop or -t nfs in 2.4.4, 2.4.4-ac2
2.4.4-pre7 worked fine. situation: mounting a remote nfs share or a loopback local filesystems doesn't work. it doesn't crash the system, the userspace process just hangs on the mount() call. all of these hang: # mount -o loop /my/ext2/image /mnt/ext2 # mount -o loop /my/fat16/image /mnt/fat16 # mount -o loop /my/iso9660/image /mnt/iso # mount other.system:/export /import mounting local drives works fine, as long as it isn't nfs - i can mount my ext2 and vfat drives, but not a local export on the same local machine. i can give strace output if desired. please help! thanks! joe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] Re: Linux NAT questions- (kernel upgrade??)
"Sim, CT (Chee Tong)" schrieb: > Hi.. I follow your instruction, but I encounter this issue, my kernel need > to be upgrade? MAy I know how to determine the current kernel version uname -a > and > how to upgrade it?? Either upgrade to a distro that includes the new kernel (e.g. latest SuSE or Red Hat) or download kernel source and compile. It might be helpful to provide the distribution and version you are using (Red Hat 6.2, Slackware 7, Debian Potato, etc) > [root@guava /root]# iptables -t nat -A PREROUTING -p tcp --dst 1.1.1.160 -i > eth1 -j D > NAT --to-destination 192.168.200.2 > iptables v1.1.1: can't initialize iptables table `nat': iptables who? (do > you need to insm > od?) > Perhaps iptables or your kernel needs to be upgraded. > > [root@guava simc]# rpm -ivh iptables-1_2_0-6_i386.rpm > error: failed dependencies: > kernel >= 2.4.0 is needed by iptables-1.2.0-6 Yes, of course iptables won't work with the old kernel. If you want to stay with the old kernel, you must use ipchains instead. cu Jup - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux Cluster using shared scsi
Doug, A question on clarification. Is the configuration you are testing have both FC adapters going to the same port of the storage device (mutli-path) or to different ports of the storage device (mulit-port)? The reason I ask is that I thought if you are using SCSI-2 reserves that the reserve was on a per initiator basis. How does one know which path has the reserve? On a side note. I thought the GFS project had up leveled there locking / fencing into a API called a locking harness to support different kinds of fencing methods. Any thoughts if this capability could be plugged into this service so that users could reduce recoding depending on which fencing support they selected. Thanks, -Mike Doug Ledford [[EMAIL PROTECTED]] wrote: > > > > To: [EMAIL PROTECTED] > cc: James Bottomley <[EMAIL PROTECTED]>, "Roets, Chris" > <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > [EMAIL PROTECTED] > > > > > > "Eric Z. Ayers" wrote: > > > > Doug Ledford writes: > > (James Bottomley commented about the need for SCSI reservation kernel > patches) > > > > > > I agree. It's something that needs fixed in general, your software > needs it > > > as well, and I've written (about 80% done at this point) some open > source > > > software geared towards getting/holding reservations that also > requires the > > > same kernel patches (plus one more to be fully functional, an ioctl to > allow a > > > SCSI reservation to do a forced reboot of a machine). I'll be > releasing that > > > package in the short term (once I get back from my vacation anyway). > > > > > > > Hello Doug, > > > > 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. > > It doesn't have to. The kernel changes are minimal (basically James' SCSI > reset patch that he's been carrying around, the scsi reservation conflict > patch, and I need to write a third patch that makes the system optionally > reboot immediately on a reservation conflict and which is controlled by an > ioctl, but I haven't done that patch yet). All of the rest is implemented > in > user space via the /dev/sg entries. As such, it doesn't have any more > information about bus resets than you do. However, because of the policy > enacted in the code, it doesn't need to. Furthermore, because there are so > many ways to loose a reservation silently, it's foolhardy to try and keep > reservation consistency any way other than something similar to what I > outline > below. > > The package is meant to be a sort of "scsi reservation" library. The > application that uses the library is responsible for setting policy. I > wrote > a small, simple application that actually does a decent job of implementing > policy on the system. The policy it does implement is simple: > > If told to get a reservation, then attempt to get it. If the attempt is > blocked by an existing reservation and we aren't suppossed to reset the > drive, > then exit. If it's blocked and we are suppossed to reset the drive, then > send > a device reset, then wait 5 seconds, then try to get the reservation. If > we > again fail, then the other machine is still alive (as proven by the fact > that > it re-established its reservation after the reset) and we exit, else we now > have the reservation. > > If told to forcefully get a reservation, then attempt to get it. If the > attempt fails, then reset the device and try again immediately (no 5 second > wait), if it fails again, then exit. > > If told to hold a reservation, then resend your reservation request once > every > 2 seconds (this actually has very minimal CPU/BUS usage and isn't as big a > deal as requesting a reservation every 2 seconds might sound). The first > time > the reservation is refused, consider the reservation stolen by another > machine > and exit (or optionally, reboot). > > The package is meant to lock against itself (in other words, a malicious > user > with write access to the /dev/sg entries could confuse this locking > mechanism, > but it will work cooperatively with other copies of itself running on other > machines), the requirements for the locking to be safe are as follows: > > 1) A machine is not allowed to mount or otherwise use a drive in any way > shape or form until it has successfully acquired a reservation. > > 2) Once a machine has a reservation, it is not allowed to ever take any > action to break another machines reservation, so that if the reservation is > stolen, this machine is required to "gracefully" step away from the drive > (rebooting is the best way to accomplish this since even the act of > unmounting > the drive will attempt to write to it). > > 3) The timeouts in the program must be honored (resend your reservation, > when > you hold it, every 2 seconds so that a passive attempt to steal the >
Re: Wrong free inodes count in kernels 2.0 and 2.2
On Wed, 2 May 2001, [iso-8859-1] Samuli Kärkkäinen wrote: > I get repeatably both in 2.0 and 2.2 serieses of kernels the following kind > of errors: > > 2.2 kernels (several, including 2.2.18): > EXT2-fs error (device ide1(22,6)): ext2_check_inodes_bitmap: Wrong free inodes >count in group 768, stored = 984, counted = 717 > EXT2-fs error (device ide1(22,6)): ext2_check_inodes_bitmap: Wrong free inodes >count in group 769, stored = 1005, counted = 717 > EXT2-fs error (device ide1(22,6)): ext2_check_inodes_bitmap: Wrong free inodes >count in group 777, stored = 998, counted = 901 > [ many similar lines deleted ] > > and sometimes with 2.2 kernel, soon after the errors above: > EXT2-fs error (device ide1(22,1)): ext2_new_inode: Free inodes count corrupted in >group 414 > last message repeated 795 times We were getting this error on 4 of our arrays. We weren't able to track down the original error, but the continuing problem turned out to be that in "correcting" the errors fsck did not restore the drive to a stable state and it would eventually corrupt itself again. If this is the same problem, force fsck until it no longer finds any errors on the drive. Jay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-ac3 +IPX -SYSCTL compile fix
Em Wed, May 02, 2001 at 11:17:22AM -0400, Pavel Roskin escreveu: > > +#error This file shouldn't be compiled without CONFIG_SYSCTL defined > > Oops, sorry! Unterminated string constant in preprocessor. It should be > > #error This file should not be compiled without CONFIG_SYSCTL defined > > The patch at http://www.red-bean.com/~proski/linux/ipxsysctl.diff has been > updated. ok, I'm looking at this and including in the patch I'm about to send. - 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: Linux Kernel Debuggers, KDB or KGDB?
> > Everything is there. SCSI and ISDN have the equivalent devices of the > > "lo" driver for the networking layer. Or the equivalent of tun/tap > > devices for the ethernet layer. > > Is this sufficient to do driver development? TUN/TAP doesn't let me write > ethernet drivers inside UML. For ISDN not really. For SCSI yes - scsi generic would let you write a virtual scsi adapter 'owning' some physical devices - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Let init know user wants to shutdown
Pavel Machek <[EMAIL PROTECTED]> writes: > > > > I'm wondering if that veto business is really needed. Why not reject > > > > *all* APM rejectable events, and then let the userspace event handler > > > > send the system to sleep or turn it off? Anybody au fait with the APM > > > > spec? > > > > > > Because apmd is optional > > > > The veto stuff only comes into action, iff someone has registered as > > willing to exercise this power. We would not break compatibility with > > any std kernel by instead having a apmd send a "reject all" ioctl > > instead, and so deal with events without having the pressure of having > > to reject or accept them, and let us remove all the veto code from the > > kernel driver. Or am I missing something? > > No, this looks reasonable. What do you think Stephen and Avery? Are you happy with this idea? If anybody wants to test it, my latest pmevent patch will reject *all* APM events it can. It would be easy to adapt that to turn on and off with an ioctl. I am happy to do that if Stephen would accept it. (Personally would like it if events were rejected by default but that breaks backward compatibility and there is always someone who would get bitten.) The latest pmevent patch (v3) with various APM cleanups is available at http://ape.n3.net/programs/linux/offbutton/download Note that it currently shares no code with the pmpolicy patch. For more information see http://ape.n3.net/programs/linux/offbutton/ -- http://ape.n3.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: Linux Kernel Debuggers, KDB or KGDB?
[EMAIL PROTECTED] said: > Everything is there. SCSI and ISDN have the equivalent devices of the > "lo" driver for the networking layer. Or the equivalent of tun/tap > devices for the ethernet layer. Is this sufficient to do driver development? TUN/TAP doesn't let me write ethernet drivers inside UML. > It just have to be an config.in option in UML and every other adapters > switched off. This is a matter of fiddling the config process. It might not be easy, but there isn't much doubt that it's possible :-) > The problem is: I still do not really get how UML really works. Many > of the mapping rules (Kernel machanism on normal arch -> UML) are not > quite clear to me. > Is there a paper or sth. like that describing the design a bit more in > detail? I only found usage papers on the user-mode-linux home page. First, have a look at the USB patch at http://user-mode-linux.sourceforge.net/p atches/uml-hcd-2.4.3.patch My ALS paper has a description of how UML basically works inside and it's not too much out of date - http://user-mode-linux.sourceforge.net/als2000/index.htm l Also, my ALS and LCA slides have this sort of information - http://user-mode-linux.sourceforge.net/slides/als2000/slides.html http://user-mode-linux.sourceforge.net/slides/lca2001/lca.html The LCA slides are probably better. They are from a few months later, and I had a longer slot, so I needed more slides. If you have questions which aren't answered on my site, send me mail. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Wrong free inodes count in kernels 2.0 and 2.2
I get repeatably both in 2.0 and 2.2 serieses of kernels the following kind of errors: 2.0 kernels (at least 2.0.39): EXT2-fs error (device 03:04): ext2_check_inodes_bitmap: Wrong free inodes count in group 576, stored = 1956, counted = 1942 EXT2-fs error (device 03:04): ext2_check_inodes_bitmap: Wrong free inodes count in group 577, stored = 1951, counted = 1942 EXT2-fs error (device 03:04): ext2_check_inodes_bitmap: Wrong free inodes count in group 94, stored = 1921, counted = 1919 [ many similar lines deleted ] 2.2 kernels (several, including 2.2.18): EXT2-fs error (device ide1(22,6)): ext2_check_inodes_bitmap: Wrong free inodes count in group 768, stored = 984, counted = 717 EXT2-fs error (device ide1(22,6)): ext2_check_inodes_bitmap: Wrong free inodes count in group 769, stored = 1005, counted = 717 EXT2-fs error (device ide1(22,6)): ext2_check_inodes_bitmap: Wrong free inodes count in group 777, stored = 998, counted = 901 [ many similar lines deleted ] and sometimes with 2.2 kernel, soon after the errors above: EXT2-fs error (device ide1(22,1)): ext2_new_inode: Free inodes count corrupted in group 414 last message repeated 795 times The hosts running 2.0 and 2.2 kernels are completely separate. Also, all hardware in the 2.2 box have been changed at least once, most components more than that, and that hasn't affected the situation. There has been both P2 and Athlon CPU's. These errors start appearing when I have run my backup script about 10 times. They never show up before the script has been ran for about that many times, and they always show up eventually. I have recreated the filesystem several times, when trying different things to fix the problem, and the problem always comes back. The backup script is essentially like this: initial run: cp -ax / /backup/backup1 next night first differential: cp -al /backup/backup1 /backup/backup2 rsync --archive --hard-links --whole-file --sparse --one-file-system --delete --force / /backup/backup2 following night second differential: cp -al /backup/backup2 /backup/backup3 rsync --archive --hard-links --whole-file --sparse --one-file-system --delete --force / /backup/backup3 And so on. The result is that directories /backup/backupX each contain a snapshot of the filesystem to be backed up, in this case the root filesystem, with unchanged files hardlinked to the previous backups. The hosts where this occurs have only one thing in common, namely that the backups are made on IDE disks with ext2 filesystem. I also run this on a third box, which has 2.0 kernel and SCSI disks, and the problem doesn't occur there. Both boxes where the errors occur have otherwise no problems. dumpe2fs says about the 2.0 box: Filesystem volume name: Last mounted on: Filesystem UUID: c98e333c-0dbd-11d5-8297-00e02909a9a6 Filesystem magic number: 0xEF53 Filesystem revision #:0 (original) Filesystem features: (none) Filesystem state: clean with errors Errors behavior: Continue Filesystem OS type: Linux Inode count: 10733568 Block count: 42933712 Reserved block count: 2146685 Free blocks: 23202851 Free inodes: 10052554 First block: 1 Block size: 1024 Fragment size:1024 Blocks per group: 8192 Fragments per group: 8192 Inodes per group: 2048 Inode blocks per group: 256 Last mount time: Wed May 2 00:00:02 2001 Last write time: Wed May 2 00:41:50 2001 Mount count: 18 Maximum mount count: 180 Last checked: Wed Apr 18 07:53:30 2001 Check interval: 15552000 (6 months) Next check after: Mon Oct 15 07:53:30 2001 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) and about the 2.2 box: Filesystem volume name: Last mounted on: Filesystem UUID: e74e4331-4057-40a2-a62c-a4d195918c3a Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: filetype sparse_super Filesystem state: clean with errors Errors behavior: Continue Filesystem OS type: Linux Inode count: 2009088 Block count: 16064968 Reserved block count: 803248 Free blocks: 2213966 Free inodes: 1094493 First block: 1 Block size: 1024 Fragment size:1024 Blocks per group: 8192 Fragments per group: 8192 Inodes per group: 1024 Inode blocks per group: 128 Last mount time: Wed May 2 00:00:00 2001 Last write time: Wed May 2 00:42:32 2001 Mount count: 31 Maximum mount count: 20 Last checked: Tue Apr 3 08:25:35 2001 Check interval: 15552000 (6 months) Next check after: Sun Sep 30 08:25:35 2001 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group
Hello_Linux_Kernel_World()
Hello ()
{
How_are_you();
}
stupid but works.
<-*-*- This is not my real name, I am undercover -*-*->
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: serial console problems with 2.4.4
Fabrice Gautier <[EMAIL PROTECTED]> writes: > On Wed, 02 May 2001 11:54:11 +0200 > Reto Baettig <[EMAIL PROTECTED]> wrote: > > > Hi > > > > I just installed 2.4.4 on our alpha SMP boxes (ES40) and now I have > > problems with the serial console: > > I get same kind of problem when upgrading from 2.4.2 to 2.4.3 and using > busybox as init/getty > > The problem was a bug in busybox. The console initialisation code was > not correct. > > > > sulogin does not accept input from the serial line > > mingetty does not accept input from the serial line > > agetty works fine > > So this this probably a sulogin/mingetty problem. They should set the > CREAD flag in your tty c_cflag. > > the patch for busybox repalced the line > tty.c_cflag |= HUPCL|CLOCAL > by > tty.c_cflag |= CREAD|HUPCL|CLOCAL > > Hope this help. This part is correct. However the kernel sets CREAD by default. sysvinit (and possibly other inits) clears CREAD. I wish I knew where the breakage actually occured. And then sulogin/mingetty need to reenable it. It's not too big of a deal except the serial code doesn't accept SAK's when CREAD is clear. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Hi Doug, Great to hear your progress on this. As I had not heard anything about this effort since this time last year I had assumed you put this project on the shelf. I will be happy to test these interfaces when they are ready. Eddie > "Eric Z. Ayers" wrote: > > > > Doug Ledford writes: > > (James Bottomley commented about the need for SCSI reservation kernel patches) > > > > > > I agree. It's something that needs fixed in general, your software needs it > > > as well, and I've written (about 80% done at this point) some open source > > > software geared towards getting/holding reservations that also requires the > > > same kernel patches (plus one more to be fully functional, an ioctl to allow a > > > SCSI reservation to do a forced reboot of a machine). I'll be releasing that > > > package in the short term (once I get back from my vacation anyway). > > > > > > > Hello Doug, > > > > 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. > > It doesn't have to. The kernel changes are minimal (basically James' SCSI > reset patch that he's been carrying around, the scsi reservation conflict > patch, and I need to write a third patch that makes the system optionally > reboot immediately on a reservation conflict and which is controlled by an > ioctl, but I haven't done that patch yet). All of the rest is implemented in > user space via the /dev/sg entries. As such, it doesn't have any more > information about bus resets than you do. However, because of the policy > enacted in the code, it doesn't need to. Furthermore, because there are so > many ways to loose a reservation silently, it's foolhardy to try and keep > reservation consistency any way other than something similar to what I outline > below. > > The package is meant to be a sort of "scsi reservation" library. The > application that uses the library is responsible for setting policy. I wrote > a small, simple application that actually does a decent job of implementing > policy on the system. The policy it does implement is simple: > > If told to get a reservation, then attempt to get it. If the attempt is > blocked by an existing reservation and we aren't suppossed to reset the drive, > then exit. If it's blocked and we are suppossed to reset the drive, then send > a device reset, then wait 5 seconds, then try to get the reservation. If we > again fail, then the other machine is still alive (as proven by the fact that > it re-established its reservation after the reset) and we exit, else we now > have the reservation. > > If told to forcefully get a reservation, then attempt to get it. If the > attempt fails, then reset the device and try again immediately (no 5 second > wait), if it fails again, then exit. > > If told to hold a reservation, then resend your reservation request once every > 2 seconds (this actually has very minimal CPU/BUS usage and isn't as big a > deal as requesting a reservation every 2 seconds might sound). The first time > the reservation is refused, consider the reservation stolen by another machine > and exit (or optionally, reboot). > > The package is meant to lock against itself (in other words, a malicious user > with write access to the /dev/sg entries could confuse this locking mechanism, > but it will work cooperatively with other copies of itself running on other > machines), the requirements for the locking to be safe are as follows: > > 1) A machine is not allowed to mount or otherwise use a drive in any way > shape or form until it has successfully acquired a reservation. > > 2) Once a machine has a reservation, it is not allowed to ever take any > action to break another machines reservation, so that if the reservation is > stolen, this machine is required to "gracefully" step away from the drive > (rebooting is the best way to accomplish this since even the act of unmounting > the drive will attempt to write to it). > > 3) The timeouts in the program must be honored (resend your reservation, when > you hold it, every 2 seconds so that a passive attempt to steal the > reservation will see you are still alive within the 5 second timeout and leave > you be, which is a sort of heartbeat in and of itself). > > Anyway, as I said in my previous email, it's about 80% complete. It currently > is up and running on SCSI-2 LUN based reservations. There is code to do > SCSI-2 and SCSI-3 extent based reservations but it hasn't been tested due to > lack of devices that support extent based reservations (my test bed is a > multipath FC setup, so I'm doing all my testing on FC drives over two FC > controllers in the same machine). I've still got to add the SCSI-3 Persistent > Reservation code to the library (again, I'm lacking test drives for this > scenario). The library itself requires that the
Re: 2.4.4 code breaks compile of VMWare network bridging
"Mohammad A. Haque" wrote: > This was answered several hours ago. Check the list archives. --- Many thanks -- it was in my neverending backlog -l - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
