I have a two Marvel Sata Marvell 88NV9143 controller disks on the
board. When I tried to load mvumi module
I'm getting an invalid signature error. Further debugging I found any
read on memory mapped IO returns 0x (-1).
And also the PCI bar address is 64bit where as device is 32-bit
Hi Randy,
I reported:
on i386:
# CONFIG_CRC_T10DIF is not set
drivers/built-in.o: In function `lpfc_bg_crc':
(.text+0x3cb3c9): undefined reference to `crc_t10dif'
and then James Bottomley provided the patch.
I don't know why he added GENERIC_CSUM to it.
Thanks for investigating
To run discovery over iSER we need to advertize the CAP_TEXT_NEGO capability
towards user space. Also need to make sure the login RX buffer is posted when
SendTargets TEXT PDUs are sent. For that end, we use a setting of the
ISCSI_PARAM_DISCOVERY_SESS iscsi param as an indication that this is
-Original Message-
From: Jingoo Han [mailto:jg1@samsung.com]
Sent: Thursday, August 08, 2013 6:46 AM
To: 'James Bottomley'
Cc: DL-MegaRAID Linux; 'James Bottomley'; linux-scsi@vger.kernel.org;
Jingoo Han
Subject: [PATCH V2 4/8] [SCSI] megaraid: add missing __iomem annotation
Added
PCI core will initialize device MSI/MSI-X capability in
pci_msi_init_pci_dev(). So device driver should use
pci_dev-msi_cap/msix_cap to determine whether the device
support MSI/MSI-X instead of using
pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
Access to PCIe device config space again will
PCI core will initialize device MSI/MSI-X capability in
pci_msi_init_pci_dev(). So device driver should use
pci_dev-msi_cap/msix_cap to determine whether the device
support MSI/MSI-X instead of using
pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
Access to PCIe device config space again will
PCI core will initialize device MSI/MSI-X capability in
pci_msi_init_pci_dev(). So device driver should use
pci_dev-msi_cap/msix_cap to determine whether the device
support MSI/MSI-X instead of using
pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
Access to PCIe device config space again will
PCI core will initialize device MSI/MSI-X capability in
pci_msi_init_pci_dev(). So device driver should use
pci_dev-msi_cap/msix_cap to determine whether the device
support MSI/MSI-X instead of using
pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
Access to PCIe device config space again will
PCI core will initialize device MSI/MSI-X capability in
pci_msi_init_pci_dev(). So device driver should use
pci_dev-msi_cap/msix_cap to determine whether the device
support MSI/MSI-X instead of using
pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
Access to PCIe device config space again will
I'm good with it. You folks understand the config dependencies better
than I.
-- james
Acked-By: James Smart james.sm...@emulex.com
On 8/8/2013 3:47 AM, Anton Blanchard wrote:
Hi Randy,
I reported:
on i386:
# CONFIG_CRC_T10DIF is not set
drivers/built-in.o: In function `lpfc_bg_crc':
On Fri, 2013-08-02 at 10:06 -0700, James Bottomley wrote:
On Thu, 2013-08-01 at 16:57 -0400, Ewan D. Milne wrote:
From: Ewan D. Milne emi...@redhat.com
Generate a uevent when the following Unit Attention ASC/ASCQ
codes are received:
2A/01 MODE PARAMETERS CHANGED
2A/09
I am. Mr. Raymond Khumalo, Head
Accounts Management Section, of a
well-known
Bank here in South Africa. Can i
trust you on a transaction deal worth
US$10,000,000.if interested contact
me for details Email:
mrraymondkhumal...@gmail.com
--
To unsubscribe from this list: send the line
On Wed, Aug 7, 2013 at 9:31 AM, Douglas Gilbert dgilb...@interlog.com wrote:
So what kind of signal was leading to your stomping on the memory?
Was it user generated or something like SIGIO, SIGPIPE or a RT signal?
It was sometimes SIGHUP (for reopening log files) and sometimes
SIGALARM (for
From: Ewan D. Milne emi...@redhat.com
Generate a uevent when the following Unit Attention ASC/ASCQ
codes are received:
2A/01 MODE PARAMETERS CHANGED
2A/09 CAPACITY DATA HAS CHANGED
38/07 THIN PROVISIONING SOFT THRESHOLD REACHED
3F/03 INQUIRY DATA HAS CHANGED
3F/0E
If mpt2sas_base_map_resources takes an early error path then its
counterpart, mpt2sas_base_free_resources needs to be careful about
cleaning up:
1 - _base_mask_interrupts and _base_make_ioc_ready require memory
mapped I/O registers, make sure that this is true.
2 - _base_free_irq
Hi Sreekanth,
Here are the patches that address your offlist feedback and testing of
earlier patchset versions.
I tested with as many early exits as I could think of inside of
mpt2sas_base_map_resources to verify, so I believe all error paths
should be safe and message-log-friendly.
Regards,
If mpt3sas_base_map_resources takes an early error path then its
counterpart, mpt3sas_base_free_resources needs to be careful about
cleaning up:
1 - _base_mask_interrupts and _base_make_ioc_ready require memory
mapped I/O registers, make sure that this is true.
2 - _base_free_irq
This patch essentially removes the disk spinup wait time from the system S3
resume delay. It can be a very significant improvement on systems with large
SATA disks which can take several seconds to spin up. On the systems I've
tested this patch reduces the resume time to around half a second
On Thu, 2013-08-08 at 12:08 -0400, Ewan Milne wrote:
On Fri, 2013-08-02 at 10:06 -0700, James Bottomley wrote:
On Thu, 2013-08-01 at 16:57 -0400, Ewan D. Milne wrote:
From: Ewan D. Milne emi...@redhat.com
+ * scsi_report_lun_change - Set flag on all *other* devices on the same
target
sd_do_mode_sense() is no longer called with a fixed length buffer.
Updated its description to reflect the same.
Signed-off-by: ChinmayVS cvs...@gmail.com
---
drivers/scsi/sd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index
On 08/08/2013 9:10 PM, Yijing Wang wrote:
PCI core will initialize device MSI/MSI-X capability in
pci_msi_init_pci_dev(). So device driver should use pci_dev-
msi_cap/msix_cap to determine whether the device support MSI/MSI-X
instead of using pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
21 matches
Mail list logo
