; usb/usbd -v
Try 'usb/usbd -d1' for more information.
It's getting stranger. I just did a fresh install from the 20071222
image (from which I've done a succesfull install on the same machine
and disk before), and it gives me the same error.
Two things that I haven't mentioned before and that may be relevant are these:
1. I zeroed the target
Richard Bilson [EMAIL PROTECTED] schrieb:
and an issue related to the
fact that we need to encrypt users' data.
For the record, s3venti does encrypt blocks that it writes to S3. It
uses a single key, making it rather vulnerable to dictionary attacks,
but I haven't come up with a way to do
Thanks, I have downloaded but not yet installed QEMU. I will try this soon.
Regards
Chris Saunders
Eris Discordia [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Mon, 11 Feb 2008 14:54:20 -, Chris Saunders
[EMAIL PROTECTED] wrote:
As far as I know there is no Open dialog
Looking at /sys/src/cmd/usb/usbd/usbd.c, I wonder whether
your problem has something to do with these lines?
//unconscionable kludge (testing camera)
if(d-class == 10) setup0(d, RH2D|Rinterface, SET_INTERFACE, 10, 0, 0);
On Feb 12, 2008 10:19 AM, [EMAIL PROTECTED] wrote:
1. I zeroed the target harddisk before installation like this: dd -if
/dev/zero -of /dev/sdC1/data.
You wiped out the MBR on the disk, use DOS's FDISK/MBR (sic) to
restore it, it is the least painful way to fix this type of problem,
in my
Actually, partfs(8) provides devsd-compatible partitions and is
probably a better choice for this than fs(3). It wasn't cited in
usbdisk(4)'s SEE ALSO, but it is now.
thanks for the update. i have switched to a slightly
more agreeable key but i have a new way to fail. the key
works the first time. but the second time i connect the same
key, i get
; usbfat:
setupreq: write err: No response
usb/disk: describedevice: error writing usb
I'll take a look, but I'm afraid it's not going to help. I've already
tried NetBSD's MBR and Plan 9's MBR (using disk/mbr), and they both
don't fix the problem.
That makes two of us. I have the same problem with compact flash
devices. If I don't get the geometry exactly right (I did, a
We added booting via the BIOS to 9load specifically for USB (though it
may have other uses), so that we wouldn't have to add to 9load and
maintain 8,000 lines, and growing, of complex USB code (though that's
likely due to the inherent complexity of USB rather than being the
fault of those who have
geoff pointed out that usb/disk pulls in a lot of stuff and might need
some work to run in the kernel.
Usb root can be done by putting usb/disk and usb/usbd into /boot and
hacking /sys/src/9/boot/local.c a bit. I tried it once and it worked
albeit slowly. However, getting 9load to use usb
Actually, partfs(8) provides devsd-compatible partitions
Cool - I hadn't noticed when that appeared.
Do you mean why doesn't the ctl file accept partition commands?
You can always use fs(3) for that. But usb root is not very
practical anyway, at least with uhci, because of a stubborn
bug in the driver which makes transfers very very slow. Now
there's ohci support I would be interested to
Take a look at Qemu Manager: http://www.davereyn.co.uk/about.htm
2008/2/12, Chris Saunders [EMAIL PROTECTED]:
Thanks, I have downloaded but not yet installed QEMU. I will try this soon.
Regards
Chris Saunders
Eris Discordia [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On
On Feb 9, 2008 4:25 AM, Russ Cox [EMAIL PROTECTED] wrote:
provide any facility to attach as a different user. So, I modified the
attach strategy to look for a USER environment variable before falling
back on getuser(). I've attached the diff, hopefully I got everything.
The name in the
For the record, s3venti does encrypt blocks that it writes to S3. It
uses a single key, making it rather vulnerable to dictionary attacks,
but I haven't come up with a way to do better without changing the
venti protocol. Suggestions are welcome.
Beware: I am no security expert, I know just
one final question, is there an advantage to usb/disk creating a fs
that's incompatable with devsd? it would seem to make booting
from usb root difficult.
Do you mean why doesn't the ctl file accept partition commands?
You can always use fs(3) for that. But usb root is not very
practical
1. I zeroed the target harddisk before installation like this: dd -if
/dev/zero -of /dev/sdC1/data.
You wiped out the MBR on the disk, use DOS's FDISK/MBR (sic) to
restore it, it is the least painful way to fix this type of problem,
in my experience.
++L
Hello,
Thank you for working for usb support.
In trying usb/disk I have a question:
term% usb/disk
term% disk/partfs /n/disk/0/data
term% disk/mbr /dev/sdXX/data
term% disk/fdisk -baw /dev/sdXX/data
term% disk/prep /dev/sdXX/plan9
empty0 2 (2 sectors, 1.00 KB)
9fat
Nemo found a bug in usb/lib/dump.c that may well account for
this. I incorporated his change (and fixed a bug in his code :-).
I'll ask Geoff to push it out today.
Sape
excellent. i'll give it a shot.
- erik
usbd is exiting when i have a camera which is off
attached:
; usb/usbd -v
; echo $status
usbd 1827: usbd: setup0: usb0/1: transaction error
- erik
Nemo found a bug in usb/lib/dump.c that may well account for
this. I incorporated his change (and fixed a bug in his code :-).
I'll ask
I believe my writing turns out a bit unclear. What I meant to say was
that I actually did a dd -if /dev/zero -f /dev/sdC1/raw before I
figured out that it should have been dd -if /dev/zero -of
/dev/sdC1/data instead. Hence I was wondering if writing those zeroes
to the raw file could be the
On Feb 12, 2008 1:50 PM, erik quanstrom [EMAIL PROTECTED] wrote:
1. I zeroed the target harddisk before installation like this: dd -if
/dev/zero -of /dev/sdC1/data.
2. I also accidentally did this first when I really meant to zero the
disk: dd -if /dev/zero -f /dev/sdC1/raw.
you did the
Looking at /sys/src/cmd/usb/usbd/usbd.c, I wonder whether
your problem has something to do with these lines?
//unconscionable kludge (testing camera)
if(d-class == 10) setup0(d, RH2D|Rinterface, SET_INTERFACE, 10, 0, 0);
thanks for the suggestion, but the camera was a red herring.
it was
1. I zeroed the target harddisk before installation like this: dd -if
/dev/zero -of /dev/sdC1/data.
2. I also accidentally did this first when I really meant to zero the
disk: dd -if /dev/zero -f /dev/sdC1/raw.
you did the right thing. the raw file is for issuing raw commands to
the drive.
You could reduce your storage bill by using file names to store the data
through information hiding rather than the content ;)
http://www.geocities.com/patchnpuki/other/compression.htm
One of these days ..
my reading of the sla seemed to indicate they count bucket names
against you.
You could reduce your storage bill by using file names to store the data
through information hiding rather than the content ;)
http://www.geocities.com/patchnpuki/other/compression.htm
One of these days ..
* Uriel ([EMAIL PROTECTED]) wrote:
It is more likely that the information you want is not even in the man
page, gnu man pages are severely crippled, and if you want the real
documentation you have to travel to info hell which is likely to
contain ten times as much (mis)information and be ten
Nemo found a bug in usb/lib/dump.c that may well account for
this. I incorporated his change (and fixed a bug in his code :-).
I'll ask Geoff to push it out today.
Sape
excellent. i'll give it a shot.
- erik
Give it a shot now:
/sys/src/cmd/usb/lib/dump.c
#include u.h
Warning!, the dump.c I sent Sape has a bug.
search for len = b[0]-1, in pdesc(), replace that with
len = b[0].
sorry for the mistake.
From: [EMAIL PROTECTED]
To: 9fans@cse.psu.edu
Reply-To: 9fans@cse.psu.edu
Date: Tue Feb 12 15:36:36 CET 2008
Subject: Re: [9fans] usbd problem
30 matches
Mail list logo
