Could someone possibly help?
I have upgraded a machine from RedHat 8.0 to FC2 and the
adaptec-browser1 and adaptec-smbe software that I installed is not working
properly. It looks ok at first glance but if I pull a disk out I only get
informed of the 'informational' type messages.
(Also the
On Wed, 2005-03-16 at 08:58 +0100, Jens Axboe wrote:
Guys, who reviewed this? It looks completely bogus, using kmap() for tha
entire sg list is just wrong and can deadlock easily. The proper way is
of course to skip the virtual address requirement and dma map the sg
array properly.
I suppose
Hayes, Stuart wrote:
This patch will map the sg buffers to kernel virtual memory space in
the functions idescsi_input_buffers() and idescsi_output_buffers().
Without this patch, idescsi passes a null pointer to
atapi_input_bytes() and atapi_output_bytes() when sg pages are in
high memory
On Wed, Mar 16 2005, James Bottomley wrote:
On Wed, 2005-03-16 at 08:58 +0100, Jens Axboe wrote:
Guys, who reviewed this? It looks completely bogus, using kmap() for tha
entire sg list is just wrong and can deadlock easily. The proper way is
of course to skip the virtual address requirement
On Wed, Mar 16 2005, [EMAIL PROTECTED] wrote:
Hayes, Stuart wrote:
This patch will map the sg buffers to kernel virtual memory space in
the functions idescsi_input_buffers() and idescsi_output_buffers().
Without this patch, idescsi passes a null pointer to
atapi_input_bytes() and
On Wed, Mar 16, 2005 at 05:04:47PM +0100, Jens Axboe wrote:
The kmap() isn't just inefficient, it's a problem to iterate over the sg
list and kmap all the pages. That is illegal.
But it's not so tricky to get right, if the punting just happens in the
isr. Basically just iterate over every sg
On Wed, Mar 16 2005, Matthew Wilcox wrote:
On Wed, Mar 16, 2005 at 05:04:47PM +0100, Jens Axboe wrote:
The kmap() isn't just inefficient, it's a problem to iterate over the sg
list and kmap all the pages. That is illegal.
But it's not so tricky to get right, if the punting just happens
On Wed, Mar 16, 2005 at 05:53:39PM +0100, Jens Axboe wrote:
The list doesn't really need dma mapping at that point, the problem here
is that the driver needs to punt to pio mode because of foo. So calling
pci/dma_map_* is pointless, since the CPU will have to do the transfer
anyways. What the
Jens Axboe wrote:
On Wed, Mar 16 2005, Christoph Hellwig wrote:
On Wed, Mar 16, 2005 at 05:53:39PM +0100, Jens Axboe wrote:
The list doesn't really need dma mapping at that point, the problem here
is that the driver needs to punt to pio mode because of foo. So calling
pci/dma_map_* is pointless,
On Wed, Mar 16, 2005 at 10:44:50AM -0800, Mike Christie wrote:
I got lost here. If you are talking about the need to kmap a sglist then
software iscsi has it. iscsi-sfnet used to do
while (...)
kmap()
but I fixed that (I think I need to use kmap_atomic though, is that
correct or
James Bottomley wrote:
This is my current tranch of patches that were waiting the transition
from -rc to released (sorry it's late ... I've been on holiday).
The patch is available here:
bk://linux-scsi.bkbits.net/scsi-for-linus-2.6
Are my 3ware bugfixes in the queue? Currently 3ware claims it
Hi,
What is a reasonable defect list size for an almost new disk
(3 weeks - 146 GB).
scscinfo -d gives me :
Data from Defect Lists
--
3060 entries in manufacturer table.
...
[truncated]
On Wed, Mar 16, 2005 at 11:47:09AM -0800, Jean Tourrilhes wrote:
Hi,
What is a reasonable defect list size for an almost new disk
(3 weeks - 146 GB).
scscinfo -d gives me :
Data from Defect Lists
--
3060
On Wed, 2005-03-16 at 18:53 +, Matthew Wilcox wrote:
On Wed, Mar 16, 2005 at 10:44:50AM -0800, Mike Christie wrote:
I got lost here. If you are talking about the need to kmap a sglist then
software iscsi has it. iscsi-sfnet used to do
while (...)
kmap()
but I fixed that
On Wed, 2005-03-16 at 15:08 -0500, Salyzyn, Mark wrote:
The dpt_i2o driver uses the function memcpy_toio to copy the message
frame to the adapter. Under arch/x86_64/lib/io.c, it's helper function
is defined as:
void __memcpy_toio(unsigned long dst,const void*src,unsigned len)
{
Unsigned long is less than pointer, the reference passed in to the 'dst'
variable.
Sincerely -- Mark Salyzyn
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Matthew Wilcox
Sent: Wednesday, March 16, 2005 3:18 PM
To: Salyzyn, Mark
Cc:
OK, 64 bit unsigned long was the missing piece.
Still locking up when we make the call, will attack this as a different
issue.
Sincerely -- Mark Salyzyn
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Arjan van de Ven
Sent: Wednesday, March 16, 2005
On Wed, 2005-03-16 at 13:35 -0500, Jeff Garzik wrote:
Are my 3ware bugfixes in the queue? Currently 3ware claims it handled
the interrupt, even the interrupt is a shared one and the event was
meant for another driver.
Not in my queue ... you could try Adam Radford directly ...
James
-
To
Hi
Thanks for reviewing this patch!
On Wed, 16 Mar 2005, Jens Axboe wrote:
On Wed, Mar 16 2005, James Bottomley wrote:
...
I agree the kmap is inefficient. The efficient alternative is to do
dma_map_sg() and use kmap_atomic() in the interrupt routine where we do
the PIO cleanup---I'm
Jens Axboe wrote:
On Wed, Mar 16 2005, [EMAIL PROTECTED] wrote:
Hayes, Stuart wrote:
This patch will map the sg buffers to kernel virtual memory space in
the functions idescsi_input_buffers() and idescsi_output_buffers().
Without this patch, idescsi passes a null pointer to
On Wed, 2005-03-16 at 15:19 -0500, Salyzyn, Mark wrote:
Unsigned long is less than pointer, the reference passed in to the 'dst'
variable.
that's on that other OS, not this one ;)
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL
On Wed, 2005-03-16 at 08:02 -0500, Salyzyn, Mark wrote:
The applications require the Adaptec Branch of the driver in order to
function (mainly because the kernel.org branch drops the
/proc/scsi/aacraid entry). I have submitted a patch to Mark Haverkamp
for consideration where we add the
On Wed, 2005-03-16 at 15:31 -0500, Jeff Garzik wrote:
More info? Were they dropped on purpose, or just never arrived?
If dropped on purpose, what was the reason?
You posted substantive updates to a maintained driver. Adam Radford is
the maintainer, but I haven't heard anything from him
On Wed, Mar 02, 2005 at 11:46:47AM -0800, Patrick Mansfield wrote:
Use bus dev_attrs to create the default scsi_device attributes.
Note sdev_default_attrs is not a pointer to an array (like
scsi_sysfs_sdev_attrs), and so DEVICE_ATTR's can be removed, and __ATTR
used instaed.
Any comments on
Hello,
Here is a patch for megaraid_mm/megaraid_mbox driver which makes it
2.20.4.6.
Following is brief on the changes:
1. Added compat_ioctl
2. Reordered inputs on memset
3. Convert pci_module_iit to pci_register_driver
4. Added DMA_{32,64}BIT_MASK 5. Modified PCI PnP ID table
Signed-off-by:
On Wed, Mar 16 2005, Guennadi Liakhovetski wrote:
Hi
Thanks for reviewing this patch!
On Wed, 16 Mar 2005, Jens Axboe wrote:
On Wed, Mar 16 2005, James Bottomley wrote:
...
I agree the kmap is inefficient. The efficient alternative is to do
dma_map_sg() and use kmap_atomic() in
26 matches
Mail list logo
