lock order reversal is 5.2-BETA Nov 26
It did not crash or anything, but the following is printed on console now (addresses ommitted): lock order reversal 1st ... UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201 2nd ... system map (system map) @ /usr/src/sys/vm/vm_map.c:2210 Stack backtrace: backtrace() at backtrace+0x17 witness_lock() at wintess_lock+0x672 _mtx_lock_flags() at _mtx_lock_flags+0xba _vm_map_lock() at _vm_map_lock+0x36 vm_map_remove() at vm_map_remove+0x30 kmem_free() at kmem_free+0x32 page_free() at page_free+0x3b zone_drain() at zone_drain+0x2cf zone_foreach() at zone_foreach+0x45 uma_reclaim() at uma_reclaim+0x17 vm_pageout_scan() at vm_pageout_scan+0x148 vm_pageout() at vm_pageout+0x31b fork_exit() at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = ., ebp = 0 --- Hope, this is usefull. A new kernel -- from today's sources -- is being compiled now. -mi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ath driver not working...
According the the man-page, this is not supposed to happen: ath0: Atheros 5212 mem 0xe020-0xe020 irq 9 at device 11.0 on pci2 ath0: cannot map register space The machine is Sony Vaio TR2/B. The WiFi works fine from Windows (much better than the Orinoco card in another laptop). -mi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: lock order reversal is 5.2-BETA Nov 26
On Thu, Nov 27, 2003 at 07:16:05PM -0500, Mikhail Teterin wrote: It did not crash or anything, but the following is printed on console now (addresses ommitted): lock order reversal 1st ... UMA lock (UMA lock) @ /usr/src/sys/vm/uma_core.c:1201 2nd ... system map (system map) @ /usr/src/sys/vm/vm_map.c:2210 Thanks, this was reported several times already. How about this one? lock order reversal 1st 0xc37abad4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1323 2nd 0xc098d020 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1838 3rd 0xc1036948 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Sorry, backtrace was not logged, so I can not recreate it. -mi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
kmem_mmap_toosmall -- repeatable panic
Hello! I tried to create a cscope's database with about 6200 files listed in the cscope.files. The entire tree (including the cscope.files) is mounted over NFS from a Solaris server. The July 11th kernel would just crash, today's one is more intelligent: kmem_malloc(4096): kmem_mmap_too_small: 275251200 total allocated The machine has 1Gb of RAM and 512Mb of swap... -mi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
On Thu, 17 Jul 2003 22:18:38 +0200 Michael Nottebrock [EMAIL PROTECTED] wrote: = On Thursday 17 July 2003 22:11, Alexander Kabaev wrote: = = -Werror? As doctor said: if it hurts, DON'T DO THAT. = = In the kdelibs case, it's definitely _not_ -Werror =Whatever it is, I haven't seen one shred of evidence of GCC issues in =your messages, just complaints. Just an example: bad code generated is =GCC issue, more strict C++ compliance requirements - not. So what of =these two did you mean? Hi, Alexander! First of all, thank you very much for integrating the new GCC into FreeBSD. The pentium4-specific fixes and optimizations, as well as other compiler's features and improvements are much appreciated. Here is how to reproduce the problem, Michael is talking about. Simply try to build the kdelibs3 (or kdegraphic3, or kdenetwork3) port. It will die soon enough with a C++ error. It look like, indeed, a stricter C++ compliance issue, but it is not, because: . it is triggered by something in /usr/include/c++/3.3 itself . it goes away if you remove the ``-pedantic'' from the Makefiles (find work/kdelibs* -name Makefile | \ xargs sed -i -e 's,-pedantic,,') Note, that it is, indeed, just -pedantic, not the -pedantic-errors. So much so, I was suggesting to our KDE team to add the post-patch entry to the bsd.kde.mk, that would remove ``-pedantic'' automaticly. Yours, -mi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ``Resource temporarily unavailable'' in vi
=Every once in a while, a vi-session dies on me with: = = input: Resource temporarily unavailable =Are you running ksh93 per chance? I've seen this after I started an =OpenGL program such as xscreensaver-demo from ksh93 (however that =could have influenced the terminal settings or whatever is beyond my =current understanding.) I don't use ksh, but it does, indeed, happen when the machine is under heavy use (compiles and what-not -- xscreensaver-demo would, probably, qualify too). -mi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
problem with a file-backed md
Hello! I have a nasty problem with a file-backed md. The file is the Windows' swap file residing on a msdosfs part of the drive. First I tried to just swapon to the md: tmp=`mdconfig -a -t vnode -f /W/pagefile.sys` swapon $tmp But random big-memory programs were hanging. At that stage, even the simple sync(8) was hanging and reboot would report that some processes would not die. So I switched to using that chunk of disk as: newfs /dev/$tmp mount /dev/$tmp /scratch This seems to work initially -- the file system is created at boot. I was able to untar a sizable tarball onto it. I opened a file under /scratch in vi and was able to browse it, but on trying to :q, the editor hung and is still hung as I type this. An attempt to `umount /scratch' is currently hung as: MWCHAN STAT `wdrain D' while a subsequent forcefull `umount -f /scratch' looks slightly different: MWCHAN STAT `devfs D' Attempt to delete the md fails with EBUSY. A big program (kmail) is now hung too, although it is not supposed to look at /scratch: MWCHAN STAT `wdrain D' -- I'm afraid all disk-access is now busted and I'm able to type this only because with my 1Gb or RAM most of the stuff is entirely in cache. The -current kernel is built from Mar 6 sources, but I first observed the problem with an earlier kernel -- a few weeks before. Any hope? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
comms/birda on -current and PalmPilot sync.
Hi! Does the combo in subject work for anyone? I have Win98 on this laptop, too, and it can sync. the palm over the IrDA port. However, with FreeBSD-current it does not work. Birda's irs is running as /opt/bin/irs -y /dev/ptypv -c -d /dev/ttyd1 -Y and I point coldsync to the corresponding ttypv: /opt/bin/coldsync -md -t serial -dsync:5 /dev/ttypv Which produces the following output: Summary of sync configuration: Listen: Type: 0 Device: [/dev/palm] Speed: 0 Protocol: 0 Flags: Known PDAs: The queue of conduits: Conduit: flavors: 0x0004 SYNC Creator/Types: [/] (0x/0x) Path: [[generic]] DEFAULT Headers: Preferences: Inside run_mode_Daemon() Port specified on command line: [/dev/ttypv] Listen type: 0 Protocol: 0 Using [/dev/ttypv] as Palm device. [. waits forever .] Anyone has a success to share? I tried both birda-1.00 from the ports and the later 1.1 -- without visible differences. Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
continuing problems with RealPlayer
Can anyone, please, try the following URL, for example: pnm://rm.content.loudeye.com/~ttt-600111/0619060_0103_00_0002.ra It causes RealPlayer8.cs2 to get SIGABRT on two of my -current systems. I must have it working on at least one machine in the house, but before changing the laptop to -stable, I'd like to find out it will work there :-) The other alternative would be to install Windows... FWIW, I tried with both linux_base and linux_base-6 -- same symptoms. There are other URLs on Amazon's Music shopping, that break it, but one is enough, I guess... [I brought this point up first three weeks ago, in: http://news.gw.com/freebsd.current/29296] Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: continuing problems with RealPlayer
On Sunday 26 January 2003 02:28 pm, Gary Jennejohn wrote: = Mikhail Teterin writes: = Can anyone, please, try the following URL, for example: = = pnm://rm.content.loudeye.com/~ttt-600111/0619060_0103_00_0002.ra = = = Yup, kills my RealPlayer too. -stable or -current? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
keeping the Promise up
Hi! With the day-old -current I have troubles with the Promise-66 IDE add-on card. I have two identical drives connected to it. The one connected to the IDE1 connector is now constantly reported as: ad4: READ command timeout tag=0 serv=0 - resetting ata2: resetting devices .. done This happens with UDMA66 and DMA33. The only way to access the drive reliably is to turn it down into the PIO4 mode, which effectively limits it to 2.5Mb/sec and increases the irq-processing time 10-15 fold. I tried changing the cable -- no effect. This is not the drive either -- when I swapped the two drives (what was connected to IDE1 is now connected to IDE2), the messages did not change -- it was still the ata2 (aka Promise's IDE1 -- ata0 and ata1 being the unused on-board controllers). The previous kernel -- a week or so old worked fine... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
troubles with realplay-er
This Linux program used to work well, but now it crashes (with SIGABRT) some URLs, such as pnm://rm.content.loudeye.com/~iii-600111/0255135_0101_00_0002.ra pnm://rm.content.loudeye.com/~a-600111/0631342_0103_00_0002.ra or hangs... The crashes are persistent -- the same URL will alway cause the SIGABRT. The hangs are intermittent -- after ``killall -9 realplay'' the new instance will play the same URL. Then -- eventually hang on another... -mi P.S. Teaching libfetch about pnm:// together with mplayer would eliminate the need for RealPlayer :-) Ducks... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: troubles with realplay-er
Julian Elischer wrote: AOL me too /AOL troublemakingA 5.0-RELEASE showstopper?/troublemaking -mi On Sat, 4 Jan 2003, Mikhail Teterin wrote: This Linux program used to work well, but now it crashes (with SIGABRT) some URLs, such as pnm://rm.content.loudeye.com/~iii-600111/0255135_0101_00_0002.ra pnm://rm.content.loudeye.com/~a-600111/0631342_0103_00_0002.ra or hangs... The crashes are persistent -- the same URL will alway cause the SIGABRT. The hangs are intermittent -- after ``killall -9 realplay'' the new instance will play the same URL. Then -- eventually hang on another... -mi P.S. Teaching libfetch about pnm:// together with mplayer would eliminate the need for RealPlayer :-) Ducks... 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: pam_setenv() crashes rshd...
Mikhail Teterin [EMAIL PROTECTED] writes: The following patch fixes (works around?) the problem for me (pam_setenv is rather inefficiently implemented by the vendor, BTW), I am the vendor. What's wrong with pam_setenv()? I only went into the code to see where it may be crashing my rshd and noticed the mild inefficiency. Did not know where the code is from either. Sorry if I offended you. The pam_setenv and pam_putenv are backwards, IMHO. putenv should be using setenv -- not the other way around. Currently, the setenv takes NAME and VALUE separately, mallocs a new buffer, sprintfs %s=%s into it, sends the buffer to putenv, which re-parses it and frees it. I think, pam_setenv should be doing the actual dirty work, with putenv being a wrapper. This would save some cycles (and, possibly, syscalls -- from malloc), but, of course, it would not be very significant with todays hardware, yada, yada... Would you have any other comments about my original post -- why is pam_setenv causing the segfault somewhere, and is there anything wrong with my patch? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pam_setenv() crashes rshd...
The rshd started to crash on my system after the recent -current upgrade. It does not dump core (why?), but with a lot of syslog() I narrowed the trouble spot down to the pam_setenv() calls -- the very first one of them, in rshd.c never returned... The libpam is: /usr/lib/libpam.so.2: $FreeBSD: src/lib/csu/i386-elf/crti.S,v 1.6 2002/05/15 04:19:49 obrien Exp $ $FreeBSD: src/lib/csu/i386-elf/crtn.S,v 1.5 2002/05/15 04:19:49 obrien Exp $ $FreeBSD: src/lib/libpam/libpam/pam_std_option.c,v 1.10 2002/04/14 18:30:03 des Exp $ $FreeBSD: src/lib/libpam/libpam/pam_debug_log.c,v 1.8 2002/04/14 16:44:04 des Exp $ The following patch fixes (works around?) the problem for me (pam_setenv is rather inefficiently implemented by the vendor, BTW), but is probably wrong in some other aspect. If it is not, it will probably make rshd a bit cleaner and faster... Please, review... Thanks! -mi Index: rshd.c === RCS file: /home/ncvs/src/libexec/rshd/rshd.c,v retrieving revision 1.46 diff -U2 -r1.46 rshd.c --- rshd.c 2002/06/26 17:09:08 1.46 +++ rshd.c 2002/12/20 19:44:33 @@ -182,6 +182,4 @@ } -extern char **environ; - void doit(struct sockaddr *fromp) @@ -476,10 +474,9 @@ if (*pwd-pw_shell == '\0') pwd-pw_shell = bshell; - (void) pam_setenv(pamh, HOME, pwd-pw_dir, 1); - (void) pam_setenv(pamh, SHELL, pwd-pw_shell, 1); - (void) pam_setenv(pamh, USER, pwd-pw_name, 1); - (void) pam_setenv(pamh, PATH, _PATH_DEFPATH, 1); - environ = pam_getenvlist(pamh); (void) pam_end(pamh, pam_err); + (void) setenv(HOME, pwd-pw_dir, 1); + (void) setenv(SHELL, pwd-pw_shell, 1); + (void) setenv(USER, pwd-pw_name, 1); + (void) setenv(PATH, _PATH_DEFPATH, 1); cp = strrchr(pwd-pw_shell, '/'); if (cp) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current unusable after a crash
The only way to get my -current system back to normal after a crash is to boot into single user and do an explicit ``fsck -p''. Otherwise the system will, seemingly, boot fine, but none of the ttyvs will accept any input, although tty-switching works fine. Remote connections (ssh, telnet) don't bring up the login prompt. I thought, this might be due to the priority of the background fsck and have once left it alone for several hours -- with no effect. The usual fsck takes a few minutes. There are three drives in the system -- a 4G SCSI (on ahc0) with /, /usr, /opt, and /home on it, and two 30Gb IDEs coupled into one big ccd. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current unusable after a crash
On Monday 25 November 2002 12:24 pm, Kris Kennaway wrote: = On Mon, Nov 25, 2002 at 10:24:46AM -0500, Robert Watson wrote: = = I thought, this might be due to the priority of the background = fsck and have once left it alone for several hours -- with no = effect. The usual fsck takes a few minutes. = = We really need to disable background fsck if the system panicked. Otherwise, is there a need for fsck at all? Can sudden powerloss be reliably distinguished from a panic? = I've seen far too much bizarre filesystem behaviour that went away the = next time I did a full fsck. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
New NVidia drivers on -current
Has anyone tried them yet? After removing the #error triggered by __FreeBSD_version being over 50, I got the thing nvidia.ko to build, but: 00:50:30 aldan shutdown: reboot by root: New world, kernel. Nvidia drivers 00:56:12 aldan kernel: Preloaded elf module /boot/kernel/nvidia.ko at 0xc06470b0. 00:56:12 aldan kernel: VESA: NVidia 00:56:12 aldan kernel: VESA: NVidia Corporation NV15 Reference Board Chip Rev A0 00:56:14 aldan kernel: nvidia0: GeForce2 GTS mem 0xf000-0xf7ff,0xe900-0xe9ff irq 11 at device 0.0 on pci1 00:56:14 aldan kernel: pcib1: device nvidia0 requested decoded memory range 0xe900-0xe9ff 00:56:14 aldan kernel: pcib1: device nvidia0 requested unsupported memory range 0x0-0xe9ff (decoding 0xe900-0xe9ff, 0xf000-0xf7ff) 00:56:14 aldan kernel: nvidia0: Unable to allocate NVIDIA memory resource. 00:56:14 aldan kernel: device_probe_and_attach: nvidia0 attach returned 6 Any clues, or is, indeed, a major porting effort required to get it to work on -current? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
dc and PCMCIA still panic
Today's kernel (cvs update-ed 10 minutes ago) keeps panicing when the dc-card is inserted :-/ The panic always happens in Fatal trap 12 [...] db trace pccard_scan_cis([data],0,0) at pccard_scan_cis+0x1a5 pccard_read_cis([data]) at pccard_read_cis+0xb5 [...] whether the card is inserted at run time, or the machine is booted with it inserted... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dc and PCMCIA still panic
Even though it doesn't make sense, can you turn on the debugging information and run again? I use # Let's debug! hw.cbb.debug=1 hw.pccard.debug=1 hw.pccard.cis_debug=1 hw.cardbus.debug=1 hw.cardbus.cis_debug=1 Actually, I lied... It is a Xircom RealPort Ethernet 10/100 + Modem 56 REM56G -- the xe card. Rebooting now to try the switches above. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: kmem_malloc(4096): kmem_map too small
... 218222592 total allocated this machine has a total of 512Mb of RAM, and no swap. No X was running. Just ``cvs update''-ing. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: kmem_malloc(4096): kmem_map too small
îÅĦÌÑ 06 öÏ×ÔÅÎØ 2002 03:13 am, n0g0013 ÷É ÎÁÐÉÓÁÌÉ: On 06.10-03:06, Mikhail Teterin wrote: this machine has a total of 512Mb of RAM, and no swap. No X was running. Just ``cvs update''-ing. running vinum ? i am getting this consistently with vinum (but am taking an age to rebuild. No, this is my laptop :-) did you get a backtrace ? . . . to vfs allocations . . . and a second panic on syncing disks ? No... With today's kernel, machine has already _frozen_ after swappager complained about lack of swap. Rather sad -- a not so uncommon installation with 128Mb of memory plus twice that much of swap would still have less virtual memory than this box, which seems to be suffering because all its memory is real... BTW, what happened to the NO_SWAPPING kernel option? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: laptop panicked [with trace]
* De: Mikhail Teterin [EMAIL PROTECTED] [ Data: 2002-10-02 ] [ Subjecte: laptop panicked [with trace] ] With today's -current. No X11, two ttyv0 in use -- cvs updating, the other -- playing hack(6): This is known; A temporary fix is to modify the part dereferencing p-p_limit to check for NULL first. jhb@ is working on a proper fix, I believe. I rebuilt the kernel Friday morning (after cvs update-ing), and got the same panic (up to the Xintr14() line inclusive). kern_synch.c's version is 1.201. The laptop has fairly fast CPU (PII-400) and 512Mb of RAM, but painfully slow harddrive (intr 14 is ata). May be, that's the clue? -mi Fatal trap 12: page fault while in kernel mode fault virtual address = 0xbc [... retyped, not copy-pasted, seemingly random numbers marked ``skipped'' ...] kernel: type 12 trap, code=0 Stopped at mi_switch+0x186:movl0xbc(%ecx),%edx db trace mi_switch(c159b270,0,c0340d60,183,4) at mi_switch+0x186 ithread_schedule(c4086200,1,c03ae560,c4074270,296) at ithread_schedule+0x135 sched_ithd(e) at Xintr14+0x6a Xintr14() at Xintr14+0x6a --- interrupt, eip = 0xc02f101f, esp = 0xd7b88c44, ebp = 0xd7b88c50 cpu_unpend( [skipped] ) at cpu_unpend+0x2f cpu_critical_exit( [skipped] ,1) at cpu_critical_exit+0x15 critical_exit( [skipped], [skipped], 1b2, [skipped] ) at critical_exit+0x24 _mtx_unlock_spin_flags( [skipped],0,[skipped],1b3,[skipped] ) at _mtx_unlock_spin_flags+0xbd exit1([skipped],0,[skipped],6f,[skipped]) at exit1+0xb15 sys_exit( [skipped] ,418,1) at sys_exit+0x41 syscall(2f,2f,2f,bfbffd98,3) at syscall+0x2be Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall(1, FreeBSD ELF32, sys_exit), eip = 0x807af27, esp = bfbffc3c, ebp = 0xbfbffd50 db I'm going to leave it in this sorry state overnight -- if you'd like me to check something else before rebooting -- please, respond. Thanks, -mi -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Juli Mallett [EMAIL PROTECTED] | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: signal 6 to XFree86 (Re: cvs commit: src/tools/tools...)
[Moved to -current] On Fri, Oct 04, 2002 at 06:30:09PM -0700, Lars Eggert wrote: Wesley Morgan wrote: I had one today, they have decreased significantly since removing the Type1 module from my server configuration. I've also found that disabling xscreensaver/xlockmore helps - or just set it to blank screen only. (Some of those graphical modules use beziers.) My XFree86 crashes pretty much every time I turn my back on my PC for a few minutes and let xscreensaver kick in. I don't use screensaver -- my belief is, that the power switch is the best form of screensaving :-) But I do use the Xft library (through KDE) and the xtt.o module (not Type1, though). -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
hack(6) does not run in xterm!
Just noticed on my FreeBSD 5.0-CURRENT #0: Thu Sep 26 11:07:24 EDT 2002 % hack Terminal must backspace. Here is the end of the ktrace: [...] 41386 hack RET break 0 41386 hack CALL break(0x8089000) 41386 hack RET break 0 41386 hack CALL ioctl(0x1,TIOCGETA,0xbfbff6a0) 41386 hack RET ioctl 0 41386 hack CALL ioctl(0x1,TIOCGETA,0xbfbff660) 41386 hack RET ioctl 0 41386 hack CALL ioctl(0x1,TIOCGWINSZ,0xbfbff6c0) 41386 hack RET ioctl 0 41386 hack CALL ioctl(0,TIOCSETP,0x807eeac) 41386 hack RET ioctl 0 41386 hack CALL ioctl(0,TIOCSLTC,0x807e534) 41386 hack RET ioctl 0 41386 hack CALL write(0x1,0x807e5a0,0x19) 41386 hack GIO fd 1 wrote 25 bytes Terminal must backspace. 41386 hack RET write 25/0x19 41386 hack CALL exit(0x1) On my system at home: FreeBSD 5.0-CURRENT #0: Mon Aug 19 00:18:21 EDT 2002 it still works... If I setenv TERM to cons25 in xterm, it will come up too... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
laptop panicked [with trace]
With today's -current. No X11, two ttyv0 in use -- cvs updating, the other -- playing hack(6): Fatal trap 12: page fault while in kernel mode fault virtual address = 0xbc [... retyped, not copy-pasted, seemingly random numbers marked ``skipped'' ...] kernel: type 12 trap, code=0 Stopped at mi_switch+0x186:movl0xbc(%ecx),%edx db trace mi_switch(c159b270,0,c0340d60,183,4) at mi_switch+0x186 ithread_schedule(c4086200,1,c03ae560,c4074270,296) at ithread_schedule+0x135 sched_ithd(e) at Xintr14+0x6a Xintr14() at Xintr14+0x6a --- interrupt, eip = 0xc02f101f, esp = 0xd7b88c44, ebp = 0xd7b88c50 cpu_unpend( [skipped] ) at cpu_unpend+0x2f cpu_critical_exit( [skipped] ,1) at cpu_critical_exit+0x15 critical_exit( [skipped], [skipped], 1b2, [skipped] ) at critical_exit+0x24 _mtx_unlock_spin_flags( [skipped],0,[skipped],1b3,[skipped] ) at _mtx_unlock_spin_flags+0xbd exit1([skipped],0,[skipped],6f,[skipped]) at exit1+0xb15 sys_exit( [skipped] ,418,1) at sys_exit+0x41 syscall(2f,2f,2f,bfbffd98,3) at syscall+0x2be Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall(1, FreeBSD ELF32, sys_exit), eip = 0x807af27, esp = bfbffc3c, ebp = 0xbfbffd50 db I'm going to leave it in this sorry state overnight -- if you'd like me to check something else before rebooting -- please, respond. Thanks, -mi -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
troubles with recent -current
Hi! I'm experiencing an increasing amount of problems here, and will try to list them below. Some of this may be well known already, but, hopefully, something will be usefull. Unless I set rc_ng to NO, the ypbind will not start, even though enable_nis_client is set and Starting ypbind is displayed on boot. Attempts to shutdown gracefully result in panic -- negative refcount in vnrele (vfrele?) in vnclose() called from vnclosefile() -- can not be more precise without the serial console and another machine. X-server was working fine up to a few weeks ago. With Sep 17th kernel it began crashing every few days. With today's kernel the whole machine reboots after a few minutes in X11, although it can go through kernel (and/or XFree86-4) build in text only mode. I rebuilt XFree86-4-libraries and -Server to be sure, but it is not helping :-\ sc (or tty*?) appears to be broken -- every once in a while a particular virtual terminal gets locked out. If root was logged in on it, the syslog messages still appear, but there is no cursor and no input. The sure way to replicate is to try to login somewhere with ssh. After the password prompt, the tty is disabled. Actually, I just replicated this with vt instead of sc. Except that in sc-mode, once you leave the tty (with Alt-Fx), you can not get back to it. With vt you can. Exiting elm will hose the tty with vt (TERM set to pcvt25). Running mergemaster with sc will hose the tty too eventually. Actually, ssh does the same to xterm too -- and that's the way to reboot the whole machine. For whatever reason, with vt instead of sc, the Alt key is not usable under X11 -- I usually move windows around with Alt-left-mbutton, which does not work now. Could be a pilot error, of course, for I've never used vt before. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: troubles with recent -current
On Wed, 25 Sep 2002, Mikhail Teterin wrote: [...] Unless I set rc_ng to NO, the ypbind will not start, even though enable_nis_client is set and Starting ypbind is displayed on boot. Locally, I discovered that the hard dependency of ypbind on rpcbind now seems to be broken. Try setting rpcbind_enable=YES explicitly in rc.conf and see if that helps. Gordon already has a bug report from me on this and has plans to resolve it. This is true of some other RPC dependencies also. Thanks, but I have much bigger troubles at the moment :-( The workaround for this one is simple -- rc_ng=NO... FWIW, this -- introducing this sort of instability just two months before the scheduled release -- is a lot more damaging than the stupid trolls, IMO. The finger-breakers should consider leaving the troll alone and switching to super-gluing the pointy hats to the apropriate skulls :-| -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: troubles with recent -current
On Wed, 25 Sep 2002, Mikhail Teterin wrote: FWIW, this -- introducing this sort of instability just two months before the scheduled release -- is a lot more damaging than the stupid trolls, IMO. The finger-breakers should consider leaving the troll alone and switching to super-gluing the pointy hats to the apropriate skulls :-| There are probably going to be a few nits involved in the VFS changes, but there are a number of serious bugs being fixed here. I've been running into a bug on some boxes involving a race condition that occurs when newsyslog runs on a busy system resulting in a inode deadlock. It also may be that many of the problems were bumping into now may merely be existing bugs that are now more visible. I'm sure we made progress. But it would be better, if the few nits were noticed and fixed before committing. They are impossible not to bump into -- judging by the others' responses -- unless, of course, the developers do not routinely use -current as their primary OS. Something we all should be doing now, that the long promised release date is only two months away. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
freeze with the CardBus NIC 3CCFE575BT
Regardless of whether the xl driver is linked into the kernel or loaded as a module, the machine freezes shortly after ifconfig-ing the card. Sunday's -current. Complete freeeze -- can not go into debugger... More information available upon request... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
troubles with the new GCC -- anyone else?
Is it just me, or do others have troubles too? I upgraded yesterday: mi@celsius:~ (101) cc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20020901 (prerelease) With ``-march=pentium2 -mmmx'' . there is a file or two in XFree86-4-Server, that cause an Internal Compiler Error -- fixed with ``-march=pentium2 -mno-mmx'' (same trouble existed with the previous version, AFAIR) . one file in libiconv causes ICE -- the workaround above does not work. But ``-march=pentium -mmmx'' works. . in the kdelibs3, the kdecore/kkeyserver_x11.cpp will not compile regardless of the architecture or optimization flags -- the ICE is in GCC's cp/cp-lang.c:130, due, it seems, to the initialization complexity. Can't think of a workaround :-\ Yours, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2.1-pre imported
On Sunday 01 September 2002 05:58 pm, Alexander Kabaev wrote: = GCC 3.2.1-pre is now in the tree. Please let me know if you see any = problems recompiling your world/kernel. = = Remember to recompile your C++ ports. GCC 3.2 is not binary compatible = with 3.1. Most excellent! Thanks! -mi P.S. I wonder, if pentium[34]/SSE optimizations are working now... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Dual AthlonMP and FreeBSD
Hi! Would FreeBSD (-current or -stable) work (in SMP mode) on a pair of Athlons, or is our SMP only for Intel chips? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
unkillable process :-\
KOffice's kword is stuck here... Can not be killed even with -9. Sits idle, with its window open, but not updating: UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 1042 88248 1 0 96 0 119296 28105 - WWs pm0:00,00 kword /tmp/k Machine is otherwise fine, uptime 12 days -- my work desktop. -current of Tue Jul 16 13:14:05 EDT 2002 vintage. Any clues? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
recent bsd.lib.mk changes
I guess I missed them, but now some of my ports -- which use bsd.lib.mk -- don't work on -current :-\ and I don't know how to fix them in the backward-compatible way. The ports -- such as devel/tcl-memchan, for example, only want to build and install the shared versions of the libraries. I used to define INTERNALLIB to avoid building and installing the static version, but that is now almost reversed -- only the static will be built and nothing will be installed. Any suggestions? For now, can we have some sort of flag be put into the bsd.lib.mk, so the client makefile can check for API-version? Can the future modifications in the share/mk be, please, tested with ports as well as src builds? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: recent bsd.lib.mk changes
On Friday 21 June 2002 04:28 pm, David O'Brien wrote: = On Fri, Jun 21, 2002 at 02:29:33PM -0400, Mikhail Teterin wrote: = I used to define INTERNALLIB to avoid building and installing the = static version, but that is now almost reversed -- only the static = will be built and nothing will be installed. = = The old INTERNALLIB knob was confusion and not really used. An = internal lib is a static lib we create during `make world' because it = reduces compile times (ie, code that is shared). = = I can think of very few reasons to build a .so, but not a .a. Some = people do like to build static binaries. And some people are the opposite. However, for loadable (as in dlopen(3)) plugins, suchs Tcl modules the static libraries are useless at best. Why can't we have some way to explicitly list what is and what is not needed? = Can the future modifications in the share/mk be, please, tested with = ports as well as src builds? Thanks! = = src/share/mk is for /usr/src. If /usr/ports can use the bits, that is = nice. If not ports/Mk/bsd.FOO.mk should be created and used. By this logic, we don't need to install the bsd.*.mk files at all... I, however, disagree. I think they are a great development tool, and have served pretty good so far -- until the very recent and unfortunately incompatible modifications. Note, that they are not even called freebsd.*.mk -- to me, the names implies they are (more or less) consistens among all of the BSDs :-) -- ëÁË, ÷Ù ÒÁÚ×Å ÂÅÚ ÛÐÁÇÉ ÐÒÉÛÌÉ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: recent bsd.lib.mk changes
On Friday 21 June 2002 06:02 pm, David O'Brien wrote: = On Fri, Jun 21, 2002 at 05:46:17PM -0400, Mikhail Teterin wrote: = Why can't we have some way to explicitly list what is and what is not = needed? = = Feel free to send a patch adding ONLYSHAREDLIBS. INTERNALLIB in no = logical way I can think of would lead someone to think that only shared = libs should be built and they should be installed. Here I agree completely. I have always been puzzled by the naming of this knob. But it was the only way to achieve the goal. It is now a different knob entirely -- but under the same name, which is quite confusing. I am thinking, however, of something explicit like: WANT_SHARED_LIB ?= yes WANT_STATIC_LIB ?= yes WANT_PIC_LIB?= yes with the existing NOPROFILE and others to remain as compatibility interfaces for a while, for example: .ifndef WANT_PIC_LIB .ifndef NOPROFILE WANT_PIC_LIB = yes .else WANT_PIC_LIB = no .endif .endif The last change broke not only some ports, but who knows how many personal projects, which where doing the Right Thing (IMO) and used the bsd.*.mk I will not have time to make a patch in a while :-\, however... Any way to determine quickly from inside the Makefile, which version of the bsd.lib.mk is installed? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
IPC, npc, nwfs on -current
Any plans/updates for the subj? I did what was needed to compile the npc and nwfs modules here (proc - thread transitions), but IPX is not even mentioned in NOTES -- any hope? -mi -- ëÁË, ÷Ù ÒÁÚ×Å ÂÅÚ ÛÐÁÇÉ ÐÒÉÛÌÉ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sbin/newfs newfs.8 newfs.c
On Friday 10 May 2002 03:35 pm, Giorgos Keramidas wrote: = On 2002-05-02 23:06, Makoto Matsushita wrote: = = Mikhail.Teterin BTW, whatever became of the effort to make a = Mikhail.Teterin wrapper called mount_mfs? = = See mdmfs(8). It was been there since Jun/2001 (about 10 months = ago). = = By casully skimming through the text of mdmfs(8) I don't see how it = could be used to mount an MFS filesystem from fstab though :/ It could be -- by making a mount_mfs a symlink to mdmfs. That was the compromise agreed on :-\ However, the entire md things is lacking one important feature of the the old mfs. Mfs was using virtual memory, subject to the general memory management by the OS. md will use either a the real RAM (malloc type) or the swap (swap). This is acceptable for many, but not for all. I, for example, don't have a dedicated swap partition to list in the fstab -- I use the Windows' swap file^ (pagefile.sys) instead*. This is also in the /etc/rc.local, so when the /etc/fstab is processed during boot there is no swap at all and mount_mfs-ing fails... -mi ^This should be offered by sysinstall if the dual-boot configuration is detected at the install time. Also, why can swapon(2), or, at least, swapon(8) automaticly handle swapping onto files? *Since md replaced another system -- vn(4), I'll mention another missing feature -- /etc/vntab. I suspect, one has to be a long entrenched veteran of the FreeBSD project to be allowed to push out features (vnconfig, mount_mfs) without providing _complete_ replacements first. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
On Monday 13 May 2002 02:06 am, Terry Lambert wrote: = If you think that providing bits on the link line in dependency = order is a natural way of linking and the proper way of doing = it, how do you explain our improper use of putting object files in = lexical order in libraries and how do you resolve the contradiction = that from a build point of view the lexical order is the proper = way of building and we only get away with that because the = linker doesn't require object files in archive libraries to be = in dependency order (or we manually correct the situation by = duplication)? = I explain the lexical ordering by way of the following commands when = exiting the Makefile in vi in command mode: = = !!ls *.c = J[...] = ISRCS=esc = = 8-). This does not explain anything. Whatever the joke was, I did not get it. The question stands -- why can the object files be given to the linker in arbitrary order, but the the static libraries must be carefully ordered -- possibly even listed multiple times! There is nothing apparent in the .a format, that forces such behaviour. All of our Makefiles list objects in the alphabetical order -- why not sort them once with lorder/tsort and skip the lorder/tsort step from the library build (in bsd.lib.mk)? That would also speed up world-building... = Linking fewer object files into an executable makes the executable = smaller. Smaller executables are better than larger executables from a = putatively smarter linker (personally, I measure linker intelligence = as inversely proportional to the resulting executable size, relative = to the idealized executable size). Terry, NONE of this is relevant to the subject. Nobody is criticizing our linker for not putting UNNEEDED objects into the executables. The gaping hole in the linker, that is the subject of this thread, is the linker's inability to find NEEDED objects, which are right in front of its nose. = I had a big gripe, complete with examples involving famous names, = ready to go. But I will replace it with a much smaller response: = = A craftsman must know his tools. And always seek to improve them. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
Is there a reason for it, or this just a not-yet-implemented feature? It certainly seems like the latter -- why make the user jump through all the sorting/reordering hoops? Generally, this won't be necessary for properly organized code. The code in question is organized by software layering, right, so all you have to do is link the libraries in order? In other words, your answer is: This just a not-yet-implemented feature? = You might also want to consider using -Lpath -llibrary, = instead of trying to link .a's directly. What would this do? Make it all go through the library linking code, instead of the single object archive linking code. a .a file treated as an object is not the same as a library. What's the difference if all I have are the static libraries anyway? I actually tried this, and had the exactly same list of allegedly undefined symbols... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
On Friday 10 May 2002 12:51 pm, Terry Lambert wrote: = Mikhail Teterin wrote: =Is there a reason for it, or this just a not-yet-implemented =feature? It certainly seems like the latter -- why make the user =jump through all the sorting/reordering hoops? = = Generally, this won't be necessary for properly organized code. The = code in question is organized by software layering, right, so all you = have to do is link the libraries in order? = = In other words, your answer is: This just a not-yet-implemented feature? = Actually, it's it would not be necessary, if your code were = organized to best common practices principles. It is not my code. = Or more roughly It's not a feature. == You might also want to consider using -Lpath -llibrary, == instead of trying to link .a's directly. = =What would this do? = = Make it all go through the library linking code, instead of the = single object archive linking code. a .a file treated as an = object is not the same as a library. = = What's the difference if all I have are the static libraries anyway? = I actually tried this, and had the exactly same list of allegedly = undefined symbols... = You can add -lxxx again, and it will only pull in those things = that are missing. Thanks, this makes sense. = ... = = For my information: Why didn't you take John De Bowsky's advice to: = = ld $objlist `lorder $liblist | tsort -q` I tried that before I asked on the mailing list the first time. It did reduce the number of the undefined symbols, but not to zero. = ??? I pointed you at tsort myself, but didn't provide the full command = line like John did because I wanted the pain to be high enough that = you would fix it the right way (reorganzing your library link order = and using ranlib -- ppointed you at that, too) instead of glueing over = the problem. It would probably be quite beneficial if you dropped this paternalistic attitude. Pain high enough... Please... = Or are you on a holy crusade to get tsort incorporated into ld, so = that most of the time, it will take a lot longer to link, with exatly = the same results, since all the code everywhere else on the system has = already solved the link order problem the right way? [The term holy crusade does not help either -- it is not even paternalistic, just plain non-sense...] Tsort is ALREADY incorporated into ld in some shape, because object files on command line or within one .a CAN be misordered. All I ask, is why the collections of object files provided by different static libs are/can not be treated as one big collection. = I have to say that, given a choice between make world taking several = minutes longer and you not having to reorganize your code into logical = component units, vs. it taking less time to do a make world, and one = programmer having to *fix* their code, I have to pick you fixing your = code. Of course. Does not seem like it will come to this, however. = Also, this is a tools problem, and the tools provide a way (even if = it's ugly) to get the behaviour you want, with a single option before = your objects, and another one after. Hmm, no. The only reliable option is to either build a library of all libraries or link the the object files into the executable directly. This, BTW, shows how inconsistent the current situation is -- the linker does not mind misordered object files, but is very picky about the order of static libraries (shared ones are can be misordered too, AFAIK). I don't see how one can sincerely defend its lack of what still appears to be a missing feature. = By the tools people, I mean our linker vendor, the Free Software = Foundation... not anyone in the FreeBSD Project. Ok. Thanks for the pointer. = FreeBSD itself is *incredibly* unlikely to make a local hack to the = GNU toolchain to support what you want being automatic, since David = O'Brien, Peter Wemm, and others have sweat *blood* in order to get = FreeBSD over to as much of the standard toolchain as humanly possible. Many thanks to them. -mi -- ëÁË, ÷Ù ÒÁÚ×Å ÂÅÚ ÛÐÁÇÉ ÐÒÉÛÌÉ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: does the order of .a files matter?
On Friday 10 May 2002 04:35 pm, Terry Lambert wrote:
= Mikhail Teterin wrote:
= = For my information: Why didn't you take John De Bowsky's advice to:
= =
= = ld $objlist `lorder $liblist | tsort -q`
=
= I tried that before I asked on the mailing list the first time. It
= did reduce the number of the undefined symbols, but not to zero.
=
= It's possible that the symbols are truly undefined (e.g. stat64),
= but I think that is unlikely.
= It would probably be quite beneficial if you dropped this paternalistic
= attitude. Pain high enough... Please...
=
= If I sounded paternalistic in my answer, it's because the question
= being asked is really a newby question about how linkers work, and
= really doesn't belong on the -current list.
It looked (and still looks) to me like a bug or an incompleteness. That's
why I involved -current into it. The -stable is unlikely to make the changes
neccessary, but with -current I had hope.
= Here is a more comprehensive answer, which does not leave the solution
= as an exercise for the student:
=
= Most linkers don't do what you want, which is make up for programmer
= incompetence by doing an automatic topological sort on all symbol
= dependencies, regardless of where or in what type of file the symbol
= is defined, because most linkers treat archives and libraries very
= differently than lists of object files.
=
= This is the technically correct thing for them to do.
Doing what you explain by incompetence is no different from listing the
object files (.o) on the linker's command line in an arbitrary order --
say, alphabetically, as done by most of the FreeBSD's own Makefiles. Not
out of incompetence, but rather for neatness sake. The fact, that the
linker has no problems in this case shows the existing inconsitency.
= This only works intra-archive, not inter-archive. For inter-archive,
= you are expected to order the archives in the proper order, and the
This expectation is not even documented anywhere...
= Tsort is ALREADY incorporated into ld in some shape, because object
= files on command line or within one .a CAN be misordered.
= Within one .a, they are only permitted to be misordered if ranlib
= has been run on the archive (see the quotation of the ranlib manual
= page, above).
Your attempt to dodge explaining the other case -- that of misordered
object files _on command line_ has been logged.
= Within multiple .a's, they are handled differently, because linking
= against a .a file does not necessarily pull in all of the object files
= in the archive. *This is intentional; it is by design*.
Design of what? Of linker? If so, the design is inconsistent (broken?),
for it handles the same entities (object files) differently depending on
how they are given to it (in a single .a, on command line, in multiple
.a files).
= It's my understanding that you are making libraries in the first place
= in order to get around command line length limitations, and have
= settled upon archives, rather than incremental linking using ld -r -o
= A.o ${A_OBJS}.
Not quite. The software's original build is broken up into dozens of
interdependent libraries. They had no problems linking together on
neither Solaris, nor AIX, nor HP-UX, nor NT.
= If this is the case, it would probably be a good idea to choose
= which objects go into which library carefully, to avoid ending
= up with undefined symbols.
I'm not (yet) developing this software. I'm just trying to port it!
= Alternately, if you insist on using .a files directly, as if they
= were normal object files, someone has already posted that you should
= probably use the --whole-archive argument, so that the archive
= contents aren't pulled in *only* if they define symbols which are in
= the current undefined symbol list, but to pull them in unconditionally
= (i.e. treat them as a list of object files instead of an archive).
That suggestion I missed. But it looks like --whole-archive will suck in
everything, including the really unneeded objects.
Perhaps, the linkers on the commercial OSes I listed do use some smarter
equivalent of ``--whole-archive'' by default. IMO, it makes sense, since
those, who know, THEIR libraries are organized properly, and care for
the speed of linking can always add --no-whole-archive (or equivalent)
to THEIR makefiles -- speeding up their ``build world''.
= In the end, you will have to have already been told to solve it, in
= this thread, and which I have laid out, in no uncertain terms, in this
= email.
I think, the terms I used to say, that I already solved my problem,
were no less uncertain. My immediate problem that is.
I'm now readying my horse and armor for the trip to figure out, why is
this sort of gymnastics only needed with the OSF toolchain (actually, I
may be wrong here, since I did not _personally_ verify this thing links
on the other systems without the hoop-jumping).
= This, BTW, shows how inconsistent the current situation
Re: does the order of .a files matter?
On Wednesday 08 May 2002 09:52 pm, Terry Lambert wrote: = Mikhail Teterin wrote: [...] = The most frustrating thing is, the number of such symbols varies = greatly with the order, in which I list the libraries on the command = line. Is not the linker supposed to make several runs over the given = libraries if needed? = = No. It doesn't make several runs. It only does that for single = object files. Is there a reason for it, or this just a not-yet-implemented feature? It certainly seems like the latter -- why make the user jump through all the sorting/reordering hoops? = You might also want to consider using -Lpath -llibrary, instead = of trying to link .a's directly. What would this do? Thanks! -mi P.S. Yes, packing all object files into a single giant .a helped... -- Êàê, Âû ðàçâå áåç øïàãè ïðèøëè? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: bad peter
Using ``FreeBSD 5.0-CURRENT #0: Wed Feb 27 02:00:14 EST 2002''. While cvs updating in /usr/ports: TPTE at 0xbfca0348 IS ZERO @ VA 280d2000 panic: bad peter cpuid = 0; lapic.id = 0100 Looks like there was plenty committed to src/sys in the last few hours, so I'm rebuilding the kernel now. Thanks, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: On Wed, Feb 06, 2002 at 01:05:16PM -0500, Mikhail Teterin wrote: Uh, NO! It is not needed by the base system. We really do not want to turn on all the support libs, etc.. that would be needed with this. There is a reason the gcc30 port takes 25 minutes to compile on a fast 1.2 GHz Athlon. That's the thing. gcc30 port, essentially, installs a copy of the compiler already available as part of the base. No it doesn't. 3.0.3 is a very different compiler from 2.95.3. I thought we are moving to gcc-3.x quickly :-) But the other ports, such as lang/gcc295 don't complement the base system either -- they install a full new set under LOCALBASE, instead of just the missing pieces (like gcj). But the base is missing gcj (the port does too for now), so one would be forced to add the port. And the base system does not NEED a java compiler. Alright. But a FreeBSD installation -- might. Can we have those [libbfd and libiberty] installed, at least, to ease the work of the future porter? Nope. That's too brief for a mutually respectful conversation :-\ I know it is your style, but do not accept this answer anyway. All I'm talking about, is that having a functional gcj _available_ on FreeBSD is a good thing. Through the ports collection or as part of the base system. The fact, that nothing in the base requires Java is hardly an argument in itself. Nothing requires Fortran, or the dictionary, or the cal(1) either. But alright, let's say -- ports. gcj and gcjh themselves are installed by the several lang/gcc* ports, but they are not functional (libgcj/libjava are not ported). As a ports committer I might try to fix that, but I think, those ports should complement the base system, and that the base system should provide the bits it already uses itself (like libbfd and libiberty) to the programmers, that use FreeBSD -- install them into /usr/lib and link them _dynamicly_ into the tools. -mi 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: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: Yes it comes as part of binutils. Ok. No we should not go down this path. You've already been told that there is no official libiberty or bfd release. Well, the following URL http://www.gnu.org/manual/bfd-2.9.1/ for example, seems to imply, that there was, in fact, at some point a release 2.9.1 of bfd... It does not quite match the bfd, that's part of -current -- because of your work on bringing the binutils-3.x in. So there is _something_... Every software package that needs either comes with its own copy -- that always has bug fixes or minor changes from all the other copies out there. Well, that would be a porter's job to figure out which changes the package relies on, or which it simply did not bother to sync with the bfd, that comes with binutils. Plenty of packages come bundled with the third-party software, and a good port makes them build with the already installed versions of such software (like zlib, OpenSSL) or with the version available from another port (like c-client). I'd like to take any advice, but it has to be founded. Plenty of pieces of the FreeBSD project are a nightmare -- including the binutils, Why is binutils a nightmare?? I don't find it to be one. You edited out the rest from my list of examples. Ok. You did want to drop Alpha, because supporting the compiler on it seemed too difficult at some point -- how is that for an example? Or do you claim the proposed addition is the most nightmarish of them all? HOW will it help to add software? What is so wrong with compiling the bundled libiberty or bfd that comes with each of the new software when building them? What is so wrong with having libiberty or bfd statically linked into the new software? It is _inelegant_ and is inconsistent with our use of shared libraries for most of the rest of the system. Look, we wanted ssh and we added it. It requires OpenSSL and we added it. Do we link OpenSSL staticly into ssh and/or not install -lssl into /usr/lib? I frankly just don't see what problem it is you are trying to solve. I want libbfd (and libiberty) to be installed as part of the OS. Preferably -- in both, static and dynamic fashions, consistent with the rest of the libraries. I mean, I can add arm-aout or arm-elf binutils to the system through the devel ports, or mingw -- all with their own libbfd, but I don't have access to the native version, which is built as part of the base OS, just never installed? Is not this a bit ridiculous? Why is it ridiculous? Because FreeBSD's base source already includes the libbfd source and builds the library during build. It just does not install it, for some reason. If all targets are enabled, this cross-toolchain ports would not even need their own versions of this libraries, most likely... Personally I don't think a cross-toolchain build should be installing those bits. And in my opinion, they should not even be building those bits for themselves. I mean, I would've come up with a port of this libraries, but it just seems silly to port something, that's already in the base system. P.S. NetBSD installs shared libbfd: http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/gnu/lib/libbfd/ Of the two -- bfd and libiberty, bfd is the one we would have the most success at installing as a shared lib in /usr/lib. Alright! One step at a time... I understand, that this is an additional burden for you as Mr. Binutils, but let's admit, this might be useful and move it from NO! to May be, some day, when someone does the work. Yours, -mi 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: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: On Wed, Feb 06, 2002 at 03:46:22PM -0500, Mikhail Teterin wrote: dynamically linked libiberty would be a nightmare. libbfd and libiberty do not have version numbers, are not maintained (i.e. there is no official releases). every project includes its own libiberty and imho an attempt to find least common denominator will fail Well, they come to FreeBSD as part of the binutils, right? NO! Is that a NO! as in no, it does not come as part of the binutils, or is that a NO! as in I'M NOT GOING TO AGREE WITH ANYTHING YOU SAY? Max told you what a nightmare it would be. He is 110% right. Max only objected to using dynamic versions of this two libraries, BTW. PLEASE take some advice from two people that are experienced in the issues. I'd like to take any advice, but it has to be founded. Plenty of pieces of the FreeBSD project are a nightmare -- including the binutils, and the compilers, and the whole Alpha port, to name a few -- if the postings to this mailing lists (including those from you) are any indication. Yet, we (including you) do them anyway, because they are worth it (for whatever reasons). I'm trying to persuade the audience, that installing the libbfd and libiberty (which we build anyway!) into /usr/lib is also worth the trouble, because it will help add new software through the ports system -- like the gcj-compiler, or different versions of GCC, etc. (With all available targets enabled, preferably.) I mean, I can add arm-aout or arm-elf binutils to the system through the devel ports, or mingw -- all with their own libbfd, but I don't have access to the native version, which is built as part of the base OS, just never installed? Is not this a bit ridiculous? -mi P.S. NetBSD installs shared libbfd: http://wuarchive.wustl.edu/systems/unix/NetBSD/NetBSD-release-1-5/src/gnu/lib/libbfd/ 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: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: http://www.gnu.org/manual/bfd-2.9.1/ for example, seems to imply, that there was, in fact, at some point a release 2.9.1 of bfd... It does not quite match the bfd, No, that document describes the BFD that was included with Binutils 2.9.1. If you looked at another tree of documents you would also think that bfd was at version 5.1.1 (ie, the latest GDB). What part about two of us telling you that there are no released versions (ie, of bfd or libiberty as a unique, separate package) aren't you believing? I know the GNU toolchain, its development, release cycle, and packaging VERY well. I believe, what I see. And that is, FreeBSD includes both -- gdb and gcc, but only one libbfd, thankfully. And I want to be able to use that same libbfd for my own development and for porting of other compilers and tools. This IS the problem I'm trying to solve. WHY do you want to cause this problem of non-matching bits? So they'll be matched and fixed, leading to a better world 8-) This is my last email you on this topic, as you've yet to answer the question of what problem you are trying to solve! See above. Plenty of packages come bundled with the third-party software, and a good port makes them build with the already installed versions of such software (like zlib, OpenSSL) or with the version available from another port (like c-client). Well the GNU bits do not do that. If you report a GDB bug and they find out you weren't using the BFD or Libiberty included with GDB, the bug report would probably be dropped on the floor. Evidently, this does not prevent the FreeBSD project from using the same libbfd for its gdb and gcc. Even though, the presense of both /usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a and /usr/obj/usr/src/i386/ccd/src/gnu/usr.bin/binutils/libbfd/libbfd.a is somewhat mistifying to me, but I'm sure they are built from the same source. No I want to drop Alpha because no one cares about it and not just the compiler, but much more often kernel, WARNS, and other changes break the Alpha. Alright, so you do find it nightmarish. But we still support Alpha, for whatever reason. This means, that the simple it would be a nightmare is not an argument. It is not worth the trouble -- would be, and I'm arguing, that it is not true in this case. HOW will it help to add software? What is so wrong with compiling the bundled libiberty or bfd that comes with each of the new software when building them? What is so wrong with having libiberty or bfd statically linked into the new software? It is _inelegant_ and is inconsistent with our use of shared libraries for most of the rest of the system. Look, we wanted ssh and we added it. Go find a REAL problem to solve than something that you don't like the esthetics of. This is a REAL problem. Your theorem is ugly, so it must be incorrect. (Some famous mathematician) I frankly just don't see what problem it is you are trying to solve. I want libbfd (and libiberty) to be installed as part of the OS. Preferably -- in both, static and dynamic fashions, consistent with the rest of the libraries. That is NOT a problem. That is just some mis-founded goal with no basis of purpose. Well, than nothing is a problem. Which problem is FreeBSD's very existence trying to solve, huh? Why don't we all go and get a life, instead of spending hours in front of the computers? Please... Because FreeBSD's base source already includes the libbfd source and builds the library during build. It just does not install it, for some reason. If all targets are enabled, this cross-toolchain ports would not even need their own versions of this libraries, most likely... FEH!! You are going to patch the nightmare (yes I will use that term to describe this) autoconf and autoMake bits that come with the GNU tools? Good luck! In general with GNU tools, JUST LEAVE THINGS THE WAY THE ORIGINAL AUTHOR INTENDED THEM TO BE. Yes, I very well might. Or, may be, I'll introduce Makefiles of my own -- Something already done for the C compiler and all the other GNU tools in the base, BTW. -mi 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: panic: bdwrite: buffer is not busy
On 10 Feb, Bruce Evans wrote: On Sat, 9 Feb 2002, John Baldwin wrote: On 09-Feb-02 Mikhail Teterin wrote: While attempting to ``fdisk fd0.1440''. Or ``fdisk fd0''. Or ``newfs_msdos fd0.1440'' with or without the floppy inside :-\ With todays or Jan 3rd kernel (my previous upgrade). Only use fdisk on hard disks. Still it shouldn't panic. The bdwrite is just extra garbage, the real panic is due to a NULL pointer dereference: This is a well known bug in the device layer. I reported it on 2001/12/26 and fixed it locally a little later. See the thread in -current about panic during fdisk'ing a md(4) device for patches. Fdisk I don't really need, but attempting to newfs the floppy caused the same panic :-\ And mounting the already formatted floppy leads to invalid argument. Could we have this fixed soon, please? The inability to access a floppy is a great setback for my local FreeBSD advocacy efforts :-) -mi I'm guessing that devsw() is returning NULL here. You could add a KASSERT() to this macro just before the call to d_strategy() along the lines of KASSERT(devsw((bp)-bio_dev) != NULL, (no devsw for bio));\ Right. From my original bug report: ! fdisk /dev/fd0 now causes a null pointer panic in readdisklabel(). ! This is because fdioctl() attempts to construct a (slightly ! wrong) device using dkmodpart(), but dkmodpart() only constructs a ! half-baked device since it only calls makedev(). The device is ! missing a devsw so DEV_STRATEGY() in readdisklabel() panics on it. 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: panic: bdwrite: buffer is not busy
On 10 Feb, Bruce Evans wrote: On Sat, 9 Feb 2002, John Baldwin wrote: On 09-Feb-02 Mikhail Teterin wrote: While attempting to ``fdisk fd0.1440''. Or ``fdisk fd0''. Or ``newfs_msdos fd0.1440'' with or without the floppy inside :-\ With todays or Jan 3rd kernel (my previous upgrade). Only use fdisk on hard disks. Still it shouldn't panic. The bdwrite is just extra garbage, the real panic is due to a NULL pointer dereference: This is a well known bug in the device layer. I reported it on 2001/12/26 and fixed it locally a little later. See the thread in -current about panic during fdisk'ing a md(4) device for patches. Fdisk I don't really need, but attempting to newfs the floppy caused the same panic :-\ And mounting the already formatted floppy leads to invalid argument. Could we have this fixed soon, please? The inability to access a floppy is a great setback for my local FreeBSD advocacy efforts :-) -mi I'm guessing that devsw() is returning NULL here. You could add a KASSERT() to this macro just before the call to d_strategy() along the lines of KASSERT(devsw((bp)-bio_dev) != NULL, (no devsw for bio));\ Right. From my original bug report: ! fdisk /dev/fd0 now causes a null pointer panic in readdisklabel(). ! This is because fdioctl() attempts to construct a (slightly ! wrong) device using dkmodpart(), but dkmodpart() only constructs a ! half-baked device since it only calls makedev(). The device is ! missing a devsw so DEV_STRATEGY() in readdisklabel() panics on it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: bdwrite: buffer is not busy
While attempting to ``fdisk fd0.1440''. Or ``fdisk fd0''. Or
``newfs_msdos fd0.1440'' with or without the floppy inside :-\
With todays or Jan 3rd kernel (my previous upgrade).
IdlePTD at phsyical address 0x004ed000
initial pcb at physical address 0x00411560
panicstr: bdwrite: buffer is not busy
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0x1c
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc022d923
stack pointer = 0x10:0xce9c0b10
frame pointer = 0x10:0xce9c0b24
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 405 (fdisk)
trap number = 12
panic: page fault
cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... panic: bdwrite: buffer is not busy
cpuid = 1; lapic.id =
boot() called on cpu#1
Uptime: 1m40s
pfs_vncache_unload(): 1 entries remaining
(kgdb) where
#0 dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:504
#1 0xc021cee8 in boot (howto=260) at /ccd/src/sys/kern/kern_shutdown.c:336
#2 0xc021d3d9 in panic (fmt=0xc03728c1 bdwrite: buffer is not busy)
at /ccd/src/sys/kern/kern_shutdown.c:646
#3 0xc0253583 in bdwrite (bp=0xc7cb7af4) at /ccd/src/sys/kern/vfs_bio.c:856
#4 0xc02d28ee in ffs_update (vp=0xce8657a0, waitfor=0)
at /ccd/src/sys/ufs/ffs/ffs_inode.c:120
#5 0xc02dff6e in ffs_fsync (ap=0xce9c09cc)
at /ccd/src/sys/ufs/ffs/ffs_vnops.c:292
#6 0xc02de386 in ffs_sync (mp=0xc16cbe00, waitfor=2, cred=0xc1026b00,
td=0xc03cf2c0) at vnode_if.h:441
#7 0xc026034a in sync (td=0xc03cf2c0, uap=0x0)
at /ccd/src/sys/kern/vfs_syscalls.c:669
#8 0xc021cb14 in boot (howto=256) at /ccd/src/sys/kern/kern_shutdown.c:245
#9 0xc021d3d9 in panic (fmt=0xc03914de %s)
at /ccd/src/sys/kern/kern_shutdown.c:646
#10 0xc03299e2 in trap_fatal (frame=0xce9c0ad0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:842
#11 0xc0329709 in trap_pfault (frame=0xce9c0ad0, usermode=0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:756
#12 0xc0329147 in trap (frame={tf_fs = 24, tf_es = -828637168,
tf_ds = -1071513584, tf_edi = -1049875456, tf_esi = 0,
tf_ebp = -828634332, tf_isp = -828634372, tf_ebx = -942596204,
(kgdb) where
#0 dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:504
#1 0xc021cee8 in boot (howto=260) at /ccd/src/sys/kern/kern_shutdown.c:336
#2 0xc021d3d9 in panic (fmt=0xc03728c1 bdwrite: buffer is not busy)
at /ccd/src/sys/kern/kern_shutdown.c:646
#3 0xc0253583 in bdwrite (bp=0xc7cb7af4) at /ccd/src/sys/kern/vfs_bio.c:856
#4 0xc02d28ee in ffs_update (vp=0xce8657a0, waitfor=0)
at /ccd/src/sys/ufs/ffs/ffs_inode.c:120
#5 0xc02dff6e in ffs_fsync (ap=0xce9c09cc)
at /ccd/src/sys/ufs/ffs/ffs_vnops.c:292
#6 0xc02de386 in ffs_sync (mp=0xc16cbe00, waitfor=2, cred=0xc1026b00,
td=0xc03cf2c0) at vnode_if.h:441
#7 0xc026034a in sync (td=0xc03cf2c0, uap=0x0)
at /ccd/src/sys/kern/vfs_syscalls.c:669
#8 0xc021cb14 in boot (howto=256) at /ccd/src/sys/kern/kern_shutdown.c:245
#9 0xc021d3d9 in panic (fmt=0xc03914de %s)
at /ccd/src/sys/kern/kern_shutdown.c:646
#10 0xc03299e2 in trap_fatal (frame=0xce9c0ad0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:842
#11 0xc0329709 in trap_pfault (frame=0xce9c0ad0, usermode=0, eva=28)
at /ccd/src/sys/i386/i386/trap.c:756
#12 0xc0329147 in trap (frame={tf_fs = 24, tf_es = -828637168,
tf_ds = -1071513584, tf_edi = -1049875456, tf_esi = 0,
tf_ebp = -828634332, tf_isp = -828634372, tf_ebx = -942596204,
tf_esp = -942596204, tf_ss = -1049268480})
at /ccd/src/sys/i386/i386/trap.c:426
#13 0xc022d923 in readdisklabel (dev=0xc1756f00, lp=0xc16c2c00)
at /ccd/src/sys/kern/subr_disklabel.c:220
#14 0xc0338c61 in fdioctl (dev=0xc1756e00, cmd=1091855461, addr=0xc16bb200 ,
flag=1, td=0xce8daf04) at /ccd/src/sys/isa/fd.c:2707
#15 0xc01f4d1c in spec_ioctl (ap=0xce9c0ba4)
at /ccd/src/sys/fs/specfs/spec_vnops.c:320
#16 0xc01f499d in spec_vnoperate (ap=0xce9c0ba4)
at /ccd/src/sys/fs/specfs/spec_vnops.c:119
#17 0xc0266fb3 in vn_ioctl (fp=0xc1854bc0, com=1091855461, data=0xc16bb200 ,
td=0xce8daf04) at vnode_if.h:357
#18 0xc0237eeb in ioctl (td=0xce8daf04, uap=0xce9c0d20)
at /ccd/src/sys/sys/file.h:200
#19 0xc0329e98 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077936865, tf_esi = -1077937104, tf_ebp = -1077937112,
tf_isp = -828633740, tf_ebx = -1077937100, tf_edx = -1077936866,
tf_ecx = 134627389, tf_eax = 54, tf_trapno = 12, tf_err = 2,
tf_eip = 134546567, tf_cs = 31, tf_eflags = 659, tf_esp = -1077937504,
tf_ss = 47}) at /ccd/src/sys/i386/i386/trap.c:1034
#20 0xc031945d in syscall_with_err_pushed ()
(kgdb) up 3
#3 0xc0253583 in bdwrite (bp=0xc7cb7af4) at /ccd/src/sys/kern/vfs_bio.c:856
856
How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, Mark Murray wrote: [...] a project as important as GCC3 [...] BTW, how about, may be, if the stars are right, bringing in the Java support too? gcj is now one of the compilers, that come with the GCC package... And it is promising -- it can compile Java into byte code or byte code into native code, supposedly. -mi P.S. Time to run away for a while... Ouch, that was a new asbestos suit! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: On Wed, Feb 06, 2002 at 11:19:19AM -0500, Mikhail Teterin wrote: BTW, how about, may be, if the stars are right, bringing in the Java support too? gcj is now one of the compilers, that come with the GCC package... Uh, NO! It is not needed by the base system. We really do not want to turn on all the support libs, etc.. that would be needed with this. There is a reason the gcc30 port takes 25 minutes to compile on a fast 1.2 GHz Athlon. That's the thing. gcc30 port, essentially, installs a copy of the compiler already available as part of the base. But the base is missing gcj (the port does too for now), so one would be forced to add the port. If it were possible (through a port) to add just gcj (and accompanying libraries) to integrate with the already present gcc and other bits, but it is not :-( Even the things like libiberty and libbfd are not installed... Can we have those installed, at least, to ease the work of the future porter? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: On Wed, Feb 06, 2002 at 01:05:16PM -0500, Mikhail Teterin wrote: Uh, NO! It is not needed by the base system. We really do not want to turn on all the support libs, etc.. that would be needed with this. There is a reason the gcc30 port takes 25 minutes to compile on a fast 1.2 GHz Athlon. That's the thing. gcc30 port, essentially, installs a copy of the compiler already available as part of the base. No it doesn't. 3.0.3 is a very different compiler from 2.95.3. I thought we are moving to gcc-3.x quickly :-) But the other ports, such as lang/gcc295 don't complement the base system either -- they install a full new set under LOCALBASE, instead of just the missing pieces (like gcj). But the base is missing gcj (the port does too for now), so one would be forced to add the port. And the base system does not NEED a java compiler. Alright. But a FreeBSD installation -- might. Can we have those [libbfd and libiberty] installed, at least, to ease the work of the future porter? Nope. That's too brief for a mutually respectful conversation :-\ I know it is your style, but do not accept this answer anyway. All I'm talking about, is that having a functional gcj _available_ on FreeBSD is a good thing. Through the ports collection or as part of the base system. The fact, that nothing in the base requires Java is hardly an argument in itself. Nothing requires Fortran, or the dictionary, or the cal(1) either. But alright, let's say -- ports. gcj and gcjh themselves are installed by the several lang/gcc* ports, but they are not functional (libgcj/libjava are not ported). As a ports committer I might try to fix that, but I think, those ports should complement the base system, and that the base system should provide the bits it already uses itself (like libbfd and libiberty) to the programmers, that use FreeBSD -- install them into /usr/lib and link them _dynamicly_ into the tools. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 7 Feb, Max Khon wrote: dynamically linked libiberty would be a nightmare. libbfd anf libiberty do not have version numbers, are not maintained (i.e. there is no official releases). every project includes its own libiberty and imho an attempt to find least common denominator will fail Well, they come to FreeBSD as part of the binutils, right? That's a good start for a version number/release :-) We don't actually build separate libbfd for linker and assembler, and separate for the compiler, do we? Any additional packages (such as those from ports) should be able to use the same libraries, IMHO, even though they may come with their own versions. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: How about gcj? (Re: Not committing WARNS settings...)
On 6 Feb, David O'Brien wrote: http://www.gnu.org/manual/bfd-2.9.1/ for example, seems to imply, that there was, in fact, at some point a release 2.9.1 of bfd... It does not quite match the bfd, No, that document describes the BFD that was included with Binutils 2.9.1. If you looked at another tree of documents you would also think that bfd was at version 5.1.1 (ie, the latest GDB). What part about two of us telling you that there are no released versions (ie, of bfd or libiberty as a unique, separate package) aren't you believing? I know the GNU toolchain, its development, release cycle, and packaging VERY well. I believe, what I see. And that is, FreeBSD includes both -- gdb and gcc, but only one libbfd, thankfully. And I want to be able to use that same libbfd for my own development and for porting of other compilers and tools. This IS the problem I'm trying to solve. WHY do you want to cause this problem of non-matching bits? So they'll be matched and fixed, leading to a better world 8-) This is my last email you on this topic, as you've yet to answer the question of what problem you are trying to solve! See above. Plenty of packages come bundled with the third-party software, and a good port makes them build with the already installed versions of such software (like zlib, OpenSSL) or with the version available from another port (like c-client). Well the GNU bits do not do that. If you report a GDB bug and they find out you weren't using the BFD or Libiberty included with GDB, the bug report would probably be dropped on the floor. Evidently, this does not prevent the FreeBSD project from using the same libbfd for its gdb and gcc. Even though, the presense of both /usr/obj/usr/src/gnu/usr.bin/binutils/libbfd/libbfd.a and /usr/obj/usr/src/i386/ccd/src/gnu/usr.bin/binutils/libbfd/libbfd.a is somewhat mistifying to me, but I'm sure they are built from the same source. No I want to drop Alpha because no one cares about it and not just the compiler, but much more often kernel, WARNS, and other changes break the Alpha. Alright, so you do find it nightmarish. But we still support Alpha, for whatever reason. This means, that the simple it would be a nightmare is not an argument. It is not worth the trouble -- would be, and I'm arguing, that it is not true in this case. HOW will it help to add software? What is so wrong with compiling the bundled libiberty or bfd that comes with each of the new software when building them? What is so wrong with having libiberty or bfd statically linked into the new software? It is _inelegant_ and is inconsistent with our use of shared libraries for most of the rest of the system. Look, we wanted ssh and we added it. Go find a REAL problem to solve than something that you don't like the esthetics of. This is a REAL problem. Your theorem is ugly, so it must be incorrect. (Some famous mathematician) I frankly just don't see what problem it is you are trying to solve. I want libbfd (and libiberty) to be installed as part of the OS. Preferably -- in both, static and dynamic fashions, consistent with the rest of the libraries. That is NOT a problem. That is just some mis-founded goal with no basis of purpose. Well, than nothing is a problem. Which problem is FreeBSD's very existence trying to solve, huh? Why don't we all go and get a life, instead of spending hours in front of the computers? Please... Because FreeBSD's base source already includes the libbfd source and builds the library during build. It just does not install it, for some reason. If all targets are enabled, this cross-toolchain ports would not even need their own versions of this libraries, most likely... FEH!! You are going to patch the nightmare (yes I will use that term to describe this) autoconf and autoMake bits that come with the GNU tools? Good luck! In general with GNU tools, JUST LEAVE THINGS THE WAY THE ORIGINAL AUTHOR INTENDED THEM TO BE. Yes, I very well might. Or, may be, I'll introduce Makefiles of my own -- Something already done for the C compiler and all the other GNU tools in the base, BTW. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
libmilter (asking for more trouble :)
FreeBSD comes with sendmail, and milter is an increasingly popular part of sendmail -- used by the authors of different spam and virii filtering software. Shouldn't FreeBSD build and install libmilter and the relevant headers, too? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libmilter (asking for more trouble :)
On 6 Feb, Gregory Neil Shapiro wrote: mi FreeBSD comes with sendmail, and milter is an increasingly popular part mi of sendmail -- used by the authors of different spam and virii filtering mi software. mi Shouldn't FreeBSD build and install libmilter and the relevant headers, mi too? It will do so when 8.12 is imported. See: http://people.freebsd.org/~gshapiro/CURRENT-8.12.2 Great! The TLS support will be there too, right? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: today's current: boot/loader and console
Are your loader and 4th files in sync? There was a change to the 4th scripts that I thought I sent a heads up about. Anyways, do this to get the error message: go into /sys/boot/i386/loader, edit main.c, and change the exit() function to do a while(1); loop before callign __exit(). Compile a new loader and install it and then see what message you get. Well, interestingly enough, the problem disappeared after I simply did make make install in /sys/boot/i386/ ... All I did before was the usual buildworld, installworld, buidlkernel, installkernel, mergemaster, reboot. Yours, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
zombie linux processes remain
Hello! I'm sure, this is a bug in the program itself (graphics/mtv v. 1.2.5), but can't we do something about it? Notice the parent process id: UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 105 6536 1 0 96 0 00 - Z p40:00,00 (mtvp) 105 6537 1 4 96 0 00 - Z p40:00,00 (mtvp) 105 6538 1 32 100 0 00 - Z p40:00,00 (mtvp) 105 6539 1 0 96 0 00 - Z p40:00,00 (mtvp) 105 6541 1 2 96 0 00 - Z p40:00,00 (mtvp) 105 6542 1 5 96 0 00 - Z p40:00,00 (mtvp) 105 6543 1 43 101 0 00 - Z p40:00,00 (mtvp) 105 6544 1 0 96 0 00 - Z p40:00,00 (mtvp) 105 6548 1 1 96 0 00 - Z p40:00,00 (mtvp) 105 6549 1 6 96 0 00 - Z p40:00,00 (mtvp) 105 6550 1 34 100 0 00 - Z p40:00,00 (mtvp) 105 6551 1 0 96 0 00 - Z p40:00,00 (mtvp) 105 6553 1 2 96 0 00 - Z p40:00,00 (mtvp) 105 6554 1 7 96 0 00 - Z p40:00,00 (mtvp) 105 6555 1 39 100 0 00 - Z p40:00,00 (mtvp) 105 6556 1 0 107 0 00 - Z p40:00,00 (mtvp) 105 6560 1 3 96 0 00 - Z p40:00,00 (mtvp) 105 6561 1 8 97 0 00 - Z p40:00,00 (mtvp) 105 6562 1 35 100 0 00 - Z p40:00,00 (mtvp) 105 6563 1 0 76 0 00 - Z p40:00,00 (mtvp) 105 6565 1 2 96 0 00 - Z p40:00,00 (mtvp) 105 6566 1 7 96 0 00 - Z p40:00,00 (mtvp) 105 6567 1 43 101 0 00 - Z p40:00,00 (mtvp) 105 6568 1 0 96 0 00 - Z p40:00,00 (mtvp) 105 6572 1 2 96 0 00 - Z p40:00,00 (mtvp) 105 6573 1 8 97 0 00 - Z p40:00,00 (mtvp) 105 6574 1 40 101 0 00 - Z p40:00,00 (mtvp) 105 6575 1 0 96 0 00 - Z p40:00,00 (mtvp) 105 6577 1 2 96 0 00 - Z p40:00,00 (mtvp) 105 6578 1 6 107 0 00 - Z p40:00,00 (mtvp) 105 6579 1 43 101 0 00 - Z p40:00,00 (mtvp) 105 6580 1 0 96 0 00 - Z p40:00,00 (mtvp) 105 6584 1 1 96 0 00 - Z p40:00,00 (mtvp) 105 6585 1 5 96 0 00 - Z p40:00,00 (mtvp) 105 6586 1 38 100 0 00 - Z p40:00,00 (mtvp) 105 6587 1 0 96 0 00 - Z p40:00,00 (mtvp) 105 6591 1 1 96 0 00 - Z p40:00,00 (mtvp) 105 6592 1 6 96 0 00 - Z p40:00,00 (mtvp) 105 6593 1 33 100 0 00 - Z p40:00,00 (mtvp) 105 6594 1 0 96 0 00 - Z p40:00,00 (mtvp) 105 6596 1 1 96 0 00 - Z p40:00,00 (mtvp) 105 6597 1 6 96 0 00 - Z p40:00,00 (mtvp) 105 6598 1 43 98 0 00 - Z p40:00,00 (mtvp) 105 6599 1 0 96 0 00 - Z p40:00,00 (mtvp) 105 6603 1 1 96 0 00 - Z p40:00,00 (mtvp) 105 6604 1 5 96 0 00 - Z p40:00,00 (mtvp) 105 6605 1 32 100 0 00 - Z p40:00,00 (mtvp) 105 6606 1 1 96 0 00 - Z p40:00,00 (mtvp) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: zombie linux processes remain
On 8 Jan, Alfred Perlstein wrote: I'm sure, this is a bug in the program itself (graphics/mtv v. 1.2.5), but can't we do something about it? Notice the parent process id: UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 105 6536 1 0 96 0 00 - Z p40:00,00 (mtvp) 105 6537 1 4 96 0 00 - Z p40:00,00 (mtvp) Some fixes went in recently that might address this, what version of FreeBSD are you using and when was the last update you did? FreeBSD aldan.algebra.com 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Thu Jan 3 21:38:15 EST 2002 [EMAIL PROTECTED]:/ccd/obj/ccd/src/sys/DEBUG i386 -- |\__-__/| _/ : :::\_ '__--( ..::)--__`-mi If you have a / _- \/ :::\/ -_ serious knowledge/ / :. .\ \ about computers -- | | Ok, let's say you broke keep it in a secret! _|/ ::\|_the wall with your head Rules of dating, / /:/:_::\::\:.\ What are you going to 'Playboy', ? 1994 | :| ..:(_/ \::|::|::| do in the next cell? | :|:. ::|: |::|.:| Stanislaw J. Lec \ |:: :::_/::/: :|:/ ((___\\/___/___)) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: today's current: boot/loader and console
On 3 Jan, John Baldwin wrote: On 04-Jan-02 Mikhail Teterin wrote: After 25 days of uptime I rebuilt the world, and can no longer boot as usual. Both boot/loader and boot/loader.old (from Oct 30) flash the list of devices and immediately reset the computer. Any chance you could setup a serial console and catch the output? This is my only computer... My only way to bring it up is to press space at the right moment, get the Boot: prompt and load/boot kernel directly bypassing the loader. This works, but there is no console output (it goes from spinner straight into the login prompt). I guess, the console output is being sent down sio0, where there is an external modem now. Turning the modem off does not change anything... No, you have no console because you have no hints. If you statically compile your hints into your kernel, you will have a console again. Why did it change all of a sudden? Did hints get blown away by installworld at's the point? Why is the serial console default? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: today's current: boot/loader and console
Are your loader and 4th files in sync? There was a change to the 4th scripts that I thought I sent a heads up about. The hints did not change since forever: -r--r--r-- 1 root wheel2030 Feb 10 2001 device.hints Everything else seems fresh: -r--r--r-- 1 root wheel7721 Jan 3 20:34 loader.4th -r--r--r-- 1 root wheel 35097 Jan 3 20:34 support.4th -r-xr-xr-x 1 root wheel 174080 Jan 3 20:34 pxeboot -r-xr-xr-x 1 root wheel 176128 Jan 3 20:34 liloboot drwxr-xr-x 2 root wheel 512 Jan 3 20:34 defaults -r-xr-xr-x 1 root wheel 172032 Jan 3 20:34 loader Anyways, do thisto get the errormessage: go into /sys/boot/i386/loader, edit main.c, and change the exit() function to do a while(1); loop before callign __exit(). Compile a new loader and install it and then see what message you get. Mmm, Ok... Next time I reboot, I'll post the results... Thanks! You don't have a seiral console, you have _no_ kernel console. :) Since you are booting from boot2 and not the loader, your hints aren't getting loaded, so you aren't getting a kernel console. There was time, when direct booting of the kernel was working... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
zombie linux processes
I just noticed a whole bunch of processes, that would not go away :-( [...] 105 55742 1 0 107 0 00 - Z p3- 0:00,00 (mtvp) 105 55744 1 5 98 0 00 - Z p3- 0:00,00 (mtvp) 105 55745 1 5 107 0 00 - Z p3- 0:00,00 (mtvp) 105 55748 1 21 97 0 00 - Z p3- 0:00,00 (mtvp) 105 84170 1 0 96 0 00 - Z p3- 0:00,00 (mtvp) 105 84171 1 1 96 0 00 - Z p3- 0:00,00 (mtvp) 105 84172 1 22 98 0 00 - Z p3- 0:00,00 (mtvp) 105 84173 1 0 96 0 00 - Z p3- 0:00,00 (mtvp) 105 84189 1 0 96 0 00 - Z p3- 0:00,00 (mtvp) 105 84190 1 1 96 0 00 - Z p3- 0:00,00 (mtvp) 105 84191 1 46 101 0 00 - Z p3- 0:00,00 (mtvp) 105 84192 1 1 96 0 00 - Z p3- 0:00,00 (mtvp) [...] As you can see, the parent ID is 1, but they still exist... My -current is from Mon Nov 5 08:47:03 EST 2001... Is this something, that's fixed already? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
today's -current: pseudofs
Although pseudofs is now required for procfs to link, config(8) does not know about it -- my old kernel config file with PROCFS raised no problems until the linking time, when a bunch of pseudofs functions turned out to be absent... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
today's current: boot/loader and console
After 25 days of uptime I rebuilt the world, and can no longer boot as usual. Both boot/loader and boot/loader.old (from Oct 30) flash the list of devices and immediately reset the computer. My only way to bring it up is to press space at the right moment, get the Boot: prompt and load/boot kernel directly bypassing the loader. This works, but there is no console output (it goes from spinner straight into the login prompt). I guess, the console output is being sent down sio0, where there is an external modem now. Turning the modem off does not change anything... Dmesg output follows (note, that the ``calcru: negative time...'' messages are still here!). What have I done to deserve this? Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Thu Jan 3 21:38:15 EST 2002 [EMAIL PROTECTED]:/ccd/obj/ccd/src/sys/DEBUG Calibrating clock(s) ... TSC clock: 298563844 Hz, i8254 clock: 1193302 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium II/Pentium II Xeon/Celeron (298.54-MHz 686-class CPU) Origin = GenuineIntel Id = 0x633 Stepping = 3 Features=0x80fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,MMX real memory = 335478784 (327616K bytes) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x004f - 0x13fe7fff, 330268672 bytes (80632 pages) avail memory = 321290240 (313760K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 SMP: CPU0 apic_initialize(): lint0: 0x0700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 bios32: Found BIOS32 Service Directory header at 0xc00f7270 bios32: Entry = 0xfd824 (c00fd824) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd6c0+0x430 pnpbios: Found PnP BIOS data at 0xc00f72a0 pnpbios: Entry = f:ab93 Rev = 1.0 Other BIOS signatures found: null: null device, zero device random: entropy source mem: memory I/O Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 02 00 01 00 01 00 00 00 00 22 00 00 01 20 00 00 01 19 01 00 01 2d 01 00 01 4b 01 00 01 0a 01 09 01 02 01 03 01 04 01 00 01 01 01 05 01 11 01 14 01 10 01 13 01 16 01 02 01 06 01 VESA: 19 mode(s) found VESA: v2.0, 2048k memory, flags:0x0, mode table:0xc041f722 (122) VESA: Cirrus Logic GD-5480 VGA VESA: Vendor Name Product Name Revision Number SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x0010 SVR: 0x01ff pci_open(1):mode 1 addr port (0x0cf8) is 0x8000a010 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71928086) Using $PIR table, 8 entries at 0xc00fdf40 acpi0: IntelRSDT on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xc08-0xc0b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: physical bus=0 map[10]: type 3, range 32, base fa40, size 22, enabled found- vendor=0x8086, dev=0x7192, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 IOAPIC #0 intpin 16 - irq 2 Freeing (NOT implemented) redirected PCI irq 11. map[10]: type 4, range 32, base 1c30, size 3, enabled map[14]: type 4, range 32, base 1c24, size 2, enabled map[18]: type 4, range 32, base 1c28, size 3, enabled map[1c]: type 4, range 32, base 1c20, size 2, enabled map[20]: type 4, range 32, base 1080, size 6, enabled map[24]: type 1, range 32, base fa10, size 17, enabled found- vendor=0x105a, dev=0x4d38, revid=0x01 bus=0, slot=11, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 intpin=a, irq=2 powerspec 1 supports D0 D3 current D0 IOAPIC #0 intpin 21 - irq 3 Freeing (NOT implemented) redirected PCI irq 10. map[10]: type 4, range 32, base 1400, size 8, enabled map[14]: type 1, range 32, base fa123000, size 8, enabled map[18]: type 1, range 32, base fa12, size 12, enabled found- vendor=0x1000, dev=0x000f, revid=0x37 bus=0, slot=13, func=0 class=01-00-00, hdrtype=0x00, mfdev=1 intpin=a, irq=3 powerspec 1 supports D0 D1 D2 D3 current D0 IOAPIC #0 intpin 22 - irq 5 map[10]: type 4, range 32, base 1800, size 8, enabled map[14]: type 1, range 32, base
panic upon manual swapon(8)
I typicly run without any swap space configured -- 320Mb of RAM is
usually fine. However, after noticing a message get swap space failed
(or similar) in the nightly report, I tried to tell my Nov 5 -current to
swapon /dev/da0b
I used to do this with full impunity in the past, but this time the
thing paniced with:
IdlePTD 5033984
initial pcb at 3e3f00
panicstr: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address = 0x18
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc024f50f
stack pointer = 0x10:0xcf0fab8c
frame pointer = 0x10:0xcf0fab98
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 16315 (swapon)
trap number = 12
panic: page fault
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
syncing disks... panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
Uptime: 22h14m15s
Some sources have been re-cvsuped since, but not the vfs_subr.c, where the
actual panic occured, seemingly:
#0 dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:492
warning: Source file is more recent than executable.
492 if (!dodump)
(kgdb) where
#0 dumpsys () at /ccd/src/sys/kern/kern_shutdown.c:492
#1 0xc02124c0 in boot (howto=260) at /ccd/src/sys/kern/kern_shutdown.c:335
#2 0xc021295d in panic (fmt=0xc035c878 bwrite: buffer is not busy???)
at /ccd/src/sys/kern/kern_shutdown.c:634
#3 0xc0247203 in bwrite (bp=0xc7cea51c) at /ccd/src/sys/kern/vfs_bio.c:666
#4 0xc02484bc in vfs_bio_awrite (bp=0xc7cea51c)
at /ccd/src/sys/kern/vfs_bio.c:1529
#5 0xc02ce8f4 in ffs_fsync (ap=0xcf0faa44)
at /ccd/src/sys/ufs/ffs/ffs_vnops.c:239
#6 0xc02ccdbe in ffs_sync (mp=0xc16be600, waitfor=2, cred=0xc1027b00,
td=0xc04098e4) at vnode_if.h:441
#7 0xc0253c5a in sync (td=0xc04098e4, uap=0x0)
at /ccd/src/sys/kern/vfs_syscalls.c:657
#8 0xc02120e1 in boot (howto=256) at /ccd/src/sys/kern/kern_shutdown.c:244
#9 0xc021295d in panic (fmt=0xc0376e3e %s)
at /ccd/src/sys/kern/kern_shutdown.c:634
#10 0xc03185ea in trap_fatal (frame=0xcf0fab4c, eva=24)
at /ccd/src/sys/i386/i386/trap.c:939
#11 0xc0318311 in trap_pfault (frame=0xcf0fab4c, usermode=0, eva=24)
at /ccd/src/sys/i386/i386/trap.c:853
#12 0xc0317d4f in trap (frame={tf_fs = 24, tf_es = -821100528,
tf_ds = -831127536, tf_edi = 2, tf_esi = 0, tf_ebp = -821056616,
tf_isp = -821056648, tf_ebx = 0, tf_edx = 1, tf_ecx = -829663484,
#13 0xc024f50f in vlrureclaim (mp=0x0, count=2)
at /ccd/src/sys/kern/vfs_subr.c:561
#14 0xc024f58e in getnewvnode (tag=VT_NON, mp=0x0, vops=0xc163d000,
vpp=0xc04167f8) at /ccd/src/sys/kern/vfs_subr.c:593
#15 0xc02e5b92 in swaponvp (td=0xce8c5704, vp=0xce818080, dev=0xc1714f00,
nblks=0) at /ccd/src/sys/vm/vm_swap.c:268
#16 0xc02e5b02 in swapon (td=0xce8c5704, uap=0xcf0fad20)
at /ccd/src/sys/vm/vm_swap.c:230
#17 0xc0318a98 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077938364, tf_esi = 2, tf_ebp = -1077938372,
tf_isp = -821056140, tf_ebx = -1077938105, tf_edx = 0,
tf_ecx = 134571136, tf_eax = 85, tf_trapno = 12, tf_err = 2,
tf_eip = 134515980, tf_cs = 31, tf_eflags = 659, tf_esp = -1077938568,
tf_ss = 47}) at /ccd/src/sys/i386/i386/trap.c:1129
18 0xc030727d 0xc030727din syscall_with_err_pushed ()
#19 0x0 in ?? ()
(kgdb) up 13
#13 0xc024f50f in vlrureclaim (mp=0x0, count=2)
at /ccd/src/sys/kern/vfs_subr.c:561
561 }
[...]
env LANG=C ls -l /ccd/src/sys/kern/vfs_subr.c
-rw-r--r-- 1 mi wheel 76055 Nov 4 16:34 /ccd/src/sys/kern/vfs_subr.c
[...]
(kgdb) up
#14 0xc024f58e in getnewvnode (tag=VT_NON, mp=0x0, vops=0xc163d000,
vpp=0xc04167f8) at /ccd/src/sys/kern/vfs_subr.c:593
593 vlrureclaim(mp, 2);
(kgdb) p mp
$1 = (struct mount *) 0x0
Anything else? Thanks,
-mi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
damaged file system despite unmounts
For a while I was noticing my largest FS reported as not unmounted cleanly on boot. Today I decided to unmount it myself and check it with fsck. Here are the results. Notice, that the first fsck had to mark the FS clean. Notice that the second fsck found something else to do, and only the third one was happy. What's happening? Thanks, -mi root@aldan:/opt/etc (174) umount /ccd root@aldan:/opt/etc (175) fsck -y /ccd ** /dev/ccd0c ** Last Mounted on /ccd ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 463041 files, 12031814 used, 46114496 free (100184 frags, 5751789 blocks, 0.2% fragmentation) * FILE SYSTEM MARKED CLEAN * * FILE SYSTEM WAS MODIFIED * root@aldan:/opt/etc (176) fsck -y /ccd ** /dev/ccd0c ** Last Mounted on /ccd ** Phase 1 - Check Blocks and Sizes load: 0.09 cmd: fsck_ufs 60803 [physstr] 7.79u 1.72s 0% 11408k /dev/ccd0c: phase 1: cyl group 1001 of 1790 (55%) load: 0.08 cmd: fsck_ufs 60803 [physstr] 9.66u 2.11s 0% 12032k /dev/ccd0c: phase 1: cyl group 1307 of 1790 (73%) ** Phase 2 - Check Pathnames load: 0.14 cmd: fsck_ufs 60803 [physstr] 12.90u 2.78s 0% 12884k /dev/ccd0c: phase 2: dir 1355 of 54568 (2%) ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes ALLOCATED FRAG 174736 MARKED FREE BLK(S) MISSING IN BIT MAPS SALVAGE? yes 463041 files, 12031814 used, 46114495 free (100183 frags, 5751789 blocks, 0.2% fragmentation) * FILE SYSTEM WAS MODIFIED * root@aldan:/opt/etc (177) fsck -y /ccd ** /dev/ccd0c ** Last Mounted on /ccd ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 463041 files, 12031814 used, 46114495 free (100183 frags, 5751789 blocks, 0.2% fragmentation) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ouch -- the second controller on Promise-66 is not detected!
On 31 Oct, Andrey A. Chernov wrote: On Tue, Oct 30, 2001 at 19:37:27 -0500, Mikhail Teterin wrote: Alright, alright, what do I do now? I did NOT wire any ata devices, Ask Soren to fix ATA driver in the way I describe below: Giving more details: ATA code must test wired slot, and, if it is busy, increase number to next free slot and give it to bus code afterwards. or Try to wire device in question using your hints to proper place. Perfect, and how would I do that? You saw the ata-part of my hints file. How do I modify it? hint.ata.0.at=isa hint.ata.0.port=0x1F0 hint.ata.0.irq=14 hint.ata.1.at=isa hint.ata.1.port=0x170 hint.ata.1.irq=15 From dmesg: ata-: ata2 already exists, using ata3 instead -- bogus -mi ata2: iobase=0x1c30 altiobase=0x1c26 bmaddr=0x1080 ata2: mask=03 ostat0=50 ostat2=00 ata2-master: ATAPI probe 00 00 ata2-slave: ATAPI probe 00 00 ata2: mask=03 stat0=50 stat1=00 ata2-master: ATA probe 01 a5 ata2: devices=01 ata2: at 0x1c30 on atapci0 ata3: iobase=0x1c28 altiobase=0x1c22 bmaddr=0x1088 ata3: mask=03 ostat0=50 ostat2=00 ata3-master: ATAPI probe 00 00 ata3-slave: ATAPI probe 00 00 ata3: mask=03 stat0=50 stat1=00 ata3-master: ATA probe 01 a5 ata3: devices=01 ata3: at 0x1c28 on atapci0 ad4: QUANTUM FIREBALLP LM30.0/A35.0700 ATA-5 disk at ata2-master ad6: QUANTUM FIREBALLP LM30.0/A35.0700 ATA-5 disk at ata3-master it seems, that the ports are should be: hint.ata.2.port=0x1c30 hint.ata.3.port=0x1c28 What about IRQs? Or should I just remove the hints for ata-[01]? (Comment about current situation: not detected ATA device in some rare cases is lesser evil than kernel panic, even without any device, with pure console) Well, it always happens to me :) . I don't think it is _so_ rare -- just add a Promise card (popular hardware) to any computer... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ouch -- the second controller on Promise-66 is not detected!
Alright, alright, what do I do now? I did NOT wire any ata devices, and hints only list the on-motherboard ata controllers (one of them has a CD drive attached to it, that's it): hint.ata.0.at=isa hint.ata.0.port=0x1F0 hint.ata.0.irq=14 hint.ata.1.at=isa hint.ata.1.port=0x170 hint.ata.1.irq=15 -mi On 31 Oct, Andrey A. Chernov wrote: On Wed, Oct 31, 2001 at 02:57:42 +0300, Andrey A. Chernov wrote: On Tue, Oct 30, 2001 at 14:57:17 -0800, Peter Wemm wrote: date: 2000/05/26 13:59:05; author: sos; state: Exp; lines: +8 -13 If devclass_alloc_unit() is called with a wired unit #, and this is buzy, only search upwards for a free slot to use.. This broke unit numbering on ATA systems where PCI attached controllers come before the mainboard ones... This need to be resolved somehow else, not by using next free slot causing multiply consoles, keyboards, etc. detected (with panic). Probably upper level numbering code, i.e. ATA needs to detect its conflicts, not bus numbering code itself. Giving more details: ATA code must test wired slot, and, if it is busy, increase number to next free slot and give it to bus code afterwards. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lots of Linux zombies (mtvp)
(Scary title, is not it?) After watching some MPGs with the Linux binary-only mtvp (graphics/mtv port) I noticed 40 zomby processes: 68278 p1 Z 0:00,00 (mtvp) 68279 p1 Z 0:00,00 (mtvp) 68280 p1 Z 0:00,00 (mtvp) 68281 p1 Z 0:00,00 (mtvp) 68283 p1 Z 0:00,00 (mtvp) 68284 p1 Z 0:00,00 (mtvp) 68285 p1 Z 0:00,00 (mtvp) In all of them, init is already a parent: root@aldan:~ (220) ps -alwwx | grep 68256 105 68256 1 0 96 0 00 - Z p10:00,00 (mtvp) 0 98924 5659 0 96 0 308 44 - M+p40:00,00 grep 68256 root@aldan:~ (221) ps -alwwx | grep 68276 105 68276 1 0 96 0 00 - Z p10:00,00 (mtvp) 0 98930 5659 2 -8 0 1200 166 piperd S+p40:00,01 grep 68276 root@aldan:~ (222) kill -1 1 root@aldan:~ (223) ps -alwwx | grep 68276 105 68276 1 0 96 0 00 - Z p10:00,00 (mtvp) 0 98934 5659 0 96 0 1704 231 - RVp40:00,00 grep 68276 (csh) What's going on? Also, file(1) calls them SYSV, rather than Linux binaries, but that may well be correct. Yours, -- |\__-__/| _/ : :::\_ '__--( ..::)--__`-mi If you have a / _- \/ :::\/ -_ serious knowledge/ / :. .\ \ about computers -- | | Ok, let's say you broke keep it in a secret! _|/ ::\|_the wall with your head Rules of dating, / /:/:_::\::\:.\ What are you going to 'Playboy', ? 1994 | :| ..:(_/ \::|::|::| do in the next cell? | :|:. ::|: |::|.:| Stanislaw J. Lec \ |:: :::_/::/: :|:/ ((___\\/___/___)) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
installing kernel is troublesome... (patch)
Due, apparently, to the several removed/renamed modules still listed in the sys/modules/Makefile Index: Makefile === RCS file: /home/ncvs/src/sys/modules/Makefile,v retrieving revision 1.201 diff -U1 -r1.201 Makefile --- Makefile2001/09/18 23:31:37 1.201 +++ Makefile2001/09/19 14:13:49 @@ -35,3 +35,2 @@ if_tun \ - if_vlan \ ip6fw \ @@ -106,3 +105,2 @@ SUBDIR+=aac \ - acpi \ aic \ @@ -114,3 +112,2 @@ el \ - fe \ fpu \ Yours, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
On 5 Sep, Bruce Evans wrote: snprintf, strlen, vsnprintf, sysctl, sysctlbyname I think all of these are safe in practice. It also accesses some variables that are not safe to access in a signal handler (non-auto ones that are not of type volatile sig_atomic_t or are accessed by reads). This is unsafe in practice. E.g., concurrent calls to setproctitle() might corrupt the state of the ps_strings variable. Mmm, I don't know what those strings are used for -- what's the worst, that could happen here -- corrupted PS output, or worse? In any case, it seems, like a simple lock -- a static variable in the signal handler would work: static signal_handling; ... if (signal_handling) return; if (signal) signal_handling = 1; ... signal_handling = 0; Or is this not safe enough -- race of both signal handlers checking for the signal_handling at the same time? What would be the right way to do this generally? Thanks. In this particular case, timeest is called fairly often, but simply returns if not enough time elapsed since last report. I can make the signal handler set the flag, which will make timeest report things the next time it is called, even if 5 minutes did not elapse. This way, signal handler will only deal with a variable assignment -- all of the reporting (including proctitle update) will happen shortly afterwards -- on a normal stack. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
On 3 Sep, Terry Lambert wrote: I would like it. How often does it update the proctitle? Whenever it outputs a line to the stderr -- I personally find no regularity in that :(. SIGINFO handling is a different thing, though. I'll look at that too. Thanks, It would be nice to have in a SIGINFO handler as well, but since your application is dump run by Amanda as a background process, a SIGINFO is not very useful, unless it was being suggested that the setproctitle() be called from a SIGINFO handler? Yes that's what is being suggested. The output line will be the same, so no dump-output-parsing scripts should break (including Amanda's). Please, read the patches. I'm pretty sure that this would not be a valid thing to do; Mmm, why? SIGINFO itself is also problematic, since if you redirect output to a file, etc., you'd really need to call fflush() Why? The line will eventually be saved without an explicit fflush(), but the proctitle will be set immediately... Besides, in case of dump, it is the stderr, that has no buffering, AFAIK :) Also, printf() allocates memory for floating point, so if that percentage is a floating point calculation, then you are in double trouble, since you are not allowed to call malloc() in a signal handler. That's interesting... I can modify it a bit, to round the percentage to fit the %d if called as a signal handler. Thanks. Anything else? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
Ok, attached is the patch addding a function, which sets the proctitle
to the last output message and several calls to this function in places,
where it looked useful to me. May be, I added too many, and/or skipped
some...
Note, that I intentially did not put this functionality into the msg()
function itself -- not all messages need to be placed into the title.
But a call to my new title(void) function can be placed whereever deemed
useful. Only those, that can be followed by a long wait...
The only tricks here are to replace the \n with the \0 in the lastmsg
and to restore the title to the original before forking.
The SIGINFO handling seemed to be as simple as:
--- main.c 2001/07/09 03:06:56 1.26
+++ main.c 2001/09/02 19:58:21
@@ -274,2 +274,4 @@
+ if (signal(SIGINFO, SIG_IGN) != SIG_IGN)
+ signal(SIGHUP, sig);
if (signal(SIGHUP, SIG_IGN) != SIG_IGN)
@@ -527,2 +536,5 @@
switch(signo) {
+ case SIGINFO:
+ timeest();
+ break;
case SIGALRM:
But it just does not work :( I tried Ctrl-T and I tried killall -- no
output, besides the usual:
load: 0.11 cmd: dump 69089 [running] 0.00u 0.00s 0% 392k
Any suggestions? Thanks!
I'm only a ports committer, so if the proctitle patch is found
acceptable (wow!) -- could someone please commit it? Or tell me to
send-pr it...
-mi
Index: dump.h
===
RCS file: /home/ncvs/src/sbin/dump/dump.h,v
retrieving revision 1.9
diff -U1 -r1.9 dump.h
--- dump.h 2001/08/10 23:12:10 1.9
+++ dump.h 2001/09/02 19:58:20
@@ -104,2 +104,3 @@
void timeest __P((void));
+void title __P((void));
time_t unctime __P((char *str));
Index: main.c
===
RCS file: /home/ncvs/src/sbin/dump/main.c,v
retrieving revision 1.26
diff -U1 -r1.26 main.c
--- main.c 2001/07/09 03:06:56 1.26
+++ main.c 2001/09/02 19:58:21
@@ -332,2 +334,3 @@
}
+ title();
sync();
@@ -358,2 +361,3 @@
msg(mapping (Pass I) [regular files]\n);
+ title();
anydirskipped = mapfiles(maxino, tapesize);
@@ -361,2 +365,3 @@
msg(mapping (Pass II) [directories]\n);
+ title();
while (anydirskipped) {
@@ -410,2 +415,3 @@
}
+ title();
@@ -423,2 +429,3 @@
msg(dumping (Pass III) [directories]\n);
+ title();
dirty = 0; /* XXX just to get gcc to shut up */
@@ -441,2 +448,3 @@
msg(dumping (Pass IV) [regular files]\n);
+ title();
for (map = dumpinomap, ino = 1; ino maxino; ino++) {
@@ -478,2 +486,3 @@
spcl.c_tapea / (tend_writing - tstart_writing));
+ title();
@@ -536,2 +548,3 @@
msg(Rewriting attempted as response to unknown signal.\n);
+ title();
(void)fflush(stderr);
Index: optr.c
===
RCS file: /home/ncvs/src/sbin/dump/optr.c,v
retrieving revision 1.12
diff -U1 -r1.12 optr.c
--- optr.c 2001/01/29 09:45:51 1.12
+++ optr.c 2001/09/02 19:58:21
@@ -203,2 +203,3 @@
+ setproctitle(NULL); /* restore the proctitle modified by title() */
switch (pid = fork()) {
@@ -305,2 +306,3 @@
deltat / 3600, (deltat % 3600) / 60);
+ title();
}
@@ -333,2 +335,28 @@
va_end(ap);
+}
+
+/*
+ * This function can be called to place, what msg() above pushed to
+ * stderr, into the process title, viewable with the ps-command.
+ * A side effect of this function, is it replaces the final '\n' (if any)
+ * with the '\0' in the global variable lastmsg -- to avoid the literal
+ * \n being put into the proctitle.
+ * So, if the lastmsg needs to be output elsewhere, that should happen
+ * before calling title().
+ */
+void title()
+{
+ int lastlen;
+
+ lastlen = strlen(lastmsg);
+ if (lastmsg[lastlen-1] == '\n')
+ lastmsg[lastlen-1] = '\0';
+
+ /*
+* It would be unwise to run multiple dumps of same disk at
+* same time. So ``disk'' is sufficient for identifying, to
+* which family of dump processes this one belongs -- the
+* other processes continue to have the original titles
+*/
+ setproctitle(%s: %s, disk, lastmsg);
}
Index: tape.c
===
RCS file: /home/ncvs/src/sbin/dump/tape.c,v
retrieving revision 1.13
diff -U1 -r1.13 tape.c
--- tape.c 2001/01/28 21:21:37 1.13
+++ tape.c 2001/09/02 19:58:22
@@ -533,2 +533,3 @@
*/
+ setproctitle(NULL); /* restore the proctitle modified by title() */
childpid = fork();
proctitle progress reporting for dump(8)
Does this look like a good idea to anyone else? 79239 ?? I 0:00,89 dump 0ushf 1048576 0 - /dev/da0h (dump) 79240 ?? S 0:06,85 dump: /dev/da0h(0): 92.44% done, finished in 0:43 (dump) 79241 ?? S 0:13,93 dump 0ushf 1048576 0 - /dev/da0h (dump) 79242 ?? S 0:13,92 dump 0ushf 1048576 0 - /dev/da0h (dump) 79243 ?? S 0:13,90 dump 0ushf 1048576 0 - /dev/da0h (dump) Does anyone think, it is a bad idea? If no, I'll send-pr the patch... For me, dump is driven by a remote amanda and its nice to know, when it is going to be over (I have a fairly slow link to the backup server). Comments? -- -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: proctitle progress reporting for dump(8)
On 1 Sep, Jeroen Ruigrok/Asmodai wrote: -On [20010901 19:00], Mikhail Teterin ([EMAIL PROTECTED]) wrote: 79240 ?? S 0:06,85 dump: /dev/da0h(0): 92.44% done, finished in 0:43 (dump) Looks nice. Would definately be an improvement. I would like it. How often does it update the proctitle? Whenever it outputs a line to the stderr -- I personally find no regularity in that :(. SIGINFO handling is a different thing, though. I'll look at that too. Thanks, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
another panic (mix ppp and usb to taste)
As I was trying to let the Palm Pilot connect to my desktop
through usb using PPP, I tried to run
/usr/sbin/ppp -quiet -direct -nat /dev/ugen0
While, perhaps, not the right way to do what I want (what is? aren't
serial devices the simplest?), it should not panic (nothing should
really). But it does, and quite repeatedly (some more comments after
the trace):
IdlePTD 4984832
initial pcb at 3db040
panicstr: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address = 0x3
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01d5a0b
stack pointer = 0x10:0xce7f1c4c
frame pointer = 0x10:0xce7f1c58
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 442 (ppp)
trap number = 12
panic: page fault
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
syncing disks... panic: bwrite: buffer is not busy???
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
Uptime: 10m14s
dumping to dev da0b, offset 131200
dump ... 2 1 0
---
[...]
#12 0xc030b0bc in trap (frame={tf_fs = -1071644648, tf_es = -830734320,
tf_ds = 16777232, tf_edi = 64, tf_esi = 0, tf_ebp = -830530472,
tf_isp = -830530504, tf_ebx = -1049243648, tf_edx = -1049243428,
tf_ecx = 34, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1071818229, tf_cs = 8, tf_eflags = 66178,
tf_esp = -830530412, tf_ss = -1049288448})
at ../../../i386/i386/trap.c:405
#13 0xc01d5a0b in ugenpoll (dev=0xc1752100, events=64, p=0xce7abb80)
at ../../../dev/usb/ugen.c:1369
#14 0xc01ed604 in spec_poll (ap=0xce7f1c94)
at ../../../fs/specfs/spec_vnops.c:333
#15 0xc01ed27d in spec_vnoperate (ap=0xce7f1c94)
at ../../../fs/specfs/spec_vnops.c:119
#16 0xc0252333 in vn_poll (fp=0xc17328c0, events=64, cred=0xc1734700,
p=0xce7abb80) at vnode_if.h:381
#17 0xc0228b8b in selscan (p=0xce7abb80, ibits=0xce7f1d48,
obits=0xce7f1d3c, nfd=1) at ../../../sys/file.h:192
#18 0xc02286b5 in select (p=0xce7abb80, uap=0xce7f1f80)
at ../../../kern/sys_generic.c:772
#19 0xc030bf2d in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134842880, tf_esi = 134842880, tf_ebp = 0,
tf_isp = -830529580, tf_ebx = 3, tf_edx = 134996480,
tf_ecx = 134996352, tf_eax = 93, tf_trapno = 12, tf_err = 2,
tf_eip = 673178596, tf_cs = 31, tf_eflags = 643,
tf_esp = -1077937708, tf_ss = 47}) at ../../../i386/i386/trap.c:1129
(kgdb) up 13
#13 0xc01d5a0b in ugenpoll (dev=0xc1752100, events=64, p=0xce7abb80)
at ../../../dev/usb/ugen.c:1369
1369switch (sce-edesc-bmAttributes UE_XFERTYPE) {
(kgdb) p sce
$1 = (struct ugen_endpoint *) 0x0
(kgdb) l
1364printf(ugenpoll: no pipe\n);
1365return (EIO);
1366}
1367#endif
1368s = splusb();
1369switch (sce-edesc-bmAttributes UE_XFERTYPE) {
1370case UE_INTERRUPT:
1371if (events (POLLIN | POLLRDNORM)) {
1372if (sce-q.c_cc 0)
1373revents |= events (POLLIN | POLLRDNORM);
(kgdb) p events
$3 = 64
(kgdb) p s
No symbol s in current context.
(kgdb) p revents
$5 = 0
What I don't understand, is -- there is a check, just a few lines
above:
if (sce == NULL)
return (EINVAL);
How come it is not being caught there? Thanks,
--
|\__-__/|
_/ : :::\_
'__--( ..::)--__`-mi
If you have a / _- \/ :::\/ -_
serious knowledge/ / :. .\ \
about computers -- | | Ok, let's say you broke
keep it in a secret! _|/ ::\|_the wall with your head
Rules of dating, / /:/:_::\::\:.\ What are you going to
'Playboy', ? 1994 | :| ..:(_/ \::|::|::| do in the next cell?
| :|:. ::|: |::|.:| Stanislaw J. Lec
\ |:: :::_/::/: :|:/
((___\\/___/___))
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/lib/libc/sys mmap.2
dg 2001/08/23 15:39:53 PDT
Modified files:
lib/libc/sys mmap.2
Log:
Killed reference to MAP_INHERIT which is not supported in FreeBSD.
BTW, GNU Autoconf's AC_FUNC_MMAP macro fails on -current, which leads
the configure (in ImageMagick, for example) to a mistaken conclusion
there is no mmap support :-( Anybody cares to take a closer look?
Here is what they are doing (from config.log). Thanks,
-mi
[...]
configure:8380: cc -o conftest -O -pipe -march=i686 -Wall -I/opt/include/libxml2
-I/opt/include/libxml2/libxml -I/opt/include/freetype2 -I/opt/include/freetype2
-I/usr/local/include -I/opt/include -I/opt/include -I/opt/include/X11 -L/opt/lib
-L/opt/lib -L/opt/lib -L/opt/lib conftest.c -lwmf -lXpm -lxml2 -ljbig -ltiff
-lfreetype -ljpeg -lpng -llcms -lfpx -ldpstk -ldps -lXext -lXt -lSM -lICE -lX11
-lbz2 -lz -lm -L/usr/local/lib 15
configure: In function `main':
configure:8321: warning: implicit declaration of function `getpagesize'
configure:8330: warning: implicit declaration of function `rand'
configure:8331: warning: implicit declaration of function `umask'
configure:8335: warning: implicit declaration of function `write'
configure:8337: warning: implicit declaration of function `close'
configure:8368: warning: implicit declaration of function `read'
configure:8374: warning: implicit declaration of function `unlink'
configure: failed program was:
#line 8240 configure
#include confdefs.h
/* Thanks to Mike Haertel and Jim Avera for this test.
Here is a matrix of mmap possibilities:
mmap private not fixed
mmap private fixed at somewhere currently unmapped
mmap private fixed at somewhere already mapped
mmap shared not fixed
mmap shared fixed at somewhere currently unmapped
mmap shared fixed at somewhere already mapped
For private mappings, we should verify that changes cannot be read()
back from the file, nor mmap's back from the file at a different
address. (There have been systems where private was not correctly
implemented like the infamous i386 svr4.0, and systems where the
VM page cache was not coherent with the filesystem buffer cache
like early versions of FreeBSD and possibly contemporary NetBSD.)
For shared mappings, we should conversely verify that changes get
propogated back to all the places they're supposed to be.
Grep wants private fixed already mapped.
The main things grep needs to know about mmap are:
* does it exist and is it safe to write into the mmap'd area
* how to use it (BSD variants) */
#include sys/types.h
#include fcntl.h
#include sys/mman.h
/* This mess was copied from the GNU getpagesize.h. */
#ifndef HAVE_GETPAGESIZE
# ifdef HAVE_UNISTD_H
# include unistd.h
# endif
/* Assume that all systems that can run configure have sys/param.h. */
# ifndef HAVE_SYS_PARAM_H
# define HAVE_SYS_PARAM_H 1
# endif
# ifdef _SC_PAGESIZE
# define getpagesize() sysconf(_SC_PAGESIZE)
# else /* no _SC_PAGESIZE */
# ifdef HAVE_SYS_PARAM_H
# include sys/param.h
# ifdef EXEC_PAGESIZE
#define getpagesize() EXEC_PAGESIZE
# else /* no EXEC_PAGESIZE */
#ifdef NBPG
# define getpagesize() NBPG * CLSIZE
# ifndef CLSIZE
# define CLSIZE 1
# endif /* no CLSIZE */
#else /* no NBPG */
# ifdef NBPC
# define getpagesize() NBPC
# else /* no NBPC */
# ifdef PAGESIZE
# define getpagesize() PAGESIZE
# endif /* PAGESIZE */
# endif /* no NBPC */
#endif /* no NBPG */
# endif /* no EXEC_PAGESIZE */
# else /* no HAVE_SYS_PARAM_H */
# define getpagesize() 8192 /* punt totally */
# endif /* no HAVE_SYS_PARAM_H */
# endif /* no _SC_PAGESIZE */
#endif /* no HAVE_GETPAGESIZE */
#ifdef __cplusplus
extern C { void *malloc(unsigned); }
#else
char *malloc();
#endif
int
main()
{
char *data, *data2, *data3;
int i, pagesize;
int fd;
pagesize = getpagesize();
/*
* First, make a file with some known garbage in it.
*/
data = malloc(pagesize);
if (!data)
exit(1);
for (i = 0; i pagesize; ++i)
*(data + i) = rand();
umask(0);
fd = creat(conftestmmap, 0600);
if (fd 0)
exit(1);
if (write(fd, data, pagesize) != pagesize)
exit(1);
close(fd);
/*
* Next, try to mmap the file at a fixed address which
* already has something else allocated at it. If we can,
* also make sure that we see the same garbage.
*/
fd = open(conftestmmap, O_RDWR);
if (fd 0)
exit(1);
data2 = malloc(2 * pagesize);
if (!data2)
exit(1);
data2 += (pagesize - ((int) data2 (pagesize - 1))) (pagesize - 1);
if (data2 != mmap(data2, pagesize, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_FIXED, fd, 0L))
exit(1);
block device required
Now, this may be the wrong way to do it: # mount -oro -t msdos /dev/ugen0 /mnt But the error message is certainly misleading. Especially, since the are no block devices in -current any more :) msdosfs: /dev/ugen0: Block device required -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
microuptime() went backwards
Should I worry about this: [...] Aug 18 11:11:51 aldan /boot/mi/kernel: calcru: negative time of -1781452130 usec for pid 352 (setiathome) Aug 18 11:17:10 aldan /boot/mi/kernel: microuptime() went backwards (442732.3850800 - 442731.165931) Aug 18 11:17:10 aldan /boot/mi/kernel: microuptime() went backwards (442732.3850800 - 442731.166366) Aug 18 11:17:11 aldan /boot/mi/kernel: microuptime() went backwards (442732.3850800 - 442732.324086) Aug 18 11:17:11 aldan /boot/mi/kernel: microuptime() went backwards (442732.3850800 - 442732.324293) Aug 18 11:17:12 aldan /boot/mi/kernel: microuptime() went backwards (442732.3850800 - 442732.814924) Aug 18 11:17:13 aldan /boot/mi/kernel: calcru: negative time of -1498577479 usec for pid 352 (setiathome) ? Thanks, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: block device required
On 18 Aug, Bernd Walter wrote: On Sat, Aug 18, 2001 at 11:02:04AM -0400, Mikhail Teterin wrote: Now, this may be the wrong way to do it: # mount -oro -t msdos /dev/ugen0 /mnt But the error message is certainly misleading. Especially, since the are no block devices in -current any more :) msdosfs: /dev/ugen0: Block device required ugen is a generic usb device and not a disk What you need is umass . Yes, I figured that by now. For some reason, the umass0 was NOT created, when I attached this Flash Card Reader, even after manually kldloaded umass.ko -- only the ugen0 (and .[123]). But that's a different story. Nevertheless the error message is wrong as there are no block devices anymore. Yes, that was my point :) -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
5.0 and USB devices
Now, this _used_ to work -- some time back in February or even in spring. But not anymore... usbd is running, the usb device, with the uhci are compiled into the kernel, and the controller is reported on boot: uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0x1c00-0x1c1f irq 5 at device 18.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 But nothing happens when I connect USB devices, like Palm's craddle or a digital camera... No new /dev/ugen* created, no messages logged by usbd, nothing... The OS is FreeBSD 5.0-CURRENT #0: Sun Jul 15 12:50:23 EDT 2001 ... i386 Any clues? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: picking a DB (Re: nvi maintainer?)
Technically gdbm is fine. I doubt you'll be able to displace Berkeley DB, though; gdbm is less buggy, but doesn't offer many of the features, nor does it offer equivalent performance. I'd welcome your comments in particular, since you are an expert in the field and there is not going to be a conflict of interest. Actually, I'm pretty biased. :-) I'd like to see Berkeley DB 1.85 go away for a lot of reasons -- I don't much care what it's replaced with. Well, can you recommend some other alternative? You mentioned db-tests you created, etc. Did you evaluate any other dbm libraries useable for us from the licensing perspective? Nvi won't require upgrading the library's dbm support. Berkeley DB 3.X supports inclusion of multiple DB versions in a single application. Nvi's simple solution is to include a copy of DB in the nvi distribution. Well, may be that's how the nvi application will be distributed, but I doubt, that's how the nvi part of the FreeBSD will be built... In all probability, the new nvi will just get hacked to work with dbm-1.85 or gdbm. Although it is possible, that the relevant parts of DB3 will be linked staticly into it (kind of like DB3 Lite), it would be rather ugly :( Thanks, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mdconfig and _virtual_ memory
On 19 Jun, Matt Dillon wrote: : The swap backing in md(4) is a straight copy of the code which : lived in vn(4). I'm not terribly familiar with that code, but I : would expect that it would work with no swap space as well. : : Your man is probably Matt Dillon... You can create an MD partition with wired memory - no swap backing at all, if you want. Obviously you can make such a partition as large as you might otherwise want to make it. Well, I want it to be _virtual memory_ backed -- not just swap or just RAM. Can I do that? It seems, not right now. I don't need it working ASAP, so I don't care for workarounds :-) But this is something FreeBSD had until 5.0 and its a shame to loose it, IMHO. Thanks, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mdconfig and _virtual_ memory
So, Matt, any comments? On 7 Jun, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Mikhail Teterin writes: When I moved to mdconfig, I figured I have to use ``-t swap'' for the same effect, but it seems, I was wrong -- apparently, ``swap'' means the filesystem will always hit the disk, even if there is plenty of RAM to go around. My suspicion was further confirmed, by disabling the swapping at all -- the mdconfig-ed device stopped working -- disklabel got ENOMEM. The swap backing in md(4) is a straight copy of the code which lived in vn(4). I'm not terribly familiar with that code, but I would expect that it would work with no swap space as well. Your man is probably Matt Dillon... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
mdconfig and _virtual_ memory
Hi! For years of using MFS I presumed, that it used virtual memory -- RAM and swap to store the file system -- using RAM for speed of MFS and swap when RAM was needed by others. When I moved to mdconfig, I figured I have to use ``-t swap'' for the same effect, but it seems, I was wrong -- apparently, ``swap'' means the filesystem will always hit the disk, even if there is plenty of RAM to go around. My suspicion was further confirmed, by disabling the swapping at all -- the mdconfig-ed device stopped working -- disklabel got ENOMEM. Now I use ``-t malloc'', but I suspect, this will never hit the disk, even if there is where to swap and more memory can be used elsewhere. It seems, ``-t malloc'' simply bites a chunk of RAM away... Is it possible to make md-devices backed by _virtual memory_? Did the old MFS do that? Where else am I wrong in this letter? Thanks! Yours, -mi P.S. Where is that new mount_mfs wrapper? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mount_mfs (Re: smbfs)
I actually wrote a short program that emulates *all* of mount_mfs's umpteen options with md, disklabel, and newfs, but nobody seemed interested. My choice of name (mount_md) wasn't particuarly good, either. Look at the -hackers and cvs-all archives around late January and early February for the discussions. I still have that program, and it works great, so perhaps I should make it a port (comments?). Why can't that program _replace_ mount_mfs? And assume the name too? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
amd feature request (Re: AMD config file question.)
Now that smbfs is in, can amd be used to mount smb shares? Of course, it can. But can we have something like host type, where all smb-shares available from a host are automaticly accessible? This may be added to the host-type together with NFS, or be made part of a separate smbhost type. I'd vote for the first one, personally... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mount_mfs (Re: smbfs)
On 25 May, Sheldon Hearn wrote: On Fri, 25 May 2001 09:34:16 -0400, Mikhail Teterin wrote: Why can't that program _replace_ mount_mfs? And assume the name too? The objection that impressed me the last time this was suggested is that it's totally counter-intuitive to have a binary called mount_mfs that doesn't mount an MFS filesystem. Well, for all intents and purposes, it does. It creates the device backed by swap and newfs-es it. Rather, it does all sorts of icky extra stuff to achieve a rather specific goal. The goal of creating a virtual file-system in memory. What's MFS? I still don't see why an rc.conf knob specifically for /tmp isn't sufficient. That's what people want this for. As said before, /tmp is too specific. What if I want /tmp2 or /usr/obj to be there for whatever crazy reason? Also, this will require me to modify the /etc/fstab that served me for years. Others can read the excellent documentation supplied in mdconfig(8), which is appropriately cross-referenced from md(4), which is the manual page for the device concerned. And code their own /usr/local/etc/rc.d/mount_memory.sh? Why? Is not /etc/fstab a better place for file-system tables? Logical, orthogonal and pretty damn easy, when you look at the EXAMPLES section. :-) -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
another panic (doscmd)
Hello! I was not able to obtain a trace :( The panic mechanism itself went into an infinite loop continuously displaying kern_sync.c:385 sleeping with "panic" locked from kern_shutdown.c:544 as fast as it could :-( All I did was (as a regular user): doscmd r4d1di.exe The r4d1di.exe can be found here: http://aldan.algebra.com:8015/~mi/doscmd-crash/r4d1di.exe (it is a stupid self-extracting executable). -mi P.S. BTW, any news on the two panics I reported earlier: Attempts to run a staticly linked Linux binary panic a regular kernel, or cause the binary to seg-fault on the one with INVARIANTS and WITNESS: http://aldan.algebra.com:8015/~mi/civctp-crash/ Attemps to mount an msdos-floppy cause panic: http://aldan.algebra.com:8015/~mi/mount_msdos-crash/ P.P.S. hub.freebsd.org has strange difficulties with the algebra.com domain. If you are trying to reach me, try [EMAIL PROTECTED] Sorry. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic trying to mount_msdos
The kernel and modules compiled with INVARIANTS, INVARIANTS_SUPPORT, and WITNESS. I tried to mount this silly floppy and boom... The details are at http://aldan.algebra.com:8015/~mi/mount_msdos-crash/ :-( -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic trying to play Civillization (with trace, etc.)
Hi! All of a sudden I can't play my game :( The new kernels all crash
just trying to start the executable...
Here is the trace with my attempts to browse through it. The bzip2-ed
kernel and vmcore, as well as the /sys subtree are available for
examination at:
http://aldan.algebra.com:8015/~mi/civctp-crash/
The panic-triggering (Linux) binary is also there (civctp). I don't
think you can play the game with it without the data-files and
libraries, so Loki games should not object :) Most probably you will be
able to get the same panic by just trying to run the executable, which
worked just fine with the Feb 22 current-kernel. I link all of the
modules into the kernel.
I can also give an account or two (the machine is on a static-IP DSL
link) to those who wish to take a closer look, but can not reproduce
this locally. Thanks!
#0 dumpsys () at ../../kern/kern_shutdown.c:478
#1 0xc01de0d0 in boot (howto=260) at ../../kern/kern_shutdown.c:321
#2 0xc01de4ec in poweroff_wait (junk=0xc0342fcf, howto=-822364608)
at ../../kern/kern_shutdown.c:571
#3 0xc02e8f65 in trap_fatal (frame=0xcf02adc4, eva=0)
at ../../i386/i386/trap.c:987
#4 0xc02e8c99 in trap_pfault (frame=0xcf02adc4, usermode=0, eva=0)
at ../../i386/i386/trap.c:901
#5 0xc02e858f in trap (frame={tf_fs = -1069744104, tf_es = 16,
tf_ds = -821952496, tf_edi = -822364608, tf_esi = -1069645600,
tf_ebp = -821907952, tf_isp = -821907984, tf_ebx = 0,
tf_edx = -822364608, tf_ecx = 86, tf_eax = 1, tf_trapno = 12,
tf_err = 0, tf_eip = -1071804515, tf_cs = 8, tf_eflags = 65538,
tf_esp = 4, tf_ss = 1}) at ../../i386/i386/trap.c:448
#6 0xc01d8f9d in _mtx_unlock_sleep (m=0xc03e80e0, opts=4,
file=0xc0324024 "../../kern/kern_shutdown.c", line=258)
at ../../kern/kern_mutex.c:525
#7 0xc01ddde5 in boot (howto=256) at ../../kern/kern_shutdown.c:258
#8 0xc01de4ec in poweroff_wait (junk=0xc0342fcf, howto=-822364608)
at ../../kern/kern_shutdown.c:571
#9 0xc02e8f65 in trap_fatal (frame=0xcf02aef4, eva=0)
at ../../i386/i386/trap.c:987
#10 0xc02e8c99 in trap_pfault (frame=0xcf02aef4, usermode=0, eva=0)
at ../../i386/i386/trap.c:901
#11 0xc02e858f in trap (frame={tf_fs = -1051459560, tf_es = 16, tf_ds = 16,
tf_edi = -822364608, tf_esi = -1069645600, tf_ebp = -821907648,
tf_isp = -821907680, tf_ebx = 0, tf_edx = 1, tf_ecx = 598, tf_eax = 598,
tf_trapno = 12, tf_err = 0, tf_eip = -1071804515, tf_cs = 8,
tf_eflags = 65666, tf_esp = -822364608, tf_ss = -1069645600})
at ../../i386/i386/trap.c:448
#12 0xc01d8f9d in _mtx_unlock_sleep (m=0xc03e80e0, opts=0,
file=0xc034305c "../../i386/i386/trap.c", line=1247)
at ../../kern/kern_mutex.c:525
#13 0xc02e979d in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 144704672, tf_esi = -1077937872, tf_ebp = -1077937588,
tf_isp = -821907500, tf_ebx = 4, tf_edx = 148, tf_ecx = -1077937736,
tf_eax = 148, tf_trapno = 12, tf_err = 2, tf_eip = 139025316,
tf_cs = 31, tf_eflags = 598, tf_esp = -1077937900, tf_ss = 47})
at ../../i386/i386/trap.c:1247
#14 0xc02d705d in syscall_with_err_pushed ()
#15 0x8461eab in ?? ()
#16 0x83e012f in ?? ()
#17 0x83dfeeb in ?? ()
#18 0x81be0df in ?? ()
#19 0x81aa7c9 in ?? ()
#20 0x804b271 in ?? ()
#21 0x84b2f66 in ?? ()
#22 0x80480de in ?? ()
#23 0x846dc94 in ?? ()
(kgdb) up 12
#12 0xc01d8f9d in _mtx_unlock_sleep (m=0xc03e80e0, opts=0,
file=0xc034305c "../../i386/i386/trap.c", line=1247)
at ../../kern/kern_mutex.c:525
525 p1 = TAILQ_FIRST(m-mtx_blocked);
(kgdb) p m
$1 = (struct mtx *) 0xc03e80e0
(kgdb) p *m
$2 = {mtx_lock = 3472602691, mtx_recurse = 1, mtx_saveintr = 0, mtx_flags = 2,
mtx_description = 0xc0341df9 "Giant", mtx_blocked = {tqh_first = 0x0,
tqh_last = 0xcefbd400}, mtx_contested = {le_next = 0xc03e80e0,
le_prev = 0xcefbb7e0}, mtx_next = 0xc03dae60, mtx_prev = 0xc03e82a0,
mtx_debug = 0x0}
(kgdb) p m-mtx_blocked
$3 = {tqh_first = 0x0, tqh_last = 0xcefbd400}
(kgdb) l
520
521 mtx_lock_spin(sched_lock);
522 if ((opts MTX_QUIET) == 0)
523 CTR1(KTR_LOCK, "_mtx_unlock_sleep: %p contested", m);
524
525 p1 = TAILQ_FIRST(m-mtx_blocked);
526 MPASS(p-p_magic == P_MAGIC);
527 MPASS(p1-p_magic == P_MAGIC);
528
529 TAILQ_REMOVE(m-mtx_blocked, p1, p_procq);
(kgdb) up
#13 0xc02e979d in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 144704672, tf_esi = -1077937872, tf_ebp = -1077937588,
tf_isp = -821907500, tf_ebx = 4, tf_edx = 148, tf_ecx = -1077937736,
tf_eax = 148, tf_trapno = 12, tf_err = 2, tf_eip = 139025316,
tf_cs = 31, tf_eflags = 598, tf_esp = -1077937900, tf_ss = 47})
at ../../i386/i386/trap.c:1247
1247mtx_unlock(Giant);
(kgdb) l
1242
1243/*
1244 * Release Giant if we had to get it
1245
as segfaulting during world-build
No, I don't think it is hardware. It died on the same spot for the third time in a row: tail -15 /var/tmp/w.log* == /var/tmp/w.log == cd /opt/src/lib/csu/i386-elf; make _EXTRADEPEND cc -O -pipe -march=i686 -elf -Wall -fkeep-inline-functions -I/opt/src/lib/csu/i386-elf/../common -I/usr/obj/opt/src/i386/usr/include -c /opt/src/lib/csu/i386-elf/crt1.c -o crt1.o cc -I/opt/src/lib/csu/i386-elf/../common -I/usr/obj/opt/src/i386/usr/include -c /opt/src/lib/csu/i386-elf/crti.S -o crti.o cc -I/opt/src/lib/csu/i386-elf/../common -I/usr/obj/opt/src/i386/usr/include -c /opt/src/lib/csu/i386-elf/crtn.S -o crtn.o cc: Internal compiler error: program as got fatal signal 11 *** Error code 1 cc: Internal compiler error: program as got fatal signal 11 *** Error code 1 2 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error == /var/tmp/w.log.11 == cd /opt/src/lib/csu/i386-elf; make _EXTRADEPEND cc -O -pipe -march=i686 -elf -Wall -fkeep-inline-functions -I/opt/src/lib/csu/i386-elf/../common -I/usr/obj/opt/src/i386/usr/include -c /opt/src/lib/csu/i386-elf/crt1.c -o crt1.o cc -I/opt/src/lib/csu/i386-elf/../common -I/usr/obj/opt/src/i386/usr/include -c /opt/src/lib/csu/i386-elf/crti.S -o crti.o cc -I/opt/src/lib/csu/i386-elf/../common -I/usr/obj/opt/src/i386/usr/include -c /opt/src/lib/csu/i386-elf/crtn.S -o crtn.o cc: Internal compiler error: program as got fatal signal 11 cc: Internal compiler error: program as got fatal signal 11 *** Error code 1 *** Error code 1 2 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error == /var/tmp/w.log.11-2 == cd /opt/src/lib/csu/i386-elf; make _EXTRADEPEND cc -O -pipe -march=i686 -elf -Wall -fkeep-inline-functions -I/opt/src/lib/csu/i386-elf/../common -I/usr/obj/opt/src/i386/usr/include -c /opt/src/lib/csu/i386-elf/crt1.c -o crt1.o cc -I/opt/src/lib/csu/i386-elf/../common -I/usr/obj/opt/src/i386/usr/include -c /opt/src/lib/csu/i386-elf/crti.S -o crti.o cc -I/opt/src/lib/csu/i386-elf/../common -I/usr/obj/opt/src/i386/usr/include -c /opt/src/lib/csu/i386-elf/crtn.S -o crtn.o cc: Internal compiler error: program as got fatal signal 11 cc: Internal compiler error: program as got fatal signal 11 *** Error code 1 *** Error code 1 2 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error This is my regular home machine, it usually runs SETI@Home, when I'm not here and is a NON-overclocked dual Pentium-II 300MHz. It has 320Mb of RAM and 390Mb of swap: Device 1K-blocks UsedAvail Capacity Type /dev/rda0b 393088 36 393052 0%Interleaved I tried building the elf/as manually, and it chokes on this file just the same. Here are my attempts to issue the same commands make and cc issue: # /usr/libexec/cpp0 -lang-asm -v -I/opt/src/lib/csu/i386-elf/../common -I/usr/obj/opt/src/i386/usr/include -$ -Di386 -Dunix -D__FreeBSD__=5 -D__FreeBSD_cc_version=52 -D__i386__ -D__unix__ -D__FreeBSD__=5 -D__FreeBSD_cc_version=52 -D__i386 -D__unix '-Acpu(i386)' '-Amachine(i386)' '-Asystem(unix)' '-Asystem(FreeBSD)' -D__ASSEMBLER__ '-Acpu(i386)' '-Amachine(i386)' -Di386 -D__i386 -D__i386__ -D__ELF__ /opt/src/lib/csu/i386-elf/crtn.S crtn.s # wc -l crtn.s 33 crtn.s # /usr/libexec/elf/as -v -o crtn.o crtn.s GNU assembler version 2.10.1 (i386-unknown-freebsdelf5.0) using BFD version 2.10.1 Segmentation fault - core dumped The crtn.s is rather simple: -- # 1 "/opt/src/lib/csu/i386-elf/crtn.S" [ empty lines ] .section .init,"ax",@progbits ret .section .fini,"ax",@progbits ret -- Yours, -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
trouble linking kernel (softdep)
Is this just me? After a fresh cvsup: make buildkernel KERNEL=RTFM-5.processed -DNOMODULES -DNO_MODULES -j 3 [...] cc -c -O -pipe -march=i686 -fomit-frame-pointer -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/opt/src/sys -I/opt/src/sys/dev -I/opt/src/sys/../include -I/opt/src/sys/contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -fno-builtin -fomit-frame-pointer -mpreferred-stack-boundary=2 setdef1.c sh /opt/src/sys/conf/newvers.sh RTFM cc -c -O -pipe -march=i686 -fomit-frame-pointer -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/opt/src/sys -I/opt/src/sys/dev -I/opt/src/sys/../include -I/opt/src/sys/contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -fno-builtin -fomit-frame-pointer -mpreferred-stack-boundary=2 vers.c linking kernel ffs_softdep.o: In function `softdep_flushfiles': ffs_softdep.o(.text+0x851): undefined reference to `ffs_flushfiles' ffs_softdep.o: In function `handle_workitem_freefrag': ffs_softdep.o(.text+0x13e7): undefined reference to `ffs_blkfree' ffs_softdep.o: In function `handle_workitem_freeblocks': ffs_softdep.o(.text+0x20f4): undefined reference to `ffs_blkfree' ffs_softdep.o(.text+0x2162): undefined reference to `ffs_blkfree' ffs_softdep.o: In function `indir_trunc': ffs_softdep.o(.text+0x2320): undefined reference to `ffs_blkfree' ffs_softdep.o: In function `handle_workitem_freefile': ffs_softdep.o(.text+0x3095): undefined reference to `ffs_freefile' ufs_lookup.o: In function `ufs_dirremove': ufs_lookup.o(.text+0x13c0): undefined reference to `ffs_snapgone' ufs_lookup.o: In function `ufs_dirrewrite': ufs_lookup.o(.text+0x14b4): undefined reference to `ffs_snapgone' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error /usr/src/sys/ufs/ffs/README.snapshot: $FreeBSD: src/sys/ufs/ffs/README.snapshot,v 1.1 2000/07/11 22:07:54 mckusick Exp $ /usr/src/sys/ufs/ffs/README.softupdates: $FreeBSD: src/sys/ufs/ffs/README.softupdates,v 1.9 2000/07/08 02:31:21 mckusick Exp $ /usr/src/sys/ufs/ffs/ffs_alloc.c: $FreeBSD: src/sys/ufs/ffs/ffs_alloc.c,v 1.69 2000/07/28 22:27:00 peter Exp $ /usr/src/sys/ufs/ffs/ffs_balloc.c: $FreeBSD: src/sys/ufs/ffs/ffs_balloc.c,v 1.28 2000/07/11 22:07:54 mckusick Exp $ /usr/src/sys/ufs/ffs/ffs_extern.h: $FreeBSD: src/sys/ufs/ffs/ffs_extern.h,v 1.36 2000/12/19 04:41:02 mckusick Exp $ /usr/src/sys/ufs/ffs/ffs_inode.c: $FreeBSD: src/sys/ufs/ffs/ffs_inode.c,v 1.67 2000/12/19 04:20:13 mckusick Exp $ /usr/src/sys/ufs/ffs/ffs_snapshot.c: $FreeBSD: src/sys/ufs/ffs/ffs_snapshot.c,v 1.10 2001/02/12 00:20:07 jake Exp $ /usr/src/sys/ufs/ffs/ffs_softdep.c: $FreeBSD: src/sys/ufs/ffs/ffs_softdep.c,v 1.84 2001/02/04 16:08:18 phk Exp $ /usr/src/sys/ufs/ffs/ffs_softdep_stub.c: $FreeBSD: src/sys/ufs/ffs/ffs_softdep_stub.c,v 1.15 2000/12/17 23:59:56 assar Exp $ /usr/src/sys/ufs/ffs/ffs_subr.c: $FreeBSD: src/sys/ufs/ffs/ffs_subr.c,v 1.26 2000/05/05 09:59:03 phk Exp $ /usr/src/sys/ufs/ffs/ffs_tables.c: $FreeBSD: src/sys/ufs/ffs/ffs_tables.c,v 1.7 1999/08/28 00:52:22 peter Exp $ /usr/src/sys/ufs/ffs/ffs_vfsops.c: $FreeBSD: src/sys/ufs/ffs/ffs_vfsops.c,v 1.138 2001/02/09 06:11:33 bmilekic Exp $ /usr/src/sys/ufs/ffs/ffs_vnops.c: $FreeBSD: src/sys/ufs/ffs/ffs_vnops.c,v 1.73 2001/02/04 16:08:18 phk Exp $ /usr/src/sys/ufs/ffs/fs.h: $FreeBSD: src/sys/ufs/ffs/fs.h,v 1.17 2001/01/15 18:30:40 iedowse Exp $ /usr/src/sys/ufs/ffs/softdep.h: $FreeBSD: src/sys/ufs/ffs/softdep.h,v 1.11 2000/07/11 22:07:55 mckusick Exp $ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
patch for gnu/usr.bin/ld/Makefile
Hello!
During my attempt to build 5.0-current using 4.2-BETA, I stumbled
upon the following error:
[...]
gzip -cn /opt/src/gnu/usr.bin/ld/ld.1aout ld.1aout.gz
cc -O -pipe -mcpu=i686 -march=i686 -I/opt/src/gnu/usr.bin/ld
-I/opt/src/gnu/usr.bin/ld/../../../libexec/rtld-aout
-I/opt/src/gnu/usr.bin/ld/../../../libexec/rtld-aout/i386
-I/opt/src/gnu/usr.bin/ld/../../../contrib/gcc -DIN_GCC -DDEMANGLE_CPLUSPLUS
-DFREEBSD_AOUT -I/usr/obj/opt/src/i386/usr/include -static -o ld ld.o symbol.o
lib.o shlib.o warnings.o support.o rrs.o xbits.o md.o cplus-dem.o
cplus-dem.o: In function `cplus_demangle':
cplus-dem.o(.text+0x819): undefined reference to `cplus_demangle_new_abi'
*** Error code 1
1 error
[...]
A surprisingly simple patch fixed it:
+++ gnu/usr.bin/ld/Makefile Mon Jan 3 05:41:11 2000
+++ gnu/usr.bin/ld/Makefile Fri Dec 15 00:40:07 2000
@@ -9,5 +9,5 @@
MAN1aout=ld.1aout
SRCS= ld.c symbol.c lib.c shlib.c warnings.c support.c rrs.c xbits.c md.c \
- cplus-dem.c
+ cplus-dem.c cp-demangle.c dyn-string.c
CFLAGS+= -I${.CURDIR} -I${RTLD} -I${RTLD}/${MACHINE_ARCH} \
-I${GCCDIR} -DIN_GCC -DDEMANGLE_CPLUSPLUS -DFREEBSD_AOUT
The Makefile did not change for almost a year, but some changes were
-mi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
SMP on Alpha?
Hello! Will the -current version of FreeBSD run on a multi-CPU axp machine and use all of the CPUs? Would that be a reliable box (assuming the admin sometimes knows what he is doing)? Do I want to make a "production" server out of an axp box at all in the near future? Thanks! -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: place of logfile for cron (PR 7682) - move it?
Nick Hibma once wrote: It seems that no one really has any objections to moving the log file. These would the locations to change(find | grep /var/log) src/usr.sbin/cron/cron/config.h src/usr.sbin/cron/doc/CHANGES (src/usr.sbin/cron/doc/CHANGES.FreeBSD a la xntpd?) src/etc/Makefile src/etc/newsyslog.conf src/etc/syslog.conf I'd, probably, put a symlink from the old location to the new one... -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tcp_wrapper in contrib and ports?
David O'Brien once wrote: Are not there any other uses for it? Like xinetd? If everything else (the libwrap, the man pages) is there, why not install the tcpd as well? BECAUSE IT IS NOT NEEDED by the base system. It's Ok, no need to yell. There are a number of things, not needed by the system, that are in the system. Not just the fortran and xtend, but also, say, bc(1) or cal(1). It may be usefull, and it requires no effort to have -- in fact, it probably needed some effort to be ripped out. But most importantly, it is hard to _add_ gracefuly to an installed system. Porter will have to work hard to make the tcp_wrapper port work with the system libwrap, while having two libwrap-s is just plain ugly. -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
