* Re: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination Unreachable)
From: Marcello Scacchetti @ 2002-12-17 10:01 UTC (permalink / raw)
To: hare ram; +Cc: freedom, netfilter
In-Reply-To: <025b01c2a5b8$e2e7c200$13fcc5cb@nextto>
Try check here: http://www.haoli.org/rpm/redhat-7.x/RPMS/i386/
Marcello
Il mar, 2002-12-17 alle 11:41, hare ram ha scritto:
> hi
>
> yes you can patch up the kernel with new version
> but there is no Latest rpm availbale for 1.2.7a
>
> you need to use only 1.2.6a latest RPM with Redhat 8.0
> ----- Original Message -----
> From: "freedom" <freedom10@idemation.com>
> To: "'Marcello Scacchetti'" <marcello.scacchetti@nextrem.it>;
> <netfilter@lists.netfilter.org>
> Sent: Tuesday, December 17, 2002 9:23 AM
> Subject: RE: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination
> Unreachable)
>
>
> > Marcello,
> >
> > Sure...
> >
> > Is it possible to use IPTables version 1.2.7a with Redhat 7.3? RH 7.3
> > comes with a different version by default and I wanted to upgrade to
> > 1.2.7a. Is it possible?
> >
> > Also, do you know if any RPMs exist for IPTables version 1.2.7a and RH
> > 7.3?
> >
> > Thanks!
> > Kameron
> >
> > > -----Original Message-----
> > > From: netfilter-admin@lists.netfilter.org [mailto:netfilter-
> > > admin@lists.netfilter.org] On Behalf Of Marcello Scacchetti
> > > Sent: Monday, December 16, 2002 7:18 AM
> > > To: netfilter@lists.netfilter.org
> > > Subject: Re: ICMP Destination Unreachable
> > >
> > > Hi Kameron,
> > > can you be a little more verbose?
> > > What does "run" means? Unable to set rules? Unable to run iptables
> > > command? Unable to make rules work?
> > >
> > > Marcello
> > >
> > > Il ven, 2002-12-06 alle 16:09, Kameron ha scritto:
> > > > Hello Gurus,
> > > >
> > > > I have a couple of quick questions...
> > > >
> > > > 1) Does anybody know of any reason why I couldn't run IPTables
> > 1.2.7a
> > > > with RH7.3.
> > > >
> > > > 2) Are there any .rpm's for IPTables 1.2.7.a available? I attempted
> > to
> > > > compile my own, but didn't have any luck.
> > > >
> > > > Thanks!
> > > > Kameron
> > > --
> > > Marcello Scacchetti <marcello.scacchetti@nextrem.it>
> > >
> >
> >
> >
> >
--
Marcello Scacchetti <marcello.scacchetti@nextrem.it>
^ permalink raw reply
* Re: AW: Possible problem in asm/bitops.h
From: Paul Mackerras @ 2002-12-17 10:16 UTC (permalink / raw)
To: Georg Klug; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <FFECLICFNBJAHONLGAKMAEFOCHAA.gklug@giga-stream.de>
Georg Klug writes:
> Oops, I thought, that the directories /usr/include/linux as well as
> /usr/include/asm should come directly from the kernel (either as a copy
That is how it used to be done, but that way of doing things has been
deprecated for a long time now. /usr/include/{linux,asm} are part of
glibc these days.
> or symbolically linked). In that case those include files should always
> be prepared to be included in a userland application. Am I right with this?
>
> I also thought, that the asm-ppc/bitops.h should provide the same
> functionality as its pendant in asm-i386/ which lets userland applications
> use some static inline functions like set_bit() clear_bit() and change_bit().
> I actually don't know whether those functions are needed outside the kernel,
> so I cannot tell whether it is correct or not. But IMO it should be done
> the same way on all plattforms. Would you agree?
The policy is the same on all architectures: userland programs should
not include kernel headers. The architectures differ in the extent to
which this is enforced, that's all.
Paul.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* 3c59x AUI and sockets AF_PACKET
From: kernel @ 2002-12-17 10:16 UTC (permalink / raw)
To: netdev
Hi,
I have got an important problem to solve :
When I load the 3c59x module with no option, my 2 network cards
are working well with 10baseT, and vortex-diag tells me then :
Transceiver type in use: Autonegociate.
I can open a socket with AF_PACKET level, and bind() works fine !
I can send data to the socket through RJ45.
But, when I load 3c59x with options=1, vortex-diag tells me
Transceiver type in use : AUI10baseFL.
I can configure my 2 network cards with ifconfig.
Everything is ok, but, when i want to open my socket AF_PACKET to
send data to AUI port, bind () returns -1, as though all my interfaces
are ok (ifconfig sees them all).
I would like to send data to AUI, what is the problem ?
Thanks !!
Christophe Baillon
^ permalink raw reply
* Re: errors in symlinks in alsa-oss rc1 with mandrake 9.0
From: Friedrich Ewaldt @ 2002-12-17 10:18 UTC (permalink / raw)
To: m; +Cc: alsa-devel
In-Reply-To: <3DFCBF9A.2090108@iriXx.org>
Hi!
Exactly the same problem for me.
./configure fails for alsa-oss-0.9.0rc1 (extracted from
alsa-oss-0.9.0rc1.tar.bz2) because /usr/share/automake doesn't exist.
(There's only a /usr/share/automake-1.4 directory in my mandrake 9.0
installation).
here's part of 'ls -l alsa-oss-0.9.0rc1' output after extracting from
the tarball:
[...]
lrwxrwxrwx 1 root root 30 Dez 17 11:02 install-sh ->
/usr/share/automake/install-sh
lrwxrwxrwx 1 root root 27 Dez 17 11:02 missing ->
/usr/share/automake/missing
lrwxrwxrwx 1 root root 33 Dez 17 11:02 mkinstalldirs ->
/usr/share/automake/mkins
These 3 links are pointing to a path that doesn't exist.
Building from cvs using './cvscompile' works fine.
btw: What do I need this alsa-oss package for? I didn't miss any
functionality up to now without it, i.e I can cat wav files to /dev/dsp, ...
iriXx wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hi all
> just a note to say i had to modify the symlinks to 'missing',
> 'mkinstalldirs' and 'install-sh' to get alsa-oss-0.9.0rc1 to install
> under mandrake 9.0.
>
> it seems that from 9.0 mandrake puts automake in /usr/share/automake-1.4
> rather than /usr/share/automake. i dont know if anyone wants to add a
> detection for this to the config script?
>
> bw
> m~
> - --
> iriXx
>
-------------------------------------------------------
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
* Re: Alcatel speedtouch USB driver and SMP.
From: Alex Bennee @ 2002-12-17 10:30 UTC (permalink / raw)
To: Andrew McGregor; +Cc: Greg KH, Colin Paul Adams, Linux Kernel Mailing List
In-Reply-To: <9560000.1040119378@localhost.localdomain>
On Tue, 2002-12-17 at 10:02, Andrew McGregor wrote:
> The 2.5 tree one works for me *with PPPoATM*, which I gather is kind of a
> rare setup.
>
> Andrew
Not that rare, pppoa is quite common in Europe setups. FWIW there is now
a pppoe patch available for the user-mode driver (speedtouch.sf.net) so
if you have any problems with the kernel mode drivers you have a
fall-back position.
>
> --On Tuesday, December 17, 2002 00:57:32 +1300 Andrew McGregor
> <andrew@indranet.co.nz> wrote:
>
> > There's a binary only one from Alcatel themselves, which only works on
> > one 2.2 kernel and one (old) 2.4 kernel, the other is on SourceForge, and
> > is also GPL.
> >
> > Andrew, who's just set up one himself on 2.4 and will try 2.5 when enough
> > else behaves.
> >
> > --On Sunday, December 15, 2002 21:13:00 -0800 Greg KH <greg@kroah.com>
> > wrote:
> >
> >> On Sun, Dec 15, 2002 at 08:58:14AM +0000, Colin Paul Adams wrote:
> >>> >>>>> "Greg" == Greg KH <greg@kroah.com> writes:
> >>>
> >>> Greg> On Sun, Dec 15, 2002 at 07:10:33AM +0000, Colin Paul Adams
> >>> Greg> wrote:
> >>> >> Can anyone tell me if the speedtouch driver is SMP safe yet?
> >>>
> >>> Greg> Which driver? I know of at least 3 different ones :(
> >>>
> >>> drivers/usb/misc/speedtouch.c
> >>
> >> Ah good, you're using one that the source is available for :)
> >> I think the developer has said it will work on SMP machines, but what
> >> problems are you having, and have you asked the author of the code?
> >>
> >>> Where are the others?
> >>
> >> I don't know, but I know they are out there...
> >>
> >> thanks,
> >>
> >> greg k-h
> >> -
>
--
Alex Bennee
Senior Hacker, Braddahead Ltd
The above is probably my personal opinion and may not be that of my
employer
^ permalink raw reply
* Mailing list archive?
From: Colin.Helliwell @ 2002-12-17 10:28 UTC (permalink / raw)
To: linux-mips
Where does the list archive live these days? The only pointer I could find
to it is:
ftp://ftp.linux-mips.org/pub/linux/mips/archives/linux-mips.org/linux-mips/
but I get "permission denied"
^ permalink raw reply
* [PATCH] fix for RPM build target under newer versions
From: peter @ 2002-12-17 10:40 UTC (permalink / raw)
To: linux-kernel, Keith Owens, Michael E Chastain, kbuild-devel,
Linus Torvalds
[-- Attachment #1: Type: text/plain, Size: 551 bytes --]
Hi all,
I notice there's an "rpm" target in the Makefile, which seems broken
under RH 8.0. This may also apply to some "bleeding-edge" versions of
Mandrake and Suse. Specifically, RH "split" the RPM build process into a
separate utility from the old style rpm command. This could be fixed
with a few aliases to keep backwards compatibility a bit easier. I
wonder why an RH install doesn't already do this?
The reason why I'm sending this is because it's in the Makefile itself.
If it wasn't for that, I'd just use the aliases mentioned above.
[-- Attachment #2: Makefile.patch --]
[-- Type: text/plain, Size: 697 bytes --]
--- /usr/src/linux-2.4.19/Makefile 2002-12-15 19:04:20.000000000 -0500
+++ /home/pete/Makefile.new 2002-12-17 04:36:49.000000000 -0500
@@ -567,5 +567,16 @@
rm $(KERNELPATH) ; \
cd $(TOPDIR) ; \
. scripts/mkversion > .version ; \
- rpmbuild -ta $(TOPDIR)/../$(KERNELPATH).tar.gz ; \
+
+# RedHat split the RPM build process into a separate
+# utility called "rpmbuild", leading to a broken
+# "make rpm" target in the kernel Makefile;
+# this patch fixes that.
+
+ if [ `rpm --version | cut -b 12-15 | tr -d .` -ge '41' ] ;
+ then
+ rpmbuild -ta $(TOPDIR)/../$(KERNELPATH).tar.gz ; \
+ else
+ rpm -ta $(TOPDIR)/../$(KERNELPATH).tar.gz ; \
+ fi ; \
rm $(TOPDIR)/../$(KERNELPATH).tar.gz
^ permalink raw reply
* 2.4.20 copy_from/to_user
From: Margit Schubert-While @ 2002-12-17 10:42 UTC (permalink / raw)
To: linux-kernel
Maybe talking through the top of my hat , however -
copy_from_user and copy_to_user are used all over the place and the
return tested to see if an EFAULT should be generated.
Looking at include/asm-i386/uaccess.h and arch/i386/lib/usercopy.c
I don't see how these return anything but the 3rd (length) param.
Margit
^ permalink raw reply
* Re: Linux 2.4.20-ac2
From: O.Sezer @ 2002-12-17 10:32 UTC (permalink / raw)
To: linux-kernel
For IPMI to compile, I needed this include
in ipmi_watchdog.c :
#include <linux/nmi.h>
#include <linux/reboot.h>
#ifdef CONFIG_X86_LOCAL_APIC
+#include <asm/fixmap.h>
#include <asm/apic.h>
#endif
/*
Regards.
^ permalink raw reply
* Re: [PATCH] fix for RPM build target under newer versions
From: Henning P. Schmiedehausen @ 2002-12-17 10:44 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <3DFEFF01.7040304@wnyip.net>
peter <pvant67@wnyip.net> writes:
>--- /usr/src/linux-2.4.19/Makefile 2002-12-15 19:04:20.000000000 -0500
>+++ /home/pete/Makefile.new 2002-12-17 04:36:49.000000000 -0500
>@@ -567,5 +567,16 @@
> rm $(KERNELPATH) ; \
> cd $(TOPDIR) ; \
> . scripts/mkversion > .version ; \
>- rpmbuild -ta $(TOPDIR)/../$(KERNELPATH).tar.gz ; \
>+
>+# RedHat split the RPM build process into a separate
>+# utility called "rpmbuild", leading to a broken
>+# "make rpm" target in the kernel Makefile;
>+# this patch fixes that.
>+
>+ if [ `rpm --version | cut -b 12-15 | tr -d .` -ge '41' ] ;
>+ then
>+ rpmbuild -ta $(TOPDIR)/../$(KERNELPATH).tar.gz ; \
>+ else
>+ rpm -ta $(TOPDIR)/../$(KERNELPATH).tar.gz ; \
>+ fi ; \
Ugh. How about
--- cut ---
RPM=`which rpmbuild`
if [ -z "$RPM" ]; then
RPM=rpm
fi
$RPM -ta $(TOPDIR)/../$(KERNELPATH).tar.gz
--- cut ---
Looks less fragile. On RH 7.3 (and RH 6.x with upgrades) you also have
a rpmbuild binary (but rpm still does building, this got deprecated
and later removed on 8.0).
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
^ permalink raw reply
* Re: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination Unreachable)
From: hare ram @ 2002-12-17 10:41 UTC (permalink / raw)
To: freedom, 'Marcello Scacchetti', netfilter
In-Reply-To: <000a01c2a57f$e7a44f90$0501020a@compname3>
hi
yes you can patch up the kernel with new version
but there is no Latest rpm availbale for 1.2.7a
you need to use only 1.2.6a latest RPM with Redhat 8.0
----- Original Message -----
From: "freedom" <freedom10@idemation.com>
To: "'Marcello Scacchetti'" <marcello.scacchetti@nextrem.it>;
<netfilter@lists.netfilter.org>
Sent: Tuesday, December 17, 2002 9:23 AM
Subject: RE: Redhat 7.3 and IPTables 1.2.7a (was ICMP Destination
Unreachable)
> Marcello,
>
> Sure...
>
> Is it possible to use IPTables version 1.2.7a with Redhat 7.3? RH 7.3
> comes with a different version by default and I wanted to upgrade to
> 1.2.7a. Is it possible?
>
> Also, do you know if any RPMs exist for IPTables version 1.2.7a and RH
> 7.3?
>
> Thanks!
> Kameron
>
> > -----Original Message-----
> > From: netfilter-admin@lists.netfilter.org [mailto:netfilter-
> > admin@lists.netfilter.org] On Behalf Of Marcello Scacchetti
> > Sent: Monday, December 16, 2002 7:18 AM
> > To: netfilter@lists.netfilter.org
> > Subject: Re: ICMP Destination Unreachable
> >
> > Hi Kameron,
> > can you be a little more verbose?
> > What does "run" means? Unable to set rules? Unable to run iptables
> > command? Unable to make rules work?
> >
> > Marcello
> >
> > Il ven, 2002-12-06 alle 16:09, Kameron ha scritto:
> > > Hello Gurus,
> > >
> > > I have a couple of quick questions...
> > >
> > > 1) Does anybody know of any reason why I couldn't run IPTables
> 1.2.7a
> > > with RH7.3.
> > >
> > > 2) Are there any .rpm's for IPTables 1.2.7.a available? I attempted
> to
> > > compile my own, but didn't have any luck.
> > >
> > > Thanks!
> > > Kameron
> > --
> > Marcello Scacchetti <marcello.scacchetti@nextrem.it>
> >
>
>
>
>
^ permalink raw reply
* Re: [parisc-linux] quad tulip now not functional in 2.4.20
From: jsoe0708 @ 2002-12-17 10:43 UTC (permalink / raw)
To: grundler, Ed Schaller; +Cc: parisc-linux
In-Reply-To: <20021216231132.GC854@dsl2.external.hp.com>
>
>I've looked a bit at the same problem on A500 with
>a regular (single port) HP tulip card.
>
>> In the following dmesg out takes for 2.4.20-pa13 and 2.4.19-32 (debian=
),
>> it seems that the older kernel is finding the transceiver and
>> successfully auto-negotiating the link while the newer is not.
>
>yeah - same symptom that I saw.
>
>> Any ideas how to solve this? Any help would be greatly appreciated.
>
>I suspect it's a tulip driver bug.
>I haven't had a chance to diff the 2.4.19 vs 2.4.20 tulip driver.
>One idea might be to "forward port" the 2.4.19 drivers/net/tulip code
>into 2.4.20.
>
Same on B2k with add card.
Hmm I notice strange detail:
2.4.19 : lan heart bit on (even if interface not configure)
2.4.20 (& 21-pre1) : no lan heart bit on (interface configured or not)
I will try to revert tulip driver and advise you.
Cheer,
Joel
*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be
^ permalink raw reply
* Re: [BK][PATCH] ReiserFS CPU and memory bandwidth efficient large writes
From: Oleg Drokin @ 2002-12-17 10:53 UTC (permalink / raw)
To: Chris Mason; +Cc: Andrew Morton, Hans Reiser, Linux Kernel Mailing List
In-Reply-To: <1040063068.17501.31.camel@tiny>
Hello!
On Mon, Dec 16, 2002 at 01:24:28PM -0500, Chris Mason wrote:
> > reiserfs v3 was traditionally hungry on stack space I think.
> Well, if you want to drop stack usage, kill some inlines from stree.c.
> I really doubt we gain anything from inlining these:
I must be missing something, but I always thought that by inlining stuff we
actually _decrease_ stack usage, because no need to create one more stackframe
for function call, no need to put arguments on stack and this kind of stuff.
Bye,
Oleg
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Ulrich Drepper @ 2002-12-17 10:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.44.0212162140500.1644-100000@home.transmeta.com>
Linus Torvalds wrote:
> Ok, I did the vsyscall page too, and tried to make it do the right thing
> (but I didn't bother to test it on a non-SEP machine).
>
> But it might be interesting to verify that a
> recompiled glibc (or even just a preload) really works with this on a
> "whole system" testbed rather than just testing one system call (and not
> even caring about the return value) a million times.
I've created a modified glibc which uses the syscall code for almost
everything. There are a few int $0x80 left here and there but mostly it
is a centralized change.
The result: all works as expected. Nice.
On my test machine your little test program performs the syscalls on
roughly twice as fast (HT P4, pretty new). Your numbers are perhaps for
the P4 Xeons. Anyway, when measuring some more involved code (I ran my
thread benchmark) I got only about 3% performance increase. It's doing
a fair amount of system calls. But again, the good news is your code
survived even this stress test.
The problem with the current solution is the instruction set of the x86.
In your test code you simply use call 0xfffff000 and it magically work.
But this is only the case because your program is linked statically.
For the libc DSO I had to play some dirty tricks. The x86 CPU has no
absolute call. The variant with an immediate parameter is a relative
jump. Only when jumping through a register or memory location is it
possible to jump to an absolute address. To be clear, if I have
call 0xfffff000
in a DSO which is loaded at address 0x80000000 the jumps ends at
0x7fffffff. The problem is that the static linker doesn't know the load
address. We could of course have the dynamic linker fix up the
addresses but this is plain stupid. It would mean fixing up a lot of
places and making of those pages covered non-sharable.
Instead I've changed the syscall handling to effectve do
pushl %ebp
movl $0xfffff000, %ebp
call *%ebp
popl %ebp
An alternative is to store the address in a memory location. But since
%ebx is used for a syscall parameter it is necessary to address the
memory relative to the stack pointer which would mean loading the stack
address with 0xfffff000 before making the syscall. Not much better than
the code sequence above.
Anyway, it's still an improvement. But now the question comes up: how
the ld.so detect that the kernel supports these syscalls and can use an
appropriate DSO? This brings up again the idea of the read-only page(s)
mapped into all processes (you remember).
Anyway, it works nicely. If you need more testing let me know.
--
--------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
^ permalink raw reply
* Re: errors in symlinks in alsa-oss rc1 with mandrake 9.0
From: Takashi Iwai @ 2002-12-17 10:48 UTC (permalink / raw)
To: Friedrich Ewaldt; +Cc: perex, m, alsa-devel
In-Reply-To: <3DFEFA01.10600@gmx.de>
At Tue, 17 Dec 2002 11:18:41 +0100,
Friedrich Ewaldt wrote:
>
> Hi!
>
> Exactly the same problem for me.
> ./configure fails for alsa-oss-0.9.0rc1 (extracted from
> alsa-oss-0.9.0rc1.tar.bz2) because /usr/share/automake doesn't exist.
> (There's only a /usr/share/automake-1.4 directory in my mandrake 9.0
> installation).
>
> here's part of 'ls -l alsa-oss-0.9.0rc1' output after extracting from
> the tarball:
> [...]
> lrwxrwxrwx 1 root root 30 Dez 17 11:02 install-sh ->
> /usr/share/automake/install-sh
> lrwxrwxrwx 1 root root 27 Dez 17 11:02 missing ->
> /usr/share/automake/missing
> lrwxrwxrwx 1 root root 33 Dez 17 11:02 mkinstalldirs ->
> /usr/share/automake/mkins
> These 3 links are pointing to a path that doesn't exist.
ah, that explains the cause. we missed --copy option for automake.
anyway, cvscompile should work (as long as you installed autoconf,
automake and libtool).
Jaroslav, could you repackage the alsa-oss tarball at the next
release?
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
* Re: Multithreaded coredump patch where?
From: Roberto Fichera @ 2002-12-17 11:05 UTC (permalink / raw)
To: mgross; +Cc: linux-kernel
In-Reply-To: <200212170015.gBH0FXP13878@unix-os.sc.intel.com>
At 13.21 16/12/02 -0800, mgross wrote:
>I haven't rebased the patches I posted back in June for a while now.
>
>Attached is the patch I posted for the 2.4.18 vanilla kernel. Its a bit
>controversial, but it seems to work for a number of folks. Let me know if
>you have any troubles re-basing it.
Only one hunk failed on include/asm-ia64/elf.h but fixed by hand.
Why do you say a bit controversial ? One difference that I have
notice is in coredump size after your patch. However seem to be
working well for now. I'll try later on a SMP machine.
>I don't know if there is any plan to back port Ingo's version of this feature
>to 2.4.x
>
>--mgross
>
>
>
>On Monday 16 December 2002 09:28 am, Roberto Fichera wrote:
> > Does anyone point me where can I download a stable
> > multithread coredump patch for the 2.4.19/20 kernel ?
> >
> > Thanks in advance,
> >
> > Roberto Fichera.
> >
> >
> > ______________________________________
> > E-mail protetta dal servizio antivirus di IsolaWeb Agency & ISP
> > http://wwww.isolaweb.it
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
Roberto Fichera.
______________________________________
E-mail protetta dal servizio antivirus di IsolaWeb Agency & ISP
http://wwww.isolaweb.it
^ permalink raw reply
* mousewheel not working.
From: Anders Fugmann @ 2002-12-17 11:14 UTC (permalink / raw)
To: linux-kernel
Hi
I'm having troubles getting the mosuewheel on my logitech ps/2 mouseman+
(model M-C48) to work, under 2.5.52. Do I need to add something special
to the kernel boot parameters to instruct the driver that my mouse
carries 5 buttons?
dmesg:
device class 'input': registering
register interface 'mouse' with class 'input'
mice: PS/2 mouse device common for all mice
input: PS2++ Logitech Wheel Mouse on isa0060/serio1
.config
CONFIG_INPUT=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
Regards
Anders Fugmann
^ permalink raw reply
* Re: alsasound init script (Re: possible problems with rc6 aplay )
From: Takashi Iwai @ 2002-12-17 11:06 UTC (permalink / raw)
To: Mark Knecht; +Cc: Paul Davis, Alsa-Devel
In-Reply-To: <1040096816.3766.16.camel@Godzilla>
[-- Attachment #1: Type: text/plain, Size: 3755 bytes --]
At 16 Dec 2002 19:46:55 -0800,
Mark Knecht wrote:
>
> On Mon, 2002-12-16 at 18:51, Paul Davis wrote:
>
> >
> > i think it would something like this:
> >
> > options snd-hdsp snd_index=0
> > options snd-usb-foo snd_index=1
> >
> > i'm sure that takashi or jaroslav will correct me if i got this wrong.
> >
> > --p
>
> Paul,
> This makes perfect sense, and it isn't what I did. (!!)
>
> The PlanetCCRMA has a Nano-HOWTO on how to install the MidiMan 2X2 by
> hand. It's a little USB-based MIDI interface (not a sound card) that is
> not recognized by alsaconf, so we do a bit of editing by hand.
>
> alsaconf sets up modules.conf for the HDSP
>
> # --- BEGIN: Generated by ALSACONF, do not edit. ---
> # --- ALSACONF verion 0.9.0 ---
> alias char-major-116 snd
> alias snd-card-0 snd-hdsp
> alias char-major-14 soundcore
> alias sound-slot-0 snd-card-0
> alias sound-service-0-0 snd-mixer-oss
> alias sound-service-0-1 snd-seq-oss
> alias sound-service-0-3 snd-pcm-oss
> alias sound-service-0-8 snd-seq-oss
> alias sound-service-0-12 snd-pcm-oss
> options snd major=116 cards_limit=1 device_mode=0666
> options snd-hdsp index=0
> # --- END: Generated by ALSACONF, do not edit. ---
>
>
> We then modify one line in the file to look like this:
>
> options snd major=116 cards_limit=2 device_mode=0666
>
>
> and we also do the following:
>
> <SNIP from the Planet>
> add usb-midi and audio to the /etc/hotplug/blacklist file
> So that the OSS audio and usb-midi modules are not automatically loaded
> when the device reconnects after the firmware download. Add ``usb-midi''
> and ``audio'' in separate lines at the end of the list of blacklisted
> modules in that file.
> <End SNIP>
>
> I think, according to your info, that the problem is caused by not
> having some sort of
>
> options snd-midiman index=1
>
> line. That makes sense to me, except that I don't know what to put there
> since there actually isn't a driver. The goal is to get the system to
> make some devices in /dev/snd. This works fine on a cold boot, but fails
> sometimes on a warm boot. (At least I think it does, since sometimes I
> get pcmC1D0 when I have no pcmC0D0
the behavior depends on the order of booting.
if the hotplug service is booted before the alsasound init script,
hotplug will start the snd-usbaudio module, which will be assigned as
the first empty device, i.e. device #0, unless you specify the index
option. and afterwards, the alsasound script is started, and it
results in the confliction of devices.
setting an index option is one of the solutions.
in this case, the first usb-audio/midi device will be forced to be
assigned to #1. so, it's safe to start it beforehand.
but, when we take a deeper look at this, we find another problem.
the alsasound init script checks whether the ALSA was already started
by checking the existence of /proc/asound directory. and, if hotplug
started the usb-audio/midi before alsasound, this directory would be
also created because the alsa core was started without help of
alsasound init script, too. this leads to the skip of loading of any
other soundcards, because alsasound will quit immediately.
after all, a simple solution for this is to make sure that alsasound
starts before hotplug. then, even the index option for snd-usbaudio
wouldn't be necessary (in theory).
in the above scenario, anyway, cards_limit must be changed. and i
think it's a bit annoying.
the attached patch will change the handling of cards_limit option.
with the patch, the alsa won't restrict the number of cards per
cards_limit option, but only limits the auto-probing via kmod.
i.e. you can load more card modules even with cards_limit=1.
i'd like to hear which behavior is preferable.
ciao,
Takashi
[-- Attachment #2: limit-check.dif --]
[-- Type: application/octet-stream, Size: 1133 bytes --]
--- alsa-kernel/core/init.c 12 Jun 2002 10:21:00 -0000 1.9
+++ alsa-kernel/core/init.c 16 Jul 2002 12:11:37 -0000
@@ -67,11 +67,19 @@
idx = idx2;
break;
}
+ if (idx < 0 && snd_ecards_limit < SNDRV_CARDS)
+ /* for dynamically additional devices like hotplug:
+ * increment the limit if still free slot exists.
+ */
+ idx = snd_ecards_limit++;
} else if (idx < snd_ecards_limit) {
if (snd_cards_lock & (1 << idx))
idx = -1; /* invalid */
- }
- if (idx < 0 || idx >= snd_ecards_limit) {
+ } else if (idx < SNDRV_CARDS)
+ snd_ecards_limit = idx + 1; /* increase the limit */
+ else
+ idx = -1;
+ if (idx < 0) {
write_unlock(&snd_card_rwlock);
if (idx >= snd_ecards_limit)
snd_printk(KERN_ERR "card %i is out of range (0-%i)\n", idx, snd_ecards_limit-1);
--- alsa-kernel/core/sound.c 23 May 2002 08:26:29 -0000 1.14
+++ alsa-kernel/core/sound.c 16 Jul 2002 12:13:03 -0000
@@ -81,7 +81,7 @@
if (snd_cards[card] != NULL)
return;
- if (card < 0 || card >= snd_ecards_limit)
+ if (card < 0 || card >= snd_cards_limit)
return;
sprintf(str, "snd-card-%i", card);
request_module(str);
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: dada1 @ 2002-12-17 11:17 UTC (permalink / raw)
To: Ulrich Drepper, Linus Torvalds; +Cc: Dave Jones, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <3DFF023E.6030401@redhat.com>
> For the libc DSO I had to play some dirty tricks. The x86 CPU has no
> absolute call. The variant with an immediate parameter is a relative
> jump. Only when jumping through a register or memory location is it
> possible to jump to an absolute address. To be clear, if I have
>
> call 0xfffff000
>
> in a DSO which is loaded at address 0x80000000 the jumps ends at
> 0x7fffffff. The problem is that the static linker doesn't know the load
> address. We could of course have the dynamic linker fix up the
> addresses but this is plain stupid. It would mean fixing up a lot of
> places and making of those pages covered non-sharable.
>
You could have only one routine that would need a relocation / patch at
dynamic linking stage :
absolute_syscall:
jmp 0xfffff000
Then all syscalls routine could use :
getpid:
...
call absolute_syscall
...
instead of "call 0xfffff000"
If the kernel doesnt support the 0xfffff000 page, you could patch
absolute_syscall (if it resides in .data section) with :
absolute_syscall:
int 0x80
ret
(3 bytes instead of 5 bytes)
See you
^ permalink raw reply
* QoS limitations ....
From: Raymond Leach @ 2002-12-17 11:16 UTC (permalink / raw)
To: Netfilter Mailing List
[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]
Hi all
Does anyone know of a limit to the number of filters or classes that can
be attached to a single qdisc (let's say CBQ or HTB)?
I have a client that want to do bandwidth throttling per ip across 10
class C subnets.
What problems can I expect, and does anyone have any other suggestions
on how to accomplish this?
Ray
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
( Raymond Leach )
) Knowledge Factory (
( )
) Tel: +27 11 445 8100 (
( Fax: +27 11 445 8101 )
) (
( http://www.knowledgefactory.co.za/ )
) http://www.saptg.co.za/ (
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
o o
o o
.--. .--.
| o_o| |o_o |
| \_:| |:_/ |
/ / \\ // \ \
( | |) (| | )
/`\_ _/'\ /'\_ _/`\
\___)=(___/ \___)=(___/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCHSET] PC-9800 addtional for 2.5.50-ac1 (21/21)
From: Osamu Tomita @ 2002-12-16 14:36 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: linux-kernel, alan
In-Reply-To: <20021215.225942.24871004.yoshfuji@linux-ipv6.org>
[-- Attachment #1: Type: text/plain, Size: 2931 bytes --]
YOSHIFUJI Hideaki / 吉藤英明 wrote:
>
> In article <3DFC818F.80E3DC00@cinet.co.jp> (at Sun, 15 Dec 2002 22:20:15 +0900), Osamu Tomita <tomita@cinet.co.jp> says:
>
> > +#ifndef CONFIG_PC9800
> > if (mpf->mpf_physptr)
> > reserve_bootmem(mpf->mpf_physptr, PAGE_SIZE);
> > +#else
> > + /*
> > + * PC-9800's MPC table places on the very last of
> > + * physical memory; so that simply reserving PAGE_SIZE
> > + * from mpg->mpf_physptr yields BUG() in
> > + * reserve_bootmem.
> > + */
> > + if (mpf->mpf_physptr) {
> > + /*
> > + * We cannot access to MPC table to compute
> > + * table size yet, as only few megabytes from
> > + * the bottom is mapped now.
> > + */
> > + unsigned long size = PAGE_SIZE;
> > + unsigned long end = max_low_pfn * PAGE_SIZE;
> > + if (mpf->mpf_physptr + size > end)
> > + size = end - mpf->mpf_physptr;
> > + reserve_bootmem(mpf->mpf_physptr, size);
> > + }
> > +#endif
> > +
>
> I'm not sure if we need this #ifdef;
> it doesn't seem that this #ifdef CONFIG_PC9800 part is harmful
> for others at all.
>
> Well, if it is required, I prefer putting #ifdef..#endif inside the
> if-clause like this:
>
> if (mpf->mpf_physptr) {
> unsigned long size = PAGE_SIZE;
> #ifdef CONFIG_PC9800
> /*
> * PC-9800's MPC table places on the very last of
> * physical memory; so that simply reserving PAGE_SIZE
> * from mpg->mpf_physptr yields BUG() in
> * reserve_bootmem.
> *
> * We cannot access to MPC table to compute
> * table size yet, as only few megabytes from
> * the bottom is mapped now.
> */
> unsigned long end = max_low_pfn * PAGE_SIZE;
>
> if (mpf->mpf_physptr + size > end)
> size = end - mpf->mpf_physptr;
> #endif
> reserve_bootmem(mpf->mpf_physptr, size);
> }
>
Thanks for your advice!
Indeed, No need "#ifdef" here.
Because there is a check by "if (mpf->mpf_physptr + size > end)".
I rewrite patch. Please comment.
--
Osamu Tomita
[-- Attachment #2: smp.patch --]
[-- Type: text/plain, Size: 4480 bytes --]
diff -Nru linux/arch/i386/kernel/mpparse.c linux98/arch/i386/kernel/mpparse.c
--- linux/arch/i386/kernel/mpparse.c 2002-12-16 09:15:54.000000000 +0900
+++ linux98/arch/i386/kernel/mpparse.c 2002-12-16 17:15:15.000000000 +0900
@@ -73,6 +73,8 @@
int summit_x86 = 0;
u8 raw_phys_apicid[NR_CPUS] = { [0 ... NR_CPUS-1] = BAD_APICID };
+extern int pc98; /* NEC PC-9800 subarchitecture or not */
+
/*
* Intel MP BIOS table parsing routines:
*/
@@ -683,7 +685,8 @@
* Read the physical hardware table. Anything here will
* override the defaults.
*/
- if (!smp_read_mpc((void *)mpf->mpf_physptr)) {
+ if (!smp_read_mpc(pc98 ? phys_to_virt(mpf->mpf_physptr)
+ : (void *)mpf->mpf_physptr)) {
smp_found_config = 0;
printk(KERN_ERR "BIOS bug, MP table errors detected!...\n");
printk(KERN_ERR "... disabling SMP support. (tell your hw vendor)\n");
@@ -737,8 +740,25 @@
printk("found SMP MP-table at %08lx\n",
virt_to_phys(mpf));
reserve_bootmem(virt_to_phys(mpf), PAGE_SIZE);
- if (mpf->mpf_physptr)
- reserve_bootmem(mpf->mpf_physptr, PAGE_SIZE);
+ /*
+ * PC-9800's MPC table places on the very last of
+ * physical memory; so that simply reserving PAGE_SIZE
+ * from mpg->mpf_physptr yields BUG() in
+ * reserve_bootmem.
+ */
+ if (mpf->mpf_physptr) {
+ /*
+ * We cannot access to MPC table to compute
+ * table size yet, as only few megabytes from
+ * the bottom is mapped now.
+ */
+ unsigned long size = PAGE_SIZE;
+ unsigned long end = max_low_pfn * PAGE_SIZE;
+ if (mpf->mpf_physptr + size > end)
+ size = end - mpf->mpf_physptr;
+ reserve_bootmem(mpf->mpf_physptr, size);
+ }
+
mpf_found = mpf;
return 1;
}
@@ -750,8 +770,6 @@
void __init find_smp_config (void)
{
- unsigned int address;
-
/*
* FIXME: Linux assumes you have 640K of base ram..
* this continues the error...
@@ -781,11 +799,13 @@
* MP1.4 SPEC states to only scan first 1K of 4K EBDA.
*/
- address = *(unsigned short *)phys_to_virt(0x40E);
- address <<= 4;
- smp_scan_config(address, 0x400);
- if (smp_found_config)
- printk(KERN_WARNING "WARNING: MP table in the EBDA can be UNSAFE, contact linux-smp@vger.kernel.org if you experience SMP problems!\n");
+ if (!pc98) { /* PC-9800 has no EBDA area? */
+ unsigned int address = *(unsigned short *)phys_to_virt(0x40E);
+ address <<= 4;
+ smp_scan_config(address, 0x400);
+ if (smp_found_config)
+ printk(KERN_WARNING "WARNING: MP table in the EBDA can be UNSAFE, contact linux-smp@vger.kernel.org if you experience SMP problems!\n");
+ }
}
diff -Nru linux/arch/i386/kernel/smpboot.c linux98/arch/i386/kernel/smpboot.c
--- linux/arch/i386/kernel/smpboot.c 2002-11-23 06:40:42.000000000 +0900
+++ linux98/arch/i386/kernel/smpboot.c 2002-11-25 11:14:21.000000000 +0900
@@ -823,13 +823,27 @@
nmi_low = *((volatile unsigned short *) TRAMPOLINE_LOW);
}
+#ifndef CONFIG_PC9800
CMOS_WRITE(0xa, 0xf);
+#else
+ /* reset code is stored in 8255 on PC-9800. */
+ outb(0x0e, 0x37); /* SHUT0 = 0 */
+#endif
local_flush_tlb();
Dprintk("1.\n");
*((volatile unsigned short *) TRAMPOLINE_HIGH) = start_eip >> 4;
Dprintk("2.\n");
*((volatile unsigned short *) TRAMPOLINE_LOW) = start_eip & 0xf;
Dprintk("3.\n");
+#ifdef CONFIG_PC9800
+ /*
+ * On PC-9800, continuation on warm reset is done by loading
+ * %ss:%sp from 0x0000:0404 and executing 'lret', so:
+ */
+ /* 0x3f0 is on unused interrupt vector and should be safe... */
+ *((volatile unsigned long *) phys_to_virt(0x404)) = 0x000003f0;
+ Dprintk("4.\n");
+#endif
/*
* Be paranoid about clearing APIC errors.
diff -Nru linux/include/asm-i386/smpboot.h linux98/include/asm-i386/smpboot.h
--- linux/include/asm-i386/smpboot.h 2002-10-12 13:22:19.000000000 +0900
+++ linux98/include/asm-i386/smpboot.h 2002-10-12 19:33:46.000000000 +0900
@@ -13,8 +13,17 @@
#define TRAMPOLINE_LOW phys_to_virt(0x8)
#define TRAMPOLINE_HIGH phys_to_virt(0xa)
#else /* !CONFIG_CLUSTERED_APIC */
+ #ifndef CONFIG_PC9800
#define TRAMPOLINE_LOW phys_to_virt(0x467)
#define TRAMPOLINE_HIGH phys_to_virt(0x469)
+ #else /* CONFIG_PC9800 */
+ /*
+ * On PC-9800, continuation on warm reset is done by loading
+ * %ss:%sp from 0x0000:0404 and executing 'lret', so:
+ */
+ #define TRAMPOLINE_LOW phys_to_virt(0x4fa)
+ #define TRAMPOLINE_HIGH phys_to_virt(0x4fc)
+ #endif /* !CONFIG_PC9800 */
#endif /* CONFIG_CLUSTERED_APIC */
#ifdef CONFIG_CLUSTERED_APIC
^ permalink raw reply
* Via 8233 flooding of errors [2.4-ac]
From: Nathaniel Russell @ 2002-12-17 11:41 UTC (permalink / raw)
To: alan; +Cc: linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 283 bytes --]
Hello
When i play 3 or more songs in a row i get the error message of
drained playback and my audio just shuts off until i exit the mp3 program
and reload it. Every 3rd song though it stops playing. And plus once in
awhile i get a Assertion failed message. Help please....
Nathaniel
[-- Attachment #2: Via 8233 Error --]
[-- Type: TEXT/PLAIN, Size: 517 bytes --]
[SNIPED]
Via 686a/8233/8235 audio driver 1.9.1-ac
PCI: Found IRQ 11 for device 00:11.5
PCI: Sharing IRQ 11 with 00:09.1
PCI: Sharing IRQ 11 with 00:0a.0
via82cxxx: Six channel audio available
PCI: Setting latency timer of device 00:11.5 to 64
ac97_codec: AC97 Audio codec, id: ICE17(ICE1232)
via82cxxx: board #1 at 0xE800, IRQ 11
[SNIPED]
Assertion failed! chan->is_active == sg_active(chan->iobase),via82cxxx_audio.c,via_chan_maybe_start,line=1347
via_audio: ignoring drain playback error -512
[SNIPED]
^ permalink raw reply
* Re: Domain transition
From: Brian May @ 2002-12-17 11:42 UTC (permalink / raw)
To: Russell Coker; +Cc: SELinux
In-Reply-To: <200212171019.27323.russell@coker.com.au>
On Tue, Dec 17, 2002 at 10:19:27AM +0100, Russell Coker wrote:
> > (and yes, you can use Kerberos Telnet or SSL-Telnet too, so telnet
> > doesn't always have to mean insecure; with these protocols you need to
> > be authenticated though before login is run).
>
> SSL-Telnet would be OK apart from it's history of security holes.
Yes. At one stage a group of Debian developers looked at 2 to 4
different implementations of SSL-Telnet, trying to work out which
was the best one.
The conclusion, IIRC, was that all of them were pretty awful,
just some had more features then others.
> Kerberos still isn't safe, proxying the telnet protocol and hijacking it is
> not overly difficult...
Do you have a reference?
--
Brian May <bam@snoopy.apana.org.au>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* TTY_FLIPBUF_SIZE
From: Sriram Narasimhan @ 2002-12-17 11:43 UTC (permalink / raw)
To: linux-serial
Hello,
The TTY_FLIPBUF_SIZE is restricted to 2 * 512 bytes. Can this be
increased to support synchronous serial lines without affecting other
serial drivers which still stick to the TTY_FLIPBUF_SIZE limit ?
Thank you.
Regards,
Sriram
^ permalink raw reply
* Re: buggy scsi_register behaviour in 2.5.51
From: Willem Riede @ 2002-12-17 11:47 UTC (permalink / raw)
To: dgilbert; +Cc: linux-scsi
In-Reply-To: <3DFE998E.1080103@interlog.com>
On 2002.12.16 22:27 Douglas Gilbert wrote:
> Willem,
> Can't fix all those problems but I did notice that
> idescsi_release() was missing a call to scsi_unregister().
> With this patch the ide-scsi entry remains dangling in
> sysfs (ide problem??) but the scsi host gets cleaned up
> after rmmod.
>
> The attachment is against lk 2.5.52 . The ide-scsi
> driver in lk 2.5.52 needs cleaning up in several
> areas. If no-one else wants to attack it then I
> will.
>
Thanks Doug.
I'll also see if I can find what the remaining problems are. I'd also be
prepared do do "cleaning up" of ide-scsi -- what in your opinion needs
taking care of?
Regards, Willem Riede.
^ 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.