* Re: [PATCH] 2.4.20 IDE for 2.4.21-pre3
From: Michael Madore @ 2003-01-08 18:29 UTC (permalink / raw)
To: Tomas Szepe; +Cc: linux-kernel
In-Reply-To: <20030108182112.GQ823@louise.pinerecords.com>
Tomas Szepe wrote:
>>[mmadore@aslab.com]
>>
>>I get the following oops when running 2.4.21-pre3 +
>>2.4.21-pre3-2420ide-1. The oops occurred after running the Cerberus
>>stress test for about 5 hours. The machine uses an ASUS A7N8X single
>>AMD Athlon XP motherboard with the Nvidia nforce2 chipset. I had to
>>pass ide0=ata66 ide1=ata66 to the kernel in order to use DMA.
>>
>>
>
>Michael,
>
>are you able to reproduce this oops with vanilla 2.4.20?
>
>
>
I'll try this and post my results.
Mike
^ permalink raw reply
* some questions about flush_map() in pageattr.c
From: Thomas Schlichter @ 2003-01-08 18:29 UTC (permalink / raw)
To: linux-kernel
Hello,
currently I am writing a patch to be able to make TLBs on any IO-devices
coherent to the CPUs TLBs. So I was looking in the kernel-sources for places
where not only the local but all TLBs are flushed. So I came up with
flush_map() in the arch/i386/mm/ and the arch/x86_64/mm/ directories.
Now my questions:
1. In the x86_64 part of code the flush_kernel_map() does a
local_flush_tlb_one() but in the i386 parts a local_flush_tlb_all(). Is the
mentioned athlon bug the cause or can it be changed to work as in the x86_64
code?
2. Can the flush_map() function be replaced by a flush_tlb_all() respective
flush_tlb_page(). If I can do so, what would be the correct value for the
first argument 'vma'?
If it is not posible could you please tell me why not...?
Thank you very much!
Thomas Schlichter
^ permalink raw reply
* Re: Status of linuxppc_2.5
From: Boris Bezlaj @ 2003-01-08 18:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Pantelis Antoniou, linuxppc-dev
In-Reply-To: <1042049915.787.9.camel@zion.wanadoo.fr>
On Wed, Jan 08, 2003 at 07:18:35PM +0100, Benjamin Herrenschmidt wrote:
>
> What patch ? I'm interested ;)
It just adds +#include <linux/interrupt.h> to swim3.c
> So far, swim3 in 2.5 is not up-to-date to new BIO semantics in 2.5. I've wanted
> to do that for some time now but didn't find time yet.
But does the writing work in 2.4.x ? For me it works flawlessly in 2.2.x,
but in 2.4 there are some problems with settling (only when writing; read
is fine), which im trying to figure out and fix.
--
With best regards,
Boris B.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH][FBDEV]: fb_putcs() and fb_setfont() methods
From: Antonino Daplas @ 2003-01-08 18:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: James Simmons, Petr Vandrovec, Linux Fbdev development list,
Linux Kernel List
In-Reply-To: <Pine.GSO.4.21.0301081142190.21171-100000@vervain.sonytel.be>
On Wed, 2003-01-08 at 18:47, Geert Uytterhoeven wrote:
> On Tue, 7 Jan 2003, James Simmons wrote:
> > > Why? (a) only those which will use putcs, and (b) I see no 512 chars limit
> > > anywhere in new code. And in old code it is there only because of passed
> > > data are only 16bit, not 32bit wide... With simple search&replace you can
> > > extend it to any size you want, as long as you'll not use sparse font
> > > bitmap.
> >
> > The current "core" console code screen_buf layout is designed after VGA
> > text mode. 16 bits which only 8 bits are used to represent a character, 9
> > if you have high_fonts flag set. The other 8,7 bits are for attributes.
> > This is very limiting and it does effect fbcon.c :-( I like to the console
> > system remove these awful limitation in the future. This why I like to see
> > fbdev drivers avoid touching strings from the console layer.
>
> Please note that Tony's new accel_putcs() code uses __u32 to pass the character
> indices. So it's not limited to 256/512 characters per font. Fonts can be as
> large as you want. Sparse fonts can be handled as well, if accel_putcs() takes
> care of the conversion from sparse character indices to dense character
> indices.
>
> His code can be viewed as a way to do multiple monochrome to color expansions
> with one single call, using a predefined table of patterns. Quite generic,
> unless you want to have multi-color fonts later :-)
>
:-) I did not want prolong the discussion, but...
Geert is correct that the functions are generic. The fb_putcs() and
fb_setfont() can be compared to Tile blitting. Tile blitting is a
common operation in some games such as Warcraft, Starcraft, and most
RPG's. I'm think there is Tile Blitting support in DirectFB.
In a tile-based game, the basic unit is a Tile which is just a bitmap
with a predefined width and height. The game has several tiles stored in
memory each with it's own unique id. To draw the background/layer, a
TileMap is constructed which is basically another array. Its format is
something like this - TileMap[x] = y which means draw Tile y at screen
position x.
In the fbcon perspective, we can think of each character as a Tile, and
fontdata as the collection of tiles. fb_char.data is basically a
TileMap. Of course, tile blitting in games is more complicated than
this, since games have multiple layers for the background, so layer
position, transparency, etc has to be considered.
So maybe if we can rename fb_putcs() to fb_tileblit(), fb_setfont() to
fb_loadtiles(), struct fb_chars to struct fb_tilemap and struct
fb_fontdata to struct fb_tiledata, maybe it will be more acceptable?
It can be even be expanded by including fb_tiledata.depth
fb_tiledata.cmap so we can support multi-colored tiled blitting.
Tony
^ permalink raw reply
* Re: Corruption on mangle/INPUT when MARKing packets
From: Patrick McHardy @ 2003-01-08 18:23 UTC (permalink / raw)
To: Harald Welte; +Cc: Costa Tsaousis, netfilter-devel
In-Reply-To: <20030108170733.GR9467@sunbeam.de.gnumonks.org>
[-- Attachment #1: Type: text/plain, Size: 1593 bytes --]
Harald Welte wrote:
>On Mon, Jan 06, 2003 at 05:26:55PM +0100, Patrick McHardy wrote:
>
>
>>I think the problem lies within ip_route_me_harder. It is called on
>>mangled packets in the INPUT chain
>>and changes skb->dst with new route after setting key.src = 0 if it's
>>not a local address.
>>
>>
>
>well spotted. This is exactly the problem.
>
>So the question is: Do we really need to call route_me_harder() in the
>INPUT chain? We could argue that if somebody wants to do a change
>affecting the routing decision should make that change before the
>routing decison, not after it.
>
That sound reasonable. Besides, i think it is a rarely used feature anyways.
The difference as far as i can see between doing the change in PRE_ROUTING
and INPUT chain is that in PRE_ROUTING chain you may not know a packet
is addressed to a local address (in case it's a dynamically assigned ip).
I've written a match some time ago to match inet_addr_type
(rtm_types from include/linux/rtnetlink.h). We use it for DNAT to
distinguish
between packets that are to-be-routed and packets that are addressed at
a local ip
without having to know the ip in advance (for automatically generated
rules).
I'm attaching the patch, perhaps you like it.
Regards,
Patrick
>
>If we agree on this change, the solution is easy. Just call
>ipt_route_hook() instead of ipt_local_hook() at NF_IP_LOCAL_IN.
>
>Otherwise we'd need a seperate route_me_harder function for the case of
>non-local packets. But I don't think this makes sense at all.
>
>Patch attached (and put into 'pending').
>
>Thanks.
>
>
>
[-- Attachment #2: addrtype-pom.diff --]
[-- Type: text/plain, Size: 12753 bytes --]
diff -urN patch-o-matic-20020823/extra/addrtype.patch patch-o-matic-addrtype/extra/addrtype.patch
--- patch-o-matic-20020823/extra/addrtype.patch Thu Jan 1 01:00:00 1970
+++ patch-o-matic-addrtype/extra/addrtype.patch Wed Sep 18 14:14:50 2002
@@ -0,0 +1,139 @@
+diff -urN -X dontdiff.txt linux-2.4.20-pre5-clean/include/linux/netfilter_ipv4/ipt_addrtype.h linux-2.4.20-pre5/include/linux/netfilter_ipv4/ipt_addrtype.h
+--- linux-2.4.20-pre5-clean/include/linux/netfilter_ipv4/ipt_addrtype.h Thu Jan 1 01:00:00 1970
++++ linux-2.4.20-pre5/include/linux/netfilter_ipv4/ipt_addrtype.h Wed Sep 18 12:36:06 2002
+@@ -0,0 +1,28 @@
++#ifndef _IPT_ADDRTYPE_H
++#define _IPT_ADDRTYPE_H
++
++#define IPT_ADDRTYPE_SOURCE 0x1
++#define IPT_ADDRTYPE_DEST 0x2
++
++/* from linux/rtnetlink.h */
++
++#define IPT_ADDRTYPE_RTN_UNSPEC 0x0001
++#define IPT_ADDRTYPE_RTN_UNICAST 0x0002
++#define IPT_ADDRTYPE_RTN_LOCAL 0x0004
++#define IPT_ADDRTYPE_RTN_BROADCAST 0x0008
++#define IPT_ADDRTYPE_RTN_ANYCAST 0x0010
++#define IPT_ADDRTYPE_RTN_MULTICAST 0x0020
++#define IPT_ADDRTYPE_RTN_BLACKHOLE 0x0040
++#define IPT_ADDRTYPE_RTN_UNREACHABLE 0x0080
++#define IPT_ADDRTYPE_RTN_PROHIBIT 0x0100
++#define IPT_ADDRTYPE_RTN_THROW 0x0200
++#define IPT_ADDRTYPE_RTN_NAT 0x0400
++#define IPT_ADDRTYPE_RTN_XRESOLVE 0x0800
++
++struct ipt_addrtype_info {
++ u_int16_t type;
++ u_int8_t mode;
++ u_int8_t invert;
++};
++
++#endif
+diff -urN -X dontdiff.txt linux-2.4.20-pre5-clean/net/ipv4/netfilter/ipt_addrtype.c linux-2.4.20-pre5/net/ipv4/netfilter/ipt_addrtype.c
+--- linux-2.4.20-pre5-clean/net/ipv4/netfilter/ipt_addrtype.c Thu Jan 1 01:00:00 1970
++++ linux-2.4.20-pre5/net/ipv4/netfilter/ipt_addrtype.c Wed Sep 18 13:41:16 2002
+@@ -0,0 +1,103 @@
++#include <linux/module.h>
++#include <linux/skbuff.h>
++#include <linux/netdevice.h>
++
++#include <net/route.h>
++
++#include <linux/netfilter_ipv4/ipt_addrtype.h>
++#include <linux/netfilter_ipv4/ip_tables.h>
++
++MODULE_LICENSE("GPL");
++
++static int match(const struct sk_buff *skb, const struct net_device *in,
++ const struct net_device *out, const void *matchinfo,
++ int offset, const void *hdr, u_int16_t datalen,
++ int *hotdrop)
++{
++ const struct ipt_addrtype_info *info = matchinfo;
++ const struct iphdr *iph = skb->nh.iph;
++ unsigned type;
++ u_int32_t addr =
++ (info->mode == IPT_ADDRTYPE_SOURCE) ? iph->saddr : iph->daddr;
++
++ type = inet_addr_type(addr);
++ switch (type) {
++ case RTN_UNSPEC:
++ if (info->type&IPT_ADDRTYPE_RTN_UNSPEC)
++ return 1 ^ info->invert;
++ break;
++ case RTN_UNICAST:
++ if (info->type&IPT_ADDRTYPE_RTN_UNICAST)
++ return 1 ^ info->invert;
++ break;
++ case RTN_LOCAL:
++ if (info->type&IPT_ADDRTYPE_RTN_LOCAL)
++ return 1 ^ info->invert;
++ break;
++ case RTN_BROADCAST:
++ if (info->type&IPT_ADDRTYPE_RTN_BROADCAST)
++ return 1 ^ info->invert;
++ break;
++ case RTN_ANYCAST:
++ if (info->type&IPT_ADDRTYPE_RTN_ANYCAST)
++ return 1 ^ info->invert;
++ break;
++ case RTN_MULTICAST:
++ if (info->type&IPT_ADDRTYPE_RTN_MULTICAST)
++ return 1 ^ info->invert;
++ break;
++ case RTN_BLACKHOLE:
++ if (info->type&IPT_ADDRTYPE_RTN_BLACKHOLE)
++ return 1 ^ info->invert;
++ break;
++ case RTN_UNREACHABLE:
++ if (info->type&IPT_ADDRTYPE_RTN_UNREACHABLE)
++ return 1 ^ info->invert;
++ break;
++ case RTN_PROHIBIT:
++ if (info->type&IPT_ADDRTYPE_RTN_PROHIBIT)
++ return 1 ^ info->invert;
++ break;
++ case RTN_THROW:
++ if (info->type&IPT_ADDRTYPE_RTN_THROW)
++ return 1 ^ info->invert;
++ break;
++ case RTN_NAT:
++ if (info->type&IPT_ADDRTYPE_RTN_NAT)
++ return 1 ^ info->invert;
++ break;
++ case RTN_XRESOLVE:
++ if (info->type&IPT_ADDRTYPE_RTN_XRESOLVE)
++ return 1 ^ info->invert;
++ break;
++ }
++
++ return info->invert;
++}
++
++static int checkentry(const char *tablename, const struct ipt_ip *ip,
++ void *matchinfo, unsigned int matchsize,
++ unsigned int hook_mask)
++{
++ if (matchsize != IPT_ALIGN(sizeof(struct ipt_addrtype_info)))
++ return 0;
++
++ return 1;
++}
++
++static struct ipt_match addrtype_match = { { NULL, NULL }, "addrtype", &match,
++ &checkentry, NULL, THIS_MODULE };
++
++static int __init init(void)
++{
++ return ipt_register_match(&addrtype_match);
++}
++
++static void __exit fini(void)
++{
++ ipt_unregister_match(&addrtype_match);
++
++}
++
++module_init(init);
++module_exit(fini);
diff -urN patch-o-matic-20020823/extra/addrtype.patch.config.in patch-o-matic-addrtype/extra/addrtype.patch.config.in
--- patch-o-matic-20020823/extra/addrtype.patch.config.in Thu Jan 1 01:00:00 1970
+++ patch-o-matic-addrtype/extra/addrtype.patch.config.in Wed Sep 18 14:11:44 2002
@@ -0,0 +1,2 @@
+ dep_tristate ' TTL match support' CONFIG_IP_NF_MATCH_TTL $CONFIG_IP_NF_IPTABLES
+ dep_tristate ' address type match support' CONFIG_IP_NF_MATCH_ADDRTYPE $CONFIG_IP_NF_IPTABLES
diff -urN patch-o-matic-20020823/extra/addrtype.patch.help patch-o-matic-addrtype/extra/addrtype.patch.help
--- patch-o-matic-20020823/extra/addrtype.patch.help Thu Jan 1 01:00:00 1970
+++ patch-o-matic-addrtype/extra/addrtype.patch.help Wed Sep 18 13:55:27 2002
@@ -0,0 +1,20 @@
+Author: Patrick McHardy <kaber@trash.net>
+Status: Seems to work ..
+
+This match allows you to match address types.
+Valid types are:
+
+UNSPEC
+UNICAST
+LOCAL
+BROADCAST
+ANYCAST
+MULTICAST
+BLACKHOLE
+UNREACHABLE
+PROHIBIT
+THROW
+NAT
+XRESOLVE
+
+blabla
diff -urN patch-o-matic-20020823/extra/addrtype.patch.makefile patch-o-matic-addrtype/extra/addrtype.patch.makefile
--- patch-o-matic-20020823/extra/addrtype.patch.makefile Thu Jan 1 01:00:00 1970
+++ patch-o-matic-addrtype/extra/addrtype.patch.makefile Wed Sep 18 14:14:39 2002
@@ -0,0 +1,2 @@
+obj-$(CONFIG_IP_NF_MATCH_TCPMSS) += ipt_tcpmss.o
+obj-$(CONFIG_IP_NF_MATCH_ADDRTYPE) += ipt_addrtype.o
diff -urN extensions/libipt_addrtype.c extensions/libipt_addrtype.c
--- extensions/libipt_addrtype.c Thu Jan 1 01:00:00 1970
+++ extensions/libipt_addrtype.c Wed Sep 18 15:14:35 2002
@@ -0,0 +1,256 @@
+/* Shared library add-on to iptables to add TTL matching support
+ *
+ * This program is released under the terms of GNU GPL */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <getopt.h>
+#include <iptables.h>
+
+#include <linux/netfilter_ipv4/ip_tables.h>
+#include <linux/netfilter_ipv4/ipt_addrtype.h>
+
+static void help(void)
+{
+ printf(
+"Address type match v%s options:\n"
+" --source Match source address\n"
+" --dest Match destination address\n"
+" [!] --type [UNSPEC|UNICAST|LOCAL|BROADCAST|ANYCAST|MULTICAST|\n"
+" BLACKHOLE|UNREACHABLE|PROHIBIT|THROW|NAT|XRESOLVE]\n"
+" [,...]\n"
+, IPTABLES_VERSION);
+}
+
+static void init(struct ipt_entry_match *m, unsigned int *nfcache)
+{
+ /* caching not yet implemented */
+ *nfcache |= NFC_UNKNOWN;
+}
+
+static int
+parse_type(const char *type, size_t strlen, struct ipt_addrtype_info *info)
+{
+ if (strncasecmp(type, "UNSPEC", strlen) == 0)
+ info->type |= IPT_ADDRTYPE_RTN_UNSPEC;
+ else if (strncasecmp(type, "UNICAST", strlen) == 0)
+ info->type |= IPT_ADDRTYPE_RTN_UNICAST;
+ else if (strncasecmp(type, "LOCAL", strlen) == 0)
+ info->type |= IPT_ADDRTYPE_RTN_LOCAL;
+ else if (strncasecmp(type, "BROADCAST", strlen) == 0)
+ info->type |= IPT_ADDRTYPE_RTN_BROADCAST;
+ else if (strncasecmp(type, "ANYCAST", strlen) == 0)
+ info->type |= IPT_ADDRTYPE_RTN_ANYCAST;
+ else if (strncasecmp(type, "MULTICAST", strlen) == 0)
+ info->type |= IPT_ADDRTYPE_RTN_MULTICAST;
+ else if (strncasecmp(type, "BLACKHOLE", strlen) == 0)
+ info->type |= IPT_ADDRTYPE_RTN_BLACKHOLE;
+ else if (strncasecmp(type, "UNREACHABLE", strlen) == 0)
+ info->type |= IPT_ADDRTYPE_RTN_UNREACHABLE;
+ else if (strncasecmp(type, "PROHIBIT", strlen) == 0)
+ info->type |= IPT_ADDRTYPE_RTN_PROHIBIT;
+ else if (strncasecmp(type, "THROW", strlen) == 0)
+ info->type |= IPT_ADDRTYPE_RTN_THROW;
+ else if (strncasecmp(type, "NAT", strlen) == 0)
+ info->type |= IPT_ADDRTYPE_RTN_NAT;
+ else if (strncasecmp(type, "XRESOLVE", strlen) == 0)
+ info->type |= IPT_ADDRTYPE_RTN_XRESOLVE;
+ else
+ return 0;
+ return 1;
+}
+
+static void parse_types(const char *arg, struct ipt_addrtype_info *info)
+{
+ const char *comma;
+
+ while ((comma = strchr(arg, ',')) != NULL) {
+ if (comma == arg || !parse_type(arg, comma-arg, info))
+ exit_error(PARAMETER_PROBLEM, "Bad type `%s'", arg);
+ arg = comma + 1;
+ }
+
+ if (strlen(arg) == 0 || !parse_type(arg, strlen(arg), info))
+ exit_error(PARAMETER_PROBLEM, "Bad type `%s'", arg);
+}
+
+#define IPT_ADDRTYPE_OPT_DIR 0x1
+#define IPT_ADDRTYPE_OPT_TYPE 0x2
+
+static int parse(int c, char **argv, int invert, unsigned int *flags,
+ const struct ipt_entry *entry, unsigned int *nfcache,
+ struct ipt_entry_match **match)
+{
+ struct ipt_addrtype_info *info =
+ (struct ipt_addrtype_info *) (*match)->data;
+
+ switch (c) {
+ case '1':
+ if (*flags&IPT_ADDRTYPE_OPT_DIR)
+ exit_error(PARAMETER_PROBLEM,
+ "Can't specify source/dest twice");
+
+ info->mode = IPT_ADDRTYPE_SOURCE;
+ *flags |= IPT_ADDRTYPE_OPT_DIR;
+ break;
+ case '2':
+ if (*flags&IPT_ADDRTYPE_OPT_DIR)
+ exit_error(PARAMETER_PROBLEM,
+ "Can't specify source/dest twice");
+
+ info->mode = IPT_ADDRTYPE_DEST;
+ *flags |= IPT_ADDRTYPE_OPT_DIR;
+ break;
+ case '3':
+ if (*flags&IPT_ADDRTYPE_OPT_TYPE)
+ exit_error(PARAMETER_PROBLEM,
+ "Can't specify --type twice");
+
+ check_inverse(optarg, &invert, &optind, 0);
+ parse_types(argv[optind-1], info);
+ if (invert)
+ info->invert = 1;
+ *flags |= IPT_ADDRTYPE_OPT_TYPE;
+ break;
+ default:
+ return 0;
+ }
+
+ return 1;
+}
+
+static void final_check(unsigned int flags)
+{
+ if (!(flags&IPT_ADDRTYPE_OPT_DIR))
+ exit_error(PARAMETER_PROBLEM,
+ "addrtype: you must specify --source or --dest");
+ if (!(flags&IPT_ADDRTYPE_OPT_TYPE))
+ exit_error(PARAMETER_PROBLEM,
+ "addrtype: you must specify --type");
+}
+
+static void print_type(unsigned typemask) {
+ const char *sep = "";
+ if (typemask&IPT_ADDRTYPE_RTN_UNSPEC) {
+ printf("%sUNSPEC", sep);
+ sep = ",";
+ }
+ if (typemask&IPT_ADDRTYPE_RTN_UNICAST) {
+ printf("%sUNICAST", sep);
+ sep = ",";
+ }
+ if (typemask&IPT_ADDRTYPE_RTN_LOCAL) {
+ printf("%sLOCAL", sep);
+ sep = ",";
+ }
+ if (typemask&IPT_ADDRTYPE_RTN_BROADCAST) {
+ printf("%sBROADCAST", sep);
+ sep = ",";
+ }
+ if (typemask&IPT_ADDRTYPE_RTN_ANYCAST) {
+ printf("%sANYCAST", sep);
+ sep = ",";
+ }
+ if (typemask&IPT_ADDRTYPE_RTN_MULTICAST) {
+ printf("%sMULTICAST", sep);
+ sep = ",";
+ }
+ if (typemask&IPT_ADDRTYPE_RTN_BLACKHOLE) {
+ printf("%sBLACKHOLE", sep);
+ sep = ",";
+ }
+ if (typemask&IPT_ADDRTYPE_RTN_UNREACHABLE) {
+ printf("%sUNREACHABLE", sep);
+ sep = ",";
+ }
+ if (typemask&IPT_ADDRTYPE_RTN_PROHIBIT) {
+ printf("%sPROHIBIT", sep);
+ sep = ",";
+ }
+ if (typemask&IPT_ADDRTYPE_RTN_THROW) {
+ printf("%sTHROW", sep);
+ sep = ",";
+ }
+ if (typemask&IPT_ADDRTYPE_RTN_XRESOLVE) {
+ printf("%sXRESOLVE", sep);
+ sep = ",";
+ }
+ printf(" ");
+}
+
+static void print(const struct ipt_ip *ip,
+ const struct ipt_entry_match *match,
+ int numeric)
+{
+ const struct ipt_addrtype_info *info =
+ (struct ipt_addrtype_info *) match->data;
+
+ printf("ADDRTYPE match ");
+
+ switch (info->mode) {
+ case IPT_ADDRTYPE_SOURCE:
+ printf("sourceaddr ");
+ break;
+ case IPT_ADDRTYPE_DEST:
+ printf("destaddr ");
+ break;
+ }
+
+ if (info->invert)
+ printf("!");
+
+ print_type(info->type);
+}
+
+static void save(const struct ipt_ip *ip,
+ const struct ipt_entry_match *match)
+{
+ const struct ipt_addrtype_info *info =
+ (struct ipt_addrtype_info *) match->data;
+
+ switch (info->mode) {
+ case IPT_ADDRTYPE_SOURCE:
+ printf("--source ");
+ break;
+ case IPT_ADDRTYPE_DEST:
+ printf("--dest ");
+ break;
+ default:
+ break;
+ }
+
+ if (info->invert)
+ printf("! ");
+ printf("--type ");
+ print_type(info->type);
+}
+
+static struct option opts[] = {
+ { "source", 0, 0, '1' },
+ { "dest", 0, 0, '2' },
+ { "type", 1, 0, '3' },
+ { 0 }
+};
+
+static
+struct iptables_match addrtype = {
+ NULL,
+ "addrtype",
+ IPTABLES_VERSION,
+ IPT_ALIGN(sizeof(struct ipt_addrtype_info)),
+ IPT_ALIGN(sizeof(struct ipt_addrtype_info)),
+ &help,
+ &init,
+ &parse,
+ &final_check,
+ &print,
+ &save,
+ opts
+};
+
+
+void _init(void)
+{
+ register_match(&addrtype);
+}
diff -urN extensions/.addrtype-test extensions/.addrtype-test
--- extensions/.addrtype-test Thu Jan 1 01:00:00 1970
+++ extensions/.addrtype-test Wed Sep 18 15:18:25 2002
@@ -0,0 +1,5 @@
+#!/bin/bash
+
+if test -f $KERNEL_DIR/include/linux/netfilter_ipv4/ipt_addrtype.h; then
+ echo "addrtype"
+fi
^ permalink raw reply
* a little help request (OT)
From: Haines Brown @ 2003-01-08 18:26 UTC (permalink / raw)
To: linux-hams
I get an error when subscribers reply to my messages sent to another
list supported by vger.kernel.org, and so I'm asking for a little
help to see if the problem has (in part, at least) to do with the list
server.
The problem is that the To: line in my messages (such as the one you
are now reading) for some reason sometimes takes the form
listnamne@mydomain name. I.e., linux-hams@hartford-hwp.com. So if you
were to reply by hitting your Reply button, it will bounce because
sent to an invalid address.
Would some kind soul reply to this message and in so doing inspect its
header's To: line to see if the false address is there, and then let
me know? If so, you will have to change it to brownh@hartford-hwp.com
so that your reply gets through to me instead of bouncing back at you.
Thanks
Haines Brown KB1GRM
^ permalink raw reply
* Re: [LARTC] U32 filter for IPSEC (ESP)
From: bert hubert @ 2003-01-08 18:29 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104180993325505@msgid-missing>
On Mon, Jan 06, 2003 at 12:49:54AM +0100, Gilles Douillet wrote:
> so this u32 filter should work ? (I can use fw filter because the
> firewall/VPN can't mark pakets :-(
>
> tc filter add dev ethX parent X:0 protocol ip prio X u32 match ip protocol
> 50 0xff flowid X:XX ?
Looks fine, but try proving it - just send this traffic to anotherwise empty
class and run 'tc -s qdisc ls dev eth0' and 'tc -s class ls dev eth0' to see
if the counters change.
Regards,
bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl Consulting
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: [linux-lvm] Graphical tool to configure LVM for RedHat 8
From: Jose Luis Domingo Lopez @ 2003-01-08 18:30 UTC (permalink / raw)
To: Linux-LVM
In-Reply-To: <55939F05720D954E9602518B77F6127F8289CE@FTWMLVEM01.e2k.ad.ge.com>
On Wednesday, 08 January 2003, at 13:34:06 -0600,
Ma, Thanh(IndSys, GE Interlogix) wrote:
> The command line tools are great but I just wonder if there is a graphical tool to do the same thing (for RedHat, BTW) ?
>
Recent webmin versions include a plugin to manage LVM. I haven't tried
It, and I agree witht the other people about using the command line
utilities, but in any case,go to www.webmin.com and give it a try.
Regards,
--
Jose Luis Domingo Lopez
Linux Registered User #189436 Debian Linux Sid (Linux 2.4.20-xfs)
^ permalink raw reply
* RE: Policy Language
From: Stephen D. Smalley @ 2003-01-08 18:38 UTC (permalink / raw)
To: sguttman, selinux, Mark.Westerman
> I am asking to remove context sensitive meaning from tokens in the language.
>
> Taken from "info bison".
>
> "The Bison paradigm is to parse tokens first, then group them into
> larger syntactic units. In many languages, the meaning of a token is
> affected by its context. Although this violates the Bison paradigm,
> certain techniques (known as "kludges") may enable you to write Bison
> parsers for such languages."
The meaning of the tokens is not context sensitive. The fact that the keyword
'class' can occur in two different statements does not present a problem in
scanning and parsing the configuration. The policy language grammar does not
rely on any of the "kludges" described in the referenced section of the bison
manual. Token parsing does not depend on semantic or syntactic context.
You can use the provided grammar (or a subset of it) as a basis for developing
your own policy tools, as has already been done by others such as Tresys and
MITRE.
--
Stephen Smalley, NSA
sds@epoch.ncsc.mil
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [PATCH][FBDEV]: fb_putcs() and fb_setfont() methods
From: Antonino Daplas @ 2003-01-08 18:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: James Simmons, Petr Vandrovec, Linux Fbdev development list,
Linux Kernel List
In-Reply-To: <Pine.GSO.4.21.0301081142190.21171-100000@vervain.sonytel.be>
On Wed, 2003-01-08 at 18:47, Geert Uytterhoeven wrote:
> On Tue, 7 Jan 2003, James Simmons wrote:
> > > Why? (a) only those which will use putcs, and (b) I see no 512 chars limit
> > > anywhere in new code. And in old code it is there only because of passed
> > > data are only 16bit, not 32bit wide... With simple search&replace you can
> > > extend it to any size you want, as long as you'll not use sparse font
> > > bitmap.
> >
> > The current "core" console code screen_buf layout is designed after VGA
> > text mode. 16 bits which only 8 bits are used to represent a character, 9
> > if you have high_fonts flag set. The other 8,7 bits are for attributes.
> > This is very limiting and it does effect fbcon.c :-( I like to the console
> > system remove these awful limitation in the future. This why I like to see
> > fbdev drivers avoid touching strings from the console layer.
>
> Please note that Tony's new accel_putcs() code uses __u32 to pass the character
> indices. So it's not limited to 256/512 characters per font. Fonts can be as
> large as you want. Sparse fonts can be handled as well, if accel_putcs() takes
> care of the conversion from sparse character indices to dense character
> indices.
>
> His code can be viewed as a way to do multiple monochrome to color expansions
> with one single call, using a predefined table of patterns. Quite generic,
> unless you want to have multi-color fonts later :-)
>
:-) I did not want prolong the discussion, but...
Geert is correct that the functions are generic. The fb_putcs() and
fb_setfont() can be compared to Tile blitting. Tile blitting is a
common operation in some games such as Warcraft, Starcraft, and most
RPG's. I'm think there is Tile Blitting support in DirectFB.
In a tile-based game, the basic unit is a Tile which is just a bitmap
with a predefined width and height. The game has several tiles stored in
memory each with it's own unique id. To draw the background/layer, a
TileMap is constructed which is basically another array. Its format is
something like this - TileMap[x] = y which means draw Tile y at screen
position x.
In the fbcon perspective, we can think of each character as a Tile, and
fontdata as the collection of tiles. fb_char.data is basically a
TileMap. Of course, tile blitting in games is more complicated than
this, since games have multiple layers for the background, so layer
position, transparency, etc has to be considered.
So maybe if we can rename fb_putcs() to fb_tileblit(), fb_setfont() to
fb_loadtiles(), struct fb_chars to struct fb_tilemap and struct
fb_fontdata to struct fb_tiledata, maybe it will be more acceptable?
It can be even be expanded by including fb_tiledata.depth
fb_tiledata.cmap so we can support multi-colored tiled blitting.
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* [Linux-ia64] Re: [RFC] proposed change for syscall stub
From: David Mosberger @ 2003-01-08 18:32 UTC (permalink / raw)
To: linux-ia64
Jim Hull noticed that I posted the wrong code for the syscall stub:
the one I sent out fits in 5 bundles, not 4 as advertised. The
4-bundle code looks like this:
really_new_syscall_stub:
adds r2 = SYSINFO_OFF, r13;;
ld8 r2 = [r2]
mov r9 = ar.pfs;;
mov r15 = SYSCALL_NR
mov b7 = r2
br.call.sptk.many b6 = b7;;
cmp.eq p6,p0 = -1, r10
mov ar.pfs = r9
(p6) br.cond.spnt.few syscall_error
br.ret.sptk.many rp;;
The only difference here is that we dirty both b6 and b7, which allows
us to remove one stop bit and hence save one bundle. On McKinley,
dirtying more scratch branch registers may impact branch target
address prediction accuracy, but the effect is small enough that I
decided to go for better code-density instead.
--david
^ permalink raw reply
* Re: [LARTC] Incomprehensive problem with tc filter & mangle...
From: Stef Coene @ 2003-01-08 18:32 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-104197594226744@msgid-missing>
> # The rules that's didn't work, and I don't now why.
> $TC filter add dev $EXT_IFACE parent 1: protocol ip prio 15 \
> handle 10 fw classid 1:10
> $TC filter add dev $EXT_IFACE parent 1: protocol ip prio 20 \
> handle 15 fw classid 1:10
I don't think it's an issue, but you can try it without a prio parameter?
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Status of linuxppc_2.5
From: Benjamin Herrenschmidt @ 2003-01-08 18:34 UTC (permalink / raw)
To: Boris Bezlaj; +Cc: Pantelis Antoniou, linuxppc-dev
In-Reply-To: <20030108182254.GB1002@bandit.kista.gajba.net>
On Wed, 2003-01-08 at 19:22, Boris Bezlaj wrote:
> On Wed, Jan 08, 2003 at 07:18:35PM +0100, Benjamin Herrenschmidt wrote:
> >
> > What patch ? I'm interested ;)
>
> It just adds +#include <linux/interrupt.h> to swim3.c
>
> > So far, swim3 in 2.5 is not up-to-date to new BIO semantics in 2.5. I've wanted
> > to do that for some time now but didn't find time yet.
>
> But does the writing work in 2.4.x ? For me it works flawlessly in 2.2.x,
> but in 2.4 there are some problems with settling (only when writing; read
> is fine), which im trying to figure out and fix.
Did didn't try that driver very hard lately. Please cc me any fix you
may have.
Note also that there is a darwin driver for swim3 floating around that
gets a lot of code from MacOS 9 and that appear to document a bunch
of black magic stuffs, so that may be a good source of information. I
think it's on mklinux.org
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [PATCH]: fix all iptables problems with '!' (hopefully)
From: Patrick McHardy @ 2003-01-08 18:37 UTC (permalink / raw)
To: Harald Welte; +Cc: Netfilter Development Mailinglist
In-Reply-To: <20030107201643.GY9467@sunbeam.de.gnumonks.org>
Harald Welte wrote:
>>What about if i convert all matches to only show "!" in boolean context
>>in the helptexts and change check_inverse and what else might be
>>neccessary to enforce this ?
>>
>>
>
>I think this is a wise idea.
>
>
Since i have to touch a lot of helptexts anyway i thought it might be
the time to unify their format.
Any wishes regarding this ?
Regards,
Patrick
>
>
>>What about backward-compatibility ?
>>
>>
>
>This is usually not my idea of being user-friendly... but considering
>how much trouble we've had with this over the last couple of months, I'm
>willing to sacrifice a bit of backwards compatibility.
>
>To everyone: Please feel free to protest.
>
>
>
^ permalink raw reply
* Re: tenth post about PCI code, need help
From: Richard B. Johnson @ 2003-01-08 18:49 UTC (permalink / raw)
To: Ray Lee; +Cc: fretre3618, Linux Kernel
In-Reply-To: <1042049372.850.921.camel@orca.madrabbit.org>
On 8 Jan 2003, Ray Lee wrote:
> > 1. which device is at port address 0xCFB? (please note, NOT 0xCF8)
>
> 0xcfb ('bee') is the fourth byte of the 32 bit register that sits/starts
> at 0xcf8 ('eight'). Note the difference in the code between the outb and
> outl calls.
>
> To answer your other questions, I think you'd have better luck reading
> the spec for the x86 pc-style PCI bridge chip, rather than the (generic)
> PCI v2.0 spec itself. The spec for the actual chip is always the final
> authority for what's going on. (Unless, of course, it's wrong...)
>
> Ray
>
The problem is that he's discovered something that's not supposed
to be in the code. Only 32-bit accesses are supposed to be made to
the PCI controller ports. He has discovered that somebody has made
some 8-bit accesses that will not become configuration 'transactions'
because they are not 32 bits. According to the spec, such accesses
become direct I/O to some underlying device. So, if some underlying
device shares the same I/O address space as the PCI device, that
machine is broken.
FYI, the mechanism by which ix86 hardware determines if the PCI
port access is a configuration read or configuration write is
the 32-bit access. Any other access cannot be interpreted by
the hardware as a configuration transaction. (Page 321.,
"Into to configuration Mechanisms", PCI System Architecture,
ISBN 0-201-30974-2)
It is possible that somebody had a bad board and found that writing
some junk to this port 'fixed' something. If this is so, then the
code needs some comments. Otherwise, the non-32bit accesses should
be removed.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
^ permalink raw reply
* Re: the last changes to trident driver
From: James Tappin @ 2003-01-08 18:38 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5h4r8jaj1c.wl@alsa2.suse.de>
On Wed, 08 Jan 2003 14:05:35 +0100
Takashi Iwai <tiwai@suse.de> wrote:
> At Wed, 8 Jan 2003 12:52:27 +0000,
> James Tappin wrote:
> >
> > TI>
> > TI> hmm, unfortunately the stack wasn't parsed correctly with symbols.
> > TI> did you build the alsa drivers with debug option
> > TI> (--with-debug=full)? anyway, please rebuild the drivers with the
> > TI> attached patch (and debug option, if not yet). i hope a fatal
> > TI> oops or hang-up can be avoided now...
> > TI> oh, also, please update the cvs tree again. i've done some
> > TI> changes since yesterday.
> >
> > As far as I can tell that works, i.e. the modules load, aplay plays a
> > wav file and there's nothing in /var/log/syslog -- I can't tell if any
> > sound's coming out.
>
> thanks. then it's better to commit it to cvs, to avoid for other
> people to get oops :)
Just a quickie to say that the updated version does indeed produce sound
as it should. I can't test anything other than PCM output as thats the
only hardware I have.
Thanks for the good work,
James
--
James Tappin, O__ "I forget the punishment for using
james@tappin.me.uk -- \/` Microsoft --- Something lingering
http://www.tappin.me.uk/ with data loss in it I fancy"
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: USB CF reader reboots PC
From: Andries Brouwer @ 2003-01-08 18:49 UTC (permalink / raw)
To: Greg KH; +Cc: linux-kernel
In-Reply-To: <20030108181645.GC3127@kroah.com>
On Wed, Jan 08, 2003 at 10:16:45AM -0800, Greg KH wrote:
> > Insert CF card.
> > ls /dev shows sda and sda1
> > mount it.
> > ls /dev shows sda - no sda1
> > cd to mounted CF card
> > process hangs, sd-mod & usb-storage "busy"
> > rmmod -f usb-storage or sd-mod causes PC to stop
> > (keyboard & mouse unresponsive, wmfire frozen, net disconnects)
> So if devfs is enabled, everything works just fine?
No. I have seen this kind of thing, and muttered a little bit
on earlier occasions.
The problem is that USB storage invents a GUID, that usually
is composed of vendor and product ID of the reader, possibly
also a serial number, but does not involve the card.
When the card goes away, the partitions stay, and the device
is treated as "not present".
When a new card is inserted confusion arises.
We see that when a device goes from "not present" to "present"
it may be necessary to throw out all data we have on it.
Thus, maybe it was pointless to keep this data when it went away.
This is somewhat related to the IDs discussion of a few days ago.
People invent IDs, but nobody knows of what precisely.
Andries
^ permalink raw reply
* Re: [2.5.54][PATCH] SB16 convertation to new PnP layer.
From: Zwane Mwaikambo @ 2003-01-08 18:51 UTC (permalink / raw)
To: Ruslan U. Zakirov; +Cc: linux-kernel, ambx1
In-Reply-To: <Pine.BSF.4.05.10301081959130.88742-100000@wildrose.miee.ru>
On Wed, 8 Jan 2003, Ruslan U. Zakirov wrote:
> Hello Adam and All.
> Here is patch to sb16.c that makes it posible to compile and use this
> driver under 2.5.54-vanilla.
> It working for me as module and built in kernel, but it's need testing.
> Ruslan.
Which card do you have? Does it have wavetable?
Zwane
--
function.linuxpower.ca
^ permalink raw reply
* Re: observations on 2.5 config screens
From: Bill Davidsen @ 2003-01-08 18:36 UTC (permalink / raw)
To: Robert Love; +Cc: Adrian Bunk, Robert P. J. Day, Linux kernel mailing list
In-Reply-To: <1042041195.694.2734.camel@phantasy>
On 8 Jan 2003, Robert Love wrote:
> On Wed, 2003-01-08 at 09:32, Bill Davidsen wrote:
>
> > Someone else suggested putting all the low level options like preempt,
> > smp, and the stuff in kernel-hacking into a single menu, with a better
> > name.
>
> I do not think I like this. SMP, kernel preemption, and high memory
> support are the three most fundamental choices one makes during
> configuration.
I guess, depending on your definition of fundemental. I would put any
option which affects the kernel as a whole in that category, myself.
Compiling with frame pointers comes to mind, since every object file is
changed and there are performance implications as well.
> They should be out in the open, in the beginning, in a well-labeled
> category. They only issue I see is "processor options" should be
> renamed "core options" or whatever. But that is trivial.
Processor option would select the processor and any architecture dependent
options, I would think. Something like "kernel characteristics" could have
options like smp.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: PCI code: why need outb (0x01, 0xCFB); ?
From: H. Peter Anvin @ 2003-01-08 18:52 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <F87sTOHYNhMwqvbLaKL0001615a@hotmail.com>
Followup to: <F87sTOHYNhMwqvbLaKL0001615a@hotmail.com>
By author: "fretre lewis" <fretre3618@hotmail.com>
In newsgroup: linux.dev.kernel
> 1. which device is at port address 0xCFB?
Hopefully none.
> 2. what is meaning of the writing operation "outb (0x01, 0xCFB);" for THIS
> device?, it'seem that PCI spec v2.0 not say anything about it?
It's trying to verify that the PCI northbridge does *NOT* respond to
this (byte-wide) reference.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* Re: Patch(2.5.54): devfs shrink - integration candidate
From: H. Peter Anvin @ 2003-01-08 18:55 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20030105203725.A10808@adam.yggdrasil.com>
Followup to: <20030105203725.A10808@adam.yggdrasil.com>
By author: "Adam J. Richter" <adam@yggdrasil.com>
In newsgroup: linux.dev.kernel
>
> This patch reduces include/linux/devfs*.h and fs/devfs from
> 3655 lines to 1239, a reduction of 2450 lines, nearly a factor three.
> That may not be as impressive as the original 5X reduction, but that
> is mostly because I've restored a bunch of functionality that I hope
> to eliminate in the future.
>
Do we have any idea what the impact of this is on runtime data size?
I seem to remember devfs playing lots of tricks to reduce its working
set. If this code size reduction ends up pinning large data
structures like dentries and inodes which wouldn't otherwise have been
pinned, this could be a significant lose.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* RE: kacpidpc needs to die
From: Grover, Andrew @ 2003-01-08 18:57 UTC (permalink / raw)
To: Pavel Machek, ACPI mailing list, kernel list
> From: Pavel Machek [mailto:pavel@ucw.cz]
> For reasons discussed before [forking from timer is not safe, anyway],
> kacpidpc needs to die. Andrew, are you going to kill it or should I do
> it?
I can kill it...let me just verify with you --
acpi_os_queue_for_execution has a two block switch statement, just use
the first block (the case that uses schedule_work) and delete the rest,
yes?
Thanks -- Regards -- Andy
^ permalink raw reply
* [LARTC] Re: TC shapping and bridge mode.
From: Stef Coene @ 2003-01-08 18:51 UTC (permalink / raw)
To: lartc
On Tuesday 07 January 2003 07:49, lyntonc@lanmetrix.co.za wrote:
> Sorry.
>
> I was wondering if you have any idea why I can get TC to match port based
> rules (e.g. HTTP matches port 80), but when I try to match a subnet (e.g.
> 192.168.100.0/24) I fail to see class hits. I have tried both HTB and CBQ.
This has nothing to do with the qdisc (htb or cbq) but is a filter problem.
And I think that you use the u32 filter. Can you send me the u32 lines from
your scripts?
> Sorry to send this question direct to you, I did join the LARTC (with
> confirmation e-mail) but my question got held up for moderation (?).
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [Printing-architecture] Architecture meeting agenda 20030109. . .
From: HEMSTREET,CHARLES (HP-Vancouver,ex1) @ 2003-01-08 18:52 UTC (permalink / raw)
To: 'printing-architecture@freestandards.org'
Phone/Passcode:
* Dial-in : 816.650.0688
* passcode : 9 6 4 6 2 8
Thursday from 8-9 am PST, 9-10 am
MST, 11-12 pm EST, 4-5 pm UTC.
-------------------------
Agenda for 01/09/03:
* Discuss next face-to-face meeting. Interest in meeting at LinuxWorld?
* Where does the architecture meeting need to pick up?
Thanks,
Charles
^ permalink raw reply
* Re: Newbie - Where is my kernel? Can't run POM
From: Arnt Karlsen @ 2003-01-08 18:53 UTC (permalink / raw)
To: netfilter
In-Reply-To: <002301c2b73e$e0f36ca0$3f00a8c0@tharryman>
On Wed, 8 Jan 2003 11:53:38 -0600,
"Timothy Harryman" <timothy@woodlandscenics.com> wrote in message
<002301c2b73e$e0f36ca0$3f00a8c0@tharryman>:
> It certainly is not in /usr/src/linux (nautilus & terminal show that
> /usr/src is empty - yes, I am showing all hidden/system files), nor
> anywhere else I have looked.
>
> I have a default installation of RH 8.0, and through rhupdate, it has
> updated the kernel to 2.4.18-19.8.0
>
> I am trying to install patch-o-matic 20030107, and the script prompts
> me for the KERNEL_DIR.
>
> This is extremely frustrating, and any help is hugely appreciated!
>
> <>< <>< <>< <>< <>< <>< <>< <>< <>< <>< <><
> Timothy
> timothy@woodlandscenics.com
>
>
>
..try 'rpm -ivh kernel-source-2.4.18-19.8.0.i386.rpm'. ;-)
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
^ 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.