Re: syscons: incorrect behavior of blinking cursor
On Thu, Feb 10, 2000 at 11:11:53AM +0900, Kazutaka YOKOTA wrote:
On Wed, Feb 09, 2000 at 08:35:07PM +0200, Ruslan Ermilov wrote:
Hi!
1. Set cursor "blinking" or "destructive" (SC_BLINK_CURSOR)
2. Press Scroll Lock (cursor will go away)
3. Switch to another vtyX
4. Switch to the original vty, where you pressed Scroll Lock
5. Watch the cursor will appear at the same position as it was on vtyX.
The following patch fixes the problem.
Thank you for the report and patch.
While your patch seems to work, it looks to me it's slightly over-kill
for this problem; we shouldn't need to call sc_remove_cursor_image()
every time the screen is refreshed in scrn_upcate().
Because this problem is caused by exchange_scr() not removing the text
cursor when changing to the vty where the cursor is not currently
shown, we had better fix exchange_scr().
The attached patch is simpler and fixes the problem. I verified it
works here. Please test. Thank you.
Tested, it works, but while I was testing, I've found yet another glitch.
Please try an attached cursor.sh with and without an attached patch (p).
On my box, the cursor.sh causes "normal" cursor to be displayed several
times, and an attached patch fixes the problem.
Thanks,
--
Ruslan Ermilov Sysadmin and DBA of the
[EMAIL PROTECTED]United Commercial Bank,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.247.647Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
cursor.sh
--- scterm-sc.c~Wed Feb 9 17:37:58 2000
+++ scterm-sc.c Thu Feb 10 10:22:58 2000
@@ -530,7 +530,6 @@
if (!ISGRAPHSC(sc-cur_scp)) {
i = spltty();
sc_set_cursor_image(sc-cur_scp);
- sc_draw_cursor_image(sc-cur_scp);
splx(i);
}
break;
--- syscons.c~ Sun Feb 6 17:28:00 2000
+++ syscons.c Thu Feb 10 10:26:41 2000
@@ -735,7 +735,6 @@
if (!ISGRAPHSC(sc-cur_scp)) {
s = spltty();
sc_set_cursor_image(sc-cur_scp);
- sc_draw_cursor_image(sc-cur_scp);
splx(s);
}
return 0;
@@ -2335,6 +2334,8 @@
/* save the current state of video and keyboard */
sc_move_cursor(sc-old_scp, sc-old_scp-xpos, sc-old_scp-ypos);
+if (!ISGRAPHSC(sc-old_scp))
+ sc_remove_cursor_image(sc-old_scp);
if (sc-old_scp-kbd_mode == K_XLATE)
save_kbd_state(sc-old_scp);
Re: [usb-bsd] Re: uhci - attach fails on HP Omnibook
for some reason, the uhci driver fails to attach on my HP Omnibook
2100.
The probe is ok and detects the 82371AB/EB (PIIX4) USB controller.
But then, the uhci_pci_attach fails trying to map the i/o port.
("io_res = bus_alloc_resource(self, SYS_RES_IOPORT" returns an
error.)
It's a -CURRENT from yesterday with USB-patch-2208 installed
found- vendor=0x8086, dev=0x7112, revid=0x01
class=0c-03-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=d, irq=10
This entry (the one for you Intel UHCI controller) misses a 'map[20]
...' line. Just to be sure, this is not a cutpaste error?
The only reasonable explanation I could find is that pci_memen(cfg)
determines that the memory is not enabled by the BIOS and rejects the
mapping of the memory. I presume you did switch on USB support in the
BIOS?
found- vendor=0x8086, dev=0x7113, revid=0x02
class=06-80-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
map[90]: type 1, range 32, base 2180, size 4
uhci0: Intel 82371AB/EB (PIIX4) USB controller irq 10 at device 7.2 on pci0
uhci0: could not map ports
device_probe_and_attach: uhci0 attach returned 6
Nick
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: USB problems.
If this with usb support compiled into the kernel, try the following
patch:
--- usb_subr.c.orig Wed Feb 9 23:27:31 2000
+++ usb_subr.c Wed Feb 9 21:16:54 2000
@@ -302,7 +302,7 @@
u_int ms;
{
/* Wait at least two clock ticks so we know the time has
passed. */
- if (bus-use_polling)
+ if (bus-use_polling || cold)
delay((ms+1) * 1000);
else
tsleep(ms, PRIBIO, "usbdly", (ms*hz+999)/1000 + 1);
If it is loaded as a module, could you send me the relevant parts of the
dmesg of a verbose boot (type 'set boot_verbose' at the loader prompt)
with or without the USB support compiled in. Also could you try to load
the USB module at the loader prompt and tell me whether that works?
Cheers.
Nick
On Mon, 7 Feb 2000, David Gilbert wrote:
Since my new Viewsonic monitor included a USB hub and cable, I decided
to connect them. Under 3.3-STABLE (somewhere, forget when) this
worked and usbdev -v would show that the extra 4 port hub was
connected. After upgrading to 4.0-CURRENT, I got:
uhci0: VIA 83C572 USB controller port 0xcc00-0xcc1f irq 10 at device
4.2 on pc
i0
usb0: VIA 83C572 USB controller on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub0: device problem, disabling port 2
uhci1: VIA 83C572 USB controller port 0xd000-0xd01f irq 10 at device
4.3 on pc
i0
usb1: VIA 83C572 USB controller on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
... note the "device problem, disabling port 2" --- that message will
follow whatever I plug the monitors USB hub into.
Dave.
--
|David Gilbert, Velocet Communications. | Two things can only be |
|Mail: [EMAIL PROTECTED] | equal if and only if they |
|http://www.velocet.net/~dgilbert | are precisely opposite. |
=GLO
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Function Request
: The first is mremap(). : : What does this function do? Is the function used by freely available : software, if so can you give some examples. : :http://www.freebsd.org/cgi/man.cgi?query=mremapapropos=0sektion=0manpath=Red+Hat+Linux%2Fi386+5.2format=html mremap() is idiotic and sounds like a cop-out for a badly designed memory allocator. There are much better ways to manage memory depending on what you want to do. For one thing, don't forget that it is perfectly legal to mmap() a larger size then the underlying file - you just can't access the space beyond the file EOF until you have extended the file by other means. It is also perfectly legal to mmap() a large chunk of anonymous memory, like a megabyte, and grow into it. No memory is actually allocated until you touch it. Generally speaking, there are very limited uses to being able to remap anonymous (not file-backed) memory, and remapping file-backed memory is trivial (just an munmap()/mmap() pair). -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
At 09:58 PM 2/9/00 +0100, Kai Voigt wrote: Hello, I'm just doing a cvsup update of my system and -as many times before- I realize that /usr/ports/ takes a lot of time and also disk space to sync. # du -sk /usr/ports 71118 /usr/ports Is that just source or with some distfiles and port/work dirs? Seems a bit high. By far most of the space is taken up with distfiles once you populate a system. The number of directories is the killer, which slows down installing the collection. Am I the only one being little annoyed by this fact? Would it make any sense to offer some "castrated" ports repository. Like putting a target "overview" into each /usr/ports/*/Makefile to list all available subdiretories. Then, with some other command, one could fetch the current port's directory from the cvs server to install the port. Do these thoughts make any sense? A bit. Not certain what you are suggesting here, but something having only Makefile, DESCR and possibly README.html files for the port. Upon the first 'make' the rest of the port's directory would be first fetched with business as usual after that. My opinion is that from the start when someone installs a system they should not have to install the entire directory structure. Compared to a full source install (no X) it takes much too long. And will only increase. Breaking up ports.tgz has been suggested before. Speeding up the install should keep the impatient newcomer around and will most likely be installing the ports collection. Then there is problem of CVSup. If someone were to install the entire tree as above and use "ports-all" in their supfile... More practical to break ports.tar into their respective categories. One the "base" and other choosen categories are installed. Having the choice from the start, IMO, would mean less users with the entire, mostly unused (and certainly not needed!), tree who would later CVSup everything when updating. Then add a clear mention of of updating the ports that explains using "refuse" files along with a handy script that would use sup/whatever/refuse file for further pruning. Then if you keep the refuse files they could be used to clean fresh installs either by installing and then deleting or by removing them from ports.tar from the start, which is what I've been doing for a while. sigh There is the ever present problem of getting users to actually read documention, but at least an effort would be made. Only just recently trimmed down what I pull from ports. Did so a while back with doc and www, but didn't take the time for anything further until recently. Guess the size of the tree and CVSup logs didn't really register until a few days back (rather ironic) when I pulled for the first time in a while. Figured then it was time to make things a bit more neat and clean. Now only need to watch for checkouts and possibly add to the refuse files, which still need cleaning. The best example being ports/games, which I only need those that are called for when KDE is installed. Might want others at some time, but can check out either DESCR or README.html for candidates. Hmmm... there could be a port of these files that would compliment the INDEX. As for the initial install, taking time to trim down the original tarball saves time. (At least the CVS subdirs are gone.) Yeah, one can also use NFS and copy the tree, but I prefer to start fresh from a release and re-CVSup to -stable (or -current), so it's something I every few months. 56279040 ports-3_4.tar 48312320 ports.tar-nolang (only English spoken here :) 44206080 ports.tar-no_lang-no_README.html 39229440 ports.tar (dropped more categories) 34048000 ports.tar (nukes most games) Getting there. Glad to take some time and work out some more trimming, since 4.0-RC (2/8 snap) is on it's way over and it will be installed fresh makeing 'tar --delete -f ports.tar long_list' my friend. Trying to figure out where the time went. Last ran -current prior to 3.0. 8-) 'Nuff ramble. Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Grasshoppers at pnp/isa medows
All pertinent files are at http://www.ethereal.ru/~nms/pnpbug.tar (~20Koctets). There is one obvious bug in src/sys/isa/pnpparse.c, lines 270 and 287 where memory range size treated as byte one, while it is a 256 chunk long. See 'pnpparse.c.diffs' for patch. I am not that tough to dig into isa bus sources but somewhere there is a resource leak. The goal is kldloadable driver for isa/pnp cards. I have two of it at my test computer (a little bit different). When I try to kldload driver it shows that first board got the second resource tuple, while the second board did not got resources due to lack of free irqs. Sample stub driver with makefile, verbose dmesg and pnpinfo output provided. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On 2000-Feb-10 07:59:48 +1100, Kai Voigt [EMAIL PROTECTED] wrote: # du -sk /usr/ports 71118 /usr/ports Seems reasonable. Last time I checked (1st June 1999), I found 79967 - of which 35215 was CVS-related files/directories. There were also nearly 62,000 inodes. It'll get worse - PHK has changed the FS defaults from 8K/1K to 16K/4K, which will roughly triple the space. Am I the only one being little annoyed by this fact? This comes up regularly. The last I recall was a thread "a two-level port system?" in -hackers last May/June. My favourite solution (because it's mine) would be to replace the existing each port skeleton directory with a single ar(5) file, which is unpacked into the directory structure when you make the port. (I think ar(5) would be a good choice because (a) it is text, and so can be easily managed by CVS; (b) it includes a tool - ar(1) - for easily managing the files). As an example, /usr/ports/cad currently looks like (without CVS): /usr/ports/cad: Makefilefelt/ magic/ qcad/ xcircuit/ acs/geda/ mars/ sis/ chipmunk/ irsim/ pcb/spice/ cider/ kaskade/pkg/tkgate/ It would turn into: /usr/ports/cad: ARCHIVE/Makefile ./ARCHIVE: acs.ar geda.ar mars.ar sis.ar chipmunk.ar irsim.arpcb.ar spice.ar cider.arkaskade.ar pkg.ar tkgate.ar felt.ar magic.arqcad.ar xcircuit.ar Where the Makefile knew how to unpack/pack each ar into the existing structure as necessary. What's need to change the existing structure is: 1) A completely implemented replacement, including the tools necessary to manage the new structure. 2) Agreement from Asami-san (and maybe others) to implement the changed structure. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ipfw + natd problem
Hi, there. I'm now faced with a problem concerning ipfw + natd on the very current world with /etc properly updated. The problem is described as this: Enabling options IPFIREWALL IPDIVERT plus running natd makes it freeze on shutdown with no messages, no response to my key input, no reply to a ping from another host. :( FYI, my configuration is shown as follows, which ipfw/natd part is entirely taken from my 3.4-STABLE machine that _is_ working amazingly fine for quite a long time. knu@archon[2]% uname -a FreeBSD archon.local.idaemons.org 4.0-CURRENT FreeBSD 4.0-CURRENT #25: Thu Feb 10 18:51:07 JST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ARCHON i386 knu@archon[2]% cat /etc/rc.conf network_interfaces="fxp0 lo0" ifconfig_fxp0="inet 192.168.1.32 netmask 255.255.255.0" defaultrouter="192.168.1.1" hostname="archon.local.idaemons.org" moused_enable="YES" moused_port="/dev/cuaa0" moused_type="intellimouse" moused_flags="-w 2 -z 5 -m 7=2 -m 2=4 -m 4=5 -m 5=6 -m 6=7" allscreens_flags='-m on' firewall_enable="YES" firewall_type="open" firewall_quiet="YES" natd_enable="YES" natd_interface="fxp0" natd_flags="-f /etc/natd.conf" amd_enable="YES" amd_flags="-F /etc/amd.conf" saver="logo" keyrate="fast" knu@archon[2]% perl -ne 's/ *#.*//; print if /\S/' /sys/i386/conf/ARCHON machine i386 cpu I686_CPU ident ARCHON maxusers32 options INET options FFS options FFS_ROOT options SOFTUPDATES options MFS options NFS options MSDOSFS options NTFS options EXT2FS options CD9660 options PROCFS options NULLFS options UNION options PORTAL options COMPAT_43 options SCSI_DELAY=5000 options UCONSOLE options USERCONFIG options VISUAL_USERCONFIG options KTRACE options SYSVSHM options SYSVMSG options SYSVSEM options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options ICMP_BANDLIM options SMP options APIC_IO device isa device eisa device pci device fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device ata0at isa? port IO_WD1 irq 14 device ata device atadisk options ATA_STATIC_ID device ahc device scbus device da device sa device cd device pass device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0at atkbdc? irq 12 device vga0at isa? pseudo-device splash device sc0 at isa? device npx0at nexus? port IO_NPX irq 13 device apm0at nexus? disable flags 0x20 device pcm0 device sio0at isa? port IO_COM1 flags 0x10 irq 4 device sio1at isa? port IO_COM2 irq 3 device ppc0at isa? irq 7 device ppbus device lpt device plip device ppi device fxp pseudo-device loop pseudo-device ether pseudo-device sl 1 pseudo-device ppp 1 pseudo-device tun pseudo-device pty 16 pseudo-device md pseudo-device vn pseudo-device bpf 4 options IPFIREWALL options IPDIVERT options SHMMAXPGS=2049 options COMPAT_LINUX knu@archon[2]% cat /etc/natd.conf log no deny_incoming yes use_sockets no same_ports yes unregistered_only yes dynamic yes knu@archon[2]% If I disable natd by setting natd_enable="NO", then shutdown goes just fine. Also I confirmed that neither falling onto single user mode, unloading every kernel module nor killing natd causes freezing. Any suggestions? -- / /__ __ / ) ) ) ) / Akinori -Aki- MUSHA aka / (_ / ( (__( [EMAIL PROTECTED] "If you choose not to decide you still have made a choice." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Thu, 10 Feb 2000, Peter Jeremy wrote: Seems reasonable. Last time I checked (1st June 1999), I found 79967 - of which 35215 was CVS-related files/directories. There were also nearly 62,000 inodes. It'll get worse - PHK has changed the FS defaults from 8K/1K to 16K/4K, which will roughly triple the space. My favourite solution (because it's mine) would be to replace the existing each port skeleton directory with a single ar(5) file There are two problems in the size of the ports system. 1) The large number of inodes. Your proposal certainly addresses this. 2) The huge size of our ports collection. Unfortunately, this will only get worse^H^H^H^H^Hbetter. In addition to the files needed to build a port, there is a description which is quite useful. My variation on your theme is to have two files for each of the present ports. The first would be a Makefile that has the description imbedded in it. This would provide the hook to build the port and a browsable "library of available programs" The second would be your `ar` file of the patches, build instructions, etc. These would get unpacked only during the actual building of a particular port. For distribution, I would have the top level descriptions as one set. The archives could be obtained either individually or as sets corresponding to each of the present top level directories. Now, here is a really "silly" idea. Why don't we make a `port` collection of the FreeBSD kernel and standard userland utilities? That would lead to the next step of having the "standard distribution" become just a meta package much like 'kde' pulls in 'kdebase', 'kdeutils', 'kdegraphics', etc. -- Richard Wackerbarth [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
8 Feb current install failures
Hi ... I checked out a -current of about midnight 8 Feb ... After doing a "make buildworld" (which finished ok) ... did a "make installworld" which failed because my /usr/bin/install was not updated and thus dit not support the -fschg option. I copied the newly build install to /usr/bin and the "make installworld" completed without errors so I thought .. ok ... now it works. I compiled a new kernel and rebooted. But now everything which uses libstdc++.so.3 failes because of ... /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol "_vt$9exception" So now my KDE etc. doesn't start anymore :) HELP I've made sure that all the libraries are the latest ... I also updated /usr/src/contrib again and /usr/src/gnu Reinier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc and /usr/lib/libstdc++.so.3
On Wed, Feb 09, 2000 at 11:53:47AM -0500, Donn Miller wrote: /usr/lib/libstdc++.so.3: undefined reference to `exception type_info node' /usr/lib/libstdc++.so.3: undefined reference to `exception virtual table' /usr/lib/libstdc++.so.3: undefined reference to `__builtin_vec_new' Just a thought - have you tried -fno-c++--exceptions (or similar) ? I'm not sure if that would fix it, though. -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 8 Feb current install failures
On Thu, 10 Feb 2000, Reinier Bezuidenhout wrote: Hi ... I checked out a -current of about midnight 8 Feb ... After doing a "make buildworld" (which finished ok) ... did a "make installworld" which failed because my /usr/bin/install was not updated and thus dit not support the -fschg option. I copied the newly build install to /usr/bin and the "make installworld" completed without errors so I thought .. ok ... now it works. I compiled a new kernel and rebooted. But now everything which uses libstdc++.so.3 failes because of ... /usr/libexec/ld-elf.so.1: /usr/lib/libstdc++.so.3: Undefined symbol "_vt$9exception" You have to recompile all programs that use libstdc++.so.3, and you'll be fine. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc and /usr/lib/libstdc++.so.3
Will Andrews wrote: On Wed, Feb 09, 2000 at 11:53:47AM -0500, Donn Miller wrote: /usr/lib/libstdc++.so.3: undefined reference to `exception type_info node' /usr/lib/libstdc++.so.3: undefined reference to `exception virtual table' /usr/lib/libstdc++.so.3: undefined reference to `__builtin_vec_new' Just a thought - have you tried -fno-c++--exceptions (or similar) ? I'm not sure if that would fix it, though. I think maybe you mean -fno-vtable-thunks? Also, why do we have a separate libstdc++? I know that the standard gcc-2.95.2 itself has libstdc++ built in, so there's no separate library there. What advantage do we gain by having libstdc++ separated out? Not a criticism - just wondering. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw + natd problem
On Thu, Feb 10, 2000 at 08:46:11PM +0900, Akinori -Aki- MUSHA wrote: Hi, there. I'm now faced with a problem concerning ipfw + natd on the very current world with /etc properly updated. The problem is described as this: Enabling options IPFIREWALL IPDIVERT plus running natd makes it freeze on shutdown with no messages, no response to my key input, no reply to a ping from another host. :( FYI, my configuration is shown as follows, which ipfw/natd part is entirely taken from my 3.4-STABLE machine that _is_ working amazingly fine for quite a long time. knu@archon[2]% uname -a FreeBSD archon.local.idaemons.org 4.0-CURRENT FreeBSD 4.0-CURRENT #25: Thu Feb 10 18:51:07 JST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ARCHON i386 knu@archon[2]% cat /etc/rc.conf network_interfaces="fxp0 lo0" ifconfig_fxp0="inet 192.168.1.32 netmask 255.255.255.0" defaultrouter="192.168.1.1" hostname="archon.local.idaemons.org" moused_enable="YES" moused_port="/dev/cuaa0" moused_type="intellimouse" moused_flags="-w 2 -z 5 -m 7=2 -m 2=4 -m 4=5 -m 5=6 -m 6=7" allscreens_flags='-m on' firewall_enable="YES" firewall_type="open" firewall_quiet="YES" natd_enable="YES" natd_interface="fxp0" natd_flags="-f /etc/natd.conf" amd_enable="YES" amd_flags="-F /etc/amd.conf" saver="logo" keyrate="fast" knu@archon[2]% perl -ne 's/ *#.*//; print if /\S/' /sys/i386/conf/ARCHON machine i386 cpu I686_CPU ident ARCHON maxusers 32 options INET options FFS options FFS_ROOT options SOFTUPDATES options MFS options NFS options MSDOSFS options NTFS options EXT2FS options CD9660 options PROCFS options NULLFS options UNION options PORTAL options COMPAT_43 options SCSI_DELAY=5000 options UCONSOLE options USERCONFIG options VISUAL_USERCONFIG options KTRACE options SYSVSHM options SYSVMSG options SYSVSEM options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options ICMP_BANDLIM options SMP options APIC_IO deviceisa deviceeisa devicepci devicefdc0at isa? port IO_FD1 irq 6 drq 2 devicefd0 at fdc0 drive 0 deviceata0at isa? port IO_WD1 irq 14 deviceata deviceatadisk options ATA_STATIC_ID deviceahc devicescbus deviceda devicesa devicecd devicepass deviceatkbdc0 at isa? port IO_KBD deviceatkbd0 at atkbdc? irq 1 devicepsm0at atkbdc? irq 12 devicevga0at isa? pseudo-device splash devicesc0 at isa? devicenpx0at nexus? port IO_NPX irq 13 deviceapm0at nexus? disable flags 0x20 devicepcm0 devicesio0at isa? port IO_COM1 flags 0x10 irq 4 devicesio1at isa? port IO_COM2 irq 3 deviceppc0at isa? irq 7 deviceppbus devicelpt deviceplip deviceppi devicefxp pseudo-device loop pseudo-device ether pseudo-device sl 1 pseudo-device ppp 1 pseudo-device tun pseudo-device pty 16 pseudo-device md pseudo-device vn pseudo-device bpf 4 options IPFIREWALL options IPDIVERT options SHMMAXPGS=2049 options COMPAT_LINUX knu@archon[2]% cat /etc/natd.conf log no deny_incoming yes use_sockets no same_portsyes unregistered_only yes dynamic yes knu@archon[2]% If I disable natd by setting natd_enable="NO", then shutdown goes just fine. Also I confirmed that neither falling onto single user mode, unloading every kernel module nor killing natd causes freezing. Any suggestions? Compile your kernel with DDB, and see where it stuck from there... -- Ruslan Ermilov Sysadmin and DBA of the
Re: /usr/ports/ too big?
On Thu, Feb 10, 2000 at 10:19:18PM +1100, Peter Jeremy wrote: Am I the only one being little annoyed by this fact? This comes up regularly. The last I recall was a thread "a two-level port system?" in -hackers last May/June. Actually, -ports discussed this quite recently, and it was suggested that we combine some of the directories to reduce the number of inodes in half. This discussion belongs on -ports anyway.. so I'm bcc'ing -current. My favourite solution (because it's mine) would be to replace the existing each port skeleton directory with a single ar(5) file, which is unpacked into the directory structure when you make the port. (I think ar(5) would be a good choice because (a) it is text, and so can be easily managed by CVS; (b) it includes a tool - ar(1) - for easily managing the files). So, what you'd do is archive all of these directories into ar files, and have the Makefile unpack the archive whenever a port is needed? It would preserve the current Makefile, pkg/, scripts/, files/, etc. hierarchy? (How the hell would you pull that off? I've only known ar(1) to be used for creating library archives later ranlib'd..) Seems like this idea would make an initial install much faster and the inode/directory creation would be spread over time. Am I right? How would this affect the CVS repository? Would we still have to deal with the current hierarchy in the ports tree as it is? Or would we deal with it in ar(5) form? Which format would CVSUP update - ar(5) or current hierarchy? If it updates ar(5) form, how will bsd.port.mk know to update the directory tree for a particular port if the particular port is already unarchived? What's need to change the existing structure is: 1) A completely implemented replacement, including the tools necessary to manage the new structure. 2) Agreement from Asami-san (and maybe others) to implement the changed structure. I'm sure if Satoshi heard the answers to the above questions (among others asked), we'd be well on our way to having a new ports hierarchy for 5.0-CURRENT. :-) But it probably won't happen before 4.0-RELEASE since that's just too close to implement something big like this.. -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
annoying message when kldloading pci driver
Every attempt to kldload any pci driver produce strange message marked by in examples from two different computers. I would call it for a while "undocumented feature". Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Wed Jan 19 21:48:46 MSK 2000 nms@Draculina:/xtra/src/sys/compile/DRACULINA Timecounter "i8254" frequency 1193182 Hz CPU: Pentium/P55C (233.86-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 33554432 (32768K bytes) avail memory = 30162944 (29456K bytes) Preloaded elf kernel "kernel" at 0xc027b000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc027b09c. Intel Pentium detected, installing workaround for F00F bug npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 pci0: Intel PIIX3 ATA controller (vendor=0x8086, dev=0x7010) at 7.1 bt0: Buslogic Multi-Master SCSI Host Adapter port 0x6400-0x6403 irq 15 at device 8.0 on pci0 bt0: BT-946C FW Rev. 4.25J Narrow SCSI Host Adapter, SCSI ID 7, 100 CCBs vga-pci0: S3 ViRGE DX/GX graphics accelerator mem 0xe000-0xe3ff irq 11 at device 9.0 on pci0 de0: Digital 21140 Fast Ethernet port 0x6800-0x687f mem 0xe400-0xe47f irq 10 at device 10.0 on pci0 de0: SMC 9332DST 21140 [10-100Mb/s] pass 1.2 de0: address 00:00:c0:e0:9e:d0 de0: enabling 10baseT port xl0: 3Com 3c905B-TX Fast Etherlink XL port 0x6c00-0x6c7f mem 0xe4001000-0xe400107f irq 12 at device 11.0 on pci0 xl0: Ethernet address: 00:50:04:4c:ae:5d miibus0: MII bus on xl0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppc1: Parallel port at port 0x278-0x27f irq 5 on isa0 ppc1: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode IP packet filtering initialized, divert enabled, rule-based forwarding disabled, logging disabled Waiting 3 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a da0 at bt0 bus 0 target 0 lun 0 da0: FUJITSU M1606S-512 6226 Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 1041MB (2131992 512 byte sectors: 128H 32S/T 520C) da1 at bt0 bus 0 target 1 lun 0 da1: CONNER CFP2107E 2.14GB 1524 Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15) da1: 2048MB (4194304 512 byte sectors: 255H 63S/T 261C) da2 at bt0 bus 0 target 2 lun 0 da2: CONNER CFP2107E 2.14GB 1524 Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 15) da2: 2048MB (4194304 512 byte sectors: 255H 63S/T 261C) vinum: loaded vinum: reading configuration from /dev/da1s1e vinum: updating configuration from /dev/da2s1e de0: enabling Full Duplex 10baseT port pci0: Intel PIIX3 ATA controller (vendor=0x8086, dev=0x7010) at 7.1 ^^ pci0: Intel PIIX3 ATA controller (vendor=0x8086, dev=0x7010) at 7.1 ^^ Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Tue Feb 8 15:24:28 MSK 2000 root@Manor:/usr/src/sys/compile/MANOR Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x660 Stepping = 0 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 67096576 (65524K bytes) avail memory = 62672896 (61204K bytes) Preloaded elf kernel "kernel" at 0xc024d000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc024d09c. Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: Intel 82371AB PCI to ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX4
Mylex Support
This message was sent from Geocrawler.com by "Lawrence Farr" [EMAIL PROTECTED] Be sure to reply to that address. Has the Mylex RAID support been fixed or dropped? I could'nt see any mention of it in the hardware.txt for the release candidate. Geocrawler.com - The Knowledge Archive To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sbc and ViBRA16X - dsp device not working
[ Long post, almost a narrative. Sorry. ] Hi. A month ago I installed -current on a new computer, and the dsp device didn't work. It reminded me of why I'd rather not be running -current, so I dropped back to -stable and everything worked fine. Now I saw that a release was coming up, so I wanted to see if the problem was solved. Last night I cvsup'd to current. My sound card is recognized fine: $ dmesg | g '(sbc|pcm)' sbc1: Creative ViBRA16X at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,3 on isa0 sbc1: setting card to irq 5, drq 1, 3 pcm0: SB DSP 4.16 (ViBRA16X) on sbc1 $ tim@threads:~$ cat /dev/sndstat FreeBSD Audio Driver (newpcm) Feb 10 2000 05:59:59 Installed devices: pcm0: SB DSP 4.16 (ViBRA16X) at io 0x220 irq 5 drq 1:3 (1p/1r channels duplex) I can listen to a CD through the sound card using cdcontrol, and use mixer to adjust the volume. This is my first computer w/ a sound card, so I don't know how to do much more than that. The problem comes when trying to use the /dev/dsp device (which is the only other thing I've tried). Xmms, for example, won't play - it opens fine, and I can manipulate the play list, etc. But when I try to play an mp3 file, it stops responding. Here's a before and after ps -axlww: Before trying to play the mp3 file: 1001 3124 1 1 2 0 9068 5632 poll S p00:01.99 xmms After: 1001 3124 1 0 2 0 10856 7356 poll S p00:02.68 xmms I couldn't see anything weird with ps or top. But xmms will not respond to any mouse events. A normal kill ends the program, though. Another program I have that uses /dev/dsp is xgalaga (from the 3.4 release package). When it starts up, it says: xgal.sndsrv: fragment set to 512 and ps -xw shows: 33248 p2 S+ 0:00.14 xgalaga 33249 p2 S+ 0:00.01 /usr/X11R6/lib/X11/xgalaga/xgal.sndsrv.freebsd /usr/X11R6/lib/X11/xgalaga/sounds/ /dev/dsp No sound is heard when I play the game, but otherwise game play is normal. After I quit the game, the sndsrv program is still running: 33249 p2 S 0:00.08 /usr/X11R6/lib/X11/xgalaga/xgal.sndsrv.freebsd /usr/X11R6/lib/X11/xgalaga/sounds/ /dev/dsp After a normal kill, it quits after a few seconds. These programs worked under -stable, using the pcm sound driver (didn't need the sbc bridge there). Last month when I tried it under -current, something very odd happened that isn't happening now. After running something like $ cat /dev/dsp a ps would show two instances of cat running; likewise if I ran xmms, it would show two instances of xmms! And I'd have to send a -KILL signal to get them to die. I don't know how else to debug this. Right now if I do: $ cat /dev/dsp foo ^D I can hear a pop through my headphones. So something's there; but my applications can't use it. I built the most recent port of xmms just this morning, in case something was buggy there. If this is not a bug, I'm very sorry to have wasted your time. If you need me to try anything out, just let me know. Thanks, Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Thu, Feb 10, 2000 at 08:44:09AM -0500, Will Andrews wrote: On Thu, Feb 10, 2000 at 10:19:18PM +1100, Peter Jeremy wrote: Am I the only one being little annoyed by this fact? This comes up regularly. The last I recall was a thread "a two-level port system?" in -hackers last May/June. Actually, -ports discussed this quite recently, and it was suggested that we combine some of the directories to reduce the number of inodes in half. This discussion belongs on -ports anyway.. so I'm bcc'ing -current. Oops. I'll leave all the context in so the -ports people can see it. :-) My favourite solution (because it's mine) would be to replace the existing each port skeleton directory with a single ar(5) file, which is unpacked into the directory structure when you make the port. (I think ar(5) would be a good choice because (a) it is text, and so can be easily managed by CVS; (b) it includes a tool - ar(1) - for easily managing the files). So, what you'd do is archive all of these directories into ar files, and have the Makefile unpack the archive whenever a port is needed? It would preserve the current Makefile, pkg/, scripts/, files/, etc. hierarchy? (How the hell would you pull that off? I've only known ar(1) to be used for creating library archives later ranlib'd..) Seems like this idea would make an initial install much faster and the inode/directory creation would be spread over time. Am I right? How would this affect the CVS repository? Would we still have to deal with the current hierarchy in the ports tree as it is? Or would we deal with it in ar(5) form? Which format would CVSUP update - ar(5) or current hierarchy? If it updates ar(5) form, how will bsd.port.mk know to update the directory tree for a particular port if the particular port is already unarchived? What's need to change the existing structure is: 1) A completely implemented replacement, including the tools necessary to manage the new structure. 2) Agreement from Asami-san (and maybe others) to implement the changed structure. I'm sure if Satoshi heard the answers to the above questions (among others asked), we'd be well on our way to having a new ports hierarchy for 5.0-CURRENT. :-) But it probably won't happen before 4.0-RELEASE since that's just too close to implement something big like this.. -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Quirk in the latest 4.0-RC install disk ?
Hello, I've just installed 4.0 from the latest Release Candidate (iso image gotten from the freebsd ftp and burned this morning) the install itself went smooth, but I can't start X11 : there seems to be a bug in the dynamic libraries : % ldd `which xinit` /usr/X11R6/bin/xinit: libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0x28066000) libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x28078000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x280c) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x280c9000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x280de000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x280ea000) libxpg4.so.2 = /usr/lib/libxpg4.so.2 (0x28189000) libc.so.4 = /usr/lib/libc.so.4 (0x2818d000) libXThrStub.so.6 = not found (0x0) libXThrStub.so.6 = not found (0x0) % what's this libXThrStub.so.6 ? % uname -a FreeBSD XX.alcatel.fr 4.0-2208-CURRENT FreeBSD 4.0 % TfH dmesg : Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-2208-CURRENT #0: Thu Feb 10 16:08:11 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/P5-lnc Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 74539288 Hz CPU: Pentium/P54C (74.54-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x526 Stepping = 6 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 33554432 (32768K bytes) config q avail memory = 29990912 (29288K bytes) Preloaded elf kernel "kernel" at 0xc029d000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc029d09c. Intel Pentium detected, installing workaround for F00F bug md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 lnc0: PCNet/PCI Ethernet adapter port 0xfce0-0xfcff mem 0xfedffc00-0xfedffc1f irq 9 at device 8.0 on pci0 lnc0: PCnet-PCI II address 08:00:09:bb:26:57 lnc0: driver is using old-style compatability shims vga-pci0: S3 Trio graphics accelerator mem 0xfe00-0xfe7f at device 13. 0 on pci0 isab0: Intel 82371FB PCI to ISA bridge at device 15.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX ATA controller port 0xfcd0-0xfcdf at device 15.1 on pci0 ata0 at 0x01f0 irq 14 on ata-pci0 devclass_alloc_unit: lnc0 already exists, using next available unit number fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 ata-isa0: already registered as ata0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppi0: Parallel I/O on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port plip0: PLIP network interface on ppbus0 lnc1: not probed (disabled) ep0: 3Com 3C509-Combo EtherLink III at port 0x280-0x28f irq 5 on isa0 ep0: Ethernet address 00:60:08:78:98:cb ad0: 814MB WDC AC2850F [1654/16/63] at ata0-master using PIO3 Mounting root from ufs:/dev/ad0s1a To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
XFree86 Libraries
Hi all! I don't know if this has been addressed already, but the archives are offline. I started using current by installing 2127-SNAP of current.freebsd.org including XFree86 3.3.6. The Xfree86 a.out libraries were missing from the installtion tarballs, so e.g. Netscape would not run. I fixed it for me by getting Xbin.tgz for FreeBSD 2.2.x from XFree86.org and putting the libs in /usr/X11R6/lib/aout manually, but of course these should be in the "standard" installation of 4.0-RELEASE. Regards, Patrick -- WEB Internet Services Systemhaus GmbH Scheffelstr. 17a76135 Karlsruhe phone +49 721 9109 0 fax +49 721 9109 100 http://www.punkt.de/ Patrick M. Hausen Technical Director email [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
questions about 4.0 along with 3.4-STABLE
Hello all, I'm almost done downloading the ISO image of 4.0-RC that Jordan announced yesterday. I'd very much like to contribute to the "qa" effort for 4.0 but I've got a few questions I know you experts can answer before I dive in. Right now I've got a 3.4-STABLE system on da1. I don't want to touch that (I've got tape backups and all, but I still don't want to nuke it just yet). I was going to purchase a "cheap" (in price) 15-20Gb EIDE drive "soon" just for MP3s and other random storage and figured that before I put it into my "real" system that I could use it to install 4.0-RC and help give feedback on the experience. My questions: o As long as I DO NOTHING to my scsi drives in any of the label/partition screens, is there any chance that doing a binary install onto this new EIDE drive will affect them in any way? I saw yesterday that one must do "disklabel -B" on all your disks when upgrading from source. Would sysinstall do this to "all" disks and if so, would that screw me once I wanted to go back and boot good ol' 3.4-STABLE? o I'm currently dual-booting on this machine. Would the install do anything to the boot sector (i.e. giving me the option to boot from this new EIDE drive)? Right now, I'm only interested in "dry-running" this 4.0-RC to help out testing. Eventually, I've got to re-org da1 (and da0) and will do a complete backup, nuke, and re-install of 4.0 from "official" CDs--given this, would it be "safer" to simply unplug the silly SCSI drives from the machine and do the install (so it would be physically impossible to screw them over in any way)? Thanks, -Jr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | John Reynolds WCCG, CCE, Higher Levels of Abstraction | | Intel Corporation MS: CH6-210 Phone: 480-554-9092 pgr: 602-868-6512 | | [EMAIL PROTECTED] http://www-aec.ch.intel.com/~jreynold/ | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
first impressions after upgrading from 3.4-RELASE to 4.0-20000209-CURRENT
I have just finished a net install of 4.0-2209-CURRENT using the sysinstall's "Upgrade" procedure, over a 3.4-RELEASE system. Well, the system is now running OK, but I found some small issues. First, I must say that I was not following the -CURRENT branch since the transition to 3.1-STABLE. This means that my point of view is similar to that of many users who will install 4.0-RELEASE. The target machine is based on a Iwill PIILS motherboard (with integrated Adaptec 7880 SCSI controller), and it has no ATA peripherals. Its ethernet adapter is a 3COM509 (until I can borrow a better card ;-) ). 1. Just after booting the install kernel, I went to the visual configuration screen in order to disable all drivers for unexistent devices. My first surprise was that the ep(4) driver was not listed. However, the install kernel includes this driver: the card was correctly detected. I think that this issue should be documented somewhere, or lots of questions will flood the mailing lists :-) 2. From sysinstall, I selected the "Upgrade" option, the "X-User" distribution, and I customized it adding "games". However, /usr/games was not touched by the upgrade. 3. I selected "ftp7.de.freebsd.org" as installation media. However, the directory was not found; then, I had to specify the exact URL: ftp://ftp7.de.freebsd.org/pub/FreeBSD/snapshots/i386/. 4. After finishing an upgrade (using sysinstall or "make world") I always examine /sbin, /bin, /usr/sbin, /usr/bin, /usr/libexec and /usr/lib, searching for old binaries and libraries that must be removed or that should have been overwritten by the new versions. And I found that there was two files under /usr/libexec not touched by the upgrade: mail.local and ld-elf.so. They have the "schg" flag, so I think that the upgrade failed to overwrite them. 5. Next step: build a custom kernel. I knew that the gcc compiler is new, and I typed a "man cc" to find that I can use a "-march=pentiumpro" flag. Great! Then, I edited /etc/make.conf and... where is the new make.conf? In /etc/upgrade? No! In /usr/src/etc? No! I found it after doing a "grep make.conf /usr/share/mk/*": it resides in /etc/defaults! OK, I created a new /etc/make.conf only containing the changes from the defaults. 6. Boot the new kernel. The boot messages seem OK, except: ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs isa0: unexpected tag 14 THIS! ?? fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 7. I tested sound and it did not work. What happened? Easy: the new pcm driver attachs itself as "pcm0" instead of "pcm1". Then, I remade the sound devices with ./MAKEDEV snd0, and sound worked again. 8. I started X (I use KDE) and it worked, even after removing the old libraries. This is good, as I don't want to compile KDE today :-) Using ldd(1) I listed the shared libraries used by some KDE binaries, to find that some libs are under /usr/lib/compat. Well, this means that KDE (like most ports, I suppose) should be recompiled. But then, a thought crossed my mind: what about XFree86? The binaries have been built for FreeBSD 3.x! And indeed: /usr/X11R6/bin/XF86_SVGA: libxpg4.so.2 = /usr/lib/libxpg4.so.2 (0x282ee000) libz.so.2 = /usr/lib/libz.so.2 (0x282f2000) libm.so.2 = /usr/lib/libm.so.2 (0x282ff000) libc.so.3 = /usr/lib/compat/libc.so.3 (0x2831a000) = Hummm... This is ugly. This means that the XFree86 3.3.6 which will be distributed with 4.0-RELEASE needs the "compat3x" libraries. This should be documented somewhere. That's all for the moment. Sorry for the long message, but I thought that this information could be useful. Cheers, -- JMA --- José Mª Alcaide | mailto:[EMAIL PROTECTED] Universidad del País Vasco | mailto:[EMAIL PROTECTED] Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-946013071 --- "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 Libraries
"Patrick M. Hausen" wrote: Hi all! I don't know if this has been addressed already, but the archives are offline. I started using current by installing 2127-SNAP of current.freebsd.org including XFree86 3.3.6. The Xfree86 a.out libraries were missing from the installtion tarballs, so e.g. Netscape would not run. I can confirm this problem with 4.0-2209-CURRENT. I did not detected it myself because I did an upgrade and the old XFree86 3.3.5 a.out libraries are still in /usr/X11R6/lib/aout. -- JMA --- José Mª Alcaide | mailto:[EMAIL PROTECTED] Universidad del País Vasco | mailto:[EMAIL PROTECTED] Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-946013071 --- "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Upgrading to 4.0
after seeing your steps.. it makes sense pre-build the kernel to 4.0 _before_ installing world. however... could you provide a little more info on steps 5, 6, 7 specifically.. what does the -DNOINFO do ( i can't find it on my system.. yet) -DNOINFO is documented in src/Makefile.inc1, it is required for successful -current installworld from 3.x due to bootstrapping problems (-current install-info(1) has two new options). AHAA !! those new options wouldn't by any chance be --section --entry ??? i got an error on my original make saying --defsection --defentry were invalid options after man'ing "install-info" i went into /usr/share/src/mk and edited bsd.info.mk appropriately. however... THAT didn't work.. someone suggested doing a "make install" in /usr/share/src/mk of course, that didn't work either guess i'm just saying that this all makes a lot more sense now... thanks for all the help on all this gonna give it a shot right now in fact :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
howto for 3.4-STABLE - 4.0-CURRENT?
Any advice on upgrading a system from -STABLE to -CURRENT? Or would a standard "cvsup, make world, make kernel, reboot" do it? -- -Jason J. Horton [EMAIL PROTECTED] Fat Man in a Little Coat Intercom Online Inc. 212.376.7440 ext 21 | http://www.intercom.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: first impressions after upgrading from 3.4-RELASE to 4.0-20000209-CURRENT
On Thu, 10 Feb 2000, Jose M. Alcaide wrote: 1. Just after booting the install kernel, I went to the visual configuration screen in order to disable all drivers for unexistent devices. My first surprise was that the ep(4) driver was not listed. However, the install kernel includes this driver: the card was correctly detected. I think that this issue should be documented somewhere, or lots of questions will flood the mailing lists :-) The 'ep' driver doesn't support manual configuration now. It autodetects in normal or PnP mode just fine. There is an outstanding issue with the board conflicting with another device but I've not come up with an easy way to work around this. Not all devices are listed in the boot configuration screen; it is for devices that do not support auto-detection. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: howto for 3.4-STABLE - 4.0-CURRENT?
On 10-Feb-00 Jason J. Horton wrote: Any advice on upgrading a system from -STABLE to -CURRENT? Or would a standard "cvsup, make world, make kernel, reboot" do it? You need a -current kernel for installworld to work. In fact, if you aren't running a -current kernel installworld will blow up on your machine. Try this instead: - cvsup -current - make buildworld - make buildkernel - make installkernel - reboot into single user mode - make -DNOINFO installworld - make installworld - merge over /etc changes, etc. - reboot -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[patch] stuttering of sound with ESS cards
The following patch removes the stutter when you Ctrl-Z mpg123. The
soundcard in my desktop machine at work does not have the stutter and
that one is a ES1371 card. The patch makes the ess_intr routine look
more like the sb_intr and es_intr ones.
Index: sb.c
===
RCS file: /home/ncvs/src/sys/dev/sound/isa/sb.c,v
retrieving revision 1.49
diff -u -r1.49 sb.c
--- sb.c2000/01/10 03:22:28 1.49
+++ sb.c2000/02/10 18:27:14
@@ -360,7 +360,7 @@
sb_wr(sb, SBDSP_RST, 0);
if (sb_get_byte(sb) != 0xAA) {
DEB(printf("sb_reset_dsp 0x%lx failed\n",
- rman_get_start(d-io_base)));
+ rman_get_start(sb-io_base)));
return ENXIO; /* Sorry */
}
if (sb-bd_flags BD_F_ESS)
@@ -583,14 +583,10 @@
* We are transferring data in DSP normal mode,
* so clear the dl to indicate the DMA is stopped.
*/
- if (sb-pch.buffer-dl 0) {
- sb-pch.buffer-dl = -1;
+ if (sb-pch.buffer-dl 0)
chn_intr(sb-pch.channel);
- }
- if (sb-rch.buffer-dl 0) {
- sb-rch.buffer-dl = -1;
+ if (sb-rch.buffer-dl 0)
chn_intr(sb-rch.channel);
- }
}
static int
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Mylex Support
This message was sent from Geocrawler.com by "Lawrence Farr" [EMAIL PROTECTED] Be sure to reply to that address. Has the Mylex RAID support been fixed or dropped? It was never really in need of "fixing", although there are certainly still some issues with it. The Mylex controller family is supported in the release candidate, yes. I could'nt see any mention of it in the hardware.txt for the release candidate. I'm working on that today. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Wed, Feb 09, 2000 at 09:45:42PM -0500, Chuck Robey wrote: Flattening out the unecessarily deep ports directory structure would help, too. Probably, 98 percent of it could be done with a script, and it would greatly decrease cvsup time and space. I've often thought that it might be better if each port were a single tar file or something instead of the 30+ files that many of them now contain. From there, it seems like a straightforward step to not keep the tar files on your machine, much like you don't keep the distfiles. "make-port xmms" or whatever could go out and grab the xmms port tar file from ftpX.freebsd.org, extract it to the appropriate place, then do a make as usual. I haven't had time to try to implement it, though. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
Christopher Masto wrote: On Wed, Feb 09, 2000 at 09:45:42PM -0500, Chuck Robey wrote: Flattening out the unecessarily deep ports directory structure would help, too. Probably, 98 percent of it could be done with a script, and it would greatly decrease cvsup time and space. I've often thought that it might be better if each port were a single tar file or something instead of the 30+ files that many of them now contain. Here's what we can do. We keep all the "major" subdirectories in place, such as audio, devel, etc. BUT, instead of branching out into separate subdirectories, we can just put everything into the Makefile. For example, here are some subdirectories in /usr/ports/audio: amp/ ascd/ aumix/ bladeenc/ cam/ cd-console/ cdd/ We just do away with the subdirectories, flatten all the directories' contents out into one makefile, including DESCR, etc. (I really don't see why we need to have a separate DESC, md5 files, etc.) We can have md5 = xx and DESC=x inside the Makefiles, for example. Here's how we can flatten this: Makefile.amp Makefile.ascd Makefile.aumix Makefile.bladeenc Makefile.cam Makefile.cd-console Makefile.cdd Then, to build the port, one would do make -f Makefile.aumix to build the aumix port. All these makefiles would go inside of audio. To do the building each port, we can have the "work" be done inside the user's home directory. This would eliminate the need to log in as root in order to do the actual building. The benefits of having the port build inside the user's home directory are: * the user could have the option of installing the port in his own personal directory, in case the sysadmin doesn't see fit to put the port on the system * eliminates the security risk of having to do long compiles as root Then, to install the port, the port mechanism could check the uid of the user. If it is 0, the port gets installed in the system, under /usr/local, /usr/X11R6, or whatever. If it is nonzero, the port gets installed in the user's home directory. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
: contain. : :Here's what we can do. We keep all the "major" subdirectories in :place, such as audio, devel, etc. BUT, instead of branching out into :separate subdirectories, we can just put everything into the :Makefile. For example, here are some subdirectories in :/usr/ports/audio: Ouch. I think this is a big mistake. The one-directory-per-port scheme works extremely well, it doesn't make much sense to get rid of it, and it doesn't make much sense ripping the *working* ports scheme to shreds when a simpler solution is available. All I would propose is that those subdirectories do not need to be part of the base distribution -- that typing 'make modulename' in the parent directory (e.g. typing 'make ssh' in ports/security) would first download the subdirectory and then do a normal make within that subdirectory. The initial ports distribution would thus only be a few dozen directories and a single Makefile in each one. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Thu, 10 Feb 2000, I wrote: PHK has changed the FS defaults from 8K/1K to 16K/4K, Ooops. I mis-remembered a commit pkh made last August (src/release/sysinstall/install.c 1.91), I thought he had changed the defaults, but he just commented that 16K/4K was more sensible... My apologies to Poul-Henning and I'll try to remember not to trust my memory without double-checking :-(. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
Richard Wackerbarth writes: There are two problems in the size of the ports system. 1) The large number of inodes. I don't see the ports tree as the problem. The problem is that FreeBSD does not handle a very large directory hierarchy like that presented by the ports tree very well. The right angle of attack IMHO is to better optimize the kernel and maybe the filesystem. I don't know enough to know how you would do this though. For example, there's the thing about how we don't cache filesystem data and filesystem meta-data (directory blocks) the same way (this is the best I can describe it). Now, here is a really "silly" idea. Why don't we make a `port` collection of the FreeBSD kernel and standard userland utilities? That would lead to the next step of having the "standard distribution" become just a meta package much like 'kde' pulls in 'kdebase', 'kdeutils', 'kdegraphics', etc. This idea makes a lot of sense. All of FreeBSD could be packagable as ports/packages. It might even simplify the installer. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [patch] stuttering of sound with ESS cards
Nick Hibma wrote:
The following patch removes the stutter when you Ctrl-Z mpg123. The
soundcard in my desktop machine at work does not have the stutter and
that one is a ES1371 card. The patch makes the ess_intr routine look
more like the sb_intr and es_intr ones.
I just tried this patch, and I've got the ESS 1868. It seems to help
that nasty skipping problem with RealPlayer 5.0, and it definitely
stops the skipping in mpg123. I would consider committing this.
To test out if RealPlayer is skipping or not, try playing any of the
clips at cdnow.com. (They've got samples.) All the net congestion
made rvplayer go crazy before. Now, it's much more well-behaved.
Index: sb.c
===
RCS file: /home/ncvs/src/sys/dev/sound/isa/sb.c,v
retrieving revision 1.49
diff -u -r1.49 sb.c
--- sb.c2000/01/10 03:22:28 1.49
+++ sb.c2000/02/10 18:27:14
@@ -360,7 +360,7 @@
sb_wr(sb, SBDSP_RST, 0);
if (sb_get_byte(sb) != 0xAA) {
DEB(printf("sb_reset_dsp 0x%lx failed\n",
- rman_get_start(d-io_base)));
+ rman_get_start(sb-io_base)));
return ENXIO; /* Sorry */
}
if (sb-bd_flags BD_F_ESS)
@@ -583,14 +583,10 @@
* We are transferring data in DSP normal mode,
* so clear the dl to indicate the DMA is stopped.
*/
- if (sb-pch.buffer-dl 0) {
- sb-pch.buffer-dl = -1;
+ if (sb-pch.buffer-dl 0)
chn_intr(sb-pch.channel);
- }
- if (sb-rch.buffer-dl 0) {
- sb-rch.buffer-dl = -1;
+ if (sb-rch.buffer-dl 0)
chn_intr(sb-rch.channel);
- }
}
static int
- Donn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Thu, 10 Feb 2000, Donn Miller wrote: All these makefiles would go inside of audio. To do the building each port, we can have the "work" be done inside the user's home directory. This would eliminate the need to log in as root in order to do the actual building. The benefits of having the port build It is already possible to do this. You simply need to set $WRKDIRPREFIX and $WRKDIR. inside the user's home directory are: * the user could have the option of installing the port in his own personal directory, in case the sysadmin doesn't see fit to put the port on the system Already possible. Set $DESTDIR The stuff in /usr/ports/Mk is pretty impressive. David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
At 11:45 AM 2/10/00 -0800, Matthew Dillon wrote: : contain. : :Here's what we can do. We keep all the "major" subdirectories in :place, such as audio, devel, etc. BUT, instead of branching out into :separate subdirectories, we can just put everything into the :Makefile. For example, here are some subdirectories in :/usr/ports/audio: Ouch. I think this is a big mistake. The one-directory-per-port scheme works extremely well, it doesn't make much sense to get rid of it, and it doesn't make much sense ripping the *working* ports scheme to shreds when a simpler solution is available. In the context of CVSup server connections it would not be. Have to chuckle when I hear someone doing CVSup for ports-all. Unless they have a reason, but as we know many will do man things blindly. All I would propose is that those subdirectories do not need to be part of the base distribution -- that typing 'make modulename' in the parent directory (e.g. typing 'make ssh' in ports/security) would first download the subdirectory and then do a normal make within that subdirectory. Sounds good, but again how will the CVSup file for ports and CVSup itself deal with this. Either a "refuse" file would need to be created and then populated or there would need to be other changes. Not sure Mr Wraith or the CVS maintainers would like to break down all the ports and have a *huge* CVSup file for ports. Or some other method would be needed that would increase the complexity of how the ports source is handled. The initial ports distribution would thus only be a few dozen directories and a single Makefile in each one. But there are several goals: A faster, more simple install would be good. Reduced inode usage, less dirs to walk, etc.. Done in a manner to keep updating simple. What you (and others) have suggested covers the first 2, but then what happens when someone decides to update their source. Your suggestion would mean that to first get the source for the port, but then how does one keep it up to date. Not to mention the ports maintainer(s) might end up jumping through more hoops. Guess that should be added to the list, as well as not relying more the source repositories and mirrors. All irrelevant if hitting a mirror every time 'make port' to grab the source (initial or update) will not be an ongoing load issue for the servers. Still, what if I just want the source? Something like 'make source' will be needed or 'make fetch' will need to cover that. Just trying to cover all bases here and should sub to -install and see what's going on. Jeff Mountin - [EMAIL PROTECTED] Systems/Network Administrator FreeBSD - the power to serve '86 Yamaha MaxiumX (not FBSD powered) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
wine in freebsd-current
After upgrading to 4.0-current and attempting a clean install of wine, I
saw this:
./parser.y: In function `yyparse':
./parser.y:1624: syntax error before `}'
in: /usr/ports/emulators/wine/work/wine-991114/tools/wrc/parser.y
line 1624: expr: xpr { $$ = ($1) }
was obviously incorrect (typo), fix was:
expr: xpr { $$ = ($1); }
in case anyone else has this problem and doesnt know c.
--
Adriel Ickler
Network Administrator - [EMAIL PROTECTED]
Self Trading Securities - Voice: 512-263-2769
www.selftrading.com - Fax: 512-263-2141
Forty two.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: wine in freebsd-current
On Thu, Feb 10, 2000 at 03:30:34PM -0600, Adriel Ickler wrote:
After upgrading to 4.0-current and attempting a clean install of wine, I
saw this:
./parser.y: In function `yyparse':
./parser.y:1624: syntax error before `}'
in: /usr/ports/emulators/wine/work/wine-991114/tools/wrc/parser.y
line 1624: expr: xpr { $$ = ($1) }
was obviously incorrect (typo), fix was:
expr: xpr { $$ = ($1); }
in case anyone else has this problem and doesnt know c.
Wine thinks it can use byacc, but it needs bison. The patch attached to
the PR ports/16344 will fix the build or you can just cd to
ports/devel/bison and install it first which is all the patch really
does.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Thu, 10 Feb 2000, Archie Cobbs wrote: Richard Wackerbarth writes: There are two problems in the size of the ports system. 1) The large number of inodes. I don't see the ports tree as the problem. The problem is that FreeBSD does not handle a very large directory hierarchy like that presented by the ports tree very well. We HAVE to live in the house. The question is "how do we make the best use of the hand that was dealt us?" Fundamentally, I object to being required/expected to maintain a copy of a large amount of information that does not impact my system. I don't care about the patches to X unless I decide to install it. Similarly, I think that it is a stupid design to require everyone to keep the ENTIRE history of a file (per cvs). I have CD roms which have the old versions in case I need to reference them. Why cannot the 4.0 branch simply "end" with a reference to the 3.x CD for those who want to dig deeper. Now, here is a really "silly" idea. Why don't we make a `port` collection of the FreeBSD kernel and standard userland utilities? This idea makes a lot of sense. All of FreeBSD could be packagable as ports/packages. It might even simplify the installer. And `make` can pull in the dependencies (-: Sorry, you cannot reuse the existing tools. You must write a new one :-) -- Richard Wackerbarth [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0 fails to boot - sym troubles
On Thu, 10 Feb 2000, Gerard Roudier [EMAIL PROTECTED] wrote: Hello, Just quoting the offending messages: On Wed, 9 Feb 2000, Aaron Gifford wrote: sym0: SCSI parity error detected: SCR=3D1 DBC=3D7258 SBCL=3Daf (noperiph:sym0:0:-1:-1): SCSI BUS reset detected. The driver gets an SCSI parity error while attempting to snoop the BUS by reading directly the SCSI BUS data line bit 0...7. I have recently discovered experimentally that a spurious SCSI parity error due to the chip checking against parity for bit 8..15 can be triggerred in some special situations, for example when the WSR bit is set. The WSR bit is set when a residual byte didn't fit a previous CHMOV for a scatter entry and the target changes phase at the beginning of the next CHMOV (count) with count 1. (For count=3D1, the WSR bit isn't set and the residual byte is transferred to memory). Since this issue cannot be cleanly worked-around, I have decided to handle things differently so that it is no longer needed to snoop the BUS by reading directly the SCSI BUS data lines. Result is sym-1.3.2-2206 that haven't (yet?) been committed due to 4.0 release time.=20 If you could give a try with this driver version, this would help. ftp://ftp.tux.org/roudier/drivers/freebsd/experimental/sym-1.3.2-freebsd.20= 000206.readme ftp://ftp.tux.org/roudier/drivers/freebsd/experimental/sym-1.3.2-freebsd.20= 000206.tar.gz (The tar contains full driver files to move to src/sys/dev/sym) You may want to let me know if it fixes or not. Thanks. Regards, G=E9rard. PS: On the other hand, I seem to remember that my last commit for the `sym' driver has been done on January the 12th. So the kernel that fails should just use same `sym' driver as 4.0-CURRENT-25-January that succeeds. Btw, if the `ncr' that just ignores the WSR bit succeeds, then I may well be right. THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU THANK YOU That fixed the problem! Too bad it didn't make it into the latest 4.0-RC. Other folks with Tekram cards experiencing the problem should give your fix a try too. I rebuilt my 4.0 (as of 10 Feb. 2000 CVSup) kernel using your latest sym files and rebooted. The errors I mentioned in my posts went away completely. I did not make any other changes. Since then, the driver appears to be working find. I'm doing a buildworld right now and have seen nothing unusual at all. Again, let me repeat, many thanks for your work and for the fix! Sincerely, Aaron Gifford To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
S/Key authentication fails for ftpd
The subject says all ;-). System version: 4.0-2229-CURRENT (ftpd 6.00LS). However, S/Key authentication works for telnet and login. Of course, the simple cleartext password authentication method does work for ftpd. It looks like a bug in ftpd (or PAM?). -- JMA --- José Mª Alcaide | mailto:[EMAIL PROTECTED] Universidad del País Vasco | mailto:[EMAIL PROTECTED] Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-946013071 --- "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: first impressions after upgrading from 3.4-RELASE to 4.0-20000209-CURRENT
Kenneth Wayne Culver wrote: Hummm... This is ugly. This means that the XFree86 3.3.6 which will be distributed with 4.0-RELEASE needs the "compat3x" libraries. This should be documented somewhere. if you cd to /usr/ports/x11/XFree86 and do a make... this problem will be solved. Yes. I know how to solve this problem ;-), but just think of many users that will install (or upgrade to) 4.0-RELEASE. I suggest that the need of compat3x for XFree86 (the XFree86 3.3.6 distributed with 4.0-RELEASE) should be clearly stated. -- JMA --- José Mª Alcaide | mailto:[EMAIL PROTECTED] Universidad del País Vasco | mailto:[EMAIL PROTECTED] Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-946013071 --- "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Why is libstdc++ separate from g++ 2.95.2?
Just curious as to what the advantages are of having libstdc++ separated from gcc. From what I recall on www.gnu.org, they said g++ 2.95.2 will have libstdc++ integrated into gcc/g++ itself. It seems to causing some problems on FreeBSD, like my aforementioned post on compiling kdesupport-current. Shrugs. I followed the instructions in UPDATING and recompiling Qt, which uses g++ and hence libstdc++, but I still got the errors. (See my previous mail about libstdc++ and gcc that I made a while back.) I saw someone on here that had the same problem. He said that the errors went away when he forced static linking to libstdc++.a. (He moved /usr/lib/libstdc++.so.3 to a temp directory.) So, why is libstdc++ separate? If necessary, I can always compile gcc 2.95.2, and install that one in /usr/local as an "external" compiler. But, I guess that would be redundant. - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
Just FYI, a cvsup of ports over a single ISDN-line took 22 min on a soft-update'd disk. .cvsignore INDEX LEGAL Makefile Mk README Templates Tools YEAR2000 archivers astro audio benchmarks cad comms converters databases deskutils devel distfiles editors emulators ftp games graphics lang mail math misc net news print security shells sysutils textproc www x11 x11-clocks x11-fm x11-fonts x11-toolkits x11-wm Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ES1371 problems..
I have a SoundBlaster PCI128 (ES1371) in my computer, and for the life of me I have the weirdest problem. Of course I don't have the problem if I put a ISA SB16 in place of it. So it's gotta be ES1371 related. Okay, the ES1371 works great with all but one application (that I have found so far). If I try and use play (a wrapper shipped with sox), it works one time and than no more. But I am able to work fine using mpg123, xmms for example. All three of these use the OSS interface to the sound device. I have begun looking at the applications trying to determine which one does something differently, and so far have made little headway at all on this. As I said this works fine if I put a SB16 ISA card back in the computer instead of the ES1371. So it's related to something the ES1371 driver isn't doing. The weird part is that it plays the wav file once. Okay while I was writing this I have found a more interesting note. This appears to only happen when I'm trying to play a MONO file. It plays stereo files just fine (these are .wav files btw). Now what doesn't make sense about this is I have tried forcing mono on mpg123 and xmms and they both still work fine. So if anyone has any ideas, please shoot them to me. Otherwise I will continue my quest to figure out why this is broke. Greg -- Greg Rumple [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc and /usr/lib/libstdc++.so.3
On Tue, Feb 08, 2000 at 06:35:58PM +0100, Maxim Sobolev wrote: Donn Miller wrote: I am running the lastest -current (just did a cvsup followed by a make world last night). I am getting these link errors when trying to compile the developement version of kdesupport, which I obtained thru cvsup. (KDE uses cvsup for its development versions.) I get the following errors. I have also installed the latest development snapshot of gcc 2.96 into /usr/local/bin, and I don't get these errors. gmake[5]: Entering directory `/usr/home/dmmiller/compile/kde/kdesupport/odbc/uni xODBC/odbcinst/cmd' /bin/sh ../../../../libtool --silent --mode=link gcc -mpentium -O3 -pipe Ok, I just tried this. This is a config error in KDE-current. If you use ,g++' instead of ,gcc` in the above line, it will compile. -s -o odbcinst odbcinst.o ../libodbcinst.la ../../lst/libuodbclst.la /usr/lib/libstdc++.so.3: undefined reference to `exception type_info function' [...] gmake[5]: *** [odbcinst] Error 1 Absolutely the same is here on just builded/installed -current. Interesting that two days ago I had compiled kdesupport w/o this problem on the -current system compiled on February 3. Therefore bug in question was introduced during Feb 3 - Feb 8 period. See above. This is not a problem of FreeBSD. Using a C compiler for linking C++ just does not work. -- German Tischler, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ES1371 problems..
Greg Rumple wrote:' Can you give me the exact test that fails. I assume this is a current kernel. Also give me the "pcm" messages that get printed out at boot time; specifically the rev number. This might have something to do with the rev 7 boards again. I have a SoundBlaster PCI128 (ES1371) in my computer, and for the life of me I have the weirdest problem. Of course I don't have the problem if I put a ISA SB16 in place of it. So it's gotta be ES1371 related. Okay, the ES1371 works great with all but one application (that I have found so far). If I try and use play (a wrapper shipped with sox), it works one time and than no more. But I am able to work fine using mpg123, xmms for example. All three of these use the OSS interface to the sound device. I have begun looking at the applications trying to determine which one does something differently, and so far have made little headway at all on this. As I said this works fine if I put a SB16 ISA card back in the computer instead of the ES1371. So it's related to something the ES1371 driver isn't doing. The weird part is that it plays the wav file once. Okay while I was writing this I have found a more interesting note. This appears to only happen when I'm trying to play a MONO file. It plays stereo files just fine (these are .wav files btw). Now what doesn't make sense about this is I have tried forcing mono on mpg123 and xmms and they both still work fine. So if anyone has any ideas, please shoot them to me. Otherwise I will continue my quest to figure out why this is broke. Greg -- Greg Rumple [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Russell Cattelan [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: [OT] ICBM Long/Latt
Hi Leif, On 11-Feb-00 Leif Neland wrote: Sometime ago there was a thread regarding Longitude and Lattitude of committers etc, and a reference was made to a website, where the coordinates of any point on a map could be shown. However, I can't find this site now. Anybody? Leif I don't know of a site to do exactly what you're after but there's a nice map generator here; http://crusty.er.usgs.gov:80/mapit/ Or you could use the xearth port, you can use it to display points on a world map. I'm using a 3.2 machine ATM, and the port for that (I haven't updated it since installing 3.2) has the FreeBSD FTP sites, and the location of the core members. Perhaps now it contains more location files. Cheers, Kent Ibbetson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
In article [EMAIL PROTECTED], Leif Neland [EMAIL PROTECTED] wrote: Just FYI, a cvsup of ports over a single ISDN-line took 22 min on a soft-update'd disk. Something is seriously wrong over there then, because I can update my entire CVS repository in 1.5-2 minutes. And my Internet link is a wimpy 56 Kbit frame relay connection John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fw_enable
cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi
-nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf
-mpreferred-stack-boundary=2 vers.c
linking kernel
ip_input.o: In function `ip_input':
ip_input.o(.text+0x2d3): undefined reference to `fw_enable'
ip_output.o: In function `ip_output':
ip_output.o(.text+0x3d7): undefined reference to `fw_enable'
*** Error code 1
but i have no firewall configured, see appended config.
in /sys/netinet/ip_input.c, should the if (fw_en... be in one of those
#ifdefs?
#if defined(IPFILTER) || defined(IPFILTER_LKM)
/*
* Check if we want to allow this packet to be processed.
* Consider it to be bad if not.
*/
if (fr_checkp) {
struct mbuf*m1 = m;
if ((*fr_checkp)(ip, hlen, m-m_pkthdr.rcvif, 0, m1) || !m1)
return;
ip = mtod(m = m1, struct ip *);
}
#endif
if (fw_enable ip_fw_chk_ptr) {
#ifdef IPFIREWALL_FORWARD
/*
* If we've been forwarded from the output side, then
* skip the firewall a second time
*/
if (ip_fw_fwd_addr)
goto ours;
randy
#
# GENERIC -- Generic kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the handbook section on
# Kernel Configuration Files:
#
#http://www.freebsd.org/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.ORG/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ./LINT configuration file. If you are
# in doubt as to the purpose or necessity of a line, check first in LINT.
#
# $FreeBSD: src/sys/i386/conf/GENERIC,v 1.241 2000/02/04 07:02:53 jkh Exp $
machine i386
#cpuI386_CPU
#cpuI486_CPU
#cpuI586_CPU
cpu I686_CPU
ident RIP
maxusers96
#makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols
#optionsMATH_EMULATE#Support for x87 emulation
options INET#InterNETworking
options FFS #Berkeley Fast Filesystem
options FFS_ROOT#FFS usable as root device [keep this!]
options MFS #Memory Filesystem
#optionsMD_ROOT #MD is a potential root device
options NFS #Network Filesystem
#optionsNFS_ROOT#NFS usable as root device, NFS required
options MSDOSFS #MSDOS Filesystem
options CD9660 #ISO 9660 Filesystem
#optionsCD9660_ROOT #CD-ROM usable as root, CD9660 required
options PROCFS #Process filesystem
options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!]
options SCSI_DELAY=5000 #Delay (in ms) before probing SCSI
options UCONSOLE#Allow users to grab the console
options USERCONFIG #boot -c editor
options VISUAL_USERCONFIG #visual boot -c editor
options KTRACE #ktrace(1) support
options SYSVSHM #SYSV-style shared memory
options SYSVMSG #SYSV-style message queues
options SYSVSEM #SYSV-style semaphores
options P1003_1B#Posix P1003_1B real-time extentions
options _KPOSIX_PRIORITY_SCHEDULING
options ICMP_BANDLIM#Rate limit bad replies
# Soft updates is technique for improving file system speed and
# making abrupt shutdown less risky. It is not enabled by default due
# to copyright restraints on the code that implement it.
#
# Read ../../ufs/ffs/README.softupdates to learn what you need to
# do to enable this. ../../contrib/softupdates/README gives
# more details on how they actually work.
#
options SOFTUPDATES
options TCP_RESTRICT_RST
# To make an SMP kernel, the next two are needed
options SMP # Symmetric MultiProcessor Kernel
options APIC_IO # Symmetric (APIC) I/O
# Optionally these may need tweaked, (defaults shown):
options NCPU=2 # number of CPUs
options NBUS=4 # number of busses
options NAPIC=2 # number of IO APICs
options NINTR=24# number of INTs
device isa
#device eisa
Re: .gdbinit for kernel
On Fri, 11 Feb 2000, Greg Lehey wrote: On Thursday, 10 February 2000 at 23:28:14 -0500, Chuck Robey wrote: I was wondering if anyone had a .gdbinit that one could use, in remote debugging a kernel, that had a working kldstat in it? I found one in Greg's vinum directory, but it's a little broken here and there (although much of it does work). I want to invoke some of the ddb functions remotely, and be able to look at the module status. The .gdbinit.kernel in the vinum directory *should* work. If there's any problem with it, I'll try to fix it. What's the problem? When I try to do a kldstat, it tells me there's no file variable to set. It's too late now, I gotta go, but if you wait until I get home tomorrow, I'll give you the exact error. I'm doing remote debugging into another current box. I really appreciate the work you went to, to create that tool to begin with; it oughta be pointed to by some README, don't you think? Chuck Robey| Interests include C Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Thu, Feb 10, 2000 at 22:18:12 -0800, John Polstra wrote: In article [EMAIL PROTECTED], Leif Neland [EMAIL PROTECTED] wrote: Just FYI, a cvsup of ports over a single ISDN-line took 22 min on a soft-update'd disk. Something is seriously wrong over there then, because I can update my entire CVS repository in 1.5-2 minutes. And my Internet link is a wimpy 56 Kbit frame relay connection For me, located behind a 64Kbit ISDN connection (sppp), it takes 3min for the ports + 1min for src/crypto. Regards -- Udo Schweigert, Siemens AG | Voice : +49 89 636 42170 ZT IK 3, Siemens CERT| Fax: +49 89 636 41166 D-81730 Muenchen / Germany | email : [EMAIL PROTECTED] PGP-2/5 fingerprint | 2A 53 F6 A6 30 59 64 02 6B C4 E0 73 B2 C9 6C E7 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/ports/ too big?
On Thu, Feb 10, 2000 at 10:18:12PM -0800, John Polstra wrote: In article [EMAIL PROTECTED], Leif Neland [EMAIL PROTECTED] wrote: Just FYI, a cvsup of ports over a single ISDN-line took 22 min on a soft-update'd disk. Something is seriously wrong over there then, because I can update my entire CVS repository in 1.5-2 minutes. And my Internet link is a wimpy 56 Kbit frame relay connection Pretty much same results here... 3 mins approx on a 10Mb link this morning:-) /doc and www not counted/ The amount of data is largely dependent on how often you do the cvsup, of course. I do it every day... also it dependes on how loaded the cvsup server is. In Europe we have quite a lot of servers to choose from.:-) Regards: Szilveszter ADAM -- --- * Szilveszter ADAM * JATE Szeged * email: [EMAIL PROTECTED] * * Homepage : none * alternate email: [EMAIL PROTECTED] * * Finger [EMAIL PROTECTED] for PGP key. * * I prefer using the door instead of Windows(tm)... * To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: problems with voxware/snd0 kernel compilations..
$ grep -l '^mpu401' /sys/i386/isa/sound/*.c /sys/i386/isa/sound/mpu401.c $ grep '^i386/isa/sound/mpu401\.c' /sys/conf/files.i386 i386/isa/sound/mpu401.c optionalmpu i386/isa/sound/mpu401.c optionalsscape $ I guess css0 needs mpu0 to handle the onboard MPU401 interface. HTH, Eugene On Thu, 10 Feb 2000, f.johan.beisser wrote: | | i'm attempting to build a kernel with the "old style" voxware drivers for | the CS423x (crystal sound, or css0 in the kernel config) and i get this | wonderful error torwards the end of the kernel build: | | cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes | -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual | -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include | -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c | linking kernel | cs4232.o: In function `attach_cs4232': | cs4232.o(.text+0x1cb): undefined reference to `probe_mpu401' | cs4232.o(.text+0x1d8): undefined reference to `attach_mpu401' | *** Error code 1 | | | and it fails, obviously. everything prior to the make goes just fine.. | | any clues or advice? | | -- jan | | +-/ f. johan beisser /--+ | email: jan[at]caustic.org web: http://www.caustic.org/~jan |"knowledge is power. power corrupts. study hard, be evil." | | | | To Unsubscribe: send mail to [EMAIL PROTECTED] | with "unsubscribe freebsd-current" in the body of the message | -- Eugene M. Kim [EMAIL PROTECTED] "Is your music unpopular? Make it popular; make music which people like, or make people who like your music." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
