On Tue, 9 Jan 2018, Josh Poimboeuf wrote:
> On Tue, Jan 09, 2018 at 11:44:05AM -0800, Dan Williams wrote:
> > On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina <ji...@kernel.org> wrote:
> > > On Fri, 5 Jan 2018, Dan Williams wrote:
> > >
> > > [ ... snip ...
, and something comparable for eBPF JIT?
Is this going to be handled in eBPF in some other way?
Without that in place, and considering Jann Horn's paper, it would seem
like PTI doesn't really lock it down fully, right?
[1] https://bugs.chromium.org/p/project-zero/issues/attachmentText?aid=287305
--
Jiri Kosina
SUSE Labs
() is currently writing out one of
the other per-CPU buffers.
Please also take a look at per-CPU printk() function redirection mechanism
that got added because of printk()-from-NMI madness ('printk_func'
pointer). It might be useful for your purposes as well.
--
Jiri Kosina
SUSE Labs
/reboot) ultimately succeeds.
But with all the timeouts, dbus, Failed to issue method call: Did
not receive a reply messages, this is getting close to impossible.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord
-flags);
-
/* Now setup the interrupt handler */
retval = request_irq(pdev-irq, twa_interrupt, IRQF_SHARED, 3w-9xxx,
tw_dev);
if (retval) {
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord
,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
-disabling MSIs in pci_msi_init_pci_dev()
makes the device work properly again.
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
I am adding Adam Radford as a recepient as well, to see whether he is
able
to provide some more explanation why this device would expose
On Tue, 27 Aug 2013, Jiri Kosina wrote:
On Tue, 27 Aug 2013, Jiri Kosina wrote:
Commit d5dea7d95 (PCI: msi: Disable msi interrupts when we initialize a
pci device) makes MSIs be forcibly disabled at boot time.
It turns out that this breaks 3ware controller -- if MSIs are disabled
to any commands that are being sent to it after
initialization).
Reverting d5dea7d95 or not force-disabling MSIs in pci_msi_init_pci_dev()
makes the device work properly again.
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
I am adding Adam Radford as a recepient as well, to see whether he
[ adding Bjorn and Eric to CC, sorry for omitting you originally ]
On Tue, 27 Aug 2013, Jiri Kosina wrote:
Commit d5dea7d95 (PCI: msi: Disable msi interrupts when we initialize a
pci device) makes MSIs be forcibly disabled at boot time.
It turns out that this breaks 3ware controller
...@stratus.com
Cc: Jens Axboe ax...@kernel.dk
Cc: Jiri Kosina jkos...@suse.cz
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Bart Van Assche bvanass...@acm.org
Cc: linux-scsi@vger.kernel.org
---
block/scsi_ioctl.c| 9 -
drivers/block/paride/pd.c | 2 ++
drivers/block
of a simple NULL pointer check.
Signed-off-by: Joe Lawrence joe.lawre...@stratus.com
Cc: Jens Axboe ax...@kernel.dk
Cc: Jiri Kosina jkos...@suse.cz
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Bart Van Assche bvanass...@acm.org
Cc: linux-scsi@vger.kernel.org
---
block/blk-core.c
);
+ spin_unlock_irqrestore(ha-vport_slock, flags);
if (!vha-flags.init_done)
ql_log(ql_log_info, vha, 0x2010,
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo
){-.}
This seems to be real. You should be seeing that since 3.5-rc1 already
though ... ?
Does the patch below fix that?
From: Jiri Kosina jkos...@suse.cz
Subject: [PATCH] [SCSI] qla2xxx: fix potential deadlock on ha-hardware_lock
Lockdep reports:
=== [ cut here
On Sat, 21 Jul 2012, Jiri Kosina wrote:
The device identifies itself as
0d:05.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X
Fusion-MPT SAS (rev 01) Subsystem: NEC Corporation SAS1068
and seems to be functionally compatible with 0x0054 PID.
The request for support
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
I guess the Subsystem: NEC Corporation is telling us some rebranding
story, including the PID change ... ?
Hi guys,
any feedback on this please?
Thanks.
NACK.
Vendor 0x1000, Device id 0x0055 is actually an old LSI MegaRAID
several
times in the past (see [1] [2] and more), but aparently the PCI ID never made it
to mptsas_pci_table[].
[1] http://comments.gmane.org/gmane.linux.scsi/63836
[2] http://lkml.indiana.edu/hypermail/linux/kernel/0701.2/1715.html
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
I guess
17 matches
Mail list logo
