wdm 1.20 wont run on -CURRENT
I have seen this for about a month or two on more than one machine. xdm works fine. Rebuilds over some time have no effect. I have now built the world and wdm with -g and still have all the source and objects. Kernel config attached. What further info would you like ? And please give me some instructions on how to provide the non-obvious stuff. I tried to look with ports/devel/ddd but got stuck by the fact that the problem seems to be ld-elf.so.1 and not wdm. (gdb) core-file /wdm.core Core was generated by `wdm'. Program terminated with signal 10, Bus error. #0 0x2806010a in reloc_non_plt () from /usr/libexec/ld-elf.so.1 (gdb) All relevent ports have been rebuilt from scratch after the world build (including XFree86-4). /etc/make.conf: CFLAGS=-g -O -pipe COPTFLAGS=-g -O -pipe USA_RESIDENT=no XFREE86_VERSION=4 HAVE_MOTIF=yes WITH_MOTIF=yes WITH_PNG_MMX=yes WITH_GNOME=yes WITH_GTK=yes WITH_TK83=yes WITH_OGGVORBIS=yes WITH_SANE=yes A4=yes CVS_UPDATE=YES MASTER_SITE_GNOME=ftp://ftp.au.freebsd.org/pub/gnome/%SUBDIR%/ MASTER_SITE_GNU=ftp://ftp.au.freebsd.org/pub/gnu/%SUBDIR%/ MASTER_SITE_KDE=ftp://ftp.au.freebsd.org/pub/kde/%SUBDIR%/ MASTER_SITE_XEMACS=ftp://ftp.au.freebsd.org/pub/xemacs/%SUBDIR%/ MASTER_SITE_MOZILLA=ftp://ftp.planetmirror.com/pub/mozilla/%SUBDIR%/ KERNCONF=GENERIC # $FreeBSD: MATT,v 24.5 2002/02/06 20:03:00 +10:30 matt Exp $ # Based on: $FreeBSD: src/sys/i386/conf/NOTES,v 1.993 2002/01/27 01:00:16 jdp Exp $ machine i386 ident MATT maxusers0 # Only build Linux API modules and plus those parts of the sound system I need. #makeoptionsMODULES_OVERRIDE=linux sound/snd sound/pcm sound/driver/maestro3 #optionsKSTACK_PAGES=3 #number of 4k stack pages per process options INCLUDE_CONFIG_FILE #Include this file in kernel cpu I686_CPU options CPU_UPGRADE_HW_CACHE#Eliminate unneeded cache flush instructions # COMPATIBILITY OPTIONS options CPU_ENABLE_SSE options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SYSVSHM #SYSV style shared memory options SYSVSEM #SYSV style semaphores options SYSVMSG #SYSV style message queues # DEBUGGING OPTIONS options DDB #Enable the kernel debugger options UCONSOLE#Allow users to grab the console # NETWORKING OPTIONS options INET#Internet communications protocols # FILESYSTEM OPTIONS options UFS_DIRHASH #Speedup v. large dirs options FFS #Berkeley Fast Filesystem options NFSCLIENT #Network File System options NFSSERVER #Network File System options CD9660 #ISO 9660 Filesystem options MSDOSFS #MSDOS Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS#Pseudo-filesystem framework options SOFTUPDATES #Enable FFS soft updates support options SCSI_DELAY=300 #Delay (in ms) before probing SCSI options KTRACE #Kernel tracing (SYSV emul requirement) #optionsINVARIANTS #Sanity checking of internal structures #optionsINVARIANT_SUPPORT #Support modules built with INVARIANTS options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV#Install a CDEV entry in /dev options VFS_AIO #Real aio_* system calls options ENABLE_VFS_IOOPT#IO optimization through VM system when vfs.ioopt 0 options MSGBUF_SIZE=40960 #Size of the kernel message buffer options COMPAT_LINUX#Linux ABI emulation options LINPROCFS #Linux-like proc filesystem support device isa device pci device agp #Enable pci resources left off by a lazy BIOS: options PCI_ENABLE_IO_MODES options AUTO_EOI_1 #Save 0.7-1.25 usec for each interrupt # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk #ATA disk drives device atapicd #ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering # SCSI Controllers device sym #NCR/Symbios Logic (newer chipsets) # SCSI peripherals device scbus #SCSI bus (required) device da #Direct Access (disks) device sa #Sequential Access (tape etc) device cd #CD device pass#Passthrough device (direct SCSI access) device vga # splash screen/screen saver device splash # syscons is the default console
Re: Problems with psm probing twice.
Chris Faulhaber wrote: Commenting hints.psm.0.* and hint.atkbd.0.* from /boot/device.hints (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=84052+0+current/freebsd-current) works here. Anyone noticed there is no device.hints manual page ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: random reboots...
Alex Zepeda wrote: I haven't been able to track this down since the kernel won't panic.. but with more recent kernels I've noticed: * options NCP prevents the kernel from linking * midi panics the system right after bootup Me too Saw the NCP problem today at ctm-cvs-cur 7214. Saw the midi problem earlier but haven't put midi and seq in my kernels since then. /Me too To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Proposal to mergemaster
Brian Somers wrote: 3. Have a cvs-aware option. If the installed and new version numbers differ, mergemaster does a cvs diff -u -rINSTALLEDVERSION newversion | patch INSTALLEDFILE. If this works, everyone's happy. If not, it forces you to modify the new file 'till there are no bits in it. Yes yes yes. Many people using mergemaster have the Repo on hand at $CVSROOT so this should be an option if not the default (when $CVSROOT is defined). For those who dont I suppose a directory could keep the unmodified versions of the currently installed files that mergemaster updates. Or maybe the versions could be fetched from the web (from cvsweb ?) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAM(?) breaks r* and ftpd
Dmitry Valdov wrote: Hi! Try to make an .rhosts file and rlogin to fresh RELENG_4 or -CURRENT branch. rlogin -l dv xxx.xxx.xxx.xxx I saw the rlogin problem but somehow fixed it later my pam.conf was OK so I uncommented the ipv6 versions of the services in /etc/inetd.conf and that seemed to fix it. As I did this at work, I cant reproduce this now. This is on -CURRENT To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem with sio in -current ... possible cause of hangs?
The Hermit Hacker wrote: Morning all ... I'm trying to get my serial console to work on my desktop, and appear to be failing miserably at even just getting it to accept a 'getty' serial connection, let alone serial console ... It's not that hard as long as you stick to certain essentials: 1) Dont try to run at any speed other than 9600 unless your prepared to read the archives and maintain things bwteen builds. 2) Dont use the serial port for anything else, no getty, no mouse (if you dont have enough com ports because you have a serial modem and a serial mouse you should just get yourself a cheap PS/2 mouse). 3) Maybe add the following line to your kernel options BREAK_TO_DEBUGGER # A BREAK on a comconsole goes to DDB 4) Then just create /boot.conf containing just "-h" without the double quotes. Then you can easily turn it off by renaming that file. And yes there is no problem connecting it to another box and running something like minicom to use the console. Oh, you might want the grounds connected pin1 - pin1 but make sure the earth connections on your power outlets work or you'll get what I had once where my whole computer room (computers on a string of powerboards) was trying to earth itself through the signal ground to my wyse50 in the lounge room I didn't realise until I blew one of the serial ports on my old P90. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems compiling kern_mutex.c
The last couple of kernel builds (with cvs updates and buildworlds inbetween) have failed with messages as below. I assume I need to add something to my kernel config file so I have attached it. 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/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/../include -I/usr/src/sys/contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 /usr/src/sys/kern/kern_mutex.c /usr/src/sys/kern/kern_mutex.c:593: warning: no previous prototype for `_mtx_assert' /usr/src/sys/kern/kern_mutex.c: In function `_mtx_assert': /usr/src/sys/kern/kern_mutex.c:595: `MA_OWNED' undeclared (first use in this function) /usr/src/sys/kern/kern_mutex.c:595: (Each undeclared identifier is reported only once /usr/src/sys/kern/kern_mutex.c:595: for each function it appears in.) /usr/src/sys/kern/kern_mutex.c:596: `MA_RECURSED' undeclared (first use in this function) /usr/src/sys/kern/kern_mutex.c:597: `MA_NOTRECURSED' undeclared (first use in this function) /usr/src/sys/kern/kern_mutex.c:610: `MA_NOTOWNED' undeclared (first use in this function) /usr/src/sys/kern/kern_mutex.c:595: warning: unreachable code at beginning of switch statement *** Error code 1 /usr/src/UPDATING provides no insight. # $FreeBSD: MATT,v 22.8 2001/03/03 15:26:00 +10:30 matt Exp $ # Based on: $FreeBSD: src/sys/i386/conf/NOTES,v 1.899 2001/03/02 05:57:39 markm Exp $ machine i386 options INCLUDE_CONFIG_FILE # Include this file in kernel cpu I686_CPU ident MATT maxusers64 options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options MFS # Memory Filesystem options NFS # Network Filesystem options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem options DEVFS # Devices filesystem options SOFTUPDATES # Enable FFS soft updates support options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=300 # Delay (in ms) before probing SCSI options DDB # Enable the kernel debugger options KTRACE # Kernel tracing (SYSV emul requirement) options INVARIANT_SUPPORT # Support modules built with INVARIANTS options UCONSOLE# Allow users to grab the console options USERCONFIG # Boot -c editor options VISUAL_USERCONFIG # Visual boot -c editor options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options SHMALL=16384 options SHMMAXPGS=4096 options SHMMAX="(SHMMAXPGS*PAGE_SIZE+1)" options SHMSEG=50 options SHMMNI=64 options SEMMNI=32 options SEMMNS=128 # System V compatible message queues # Please note that the values provided here are used to test kernel # building. The defaults in the sources provide almost the same numbers. # MSGSSZ must be a power of 2 between 8 and 1024. options MSGMNB=2049 # Max number of chars in queue options MSGMNI=41 # Max number of message queue identifiers options MSGSEG=2049 # Max number of message segments options MSGSSZ=16 # Size of a message segment options MSGTQL=41 # Max number of messages in system options P1003_1B# Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# Install a CDEV entry in /dev options NCP # NetWare Core protocol options NWFS# Netware filesystem options VFS_AIO # Real aio_* system calls options ENABLE_VFS_IOOPT# IO optimization through VM system when vfs.ioopt 0 options MSGBUF_SIZE=40960 # Size of the kernel message buffer options COMPAT_LINUX# Linux ABI emulation options LINPROCFS # Linux-like proc filesystem support #optionsACCEPT_FILTER_DATA #optionsACCEPT_FILTER_HTTP # PECOFF module (Win32 Execution Format) #optionsPECOFF_SUPPORT #optionsPECOFF_DEBUG device isa device pci device agp options AUTO_EOI_1 # Save 0.7-1.25 usec for each interrupt # Floppy drives device fdc # ATA and ATAPI devices device ata
Re: resolver problem with shared linked programs
John Hay wrote:
I noticed that sendmail started to complain of a failed reverse lookup
when starting:
Feb 28 11:40:43 beast sendmail[276]:
gethostbyaddr(3ffe:2900:fffa:2:2a0:c9ff:fe8d:7c5f) failed: 2
At first I thought something is wrong with my ipv6 dns setup, but it turned
out that if a program is linked shared the first getipnodebyaddr() it does
will succeed, but the rest fail. For a staticly linked program all of
them will succeed:
So it's in -CURRENT too. -STABLE users have been complaining of a
similar problem since about the 20th/21st of Feb.
I was damned lucky that I skimmed:
http://www.mail-archive.com/freebsd-stable%40freebsd.org/
before I built a -STABLE system today.
I'm cross posting to stable so others can try your program.
And I wont install my -CURRENT buildworld.
#include sys/types.h
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
#include netdb.h
#include stdio.h
int main(int argc, char **argv)
{
struct hostent *he;
int h_err;
u_char ipnum[16];
char *astr1;
astr1 = "146.64.24.3";
h_err = inet_pton(AF_INET, astr1, ipnum);
if(h_err == 0) {
printf("conversion error with inet_pton()\n");
exit(1);
}
he = getipnodebyaddr(ipnum, 4, AF_INET, h_err);
if(he == NULL) {
printf("Oops: %d.\n", h_err);
herror("getipnodebyaddr");
} else
printf("And the answer is: %s\n", he-h_name);
he = getipnodebyaddr(ipnum, 4, AF_INET, h_err);
if(he == NULL) {
printf("Oops: %d.\n", h_err);
herror("getipnodebyaddr");
} else
printf("And the answer is: %s\n", he-h_name);
return 0;
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
find / -fstype local traverses non-local filesystems
rlogin olde sudo find / -fstype local -name UPDATING ls -l /usr/src/UPDATING -rw-r--r-- 1 me wheel 20477 Feb 18 21:48 /usr/src/UPDATING df Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/ad0s2a 198399 1506323189683%/ /dev/ad0s2e 2622211 1497532 91490362%/usr procfs 440 100%/proc linprocfs 440 100%/usr/compat/linux/proc /dev/ad0s1 1050164 428128 62203641%/C /dev/ad0s3a 20550421 1890638 0%/scratch /dev/acd0c647152 6471520 100%/cdrom new:/usr/ports 8024556 3265929 411666344%/usr/ports new:/usr/src 8024556 3265929 411666344%/usr/src new:/usr/obj 8024556 3265929 411666344%/usr/obj new:/usr/sup 8024556 3265929 411666344%/usr/sup This looks fine I know. The problem is that the find took forever and the disk on host new was thrashing away most of the time. find seems to be traversing all file systems (local and non-local) but just not reporting the found file when its on a non-local filesystem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
Sheldon Hearn wrote: On Sat, 13 Jan 2001 15:50:15 +1030, Matthew Thyer wrote: Then don't limit the size! :-) I dont. So what next ? Since I dont have much time for debugging FreeBSD, I stopped using mfs instead. This is a very simple problem -- you're running out of space. If you can't do anything about the amount of space used in /tmp, then either swap fills up or you limit the size of mfs. If you don't like either of those, use a separate partition for /tmp. But then you may as well use that partition as extra swap space and continue to mount /tmp in mfs. :-) Sheldon, I'm not stupid. At the time the message occurred I had less than 6 MB usage in /tmp if that. I have 128MB of RAM and 500MB swap. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
Sheldon Hearn wrote: On Fri, 12 Jan 2001 00:54:40 +1030, Matthew Thyer wrote: /boot/kernel/kernel: swap_pager_getswapspace: failed This seems to have started in the last week. I saw the same problem until I stopped using mfs on /tmp. Stop using mfs for /tmp. Are you sure it's not just /tmp "filling up" swap? If it's just that, all Edwin needs to do is limit the size of his MFS /tmp. I do this in /etc/fstab: /dev/ad0s1b /tmp mfs rw,-s=245760 0 0 See the description of the -s option in mount_mfs(8). Well, limits are nice if you can predict your usage in advance. In my case I was using an unlimited mfs (as I have for years): /dev/ad0s2b/tmpmfs rw 0 0 I seem to remember some changes to mfs a while ago and (without checking cvsweb) I assume that's when this: -s size The size of the file system in sectors. This value defaults to the size of the raw partition specified in special (in other words, newfs will use the entire partition for the file system). became the default behaviour. This seems a bit of a pain. Is there anyway to go back (if I'm correct) to a dynamic swap user. I suppose I'm talking about a real tmpfs ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
Sheldon Hearn wrote: On Fri, 12 Jan 2001 00:54:40 +1030, Matthew Thyer wrote: /boot/kernel/kernel: swap_pager_getswapspace: failed This seems to have started in the last week. I saw the same problem until I stopped using mfs on /tmp. Stop using mfs for /tmp. Are you sure it's not just /tmp "filling up" swap? If it's just that, all Edwin needs to do is limit the size of his MFS /tmp. I do this in /etc/fstab: /dev/ad0s1b /tmp mfs rw,-s=245760 0 0 See the description of the -s option in mount_mfs(8). Well, limits are nice if you can predict your usage in advance. In my case I was using an unlimited mfs (as I have for years): /dev/ad0s2b/tmpmfs rw 0 0 I seem to remember some changes to mfs a while ago and (without checking cvsweb) I assume that's when this: -s size The size of the file system in sectors. This value defaults to the size of the raw partition specified in special (in other words, newfs will use the entire partition for the file system). became the default behaviour. This seems a bit of a pain. Is there anyway to go back (if I'm correct) to dynamic usage of swap ? I suppose I'm talking about a real tmpfs ala Solaris. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sio serial console in -current?
Matthew Jacob wrote: Something wierd has been happening lately- the serial console on my i386 machine works fine up until init is forked.. THen the output is mangled, and one gets replicated and/or mangled stuff. On a reboot I'm getthing things like: Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped It's like the output is being repeated... Anyone seen same? My guess is you might be using PHK's syslog feature and be sending console output to the console ? (I haven't tried it tho). Check your syslog.conf (or disable syslogd and see what happens). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
Sheldon Hearn wrote: On Fri, 12 Jan 2001 22:01:03 +1030, Matthew Thyer wrote: This seems a bit of a pain. Is there anyway to go back (if I'm correct) to a dynamic swap user. I suppose I'm talking about a real tmpfs ? The way it is now is the way it's always been. Think about what you mean when you say "dynamic swap user". You want mfs to use more swap than you have? :-) No I want mfs to grow and shrink its filesystem dynamically. I never had these messages until recent changes in mfs but it will take me too much time to narrow it down as the message is hard to reproduce. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Data corruption whilst debugging sonar module of ports/graphics/xscreensaver-gtk-3.26 ?
Both of my main FreeBSD-CURRENT machines cant seem to run the sonar
module from xscreensaver-gtk-3.26 for very long. It crashes with a
SIGBUS on line 1654 of xscreensaver-3.26/hacks/sonar.c when the sonar
sweep gets back around to the first bogie that was ever displayed.
Since my home box is XFree 3.3.6 and work is XFree 4.0.2, I assume
this is a bug with the screensaver itself. Note both machines are
recent -CURRENT (within 1 week of today).
Today I had some spare time (wife and kids out of my hair) so I
installed ports/devel/ddd to have a look at whats going on.
To reproduce what I'm doing:
- Install ports/devel/ddd
- Set "CFLAGS=-g -pipe" in /etc/make.conf
- cd /usr/ports/x11/xscreensaver ; sudo make install
- Set your CFLAGS back to what they were
- cd /usr/ports/x11/xscreensaver/work/xscreensaver-3.26/hacks
- ddd
- File-Open Program... and choose "sonar"
- Run until it dies with the SIGBUS on line 1654 (subroutine "Sonar")
- Display "si", "*si", "*si-visable", all the "*si-visable{-next}*"
(e.g. "*si-visable-next", "*si-visable-next-next" etc) and
the local variables.
I'm seeing the local variable "bp" with a value of 0xd0d0d0d0.
I cant see how this happens when "bp" is initialised from
si-visable in the for loop at line 1647 and thereafter follows
the list (via -next) where no members have an address of 0xd0d0d0d0.
It seems that something in sonar.c is overwriting memory it shouldn't.
I haven't done much debugging since Uni, so I was wonderring if
others can reproduce this and does someone have some ideas how I
can easily detect this data corruption with ddd or is it a compiler
bug ? (I suspect not as it always happens when the sweep gets back
around to the first bogie ever displayed).
Does anyone recognise where 0xd0d0d0d0 may have come from ?
1635 static void
1636 Sonar(sonar_info *si, Bogie *bl)
1637 {
1638
1639 /* Local Variables */
1640
1641 Bogie *bp, *prev;
1642 int i;
1643
1644 /* Check for expired tagets and remove them from the visable list */
1645
1646 prev = NULL;
1647 for (bp = si-visable; bp != NULL; bp = bp-next) {
1648
1649 /*
1650 * Remove it from the visable list if it's expired or we have
1651 * a new target with the same name.
1652 */
1653
1654 bp-age ++;
1655
Thanks
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
Sheldon Hearn wrote: On Sat, 13 Jan 2001 01:46:46 +1030, Matthew Thyer wrote: The way it is now is the way it's always been. Think about what you mean when you say "dynamic swap user". You want mfs to use more swap than you have? :-) No I want mfs to grow and shrink its filesystem dynamically. Then don't limit the size! :-) I dont. So what next ? Since I dont have much time for debugging FreeBSD, I stopped using mfs instead. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Data corruption whilst debugging sonar module of ports/graph
Mike Heffner wrote: On 13-Jan-2001 Matthew Thyer wrote: | Does anyone recognise where 0xd0d0d0d0 may have come from ? | [snip] Read the "Tuning" section of malloc(3). 0xd0 is what allocated and deallocated memory is set to. xscreensaver is probably not initializing malloc()'d memory, and therefore it's left at 0xd0. A work around is to turn off this feature: ln -s aj /etc/malloc.conf however, xscreensaver should be fixed instead. Yes, that's what I'm trying to achieve. I thought it was "0xdeadcode" that got put in the malloc'd memory but if that's changed then thanks for the lead. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /boot/kernel/kernel: swap_pager_getswapspace: failed
Edwin Culp wrote: I am starting to get the following error. I've never seen it before and don't really understand why it should fail. Where should I start looking for the problem? /boot/kernel/kernel: swap_pager_getswapspace: failed This seems to have started in the last week. I saw the same problem until I stopped using mfs on /tmp. Stop using mfs for /tmp. P.S. you might want to add the following to /etc/rc.conf: clear_tmp_enable="YES" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Network performance-problem
Michael Class wrote: Hello, i am seeing a problem with 5.0-current (from 14.12.00) and a 3COM 3CCFE575CT Lancard (pc-cardbus) using the xl-driver. [snip] Why behaves my FreeBSD-machines worse then the other boxes? Any Ideas? Make sure you are running with the TCP/IP NewReno optimisation turned off. There are bugs in the TCP/IP NewReno code that result in bad packets and hence lots of retransmission with generally reduced network performance. I think its meant to be the default now in -CURRENT (to have NewReno off) but I'm not sure if PHK has disabled it yet. $ cat /usr/local/etc/rc.d/nonewreno.sh #!/bin/sh sysctl -w net.inet.tcp.newreno=0 echo -n " no_newreno" $ sysctl net.inet.tcp.newreno net.inet.tcp.newreno: 0 One day hopefully NewReno may be fixed as it sounded worthwhile. See Poul's messages in the freebsd-current archives. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: write(2) returns error saying read only filesystem when trying to write to a partition
"Daniel C. Sobral" wrote: Regardless /dev/da18s1 should work as for /dev/da18 [snip] No, and no. You misunderstand the problem. A disk on IBM PC compatible computers has the following format: I dont misunderstand the problem and I do know how disks are laid out under FreeBSD. I may not have expressed myself very well when I said "/dev/da18s1 should work as for /dev/da18" as I was referring to my in context discussion of "why cant I write to this device". My point is that I should be able to write to anything and do the damage that would result. Solaris and Compaq's Tru64 (the OS formerly know as DEC OSF/1) both allow me to destroy the UNIX disklabel by writing to the 'c' partition. I am of the opinion that FreeBSD should allow me to as well. The kernel has an in-memory copy of the disklabel so there shouldn't be a technical issue to stop me from doing so. -- Matthew Thyer Phone: +61 8 8259 7249 Science Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: write(2) returns error saying read only filesystem when trying to write to a partition
David O'Brien wrote: On Fri, Dec 08, 2000 at 01:44:47PM +1030, Matthew Thyer wrote: Regardless /dev/da18s1 should work as for /dev/da18 Correct me if I'm wrong, but /dev/da18s1 would only work if you installed a true slice vs. a dedicated configuaation of the disk something like ``disklabel da18 auto''. Back near the start of this thread I said I'd prepared the disk via: "fdisk -I da18" and then "disklabel -wr da18s1 auto". -- Matthew Thyer Phone: +61 8 8259 7249 Science Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Re: write(2) returns error saying read only filesystem when trying to write to a partition
I've been writing to the whole disk OK (since I changed to
/dev/da18), but now I am finding a problem with trying to
seek further into the disk before starting to write.
The code fragment is below and the "lseek(fd, 0L, SEEK_SET)"
works OK but the first "lseek(fd, 8192L, SEEK_CUR)" thereafter
fails with an "Undefined error: 0"
The only way I can get "lseek(fd, X, SEEK_CUR)" to work is where
X = 0.
Any ideas ?
if ( (fd = open("/dev/da18",O_WRONLY)) 0 ) {
perror("open");
exit(1);
}
/* write alternating 1s and zeros to disk */
for (i = 1; i = 5; i++) {
/* rewind to start file partition */
if (lseek(fd, 0L, SEEK_SET) != 0) {
perror("lseek seek_set");
exit(1);
}
count = 0L;
/* Now seek up to where we are up to: */
do {
if (lseek(fd, 8192L, SEEK_CUR) != 0) {
perror("lseek seek_cur");
exit(1);
} else ++count;
} while ( count 1062000 );
--
Matthew Thyer Phone: +61 8 8259 7249
Science Corporate Information Systems Fax:+61 8 8259 5537
Defence Science and Technology Organisation, Salisbury
PO Box 1500 Salisbury South Australia 5108
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: write(2) returns error saying read only filesystem when trying to write to a partition
CC: to -current as that's what I'm running.
"John W. De Boskey" wrote:
Hi,
I can't answer your questions directly, but you might want
to checkout the sources to newfs (/usr/src/sbin/newfs/newfs.c or
http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sbin/newfs/newfs.c?annotate=1.31
line 417).
I'll be glad to review your program if you would like.
I'm not after a review, I'd like FreeBSD-CURRENT fixed.
The program works on Compaq True64 UNIX v 4.0d
It also works on Solaris 7 (only tested sparc).
So it seems FreeBSD is broken here.
-john
[EMAIL PROTECTED]
- Matthew Thyer's Original Message -
Attached is scrub.c used to scrub a hard disk.
Examine the lines:
/* if ( (fd = open("/dev/da12s1c",O_RDWR)) 0 ) { */
if ( (fd = open("/mnt/foo",O_RDWR)) 0 ) {
If I newfs the 'a' partition of da12s1 (a is the same as 'c'), mount
it as /mnt, touch the file foo and then run the program it works fine.
If instead I open the c partition (as in the commented out line),
the open succeeds, the lseek succeeds but the writes fail with an
error saying read only filesystem.
Why ??
I want to scrub the whole disk, not just write to a file.
--
Matthew Thyer Phone: +61 8 8259 7249
Science Corporate Information Systems Fax:+61 8 8259 5537
Defence Science and Technology Organisation, Salisbury
PO Box 1500 Salisbury South Australia 5108
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include sys/uio.h
#include unistd.h
#define BUFSIZE 8192
main()
{
/* program to write 1's and 0's to disk */
off_t result;
long int i;
long int nwrite;
long int count;
int passes;
int fd;
char buf0[BUFSIZE], buf1[BUFSIZE];
/* initialize write buffers */
for (i=0; i BUFSIZE; i++) {
buf0[i] = 0;
buf1[i] = 1;
}
/*if ( (fd = open("/dev/da12s1c",O_RDWR)) 0 ) { */
if ( (fd = open("/mnt/foo",O_RDWR)) 0 ) {
perror("open");
exit(1);
}
/* write alternating 1s and zeros to disk */
for (i = 1; i = 5; i++) {
/* rewind to start file partition */
if ((result = lseek(fd, 0L, SEEK_SET)) != 0) {
perror("lseek");
exit(1);
}
count = 0L;
do {
if ( (nwrite = write(fd, buf0, BUFSIZE)) != BUFSIZE) {
printf("wrote last %ld bytes to disk\n",nwrite);
printf("Total bytes written were %ld bytes\n",
BUFSIZE*count + nwrite);
perror("write");
}
else {
++count;
if ( count % 1000 == 0)
printf("overwrote %ld bytes w/ 0s\n",
BUFSIZE*count);
}
} while ( nwrite == BUFSIZE nwrite 0 );
/* rewind to start file partition */
if ((result = lseek(fd, 0L, SEEK_SET)) != 0) {
perror("lseek");
exit(1);
}
count = 0L;
do {
if ( (nwrite = write(fd, buf1, BUFSIZE)) != BUFSIZE) {
printf("wrote last %ld bytes to disk\n",nwrite);
printf("Total bytes written were %ld bytes\n",
BUFSIZE*count + nwrite);
perror("write");
}
else {
++count;
if ( count % 1000 == 0)
printf("overwrote %ld bytes w/ 1s\n",
BUFSIZE*count);
}
} while ( nwrite == BUFSIZE nwrite 0 );
printf("Pass %d complete\n",i);
}
printf("All passes complete\n");
}
--
Matthew Thyer Phone: +61 8 8259 7249
Science Corporate Information Systems Fax:+61 8 8259 5537
Defence Science and Technology Organisation, Salisbury
PO Box 1500 Salisbury South Australia 5108
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: write(2) returns error saying read only filesystem when trying to write to a partition
Mike Smith wrote: The program works on Compaq True64 UNIX v 4.0d It also works on Solaris 7 (only tested sparc). So it seems FreeBSD is broken here. FreeBSD just behaves differently. If you want to write to the whole disk, open the whole-disk device, not the 'c' partition. Thanks Mike, /dev/da18 works fine for me although I notice that /dev/da18s1 does not. There seems to be some inconcistencies in this area. Please tell me (and for the benefit of the list) as to why I cant use /dev/da18s1c ? Note that the disk has been set up with "fdisk -I da18" and then "disklabel -wr da18s1". -- Matthew Thyer Phone: +61 8 8259 7249 Science Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: write(2) returns error saying read only filesystem when trying to write to a partition
Mike Smith wrote: Mike Smith wrote: The program works on Compaq True64 UNIX v 4.0d It also works on Solaris 7 (only tested sparc). So it seems FreeBSD is broken here. FreeBSD just behaves differently. If you want to write to the whole disk, open the whole-disk device, not the 'c' partition. Thanks Mike, /dev/da18 works fine for me although I notice that /dev/da18s1 does not. There seems to be some inconcistencies in this area. That would be something of an understatement... Please tell me (and for the benefit of the list) as to why I cant use /dev/da18s1c ? The 'c' device won't let you overwrite the beginning of the slice/disk, since that's where the partition information is kept. In the grand tradition of being allowed to shoot yourself in the foot, I would like to be able to do such things as this is clearly what I intend. Since we dont normally hold peoples hands for other things, why cant we allow big holes in my feet for this too ? Regardless /dev/da18s1 should work as for /dev/da18 I know... send patches... unfortunately my day job hasn't seen the light yet so I cant work on FreeBSD at work. -- Matthew Thyer Phone: +61 8 8259 7249 Science Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
You should be running -STABLE (Was: Re: interesting problem)
Tony Johnson wrote: Since I am complaining then I need to figure out what U have done to make 5.0-CURRENT crash?? Well atleast U admit that U do not know and U do not care. So anyone who is using FreeBSD should also not care?? This is more screwed up then I thought and people @FreeBSD have made this much harder then necessary. Learn the lesson now and save us all from reading your messages in the future. First: If you run FreeBSD-CURRENT, you must take the time to read at least 2 mailing lists being freebsd-current and cvs-all. I'd recommend archiving them as well and definitely have your own source repo. Second: Dont try to antagonise the list. Do you think that everyone is actually aiming to produce a broken by design system ? Third: Investigate you own problem. If you can fix it you have provided a service to others who have the same hardware. You may have to spend time doing a search of your email to identify the likely commit that caused your problem... keep release CD's around for quick testing of boot floppies. Keep a source repo so you can checkout kernel floppies from around the exact change to the GENERIC kernel that broke your system. There should never be time deadlines on you doing this because YOU SHOULD NOT USE -CURRENT FOR A PRODUCTION SYSTEM. It really doesn't take long for new technologies like softupdates, ACPI, ATA-100 to get into the -STABLE stream and then into a release. FreeBSD is a volunteer project with a development model that lets anyone 'listen in' on whats happening at the head of the development tree. If you are prepared to use the head of the tree, you do need to fix your own problems or at least provide the list with an exhaustive list of your configuration and the behaviour you see under everything you've tried (removing hardware, changing cards, flashing BIOS, hacking CODE! yes you can do this too!). If you dont have time to do this, run -STABLE or the last release. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CURRENT kernel make depend fails in sn module
Just synced my repo with cvsup4 and find that make depend fails. This is after "config -r MATT". "make includes" in /usr/src doesn't fix it either. === sn @ - /usr/src/sys machine - /usr/src/sys/i386/include perl @/kern/makeobjops.pl -h @/kern/device_if.m perl @/kern/makeobjops.pl -h @/kern/bus_if.m perl @/kern/makeobjops.pl -h @/isa/isa_if.m rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../include -I/usr/include /usr/src/sys/modules/sn/../../dev/sn/if_sn.c /usr/src/sys/modules/sn/../../dev/sn/if_sn_isa.c /usr/src/sys/modules/sn/../../dev/sn/if_sn_pccard.c /usr/src/sys/modules/sn/../../dev/sn/if_sn_pccard.c:60: card_if.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/sn. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/src/sys/compile/MATT. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT kernel make depend fails in sn module
Matthew Thyer wrote: mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../include -I/usr/include /usr/src/sys/modules/sn/../../dev/sn/if_sn.c /usr/src/sys/modules/sn/../../dev/sn/if_sn_isa.c /usr/src/sys/modules/sn/../../dev/sn/if_sn_pccard.c /usr/src/sys/modules/sn/../../dev/sn/if_sn_pccard.c:60: card_if.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/sys/modules/sn. Warner's fixed this so update again To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FIXIT problems with /dev
Kent Hauser wrote: Hi All, I just did something foolhardy -- and yet instructive. Pls let me relate. Longish story about MAKEDEV limitations.. I suggest you become familiar with the chroot command. Regards, Kent To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Oddities with the new binutils
Repost of old mail now that I've made my ISP register their mail relays (which took three months for them to understand!). I know this is ancient but being in the archives may help someone. It was a kernel problem. I made a new kernel from sources of about 8 hours ago and the problem has dissappeared from my home machine (have to wait until after the long weekend [- in Oz] to test the work machine). It seems that something in the May 29th kernel was causing problems for X. Matthew Thyer wrote: It may not be FP itself. In fact I have seen some other strange graphic corruption at home when running xplanet in the background and xanim. When the planet turns, the top 20 or so rows of the root window get corrupted with some of the image of the currently playing animation in xanim. I haven't mentioned this yet because I've only been running xplanet since post-binutils so I cant compare it with previous behaviour. It would appear to be an Xserver problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/usr/local/etc/rc.d and /etc/rc.d
[I know this was discussed a couple of months ago but since nothings
been committed yet I throw in my 3 month old email that I haven't
been able to send due to my stupid ISP with unregistered mail relays]
Please read as I have done a fair bit of thinking on this matter as
the sysadmin of many commercial UNIX systems (SunOS, Solaris, IRIX,
HP-UX, True64) plus FreeBSD and Linux (we'll just call it UNIX even
though that's debatable). [NOTE I'm 750 behind on my cvs-all mail so
dont hassle me as I haven't read this thread yet but feel the need to
respond before we end up with some wierd non backward compatible
system that's totally different from common UNIX systems].
I would like to see startup and shutdown scripts exist in a single
directory ("/usr/local/etc/rc.d/" for ports and eventually
"/etc/rc.d" when the system migrates to the same scheme).
The startup and shutdown functionality would be in the same script
and the scripts should be named starting with a capital 'S' for
startup and a capital 'K' for shutdown (I'm also keen on the HPUX
startmsg and stopmsg one liners).
There's no need for the seperate SYSV init.d directory as scripts
will be off if they dont start with the right naming convention.
As for runlevels... thats not BSD and I dont know any SYSV admin
who uses them (I dont count the RedHat hack to turn on X).
The scripts will be differentiated from existing scripts (the old
system) as the new system will only act on scripts that have a digit
in the second character of their name (there could be a backward
compatability process to act on all the others afterwards which
would be disabled by default... presumably "disabled.S99rc.compat"
or some such name).
Stop scripts will be a symbolic link to their startup script
counterpart (and would simply not be executed if the K* file doesn't
exist). Symbolic links make it clear they are the same script.
Scripts would be executed in alphabetical order (after the S or K)
so the sysadmin has control over the execution order which is
important.
Scripts would source common functions from a system file so we have
control over future changes in functionality/reporting. This would
also make the template script very simple.
Eventually I would like the system to migrate to such a scheme but
maintain the backward compatibility scripts /etc/netstart which
could be implemented either by simply 'knowing' which rc scripts
do network functionality or by reserving a range of numbers for
network startup --- HACK!
I'd really like the system to allow stuff like "/etc/rc.d/S84named
reread" (or "restart", "reload" whatever is acceptable).
I'd also really like at least named and perl to be removed from the
base system but that's another thread.
One of the big turn offs to FreeBSD in the System V world is:
"What!, why do I need to know which signal to send blah to reload
it ?".
The backward compatibilty hack script in "/usr/local/etc/rc.d/"
would ignore files starting with "README" and "disabled" (and
maybe other typical disabling naming methods).
This is not too much of a hack as the backward compatibility
script would go away in a release or two.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Please consider some cosmetic changes in boot messages
Anyone else noticed how FreeBSD is inconsistent with the use of words like "Doing", "setting" and "starting" in the boot messages ? For instance, I think the following fragment of my boot should change from: Additional routing options: tcp extensions=NO TCP keepalive=YES. routing daemons:. Mounting NFS file systems. additional daemons: syslogd. checking for core dump...savecore: no core dump Doing additional network setup: portmap. Starting final network daemons: mountd nfsd rpc.statd nfsiod NFS access cache ti me=2. setting ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib setting a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout starting standard daemons: inetd cron usbd. Initial rc.i386 initialization: apm apmd. rc.i386 configuring syscons: font8x16 font8x14 font8x8 blank_time allscreens. additional ABI support:. Local package initialization: fkeys SETI@home xfstt. Additional TCP options:. To: (I've put * against the changed lines) Additional routing options: tcp extensions=NO TCP keepalive=YES. routing daemons:. Mounting NFS file systems. additional daemons: syslogd. checking for core dump...savecore: no core dump * additional network setup: portmap. * final network daemons: mountd nfsd rpc.statd nfsiod NFS access cache time=2. * ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib * a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout * standard daemons: inetd cron usbd. * rc.i386 initialization: apm apmd. rc.i386 configuring syscons: font8x16 font8x14 font8x8 blank_time allscreens. additional ABI support:. Local package initialization: fkeys SETI@home xfstt. Additional TCP options:. And finally, for filesystems with = 10^6 blocks free, the fsck -p output (second line) hits exactly 80 chars which makes syscons leave a blank line before the next line of output. Call me pedantic but could we change the word "fragmentation" to "fragmented" to give room for many more blocks in the filesystem before wrapping. I'm sure the answer is no due to histerical raisins but its worth a try ;) /dev/ad0s2e: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s2e: clean, 5929804 free (2252 frags, 740944 blocks, 0.0% fragmentation) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
Replying to my own message. In summary, the main things the scheme I describe gives us are: - control over startup/shutdown order with the numbers - accomodates older scripts (by just not having the K script linked to the S, script things wont be started again at shutdown time). - enough similarity to SYSV to not confuse - ability to easily disable scripts (rename to not start with S[0-9] or K[0-9]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
Neil Blakey-Milner wrote: On Fri 2000-09-08 (22:53), Matthew Thyer wrote: The startup and shutdown functionality would be in the same script and the scripts should be named starting with a capital 'S' for startup and a capital 'K' for shutdown (I'm also keen on the HPUX startmsg and stopmsg one liners). Why not just use chmod +x or chmod -x, like we do already? This means not having to rename things. You could do either with my scheme. Stop scripts will be a symbolic link to their startup script counterpart (and would simply not be executed if the K* file doesn't exist). Symbolic links make it clear they are the same script. I don't see the point. The point is that people are worried about scripts that aren't aware of the "start" and "stop" argument trying to start apps again at shutdown time. With my scheme, the script wont be executed at shutdown time if the K* script doesn't exist. Scripts would be executed in alphabetical order (after the S or K) so the sysadmin has control over the execution order which is important. I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at http://people.FreeBSD.org/~eivind/newrc.tar.gz) I haven't looked at this yet but off the top of my head, a dependency based system sounds overly complicated (consider ports authors) and unecessarily different from other systems. I'd also really like at least named and perl to be removed from the base system but that's another thread. I'll comment when you bring it up. Warning: perl is necessary for kernel builds. I know but I'm pretty keen on awk and would like all the perl dependencies to be re-written with awk or other tools as I dislike FreeBSD being dependent on such a beast as perl which should only exist as a port. Just look at the pain of getting perl 5.6.0 into the system. I know the perl lovers will hate me but I thinks its worth having some ugly awk to get away from elegant perl being required in the base system. I'd go further to say that the whole base OS needs to be more modularised ala Solaris and Linux especially since we dont have an established binary patch process. Its pretty hard to sell FreeBSD to my work masters when the only patch method is source code patches or a complete rebuild of -STABLE or just wait until the next release. A more modular system could be upgraded more easily. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] Matthew Thyer who needs a new .sig To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
Neil Blakey-Milner wrote: On Sat 2000-09-09 (00:05), Matthew Thyer wrote: The point is that people are worried about scripts that aren't aware of the "start" and "stop" argument trying to start apps again at shutdown time. With my scheme, the script wont be executed at shutdown time if the K* script doesn't exist. If it's there, it gets executed. If it's there, it was put there. If it was put there, it'll have support for "start" and "stop". If an administrator puts a script in there that does the wrong thing, that's his fault. He could use the fall-back rc.local method. We needn't support stupid behaviour by complicating the matter. I'm behind on cvs-all and freebsd-current so forgive me but I'm basing my comments on rc.shutdown executing /usr/local/etc/rc.d/* with argument "stop". Which seems very dangerous given that people may not have rebuilt their ports for a long time. With my way the old scripts may not even be run until the admin reads up on the new scheme. # before zope # before apache # after networking # after nfs is much better than: S10.networking.sh S20.nfs.sh S40.zope.sh S45.apache.sh and then figuring to use S43.foo.sh. We'll have to disagree on this point. Given that we've had no order control in the past and that ports are generally (yes its bad to generalise) not dependent on each other, should the situation arise I think that any admin worth his/her pay can work out how to change the order with the numbers. Remember that I'm trying to stay remotely compatible with other systems. We dont have to re-invent the wheel. I still think a dependency based system is way more complicated than what is required. I'm not particularly attached to perl, but it has a convenience in some sections, like ports, that is unmatched by sed and awk. Note the excessive use of "perl -i -pe 's/foo/bar/'" for in-place substitution. I've asked on at least two occasions for a simple, easy-to-use, thing to do it without doing a two-liner that copies to another file, and then replaces the old file with the new file. My point is that its worth some ugly awk and sed to get away from the base OS depending on perl. I dont care how elegant perl is. Thats about all I'll say on this thread got to sleep. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
Don Lewis wrote: On Sep 9, 12:05am, Matthew Thyer wrote: } Subject: Re: /usr/local/etc/rc.d and /etc/rc.d } Neil Blakey-Milner wrote: } I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at } http://people.FreeBSD.org/~eivind/newrc.tar.gz) How does this compare with what NetBSD implemented? } I haven't looked at this yet but off the top of my head, a dependency } based system sounds overly complicated (consider ports authors) and } unecessarily different from other systems. NetBSD switched to a dependency based system a while back. Judging by the traffic on their mail lists, it was somewhat controversial ... I'd consider it overly complicated because: - The OS vendor can work out the correct order for system component startup and set the numbers right once per release so who needs the overhead and complexity of a dependency based system ? - The ports collection is so huge these days that we need to make it easier rather than harder for non-hardcore FreeBSD users to submit and maintain their own ports. Its already hard enough to do a port right especially if it should have ifdefs on the version of FreeBSD to work correctly in -STABLE and -CURRENT. Port authors really need -CURRENT and -STABLE installed and maintain a copy of the repository to DTRT. - The SysV style number based system is fine in that port authors can all use the same number (say S50myport) unless it needs to be changed due to the unlikely need for ordering (remember we haven't had ordering to date and there are ~3700 ports). - Dont think of /usr/local/etc/rc.d being just for the ports collection, people will put there own startup scripts there too and will find it very easy to just pick the right numbers ala SysV. I do admin SysV systems of all types (mainly Solaris, HPUX, IRIX, True64 - yes I work for Defence) as my paid job so I know how easy the number order system is to use. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
I thought I told you not to send a test message
Why have you annoyed many hundreds of people with your test message which I told you was not necessary to send ? I clearly described the simple problem of your organisation using email relay servers which were not registered in the DNS causing many weeks of problems for me. Not only have you annoyed many people but you have sent email using my sending address instead of your own address for a test which was not necessary. I am extremely unimpressed with the performance of your organisation and the incompetant manner that this simple problem has been handled. It would be within my rights to take legal action against your organisation. Please have someone contact me as soon as possible to discuss the way your organisation should repay me for the more than 2 months of inconvienience and suffering I have endured. To the FreeBSD-current list subscribers, I hope you accept that I did not send that stupid test message and also be advised that the Australian operations of UU.net and Access One take about 2 months to even understand a simple DNS problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA66 support
Soren Schmidt wrote: It seems Andreas Klemm wrote: ad4: 39082MB Maxtor 54098U8 [79406/16/63] at ata2-master using UDMA33 AHA! try swap that with a known good drive (ie non Maxtor/WD) if you can Are there plans to try to support this broken hardware ? Maxtor seem to be violating ATAPI standards in that FreeBSD and Linux cannot use many Maxtor drives at rated speed, however. Maxtor has some extremely fast drives that `work' in WinTel machines faster than all other competitors using ATA66 (as of a month or so ago) so it appears they are cutting corners on the standard (cheating) in order to produce a very fast product. Are there plans to accomodate their behavior ? Do you have any contacts in Maxtor to help in this task ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Matthew Thyer (who doesn't send useless test mail to mailing lists) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Oddities with the new binutils
"-O -pipe" is all I use for kernel and world builds. The kernel config file from my work box is attached. I have never built gcc from ports. I always use "config -r" when building kernels. I dont use modules as I have everything I need in my kernel including COMPAT_LINUX. And as I said before I removed all ports so that my testing is with XFree86, xaos and any supporting libraries all compiled after my world and kernel build. Did you do something similar ? I am using XFree86 3.3.6 on both machines. If it comes down to particular video cards, My work machine has: VESA: v1.2, 2048k memory, flags:0x0, mode table:0xc00c09da (c9da) VESA: S3 Incorporated. Trio64V+ My home machine has a "3dfx Velocity 100 AGP with 8MB SGRAM" which is detected as a Voodoo 3 by the VESA code. Martin Cracauer wrote: In [EMAIL PROTECTED], Martin Cracauer wrote: In [EMAIL PROTECTED], David O'Brien wrote: On Fri, Jun 02, 2000 at 04:42:29PM +0930, Matthew Thyer wrote: Three issues: - floating point math doesn't seem to work properly: I don't have a -current machine I want to delete all ports from, but I have a -current from yesterday, I compiled xaos on it and libpng, which is the only dependency of xaos. That leave XFree as the only non-recompiled thing in the chain. Works fine. OK, now I am pissed. I also recompiled and restarted X11 to trace this down, only to find that some stupid error in Xwrapper breaks xinit and I had to roll my own xinit. Anyway, now I am running everything in the pipe compiled within the last 24 hours on a fresh -current and xaos work just fine. It could also be poorly written ASM code in the things you were running. The old Binutils let people write inconsistent and illegal ASM. xoas and png themself do not have assembler files. Xfree servers have some, but not in floating point related things. Where is the information that this is a floating-point problem from? Matthew, do you possibly use a custom gcc from /usr/local/bin and the native assembler or vice versa? Also, what level of optimization do you use? Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ -- Matthew Thyer Phone: +61 8 8259 7249 Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 # $FreeBSD: FUZZ,v 5.5 2000/05/30 10:59:00 +09:30 thyerm Exp $ # based on $FreeBSD: src/sys/i386/conf/LINT,v 1.775 2000/05/22 15:00:40 dan Exp $ machine i386 ident "FUZZ" maxusers64 options INCLUDE_CONFIG_FILE # Include this file in kernel cpu I686_CPU options CPU_FASTER_5X86_FPU options NO_F00F_HACK # COMPATIBILITY OPTIONS options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options USER_LDT# Let processes manipulate their local descriptor table (needed for WINE) options SYSVSHM # Enable SYSV style shared memory options SYSVSEM # Enable SYSV style semaphores options SYSVMSG # Enable SYSV style message queues options SHM_PHYS_BACKED options SHMALL=16384 options SHMMAXPGS=4096 options SHMMAX="(SHMMAXPGS*PAGE_SIZE+1)" options SHMSEG=50 options SHMMNI=64 options SEMMNI=32 options SEMMNS=128 # DEBUGGING OPTIONS #optionsDDB # Enable the kernel debugger options KTRACE # kernel tracing (SVR4 emul needs this) options UCONSOLE# Allow users to grab the console options USERCONFIG # boot -c editor options VISUAL_USERCONFIG # visual boot -c editor # NETWORKING OPTIONS options INET# Internet communications protocols # Network interfaces: pseudo-device ether # Generic Ethernet pseudo-device loop# Network loopback device #pseudo-device tun # Tunnel driver (user ppp requirement) # FILESYSTEM OPTIONS options FFS # Berkeley Fast Filesystem options FFS_ROOT# FFS usable as root device options NFS # Network Filesystem options MFS # Memory Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process Filesystem options MSDOSFS # MSDOS Filesystem options NSWAPDEV=4 # Allow this many swap-devices options SOFTUPDATES # Allow FFS to use Softupdates tech options
Re: Oddities with the new binutils
David, I emailed my details on what I have done on two machines that are exhibiting this problem. Because these machines are different in their hardware and have not expressed the problem in the past, I dont think its a hardware issue. Before the new binutils both machines did not have this problem. I dont know if it is the binutils change that has caused this problem as I do not have the time to exhaustively test. My email was to try to get others to reproduce the problem hence I gave details on what I did. So, has anyone done the procedure I have and seen or not seen the problem where xaos version 3.0 draws garbage when renderring. (run xaos and press the 'a' key). I haven't given kernel config files or hardware details because I dont think its relevant until someone can say "I have done the steps you have outlined and I dont see you problem". I do not have time to debug this myself (I would also need to learn a few things) however, I have been running -CURRENT for more than 5 years and know that I have upgraded my software correctly and am fairly convinced that hardware is not an issue so I am reporting this problem to see if others can reproduce it as a service to the FreeBSD community (I wont even charge for it!). I also do not intend to report this to the binutils maintainers because it may be a FreeBSD issue, not a binutils issue. David O'Brien wrote: On Mon, Jun 05, 2000 at 10:24:24AM +0930, Matthew Thyer wrote: Has anyone tried the specific instructions I gave to reproduce the problem ? These instructions do things at too high a level. i.e.: - make world - making and installing a new kernel - mergemaster - reboot All fine. - deletion of ALL installed ports - recompile of every essential port (inc XFree 3.3.6) This doesn't give me anything to debug. I need to know a specific source file. Sending this bug report plus instructions to reproduce to the Binutils maintainers will get no where. -- -- David ([EMAIL PROTECTED]) -- Matthew Thyer Phone: +61 8 8259 7249 Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Oddities with the new binutils
Has anyone tried the specific instructions I gave to reproduce the problem ? i.e.: - make world - making and installing a new kernel - mergemaster - reboot - deletion of ALL installed ports - recompile of every essential port (inc XFree 3.3.6) Then: Build xaos from ports (/usr/ports/graphics/xaos) Run xaos and press 'a' David O'Brien wrote: On Fri, Jun 02, 2000 at 04:42:29PM +0930, Matthew Thyer wrote: Three issues: - floating point math doesn't seem to work properly: - backward compatibility: - stability: Are others seeing these issues? These issues make me think that the new binutils is not yet ready for -STABLE. It could also be poorly written ASM code in the things you were running. The old Binutils let people write inconsistent and illegal ASM. -- -- David ([EMAIL PROTECTED]) -- Matthew Thyer Phone: +61 8 8259 7249 Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Oddities with the new binutils
Three issues: - floating point math doesn't seem to work properly: To reproduce: Build xaos from ports (/usr/ports/graphics/xaos) Run xaos and press 'a' - enjoy the show but I dont think its what the author intended. I have reproduced this on two machines which are running -CURRENT as of around May 29th - 30th with the new binutils. Both machines were upgraded by: - make world - making and installing a new kernel - mergemaster - reboot - deletion of ALL installed ports - recompile of every essential port (inc XFree 3.3.6) One machine has its source populated by cvsup from cvsup4, the other by cvsup from my own cvsup server whos repository is populated by ctm-cvs-cur delta so I dont think there are any problems with my source tree. - backward compatibility: Before I deleted all ported software on my home machine (cvsup's from cvsup4) I ran wdm and Window maker and saw lots of problems with font rendering into wrong locations, menus not being displayed properly and icons being placed in incorrect locations (not actually icons but the launching thingies!). I'm not complaining but rather reporting so that people can bump appropriate FreeBSD version numbers..., update UPDATING etc if required or if there are not meant to be any issues then work out why there are. - stability: Windowmaker at home dumps core whenever I log out (it never used to do this before the new binutils with the exact same version of Windowmaker). I haven't noticed other stability problems yet. These issues make me think that the new binutils is not yet ready for -STABLE. -- Matthew Thyer Phone: +61 8 8259 7249 Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
Try flags 0x04 on device psm. This undocumented option fixed my PS/2 IntelliMouse clone that has a wheel (which is also the center button). Bug Kazu as to why this isn't documented in LINT. "Jordan K. Hubbard" wrote: No, I don't mean rodents who've nibbled on chocolate-covered expresso beans, I mean PS/2 mice which fall victim to this new problem: May 19 00:50:45 zippy /kernel: psmintr: out of sync (00c0 != ). I've seen it for the last few weeks and can only think that something must be stomping on the psm driver now (or the driver is missing interrupts for reasons of its own). Anyone else seeing this? - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: port/XFree86-4 make install fail.
Idea Receiver wrote: On Thu, 16 Mar 2000, Jean-Marc Zucconi wrote: Idea Receiver writes: "make all" success without any problem. There was an error but "make all" always complete. however, make install fail ;( What are your CFLAGS in /etc/make.conf ? default only. CFLAG= -O -pipe I have no problem of installing XFree-4.0 binary. Just not from ports/x11/XFree-4:( I had no problem. I tend to uninstall anything that uses X, build install new X and then build new apps. It doesnt take that long. This is all using ports with CFLAG= -O -pipe -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BP6 (Was Re: Success with ATA drivers and UDMA66)
I know your talking SMP but thought you'd like to know some temps for UP systems as well... I have a Celeron 300a that I overclock to 464 MHz (100 MHz FSB + extra turbo frequency boost) running at 2.1 v and it runs at about 30 degrees celcius when idle and at 52 degrees when running setiathome (was 50 degrees in winter). A friend of mine running an ISP on FreeBSD has alarms set at 53 degrees (and they haven't gone off unless there has been a problem to date). A friend of above friend (in Sydney) has all his machines running quite reliably at 96 degrees (yes celcius). His alarms dont go off until 104! I dont think he has any airconditioning in his machine room. I cant speak for what the other peoples hardware is but it appears that the Intel CPUs can take quite a beating I wouldn't be worried until you hit at least 65 degrees. On Wed, 22 Dec 1999, Thierry Herbelot wrote: "Dave J. Boers" wrote: On Tue, Dec 21, 1999 at 11:22:12PM +0100, Thierry Herbelot wrote: Let's start a thread on the BP6 ? (the release of the board was carefully synchronized with stable SMP releases of FreeBSD : kudos to the FreeBSD release engineering team ;-)) I second that! Running -current since October and never had a serious SMP problem. I was not really serious, but the nearly simultaneous release of a "stable" SMP FreeBSD and a very inexpensive Dual MoBo was a very pleasant surprise. [SNIP] I think the PS is pressed to its limits because if I add just one more drive (5400 RPM IDE disk) it's over the edge. Those Celeron's must be eating lot's of power (they are 400 Mhz ones running at 75 Mhz bus speed). Is it possible to directly boot from the HPT-366 controller ? (I know the BIOS is ok, but is there any problem with the new ata driver ?) I'm doing it currently. Very fine [SNIP] I would like to know how HOT other people's processors get. In the stationary situation I have a system core (= processor average) temperature of 46 and a case temperature of 50 degrees Celcius/Centigrade. What do you use for temp. watching ? (I fetched a little hack which is called wmtempmon). My temps are somewhat lower : around 35/36 °C, as I've installed "Alpha" coolers, bought from www.3dfx.com. One colleague at work uses the same sink/fan combo, but with peltier and a monstrous PSU to get to 572MHz. I've also loaded the latest BIOS from Abit. TfH Don't ask why case temperature is higher than core temperature! I don't get it either. The hard drives are not even above 30 degrees. Maybe it's the graphics board (viper 550 agp): it's doing 1600x1200@85Hz. I once clocked the system at 500 Mhz (83 Mhz bus), which runs fine but then things get way too hot. Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RELEASE timelines
Yes 2.x went on for too long but I was counting 2.2.x as the equivalent of 3.x due to the change in the release schedule (mainly just a change in the numberring). The thing that worries me is the bad reputation that comes from releasing not quite ready releases. Basically the real way to run FreeBSD is from source ala -STABLE as we dont have a binary patching system established like the commercial vendors. Its argueable that the real FreeBSD is -CURRENT considering there is no automated method for tracking what hasn't yet been committed to -STABLE. It seems there is always a mad rush to MFC when -STABLE is about to pop out another release and this often leads to less than perfect releases and sometimes downright embarrasing mistakes. I'm not calling for a years worth of beta testing ala IRIX 6.5 but there are probably some improvements that can be made to the release system. After all we dont have to have the latest set of gcc, binutils, etc whenever a release appears since we have a good ports system. My first thought would be for cvs to be modified to require tagging of each commit to -CURRENT with a flag to indicate whether it should be merged into -STABLE before the next release (maybe it would indicate which release this change should be in). This will make it easier to process the backlog and allow a longer testing period for -STABLE before each release. I hope this doesn't start too big a thread as I'm rather behind on my cvs-all mail as it is (methinks those people who read all of current and cvs-all must have a job that lets them do this during work time or no wife and kids like myself). On Tue, 14 Dec 1999, Mark Newton wrote: On Tue, Dec 14, 1999 at 12:34:28AM +1030, Matthew Thyer wrote: Consider the 2.2 stream that went through many more releases (counting 2.2.1 - 2.2.8). Using that yardstick you'd expect 4.0 to stay in development until 3.7 is released. I know 7 releases of the 2.2 stream was considerred a few too many but surely we can hold 4.0 back a bit longer considerring the age of some of the code. The fact that the 2.2 stream went on for so long was one of the things which prompted the change to the way FreeBSD release engineering occurs. Continuing to bang on 2.x for, what, 16 minor revisions? was a problem, because it held the many improvements in 3.x back from the release stream for ages: So long, in fact, that some of the developers who had been working on them decided to leave for greener pastures where their code would actually see the light of day. Bear in mind the difference between 4.0-RELEASE and 4.1-STABLE too: 4.0-RELEASE will be for "early adopters" anyway. - mark -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: join the mailing-list
Not this way. Send email to "[EMAIL PROTECTED]" with the following two lines in the body of the message: subscribe freebsd-current subscribe cvs-all You should consider this action very carefully as you will start receiving approximately 200 messages each day. I would suggest that you only subscribe to freebsd-current to start with. On Tue, 14 Dec 1999, Leung Wa, Thomas Chow wrote: -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Speaking of moving files (Re: make world broken building fortunes )
On Mon, 13 Dec 1999, Louis A. Mamakos wrote: So how about /usr/sbin/chown - /sbin/chown so that MAKEDEV works with just the root file system mounted? How about removing awk from MAKEDEV so life isn't so hard to recover when you use a 3.3 fixit floppy after removing /dev and not making enough of it again. -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RELEASE timelines
What is the big rush to 4.0-RELEASE ? With all the new functionality and recent changes there are some things that need to be bedded in (I'm thinking newpcm and ATA). Maybe I'm saying this because my SB16 PnP has only just been fixed and my CD-ROM drive doesn't work under the ATA driver (I'm about to try the most recent fixes so dont yell at me yet) but maybe I'm saying this because things seem a bit rushed. Consider the 2.2 stream that went through many more releases (counting 2.2.1 - 2.2.8). Using that yardstick you'd expect 4.0 to stay in development until 3.7 is released. I know 7 releases of the 2.2 stream was considerred a few too many but surely we can hold 4.0 back a bit longer considerring the age of some of the code. -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA problem
Does your /etc/fstab have character devices listed or block devices ? If it has character devices (aka raw devices), change them to block (remove the 'r' at the front) e.g. change: "/dev/rad0s2a" to "/dev/ad0s2a". It seems to be only necessary for the root filesystem. Some people (like me) changed their fstabs to raw devices after a message from Poul Henning-Kamp (I hope thats the spelling) saying that it should be possible to use only raw devices throughout the system. This worked for a while but then other changes made it unable to boot. On Sat, 11 Dec 1999, Greg Childers wrote: Hi, With a bit of investigating, I've found the problem described in my previous email quoted at the end of this message started with the commits listed below. A kernel built using sources just before these commits works fine, whereas a kernel build just after freezes after the line Mounting root from ufs:wd0s1a Hope this helps. If you need any more info, just ask. Greg sos 1999/10/09 12:57:15 PDT Modified files: sys/dev/ata ata-all.c ata-all.h ata-disk.c ata-disk.h ata-dma.c atapi-all.c atapi-all.h atapi-cd.c atapi-fd.c atapi-fd.h atapi-tape.c atapi-tape.h Log: Add support for the HPT366 chip, this is used on the Abit boards and their HotRod controller and on SIIG PCI ultra DMA controller. These changes also made lots of the Promise code go away, its all much more generic this way. Get rid of atapi_immed_cmd, instead use the queue to move atapi commands from interrupt context if nessesary, the entire atapi layer has gotten an overhaul. Lots of fixes to utililize the new features in subr_disk.c etc, and get rid of the last biots of softc arrays in the drivers, the only one left is atadevices which cannot easily go away (yet). Use our own malloc names, its a lot easier to track memory usage this way. General cleanup overall. Revision ChangesPath 1.24 +191 -160 src/sys/dev/ata/ata-all.c 1.12 +21 -14src/sys/dev/ata/ata-all.h 1.30 +57 -56src/sys/dev/ata/ata-disk.c 1.13 +14 -5 src/sys/dev/ata/ata-disk.h 1.14 +174 -59 src/sys/dev/ata/ata-dma.c 1.18 +146 -169 src/sys/dev/ata/atapi-all.c 1.12 +25 -27src/sys/dev/ata/atapi-all.h 1.21 +68 -92src/sys/dev/ata/atapi-cd.c 1.21 +20 -20src/sys/dev/ata/atapi-fd.c 1.6 +11 -11src/sys/dev/ata/atapi-fd.h 1.18 +50 -60src/sys/dev/ata/atapi-tape.c 1.8 +50 -50src/sys/dev/ata/atapi-tape.h sos 1999/10/09 13:22:02 PDT Modified files: sys/conf options Log: Add the options for the ATA driver. Revision ChangesPath 1.159 +5 -1 src/sys/conf/options Hello, Seems now is the time to raise problems with ATA, so here goes. I have used the ATA driver since its introduction into -current without problem until recently. A kernel from October 5 worked fine. Now, it no longer works using ATA, but works fine using the old WD drivers. The console freezes after the dmesg and the keyboard is unresponsive. The ata info in MYKERNEL is a direct cut and paste from GENERIC. The motherboard is an Intel Premiere/PCI (Batman's Revenge). According to technical product summary, the primary IDE interface, on which both my drives reside, is a PCTech RZ1000 on the PCI local bus. The secondary IDE interface is a SMC 37C665 I/O controller on the ISA bus. Below is the relevant sections of a verbose dmesg. If there's any additional info I can provide to help diagnose thisproblem, please ask. Thanks, Greg ata-pci0: Unknown PCI IDE controller (generic mode) at device 1.0 on pci0 ata-pci0: Busmastering DMA not supported ata0: iobase=0x01f0 altiobase=0x03f4 ata0: mask=03 status0=50 status1=50 ata0: mask=03 status0=50 status1=50 ata0: devices = 0x3 ata0 at 0x01f0 irq 0 on ata-pci0 ata-isa0: already registered as ata0 BIOS Geometries: 0:020a1f3f 0..522=523 cylinders, 0..31=32 heads, 1..63=63 sectors 1:026b3f3f 0..619=620 cylinders, 0..63=64 heads, 1..63=63 sectors 0 accounted for Device configuration finished. device combination doesn't support shared irq0 intr_connect(irq0) failed, result=-1 ad0: piomode=3 dmamode=1 udmamode=-1 cblid=0 ad0: WDC AC2540H/12.08R30 ATA-? disk at ata0 as master ad0: 515MB (1056384 sectors), 1048 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 1 depth queue, PIO Creating DISK ad0 Creating DISK wd0 ad1: piomode=3 dmamode=1 udmamode=-1 cblid=0 ad1: WDC AC31200F/15.05F29 ATA-? disk at ata0 as slave ad1: 1222MB (2503872 sectors), 2484 cyls, 16 heads, 63 S/T, 512 B/S ad1: 16 secs/int, 1 depth queue, PIO Creating DISK ad1 Creating DISK wd1 Mounting root from ufs:wd0s1a
Re: Compiler looping
I can also vouch that there is nothing wrong with mysql-server-3.22.27. When my machine was compiling sql_yacc.cc the compiler was using 200 MB of memory (this is on a machine with 64 MB RAM!). The solution is to minimize other memory use (stop the X server and setiathome if you run it) and go to bed. In the morning it was all finished without problems. On Tue, 7 Dec 1999, Jeroen Ruigrok/Asmodai wrote: -On [19991206 21:57], Forrest Aldrich ([EMAIL PROTECTED]) wrote: Someone recently posted a note about a compiler error (loop?) when compiling mysql. I just did buildworld/installworld from today's cvsup and still get the same problem when it goes to: c++ -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME="\"/usr/local\"" -DDATADIR="\"/var/db/mysql\"" -DSHAREDIR="\"/usr/local/share/mysql\""-DHAVE_CONFIG_H -I./../include -I./../regex-I. -I../include -I.. -I. -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DDBUG_OFF -O -pipe -fno-implicit-templates -c sql_yacc.cc As what said in the other mail. This is not a `loop'. The C++ compilation takes ages before it is done compiling. Just let it finish, if you are worried about resources, you can limit those per instructions in the other mail. -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How do I get a USB mouse working in todays -CURRENT ?
Thanks Nick, my USB mouse works perfectly now.
On Thu, 2 Dec 1999, Nick Hibma wrote:
The problem is that the mouse doesn't work (its not a hardware problem),
all I get whenever I move the mouse are lots of the following messages
on the console:
Discarded 7 bytes in queue
This means that your mouse is working but moused is closing while the
buffer is not empty yet. This looks a lot like my mistake I fixed
earlier.
Do I need to change /etc/usbd.conf in some way ?
No, you are probably looking at a stale moused.c. Please update the file
/usr/src/usr.sbin/moused/moused.c with the following diff (there is an
extra semicolon at the end of that line) and execute makemake install
in that directory:
Index: src/usr.sbin/moused/moused.c
===
RCS file: /home/ncvs/src/usr.sbin/moused/moused.c,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -w -r1.32 -r1.33
--- moused.c1999/11/29 17:21:07 1.32
+++ moused.c1999/11/30 10:20:33 1.33
@@ -746,7 +746,7 @@
}
/* mouse event */
- if (read(rodent.mfd, b, 1) == -1);
+ if (read(rodent.mfd, b, 1) == -1)
return; /* file seems to be closed on us */
if (r_protocol(b, action)) { /* handler detected action */
Nick
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] USB project
http://www.etla.net/~n_hibma/
--
/===\
| Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] |
\===/
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
E. P. Tryon from "Nature" Vol.246 Dec.14, 1973
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
How do I get a USB mouse working in todays -CURRENT ?
What's involved in getting a USB mouse working in -CURRENT ? I have a Micro$oft USB IntelliMouse 1.1A. I have added everything USB to my kernel (as I'm not using any USB klds) and have set usbd_enable to YES in /etc/rc.conf. My kernel and world are up to date as of about 3 hours ago and I have updated my /etc files (and hence have the latest /etc/usbd.conf). I disabled moused in /etc/rc.conf as usbd starts moused when attaching mice. This is what I see in the kernel probes (non-verbose boot with all the USB debugging options): uhci0: Intel 82371AB/EB (PIIX4) USB controller irq 12 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision unknown, not supported uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Microsoft IntelliMouse, rev 1.00/1.04, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. ums_attach: sc=0xc0921c00 ums_attach: X 8/8 ums_attach: Y 16/8 ums_attach: Z 24/8 ums_attach: B1 0/1 ums_attach: B2 1/1 ums_attach: B3 2/1 ums_attach: size=4, id=0 The problem is that the mouse doesn't work (its not a hardware problem), all I get whenever I move the mouse are lots of the following messages on the console: Discarded 7 bytes in queue Do I need to change /etc/usbd.conf in some way ? Any help greatly appreciated as all my PS/2 and serial mice are dead (luckily I read mail on my dumb terminal with PINE!). -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: {a}sync updates (was Re: make install trick)
Maybe the best solution is the following: - leave "sync" with its current behaviour - create a sysctl to make it truely synchronous (I was thinking of a new mount option but thats overkill) and have the documentation for that sysctl state the performance hit and recommend that the filesystem be mounted with "noatime" when this sysctl is on. The sysctl could have three levels: - off - on for atime updates - on for atime updates and free block bitmap updates On Thu, 7 Oct 1999, Peter Jeremy wrote: On 1999-Oct-07 09:15:42 +1000, Matthew D. Fuller wrote: Is this good, bad, ugly, or just inconsistent? On the one hand, you can argue that 'sync should be sync should be sync, I don't bloody care, just don't do anything async at all', since that's what it's supposed to do: mount(8): syncAll I/O to the file system should be done synchronously. How detailed should the man page be? If it stated "all file data will be written synchronously, but inodes where the only update is atime and free block bitmaps are written asynchronously", would that be any clearer to a user who didn't have a detailed understanding of UFS? If you would like it to say something different, write some patches and send them in as a PR (keeping in mind phk's recent e-mail about green bikesheds). sync atime updates will slow it down, but on the flip side, if you're mounting sync in the first place you don't care much for speed anyway. There should be fairly few writes to the root partition, so having these writes synchronous is not a big performance hit. On the other hand, there are probably a _lot_ of read accesses to devices in /dev and files in /bin (how many of your scripts begin #!/bin/sh?). Unless you specify NOATIME, each of these read accesses implies an atime update within the inode. Making these synchronous probably would be a big performance hit. Peter -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Not for me. (was: CVSup core dumps)
Just an anti-me too.
Static cvsup works perfectly for me (installed from ports cvsup-bin on
Sept 9th).
I run it both on my dumb terminal and on my X display.
(My X configuration is XFree86 3.3.5, Gnome/Enlightenment [all built
Sept 9th after a make world]).
My shell is tcsh 6.09 (built Sept 1st).
I have never had cvsup-bin core dump.
I have built the world twice since the signal changes and am currently
running on my build which completed about 36 hours ago.
localhost# {8} cvsup -v
CVSup client, GUI version
Software version: REL_16_0
Protocol version: 16.0
http://www.polstra.com/projects/freeware/CVSup/
Report problems to [EMAIL PROTECTED]
localhost# {9}
On Mon, 4 Oct 1999, John Polstra wrote:
I've seen a few reports that CVSup has suddenly started dumping
core on a segmentation violation under -current, but I need more
information. For starters, I would like to know whether the static
binary (ports/net/cvsup-bin) works or not under the very latest
-current on the i386. Could somebody please check that and report
back to the list? I can't sacrifice my i386 -current machine to the
cause right now.
Also, for those of you who are experiencing problems: Please state
as precisely as possible:
- which vintage of -current are you running?
- what is the output from "cvsup -v"?
- is "cvsup" a static binary or is it dynamically linked?
- did you build it, or did you simply install a binary?
- if you built it, when did you build it?
Note, you are going to have trouble getting much out of the core dumps
from the binaries, because they're a.out. I've placed an unstripped
ELF binary here if you'd like to help out by getting a stack trace:
http://www.freebsd.org/~jdp/cvsup-16.0.gz
The compressed file is about 2.3 MB in size.
John
--
/===\
| Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] |
\===/
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
E. P. Tryon from "Nature" Vol.246 Dec.14, 1973
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
make world speed-up patch (was Re: optional 'make release' speed-uppatch)
Ooops... stick foot in mouth put on flame proof suit
Mike, you can call me stupid if you want because I was in sending that
email. Thats what happens when you reply to mail without reading the
thread first! Stupid me especially when the subject is clearly about
"make release".
Now back to what I was really emailing about which is "make world".
The snippet from /usr/src/Makefile.inc1 that I'm talking about (in my
own little world) was this:
.if !defined(NOCLEAN)
@echo
@echo "--"
@echo " Cleaning up the temporary ${OBJFORMAT} build tree"
@echo "--"
mkdir -p ${WORLDTMP}
-chflags -R noschg ${WORLDTMP}/
rm -rf ${WORLDTMP}
.endif
Can we please have this optimised ?
On Sun, 12 Sep 1999, Oliver Fromme wrote:
Matthew Thyer wrote in list.freebsd-current:
YES please fix this ridiculous inefficiency pointed out by Rod!
There's nothing broken, so there's nothing to fix (IMO).
The current method of cleaning the build tree is to chflags -R and
then rm -r which results in two full traversals of the entire /usr/obj
tree which takes MUCH longer than attempting an rm -r first followed by
a chflags -R and another rm -r.
Uhm, what are you talking about? The Makefile does exactly
that:
quote
# The first command will fail on a handful of files that have their schg
# flags set. But it greatly speeds up the next two commands.
-rm -rf ${CHROOTDIR}
-chflags -R noschg ${CHROOTDIR}/.
-rm -rf ${CHROOTDIR}
/quote
Regards
Oliver
--
/===\
| Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] |
\===/
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
E. P. Tryon from "Nature" Vol.246 Dec.14, 1973
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
FreeBSD-CURRENT rl driver not auto-negotiating ?
Bill, Firstly, a great job on the rl driver (I'm amazed that you have made it this good considering the hardware). Anyway my problem is that since the rl driver has required "controller miibus0" in the kernel it has not auto-negotiated its network link properly for me (though I do appreciate the fast kernel probe time ;). It seems to be defaulting to full duplex now when it wasn't before the "controller miibus0" stuff went in. I find that I now have to change my /etc/rc.conf line from: ifconfig_rl0="inet 10.0.0.27 netmask 255.0.0.0" to: ifconfig_rl0="inet 10.0.0.27 netmask 255.0.0.0 media 10BaseT/UTP -mediaopt full-duplex" Interestingly "mediaopt half-duplex" doesn't work with error: "ifconfig: SIOCSIFMEDIA: Device not configured" Is this all expected behaviour ? If I dont do the above, I get terrible ftp speeds on my local 10BaseT/UTP network (3 KB/sec instead of the 1 MB/sec I am used to). I have a 3COM Linkbuilder hub and two machines. My old machine is a P150 with an NE2000 clone. My new machine is a PII Celeron 450 with a RealTek 8139 (a SureCom Networks SN5000 card - but that wont mean anything as I bought it because it wasn't a RealTek when my friend bought it... it was a VIA Rhine then I was really trying to avoid a RealTek!!). My kernel from before the move to the "controller miibus0" stuff works fine without any media options. Dmesg and kernel config file attached. Thanks in advance. CCd to the list for the benefit of others. -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sun Sep 12 23:04:55 CST 1999 matt@localhost:/usr/src/sys/compile/MATT Timecounter "i8254" frequency 1193182 Hz CPU: Celeron (463.91-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 = 67043328 (65472K bytes) avail memory = 62025728 (60572K bytes) Preloaded elf kernel "kernel" at 0xc02a8000. VESA: v2.0, 2304k memory, flags:0x0, mode table:0xc00c6b5d (c0006b5d) VESA: Tseng Labs ET6000 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 7.0 on pci0 isa0: ISA bus on isab0 ata-pci0: Intel PIIX4 IDE controller at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 chip1: UHCI USB controller irq 11 at device 7.2 on pci0 intpm0: Intel 82371AB Power management controller at device 7.3 on pci0 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped 4000 rl0: RealTek 8139 10/100BaseTX irq 11 at device 9.0 on pci0 rl0: Ethernet address: 00:00:21:c0:5e:c9 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vga-pci0: Tseng Labs ET6000 graphics accelerator at device 13.0 on pci0 atkbdc0: keyboard controller (i8042) at port 0x60-0x6f on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse flags 0x4 irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 vga0: Generic ISA VGA at port 0x3b0-0x3df iomem 0xa-0xb on isa0 sc0: System console on isa0 sc0: VGA 12 virtual consoles, flags=0x200 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 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 joy0 at port 0x201 on isa0 joy0: joystick unknown0: Reserved on isa0 unknown1: Game on isa0 pcm0: SB16 PnP at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 unknown2: Generic ESDI/IDE/ATA controller at port 0x168-0x16f,0x36e-0x36f irq 10 on isa0 ata1: unwanted interrupt 1 status = ff ata0: master: setting up UDMA2 mode
Re: optional 'make release' speed-up patch
YES please fix this ridiculous inefficiency pointed out by Rod!
The current method of cleaning the build tree is to chflags -R and
then rm -r which results in two full traversals of the entire /usr/obj
tree which takes MUCH longer than attempting an rm -r first followed by
a chflags -R and another rm -r.
Rather than patch /usr/src/Makefile.inc1, I have been using an alias
for the last year or so:
mkworld (rm -rf /usr/obj/usr ; chflags -R noschg /usr/obj/usr ; rm -rf
/usr/obj/usr ; cd /usr/src make world) /usr/src/WORLD.log.`date
"+%g%m%d"`
Also while I was looking at /usr/src/Makefile I noticed the following
paragraph. Is this still true (the defaulting to a.out) ? There is also
is a typo: "or 3.0." should be "of 3.0.".
# The `make world' process always follows the installed object format.
# This is set by creating /etc/objformat containing either OBJFORMAT=aout
# or OBJFORMAT=elf. If this file does not exist, the object format defaults
# to aout. This is expected to be changed to elf just prior to the release
# or 3.0. If OBJFORMAT is set as an environment variable or in /etc/make.conf,
# this overrides /etc/objformat.
On Wed, 8 Sep 1999, Rodney W. Grimes wrote:
Hi,
The following patch to /usr/src/release/Makefile allows the
specification of the variable FASTCLEAN, which instead of doing
a recursive rm on CHROOTDIR, simply umounts/newfs/mounts. Of
course, this is only useful if your CHROOTDIR location is a
separate mount point (which mine is: /snap).
Comments and critiques welcome.
And how about a similiar patch to /usr/src/Makefile that is
FASTCLEANDIR that brings back a patched up version of
my original CLEANDIR. Something like
-rm -rf /usr/obj/${.CURDIR}/tmp
chflags -R noschg /usr/obj/${.CURDIR}/tmp
rm -rf /usr/obj/${.CURDIR}
Would someone consider committing this please?
Thanks,
John
Index: Makefile
===
RCS file: /mirror/ncvs/src/release/Makefile,v
...
--
/===\
| Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] |
\===/
"If it is true that our Universe has a zero net value for all conserved
quantities, then it may simply be a fluctuation of the vacuum of some
larger space in which our Universe is imbedded. In answer to the
question of why it happened, I offer the modest proposal that our
Universe is simply one of those things which happen from time to time."
E. P. Tryon from "Nature" Vol.246 Dec.14, 1973
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Communicator 4 and LDAP
We are forced to use Exchange at work and I use its LDAP server to look up addressing information. I do occasionally get the error 0x5B that others report but I just try again and it usually works. This is with Netscape 4.61 on 4.0-CURRENT On Wed, 8 Sep 1999, Lars Fredriksen wrote: Hi, Has anyone had any luck using communicator with a LDAP server? Both communicator 4.5 and 4.61 fails to connect to any LDAP server that I have tried. It appears that the connect() gets interrupted and not restarted. This happens both under current and 3.0. Lars To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NewPCM and Quake :)
I am having a few problems with newpcm. I often play a whole bunch of Sesame Street AVIs to keep the 1 and 3 year olds happy while I read email. I usually play them like so (straight from the CD-ROM): foreach blah ( /cdrom/letters/tv/*.avi ) xanim -Zr +Ze +Av`mixer | grep pcm | cut -d: -f2` $blah /dev/null end This worked fine with the old sound drivers but now I find that I have to put in a 1 second sleep after xanim or the sound will usually stop completely after the first AVI. I am also now getting the following messages on the console: "dsp sync" I get 4 of these at the start of each invocation of xanim and then I get 1 at the end of each invocation of xanim. When the sound has stopped completely I have to reboot to get it back. My -CURRENT is about 3 days old. (9/9/99 my time which is UTC +9.5 hours) elf make world started on Thu Sep 9 09:29:09 CST 1999 elf make world completed on Thu Sep 9 11:01:23 CST 1999 I have a PnP SB16 and "device pcm0" in my kernel (along with "controller pnp0") of course. The most recently updated file in /usr/src/sys/dev/pcm for me is channel.c at version 1.3 if thats usefull. On Fri, 10 Sep 1999, Daniel O'Connor wrote: Hi, I am trying NewPCM on -current with an AWE64. It works fine for normal sound apps like esd, splay etc etc.. but Quake 1 2 which use the DMA buffers to play their sound. It is allowed to do this (the ioctl is supported), but it stutters very badly. Its a bit hard to explain :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
The problem is that recent versions of MS-DOS (version 7 and above ? ...definitely the DOS that comes with Windows 98 and I think the DOS with Windows 95 under some circumstances) change various vectors which destroy FBSDBOOTs ability to work (this is because there is no way to determine where these vectors used to point and the original addresses are required for correct operation of either FBSDBOOT or the kernel/ loader). What I do know is that at least some older versions of MS-DOS do not do this. Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22 boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel and hence the whole system. Hopefully now that Carlos Tapang has updated FBSDBOOT.EXE for ELF, such a boot floppy could boot a 3.1, 3.2 or -CURRENT system. Unfortunately the project cannot guarantee anything when you are booting from another vendor's operating system (such as MS-DOS) so its a lot easier to say that FBSDBOOT.EXE has been retired. Given the number of different DOSes that exist, that's an entirely understandable policy. I hope this clears things up (and adds a good summary to the archives). Carlos C. Tapang wrote: Mike, Thanks for trying fbsdboot.exe. I need more information to fix it. I would like to fix it, so please describe exactly what the problem is. What do you mean by the need to reboot the system to restore various vectors that DOS destroys? Do you mean that prior to executing the FreeBSD kernel init routines, DOS does something to the loaded area? I'm sorry I can't find any info on this either in the mail threads or in freebsd.org. Probably I'm not looking hard enough, but I believe it would be more efficient to just ask you. Carlos C. Tapang http://www.genericwindows.com -Original Message- From: Mike Smith m...@smith.net.au To: Carlos C. Tapang ctap...@easystreet.com Cc: Bob Bishop r...@gid.co.uk; Mike Smith m...@smith.net.au; curr...@freebsd.org curr...@freebsd.org Date: Sunday, May 16, 1999 7:28 PM Subject: Re: FBSDBOOT.EXE It doesn't work. Don't use it. You need to reboot the system to restore various vectors that DOS destroys. Please see the previous threads on this topic, especially anything from Robert Nordier. The most relevant piece I can find from R. Nordier is the following: The fbsdboot.exe program should probably be considered obsolete. It should (in theory) be possible to use it to load /boot/loader, which can then load the kernel, but there are various reasons this doesn't work too well. These reasons were also expounded, and I did summarise them in another message on this thread. I have not tested the updated program with /boot/loader. /boot/loader does not help me because my root directory is in a memory file system, and I can not assume that my users will want to reformat their DOS drives or even repartition it. So all FreeBSD files are in the DOS file system. The loader won't help you because you are booting from under DOS, but the loader will boot the kernel just fine off a DOS filesystem. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: XFree86 xsetpointer causes silo overflows (Was: Re: Fixed my MAMEd sio problem.)
The big problem is that the silo overflows continue after I have returned the pointer to the mouse (with xsetpointer pointer). This should close the joystick device shouldn't it ? If it doesn't then there is a problem with either the X server or FreeBSD. Bruce has already indicated that there is a problem with the FreeBSD joystick driver but he thought it should stop when the joystick device is closed but I see that the problem continues until I restart the X server so that would seem to indicate a problem with the X server. David Dawes wrote: On Wed, May 19, 1999 at 01:20:01AM +0930, Matthew Thyer wrote: I have confirmed that the problem occurs if I just do: xsetpointer Joystick sleep 1 xsetpointer pointer So M.A.M.E. is unrelated to the problem as Bruce Evans would suggest. So the problem appears to be with XFree86 not closing the joystick device after I've used it as a pointer with 'xsetpointer'. The problem is in the joystick driver (or are silo overflows acceptable while you actually want to use the joystick?). I am sure I am using xsetpointer correctly as I can use my PC joystick as a pointing device (once I calibrate it). I was just using xsetpointer with an incorrectly calibrated joystick so it moved the pointer to the top left corner of the screen in my xmame.sh shell script (I'd like to know how to do this another way). A better way would be a small X client that uses XWarpPointer(3). David To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
XFree86 xsetpointer causes silo overflows (Was: Re: Fixed my MAMEd sio problem.)
I have confirmed that the problem occurs if I just do: xsetpointer Joystick sleep 1 xsetpointer pointer So M.A.M.E. is unrelated to the problem as Bruce Evans would suggest. So the problem appears to be with XFree86 not closing the joystick device after I've used it as a pointer with 'xsetpointer'. I am sure I am using xsetpointer correctly as I can use my PC joystick as a pointing device (once I calibrate it). I was just using xsetpointer with an incorrectly calibrated joystick so it moved the pointer to the top left corner of the screen in my xmame.sh shell script (I'd like to know how to do this another way). Bruce Evans wrote: Just so you all know (the list included) how I have fixed my silo overflow problem which occurred while running xmame (and after I quit until I restarted the X server) I have found the problem doesn't occur if I remove the following lines from the shell script I use to start xmame: xsetpointer Joystick sleep 1 xsetpointer pointer FreeBSD's joystick driver certainly causes silo overflows. It disables CPU interrupts and polls for 2 msec. For 16550 serial hardware, this may cause loss of 21 characters at 115200 bps (23 characters arriving in 2 msec less 2 characters of buffering provided by the 16550 fifo above the trigger level). If sio used a more conservative trigger level of 8, then then the loss would be limited to only 15 characters. With those lines in the script I had to restart the X-server after using xmame or I'd get continuous silo overflows. Closing the joystick device should also work. The joystick driver shouldn't disable CPU interrupts or mask clock interrupts. Bruce -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Fixed my MAMEd sio problem. Was: Re: Doesn't anyone care about the broken sio ??
Just so you all know (the list included) how I have fixed my silo overflow problem which occurred while running xmame (and after I quit until I restarted the X server) I have found the problem doesn't occur if I remove the following lines from the shell script I use to start xmame: xsetpointer Joystick sleep 1 xsetpointer pointer I was doing those three lines just before starting xmame to get the mouse pointer into the top left hand corner (my script also used vidtune to get the right resolution for each game). Since I have removed those lines it works fine. I can now download to my hearts content whilst playing some ancient game. (I'd like to know an easy way to move the mouse pointer though!) With those lines in the script I had to restart the X-server after using xmame or I'd get continuous silo overflows. FYI, the output of xsetpointer -l is: keyboard [XKeyboard] pointer [XPointer] SWITCH[XExtensionDevice] Joystick [XExtensionDevice] And as you can see from the XF86Config file in the message I'm replying to, I am loading several modules to use XExtension Devices and the PC joystick (which is compiled into my kernel): Load xie.so Load pex5.so Load xf86Jstk.so Matthew Thyer wrote: *** STOP PRESS *** I have just confirmed that restarting the X server is enough to fix the problem. So my apologies to Bruce, -CURRENT and the whole FreeBSD community in general for blaming sio. For the benefit of David Dawes, I'll quickly restate the problem: Running xmame (from the ports collection) causes lots of silo overflows with user mode ppp until I either restart the X server or reboot. This occurs even after I exit xmame. This is all on FreeBSD-CURRENT but has been happenning for months and is not newbus related. Thankyou Brian, you are the first to NOT reproduce the problem. Note that all my recent testing of this has been at 300 MHz so dont jump on me when you see that I normally overclock at 450 MHz. So compare configuration: My X server is XFree86 3.3.3.1 (from ports) and I use the XF86_SVGA server. My video card is an ET6000 Jaton VIDEO-58P with 2.25 MB RAM. I run in 16 bit colour with KDE 1.1.1. I run MAME with sound enabled and I'm NOT using Luigi's PCM driver but rather the old driver (whats it called ??). I have a new ABIT BX6 release 2.0 motherboard (with 16550s I assume). I have an Intel Celeron 300a CPU which I normally run at 450 MHz (using a 100 MHz memory bus speed instead of 66 MHz but when I run it at 300 MHz it doesn't make any difference to this problem). I have PC100 SD RAM with an EPROM. This RAM is rated at 7ns believe it or not. I'd like to be using Soren's ATAPI driver but it doesn't like my CD-ROM drive so I'm using the normal wd driver with flags a0ffa0ff. I'm using a KTX V.90 modem at 115000 baud. I typically get 45333, 46667 or 48000 connections to my ISP. I'm using a Microsoft serial mouse but am not using moused. I do have a PS/2 intellimouse compatible mouse attached but only use it when I'm on the darkside (In Windows 95) as it doesn't work with moused or in XFree86. My whole system has been re-compiled within the last 2 days (world, updated /etc, kernel AND ALL ports [XFree86 3.3.3.1, kde 1.1.1 etc etc etc]) Kernel config file (MATTE), /etc/XF86Config file and dmesg output attached. I have one question about my kernel config: How do I know when it's unsafe to use options CPU_DISABLE_5X86_LSSER ? It would be good if the kernel disabled this option under those cases. My /etc/ppp/ppp.conf is: default: set log chat connect phase set device /dev/cuaa1 set speed 115200 allow users matt deny lqr deny chap set timeout 0 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \\ ATX4S95=47 OK-AT-OK \\dATDT\\T TIMEOUT 80 CONNECT set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 isp: set phone ISPNUMBER set login TIMEOUT 10 sername:--sername: MYUSER ssword: MYPASS dial Brian Feldman wrote: On Sat, 8 May 1999, Jordan K. Hubbard wrote: I mailed a simple way to reproduce the serious brokeness of the serial port driver on my system and no one responds. What does this mean ? It means that nobody is probably willing to go bring up a MAME environment just to test this. You need to isolate it to a more minimal test case if you want people to jump on what could be a local problem (some serial hardware is better behaved than others) or a misbehaving X server (which is masking interrupts for too long; see mailing list archives on this topic). The more complex your reproduction case, in other words, the less likely it is that anyone will respond to it. Hmm, so now you're the second to cite the possibility of X masking interrupts too long, eh? ;) Actually, I use MAME all the time, and this problem does NOT occur (XF86_SVGA on an S3 ViRGE/DX). Oh, user-ppp too of course. If I could have
Re: Different SCSI probe behavior
Every time I boot my -CURRENT system at work I get this problem. And for me its not recent, its been happening ever since the aha driver was finally converted to CAM I think (3 or 4 months I guess). I am using a 1542B with an old Wren drive and some other drive. (Wren 7G springs to mind but I cant be sure). A 1.5GB and a 1.8GB drive are all I have on the SCSI bus. I haven't mentioned it because it still works OK after the 30 or so second delay and I'm too busy at work to provide enough information and follow an email exchange (as I'm not on the lists at work anymore). Khetan Gajjar wrote: On Sat, 15 May 1999, Bret A. Ford wrote: Waiting 10 seconds for SCSI devices to settle aha0: ahafetchtransinfo - Inquire Setup Info Failed (probe20:aha0:0:5:0): CCB 0xc553b450 - timed out (probe20:aha0:0:5:0): CCB 0xc553b450 - timed out aha0: No longer in timeout I'm seeing the same thing, but for 3 of my devices on a chain with 4 devices. It takes quite long, but doesn't appear to do any damage or decrease functionality (so far that is). Do I need to update something for normal behavior? I've been following freebsd-current and cvs-all, though I might have missed something that would have clued me in. I've seen Werner Losch discovering a problem with the aha driver in -stable, and he committed a fix for that. Is it possible for that fix to be MFS ? --- Khetan Gajjar (!kg1779) * khe...@iafrica.com ; khe...@os.org.za http://www.os.org.za/~khetan * Talk/Finger khe...@chain.freebsd.os.org.za FreeBSD enthusiast* http://www2.za.freebsd.org/ Security-wise, NT is a OS with a kick me sign taped to it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: problem with NewScroll Mouse, etc
Moused and XFree86 3.3.3.1 dont support a particular new type of mouse. This is the PS/2 Intellimouse clone. (I'm note sure if 'real' MicroSoft Intellimice work ??). My mouse is such a clone and behaves the same as you are saying but works fine under Windows 95 with the PS/2 mouse driver. Someone who was interested in this when I complained about my mouse was Kazutaka Yokota who replied to me with the attached message. Ilya Naumov wrote: We , 12 may 1999, Steve O'Hara-Smith wrote: 1. something is wrong with psm0 driver. my Genius NewScroll PS/2 mouse works well, but in random moment when i touch the mouse kernel starts to write to the system log the following. Apr 29 11:55:58 camel /kernel: psmintr: out of sync (00c8 != 0008). Apr 29 11:55:58 camel /kernel: psmintr: out of sync (00c0 != 0008). when it happens, mouse cursor moves, but buttons do not work. only reboot solves this problem. even full restart of moused doesn't help. very strange bug. NewScroll seems to be fully compatible with Microsoft PS/2 mouse protocol, and a problem with it appears under FreeBSD only. -- sincerely, ilya naumov (at work) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973---BeginMessage--- I recently bought a PS/2 mouse that claims to be an Intellimouse (PS/2) clone. It has two normal buttons and a roller wheel (that is the third button as well). Anyway, this doesn't work with moused (which I know is based on the XFree86 mouse code), and it doesn't work with XFree86 3.3.3.1 either. Well, moused was originally based on XFree86 code. However, the other way round is the case these days; XFree86 mouse code is based on moused code :-) In both cases the application (moused or X) seems to think it is clicking the left mouse button several times whenever I move the mouse up the screen (Down the screen seems fine). The mouse is called Laser Smart (I think its made in China). Any ideas on how I can make this work ? My kernel probes it as: psm0: model IntelliMouse, device ID 3 The mouse is certainly claiming to be IntelliMouse... Please carry out the following test and send me the result. 1. Become root. 2. Kill moused if it is running. 3. Capture the rest of the experiment by the `script' command. script _file_name_to_save_output_ 4. Run moused in the debug mode. moused -d -f -p /dev/psm0 -l 2 5. Don't move mouse, but click buttons in turn. You should see status output from moused. 6. Then, move mouse and turn it wheel. 7. Stop moused by hitting ^C. 8. Stop the script command by typing `exit'. Kazu ---End Message---
Doesn't anyone care about the broken sio ??
) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sun May 2 01:10:27 CST 1999 m...@localhost:/usr/src/sys/compile/MATTE Timecounter i8254 frequency 1193182 Hz CPU: Celeron (463.91-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 = 67108864 (65536K bytes) config pnp 1 0 bios enable avail memory = 62140416 (60684K bytes) Preloaded elf kernel kernel at 0xc02ed000. Preloaded userconfig_script /boot/kernel.conf at 0xc02ed09c. Pentium Pro MTRR support enabled, default memory type is uncacheable Probing for PnP devices: CSN 1 Vendor ID: CTL0024 [0x24008c0e] Serial 0x100a1ec0 Comp ID: PNP0600 [0x0006d041] npx0: math processor on motherboard npx0: INT 16 interface apm0: APM BIOS on motherboard apm: found APM BIOS version 1.2 pcib0: PCI host bus adapter on motherboard pci0: PCI bus on pcib0 chip0: Intel 82443BX host to PCI bridge at device 0.0 on pci0 chip1: Intel 82443BX host to AGP bridge at device 1.0 on pci0 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 ata-pci0: Intel PIIX4 IDE controller at device 7.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 chip2: Intel 82371AB Power management controller at device 7.3 on pci0 ncr0: ncr 53c810 fast10 scsi at device 13.0 on pci0 ncr0: interrupting at irq 11 isa0: ISA bus on motherboard atkbdc0: keyboard controller (i8042) at port 0x60 on isa0 atkbd0: AT Keyboard on atkbdc0 atkbd0: interrupting at irq 1 psm0: PS/2 Mouse on atkbdc0 psm0: model IntelliMouse, device ID 3 psm0: interrupting at irq 12 vga0: Generic ISA VGA on isa0 sc0: System console on isa0 sc0: VGA color 12 virtual consoles, flags=0x0 fdc0: interrupting at irq 6 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive at fdc0 drive 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio0: interrupting at irq 4 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio1: interrupting at irq 3 ed0 at port 0x300-0x31f irq 9 on isa0 ed0: address 00:00:e8:20:33:e8, type NE2000 (16 bit) ed0: interrupting at irq 9 joy0 at port 0x201 on isa0 joy0: joystick sb0 at port 0x220 irq 5 drq 1 on isa0 snd0: SoundBlaster 16 4.13 sb0: interrupting at irq 5 sbxvi0 at drq 5 on isa0 snd0: SoundBlaster 16 4.13 sbmidi0 at port 0x330 on isa0 snd0: SoundBlaster MPU-401 opl0 at port 0x388 on isa0 snd0: Yamaha OPL3 FM ata0: master: settting up UDMA2 mode on PIIX4 chip OK ad0: IBM-DHEA-36480/HE8OA40F ATA-3 disk at ata0 as master ad0: 6197MB (12692736 sectors), 12592 cyls, 16 heads, 63 S/T, 512 B/S ad0: piomode=4, dmamode=2, udmamode=2 ad0: 16 secs/int, 0 depth queue, DMA mode changing root device to wd0s2a ffs_mountfs: superblock updated for soft updates ed0: device timeout ---End Message--- ---BeginMessage--- Re-nicing wont help as I have just confirmed that the problem occurs if I run MAME, exit MAME and then get on the net. Very wierd... after running MAME, the serial port is unusable for ppp unless I reboot. Just doing a DNS lookup causes several silo overflows. MAME does something very strange to the system. I will grep the MAME source code for anything related to serial ports. Doug Russell wrote: On Sun, 2 May 1999, Matthew Thyer wrote: I have been investigating the silo overflow situation for some time. I can trigger them every time by the following action: - Run M.A.M.E. (Multi arcade machine emulator) and then try to download something. (I am using user mode ppp). Can you nice M.A.M.E. slightly? Later.. Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 ---End Message--- ---BeginMessage--- This problem is easily reproducible. However to do so, you need a ROM image for an arcade game that the Multi Arcade Machine Emulator emulates as it wont do it without any roms in the directory /usr/local/lib/mame/roms. I am using xmame installed from the ports collection (/usr/ports/emulators/xmame) on a very recent -CURRENT machine. If I run xmame *before* I get online with user mode ppp (or while I am on the net), the serial ports get
Re: Doesn't anyone care about the broken sio ??
As far as I can tell, this is unrelated to newbus as the same actions would trigger this problem before and after newbus. I have been seeing this problem for many months (maybe years - but I've only recently identified a set of actions to reproduce it every time). The wierd thing is that I can download heaps of stuff all at the same time (at 48000 baud) and get over 5.5 K/s without a silo overflow BUT as soon as I run MAME, the serial port is stuffed and requires a reboot to do the smallest amount of traffic. NOTE: This occurs AFTER I exit MAME or while I keep it running Very strange. And its not just on this hardware. I'd just like someone to try to reproduce this. I realise that downloading a MAME ROM is problematic but surely someone out there owns an old space invaders machine or something similar. Poul-Henning Kamp wrote: Bruce said, in his own quite way, that somebody had broken fast interrupts as part of newbus, and that is the end of that story. Poul-Henning In message 9.926181...@zippy.cdrom.com, Jordan K. Hubbard writes: I mailed a simple way to reproduce the serious brokeness of the serial port driver on my system and no one responds. What does this mean ? It means that nobody is probably willing to go bring up a MAME environment just to test this. You need to isolate it to a more minimal test case if you want people to jump on what could be a local problem (some serial hardware is better behaved than others) or a misbehaving X server (which is masking interrupts for too long; see mailing list archives on this topic). The more complex your reproduction case, in other words, the less likely it is that anyone will respond to it. If you can say here's a small stand-alone C program which hogs things to the extent that the serial driver seriously overruns its buffers then it's likely that someone will be at least motivated to compile, run and try it. If it involves running some esoteric application which requires downloading data of questionable legality on top of it, it's far less likely that anyone will even bother to look. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Doesn't anyone care about the broken sio ??
*** STOP PRESS *** I have just confirmed that restarting the X server is enough to fix the problem. So my apologies to Bruce, -CURRENT and the whole FreeBSD community in general for blaming sio. For the benefit of David Dawes, I'll quickly restate the problem: Running xmame (from the ports collection) causes lots of silo overflows with user mode ppp until I either restart the X server or reboot. This occurs even after I exit xmame. This is all on FreeBSD-CURRENT but has been happenning for months and is not newbus related. Thankyou Brian, you are the first to NOT reproduce the problem. Note that all my recent testing of this has been at 300 MHz so dont jump on me when you see that I normally overclock at 450 MHz. So compare configuration: My X server is XFree86 3.3.3.1 (from ports) and I use the XF86_SVGA server. My video card is an ET6000 Jaton VIDEO-58P with 2.25 MB RAM. I run in 16 bit colour with KDE 1.1.1. I run MAME with sound enabled and I'm NOT using Luigi's PCM driver but rather the old driver (whats it called ??). I have a new ABIT BX6 release 2.0 motherboard (with 16550s I assume). I have an Intel Celeron 300a CPU which I normally run at 450 MHz (using a 100 MHz memory bus speed instead of 66 MHz but when I run it at 300 MHz it doesn't make any difference to this problem). I have PC100 SD RAM with an EPROM. This RAM is rated at 7ns believe it or not. I'd like to be using Soren's ATAPI driver but it doesn't like my CD-ROM drive so I'm using the normal wd driver with flags a0ffa0ff. I'm using a KTX V.90 modem at 115000 baud. I typically get 45333, 46667 or 48000 connections to my ISP. I'm using a Microsoft serial mouse but am not using moused. I do have a PS/2 intellimouse compatible mouse attached but only use it when I'm on the darkside (In Windows 95) as it doesn't work with moused or in XFree86. My whole system has been re-compiled within the last 2 days (world, updated /etc, kernel AND ALL ports [XFree86 3.3.3.1, kde 1.1.1 etc etc etc]) Kernel config file (MATTE), /etc/XF86Config file and dmesg output attached. I have one question about my kernel config: How do I know when it's unsafe to use options CPU_DISABLE_5X86_LSSER ? It would be good if the kernel disabled this option under those cases. My /etc/ppp/ppp.conf is: default: set log chat connect phase set device /dev/cuaa1 set speed 115200 allow users matt deny lqr deny chap set timeout 0 set dial ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \\ ATX4S95=47 OK-AT-OK \\dATDT\\T TIMEOUT 80 CONNECT set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.0 0.0.0.0 isp: set phone ISPNUMBER set login TIMEOUT 10 sername:--sername: MYUSER ssword: MYPASS dial Brian Feldman wrote: On Sat, 8 May 1999, Jordan K. Hubbard wrote: I mailed a simple way to reproduce the serious brokeness of the serial port driver on my system and no one responds. What does this mean ? It means that nobody is probably willing to go bring up a MAME environment just to test this. You need to isolate it to a more minimal test case if you want people to jump on what could be a local problem (some serial hardware is better behaved than others) or a misbehaving X server (which is masking interrupts for too long; see mailing list archives on this topic). The more complex your reproduction case, in other words, the less likely it is that anyone will respond to it. Hmm, so now you're the second to cite the possibility of X masking interrupts too long, eh? ;) Actually, I use MAME all the time, and this problem does NOT occur (XF86_SVGA on an S3 ViRGE/DX). Oh, user-ppp too of course. If I could have reproduced this problem, I would have replied. If you can say here's a small stand-alone C program which hogs things to the extent that the serial driver seriously overruns its buffers then it's likely that someone will be at least motivated to compile, run and try it. If it involves running some esoteric application which requires downloading data of questionable legality on top of it, it's far less likely that anyone will even bother to look. MAME is a great piece of software, and in and of itself entirely legal; what problem do you have with it? - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | http://www.freebsd.org _ |___)___/___/ -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in
Silo overflows and MAME can someone else reproduce this problem ??
This problem is easily reproducible. However to do so, you need a ROM image for an arcade game that the Multi Arcade Machine Emulator emulates as it wont do it without any roms in the directory /usr/local/lib/mame/roms. I am using xmame installed from the ports collection (/usr/ports/emulators/xmame) on a very recent -CURRENT machine. If I run xmame *before* I get online with user mode ppp (or while I am on the net), the serial ports get hosed and I have to reboot or I continually get silo overflows. This is not right as it happens AFTER I exit xmame !!! Please can someone else reproduce this problem as I'd hate to think its only on the systems I have owned (Pentium 166 and Celeron 300). -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Silo overflows and MAME can someone else reproduce this problem ??
My usermode ppp works fine normally as I can quite happily download 4 things at once without a single silo overflow (as I did last night) even when there is lots of disk activity or X11 activity. Note this problem is unrelated to newbus as it occurs both before and after those commits. Matthew Thyer wrote: This problem is easily reproducible. However to do so, you need a ROM image for an arcade game that the Multi Arcade Machine Emulator emulates as it wont do it without any roms in the directory /usr/local/lib/mame/roms. I am using xmame installed from the ports collection (/usr/ports/emulators/xmame) on a very recent -CURRENT machine. If I run xmame *before* I get online with user mode ppp (or while I am on the net), the serial ports get hosed and I have to reboot or I continually get silo overflows. This is not right as it happens AFTER I exit xmame !!! Please can someone else reproduce this problem as I'd hate to think its only on the systems I have owned (Pentium 166 and Celeron 300). -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Silo overflows and MAME can someone else reproduce this problem??
The sio driver seems to get into some kind of state where once it starts overflowing there is nothing you can do other than reboot. If you can determine exactly what triggers this on your system and give the list something they can reproduce that would be helpfull. vortexia wrote: Im getting continous overflows on sio0 after I shutdown X no matter what I do, even when there is NOTHING else running, the moment I shutdown X and I move my mouse I get tons of overflows. I have no pppd running at all and no moused, any ideas? Cheers Andrew On Tue, 4 May 1999, Matthew Thyer wrote: My usermode ppp works fine normally as I can quite happily download 4 things at once without a single silo overflow (as I did last night) even when there is lots of disk activity or X11 activity. Note this problem is unrelated to newbus as it occurs both before and after those commits. Matthew Thyer wrote: This problem is easily reproducible. However to do so, you need a ROM image for an arcade game that the Multi Arcade Machine Emulator emulates as it wont do it without any roms in the directory /usr/local/lib/mame/roms. I am using xmame installed from the ports collection (/usr/ports/emulators/xmame) on a very recent -CURRENT machine. If I run xmame *before* I get online with user mode ppp (or while I am on the net), the serial ports get hosed and I have to reboot or I continually get silo overflows. This is not right as it happens AFTER I exit xmame !!! Please can someone else reproduce this problem as I'd hate to think its only on the systems I have owned (Pentium 166 and Celeron 300). -- Matthew Thyer Phone: +61 8 8259 7249 Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: silo overflows in CURRENT ... some info that may help
Re-nicing wont help as I have just confirmed that the problem occurs if I run MAME, exit MAME and then get on the net. Very wierd... after running MAME, the serial port is unusable for ppp unless I reboot. Just doing a DNS lookup causes several silo overflows. MAME does something very strange to the system. I will grep the MAME source code for anything related to serial ports. Doug Russell wrote: On Sun, 2 May 1999, Matthew Thyer wrote: I have been investigating the silo overflow situation for some time. I can trigger them every time by the following action: - Run M.A.M.E. (Multi arcade machine emulator) and then try to download something. (I am using user mode ppp). Can you nice M.A.M.E. slightly? Later.. Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: sio overflows of some kind?
I have seen silo overflows on my serial port when I am using user mode ppp when using a PS/2 mouse and moused. Whilst downloading a large file I was able to cause multiple sio silo overflows by moving the mouse. I have stopped using moused since then (because of this) and can now download large files without problem but can still cause my serial ports to be unusable (requiring a reboot) if I run MAME first (before getting on the net) or while I am on the net. I can still use a PS/2 mouse, just not with moused, so XFree86 is using the mouse directly now instead of /dev/sysmouse. See my recent messages to freebsd-current entitled silo overflows in CURRENT ... some info that may help vortexia wrote: Hrmmm for some strange reason since I cvsupped a few days ago, Ive been getting strange messages on my consoles every time I move my mouse, something to the effect of: May 2 09:53:04 main /kernel: sio0: 103 more tty-level buffer overflows (total 902) Anyone got any ideas what this is? Cheers Andrew To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
silo overflows in CURRENT ... some info that may help
I have been investigating the silo overflow situation for some time. I can trigger them every time by the following action: - Run M.A.M.E. (Multi arcade machine emulator) and then try to download something. (I am using user mode ppp). I believe that the sio driver is its own worst enemy in that once you get one silo overflow, it seems that the driver tries to compensate but it only makes it worse as I continue to get them and the serial port is unusable after that. Exiting MAME doesn't help, I have to reboot or I will be unable to do the smallest thing such as download my mail. I dont think its just MAME but rather anything that thrashes the interrupt system. This is not related to newbus as it occurrred before then in just the same manner. I have seen this effect on my home system no matter what combination of motherboard, modem, serial hardware. I was running a patch to sio.c before newbus came in to improve the speed at which the FIFO buffers were processed but MAME would still trigger the start of the silo overflow storm. With either a patched or unpatched system I can download huge files no problems as long as I dont run MAME at any time. Now dont say just dont do that (I know some of you will want to). Kernel config is attached. /etc/ppp/ppp.conf (edited) is attached. dmesg output is also attached. -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973# Machine with Ultra DMA 32 Bit WD disk, ATAPI CD-ROM, SB16, NE2000 NIC, # NCR PCI SCSI, APM and Intel PIIX power management. # $Id: MATTE,v 11.8 1999/05/02 01:06:00 +09:30 matt Exp $ # based on: $Id: LINT,v 1.589 1999/04/24 21:45:44 peter Exp $ # machine i386 ident MATTE maxusers20 options INCLUDE_CONFIG_FILE # Include this file in kernel config kernel root on wd0 cpu I686_CPU options CPU_DISABLE_5X86_LSSER # Dont use if you use memory mapped I/O device(s). options CPU_FASTER_5X86_FPU # Faster FPU exception handler options NO_F00F_HACK# Disable Pentium F00F hack # COMPATIBILITY OPTIONS options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options USER_LDT# Let processes manipulate their local descriptor table (needed for WINE) options SYSVSHM # Enable SYSV style shared memory options SYSVSEM # Enable SYSV style semaphores options SYSVMSG # Enable SYSV style message queues options MD5 # Include a MD5 routine in the kernel options VM86# Allow processes to switch to vm86 mode (needed for doscmd) # DEBUGGING OPTIONS options DDB # Enable the kernel debugger #optionsINVARIANTS # Extra sanity checking (slower) #optionsINVARIANT_SUPPORT # Include sanity checking functions options UCONSOLE# Allow users to grab the console options USERCONFIG # Boot -c editor options VISUAL_USERCONFIG # Visual boot -c editor # NETWORKING OPTIONS options INET# Internet communications protocols # Network interfaces: pseudo-device ether # Generic Ethernet pseudo-device loop# Network loopback device pseudo-device tun 1 # Tunnel driver(user process ppp) pseudo-device streams # SysVR4 STREAMS emulation # FILESYSTEM OPTIONS options FFS # Berkeley Fast Filesystem options FFS_ROOT# FFS usable as root device options NFS # Network Filesystem options CD9660 # ISO 9660 Filesystem options MFS # Memory Filesystem options MSDOSFS # MSDOS Filesystem options PROCFS # Process Filesystem options NSWAPDEV=4 # Allow this many swap-devices options SOFTUPDATES # SoftUpdates aka delayed writes controller pci0 controller ncr0 options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L # SCSI DEVICE CONFIGURATION (CAM SCSI) controller scbus0 at ncr0 # Base SCSI code diskda0 at scbus0 target 0 disk
New ATA drivers wont boot if second IDE controller enabled
I have been unable to use my Ultra DMA ATAPI CD-ROM since version 4 of Soren's ATAPI driver. Version 4 worked fine but since then (since at least version 6 I didn't try version 5) The system wont boot if I have my secondary IDE controller enabled. The system never completes its kernel probing, it just sits there after configuring the hard disk. I am running an IBM 6.48 GB (metric GB) hard disk on the first IDE controller as the master. I am running a Diamond Data 32 speed Ultra DMA CD-ROM on the second IDE controller and it doesnt matter if its a slave or master (there is nothing else on the controller). The CD-ROM is model number 632A 023 and is made in June 1998. Diamond Data is a trade mark of Mitsubishi Electric Australia. My -CURRENT is only a few hours old (freshly build world and kernel). Kernel config file and dmesg output are attached. -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973# Machine with Ultra DMA 32 Bit WD disk, ATAPI CD-ROM, SB16, NE2000 NIC, # NCR PCI SCSI, APM and Intel PIIX power management. # $Id: MATTE,v 11.8 1999/05/02 01:06:00 +09:30 matt Exp $ # based on: $Id: LINT,v 1.589 1999/04/24 21:45:44 peter Exp $ # machine i386 ident MATTE maxusers20 options INCLUDE_CONFIG_FILE # Include this file in kernel config kernel root on wd0 cpu I686_CPU options CPU_DISABLE_5X86_LSSER # Dont use if you use memory mapped I/O device(s). options CPU_FASTER_5X86_FPU # Faster FPU exception handler options NO_F00F_HACK# Disable Pentium F00F hack # COMPATIBILITY OPTIONS options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options USER_LDT# Let processes manipulate their local descriptor table (needed for WINE) options SYSVSHM # Enable SYSV style shared memory options SYSVSEM # Enable SYSV style semaphores options SYSVMSG # Enable SYSV style message queues options MD5 # Include a MD5 routine in the kernel options VM86# Allow processes to switch to vm86 mode (needed for doscmd) # DEBUGGING OPTIONS options DDB # Enable the kernel debugger #optionsINVARIANTS # Extra sanity checking (slower) #optionsINVARIANT_SUPPORT # Include sanity checking functions options UCONSOLE# Allow users to grab the console options USERCONFIG # Boot -c editor options VISUAL_USERCONFIG # Visual boot -c editor # NETWORKING OPTIONS options INET# Internet communications protocols # Network interfaces: pseudo-device ether # Generic Ethernet pseudo-device loop# Network loopback device pseudo-device tun 1 # Tunnel driver(user process ppp) pseudo-device streams # SysVR4 STREAMS emulation # FILESYSTEM OPTIONS options FFS # Berkeley Fast Filesystem options FFS_ROOT# FFS usable as root device options NFS # Network Filesystem options CD9660 # ISO 9660 Filesystem options MFS # Memory Filesystem options MSDOSFS # MSDOS Filesystem options PROCFS # Process Filesystem options NSWAPDEV=4 # Allow this many swap-devices options SOFTUPDATES # SoftUpdates aka delayed writes controller pci0 controller ncr0 options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L # SCSI DEVICE CONFIGURATION (CAM SCSI) controller scbus0 at ncr0 # Base SCSI code diskda0 at scbus0 target 0 diskda1 at scbus0 target 1 diskda2 at scbus0 target 2 diskda3 at scbus0 target 3 diskda4 at scbus0 target 4 diskda5 at scbus0 target 5 diskda6 at scbus0 target 6 options SCSI_DELAY=500 # Only wait 0.5 seconds for SCSI # MISCELLANEOUS DEVICES AND OPTIONS pseudo-device pty 64 # Pseudo ttys - can go as high as 256 pseudo-device gzip#
Re: Lastest ATA/ATAPI driver boots with kernel.debug only.
I've found that I need to disable my secondary IDE controller with the version 5 and 6 of the new ATAPI drivers. It's probably something to do with Ultra DMA support as I have an Ultra DMA 6.48 GB IBM drive on my IDE controller 0 (master) and a Ultra DMA Mitsubishi 32 spin CD-ROM drive as slave on my second IDE controller. By the way, the IBM 6.48 GB drive is working fine in UDMA2... Lovely. Too bad my drive cant do tagged queueing. There must be a problem with the UDMA CDROMs as with my second IDE controller enabled, I never boot it just never gets to the changing root device to bit. dmesg attached with second controller disabled also old boot messages attached for ATAPI driver version 4 when I could have the controller enabled. Natty Rebel wrote: Hello Soren and other -current users, I've used your new ATA/ATAPI driver flawlessly through the 4th version. I was not able to get past the 'changing root device to wd0s1a' message with version 5, so I just went back to the wd driver. Last nigh I tried version 6 and ran into the same problem. I finally decided to do a little investigating. First I found that I could do a 'ctrl-alt-del' to reboot. I then decided to install the debug kernel doing a 'make install.debug' in my kernel build directory. Lo! and behold! to my surprise my box booted flawlessly. The questions I have are 1) Why did the debug kernel boot and not the kernel without debug symbols? 2) What procedures/tools should I use to investigate this further? Of course any help/pointers are appreciated ... Thanxs. #;^) i'khala -- natty rebel harder than the rest ... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Fri Apr 16 23:03:56 CST 1999 m...@localhost:/usr/src/sys/compile/MATTE Timecounter i8254 frequency 1193182 Hz CPU: Celeron (463.91-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 = 67108864 (65536K bytes) config pnp 1 0 bios enable avail memory = 62177280 (60720K bytes) Preloaded elf kernel kernel at 0xc02eb000. Preloaded userconfig_script /boot/kernel.conf at 0xc02eb09c. Preloaded elf module splash_bmp.ko at 0xc02eb0ec. Pentium Pro MTRR support enabled, default memory type is uncacheable module_register_init: module_register(splash_bmp, c02e760c, 0) error 2 Probing for devices on PCI bus 0: chip0: Intel 82443BX host to PCI bridge rev 0x03 on pci0.0.0 chip1: Intel 82443BX host to AGP bridge rev 0x03 on pci0.1.0 chip2: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.7.0 ata-pci0: Intel PIIX4 IDE controller rev 0x01 on pci0.7.1 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 intpm0: Intel 82371AB Power management controller rev 0x02 on pci0.7.3 intpm0: I/O mapped 5000 ALLOCED IRQ 0 intr IRQ 9 enabled revision 0 intsmb0: Intel PIIX4 SMBUS Interface smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped 4000 vga0: Tseng Labs ET6000 graphics accelerator rev 0x30 int a irq 255 on pci0.11.0 ncr0: ncr 53c810 fast10 scsi rev 0x02 int a irq 11 on pci0.13.0 Probing for devices on PCI bus 1: Probing for PnP devices: CSN 1 Vendor ID: CTL0024 [0x24008c0e] Serial 0x100a1ec0 Comp ID: PNP0600 [0x0006d041] Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 12 virtual consoles, flags=0x0 ed0 at 0x300-0x31f irq 9 on isa ed0: address 00:00:e8:20:33:e8, type NE2000 (16 bit) atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 irq 12 on isa psm0: model Generic PS/2 mouse, device ID 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in ppc0 not found vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface apm0 on isa apm: found APM BIOS version 1.2 joy0 at 0x201 on isa joy0: joystick sb0 at 0x220 irq 5 drq 1 on isa snd0: SoundBlaster 16 4.13 sbxvi0 at drq 5 on isa snd0: SoundBlaster 16 4.13 sbmidi0
Re: ftp hangs on -current
How many of you are using RealTek network cards ? They are crap in my experience (under any OS). Bret Ford wrote: Wednesday, April 14, 1999, 10:25:11 AM, you wrote: I am getting problems similar to those outlined above. I don't run natd, either, but I do have a firewall enabled. (open rule) I've had to 'put' files rather than 'get' them, since my last build/installworld. (Yesterday's -current source) TP I am not running any firewall but my last cvsup which is also current was the same day as yours. i'm still experiencing this strange problem too. developers, where are you? :) Let's continue this thread in capital letters. We might attract some attention! ;-) I CAN'T FTP OUT FROM MY -CURRENT SYSTEM. I CAN FTP IN. SOMETHING IS PROBABLY WRONG. I CAN LIST DIRECTORIES, USUALLY. 'GET' COMMANDS HANG. I AM RUNNING -CURRENT FROM MORNING APR 13. THANKS! BRET FORD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: cvsup
Whats the posibility of having another process for the display ? Naturally this would only be forked if the DISPLAY env is set and the user didnt refuse GUI mode. John Polstra wrote: Thomas Schuerger wrote: cvsup is mostly based on disk (and network) I/O, so there shouldn't be a problem with properly updating the GUI. Someone said it is done in a separate process, so I still wonder why the GUI is updated so slowly on my PII/450. Not a separate process -- a separate thread. It uses user-level threads. If the process blocks in a disk I/O call, all threads stop until the call completes. That's just the way Unix works. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Self-interest is the aphrodisiac of belief. -- James V. DeLong To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: swap-related problems
There is obviously a problem when all swap is exhausted. The only solution is to allow the additional memory *use* to succeed AND to warn the sysadmin that ALL virtual memory has been exhausted. The only way to do this is to be able to allocate extra virtual memory. I'd vote for a system that would create swap files in the largest mounted read/write filesystem of type UFS or in the filesystem of my choice. There would be a systctl to set the limits on how much space to allocate. Possibly a setting for size and number of emergency swap files. When the time comes for killing processes, you should be able to specify that certain processes (by name) are precious and that processes owned by particular users and/or particular login classes are in the last resort or first resort for killing. I dont think it's worth trying to signal with a different signal because only FreeBSD specific programs will know what to do when signalled in such a manner. I suppose you could signal prior to killing as another layer to my dream system. Warner Losh wrote: In message 199904142340.taa96...@misha.cisco.com Mikhail Teterin writes: : Then, one can write a safe malloc, which will install the signal : handler, and touch every page in the the memory referenced by the : to-be-returned pointer. If the signal handler is invoked in the : progress, the to-be-returned memory must be returned back to the : system and NULL should be returned to the caller. This won't work all the time. FreeBSD overcommits swap space and you may get a SIGKILL even if you've touched all the pages. FreeBSD kills processes when swap space runs out. : However, my (in)ability to propose anything remotely sensible does : not change the facts established in this painful thread. That our : malloc does not conform to standards (for whatever reasons), and : that something should be done about it. That something must start : with documenting the flaw... The behavior is documented: The malloc() and calloc() functions return a pointer to the allocated memory if successful; otherwise a NULL pointer is returned. What the system does when it has resource shortages is beyond the scope of the ANSI-C standard, so I don't see why you say that FreeBSD's malloc isn't standard conforming. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: swap-related problems
Replying to myself... You'd have to be able to specify the absolute maximum memory use for a process to ensure you'd still kill run-aways (These would go first! regardless of the other rules maybe). Matthew Thyer wrote: There is obviously a problem when all swap is exhausted. The only solution is to allow the additional memory *use* to succeed AND to warn the sysadmin that ALL virtual memory has been exhausted. -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: RealTek driver woes
There are certain RealTek chipsets that perform very badly in both Windows and FreeBSD in my experience. This is due to poor hardware design as far as the FreeBSD driver author could see. Replace your network card with a $30 PCI 10/100 card that is not a RealTek such as the VIA Technologies VT3043 `Rhine I' and VT86C100A `Rhine II' chips and you'll get much better performance (FreeBSD 'vr' driver). Search the cvs-all mailing list archives for mail re: the 'rl' driver. In my experience: A no-one could get files from a firend of mine's Windows 95 box but he copy them to other peoples machines. If you did manage to get a small file it was corrupt. Under FreeBSD we had the same lockups you are having (using UTP). If we used coax (BNC) it worked fine. This was all at 10 Mbps. We didn't test Windows on coax. Now that we have put a Rhine based card in his machine both Windows and FreeBSD are working fine at ~1 MB/s through put (at 10 Mbps) and NFS is working fine. On Thu, 25 Mar 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: I'm running a RealTek ethernet card in a 486dx4-100 machine and am having some problems. Firstly, doing an ls on a nfs mounted directory exported from the RealTek machine hangs. According to tcpdump it is receiving the readdir packets. Secondly, it will hange solidly when acting as the receiver (haven't tried it as the sender) running the netpipe tests (NPtcp -s -r receiving, the sender runs NP -t -h host_rl -s) - no DDB, just a solid hang. An ISA SMC card in the same machine is fine. I've tried it with RL_USEIOSPACE defined and undefined. This is running a very current system, with the id string $Id: if_rl.c,v 1.12 1999/02/23 15:38:25 wpaul Exp$ Here's the dmesg output. Copyright (c) 1992-1999 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: Thu Mar 25 21:37:03 WST 1999 t...@bloop.craftncomp.com:/data/src/sys/compile/bleep Timecounter i8254 frequency 1193182 Hz CPU: AMD Enhanced Am486DX4 Write-Through (486-class CPU) Origin = AuthenticAMD Id = 0x484 Stepping=4 Features=0x1FPU real memory = 16777216 (16384K bytes) avail memory = 13750272 (13428K bytes) Preloaded elf kernel kernel at 0xc02c3000. Preloaded elf module linux.ko at 0xc02c309c. Probing for devices on PCI bus 0: chip0: Host to PCI bridge (vendor=10b9 device=1445) rev 0x00 on pci0.0.0 rl0: RealTek 8139 10/100BaseTX rev 0x10 int a irq 9 on pci0.4.0 rl0: Ethernet address: 00:00:e8:53:a2:3e rl0: autoneg complete, link status good (half-duplex, 10Mbps) Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 ed0 at 0x280-0x29f irq 10 maddr 0xd8000 msize 16384 on isa ed0: address 00:00:c0:d2:b2:72, type SMC8216T (16 bit) atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A pca0 on motherboard pca0: PC speaker audio driver ata0 at 0x1f0-0x1f7 irq 14 on isa fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fd0: 1.44MB 3.5in vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface IP packet filtering initialized, divert enabled, rule-based forwarding disabled, logging disabled ad0: ST34321A/3.11 ATA-4 disk at ata0 as master ad0: 4103MB (8404830 sectors), 8894 cyls, 15 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 0 depth queue changing root device to ad0s2a Stephen -- The views expressed above are not those of PGS Tensor. People often think of research as a form of development -- that it's about doing exactly what you planned, doing it on time, and doing it with resources that you said you'd use. But if you're going to do that, you have to know what you are doing, and if you know what you are doing, it isn't really research. --Dave Liddle, The New Yorker, Feb. 23/Mar.2, 1998, p 84 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send
Soundblaster live soundcard support ?
Is the Creative Labs Soundblaster Live supported under FreeBSD-CURRENT ? This is a PCI card with 3D surround sound (4 speakers). Under Windows it has a soundblaster emulation mode where it emulates a Sound Blaster 16 but the PCI card normally uses a single interrupt and a single I/O port. -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How to power off an ATX power supply machine on shutdown ?
Yes I know now... and it does work the only problem now is that I've only seen it once because I never turn the machine off !! :) On Tue, 16 Feb 1999, Warner Losh wrote: In message pine.bsf.4.05.9902120005080.38269-100...@localhost Matthew Thyer writes: : I have apm in the kernel and it probes as apm v 1.2 but when : the shutdown -p now command is run, the power is not turned : off and I have to hold down the power button for 4 seconds to : turn it off. : : Hows it done ? You need to set apm_enabled=YES in your rc.conf file. Warner /=\ |Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au| \=/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
CTM deltas have stopped 3 days ago
Is something broken or is there a reason for this ? I normally get src-cur and ports-cur. /=\ |Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au| \=/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Aladdin chipset SMBus support available!
I had the same problem with a non Aladin system. I believe the problem is that Takanori's examples no longer work since changes were made to pcisupport.c. Why do I say this ? Because Takanori said so in email to me. I dont understand how it all works but if I show you Takanori's comments maybe you guys will. START Takanori's comments === Commited code on pcisupport.c from 1.88 to 1.89 will break it. If intpm.h is not included,chipset probe code is used instead of the driver probe code. P.S I have forgotten to enclose unused variable in #undef ENABLE_ALART with #ifdef ENABLE_ALART - #endif ,so the variable may deleted when it was commited. And currently ENABLE_ALART code will not work properly. END Takanori's comments == On Sun, 14 Feb 1999, Nicolas Souchu wrote: On Sat, Feb 13, 1999 at 05:22:00PM -0500, Brian Feldman wrote: On Sat, 13 Feb 1999, Nicolas Souchu wrote: Hi folks, I've just committed the alpm(4) driver to -current: the Aladdin SMBus driver. Great, my newest mobo is an AcerLabs. With an onboard system management chip (lm7x or w87381), it offers monitoring capabilities to recent Acer based motherboards like the ASUS P5AB. I'm using a matsonic. Example program to fetch temperature or voltages is available at http://www.planet.sci.kobe-u.ac.jp/~takawata/smbus/examples/ There's also an example program to fetch SDRAM info over the smbus. I attach you the detect.c program. It's very simple and may help us in knowing what I2C hardware you have on your mobo. I tried them, and there's the problem: all the ioctl()s they perform return EINTR! Has this driver been tested on many motherboards? Why should I expect an EINTR? Just wondering :) EINTR is odd. It just mean that the device at the address requested on the I2C bus do not respond. I have to translate SMBus errors to the appropriate unix ones. You may also want to know what smbus(4) is: http://www.freebsd.org/~nsouch/iicbus.html Feedbacks are wellcome. Nicholas. PS: A driver is also available for the Intel PIIX4, see intpm(4). -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message Brian Feldman _ __ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message /=\ |Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au| \=/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Disk locks and weird things
Shouldn't a make world take about 10 hours on a P100 ?? -depends on the speed of your disks. You should probably remove all the junk in /usr/obj from previous make worlds, then run make cleandir in /usr/src and then try a make world again. The messages about no such user 'tty' indicate your /etc files are out of date. Use the mergemaster port to keep your /etc files up to date but you'll need to be carefull when adding the new users to /etc/passwd (hint: run vipw after editing /etc/passwd so the password databases are re-created). One last hint: READ THE CURRENT AND CVS-ALL MAILING LISTS IF YOU'RE GOING TO RUN CURRENT! - if you cant be botherred spending the time to do this dont run CURRENT! P.S. If your existing CURRENT system is too old, you may need to try installing a snapshot first you may have to try a few different snapshots before you find one that works... there were some problems a while back with boot disks I think. On Sun, 14 Feb 1999, Erik Funkenbusch wrote: Recently I've been trying to upgrade an early januarrry -current to current -current. I've rebuilt the kernel several times over the last few days (with new cvsup's) so i've eliminated any freak check-in mismatches. During a make world (usually about 10-20 minutes in on my P100) everything just comes to a grinding halt. No disk activity, but the screen saver will kick in (despite the shell being in the middle of said make world). If I switch to any alternate consoles and try to do anything, even an ls, it accesses the disk for a brief second, then hangs as well. Other tasks that don't need to access the disk keep running (such as natd and obviously the screen saver). After waiting about a half hour, I hit the reset and get lots of UNREF FILE's and SUMMARY INFORMATION BAD and BLK(S) MISSING IN BIT MAPS. They all say slavaged or cleared. It doesn't appear to be a problem with the actual disk, since rebooting works fine until I try and build again. Even building the kernel works fine. but doing a make world does not (I don't know if anything else causes this). It never fails in the same place twice either, but it's always the same effect. Additionally, i've been getting No such user 'tty', service ignored messages from ntalk and comsat. I'm sure these services were updated to make use of some tty user or something, but i'd like to know what exactly I should do here. I'm also getting messages from de0 and lo0 that say: de0 XXX: driver didn't set ifq_maxlen Finally, if I try and run top i get: top: cannot read swaplist: kvm_read: Bad address kvm_open: proc size mismatch (11392 total, 680 chunks) top: Out of memory. I assume this is from a newer kernel with older support files (such as top) but since I can't get world to build, I'm kinda stuck.. One more thing. I figured I might try a complete reinstallation so I tried to download the 4.0-snap of 2-11 and was able to successfully create a kern.flp but when I tried to create mfsroot.flp it seems to sit in a loop forever just moving the disk head back and forth. I tried it with several floppies (including the one I was able to successfully create kern.flp on) with the same results. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message /=\ |Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au| \=/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
How to power off an ATX power supply machine on shutdown ?
Sorry if this is inappropriate for -CURRENT but I am mailing here as the answer may be to do with recent committed features to -CURRENT (intpm ??). Anyway, how do I power off a machine on shutdown ? I have apm in the kernel and it probes as apm v 1.2 but when the shutdown -p now command is run, the power is not turned off and I have to hold down the power button for 4 seconds to turn it off. Hows it done ? Do I have to run apmconf -e (The owner hasn't tried this yet) I cant give more info as it's not my machine and I only see it on weekends. /=\ |Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au| \=/ If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time. E. P. Tryon from Nature Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: How do I query system temperature probes ?
Thanks, Takanori, are you going to commit your example code in say /usr/src/share/examples/smbus ? If not can you send me a copy please ? Nicolas Souchu wrote: On Wed, Feb 03, 1999 at 02:51:37PM +1030, Matthew Thyer wrote: I seem to have all the hardware required for querying the temperature probes in the system (At least I can do it from the BIOS). How can I query this info ? I assume I need controller smbus0 and controller intpm0 in my kernel. But do I also need device smb0 at smbus? and/or any of the following: # ici2c network interface # iic i2c standard io # iicsmb i2c to smb bridge. Allow i2c i/o with smb commands. You need: controller intpm0 # the PIIX4 interface controller smbus0 # the SMBus system device smb0 at smbus? # user access to the SMBus Once I have all this stuff in my kernel, what commands do I use to query the probes ?? Takanori Watanabe takaw...@shidahara1.planet.sci.kobe-u.ac.jp as example code to do this. My system is FreeBSD 4.0-CURRENT (of CTM 3722 - but will soon be really -CURRENT) Extract from dmesg: chip0: Host to PCI bridge (vendor=8086 device=7180) rev 0x03 on pci0.0.0 chip1: PCI to PCI bridge (vendor=8086 device=7181) rev 0x03 on pci0.1.0 chip2: Intel 82371AB PCI to ISA bridge rev 0x01 on pci0.7.0 ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.7.1 chip3: Intel 82371AB Power management controller rev 0x01 on pci0.7.3 -- Matthew Thyer Phone: +61 8 8259 7249 Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message -- Matthew Thyer Phone: +61 8 8259 7249 Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
How do I query system temperature probes ?
I seem to have all the hardware required for querying the temperature probes in the system (At least I can do it from the BIOS). How can I query this info ? I assume I need controller smbus0 and controller intpm0 in my kernel. But do I also need device smb0 at smbus? and/or any of the following: # ici2c network interface # iic i2c standard io # iicsmb i2c to smb bridge. Allow i2c i/o with smb commands. Once I have all this stuff in my kernel, what commands do I use to query the probes ?? My system is FreeBSD 4.0-CURRENT (of CTM 3722 - but will soon be really -CURRENT) Extract from dmesg: chip0: Host to PCI bridge (vendor=8086 device=7180) rev 0x03 on pci0.0.0 chip1: PCI to PCI bridge (vendor=8086 device=7181) rev 0x03 on pci0.1.0 chip2: Intel 82371AB PCI to ISA bridge rev 0x01 on pci0.7.0 ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.7.1 chip3: Intel 82371AB Power management controller rev 0x01 on pci0.7.3 -- Matthew Thyer Phone: +61 8 8259 7249 Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Salisbury PO Box 1500 Salisbury South Australia 5108 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
