Re: [Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...
Hello, Igor. You wrote 29 апреля 2013 г., 6:06:35: IM Once I narrowed down the problem (acpi uart), I stumbled across IM http://forums.freebsd.org/archive/index.php/t-15740.html IM Preventing the ACPI driver from seizing control of UART seems to work IM and cuau0 is now functional. Hm. I need to try this on my D2500CC, where I have 4 UARTs and none of them works. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...
please file a PR! Adrian On 28 April 2013 19:06, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: Once I narrowed down the problem (acpi uart), I stumbled across http://forums.freebsd.org/archive/index.php/t-15740.html Preventing the ACPI driver from seizing control of UART seems to work and cuau0 is now functional. Thanks to all, -- Igor M. :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
SpaceDart.com Offers Pay Per Click Campaign!
Greetings, SpaceDart.com is India’s real estate destination. Users can find and post properties as well as search to buy/sale/rent, both new or resale Flats,homes and villas. Affiliates can leverage SpaceDart.com’s presence as the premiere real estate company in India to grow this affiliate program. Here are the program specifics: SpaceDart.com provides tracking links that you can put on your site. Visitors click on the links and search for property on SpaceDart.com. We happily pay our affiliates for the traffic referred to us. Sign up Today! http://mail.emobimail.com/link.php?M=5465001N=550L=271F=T If your site reaches a Indian audience and you are promoting other real estate affiliate programs then you need to be promoting SpaceDart.com. Feel free to contact us if you have questions or if you need anything, we are here to help. Thanks! Uday Bhaskar Affiliate Manager www.spacedart.com e-mail: udayabhas...@spacedart.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...
Hello Igor On 29.04.2013 04:06, Igor Mozolevsky wrote: Once I narrowed down the problem (acpi uart), I stumbled across http://forums.freebsd.org/archive/index.php/t-15740.html Preventing the ACPI driver from seizing control of UART seems to work and cuau0 is now functional. I have a similar problem, but with a DCF77 Gude mouseCLOCK (connected to on-board COM2), which was working just fine on this system when running FreeBSD 7.4 (sio). But since I have upgraded to FreeBSD 9.1 (uart), ntpd does only get partial data from the mouseCLOCK. So today I tried with the above hint, but this did not help. Without any modification (and also with disabled acpi for the uart) I do see messages like this (sorry for the line wrapping): Apr 29 16:31:39 superman ntpd[1737]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 0 bits Apr 29 16:31:39 superman ntpd[1737]: PARSE receiver #0: interval for following error message class is at least 00:01:00 Apr 29 16:31:39 superman ntpd[1737]: PARSE receiver #0: FAILED TIMECODE: \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00... (check receiver configuration / wiring) Apr 29 16:31:41 superman ntpd[1737]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 1 bits Apr 29 16:31:43 superman ntpd[1737]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 2 bits Apr 29 16:31:52 superman ntpd[1737]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 11 bits [...] Apr 29 16:33:01 superman ntpd[1737]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 4 bits Apr 29 16:33:08 superman ntpd[1737]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 8 bits Apr 29 16:33:16 superman ntpd[1737]: PARSE receiver #0: no data from device within poll interval (check receiver / wiring) When I also add the following line to /boot/device.hints it does improve a little bit and ntpd sees more bits, but still not enough to be working (log entries below): hint.uart.1.flags=0x100 Apr 29 16:46:06 superman ntpd[1737]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 0 bits Apr 29 16:46:06 superman ntpd[1737]: PARSE receiver #0: interval for following error message class is at least 00:01:00 Apr 29 16:46:06 superman ntpd[1737]: PARSE receiver #0: FAILED TIMECODE: \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00... (check receiver configuration / wiring) Apr 29 16:46:21 superman ntpd[1737]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 1 bits Apr 29 16:46:53 superman ntpd[1737]: PARSE receiver #0: interval for following error message class is at least 00:01:00 Apr 29 16:46:53 superman ntpd[1737]: PARSE receiver #0: no data from device within poll interval (check receiver / wiring) Apr 29 16:47:00 superman ntpd[1737]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 45 bits Apr 29 16:47:41 superman ntpd[1737]: parse: convert_rawdcf: parity check FAILED for --##---RADMLS-24--24p-24---P1--81--2412-81-2481--8P_? Apr 29 16:47:41 superman ntpd[1737]: PARSE receiver #0: 2 messages where suppressed, error condition class persists for 00:01:35 Apr 29 16:47:41 superman ntpd[1737]: PARSE receiver #0: FAILED TIMECODE: --##---RADMLS-24--24p-24---P1--81--2412-81-2481--8P_ (check receiver configuration / wiring) Apr 29 16:47:58 superman ntpd[1737]: PARSE receiver #0: no data from device within poll interval (check receiver / wiring) Apr 29 16:48:00 superman ntpd[1737]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 23 bits Apr 29 16:48:45 superman ntpd[1737]: parse: convert_rawdcf: parity check FAILED for --##---##-#-AD--S1--8124p-24--2P12-8121-4-2481--48-248P__ Apr 29 16:48:45 superman ntpd[1737]: PARSE receiver #0: 1 message was suppressed, error condition class persists for 00:02:39 Apr 29 16:48:45 superman ntpd[1737]: PARSE receiver #0: FAILED TIMECODE: --##---##-#-AD--S1--8124p-24--2P12-8121-4-2481--48-248P_ (check receiver configuration / wiring) Apr 29 16:49:00 superman ntpd[1737]: parse: convert_rawdcf: INCOMPLETE DATA - time code only has 18 bits Apr 29 16:49:44 superman ntpd[1737]: parse: convert_rawdcf: parity check FAILED for --#---MLs-24--24p---81-P1--8121-41-4811--81-48P?_ Apr 29 16:50:00 superman ntpd[1737]: parse: convert_rawdcf:
Re: [Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...
Hm, can you double check the port configuration? is it somehow getting the number of stop bits wrong or something? What about flow control? Are there overflow/underflow counters with the uart driver? I wonder if you're hitting issues there. adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...
Hello Adrian On 29.04.2013 19:51, Adrian Chadd wrote: Hm, can you double check the port configuration? is it somehow getting the number of stop bits wrong or something? What about flow control? I did not change anything, I even did not set anything special back with FreeBSD 7.4 during the setup of ntpd for the DCF77 mouseCLOCK. Here the settings of the serial (sorry for the line wrapping): root@superman:~ # stty -a -f /dev/refclock-0 speed 50 baud; 0 rows; 0 columns; lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo -extproc iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -ignbrk -brkint -inpck ignpar -parmrk oflags: -opost -onlcr -ocrnl tab0 -onocr -onlret cflags: cread cs8 -parenb -parodd -hupcl clocal -cstopb -crtscts -dsrflow -dtrflow -mdmbuf cchars: discard = undef; dsusp = undef; eof = undef; eol = undef; eol2 = undef; erase = undef; erase2 = undef; intr = undef; kill = undef; lnext = undef; min = 1; quit = undef; reprint = undef; start = undef; status = undef; stop = undef; susp = undef; time = 0; werase = undef; root@superman:~ # ls -l /dev/refclock-0 lrwxr-xr-x 1 root wheel 5 Apr 29 17:05 /dev/refclock-0@ - cuau1 root@superman:~ # Are there overflow/underflow counters with the uart driver? I wonder if you're hitting issues there. Is there anything I can do to debug? PS: No need to use reply all, reply only to the list is perfect, as I do filter e-mails based on the List-Id header line. bye Fabian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...
On 29 April 2013 11:00, Fabian Wenk fab...@wenks.ch wrote: Is there anything I can do to debug? I don't know. Unfortunately there's no active uart maintainer. That's why I was wondering if someone already knew about whether uart kept underflow/overflow statistics. Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...
On Mon, Apr 29, 2013 at 11:14:38AM -0700, Adrian Chadd wrote: On 29 April 2013 11:00, Fabian Wenk fab...@wenks.ch wrote: Is there anything I can do to debug? I don't know. Unfortunately there's no active uart maintainer. Eh? I was under the impression Marcel Moolenaar mar...@freebsd.org was active and maintaining this code. He has alternate Email addresses if that one does not work. That's why I was wondering if someone already knew about whether uart kept underflow/overflow statistics. Based on what I can tell, it does not. It has the capability of detecting overruns, but there does not appear to be (based on a quick skim) any counter capability. I should note that this has been a long-standing issue with FreeBSD, re: whether ACPI or ISA should have control over serial ports (uart(4)). The road goes both ways -- what works for some people doesn't for others. If a person is having to throw in ACPI tweaks/overrides/hints to get this to work, someone should probably involve freebsd-acpi. I'll also point out that since the ACPI tables come from the BIOS/UEFI, it does not surprise people that BIOS maintainers often screw things up as well. Nothing on PC architecture is simple any more. Nothing. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [Solved] [UART] GPS 18-5Hz LVC and COM1 silence, OK on Linux though...
Hello Jeremy On 29.04.2013 20:25, Jeremy Chadwick wrote: Nothing on PC architecture is simple any more. Nothing. I my case it was an upgrade from FreeBSD 7.4 to FreeBSD 9.1 without any change on the hardware. The only difference is the serial driver which changed from sio to uart. So I guess it is related to differences between sio and uart. PS: No need to use reply all, reply only to the list is perfect, as I do filter e-mails based on the List-Id header line. bye Fabian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
/usr/src over NFS: buildworld fail
Hi everyone! /usr/src imported via NFS make buildworld is always fails in the same place with error: make: result too large. Localy its works fine Does anybody know how to fix it? i386 FreeBSD 9-STABLE (r250044) Best regards, Andrew Romanenko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /usr/src over NFS: buildworld fail
Andrew Romanenko melan...@gmail.com writes: /usr/src imported via NFS make buildworld is always fails in the same place with error: make: result too large. Localy its works fine Does anybody know how to fix it? I've been doing that for years, with no problems. If you NFS-mount the src tree, do you do it read-only? When the src is reached by NFS, where is the obj tree (usually /usr/obj), and how is *it* accessed? Does it have enough space? Also, I'd generally recommend mounting the src read-only. i386 FreeBSD 9-STABLE (r250044) Good luck. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /usr/src over NFS: buildworld fail
On Mon, Apr 29, 2013 at 09:42:06PM +0300, Andrew Romanenko wrote:
Hi everyone!
/usr/src imported via NFS
make buildworld is always fails in the same place with error: make: result
too large.
Localy its works fine
Does anybody know how to fix it?
i386 FreeBSD 9-STABLE (r250044)
Actual output would have been more useful than a paraphrased response.
The same goes for actual NFS server and client details (OS, backing
filesystems, make.conf, src.conf, rc.conf, loader.conf, sysctl.conf,
etc.).
Result too large is error ERANGE (see /usr/include/errno.h), errno 34,
assuming that it has a capital R (Result, not result).
I see no cases in src/usr.bin/make/* where ERANGE or errno 34 is
returned directly.
I do not believe NFS returns ERANGE either.
There may be cases where the backing filesystem (i.e. the filesystem
used on the NFS server) could return ERANGE. I know ZFS does, but only
in one specific case (only if the compression property is enabled).
I do see some other cases in the ZFS code pertaining to UTF-8 support
that can return ERANGE but did not look at what those cases may be.
You may end up having to do the following:
rm -fr /usr/obj/*
cd /usr/src
ktrace -t+ -f /tmp/ktrace.out make buildworld
{wait until the failure}
cd /tmp
kdump
Then look to see what syscall/operation returns this. You may have to
put this file up on the web somewhere (it should gzip quite well), and
be aware there may be personal information in it (environment variables,
contents of files, etc.), so choose wisely.
Good luck.
--
| Jeremy Chadwick j...@koitsu.org |
| UNIX Systems Administratorhttp://jdc.koitsu.org/ |
| Mountain View, CA, US|
| Making life hard for others since 1977. PGP 4BD6C0CB |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
