Re: dump on mounted fs
Mark W. Krentel wrote: Dump still works on a mounted file system in Freebsd, right? That is, a write that completes before dump is started will be in the dump, even if the data is in memory? I don't mean writing to a file during the dump, that's a separate problem. I only recently learned that this doesn't work in Linux and I wanted to check that it's (still?) ok in Freebsd. Apparently, in the 2.4 Linux kernels, the buffer and page caches make it impossible for dump to always get the correct version of a file, even if there are no writes during the dump. It takes a umount before dump will see all of the changes (yuck). Anyone know about Solaris, IRIX, etc? Dump on a live FS is always risky. FreeBSD in 4.x and earlier will have up to about a 30 second delay before a write() makes it to physical disk. However, 5.x have snapshots where you can take a virtual snapshot of the file system device as it existed at the instant that you create it. You can then take a coherent dump that *will* be accurate. fsck uses snapshots in 5.x to do background fsck to reclaim lost resources. 5.0 should be released sometime this century. :-) Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Beep after shutdown
In message 002101c22d73$972ec970$[EMAIL PROTECTED], Sean Hamilton wrote: Greetings, The fact that FreeBSD does not beep after it finishes shutting down has costed me dozens of hours of reformatting inconsistent filesystems, and probably all sorts of little bits of data loss which I'm just unaware of. I've tried to hack this into the kernel myself, without much luck. The best I got it to do was start beeping but never end, since the timer related stuff had already been killed off. This wound up being more irritating than useful. Anybody clueful want to point me in the right direction? Following patch is Chiharu Shibata's patch for old 4-stable. The article on the patch is published in FreeBSD press(http://www.ux.mycom.co.jp/). http://plaza17.mbn.or.jp/~chi/myprog/FreeBSD/scbeep.diff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Beep after shutdown
* Sean Hamilton [EMAIL PROTECTED] [2002-07-17 02:23 -0700]: Greetings, The fact that FreeBSD does not beep after it finishes shutting down has costed me dozens of hours of reformatting inconsistent filesystems, and probably all sorts of little bits of data loss which I'm just unaware of. I've tried to hack this into the kernel myself, without much luck. The best I got it to do was start beeping but never end, since the timer related stuff had already been killed off. This wound up being more irritating than useful. Anybody clueful want to point me in the right direction? See http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/34820 Nicolas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Beep after shutdown
On Wed, Jul 17, 2002 at 02:45:29AM -0700, Sean Hamilton wrote: From: Takanori Watanabe [EMAIL PROTECTED] Anybody clueful want to point me in the right direction? Following patch is Chiharu Shibata's patch for old 4-stable. The article on the patch is published in FreeBSD press(http://www.ux.mycom.co.jp/). http://plaza17.mbn.or.jp/~chi/myprog/FreeBSD/scbeep.diff Unfortunately, no luck here. One of the devices I pull from the kernel is sc, which this depends on. The only bit from syscons used here is sc_tone(), which can quite litterally be pulled out of isa/isa_syscons.c with copy paste. -- Jonathan Mini [EMAIL PROTECTED] http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: NetBSD's uvm_pglistalloc equivalent?
On Tue, Jul 16, 2002 at 01:54:04PM -0700, Terry Lambert wrote: Stephane E. Potvin wrote: How often must this be allocated? How many of them are needed? If you only need a small set number of them, then they can be allocated very early on in the system lifetime, which means you should allocate them in machdep.c, with the rest of the memory overlay which attempts to make memory in protected mode look like physical RAM. I need one per process to hold the L1PT of the process' vm space. I will probably implement a cache to avoid creating/destroying repetitively but I don't think that it's reasonable to preallocate them as it will wire too much physical memory. So your answers are: o Allocated on every fork, freed on every exit o One per process I don't know how you have the ARM memory map laid out. One thing that FreeBSD does -- and why I suggested machdep.c -- is to map out page mappings, without providing backing store for those mappings until later. I guess I need a clarification on your original statement: table of the StrongARM processor is four pages. These pages need to be allocated contiguously. The questions are: o Contiguous in physical memory? yes/no o Contiguous in kernel virtual memory? yes/no o Mapped at all in user virtual memory? yes/no o Contiguous in user virtual memory? yes/no If it's just in kernel virtual memory, then the approach I suggested -- using machdep.c -- is the correct one. Ok, here are your answers: 1. Contiguous in physical memory? yes 2. Contiguous in kernel virtual memory? not mandatory but would be nice 3. Mapped at all in user virtual memory? no 4. Contiguous in user virtual memory? no This memory area is for the l1 table and is similar to the x86 l1 table, the only difference is the size of the table. On x86 processors, you have 1024 l1 entries (for a total of 4096 bytes or one physical page) per l1 table and each l2 table is 1024 entries (for a total of 4096 bytes or one physical page). In the ARM case, there is 4096 l1 entries (for a total of 16384 bytes or four physical pages) per l1 table and each l2 table is 256 entries (for a total of 1024 bytes or four l2 tables per physical page). The l1 table is mainly accessed by the processor as part of the virtual-physical translation and must be contiguous in physical memory for that reason. Steph To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dump on mounted fs
On Wed, Jul 17, 2002 at 01:29:53AM -0400, Mark W. Krentel wrote: I only recently learned that this doesn't work in Linux and I wanted to check that it's (still?) ok in Freebsd. Apparently, in the 2.4 Linux kernels, the buffer and page caches make it impossible for dump to always get the correct version of a file, even if there are no writes during the dump. It takes a umount before dump will see all of the changes (yuck). After upgrading some Redhat machines to 1GB of ram it became nearly impossible to dump any filesystem without dump going crazy trying to read nonexistant blocks (previously it had worked fine). Upgrading the version of the linux dump program which we use helped significantly and now we can back up the machines with amanda again. Though dumping a live filesystem isn't a very good idea in theory, the only problems we've ever encountered with dumping live FreeBSD filesystems are related to the last allocated inode changing between the start and the end of the dump. I think Ian Dowse has fixed some of these problems in restore. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: terminfo/termcap and cygwin
On Wed, 10 Jul 2002, Terry Lambert wrote: Alex Dupre wrote: In normal situation accessing to a FreeBSD 4.x machine from cygwin is not very pleasant: editing files is quite a pain, there are many terminal glitches like the cursor in the wrong position and garbage text. Sounds like Cygwin's terminal program fails to correctly implement the ANSI 3.64 standard. Could you use an ANSI 3.64 standard terminal, instead? Windows Telnet is standards compliant, for example. I'm not sure that cygwin does much in the way of the ANSI work. It's just a DOS box with bash in it, right? My work around for this problem was to use rxvt under cygwin which behaves almost exacly like xterm right down to cutting and pasting. Adrian -- [ [EMAIL PROTECTED] ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
ffs_blkfree: bad size panic
I got a panic on 4.5-STABLE with ffs_blkfree: bad size. I've searched through the mailing lists archives without finding anything. Can anyone help me trace down what the problem is? Thanks! david [EMAIL PROTECTED] - (davidp) gc02:/tmp$ uname -a FreeBSD gc02.nnrp.aus1.giganews.com 4.5-STABLE FreeBSD 4.5-STABLE #0: Wed May 15 13:44:34 CDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/NEWSBELL1800 i386 (davidp) gc02:/tmp$ sudo gdb -k /usr/tmp/kernel.0 /usr/tmp/vmcore.0 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-unknown-freebsd... (no debugging symbols found)... SMP 2 cpus IdlePTD at phsyical address 0x00324000 initial pcb at physical address 0x00293600 panicstr: ffs_blkfree: bad size panic messages: --- panic: ffs_blkfree: bad size mp_lock = 0001; cpuid = 0; lapic.id = 0100 boot() called on cpu#0 syncing disks... 240 71 23 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 giving up on 9 buffers Uptime: 4d0h40m46s xl0: reset didn't complete dumping to dev #twed/0x20001, offset 4194304 dump 2048 2047 2046 2045 2044 2043 2042 2041 2040 2039 2038 2037 2036 2035 2034 2033 2032 2031 2030 2029 2028 2027 2026 2025 2024 2023 2022 2021 2020 2019 2018 2017 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006 2005 2004 2003 2002 2001 2000 1999 1998 1997 1996 1995 1994 1993 1992 1991 1990 1989 1988 1987 1986 1985 1984 1983 1982 1981 1980 1979 1978 1977 1976 1975 1974 1973 1972 1971 1970 1969 1968 1967 1966 1965 1964 1963 1962 1961 1960 1959 1958 1957 1956 1955 1954 1953 1952 1951 1950 1949 1948 1947 1946 1945 1944 1943 1942 1941 1940 1939 1938 1937 1936 1935 1934 1933 1932 1931 1930 1929 1928 1927 1926 1925 1924 1923 1922 1921 1920 1919 1918 1917 1916 1915 1914 1913 1912 1911 1910 1909 1908 1907 1906 1905 1904 1903 1902 1901 1900 1899 1898 1897 1896 1895 1894 1893 1892 1891 1890 1889 1888 1887 1886 1885 1884 1883 1882 1881 1880 1879 1878 1877 1876 1875 1874 1873 1872 1871 1870 1869 1868 1867 1866 1865 1864 1863 1862 1861 1860 1859 1858 1857 1856 1855 1854 1853 1852 1851 1850 1849 1848 1847 1846 1845 1844 1843 1842 1841 1840 1839 1838 1837 1836 1835 1834 1833 1832 1831 1830 1829 1828 1827 1826 1825 1824 1823 1822 1821 1820 1819 1818 1817 1816 1815 1814 1813 1812 1811 1810 1809 1808 1807 1806 1805 1804 1803 1802 1801 1800 1799 1798 1797 1796 1795 1794 1793 1792 1791 1790 1789 1788 1787 1786 1785 1784 1783 1782 1781 1780 1779 1778 1777 1776 1775 1774 1773 1772 1771 1770 1769 1768 1767 1766 1765 1764 1763 1762 1761 1760 1759 1758 1757 1756 1755 1754 1753 1752 1751 1750 1749 1748 1747 1746 1745 1744 1743 1742 1741 1740 1739 1738 1737 1736 1735 1734 1733 1732 1731 1730 1729 1728 1727 1726 1725 1724 1723 1722 1721 1720 1719 1718 1717 1716 1715 1714 1713 1712 1711 1710 1709 1708 1707 1706 1705 1704 1703 1702 1701 1700 1699 1698 1697 1696 1695 1694 1693 1692 1691 1690 1689 1688 1687 1686 1685 1684 1683 1682 1681 1680 1679 1678 1677 1676 1675 1674 1673 1672 1671 1670 1669 1668 1667 1666 1665 1664 1663 1662 1661 1660 1659 1658 1657 1656 1655 1654 1653 1652 1651 1650 1649 1648 1647 1646 1645 1644 1643 1642 1641 1640 1639 1638 1637 1636 1635 1634 1633 1632 1631 1630 1629 1628 1627 1626 1625 1624 1623 1622 1621 1620 1619 1618 1617 1616 1615 1614 1613 1612 1611 1610 1609 1608 1607 1606 1605 1604 1603 1602 1601 1600 1599 1598 1597 1596 1595 1594 1593 1592 1591 1590 1589 1588 1587 1586 1585 1584 1583 1582 1581 1580 1579 1578 1577 1576 1575 1574 1573 1572 1571 1570 1569 1568 1567 1566 1565 1564 1563 1562 1561 1560 1559 1558 1557 1556 1555 1554 1553 1552 1551 1550 1549 1548 1547 1546 1545 1544 1543 1542 1541 1540 1539 1538 1537 1536 1535 1534 1533 1532 1531 1530 1529 1528 1527 1526 1525 1524 1523 1522 1521 1520 1519 1518 1517 1516 1515 1514 1513 1512 1511 1510 1509 1508 1507 1506 1505 1504 1503 1502 1501 1500 1499 1498 1497 1496 1495 1494 1493 1492 1491 1490 1489 1488 1487 1486 1485 1484 1483 1482 1481 1480 1479 1478 1477 1476 1475 1474 1473 1472 1471 1470 1469 1468 1467 1466 1465 1464 1463 1462 1461 1460 1459 1458 1457 1456 1455 1454 1453 1452 1451 1450 1449 1448 1447 1446 1445 1444 1443 1442 1441 1440 1439 1438 1437 1436 1435 1434 1433 1432 1431 1430 1429 1428 1427 1426 1425 1424 1423 1422 1421 1420 1419 1418 1417 1416 1415 1414 1413 1412 1411 1410 1409 1408 1407 1406 1405 1404 1403 1402 1401 1400 1399 1398 1397 1396 1395 1394 1393 1392 1391 1390 1389 1388 1387 1386 1385 1384 1383 1382 1381 1380 1379 1378 1377 1376 1375 1374 1373 1372 1371 1370 1369 1368 1367 1366 1365 1364 1363 1362 1361 1360 1359 1358 1357 1356 1355 1354 1353 1352 1351 1350 1349 1348 1347 1346 1345 1344 1343 1342 1341 1340 1339 1338 1337 1336 1335 1334 1333 1332 1331 1330 1329
Re: Beep after shutdown
Sean Hamilton wrote: The fact that FreeBSD does not beep after it finishes shutting down has costed me dozens of hours of reformatting inconsistent filesystems, and probably all sorts of little bits of data loss which I'm just unaware of. I've tried to hack this into the kernel myself, without much luck. The best I got it to do was start beeping but never end, since the timer related stuff had already been killed off. This wound up being more irritating than useful. Anybody clueful want to point me in the right direction? I agree. If it could beep after powering off, that would be useful, too. I ...er ...uh ...what the heck are you talking about? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: forum for discussing 'make release' issues
On Tue, Jul 16, 2002 at 11:09:15PM -0700, Terry Lambert wrote: Brian Reichert wrote: Can someone suggest the be FreeBSD mailing list wherein I could explore issues I'm having with trying to build a 4.6-STABLE release on a 4.5-RELEASE box? I don't know if this is a -hackers question, or a -stable question, or what. (I've looked at the list of lists majordomo knows about, and I don't see what would be a good fit...) Thanks for any input... I don't see anyone else answering, but... This configuration is not supported(tm). Darn. Posting the precise symptoms of the failure on -hackers is probably your best change for an answer; if anyone is doing this, it's there. Ok, thanks. Is this just to upgrade? No. What I had hoped to do was maintain a single build box, on which I could maintain the presence of several releases. I had explored trying to mirror various FTP archives, but I was finding difficult to gauge what I needed for diskspace, and how to selectively pare out what parts I didn't want or need. There doesn't seem to be a canonical description of how that gets laid out, WRT symlinks and whatnot... I found that it was easy enough to keep a mirror of the source tree, as I can extract whatever flavor of source I want. I had a fantasy that that would give me the stepping stone I needed. But, it seems not to be. Oh, well. It was only an experiment. :/ I _wish_ vmware would behave for me... It it works, great, but it's not a project goal. Noted. Thanks for the feedback... -- Terry -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
strace, PIOCWSTOP, NFS, and dynamically linked executables
Hi there... I seem to have some problems with running strace (A program that traces system calls, signals, and processes, in the ports: devel/strace) on FreeBSD. The problem is that the binary executable is not traced (it runs as a forked process of strace, but in the background of the shell). The only output of strace is something like: execve(..., [...], [/* ... vars */]PIOCWSTOP: Resource temporarily unavailable (What I substituted '...' for depends on the binary executed) I couldn't find yet what this PIOCWSTOP means exactly (I didn't find it in a search (grep) of all the /usr/include tree). The cases when the problem happens seem to be as follows: If I try to run strace on a statically linked binary (like most binaries in /bin), then: If the binary is on a remote NFS filesystem (FreeBSD 4.6 is the NFS server in this case too, even though it seems to be so too with NetApp's Filer servers), then first the problem happens, then after waiting about 5 seconds and running strace on the same binary again, the problem doesn't happen. If the binary is on a local filesystem (UFS in this case), then the problem does not happen. If I try to run strace on a dynamically linked binary (like most binaries in /usr and other installed programs), then: If the binary is on a remote NFS filesystem, then the problem always seems to happen. If the binary is on a local filesystem, then the problem first happens, and after about 5 seconds running strace on the same binary again, the problem doesn't happen. Or, to say: The problem always happens with a dynamically linked binary on NFS. The problem happens only the first time with a statically linked binary on NFS, or a dynamically linked binary on a local filesystem. The problem never happens with a statically linked binary on a local filesystem. I couldn't yet find the cause, and wonder (would be glad) if someone could help. Thank you, any help appreciated, -- Tom -- Tom Alsberg - certified insane, complete illiterate. e-mail: [EMAIL PROTECTED] Homepage: http://www.cs.huji.ac.il/~alsbergt/ * An idea is not responsible for the people who believe in it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: forum for discussing 'make release' issues
Brian Reichert wrote: What I had hoped to do was maintain a single build box, on which I could maintain the presence of several releases. I had explored trying to mirror various FTP archives, but I was finding difficult to gauge what I needed for diskspace, and how to selectively pare out what parts I didn't want or need. There doesn't seem to be a canonical description of how that gets laid out, WRT symlinks and whatnot... I found that it was easy enough to keep a mirror of the source tree, as I can extract whatever flavor of source I want. I had a fantasy that that would give me the stepping stone I needed. But, it seems not to be. Oh, well. It was only an experiment. :/ The normal way to do this, barring any gratuitous system call changes(*), is to take the DISC2 FS image, copy it into a directory, chroot into the directory, and do the build in the chroot'ed environment. -- Terry (*) *all* system call changes are, by definition, gratuitous; but everyone believes they can improve mount at some point in their naieve young lives, and so there are incompatabilities To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Counting the clock cycles
I was asking around in #freebsdhelp on EFNet what the equivalent of GetTickCount() in the Win32 API is in FreeBSD. I need a way to properly determine passage of time that is not affected if I change the system clock for example. The only way I'm aware that you can do that is by counting the number of clock cycles since system startup. What function does that in FreeBSD? I'd also like a Linux way if possible. (that is a way that will work across all UNIX clones). Thanks and please include my email in the reply directly since I'm not signed up to this mailing list. Thanks once again. Andrei Cojocaru [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
Andrei Cojocaru wrote: I was asking around in #freebsdhelp on EFNet what the equivalent of GetTickCount() in the Win32 API is in FreeBSD. I need a way to properly determine passage of time that is not affected if I change the system clock for example. The only way I'm aware that you can do that is by counting the number of clock cycles since system startup. What function does that in FreeBSD? I'd also like a Linux way if possible. (that is a way that will work across all UNIX clones). Thanks and please include my email in the reply directly since I'm not signed up to this mailing list. Use the Pentium Cycle Counter. Note that power management is going to make it inaccurate as a time base. Give up on the idea that you will have a wall time that is more accurate than the CMOS clock; after you've embraced that, you can learn to stop worrying and love Intel. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
* Andrei Cojocaru [EMAIL PROTECTED] [020717 12:02] wrote: I was asking around in #freebsdhelp on EFNet what the equivalent of GetTickCount() in the Win32 API is in FreeBSD. I need a way to properly determine passage of time that is not affected if I change the system clock for example. The only way I'm aware that you can do that is by counting the number of clock cycles since system startup. What function does that in FreeBSD? I'd also like a Linux way if possible. (that is a way that will work across all UNIX clones). Thanks and please include my email in the reply directly since I'm not signed up to this mailing list. Thanks once again. I don't see a platform independant way of doing this, sorry. Have a look at the source for w(1). http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/w/w.c Look at the function pr_header(), it uses SYSCTL to grab system uptime. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
FW: Reg: Claiming a device which is already claimed by another driver.
I had sent this mail already, but was not sure if it reached... as I had not registered previously... I would very much appreciate help on thi topic... Regards, -Vani. -Original Message- From: Sabapathi, Vanishree Sent: Wednesday, July 17, 2002 11:11 AM To: '[EMAIL PROTECTED]' Subject: Reg: Claiming a device which is already claimed by another driver. Hi, I am writing a charecter driver for a pci-ide controller, my problem is that atapci driver already claims my device. So in essence I need to detach the atapci driver from my device and claim it I have tried using the bus_generic_detach to detach the atapci driver, but now how will I be able to attach to it?? Regards, -Vanishree To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
rdtsc() will give you cycle counts since system boot. It reads a Pentium internal register which is incremented at every CPU internal clock cycle. Deepankar Andrei Cojocaru wrote: I was asking around in #freebsdhelp on EFNet what the equivalent of GetTickCount() in the Win32 API is in FreeBSD. I need a way to properly determine passage of time that is not affected if I change the system clock for example. The only way I'm aware that you can do that is by counting the number of clock cycles since system startup. What function does that in FreeBSD? I'd also like a Linux way if possible. (that is a way that will work across all UNIX clones). Thanks and please include my email in the reply directly since I'm not signed up to this mailing list. Thanks once again. Andrei Cojocaru [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
In message 00d501c22dc4$57d08b00$0200a8c0@twothousand, Andrei Cojocaru writ es: I was asking around in #freebsdhelp on EFNet what the equivalent of GetTickCount() in the Win32 API is in FreeBSD. I need a way to properly determine passage of time that is not affected if I change the system clock for example. The only way I'm aware that you can do that is by counting the number of clock cycles since system startup. What function does that in FreeBSD? I'd also like a Linux way if possible. (that is a way that will work across all UNIX clones). Thanks and please include my email in the reply directly since I'm not signed up to this mailing list. Thanks once again. How about time(3)? -- Cheers, Phone: 250-387-8437 Cy SchubertFax: 250-387-5766 Team Leader, Sun/Alpha Team Email: [EMAIL PROTECTED] Open Systems Group, CITS Ministry of Management Services Province of BC FreeBSD UNIX: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
doesn't fit my criteria since it changes, bah I'll just use gettimeofday since it's a portable API and hope the computers I run it on don't change their blocks by too much... - Original Message - From: Cy Schubert - CITS Open Systems Group [EMAIL PROTECTED] To: Andrei Cojocaru [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, July 17, 2002 13:43 Subject: Re: Counting the clock cycles In message 00d501c22dc4$57d08b00$0200a8c0@twothousand, Andrei Cojocaru writ es: I was asking around in #freebsdhelp on EFNet what the equivalent of GetTickCount() in the Win32 API is in FreeBSD. I need a way to properly determine passage of time that is not affected if I change the system clock for example. The only way I'm aware that you can do that is by counting the number of clock cycles since system startup. What function does that in FreeBSD? I'd also like a Linux way if possible. (that is a way that will work across all UNIX clones). Thanks and please include my email in the reply directly since I'm not signed up to this mailing list. Thanks once again. How about time(3)? -- Cheers, Phone: 250-387-8437 Cy SchubertFax: 250-387-5766 Team Leader, Sun/Alpha Team Email: [EMAIL PROTECTED] Open Systems Group, CITS Ministry of Management Services Province of BC FreeBSD UNIX: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
Andrei Cojocaru wrote: doesn't fit my criteria since it changes, bah I'll just use gettimeofday since it's a portable API and hope the computers I run it on don't change their blocks by too much... If you're really worried about it, get a GPS device that can provide you with a PPS signal for use with ntpd. Then I'd say you could safely rely on the computer's clock being accurate. From: Cy Schubert - CITS Open Systems Group [EMAIL PROTECTED] In message 00d501c22dc4$57d08b00$0200a8c0@twothousand, Andrei Cojocaru writes: I was asking around in #freebsdhelp on EFNet what the equivalent of GetTickCount() in the Win32 API is in FreeBSD. I need a way to properly determine passage of time that is not affected if I change the system clock for example. The only way I'm aware that you can do that is by counting the number of clock cycles since system startup. What function does that in FreeBSD? I'd also like a Linux way if possible. (that is a way that will work across all UNIX clones). Thanks and please include my email in the reply directly since I'm not signed up to this mailing list. Thanks once again. How about time(3)? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
I am already synchronizing using xntp, that's not the problem. The problem is by some weird way the clock got out of sync by about 1hr during daylight switch on one of the computers I run, and I need a reliable way to get passage of time (I don't need date/time, just the passage of it) for different internal operations in the program. - Original Message - From: Darren Pilgrim [EMAIL PROTECTED] To: Andrei Cojocaru [EMAIL PROTECTED] Cc: Cy Schubert - CITS Open Systems Group [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, July 17, 2002 14:25 Subject: Re: Counting the clock cycles Andrei Cojocaru wrote: doesn't fit my criteria since it changes, bah I'll just use gettimeofday since it's a portable API and hope the computers I run it on don't change their blocks by too much... If you're really worried about it, get a GPS device that can provide you with a PPS signal for use with ntpd. Then I'd say you could safely rely on the computer's clock being accurate. From: Cy Schubert - CITS Open Systems Group [EMAIL PROTECTED] In message 00d501c22dc4$57d08b00$0200a8c0@twothousand, Andrei Cojocaru writes: I was asking around in #freebsdhelp on EFNet what the equivalent of GetTickCount() in the Win32 API is in FreeBSD. I need a way to properly determine passage of time that is not affected if I change the system clock for example. The only way I'm aware that you can do that is by counting the number of clock cycles since system startup. What function does that in FreeBSD? I'd also like a Linux way if possible. (that is a way that will work across all UNIX clones). Thanks and please include my email in the reply directly since I'm not signed up to this mailing list. Thanks once again. How about time(3)? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
depending on the acuracy needed use the uptime.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
In message 005f01c22dd1$7be7d180$0300a8c0@fivehundred, Andrei Cojocaru writ es: I am already synchronizing using xntp, that's not the problem. The problem is by some weird way the clock got out of sync by about 1hr during daylight switch on one of the computers I run, and I need a reliable way to get passage of time (I don't need date/time, just the passage of it) for different internal operations in the program. Use UTC time, it has no daylight savings problems. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
yes but how do you get the uptime? - Original Message - From: Julian Elischer [EMAIL PROTECTED] To: Darren Pilgrim [EMAIL PROTECTED] Cc: Andrei Cojocaru [EMAIL PROTECTED]; Cy Schubert - CITS Open Systems Group [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, July 17, 2002 14:50 Subject: Re: Counting the clock cycles depending on the acuracy needed use the uptime.. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
I need a way to properly determine passage of time that is not affected if I change the system clock for example. how about using setitimer(2) - ITIMER_REAL? since it appears(?) on almost all unix(-like) platforms this expires based only on callout (or jiffies) ticks countdown, and settimeofday(2) never seems to bother adjusting callout queues. kenji To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
problem getting multiple bktr devices talking through a single HB1 bridge
Hello everyone,
I've got a problem I'm hoping that someone out there can help
solve (surprise, surprise!).
I've got a bunch of capture cards that use 4 Conexant BT878A
capture chips connected through a single HiNT HB1 bridge chip.
When I've tried connecting multiple BT878's directly to the main
PCI bus, the system runs just fine with all slots filled. I've
tried the same thing using the multi-chip capture cards but have
had much less success - the system will run for a period of
time, then spontaneously reboot without warning. It usually
does not leave a kernel dump.
So far, Ive got:
1) Multiple independent BT878A's work fine (devices bktr0
through bktr7 usually, although I've also tweaked things to test
with up to 20 bktr devices)
2) Running only one BT878A per HiNT HB1 bridge works just fine
3) Running multiple BT878A's per HB1 causes reboots
The test software I've been using to try and figure this out is
fxtv. I'll be using some of my own streaming code in the end,
but this provides a nice open source verification of the problem
(thus assuring me that it's not something I did wrong). The
more simultaneous session started ('cause the bktr driver
doesn't automatically disable capture when a connected client
process closes), the quicker the system crashes.
I've talked to Roger Hardiman, who maintains the bktr driver,
who suggested that perhaps some special setup info had to be
given to bridge chip (like what is done to support the newer
Matrox Meteor cards). The only affect I've been able to have by
doing this has been to set the primary and secondary latency
higher - this results in somewhat longer times between reboots.
I've talked to HiNT who thinks this is likely an issue with the
BT878A driver on FreeBSD. I've been trying to get in touch with
Conexant, but the closest I've been able to get is phone tag
with a local field engineer.
Can anyone provide any other suggestions? I can provide specs
sheets for all chips involved, kernel configuration info, run
tests, etc. if it will help. I's also be willing to compensate
someone some for their efforts should we manage to find an
answer.
Thanks, in advance,
Rob McKeever
Vancouver, BC Canada
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
ezmlm response
Hi! I'm managing the PowerList mailing list. I'm sorry, I've been unable to carry out your request, since the address [EMAIL PROTECTED] was not on the PowerList mailing list when I received your request and is not a subscriber of this list. If you unsubscribe, but continue to receive mail, you're subscribed under a different address than the one you currently use. The message will have a ``List-Unsubscribe:'' header, you can send a message to the address in that header. It contains the subscription already coded into it. If this still doesn't work, I'm sorry to say that I can't help you. Please FORWARD a list message together with a note about what you're trying to achieve and a list of addresses that you might be subscribed under to my owner: [EMAIL PROTECTED] who will take care of it. My owner is a little bit slower than I am, so please be patient. --- Enclosed is a copy of the request I received. Return-Path: [EMAIL PROTECTED] Received: (qmail 16652 invoked from network); 17 Jul 2002 06:38:42 - Received: from english-breakfast.cloud9.net (168.100.1.9) by 0 with SMTP; 17 Jul 2002 06:38:42 - Received: from irish-breakfast.cloud9.net (irish-breakfast.cloud9.net [168.100.1.6]) by english-breakfast.cloud9.net (Postfix) with ESMTP id BC73D26C48 for [EMAIL PROTECTED]; Mon, 15 Jul 2002 07:35:54 -0400 (EDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] X-Originating-Ip: 198.8.1.14 MIME-Version: 1.0 Reply-To: [EMAIL PROTECTED] Date: Mon, 15 Jul 2002 7:35:54 EDT X-Mailer: EMUmail 5.1 Subject: (No subject) X-Http_host: www.mail.cloud9.net X-Webmail-User: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
In message: [EMAIL PROTECTED] Darren Pilgrim [EMAIL PROTECTED] writes: : If you're really worried about it, get a GPS device that can provide : you with a PPS signal for use with ntpd. Then I'd say you could safely : rely on the computer's clock being accurate. If you are lucky enough to find accuracy in the 10s of us close enough. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message 005f01c22dd1$7be7d180$0300a8c0@fivehundred, Andrei Cojocaru writ : es: : I am already synchronizing using xntp, that's not the problem. The : problem is by some weird way the clock got out of sync by about 1hr : during daylight switch on one of the computers I run, and I need a : reliable way to get passage of time (I don't need date/time, just : the passage of it) for different internal operations in the program. : : Use UTC time, it has no daylight savings problems. Just stupid leap-seconds :-( Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Darren Pilgrim [EMAIL PROTECTED] writes: : If you're really worried about it, get a GPS device that can provide : you with a PPS signal for use with ntpd. Then I'd say you could safely : rely on the computer's clock being accurate. If you are lucky enough to find accuracy in the 10s of us close enough. I don't quite understand what you're saying here. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
In message: [EMAIL PROTECTED] Darren Pilgrim [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : : In message: [EMAIL PROTECTED] : Darren Pilgrim [EMAIL PROTECTED] writes: : : If you're really worried about it, get a GPS device that can provide : : you with a PPS signal for use with ntpd. Then I'd say you could safely : : rely on the computer's clock being accurate. : : If you are lucky enough to find accuracy in the 10s of us close enough. : : I don't quite understand what you're saying here. I'm saying that ntp steers the system clock only +- 40-70us (eg a few 10's of us) in the best client situation on a LAN. Reference clocks can get the system time deviation down to a few microseconds (on the order of 2-5us). phk claims to have gotten better with custom clock hardware... of course these numbers are from FreeBSD 4.3 and the ntp nano-kernel in the kernel has gotten a little better since then. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Counting the clock cycles
In message [EMAIL PROTECTED], M. Warner Losh writes: In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message 005f01c22dd1$7be7d180$0300a8c0@fivehundred, Andrei Cojocaru writ : es: : I am already synchronizing using xntp, that's not the problem. The : problem is by some weird way the clock got out of sync by about 1hr : during daylight switch on one of the computers I run, and I need a : reliable way to get passage of time (I don't need date/time, just : the passage of it) for different internal operations in the program. : : Use UTC time, it has no daylight savings problems. Just stupid leap-seconds :-( Well, I have already sent comments to the latest IERS questionaire telling them how ugly we think those are. Unless we want to deal properly with leapseconds and implement TAI, we have no choice in that matter. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
