On 03/22, James Bottomley wrote:
OK, the fix from the SCSI point of view is to make the mpt teardown path
actually work. The whole thing looks to be a complete mess because
there's another place where it will do the wrong thing in
mptscsih_remove(). You always have to call mpt_detach()
On Sun, 23 Mar 2014, Tetsuo Handa wrote:
Thomas Gleixner wrote:
But then systemd/udev mutters:
You migh be able to work around the timeout with udev rules and
OPTIONS+=event_timeout=120, but that code was maybe never used
or tested, so it might not work correctly. [1]
On Sun, 2014-03-23 at 09:04 +0100, Thomas Gleixner wrote:
On Sun, 23 Mar 2014, Tetsuo Handa wrote:
Thomas Gleixner wrote:
But then systemd/udev mutters:
You migh be able to work around the timeout with udev rules and
OPTIONS+=event_timeout=120, but that code was maybe
On Sun, 23 Mar 2014, James Bottomley wrote:
On Sun, 2014-03-23 at 09:04 +0100, Thomas Gleixner wrote:
On Sun, 23 Mar 2014, Tetsuo Handa wrote:
Thomas Gleixner wrote:
But then systemd/udev mutters:
You migh be able to work around the timeout with udev rules and
On Sun, 2014-03-23 at 15:28 +0100, Thomas Gleixner wrote:
On Sun, 23 Mar 2014, James Bottomley wrote:
On Sun, 2014-03-23 at 09:04 +0100, Thomas Gleixner wrote:
On Sun, 23 Mar 2014, Tetsuo Handa wrote:
Thomas Gleixner wrote:
But then systemd/udev mutters:
You migh
Oleg Nesterov wrote:
Tetsuo, what do you think?
I don't like blocking SIGKILL while doing operations that depend on memory
allocation by other processes. If the OOM killer is triggered and it chose
the process blocking SIGKILL in mptsas_init() (I know it unlikely happens),
it generates the OOM
On 03/22, Tetsuo Handa wrote:
Oleg Nesterov wrote:
Tetsuo, what do you think?
I don't like blocking SIGKILL while doing operations that depend on memory
allocation by other processes. If the OOM killer is triggered and it chose
the process blocking SIGKILL in mptsas_init() (I know it
On Sat, 2014-03-22 at 20:25 +0100, Oleg Nesterov wrote:
On 03/22, Tetsuo Handa wrote:
Oleg Nesterov wrote:
Tetsuo, what do you think?
I don't like blocking SIGKILL while doing operations that depend on memory
allocation by other processes. If the OOM killer is triggered and it chose
On Sat, 22 Mar 2014, Oleg Nesterov wrote:
On 03/22, Tetsuo Handa wrote:
Many kernel operations (e.g. mutex_lock() wait_event()
wait_for_completion())
ignore SIGKILL and the current users depend on SIGKILL being ignored. Thus,
commit 786235ee sounds like a kernel API breakage.
On Sat, 22 Mar 2014, Thomas Gleixner wrote:
On Sat, 22 Mar 2014, Oleg Nesterov wrote:
Personally I dislike this change. In fact I think it is ugly. But this
is only my opinion.
It's not only ugly, it's activly wrong. It's as wrong as 786235ee
itself. And 786235ee needs to be reverted and
Oleg Nesterov wrote:
On 03/22, Tetsuo Handa wrote:
Oleg Nesterov wrote:
Tetsuo, what do you think?
I don't like blocking SIGKILL while doing operations that depend on memory
allocation by other processes. If the OOM killer is triggered and it chose
the process blocking SIGKILL in
Thomas Gleixner wrote:
But then systemd/udev mutters:
You migh be able to work around the timeout with udev rules and
OPTIONS+=event_timeout=120, but that code was maybe never used
or tested, so it might not work correctly. [1]
AFAICT from the ubuntu bug system [2] nobody
On 03/20, Oleg Nesterov wrote:
On 03/20, Joseph Salisbury wrote:
There was some testing done with your test kernel. The data collected
while running your kernel is available in the bug report:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/comments/58
Joseph, thanks a
On Fri, Mar 21, 2014 at 11:34 AM, Oleg Nesterov o...@redhat.com wrote:
Yes, it seems that it actually needs 30 secs. It spends most of the time
(30.13286 seconds) in [..]
So how about taking a completely different approach:
- just say that waiting for devices in the module init sequence for
On Fri, 2014-03-21 at 12:32 -0700, Linus Torvalds wrote:
On Fri, Mar 21, 2014 at 11:34 AM, Oleg Nesterov o...@redhat.com wrote:
Yes, it seems that it actually needs 30 secs. It spends most of the time
(30.13286 seconds) in [..]
So how about taking a completely different approach:
-
On 03/19/2014 03:42 PM, Oleg Nesterov wrote:
On 03/19, Oleg Nesterov wrote:
On 03/19, Oleg Nesterov wrote:
But please do not forget that the kernel crashes. Whatever else we do, this
should be fixed anyway. And this should be fixed in driver.
drivers/message/fusion/ is obviously buggy.
On 03/20, Joseph Salisbury wrote:
On 03/19/2014 03:42 PM, Oleg Nesterov wrote:
On 03/19, Oleg Nesterov wrote:
On 03/19, Oleg Nesterov wrote:
But please do not forget that the kernel crashes. Whatever else we do,
this
should be fixed anyway. And this should be fixed in driver.
On 03/19, Oleg Nesterov wrote:
But please do not forget that the kernel crashes. Whatever else we do, this
should be fixed anyway. And this should be fixed in driver.
drivers/message/fusion/ is obviously buggy.
mptsas_probe() does
sh = scsi_host_alloc(...);
if
On 03/19, Oleg Nesterov wrote:
On 03/19, Oleg Nesterov wrote:
But please do not forget that the kernel crashes. Whatever else we do, this
should be fixed anyway. And this should be fixed in driver.
drivers/message/fusion/ is obviously buggy.
Perhaps this is the only problem and Tetsuo
On 03/19/2014 03:42 PM, Oleg Nesterov wrote:
On 03/19, Oleg Nesterov wrote:
On 03/19, Oleg Nesterov wrote:
But please do not forget that the kernel crashes. Whatever else we do, this
should be fixed anyway. And this should be fixed in driver.
drivers/message/fusion/ is obviously buggy.
20 matches
Mail list logo
