Re: anyone got advice on sendmail and TLS on 8.1?
Don't forget to add the following to /etc/make.conf
SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2
SENDMAIL_LDFLAGS+= -L/usr/local/lib
SENDMAIL_LDADD+=-lsasl2
so it will be compiled correctly on the next buildworld.
Nick
On 11 Oct 2010, at 18:14, John Baldwin wrote:
> On Sunday, October 10, 2010 5:22:01 pm Julian Elischer wrote:
>> When I last did sendmail there wasn't any TLS/SSL stuff.
>>
>> has anyone got an exact howto as to how to enable a simple sendmail
>> server?
>>
>> all I want is:
>>
>> TLS and authenticated email submission by me and my family
>> able to forward the email anywhere (maybe just to my ISP but who
>> knows) (outgoing)
>> non TLS submission from outside to reject all mail not to
>> elischer.{org,com}
>> and deliver our mail to mailboxes or gmail (or where-ever /etc/aliases
>> says.).
>>
>> This is probably ALMOST a default configuration
>> but I can't be sure what is needed.. there are several
>> howtos on hte net but they are generally old and differ in details.
>
> Your best bet is probably to look at the docs on sendmail.org. You need to
> recompile the sendmail in base against SASL and need to install cyrus-sasl2
> from ports to manage your authentication database.
>
> --
> John Baldwin
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Mesh networking
It's their own variation on AODV I believe. Nick On 3 Nov 2009, at 13:35, Eric wrote: On Tue, 2009-11-03 at 11:52 +0100, Nick Hibma wrote: Anyone interested in Mesh networking might want to have a look at http://meshcom.com/en/products/meshdriver/ We have started to use the mesh driver (ok, on voyage linux). A port should not be difficult, especially the userland daemon. It's dependencies on Linux syscalls are minimal. Starting it through linux emulation does not work (in my FreeBSD setup). Meshcom says they are happy to look at the port when it is done. Cheers, Nick P.S.: I am not affiliated to them other than that I am very impressed with the quality of the software. Does it IEEE 802.20 compliant? -- Best Regards, Eric L. Chen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Mesh networking
Anyone interested in Mesh networking might want to have a look at http://meshcom.com/en/products/meshdriver/ We have started to use the mesh driver (ok, on voyage linux). A port should not be difficult, especially the userland daemon. It's dependencies on Linux syscalls are minimal. Starting it through linux emulation does not work (in my FreeBSD setup). Meshcom says they are happy to look at the port when it is done. Cheers, Nick P.S.: I am not affiliated to them other than that I am very impressed with the quality of the software. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: What's changed between 7.1 and 7.2
The debugging printf has been changed to not print anything if debuglevel is 0. Nick > On 2009-07-08 19:28, Robert Watson wrote: > > This is effectively debugging output that slipped into the release and > > shouldn't have. I believe it's now removed in 8.x, I'm not sure it's > > been MFC'd to 7.x yet. > > It was indeed removed, with r193131. The diff here: > > http://svn.freebsd.org/viewvc/base/head/sys/geom/label/g_label.c?view=pat >ch&r1=193131&r2=193130&pathrev=193131 > > should apply to 7.x without problems. > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: booting/loading a tool, not kernel
You are aware of nextboot(8)? That you could use to specify the 'kernel' to load on next boot. Also boot.config(5) might be of use. Nick > I'd like to add an entry to my loader menu to load/execute memtest86 > instead of a kernel. It is built as standalone ELF executable, of course. > > Currently I go to a loader prompt and do: > > unload > > load /boot/memtest86 > > boot > > Where should I look to get this into the forth code? > > Suppose I want to extend this approach. > What would be a good name for subdirectory to put such tools? > What would be a good way to add a sub-menu for such tools? > > Also, my current approach means that loader still first loads a standard > kernel and its modules and then replaces them with memetest86. How to > get to a loader menu without pre-loading anything? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Unicode USB strings conversion
> Or you could try to search for a better language ID. Currently the USB > stack (old and new) selects the first language ID in the language string. > Probably there is an english language ID, but not as the first selection. The first part of the string is correct, so I assume that they added some strange characters (like copyright) at the end. Besides, even in the English character set there might be strange characters, for example scandinavian characters in names. Nick ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Unicode USB strings conversion
In the USB code (and I bet it is the same in the USB4BSD code) unicode
characters in strings are converted in a very crude way to ASCII. As I have
a user on the line who sees rubbish in his logs and when using
usbctl/usbdevs/etc., I bet this is the problem.
I'd like to try and fix this problem by using libkern/libiconv.
1) Is this the right approach to convert UTF8 to printable string in the
kernel?
2) Is this needed at all in the short term future? I remember seeing
attempts at making the kernel use UTF8.
3) Does anyone know of a good example in the code without me having to hunt
through the kernel to find it?
For reference: The code that needs replacing is:
usbd_get_string():
s = buf;
n = size / 2 - 1;
for (i = 0; i < n && i < len - 1; i++) {
c = UGETW(us.bString[i]);
/* Convert from Unicode, handle buggy strings. */
if ((c & 0xff00) == 0)
*s++ = c;
else if ((c & 0x00ff) == 0 && swap)
*s++ = c >> 8;
else
*s++ = '?';
}
*s++ = 0;
I haven't got the USB specs handy, but I believe that this is a simple way
of converting LE and BE UTF8 to ASCII.
Nick
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: umass driver speed
Woohoo! Congrats. Nice job. If other people could test this, this should be committed. I'll have to have a quick look at the initialisation code that has been added to see whether there is no problem with that, but from the quick glance I just had, I don't think there is a prolbem in there. Nick > > Bingo! :) > > When I changed the bsqh initialisation, I get speed above 400 KB/s, > that makes me feel much better :) > > I am sending a corrected patch as attachment. > > Tomas > > On Thu, 28 Nov 2002, Ian Dowse wrote: > > > I had a quick look at the patch - one thing I noticed is that you > > are possibly not initialising all of the bsqh fields. In -current, > > bsqh->hlink and bsqh->qh.qh_hlink are set up to point at the `lsqh' > > QH. It might not be the problem though. > > > > Ian > > > -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: umass driver speed
[pats Joe on the head] Well done!
Well, the only sections that are needed are the ones that relate to
uhci_{add,rem}_loop. Do a diff between RELENG_4 and HEAD and filter out
the stuff that you would need to implmenet the bandwidth reclamation.
Nick
> It seems to me that it is present in -CURRENT,
> isn't it ?
> Tomas
>
> On Wed, 27 Nov 2002, Nick Hibma wrote:
>
> >
> > uhci_{add,rem}_loop from
> >
> >
>http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/dev/usb/uhci.c.diff?r1=1.122&r2=1.123
> >
> > is probably what is needed then.
> >
> > Nick
> >
>
>
--
[EMAIL PROTECTED] http://www.van-laarhoven.org/
[EMAIL PROTECTED]http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: umass driver speed
uhci_{add,rem}_loop from
http://cvsweb.netbsd.org/bsdweb.cgi/syssrc/sys/dev/usb/uhci.c.diff?r1=1.122&r2=1.123
is probably what is needed then.
Nick
P.S.: And no,. I don't have the time at the moment to actually do the
work. Patches are welocme. There is another change in that tree that
needs copying at the same time, about control transfers.
>
> On Wed, 27 Nov 2002, Nick Hibma wrote:
>
> >
> > The ZIP Drive is USB as well?
>
> No, it's ATAPI.
>
> > Are you using a UHCI controller (dmesg)?
>
> Yes:
> uhci0: port 0xc000-0xc01f irq 11 at device
> 17.2 on pci0
> usb0: on uhci0
> uhci1: port 0xc400-0xc41f irq 11 at device
> 17.3 on pci0
> usb1: on uhci1
>
> Tomas
>
>
--
[EMAIL PROTECTED] http://www.van-laarhoven.org/
[EMAIL PROTECTED]http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: umass driver speed
The ZIP Drive is USB as well? Are you using a UHCI controller (dmesg)? Nick > > Hello, > > It seems to me that the slowness of umass driver is not caused by msdosfs. > I know about the msdosfs problems, for example when I run dd from my ZIP > drive (with FAT) with request size of 2048, it's extremely slow. When I > change request size to 64K, it gains normal speed (about 1MB/s). > > But with my camera (umass), I get: > > # dd if=/dev/da0s1 of=/tmp/nikon bs=2048 count=10 > 10+0 records in > 10+0 records out > 20480 bytes transferred in 0.379587 secs (53953 bytes/sec) > > # dd if=/dev/da0s1 of=/tmp/nikon bs=4096 count=10 > 10+0 records in > 10+0 records out > 40960 bytes transferred in 0.719477 secs (56930 bytes/sec) > > # dd if=/dev/da0s1 of=/tmp/nikon bs=8192 count=10 > 10+0 records in > 10+0 records out > 81920 bytes transferred in 1.389069 secs (58975 bytes/sec) > > # dd if=/dev/da0s1 of=/tmp/nikon bs=65536 count=10 > 10+0 records in > 10+0 records out > 655360 bytes transferred in 10.832928 secs (60497 bytes/sec) > > # dd if=/dev/da0s1 of=/tmp/nikon bs=524288 count=1 > 1+0 records in > 1+0 records out > 524288 bytes transferred in 8.668605 secs (60481 bytes/sec) > > The speed is nearly the same, no matter about the request size. > > What do you think about it ? > > Tomas > > On Sat, 24 Aug 2002, Nick Hibma wrote: > > > > > Yes, unfortunately it is a known issue in the msdos file system. The > > requests it makes are too small for the driver to take advantage of the > > speed of USB. > > > > Nick > > -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: umass driver speed
> This is the debug output of > #dd if=/dev/da0s1c of=/tmp/data bs=65536 count=3 > > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/512b data/32b sense The 3 64k blocks you asked for are below. > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x28, flags: 0x40, 10b cmd/65536b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x35, flags: 0xc0, 10b cmd/0b data/32b sense > umass0:0:0:0:XPT_SCSI_IO: cmd: 0x1e, flags: 0xc0, 6b cmd/0b data/32b sense So, the blocks are fetched in 64k blocks. Two options: Either the USB stack does not chain the transfers in such a way that the device can run at full performance or otherwise the device chokes on the transfers and forces the chain of transfers to be delayed till the next frame. There is a 'bandwidth reclamation' feature in the NetBSD stack in the UHCI driver of which I do not know whether they made it into the USB stack. An option would be to fetch a timestamp from somewhere (is there a tick counter that counts in HZ?) to see which transfer takes a long time. If there is no other activity transferring 64k should take no more than 64 frames roughly, which 64 msecs. Nick -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: umass driver speed
You would have to switch on UMASS_DEBUG in your kernel config to see whether the driver is actually asked for large chunks. If you ask CAM for 64k blocks it will produce 64k requests, which are passed down to the USB layer, which doesn't cut them up. So in that case there is something else wrong. Nick > > Hello, > > It seems to me that the slowness of umass driver is not caused by msdosfs. > I know about the msdosfs problems, for example when I run dd from my ZIP > drive (with FAT) with request size of 2048, it's extremely slow. When I > change request size to 64K, it gains normal speed (about 1MB/s). > > But with my camera (umass), I get: > > # dd if=/dev/da0s1 of=/tmp/nikon bs=2048 count=10 > 10+0 records in > 10+0 records out > 20480 bytes transferred in 0.379587 secs (53953 bytes/sec) > > # dd if=/dev/da0s1 of=/tmp/nikon bs=4096 count=10 > 10+0 records in > 10+0 records out > 40960 bytes transferred in 0.719477 secs (56930 bytes/sec) > > # dd if=/dev/da0s1 of=/tmp/nikon bs=8192 count=10 > 10+0 records in > 10+0 records out > 81920 bytes transferred in 1.389069 secs (58975 bytes/sec) > > # dd if=/dev/da0s1 of=/tmp/nikon bs=65536 count=10 > 10+0 records in > 10+0 records out > 655360 bytes transferred in 10.832928 secs (60497 bytes/sec) > > # dd if=/dev/da0s1 of=/tmp/nikon bs=524288 count=1 > 1+0 records in > 1+0 records out > 524288 bytes transferred in 8.668605 secs (60481 bytes/sec) > > The speed is nearly the same, no matter about the request size. > > What do you think about it ? > > Tomas > > On Sat, 24 Aug 2002, Nick Hibma wrote: > > > > > Yes, unfortunately it is a known issue in the msdos file system. The > > requests it makes are too small for the driver to take advantage of the > > speed of USB. > > > > Nick > > -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB->ATA devices
> > This would be hard to do right, as the preferred way to talk to USB > > devices is with a request-callback model. The ATA command would > > need to be put into a request structure and handed to the USB device > > driver, and the USB driver would then call back when the request > > completes. There are hacks that can be used to perform the USB > > operations synchronously, but they generally do not handle unexpected > > removal of the device well at all. > > > > There are many possible ATA/ATAPI over USB protocols, so turning > > the ATA request into one or more USB transfers is a bridge-specific > > operation. Basically these odd protocols exist because the manufacturers > > of the various bridges have decided to cut corners and not implement > > the standard USB mass storage interface. > > Sounds like a can of worms better left unopened... Translating the commands in the umass driver is the best you can do I'm afraid. Until the moment of course where you run the ATA driver on a thread that doesn't mind being suspended for 1 or 2 ms during a 'register write' operation. That approach has been considered and hacked into shape for the MIIBUS enabled USB ethernet dongles. Just check out the threads telling you that they won't work and you'll see that it ain't an easy problem to solve. Nick -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB "Memorybird" quirks
I saw the NEW_TRANS code and that seems definitely the way to code. A lot of work though. > There are other commands that can get sent, though -- inquiry, test unit > ready, and start/stop unit are all 6 byte commands, and there are no 10 > byte SCSI equivalents. So how do you handle those now? The problem is only there for commands that have a 10 byte equivalent. The ATAPI spec seems to have dropped the 6 byte ones. So inquiry is not a problem. The end of the command is padded with zeroes. > > And then the third one would be to have a look at for example scsi_cd.c > > and friends and make similar changes there. > > The CD driver already uses 10 byte read and write commands, since the 6 > byte read/write commands are not required for CD type devices. It does use > a 6 byte mode sense/mode select, but since it rolls its own (can't remember > why at the moment), that can be easily modified to look at the transport > type and optionally use a 10 byte command. Ok. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB "Memorybird" quirks
Cheers, I've closed the PR as the same thing has already been done in CURRENT by jhb. Thanks for pointing me at the PR though! Nick On Wed, 10 Apr 2002, Lars Eggert wrote: > There is some (maybe) related code that has been sitting for a while in > PR misc/32490 (http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/32490) > > Lars > -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB to IDE converter
Have a look in the sys/dev/usb/umass.c driver and remove the check for
the CSW tag. I wouldn't be surprised if the firmware is buggered and
doesn't copy the tag from the incoming request into the outgoing packet.
Like so:
heather:n_hibma% diff -wu umass.c.2~ umass.c.2
--- umass.c.2~ Wed Apr 10 21:17:58 2002
+++ umass.c.2 Wed Apr 10 21:17:28 2002
@@ -1500,6 +1500,7 @@
umass_bbb_reset(sc, STATUS_WIRE_FAILED);
return;
+#if 0
} else if (UGETDW(sc->csw.dCSWTag)
!= UGETDW(sc->cbw.dCBWTag)) {
printf("%s: Invalid CSW: tag %d should be %d\n",
@@ -1509,6 +1510,7 @@
umass_bbb_reset(sc, STATUS_WIRE_FAILED);
return;
+#endif
/* CSW is valid here */
} else if (sc->csw.bCSWStatus > CSWSTATUS_PHASE) {
But your firmware is definitely screwed.
Nick
Tech note: The tag is there to enable a driver to send multiple
concurrent requests and manage the replies. So for us it is not really a
problem to ignore it as we do not do concurrent requests (nor does any
firmware actually support it as far as I know).
On Sun, 7 Apr 2002, Brian Dean wrote:
> On Sat, Apr 06, 2002 at 11:41:35PM -0800, Doug White wrote:
> >
> > 'camcontrol rescan 1'?
>
> That provoked this response:
>
> Apr 7 09:36:21 neutrino /kernel: umass1: GoodWay USBIDE GoodWay USBIDE, rev
>1.10/2.60, addr 3
> Apr 7 09:36:21 neutrino /kernel: umass1: Invalid CSW: tag 2359384 should be 1
> Apr 7 09:36:21 neutrino /kernel: umass1: Invalid CSW: tag 2359384 should be 2
> Apr 7 09:36:21 neutrino /kernel: umass1: Invalid CSW: tag 2359384 should be 3
> Apr 7 09:36:21 neutrino /kernel: umass1: Invalid CSW: tag 2359384 should be 4
> Apr 7 09:36:21 neutrino /kernel: umass1: Invalid CSW: tag 2359384 should be 5
>
> Other than that, no change.
>
> -Brian
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
--
[EMAIL PROTECTED] http://www.van-laarhoven.org/
[EMAIL PROTECTED]http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: USB "Memorybird" quirks
Oh, and RBC of course. Anyway, you get my point I guess. Nick > > The class of devices that does not accept 6 byte commands is well known: > ATAPI and UFI. > > Nick > > > It seems to me that umass_scsi_transform() in umass.c is > > the place intended for this kind of things. After the > > first failure (which is detected in umass_bbb_state()), > > a flag (quirk) should be set in the softc, and afterwards > > umass_scsi_transform should translate 6-byte commands to > > 10-byte commands. Doesn't sound too complicated to me. > > > > Or am I totally wrong? > > > > Regards > > Oliver > > > > > > -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB "Memorybird" quirks
minimum_cmd_size is only used for read_write commands, not for others like MODE_SENSE_6 and friends. Nick > > As in, try a 6 byte command, and if that fails try a 10 byte command > > instead? > > As in, if it fails to reset, then > > sc->softc->minimum_cmd_size = 10; > printf( "auto-quirking mumble foo\n"); > > It would let most of the existing quirks table go away, but > would require additional retries. The cool thing is that it > would all happen in the error path, so, other than increasing > the number of retries to cause it to engage by itself without > having to try the disklabel 3 times, which is also failure > mode stuff, it adds no overhead to working devices, and makes > non-working ones work with the overhead they have to have > anyway. > > > > Unfortunately although I'm maintaining USB in -current, I don't have a > > complete in depth understanding of the code yet. :( I'm mainly trying > > to fix my problems by taking from NetBSD. > > I took a look at the code. I have to say it's opaque. It > makes a better door than a window. ;-). > > I haven't figured out how to turn a struct umass_softc * into > a struct da_softc *, or I would have given you an ugly little > patch against an older version of FreeBSD to try. 8-p. > > I think someone with one of these things, or with a quirky > one with the DA_Q_NO_6_BYTE removed from the quirks table, > is going to have to set CAM_DEBUG on big-time, and then > see where the reset error falls out, add a static fail > counter to that place in the code, and then if it fails > and the fail counter >= 3 (for example), reset the minimum > command size to 10. > > That should "just work". > > If the reset is retried enough times, you could get rid of > the quirks entries that existed solely for this quirk; I > think that a > > 6 byte commands not supported: changing to 10 byte commands > > message on the console is probably acceptable "noise" in > trade for getting rid of it, and supporting future devices > with the same problem, without needing to "quirk" them. > > I think DA_Q_NO_SYNC_CACHE might be handleable the same > way, which would get rid of all the quirk entries, and > maybe the need for a quirk table at all (it looks like > the daclose/dadump/dashutdown sync code could be static'ed > and shared, as well). > > Maybe this is a CAM-specific thing, and shouldn't be > handled in the USB code at all (you won't know until > you see a quirked device failure with the CAM debug, or > you write the CAM code to tape and run it through your > dental fillings or otherwise load it into your head). > > -- Terry > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hardware" in the body of the message > -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB "Memorybird" quirks
The class of devices that does not accept 6 byte commands is well known: ATAPI and UFI. Nick > It seems to me that umass_scsi_transform() in umass.c is > the place intended for this kind of things. After the > first failure (which is detected in umass_bbb_state()), > a flag (quirk) should be set in the softc, and afterwards > umass_scsi_transform should translate 6-byte commands to > 10-byte commands. Doesn't sound too complicated to me. > > Or am I totally wrong? > > Regards > Oliver > > -- [EMAIL PROTECTED] http://www.van-laarhoven.org/ [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB "Memorybird" quirks
The problem is that we emulate ATAPI and UFI command sets through converting SCSI commands. These command sets both do not have 6 byte commands. The solution is to have the umass driver pass a quirk back to the CAM layer dynamically for these devices. Any takers for an implementation that doesn't cause a large memory overhead? The solution that doesn't require memory consuming storing of quirks would be to have the da peripheral driver ask the SIM (umass in this case) for the quirks. The umass driver does not know about the attachment of the da driver to the SCSI device we have created (nor should it), so it is difficult to find a way to push the quirk info up to the driver. I'm all ears to good ideas. A second piece of work would be to convert all the other 6 byte commands it produces to their 10 byte equivalents, in the same way it is done in scsi_da.c: Pass softc->minimum_cmd_size into scsi_mode_sense and scsi_mode_select and make those functions use the 10 byte commands where necessary. And then the third one would be to have a look at for example scsi_cd.c and friends and make similar changes there. Don't forget the testing and finishing touches that I haven't described here. That makes it more than the evening's amount of work I could spend on it. And it is not difficult. So, who's going to do it? Send me patches when your done. Nick On Thu, 7 Feb 2002, Eugene M. Kim wrote: > This is a common problem of most umass devices that implements BBB > protocol, and arises from the fact that those devices don't understand > the 6-byte SCSI READ command. You can add a quirk entry to > src/sys/cam/scsi_da.c (refer to quirk entries that have DA_Q_NO_6_BYTE). > > IIRC this problem is being addressed at a more fundamental level on > -current, by adding a 6-byte-to-10-byte READ command translator > somewhere in the abstraction layer. > > Eugene > > On Thu, Feb 07, 2002 at 09:46:28PM +0100, Oliver Fromme wrote: > > > > > > Hi, > > > > I've got a small problem with a nice little thing called > > "USB Memorybird" (Fujitsu-Siemens) ... > > > > It is bascially a 64 MB Flash chip in a small plastic pen > > that you can carry with your keys. It doesn't need any > > battery and you can plug it directly into a USB socket. > > Very neat. > > > > Works without any drivers on WinME and Win2k, so I assume > > it should be some standard USB mass storage device. > > > > FreeBSD 4.5 recognizes it out of the box and attaches it as > > a SCSI disk, but I cannot access it. This is what happens: > > > > >From the boot log: > > > > uhci0: port 0xd400-0xd41f irq 10 at device 7.2 on pci0 > > usb0: on uhci0 > > usb0: USB revision 1.0 > > uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > > uhub0: 2 ports with 2 removable, self powered > > > > This appears when I connect the Memorybird: > > > > umass0: Fujitsu Memorybird, rev 1.00/1.00, addr 2 > > da2 at umass-sim0 bus 0 target 0 lun 0 > > da2: Removable Direct Access SCSI-0 device > > da2: 650KB/s transfers > > da2: 62MB (128000 512 byte sectors: 64H 32S/T 62C) > > > > This is the output from "usbdevs -v" (note that there is a > > ~10 seconds delay!): > > > > Controller /dev/usb0: > > addr 1: self powered, config 1, UHCI root hub(0x), VIA(0x), rev 0x0100 > > port 1 powered > > < ~10 seconds delay > > > port 2 addr 2: power 100 mA, config 1, product 0x0100(0x0100), vendor >0x0d7d(0x0d7d), rev 0x0100 > > > > When I type "fdisk da2", it hangs for a while, then prints: > > > > fdisk: can't open device /dev/da2 > > fdisk: cannot open disk /dev/da2: Input/output error > > > > At the same time, the kernel logs this: > > > > Feb 7 20:00:31 lurza /kernel: umass0: BBB reset failed, TIMEOUT > > Feb 7 20:00:36 lurza /kernel: umass0: BBB bulk-in clear stall failed, TIMEOUT > > Feb 7 20:00:41 lurza /kernel: umass0: BBB bulk-out clear stall failed, TIMEOUT > > Feb 7 20:00:51 lurza /kernel: umass0: BBB reset failed, TIMEOUT > > Feb 7 20:00:56 lurza /kernel: umass0: BBB bulk-in clear stall failed, TIMEOUT > > Feb 7 20:01:01 lurza /kernel: umass0: BBB bulk-out clear stall failed, TIMEOUT > > > > The same happens when I try to dd some block from the > > device to /dev/null. During my experiments I also got > > these messages (I don't know if they're important): > > > > Feb 7 19:54:46 lurza /kernel: da2: reading primary partition table: error reading >fsbn 0 > > Feb 7 19:54:56 lurza /kernel: umass0: BBB reset failed, TIMEOUT > > Feb 7 19:55:01 lurza /kernel: umass0: BBB bulk-in clear stall failed, TIMEOUT > > Feb 7 19:55:06 lurza /kernel: umass0: BBB bulk-out clear stall failed, TIMEOUT > > Feb 7 19:55:06 lurza /kernel: (da2:umass-sim0:0:0:0): Synchronize cache failed, >status == 0x4, scsi status == 0x0 > > > > Is there a chance to get this to run? Clearly the umass > > driver recognizes it and attaches it as a SCSI disk, so > > I assume that it can't be _that_ hard to convince it to > > work with FreeBSD. :) > > > > Are there any quirks that I should try
Re: Mounting FAT16 on USB connected Rio 600
As said below, modify usbdevs/umass.c to recognise your device and then see whether it behaves. If not, try adding the quirks to scsi_da.c (no READS_6 and no cache sync) and see whether that improves things. If it is an ATAPI based device it might be more work to get this device working. Nick On Thu, 23 Aug 2001, Jim Bryant wrote: > Matthew Emmerton wrote: > > >>Hackers, > >> > >>The overwhelming lack of response on -questions suggests I might do better > >>here. I though this would be an easy one. > >> > >>In short, I simply want to know what device to mount and what to do get > >>that device configured. > >> > >># usbdevs -v > >>Controller /dev/usb0: > >>addr 1: self powered, config 1, UHCI root hub(0x), Intel(0x), rev > >> > > 0x0100 > > > >> port 1 powered > >> port 2 addr 2: self powered, config 1, Diamond Multimedia Digital Audio > >> > > Player(0x5001), Diamond Multimedia(0x045a), rev 0x0100 > > > >>/kernel: ugen0: at uhub0 port 2 (addr 2) disconnected > >>/kernel: ugen0: detached > >>/kernel: ugen0: Diamond Multimedia Diamond Multimedia Digital Audio > >> > > Player, rev 1.00/1.00, addr 2 > > > > Since this device is recognized by the kernel as 'ugen0', it doesn't know > > that it's a storage unit, and explains why you can't mount it. > > > > In order to use this device, you'll have to update the USB subsystem to > > recognize this device as a storage unit, and perhaps do some other code > > hacking before you can access it as a SCSI disk. > > > > Hopefully someone else on the list can provide you with more details (as in, > > how do I do what I need to do to get this thing working!) > > > For an example of how to do this, please see the changes to: > > /usr/src/sys/dev/usb/umass.c > /usr/src/sys/dev/usb/usbdevs > /usr/src/sys/dev/usb/usbdevs.h > /usr/src/sys/dev/usb/usbdevs_data.h > /usr/src/sys/cam/scsi/scsi_da.c > > These changes were just committed to solve the exact problem you are having, instead >it was for the MicroTech CameraMate > CompactFlash/SmardCard reader. grep -i microtech on those files and look in the >vicinity of the hits for the changes. The two .h > files don't have to be changed, just run the makefile in that directory after >changing usbdevs. > > Since I don't have a Diamond MP3 player, I can't do this. Although I didn't write >the changes for the MicroTech CameraMate, I did > learn a bit from the experience testing them, and it really doesn't look that hard >once you figure out what is going on. > > Oh yeah, once you have it working, come back here, and post the patches asking that >they be further tested and committed! It can > take a little while, but it'll be worth it for the next guy. > > You may also want to search the archives and see if anyone else has announced >patches being available for testing, that's how I came > across the CameraMate patches that were just committed as a result of my testing >[and asking for them to be committed until a > committer noticed I was asking]. I searched the archives, found that someone had >done some patches, and advertised the fact asking > for others to test them, this was from back in April. A few weeks ago, I wrote him, >and asked for a copy, although they didn't go > in straight from patch, they were easy enough to put in by hand, and generate >-current patches. After testing them out and finding > they work, it was just a matter of asking for them to be committed. > > Welcome to open-source, community-supported operating systems! > > Should you choose to take this assignment, Matt, the secretary will disavow your >actions if you are caught. Good luck! ;^) > > jim > -- > ET has one helluva sense of humor! > He's always anal-probing right-wing schizos! > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: disconnecting from detached zip drive
Have a look at the umass driver. When I wrote the detach code I never managed to actually detach the SIM. It would panic on reattach. I never bothered to figure out why. What the driver does: When the module loads it does not immediatelly attach itself to CAM as a SIM as I might want to unload it. When it finds a device it wants to tell CAM about it registers the SIM, announces the device, and is ready to start servicing requests. On detach it only removes the drive from CAM and not the SIM. However, there is some code in there that shows how I *think* detaching the SIM should work. So there should be a starting point. Another example of a detachable SIM would be the AIC driver I believe. Ask Warner Losh, at [EMAIL PROTECTED], he wrote the detach code for that driver I believe. I'd be very interested to hear about it, if you find a reliable solution. Nick On Tue, 12 Jun 2001, j mckitrick wrote: > > hi all, > > i'm working on turning the zip driver and all the ppbus devices into > modules. So far, i have the vpo (zip driver) detaching, but i have problems > when i reattach. > > In the initial attach() call, we allocate a tiny bit of memory for a device > controlling microsequence, and we call cam_sim_alloc(), xpt_bus_register(), > and then rescan the bus. If we fail, we call cam_simq_free() if the > xxx_alloc call failed, and we call cam_sim_free() if xxx_register() fails. > > In detach(), i am experimenting (!) and right now i free() the microsequence > (unrelated to cam) and call cam_sim_free(). > > Here is the problem: when i detach, everything looks fine. I attach() when i > reload the module, and the log message says it is now allocating device vpo0 > and vpo1. There is only supposed to be vpo0, of course. It also assigns > these as da1 and da2, instead of da0. Now, when i try to mount the drive, i > get a page fault in cam and/or mount, depending on what i did in detach(). > > What needs to be done to completely disconnect the zip drive from cam, so > that the new attachment looks like it is starting over from scratch? > > Jonathon > -- > Tech support: Try this. Arrange the parts in neat piles. Stand on your > chair until you can see over your cubicle walls. Now shout "Does anybody > know how to read a manual?" > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Resource reservation idea
> > - Some dummy driver which grabs the resource. The dummy driver would > >need to be unloaded when the actual driver needs the resources. > > This sounds attractive, but it's hard to find the dummy driver when > you want to open the bidding for one or more devices again. You also end > up with the ugly case where the device has more resources than the driver > uses; you end up needing a placeholder of some sort for these as well, so > you might as well just built it into the way the bus thinks about child > devices and be done with it. It was suggested some time ago to do this by having a priority value that indicates a dummy, say -1. When a driver is loaded, all dummies are detached and the probe is restarted. The dummies are quiet if not cold booting to avoi a storm of dummies announcing themselves again and again. Nick -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD 4.3 crashing with USB hub attached...
If you could compile a kernel with debugging and debugger makeoptions DEBUG=-g options DDB and then type trace show registers and take it from there, that would be appreciated. Typing panic at the debugger prompt creates a crashdump which you can then fish out of swap space if you have dumpdev set in rc.conf. Nick On Mon, 14 May 2001, Chris Dillon wrote: > On Mon, 14 May 2001, Shannon Hendrix wrote: > > > Did you notice, before the crash, that the kernel had some trouble > > querying the offending device? That happens with me, and then a > > little while later in the boot it crashes. > > Yes, the symptoms were the same as yours. The initial probing during > boot took quite a while, and generated a few errors if I remember > correctly, then a panic shortly afterwards. I'm going to try my USB > joypad on my own 4.3-STABLE box tonight and see if I encounter any > problems, since I just got a new OHCI USB controller for it (I was > having what I can only explain as EMI/RFI problems with my on-board > USB controller). > > I'll be going to my friend's place this weekend, so I can get details > on what is happening with the joystick in question. > > > -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] >FreeBSD: The fastest and most stable server OS on the planet. >For IA32 and Alpha architectures. IA64, PPC, and ARM under development. >http://www.freebsd.org > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD 4.3 crashing with USB hub attached...
It starts to look like memory trampling. I changed the code a bit and all of a sudden the device was accepted and no error 'no report descriptor' was displayed. :-( Try and add 'err' to the print statement that prints 'no report descriptor' in uhid.c. That should give you an indication in what part of that subroutine the code breaks (if it displays that error at all). So, I'll start looking for an error like that. *sigh* I HATE those bugs. They are so hard to find and in the end it is always some stupid little typo or off-by-one error. Dfr found an off-by-one error 'implemented' by me the other day (buffer[sizeof(buffer)] = '\0'). The symptoms were that the code would crash within throw, which made him chase through the gcc sources and Fred knows what else. Took him about 3 hours to, by chance, notice the problem. That cost me a round of beers :-) Nick > > I believe I had a similar problem back on 4.2-RELEASE with a PSX->USB adapter. > > >http://www.geocrawler.com/mail/thread.php3?subject=Broken-by-design+USB+device%3F&list=159 > > > > I sent the offending hardware off to Nick Hibma for him to look at, uh, 4 > > months ago. Is he back from vacation yet? > > Did you send him crash details? Would you mind sharing them with me if > you did? I want to do the same on my system and compare them. Might be > helpful to compare the two incidents. > > I've so far been unable to trigger a kernel panic with any other USB > hardware. I have another force feedback device to try and that's > pretty much it for me. > > After that I will submit a more detailed bug report if possible. > > -- > [EMAIL PROTECTED] _ > __/ armchairrocketscientistgraffitiexenstentialist > "And in billows of might swell the Saxons before her,-- Unite, oh > unite! Or the billows burst o'er her!" -- Downfall of the Gael > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken-by-design USB device?
Oh, and another thing: a kernel panicing is unacceptable, even with bad hardware (except possibly for hardware faults. There is not a lot you can do about those). We've found one non-trivial bug, and I have the feeling that we are looking at another one (possibly a stack or device list corruption bug), which I'm determined to find. If you could send me the make and model (basically all the numbers (including the FCC one) on the label on the device, that would be appreciated. I'll have a look around to see whether I can find another one. We have a PlayStation 2 Developer's Kit in the office, so I'm interested to see the controllers work. We develop a game for PlayStation 2 and Windows (but it runs on FreeBSD as well :-), so being able to use the gamepad converter on FreeBSD would be a laugh. Hm, is it one of these? http://www.psxshop.com/shownews.asp?NewsID=1870 http://www.allusb.com/products/P10227.html http://www.angelcd.com/angelcd/psxusbcon.html http://www.baysoftgames.com/baysoftgames/pssmartjoy2.html http://www.dcs.com.hk/misc/mc_joybox.htm http://www.goldenshop.com.hk/AI-trad/pc/pc_psxn64usb.htm http://www.smartjoy.com/ or was it a do-it-your-self adapater http://www.users.globalnet.co.uk/~snandhe/usbpads.htm There is quite a few of those it seems. Or I have loads of duplicates ... That could be as well :) Cheers, Nick > If I'm following you, the info above will just prove that something is too > broken to figure out. If I can find another one of these things I'll just mail > it to you. Other than that, I'll stop wasting your time :) > > Thank you very much for the help. > > --- > Jon Simola <[EMAIL PROTECTED]> | "In the near future - corporate networks > Systems Administrator | reach out to the stars, electrons and light > ABC Communications | flow throughout the universe." -- GITS > > > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: scsi and PS2 mode parallel port programming
You've been speaking to Nicolas Souchu, right? He has written the current driver and seems to know a fair bit about this topic. Nick > | I'll put this on my pile of things to and dig through the CAM changes to > | find it. There weren't that many in the past year. > > I finally heard from the guy who noticed the change, and asked if he could > help localize it. > > | I don't know much about the PS2 mode nor the parallel port driver > | (allthough I've had my fingers in there, as you know). > > A parallel port in ECP mode should support PS2 without any problem, correct? > And if I recall, it worked under 3.x, so that *should* rule out a buggy BIOS > or hardware anomaly. I *hate* when problems only afflict my machine. > > > jcm > -- > o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o > | Jonathon McKitrick ~ | > | "I prefer the term 'Artificial Person' myself." | > o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken-by-design USB device?
First of all, you are not wasting my time (I _asked_ for the info, right?). More probably it is the other way around with you having to crash you machine all the time ... :-) Second the info your supplying is good quality. Thanks for that. I'll have a look after the weekend (I'll try and not be a sad person while on holiday) ... oh hell ... I have enough space on my laptop for a usr/src/sys tree of STABLE ... sigh, they'll hate me now... Thanks. Nick On Thu, 11 Jan 2001, Jon Simola wrote: > On Mon, 8 Jan 2001, Nick Hibma wrote: > > > Just as a note on the side, the fact that the attach of the generic > > driver fails (while setting config 0, which is a sort of a soft > > reset) could indicate that there is something fishy going on with > > respect to fetching the report descriptor. I seems to freeze. > > I'd still bet on the hardware being suspect. It's got all the prime labelling > of a quality product: "PS-PC USB Converter" "Full Colors" "Special Design, > Extra Stable & Highly Compatibility" > > > And now back to your scheduled 'panic' demolition: > > > > It still bombs in the middle of DEVOPMETH in: > > > >device_probe_t *m = (device_probe_t *) DEVOPMETH(dev, device_probe); > > > > which is > > > >#define DEVOPMETH(DEV, OP) \ > > ((DEVOPDESC(OP)->offset >= DEVOPS(DEV)->maxoffset) \ > > ? DEVOPDESC(OP)->deflt \ > > : DEVOPS(DEV)->methods[DEVOPDESC(OP)->offset]) > > > > while executing > > > >56: 3b 02 cmp(%edx),%eax > > > > with edx == dev->ops and eax == device_probe_ops->offset (don't you hate > > i386 assembler syntax?) and edx apparently being 0. > > > > Which as far as I can see is impossible in the subr_bus.c code. So that > > leaves 'memory spamming' as the only option :-( Apart from that, I have > > no clue which driver tries to attach after the > > ugen driver is finished. Because that is the last driver that makes an > > attempt. > > > > Could you do the following: Boot the machine and when it panics type the > > following commands: > > > > show registers > > db> show registers > cs 0x8 > ds 0xc0a20010 > es 0xc0150010 await+0xe4 > fs 0xc0300010 > ss0x10 > eax0x9 > ecx 0xc0d32400 > edx 0 > ebx0x6 > esp 0xc030b920 > ebp 0xc030b920 > esi 0xc0a227b0 > edi 0xc0d32400 > eip 0xc011d58a DEVICE_PROBE+0xe > efl0x90282 > > > x/x $ecx,0x20 > > db> x/x $ecx,0x20 > 0xc0d32400: 0 0 0 0 > 0xc0d32410: 0 0 0 c0d2ac40 > 0xc0d32420: 0 c0a220400 0 > 0xc0d32430: 0 0 0 0 > 0xc0d32440: 0 0 0 0 > 0xc0d32450: 0 0 0 0 > 0xc0d32460: 0 0 0 0 > 0xc0d32470: 0 0 0 0 > > > x/c *($ecx+0x24),0x10 > > db> x/c *($ecx+0x24),0x10 > 0xc0a22040: uhid0\000\000\000\000\000\000\000\000\000\000\000 > > > which will print three things: the contents of all registers (show > > registers), then the 32 longs at address $ecx (x/x $ecx,20), basically > > the contents of the struct device in DEVICE_PROBE, in which the 6th > > element (at +0x14) should be zero. And then the string that is pointed > > to by the nameunit element in the struct device. This last one should > > give us a hint at which device is failing. > > > > Never mind if the last one gives you a page fault. nameunit might be > > zero. > > > > I really am at a loss what this could be :( > > If I'm following you, the info above will just prove that something is too > broken to figure out. If I can find another one of these things I'll just mail > it to you. Other than that, I'll stop wasting your time :) > > Thank you very much for the help. > > --- > Jon Simola <[EMAIL PROTECTED]> | "In the near future - corporate networks > Systems Administrator | reach out to the stars, electrons and light > ABC Communications | flow throughout the universe." -- GITS > > > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: scsi and PS2 mode parallel port programming
> I can *try*, but it was someone else who spotted the changes, and I can't > seem to contact him. But he also did not find a specific change. I can > give it a shot, but I would guess it has to do with handling the scsi status > codes. I'll put this on my pile of things to and dig through the CAM changes to find it. There weren't that many in the past year. > | Where does the 0x01 come from? From the drive or from the drivers? > > Directly from the drive. The imm module asks the drive itself if it has any > more status to return, and it returns the 0x01 value. > > Also, have you ever gotten r_dtr to work in PS2 mode? All I ever get is > 0x01 returned, never any valid data, even though the negociate routine says > PS2 is working an accepted. I don't know much about the PS2 mode nor the parallel port driver (allthough I've had my fingers in there, as you know). Nick -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: scsi and PS2 mode parallel port programming
> 2. In the list of scsi error codes, 0x00 is no error, and the defacto > errors start with 0x02. However, in PS2 mode, when asked for status, the > zip drive returns 0x01. If I ignore any byte with this bit set, the drive > seems to work okay, but this is a crude and potentially risky fix. Is there > any way to find out what this actually means? Could it just be a stray bit? > Or is it an additional scsi status that should be handled? I *believe* PS2 > mode quit working for parallel port zips after a commit to the cam/scsi > system Dec 1999, but I am not familiar with that code, so I didn't know > where to start looking. Could you point a date (or date range) when that commit to CAM was? I'm vaguely familiar with it and more than willing to help. Where does the 0x01 come from? From the drive or from the drivers? > I am very interested in contributing my meager skills to the BSD effort in > this manner, but I need a little help getting pointed in the right > direction. Thanks in advance for any help anyone can offer. -hackers is probably the best place for these questions if you want to try and find a person with the necessary skills. Nick -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken-by-design USB device?
> uhid0: vendor 0x product 0x0667, rev 1.00/2.88, addr 2, iclass 3/0 > uhid0: no report descriptor > device_probe_and_attach: uhid0 attach returned 6 > ugen0: vendor 0x product 0x0667, rev 1.00/2.88, addr 2 > ugen0: setting configuration index 0 failed > device_probe_and_attach: ugen0 attach returned 6 Just as a note on the side, the fact that the attach of the generic driver fails (while setting config 0, which is a sort of a soft reset) could indicate that there is something fishy going on with respect to fetching the report descriptor. I seems to freeze. And now back to your scheduled 'panic' demolition: It still bombs in the middle of DEVOPMETH in: device_probe_t *m = (device_probe_t *) DEVOPMETH(dev, device_probe); which is #define DEVOPMETH(DEV, OP) \ ((DEVOPDESC(OP)->offset >= DEVOPS(DEV)->maxoffset) \ ? DEVOPDESC(OP)->deflt \ : DEVOPS(DEV)->methods[DEVOPDESC(OP)->offset]) while executing 56: 3b 02 cmp(%edx),%eax with edx == dev->ops and eax == device_probe_ops->offset (don't you hate i386 assembler syntax?) and edx apparently being 0. Which as far as I can see is impossible in the subr_bus.c code. So that leaves 'memory spamming' as the only option :-( Apart from that, I have no clue which driver tries to attach after the ugen driver is finished. Because that is the last driver that makes an attempt. Could you do the following: Boot the machine and when it panics type the following commands: show registers x/x $ecx,0x20 x/c *($ecx+0x24),0x10 which will print three things: the contents of all registers (show registers), then the 32 longs at address $ecx (x/x $ecx,20), basically the contents of the struct device in DEVICE_PROBE, in which the 6th element (at +0x14) should be zero. And then the string that is pointed to by the nameunit element in the struct device. This last one should give us a hint at which device is failing. Never mind if the last one gives you a page fault. nameunit might be zero. I really am at a loss what this could be :( Nick > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc011d58a > stack pointer = 0x10:0xc030b920 > frame pointer = 0x10:0xc030b920 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > interrupt mask = net tty bio cam > kernel: type 12 trap, code=0 > Stopped at DEVICE_PROBE+0xe: cmpl0(%edx),%eax > db> trace > DEVICE_PROBE(c0d32400,c0d32400,c0d32800,0,0) at DEVICE_PROBE+0xe > device_probe_child(c0d32800,c0d32400,c0d32500,0,c0d32530) at device_probe_child+0xc1 > device_probe_and_attach(c0d32400) at device_probe_and_attach+0x3d > usbd_probe_and_attach(c0d32800,c0d32500,2,3,c0d32500) at usbd_probe_and_attach+0xef > usbd_new_device(c0d32800,c0d33000,1,200,2,c0d327c0) at usbd_new_device+0x1dd > uhub_explore(c0d32980,c0d32a00,c0d31580,0,c030be50) at uhub_explore+0x1d4 > usb_attach(c0d32a00,c030be6c,c0154967,c0d32a00,c0d33000) at usb_attach+0xf1 > DEVICE_ATTACH(c0d32a00,c0d33000,c0d31580,0,1) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d32a00) at device_probe_and_attach+0x63 > uhci_pci_attach(c0d31580,c030beb8,c0154967,c0d31580,c0d31580) at >uhci_pci_attach+0x33f > DEVICE_ATTACH(c0d31580,c0d31580,c0d31b00,0,0) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d31580) at device_probe_and_attach+0x63 > bus_generic_attach(c0d31a80,c030bef0,c0154967,c0d31a80,c0d31a80) at >bus_generic_attach+0x16 > DEVICE_ATTACH(c0d31a80,c0d31a80,c0d31c80,0,1) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d31a80) at device_probe_and_attach+0x63 > bus_generic_attach(c0d31b00,c030bf28,c0154967,c0d31b00,c0d31b00) at >bus_generic_attach+0x16 > DEVICE_ATTACH(c0d31b00,c0d31b00,c0a25800,0,1) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d31b00) at device_probe_and_attach+0x63 > bus_generic_attach(c0d31c80,c0d31c80,c030bf54,c011d60e,c0d31c80) at >bus_generic_attach+0x16 > nexus_attach(c0d31c80,c030bf70,c0154967,c0d31c80,c0d31c80) at nexus_attach+0xd > DEVICE_ATTACH(c0d31c80,c0d31c80,c02791f0,31,1) at DEVICE_ATTACH+0x2e > device_probe_and_attach(c0d31c80) at device_probe_and_attach+0x63 > root_bus_configure(c0a25800,c0258f8c,0) at root_bus_configure+0x16 > configure(0,309c00,31,0,c011d014) at configure+0x33 > mi_startup(c030bfb4,b0206,ffe,31,c0159069) at mi_startup+0x70 > begin() at begin+0x4b > db> > > > --- > Jon Simola <[EMAIL PROTECTED]> | "In the near future - corporate networks > Systems Administrator | reach out to the stars, electrons and light > ABC Communications | flow throughout the universe." -- GITS > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-h
Re: umodem and manual
I have no Zyxel modem, nor do I have any specs for what the device. So you might be better off asking on the usb-bsd mailing list: USB BSD list <[EMAIL PROTECTED]> Nick On Fri, 8 Dec 2000, Kaltashkin Eugene wrote: > KE: I try testing 3com USB modem, but don't know, how connect to him ? > KE: Maybe i can get some help about it ? > > I found problem (MAKEDEV create umodem0 with rw--- permissions, change it to > 660) > When Zyxel Omni USB modems be supported in FreeBSD kernel ? > > -- > Best Regards > ZHECKA-RIPN > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: umodem and manual
The change to MAKEDEV will be committed. Thanks! Nick > KE: I try testing 3com USB modem, but don't know, how connect to him ? > KE: Maybe i can get some help about it ? > > I found problem (MAKEDEV create umodem0 with rw--- permissions, change it to > 660) > When Zyxel Omni USB modems be supported in FreeBSD kernel ? > > -- > Best Regards > ZHECKA-RIPN > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken-by-design USB device?
There is, I think, at least a bug in subr_bus.c that might cause this,
although, this is just a hunch. I've not been able to explain what's
happening yet.
What is happening is that device_probe_child sets the device class, and
in case of an error unsets it. But in this case attach (instead of
probe) returns an error and hence the devclass _should_ be unset for
that device (it didn't have a devclass to start with) to force it back
to its virgin state, but isn't.
If you could review his patch dfr, that would be appreciated.
This is an issue in current as well.
Jon, could you try the attached patch and tell me whether that works for
you?
Cheers,
Nick
On Tue, 2 Jan 2001, Jon Simola wrote:
> On Sat, 30 Dec 2000, Nick Hibma wrote:
>
> > The panic is definitely bad. It happens straight after failing the
> > attach?
>
> Yep, but only during the kernel boot. Hot plugging the device after the system
> is booted spews the same errors to the console but does not cause a panic:
>
> uhid0: no report descriptor
> device_probe_and_attach: uhid0 attach returned 6
>
> > plug the device in again, and after it has panicked (it will drop into
> > the debugger), type trace. That would give me a hint at where it
> > crashes.
>
> Here you go. If you need anything else, please ask.
>
> kernel: type 12 trap, code=0
> Stopped at DEVICE_PROBE+0xe: cmpl0(%edx),%eax
> db> trace
> DEVICE_PROBE(c1142d00,c1142d00,c1139100,0,0) at DEVICE_PROBE+0xe
> device_probe_child(c1139100,c1142d00,c1142e00,0,c1142e30) at
> device_probe_child+0xc1
> device_probe_and_attach(c1142d00) at device_probe_and_attach+0x29
> usbd_probe_and_attach(c1139100,c1142e00,2,3,c1142e00) at
> usbd_probe_and_attach+0xef
> usbd_new_device(c1139100,c113a000,1,200,2,c11390c0) at usbd_new_device+0x1dd
> uhub_explore(c1139280,c1139300,c1139e80,0,c0456e64) at uhub_explore+0x1d4
> usb_attach(c1139300,c0456e7c,c01afc0b,c1139300,c113a000) at usb_attach+0xf1
> DEVICE_ATTACH(c1139300,c113a000,c1139e80,0,c0456ea0) at DEVICE_ATTACH+0x2e
> device_probe_and_attach(c1139300) at device_probe_and_attach+0x4f
> uhci_pci_attach(c1139e80,c0456ec4,c01afc0b,c1139e80,c1139e80) at
> uhci_pci_attach+0x33f
> DEVICE_ATTACH(c1139e80,c1139e80,c1136400,0,c0456ed4) at DEVICE_ATTACH+0x2e
> device_probe_and_attach(c1139e80) at device_probe_and_attach+0x4f
> bus_generic_attach(c1136380,c0456ef8,c01afc0b,c1136380,c1136380) at
> bus_generic_attach+0x16
> DEVICE_ATTACH(c1136380,c1136380,c1136580,0,c0456f08) at DEVICE_ATTACH+0x2e
> device_probe_and_attach(c1136380) at device_probe_and_attach+0x4f
> bus_generic_attach(c1136400,c0456f2c,c01afc0b,c1136400,c1136400) at
> bus_generic_attach+0x16
> DEVICE_ATTACH(c1136400,c1136400,c0e25800,0,c0456f3c) at DEVICE_ATTACH+0x2e
> device_probe_and_attach(c1136400) at device_probe_and_attach+0x4f
> bus_generic_attach(c1136580,c1136580,c0456f58,c012740e,c1136580) at
> bus_generic_attach+0x16
> nexus_attach(c1136580,c0456f70,c01afc0b,c1136580,c1136580) at nexus_attach+0xd
> DEVICE_ATTACH(c1136580,c1136580,c039a710,45b000,c0456f80) at
> DEVICE_ATTACH+0x2e
> device_probe_and_attach(c1136580) at device_probe_and_attach+0x4f
> root_bus_configure(c0e25800,c036d38c,0) at root_bus_configure+0x16
> configure(0,454c00,45b000,0,c0126df4) at configure+0x33
> mi_startup(c0456fb4,b0206,ffe,45b000,c01b42f9) at mi_startup+0x70
> begin() at begin+0x4b
>
> > The controller probably requires some work because a fake report
> > descriptor is needed to make it possible for the uhid driver to talk to
> > it. It does not provide any information on where the information for the
> > buttons and axes is stored in the descriptor returned on the interrupt
> > pipe.
>
> ---
> Jon Simola <[EMAIL PROTECTED]> | "In the near future - corporate networks
> Systems Administrator | reach out to the stars, electrons and light
> ABC Communications | flow throughout the universe." -- GITS
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
--
Qube Software, Ltd. Private:
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.qubesoft.com/ http://www.etla.net/~n_hibma/
Index: subr_bus.c
===
RCS file: /home/ncvs/src/sys/kern/subr_bus.c,v
retrieving revision 1.54.2.7
diff -u -r1.54.2.7 subr_bus.c
--- subr_bus.c 2000/08/03 06:36:38 1.54.2.7
+++ subr_bus.c 2001/01/07 13:51:15
@@ -1140,6 +1140,7 @@
{
device_t bus = dev->parent;
int error = 0;
+int hasclass
Re: Broken-by-design USB device?
The panic is definitely bad. It happens straight after failing the attach? If you could recompile the kernel with options DDB makeoptions DEBUG=-g plug the device in again, and after it has panicked (it will drop into the debugger), type trace. That would give me a hint at where it crashes. The controller probably requires some work because a fake report descriptor is needed to make it possible for the uhid driver to talk to it. It does not provide any information on where the information for the buttons and axes is stored in the descriptor returned on the interrupt pipe. Nick > I've got a little USB device that allows Playstation controllers to be > used on a PC. If it's plugged in while booting FreeBSD 4.2-RELEASE (the > shipped GENERIC kernel), I get: > > uhci0: port 0xd400-0xd41f irq 3 at > device 4.2 on pci0 > usb0: on uhci0 > usb0: USB revision 1.0 > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > uhid0: vendor 0x product 0x0667, rev 1.00/2.88, addr 2, iclass 3/0 > uhid0: no report descriptor > device_probe_and_attach: uhid0 attach returned 6 > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc012663a > stack pointer = 0x10:0xc044a938 > frame pointer = 0x10:0xc044a938 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > interrupt mask = net tty bio cam > trap number = 12 > panic: page fault > Uptime: 0s > Automatic reboot in 15 seconds - press a key on the console to abort > > > After poking around in the uhid and usb code, I'm beginning to think that > this adapter is just broken by design. Can someone a bit more familiar > with the USB stuff comment on that? Thanks. > > For identifying what this is, there's not a lot of info available. It shows > up in Windows as a "Monster Gamepad" with 4 analog axis and 16 buttons, and > just has a single 20 pin DIPP chip inside with these markings (looks like a > PLA to me): > CY7C63000A-PC > 9946 G 02 518003 > > --- > Jon Simola <[EMAIL PROTECTED]> | "In the near future - corporate networks > Systems Administrator | reach out to the stars, electrons and light > ABC Communications | flow throughout the universe." -- GITS > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
In that case it might be that they are using some kind of private command to set the SCSI subsequently to different IDs. I'll check whether I have the device here and if so, I will try and snoop that command off the wire. Thanks for the pointer! Nick On Sun, 12 Nov 2000, James FitzGibbon wrote: > * Nick Hibma ([EMAIL PROTECTED]) [001112 06:01]: > > > I don't know. The only thing I know is that the protocol on the USB > > wire does not let you select the SCSI id, just the LUN. > > I've confirmed that under Windows this cable works with any SCSI ID, but > only if you install the Microtech driver. Otherwise, it doesn't show up > (i.e. identical to FBSD). Presuming that their driver is actually just a > ID mapping layer, would the same thing be feasible under BSD? > > I'll fire off a note to their support people and see if they can at least > confirm my line of thinking here. > > -- > j. > > James FitzGibbon [EMAIL PROTECTED] > Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
I don't know. The only thing I know is that the protocol on the USB wire does not let you select the SCSI id, just the LUN. Nick On Fri, 10 Nov 2000, Chris Dillon wrote: > On Fri, 10 Nov 2000, Nick Hibma wrote: > > > This makes sense as the adapter is not a ful controller, just a > > cheapo interface. > > > > You cannot select the SCSI id from the USB driver. > > Hmm.. Since I was looking for a "true" USB-SCSI controller, obviously > this thing won't work. If it only works with devices set to ID 0, it > will never work with a SCSI ZIP drive which only has settings for ID 5 > or 6 (which is one thing I would use it with). Do the Shuttle-based > USB-SCSI adapters have the same limitation? > > > -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] >FreeBSD: The fastest and most stable server OS on the planet. >For IA32 and Alpha architectures. IA64 and PowerPC under development. >http://www.freebsd.org > > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
This makes sense as the adapter is not a ful controller, just a cheapo interface. You cannot select the SCSI id from the USB driver. Nick On Fri, 10 Nov 2000, James FitzGibbon wrote: > * Nick Hibma ([EMAIL PROTECTED]) [001109 17:31]: > > > Hm, I missed the zip story. You seem to have all the bits that are > > necessary in your kernel. > > > > Could you compile your kernel/module with UMASS_DEBUG defined and send > > me the output after an attach? > > As it turns out, I got it working, but only when the device is on SCSI ID 0. > Any other SCSI id and the device is not found when I run 'camcontrol rescan > 0' > > The output is rather large, so I put it on a web server: > > http://people.targetnet.com/~james/dmesg.plugin > http://people.targetnet.com/~james/dmesg.rescan > > (plugin is the dmesg output when I plugged it into the USB port, and rescan > is the additional output when I ran camcontrol rescan 0). > > Thanks. > > -- > j. > > James FitzGibbon [EMAIL PROTECTED] > Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
The cable is pretty decent and the fact that it does not support the call is not a problem. Nick On Thu, 9 Nov 2000, Chris Dillon wrote: > On Thu, 9 Nov 2000, Nick Hibma wrote: > > > This is not a problem as the thing works although it displays the > > message. Because it does not support the call it gives an > > indication that multi LUN devices are not supported. > > > > I have one of these cables and managed to newfs a 4Gb SCSI drive. > > > > Was anything connected to the cable when you connected it? > > I'm looking for a USB to SCSI converter myself... are there any that > are a little more well-behaved and work great with FreeBSD and Windows > (preferably one that Win98+ will see without having to carry around a > driver disk)? I doubt I'll ever attach multi-lun devices to it > either, but I don't like my options limited. :-) > > > -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] >FreeBSD: The fastest and most stable server OS on the planet. >For IA32 and Alpha architectures. IA64 and PowerPC under development. >http://www.freebsd.org > > > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
Hm, I missed the zip story. You seem to have all the bits that are necessary in your kernel. Could you compile your kernel/module with UMASS_DEBUG defined and send me the output after an attach? The 'GetMAXLUN not supported' thing does not make the driver fail, it makes it just assume that the LUN is always 0. Nick On Thu, 9 Nov 2000, James FitzGibbon wrote: > * Nick Hibma ([EMAIL PROTECTED]) [001109 14:52]: > > > > > This is not a problem as the thing works although it displays the > > message. Because it does not support the call it gives an indication > > that multi LUN devices are not supported. > > > > I have one of these cables and managed to newfs a 4Gb SCSI drive. > > > > Was anything connected to the cable when you connected it? > > Yes, I've tried with a Yahama external CDR and a Syquest Syjet drive. In > neither case did the device show up on the probe. I do have "SCSI over USB" > working on the box, since I regularly use a USB zip drive on the same > machine and it comes up as device da0 right after the 'umass-sim0' probe. > > Can you share your kernel config and/or dmesg for that 4gb drive you mention > ? > > Thanks. > > -- > j. > > James FitzGibbon [EMAIL PROTECTED] > Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
Which version of the OS? Please update to a recent release of 4-STABLE if you are not there. Did you do a camcontrol rescan 0? What does that produce? All you will need is kldload usb kldload cam kldload umass or compile with the following options (I am not sure whether the CAM module is available in stable) device scbus device da device usb device umass Hope this helps. Nick On Thu, 9 Nov 2000, James FitzGibbon wrote: > * Nick Hibma ([EMAIL PROTECTED]) [001109 14:52]: > > > > > This is not a problem as the thing works although it displays the > > message. Because it does not support the call it gives an indication > > that multi LUN devices are not supported. > > > > I have one of these cables and managed to newfs a 4Gb SCSI drive. > > > > Was anything connected to the cable when you connected it? > > Yes, I've tried with a Yahama external CDR and a Syquest Syjet drive. In > neither case did the device show up on the probe. I do have "SCSI over USB" > working on the box, since I regularly use a USB zip drive on the same > machine and it comes up as device da0 right after the 'umass-sim0' probe. > > Can you share your kernel config and/or dmesg for that 4gb drive you mention > ? > > Thanks. > > -- > j. > > James FitzGibbon [EMAIL PROTECTED] > Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
This is not a problem as the thing works although it displays the message. Because it does not support the call it gives an indication that multi LUN devices are not supported. I have one of these cables and managed to newfs a 4Gb SCSI drive. Was anything connected to the cable when you connected it? Nick > I have a Microtech USB to SCSI converter (see > http://www.microtechint.com/qs-usbscsi.html for details). > > Under Windows (having installed the driver that comes with), everything > works without issue. Under BSD, I get this on boot: > > umass0: Microtech International, Inc. USB-SCSI-HD50, rev 1.00/1.00, addr 3 > umass0: Get Max Lun not supported (STALLED) > > Are there any known workarounds for this problem ? In my particular > application I won't be using multi-lun devices, but I don't think that > making a "maxlun=0" assumption is a good thing to do. > > Are there any known workarounds for this problem ? > > Thanks. > > -- > j. > > James FitzGibbon [EMAIL PROTECTED] > Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-scsi" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dumb usb question
We do not have support for that serial device yet. And it is not straightforward to write support for it. Nick On Tue, 17 Oct 2000, Andrew Gallatin wrote: > > A friend of mine just bought a D-Link USB-S25 USB to Serial Port > converter cable. Given that he cannot make it work under linux and > that I've been trying to sell him on FreeBSD, I'd like to give it a > whirl under FreeBSD. > > What is the appropriate driver? umodem looks like it just deals with > generic serial devices and might do the job. Is that correct? > > Thanks, > > Drew > > -- > Andrew Gallatin, Sr Systems Programmerhttp://www.cs.duke.edu/~gallatin > Duke University Email: [EMAIL PROTECTED] > Department of Computer SciencePhone: (919) 660-6590 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Programming a USB driver
Starting from a Linux driver is an option. Also, you want to subscribe to the usb-bsd mailing list at http://lists.inteltec.com/wws/info/usb-bsd There are some people there that are toying with the idea and someone might have started to work on a driver. Nick > I don't know if this is the right list to post to, so i'm sorry if it is. > > I'm borrowing a Digital Camera, it has only Windows drivers, and I heard > that it may be running in Linux using the CPiA drivers. > > These are my boot msgs: > > uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > ugen0: STMicroelectronics USB Dual-mode Camera, rev 1.10/0.00, addr 2 > > It obviously found something there. Would it be hard to make a driver for > this camera? I would really appreciate some starting places and tips. > > TIA > > Torbjorn Kristoffersen > [EMAIL PROTECTED] > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Creating a list of newbus devices.
The answers are 'no' and 'root_bus'. The 'no' could be revised into something more useful if you are able to tell us what you are trying to do. Nick On Fri, 8 Sep 2000, Nicolai Petri wrote: > Is it possible from kernel mode to create a list of newbus devices ? > And how do I'll get a pointer to the new-bus root (or whatever it's > tecnical name is :) > > --- > Nicolai Petri > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot/kernel debugging
> > You can single step at boot time, by setting the flags in the loader. > > None of this will be source level, correct? Will it at least have labels if > i use a debug kernel? With remote debugging it will be source level debugging, with DDB it will not. In both cases it will have labels. Even in modules. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: modules and newbus
> I got the impression that newbus would make it easier to make kernel > modules out of things. What in general does it take to make something > into a kld? I'm thinking of pcm for example. In general all it takes is a good look at de-allocation of the resources it allocates. Another point with some hardware is that you need to deinitialise it and make it shut up / no longer produce interrupts. Also the encapsulation of the driver into a MODULE needs to be done, which should be fairly trivial or already done. Be reminded that you cannot detach from all the busses, like for example ISA. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot/kernel debugging
In general it is well possible to single step anything in the kernel. You might find occasions where things stop working, and odd cases were things all of a sudden start working, but normally, apart from hardware things, most things are not time critical, or create problems through spin locks. You can single step at boot time, by setting the flags in the loader. set boot_ddb# jump to debugger set boot_gdb# use remote gdb for debugging by default Hope this helps. Nick > I've used softice for debugging under windows, and i was wondering if gdb > offers similar capabilities. It seems the best way to debug the ECP > parallel port problem is to step through the code during the boot phase. > Can this be done, or is there too much timing-critical stuff going on then? > > jm > -- > --- > Jonathon McKitrick -- [EMAIL PROTECTED] > I am a bomb technician. If you see me running, try to keep up. > --- > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: further question to bus_alloc_resource
> > It was just the first driver I got, so far only an example (bad one). > > What about aha? > > It would be nice to be able te detach most drivers. I think that when aha > was converted originally, cam didn't support detach but I'm pretty sure it > does now. The cam_sim_free hasn't been exercised a lot. I've tried using it for the USB Zip drives, but I failed at some stage and left it at that. Basically, you can detach from a drive, but you can't detach from a SIM IMHO. However, the PCCARD ahc driver does detach properly from a SIM, so maybe it does work, and there simply was a bug in my code. One of the things I was not doing, I just noticed, was to send a AC_LOST_DEVICE for path for the SIM. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What do people think of maybe using the sourceforge software?
I guess that most people leading a project could do with a bit of feature creep, features being shoved under their noses. Even if at first you think that source control solves all our problems, it still could be a way to develop new tools and get them running and tried out before committing them to the tree. Second, the projects page we have now, with all due respect to the people that try to keep it reasonably organised, is a mess due to the lack of updates. people only maintain their project pages perhaps, but certainly not the links that lead to them. Being able to work with more people on the same project on an equal bases would be a good idea IMHO. Nick > http://sourceforge.net/project/filelist.php?group_id=1 > > Contains the software used by source forge to implement the > project/help desk/download tracker thingie which they themselves use > to manage the various projects registered with source forge. > > I think it's also reasonable to say that FreeBSD itself is a bit too > large to register and run as a sourceforge project, but why not use > the same software to offer a higher level of "polish" to the existing > project infrastructure? Comments? I'm just playing with this stuff a > bit myself right now and will say more once I actually know more about > it. > > - Jordan > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: in_cksum changes break IPSEC?
The patch below should fix it for you. -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ -- Forwarded message -- Date: Tue, 9 May 2000 12:49:16 +0100 (BST) From: Nick Hibma <[EMAIL PROTECTED]> To: Jonathan Lemon <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: cvs commit: src/sys/alpha/alpha in_cksum.c src/sys/alpha/include in_cksum.h src/sys/i386/i386 in_cksum.c src/sys/i386/include in_cksum.h The following patch makes LINT compile again. Could you commit it if you agree? Thanks. su-2.03# cvs diff Index: fil.c === RCS file: /home/ncvs/src/sys/netinet/fil.c,v retrieving revision 1.11 diff -w -u -r1.11 fil.c --- fil.c 2000/05/01 20:13:50 1.11 +++ fil.c 2000/05/09 11:49:10 @@ -87,6 +87,8 @@ #endif #include "netinet/ipl.h" +#include "machine/in_cksum.h" + #ifndef_KERNEL # include "ipf.h" # include "ipt.h" Index: ip_fil.c === RCS file: /home/ncvs/src/sys/netinet/ip_fil.c,v retrieving revision 1.14 diff -w -u -r1.14 ip_fil.c --- ip_fil.c2000/02/10 21:29:09 1.14 +++ ip_fil.c2000/05/09 11:49:33 @@ -114,6 +114,8 @@ extern int ip_optcopy __P((struct ip *, struct ip *)); #endif +#include "machine/in_cksum.h" + extern struct protosw inetsw[]; On Sat, 6 May 2000, Jonathan Lemon wrote: > jlemon 2000/05/06 11:18:33 PDT > > Modified files: > sys/alpha/alpha in_cksum.c > sys/alpha/includein_cksum.h > sys/i386/i386in_cksum.c > sys/i386/include in_cksum.h > Log: > Make in_cksum() a macro call to in_cksum_skip(), since it provides the > same functionality. Sharing code should help cache issues. > > Remove in_cksum_partial, since its not being used, and we now have > a way to compute partial checksums on mbuf chains. > > Revision ChangesPath > 1.4 +1 -33 src/sys/alpha/alpha/in_cksum.c > 1.5 +3 -4 src/sys/alpha/include/in_cksum.h > 1.20 +1 -344src/sys/i386/i386/in_cksum.c > 1.9 +3 -4 src/sys/i386/include/in_cksum.h > > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: usb stuff
> I am using a usb mouse, and dlink ethernet nic connected to a belkin > usb hub in FreeBSD 4.0R. I also have a "Solidtek ACK-298" keyboard, > but I have not gotten any progress out of it in freebsd. Has anyone > tried usb "direct connect" with freebsd? That would be much cooler > than plip I think... The direct connect thingies are not yet supported. But I have one at home and two different drivers that kind of make it work. The (netgraph based) driver was written by Doug Ambrisko and Julian Elischer. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reserving Resources
> H. This work was on a 4.0-RELEASE system Makes sense. Right, that has not backported yet. I'll do that ASAP (this evening), including the patch where nextunit is no longer used. > BTW, I have a hack to subr_bus that prints detach messages when a > device is detached. This will hoist some code from the drivers that > detach into the bus system. I think it would be useful to commit. > Comments? Hm, maybe you should check device_quiet. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reserving Resources
> In theory, if one matches with a -1 or smaller rather than 0, then it > will be detached on reprobe. Isn't that the case? On -newbus this issue has come up and the conclusion was that there is always some problem rearing its ugly head. On loading a new driver you would have to run a non-intrusive probe on the device (if at all possible, some USB devices won't let you do that), the driver needs to detach (if possible, what if they attached to a CAM SIM which you should not delete) and the new driver needs to attach and initialise the device (if possible, what about ISA cards that freeze if you treat them the wrong way?). The issue is pretty hairy and for now I think the solution is to make any stub use DEVICE_NOMATCH (see pci.c), which does not attach a driver to a device, just mentions it during boot. I have no idea however whether this can be done with the unknown driver Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reserving Resources
> : The issue is pretty hairy and for now I think the solution is to make > : any stub use DEVICE_NOMATCH (see pci.c), which does not attach a driver > : to a device, just mentions it during boot. > > And during every reprobe after that... :-(. > I'm currently working on a pci card driver and the vga chipset gets > reprinted every single time I load the driver... Um, in that case you should update subr_bus.c. Change committed two weeks ago. I got annoyed to by that too :-) -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Device driver & KLD module
First of all the joy module is not a good example as it has been made to work, but nothing beyond that. Second, you are still using lkm-isms, which you shouldn't. Any use of lkm* is wrong and should be converted to kld*. It should be fairly straightforward to create an ISA driver that loads as a module based on for example the USB mouse driver or another simple driver. The only fishy thing is the isa probe, which might not start to reprobe on module load. Third, you can drop the SYSINIT. You can handle that in the mod_load. Hope this helps. I'm spoiled as I have only been working with PCI devices, no ISA. Nick On Fri, 18 Feb 2000, James Housley wrote: > History: > I had a device driver for a BDM (Background Debug Module for > Motorola 683xx CPUs) that worked fine as a kernel device and a LKM. It > was based upon the LPT driver, because it attached to the parallel port, > and the JOY LKM, cause it was simple. > > Present: > I have updated the driver, it does work as a kernel device. It does > not work as a KLD. It does not print its startup nor create a device. > It was updated to match the current JOY KLD. It also appears the JOY > KLD may not be working. > > Questions: > 1) Does the JOY KLD actually work? What is the simplest way to test > it. I have a joystick, but not sure how to read info from it. > 2) If not I will fix it, if possible, while fixing my BDM. > 3) Looking around it would seem that the VESA KLD might be the > simplest KLD to look at. Is this true, or is there a better one? > > My source for the BDM driver is available, for anyone who wants to peek, > is at: http://bdm.thehousleys.net/bdm.tgz . The full page with some > more info is at: http://bdm.thehousleys.net . > > Thanks for all help. > > Jim > -- > microsoft: "where do you want to go today?" > linux: "where do you want to go tomorrow?" > BSD: "are you guys coming, or what?" > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Removing interfaces
if_kue, if_aue or ask Doug Ambrisko for a copy of the udbp (USB double bulk pipe) driver that should have that as well. Nick On Wed, 2 Feb 2000, Archie Cobbs wrote: > With all the PCMCIA card stuff going on, is it now possible to > remove a networking interface in FreeBSD (from within the kernel)? > > If so could someone show me an example how. I'd like to implement > this in the ng_iface(8) netgraph node type. > > Thanks, > -Archie > > ___ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB vs. parallel port
Except that I doubt whether UHCI will survive USB2.0. Nick On Wed, 5 Jan 2000, Peter Wemm wrote: > Nick Hibma wrote: > > > By the way, at the moment it is better to have a UHCI controller on > > your motherboard. Allthough the OHCI controller is much smarter and more > > efficient, support for it is not as stable as the support for UHCI > > controllers. > > Sounds like UHCI => IDE, OHCI => SCSI ? (only 1/2 :-). > > Cheers, > -Peter > > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB vs. parallel port
Whether or not the system is loaded or not depends mainly on what hardware you have. OHCI tends to load the system a lot less than UHCI (Intel). But compared to serial and parallel ports, USB is a lot better. Most of the transaction is done per DMA and with large quantities it outperforms both of them in every way. 300Kb/s at less than 1% CPU should be no problem. I have no idea what the load on the PCI bus is though. That might be a problem as there are a lot of small transfers over that bus. By the way, at the moment it is better to have a UHCI controller on your motherboard. Allthough the OHCI controller is much smarter and more efficient, support for it is not as stable as the support for UHCI controllers. Nick > A co-worker is looking into buying a printer, and was wondering which > kind would be better, USB and/or parallel. (There are also some that do > both). > > Parallel printers tend to load down the system when busy, but serial > devices tend to load them down even more, although USB is a whole > different animal. > > What are the trade-offs? > > Thanks for any help you can provide! > > > Nate > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCMCIA-ATA/USB support for SanDisk/Digital Cameras
> uhub0: 2 ports with 2 removable, self powered > ugen0: SanDisk USB CFII, rev 1.00/0.05, addr 2 > ugen_set_config: ugen0 to configno 1, sc=0xc0d82000 > ugen_set_config: ifaceno 0 > ugen_set_config: endptno 0, endpt=0x01(1,1), sce=0xc0d820cc > ugen_set_config: endptno 1, endpt=0x02(2,1), sce=0xc0d82144 > ugen_set_config: endptno 2, endpt=0x03(3,0), sce=0xc0d82180 > >Other than the above output, I don't seem to be able to talk > to the device. /usr/sbin/usbdevs reports: > > # usbdevs -v > usbdevs: no USB controllers found Hm, you should do a make world. Or a cd /usr/src/*/usbdevs make make install cd /dev/ sh MAKEDEV ugen0 usb0 usb usbdevs -v Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCMCIA-ATA/USB support for SanDisk/Digital Cameras
>Basically, it appears to be a combination of PCMCIA-ATA > support melded together with USB. Hm, with a bit of luck it is a mass storage compliant device. (But I don't think so). Please, send me the output of usb_dump -D -f /dev/ugen0 available from http://www.etla.net/~n_hibma/usb/usb_dump.c That should give us some idea of what the device looks like. Cheers, Nick \ > >Does anyone have any experience with this unit? Am I correct > that with USB support coming onboard in -current that it would > be feasible to get a driver working? > > Thanks! > John > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Possible solution for USB Ethernet problem
Nice catch (of yet another stupidity in the UHCI controllers). In 1.3.1 they say that 'the preSOF point also prevents a packet that may not fit in the remaining frame period from being initiated.' So the UHCI controller should not start a 64 byte transfer if the MAXP is not set. What happens probably is that the controller does start it and ends up overruning its SOF. The reason for not setting it is that using a MAXP of 32 is more efficient. However, up to now I;ve not seen a device with a packet size of 32 (only 64, 16 and smaller). So switching it on should be no problem. You have a 'Intel 82371SB (PIIX3) USB controller' ? If so, we might be looking at a problem with the 1.0 specification. (please post 'dmesg|grep USB'). I have never had a BABBLE error here, which indicates to me that there was a problem with the 82371SB, which has been solved in the AB/EB. Hm, I'll have to find someone with an 82371SB board and borrow that for a while to get a trace and see what is happening on the wire. This problem should show up with any bulk-64b device if you are right. Cheers, Nick > I downloaded a copy of the Intel UHCI spec document from > ftp://download.intel.com/design/usb/UHCI11D.PDF and scrutinized it > for a while. On page 17, it describes the MAXP bit in the command > register. The description reads: > > Max Packet (MAXP). 1=64 bytes, 0=32 bytes. This bit selects the > maximum packet size that can be used for full speed bandwitdh > reclamation at the end of a frame. This value is used by the > Host Controller to determine whether it should initiate another > transaction based on the time remaining in the SOF counter. Use > of reclamation packets larger than the programmed size will > cause a Babble error if executed during the critical window at > frame end. The Babble error results in the offending endpoint > being stalled. Software is responsible for ensuring that any > packet which could be executed under bandwidth reclamation be > within this size limit. > > The ADMtek part is documented to use 64-byte USB packets for frame > transfers. However, /sys/dev/usb/uhci.c:uhci_run() never sets the > MAXP bit in the command register when it starts the controller running. > I modified uhci_run() to include the UHCI_CMD_MAXP bit and now the > ADMtek ethernet controller sends and receives 1500-byte frames with > no problems. > > The question is, how should this be handled? Should the UHCI_CMD_MAXP > bit be set all the time, or just when high speed devices are attached > to the bus? The Intel manual seems to imply that it's safe to leave this > bit enabled all the time, however I can't test this since I only have > the one USB device. Also, should something similar be done with OHCI > controllers, or do they handle this sort of thing correctly? > > -Bill > > -- > = > -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu > Work: [EMAIL PROTECTED] | Center for Telecommunications Research > Home: [EMAIL PROTECTED] | Columbia University, New York City > = > "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" > = > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB ethernet hacking
> P.S.: Please don't write me asking for help getting your USB ethernet
> adapter work with FreeBSD. Don't ask me when/if the driver will
> be done. Don't ask me if your favorite adapter will be supported.
> Don't ask me how to make the code work with FreeBSD 3.x.
:-))) What's wrong? Delete button ain't working?
The problem of usbd_abort_pipe is caused by the following code:
if (status == USBD_CANCELLED) {
usbd_setup_xfer(xfer, sc->aue_ep[AUE_ENDPT_RX],
sc, sc->aue_rx_buf, 1536, USBD_SHORT_XFER_OK,
USBD_NO_TIMEOUT, aue_rxeof);
usbd_transfer(xfer);
splx(s);
return;
}
USBD_CANCELLED is the error code returned when the transfer was
cancelled by abort_pipe. It might mean 'your dead, go away'.
Nick
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: USB ethernet hacking
> However that's not my biggest problem. My biggest problem is getting > transfers over 1100 bytes or so to work reliably. My initial scheme > for transmitting and receiving packets was to set up asynchronous > transfers with callbacks. Packets are sent over bulk transfer endpoints > (one for RX, one for TX). For TX, I would set up a transfer and initiate > it, then wait until the callback is called to free the mbuf containing > the packet data. This seemed to work, but only for transfers around > 1000 to 1100 bytes or so. Trying to transfer packets of 1200 bytes or > more always seemed to yield an "IOERROR" error. I switched the packet > transmission code to use synchronous transfers (i.e. waiting for the > transfer to complete before moving on) and this seemed to help: I could > now get transmissions up to 1500 bytes to work without errors. This sounds to me like the device wants the xfer all in one go, occupying the best part of two USB frames. Why the switch to synchronous transfers changes things I don't know, but it might be coincidental. > However, I have the same problem now with received packets: trying to > receive a frame larger than 1100 bytes also causes an IOERROR, however > I can't use a synchronous transfer here since that would cause the kernel > to freeze in its tracks waiting for a packet. Would it be possible to limit the MTU length on the ethernet network to something less then 1000 bytes (the USB frame length)? Just to make sure you get the rest working before addressing this problem. > Tracing down the error shows that the uhci driver is getting an error > status of 0x50, which is apparently the logical OR of two error bits: > "babble" and "stall." I have the Intel UHCI spec document and it mentions > these errors, however it doesn't seem to say what causes them, how to > clear them or, more importantly, how to avoid them. If I could just > figure out how to get this thing to handle these "large" transfers, I > would be a happy camper. BABBLE means that the device is transmitting more than it should be. It indicates a protocol or firmware error. You'll have to reset the device to bring it into a known state. At that point, the total length is not valid. > I put a copy of my current code at: > > http://www.freebsd.org/~wpaul/ADMtek/USB/4.0 line 928: USBD_SHORT_XFER_OK on outgoing transfers is useless. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB ethernet hacking
> I don't think there was anything special about the memory used for > a buffer. There isn't. All i386 mem is DMA-able. I still have to make things work with bus_dma and friends. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB ethernet hacking
Your register read will take at least 1msec. That is the time between scheduling the transfer and the interrupt being triggered for completion. But typically it will take 2msecs. Nick > > Because this is not an asynchronous task that I'm trying to do here. > > I'm talking about reading and writing registers from the ethernet > > controller. If this was a PCI device, I'd be using > > bus_space_read_X()/bus_space_write_X() to read the registers directly. I > > don't want to start reading a register and then come back a while later > > to read the results. The code isn't meant to work like that. > > Unfortunately, given that your 'register read request' is being queued > over what is basically a packet-switched network, you're going to have to > change the way the code works so that it _can_ work like that. If you > don't like it now, imagine how much less you're going to like, say, I2O > or SystemIO... > > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] > \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB ethernet hacking
> I have worked around this for now by hacking usbdi.c so that it polls > the controller interrupt/status register instead of tsleep()ing. I'm not > sure this is the best solution, but it's the only one that seems to work. It isn't. You don't want to be polling for 2msecs for every register transfer. The 2 msecs is due to the framing of the transfers and _nothing_ can be done about that. You'll have to live with that. > Tracing down the error shows that the uhci driver is getting an error > status of 0x50, which is apparently the logical OR of two error bits: > "babble" and "stall." I have the Intel UHCI spec document and it mentions > these errors, however it doesn't seem to say what causes them, how to > clear them or, more importantly, how to avoid them. If I could just > figure out how to get this thing to handle these "large" transfers, I > would be a happy camper. Please compile your kernel with UHCI_DEBUG and set the uhcidebug in the header of uhci.c to 11 or greater. Then look for uhci_idone. That should show what the error exactly is. If it is babble we have a piece of broken software. If it is NAK then you should set the timeout to a larger value. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ATA w/ today's -CURRENT
> > ata_command: timeout waiting for interrupt > > ^^^ > > Thats an aritifact from the ATAPI probes, it should be of no harm... In that case, is there some way of getting rid of the message? Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Basic question about threads and SMP
Being multi-threaded has almost nothing to do with being multi-processor. Multi-threading means that your application has multiple threads of execution that are able to run simultaneously. The multi-processing capability of your box means that 2 threads of execution, be it a process or a thread within a process, are executed _literally_ at the same time, and not in simulated concurrency like it happens on a UP box. Whether or not any application should be compiled with libc_r depends solely on the application itself. And, as you suggest, that is decided at build time. If applications support multi-threading they normally come with a Makefile using libc_r. Now, whether you want to multi-thread Apache is totally different issue ... Nick On Wed, 1 Dec 1999, Doug Barton wrote: > You know, a stray thought just occured to me, which hopefully > won't sound to silly to people who know about this stuff. :) If I have an > SMP box (using -Current specifically) do I want to be compiling things > with -lc_r? I'm thinking specifically of mission critical things like > apache, but in general will other ports and such take advantage of > libc_r if they are compiled with it, or would a program that _can_ take > advantage of it already have that built in, say into autoconf or some > such? What about other parts of the base system? I'm assuming that the > kernel is covered by virtue of the fact that I've enabled the SMP options, > yes? > > I'm trying to learn more about SMP, threads, and such like in > general. The recent conversations about those topics on the lists have > been very educational. I'm still wading through them, but I appreciate > being able to sit on the sidelines and glean bits here and there. > > Thanks, > > Doug > -- > "Welcome to the desert of the real." > > - Laurence Fishburne as Morpheus, "The Matrix" > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Hardware list idea
> I think openbsd asks users to email them the output of 'dmesg', > so they can tell which drivers are really of interest to the > greatest number of their users. Seems like a reasonable idea. You might want to include the list of packages installed from the base CD's as well to prime the packages that need to be there. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Digi AccelePort-USB 2, 4 or 8 port serial terminal server ?
> Nice serial server, anyone working for serial support on USB ? > Have an 8 port and could help getting support for it or testing > drivers. If you are or someone else is willing to write a driver under NDA I can give you the e-mail address of a guy who can give you the specifications for it. I dropped the idea of writing the driver as there were other, open source projects to be working on. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Set the baud rate on remote debugging
> db> gdb 19200 > Next trap will enter GDB remote protocol mode at 19200 bps > > Comments? Yes: Please do. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Support for USB floppies like Y-E Data FlashBuster-u ?
> Anyone working on such support yet ? This drive came with the Sony > Vaio Z505R. If you ask the 3 IDE disks and ethernet hub that have gone pop this weekend, they would say no, but myself I was pretty firm that I was going to do something about it this weekend. Bastard things, they should be shot and they will be. All is well now, so maybe this week, maybe next, top of the prioritised list in any case. And it would be great if by the time something is working I could count on a few people with machines that can boot from USB floppies to give me a hand in getting booting and installing on those machines to work. Cheers, Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CAM-ification - documentation
> > Ick. Polling == bad. Interrupts == good. This isn't a single- > > tasking OS ala Win9x. This goes double for SCSI drivers, which are > > inherently async and overlapped. > > I never said polling was good. Nick just asked about polling, and I > commented on how it could be done. I have no idea why he wanted to know > about polling, though. Well, I am not sure whether I need polling, but there are some problems related to the fact that multiple USB transactions are needed for one SCSI transaction. Combined with the fact that some requests are done asynchronously (clear endpoint halt at the end of a transaction if the transaction failed) it might be useful to do polling to avoid massively complex code. Nick -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
CAM-ification - documentation
While on the topic: What documentation is there for CAM? I've found the following, but would like to know whether there is more - CAM specification (at Digital?) - justin's docu on freefall. Especially some help on the topic of polling would be appreciated. Otherwise I'll have to resort to figuring out how to do things in interrupt context, and that is going to be dirty. Nick > Warner Losh wrote... > > In message <[EMAIL PROTECTED]> Wilko Bulte writes: > > : How difficult would CAMifying a driver be? > > > > Speaking of which, has a "How to CAMify a driver" doc been written? > > Nope. You've CAMified a driver, would you like to write it? :) > > Ken > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: wormcontrol write speed
And, oh while you are at it, why not create a CAM SIM that makes IDE available through CAM. That would save me a lot of work :-) Nick On Sun, 26 Sep 1999, Soren Schmidt wrote: > It seems Christopher Masto wrote: > > On Wed, Sep 22, 1999 at 09:27:37AM +0200, Soren Schmidt wrote: > > > Anyhow, I have some changes to the worm stuff, it needs to be dealt with > > > to handle modern HW, and to deal with all the possible block formats > > > thats possible on a CD nowadays. It will probably mean the death of > > > the worm stuff as is now, but I'm the last user anyways so > > > > Any chance of getting a passthrough or "SCSI emulation" so that > > cdrecord could be used instead? (Then you won't have to worry about > > different CD-R quirks) > > If somebody writes it there is a chance. I dont have this on my TODO > list. I could maybe be talked into providing a generic ATAPI interface > that would give you a method of injecting ATAPI commands directly > into the systemi, cdrecord etc could use that then. > > > I have an Acer CRW 6202A which doesn't seem to work with FreeBSD > > (current as of five minutes ago, including the rev 1.19 of > > atapi-cd.c). "wormcontrol blank" (with a CD-RW of course) runs for a > > little while, then aborts with an I/O error. Also, all IDE devices > > are completely locked up while it's running. > > What I/O error ?? its impossible to diagnose on no data... > > > The dd also sort of works for a while, then gets an I/O error. Same > > with fixate (which also locks up the IDE busses). > > What I/O error ?? its impossible to diagnose on no data... > > > I'm currently recompiling with ATAPI_DEBUG and ACD_DEBUG in the hopes > > that I'll be able to produce a better bug report. Any suggestions? > > Provide data, the system spits out lots of sensekey things and the > like on errors, those are invaluable data to diagnose this... > > -Søren > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > > -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAPERSIZE in /etc/make.conf?
> > Should we have a PAPERSIZE variable (A4 vs. letter) in /etc/make.conf? > > > > - groff has the paper size set as compile time option. > > > > - Various ports that now exist in two versions or require the > > user to define the paper size at build time could automatically > > pull the value in. > > Yes. I think I encountered this with enscript the other day, too. Sent > the LaserJam into a blinking fit, displaying "PC LOAD A4". Us 'silly' people could appreciate an option like that. Would also reduce the number of ports having to specify this in the name of the port. Nick -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: nuking a vnode
> int major;
> dev_t dev;
> struct vnode *vp;
>
> major = ultp_cdevsw.d_maj;
> dev = makedev(major, self->dv_unit)
> vp = SLIST_FIRST(&dev->si_hlist);
if (vfinddev(dev, VCHR, &vp))
VOP_REVOKE(vp, REVOKEALL);
#if 0
> if (vp) {
> VOP_REVOKE(vp. REVOKEALL);
> }
#endif
> remove_dev(dev);
/* Good one! I had not yet thought about that one */
> 3.3 will be considerably different.
Not one of my main concerns.
Nick
--
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: nuking a vnode
> int major;
> dev_t dev;
> struct vnode *vp;
>
> major = ultp_cdevsw.d_maj;
> dev = makedev(major, self->dv_unit)
> vp = SLIST_FIRST(&dev->si_hlist);
if (vfinddev(dev, VCHR, &vp))
VOP_REVOKE(vp, REVOKEALL);
#if 0
> if (vp) {
> VOP_REVOKE(vp. REVOKEALL);
> }
#endif
> remove_dev(dev);
/* Good one! I had not yet thought about that one */
> 3.3 will be considerably different.
Not one of my main concerns.
Nick
--
ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
nuking a vnode
How do I nuke vnodes? This is the NetBSD code that needs to be emulated: /* locate the major number */ for (maj = 0; maj < nchrdev; maj++) if (cdevsw[maj].d_open == ulptopen) break; /* Nuke the vnodes for any open instances (calls close). */ mn = self->dv_unit; vdevgone(maj, mn, mn, VCHR); -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
nuking a vnode
How do I nuke vnodes? This is the NetBSD code that needs to be emulated: /* locate the major number */ for (maj = 0; maj < nchrdev; maj++) if (cdevsw[maj].d_open == ulptopen) break; /* Nuke the vnodes for any open instances (calls close). */ mn = self->dv_unit; vdevgone(maj, mn, mn, VCHR); -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB cameras
> A simple question: Are USB cameras supported? Is anybody working on it? No. Isochronous pipes are not supported yet, but work is underway. > Oh, btw, how long can USB be extended? Hm, the mechanical specification of the cable is confusing before coffee. I think it was 6ft / 2m. You'll notice that when connecting full speed devices they will drop packets and get unwanted timeouts. Low speed devices are more tolerant. Nick -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: USB cameras
> A simple question: Are USB cameras supported? Is anybody working on it? No. Isochronous pipes are not supported yet, but work is underway. > Oh, btw, how long can USB be extended? Hm, the mechanical specification of the cable is confusing before coffee. I think it was 6ft / 2m. You'll notice that when connecting full speed devices they will drop packets and get unwanted timeouts. Low speed devices are more tolerant. Nick -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to go about making a compiler port
What about providing a package (binary only distribution) and a port? And the port could include the possibility to bootstrap the installation. See the handbook on how to build a package. Nick On Sun, 12 Sep 1999, Simon Marlow wrote: > [originally sent to ports, resending to hackers at the suggestion of someone > on that list.] > > Hi Folks, > > I'd like to make a port for our Haskell compiler, GHC (see > http://research.microsoft.com/users/t-simonm/ghc). There are some subtle > problems with this: > > - GHC depends on itself. That is, you need GHC > installed in order to build GHC. > > - GHC depends on Happy, our parser generator. > > - Happy depends on GHC (it's written in Haskell). > > So, one solution would be to provide a binary port, say ghc-bin, which would > install a binary distribution. I checked the modula-3 port, and it doesn't > seem to have a binary port, so what's the accepted way of doing this? > > It's possible to bootstrap GHC from intermediate C files, but it's a bit > fiddly and I'd prefer not to do this if possible. However, one thing that > occurs to me is that the port could bootstrap itself from C if you say 'make > BOOTSTRAP=YES', and otherwise attempt to build using an installed GHC. > > Any thoughts greatly appreciated. > > I'm not on this list, BTW. > > Cheers, > Simon > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > > -- e-Mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to go about making a compiler port
What about providing a package (binary only distribution) and a port? And the port could include the possibility to bootstrap the installation. See the handbook on how to build a package. Nick On Sun, 12 Sep 1999, Simon Marlow wrote: > [originally sent to ports, resending to hackers at the suggestion of someone > on that list.] > > Hi Folks, > > I'd like to make a port for our Haskell compiler, GHC (see > http://research.microsoft.com/users/t-simonm/ghc). There are some subtle > problems with this: > > - GHC depends on itself. That is, you need GHC > installed in order to build GHC. > > - GHC depends on Happy, our parser generator. > > - Happy depends on GHC (it's written in Haskell). > > So, one solution would be to provide a binary port, say ghc-bin, which would > install a binary distribution. I checked the modula-3 port, and it doesn't > seem to have a binary port, so what's the accepted way of doing this? > > It's possible to bootstrap GHC from intermediate C files, but it's a bit > fiddly and I'd prefer not to do this if possible. However, one thing that > occurs to me is that the port could bootstrap itself from C if you say 'make > BOOTSTRAP=YES', and otherwise attempt to build using an installed GHC. > > Any thoughts greatly appreciated. > > I'm not on this list, BTW. > > Cheers, > Simon > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > > -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
> | PCI and CardBus to USB. Any one having seen a ISA or PCMCIA variant, > | please let me know. > > I thought I saw a PCMCIA -> USB at Fry's. Hm, I had a good look around, but couldn't find one. If you happen to end up at Fry's one day, let me know if you can find the name of the brand. Cheers, Nick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
> | PCI and CardBus to USB. Any one having seen a ISA or PCMCIA variant, > | please let me know. > > I thought I saw a PCMCIA -> USB at Fry's. Hm, I had a good look around, but couldn't find one. If you happen to end up at Fry's one day, let me know if you can find the name of the brand. Cheers, Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
>I disagree quite strongly. DDB provides a mechanism to allow a >sysadmin to obtain a greater amount of information from a panic >situation then he could get otherwise. Being able to obtain this >information does not run counter to running with a raised securelevel. > >If the system winds up in a state where a kernel core cannot be >generated, DDB is the only way to figure out what is going on. >securelevel is a mechanism which attempts to guarentee data security, >at least to a degree. These two items do not clash. > Anyway, as soon as you can physically access the PC, youD loose anyway, independent of whether you can go into DDB to do things. You can reboot, boot a floppy. Yes you can do something about those things, but only to a limited extent. Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Init(8) cannot decrease securelevel
>I disagree quite strongly. DDB provides a mechanism to allow a >sysadmin to obtain a greater amount of information from a panic >situation then he could get otherwise. Being able to obtain this >information does not run counter to running with a raised securelevel. > >If the system winds up in a state where a kernel core cannot be >generated, DDB is the only way to figure out what is going on. >securelevel is a mechanism which attempts to guarentee data security, >at least to a degree. These two items do not clash. > Anyway, as soon as you can physically access the PC, youD loose anyway, independent of whether you can go into DDB to do things. You can reboot, boot a floppy. Yes you can do something about those things, but only to a limited extent. Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limit of bus hierarchies (was Re: PCI modems do not work???)
> I'll give that a try too. I do like having a USB keyboard, except for the > fact that if the system is *very* busy, I tend to get some weird > repetitions. I dunno if this'll happen under FreeBSD or not, but it's > annoying. > > (example, I start up ScanDisk, and a CPU eating program at the same time, > and try to type... The quick ick ick brown fox jumpumped over erthe > lazy og) > > I'll blame this on a Windowsism until I see otherwise. :) This very much sounds like Windows not being fast enough in retiring the TD's (you have a UHCI controller and a lot of work has to be done by the CPU, when compared to OHCI). This is not a problem that USB can produce in any way. I guess it must be something like Windows not retiring the TD fast enough, so at the next frame the same TD is handled again. Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Limit of bus hierarchies (was Re: PCI modems do not work???)
> This is under 3.2-STABLE as of a few days ago. Any ideas here? Yes, use CURRENT :-) > This is the ethernet device, which appears as port 4 of this hub. (1-3 are > USB ports, port 4 is an ethernet port) That is the way it should be done. I have a PCI card here with a hub included to make 4 out of 2 ports :-) > Device Descriptor: > bcdUSB: 0x0100 > bDeviceClass: 0x00 > bDeviceSubClass: 0x00 > bDeviceProtocol: 0x00 > bMaxPacketSize0: 0x08 (8) > idVendor: 0x1645 > idProduct: 0x0005 > bcdDevice: 0x0202 > iManufacturer:0x02 > iProduct: 0x03 > iSerialNumber:0x01 > bNumConfigurations: 0x01 > > ConnectionStatus: DeviceConnected > Current Config Value: 0x01 > Device Bus Speed: Full > Device Address: 0x06 > Open Pipes: 3 Pitty it does not list the interface descriptor. It might have given some more information on the class/subclass/protocol in use. > Endpoint Descriptor: > bEndpointAddress: 0x81 > Transfer Type:Bulk > wMaxPacketSize: 0x0040 (64) > bInterval:0x00 > > Endpoint Descriptor: > bEndpointAddress: 0x02 > Transfer Type:Bulk > wMaxPacketSize: 0x0040 (64) > bInterval:0x00 > > Endpoint Descriptor: > bEndpointAddress: 0x83 > Transfer Type: Interrupt > wMaxPacketSize: 0x0008 (8) > bInterval:0x01 (hub/serial/parallel) > idVendor: 0x1645 > idProduct: 0x0001 > bcdDevice: 0x0102 > bInterfaceClass: 0x07 > bInterfaceSubClass: 0x01 > bInterfaceProtocol: 0x01 Looks like they glued the hub, serial and parallel simply together. > Here's also something somewhat interesting... a USB keyboard with a PS/2 > mouseport on the keyboard itself. (sorta like the mac) Sorta very much unlike the mac. It's one device with 2 interfaces (compared to 3 devices: a hub, a keyboard and a mouse :) > bInterfaceClass: 0x03 > bInterfaceSubClass: 0x01 > bInterfaceProtocol: 0x01 HID keyboard > bInterfaceClass: 0x03 > bInterfaceSubClass: 0x01 > bInterfaceProtocol: 0x02 HID mouse > I have no idea if this means anything to you, but in lieu of your usb dump, > it's at least something. :) If I can figure out how to make USB work on this > system with FreeBSD, i'll use usb_dump and send this to you again. The HID keyboard/mouse is supported under 3.2 supposedly. There are people using it on a daily basis, with some limitations as in not disconnecting the things. thanks a lot! Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Limit of bus hierarchies (was Re: PCI modems do not work???)
> I'll give that a try too. I do like having a USB keyboard, except for the > fact that if the system is *very* busy, I tend to get some weird > repetitions. I dunno if this'll happen under FreeBSD or not, but it's > annoying. > > (example, I start up ScanDisk, and a CPU eating program at the same time, > and try to type... The quick ick ick brown fox jumpumped over erthe > lazy og) > > I'll blame this on a Windowsism until I see otherwise. :) This very much sounds like Windows not being fast enough in retiring the TD's (you have a UHCI controller and a lot of work has to be done by the CPU, when compared to OHCI). This is not a problem that USB can produce in any way. I guess it must be something like Windows not retiring the TD fast enough, so at the next frame the same TD is handled again. Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
> And USB? This reference says that you can (now? soon?) buy a > laptop docking station with all of the usual ports, connected > only by USB... > > http://www.infoworld.com/cgi-bin/displayStory.pl?99093.piusb.htm That thing looks very simple probably on the USB bus: root hub device hub (internal) externally available 4 ports hub externally available 7 ports hub modem serial port parallel port etc. > Hmm. What sort of level of nesting do we support for this sort > of thing? It's probably possible to buy USB interface cards > that plug into ISA, PCI, SCSI? And vice-versa? PCI and CardBus to USB. Any one having seen a ISA or PCMCIA variant, please let me know. USB->SCSI: E-Shuttle from Microtech / Shuttle or in the Iomega Zip drive Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Limit of bus hierarchies (was Re: PCI modems do not work???)
> No. The Windows world presents a standard SERIAL DRIVER interface, at > least that's the theory that is preached. I see no reason why a USB > serial port wouldn't do the same. USB defines a serial port > interface, IIRC, which is the same across manufacturers (in theory) > which would be handled by a single USB driver in our USB stack. Keep dreaming ... Example: Mice and keyboards have a well defined standard interface: HID (Human Interface Devices), but we have found already three ways of doing things, requiring a rewrite of the probe and attach functionality. Reason: It's much cheaper to present one device with a special interface and write the driver (for Windows) for it, than to present two functions and having to integrate a hub on the device. You don't want to know what a ethernet/parallel/serial/hub thingie looks like. I don't have one, so anyone that has one, could you send me the output of the usb_dump utility avaible from http://www.etla.net/~n_hibma/usb/usb.pl > Likewise with parallel ports. Although turning a USB parallel port > into a bit twiddling interface may present some interesting > challanges. There is at least a spec for the parallel port devices. -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Limit of bus hierarchies (was Re: PCI modems do not work???)
> This is under 3.2-STABLE as of a few days ago. Any ideas here? Yes, use CURRENT :-) > This is the ethernet device, which appears as port 4 of this hub. (1-3 are > USB ports, port 4 is an ethernet port) That is the way it should be done. I have a PCI card here with a hub included to make 4 out of 2 ports :-) > Device Descriptor: > bcdUSB: 0x0100 > bDeviceClass: 0x00 > bDeviceSubClass: 0x00 > bDeviceProtocol: 0x00 > bMaxPacketSize0: 0x08 (8) > idVendor: 0x1645 > idProduct: 0x0005 > bcdDevice: 0x0202 > iManufacturer:0x02 > iProduct: 0x03 > iSerialNumber:0x01 > bNumConfigurations: 0x01 > > ConnectionStatus: DeviceConnected > Current Config Value: 0x01 > Device Bus Speed: Full > Device Address: 0x06 > Open Pipes: 3 Pitty it does not list the interface descriptor. It might have given some more information on the class/subclass/protocol in use. > Endpoint Descriptor: > bEndpointAddress: 0x81 > Transfer Type:Bulk > wMaxPacketSize: 0x0040 (64) > bInterval:0x00 > > Endpoint Descriptor: > bEndpointAddress: 0x02 > Transfer Type:Bulk > wMaxPacketSize: 0x0040 (64) > bInterval:0x00 > > Endpoint Descriptor: > bEndpointAddress: 0x83 > Transfer Type: Interrupt > wMaxPacketSize: 0x0008 (8) > bInterval:0x01 (hub/serial/parallel) > idVendor: 0x1645 > idProduct: 0x0001 > bcdDevice: 0x0102 > bInterfaceClass: 0x07 > bInterfaceSubClass: 0x01 > bInterfaceProtocol: 0x01 Looks like they glued the hub, serial and parallel simply together. > Here's also something somewhat interesting... a USB keyboard with a PS/2 > mouseport on the keyboard itself. (sorta like the mac) Sorta very much unlike the mac. It's one device with 2 interfaces (compared to 3 devices: a hub, a keyboard and a mouse :) > bInterfaceClass: 0x03 > bInterfaceSubClass: 0x01 > bInterfaceProtocol: 0x01 HID keyboard > bInterfaceClass: 0x03 > bInterfaceSubClass: 0x01 > bInterfaceProtocol: 0x02 HID mouse > I have no idea if this means anything to you, but in lieu of your usb dump, > it's at least something. :) If I can figure out how to make USB work on this > system with FreeBSD, i'll use usb_dump and send this to you again. The HID keyboard/mouse is supported under 3.2 supposedly. There are people using it on a daily basis, with some limitations as in not disconnecting the things. thanks a lot! Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limit of bus hierarchies (was Re: PCI modems do not work???)
> > > USB doesn't present a 16550A interface to the host, so I don't think > > > that sio would have a USB attachment. > > > > So there's going to be manufacturer-specific terminal/serial port drivers > > to talk to the serial ports on USB-attached laptop docking stations, like > > the Annex ethernet terminal server things? > > Presuming we are able to get any documentation out of any of these > vendors; so far USB serial ports have been one of the worst things to > enquire about. 1) Why do you want a sio like interface to something that contains brains, i.e. a 8051 microcontroller? 2) There is someone writing firmware for the most commonly found serial, adapter from Entrega, and he is at the point where he is using the serial port for debugging output for the firmware in the microcontroller. Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
> And USB? This reference says that you can (now? soon?) buy a > laptop docking station with all of the usual ports, connected > only by USB... > > http://www.infoworld.com/cgi-bin/displayStory.pl?99093.piusb.htm That thing looks very simple probably on the USB bus: root hub device hub (internal) externally available 4 ports hub externally available 7 ports hub modem serial port parallel port etc. > Hmm. What sort of level of nesting do we support for this sort > of thing? It's probably possible to buy USB interface cards > that plug into ISA, PCI, SCSI? And vice-versa? PCI and CardBus to USB. Any one having seen a ISA or PCMCIA variant, please let me know. USB->SCSI: E-Shuttle from Microtech / Shuttle or in the Iomega Zip drive Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limit of bus hierarchies (was Re: PCI modems do not work???)
> No. The Windows world presents a standard SERIAL DRIVER interface, at > least that's the theory that is preached. I see no reason why a USB > serial port wouldn't do the same. USB defines a serial port > interface, IIRC, which is the same across manufacturers (in theory) > which would be handled by a single USB driver in our USB stack. Keep dreaming ... Example: Mice and keyboards have a well defined standard interface: HID (Human Interface Devices), but we have found already three ways of doing things, requiring a rewrite of the probe and attach functionality. Reason: It's much cheaper to present one device with a special interface and write the driver (for Windows) for it, than to present two functions and having to integrate a hub on the device. You don't want to know what a ethernet/parallel/serial/hub thingie looks like. I don't have one, so anyone that has one, could you send me the output of the usb_dump utility avaible from http://www.etla.net/~n_hibma/usb/usb.pl > Likewise with parallel ports. Although turning a USB parallel port > into a bit twiddling interface may present some interesting > challanges. There is at least a spec for the parallel port devices. -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limit of bus hierarchies (was Re: PCI modems do not work???)
> > > USB doesn't present a 16550A interface to the host, so I don't think > > > that sio would have a USB attachment. > > > > So there's going to be manufacturer-specific terminal/serial port drivers > > to talk to the serial ports on USB-attached laptop docking stations, like > > the Annex ethernet terminal server things? > > Presuming we are able to get any documentation out of any of these > vendors; so far USB serial ports have been one of the worst things to > enquire about. 1) Why do you want a sio like interface to something that contains brains, i.e. a 8051 microcontroller? 2) There is someone writing firmware for the most commonly found serial, adapter from Entrega, and he is at the point where he is using the serial port for debugging output for the firmware in the microcontroller. Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
