Alan,
>How about the patch below instead? It's a bit easier to use, in that it
>doesn't require users to know about a new parameter. Also it retries at
>1-second intervals for up to 5 seconds, which makes it a little more
>flexible. If this works for you, I'll submit it for inclusion in the
On Mon, 11 Jul 2005, Roberts-Thomson, James wrote:
> OK, it turns out that for this particular key, a two second pause after
> "sd_spinup_disk" is called and before "sd_read_capacity" will make it work.
> The 'dmesg' (or syslog) output is still ugly, however; but once I realised
> that it was "sd_
All,
> > Can you try adding delays before, after, and inbetween the calls to
> > sd_read_capacity, sd_read_write_protect_flag, and
> sd_read_cache_type,
> > all near the end of sd_revalidate_disk?
>
> Yes, will do this and post results.
OK, it turns out that for this particular key, a two sec
Back again! (had a 2 day course last week).
> > There are three delays from my patch in the above list,
>
> Yes. Why are there three instead of just one? The
> sd_revalidate_disk routine should only be called once
> (although a bug in recent kernels causes it to be called twice).
Don't know
On Wed, 6 Jul 2005, Roberts-Thomson, James wrote:
> Alan,
>
> > Try putting delays at various spots in sd_revalidate_disk:
> > the beginning, the middle, and the end.
>
> OK, the attached patch works for me when sd_mod was loaded with delay_use=1.
>
> Now I'm quite prepared to be told that th
Alan,
> Try putting delays at various spots in sd_revalidate_disk:
> the beginning, the middle, and the end.
OK, the attached patch works for me when sd_mod was loaded with delay_use=1.
Now I'm quite prepared to be told that this is a really horrible and
inapproprate hack (given that I am not
On Wed, 6 Jul 2005, Roberts-Thomson, James wrote:
> One more additional note is that the key came with some s/w that allows you
> to partition the key into "private" and "public" areas, where the private
> area is accessed by a password. Naturally, this s/w (Ustorage) is Windows
> only; but looki
Alan,
Thanks very much for the input.
> > I'm trying to diagnose an issue with a USB "Memory Key"
> (128Mb Flash
> > drive) on my workstation (i386 Linux 2.6.12 kernel, using udev 058).
> >
> > When connecting the key, the kernel fails to read the
> partition table,
> > and therefore the blo
8 matches
Mail list logo