Re: Question about SysRq
Unfortunately, > the only one that responds is sysrq-b, which boots the box without > syncing or unmounting the disks. Not only does that piss me off but it's > led to some fs corruption as well (which pisses me off even more). sysrq-b > is the *only* combination I can get working when this happens. I looked a bit at the source of sysrq handling. I've found there is rather big difference between sysrq+b and other killers handling. Sysrq+b is just called with pretty straitforward fashion - stops other processors on SMP and reboots directly (hardware impulse or triple fault) or through the bios - so it just calls for the corruptions. On the other side sysrq+s marks a single variable, which will be tested next cycle in the bdflush kernel threads' main loop, and adds bdflush to scheduler runqueue list. So it gets possibility to check for emergency sync onle when gets next scheduled. Does it ? Can you anyhow find something in your logs/console/serial console messages like 13.13.2000 kernel : Sysrq: Emergency Sync (this should be present - is written within keyboard handler, not after shedule) and what's next logs ? We could determine, if the bdflush thread got scheduled and called emergency syncing routine indeed. As you wrote no of your processes does respond - probably telnet will not help. You may try to write experimental programme, that only log say current time every n seconds, and see, if it just stopped to log messages after lockup-time. If not - it doesn't get scheduled. If continues - there's problem with syncing. Again - try, as far as i understand, log kernel messages to serial console or alike, because the messages should not get written to logfiles - syslogd can't be woken up eg. Quick help against those corruptions, which comes on my mind, is use the reiserfs. I have no real experiences with that and its reliability, also as aj followed some of messages in this list about resierfs - it has some problems too - but in definition it shoudn't get corrupted by not- syncing reboot. But i see this not much helpfull ,cause if you really would depend on big reliability, you wouldn't intall 2.3.x-pre kernel :) There go also occasionally discussions about watchdogs - it may be helpfull - but none of the two really solve the problem. LW: today a got ugly lockup with dosemu and experimental execution of virtual pool ;). Neither Sysrq+b functioned. But that's probably another story. Root or privilege suid processes (X server among them) need really just a 1-bit error to corrupt near what they like. The least fsck sessions and nice day B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Basic Text Mode (was: Re: Question about SysRq)
Some stupid questions about videomem: 1) How do 2 or more X servers, or svgalibbed apps share the same physical video memory ? Does it get saved to ram when switching between them ? 2) Does console switching (gfx or text) save and restore all registers of videocard in kernel ? Or kernel only restores text things and gfx apps must it do in their own ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Basic Text Mode (was: Re: Question about SysRq)
> It is a very good idea, and to implement quite easy. You just do have to > diff between three types of video cards (MDA, MGA and HGC vs. CGA and AGA vs. EGA+). > Then you do direct register writes. For the HGC I did it recently in a DOS proggy > which switched from text to gfx and back. I had a TSR which simulated a gfx BIOS. > Only problem is, I lost the source. But I could rewrite and test it on request. > I even would put it under GPL for the kernel (normally this is a no-no for me), > just ask me. I will write it in NASM then because I can't the AT&T syntax. > For non-i386 Platforms I do not know about this topic. (IIRC the Apples didnt > even have a text mode) > Maybe I could look up the EGA register values somewhere. The hardware part of mode restoring could really be done the register way and may be interesting - i did code a lot in dos and this is what i did too, if i had experience with register programming and vga(..). Mostly i skipped this arena, because i have had information about vga registers just enough to damage monitor, so rather used VESA for video stuff :) But i think only this way should break some internal state of console or what driver. Thanks for the willingness, thought. I read from the thread - James Simmons, console developer, is working on it, so you may eg. ask to cooperate with him, he surely has a lot of ideas of text/vga switching in linux. Cheers B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about SysRq
>You could even set sysvinit > to run it when you press a certain key combo. You mean inittab & kbrequest ? I didn't know about this. Must have a look at some documentation, manpage didn't help me a lot. Besides, you have very interesting name/domain, cheaf of bandits !! B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Non keyboard trigger of Alt-SysRQ-S-U-B
> If you have a serial console on the server, you can get sysrq by > sending a serial break followed by the character. Hi, i've tried it with minicom and functioned : ctrl+a+F and key for function as in normal sysrq. This approach will probably not help you a lot thought, since you wouldn't have access to your serial console too. If you don't get your problems solved till now, i could make a simple single-purpos module which will export a syscall to priviledged process to call sysrq functions. Gonna to have a look... Bye B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Non keyboard trigger of Alt-SysRQ-S-U-B
Hi Nathan, I've just made an experimental module which offers syscall to privileged process, which internally translates itself into real sysrq handler (handle_sysrq) defined in drivers/char/sysrq.c. It occupates itself one of unussed linux system calls (concretely stty - no. 31). Makefile and patch for that sysrq.c are included in attached archive. (I stronly believe i didn't made it reversed :). The patch itself only exports 1 variable and 1 function from sysrq.c, that normally aren't. You can make a daemon, which listens on socket and triggers commands send by clients. Dont call sysrq+boot until a while needed to sync and unmount. This check, if sync and/or umount were finished before boot, should be really done, but it would require more changes in kernel source. And of course, the security is to be taken in client/server into account. Bye B. srq.tar.gz
Re: Compiling problem kernel 2.4.2
> gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -02 > -fomit-frame-pointer -fno-strict-aliasing -pipe -march=i486 -c -o init/main.o > init/main.c > gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -02 > fomit-frame-pointer -fno-strict-aliasing -pipe -march=i486 > -DUTS_MACHINE='"i386"' -c -o init/version.o init/version.c > cpp: /usr/src/linux/include/linux/compile.h: Input/output error > init/version.c:20: `UTS_VERSION' undeclared here (not in a function) > init/version.c:20: initializer element for `system_utsname.version' is not > constant > init/version.c:25: parse error before `LINUX_COMPILE_BY' > make: *** [init/version.o] Error 1 Hi. -02 mean -O2 ? Do you comile over NFS ? Did you try it to local-compile , or compile on another system version ? It really may be nfs or some system bug, if you compile on some old system (what kernel version did you compile on ? They me differ on slack and redhat machines.) I recently had a bug with gnu assembler, which could safely compile all files a tried, but not the ones that consisted of any combination 3 chars name+1 char suffix. Really interesting bug too. Bye B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 in khttpd, 2.4.4-ac3
Hello. I was performing some benchmarks of http transfer with program 'ab' (apache benchmark), comparing, how it will perform with/without kernel khttpd support. I've got oops several times, the error is replicable on my machine, without appache even started. The exact order of actions i did: modprobe khttpd I let the default configuration for first try ( threads=2, maxconnect=1000, clientport=80, serverport=8080...) echo 1 > /proc/sys/net/khttpd/start ab -n 1000 http://localhost:8080/icons/logo.gif (included as attachement) and everithing goes well for now, really pretty boost. echo 1 > /proc/sys/net/khttpd/stop got message: Daemon 1 has ended, Daemon 0 has ended After this step, i see from ps aux: [khttpd - 0 ] Now, stopped the httpd accelerator and increased number of threads to four: echo 1 > /proc/sys/net/khttpd/stop echo 4 > /proc/sys/net/khttpd/threads Restarted khttpd: echo 1 > /proc/sys/net/khttpd/start (i see some defunct-ed threads too now) Then i reruned the 'ab' benchmark like above: ab -n 1000 http://localhost:8080/icons/logo.gif and the oops become. If i optionally make yet another try of 'ab' benchmark after this oops, i get another oops of type "Aieee in interrupt...killing interrupt"... - Here are infos: ksymoops 2.3.7 on i586 2.4.3-ac3. Options used -v /usr/src/linux/vmlinux (specified) -k ./ksyms (specified) -l ./modules (specified) -o /lib/modules/2.4.3-ac3/ (specified) -m /usr/src/linux/System.map (specified) Apr 14 14:44:04 Boris kernel: Oops: Apr 14 14:44:04 Boris kernel: CPU:0 Apr 14 14:44:04 Boris kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Apr 14 14:44:04 Boris kernel: EFLAGS: 00010202 Apr 14 14:44:04 Boris kernel: eax: ebx: c141702c ecx: 0004 edx: 0004 Apr 14 14:44:04 Boris kernel: esi: edi: c2897a01 ebp: esp: c1415f14 Apr 14 14:44:04 Boris kernel: ds: 0018 es: 0018 ss: 0018 Apr 14 14:44:04 Boris kernel: Process khttpd - 0 (pid: 1016, stackpage=c1415000) Apr 14 14:44:04 Boris kernel: Stack: c000 c1417000 c289638a c2897a01 c141702c c000 c1417000 Apr 14 14:44:04 Boris kernel: c2897538 Apr 14 14:44:04 Boris kernel: c1417000 c02c936c c1417000 c2899e80 0fff Apr 14 14:44:04 Boris kernel: Call Trace: [] [] [] [] [] [] [] Apr 14 14:44:04 Boris kernel:[] [] [] [] Apr 14 14:44:04 Boris kernel: Code: f3 a6 74 0a 96 46 80 78 ff 00 75 ec 31 c0 5e 5f c3 90 90 90 >>EIP; c01bd9a8<= Trace; c289638a <[khttpd]ParseHeader+26/2dc> Trace; c2897a01 <[khttpd].rodata.start+361/6ed> Trace; c2897538 <[khttpd]DecodeHeader+b4/198> Trace; c2899e80 <[khttpd]Buffer+180/37f> Trace; c28973e6 <[khttpd]WaitForHeaders+76/b8> Trace; c28951f1 <[khttpd]MainDaemon+155/218> Trace; c2898e40 <[khttpd]CountBuf+0/40> Trace; c2898e00 <[khttpd]Running+0/40> Trace; c010542c Trace; c2898e40 <[khttpd]CountBuf+0/40> Trace; c2898e40 <[khttpd]CountBuf+0/40> Code; c01bd9a8 <_EIP>: Code; c01bd9a8<= 0: f3 a6 repz cmpsb %es:(%edi),%ds:(%esi) <= Code; c01bd9aa 2: 74 0a je e <_EIP+0xe> c01bd9b6 Code; c01bd9ac 4: 96xchg %eax,%esi Code; c01bd9ad 5: 46inc%esi Code; c01bd9ae 6: 80 78 ff 00 cmpb $0x0,0x(%eax) Code; c01bd9b2 a: 75 ec jnefff8 <_EIP+0xfff8> c01bd9a0 Code; c01bd9b4 c: 31 c0 xor%eax,%eax Code; c01bd9b6 e: 5epop%esi Code; c01bd9b7 f: 5fpop%edi Code; c01bd9b8 10: c3ret Code; c01bd9b9 11: 90nop Code; c01bd9ba 12: 90nop Code; c01bd9bb 13: 90nop - cat /proc/modules: khttpd 21072 5 autofs4 8128 6 (autoclean) 3c509 6896 1 (autoclean) awe_wave 155936 0 sb 7008 0 sb_lib 32368 0 [sb] uart401 6000 0 [sb_lib] sound 52704 0 [awe_wave sb_lib uart401] nls_iso8859-1 2848 2 (autoclean) nls_cp437 4352 2 (autoclean) vfat8400 2 (autoclean) fat29120 0 (autoclean) [vfat] floppy 45872 0 (autoclean) ide-cd 25904 0 (autoclean) cdrom 27008 0 (autoclean) [ide-cd] --- ver_linux script: Linux Boris 2.4.3-ac3 #1 Fri Apr 13 20:48:04 CEST 2001 i586 unknown Gnu C 2.95.3
Re: Is swap == 2 * RAM a permanent thing?
On Thu, Mar 15, 2001 at 11:44:52PM -0300, Rik van Riel wrote: > On Thu, 15 Mar 2001, William T Wilson wrote: > > > it seems to me that in 2.2.x it looks like this: > > > > total usage == swap + RAM > > under 2.4.x it looks like: > > total usage == swap > > total usage == maximum(swap, ram) Hi, Do you in fact talk about 1) curren usage == maximum(swap, ram) or 2) virtual ram capacity == maximum(swap, ram) ? I'm a bit confused. My next question is: some time ago i've read, that code segments of process, which comes from executable and should stay unmodified during process duration, are not swapped into swap space, cause they can be restored back from the executable. This should be ok, because in protect mode no one can write into code seg. This does seem to be true for win, because i cannot delete executable file when it's just run, but under linux i can delete /bin/bash without any problem. Why this is so ? Because of security ? Say my disk gets corrupted right at blocks executable image si contained and swapping in page(s) from this errorneous area should lock/corrupt system ? Code content can be changed indirectly in case data or some read-write segment overlaps code segment. Does linux count with such a situation ? (may data segment overlap code seg ?) ThanksBoro email: [EMAIL PROTECTED] PGP signature
Re: Utility for re-patritioning
Hello, try resize2fs from e2fsprogs package. B. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Cannot compile 2.4.2-ac23 kernel
Hello anybody. Today i applied A.COX's patch 2.4.2-ac23 on 2.4.0 kernel previsiously patched with 2.4.1 and 2.4.2 patches. Before everything used to compile well, but with this patch i get this error message: setup.c: In function `identify_cpu': setup.c:2280: `tsc_disable' undeclared (first use in this function) setup.c:2280: (Each undeclared identifier is reported only once setup.c:2280: for each function it appears in.) and compilation stops. Did i do wrong, if i patched ac23 over clean 2.4.2, or should i have to patch ac23 directly over 2.4.1 (2.4.0 ?). I tried both, but got lots of error messages. My current gcc: 2.95.3 make: 3.79.1 as:2.10.90 CPU: Intel P1 166 MMX Can somebody help me, what did i do wrong ? Thanks B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question about SysRq
Hi.
I managed fullowing situation: user with no ulimits will run script like
this:
#! /usr/bin/perl
while (1)
{
fork();
};
on say tty2. The processes get created pretty fast. After a short while
I supposed a single solution to this to kill all session by alt+sysrq+k,
but nothing happened. Under normal averagely loaded situation, this will
imidiately kill all processes on current vt and bring getty prompt.
Shouldn't it function similiarily in former case ? I see all processes on vt
get SIGKILL, so what's hapenned ? Maybe I had to wait
a bit longer for kernel to accomplish that ? Killing all processes with init
(alt+sysrq+i) seems to be immediate.
Thought, i really love all sysrq properties of linux, so i need less often
to make hardware resets an then await and fear, what fsck will print.
One more property, that i'd like to have should be request key to force the
most basic text mode (say 80x25) on the console, when eg. X freezes and
i kill its session, then last gfx mode resides on the screen and see no way
to restore back the text mode - /usr/bin/reset or something alike will not
do it. But it seems to be not a good idea at all, does it ?
Cheers B.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
