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 kma
"Ju, Seokmann" <[EMAIL PROTECTED]> wrote:
>
> 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
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: Se
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 comment
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 (neit
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 inf
3060 seems low when you compare your disk's size to my 18 Gig disks!
I have 17 disks, 18 Gig each.
2112 entries (16896 bytes) in manufacturer table.
1902 entries (15216 bytes) in manufacturer table.
2048 entries (16384 bytes) in manufacturer table.
1304 entries (10432 bytes) in manufacturer table
On Wed, Mar 16, 2005 at 01:56:25PM -0600, Matt Domsch wrote:
> 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 :
> > --
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 PROTE
James Bottomley wrote:
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 directl
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
>>> ata
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---
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 3:18
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: linux-scsi@vger.kerne
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)
> {
>
On Wed, Mar 16, 2005 at 03:08:13PM -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)
> {
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)
{
__inline_memcpy((void *) dst,src,len);
}
The first argument should
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
-
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
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
> --
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]
---
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 han
On Wed, Mar 16 2005, Mike Christie wrote:
> 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
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
> corr
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, si
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, since
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 t
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 h
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 ever
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, 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 requi
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, 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 suppo
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 information back to the /sys
filesystem, and the /proc filesystem (
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 browse
35 matches
Mail list logo
