Bodo Eggert wrote:
> Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
>
>
>>+If you want to store your suspend image encrypted with a temporary
>>+key to prevent data gathering after resume you must compile
>>+crypto and the aes algorithm into the kernel - modules won't work
>>+as they cannot be
On 2005-04-11, Linus Torvalds wrote:
>I'm inclined to go with GPLv2 just because it's the most common one [...]
You may want to use a file from GPL'ed monotone that
implements a substantial diff optimization described in the August
1989 paper by Sun Wu, Udi Manber and Gene Myers ("An
On Mon, 11 Apr 2005, Ingo Molnar wrote:
>
> if a repository is corrupted then it pretty much needs to be dropped
> anyway.
I disagree. Yes, the thing is designed to be replicated, so most of the
time the easiest thing to do is to just rsync with another copy.
But dammit, I don't want to
Troy> How is memory pinning handled? (I haven't had time to read
Troy> all the code, so please excuse my ignorance of something
Troy> obvious).
The userspace library calls mlock() and then the kernel does
get_user_pages().
Troy> The old mellanox drivers used to have a hack to
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> > > to construct the combo blob later on, we do have to unpack sched.c (and
> > > if it's already a combo-blob that is not cached then we'd have to unpack
> > > all parents until we arrive at some
> > 3) No other user should have access to files under the mount, not
> > even root[5]
>
> > [5] Obviously root cannot be restricted, but accidental access to
> > private data is still a good idea. E.g. root squashing by NFS servers
> > has a similar affect.
>
> Could you explain a
On Sun, 10 Apr 2005 16:38:00 -0700 (PDT) Linus Torvalds wrote:
|
|
| On Sun, 10 Apr 2005, Paul Jackson wrote:
| >
| > Useful explanation - thanks, Linus.
|
| Hey. You're welcome. Especially when you create good documentation for
| this thing.
|
| Because:
|
| > Is this picture and
On Mon, Apr 11, 2005 at 11:21:45AM -0400, Trond Myklebust wrote:
> må den 11.04.2005 Klokka 16:41 (+0200) skreiv Jakob Oestergaard:
>
> > > That can mean either that the server is dropping fragments, or that the
> > > client is dropping the replies. Can you generate a similar tcpdump on
> > > the
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > to construct the combo blob later on, we do have to unpack sched.c (and
> > if it's already a combo-blob that is not cached then we'd have to unpack
> > all parents until we arrive at some full blob).
>
> I really don't want to have this. Having
On Llu, 2005-04-04 at 18:42, Jonas Diemer wrote:
> I figured there could be a kernel compiled-in option that will make the
> kernel
> lock all drives found during bootup. then, a malicous program would need to
> install a different kernel in order to harm the drive, which would be much
> more
On Mon, Apr 11, 2005 at 04:43:32PM +0200, Miklos Szeredi wrote:
> 3) No other user should have access to files under the mount, not
> even root[5]
> [5] Obviously root cannot be restricted, but accidental access to
> private data is still a good idea. E.g. root squashing by NFS servers
>
On Mon, 11 Apr 2005, Ingo Molnar wrote:
>
> to construct the combo blob later on, we do have to unpack sched.c (and
> if it's already a combo-blob that is not cached then we'd have to unpack
> all parents until we arrive at some full blob).
I really don't want to have this. Having chains of
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> here are some stats: of the last 34160 files modified in the Linux
> kernel tree in the past 1 year, the file sizes total to 1 GB, and the
> average file-size per file committed is 31220 bytes. The changes
> themselves amount to:
>
> 22404 files
On Maw, 2005-04-05 at 09:49, Martin Egholm Nielsen wrote:
> As I can see, the patch never made it in 2.4.x, right?!
> So, I would like a diff - if still possible :-)
I submitted it ages ago but it was rejected and punted to 2.6. The 2.4
support is available in Red Hat Enterprise Linux 3, so you
here are some stats: of the last 34160 files modified in the Linux
kernel tree in the past 1 year, the file sizes total to 1 GB, and the
average file-size per file committed is 31220 bytes. The changes
themselves amount to:
22404 files changed, 1996494 insertions(+), 1396644 deletions(-)
Hello,
I've encountered the strangest problem yet in my linux career...I'll just
explain my setup, what happens, and what solved the problem and you can decide
if you are more interested after that...
* Company firewall 2.6.8.1 ip-address 1.2.3.4 with priv net 192.168.1
* Home firewall
mà den 11.04.2005 Klokka 16:41 (+0200) skreiv Jakob Oestergaard:
> > That can mean either that the server is dropping fragments, or that the
> > client is dropping the replies. Can you generate a similar tcpdump on
> > the server?
>
> Certainly; http://unthought.net/sparrow.dmp.bz2
So, it
On Mon, Apr 11, 2005 at 12:48:34AM +0200, Adrian Bunk wrote:
> kernel-rcupdatec-make-the-exports-export_symbol_gpl.patch
> add-deprecated_for_modules.patch
> add-deprecated_for_modules-fix.patch
> deprecate-synchronize_kernel-gpl-replacement.patch
>
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> Hmmm ... I have this strong sense that I am about 2 hours away from
> smacking my forehead and groaning "Duh - so that's what Ingo meant!"
>
> However, one must play out one's destiny.
>
> Could you provide an example scenario, which results in the
Hi,
Please find the patch below to fix Oops! in unregister_kprobe().
Please let me know if you any issues.
Thanks
Prasanna
kernel oops! when unregister_kprobe() is called on a non-registered
kprobe. This patch fixes the above problem by checking if the probe exists
before unregistering.
Some nlmsg alignment cleanups. Documentation module cleanups.
Thanks, Thomas.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
* looking for [EMAIL PROTECTED]/connector--main--0--patch-47 to compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-47
M cn_test.c
M
Hmmm ... I have this strong sense that I am about 2 hours away from
smacking my forehead and groaning "Duh - so that's what Ingo meant!"
However, one must play out one's destiny.
Could you provide an example scenario, which results in the creation of
a combo-blob?
The best I can come up with is
We're having a bit of a disagreement with Christoph Hellwig about the
way FUSE does (or should do) permission checking. Comments (either
way) are appreciated.
Here's my side of the story:
FUSE (filesystem in userspace) is designed to allow mounting an FS by
non-privileged users (it can also be
On Mon, Apr 11, 2005 at 10:35:25AM -0400, Trond Myklebust wrote:
> må den 11.04.2005 Klokka 15:47 (+0200) skreiv Jakob Oestergaard:
>
> > Certainly;
> >
> > http://unthought.net/binary.dmp.bz2
> >
> > I got an 'invalid snaplen' with the 9 you suggested, the above dump
> > is done with 9000
mà den 11.04.2005 Klokka 15:47 (+0200) skreiv Jakob Oestergaard:
> Certainly;
>
> http://unthought.net/binary.dmp.bz2
>
> I got an 'invalid snaplen' with the 9 you suggested, the above dump
> is done with 9000 - if you need another snaplen please just let me know.
So, the RPC itself looks
Adrian,
./drivers/char/mwave/Makefile also references Paul's email
address, at least in v2.4.
Applied, thanks.
On Sun, Apr 10, 2005 at 01:15:45AM +0200, Adrian Bunk wrote:
> Both maintainer email addresses are bouncing and the web address is no
> longer valid.
>
> Seems to be a good time to
> In particular, the memory pinning code in in uverbs_mem.c could stand
> a looking over. In addition, a sanity check of the write()-based
> scheme for passing commands into the kernel in uverbs_main.c and
> uverbs_cmd.c is probably worthwhile.
How is memory pinning handled? (I haven't had time
> Andreas is right, his patches are needed.
>
> Currently, if your laptop is stolen after resume, they can still data
> in swsusp image.
Which shows that swsusp is a security risk if you have sensitive data in
RAM. A thief stealing a running computer can get access to memory
contents much more
Followup to: <[EMAIL PROTECTED]>
By author:Christopher Li <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> There is one problem though. How about the SHA1 hash collision?
> Even the chance is very remote, you don't want to lose some data do due
> to "software" error. I think it is OK
Hello,
here goes git-pasky-0.3, my set of patches and scripts upon
Linus' git, aimed at human usability and to an extent a SCM-like usage.
If you already have a previous git-pasky version, just git pull pasky
to get it (but see below!!!). Otherwise, you can get it from:
On Mon, Apr 11, 2005 at 08:35:39AM -0400, Trond Myklebust wrote:
...
> That certainly shouldn't be the case (and isn't on any of my setups). Is
> the behaviour identical same on both the PIII and the Opteron systems?
The dual opteron is the nfs server
The dual athlon is the 2.4 nfs client
The
Michael Poole wrote:
Copyright law only _explicitly_ grants a monopoly on preparation of
derivative works. However, it is trivial, and overwhelmingly common,
for a copyright owner to grant a license to create a derivative work
that is conditional on how the licensee agrees to distribute (or not
Humberto Massa writes:
> David Schwartz wrote:
>
>> > On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote:
>>
>>
>> >> The way you stop someone from distributing part of your work is
>> >> by arguing that the work they are distributing is a derivative
>> >> work of your work and they
* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-11 16:59
> + size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> +
> + skb = alloc_skb(size, gfp_mask);
> + if (!skb) {
> + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n",
> size);
> + return -ENOMEM;
> +
Richard B. Johnson wrote:
Shouldn't it just be:
#define mach_reboot_fixup(x)
|___ Nothing here.
Dear Wrongbot,
No.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
At Sun, 10 Apr 2005 01:12:11 +0200,
Adrian Bunk wrote:
>
> This patch removes some dead code found by the Coverity checker.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Applied to ALSA tree. Thanks!
Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Pavel Machek wrote:
> Hi!
>
>
>>The following patch adds the core functionality for the encrypted
>>suspend image.
>
>
> +#ifdef CONFIG_SWSUSP_ENCRYPT
> +static struct crypto_tfm *crypto_init(int mode)
> +{
> + struct crypto_tfm *tfm;
> + int len;
> +
> + tfm =
Rafael J. Wysocki wrote:
> Hi,
>
> On Monday, 11 of April 2005 01:17, Andreas Steinmetz wrote:
>
>>Pavel,
>>during testing of the encrypted swsusp_image on x86_64 I did get an Oops
>>from time to time at memcpy+11 called from swsusp_save+1090 which turns
>>out to be the memcpy in
[EMAIL PROTECTED] wrote:
>>>The following patch adds the core functionality for the encrypted
>>>suspend image.
>>
>>[Please inline patches, it makes it easier to comment on them.]
Aiyeeh - good ole Mozilla tends to reformat things when inlining...
>>You seem to reuse same key/iv for all the
On Monday 11 April 2005 03:38, Ingo Molnar wrote:
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > So anything that got modified in just one tree obviously merges to
> > that version. Any file that got modified in two trees will end up just
> > being passed to the "merge" program. See "man merge"
I handled this issue by precaching all my files (15MB),
from my readonly root filesystem.
find / -type f |
grep -v ^/boot | #kernel is > 1MB and never read so don't put in cache
while read file; do
dd bs=32k if="$file" of=/dev/null 2>/dev/null
done
Pádraig.
-
To unsubscribe from this list:
Hi,
On Thu, 2005-04-07 at 16:51, Stephen C. Tweedie wrote:
> I'm currently running with the buffer-trace debug patch, on 2.4, with a
> custom patch to put every buffer jbd ever sees onto a per-superblock
> list, and remove it only when the bh is destroyed in
> put_unused_buffer_head(). At
/*/
Kernel Connector.
/*/
Kernel connector - new netlink based userspace <-> kernel space easy to use
communication module.
Connector driver adds possibility to connect various agents using
netlink based network.
Nick Piggin wrote:
The common theme seems to be: try_to_free_pages, swap_writepage,
mempool_alloc, down/down_failed in .text.lock.md. Next I would suspect
md/raid1 - maybe some deadlock in an uncommon memory allocation
failure path?
I'll see if I can reproduce it here.
No luck yet (on SMP i386).
> + cmd->request->flags |= REQ_SOFTBARRIER;
> +
> + spin_lock_irqsave(q->queue_lock, flags);
> + blk_requeue_request(q, cmd->request);
> + spin_unlock_irqrestore(q->queue_lock, flags);
>
> scsi_run_queue(q);
This exact code sequence is duplicated in the previous patch,
On Mon, 11 Apr 2005, H. Peter Anvin wrote:
[EMAIL PROTECTED] wrote:
Hi Riley, Dave, Peter, i386 boot/workaround maintainers,
I'm resending this patch (from March 28).
This patch incorporates the suggestions from the previous thread and also
switches to using pci_get_device since pci_find_device is
mà den 11.04.2005 Klokka 09:48 (+0200) skreiv Jakob Oestergaard:
> tcp with timeo=600 causes retransmits (as seen with nfsstat) to drop to
> zero.
Good.
> File Block Num Seq ReadRand Read Seq Write Rand Write
> DirSize Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%)
[EMAIL PROTECTED] wrote:
Hi Riley, Dave, Peter, i386 boot/workaround maintainers,
I'm resending this patch (from March 28).
This patch incorporates the suggestions from the previous thread and also
switches to using pci_get_device since pci_find_device is deprecated, and
made some of the
On Apr 11, 2005 1:38 PM, kus Kusche Klaus <[EMAIL PROTECTED]> wrote:
> So the question is, what exactly is the IDE priority?
> Is the PIO transfer done in the IRQ handler or in a bh?
in the IRQ handler
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
David Schwartz wrote:
> On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote:
>> The way you stop someone from distributing part of your work is
>> by arguing that the work they are distributing is a derivative
>> work of your work and they had no right to *make* it in the first
>>
Giuseppe Bilotta wrote:
On Fri, 08 Apr 2005 20:42:17 +0200, Josselin Mouette wrote:
Every book in my book shelf is software?
If you digitalize it, yes.
AFAIK software only refers to programs, not to arbitrary sequences of
bytes. An MP3 file isn't "software". Although it surely isn't
Hi,
On Fri, 2005-04-08 at 19:10, Mingming Cao wrote:
> > It still needs to be done under locking to prevent us from expanding
> > over the next window, though. And having to take and drop a spinlock a
> > dozen times or more just to find out that there are no usable free
> > blocks in the
Adrian Bunk wrote:
Even RedHat with a stronger financial background than Debian considered
the MP3 patents being serious enough to remove MP3 support.
Actually, they did it to spite the patent holders.
[]s
Massa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Glenn Maynard wrote:
I've heard the claim, several times, that that creating a derivative
work requires creative input, that linking stuff together with "ld" is
completely uncreative, therefore no derivative work is created. (I'm
not sure if you're making (here or elsewhere) that claim, but it
>From the three sources of multi-millisecond latency in my experiments
(console messages to dead serial console, USB I/O, CF Card bulk read),
I've analyzed one:
The latency of around 70 milliseconds in low-priority RT processes
when running a "dd if=/dev/hda of=/dev/null" in parallel (where hda
Hi,
On Fri, 2005-04-08 at 18:14, Badari Pulavarty wrote:
> I get OOPs in log_do_checkpoint() while using ext3 quotas.
> Is this anyway related to what you are working on ?
>
> Unable to handle kernel NULL pointer dereference at virtual address
>
Doesn't look like it, no. If we
> > > > The following patch adds the core functionality for the encrypted
> > > > suspend image.
> > > [Please inline patches, it makes it easier to comment on them.]
> > > You seem to reuse same key/iv for all the blocks. I'm no crypto
> > > expert, but I think that is seriously wrong... You
i think all of the 'repository size' and 'bandwidth' concerns could be
solved via a new (and pretty much simple and transparent) object type:
the 'combo-blob'.
Summary:
This is a space/bandwidth-efficient blob that 'includes' arbitrary
portions of (one, two, or more) simple blobs by
Hello,
> On Mon, 2005-04-04 at 10:04, Jan Kara wrote:
>
> > In log_do_checkpoint() we go through the t_checkpoint_list of a
> > transaction and call __flush_buffer() on each buffer. Suppose there is
> > just one buffer on the list and it is dirty. __flush_buffer() sees it and
> > puts it to
On Mon, 2005-04-11 at 12:45 +0200, Thomas Graf wrote:
> * Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-11 09:22
> > On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED])
> > wrote:
> > > + size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> > > +
> > > + skb =
> I get OOPs in log_do_checkpoint() while using ext3 quotas.
> Is this anyway related to what you are working on ?
Nope, it does not seem to be the same problem. In theory it could be a
bug Stephen fixed some time ago - could you try to reproduce the problem
with 2.6.12-rc2 (it contains the
Hi!
> The following patch adds the core functionality for the encrypted
> suspend image.
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struct crypto_tfm *crypto_init(int mode)
+{
+ struct crypto_tfm *tfm;
+ int len;
+
+ tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+
Hi!
> > > The following patch adds the core functionality for the encrypted
> > > suspend image.
> > [Please inline patches, it makes it easier to comment on them.]
> > You seem to reuse same key/iv for all the blocks. I'm no crypto
> > expert, but I think that is seriously wrong... You probably
Hi!
> during testing of the encrypted swsusp_image on x86_64 I did get an Oops
> from time to time at memcpy+11 called from swsusp_save+1090 which turns
> out to be the memcpy in copy_data_pages() of swsusp.c.
> The Oops is caused by a NULL pointer (I don't remember if it was source
> or
Hi!
> > > No, XFS is my root filesystem. :( (Now that I think about it, would
> > > modularizing XFS and using an initrd be OK?)
> >
> > Yes, loading xfs from initrd should help. [At least it did during
> > suse9.3 testing.]
>
> Once I modularized xfs and switched to using an initrd, the
Dear diary, on Mon, Apr 11, 2005 at 10:40:00AM CEST, I got a letter
where Florian Weimer <[EMAIL PROTECTED]> told me that...
> * Ingo Molnar:
>
> > is there any fundamental problem with going with v2 right now, and then
> > once v3 is out and assuming it looks ok, all newly copyrightable bits
>
* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-11 09:22
> On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED])
> wrote:
> > + size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> > +
> > + skb = alloc_skb(size, GFP_ATOMIC);
> > + if (!skb) {
> > +
When a process running with RT priority dumps core,
I get the following BUG:
Apr 11 13:44:23 OF455 kern.err kernel: BUG: rtc2:833 RT task
yield()-ing!
Apr 11 13:44:23 OF455 kern.warn kernel: [] yield+0x61/0x70
(8)
Apr 11 13:44:23 OF455 kern.warn kernel: []
coredump_wait+0x79/0xc0 (20)
Apr 11
Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
> Hi!
>
> > > Oliver Neukum wrote:
> > > > What is the point in doing so after they've rested on the disk for ages?
> > >
> > > The point is not physical access to the disk but data gathering after
> > > resume or reboot.
> >
> > After
> > The following patch adds the core functionality for the encrypted
> > suspend image.
> [Please inline patches, it makes it easier to comment on them.]
> You seem to reuse same key/iv for all the blocks. I'm no crypto
> expert, but I think that is seriously wrong... You probably should use
>
Andrew Morton wrote:
bk-cifs.patch
This breaks the build on mips, ppc64, sparc, sparc64 with the
following error (defconfig, compared to mm2):
CC [M] fs/cifs/misc.o
fs/cifs/misc.c: In function `cifs_convertUCSpath':
fs/cifs/misc.c:546: error: case label does not reduce to an integer constant
Hi!
> The following patch adds the core functionality for the encrypted
> suspend image.
[Please inline patches, it makes it easier to comment on them.]
You seem to reuse same key/iv for all the blocks. I'm no crypto
expert, but I think that is seriously wrong... You probably should use
block
Dear diary, on Mon, Apr 11, 2005 at 10:50:51AM CEST, I got a letter
where Ingo Molnar <[EMAIL PROTECTED]> told me that...
>
> * Petr Baudis <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> >
> > here goes git-pasky-0.2, my set of patches and scripts upon Linus'
> > git, aimed at human usability
Thanks Maneesh for your comments. Please find
the patch below.
> [..]
> > Assumption : If a user has already inserted a probe using old
> > register_kprobe()
> > routine, and later wants to insert another probe at the same address using
> > register_multiprobe() routine, then
Dear diary, on Mon, Apr 11, 2005 at 04:46:42AM CEST, I got a letter
where Daniel Barkalow <[EMAIL PROTECTED]> told me that...
> On Mon, 11 Apr 2005, Petr Baudis wrote:
>
> > Hello,
> >
> > here goes git-pasky-0.2, my set of patches and scripts upon
> > Linus' git, aimed at human usability
Hi!
> > Encrypting swsusp image is of course even better, because you don't
> > have to write large ammounts of zeros to your disks during resume ;-).
>
> How does zeroing help if they steal the laptop? The data is there, they
> can just pull the hard disk out and mirror it before they boot.
>
On 4/9/05, Domen Puncer <[EMAIL PROTECTED]> wrote:
> On 21/03/05 00:06 +0100, Magnus Damm wrote:
> > Here are a set of patches that makes it possible to autogenerate kernel
> > command
> > line documentation from the source code. The approach is rather
> > straightforward
> > - the parameter
Hi!
> > The following patches allow for encryption of the on-disk swsusp image
> > to prevent data gathering of e.g. in-kernel keys or mlocked data after
> > resume.
> > For this purpose the aes cipher must be compiled into the kernel as
> > module load is not possible at resume time.
> > A
Claudio Martins wrote:
On Sunday 10 April 2005 03:47, Andrew Morton wrote:
Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from
cutting in during long sysrq traces.
Also, capture the `sysrq-m' output so we can see if the thing is out of
memory.
Hi Andrew,
Thanks for the
[PATCH] I2C rtc8564.c remove duplicate include
Trivial fix: removes duplicate include line.
Patch applies to: 2.6.11.x
(This is my very first patch to the linux-kernel, so let me
start with small things first...)
Signed-off-by: Clemens Koller <[EMAIL PROTECTED]>
---
diff -Nur
(Please do reply-to-all)
"J.A. Magallon" <[EMAIL PROTECTED]> wrote:
>
> On 04.11, Andrew Morton wrote:
> >
> >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> >
> >
>
> Is this not needed anymore ?
>
> ---
On Mon, 2005-04-11 at 01:04 +0200, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > (I repeat the xxx in the leaf name - easier to code.)
>
> It is a bit OT, but just a note: there are file systems (hash functions) out
> there who dont like a lot of files named the same way.
On Mon, 2005-04-11 at 11:07 +0200, Mathieu Fluhr wrote:
> Hello
>
> It seems that the smbfs driver does not handle correctly large files
> (>2GB). The thing is that statting them is correct (for example, the
> st_size field is correctly set), but as soon as you try to make a lseek
> with an
Hello
It seems that the smbfs driver does not handle correctly large files
(>2GB). The thing is that statting them is correct (for example, the
st_size field is correctly set), but as soon as you try to make a lseek
with an offset larget than INT_MAX, you get a EINVAL error.
Note: This is not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Can you tell me if there is currently support in the
> kernel for HP's new LightScribe technology?
> (http://h30015.www3.hp.com/hp_dec/lightscribe/index_FL.asp).
> If there is not, are there plans for it?
>
> Supposdly, you can burn DVD's or CD's,
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>
>* Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
>
>> Let me re-phrase then: it is a must have only on PI, to make sure you
>> don't have a loop when doing it. Maybe is a consequence of the
>> algorithm I chose. -However- it should be possible to
* Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
> Let me re-phrase then: it is a must have only on PI, to make sure you
> don't have a loop when doing it. Maybe is a consequence of the
> algorithm I chose. -However- it should be possible to disable it in
> cases where you are reasonably
On 04.11, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
>
>
Is this not needed anymore ?
--- 25/arch/i386/kernel/entry.S~nmi_stack_correct-fix 2005-04-05
00:02:48.0 -0700
+++ 25-akpm/arch/i386/kernel/entry.S
* Petr Baudis <[EMAIL PROTECTED]> wrote:
> Hello,
>
> here goes git-pasky-0.2, my set of patches and scripts upon Linus'
> git, aimed at human usability and to an extent a SCM-like usage.
works fine on FC4, i only minor issues: 'git' in the tarball didnt have
the x permission. Also, your
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>
>* Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
>
>> >OTOH, deadlock detection is another issue. It's quite expensive and
i'm
>> >not sure we want to make it a runtime thing. But for fusyn's
deadlock
>> >detection and safe teardown on owner-exit
* Perez-Gonzalez, Inaky <[EMAIL PROTECTED]> wrote:
> >OTOH, deadlock detection is another issue. It's quite expensive and i'm
> >not sure we want to make it a runtime thing. But for fusyn's deadlock
> >detection and safe teardown on owner-exit is a must-have i suspect?
>
> Not really. Deadlock
* Ingo Molnar:
> is there any fundamental problem with going with v2 right now, and then
> once v3 is out and assuming it looks ok, all newly copyrightable bits
> (new files, rewrites, substantial contributions, etc.) get a v3
> copyright? (and the collection itself would be v3 too) That
>From: Ingo Molnar [mailto:[EMAIL PROTECTED]
>
>
>i'd not mind merging the extra bits to PREEMPT_RT to enable fusyn's, if
>they come in small, clean steps. E.g. Daniel's plist.h stuff was nice
>and clean.
I am finishing breaking it up in small bits so you can take a look
at it. Should be finished
Uttered Tomko <[EMAIL PROTECTED]>, spake thus:
> I would like to ask when a userprogram called in user space called
> execve("/bin/abc" will this system call finally copy the code of
> /bin/abc into kernel space before kernel runs it or just leave the code
> in the userspace and run
Dave Hansen wrote:
The only arch with phys_to_pfn() defined is UML, so the patch simply
won't compile anything but UML on current kernels (unless I'm missing
something).
oops, I forgot to send the part of the patch that defines these macros,
sorry.
Could you try to give us a more complete
Hi !
This patch hacks the current PowerMac Alsa driver to add some basic
support of analog sound output to some desktop G5s. It has severe
limitations though:
- Only 44100Khz 16 bits
- Only work on G5 models using a TAS3004 analog code, that is early
single CPU desktops and all dual CPU
Hi,
I am having problems while booting 2.6.12-rc2-mm1 on i386 with command line
maxcpus=1. Without this commandline, system boots fine otherwise it hangs.
Serial output is pasted below.
If maxcpus=1 is given along with acpi=off then system boots fine. I am not sure
where the problem is.
> The following patches allow for encryption of the on-disk swsusp image
> to prevent data gathering of e.g. in-kernel keys or mlocked data after
> resume.
> For this purpose the aes cipher must be compiled into the kernel as
> module load is not possible at resume time.
> A random key is
On Sat, Apr 09, 2005 at 05:52:32PM -0400, Trond Myklebust wrote:
> lau den 09.04.2005 Klokka 23:35 (+0200) skreiv Jakob Oestergaard:
>
> > 2.6.11.6: (dual PIII 1GHz, 2G RAM, Intel e1000)
> >
> > File Block Num Seq ReadRand Read Seq Write Rand Write
> > DirSize Size
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Btw, does anybody have strong opinions on the license? I didn't put in
> a COPYING file exactly because I was torn between GPLv2 and OSL2.1.
>
> I'm inclined to go with GPLv2 just because it's the most common one,
> but I was wondering if anybody
201 - 300 of 642 matches
Mail list logo
