Re: Recommendations for a serial port card you can actually BUY?
On Thu, 5 Oct 2006, Karl Denninger wrote: On Thu, Oct 05, 2006 at 05:04:41PM -0400, Bob Johnson wrote: I have used USB-to-serial converters with no problem. All the control signals (at least the ones my applications need) seem to work correctly. I don't remember any brands or models off hand, I bought what was cheap as I needed them and they all worked. Cheap means under $20 delivered (for one port). Interesting. Now, what happens when you reboot? Do they come back in random order? That won't work! I need to know that port 2 will BE Port 2 the next time the machine comes up Competent USB devices have serial numbers in them, although the current FreeBSD USB system doesn't provide easy access to the data (the kernel collects it as part of the device discovery, but AFAIR doesn't do anything with it). I solved my problems in a different way (below). As already mentioned in this thread, USB serial adapters fall into the 'too cheap' category (the purchase cost isn't worth mentioning, but you have no idea what will arrive when you order one). IMO, it's worth standardising on one adapter type (hence one device driver) and spending a bit more time/money on the purchasing. I standardized on adapters using the FTDI chips (www.ftdichip.com, they sell their own adapters but these chips are widely used and I've usually bought mine elsewhere). FTDI have been through about 3 generations of these chips while remaining driver compatible. When I started (several years ago), the uftdi driver wasn't up to the job for the sort of reasons you mention (control of handshakes, real-time control), but for my applications it was convenient to avoid using uftdi and simply address the devices with the ugen driver - giving me direct control over the handshakes, the FIFO timeout behaviour etc. I believe that uftdi has since improved and may now be the right way to go if your applications want a tty-style interface (I don't use it much, having as above written all my serious applications another way). The FTDI devices keep the device descriptors etc. in an EEPROM, so my approach to the 'which port is which' problem was to change the textual part of the descriptor - usbdevs -d then immediately tells you what is going on. The EEPROM is writable over the USB connection - I have a program to do so if anybody wants it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can't assign requested address with ntpd on 5-STABLE
On Sun, 22 May 2005, Richard Coleman wrote: On 5-STABLE, when I try to start ntpd, I get the following error: bind() fd 7, family 28, port 123, addr fe80:1::2a0:c9ff:fec8:ea25, in6_is_addr_multicast=0 flags=0 fails: Can't assign requested address Anyone else seen this recently. I've seen something similar with IPV4. Problem here was that I had multiple interfaces with the same address (an ethernet and some point-to-point interfaces that shared the same near-end address). ntpd appears to enumerate the interfaces and tries to bind (by address) to all of them, then fails because it's trying to bind the same thing twice. This isn't directly the same as your problem, but might be similar? Do you have alias addresses or something that may give the same effect? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb 2 or firewire in stable?
On Mon, 23 Dec 2002, Aaron Wohl wrote: Is anyone using usb 2 or fireware in 4.7 stable? If so how? I need one or the other to do backups to an external disk. The machine is a production machine tho so I cant really go to current yet. I tried some usb 2 cards. They show up as usb 1 cards and work ok but only at usb 1 speeds. I am using firewire to do exactly that. Cheap firewire cards in all my machines, couple of 180G external firewire hard drives as the storage media. I put a normal filesystem on the drive, then run 'dump' through gzip to create backups. Firewire support has been in -stable for a few months now. It works well in general; throughput is good, the only problems I have run into relate to error handling under fault conditions (at one point I had a loose power connection on a drive, which lead to lock-ups rather than more graceful error handling). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
USB Smartmedia readers
Following up on previous correspondance, I can confirm that both models of the FujiFilm USB SmartMedia readers (the obsolete SM-R1 and the current SM-R2) work OK with FreeBSD 4.3. In fact, they seem almost identical, apart from the fact that the case is now painted gloss purple rather than matt grey. On the inside, the PCB has had a re-layout but appears to have much the same chipset. They've forgotten to private-label the firmware in the new version: SM-R1 (empty): umass0: Fuji Photo Film SmartMedia R/W, rev 1.00/1.00, addr 4 umass0: Get Max Lun not supported (STALLED) da1 at umass-sim0 bus 0 target 0 lun 0 da1: GENERIC SmartMedia R/W 1.00 Removable Direct Access SCSI-2 device da1: 650KB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present SM-R2 (with card loaded): umass0: Hagiwara Sys-Com SmartMedia R/W, rev 1.10/2.00, addr 5 umass0: Get Max Lun not supported (STALLED) da1 at umass-sim0 bus 0 target 0 lun 0 da1: HAGIWARA SmartMedia R/W 2.00 Removable Direct Access SCSI-2 device da1: 650KB/s transfers da1: 62MB (128000 512 byte sectors: 64H 32S/T 62C) Performance is good: reading through the filesystem gives a shade over 700Kbyte/sec; reading the raw device depends on the block size - with a 32K block size you get the same 700Kbyte/sec, down to about 80Kbyte/sec with 512byte block. Writing is slower - about 150 to 200Kbyte/sec. Software notes: 1) Hot-plugging the USB doesn't work: the device has to be connected at boot time for it to get properly associated with the CAM subsystem (doesn't matter if there is a card in the drive or not). After attempts to hot-plug, camcontrol devlist reports that the USB device is associated with pass1 but not da1, and camcontrol rescan 1 hangs forever, sometimes leading to a panic if you then unplug. 2) The USB controller gets scanned before the SCSI controllers (at least in my system), so you need a kernel with the SCSI devices wired down if your root is on a SCSI drive (to avoid trying to mount root from the smartmedia). 3) The standard SmartMedia formatting has a full FDISK table and a DOS filesystem on it, so mount -t msdos /dev/da1s1 /mnt is required to mount a card written from a camera. 4) camcontrol eject da1 turns off the drive active LED allowing the card to be removed (Fuji seem to be paranoid about this: there is a sticker on the top warning you not to try removing the card while the LED is on; there's a sensor attached to the eject lever that (presumably) allows the firmware to power down the card if you press the lever intemperately, and in any case the contacts on the card are designed so that GND disconnects last and so you'd be unlucky to blow it up anyhow). 5) camcontrol format da1 will re-write the low-level format. This is useful if you have cards that have been used in a Rio MP3 player: the Rio uses a proprietary low-level format, and my (olympus) camera refuses to touch cards that have been used in the Rio, even with the menu option to format the card. After a low-level format in the reader, the camera is then happy to high-level format the card and you are back in business. As an aside, I also tried a very cheap smartmedia reader: ugen0: SCM Microsystems Inc. SCM eUSB SmartMedia , rev 1.00/1.00, addr 5 This is sold here as the Cardport Swift and claims to be made in the UK, (though I have my doubts, given the above ident string and I am fairly sure I've seen this OR-gate shaped housing elsewhere - see http://www.premierelect.co.uk/CARDportSwift.html for a picture). This unit does NOT work with FreeBSD. Compared to Fuji's concern over ejecting, this unit has no LEDs or eject levers at all - you just yank the card out when you feel like it. Surprisingly, their supplied Windows drivers don't crash when you do this. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.3-STABLE and VIA VT82C686A sound...
On Sun, 6 May 2001, Alessandro de Manzano wrote: you mean you have this device : libero:(root)/root# cat /dev/sndstat FreeBSD Audio Driver (newpcm) May 1 2001 14:11:58 Installed devices: pcm0: VIA VT82C686A at io 0xcc00 irq 5 (1p/1r channels duplex) and libero:(root)/root# dmesg | grep pcm pcm0: VIA VT82C686A port 0xd400-0xd403,0xd000-0xd003,0xcc00-0xccff irq 5 at device 7.5 on pci0 (FreeBSD 4.3-stable of May, 1st) and works correctly ? It all depends what you mean by correctly. And the above message is not enough to identify your sound hardware: the VIA 82C686 is effectively just a DMA engine, and the features you get depend on the AC97 chip attached to it. In particular, some motherboards only support a very limited range of sampling rates: I have one 82C686 motherboard here that supports only 48000Hz (and I have others that support multiple rates). These machines often come with Windows drivers that mimic the behaviour of a 'real' soundcard - ie. they use software to convert the sample rate of the input to the sample rate supported by the hardware. The FreeBSD driver just gives an error if you try to select a speed not supported by the hardware. This doesn't stop you using other software to solve the problem - for example sox (ports/audio/sox) will do sample rate interpolation. I ask you because mine is not! :( If I try playing, example, a MP3 file with AMP 0.7.6 (it's in the ports) I only got errors Unable to seq frequenct : 44100 The same with other MP3 players :( Did you try mp3blaster? Last time I tried it, it ignored the error from the driver and just played the MP3 at the wrong speed. This isn't actually useful, but at least confirms the hardware is basically working. I tought such AC'97 pseudo-audio devices were not (yet?) fully supported, but if your is working maybe I'm wrong ;) AC97 is not a full description of your hardware's capabilities. Unfortunately, motherboard/soundcard manuals almost always contain only marketing buzzwords and no useful information whatever. Buying a soundcard is a game of chance. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.0 Release - 4.2-Stable should be ok ? via cvsup ?
On Sat, 10 Feb 2001, Warner Losh wrote: Yes. I've done this with Feb 4th sources on our 4.0-RELEASE firewall. Well, I'm waiting for a time to do the make installworld/installkernel since the machine isn't at my house and I'm nervous about doing it remotely since I screw 4 people if something goes wrong. I hope that's _late_ Feb 4th sources if your firewall uses ipfw: ipfw was substantially broken from 2001/02/01 20:25:09 to 2001/02/04 05:48:59 (/sys/netinet/ip_fw.c rev 1.131.2.13 is the bad version). We were upgrading our firewall around that time and were dismayed to find it wide-open after the upgrade! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
softupdates/NFS/vinum(?) panics
I have been getting frequent panics:
softdep_lock: locking against myself
These have been occurring since an incident on 16th January, where the
SCSI cable was accidentally unplugged on a running system, and vinum had
trouble recovering. That incident almost certainly caused some arbitrary
corruption to the filesystem; however, there is no obvious vinum
involvement in the more recent panics (except that the filesystem in
question is almost certainly the vinum one, as the other filesystems on
this machine are almost unused).
This suggests either:
1) The big crash left some corruption that fsck can't see but causes
subsequent problems.
2) There is some vinum interaction that happens to have been arisen
around this time (the filesystem has been growing gradually from
25% full when the system was commissioned in November to 50% now)
3) There is some softupdates problem unrelated to vinum.
For most of the period, the system has been running a kernel built from
-stable as at 1st January; over the weekend I upgraded to -stable (cvsup
on Friday 19th), but we've had 3 crashes this morning so that doesn't
appear to have helped.
All the dumps are rather similar, apparently serving an NFS write; here's
the latest one, and an older one:
IdlePTD 3162112
initial pcb at 2838e0
panicstr: softdep_lock: locking against myself
panic messages:
---
panic: allocdirect_check: old 59099240 != new 59099240 || lbn 1 = 12
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:469
#1 0xc014ea8b in boot (howto=260) at ../../kern/kern_shutdown.c:309
#2 0xc014ee08 in poweroff_wait (junk=0xc02545c0, howto=-1025022464)
at ../../kern/kern_shutdown.c:556
#3 0xc01e7cf1 in acquire_lock (lk=0xc0277fdc)
at ../../ufs/ffs/ffs_softdep.c:263
#4 0xc01ebac4 in softdep_update_inodeblock (ip=0xc2e76600, bp=0xc7bf59b0,
waitfor=0) at ../../ufs/ffs/ffs_softdep.c:3643
#5 0xc01e6fed in ffs_update (vp=0xcfbabe00, waitfor=0)
at ../../ufs/ffs/ffs_inode.c:106
#6 0xc01eed50 in ffs_sync (mp=0xc28da400, waitfor=2, cred=0xc0a3b900,
p=0xc0297c20) at ../../ufs/ffs/ffs_vfsops.c:987
#7 0xc017c587 in sync (p=0xc0297c20, uap=0x0) at ../../kern/vfs_syscalls.c:545
#8 0xc014e85e in boot (howto=256) at ../../kern/kern_shutdown.c:233
#9 0xc014ee08 in poweroff_wait (junk=0xc0254be0, howto=59099240)
at ../../kern/kern_shutdown.c:556
#10 0xc01e8eff in allocdirect_merge (adphead=0xc2f04c44, newadp=0xc2cc7f80,
oldadp=0xc2cd3200) at ../../ufs/ffs/ffs_softdep.c:1323
#11 0xc01ebc7d in merge_inode_lists (inodedep=0xc2f04c00)
at ../../ufs/ffs/ffs_softdep.c:3718
#12 0xc01ebb43 in softdep_update_inodeblock (ip=0xc2eb3d00, bp=0xc7b9fee4,
waitfor=1) at ../../ufs/ffs/ffs_softdep.c:3665
#13 0xc01e6fed in ffs_update (vp=0xcfbe9600, waitfor=1)
at ../../ufs/ffs/ffs_inode.c:106
#14 0xc01efcde in ffs_write (ap=0xcfb3bc88)
at ../../ufs/ufs/ufs_readwrite.c:544
#15 0xc01b09f4 in nfsrv_write (nfsd=0xc2eb3a00, slp=0xc2ce3200,
procp=0xce781400, mrq=0xcfb3bdfc) at vnode_if.h:363
#16 0xc01c7c9a in nfssvc_nfsd (nsd=0xcfb3be5c, argp=0x807c4a0 "", p=0xce781400)
at ../../nfs/nfs_syscalls.c:602
#17 0xc01c75ef in nfssvc (p=0xce781400, uap=0xcfb3bf80)
at ../../nfs/nfs_syscalls.c:306
#18 0xc022cb31 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 0, tf_esi = 0, tf_ebp = -1077936788, tf_isp = -810303532,
tf_ebx = 4, tf_edx = 1, tf_ecx = -3, tf_eax = 155, tf_trapno = 12,
tf_err = 2, tf_eip = 134518292, tf_cs = 31, tf_eflags = 647,
tf_esp = -1077937216, tf_ss = 47}) at ../../i386/i386/trap.c:1150
#19 0xc0221995 in Xint0x80_syscall ()
#20 0x8048135 in ?? ()
(kgdb)
Sample dump from January 1st kernel:
IdlePTD 3158016
initial pcb at 2823c0
panicstr: softdep_lock: locking against myself
panic messages:
---
panic: allocdirect_check: old 36273280 != new 36273280 || lbn 4 = 12
syncing disks... panic: softdep_lock: locking against myself
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:469
#1 0xc014db3f in boot (howto=260) at ../../kern/kern_shutdown.c:309
#2 0xc014debc in poweroff_wait (junk=0xc0253200, howto=0)
at ../../kern/kern_shutdown.c:556
#3 0xc01e6b2d in acquire_lock (lk=0xc0276a7c)
at ../../ufs/ffs/ffs_softdep.c:263
#4 0xc01eade6 in softdep_fsync_mountdev (vp=0xce77a3c0)
at ../../ufs/ffs/ffs_softdep.c:3846
#5 0xc01eeef2 in ffs_fsync (ap=0xcfb39a80) at ../../ufs/ffs/ffs_vnops.c:134
#6 0xc01edbfa in ffs_sync (mp=0xc29d7000, waitfor=2, cred=0xc0a3b900,
p=0xc02966c0) at vnode_if.h:537
#7 0xc017b41f in sync (p=0xc02966c0, uap=0x0) at ../../kern/vfs_syscalls.c:545
#8 0xc014d91a in boot (howto=256) at ../../kern/kern_shutdown.c:233
#9 0xc014debc in poweroff_wait (junk=0xc0253820, howto=36273280)
at ../../kern/kern_shutdown.c:556
#10 0xc01e7d3b in allocdirect_merge (adphead=0xc2b30244, newadp=0xc305c100,
oldadp=0xc305c580) at ../../ufs/ffs/ffs_softdep.c:1323
#11 0xc01eaab9 in merge_inode_lists (inodedep=0xc2b30200)
at
lpt - newbus breakage?
The lpt driver has a bunch of flags in the high bits of the minor device number which affect device behaviour. Most of these appear to have been broken since newbus - if you create the /dev node and try to open it, you get "Device not configured", and the lptopen() entry point in the driver doesn't get called. The following fixes it for the specific case I am interested in: Index: lpt.c === RCS file: /repository/src/sys/dev/ppbus/lpt.c,v retrieving revision 1.15.2.3 diff -c -r1.15.2.3 lpt.c *** lpt.c 2000/07/07 00:30:40 1.15.2.3 --- lpt.c 2000/08/29 11:29:28 *** *** 417,422 --- 417,424 UID_ROOT, GID_WHEEL, 0600, LPT_NAME "%d", unit); make_dev(lpt_cdevsw, unit | LP_BYPASS, UID_ROOT, GID_WHEEL, 0600, LPT_NAME "%d.ctl", unit); + make_dev(lpt_cdevsw, unit | LP_PRIMEOPEN, + UID_ROOT, GID_WHEEL, 0600, LPT_NAME "%d.reset", unit); return (0); } but full coverage of the combinations of the 4 option bits would need 16 such entries. Even omitting combinations that have no obvious use gives 7 entries. Is this how things are meant to be done? What about drivers that pack a ton of info into the minor device? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problem with psm0
On Tue, 14 Dec 1999, Kazutaka YOKOTA wrote: I have two systems, both now running 3.4-RC (built from the most recent source I had via CTM a couple of hours ago). I also have two very similar mice. However: [...] system1 is a Gigabyte 71X Athlon motherboard (AMD chipset) system2 is a PC-Chips socket-7 motherboard (SiS chipset) mouse1 is a MouseSystems M5 PS/2 optical mouse (model 403011-001) mouse2 is a MouseSystems type 2544 PS/2 optical mouse (model 404273-001) Both have been in use for some time on FreeBSD 2.2 systems (the main difference between mouse1 and mouse2 is that mouse1 cost about 4 times as much and has slightly better buttons!). When you were running FreeBSD 2.2, were you using the above motherboards? No, system 1 is brand-new (when upgrading from 2.2 to 3.x I replaced the whole machine, just keeping the kbd/mouse/screen). I just tried booting a 2.2.8-RELEASE CD in the problem machine, and it didn't detect psm0 either, so this is a red herring. I then went looking for a hardware problem. I thought I was onto something when I measured the +5V on-load voltage at the PS/2 keyboard/mouse ports as only 4.71V: this motherboard seems to have a high-resistance fuse. However, soldering a wire to bypass the fuse gave me a solid 5.01V but no change in the behaviour. I suppose I ought to try installing Windows and see if the mouse works there, though that will take some time as this is currently an all-SCSI machine. System1/Mouse1: [...] psm0: current command byte:0047 kbdc: TEST_AUX_PORT status: kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status: kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status: psm0: failed to reset the aux device. psm0 not found Do you by any chance use any console switch? We may have a timing problem here. Would you send us the full dmesg output? I do not have a switch: the mouse is plugged directly into the motherboard mouse port. Full dmesg output is attached. In the meantime, try adding the following options in your kernel configuration file. options KBDIO_MAXWAIT 10 The default value is 5. Increase the value if your mouse is not still recognized. I assume you mean "options KBD_MAXWAIT=10" ? I tried this, but it had no effect. I also tried other values, including: options KBD_MAXWAIT=10 options KBD_RESETDELAY=1000 options KBD_MAXRETRY=10 but again no obvious effect (other than a noticeable delay at that point in the boot sequence). Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.4-RC #7: Wed Dec 15 00:46:57 GMT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/ROCKET Calibrating clock(s) ... TSC clock: 598896444 Hz, i8254 clock: 1193301 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: AMD-K7(tm) Processor (598.84-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x612 Stepping = 2 Features=0x81f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX AMD Features=0xc040b22,b30,3DNow! Data TLB: 24 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative real memory = 134217728 (131072K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x002e8000 - 0x07ff5fff, 131129344 bytes (32014 pages) avail memory = 127516672 (124528K bytes) Found BIOS32 Service Directory header at 0xc00fafc0 Entry = 0xfb430 (0xc00fb430) Rev = 0 Len = 1 PCI BIOS entry at 0xb460 SMIBIOS header at 0xc00f5040 Version 2.1 Table at 0xf0800, 39 entries, 958 bytes, largest entry 74 bytes DMI header at 0xc00f5050 Version 2.1 Table at 0xf0800, 39 entries, 958 bytes Other BIOS signatures found: ACPI: $PnP: 000fc0a0 Preloaded elf kernel "kernel" at 0xc02cf000. VESA: information block 56 45 53 41 00 02 00 01 00 01 00 00 00 00 22 00 00 01 80 00 00 01 0b 01 00 01 21 01 00 01 2a 01 00 01 00 01 01 01 10 01 11 01 12 01 03 01 13 01 14 01 15 01 05 01 16 01 17 01 18 01 07 01 19 01 VESA: 3 mode(s) found Pentium Pro MTRR support enabled Math emulator present pci_open(1):mode 1 addr port (0x0cf8) is 0x80003840 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=70061022) Probing for devices on PCI bus 0: found- vendor=0x1022, dev=0x7006, revid=0x23 class=06-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 map[0]: type 3, range 32, base d800, size 26 map[1]: type 3, range 32, base e3101000, size 12
