* disabling module version support
From: ransom . @ 2003-01-08 22:58 UTC (permalink / raw)
To: linux-admin
How does one compile a kernel without version support? [ie- one that won't
complain if a module with a different version number is loaded]
Basically, I want a kernel that allows me to
# insmod ./hello.o
without this:
# insmod hellomodule.o
hellomodule.o: kernel-module version mismatch
hellomodule.o was compiled for kernel version 2.4.18
while this kernel is version 2.4.20.
as described in the first couple of paragraphs in chapter 2 of oreilly's
"Linux device drivers, which can be found here:
http://www.xml.com/ldd/chapter/book/ch02.html
I've tried the following:
# insmod -f hellomodule.o
Warning: kernel-module version mismatch
hellomodule.o was compiled for kernel version 2.4.18
while this kernel is version 2.4.20
Warning: loading hellomodule.o will taint the kernel: no license
See http://www.tux.org/lkml/#export-tainted for information about tainted
modules
Warning: loading hellomodule.o will taint the kernel: forced load
Module hellomodule loaded, with warnings
# rmmod hellomodule
so that's great, EXCEPT I didn't get the messages printed to stdout that I
was supposed to as described in the Linux Device Drivers book
(http://www.xml.com/ldd/chapter/book/ch02.html)
eg-
save
#define MODULE
#include <linux/module.h>
int init_module(void) { printk("<1>Hello, world\n"); return 0; }
void cleanup_module(void) { printk("<1>Goodbye cruel world\n"); }
as hello.c (or whatever name), then
root# gcc -c hello.c
root# insmod ./hello.o
Hello, world
root# rmmod hello
Goodbye cruel world
root#
"Hello, world", as you can see in my ACTUAL output, didn't appear on screen.
Perhaps this is a programming issue? But it seems as though a proper
configuration would allow me to duplicate what's in the book.
Many thanks for you help!
_________________________________________________________________
MSN 8: advanced junk mail protection and 2 months FREE*.
http://join.msn.com/?page=features/junkmail
^ permalink raw reply
* Re: [2.5.54][PATCH] SB16 convertation to new PnP layer.
From: Ruslan U. Zakirov @ 2003-01-08 23:06 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: linux-kernel, ambx1
In-Reply-To: <Pine.LNX.4.50.0301081350440.2130-100000@montezuma.mastecende.com>
On Wed, 8 Jan 2003, Zwane Mwaikambo wrote:
> 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
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
It's SBAWE32. It's EMU8000.
Ruslan.
^ permalink raw reply
* Re: observations on 2.5 config screens
From: Bill Davidsen @ 2003-01-08 22:49 UTC (permalink / raw)
To: Dave Jones
Cc: Robert Love, Adrian Bunk, Robert P. J. Day,
Linux kernel mailing list
In-Reply-To: <20030108195000.GA670@codemonkey.org.uk>
On Wed, 8 Jan 2003, Dave Jones wrote:
> On Wed, Jan 08, 2003 at 01:36:06PM -0500, Bill Davidsen wrote:
>
> > 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.
>
> No-one other than kernel hackers should be playing with that option,
> hence it's in the kernel hacking menu.
Anyone who wants to be able to debug a problem should be playing with
that, it's one thing which affects the whole kernel, and is't really a
hack in the usualy sense. And sysctl isn't really a hack, it's just
another feature (my opinion).
> > Processor option would select the processor and any architecture dependent
> > options, I would think. Something like "kernel characteristics" could have
> > options like smp.
>
> SMP isn't a processor option ?
Clearly not, it's not processor dependent or even architecture dependent
generally. It's a characteristic of the os, unlike microcode, mtrr, and
other stuff not on some architectures. You can select it for 386/486/P5
(and it works in 2.4 at least, for P5, have several).
I would think that processor options would select the processor and any
options which are specific to it rather than generally supported. Serial
numbers, firmware loads, that sort of feature.
Preempt and smp, are general, I guess not supported on every possible
hardware, but certainly not restricted to a single model or family.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* Re: [PATCH] /proc/sys/kernel/pointer_size
From: Linus Torvalds @ 2003-01-08 23:04 UTC (permalink / raw)
To: David S. Miller; +Cc: levon, linux-kernel
In-Reply-To: <20030108.143441.31155028.davem@redhat.com>
On Wed, 8 Jan 2003, David S. Miller wrote:
>
> Being that 32-bit is the primary (and in many ways, ONLY) userland for
> at least 2 64-bit kernel platforms, I think this does matter.
Nope.
System binaries match the kernel. It's as easy as that. So what if 90% of
the user binaries use 32-bit mode because it's smaller and faster? We're
talking about a system binary that is _very_ intimate with the kernel.
Just make it a compile-time option and be done with it.
Linus
^ permalink raw reply
* Re: File perforation.
From: Eli Carter @ 2003-01-08 22:56 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-fsdevel
In-Reply-To: <22288.1042065284@passion.cambridge.redhat.com>
David Woodhouse wrote:
> eli.carter@inet.com said:
>
>> Could you elaborate on the difference between what you want to do and
>> sparse files?
>
>
>
> No difference. Given a non-sparse file, I want a way to make it sparse.
>
> Well, I _have_ a way to make it sparse; all I have to do is write out a
> single log entry. What I am lacking is a way for the user to tell me to do
> so :)
>
> I'm aware that you can do this by deleting the file and writing out a new
> copy. But this is flash and it has a limited number of write cycles; I don't
> want to do that.
(No answers, just questions... ;) )
On a compressed fs like jffs2, wouldn't a block of 0's compress down to
next-to-nothing already?
Can the fs recognize a big block of 0's and make it sparse on-the-fly
without needing the user to specify it? (On block-based fs's, that
might not always be desirable due to out-of-space errors on modifying a
file, but for a compressed fs, that's not a new issue.)
(Hmm.... If I'm missing something obvious, clue-by-four me and I'll go
away. ;) )
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ permalink raw reply
* Re: Newbie - Where is my kernel? Can't run POM
From: Arnt Karlsen @ 2003-01-08 22:56 UTC (permalink / raw)
To: netfilter
In-Reply-To: <20030108181810.GD21359@miggy.org>
On Wed, 8 Jan 2003 18:18:10 +0000,
Athan <netfilter@miggy.org> wrote in message
<20030108181810.GD21359@miggy.org>:
> On Wed, Jan 08, 2003 at 11:53:38AM -0600, Timothy Harryman wrote:
> > 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.
>
> RH is almost certainly using seperate runtime and source packages
> for
> the kernel. Looking at http://www.rpmfind.net/ I see things like:
>
> kernel-2.4.20-2.6.i686.rpm
> kernel-2.4.20-2.6.src.rpm
..??? Url?
>
> The first being the compiled kernel and modules, the latter the source
> for it. So go find kernel-2.4.18-19.8.0.src.rpm, or even better
> upgrade packages to a 2.4.20 kernel the current latest stable release.
..2.4.18-19.8.0 is RH's upgraded kernel for RH-8.0, and 2.4.18-19.7.x
for RH-7.3 et al. 2.4.20-2.2 is "RawHide 1.0 Source" which is
RH-talk for development stuff. Read the specfile to see how RH
builds their kernels.
--
..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
* Re: File perforation.
From: Matthew Wilcox @ 2003-01-08 22:55 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-fsdevel
In-Reply-To: <21551.1042063560@passion.cambridge.redhat.com>
On Wed, Jan 08, 2003 at 10:06:00PM +0000, David Woodhouse wrote:
> I've been resisting these requests because I really don't want to do it
> with an ioctl on the file. Only if we can have a generic sys_perforate()
> would I really want to do it.
SGI have an fcntl to do this:
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/p_man/cat2/standard/fcntl.z
F_FREESP
However, I think this is probably the ugliest method available to perform
this function.
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
^ permalink raw reply
* Re: Undelete files on ext3 ??
From: John Bradford @ 2003-01-08 23:03 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: rddunlap, linux-kernel
In-Reply-To: <200301082206.h08M6pRA014912@turing-police.cc.vt.edu>
> > | > > What I was thinking of was a virtual device that allocated a new
> > | > > sector whenever an old one was overwritten - kind of like a journaled
> > | > > filesystem, but without the filesystem, (I.E. just the journal) :-).
> > | >
> > | > $ DIR FOO.TXT;*
> > | > FOO.TXT;1 FOO.TXT;2 FOO.TXT;2
> > | >
> > | > VMS-style file versioning, anybody? ;)
> > |
> > | Brilliant!
> >
> > re-read the archives from 6-8 months ago.
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=101914252421742&w=2
So basically the idea already already exists:
http://www.netcraft.com.au/geoffrey/katie/
Brilliant! :-)
John.
^ permalink raw reply
* Re: [RFC] Change signal used to exit scsi error handlers
From: Willem Riede @ 2003-01-08 22:53 UTC (permalink / raw)
To: linux-scsi; +Cc: andmike
In-Reply-To: <20030101210555.GS1378@linnie.riede.org>
On 2003.01.01 16:05 Willem Riede wrote:
> I earlier reported, that the error handler for ide-scsi exits prematurely if modprobed
> from rc.sysinit. I put in some debug prints to apprehend the culprit responsible for
> sending the SIGHUP signal that causes the exit.
>
[snip]
>
> Since we want error handlers to survive, IMHO that means that the choice of signal
> for error handler exit is unfortunate. The source of scsi_error suggests SIGPWR
> might be a worthy alternative. I think that is true. From inspecting init source,
> it is not capable of sending SIGPWR. SIGPWR should never be sent by dying processes
> (its sole use should be from a power daemon _to_ init to shut the system down when
> the juice is running out).
>
So nobody has any comments? But who decides whether to make this change?
>From the source it appears that the last person to touch scsi_error.c and hosts.c
is Mike Anderson. Does that make you the defacto maintainer, Mike?
Thanks, Willem Riede.
^ permalink raw reply
* RE: Gigabit/SMP performance problem
From: Ronciak, John @ 2003-01-08 21:44 UTC (permalink / raw)
To: 'Robert Olsson', Avery Fay; +Cc: Anton Blanchard, linux-kernel
All,
We (Intel - LAN Access Division, e1000 driver) are taking a look at what is
going on here. We don't have any data yet but we'll keep you posted on what
we find.
Thanks for your patients.
Cheers,
John
> -----Original Message-----
> From: Robert Olsson [mailto:Robert.Olsson@data.slu.se]
> Sent: Tuesday, January 07, 2003 10:16 AM
> To: Avery Fay
> Cc: Anton Blanchard; linux-kernel@vger.kernel.org
> Subject: Re: Gigabit/SMP performance problem
>
>
>
> Avery Fay writes:
> > Hmm. That paper is actually very interesting. I'm thinking
> maybe with the
> > P4 I'm better off with only 1 cpu. WRT hyperthreading, I
> actually disabled > it because it make performance worse
> (wasn't clear in the original email).
>
>
> With 1CPU-SMP-HT I'm on UP level of performance this with
> forwarding two
> single flows evenly distributes between CPU's. So HT payed
> the SMP cost so
> to say.
>
> Also I tested the MB bandwidth with new threaded version of
> pktgen just
> TX'ing a packets on 6 GIGE I'm seeing almost 6 Gbit/s TX'ed
> w 1500 bytes
> packets.
>
> I have problem populating all slots w. GIGE NIC's. WoL (Wake
> on Lan) this
> is a real pain... Seems like my adapters needs a standby
> current 0.8A and
> most Power Supplies gives 2.0A for this. (Number come from
> SuperMicro).
> So booting fails radomlingy. You have 8 NIC's -- Didn't you
> have problem?
>
> Anyway I'll guess profiling is needed?
>
> Cheers.
> --ro
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH]: Remove PF_MEMDIE as it is redundant
From: Robert Love @ 2003-01-08 23:00 UTC (permalink / raw)
To: Juan Quintela; +Cc: Marcelo Tosatti, Andrea Arcangeli, lkml
In-Reply-To: <m2r8bn6yxz.fsf@demo.mitica>
On Wed, 2003-01-08 at 17:47, Juan Quintela wrote:
> PF_MEMDIE don't have any use in current kernels. Please
> remove, we only set it in one place, and there we also set
> PF_MEMALLOC. And we only test it in other place, and we also
> test for PF_MEMALLOC. This patch has existed in aa for some
> quite time.
I independently thought this same thing, and did a patch for 2.5 which
had the same effect.
I was reminded by better-VM-hackers-than-I that PF_MEMALLOC can be
cleared in various paths so the PF_MEMDIE is required to ensure that the
check in page_alloc.c is always true for OOM'ed tasks.
Robert Love
^ permalink raw reply
* Re: [PATCH] mm/slab.c, kernel <2.4.20>
From: Shangc @ 2003-01-08 22:58 UTC (permalink / raw)
To: Marc-Christian Petersen, linux-kernel; +Cc: markhe, Shangc
In-Reply-To: <200301082312.32961.m.c.p@wolk-project.de>
thank you for reply. However, I am not very sure to be
vary agree with you.
after assigned the calculated initial value for "i",
it is very close to the break value for the next while
loop, actually, it is only one loop at most, so "i"
never goes to be
i*size + L1_CACHE_ALIGN(base+i*extra) > wastage +
L1_CACHE_BYTES
so, we do not need change the line 399 of slab.c.
thanks,
chen
--- Marc-Christian Petersen <m.c.p@wolk-project.de>
wrote:
> On Wednesday 08 January 2003 23:03, Shangc wrote:
>
> Hi Shangc,
>
> > --- slab.c 2003-02-08 04:26:50.000000000 -0500
> > +++ slab.c 2003-02-08 04:26:14.000000000 -0500
> > @@ -397,7 +397,7 @@
> > base = sizeof(slab_t);
> > extra = sizeof(kmem_bufctl_t);
> > }
> > - i = 0;
> > + i = (wastage - base) / (size + extra);
> > while (i*size + L1_CACHE_ALIGN(base+i*extra) <=>
> wastage)
> > i++;
> > if (i > 0)
> if you use this you may also want this.
>
> ciao, Marc> diff -Naurp a/mm/slab.c b/mm/slab.c
> --- a/mm/slab.c Wed Jul 17 12:25:04 2002
> +++ b/mm/slab.c Wed Jul 17 12:25:04 2002
> @@ -399,10 +399,10 @@
> base = sizeof(slab_t);
> extra = sizeof(kmem_bufctl_t);
> }
> - i = 0;
> + i = (wastage - base)/(size + extra);
> while (i*size + L1_CACHE_ALIGN(base+i*extra) <=
> wastage)
> i++;
> - if (i > 0)
> + while (i*size + L1_CACHE_ALIGN(base+i*extra)
> > wastage)
> i--;
>
> if (i > SLAB_LIMIT)
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
^ permalink raw reply
* Re: SCTP path mtu support needs some ip layer support.
From: Jon Grimm @ 2003-01-08 22:48 UTC (permalink / raw)
To: David S. Miller; +Cc: sri, kuznet, netdev
In-Reply-To: <20030108.150638.09647984.davem@redhat.com>
"David S. Miller" wrote:
>
> From: Sridhar Samudrala <sri@us.ibm.com>
> Date: Wed, 8 Jan 2003 15:04:53 -0800 (PST)
>
> 1. Add a new argument to ip_queue_xmit() to pass the value of DF bit.
> 2. Use the __unused field in skb to pass the value of DF bit.
> 3. Let SCTP call its own routine that fills in the ip header with the
> appropriate value in the DF bit, but this duplicates most of the code
> in ip_queue_xmit(). Also ip_options_build() needs to be exported.
>
> Which option do you prefer? Or can you suggest any better alternative?
>
> Too bad there's not a 4th option, fix SCTP. This is really broken
> that the data stream can get into a state where resegmentation cannot
> be performed.
>
> Sigh... I guess the new argument to ip_queue_xmit() is the least
> intrusive.
I hate to mention it, but there is at least one other alternative (to
complete the picture) that is to chunk up the messages into their
smallest fragment and then bundle these chunks up to the MTU allowable
packet.
This however does each up space in the packet for each chunk header and
require more processing at the other end to reassemble the records.
IIRC, this is what OpenSS7s SCTP does, while the KAME SCTP manually
controls the DF bit as per Sridhar's suggestion. There are tradeoffs
in either approach.
Best Regards,
Jon
^ permalink raw reply
* Re: File perforation.
From: Dave Kleikamp @ 2003-01-08 22:45 UTC (permalink / raw)
To: David Woodhouse, linux-fsdevel
In-Reply-To: <21551.1042063560@passion.cambridge.redhat.com>
On Wednesday 08 January 2003 16:06, David Woodhouse wrote:
> I've been resisting these requests because I really don't want to do
> it with an ioctl on the file. Only if we can have a generic
> sys_perforate() would I really want to do it.
I have heard requests for the same thing. I would not be opposed to the
new system call.
> Apparently it's hard to implement on block-based file systems. I
> don't really care about that though -- just falling back to writing
> zeroes to the offending range (or indeed returning -EINVAL) would be
> perfectly sufficient until/unless it gets implemented for other file
> systems. All I want is an interface that doesn't make me feel dirty
> :)
I don't think that it would be terribly hard to implement for
block-based fs's. It's basically a more general form of truncate. Of
course, I'm not saying it would be trivial. Experience says that
anything dealing with truncate is full of gotchas and corner cases.
> Comments?
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
* Re: [RFC][PATCH] allow bigger PAGE_OFFSET with PAE
From: William Lee Irwin III @ 2003-01-08 22:44 UTC (permalink / raw)
To: Dave Hansen, Linux Kernel Mailing List, linux-mm
In-Reply-To: <20030108220533.GD23814@holomorphy.com>
On Tue, Jan 07, 2003 at 12:06:38PM -0800, Dave Hansen wrote:
>>>> Also, this gets the kernel's pagetables right, but neglects
>>>> userspace's for now. pgd_alloc() needs to be fixed to allocate
>>>> another PMD, if the split isn't PMD-alighed.
William Lee Irwin III wrote:
>>> Um, that should be automatic when USER_PTRS_PER_PGD is increased.
On Wed, Jan 08, 2003 at 01:04:23PM -0800, Dave Hansen wrote:
>> Nope, you need a little bit more. pgd_alloc() relies on its memcpy()
>> to provide the kernel mappings. After the last user PMD is allocated,
>> you still need to copy the kernel-shared part of it in.
On Wed, Jan 08, 2003 at 02:05:33PM -0800, William Lee Irwin III wrote:
> See the bit about rounding up. Then again, the pmd entries don't get
> filled in by any of that...
Okay, basically:
#define __USER_PTRS_PER_PGD (TASK_SIZE/PGDIR_SIZE)
#define PARTIAL_PGD (TASK_SIZE > __USER_PTRS_PER_PGD*PGDIR_SIZE ? 1 : 0)
#define PARTIAL_PMD ((TASK_SIZE % PGDIR_SIZE)/PMD_SIZE)
#define USER_PTRS_PER_PGD (PARTIAL_PGD + __USER_PTRS_PER_PGD)
then
pgd_t *pgd_alloc(struct mm_struct *mm)
{
int i;
pgd_t *pgd = kmem_cache_alloc(pae_pgd_cachep, GFP_KERNEL);
if (pgd) {
for (i = 0; i < USER_PTRS_PER_PGD; i++) {
unsigned long pmd = __get_free_page(GFP_KERNEL);
if (!pmd)
goto out_oom;
clear_page(pmd);
set_pgd(pgd + i, __pgd(1 + __pa(pmd)));
}
if (USER_PTRS_PER_PGD < PTRS_PER_PGD)
memcpy(pgd + USER_PTRS_PER_PGD,
swapper_pg_dir + USER_PTRS_PER_PGD,
(PTRS_PER_PGD-USER_PTRS_PER_PGD)*sizeof(pgd_t));
if (PARTIAL_PGD) {
pgd_t *kpgd, *upgd;
pmd_t *kpmd, *upmd;
kpgd = pgd_offset_k(TASK_SIZE);
upgd = pgd_offset(mm, TASK_SIZE);
kpmd = pmd_offset(kpgd, TASK_SIZE);
upmd = pmd_offset(upgd, TASK_SIZE);
memcpy(upmd, kpmd, (PTRS_PER_PMD-PARTIAL_PMD)*sizeof(pmd_t));
}
}
return pgd;
out_oom:
for (i--; i >= 0; i--)
free_page((unsigned long)__va(pgd_val(pgd[i])-1));
kmem_cache_free(pae_pgd_cachep, pgd);
return NULL;
}
etc.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: Newbie - Where is my kernel? Can't run POM
From: Arnt Karlsen @ 2003-01-08 22:38 UTC (permalink / raw)
To: netfilter
In-Reply-To: <001301c2b754$59f77280$6601a8c0@s3ac>
On Wed, 08 Jan 2003 12:27:22 -0800,
Rowan Reid <rreid@studio3arc.com> wrote in message
<001301c2b754$59f77280$6601a8c0@s3ac>:
>
> >
> > ..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.
>
> If this is a new kernel don_t forget to do a dry run and compile the
> kernel prior to running pom
>
..my "try" line installs RH's kernel source tree.
I just run pom over it and then compile.
(However, kernelmod-0.6.tar.gz'ing from
http://sourceforge.net/project/showfiles.php?group_id=44827
needs a built and installed kernel _and_ the tree.)
--
..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
* Re: [PATCH] /proc/sys/kernel/pointer_size
From: David S. Miller @ 2003-01-08 22:37 UTC (permalink / raw)
To: torvalds; +Cc: levon, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301081300200.1497-100000@home.transmeta.com>
From: Linus Torvalds <torvalds@transmeta.com>
Date: Wed, 8 Jan 2003 13:03:14 -0800 (PST)
On Wed, 8 Jan 2003, John Levon wrote:
> What other ways ? Dave M reasonably argued it wasn't part of the
> architecture's ABI, so did not have a place in the headers.
You should certainly see it in "uname -a" output, for example.
Doesn't tell you the kernel pointer size. We fake the uname
output when a process runs as PERS_LINUX_32BIT which is what
we use to trick 'configure' and other build programs in order to
build 32-bit apps properly.
Compile oprofile for the proper architecture if you do it yourself, and
complain to the vendor if the vendor is stupid enough to supply a 32-bit
oprofile with a 64-bit kernel.
There is _no_ excuse to bloat the kernel for user mistakes.
There simply is no fully usable 64-bit userland on some of these
platforms.
^ permalink raw reply
* Re: [RFC][PATCH] allow bigger PAGE_OFFSET with PAE
From: William Lee Irwin III @ 2003-01-08 22:44 UTC (permalink / raw)
To: Dave Hansen, Linux Kernel Mailing List, linux-mm
In-Reply-To: <20030108220533.GD23814@holomorphy.com>
On Tue, Jan 07, 2003 at 12:06:38PM -0800, Dave Hansen wrote:
>>>> Also, this gets the kernel's pagetables right, but neglects
>>>> userspace's for now. pgd_alloc() needs to be fixed to allocate
>>>> another PMD, if the split isn't PMD-alighed.
William Lee Irwin III wrote:
>>> Um, that should be automatic when USER_PTRS_PER_PGD is increased.
On Wed, Jan 08, 2003 at 01:04:23PM -0800, Dave Hansen wrote:
>> Nope, you need a little bit more. pgd_alloc() relies on its memcpy()
>> to provide the kernel mappings. After the last user PMD is allocated,
>> you still need to copy the kernel-shared part of it in.
On Wed, Jan 08, 2003 at 02:05:33PM -0800, William Lee Irwin III wrote:
> See the bit about rounding up. Then again, the pmd entries don't get
> filled in by any of that...
Okay, basically:
#define __USER_PTRS_PER_PGD (TASK_SIZE/PGDIR_SIZE)
#define PARTIAL_PGD (TASK_SIZE > __USER_PTRS_PER_PGD*PGDIR_SIZE ? 1 : 0)
#define PARTIAL_PMD ((TASK_SIZE % PGDIR_SIZE)/PMD_SIZE)
#define USER_PTRS_PER_PGD (PARTIAL_PGD + __USER_PTRS_PER_PGD)
then
pgd_t *pgd_alloc(struct mm_struct *mm)
{
int i;
pgd_t *pgd = kmem_cache_alloc(pae_pgd_cachep, GFP_KERNEL);
if (pgd) {
for (i = 0; i < USER_PTRS_PER_PGD; i++) {
unsigned long pmd = __get_free_page(GFP_KERNEL);
if (!pmd)
goto out_oom;
clear_page(pmd);
set_pgd(pgd + i, __pgd(1 + __pa(pmd)));
}
if (USER_PTRS_PER_PGD < PTRS_PER_PGD)
memcpy(pgd + USER_PTRS_PER_PGD,
swapper_pg_dir + USER_PTRS_PER_PGD,
(PTRS_PER_PGD-USER_PTRS_PER_PGD)*sizeof(pgd_t));
if (PARTIAL_PGD) {
pgd_t *kpgd, *upgd;
pmd_t *kpmd, *upmd;
kpgd = pgd_offset_k(TASK_SIZE);
upgd = pgd_offset(mm, TASK_SIZE);
kpmd = pmd_offset(kpgd, TASK_SIZE);
upmd = pmd_offset(upgd, TASK_SIZE);
memcpy(upmd, kpmd, (PTRS_PER_PMD-PARTIAL_PMD)*sizeof(pmd_t));
}
}
return pgd;
out_oom:
for (i--; i >= 0; i--)
free_page((unsigned long)__va(pgd_val(pgd[i])-1));
kmem_cache_free(pae_pgd_cachep, pgd);
return NULL;
}
etc.
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Wichert Akkerman @ 2003-01-08 22:43 UTC (permalink / raw)
To: Andrew McGregor; +Cc: Fabio Massimo Di Nitto, netdev, linux-kernel
In-Reply-To: <78180000.1042055993@localhost.localdomain>
Previously Andrew McGregor wrote:
> Probably on the server's side it got an ICMP Host Unreachable or two as
> some router updated its tables, and decided to close the connection.
The fact that this problem does not seem to occur when using a window
XP client seems to contradict the suggestions that it may be a router
problem.
Wichert.
--
Wichert Akkerman <wichert@wiggy.net> http://www.wiggy.net/
A random hacker
^ permalink raw reply
* Re: File perforation.
From: David Woodhouse @ 2003-01-08 22:34 UTC (permalink / raw)
To: Eli Carter; +Cc: linux-fsdevel
In-Reply-To: <3E1CA628.7000002@inet.com>
eli.carter@inet.com said:
> Could you elaborate on the difference between what you want to do and
> sparse files?
No difference. Given a non-sparse file, I want a way to make it sparse.
Well, I _have_ a way to make it sparse; all I have to do is write out a
single log entry. What I am lacking is a way for the user to tell me to do
so :)
I'm aware that you can do this by deleting the file and writing out a new
copy. But this is flash and it has a limited number of write cycles; I don't
want to do that.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] /proc/sys/kernel/pointer_size
From: David S. Miller @ 2003-01-08 22:34 UTC (permalink / raw)
To: torvalds; +Cc: levon, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301081222430.5369-100000@home.transmeta.com>
From: Linus Torvalds <torvalds@transmeta.com>
Date: Wed, 8 Jan 2003 12:28:23 -0800 (PST)
Don't add stupid bloat to the kernel because somebody is silly
enough to care about a 32-bit oprofile working with a 64-bit kernel.
Being that 32-bit is the primary (and in many ways, ONLY) userland for
at least 2 64-bit kernel platforms, I think this does matter.
We're exporting an int to userland, what kind of bloat is that really?
^ permalink raw reply
* Re: [PATCH] /proc/sys/kernel/pointer_size
From: John Levon @ 2003-01-08 22:40 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301081300200.1497-100000@home.transmeta.com>
On Wed, Jan 08, 2003 at 01:03:14PM -0800, Linus Torvalds wrote:
> You should certainly see it in "uname -a" output, for example.
Hrmph. Actually we can take it from the ELF headers of the vmlinux file
that gets passed in I suppose. Along with a uname hack for when there's
no vmlinux available...
> The same is true of kernel modules - 32-bit kernel modules do not work at
> all when the kernel is 64-bit.
Modules aren't in userspace.
> Compile oprofile for the proper architecture if you do it yourself, and
> complain to the vendor if the vendor is stupid enough to supply a 32-bit
> oprofile with a 64-bit kernel.
I don't see what's stupid about a 32-bit binary on a system where all of
user-space is 32-bit. But it doesn't matter.
regards
john
--
"CUT IT OUT FACEHEAD"
- jeffk
^ permalink raw reply
* [PATCH]: Remove PF_MEMDIE as it is redundant
From: Juan Quintela @ 2003-01-08 22:47 UTC (permalink / raw)
To: Marcelo Tosatti, Andrea Arcangeli, lkml
Hi
PF_MEMDIE don't have any use in current kernels. Please
remove, we only set it in one place, and there we also set
PF_MEMALLOC. And we only test it in other place, and we also
test for PF_MEMALLOC. This patch has existed in aa for some
quite time.
Please apply.
Later, Juan.
diff -urNp ref/include/linux/sched.h 2.4.20pre5aa1/include/linux/sched.h
--- ref/include/linux/sched.h Fri Aug 30 01:55:20 2002
+++ 2.4.20pre5aa1/include/linux/sched.h Fri Aug 30 01:55:22 2002
@@ -481,7 +481,6 @@ struct task_struct {
#define PF_DUMPCORE 0x00000200 /* dumped core */
#define PF_SIGNALED 0x00000400 /* killed by a signal */
#define PF_MEMALLOC 0x00000800 /* Allocating memory */
-#define PF_MEMDIE 0x00001000 /* Killed for out-of-memory */
#define PF_FREE_PAGES 0x00002000 /* per process page freeing */
#define PF_NOIO 0x00004000 /* avoid generating further I/O */
diff -urNp ref/mm/oom_kill.c 2.4.20pre5aa1/mm/oom_kill.c
--- t3/mm/oom_kill.c.cc13-2.orig 2002-10-25 12:53:02.000000000 +0200
+++ t3/mm/oom_kill.c 2002-10-25 13:09:27.000000000 +0200
@@ -149,7 +149,7 @@ void oom_kill_task(struct task_struct *p
* exit() and clear out its resources quickly...
*/
p->counter = 5 * HZ;
- p->flags |= PF_MEMALLOC | PF_MEMDIE;
+ p->flags |= PF_MEMALLOC;
/* This process has hardware access, be more careful. */
if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO)) {
diff -uNp t1/mm/page_alloc.c.cc13-3.orig t1/mm/page_alloc.c
--- t1/mm/page_alloc.c.cc13-3.orig 2003-01-08 23:32:31.000000000 +0100
+++ t1/mm/page_alloc.c 2003-01-08 23:40:26.000000000 +0100
@@ -351,7 +351,7 @@ struct page * __alloc_pages(unsigned int
/* here we're in the low on memory slow path */
rebalance:
- if (current->flags & (PF_MEMALLOC | PF_MEMDIE)) {
+ if (current->flags & PF_MEMALLOC) {
zone = zonelist->zones;
for (;;) {
zone_t *z = *(zone++);
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: Oops 2.4.20 + ppp + ide-scsi / usb
From: Guennadi Liakhovetski @ 2003-01-08 22:37 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301021137001.10593-100000@poirot.grange>
Forgot to mention - the hardware:
an ASUS (A7VI-VM) mobo with the
VIA ProSavage KM133 (VIA VT8365) North and
VT82C686B South bridges,
Duron 900MHz
hda: Maxtor 2B020H1,
hdb: WDC AC21600H,
hdc: 40X12, (BenQ CD/RW "CRW 4012A")
Adaptec 29160 Ultra160 SCSI adapter
PIONEER Model: DVD-ROM DVD-305 Rev: 1.03
...still hoping for some feedback / encouragement:-) Now that I was trying
to reproduce those Oopses it works rock-stable with the same kernel /
modules:-( whatever I do - ide-scsi read / write with usb-printing and
ppp-transfers, with and without X - conditions that gave me multiple
Oopses when I didn't want them:-) From all the info in these messages, any
idea how to re-trigger them?
Thanks
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: File perforation.
From: Eli Carter @ 2003-01-08 22:28 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-fsdevel
In-Reply-To: <21551.1042063560@passion.cambridge.redhat.com>
David Woodhouse wrote:
> I keep receiving requests from users to allow space saving by making holes
> in files. For people using JFFS2, a compressed file system designed for use
> on fairly small solid state storage devices, this is a fairly reasonable
> request, and it's also fairly simple to implement. It's only the interface
> I'm concerned about.
>
> I've been resisting these requests because I really don't want to do it
> with an ioctl on the file. Only if we can have a generic sys_perforate()
> would I really want to do it.
>
> Apparently it's hard to implement on block-based file systems. I don't
> really care about that though -- just falling back to writing zeroes to the
> offending range (or indeed returning -EINVAL) would be perfectly sufficient
> until/unless it gets implemented for other file systems. All I want is an
> interface that doesn't make me feel dirty :)
>
> Comments?
Could you elaborate on the difference between what you want to do and
sparse files?
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ 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.