On Tue, Feb 19, 2008 at 09:50:55PM -0800, Greg KH wrote:
> What's the best way to constantly follow this tree? I had cloned it
> a while ago, but now if I 'git pull' it wants to merge things, which
> isn't right.
I would guess:
$ git remote add linux-next
git://git.kernel.org/pub/scm/linux/k
On Thu, Jan 31, 2008 at 07:55:43PM +0200, Adrian Bunk wrote:
> Who was talking about laptops?
If laptops are mostly MP these days, then 'desktops' and 'servers'
certainly are --- so pretty much everyone needs CPU hotplug.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
On Thu, Jan 31, 2008 at 07:14:36PM +0200, Adrian Bunk wrote:
> > cpuhotplug is required for suspend/resume.
>
> Not on UP computers.
those are less and less common now, most modern laptops are dual core
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote:
> Looks like the readdir is in the bowels of the btree code when
> filldir gets called here, there are probably locks on several
> buffers in the btree at this point. This will only show up for large
> directories I bet.
I see it for f
On Sun, Nov 25, 2007 at 04:30:14PM +, Christoph Hellwig wrote:
> The current readdir implementation deadlocks on a btree buffers
> locks because nfsd calls back into ->lookup from the filldir
> callback. The only short-term fix for this is to revert to the old
> inefficient double-buffering s
On Fri, Nov 16, 2007 at 09:19:32AM -0500, Trond Myklebust wrote:
> Very funny, but disabling XFS on the client won't help.
Oops, I meant it for NFSD... and I'm somewhat serious. I'm not
saying it's a good long term solution, but a potentially safer
short-term workaround.
-
To unsubscribe from
On Fri, Nov 16, 2007 at 10:17:17AM +0100, Christian Kujau wrote:
> OK, I'll try this. I hope this can be fixed somehow before 2.6.24...
Well, one simple nasty idea would be something like:
diff --git a/fs/Kconfig b/fs/Kconfig
index 429a002..da231fd 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -16
On Thu, Nov 15, 2007 at 08:51:36AM +0100, Christian Kujau wrote:
> [] mutex_lock_nested+0xcc/0x2c0
> [] do_lookup+0xa4/0x190
> [] __link_path_walk+0x749/0xd10
> [] link_path_walk+0x44/0xc0
> [] path_walk+0x18/0x20
> [] do_path_lookup+0x78/0x1c0
> [] __user_walk_fd+0x38/0x60
> [] vfs_stat_fd+0x21/0
On Tue, Nov 13, 2007 at 11:04:00PM -0800, Chris Wedgwood wrote:
> With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always)
> see a hang when accessing some NFS exported XFS filesystems. Local
> access to these filesystems ahead of time works without problems.
>
> This
With 2.6.24-rc2 (amd64) I sometimes (usually but perhaps not always)
see a hang when accessing some NFS exported XFS filesystems. Local
access to these filesystems ahead of time works without problems.
This does not occur with 2.6.23.1. The filesystem does not appear to
be corrupt.
The call ch
> (to make it easier for people to click)
actually, it's not a tarball either... am I seeing something stale or
perhaps the result of slow 'kernel.org replication?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
On Mon, Sep 24, 2007 at 09:31:48AM -0700, Greg KH wrote:
> A tarball of the patches can be found at:
> kernel.org/pub/linux/kernel/v2.6/stable-testing/patch-2.6.22.8-rc1.gz
^^^
s/testing/review/
http://kernel.org/pub/linux/kernel/v2.6/st
On Thu, Sep 13, 2007 at 10:17:27PM +0200, Oleg Verych wrote:
> That particular one-line `ALTARCH := i386' of course can be matched
> simpler, because there's only *one* (as written above) whitespace and no
> make's assignment variations,
The goal is to extract the RHS from ALTARCH := ...
> Also,
On Thu, Sep 13, 2007 at 08:34:00PM +0200, Sam Ravnborg wrote:
> A few. Please address them and resubmit with full changelog and
> proper attribution (if possible) and a signed-of-by.
sure
> I would strongly prefer the name "build-pkg".
right
> The prefix -pkg is just to use the magic in top-le
This is a somewhat rough first-pass at making a 'minimal tree'
installation target. This installs a partial source-tree which you
can use to build external modules against. It feels pretty unclean
but I'm not aware of a much better way to do some of this.
This patch works for me, even when using
On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
> Are there any architectures still requiring a gcc < 4.0 ?
Yes, sadly in some places (embedded) there are people with older
compiler who want newer kernels.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
On Wed, May 30, 2007 at 02:59:55PM +0200, Michal Marek wrote:
> +typedef struct xfs_fsop_geom_v132 {
wouldn't xfs_fsop_geom_v1_32
^
> + __u32 blocksize; /* filesystem (data) block size */
[...]
> + __u32 dirblocksize; /* directory blo
MODPOST seems to be spewing bogus warnings. It's not clear how best
to fix it so perhaps we should silence it for now?
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 113dc77..bd6fe7b 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -872,6 +872,10 @@ static void
Does this look correct?
diff --git a/fs/nfs/read.c b/fs/nfs/read.c
index 9a55807..7bd7cb9 100644
--- a/fs/nfs/read.c
+++ b/fs/nfs/read.c
@@ -79,7 +79,7 @@ void nfs_readdata_release(void *data)
static
int nfs_return_empty_page(struct page *page)
{
- memclear_highpage_flush(page, 0, PAGE_CA
On Wed, May 09, 2007 at 12:24:32AM +0200, Andi Kleen wrote:
> Somehow yes. But i'm not going to add a useless syscall just to
> shut it up.
It turns out this has come up in other places. Sam has a suggestion
on how to silence this per-arch so I'll post a patch once that change
is in.
-
To unsub
On Wed, May 09, 2007 at 12:13:48AM +0200, Andi Kleen wrote:
> Nope. There already is a getcpu vsyscall. This is not needed.
The kbuild magic that checks for missing syscalls needs to be taught
about this then I take it?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Tue, May 08, 2007 at 11:37:26AM -0700, Chris Wedgwood wrote:
> +#define __NR_getcpu 280
I see something was merged just now that uses 280. Should I resubmit
this using 281 & 282?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
On Wed, May 09, 2007 at 12:03:19AM +0400, Alexey Dobriyan wrote:
> For one, size_t should be printed with %zu.
thanks, i wasn't aware of this
> For two, this is already fixed in mainline.
this was against mainline that wasn't more than an hour old when i
sent the patch
-
To unsubscribe from thi
Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]>
---
net/sunrpc/sched.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/sched.c b/net/sunrpc/sched.c
index 4a53e94..60df3c1 100644
--- a/net/sunrpc/sched.c
+++ b/net/sunrpc/sched.c
@@ -764,7 +764,7 @
Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]>
---
include/asm-x86_64/unistd.h |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/include/asm-x86_64/unistd.h b/include/asm-x86_64/unistd.h
index 26e23e0..aa7d4bf 100644
--- a/include/asm-x86_64/unistd.h
+++ b/inclu
Signed-off-by: Chris Wedgwood <[EMAIL PROTECTED]>
---
drivers/base/dd.c | 13 -
1 files changed, 0 insertions(+), 13 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 92428e5..b0088b0 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -207,19
On Mon, Apr 30, 2007 at 03:56:32PM +1000, David Chinner wrote:
> On Sun, Apr 29, 2007 at 10:25:59PM -0700, Chris Wedgwood wrote:
> IIRC, the argument for FA_ALLOCATE changing file size is that
> posix_fallocate() is supposed to change the file size.
But it's not posix_fallocate;
On Mon, Apr 30, 2007 at 10:47:02AM +1000, David Chinner wrote:
> For FA_ALLOCATE, it's supposed to change the file size if we
> allocate past EOF, right?
I would argue no. Use truncate for that.
> For FA_DEALLOCATE, does it change the filesize at all?
Same as above.
> Or does
> it just punch
On Fri, Apr 27, 2007 at 07:46:13PM +0200, Heiko Carstens wrote:
> If one insists to have fd at first argument, what is wrong with
> having u32 arguments only?
Well, I was one of those who objected as it seems *UGLY* to me.
> It's not that this syscall comes even close to what can be
> considered
On Sun, Apr 08, 2007 at 08:59:03PM -0400, Jeff Garzik wrote:
> >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch
>
> It sounded this was specific to Ingo.
I'm not sure, it sounds a bit like so
On Mon, Apr 02, 2007 at 12:04:56PM -0700, Tom Strader wrote:
> I have seen quite a few posts regarding unable to open an initial
> console, but my system seems to have the necessary things in place
> so I come looking for help.
your rootfs/initramfs/initrd is missing a valid working /dev/console
On Thu, Mar 29, 2007 at 05:21:26PM +0530, Amit K. Arora wrote:
>int fallocate(int fd, loff_t offset, loff_t len, int mode)
Right now there are only two possible values for mode --- it's not
clear what additional values there will be in the future.
How about two syscalls? If we decide later
I hate to comment at this late stage, especially on something that I
think is really a great idea (I did similar more complex, sys_blkalloc
with even more arguments time ago --- I'm glad given how complex this
thread has become I didn't post them now).
In the past there wasn't that much incentive
On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote:
> This patch allows for ibm-acpi to coexist (with diminished
> functionality) with other drivers like ACPI_BAY.
Given the ACP_IBM_BAY implementation is more complete (or seems to be,
please comment if that isn't the case
ACPI_IBM_BAY cannot coexist with ACPI_BAY --- it causes the IBM ACPI
code to fail to initialize so all the IBM ACPI functionality is
missing. The simplest fix is to just make sure the Kconfig magic
disallows ACPI_IBM_BAY when ACPI_BAY is enabled.
Signed-off-by: Chris Wedgwood <[EMAIL PROTEC
On Thu, Jan 18, 2007 at 10:29:14AM +0100, joachim wrote:
> Not only has it only been on Nvidia chipsets but we have only seen
> reports on the Nvidia CK804 SATA controller.
People have reported problems with other controllers. I have one here
I can test given a day or so.
I don't think it's SAT
On Thu, Jan 18, 2007 at 04:00:28AM -0700, Erik Andersen wrote:
> I just tried again and while using iommu=soft does avoid the
> corruption problem, as with previous kernels with 2.6.20-rc5 using
> iommu=soft still makes my pcHDTV HD5500 DVB cards not work.
i would file a separate bug about that,
On Tue, Jan 16, 2007 at 09:31:31PM +0100, Krzysztof Halasa wrote:
> Do you (someone) have (maintain) a list of affected systems,
> including motherboard type and possibly version, BIOS version and
> CPU type? A similar list of unaffected systems with 4GB+ RAM could
> be useful, too.
All I know is
On Tue, Jan 16, 2007 at 08:52:32PM +0100, Christoph Anton Mitterer wrote:
> I agree,... it seems drastic, but this is the only really secure
> solution.
I'd like to here from Andi how he feels about this? It seems like a
somewhat drastic solution in some ways given a lot of hardware doesn't
seem
On Tue, Jan 16, 2007 at 08:26:05AM -0600, Robert Hancock wrote:
> >If one use iommu=soft the sata_nv will continue to use the new code
> >for the ADMA, right?
>
> Right, that shouldn't affect it.
right now i'm thinking if we can't figure out which cpu/bios
combinations are safe we might almost be
On Thu, Dec 14, 2006 at 12:15:20PM -0600, Eric Sandeen wrote:
> Please don't use that name, it strikes me as much more confusing
> than EXPORT_SYMBOL_GPL, even though I agree that _GPL doesn't quite
> convey what it means, either.
Calling internal symbols _INTERNAL is confusing?
> EXPORT_SYMBOL_
On Thu, Dec 14, 2006 at 05:38:27PM +, Christoph Hellwig wrote:
> Yes, EXPORT_SYMBOL_INTERNAL would make a lot more sense.
A quick grep shows that changing this now would require updating
nearly 1900 instances, so patches to do this would be pretty large and
disruptive (though we could support
On Thu, Dec 14, 2006 at 09:03:57AM -0800, Linus Torvalds wrote:
> I actually think the EXPORT_SYMBOL_GPL() thing is a good thing, if
> done properly (and I think we use it fairly well).
>
> I think we _can_ do things where we give clear hints to people that
> "we think this is such an internal Lin
On Wed, Dec 13, 2006 at 09:11:29PM +0100, Christoph Anton Mitterer wrote:
> - error in the Opteron (memory controller)
> - error in the Nvidia chipsets
> - error in the kernel
My guess without further information would be that some, but not all
BIOSes are doing some work to avoid this.
Does anyo
On Wed, Dec 13, 2006 at 08:18:21PM +0100, Christoph Anton Mitterer wrote:
> booting with iommu=soft => works fine
> booting with iommu=noagp => DOESN'T solve the error
> booting with iommu=off => the system doesn't even boot and panics
> When I set IOMMU to disabled in the BIOS the error is not s
On Wed, Dec 13, 2006 at 08:20:59PM +0100, Christoph Anton Mitterer wrote:
> Did anyone made any test under Windows? I cannot set there
> iommu=soft, can I?
Windows never uses the hardware iommu, so it's always doing the
equivalent on iommu=soft
-
To unsubscribe from this list: send the line "unsu
On Mon, Dec 11, 2006 at 10:24:02AM +0100, Karsten Weiss wrote:
> We could not reproduce the data corruption anymore if we boot the
> machines with the kernel parameter "iommu=soft" i.e. if we use
> software bounce buffering instead of the hw-iommu. (As mentioned
> before, booting with mem=2g works
On Wed, Dec 06, 2006 at 12:11:38PM +0100, Christian wrote:
> I copied a massive amount of data (more than 500GB) several times
> between the HDDs and ran md5sum each time, but it found no errors.
It might be a known problem that your BIOS addresses already, or maybe
it's restricted to some revisi
On Sat, Dec 02, 2006 at 01:56:06AM +0100, Christoph Anton Mitterer wrote:
> I found a severe bug mainly by fortune because it occurs very
> rarely. My test looks like the following: I have about 30GB of
> testing data on my harddisk,... I repeat verifying sha512 sums on
> these files and check if
On Fri, Sep 02, 2005 at 02:39:15AM +0200, Adrian Bunk wrote:
> 4Kb kernel stacks are the future on i386, and it seems the problems
> it initially caused are now sorted out.
Not entirely.
XFS when mixed with raid/lvm/nfs still blows up. It's probably not
alone in this respect but worse than ext2
On Thu, Sep 01, 2005 at 12:12:00AM +0200, Jesper Juhl wrote:
> b) add a new boot option telling the kernel the name of some file in
> initrd or similar from which to load additional options.
a file in initrd isn't a good choice; as the initrd is generally a fix
image
the point is some bootloader
On Wed, Aug 31, 2005 at 03:12:58PM -0700, H. Peter Anvin wrote:
> Well, we have initramfs for the really big stuff. The kernel
> shouldn't really need that much data, though.
except the initrd image is in many cases fairly fixed; right now i
have options i pass into initramfs by passing argument
On Wed, Aug 31, 2005 at 03:01:57PM -0700, H. Peter Anvin wrote:
> Maybe not. Another option would simply be to bump it up
> significantly (2x isn't really that much.) 4096, maybe.
I wonder if we're not at the point where we need something different
to what we have now. The concept of a command
On Wed, Aug 31, 2005 at 02:29:44PM -0700, H. Peter Anvin wrote:
> I think someone on the SYSLINUX mailing list already sent a patch to
> akpm to make 512 the default; making it configurable would be a
> better idea. Feel free to send your patch through me.
So we really need this to be a configur
On Sat, Aug 27, 2005 at 10:45:55PM +, Kent Robotti wrote:
> Why don't you do some research on manners?
It was (an obvious) troll. Don't take it so seriously. Besides, deep
deep down I really am a terrible person.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
On Sat, Aug 27, 2005 at 08:19:18AM +, Kent Robotti wrote:
> I know that experience dosen't come from packing the kernel source,
> or the zillion other tar archives on the internet.
Are you deliberately trying to be annoying? Let me guess:
- your under 25 years of age, probably in high sc
On Sat, Aug 27, 2005 at 03:21:27AM +, Kent Robotti wrote:
> The purpose of the patch is to overmount ramfs/rootfs with tmpfs before
> the compressed cpio archive is unpacked and /init is run.
yes and no
there are people who want the overmount even without cpio
decompression
> But, it's only
On Fri, Aug 26, 2005 at 08:08:51PM +, Kent Robotti wrote:
> Overmount_rootfs shouldn't take place until you know for sure the
> kernel detects an initramfs.
Actually, it was a deliberate decision to *always* overmount after
some discussion with people.
It's not a clean solution and the overa
On Thu, Aug 25, 2005 at 08:05:32PM +0100, Alan Jenkins wrote:
> I'm curious as to why the kernel has to include the decoder - why
> you can't just run a self-extracting executable in an empty
> initramfs (with a preset capacity if needs be).
You could do tht right now if you wished.
We just supp
On Thu, Aug 25, 2005 at 11:38:49AM -0400, [EMAIL PROTECTED] wrote:
> What if you have a root.cpio.gz that requires 200MB to hold, but you
> only have 300MB of memory?
then it won't work with nay of the schemes you've suggested
> 50% of total memory wouldn't hold it, but 90% etc. would (tmpfs_siz
On Thu, Aug 25, 2005 at 09:39:15PM -0400, [EMAIL PROTECTED] wrote:
> Wouldn't it be better to put overmount_rootfs in initramfs.c
> and call it only if there's a initramfs?
I don't see what or how that helps. Yes we can shuffle some code
about but the real problem still exists.
That is is that
On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote:
> I don't know, because tar is probably more widely used and
> consequently people are more familiar with how to use it.
As I said before, the cpio format is cleaner/easier to parse in the
kernel. Everyone has cpio probably so us
On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote:
> Right, but it would be nice to have that option if initramfs
> using tmpfs becomes part of the kernel.
But it's not needed so why add bloat?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
On Tue, Aug 23, 2005 at 05:16:05PM -0400, [EMAIL PROTECTED] wrote:
> Also, tar should be an option instead of cpio for the archiver,
> because tar is more widely used.
pretty much everyone will have cpio and it's format is much
simpler/cleaner to deal with
if we want vastly more complex early-us
On Wed, Aug 24, 2005 at 06:41:26PM -0400, [EMAIL PROTECTED] wrote:
> I tried it with kernel 2.6.13-rc5 and it seems to work.
it should yes
> It uses 50% of total memory for tmpfs, but it would be nice to have
> an option (tmpfs_size=90% etc.) that you could pass to the kernel.
that's just becau
On Wed, Aug 24, 2005 at 09:00:21PM -0500, Doug Warzecha wrote:
[...]
> +Dell OpenManage requires this driver on the following Dell PowerEdge systems:
> +300, 1300, 1400, 400SC, 500SC, 1500SC, 1550, 600SC, 1600SC, 650, 1655MC,
> +700, and 750. Other Dell software such as the open source Libsmbios
On Wed, Aug 24, 2005 at 04:52:37PM -0400, Wakko Warner wrote:
> Care to send me the patch?
Heh. Not really as I don't really know if people should be using it
in it's current state --- the shmem init is very very hacky and I have
other changes I've not had a chance to do.
Anyhow, here is an old
On Tue, Aug 23, 2005 at 06:05:47PM -0400, [EMAIL PROTECTED] wrote:
> I was just making a suggestion to whoever it may concern, because I
> think it would extend the usefullness of initramfs.
I have a path for initramfs to use tmpfs. It's sorta hacky so I never
submitted it and solves a niche pro
On Sun, Aug 21, 2005 at 09:56:45PM +0200, Bodo Eggert wrote:
> The parameter value should IMHO be a pointer to a struct {
> unsigned long long maxspeed; // (with 0 being the magic max. value?)
> int facility; /* 0=general speed, 2=general read, 4=read data,
> 6=read audio, 8=re
On Sat, Aug 20, 2005 at 05:33:27PM -0700, [EMAIL PROTECTED] wrote:
> Another annoying problem is that once the system reaches this 2GB
> limit, then every process which exits will receive a signal,
> SIGXFSZ. This signal is generated because an attempt was made to
> write beyond the limit for the
On Thu, Aug 18, 2005 at 11:03:45PM -0700, Howard Chu wrote:
> If the 2.6 kernel makes this programming model unreasonably slow,
> then quite simply this kernel is not viable as a database platform.
Pretty much everyone else manages to make it work.
-
To unsubscribe from this list: send the line "
On Thu, Aug 18, 2005 at 09:28:10AM +0200, Sebastian Cla?en wrote:
> in struct net_device_stats all members are defined as unsgined
> long. In time of gigabit ethernet this takes not long to overflow.
It should still take an appreciable amount of time surely? We can
detect those wraps in userspac
On Sun, Aug 14, 2005 at 09:47:15AM +0100, Christoph Hellwig wrote:
> Looks like people never learn. We had horrible problems with devfs
> because it decided to overload existing name fields, but the udev
> brigade does the same idiocy again..
It's not too late to fix this. We can add a new fiel
On Mon, Aug 15, 2005 at 09:42:37AM -0400, Stephen Frost wrote:
> I also agree and am rather disappointed by this news.
> Unfortunately, I've already bought an A8N-SLI.
If you can send it back citing the driver issues as the reason.
Linux sales are probably a tiny blip on the radar for them so I
On Wed, Aug 17, 2005 at 10:45:48PM +0200, Jesper Juhl wrote:
> It seems slightly odd to me that XFS support should be in a separate
> submenu, when all the other filesystems are not using submenus but
> are directly selectable from the Filesystems menu.
XFS also has an out-of-tree version. Makin
On Tue, Aug 16, 2005 at 12:19:49AM -0500, Michael E Brown wrote:
> Hmm... did I mention libsmbios? :-)
> http://linux.dell.com/libsmbios/main.
I'm aware of it --- it seems pretty limited right now and I'm still
irked Dell isn't more forthcoming with documentation.
> SMI support is not yet implem
On Tue, Aug 16, 2005 at 12:55:35AM -0400, Kyle Moffett wrote:
> I'm worried that it might be more of a mess in userspace than it
> could be if done properly in the kernel.
I would rather if it's gonna be a mess it's, then we put that mess in
userspace rather than in the kernel.
> Hardware driver
On Mon, Aug 15, 2005 at 04:23:37PM -0400, Kyle Moffett wrote:
> Why can't you just implement the system management actions in the
> kernel driver?
Why put things in the kernel unless it's really needed?
I'm not thrillied about the lack of userspace support for this driver
but that still doesn't
On Sun, Aug 14, 2005 at 01:43:22AM +0200, Olaf Hering wrote:
> It is used for /class/misc/$name/dev
Ick. I would almost suggest we change that were it not too late. I
think keeping the decription is useful and desirable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Fri, Jul 29, 2005 at 07:31:20AM +0400, Andrey Borzenkov wrote:
> Mandrake always mounted USB sticks with sync option; it was
> effectively noop except for a patch that implemented limited dsync
> semantic.
fwiw; various people have reported using flash block devices with
'sync' ruins them as t
On Thu, Jul 21, 2005 at 09:20:03AM +0200, J?rn Engel wrote:
> In both cases, what used to be a proper offset in one fd can be
> complete bogus for another one.
Exactly.
Knowing the position within a directory is of questionable value and
trying to implement any reliable semantics for lseek is fu
On Wed, Jul 20, 2005 at 01:21:27PM +0200, J?rn Engel wrote:
> To my understanding, you can lseek to any "proper" offset inside a
> directory. Proper means that the offset marks the beginning of a
> new dirent (or end of file) in the interpretation of the filesystem.
But you can never tell where
On Tue, Jul 19, 2005 at 09:14:04PM +0200, Jan Blunck wrote:
> >So you can seek to m*+ to access an offset into
> >something at depth m?
> >
>
> Yes.
Hos does that work if offset >= m?
> I disagree. Where is the information value of i_size if we always
> could return 0?
Directories clearly can't
On Tue, Jul 19, 2005 at 08:22:26PM +0200, Jan Blunck wrote:
> Since these "arranged" values are also used as the offsets in the
> return dirent IMO it is quite clean.
So the size you want to reflect is n* i take it? Where
in this case n is 20?
So you can seek to m*+ to access an offset into
som
On Tue, Jul 19, 2005 at 11:28:10AM +0200, Jan Blunck wrote:
> I'm using the i_size of directories in my patches. When reading
> from a union directory, I'm using the i_size to seek to the right
> offset in the union stack.
Ick. That'a a bit of a hack.
> Therefore I need values of dirent->d_off
On Tue, Jul 12, 2005 at 06:17:29PM -0500, Doug Warzecha wrote:
> Because the hardware interfaces on those systems and the Dell
> systems management software that access the interfaces are
> proprietary, I can't provide specifications for the interfaces or
> source code for the software.
So you wa
On Fri, Jul 15, 2005 at 11:52:42AM -0700, Linus Torvalds wrote:
> I really think you should update the "simple_xxx()" functions
> instead, and thus make this happen for _any_ filesystem that uses
> the simple fs helper functions.
Why bother at all?
I don't see why zero sizes are a problem. We'v
On Fri, Jul 15, 2005 at 12:33:15PM -0400, Brown, Len wrote:
> So, the 13-year-old design advice will continue to apply to
> 13-year-old systems, but newer systems with C3 and HPET
> should be using them.
Last I looked HPET isn't everywhere yet (absent from nforce4
mainboards for example, but that
On Thu, Jul 14, 2005 at 01:41:44PM -0700, Christoph Lameter wrote:
> AFAIK John simply wants to change jiffies to count in nanoseconds
> since bootup and then call it "clock_monotonic".
Clocks and counter drift so calling it seconds would be
misleading. It would really only be good for approxima
On Wed, Jul 13, 2005 at 04:41:41PM -0700, dean gaudet wrote:
> windows xp base rate is 100Hz... but multimedia apps can ask for
> almost any rate they want (depends on the hw capabilities). i
> recall seeing rates >1200Hz when you launch some of the media player
> apps -- sorry i forget the exact
On Wed, Jul 13, 2005 at 05:24:41PM -0400, Lee Revell wrote:
> Does anyone object to setting HZ at boot? I suspect nothing else
> will make everyone happy.
Does it bloat the code or slow things measurably?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Wed, Jul 13, 2005 at 01:48:57PM -0700, Andrew Morton wrote:
> Len Brown, a year ago: "The bottom line number to laptop users is
> battery lifetime. Just today somebody complained to me that Windows
> gets twice the battery life that Linux does."
It seems the motivation for lower HZ is really:
On Mon, Jul 11, 2005 at 10:05:10AM -0400, Theodore Ts'o wrote:
> The real answer here is for the tickless patches to cleaned up to
> the point where they can be merged, and then we won't waste battery
> power entering the timer interrupt in the first place. :-)
Whilst conceptually this is a nice
On Sat, Jul 09, 2005 at 04:41:16PM +0200, Ingo Molnar wrote:
> this patch pushes the creation of a rare signal frame (SIGBUS or
> SIGSEGV) into a separate function, thus saving stackspace in the
> main do_page_fault() stackframe. The effect is 132 bytes less of
> stack used by the typical do_page_
On Sat, Jul 09, 2005 at 02:49:43PM -0400, Lee Revell wrote:
> BTW, Christoph Lameter, if you're seeing this, your mail is bouncing...
my bad, i typoed it when i first send the original email
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
On Sat, Jul 09, 2005 at 08:31:55PM +0200, Arjan van de Ven wrote:
> it's a config option. Some distros ship 100 already, others 1000,
> again others will do 250.
Who does anything other than 1000 for a 2.6.x kernel?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Fri, Jul 08, 2005 at 03:59:35PM -0700, Martin J. Bligh wrote:
> I think we're talking between 2.6.12-git5 and 2.6.12-git6 right? I
> can confirm more explicitly if really need be. 48s -> 45.5s elapsed.
That's a huge difference (5%) --- what hardware is that on?
-
To unsubscribe from this list:
On Fri, Jul 08, 2005 at 02:59:53PM -0700, Andrew Morton wrote:
> > On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
> ^^
> It's been over two weeks and nobody has complained about anything.
Two weeks isn't that long IMO (I only just noticed myself).
> Bec
On Thu, Jun 23, 2005 at 11:28:47AM -0700, Linux Kernel Mailing List wrote:
> [PATCH] i386: Selectable Frequency of the Timer Interrupt
[...]
> +choice
> + prompt "Timer frequency"
> + default HZ_250
WHAT?
The previous value here i386 is 1000 --- so why is the default 250.
Changing the
On Tue, Jul 05, 2005 at 07:13:34PM -0500, Doug Warzecha wrote:
> This patch adds the Dell Systems Management Base driver.
You keep posting this driver without explaining/showing how it's used.
Could you perhaps give some more details here please?
-
To unsubscribe from this list: send the line "un
1 - 100 of 182 matches
Mail list logo
