* Re: Why is Nvidia given GPL'd code to use in closed source drivers?
From: Helge Hafting @ 2003-01-08 10:06 UTC (permalink / raw)
To: Valdis.Kletnieks, linux-kernel
In-Reply-To: <200301071515.h07FFKCR008361@turing-police.cc.vt.edu>
Valdis.Kletnieks@vt.edu wrote:
>
> On Tue, 07 Jan 2003 10:08:00 +0100, Helge Hafting <helgehaf@aitel.hist.no> said:
> > loss. Giving away driver code (or at least programming specs)
> > wouldn't be a loss to nvidia though - because users would still
> > need to buy those cards.
>
> It would be a major loss to nvidia *AND* its customers if it were bankrupted in
> a lawsuit because it open-sourced code or specs that contained intellectual
> property that belonged to somebody else.
Perhaps their driver contains some IP. But I seriously doubt the
programming specs for their chips contains such secrets. It is
not as if we need the entire chip layout - it is basically
things like:
"To achieve effect X, write command code 0x3477 into register 5
and the new coordinates into registers 75-78. Then wait 2.03ms before
attempting to access the chip again..."
Something is very wrong if they _can't_ release that sort of
information.
Several other manufacturers have no problem with this.
> In the real world, ideology needs to be tempered with realism.
>
Sure. But in this case, it is more about common sense than ideology.
Helge Hafting
^ permalink raw reply
* Re: clipping
From: Geert Uytterhoeven @ 2003-01-08 9:54 UTC (permalink / raw)
To: James Simmons; +Cc: Antonino Daplas, Linux Frame Buffer Device Development
In-Reply-To: <Pine.LNX.4.44.0301072211310.17129-100000@phoenix.infradead.org>
On Tue, 7 Jan 2003, James Simmons wrote:
> > > > BTW, do we really need clipping in fb_ops.fb_{fillrect,copyarea,imageblit}()?
> > > Personally, I don't think we need clipping. I tried removing it before
> > > (circa linux-2.5.30+), but the console segfaults whenever I decrease
> > > var->yres_virtual. I haven't tried this again with the newest
> > > framebuffer framework though.
> >
> > Any definitive answer on this?
> >
> > What happens if you resize the VT to such a large size that columns*fontwidth >
> > xres_virtual or rows*fontheight > yres_virtual? I guess clipping prevents a
> > crash there?
>
> Correct. Actually fbcon_resize checks to make sure the user doesn't do
> something stupid like this. So we might not needed. Hm.
And what if you use fbset to reduce the resolution below what's needed to
accomodate the current console size?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Undelete files on ext3 ??
From: bart @ 2003-01-08 10:03 UTC (permalink / raw)
To: root; +Cc: maxvaldez, bulb, linux-kernel
On 7 Jan, Richard B. Johnson wrote:
>
> tell it to 'really' delete a file (or is there?). So,
> maybe we need a new kernel function? Just hacking existing
> utilities won't do the whole thing because we need programs
> that delete files to transparently put them into the
> dumpster as well.
I think libc would be the best place to implement such a thing.
Bart
--
Bart Hartgers - TUE Eindhoven
http://plasimo.phys.tue.nl/bart/contact.html
^ permalink raw reply
* Re: Re: [PATCH]: image.depth fix to accomodate monochrome cards
From: Geert Uytterhoeven @ 2003-01-08 9:52 UTC (permalink / raw)
To: Antonino Daplas; +Cc: James Simmons, Linux Fbdev development list
In-Reply-To: <1041991742.927.12.camel@localhost.localdomain>
On 8 Jan 2003, Antonino Daplas wrote:
> On Wed, 2003-01-08 at 05:06, Geert Uytterhoeven wrote:
> > On 8 Jan 2003, Antonino Daplas wrote:
> > > 2. diff submitted by Geert: cleaner logo data preparation for
> > > monochrome cards and correct initialization of palette_cmap.transp.
> >
> > I'll have to do some more fixes there, since the monochrome logo is used not
> > only on monochrome displays, but on all other displays with bits_per_pixel < 4
> > Since the pixel data in fb_image are colormap indices, they have to reflect the
> > correct `black' and `white' colors on such displays.
> >
> > E.g. on amifb (which supports all bits_per_pixel from 1 through 8) the logo
> > showed up in black-and-blue with bits_per_pixel == 3, cfr. the first two
> > entries of {red,green,blue}8[] in fbcmap.c.
> >
>
> Hmm, I see. I think only linux_logo_bw will be the only one affected,
> since linux_logo_16 happens to match the console palette and in
> linux_logo, we either reset the palette and/or the cmap.
Indeed.
> Would expanding each bit to the full bit depth work? Ie for bpp=8 using
> monochrome data, white is 0 and black is 0xff.
For bpp=8 that won't work, since we have 16 console colors only :-)
But for bpp=[1-3] that's OK, cfr. fbcmap.c.
BTW, perhaps it makes sense to just pass the appropriate `black' and `white'
pixel values to the logo conversion routine? Preferably through a 2-element
array, so we can index it with the logo data bit value instead of using
tests/branches. Then we'd have:
- mono01: black = (1<<bits_per_pixel)-1, white = 0
- mono10: black = 0, white = (1<<bits_per_pixel)-1
- pseudocolor depth 1: black = 0, white = 1
- pseudocolor depth 2: black = 0, white = 3
- pseudocolor depth 3: black = 0, white (actually light grey) = 7
And thanks to the `(1<<depth)-1' instead of `1' for the mono* cases, monochrome
with bits_per_pixel = e.g. 8 will work as well.
What do you think?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* [PATCH 10/10] dm: Remove redundant error checking
From: Joe Thornber @ 2003-01-08 10:00 UTC (permalink / raw)
To: Joe Thornber; +Cc: Linus Torvalds, Linux Mailing List
In-Reply-To: <20030108095221.GA2063@reti>
bio_alloc() shouldn't fail if GFP_NOIO is used, and the bvec count is
sensible. So remove redundant error checking.
--- diff/drivers/md/dm.c 2003-01-02 11:10:22.000000000 +0000
+++ source/drivers/md/dm.c 2003-01-02 11:27:23.000000000 +0000
@@ -347,18 +347,15 @@
struct bio_vec *bv = bio->bi_io_vec + idx;
clone = bio_alloc(GFP_NOIO, 1);
+ memcpy(clone->bi_io_vec, bv, sizeof(*bv));
- if (clone) {
- memcpy(clone->bi_io_vec, bv, sizeof(*bv));
-
- clone->bi_sector = sector;
- clone->bi_bdev = bio->bi_bdev;
- clone->bi_rw = bio->bi_rw;
- clone->bi_vcnt = 1;
- clone->bi_size = to_bytes(len);
- clone->bi_io_vec->bv_offset = offset;
- clone->bi_io_vec->bv_len = clone->bi_size;
- }
+ clone->bi_sector = sector;
+ clone->bi_bdev = bio->bi_bdev;
+ clone->bi_rw = bio->bi_rw;
+ clone->bi_vcnt = 1;
+ clone->bi_size = to_bytes(len);
+ clone->bi_io_vec->bv_offset = offset;
+ clone->bi_io_vec->bv_len = clone->bi_size;
return clone;
}
@@ -432,11 +429,6 @@
clone = split_bvec(bio, ci->sector, ci->idx,
bv->bv_offset, max);
- if (!clone) {
- dec_pending(ci->io, -ENOMEM);
- return;
- }
-
__map_bio(ti, clone, ci->io);
ci->sector += max;
@@ -446,11 +438,6 @@
len = to_sector(bv->bv_len) - max;
clone = split_bvec(bio, ci->sector, ci->idx,
bv->bv_offset + to_bytes(max), len);
- if (!clone) {
- dec_pending(ci->io, -ENOMEM);
- return;
- }
-
__map_bio(ti, clone, ci->io);
ci->sector += len;
^ permalink raw reply
* [PATCH 8/10] dm: Simplify error->map
From: Joe Thornber @ 2003-01-08 9:59 UTC (permalink / raw)
To: Joe Thornber; +Cc: Linus Torvalds, Linux Mailing List
In-Reply-To: <20030108095221.GA2063@reti>
Just return an error from the error targets map function, rather than
erroring the buffer_head.
--- diff/drivers/md/dm-target.c 2003-01-02 11:26:44.000000000 +0000
+++ source/drivers/md/dm-target.c 2003-01-02 11:27:04.000000000 +0000
@@ -163,8 +163,7 @@
static int io_err_map(struct dm_target *ti, struct bio *bio)
{
- bio_io_error(bio, 0);
- return 0;
+ return -EIO;
}
static struct target_type error_target = {
^ permalink raw reply
* [PATCH 9/10] dm: Export dm_table_get_mode()
From: Joe Thornber @ 2003-01-08 9:59 UTC (permalink / raw)
To: Joe Thornber; +Cc: Linus Torvalds, Linux Mailing List
In-Reply-To: <20030108095221.GA2063@reti>
Export dm_table_get_mode()
--- diff/drivers/md/dm-table.c 2003-01-02 11:26:53.000000000 +0000
+++ source/drivers/md/dm-table.c 2003-01-02 11:27:13.000000000 +0000
@@ -751,3 +751,4 @@
EXPORT_SYMBOL(dm_get_device);
EXPORT_SYMBOL(dm_put_device);
EXPORT_SYMBOL(dm_table_event);
+EXPORT_SYMBOL(dm_table_get_mode);
^ permalink raw reply
* [PATCH 7/10] dm: printk tgt->error if dm_table_add_target() fails.
From: Joe Thornber @ 2003-01-08 9:58 UTC (permalink / raw)
To: Joe Thornber; +Cc: Linus Torvalds, Linux Mailing List
In-Reply-To: <20030108095221.GA2063@reti>
printk tgt->error if dm_table_add_target() fails.
--- diff/drivers/md/dm-table.c 2003-01-02 11:26:35.000000000 +0000
+++ source/drivers/md/dm-table.c 2003-01-02 11:26:53.000000000 +0000
@@ -578,9 +578,8 @@
int dm_table_add_target(struct dm_table *t, const char *type,
sector_t start, sector_t len, char *params)
{
- int r, argc;
+ int r = -EINVAL, argc;
char *argv[32];
- struct target_type *tt;
struct dm_target *tgt;
if ((r = check_space(t)))
@@ -589,14 +588,13 @@
tgt = t->targets + t->num_targets;
memset(tgt, 0, sizeof(*tgt));
- tt = dm_get_target_type(type);
- if (!tt) {
+ tgt->type = dm_get_target_type(type);
+ if (!tgt->type) {
tgt->error = "unknown target type";
- return -EINVAL;
+ goto bad;
}
tgt->table = t;
- tgt->type = tt;
tgt->begin = start;
tgt->len = len;
tgt->error = "Unknown error";
@@ -605,23 +603,19 @@
* Does this target adjoin the previous one ?
*/
if (!adjoin(t, tgt)) {
- DMERR("Gap in table");
- dm_put_target_type(tt);
- return -EINVAL;
+ tgt->error = "Gap in table";
+ goto bad;
}
r = split_args(ARRAY_SIZE(argv), &argc, argv, params);
if (r) {
tgt->error = "couldn't split parameters";
- dm_put_target_type(tt);
- return r;
+ goto bad;
}
- r = tt->ctr(tgt, argc, argv);
- if (r) {
- dm_put_target_type(tt);
- return r;
- }
+ r = tgt->type->ctr(tgt, argc, argv);
+ if (r)
+ goto bad;
t->highs[t->num_targets++] = tgt->begin + tgt->len - 1;
@@ -629,6 +623,11 @@
* the merge fn apply the target level restrictions. */
combine_restrictions_low(&t->limits, &tgt->limits);
return 0;
+
+ bad:
+ printk(KERN_ERR DM_NAME ": %s\n", tgt->error);
+ dm_put_target_type(tgt->type);
+ return r;
}
static int setup_indexes(struct dm_table *t)
^ permalink raw reply
* [PATCH 6/10] dm: Remove explicit returns from void fns (fluff)
From: Joe Thornber @ 2003-01-08 9:57 UTC (permalink / raw)
To: Joe Thornber; +Cc: Linus Torvalds, Linux Mailing List
In-Reply-To: <20030108095221.GA2063@reti>
Remove explicit return at the end of a couple of void functions.
--- diff/drivers/md/dm-target.c 2003-01-02 11:26:27.000000000 +0000
+++ source/drivers/md/dm-target.c 2003-01-02 11:26:44.000000000 +0000
@@ -66,8 +66,6 @@
strcat(module_name, name);
request_module(module_name);
-
- return;
}
struct target_type *dm_get_target_type(const char *name)
@@ -161,7 +159,6 @@
static void io_err_dtr(struct dm_target *ti)
{
/* empty */
- return;
}
static int io_err_map(struct dm_target *ti, struct bio *bio)
^ permalink raw reply
* [PATCH 5/10] dm: Call dm_put_target_type() *after* calling the destructor
From: Joe Thornber @ 2003-01-08 9:57 UTC (permalink / raw)
To: Joe Thornber; +Cc: Linus Torvalds, Linux Mailing List
In-Reply-To: <20030108095221.GA2063@reti>
Call dm_put_target_type() *after* calling the destructor.
--- diff/drivers/md/dm-table.c 2002-12-30 10:17:13.000000000 +0000
+++ source/drivers/md/dm-table.c 2003-01-02 11:26:35.000000000 +0000
@@ -250,12 +250,12 @@
/* free the targets */
for (i = 0; i < t->num_targets; i++) {
- struct dm_target *tgt = &t->targets[i];
-
- dm_put_target_type(t->targets[i].type);
+ struct dm_target *tgt = t->targets + i;
if (tgt->type->dtr)
tgt->type->dtr(tgt);
+
+ dm_put_target_type(tgt->type);
}
vfree(t->highs);
^ permalink raw reply
* [PATCH 4/10] dm: rwlock_t -> rw_semaphore (fluff)
From: Joe Thornber @ 2003-01-08 9:56 UTC (permalink / raw)
To: Joe Thornber; +Cc: Linus Torvalds, Linux Mailing List
In-Reply-To: <20030108095221.GA2063@reti>
Use a rw_semaphore in dm_target.c rather than a rwlock_t, just to keep
in line with dm.c
--- diff/drivers/md/dm-target.c 2003-01-02 11:16:16.000000000 +0000
+++ source/drivers/md/dm-target.c 2003-01-02 11:26:27.000000000 +0000
@@ -19,7 +19,7 @@
};
static LIST_HEAD(_targets);
-static rwlock_t _lock = RW_LOCK_UNLOCKED;
+static DECLARE_RWSEM(_lock);
#define DM_MOD_NAME_SIZE 32
@@ -42,7 +42,7 @@
{
struct tt_internal *ti;
- read_lock(&_lock);
+ down_read(&_lock);
ti = __find_target_type(name);
if (ti) {
@@ -52,7 +52,7 @@
ti->use++;
}
- read_unlock(&_lock);
+ up_read(&_lock);
return ti;
}
@@ -86,13 +86,13 @@
{
struct tt_internal *ti = (struct tt_internal *) t;
- read_lock(&_lock);
+ down_read(&_lock);
if (--ti->use == 0)
module_put(ti->tt.module);
if (ti->use < 0)
BUG();
- read_unlock(&_lock);
+ up_read(&_lock);
return;
}
@@ -117,13 +117,13 @@
if (!ti)
return -ENOMEM;
- write_lock(&_lock);
+ down_write(&_lock);
if (__find_target_type(t->name))
rv = -EEXIST;
else
list_add(&ti->list, &_targets);
- write_unlock(&_lock);
+ up_write(&_lock);
return rv;
}
@@ -131,21 +131,21 @@
{
struct tt_internal *ti;
- write_lock(&_lock);
+ down_write(&_lock);
if (!(ti = __find_target_type(t->name))) {
- write_unlock(&_lock);
+ up_write(&_lock);
return -EINVAL;
}
if (ti->use) {
- write_unlock(&_lock);
+ up_write(&_lock);
return -ETXTBSY;
}
list_del(&ti->list);
kfree(ti);
- write_unlock(&_lock);
+ up_write(&_lock);
return 0;
}
^ permalink raw reply
* [PATCH 3/10] dm: Correct target_type reference counting
From: Joe Thornber @ 2003-01-08 9:55 UTC (permalink / raw)
To: Joe Thornber; +Cc: Linus Torvalds, Linux Mailing List
In-Reply-To: <20030108095221.GA2063@reti>
ti->use was only getting incremented the first time a target type was
retrieved (bug introduced by recent hch patch).
--- diff/drivers/md/dm-target.c 2003-01-02 10:43:06.000000000 +0000
+++ source/drivers/md/dm-target.c 2003-01-02 11:16:16.000000000 +0000
@@ -43,15 +43,16 @@
struct tt_internal *ti;
read_lock(&_lock);
+
ti = __find_target_type(name);
- if (ti && ti->use == 0) {
- if (try_module_get(ti->tt.module))
- ti->use++;
- else
+ if (ti) {
+ if ((ti->use == 0) && !try_module_get(ti->tt.module))
ti = NULL;
+ else
+ ti->use++;
}
- read_unlock(&_lock);
+ read_unlock(&_lock);
return ti;
}
^ permalink raw reply
* [PATCH 2/10] dm: Correct clone info initialisation
From: Joe Thornber @ 2003-01-08 9:54 UTC (permalink / raw)
To: Joe Thornber; +Cc: Linus Torvalds, Linux Mailing List
In-Reply-To: <20030108095221.GA2063@reti>
Initialize the clone-info's index to the original bio's index.
Required to properly handle stacking DM devices. [Kevin Corry]
--- diff/drivers/md/dm.c 2002-12-30 10:17:13.000000000 +0000
+++ source/drivers/md/dm.c 2003-01-02 11:10:22.000000000 +0000
@@ -475,7 +475,7 @@
ci.io->md = md;
ci.sector = bio->bi_sector;
ci.sector_count = bio_sectors(bio);
- ci.idx = 0;
+ ci.idx = bio->bi_idx;
atomic_inc(&md->pending);
while (ci.sector_count)
^ permalink raw reply
* [PATCH 1/10] dm: Don't let the ioctl interface drop a suspended device
From: Joe Thornber @ 2003-01-08 9:54 UTC (permalink / raw)
To: Joe Thornber; +Cc: Linus Torvalds, Linux Mailing List
In-Reply-To: <20030108095221.GA2063@reti>
Don't let the ioctl interface drop a suspended device.
--- diff/drivers/md/dm-ioctl.c 2002-12-30 10:17:13.000000000 +0000
+++ source/drivers/md/dm-ioctl.c 2003-01-02 11:10:14.000000000 +0000
@@ -812,6 +812,24 @@
return -EINVAL;
}
+ /*
+ * You may ask the interface to drop its reference to an
+ * in use device. This is no different to unlinking a
+ * file that someone still has open. The device will not
+ * actually be destroyed until the last opener closes it.
+ * The name and uuid of the device (both are interface
+ * properties) will be available for reuse immediately.
+ *
+ * You don't want to drop a _suspended_ device from the
+ * interface, since that will leave you with no way of
+ * resuming it.
+ */
+ if (dm_suspended(hc->md)) {
+ DMWARN("refusing to remove a suspended device.");
+ up_write(&_hash_lock);
+ return -EPERM;
+ }
+
__hash_remove(hc);
up_write(&_hash_lock);
return 0;
^ permalink raw reply
* device-mapper patchset 2.5.54-dm-1
From: Joe Thornber @ 2003-01-08 9:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: joe, Linux Mailing List
Linus,
Could you please apply the following patches ?
Thanks,
- Joe
^ permalink raw reply
* Re: [ACPI] acpi_os_queue_for_execution()
From: Faye Pearson @ 2003-01-08 9:47 UTC (permalink / raw)
To: peter.holmes; +Cc: linux-kernel
In-Reply-To: <3E1AE2C9.13240.1114A3C@localhost>
peter.holmes@fopet-esl.com [peter.holmes@fopet-esl.com] wrote:
> As a relative newcomer to LINUX quite a lot of it is a foreign language,
> (no awful pun intended). I've been around electronics and computers for
> quite a few years now. So would you be so kind as to explain just what
> is "GPE_L00" and "DSDT". And just how we remove the salient part?
> I have a new Acer Aspire 1304LC which I could cook an egg on.
> Windoze(2K & XP Pro) don't generate anything like so much warmth.
These terms have nothing to do with linux, they're ACPI things from
within the BIOS. the GPE is a General Purpose Event I believe. The
_L00 event seems to be an event which is generated if the machine gets
too hot - It may be called something different on a different
manufacturer's BIOS.
What you need to do is run an ACPI enabled kernel and dump the
/proc/acpi/dsdt to a file (cat /proc/acpi/dsdt > mydsdt.aml). You can't
read this directly as it is in a compiled form. You need to disassemble
it and you do that with the iasl assembler/disassembler you can get from
Intel's instantly available technology pages.
(http://www.intel.com/technology/iapc/acpi/downloads.htm)
Once you have it disassembled, try "compiling" it straight away and you
will probably find that there are errors and warnings. Check the acpi
mailing list archives for details on how to fix these.
Once you have it working, compile it into the kernel - how to do this is
covered in the archives as well. Booting with this kernel should make
your acpi work much better. If it doesn't solve your heating problem
then if you put your disassembled and original dsdt on the web somewhere
and post a message asking for help, with links to these files on the
acpi list then you are likely to get some good assistance.
It is definitely worthwhile, my laptop now runs about 99% of the time
with no fan - showing it's much cooler.
The page with my efforts on for the Compaq Presario 2701EA is
http://dude.noc.clara.net/~faye/
Good luck.
Faye
--
Faye Pearson,
Covert Development
ClaraNET Ltd. Tel 020 7903 3000
You don't move to Edina, you achieve Edina.
-- Guindon
^ permalink raw reply
* [parisc-linux] Re: do_page_fault() infinite loop running 2.4.20-pa18 #9 SMP
From: Matt Foster @ 2003-01-08 9:36 UTC (permalink / raw)
To: parisc-linux
My B132 seems to be having similar problems running a non SMP kernel,
don't know if this is useful information.
saturn:/usr/local/src# dmesg | more
Linux version 2.4.20-pa18 (bame@dsl2) (gcc version 3.0.3) #1 Tue Jan 7
06:44:31
MST 2003
FP[0] enabled: Rev 1 Model 15
The 32-bit Kernel has started...
Determining PDC firmware type: System Map.
[*SNIP*]
Adding Swap: 249232k swap-space (priority -1)
eth0: link ok.
do_page_fault() pid=266 command='sendmail' type=6 address=0x00000003
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111 Not tainted
r00-03 00000000 400c78f0 40315e07 00000000
r04-07 40326bec 40316230 00000010 00000001
r08-11 00000000 402d3c98 0008df50 0008df54
r12-15 00000076 00000073 00000006 00000000
r16-19 000b3348 ffffffff 000bc248 40326bec
r20-23 00000000 faf02a58 00000000 00000001
r24-27 00000000 40316230 000f6dd0 000b3348
r28-31 00000016 400e19dc faf029c0 40315e07
sr0-3 00000000 0000016e 00000000 0000016e
sr4-7 0000016e 0000016e 0000016e 0000016e
IASQ: 0000016e 0000016e IAOQ: 00000003 00000007
IIR: 081c0243 ISR: 0000016e IOR: 000f703c
CPU: 0 CR30: 16668000 CR31: 103b8000
ORIG_R28: 00000000
^ permalink raw reply
* Re: netfilter digest, Vol 1 #514 - 7 msgs
From: oarojo @ 2003-01-08 9:32 UTC (permalink / raw)
To: netfilter
In-Reply-To: <20030108052635.5370.76979.Mailman@kashyyyk>
Yes I'm using telnet from other network...
> Send netfilter mailing list submissions to
> netfilter@lists.netfilter.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.netfilter.org/mailman/listinfo/netfilter
> or, via email, send a message with subject or body 'help' to
> netfilter-request@lists.netfilter.org
>
> You can reach the person managing the list at
> netfilter-admin@lists.netfilter.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of netfilter digest..."
>
>
> Today's Topics:
>
> 1. Re: port redirection *without* NAT (sm@rhythm.cx)
> 2. Re: 2.4.20 - ntfilter (owner) problems (Thorsten Scherf)
> 3. OT: curious about eth0/eth1 (Tommy McNeely)
> 4. RE: netfilter digest, Vol 1 #513 - 12 msgs (Bob Balsover)
> 5. Re: 2.4.20 - ntfilter (owner) problems (blkcore)
> 6. Re: OT: curious about eth0/eth1 (Joel Newkirk)
> 7. Re: portforwarding-HOWTO (Joel Newkirk)
>
> --__--__--
>
> Message: 1
> Date: Tue, 7 Jan 2003 17:36:30 -0500
> From: sm@rhythm.cx
> To: Athan <netfilter@miggy.org>
> Cc: netfilter@lists.netfilter.org
> Subject: Re: port redirection *without* NAT
>
> On Tue, Jan 07, 2003 at 10:08:00PM +0000, Athan wrote:
>>
>> Didn't you already ask this and myself and someone else replied
>> with
>> "yes you want DNAT".
>>
>
> Yes. This was a duplicate message, sorry. I sent it to the list from
> the wrong address by mistake, and was informed it got put into a queue
> for the moderator to look at. I asked for it to be disregarded and then
> I posted again from the correct address, but I guess the original got
> passed to the list anyway. (oops, there goes my spam-free address into
> the archives :/).
>
> I understand now that was I am describing is in fact NAT, it just
> didn't hit me at the time (duh). Sorry for the dupe, thanks for the
> help (Joel Newkirk too). Issue resolved.
>
>
>
> --__--__--
>
> Message: 2
> From: Thorsten Scherf <tscherf@web.de>
> Reply-To: tscherf@web.de
> To: "blkcore" <netfilter@blackcore.net>,
> <netfilter@lists.netfilter.org>
> Subject: Re: 2.4.20 - ntfilter (owner) problems
> Date: Wed, 8 Jan 2003 00:19:09 +0100
>
>> I recently compiled 2.4.20 with netfilter support, with the owner
>> modul=
> e
>> (-m owner), and after several attempts of trying to use it (worked for
>> 2.4.18), it gives an error.
>>
>> [root@scsi1 slinksi]# iptables -I OUTPUT -m owner --uid-owner root=20
>> iptables: Target problem
>
> Where is your target?! Is see no one!
>
>
>
> --__--__--
>
> Message: 3
> Date: Tue, 07 Jan 2003 16:59:53 -0700
> From: Tommy McNeely <Tommy.McNeely@Sun.COM>
> Subject: OT: curious about eth0/eth1
> To: netfilter@lists.netfilter.org
>
>
> I am curious about why people choose to make a certain interface
> internal or external...
>
> I have always made my "eth0" interface my inside interface.. and once I
> have the box UP and RUNNING (and firewalled), then bring up my outside
> interface "eth1" ... My primary network for smb/nfs/whatever is my
> inside network (thus eth0)... The outside interface is just a "extra
> interface" that I can add on (or move/change/delete) or even make it
> ppp0 if I happen to be changing ISP's :)
>
> I notice several people pick eth0 as their outside interface, and sorta
> "oh yea" the rest of the inside network is on eth1. I know the linux
> kernel could really care less what they are called, its mostly a
> "neatness" thing I guess... Also it seems like that leaves your box
> open to attack from the time it installs (if you do a NET based
> install) till the time you get around to actually putting a firewall
> on it.
>
> Again.. I am just curious as to why some do it one way.. and some the
> other... the above is only MY opinion, and could be dreadfully wrong :)
>
> Tommy
>
>
>
> --
> Tommy McNeely -- Tommy.McNeely@Sun.COM
> Sun Microsystems - IT Ops - Broomfield Campus Support
> Phone: x50888 / 303-464-4888 -- Fax: 720-566-3168
>
>
>
> --__--__--
>
> Message: 4
> Date: Tue, 07 Jan 2003 17:01:30 -0800
> From: Bob Balsover <balsover@pacbell.net>
> Subject: RE: netfilter digest, Vol 1 #513 - 12 msgs
> To: netfilter@lists.netfilter.org
>
>
> Message: 9
> Date: Tue, 7 Jan 2003 21:13:34 +0100
> From: Harald Welte <laforge@netfilter.org>
> To: Netfilter Development Mailinglist
> <netfilter-devel@lists.netfilter.org>
> Cc: Netfilter Mailinglist <netfilter@lists.netfilter.org>,
> Netfilter Announcement List
> <netfilter-announce@lists.netfilter.org>
> Subject: [ANNOUNCE] New netfilter/iptables patch-o-matic release
> Reply-To: coreteam@netfilter.org
>
>
> --KMIs29sPfC/9Gbii
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> While patch-o-matic-20030107 is announced on the home page, it is not
> listed on the download page...
>
>
>
> ------------------------------------------
> Good news, Everyone! (TM)
>
> The netfilter core team announces a new release of the netfilter
> patch-o-matic suite:
>
> patch-o-matic-20030107
>
> This release contains the most up-to-date bugfixes and new features
> for=20
> the netfilter/iptables subsystem of the 2.4.x Linux kernel.
>
> The patches are devided into several repositories. Which ones are to
> be used, depends on how conservative or adventurous the user is ;)
>
> 'submitted':
> Patches which have been submitted for kernel inclusion, most of
> them have already appeared in 2.4.20. It's really recommended
> to always apply those
>
> 'pending':
> Patches currently pending for kernel inclusion. They will
> almost certainly appear in the next official kernel release.
>
> 'base':
> New features which are self-contained enough so it's sure they
> don't clash with each other. Those are safe in the way that
> they
> don't harm already existing functionality. Playing with them
> might discover one or the other remaining bug... you've been
> warned.
>
> 'extra':
> New features which might cause other patches from 'extra' to
> clash with each other. Most interestingly, you will find here
> conntrack/nat helpers for H.323, PPTP, talk/ntalk, rsh, tftp,
> mms and amanda.
>
>
> Read more about the individual patches of this new patch-o-matic
> release at:
> http://www.netfilter.org/documentation/pomlist/pom-summary.html
>
> The new patch-o-matic release including a cryptographic GPG signature
> is available for download at
>
> http://www.netfilter.org/downloads.html#pom-20030107
>
>
> Enjoy,
> Harald (for the netfilter core team)
>
>
>
> --__--__--
>
> Message: 5
> From: "blkcore" <netfilter@blackcore.net>
> To: <netfilter@lists.netfilter.org>
> Subject: Re: 2.4.20 - ntfilter (owner) problems
> Date: Tue, 7 Jan 2003 17:26:49 -0800
>
> You don't need a -j target to use the owner module, I use it for
> bandwidth byte/counter logging, but heres some output for you to read.
>
> [root@scsi1 root]# uname -r
> 2.4.20-grsec
> [root@scsi1 root]# iptables -I OUTPUT -m owner --uid-owner root -j
> ACCEPT iptables: Target problem
>
> laptop:~# uname -r
> 2.4.19
> laptop:~# iptables -I OUTPUT -m owner --uid-owner root
> laptop:~# iptables -I OUTPUT -m owner --uid-owner root -j ACCEPT
> laptop:~#
>
> ----- Original Message -----
> From: "Thorsten Scherf" <tscherf@web.de>
> To: "blkcore" <netfilter@blackcore.net>;
> <netfilter@lists.netfilter.org> Sent: Tuesday, January 07, 2003 3:19 PM
> Subject: Re: 2.4.20 - ntfilter (owner) problems
>
>
>> I recently compiled 2.4.20 with netfilter support, with the owner
>> module (-m owner), and after several attempts of trying to use it
>> (worked for 2.4.18), it gives an error.
>>
>> [root@scsi1 slinksi]# iptables -I OUTPUT -m owner --uid-owner root
>> iptables: Target problem
>
> Where is your target?! Is see no one!
>
>
>
>
>
> --__--__--
>
> Message: 6
> From: Joel Newkirk <netfilter@newkirk.us>
> Reply-To: netfilter@newkirk.us
> To: Tommy McNeely <Tommy.McNeely@Sun.COM>,
> netfilter@lists.netfilter.org
> Subject: Re: OT: curious about eth0/eth1
> Date: Tue, 7 Jan 2003 22:47:24 -0500
>
> On Tuesday 07 January 2003 06:59 pm, Tommy McNeely wrote:
>> I am curious about why people choose to make a certain interface
>> internal or external...
>
>> I notice several people pick eth0 as their outside interface, and
>> sorta "oh yea" the rest of the inside network is on eth1. I know the
>> linux kernel could really care less what they are called, its mostly a
>> "neatness" thing I guess... Also it seems like that leaves your box
>> open to attack from the time it installs (if you do a NET based
>> install) till the time you get around to actually putting a firewall
>> on it.
>
> Why would this in particular leave a box exposed?
>
> I think that the main reason for 'some one way, some the other' is
> random= =20
> chance. However, consider this scenario:
>
> You have two NICs, eth0 and eth1. The connections on one you trust
> (-i=20 eth0 -j ACCEPT), the other you don't. One of them fails, or the
> board=20 works loose from it's socket, or something, so that upon
> booting the=20 machine you only have one interface. No matter which
> board fails, the=20 remaining board would be eth0. If eth0 is your
> 'trusted' internal=20 network in normal conditions, and it fails, then
> suddenly the untrusted=20 network is operating under the trusted
> network's rules. However, the IP=20 assignment (if static!) would
> remain that of the trusted network, so as=20 long as eth0 is configured
> with a static IP this shouldn't present a=20 risk. If, however, both
> are dynamic, (say DHCP assigned) then this=20 would qualify as a
> security hole, possibly a huge one. To be fair, this=20 is probably a
> very rare intersection of situations, but if eth0 is the=20 untrusted
> network, then any failure would be an annoyance, not a risk.
>
> j
>
>
>
>
> --__--__--
>
> Message: 7
> From: Joel Newkirk <netfilter@newkirk.us>
> Reply-To: netfilter@newkirk.us
> To: <oarojo@intermediacorp.com>,
> <netfilter@lists.netfilter.org>
> Subject: Re: portforwarding-HOWTO
> Date: Tue, 7 Jan 2003 22:59:25 -0500
>
> On Monday 06 January 2003 01:50 am, oarojo@intermediacorp.com wrote:
>> Hello people!!!
>>
>> I have set-up a linux box firewall with two ethernet cards; eth0
>> facing the internet and eth1 facing the internal network. Inside my
>> network is my mail server with an IP of 192.168.0.5. Now since my ISP
>> had only given me one valid IP address for my network, I wish to do
>> port-forwarding for ports 25 and 110. I did something like:
>>
>> # iptables -t nat -A PREROUTING -p tcp -i eth0 -d xxx.xxx.xxx.xxx
>> --dport 25 -j DNAT --to 192.168.0.5:25
>>
>> # iptables -t nat -A PREROUTING -p tcp -i eth0 -d xxx.xxx.xxx.xxx
>> --dport 110 -j DNAT --to 192.168.0.5:110
>>
>> # iptables -A FORWARD -p tcp -i eth0 -d 192.168.0.5 --dport 25=20 -j
>> ACCEPT=20
>> # iptables -A FORWARD -p tcp -i eth0 -d 192.168.0.5 --dport 110
>> -j ACCEPT
>>
>> # iptables-save > /etc/sysconfig/iptables
>>
>> When i used nmap to determine if ports 25 and 110 are open, it says:
>>
>> 25/tcp filtered smtp
>> 110/tcp filtered pop-3
>>
>> and when i try telnetting its valid ip
>>
>> #telnet xxx.xxx.xxx.xxx 25
>>
>>
>> it says "trying...." and can't connect at all...
>>
>> How's this? Did I missed something here? Please Help!!!
>
> Do you have a FORWARD rule to allow return traffic back out? You
> don't=20 mention one, so I have to ask. Something like this would
> work, if no=20 other more general rule allows it:
>
> iptables -A FORWARD -p tcp -o eth0 -s 192.168.0.5 -m multiport \
> --sport 25,110 -j ACCEPT
>
> Are you trying to telnet from outside the network? If you are trying
> to=20 do it from the firewall box or from anywhere on the 192.168
> network it=20 will fail unless you have other rules to help 'guide' the
> traffic back=20 through the firewall. (of course the rules you list
> are presumably for=20 traffice from outside...) See Oskar's tutorial's
> DNAT info at:
> http://iptables-tutorial.frozentux.net/chunkyhtml/targets.html#DNATTARGET
> where he explains the problem and the solution, if you need to allow=20
> access from the local network or firewall.
>
> j
>
>
>
>
> --__--__--
>
> _______________________________________________
> netfilter mailing list
> netfilter@lists.netfilter.org
> https://lists.netfilter.org/mailman/listinfo/netfilter
>
>
> End of netfilter Digest
^ permalink raw reply
* Re: BDI-2000
From: Marius Groeger @ 2003-01-08 9:23 UTC (permalink / raw)
To: Muaddi, Cecilia; +Cc: 'linuxppc-embedded@lists.linuxppc.org'
In-Reply-To: <885489B3B89FB6449F93E525DF78777F064531@srvnt506.ALLOPTIC.COM>
On Tue, 7 Jan 2003, Muaddi, Cecilia wrote:
> I have a proven hardware platform with
> PPC860, IMMR is mapped to 0xf0000000.
> 16 MB of SRAM in CS3 starts at physical locatio 0x0
> 1 MB of BootROM in CS1 starts at physical location 0x28000000
> 16 MB of code flash in CS5 starts at physical location 0x08000000
> some other IO mapped to miscellaneous addresses.
>
> The hardware platform is running vxWorks with vxWorks bootrom. I am trying
> to
> port the Linux to this custom hardware platform. I was successful building
I'm sorry for sounding a bit negative and not giving any real help,
but I can't resist commenting that being able to run vxWorks is NOT
proving the same HW can also run Linux. This is because Linux is using
the HW in ways WindRiver can only dream vxWorks could. We have seen
many HW going down on it's knees in the transition from a boot-loader/
interrupt handler kind of OS to real Unix systems with true virtual
memory support.
Regards,
Marius
-----------------------------------------------------------------------------
Marius Groeger SYSGO Real-Time Solutions AG mgroeger@sysgo.de
Software Engineering Embedded and Real-Time Software www.sysgo.de
Voice: +49-6136-9948-0 Am Pfaffenstein 14 www.osek.de
FAX: +49-6136-9948-10 55270 Klein-Winternheim, Germany www.elinos.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Status of linuxppc_2.5
From: Pantelis Antoniou @ 2003-01-08 9:18 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
Hi
I'm trying to compile linuxppc_2.5
and the following patch is needed to
make it compile.
The configuration is from
make pmac_config.
I didn't test it though, I don't have
a test pmac system, my intention is to
test it on a 8xx system.
BTW, are there any gotchas, or anything
I should pay attention moving
from 2.4 -> 2.5?
Regards
Pantelis
[-- Attachment #2: compile-2.5.diff --]
[-- Type: text/plain, Size: 3025 bytes --]
===== arch/ppc/kernel/traps.c 1.21 vs edited =====
--- 1.21/arch/ppc/kernel/traps.c Mon Jan 6 09:02:42 2003
+++ edited/arch/ppc/kernel/traps.c Wed Jan 8 09:23:43 2003
@@ -174,7 +174,7 @@
(*nip & 0x100)? "OUT to": "IN from",
regs->gpr[rb] - _IO_BASE, nip);
regs->msr |= MSR_RI;
- regs->nip = fixup;
+ regs->nip = entry->fixup;
return;
}
}
===== drivers/block/swim3.c 1.22 vs edited =====
--- 1.22/drivers/block/swim3.c Fri Dec 6 03:10:45 2002
+++ edited/drivers/block/swim3.c Wed Jan 8 10:40:20 2003
@@ -26,6 +26,7 @@
#include <linux/ioctl.h>
#include <linux/blk.h>
#include <linux/devfs_fs_kernel.h>
+#include <linux/interrupt.h>
#include <asm/io.h>
#include <asm/dbdma.h>
#include <asm/prom.h>
===== drivers/macintosh/mediabay.c 1.10 vs edited =====
--- 1.10/drivers/macintosh/mediabay.c Tue Nov 12 01:47:53 2002
+++ edited/drivers/macintosh/mediabay.c Wed Jan 8 10:53:47 2003
@@ -36,6 +36,7 @@
#include <asm/keylargo.h>
#include <linux/adb.h>
#include <linux/pmu.h>
+#include <linux/ide.h>
#ifdef CONFIG_PMAC_PBOOK
static int mb_notify_sleep(struct pmu_sleep_notifier *self, int when);
@@ -599,7 +600,7 @@
if (bay->cd_index >= 0) {
printk(KERN_DEBUG "Unregistering mb %d ide, index:%d\n", i,
bay->cd_index);
- ide_unregister(&ide_hwifs[bay->cd_index]);
+ ide_unregister(bay->cd_index);
bay->cd_index = -1;
}
if (bay->cd_retry) {
===== drivers/usb/host/ohci-pci.c 1.6 vs edited =====
--- 1.6/drivers/usb/host/ohci-pci.c Sun Dec 1 04:21:11 2002
+++ edited/drivers/usb/host/ohci-pci.c Wed Jan 8 10:49:46 2003
@@ -18,6 +18,7 @@
#include <asm/machdep.h>
#include <asm/pmac_feature.h>
#include <asm/pci-bridge.h>
+#include <asm/prom.h>
#ifndef CONFIG_PM
# define CONFIG_PM
#endif
===== fs/nfs/write.c 1.36 vs edited =====
--- 1.36/fs/nfs/write.c Sat Dec 21 08:29:02 2002
+++ edited/fs/nfs/write.c Wed Jan 8 10:38:32 2003
@@ -828,7 +828,9 @@
struct nfs_write_data *data = (struct nfs_write_data *) task->tk_calldata;
struct nfs_writeargs *argp = &data->args;
struct nfs_writeres *resp = &data->res;
+#if defined(CONFIG_NFS_V3) || defined(CONFIG_NFS_V4)
struct inode *inode = data->inode;
+#endif
struct nfs_page *req;
struct page *page;
===== include/linux/ide.h 1.32 vs edited =====
--- 1.32/include/linux/ide.h Sat Dec 28 21:09:38 2002
+++ edited/include/linux/ide.h Wed Jan 8 10:47:16 2003
@@ -334,6 +334,9 @@
*/
int ide_register_hw(hw_regs_t *hw, struct hwif_s **hwifp);
+/* XXX panto */
+void ide_unregister (unsigned int index);
+
/*
* Set up hw_regs_t structure before calling ide_register_hw (optional)
*/
^ permalink raw reply
* Re: Re: /var/lib/nfs/sm/ files
From: Trond Myklebust @ 2003-01-08 9:13 UTC (permalink / raw)
To: David Shirley, Christian Reis; +Cc: NFS
In-Reply-To: <00ed01c2b6ed$2a9d9530$64070786@synack>
On Wednesday 08 January 2003 09:08, David Shirley wrote:
> Trond,
>
> Will the client automatically remount or fix the mount
> once the server comes back up? ie after the server
> notifys the client, or does the client still have to restart
> nfs?
If the client and server both comply with the NFS standards, then the client
should never have to remount after a server reboot. rpc.statd exists purely
for the benefit of the NFS file locking.
Cheers,
Trond
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Oops on kernel 2.4.20
From: javamaster @ 2003-01-08 9:22 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
I have a RedHat 7.0 distro on a Pentium 200 system with 80mb of ram. I
just upgraded my kernel to 2.4.20 and I keep getting an oops whenever
I'm doing something fairly intensive (make dep for the kernel always
causes it). I've attached the log captured by klogd, the output from
ksymoops and the gdb disassemble of the offending function shrink_cache.
The system works fine with the 2.2.16-22 kernel that came with RedHat
7.0. The only thing weird about my system is that the primary IDE
interface is not working. Any ideas?
javamaster@bonaplus.com
[-- Attachment #2: gdb_output.txt --]
[-- Type: text/plain, Size: 13998 bytes --]
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
(gdb) disassemble shrink_cah\b \bche
Dump of assembler code for function shrink_cache:
0xc0129280 <shrink_cache>: push %ebp
0xc0129281 <shrink_cache+1>: push %edi
0xc0129282 <shrink_cache+2>: mov %eax,%edi
0xc0129284 <shrink_cache+4>: push %esi
0xc0129285 <shrink_cache+5>: push %ebx
0xc0129286 <shrink_cache+6>: mov %edi,%ebx
0xc0129288 <shrink_cache+8>: sub $0x24,%esp
0xc012928b <shrink_cache+11>: mov %edx,0x10(%esp,1)
0xc012928f <shrink_cache+15>: mov 0xc02b6058,%edx
0xc0129295 <shrink_cache+21>: mov %edx,%eax
0xc0129297 <shrink_cache+23>: sar $0x1f,%edx
0xc012929a <shrink_cache+26>: idiv 0x38(%esp,1),%eax
0xc012929e <shrink_cache+30>: mov 0x38(%esp,1),%edx
0xc01292a2 <shrink_cache+34>: mov %eax,%ebp
0xc01292a4 <shrink_cache+36>: mov $0xa,%eax
0xc01292a9 <shrink_cache+41>: mov %ecx,0xc(%esp,1)
0xc01292ad <shrink_cache+45>: sub %edx,%eax
0xc01292af <shrink_cache+47>: mov $0x66666667,%edx
0xc01292b4 <shrink_cache+52>: mov %al,%cl
0xc01292b6 <shrink_cache+54>: mov %edx,%eax
0xc01292b8 <shrink_cache+56>: imul %ebp,%eax
0xc01292ba <shrink_cache+58>: sar $0x2,%edx
0xc01292bd <shrink_cache+61>: mov %ebp,%eax
0xc01292bf <shrink_cache+63>: sar $0x1f,%eax
0xc01292c2 <shrink_cache+66>: shl %cl,%ebx
0xc01292c4 <shrink_cache+68>: sub %eax,%edx
0xc01292c6 <shrink_cache+70>: cmp %ebx,%edx
0xc01292c8 <shrink_cache+72>: jle 0xc01292cc <shrink_cache+76>
0xc01292ca <shrink_cache+74>: mov %ebx,%edx
0xc01292cc <shrink_cache+76>: dec %ebp
0xc01292cd <shrink_cache+77>: mov %edx,0x8(%esp,1)
0xc01292d1 <shrink_cache+81>: js 0xc0129583 <shrink_cache+771>
0xc01292d7 <shrink_cache+87>: mov 0xc02613fc,%ecx
0xc01292dd <shrink_cache+93>: cmp $0xc02613f8,%ecx
0xc01292e3 <shrink_cache+99>: je 0xc0129583 <shrink_cache+771>
0xc01292e9 <shrink_cache+105>: mov $0xffffe000,%edx
0xc01292ee <shrink_cache+110>: and %esp,%edx
0xc01292f0 <shrink_cache+112>: movl $0xffffe000,0x4(%esp,1)
0xc01292f8 <shrink_cache+120>: mov %edx,0x4(%esp,1)
0xc01292fc <shrink_cache+124>: lea 0x0(%esi,1),%esi
0xc0129300 <shrink_cache+128>: mov 0x4(%esp,1),%edx
0xc0129304 <shrink_cache+132>: mov 0x14(%edx),%eax
0xc0129307 <shrink_cache+135>: test %eax,%eax
0xc0129309 <shrink_cache+137>: je 0xc0129320 <shrink_cache+160>
0xc012930b <shrink_cache+139>: movl $0x0,(%edx)
0xc0129311 <shrink_cache+145>: call 0xc0110840 <schedule>
0xc0129316 <shrink_cache+150>: jmp 0xc012956e <shrink_cache+750>
0xc012931b <shrink_cache+155>: nop
0xc012931c <shrink_cache+156>: lea 0x0(%esi,1),%esi
0xc0129320 <shrink_cache+160>: lea 0xffffffe4(%ecx),%esi
0xc0129323 <shrink_cache+163>: mov 0xfffffffc(%ecx),%eax
0xc0129326 <shrink_cache+166>: xor $0x40,%eax
0xc0129329 <shrink_cache+169>: and $0x40,%eax
0xc012932c <shrink_cache+172>: je 0xc0129336 <shrink_cache+182>
0xc012932e <shrink_cache+174>: ud2a
0xc0129330 <shrink_cache+176>: add %di,0x22(%esp,%ebx,4)
0xc0129335 <shrink_cache+181>: rorb $0x0,0x80a9fc41(%ebx)
0xc012933c <shrink_cache+188>: add %al,(%eax)
0xc012933e <shrink_cache+190>: je 0xc0129348 <shrink_cache+200>
0xc0129340 <shrink_cache+192>: ud2a
0xc0129342 <shrink_cache+194>: addr16 add %edi,-100(%si)
0xc0129346 <shrink_cache+198>: and %al,%al
0xc0129348 <shrink_cache+200>: mov (%ecx),%eax
0xc012934a <shrink_cache+202>: mov 0x4(%ecx),%edx
0xc012934d <shrink_cache+205>: xor %ebx,%ebx
0xc012934f <shrink_cache+207>: mov %edx,0x4(%eax)
0xc0129352 <shrink_cache+210>: mov %eax,(%edx)
0xc0129354 <shrink_cache+212>: movl $0x0,(%ecx)
0xc012935a <shrink_cache+218>: movl $0x0,0x4(%ecx)
0xc0129361 <shrink_cache+225>: mov 0xc02613f8,%eax
0xc0129366 <shrink_cache+230>: mov %ecx,0x4(%eax)
0xc0129369 <shrink_cache+233>: mov %eax,(%ecx)
0xc012936b <shrink_cache+235>: movl $0xc02613f8,0x4(%ecx)
0xc0129372 <shrink_cache+242>: mov %ecx,0xc02613f8
0xc0129378 <shrink_cache+248>: mov 0xfffffff8(%ecx),%eax
0xc012937b <shrink_cache+251>: test %eax,%eax
0xc012937d <shrink_cache+253>: sete %bl
0xc0129380 <shrink_cache+256>: test %ebx,%ebx
0xc0129382 <shrink_cache+258>: jne 0xc012956e <shrink_cache+750>
0xc0129388 <shrink_cache+264>: xor %eax,%eax
0xc012938a <shrink_cache+266>: mov 0xffffffff(%ecx),%al
0xc012938d <shrink_cache+269>: mov 0xc02b605c(,%eax,4),%edx
0xc0129394 <shrink_cache+276>: mov 0x10(%esp,1),%eax
0xc0129398 <shrink_cache+280>: mov 0x98(%eax),%eax
0xc012939e <shrink_cache+286>: cmp %eax,0x98(%edx)
0xc01293a4 <shrink_cache+292>: jne 0xc012956e <shrink_cache+750>
0xc01293aa <shrink_cache+298>: cmp 0x10(%esp,1),%edx
0xc01293ae <shrink_cache+302>: ja 0xc012956e <shrink_cache+750>
0xc01293b4 <shrink_cache+308>: mov 0x28(%esi),%eax
0xc01293b7 <shrink_cache+311>: test %eax,%eax
0xc01293b9 <shrink_cache+313>: jne 0xc01293d2 <shrink_cache+338>
0xc01293bb <shrink_cache+315>: mov 0xfffffff8(%ecx),%eax
0xc01293be <shrink_cache+318>: cmp $0x1,%eax
0xc01293c1 <shrink_cache+321>: jne 0xc0129503 <shrink_cache+643>
0xc01293c7 <shrink_cache+327>: mov 0xffffffec(%ecx),%edx
0xc01293ca <shrink_cache+330>: test %edx,%edx
0xc01293cc <shrink_cache+332>: je 0xc0129503 <shrink_cache+643>
0xc01293d2 <shrink_cache+338>: bts %ebx,0xfffffffc(%ecx)
0xc01293d6 <shrink_cache+342>: sbb %eax,%eax
0xc01293d8 <shrink_cache+344>: test %eax,%eax
0xc01293da <shrink_cache+346>: je 0xc0129413 <shrink_cache+403>
0xc01293dc <shrink_cache+348>: mov 0xfffffffc(%ecx),%eax
0xc01293df <shrink_cache+351>: test $0x8000,%eax
0xc01293e4 <shrink_cache+356>: je 0xc012956e <shrink_cache+750>
0xc01293ea <shrink_cache+362>: testl $0x100,0xc(%esp,1)
0xc01293f2 <shrink_cache+370>: je 0xc012956e <shrink_cache+750>
0xc01293f8 <shrink_cache+376>: incl 0xfffffff8(%ecx)
0xc01293fb <shrink_cache+379>: mov 0xfffffffc(%ecx),%eax
0xc01293fe <shrink_cache+382>: and $0x1,%eax
0xc0129401 <shrink_cache+385>: je 0xc01294c7 <shrink_cache+583>
0xc0129407 <shrink_cache+391>: push %esi
0xc0129408 <shrink_cache+392>: call 0xc0122f10 <___wait_on_page>
0xc012940d <shrink_cache+397>: pop %eax
0xc012940e <shrink_cache+398>: jmp 0xc01294c7 <shrink_cache+583>
0xc0129413 <shrink_cache+403>: mov 0xfffffffc(%ecx),%eax
0xc0129416 <shrink_cache+406>: and $0x10,%eax
0xc0129419 <shrink_cache+409>: je 0xc0129480 <shrink_cache+512>
0xc012941b <shrink_cache+411>: mov 0xfffffff8(%ecx),%edx
0xc012941e <shrink_cache+414>: mov 0x28(%esi),%ecx
0xc0129421 <shrink_cache+417>: test %ecx,%ecx
0xc0129423 <shrink_cache+419>: je 0xc0129430 <shrink_cache+432>
0xc0129425 <shrink_cache+421>: xor %eax,%eax
0xc0129427 <shrink_cache+423>: cmp $0x2,%edx
0xc012942a <shrink_cache+426>: jmp 0xc0129435 <shrink_cache+437>
0xc012942c <shrink_cache+428>: lea 0x0(%esi,1),%esi
0xc0129430 <shrink_cache+432>: xor %eax,%eax
0xc0129432 <shrink_cache+434>: cmp $0x1,%edx
0xc0129435 <shrink_cache+437>: sete %al
0xc0129438 <shrink_cache+440>: test %eax,%eax
0xc012943a <shrink_cache+442>: je 0xc0129483 <shrink_cache+515>
0xc012943c <shrink_cache+444>: mov 0x8(%esi),%eax
0xc012943f <shrink_cache+447>: test %eax,%eax
0xc0129441 <shrink_cache+449>: je 0xc0129483 <shrink_cache+515>
0xc0129443 <shrink_cache+451>: mov 0x1c(%eax),%eax
0xc0129446 <shrink_cache+454>: testl $0x100,0xc(%esp,1)
0xc012944e <shrink_cache+462>: mov (%eax),%edx
0xc0129450 <shrink_cache+464>: je 0xc0129483 <shrink_cache+515>
0xc0129452 <shrink_cache+466>: test %edx,%edx
0xc0129454 <shrink_cache+468>: je 0xc0129483 <shrink_cache+515>
0xc0129456 <shrink_cache+470>: mov $0x4,%eax
0xc012945b <shrink_cache+475>: btr %eax,0x18(%esi)
0xc012945f <shrink_cache+479>: mov $0xf,%eax
0xc0129464 <shrink_cache+484>: bts %eax,0x18(%esi)
0xc0129468 <shrink_cache+488>: incl 0x14(%esi)
0xc012946b <shrink_cache+491>: push %esi
0xc012946c <shrink_cache+492>: call *%edx
0xc012946e <shrink_cache+494>: mov %esi,%eax
0xc0129470 <shrink_cache+496>: xor %edx,%edx
0xc0129472 <shrink_cache+498>: call 0xc012a650 <__free_pages>
0xc0129477 <shrink_cache+503>: pop %esi
0xc0129478 <shrink_cache+504>: jmp 0xc012956e <shrink_cache+750>
0xc012947d <shrink_cache+509>: lea 0x0(%esi),%esi
0xc0129480 <shrink_cache+512>: mov 0x28(%esi),%ecx
0xc0129483 <shrink_cache+515>: test %ecx,%ecx
0xc0129485 <shrink_cache+517>: je 0xc01294d5 <shrink_cache+597>
0xc0129487 <shrink_cache+519>: incl 0x14(%esi)
0xc012948a <shrink_cache+522>: mov 0xc(%esp,1),%ebx
0xc012948e <shrink_cache+526>: push %ebx
0xc012948f <shrink_cache+527>: push %esi
0xc0129490 <shrink_cache+528>: call 0xc0131ff0 <try_to_release_page>
0xc0129495 <shrink_cache+533>: pop %edx
0xc0129496 <shrink_cache+534>: test %eax,%eax
0xc0129498 <shrink_cache+536>: pop %ecx
0xc0129499 <shrink_cache+537>: je 0xc01294c0 <shrink_cache+576>
0xc012949b <shrink_cache+539>: mov 0x8(%esi),%eax
0xc012949e <shrink_cache+542>: test %eax,%eax
0xc01294a0 <shrink_cache+544>: jne 0xc01294b5 <shrink_cache+565>
0xc01294a2 <shrink_cache+546>: mov %esi,%eax
0xc01294a4 <shrink_cache+548>: call 0xc0122fd0 <unlock_page>
0xc01294a9 <shrink_cache+553>: mov %esi,%eax
0xc01294ab <shrink_cache+555>: call 0xc0128d30 <__lru_cache_del>
0xc01294b0 <shrink_cache+560>: jmp 0xc0129562 <shrink_cache+738>
0xc01294b5 <shrink_cache+565>: xor %edx,%edx
0xc01294b7 <shrink_cache+567>: mov %esi,%eax
0xc01294b9 <shrink_cache+569>: call 0xc012a650 <__free_pages>
0xc01294be <shrink_cache+574>: jmp 0xc01294d5 <shrink_cache+597>
0xc01294c0 <shrink_cache+576>: mov %esi,%eax
0xc01294c2 <shrink_cache+578>: call 0xc0122fd0 <unlock_page>
0xc01294c7 <shrink_cache+583>: xor %edx,%edx
0xc01294c9 <shrink_cache+585>: mov %esi,%eax
0xc01294cb <shrink_cache+587>: call 0xc012a650 <__free_pages>
0xc01294d0 <shrink_cache+592>: jmp 0xc012956e <shrink_cache+750>
0xc01294d5 <shrink_cache+597>: mov 0x8(%esi),%ecx
0xc01294d8 <shrink_cache+600>: test %ecx,%ecx
0xc01294da <shrink_cache+602>: je 0xc01294fc <shrink_cache+636>
0xc01294dc <shrink_cache+604>: mov 0x28(%esi),%ebx
0xc01294df <shrink_cache+607>: mov 0x14(%esi),%edx
0xc01294e2 <shrink_cache+610>: test %ebx,%ebx
0xc01294e4 <shrink_cache+612>: je 0xc01294f0 <shrink_cache+624>
0xc01294e6 <shrink_cache+614>: xor %eax,%eax
0xc01294e8 <shrink_cache+616>: cmp $0x2,%edx
0xc01294eb <shrink_cache+619>: jmp 0xc01294f5 <shrink_cache+629>
0xc01294ed <shrink_cache+621>: lea 0x0(%esi),%esi
0xc01294f0 <shrink_cache+624>: xor %eax,%eax
0xc01294f2 <shrink_cache+626>: cmp $0x1,%edx
0xc01294f5 <shrink_cache+629>: sete %al
0xc01294f8 <shrink_cache+632>: test %eax,%eax
0xc01294fa <shrink_cache+634>: jne 0xc0129520 <shrink_cache+672>
0xc01294fc <shrink_cache+636>: mov %esi,%eax
0xc01294fe <shrink_cache+638>: call 0xc0122fd0 <unlock_page>
0xc0129503 <shrink_cache+643>: decl 0x8(%esp,1)
0xc0129507 <shrink_cache+647>: jns 0xc012956e <shrink_cache+750>
0xc0129509 <shrink_cache+649>: mov 0x10(%esp,1),%ecx
0xc012950d <shrink_cache+653>: mov 0xc(%esp,1),%edx
0xc0129511 <shrink_cache+657>: mov 0x38(%esp,1),%eax
0xc0129515 <shrink_cache+661>: call 0xc0128dc0 <swap_out>
0xc012951a <shrink_cache+666>: jmp 0xc0129583 <shrink_cache+771>
0xc012951c <shrink_cache+668>: lea 0x0(%esi,1),%esi
0xc0129520 <shrink_cache+672>: mov 0x18(%esi),%eax
0xc0129523 <shrink_cache+675>: and $0x10,%eax
0xc0129526 <shrink_cache+678>: je 0xc0129531 <shrink_cache+689>
0xc0129528 <shrink_cache+680>: mov %esi,%eax
0xc012952a <shrink_cache+682>: call 0xc0122fd0 <unlock_page>
0xc012952f <shrink_cache+687>: jmp 0xc012956e <shrink_cache+750>
0xc0129531 <shrink_cache+689>: cmp $0xc0261460,%ecx
0xc0129537 <shrink_cache+695>: je 0xc0129542 <shrink_cache+706>
0xc0129539 <shrink_cache+697>: push %esi
0xc012953a <shrink_cache+698>: call 0xc0122460 <__remove_inode_page>
0xc012953f <shrink_cache+703>: pop %ecx
0xc0129540 <shrink_cache+704>: jmp 0xc0129554 <shrink_cache+724>
0xc0129542 <shrink_cache+706>: mov 0xc(%esi),%ebx
0xc0129545 <shrink_cache+709>: push %esi
0xc0129546 <shrink_cache+710>: call 0xc012a9f0 <__delete_from_swap_cache>
0xc012954b <shrink_cache+715>: mov %ebx,(%esp,1)
0xc012954e <shrink_cache+718>: call 0xc012af10 <swap_free>
0xc0129553 <shrink_cache+723>: pop %edx
0xc0129554 <shrink_cache+724>: mov %esi,%eax
0xc0129556 <shrink_cache+726>: call 0xc0128d30 <__lru_cache_del>
0xc012955b <shrink_cache+731>: mov %esi,%eax
0xc012955d <shrink_cache+733>: call 0xc0122fd0 <unlock_page>
0xc0129562 <shrink_cache+738>: xor %edx,%edx
0xc0129564 <shrink_cache+740>: mov %esi,%eax
0xc0129566 <shrink_cache+742>: call 0xc012a650 <__free_pages>
0xc012956b <shrink_cache+747>: dec %edi
0xc012956c <shrink_cache+748>: je 0xc0129583 <shrink_cache+771>
0xc012956e <shrink_cache+750>: dec %ebp
0xc012956f <shrink_cache+751>: js 0xc0129583 <shrink_cache+771>
0xc0129571 <shrink_cache+753>: mov 0xc02613fc,%ecx
0xc0129577 <shrink_cache+759>: cmp $0xc02613f8,%ecx
0xc012957d <shrink_cache+765>: jne 0xc0129300 <shrink_cache+128>
0xc0129583 <shrink_cache+771>: mov %edi,%eax
0xc0129585 <shrink_cache+773>: add $0x24,%esp
0xc0129588 <shrink_cache+776>: pop %ebx
0xc0129589 <shrink_cache+777>: pop %esi
0xc012958a <shrink_cache+778>: pop %edi
0xc012958b <shrink_cache+779>: pop %ebp
0xc012958c <shrink_cache+780>: ret
0xc012958d <shrink_cache+781>: lea 0x0(%esi),%esi
End of assembler dump.
(gdb) q
[-- Attachment #3: ksymoops_output.txt --]
[-- Type: text/plain, Size: 2260 bytes --]
ksymoops 2.4.8 on i586 2.4.20. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.20/ (default)
-m /boot/System.map (specified)
No modules in ksyms, skipping objects
Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file?
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000400
<4>00000400
<1>*pde = 00000000
<4>Oops: 0000
<4>CPU: 0
<4>EIP: 0010:[<00000400>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
<4>EFLAGS: 00010202
<4>eax: 00000001 ebx: c02b60a0 ecx: c5804000 edx: 00000004
<4>esi: 00000004 edi: 00000019 ebp: 0000094e esp: c11aff28
<4>ds: 0018 es: 0018 ss: 0018
<4>Process kswapd (pid: 4, stackpage=c11af000)
<4>Stack: c10aa504 c0129553 c02b60a0 00000020 c11ae000 000000ef 000001d0 c0261570
<4> 00007006 00000020 00000018 00000018 00000020 000001d0 00000006 00007006
<4> c01296e5 00000006 00000003 c0261570 00000006 000001d0 c0261570 00000000
<4>Call Trace: [shrink_cache+723/784] [shrink_caches+85/128] [try_to_free_pages_zone+48/80] [kswapd_balance_pgdat+69/144] [kswapd_balance+22/48]
<4>Code: Bad EIP value.
>>EIP; 00000400 Before first symbol <=====
>>ebx; c02b60a0 <swap_info+0/680>
<4> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000300
<4>00000300
<1>*pde = 00000000
<4>Oops: 0000
<4>CPU: 0
<4>EIP: 0010:[<00000300>] Not tainted
<4>EFLAGS: 00010202
<4>eax: 00000001 ebx: c02b60a0 ecx: c5804000 edx: 00000003
<4>esi: 00000003 edi: 00000020 ebp: 00000980 esp: c067bd88
<4>ds: 0018 es: 0018 ss: 0018
<4>Process mkdep (pid: 1565, stackpage=c067b000)
<4>Stack: c10a4e38 c0129553 c02b60a0 00000202 c067a000 000000f1 000001d2 c0261570
<4> c10df0c0 c34f14c0 c10dfcfc 00000001 00000020 000001d2 00000006 00007222
<4> c01296e5 00000006 00000003 c0261570 00000006 000001d2 c0261570 00000000
<4>Call Trace: [shrink_cache+723/784] [shrink_caches+85/128] [try_to_free_pages_zone+48/80] [balance_classzone+90/528] [__alloc_pages+274/368]
<4>Code: Bad EIP value.
>>EIP; 00000300 Before first symbol <=====
>>ebx; c02b60a0 <swap_info+0/680>
1 warning issued. Results may not be reliable.
[-- Attachment #4: oops.txt --]
[-- Type: text/plain, Size: 12693 bytes --]
klogd 1.3-3, log source = /proc/kmsg started.
Inspecting /boot/System.map-2.4.20
Loaded 15928 symbols from /boot/System.map-2.4.20.
Symbols match kernel version 2.4.20.
No module symbols loaded.
<1>Unable to handle kernel NULL pointer dereference at virtual address 00000400
<4> printing eip:
<4>00000400
<1>*pde = 00000000
<4>Oops: 0000
<4>CPU: 0
<4>EIP: 0010:[<00000400>] Not tainted
<4>EFLAGS: 00010202
<4>eax: 00000001 ebx: c02b60a0 ecx: c5804000 edx: 00000004
<4>esi: 00000004 edi: 00000019 ebp: 0000094e esp: c11aff28
<4>ds: 0018 es: 0018 ss: 0018
<4>Process kswapd (pid: 4, stackpage=c11af000)
<4>Stack: c10aa504 c0129553 c02b60a0 00000020 c11ae000 000000ef 000001d0 c0261570
<4> 00007006 00000020 00000018 00000018 00000020 000001d0 00000006 00007006
<4> c01296e5 00000006 00000003 c0261570 00000006 000001d0 c0261570 00000000
<4>Call Trace: [shrink_cache+723/784] [shrink_caches+85/128] [try_to_free_pages_zone+48/80] [kswapd_balance_pgdat+69/144] [kswapd_balance+22/48]
<4> [kswapd+161/192] [kswapd+0/192] [kernel_thread+43/64]
<4>
<4>Code: Bad EIP value.
<4> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000300
<4> printing eip:
<4>00000300
<1>*pde = 00000000
<4>Oops: 0000
<4>CPU: 0
<4>EIP: 0010:[<00000300>] Not tainted
<4>EFLAGS: 00010202
<4>eax: 00000001 ebx: c02b60a0 ecx: c5804000 edx: 00000003
<4>esi: 00000003 edi: 00000020 ebp: 00000980 esp: c067bd88
<4>ds: 0018 es: 0018 ss: 0018
<4>Process mkdep (pid: 1565, stackpage=c067b000)
<4>Stack: c10a4e38 c0129553 c02b60a0 00000202 c067a000 000000f1 000001d2 c0261570
<4> c10df0c0 c34f14c0 c10dfcfc 00000001 00000020 000001d2 00000006 00007222
<4> c01296e5 00000006 00000003 c0261570 00000006 000001d2 c0261570 00000000
<4>Call Trace: [shrink_cache+723/784] [shrink_caches+85/128] [try_to_free_pages_zone+48/80] [balance_classzone+90/528] [__alloc_pages+274/368]
<4> [page_cache_read+95/192] [read_cluster_nonblocking+41/64] [filemap_nopage+269/528] [iget4+211/224] [filemap_nopage+0/528] [do_no_page+83/464]
<4> [handle_mm_fault+88/192] [do_mmap_pgoff+1240/1440] [do_page_fault+390/1227] [open_namei+728/1280] [old_mmap+258/320] [old_mmap+298/320]
<4> [do_page_fault+0/1227] [error_code+52/64]
<4>
<4>Code: Bad EIP value.
<4> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000100
<4> printing eip:
<4>00000100
<1>*pde = 00000000
<4>Oops: 0000
<4>CPU: 0
<4>EIP: 0010:[<00000100>] Not tainted
<4>EFLAGS: 00010202
<4>eax: 00000001 ebx: c02b60a0 ecx: c5804000 edx: 00000001
<4>esi: 00000001 edi: 00000013 ebp: 0000096c esp: c43b7dcc
<4>ds: 0018 es: 0018 ss: 0018
<4>Process gdb (pid: 1573, stackpage=c43b7000)
<4>Stack: c10cfcb0 c0129553 c02b60a0 00000003 c43b6000 000000e8 000001d2 c0261570
<4> c10dfbb8 c38e7040 c10df48c 00000000 00000020 000001d2 00000006 0000723a
<4> c01296e5 00000006 00000003 c0261570 00000006 000001d2 c0261570 00000000
<4>Call Trace: [shrink_cache+723/784] [shrink_caches+85/128] [try_to_free_pages_zone+48/80] [balance_classzone+90/528] [__alloc_pages+274/368]
<4> [do_anonymous_page+94/320] [do_no_page+53/464] [handle_mm_fault+88/192] [do_page_fault+390/1227] [update_process_times+32/176] [update_wall_time+11/64]
<4> [timer_bh+39/928] [timer_interrupt+116/288] [bh_action+27/80] [tasklet_hi_action+70/112] [do_softirq+85/160] [do_page_fault+0/1227]
<4> [error_code+52/64]
<4>
<4>Code: Bad EIP value.
<4> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000400
<4> printing eip:
<4>00000400
<1>*pde = 00000000
<4>Oops: 0000
<4>CPU: 0
<4>EIP: 0010:[<00000400>] Not tainted
<4>EFLAGS: 00010202
<4>eax: 00000001 ebx: c02b60a0 ecx: c5804000 edx: 00000004
<4>esi: 00000004 edi: c4e09ff8 ebp: c1130220 esp: c3dede9c
<4>ds: 0018 es: 0018 ss: 0018
<4>Process rhnsd (pid: 776, stackpage=c3ded000)
<4>Stack: c10b26f4 c0120836 c02b60a0 00000002 bfffef20 00000001 c1130220 c112ef60
<4> c0120c2b c1130220 c112ef60 bfffef20 c4e09ff8 00000400 00000001 0000000f
<4> c3dec560 c4db619c c4db619c c3dedf30 c01069ed 0000000f c4db619c c1130220
<4>Call Trace: [do_swap_page+134/256] [handle_mm_fault+107/192] [handle_signal+125/256] [do_page_fault+390/1227] [dput+289/336]
<4> [schedule_timeout+132/160] [process_timeout+0/80] [sys_nanosleep+272/400] [do_page_fault+0/1227] [error_code+52/64]
<4>
<4>Code: Bad EIP value.
<4> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000300
<4> printing eip:
<4>00000300
<1>*pde = 00000000
<4>Oops: 0000
<4>CPU: 0
<4>EIP: 0010:[<00000300>] Not tainted
<4>EFLAGS: 00010207
<4>eax: 00000000 ebx: c02b60a0 ecx: c5804000 edx: 00003fde
<4>esi: 00000003 edi: c10b11a4 ebp: c10bf038 esp: c3dedca4
<4>ds: 0018 es: 0018 ss: 0018
<4>Process rhnsd (pid: 776, stackpage=c3ded000)
<4>Stack: c10b11a4 c012aa80 c02b60a0 c02b60a0 c02b60a0 c012b11f c10b11a4 00000300
<4> 00004000 00003000 c011f8b9 00000300 00000002 c4e0a4e0 00000000 40139000
<4> c3def400 40135000 00000000 40139000 c3def400 00000001 c01a0db4 c02c1f14
<4>Call Trace: [delete_from_swap_cache+64/80] [free_swap_and_cache+111/160] [zap_page_range+409/640] [poke_blanked_console+100/112] [fput+198/240]
<4> [exit_mmap+177/288] [mmput+81/112] [do_exit+143/544] [bust_spinlocks+62/80] [die+77/112] [do_page_fault+919/1227]
<4> [start_request+430/544] [ide_do_request+664/736] [do_ide_request+15/32] [schedule+772/816] [do_page_fault+0/1227] [error_code+52/64]
<4> [do_swap_page+134/256] [handle_mm_fault+107/192] [handle_signal+125/256] [do_page_fault+390/1227] [dput+289/336] [schedule_timeout+132/160]
<4> [process_timeout+0/80] [sys_nanosleep+272/400] [do_page_fault+0/1227] [error_code+52/64]
<4>
<4>Code: Bad EIP value.
<4> <1>Unable to handle kernel paging request at virtual address 00001300
<4> printing eip:
<4>00001300
<1>*pde = 00000000
<4>Oops: 0000
<4>CPU: 0
<4>EIP: 0010:[<00001300>] Not tainted
<4>EFLAGS: 00010202
<4>eax: 00000001 ebx: c02b60a0 ecx: c5804000 edx: 00000013
<4>esi: 00000013 edi: c41b3798 ebp: c1130520 esp: c3e85e9c
<4>ds: 0018 es: 0018 ss: 0018
<4>Process xfs (pid: 744, stackpage=c3e85000)
<4>Stack: c10a9928 c0120836 c02b60a0 00000001 401e6004 00000000 c1130520 c4496e60
<4> c0120c2b c1130520 c4496e60 401e6004 c41b3798 00001300 00000000 0000000f
<4> c3e84560 c4af367c c4af367c c3e85f30 c01069ed 0000000f c4af367c c1130520
<4>Call Trace: [do_swap_page+134/256] [handle_mm_fault+107/192] [handle_signal+125/256] [do_page_fault+390/1227] [do_sigaction+197/256]
<4> [sys_rt_sigaction+153/240] [sys_socketcall+289/528] [do_page_fault+0/1227] [error_code+52/64]
<4>
<4>Code: Bad EIP value.
<4> <1>Unable to handle kernel NULL pointer dereference at virtual address 00000500
<4> printing eip:
<4>00000500
<1>*pde = 00000000
<4>Oops: 0000
<4>CPU: 0
<4>EIP: 0010:[<00000500>] Not tainted
<4>EFLAGS: 00010203
<4>eax: 00000000 ebx: c02b60a0 ecx: c5804000 edx: 00003fdf
<4>esi: 00000005 edi: c10a93d4 ebp: c10a9400 esp: c3e85ca4
<4>ds: 0018 es: 0018 ss: 0018
<4>Process xfs (pid: 744, stackpage=c3e85000)
<4>Stack: c10a93d4 c012aa80 c02b60a0 c02b60a0 c02b60a0 c012b11f c10a93d4 00000500
<4> 00009000 00004000 c011f8b9 00000500 00000004 c41b322c 00000000 40090000
<4> c3e97400 40087000 00000000 40090000 c3e97400 00000001 c01a0db4 c02c1f14
<4>Call Trace: [delete_from_swap_cache+64/80] [free_swap_and_cache+111/160] [zap_page_range+409/640] [poke_blanked_console+100/112] [fput+198/240]
<4> [exit_mmap+177/288] [call_console_drivers+224/240] [mmput+81/112] [do_exit+143/544] [bust_spinlocks+62/80] [die+77/112]
<4> [do_page_fault+919/1227] [sock_def_readable+34/80] [unix_dgram_sendmsg+804/896] [vsnprintf+681/1088] [do_page_fault+0/1227] [error_code+52/64]
<4> [do_swap_page+134/256] [handle_mm_fault+107/192] [handle_signal+125/256] [do_page_fault+390/1227] [do_sigaction+197/256] [sys_rt_sigaction+153/240]
<4> [sys_socketcall+289/528] [do_page_fault+0/1227] [error_code+52/64]
<4>
<4>Code: Bad EIP value.
<4> <1>Unable to handle kernel paging request at virtual address 00001600
<4> printing eip:
<4>00001600
<1>*pde = 00000000
<4>Oops: 0000
<4>CPU: 0
<4>EIP: 0010:[<00001600>] Not tainted
<4>EFLAGS: 00010202
<4>eax: 00000001 ebx: c02b60a0 ecx: c5804000 edx: 00000016
<4>esi: 00000016 edi: c42934c8 ebp: c11307a0 esp: c40c5e9c
<4>ds: 0018 es: 0018 ss: 0018
<4>Process gpm (pid: 571, stackpage=c40c5000)
<4>Stack: c10b3220 c0120836 c02b60a0 00000001 401325e8 00000000 c11307a0 c4e35980
<4> c0120c2b c11307a0 c4e35980 401325e8 c42934c8 00001600 00000000 c1162040
<4> c10d9314 000008c0 000008e0 c1162040 c10d9314 00000000 c10d9314 c11307a0
<4>Call Trace: [do_swap_page+134/256] [handle_mm_fault+107/192] [do_page_fault+390/1227] [ext2_delete_entry+387/400] [ext2_unlink+73/96]
<4> [vfs_unlink+285/336] [path_release+16/48] [sys_unlink+186/240] [do_page_fault+0/1227] [error_code+52/64]
<4>
<4>Code: Bad EIP value.
<4> <1>Unable to handle kernel paging request at virtual address 00001500
<4> printing eip:
<4>00001500
<1>*pde = 00000000
<4>Oops: 0000
<4>CPU: 0
<4>EIP: 0010:[<00001500>] Not tainted
<4>EFLAGS: 00010213
<4>eax: 00000000 ebx: c02b60a0 ecx: c5804000 edx: 00003fe0
<4>esi: 00000015 edi: c10b32a4 ebp: 4012f000 esp: c40c5ca4
<4>ds: 0018 es: 0018 ss: 0018
<4>Process gpm (pid: 571, stackpage=c40c5000)
<4>Stack: c10b32a4 c012aa80 c02b60a0 c02b60a0 c02b60a0 c012b11f c10b32a4 00001500
<4> 00006000 00000000 c011f8b9 00001500 00000000 c42934bc 00000000 40135000
<4> c40c6400 4012f000 00000000 40135000 c40c6400 00000001 c01a0db4 c02c1f14
<4>Call Trace: [delete_from_swap_cache+64/80] [free_swap_and_cache+111/160] [zap_page_range+409/640] [poke_blanked_console+100/112] [fput+198/240]
<4> [exit_mmap+177/288] [call_console_drivers+224/240] [mmput+81/112] [do_exit+143/544] [bust_spinlocks+62/80] [die+77/112]
<4> [do_page_fault+919/1227] [ext2_add_link+762/784] [do_page_fault+0/1227] [error_code+52/64] [do_swap_page+134/256] [handle_mm_fault+107/192]
<4> [do_page_fault+390/1227] [ext2_delete_entry+387/400] [ext2_unlink+73/96] [vfs_unlink+285/336] [path_release+16/48] [sys_unlink+186/240]
<4> [do_page_fault+0/1227] [error_code+52/64]
<4>
<4>Code: Bad EIP value.
<4> <1>Unable to handle kernel paging request at virtual address 00001a00
<4> printing eip:
<4>00001a00
<1>*pde = 00000000
<4>Oops: 0000
<4>CPU: 0
<4>EIP: 0010:[<00001a00>] Not tainted
<4>EFLAGS: 00010202
<4>eax: 00000001 ebx: c02b60a0 ecx: c5804000 edx: 0000001a
<4>esi: 0000001a edi: c42ea2dc ebp: c1130720 esp: c4155e9c
<4>ds: 0018 es: 0018 ss: 0018
<4>Process sendmail (pid: 555, stackpage=c4155000)
<4>Stack: c10b3640 c0120836 c02b60a0 00000001 080b7d7c 00000000 c1130720 c426a1e0
<4> c0120c2b c1130720 c426a1e0 080b7d7c c42ea2dc 00001a00 00000000 0000000f
<4> c4154560 c4530bbc c4530bbc c4155f30 c01069ed 0000000f c4530bbc c1130720
<4>Call Trace: [do_swap_page+134/256] [handle_mm_fault+107/192] [handle_signal+125/256] [do_page_fault+390/1227] [do_getitimer+152/160]
<4> [do_setitimer+115/240] [sys_alarm+50/80] [do_page_fault+0/1227] [error_code+52/64]
<4>
<4>Code: Bad EIP value.
<4> <1>Unable to handle kernel paging request at virtual address 00001900
<4> printing eip:
<4>00001900
<1>*pde = 00000000
<4>Oops: 0000
<4>CPU: 0
<4>EIP: 0010:[<00001900>] Not tainted
<4>EFLAGS: 00010207
<4>eax: 00000000 ebx: c02b60a0 ecx: c5804000 edx: 00003fe1
<4>esi: 00000019 edi: c10b5218 ebp: 080a7000 esp: c4155ca4
<4>ds: 0018 es: 0018 ss: 0018
<4>Process sendmail (pid: 555, stackpage=c4155000)
<4>Stack: c10b5218 c012aa80 c02b60a0 c02b60a0 c02b60a0 c012b11f c10b5218 00001900
<4> 00004000 00000000 c011f8b9 00001900 00000000 c42ea29c 00000000 080ab000
<4> c4156080 080a7000 00000000 080ab000 c4156080 00000001 c01a0db4 c02c1f14
<4>Call Trace: [delete_from_swap_cache+64/80] [free_swap_and_cache+111/160] [zap_page_range+409/640] [poke_blanked_console+100/112] [vt_console_print+766/784]
<4> [exit_mmap+177/288] [call_console_drivers+224/240] [mmput+81/112] [do_exit+143/544] [bust_spinlocks+62/80] [die+77/112]
<4> [do_page_fault+919/1227] [do_no_page+53/464] [handle_mm_fault+88/192] [do_page_fault+0/1227] [error_code+52/64] [do_swap_page+134/256]
<4> [handle_mm_fault+107/192] [handle_signal+125/256] [do_page_fault+390/1227] [do_getitimer+152/160] [do_setitimer+115/240] [sys_alarm+50/80]
<4> [do_page_fault+0/1227] [error_code+52/64]
<4>
<4>Code: Bad EIP value.
Kernel logging (proc) stopped.
Kernel log daemon terminating.
^ permalink raw reply
* Re: Using iptables for bandwidth mesurement
From: Joel Newkirk @ 2003-01-08 9:03 UTC (permalink / raw)
To: marco_simon, netfilter
In-Reply-To: <ID0NVT4YQPJ4WB6TSIMGSLF8632.3e195dc8@europe>
On Monday 06 January 2003 05:43 am, Marco Simon wrote:
> Hello netfilter-group,
>
> we are using iptables on our gateway-server for doing NAT and
> package-filtering.
>
> Actually one of our hosting-customers wants to be informed how much
> off of our bandwidth to the internet (1.5 MBit maximum) is used, in
> order to avoid that some of his "homepage - guests" are not able
> visite his site due lack of bandwidth. Is there any way, how I can use
> IPtables for giving him a report about the bandwith usage ? e.g. how
> can I get the current bandwidth - usage on a special interface ?
>
> The other point we need, is an report about the traffic which comes up
> between our cusomers web-server (which is inside our lan, packages
> will have to pass the firewall) and the outside-world. How can I set
> up such a service using iptalbes ??
>
> Thanks for any comment !
Look into software packages that are addressed through the ULOG target to
perform detailed accounting of traffic. There are several available,
IIRC, which can sift, sort, and map the data collected on all the
traffic through the firewall, so long as you set an appropriate "-j
ULOG" rule.
A quick and dirty answer to part two is to use "iptables -L -v -n" and a
rule at the start of your FORWARD chain which does nothing but match ALL
traffic outbound from that customer's server, but has no target. The
rule will then count packets and bytes but not actually DO anything.
This is NOT a good solution, but you can use it for rough numbers over a
short period. (if the firewall is reset, or the counts reset, then
everything is lost) Just zero the counts, (iptables -Z, or iptables -Z
FORWARD) and after a period of time list the rules with "-v" and check
the packet and byte counts. If you want to try this without zeroing all
counts, just remove and reinsert the rule.
j
^ permalink raw reply
* OT Naming. was: Re: Why is Nvidia given GPL'd code to use in closed source drivers?
From: Nils Petter Vaskinn @ 2003-01-08 9:04 UTC (permalink / raw)
To: rms; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <E18WB8Q-0004k6-00@fencepost.gnu.org>
On Wed, 2003-01-08 at 09:00, Richard Stallman wrote:
> The practice of referring to the whole system by the same name as the
> kernel alone leads to constant confusion between the two. You will
> often see statements that "Linux is a Unix-like operating system, like
> Solaris or FreeBSD, which is released under the GNU GPL." That is
> false regardless of what meaning you assign to "Linux". The only way
> to avoid confusion is to stop calling the whole system by the name
> used for the kernel.
This is what I understand is the COMMON usage:
linux refers to the kernel plus the GNU software, a complete os
linux-kernel refers to the kernel (which is why this is the linux-kernel
mailinglist not the linux mailinglist)
I have not seen the word linux used to describe an os built around the
linux kernel but without the GNU software, it may be referred to as
"linux based" but if they called it linux users wouldn't get what they
expected and complain.
The confusion you describe doesn't appear to exist, and making everybody
start calling the kernel "Linux" and the os "GNU/Linux" will at best
change nothing (practically, of course it may improve some peoples egos)
and possibly cause confusion.
The "GNU/Linux" vs "Linux" argument is a political one, not a practical
one, don't try to disguise it.
regards
NP
^ permalink raw reply
* Re: [2.5.54-dj1-bk] Some interesting experiences...
From: Vojtech Pavlik @ 2003-01-08 8:52 UTC (permalink / raw)
To: Anders Gustafsson; +Cc: Joshua Kwan, linux-kernel, vojtech
In-Reply-To: <20030108015107.GA2170@gagarin>
On Wed, Jan 08, 2003 at 02:51:07AM +0100, Anders Gustafsson wrote:
> On Tue, Jan 07, 2003 at 05:21:46PM -0800, Joshua Kwan wrote:
> >
> > 3. [linux-2.5] PS/2 mouse goes haywire every 30 seconds or so of use.
> > dmesg sayeth:
> > mice: PS/2 mouse device common for all mice
> > input: PS/2 Synaptics TouchPad on isa0060/serio4
> >
> > but more importantly this is the cause:
> >
> > psmouse.c: Lost synchronization, throwing 2 bytes away.
> > psmouse.c: Lost synchronization, throwing 2 bytes away.
>
> This happens here too. But not that frequent at all, more like once every
> hour. And has happend on all kernels since at least 2.5.46 [1].
>
> However 5 hours ago I changed the timeout in psmouse.c from 50ms to 100ms.
> And now it haven't misbehaved yet, but that might be just some nightly luck.
> Is there something that turns off interupts or something and hinders the
> mouse driver from processing the data for such long time? Or is my hardware
> just buggy?
That I'd like to know, too. In the worst case, we can make the timeout
be half a second, or more - it'd just mean that for a resync you would
have to not touch the mouse this long if really a byte is lost.
> [1] http://marc.theaimsgroup.com/?l=linux-kernel&m=103688231622278&w=2
>
> --
> Anders Gustafsson - andersg@0x63.nu - http://0x63.nu/
--
Vojtech Pavlik
SuSE Labs
^ 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.