On Wed, Jul 08, 2015 at 09:13:15PM +0930, Arthur Marsh wrote:
> I rebuilt again with CONFIG_MODULE_UNLOAD enabled and Peter's patch above
> and the resulting kernel also booted fine.
>
> Thanks for everyone's help!
Awesome, lemme go write up a proper patch to make Rusty happy too ;-)
--
To unsubs
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 t
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 to take them out of the tree.
>
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 bel
Peter Zijlstra writes:
> On Tue, Jul 07, 2015 at 11:56:20PM +0200, Peter Zijlstra wrote:
>> On Wed, Jul 08, 2015 at 05:45:45AM +0930, Arthur Marsh wrote:
>> > I'm not aware of any modules being loaded with --force .
>> >
>> > I've applied the patch, thanks!
>> >
>> > The resultant kernel locked
On Tue, Jul 07, 2015 at 11:56:20PM +0200, Peter Zijlstra wrote:
> On Wed, Jul 08, 2015 at 05:45:45AM +0930, Arthur Marsh wrote:
> > I'm not aware of any modules being loaded with --force .
> >
> > I've applied the patch, thanks!
> >
> > The resultant kernel locked up as follows:
> >
> > http://w
On Wed, Jul 08, 2015 at 05:45:45AM +0930, Arthur Marsh wrote:
> I'm not aware of any modules being loaded with --force .
>
> I've applied the patch, thanks!
>
> The resultant kernel locked up as follows:
>
> http://www.users.on.net/~arthur.marsh/20150708469.jpg
This has "Not tainted" which woul
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
- 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 head kernel in 64-bit mode.
>
> Hmm, dis
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 do
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 head kernel in 64-bit mode.
Hmm, disturbing.. I've had my machines run this stuff for weeks and not
had anything like this
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" \
make-kp
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 withou
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 without issue if you remove the
Radeon?
Mos
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 to
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 to and slightly passed the point where
> t
On Mon, Jul 06, 2015 at 06:17:44PM +0930, Arthur Marsh wrote:
> This kernel does go boom, after it locks up I have to do a major power down,
> pull out the graphics card, reboot, shutdown, replace graphics card to get
> things working again properly.
*blink* that seems radical
--
To unsubscr
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 if 32bi
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 if 32bit
> userspace in KVM can reproduce.
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 if 32bit
> userspace in KVM can reproduce.
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 if
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 if 32bit
userspace in KVM can reproduce.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
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
23 matches
Mail list logo