On Mon, Oct 22 2007, David Miller wrote:
>
> I'm debugging a blk_rq_map_sg() crash that i'm getting on sparc64 as
> root is mounted over IDE. I think I know what is happening now.
>
> The IDE sg table is allocated and initialized like this in
> drivers/ide/ide-probe.c:
>
> x = kmalloc(siz
On Tue, Oct 23, 2007 at 10:36:41AM +1000, David Chinner wrote:
> On Tue, Oct 23, 2007 at 01:35:14AM +0200, Andi Kleen wrote:
> > On Tue, Oct 23, 2007 at 08:32:25AM +1000, David Chinner wrote:
> > > Could vmap()/vunmap() take references to the pages that are mapped? That
> > > way delaying the unmap
On Tue, Oct 23 2007, Jens Axboe wrote:
> On Mon, Oct 22 2007, David Miller wrote:
> >
> > I'm debugging a blk_rq_map_sg() crash that i'm getting on sparc64 as
> > root is mounted over IDE. I think I know what is happening now.
> >
> > The IDE sg table is allocated and initialized like this in
>
Giacomo Catenazzi wrote:
> What do technical and regulatory differences have "driver/LSM module" that
> is build-in and one that is modular?
> It seems to me silly to find difference. A kernel with a new kernel module
> is a new kernel.
>
*I* understand that, from a security and logic integrity
On Tue, Oct 23 2007, FUJITA Tomonori wrote:
> arch/arm/common/dmabounce.c: In function 'dma_map_sg':
> arch/arm/common/dmabounce.c:445: error: implicit declaration of function
> 'sg_page'
Thanks, applied.
--
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On Tue, Oct 23 2007, Olof Johansson wrote:
>
> More fallout from sg_page changes:
>
> drivers/infiniband/hw/ehca/ehca_mrmw.c: In function 'ehca_set_pagebuf_user1':
> drivers/infiniband/hw/ehca/ehca_mrmw.c:1779: error: 'struct scatterlist' has
> no member named 'page'
> drivers/infiniband/hw/ehca
On Tue, 23 Oct 2007 09:09:33 +0200
Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 23 2007, Jens Axboe wrote:
> > On Mon, Oct 22 2007, David Miller wrote:
> > >
> > > I'm debugging a blk_rq_map_sg() crash that i'm getting on sparc64 as
> > > root is mounted over IDE. I think I know what is h
On Mon, Oct 22 2007, Olof Johansson wrote:
> Fix fallout from 18dabf473e15850c0dbc8ff13ac1e2806d542c15:
>
> In file included from include/linux/dma-mapping.h:52,
> from drivers/base/dma-mapping.c:10:
> include/asm/dma-mapping.h: In function 'dma_map_sg':
> include/asm/dma-mapping.
On Tue, Oct 23 2007, Heiko Carstens wrote:
> On Mon, Oct 22, 2007 at 08:10:58PM +0200, Jens Axboe wrote:
> > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
> > ---
>
> You forgot s390's zfcp driver. But unfortunately the trivial fix below
> doesn't work. No more I/O possible. Swen and/or Christof c
Hello list,
there is a typo in the definition of per_cpu_offset because, for ia64,
the __per_cpu_offset is an array.
extern unsigned long __per_cpu_offset[NR_CPUS];
-#define per_cpu_offset(x) (__per_cpu_offset(x))
+#define per_cpu_offset(x) (__per_cpu_offset[x])
Thanks,
Luming
Signed-off-by: Y
On Tue, Oct 23, 2007 at 09:14:07AM +0200, Jens Axboe wrote:
> On Tue, Oct 23 2007, Heiko Carstens wrote:
> > On Mon, Oct 22, 2007 at 08:10:58PM +0200, Jens Axboe wrote:
> > > Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
> > > ---
> >
> > You forgot s390's zfcp driver. But unfortunately the trivia
On Mon, 2007-10-22 at 12:59 +0200, Bernd Schubert wrote:
> On Monday 22 October 2007 12:36:32 Soeren Sonnenburg wrote:
> > On Mon, 2007-10-22 at 11:48 +0200, Bernd Schubert wrote:
> > > Hello,
> > >
> > > On Monday 22 October 2007 04:12:44 Tejun Heo wrote:
> > > > Helo,
> > > > [...]
> > > >
> > >
From: Jens Axboe <[EMAIL PROTECTED]>
Date: Tue, 23 Oct 2007 09:09:33 +0200
> Eh this wont work, it's the wrong entry... Here's a temporary
> work-around.
>
> diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
> index c89f0d3..108202b 100644
> --- a/drivers/ide/ide-io.c
> +++ b/drivers/ide/i
On Mon, 22 Oct 2007, Linus Torvalds wrote:
> On Mon, 22 Oct 2007, Alan Cox wrote:
> > For structures, not array elements or stack objects. Does gcc now get
> > aligned correct as an attribute on a stack object ?
>
> I think m68k stack layout still guarantees 4-byte-alignment, no?
The stack pointe
On 10/22/07, Paul Menage <[EMAIL PROTECTED]> wrote:
>
> Using cgroup_mutex is certainly possible for now, although more
> heavy-weight than I'd like long term. Using css_get isn't the right
> approach, I think - we shouldn't be able to cause an rmdir to fail due
> to a concurrent read.
>
OK, the o
On Tue, Oct 23 2007, FUJITA Tomonori wrote:
> On Tue, 23 Oct 2007 09:09:33 +0200
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Oct 23 2007, Jens Axboe wrote:
> > > On Mon, Oct 22 2007, David Miller wrote:
> > > >
> > > > I'm debugging a blk_rq_map_sg() crash that i'm getting on sparc64 as
On Tue, Oct 23 2007, David Miller wrote:
> From: Jens Axboe <[EMAIL PROTECTED]>
> Date: Tue, 23 Oct 2007 09:09:33 +0200
>
> > Eh this wont work, it's the wrong entry... Here's a temporary
> > work-around.
> >
> > diff --git a/drivers/ide/ide-io.c b/drivers/ide/ide-io.c
> > index c89f0d3..108202b
On Mon, Oct 22 2007, Benny Halevy wrote:
> It looks like it could be nice to define and use a helper for
> page_address(sg_page(sg)) (although 11 call sites could use it
> after this patch)
>
> #define sg_pgaddr(sg) page_address(sg_page(sg))
>
> Note that mips sg_{un,}map_sg checked for page_addr
On Tue, Oct 23 2007, Heiko Carstens wrote:
> From: Heiko Carstens <[EMAIL PROTECTED]>
>
> net/xfrm/xfrm_algo.c: In function 'skb_icv_walk':
> net/xfrm/xfrm_algo.c:555: error: implicit declaration of function
> 'sg_set_page'
> make[2]: *** [net/xfrm/xfrm_algo.o] Error 1
Thanks, arch fallout... Ap
On Tue, Oct 23 2007, FUJITA Tomonori wrote:
> git-drivers/ide/ide-probe.c: In function 'hwif_init':
> drivers/ide/ide-probe.c:1327: error: implicit declaration of function
> 'sg_init_table'
>
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
Applied!
--
Jens Axboe
-
To unsubscribe from thi
On Tue, Oct 23 2007, FUJITA Tomonori wrote:
> arch/parisc/kernel/pci-dma.c: In function 'pa11_dma_map_sg':
> arch/parisc/kernel/pci-dma.c:487: error: 'struct scatterlist' has no member
> named 'page'
> arch/parisc/kernel/pci-dma.c: In function 'pa11_dma_unmap_sg':
> arch/parisc/kernel/pci-dma.c:50
On Tue, Oct 23 2007, FUJITA Tomonori wrote:
> On Tue, 23 Oct 2007 07:04:27 +0200
> Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Oct 23 2007, FUJITA Tomonori wrote:
> > > drivers/pci/intel-iommu.c: In function 'intel_unmap_sg':
> > > drivers/pci/intel-iommu.c:1987: error: 'struct scatterlist
> I guess we can debug it in the old-fashioned ways. The first of which is
> to palm the problem off on Pavel ;)
>
> I don't recall seeing a simple step-by-step way by which others can
> reproduce this?
My method is this:
- enable CONFIG_FUSE_FS
- compile fuse from CVS:
cvs -d:pserver:[EMAIL P
On 10/22/07, Paul Menage <[EMAIL PROTECTED]> wrote:
> On 10/22/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> >
> > Minor nit: From pov of making this patch series git bisect safe, shouldn't
> > we
> > be registering a write_uint() handler in this patch as well?
> >
>
> Yes, we should. Sigh.
From: Jens Axboe <[EMAIL PROTECTED]>
Date: Tue, 23 Oct 2007 09:23:59 +0200
> On Tue, Oct 23 2007, David Miller wrote:
> > From: Jens Axboe <[EMAIL PROTECTED]>
> > Date: Tue, 23 Oct 2007 09:09:33 +0200
> >
> > > Eh this wont work, it's the wrong entry... Here's a temporary
> > > work-around.
> > >
On Tuesday 23 October 2007 16:55:06 Christian Borntraeger wrote:
> Having virtio in Linus tree would make my life easier wiring it up for
> virtualization on s390.
Indeed. And given lguest's lack of interface guarantees, it make sense to use
it as the first virtio guinea pig. I expect changes a
On Tue, Oct 23 2007, David Miller wrote:
> From: Jens Axboe <[EMAIL PROTECTED]>
> Date: Tue, 23 Oct 2007 09:23:59 +0200
>
> > On Tue, Oct 23 2007, David Miller wrote:
> > > From: Jens Axboe <[EMAIL PROTECTED]>
> > > Date: Tue, 23 Oct 2007 09:09:33 +0200
> > >
> > > > Eh this wont work, it's the w
Paul Menage wrote:
> On 10/22/07, Paul Menage <[EMAIL PROTECTED]> wrote:
>> Using cgroup_mutex is certainly possible for now, although more
>> heavy-weight than I'd like long term. Using css_get isn't the right
>> approach, I think - we shouldn't be able to cause an rmdir to fail due
>> to a concur
Hi,
On 10/23/07, Yasunori Goto <[EMAIL PROTECTED]> wrote:
> > "Make kmem_cache_node for SLUB on memory online to avoid panic" introduced
> > the following:
> >
> > mm/slub.c:2737: warning: passing argument 1 of 'atomic_read' from
> > incompatible pointer type
> >
> >
> > Signed-off-by: Olof Johans
On 10/23/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> Well, most people who care about deletion will use the notify_on_release
> callback and retry.
I'm not convinced this is true. Certainly the userspace approaches
we're developing at Google don't (currently) use notify_on_release.
Paul
-
To
This is not a new problem in 2.6.23-git17.
2.6.22/2.6.23 is buggy in the same way.
Reiserfs could leave newly created sub-page-size files in dirty state
for ever. They cannot be synced to disk by pdflush routines or
explicit `sync' commands. Only `umount' can do the trick.
The direct cause is:
Paul Menage wrote:
> On 10/23/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>> Well, most people who care about deletion will use the notify_on_release
>> callback and retry.
>
> I'm not convinced this is true. Certainly the userspace approaches
> we're developing at Google don't (currently) use not
I would like to potentially move the sparc64 IOMMU code over to using
the nice new drivers/pci/iova.[ch] code for free area management..
In order to do that we have to detach the IOMMU page size assumptions
which only really need to exist in the intel-iommu.[ch] code.
This patch attempts to impl
This patch set defines a 32-bit boot protocol for x86 platform, adds
an extensible boot parameter passing mechanism, export the boot
parameters via sysfs.
The patch set has been tested against kernel of git version
v2.6.23-6623-g55b70a0 (with Rusty's git tree pulled) on x86_64 and
i386.
This patc
This patch add a field of 64-bit physical pointer to NULL terminated
single linked list of struct setup_data to real-mode kernel
header. This is used as a more extensible boot parameters passing
mechanism.
Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
---
arch/x86/boot/header.S |6
This patch defines a 32-bit boot protocol and adds corresponding
document. It is based on the proposal of Peter Anvin.
Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
---
boot.txt | 76 +
zero-page.txt | 130 +
This patch export the boot parameters via sysfs. This can be used for
debugging and kexec.
Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
---
Makefile_32 |1
Makefile_64 |1
ksysfs.c| 236
setup64.c |2
setup_32.c
Jeff Garzik wrote:
> Alan Cox wrote:
>>> 2) Once we identified, over time, the set of drives affected by this
>>> 3112 quirk (aka drives that didn't fully comply to SATA spec), the
>>> debugging of corruption cases largely shifted to the standard
>>> routine: update the BIOS, replace the
>>> cables
On 10/23/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> Well, without notify_on_release you can never be sure if a new task
> got added to the control group or if someone acquired a reference
> to it. I can't think of a safe way of removing control groups/cpusets
> without using notify_on_release.
Crispin Cowan wrote:
Giacomo Catenazzi wrote:
What do technical and regulatory differences have "driver/LSM module" that
is build-in and one that is modular?
It seems to me silly to find difference. A kernel with a new kernel module
is a new kernel.
*I* understand that, from a security and
On Mon, Oct 22, Andrew Morton wrote:
> On Mon, 22 Oct 2007 15:57:58 +0200
> Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> >
> > Any reason we've got this patchset posted by three people now? :)
>
> presumably because I haven't been merging it.
>
> I was in bugfix-only mode from a week prior
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Changes since V1:
> Updated to git tree 55b70a0300b873c0ec7ea6e33752af56f41250ce
>
> Various clean ups suggested by Gregory Haskins, Dmitry Adamushko,
> and Peter Zijlstra.
ok, i like this new approach - nice work! I'd suggest we test
On Tue, Oct 23, Bharata B Rao wrote:
> On Mon, Oct 22, 2007 at 03:57:58PM +0200, Christoph Hellwig wrote:
> >
> > Any reason we've got this patchset posted by three people now? :)
>
> Two reasons actually !
>
> - The set of patches posted by Jan last was on 2.6.23-rc8-mm1. So I
> thought let me
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> >> Should we re-add them for the function pointers in
> >> asm-x86/paravirt.h?
> >
> > yes, yes, yes. :-) It was a nightmare to sort it out in -rt (and
> > still is).
>
> Do you have a patch to do this already?
yes, attached. Ack?
In
Miklos Szeredi wrote:
>> I guess we can debug it in the old-fashioned ways. The first of which is
>> to palm the problem off on Pavel ;)
I look at the 2.6.23-mm1 and see that there's one hunk lost. This
is the one Oleg re-sent some days ago (the mail thread subject was
2.6.23-mm1 thread exit_grou
On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
>
>> I do have a pseudo LSM called "multiadm" at
>> http://freshmeat.net/p/multiadm/ , quoting:
>
>> Policy is dead simple since it is based on UIDs. The UID ranges can be
>> set on module load time or during runtime (sysfs params). This LSM is
>>
On Mon, Oct 22, 2007 at 08:48:04PM -0400, Erez Zadok wrote:
> Why? Are you concerned that the security policy may change after a module
> is loaded?
No, it's a matter of proper layering. We generally don't want modules
like stackabke filesystems to call directly into methods but rather use
prope
On Tue, Oct 23, 2007 at 12:00:00AM +0200, Pavel Machek wrote:
> there's nothing to suggest otherwise, and there's explicit:
>
> #define DRIVER_AUTHOR "Jeff Lee<[EMAIL PROTECTED]>"
> #define DRIVER_DESC "IS89C35 802.11bg WLAN USB
> Driver"
> MODULE_LIC
On Oct 22 2007 22:16, Chris Wright wrote:
>>
>> If it turns out that the above module becomes unmaintained and no
>> longer usable, and no other useful cases show up, we can always
>> garbage collect this code in the future; it's now low-overhead
>> anyway for those who care, due to the KConfig o
Hi!
On 10/23/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 23, 2007 at 12:00:00AM +0200, Pavel Machek wrote:
> > there's nothing to suggest otherwise, and there's explicit:
> >
> > #define DRIVER_AUTHOR "Jeff Lee<[EMAIL PROTECTED]>"
> > #define DRIVER_DESC
* Jan Engelhardt ([EMAIL PROTECTED]) wrote:
> On Oct 22 2007 22:16, Chris Wright wrote:
> >Yes, and I think we can still improve performance although I can't see
> >anyway to help out the modular case, so I guess it will have to incur
> >the hit that's always been there. I think your Kconfig optio
On Oct 21 2007 08:57, James Morris wrote:
>> >I'd like to note that I asked people who were actually affected, and had
>> >examples of their real-world use to step forward and explain their use,
>> >and that I explicitly mentioned that this is something we can easily
>> >re-visit.
[...]
I look
On Oct 23 2007 02:13, Chris Wright wrote:
>* Jan Engelhardt ([EMAIL PROTECTED]) wrote:
>> On Oct 22 2007 22:16, Chris Wright wrote:
>> >Yes, and I think we can still improve performance although I can't see
>> >anyway to help out the modular case, so I guess it will have to incur
>> >the hit that'
Jan Engelhardt wrote:
On Oct 23 2007 07:44, Giacomo Catenazzi wrote:
I do have a pseudo LSM called "multiadm" at
http://freshmeat.net/p/multiadm/ , quoting:
Policy is dead simple since it is based on UIDs. The UID ranges can be
set on module load time or during runtime (sysfs params). This LSM
On Mon, Oct 22, 2007 at 10:02:59PM +0400, Oleg Nesterov wrote:
...
> If this work doesn't rearm itself - yes. (otherwise, the same ->func
> can run twice _at the same time_)
>
> But again, in this case wait_on_work() after try_to_grab_pending() == 1
> doesn't block, so we can just do
>
> if
On Oct 23 2007 11:14, Giacomo A. Catenazzi wrote:
>> So, we give caps to the subadmins (which is IMHO a natural task),
>> and then, as per LSM design (wonder where that is written) deny
>> some of the rights that the capabilities raised for subadmins grant,
>> because that is obviously too much.
>
Forwarding this to more public places. :)
-- Forwarded Message --
Subject: b43legacy maintainer needed
Date: Tuesday 23 October 2007
From: Larry Finger <[EMAIL PROTECTED]>
To: Broadcom Linux <[EMAIL PROTECTED]>
As you have seen in a previous E-mail, I have resigned as maintaine
On Tue, Oct 23, 2007 at 10:36:41AM +1000, David Chinner wrote:
> > That doesn't mean it is correct.
>
> Right, but it also points to the fact that it's not causing problems
> from 99.999% of ppl out there.
So you're waiting for someone to take months to debug this again?
> You mean like vmap()
On Mon, Oct 22 2007 at 23:47 +0200, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> On Mon, 22 Oct 2007, Alan Cox wrote:
>
>> For structures, not array elements or stack objects. Does gcc now get
>> aligned correct as an attribute on a stack object ?
>
> I think m68k stack layout still guarantees
On Tue, Oct 23, 2007 at 05:04:14PM +1000, David Chinner wrote:
> On Tue, Oct 23, 2007 at 10:36:41AM +1000, David Chinner wrote:
> > On Tue, Oct 23, 2007 at 01:35:14AM +0200, Andi Kleen wrote:
> > > On Tue, Oct 23, 2007 at 08:32:25AM +1000, David Chinner wrote:
> > > > Could vmap()/vunmap() take ref
Move the calls to the cgroup subsystem destroy() methods from
cgroup_rmdir() to cgroup_diput(). This allows control file reads and
writes to access their subsystem state without having to be concerned
with locking against cgroup destruction - the control file dentry will
keep the cgroup and its sub
Am Dienstag 23 Oktober 2007 schrieb Pete Zaitcev:
> Two main issues fixed here are:
> - An improper use of in-struct lock to protect an open count
> - Use of urb status for -EINPROGRESS
> + /* XXX Anchor these instead */
> + spin_lock_irqsave(&dev->buflock, flags);
> + if (!dev->read
On Tue, Oct 23 2007, Boaz Harrosh wrote:
> On Mon, Oct 22 2007 at 23:47 +0200, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, 22 Oct 2007, Alan Cox wrote:
> >
> >> For structures, not array elements or stack objects. Does gcc now get
> >> aligned correct as an attribute on a stack obje
Linus,
Please pull from
ssh://master.kernel.org/pub/scm/linux/kernel/git/hskinnemoen/avr32-2.6.git
for-linus
to receive the following updates. This is mostly about connecting a few
loose ends that came in through other trees, that is make sure that the
new drivers can actually be used on avr3
Hi David:
> I think this pretty much sums up the situation accurately.
>
> My suggestion is:
>
> 1) Leave the pci_intx() twiddling code in drivers/pci/msi.c
>
> 2) Add quirks for "INTX_DISABLE turns off MSI too", this sets
>a flag in the pci_dev.
>
> 3) The pci_intx() calls in drivers/pci/
Roel Kluin <[EMAIL PROTECTED]> writes:
> unlock 12c_mutex before return -EINVAL
>
> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/media/dvb/dvb-usb/au6610.c
> b/drivers/media/dvb/dvb-usb/au6610.c
> index 18e0b16..31f47c7 100644
> --- a/drivers/media/dvb/d
From: Rob Landley <[EMAIL PROTECTED]>
Add missing section IDs to genericirq.tmpl
Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
---
Either one more showed up in -git since I submitted this, or I missed one.
Documentation/DocBook/genericirq.tmpl | 26
1 file changed,
On Tue, Oct 23 2007 at 11:41 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 23 2007, Boaz Harrosh wrote:
>> On Mon, Oct 22 2007 at 23:47 +0200, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>>> On Mon, 22 Oct 2007, Alan Cox wrote:
>>>
For structures, not array elements or stack objects
From: Rob Landley <[EMAIL PROTECTED]>
Add missing section ID to lsm.tmpl
Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
---
Documentation/DocBook/lsm.tmpl |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -r a868e8217782 Documentation/DocBook/lsm.tmpl
--- a/Documentation/DocBook/ls
From: Rob Landley <[EMAIL PROTECTED]>
Add section IDs to mtdnand.tmpl
Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
---
Documentation/DocBook/mtdnand.tmpl | 58 +--
1 file changed, 29 insertions(+), 29 deletions(-)
diff -r a868e8217782 Documentation/DocBook/mtdnand.t
From: Rob Landley <[EMAIL PROTECTED]>
Add missing IDs to procfs-guide.tmpl
Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
---
Documentation/DocBook/procfs-guide.tmpl | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff -r a868e8217782 Documentation/DocBook/procfs-guide
Hello,
Steen Eugen Poulsen wrote:
> Sep 28 04:32:40 locker ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0
> action 0x2 frozen
> Sep 28 04:32:40 locker ata1.00: cmd b0/d2:f1:00:4f:c2/00:00:00:00:00/00
> tag 0 cdb 0x0 data 123392 in
> Sep 28 04:32:40 locker res 50/00:f1:00:4f:c2/00:00:00:00:00/00 Em
On Tue, Oct 23 2007, Boaz Harrosh wrote:
> On Tue, Oct 23 2007 at 11:41 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > On Tue, Oct 23 2007, Boaz Harrosh wrote:
> >> On Mon, Oct 22 2007 at 23:47 +0200, Linus Torvalds <[EMAIL PROTECTED]>
> >> wrote:
> >>> On Mon, 22 Oct 2007, Alan Cox wrote:
> >>>
From: Rob Landley <[EMAIL PROTECTED]>
Add section IDs to rapidio.tmpl
Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
---
Documentation/DocBook/rapidio.tmpl | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff -r a868e8217782 Documentation/DocBook/rapidio.tmpl
--- a/D
From: Rob Landley <[EMAIL PROTECTED]>
Add table IDs to videobook.tmpl
Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
---
Documentation/DocBook/videobook.tmpl | 34 -
1 file changed, 17 insertions(+), 17 deletions(-)
diff -r a868e8217782 Documentation/DocBook/videobook
From: Rob Landley <[EMAIL PROTECTED]>
Add chapter IDs to z8530book.tmpl
Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
---
Documentation/DocBook/z8530book.tmpl | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff -r 33c949e2f851 Documentation/DocBook/z8530book.tmpl
--- a/D
Jeremy,
CONFIG_XEN (in 2.6.23) depends on X86_CMPXCHG and X86_TSC. This
precludes enabling the option in kernels using M386, M486, or M586, despite
the fact that the detection code doesn't need these features and if Xen is
present the features are implicitly there. At least the X86_TSC dependency
David Miller wrote:
My suggestion is:
1) Leave the pci_intx() twiddling code in drivers/pci/msi.c
2) Add quirks for "INTX_DISABLE turns off MSI too", this sets
a flag in the pci_dev.
3) The pci_intx() calls in drivers/pci/msi.c are skipped if this
flag from #2 is set.
4) Add quirk entri
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Tue, 23 Oct 2007 06:01:17 -0400
> David Miller wrote:
> > My suggestion is:
...
> Sounds good to me also.
Ok, it seems I've sort-of self-nominated myself to implement
this so I'll try to work on it tomorrow :-)
-
To unsubscribe from this list: send the
[PATCH] x86_64: do not clear cpu_index set by store_cpu_info
early_indentify_cpu is called after store_cpu_info.
So don't clear the assigned cpu_index
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index e7a9e36..80ce096 100644
[PATCH] x86_64: set cpu_index to NR_CPUS instead of 0
same BIOS will support two/four dualcore/quadcore system, and will get
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:1 APIC version 16
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:1 APIC version 16
AC
[ adding reiserfs devs to the CC ]
On Tue, 2007-10-23 at 15:55 +0800, Fengguang Wu wrote:
> This is not a new problem in 2.6.23-git17.
> 2.6.22/2.6.23 is buggy in the same way.
>
> Reiserfs could leave newly created sub-page-size files in dirty state
> for ever. They cannot be synced to disk by
[PATCH] x86: typo about sequence of cpu_index and cpu_online in show_cpuinfo
use the real cpu_index instead of 0.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 2d42b41..2196b51 100644
--- a/arch/x86/kernel/cpu/proc.c
+++
On Mon, Oct 22, 2007 at 19:38:10 -0700, Linus Torvalds wrote:
>
> This set of two patches look ok by me, but I'd like sign-offs.. Also, were
> they tested and found to fix the problem by Sami?
>
> Linus
The previous patch I tested by Philippe, oprof-fix-profile_pc-use.patch,
worke
Krzysztof Halasa wrote:
Jeff Garzik <[EMAIL PROTECTED]> writes:
Note that INTX_DISABLE is a recent addition to PCI.
It's PCI 2.3.
Yes.
Older PCI devices
support neither MSI nor INTX-disable, so make sure such devices don't
creep into your sample.
MSI has been introduced by PCI 2.2 (an
Daniel Barkalow wrote:
I have a device that supports MSI and INTX-disable, and, with MSI on (and
delivering interrupts successfully) also sends legacy interrupts (on
the IRQ that is no longer associated with the device) unless INTX is
disabled. Without the intx_disable(), the kernel disables th
On Tuesday 23 October 2007 09:55:14 Fengguang Wu wrote:
> This is not a new problem in 2.6.23-git17.
> 2.6.22/2.6.23 is buggy in the same way.
>
> Reiserfs could leave newly created sub-page-size files in dirty state
> for ever. They cannot be synced to disk by pdflush routines or
> explicit `syn
Fix possible array overflow:
drivers/pci/intel-iommu.c: In function ‘dmar_get_fault_reason’:
drivers/pci/intel-iommu.c:753: warning: array subscript is above array bounds
drivers/pci/intel-iommu.c: In function ‘iommu_page_fault’:
drivers/pci/intel-iommu.c:753: warning: array subscript is above arr
> >> I guess we can debug it in the old-fashioned ways. The first of which is
> >> to palm the problem off on Pavel ;)
>
> I look at the 2.6.23-mm1 and see that there's one hunk lost. This
> is the one Oleg re-sent some days ago (the mail thread subject was
> 2.6.23-mm1 thread exit_group issue).
On Tue, Oct 23 2007 at 11:55 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 23 2007, Boaz Harrosh wrote:
>> On Tue, Oct 23 2007 at 11:41 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
>>> On Tue, Oct 23 2007, Boaz Harrosh wrote:
On Mon, Oct 22 2007 at 23:47 +0200, Linus Torvalds <[EM
On Tue, Oct 23 2007, Boaz Harrosh wrote:
> On Tue, Oct 23 2007 at 11:55 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > On Tue, Oct 23 2007, Boaz Harrosh wrote:
> >> On Tue, Oct 23 2007 at 11:41 +0200, Jens Axboe <[EMAIL PROTECTED]> wrote:
> >>> On Tue, Oct 23 2007, Boaz Harrosh wrote:
> On M
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> It's all about the end goal - having maintainable and resilient code.
> And I think the sg code will be better once we get past the next day
> or so, and it'll be more robust. That is what matters to me, not the
> simplicity of the patch itself.
Linus
On Mon, Oct 22, 2007 at 04:12:06PM +0400, Alexey Dobriyan wrote:
> Steps to reproduce:
>
> modprobe sr_mod
To clarify: this is done during boot sequence.
> rmmod sr_mod
> modprobe sr_mod
This -- by hand.
> BUG: unable to handle kernel paging request at virtual address f881b9f
On Tue, 23 Oct 2007 11:43:14 +0200
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> Subject: [GIT PULL]
Heh, I knew I forgot something. Sorry about that.
Håvard
> Linus,
>
> Please pull from
>
> ssh://master.kernel.org/pub/scm/linux/kernel/git/hskinnemoen/avr32-2.6.git
> for-linus
>
> to r
Fix sctp compile
sctp fails to compile with
net/sctp/sm_make_chunk.c: In function 'sctp_pack_cookie':
net/sctp/sm_make_chunk.c:1516: error: implicit declaration of function
'sg_init_table'
net/sctp/sm_make_chunk.c:1517: error: implicit declaration of function
'sg_set_page'
use the proper inclu
On Tue, 23 Oct 2007 00:43:21 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Jens Axboe <[EMAIL PROTECTED]>
> Date: Tue, 23 Oct 2007 09:23:59 +0200
>
> > On Tue, Oct 23 2007, David Miller wrote:
> > > From: Jens Axboe <[EMAIL PROTECTED]>
> > > Date: Tue, 23 Oct 2007 09:09:33 +0200
> >
> If the pci_intx change will be applied to the SATA driver, can it be
> applied for the ATI USB-HCDs too? See
> http://lkml.org/lkml/2006/12/21/47 for more details. That should help
> most of the ATI MSI quirks. It helped me (Acer Aspire 502x laptop with
> ATI RS480/SB400).
I checked the USB MSI
On Tue, Oct 23 2007, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > It's all about the end goal - having maintainable and resilient code.
> > And I think the sg code will be better once we get past the next day
> > or so, and it'll be more robust. That is what matters to m
Userspace should use getpagesize() or sysconf(_SC_PAGESIZE) to get memory
page size.
man 2 getpagesize:
... Generally, one uses binaries that are architecture but not machine
model dependent, in order to have a single binary distribution per
architecture. This means that a user program should n
On Tue, Oct 23 2007, FUJITA Tomonori wrote:
> On Tue, 23 Oct 2007 00:43:21 -0700 (PDT)
> David Miller <[EMAIL PROTECTED]> wrote:
>
> > From: Jens Axboe <[EMAIL PROTECTED]>
> > Date: Tue, 23 Oct 2007 09:23:59 +0200
> >
> > > On Tue, Oct 23 2007, David Miller wrote:
> > > > From: Jens Axboe <[EMAIL
1 - 100 of 553 matches
Mail list logo
