* RE: portfw on iptables 2.4 kernel problem.
From: Reckhard, Tobias @ 2002-12-12 7:33 UTC (permalink / raw)
To: netfilter
> Thanks for those people who replied, But still i can't get it to work.
> Ill be posting my rule set here.
Have you tried the more complicated rule set that I'd posted (in
pseudo-code)? At a first, casual glance, your NAT rules don't look good to
me.
Cheers,
Tobias
^ permalink raw reply
* Re: ELKS port of Adventure - help needed :)
From: Paul Nasrat @ 2002-12-12 7:39 UTC (permalink / raw)
To: linux-8086
In-Reply-To: <1039651196.1847.43.camel@Castle.goembel>
On Wed, Dec 11, 2002 at 05:59:56PM -0600, Phil Goembel wrote:
> On Wed, 2002-12-11 at 16:22, Richard Wallman wrote:
> > On 11 Dec, Richard Wallman wrote:
> >
> > > Possible a source code or bcc problem
> >
> > It's a bcc problem: strcmp doesn't return the right values.
> >
> Yes, I was thinking either a compiler problem or a
> runtime library problem.
Two possible fixes - there is a new dev86 out which string.c has
changed in (0.16.10). I'm going to test this out later when I get into
work. Thanks Robert :)
Or you can use the C version from uclibc:
http://www.uclibc.org/cgi-bin/cvsweb/uClibc/libc/string/Attic/string.c?rev=1.3&hideattic=0&content-type=text/vnd.viewcvs-markup
Paul
^ permalink raw reply
* [PATCH] 2.5.51 SCSI_IOCTL_GET_IDLUN + _GET_BUS_NUMBER
From: Douglas Gilbert @ 2002-12-12 7:44 UTC (permalink / raw)
To: linux-scsi
[-- Attachment #1: Type: text/plain, Size: 333 bytes --]
For disks both the SCSI_IOCTL_GET_IDLUN and
SCSI_IOCTL_GET_BUS_NUMBER ioctls return the value
0 (type: int) in all cases. The attachment removes
the dummy definitions of these ioctls in
driver/block/scsi_ioctl.c so they fall through
to the scsi mid level which correctly implements
them (at least in terms of lk 2.4).
Doug Gilbert
[-- Attachment #2: scsi_ioctl_blk2551.diff --]
[-- Type: text/plain, Size: 802 bytes --]
--- linux/drivers/block/scsi_ioctl.c 2002-11-29 09:27:35.000000000 +1100
+++ linux/drivers/block/scsi_ioctl.c2551xidlun 2002-12-12 18:19:23.000000000 +1100
@@ -73,16 +73,6 @@
return put_user(sg_version_num, p);
}
-static int scsi_get_idlun(request_queue_t *q, int *p)
-{
- return put_user(0, p);
-}
-
-static int scsi_get_bus(request_queue_t *q, int *p)
-{
- return put_user(0, p);
-}
-
static int sg_get_timeout(request_queue_t *q)
{
return q->sg_timeout;
@@ -413,10 +403,6 @@
*/
case SG_GET_VERSION_NUM:
return sg_get_version((int *) arg);
- case SCSI_IOCTL_GET_IDLUN:
- return scsi_get_idlun(q, (int *) arg);
- case SCSI_IOCTL_GET_BUS_NUMBER:
- return scsi_get_bus(q, (int *) arg);
case SG_SET_TIMEOUT:
return sg_set_timeout(q, (int *) arg);
case SG_GET_TIMEOUT:
^ permalink raw reply
* Re: Malta board patch
From: Carsten Langgaard @ 2002-12-12 7:46 UTC (permalink / raw)
To: Jun Sun; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <20021211090405.B6755@mvista.com>
Jun Sun wrote:
> A couple of nit-picking points ...
>
> On Wed, Dec 11, 2002 at 09:20:28AM +0100, Carsten Langgaard wrote:
> > Index: arch/mips/mips-boards/generic/pci.c
> > ===================================================================
> > RCS file: /home/cvs/linux/arch/mips/mips-boards/generic/pci.c,v
> > retrieving revision 1.5.2.4
> > diff -u -r1.5.2.4 pci.c
> > --- arch/mips/mips-boards/generic/pci.c 28 Sep 2002 18:28:44 -0000 1.5.2.4
> > +++ arch/mips/mips-boards/generic/pci.c 11 Dec 2002 08:11:56 -0000
> > @@ -405,6 +405,12 @@
> > ".set\treorder");
> >
> > irq = *(volatile u32 *)(KSEG1ADDR(BONITO_PCICFG_BASE));
> > + __asm__ __volatile__(
> > + ".set\tnoreorder\n\t"
> > + ".set\tnoat\n\t"
> > + "sync\n\t"
> > + ".set\tat\n\t"
> > + ".set\treorder");
> > irq &= 0xff;
> > BONITO_PCIMAP_CFG = 0;
> > break;
>
> Would a higher level macro such as __sync or fast_mb be better here?
I have already send a new patch to Ralf, because he argued for the same thing.
These macros was just not around, when I made this fix.
>
> > Index: arch/mips/mips-boards/malta/malta_int.c
> > ===================================================================
> > RCS file: /home/cvs/linux/arch/mips/mips-boards/malta/malta_int.c,v
> > retrieving revision 1.8.2.6
> > diff -u -r1.8.2.6 malta_int.c
> > --- arch/mips/mips-boards/malta/malta_int.c 5 Aug 2002 23:53:34 -0000 1.8.2.6
> > +++ arch/mips/mips-boards/malta/malta_int.c 11 Dec 2002 08:11:57 -0000
> > @@ -91,6 +91,9 @@
> > {
> > unsigned int data,datahi;
> >
> > + /* Mask out corehi interrupt. */
> > + clear_c0_status(IE_IRQ3);
> > +
> > printk("CoreHI interrupt, shouldn't happen, so we die here!!!\n");
> > printk("epc : %08lx\nStatus: %08lx\nCause : %08lx\nbadVaddr : %08lx\n"
> > , regs->cp0_epc, regs->cp0_status, regs->cp0_cause, regs->cp0_badvaddr);
> > @@ -125,7 +128,6 @@
> >
> > /* We die here*/
> > die("CoreHi interrupt", regs);
> > - while (1) ;
> > }
> >
> > void __init init_IRQ(void)
>
> I think corehi interrupt should be blocked from the beginning. I seem to
> remember a board errata itme that recommands not using it.
>
I have found quite a lot of bugs, with the corehi interrupt enabled. It should never
happen, so it indicates a fatal error, if it does.
It's true that on an early revision of some PLD code, there was a bug around the corehi
interrupt. If you got such a board, I suggest you update your PLD code.
>
> Jun
--
_ _ ____ ___ Carsten Langgaard Mailto:carstenl@mips.com
|\ /|||___)(___ MIPS Denmark Direct: +45 4486 5527
| \/ ||| ____) Lautrupvang 4B Switch: +45 4486 5555
TECHNOLOGIES 2750 Ballerup Fax...: +45 4486 5556
Denmark http://www.mips.com
^ permalink raw reply
* Re: [PATCH] Notifier for significant events on i386
From: Vamsi Krishna S . @ 2002-12-12 8:13 UTC (permalink / raw)
To: Alan Cox; +Cc: John Levon, Linux Kernel Mailing List, Stephen Hemminger
In-Reply-To: <1039641336.18587.30.camel@irongate.swansea.linux.org.uk>
On Wed, Dec 11, 2002 at 10:13:33PM +0000, Alan Cox wrote:
> On Wed, 2002-12-11 at 20:27, John Levon wrote:
> > There are notifiers being used that sleep inside the called notifiers.
> >
> > You could easily make a __notifier_call_chain that is lockless and
> > another one that readlocks the notifier_lock ...
>
> The notifier chains assume the users will do the locking needed for
> them. It might be possible to do cool things there with RCU
>
Hmm. If the called notifiers sleep, RCU can't prevent the notifiers
from being unregistered while they are executing. I suppose then that
RCU is not suitable for generic notifiers. It may still be useful
for managing notifiers in very fast paths where acquiring a
read lock may be undesirable (like the oprofile's NMI handler).
Instead of a lockless __notifier_call_chain, I would rather add
a notifier_call_chain_safe() to avoid changing the existing
handlers. Something like the patch below.
The safe version should be used for the trap handlers: we know
that the called notifiers will not sleep and the smp-safeness
makes the handlers simpler.
Thanks,
Vamsi.
--
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: vamsi@in.ibm.com
--
diff -urN -X /home/vamsi/.dontdiff 51-pure/include/linux/notifier.h 51-notifier/include/linux/notifier.h
--- 51-pure/include/linux/notifier.h 2002-12-10 08:15:43.000000000 +0530
+++ 51-notifier/include/linux/notifier.h 2002-12-12 11:53:53.000000000 +0530
@@ -24,6 +24,7 @@
extern int notifier_chain_register(struct notifier_block **list, struct notifier_block *n);
extern int notifier_chain_unregister(struct notifier_block **nl, struct notifier_block *n);
extern int notifier_call_chain(struct notifier_block **n, unsigned long val, void *v);
+extern int notifier_call_chain_safe(struct notifier_block **n, unsigned long val, void *v);
#define NOTIFY_DONE 0x0000 /* Don't care */
#define NOTIFY_OK 0x0001 /* Suits me */
diff -urN -X /home/vamsi/.dontdiff 51-pure/kernel/sys.c 51-notifier/kernel/sys.c
--- 51-pure/kernel/sys.c 2002-12-10 08:15:43.000000000 +0530
+++ 51-notifier/kernel/sys.c 2002-12-12 11:52:45.000000000 +0530
@@ -166,6 +166,29 @@
}
/**
+ * notifier_call_chain_safe - Call functions in a notifier chain
+ * @n: Pointer to root pointer of notifier chain
+ * @val: Value passed unmodified to notifier function
+ * @v: Pointer passed unmodified to notifier function
+ *
+ * Calls each function in a notifier chain in turn while ensuring
+ * that a notifier cannot be unregistered while it is being
+ * executed. Because a read_lock is taken, the called notifiers
+ * must not sleep.
+ */
+
+int notifier_call_chain_safe(struct notifier_block **n, unsigned long val, void *v)
+{
+ int ret;
+
+ read_lock(¬ifier_lock);
+ ret = notifier_call_chain(n, val, v);
+ read_unlock(¬ifier_lock);
+
+ return ret;
+}
+
+/**
* register_reboot_notifier - Register function to be called at reboot time
* @nb: Info about notifier function to be called
*
^ permalink raw reply
* Re: 2.5.51 ide module problem (fwd)
From: Rusty Russell @ 2002-12-12 7:54 UTC (permalink / raw)
To: Jeff Chua; +Cc: Adam J. Richter, Linux Kernel
In-Reply-To: <Pine.LNX.4.50.0212121419410.15261-100000@boston.corp.fedex.com>
In message <Pine.LNX.4.50.0212121419410.15261-100000@boston.corp.fedex.com> you
write:
>
> Rusty,
>
> Any chance that module-init-tools-0.9.3 can be modified to stop looping
> when it detected it has repeated scanning the same module again?
I didn't see this report before, so it's the first I've heard of it.
> > I think the new depmod recurses infinitely when it encounters
> > circular dependencies. It eventually segfaults and leaves a huge
> > modules.dep file from the infinite loop. If you look at the final
> > huge line in that file, you can see where the loop occurred.
> >
> > depmod has no need to do any recursion, since it only needs
> > to determine the immediate dependencies of each module. However,
> > noticing such loops and printing them out would be a handy feature.
Actually, depmod should print out every dependency, so that modprobe
doesn't have to do the recursion check.
But yes, circular dependencies will screw it.
> >depmod will ecounter "Segmentation fault" if the ide.ko and ide-io.ps
> >modules are in /lib/modules/2.5.51/kernel
I'll test, and release a fix.
Thanks for the (indirect) bug report!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: Regarding consistent_alloc
From: Pantelis Antoniou @ 2002-12-12 8:00 UTC (permalink / raw)
To: Dan Malek
Cc: Tom Rini, joakim.tjernlund, acurtis, Paul Mackerras, Matt Porter,
linuxppc-embedded
In-Reply-To: <3DF8057D.3040106@embeddededge.com>
Dan Malek wrote:
> Pantelis Antoniou wrote:
>
>> Perhaps the best way to proceed is just to fix the
>> xxx_cpm_hostalloc() and
>> xxx_cpm_dpalloc() routines to work more intelligently, and to
>> forget about consistent_alloc entirely...
>
>
> You are totally missing the proper use of these functions. The 'cpm'
> functions are used specifically to assist the management of memory
> for the CPM peripherals on the 8xx and 82xx processor. There are often
> unique attributes of mapping these spaces that must be considered. The
> only thing to "fix" in these functions is to make a resource free (and
> smarter resource management) that works for loadable modules.
>
> The purpose of consistent_alloc() functions is to provide a method of
> allocating DMA consistent (i.e. non-cached in our case) memory spaces
> for _any_ purpose. These are functions you will find in other processor
> architectures and have become standard part of many Linux processor
> ports.
>
> The 'cpm' and PCI (and other non-PCI functions like USB OHCI) functions
> will rely on the consistent_alloc() functions to provide consistent
> spaces when necessary. There are some memory mapping assumptions made
> about the way consistent memory is allocated for the purposes of
> portabilty
> and performance.
>
> All of these functions are required and work reasonably well as currently
> implemented when they are used properly.
>
> Thanks.
>
>
> -- Dan
>
>
>
Fine,
I see now.
Since what I'm doing regards the CPM the proper thing to do
is to actually use the 8xx routines.
They only reason that I considered the consistent() routines was
that the 8xx routines are unsuitable for use in modules.
I will prepare a patch that deals with the inefficiencies
of the 8xx routines.
I believe you are the person that is assigned for maintaining
the 8xx series. Can you audit them after I post them
to the list?
Regards
--
Pantelis Antoniou
INTRACOM S.A. Greece
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: separation of sysctl and tcp-window-tracking patch?
From: James Ralston @ 2002-12-12 8:05 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <20021101021236.GA16306@pc.ilinx>
I was catching up on back netfilter-devel messages and saw this.
I absolutely agree. I would *really* like to be able to tune various
netfilter-related settings via /proc, regardless of my opinions on the
tcp-window-tracking patch.
(My specific need is related to DNS service: namely, in many cases, 30
seconds to establish a UDP session simply isn't enough time to permit
a reply to an outstanding DNS query. I want to be able to up that
timeout to something closer to 60 or 120 seconds.)
--
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA
On 2002-10-31 at 21:12:36-0500 netfilter@interlinx.bc.ca wrote:
> There seems to be varied needs for netfilter specific /proc entries.
> The tcp-window-tracking patch seems to me to have placed a /proc
> entry point for netfilter most sanely at
> /proc/sys/net/ipv4/netfilter/. I would also like to have a
> sysctl/proc node to diddle with tunables in my Amanda conntracking
> module.
>
> Specifically the default of 180 seconds for a UDP stream is not long
> enough on the control (master in netfilter parlance) connection of
> an Amanda session, so I would like to override the master's timeout
> value in my conntrack helper. I have tested my theory with a hard
> coded value and it work. Now I would like to make it tunable by the
> user/administrator.
>
> I suppose I could pass an argument while loading the module, but
> using sysctl (and/or /proc) just seems so much more sane. But I
> digress, greatly.
>
> I am wondering if Jozsef and/or Harald would like to separate out
> the creation of the /proc/sys/net/ipv4/netfilter/ node into a
> separate patch for the rest of us to use, rather than having to make
> tcp-window-tracking a prerequisite just to get a proc entry to use.
>
> Thots?
> b.
^ permalink raw reply
* Re: Raid 5 on 2.5.50/2.5.51, dirty array, kernel panic
From: Eurijk @ 2002-12-12 8:08 UTC (permalink / raw)
To: linux-raid
In-Reply-To: <3DF7847D.1050606@mvista.com>
> Please run the dump through ksymoops -m System.map. Without this, its
> quite difficult to tell where the failure occured.
I appear unable to link ksymoops :(, perhaps I can do something similar by hand... (see below)
Let me know, Thanks
-eurijk!
=== BREAK ===
eip c0289977 => c0289960 t make_request
EIP: 0060:[<c0289977>] => c0289880 t raid5_unplug_device
Call Trace Function Reference:
[<c014c90b>] c014c8a0 t bvec_alloc
[<c0249adc>] c02499c0 T generic_make_request
[<c0249b9d>] c0249b60 T submit_bio
[<c0149359>] c0149300 t __bread_slow
[<c01495c8>] c0149590 T __bread
[<c017d9d3>] c017d920 t ext2_fill_super
[<c01deeef>] c01deed0 T sprintf
[<c014dce5>] c014dcc0 T sb_set_blocksize
[<c014d613>] c014d400 T get_sb_bdev
[<c0160eec>] c0160e50 T alloc_vfsmnt
[<c017e46f>] c017e440 t ext2_get_sb
[<c017d920>] c017d920 t ext2_fill_super
[<c014d86f>] c014d810 T do_kern_mount
[<c0162125>] c0162090 t do_add_mount
[<c0162440>] c01622e0 T do_mount
[<c01e0ffc>] c01e0fb0 T copy_from_user
[<c0162828>] c0162760 T sys_mount
[<c010524b>] c01051e0 T prepare_namespace
[<c010507f>] c0105040 t init
[<c0105040>] c0105040 t init
[<c0107249>] c0107244 t kernel_thread_helper
=== BREAK ===
Unable to handle kernel NULL pointer dereference at virtual address 00000088 printing eip:
c0289977
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0060:[<c0289977>] Not tainted
EFLAGS: 00010292
eax: f7d3a200 ebx: f7cfd660 ecx: c19e9680 edx: 00000000
esi: 00000002 edi: 00000000 ebp: f7fb09e0 esp: f7f9fd58
ds: 0068 es: 0068 ss: 0068
Process swapper (pid: 1, threadinfo=f7f9e000 task=f7f9c040)
Stack: f7f9fd54 f7f9fd78 00000000 00000000 f7fb09e0 00000000 00000000 00000010
c014c90b f7ffee40 00000010 f7cfd660 00000002 f7d3a2a8 f7fb09e0 c0249adc
f7d3a2a8 f7fb09e0 00000010 00000001 f7f9fdac 00000000 f7ff87f0 00000000
Call trace: [<c014c90b>] [<c0249adc>] [<c0249b9d>] [<c0149359>] [<c01495c8>]
[<c017d9d3>] [<c01deeef>] [<c014dce5>] [<c014d613>] [<c0160eec>] [<c017e46f>]
[<c017d920>] [<c014d86f>] [<c0162125>] [<c0162440>] [<c01e0ffc>] [<c0162828>]
[<c010524b>] [<c010507f>] [<c0105040>] [<c0107249>]
Code: 8b 87 88 00 00 00 89 44 24 20 48 89 44 24 1c 8b 55 00 8b 45
<0>Kernel panic: Attempted to kill init!
^ permalink raw reply
* RE: portfw on iptables 2.4 kernel problem.
From: Reckhard, Tobias @ 2002-12-12 8:09 UTC (permalink / raw)
To: netfilter
Following up to myself...
> Then that's where our impression differs. I have thought up
> to now that
> INPUT is hit before PREROUTING before FORWARD before
> POSTROUTING before
> OUTPUT. And that a packet may stop being processed between
> PREROUTING and
> FORWARD as well as between POSTROUTING and OUTPUT.
>
> I may check the one NATing firewall I have running.. later.
I just did check that machine and you're right, I was wrong. So INPUT and
OUTPUT rules shouldn't be required in the case we're discussing.
Cheers,
Tobias
^ permalink raw reply
* boot hardhat linux on ide hard disk
From: 于婧 @ 2002-12-12 8:11 UTC (permalink / raw)
To: linuxppc-embedded@lists.linuxppc.org
hi!
I want to boot hardhat linux on an ide hard disk ,that is to say not using nfs.My target board is motorola lopec,using PPC5-Bug.I have copied the entire filesystem to the ide,and I want to put the hardhat kernel image into the flash.But how can I boot from ppcbug to the kernel image?Or,if I copy the filesystem with kernel in it to the ide,How can I boot the kernel now?
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡yuj@mail.ndsc.com.cn
¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-11-26
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Iptables and various domains
From: Raymond Leach @ 2002-12-12 8:14 UTC (permalink / raw)
To: E-GIM Security; +Cc: Netfilter Mailing List
In-Reply-To: <NEBBKLENIBMGHGCLGBPIKEBKCDAA.security@e-gim.es>
[-- Attachment #1: Type: text/plain, Size: 2381 bytes --]
Hi
Yes and maybe no. If your domains are virtually hosted (they resolve to
the same ip numbers) then no. iptables cannot redirect traffic in this
case - it uses ip numbers. You would need to use something like Apache
virtual hosting and possibly redirect pages to accomplish your goal in
this case.
If your domains resolve to different ip numbers, then iptables can be
your solution:
iptables -t nat -A PREROUTING -d www.dom1.com -p tcp --dport 80 -j
REDIRECT --to-destination webserver-1:80
iptables -t nat -A PREROUTING -d www.dom2.com -p tcp --dport 80 -j
REDIRECT --to-destination webserver-1:80
iptables -t nat -A PREROUTING -d www.dom3.com -p tcp --dport 80 -j
REDIRECT --to-destination webserver-2:80
iptables -t nat -A PREROUTING -d www.dom4.com -p tcp --dport 80 -j
REDIRECT --to-destination webserver-2:80
Remember, to use iptables like above, www.dom1.com, www.dom2.com,
www.dom3.com, www.dom4.com must resolve to different ip numbers.
Ray
On Thu, 2002-12-12 at 10:58, E-GIM Security wrote:
> Hi,
>
> Can Iptables route by domains? For example, I have a webserver and my
> firewall with iptables route all request on port 80 throw IP webserver. I
> need add another webserver, and various domains (www.dom1.com, www.dom2.com)
> will be redirect to webserver-1 and other domains (www.dom3.com,
> www.dom4.com) will be redirect to webserver-2. Can IPTables help me? Which
> is the solution)
>
> Thanks and sorry ... my english is very poor.
>
> José Antonio García García
> Technical Internet Solutions
>
> E-GIM +34 952700010
> http://www.e-gim.es
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
( Raymond Leach )
) Knowledge Factory (
( )
) Tel: +27 11 445 8100 (
( Fax: +27 11 445 8101 )
) (
( http://www.knowledgefactory.co.za/ )
) http://www.saptg.co.za/ (
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
o o
o o
.--. .--.
| o_o| |o_o |
| \_:| |:_/ |
/ / \\ // \ \
( | |) (| | )
/`\_ _/'\ /'\_ _/`\
\___)=(___/ \___)=(___/
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: ELKS port of Adventure - help needed :)
From: Paul Nasrat @ 2002-12-12 8:18 UTC (permalink / raw)
To: linux-8086
In-Reply-To: <20021212073945.GC10355@raq465.uk2net.com>
On Thu, Dec 12, 2002 at 07:39:46AM +0000, Paul Nasrat wrote:
> Two possible fixes - there is a new dev86 out which string.c has
> changed in (0.16.10). I'm going to test this out later when I get into
> work. Thanks Robert :)
I can confirm adventure *works* with bcc 0.16.10 which was released on the
5th of December.
This is a bleeding edge bcc with pre-processor, etc. But other than a
complaint about:
advent.h:265: warning: Unexpected text following preprocessor command
But it compiles and runs :)
At least I get to play a game at the lan party now...
Paul
^ permalink raw reply
* Re: Regarding consistent_alloc
From: Wolfgang Denk @ 2002-12-12 8:18 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: Dan Malek, Tom Rini, joakim.tjernlund, acurtis, Paul Mackerras,
Matt Porter, linuxppc-embedded
In-Reply-To: <3DF8420A.4040409@intracom.gr>
In message <3DF8420A.4040409@intracom.gr> you wrote:
>
> They only reason that I considered the consistent() routines was
> that the 8xx routines are unsuitable for use in modules.
This is trivial to fix - just add the missing EXPORT_SYMBOL
statements to arch/ppc/kernel/ppc_ksyms.c ; but be aware that the
current implementation will leak CPM resources upon module unload -
which is probably the main reason that these symbols are not expoted
for use in modules.
> I will prepare a patch that deals with the inefficiencies
> of the 8xx routines.
Don't re-invent the wheel. There is an implementation of this code
available in our kernel source tree (linux-2.4 module in our CVS)
which for example provides both m8xx_cpm_dpalloc / m8xx_cpm_dpfree
I sent the patches to Tom Rini. Several times. I don't know why they
never made it into the official kernel source tree. [This is why we
have to maintain our own source tree.]
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
The C-shell doesn't parse. It adhoculates.
- Casper.Dik@Holland.Sun.COM in <3ol96k$b2j@engnews2.Eng.Sun.COM>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Install in config.emu
From: Lars Bjørndal @ 2002-12-12 8:19 UTC (permalink / raw)
To: linux-msdos
Please help:
The install-command seems to not work in config.emu under windows
98-dos. Look at this:
device=c:\ems.sys
files=40
lastdrive=z
country=047,850,c:\country.sys
device=c:\cdrom.sys
device=aspi.sys
install=c:\SUBST.EXE I: C:\
install=c:\command.com /c "c:\lredir.exe c: linux\fs/w98"
SHELL=C:\COMMAND.COM C:\ /e:1024 /p /k c:\autoemu.bat
None of these install-commands doesn't work.
As you can see, I want to get the drive letter c: to be associated
with the pat /w98. How can I do this?
This procedure works fine under ms-dos 6.22.
Lars
^ permalink raw reply
* Re: 2.4.20-ac2 and i810 drm
From: Arjan van de Ven @ 2002-12-12 8:32 UTC (permalink / raw)
To: Dave Airlie; +Cc: linux-kernel, alan
In-Reply-To: <3457.210.8.93.34.1039665245.squirrel@www.csn.ul.ie>
On Thu, 2002-12-12 at 04:54, Dave Airlie wrote:
>
> I've been running 2.4.20-rc4 up to now with DRM enabled for my i810
> chipset and XFree86 4.2 from RH 7.3.
>
> When I run my OpenGL application (internal app) under 2.4.20-ac2 with the
> same .config when I ctrl-c the application the machine hangs hard.
>
> It is the only application running on the X server so the X server
> restarts when I exit the app.. under 2.4.20-rc4 this works fine...
I just got an updated source for the i810 DRM and will port it to -ac2;
lots of i810 bugfixes
^ permalink raw reply
* Re: pnp/IDE question- help fixing up a patch
From: Andre Hedrick @ 2002-12-12 8:33 UTC (permalink / raw)
To: Ted Kaminski; +Cc: linux-kernel, Alan Cox, Marcelo Tosatti, Jens Axboe
In-Reply-To: <007e01c2a19b$934e9a00$6400a8c0@win01>
Ted,
Somebody asked me to poke my nose in here, so here goes.
The difference in the two locations has to do with early initalization.
One the issues of concern in the patch, is the usage of "passive".
A stronger position for setup would have a hwif->intq_mode operator.
Regardless if it is a bit field or not.
This would force ide-probe to initialize the hwif_intr properly.
Next the mask of the field would provide a method for poking the
drive_is_ready().
This would remove several issue.
One the config option for share or not interrupts goes away.
The list is short and obvious.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Wed, 11 Dec 2002, Ted Kaminski wrote:
> Hello all,
>
> I've got an ide, and an idepnp question... (for 2.4)
>
> I'm working on refining a patch sent previously
> (http://groups.google.com/groups?selm=20021108061020.A14168%40localhost) to
> be less intrusive. I'll be refering to things done in that patch...
>
> The short of it is, this sb16 pnpide interface apparently cannot use
> ALTSTATUS at a certain point. (I'm no ide whiz, I'm just simplifying the
> code that David Meybohm wrote, so maybe I'm off a bit) at any rate, this
> seems to require a new flag be listed along with the hardware information.
>
> His solution was to add
> + int no_passive; /* no passive status tests */
> to hw_reg_s in ide.h and check that flag in drive_is_ready()
>
> I *think* it's out of place. It seems to me it'd be more appropriate to add
> + unsigned no_passive : 1; /* no passive status tests */
> to hwif_s in ide.h. Right next to a few other bitfields
>
> Which is better? or is there a different, even better spot?
>
> As for the idepnp part, he added a "dev = NULL" into the loop, and was
> unsure of whether or not this was a good idea. I have the same question.
> Or perhaps this smells of a seperate patch?
>
> I'd rather ask these question in the form of my own patch, but... I'm a bit
> short on time, atm. sorry.
>
> Thanks in advace,
> -Ted
>
> -
> 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: PATCH: Four function buttons on DELL Latitude X200
From: Vojtech Pavlik @ 2002-12-12 8:43 UTC (permalink / raw)
To: Pavel Machek; +Cc: H. Peter Anvin, linux-kernel
In-Reply-To: <20021210213444.GA451@elf.ucw.cz>
On Tue, Dec 10, 2002 at 10:34:44PM +0100, Pavel Machek wrote:
> > > In article <m3d6ocjd81.fsf@Janik.cz> you wrote:
> > > > this patch add support for four functions key on DELL Latitude X200.
> > >
> > > we need a more generic appoach to handle those key codes for various
> > > extensions. I think a pure software reconfiguration of the keymaps or a
> > > daemon trakcing the raw codes is fine. Perhaps we can make something like a
> > > hook into the kernel where all untrapped function keys are send to in raw
> > > format?
> >
> > The PC only has so many possible keycodes (with E0 and E1 it's still
> > in the sub-300 range.) It won't fit within 128, but I would really
> > like an algorithmic mapping from scancodes to keycodes so we don't
> > continue to have this problem.
> >
> > For example, using a 16-bit keycode model:
> >
> >
> > Scancode Keycode (binary)
> > mxxxxxxx m0000000 0xxxxxxx
> > E0 mxxxxxxx m0000000 1xxxxxxx
> > E1 mxxxxxxx yyyyyyyy mxxxxxxx yyyyyyyy
> >
> > m = make/break bit
>
> Well, nothing prevents keyboard manufacturers from using 0xe2 as a
> prefix, too.
Except that it would pretty much confuse any existing OS. The only key
prefix is E0, because E1 is only used for a single key, and that's fake
right shift, which should be discarded anyway even before a keycode is
generated.
Anyway, we definitely don't want scancode dependent keycodes. Keycodes
should be the same for all types of keyboards (Be it PS/2, USB, or ADB),
so that you can have a single set of N keymaps (us, gb, french, czech,
whatever), and not N*M keymaps for different languages and keyboard
types.
This simplifies things both in the kernel (a bit), and userspace (a lot).
Now, speaking about a fixed scancode->something mapping, atkbd.c in 2.5
uses this encoding:
xxxxxxxx -> 0 xxxxxxxx
E0 xxxxxxxx -> 1 xxxxxxxx
Note that no make/break bit is used, as the keyboard is operated in
"Set 2" of scancodes, where release is signalled by the F0 prefix, and
not by the highest bit. And since the keycode is passed on as an input
event, we don't need to encode make/break into the keycode on the output
either.
The real question is, when we have these 16-bit (or more bit) keycodes,
how do we export them to the userspace? In cooked mode, there is no
problem, we can extend the keymaps. But both medium raw and raw modes
are pretty much limited in the number of keys they can carry. See 2.5
keyboard.c for the current imperfect solution.
IMHO applications which now use raw mode should instead switch to using
the event devices in /dev/input ...
> I think there are really *weird* keyboards out there.
There are, but fortunately not that much weird.
--
Vojtech Pavlik
SuSE Labs
^ permalink raw reply
* Re: [LARTC] HTB and theory
From: Abraham van der Merwe @ 2002-12-12 8:36 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103945416224487@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 2685 bytes --]
Hi Stef!
> > > > How does this influence the shaping results and the shaping of other
> > > > classes? I've actually asked a similar question before: If you have
> > > >
> > > > 1:1
> > > > / \
> > > > / \
> > > > 1:2 1:3
> > > > /|\ \------
> > > > / | \ \ \
> > > > 1:4 1:5 1:6 1:7 1:8
> > > >
> > > > if 1:7 and 1:8 respects the rate/ceil of 1:3 and 1:3 respects the
> > > > rate/ceil of 1:1, but 1:4 does not respect the rate/ceil of 1:2 and 1:2
> > > > respects the rate/ceil of 1:1, does the shaping of 1:3 work as normal
> > > > and only those classes under 1:2 are adversely affected or not? from
> > > > your previous answer, it seems that the classes under 1:3 would not be
> > > > affected, but I would love to know why. what happens with 1:4 requests
> > > > some bandwidth which 1:2 does not have...
> > >
> > > It's easier if you add some numbers of ceil/rate to understand the
> > > question.
> > >
> > > I'm going to create an extra page on www.docum.org with your questions
> > > and my answer to explain how rate and ceil of classes and parent classes
> > > are used. Ok?
> >
> > That would be great, thanks
> I wrote some more information about ceil and rate. You can find it on the faq
> page on www.docum.org under "Basic rules for traffic shaping with HTB". If
> you have more questions, let me know and I will try to answer them.
> Remember, htb will work if you don't follow this rule. But it will be less
> obviuos to figure out how the bandwidth will be distributed.
I think your explanation of "rate of class" in your FAQ is wrong. it
caught me as well, but from devik's faq page
(http://luxik.cdi.cz/~devik/qos/htb/htbfaq.htm):
------------< snip <------< snip <------< snip <------------
What if sum of child rates is greater than parent rate ?
Then interesting things can happen. Total rate delivered by children can be
higher that parent's rate (thus its rate is not respected). However when sum
of actual child rates are under parent's rate then borrowing will occur like
in regular case.
------------< snip <------< snip <------< snip <------------
Thus, if sum (rate of childs) > parent rate, then the parent rate is _not
respected_.
--
Regards
Abraham
An American's a person who isn't afraid to criticize the president but is
always polite to traffic cops.
___________________________________________________
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: [parisc-linux] Re: Solved: Kernel crash when loggin in via ssh
From: Thibaut VARENE @ 2002-12-12 8:36 UTC (permalink / raw)
To: Randolph Chung; +Cc: M. Grabert, Carlos O'Donell, parisc-linux
In-Reply-To: <20021212000511.GH19331@tausq.org>
Le jeudi, 12 d=E9c 2002, =E0 01:05 Europe/Paris, Randolph Chung a =E9crit =
:
>> gcc-3.0_3.0.4-13 produces a working kernel, gcc-3.2-3.2.2-0pre0=20
>> produces
>> a miscompiled kernel (faulty networking, causes kernel crash).
>
> Just to reiterate Dave's point, this is not necessarily a compiler
> problem.
I'm pretty interested to help finding out whether it is or not a=20
compiler problem.
I had the exact same problem that what was mentioned here, a couple of=20=
months ago, with both native and cross compiler (gcc-3.2).
Any attempt to login on the box via network led to a kernel crash.
I'll try to reproduce it to track down where the kernel crashed, since=20=
I don't remember it off hand.
Anyway, I'd be interested in learning what you guys may suspect as=20
other possible cause for this _weird_ behaviour...
HTH,
Thibaut VARENE
The PA/Linux ESIEE Team
http://pateam.esiee.fr/=
^ permalink raw reply
* Re: Regarding consistent_alloc
From: Pantelis Antoniou @ 2002-12-12 8:37 UTC (permalink / raw)
To: Wolfgang Denk
Cc: Dan Malek, Tom Rini, joakim.tjernlund, acurtis, Paul Mackerras,
Matt Porter, linuxppc-embedded
In-Reply-To: <20021212081841.390C7C613A@atlas.denx.de>
Wolfgang Denk wrote:
>In message <3DF8420A.4040409@intracom.gr> you wrote:
>
>
>>They only reason that I considered the consistent() routines was
>>that the 8xx routines are unsuitable for use in modules.
>>
>>
>
>This is trivial to fix - just add the missing EXPORT_SYMBOL
>statements to arch/ppc/kernel/ppc_ksyms.c ; but be aware that the
>current implementation will leak CPM resources upon module unload -
>which is probably the main reason that these symbols are not expoted
>for use in modules.
>
Yes I know, that is one the main deficiencies I'm talking about...
>
>>I will prepare a patch that deals with the inefficiencies
>>of the 8xx routines.
>>
>>
>
>Don't re-invent the wheel. There is an implementation of this code
>available in our kernel source tree (linux-2.4 module in our CVS)
>which for example provides both m8xx_cpm_dpalloc / m8xx_cpm_dpfree
>
>I sent the patches to Tom Rini. Several times. I don't know why they
>never made it into the official kernel source tree. [This is why we
>have to maintain our own source tree.]
>
>
>Best regards,
>
>Wolfgang Denk
>
Could you please sent me these patches, since I'm behind a firewall?
But still there is the matter of the m8xx_cpm_hostalloc routines.
BTW Wolfgang have you seen my patch for the QMC? Any comments?
Please note that I had a few requests for the QMC patch directly
by people off the list, so it's not like no-one is using it...
Regards
--
Pantelis Antoniou
INTRACOM S.A. Greece
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Is this going to be true ?
From: Kai Henningsen @ 2002-12-12 6:50 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <3DF77410.3010103@alvie.com>
alvieboy@alvie.com (Alvaro Lopes) wrote on 11.12.02 in <3DF77410.3010103@alvie.com>:
> Serge Kuznetsov wrote:
>
> >I totaly agree with you.
> >
> >But why do you think Microsoft will come back to *nix lane?
> >AFAIK, they closed their Xenix project back in 80s.
> >Do you think they will resurrect it?
> >
> >
> I just remembered... what happened to SCO ? Isn't it still from Microsoft?
Well, I suppose there are still a few MS copyright notices in there, but
MS sold it off a *long* time ago.
It was not quite recently borged by Caldera, the same people who borged Dr
DOS^W^WNovell DOS. Remember what OS *they* started out with?
MfG Kai
^ permalink raw reply
* Re: Agressive selective pre-allocation
From: Ragnar Kjørstad @ 2002-12-12 8:47 UTC (permalink / raw)
To: reiserfs-list
In-Reply-To: <20021210111228.GA9155@shuttle.mothership.home.dhs.org>
On Tue, Dec 10, 2002 at 12:12:28PM +0100, Stefan Fleiter wrote:
> > mbox's aren't an issue, if you have them then you probably don't care too
> > much about performance anyway.
>
> I switched some large mailing lists with thousands of messages from mbox to
> maildir with mutt. Changing mailboxes lasted maybe 2 or 3 times longer,
> so I switched back to mbox *for speed*.
Yes, maildir is not always faster.
First problem is disk-layout. The way it works with reiserfs3.6 and
default hashes the inodes and files are written in different orders and
the disk does a lot of unneeded seeks. A workaround is to use a hash
that automagicly orders inodes and files the same way. A better way is
probably to store the stat-data with the directory-data. I think that is
on the schedule, is it not?
It is also important that readdir-order matches the ondisk layout, but
that is perhaps already the case?
Possible the overhead of the systemcalls is also significant, but my
guess is that it is negletable compared to io-performance.
Next problem is readahead. When the whole mailbox is in a single file
the OS is able to use readahead to improve performance, but it doesn't
seem to work as well when reading a whole directory. This is perhaps the
thoughest one to solve, IMHO.
However, the single most important fix would be the mail-clients. If I'm
not mistaken mutt reads the whole mail, and that's simply not required.
It should only read the headers. That will speed things up by a huge
factor when you have mails with attachments and so on. It must also learn
that it shouldn't reread the folder everytime it's updated!
Right now the case is pretty much that none or few of the potential
performance-benefits of maildir are made use of, and the drawbacks are
hitting much harder then they ought to. I bet it's only temporary
though. Reiserfs has the potential to make faster mailsystems with
the use of maildir! :-)
--
Ragnar Kjørstad
^ permalink raw reply
* Iptables Log - session Log
From: Jens Kühlberg @ 2002-12-12 8:49 UTC (permalink / raw)
To: netfilter
Hello,
I looking for a tool, witch can analyse iptales logs and show me only
connections-session in realtime and not the complete IP-traffic.
Bye
Jens
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
^ permalink raw reply
* Re: [Dri-devel] Re: 2.4.20 AGP for I845 wrong ?
From: Nicolas ASPERT @ 2002-12-12 8:57 UTC (permalink / raw)
To: David Dawes; +Cc: Margit Schubert-While, linux-kernel, davej, faith, dri-devel
In-Reply-To: <20021211205854.A7654@xfree86.org>
David Dawes wrote:
>
> No, I think it should be intel_845_setup too, since the 845G docs on
> Intel's public web site show that the behaviour is like the 845 when
> the on-board graphics isn't enabled. I made that change in my
> locally maintained version of the agpgart driver a little while ago,
> but haven't had the opportunity to test it with an external AGP card
> in an 845G box yet.
Damn, you're right. Now I got the docs from Intel (at the time were the
patch to support 845g was submitted, they were just not available yet),
and truly the specs are closer to the 845, so let's switch to
'intel_845_setup' to initialize the 845g. Not that it should change
things too much, but it will avoid further confusions....
Best regards.
Nicolas
PS: I hope the IBM annoyances for mails sent to lkml stopped...
--
Nicolas Aspert Signal Processing Institute (ITS)
Swiss Federal Institute of Technology (EPFL)
^ 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.