* [U-Boot-Users] questions regarding support for new command (getspr/setspr)
From: Kumar Gala @ 2004-01-28 5:43 UTC (permalink / raw)
To: u-boot
I was wondering if it was considered useful to extend the
CFG_CMD_SETGETDCR done by Erik Theisen for DCR registers on the 4xx
family to all PowerPC products for SPRs (CFG_CMD_SETGETSPR).
This is rather simple but can be a useful command.
If, so I had a few questions:
1. Is it ok that the command does not do any checking on the SPR
number. This is quick difficult and would have to be done per
processor since what SPRs exists is implementation specific. If the
user gives the commands an SPR that does not exist the result is going
to be some exception (is this ok)
2. What numerical format should the spr number for the command be taken
in? My think is decimal
3. For setspr what numerical format should the spr value be taken in?
My thinking is hex
4. For getspr what numerical format should the spr be printed in? My
thinking is hex
If so, I will fixup my working patch and submit it once I get answers
to the questions.
thanks
- kumar
^ permalink raw reply
* [ALSA - driver 0000007]: alsa-kernel/pci does NOT contain bt87x driver
From: noreply @ 2004-01-28 5:46 UTC (permalink / raw)
To: alsa-devel
A BUGNOTE has been added to this bug.
======================================================================
http://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000007
======================================================================
Reporter: yahoo
Handler:
======================================================================
Project: ALSA - driver
Bug ID: 7
Category: OTHERS
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 01-28-2004 05:01 CET
Last Modified: 01-28-2004 06:46 CET
======================================================================
Summary: alsa-kernel/pci does NOT contain bt87x driver
Description:
alsa-kernel/pci does NOT contain bt87x driver it is however
present in alsa-driver/pci.
======================================================================
----------------------------------------------------------------------
alexzapatka - 01-28-2004 06:46 CET
----------------------------------------------------------------------
got tired of having to compile the kernel then recompile ALSA just for this
driver, so here is a quick patch to add it. one file contains the latest
ALSA bk patch from the ftp.alsa-project.org site
(alsa-bk-2004-01-25-plus-bt87x-audio.patch.bz2), the other is just the
patch that assumes you have ALREADY installed the latest bkpatch from the
site (alsa-bt87x-audio.patch.bz2), it probably wont work unless you have
2.6's alsa upgraded to 1.0.1 atleast, but who knows?
Bug History
Date Modified Username Field Change
======================================================================
01-28-04 05:01 yahoo New Bug
01-28-04 06:43 alexzapatka File Added: alsa-bk-2004-01-25-plus-bt87x-audio.patch.bz2
01-28-04 06:43 alexzapatka File Added: alsa-bt87x-audio.patch.bz2
01-28-04 06:46 alexzapatka Bugnote Added: 0000011
======================================================================
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* RE: forwarding traffic from one port to another on the same box
From: Mark E. Donaldson @ 2004-01-28 5:49 UTC (permalink / raw)
To: 'Andrew', netfilter
In-Reply-To: <bv779t$mo0$1@sea.gmane.org>
Andrew - your DNAT rule looks fine to me and it should work. I really
think your problem is the first rule, even though the error is apparently
charged to the second rule. I think what you need to do is change the first
rule to -A to the INPUT chain and not the forward chain and it should work.
The packet is not being forwarded, but is rather destined to the same NIC -
so it should be the INPUT chain. Try that and see if it does the trick. If
not, holler again cause there are many with greater expertise on this list
than me.
-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Andrew
Sent: Tuesday, January 27, 2004 6:38 PM
To: netfilter@lists.netfilter.org
Subject: forwarding traffic from one port to another on the same box
I would like to forward all tcp traffic arriving on a particular port to
another port on the same machine. This has worked for me in the past but I
can't get it working on my current machine.
Here are the two commands I'm using to try to create the forward.
iptables -I FORWARD -p tcp -d 192.168.10.34 --dport 26 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -i eth0 -s 0/0 -d 192.168.10.34 --dport
26 -j DNAT --to 192.168.10.34:25
The first command is accepted but the second command results in an 'Invalid
argument' error.
The computer has only one interface, eth0. Here are its particulars:
Mandrake Linux 9.2
Iptables 1.2.8
kernel 2.4.24 patched with super-freeswan 1.99.8
The value of /proc/sys/net/ipv4/conf/eth0/forwarding is 0. Changing it to 1
has no impact.
The value of /proc/sys/net/ipv4/conf/eth0/rp_filter is 0.
I hope someone out there has some ideas about what's going on because I'm
all out.
Andrew
^ permalink raw reply
* [ALSA - driver 0000007]: alsa-kernel/pci does NOT contain bt87x driver
From: noreply @ 2004-01-28 5:52 UTC (permalink / raw)
To: alsa-devel
A BUGNOTE has been added to this bug.
======================================================================
http://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000007
======================================================================
Reporter: yahoo
Handler:
======================================================================
Project: ALSA - driver
Bug ID: 7
Category: OTHERS
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 01-28-2004 05:01 CET
Last Modified: 01-28-2004 06:52 CET
======================================================================
Summary: alsa-kernel/pci does NOT contain bt87x driver
Description:
alsa-kernel/pci does NOT contain bt87x driver it is however
present in alsa-driver/pci.
======================================================================
----------------------------------------------------------------------
alexzapatka - 01-28-2004 06:46 CET
----------------------------------------------------------------------
got tired of having to compile the kernel then recompile ALSA just for this
driver, so here is a quick patch to add it. one file contains the latest
ALSA bk patch from the ftp.alsa-project.org site
(alsa-bk-2004-01-25-plus-bt87x-audio.patch.bz2), the other is just the
patch that assumes you have ALREADY installed the latest bkpatch from the
site (alsa-bt87x-audio.patch.bz2), it probably wont work unless you have
2.6's alsa upgraded to 1.0.1 atleast, but who knows?
----------------------------------------------------------------------
alexzapatka - 01-28-2004 06:52 CET
----------------------------------------------------------------------
sorry... get the ones marked "new"... typo in the last ones...
Bug History
Date Modified Username Field Change
======================================================================
01-28-04 05:01 yahoo New Bug
01-28-04 06:43 alexzapatka File Added: alsa-bk-2004-01-25-plus-bt87x-audio.patch.bz2
01-28-04 06:43 alexzapatka File Added: alsa-bt87x-audio.patch.bz2
01-28-04 06:46 alexzapatka Bugnote Added: 0000011
01-28-04 06:52 alexzapatka Bugnote Added: 0000012
======================================================================
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: [uml-devel] Re: more on COW (long)
From: Dan Shearer @ 2004-01-28 5:55 UTC (permalink / raw)
To: Jeff Dike; +Cc: James W McMechan, user-mode-linux-devel
In-Reply-To: <200401280518.i0S5IOZw005580@ccure.user-mode-linux.org>
On Wed, Jan 28, 2004 at 12:18:24AM -0500, Jeff Dike wrote:
> mcmechanjw@juno.com said:
> > Well yes, I want to be able to read real disk images either from a raw
> > device, yes we could stick in a special case ioctl to check for a real
> > device and read its geometry but ick it is easier to specify it, or
> > from a dd'ed image file of a hard disk which would not work even with
> > the ioctl, so ubd1C102H15S16 is better from my view :)
>
> OK, build it and maybe people will come :-)
Yep. I work with many different simulation environments and this is a
*really* useful option. Apart from anything else real sectors are a kind
of semi-universal file format between simulation environments. But there
is also the case where you dd from a running system for purposes such as
planning preventative maintenance, disaster recovery, forensics,
security testing to mention a few. Not too many of the open source
simulators do this but many of the closed source ones do.
--
Dan Shearer
dan@shearer.org
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for
From: David Mosberger @ 2004-01-28 6:06 UTC (permalink / raw)
To: Paul Mackerras
Cc: davidm, Andrew Morton, Jes Sorensen, linux-kernel, linux-ia64
In-Reply-To: <16406.63734.400759.452955@cargo.ozlabs.ibm.com>
>>>>> On Wed, 28 Jan 2004 10:49:10 +1100, Paul Mackerras <paulus@samba.org> said:
Paul> I really don't like the uglification of lib/extable.c.
I disagree about this being an uglification. But beauty is obviously
in the eye of the beholder...
Anyhow, you clearly feel _much_ stronger about this particular issue
than I do and I haven't heard much from Andrew, so I'll make a local
version of sort_extable() for now. If someone cares about
resurrecting a generic version, they can do that later on.
--david
^ permalink raw reply
* Re: [patch] 2.6.1-mm5 compile do not use shared extable code for ia64
From: David Mosberger @ 2004-01-28 6:06 UTC (permalink / raw)
To: Paul Mackerras
Cc: davidm, Andrew Morton, Jes Sorensen, linux-kernel, linux-ia64
In-Reply-To: <16406.63734.400759.452955@cargo.ozlabs.ibm.com>
>>>>> On Wed, 28 Jan 2004 10:49:10 +1100, Paul Mackerras <paulus@samba.org> said:
Paul> I really don't like the uglification of lib/extable.c.
I disagree about this being an uglification. But beauty is obviously
in the eye of the beholder...
Anyhow, you clearly feel _much_ stronger about this particular issue
than I do and I haven't heard much from Andrew, so I'll make a local
version of sort_extable() for now. If someone cares about
resurrecting a generic version, they can do that later on.
--david
^ permalink raw reply
* IDE status timeout
From: Xupei Liang @ 2004-01-28 6:13 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I have a customed board that is running Linux 2.4.19
and XFS and that has a compactFlash card. The
compactFlash card is running in true IDE mode. I ran
into the following error once in a while. It is very
difficult to reproduce.
>hda: status timeout: status=0xd0 { Busy }
>hda: no DRQ after issuing WRITE
>ide0: reset timed-out, status=0x80
>hda: status timeout: status=0x80 { Busy }
>hda: drive not ready for command
>ide0: reset timed-out, status=0x80
>end_request: I/O error, dev 03:02 (hda), sector 71472
>end_request: I/O error, dev 03:02 (hda), sector 71480
>end_request: I/O error, dev 03:02 (hda), sector 77264
>end_request: I/O error, dev 03:02 (hda), sector 77272
>end_request: I/O error, dev 03:02 (hda), sector
115537
>I/O error in filesystem ("ide0(3,2)") meta-data dev
0x302 block 0x1c351
>
I read some discussions on a similar (or same?)
problem in another forum.
http://www.ussg.iu.edu/hypermail/linux/kernel/0312.3/index.html#1111
But my problem seems to be different because even a
soft reset can not reset the card and the problem
happens very randomly. The compactFlash card seems to
be stuck. Has anybody seen this problem before?
Thank you in advanced for your input.
Regards,
Terry Liang
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: JFFS2 case insensitivity
From: David Woodhouse @ 2004-01-28 6:13 UTC (permalink / raw)
To: manningc2; +Cc: MTD List, Jarkko Lavinen
In-Reply-To: <20040127224134.9F91515D43@desire.actrix.co.nz>
On Wed, 2004-01-28 at 11:49 +1300, Charles Manning wrote:
> On Wednesday 28 January 2004 04:18, David Woodhouse wrote:
> > I _really_ don't want to have the JFFS2 code play with character
> > sets and know that û is really the same as �, etc. And don't get
> > me started on Ŵ and ŵ :)
Quod Erat Demonstrandum. :)
--
dwmw2
^ permalink raw reply
* Re: [2.0.40-rc8] Works well
From: Markus Hästbacka @ 2004-01-28 6:13 UTC (permalink / raw)
To: David Weinehall; +Cc: Coywolf Qi Hunt, Kernel Mailinglist
In-Reply-To: <20040128033755.GC16675@khan.acc.umu.se>
On Wed, 28 Jan 2004, David Weinehall wrote:
> On Wed, Jan 28, 2004 at 03:28:30AM +0000, Coywolf Qi Hunt wrote:
> ...
> > Recently I just have such an idea that is to port the 2.0.39 to let it
> > be compiled with my gcc 2.95.4 or any
> > other latest gcc. At the same time, also make it remain compliant to
> > gcc 2.7.2.1. ( I can't find 2.7.2.1, only 2.7.2.3
> > on the ftp) Is this work worth while?
>
> Well, for sure it's quite a demanding task, since, if I remember
> correctly, the module-code uses some nasty internal gcc-knowledge to
> generate code, that simply doesn't work with later versions of gcc.
> It might be that I remember this incorrectly though.
>
only the module-code? :)
> It would be interesting, yes, but only if it can be proved to some
> degree that no new bugs are introduced.
>
That would probably be impossible to do without introducing any bugs..
> My aim for 2.0.41 is to make it a cleanup-release; remove warnings, tidy
> up a little source-code mess, kill dead code, fix typos etc.
>
Sounds great, a bit amazing that 2.0 is alive again :)
Markus
^ permalink raw reply
* cs46xx capture dropout on busy systems
From: Perry Scott @ 2004-01-28 6:14 UTC (permalink / raw)
To: alsa-devel
[2.4.23]
I've been chasing a capture dropout in the old OSS cs46xx driver
(drivers/sound/cs46xx.c) for the past two months (evenings and weekends),
and I finally nailed it. I looked over at the ALSA driver, and I think I
see the same problem there as well. I traced the peek/poke(PD1_CBA) from
the update_ptr routine to the read routine, so I'm pretty confident the bug
is there.
Briefly, I'm doing 8-channel recording, using 4 TB Santa Cruz
cards. Occasionally, one of the cards loses a chunk of data. I traced the
problem to the 4k dma buffer size. The IRQ updates the capture pointer,
but it only has a 1/44th second real-time latency before it loses data. If
the read doesn't get reposted by the application within that time, data
will be lost. All it really takes is a busy system - either an IRQ from
another card, or another thread getting in the way.
I fixed the problem in the OSS driver by copying the 4k ping-pong into a
larger buffer, which is then drained by read(). Essentially, I implemented
the Scatter/Gather in the ISR. It's not pretty, but it
works. (Incidentally, if anyone has found the Cirrus documentation on
cs46xx capture S/G, I'd be most appreciative. The only document I found in
the ALSA documentation archive glibly said that S/G is "complicated" and
that 1/44th second should be OK - yeah, right.)
This problem is likely to affect *any* sound card with a 4k dma
ping-pong. I'm not sure if the cs46xx is the only pathological case out
there, but I wouldn't be surprised if there are others. The really
disturbing thought is that ALSA itself has real-time issues because 4k is a
common dma size (say it isn't so!)
I'm a couple weeks away from porting my application to ALSA, so if someone
else wants to load up a bunch of sound cards, feel free. I'm finding the
bug injecting a sine wave into the four cards, then looking for large
deltas from one sample to the next.
Comments?
Perry Scott
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: [LARTC] tncg and bandwidth limiting
From: Martin A. Brown @ 2004-01-28 6:18 UTC (permalink / raw)
To: lartc
In-Reply-To: <5.2.0.9.0.20040127150331.00ac7bd0@mail.web-ster.com>
Scott,
: Basically ignore that last message.
Earlier message ignored.
: I'm trying to do some very simple rate-shaping on an interface. I want
: to limit my 100baseT interface to 7 megs both ingress and egress of the
: interface.
You'll notice that Rubens suggested you use a TBF. This would be
perfectly adequate solution for your transmitted traffic. Note that an
HTB class and a TBF qdisc are essentially performing the same function.
Shaping!
Note there is a difference in the traffic control structures created by
your tcng configuration. Your egress section will actually be two HTB
classes inside an HTB qdisc attached to the INTERFACE in question. In
your situation, you do not need both classes (created as siblings), since
you are classifying everything into class $all.
: I'm curious if some of the other experts out there wouldn't have a
: "better" way to do what I'm doing. I'd like to do HTB ingress as well,
: but it complains that the the ingress qdisc doesn't allow inside
: classes or something like that. I think this will work for me, I just
: want to make sure this is the best way to do things.
This is a limitation of traffic control under Linux. You can only shape
what you transmit [ see IMQ if you want to know how to break this rule ].
So, unless you are going to use IMQ, you'll not be able to shape your
local input traffic (if you are a router, you should be able to slow down
conversations by "artificially" delaying the packets on the internal
interface).
However, you don't need to care that you are not shaping on your inbound
traffic. You can police the traffic. For the difference between shaping
and policing, try here [0].
[ snip ]
: htb () {
: class ( rate 100Mbps, ceil 100Mbps ) ; /* remove this */
: $all = class ( rate 7Mbps, ceil 7Mbps ) ;
: }
: ingress {
: $p = bucket(rate 7Mbps, burst 100kB, mpu 200B);
: class (1) if (conform $p && count $p) || drop;
: }
After you run your tcng config file through tcc ("tcc < $FILE | less"),
you should see (lines broken for readability) the following for the
ingress traffic control. I left INTERFACE in the config file--obviously
you have #defined it someplace else.
tc qdisc add dev INTERFACE ingress
tc filter add dev INTERFACE parent ffff:0 protocol all prio 1 \
u32 match u32 0x0 0x0 at 0 classid ffff:1 \
police index 2 rate 875000bps burst 102400 mpu 200 action drop/pass
^^^^^^
Note that the policer will (somewhat harshly) accommodate your desires to
limit the traffic accepted inbound on an interface.
Best of luck,
-Martin
[0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/elements.html#e-shaping
http://tldp.org/HOWTO/Traffic-Control-HOWTO/elements.html#e-policing
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [PATCH|RFC] IPv6 netfilter: a module for complete proxy ND support
From: Pekka Savola @ 2004-01-28 6:39 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: netdev
In-Reply-To: <20040128.084601.13486645.yoshfuji@linux-ipv6.org>
On Wed, 28 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] ^[$B5HF#1QL@^[(B wrote:
> On performance issue: as IPv4, we may want to have
> net.ipv6.conf.<if>.proxy_ndisc sysctl.
IPv4 proxy_arp is different. It's the way of configuring automatic
proxy ARP. No such thing exists for IPv6 at the moment, so when we
implement ND proxying, it would probably be the place to toggle it on
and off. So I see little need for a sysctl toggle to switch this on
and off, as the addresses to be proxied are currently manually
configured anyway.
> We may also want to have another configuration
> option (to enable proxy) bacause not all routers require this
> feature.
I'm not sure whether this is called for, for a small piece of code
like this. We need fewer configuration options, not more! :-)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
^ permalink raw reply
* [LARTC] IProute and Traffic Control of PPC
From: David Bierce @ 2004-01-28 6:46 UTC (permalink / raw)
To: lartc
Has any one ever done it? We are in the planning stages and the
majority of the hardware we have available is PPC, what are some
thoughts?
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [LARTC] Shaping Device Aliases
From: Martin A. Brown @ 2004-01-28 6:54 UTC (permalink / raw)
To: lartc
In-Reply-To: <200401151118.04852.gordan@bobich.net>
Gordan,
I've noticed that you are trying to use aliased IP addresses and traffic
control together, and you are a bit frustrated that tc doesn't handle
aliased interface names.
: > > I understand that device aliases (e.g. eth2:3) are not shapeable.
: > > Does anybody know if this functionality is planned in the future?
: >
: > None of the new(er) networking tools recognise device aliases,
: > because on all recent linux releases, aliases don't exist.
: > the ethX:X notation is a legacy notation used only by the ifconfig
: > program. everything else just sees a ethX with more than one IP
: > address.
: >
: > So you just run your shaping rules on the real interfaces, and
: > restrict it's operation with IP address filtering.
:
: Yes, I am aware of that. However, that makes shaping multiple
: independent "streams" going through one interface much more difficult.
I don't understand why this becomes much more difficult--it just becomes a
little more difficult, depending on the number of IP addresses you have
active on a given interface. If you can handle multiple addresses on an
interface, then shaping traffic on these (known) addresses shouldn't be
much more difficult than managing each address.
: The only other thing I can think of is setting up a dummy network
: device and giving it the IP addresses on all the non-primary subnets
: (e.g. multiple DSL lines), and setting up the arp and routing to make
: the packet actually go via the primary interface.
This sounds like a very confused idea. I'm not sure it's worth the
hassle--as I hope I can convince you below.
[ more stuff snipped ]
: Has anybody got any thoughts on this?
I have some thoughts, which I hope can help you understand why you will be
able to use the traffic control tools to accomplish your filtering. For
posterity, I'll reiterate some of what has come before.
IP aliases don't exist. This is a convention for ifconfig. "ip addr
show" will display all IP addresses active on a given interface.
Traffic control is the last thing performed before turning the packet over
to the device driver and hardware. Similarly, it is the first thing
called on receipt of a packet. See diagrams KPTD [0] and ebtables packet
flow [1].
In this case, you can use any number of techniques to identify the packets
with tc tools based on their IP addresses--the convenience of the aliased
interface naming is simply an obstruction of the real path the packet
takes.
: If this would work, maybe it should be documented in the advanced
: routing howto, as I can see how there might be a lot of people out
: there who would find it useful.
Let me suggest a possibility, if we assume a nested configuration. Let's
say you have IP0 and IP1 active on interface eth3 and you want to make
sure that bandwidth is split 75/25 between these two and you want them to
share bandwidth. Classic bandwidth-sharing situation....in the tcng
config below, you'd need to #define IP0 and IP1, but then you'd have a
simple configuration. If you needed to further subdivide traffic within
each of the IP0 and IP1 classes, you'd have an easy way to do so.
dev eth0 {
egress {
class ( <$ip0> ) if ip_src = IP0 ;
class ( <$ip1> ) if ip_src = IP1 ;
htb () {
class ( rate 1544kbps, ceil 1544kbps ) { /* T1 speed */
$ip0 = class ( rate 1024kbps, ceil 1544kbps ) ;
$ip1 = class ( rate 384kbps, ceil 1544kbps ) ;
}
}
}
}
Alternately, you may wish to simulate virtual circuits with each of the IP
addresses on a machine. In this case, you could use separate root
classes attached to the HTB qdisc, or another class. You can prevent the
two classes from competing with each other by setting the rate and ceil to
the same value. Here's a very simple permutation of the above.
dev eth0 {
egress {
class ( <$ip0> ) if ip_src = IP0 ;
class ( <$ip1> ) if ip_src = IP1 ;
htb () {
class ( rate 1544kbps, ceil 1544kbps ) { /* T1 speed */
$ip0 = class ( rate 1024kbps, ceil 1024kbps ) ;
$ip1 = class ( rate 384kbps, ceil 384kbps ) ;
}
}
}
}
Best of luck, Gordan!
-Martin
[0] http://www.docum.org/stef.coene/qos/kptd/
[1] http://ebtables.sourceforge.net/br_fw_ia/PacketFlow.png
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Lost characters on serial console
From: Detlef Schmicker @ 2004-01-28 6:55 UTC (permalink / raw)
To: linux-kernel
Hello,
we loose characters on the serial consol during receiving at 115kbaud.
Especially if
the ide harddisk is used during reception.
We use a 300MHz Goede MediaGX, with a 16550A serial port (16 byte FIFO). We
tuned the Harddisk with hdparm, which reduced the problem, but it still
exists.
We tried several Kernels: 2.4.4, 2.4.20, 2.4.24 and 2.6.0 and several
patches "preempt" and "low-lattency".
No changes at all.
We used ext2 and ReiserFS file system.
There were some messages on this problem in the mailing list, but they
are years old and we did not find
real hints, how to solve.
Can anybody help, can we help with debugging, testing?
Thanks a lot
Detlef Schmicker
^ permalink raw reply
* [ALSA - driver 0000005]: alsa-driver-1.0.2: unresolved symbols in snd.o
From: noreply @ 2004-01-28 6:57 UTC (permalink / raw)
To: alsa-devel
The following bug has been CLOSED
======================================================================
http://bugtrack.alsa-project.org/alsa-bug/bug_view_advanced_page.php?bug_id=0000005
======================================================================
Reporter: ZlatkO
Handler: perex
======================================================================
Project: ALSA - driver
Bug ID: 5
Category: 0_compilation problem_!!!
Reproducibility: always
Severity: block
Priority: immediate
Status: closed
Distribution: Slackware 8.1
Kernel Version: 2.4.24
======================================================================
Date Submitted: 01-27-2004 21:31 CET
Last Modified: 01-28-2004 07:57 CET
======================================================================
Summary: alsa-driver-1.0.2: unresolved symbols in snd.o
Description:
snd.o fails to load due to an unresolved symbol ("sound_class") on a
Slackware 8.1 system, kernel 2.4.24 (plain vanilla from kernel.org),
modutils-2.4.16.
There is no "sound_class" in the kernel's own
/usr/src/linux-2.4.24/drivers/sound/sound_core.c - am I supposed to
replace it with alsa-kernel/sound_core.c? This was not necessary in
previous ALSA versions.
======================================================================
----------------------------------------------------------------------
perex - 01-27-2004 22:08 CET
----------------------------------------------------------------------
I cannot reproduce this bug, but it might be possible that removing
of line 'extern struct class_simple *sound_class;' in
alsa-driver/alsa-kernel/core/sound.c solves this bug.
Can you confirm?
I've recreated new alsa-driver package with date:
Jan 27 22:02 alsa-driver-1.0.2.tar.bz2
----------------------------------------------------------------------
khali - 01-27-2004 22:18 CET
----------------------------------------------------------------------
Doesn't work for me. Even worse, alsa-driver doesn't compile anymore after
I commented the line out:
sound.c: In function `snd_register_device_R1f4c5f07':
sound.c:239: `sound_class' undeclared (first use in this function)
sound.c:239: (Each undeclared identifier is reported only once
sound.c:239: for each function it appears in.)
sound.c: In function `alsa_sound_init':
sound.c:376: `sound_class' undeclared (first use in this function)
sound.c: At top level:
sound.c:41: warning: `device_mode' defined but not used
make[1]: *** [sound.o] Error 1
make[1]: Leaving directory `/usr/src/alsa-driver-1.0.2/acore'
make: *** [compile] Error 1
----------------------------------------------------------------------
perex - 01-27-2004 22:39 CET
----------------------------------------------------------------------
Ok, can you add '#define sound_class NULL' after removing of suggested line
(on the same place)? Note that the rebuilt alsa-driver package has this
fix included.
edited on: 01-27-04 22:39
----------------------------------------------------------------------
khali - 01-27-2004 22:48 CET
----------------------------------------------------------------------
OK, works fine for me.
Thanks.
----------------------------------------------------------------------
ZlatkO - 01-27-2004 22:48 CET
----------------------------------------------------------------------
Works fine here after the second fix (same problem after the first one).
Thanks! :-)
----------------------------------------------------------------------
perex - 01-28-2004 07:57 CET
----------------------------------------------------------------------
Please, get the alsa-driver package v1.0.2 again from the ALSA FTP site, if
you encouter the same problem.
Bug History
Date Modified Username Field Change
======================================================================
01-27-04 21:31 ZlatkO New Bug
01-27-04 22:08 perex Bugnote Added: 0000005
01-27-04 22:08 perex Assigned To => perex
01-27-04 22:08 perex Status new => assigned
01-27-04 22:08 perex Priority normal => immediate
01-27-04 22:15 perex Category CORE - control => 0_compilation problem_!!!
01-27-04 22:18 khali Bugnote Added: 0000007
01-27-04 22:37 perex Bugnote Added: 0000008
01-27-04 22:39 perex Bugnote Edited: 0000008
01-27-04 22:48 khali Bugnote Added: 0000009
01-27-04 22:48 ZlatkO Bugnote Added: 0000010
01-28-04 07:57 perex Bugnote Added: 0000013
01-28-04 07:57 perex Status assigned => closed
======================================================================
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: NFS rpc and stale handles on 2.6.x servers
From: Mike Fedyk @ 2004-01-28 6:57 UTC (permalink / raw)
To: hanasaki; +Cc: linux-kernel
In-Reply-To: <40145E3A.5050704@hanaden.com>
On Sun, Jan 25, 2004 at 06:24:26PM -0600, hanasaki wrote:
> The below is being reported, on and off, when hitting nfs-kernel-servers
> running on 2.6.0 and 2.6.1 Could someone tell me if this is smoe bug or
> what? Thanks
> RPC request reserved 0 but used 124
>
> Debian sarge
> nfs-kernel-server
> am-untils
> nfsv3 over tcp
I get this also, and the comments in the code suggest that it is a bug.
Asking Niel and Trond will help getting this answered...
^ permalink raw reply
* [Bluez-users] SuSE and Audio
From: Jérôme Stadelmann @ 2004-01-28 6:58 UTC (permalink / raw)
To: bluez-users
Hello everybody
I'm actually a nb with linux, but I have to develop an application with =
some
audio bluetooth transmission. Actually I have a SuSE 9.0 distribution.
Marcel (Holtmann) said that I have to patch my kernel, but his patch =
doesn't
work with the SuSE kernel source. And I don't know how to do it easily
without having to configure all my computer.
Please, can somebody help me or give me a hint?
Thanks
Jerome
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply
* Re: virus warning
From: Babar Kazmi @ 2004-01-28 7:02 UTC (permalink / raw)
To: alexis, netfilter
Dear
We all will know on 1st Feb as the trigger starts :)
Any how lets the keep the fingers crossed and hold tight the input policy ..
Regards
Babar Kazmi.
>
>In this case, we are protected !!!!!
>
>We are all using a firewall with netfilter and input policy drop
>
>:))))
>
>
>
>----- Original Message -----
>From: "Fritz Mesedilla"
>To: "Netfilter Mailing List (E-mail)"
>Sent: Tuesday, January 27, 2004 4:30 AM
>Subject: RE: virus warning
>
>
>
>I forgot to send the details.
>
>
>W32.Novarg.A@mm is a mass-mailing worm. The worm will arrive as an
>attachment with a file extension of .bat, .cmd, .exe, .pif, .scr, or .zip.
>
>When the machine gets infected, the worm will set up a backdoor into the
>system by opening TCP ports 3127 thru 3198. This will potentially allow a
>hacker to connect to the machine and utilize it as a proxy to gain access
to
>it's network resources. In addition, the backdoor has the ability to
>download and execute arbitrary files.
>
>The worm will perform a DoS starting on February 1, 2004. On February 12,
>2004 the worm has a trigger date to stop spreading.
>
>
>http://securityresponse.symantec.com/avcenter/venc/data/w32.novarg.a@mm.htm
l
>
>
>
>Cheers,
>
>fritz
>---
>+ Basta Ikaw Lord
>
>
>
>
>-----Original Message-----
>From:
>Sent: Tuesday, January 27, 2004 2:45 PM
>To: Netfilter Mailing List (E-mail)
>Subject: Re: virus warning
>
>
>
>Obviously this is a really new one ... F-prot didn't catch it .. and mines
>up to date ...
>However ... since kmail and linux don't much like 7 bit mime ... *grin*
>
>I'm handing this one up to the folks at F-Prot to see why they didn't catch
>it...
>
>
>Alistair.
>
>On January 27, 2004 12:44 am, Fritz Mesedilla wrote:
> > friends,
> >
> > we got a virus in our list.
> > clamav warned me about it.
> > it's now spreading like fire even on other lists.
> >
> > thought you might like to be warned.
> >
> >
> > Cheers,
> >
> > fritz
> > ---
> > + Basta Ikaw Lord
> >
> >
> >
> >
> > ----------------------------------------------------------------------
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed. If you have received this email in error please notify
> > the sender immediately by e-mail and delete this e-mail from your
> > system. Please note that any views or opinions presented in this
> > email are solely those of the author and do not necessarily represent
> > those of the company. Finally, the recipient should check this email
> > and any attachments for the presence of viruses. The company accepts
> > no liability for any damage caused by any virus transmitted by this
> > email.
> >
> > Overture Media, Inc.
> > Direct Line: (632) 635-4785
> > Trunkline: (632) 631-8971 Local 146
> > Fax: (632) 637-2206
> > Level 1 Summit Media Offices, Robinsons Galleria EDSA Cor. Ortigas Ave.,
> > Quezon City 1100
>
>
>----------------------------------------------------------------------
>This email and any files transmitted with it are confidential and
>intended solely for the use of the individual or entity to whom they
>are addressed. If you have received this email in error please notify
>the sender immediately by e-mail and delete this e-mail from your
>system. Please note that any views or opinions presented in this
>email are solely those of the author and do not necessarily represent
>those of the company. Finally, the recipient should check this email
>and any attachments for the presence of viruses. The company accepts
>no liability for any damage caused by any virus transmitted by this
>email.
>
>Overture Media, Inc.
>Direct Line: (632) 635-4785
>Trunkline: (632) 631-8971 Local 146
>Fax: (632) 637-2206
>Level 1 Summit Media Offices, Robinsons Galleria EDSA Cor. Ortigas Ave.,
>Quezon City 1100
>
>
>
>
>
^ permalink raw reply
* AntiVirus - Warnung
From: SLZ-01-HUB03-KoyEXo1WXqVeoWH0uzbU5w @ 2004-01-28 7:08 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In dem von Ihnen gesendetem Mail wurde ein Virus entdeckt und
- gegebenenfalls mit der/den angehaengten Datei/en - entfernt.
The infected component in the scanned document was deleted.
Violation Information:
The attachment doc.zip contained the virus W32.Novarg.A-rtiCCPl9gjg@public.gmane.org and was deleted.
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: [PATCH|RFC] IPv6: have a proxy discard link-local traffic
From: Ville Nuorvala @ 2004-01-28 7:13 UTC (permalink / raw)
To: Pekka Savola
Cc: YOSHIFUJI Hideaki / 吉藤英明, davem,
usagi-core, netdev
In-Reply-To: <Pine.LNX.4.44.0401280725370.14588-100000@netcore.fi>
On Wed, 28 Jan 2004, Pekka Savola wrote:
> On Wed, 28 Jan 2004, YOSHIFUJI Hideaki / [iso-2022-jp] µÈÆ£±ÑÌÀ wrote:
> > In article <Pine.LNX.4.58.0401272259160.28384@rhea.tcs.hut.fi> (at Tue, 27 Jan 2004 23:11:20 +0200 (EET)), Ville Nuorvala <vnuorval@tcs.hut.fi> says:
> > > + /* The proxying router can't forward traffic sent to a link-local
> > > + address, so signal the sender and discard the packet. This
> > > + behavior is required by the MIPv6 specification. */
> >
> > Would you please clarify the word "can't" and its reasons?
> > won't? don't? or whatever?
>
> I think "can't" in this context means, "it can't be _forwarded_
> because it's link-local". It could be proxied using some other
> function than ip6_forward, though.
Yes.
--
Ville Nuorvala
Research Assistant, Institute of Digital Communications,
Helsinki University of Technology
email: vnuorval@tcs.hut.fi, phone: +358 (0)9 451 5257
^ permalink raw reply
* REJECT rules with tcp-reset.
From: Egor Tur @ 2004-01-28 7:17 UTC (permalink / raw)
To: netfilter
Hi folk.
How can I correctly create rules with REJECT and tcp-reset.
If I do
eth0 - NET, eth1 LAN
iptables -A FORWARD -i eth0 -o eth1 -p tcp --sport 1024: -d MY.LAN.IP --dport 113 -j REJECT --reject-with tcp-reset
iptables -A FORWARD -i eth1 -o eth0 -p tcp ! --syn --dport 1024: -s MY.LAN.IP --sport 113 -j ACCEPT
iptables -t nat -A PREROUTING -i eth0 -p tcp --sport 1024: -d MY.NET.IP --dport 113 -j DNAT --to MY.LAN.IP:113
I wait long time when I try connect with ftp & mail services.
(And I see some attempts to connect to auth service)
If I try REJECT --reject-with icmp-port-unreachable
this work quickly but slowly then I permit authentication.
When I try use INPUT & OUTPUT chains I have the same situation.
nat & mangle tables have ACCEPT policy, filter - DROP
What can I do in order to use tcp-reset?
iptables 1.2.9, kernel 2.4.24
Thanx.
^ permalink raw reply
* anti-dos
From: Fritz Mesedilla @ 2004-01-28 7:18 UTC (permalink / raw)
To: Netfilter Mailing List (E-mail)
in preparation to sco's feb 1. dos attack, is there any special iptables rules that i can use to avoid dos attacks?
all i have right now is i blocked all ports then opened the mail and internet.
what else can i do for rules?
thanks.
Cheers,
fritz <www.mesedilla.com>
---
+ Basta Ikaw Lord
----------------------------------------------------------------------
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the sender immediately by e-mail and delete this e-mail from your
system. Please note that any views or opinions presented in this
email are solely those of the author and do not necessarily represent
those of the company. Finally, the recipient should check this email
and any attachments for the presence of viruses. The company accepts
no liability for any damage caused by any virus transmitted by this
email.
Overture Media, Inc.
Direct Line: (632) 635-4785
Trunkline: (632) 631-8971 Local 146
Fax: (632) 637-2206
Level 1 Summit Media Offices, Robinsons Galleria EDSA Cor. Ortigas Ave., Quezon City 1100
^ permalink raw reply
* [PATCH 1/2] IPV6: use ipv6_addr_any()
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2004-01-28 7:30 UTC (permalink / raw)
To: davem; +Cc: netdev, yoshfuji
Hello.
Use simple ipv6_addr_any()
where ipv6_addr_type() is called only to check for unspecified address.
Thanks.
===== net/ipv6/af_inet6.c 1.60 vs edited =====
--- 1.60/net/ipv6/af_inet6.c Thu Jan 22 15:38:40 2004
+++ edited/net/ipv6/af_inet6.c Wed Jan 28 16:11:31 2004
@@ -464,7 +464,7 @@
if (np->sndflow)
sin->sin6_flowinfo = np->flow_label;
} else {
- if (ipv6_addr_type(&np->rcv_saddr) == IPV6_ADDR_ANY)
+ if (ipv6_addr_any(&np->rcv_saddr))
ipv6_addr_copy(&sin->sin6_addr, &np->saddr);
else
ipv6_addr_copy(&sin->sin6_addr, &np->rcv_saddr);
===== net/ipv6/ndisc.c 1.64 vs edited =====
--- 1.64/net/ipv6/ndisc.c Thu Jan 22 15:38:40 2004
+++ edited/net/ipv6/ndisc.c Wed Jan 28 16:13:21 2004
@@ -544,7 +544,7 @@
}
len = sizeof(struct icmp6hdr) + sizeof(struct in6_addr);
- send_llinfo = dev->addr_len && ipv6_addr_type(saddr) != IPV6_ADDR_ANY;
+ send_llinfo = dev->addr_len && !ipv6_addr_any(saddr);
if (send_llinfo)
len += NDISC_OPT_SPACE(dev->addr_len);
--
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ 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.