[EMAIL PROTECTED] wrote:
Linux _will_ write all modified data to permanent storage locations.
Since 2.6.17 it will do this regardless of msync(). Before 2.6.17 you
do need msync() to enable data to be written back.
But it will not start I/O immediately, which is not a requirement in
the standar
On Wed, 28 Mar 2007, Li Yu wrote:
> I also sense this. we may need not such a complete layer at all.
> Although the work of hiddev/rawdev support does not begin, however, as
> the design, especially, let hiddev/rawdev live in HIDAL, I think this
> may need a bit of abstract of transport layer.
Hi,
generic_forget_inode() don't call trancate_inode_pages() if FS is still active
see the 10449 line below:
1040 static void generic_forget_inode(struct inode *inode)
1041 {
1042 struct super_block *sb = inode->i_sb;
1043
1044 if (!hlist_unhashed(&inode->i_hash)) {
1045
Eric W. Biederman wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
It can be done trivially without performing any IO or swap, yes.
Please give me a rough sketch of how to do so.
Reading sparse files is just one I had in mind. But I'm not very
creative compared to university students doing
This disables libata ACPI, among other things.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/ahci.c | 21 +++-
drivers/ata/libata-acpi.c |
Jeff Garzik wrote:
This disables libata ACPI, among other things.
If a -rc6 is possible, that would be quite nice...
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/atl1/atl1_hw.c |1 -
drivers/net/forcedeth.c |8 ++-
drivers/net/mv643xx_et
On Wed, 28 Mar 2007, Wu, Bryan wrote:
> Cool, you are so quick and your patchbomb tool is very efficient.
Yeah, quilt + pine = a deadly combination =)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at htt
Would you take a look at it?
The patch looks fine, similar to mine, I also used a flag when trying
to send a zero attribute to the server, but removed it later to reduce
the number of differences.
I made another small change: The ATTR_READONLY is only cleared if all
writeable bits are set in th
On Wed, 2007-03-28 at 09:24 +0300, Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> As NOMMU does not include fs/revoke.c, we need to provide a stub for
> generic_file_revoke() so that filesystems using it compile.
>
> Cc: Bryan Wu <[EMAIL PROTECTED]>
> Signed-off-by: Pekka Enbe
On Wed, Mar 28, 2007 at 12:13:53PM +0530, Vivek Goyal wrote:
> On Wed, Mar 28, 2007 at 03:18:58PM +0900, Simon Horman wrote:
> > Currently the size of the per-cpu region reserved to save crash
> > notes is set by the per-architecture value MAX_NOTE_BYTES. Which
> > in turn is currently set to 1024
On Sun, Mar 25, 2007 at 07:54:07PM +0400, Oleg Nesterov wrote:
> I am sorry for being completely off-topic, but I've been wondering for the
> long time...
>
> What if we replace raw_spinlock_t.slock with "struct task_struct *owner" ?
>
> void _spin_lock(spinlock_t *lock)
> {
>
On Tue, 2007-03-27 at 01:46 +0800, Jeff Chua wrote:
> On 3/27/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > > It's related. I tested without CONFIG_HPET_TIMER, and now my X60 can
> > > suspend and resume from RAM (s2ram). Even better, it works
> > > with/without CONFIG_NO_HZ.
> >
> > Does t
On Sat, Mar 24, 2007 at 01:41:28PM -0800, Andrew Morton wrote:
> > On Fri, 23 Mar 2007 11:32:44 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > I'm not as concerned about the contended performance of spinlocks
> >
>
> The contended case matters. Back in 2.5.something I screwed up the debug
>
> > +++ linux-2.6/drivers/s390/char/sclp_confmgm.c
>
> Can we get less cyptic name?
Would you like to see sclp_configuration_management.c?
> > +static void sclp_conf_receiver_fn(struct evbuf_header *evbuf)
> > +{
> > + struct conf_mgm_data *cdata;
> > +
> > + cdata = (struct conf_mgm_data *)
Hi,
If a Linux process opens and reads a file A, then it closes the file.
Will Linux keep the file A's data in cache for a while in case another
process opens and reads the same in a short time? I think that is what
I heard before.
But after I digged into the kernel code, I am confused.
When a
On Sat, Mar 24, 2007 at 06:29:59PM +0100, Ingo Molnar wrote:
>
> * Nikita Danilov <[EMAIL PROTECTED]> wrote:
>
> > Indeed, this technique is very well known. E.g.,
> > http://citeseer.ist.psu.edu/anderson01sharedmemory.html has a whole
> > section (3. Local-spin Algorithms) on them, citing pape
On Wed, Mar 28, 2007 at 03:18:58PM +0900, Simon Horman wrote:
> Currently the size of the per-cpu region reserved to save crash
> notes is set by the per-architecture value MAX_NOTE_BYTES. Which
> in turn is currently set to 1024 on all supported architectures.
>
> While testing ia64 I recently di
Michael Ellerman <[EMAIL PROTECTED]> writes:
> It's an arch detail whether MSI irqs need to be masked using the PCI
> MSI registers.
Agreed. It isn't an arch detail that they need to be unmasked in
the pci configuration space.
I assume this patch is motivated just to make arch support easier
an
Michael Ellerman <[EMAIL PROTECTED]> writes:
> The msi descriptors are linked together with what looks a lot like
> a linked list, but isn't a struct list_head list. Make it one.
>
> The only complication is that previously we walked a list of irqs, and
> got the descriptor for each with get_irq_m
Hi all,
The CELF Embedded Linux Conference is less than a month away!
The conference is coming up on April 17, 18, and 19 in San Jose, California.
If you haven't already done so, PLEASE visit the conference website -
http://www.celinux.org/elc2007/ - to check out the session list and
register fo
From: Pekka Enberg <[EMAIL PROTECTED]>
As NOMMU does not include fs/revoke.c, we need to provide a stub for
generic_file_revoke() so that filesystems using it compile.
Cc: Bryan Wu <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
include/linux/fs.h |4
1 file chan
There is a tiny probability that the return value from vtime(time_t *t) is
different than the value stored in *t
Using a temporary variable solves the problem and gives a faster code.
17: 48 85 fftest %rdi,%rdi
1a: 48 8b 05 00 00 00 00mov0(%rip),%rax#
Currently the size of the per-cpu region reserved to save crash
notes is set by the per-architecture value MAX_NOTE_BYTES. Which
in turn is currently set to 1024 on all supported architectures.
While testing ia64 I recently discovered that this value is
in fact too small. The particular setup I wa
Jay Cliburn wrote:
From: Jay Cliburn <[EMAIL PROTECTED]>
The original vendor driver contained a private ether_crc_le() function
that produced an inverted crc. When we changed to the kernel version of
ether_crc_le(), we neglected to undo the inversion. Let's do it now.
Discovered by and patch p
On Mon, 2007-03-26 at 15:12 +0300, Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> There's just no sane way to revoke shared memory mappings for NOMMU so lets
> disable the thing completely when CONFIG_MMU=n.
>
> Cc: Bryan Wu <[EMAIL PROTECTED]>
> Cc: David Howells <[EMAIL PRO
Michael Ellerman <[EMAIL PROTECTED]> writes:
> When freeing an MSI-X in msi_free_irq(), the irq must have already been
> free'd (otherwise we'd hit the BUG_ON), and in the process will have been
> masked or otherwise disabled by the irq chip methods. So there's no
> reason to mask again in the MSI
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Consolidate precondition checks into a single if statement.
Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Add an arch_msi_supported(), which gives archs a chance to check the input
> to pci_enable_msi/x. For MSI-X this routine might need the entry array, so
> pass it in. For plain MSI, NULL is passed, the arch routine needs to cope
> with that. Propagate
On Tue, 2007-03-27 at 23:20 -0600, Eric W. Biederman wrote:
> Michael Ellerman <[EMAIL PROTECTED]> writes:
>
> > I don't think it's that confusing. I agree it was a bit weird that
> > previously it was explicitly checking for < 0, so I fixed that.
>
> The previous case was clearer. This isn't a
On another thought if we want to keep the return code we should
probably rename it pci_msi_verify(). Or something like that
so it is clear we are not asking if it is supported a question
with a boolean answer. But merely verifying that it is supported.
At which point if the verification functio
Michael Ellerman <[EMAIL PROTECTED]> writes:
> I don't think it's that confusing. I agree it was a bit weird that
> previously it was explicitly checking for < 0, so I fixed that.
The previous case was clearer. This isn't a please do some work
for me function, where we expect occasional failure
On Tue, 2007-03-27 at 22:45 -0600, Eric W. Biederman wrote:
> Michael Ellerman <[EMAIL PROTECTED]> writes:
>
> > pci_enable_msi() and pci_enable_msix() both search for the MSI/MSI-X
> > capability, we can fold this into pci_msi_supported() by passing the
> > type in.
> >
> > Update the code to mat
Michael Ellerman <[EMAIL PROTECTED]> writes:
> pci_enable_msi() and pci_enable_msix() both search for the MSI/MSI-X
> capability, we can fold this into pci_msi_supported() by passing the
> type in.
>
> Update the code to match the comment for pci_msi_supported(). That is
> it returns 0 on success,
Michael Ellerman <[EMAIL PROTECTED]> writes:
> We don't need a special cache just for msi descriptors. They're not
> particularly large, under 100 bytes for sure, and don't seem to require any
> special alignment etc. On most systems there will be relatively few MSIs,
> and hence we waste most of
On Tue, Mar 27, 2007 at 02:27:45PM -0400, Jeff Dike wrote:
> These are all 2.6.22 material.
err, I meant 2.6.21...
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Michael Ellerman <[EMAIL PROTECTED]> writes:
> When freeing MSIs and MSI-Xs, we BUG_ON() if the irq has not been
> freed, ie. if it still has an action. We can consolidate all of these
> BUG_ON()s into msi_free_irqs() as all the code paths lead there almost
> immediately anyway.
Acked-by: "Eric W
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Move EXPORT_SYMBOL()s near their definition.
Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger
Michael Ellerman <[EMAIL PROTECTED]> writes:
> For the MSI-X case we do exactly the same logic in pci_disable_msix() and
> msi_remove_pci_irq_vectors(), so consolidate them.
>
> msi_remove_pci_irq_vectors() wasn't setting dev->first_msi_irq to 0, but
> I think it should have been, so the consolida
On Tue, Mar 27, 2007 at 11:17:43PM -0400, Bill Nottingham wrote:
> Kay Sievers ([EMAIL PROTECTED]) said:
> > >If you *do* try to use one of these names, the rename will succeed...
> > >partway. The link in /sys/class/net is renamed, the directory is
> > >not (as it obviously can't rename on top of
On Wed, Mar 28, 2007 at 04:26:05AM +0100, Sid Boyce wrote:
> Eric W. Biederman wrote:
> >Sid Boyce <[EMAIL PROTECTED]> writes:
> >
> >
> >>This is what I've got so far on the first boot, I shall have to check the
> >>manpage for git-bisect again to see if there is anything else to be added,
> >>n
On Wed, Mar 28, 2007 at 02:16:08AM +0100, Matthew Garrett wrote:
> It's ata_read_native_max_address_ext failing, and it's fine if I use
> ahci rather than ata_piix, so I'll just chalk this up to Apple's
> firmware being broken (again) and putting the hardware into some sort of
> "I can't believ
On Tuesday 27 March 2007 23:28, Len Brown wrote:
> Thomas,
>
> Is this failure specific to NO_HZ, and that is why the "nolapic_timer" fix is
> i386 only?
> I'm running 2.6.21-rc5 an nx6325 here in 64-bit mode and I don't see the
> dramatic
> boot failure described earlier in this thread.
>
> Ho
I am not sure where to post this, maybe you can direct me what to do, if
anything.
We have two computers running slackware for amd64 version 11.0.
Tonight we compiled mplayer on each of the systems.
On the first, everything compiled fine--it has a core 2 duo cpu and is
running a stock kernel o
Thomas,
Is this failure specific to NO_HZ, and that is why the "nolapic_timer" fix is
i386 only?
I'm running 2.6.21-rc5 an nx6325 here in 64-bit mode and I don't see the
dramatic
boot failure described earlier in this thread.
However, I have observed that when running on battery,
the LOC falls
BIT macro cleanup,now in bitops.h
Signed-off-by: Milind Arun Choudhary <[EMAIL PROTECTED]>
---
arch/ppc/platforms/chestnut.c |1
drivers/edac/edac_mc.h |2 -
drivers/i2c/busses/i2c-pxa.c| 55 ++--
drivers/net
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Although it might be nice to do a printk before BUG'ing, it's really not
> necessary, and it complicates the code.
>
> The behaviour has changed slightly, in that before we set a flag if the irq
> had an action, and continued freeing the other irqs. B
Eric W. Biederman wrote:
Sid Boyce <[EMAIL PROTECTED]> writes:
This is what I've got so far on the first boot, I shall have to check the
manpage for git-bisect again to see if there is anything else to be added,
nothing enlightening seen so far - further reboots to be done.
I'm a litt
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Although it might be nice to do a printk before BUG'ing, it's really not
> necessary, and it complicates the code.
Acked-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
Kay Sievers ([EMAIL PROTECTED]) said:
> >If you *do* try to use one of these names, the rename will succeed...
> >partway. The link in /sys/class/net is renamed, the directory is
> >not (as it obviously can't rename on top of whatever is already there.)
> >Various networking tools then break in as
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Although it might be nice to do a printk before BUG'ing, it's really not
> necessary, and it complicates the code.
>
> The behaviour has changed slightly, in that before we set a flag if the irq
> had an action, and continued freeing the other irqs. B
Michael Ellerman <[EMAIL PROTECTED]> writes:
> Although it might be nice to do a printk before BUG'ing, it's really not
> necessary, and it complicates the code.
>
Acked-by: Eric W. Biederman <[EMAIL PROTECTED]>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> ---
>
> drivers/pci/msi.c |
On Tuesday 27 March 2007 17:34, johann deneux wrote:
> What about adding a member to ff_effect which would be the number of the
> motor?
> We can't change the layout of ff_effect too much though, so we have to
> find unused bits and put them to work.
>
> For instance, we could replace
>
> __u16
黃建興-Jesse wrote:
> Dear Sirs,
>
> I have got the status.
> I appreciate your contribution to this driver.
> And if anything I can help or any update, please let me know.
Someone needs to send me a signed-off patch.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux
>> Tue, 27 Mar 2007 15:51:39 -0700
>> [Subject: (usagi-core 32652) Re: [linux-usb-devel] [PATCH 0/2] [SERIAL]
>> [USB] fixed to skip NULL entry in struct serial usb_serial_port.]
>> Greg KH <[EMAIL PROTECTED]> wrote...
> > I think so. But I wonder if usb_get_serial_port_data() should check
> >
Andi Kleen wrote:
> init functions should only ever be called from other init functions.
>
> So this should not happen. If it happens the annotations need to be fixed.
>
I've seen some versions of gcc inline weak functions too.
J
-
To unsubscribe from this list: send the line "unsubscribe
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
drivers/char/Kconfig | 33 +
diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 3429ece..d0c978f 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -386,6 +386,39 @@ config AU1000_SERIAL_CON
On Tuesday 27 March 2007 18:16, Len Brown wrote:
> On Tuesday 27 March 2007 17:34, Linus Torvalds wrote:
> >
> > On Tue, 27 Mar 2007, Len Brown wrote:
> > >
> > > I think the only fool-proof way to do this automatically is to
> >
> > Why not just take the known-good CPUID signature?
> >
> > Scre
On Tuesday March 27, [EMAIL PROTECTED] wrote:
> On Tue, Mar 27, 2007 at 11:40:48AM -0700, Phy Prabab wrote:
> > Hello,
> >
> > I am currently running 2.6.21-rc5 and I am seeing quite a bit of this
> > message in my log files:
> > kernel: rpcsvc: received unknown control message:-2144992132/-1
> >
In that case, Bryan may like to know that git, mercurial (IIRC),
and quilt have patchbomb tools. Also GregKH has one somewhere (he
can tell you where). And Paul Jacksone has one at
http://www.speakeasy.org/~pj99/sgi/sendpatchset
Thanks a lot, I will try on my side. And one more question:
On Tue, 2007-03-27 at 08:34 -0700, Randy Dunlap wrote:
> On Tue, 27 Mar 2007 13:40:45 +0800 Wu, Bryan wrote:
>
> > On Mon, 2007-03-26 at 22:27 -0700, Randy Dunlap wrote:
> > > On Tue, 27 Mar 2007 01:17:06 -0400 Mike Frysinger wrote:
> > >
> > > > On 3/27/07, Paul Mundt <[EMAIL PROTECTED]> wrote:
On Mar 27 2007 17:07, Paweł Sikora wrote:
>
> The recent gcc (3.4/4.x) optimizer inlines functions across
> sections which is definitely not we want, e.g. inlining
> functions from .init.text section.
>
> I think, the `__init' macro needs `noinline' attribute and all
An function from the .init se
[ This patch needs to get into 2.6.21, as it fixes a serious bug
introduced soon after 2.6.20 ]
Commit 62f96cb01e8de7a5daee472e540f726db2801499 introduced per-devices
queues and locks, which was fine as far as it went, but left in place
a global which controlled access to submitting requests to th
Marcel Holtmann wrote:
> please don't take the transport layers into account when designing the
> HID bus. They have nothing to do with the upper layer. Especially the
> upper layer shouldn't care at all if the actual HID reports are sent
> over USB or Bluetooth.
>
>
I am sorry for I see this ma
> Linux _will_ write all modified data to permanent storage locations.
> Since 2.6.17 it will do this regardless of msync(). Before 2.6.17 you
> do need msync() to enable data to be written back.
>
> But it will not start I/O immediately, which is not a requirement in
> the standard, or at least
On Mar 27, 2007, at 12:04 PM, Adam Belay wrote:
On Mon, 2007-03-26 at 13:36 +0800, Shaohua Li wrote:
Hi,
On Sat, 2007-03-24 at 03:47 -0400, Adam Belay wrote:
This patch adds the 'menu' governor, as was described in my first
email.
+/**
+ * menu_select - selects the next idle state to en
So I've been putting off this change for awhile since there's been so
much churn in the timekeeping code, but now looking at both -mm and -rt
it seems there is only a minimal amount of timekeeping changes pending,
so I wanted to send this out there for comments before pushing it to -mm
with
On Tue, Mar 27, 2007 at 07:17:49PM +0200, Cornelia Huck wrote:
> On Tue, 27 Mar 2007 11:25:57 +0200,
> "Kay Sievers" <[EMAIL PROTECTED]> wrote:
> > Checking the uevent return value, will not prevent any malfunction,
> > usually this kind of "error handling" just prevents bringing up a
> > whole sub
Herbert Poetzl wrote:
On Sat, Mar 24, 2007 at 12:19:06PM -0800, Andrew Morton wrote:
Or change the reclaim code so that a page which hasn't
been referenced from a process within its hardware
container is considered unreferenced (so it gets reclaimed).
that might easily lead to some pi
Hi Ingo,
At Tue, 27 Mar 2007 21:14:20 +0200,
Ingo Molnar wrote:
>
>
> * Satoru Takeuchi <[EMAIL PROTECTED]> wrote:
>
> > Hi Ingo and all,
> >
> > When I was executing massive interactive processes, I found that some
> > of them occupy CPU time and the others hardly run.
>
> yeah.
>
> > I al
On Wed, Mar 28, 2007 at 01:16:10AM +0100, Matthew Garrett wrote:
> comment seems to be wrong (or, alternatively, it's the
> ata_read_native_max_address_ext call that's failing and returning
> garbage? I'll look into that)
It's ata_read_native_max_address_ext failing, and it's fine if I use
ahc
"Williams, Mitch A" <[EMAIL PROTECTED]> writes:
> Doh! I was reading the code wrong. We only mask if we're still
> handling a previous interrupt on the same vector. My bad.
>
> However, I can't really see where mask() is used outside of that
> instance. Which then leads us back to the question
On Wed, 28 Mar 2007 01:00:24 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Subject: atl1 net driver: problem with sockets
> References : http://lkml.org/lkml/2007/3/21/248
> Submitter : Jose Alberto Reguero <[EMAIL PROTECTED]>
> Patch : http://marc.info/?l=linux-netdev&m=117502041808665
From: Jay Cliburn <[EMAIL PROTECTED]>
The original vendor driver contained a private ether_crc_le() function
that produced an inverted crc. When we changed to the kernel version of
ether_crc_le(), we neglected to undo the inversion. Let's do it now.
Discovered by and patch proffered by Jose Albe
On Wed, Mar 28, 2007 at 01:08:52AM +0100, Matthew Garrett wrote:
> ata3.01: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 0
^
Does this just indicate the lack of an hpa? If so, the
/* if no hpa, both should be equal */
comment
On Fri, Mar 23, 2007 at 07:13:21PM +, Alan Cox wrote:
> For reference this is what I am currently using with 2.6.21-rc4-mm1 and
> it is working for all my test cases so far: Its basically Kyle's patch
> with a libata switch to turn it on/off and some minor fixups from
> the original patch as po
On Mon, Mar 26, 2007 at 07:32:00PM -0400, Robert P. J. Day wrote:
>
> the output from a short script i wrote, locating all CONFIG_
> variables in makefiles that don't appear to exist in any Kconfig file
> anywhere in the source tree.
>
> first, from the drivers/ directory:
>...
> = ZS ===
On Tue, Mar 27, 2007 at 03:44:01PM -0700, Zach Brown wrote:
> The user can generate console output if they cause do_mmap() to fail during
> sys_io_setup(). This was seen in a regression test that does exactly that by
> spinning calling mmap() until it gets -ENOMEM before calling io_setup().
>
> W
On Tuesday 27 March 2007 20:05:24 Pete Zaitcev wrote:
> On Tue, 27 Mar 2007 13:15:14 -0400 (EDT), Alan Stern <[EMAIL PROTECTED]>
> wrote:
>
> > > Suspend to disk still causes "virtual replugging" and I think that
> > > controller is reset and will unplug/replug devices anyway
> > > Resolving th
Andrew Morton wrote:
On Tue, 27 Mar 2007 23:29:34 +0200
Eric Dumazet <[EMAIL PROTECTED]> wrote:
Andrew Morton a écrit :
The wheel spins around, slows then settles on
time-smp-friendly-alignment-of-struct-clocksource.patch!
Presumably because the cacheline_aligned made vsyscall_gt
On Tue, Mar 27, 2007 at 01:03:51PM +0200, Cornelia Huck wrote:
> On Tue, 27 Mar 2007 03:02:51 +0200,
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > This patch removes the PCI_MULTITHREAD_PROBE option that had already
> > been marked as broken.
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED
On Mon, Mar 26, 2007 at 09:38:15AM +0900, Noriaki TAKAMIYA wrote:
> Hi,
>
> >> Sun, 25 Mar 2007 08:55:21 -0700
> >> [Subject: (usagi-core 32640) Re: [linux-usb-devel] [PATCH 0/2] [SERIAL]
> >> [USB] fixed to skip NULL entry in struct serial usb_serial_port.]
> >> Greg KH <[EMAIL PROTECTED]> wrote
On Wednesday, 28 March 2007 01:00, Adrian Bunk wrote:
> This email lists some known regressions in Linus' tree compared to 2.6.20
> with patches available.
>
> If you find your name in the Cc header, you are either submitter of one
> of the bugs, maintainer of an affectected subsystem or driver, a
> > > > > For each fd the information is provided in the following format:
> > > > >
> > > > > pos: 1234
> > > > > flags:012
> > > >
> > > > Octal? Maybe we should use more traditional hex here?
> >
> > It's octal in , so it's easier for a human to read.
> >
> > > Good point. The
+#define pipe_kmap_atomic(page, type) pipe_kmap(page)
+#define pipe_kunmap(page) do { } while (0)
+#define pipe_kunmap_atomic(page, type) do { } while (0)
Please don't drop arguments in stubs. It can let completely broken
code compile, like:
pipe_kunmap(SOME_COMPLETE_
Pavel Machek napisał(a):
> Hi!
>>> There's various fixes here, ranging from some architecture updates (ia64,
>>> ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
>>>
>> Suspend to disk doesn't work for me with this patch. It hangs after
>> PM: Preparing devices for restore.
>> Suspen
We don't need this printk all, just remove it.
("at all". Sigh.)
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux
[PATCH] [qla2xxx] Remove duplicate pci_disable_device() call
On the path qla2x00_probe_one() -> probe_failed -> qla2x00_free_device(),
pci_disable_device() is executed twice, once in qla2x00_free_device()
and once in qla2x00_probe_one().
This patch removes the unnecessary call.
Signed-off-by: B
Adrian Bunk schrieb:
> It's now in Linus' tree.
>
> Thomas (Meyer), are there any regressions left with the latest -git tree
> plus the MSI fix?
>
No, not for me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordo
Randy Dunlap wrote:
> func() or ??
> and what does "nearly ready" mean?
>
Sorry, I forgot to include your doc updates from last time.
"nearly ready" means that its just about to call the function, but
hasn't necessarily done so.
J
-
To u
aio: remove bare user-triggerable error printk
The user can generate console output if they cause do_mmap() to fail during
sys_io_setup(). This was seen in a regression test that does exactly that by
spinning calling mmap() until it gets -ENOMEM before calling io_setup().
We don't need this prin
On Tue, 27 Mar 2007 15:13:29 -0700 Jeremy Fitzhardinge wrote:
> smp_call_function and smp_call_function_single are almost complete
> duplicates of the same logic. This patch combines them by
> implementing them in terms of the more general
> smp_call_function_mask().
>
> [ Jan, Andi: This only c
On Wed, Mar 28, 2007 at 02:22:27AM +0400, Oleg Nesterov wrote:
> On 03/27, Venki Pallipadi wrote:
> >
> > @@ -368,7 +368,7 @@
> >
> > for (;;) {
> > tvec_base_t *prelock_base = timer->base;
> > - base = timer_get_base(timer);
> > + base = tbase_get_base(prelock
Hi!
> > > > For each fd the information is provided in the following format:
> > > >
> > > > pos:1234
> > > > flags: 012
> > >
> > > Octal? Maybe we should use more traditional hex here?
>
> It's octal in , so it's easier for a human to read.
>
> > Good point. The O_foo flags are per
On 03/28, Oleg Nesterov wrote:
>
> looks a little bit ugly, but may be this is just me. How about
>
> void timer_set_base(struct timer_list *timer, struct tvec_t_base_s
> *new_base)
> {
> timer->base = (struct tvec_t_base_s *)
> ((unsigned long)(new
On Tuesday 27 March 2007 17:34, Linus Torvalds wrote:
>
> On Tue, 27 Mar 2007, Len Brown wrote:
> >
> > I think the only fool-proof way to do this automatically is to
>
> Why not just take the known-good CPUID signature?
>
> Screw firmware or ACPI tables. They're going to be occasionally wrong.
Hi!
> >There's various fixes here, ranging from some architecture updates (ia64,
> >ARM, MIPS, SH, Sparc64) to KVM, networking and network drivers.
> >
>
> Suspend to disk doesn't work for me with this patch. It hangs after
> PM: Preparing devices for restore.
> Suspending console(s)
> during resu
On Tue, Mar 27, 2007 at 12:09:13PM +0200, Rafael J. Wysocki wrote:
> On Tuesday, 27 March 2007 03:59, Adrian Bunk wrote:
> > This email lists some known regressions in Linus' tree compared to 2.6.20.
> >
> > If you find your name in the Cc header, you are either submitter of one
> > of the bugs, m
If we're about to enter a prolonged period in which we know we're
going to hold off scheduler ticks, then disable the CPU's softlockup
watchdog for the duration. This avoids having to repeatedly touch the
timestamp, or conversely, risk having the watchdog timeout in the
middle of your long operati
Jeff Garzik <[EMAIL PROTECTED]> :
> Jesse Huang wrote:
> >Dear all:
> >
> >Would someone tell me the current status of IP1000A Linux Driver?
> >Would it be putted into Linux Kernel or not?
>
> I forgot what the status of this was? Didn't it need some cleanups?
More cleanups than what it already
1 - 100 of 334 matches
Mail list logo
