Re: ext3-2.4-0.9.0
On Sunday July 8, [EMAIL PROTECTED] wrote:
>
> Could well be. ext3 will happily feed 2,000 buffers into submit_bh()
> prior to running tq_disk. Everything else is happy with this, so I blame
> nfsd and raid5 :) Rapid fsyncs will break this up, however.
>
raid5 is definately happy with large sequences of requests between
tq_disk (infact, that is best), but I think I have found a situation
where lots of small requests can confuse it. It seems that your
intuation about the direction of blame is better than mine :-)
Then a write request happens to raid5, the queue is (potentially)
plugged, and then the request is (potentially) queued, and there is a
window between the two where the queue can be unplugged by another
process. If this happens, then the tq_disk run the follows the write
request will not wake-up the raid5d, so the raid5 queue will not be
run, and the request will just sit there until something else causes
raid5d to run.
I'm guessing that ext3 imposes more sequencing on requests than ext2
does, and so it is easier for one request being stalled to stall the
whole filesystem.
In any case, the follow patch against raid5 seems to have relieved the
situation, but more testing is underway.
So ThankYou to ext3 for helping to find a bug in raid5 :-)
NeilBrown
--- drivers/md/raid5.c 2001/07/07 06:23:02 1.1
+++ drivers/md/raid5.c 2001/07/08 00:22:52
@@ -66,9 +66,10 @@
BUG();
if (atomic_read(>active_stripes)==0)
BUG();
- if (test_bit(STRIPE_DELAYED, >state))
+ if (test_bit(STRIPE_DELAYED, >state)) {
list_add_tail(>lru, >delayed_list);
- else if (test_bit(STRIPE_HANDLE, >state)) {
+ md_wakeup_thread(conf->thread);
+ } else if (test_bit(STRIPE_HANDLE, >state)) {
list_add_tail(>lru, >handle_list);
md_wakeup_thread(conf->thread);
} else {
@@ -1167,10 +1168,9 @@
raid5_activate_delayed(conf);
- if (conf->plugged) {
+ if (conf->plugged)
conf->plugged = 0;
- md_wakeup_thread(conf->thread);
- }
+ md_wakeup_thread(conf->thread);
spin_unlock_irqrestore(>device_lock, flags);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
trying again.
Hello to all. I'm sorry if this is the wrong list to post this question to, but I did 4 days ago, and haven't seen anything concerning my problem. I have a Ricoh mp7120a cdrw drive. Since it is a atapi drive, i must use ide-scsi and sg to use it with cdrecord. However there is a strange problem with the audio cd players. After issuing a command to stop an audio cd from playing, two play commands are required to start the cd playing again. This doesn't happen if I use the ide-cd driver, and point /dev/cdrom to /dev/hdc. There is no documentation at all on ide-scsi, and I can't find any error messages anywhere. I have the following append command in lilo.conf append="hdc=ide-scsi" If someone is working on this, or has any idea as to what's happening, I would sure appreciate it. I am using kernel version 2.2.19. this also occurred with 2.2.18. the audio cd players return no error messages at all. when the first play command is issued after a stop command, I just get the shell prompt back with nothing happening to the cd-rw drive at all, until I ether open and close the drive, or issue a second play command. If I open and close the drive between stop and play commands, it plays the cd every time. Thanks. -- Rick Hayner [EMAIL PROTECTED] Member spebsqsa, Baritone Kalamazoo Mall City Chorus. Amateur radio station wa8jqv - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: OOM: A Success Report
> Moreover, when swap is of, the hard disk > goes crazy as if it where using swap, when in fact it isn't). Is this > expected behaviour ? Yes, it's recovering memory by dropping program text pages (memory mapped from elf files) so those have to be reloaded when the program executes them again. -- 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/
PATCH: linux-2.4.7-pre3/drivers/char/sonypi.c would hang some non-Sony notebooks
The pci_device_id tables in linux-2.4.7-pre3/drivers/char/sonypi.c
claims that the driver wants to be loaded on all computers that have
an that have a PCI device with vendor id PCI_VENDOR_ID_INTEL and
a device ID of either PCI_DEVICE_ID_INTEL_82371AB_3 (0x7110) or
PCI_DEVICE_ID_INTEL_82801BA_10 (0x244c). My Kapok 1100m notebook
computer has an Intel 82371ab, so the sonypi module automatically
loads at boot time and hangs the computer.
sonypi_init_module needs to do some kind of test to figure out
if it is on a Sony Vaio and abort otherwise. Looking at the result of
"lspci -v" on my Sony Vaio Picturebook, I see that, while none of the
PCI devices have Sony's vendor ID, a number of them have Sony's
vendor ID as their subsystem vendor ID's. So, I have implemented the
following test to cause sonypi only to be loadable on machines that
have at least one PCI device that has a subsystem vendor ID of
PCI_VENDOR_ID_SONY.
--
Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.4.7-pre3/drivers/char/sonypi.c Sat Jul 7 18:00:12 2001
+++ linux/drivers/char/sonypi.c Sat Jul 7 18:00:28 2001
@@ -690,7 +690,11 @@
};
static int __init sonypi_init_module(void) {
- return pci_module_init(_driver);
+ if (pci_find_subsys(PCI_ANY_ID, PCI_ANY_ID,
+ PCI_VENDOR_ID_SONY, PCI_ANY_ID, NULL) != NULL)
+ return pci_module_init(_driver);
+ else
+ return -ENODEV;
}
static void __exit sonypi_cleanup_module(void) {
Re: ext3-2.4-0.9.0
Neil Brown wrote: > > On Saturday July 7, [EMAIL PROTECTED] wrote: > > An update of the ext3 journalling filesystem for 2.4 kernels > > is available at > > > > http://www.uow.edu.au/~andrewm/linux/ext3/ > > > > Patches are against 2.4.6-ac1 and 2.4.6. > > I thought it was time to try out ext3 between nfsd and raid5, so I > built 2.4.6 plus this patch, and an ext3 filesystem on a largish > raid5 volume, exported it (with the "sync" flag), mounted it from > another machines with NFSv2, and ran "dbench 4". > > This produces a live-lock (I think that it the right term). > Throughput would drop to zero (determined by watching the counts in > /proc/nfs/rpc/nfsd), but could be coaxed along by generating other > filesystem activity. > > I tried nfs over ext3 on a plain ide disc and it worked fine. > I tried dbench directly on ext3/raid5 and it worked fine. > I tried dbench/nfs/ext2/raid5 and it worked fine. > > So I think it is some interaction between ext3fs and raid5 triggered > by the high rate of "fsync" calls made by nfsd. Naturally I blame > ext3 because I know more about raid5 and nfsd :-) fsync will cause ext3 to commit the current transaction once all handles against it close - so that will produce rapid bursts of small numbers of writes. > One particular aspect of raid5 that *could* be related is that it is > very reticent to schedule write requests. It tries to hang on the them > as long as possible in the hope of getting more write requests in the > same stripe. My guess as to what is happening is that as write > request is submitted and then waited-for without an intervening > run_task_queue(_disk); Could well be. ext3 will happily feed 2,000 buffers into submit_bh() prior to running tq_disk. Everything else is happy with this, so I blame nfsd and raid5 :) Rapid fsyncs will break this up, however. Does this patch help? --- fs/jbd/commit.c 2001/07/01 04:24:42 1.40 +++ fs/jbd/commit.c 2001/07/08 00:53:42 @@ -202,6 +202,7 @@ spin_unlock(_datalist_lock); unlock_journal(journal); ll_rw_block(WRITE, bufs, wbuf); + run_task_queue(_disk); lock_journal(journal); journal_brelse_array(wbuf, bufs); goto write_out_data; @@ -410,6 +411,7 @@ bh->b_end_io = end_buffer_io_sync; submit_bh(WRITE, bh); } + run_task_queue(_disk); lock_journal(journal); /* Force a new descriptor to be generated next > When the system is livelocked, all I can tell at the moment (I am at > home and the console is at work so I cannot use alt-sysrq) is that > kjournal is waiting in wait_on_buffer and an nfsd thread is waiting on > the journal. That sounds like Something Wierd is going on. wait_on_buffer will unplug and the disks should be going hell-for-leather. > I will try to explore it more deeply next time I am at work, but if > there are any suggestions as to what it might be, or how I might more > easily find out what is going on, I am all ears. > I'll see if I can get it to happen here. 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/
modem problem solved
Solved with new ppp. Thanks, and sorry. --- My modems (Courier 28.8 external, Actiontec PCI call waiting non-winmodem) connect to the Internet fine with 2.4.0, and broke around 2.4.1. What happens is they dial out, make those sounds, and just as they seem to be about to connect, they disconnect. I'm pretty sure both kernels are configured correctly. This still occurs with kernel 2.4.6. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How to change a module to a character device driver
Hi, all, I am new to linux device driver. I do not know how to change a module to a character device driver. I have a module by hand, I want to modify it to a character device driver. Then I can make it in linux kernel, and do not need modutils rpm. If someone knows, please help me. Thanks! Barry __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
TCP_DEFER_ACCEPT
i was digging around for info on TCP_DEFER_ACCEPT and found this claim in the thttpd mailing list archive: > Alexey Kuznestov mentioned to me that on SMP servers, this option may > not be desired as it creates a new contention point is this still the case? i haven't played with it yet, but i was going to add it to apache-2.0's portability layer (which already has freebsd's SO_ACCEPTFILTER support). is this one of those cases where kernel gurus would prefer me to put it into apache-2.0 and turn it on regardless of the current performance 'cause you guys think you can fix it? (lately i'm playing only with non-SMP boxes, and my viewpoint is kind of biased :) -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: OOM: A Success Report
On 08 Jul 2001 00:40:51 +, José Luis Domingo López wrote: > > Another interesting thing I noted is the fact (as shown by Robert Love's > message) that oom_kill() seems to kill processes without taking into > account whether the selected process is a full application or just one > of more "threads" in some application. This happened to me when OpenOffice > went crazy and OOM hit, but instead of killing the parent process, it just > killed one of the children and, though OOM recoverd memory, OpenOffice > ended useless. Maybe OOM should have killed the parent in the first place. for whatever reason, i did not even notice this. i guess because evolution itself exited, for some reason (normally if a single component dies, say mail, it just puts a dialog up saying `mail component died'). i think there may be problems with determining what the parent app is, or if there is a parent app. killing the PPID may not always be the answer (but in many cases, like what you gave, is a very good answer). > Final question: a 2.4.4 kernel with no swap activated, and OOM hit (thanks > to a purposedly executed ls ../*/../*/..) takes much more time to recover > than the same setup but with swap activated (exact numbers missing, > sorry). Moreover, when swap is of, the hard disk goes crazy as if it where > using swap, when in fact it isn't). Is this expected behaviour ? i think i recall hearing about this, and the reply was something to the effect of `its known but not wanted'. > If someone wants some test with real numbers, please let me know and > though I'm on vacation, I'll go where I work to make some test :) i forgot to give any stats from my incident. i couldnt access the console (the machine was almost locked, the mouse barely moved), so i dont have any hard numbers. from my gnome applets i see load was approaching 10, memory was (or was close to) 100%, and swap was growing close to 100%. this is kernel 2.4.6-ac2, x86, with 256MB memory, 768MB swap. after the incident memory was done to the bare load with only 30MB of cache and swap was only at about 20MB use. i restarted X but not the system, and all is well. -- Robert M. Love rml at ufl.edu rml at tech9.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: OOM: A Success Report
On Saturday, 07 July 2001, at 18:00:08 -0400, Robert Love wrote: > i thought it would be nice to finally hear something good about the OOM > killer. > [...] > kernel showed: > Out of Memory: Killed process 1296 (evolution-mail). > [...] > Out of Memory: Killed process 1307 (evolution-mail). > I've had both succesful and not-so-sucesful times with 2.4.x's OOM killer. Having looked at oom_kill.c code, from my newbie point of view, it _seems_ that theoretically we try to kill a process too late (that is, in out_of_memory() we report OOM when swap is full AND memory has freepages.min or less 4KB pages left). I've seem some applications cause some memory to be reserved when told to exit normally (i.e. Mozilla). If we are OOM we just have freepages.min pages free, that AFAIK is the first number under /proc/sys/vm/freepages, or 512 KB worth of memory. Maybe this is not enough in some situations, and that colud cause the machine to slow badly trying to kill something that needs free memory, when in fact we have not free memory at all. Another interesting thing I noted is the fact (as shown by Robert Love's message) that oom_kill() seems to kill processes without taking into account whether the selected process is a full application or just one of more "threads" in some application. This happened to me when OpenOffice went crazy and OOM hit, but instead of killing the parent process, it just killed one of the children and, though OOM recoverd memory, OpenOffice ended useless. Maybe OOM should have killed the parent in the first place. Final question: a 2.4.4 kernel with no swap activated, and OOM hit (thanks to a purposedly executed ls ../*/../*/..) takes much more time to recover than the same setup but with swap activated (exact numbers missing, sorry). Moreover, when swap is of, the hard disk goes crazy as if it where using swap, when in fact it isn't). Is this expected behaviour ? If someone wants some test with real numbers, please let me know and though I'm on vacation, I'll go where I work to make some test :) Regards. -- José Luis Domingo López Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM) jdomingo EN internautas PUNTO org => ¿ Spam ? Atente a las consecuencias jdomingo AT internautas DOT org => Spam at your own risk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Large ramdisk crashes 2.4.6
I mailed the list about similar problems with 2.4.5. Since it's still happening now that 2.4.6 is out I decided to send another report. The following will crash my 128 meg x86 running 2.4.6. mke2fs /dev/ram0 8 mount /dev/ram0 /mnt dd if=/dev/zero of=/mnt/junk bs=1024000 count=60 I poked around with sysrq and noticed one thing that seems definitely wrong. The bdflush process is stuck in an infinite loop executing the same eight functions over and over again. The ksymoops looks like this. Trace; c0129e2d <__alloc_pages+109/278> Trace; c0129d22 <_alloc_pages+16/18> Trace; c0132dde Trace; c0130ff4 Trace; c0131000 # Repeating starts here Trace; c01314e4 Trace; c017cff2 Trace; c01758fc Trace; c0175962 Trace; c0175bbb Trace; c013331a Trace; c013338e Trace; c013100e # Round two Trace; c01314e4 Trace; c017cff2 Trace; c01758fc Trace; c0175962 Trace; c0175bbb Trace; c013331a Trace; c013338e Trace; c013100e It has repeated the above eight functions about (roughly) 50 times at the time the system is crashed. I extracted the code from the kernel for those eight functions and put them into a single file in the ksymoops reverse order, also putting in easy to spot comments within each function for where the next one is called. The hope is this will make it easier for someone to spot the problem. It seems too long for this email but it's at www.aracnet.com/~paulb/endlessloop.c.html. I don't think the dd trace will turn out to be interesting, especially since with some number combinations the dd process exits before the system actually crashes but here is the full listing anyway. Trace; c0129e2d <__alloc_pages+109/278> Trace; c0129d22 <_alloc_pages+16/18> Trace; c0124489 Trace; c012f5ba Trace; c0106e63 Finally, the system would crash in a number of ways. Sometimes it will silently hang. Other times it will give a message of one sort or another. These include Unable to handle kernel null pointer dereference Unable to handle kernel paging request Aiee, killing interrupt handler - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Acpi] Re: ACPI fundamental locking problems
[EMAIL PROTECTED] wrote: > >> Would it be possible to use a cramfs image in vmlinux (i.e. real > >> filesystem image, not an in-kernel-structures fs like ramfs), and map > >> it directly from the kernel image (it would have to be suitably aligned, > >> of course)? > > > Yes that would work, and it would work on machines with less RAM too. > > You would want to remove the cramfs filesystem code when you're done though. > > Until you pxe-boot your kernel over the network I don't see a problem with that. pxe-boot loads vmlinuz, kernel boots and finds cramfs image inside itself. Problem? -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6 + MediaGX = kernel panic
On 7-Jul-01 at 20:42, Alan Cox ([EMAIL PROTECTED]) wrote: > > I have Casio Fiva 102 which is a mini notebook based on Cyrix MediaGX > > (clone) chipset. 2.4.5 runs like a charm, but 2.4.6, immediately > > after starting, displays this: > > 2.4.7pre3 should fix that one It works, thanks. Eugene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Acpi] Re: ACPI fundamental locking problems
Mike Touloumtzis wrote: > > Yes that would work, and it would work on machines with less RAM too. > > You would want to remove the cramfs filesystem code when you're done though. > > Some of the files in the boot time FS would need to > be kept around, such as the ACPI code, right? Perhaps. They could be copied to a ramfs by the user-space code :-) On this theme, it's just occured to me that the module loader could be taught to map ramfs pages directly to module code/data space. That would save a little memory. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: ext3-2.4-0.9.0
On Saturday July 7, [EMAIL PROTECTED] wrote: > An update of the ext3 journalling filesystem for 2.4 kernels > is available at > > http://www.uow.edu.au/~andrewm/linux/ext3/ > > Patches are against 2.4.6-ac1 and 2.4.6. I thought it was time to try out ext3 between nfsd and raid5, so I built 2.4.6 plus this patch, and an ext3 filesystem on a largish raid5 volume, exported it (with the "sync" flag), mounted it from another machines with NFSv2, and ran "dbench 4". This produces a live-lock (I think that it the right term). Throughput would drop to zero (determined by watching the counts in /proc/nfs/rpc/nfsd), but could be coaxed along by generating other filesystem activity. I tried nfs over ext3 on a plain ide disc and it worked fine. I tried dbench directly on ext3/raid5 and it worked fine. I tried dbench/nfs/ext2/raid5 and it worked fine. So I think it is some interaction between ext3fs and raid5 triggered by the high rate of "fsync" calls made by nfsd. Naturally I blame ext3 because I know more about raid5 and nfsd :-) One particular aspect of raid5 that *could* be related is that it is very reticent to schedule write requests. It tries to hang on the them as long as possible in the hope of getting more write requests in the same stripe. My guess as to what is happening is that as write request is submitted and then waited-for without an intervening run_task_queue(_disk); When the system is livelocked, all I can tell at the moment (I am at home and the console is at work so I cannot use alt-sysrq) is that kjournal is waiting in wait_on_buffer and an nfsd thread is waiting on the journal. I will try to explore it more deeply next time I am at work, but if there are any suggestions as to what it might be, or how I might more easily find out what is going on, I am all ears. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Acpi] Re: ACPI fundamental locking problems
On Sat, Jul 07, 2001 at 11:53:29PM +0200, Jamie Lokier wrote: > Mike Touloumtzis wrote: > > > > Would it be possible to use a cramfs image in vmlinux (i.e. real > > filesystem image, not an in-kernel-structures fs like ramfs), and map > > it directly from the kernel image (it would have to be suitably aligned, > > of course)? > > > > This would allow demand paging of files in the image (not too important > > for a minimal boot fs, admittedly), and would allow text pages to be > > dropped under VM pressure (nice for a fs which holds substantial amounts > > of boot-time-only code). > > Yes that would work, and it would work on machines with less RAM too. > You would want to remove the cramfs filesystem code when you're done though. Some of the files in the boot time FS would need to be kept around, such as the ACPI code, right? miket - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Acpi] Re: ACPI fundamental locking problems
In article <[EMAIL PROTECTED]> you wrote: >> Would it be possible to use a cramfs image in vmlinux (i.e. real >> filesystem image, not an in-kernel-structures fs like ramfs), and map >> it directly from the kernel image (it would have to be suitably aligned, >> of course)? > Yes that would work, and it would work on machines with less RAM too. > You would want to remove the cramfs filesystem code when you're done though. Until you pxe-boot your kernel over the network - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
OOM: A Success Report
i thought it would be nice to finally hear something good about the OOM killer. i am testing Evolution (Ximian's GNOME emailer/groupware app), and the latest Evolution cvs-snapshot went crazy when trying to copy a mail folder. my load averaged spiked, swap filled, and then i ran out of memory. *poof*, Evolution was killed, and everything returned to normal. kernel showed: Out of Memory: Killed process 1296 (evolution-mail). Out of Memory: Killed process 1296 (evolution-mail). Out of Memory: Killed process 1296 (evolution-mail). Out of Memory: Killed process 1302 (evolution-mail). Out of Memory: Killed process 1303 (evolution-mail). Out of Memory: Killed process 1306 (evolution-mail). Out of Memory: Killed process 1307 (evolution-mail). now, i dont know if the load average spiking was evolution's fault, or not...but everything seemed to work. Good job. -- Robert M. Love rml at ufl.edu rml at tech9.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: [Acpi] Re: ACPI fundamental locking problems
Mike Touloumtzis wrote: > > > Doesn't the approach "treat a chunk of data built into bzImage as > > > populated ramfs" look cleaner? No need to fiddle with tar format, > > > no copying data from place to place. > > > > So tell me, how do you populate ramfs without a format which tells you > > what path and which permissions to assign each file? That's exactly > > what tar is. > > Would it be possible to use a cramfs image in vmlinux (i.e. real > filesystem image, not an in-kernel-structures fs like ramfs), and map > it directly from the kernel image (it would have to be suitably aligned, > of course)? > > This would allow demand paging of files in the image (not too important > for a minimal boot fs, admittedly), and would allow text pages to be > dropped under VM pressure (nice for a fs which holds substantial amounts > of boot-time-only code). Yes that would work, and it would work on machines with less RAM too. You would want to remove the cramfs filesystem code when you're done though. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Acpi] Re: ACPI fundamental locking problems
Jamie Lokier writes: > (tar has a silly pad-to-multiple-of-512-byte per file rule, which is > inappropriate for this). If you remember that 'tar' means "tape archiver", and that at the time it was written the standard tape block size was 512 bytes, the rule isn't silly at all, although it may be undesirable overhead for modern uses of 'tar'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: VM in 2.4.7-pre hurts...
On Sat, 7 Jul 2001, Alan Cox wrote: > > > Its certainly misleading. I got Jeff to try making oom return > > > 4999 out of 5000 times regardless. > > > > In that case, he _is_ OOM. ;) > > Hardly > > > 1) (almost) no free memory > > 2) no free swap > > 3) very little pagecache + buffer cache > > Large amounts of cache, which went away when the OOM code was neutered So Jeff backed out my patch before testing yours? ;) Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM in 2.4.7-pre hurts...
> > Its certainly misleading. I got Jeff to try making oom return > > 4999 out of 5000 times regardless. > > In that case, he _is_ OOM. ;) Hardly > 1) (almost) no free memory > 2) no free swap > 3) very little pagecache + buffer cache Large amounts of cache, which went away when the OOM code was neutered - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Acpi] Re: ACPI fundamental locking problems
On Sat, Jul 07, 2001 at 07:34:38AM -0400, Jeff Garzik wrote: > Eugene Crosser wrote: > > > > Doesn't the approach "treat a chunk of data built into bzImage as > > populated ramfs" look cleaner? No need to fiddle with tar format, > > no copying data from place to place. > > So tell me, how do you populate ramfs without a format which tells you > what path and which permissions to assign each file? That's exactly > what tar is. Would it be possible to use a cramfs image in vmlinux (i.e. real filesystem image, not an in-kernel-structures fs like ramfs), and map it directly from the kernel image (it would have to be suitably aligned, of course)? This would allow demand paging of files in the image (not too important for a minimal boot fs, admittedly), and would allow text pages to be dropped under VM pressure (nice for a fs which holds substantial amounts of boot-time-only code). miket - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Machine check exception? (2.4.6+SMP+VIA)
> I was running 2.4.6-stable in SMP mode on a dual P3-1GHz machine (VIA 694D > Chipset / MSI-6321 M/B + ) and the following message popped up after which > the system hardlocked (no SysRQ input). What does this message mean? > > CPU 1: Machine Check Exception: 0004 > Bank 1: b2000115 > Kernel panic: CPU context corrupt It means your processor flagged a fault. The b2115 number decodes to info about the fault cause if you grab the PIII manual. Stupid things like overheating. wrong voltages can also trigger it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM in 2.4.7-pre hurts...
Rik van Riel wrote: > > On Sat, 7 Jul 2001, Alan Cox wrote: > > > > instead. That way the vmstat output might be more useful, although vmstat > > > obviously won't know about the new "SwapCache:" field.. > > > > > > Can you try that, and see if something else stands out once the misleading > > > accounting is taken care of? > > > > Its certainly misleading. I got Jeff to try making oom return > > 4999 out of 5000 times regardless. > > In that case, he _is_ OOM. ;) > > 1) (almost) no free memory > 2) no free swap > 3) very little pagecache + buffer cache It got -considerably- farther after Alan's suggested hack to the OOM killer; so at least in this instance, OOM killer appeared to me to be killing too early... -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Acpi] Re: ACPI fundamental locking problems
Daniel Phillips wrote: > > Reading a tarball is the distillation of what you describe into > > efficient form :) > > /me downloads tar file definition > > Um, gnu tar or posix tar? or some new, improved tar? I suggest cpio, which is more compact and in some ways more standard. (tar has a silly pad-to-multiple-of-512-byte per file rule, which is inappropriate for this). GNU cpio creates cpio format just fine. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: VM in 2.4.7-pre hurts...
> But neutering the OOM killer like Alan suggested may be a rather valid > approach anyway. Delaying the killing sounds valid: if we're truly > livelocked on the VM, we'll be calling down to the OOM killer so much that > it's probably quite valid to say "only return 1 after X iterations". Its hiding the real accounting screw up with a 'goes bang at random less often' - nice hack, but IMHO bad long term approach. We need to get the maths right. We had similar 2.2 problems the other way (with nasty deadlocks) until Andrea fixed that - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: VM in 2.4.7-pre hurts...
On Sat, 7 Jul 2001, Alan Cox wrote: > > instead. That way the vmstat output might be more useful, although vmstat > > obviously won't know about the new "SwapCache:" field.. > > > > Can you try that, and see if something else stands out once the misleading > > accounting is taken care of? > > Its certainly misleading. I got Jeff to try making oom return > 4999 out of 5000 times regardless. In that case, he _is_ OOM. ;) 1) (almost) no free memory 2) no free swap 3) very little pagecache + buffer cache regards, Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM in 2.4.7-pre hurts...
> instead. That way the vmstat output might be more useful, although vmstat > obviously won't know about the new "SwapCache:" field.. > > Can you try that, and see if something else stands out once the misleading > accounting is taken care of? Its certainly misleading. I got Jeff to try making oom return 4999 out of 5000 times regardless. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.6-ac2
depmod: *** Unresolved symbols in /lib/modules/2.4.6-ac2/kernel/drivers/net/dl2k.o depmod: __ucmpdi2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
networking in v2.2 vs v2.4 kernels.
kernels: Linux pepsi 2.4.6-pre1-packet #1 SMP Tue Jun 12 02:12:32 EDT 2001 i686 Linux eax 2.2.20pre6 #1 Wed Jun 27 10:39:14 EST 2001 i586 I have a program which does : flags = MSG_WAITALL; rawsock = socket(PF_INET,SOCK_RAW,IPPROTO_TCP); bytesread = recvfrom(rawsock,,buflen,flags, (struct sockaddr*)(), on my 2.4.x box it works pretty much as expected (excpet that for some reason the from.sin_port is always set to 0). However if I try to run the same piece of code on 2.2 kernel it basically never blocks and always immediatelly returns, and for second thing, it seems as if it getting some random junk from loopback device, and it never seems to get any data from any other interface.. any idea what could the difference in behavior between 2.4 and 2.2 ? -- Adam http://www.eax.com The Supreme Headquarters of the 32 bit registers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Machine check exception? (2.4.6+SMP+VIA)
Followup to: <[EMAIL PROTECTED]> By author:"Vibol Hou" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Hi, > > I was running 2.4.6-stable in SMP mode on a dual P3-1GHz machine (VIA 694D > Chipset / MSI-6321 M/B + ) and the following message popped up after which > the system hardlocked (no SysRQ input). What does this message mean? > > CPU 1: Machine Check Exception: 0004 > Bank 1: b2000115 > Kernel panic: CPU context corrupt > > Message from syslogd@delta at Sat Jul 7 13:18:36 2001 ... > delta kernel: CPU 1: Machine Check Exception: 0004 > > Message from syslogd@delta at Sat Jul 7 13:18:36 2001 ... > delta kernel: Bank 1: b2000115 > > Message from syslogd@delta at Sat Jul 7 13:18:36 2001 ... > delta kernel: Kernel panic: CPU context corrupt > It means your hardware is bad. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Does kernel require IDE enabled in BIOS to access HD, FS errors?
On Sat, 7 Jul 2001, Jim Roland wrote: > but it's possible that the kernel is making a BIOS call, Not really ... Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Does kernel require IDE enabled in BIOS to access HD, FS errors?
- Original Message - From: "M.H.VanLeeuwen" <[EMAIL PROTECTED]> To: "Jim Roland" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, July 07, 2001 8:47 AM Subject: Re: Does kernel require IDE enabled in BIOS to access HD, FS errors? > Jim, > > Thanks for the info, comments interleaved below > [snip] > > But, that's kind of the point I'm driving at if the OS can't correctly access the > IDE interface it shouldn't do it at all. Right. It's possible that your BIOS may be letting the kernel write. While I don't write the kernel, it's probably best for Linus to answer this one, but it's possible that the kernel is making a BIOS call, and the BIOS does not refuse to write data (which it should just say "no IDE drives are on the system right now") with the IDE setting to in your BIOS. OTOH, the kernel may be making calls of it's own or as you say, there may be a broken driver. I seem to remember there was a "bug workaround" option in the kernel for the CMD640 chipset. > > Are you getting IDE corruption with the BIOS set to for your IDE > > drive? > > None whatsoever. Then AFAIK, it's definitely a BIOS issue. There might be (if not there already) a kernel option to check to see what the BIOS setting is for number of IDE drives (of course set to would mean 0 drives), and refuse to write it. This workaround (if any) would be required for buggy BIOSes (I'm sure yours isn't the only one ). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Machine check exception? (2.4.6+SMP+VIA)
Hi, I was running 2.4.6-stable in SMP mode on a dual P3-1GHz machine (VIA 694D Chipset / MSI-6321 M/B + ) and the following message popped up after which the system hardlocked (no SysRQ input). What does this message mean? CPU 1: Machine Check Exception: 0004 Bank 1: b2000115 Kernel panic: CPU context corrupt Message from syslogd@delta at Sat Jul 7 13:18:36 2001 ... delta kernel: CPU 1: Machine Check Exception: 0004 Message from syslogd@delta at Sat Jul 7 13:18:36 2001 ... delta kernel: Bank 1: b2000115 Message from syslogd@delta at Sat Jul 7 13:18:36 2001 ... delta kernel: Kernel panic: CPU context corrupt -- Vibol Hou - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Hi all, a strange full lock in SMP-kernel 2.4.6 and 2.4.5
Just to follow up to myself, after futher testing, it looks like it's an SMP-related problem. I'm not yet sure if it's an SMP-Via chipset problem or just an SMP problem. I've heard from two people with this same problem. I think one of them has a Via chipset and I'm not sure about the other one. Can anybody look into this or give me a good brain dump on how I can fix it? Thanks, pete On Fri, 06 Jul 2001, Pete Toscano wrote: > I think I've seen this same problem, at least with regards to USB > printing. Yesterday, I traced the problem down to a patch to usb-uhci.c > in the transition from 2.4.3 to 2.4.4. The problem persists today. A > work around for this problem is to use the alternate UHCI driver > (uhci.o). > > What motherboard and chipset are you using. I use the Tyan Tiger 133 > motherboard with the VIA Apollo Pro 133a chipset. Someone else who I > heard from uses another VIA-based chipset (I think, he never replied to > my question). Maybe this is a VIA-related problem, like the APIC > problem is. (Do you use "noapic" when you boot? He and I both have SMP > systems too) > > I posted something on the linux-usb list yesterday about this problem > and with all the info I was able to track down, but I have yet to see > any response. I've taken this as far as I can by myself. I don't know > enough about kernel programming or about USB to check the code in > usb-uhci.c, but I'm more than happy to help by providing information > and/or testing potential patches/fixes. > > 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/
Modem problem
My modems (Courier 28.8 external, Actiontec PCI call waiting non-winmodem) connect to the Internet fine with 2.4.0, and broke around 2.4.1. What happens is they dial out, make those sounds, and just as they seem to be about to connect, they disconnect. I'm pretty sure both kernels are configured correctly. This still occurs with kernel 2.4.6. On a seperate note (and I realize this is a lot more nebulous) my disk begins to make a lot of noise at random times and doesn't stop for several minutes. This sometimes happens when using apt-get, though I've seen it do it at gdm login prompts. 128 megs ram, 130 meg swap. Any ideas...? Thank you, Gerry please cc, not subscribed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: VM in 2.4.7-pre hurts...
On Sat, 7 Jul 2001, Linus Torvalds wrote: > In fact, I do not see any part of the whole path that sets the > page age at all, so we're basically using a completely > uninitialized field here (it's been initialized way back when > the page was allocated, but because it hasn't been part of the > normal aging scheme it has only been aged up, never down, so the > value is pretty much random by the time we actually add it to > the swap cache pool). Not quite. The more a page has been used, the higher the page->age will be. This means the system has a way to distinguish between anonymous pages which were used once and anonymous pages which are used lots of times. > Suggested fix: [snip disabling of page aging for anonymous memory] > That would certainly help explain why aging doesn't work for some people. As would your patch ;) regards, Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM in 2.4.7-pre hurts...
On Sat, 7 Jul 2001, Rik van Riel wrote: > > Not at all. Note that try_to_swap_out() will happily > create swap cache pages with a very high page->age, > pages which are in absolutely no danger of being > evicted from memory... That seems to be a bug in "add_to_swap_cache()". In fact, I do not see any part of the whole path that sets the page age at all, so we're basically using a completely uninitialized field here (it's been initialized way back when the page was allocated, but because it hasn't been part of the normal aging scheme it has only been aged up, never down, so the value is pretty much random by the time we actually add it to the swap cache pool). Suggested fix: --- v2.4.6/linux/mm/swap_state.cTue Jul 3 17:08:22 2001 +++ linux/mm/swap_state.c Sat Jul 7 11:49:13 2001 @@ -81,6 +81,7 @@ BUG(); flags = page->flags & ~((1 << PG_error) | (1 << PG_arch_1)); page->flags = flags | (1 << PG_uptodate); + page->age = PAGE_AGE_START; add_to_page_cache_locked(page, _space, entry.val); } Does that make a difference for people? That would certainly help explain why aging doesn't work for some people. 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/
[RFC-PATCH] split cache and swapcache statistics
Hi, maybe we'll want to end the confusion and split the cached and swap-cached statistics ... Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ --- linux-2.4.6/fs/proc/proc_misc.c.origSat Jul 7 15:17:42 2001 +++ linux-2.4.6/fs/proc/proc_misc.c Sat Jul 7 15:19:31 2001 @@ -165,7 +165,8 @@ "MemFree: %8lu kB\n" "MemShared:%8lu kB\n" "Buffers: %8lu kB\n" -"Cached: %8u kB\n" +"Cached: %8lu kB\n" + "SwapCached: %8lu kB\n" "Active: %8u kB\n" "Inact_dirty: %8u kB\n" "Inact_clean: %8u kB\n" @@ -180,7 +181,8 @@ K(i.freeram), K(i.sharedram), K(i.bufferram), -K(atomic_read(_cache_size)), +K(atomic_read(_cache_size) - swapper_space.nrpages), + K(swapper_space.nrpages), K(nr_active_pages), K(nr_inactive_dirty_pages), K(nr_inactive_clean_pages()), - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 region check in drivers/pcmcia/rsrc_mgr.c
On Sat, 7 Jul 2001, Paul Mackerras wrote: > > The patch below does this (and makes a similar correction for I/O > space). With this patch applied, the pcmcia stuff works fine on my > powerbook, and I end up with something like this in /proc/iomem: This is wrong. The reason it currently uses the rather fascist check_resource() is that the thing needs a completely _unallocated_ region. By changing it to use "check_region" instead of "check_resource()", you allow the PCMCIA code to use an already allocated (but not in use) PCI region. That is not what the code is meant to do - you might find that the yenta code suddenly starts allocating the PCMCIA resources inside another PCI device that just hasn't marked its resources busy yet. This is, in fact, exactly what happens for you: it allocates the resources inside your PCI bridge mappings. Which happens to be what you want in this case, but it's not right in general. > Linus, would you apply this patch to your tree? I don't think so. HOWEVER, you can change the resource checking to use the proper "parent resource" instead of using the root resource. I absolutely agree that using the root resource is wrong per se - it depends (incorrectly) on the fact that on all laptops the PCMCIA controller tends to be on the root bus. Note that the CardBus side gets this all right - I assume that a 32-bit CardBus card with a PCI driver should work on your powerbook even without this patch, no? It's only the old-style PCMCIA resource management that is fairly broken. It may be that you rpatch might be an acceptable band-aid, but I really think that the problem should be solved differently. 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: VM in 2.4.7-pre hurts...
On Sat, 7 Jul 2001, Jeff Garzik wrote: > Sigh. since I am a VM ignoramus I doubt my opinion matters much > at all here... but it would be nice if oddball configurations > like 384MB with 50MB swap could be supported. It would be fun if we had 48 hours in a day, too ;) This particular thing has been on the TODO list of the VM developers for a while, but we just haven't gotten around to it. regards, Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH #2] OOM kill trigger
On Fri, 6 Jul 2001, Jeff Garzik wrote: > Rik van Riel wrote: > > + cache_mem = atomic_read(_cache_size); > > + cache_mem += atomic_read(_pages); > > + cache_mem -= swapper_space.nrpages; > > + limit = (page_cache.min_percent + buffer_mem.min_percent); > > Don't you need extra protection around swapper_space.nrpages? > A barrier right above it? No. It's just a heuristic. Besides, all that could change is the VALUE of swapper_space.nrpages and it won't change by all that much... Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM in 2.4.7-pre hurts...
Linus Torvalds wrote: > > On Sat, 7 Jul 2001, Jeff Garzik wrote: > > Linus Torvalds wrote: > > > > > > Now, the fact that the system appears unusable does obviously mean that > > > something is wrong. But you're barking up the wrong tree. > > > > Two more additional data points, > > > > 1) partially kernel-unrelated. MDK's "make" macro didn't support > > alpha's /proc/cpuinfo output, "make -j$numprocs" became "make -j" and > > fun ensued. > > Ahh, well.. > > The kernel source code is set up to scale quite well, so yes a "make -j" > will parallellise a bit teoo well for most machines, and you'll certainly > run out of memory on just about anything (I routinely get load averages of > 30+, and yes, you need at least half a GB of RAM for it to not be > unpleasant - and probably more like a full gigabyte on an alpha). "make -j" is a lot of fun on a dual athlon w/ 512mb :) > So I definitely think the kernel likely did the right thing. It's not even > clear that the OOM killer might not have been right - due to the 2.4.x > swap space allocation, 256MB of swap-space is a bit tight on a 384MB > machine that actually wants to use a lot of memory. Sigh. since I am a VM ignoramus I doubt my opinion matters much at all here... but it would be nice if oddball configurations like 384MB with 50MB swap could be supported. I don't ask that it perform optimally at all, but at least the machine should behave predictably... This type of swap configuration makes sense for, "my working set is pretty much always in RAM, including i/dcache, but let's have some swap just-in-case" > > 2) I agree that 200MB into swap and 200MB into cache isn't bad per se, > > but when it triggers the OOM killer it is bad. > > Note that it might easily have been 256MB into swap (ie it had eaten _all_ > of your swap) at some stage - and you just didn't see it in the vmstat > output because obviously at that point the machine was a bit loaded. I'm pretty sure swap was 100% full. I should have sysrq'd and checked but I forgot. > But neutering the OOM killer like Alan suggested may be a rather valid > approach anyway. Delaying the killing sounds valid: if we're truly > livelocked on the VM, we'll be calling down to the OOM killer so much that > it's probably quite valid to say "only return 1 after X iterations". cnt % 5000 may have been a bit extreme but it was fun to see it thrash. sysrq was pretty much the only talking point into the system. -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: VM in 2.4.7-pre hurts...
On Sat, 7 Jul 2001, Jeff Garzik wrote:
> 2) I agree that 200MB into swap and 200MB into cache isn't bad
> per se, but when it triggers the OOM killer it is bad.
Please read my patch for the OOM killer. It substracts the
swap cache from the cache figure you quote and ONLY goes
into oom_kill() if the page & buffer cache together take
less than 4% of memory (see /proc/sys/vm/{buffermem,pagecache}).
regards,
Rik
--
Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: VM in 2.4.7-pre hurts...
On Sat, 7 Jul 2001, Jeff Garzik wrote: > Linus Torvalds wrote: > > > > Now, the fact that the system appears unusable does obviously mean that > > something is wrong. But you're barking up the wrong tree. > > Two more additional data points, > > 1) partially kernel-unrelated. MDK's "make" macro didn't support > alpha's /proc/cpuinfo output, "make -j$numprocs" became "make -j" and > fun ensued. Ahh, well.. The kernel source code is set up to scale quite well, so yes a "make -j" will parallellise a bit teoo well for most machines, and you'll certainly run out of memory on just about anything (I routinely get load averages of 30+, and yes, you need at least half a GB of RAM for it to not be unpleasant - and probably more like a full gigabyte on an alpha). So I definitely think the kernel likely did the right thing. It's not even clear that the OOM killer might not have been right - due to the 2.4.x swap space allocation, 256MB of swap-space is a bit tight on a 384MB machine that actually wants to use a lot of memory. > 2) I agree that 200MB into swap and 200MB into cache isn't bad per se, > but when it triggers the OOM killer it is bad. Note that it might easily have been 256MB into swap (ie it had eaten _all_ of your swap) at some stage - and you just didn't see it in the vmstat output because obviously at that point the machine was a bit loaded. But neutering the OOM killer like Alan suggested may be a rather valid approach anyway. Delaying the killing sounds valid: if we're truly livelocked on the VM, we'll be calling down to the OOM killer so much that it's probably quite valid to say "only return 1 after X iterations". 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: VM in 2.4.7-pre hurts...
Linus Torvalds wrote: > > On Sat, 7 Jul 2001, Jeff Garzik wrote: > > > > When building gcc-2.96 RPM using gcc-2.96 under kernel 2.4.7 on alpha, > > the system goes --deeply-- into swap. Not pretty at all. The system > > will be 200MB+ into swap, with 200MB+ in cache! I presume this affects > > 2.4.7-release also. > > Note that "200MB+ into swap, with 200MB+ in cache" is NOT bad in itself. > > It only means that we have scanned the VM, and allocated swap-space for > 200MB worth of VM space. It does NOT necessarily mean that any actual > swapping has been taking place: you should realize that the "cache" is > likely to be not at least partly the _swap_ cache that hasn't been written > out. > > This is an accounting problem, nothing more. It looks strange, but it's > normal. > > Now, the fact that the system appears unusable does obviously mean that > something is wrong. But you're barking up the wrong tree. Two more additional data points, 1) partially kernel-unrelated. MDK's "make" macro didn't support alpha's /proc/cpuinfo output, "make -j$numprocs" became "make -j" and fun ensued. 2) I agree that 200MB into swap and 200MB into cache isn't bad per se, but when it triggers the OOM killer it is bad. Alan suggested that I insert the following into the OOM killer code, as the last test before returning 1. cnt++; if ((cnt % 5000) != 0) return 0; I did this, and while watching "vmstat 3", the cache was indeed being trimmed, whereas it was not before. So, the OOM killer appears to be getting triggered early, but the rest of the report was my screwup not the kernel. -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: VM in 2.4.7-pre hurts...
On Sat, 7 Jul 2001, Jeff Garzik wrote: > > When building gcc-2.96 RPM using gcc-2.96 under kernel 2.4.7 on alpha, > the system goes --deeply-- into swap. Not pretty at all. The system > will be 200MB+ into swap, with 200MB+ in cache! I presume this affects > 2.4.7-release also. Note that "200MB+ into swap, with 200MB+ in cache" is NOT bad in itself. It only means that we have scanned the VM, and allocated swap-space for 200MB worth of VM space. It does NOT necessarily mean that any actual swapping has been taking place: you should realize that the "cache" is likely to be not at least partly the _swap_ cache that hasn't been written out. This is an accounting problem, nothing more. It looks strange, but it's normal. Now, the fact that the system appears unusable does obviously mean that something is wrong. But you're barking up the wrong tree. Although it might be the "right tree" in the sense that we might want to remove the swap cache from the "cached" output in /proc/meminfo. It might be more useful to separate out "Cached" and "SwapCache": add a new line to /proc/meminfo that is "swapper_space.nr_pages", and make the current code that does atomic_read(_cache_size) do (atomic_read(_cache_size) - swapper_space.nrpages) instead. That way the vmstat output might be more useful, although vmstat obviously won't know about the new "SwapCache:" field.. Can you try that, and see if something else stands out once the misleading accounting is taken care of? 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: RFC: Remove swap file support
In article <[EMAIL PROTECTED]> you wrote: > Since you can make any file into a block device using loop, > is there any value to supporting swap files in 2.5? > swap files seem like a special case that is no longer necessary... loop is always tricky re near-OOM deadlocks. It'll survive now, by sleeping and waiting for memory, but swapping over that changes that equation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Acpi] Re: ACPI fundamental locking problems
On Saturday 07 July 2001 15:50, Jeff Garzik wrote: > Eugene Crosser wrote: > > In article > > <[EMAIL PROTECTED]>, > > > > Alexander Viro <[EMAIL PROTECTED]> writes: > > >> Doesn't the approach "treat a chunk of data built into bzImage > > >> as populated ramfs" look cleaner? No need to fiddle with tar > > >> format, no copying data from place to place. > > > > > > What the hell _is_ "populated ramfs"? The thing doesn't live in > > > array of blocks. Its directory structure consists of a bunch of > > > dentries. > > > > I am stupid. But the point still stays: having an image of > > pre-populated filesystem (some other than ramfs) that you only need > > to load into RAM seems more sutable than parsing tar format. Maybe > > (probably) I am missing something. > > Yeah -- we build all this stuff dynamically. struct file, struct > inode, etc. You could store them on disk as they would be > represented in memory, but this would be incredibly inefficient > because of all the runtime structures unnecessary on disk, and > because of all the fixups and checks you would have to perform on the > data in the images after they magically appear in memory. Not to mention internal fragmentation. > Reading a tarball is the distillation of what you describe into > efficient form :) /me downloads tar file definition Um, gnu tar or posix tar? or some new, improved tar? -- 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] gamecon.c: Fix for SNES controllers
On Thu, Jul 05, 2001 at 09:49:08PM -0400, Michael Gold wrote:
> In kernel 2.4.4, a change was made to gamecon.c that causes problems
> with Super Nintendo controllers. The directional pad no longer works
> correctly - only the up and left directions work. The following patch
> fixes the problem by reversing the change. It applies cleanly to
> kernels 2.4.4, 2.4.5, and 2.4.6.
>
> --- linux-2.4.4-orig/drivers/char/joystick/gamecon.c Wed Apr 11 22:02:30 2001
> +++ linux-2.4.4/drivers/char/joystick/gamecon.c Sat May 26 03:57:13 2001
> @@ -345,8 +345,8 @@
> s = gc_status_bit[i];
>
> if (s & (gc->pads[GC_NES] | gc->pads[GC_SNES])) {
> - input_report_abs(dev + i, ABS_X, ! - !(s & data[6]) -
>!(s & data[7]));
> - input_report_abs(dev + i, ABS_Y, ! - !(s & data[4]) -
>!(s & data[5]));
> + input_report_abs(dev + i, ABS_X, !!(s & data[7]) -
>!!(s & data[6]));
> + input_report_abs(dev + i, ABS_Y, !!(s & data[5]) -
>!!(s & data[4]));
> }
>
> if (s & gc->pads[GC_NES])
>
Already fixed in -ac series kernels. Thanks anyway.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.4.7pre3aa1
Diff between 2.4.7pre2aa1 and 2.4.7pre3aa1: - Only in 2.4.7pre2aa1: 00_3c59x-zerocopy-1 Only in 2.4.7pre3aa1: 00_3c59x-zerocopy-2 Right fix for enabling zerocopy on highmem kernels. (nice to have) Only in 2.4.7pre3aa1: 00_async-io-unlock-race-1 Fix possible memory corruption due a race where the page can be unlocked under us and so the bh could be unlocked as well under us. Found it in -ac. (recommended) Only in 2.4.7pre2aa1: 00_ksoftirqd-7 Only in 2.4.7pre3aa1: 00_ksoftirqd-8 Add the BUG() check, to be as strict as mainline (no functional differences for correct code). (nice to have) Only in 2.4.7pre3aa1: 00_meminfo-wraparound-1 Use long long in /proc/meminfo to avoid wrap arounds on >4G boxes. (nice to have) Only in 2.4.7pre3aa1: 00_rawio-down_read-1 Use read lock for rawio. (nice to have) Only in 2.4.7pre2aa1: 00_vm-deadlock-fix-1 Only in 2.4.7pre2aa1: 00_xircom-serial-1 Merged in mainline. Only in 2.4.7pre2aa1: 10_blkdev-pagecache-4 Only in 2.4.7pre3aa1: 40_experimental Moved the 10_blkdev-pagecache-4 patch back into the 40_experimental directory, don't apply it for production it's not ready yet, initrd is still broken (it will be fixed soon). - Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6 PCMCIA NET modular build breakage
On Sat, Jul 07, 2001 at 06:30:33PM +0400, Oleg Drokin wrote: > Hmm > (examining Makefile...) > I see. So there cannot be usual targets before including Rules.make, > and my copy of the tree have these. And if I move them after inclusion, > everything builds just fine. > Perhaps it should be documented somewhere. > > Well. So at the end it seems to be not a vanilla kernel problem. That's good. Ok, so you got the problem solved. Mind enlightening me and Nico so we know what's wrong please? -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG?] vtund broken by tun driver changes in 2.4.6
Recompile your VTUND daemon with the new kernel headers (and also updated to 2.5 vtund, it has some small patches) and you will be fine. - Original Message - From: "Ryan Mack" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, July 07, 2001 1:02 AM Subject: [BUG?] vtund broken by tun driver changes in 2.4.6 > I recently upgraded a server running vtund 2.4 (4/18/01) to stock 2.4.6 > kernel. It seems the changes to the tun driver have broken vtund. Now my > syslog gets filled with the following messages when a client attempts to > connect: > > Jul 5 10:15:53 mackman vtund[4011]: Session > mackman-vpn[64.169.117.25:2359] opened > Jul 5 10:15:53 mackman vtund[4011]: Can't allocate tun device. File > descriptor in bad state(77) > Jul 5 10:15:53 mackman vtund[4011]: Session mackman-vpn closed > Jul 5 10:16:04 mackman vtund[4014]: Session > mackman-vpn[64.169.117.25:2360] opened > Jul 5 10:16:04 mackman vtund[4014]: Can't allocate tun device. File > descriptor in bad state(77) > Jul 5 10:16:04 mackman vtund[4014]: Session mackman-vpn closed > > Eventually the client gives up. Do you have any suggestions or know of > any fixes? > > Thanks, Ryan Mack > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message 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/
Linux 2.4.6-ac2
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org 2.4.6-ac2 o Merge Linus 2.4.7pre1 o Drop out various bits that are 2.5 stuff AS/400 etc o Merge Linus 2.4.7pre2 o Merge Linus 2.4.7pre3 o Handle strange USB descriptors in CDCEther (Brad Hards, | Fixe Motorola SB4100 cable modem Jason Purdy) o Experimentally add aha1505 isapnp support (Peter Samuelson) o Fix SMP race in buffer.c(Andrew Morton) o Fix fs/sysv/dir.c link mishandling (Al Viro) o D-Link 2000 Gigabit ethernet driver (Edward Peng) o EEPro100 fixes (Kai Germaschewski) o Radeon frame buffer driver updates (Ani Joshi) o Incorrect PPC irq assignment fix(Paul Mackerras) o Fix usb scanner ioctl error return (Paul Mackerras) o Fix ohci ppc build (Paul Mackerras) o Avoid oom handler firing excessively early (Rik van Riel) o Fix imsttfb build bug (Paul Mackerras) o Add another kaweth ethernet id (Fumiaki OHATA) o i810 audio driver updates (Doug Ledford) o Vm86 sti handling fixup (Stas Sergeev) o Fix non pnpbios build (Steve Cole) o Remove SGML short forms from video docs (Erik Mouw) o Pnp comments change for remove op (Jeff Garzik) o Revert epic100 MII change (Jeff Garzik) o Update Jes maintainer info (Jes Sorensen) o Add test shared irq support to fdomain driver (me) o Add mising DQUOT_INIT in inode.c(Al Viro) o Fix device locking leak in pppoe(Arnaldo Carvalho de Melo) o Clean up the pnpbios BIOS calling code (Brian Gerst) o Configure.help updates (Eric Raymond) o Don't autoload parport_serial in parport(Tim Waugh) o Update atyfb(Geert Uytterhoeven) o Fix procfs reporting of ataraid (Arjan van de Ven) o Upate ATP870u driver to handle the new (Wittman Lee) 6760 U160 hardware o Further ALi trident driver updates (Matt Wu) 2.4.6-ac1 o Merge with Linus 2.4.6 o Fix 2.4.6 pci_enable_device breakage(Kai Germaschewski) o Fix missing ";" in ide-tape debug modes (Johh Guthrie) o Update usb serial driver(Greg Kroah-Hartmann) o Fix ppc build error (Paul Mackerras) o Fill out core of pnpbios hotplug structure (me) | ie borrow from PCI 2.4.5-ac24 o Serverworks AGP support (Jeff Hartmann) o Split I/O requests on pdcraid/hptraid when (Arjan van de Ven) they cross stride o Fix hangs on TI1410 cardbus bridge (Erik Mouw) o Update Configure.help (Eric Raymond) o Fix bug in ext2_new_inode (Al Viro) o Fix double pci_set_power_state stub (Jeff Garzik) o Fix mcheck_disable (Andrew Morton) o Merge 2.4.6-pre9 - Ignored ATI changes versus old atyfb codebase - Remove several totally broken drivers/net/Config.in changes o Update act2000 isdn driver (Kai Germaschewski) o Fix ELOOP handling bug (Al Viro) 2.4.5-ac23 o Merge with 2.4.6pre8 | This should make things much more stable o Restore backed out shm patches (Christoph Rohland) o Fix quotaoff crash (Jan Kara) o Move stuff into BSS on decnet (Xavier Bestel) o Update ims twinturbo fb maintainer (Paul Mundt) o Update Crutcher Dunnavant's email address (Crutcher Dunnavant) o UML ^S/^Q support for the console and serial(Livio Soares) o code cleanups in UML drivers(Jeff Dike) o UML include and #define cleanups(Niels Kristian Bech Jensen) o UML ubd driver defines blk_size correctly (Roman Zippel) o which allowed clean up of related ubd code (Jeff Dike) o tweak the UML definition is a fixable seg fault (Jeff Dike) o fix the UML TASK_UNINTERRUPTIBLE deadlock (Jeff Dike) o Update ldconfig scripts for multiple rodata (Jakub Jelinek) o Small isdn.h fixes (Kai Germaschewski) o Add Advantech TurboPAM isdn (Stelian Pop) o Maxine frame buffer
Re: 2.4.6 + MediaGX = kernel panic
> I have Casio Fiva 102 which is a mini notebook based on Cyrix MediaGX > (clone) chipset. 2.4.5 runs like a charm, but 2.4.6, immediately > after starting, displays this: 2.4.7pre3 should fix that one - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.6 + MediaGX = kernel panic
I have Casio Fiva 102 which is a mini notebook based on Cyrix MediaGX (clone) chipset. 2.4.5 runs like a charm, but 2.4.6, immediately after starting, displays this: zone(0): 4096 pages. zone(1): 11648 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=linux ro root=304 sb=0x220,5,1,5 Initializing CPU#0 Working around Cyrix MediaGX virtual DMA bugs Console: colour VGA+ 80x25 kernel BUG at softirq.c:206! == The rest of the output is passed through ksymoops: ksymoops 2.3.3 on i586 2.4.5. Options used -v /usr/src/linux/vmlinux (specified) -K (specified) -L (specified) -O (specified) -m /usr/src/linux/System.map (default) invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: 001d ebx: c0253b20 ecx: 0001 edx: c01fce68 esi: c0253b20 edi: 0001 ebp: esp: c020befc ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c020b000) Stack: c01d1caa c01d1d26 00ce 0009 c023d5c0 c023d5c0 c020bf40 c0113d1f c023d5c0 c023b900 c010807d c0201e60 c020bf9f 02d4 c01fca40 02d4 c0106d80 c0201e60 02d4 c020bf9f 02d4 Call trace: [] [] [] [] [] Code: 0f 0b 83 c4 0c 8b 43 08 85 c0 75 18 fb 8b 43 10 50 8b 43 0c >>EIP; c0113f0e<= Trace; c0113d1f Trace; c010807d Trace; c0106d80 Trace; c011092f Trace; c0105000 <_stext+0/0> Code; c0113f0e <_EIP>: Code; c0113f0e<= 0: 0f 0b ud2a <= Code; c0113f10 2: 83 c4 0c add$0xc,%esp Code; c0113f13 5: 8b 43 08 mov0x8(%ebx),%eax Code; c0113f16 8: 85 c0 test %eax,%eax Code; c0113f18 a: 75 18 jne24 <_EIP+0x24> c0113f32 Code; c0113f1a c: fbsti Code; c0113f1b d: 8b 43 10 mov0x10(%ebx),%eax Code; c0113f1e 10: 50push %eax Code; c0113f1f 11: 8b 43 0c mov0xc(%ebx),%eax Kernel panic: Aiee, killing interrupt handler! Tell me if I can provide more information Eugene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bugreport : system unacceptably slow.
Hi, Every once in a while, my system gets unbelievable slow. So slow that I almost can't do anything anymore. This happens only once in a few months. I think it has to do with sound, because when I start using sound, it happens. "top" gives me then about 90% idle time, and "top" is using this 10% then. This already happens quite a while. I already had this with a 2.2.x kernel and I just had it with the 2.4.2 kernel. Could you tell me what I can do to give you more information ? Do you think it could be in this module ? I use the es1370 driver as a loadable module that gets loaded when asked for it. I always use standard distribution installation. Now I have RH7.1 With kind regards, Edwin. info : [root@CC90001-A /root]# cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 4). Master Capable. Latency=64. Non-prefetchable 32 bit memory at 0xe000 [0xe3ff]. Bus 0, device 1, function 0: PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 4). Master Capable. Latency=64. Min Gnt=8. Bus 0, device 2, function 0: USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 3). IRQ 9. Master Capable. Latency=64. Max Lat=80. Non-prefetchable 32 bit memory at 0xde80 [0xde800fff]. Bus 0, device 3, function 0: Bridge: Acer Laboratories Inc. [ALi] M7101 PMU (rev 0). Bus 0, device 7, function 0: ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV] (rev 195). Bus 0, device 9, function 0: Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 1). IRQ 5. Master Capable. Latency=32. Min Gnt=12.Max Lat=128. I/O at 0xd800 [0xd83f]. Bus 0, device 10, function 0: Ethernet controller: Winbond Electronics Corp W89C940 (rev 11). IRQ 7. I/O at 0xd400 [0xd41f]. Bus 0, device 11, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] (rev 33). IRQ 10. Master Capable. Latency=32. I/O at 0xd000 [0xd07f]. Non-prefetchable 32 bit memory at 0xde00 [0xde7f]. Bus 0, device 12, function 0: SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c810 (rev 35). IRQ 11. Master Capable. Latency=64. Min Gnt=8.Max Lat=64. I/O at 0xb800 [0xb8ff]. Non-prefetchable 32 bit memory at 0xdd80 [0xdd8000ff]. Bus 0, device 15, function 0: IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev 193). Master Capable. Latency=32. Min Gnt=2.Max Lat=4. I/O at 0xb400 [0xb40f]. Bus 1, device 0, function 0: VGA compatible controller: nVidia Corporation Riva TnT 128 [NV04] (rev 4). IRQ 11. Master Capable. Latency=64. Min Gnt=5.Max Lat=1. Non-prefetchable 32 bit memory at 0xdf00 [0xdfff]. Prefetchable 32 bit memory at 0xe700 [0xe7ff]. [root@CC90001-A /root]# lspci -vvv 00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1541 (rev 04) Subsystem: Acer Laboratories Inc. [ALi] ALI M1541 Aladdin V/V+ AGP System Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- 00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5243 (rev 04) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- Reset- FastB2B- 00:02.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03) (prog-if 10 [OHCI]) 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=32K] 00:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21041 [Tulip Pass 3] (rev 21) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=256K] 00:0c.0 SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c810 (rev 23) Subsystem: Symbios Logic Inc. (formerly NCR) 8100S 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- [root@CC90001-A /root]# lsmod Module Size Used by es1370 24896 0 (autoclean) soundcore 4432 4 (autoclean) [es1370] ov511 38768 0 videodev4896 1 [ov511] autofs 11136 1 (autoclean) ne2k-pci4864 1
Re: NCR 35XXXX MCA bus and SMP
> And i have a NCR 3525 with MCA bus and 8 processors and 512MB RAM , i > tried Suse 6.4 and Red Hat 7.1 , but nome detected my MCA bus , the 8 > processors and more than 64MB ... i tried kernel parameter mem=512m , > but no results... only 64MB i recompiled the kernel (2.4.2) with > MCA=y and SMP =y ... and no results... somebody can help me ? Machines like this require a special SMP HAL to get them to work. You could try the experimental kernels from http://www.hansenpartnership.com/voyager which contain the SMP HAL for the voyager systems (which is what a 3525 is). James Bottomley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RFC: Remove swap file support
Since you can make any file into a block device using loop, is there any value to supporting swap files in 2.5? swap files seem like a special case that is no longer necessary... -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Filesystem bug? "sync" hangs...
Kernel 2.4.7-pre3 on alpha. The initial phase of an RPM build is unpacking a tarball and applying patches, which is a bunch of writes followed by a update of read/write updates. A lot of write activity, basically. RPM build is running at normal priority as a normal user. In another xterm, su'd in a shell that is renice'd to -14, I run "sync" during all this write activity. It hangs for 17 seconds before I get impatient, stop counting, and suspend the RPM build process. sync continues to block, not returning to the command prompt. I run dmesg (generated read activity?), and sync finally returns. The RPM build process continues unpacking/writing files without appearing to slow in window 1 while sync blocks in window 2. I have not seen this behavior before, but I do not recall trying 'sync' specifically during heavy write activity before. This behavior is reproducible. -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: crazy timer on dual pentium-mmx (2.4.5 and 2.4.6)
hello, I have a serious problem since 2.4.5 kernel, the timer go crazy (about 10 time normal speed) I can't login because the 60 secondes timeout get only a few second in real life. Same thing about harddrive timeout error. The motherboard is a dual pentium-mmx 200 http://www.asus.com/products/motherboard/pentium/p65up5-p55t2d/p65up5-p55t2d-spec.html http://www.asus.com/Products/Motherboard/Pentiumpro/P65up5-p6nd/c-p55t2d.html kernel is compiled on the computer with kernel 2.4.4 and following tools: Gnu C 2.95.2 Gnu make 3.79.1 binutils 2.9.5.0.37 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6 PCMCIA NET modular build breakage
Oleg Drokin wrote: > arm-linux-ld -p -X -T arch/arm/vmlinux.lds arch/arm/kernel/head-armv.o >arch/arm/kernel/init_task.o init/main.o init/version.o \ > --start-group \ > arch/arm/kernel/kernel.o arch/arm/mm/mm.o arch/arm/mach-sa1100/sa1100.o > kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ > drivers/char/char.o drivers/block/block.o drivers/misc/misc.o >drivers/net/net.o drivers/media/media.o drivers/cdrom/driver.o drivers/mtd/mtdlink.o >drivers/net/pcmcia/pcmcia_net.o drivers/net/wireless/wireless_net.o >drivers/video/video.o \ > net/network.o \ > arch/arm/fastfpe/fast-math-emu.o arch/arm/nwfpe/math-emu.o >arch/arm/lib/lib.a /home/green/arm/cvs/linux/kernel/lib/lib.a >/skiff/local/lib/gcc-lib/arm-linux/2.95.2/soft-float/libgcc.a \ > --end-group \ > -o vmlinux > arm-linux-ld: cannot open drivers/net/pcmcia/pcmcia_net.o: No such file or directory > make: *** [vmlinux] Error 1 > > And Rules.make is almost identical to that in vanilla kernel (if someone is > interested). (almost means that it have rule on how to make .o files from .S) It is clear that, (1) your config has CONFIG_NET_PCMCIA, and appears to be ok (2) your linux/Makefile is correct, as the link statement includes pcmcia_net.o So that leaves us with drivers/net/Makefile and drivers/net/pcmcia/Makefile. drivers/net/Makefile is a potential problem source, perhaps the following change is not in your arch tree: subdir-$(CONFIG_NET_PCMCIA) += pcmcia If that statement exists in drivers/net/Makefile, you need to run a kernel build, and start staring at make output to see exactly why it is not building. -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6 PCMCIA NET modular build breakage
Hello! >> Seems like its something that appeared between 2.4.5 and 2.4.6. Anyone >> know the correct fix, other than reversing the change? KG> It should be fine. It is not. >> Since all net cards are modules, object list for pcmcia_net.o is empty and >> kernel can't be linked. KG> Could you reproduce this? (I don't think you can) Sure, I can. First thing I did was in fact to try and reproduce that. KG> Rules.make takes care of an empty $(obj-y) and builds an empty $(O_TARGET) KG> file in this case, so linking this in should work fine. Hmm (examining Makefile...) I see. So there cannot be usual targets before including Rules.make, and my copy of the tree have these. And if I move them after inclusion, everything builds just fine. Perhaps it should be documented somewhere. Well. So at the end it seems to be not a vanilla kernel problem. That's good. Bye, Oleg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6 PCMCIA NET modular build breakage
Hello! >> Seems like its something that appeared between 2.4.5 and 2.4.6. Anyone >> know the correct fix, other than reversing the change? AC> I build with all pcmcia network drivers modular on my test builds, what AC> am I missing here ? Well. As you might have noticed - this is build for StrongArm platform (and that's why I wrote this to SA port maintainer, not to linux-kernel at first). This is repeatable, of course, and it is started as of 2.4.6 upgrade: ... make[2]: Leaving directory `/home/green/arm/cvs/linux/kernel/arch/arm/fastfpe' make[1]: Leaving directory `/home/green/arm/cvs/linux/kernel/arch/arm/fastfpe' arm-linux-ld -p -X -T arch/arm/vmlinux.lds arch/arm/kernel/head-armv.o arch/arm/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/arm/kernel/kernel.o arch/arm/mm/mm.o arch/arm/mach-sa1100/sa1100.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/cdrom/driver.o drivers/mtd/mtdlink.o drivers/net/pcmcia/pcmcia_net.o drivers/net/wireless/wireless_net.o drivers/video/video.o \ net/network.o \ arch/arm/fastfpe/fast-math-emu.o arch/arm/nwfpe/math-emu.o arch/arm/lib/lib.a /home/green/arm/cvs/linux/kernel/lib/lib.a /skiff/local/lib/gcc-lib/arm-linux/2.95.2/soft-float/libgcc.a \ --end-group \ -o vmlinux arm-linux-ld: cannot open drivers/net/pcmcia/pcmcia_net.o: No such file or directory make: *** [vmlinux] Error 1 And Rules.make is almost identical to that in vanilla kernel (if someone is interested). (almost means that it have rule on how to make .o files from .S) My .config is below: CONFIG_ARM=y CONFIG_UID16=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_KMOD=y CONFIG_ARCH_SA1100=y CONFIG_SA1100_BITSY=y CONFIG_SA1100_USB=m CONFIG_SA1100_USB_NETLINK=m CONFIG_SA1100_USB_CHAR=m CONFIG_SA1100_REGMON=m CONFIG_CPU_32=y CONFIG_CPU_32v4=y CONFIG_CPU_SA1100=y CONFIG_DISCONTIGMEM=y CONFIG_CPU_FREQ=y CONFIG_HOTPLUG=y CONFIG_PCMCIA=m CONFIG_PCMCIA_SA1100=m CONFIG_NET=y CONFIG_SYSVIPC=y CONFIG_SYSCTL=y CONFIG_FPE_NWFPE=y CONFIG_FPE_FASTFPE=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_PM=y CONFIG_APM=m CONFIG_CMDLINE="keepinitrd" CONFIG_ALIGNMENT_TRAP=y CONFIG_MTD=y CONFIG_MTD_DEBUG=y CONFIG_MTD_DEBUG_VERBOSE=1 CONFIG_MTD_PARTITIONS=y CONFIG_MTD_BOOTLDR_PARTS=y CONFIG_MTD_CHAR=m CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_ADV_OPTIONS=y CONFIG_MTD_CFI_NOSWAP=y CONFIG_MTD_CFI_GEOMETRY=y CONFIG_MTD_CFI_B2=y CONFIG_MTD_CFI_B4=y CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y CONFIG_MTD_CFI_INTELEXT=y CONFIG_MTD_SA1100=y CONFIG_MTD_SA1100_KERNELSIZE=c CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETFILTER=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_NET_IPIP=y CONFIG_NET_IPGRE=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_INET_ECN=y CONFIG_IPV6=m CONFIG_IPV6_MOBILITY=m CONFIG_IPV6_MOBILITY_DEBUG=y CONFIG_IP6_NF_IPTABLES=m CONFIG_NETDEVICES=y CONFIG_PPP=m CONFIG_PPP_ASYNC=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_NET_RADIO=y CONFIG_WAVELAN=m CONFIG_ARLAN=m CONFIG_AIRONET4500=m CONFIG_AIRONET4500_NONCS=m CONFIG_PCMCIA_HERMES=m CONFIG_NET_WIRELESS=y CONFIG_NET_PCMCIA=y CONFIG_PCMCIA_3C589=m CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_FMVJ18X=m CONFIG_PCMCIA_PCNET=m CONFIG_PCMCIA_NMCLAN=m CONFIG_PCMCIA_SMC91C92=m CONFIG_PCMCIA_XIRC2PS=m CONFIG_NET_PCMCIA_RADIO=y CONFIG_PCMCIA_WVLAN=m CONFIG_IRDA=m CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m CONFIG_IRDA_ULTRA=y CONFIG_IRDA_OPTIONS=y CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y CONFIG_IRDA_DEBUG=y CONFIG_SA1100_FIR=m CONFIG_IDE=m CONFIG_BLK_DEV_IDE=m CONFIG_BLK_DEV_IDEDISK=m CONFIG_BLK_DEV_IDECS=m CONFIG_BLK_DEV_IDECD=m CONFIG_BLK_DEV_IDETAPE=m CONFIG_BLK_DEV_IDEFLOPPY=m CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=m CONFIG_SERIAL_SA1100=y CONFIG_SERIAL_SA1100_CONSOLE=y CONFIG_SA1100_DEFAULT_BAUDRATE=115200 CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=32 CONFIG_TOUCHSCREEN_BITSY=m CONFIG_H3600_STOWAWAY=m CONFIG_PROFILER=m CONFIG_MOUSE=m CONFIG_SA1100_RTC=m CONFIG_PCMCIA_SERIAL_CS=m CONFIG_VIDEO_DEV=m CONFIG_VIDEO_PROC_FS=y CONFIG_FAT_FS=m CONFIG_VFAT_FS=m CONFIG_JFFS2_FS=y CONFIG_JFFS2_FS_DEBUG=1 CONFIG_CRAMFS=m CONFIG_RAMFS=y CONFIG_PROC_FS=y CONFIG_DEVFS_FS=y CONFIG_DEVFS_MOUNT=y CONFIG_DEVPTS_FS=y CONFIG_EXT2_FS=m CONFIG_NFS_FS=m CONFIG_SUNRPC=m CONFIG_LOCKD=m CONFIG_SMB_FS=m CONFIG_MSDOS_PARTITION=y CONFIG_SMB_NLS=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_PC_KEYMAP=y CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y CONFIG_FB_SA1100=y CONFIG_FBCON_ADVANCED=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_FONTWIDTH8_ONLY=y CONFIG_FBCON_FONTS=y CONFIG_FONT_8x8=y CONFIG_SOUND=m CONFIG_SOUND_BITSY_UDA1341=m CONFIG_SOUND_UDA1341=m CONFIG_DEBUG_ERRORS=y Bye, Oleg - To
test
this is a test - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM in 2.4.7-pre hurts...
Jeff Garzik wrote: > > Oh this is a fun one :) > > When building gcc-2.96 RPM using gcc-2.96 under kernel 2.4.7 on alpha, > the system goes --deeply-- into swap. Not pretty at all. The system > will be 200MB+ into swap, with 200MB+ in cache! I presume this affects > 2.4.7-release also. > > System has 256MB of swap, and 384MB of RAM. > > Only patches applied are Rik's recent OOM killer friendliness patch, and > Andrea's ksoftirq patch. > > I ran "vmstat 3" throughout the build, and that output is attached. I > also manually ran "ps wwwaux >> ps.txt" periodically. This second > output is not overly helpful, because the system was swapping and > unuseable for the times when the 'ps' output would be most useful. Sorry, I forgot to mention that OOM killer kicked in twice. You can probably pick out the points where it kicked in, in the vmstat output. -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: ASUS CUV4X-D Dual CPU's - Failure to boot...
[EMAIL PROTECTED] wrote: > > In article <[EMAIL PROTECTED]> you >wrote: > > Dear Kernel People, > > A friend of mine has a new PC with an ASUS CUV4X-D motherboard > > and dual 1GHZ PIII's. ... > For several people the following works: > 1) Upgrade to the latest bios > 2) Change the "MPS" level in the bios. It can have 3 values "1.4" "1.1" and >"none". the default one doesn't work, one of the others does (but I >forgot which one) 1.1 works fine for me. I haven't had a problem with this board since upgrading the BIOS and changing the MPS version to 1.1. You can also specify "noapic" to the booting kernel. 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/
Re: [Acpi] Re: ACPI fundamental locking problems
Eugene Crosser wrote: > > In article <[EMAIL PROTECTED]>, > Alexander Viro <[EMAIL PROTECTED]> writes: > > >> Doesn't the approach "treat a chunk of data built into bzImage as > >> populated ramfs" look cleaner? No need to fiddle with tar format, > >> no copying data from place to place. > > > > What the hell _is_ "populated ramfs"? The thing doesn't live in array > > of blocks. Its directory structure consists of a bunch of dentries. > > I am stupid. But the point still stays: having an image of pre-populated > filesystem (some other than ramfs) that you only need to load into > RAM seems more sutable than parsing tar format. Maybe (probably) I am > missing something. Yeah -- we build all this stuff dynamically. struct file, struct inode, etc. You could store them on disk as they would be represented in memory, but this would be incredibly inefficient because of all the runtime structures unnecessary on disk, and because of all the fixups and checks you would have to perform on the data in the images after they magically appear in memory. Reading a tarball is the distillation of what you describe into efficient form :) -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VM in 2.4.7-pre hurts...
Oh this is a fun one :) When building gcc-2.96 RPM using gcc-2.96 under kernel 2.4.7 on alpha, the system goes --deeply-- into swap. Not pretty at all. The system will be 200MB+ into swap, with 200MB+ in cache! I presume this affects 2.4.7-release also. System has 256MB of swap, and 384MB of RAM. Only patches applied are Rik's recent OOM killer friendliness patch, and Andrea's ksoftirq patch. I ran "vmstat 3" throughout the build, and that output is attached. I also manually ran "ps wwwaux >> ps.txt" periodically. This second output is not overly helpful, because the system was swapping and unuseable for the times when the 'ps' output would be most useful. Both outputs are attached, as they compressed pretty nicely. -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | vmstat.txt.bz2 ps.txt.bz2
Re: [Acpi] Re: ACPI fundamental locking problems
In article <[EMAIL PROTECTED]>, Alexander Viro <[EMAIL PROTECTED]> writes: >> Doesn't the approach "treat a chunk of data built into bzImage as >> populated ramfs" look cleaner? No need to fiddle with tar format, >> no copying data from place to place. > > What the hell _is_ "populated ramfs"? The thing doesn't live in array > of blocks. Its directory structure consists of a bunch of dentries. I am stupid. But the point still stays: having an image of pre-populated filesystem (some other than ramfs) that you only need to load into RAM seems more sutable than parsing tar format. Maybe (probably) I am missing something. Eugene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Does kernel require IDE enabled in BIOS to access HD, FS errors?
Jim, Thanks for the info, comments interleaved below Thanks Martin Jim Roland wrote: > > Activating an IDE drive in an older BIOS (newer ones have a SCSI option in > the "A/C/CDROM" options) will always force an IDE drive boot with older > BIOSes. Older BIOSes are written to stop looking for a boot device once it > has found one, and it's own IDE is where it says "Ok, I have boot > capability", otherwise no IDE drive, means it passes boot control to other > system BIOSes (like your SCSI or NIC cards). This is by default with older > systems. This behavior is acceptable, as I can as you suggest move the kernel to the IDE and tell it the root device is /dev/md0. Actually that is what I did to a floppy to get access to the system while the BIOS was set to detect the IDE drives. Since I only boot whenever Linus puts out a new kernel that isn't so much of a concern. > > I expect someone will rebut my comments about the kernel (which is fine, I'm > not a Kernel hacker--PROPERLY USED TERM HERE (not the media's term) ), > but it is my understanding that the kernel uses your system BIOS for actual > reads/writes at the hardware level, this way it does not have to account for > EVERY possible BIOS out there. (Other OSes use BIOS system calls for this > purpose as well) When you turn BIOS to the OS does what it can, but > the BIOS in your system *SHOULD* refuse to process the call, instead it's > doing the read/writes, but not the same way as if IDE was turned on. But, that's kind of the point I'm driving at if the OS can't correctly access the IDE interface it shouldn't do it at all. My guess is that the CMD64X driver is broken since the system can write data to the HD but with random corruption. Ditto for reading data. Likewise, why would I see an increase in write performance when "dd if=/dev/zero of=/dev/null" is running simultaneously on another console. > Are you getting IDE corruption with the BIOS set to for your IDE > drive? None whatsoever. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6 PCMCIA NET modular build breakage
On Sat, 7 Jul 2001, Russell King wrote: > Seems like its something that appeared between 2.4.5 and 2.4.6. Anyone > know the correct fix, other than reversing the change? It should be fine. > Since all net cards are modules, object list for pcmcia_net.o is empty and > kernel can't be linked. Could you reproduce this? (I don't think you can) Rules.make takes care of an empty $(obj-y) and builds an empty $(O_TARGET) file in this case, so linking this in should work fine. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rtl8139 dhcp-autoconfiguration problem
hi, > did you boot with ip=bootp or ip=dhcp or ip=rarp? no, i didn't - it seems to be that this is required for kernels >2.2.17. -> now it works - thanks a lot! greets, albert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Does kernel require IDE enabled in BIOS to access HD, FS errors?
Activating an IDE drive in an older BIOS (newer ones have a SCSI option in
the "A/C/CDROM" options) will always force an IDE drive boot with older
BIOSes. Older BIOSes are written to stop looking for a boot device once it
has found one, and it's own IDE is where it says "Ok, I have boot
capability", otherwise no IDE drive, means it passes boot control to other
system BIOSes (like your SCSI or NIC cards). This is by default with older
systems.
I expect someone will rebut my comments about the kernel (which is fine, I'm
not a Kernel hacker--PROPERLY USED TERM HERE (not the media's term) ),
but it is my understanding that the kernel uses your system BIOS for actual
reads/writes at the hardware level, this way it does not have to account for
EVERY possible BIOS out there. (Other OSes use BIOS system calls for this
purpose as well) When you turn BIOS to the OS does what it can, but
the BIOS in your system *SHOULD* refuse to process the call, instead it's
doing the read/writes, but not the same way as if IDE was turned on.
My suggestion is that you install the OS onto the IDE drive, let it boot,
and use it for a boot only drive. Mount user data from your SCSI drive onto
the IDE's mount points. Otherwise, since your reason for doing this is that
you're out of space, add another SCSI drive.
Are you getting IDE corruption with the BIOS set to for your IDE
drive?
Regards,
Jim Roland, RHCE
- Original Message -
From: "M.H.VanLeeuwen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, July 07, 2001 12:25 AM
Subject: Does kernel require IDE enabled in BIOS to access HD, FS errors?
> Hi,
>
> I have a SMP P166 system that has been running for years with an AIC7xxx
SCSI card as
> opposed to the native IDE interface. The BIOS has the IDE 0,1,2,3 set to
.
> Running out of disk space I installed one of the original IDE drives. The
kernel
> booted and ID'd the drive correctly. Kernel version 2.4.5/6 behave the
same.
>
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
> CMD646: IDE controller on PCI bus 00 dev 10
> CMD646: chipset revision 1
> CMD646: not 100% native mode: will probe irqs later
> CMD646: chipset revision 0x01, MultiWord DMA Limited, IRQ workaround
enabled
> CMD646: simplex device: DMA disabled
> ide0: CMD646 Bus-Master DMA disabled (BIOS)
> CMD646: simplex device: DMA disabled
> ide1: CMD646 Bus-Master DMA disabled (BIOS)
> hdb: CD-ROM CDU76E, ATAPI CD/DVD-ROM drive
> ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
> hdc: WDC AC2850F, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hdc: 1667232 sectors (854 MB) w/64KiB Cache, CHS=1654/16/63
> hdb: packet command error: status=0x51 { DriveReady SeekComplete Error }
> hdb: packet command error: error=0x44
> hdb: ATAPI 4X CD-ROM drive, 256kB Cache
> Uniform CD-ROM driver Revision: 3.12
> Partition check:
> hdc: [PTBL] [827/32/63] hdc1
>
> However I can't boot from the SCSI drives if the IDE HD is enabled due to
deficiencies
> in the BIOS... boot "A: then C:" or "C: then A:" are the only choices, if
neither are
> present the system boots from the SCSI card, otherwise it fails to boot.
>
> PROBLEM: cannot reliably R/W to the HD unless the BIOS is set to
recognize.
> I consistently see MD5SUM errors and FS corruption and other strange FS
symptoms
> when the BIOS is set to for the drive and _never_ see any errors
with the
> setting set to . There are no messages emitted by the kernel that
there
> were any system errors encountered leading one to believe that all is
well, when
> it isn't.
>
> What is interesting, is that the I/O writes increase from once every 14
seconds to
> once every 2-3 seconds and the FS corruption diminishes but don't
disappear
> if a background "dd if=/dev/zero of=/dev/null" is running.
>
> Is this expected kernel behavior?
>
> VMSTAT follow... when copying files from SCSI drives to IDE drive.
>
> More info available if needed...
>
> Thanks,
> Martin
>
> The waiting processes are kupdated and bdflush. (I have Alt-SysRq- trace
of them)
>
> VMSTAT 1 for the case w/ BIOS set to looks like (w/o dd running):
>
>procs memoryswap io system
cpu
> r b w swpd free buff cache si sobibo incs us
sy id
> 0 0 0 0 83180 1056 39800 0 0 261 3 8343 5
8 87
> 0 0 0 0 83176 1056 39800 0 0 0 0 11920 3
2 95
> 0 0 0 0 83176 1056 39800 0 0 0 0 11620 2
2 96
> 0 1 0 0 83012 1096 39812 0 0 329 0 196 183 3
8 89
> 0 1 0 0 81268 1128 41444 0 0 1021 0 309 275 3
17 80
> 0 1 0 0 74464 1200 47716 0 0 313127 292 264 6
25 69
> 2 0 0 0 67772 1276 53632 0 0 2962 0 397 245 12
25 63
> 2 0 0 0 64016 1324 56900 0
Re: rtl8139 dhcp-autoconfiguration problem
Albert Weichselbraun wrote: > > On 2001-07-07 at 08:26:49 -0400, Jeff Garzik wrote: > > Can you try 2.4.6 please? > done. > - sorry, but 2.4.6 doesn't work either. > > > ... > 8139too Fast Ethernet driver 0.9.18-pre4 > PCI: Found IRQ 10 for device 00:09.0 > eth0: RealTek RTL8139 Fast Ethernet at 0xe080, 00:00:21:fa:20:ce, IRQ 10 > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP > IP: routing cache hash table of 4096 buckets, 32 Kbytes > TCP: Hash table configured (established 32768 bind 32768) > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > Root-NFS: No NFS server available, giving up. > ... > did you boot with ip=bootp or ip=dhcp or ip=rarp? -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: rtl8139 dhcp-autoconfiguration problem
On 2001-07-07 at 08:26:49 -0400, Jeff Garzik wrote: > Can you try 2.4.6 please? done. - sorry, but 2.4.6 doesn't work either. ... 8139too Fast Ethernet driver 0.9.18-pre4 PCI: Found IRQ 10 for device 00:09.0 eth0: RealTek RTL8139 Fast Ethernet at 0xe080, 00:00:21:fa:20:ce, IRQ 10 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 4096 buckets, 32 Kbytes TCP: Hash table configured (established 32768 bind 32768) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Root-NFS: No NFS server available, giving up. ... greets, albert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
rtl8139 dhcp-autoconfiguration problem
hi, i'm experiencing problems using dhcp-autoconfiguration with rtl8139-network cards and kernels >2.2.17. - it seems to be, that the kernel tries to mount the nfs-root-directory, before fetching the nodes-ip-address via dhcp (the logs from dhcpd indicate, that the node doesn't even try to fetch an ip-address). ... rtl8139.c:v1.07 5/6/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html eth0: RealTek RTL8139 Fast Ethernet at 0xe000, IRQ 15, 00:02:44:16:41:0b. Root-NFS: No NFS server available, giving up. ... ... eth0: 8139too FastEthernet driver 0.9.14-2.2 Jeff Garzik <[EMAIL PROTECTED]> eth0: Linux-2.2 bug reports to Jens David <[EMAIL PROTECTED]> eth0: RealTek RTL8139 Fast Ethernet board found at 0xe0800, IRQ 10 eth0: Chip is 'RTL-8139B' - MAC address '00:00:21:fa:20:ce'. Root-NFS: No NFS server available, giving up. ... ... 8139too Fast Ethernet driver 0.9.17 PCI: Found IRQ 10 for device 00:09.0 eth0: RealTek RTL8139 Fast Ethernet at 0xe080, 00:00:21:fa:20:ce, IRQ 10 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 4096 buckets, 32 Kbytes TCP: Hash table configured (established 32768 bind 32768) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Root-NFS: No NFS server available, giving up. ... using the same kernel-config with kernels <= 2.2.17 works without any problems. ... rtl8139.c:v1.07 5/6/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html eth0: RealTek RTL8139 Fast Ethernet at 0xe000, IRQ 15, 00:02:44:16:41:0b. Sending DHCP requests .. OK IP-Config: Got DHCP answer from 192.168.109.51 IP-Config: Complete: device=eth0, addr=192.168.109.46, mask=255.255.255.128, gw=192.168.109.1, host=192.168.109.46, domain=in-vienna.iaeste.or.at, nis-domain=(none), bootserver=192.168.109.51, rootserver=192.168.109.51, rootpath= Looking up port of RPC 13/2 on 192.168.109.51 Looking up port of RPC 15/1 on 192.168.109.51 VFS: Mounted root (NFS filesystem). Freeing unused kernel memory: 40k freed ... the kernel-config and dmesg output are available under http://www.iaeste.or.at/cc/8139/ any hints, what might be wrong? greets, albert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Athlon oops traced to CONFIG_MK7 code in arch/i386/lib/mmx.c
> I'm interested if there is an explanation of the MK7 specific code in mmx.c and > whether that could really be the source of the problem. I would like to get > to the bottom of this. As far as we can tell the problem is 'using a VIA chipset'. The code itself is a fast copying loop using mmx/3dnow/amd athlon extended mmx stuff Pick up an Athlon documentation set (pdf on the web site) and you should be able to follow it. prefetch does what you'd expect, sfence is a store fence for non temporal stores (ie out of order stuff) amd movntq is an out of order move > FWIW - the RedHat 7.1 stock 2.4.2 athlon kernel boots successfully without oopsen. That doesn't have CONFIG_MK7k - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6 PCMCIA NET modular build breakage
> Seems like its something that appeared between 2.4.5 and 2.4.6. Anyone > know the correct fix, other than reversing the change? I build with all pcmcia network drivers modular on my test builds, what am I missing here ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 patch process
> Can anyone let me know the steps for making/submitting > a linux kernel patch ? What is the difference between man diff Use the diff -u options > an unofficial patch and an official patch ? I guess it depends who made it, who likes it and who you trust 8) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: ASUS CUV4X-D Dual CPU's - Failure to boot...
>A friend of mine has a new PC with an ASUS CUV4X-D motherboard > and dual 1GHZ PIII's. We have installed RedHat 7.1. The original > RedHat SMP kernel (2.4.2) did not boot; it froze with some complaints You need at least bios rev 1007 I believe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: drivers/ide/sl82c105.c
> I am wondering who maintains drivers/ide/sl82c105.c, and who sent in
> the recent changes to it. We now have, at around line 278, this code:
>
> unsigned int pci_init_sl82c105(struct pci_dev *dev, const char *msg)
> {
> return ide_special_settings(dev, msg);
> }
>
> The call to ide_special_settings gives a link error because
The IDE stuff isnt fully merged right now. There are some quite tricky things
to sort out there.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 region check in drivers/pcmcia/rsrc_mgr.c
Paul Mackerras wrote: > In drivers/pcmcia/rsrc_mgr.c, there is code that check whether a given > range of PCI memory addresses are available for the pcmcia code to > use. This code uses a macro, check_mem_resource(), to check whether a > particular region is available, defined like this: > > #define check_mem_resource(b,n) check_resource(_resource, (b), (n)) [...] > I think that > we should be using check_mem_region instead, AFAICS you are correct. check_xxx is deprecated, though. Is it possible to move a request_xxx earlier in the logic? check_xxx is inherently racy. -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 region check in drivers/pcmcia/rsrc_mgr.c
In drivers/pcmcia/rsrc_mgr.c, there is code that check whether a given range of PCI memory addresses are available for the pcmcia code to use. This code uses a macro, check_mem_resource(), to check whether a particular region is available, defined like this: #define check_mem_resource(b,n) check_resource(_resource, (b), (n)) This code is now causing me problems on my powerbook because we now register the regions mapped by each PCI host bridge in the iomem_resource structure. The basic problem is that check_resource only checks at the top level of the iomem_resource tree. I think that we should be using check_mem_region instead, which will descend the tree until it finds out whether the region is actually in use or not. The patch below does this (and makes a similar correction for I/O space). With this patch applied, the pcmcia stuff works fine on my powerbook, and I end up with something like this in /proc/iomem: 8000-afff : /pci@f200 8000-8007 : Apple Computer Inc. KeyLargo Mac I/O 9000-9fff : PCI CardBus #02 a000-afff : Texas Instruments PCI1211 a0001000-a0001fff : Apple Computer Inc. KeyLargo USB (#2) a0001000-a0001fff : usb-ohci a0002000-a0002fff : Apple Computer Inc. KeyLargo USB a0002000-a0002fff : usb-ohci a700-a7000fff : card services b000-bfff : /pci@f000 b000-b0003fff : ATI Technologies Inc Mobility M3 AGP 2x b000-b0003fff : aty128fb MMIO b400-b7ff : ATI Technologies Inc Mobility M3 AGP 2x b400-b7ff : aty128fb FB f100-f1ff : /pci@f000 f300-f3ff : /pci@f200 f300-f33f : PCI CardBus #02 f500-f5ff : /pci@f400 f500-f5000fff : Apple Computer Inc. UniNorth FireWire f520-f53f : Apple Computer Inc. UniNorth GMAC Linus, would you apply this patch to your tree? Paul. diff -urN linux/drivers/pcmcia/rsrc_mgr.c pmac/drivers/pcmcia/rsrc_mgr.c --- linux/drivers/pcmcia/rsrc_mgr.c Sat Mar 31 03:06:19 2001 +++ pmac/drivers/pcmcia/rsrc_mgr.c Wed Jun 20 14:25:25 2001 @@ -104,8 +104,8 @@ ==*/ -#define check_io_resource(b,n) check_resource(_resource, (b), (n)) -#define check_mem_resource(b,n)check_resource(_resource, (b), (n)) +#define check_io_resource(b,n) check_region((b), (n)) +#define check_mem_resource(b,n)check_mem_region((b), (n)) /*== - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel patch process
On Fri, Jul 06, 2001 at 11:28:35PM -0700, Satish Kumar wrote: > Can anyone let me know the steps for making/submitting > a linux kernel patch ? What is the difference between > an unofficial patch and an official patch ? See Documentation/SubmittingPatches in your kernel tree. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
Eugene Crosser wrote: > > In article <[EMAIL PROTECTED]>, > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > I don't like the current initrd very much myself, I have to admit. I'm not > > going to accept a "you have to have a ramdisk" approach - I think the > > ramdisks are really broken. > > > > But I've seen a "populate ramfs from a tar-file built into 'bzImage'" > > patch somewhere, and that would be a whole lot more palatable to me. > > Doesn't the approach "treat a chunk of data built into bzImage as > populated ramfs" look cleaner? No need to fiddle with tar format, > no copying data from place to place. So tell me, how do you populate ramfs without a format which tells you what path and which permissions to assign each file? That's exactly what tar is. -- Jeff Garzik | A recent study has shown that too much soup Building 1024| can cause malaise in laboratory mice. MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Acpi] Re: ACPI fundamental locking problems
On 7 Jul 2001, Eugene Crosser wrote: > Doesn't the approach "treat a chunk of data built into bzImage as > populated ramfs" look cleaner? No need to fiddle with tar format, > no copying data from place to place. What the hell _is_ "populated ramfs"? The thing doesn't live in array of blocks. Its directory structure consists of a bunch of dentries. Permissions/ownership/timestamps are in a bunch of struct inode - sitting in icache and allocated in normal way. Regular files are entirely in pagecache, ditto for symlinks. Ramfs has no backing store. At all. That's precisely what remains of filesystem if you take backing store away - everything is in VFS/VM caches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] I/O Access Abstractions
On Tue, 3 Jul 2001, David Howells wrote:
> > The question I think being ignored here is. Why not leave things as is. The
> > multiple bus stuff is a port specific detail hidden behind readb() and
> > friends.
>
> This isn't so much for the case where the address generation is done by a
> simple addition. That could be optimised away by the compiler with an entirely
> inline function (as per David Woodhouse's suggestion).
>
> It's far more important for non-x86 platforms which only have a single address
> space and have to fold multiple external address spaces into it.
>
> For example, one board I've got doesn't allow you to do a straight
> memory-mapped I/O access to your PCI device directly, but have to reposition a
> window in the CPU's memory space over part of the PCI memory space first, and
> then hold a spinlock whilst you do it.
This is a common practice on NEC PCI host bridges: usually you have 2 `windows'
to the PCI bus only, so you can have direct access to only two of PCI memory,
PCI I/O and PCI config spaces at the same time. If you need access to the
third, you have to reconfigure the windows. Usually you configure the windows
to have direct access to PCI memory and PCI I/O spaces. So PCI config space
takes the hit. If you have only one window, YMMV.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] I/O Access Abstractions
On Tue, 3 Jul 2001, David Howells wrote:
> * It should make drivers easier to write: they don't have to worry about
>whether a resource refers to memory or to I/O or to something more exotic.
>
> * It makes some drivers more flexible. For example, the ne2k-pci driver has
>to be set at _compile_ time to use _either_ I/O ports _or_ memory. It'd
>make Linux installation more better if _both_ were supported.
>
> * It'd allow some drivers to be massively cleaned up (serial.c).
And the IDE driver.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Trouble Booting Linux PPC 2000 On Mac G4
>I think what we are seeing is XBoot rather than yaboot and we tried just >about all conceivable "kernel options", as exposed by Xboot. When Xboot >comes up it shows a ramdisk_size=8192 as the only default parameter. >Rapidly growing to hate the non-intuitive nature of the MAC OS we are >not experts on the Mac OS. P.S. We are running Mac OS 9.1. > >Oops, We just discovered that Xboot does not work with MacOS 9.1 (geez) > you MUST use yaboot. It's a generic issue with BootX (MacOS "takeover" bootloader). It won't work reliably with any recent machine, you should use the more complicated but safer OpenFirmware way of booting, either using yaboot or directly booting the CHRP ELF zImage. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Acpi] Re: ACPI fundamental locking problems
In article <[EMAIL PROTECTED]>, Linus Torvalds <[EMAIL PROTECTED]> writes: > I don't like the current initrd very much myself, I have to admit. I'm not > going to accept a "you have to have a ramdisk" approach - I think the > ramdisks are really broken. > > But I've seen a "populate ramfs from a tar-file built into 'bzImage'" > patch somewhere, and that would be a whole lot more palatable to me. Doesn't the approach "treat a chunk of data built into bzImage as populated ramfs" look cleaner? No need to fiddle with tar format, no copying data from place to place. Eugene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: device plugging
On Sat, Jul 07 2001, gopi krishna wrote: > Why do we need a dummy req for plugging. > As i understood only thing plugging does is to, on arrival of new req if > the dev queue is empty, puts a dummy req on the queue, and schedules the > unplug routine on tq_disk, which on being scheduled calls the strategy > routine. You are reading 2.2 sources, maybe try the 2.4 sources as they are easier to follow in this regard IMHO. What happens is that we assign dev->current_request >plug, so that the front request is recognizable as the 'plug' and not a valid request. You seem to completely misunderstand plugging -- if we just put the new request on the queue and scheduled tq_disk, then there would be no plugging going on at all. What we do instead is add this specific 'plug request' and queue lots of stuff behind that. Not until someone needs the data on the queue is the 'plug request' removed and the request_fn run. This happens for instance if _someone else_ calls tq_disk, typically __wait_on_buffer. > So we can as well put the new req on the queue without dummy req. Wrong > If i'm incorrect please explain what's exact process and the reason See? -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS (kswapd) in 2.4.5 and 2.4.6
Henry wrote: > > > > > I wonder why it only affects you. Is the drive which holds > > your swap partition running in PIO mode? `hdparm' will tell > > you. If it is, then that could easily cause the page to come > > unlocked before brw_page() has finished touching the buffer > > ring. Then all it takes is a parallel try_to_free_buffers > > on the other CPU. > > Here's output from htparm: > > /dev/hda: > multcount= 0 (off) > I/O support = 0 (default 16-bit) > unmaskirq= 0 (off) > using_dma= 0 (off) > keepsettings = 0 (off) > nowerr = 0 (off) > readonly = 0 (off) > readahead= 8 (on) > geometry = 2494/255/63, sectors = 40079088, start = 0 > > Does this provide the info you need? Bingo. PIO mode -> synchronous writes in submit_bh(). Thanks. > I believe another chap responded to my post with a similar issue (also > SMP machine). No, his oops was a bad inode state while trying to release unused NFS client inodes. Different bug :) - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS (kswapd) in 2.4.5 and 2.4.6
> > I wonder why it only affects you. Is the drive which holds > your swap partition running in PIO mode? `hdparm' will tell > you. If it is, then that could easily cause the page to come > unlocked before brw_page() has finished touching the buffer > ring. Then all it takes is a parallel try_to_free_buffers > on the other CPU. Here's output from htparm: /dev/hda: multcount= 0 (off) I/O support = 0 (default 16-bit) unmaskirq= 0 (off) using_dma= 0 (off) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead= 8 (on) geometry = 2494/255/63, sectors = 40079088, start = 0 Does this provide the info you need? I believe another chap responded to my post with a similar issue (also SMP machine). Uptime now 21:55 with no oops. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.6 PCMCIA NET modular build breakage
Seems like its something that appeared between 2.4.5 and 2.4.6. Anyone know the correct fix, other than reversing the change? - Forwarded message from Nicolas Pitre <[EMAIL PROTECTED]> - -- Forwarded message -- Date: Fri, 6 Jul 2001 12:17:54 +0400 From: Oleg Drokin <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: 2.4.6-rmk1-np1 breakage Hello! these sevaral bits from latest patch do not allow kernel to build when PCMCIA netcard is selected, but all if the cards are selected as modules diff -uNr linux-2.4.5-rmk7-np1/drivers/net/pcmcia/Config.in linux-2.4.6-rmk1-np1/drivers/net/pcmcia/Config.in --- linux-2.4.5-rmk7-np1/drivers/net/pcmcia/Config.in Mon May 28 10:21:00 2001 +++ linux-2.4.6-rmk1-np1/drivers/net/pcmcia/Config.in Wed Jul 4 10:47:46 2001@@ +-32,13 +32,4 @@ fi fi -if [ "$CONFIG_PCMCIA_3C589" = "y" -o "$CONFIG_PCMCIA_3C574" = "y" -o \ - "$CONFIG_PCMCIA_FMVJ18X" = "y" -o "$CONFIG_PCMCIA_PCNET" = "y" -o \ - "$CONFIG_PCMCIA_NMCLAN" = "y" -o "$CONFIG_PCMCIA_SMC91C92" = "y" -o \ - "$CONFIG_PCMCIA_XIRC2PS" = "y" -o "$CONFIG_PCMCIA_RAYCS" = "y" -o \ - "$CONFIG_PCMCIA_NETWAVE" = "y" -o "$CONFIG_PCMCIA_WAVELAN" = "y" -o \ - "$CONFIG_PCMCIA_XIRTULIP" = "y" ]; then - define_bool CONFIG_PCMCIA_NETCARD y -fi And this bit for top level Makefile -DRIVERS-$(CONFIG_PCMCIA_NETCARD) += drivers/net/pcmcia/pcmcia_net.o +DRIVERS-$(CONFIG_NET_PCMCIA) += drivers/net/pcmcia/pcmcia_net.o Since all net cards are modules, object list for pcmcia_net.o is empty and kernel can't be linked. Bye, Oleg - End forwarded message - -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ASUS CUV4X-D Dual CPU's - Failure to boot...
In article <[EMAIL PROTECTED]> you wrote: > Dear Kernel People, > A friend of mine has a new PC with an ASUS CUV4X-D motherboard > and dual 1GHZ PIII's. We have installed RedHat 7.1. The original > RedHat SMP kernel (2.4.2) did not boot; it froze with some complaints > about APIC. The backup single processor kernel 2.4.2 booted o.k., > however. The upgraded kernel from RedHat (2.4.3) also refused to boot > properly - the boot up will start and the screen will then go blank > before I can discern any informative messages. I also downloaded the > latest 2.4.6 kernel which had the identical problem, and then I also > applied the latest Alan-Cox patch for 2.4.6 which did not solve the > problem. The 2.4.6 kernel will boot when only a single processor > is used, however. For several people the following works: 1) Upgrade to the latest bios 2) Change the "MPS" level in the bios. It can have 3 values "1.4" "1.1" and "none". the default one doesn't work, one of the others does (but I forgot which one) Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Athlon oops traced to CONFIG_MK7 code in arch/i386/lib/mmx.c
On Sat, Jul 07, 2001 at 09:10:46AM -0800, Richard Chan wrote: > Athlon oops saga continues - I consistently get Athlon kernels oopsing > during the boot up process either in rc.sysinit or loading of usb modules > (this is a RedHat system 7.1). These kernels can boot to a shell init=/bin/sh > but once I try to do stuff like inserting modules they oops left, right, and centre. > What motherboard, how big is your PSU ? This code has the tendency to get full memory-bandwidth and it appears that some boards can't handle this Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS (kswapd) in 2.4.5 and 2.4.6
Henry wrote: > > ... > So far, so good. There has not been a single oops on the two principle > servers I patched. > > uptime1:8:04am up 18:22, 1 user, load average: 0.09, 0.15, 0.11 > uptime2:8:04am up 18:25, 1 user, load average: 0.15, 0.20, 0.15 OK, that looks good. > Andrew my china, you are the _MAN_! Not only that - I have great legs! > We should know by monday afternoon > (the monday morning/midday crunch should provide some valuable > feedback). I wonder why it only affects you. Is the drive which holds your swap partition running in PIO mode? `hdparm' will tell you. If it is, then that could easily cause the page to come unlocked before brw_page() has finished touching the buffer ring. Then all it takes is a parallel try_to_free_buffers on the other CPU. There's a similar bug in __block_write_full_page(). I'll send a patch... - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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?] vtund broken by tun driver changes in 2.4.6
I recently upgraded a server running vtund 2.4 (4/18/01) to stock 2.4.6 kernel. It seems the changes to the tun driver have broken vtund. Now my syslog gets filled with the following messages when a client attempts to connect: Jul 5 10:15:53 mackman vtund[4011]: Session mackman-vpn[64.169.117.25:2359] opened Jul 5 10:15:53 mackman vtund[4011]: Can't allocate tun device. File descriptor in bad state(77) Jul 5 10:15:53 mackman vtund[4011]: Session mackman-vpn closed Jul 5 10:16:04 mackman vtund[4014]: Session mackman-vpn[64.169.117.25:2360] opened Jul 5 10:16:04 mackman vtund[4014]: Can't allocate tun device. File descriptor in bad state(77) Jul 5 10:16:04 mackman vtund[4014]: Session mackman-vpn closed Eventually the client gives up. Do you have any suggestions or know of any fixes? Thanks, Ryan Mack - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
