Hi, I found that Linux kernel 3.9.0-rc2 would not mount a remote cifs
filesystem, and ran a git bisect which identified the following commit:
am64:/mnt# mount -t cifs //192.168.1.104/homes homes
Password:
am64:/mnt# cd /usr/src/linux
am64:/usr/src/linux# git bisect good
Eric W. Biederman wrote, on 12/03/13 00:07:
Arthur Marsharthur.ma...@internode.on.net writes:
Hi, I found that Linux kernel 3.9.0-rc2 would not mount a remote cifs
filesystem, and ran a git bisect which identified the following
commit:
Is there a patch already present somewhere to fix this
[repost, apologies if you see it twice]
I'm running Debian unstable on AMD64 (quad core) with Linus' github.com
kernels.
Recently (post 3.5.0 kernels) writes to an ntfs-3g filesystem started
failing, and I bisected back to the following:
# git bisect good
Josh Boyer wrote, on 13/08/12 00:07:
On Sun, Aug 12, 2012 at 9:59 AM, Arthur Marsh
...
Has this problem been seen by anyone else?
Yep, it was reported in Fedora last week.
Is a fix already in the works?
Miklos posted this patch series that fixed things:
http://thread.gmane.org
Herbert Xu wrote, on 12/09/13 13:56:
On Wed, Sep 11, 2013 at 08:43:19PM +0900, Tetsuo Handa wrote:
Hello.
I'm again having the boot failure problem due to commit 68411521 'Reinstate
crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform
framework' in linux.git .
OK, can
Takashi Iwai wrote, on 20/01/14 19:22:
At Sun, 19 Jan 2014 17:32:16 +1030,
Arthur Marsh wrote:
I have had reproducible lock-ups on shut-down (at the shutting down ALSA
stage) of my AMD64 machine (Asus M3A78Pro motherboard, BIOS 1701
01/27/2011, CPU AMD Athlon(tm) II X4 640 Processor) running
Takashi Iwai wrote, on 21/01/14 21:43:
At Tue, 21 Jan 2014 11:50:43 +1030,
Arthur Marsh wrote:
Takashi Iwai wrote, on 20/01/14 19:22:
At Sun, 19 Jan 2014 17:32:16 +1030,
Arthur Marsh wrote:
I have had reproducible lock-ups on shut-down (at the shutting down ALSA
stage) of my AMD64
I have had reproducible lock-ups on shut-down (at the shutting down ALSA
stage) of my AMD64 machine (Asus M3A78Pro motherboard, BIOS 1701
01/27/2011, CPU AMD Athlon(tm) II X4 640 Processor) running the 64 bit
Linux kernel more recent than 3.12 when *both* radeon.audio=1 was set
and I had been
Colin Watson wrote on 11/12/14 23:10:
On Thu, Dec 11, 2014 at 10:32:00PM +1030, Arthur Marsh wrote:
Colin Watson wrote on 11/12/14 21:14:
The latest binfmt_misc module in git has much more detailed debugging
output in dmesg. What does dmesg | grep binfmt_misc say?
Hi, I'm seeing:
$ dmesg
Al Viro wrote on 12/12/14 16:31:
On Fri, Dec 12, 2014 at 02:51:55PM +1030, Arthur Marsh wrote:
6b899c4e9a049dfca759d990bd53b14f81c3626c is the first bad commit
commit 6b899c4e9a049dfca759d990bd53b14f81c3626c
Author: Mike Frysinger vap...@gentoo.org
Date: Wed Dec 10 15:52:08 2014 -0800
Al Viro wrote on 12/12/14 16:31:
On Fri, Dec 12, 2014 at 02:51:55PM +1030, Arthur Marsh wrote:
6b899c4e9a049dfca759d990bd53b14f81c3626c is the first bad commit
commit 6b899c4e9a049dfca759d990bd53b14f81c3626c
Author: Mike Frysinger vap...@gentoo.org
Date: Wed Dec 10 15:52:08 2014 -0800
I just hit this rebooting an x86-64 3.19.0-rc1 kernel on a 4 core AMD
cpu when the machine was starting check the filesystems:
[ 22.427652] general protection fault: [#1] PREEMPT SMP
[ 22.431822] Modules linked in: max6650 fuse parport_pc ppdev lp
parport snd_hda_codec_hdmi
Borislav Petkov wrote on 22/12/14 19:35:
...
I haven't hit one of these errors for a while and this has only
happened the once with this kernel. If anyone wants more details I'm
happy to supply them.
Does that mean that you've hit similar corruptions in the past too? If
so, do they all look
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
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 \
Hi, I experienced glyph corruption in iceweasel (unbranded Firefox) on a
machine with a Radeon 3850HD video card and 4.1.0-rc4 and later kernels.
Git bisecting pointed to the commit 607d48063512707a414e346972e2210dc71ab491
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
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
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
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
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
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(
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
+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,
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
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 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 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
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 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:
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 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 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
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
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
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
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:
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,
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
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 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
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 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
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
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
Herbert Xu wrote, on 12/09/13 13:56:
On Wed, Sep 11, 2013 at 08:43:19PM +0900, Tetsuo Handa wrote:
Hello.
I'm again having the boot failure problem due to commit 68411521 'Reinstate
"crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform
framework"' in linux.git .
OK, can
Hi, I found that Linux kernel 3.9.0-rc2 would not mount a remote cifs
filesystem, and ran a git bisect which identified the following commit:
am64:/mnt# mount -t cifs //192.168.1.104/homes homes
Password:
am64:/mnt# cd /usr/src/linux
am64:/usr/src/linux# git bisect good
Eric W. Biederman wrote, on 12/03/13 00:07:
Arthur Marsh writes:
Hi, I found that Linux kernel 3.9.0-rc2 would not mount a remote cifs
filesystem, and ran a git bisect which identified the following
commit:
Is there a patch already present somewhere to fix this problem?
Grr
Takashi Iwai wrote, on 21/01/14 21:43:
At Tue, 21 Jan 2014 11:50:43 +1030,
Arthur Marsh wrote:
Takashi Iwai wrote, on 20/01/14 19:22:
At Sun, 19 Jan 2014 17:32:16 +1030,
Arthur Marsh wrote:
I have had reproducible lock-ups on shut-down (at the shutting down ALSA
stage) of my AMD64
I have had reproducible lock-ups on shut-down (at the shutting down ALSA
stage) of my AMD64 machine (Asus M3A78Pro motherboard, BIOS 1701
01/27/2011, CPU AMD Athlon(tm) II X4 640 Processor) running the 64 bit
Linux kernel more recent than 3.12 when *both* radeon.audio=1 was set
and I had been
Takashi Iwai wrote, on 20/01/14 19:22:
At Sun, 19 Jan 2014 17:32:16 +1030,
Arthur Marsh wrote:
I have had reproducible lock-ups on shut-down (at the shutting down ALSA
stage) of my AMD64 machine (Asus M3A78Pro motherboard, BIOS 1701
01/27/2011, CPU AMD Athlon(tm) II X4 640 Processor) running
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
[repost, apologies if you see it twice]
I'm running Debian unstable on AMD64 (quad core) with Linus' github.com
kernels.
Recently (post 3.5.0 kernels) writes to an ntfs-3g filesystem started
failing, and I bisected back to the following:
# git bisect good
Josh Boyer wrote, on 13/08/12 00:07:
On Sun, Aug 12, 2012 at 9:59 AM, Arthur Marsh
...
Has this problem been seen by anyone else?
Yep, it was reported in Fedora last week.
Is a fix already in the works?
Miklos posted this patch series that fixed things:
http://thread.gmane.org
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
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.
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.
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.
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
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
Colin Watson wrote on 11/12/14 23:10:
On Thu, Dec 11, 2014 at 10:32:00PM +1030, Arthur Marsh wrote:
Colin Watson wrote on 11/12/14 21:14:
The latest binfmt_misc module in git has much more detailed debugging
output in dmesg. What does "dmesg | grep binfmt_misc" say?
Hi,
Al Viro wrote on 12/12/14 16:31:
On Fri, Dec 12, 2014 at 02:51:55PM +1030, Arthur Marsh wrote:
6b899c4e9a049dfca759d990bd53b14f81c3626c is the first bad commit
commit 6b899c4e9a049dfca759d990bd53b14f81c3626c
Author: Mike Frysinger
Date: Wed Dec 10 15:52:08 2014 -0800
binfmt_misc: add
Hi, I experienced glyph corruption in iceweasel (unbranded Firefox) on a
machine with a Radeon 3850HD video card and 4.1.0-rc4 and later kernels.
Git bisecting pointed to the commit 607d48063512707a414e346972e2210dc71ab491
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 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
+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
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
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
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
...
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.
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
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: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
Al Viro wrote on 12/12/14 16:31:
On Fri, Dec 12, 2014 at 02:51:55PM +1030, Arthur Marsh wrote:
6b899c4e9a049dfca759d990bd53b14f81c3626c is the first bad commit
commit 6b899c4e9a049dfca759d990bd53b14f81c3626c
Author: Mike Frysinger
Date: Wed Dec 10 15:52:08 2014 -0800
binfmt_misc: add
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
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 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
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 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
1 - 100 of 129 matches
Mail list logo
