On 01/09/2008 11:11 AM, Jiri Kosina wrote:
On Wed, 9 Jan 2008, Jiri Slaby wrote:
BUG: soft lockup - CPU#1 stuck for 11s! [X:2887]
[ ... ]
Call Trace:
[] __mutex_lock_slowpath+0x38/0xd0
[] mutex_lock+0x1e/0x30
[] input_release_device+0x27/0x50
[] evdev_ungrab+0x3a/0x50
[]
On 01/09/2008 11:11 AM, Jiri Kosina wrote:
On Wed, 9 Jan 2008, Jiri Slaby wrote:
BUG: soft lockup - CPU#1 stuck for 11s! [X:2887]
[ ... ]
Call Trace:
[804e7648] __mutex_lock_slowpath+0x38/0xd0
[804e747e] mutex_lock+0x1e/0x30
[8040c497]
On 01/09/2008 11:11 AM, Jiri Kosina wrote:
On Wed, 9 Jan 2008, Jiri Slaby wrote:
BUG: soft lockup - CPU#1 stuck for 11s! [X:2887]
[ ... ]
Call Trace:
[] __mutex_lock_slowpath+0x38/0xd0
[] mutex_lock+0x1e/0x30
[] input_release_device+0x27/0x50
[] evdev_ungrab+0x3a/0x50
[]
On Wed, 9 Jan 2008, Jiri Slaby wrote:
> BUG: soft lockup - CPU#1 stuck for 11s! [X:2887]
[ ... ]
> Call Trace:
> [] __mutex_lock_slowpath+0x38/0xd0
> [] mutex_lock+0x1e/0x30
> [] input_release_device+0x27/0x50
> [] evdev_ungrab+0x3a/0x50
> [] evdev_release+0xcb/0xd0
> [] __fput+0xc0/0x230
>
Hi,
I got this after resume (finally untainted version):
usb 4-1: new full speed USB device using uhci_hcd and address 14
usb 4-1: configuration #1 chosen from 1 choice
hub 4-1:1.0: USB hub found
hub 4-1:1.0: 3 ports detected
usb 4-1.1: new full speed USB device using uhci_hcd and address 15
Hi,
I got this after resume (finally untainted version):
usb 4-1: new full speed USB device using uhci_hcd and address 14
usb 4-1: configuration #1 chosen from 1 choice
hub 4-1:1.0: USB hub found
hub 4-1:1.0: 3 ports detected
usb 4-1.1: new full speed USB device using uhci_hcd and address 15
On Wed, 9 Jan 2008, Jiri Slaby wrote:
BUG: soft lockup - CPU#1 stuck for 11s! [X:2887]
[ ... ]
Call Trace:
[804e7648] __mutex_lock_slowpath+0x38/0xd0
[804e747e] mutex_lock+0x1e/0x30
[8040c497] input_release_device+0x27/0x50
[804102aa]
On 01/09/2008 11:11 AM, Jiri Kosina wrote:
On Wed, 9 Jan 2008, Jiri Slaby wrote:
BUG: soft lockup - CPU#1 stuck for 11s! [X:2887]
[ ... ]
Call Trace:
[804e7648] __mutex_lock_slowpath+0x38/0xd0
[804e747e] mutex_lock+0x1e/0x30
[8040c497]
on't have -mm tree at hand, check if
> > there's anything affected in these areas. Perhaps somebody tried to pass
> > error values from isofs_iget() and forgot to update callers?
>
> Yep. Unlike 2.6.24-rc5-mm1, 2.6.24-rc6-mm1 has
>
> iget-stop-isofs-from-using-read_inode-
erhaps somebody tried to pass
> error values from isofs_iget() and forgot to update callers?
Yep. Unlike 2.6.24-rc5-mm1, 2.6.24-rc6-mm1 has
iget-stop-isofs-from-using-read_inode-fix-2.patch
iget-stop-isofs-from-using-read_inode-fix-2-update.patch
so hopefully this was all fixed.
--
To unsubscr
error values from isofs_iget() and forgot to update callers?
Yep. Unlike 2.6.24-rc5-mm1, 2.6.24-rc6-mm1 has
iget-stop-isofs-from-using-read_inode-fix-2.patch
iget-stop-isofs-from-using-read_inode-fix-2-update.patch
so hopefully this was all fixed.
--
To unsubscribe from this list: send the line
anything affected in these areas. Perhaps somebody tried to pass
error values from isofs_iget() and forgot to update callers?
Yep. Unlike 2.6.24-rc5-mm1, 2.6.24-rc6-mm1 has
iget-stop-isofs-from-using-read_inode-fix-2.patch
iget-stop-isofs-from-using-read_inode-fix-2-update.patch
so
* David Howells <[EMAIL PROTECTED]> wrote:
> > FWIW, this patch pile is getting ridiculous - it's what, original +
> > 2 fixes in -mm + mine + this one? Could you post the updated patch
> > with all fixes and fixes to fixes folded into it?
>
> I can, though Andrew usually objects to that.
Al Viro <[EMAIL PROTECTED]> wrote:
> My apologies, should've had coffee before posting.
Me too, probably.
> FWIW, this patch pile is getting ridiculous - it's what, original + 2 fixes
> in -mm + mine + this one? Could you post the updated patch with all fixes
> and fixes to fixes folded into
On Fri, Jan 04, 2008 at 12:24:01PM +, David Howells wrote:
> Add some more fixes to ISOFS error handling on top of Al Viro's patch:
>
> (1) Use IS_ERR() rather than ERR_PTR() to test for errors.
*blush*
My apologies, should've had coffee before posting. FWIW, this patch
pile is getting
Al Viro <[EMAIL PROTECTED]> wrote:
> Not enough. isofs_iget() still can return NULL; that needs to be converted to
> ERR_PTR().
>
> BTW, ERR_CAST is there for purpose...
This patch should probably be added on top of that one.
David
---
IGET: Add another couple of fixes to ISOFS error handling
On Fri, Jan 04, 2008 at 07:13:57PM +0800, Dave Young wrote:
> > iget-stop-isofs-from-using-read_inode-fix*
> >
> > Callers in fs/isofs/namei.c are missed.
>
> Yes, some isofs_iget return value should be handled, it is missed.
>
> Maybe this:
Not enough. isofs_iget() still can return NULL;
On Fri, Jan 04, 2008 at 07:13:57PM +0800, Dave Young wrote:
> On Fri, Jan 04, 2008 at 10:47:55AM +, Al Viro wrote:
> > On Thu, Jan 03, 2008 at 03:15:56PM +0100, Jiri Slaby wrote:
> >
> > > Can't say, the DVD seems to be OK, I don't know what was wrong (as I can
> > > say,
> > > this happened
On Fri, Jan 04, 2008 at 10:47:55AM +, Al Viro wrote:
> On Thu, Jan 03, 2008 at 03:15:56PM +0100, Jiri Slaby wrote:
>
> > Can't say, the DVD seems to be OK, I don't know what was wrong (as I can
> > say,
> > this happened several times in the past yet and after reboot everything OK;
> > I
>
On Thu, Jan 03, 2008 at 03:15:56PM +0100, Jiri Slaby wrote:
> Can't say, the DVD seems to be OK, I don't know what was wrong (as I can say,
> this happened several times in the past yet and after reboot everything OK; I
> suspect gnome auto mounter -- multiple machines, several DVD ROMs, same
On Fri, Jan 04, 2008 at 07:13:57PM +0800, Dave Young wrote:
iget-stop-isofs-from-using-read_inode-fix*
Callers in fs/isofs/namei.c are missed.
Yes, some isofs_iget return value should be handled, it is missed.
Maybe this:
Not enough. isofs_iget() still can return NULL; that
On Fri, Jan 04, 2008 at 07:13:57PM +0800, Dave Young wrote:
On Fri, Jan 04, 2008 at 10:47:55AM +, Al Viro wrote:
On Thu, Jan 03, 2008 at 03:15:56PM +0100, Jiri Slaby wrote:
Can't say, the DVD seems to be OK, I don't know what was wrong (as I can
say,
this happened several times
On Fri, Jan 04, 2008 at 10:47:55AM +, Al Viro wrote:
On Thu, Jan 03, 2008 at 03:15:56PM +0100, Jiri Slaby wrote:
Can't say, the DVD seems to be OK, I don't know what was wrong (as I can
say,
this happened several times in the past yet and after reboot everything OK;
I
suspect
On Thu, Jan 03, 2008 at 03:15:56PM +0100, Jiri Slaby wrote:
Can't say, the DVD seems to be OK, I don't know what was wrong (as I can say,
this happened several times in the past yet and after reboot everything OK; I
suspect gnome auto mounter -- multiple machines, several DVD ROMs, same disk
Al Viro [EMAIL PROTECTED] wrote:
Not enough. isofs_iget() still can return NULL; that needs to be converted to
ERR_PTR().
BTW, ERR_CAST is there for purpose...
This patch should probably be added on top of that one.
David
---
IGET: Add another couple of fixes to ISOFS error handling
On Fri, Jan 04, 2008 at 12:24:01PM +, David Howells wrote:
Add some more fixes to ISOFS error handling on top of Al Viro's patch:
(1) Use IS_ERR() rather than ERR_PTR() to test for errors.
*blush*
My apologies, should've had coffee before posting. FWIW, this patch
pile is getting
Al Viro [EMAIL PROTECTED] wrote:
My apologies, should've had coffee before posting.
Me too, probably.
FWIW, this patch pile is getting ridiculous - it's what, original + 2 fixes
in -mm + mine + this one? Could you post the updated patch with all fixes
and fixes to fixes folded into it?
I
On 01/03/2008 02:51 PM, Pekka J Enberg wrote:
> Hi Jiri,
>
> On Thu, 3 Jan 2008, Jiri Slaby wrote:
>> this happened, while playing with broken dvd.
>
> [snip]
>
>> Buffer I/O error on device sr0, logical block 5441
>> end_request: I/O error, dev sr0, sector 136
>> ISOFS: unable to read i-node
On Thu, Jan 03, 2008 at 03:11:20PM +0100, Ingo Molnar wrote:
> and there are about 5 other callsites as well that only check for a NULL
> return.
... except that this is *not* getting NULL or make_bad_inode(); that's
getting ERR_PTR(), which can't happen in mainline. So that looks like
an -mm
* Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> return ERR_PTR(-EACCES);
> }
> + if (is_bad_inode(inode)) {
> + unlock_kernel();
> + iput(inode);
> + return ERR_PTR(-ENOENT);
> +
On Thu, Jan 03, 2008 at 03:51:28PM +0200, Pekka J Enberg wrote:
> Does the following patch fix it?
Highly doubtful, and doesn't deal with the real problem, AFAICS...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Thu, Jan 03, 2008 at 02:23:44PM +0100, Jiri Slaby wrote:
> ISOFS: unable to read i-node block
isofs_read_inode() failing, about to do make_bad_inode()
> Unable to handle kernel NULL pointer dereference at 00ad RIP:
> [] d_splice_alias+0x1f/0x100
struct dentry
Hi Jiri,
On Thu, 3 Jan 2008, Jiri Slaby wrote:
> this happened, while playing with broken dvd.
[snip]
> Buffer I/O error on device sr0, logical block 5441
> end_request: I/O error, dev sr0, sector 136
> ISOFS: unable to read i-node block
> Unable to handle kernel NULL pointer dereference at
Hi,
this happened, while playing with broken dvd.
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
end_request: I/O error, dev sr0, sector 21760
Buffer I/O error on device sr0, logical block 5440
Buffer I/O error on device sr0, logical block 5441
Buffer I/O error on
Hi,
this happened, while playing with broken dvd.
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
end_request: I/O error, dev sr0, sector 21760
Buffer I/O error on device sr0, logical block 5440
Buffer I/O error on device sr0, logical block 5441
Buffer I/O error on
Hi Jiri,
On Thu, 3 Jan 2008, Jiri Slaby wrote:
this happened, while playing with broken dvd.
[snip]
Buffer I/O error on device sr0, logical block 5441
end_request: I/O error, dev sr0, sector 136
ISOFS: unable to read i-node block
Unable to handle kernel NULL pointer dereference at
On Thu, Jan 03, 2008 at 02:23:44PM +0100, Jiri Slaby wrote:
ISOFS: unable to read i-node block
isofs_read_inode() failing, about to do make_bad_inode()
Unable to handle kernel NULL pointer dereference at 00ad RIP:
[802a679f] d_splice_alias+0x1f/0x100
struct dentry
* Pekka J Enberg [EMAIL PROTECTED] wrote:
return ERR_PTR(-EACCES);
}
+ if (is_bad_inode(inode)) {
+ unlock_kernel();
+ iput(inode);
+ return ERR_PTR(-ENOENT);
+ }
On Thu, Jan 03, 2008 at 03:51:28PM +0200, Pekka J Enberg wrote:
Does the following patch fix it?
Highly doubtful, and doesn't deal with the real problem, AFAICS...
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Thu, Jan 03, 2008 at 03:11:20PM +0100, Ingo Molnar wrote:
and there are about 5 other callsites as well that only check for a NULL
return.
... except that this is *not* getting NULL or make_bad_inode(); that's
getting ERR_PTR(), which can't happen in mainline. So that looks like
an -mm
On 01/03/2008 02:51 PM, Pekka J Enberg wrote:
Hi Jiri,
On Thu, 3 Jan 2008, Jiri Slaby wrote:
this happened, while playing with broken dvd.
[snip]
Buffer I/O error on device sr0, logical block 5441
end_request: I/O error, dev sr0, sector 136
ISOFS: unable to read i-node block
Unable
On Thu, 20 Dec 2007 13:22:12 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Dec 2007 15:57:45 -0500
> Rik van Riel <[EMAIL PROTECTED]> wrote:
>
> > 2.6.24-rc5-mm1 seems to have a hang related to the SCSI or block
> > device probing code.
> It
On Thu, 20 Dec 2007 13:22:12 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 20 Dec 2007 15:57:45 -0500
Rik van Riel [EMAIL PROTECTED] wrote:
2.6.24-rc5-mm1 seems to have a hang related to the SCSI or block
device probing code.
It could be a scsi problem, or it could be all
On Fri, 21 Dec 2007 22:51:45 +0100 Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> > Here's a test patch:
>
> Tested on 2.6.23 and 2.6.24-rc5-mm1. The patch fixes the bug.
>
> Thanks a lot to both of you.
Thank you for testing -mm (especially on sparc64) a
gt; >
> > It just blindly goes "vmemmap + pfn" which is asking for trouble, in
> > particular when the physical RAM layout really is sparse.
> >
> > Maybe it's enough to add a pfn_valid() check here? If pfn_valid()
> > means there is a vmemmap translation setup
On Dec 21, 2007 3:00 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Dec 2007 11:06:49 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
>
> > > >
> > > > How do I determine what comes next?
> > > >
> > >
> > > By comparing it with the /proc/iomem from prior to suspending the machine.
> > >
On Fri, 21 Dec 2007 11:06:49 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> > >
> > > How do I determine what comes next?
> > >
> >
> > By comparing it with the /proc/iomem from prior to suspending the machine.
> >
>
> The offending information seems to be "9000-9fff : Intel Flush Page"
On Dec 21, 2007 1:29 AM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> On Fri, 21 Dec 2007 00:58:19 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
>
> > On Dec 20, 2007 12:32 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane <[EMAIL PROTECTED]>
> >
Andrew Morton wrote:
> On Thu, 20 Dec 2007 10:55:51 -0600
> Jason Wessel <[EMAIL PROTECTED]> wrote:
>
>
>> Andrew Morton wrote:
>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
>>>
>>&
Andrew Morton wrote:
On Thu, 20 Dec 2007 10:55:51 -0600
Jason Wessel [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
- git-kgdb.patch is still dropped for the same reason
[snip] Regarding
On Dec 21, 2007 1:29 AM, Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 21 Dec 2007 00:58:19 -0500 Miles Lane [EMAIL PROTECTED] wrote:
On Dec 20, 2007 12:32 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane [EMAIL PROTECTED]
wrote:
On
On Fri, 21 Dec 2007 11:06:49 -0500 Miles Lane [EMAIL PROTECTED] wrote:
How do I determine what comes next?
By comparing it with the /proc/iomem from prior to suspending the machine.
The offending information seems to be 9000-9fff : Intel Flush Page
ah-hah.
On Dec 21, 2007 3:00 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 21 Dec 2007 11:06:49 -0500 Miles Lane [EMAIL PROTECTED] wrote:
How do I determine what comes next?
By comparing it with the /proc/iomem from prior to suspending the machine.
The offending information
, in
particular when the physical RAM layout really is sparse.
Maybe it's enough to add a pfn_valid() check here? If pfn_valid()
means there is a vmemmap translation setup for that page struct too,
it would work.
Here's a test patch:
Tested on 2.6.23 and 2.6.24-rc5-mm1. The patch fixes the bug
On Fri, 21 Dec 2007 22:51:45 +0100 Mariusz Kozlowski [EMAIL PROTECTED] wrote:
Here's a test patch:
Tested on 2.6.23 and 2.6.24-rc5-mm1. The patch fixes the bug.
Thanks a lot to both of you.
Thank you for testing -mm (especially on sparc64) and for reporting
the bug and for testing
On Fri, 21 Dec 2007 00:58:19 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> On Dec 20, 2007 12:32 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On further investigation, "cat /proc/iomem" does not
Resending... Curse GMail's HTML messages!
On Dec 21, 2007 12:58 AM, Miles Lane <[EMAIL PROTECTED]> wrote:
>
> On Dec 20, 2007 12:32 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane <[EMAIL PROTECTED]> wrote:
> >
> > > On further investigation, "cat
From: Matt Mackall <[EMAIL PROTECTED]>
Date: Thu, 20 Dec 2007 19:06:55 -0600
> @@ -707,7 +707,10 @@ static ssize_t kpagecount_read(struct fi
> return -EIO;
>
> while (count > 0) {
> - ppage = pfn_to_page(pfn++);
> + ppage = 0;
> + if
Hi Andrew,
Here are the patches that would be interesting to queue for 2.6.25. As you
asked, the patchset applies to 2.6.24-rc5-mm1.
It includes those logical changes and applies in the following order.
Thanks,
Mathieu
#Text Edit Lock
kprobes-use-mutex-for-insn-pages.patch
kprobes-dont-use
On Thu, Dec 20, 2007 at 04:17:26PM -0800, David Miller wrote:
> From: Mariusz Kozlowski <[EMAIL PROTECTED]>
> Date: Thu, 20 Dec 2007 20:47:55 +0100
>
> > [ 145.128915] TSTATE: 004411009603 TPC: 005119ac TNPC:
> > 005119b0 Y: Not tainted
> > [ 145.128940] TPC:
>
From: Mariusz Kozlowski <[EMAIL PROTECTED]>
Date: Thu, 20 Dec 2007 20:47:55 +0100
> [ 145.128915] TSTATE: 004411009603 TPC: 005119ac TNPC:
> 005119b0 Y: Not tainted
> [ 145.128940] TPC:
My suspicion at this point is that with certain RAM layouts, simply
On Thu, 20 Dec 2007 10:55:51 -0600
Jason Wessel <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
> >
> > - If something goes wrong with a PCI device's probing or initialisati
On Thu, 20 Dec 2007 15:57:45 -0500
Rik van Riel <[EMAIL PROTECTED]> wrote:
> 2.6.24-rc5-mm1 seems to have a hang related to the SCSI or block
> device probing code.
>
> This is on a dual quad-core x86-64 system with megaraid_sas controller.
>
> scsi 0:2:0:0: Direct-Acce
On Thu, 13 Dec 2007 02:40:50 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
2.6.24-rc5-mm1 seems to have a hang related to the SCSI or block
device probing code.
This is on a dual quad-core x86-64 system with megaraid_sas controller.
scsi 0:2:0:0: Direct-Access DELL
Hello,
> > > Actually, you may only need these two:
> > >
> > > > maps4-add-proc-kpagecount-interface.patch
> > > > maps4-add-proc-kpageflags-interface.patch
> >
> > Yes these two were enough, and exporting fs/proc/base.c's
> > mem_lseek().
> >
> > As hard as I try, I can't reproduce this at
On Thu, Dec 20, 2007 at 04:53:59AM -0800, David Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Mon, 17 Dec 2007 08:55:54 -0600
>
> > On Sun, Dec 16, 2007 at 10:39:17PM -0800, Andrew Morton wrote:
> > Actually, you may only need these two:
> >
> > >
On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane <[EMAIL PROTECTED]> wrote:
> On further investigation, "cat /proc/iomem" does not trigger the stack
> trace until after a suspend-to-disk/resume cycle has occurred.
I still can't reproduce this.
Could you please try this?
- cat /proc/iomem
-
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
>
> - If something goes wrong with a PCI device's probing or initialisation, try
> reverting pci-disable-decoding-during-sizing-of-bars.patch.
>
> - git-sch
a patch to re-export
> > > > > drain_local_pages() again and use it for software suspend:
> > > > >
> > > > > Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
> > > > >
> > > > > ---
> > > > > inclu
cessor fan
[ 252.868469]
[ 252.868472] Pid: 7088, comm: head Not tainted (2.6.24-rc5-mm1 #9)
[ 252.868476] EIP: 0060:[] EFLAGS: 00010297 CPU: 0
[ 252.868481] EIP is at r_show+0x2a/0x70
[ 252.868483] EAX: EBX: 0001 ECX: c07e3224 EDX: c04bb034
[ 252.868486] ESI: 0008 EDI: ed1f52c0 EBP: f5
On Dec 20, 2007 6:37 AM, David Howells <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > I would be suspecting iget-stop-procfs-from-using-iget-and-read_inode.patch.
>
> I think your suspicions are very unlikely. The patch only affects
> proc_get_inode() - and looking at
From: Matt Mackall <[EMAIL PROTECTED]>
Date: Mon, 17 Dec 2007 08:55:54 -0600
> On Sun, Dec 16, 2007 at 10:39:17PM -0800, Andrew Morton wrote:
> Actually, you may only need these two:
>
> > maps4-add-proc-kpagecount-interface.patch
> > maps4-add-proc-kpageflags-interface.patch
Yes these two were
Andrew Morton <[EMAIL PROTECTED]> wrote:
> I would be suspecting iget-stop-procfs-from-using-iget-and-read_inode.patch.
I think your suspicions are very unlikely. The patch only affects
proc_get_inode() - and looking at the patch backtrace, it looks like the
system is successfully past that
> > > Okay. The command that directly triggers this is: cat /proc/iomem
> > > [ 252.868386] BUG: unable to handle kernel NULL pointer dereference at
> > > virtual address 0018
> > > [ 252.868481] EIP is at r_show+0x2a/0x70
> > > [ 252.868483] EAX: EBX: 0001 ECX:
On Thu, Dec 20, 2007 at 12:35:51AM -0500, Miles Lane wrote:
> Added Ingo and Russell to the TO list, since they seem to potentially be
> the right people to look into this.
Huh? Don't think so.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
On Thu, Dec 20, 2007 at 12:35:51AM -0500, Miles Lane wrote:
Added Ingo and Russell to the TO list, since they seem to potentially be
the right people to look into this.
Huh? Don't think so.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To
Okay. The command that directly triggers this is: cat /proc/iomem
[ 252.868386] BUG: unable to handle kernel NULL pointer dereference at
virtual address 0018
[ 252.868481] EIP is at r_show+0x2a/0x70
[ 252.868483] EAX: EBX: 0001 ECX: c07e3224 EDX:
Andrew Morton [EMAIL PROTECTED] wrote:
I would be suspecting iget-stop-procfs-from-using-iget-and-read_inode.patch.
I think your suspicions are very unlikely. The patch only affects
proc_get_inode() - and looking at the patch backtrace, it looks like the
system is successfully past that
From: Matt Mackall [EMAIL PROTECTED]
Date: Mon, 17 Dec 2007 08:55:54 -0600
On Sun, Dec 16, 2007 at 10:39:17PM -0800, Andrew Morton wrote:
Actually, you may only need these two:
maps4-add-proc-kpagecount-interface.patch
maps4-add-proc-kpageflags-interface.patch
Yes these two were enough,
On Dec 20, 2007 6:37 AM, David Howells [EMAIL PROTECTED] wrote:
Andrew Morton [EMAIL PROTECTED] wrote:
I would be suspecting iget-stop-procfs-from-using-iget-and-read_inode.patch.
I think your suspicions are very unlikely. The patch only affects
proc_get_inode() - and looking at the patch
[ 252.868469]
[ 252.868472] Pid: 7088, comm: head Not tainted (2.6.24-rc5-mm1 #9)
[ 252.868476] EIP: 0060:[c012d527] EFLAGS: 00010297 CPU: 0
[ 252.868481] EIP is at r_show+0x2a/0x70
[ 252.868483] EAX: EBX: 0001 ECX: c07e3224 EDX: c04bb034
[ 252.868486] ESI: 0008 EDI: ed1f52c0 EBP
-off-by: Christoph Lameter [EMAIL PROTECTED]
---
include/linux/gfp.h |1 +
kernel/power/snapshot.c |2 +-
mm/page_alloc.c |2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6.24-rc5-mm1/kernel/power/snapshot.c
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
- If something goes wrong with a PCI device's probing or initialisation, try
reverting pci-disable-decoding-during-sizing-of-bars.patch.
- git-sched was dropped due to breaking
On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane [EMAIL PROTECTED] wrote:
On further investigation, cat /proc/iomem does not trigger the stack
trace until after a suspend-to-disk/resume cycle has occurred.
I still can't reproduce this.
Could you please try this?
- cat /proc/iomem
-
On Thu, Dec 20, 2007 at 04:53:59AM -0800, David Miller wrote:
From: Matt Mackall [EMAIL PROTECTED]
Date: Mon, 17 Dec 2007 08:55:54 -0600
On Sun, Dec 16, 2007 at 10:39:17PM -0800, Andrew Morton wrote:
Actually, you may only need these two:
maps4-add-proc-kpagecount-interface.patch
Hello,
Actually, you may only need these two:
maps4-add-proc-kpagecount-interface.patch
maps4-add-proc-kpageflags-interface.patch
Yes these two were enough, and exporting fs/proc/base.c's
mem_lseek().
As hard as I try, I can't reproduce this at all. I tried
both on
On Thu, 13 Dec 2007 02:40:50 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
2.6.24-rc5-mm1 seems to have a hang related to the SCSI or block
device probing code.
This is on a dual quad-core x86-64 system with megaraid_sas controller.
scsi 0:2:0:0: Direct-Access DELL PERC 5/i
On Thu, 20 Dec 2007 15:57:45 -0500
Rik van Riel [EMAIL PROTECTED] wrote:
2.6.24-rc5-mm1 seems to have a hang related to the SCSI or block
device probing code.
This is on a dual quad-core x86-64 system with megaraid_sas controller.
scsi 0:2:0:0: Direct-Access DELL PERC 5/i
On Thu, 20 Dec 2007 10:55:51 -0600
Jason Wessel [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc5/2.6.24-rc5-mm1/
- If something goes wrong with a PCI device's probing or initialisation, try
reverting pci-disable
From: Mariusz Kozlowski [EMAIL PROTECTED]
Date: Thu, 20 Dec 2007 20:47:55 +0100
[ 145.128915] TSTATE: 004411009603 TPC: 005119ac TNPC:
005119b0 Y: Not tainted
[ 145.128940] TPC: kpagecount_read+0x94/0xe0
My suspicion at this point is that with certain RAM
On Thu, Dec 20, 2007 at 04:17:26PM -0800, David Miller wrote:
From: Mariusz Kozlowski [EMAIL PROTECTED]
Date: Thu, 20 Dec 2007 20:47:55 +0100
[ 145.128915] TSTATE: 004411009603 TPC: 005119ac TNPC:
005119b0 Y: Not tainted
[ 145.128940] TPC:
Hi Andrew,
Here are the patches that would be interesting to queue for 2.6.25. As you
asked, the patchset applies to 2.6.24-rc5-mm1.
It includes those logical changes and applies in the following order.
Thanks,
Mathieu
#Text Edit Lock
kprobes-use-mutex-for-insn-pages.patch
kprobes-dont-use
From: Matt Mackall [EMAIL PROTECTED]
Date: Thu, 20 Dec 2007 19:06:55 -0600
@@ -707,7 +707,10 @@ static ssize_t kpagecount_read(struct fi
return -EIO;
while (count 0) {
- ppage = pfn_to_page(pfn++);
+ ppage = 0;
+ if
Resending... Curse GMail's HTML messages!
On Dec 21, 2007 12:58 AM, Miles Lane [EMAIL PROTECTED] wrote:
On Dec 20, 2007 12:32 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane [EMAIL PROTECTED] wrote:
On further investigation, cat /proc/iomem does
On Fri, 21 Dec 2007 00:58:19 -0500 Miles Lane [EMAIL PROTECTED] wrote:
On Dec 20, 2007 12:32 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane [EMAIL PROTECTED]
wrote:
On further investigation, cat /proc/iomem does not trigger the stack
trace
vice cfg80211 sky2 battery yenta_socket rsrc_nonstatic
> > pcmcia_core ac snd soundcore snd_page_alloc button shpchp pci_hotplug
> > sr_mod cdrom pata_acpi piix ide_core firewire_ohci firewire_core
> > crc_itu_t thermal processor fan
> > [ 252.868469]
> > [ 252.8684
crc_itu_t thermal processor fan
[ 252.868469]
[ 252.868472] Pid: 7088, comm: head Not tainted (2.6.24-rc5-mm1 #9)
[ 252.868476] EIP: 0060:[] EFLAGS: 00010297 CPU: 0
[ 252.868481] EIP is at r_show+0x2a/0x70
[ 252.868483] EAX: EBX: 0001 ECX: c07e3224 EDX: c04bb034
[ 252.868486] ESI
nd_rawmidi snd_seq_midi_event snd_seq rng_core snd_timer
snd_seq_device shpchp pci_hotplug battery snd ac button soundcore
snd_page_alloc s
r_mod cdrom pata_acpi piix ide_core firewire_ohci firewire_core
crc_itu_t thermal processor fan
[ 54.733915]
[ 54.733918] Pid: 5703, comm: tail Not tainted (2.6.24-
>
> > > > 3. on 2.6.24-rc5 kernel reports only the part 1, after try mount the
> > > > disk it just mount the partition as ro with nothing more messages.
Oh, sorry. It's a typo. should be 2.6.24-rc5-mm1
>
> So which is correct?
>
> > Hi, Alan
> &
by: Christoph Lameter <[EMAIL PROTECTED]>
> > > >
> > > > ---
> > > > include/linux/gfp.h | 1 +
> > > > kernel/power/snapshot.c |2 +-
> > > > mm/page_alloc.c | 2 +-
> > > > 3 files changed, 3 ins
1 - 100 of 299 matches
Mail list logo
