* Re: Help! ip traffic accounting and bidirection with iptables ??
From: Oskar Berggren @ 2002-12-16 11:12 UTC (permalink / raw)
To: Toth Szabolcs; +Cc: netfilter, netfilter-devel
In-Reply-To: <Pine.LNX.4.21.0212131702290.24104-100000@eagle.ajkanet.hu>
[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]
Toth Szabolcs wrote:
>
> ipchains -N acct
> ipchains -A input -j acct -s 192.168.0.0/16 -b
> ipchains -A output -j acct -s 192.168.0.0/16 -b
>
> ipchains -A acct -p all -s 192.168.0.19 -i eth1 -b
> ipchains -A acct -p all -s 192.168.2.10 -i eth1 -b
> ipchains -A acct -p all -s 192.168.2.26 -i eth1 -b
> ipchains -A acct -p all -s 192.168.2.42 -i eth1 -b
> ipchains -A acct -p all -s 192.168.2.58 -i eth1 -b
> ......
> .....
> .....
> (n+1)
>
Hmm, i haven't worked extensively with ipchains, but isn't -b
just a shorthand for inserting two rules? Isn't it actually
2n rules in the kernel?
Anyway, a different means of doing this is using an iptables
extension wich I've written, called IPSTATS. It works
as a target.
To use, compile and insmod the module. Insert one rule
that selects the traffic you want to account for, irregardless
of interal ip. Target this traffic to the IPSTATS module, which
will separate the traffic based on ip-address. Then use a
separate utility 'ipstats' to list the counters.
If your ip-addresses are distributed sparsely in the B-net you
are using, this will use a lot of memory, but it will take
constant time.
iptables -A FORWARD -s 192.168.0.0/16 -j IPSTATS --is-id 1 \
--is-start-ip 192.168.0.0 --is-size 65536
--is-source
iptables -A FORWARD -d 192.168.0.0/16 -j IPSTATS --is-id 2 \
--is-start-ip 192.168.0.0 --is-size 65536
--is-source
# ./ipstats --list 1 |head -4
ac_idx: 1 elements: 65536
192.168.0.0 0 0
192.168.0.1 0 0
192.168.0.2 0 0
[...]
If your ip-addresses are distributed in only the lower part
of the subnet, it is perfectly valid to specify a smaller
size to the IPSTATS module.
Included is the source of the latest version. No guarantees of
any kind. We have recently started using it in a production
environment, and I know of at least one other person/organization
using it.
regards
Oskar
[-- Attachment #2: ipstats-0.8.5.tar.gz --]
[-- Type: application/gzip, Size: 13164 bytes --]
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Pavel Machek @ 2002-12-16 11:17 UTC (permalink / raw)
To: Albert D. Cahalan; +Cc: linux-kernel, hpa, terje.eggestad
In-Reply-To: <200212160733.gBG7XhD67922@saturn.cs.uml.edu>
Hi!
> >> Have apps enter kernel mode via Intel's purposely undefined
> >> instruction, plus a few bytes of padding and identification.
> >> Require that this not cross a page boundry. When it faults,
> >> write the SYSENTER, INT 0x80, or SYSCALL as needed. Leave
> >> the page marked clean so it doesn't need to hit swap; if it
> >> gets paged in again it gets patched again.
> >
> > Thats *very* dirty hack. vsyscalls seem cleaner than that.
>
> Sure it's dirty. It's also fast, with the only overhead being
> a few NOPs that could get skipped on syscall return anyway.
> Patching overhead is negligible, since it only happens when a
> page is brought in fresh from the disk.
Yes but "read only" code changing under you... Should better be
avoided.
> The vsyscall stuff costs you on every syscall. It's nice for
Well, the cost is basically one call. That's not *that* big cost.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
^ permalink raw reply
* Re: [linux-lvm] lvm-problems. vgda inconsistency
From: Dieter Franzke @ 2002-12-16 11:10 UTC (permalink / raw)
To: linux-lvm, Heinz J . Mauelshagen
In-Reply-To: <20021216164845.A19655@sistina.com>
Hi,
Am Montag, 16. Dezember 2002 16:48 schrieb Heinz J . Mauelshagen:
> On Mon, Dec 16, 2002 at 09:23:58AM +0100, Dieter Franzke wrote:
> > Hi,
> >
> > I've created a pv, vg and lv
> > via pvcreate, vgcreate and lvcreate.
> > Everything went well.
> > But when I tried to initialize a filesystem via mkfs.xfs I get following
> > error:
> >
> > VGDA in Kernel and lvmtab are NOT consistent; please run vgscan
> >
> > When I run vgscan nothing is changed.
> > How can I fix this without rebooting?
>
> Rebooting won't help this. vgscan _reads_ the LVM metadata on the PVs
> and tries to update the working copies of the metadata in /etc/lvmtab*.
> No change to the metadata on the PVs happens during a vgscan run.
>
> Does vgscan display any error?
2 VGs were recognized, the 3rd (the last I've created) isn't displayed.
> What does vgck display?
VGDA in Kernel and lvmtab are NOT consistent; please run vgscan
>
> vgck should check the ondisk metadata fine or we need to restore it
> from archive copies in /etc/lvmconf/ (please save those!)
in my /etc/lvm-conf there is .conf of my third VG /etc/lvm-conf/daten.conf
vgcfgrestore -n daten -t /dev/sda1 works fine
backup of VolumeGroup "daten" is consistent
an the option -l works also fine.
but a vgcfgrestore -n daten -f /etc/lvm-conf/daten.conf /dev/sda1
displays: can't restore part of active Volume group daten.
But vgscan says: daten isn't existent.
shows only buero, datenbu
ciao
dieter
--
registered linuxuser 199810
it's time to close windows....
^ permalink raw reply
* Re: Q: i845MP/P4-M laptop support? (specific problems listed)
From: James H. Cloos Jr. @ 2002-12-16 11:16 UTC (permalink / raw)
To: linux-kernel; +Cc: Simon Oosthoek
In-Reply-To: <20021216100610.GA16816@margo.student.utwente.nl>
>>>>> "Simon" == Simon Oosthoek <simon@margo.student.utwente.nl> writes:
Simon> - missing driver for smartmedia slot (I guess this is a feature
Simon> request, if it's not available)
Simon> 02:06.0 System peripheral: Toshiba America Info Systems: Unknown device 0804
For the benefit of the archives, that is in the 2.5 kernel's pci.ids as:
0804 TC6371AF SmartMedia Controller
Docs at:
http://www.toshiba.com/taec/components/Datasheet/TC6371AF--020122E_R1.8.pdf
http://216.239.53.100/search?q=cache:www.toshiba.com/taec/components/Datasheet/TC6371AF--020122E_R1.8.pdf
Also, a post archvied at:
http://linux.toshiba-dme.co.jp/ML/tlinux-users/1700/1739.html
suggests someone had the TC6371AF's smart media support working on a
suse 7.2 box back in 2002/January, FWIW.
-JimC
^ permalink raw reply
* Re: [2.5.50, ACPI] link error
From: Pavel Machek @ 2002-12-16 11:16 UTC (permalink / raw)
To: Eric Altendorf; +Cc: Jochen Hein, Linux Kernel Mailing List
In-Reply-To: <200212151940.25024.EricAltendorf@orst.edu>
Hi!
> >
> > > > > Right ... I'm no kernel hacker so I don't know why, but I can
> > > > > only get the recent kernels to compile with sleep states if I
> > > > > turn *ON* software suspend as well. However, as soon as I
> > > > > turn on swsusp and get a compiled kernel, it oops'es on boot.
> > > >
> > > > Can you mail me decoded oops?
> > > > Pavel
> > >
> > > This is the first time I've decoded an oops, and since I had to
> > > decode it on a different kernel (2.5.25) than the one I'm
> > > debugging (2.5.50 + Dec 6 ACPI patch), and I couldn't
> >
> > Can you try passing
> > "resume=hda5_or_whatever_your_swap_partition_is"?
>
> Well, I've had "resume=/dev/hda6" in there the whole time (same as it
> was on prior kernels that booted). I tried passing "resume=hda6"
> instead just for kicks and got the same result, though... (This is
> still on the 2.5.50 + Dec6ACPI kernel)
Strange... Can you report if it is still broken with 2.5.51?
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
^ permalink raw reply
* Re: transparent squid & iptables
From: Arindam Haldar @ 2002-12-16 11:04 UTC (permalink / raw)
To: Abylai Ospan; +Cc: netfilter
In-Reply-To: <008201c2a420$487f82a0$8902010a@alkaloid>
iptables -A PREROUTING -t nat -p 6 --dport 80 -j REDIRECT --to-port 3128
Abylai Ospan wrote:
> Hello, All.
>
> We tried to make transparent squid on 127.0.0.1 and REDIRECT (or DNAT)
> in iptables but iptables redirect pakets to the received interface IP.
>
> In the iptables:
> iptables -t nat -A PREROUTING -p TCP --dport 80 -j REDIRECT 3128
>
> For example:
> packet from user (IP: 10.0.0.5) to <http://www.ru>www.ru
> <http://www.ru>:80 received on eth0 (IP: 10.0.0.1). Packet redirected to
> the 10.0.0.1:3128 but squid listen on 127.0.0.1:3128 so nothing work ;-(
>
> How we can redirect packet to the 127.0.0.1 port 3128 in iptables ?!
>
> wbr, Abylai
> NetUP Systems
> Moscow, Russia
^ permalink raw reply
* Re: Iptables Log - session Log
From: Roberto Nibali @ 2002-12-16 11:04 UTC (permalink / raw)
To: Jens Kühlberg; +Cc: netfilter
In-Reply-To: <10887.1039682956@www54.gmx.net>
> I looking for a tool, witch can analyse iptales logs and show me only
> connections-session in realtime and not the complete IP-traffic.
Define 'realtime' in the context of logging filtered traffic flows. I hear it
everywhere but people mostly seem to have a strange view about that, especially
when it comes to IDS.
I presume that you'd like to log:
o session start packet (entering conntrack table with its own timer)
o session end packet (lifetime defined through TSM of the conntrack core)
o session time (endlife packet time - packet entering time)
o session stats
- total amount of bytes per session
- total amount of packets per session
- whatever conntrack has to give us and is interesting ;)
If so, in the beginning of next year (probably February) I will release a new
target for netfilter called SLOG, which stands for session log. It was done
exactly for this purpose and because logging anything else then sessions in most
of the cases doesn't make too much sense (we have IDS doing that for example).
I need to rework and fix some issues of the initial work that has been done by
Roman Hoog Antink as a contract work for our company in conjunction with his
semester thesis at uni. An outstanding thing for example is the usage of
ctnetlink, which still seems to have quite a few rough edges.
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
^ permalink raw reply
* Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?
From: Wolfgang Denk @ 2002-12-16 9:56 UTC (permalink / raw)
To: David Woodhouse; +Cc: Paul Nash, Linux-MTD (E-mail)
In-Reply-To: <2466.1040031514@passion.cambridge.redhat.com>
In message <2466.1040031514@passion.cambridge.redhat.com> you wrote:
>
> Also true. Of course we have to distinguish between XIP of file system
> pages and of the kernel -- I was ignoring the latter because it's even less
> sane than the former. If you ever want to write to the chip, you have to
> disable all interrupts and wait while the chip is busy. For up to 20
> seconds, in the case of a slow erase.
Running the kernel XIP is not so insane. It can help to reduce boot
time. We still more than 3 seconds from power-on to application
start, which is not so bad, but still too much in some cases;
avoiding the memcpy() of some 2 MB of data is kind of attractive
then...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
"Just think of a computer as hardware you can program."
- Nigel de la Tierre
^ permalink raw reply
* Re: i4l dtmf errors
From: Roy Sigurd Karlsbakk @ 2002-12-16 11:07 UTC (permalink / raw)
To: Wolfgang Fritz, linux-kernel
In-Reply-To: <atg5jv$d73$1@fritz38552.news.dfncis.de>
> The DTMF detection is broken since kernel 2.0.x. I have a patch for a
> 2.2 kernel which may manually be applied 2.4 kernels with some manual
> work. It fixes an overflow problem in the goertzel algorithm (which
> does the basic tone detection) and changes the algorithm to detect the
> DTMF pairs. If interested, I can try to recover that patch.
I'm very interested, as the alternative is to rewrite Asterisk (dot org) to
use it's own. Today, I get beeps whenever I speak on the phone - espessialy
with my girlfriend ;-P
roy
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply
* [BENCHMARK]Unixbench result for kernel 2.5.52
From: Sowmya Adiga @ 2002-12-16 11:01 UTC (permalink / raw)
To: linux-kernel
Hi,
Here are the Unixbench result for kernel 2.5.52.
kernel 2.5.52 performed better in file copy operation,when compared with
kernel 2.5.51.
________________________________________________________________________
Test Machine details
---------------------
processor : 0(single processor)
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 10
cpu MHz : 868.275
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 : 1716.22
------------------------------------------------------------------------
kernel 2.5.51
------------------------------------------------------------------------
BYTE UNIX Benchmarks (Version 4.1.0)
System -- Linux access1 2.5.51 #3 Tue Dec 10 11:52:13 IST 2002 i686
unknown Start Benchmark Run: Tue Dec 10 13:23:54 IST 2002 1 interactive
users. 1:23pm up 1 min, 1 user, load average: 0.13, 0.08, 0.03
lrwxrwxrwx 1 root root 4 Oct 22 00:35 /bin/sh -> bash
/bin/sh: symbolic link to bash
/dev/hda2 8262068 2711284 5131088 35% /data
Dhrystone 2 using register variables 1753562.1
lps(10.0secs,10samples)
Double-Precision Whetstone 477.0 MWIPS(10.0 secs,10samples)
System Call Overhead 458680.5 lps(10.0
secs,10samples)
Pipe Throughput 452140.4 lps(10.0
secs,10samples)
Pipe-based Context Switching 224110.7 lps (10.0
secs,10samples)
Process Creation 4090.9 lps (30.0 secs,3samples)
Execl Throughput 956.9 lps (29.9 secs,3samples)
File Read 1024 bufsize 2000 maxblocks 244936.0 KBps(30.0
secs,3samples) File Write 1024 bufsize 2000 maxblocks 99665.0 KBps
(30.0 secs,3samples) File Copy 1024 bufsize 2000 maxblocks 67488.0
KBps (30.0 secs,3samples)
File Read 256 bufsize 500 maxblocks 114320.0KBps (30.0
secs,3samples)
File Write 256 bufsize 500 maxblocks 55900.0 KBps (30.0
secs,3samples)
File Copy 256 bufsize 500 maxblocks 33000.0 KBps (30.0
secs,3samples)
File Read 4096 bufsize 8000 maxblocks 336659.0 KBps(30.0
secs,3samples) File Write 4096 bufsize 8000 maxblocks 125510.0
KBps(30.0 secs,3samples) File Copy 4096 bufsize 8000 maxblocks 81771.0
KBps (30.0 secs,3samples)
Shell Scripts (1 concurrent) 867.7 lpm (60.0 secs,3samples)
Shell Scripts (8 concurrent) 113.0 lpm (60.0 secs,3samples)
Shell Scripts (16 concurrent) 57.0 lpm (60.0 secs,3samples)
Arithmetic Test (type = short) 208206.7 lps(10.0 secs,3samples)
Arithmetic Test (type = int) 225297.0 lps(10.0 secs,3samples)
Arithmetic Test (type = long) 225335.1 lps(10.0 secs,3samples)
Arithmetic Test (type = float) 227559.9 lps(10.0 secs,3samples)
Arithmetic Test (type = double) 227389.7 lps(10.0 secs,3samples)
Arithoh 3996200.7 lps(10.0secs,3samples)
C Compiler Throughput 409.7 lpm (60.0 secs,3samples)
Dc: sqrt(2) to 99 decimal places 34294.6 lpm (30.0 secs,3samples)
Recursion Test--Tower of Hanoi 29280.8 lps (20.0 secs,3samples)
INDEX VALUES
TEST BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 1753562.1 150.3
Double-Precision Whetstone 55.0 477.0 6.7
Execl Throughput 43.0 956.9 222.5
File Copy 1024 bufsize 2000 maxblocks 3960.0 67488.0 170.4
File Copy 256 bufsize 500 maxblocks 1655.0 33000.0 199.4
File Copy 4096 bufsize 8000 maxblocks 5800.0 81771.0 141.0
Pipe Throughput 12440.0 452140.4 363.5
Process Creation 126.0 4090.9 324.7
Shell Scripts (8 concurrent) 6.0 113.0 188.3
System Call Overhead 15000.0 458680.5 305.8
=========
FINAL SCORE 198.4
------------------------------------------------------------------------
kernel 2.5.52
------------------------------------------------------------------------
BYTE UNIX Benchmarks (Version 4.1.0)
System -- Linux access1 2.5.52 #4 Mon Dec 16 10:16:06 IST 2002 i686
unknown Start Benchmark Run: Mon Dec 16 11:30:24 IST 2002 1 interactive
users. 11:30am up 1:05, 1 user, load average: 0.07, 0.58, 0.79
lrwxrwxrwx 1 root root 4 Oct 22 00:35 /bin/sh -> bash
/bin/sh: symbolic link to bash
/dev/hda2 8262068 3454348 4388024 45% /data
Dhrystone 2 using register variables 1753628.8 lps(10.0
secs,10samples)
Double-Precision Whetstone 476.9 MWIPS (10.0 secs,10
samples)
System Call Overhead 450934.1 lps(10.0 secs10
samples)
Pipe Throughput 456612.8 lps(10.0 secs,10
samples)
Pipe-based Context Switching 225683.4 lps(10.0 secs,10
samples)
Process Creation 4275.6 lps (30.0 secs,3
samples)
Execl Throughput 909.8 lps (29.7 secs, 3
samples)
File Read 1024 bufsize 2000 maxblocks 244385.0 KBps(30.0
secs,3samples) File Write 1024 bufsize 2000 maxblocks 100577.0
KBps(30.0 secs,3samples)
File Copy 1024 bufsize 2000 maxblocks 70152.0 KBps(30.0
secs,3samples)
File Read 256 bufsize 500 maxblocks 111926.0 KBps(30.0
secs,3samples)
File Write 256 bufsize 500 maxblocks 56243.0 KBps (30.0
secs,3samples)
File Copy 256 bufsize 500 maxblocks 35585.0 KBps (30.0
secs,3samples)
File Read 4096 bufsize 8000 maxblocks 338086.0 KBps (30.0
secs,3samples)
File Write 4096 bufsize 8000 maxblocks 126577.0 KBps(30.0
secs,3samples)
File Copy 4096 bufsize 8000 maxblocks 89815.0 KBps (30.0
secs,3samples)
Shell Scripts (1 concurrent) 849.1 lpm (60.0 secs,3 samples)
Shell Scripts (8 concurrent) 111.0 lpm (60.0 secs, 3
samples)
Shell Scripts (16 concurrent) 56.0 lpm (60.0 secs, 3 samples)
Arithmetic Test (type = short) 208275.8 lps(10.0 secs,3
samples)
Arithmetic Test (type = int) 225111.9 lps(10.0 secs,3
samples)
Arithmetic Test (type = long) 225305.4 lps(10.0
secs,3samples)
Arithmetic Test (type = float) 227632.9 lps (10.0
secs,3samples)
Arithmetic Test (type = double) 227629.5 lps (10.0
secs,3samples)
Arithoh 3997619.3 lps(10.0
secs,3samples)
C Compiler Throughput 408.0 lpm (60.0 secs,3samples)
Dc: sqrt(2) to 99 decimal places 32839.0 lpm (30.0
secs,3samples)
Recursion Test--Tower of Hanoi 29277.5 lps (20.0 secs,
3samples)
INDEX VALUES
TEST BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 1753628.8 150.3
Double-Precision Whetstone 55.0 476.9 86.7
Execl Throughput 43.0 909.8 211.6
File Copy 1024 bufsize 2000 maxblocks 3960.0 70152.0 177.2
File Copy 256 bufsize 500 maxblocks 1655.0 35585.0 215.0
File Copy 4096 bufsize 8000 maxblocks 5800.0 89815.0 154.9
Pipe Throughput 12440.0 456612.8 367.1
Process Creation 126.0 4275.6 339.3
Shell Scripts (8 concurrent) 6.0 111.0 185.0
System Call Overhead 15000.0 450934.1 300.6
=========
FINAL SCORE 201.9
________________________________________________________________________
Regards
Sowmya Adiga
Project Engineer
Wipro Technologies
53/1,Hosur Road,Madivala
Bangalore-560 068,INDIA
Tel: +91-80-5502001 Extn.5086
sowmya.adiga@wipro.com
^ permalink raw reply
* [PATCH] kprobes for 2.5.52
From: Vamsi Krishna S . @ 2002-12-16 11:16 UTC (permalink / raw)
To: torvalds; +Cc: lkml, dprobes, rusty, tom, richard
Linus,
Here is the kprobes patch for 2.5.52.
This has incorporated all your feedback to unconditionally turn
trap1 and trap3 to ring3 interrupt gates and DaveM's (who wanted
the arch-indep bits for sparc).
kprobes allows trapping at almost any kernel address, useful for
various kernel-hacking tasks, and building on for more
infrastructure. This patch is x86 only, but other archs can add
support as required (s390 and ppc support is almost done, will be
submitted once this patch is in).
Rusty Lynch has built a sysfs-based module to use kprobes to
dynamically insert printks in running kernels. Other tools
that build on top of kprobes infrastructure, including
support for user space probes, are available/in development.
Please apply.
Thanks,
Vamsi.
[vamsi@vamsiks] ~$ diffstat /patches/kprobes-2552-1.patch
arch/i386/Kconfig | 9 ++
arch/i386/kernel/Makefile | 1
arch/i386/kernel/entry.S | 22 +++++-
arch/i386/kernel/kprobes.c | 160 +++++++++++++++++++++++++++++++++++++++++++++
arch/i386/kernel/traps.c | 36 ++++++++--
arch/i386/mm/fault.c | 4 +
include/asm-i386/kprobes.h | 34 +++++++++
include/linux/kprobes.h | 60 ++++++++++++++++
kernel/Makefile | 3
kernel/kprobes.c | 89 +++++++++++++++++++++++++
10 files changed, 406 insertions(+), 12 deletions(-)
--
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: vamsi@in.ibm.com
--
diff -urN -X /home/vamsi/.dontdiff 52-pure/arch/i386/Kconfig 52-kprobes/arch/i386/Kconfig
--- 52-pure/arch/i386/Kconfig 2002-12-13 18:04:57.000000000 +0530
+++ 52-kprobes/arch/i386/Kconfig 2002-12-13 18:19:02.000000000 +0530
@@ -1498,6 +1498,15 @@
Say Y here if you are developing drivers or trying to debug and
identify kernel problems.
+config KPROBES
+ bool "Kprobes"
+ depends on DEBUG_KERNEL
+ help
+ Kprobes allows you to trap at almost any kernel address, using
+ register_kprobe(), and providing a callback function. This is useful
+ for kernel debugging, non-intrusive instrumentation and testing. If
+ in doubt, say "N".
+
config DEBUG_STACKOVERFLOW
bool "Check for stack overflows"
depends on DEBUG_KERNEL
diff -urN -X /home/vamsi/.dontdiff 52-pure/arch/i386/kernel/entry.S 52-kprobes/arch/i386/kernel/entry.S
--- 52-pure/arch/i386/kernel/entry.S 2002-12-10 08:15:52.000000000 +0530
+++ 52-kprobes/arch/i386/kernel/entry.S 2002-12-13 18:19:02.000000000 +0530
@@ -403,9 +403,16 @@
jmp ret_from_exception
ENTRY(debug)
+ pushl $-1 # mark this as an int
+ SAVE_ALL
+ movl %esp,%edx
pushl $0
- pushl $do_debug
- jmp error_code
+ pushl %edx
+ call do_debug
+ addl $8,%esp
+ testl %eax,%eax
+ jnz restore_all
+ jmp ret_from_exception
ENTRY(nmi)
pushl %eax
@@ -418,9 +425,16 @@
RESTORE_ALL
ENTRY(int3)
+ pushl $-1 # mark this as an int
+ SAVE_ALL
+ movl %esp,%edx
pushl $0
- pushl $do_int3
- jmp error_code
+ pushl %edx
+ call do_int3
+ addl $8,%esp
+ testl %eax,%eax
+ jnz restore_all
+ jmp ret_from_exception
ENTRY(overflow)
pushl $0
diff -urN -X /home/vamsi/.dontdiff 52-pure/arch/i386/kernel/kprobes.c 52-kprobes/arch/i386/kernel/kprobes.c
--- 52-pure/arch/i386/kernel/kprobes.c 1970-01-01 05:30:00.000000000 +0530
+++ 52-kprobes/arch/i386/kernel/kprobes.c 2002-12-13 18:19:02.000000000 +0530
@@ -0,0 +1,160 @@
+/*
+ * Support for kernel probes.
+ * (C) 2002 Vamsi Krishna S <vamsi_krishna@in.ibm.com>.
+ */
+
+#include <linux/config.h>
+#include <linux/kprobes.h>
+#include <linux/ptrace.h>
+#include <linux/spinlock.h>
+#include <linux/preempt.h>
+
+/* kprobe_status settings */
+#define KPROBE_HIT_ACTIVE 0x00000001
+#define KPROBE_HIT_SS 0x00000002
+
+static struct kprobe *current_kprobe;
+static unsigned long kprobe_status, kprobe_old_eflags, kprobe_saved_eflags;
+
+/*
+ * returns non-zero if opcode modifies the interrupt flag.
+ */
+static inline int is_IF_modifier(u8 opcode)
+{
+ switch(opcode) {
+ case 0xfa: /* cli */
+ case 0xfb: /* sti */
+ case 0xcf: /* iret/iretd */
+ case 0x9d: /* popf/popfd */
+ return 1;
+ }
+ return 0;
+}
+
+static inline void disarm_kprobe(struct kprobe *p, struct pt_regs *regs)
+{
+ *p->addr = p->opcode;
+ regs->eip = (unsigned long)p->addr;
+}
+
+/*
+ * Interrupts are disabled on entry as trap3 is an interrupt gate and they
+ * remain disabled thorough out this function.
+ */
+int kprobe_handler(struct pt_regs *regs)
+{
+ struct kprobe *p;
+ int ret = 0;
+ u8 *addr = (u8 *)(regs->eip-1);
+
+ /* We're in an interrupt, but this is clear and BUG()-safe. */
+ preempt_disable();
+
+ /* Check we're not actually recursing */
+ if (kprobe_running()) {
+ /* We *are* holding lock here, so this is safe.
+ Disarm the probe we just hit, and ignore it. */
+ p = get_kprobe(addr);
+ if (p) {
+ disarm_kprobe(p, regs);
+ ret = 1;
+ }
+ /* If it's not ours, can't be delete race, (we hold lock). */
+ goto no_kprobe;
+ }
+
+ lock_kprobes();
+ p = get_kprobe(addr);
+ if (!p) {
+ unlock_kprobes();
+ /* Unregistered (on another cpu) after this hit? Ignore */
+ if (*addr != BREAKPOINT_INSTRUCTION)
+ ret = 1;
+ /* Not one of ours: let kernel handle it */
+ goto no_kprobe;
+ }
+
+ kprobe_status = KPROBE_HIT_ACTIVE;
+ current_kprobe = p;
+ kprobe_saved_eflags = kprobe_old_eflags
+ = (regs->eflags & (TF_MASK|IF_MASK));
+ if (is_IF_modifier(p->opcode))
+ kprobe_saved_eflags &= ~IF_MASK;
+
+ p->pre_handler(p, regs);
+
+ regs->eflags |= TF_MASK;
+ regs->eflags &= ~IF_MASK;
+
+ /* We hold lock, now we remove breakpoint and single step. */
+ disarm_kprobe(p, regs);
+ kprobe_status = KPROBE_HIT_SS;
+ return 1;
+
+no_kprobe:
+ preempt_enable_no_resched();
+ return ret;
+}
+
+static void rearm_kprobe(struct kprobe *p, struct pt_regs *regs)
+{
+ regs->eflags &= ~TF_MASK;
+ *p->addr = BREAKPOINT_INSTRUCTION;
+}
+
+/*
+ * Interrupts are disabled on entry as trap1 is an interrupt gate and they
+ * remain disabled thorough out this function. And we hold kprobe lock.
+ */
+int post_kprobe_handler(struct pt_regs *regs)
+{
+ if (!kprobe_running())
+ return 0;
+
+ if (current_kprobe->post_handler)
+ current_kprobe->post_handler(current_kprobe, regs, 0);
+
+ /*
+ * We singlestepped with interrupts disabled. So, the result on
+ * the stack would be incorrect for "pushfl" instruction.
+ * Note that regs->esp is actually the top of the stack when the
+ * trap occurs in kernel space.
+ */
+ if (current_kprobe->opcode == 0x9c) { /* pushfl */
+ regs->esp &= ~(TF_MASK | IF_MASK);
+ regs->esp |= kprobe_old_eflags;
+ }
+
+ rearm_kprobe(current_kprobe, regs);
+ regs->eflags |= kprobe_saved_eflags;
+
+ unlock_kprobes();
+ preempt_enable_no_resched();
+
+ /*
+ * if somebody else is singlestepping across a probe point, eflags
+ * will have TF set, in which case, continue the remaining processing
+ * of do_debug, as if this is not a probe hit.
+ */
+ if (regs->eflags & TF_MASK)
+ return 0;
+
+ return 1;
+}
+
+/* Interrupts disabled, kprobe_lock held. */
+int kprobe_fault_handler(struct pt_regs *regs, int trapnr)
+{
+ if (current_kprobe->fault_handler
+ && current_kprobe->fault_handler(current_kprobe, regs, trapnr))
+ return 1;
+
+ if (kprobe_status & KPROBE_HIT_SS) {
+ rearm_kprobe(current_kprobe, regs);
+ regs->eflags |= kprobe_old_eflags;
+
+ unlock_kprobes();
+ preempt_enable_no_resched();
+ }
+ return 0;
+}
diff -urN -X /home/vamsi/.dontdiff 52-pure/arch/i386/kernel/Makefile 52-kprobes/arch/i386/kernel/Makefile
--- 52-pure/arch/i386/kernel/Makefile 2002-12-13 18:04:57.000000000 +0530
+++ 52-kprobes/arch/i386/kernel/Makefile 2002-12-13 18:19:02.000000000 +0530
@@ -29,6 +29,7 @@
obj-$(CONFIG_PROFILING) += profile.o
obj-$(CONFIG_EDD) += edd.o
obj-$(CONFIG_MODULES) += module.o
+obj-$(CONFIG_KPROBES) += kprobes.o
EXTRA_AFLAGS := -traditional
diff -urN -X /home/vamsi/.dontdiff 52-pure/arch/i386/kernel/traps.c 52-kprobes/arch/i386/kernel/traps.c
--- 52-pure/arch/i386/kernel/traps.c 2002-12-10 08:15:44.000000000 +0530
+++ 52-kprobes/arch/i386/kernel/traps.c 2002-12-13 18:19:02.000000000 +0530
@@ -24,6 +24,7 @@
#include <linux/interrupt.h>
#include <linux/highmem.h>
#include <linux/kallsyms.h>
+#include <linux/kprobes.h>
#ifdef CONFIG_EISA
#include <linux/ioport.h>
@@ -404,7 +405,6 @@
}
DO_VM86_ERROR_INFO( 0, SIGFPE, "divide error", divide_error, FPE_INTDIV, regs->eip)
-DO_VM86_ERROR( 3, SIGTRAP, "int3", int3)
DO_VM86_ERROR( 4, SIGSEGV, "overflow", overflow)
DO_VM86_ERROR( 5, SIGSEGV, "bounds", bounds)
DO_ERROR_INFO( 6, SIGILL, "invalid operand", invalid_op, ILL_ILLOPN, regs->eip)
@@ -420,6 +420,9 @@
{
if (regs->eflags & VM_MASK)
goto gp_in_vm86;
+
+ if (kprobe_running() && kprobe_fault_handler(regs, 13))
+ return;
if (!(regs->xcs & 3))
goto gp_in_kernel;
@@ -551,6 +554,17 @@
nmi_callback = dummy_nmi_callback;
}
+asmlinkage int do_int3(struct pt_regs *regs, long error_code)
+{
+ if (kprobe_handler(regs))
+ return 1;
+ /* This is an interrupt gate, because kprobes wants interrupts
+ disabled. Normal trap handlers don't. */
+ restore_interrupts(regs);
+ do_trap(3, SIGTRAP, "int3", 1, regs, error_code, NULL);
+ return 0;
+}
+
/*
* Our handling of the processor debug registers is non-trivial.
* We do not clear them on entry and exit from the kernel. Therefore
@@ -573,7 +587,7 @@
* find every occurrence of the TF bit that could be saved away even
* by user code)
*/
-asmlinkage void do_debug(struct pt_regs * regs, long error_code)
+asmlinkage int do_debug(struct pt_regs * regs, long error_code)
{
unsigned int condition;
struct task_struct *tsk = current;
@@ -581,6 +595,12 @@
__asm__ __volatile__("movl %%db6,%0" : "=r" (condition));
+ if (post_kprobe_handler(regs))
+ return 1;
+
+ /* Interrupts not disabled for normal trap handling. */
+ restore_interrupts(regs);
+
/* Mask out spurious debug traps due to lazy DR7 setting */
if (condition & (DR_TRAP0|DR_TRAP1|DR_TRAP2|DR_TRAP3)) {
if (!tsk->thread.debugreg[7])
@@ -631,15 +651,15 @@
__asm__("movl %0,%%db7"
: /* no output */
: "r" (0));
- return;
+ return 0;
debug_vm86:
handle_vm86_trap((struct kernel_vm86_regs *) regs, error_code, 1);
- return;
+ return 0;
clear_TF:
regs->eflags &= ~TF_MASK;
- return;
+ return 0;
}
/*
@@ -803,6 +823,8 @@
struct task_struct *tsk = current;
clts(); /* Allow maths ops (or we recurse) */
+ if (kprobe_running() && kprobe_fault_handler(®s, 7))
+ return;
if (!tsk->used_math)
init_fpu(tsk);
restore_fpu(tsk);
@@ -896,9 +918,9 @@
#endif
set_trap_gate(0,÷_error);
- set_trap_gate(1,&debug);
+ _set_gate(idt_table+1,14,3,&debug); /* debug trap for kprobes */
set_intr_gate(2,&nmi);
- set_system_gate(3,&int3); /* int3-5 can be called from all */
+ _set_gate(idt_table+3,14,3,&int3); /* int3-5 can be called from all */
set_system_gate(4,&overflow);
set_system_gate(5,&bounds);
set_trap_gate(6,&invalid_op);
diff -urN -X /home/vamsi/.dontdiff 52-pure/arch/i386/mm/fault.c 52-kprobes/arch/i386/mm/fault.c
--- 52-pure/arch/i386/mm/fault.c 2002-12-13 18:04:57.000000000 +0530
+++ 52-kprobes/arch/i386/mm/fault.c 2002-12-13 18:19:02.000000000 +0530
@@ -19,6 +19,7 @@
#include <linux/init.h>
#include <linux/tty.h>
#include <linux/vt_kern.h> /* For unblank_screen() */
+#include <linux/kprobes.h>
#include <asm/system.h>
#include <asm/uaccess.h>
@@ -161,6 +162,9 @@
/* get the address */
__asm__("movl %%cr2,%0":"=r" (address));
+ if (kprobe_running() && kprobe_fault_handler(regs, 14))
+ return;
+
/* It's safe to allow irq's after cr2 has been saved */
if (regs->eflags & X86_EFLAGS_IF)
local_irq_enable();
diff -urN -X /home/vamsi/.dontdiff 52-pure/include/asm-i386/kprobes.h 52-kprobes/include/asm-i386/kprobes.h
--- 52-pure/include/asm-i386/kprobes.h 1970-01-01 05:30:00.000000000 +0530
+++ 52-kprobes/include/asm-i386/kprobes.h 2002-12-13 18:19:02.000000000 +0530
@@ -0,0 +1,34 @@
+#ifndef _ASM_KPROBES_H
+#define _ASM_KPROBES_H
+/*
+ * Dynamic Probes (kprobes) support
+ * Vamsi Krishna S <vamsi_krishna@in.ibm.com>, July, 2002
+ * Mailing list: dprobes@www-124.ibm.com
+ */
+#include <linux/types.h>
+#include <linux/ptrace.h>
+
+struct pt_regs;
+
+typedef u8 kprobe_opcode_t;
+#define BREAKPOINT_INSTRUCTION 0xcc
+
+/* trap3/1 are intr gates for kprobes. So, restore the status of IF,
+ * if necessary, before executing the original int3/1 (trap) handler.
+ */
+static inline void restore_interrupts(struct pt_regs *regs)
+{
+ if (regs->eflags & IF_MASK)
+ __asm__ __volatile__ ("sti");
+}
+
+#ifdef CONFIG_KPROBES
+extern int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
+extern int post_kprobe_handler(struct pt_regs *regs);
+extern int kprobe_handler(struct pt_regs *regs);
+#else /* !CONFIG_KPROBES */
+static inline int kprobe_fault_handler(struct pt_regs *regs, int trapnr) { return 0; }
+static inline int post_kprobe_handler(struct pt_regs *regs) { return 0; }
+static inline int kprobe_handler(struct pt_regs *regs) { return 0; }
+#endif
+#endif /* _ASM_KPROBES_H */
diff -urN -X /home/vamsi/.dontdiff 52-pure/include/linux/kprobes.h 52-kprobes/include/linux/kprobes.h
--- 52-pure/include/linux/kprobes.h 1970-01-01 05:30:00.000000000 +0530
+++ 52-kprobes/include/linux/kprobes.h 2002-12-13 18:19:02.000000000 +0530
@@ -0,0 +1,60 @@
+#ifndef _LINUX_KPROBES_H
+#define _LINUX_KPROBES_H
+#include <linux/config.h>
+#include <linux/list.h>
+#include <linux/notifier.h>
+#include <linux/smp.h>
+#include <asm/kprobes.h>
+
+struct kprobe;
+struct pt_regs;
+
+typedef void (*kprobe_pre_handler_t)(struct kprobe *, struct pt_regs *);
+typedef void (*kprobe_post_handler_t)(struct kprobe *, struct pt_regs *,
+ unsigned long flags);
+typedef int (*kprobe_fault_handler_t)(struct kprobe *, struct pt_regs *,
+ int trapnr);
+
+struct kprobe {
+ struct list_head list;
+
+ /* location of the probe point */
+ kprobe_opcode_t *addr;
+
+ /* Called before addr is executed. */
+ kprobe_pre_handler_t pre_handler;
+
+ /* Called after addr is executed, unless... */
+ kprobe_post_handler_t post_handler;
+
+ /* ... called if executing addr causes a fault (eg. page fault).
+ * Return 1 if it handled fault, otherwise kernel will see it. */
+ kprobe_fault_handler_t fault_handler;
+
+ /* Saved opcode (which has been replaced with breakpoint) */
+ kprobe_opcode_t opcode;
+};
+
+#ifdef CONFIG_KPROBES
+/* Locks kprobe: irq must be disabled */
+void lock_kprobes(void);
+void unlock_kprobes(void);
+
+/* kprobe running now on this CPU? */
+static inline int kprobe_running(void)
+{
+ extern unsigned int kprobe_cpu;
+ return kprobe_cpu == smp_processor_id();
+}
+
+/* Get the kprobe at this addr (if any). Must have called lock_kprobes */
+struct kprobe *get_kprobe(void *addr);
+
+int register_kprobe(struct kprobe *p);
+void unregister_kprobe(struct kprobe *p);
+#else
+static inline int kprobe_running(void) { return 0; }
+static inline int register_kprobe(struct kprobe *p) { return -ENOSYS; }
+static inline void unregister_kprobe(struct kprobe *p) { }
+#endif
+#endif /* _LINUX_KPROBES_H */
diff -urN -X /home/vamsi/.dontdiff 52-pure/kernel/kprobes.c 52-kprobes/kernel/kprobes.c
--- 52-pure/kernel/kprobes.c 1970-01-01 05:30:00.000000000 +0530
+++ 52-kprobes/kernel/kprobes.c 2002-12-13 18:19:02.000000000 +0530
@@ -0,0 +1,89 @@
+/* Support for kernel probes.
+ (C) 2002 Vamsi Krishna S <vamsi_krishna@in.ibm.com>.
+*/
+#include <linux/kprobes.h>
+#include <linux/spinlock.h>
+#include <linux/hash.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <asm/cacheflush.h>
+#include <asm/errno.h>
+
+#define KPROBE_HASH_BITS 6
+#define KPROBE_TABLE_SIZE (1 << KPROBE_HASH_BITS)
+
+static struct list_head kprobe_table[KPROBE_TABLE_SIZE];
+
+unsigned int kprobe_cpu = NR_CPUS;
+static spinlock_t kprobe_lock = SPIN_LOCK_UNLOCKED;
+
+/* Locks kprobe: irqs must be disabled */
+void lock_kprobes(void)
+{
+ spin_lock(&kprobe_lock);
+ kprobe_cpu = smp_processor_id();
+}
+
+void unlock_kprobes(void)
+{
+ kprobe_cpu = NR_CPUS;
+ spin_unlock(&kprobe_lock);
+}
+
+/* You have to be holding the kprobe_lock */
+struct kprobe *get_kprobe(void *addr)
+{
+ struct list_head *head, *tmp;
+
+ head = &kprobe_table[hash_ptr(addr, KPROBE_HASH_BITS)];
+ list_for_each(tmp, head) {
+ struct kprobe *p = list_entry(tmp, struct kprobe, list);
+ if (p->addr == addr)
+ return p;
+ }
+ return NULL;
+}
+
+int register_kprobe(struct kprobe *p)
+{
+ int ret = 0;
+
+ spin_lock_irq(&kprobe_lock);
+ if (get_kprobe(p->addr)) {
+ ret = -EEXIST;
+ goto out;
+ }
+ list_add(&p->list, &kprobe_table[hash_ptr(p->addr, KPROBE_HASH_BITS)]);
+
+ p->opcode = *p->addr;
+ *p->addr = BREAKPOINT_INSTRUCTION;
+ flush_icache_range(p->addr, p->addr + sizeof(kprobe_opcode_t));
+ out:
+ spin_unlock_irq(&kprobe_lock);
+ return ret;
+}
+
+void unregister_kprobe(struct kprobe *p)
+{
+ spin_lock_irq(&kprobe_lock);
+ *p->addr = p->opcode;
+ list_del(&p->list);
+ flush_icache_range(p->addr, p->addr + sizeof(kprobe_opcode_t));
+ spin_unlock_irq(&kprobe_lock);
+}
+
+static int __init init_kprobes(void)
+{
+ int i;
+
+ /* FIXME allocate the probe table, currently defined statically */
+ /* initialize all list heads */
+ for (i = 0; i < KPROBE_TABLE_SIZE; i++)
+ INIT_LIST_HEAD(&kprobe_table[i]);
+
+ return 0;
+}
+__initcall(init_kprobes);
+
+EXPORT_SYMBOL_GPL(register_kprobe);
+EXPORT_SYMBOL_GPL(unregister_kprobe);
diff -urN -X /home/vamsi/.dontdiff 52-pure/kernel/Makefile 52-kprobes/kernel/Makefile
--- 52-pure/kernel/Makefile 2002-12-13 18:05:07.000000000 +0530
+++ 52-kprobes/kernel/Makefile 2002-12-13 18:19:40.000000000 +0530
@@ -10,7 +10,7 @@
exit.o itimer.o time.o softirq.o resource.o \
sysctl.o capability.o ptrace.o timer.o user.o \
signal.o sys.o kmod.o workqueue.o futex.o platform.o pid.o \
- rcupdate.o intermodule.o extable.o params.o
+ rcupdate.o intermodule.o extable.o params.o kprobes.o
obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o
obj-$(CONFIG_SMP) += cpu.o
@@ -22,6 +22,7 @@
obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
obj-$(CONFIG_SOFTWARE_SUSPEND) += suspend.o
obj-$(CONFIG_COMPAT) += compat.o
+obj-$(CONFIG_KPROBES) += kprobes.o
ifneq ($(CONFIG_IA64),y)
# According to Alan Modra <alan@linuxcare.com.au>, the -fno-omit-frame-pointer is
^ permalink raw reply
* [TRIVIAL] aic7xxx_Makefile fix
From: Rusty Trivial Russell @ 2002-12-16 10:52 UTC (permalink / raw)
To: Kai Germaschewski, linux-scsi
From: junio@siamese.dyndns.org
Patch against 2.4.19. If you are in a (good) habit of making
all the upstream sources read-only before starting your build,
generation of the firmware code fails because it tries to write
into read-only files. This bites only in configurations where
CONFIG_AIC7XXX_BUILD_FIRMWARE is set to 'y'.
--- trivial-2.4.21-pre1/drivers/scsi/aic7xxx/Makefile.orig 2002-12-16 17:22:40.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/scsi/aic7xxx/Makefile 2002-12-16 17:22:40.000000000 +1100
@@ -39,6 +39,7 @@
$(obj-aic7xxx): aic7xxx_reg.h
aic7xxx_seq.h aic7xxx_reg.h: aic7xxx.seq aic7xxx.reg aicasm/aicasm
+ rm -f aic7xxx_seq.h aic7xxx_reg.h
aicasm/aicasm -I. -r aic7xxx_reg.h -o aic7xxx_seq.h aic7xxx.seq
endif
--
Don't blame me: the Monkey is driving
File: junio@siamese.dyndns.org: [TRIVIAL] aic7xxx_Makefile fix
^ permalink raw reply
* ISA DMA troubles
From: Philippe Villet @ 2002-12-16 10:52 UTC (permalink / raw)
To: linuxppc-embedded
We are using a custom board based on a 405GP processor with a PIIX4
Southbridge (providing a PCI to ISA bridge, a DMA controller, an interrupt
controller, ...)
A FDC37C78 floppy disk controller is connected to the ISA bus, use a DMA
and an interrupt line of the southbridge.
Kernel version is 2.4.17 (Monta vista HHL 2.1) -
When we perform WRITE operations to the floppy, dma data sent to the floppy
controller are corrupted.
I try some debug and i saw that when a corrupted data is sent, it was a
data from the previous dma transfer from the same address.
When i dump the memory (with BDI2000) at the end of the transfert,
everything is OK.
Does someone met this problem ? A cache pb ?
How can i go further to debug ?
READ operations seems OK.
Thanks for your help .
Philippe
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [TRIVIAL] 16) request_region check, 11-20
From: Rusty Trivial Russell @ 2002-12-16 10:49 UTC (permalink / raw)
To: linux-scsi, rmk
(Included in 2.5)
From: johnpol@2ka.mipt.ru
here is one more trivial check.
So please test and apply.
Evgeniy Polyakov ( s0mbre )
--- trivial-2.4.21-pre1/drivers/acorn/scsi/oak.c.orig 2002-12-16 17:22:38.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/acorn/scsi/oak.c 2002-12-16 17:22:38.000000000 +1100
@@ -134,7 +134,8 @@
ecard_claim(ecs[count]);
instance->n_io_port = 255;
- request_region (instance->io_port, instance->n_io_port, "Oak SCSI");
+ if (!request_region (instance->io_port, instance->n_io_port, "Oak SCSI"))
+ break;
if (instance->irq != IRQ_NONE)
if (request_irq(instance->irq, do_oakscsi_intr, SA_INTERRUPT, "Oak SCSI", NULL)) {
--
Don't blame me: the Monkey is driving
File: johnpol@2ka.mipt.ru: 16) request_region check, 11-20
^ permalink raw reply
* [TRIVIAL] 15) request_region check, 11-20
From: Rusty Trivial Russell @ 2002-12-16 10:49 UTC (permalink / raw)
To: linux-scsi, rmk
(Included in 2.5)
From: johnpol@2ka.mipt.ru
here is one more trivial check.
So please test and apply.
Evgeniy Polyakov ( s0mbre )
--- trivial-2.4.21-pre1/drivers/acorn/scsi/cumana_2.c.orig 2002-12-16 17:22:38.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/acorn/scsi/cumana_2.c 2002-12-16 17:22:38.000000000 +1100
@@ -382,8 +382,13 @@
ecs[count]->irq_data = (void *)info->alatch;
ecs[count]->ops = (expansioncard_ops_t *)&cumanascsi_2_ops;
- request_region(host->io_port + CUMANASCSI2_FAS216_OFFSET,
- 16 << CUMANASCSI2_FAS216_SHIFT, "cumanascsi2-fas");
+ if (!request_region(host->io_port + CUMANASCSI2_FAS216_OFFSET,
+ 16 << CUMANASCSI2_FAS216_SHIFT, "cumanascsi2-fas")) {
+ scsi_unregister(host);
+ ecard_release(ecs[count]);
+ break;
+ }
+
if (host->irq != NO_IRQ &&
request_irq(host->irq, cumanascsi_2_intr,
--
Don't blame me: the Monkey is driving
File: johnpol@2ka.mipt.ru: 15) request_region check, 11-20
^ permalink raw reply
* Re: Loding rules
From: Roberto Nibali @ 2002-12-16 10:47 UTC (permalink / raw)
To: nedco; +Cc: netfilter
In-Reply-To: <3df77ff9.7a14.0@unacs.bg>
> Hi,
> How to load fast about 20000 rules in iptables.
> If some document will be help , please let me know :)
Netfilter is not designed for that. Please use the nf-hipac[1] drop-in
replacement. NF-hipac will do the filtering and rule organisation for you and
for the rest (NAT, mangle) you can still use netfilter. Also you should check if
you can't logically draw a binary tree with your rules which would then result
in faster matching lookup (at least with netfilter).
And no: iptables-save/restore is _not_ an option for dynamically changing rules!
If you have that many rules you certainly have a logic or kind of a matrix
behind that. Try to use some algebraic transformations (linear translation,
Laplace (define network flows), Gauss, TSP, ...) to optimize the ruleset. I have
done this and successfully reduced the number of rules.
[1] http://www.hipac.org
Regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
^ permalink raw reply
* Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?
From: Wolfgang Denk @ 2002-12-16 11:16 UTC (permalink / raw)
To: Michal Schulz; +Cc: David Woodhouse, Paul Nash, Linux-MTD (E-mail)
In-Reply-To: <Pine.GSO.4.44.0212161155540.15280-100000@rose.man.poznan.pl>
In message <Pine.GSO.4.44.0212161155540.15280-100000@rose.man.poznan.pl> you wrote:
>
> With the XIP in kernel it is relatively simple with 2.2.x serie of
> kernels. I have managed to put most of 2.2.18 kernel onto flash, where it
We also tested this with 2.4.4 on PowerPC.
> was executing from. The most problems are with .rodata section, which is
> not read-only for kernel. It is so because some structures (one passed to
With recent kernels, at least on PPC, there are also places where the
.text segment is written into. Some people even find "binary
patching" a cool idea.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
FORTRAN? The syntactically incorrect statement "DO 10 I = 1.10" will
parse and generate code creating a variable, DO10I, as follows:
"DO10I = 1.10" If that doesn't terrify you, it should.
^ permalink raw reply
* [BUG] module-init-tools 0.9.3, rmmod modules with '-'
From: Vamsi Krishna S . @ 2002-12-16 11:06 UTC (permalink / raw)
To: rusty; +Cc: lkml
Hi Rusty,
It seems we cannot unload modules if they have a '-' in their name.
filename2modname() in rmmod.c converts a '-' in the filename
to '_'. Why? Are dashes not allowed as part of module names?
For eg: (kernel 2.5.52/module-init-tools 0.9.3)
[root@llm10 test-modules]# ./insmod probe-test.o
[root@llm10 test-modules]# ./lsmod
Module Size Used by
probe-test 943 0
[root@llm10 test-modules]# cat /proc/modules
probe-test 943 0
[root@llm10 test-modules]# ./rmmod -V
module-init-tools version 0.9.3
[root@llm10 test-modules]# ./rmmod probe-test
ERROR: Module probe_test does not exist in /proc/modules
^note this
Editing filename2modname() to remove this special test for
'-' seems to fix it. But, this is done explicitly, so
I wonder if there is a deeper meaning to this. Can you
please take a look and explain?
Thanks,
Vamsi.
--
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: vamsi@in.ibm.com
--
--- rmmod-old.c 2002-12-13 21:11:57.000000000 +0530
+++ rmmod.c 2002-12-13 21:10:44.000000000 +0530
@@ -157,9 +157,12 @@
else
afterslash++;
- /* stop at first . */
+ /* Convert to underscores, stop at first . */
for (i = 0; afterslash[i] && afterslash[i] != '.'; i++) {
- modname[i] = afterslash[i];
+ if (afterslash[i] == '-')
+ modname[i] = '_';
+ else
+ modname[i] = afterslash[i];
}
modname[i] = '\0';
}
^ permalink raw reply
* Re: [LARTC] total bandwidth ocupied
From: Stef Coene @ 2002-12-16 10:41 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104000531807331@msgid-missing>
On Monday 16 December 2002 03:25, Adi Nugroho wrote:
> Dear sir/madam,
>
> I discover that bandwidth usage which is limited using htb is about 5 to
> 10% higher than the rate/ceil we set, if we monitor it using iptraf.
>
> I become more confused since I saw, the grafic in HTB homepage are also
> show more bandwidth than the setting.
>
> My question is:
> * what is the exac value of this over bandwidth?
> * how to make the bandwidth are limited exacly at "x" kbps?
I did some "stream" tests with htb. I generated a lot of tcp traffic with tcp
and recorded the shaped bandwidth. The result is allmost perfect. (results
can be found on www.docum.org on the test pages).
But in a real world scenario, you also have bursts in the traffic. Maybe you
allow bursts (you always have some minimal bursts) so the average bandwidth
may be higher then the configured bandwith.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [TRIVIAL] [Trivial Patch] scsi_register-008
From: Rusty Trivial Russell @ 2002-12-16 10:39 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Achim Leubner, linux-scsi
(Included in 2.5)
From: Michael Still <mikal@stillhq.com>
This patch has been generated as part of my scsi_register audit of the 2.5.45 kernel tree. scsi_register() can fail, returning a NULL pointer, and the failure case was not being handled here...
--- trivial-2.4.21-pre1/drivers/scsi/gdth.c.orig 2002-12-16 17:22:29.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/scsi/gdth.c 2002-12-16 17:22:29.000000000 +1100
@@ -4253,6 +4253,9 @@
if (gdth_ctr_count >= MAXHA)
break;
shp = scsi_register(shtp,sizeof(gdth_ext_str));
+ if(shp == NULL)
+ continue;
+
ha = HADATA(shp);
if (!gdth_init_pci(&pcistr[ctr],ha)) {
scsi_unregister(shp);
--
Don't blame me: the Monkey is driving
File: Michael Still <mikal@stillhq.com>: [Trivial Patch] scsi_register-008
^ permalink raw reply
* [TRIVIAL] [Trivial Patch] scsi_register-006
From: Rusty Trivial Russell @ 2002-12-16 10:39 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Achim Leubner, linux-scsi
(Included in 2.5)
From: Michael Still <mikal@stillhq.com>
This patch has been generated as part of my scsi_register audit of the 2.5.45 kernel tree. scsi_register() can fail, returning a NULL pointer, and the failure case was not being handled here...
--- trivial-2.4.21-pre1/drivers/scsi/gdth.c.orig 2002-12-16 17:22:29.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/scsi/gdth.c 2002-12-16 17:22:29.000000000 +1100
@@ -4143,6 +4143,9 @@
break;
if (gdth_search_eisa(eisa_slot)) { /* controller found */
shp = scsi_register(shtp,sizeof(gdth_ext_str));
+ if(shp == NULL)
+ continue;
+
ha = HADATA(shp);
if (!gdth_init_eisa(eisa_slot,ha)) {
scsi_unregister(shp);
--
Don't blame me: the Monkey is driving
File: Michael Still <mikal@stillhq.com>: [Trivial Patch] scsi_register-006
^ permalink raw reply
* [TRIVIAL] [Trivial Patch] scsi_register-004
From: Rusty Trivial Russell @ 2002-12-16 10:39 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Achim Leubner, linux-scsi
(Included in 2.5)
From: Michael Still <mikal@stillhq.com>
This patch has been generated as part of my scsi_register audit of the 2.5.45 kernel tree. scsi_register() can fail, returning a NULL pointer, and the failure case was not being handled here...
--- trivial-2.4.21-pre1/drivers/scsi/gdth.c.orig 2002-12-16 17:22:28.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/scsi/gdth.c 2002-12-16 17:22:28.000000000 +1100
@@ -4029,6 +4029,9 @@
break;
if (gdth_search_isa(isa_bios)) { /* controller found */
shp = scsi_register(shtp,sizeof(gdth_ext_str));
+ if(shp == NULL)
+ continue;
+
ha = HADATA(shp);
if (!gdth_init_isa(isa_bios,ha)) {
scsi_unregister(shp);
--
Don't blame me: the Monkey is driving
File: Michael Still <mikal@stillhq.com>: [Trivial Patch] scsi_register-004
^ permalink raw reply
* [TRIVIAL] [Trivial Patch] scsi_register-002
From: Rusty Trivial Russell @ 2002-12-16 10:39 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-scsi
(Included in 2.5)
From: Michael Still <mikal@stillhq.com>
This patch has been generated as part of my scsi_register audit of the 2.5.45 kernel tree. scsi_register() can fail, returning a NULL pointer, and the failure case was not being handled here...
--- trivial-2.4.21-pre1/drivers/scsi/aacraid/linit.c.orig 2002-12-16 17:22:28.000000000 +1100
+++ trivial-2.4.21-pre1/drivers/scsi/aacraid/linit.c 2002-12-16 17:22:28.000000000 +1100
@@ -203,6 +203,9 @@
* specific information.
*/
host_ptr = scsi_register( template, sizeof(struct aac_dev) );
+ if(host_ptr == NULL)
+ continue;
+
/*
* These three parameters can be used to allow for wide SCSI
* and for host adapters that support multiple buses.
--
Don't blame me: the Monkey is driving
File: Michael Still <mikal@stillhq.com>: [Trivial Patch] scsi_register-002
^ permalink raw reply
* Re: aix7xxx_old woes in 2.5
From: Andrew Morton @ 2002-12-16 10:39 UTC (permalink / raw)
To: Doug Ledford; +Cc: linux-scsi
In-Reply-To: <20021216074008.GC13989@redhat.com>
Doug Ledford wrote:
>
> On Sat, Dec 14, 2002 at 08:36:25PM -0800, Andrew Morton wrote:
> >
> > ho hum.
> >
> > It just doesn't start at all:
> >
> > scsi HBA driver <NULL> didn't set max_sectors, please fix the template<6>(scsi0) <Adaptec AIC-7892 Ultra 160/m SCSI host adapter> found at PCI 3/4/0
> > (scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
> > (scsi0) Downloading sequencer code... 396 instructions downloaded
> > (scsi1) <Adaptec AIC-7880 Ultra SCSI host adapter> found at PCI 0/10/0
> > (scsi1) Wide Channel, SCSI ID=7, 16/255 SCBs
> > (scsi1) Downloading sequencer code... 436 instructions downloaded
> > scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.6/5.2.0
> > <Adaptec AIC-7892 Ultra 160/m SCSI host adapter>
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 0 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 1 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 2 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 3 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 4 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 5 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 6 lun 0
> > scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 8 lun 0
> >
> > (The above took three minutes or more)
>
> Interrupt routing problems is what that looks like to me, not driver
> problems. Try booting with different interrupt settings or with a
> different kernel (smp vs. up, that sort of thing).
Uniprocessor, no IO-APIC. No go:
CPU0
0: 736412 XT-PIC timer
1: 15 XT-PIC i8042
2: 0 XT-PIC cascade
4: 0 XT-PIC GDB-stub
8: 1 XT-PIC rtc
11: 294 XT-PIC ide2, ide3, ide4, ide5, aic7xxx, aic7xxx, eth0
12: 52 XT-PIC i8042
14: 2848 XT-PIC ide0
15: 8 XT-PIC ide1
NMI: 0
ERR: 0
(Doesn't this rule out your theory? If it's asserting the IRQ, we will
take an interrupt with this configuration?)
Uniprocessor, IO-APIC:
CPU0
0: 654721 IO-APIC-edge timer
1: 15 IO-APIC-edge i8042
2: 0 XT-PIC cascade
4: 0 IO-APIC-edge GDB-stub
8: 1 IO-APIC-edge rtc
12: 55 IO-APIC-edge i8042
14: 2835 IO-APIC-edge ide0
15: 10 IO-APIC-edge ide1
19: 43 IO-APIC-level ide2, ide3, ide4, ide5
35: 0 IO-APIC-level aic7xxx
38: 296 IO-APIC-level eth0
58: 137 IO-APIC-level aic7xxx
NMI: 668
LOC: 654631
ERR: 0
MIS: 0
I assume SMP/IO-APIC will do the same thing (takes too darn long
to go through them all).
Why should aic7xxx_old have this problem, and not aic7xxx?
Here's /proc/interrupts with aic7xxx, uniproc, IO-APIC:
CPU0
0: 38650 IO-APIC-edge timer
1: 16 IO-APIC-edge i8042
2: 0 XT-PIC cascade
4: 0 IO-APIC-edge GDB-stub
8: 1 IO-APIC-edge rtc
12: 55 IO-APIC-edge i8042
14: 2726 IO-APIC-edge ide0
15: 10 IO-APIC-edge ide1
19: 43 IO-APIC-level ide2, ide3, ide4, ide5
35: 391 IO-APIC-level aic7xxx
38: 115 IO-APIC-level eth0
58: 284 IO-APIC-level aic7xxx
NMI: 48
LOC: 38516
ERR: 0
MIS: 0
Just the same, only this time it's generating interrupts.
I don't think this is a mainboard problem.
The logs say:
scsi HBA driver <NULL> didn't set max_sectors, please fix the template
(scsi0) <Adaptec AIC-7892 Ultra 160/m SCSI host adapter> found at PCI 3/4/0
(scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 396 instructions downloaded
(scsi1) <Adaptec AIC-7880 Ultra SCSI host adapter> found at PCI 0/10/0
(scsi1) Wide Channel, SCSI ID=7, 16/255 SCBs
(scsi1) Downloading sequencer code... 436 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.6/5.2.0
<Adaptec AIC-7892 Ultra 160/m SCSI host adapter>
scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 0 lun 0
scsi: Device offlined - not ready or command retry failed after error recovery: host 0 channel 0 id 1 lun 0
Maybe the 7892 sequencer code is bust??
^ permalink raw reply
* Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?
From: Michal Schulz @ 2002-12-16 11:04 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: David Woodhouse, Paul Nash, Linux-MTD (E-mail)
In-Reply-To: <20021216092801.80539C6139@atlas.denx.de>
On Mon, 16 Dec 2002, Wolfgang Denk wrote:
> > With the chips available today and in the near future, XIP, at least for a
> > writable flash chip, makes virtually zero sense on Linux. Anyone who tries
> > to tell you otherwise is either on crack, trying to sell you something, or
> > both.
>
> Also you might find problems running recent (and future) kernels in
> XIP mode - the kernel text segment is often not exactly read-only.
> Especially when you use one f the existing real-time extensions (but
> not only then). It seems the amount of tweaking that is necessary for
> XIP is growing with each new kernel release - to a level where it
> becomes impractical.
With the XIP in kernel it is relatively simple with 2.2.x serie of
kernels. I have managed to put most of 2.2.18 kernel onto flash, where it
was executing from. The most problems are with .rodata section, which is
not read-only for kernel. It is so because some structures (one passed to
procfs for example) are created dynamically during function call, so they
can be later found in .rodata section.
After some play with arch/i386/vmlinux.lds.S it is possible to divide the
kernel into two parts. One is really read-only one and may reside anywhere
in memory (so for example in rom or in Flash) and the other one must be
copied from rom/flash into ram.
with XIP and runable applications, it makes sence when one operates with
2.5MB of real RAM or less. but it doesn't save too much because tons of
data are in writable sections. It is possible to fix romfs driver and
implement XIP there.
Please also note, that many flash memories are unreadable during write
cycles, so it makes no sence to execute linux kernel from them and using
some parts as a writable fs, because it causes immediate lock.
--
Michal Schulz
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.