Re: SysRq behavior
On Mon, 11 Dec 2000, James Simmons wrote: > > > When built into the Kernel, by only pressing the > > > PrintScreen/SysRq the current application is terminated (tested > > > on a console and GNU screen). Is this just me or I should > > > expect it? Well this should happen even when sysrq is NOT compiled into the kernel... > > Probably bug. Happens for me, too, and it is pretty nasty. Not a bug - just an easy-to-disable "feature" - read on ;) > Just played with this bug. It doesn't kill a login shell but does any > app running on it. I just went looking for where "Quit" is printed > out. When I press SysRq Quit is printed on the command line. Any ideas? Well that "print-screen" key is usually bound to ^\ : % dumpkeys | grep 'e 99' keycode 99 = Control_backslash control alt keycode 99 = Meta_Control_backslash Now by default ^\ is bound to sigquit - and should be as quite a few programs depend on that... % dumpkeys | grep [^_]Control_backslash keycode 5 = four degree dollar Control_backslash Control_backslash altgr control keycode 12 = Control_backslash control keycode 43 = Control_backslash keycode 99 = Control_backslash Looks like there're quite a few ways to generate ^\ - so disabling one of them won't hurt: % echo 'keycode 99 = VoidSymbol' | loadkeys (Note that this leaves all the "modified" versions of sysrq to do whatever they were already doing - so shift-printscreen will still generate ^\) In any case putting that somewhere in your bootup scripts should solve it ;) (or even users' login scripts as Linux allows anyone to screw up the keyboard mappings - why?!) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
netfilter, nat & packet floods?
Anyone know how to properly filter packet floods using iptables w/ nat? >From my point of view 2.4.x:ish connection tracking seems to be quite a bit more vulnerable to packet flooding than the 2.2.x:ish IP Masquerading used to be (when using default configuration that is). First we try to make both input & output flood-filtered: iptables -t nat -I PREROUTING -j floodprot iptables -t nat -I OUTPUT -j floodprot For example the following rule seems to match no packets: iptables -t nat -A floodprot -p tcp --tcp-flags ALL NONE -j DROP (According to the documentation --tcp-flags ALL NONE should match the so-called "Null scan", aka nmap -sN) The following rules seem to rate-limit ping & traceroute properly: iptables -t nat -A floodprot -p icmp --icmp-type echo-request -m limit \ --limit 4/s ! -f -j RETURN iptables -t nat -A floodprot -p icmp --icmp-type echo-request -j DROP iptables -t nat -A floodprot -p udp --dport 33400:33499 --sport \ 5:65535 -m limit --limit 4/s ! -f -j RETURN iptables -t nat -A floodprot -p udp --dport 33400:33499 --sport \ 5:65535 -j DROP But is there a better (=simpler) way to do that? Also if I happen to have a bunch of interfaces that are not supposed to get any routing and/or nat from this box, tracking connections on them seems to be waste of resources to me - there probably is no way to turn connection tracking off for some interface pairs? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIIX4 BX Errata for DMA errors.
On Fri, 24 Nov 2000, Andre Hedrick wrote:
> Anyone having DMA errors that are dmaproc: error 14, there is not a clean
> workaround yet. Also the Intel erratas state that only a bus reset will
> clear the hang, but the details are loose.
We talking about errors like the following one? :
Nov 18 10:08:46 bx3 kernel: hdb: timeout waiting for DMA
Nov 18 10:08:46 bx3 kernel: ide_dmaproc: chipset supported ide_dma_timeout func only:
14
Nov 18 10:08:46 bx3 kernel: hdb: irq timeout: status=0xd0 { Busy }
Nov 18 10:08:46 bx3 kernel: hda: DMA disabled
Nov 18 10:08:46 bx3 kernel: hdb: DMA disabled
Nov 18 10:08:48 bx3 kernel: ide0: reset: success
If so, anyone happen to be able to help me figure out why that keeps
happening on hdb & hdd while it never happens on hda?
/dev/hda:
Model=IBM-DJNA-352500, FwRev=J51OA30K, SerialNo=GW0GWF37316
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34
BuffType=DualPortCache, BuffSize=1966kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=49981680
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4
/dev/hdb:
Model=IBM-DTTA-371440, FwRev=T71OA73A, SerialNo=WK0WKG29267
BuffType=DualPortCache, BuffSize=462kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=28229040
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 *udma1 udma2
/dev/hdd:
Model=IBM-DTTA-371440, FwRev=T71OA73A, SerialNo=WK0WKA28245
BuffType=DualPortCache, BuffSize=462kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=28229040
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
DMA modes: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
Also is there a way to actually use /proc/ide/hd?/smart_* ?
# diff -u --recursive 19990822 20001125 | diffstat
hda/smart_values | 14 +++---
hdb/smart_values | 12 ++--
hdd/smart_values | 10 +-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: silly [< >] and other excess
On Thu, 23 Nov 2000, Charles Cazabon wrote: > [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Thats because too many things get put on a line then. > > > And because we do [] [] not [][] ? > > > > In the good old times we had foo bar for a total of 8*(8+1) = 72 > > positions. Now we have [] [] which takes 8*(8+1+4) = 104 > > positions. If you turned this into 6 items per line instead of 8, > > it would certainly improve matters a bit. > > The original poster complained the output lines were too wide for the screen > on his PC. Perhaps he should change his console mode to 132 characters wide > (via SVGATextMode or such) -- voila, no more problem, no broken kernel patches. Well that 72 characters is also known as the "safe" email line length... ... and besides some people still use the old VT330s and alike ;) But in practice even those 79 chars would be better than 104. -- No .sig here... especially no 128x48 .sig here - nor 132xYuch... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
