Re: OOPS (kswapd) in 2.4.5 and 2.4.6
> > > > FYI, I see a similar problem under 2.4.5, also SMP, although only > > intermittently. Two oopses are below, from two different, although > > similarly configured, machines. > > [snip] > > Sounds very similar. Our servers are all identical (except for RAM). > > What's unusual is that the machines we *expect* to fail sooner - don't > (not even an oops). Those are very busy cache servers (several of them > in a sibling cluster) which do a lot of swapping. The machines which > *do* fail (or oops without any further catastrophe) are typically > web/mail hosting servers (reasonably busy with about 25% swap being > used). Increasing swap did not help on 2.4.5. We're still waiting for > something to happen on 2.4.6 (ie, oops already appeared - waiting for > meltdown, which, hopefully, will not occur). We used to auto-reboot > every morning at 2am or something to keep things stable - which I > *hate* because I remember having a 2.0.35/6 workstation that had an > uptime of 6 months a couple of years ago. God, I loved that box. > It's happened again. The server which previously failed with memory errors, has failed again and required a reboot. It was using 26% swap, and apache would fail to start with 'semget: No space left on device'. What we also noticed was that the kswapd process showed 'defunct' on ps... mean anything to anyone? Regards Henry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: floating point problem
[EMAIL PROTECTED] writes: > In Linux PPC, the MSR[FP] bit (that is floating point available bit) is off > (atleast for non-SMP). > > Due to this, whenever some floating point instruction is executed in 'user > mode', it leads to a exception 'FPUnavailable'. The exception handler for Yes, this is so that we don't have to save and restore the floating point registers on every context switch. > this exception apart from setting the MSR[FP] bit, also sets the MSR[FE0] > and MSR[FE1] bits. These bits basically enables the floating point > exceptions so that if there are some floating point exception conditions > encountered while exeuting a floating point instruction, an appropriate > exception is raised. You have control at user-level over whether the cpu will take an exception (leading to a SIGFPE signal) or not by means of the FPSCR register. The VE, OE, UE, ZE and XE bits in the FPSCR control whether the cpu will take an exception on floating-point invalid operation, overflow, underflow, divide by zero and inexact result respectively. If the kernel cleared the FE0 and FE1 bits, there would be no way for an application to get a signal when a floating-point error occurred. With FE0 and FE1 set, the application can control this using the FPSCR, and get a signal, or not, as it prefers. > But whenever some floating point instruction is executed in 'kernel mode', > 'FPUnavailabe' exception handler code does not set the 'MSR[FE0] and > MSR[FE1]' bits. Floating point is not intended to be used in the kernel except in a couple of specific places. > Problem is that we want to get the good results without changing the > kernel. Either by having the user mode application to interact with some > special module which can set the MSR[FP] bit before we execute the floating > point instruction or by some other trick.Is there any solution apart > from changing the kernel? Clear the appropriate bits in the FPSCR. There is almost certainly a glibc interface to do this but I don't know what it would be. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Acpi] Re: ACPI fundamental locking problems
Jeff writes: > I've always thought it would be neat to do: > > cat bzImage initrd.tar.gz > vmlinuz > rdev --i-have-a-tarball-piggyback vmlinuz > > Linking into the image is easy for hackers, but why not make it > scriptable and super-easy for end users? x86 already has the rdev > utility to mark a kernel image as having certain flags. It could even > be a command line option, "inittgz" or somesuch, telling us that a > gzip-format tarball immediately follows the end of our ELF image. This would be especially handy for network booting: you only need to send the one file to the client, and it boots the kernel and loads the initrd without any extra requests/parameters/configuration needed. > I wonder if any bootloader mods would be needed at all to do this... > AFAICS you just need to make sure the kernel doesn't trample the > piggyback'd data. Probably not - the kernel would handle all of it. It sounds like Linus and Al are in favour of this, so it will likely be in 2.5.early. Having the tar be extracted into ramfs has the added benefit that you don't need to 'pre-configure' ramdisk size, make dd initrd images, or waste memory that is representing empty fs space. Conversely, if the root is ramfs you also don't need to worry about the ramdisk fs being too small if you need to create some temprary files there... It is a win in all cases. Cheers, Andreas -- Andreas Dilger Turbolinux filesystem development http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
Trevor Hemsley wrote: > > On Thu, 5 Jul 2001 03:06:11, Erik Mouw <[EMAIL PROTECTED]> > wrote: > > > Hmm, Cardbus and USB problems... you probably have both Cardbus and > > i82365 support in your kernel configuration. > > Once I have the BIOS set to "cardbus/16 bit" instead of "auto-detect" > I don't have a problem with having both Cardbus and i82365 support > compiled in. If the BIOS is set to auto then the PCI tables don't have > an IRQ specified and yenta.c uses IRQ 0! Interesting... That sounds like the kernel's plug-n-play code isn't doing its job. -- Jeff Garzik | Thalidomide, eh? Building 1024| So you're saying the eggplant has an accomplice? 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: max sizes for files and file systems
Derek Vadala writes: > It's clear that under 2.4, the kernel imposes a limit of 2TB as the > maximum file size and that some portion of the kernels before 2.4 had a > limit of 2GB. > > However, it's not clear to me when the file size limit was increased, or > what the maximum file system sizes under 2.0, 2.2 and 2.4 are. I realize > that both of these values are also contingent on the filesystem used, but > I'm wondering about what limits the kernel itself imposes. > > I'm also a bit unclear as to where the 2GB limit in kernels < 2.4 comes > from. It appears to be a kernel imposed limit, but there also seems to be > a lot conflicting information out there, blaming the problem on > EXT2. However, from what I can tell, 2.0.39, 2.2.19 and 2.4.5 all use the > same version (0.5b-95/08/09) of ext2-- either that or EXT2FS_VERSION and > EXT2FS_DATE in .../include/linux/ext2_fs.h simply haven't been updated. No 32-bit Linux system could exceed 1 TB on anything until this week. This is caused by signed 32-bit math on units of 512 bytes. Now there are experimental patches for larger devices. The file access API was limited to signed 32-bit byte values. Officially, this was fixed for the 2.4 series. Most distributions shipped 2.2 series kernels with patches to allow large files. The ext2, FAT, and NFSv2 filesystems all had a 32-bit file size limit. For ext2 this was lifted just as the 2.2 series came out, but only Alpha systems could use the large files. FAT has not been fixed. NFSv2 has been replaced by NFSv3. EXT2FS_VERSION has not been updated because feature flag bits are being used instead. I have a graph of ext2 limits: http://www.cs.uml.edu/~acahalan/linux/ext2.gif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Bob_Tracy wrote: > > Andrea Arcangeli quoted: > > On Thu, Jul 05, 2001 at 11:46:33AM -0400, Arjan van de Ven wrote: > > > On Thu, Jul 05, 2001 at 11:32:00PM +0800, Thibaut Laurent wrote: > > > > And the winner is... Andrea. Kudos to you, I've just applied these patches, > > > > recompiled and it seems to work fine. > > > > Too bad, this was the perfect excuse for getting rid of those good old Cyrix > > > > boxen ;) > > > > > > As Andrea's patches don't actually fix anything Cyrix related it's obvious > > > that they just avoid the real bug instead of fixing it. > > > It's a very useful datapoint though. > > Put me in the "it works for me" camp also. Do we have the definitive answer > as far as what is/was broken? Thanks, Andrea... The Cyrix setup code in arch/i386/kernel/setup.c is unconditionally enabling interrupts when it shouldn't. This allows timer interrupts to start running before the softirq system has been set up. A subsequent softirq_init() mucks up the softirq data structures and we hit the BUG(). The setup code needs to not reenable interrupts, and softirq_init() should be called prior to time_init(). Both these changes are in 2.4.7-pre3. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
max sizes for files and file systems
I've been trying to do some research on the file size and filesystem size limitations under Linux for stable releases since 2.0. It's clear that under 2.4, the kernel imposes a limit of 2TB as the maximum file size and that some portion of the kernels before 2.4 had a limit of 2GB. However, it's not clear to me when the file size limit was increased, or what the maximum file system sizes under 2.0, 2.2 and 2.4 are. I realize that both of these values are also contingent on the filesystem used, but I'm wondering about what limits the kernel itself imposes. I'm also a bit unclear as to where the 2GB limit in kernels < 2.4 comes from. It appears to be a kernel imposed limit, but there also seems to be a lot conflicting information out there, blaming the problem on EXT2. However, from what I can tell, 2.0.39, 2.2.19 and 2.4.5 all use the same version (0.5b-95/08/09) of ext2-- either that or EXT2FS_VERSION and EXT2FS_DATE in .../include/linux/ext2_fs.h simply haven't been updated. Any clarification would be appreciated. --- Derek Vadala, [EMAIL PROTECTED], http://www.cynicism.com/~derek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Random lockups with kernels 2.4.6-pre8+
Hi again, I have been able to reproduce the locking-up behaviour! It occurs every time I start Mozilla (0.9.2) or gtkEmbed. Other memory intensive programs (GIMP) don't have that behaviour. Strangely enough, the system remains mostly functional: I can switch consoles, X and Enlightenment remain responsive, I can even execute some programs. But programs that deal with mozillas /proc entries just hang. top and ps hang; also if I cd into /proc/ and do an ls *block*; you can't even kill it with CTRL-C. Listing other subdirs works fine though. Other things that hang are w and xdm-greeter. Considering these symptoms, it seems to be more of an issue with mozilla than with the kernel. Still, I don't know why the ls /proc/mozilla should block. Also things work perfectly with kernel 2.4.6-pre5. Can anybody reproduce the symptoms, tell me whether this is a problem with the kernel, mozilla or both, or provide me with other insight? I'd appreciate it very much! Bye Felix - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cleanup_module/delete_module.
Hi, I want to know the difference between the cleanup_module and delete_module system call. Can any one please clarify my doubt. Thanks, sendhil __ 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/
window field in TCP header.
Hello, I am running linux kernal 2.4.2 . My query is concerning the manner in which the TCP code handles the initial window size value ( RWIN ) in the TCP header. I observed that RWIN that the client announces is 5840 bytes in the packet irrespective of what value I set using the setsockopt . Is there any particular reason for this ? It seems to me as a too small a value. Secondly, any way to get around this ? I checked the /proc/sys/net/core/* where the defaults are set. rmem_default is set to 65535 . Similarly wmem_default. Further more, when I checked the complete packet trace using tcpdump for the FTP data connection ( for a large file transfer ) , it seems that though TCP starts with a RWIN of 5840 in the segement but keeps on increasing the RWIN as the connection progresses upto 47784 . Next, I modified FTP code to set the initial window field to 500 K bytes. The window field in the packet should have been 64 K and wscale = 3. But again the window field was 5840 bytes and wscale = 1. After some packets were transferred , the window field increased upto 47784 but not beyond that. Now the RFC 1323 says that the receiver will left-shift window field of every incoming segemet by wscale bits. Left shifting 47784 by 1 bit would in no way offer me th desired window ( 500 K bytes ). Is there some thing that I am doing wrong or is there something wrong in the TCP implementation ? Please CC any replies to my email id. Thanks, Manish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: __alloc_pages: 4-order allocation failed
On Thu, 5 Jul 2001, David Whysong wrote: > Jes Sorensen ([EMAIL PROTECTED]) wrote: > > >You ran out of memory, ie. there were no more free blocks of 16 > >consecutive pages available in the system. This is what happens on a > >system with little memory or which is loaded with memory intensive > >applications. > > I'm seeing the same thing here on a machine with 256 MB RAM and 1.5 > gigabytes of swap. There is no chance I am using anywhere near that > much virtual memory. > > Something is wrong with the MM in 2.4.6-pre9. David, The messages are "harmless". The SCSI layer is trying to allocate big chunks of memory (for the scattergather tables IIRC) just as an optimization. If its not possible to allocate big chunks, the SCSI code will use lower order allocations. (smaller chunks) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] gamecon.c: Fix for SNES controllers
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.cWed 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])
PGP signature
Re: [PATCH] more SAK stuff
Rob Landley writes: > Off the top of my head, fun things you can't do suid root: ... > ps (What the...? Worked in Red Hat 7, but not in suse 7.1. > Huh? "suid-to apache ps ax" works fine, though...) The ps command used to require setuid root. People would set the bit by habit. > I keep bumping into more of these all the time. Often it's fun > little warnings "you shouldn't have the suid bit on this > executable", which is frustrating 'cause I haven't GOT the suid bit > on that executable, it inherited it from its parent process, which > DOES explicitly set the $PATH and blank most of the environment > variables and other fun stuff...) Oh, cry me a river. You can set the RUID, EUID, SUID, and FUID in that same parent process or after you fork(). Since you didn't set all the UID values, I have to wonder what else you forgot to do. Maybe you shouldn't be messing with setuid programming. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problems playing audio cds with ide-scsi installed.
Hello to all. I have the following setup. tyan s1590s motherboard, 64mb ram, two ide ports on board, amdk63d processor. I am running debian linux using kernel 2.2.19. I have a Ricoh MP7120 cdrw drive. This is an atapi drive. Because of this I need to use the ide-scsi driver along with the sg driver. I have no trouble at all writing audio or data cds using cdrecord. The problem comes when I need to play an audio cd. If I have just put the cd in the drive, any audio cd player works fine. However after a stop command with either cdcd or cdtool, I must issue two cdcd play commands in a row, or two cdplay commands in the case of cdtool in order to get the cd to begin playing again. The cdrw drive is on the secondary port and it is a master. I have the following append command in lilo.conf append="hdc=ide-scsi" If I remove this command, and make /dev/cdrom point to /dev/hdc, the problem disappears altogether. I've looked in every log file I can find on the system and cannot find any error messages anywhere. The audio cd players just don't do anything at all on the first play command after a stop command. I've read the ide documentation, and there is very little said about ide-scsi. Does anyone have any idea as to what on earth is happening here? Thanks for any help. Sincerely, -- 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: __alloc_pages: 4-order allocation failed
Jes Sorensen ([EMAIL PROTECTED]) wrote: >You ran out of memory, ie. there were no more free blocks of 16 >consecutive pages available in the system. This is what happens on a >system with little memory or which is loaded with memory intensive >applications. I'm seeing the same thing here on a machine with 256 MB RAM and 1.5 gigabytes of swap. There is no chance I am using anywhere near that much virtual memory. Something is wrong with the MM in 2.4.6-pre9. Dave David Whysong [EMAIL PROTECTED] Astrophysics graduate student University of California, Santa Barbara My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6 D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Support for HFS Plus?
Hello, I don't know whether this is the right place to send this question, but do you have any software for Linux which allows me to mount HFS Plus file systems on a Linux 2.4.x kernel? I am particularly interested in mounting file systems which have been created under Mac OS 9.1 or Mac OS X. Thanks. -- Tony Kavadias, E-mail: [EMAIL PROTECTED] SGI Australia, Pty. Ltd. Phone: +61 3 9834 8200x234 357 Camberwell Road, Camberwell, VIC, 3124. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: LILO calling modprobe?
> > > Is there a reason that it does this? > > > > I believe there is. It wants to find what drive is bios drive 80h. > > Yes. > > > I had a machine at work with both ide and scsi. ide hdd was hdc and ide > > cdrom was hda just to keep lilo from thinking hdc is the first bios drive > > which infact sda was > > But why don't you use the bios keyword? From lilo.conf(5): I was only explaining. I foundout about the bios keyword after searching. But I didn't have time then to do the searching and didn't care. it worked for me. I don't boot scsi drives on any of my systems that also have ide. I prefer the systems to be either, but not both (test boxes excluded =) -- Lab tests show that use of micro$oft causes cancer in lab animals - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: LILO calling modprobe?
On Fri, Jul 06, 2001 at 01:08:55AM +0200, Guest section DW wrote: > (But you must distinguish people. One complains about the probing, > another about the numbering. The bios keyword tells lilo about > the numbering, and it works.) Well, shouldn't lilo avoid probing if you pass bios=? Currently it doesn't. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/macros.h(new) and linux/list.h(mod) ...
On 20010706 Davide Libenzi wrote:
>
>On 05-Jul-2001 David Woodhouse wrote:
>>
>> [EMAIL PROTECTED] said:
>>> This program prints garbage:
>>> #define min(x,y) ({ typeof((x)) _x = (x); typeof((y)) _y = (y);
>>> #(_x>_y)?_y:_x; })
>>> int main (void) {
>>> int _x = 3, _y = 4;
>>> printf("%i\n", min(_x, _y));
>>> return 0;
>>> }
>>
>> Life's a bitch.
>> cf. get_user(__ret_gu, __val_gu); (on i386)
>>
>> Time to invent a gcc extension which gives us unique names? :)
>
>Something like ::(x) to move up one level the name resolution for example.
>
Tell gcc people to support ? in C besides C++.
--
J.A. Magallon # Let the source be with you...
mailto:[EMAIL PROTECTED]
Mandrake Linux release 8.1 (Cooker) for i586
Linux werewolf 2.4.6-ac1 #2 SMP Thu Jul 5 01:15:49 CEST 2001 i686
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Hi Andrew! On Fri, 06 Jul 2001, Andrew Morton wrote: > > Okay, here's the output of gdb: > > > > (gdb) x/10i 0xc0118028 > > 0xc0118028 : mov0x4(%esp,1),%eax > > 0xc011802c : cmpl $0x0,0xc025c2e4 > > 0xc0118033 : jne0xc0118043 > > 0xc0118035 : mov0xc024af20(,%eax,4),%eax > > 0xc011803c : test %eax,%eax > > 0xc011803e : je 0xc0118042 > > 0xc0118040 : call *%eax > > 0xc0118042 : ret > > 0xc0118043 : lea(%eax,%eax,4),%eax > > 0xc0118046 : lea0xc025bf80(,%eax,4),%eax > > > > Well I guess it tells us it's not random uninitialised > crud. > > Just for interest: what happens if you swap around the lines > > time_init(); > softirq_init(); > > in init/main.c? > That works, kernel boots now without problems. Thanks, Manfred -- /"\| PGP-Key available at Public Key Servers \ / ASCII ribbon campaign | or "http://www.mahowi.de/pgp/mahowi.asc; X against HTML mail | RSA: 0xC05BC0F5 * DSS: 0x4613B5CA / \ and postings | AIM: mahowi42 * ICQ: 61597169 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: What are rules for acpi_ex_enter_interpreter?
Thanks for the report on the locking issue. A fix is checked in locally. > From: Petr Vandrovec [mailto:[EMAIL PROTECTED]] > Replying to myself, after following change in additon to acpi_ex_... > poweroff on my machine works. It should probably map type 0 > => 0, 3 => 1 > and 7 => 2, but it is hard to decide without VIA datasheet, so change > below is minimal change needed to get poweroff through ACPI > to work on my > ASUS A7V. How did you discover slp typ values of 2 worked, where 7 did not? Did you just try all possibilities (0-7)? Regards -- Andy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: LILO calling modprobe?
On Thu, Jul 05, 2001 at 04:03:32PM -0700, Aaron Lehmann wrote: > On Fri, Jul 06, 2001 at 01:01:07AM +0200, Guest section DW wrote: > > But why don't you use the bios keyword? From lilo.conf(5): > > It doesn't help. Of course it does. (But you must distinguish people. One complains about the probing, another about the numbering. The bios keyword tells lilo about the numbering, and it works.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Kernel Panics because of sync() and IO ressources, Supposed to be fixed in 2.4.5pre9 ?
Good Morning! NOTE: Please CC answers/replies to my personal email account, because i can't keep track of all the stuff on linux-kernel, as i just started a new job. Thank you very much! Ok i'll try to stick to the bug report form :) PROBLEM: Kernel Panics since i switched to T-DSL, using masquadering. Supposed to be fixed in 2.4.5pre9 ? Description: I switched to DSL about 2 weeks ago, i got 3 NICs in that box one for the private net, one for the biz net and one for the DSL modem, using pppoe (not rp-pppoe). All three are Intel EtherExpress Pro 100+, two brand new ones and an older one (different size, same driver), but it happened with a Tulip card instead of the old Intel (which serves the modem) as well. The Kernel kept crashing with Kernel Panics, usually with Process: swapper (PID = 0), but when dnetc is running, it preferrable gives dnetc as process. It seems to occur only with masquadering in use. I'm using Kernel 2.4.6 (it happened in 2.4.4, 2.4.5 and 2.4.5ac22 as well), because i thought those fixes in pre9 would od the trick: -pre9: - make sure "sync()" doesn't effectively lock up the machine by overloading all the IO resources - fix up some network memory allocations that don't wan tto wait on IO. it crashed only two times in a little more than 24 hours, which is really good.. I was happy for every hour uptime the days before :) I hope the other informations help you to find and fix the problem, i'll be happy to provide any other information needed. Keywords: Kernel Panics, sync(), IO ressources (i think ;) root@router:~# cat /proc/version Linux version 2.4.6 (root@router) (gcc version 2.95.2 19991024 (release)) #2 SMP Wed Jul 4 19:18:12 CEST 2001 Couldn't figure out how to do the oops tracing (it's late) and i can't provide a shell script/program which reproduces the crash unfortunately, it dies unexpectandly. Environment: Linux router 2.4.6 #2 SMP Wed Jul 4 19:18:12 CEST 2001 i686 unknown Gnu C egcs-2.91.66 Gnu make 3.79 binutils 2.9.1.0.25 util-linux 2.11d mount 2.11d modutils 2.4.6 e2fsprogs 1.22 reiserfsprogs 3.x.0j PPP2.4.1 isdn4k-utils 3.1pre1 Linux C Library2.1.3 ldd: version 1.9.9 Procps 2.0.6 Net-tools 1.55 Kbd0.99 Sh-utils 2.0 Modules Loaded pppoe pppox ipt_TOS ipt_state ipt_REJECT ipt_LOG ipt_limit ipt_MASQUERADE iptable_mangle iptable_nat ip_conntrack iptable_filter ip_tables hisax isdn root@router:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 6 model name : Celeron (Mendocino) stepping: 0 cpu MHz : 300.688 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips: 599.65 root@router:~# cat /proc/modules pppoe 8416 1 (autoclean) pppox 1664 1 (autoclean) [pppoe] ipt_TOS 1200 5 (autoclean) ipt_state896 5 (autoclean) ipt_REJECT 3232 7 (autoclean) ipt_LOG 3600 14 (autoclean) ipt_limit 1344 16 (autoclean) ipt_MASQUERADE 1680 2 (autoclean) iptable_mangle 2016 0 (autoclean) (unused) iptable_nat16464 0 (autoclean) [ipt_MASQUERADE] ip_conntrack 16496 2 (autoclean) [ipt_state ipt_MASQUERADE iptable_nat] iptable_filter 2048 0 (autoclean) (unused) ip_tables 11104 11 [ipt_TOS ipt_state ipt_REJECT ipt_LOG ipt_limit ipt_MASQUERADE iptable_mangle iptable_nat iptable_filter] hisax 137104 2 isdn 116592 3 [hisax] root@router:~# cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial(auto) 0340-0340 : HiSax hscx A fifo 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0740-075f : HiSax hscx A 0b40-0b40 : HiSax hscx B fifo 0cf8-0cff : PCI conf1 0f40-0f5f : HiSax hscx B 1340-1340 : HiSax isac fifo 1740-175f : HiSax isac 1b40-1b47 : avm cfg 4000-403f : Intel Corporation 82371AB PIIX4 ACPI 5000-501f : Intel Corporation 82371AB PIIX4 ACPI e000-e01f : Intel Corporation 82371AB PIIX4 USB e400-e43f : Intel Corporation 82557 [Ethernet Pro 100] e400-e43f : eepro100 e800-e81f : Intel Corporation 82557 [Ethernet Pro 100] (#2) e800-e81f : eepro100 ec00-ec3f : Intel Corporation 82557 [Ethernet Pro 100] (#3) ec00-ec3f : eepro100 f000-f00f : Intel Corporation 82371AB PIIX4 IDE root@router:~# cat /proc/iomem
[OT] Maintainers master list: new idea
Hi there, Sorry to bother you with this, but I have some new ideas to keep the MAINTAINERS-file up-to-date. Currently, data in the file aren't up-to-date. I had the following idea: What if we create a website, where maintainers can verify and update their records. Records could also be added, in case a new driver appears, or removed if the code was obsoleted. The nice thing about this is that we can send a mail to the maintainer when he hasn't updated his record for say, 6 months (as suggested in previous mails). This way, patches to the original file could be sent to Linus on a regular basis. MAINTAINERS would be UP TO DATE!! Please give me some suggestions, or mail me for more details. Regards, Marc Brekoo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: LILO calling modprobe?
On Fri, Jul 06, 2001 at 01:01:07AM +0200, Guest section DW wrote: > But why don't you use the bios keyword? From lilo.conf(5): It doesn't help. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: LILO calling modprobe?
On Thu, Jul 05, 2001 at 06:03:31PM -0400, Wakko Warner wrote: > > > Before doing anything LILO v21 collects the hda, hdb, sda, sdb info. > > > There is no problem, certainly no kernel problem. > > > > Sure it isn't a problem, but it's really annoying if it won't need to > > touch hda anyway. > > > > Is there a reason that it does this? > > I believe there is. It wants to find what drive is bios drive 80h. Yes. > I had a machine at work with both ide and scsi. ide hdd was hdc and ide > cdrom was hda just to keep lilo from thinking hdc is the first bios drive > which infact sda was But why don't you use the bios keyword? From lilo.conf(5): For example, disk=/dev/sda bios=0x80 disk=/dev/hda bios=0x81 would say that your SCSI disk is the first BIOS disk, and your (primary master) IDE disk is the second BIOS disk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Small compile error with MTD driver
Linus, I just downloaded the 2.4.6 kernel and got a compile error while building the mtd driver as a module. The following patch addresses the issue and I apologize if someone has already sent this in. -Jeff --- 2.4.6.clean/include/linux/mtd/cfi.h Thu Jul 5 15:03:47 2001 +++ 2.4.6/include/linux/mtd/cfi.h Thu Jul 5 15:30:43 2001 @@ -10,6 +10,7 @@ #include #include #include +#include #include #include -- Jeff Golds Sr. Software Engineer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Andrea Arcangeli quoted: > On Thu, Jul 05, 2001 at 11:46:33AM -0400, Arjan van de Ven wrote: > > On Thu, Jul 05, 2001 at 11:32:00PM +0800, Thibaut Laurent wrote: > > > And the winner is... Andrea. Kudos to you, I've just applied these patches, > > > recompiled and it seems to work fine. > > > Too bad, this was the perfect excuse for getting rid of those good old Cyrix > > > boxen ;) > > > > As Andrea's patches don't actually fix anything Cyrix related it's obvious > > that they just avoid the real bug instead of fixing it. > > It's a very useful datapoint though. Put me in the "it works for me" camp also. Do we have the definitive answer as far as what is/was broken? Thanks, Andrea... --Bob Tracy [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: LILO calling modprobe?
Wakko Warner writes: > I believe there is. It wants to find what drive is bios drive 80h. Really > annoying since there's no way (correct me if I'm wrong) to read bios from > linux. If there is, lilo should do that. But since it's an old copy, this > probably was fixed. > > I had a machine at work with both ide and scsi. ide hdd was hdc and ide > cdrom was hda just to keep lilo from thinking hdc is the first bios drive > which infact sda was The easy way to handle this is to md5 checksum the disks at boot. Read the first and last track of the first and last cylinder of every BIOS drive. Then match up the disks when partition tables get scanned. The hard way involves running the BIOS in virtual-8088 mode to trap IO accesses, then mapping to drivers by IO region later. Neither way is 100% reliable, but the current guess is worse. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: pcmcia lockup inserting or removing cards in 2.4.5-ac{13,22}
On Thu, 5 Jul 2001 03:06:11, Erik Mouw <[EMAIL PROTECTED]> wrote: > Hmm, Cardbus and USB problems... you probably have both Cardbus and > i82365 support in your kernel configuration. Once I have the BIOS set to "cardbus/16 bit" instead of "auto-detect" I don't have a problem with having both Cardbus and i82365 support compiled in. If the BIOS is set to auto then the PCI tables don't have an IRQ specified and yenta.c uses IRQ 0! -- Trevor Hemsley, Brighton, UK. [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: LILO calling modprobe?
> > cache_add("/dev/hda",0x300);
> > for (i = 1; i <= 8; i++) {
> > sprintf(tmp,"/dev/hda%d",i);
> > cache_add(tmp,0x300+i);
> >
> > Before doing anything LILO v21 collects the hda, hdb, sda, sdb info.
> > There is no problem, certainly no kernel problem.
>
> Sure it isn't a problem, but it's really annoying if it won't need to
> touch hda anyway.
>
> Is there a reason that it does this?
I believe there is. It wants to find what drive is bios drive 80h. Really
annoying since there's no way (correct me if I'm wrong) to read bios from
linux. If there is, lilo should do that. But since it's an old copy, this
probably was fixed.
I had a machine at work with both ide and scsi. ide hdd was hdc and ide
cdrom was hda just to keep lilo from thinking hdc is the first bios drive
which infact sda was
--
Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: __alloc_pages: 4-order allocation failed
> "Ho" == Ho Chak Hung <[EMAIL PROTECTED]> writes: Ho> Hi, I got the error __alloc_pages: 4-order allocation failed in a Ho> module that uses and frees a lot of pages. Basically, I am trying Ho> implement a page cache for the module. First, I keep allocating Ho> pages using page_cache_alloc() until it fails, then I free a whole Ho> bunch of pages using freepages((unsigned long)page_address(page)) Ho> Would anyone please give me some advice about how to solve this Ho> problem? Thanks a lot. You ran out of memory, ie. there were no more free blocks of 16 consecutive pages available in the system. This is what happens on a system with little memory or which is loaded with memory intensive applications. Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
increasing the TASK_SIZE
I was wondering how I can increase the process address space, TASK_SIZE (PAGE_OFFSET), in the current kernel. It looks like the 3 GB value is hardcoded in a couple of places and is thus not trivial to alter. Is there any good reason to limit this value at all, why not just have it be the same as the max addressable space (64 GB)? We have an ix86 SMP box with 4 GB of RAM and want to be able to allocate all of it to a single program (physics simulation). I would greatly appreciate any help on this. Thanks a great deal, Ernie PS. Please `CC' me the answer! /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Ernest N. Mamikonyan E-Mail: [EMAIL PROTECTED] Department of Physics, Phone: (215) 895-1544 Drexel UniversityFax: (215) 895-5934 Philadelphia, PA 19104 Web: www.physics.drexel.edu/research/astro /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Initio 9100 Driver for Linux
On Thu, 5 Jul 2001 11:32:12, [EMAIL PROTECTED] wrote:
> > I have a problem with the driver for Initio SCSI Controller 9100 SCSI,
> > a dual channel UW SCSI-Controller. On checking the SCSI bus the systems
> > has problems to initialize the CD-RW Sanyo (aka Brainwave) BP4-N SCSI
> > The CD-RW has SCSI-ID 6 on the second Controller. It is shown on
> > system startup an GENERIC CRD-BP4
> >
> > I had this problem both with Kernel 2.2.17 and 2.2.19.
>
> Check your termination. The initio drivers are very sensitive to
> termination errors (use active if possible), and make sure you follow all
> the normal rules regarding scsi.
>
> Most problems I've seen are caused by lousy termination, or using three
> way busses. I've also seen some problems with some cd writers (Yamaha to
> be exact), that I haven't been able to solve yet.
There's a bug in i91uscsi.c, init_tulip where it cycles through the onboard NVRAM
config. On the controller there's a single byte per device but it cycles through the
NVRAM in words. Since x86 words are two bytes a piece this means that the
code uses the NVRAM config for the device on twice the SCSI id - the only one
that's right is the one on id 0.
The patch below has been working here since January - though I've just extracted
this one fix from a much larger modification that I've done to the driver - proc fs
support, merging of i91uscsi.h and ini9100u.h since they contain many of the
same definitions but the two definitions are different which looks extremely
dangerous to me! i91uscsi.h is no more here.
I may have missed something with this one fix.
--- drivers/scsi/i91uscsi.cold Thu Jul 5 20:50:04 2001
+++ drivers/scsi/i91uscsi.c Thu Jul 5 20:55:03 2001
@@ -590,8 +590,8 @@
int init_tulip(HCS * pCurHcb, SCB * scbp, int tul_num_scb, BYTE * pbBiosAdr, int
seconds)
{
int i;
- BYTE *pwFlags;
BYTE *pbHeads;
+ UCHAR *pTarg;
SCB *pTmpScb, *pPrevScb = NULL;
pCurHcb->HCS_NumScbs = tul_num_scb;
@@ -673,12 +673,12 @@
TUL_WR(pCurHcb->HCS_Base + TUL_GCTRL1,
((pCurHcb->HCS_Config & HCC_AUTO_TERM) >> 4) |
(TUL_RD(pCurHcb->HCS_Base, TUL_GCTRL1) & 0xFE));
+ pTarg = >NVMSCSIInfo[0].MVM_Targ0Config;
for (i = 0,
-pwFlags = & (i91unvramp->NVM_SCSIInfo[0].NVM_Targ0Config),
pbHeads = pbBiosAdr + 0x180;
i < pCurHcb->HCS_MaxTar;
-i++, pwFlags++) {
- pCurHcb->HCS_Tcs[i].TCS_Flags = *pwFlags & ~(TCF_SYNC_DONE |
TCF_WDTR_DONE);
+i++) {
+ pCurHcb->HCS_Tcs[i].TCS_Flags = *(pTarg+i);
if (pCurHcb->HCS_Tcs[i].TCS_Flags & TCF_EN_255)
pCurHcb->HCS_Tcs[i].TCS_DrvFlags = TCF_DRV_255_63;
else
Trevor Hemsley, Brighton, UK.
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[OT] Re: LILO calling modprobe?
> cache_add("/dev/hda",0x300);
> for (i = 1; i <= 8; i++) {
> sprintf(tmp,"/dev/hda%d",i);
> cache_add(tmp,0x300+i);
>
> Before doing anything LILO v21 collects the hda, hdb, sda, sdb info.
> There is no problem, certainly no kernel problem.
Sure it isn't a problem, but it's really annoying if it won't need to
touch hda anyway.
Is there a reason that it does this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: LILO calling modprobe?
On Thu, Jul 05, 2001 at 02:58:18PM -0500, Stephen C Burns wrote: > modprobe: Can't locate module block-major-3 If you want to get rid of this, add: alias block-major-3 off in /etc/modules.conf -- 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: 2.4.7pre2aa1
On Thu, 5 Jul 2001, Andrea Arcangeli wrote: > ... It also fixes a vm deadlock ... I take it you've submitted this part of the patch set to Linus and Alan so we'll see it in the main kernel soon ? ;) 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: >128 MB RAM stability problems (again)
On 4 Jul 2001, Ronald Bultje wrote: > Hi, Hi back at you :-) > you might remember an e-mail from me (two weeks ago) with my problems > where linux would not boot up or be highly instable on a machine with > 256 MB RAM, while it was 100% stable with 128 MB RAM. Basically, I still > have this problem, so I am running with 128 MB RAM again. This can mean (but is not limited to) that the second memory module is bad, or can't keep up with the DRAM controller. An obvious test is to replace your existing memory module with the other memory module and see if you experience problems. If you experience no problems, then it's not the module. Most likely it's the DRAM controller (or a capacitence problem due to timing). Some BIOSs allow you to adjust the DRAM controller timings (RAS, CAS, clock). You may have to slow down the timings to stabalize the memory access. I have a DELL computer at work that is supposed to be able to take 128M (4 banks of 32M) in SIMMs, but no matter what brand of memory (I went through 4 different manufacturers), it always caused OS crashes. Yet, if I load it with 64M (4 banks of 16M) its completely stable. That computers BIOS doesn't allow me to change the DRAM timings, so I'm stuck with 64M. This is just to illustrate that it might not be the memory, but the controller thats the problem. > I've been running Mandrake 7.2 on another machine for some time - no > problem, until. I added another 64 MB RAM and tried to install > redhat (25 times (!!!)) and Mandrake 8.0... Both crash with memory > faults. Redhat just freezes or givesa a python warning, Mandrake > gives a segfault with a warning that "memory is missing" Both refuse > to complete installation... When you boot the installer (either from CD or floppy) you get the option to add kernel parameters before the installer kernel actually boots. Try adding the parameter "mem=128M" or "mem=64M". This will restrict the installer to using a subset of the total memory. In my experience, the installer environment of most distributions is not very robust, but once installed, the normal system is quite stable. > I'm kind of astounded now, WHY can't linux-2.4.x run on ANY machine in > my house with more than 128 MB RAM?!? Can someone please point out to me > that he's actually running kernel-2.4.x on a machine with more than 128 > MB RAM and that he's NOT having severe stability problems? > And can that same person PLEASE point out to me why 2.4.x is crashing on > me (or help me to find out...)? Really, we need more information than "can't linux-2.4.x run on ANY machine". What brand/make motherboard? > First machine is a Intel P-II 400 with 128 MB RAM (133 MHz SDRAM) and > crashing when I insert an additional 128 - it's running RH-7.0 with > kernel-2.4.4. Second machine is an AMD Duron 600 with 196 MB RAM (also > 133 MHz SDRAM), crashing during the installation of both Mandrake 8.0 > and Redhat 7.1 and which used to run stable with 128 MB RAM or 64 MB RAM > with Mandrake-7.2. Win2k runs stable on this machine in all > configurations. Each OS allocates the physical memory differently. MS-Windows typically allocates physical memory sequentually. Linux tends to uses both ends of the memory pool. For a proper test, you need to load enough programs so that all of physical memory will be utilized. Win2k may be "stable" because you aren't loading enough of the system to touch the second bank of memory. Please try running several large programs and exercise them all together for several minutes. You can use the task manager to find the total memory used on the system. > I'm getting desperate win2k is running stable and it's scary to see > linux crash while win2k runs stable and smooth. It's kinda funny, but I actually use MS-Windows NT as a memory/controller tester ;-). In my experience, I've found that Windows is much more demanding/picky of the hardware than Linux is (Linux installer experiences being the notable exception). > (ps I'm not subscribed to the list - please CC a copy to me when > replying) > > Thanks in advance for any help on this, > -- > Ronald Bultje -- Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> "Cats are just autistic Dogs" -- Dr. Tony Attwood - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: LILO calling modprobe?
On Thu, Jul 05, 2001 at 02:58:18PM -0500, Stephen C Burns wrote:
> Each time I run lilo, I receive the following message in syslog:
>
> modprobe: Can't locate module block-major-3
>
> This machine has no IDE devices. when I run lilo in verbose mode, I see
> that it is querying all possible hard disks in /dev (e.g. Caching device
> /dev/hda (0x0300, etc.). I am, in fact, running an older version of
> LILO (0.21) but upgrading when it is not necessary frightens me.
Well, why not look at the source, then?
void preload_dev_cache(void)
{
char tmp[10];
int i;
cache_add("/dev/hda",0x300);
for (i = 1; i <= 8; i++) {
sprintf(tmp,"/dev/hda%d",i);
cache_add(tmp,0x300+i);
}
cache_add("/dev/hdb",0x340);
for (i = 1; i <= 8; i++) {
sprintf(tmp,"/dev/hdb%d",i);
cache_add(tmp,0x340+i);
}
cache_add("/dev/sda",0x800);
for (i = 1; i <= 8; i++) {
sprintf(tmp,"/dev/sda%d",i);
cache_add(tmp,0x800+i);
}
cache_add("/dev/sdb",0x810);
for (i = 1; i <= 8; i++) {
sprintf(tmp,"/dev/sdb%d",i);
cache_add(tmp,0x810+i);
}
}
Before doing anything LILO v21 collects the hda, hdb, sda, sdb info.
There is no problem, certainly no kernel problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] more SAK stuff
On Monday 02 July 2001 15:10, Hua Zhong wrote: > -> From Alan Cox <[EMAIL PROTECTED]> : > > > (a) It does less, namely will not kill processes with uid 0. > > > Ted, any objections? > > > > That breaks the security guarantee. Suppose I use a setuid app to confuse > > you into doing something ? > > a setuid app only changes euid, doesn't it? Yup. And you'd be amazed how many fun little user mode things were either never tested with the suid bit or obstinately refuse to run for no good reason. (Okay, I made something like a sudo script. It's in a directory that non-root users can't access and I'm being as careful as I know how to be, but I've got a cgi that needs root access to query/set system and network configuration.) Off the top of my head, fun things you can't do suid root: The samba adduser command. (But I CAN edit the smb.passwd file directly, which got me around this.) su without password (understandable, implementation detail. It's always suid, being run by somebody other than root is how it knows when it NEEDS to ask for a password. But when I want to DROP root privelidges... Wound up making "suid-to" to do it.) ps (What the...? Worked in Red Hat 7, but not in suse 7.1. Huh? "suid-to apache ps ax" works fine, though...) dhcpcd (I patched it and yelled at the maintainer of this months ago, should be fixed now. But a clear case of checking uid when he meant euid, which is outright PERVASIVE...). I keep bumping into more of these all the time. Often it's fun little warnings "you shouldn't have the suid bit on this executable", which is frustrating 'cause I haven't GOT the suid bit on that executable, it inherited it from its parent process, which DOES explicitly set the $PATH and blank most of the environment variables and other fun stuff...) By the way, anybody who knows why samba goes postal if you change the hostname of the box while it's running, please explain it to me. It's happy once HUPed, then again it execs itself. (Not nmbd. smbd. Why does it CARE? And sshd has the most amazing timeouts if it can't do a reverse dns lookup on the incoming IP, even if I tell it not to log!) Apache has a similar problem, and HUP-ing it interrupts in-progress transfers, which could be very large files, 'cause it execs itself. I made that happy by telling it its host name was a dot notation IP address, although that does mean that logging into a password protected web page using the host name forces you to log in twice (again when it switches you to http://1.2.3.4/blah...) Fun, isn't it? :) Alan's right. We DO need a rant tag. Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [OT] Quad-cpu motherboard recommendation
> > can someone please recommend a motherboard that can carry four CPUs, > > either AMD or Intel (but other than Pentium III Xeon 700 > > Mhz) capable of> > running Linux? > > If you're going to go quad then you're usually better off > dealing with a big > company like Dell or IBM than going homebrew. Yes, they're > pricey, but they know what they're doing. Thanks for the vote of confidence. :-) Dell PowerEdge 6400 and 6450 servers can have up to 4 Intel Pentium III Xeon 700 or 900MHz CPUs. The 900MHz/2MB cache ones aren't available drop-down on the web page at the moment, but are if you call and ask. www.dell.com/linux, choose PowerEdge 6400, "Buy This System", then call the phone number 1-800-917-DELL listed there, and tell them what you want. Base code 649002 Processors 4P9002M Thanks, Matt -- Matt Domsch Sr. Software Engineer Dell Linux Solutions www.dell.com/linux #2 Linux Server provider with 17% in the US and 14% Worldwide (IDC)! #3 Unix provider with 18% in the US (Dataquest)! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: LILO calling modprobe?
On Thu, Jul 05, 2001 at 02:58:18PM -0500, Stephen C Burns wrote: > Hey all, > > Each time I run lilo, I receive the following message in syslog: > > modprobe: Can't locate module block-major-3 I have the same problem. http://bugs.debian.org/83710 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OOPS] insmod, 2.4.6-ac1
Booting up the system normally today, my first try with 2.4.6-ac1 yielded the following OOPS: ksymoops 2.4.0 on i686 2.4.6-ac1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.6-ac1/ (default) -m /boot/System.map-2.4.6-ac1 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Error (regular_file): read_system_map stat /boot/System.map-2.4.6-ac1 failed invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: c0298edc ebx: c40fc2b4 ecx: 0007 edx: c40fc2b4 esi: 0202 edi: c40fc2b4 ebp: c6ac5f2c esp: c6ac5ec4 ds: 0018 es: 0018 ss: 0018 Process insmod (pid: 576, stackpage=c6ac5000) Stack: c40fc2b4 0202 0007 c6ac5f2c c41a3220 c0124829 c40fc2b4 0007 c88c2000 c88c206f c88c268f 006c 0007 c88c2bc0 c02991f4 c88c2000 c88c206f c88c206f 0d90 c1044010 0207 Call Trace: [] [] [] Code: 0f 0b f6 c5 10 0f 85 ae 01 00 00 a1 28 fd 2e c0 f7 d8 89 ce >>EIP; c01245a7<= Trace; c0124829 Trace; c01130dd Trace; c0106a2b <__up_wakeup+fa7/22f4> Code; c01245a7 <_EIP>: Code; c01245a7<= 0: 0f 0b ud2a <= Code; c01245a9 2: f6 c5 10 test $0x10,%ch Code; c01245ac 5: 0f 85 ae 01 00 00 jne1b9 <_EIP+0x1b9> c0124760 Code; c01245b2 b: a1 28 fd 2e c0mov0xc02efd28,%eax Code; c01245b7 10: f7 d8 neg%eax Code; c01245b9 12: 89 ce mov%ecx,%esi 1 warning and 1 error issued. Results may not be reliable. DMESG: (from the working 2.4.5-ac13 version) Linux version 2.4.5-ac13 (xxx) (gcc version 2.95.3) #2 Tue Jun 19 09:11:23 EDT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000e6c00 - 0010 (reserved) BIOS-e820: 0010 - 040fd800 (usable) BIOS-e820: 040fd800 - 040ff800 (ACPI data) BIOS-e820: 040ff800 - 040ffc00 (ACPI NVS) BIOS-e820: 040ffc00 - 0800 (usable) BIOS-e820: fff8 - 0001 (reserved) On node 0 totalpages: 32768 zone(0): 4096 pages. zone(1): 28672 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=linux ro root=803 hdd=ide-scsi ide_setup: hdd=ide-scsi Initializing CPU#0 Detected 698.400 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1392.64 BogoMIPS Memory: 126328k/131072k available (1320k kernel code, 4344k reserved, 390k data, 196k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) Buffer-cache hash table entries: 8192 (order: 3, 32768 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0383f9ff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383f9ff CPU: After generic, caps: 0383f9ff CPU: Common caps: 0383f9ff CPU: Intel Pentium III (Coppermine) stepping 01 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfd993, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router PIIX [8086/7110] at 00:07.0 Limiting direct PCI/PCI transfers. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 NTFS version 1.1.15 parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP] parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) pty: 256 Unix98 ptys configured lp0: using parport0 (polling). Serial driver version 5.05b (2001-05-03) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A block: queued sectors max/low 83888kB/27962kB, 256 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for
LILO calling modprobe?
Hey all, Each time I run lilo, I receive the following message in syslog: modprobe: Can't locate module block-major-3 This machine has no IDE devices. when I run lilo in verbose mode, I see that it is querying all possible hard disks in /dev (e.g. Caching device /dev/hda (0x0300, etc.). I am, in fact, running an older version of LILO (0.21) but upgrading when it is not necessary frightens me. I also note that calling lilo on a newer machine with newer lilo (21.4) that it does not query all devices, although that particular machine is all IDE. I realize that I can alias this block module to off in /etc/modules.conf, but I wanted to be sure that this is a cosmetic problem before I brush it off. Anyone for input? Thank you! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Quad-cpu motherboard recommendation
On Thu, Jul 05, 2001 at 01:24:03PM -0600, [EMAIL PROTECTED] wrote: > Hello, > > can someone please recommend a motherboard that can carry four CPUs, > either AMD or Intel (but other than Pentium III Xeon 700 Mhz) capable > of running Linux? I only know of , but they use Xeon last time I checked. Why not get dual, and take a coffee break? -- William Park, Open Geometry Consulting, <[EMAIL PROTECTED]> 8 CPUs cluster, (Slackware) Linux, Python, LaTeX, Vim, Mutt, Sc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Quad-cpu motherboard recommendation
pIII's other than xeons aren't capable of running in > 2 cpu configurations... you chipset choices are also limited to 450nx, profusion, and serverset IIIHE joelja On Thu, 5 Jul 2001 [EMAIL PROTECTED] wrote: > Hello, > > can someone please recommend a motherboard that can carry four CPUs, > either AMD or Intel (but other than Pentium III Xeon 700 Mhz) capable of > running Linux? > > Best regards, > Ognen > -- -- Joel Jaeggli [EMAIL PROTECTED] Academic User Services [EMAIL PROTECTED] PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Quad-cpu motherboard recommendation
On Thu, 5 Jul 2001 [EMAIL PROTECTED] wrote: > Hello, > > can someone please recommend a motherboard that can carry four CPUs, > either AMD or Intel (but other than Pentium III Xeon 700 Mhz) capable of > running Linux? > > Best regards, > Ognen If you're going to go quad then you're usually better off dealing with a big company like Dell or IBM than going homebrew. Yes, they're pricey, but they know what they're doing. -- Ignacio Vazquez-Abrams <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Quad-cpu motherboard recommendation
On Thu, 5 Jul 2001 [EMAIL PROTECTED] wrote: > can someone please recommend a motherboard that can carry four CPUs, > either AMD or Intel (but other than Pentium III Xeon 700 Mhz) capable of > running Linux? So you want a quad-pentiumpro-200 do you? :D -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[OT] Quad-cpu motherboard recommendation
Hello, can someone please recommend a motherboard that can carry four CPUs, either AMD or Intel (but other than Pentium III Xeon 700 Mhz) capable of running Linux? Best regards, Ognen -- Ognen Duzlevski Plant Biotechnology Institute National Research Council of Canada Bioinformatics team - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
arch/i386/kernel/semaphore.c
Hi,
I patched semaphore.c to compile cleanly and without any warning when
using GCC 3.0.
Regards,
Erik
/*
* i386 semaphore implementation.
*
* (C) Copyright 1999 Linus Torvalds
*
* Portions Copyright 1999 Red Hat, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
* rw semaphores implemented November 1999 by Benjamin LaHaise <[EMAIL PROTECTED]>
*/
#include
#include
#include
/*
* Semaphores are implemented using a two-way counter:
* The "count" variable is decremented for each process
* that tries to acquire the semaphore, while the "sleeping"
* variable is a count of such acquires.
*
* Notably, the inline "up()" and "down()" functions can
* efficiently test if they need to do any extra work (up
* needs to do something only if count was negative before
* the increment operation.
*
* "sleeping" and the contention routine ordering is
* protected by the semaphore spinlock.
*
* Note that these functions are only called when there is
* contention on the lock, and as such all this is the
* "non-critical" part of the whole semaphore business. The
* critical part is the inline stuff in
* where we want to avoid any extra jumps and calls.
*/
/*
* Logic:
* - only on a boundary condition do we need to care. When we go
*from a negative count to a non-negative, we wake people up.
* - when we go from a non-negative count to a negative do we
*(a) synchronize with the "sleeper" count and (b) make sure
*that we're on the wakeup list before we synchronize so that
*we cannot lose wakeup events.
*/
void __up(struct semaphore *sem)
{
wake_up(>wait);
}
static spinlock_t semaphore_lock = SPIN_LOCK_UNLOCKED;
void __down(struct semaphore * sem)
{
struct task_struct *tsk = current;
DECLARE_WAITQUEUE(wait, tsk);
tsk->state = TASK_UNINTERRUPTIBLE;
add_wait_queue_exclusive(>wait, );
spin_lock_irq(_lock);
sem->sleepers++;
for (;;) {
int sleepers = sem->sleepers;
/*
* Add "everybody else" into it. They aren't
* playing, because we own the spinlock.
*/
if (!atomic_add_negative(sleepers - 1, >count)) {
sem->sleepers = 0;
break;
}
sem->sleepers = 1; /* us - see -1 above */
spin_unlock_irq(_lock);
schedule();
tsk->state = TASK_UNINTERRUPTIBLE;
spin_lock_irq(_lock);
}
spin_unlock_irq(_lock);
remove_wait_queue(>wait, );
tsk->state = TASK_RUNNING;
wake_up(>wait);
}
int __down_interruptible(struct semaphore * sem)
{
int retval = 0;
struct task_struct *tsk = current;
DECLARE_WAITQUEUE(wait, tsk);
tsk->state = TASK_INTERRUPTIBLE;
add_wait_queue_exclusive(>wait, );
spin_lock_irq(_lock);
sem->sleepers ++;
for (;;) {
int sleepers = sem->sleepers;
/*
* With signals pending, this turns into
* the trylock failure case - we won't be
* sleeping, and we* can't get the lock as
* it has contention. Just correct the count
* and exit.
*/
if (signal_pending(current)) {
retval = -EINTR;
sem->sleepers = 0;
atomic_add(sleepers, >count);
break;
}
/*
* Add "everybody else" into it. They aren't
* playing, because we own the spinlock. The
* "-1" is because we're still hoping to get
* the lock.
*/
if (!atomic_add_negative(sleepers - 1, >count)) {
sem->sleepers = 0;
break;
}
sem->sleepers = 1; /* us - see -1 above */
spin_unlock_irq(_lock);
schedule();
tsk->state = TASK_INTERRUPTIBLE;
spin_lock_irq(_lock);
}
spin_unlock_irq(_lock);
tsk->state = TASK_RUNNING;
remove_wait_queue(>wait, );
wake_up(>wait);
return retval;
}
/*
* Trylock failed - make sure we correct for
* having decremented the count.
*
* We could have done the trylock with a
* single "cmpxchg" without failure cases,
* but then it wouldn't work on a 386.
*/
int __down_trylock(struct semaphore * sem)
{
int sleepers;
unsigned long flags;
spin_lock_irqsave(_lock, flags);
sleepers = sem->sleepers + 1;
sem->sleepers = 0;
/*
* Add "everybody else" and us into it. They aren't
* playing, because we own the spinlock.
*/
if (!atomic_add_negative(sleepers, >count))
wake_up(>wait);
spin_unlock_irqrestore(_lock, flags);
return 1;
}
/*
* The semaphore operations have a special calling sequence that
* allow us to do a simpler in-line version of them. These routines
* need to convert that sequence back into the C sequence when
* there is contention on the semaphore.
*
* %ecx contains the semaphore pointer on entry. Save the C-clobbered
* registers (%eax, %edx and %ecx) except %eax when used as a return
* value..
*/
asm(
".text\n"
".align 4\n"
".globl __down_failed\n"
"__down_failed:\n\t"
Re: Is Swapping on software RAID1 possible in linux 2.4 ?
In linux-kernel, you wrote: > Peter Zaitsev wrote: > > > > That's why I thought this problem is related to raid1 swapping I'm > > using. > > Well there is the potential problem that RAID1 has that it can't avoid allocating > memory in some occasions, for the 2nd bufferhead. ATARAID raid0 has the same problem >for > now, and there is no real solution to this. You can pre-allocate a bunch of >bufferheads, > but under high load you will run out of those, no matter how many you pre-allocate. Arjan, why doesn't it sleep instead (GFP_KERNEL)? -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems halting/rebooting with 2.4.{5,6}-ac
Jordan Breeding wrote: > > I have a Tyan Tiger 230 SMP system running dual 1 GHz PIII processors. > The processors are of the same lot and revision, bought on the same > day. Everything worked fine or some time in regard to > halting/rebooting. I was using ac kernels configured with ACPI. At the > time of the merge with the Linus stuff which included new ACPI I started > configuring with ACPI and ACPI bus management and I could no longer halt > the system but rebooting worked OK. As of 2.4.5-ac24 and 2.4.6-ac1 I > can no longer halt or reboot my system properly using no power > management or ACPI, and APM still displays the message about being > broken on SMP. Has anyone seen this problem, is there a fix for it? > Another thing I have noticed is that my /proc/cpuinfo file looks like > this: > > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 8 > model name : Pentium III (Coppermine) > stepping: 6 > cpu MHz : 999.694 > cache size : 256 KB > fdiv_bug: no > hlt_bug : no > f00f_bug: no > coma_bug: no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 mmx fxsr sse > bogomips: 1992.29 > > processor : 1 > vendor_id : GenuineIntel > cpu family : 6 > model : 8 > model name : Pentium III (Coppermine) > stepping: 6 > cpu MHz : 999.694 > cache size : 256 KB > fdiv_bug: no > hlt_bug : no > f00f_bug: no > coma_bug: no > fpu : yes > fpu_exception : yes > cpuid level : 3 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 mmx fxsr sse > bogomips: 1998.84 > > Notice the difference in cpuid level and bogomips values between the > two. These processors should be exactly the same, same lot and revision > and everything else according to the shrink wrapped Intel retail boxes > they came out of. What could be casuing them to show up at different > cpuid levels? Thanks for any help with either issue. > > Jordan Breeding Very sorry to have not included more information, when halting or rebooting it now stop at INIT: there are no more processes left at this run level and never actually reboots or halts. To get around it I either have to hit the power/reset buton or use SysReq to reboot it. Thanks again for any help. Jordan Breeding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.[56] kernel + xfree 4.1.0
Justin Guyett wrote: > > After upgrading to xfree 4.1.0, after switching back to the console after > starting X, suspending, and resuming, the text-mode terminals are corrupt 2.4.x and XFree86 4.1.0 is first combination that doesn't mess up my text console and crash if there are graphics updates in X when console is in text mode. XF 3.3.6 was just deadlocking my machine (I used Accelerated-X before XFree86 4.x). I haven't tested the framebuffer in this machine. GDA is Voodoo3 2000 PCI (SDRAM). - Jussi Laako -- PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B 39DD A4DE 63EB C216 1E4B Available at PGP keyservers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.7pre2aa1
The main new thing is the blkdev in pagecache by default (not in the experimental dir anymore). Ramdisk and initrd should work fine now (initrd is untested though). It also fixes a vm deadlock and merges uml from -ac. Diff between 2.4.6pre5aa1 and 2.4.7pre2aa1: Only in 2.4.6pre5aa1: 00_irda-2.4.5ac13-1.bz2 Only in 2.4.6pre5aa1: 00_swapinfo-1 Only in 2.4.6pre5aa1: 00_numa-compile-1 Only in 2.4.6pre5aa1: 00_alpha-irq_err_count-1 Only in 2.4.6pre5aa1: 00_bootmem-header-1 Merged in in mainline. Only in 2.4.7pre2aa1/: 00_3c59x-zerocopy-1 Fix from Andi to allow zerocopy networking on HIGHMEM enabled kernel running on non highmem hardware. Only in 2.4.6pre5aa1: 00_double-buffer-pass-1 Only in 2.4.7pre2aa1/: 00_double-buffer-pass-2 Rediffed on top of the new sync logic. Only in 2.4.7pre2aa1/: 00_increase-logbuffer-1 Increase dmesg buffer for long bootup logs. Only in 2.4.6pre5aa1: 00_ksoftirqd-6_ia64-1 Only in 2.4.7pre2aa1/: 00_ksoftirqd-7_ia64-2 Fix from Andreas S. Only in 2.4.6pre5aa1: 00_nanosleep-4 Only in 2.4.7pre2aa1/: 00_nanosleep-5 Fixed a stupid merging bug. (spotted by Andi) Only in 2.4.6pre5aa1: 00_rwsem-13 Only in 2.4.7pre2aa1/: 00_rwsem-14 Rediffed to fix minor reject. Only in 2.4.7pre2aa1/: 00_swapfiles-1 Increase the max number of swapfiles (should be dynamic oh well). Only in 2.4.7pre2aa1/: 00_vm-deadlock-fix-1 Fix VM deadlock with GFP_NOFS. Only in 2.4.7pre2aa1/: 10_blkdev-pagecache-4 Move blkdev in pagecache. Ramdisk should be rock solid, even better than before, the rd_blocksize is meaningless these days so it won't break regardless of the blocksize used by the fs like it could happen before. Only last pending points are: 1) blkdev with a size not multiple of PAGE_CACHE_SIZE, need to check nothing fatal happens in that case with some simulation. 2) about performance, Chel van Gennip raised a point about granularity of the I/O to avoid read-modify-write (which is easily selectable at compile time like in 2.2, by default it is 4k for streming I/O performance reason, order of magnitude faster) The question is if we should change the granularity dynamically, and if we should also handle partial reads similarly to what we do with the partial writes. (this way a partial write followed by a partial read would generate no I/O besides the async flush of the dirty block) However this is a performance point, not really a functional/stability point. Only in 2.4.6pre5aa1/30_tux: 30_atomic-alloc-1 Only in 2.4.7pre2aa1/30_tux: 30_atomic-alloc-2 Rediffered to fix trivial reject. Only in 2.4.6pre5aa1: 40_experimental Gone away as blkdev in pagecache is included by default. Only in 2.4.7pre2aa1/: 50_uml-arch-2.4.5ac17.bz2 Only in 2.4.7pre2aa1/: 50_uml-common-1.bz2 Only in 2.4.7pre2aa1/: 51_uml-ac-to-aa-1.bz2 Merged in uml from -ac. 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: [PATCH] RE: 2.4.5-ac14 through to 2.4.6-ac1 fdomain.c initialisation for shared IRQ
> > A. Check bit 0 of the status port and return > > > > B. Check bit 4 or bit 9 of the interrupt control register > > > > Without docs someone would need to play with the various combinations and > > see what happened > > Uhmmm, an idea would be to look in fd_mcs.c as that driver already has > working support for irq-sharing. Doh. Ok that indeed shows you check bit 0 if the status port. Right I'll add shared IRQ support to that driver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.2.20pre7aa1
Only rediffed (maintenance mode, no known bugs, alpha rtc thing not merged yet). --- Difference between 2.2.20pre5aa1 and 2.2.20pre7aa1: Only in 2.2.20pre5aa1: 00_K7_P4-cachelines-4 Only in 2.2.20pre7aa1: 00_K7_P4-cachelines-5 Fixup trivial reject. --- 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: [PATCH] RE: 2.4.5-ac14 through to 2.4.6-ac1 fdomain.c initialisation for shared IRQ
On Thu, Jul 05, 2001 at 07:16:26PM +0100, Alan Cox wrote: > > I have recently had a problem with the fdomain driver initialisation and > > have found the problem to be the way in which it requests the irq. Here is > > my patch that has so far work ok. > > I've seen this patch before. It needs at least one change > > > -do_fdomain_16x0_intr, 0, "fdomain", NULL); > > + retcode = request_irq( shpnt->irq, > > +do_fdomain_16x0_intr, SA_SHIRQ, "fdomain", shpnt); > > Only set SA_SHIRQ if PCI - say - > > pdev?SA_SHIRQ:0 > > The other problem is that the code doesnt have support for handling IRQ > source checking, so if the line it shares with generates interrupts we might > sometimes do the right thing > > I have a long outstanding request with adaptec (who bought future domain) > for the info needed to fix this, but obviously its a dead product, from a > bought company and hardly on their priorities. > > I suspect the IRQ handler needs to either > > A.Check bit 0 of the status port and return > > B.Check bit 4 or bit 9 of the interrupt control register > > Without docs someone would need to play with the various combinations and > see what happened Uhmmm, an idea would be to look in fd_mcs.c as that driver already has working support for irq-sharing. /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RE: 2.4.5-ac14 through to 2.4.6-ac1 fdomain.c initialisation for shared IRQ
> I have recently had a problem with the fdomain driver initialisation and > have found the problem to be the way in which it requests the irq. Here is > my patch that has so far work ok. I've seen this patch before. It needs at least one change > - do_fdomain_16x0_intr, 0, "fdomain", NULL); > + retcode = request_irq( shpnt->irq, > + do_fdomain_16x0_intr, SA_SHIRQ, "fdomain", shpnt); Only set SA_SHIRQ if PCI - say - pdev?SA_SHIRQ:0 The other problem is that the code doesnt have support for handling IRQ source checking, so if the line it shares with generates interrupts we might sometimes do the right thing I have a long outstanding request with adaptec (who bought future domain) for the info needed to fix this, but obviously its a dead product, from a bought company and hardly on their priorities. I suspect the IRQ handler needs to either A. Check bit 0 of the status port and return B. Check bit 4 or bit 9 of the interrupt control register Without docs someone would need to play with the various combinations and see what happened - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problems halting/rebooting with 2.4.{5,6}-ac
I have a Tyan Tiger 230 SMP system running dual 1 GHz PIII processors. The processors are of the same lot and revision, bought on the same day. Everything worked fine or some time in regard to halting/rebooting. I was using ac kernels configured with ACPI. At the time of the merge with the Linus stuff which included new ACPI I started configuring with ACPI and ACPI bus management and I could no longer halt the system but rebooting worked OK. As of 2.4.5-ac24 and 2.4.6-ac1 I can no longer halt or reboot my system properly using no power management or ACPI, and APM still displays the message about being broken on SMP. Has anyone seen this problem, is there a fix for it? Another thing I have noticed is that my /proc/cpuinfo file looks like this: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 cpu MHz : 999.694 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1992.29 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 cpu MHz : 999.694 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 3 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1998.84 Notice the difference in cpuid level and bogomips values between the two. These processors should be exactly the same, same lot and revision and everything else according to the shrink wrapped Intel retail boxes they came out of. What could be casuing them to show up at different cpuid levels? Thanks for any help with either issue. Jordan Breeding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] RE: 2.4.5-ac14 through to 2.4.6-ac1 fdomain.c initialisation for shared IRQ
I have recently had a problem with the fdomain driver initialisation and
have found the problem to be the way in which it requests the irq. Here is
my patch that has so far work ok.
--- linux/drivers/scsi/fdomain.cThu Jul 5 13:35:41 2001
+++ fdomain.c Thu Jun 28 08:08:03 2001
@@ -981,8 +981,8 @@
} else {
/* Register the IRQ with the kernel */
- retcode = request_irq( interrupt_level,
-do_fdomain_16x0_intr, 0, "fdomain", NULL);
+ retcode = request_irq( shpnt->irq,
+do_fdomain_16x0_intr, SA_SHIRQ, "fdomain", shpnt);
if (retcode < 0) {
if (retcode == -EINVAL) {
Hope this is correct.
Regards
Grant Fribbens
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: floating point problem
On Thu, 5 Jul 2001 [EMAIL PROTECTED] wrote:
> In Linux PPC, the MSR[FP] bit (that is floating point available bit) is off
> (atleast for non-SMP).
>
Yes, so the first FP instruction per process lets "lazy FPU" save/restore
work.
> Due to this, whenever some floating point instruction is executed in 'user
> mode', it leads to a exception 'FPUnavailable'. The exception handler for
> this exception apart from setting the MSR[FP] bit, also sets the MSR[FE0]
> and MSR[FE1] bits. These bits basically enables the floating point
> exceptions so that if there are some floating point exception conditions
> encountered while exeuting a floating point instruction, an appropriate
> exception is raised.
> But whenever some floating point instruction is executed in 'kernel mode',
> 'FPUnavailabe' exception handler code does not set the 'MSR[FE0] and
> MSR[FE1]' bits.
>
The kernel is not supposed to use floating-point.
[SNIPPED...]
I think all you need is this:
/*
* Note FPU control only exists per process. Therefore, you have
* to set up the FPU before you use it in any program.
*/
#include
#define FPU_MASK (_FPU_MASK_IM |\
_FPU_MASK_DM |\
_FPU_MASK_ZM |\
_FPU_MASK_OM |\
_FPU_MASK_UM |\
_FPU_MASK_PM)
void fpu()
{
__setfpucw(_FPU_DEFAULT & ~FPU_MASK);
}
main() {
double zero=0.0;
double one=1.0;
fpu();
one /=zero;
}
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
I was going to compile a list of innovations that could be
attributed to Microsoft. Once I realized that Ctrl-Alt-Del
was handled in the BIOS, I found that there aren't any.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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
On Thu, 05 Jul 2001, Wayne Whitney wrote: > In mailing-lists.linux-kernel, you wrote: > > > We've noticed the following kernel error since 2.4 (2.4.1-2.4.6). > > It appears to be swap (kswapd thread specific?) related. The same > > error is reported on several SMP machines after only a short period > > (an hour or less). > > FYI, I see a similar problem under 2.4.5, also SMP, although only > intermittently. Two oopses are below, from two different, although > similarly configured, machines. [snip] Sounds very similar. Our servers are all identical (except for RAM). What's unusual is that the machines we *expect* to fail sooner - don't (not even an oops). Those are very busy cache servers (several of them in a sibling cluster) which do a lot of swapping. The machines which *do* fail (or oops without any further catastrophe) are typically web/mail hosting servers (reasonably busy with about 25% swap being used). Increasing swap did not help on 2.4.5. We're still waiting for something to happen on 2.4.6 (ie, oops already appeared - waiting for meltdown, which, hopefully, will not occur). We used to auto-reboot every morning at 2am or something to keep things stable - which I *hate* because I remember having a 2.0.35/6 workstation that had an uptime of 6 months a couple of years ago. God, I loved that box. cheers Henry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: >128 MB RAM stability problems (again)
Hmm, I have no problems either. Asus KT7 KT133 Chipset root@station2-lnx:~# uname -a Linux station2-lnx 2.4.6 #10 Thu Jul 5 11:08:39 CDT 2001 i686 unknown root@station2-lnx:~# free total used free sharedbuffers cached Mem:512944 509888 3056 0 32140 417532 -/+ buffers/cache: 60216 452728 Swap: 1100444 01100444 > > > Can someone please > > point out to me > > that he's actually running kernel-2.4.x on a machine with > > more than 128 > > MB RAM and that he's NOT having severe stability problems? > > And can that same person PLEASE point out to me why 2.4.x is > > crashing on > > me (or help me to find out...)? > > %uname -a > Linux cartman 2.4.0-64GB-SMP #1 SMP Wed Jan 24 15:52:30 GMT 2001 i686 > unknown > %uptime > 8:35am up 57 days, 12:42, 2 users, load average: 2.00, 2.00, 2.00 > %free > total used free shared buffers cached > Mem:254904251968 2936 092224 45028 > -/+ buffers/cache:114716140188 > Swap: 524656 14192510464 > > Could this be a 2.4 swap issue. You NEED at least RAM x2 swap. If you're > just adding memory to > a box that's stable with 128 megs and possibly 256 megs swap (you don't > state, just guessing..) > you've now got too little swap, and boom, stability goes bye-bye. > > Just haven't seen the swap issue mentioned this thread... > > =Don= > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Gary White Network Administrator [EMAIL PROTECTED] Internet Pathway Voice 601-776-3355Fax 601-776-2314 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
floating point problem
In Linux PPC, the MSR[FP] bit (that is floating point available bit) is off (atleast for non-SMP). Due to this, whenever some floating point instruction is executed in 'user mode', it leads to a exception 'FPUnavailable'. The exception handler for this exception apart from setting the MSR[FP] bit, also sets the MSR[FE0] and MSR[FE1] bits. These bits basically enables the floating point exceptions so that if there are some floating point exception conditions encountered while exeuting a floating point instruction, an appropriate exception is raised. But whenever some floating point instruction is executed in 'kernel mode', 'FPUnavailabe' exception handler code does not set the 'MSR[FE0] and MSR[FE1]' bits. The result is that when we execute a piece of code that executes floating point instructions with some large values, we get 'floating point exceptions for overflow etc' but we get some rounded off values when we execute the same piece of code in a kernel module. We made a modification in the head.S file and commented out the setting of 'MSR[FE0] and MSR[FE1]' bits in the 'FPUnavailable' exception handler for user mode. Due to this we are getting correct results i.e. rounded off values. Problem is that we want to get the good results without changing the kernel. Either by having the user mode application to interact with some special module which can set the MSR[FP] bit before we execute the floating point instruction or by some other trick.Is there any solution apart from changing the kernel? thanks, Daljeet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: GFP_NOFS broken
On Thu, 5 Jul 2001, Andrea Arcangeli wrote: > > getblk called from the fs calls grow_buffers with GFP_NOFS which doesn't > inhibit shrink_dcache_memory to re-enter the fs in prune_dcache because > __GFP_IO is set. And it will deadlock as usual when shrink_dcache reenter > the fs that way. Good catch. I renamed GFP_BUFFER on purpose to make sure that nobody relied on the old semantics, but I didn't think of the low-level __GFP_IO one which also changed semantics. A quick "grep" indicates that you seem to have found the only two that were left. Thanks. > Secondly this cleanups a bit in page_launder. If we are allowed to enter > the FS we can certainly also do I/O. Yup. 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: DMA memory limitation?
On Thu, 5 Jul 2001, Christophe Beaumont wrote: > > > > On Thu, 5 Jul 2001, Vasu Varma P V wrote: > > > > > Hi, > > > > > > Is there any limitation on DMA memory we can allocate using > > > kmalloc(size, GFP_DMA)? I am not able to acquire more than > > > 14MB of the mem using this on my PCI SMP box with 256MB ram. > > > I think there is restriction on ISA boards of 16MB. > > > Can we increase it ? > > > > > > thx, > > > Vasu > > > > 14MB of DMA(able) memory? Err. I think you are trying to > > do something you would never need to do. > > > And what is that supposed to be > Did you READ the rest of the carefully-worded paragraphs, carefully, explaining that it ** ISN'T DMA ** memory that you need? > I have a piece of pretty well designed hardware here... and my > application requires me to have the PCI board to random access > in master mode a whole lot of memory (anywhere from 128MEGS to ^^^ You JUST give it the address of any RAM you want to read/write... as explained before. As explained, in a documentation file I specified, you convert the virtual address using a macro that the kernel headers provide. You can even give it user-mode buffers as long as they are non-paged during the access. > 1GIG... and possibly more...) so I really do need BIG DMA buffers > (I don't say huge anymore as one can get 1/2 Gig of RAM for just > over 120 bucks???)... > > There is no way I can have the piece of hardware behave in > another fashion... and NO it is NOT broken (when you do BOTH > hardware & software, you know about BOTH limitations... there > are just some cases where you have to face some unique issues). > the mem=1024M works pretty fine once you have figured out how > to handle in a fairly simple way this "reserved" memory... > This is wrong! Good luck sucker. > So please software people... ^^^ I am a Software Engineer, with a long history of hardware design. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). I was going to compile a list of innovations that could be attributed to Microsoft. Once I realized that Ctrl-Alt-Del was handled in the BIOS, I found that there aren't any. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: DMA memory limitation?
> On Thu, 5 Jul 2001, Vasu Varma P V wrote: > > > Hi, > > > > Is there any limitation on DMA memory we can allocate using > > kmalloc(size, GFP_DMA)? I am not able to acquire more than > > 14MB of the mem using this on my PCI SMP box with 256MB ram. > > I think there is restriction on ISA boards of 16MB. > > Can we increase it ? > > > > thx, > > Vasu > > 14MB of DMA(able) memory? Err. I think you are trying to > do something you would never need to do. > And what is that supposed to be I have a piece of pretty well designed hardware here... and my application requires me to have the PCI board to random access in master mode a whole lot of memory (anywhere from 128MEGS to 1GIG... and possibly more...) so I really do need BIG DMA buffers (I don't say huge anymore as one can get 1/2 Gig of RAM for just over 120 bucks???)... There is no way I can have the piece of hardware behave in another fashion... and NO it is NOT broken (when you do BOTH hardware & software, you know about BOTH limitations... there are just some cases where you have to face some unique issues). the mem=1024M works pretty fine once you have figured out how to handle in a fairly simple way this "reserved" memory... So please software people... do not blame it all on the hardware... =) Chris. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
GFP_NOFS broken
While I was travelling disconnected from the internet the last week (I
will buy a GPRS phone soon ;) I also spotted and fixed the __GFP_BUFFER
deadlock that I was triggering on my 128m laptop while browsing large
email folders on top of crypto loop:
--- 2.4.6pre6aa1/include/linux/mm.h.~1~ Sat Jun 30 00:49:54 2001
+++ 2.4.6pre6aa1/include/linux/mm.h Sat Jun 30 02:20:57 2001
@@ -538,9 +538,8 @@
#define __GFP_WAIT 0x10
#define __GFP_HIGH 0x20
#define __GFP_IO 0x40
-#define __GFP_BUFFER 0x80
-#define GFP_BUFFER (__GFP_HIGH | __GFP_WAIT | __GFP_BUFFER)
+#define GFP_BUFFER (__GFP_HIGH | __GFP_WAIT)
#define GFP_ATOMIC (__GFP_HIGH)
#define GFP_USER ( __GFP_WAIT | __GFP_IO)
#define GFP_HIGHUSER ( __GFP_WAIT | __GFP_IO | __GFP_HIGHMEM)
--- 2.4.6pre6aa1/include/linux/slab.h.~1~ Sat Jun 30 00:49:56 2001
+++ 2.4.6pre6aa1/include/linux/slab.h Sat Jun 30 02:21:09 2001
@@ -22,7 +22,7 @@
#defineSLAB_NFSGFP_NFS
#defineSLAB_DMAGFP_DMA
-#define SLAB_LEVEL_MASK(__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_BUFFER)
+#define SLAB_LEVEL_MASK(__GFP_WAIT|__GFP_HIGH|__GFP_IO)
#defineSLAB_NO_GROW0x1000UL/* don't grow a cache */
/* flags to pass to kmem_cache_create().
--- 2.4.6pre6aa1/mm/vmscan.c.~1~Sat Jun 30 00:44:36 2001
+++ 2.4.6pre6aa1/mm/vmscan.cSat Jun 30 02:21:25 2001
@@ -425,7 +425,6 @@
*/
#define MAX_LAUNDER(4 * (1 << page_cluster))
#define CAN_DO_IO (gfp_mask & __GFP_IO)
-#define CAN_DO_BUFFERS (gfp_mask & __GFP_BUFFER)
int page_launder(int gfp_mask, int sync)
{
int launder_loop, maxscan, cleaned_pages, maxlaunder;
@@ -613,7 +612,7 @@
* loads, flush out the dirty pages before we have to wait on
* IO.
*/
- if ((CAN_DO_IO || CAN_DO_BUFFERS) && !launder_loop && free_shortage()) {
+ if (CAN_DO_IO && !launder_loop && free_shortage()) {
launder_loop = 1;
/* If we cleaned pages, never do synchronous IO. */
if (cleaned_pages)
However the more finegrined fix that I found in 2.4.7pre2 and 2.4.6
seems broken unlike my above one.
getblk called from the fs calls grow_buffers with GFP_NOFS which doesn't
inhibit shrink_dcache_memory to re-enter the fs in prune_dcache because
__GFP_IO is set. And it will deadlock as usual when shrink_dcache reenter
the fs that way.
This should cure the deadlock (against 2.4.7pre2) but beware it's
untested.
--- 2.4.7pre2aa1/fs/dcache.c.~1~Thu Jul 5 17:13:50 2001
+++ 2.4.7pre2aa1/fs/dcache.cThu Jul 5 18:52:03 2001
@@ -566,7 +566,7 @@
* We should make sure we don't hold the superblock lock over
* block allocations, but for now:
*/
- if (!(gfp_mask & __GFP_IO))
+ if (!(gfp_mask & __GFP_FS))
return;
if (priority)
--- 2.4.7pre2aa1/fs/inode.c.~1~ Thu Jul 5 17:13:48 2001
+++ 2.4.7pre2aa1/fs/inode.c Thu Jul 5 18:52:08 2001
@@ -696,7 +696,7 @@
* want to recurse into the FS that called us
* in clear_inode() and friends..
*/
- if (!(gfp_mask & __GFP_IO))
+ if (!(gfp_mask & __GFP_FS))
return;
if (priority)
Secondly this cleanups a bit in page_launder. If we are allowed to enter
the FS we can certainly also do I/O.
--- 2.4.7pre2aa1/mm/vmscan.c.~1~Thu Jul 5 17:13:48 2001
+++ 2.4.7pre2aa1/mm/vmscan.cThu Jul 5 18:59:33 2001
@@ -612,7 +612,7 @@
* loads, flush out the dirty pages before we have to wait on
* IO.
*/
- if ((CAN_DO_IO || CAN_DO_FS) && !launder_loop && free_shortage()) {
+ if (CAN_DO_IO && !launder_loop && free_shortage()) {
launder_loop = 1;
/* If we cleaned pages, never do synchronous IO. */
if (cleaned_pages)
I will include them in my next tree as it is at least certainly better
than the previous code.
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: Why Plan 9 C compilers don't have asm("")
On Wed, Jul 04, 2001 at 09:54:05PM -0400, Rick Hohensee wrote:
> >
> > On Tue, Jul 03, 2001 at 11:37:28PM -0400, Rick Hohensee wrote:
> > > That's with the GNU tools, without asm(), and without proper declaration
> > > of printf, as is my tendency. I don't actually return an int either, do I?
> > > LAAETTR.
> >
> > Under ISO C rules, this is illegal, since you must have a proper prototype in
> > scope when calling variable argument functions. In fact, I have worked on
> > several GCC ports, where the compiler uses a different calling sequence for
> > variable argument functions than it does for normal functions. For example, on
> > the Mips, if the first argument is floating point and the number of arguments
> > is not variable, it is passed in a FP register, instead of an integer
> > register. For variable argument functions, everything is passed in the integer
> > registers.
> >
>
> I didn't know that, but...
>
> You seem to be saying the use of assumptions about args passing is
> non-standard. I know. It's more standard than GNU extensions to C though,
> C_labels_in_asms in particular, and even in your examples it appears that
> the particular function abusing these tenets will know what it can expect
> from a particular compiler, since it knows what it's arguments are. It
> can't know what it can expect from any compiler. This perhaps is where
> #ifdef comes in, or similar. Well, it's not more standard than GNU, but
> the differences would be less detailed in the case of just dealing with
> various args passing schemes, and there may be some compiler-to-compiler
> overlap, where there won't be any with stuff like C_labels_in_asms.
Doing this is a losing game. How many different platforms does Linux currently
run on? Do you know exactly what the ABI is for each of the machines? What
happens when Linux is ported to a new machine? My point is:
extern int printf (const char *, ...);
printf ("%d %d\n", 1, 2);
and
extern int my_printf (const char *, int, int);
my_printf ("%d %d\n", 1, 2);
under some ABIs will pass arguments completely differently and as I said, I
have worked on various GCC ports that did this, so it is not a theoretical
possibility.
> It's illegal to not declare main() as int. I don't know of a unix that
> actually passes anything but a byte to the calling process. I got flamed
> mightily for this in comp.unix.programmer until people ran some checks on
> thier big Real Unix(TM) boxes of various types. Linux won't pass void
> either, you have to get a 0 at least. Compliance is subjective. It's
> easier when things make sense.
Yes, that is an artifact of the original UNIX implementation on the PDP-11 (16
bit ints, signal number is passed back in one byte, and the return value in
another byte).
--
Michael Meissner, Red Hat, Inc. (GCC group)
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work: [EMAIL PROTECTED] phone: +1 978-486-9304
Non-work: [EMAIL PROTECTED] fax: +1 978-692-4482
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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
In mailing-lists.linux-kernel, you wrote: > We've noticed the following kernel error since 2.4 (2.4.1-2.4.6). > It appears to be swap (kswapd thread specific?) related. The same > error is reported on several SMP machines after only a short period > (an hour or less). FYI, I see a similar problem under 2.4.5, also SMP, although only intermittently. Two oopses are below, from two different, although similarly configured, machines. A bit of warning: these kernels were patched with MOSIX-1.04 (www.mosix.org), but I don't believe that it touches the relevant parts of the kernel. Moreover, the MOSIX developers suggested these oopses were not MOSIX-related, and they are usually pretty good about that. Cheers, Wayne ksymoops 2.3.4 on i686 2.4.5-mosix-1.0.4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-mosix-1.0.4/ (default) -m /boot/System.map (specified) Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Jun 15 01:18:17 mf3 kernel: invalid operand: Jun 15 01:18:17 mf3 kernel: CPU:0 Jun 15 01:18:17 mf3 kernel: EIP:0010:[clear_inode+51/260] Jun 15 01:18:17 mf3 kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Jun 15 01:18:17 mf3 kernel: EFLAGS: 00010292 Jun 15 01:18:17 mf3 kernel: eax: 001b ebx: c42cdd60 ecx: 0001 edx: 0001 Jun 15 01:18:17 mf3 kernel: esi: e0937860 edi: c42cdd60 ebp: 1e7c esp: dff67f68 Jun 15 01:18:17 mf3 kernel: ds: 0018 es: 0018 ss: 0018 Jun 15 01:18:17 mf3 kernel: Process kswapd (pid: 4, stackpage=dff67000) Jun 15 01:18:17 mf3 kernel: Stack: c023fea4 c023ff03 01eb c42cdd60 c015c842 c42cdd60 c42f2940 c42f2920 Jun 15 01:18:17 mf3 kernel:e0929ffd c42cdd60 c42f2940 c015a040 c42f2920 c42cdd60 0482 0004 Jun 15 01:18:17 mf3 kernel: 0008e000 c015a399 2bc0 c013b2b7 0006 0004 0004 Jun 15 01:18:17 mf3 kernel: Call Trace: [iput+342/360] [ide-scsi:__insmod_ide-scsi_S.bss_L96+377149/32977459] [prune_dcache+220/368] [shrink_dcache_memory+33/48] [do_try_to_free_pages+39/88] [kswapd+87/228] [prepare_namespace+0/8] Jun 15 01:18:17 mf3 kernel: Call Trace: [] [] [] [] [] [] [] Jun 15 01:18:17 mf3 kernel:[] Jun 15 01:18:17 mf3 kernel: Code: 0f 0b 83 c4 0c 8d 74 26 00 8b 83 f4 00 00 00 a8 10 75 26 68 >>EIP; c015bca7<= Trace; c015c842 Trace; e0929ffd <[nfs]nfs_dentry_iput+75/7c> Trace; c015a040 Trace; c015a399 Trace; c013b2b7 Trace; c013b33f Trace; c0105000 Trace; c010550b Code; c015bca7 <_EIP>: Code; c015bca7<= 0: 0f 0b ud2a <= Code; c015bca9 2: 83 c4 0c add$0xc,%esp Code; c015bcac 5: 8d 74 26 00 lea0x0(%esi,1),%esi Code; c015bcb0 9: 8b 83 f4 00 00 00 mov0xf4(%ebx),%eax Code; c015bcb6 f: a8 10 test $0x10,%al Code; c015bcb8 11: 75 26 jne39 <_EIP+0x39> c015bce0 Code; c015bcba 13: 68 00 00 00 00push $0x0 1 warning issued. Results may not be reliable. ksymoops 2.3.4 on i686 2.4.5-mosix-1.0.4b. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-mosix-1.0.4b/ (default) -m /boot/System.map (specified) Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Jun 27 09:22:58 mf2 kernel: Unable to handle kernel NULL pointer dereference at virtual address 0814 Jun 27 09:22:58 mf2 kernel: c015a045 Jun 27 09:22:58 mf2 kernel: *pde = Jun 27 09:22:58 mf2 kernel: Oops: Jun 27 09:22:58 mf2 kernel: CPU:0 Jun 27 09:22:58 mf2 kernel: EIP:0010:[prune_dcache+209/368] Jun 27 09:22:58 mf2 kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Jun 27 09:22:58 mf2 kernel: EFLAGS: 00010206 Jun 27 09:22:58 mf2 kernel: eax: 0800 ebx: e959a8e0 ecx: e9596df0 edx: e9596df0 Jun 27 09:22:58 mf2 kernel: esi: e959a8c0 edi: e9596de0 ebp: 101b esp: c2225fa0 Jun 27 09:22:58 mf2 kernel: ds: 0018 es: 0018 ss: 0018 Jun 27 09:22:58 mf2 kernel: Process kswapd (pid: 4, stackpage=c2225000) Jun 27 09:22:58 mf2 kernel: Stack: 00c8 0004 0008e000 c015a3a9 2926 c013b2b7 0006 Jun 27 09:22:58 mf2 kernel:0004 0004 c2224000 c023bb31 c2224331 c013b33f 0004 Jun 27 09:22:58 mf2 kernel: 00010f00 c2213fb4 c0105000 c010550b c02bb080 c2212000 Jun 27 09:22:58 mf2 kernel: Call Trace: [shrink_dcache_memory+33/48] [do_try_to_free_pages+39/88] [kswapd+87/228] [prepare_namespace+0/8] [kernel_thread+35/48] Jun 27 09:22:58 mf2 kernel: Call Trace: [] [] [] [] [] Jun 27 09:22:58 mf2 kernel: Code: 8b 40 14 85 c0 74 09 57 56 ff d0 83 c4 08 eb 12 57 e8 a1
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
On Thu, Jul 05, 2001 at 11:46:33AM -0400, Arjan van de Ven wrote: > On Thu, Jul 05, 2001 at 11:32:00PM +0800, Thibaut Laurent wrote: > > And the winner is... Andrea. Kudos to you, I've just applied these patches, > > recompiled and it seems to work fine. > > Too bad, this was the perfect excuse for getting rid of those good old Cyrix > > boxen ;) > > As Andrea's patches don't actually fix anything Cyrix related it's obvious > that they just avoid the real bug instead of fixing it. > It's a very useful datapoint though. I repeat an hardware issue cannot cause that BUG(), I assume you are worried about the software device driver. The softirq stuff in mainline is pretty broken, to make an example think if atomic_read(>count) is > 0 and another cpu enables the tasklet before the tasklet_unlock but after the test_bit(TASKLET_STATE_SCHED), the following test_bit(TASKLET_STATE_SCHED) will trigger but tasklet_hi_schedule won't do anything because TASKLET_STATE_SCHED is just set and you will break badly if you don't use my patches. The new code breaks the invariant that when irq are locally enabled and the TASKLET_STATE_SCHED is set the tasklet is guaranteed to be just queued and that can have side effects, possibly the BUG() you are seeing, I didn't checked the new code too closely because I simply don't agree with the "infinite loop into atomic context" design, ksoftirqd solves the latency bugs just fine without losing robusteness that way. But of course if the driver has all the power to be able to be the buggy piece of code, in that case I will be more than willing to add some BUG() to my variant of the softirq handling to trigger it too. But at the moment it is not obvious to me this is not a bug in the softirq code. 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/
PPP/MPPE Problem
I have successfully (finally) installed MPPE and PPP with PPP 2.40 and Linux Kernel 2.4.2. However, anytime I allow and use MPPE-40 packets will not forward into a VPN. If I comment it out and use MPPE-STATELESS or MPPE-128 it works fine. As soon as MPPE-40 is uncommented, it fails to operate. What can I do to fix this? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Alan Cox wrote:
>
> > My money is on the unconditional sti()'s in the cyrix code.
>
> Possibly but the diff is wrong
But it'll still work :)
--- linux-2.4.6/init/main.c Wed Jul 4 18:21:32 2001
+++ lk-ext3/init/main.c Fri Jul 6 02:06:12 2001
@@ -523,8 +523,8 @@ asmlinkage void __init start_kernel(void
trap_init();
init_IRQ();
sched_init();
- time_init();
softirq_init();
+ time_init();
/*
* HACK ALERT! This is early. We're enabling the console before
--- linux-2.4.6/arch/i386/kernel/setup.cMon May 28 13:31:46 2001
+++ lk-ext3/arch/i386/kernel/setup.cFri Jul 6 01:59:37 2001
@@ -1243,11 +1255,13 @@ static int __init init_amd(struct cpuinf
/*
* Read Cyrix DEVID registers (DIR) to get more detailed info. about the CPU
*/
-static inline void do_cyrix_devid(unsigned char *dir0, unsigned char *dir1)
+static void do_cyrix_devid(unsigned char *dir0, unsigned char *dir1)
{
unsigned char ccr2, ccr3;
+ unsigned long flags;
/* we test for DEVID by checking whether CCR3 is writable */
+ save_flags(flags);
cli();
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, ccr3 ^ 0x80);
@@ -1272,7 +1286,7 @@ static inline void do_cyrix_devid(unsign
*dir0 = getCx86(CX86_DIR0);
*dir1 = getCx86(CX86_DIR1);
}
- sti();
+ restore_flags(flags);
}
/*
@@ -1316,7 +1330,9 @@ static void __init check_cx686_slop(stru
{
if (Cx86_dir0_msb == 3) {
unsigned char ccr3, ccr5;
+ unsigned long flags;
+ save_flags(flags);
cli();
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
@@ -1324,7 +1340,7 @@ static void __init check_cx686_slop(stru
if (ccr5 & 2)
setCx86(CX86_CCR5, ccr5 & 0xfd); /* reset SLOP */
setCx86(CX86_CCR3, ccr3); /* disable MAPEN */
- sti();
+ restore_flags(flags);
if (ccr5 & 2) { /* possible wrong calibration done */
printk(KERN_INFO "Recalibrating delay loop with SLOP bit
reset\n");
@@ -2092,15 +2108,17 @@ static int __init id_and_try_enable_cpui
if (dir0 == 5 || dir0 == 3)
{
unsigned char ccr3, ccr4;
+ unsigned long flags;
printk(KERN_INFO "Enabling CPUID on Cyrix processor.\n");
+ save_flags(flags);
cli();
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
ccr4 = getCx86(CX86_CCR4);
setCx86(CX86_CCR4, ccr4 | 0x80); /* enable cpuid */
setCx86(CX86_CCR3, ccr3); /* disable MAPEN */
- sti();
+ restore_flags(flags);
}
} else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: code of ps command
Naveen Kumar Pagidimarri wrote: > tell me the source where i can get the information about the > > > data structures/related system calls used for the > > implementation of the ps command. The ps command probably reads ALL or most of the info it needs from the /proc directory. The proc filesystem is a virtual filesystem implemented by the kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
> My money is on the unconditional sti()'s in the cyrix code. Possibly but the diff is wrong > - cli(); > + save_flags(flags); >>> cli() needed still - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: >128 MB RAM stability problems (again)
> Can someone please > point out to me > that he's actually running kernel-2.4.x on a machine with > more than 128 > MB RAM and that he's NOT having severe stability problems? > And can that same person PLEASE point out to me why 2.4.x is > crashing on > me (or help me to find out...)? %uname -a Linux cartman 2.4.0-64GB-SMP #1 SMP Wed Jan 24 15:52:30 GMT 2001 i686 unknown %uptime 8:35am up 57 days, 12:42, 2 users, load average: 2.00, 2.00, 2.00 %free total used free shared buffers cached Mem:254904251968 2936 092224 45028 -/+ buffers/cache:114716140188 Swap: 524656 14192510464 Could this be a 2.4 swap issue. You NEED at least RAM x2 swap. If you're just adding memory to a box that's stable with 128 megs and possibly 256 megs swap (you don't state, just guessing..) you've now got too little swap, and boom, stability goes bye-bye. Just haven't seen the swap issue mentioned this thread... =Don= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Arjan van de Ven wrote:
>
> On Thu, Jul 05, 2001 at 11:32:00PM +0800, Thibaut Laurent wrote:
> > And the winner is... Andrea. Kudos to you, I've just applied these patches,
> > recompiled and it seems to work fine.
> > Too bad, this was the perfect excuse for getting rid of those good old Cyrix
> > boxen ;)
>
> As Andrea's patches don't actually fix anything Cyrix related it's obvious
> that they just avoid the real bug instead of fixing it.
> It's a very useful datapoint though.
My money is on the unconditional sti()'s in the cyrix code.
--- linux-2.4.6/arch/i386/kernel/setup.cMon May 28 13:31:46 2001
+++ lk-ext3/arch/i386/kernel/setup.cFri Jul 6 01:37:39 2001
@@ -1243,12 +1255,13 @@ static int __init init_amd(struct cpuinf
/*
* Read Cyrix DEVID registers (DIR) to get more detailed info. about the CPU
*/
-static inline void do_cyrix_devid(unsigned char *dir0, unsigned char *dir1)
+static void do_cyrix_devid(unsigned char *dir0, unsigned char *dir1)
{
unsigned char ccr2, ccr3;
+ unsigned long flags;
/* we test for DEVID by checking whether CCR3 is writable */
- cli();
+ save_flags(flags);
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, ccr3 ^ 0x80);
getCx86(0xc0); /* dummy to change bus */
@@ -1272,7 +1285,7 @@ static inline void do_cyrix_devid(unsign
*dir0 = getCx86(CX86_DIR0);
*dir1 = getCx86(CX86_DIR1);
}
- sti();
+ restore_flags(flags);
}
/*
@@ -1316,15 +1329,16 @@ static void __init check_cx686_slop(stru
{
if (Cx86_dir0_msb == 3) {
unsigned char ccr3, ccr5;
+ unsigned long flags;
- cli();
+ save_flags(flags);
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
ccr5 = getCx86(CX86_CCR5);
if (ccr5 & 2)
setCx86(CX86_CCR5, ccr5 & 0xfd); /* reset SLOP */
setCx86(CX86_CCR3, ccr3); /* disable MAPEN */
- sti();
+ restore_flags(flags);
if (ccr5 & 2) { /* possible wrong calibration done */
printk(KERN_INFO "Recalibrating delay loop with SLOP bit
reset\n");
@@ -2092,15 +2106,16 @@ static int __init id_and_try_enable_cpui
if (dir0 == 5 || dir0 == 3)
{
unsigned char ccr3, ccr4;
+ unsigned long flags;
printk(KERN_INFO "Enabling CPUID on Cyrix processor.\n");
- cli();
+ save_flags(flags);
ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable MAPEN */
ccr4 = getCx86(CX86_CCR4);
setCx86(CX86_CCR4, ccr4 | 0x80); /* enable cpuid */
setCx86(CX86_CCR3, ccr3); /* disable MAPEN */
- sti();
+ restore_flags(flags);
}
} else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
On Thu, Jul 05, 2001 at 11:32:00PM +0800, Thibaut Laurent wrote: > And the winner is... Andrea. Kudos to you, I've just applied these patches, > recompiled and it seems to work fine. > Too bad, this was the perfect excuse for getting rid of those good old Cyrix > boxen ;) As Andrea's patches don't actually fix anything Cyrix related it's obvious that they just avoid the real bug instead of fixing it. It's a very useful datapoint though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
And the winner is... Andrea. Kudos to you, I've just applied these patches, recompiled and it seems to work fine. Too bad, this was the perfect excuse for getting rid of those good old Cyrix boxen ;) Thanks, Thibaut - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: >128 MB RAM stability problems (again)
> "Ragnar" == Ragnar Hojland Espinosa <[EMAIL PROTECTED]> writes: Ragnar> And here's a counter claim: At home have 128 + 64, both of Ragnar> different speeds and brands. Of course, to run properly you Ragnar> have to force the pc100 to run at 66, but other than that Ragnar> they're happy (96MB swap) [...] Yes, I imagine Linux does work ;-) The fact is that SDRAM is problematic (from a hardware perspective). For the OP, it could be a bus capacitance problem. If the boards are older, they might not be designed for larger memories with have a higher capacitance. Slowing down the accesses will stop the problem. You would do this by going to the BIOS and changing the CAS and RAS timings (or maybe you can change the SDRAM clock). SDRAM has a `NOP' state so that you can run at a higher clock speed, but delay a command. Anyways, I don't think that Linux is messing with the SDRAM controllers, but I am not an authority. Also, a single stick is always better than several smaller memory sizes. I was looking at the memtest86 web sight "http://www.memtest86.com/; and I didn't see anything that test for SDRAM cache lines. Single beat SDRAM read/writes are less stressful than BURSTS. It is typical for single beats read/write to work while bursts fail as four 32 bit values are written and read in quick succession. The `algorithm' description on the web page doesn't seem to test for this issue from what I see... of course I have been wrong before! regards, Bill Pringlemeir - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Module tracing.
> I want this. I've been thinking about it since your original post, and I also would be very much interested in having such a great tool by hand. Please mail me any information, or code to try, thanx! > > Perhaps you should also think about a non-devfs way of doing this, I don't > know, it's a matter of taste. Here's a Rube Goldbergesque way: when the > client registers, export a dynamically allocated major number through proc > and let the user mknod a device with that major. Yes I think, that would be a great alternative, using good old /proc. Constantin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: >128 MB RAM stability problems (again)
Ronald Bultje wrote: > No, it's the installation so I'm booting from the CD (mdk-8/RH-7.1 > installation CDs). Your cd might be corrupted. If you are using the same cd for both machines, try changing 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: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Andrea Arcangeli schrieb am Donnerstag, den 05. Juli 2001: > On Wed, Jul 04, 2001 at 11:28:17PM +0200, Manfred H. Winter wrote: > > Hi! > > > > I tried to install kernel 2.4.6 with same configuration as 2.4.5, but > > booting failed with: > > > > kernel BUG at softirq.c:206! > > do you have any problem with those patches applied? > > >ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre5aa1/00_ksoftirqd-7 > >ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre5aa1/00_softirq-fixes-4 > I didn't know about these patches but I'll give them a try. Manfred -- /"\| PGP-Key available at Public Key Servers \ / ASCII ribbon campaign | or "http://www.mahowi.de/pgp/mahowi.asc; X against HTML mail | RSA: 0xC05BC0F5 * DSS: 0x4613B5CA / \ and postings | AIM: mahowi42 * ICQ: 61597169 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
"Manfred H. Winter" wrote:
>
> ...
> > --- linux-2.4.6/kernel/softirq.c Wed Jul 4 18:21:32 2001
> > +++ lk-ext3/kernel/softirq.c Thu Jul 5 21:32:08 2001
> > @@ -202,8 +202,10 @@ static void tasklet_hi_action(struct sof
> > if (!tasklet_trylock(t))
> > BUG();
> > repeat:
> > - if (!test_and_clear_bit(TASKLET_STATE_SCHED, >state))
> > + if (!test_and_clear_bit(TASKLET_STATE_SCHED, >state)) {
> > + printk("func: %p\n", t->func);
> > BUG();
> > + }
> > if (!atomic_read(>count)) {
> > local_irq_enable();
> > t->func(t->data);
> >
>
> Okay, here's the output of gdb:
>
> (gdb) x/10i 0xc0118028
> 0xc0118028 : mov0x4(%esp,1),%eax
> 0xc011802c : cmpl $0x0,0xc025c2e4
> 0xc0118033 : jne0xc0118043
> 0xc0118035 : mov0xc024af20(,%eax,4),%eax
> 0xc011803c : test %eax,%eax
> 0xc011803e : je 0xc0118042
> 0xc0118040 : call *%eax
> 0xc0118042 : ret
> 0xc0118043 : lea(%eax,%eax,4),%eax
> 0xc0118046 : lea0xc025bf80(,%eax,4),%eax
>
Well I guess it tells us it's not random uninitialised
crud.
Just for interest: what happens if you swap around the lines
time_init();
softirq_init();
in init/main.c?
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: O_DIRECT! or O_DIRECT?
Hi, On Wed, Jul 04, 2001 at 08:23:10PM +, Miquel van Smoorenburg wrote: > >huge copies. But what part of the normal handling of sequential files > >would O_SEQUENTIAL change? Good handling of sequential files should > >be the default, not an explicitly-requested feature. > > exactly what I meant, since that is what MADV_SEQUENTIAL seems to do: > > linux/mm/filemap.c: > > * MADV_SEQUENTIAL - pages in the given range will probably be accessed > * once, so they can be aggressively read ahead, and > * can be freed soon after they are accessed. We already have "drop-behind" for sequential reads --- we lower the priority of recently read-in pages so that if they don't get accessed again, they can be reclaimed. This should be, and is, part of the default kernel behaviour for such things. The trouble is that you still need the VM to go around and clean up those pages if you need the memory for something else. There's a big difference between "can be freed" and "are forcibly freed". O_DIRECT behaves like the latter: the memory is automatically reclaimed after use so it results in no memory pressure at all, whereas the MADV_SEQUENTIAL type of behaviour just allows the VM to reclaim those pages on demand --- the VM still has to do the work. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Thu, 5 Jul 2001, Helge Hafting wrote: > > I am fine with "You have to use initrd (or similiar) _if_ you want this > feature." Nope. I do not want to maintain two interfaces. If we make user space the way to do these things, then we will do pretty much most of the driver setup etc in user space. We'd have to: we'd enter user space before drivers have had a chance to initialize, exactly because "features like these" can change the device mappings etc. And I don't want to have two completely different bootup paths. > But please don't make initrd mandatory for those of us who don't > need ACPI, don't need dhcp before mounting disks and so on. You would never even know the difference. You'd do a "make bzImage", and the default filesystem would just be embedded into the image. By default it probably doesn't need to do much - although things like the BIOS DPMI scan etc would surely be good to get rid of. Why complain about that? 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 Requirement Document - v0.0
> Well, on a laptop memory and disk bandwith are rarely wasted - they cost > battery life. I've been playing around with different scenarios to see the differences in performance. A good way to trigger the cache problem is to untar a couple of kernel source trees or other large amounts of files, until free memory is down to less than 2mb. Then try to fire up a few apps that need some memory. The hard drive thrashes around as the VM tries to free up enough space, often using swap instead of flushing out the cache. These source trees can then be deleted which frees up the memory the cache was using and performance returns to where it should be. However, if I just fire up enough apps to use up all the memory and then go into swap, response is still acceptable. If the app requires loading from swap there is just a short lag while the VM does its thing and then life is good. I don't expect to be able to run more apps than I have memory for without a performance hit, but I do expect to be able to run with over 128MB of "real" free memory and not suffer from performance degradation (which doesn't happen at present) Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Hi Alan! On Thu, 05 Jul 2001, Alan Cox wrote: > > This bug hits me since 2.4.6-pre5 but nobody answered to my emails... The > > code line is identical (and the softirq.c:206 ofc). > > > > Anyone, any idea? > > None at all. There are odd items in your config - like khttpd which if > involved might explain why there are not more reports. > But khttpd is compiled as a module which isn't loaded at the moment, the crash appears. The crash is just after "Calibrating delay loop... 333.41 BogoMIPS". At this moment, there should be no modules loaded. As others report the same error, it seems to be a conflict with Cyrix processors. Bye, Manfred -- /"\| PGP-Key available at Public Key Servers \ / ASCII ribbon campaign | or "http://www.mahowi.de/pgp/mahowi.asc; X against HTML mail | RSA: 0xC05BC0F5 * DSS: 0x4613B5CA / \ and postings | AIM: mahowi42 * ICQ: 61597169 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Is Swapping on software RAID1 possible in linux 2.4 ?
Nick DeClario wrote: > > Just out of curiousity what are the advantages to having a RAID1 swap > partition? Setting the swap priority to 0 (pri=0) in the fstab of all > the swap partitions on your system should have the same effect as doing > it with RAID but without the overhead, right? RAID1 would also mirror > your swap. Why would you want that? > > Regards, > -Nick > Hi, Setting swap priority to 0 is equivalent to RAID0 (striping) not RAID1 (mirroring). Mirroring your swap partition is important because if the disk containing your swap fails, your system is dead. If you want to keep your system running even if one disk fails you need to mirror ALL your active partitions including swap. If you only mirror your data partitions, your are only protected against data loss in case of a disk crash (assuming you shutdown gracefully before it panics while it tries to read/write on a crashed swap partition and leave your data in some inconsistent state). Regards -- Joseph Bueno - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Requirement Document - v0.0
Daniel Phillips <[EMAIL PROTECTED]> writes: > Also, notice that the scenario we were originally discussing, the off-hours > updatedb, doesn't normally happen on laptops because they tend to be > suspended at that time. No, even worse, it happens when you open the laptop for the first time in the morning, thanks to anacron. -- Alan Shutko <[EMAIL PROTECTED]> - In a variety of flavors! For children with short attention spans: boomerangs that don't come back. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
Hi Andrew!
On Thu, 05 Jul 2001, Andrew Morton wrote:
> > kernel panic every time (see original post). My CPU is a MediaGX, and
> > Manfred's one is a 6x86MX. What about yours ?
> > After my first unsuccessful attempt with a 2.4.6-pre3, I tried several other
> > 2.4.6-preX and 2.4.5-acX kernels. All 2.4.6 (since pre1) seem to be
> > affected, and so do the latest ac's. I don't have tested 2.4.7-pre[12] yet,
> > but looking at the changelog, I doubt the fix is in.
>
>
> It may help to know which tasklet is in the wrong state.
> Could you please add this patch:
>
> --- linux-2.4.6/kernel/softirq.c Wed Jul 4 18:21:32 2001
> +++ lk-ext3/kernel/softirq.c Thu Jul 5 21:32:08 2001
> @@ -202,8 +202,10 @@ static void tasklet_hi_action(struct sof
> if (!tasklet_trylock(t))
> BUG();
> repeat:
> - if (!test_and_clear_bit(TASKLET_STATE_SCHED, >state))
> + if (!test_and_clear_bit(TASKLET_STATE_SCHED, >state)) {
> + printk("func: %p\n", t->func);
> BUG();
> + }
> if (!atomic_read(>count)) {
> local_irq_enable();
> t->func(t->data);
>
Okay, here's the output of gdb:
(gdb) x/10i 0xc0118028
0xc0118028 : mov0x4(%esp,1),%eax
0xc011802c : cmpl $0x0,0xc025c2e4
0xc0118033 : jne0xc0118043
0xc0118035 : mov0xc024af20(,%eax,4),%eax
0xc011803c : test %eax,%eax
0xc011803e : je 0xc0118042
0xc0118040 : call *%eax
0xc0118042 : ret
0xc0118043 : lea(%eax,%eax,4),%eax
0xc0118046 : lea0xc025bf80(,%eax,4),%eax
HTH,
Manfred
--
/"\| PGP-Key available at Public Key Servers
\ / ASCII ribbon campaign | or "http://www.mahowi.de/pgp/mahowi.asc;
X against HTML mail | RSA: 0xC05BC0F5 * DSS: 0x4613B5CA
/ \ and postings | AIM: mahowi42 * ICQ: 61597169
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 Requirement Document - v0.0
On Thursday 05 July 2001 17:00, Xavier Bestel wrote: > On 05 Jul 2001 17:04:00 +0200, Daniel Phillips wrote: > > Also, notice that the scenario we were originally discussing, the > > off-hours updatedb, doesn't normally happen on laptops because they tend > > to be suspended at that time. > > Suspended != halted. The updatedb stuff starts over when I bring it back > to life (RH6.2, dunno for other distribs) Yes, but then it's normally overlapped with other work you are doing, like trying to read your mail. Different problem, one we also perform poorly at but for different reasons. -- 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: O_DIRECT please; Sybase 12.5
Andrea Arcangeli wrote: > > On Fri, Jul 06, 2001 at 12:28:15AM +1000, Andrew Morton wrote: > > ext3 journals data. That's unique and it breaks things (or rather, > > things break it). It'd be trivial to support O_DIRECT in ext3's > > writeback mode (metadata-only), but nobody uses that. > > I thought everybody uses metadata-only to avoid killing data-write > performance. ext3 has three modes: data=journal Data is journalled. Yes, this slows things down significantly. data=ordered The default mode and the most popular. All data is written to disk prior to a commit. Write throughput is good, and you don't have uninitialised data in your files after a crash. data=writeback Metadata-only. Better write throughput (in dbench, anyway), but only metadata integrity is preserved after a crash. ie: fsck says the fs is fine, but files can (and almost always do) contain random stuff after a crash. Ordered data mode is really nice. It's not magical though - for example, if you reset the machine during a kernel build, a subsequent `make' will fail because you have a number of .o files which have zero length. That's the length they happened to have when the machine went down. For ordered-data mode we need to keep track of all the buffers which are associated with a transaction's journalled metadata and ensure that they are written out before the transaction commits. That is done with a little structure which hangs off ->b_private. > So I thought it was ok to at first support O_DIRECT only > for metadata journaling, doing that should be a three liner as you said > and that is what I expected. Yup. metadata-only journalling is all-round much, much simpler. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Requirement Document - v0.0
On 05 Jul 2001 17:04:00 +0200, Daniel Phillips wrote: > > Well, on a laptop memory and disk bandwith are rarely wasted - they cost > > battery life. > > Let me comment on this again, having spent a couple of minutes more > thinking about it. Would you be happy paying 1% of your battery life to get > 80% less sluggish response after a memory pig exits? Told like this, of course I agree ! > Also, notice that the scenario we were originally discussing, the off-hours > updatedb, doesn't normally happen on laptops because they tend to be > suspended at that time. Suspended != halted. The updatedb stuff starts over when I bring it back to life (RH6.2, dunno for other distribs) Xav - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Requirement Document - v0.0
On Thursday 05 July 2001 16:00, Xavier Bestel wrote: > On 05 Jul 2001 15:02:51 +0200, Daniel Phillips wrote: > > Here's an idea I just came up with while I was composing this... along > > the lines of using unused bandwidth for something that at least has a > > chance of being useful. Suppose we come to the end of a period of > > activity, the general 'temperature' starts to drop and disks fall idle. > > At this point we could consult a history of which currently running > > processes have been historically active and grow their working sets by > > reading in from disk. Otherwise, the memory and the disk bandwidth is > > just wasted, right? This we can do inside the kernel and not require > > coders to mess up their apps with hints. Of course, they should still > > take the time to reengineer them to reduce the cache footprint. > > Well, on a laptop memory and disk bandwith are rarely wasted - they cost > battery life. Let me comment on this again, having spent a couple of minutes more thinking about it. Would you be happy paying 1% of your battery life to get 80% less sluggish response after a memory pig exits? Also, notice that the scenario we were originally discussing, the off-hours updatedb, doesn't normally happen on laptops because they tend to be suspended at that time. -- 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: Is Swapping on software RAID1 possible in linux 2.4 ?
Just out of curiousity what are the advantages to having a RAID1 swap partition? Setting the swap priority to 0 (pri=0) in the fstab of all the swap partitions on your system should have the same effect as doing it with RAID but without the overhead, right? RAID1 would also mirror your swap. Why would you want that? Regards, -Nick Peter Zaitsev wrote: > > Hello linux-kernel, > > Does anyone have information on this subject ? I have the constant > failures with system swapping on RAID1, I just wanted to be shure > this may be the problem or not. It works without any problems with > 2.2 kernel. > > -- > Best regards, > Peter mailto:[EMAIL PROTECTED] > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Nicholas DeClario Systems EngineerGuardian Digital, Inc. (201) 934-9230Pioneering. Open Source. Security. [EMAIL PROTECTED]http://www.guardiandigital.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 Requirement Document - v0.0
On Thursday 05 July 2001 16:00, Xavier Bestel wrote: > On 05 Jul 2001 15:02:51 +0200, Daniel Phillips wrote: > > Here's an idea I just came up with while I was composing this... along > > the lines of using unused bandwidth for something that at least has a > > chance of being useful. Suppose we come to the end of a period of > > activity, the general 'temperature' starts to drop and disks fall idle. > > At this point we could consult a history of which currently running > > processes have been historically active and grow their working sets by > > reading in from disk. Otherwise, the memory and the disk bandwidth is > > just wasted, right? This we can do inside the kernel and not require > > coders to mess up their apps with hints. Of course, they should still > > take the time to reengineer them to reduce the cache footprint. > > Well, on a laptop memory and disk bandwith are rarely wasted - they cost > battery life. Then turn the feature off. -- 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: O_DIRECT please; Sybase 12.5
On Fri, Jul 06, 2001 at 12:28:15AM +1000, Andrew Morton wrote: > ext3 journals data. That's unique and it breaks things (or rather, > things break it). It'd be trivial to support O_DIRECT in ext3's > writeback mode (metadata-only), but nobody uses that. I thought everybody uses metadata-only to avoid killing data-write performance. So I thought it was ok to at first support O_DIRECT only for metadata journaling, doing that should be a three liner as you said and that is what I expected. > >From a quick look it seems that we'll need fs-private implementations > of generic_direct_IO() and brw_kiovec() at least. brw_kiovec is called by generic_direct_IO, so yes, all you need is a private generic_direct_IO implementation to deal with the journaled data writes. > I'll take a closer look. OK, thanks! 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/
OOPS (kswapd) in 2.4.5 and 2.4.6
Hello
Presumably this has already been mentioned, but since it seems like an ongoing
thing (I've seen a similar topic discussed at
http://kt.zork.net/kernel-traffic/) I thought it wouldn't hurt to provide
more info.
We've noticed the following kernel error since 2.4 (2.4.1-2.4.6). It appears to
be swap (kswapd thread specific?) related. The same error is reported on
several SMP machines after only a short period (an hour or less). The problem
has only started since we upgraded to 2.4.
Here's two ksymoops outputs from different machines (on 2.4.5 the first server
would eventually fail with memory errors (sorry, don't have the specific
error, but it involved 'semget' and (eg) apache would refuse to launch) and
require a reboot; the second server would not require a reboot). With 2.4.6
the error still appears, but the servers *seem* more stable (ie, not requiring
a reboot).
Please advise if more detail is required or if anything else will help.
regards
Henry
Hardware:
---
Our test servers are:
Dual-cpu pentium 233 (intel) with 128MB RAM and more than double that swap.
Software:
---
Kernel: 2.4.6
gcc: egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) and gcc version 2.95.2
19991024 (as I type this I realise the diff with compilers - surely that's not
the cause though, since compiling 2.2 with both was not a problem)
Distribution: slackware 7 with the latest e2fsprogs/modutils/util-linux.
Server1: --
cpu: 0, clocks: 668166, slice: 222722
cpu: 1, clocks: 668166, slice: 222722
Unable to handle kernel NULL pointer dereference at virtual address 0008
c01b4227
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010207
eax: 0001 ebx: ecx: 00c0 edx: c12c49c0
esi: c12d3f4c edi: 0001 ebp: c0d0f2a0 esp: c12d3ee0
ds: 0018 es: 0018 ss: 0018
Process kswapd (pid: 3, stackpage=c12d3000)
Stack: c12d3f4c c12d3f4c c01330cb 0001 001c4300 c1203048
0028 c0129752 0001 c1203048 0305 c12d3f48 1000
001c4300 c1203048 0028 c12d3f48 1000 1c43
Call Trace: [] [] [] [] [] [] []
[] []
Code: 0f b7 43 08 66 c1 e8 09 0f b7 f0 8b 43 18 a8 04 75 19 68 a7
>>EIP; c01b4227<=
Trace; c01330cb
Trace; c0129752
Trace; c0106cec
Trace; c012981f
Trace; c012a4e8
Trace; c0128b1d
Trace; c01293f5
Trace; c0129486
Trace; c01054cc
Code; c01b4227
<_EIP>:
Code; c01b4227<=
0: 0f b7 43 08 movzwl 0x8(%ebx),%eax <=
Code; c01b422b
4: 66 c1 e8 09 shrw $0x9,%ax
Code; c01b422f
8: 0f b7 f0 movzwl %ax,%esi
Code; c01b4232
b: 8b 43 18 movl 0x18(%ebx),%eax
Code; c01b4235
e: a8 04 testb $0x4,%al
Code; c01b4237
10: 75 19 jne2b <_EIP+0x2b> c01b4252
Code; c01b4239
12: 68 a7 00 00 00pushl $0xa7
Server2:
--
cpu: 0, clocks: 668219, slice: 222739
cpu: 1, clocks: 668219, slice: 222739
Unable to handle kernel NULL pointer dereference at virtual address 0008
c01bd75b
*pde =
Oops:
CPU:1
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010207
eax: ebx: ecx: 0001 edx:
esi: 0002 edi: 0001 ebp: c12d5f4c esp: c12d5ee4
ds: 0018 es: 0018 ss: 0018
Process kswapd (pid: 3, stackpage=c12d5000)
Stack: 0002 c0948d40 c01345bf 0001 0020b000 c1192208
0008 1000 c012a7c7 0001 c1192208 0302 c12d5f48 1000
0020b000 c1192208 0008 0030 c12d5f48 20b0 030200c0
Call Trace: [] [] [] [] [] [] []
[] []
Code: 0f b7 43 08 66 c1 e8 09 0f b7 f0 8b 43 18 a8 04 75 1b 68 a7
>>EIP; c01bd75b<=
Trace; c01345bf
Trace; c012a7c7
Trace; c012a89c
Trace; c012b56c
Trace; c0129a44
Trace; c012a445
Trace; c012a4d6
Trace; c0105000 <_stext+0/0>
Trace; c010550b
Code; c01bd75b
<_EIP>:
Code; c01bd75b<=
0: 0f b7 43 08 movzwl 0x8(%ebx),%eax <=
Code; c01bd75f
4: 66 c1 e8 09 shrw $0x9,%ax
Code; c01bd763
8: 0f b7 f0 movzwl %ax,%esi
Code; c01bd766
b: 8b 43 18 movl 0x18(%ebx),%eax
Code; c01bd769
e: a8 04 testb $0x4,%al
Code; c01bd76b
10: 75 1b jne2d <_EIP+0x2d> c01bd788
Code; c01bd76d
12: 68 a7 00 00 00pushl $0xa7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: [2.4.6] kernel BUG at softirq.c:206!
On Thu, Jul 05, 2001 at 03:36:29PM +0100, Arjan van de Ven wrote: > Andrea Arcangeli wrote: > > > > On Wed, Jul 04, 2001 at 11:28:17PM +0200, Manfred H. Winter wrote: > > > Hi! > > > > > > I tried to install kernel 2.4.6 with same configuration as 2.4.5, but > > > booting failed with: > > > > > > kernel BUG at softirq.c:206! > > > > do you have any problem with those patches applied? > > > > >ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre5aa1/00_ksoftirqd-7 > > >ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.6pre5aa1/00_softirq-fixes-4 > > > > Is there anything in here that fixes a Via/Cyrix specific bug ? definitely not. The softirq.c:206 bug cannot be caused by any hardware bug, unless the bug triggers memory corruption exactly in the tasklet->state word (which sounds unlikely since different people triggered the bug using different binary kernels that are unlikely to allocate t->state exactly in the same place). 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/
