ock 30343695: comm jbd2/sdb7-8: invalid block
>
>Fix this by adding the missing exception check.
>
>Fixes: 345c0dbf3a30 ("ext4: protect journal inode's blocks using
>block_validity")
>Reported-by: Arthur Marsh
>Signed-off-by: Theodore Ts'o
>---
> fs/ext4/block_v
On 14 May 2019 11:29:37 am ACST, Arthur Marsh
wrote:
>Apologies, I had forgotten to
>
>git bisect - - hard origin/master
>
>I am still seeing the corruption leading to the invalid block error on
>5.1.0+ kernels on both my machines.
>
>Arthur.
After the mm co
Apologies, I had forgotten to
got bisect - - hard origin/master
I am still seeing the corruption leading to the invalid block error on 5.1.0+
kernels on both my machines.
Arthur.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
After a git bisect reset and updating to the current Linus git head, the
problem no longer occurs.
Thanks for the feedback on the problem that I experienced.
Arthur.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
I have yet to bisect, but have had trouble with recent, post 5.1.0 kernels
built from Linus' git head on both i386 (Pentium 4 pc) and amd64 (Athlon II X4
640).
The easiest way to trigger the problem is:
git gc
on the kernel source tree, although the problem can occur without doing a git
gc.
egression"). And even then it apparently
took a year for people to have noticed the breakage.
But because the person who reported that problem is still around, I'll
just add him to the cc, just in case.
Arthur Marsh, you have the dubious honor and distinction of being the
only person to have a
n it apparently
took a year for people to have noticed the breakage.
But because the person who reported that problem is still around, I'll
just add him to the cc, just in case.
Arthur Marsh, you have the dubious honor and distinction of being the
only person to have apparently used that driver in th
After a recent git pull and kernel build and reboot, Xorg could not find
the input devices and I was left with unresponsive mouse and keyboard
until I could remotely shut-down and boot into an earlier kernel.
With good kernels, Xorg.log showed evdev finding the mouse and keyboard.
Bisecting
After a recent git pull and kernel build and reboot, Xorg could not find
the input devices and I was left with unresponsive mouse and keyboard
until I could remotely shut-down and boot into an earlier kernel.
With good kernels, Xorg.log showed evdev finding the mouse and keyboard.
Bisecting
Michal Hocko wrote on 02/05/17 17:01:
[92311.93] swap_info_get: Bad swap offset entry 000d
[92311.99] swap_info_get: Bad swap offset entry 000e
[92311.944451] swap_info_get: Bad swap offset entry 000f
Pte swap entry seem to be clobbered. That suggests a deeper problem
Michal Hocko wrote on 02/05/17 17:01:
[92311.93] swap_info_get: Bad swap offset entry 000d
[92311.99] swap_info_get: Bad swap offset entry 000e
[92311.944451] swap_info_get: Bad swap offset entry 000f
Pte swap entry seem to be clobbered. That suggests a deeper problem
Michal Hocko wrote on 27/04/17 18:56:
On Thu 27-04-17 18:36:38, Arthur Marsh wrote:
[...]
[55363.482931] QXcbEventReader: page allocation stalls for 10048ms, order:0,
mode:0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null)
Are there more of these stalls?
I haven't seen the same kinds
Michal Hocko wrote on 27/04/17 18:56:
On Thu 27-04-17 18:36:38, Arthur Marsh wrote:
[...]
[55363.482931] QXcbEventReader: page allocation stalls for 10048ms, order:0,
mode:0x14200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null)
Are there more of these stalls?
I haven't seen the same kinds
I came home yesterday to discover my desktop KDE/plasma session locked
up until I could shutdown firefox and chromium from a console login.
The desktop then became responsive and I could then restart firefox and
chromium.
the 4GiB swap space was nearly full, but the OOM killer apparently
I came home yesterday to discover my desktop KDE/plasma session locked
up until I could shutdown firefox and chromium from a console login.
The desktop then became responsive and I could then restart firefox and
chromium.
the 4GiB swap space was nearly full, but the OOM killer apparently
I've had no issues building the 4.11.0-rc1+ kernels on x86_64 until some
commits in the last 24 hours, that resulted in:
[ 18.746569] BUG: Bad page map in process libinput-device
pte:3f90 pmd:22
0910067
[ 18.746757] addr:7efd31d0 vm_flags:0870 anon_vma:
(null)
I've had no issues building the 4.11.0-rc1+ kernels on x86_64 until some
commits in the last 24 hours, that resulted in:
[ 18.746569] BUG: Bad page map in process libinput-device
pte:3f90 pmd:22
0910067
[ 18.746757] addr:7efd31d0 vm_flags:0870 anon_vma:
(null)
On one of my pc's I have 2 PATA disks (one, WDC below is used for
booting, the other SAMSUNG is not mounted), plus an IBM SCSI disk using
a DPT 2044W controller with eata driver and sometimes a Verbatim
Storengo USB stick.
On recent 4.10.0+ kernel builds (i386), the resulting kernel would
On one of my pc's I have 2 PATA disks (one, WDC below is used for
booting, the other SAMSUNG is not mounted), plus an IBM SCSI disk using
a DPT 2044W controller with eata driver and sometimes a Verbatim
Storengo USB stick.
On recent 4.10.0+ kernel builds (i386), the resulting kernel would
Jiang Liu wrote on 02/03/16 13:50:
I spoke too soon, without removing and re-inserting the eata module
before any filesystems on disks attached to the DPT controller were
mounted, I'd get the following messages, similar to ones previously
reported:
sd 0:0:6:0: tag#0 abort, mbox 1.
EATA0:
Jiang Liu wrote on 02/03/16 13:50:
I spoke too soon, without removing and re-inserting the eata module
before any filesystems on disks attached to the DPT controller were
mounted, I'd get the following messages, similar to ones previously
reported:
sd 0:0:6:0: tag#0 abort, mbox 1.
EATA0:
Arthur Marsh wrote on 02/03/16 03:57:
Christoph Hellwig wrote on 01/03/16 17:22:
Hi Jiang.
I'd love to see this patch in and abuse of the old PCI API gone.
Did you resolve the problems Arthur saw with the previous iteratons
of the patch?
I applied Jiang Liu's patch of 1st March 2016
Arthur Marsh wrote on 02/03/16 03:57:
Christoph Hellwig wrote on 01/03/16 17:22:
Hi Jiang.
I'd love to see this patch in and abuse of the old PCI API gone.
Did you resolve the problems Arthur saw with the previous iteratons
of the patch?
I applied Jiang Liu's patch of 1st March 2016
Christoph Hellwig wrote on 01/03/16 17:22:
Hi Jiang.
I'd love to see this patch in and abuse of the old PCI API gone.
Did you resolve the problems Arthur saw with the previous iteratons
of the patch?
I applied Jiang Liu's patch of 1st March 2016 to a clean kernel
4.5.0-rc6 source,
Christoph Hellwig wrote on 01/03/16 17:22:
Hi Jiang.
I'd love to see this patch in and abuse of the old PCI API gone.
Did you resolve the problems Arthur saw with the previous iteratons
of the patch?
I applied Jiang Liu's patch of 1st March 2016 to a clean kernel
4.5.0-rc6 source,
Jiang Liu wrote on 25/11/15 18:57:
Hi Arthur,
Thanks for reminder again!
It's a little strange, the formal patch "[Bugfix] x86/PCI: Fix
regression caused by commit 4d6b4e69a245" is based on the debug patch
I sent to you at 9 November 2015.
Could you please help to try the
Jiang Liu wrote on 25/11/15 18:57:
Hi Arthur,
Thanks for reminder again!
It's a little strange, the formal patch "[Bugfix] x86/PCI: Fix
regression caused by commit 4d6b4e69a245" is based on the debug patch
I sent to you at 9 November 2015.
Could you please help to try the
Keith Busch wrote on 25/11/15 09:34:
On Tue, Nov 24, 2015 at 11:19:34PM +0100, Rafael J. Wysocki wrote:
Quite frankly, I'm more likely to revert the offending commit at this
point as that's not the only regression reported against it and the
fix only helps in one case (out of three known to
Keith Busch wrote on 25/11/15 09:34:
On Tue, Nov 24, 2015 at 11:19:34PM +0100, Rafael J. Wysocki wrote:
Quite frankly, I'm more likely to revert the offending commit at this
point as that's not the only regression reported against it and the
fix only helps in one case (out of three known to
regression on some legacy
AMD platforms as reported by Arthur Marsh .
The root causes is that acpi_pci_root_create() fails to insert
host bridge resources into iomem_resource/ioport_resource because
x86_pci_root_bus_resources() has already inserted those resources.
So change x86_pci_root_bus
in
arch/x86/pci/bus_numa.c, which causes regression on some legacy
AMD platforms as reported by Arthur Marsh <arthur.ma...@internode.on.net>.
The root causes is that acpi_pci_root_create() fails to insert
host bridge resources into iomem_resource/ioport_resource because
x86_pci_root_bus_resources(
Jiang Liu wrote on 09/11/15 18:22:
Hi Arthur,
Could you please help to try the attached test patch?
Thanks,
Gerry
Thanks, I applied the patch, rebuilt and installed the resulting kernel
and it booted fine.
dmesg output from booting with this patch applied attached.
Arthur.
[
Jiang Liu wrote on 09/11/15 18:22:
Hi Arthur,
Could you please help to try the attached test patch?
Thanks,
Gerry
Thanks, I applied the patch, rebuilt and installed the resulting kernel
and it booted fine.
dmesg output from booting with this patch applied attached.
Arthur.
[
Jiang Liu wrote on 08/11/15 23:33:
On 2015/11/7 15:56, Arthur Marsh wrote:
Hi, I've run into a situation where I've been getting a lock-up a few
seconds into the boot process on a machine with an ASUS A8V-MX
motherboard, BIOS 050312/06/2005 with AMD Athlon(tm) 64 Processor
3200+ (single
Jiang Liu wrote on 08/11/15 23:33:
On 2015/11/7 15:56, Arthur Marsh wrote:
Hi, I've run into a situation where I've been getting a lock-up a few
seconds into the boot process on a machine with an ASUS A8V-MX
motherboard, BIOS 050312/06/2005 with AMD Athlon(tm) 64 Processor
3200+ (single
Jiang Liu wrote on 03/10/15 17:41:
If I do a normal boot which includes eata being loaded, the disk
attached to the DPT2044W controller having its filesystems checked and
mounted, then attempt a kexec reboot, I get the reboot pausing after the
"synchronizing SCSI cache" messages as before.
Jiang Liu wrote on 03/10/15 17:41:
If I do a normal boot which includes eata being loaded, the disk
attached to the DPT2044W controller having its filesystems checked and
mounted, then attempt a kexec reboot, I get the reboot pausing after the
"synchronizing SCSI cache" messages as before.
Jiang Liu wrote on 03/10/15 17:41:
Hi Arthur,
The above results suggest that we need to shutdown eata
controller for kexec. So could you please try to apply the attached
patch upon the previous two patches?
Thanks!
Gerry
Hi, I still get kexec shutdown errors like this with the 3rd
Jiang Liu wrote on 03/10/15 17:41:
Hi Arthur,
The above results suggest that we need to shutdown eata
controller for kexec. So could you please try to apply the attached
patch upon the previous two patches?
Thanks!
Gerry
Hi, I still get kexec shutdown errors like this with the 3rd
Arthur Marsh wrote on 24/09/15 15:26:
Jiang Liu wrote on 24/09/15 13:58:
Hi James,
Thanks for review. How about the attached patch which addresses
the three suggestions from you?
Thanks!
Gerry
I've applied the patch, rebuilt the kernel and verified that it allows
unloading
Arthur Marsh wrote on 24/09/15 15:26:
Jiang Liu wrote on 24/09/15 13:58:
Hi James,
Thanks for review. How about the attached patch which addresses
the three suggestions from you?
Thanks!
Gerry
I've applied the patch, rebuilt the kernel and verified that it allows
unloading
Jiang Liu wrote on 24/09/15 13:58:
Hi James,
Thanks for review. How about the attached patch which addresses
the three suggestions from you?
Thanks!
Gerry
I've applied the patch, rebuilt the kernel and verified that it allows
unloading of the eata module and reloading it, as well
Jiang Liu wrote on 23/09/15 14:54:
Hi Arthur,
I have found the cause of the warning messages, it's caused
by a flaw in the conversion. But according to my understanding,
it isn't related to the kexec/kdump failure. Could you please help
to test the attached new version?
Thanks!
Gerry
Jiang Liu wrote on 23/09/15 14:54:
Hi Arthur,
I have found the cause of the warning messages, it's caused
by a flaw in the conversion. But according to my understanding,
it isn't related to the kexec/kdump failure. Could you please help
to test the attached new version?
Thanks!
Gerry
Jiang Liu wrote on 24/09/15 13:58:
Hi James,
Thanks for review. How about the attached patch which addresses
the three suggestions from you?
Thanks!
Gerry
I've applied the patch, rebuilt the kernel and verified that it allows
unloading of the eata module and reloading it, as well
James Bottomley wrote on 23/09/15 08:15:
On Wed, 2015-09-23 at 07:55 +0930, Arthur Marsh wrote:
Jiang Liu wrote on 22/09/15 17:00:
Previously the eata driver just grabs and accesses eata PCI devices
without implementing a PCI device driver, that causes troubles with
latest IRQ related
Jiang Liu wrote on 22/09/15 17:00:
Previously the eata driver just grabs and accesses eata PCI devices
without implementing a PCI device driver, that causes troubles with
latest IRQ related
Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") changes the way
Jiang Liu wrote on 22/09/15 17:00:
Previously the eata driver just grabs and accesses eata PCI devices
without implementing a PCI device driver, that causes troubles with
latest IRQ related
Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") changes the way
James Bottomley wrote on 23/09/15 08:15:
On Wed, 2015-09-23 at 07:55 +0930, Arthur Marsh wrote:
Jiang Liu wrote on 22/09/15 17:00:
Previously the eata driver just grabs and accesses eata PCI devices
without implementing a PCI device driver, that causes troubles with
latest IRQ related
Christoph Hellwig wrote on 16/09/15 23:12:
Jiang, you also need to convert the driver to
scsi_add_host/scsi_remove_host from the legacy scsi_register interface,
otherwise the SCSI layer will be very unhappy.
Take a look at commit 0d31f8759109cbc1e6fc196d08e6b0e8a9e93b3f for
example, the
Christoph Hellwig wrote on 16/09/15 23:12:
Jiang, you also need to convert the driver to
scsi_add_host/scsi_remove_host from the legacy scsi_register interface,
otherwise the SCSI layer will be very unhappy.
Take a look at commit 0d31f8759109cbc1e6fc196d08e6b0e8a9e93b3f for
example, the
Jiang Liu wrote on 16/09/15 17:51:
Hi Arthur,
It would be great if we could capture the text as in the
picture posted by you at:
http://www.users.on.net/~arthur.marsh/20150915547.jpg
I guess a serial console could help us to capture those
log messages. To use serial
Jiang Liu wrote on 16/09/15 14:37:
On 2015/9/15 15:19, Arthur Marsh wrote:
Jiang Liu wrote on 15/09/15 12:01:
HI Arthur,
Really appreciate your help to test the patches. That's
a good sign we have moved forward a bit:)
For kexec, it's always challenging to me. So could you
Jiang Liu wrote on 16/09/15 14:37:
On 2015/9/15 15:19, Arthur Marsh wrote:
Jiang Liu wrote on 15/09/15 12:01:
HI Arthur,
Really appreciate your help to test the patches. That's
a good sign we have moved forward a bit:)
For kexec, it's always challenging to me. So could you
Jiang Liu wrote on 16/09/15 17:51:
Hi Arthur,
It would be great if we could capture the text as in the
picture posted by you at:
http://www.users.on.net/~arthur.marsh/20150915547.jpg
I guess a serial console could help us to capture those
log messages. To use serial
Jiang Liu wrote on 15/09/15 12:01:
HI Arthur,
Really appreciate your help to test the patches. That's
a good sign we have moved forward a bit:)
For kexec, it's always challenging to me. So could you
please help to provide full dmesg logs with working kernels
so I could try to
Jiang Liu wrote on 15/09/15 12:01:
HI Arthur,
Really appreciate your help to test the patches. That's
a good sign we have moved forward a bit:)
For kexec, it's always challenging to me. So could you
please help to provide full dmesg logs with working kernels
so I could try to
Jiang Liu wrote on 14/09/15 12:38:
Hi Authur,
As suggested by Bjorn, patch 1-2 set implement a PCI device
driver to manage eata PCI devices. And patch 3 tries to support PCI
device hot-removal for eata, but I have no change to test due to
limited knowledge about scsi subsystem and
Jiang Liu wrote on 14/09/15 12:38:
Hi Authur,
As suggested by Bjorn, patch 1-2 set implement a PCI device
driver to manage eata PCI devices. And patch 3 tries to support PCI
device hot-removal for eata, but I have no change to test due to
limited knowledge about scsi subsystem and
Jiang Liu wrote on 10/09/15 17:43:
Hi Authur,
Thanks for the updating. Seem Bjorn doesn't like
neither of my two patches. So I'm trying to convert eata
to formal PCI driver, but the change will be much more
bigger and still not sure whether we could achieve that.
Will keep you updated.
Jiang Liu wrote on 08/09/15 14:49:
Hi Auhur,
Could you please help to apply the test patch
against the latest mainstream linux kernel?
Thanks!
Gerry
...
git bisect good
991de2e59090e55c65a7f59a049142e3c480f7bd is the first bad commit
commit 991de2e59090e55c65a7f59a049142e3c480f7bd
Jiang Liu wrote on 08/09/15 14:49:
Hi Auhur,
Could you please help to apply the test patch
against the latest mainstream linux kernel?
Thanks!
Gerry
...
git bisect good
991de2e59090e55c65a7f59a049142e3c480f7bd is the first bad commit
commit 991de2e59090e55c65a7f59a049142e3c480f7bd
Jiang Liu wrote on 10/09/15 17:43:
Hi Authur,
Thanks for the updating. Seem Bjorn doesn't like
neither of my two patches. So I'm trying to convert eata
to formal PCI driver, but the change will be much more
bigger and still not sure whether we could achieve that.
Will keep you updated.
Jiang Liu wrote on 08/09/15 16:56:
Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
for PCI devices on x86 platforms. Instead of allocating PCI legacy
IRQs when pcibios_enable_device() gets called, now
Jiang Liu wrote on 08/09/15 16:56:
Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
for PCI devices on x86 platforms. Instead of allocating PCI legacy
IRQs when pcibios_enable_device() gets called, now
Jiang Liu wrote on 08/09/15 16:56:
Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
for PCI devices on x86 platforms. Instead of allocating PCI legacy
IRQs when pcibios_enable_device() gets called, now
Jiang Liu wrote on 08/09/15 14:49:
Hi Auhur,
Could you please help to apply the test patch
against the latest mainstream linux kernel?
Thanks!
Gerry
Done, and it appears to work properly thanks!
Arthur.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing
Jiang Liu wrote on 08/09/15 14:49:
Hi Auhur,
Could you please help to apply the test patch
against the latest mainstream linux kernel?
Thanks!
Gerry
Done, and it appears to work properly thanks!
Arthur.
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing
Jiang Liu wrote on 08/09/15 16:56:
Commit 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") changes the way to allocate PCI legacy IRQ
for PCI devices on x86 platforms. Instead of allocating PCI legacy
IRQs when pcibios_enable_device() gets called, now
+0930
From: Arthur Marsh
To: Jiang Liu
CC: Bjorn Helgaas , t...@linutronix.de,
linux-s...@vger.kernel.org, linux-kernel@vger.kernel.org
Jiang Liu wrote on 07/09/15 12:36:
On 2015/9/7 4:31, Arthur Marsh wrote:
Arthur Marsh wrote on 06/09/15 21:07:
Arthur Marsh wrote on 06/09/15 18:34
+0930
From: Arthur Marsh <arthur.ma...@internode.on.net>
To: Jiang Liu <jiang@linux.intel.com>
CC: Bjorn Helgaas <bhelg...@google.com>, t...@linutronix.de,
linux-s...@vger.kernel.org, linux-kernel@vger.kernel.org
Jiang Liu wrote on 07/09/15 12:36:
On 2015/9/7 4:31,
Vlastimil Babka wrote on 21/08/15 21:18:
On 08/21/2015 01:37 PM, Vlastimil Babka wrote:
That, said, looking at the memory values:
rc6: Free+Buffers+A/I(Anon)+A/I(File)+Slab = 6769MB
rc7: ... = 4714MB
That's 2GB unaccounted for.
So one brute-force way to
Vlastimil Babka wrote on 21/08/15 21:18:
On 08/21/2015 01:37 PM, Vlastimil Babka wrote:
That, said, looking at the memory values:
rc6: Free+Buffers+A/I(Anon)+A/I(File)+Slab = 6769MB
rc7: ... = 4714MB
That's 2GB unaccounted for.
So one brute-force way to
Vlastimil Babka wrote on 21/08/15 21:07:
On 08/21/2015 11:17 AM, Arthur Marsh wrote:
Vlastimil Babka wrote on 20/08/15 17:46:
On 08/19/2015 05:44 PM, Arthur Marsh wrote:
Hi, I've found that the Linus' git head kernel has had some unwelcome
behaviour where chromium browser would exhaust
Vlastimil Babka wrote on 21/08/15 21:18:
On 08/21/2015 01:37 PM, Vlastimil Babka wrote:
That, said, looking at the memory values:
rc6: Free+Buffers+A/I(Anon)+A/I(File)+Slab = 6769MB
rc7: ... = 4714MB
That's 2GB unaccounted for.
So one brute-force way to
Vlastimil Babka wrote on 21/08/15 21:07:
On 08/21/2015 11:17 AM, Arthur Marsh wrote:
Vlastimil Babka wrote on 20/08/15 17:46:
On 08/19/2015 05:44 PM, Arthur Marsh wrote:
Hi, I've found that the Linus' git head kernel has had some unwelcome
behaviour where chromium browser would exhaust
Vlastimil Babka wrote on 21/08/15 21:18:
On 08/21/2015 01:37 PM, Vlastimil Babka wrote:
That, said, looking at the memory values:
rc6: Free+Buffers+A/I(Anon)+A/I(File)+Slab = 6769MB
rc7: ... = 4714MB
That's 2GB unaccounted for.
So one brute-force way to
Hi, I've found that the Linus' git head kernel has had some unwelcome
behaviour where chromium browser would exhaust all swap space in the
course of a few hours. The behaviour appeared before the release of
4.2.0-rc7.
This does not happen with kernel 4.2.0-rc6.
When I tried a git-bisect, the
Hi, I've found that the Linus' git head kernel has had some unwelcome
behaviour where chromium browser would exhaust all swap space in the
course of a few hours. The behaviour appeared before the release of
4.2.0-rc7.
This does not happen with kernel 4.2.0-rc6.
When I tried a git-bisect, the
Oleg Nesterov wrote on 15/08/15 02:49:
On 08/13, Jan Kara wrote:
Regarding the routing, ideally Al Viro should take these as a VFS
maintainer.
Al, could you take these patches?
Only cosmetic changes in V3 to address the comments from Jan, I
preserved his acks.
In case you missed all the
Oleg Nesterov wrote on 15/08/15 02:49:
On 08/13, Jan Kara wrote:
Regarding the routing, ideally Al Viro should take these as a VFS
maintainer.
Al, could you take these patches?
Only cosmetic changes in V3 to address the comments from Jan, I
preserved his acks.
In case you missed all the
Peter Zijlstra wrote on 08/07/15 18:34:
On Wed, Jul 08, 2015 at 06:01:29PM +0930, Arthur Marsh wrote:
Peter Zijlstra wrote on 08/07/15 07:41:
On Tue, Jul 07, 2015 at 11:56:20PM +0200, Peter Zijlstra wrote:
Could you try the below? It appears there was a spot freeing modules
that forgot
Peter Zijlstra wrote on 08/07/15 07:41:
On Tue, Jul 07, 2015 at 11:56:20PM +0200, Peter Zijlstra wrote:
Could you try the below? It appears there was a spot freeing modules
that forgot to take them out of the tree.
If that fails, try and disable CONFIG_MODULE_UNLOAD.
I tried the patch
Peter Zijlstra wrote on 08/07/15 18:34:
On Wed, Jul 08, 2015 at 06:01:29PM +0930, Arthur Marsh wrote:
Peter Zijlstra wrote on 08/07/15 07:41:
On Tue, Jul 07, 2015 at 11:56:20PM +0200, Peter Zijlstra wrote:
Could you try the below? It appears there was a spot freeing modules
that forgot
Peter Zijlstra wrote on 08/07/15 07:41:
On Tue, Jul 07, 2015 at 11:56:20PM +0200, Peter Zijlstra wrote:
Could you try the below? It appears there was a spot freeing modules
that forgot to take them out of the tree.
If that fails, try and disable CONFIG_MODULE_UNLOAD.
I tried the patch
Mathieu Desnoyers wrote on 08/07/15 02:03:
- On Jul 7, 2015, at 3:29 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Jul 07, 2015 at 02:59:06PM +0930, Arthur Marsh wrote:
I had a single, non-reproducible case of the same lock-up happening on my
other machine running the Linus git
Peter Zijlstra wrote on 07/07/15 16:59:
Do you have a serial cable between those machines? serial console output
will allow capturing more complete traces than these pictures can and
might also aid in capturing some extra debug info.
In any case, I'll go try and build some debug code.
I
Peter Zijlstra wrote on 07/07/15 16:59:
Do you have a serial cable between those machines? serial console output
will allow capturing more complete traces than these pictures can and
might also aid in capturing some extra debug info.
In any case, I'll go try and build some debug code.
I
Mathieu Desnoyers wrote on 08/07/15 02:03:
- On Jul 7, 2015, at 3:29 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Jul 07, 2015 at 02:59:06PM +0930, Arthur Marsh wrote:
I had a single, non-reproducible case of the same lock-up happening on my
other machine running the Linus git
I had a single, non-reproducible case of the same lock-up happening on
my other machine running the Linus git head kernel in 64-bit mode.
The kernel was built very similarly to the 32-bit mode kernel, using:
CONCURRENCY_LEVEL=4 MAKEFLAGS="CC=gcc-5 LD=ld.gold
KCFLAGS=-march=athlon64" \
Peter Zijlstra wrote on 06/07/15 20:02:
On Mon, Jul 06, 2015 at 07:41:38PM +0930, Arthur Marsh wrote:
No, it's the standard kernel radeon driver.
If it's of any use I can reboot the machine with the kernel that goes boom
and the video card removed.
You're saying the same kernel boots
Peter Zijlstra wrote on 06/07/15 19:34:
On Mon, Jul 06, 2015 at 04:03:45AM +0930, Arthur Marsh wrote:
On this machine, a single core Athlon 64 with a 32 bit current Linus' git
head kernel, I get a lock-up early in the boot process. (A dmesg output of a
successful boot-up of kernel 4.1.0 up
Peter Zijlstra wrote on 06/07/15 17:42:
On Mon, Jul 06, 2015 at 09:19:11AM +0200, Peter Zijlstra wrote:
On Mon, Jul 06, 2015 at 04:03:45AM +0930, Arthur Marsh wrote:
I am happy to supply further details and run further tests.
A .config and gcc version might be a good start. I'll see
Apologies if a duplicate, mailing list did not like the large .config.
Peter Zijlstra wrote on 06/07/15 16:49:
On Mon, Jul 06, 2015 at 04:03:45AM +0930, Arthur Marsh wrote:
I am happy to supply further details and run further tests.
A .config and gcc version might be a good start. I'll see
Peter Zijlstra wrote on 06/07/15 19:34:
On Mon, Jul 06, 2015 at 04:03:45AM +0930, Arthur Marsh wrote:
On this machine, a single core Athlon 64 with a 32 bit current Linus' git
head kernel, I get a lock-up early in the boot process. (A dmesg output of a
successful boot-up of kernel 4.1.0 up
Peter Zijlstra wrote on 06/07/15 17:42:
On Mon, Jul 06, 2015 at 09:19:11AM +0200, Peter Zijlstra wrote:
On Mon, Jul 06, 2015 at 04:03:45AM +0930, Arthur Marsh wrote:
I am happy to supply further details and run further tests.
A .config and gcc version might be a good start. I'll see
Apologies if a duplicate, mailing list did not like the large .config.
Peter Zijlstra wrote on 06/07/15 16:49:
On Mon, Jul 06, 2015 at 04:03:45AM +0930, Arthur Marsh wrote:
I am happy to supply further details and run further tests.
A .config and gcc version might be a good start. I'll see
Peter Zijlstra wrote on 06/07/15 20:02:
On Mon, Jul 06, 2015 at 07:41:38PM +0930, Arthur Marsh wrote:
No, it's the standard kernel radeon driver.
If it's of any use I can reboot the machine with the kernel that goes boom
and the video card removed.
You're saying the same kernel boots
I had a single, non-reproducible case of the same lock-up happening on
my other machine running the Linus git head kernel in 64-bit mode.
The kernel was built very similarly to the 32-bit mode kernel, using:
CONCURRENCY_LEVEL=4 MAKEFLAGS=CC=gcc-5 LD=ld.gold
KCFLAGS=-march=athlon64 \
On this machine, a single core Athlon 64 with a 32 bit current Linus'
git head kernel, I get a lock-up early in the boot process. (A dmesg
output of a successful boot-up of kernel 4.1.0 up to and slightly passed
the point where the git head kernel locks up is attached).
A photo of the lock-up
1 - 100 of 129 matches
Mail list logo