* [LARTC] HTB bug?
From: Abraham van der Merwe @ 2002-12-13 17:02 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 2515 bytes --]
Hi!
A couple of weeks ago we started using the Linux TC implementation to shape
clients (using HTB) and since then our QoS box started crashing every now
and again (talk about inconvenient timing :P).
First we suspected hardware, but we replaced the hardware this week and it
still keeps crashing. Current machine specs:
Celeron 400 MHz
128MB Ram
128MB Compact Flash storage
Distribution: stripped down Debian (woody)
The machine runs now services whatsoever:
------------< snip <------< snip <------< snip <------------
root@rana:~# netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
PID/Program nam
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags Type State I-Node PID/Program name
Path
------------< snip <------< snip <------< snip <------------
It has no load whatsoever.
The kernel:
2.4.20rc1 with Andrea Arcangeli's pausing fix applied (I'm running the
kernel on several other machines that have much higher load (read: that
actually has load), including my own workstation and they're all very
stable.
The only other unknown is HTB and so I'm starting to suspect it. I'm using
tc from the iproute ss020116-try tarball with the HTB 3.6 patch applied.
Now the problem is that I don't have enough space to log to disk - I'm just
logging to console (also logging with kernel log level 8 to console). Each
time I get to the machine it is completely dead, and the keyboard leds is
flashing continuously. Unfortunately I can't see whether there is any oopses
or last dying messages since I only have serial console on the machine right
now (no messages to tty) and each time I didn't actually check the serial
console.
I know this isn't a very useful bug report (will try to get something more
useful later on), but I just want to know if somebody else have experienced
the same kind of behaviour lately.
In anycase, I've removed all the rules from the machine and is going to just
to QoS on our Cisco routers again until I resolve the problem :P
--
Regards
Abraham
Real programmers don't write in BASIC. Actually, no programmers write in
BASIC after reaching puberty.
___________________________________________________
Abraham vd Merwe [ZR1BBQ] - Frogfoot Networks
P.O. Box 3472, Matieland, Stellenbosch, 7602
Cell: +27 82 565 4451 Http: http://www.frogfoot.net/
Email: abz@frogfoot.net
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: Re: [Alsa-user] fm801 driver status?
From: Takashi Iwai @ 2002-12-13 17:02 UTC (permalink / raw)
To: Friedrich Ewaldt; +Cc: Thierry Vignaud, alsa-user, alsa-devel
In-Reply-To: <3DFA1166.2020409@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]
At Fri, 13 Dec 2002 17:57:10 +0100,
Friedrich Ewaldt wrote:
>
> Takashi Iwai schrieb:
> [...]
> >>00:0b.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A
> >>[FM801] (rev a0)
> >> Subsystem: Fortemedia, Inc: Unknown device 1319
> >> Flags: bus master, medium devsel, latency 40, IRQ 10
> >> I/O ports at ec00 [size=128]
> >> Capabilities: [dc] Power Management version 1
> >>
> >>00:0b.1 Input device controller: Fortemedia, Inc Xwave QS3000A [FM801]
> >>(rev a0)
> >> Subsystem: Fortemedia, Inc: Unknown device 1319
> >> Flags: bus master, medium devsel, latency 40, IRQ 11
> >> Capabilities: [dc] Power Management version 1
> >
> >
> > i need the pci vendor/device id for them.
> > could you give me the output of "lspci -n" for two devices above?
> > the audio chip should be 0x1319:0x0801.
> >
>
> lspci -n output:
>
> 00:0b.0 Class 0401: 1319:0801 (rev a0)
> 00:0b.1 Class 0980: 1319:0801 (rev a0)
thanks, could you try the attached patch?
at least, the weird messages for allocation of invalid i/o ports
should disappear. not sure whether this cures the lock-up problem,
though.
Takashi
[-- Attachment #2: fm801-fix.dif --]
[-- Type: application/octet-stream, Size: 599 bytes --]
Index: alsa-kernel/pci/fm801.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/fm801.c,v
retrieving revision 1.20
diff -u -r1.20 fm801.c
--- alsa-kernel/pci/fm801.c 9 Dec 2002 10:54:45 -0000 1.20
+++ alsa-kernel/pci/fm801.c 13 Dec 2002 16:59:43 -0000
@@ -164,7 +164,7 @@
};
static struct pci_device_id snd_fm801_ids[] __devinitdata = {
- { 0x1319, 0x0801, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* FM801 */
+ { 0x1319, 0x0801, PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_MULTIMEDIA_AUDIO << 8, 0xffff00, 0, }, /* FM801 */
{ 0, }
};
^ permalink raw reply
* pci api question
From: Jason Lunz @ 2002-12-13 17:07 UTC (permalink / raw)
To: linux-kernel
I have a userspace program that I'd like to port to the kernel. The only
thing it really does is flip a bit in a pci config register of my Via
northbridge.
I've got it mostly done, except that I'm not sure how to express what
the userspace program does using the linux pci api. The (very ugly)
userspace program, in a nutshell, does this:
#define DWORD unsigned long
DWORD PCIRead(int reg, int fn=0, int dev=0,int bus=0, int port=0xcf8)
{
DWORD r=0x80000000;
DWORD ret,org;
r|=(( bus & 0xff) <<16);
r|=(( dev & 0x1f) <<11);
r|=(( fn & 0x7 ) << 8);
r|=(( reg & 0xfc) );
org=inl(port);
outl(r,port);
ret=inl(port+4);
outl(org,port);
return ret;
}
void PCIWrite(DWORD val, int reg, int fn=0, int dev=0,int bus=0, int port=0xcf8)
{
DWORD r=0x80000000;
DWORD org;
r|=(( bus & 0xff) <<16);
r|=(( dev & 0x1f) <<11);
r|=(( fn & 0x7 ) << 8);
r|=(( reg & 0xfc) );
org=inl(port);
outl(r,port);
outl(val,port+4);
outl(org,port);
}
void main(void) {
DWORD res;
res =PCIRead(0x52,0,0,0);
printf("read %#.8x\n", res);
res |= 0x00800000;
printf("writing %#.8x\n", res);
PCIWrite(res,0x52,0,0,0);
}
this prints out
read 0xb46ba417
writing 0xb4eba417
I want to do this within the kernel. I have this (abridged):
#include <linux/module.h>
#include <linux/pci.h>
static int __devinit via_nb_init(struct pci_dev *pdev, const struct pci_device_id *ent);
static void __devexit via_nb_remove(struct pci_dev *pdev);
static struct pci_device_id via_nb_tbl[] __devinitdata = {
{PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8363_0, PCI_ANY_ID, PCI_ANY_ID,},
{PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8371_0, PCI_ANY_ID, PCI_ANY_ID,},
{0,}
};
static struct pci_driver via_nb_driver = {
name: "via83xx_pm-nb",
id_table: via_nb_tbl,
probe: via_nb_init,
remove: via_nb_remove,
};
static int __devinit
via_nb_init(struct pci_dev *pdev, const struct pci_device_id *ent)
{
u32 enable;
printk(KERN_INFO "via83xx_pm: Initializing northbridge %s\n", pdev->name);
pci_read_config_dword(pdev, 0x52, &enable);
printk(KERN_INFO "read %#.8x\n", enable);
enable |= 0x00800000;
printk(KERN_INFO "writing %#.8x to 0x52\n", enable);
pci_write_config_dword(pdev, 0x52, enable);
return 0;
}
static void __devexit
via_nb_remove(struct pci_dev *pdev)
{
u32 enable;
pci_read_config_dword(pdev, 0x52, &enable);
printk(KERN_INFO "0x52 is %#.8x\n", enable);
enable &= ~0x00800000;
printk(KERN_INFO "would write %#.8x to 0x52\n", enable);
pci_write_config_dword(pdev, 0x52, enable);
}
static int __init
via83xx_pm_init(void)
{
found = pci_module_init(&via_nb_driver);
if (found < 0) {
printk(KERN_ERR "via83xx_pm: Could not find northbridge\n");
return 1;
}
return 0;
}
static void __exit
via83xx_pm_cleanup(void)
{
pci_unregister_driver(&via_nb_driver);
}
MODULE_LICENSE("GPL");
module_init(via83xx_pm_init);
module_exit(via83xx_pm_cleanup);
however, the pci_(read|write)_config_dword() calls seem to be changing
a different register than the userspace program. The kernel module
prints out these (very different) values:
read 0xc12cc400
would write 0xc1acc400
The userspace version works. The kernel one doesn't. Any idea what I'm
doing wrong?
thanks, Jason
^ permalink raw reply
* Re: Re: [Alsa-user] fm801 driver status?
From: Friedrich Ewaldt @ 2002-12-13 16:57 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Thierry Vignaud, alsa-user, alsa-devel
In-Reply-To: <s5hisxxubkx.wl@alsa2.suse.de>
Takashi Iwai schrieb:
[...]
>>00:0b.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A
>>[FM801] (rev a0)
>> Subsystem: Fortemedia, Inc: Unknown device 1319
>> Flags: bus master, medium devsel, latency 40, IRQ 10
>> I/O ports at ec00 [size=128]
>> Capabilities: [dc] Power Management version 1
>>
>>00:0b.1 Input device controller: Fortemedia, Inc Xwave QS3000A [FM801]
>>(rev a0)
>> Subsystem: Fortemedia, Inc: Unknown device 1319
>> Flags: bus master, medium devsel, latency 40, IRQ 11
>> Capabilities: [dc] Power Management version 1
>
>
> i need the pci vendor/device id for them.
> could you give me the output of "lspci -n" for two devices above?
> the audio chip should be 0x1319:0x0801.
>
lspci -n output:
00:0b.0 Class 0401: 1319:0801 (rev a0)
00:0b.1 Class 0980: 1319:0801 (rev a0)
and that's part of the output of 'lspcidrake -v':
snd-fm801 : Fortemedia, Inc|Xwave QS3000A [FM801]
[MULTIMEDIA_AUDIO] (vendor:1319 device:0801 subv:1319 subd:1319)
snd-fm801 : Fortemedia, Inc|Xwave QS3000A [FM801] [INPUT_OTHER]
(vendor:1319 device:0801 subv:1319 subd:1319)
does this information help or do you need any other outputs? thanks!
(The fm801 chip on this card is one of the older models without SPDIF
input. I looked this up some time ago because I saw the possibility to
get an digital input with this card using an soldering iron and some el.
parts for a few cents)
fe
-------------------------------------------------------
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: Symlink indirection
From: Andrew Walrond @ 2002-12-13 17:04 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: linux-kernel
In-Reply-To: <20021213115508.A16493@devserv.devel.redhat.com>
Of course; Didn't think of that in this context.
My application of symlinks involves overlaying several directories onto
another, in an order such that any like named files are overridden in a
defined way.
I had thought about asking the feasibility of [made up name]
'transparent bindings' which would have this effect
Suppose I might as well ask now ;) Any takers?
Pete Zaitcev wrote:
>>Date: Fri, 13 Dec 2002 16:48:45 +0000
>>From: Andrew Walrond <andrew@walrond.org>
>
>
>>Sorry for being dense, but what do you mean by 'bindings' ? Hard links?
>
>
> $ man mount
>
> Since Linux 2.4.0 it is possible to remount part of the file hierarchy
> somewhere else. The call is
> mount --bind olddir newdir
> After this call the same contents is accessible in two places.
>
> -- Pete
>
^ permalink raw reply
* Re: Linux 2.4.21-pre1 IDE
From: Alan Cox @ 2002-12-13 17:42 UTC (permalink / raw)
To: Tomas Szepe; +Cc: andersen, Marcelo Tosatti, lkml
In-Reply-To: <20021213142340.GB22190@louise.pinerecords.com>
On Fri, 2002-12-13 at 14:23, Tomas Szepe wrote:
> Alan, I sent you a patch fixing this last week, can resend if necessary.
In my queue along with some other pci fixes to sort out the mixed up
native/legacy configurations and a driver for the Triflex contributed by
Compaq
^ permalink raw reply
* Re: [PATCH] S4Bios support for 2.4.20 + acpi-20021205
From: Marc Giger @ 2002-12-13 16:54 UTC (permalink / raw)
To: Ducrot Bruno
Cc: nils-t93Ne7XHvje5bSeCtf/tX7NAH6kLmebB,
acpi-devel-pyega4qmqnRoyOMFzWx49A
In-Reply-To: <20021213163615.GI4327-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>
Hi,
On Fri, 13 Dec 2002 17:36:15 +0100
Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> On Fri, Dec 13, 2002 at 05:14:31PM +0100, Nils Faerber wrote:
> > On Fri, 13 Dec 2002 16:53:09 +0100
> > Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> > > Patch for 2.4.20 and acpi-20021205 for adding s4bios feature.
> >
> > Hey, that sounds great!
> > Just a little question: How do I use it :)
> >
> > Don't think I am stupid...
> > I know that a echo 1 > /proc/acpi/sleep should do the trick, i.e.
> > suspend to disk. But how do I configure that suspend partition? Or where
>
> Well, I don't know. Perhaps lphdisk (I don't remember the URI) could
> help. Some googling permit to get it. Or (who knows?) even a /dev/hda1
> as a vfat partition can help?
>
> > does it suspend? I know for Phoenix BIOSes there is a tool on the net to
> > create that partition. I have a Asus L3800C notebook which has AFAIK an
> > AWARD BIOS. And AFAIK there is no tool available from ASUS or AWARD to
> > create such a partition.
>
> In a really perfect world:
> echo 1 > /proc/acpi/sleep # for standby
> echo 2 > /proc/acpi/sleep # for suspend to ram
> echo 3 > /proc/acpi/sleep # for suspend to ram, but with more power conservative
> echo 4 > /proc/acpi/sleep # for suspend to disk
> echo 5 > /proc/acpi/sleep # for shutdown unfriendly the system
>
> and perhaps
> echo 4b > /proc/acpi/sleep # for suspend to disk via s4bios
>
> Actually, since there is no S4 support in 2.4, 4 and 4b is the same here.
Just a question:
I thought S2 and S3 are not supported in 2.4 ? S4 over swsuspend in 2.4 ? or not?
I was never able to suspend a machine with S2 or S3...
greets
Marc
-------------------------------------------------------
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: 823 Video Controller Driver - where ?
From: Wolfgang Grandegger @ 2002-12-13 16:51 UTC (permalink / raw)
To: Steve Rossi; +Cc: Embedded Linux PPC List
In-Reply-To: <3DFA05C3.30703@ccrl.mot.com>
On 12/13/2002 05:07 PM Steve Rossi wrote:
> I've seen some reference on the list regarding a driver for the 823
> Video Controller -
> i.e.
> http://lists.linuxppc.org/results.html?restrict=linuxppc-embedded&words=vid823
> however I've been unable to locate the source to vid823.c
> apparently this question was asked before:
> http://lists.linuxppc.org/linuxppc-embedded/200201/msg00164.html
> and the answer was that its in the 2_4_devel tree, but I was unable to
> find it in a recent snapshot of the tree (I'm unable to get the tree
> from the bitkeeper repository due to a problem in bitkeeper 3.0 related
> to http proxy with authentication - but thats another story!) so I got
> the snapshot from http://ppckernel.org/tree.php?id=5
> All I could find was the RPX framebuffer driver rpxfb.c for various LCD
> panels using the LCD controller..
> I'm looking for a driver for the video controller to output to an NTSC
> encoder. Am I just missing something?
> Anyone know where I can get vid823.c (or whatever it might be called
> now) and whether its a true framebuffer driver?
Recently we have ported a video driver to the MPC823 using the video
encoder AD7176. The problem is, that the pixels data in the framebuffer
must have the YUV or Y-Cb-Y-Cr-Format which is rarely used, at least I
have not found any support in Linux or Microwindows. You can find the
port on our linux-2.4 CVS tree (see http://www.denx.de/re/linux.html).
Check for "arch/ppc_8xx/video823.c" and "drivers/video/fbcon-yuv.c".
Hope it helps,
Wolfgang.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: pci-skeleton duplex check
From: Donald Becker @ 2002-12-13 16:56 UTC (permalink / raw)
To: David S. Miller
Cc: Jeff Garzik, Roger Luethi, netdev, Linux Kernel Mailing List
In-Reply-To: <1039771036.1509.5.camel@rth.ninka.net>
On 13 Dec 2002, David S. Miller wrote:
> On Thu, 2002-12-12 at 17:18, Donald Becker wrote:
> > Or perhaps recognizing that when someone that has been a significant,
> > continuous contributer since the early days of Linux
>
> Until you learn to play nice with people and mesh within the
> fabric of Linux development, I adamently do not classify you
> as you appear to self-classify yourself. You don't contribute,
> you sit in your sandbox and then point fingers at the people who
> do know how to work with other human beings and say "see how much
> that stuff sucks? well my stuff works, nyah!"
..
> If Linux itself is worse off and went backwards in time for a while...
The development criteria used to be technically based, and that is still
the public statement. Now, as your statement makes clear, working code
is an irrelevant criteria.
You comments immediately moved the subject from the technical merit and
correctness of the code to an ad hominem attack. The facts, and the
code, clearly show the long term interaction and contribution. In most
cases the code and interfaces we are talking about were written and
defined by me throughout the past decade.
--
Donald Becker becker@scyld.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Scyld Beowulf cluster system
Annapolis MD 21403 410-990-9993
^ permalink raw reply
* Re: Symlink indirection
From: Pete Zaitcev @ 2002-12-13 16:55 UTC (permalink / raw)
To: Andrew Walrond; +Cc: linux-kernel
In-Reply-To: <3DFA0F6D.1010904@walrond.org>
> Date: Fri, 13 Dec 2002 16:48:45 +0000
> From: Andrew Walrond <andrew@walrond.org>
> Sorry for being dense, but what do you mean by 'bindings' ? Hard links?
$ man mount
Since Linux 2.4.0 it is possible to remount part of the file hierarchy
somewhere else. The call is
mount --bind olddir newdir
After this call the same contents is accessible in two places.
-- Pete
^ permalink raw reply
* Re: Symlink indirection
From: Jeff Bailey @ 2002-12-13 16:51 UTC (permalink / raw)
To: root; +Cc: Andrew Walrond, linux-kernel, libc-alpha
In-Reply-To: <Pine.LNX.3.95.1021213101227.2190A-100000@chaos.analogic.com>
[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]
On Fri, 2002-12-13 at 10:23, Richard B. Johnson wrote:
> Since a symlink is just a file containing a name, the resulting path
> length is simply the maximum path length that user-space tools allow.
> This should be defined as "PATH_MAX". Posix defines this as 255 characters
> but I think posix requires that this be the minimum and all file-name
> handling buffers must be at least PATH_MAX in length.
Small nit here, the Posix draft I have says that the definition shall be
omitted from the <limits.h> header on specific implementation where the
corresponding value is equal or greater than the stated minimum, but
where the value can vary depending on the file to which it is applied.
Please don't ever rely on PATH_MAX existing. pathconf() is a better
tool. We spend a lot of time chasing authors to explain to them why it
really is okay for the Hurd (i386-pc-gnu)'s libc to omit this
definition.
Tks,
Jeff Bailey
--
When you get to the heart,
use a knife and fork.
- From instructions on how to eat an artichoke.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Mike Hayward @ 2002-12-13 16:49 UTC (permalink / raw)
To: wli; +Cc: linux-kernel
In-Reply-To: <20021213154544.GK9882@holomorphy.com>
Hi Bill,
> On Mon, Dec 09, 2002 at 01:30:28AM -0700, Mike Hayward wrote:
> > Any ideas? Not sure I want to upgrade to the P7 architecture if this
> > is right, since for me system calls are probably more important than
> > raw cpu computational power.
>
> This is the same for me. I'm extremely uninterested in the P-IV for my
> own use because of this.
I've also noticed that algorithms like the recursive one I run which
simulates solving the Tower of Hanoi problem are most likely very hard
to do branch prediction on. Both the code and data no doubt fit
entirely in the L2 cache. The AMD processor below is a much lower
cost and significantly lower clock rate (and on a machine with only a
100Mhz Memory bus) than the Xeon, yet dramatically outperforms it with
the same executable, compiled with gcc -march=i686 -O3. Maybe with a
better Pentium 4 optimizing compiler the P4 and Xeon could improve a
few percent, but I doubt it'll ever see the AMD numbers.
Recursion Test--Tower of Hanoi
Uni AMD XP 1800 2.4.18 kernel 46751.6 lps (10 secs, 6 samples)
Dual Pentium 4 Xeon 2.4Ghz 2.4.19 kernel 33661.9 lps (10 secs, 6 samples)
- Mike
^ permalink raw reply
* [PATCH] sscanf doesn't handle %x in 2.4.20
From: steven pratt @ 2002-12-13 16:47 UTC (permalink / raw)
To: linux-kernel, alan, marcelo; +Cc: slpratt
In vsscanf in vsprintf.c incorectly uses isdigit to check for a leading
numeric
after finding a %x and setting the base to 16. This breaks device
mapper under
certain conditions. Following patch is backport from 2.5.50.
--- vsprintf.c Thu Oct 11 13:17:22 2001
+++ /usr/src/linux-2.4.20/lib/vsprintf.c Fri Dec 13 09:57:14 2002
@@ -637,7 +637,11 @@
while (isspace(*str))
str++;
- if (!*str || !isdigit(*str))
+ if (!*str
+ || (base == 16 && !isxdigit(*str))
+ || (base == 10 && !isdigit(*str))
+ || (base == 8 && (!isdigit(*str) || *str > '7'))
+ || (base == 0 && !isdigit(*str)))
break;
switch(qualifier) {
^ permalink raw reply
* Help! ip traffic accounting and bidirection with iptables ??
From: Toth Szabolcs @ 2002-12-13 16:42 UTC (permalink / raw)
To: netfilter; +Cc: netfilter-devel
Hi All !
I have the following network schema :
firewall
_________
INET | | | LAN
<------>ETH0 | ETH1<----->
1.2.3.5 | | | 192.168.0.0/16
---------
server
I measure the ip traffic for each user who are in the LAN segment.
I measure all traffic that goes to , come from the server and INET.
I used unil now ipchains. The following rules make it possible for me to
see seperated the incoming and outgoing traffic on each user ip:
pkts bytes
1125 208155 - all ------ 0xFF 0x00 eth1 192.168.2.10 0.0.0.0/0 n/a
1542 1153702 - all ------ 0xFF 0x00 eth1 0.0.0.0/0 192.168.2.10 n/a
---------------
ipchains -N acct
ipchains -A input -j acct -s 192.168.0.0/16 -b
ipchains -A output -j acct -s 192.168.0.0/16 -b
ipchains -A acct -p all -s 192.168.0.19 -i eth1 -b
ipchains -A acct -p all -s 192.168.2.10 -i eth1 -b
ipchains -A acct -p all -s 192.168.2.26 -i eth1 -b
ipchains -A acct -p all -s 192.168.2.42 -i eth1 -b
ipchains -A acct -p all -s 192.168.2.58 -i eth1 -b
......
.....
.....
(n+1)
Now I would change to iptables but I have a problem that I can not solve.
I can not measure the ip traffic / seperated for incoming and outgoing !!/
in ONE rule beacuse there is now "-b" /bidirection/ option in the
iptables.
Now I use the following rules in iptables:
iptables -N acct
iptables -A acct -d 192.168.2.10
iptables -A acct -s 192.168.2.10
........
.......
(2n+1)
iptables -A INPUT -i eth1 -s 192.168.0.0/16 -j acct
iptables -A FORWARD -j acct
iptables -A OUTPUT -o eth1 -d 192.168.0.0/16 -j acct
If anybody know a better solution please write me: totya@ajkanet.hu
^ permalink raw reply
* Re: 823 Video Controller Driver - where ?
From: Wolfgang Denk @ 2002-12-13 16:42 UTC (permalink / raw)
To: Steve Rossi; +Cc: Embedded Linux PPC List
In-Reply-To: <3DFA05C3.30703@ccrl.mot.com>
Dear Steve,
in message <3DFA05C3.30703@ccrl.mot.com> you wrote:
>
> I've seen some reference on the list regarding a driver for the 823
> Video Controller -
> i.e.
> http://lists.linuxppc.org/results.html?restrict=linuxppc-embedded&words=vid823
> however I've been unable to locate the source to vid823.c
It is my understanding that this driver is available with and for
some EP board only, and obviously not available for free.
> apparently this question was asked before:
> http://lists.linuxppc.org/linuxppc-embedded/200201/msg00164.html
> and the answer was that its in the 2_4_devel tree, but I was unable to
> find it in a recent snapshot of the tree (I'm unable to get the tree
I haven't found anything either when I searched some time ago.
> I'm looking for a driver for the video controller to output to an NTSC
> encoder. Am I just missing something?
> Anyone know where I can get vid823.c (or whatever it might be called
> now) and whether its a true framebuffer driver?
We have a video controller driver in our source tree (module
linux-2.4 on our CVS server), see arch/ppc/8xx_io/video823.c
Note: the code relies on some initialization performed by the U-Boot
boot loader, and it has never been tested yet with NTSC. But it
should be a starting point at least.
And yes, it is a true framebuffer driver, although it uses the
awkward YUYV video mode format only.
Hope this helps.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
God may be subtle, but He isn't plain mean. - Albert Einstein
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Symlink indirection
From: Andrew Walrond @ 2002-12-13 16:48 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: linux-kernel
In-Reply-To: <200212131616.gBDGGH302861@devserv.devel.redhat.com>
Pete,
Sorry for being dense, but what do you mean by 'bindings' ? Hard links?
Andrew
> Frankly, all cases when I had seen the nested symlink farms of that
> depth would be better served by use of bindings - these are not subject
> to any limits on nesting and avoid a lot of PITA inherent to symlink
> farms. To put it another way, nested symlink farms grow from attempts
> to work around the lack of bindings. It's not that you need to replace
> all symlinks with bindings, of course - the crown of the tree is usually
> OK, it's the trunk that acts as source of pain.
^ permalink raw reply
* Re: Linux installation on DOC / problems / I need your help
From: Henrik Nordstrom @ 2002-12-13 17:08 UTC (permalink / raw)
To: Alejandro O. Gonzalez; +Cc: linux-mtd
In-Reply-To: <002c01c2a2a9$54ea2900$a2e4f4d8@nnn123>
This will as you assume erase the BIOS from the DOC.
If you want to be able to access the DOC from DOS without first booting
from another media and loading a separate DOS DOC driver you need to use
the mSYS DOC BIOS, installed by running DFORMAT from DOS.
However, using the mSYS 5.1.5 DOS driver (I think, not entirely sure about
version but a 5 something) I could not make it function reliably if the
DOC had been partitioned with more than one partition.. No such problems
with the Linux driver.
Regards
Henrik
On Fri, 13 Dec 2002, Alejandro O. Gonzalez wrote:
> I rebuild the kernel. Then I made this
>
> 1- run the driver
> #modprobe doc2000
> #modprobe docprobe
>
> 2- format the memory
> #nftl_format /dev/mtd0 0 16777216
>
> 3- run nftl
> #modprobe nftl
>
> 4- make a partition
> #fdisk /dev/nftla
> I make two partition first DOS, and second Linux.
>
> 5- make filesystem
> #mkfs.msdos /dev/nftla1
> #mke2fs /dev/nftla2
>
> 6-Install syslinux
> #syslinux /dev/nftla1
>
> 7-configure boot and reboot
>
> I don´t know if this procedure is correct, but when reboot the bios not
> found a valid boot device.
> When I format all memory with nftl_format command I delete the TrueFFS bios
> of MSYS. This is Ok ?
>
> I try then to overwrite the TrueFFS bios driver
>
> DFORMAT /WIN:E000 /S:DOC512.EXB /NOFORMAT /FIRST
>
> but display an error, can´t write the bios.
>
> I do so that the bios recognize the DOC like a valid device of boot.
>
> I try also to format with MSYS utility, then create a 2MB of DOS partition.
> Boot with linux and format the last 14 MB of memory with
> nftl_format. But when startup nftl driver says "we don´t support
> UnitSizeFactor!=1" and it is not possible to work with a nftl partition.
> I will appreciate any commentary, thank you for your time.
> Regards,
> Alejandro Gonzalez
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
^ permalink raw reply
* Re: Symlink indirection
From: Alan Cox @ 2002-12-13 17:22 UTC (permalink / raw)
To: Andrew Walrond; +Cc: Marc-Christian Petersen, Linux Kernel Mailing List
In-Reply-To: <3DF9FAB1.5070504@walrond.org>
On Fri, 2002-12-13 at 15:20, Andrew Walrond wrote:
> Thanks Marc
>
> 5 is very low isn't it? Certainly marginal for an application I have in
> mind.
8 is more normal, but their are recursion and stack size considerations
^ permalink raw reply
* Re: [PATCH] S4Bios support for 2.4.20 + acpi-20021205
From: Ducrot Bruno @ 2002-12-13 16:36 UTC (permalink / raw)
To: Nils Faerber; +Cc: Ducrot Bruno, acpi-devel-pyega4qmqnRoyOMFzWx49A
In-Reply-To: <20021213171431.045233f0.nils-t93Ne7XHvje5bSeCtf/tX7NAH6kLmebB@public.gmane.org>
On Fri, Dec 13, 2002 at 05:14:31PM +0100, Nils Faerber wrote:
> On Fri, 13 Dec 2002 16:53:09 +0100
> Ducrot Bruno <ducrot-kk6yZipjEM5g9hUCZPvPmw@public.gmane.org> wrote:
> > Patch for 2.4.20 and acpi-20021205 for adding s4bios feature.
>
> Hey, that sounds great!
> Just a little question: How do I use it :)
>
> Don't think I am stupid...
> I know that a echo 1 > /proc/acpi/sleep should do the trick, i.e.
> suspend to disk. But how do I configure that suspend partition? Or where
Well, I don't know. Perhaps lphdisk (I don't remember the URI) could
help. Some googling permit to get it. Or (who knows?) even a /dev/hda1
as a vfat partition can help?
> does it suspend? I know for Phoenix BIOSes there is a tool on the net to
> create that partition. I have a Asus L3800C notebook which has AFAIK an
> AWARD BIOS. And AFAIK there is no tool available from ASUS or AWARD to
> create such a partition.
In a really perfect world:
echo 1 > /proc/acpi/sleep # for standby
echo 2 > /proc/acpi/sleep # for suspend to ram
echo 3 > /proc/acpi/sleep # for suspend to ram, but with more power conservative
echo 4 > /proc/acpi/sleep # for suspend to disk
echo 5 > /proc/acpi/sleep # for shutdown unfriendly the system
and perhaps
echo 4b > /proc/acpi/sleep # for suspend to disk via s4bios
Actually, since there is no S4 support in 2.4, 4 and 4b is the same here.
Please note also that this patch DO NOT fix devices suspensions codes in
general, and have certainly some data corruption that need to be fixed
before a real inclusion.
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
-------------------------------------------------------
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
* Mirrored Display?
From: Michael Kaufmann @ 2002-12-13 18:33 UTC (permalink / raw)
To: Linux-fbdev-devel
Hello,
i would like to use a mono LCD with a framebuffer driver.
I've modified existing drivers, and after a lot of work i now have a clear
picture on my display. Unfortunately, the complete picture is mirrored.
The Bootlogo is top/right instead of top/left and the ascii output starts from
right to left.
Where is the right place to modify this behaviour?
I'm also looking for a possibility to rotate the picture.
Because my videocontroller can emulate 15 grayscales, i'm useing 4bpp.
It would be very nice, if someone can guide me in the right direction.
Thanks in advance!
Michael
-------------------------------------------------------
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: Support for Arctic platform (405LP based)
From: Tom Rini @ 2002-12-13 16:35 UTC (permalink / raw)
To: Gary Thomas; +Cc: linuxppc embedded
In-Reply-To: <20021213151642.GH19456@opus.bloom.county>
On Fri, Dec 13, 2002 at 08:16:43AM -0700, Tom Rini wrote:
[snip]
> If you aren't already on the linuxppc-commit@source.mvista.com list, you
> might want to join that.
And since this is at a possibly non obvious location:
http://source.mvista.com/cgi-bin/mailman/listinfo/linuxppc-commit
<hint>Hopefully PenguinPPC.org will have a link to this somewhere.</hint>
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [PATCH] minor bug fix in sym53c8xx_2
From: Alex Tomas @ 2002-12-13 16:36 UTC (permalink / raw)
To: linux-kernel
Good day!
There is minor bug in sym53c8xx_2. Because of it you may not
exclude some HBA from scanning. Thus, kernel parameter
sym53c8xx=excl:0xe400 won't work. Please, apply path:
--- linux-2.5.51/drivers/scsi/sym53c8xx_2/sym_glue.c Fri Dec 13 19:30:27 2002
+++ linux-2.5.51n/drivers/scsi/sym53c8xx_2/sym_glue.c Fri Dec 13 19:23:48 2002
@@ -2481,7 +2487,8 @@
*/
if (base_io) {
for (i = 0 ; i < 8 ; i++) {
- if (sym_driver_setup.excludes[i] == base_io)
+ if (sym_driver_setup.excludes[i] ==
+ (base_io & PCI_BASE_ADDRESS_IO_MASK))
return -1;
}
}
sym53c8xx_2 in 2.4 has this bug too and this patch may by applied.
^ permalink raw reply
* Re: Symlink indirection
From: Alfred M. Szmidt @ 2002-12-13 16:41 UTC (permalink / raw)
To: root; +Cc: andrew, linux-kernel, libc-alpha
In-Reply-To: <Pine.LNX.3.95.1021213101227.2190A-100000@chaos.analogic.com>
This should be defined as "PATH_MAX".
This should only be defined if such an limit exists. Systems like
GNU/Hurd do not have this limit, but GNU/Linux does.
^ permalink raw reply
* Re: Re: [Alsa-user] fm801 driver status?
From: Thierry Vignaud @ 2002-12-13 16:33 UTC (permalink / raw)
To: Takashi Iwai; +Cc: Friedrich Ewaldt, alsa-user, alsa-devel
In-Reply-To: <s5hisxxubkx.wl@alsa2.suse.de>
Takashi Iwai <tiwai@suse.de> writes:
> i need the pci vendor/device id for them.
> could you give me the output of "lspci -n" for two devices above?
or "lspcidrake -v" if you have ldetect package installed but not
pciutils
-------------------------------------------------------
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: Re: [Alsa-user] fm801 driver status?
From: Takashi Iwai @ 2002-12-13 16:29 UTC (permalink / raw)
To: Friedrich Ewaldt; +Cc: Thierry Vignaud, alsa-user, alsa-devel
In-Reply-To: <3DF9C1CD.3090205@gmx.de>
At Fri, 13 Dec 2002 12:17:33 +0100,
Friedrich Ewaldt wrote:
>
> >>you can check this also via lspci command.
> >>
> >>
> >
> >lspcidrake -v will give him the module too
> >
> >
> I already attached my lspci -v outputs in two previous mails, but to be
> sure they get to where they should ...
>
> 00:0b.0 Multimedia audio controller: Fortemedia, Inc Xwave QS3000A
> [FM801] (rev a0)
> Subsystem: Fortemedia, Inc: Unknown device 1319
> Flags: bus master, medium devsel, latency 40, IRQ 10
> I/O ports at ec00 [size=128]
> Capabilities: [dc] Power Management version 1
>
> 00:0b.1 Input device controller: Fortemedia, Inc Xwave QS3000A [FM801]
> (rev a0)
> Subsystem: Fortemedia, Inc: Unknown device 1319
> Flags: bus master, medium devsel, latency 40, IRQ 11
> Capabilities: [dc] Power Management version 1
i need the pci vendor/device id for them.
could you give me the output of "lspci -n" for two devices above?
the audio chip should be 0x1319:0x0801.
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
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.