Mysterious system freeze-ups on my consoles...
Howdy. I've had this problem on FreeBSD 4.x for some time, on occasion. What happens is that when using a handful of full-screen applications on the normal syscons consoles (alt-F1 on up), the system occasionally locks up entirely right as I'm doing some navigation on the screen. I can't get into the debugger, or do anything at all from the console, the machine has suddenly completely wedged, and whatever else it may have been doing stops. (I haven't tried a remote console debugger.) What would cause such a total lockup -- would it be interrupt/locking related? I'm ignorant here. This happens when I'm online, networked, as the full-screen applications (lynx and links web browsers) don't really work without a network connection, and it has definitely happened when I've been connected over dial-in PPP via a serial port, and more recently I believe I've been connected via a USB-attached ethernet adapter. I don't recall it happening at any time when I was connected via an internal ISA or PCI network card. Is it possible that these freezes are related to the serial port, or over USB? One almost sure-fire way for it to happen with serial-port PPP was to expand a menu of items to select. Recently the freezes happened rather regularly viewing Google with lynx going off the top line to the input field. Version of lynx made no difference, and `links' had the same problem somewhere. Running `lynx' in an xterm, I simply haven't had this problem at all. Nor does normal console use, as far as I can see. 4.x kernel is more than half a year old but I've had the problem for at least a year; have not tried a newer kernel yet. Please let me know if my hypothesis that data arriving via the serial port or via USB combined with cons25-type screen activity could be the cause of this, or if it's just coincidence, as well as what is likely to cause a complete solid wedge, for my education. Thanks. barry bouwsma ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB OHCI problems...
[drop me from any replies, and I'll catch up from the archives, thanx] On Wed, 1 Dec 2004 10:48:42 +1030, "Daniel O'Connor" wrote: > > In addition, I've connected a uaudio sound device, which > > works to play audio for between 10 and 13 minutes, before > > bombing out with an error in ohci_device_isoc_enter(), > On a side note.. > How are you testing it? ``waveplay -S 48000 -f /dev/dsp[0-2]'' (when part of a pipeline that cuts off the WAV header info), or via a wrapper that invokes `ogg123' with the appropriate /dev/dsp? audio device. Into a pair of headphones. I haven't done a serious comprehensive test to try recording or anything; that comes later. > Last time I tried my USB audio device I got pretty reliable panics trying to > get KDE to use it :( Which FreeBSD and what sort of device? My FreeBSD-4.x is using as much USB code from -current as possible, which might make some difference. The uaudio device I have is one that I inquired about some months back in either the -multimedia or -hardware list -- I need to dig out that post, and make a followup to it with potentially useful info sometime later today. There are, um, ``interesting'' things I've observed, which I'll mention in my followup to whichever list, that I need to verify are independent of UHCI/OHCI controller, and also whether afflict NetBSD as well. NetBSD also gives me more access to the device. FreeBSD finds it as uaudio and uhid, and (my module source) plays back at a fixed volume level (apparently samplerate too). The (usual) worst I experience is the `isoc TD' message followed by a `pcmX:play: timeout, channel dead' type of message, after which the device no longer works. While I've had panics from other causes, I don't think any of mine could be pinned on the uaudio/uhid device -- but I haven't done much in the way of connect/disconnecting and stuff. thanks barry bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Soundcard tweaking: `mixer' v. `sysctl' ?
[drop me from replies and I'll catch up from the archives RSN] I seek guidance in my hideous hacking. I have multiple sound cards based on the CMI8738 chip with spdif input in one machine, for which I was using hacked kernel modules to select either optical or coaxial spdif input from both cards. The cmpci driver under NetBSD has far more functionality, allowing one to use mixerctl/audioctl to access much more than FreeBSD's mixer or sysctl can give me. Now that I'm wanting to record from different sources on the two cards, as well as having been spoilt by what NetBSD is able to offer in monitoring and whatnot, I'm wanting to hack comparable functionality into my FreeBSD kernel modules. My first ugly hack makes use of two added mixer inputs to allow me to select one of the two spdif inputs independently of the other card, with `mixer', whee. After I had had no luck with my wish to use a sysctl to select recording source like the NetBSD mixerctl program. First question, am I missing anything that gives sysctl-like control over sound devices, under my FreeBSD4? Secondly, after another attempt to whup the sysctl into submission, I had success. Yow. So I was able to duplicate my `mixer' input source selection hack as a `sysctl' input source selection hack, as well as introduce a handful of other sysctl knobs to be used to tweak things important to me, leaving the door open for others. So, should I give up on `mixer' in favour of `sysctl' to select recording source (the spdif inputs are exclusive), or is it still reasonable/preferable to use `mixer =rec dig1' as my earlier hacks allow (haven't tried to make those disappear from the mixer itself, as the level cannot be adjusted) ? In addition, for something like enabling spdif monitor to the analog outputs (which NetBSD's mixerctl spdif.monitor allows me to do), should this be done with a sysctl, as my later hack does, or by something else? There's already one sysctl for this sound driver to enable spdif playback output, so I would imagine this is the way to go. Apologies for my stupidity. And I'll submit (ugly) patches, when I'm happy with my hacks. If desired. thanks barry bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB OHCI problems...
Just to add to what I wrote at the end of October:
> Anyway, under FreeBSD-4 with kernel modules built 10.August
> from source that I believe is based on FreeBSD-5-current of
> that era, I'm seeing corruption of data read from umass
> devices attached to an OHCI controller card. Use of a UHCI
> controller card instead seems mostly free of problems.
In addition, I've connected a uaudio sound device, which
works to play audio for between 10 and 13 minutes, before
bombing out with an error in ohci_device_isoc_enter(),
tripping over one of the two
/* Allocate next ITD */
nsitd = ohci_alloc_sitd(sc);
if (nsitd == NULL) {
/* XXX what now? */
printf("%s: isoc TD alloc failed\n",
USBDEVNAME(sc->sc_bus.bdev));
return;
}
Connecting this uaudio device to a UHCI card results in
problem-free playback for at least a couple hours. And,
I'm rather sure that I was able to play through this OHCI
controller under NetBSD for an extended time. This device
does not attach to EHCI.
For this, I used kernel modules on my FreeBSD 4.x box,
recently built from as much of the -current USB code as
I could get to compile with minimal hackery, but this time
without merging in the work in P4 from Ian Dowse, or the
patchsets based on these. Source code date at least a
couple weeks to a month old.
I'll try updating to the most recent code I can lay me
grubby mitts on (stop with all these updates while I'm
offline, eh) as well as the above patchsets, to see if
things are changed in the OHCI world.
Also, I'm about to the point of readiness to acquire another
card with OHCI to see if any chipset-specific problems could
be tickling my problems -- though NetBSD appears to work
mostly fine. This OHCI chipset is on a combi-card in a
machine with a severe lack of PCI slots, while my UHCI card
is devoted to USB and fit better into a machine with a lack
(but not quite so severe) of PCI slots. Perhaps there's a
PCI-PCI bridge on the card in the way, but there's a firewire
controller on the card sharing the interrupt with OHCI, and
I have no problems with the firewire.
thanks
barry bouwsma
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB OHCI problems...
Apologies for this posting, as so far as I know it's a known issue that the USB OHCI code has some problems, or perhaps that there have been code commits in the last weeks so this is no longer a problem... Anyway, under FreeBSD-4 with kernel modules built 10.August from source that I believe is based on FreeBSD-5-current of that era, I'm seeing corruption of data read from umass devices attached to an OHCI controller card. Use of a UHCI controller card instead seems mostly free of problems. In comparison, I accessed the data with NetBSD-current of similar vintage, and in the files copied with the identical hardware, the data is intact. The point at which the corruption begins is at some multiple of 16384 bytes into the file. The corruption is not consistent, as it is less likely to occur when the machine is somewhat idle, and as the below shows, also occurs at different points into the same file. I haven't looked to see for how long this corruption is present (it's more than a few hundred bytes, at least) or how the file appears after this, or whether this corruption follows any particular pattern of the rest of the file. The below is `cmp' output under my FreeBSD, compared against the files previously downloaded with NetBSD (and verified that all the images are intact). /cdrom/dcim/100dscim/pict0681.jpg pict0681.jpg differ: char 524289, line 2284 /cdrom/dcim/100dscim/pict0683.jpg pict0683.jpg differ: char 507905, line 2116 /cdrom/dcim/100dscim/pict0684.jpg pict0684.jpg differ: char 1163265, line 3323 /cdrom/dcim/100dscim/pict0685.jpg pict0685.jpg differ: char 294913, line 1402 /cdrom/dcim/100dscim/pict0686.jpg pict0686.jpg differ: char 393217, line 1716 /cdrom/dcim/100dscim/pict0687.jpg pict0687.jpg differ: char 753665, line 2606 /cdrom/dcim/100dscim/pict0686.jpg pict0686.jpg differ: char 983041, line 3648 This is just a sample -- note that the last line is the same file that I had previously `cmp'ed two lines above. In fairness, the files copied from NetBSD were done with the machine mostly idle, so I don't know if NetBSD suffers the same if I were pounding the machine. If this issue hasn't been handled, perhaps the fact that NetBSD doesn't seem to have problems might give someone some ideas as to where the problem might lie. As usual, apologies for the untimeliness of this, as well as my lack of detailed testing with fresh -current or with code fresher than two months ago. thanks barry bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: probe ordering of interfaces
Mike Meyer wrote: > > Even more specifically, I have a drive that I either attach > > via firewire on one machine, or via USB on a different box. > > I wish this drive to always be da0. I can connect it to a > You can do this in the config file. > deviceahc0# AHA2940 and onboard AIC7xxx devices > devicescbus0 at ahc0 # SCSI bus (required) Ah, thanks. Ah, hmmm. Ah, yes. Ah, oh no. Hmmm, you see, at the moment, I'm using kernel modules for my firewire and also usb support. (I'm not even sure I could build a kernel from the same code base, without a bunch of work to track down where I've hid the hacked source for the usb support, in particular, if I'd want to -- the ease with which I can add and back out, say, ehci awareness is one reason why I'm not yet ready to change.) I suspect that I'll have to wake up a bit and grovel around in the source to get things working for me... Thanks for the reply anyway. barry bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ISA card and if_ed as module
[keep replies to the list and I'll catch up later, thanks] > : Is it to be expected that the kernel if_ed.ko module appears to > : be unable to probe and attach an ISA NIC, while when I build the > Yes and No. If the ISA nic is PNP, it will just work. IF not, you > have to have the 'hints' in the kernel. I have the hints framework > backported, but I don't know if it was ever committed. Too old for pnp, so I'm out of luck there. I have hints on my -stable machine (for other reasons), and I can see that they show up in the `loader' environment, but that still isn't enough to probe the device. I'll assume this means that hints doesn't work (hasn't been backported) in -stable. Would it be possible for me to get a copy of your work to see if that's enough to make the NIC appear? A pointer would suffice -- particularly if others would want to try it -- unless you prefer to mail it. (I've looked quickly for obvious differences between -stable and -current that would be relevant but don't really see them) And yes, the NIC does show up in -current, so while part of the framework is in -stable, actually turning those environment hints into action just doesn't happen. thanks barry bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ISA card and if_ed as module
[keep replies to the list and I'll catch up later, thanks] Hallowed hackers: Is it to be expected that the kernel if_ed.ko module appears to be unable to probe and attach an ISA NIC, while when I build the ed* support into the kernel, it works? This is with RELENG_4. Or should kernel modules be able to probe and attach ISA as well as pci/pccard devices? Sorry if this is a questions@ type of question, but I'd like an explanation too... I've added a bunch of debuggery to see which routines get invoked at `kldload' time. I see that ed_pci_probe is called a couple of times, and at boot a couple more times. However, in neither case does my debugging to indicate that any ISA probe might be happening, show up, which reflects the total absence of any ed0 messages at boot, unless I build the device into the kernel. If there's a good reason why, I'll be happy to keep ed* in my kernel (maybe, I'm not sure if the presence of `miibus' as well causes problems with the autoloading of module miibus when other NIC modules get loaded...) thanks barry bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
man/cat pages, compressed/or not
Salutations, dudes. I've added an unsightly hack to `man' so that when it creates catpages from the compressed manpages, it's possible that they can be created uncompressed (for the benefit of older slower machines with newer big disks). But I'm wondering what's the best way to do this, if this is something that might be of general interest... (I think I also took a meatgrinder to `catman' some time back to get it to spit out uncompressed pages. I can't remember what problems I may have had, in that `man' didn't seem to want to use these pages, but that may be solved by my latest hacks.) There's a make.conf variable one can set to create uncompressed man pages; should there be something similar to decide whether man should create compressed or uncompressed catpages? Right now, I just let one define another option, which makes man put out uncompressed pages, in the Makefile (where the DO_COMPRESS is defined). Purely as a proof of concept. Is such an option desirable for anyone else as well? With this, one can have compressed manpages (to save space on seldom-accessed files), and uncompressed corresponding catpages for fast access... (I know, you'll tell me that if I have a big disk and a slow machine, there's no reason to want compressed manpages to go with the uncompressed catpages, so set NOMANCOMPRESS=true.) thanks barry bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pci_cfgintr: can't route an interrupt ...
This message is ancient, but I finally got things (sort of) working just now. More context can be found in the first message in this thread On Tue, 23 Dec 2003, John Baldwin wrote: > On 23-Dec-2003 Barry Bouwsma wrote: > > > There was a thread about this in this list back in late may of 2003. > > I recently found a mainboard which exhibits this problem with one particular > > card I have -- a combi OHCI+EHCI USB card with firewire, and an on-card > > HiNT PCI-PCI bridge. > FreeBSD-4 is not going to route interrupts correctly across an onboard > PCI-PCI bridge or any devices behind it. FreeBSD-5 will, but 4.x will > not. Try disabling PNP OS in your BIOS if you have it set to get the > BIOS to route all the interrupts if possible. Well, I decided to take the easy way out. I saw nothing in the BIOS of this particular machine that would make any difference (no PNP OS choice). Rather than using an older machine whose BIOS does assign interrupts to every controller, or buying a newer machine, or using 5.x, I decided to try to hack in parts of -current into 4.x to make it work. And I had some success. But the hacks really aren't worthy of public sharing, since, for starters, the assign_interrupt_method kept wanting to give me irq 6 -- the floppy controller irq which is assigned later in the boot. Certainly my fault. I have a handful of ideas for what could be wrong here. But I hacked around this by overriding the irq to something reasonable, and that worked, although I had to set the values precisely for things to work (intpin b to irq 11; intpin c to irq 10). And work it did, and I was overjoyed. Problems were observed elsewhere, as expected. But finally I could access devices on these two controllers. Unfortunately, I don't know what I'm doing enough to have created a clean patch that Just Works with 4.x, which is what I had hoped to offer in a message like this one, to be able to share and enjoy. sorry, barry bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP!!! USB MFC committed..
[sorry for the late followup. also, my address is ipv6-only; drop it and I'll catch up from the archives after some time] > On Sun, 29 Feb 2004, Julian Elischer wrote: > > The USB code in RELENG_4 has been updated to match that in -current. > > Please test any USB devices that are critical to you BEFORE we release > > 4.10 :-) > p.s. there are some more MFCs to come but they are minor > (except for what looks like a major rewrite of parts of umass) Would it be possible to merge in the umass parts of -current that enable all slots of a 6/8/whetever-in-1 USB card reader/writer thingies to be detected? In source updated around 30.mar, building the umass -stable kernel module only finds the CF slot. I've added a few dozen lines to the -current umass code and built a module from that which appears to work as needed (meaning, I have not had major problems, but I haven't stress-tested it) with the -stable usb code and kernel I'm using. This gives me all sorts of da* devices (see below). Unfortunately, adding EHCI support to the usb.ko module causes panics with such a umass.ko module; adding an EBUSY line to match -stable seems to make things better, but not perfect (from what I can remember). The below result is with only uhci/ohci support. My added-lines hack is not based on knowing what I'm doing, but rather based on what appears superficially to work and is probably horribly wrong. I believe the code to add support for the card readers was added to -current something like a year ago, and may possibly be found in a patch mentioned around that time by Bernd Walter -- as I have not been online, I haven't been able to download it and check. The -current diff appears to be between 1.79 and 1.80, but when massaged into -stable, I don't get all the devices (can be my fault). My world/kernel/modules on the machine in question are a horrible mongrel mix spanning the last couple of years and originate from both -stable and adopted out of -current, so I hesitate to make a fool of myself by publicly posting the added lines to umass.c from -current to make it operate with my mostly-stable. (Actually, it looks like all I did was to un-re-implement cam_calc_geometry() back to what was in -stable, and to say that I don't have a ZIP_100 so I could junk that portion of the code just to get it to compile quietly, rather than to make it work.) thanks barry bouwsma Preloaded elf module "usb_NEW.ko" at 0xc042f600. Preloaded elf module "ums_NEW.ko" at 0xc042f6a0. Preloaded elf module "ugen_NEW.ko" at 0xc042f740. Preloaded elf module "umass_CURRENT.ko" at 0xc042f7e0. [...] umass1: OTi USB 7-in-1 Card Reader, rev 2.00/2.00, addr 4 umass1:1:1:-1: Attached to scbus1 [...] umass2: SMSC 223 USB97C223, rev 2.00/1.95, addr 7 umass2:2:2:-1: Attached to scbus2 [...] Creating DISK da0 Creating DISK da1 Creating DISK da2 Creating DISK da3 Creating DISK da4 Creating DISK da5 Creating DISK da6 Creating DISK da7 Creating DISK da8 [snipping for brevity] da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: Serial Number A80A06AE da0: 1.000MB/s transfers da0: 239371MB (490232832 512 byte sectors: 255H 63S/T 30515C) da1 at umass-sim1 bus 1 target 0 lun 0 da1: Removable Direct Access SCSI-0 device [Serial Number lines from this umass device are a control-underscore] da1: 1.000MB/s transfers da5 at umass-sim2 bus 2 target 0 lun 0 da5: Removable Direct Access SCSI-0 device da5: Serial Number da5: 1.000MB/s transfers da2 at umass-sim1 bus 1 target 0 lun 1 da2: Removable Direct Access SCSI-0 device da2: 1.000MB/s transfers da3 at umass-sim1 bus 1 target 0 lun 2 da3: Removable Direct Access SCSI-0 device da3: 1.000MB/s transfers da3: 60MB (124160 512 byte sectors: 64H 32S/T 60C) da6 at umass-sim2 bus 2 target 0 lun 1 da6: Removable Direct Access SCSI-0 device da6: Serial Number da6: 1.000MB/s transfers da4 at umass-sim1 bus 1 target 0 lun 3 da4: Removable Direct Access SCSI-0 device da4: 1.000MB/s transfers da7 at umass-sim2 bus 2 target 0 lun 2 da7: Removable Direct Access SCSI-0 device da7: Serial Number da7: 1.000MB/s transfers da8 at umass-sim2 bus 2 target 0 lun 3 da8: Removable Direct Access SCSI-0 device da8: Serial Number da8: 1.000MB/s transfers da8: 243MB (498176 512 byte sectors: 64H 32S/T 243C) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
dev_mkdb coredumps under -stable with a different root disk...
[bla bla drop address to reply bla bla archives bla bla IPv6 bla] Howdy, This probably isn't the right place to ask, but here goes anyway... Is there a good reason why `dev_mkdb' should coredump when encountering selected devices in a /dev directory on a different filesystem than that containing the kernel which I booted? It has no problems on the /dev directory on the disk I used to keep kernel, root, and all -- only on a different disk to which I copied (then later re-created) the /dev directory from the original. FreeBSD 4.x in use from some months back. Also, the /var/run directory on the original disk contains a suitably small dev.db file: -rw-r--r-- 1 root wheel 32768 Dec 24 18:56 /var/run/dev.db while that from the not-original disk is far larger: -rw-r--r-- 1 root wheel150929408 Dec 18 11:29 dev.db which probably explains why it takes several minutes to run, but I still wonder *why* it's much larger and induces coredumps. I got fed up with the CMD640 chipset on this old machine and decided to use it for little more than booting the kernel. So I tar'red me up the / and /usr filesystems and untarred them onto a firewire-attached disk. Well, actually, I first tried `pax' for fun, but upon extracting the /dev directory, it seemed all devices were created with major/minor numbers of 0, though my system (4.something) is a bit old. `tar' only had a problem with two foo.ctl devices, complaining the number was too big or something, so I went ahead with that. Booting, then mounting root at ufs:/dev/daFOO went mostly okay, but as noted, dev_mkdb kept sig-11'ing on me. So I recreated /dev from scratch with MAKEDEV if something was messed up in untarring. Still no joy. In order to achieve joy, it turned out I needed to delete a good number of devices: apparently all raw disk and tape and similar devices; plus all `c' disk partitions and such, and maybe a few others I don't remember -- I think the .ctl devices that failed `tar' also had to fall victim. Finally, dev_mkdb finished. Other than that, and a small bit of minor tweaking, things are working fine, and the accursed CMD640 only gets to hog interrupts at boot, after which it's no longer needed for the system root and utilities and logs, and I appear to achieve the performance I sought. Is there a simple explanation why a manually-specified root filesystem somewhere else (specified in loader.conf) triggers an intense dislike of raw devices and whole-device partitions? Might a different block/ fragment size have something to do with it? (I shared an existing partition created with a completely different purpose in mind, for which 65536/32768 b/fsize was more appropriate for multi-gig files.) thanks, Barry Bouwsma, puzzled ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pci_cfgintr: can't route an interrupt ...
#x27;s what NetBSD had to say at boot about it on that machine: BIOS32 rev. 0 found at 0xf8080 [...] ppb0 at pci0 dev 11 function 0: HiNT HB1 PCI-PCI Bridge (rev. 0x11) pci1 at ppb0 bus 1 pci1: i/o space, memory space enabled, rd/line, wr/inv ok ohci0 at pci1 dev 8 function 0: NEC USB Host Controller (rev. 0x41) ohci0: interrupting at irq 9 ohci0: OHCI version 1.0 usb at ohci0 not configured ohci1 at pci1 dev 8 function 1: NEC USB Host Controller (rev. 0x41) ohci1: interrupting at irq 9 ohci1: OHCI version 1.0 usb at ohci1 not configured ehci0 at pci1 dev 8 function 2: NEC USB Host Controller (rev. 0x02) ehci0: interrupting at irq 9 ehci0: EHCI version 0.95 ehci0: companion controllers, 3 ports each: ohci0 ohci1 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 uhub1: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 5 ports with 5 removable, self powered fwohci0 at pci1 dev 11 function 0: VIA Technologies VT3606 OHCI IEEE 1394 Contro ller (rev. 0x46) fwohci0: interrupting at irq 9 fwohci0: OHCI 1.0, 00:10:74:70:00:10:0b:f3, 400Mb/s, 2048 max_rec, 8 ir_ctx, 8 i t_ctx (hrm, haven't tried anything but FreeBSD 3.x and 4.x on the problematic newly-acquired board, sorry to say) Now, the ``new'' board appears to wedge solid at times with this card, accessing a firewire-attached drive. No debugger, no keyboard input, no numlock, no nuthin' that I can see, just power-cycle the thing. Would this probably be an interrupt issue? If so, would it possibly be related to fwohci sharing interrupts with many other cards, including the usb ohci? (my ohci code dates from a few months back, and I know there have been a good number of fixes) The devices sharing this IRQ are pcm0: port 0x6100-0x617f irq 12 at device 9 .0 on pci0 ohci0: mem 0xd000-0xdfff irq 12 at device 8.0 on pci1 fwohci0: port 0xe000-0xe07f mem 0xd0003000-0xd00037ff irq 12 at dev ice 11.0 on pci1 uhci0: port 0x6300-0x631f irq 12 at device 11.0 on p ci0 pci0: (vendor=0x1106, dev=0x3104) at 11.2 irq 12 At the moment, I'm running this machine with the combi-ohci+fw card swapped out for two separate uhci usb and fwohci firewire cards, also at irq12. No wedges yet after a day of operation. Now, I'll quote from this thread back late May, and pose questions: M. Warner Losh: > : > You lose. W/o a pci interrupt router, you can't use the cardbus > : > bridge. > : Good - so who/what should set up a PCI router ? the Bios ? > It depends. Really old machines routed interrupts to all PCI slots > and assigned devices found there an interrupt. Newer old machines > expect the PCI bridge driver of the OS to cope. Newer old machines > provide a BIOS interface to route them (which we can use). Newer > machines with ACPI have ACPI to do the routing. You might want to do Would my newly-found motherboard be a Really Old Machine, or is that what is happening in the DEC Venturis machine where it works? As shown above, they both have PCIBIOS shown in the verbose boot... This isn't a cardbus bridge, rather an on-card PCI bridge, for whatever difference that makes. I have at hand no newer machines than 100+MHz pentium vintage at least six years old -- certainly no ACPI -- so I can't compare in newer boxes, sorry. I could try NetBSD, which disk is currently in use in a different machine, to see how it copes with this board/card combination. thanks barry bouwsma dumpster-diving for motherboards better off left behind ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB card overcurrent problems...
[Drop my (IPv6-only) address when replying -- I'm offline too much, and I'm not even sure if all the ISPs I use let IPv4 mail through either] [Sorry for being offline so long, and the delay in this reply...] > > fine, but the other one, an OHCI card, out-of-the-box exhibits problems. > > Chipset is identified in dmesg as NEC uPD 9210 USB controller. > Current protection and limiting is completely up to the card designer. > The best that FreeBSD can do is getting informed if the card design > allows it, but I almost never saw a card doing this. The source has the following comment: /* Fiddle the No OverCurrent Protection bit to avoid chip bug. */ desca = OREAD4(sc, OHCI_RH_DESCRIPTOR_A); OWRITE4(sc, OHCI_RH_DESCRIPTOR_A, desca | OHCI_NOCP); OWRITE4(sc, OHCI_RH_STATUS, OHCI_LPSC); /* Enable port power */ usb_delay_ms(&sc->sc_bus, OHCI_ENABLE_POWER_DELAY); OWRITE4(sc, OHCI_RH_DESCRIPTOR_A, desca); (Somehow that didn't make it into my hacked code; hmmm, I wonder if I really hacked what I thought I was hacking -- I did try it alone once, which wasn't enough to reliably power the external hub) Since this doesn't seem to be in the RELENG_4 branch, or else I've really botched my cvs tags, and the commit comment mentions that it afflicts some OHCI controllers, I wonder if I have an even buggier chip. Nonetheless, I've apparently managed to make it work, somehow, after boot, in spite of the overcurrent. During boot (or when auto-loaded at boot by usbd), though, it seems to hang with a timeout during the port reset. I need to make more sense of my hacks... More hacking has allowed me to also sometimes power it up at boot, although with a painful delay, unlike my after-boot hack which powers it on cleanly. > Either your hubs really use more power then it is allowed to or you I wondered, but there were several things that made me suspicious that this was not the case. Then, some other things make me suspect that it could be the case too: = favoring the idea that the hub does not take too much power: * the external hub works without any problems with a built-in UHCI USB, * it also works fine with a different UHCI PCI card, * I can connect an external power supply to the hub, also with current- drawing devices attached to the USB ports, then disconnect this power supply after everything is detected and the bus-power takes over with no overcurrent problems, * my hacks of repeatedly applying power a few times are enough to power up the external hub, also with bus-powered devices attached... = favoring the idea that the hub does take too much power: * connecting a bus-powered USB mouse dongle to this same card does not trigger any overcurrent warnings. (I have no other USB devices now) Does `usbctl' or any similar utility give the aktuell current being supplied on a particular port? All I see is for the internal OHCI hub, (some snippage) iManufacturer=1(NEC) iProduct=2(OHCI root hub) iSerialNumber=0() bNumConfigurations=1 CONFIGURATION descriptor 0: bLength=9 bDescriptorType=config(2) wTotalLength=25 bNumInterface=1 bConfigurationValue=1 iConfiguration=0() bmAttributes=40 bMaxPower=0 mA HUB descriptor: bDescLength=10 bDescriptorType=41 bNbrPorts=2 wHubCharacteristics=00 bPwrOn2PwrGood=255 bHubContrCurrent=0 DeviceRemovable=0 and for the external (Cypress) hub, bDeviceProtocol=0 bMaxPacketSize=64 idVendor=0x04b4 idProduct=0x6560 bcdDevice=7 iManufacturer=0() iProduct=0() iSerialNumber=0() bNumConfigurations=1 CONFIGURATION descriptor 0: bLength=9 bDescriptorType=config(2) wTotalLength=25 bNumInterface=1 bConfigurationValue=1 iConfiguration=0() bmAttributes=e0 bMaxPower=100 mA HUB descriptor: bDescLength=9 bDescriptorType=41 bNbrPorts=4 wHubCharacteristics=89 bPwrOn2PwrGood=50 bHubContrCurrent=100 DeviceRemovable=0 This is comparable to the mouse dongle bMaxPower=100 mA so I'm sure I'm not seeing the actual current the device is sucking down. Another Interesting Thing is that `usbdevs' reports this external hub always as self-powered, even when it takes its power from the bus... port 1 addr 2: self powered, config 1, product 0x6560(0x6560), Cypress Semicond uctor(0x04b4), rev 0.07 If that makes any difference. > have a broken controller card. This is possible, for it was in a opened package marked a few Euro less than normal, and I figured I'd take a chance, what with some 95% of the junk I pick up at a discount or being discarded working fine for me, and someone might have only been dissatisfied with it (or had an IRQ problem, as I seemed to have earlier). I'll either keep my present hacks, and continue to hack on the at-boot case to see if I can arrive at a clean power-on, or keep the external hub attached to its power supply cord, or try yet another card, or some combination of the above, or something different.
Re: USB2.0 external hub and ehci question
[heh, got this reply over IPv6, sorry about the other bounce, at least some mail passes some ISPs, but drop me anyway and I'll catch the archives] [sorry for the delay, you know, offline, real-life, laziness, etc] > > namely, that I can't attach an external hub, supposedly with USB2.0 > > capability, and have it be recognized. > > When I connect the external hub in its place, I get the error that the > > port was disabled, STALLED -- just as I saw under old NetBSD. > cypress hubs stall the controll endpoint without a reason when running > high speed - even if it had one the specs say that the control endpoint > shouldn't stall at all. Oh wonderful. So I have a shiny USB1.x hub with a USB2.0 label. Heck, it was fun anyway, though it does sometimes work as USB1.x too... > I have a workaround for the probing problem, but USB2 hubs won't work > anyway, because at ehci is missing support for interrupt endpoints. Oh joy. I assume you mean that the current ehci.c codebase is missing the support for this, and that some time in the future it may be added or imported, rather than that it's not at all possible? In other words, if the USB2-labelled hubs I see frequently nowadays in grocery stores and the like might work later, I should still consider them, and/or trying to hack the codebase? In any case, maybe I need to disable the probing for a hub of this type, as a Long Time Ago, with NetBSD, the EHCI probe failed (that stalled error), and no USB1 attach was done. Admittedly, I don't know if this is also the case under FreeBSD, since I haven't properly updated my machine to -current. > Maybe there are other show stopppers too. Erk. Thanks for your informative replies! Barry Bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB2.0 external hub and ehci question
[Drop hostname part of IPv6-only address above to obtain IPv4-capable e-mail, or just drop me from the recipients and I'll catch up from the archives] Hallo Hackers, I suppose I should post this to -current as the code in question is derived from there, but I'm running it on RELENG_4, so... I've ported the USB controller codes (uhci, ohci, and ehci) from -current to 4.9-PRERELEASE in order to try and add USB2.0 support to 4.x, and I see something that I also saw with the NetBSD ehci codes back last December; namely, that I can't attach an external hub, supposedly with USB2.0 capability, and have it be recognized. First, I seem to have no problems building just the uhci and ohci codes into the usb.ko kernel module, and using them, though I haven't thoroughly crash-tested them. I've mixed all three controller codes, with the result that the hub is not seen. Nor is the external drive. Which I attribute to my own incompetence more than anything. So to make things easier, I ditched all but the ehci code and ignored the check for companion controllers, to limit testing to just that. With an external USB2.0 drive connected, I am able to see and mount it. When I connect the external hub in its place, I get the error that the port was disabled, STALLED -- just as I saw under old NetBSD. I haven't built -current, or a more recent NetBSD, to see if their behaviour is any different when faced with this hub. Is it possible I need some sort of quirks entry for this device, which I can use as a USB1.x device fine? Or do I not even get that far? Here's the dmesg with uhubdebug and ehcidebug set to 1, with a few comments... (I may have added a few additional debug printf()s too) ehci0: mem 0xfdffdc00-0xfdffdcff irq 10 at device 8.2 on pci1 using shared irq10. ehci_init: start usb0: EHCI version 0.95 ehci_init: sparams=0x2395 usb0: wrong number of companions (2 != 0) This here is the PCI card, along with my hack mentioned. [ snip ... ] usb0: on ehci0 usb0: USB revision 2.0 usbd_new_device bus=0xc1728000 port=0 depth=0 speed=0 ehci_open: pipe=0xc1727580, addr=0, endpt=0 (0) usbd_new_device: adding unit addr=1, rev=200, class=9, subclass=0, protocol=1, maxpacket=64, len=18, speed=0 uhub0: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub0: 5 ports with 5 removable, self powered ehci_open: pipe=0xc1727400, addr=1, endpt=129 (1) usb_init_port: turn on port 1 power usb_init_port: turn on port 2 power usb_init_port: turn on port 3 power usb_init_port: turn on port 4 power usb_init_port: turn on port 5 power ehci_pcd: change=0x02 uhub_explore: port 1 status 0x0501 0x0001 uhub_explore: status change hub=1 port=1 ehci after reset, status=0x1005 ehci port 1 reset, status = 0x1005 uhub speed is 3 usbd_new_device bus=0xc1728000 port=1 depth=1 speed=3 ehci_open: pipe=0xc1727180, addr=0, endpt=0 (1) ehci_device_ctrl_close: pipe=0xc1727180 ehci_intr1: door bell uhub_explore: usb_new_device failed, error=STALLED uhub0: device problem, disabling port 1 I can provide a dmesg with a higher debug level, if it would be desired. This is the same regardless of which of two USB2.0 PCI cards that I have I am using. The external hub that causes problems is seen with the USB1.x codes as Sep 28 23:12:34 chubby /kernel: uhub2: Cypress Semiconductor product 0x6560, class 9/0, rev 2.00/0.07, addr 2 Sep 28 23:12:34 chubby /kernel: uhub2: 4 ports with 4 removable, self powered And I can provide a patch I've used to usbdevs* to make this a bit more descriptive... Under NetBSD of last year, I could unplug and somewhat quickly re-plug the external hub after the ehci port was disabled, and after a few tries, I'd get it to be attached as a functioning USB1.x hub while ehci was snoozing or something. Of course, the ehci support was clearly marked as beta then. Oh heck, below I've attached an echidebug=3 dmesg, as it includes a few and for anyone who can make sense out of it, with a failed attempt at trying a random quirk. I'll see about downloading some USB utilities while I'm online to nab more useful info. Thanks, Barry Bouwsma uhub_explore: port 1 status 0x0501 0x0001 uhub_explore: status change hub=1 port=1 ehci after reset, status=0x1005 ehci port 1 reset, status = 0x1005 uhub speed is 3 usbd_new_device bus=0xc1728000 port=1 depth=1 speed=3 ehci_open: pipe=0xc1727180, addr=0, endpt=0 (1) ehci_alloc_sqtd: allocating chunk ehci_alloc_sqtd_chain: start len=8 ehci_check_intr: ex=0xc1729400 ehci_idone: ex=0xc1729400 ehci_idone: xfer=0xc1729400, pipe=0xc1727180 ready ehci_idone: len=8, actlen=8, status=0x40 ehci_idone: error, addr=0, endpt=0x00, status 0x40 QH(0xc174af80) at 0x00fedf80: link=0x00fedfc2 endp=0x80082000 addr=0x00 inact=0 endpt=0 eps=2 dtc=0 hrecl=0 mpl=0x8 ctl=0 nrl=8 endphub=0x4000 smask=0x00 cmask=0x00 huba=0x00 port=0 mult=1 curqtd=0x00f6ef80<> Overlay qTD: next=0x00
Re: Any workarounds for Verisign .com/.net highjacking?
[obligatory From: address is IPv6-only; to obtain IPv4-mailable address, remove hostname part. Even then no guarantee mail won't bounce -- I follow the list archives in my copious offline time] > > > In the meantime I'm trying to figure out if there's some > > >simple hack to disregard these wildcard A records, short of > > I have no idea of how well either of these work. Use your > > own discretion at applying them. > djbdns-1.05-ignoreip2.patch seems to work very well here, on three A stupid question, no less, since I see this being discussed here -- is it correct that the ISC BIND patch does not work with a nameserver that's set up as a forward-only box? I've applied the patch to a random BIND successfully, but I'm configured as forward-only for the domains I don't dish out, being on the unpleasant end of a PPP dial-in and trying to do my part to keep the root nameservers' load down. I nab the ISP-provided DNS addresses during the PPP handshake, configure them as forwarders (plus one or two backups) and restart named, but still I was able to resolve a made-up com domain to the Usual Address. This tells me I need to use the DNS machines of an ISP with Clue as static forwarder addresses, not those provided by ISP-of-the-day (and the last ISP seemed to give horribly broken machines anyway), if this reaches a point where I actually want to do something about these wildcards. Provided the ISP allows outgoing DNS queries too. Thanks, Barry Bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Machine wedges solid after one serial-port source-lineaddition...
[Drop hostname part of IPv6-only address above to obtain IPv4-capable e-mail, or just drop me from the recipients and I'll catch up from the archives] Terry Lambert writes: > I remember wakeup() being bad. Taking any time to do anything > at all more than just queueing data and going away is probably > bad. Then that's probably why it worked fine for some hours, then failed miserably. Thanks! > If it were my project, I'd mirror the values out to a status > structure that's only written at interrupt, and read and reset > at software interrupt, and then use the soft interrupt handler > to raise the signals/send the wakeup/whatever and then resets > the flags bits to zero via a call down that synchronizes like Maybe I'll turn back to this, when I'm older and wiser. But also, serial ports are a scarcity for me, so I'm wondering what else I can use to get precise timing information, to free up the serial port for something else. I wrote earlier (from an invalid address that probably most list readers rejected as spam) that I had a problem accessing the parallel port nACK as /dev/pps for the precise timing already present in the kernel source, and simultaneously as /dev/ppi for coarse timing via polling from which I'd determine the time that the PPS signal refers to. I tried adding printf()s to various parallel-port kernel code to see if there might be an interrupt I could jump onto for each transition of the nACK status line, but I suspect my lack of success with both swings of the signal has to do with not doing it right. So I'll ask a basic question here, forgive my ignorance: Can the lines of the parallel port be used to generate interrupts that I can use, in the same way that I've been able to use the four serial port status lines, or is this right out? And another question, I see three unused joystick connectors on the three sound cards in my machine, that are less likely to be used than the so-far- unused parallel port. Would it be possible to get interrupts from the sound card's joystick connector, when interfaced with suitable hardware to the radio clock output, that I would also theoretically be able to use? Or is this also something I'd need to poll the status of the switch(es), so only coarse precision would be possible? Please excuse my basic ignorance of fundamental PC hardware principles, and I'll welcome pointers to sources of more knowledge. Thanks, Barry Bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Kernel module problems/questions
[You know the drill: drop my hostname from the above IPv6-only address to get an IPv4-capable address; drop me entirely to avoid bounces and I'll catch the archives before your mail might reach me if it doesn't bounce] Some stupid kernel module questions. Kernel source from a few days ago, RELENG_4. First, why would USB-related modules whose source explicitly declares a DEPEND on the usb.ko module, fail to auto-load the usb module when they're kldload'ed? They fail with various undefined symbol errors, and there's no trace of any attempt to load the usb module. Second, why do some USB devices declare a module dependency on usb, while others (say, umass) do not? Ignoring that the usb auto-load fails for now. Third, if I load the usb.ko module by hand, everything works, except that I can't unload the usb.ko module. The error is `Device not configured.' To make this a question, I'll add: Why is this? Fourth, after boot, if I load, say, sbp.ko, it auto-loads firewire.ko, and attempts to unload firewire are denied so long as sbp.ko remains loaded. But if at boot, I've mangled the loader.conf to load sbp.ko, which then auto-loads firewire.ko, I *am* able to unload firewire.ko later by hand. Then unloading sbp.ko promptly results in a kernel panic. So, why can I unload modules auto-loaded at boot, when I'm denied unloading the same modules auto-loaded after boot? The desired behaviour would be *not* to be able to unload any auto-loaded modules, regardless. Fifth, I've run out of questions for now. Tune in again later. Thanks, Barry Bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB card overcurrent problems...
[Drop hostname part of IPv6-only address above to obtain IPv4-capable e-mail, or just drop me from the recipients and I'll catch up from the archives] Hello every last one of you, First, before I spout off in the wrong forum, is there a better or preferred location for USB-hardware-related questions like that which follows, akin to the firewire list? Okay, the question: I have two cards with USB2.0 awareness, used for their USB 1.x capability under FreeBSD 4.x. One of them, a UHCI card, works just fine, but the other one, an OHCI card, out-of-the-box exhibits problems. Chipset is identified in dmesg as NEC uPD 9210 USB controller. What happens, when I put it in a machine that it doesn't promptly wedge at boot or soon afterwards, is that the uhub/ohci USB codes from 4.5-RC up to 4.7 of last December (and now even recent 4.9-prerelease codes; haven't tried the NetBSD codes they originate from) result in the internal hub going dead (being disabled) when a bus-powered external USB2 hub device is connected to it -- the other card (UHCI) has no problems with repeated attach/detaches of this external hub. There is no obvious problem when connecting a self-powered device like that external hub with wall wart, or an external hard drive. Observation of the power indicator on the external hub shows that at time of attachment, it lights very briefly and then immediately goes out, and repeated unplug/re-plugging of the USB cable results in no further activity. Adding copious debuggery to the kernel indicates that at time of connecting the hub, the status of the internal port changes to unpowered and the change variable has the overcurrent bit set. Assuming that I don't have a truly wimpy piece of hardware (I haven't tried it under any non-*BSD OSen), it should durn well be able to power this hub, but perhaps the power-on surge of current into the filter capacitors is triggering this (temporary?) overcurrent indication. In fact, I was able to get the power indicator to come on and stay lit on the external hub by checking for an overcurrent condition in uhub.c, and then clearing the bit and re-applying power. Not 100% reliably, but later hacking (this evening) seems to have improved that, at the risk of ignoring a Real Overcurrent indication. What would be the proper changes to the code, after testing for such an overcurrent condition, in order to safely reapply power until such condition clears? Adding a delay somewhere? Limiting the number of times I try to re-apply power before bailing? (This last boot took some 5 or 6 tries until it came up okay in a tight loop) (There are comments in the source, imported from NetBSD, that some work- arounds for an overcurrent problem have been applied, but those did not seem to make any difference to me. Also, as noted, I haven't yet tried NetBSD from which these workarounds came, to see if there may be any not- yet-imported fixes that make my device work.) Also, I found that when applying the power within the test for overcurrent, that clearing the overcurrent change did not necessarily re-enable the interrupts, so I added that test to the routine that applies power, if that's safe to do. I'm probably not describing things well, but I'm positive my hacks aren't at all proper, so I'd rather learn the right way to handle this case before explaining where I run into problems. And, I'll have more USB-related questions later, so pointers to the proper place for those would be appreciated, if this list isn't it. Thanks, Barry Bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Machine wedges solid after one serial-port source-line addition...
[Ooops, looks like I sent out two mails to this list with the wrong address, so most of your anti-spam filters probably bitbucketed them where they belong. Fixed, I hope, with an IPv6-only address. But just reply to the list and drop me, I'll catch up from the archives... ] Terry Lambert wrote: > > Would anyone care to explain why the following simple patch could be > > enough to wedge my machine solid? (My original hack-patches without > You are calling printf() from a fast interrupt handler. I had a feeling it might be something like that. In truth, I had experienced a repeatable machine hang *without* the printf() that either happened immediately or after some hours -- I can't remember which now -- and tried to simplify my code down to something simpler using printf()... > If you need to communicate information to a console log (or > wherever), then you should enqueue the information on the > status change, and wake up some thread to do the actual Well, I only wanted the printf() to verify that that part of the code was being hit as expected, for debugging. My original code was calling wakeup(). You see, what I'm attempting to do, without knowing what I'm doing, is to implement the TIOCMIWAIT ioctl that apparently exists in Linux, to notify a userland program that there's been a status change on one or more of the modem status lines, and eliminate the need to poll the status line in question, cutting that program's cost to run by a factor of about 20 in the testing I did before the machine would wedge. I did all this offline, with no examples to follow, but now I have something to look at and see if I have the general idea. So I should probably shut up and study it. So, since a printf() is right out, is it safe for me (as a non- programmer, so forgive my ignorance of the basics) to simply use little more than a wakeup() in its place? Or does that, or the tsleep() corresponding, need some sort of careful handling to avoid the lockups I've experienced? Thanks, Barry Bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Conflict between use of /dev/pps and /dev/ppi?
[NOTE: IPv6-only e-mail above, so you probably want to drop me from
the recipients and just send to the list, which I'll read later, as
I'm not always online -- else remove JUST the hostname part to reveal
an IPv4-aware e-mail for me that may still timeout and bounce. Sorry.]
Hello hallowed hackers,
Be cautioned that this appears valid for RELENG_4 code way back from
December of 2002, and I'm pretty sure I haven't banged on either the
latest kernel source, or -CURRENT for that matter, as I'm still trying
to catch up.
I noticed that if I try to write a simple program to open /dev/ppi and
do things with it (that work, no less, sometimes), this fails so long
as ntpd has /dev/pps open (the parallel port nACK line is used for that).
Likewise, when I stop ntpd and run my program, then I'm unable to start
ntpd without it complaining about being unable to open /dev/pps.
Is there something I should be doing when opening /dev/ppi0 to free it
from /dev/pps0 ? I can open /dev/ppi0 simultaneously by several
progams though.
crw-rw 1 root wheel 82, 0 Jan 6 2002 /dev/ppi0
crw--- 1 root wheel 89, 0 Jul 3 14:45 /dev/pps0
The particular code I'm using looks like
fd = open("/dev/ppi0", O_RDONLY );
Or is this something within the kernel source that needs munging?
Apologies if it no longer (fails to) work this way, but I'm still
downloading and reviewing the last nine months of changes to the Internet.
Thanks,
Barry Bouwsma
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Machine wedges solid after one serial-port source-line addition...
[NOTE: IPv6-only e-mail above, so you probably want to drop me from
the recipients and just send to the list, which I'll read later, as
I'm not always online -- else remove just the hostname part to reveal
an IPv4-aware e-mail for me that may well timeout and bounce. Sorry.]
Hello gurus and the like;
In the process of trying to enhance my FreeBSD kernel's PPS and related
NTP timekeeping ability, I discovered I could reliably wedge my machine
(two different machines, actually) solid, such that I couldn't break into
the kernel debugger and the NumLock key wouldn't toggle the LED, and only
hitting the reset/power switch could return me to sanity.
Thinking it was a problem with the logic of my added code, I pruned things
and realized a single printf() line would cause my machine to hang within
a few minutes of boot; of course, with a PPS source (radio clock) connected
to the serial port to toggle the DCD line every second and trigger the
printf().
I'd been stuck with STABLE-09.Dec.2002 for a while, but the same thing
seems to happen as well with a RELENG_4 kernel as of a week or so ago --
at least with my hardware.
Would anyone care to explain why the following simple patch could be
enough to wedge my machine solid? (My original hack-patches without
any console printf() debuggery did the same thing within seconds, as
well...) All it does is notify the console whenever a serial port DCD
PPS signal transition is detected, as follows (patch against 4.foo; I
haven't tried this with 5.bar or later -- also, not a real patch as I've
included context and snipped my comments) :
--- /usr/local/system/src/sys/isa/sio.c Tue Sep 2 08:57:19 2003
+++ /usr/local/source-hacks/sys/isa/sio.c Tue Sep 2 18:55:31 2003
[...]
@@ -1999,21 +2015,56 @@
while (!com->gone) {
if (com->pps.ppsparam.mode & PPS_CAPTUREBOTH) {
modem_status = inb(com->modem_status_port);
if ((modem_status ^ com->last_modem_status) & MSR_DCD) {
tc = timecounter;
count = tc->tc_get_timecount(tc);
pps_event(&com->pps, tc, count,
(modem_status & MSR_DCD) ?
PPS_CAPTUREASSERT : PPS_CAPTURECLEAR);
+ printf("DCD status change\n");
}
}
line_status = inb(com->line_status_port);
[...]
I'd be grateful for enlightenment. I'd successfully added other lines
to record timestamps of other modem lines in addition to DCD (TIOCDCDTIMESTAMP)
but any attempt to do anything with code comparable to the above would
invariably result in a wedge within seconds to hours, from which keyboard
debugger entry was ineffective.
Also note that added debuggery reveals the solid wedge doesn't happen
anywhere in the suspect section of code that I sprinkled with printf()s,
but I haven't done enough debuggery to narrow down where it does or does
not happen.
I'm wondering if it's something really blindingly obvious that I should
be but am not aware of, or something I gotta work on to track down.
Thanks,
Barry Bouwsma
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Tuning up semaphores in kernel
On Sun, 13 Feb 19100, Andrey Novikov wrote: > > You probably want to increase either SEMMNI or SEMMNS. > > I've noticed that but why are they so "round"? Is there any corelation > between all these numbers? I don't want to break my kernel by guessing. > > > > options SEMMAP=31 > > > options SEMMNI=11 > > > options SEMMNS=61 > > > options SEMMNU=31 > > > options SEMMSL=61 > > > options SEMOPM=101 > > > options SEMUME=11 I ran into this problem when I was trying to compile and use a useful Linux audio application and I got the ENOSPC error. What I did was to look at the Linux kernel semaphore values, and, since I don't know what I'm doing, I just plugged them into the FreeBSD kernel config file like this... (The values given as examples in the config file are one more than the default, and do not work with that program either) #! options SEMMAP=31 #! options SEMMNI=11 #! options SEMMNS=61 #! options SEMMNU=31 #! options SEMMSL=61 #! options SEMOPM=101 #! options SEMUME=11 options SEMMAP=4096 options SEMMNI=128 options SEMMNS=4096 options SEMMNU=4096 options SEMMSL=32 options SEMOPM=32 options SEMUME=32 Of course, seeing that I do *not* know what I am doing, I haven't played with these values to find a happy medium between the FreeBSD defaults and those used by Linux, with which the audio program works. But I have had no problems with the kernel using these values. Now, I'd like to contribute the hacking and bugfixing I've done on the linux bplay program to someone for review and possible inclusion as a port, but if it doesn't work with the supplied kernel and generic config, I'm not sure what the correct action for me to take would be. Is there a good reason not to tweak the GENERIC/LINT FreeBSD kernel config SEM* definitions upwards to something that will allow the bplay to work out-of-the-box^H^H^Hport? Or should there just be a huge warning that appears when building bplay advising that certain kernel parameters may need tuning before the program has a chance of working, during the compilation/installation, or just somewhere in the ports files where it can be ignored? Otherwise, I can't see that bplay would be particularly useful as a port, but rather as additional software the user could optionally choose to hunt down and install... thanks, barry bouwsma, tele damnark internet -- *** This was posted with the express permission of *** ** ** HIS HIGHNESS KAAZMANN LORD AND MASTER OF USENET ** ** * We are simple servants of his will * To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
