* Possible problem in asm/bitops.h
From: Georg Klug @ 2002-12-11 15:31 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
today I tried to compile the iproute2-2.4.7-now-ss010824 for my walnut-like
custom board. But unfortunately it fails: (original make output below)
The reason seems to be that linux/inetdevice.h uses the inline function ffz()
to define another inline function inet_mask_len(). The ffz() function is
defined in the include file asm/bitops.h. But now there is some inconsistency
between the asm-i386/ and the asm-ppc/ directory: while the asm-i386/bitops.h
defines the ffz function for all includes, the asm-ppc/bitops.h restricts the
ffz function (and also some others) to kernel files (with #ifdef __KERNEL__).
I then tried to remove the #ifdef __KERNEL__ from the first significant line
of the asm-ppc/bitops.h file, but now the compiler complained about the missing
macro definition of PPC405_ERR77(). This one is defined in the asm-ppc/atomic.h
as well as in asm-ppc/ppc_asm.h, but - unfortunately - differently. (One has
double quotes, the other not.) The definition in atomic.h is only for kernel
files, but I moved it out of the #ifdef __KERNEL__ and could successfully
compile
iproute2.
But here are my questions:
Q: Is the ffz() function desgined to work in a user space application, too? If
yes, the file asm-ppc/bitops.h would need a change.
Q: Does it make any sense to define one single macro (PPC405_ERR77()) in
different
ways in different include files?
What is your opinion?
Kind regards,
Georg Klug
------------- output of the make ---------------------------------
make KERNEL_INCLUDE=/var/samba/Users/gklug/Work/tmp/linux-2.4.17_mvl21/include
CC=ppc_405-gcc
make[1]: Entering directory
`/var/samba/Users/gklug/Work/linux/tools/net/iproute2/lib'
ppc_405-gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -Werror -g -I../include-
glibc -include
../include-glibc/glibc-bugs.h -I/var/samba/Users/gklug/Work/tmp/linux-2.4.17_mvl
21/include -I../include -DRESOLVE_HOSTNAMES -c -o ll_map.o ll_map.c
ppc_405-gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -Werror -g -I../include-
glibc -include
../include-glibc/glibc-bugs.h -I/var/samba/Users/gklug/Work/tmp/linux-2.4.17_mvl
21/include -I../include -DRESOLVE_HOSTNAMES -c -o libnetlink.o libnetlink.c
ar rcs libnetlink.a ll_map.o libnetlink.o
ppc_405-gcc -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -Werror -g -I../include-
glibc -include
../include-glibc/glibc-bugs.h -I/var/samba/Users/gklug/Work/tmp/linux-2.4.17_mvl
21/include -I../include -DRESOLVE_HOSTNAMES -c -o utils.o utils.c
cc1: warnings being treated as errors
In file included from ../include/utils.h:6,
from utils.c:30:
/var/samba/Users/gklug/Work/tmp/linux-2.4.17_mvl21/include/linux/inetdevice.h:
In function `inet_mask_len':
/var/samba/Users/gklug/Work/tmp/linux-2.4.17_mvl21/include/linux/inetdevice.h:16
3: warning: implicit declaration of function `ffz'
make[1]: *** [utils.o] Error 1
make[1]: Leaving directory
`/var/samba/Users/gklug/Work/linux/tools/net/iproute2/lib'
make: *** [all] Error 2
------------------------------------------------------------------
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: ax25 kernel problem sometimes accur
From: Jeroen Vreeken @ 2002-12-11 15:32 UTC (permalink / raw)
To: linux-hams
In-Reply-To: <Pine.LNX.4.44.0212110828110.1073-100000@jeeves.mvw.net>
On 2002.12.11 14:36:25 +0100 mvw@mvw.net wrote:
> Gents,
>
> > [snip] AX.25 is about the worst protocol design
> > I've ran over in my life
>
> That's not encouraging. Is it really that bad?
>
> Asking becuase TCP/IP over ax.25 is the one thing that can rescue packet,
I think he was refering to ax.25 connections, tcp/ip is generally done in
UI frames, for those ax25 is not much different from e.g. ethernet.
On a side note:
What is the state of netrom? I have had only ax25 races with 2.4, netrom
seems to be stable (or atleast stable enough to let ax25 crash first :)
I am curious to what will need to change to netrom because I would have to
update my inp3 patch to it...
Jeroen
^ permalink raw reply
* Re: Is this going to be true ?
From: Alan Cox @ 2002-12-11 16:19 UTC (permalink / raw)
To: root; +Cc: Serge Kuznetsov, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.3.95.1021211082545.19625B-100000@chaos.analogic.com>
On Wed, 2002-12-11 at 13:38, Richard B. Johnson wrote:
> recent ground-breaking). Microsoft intends to "continue to be a world
> leader...etc..", and is positioning itself world-wide so it will not
> even need the United States for distribution. This is its response to the
> US lawsuits. Basically, they have outgrown the need for the United
> States...
Lawsuits are very little to do with it. Its straight forward hard
numbers. Software writing is a labour intensive business with easily
transportable goods. Like all such businesses the non specialist part of
it has no future in the US or Western Europe. Any economist can happily
show you that all these "digital future", "e-economy" buzzwords are
crap, at least to the west.
^ permalink raw reply
* Re: Is this going to be true ?
From: Herman Oosthuysen @ 2002-12-11 1:08 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <001801c2a0a9$02613f40$2e863841@joe>
MS once described the GPL as a 'cancer'. One of the 'features' of
cancer is that it grows fast and can't be stopped easily, so I suppose
they were correct...
MS history shows that they did and does support various flavours of
*nix. So, it is not beneath them to release apps for Linux too one day
and it would be a good thing if they do. Competition is always good. It
inpires people to do better.
Joseph D. Wagner wrote:
>>I am just curious if someone has an opinion for the
>>following link?
>>
>>Research Firm: Microsoft Will Use Linux by 2004:
>>[trim]
>
>
> Over Bill Gates' dead body. The Microsoft Corporation (and by that, I mean
> the people running it: Chairman of the Board, CEO, CIO, CFO, Board of
> Directors, most of the stockholders, etc.) is of the genuine belief that
> Microsoft Windows is the operating system of the future. (Whether you
> believe it or not is a separate topic.) Developing products for the Linux
> platform is both 1) an admission that this belief was wrong, and 2) an
> admission that their own current version of Microsoft Windows is somehow
> shoddy, not-up-to-par, insufficient, or even on an equal footing with Linux.
> The Microsoft Corporation will never admit either of those two things.
> After all, it's the MICROSOFT CORPORATION. If they didn't believe these
> things, they would go somewhere else.
>
> The following scenarios are far more likely.
>
> 1) Future development of the Windows operating system or some of its
> components will be *BSD based. The Microsoft Corporation will never touch
> Linux. Period. The lawyers simply wouldn't allow it. The lawyers think of
> GNU GPL as an infectious disease, and so anything Linux is out of the
> question. The BSD license is far more favorable to proprietary development,
> since it allows you to close off the source. Hence, assimilating a *BSD
> structure, component, or piece of code is far more likely.
>
> In fact, Microsoft Windows 2000/XP already did that with Kerberos.
>
> 2) Lower prices for Microsoft Licensing or more broadly interpreted
> licensing. It may be that to better compete with Linux that Microsoft
> lowers the prices of some of its Microsoft products.
>
> One thing Microsoft has already done in this regard is to change the
> licensing on Terminal Server. On Windows NT 4.0, each copy of Windows NT
> Workstation needed a Client Access License and a Terminal Server Client
> Access License to connect to a server and a server's Terminal Server,
> respectively. Now, with Windows 2000 and XP Pro, a Terminal Server Client
> Access License is included with either a regular Client Access License or a
> Windows 2000 or XP Pro operating system license (I forget which).
>
> 3) Develop kits, wizards, and other software to help people convert from
> Linux to Windows. Microsoft already has Unix for Windows Services (or
> something like that with a similar name). It's purpose is to help people
> convert from SCO UNIX to Windows. I see no reason that Microsoft can't
> develop a similar such kit for, say, Red Hat Linux. (Sure, it would be one
> heck-of-a-kit and very complicated, but I can see it).
>
> *Sigh* Yet, another topic for the linux-politics list. There is no such
> list, BTW, but this email highlights the need for one.
>
> Joseph Wagner
>
> -
> 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/
>
^ permalink raw reply
* Re: PPTP+NAT+MASQ anyone?
From: Roy Sigurd Karlsbakk @ 2002-12-11 15:35 UTC (permalink / raw)
To: Martin Josefsson; +Cc: Netfilter mailinglist
In-Reply-To: <1039616794.20561.83.camel@tux>
> > cd /usr/src
> > tar xzf packed/linux-2.4.19.tar.gz
> > ln -s linux-2.4.19 linux
> > cd netfilter/patch-o-matic
> > ./runme pending
> > ./runme extra
>
> I have no idea, you say you use p-o-m from cvs and that you apply all
> pending patches... after doing that the pptp patch works fine here.
that's exactly what I'm doing. with kernel 2.4.19 and 2.4.20.
doesn't work
so.
can I just add the required patches manually without going for the whole
bunch?
if so - which ones do i need?
--
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
* RE: Regarding consistent_alloc
From: acurtis @ 2002-12-11 15:36 UTC (permalink / raw)
To: Pantelis Antoniou, acurtis
Cc: joakim.tjernlund, Tom Rini, Dan Malek, Paul Mackerras,
Matt Porter, linuxppc-embedded
In-Reply-To: <3DF75343.3060005@intracom.gr>
> Lets assume that we force the memory returned by the xxx_cpm_hostalloc()
> and xxx_cpm_dpalloc() routines to return contiguous memory both
> virtually and physically. Is there any negative impact?
> Every driver out there expects precisely that.
>
It will be interesting to see how you solve the virtual and physical
contiguity in a general implementation. IMHO it isn't worth the effort.
> Regarding the dual-ported memory, keep in mind that there are members
> of the 8xx family that are very constrained.
> Better allocation routines will allow us to utilise even the gaps
> left between configured parameter areas. Yes it is horrible
> but that's the way that the hardware is designed.
Yes, we need every spare byte and sometime you MUST use certain memory
regions based on hardware contraints.
Sorry for any confusion.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [RFC] [PATCH] use nice values in deadline IO scheduler
From: Charles Baylis @ 2002-12-11 15:44 UTC (permalink / raw)
To: linux-kernel
This untested patch uses the nice value of the current task to scale the
deadline for new read requests.
Does current contain a pointer to the task which caused the IO request at
this point? Is there any other reason why this might be a daft thing to do?
--- drivers/block/deadline-iosched.c~std 2002-12-11 14:33:48.000000000 +0000
+++ drivers/block/deadline-iosched.c 2002-12-11 15:17:58.000000000 +0000
@@ -17,6 +17,7 @@
#include <linux/init.h>
#include <linux/compiler.h>
#include <linux/hash.h>
+#include <linux/sched.h>
/*
* feel free to try other values :-). read_expire value is the timeout for
@@ -81,6 +82,19 @@ static kmem_cache_t *drq_pool;
#define RQ_DATA(rq) ((struct deadline_rq *) (rq)->elevator_private)
/*
+ * scale_deadline
+ */
+static int scale_deadline(int default_deadline)
+{
+ int prio = current->static_prio - MAX_RT_PRIO;
+ /* make priorities higher than nice -10 equal to nice -10 */
+ if (prio < 10)
+ prio = 10;
+ /* scale the deadline according to priority */
+ return default_deadline * prio/20;
+}
+
+/*
* rq hash
*/
static inline void __deadline_del_rq_hash(struct deadline_rq *drq)
@@ -440,7 +454,7 @@ deadline_add_request(request_queue_t *q,
/*
* set expire time and add to fifo list
*/
- drq->expires = jiffies + dd->read_expire;
+ drq->expires = jiffies + scale_deadline(dd->read_expire);
list_add_tail(&drq->fifo, &dd->read_fifo);
}
}
^ permalink raw reply
* Re: Modifying Source Ip on input/prerouting
From: Stephane Jourdois @ 2002-12-11 15:38 UTC (permalink / raw)
To: Andrea Rossato; +Cc: netfilter
In-Reply-To: <3DF7536F.9050002@istitutocolli.org>
On Wed, Dec 11, 2002 at 04:02:07PM +0100, Andrea Rossato wrote:
> Stephane Jourdois wrote:
> >I would need to be able to modify the source ip on input GRE paquets.
> >This is because I'm trying to setup a pptp tunnel, via a router that
> >doesn't NAT correctly the GRE.
> >The client receives GRE, but replies with it's own local ip, then my
> >server cannot receive the answers... If I could just change the source
> >ip on those paquets, that would be perfect...
>
> i don't know if I've got your problem correctly, also because I don't
> know pptp too much (so, shut up, you'll say...;)
no, no, I won't ;-)
> if you want to match gre packets and change their source address (not
> the source addr. of encapsulated packets) you should be able with
> iptables -A POSTROUTING -t nat -p gre -j SNAT --to-source
> new-grepacket-source-addr
> this will match all outgoing (from the client) traffic using gre protocol.
The problem is that I wan't to change the incoming traffic...
What I would need is something similar to :
-A PREROUTING -j SNAT --from-source xxx
> but is this what you need?
> where are the tunnel end points? the router has two tunnels connecting
> the server and the client? the tunnel is between the router and the server?
The server is My linux machine, on which I wan't to modify the GRE
traffic, because I don't have access to the gateway of the client (a
windows 2k, but that doesn't matter).
> Instead, if you want to change source address of encasplulated packets,
> that would be interesting...
mmm No, they are not. Well, they are over IP ;-)
Thanks for your help, anyway.
--
/// Stephane Jourdois /"\ ASCII RIBBON CAMPAIGN \\\
((( Ingénieur développement \ / AGAINST HTML MAIL )))
\\\ 6, av. George V X ///
\\\ 75008 Paris / \ +33 6 8643 3085 ///
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Christoph Hellwig @ 2002-12-11 15:39 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: Christoph Hellwig, James Bottomley, linux-scsi
In-Reply-To: <1266570000.1039619906@aslan.scsiguy.com>
On Wed, Dec 11, 2002 at 08:18:26AM -0700, Justin T. Gibbs wrote:
> > Okay, here's a lightly tested patch to get it in shape and
> > compile/useable..
>
> Why is this based on Alpha1 and not Alpha2.
Because that's a) what James put in the BK tree and b) that's what I downloaded
from your website today for reference.
> driver has to build all the way back to 2.4.7 (RedHat 7.2 support).
RedHat only supports kernel 2.4.18 for RH7.2/i386 and 2.4.9 with tons of
hacks for the other arches, so your argument is void. Not to mention the only
support that is dropped by my changes is for builtin support < 2.2.18.
> Removing ifdefs just makes it harder for me to merge in changes from
> external trees. Yes, the ifdefs are ugly, but so is the Linux SCSI layer
> and the unmanaged way that interfaces have been changed without any
> consideration to backwards compatibility (eg. the HIGHIO stuff could have
> been done with 0 impact to drivers, but wasn't for some strange reason).
linux driver interface change between stable series, face it. And a driver
with tons of ifdefs is utter crap. Interestingly only vendor driver use
that shitty scheme.
>
> > - fix kbuild integration
>
> Can you explain what failed before? I don't mind using aic7xxx-y
> or aic79xx-y instead of *-obj, but I would like to understand what
> bug this fixes.
AIC79xx support could be selected without PCI beeing set, letting
the makefile silently not build it, the driver wouldn't compile with
objdir != srcdir and it used more makefile code then nessecary.
^ permalink raw reply
* Re: PPTP+NAT+MASQ anyone?
From: Martin Josefsson @ 2002-12-11 15:40 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk; +Cc: Netfilter mailinglist
In-Reply-To: <200212111635.37659.roy@karlsbakk.net>
On Wed, 2002-12-11 at 16:35, Roy Sigurd Karlsbakk wrote:
> that's exactly what I'm doing. with kernel 2.4.19 and 2.4.20.
> doesn't work
> so.
> can I just add the required patches manually without going for the whole
> bunch?
> if so - which ones do i need?
You will at least need the newnat patch. (I hope the pptp patch doesn't
depend on some other patch in there)
But everything in the pending directory is recommended.
then just apply the pptp patch.
I can't see why this shouldn't work for you.
You are sure you are using an up to date cvs checkout?
--
/Martin
Never argue with an idiot. They drag you down to their level, then beat
you with experience.
^ permalink raw reply
* Re: [PATCH] let 2.5.51 build
From: Takashi Iwai @ 2002-12-11 15:43 UTC (permalink / raw)
To: Thierry Vignaud; +Cc: alsa-devel
In-Reply-To: <m2k7igc29i.fsf@vador.mandrakesoft.com>
At Wed, 11 Dec 2002 10:51:05 +0100,
Thierry Vignaud wrote:
>
> [1 <text/plain (7bit)>]
> this patch enable 2.5.51 kernel to build without sequencer support :
hmm, applying this is surely harmless but i still don't figure out
why this fixes the bug. synth/emux/Makefile is:
snd-emux-synth-objs := emux.o emux_synth.o emux_seq.o emux_nrpn.o \
emux_effect.o emux_proc.o soundfont.o
ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
snd-emux-synth-objs += emux_oss.o
endif
# Toplevel Module Dependency
ifeq ($(subst m,y,$(CONFIG_SND_SEQUENCER)),y)
obj-$(CONFIG_SND_SBAWE) += snd-emux-synth.o
obj-$(CONFIG_SND_EMU10K1) += snd-emux-synth.o
endif
and if $CONFIG_SND_SEQUENCER is n, snd-emux-synth.o will be never
compiled nor built-in...
Takashi
> [2 alsa-fix-compile.diff <text/x-patch (7bit)>]
> fix compiling without sequencer support
> --- ./sound/synth/Makefile.tv 2002-12-10 22:02:00.000000000 -0500
> +++ ./sound/synth/Makefile 2002-12-10 21:50:37.000000000 -0500
> @@ -12,8 +12,8 @@
> obj-$(CONFIG_SND_TRIDENT) += snd-util-mem.o
> ifeq ($(subst m,y,$(CONFIG_SND_SEQUENCER)),y)
> obj-$(CONFIG_SND_SBAWE) += snd-util-mem.o
> +obj-$(CONFIG_SND) += emux/
> endif
>
> -obj-$(CONFIG_SND) += emux/
>
> include $(TOPDIR)/Rules.make
-------------------------------------------------------
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: hostname forwarding
From: Rob Sterenborg @ 2002-12-11 15:43 UTC (permalink / raw)
To: 'bernard', netfilter
In-Reply-To: <FD8F124A387AD6119F7900A0D218B3215619EA@hslex01.hslbz.local>
> Now I want to redirect on a hostname basis on different private ip's
> like this :
>
> hostname A:80 -> public ip -> iptables -> 192.168.1.1:80
> hostname B:80 -> public ip -> iptables -> 192.168.1.2:80
>
> Does anyone know a solution ?
Iptables will only forward (resolved) IP adresses (and/or ports).
If Host-A has the same IP address as Host-B, then packets will be
forwarded to one and the same internet IP address.
You could accept http traffic on, let's say, port 81 and redirect
traffic for Host-B:81 to 192.168.1.2:80, but I don't think that's what
you want : people would have to type http://Host-B:81 to enter the site.
Rob
^ permalink raw reply
* Re: [Linux-fbdev-devel] Re: atyfb in 2.5.51
From: James Simmons @ 2002-12-11 15:46 UTC (permalink / raw)
To: Antonino Daplas
Cc: Benjamin Herrenschmidt, Paul Mackerras, Linux Kernel Mailing List,
Linux Fbdev development list
In-Reply-To: <1039610834.1084.106.camel@localhost.localdomain>
> Before, most drivers just unconditionally refresh the hardware at every
> switch during set_var(). I've been pointing this out for a long time
> now, do we unconditionally do a check_var()/set_par() after every
> console switch, or do we rely on fbdev and X cooperating with each
> other? Or better, maybe fbcon has a way of knowing if the switch came
> from Xfree86.
My next project is to fix this issue. I will be working on that today.
^ permalink raw reply
* Re: Is this going to be true ?
From: Måns Rullgård @ 2002-12-11 15:55 UTC (permalink / raw)
To: Herman Oosthuysen; +Cc: linux-kernel
In-Reply-To: <3DF6901A.7040309@WirelessNetworksInc.com>
Herman Oosthuysen <Herman@WirelessNetworksInc.com> writes:
> MS history shows that they did and does support various flavours of
> *nix. So, it is not beneath them to release apps for Linux too one
> day and it would be a good thing if they do.
Why would that be good? People would start using their programs and
blame Linux when they crash.
> Competition is always good. It inpires people to do better.
Doing better than MS isn't much of an inspiration to me.
--
Måns Rullgård
mru@users.sf.net
^ permalink raw reply
* Re: Linux 2.4.21-pre1
From: Ralf Hildebrandt @ 2002-12-11 15:56 UTC (permalink / raw)
To: lkml; +Cc: Alan Cox, Ralf Hildebrandt
In-Reply-To: <20021211153414.GQ8741@charite.de>
* Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>:
> According to the 2.4.20 kernel (see
> http://www.stahl.bau.tu-bs.de/~hildeb/kernel/2.4.20.jpg for a snapshot
> of the boot process!) the drives are:
>
> hda: TOSHIBA MK4019GAX, ATA DISK drive
> hdc: TOSHIBA DVD-ROM SD-R2102, ATAPI CD/DVD-ROM drive
>
> And the controller:
> ICH3M: chipset revision 2
More details (lspci -vv):
00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) (prog-if 8a [Master SecP PriP])
Subsystem: Toshiba America Info Systems: Unknown device 0001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at cff8 [size=8]
Region 1: I/O ports at cff4 [size=4]
Region 2: I/O ports at cfe8 [size=8]
Region 3: I/O ports at cfe4 [size=4]
Region 4: I/O ports at cfa0 [size=16]
Region 5: Memory at 10000000 (32-bit, non-prefetchable) [size=1K]
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt@charite.de
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
Why you can't find your system administrators:
The Cray's Chiller decided to go on vacation, and (S)he got stuck to one of the vents on the Y-MP after switching to air-cooled mode.
--Jeff Wolfe wolfe@ems.psu.edu
^ permalink raw reply
* Re: ALSA-drivers-writing howto updated
From: Takashi Iwai @ 2002-12-11 15:49 UTC (permalink / raw)
To: John S. Denker; +Cc: Patrick Shirkey, alsa-devel
In-Reply-To: <3DF66645.6090305@monmouth.com>
At Tue, 10 Dec 2002 17:10:13 -0500,
John S. Denker <jsd@monmouth.com> wrote:
>
> Patrick Shirkey wrote:
>
> > I have added a link to the documentation page now.
>
> I assume the page in question is:
> http://www.alsa-project.org/documentation.php3
>
> That is a useful page.
>
> Suggestion: Include that page, verbatim, in the
> distribution, in
> -- lib/doc/
> -- driver/alsa-kernel/Documentation/
> -- driver/doc/
patch please!
> (Why are the last two distinct???)
driver/doc is the location of documents for drivers existing only on
alsa-driver tree yet or of ones which still are not rewritten as
standard kernel documents.
> Also, please mention it (giving its online location
> AND its distributed-file locations) in
> -- driver/README
> -- driver/doc/README.1st
> -- lib/README
patch please! :)
ciao,
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: module-init-tools 0.9.3 -- "missing" issue
From: ALESSANDRO.SUARDI @ 2002-12-11 15:53 UTC (permalink / raw)
To: jt; +Cc: linux-kernel, rusty
Jean Tourrhiles wrote:
>
> Rusty Russell wrote :
> > In message <3DF67878.6090703@oracle.com> you write:
> > > to modprobe vfat - but not the full irda stack, I'll report this
> > > separately to Jean) _and_ on 2.4.20 (modular IrDA and PPP are
> >
> > I'd appreciate receiving a copy of that irda report. It's probably
> > not Jean's fault.
> I've just managed to load and run Linux-IrDA on 2.5.51, and
> apart from a few warning (see my other e-mail) it was working. I even
> tested PPP over IrCOMM. But I didn't check smc-ircc.
> So, this one might be *mine* ;-)
Yep, it's smc-ircc :)
Dec 10 22:57:36 dolphin kernel: IrCOMM protocol (Dag Brattli)
Dec 10 22:57:36 dolphin irattach: executing: '/sbin/modprobe irda0'
Dec 10 22:57:36 dolphin kernel: found SMC SuperIO Chip (devid=0x09 rev=08 base=0x03f0): FDC37N958FR
Dec 10 22:57:36 dolphin kernel: SMC IrDA Controller found
Dec 10 22:57:36 dolphin kernel: IrCC version 1.1, firport 0x290, sirport 0x3e8 dma=3, irq=4
Dec 10 22:57:36 dolphin irattach: + FATAL: Error inserting smc_ircc
(/lib/modules/2.5.51/kernel/smc-ircc.ko): No such device
Dec 10 22:57:36 dolphin irattach: Trying to load module irda0 exited with status 1
Dec 10 22:57:36 dolphin irattach: executing: 'echo 1 >
/proc/sys/net/irda/discovery'
Dec 10 22:57:36 dolphin irattach: Starting device irda0
Dec 10 22:57:36 dolphin kernel: Module irda cannot be unloaded due to unsafe usage in net/irda/af_irda.c:1146
Should I give up on it and go for Daniele's smsc-ircc2 ? I confess I hadn't
used 2.5.xx for a couple of weeks awaiting for some form of stabilization
of the new module code (don't blame me - I can only, ahem, "test" on
my work laptop), and I had forgot about smsc-ircc2.
Since it seems someone could make some of the modular stuff work
I'm back in the game :)
--alessandro
^ permalink raw reply
* Re: [PATCH] let 2.5.51 build
From: Thierry Vignaud @ 2002-12-11 15:51 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hlm2w7e8f.wl@alsa2.suse.de>
Takashi Iwai <tiwai@suse.de> writes:
> > this patch enable 2.5.51 kernel to build without sequencer support :
>
> hmm, applying this is surely harmless but i still don't figure out
> why this fixes the bug. synth/emux/Makefile is:
>
> snd-emux-synth-objs := emux.o emux_synth.o emux_seq.o emux_nrpn.o \
> emux_effect.o emux_proc.o soundfont.o
> ifeq ($(CONFIG_SND_SEQUENCER_OSS),y)
> snd-emux-synth-objs += emux_oss.o
> endif
>
> # Toplevel Module Dependency
> ifeq ($(subst m,y,$(CONFIG_SND_SEQUENCER)),y)
> obj-$(CONFIG_SND_SBAWE) += snd-emux-synth.o
> obj-$(CONFIG_SND_EMU10K1) += snd-emux-synth.o
> endif
>
> and if $CONFIG_SND_SEQUENCER is n, snd-emux-synth.o will be never
> compiled nor built-in...
hummmm. must be some sort of "too late in the night to compile a
kernel" workaround for a broken make rule (was not able to build
emux/built-in.o if i remember right)
so you can just discard this patch
-------------------------------------------------------
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: disallow normal users from bind()-ing to ports
From: David Garamond @ 2002-12-11 15:54 UTC (permalink / raw)
To: netfilter
In-Reply-To: <3DF6E339.3000403@icqmail.com>
David Garamond wrote:
> + there are certain IP aliases (say: 12.34.56.78 and 12.34.56.79) and of
> course 0.0.0.0 that should be able to be bind()-ed by normal users at all.
sorry, i meant "should not".
--
dave
^ permalink raw reply
* Re: PPTP+NAT+MASQ anyone?
From: Roy Sigurd Karlsbakk @ 2002-12-11 15:56 UTC (permalink / raw)
To: Martin Josefsson; +Cc: Netfilter mailinglist
In-Reply-To: <1039621206.20499.86.camel@tux>
On Wednesday 11 December 2002 16:40, Martin Josefsson wrote:
> On Wed, 2002-12-11 at 16:35, Roy Sigurd Karlsbakk wrote:
> > that's exactly what I'm doing. with kernel 2.4.19 and 2.4.20.
> > doesn't work
> > so.
> > can I just add the required patches manually without going for the whole
> > bunch?
> > if so - which ones do i need?
>
> You will at least need the newnat patch. (I hope the pptp patch doesn't
> depend on some other patch in there)
> But everything in the pending directory is recommended.
>
> then just apply the pptp patch.
>
> I can't see why this shouldn't work for you.
> You are sure you are using an up to date cvs checkout?
# rm -rf linux-2.4.19 && tar xzf packed/linux-2.4.19.tar.gz && \
cd netfilter/patch-o-matic && cvs update -Pd -D now && \
./runme pending && ./runme extra
Testing... ahesp-static.patch NOT APPLIED (1 rejects out of 1 hunks)
Testing... conntrack+nat-helper-unregister.patch NOT APPLIED (6 rejects out of
6 hunks)
Testing... ip6tables-exthdr-bug.patch.ipv6 NOT APPLIED (6 rejects out of 6
hunks)
etc
etc
etc
what am I doing wrong?
--
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
* Re: [ACPI] Re: [2.5.50, ACPI] link error
From: Alan Cox @ 2002-12-11 16:00 UTC (permalink / raw)
To: Ducrot Bruno
Cc: Andrew McGregor, Linux Kernel Mailing List, ACPI mailing list
In-Reply-To: <20021211101438.GC29390-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>
On Wed, 2002-12-11 at 10:14, Ducrot Bruno wrote:
> No. You are wrong. I need to suspend allmost all the drivers, and the
> video chipset is not an execption (or go to a console before suspending,
> in fact).
> You still need to bug NVIDIA in order to have proper pm support
> in their driver.
To an extent. However you can also switch back to text mode on suspend
to disk, then resume back into text mode and effectively switch back
into X11
^ permalink raw reply
* Re: PPTP+NAT+MASQ anyone?
From: Roy Sigurd Karlsbakk @ 2002-12-11 16:01 UTC (permalink / raw)
To: Martin Josefsson; +Cc: Netfilter mailinglist
In-Reply-To: <1039621206.20499.86.camel@tux>
On Wednesday 11 December 2002 16:40, Martin Josefsson wrote:
> On Wed, 2002-12-11 at 16:35, Roy Sigurd Karlsbakk wrote:
> > that's exactly what I'm doing. with kernel 2.4.19 and 2.4.20.
> > doesn't work
> > so.
> > can I just add the required patches manually without going for the whole
> > bunch?
> > if so - which ones do i need?
>
> You will at least need the newnat patch. (I hope the pptp patch doesn't
> depend on some other patch in there)
> But everything in the pending directory is recommended.
>
> then just apply the pptp patch.
>
> I can't see why this shouldn't work for you.
> You are sure you are using an up to date cvs checkout?
seems like newnat-udp-helper.patch
[root@fw linux]# patch -p1 <
../netfilter/patch-o-matic/pending/newnat-udp-helper.patch
patching file include/linux/netfilter_ipv4/ip_nat_helper.h
Hunk #1 succeeded at 36 (offset -14 lines).
patching file net/ipv4/netfilter/ip_nat_helper.c
Hunk #1 FAILED at 8.
Hunk #2 succeeded at 18 (offset -7 lines).
Hunk #3 succeeded at 53 (offset -2 lines).
Hunk #4 succeeded at 75 (offset -7 lines).
Hunk #5 succeeded at 174 (offset -2 lines).
Hunk #6 succeeded at 203 with fuzz 2 (offset -7 lines).
1 out of 6 hunks FAILED -- saving rejects to file
net/ipv4/netfilter/ip_nat_helper.c.rej
patching file net/ipv4/netfilter/ip_nat_standalone.c
Hunk #1 FAILED at 358.
1 out of 1 hunk FAILED -- saving rejects to file
net/ipv4/netfilter/ip_nat_standalone.c.rej
--
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
* Reliable hardware
From: Orion Poplawski @ 2002-12-11 16:08 UTC (permalink / raw)
To: scott; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <200212102000.54287.scott@thomasons.org>
scott thomason wrote:
>On Tuesday 10 December 2002 03:00 pm, Alan Cox wrote:
>
>
>>Random lockups on dual athlons are a notorious problem under all
>>OS's. Start by checking it passes memtest86, that will verify the
>>RAM is ok - and the AMD is -very- picky about RAM.
>>
>>If thats ok then let me know which board you have, what is plugged
>>into it and what PSU you are using.
>>
>>
>
>I have two AMD MP 2000+ cpus in an ASUS A7M266-D. Even after returning
>my memory for new chips the store owner memtest86'd, my combo of cpus
>and mobo was finding the occasional error. I finally ended up
>resolving it by simply underclocking the bus about 6Mhz :(
>
>Next time, I'm buying ECC memory.
>---scott
>
>
Is there a good site for pointers towards assembling reliable Linux
machines? It seems to me the trickiest part of the whole operation is
choosing good hardware in the first place. I just started a new job and
inherited a buch of new but flakey machines, and I'd like to avoid doing
that in the future.
^ permalink raw reply
* Re: Oops on linux 2.4.20-ac1
From: Orion Poplawski @ 2002-12-11 16:10 UTC (permalink / raw)
To: scott; +Cc: Linux Kernel Mailing List
In-Reply-To: <200212102000.54287.scott@thomasons.org>
scott thomason wrote:
>I have two AMD MP 2000+ cpus in an ASUS A7M266-D. Even after returning
>my memory for new chips the store owner memtest86'd, my combo of cpus
>and mobo was finding the occasional error. I finally ended up
>resolving it by simply underclocking the bus about 6Mhz :(
>
>Next time, I'm buying ECC memory.
>---scott
>
>
Underclocking has been my "solution" to these lockups as well. Would
ECC memory actually help in this case though?
^ permalink raw reply
* Re: 2.5.51 -- rivafb is whacky (characters flipped on vertical axis, 640x480 usable area shown inside a higher-res area, etc).
From: Miles Lane @ 2002-12-11 16:05 UTC (permalink / raw)
To: Antonino Daplas; +Cc: James Simmons, Linux Fbdev development list
In-Reply-To: <1039610250.1147.95.camel@localhost.localdomain>
On Wed, 2002-12-11 at 04:49, Antonino Daplas wrote:
> On Wed, 2002-12-11 at 05:39, Miles Lane wrote:
> > Hi,
> >
> > I have tried getting rivafb to work in 2.5.51. It is much better
> > than before (thanks!). It compiles and sorta works.
> >
> > Here are the problems:
> >
> > When I run "fbset -a 640x480", I get display that fills
> > the screen and looks okay, but most of the characters are
> > flipped along the vertical axis, so they are backwards, so that:
> >
> > +---- ----+
> > | |
> > +--- becomes ---+
> > | |
> > | |
> >
> What's the hardware, is it on a big endian machine? I think there's a
> typo there (__BIG_ENDIAN__ instead of __BIG_ENDIAN). This should
> produce the "mirroring" effect.
CPU: AMD Athlon(tm) Processor stepping 01
00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-751 [Irongate]
System Controller (rev 25)
01:05.0 VGA compatible controller: nVidia Corporation NV10 [GeForce 256
DDR] (rev 10) (prog-if 00 [VGA])
Subsystem: VISIONTEK: Unknown device 000b
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at fd000000 (32-bit, non-prefetchable)
[size=16M]
Region 1: Memory at e8000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at feaf0000 [disabled] [size=64K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
> Secondly, a lot of the changes there are for riva128, which may not
> apply for all cards. Try doing fbset -accel false/true and see if
> there's any effect. Or open linux/video/drivers/riva/fbdev.c, line 277
> and comment out the line with the FB_ACCELF_TEXT. This should force the
> hardware to do everything in software.
Thanks, I'll check this today.
Miles
-------------------------------------------------------
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
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.