On 16-09-20, 13:50, Viresh Kumar wrote:
> On 16-09-20, 13:37, Viresh Kumar wrote:
> > On 16-09-20, 09:37, Ulf Hansson wrote:
> > > I have the board as well. If you need some help with testing, just let me
> > > know.
> > >
> > > In any case, I will try the revert and see how that changes things.
On 16-09-20, 13:37, Viresh Kumar wrote:
> On 16-09-20, 09:37, Ulf Hansson wrote:
> > I have the board as well. If you need some help with testing, just let me
> > know.
> >
> > In any case, I will try the revert and see how that changes things.
>
> I am testing this with help of Naresh
On 16-09-20, 09:37, Ulf Hansson wrote:
> I have the board as well. If you need some help with testing, just let me
> know.
>
> In any case, I will try the revert and see how that changes things.
I am testing this with help of Naresh currently, will try to update
back today itself.
--
viresh
l-config:
> > > https://builds.tuxbuild.com/J5oDTkph2aj855oeGOd45Q/kernel.config
> > >
> > >
> > > crash log:
> > > -
> > > [ 3.517615] Synopsys Designware Multimedia Card Interface Driver
> > > [3.524258] sdhci-pltfm: SD
> > -
> > [3.517615] Synopsys Designware Multimedia Card Interface Driver
> > [3.524258] sdhci-pltfm: SDHCI platform and OF driver helper
> > [3.531302] Unable to handle kernel paging request at virtual
> > address dead0108
> >
/J5oDTkph2aj855oeGOd45Q/kernel.config
crash log:
-
[3.517615] Synopsys Designware Multimedia Card Interface Driver
[3.524258] sdhci-pltfm: SDHCI platform and OF driver helper
[3.531302] Unable to handle kernel paging request at virtual
address dead0108
[3.531396
SDHCI platform and OF driver helper
> [ 3.531302] Unable to handle kernel paging request at virtual
> address dead0108
> [3.531396] Mem abort info:
> [3.531460] sdhci_msm 7864900.sdhci: Got CD GPIO
> [3.539182] ESR = 0x9644
> [3.541953] ledtrig-cpu:
On 28-08-20, 14:23, Ulf Hansson wrote:
> Anders, Naresh - thanks for testing and reporting. I am dropping the
> patch from my tree.
>
> Viresh, I suggest to keep Anders/Naresh in the cc, for the next
> version. Then I can wait for their tested-by tag before I apply again.
Sorry for the trouble,
On Fri, 28 Aug 2020 at 12:29, Anders Roxell wrote:
>
> On Fri, 28 Aug 2020 at 11:35, Ulf Hansson wrote:
> >
> > On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju
> > wrote:
> > >
> > > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> > > wrote:
> > > >
> > > > On Thu, 27 Aug 2020 at 15:42, Viresh
On Fri, 28 Aug 2020 at 11:35, Ulf Hansson wrote:
>
> On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju
> wrote:
> >
> > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> > wrote:
> > >
> > > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar
> > > wrote:
> > > >
> > > > On 27-08-20, 11:48, Arnd Bergmann
On Fri, 28 Aug 2020 at 15:05, Ulf Hansson wrote:
>
> On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju
> wrote:
> >
> > On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> > wrote:
> > >
> > > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar
> > > wrote:
> > > >
> > > > On 27-08-20, 11:48, Arnd Bergmann
On Fri, 28 Aug 2020 at 11:22, Naresh Kamboju wrote:
>
> On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju
> wrote:
> >
> > On Thu, 27 Aug 2020 at 15:42, Viresh Kumar wrote:
> > >
> > > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > > >
On Thu, 27 Aug 2020 at 17:06, Naresh Kamboju wrote:
>
> On Thu, 27 Aug 2020 at 15:42, Viresh Kumar wrote:
> >
> > On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > > [3.683431] sdhci_msm_probe+0x284/0x9a0
> > >
> > >
On Thu, 27 Aug 2020 at 15:42, Viresh Kumar wrote:
>
> On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > > [3.683431] sdhci_msm_probe+0x284/0x9a0
> >
> > dev_pm_opp_put_clkname() is part of the error handling in the
> > probe function, so
On 27-08-20, 11:48, Arnd Bergmann wrote:
> > > [3.680477] dev_pm_opp_put_clkname+0x30/0x58
> > > [3.683431] sdhci_msm_probe+0x284/0x9a0
>
> dev_pm_opp_put_clkname() is part of the error handling in the
> probe function, so I would deduct there are two problems:
>
> - something failed
roller Interface driver
> > [3.493508] sdhci: Copyright(c) Pierre Ossman
> > [3.500902] Synopsys Designware Multimedia Card Interface Driver
> > [3.507441] sdhci-pltfm: SDHCI platform and OF driver helper
> > [3.514308] Unable to handle kernel paging request at vir
.493508] sdhci: Copyright(c) Pierre Ossman
> [3.500902] Synopsys Designware Multimedia Card Interface Driver
> [ 3.507441] sdhci-pltfm: SDHCI platform and OF driver helper
> [3.514308] Unable to handle kernel paging request at virtual
> address dead0108
> [3.514695
tx channel not available
> [3.493455] sdhci: Secure Digital Host Controller Interface driver
> [3.493508] sdhci: Copyright(c) Pierre Ossman
> [3.500902] Synopsys Designware Multimedia Card Interface Driver
> [ 3.507441] sdhci-pltfm: SDHCI platform and OF driver helper
Card Interface Driver
[3.507441] sdhci-pltfm: SDHCI platform and OF driver helper
[3.514308] Unable to handle kernel paging request at virtual
address dead0108
[3.514695] Mem abort info:
[3.522421] ESR = 0x9644
[3.525096] EC = 0x25: DABT (current EL), IL = 32 bits
ftrace_buffer_size_kb.sh: line 33: echo: write error: Cannot allocate memory
[ 55.868262] Unable to handle kernel paging request at virtual
address 800036ac1000
[ 55.868317] Mem abort info:
[ 55.874729] Exception class = DABT (current EL), IL = 32 bits
[ 55.877427] SET = 0, FnV = 0
[ 55.883323
On Wed, 1 Jul 2020 at 13:49, Michal Hocko wrote:
>
> On Wed 01-07-20 13:24:54, Naresh Kamboju wrote:
> > While running LTP mm test suite on arm64 Juno device the kernel panic
> > noticed on linux-next 20200630 tag.
>
> Can you try to bisect? The new memcg slab allocator series sounds like a
>
On Wed 01-07-20 13:24:54, Naresh Kamboju wrote:
> While running LTP mm test suite on arm64 Juno device the kernel panic
> noticed on linux-next 20200630 tag.
Can you try to bisect? The new memcg slab allocator series sounds like a
potential candidate. One of the patches has changed the memcg
: 4096
thp01.c:81: INFO: left: 0, right: 2048, mid: 2048
thp01.c:81: INFO: left: 1024, right: 2048, mid: 1024
[ 321.974581] Unable to handle kernel paging request at virtual
address 80096d78f000
[ 321.982517] Mem abort info:
[ 321.985309] ESR = 0x9605
[ 321.988378] EC = 0x25: DABT
On Thu, 14 May 2020 at 22:01, Mike Kravetz wrote:
>
> On 5/13/20 11:40 PM, Michal Hocko wrote:
> > On Wed 13-05-20 23:11:40, Naresh Kamboju wrote:
> >> While running libhugetlbfs fallocate_stress.sh on stable-rc 5.4 branch
> >> kernel
> >> on arm64 hikey device. The following kernel Internal
On 5/13/20 11:40 PM, Michal Hocko wrote:
> On Wed 13-05-20 23:11:40, Naresh Kamboju wrote:
>> While running libhugetlbfs fallocate_stress.sh on stable-rc 5.4 branch kernel
>> on arm64 hikey device. The following kernel Internal error: Oops:
>> crash dump noticed.
>
> Is the same problem
e
patches?
>
> fallocate_stress.sh (2M: 64):
> [ 129.706506] Unable to handle kernel paging request at virtual
> address 6772f000
> [ 129.714638] Mem abort info:
> [ 129.717553] ESR = 0x9647
> [ 129.720726] EC = 0x25: DABT (current EL), IL = 32 bits
>
While running libhugetlbfs fallocate_stress.sh on stable-rc 5.4 branch kernel
on arm64 hikey device. The following kernel Internal error: Oops:
crash dump noticed.
fallocate_stress.sh (2M: 64):
[ 129.706506] Unable to handle kernel paging request at virtual
address 6772f000
[ 129.714638
h64-linux-gnu, the bug does disappear.
Thanks for your help!
>
>
>> Unable to handle kernel paging request at virtual address 44d0
>> pgd = ffc0007fb000
>> [44d0] *pgd=79407003, *pud=79407003,
>> *pmd=79408003, *pte=006008004707
>&g
mpiler bug when generating code for
smp_load_acquire() (see below); what compiler are you using?
> Unable to handle kernel paging request at virtual address 44d0
> pgd = ffc0007fb000
> [44d0] *pgd=79407003, *pud=79407003,
> *pmd=79408003, *pte=006000
Hi Guys,
Just found the following oops during kernel booting when I
test the latest linus tree on one arm64 VM booted from uefi
plus grub2:
Unable to handle kernel paging request at virtual address 44d0
pgd = ffc0007fb000
[44d0] *pgd=79407003, *pud=79407003,
*pmd
!
Unable to handle kernel paging request at virtual address 44d0
pgd = ffc0007fb000
[44d0] *pgd=79407003, *pud=79407003,
*pmd=79408003, *pte=006008004707
Internal error: Oops: 9405 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 632 Comm: kworker/1
Hi Guys,
Just found the following oops during kernel booting when I
test the latest linus tree on one arm64 VM booted from uefi
plus grub2:
Unable to handle kernel paging request at virtual address 44d0
pgd = ffc0007fb000
[44d0] *pgd=79407003, *pud=79407003,
*pmd
generating code for
smp_load_acquire() (see below); what compiler are you using?
Unable to handle kernel paging request at virtual address 44d0
pgd = ffc0007fb000
[44d0] *pgd=79407003, *pud=79407003,
*pmd=79408003, *pte=006008004707
Internal error: Oops
velopment tree.
None of the above helped anything.
Here's a log (2.6.23.12, no X running, Avermedia EZCapture card;
capturing for several hours, then stopping, then capturing again - crash!):
--
BUG: unable to handle kernel paging request at virtual address 968e8787
printing eip:
c017
EZCapture card;
capturing for several hours, then stopping, then capturing again - crash!):
--
BUG: unable to handle kernel paging request at virtual address 968e8787
printing eip:
c017dc67
*pde =
Oops: 0002 [#1]
PREEMPT SMP
Modules linked in: bttv video_buf ir_common compat_ioctl32
On Sun, 6 Jan 2008 00:20:50 +0300
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> netconsole should be more quick:
Thanks a lot for the tip, I'll try that.
Alexander
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Sun, Jan 06, 2008 at 12:30:34AM +0400, Alexander Shaduri wrote:
> > Get a serial console? Take another box, plug e.g. pl2303-based
> > usb-to-serial (several bucks these days) into it, stick null-modem
> > convertor (ditto) on its serial end and attach to ttyS0 on the
> > victim.
> Get a serial console? Take another box, plug e.g. pl2303-based
> usb-to-serial (several bucks these days) into it, stick null-modem
> convertor (ditto) on its serial end and attach to ttyS0 on the
> victim. console=ttyS0 on victim, something like minicom on watcher
> and tell it to capture
On Sat, Jan 05, 2008 at 06:46:56PM +0400, Alexander Shaduri wrote:
> On Sat, 5 Jan 2008 15:34:25 +0100
> Mikael Pettersson <[EMAIL PROTECTED]> wrote:
>
> > This kernel is tainted by the nvidia module...
>
> I know that, but as I wrote in the original message, the hangs occur
> without it too.
>
On Sat, 5 Jan 2008 15:34:25 +0100
Mikael Pettersson <[EMAIL PROTECTED]> wrote:
> This kernel is tainted by the nvidia module...
I know that, but as I wrote in the original message, the hangs occur
without it too.
I just tested it today. Had to leave it running
(in vesa framebuffer mode), without
> bttv0: OCERR @ 375e2014,bits: HSYNC OFLOW FBUS FDSR OCERR*
> BUG: unable to handle kernel paging request at virtual address 23232323
> printing eip:
> c011d6f8
> *pde =
> Oops: [#1]
> PREEMPT SMP
> Modules linked in: ppp_generic slhc iptable_filter ip_
put of dmesg:
bttv0: OCERR @ 375e2014,bits: HSYNC OFLOW FDSR OCERR*
(two pages of the same message here)
bttv0: OCERR @ 375e2014,bits: HSYNC OFLOW FDSR OCERR*
bttv0: OCERR @ 375e2014,bits: HSYNC OFLOW FBUS FDSR OCERR*
BUG: unable to handle kernel paging request at virtual address 23232323
printing eip:
c0
On Fri, Jan 04, 2008 at 09:38:12PM +0400, Alexander Shaduri wrote:
>
> I got the following message, shortly followed by a system hang.
> BUG: unable to handle kernel paging request at virtual address 48464443
>
> (see the oops below).
AFAICS, it's quicklist_alloc() called
On Fri, Jan 04, 2008 at 09:38:12PM +0400, Alexander Shaduri wrote:
I got the following message, shortly followed by a system hang.
BUG: unable to handle kernel paging request at virtual address 48464443
(see the oops below).
AFAICS, it's quicklist_alloc() called from pgd_alloc():
static
: HSYNC OFLOW FDSR OCERR*
(two pages of the same message here)
bttv0: OCERR @ 375e2014,bits: HSYNC OFLOW FDSR OCERR*
bttv0: OCERR @ 375e2014,bits: HSYNC OFLOW FBUS FDSR OCERR*
BUG: unable to handle kernel paging request at virtual address 23232323
printing eip:
c011d6f8
*pde =
Oops:
).
Output of dmesg:
bttv0: OCERR @ 375e2014,bits: HSYNC OFLOW FDSR OCERR*
(two pages of the same message here)
bttv0: OCERR @ 375e2014,bits: HSYNC OFLOW FDSR OCERR*
bttv0: OCERR @ 375e2014,bits: HSYNC OFLOW FBUS FDSR OCERR*
BUG: unable to handle kernel paging request at virtual
On Sat, 5 Jan 2008 15:34:25 +0100
Mikael Pettersson [EMAIL PROTECTED] wrote:
This kernel is tainted by the nvidia module...
I know that, but as I wrote in the original message, the hangs occur
without it too.
I just tested it today. Had to leave it running
(in vesa framebuffer mode), without
On Sat, Jan 05, 2008 at 06:46:56PM +0400, Alexander Shaduri wrote:
On Sat, 5 Jan 2008 15:34:25 +0100
Mikael Pettersson [EMAIL PROTECTED] wrote:
This kernel is tainted by the nvidia module...
I know that, but as I wrote in the original message, the hangs occur
without it too.
I just
On Sun, Jan 06, 2008 at 12:30:34AM +0400, Alexander Shaduri wrote:
Get a serial console? Take another box, plug e.g. pl2303-based
usb-to-serial (several bucks these days) into it, stick null-modem
convertor (ditto) on its serial end and attach to ttyS0 on the
victim. console=ttyS0 on
On Sun, 6 Jan 2008 00:20:50 +0300
Alexey Dobriyan [EMAIL PROTECTED] wrote:
netconsole should be more quick:
Thanks a lot for the tip, I'll try that.
Alexander
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
I got the following message, shortly followed by a system hang.
BUG: unable to handle kernel paging request at virtual address 48464443
(see the oops below).
I've been getting kernel oopses for quite some time now, ever since I
got a new computer (several months now).
The problem manifests
I got the following message, shortly followed by a system hang.
BUG: unable to handle kernel paging request at virtual address 48464443
(see the oops below).
I've been getting kernel oopses for quite some time now, ever since I
got a new computer (several months now).
The problem manifests
Rafael J. Wysocki wrote:
On Tuesday, 4 of December 2007, Giacomo A. Catenazzi wrote:
Ingo Molnar wrote:
hi,
* Giacomo Catenazzi <[EMAIL PROTECTED]> wrote:
On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at
virtual address 3d15b925
In last git, I see the followin
Rafael J. Wysocki wrote:
On Tuesday, 4 of December 2007, Giacomo A. Catenazzi wrote:
Ingo Molnar wrote:
hi,
* Giacomo Catenazzi [EMAIL PROTECTED] wrote:
On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at
virtual address 3d15b925
In last git, I see the following BUGs
On Tuesday, 4 of December 2007, Giacomo A. Catenazzi wrote:
> Ingo Molnar wrote:
> > hi,
> >
> > * Giacomo Catenazzi <[EMAIL PROTECTED]> wrote:
> >
> >> On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at
> >> vi
Ingo Molnar wrote:
hi,
* Giacomo Catenazzi <[EMAIL PROTECTED]> wrote:
On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at
virtual address 3d15b925
In last git, I see the following BUGs in various programs. It seems
reproducible, but sometime I've hard lookup on po
hi,
* Giacomo Catenazzi <[EMAIL PROTECTED]> wrote:
> On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at
> virtual address 3d15b925
>
> In last git, I see the following BUGs in various programs. It seems
> reproducible, but sometime I've hard lookup
hi,
* Giacomo Catenazzi [EMAIL PROTECTED] wrote:
On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at
virtual address 3d15b925
In last git, I see the following BUGs in various programs. It seems
reproducible, but sometime I've hard lookup on poweroff.
do you still
Ingo Molnar wrote:
hi,
* Giacomo Catenazzi [EMAIL PROTECTED] wrote:
On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at
virtual address 3d15b925
In last git, I see the following BUGs in various programs. It seems
reproducible, but sometime I've hard lookup on poweroff
On Tuesday, 4 of December 2007, Giacomo A. Catenazzi wrote:
Ingo Molnar wrote:
hi,
* Giacomo Catenazzi [EMAIL PROTECTED] wrote:
On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at
virtual address 3d15b925
In last git, I see the following BUGs in various
Andrew Morton wrote:
> On Tue, 23 Oct 2007 21:04:20 +0200 Giacomo Catenazzi <[EMAIL PROTECTED]>
> wrote:
>
>> Oct 23 20:20:05 catee kernel: BUG: unable to handle kernel paging request at
>> virtual address 92184900
>
> Is this still happening in the latest Li
On Tue, 23 Oct 2007 21:04:20 +0200 Giacomo Catenazzi <[EMAIL PROTECTED]> wrote:
> Hello people,
>
> I've still some kernel bug
>
> ciao
> cate
>
> Oct 23 20:20:05 catee kernel: BUG: unable to handle kernel paging request at
> virtual address 921849
On Tue, 23 Oct 2007 21:04:20 +0200 Giacomo Catenazzi [EMAIL PROTECTED] wrote:
Hello people,
I've still some kernel bug
ciao
cate
Oct 23 20:20:05 catee kernel: BUG: unable to handle kernel paging request at
virtual address 92184900
Oct 23 20:20:05 catee kernel: printing eip
Andrew Morton wrote:
On Tue, 23 Oct 2007 21:04:20 +0200 Giacomo Catenazzi [EMAIL PROTECTED]
wrote:
Oct 23 20:20:05 catee kernel: BUG: unable to handle kernel paging request at
virtual address 92184900
Is this still happening in the latest Linus tree?
If so, please send some more oops
I think this problem is caused by the lirc_serial module, because if I
try to modprobe the lirc_serial module I get this error:
kobject_add failed for lirc_serial.0 with -EEXIST, don't try to
register things whith the same name in the same directory.
kobject_shadow_add
kobject_set_name
device_add
ll the error:
===
[9271.829711] BUG: unable to handle kernel paging request at virtual
address 6d207972
[9271.829805] printing eip:
[9271.829845] 6d207972
[9271.829883] *pde =
[9271.829926] Oops: 000 [#2]
[9271.829965] SMP
[9271.830067] Modules linked in: bluetoot
I think this problem is caused by the lirc_serial module, because if I
try to modprobe the lirc_serial module I get this error:
kobject_add failed for lirc_serial.0 with -EEXIST, don't try to
register things whith the same name in the same directory.
kobject_shadow_add
kobject_set_name
device_add
:
===
[9271.829711] BUG: unable to handle kernel paging request at virtual
address 6d207972
[9271.829805] printing eip:
[9271.829845] 6d207972
[9271.829883] *pde =
[9271.829926] Oops: 000 [#2]
[9271.829965] SMP
[9271.830067] Modules linked in: bluetooth capability
Hi,
I'm kind of lost in my debugging. Hope someone out there can help me
figure out the problem.
I am loading 4 modules-> class driver, device controller, interface
layer(working on a dual-core) abstraction layer.
Device has to work as a mass storage class. After doing some file
transfer and
On Fri, Aug 10, 2007 at 01:44:24AM +0200, shacky wrote:
> > You snipped the most important part. Even a digital photo of the
> > crash would be more useful than what we have above.
> > So far, there's not really much to go on.
>
> Could you tell me what is the most important part, so I try
> You snipped the most important part. Even a digital photo of the
> crash would be more useful than what we have above.
> So far, there's not really much to go on.
Could you tell me what is the most important part, so I try to rewrite
it by hand?
I don't think a digital photo will be much
On Fri, Aug 10, 2007 at 01:17:14AM +0200, shacky wrote:
> [87.935473] BUG: unable to handle kernel paging request at virtual
> address 6d207972
> [...] printing eip:
> [...] 6d207972
> [...] *pde =
> [...] Oops: 000 [#2]
&
hangs and I see this error:
[87.935473] BUG: unable to handle kernel paging request at virtual
address 6d207972
[...] printing eip:
[...] 6d207972
[...] *pde =
[...] Oops: 000 [#2]
[...] SMP
[...] Modules linked in: bluetooth capability lirc_dev
You snipped the most important part. Even a digital photo of the
crash would be more useful than what we have above.
So far, there's not really much to go on.
Could you tell me what is the most important part, so I try to rewrite
it by hand?
I don't think a digital photo will be much useful
On Fri, Aug 10, 2007 at 01:17:14AM +0200, shacky wrote:
[87.935473] BUG: unable to handle kernel paging request at virtual
address 6d207972
[...] printing eip:
[...] 6d207972
[...] *pde =
[...] Oops: 000 [#2]
[...] SMP
hangs and I see this error:
[87.935473] BUG: unable to handle kernel paging request at virtual
address 6d207972
[...] printing eip:
[...] 6d207972
[...] *pde =
[...] Oops: 000 [#2]
[...] SMP
[...] Modules linked in: bluetooth capability lirc_dev
On Fri, Aug 10, 2007 at 01:44:24AM +0200, shacky wrote:
You snipped the most important part. Even a digital photo of the
crash would be more useful than what we have above.
So far, there's not really much to go on.
Could you tell me what is the most important part, so I try to
Hi,
I'm kind of lost in my debugging. Hope someone out there can help me
figure out the problem.
I am loading 4 modules- class driver, device controller, interface
layer(working on a dual-core) hardware abstraction layer.
Device has to work as a mass storage class. After doing some file
transfer
I can confirm the same oops on 2.6.20-ck1 with pktcdvd either as
module or as built-in.
I can assume perhaps this is not so much an issue with the pktcdvd
driver as it is with the libata drivers and scsi. Beats me, I'll
leave it up to you.
-
To unsubscribe from this list: send the line
I can confirm the same oops on 2.6.20-ck1 with pktcdvd either as
module or as built-in.
I can assume perhaps this is not so much an issue with the pktcdvd
driver as it is with the libata drivers and scsi. Beats me, I'll
leave it up to you.
-
To unsubscribe from this list: send the line
Hmm, THAT looks familiar...
http://bugzilla.kernel.org/show_bug.cgi?id=8198
Yes, it is in 2.6.20.x.
Cheers,
Chris
___
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/
-
either.)
(config and full bootlog attached.)
Ingo
-->
BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
printing eip:
c013c1f5
*pde = 0203000c
Oops: 0002 [#1]
SMP
Modules linked in:
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010256 (2
.)
(config and full bootlog attached.)
Ingo
--
BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
printing eip:
c013c1f5
*pde = 0203000c
Oops: 0002 [#1]
SMP
Modules linked in:
CPU:0
EIP:0060:[c013c1f5]Not tainted VLI
EFLAGS: 00010256
Hmm, THAT looks familiar...
http://bugzilla.kernel.org/show_bug.cgi?id=8198
Yes, it is in 2.6.20.x.
Cheers,
Chris
___
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/
-
Thomas Meyer wrote:
> dmesg output:
>
> pktcdvd: pkt_get_last_written failed
> BUG: unable to handle kernel paging request at virtual address 080e
> EFLAGS: 00010203 (2.6.21-rc6 #295)
> cdrom: This disc doesn't have any tracks I recognize!
>
> This happens while
Thomas Meyer wrote:
dmesg output:
pktcdvd: pkt_get_last_written failed
BUG: unable to handle kernel paging request at virtual address 080e
SNIP
EFLAGS: 00010203 (2.6.21-rc6 #295)
SNIP
cdrom: This disc doesn't have any tracks I recognize!
This happens while calling command pktsetup
dmesg output:
pktcdvd: pkt_get_last_written failed
BUG: unable to handle kernel paging request at virtual address 080e
printing eip:
c015cc98
*pde = 3741d067
*pte =
Oops: [#1]
SMP
Modules linked in: nls_iso8859_15 nls_cp850 vfat fat appletouch dummy
genrtc binfmt_misc tun
dmesg output:
pktcdvd: pkt_get_last_written failed
BUG: unable to handle kernel paging request at virtual address 080e
printing eip:
c015cc98
*pde = 3741d067
*pte =
Oops: [#1]
SMP
Modules linked in: nls_iso8859_15 nls_cp850 vfat fat appletouch dummy
genrtc binfmt_misc tun
I cannot reproduce the BUG with your ml.bz2 patch applied.
I am seeing this with both 2.6.21-rc4-mm1 + hotfixes, and with
2.6.21-rc4 + ml.bz2:
Mar 22 09:10:35 FractalPath kernel: ACPI: CPU0 (power states: C1[C1]
C2[C2] C3[C3])
Mar 22 09:10:35 FractalPath kernel: The kobject at, or inside
.config file.
>
> I hope this helps,
> Miles
>
> kobject drivers: registering. parent: ipw2200, set:
> kobject_uevent_env
> kobject filter function caused the event to drop!
> kobject :01:06.0: cleaning up
> kobject firmware: cleaning up
> BUG: unable to h
On Thu, 22 Mar 2007 00:29:54 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> kobject :01:06.0: cleaning up
> kobject firmware: cleaning up
> BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
> printing eip:
> c0137c22
> *pde = 0
kobject :01:06.0: cleaning up
kobject firmware: cleaning up
BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
printing eip:
c0137c22
*pde =
Oops: 0002 [#1]
last sysfs file:
devices/pci:00/:00:1e.0/:01:06.0/firmware/:01:06.0/loading
Modules linked
On Thu, 22 Mar 2007 00:29:54 -0700 Miles Lane [EMAIL PROTECTED] wrote:
kobject :01:06.0: cleaning up
kobject firmware: cleaning up
BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
printing eip:
c0137c22
*pde =
Oops: 0002 [#1]
last sysfs file:
devices
,
Miles
kobject drivers: registering. parent: ipw2200, set: NULL
kobject_uevent_env
kobject filter function caused the event to drop!
kobject :01:06.0: cleaning up
kobject firmware: cleaning up
BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
printing eip
I cannot reproduce the BUG with your ml.bz2 patch applied.
I am seeing this with both 2.6.21-rc4-mm1 + hotfixes, and with
2.6.21-rc4 + ml.bz2:
Mar 22 09:10:35 FractalPath kernel: ACPI: CPU0 (power states: C1[C1]
C2[C2] C3[C3])
Mar 22 09:10:35 FractalPath kernel: The kobject at, or inside
Becker and others. www.scyld.com/network/vortex.html
:00:0b.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xd400. Vers LK1.1.19
Unable to handle kernel paging request at virtual address e000
c015ef16
*pde = 1067
Oops: 0003 [#1]
CPU:0
EIP:0060:[]Not tainted VLI
Using defaults from
Becker and others. www.scyld.com/network/vortex.html
:00:0b.0: 3Com PCI 3c905 Boomerang 100baseTx at 0xd400. Vers LK1.1.19
Unable to handle kernel paging request at virtual address e000
c015ef16
*pde = 1067
Oops: 0003 [#1]
CPU:0
EIP:0060:[c015ef16]Not tainted VLI
Using defaults
Hi.
#
[1.] Problem when rebooting
#
[2.] I'm running Debian/unstable and each time I reboot the system, I
get a "Unable to handle kernel pading request at
Hi.
#
[1.] Problem when rebooting
#
[2.] I'm running Debian/unstable and each time I reboot the system, I
get a Unable to handle kernel pading request at
ccbddf98 ffe9 bfffda58 c0119f79 0002 ccbddfac
Call Trace: [] [] [] [] []
[]
Code: 8b 44 82 18 89 42 14 83 f8 ff 75 05 8b 02 89 43 08 56 9d 89
Unable to handle kernel paging request at virtual address 189d4d44
printing eip:
c0124482
*pde =
Oops:
CPU:0
EIP:0010
1 - 100 of 103 matches
Mail list logo
