On Donnerstag, 14. Februar 2008, Jeff Dike wrote:
> On Thu, Feb 14, 2008 at 12:13:09PM +0100, Ph. Marek wrote:
> > make -C linux-2.6.24.2/ O=output_path/build ARCH=um bzImage
> >
> > make[2]: *** No rule to make target `bzImage'. Stop.
>
> This seems pretty clear, n
Sorry about the noise ...
Going to another machine with a recent gcc, and re-applying the config file
seems to work, I now got a image.
Just have to get it working now ...
Gabriel: I just got it working.
That was a plain 2.6.24.2 untar - but the "make ARCH=um bzImage" seems to make
a mess.
Hello everybody,
On Donnerstag, 14. Februar 2008, Ph. Marek wrote:
> I'm trying to compile an UML binary from 2.6.24.
>
> make ARCH=um O=... bzImage
>
> gives
>
> make -C linux-2.6.24.2/ O=output_path/build ARCH=um bzImage
> make[1]: Entering directory `output_path/l
Hello Jeff,
hello everybody else,
I'm trying to compile an UML binary from 2.6.24.
make ARCH=um O=... bzImage
gives
make -C linux-2.6.24.2/ O=output_path/build ARCH=um bzImage
make[1]: Entering directory `output_path/linux-2.6.24.2'
GEN output_path/build/Makefile
Hello Jeff,
hello everybody else,
I'm trying to compile an UML binary from 2.6.24.
make ARCH=um O=... bzImage
gives
make -C linux-2.6.24.2/ O=output_path/build ARCH=um bzImage
make[1]: Entering directory `output_path/linux-2.6.24.2'
GEN output_path/build/Makefile
Hello everybody,
On Donnerstag, 14. Februar 2008, Ph. Marek wrote:
I'm trying to compile an UML binary from 2.6.24.
make ARCH=um O=... bzImage
gives
make -C linux-2.6.24.2/ O=output_path/build ARCH=um bzImage
make[1]: Entering directory `output_path/linux-2.6.24.2'
GEN
Sorry about the noise ...
Going to another machine with a recent gcc, and re-applying the config file
seems to work, I now got a image.
Just have to get it working now ...
Gabriel: I just got it working.
That was a plain 2.6.24.2 untar - but the make ARCH=um bzImage seems to make
a mess.
On Donnerstag, 14. Februar 2008, Jeff Dike wrote:
On Thu, Feb 14, 2008 at 12:13:09PM +0100, Ph. Marek wrote:
make -C linux-2.6.24.2/ O=output_path/build ARCH=um bzImage
make[2]: *** No rule to make target `bzImage'. Stop.
This seems pretty clear, no?
bzImage is a x86-ism. Just
Hello everybody!
I'd like to mirror write accesses to a block-device to two devices, get all
all *read* accesses from one of these, and if it fails, to fallback to the
other device.
The usage would be to use some kind of NAS box as persistent network block
device, with some other machine
Hello everybody!
I'd like to mirror write accesses to a block-device to two devices, get all
all *read* accesses from one of these, and if it fails, to fallback to the
other device.
The usage would be to use some kind of NAS box as persistent network block
device, with some other machine
Hell Roman!
Thank you for your answer.
On Montag, 7. Januar 2008, Roman Zippel wrote:
> On Thursday 3. January 2008, Ph. Marek wrote:
> > So I took a look at "Help", and saw that blob:
...
> > That is a _bit_ unreadable.
>
> What you see here is the intern
Hell Roman!
Thank you for your answer.
On Montag, 7. Januar 2008, Roman Zippel wrote:
On Thursday 3. January 2008, Ph. Marek wrote:
So I took a look at Help, and saw that blob:
...
That is a _bit_ unreadable.
What you see here is the internal representation of the select expression
Hello everybody!
[[ Please keep me CC'ed. Thank you. ]]
I just tried looking at NF_CONNTRACK_MARK (menuconfig, in 2.6.23.12), and
found it disallowed.
So I took a look at "Help", and saw that blob:
Selected by: NETFILTER_XT_TARGET_CONNMARK && NET && INET && NETFILTER &&
Hello everybody!
[[ Please keep me CC'ed. Thank you. ]]
I just tried looking at NF_CONNTRACK_MARK (menuconfig, in 2.6.23.12), and
found it disallowed.
So I took a look at Help, and saw that blob:
Selected by: NETFILTER_XT_TARGET_CONNMARK NET INET NETFILTER
NETFILTER_XTABLES
Hello everybody,
I've already pondered about a question for some time, and would like to ask
for a better idea here. It's not entirely about the kernel - although that
surely has some impact, too.
I've got some process/daemon, that wants to export information to other
processes. As model for
Hello everybody,
I've already pondered about a question for some time, and would like to ask
for a better idea here. It's not entirely about the kernel - although that
surely has some impact, too.
I've got some process/daemon, that wants to export information to other
processes. As model for
Hello everybody,
is there some way to duplicate a directory somewhere else (like
with "mount --bind"), but having different owner/group/mode bits?
I'd like to mount a directory I have no control over (think NFS, or
floppy, ...) with clearly defined rights - like root:, mode 0550
for all
Hello everybody,
is there some way to duplicate a directory somewhere else (like
with mount --bind), but having different owner/group/mode bits?
I'd like to mount a directory I have no control over (think NFS, or
floppy, ...) with clearly defined rights - like root:some group, mode 0550
for
Hello Randy!
> This doesn't work when there is no include/asm symlink.
Why? I specifically test for that, and tried it on my machine.
What's the bug?
ASMARCH should come out empty, and the ?= and $(or) should take care of
the rest ...
> It also didn't apply cleanly due to tab(s) being converted
Hello Jeff,
> On Wed, Sep 19, 2007 at 06:17:51PM +0200, Philipp Marek wrote:
>> How about that?
>> readlink include/asm
>> returns
>> asm-um
>> in my case, so I only have to strip the "asm-" part ...
>
> It doesn't handle O= directories...
Sorry, I don't understand you. What are "0="
Hello Jeff,
On Wed, Sep 19, 2007 at 06:17:51PM +0200, Philipp Marek wrote:
How about that?
readlink include/asm
returns
asm-um
in my case, so I only have to strip the asm- part ...
It doesn't handle O= directories...
Sorry, I don't understand you. What are 0= directories? Do you
Hello Randy!
This doesn't work when there is no include/asm symlink.
Why? I specifically test for that, and tried it on my machine.
What's the bug?
ASMARCH should come out empty, and the ?= and $(or) should take care of
the rest ...
It also didn't apply cleanly due to tab(s) being converted
Hello everybody,
I found a problem in /proc/self/schedstat: a simple "cat" can give "wrong"
results.
/proc# cat self/schedstat
91117 26027 2
/proc# cat self/schedstat
90691 27872 2
/proc# cat self/schedstat
995483 15675 3
/proc# cat
Hello everybody,
I found a problem in /proc/self/schedstat: a simple cat can give wrong
results.
/proc# cat self/schedstat
91117 26027 2
/proc# cat self/schedstat
90691 27872 2
/proc# cat self/schedstat
995483 15675 3
/proc# cat
On Mittwoch, 8. August 2007, Andi Kleen wrote:
> > Not everyone likes frame buffer
>
> You don't need the frame buffer; cards typically have text mode
> fonts upto 80x50. The node numbers vary, but you can find out yours
> with vga=ask
>
> > but even with it any OOPs in
> > network code which
On Mittwoch, 8. August 2007, Andi Kleen wrote:
Not everyone likes frame buffer
You don't need the frame buffer; cards typically have text mode
fonts upto 80x50. The node numbers vary, but you can find out yours
with vga=ask
but even with it any OOPs in
network code which happens in
On Mittwoch, 1. August 2007, Josef Sipek wrote:
> Alright not the greatest of examples, there is something to be said about
> symmetry, so...let me try again :)
...
> Oops! There's a whiteout in /b that hides the directory in /c -- rename(2)
> shouldn't make directory subtrees disappear.
>
> There
On Dienstag, 31. Juli 2007, Len Brown wrote:
> Please get Linux up and running on the two boxes
> using whatever means are at your disposal
...
> Then open two a bug report for each machine here:
> http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
Done, see
On Dienstag, 31. Juli 2007, Len Brown wrote:
Please get Linux up and running on the two boxes
using whatever means are at your disposal
...
Then open two a bug report for each machine here:
http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI
Done, see
On Mittwoch, 1. August 2007, Josef Sipek wrote:
Alright not the greatest of examples, there is something to be said about
symmetry, so...let me try again :)
...
Oops! There's a whiteout in /b that hides the directory in /c -- rename(2)
shouldn't make directory subtrees disappear.
There are
On Dienstag, 31. Juli 2007, Cal Peake wrote:
> > Whom should I CC for other documentation updates? Is the maintainer
> > the correct person, or are such small fixes "send and forget"?
>
> For spelling and grammar fixes, sending to [EMAIL PROTECTED] is prolly
> the best bet with a CC to l-k.
>
>
On Dienstag, 31. Juli 2007, Gabriel C wrote:
> [ added linux-acpi to CC ]
Sorry, forgot to mention:
I'd like to use 2.6.20.1, but I already tested with 2.6.22.1.
IIUC if there's a problem with the ACPI tables, the blacklist won't help,
because to know whether the ACPI blacklist applies ACPI
Hello everybody!
I have two machines which freeze during boot; this seems to be ACPI-related,
because with acpi=off they start.
The first one is the HP DC 7700; some summary can be seen on
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1081719
It hangs after a line
Hello everybody,
here are some small documentation fixes - mostly typing errors.
Please take a look at the last chunk - I think that klibc.bkbits.net
is no longer the current version, but I'm not sure whether the
other link is better.
Whom should I CC for other documentation updates? Is the
Hello everybody,
here are some small documentation fixes - mostly typing errors.
Please take a look at the last chunk - I think that klibc.bkbits.net
is no longer the current version, but I'm not sure whether the
other link is better.
Whom should I CC for other documentation updates? Is the
Hello everybody!
I have two machines which freeze during boot; this seems to be ACPI-related,
because with acpi=off they start.
The first one is the HP DC 7700; some summary can be seen on
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1081719
It hangs after a line
On Dienstag, 31. Juli 2007, Gabriel C wrote:
[ added linux-acpi to CC ]
Sorry, forgot to mention:
I'd like to use 2.6.20.1, but I already tested with 2.6.22.1.
IIUC if there's a problem with the ACPI tables, the blacklist won't help,
because to know whether the ACPI blacklist applies ACPI
On Dienstag, 31. Juli 2007, Cal Peake wrote:
Whom should I CC for other documentation updates? Is the maintainer
the correct person, or are such small fixes send and forget?
For spelling and grammar fixes, sending to [EMAIL PROTECTED] is prolly
the best bet with a CC to l-k.
Also, please
Hello Daniel,
hello everbody else,
in Oct 2000 there's been some discussion "Tux2 - evil patents sighted"
(http://www.ussg.iu.edu/hypermail/linux/kernel/0010.0/0343.html), and in Aug
2002 (http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.3/0332.html) Daniel
wrote
> It's well down my list of
On Mittwoch, 20. Juni 2007, Vladislav Bolkhovitin wrote:
> Philipp Matthias Hahn wrote:
> I would also suggest one more feature: support for block level
> de-duplication. I mean:
> So, seems ever for file based de-duplication some support from the FS,
> including some kind of ability for
On Mittwoch, 20. Juni 2007, H. Peter Anvin wrote:
> Alan Cox wrote:
> > POSIX is very
> > clear about what is acceptable as magic in a pathname, and the unix spec
> > even more so. The NetApp approach recognizes two important things
> >
> > 1. Old version access is the oddity not the norm
> > 2.
On Mittwoch, 20. Juni 2007, H. Peter Anvin wrote:
Alan Cox wrote:
POSIX is very
clear about what is acceptable as magic in a pathname, and the unix spec
even more so. The NetApp approach recognizes two important things
1. Old version access is the oddity not the norm
2. Standards
On Mittwoch, 20. Juni 2007, Vladislav Bolkhovitin wrote:
Philipp Matthias Hahn wrote:
I would also suggest one more feature: support for block level
de-duplication. I mean:
So, seems ever for file based de-duplication some support from the FS,
including some kind of ability for different
Hello Daniel,
hello everbody else,
in Oct 2000 there's been some discussion Tux2 - evil patents sighted
(http://www.ussg.iu.edu/hypermail/linux/kernel/0010.0/0343.html), and in Aug
2002 (http://www.uwsg.iu.edu/hypermail/linux/kernel/0208.3/0332.html) Daniel
wrote
It's well down my list of
On Donnerstag, 14. Juni 2007, DervishD wrote:
> Your message is very peculiar... because I already have a similar
> thing working on my system ;))) I tried FSVS and I didn't like it fully
> (don't ask me why, I don't even remember, that was a time ago), so I
> wrote my own system.
Well, if you
(Sorry for this hand-crafted message. I'm not subscribed, lkml.org is down, so
I have to manually add the Reply-To header.)
> I was just wondering if, apart from the excessive wear, there were
> other reasons. One of the reasons I would like to use a good filesystem
> for a pendrive is to be
(Sorry for this hand-crafted message. I'm not subscribed, lkml.org is down, so
I have to manually add the Reply-To header.)
I was just wondering if, apart from the excessive wear, there were
other reasons. One of the reasons I would like to use a good filesystem
for a pendrive is to be
On Donnerstag, 14. Juni 2007, DervishD wrote:
Your message is very peculiar... because I already have a similar
thing working on my system ;))) I tried FSVS and I didn't like it fully
(don't ask me why, I don't even remember, that was a time ago), so I
wrote my own system.
Well, if you
On Mittwoch, 23. Mai 2007, Al Viro wrote:
> Then I do not understand what this mechanism could be used for, other
> than an odd way to twist POSIX behaviour and see how much of the userland
> would survive that.
I have some similar considerations about how userspace should deal with that.
The
On Mittwoch, 23. Mai 2007, Al Viro wrote:
Then I do not understand what this mechanism could be used for, other
than an odd way to twist POSIX behaviour and see how much of the userland
would survive that.
I have some similar considerations about how userspace should deal with that.
The
Pine.LNX.4.64.0704181515290.25880 () alien ! or ! mcafeemobile ! com
Davide Libenzi wrote:
> On Wed, 18 Apr 2007, Ingo Molnar wrote:
> > That's one reason why i dont think it's necessarily a good idea to
> > group-schedule threads, we dont really want to do a per thread group
> > percpu_alloc().
Pine.LNX.4.64.0704181515290.25880 () alien ! or ! mcafeemobile ! com
Davide Libenzi wrote:
On Wed, 18 Apr 2007, Ingo Molnar wrote:
That's one reason why i dont think it's necessarily a good idea to
group-schedule threads, we dont really want to do a per thread group
percpu_alloc().
I
> Hello,
>> - encrypts new files depending on their filename, and generally
>
> What about renaming a file ???
Well, that's a small (but known!) problem with this scheme.
If you say that everything below a directory "_crypt_" should be
encrypted, and just move files in there, you've got no
Hello everybody!
I'm aware of some implementations for file system encryption - dm-crypt,
loopback with encryption, truecrypt, and fuse.
Now I'd like to ask if it's easily possible to write a (preloaded)
user-space library or a kernel module, that
- overlays an existing directory tree,
-
Hello everybody!
I'm aware of some implementations for file system encryption - dm-crypt,
loopback with encryption, truecrypt, and fuse.
Now I'd like to ask if it's easily possible to write a (preloaded)
user-space library or a kernel module, that
- overlays an existing directory tree,
-
Hello,
- encrypts new files depending on their filename, and generally
What about renaming a file ???
Well, that's a small (but known!) problem with this scheme.
If you say that everything below a directory _crypt_ should be
encrypted, and just move files in there, you've got no problems - the
>> >> If a file's data has been changed, it suffices to update the inode and
>> >> the of free blocks bitmap (fbb).
>> >> But updating them in one go is not possible
>> >
>> >You seem to have missed some fundamental understanding of
>> >exactly how phase tree works; the wohle point of phase
>>
If a file's data has been changed, it suffices to update the inode and
the of free blocks bitmap (fbb).
But updating them in one go is not possible
You seem to have missed some fundamental understanding of
exactly how phase tree works; the wohle point of phase
tree is to make atomic
>> If a file's data has been changed, it suffices to update the inode and the
>> of free blocks bitmap (fbb).
>> But updating them in one go is not possible
>
>You seem to have missed some fundamental understanding of
>exactly how phase tree works; the wohle point of phase
>tree is to make atomic
I'd like to give some of my thoughts regarding tux2 (phase-change-tree fs):
* FILES *
If a file's data has been changed, it suffices to update the inode and the
of free blocks bitmap (fbb).
But updating them in one go is not possible - the fbb is located at the
superblock, the inode can be
I'd like to give some of my thoughts regarding tux2 (phase-change-tree fs):
* FILES *
If a file's data has been changed, it suffices to update the inode and the
of free blocks bitmap (fbb).
But updating them in one go is not possible - the fbb is located at the
superblock, the inode can be
If a file's data has been changed, it suffices to update the inode and the
of free blocks bitmap (fbb).
But updating them in one go is not possible
You seem to have missed some fundamental understanding of
exactly how phase tree works; the wohle point of phase
tree is to make atomic updates
>For your specific problem I'd suggest the following approach:
>
>write a new filter prog, kind of a 'destructive cat' command.
>
>Open the file for read-modify (non destructive)
>Let it read some blocks (number controllable on commandline) from the
>beginning and pipe them to stdout. Then.. read
Hi everybody,
though looking and grepping through the sources I couldn't find a way (via
fcntl() or whatever) to allow an existing file to get holes.
I found that cp has a parameter --sparse (or suchlike) - but strace shows
it doing a open(,O_TRUNC) which has a bit of impact on previous
Hi everybody,
though looking and grepping through the sources I couldn't find a way (via
fcntl() or whatever) to allow an existing file to get holes.
I found that cp has a parameter --sparse (or suchlike) - but strace shows
it doing a open(,O_TRUNC) which has a bit of impact on previous
For your specific problem I'd suggest the following approach:
write a new filter prog, kind of a 'destructive cat' command.
Open the file for read-modify (non destructive)
Let it read some blocks (number controllable on commandline) from the
beginning and pipe them to stdout. Then.. read in
Hi everybody,
I'd like to offer my $0.02 to the ongoing discussion.
IIRC we already have some OOB-data channels - ioctl, setsockopt, fcntl ...
to name only a few.
But: we already have a side-band: send with MSG_OOB!
And, as I just saw in the sources, there are some flags free.
So how about
Hi everybody,
I'd like to offer my $0.02 to the ongoing discussion.
IIRC we already have some OOB-data channels - ioctl, setsockopt, fcntl ...
to name only a few.
But: we already have a side-band: send with MSG_OOB!
And, as I just saw in the sources, there are some flags free.
So how about
Hi Richard,
in fs/devfs/util.c is
void __init devfs_make_root (const char *name)
which is wrong as pivot_root allows changing the root-device in the runtime.
I think it should be
void __init devfs_make_root (const char *name)
and get called by
fs/super.c:
asmlinkage
Hi Richard,
in fs/devfs/util.c is
void __init devfs_make_root (const char *name)
which is wrong as pivot_root allows changing the root-device in the runtime.
I think it should be
void __init devfs_make_root (const char *name)
and get called by
fs/super.c:
asmlinkage
Hi everybody,
thanks for your patience.
It's an error on my side (as expected).
Looking through the sources of mount I found out that due to a bad copying
mount had -rwsr-xr-x with a non-0 user id. That explains it.
Thanks again!
Phil
-
To unsubscribe from this list: send the line
Hi everybody,
thanks for your patience.
It's an error on my side (as expected).
Looking through the sources of mount I found out that due to a bad copying
mount had -rwsr-xr-x with a non-0 user id. That explains it.
Thanks again!
Phil
-
To unsubscribe from this list: send the line
>> Hi everybody!
>>
>> Hope I didn't forget something necessary.
>>
>>
>>
>> 1:
>> Kernel bug/Segmentation fault when floppy disk removed 2nd time
>>
>>
>> 2:
>> Segmentation fault in a program,
>> hanging processes in "D"-state,
>> Kernel bug in inode.c:885!
>>
>> when removing floppy
Hi everybody!
Hope I didn't forget something necessary.
1:
Kernel bug/Segmentation fault when floppy disk removed 2nd time
2:
Segmentation fault in a program,
hanging processes in "D"-state,
Kernel bug in inode.c:885!
when removing floppy disk before unmounting and then using again
3:
Hi everybody!
Hope I didn't forget something necessary.
1:
Kernel bug/Segmentation fault when floppy disk removed 2nd time
2:
Segmentation fault in a program,
hanging processes in "D"-state,
Kernel bug in inode.c:885!
when removing floppy disk before unmounting and then using again
3:
Hi everybody!
Hope I didn't forget something necessary.
1:
Kernel bug/Segmentation fault when floppy disk removed 2nd time
2:
Segmentation fault in a program,
hanging processes in "D"-state,
Kernel bug in inode.c:885!
when removing floppy disk before unmounting and then
>> Furthermore, in the "char *"-case the pointer is stored in memory.
>
>It has to be, no matter of optimalization level. Some other module
>might access that variable. You _could_ do static const char *..., but
>it would probably not help.
I know that the pointer is NEEDED (from the compilers
Furthermore, in the "char *"-case the pointer is stored in memory.
It has to be, no matter of optimalization level. Some other module
might access that variable. You _could_ do static const char *..., but
it would probably not help.
I know that the pointer is NEEDED (from the compilers pov);
Hello everybody,
looking through the sources I found several pieces like
lib/vsprintf.c, line 111:
const char *digits="0123456789abcdefghijklmnopqrstuvwxyz";
As tested with egcs-2.91.60 even with -O3 there is a difference
between
const char
Hello everybody,
looking through the sources I found several pieces like
lib/vsprintf.c, line 111:
const char *digits="0123456789abcdefghijklmnopqrstuvwxyz";
As tested with egcs-2.91.60 even with -O3 there is a difference
between
const char
>I need the output from these commands on a running 2.4.x kernel
>compiled for duron.
>
>grep _mmx_memcpy /proc/ksyms
>strings -a `/sbin/modprobe -l '*tulip*'` | grep _mmx_memcpy
Short version: it's caused by CONFIG_MODVERSIONS=y.
see the logs on the end.
If I turn it off and compile again, it
I need the output from these commands on a running 2.4.x kernel
compiled for duron.
grep _mmx_memcpy /proc/ksyms
strings -a `/sbin/modprobe -l '*tulip*'` | grep _mmx_memcpy
Short version: it's caused by CONFIG_MODVERSIONS=y.
see the logs on the end.
If I turn it off and compile again, it works.
Hi everybody,
Some time ago I tried 2.4.0 compiled with option for duron-processors,
yesterday I tried 2.4.1; both give problems on insmod/modprobe with some
modules, eg. tulip.
The offending function is _mmx_memcpy, which can be found in the System.map
(but, opposed to other functions, with an
83 matches
Mail list logo
