On Mon, 19 Sep, at 01:09:22PM, Waiman Long wrote:
> On 09/19/2016 10:51 AM, Matt Fleming wrote:
> >On Mon, 19 Sep, at 10:48:12AM, Waiman Long wrote:
> >>With this patch applied, I am able to successfully boot both the 16-socket
> >>12-TB and 8-socket 6TB configurations without problem.
> >>
>
On Mon, 19 Sep, at 01:09:22PM, Waiman Long wrote:
> On 09/19/2016 10:51 AM, Matt Fleming wrote:
> >On Mon, 19 Sep, at 10:48:12AM, Waiman Long wrote:
> >>With this patch applied, I am able to successfully boot both the 16-socket
> >>12-TB and 8-socket 6TB configurations without problem.
> >>
>
On Mon, 19 Sep, at 10:48:12AM, Waiman Long wrote:
>
> With this patch applied, I am able to successfully boot both the 16-socket
> 12-TB and 8-socket 6TB configurations without problem.
>
> Tested-by: Waiman Long
Could you please show your dmesg after booting with
On Mon, 19 Sep, at 10:48:12AM, Waiman Long wrote:
>
> With this patch applied, I am able to successfully boot both the 16-socket
> 12-TB and 8-socket 6TB configurations without problem.
>
> Tested-by: Waiman Long
Could you please show your dmesg after booting with efi=debug? The
part I'm
On 09/19/2016 08:43 AM, Matt Fleming wrote:
On Sun, 18 Sep, at 11:09:08PM, Waiman Long wrote:
On 09/14/2016 03:19 PM, Linus Torvalds wrote:
On Wed, Sep 14, 2016 at 12:14 PM, Waiman Long wrote:
In the stack backtrace above, the kernel hadn't even reached SMP boot after
On 09/19/2016 08:43 AM, Matt Fleming wrote:
On Sun, 18 Sep, at 11:09:08PM, Waiman Long wrote:
On 09/14/2016 03:19 PM, Linus Torvalds wrote:
On Wed, Sep 14, 2016 at 12:14 PM, Waiman Long wrote:
In the stack backtrace above, the kernel hadn't even reached SMP boot after
about 50s. That was
On Sun, 18 Sep, at 11:09:08PM, Waiman Long wrote:
> On 09/14/2016 03:19 PM, Linus Torvalds wrote:
> >On Wed, Sep 14, 2016 at 12:14 PM, Waiman Long wrote:
> >>In the stack backtrace above, the kernel hadn't even reached SMP boot after
> >>about 50s. That was extremely slow. I
On Sun, 18 Sep, at 11:09:08PM, Waiman Long wrote:
> On 09/14/2016 03:19 PM, Linus Torvalds wrote:
> >On Wed, Sep 14, 2016 at 12:14 PM, Waiman Long wrote:
> >>In the stack backtrace above, the kernel hadn't even reached SMP boot after
> >>about 50s. That was extremely slow. I tried the 4.7.3
On Sun, 18 Sep, at 11:09:08PM, Waiman Long wrote:
>
> I have finally finished bisecting the problem. I was wrong in saying that
> the 4.7.3 kernel had no problem. It did have. There were some slight
> differences between the 4.8 and 4.7 kernel config files that I used. After
> some further
On Sun, 18 Sep, at 11:09:08PM, Waiman Long wrote:
>
> I have finally finished bisecting the problem. I was wrong in saying that
> the 4.7.3 kernel had no problem. It did have. There were some slight
> differences between the 4.8 and 4.7 kernel config files that I used. After
> some further
On 09/14/2016 03:19 PM, Linus Torvalds wrote:
On Wed, Sep 14, 2016 at 12:14 PM, Waiman Long wrote:
In the stack backtrace above, the kernel hadn't even reached SMP boot after
about 50s. That was extremely slow. I tried the 4.7.3 kernel and it booted
up fine. So I suspect
On 09/14/2016 03:19 PM, Linus Torvalds wrote:
On Wed, Sep 14, 2016 at 12:14 PM, Waiman Long wrote:
In the stack backtrace above, the kernel hadn't even reached SMP boot after
about 50s. That was extremely slow. I tried the 4.7.3 kernel and it booted
up fine. So I suspect that there may be too
Hello,
On Wed, Sep 14, 2016 at 03:55:51PM -0400, Tejun Heo wrote:
> We've used keventd_up() for this purpose and it hasn't been big enough
> an issue as workqueue usages during earlyboot are very rare (only five
> users right now). But, yeah, it's getting used a more and more and
> there's no
Hello,
On Wed, Sep 14, 2016 at 03:55:51PM -0400, Tejun Heo wrote:
> We've used keventd_up() for this purpose and it hasn't been big enough
> an issue as workqueue usages during earlyboot are very rare (only five
> users right now). But, yeah, it's getting used a more and more and
> there's no
On 09/14/2016 05:06 PM, Linus Torvalds wrote:
On Wed, Sep 14, 2016 at 12:34 PM, Waiman Long wrote:
I can try, but the 16-socket system that I have at the moment takes a long
time (more than an hour) for one shutdown-reboot cycle. It may not be really
more interrupts in
On 09/14/2016 05:06 PM, Linus Torvalds wrote:
On Wed, Sep 14, 2016 at 12:34 PM, Waiman Long wrote:
I can try, but the 16-socket system that I have at the moment takes a long
time (more than an hour) for one shutdown-reboot cycle. It may not be really
more interrupts in 4.8, it may be that the
On Wed, Sep 14, 2016 at 12:34 PM, Waiman Long wrote:
>
> I can try, but the 16-socket system that I have at the moment takes a long
> time (more than an hour) for one shutdown-reboot cycle. It may not be really
> more interrupts in 4.8, it may be that the random driver just
On Wed, Sep 14, 2016 at 12:34 PM, Waiman Long wrote:
>
> I can try, but the 16-socket system that I have at the moment takes a long
> time (more than an hour) for one shutdown-reboot cycle. It may not be really
> more interrupts in 4.8, it may be that the random driver just somehow run
> very
Hello, Linus.
On Wed, Sep 14, 2016 at 12:14:30PM -0700, Linus Torvalds wrote:
> I'm wondering if we couldn't just initialize "system_wq" earlier.
> Right now init_workqueues() is an "early_initcall()", so it's at the
> same priority as a number of other random early initcalls. My gut
> feeling is
Hello, Linus.
On Wed, Sep 14, 2016 at 12:14:30PM -0700, Linus Torvalds wrote:
> I'm wondering if we couldn't just initialize "system_wq" earlier.
> Right now init_workqueues() is an "early_initcall()", so it's at the
> same priority as a number of other random early initcalls. My gut
> feeling is
On 09/14/2016 03:19 PM, Linus Torvalds wrote:
On Wed, Sep 14, 2016 at 12:14 PM, Waiman Long wrote:
In the stack backtrace above, the kernel hadn't even reached SMP boot after
about 50s. That was extremely slow. I tried the 4.7.3 kernel and it booted
up fine. So I suspect
On 09/14/2016 03:19 PM, Linus Torvalds wrote:
On Wed, Sep 14, 2016 at 12:14 PM, Waiman Long wrote:
In the stack backtrace above, the kernel hadn't even reached SMP boot after
about 50s. That was extremely slow. I tried the 4.7.3 kernel and it booted
up fine. So I suspect that there may be too
On 09/14/2016 03:14 PM, Linus Torvalds wrote:
Ugh, I detest this patch.
My gut feeling is that a driver (even a fairly core one like the
random code) should not have to know these kinds of details like
"schedule_work() needs system_wq to have been initialized".
I'm wondering if we couldn't
On 09/14/2016 03:14 PM, Linus Torvalds wrote:
Ugh, I detest this patch.
My gut feeling is that a driver (even a fairly core one like the
random code) should not have to know these kinds of details like
"schedule_work() needs system_wq to have been initialized".
I'm wondering if we couldn't
On Wed, Sep 14, 2016 at 12:14 PM, Waiman Long wrote:
>
> In the stack backtrace above, the kernel hadn't even reached SMP boot after
> about 50s. That was extremely slow. I tried the 4.7.3 kernel and it booted
> up fine. So I suspect that there may be too many interrupts
On Wed, Sep 14, 2016 at 12:14 PM, Waiman Long wrote:
>
> In the stack backtrace above, the kernel hadn't even reached SMP boot after
> about 50s. That was extremely slow. I tried the 4.7.3 kernel and it booted
> up fine. So I suspect that there may be too many interrupts going on and it
>
On 09/14/2016 03:03 PM, Waiman Long wrote:
While booting a 4.8-rc6 kernel on a 16-socket 768-thread Broadwell-EX
system, the kernel panic'ed with the following log:
[ 51.837010] BUG: unable to handle kernel NULL pointer dereference at
0102
[ 51.845635] IP: []
On 09/14/2016 03:03 PM, Waiman Long wrote:
While booting a 4.8-rc6 kernel on a 16-socket 768-thread Broadwell-EX
system, the kernel panic'ed with the following log:
[ 51.837010] BUG: unable to handle kernel NULL pointer dereference at
0102
[ 51.845635] IP: []
Ugh, I detest this patch.
My gut feeling is that a driver (even a fairly core one like the
random code) should not have to know these kinds of details like
"schedule_work() needs system_wq to have been initialized".
I'm wondering if we couldn't just initialize "system_wq" earlier.
Right now
Ugh, I detest this patch.
My gut feeling is that a driver (even a fairly core one like the
random code) should not have to know these kinds of details like
"schedule_work() needs system_wq to have been initialized".
I'm wondering if we couldn't just initialize "system_wq" earlier.
Right now
30 matches
Mail list logo