* Re: modprobe: Can't locate module personality-8
From: Stephan van Hienen @ 2002-12-16 12:01 UTC (permalink / raw)
To: linux-kernel; +Cc: sparclinux
In-Reply-To: <Pine.LNX.4.50.0212121031450.23699-100000@ddx.a2000.nu>
On Thu, 12 Dec 2002, Stephan van Hienen wrote:
> Dec 8 18:59:46 ddx modprobe: modprobe: Can't locate module personality-8
> Dec 8 18:59:46 ddx modprobe: modprobe: Can't locate module personality-8
> ..
> Dec 8 19:16:15 ddx modprobe: modprobe: Can't locate module personality-8
> Dec 8 19:16:55 ddx last message repeated 6 times
> Dec 8 19:17:06 ddx last message repeated 3 times
> ..
> Dec 11 10:06:12 ddx modprobe: modprobe: Can't locate module personality-8
> Dec 11 10:06:12 ddx modprobe: modprobe: Can't locate module personality-8
>
>
> Did i forget to compile something in the kernel ?
> (2.4.20 on sun ultrasparc)
> -
yesterday again :
Dec 14 03:46:30 ddx modprobe: modprobe: Can't locate module personality-8
Dec 14 03:47:11 ddx last message repeated 2 times
Dec 14 03:47:11 ddx modprobe: modprobe: Can't locate module personality-8
and now also 2 'new' errors :
Dec 14 03:54:18 ddx modprobe: modprobe: Can't locate module block-major-8
Dec 14 03:54:28 ddx modprobe: modprobe: Can't locate module block-major-8
Dec 14 03:55:32 ddx kernel: hdc:
Dec 14 03:55:34 ddx kernel: hdc:
(i think i runned fdisk at this time on /dec/hdc)
I don't have any modules compiled (all drivers inside kernel)
and i don't have /etc/modules.conf (someone told me that personality-8
could be an alias inside this config)
Can someone explain these 'errors' ?
^ permalink raw reply
* Re: [PATCH] remove error message on illegal ioctl
From: Jens Axboe @ 2002-12-16 11:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Robert Love, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212160138480.1317-100000@home.transmeta.com>
On Mon, Dec 16 2002, Linus Torvalds wrote:
>
>
> On Mon, 16 Dec 2002, Jens Axboe wrote:
> >
> > Your non-root user still has to be able to open the cdrom.
>
> Why not just make this all use the "quiet" flag, and make the ioctl's
> always set it. That's what it's there for.
Yes that would be fine. I just don't want uniform packets to be silently
dropped, that makes debugging a problem with a drive pretty much
impossible.
--
Jens Axboe
^ permalink raw reply
* Re: Ali5451 problem with mixer
From: Takashi Iwai @ 2002-12-16 11:46 UTC (permalink / raw)
To: Rafal Dejewski; +Cc: alsa-devel
In-Reply-To: <200212141304.40416.lardel@interia.pl>
At Sat, 14 Dec 2002 13:04:40 +0100,
Rafal Dejewski wrote:
>
> Hi,
> I have a problem with alsa mixer on kernel 2.5.51 and alsa-lib, alsa-utils
> 0.6rc6. Whenerver I try to run alsamixer the following message appers in
> console and alsamixer would not start:
> $ alsamixer
> ALSA lib simple.c:944:(simple_add1) helem (MIXER,'IEC958 Playback
> Switch',0,0,0) appears twice or more
could you try the latest cvs version? perhaps this is because of the
name confliction between the internal switch and ac97-codec's switch.
if my guess is correct, it should have been fixed now.
Takashi
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* [LARTC] compress data, ipsec & iproute !!
From: Arindam Haldar @ 2002-12-16 11:41 UTC (permalink / raw)
To: lartc
Hi all.
Is it possible to use ipsec and also compress data from one linux box to
another via a WAN link ?.. if yes how can i compress such data ??..by
data i mean network traffic(internet) !!
the corresponding linux box uses iproute & is linked with 2 isp.
the idea behind is to use a maximum of the available pipe which is 2mb
but with needs, has grown out...
can u suggest how to do it or some site for reference for the same ...
thanking in advance...
A.H
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Telnetd:All network ports in use:
From: rekha gvv @ 2002-12-16 11:40 UTC (permalink / raw)
To: linuxppc-embedded
Hi Everybody,
Now that Applications have started running on mpc860 I
am trying to run telnetd application.But i get the
error
" All network ports in use "
I have got the following files
/etc/inetd.conf
telnet stream tcp nowait root /bin/telnetd telnetd
-L/bin/sh
/etc/protocols ,/etc/services ..
Is there any other configuration that has to be made
i have got inetd in /bin/inetd .
Thanks
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: small buglet in iptables-save with "-m mac"
From: Michael Schwendt @ 2002-12-16 11:40 UTC (permalink / raw)
To: Roland Kuhn; +Cc: netfilter-devel
In-Reply-To: <Pine.LNX.4.44.0212101518580.1838-100000@pc40.e18.physik.tu-muenchen.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 10 Dec 2002 15:26:30 +0100 (CET), Roland Kuhn wrote:
> Please Cc: me as I'm not on the list.
>
> This small buglet is biting me since quite a while, so I got the
> 1.2.7a source to see if it is fixed, and it isn't: if you try
> iptables-save on a rule with inverted MAC matching (e.g. "-m mac
> --mac-source ! xx:xx:xx:xx:xx:xx") you'll end up with "-m mac --mac
> !xx:xx:xx:xx:xx:xx", which doesn't work because of the missing space
> between the ! and the MAC. The patch below should fix it (tested on
> RH7.2, kernel 2.4.20).
This has been fixed several weeks ago in CVS.
Sometime later I've submitted a patch which cleans up libipt_mac.c
so the space is only printed for iptables-save and not for iptables
- -L (other userspace extension do it similarly with readability in
mind).
Michael
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
iD8DBQE9/bug0iMVcrivHFQRArKwAJ4jFlBLTGhhFzcPR4Z7aiEMtaOhIACfQt7U
rFm3uUrJdvmKrGF1l4nJSt0=
=GSMW
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Iptables - disable statefull inspection?
From: Patrick Schaaf @ 2002-12-16 11:23 UTC (permalink / raw)
To: Jan Kaastrup; +Cc: netfilter-devel
In-Reply-To: <000001c2a1cf$55f818a0$2864a8c0@pcjka>
> I want to disable the connections in ip_conntrack, because it completely
> kills the CPU because ip_conntrack reach Maximum connection.
That's simple: answer 'N' to the relevant kernel questions, then build and
boot that kernel. Without ip_conntrack compiled, it will certainly not
interfere with your testing.
If you already did build ip_conntrack as a module, remove the ip_conntrack.o
file under /lib/modules/`uname -r`, and reboot. The system will then not
be able to load ip_conntrack, and consequently fail loading of all components
which rely on ip_conntrack's presence (nat table, state match).
Easy, isn't it? The hard part comes when you want to load-test some
component (like NAT) which does require ip_conntrack...
best regards
Patrick
^ permalink raw reply
* Re: Intel sez: Synchronous Flash and XIP is the future -- thoughts?
From: David Woodhouse @ 2002-12-16 11:45 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Paul Nash, Linux-MTD (E-mail)
In-Reply-To: <20021216095652.D4D24C6139@atlas.denx.de>
wd@denx.de said:
> 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...
That's true, although even if you have the kernel on a separate flash chip
to which you don't ever write, it does cost you later because you then run
from flash which is slower than RAM. I wonder if we could copy the kernel
from flash to RAM at runtime and fix up the page tables as we go, to get the
best of both worlds?
--
dwmw2
^ permalink raw reply
* [U-Boot-Users] Automatic boot of Linux from flash (Big ppcboot image the sequel)
From: Wolfgang Denk @ 2002-12-16 11:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <81A66F72DCACD511B0600002A551BFCB4E9CE6@kuumex05.barco.com>
Hi,
in message <81A66F72DCACD511B0600002A551BFCB4E9CE6@kuumex05.barco.com> you wrote:
>
> I tried another approach to boot directly Linux ,from flash from an image
> loaded in flash in one block.
What do you mean with "in one block"? One erase unit? One image file?
Or what?
> Instead of compiling ppcboot with an image of the linux kernel in a big
> array ( makes linking problem)
It makes only linking problems if you fail to adjust the linker
script; if you check for example how the Linux bootstrap loader
embeds theLinux kernel and the ramdisk image as separate sections
into a binary image you should get an idea how this can be done. But
that does not mean that I recommend such a method - it seems to me to
be a very strange thing to do.
> I placed the kernel image direcltly after the ppcboot image with the (linux)
> command cat image >> ppcboot.bin.
Again, I don't think this is a good idea. It makes it impossible to
ever update the Linux kernel image without replacing U-Boot, too. The
risk to hang the whole system during this procedure makes this
prohibitive.
Maybe you should explain why you think you must include the kernel
image within the PPCBoot image, without proper alignment on flash
erase unit boundaries. I am pretty sure there must be better ways to
acchieve whtever you are trying to do.
> With the offset of the kernel and its length hardcoded no problem everything
> start.
I really wonder what you are doing.
> But when I use the function get_endaddr() (before relocation of course) It
> give me back an address approximatively 30 kBytes after the real end of
> ppcboot.
???
> Second problem, How can I find back or make ppcboot find the end of the
> Kernel image without anything hardcoded ?
Why would you do such a thing? PPCboot does not need to know the end
of the kernel image. For booting you just have to pass the start
address. And I strongly recommend to align this stard address with an
erase unit of your flash.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Any sufficiently advanced technology is indistinguishable from magic.
Clarke's Third Law - _Profiles of the Future_ (1962; rev. 1973)
``Hazards of Prophecy: The Failure of Imagination''
^ permalink raw reply
* 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
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.