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]>
> >
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
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
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 further investigation, "cat /proc/iomem" does not trigger the stack
trace until after a suspend-to-disk/resume cycle has occurred.
I am removing Ingo and Russell from the TO list (as they are apparently
the wrong people) and adding the suspend folks, as suspend is implicated.
My .config
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
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
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
On further investigation, cat /proc/iomem does not trigger the stack
trace until after a suspend-to-disk/resume cycle has occurred.
I am removing Ingo and Russell from the TO list (as they are apparently
the wrong people) and adding the suspend folks, as suspend is implicated.
My .config file
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
-
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
On Thu, 20 Dec 2007 00:35:51 -0500 Miles Lane <[EMAIL PROTECTED]> wrote:
> Added Ingo and Russell to the TO list, since they seem to potentially be
> the right people to look into this.
> .config attached in order to not trip spam filters.
>
> Miles Lane wrote:
> > Okay. The command that
Okay. The command that directly triggers this is: cat /proc/iomem
Here is the stack trace without the line-wrapping (sorry!):
[ 251.602965] wlan0_rename: RX non-WEP frame, but expected encryption
[ 252.868386] BUG: unable to handle kernel NULL pointer dereference at
virtual address
Okay. The command that directly triggers this is: cat /proc/iomem
Here is the stack trace without the line-wrapping (sorry!):
[ 251.602965] wlan0_rename: RX non-WEP frame, but expected encryption
[ 252.868386] BUG: unable to handle kernel NULL pointer dereference at
virtual address
On Thu, 20 Dec 2007 00:35:51 -0500 Miles Lane [EMAIL PROTECTED] wrote:
Added Ingo and Russell to the TO list, since they seem to potentially be
the right people to look into this.
.config attached in order to not trip spam filters.
Miles Lane wrote:
Okay. The command that directly
26 matches
Mail list logo