Re: 5.1-RELEASE TODO
On Sun, Jun 01, 2003 at 02:26:34AM -0700, Luigi Rizzo wrote: On Sun, Jun 01, 2003 at 03:32:56AM +0200, Bernd Walter wrote: ... :) And I hoped a programmer who knows the source could find out and fix very quickly. sorry, i missed the offending line number in your previous email. I think i missed a in all the first arguments to bcopy in the src/sbin/ipfw2.c changes :( this happens at lines 818, 1224, 1461 and 1701. Fortunately the kernel part seems correct. In detail, the fix should be the following: 818: - bcopy(rule-next_rule, set_disable, sizeof(set_disable)); + bcopy(rule-next_rule, set_disable, sizeof(set_disable)); 1224: - bcopy(d-rule, rulenum, sizeof(rulenum)); + bcopy(d-rule, rulenum, sizeof(rulenum)); 1461: - bcopy(((struct ip_fw *)data)-next_rule, + bcopy(((struct ip_fw *)data)-next_rule, 1701: - bcopy(d-rule, rulenum, sizeof(rulenum)); + bcopy(d-rule, rulenum, sizeof(rulenum)); Look way bettter now :) I wasn't able to crash the kernel with missaligned access any more, but the userland tool still does in some situations: [59]cicely12# ipfw show pid 2121 (ipfw): unaligned access: va=0x1200ac09c pc=0x120003bb4 ra=0x120003bfc op=ldq pid 2121 (ipfw): unaligned access: va=0x1200ac0a4 pc=0x120003bdc ra=0x120003bc8 op=ldq 001005237 824333 allow tcp from any to any dst-port 1-65535,1-65535 00200 0 0 allow tcp from any to any dst-port 1-65535,1-65535,1-65535 pid 2121 (ipfw): unaligned access: va=0x1200ac09c pc=0x120002260 ra=0x1200015ec op=ldq pid 2121 (ipfw): unaligned access: va=0x1200ac0a4 pc=0x120002264 ra=0x1200015ec op=ldq 65535 5836817 1002036976 allow ip from any to any [64]cicely12# sysctl machdep.unaligned_sigbus=1 machdep.unaligned_sigbus: 0 - 1 [65]cicely12# ipfw show pid 2146 (ipfw): unaligned access: va=0x1200ac09c pc=0x120003bb4 ra=0x120003bfc op=ldq Bus error (core dumped) Exit 138 [66]cicely12# gdb ./ipfw ipfw.core GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as alpha-undermydesk-freebsd... Core was generated by `ipfw'. Program terminated with signal 10, Bus error. #0 0x120003bb4 in list (ac=0, av=0x11fff720) at ipfw2.c:1629 1629width = snprintf(NULL, 0, %llu, r-pcnt); (gdb) bt #0 0x120003bb4 in list (ac=0, av=0x11fff720) at ipfw2.c:1629 #1 0x120007d10 in ipfw_main (ac=1, av=0x11fff718) at ipfw2.c:3486 #2 0x1200084bc in main (ac=2, av=0x11fff710) at ipfw2.c:3637 -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1-RELEASE TODO
This is an automated bi-daily mailing of the FreeBSD 5.1 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.1R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.1. FreeBSD 5.1 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.1. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.1-RELEASE ++ | Issue | Status| Responsible | Description | |--+-+-+-| | | | | There are reports of| | ipfw/ipfw2 | | | alignment problems with | | alignment issues | In progress | Luigi Rizzo | ipfw and/or ipfw2 on| | on alpha/sparc64 | | | 64-bit platforms| | | | | (specifically alpha and | | | | | sparc64). | ++ Desired Features for 5.1-RELEASE ++ |Issue |Status |Responsible |Description | ++ Documentation items that must be resolved for 5.1 ++ |Issue |Status |Responsible |Description | ++ Areas requiring immediate testing ++ | Issue | Status | Responsible |Description| |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| | || | PAE support allows the| | || | use of up to 64GB of RAM | | PAE support for | -- | --| on Pentium Pro and above | | i386 || | systems. Virtual | | || | addresses are still | | || | constrained to 32-bits. | |---++---+---| | || | The recently upgraded | | || | if_wi driver is more | | || | tuned to Prism hardware | | || | than to Lucent hardware, | | if_wi problems on || | resulting in system | | Lucent hardware | -- | --| lockups and poor | | || | performance when using| | || | Lucent hardware. These| | || | problems are believed to | | || | be fixed but more testing | | || | is welcome. | |---++---+---| | || | For 5.1-RELEASE, the | | || | default file system type | | || | for newly created file| | || | systems is UFS2 rather| | UFS2 as || | than UFS1. newfs(8) and | | installation, | -- | Robert Watson | sysinstall(8) have been | | newfs default || | updated to use this new | | || | default. Testing to make | | || | sure all goes well after | | || | the change (committed on | | || | April 20, 2003) is vital. | |---++---+---| | |
Re: raidframe
On Sun, Jun 01, 2003 at 02:51:07PM +0300, Petri Helenius wrote: Is there anyone actually successfully using raidframe and if yes, what kind of hardware? RAIDframe is non-functional in 5.1 and -current [kern/50541] and it would be unwise to use it in 5.0 for anything other than experimentation. Hopefully it will be fixed before 5.2. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
I am successfully using a Mylex DAC1164PVX RAID controller on 5-CURRENT: mlx0: Mylex version 5 RAID interface port 0x2000-0x207f mem 0xf800-0xfbff,0xec91-0xec91007f irq 5 at device 8.0 on pci2 mlx0: controller initialisation in progress... mlx0: initialisation complete. mlx0: DAC1164PVX, 3 channels, firmware 5.08-0-87, 64MB RAM mlxd0: Mylex System Drive on mlx0 mlxd0: 105009MB (215058432 sectors) RAID 5 (online) On Sun, Jun 01, 2003 at 02:51:07PM +0300, Petri Helenius wrote: Is there anyone actually successfully using raidframe and if yes, what kind of hardware? Same question goes for any recent SCSI RAID controllers supported by FreeBSD. I admit not having tried all combinations but it seems that using anything else than simple ahc scsi stuff results in kernel panic with 5.x. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Bob Willcox Patience is a minor form of despair, disguised as virtue. [EMAIL PROTECTED]-- Ambrose Bierce, on qualifiers Austin, TX ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vm-related panic with 5.1RC1
On Sun, 1 Jun 2003 11:26:12 +0200 (CEST) Martin Blapp [EMAIL PROTECTED] wrote: Hi all, I just got this panic during compile of openoffice Fatal trap 12 while in kernel mode fault virtual address = 0x68 fault code= supervisor read, page not present instruction pointer = 0x8:0xc0271f4d stack pointer = 0x10:0xe6e51ab0 frame pointer = 0x10:0xe6e51ae0 code segement = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32, gran 1 processor flags = interrupt enabled, resume, IOPL =1 current process = 22362 kernel: type 12 trap, code=0 Stopped at _mtx_lock_sleep+0x16d: movl 0x68(%ecx),%edx db trace _mtx_lock_sleep(c082f0b0,0,0,0,c0678415) at _mtx_lock_sleep+0x16d vm_map_delete(c082f000, d0d0d000, d0d11000, e6effda0, c78d5720) at vm_map_delete+0x383) vm_map_remove(c082f000, d0d0d000, d0d11000, e6e51b9c, c03b247f) at vm_map_remove+0x58) kmem_free(c082f000, d0d0d000, 3000, 0, 80) at kmem_free+0x32 cpu_thread_clean(c78d54c0, e6e51bb4,c78d54c0, c78d54c0, e6e51be4) at cpu_thread_clean+0x7f thread_free(c78d54c0, e6e51bd0, c0275839, c67a3000, c6abf030) at thread_free+0x14 thread_reap(c78d55f0) at thread_reap+0x16c thread_wait(c656b000, , 0, c03feb34,0) at thread_wait+0x55 wait1(c6569980, e6e51d10, 0, e6e51d40, c03b0dfa) at wait1+0x738 wait5(c6569980, e6e51d10, 10, c6569980, 4) at wait4+0x20 syscall(2f, 2f, 2f, bfbff074, 325) at syscall+0x2aa Xint0x80_syscall() at Xint0x80_syscall()+0x1d --- syscall (7, FreeBSD ELF32, wait4) eip = 0x807b28b, esp = 0xbfbfefbc, ebp = 0xbfbfefd8) Unfortunatly my partition was too small, so I could not get a dump. I've adjusted this now and the next time it panics I'll have one ready. Martin This is exactly the panic I am seeing on my dual-processor box. My current suspicion is that it somehow relates to the same pcb_ext being freed twice. I do not need OpenOffice to trigger the bug, on SMP configuration it happens all the time. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-RELEASE TODO
This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. FreeBSD 5.2 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.2. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.2-RELEASE ++ |Issue| Status | Responsible | Description | |-+--+-+-| | | | | KSE M:N threading | | | | | support is reaching | | | | | experimental yet| | | | Julian | usable status on| | Production-quality | In | Elischer, David | i386 for| | M:N threading | progress | Xu, Daniel | 5.1-RELEASE. M:N| | | | Eischen | threading should be | | | | | productionable and | | | | | usable on all | | | | | platforms by| | | | | 5.2-RELEASE.| |-+--+-+-| | | | | Currently, the MD | | | | | elements of KSE are | | | | | present only for| | | | | the i386 platform, | | | | | limiting use of KSE | | | | | to the i386 | | | | | platform. It is | | | | | highly desirable to | | KSE support for | | Jake| make KSE available | | sparc64, alpha, | -- | Burkholder, --, | on non-i386 | | ia64| | -- | platforms for | | | | | 5.2-RELEASE so that | | | | | KSE can see more| | | | | broad exposure, and | | | | | the performance | | | | | benefits of KSE can | | | | | be visible to users | | | | | of the 64-bit | | | | | FreeBSD | | | | | architectures. | |-+--+-+-| | | | | Kris Kennaway | | | | | reports high| | | | | instability of | | | | | 5-CURRENT on ia64 | | | In | Marcel | machines, such as | | ia64 stability | Progress | Moolenaar | the pluto* | | | | | machines. These | | | | | problems need to be | | | | | fixed in order to | | | | | get a successful| | | | | package build. | |-+--+-+-| | | | | ia64 serial console | | | | | support is reported | | | | | to not be | | | | | functional on HP| | | In | Marcel | Itanium2 platforms. | | ia64 sio support| progress | Moolenaar, | A reworking of the | | | | Warner Losh | sio driver to | | | | | improve platform| | | | | independence and| |
IPv4 problems with an driver
Hi there, I'm having some troubles with my an (cisco 350) device under current. it seems like ipv4 is not workint perfectly. ipv6 seems to work fine though. here the ping statistics to my gateway over ipv4 and ipv6 - --- 192.168.2.1 ping statistics --- 100 packets transmitted, 67 packets received, 33% packet loss round-trip min/avg/max/stddev = 2.114/2.232/3.187/0.168 ms - - --- 2001:ab8:1002:666::1 ping6 statistics --- 101 packets transmitted, 101 packets received, 0% packet loss round-trip min/avg/max/std-dev = 2.036/2.987/8.183/1.111 ms - Has anyone seen this problems as well? Regards, Joris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Mailinglistenverwalter: : ML-(un)subscribe
-- Ihre E-Mail an [EMAIL PROTECTED] mit dem Kommando subscribe [EMAIL PROTECTED] [EMAIL PROTECTED] muss überprüft werden. Hierzu wird eine weitere E-Mail mit einem Authentifizierungschlüssel an folgende Adresse geschickt: [EMAIL PROTECTED] Erst wenn diese zweite E-Mail nochmals vom Empfänger bestätigt wurde ist [EMAIL PROTECTED] auf der Mailingliste angemeldet. - Your request to [EMAIL PROTECTED]: subscribe [EMAIL PROTECTED] [EMAIL PROTECTED] must be authenticated. To accomplish this, another request must be sent in with an authorization key, which has been sent to: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
subscribe newsletter@laserhotline.de
-- ACHTUNG: Ihre E-Mail-Adresse wurde noch NICHT in die Mailingliste [EMAIL PROTECTED] eingetragen! Bitte bestätigen Sie die Eintragung nun wie folgt beschrieben: - Sie erhalten diese E-Mail zur Verifizierung. Um Ihre E-Mail-Adresse in die obige Mailingliste einzutragen, klicken Sie bitte auf diesen Link: http://confirm.mailingliste.kundenserver.de/cgi-bin/auth.cgi?cookie=c043c9c9[EMAIL PROTECTED][EMAIL PROTECTED] - Oder schicken Sie zur Bestätigung eine E-Mail, indem Sie auf diese E-Mail antworten. Verwenden Sie dafür die 'Beantworten/Reply' Funktion in ihrem E-Mail-Programm. Löschen Sie dann alles bis auf folgende Textzeile und stellen Sie dabei sicher, dass kein '' am Zeilenanfang steht und dass Sie keine HTML E-Mail versenden: auth c043c9c9 subscribe [EMAIL PROTECTED] [EMAIL PROTECTED] - Oder, wenn Sie nicht Teilnehmer der Mailingliste werden wollen, ignorieren Sie diese E-Mail einfach, Sie werden dann nicht auf die Liste eingetragen. Bei Fragen zur Mailingliste wenden Sie sich bitte an den Administrator: [EMAIL PROTECTED] Someone (possibly you) has requested that your email address be added to the mailing list [EMAIL PROTECTED]. - If you really want this action to be taken, please click this link: http://confirm.mailingliste.kundenserver.de/cgi-bin/auth.cgi?cookie=c043c9c9[EMAIL PROTECTED][EMAIL PROTECTED] - Or send the following command (exactly as shown, no leading '') back to [EMAIL PROTECTED], please send the mail as plain text, not as HTML encoded mail: auth c043c9c9 subscribe [EMAIL PROTECTED] [EMAIL PROTECTED] - If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If you have any questions about the policy of the list owner, please contact contact [EMAIL PROTECTED] L'inscription de votre adresse e-mail sur la liste de diffusion [EMAIL PROTECTED] a été demandé (vraisemblablement par vous-même). - Afin de confirmer cette inscription veuillez nous renvoyer la ligne ci-dessous sans la modifier (veuillez même ne pas rajouter au début de la ligne) à [EMAIL PROTECTED] Veuillez nous renvoyer cet email dans le format texte et pas au format HTML: auth c043c9c9 subscribe [EMAIL PROTECTED] [EMAIL PROTECTED] - Alternativement, vous pouvez aussi vous authentifier en cliquent le lient suivant: http://confirm.mailingliste.kundenserver.de/cgi-bin/auth.cgi?cookie=c043c9c9[EMAIL PROTECTED][EMAIL PROTECTED] - Si vous ne voulez pas vous inscrire à cette liste de diffusion, ignorer simplement cet email. Vous ne serez alors pas inscrit sur la liste. Pour toutes questions au sujet de cette liste de diffusion, veuillez vous adresser à l'administrateur: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Mailinglistenverwalter: : auth
-- Willkommen, Ihre Anmeldung zu [EMAIL PROTECTED] war erfolgreich. Wenn Sie sich von der Liste wieder austragen möchten, benutzen Sie einfach das WWW-Interface oder schicken Sie eine E-Mail an [EMAIL PROTECTED], mit leerem Betreff und folgender Zeile in der Nachricht: unsubscribe [EMAIL PROTECTED] [EMAIL PROTECTED] Bitte schicken Sie Ihren Wunsch zum Austragen aus der Liste nicht an die Liste selbst, oder den Administrator der Liste. Bei Fragen zur Mailingliste wenden Sie sich an den Administrator [EMAIL PROTECTED] - Welcome, your subscription to [EMAIL PROTECTED] has been successful. If you ever want to get off the list use the WWW interface or send an email to [EMAIL PROTECTED] with an empty subject and one line in the body reading unsubscribe [EMAIL PROTECTED] [EMAIL PROTECTED] Please do not send any unsubscribe requests directly to the list or the list maintainer. If you have questions regarding this list write to the maintainer [EMAIL PROTECTED] - Bienvenue! Suite à votre demande, vous venez d'être inscrit sur la liste de diffusion [EMAIL PROTECTED] Si vous souhaitez ne plus faire partie de cette liste, il vous suffit d' utiliser l'interface WWW, ou d'envoyer le mail suivant (sans objet) à [EMAIL PROTECTED]: unsubscribe [EMAIL PROTECTED] [EMAIL PROTECTED] Attention de ne pas envoyer ce message de désinscription ni à la liste, ni à l'administrateur de la liste! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Mailinglistenverwalter: : auth
-- Bei der Bearbeitung Ihrer Eintragung ist ein Fehler aufgetreten: [EMAIL PROTECTED] ist bereits auf der Liste [EMAIL PROTECTED] eingetragen. - An error occurred while processing your subscribe request: [EMAIL PROTECTED] is already subscribed to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vm-related panic with 5.1RC1
On Sun, 1 Jun 2003, Martin Blapp wrote: Hi all, I just got this panic during compile of openoffice Fatal trap 12 while in kernel mode fault virtual address = 0x68 fault code= supervisor read, page not present instruction pointer = 0x8:0xc0271f4d stack pointer = 0x10:0xe6e51ab0 frame pointer = 0x10:0xe6e51ae0 code segement = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32, gran 1 processor flags = interrupt enabled, resume, IOPL =1 current process = 22362 kernel: type 12 trap, code=0 Stopped at _mtx_lock_sleep+0x16d: movl 0x68(%ecx),%edx db trace _mtx_lock_sleep(c082f0b0,0,0,0,c0678415) at _mtx_lock_sleep+0x16d vm_map_delete(c082f000, d0d0d000, d0d11000, e6effda0, c78d5720) at vm_map_delete+0x383) vm_map_remove(c082f000, d0d0d000, d0d11000, e6e51b9c, c03b247f) at vm_map_remove+0x58) kmem_free(c082f000, d0d0d000, 3000, 0, 80) at kmem_free+0x32 cpu_thread_clean(c78d54c0, e6e51bb4,c78d54c0, c78d54c0, e6e51be4) at cpu_thread_clean+0x7f thread_free(c78d54c0, e6e51bd0, c0275839, c67a3000, c6abf030) at thread_free+0x14 thread_reap(c78d55f0) at thread_reap+0x16c thread_wait(c656b000, , 0, c03feb34,0) at thread_wait+0x55 wait1(c6569980, e6e51d10, 0, e6e51d40, c03b0dfa) at wait1+0x738 wait5(c6569980, e6e51d10, 10, c6569980, 4) at wait4+0x20 syscall(2f, 2f, 2f, bfbff074, 325) at syscall+0x2aa Xint0x80_syscall() at Xint0x80_syscall()+0x1d --- syscall (7, FreeBSD ELF32, wait4) eip = 0x807b28b, esp = 0xbfbfefbc, ebp = 0xbfbfefd8) Unfortunatly my partition was too small, so I could not get a dump. I've adjusted this now and the next time it panics I'll have one ready. This is with KSE right? I've seen this.. but never when I'm ready for it.. The 0xd0d11000 is always there.. it seems to be a symptom of the problem. It' probably an important clue.. I think it indicates a garbage pointer fo some type. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Sun, 1 Jun 2003 09:00:13 -0400 (EDT) Robert Watson [EMAIL PROTECTED] wrote: Areas requiring immediate testing I already reported to -current that I wasn't able to umount a msdosfs slice a while ago (umount failed with busy and the slice was still mounted), last week I had the possibility to test it with a May 25 kernel again and I still wasn't able to umount the msdosfs slice. I tried not with the same harddisk as last time and the slices wheren't created by the same Windows system, so I exclude the possibility of a damaged slice. I try to get time to connect the harddisk again to my system (with a May 30 kernel) before I return the disk, but I think the issue should get added to the list of issues to look at before 5.1 (at least to be able to add it to the errata). Bye, Alexander. -- ...and that is how we know the Earth to be banana-shaped. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
confirm subscribe to phpwizard@rent-a-phpwizard.de
Hi! This is the ezmlm program. I'm managing the [EMAIL PROTECTED] mailing list. To confirm that you would like [EMAIL PROTECTED] added to the phpwizard mailing list, please send an empty reply to this address: [EMAIL PROTECTED] Usually, this happens when you just hit the reply button. If this does not work, simply copy the address and paste it into the To: field of a new message. This confirmation serves two purposes. First, it verifies that I am able to get mail through to you. Second, it protects you in case someone forges a subscription request in your name. --- Administrative commands for the phpwizard list --- I can handle administrative requests automatically. Please do not send them to the list address! Instead, send your message to the correct command address: To subscribe to the list, send a message to: [EMAIL PROTECTED] To remove your address from the list, send a message to: [EMAIL PROTECTED] Send mail to the following for info and FAQ for this list: [EMAIL PROTECTED] [EMAIL PROTECTED] To get messages 123 through 145 (a maximum of 100 per request), mail: [EMAIL PROTECTED] To get an index with subject and author for messages 123-456 , mail: [EMAIL PROTECTED] They are always returned as sets of 100, max 2000 per request, so you'll actually get 100-499. To receive all messages with the same subject as message 12345, send an empty message to: [EMAIL PROTECTED] The messages do not really need to be empty, but I will ignore their content. Only the ADDRESS you send to is important. You can start a subscription for an alternate address, for example [EMAIL PROTECTED], just add a hyphen and your address (with '=' instead of '@') after the command word: [EMAIL PROTECTED] To stop subscription for this address, mail: [EMAIL PROTECTED] In both cases, I'll send a confirmation message to that address. When you receive it, simply reply to it to complete your subscription. If despite following these instructions, you do not get the desired results, please contact my owner at [EMAIL PROTECTED] Please be patient, my owner is a lot slower than I am ;-) --- Enclosed is a copy of the request I received. Return-Path: [EMAIL PROTECTED] Received: (qmail 20207 invoked by uid 609); 1 Jun 2003 14:35:03 - Date: 1 Jun 2003 14:35:03 - Message-ID: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: From: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
confirmation required -- for Disquiet.com subscription
To complete your Disquiet.com email subscription, you must confirm your request by replying to this message. Be sure to include this phrase: ['j9r3,a1] If you did not request, or do not want, a subscription to the free Disquiet.com email newsletter, please accept this apology and ignore this message. Thanks. PS: If you wouldn't mind, please note in your reply how you came across the Disquiet website.. - - - Disquiet.com \ reflections on ambient/electronic music, and interviews with the people who make it \ http://www.disquiet.com \ [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Eh..
Can someone find out who's trying to add the freebsd mailinglist to other mailinglists? This is getting annoying. Erik. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Confirm your subscription to: Fashions of India Newsletter
A few minutes ago, you entered your email address at http://www.fashions-of-india.com to be added to our mailing list. This list has a double optin feature so you must visit the URL listed below to confirm your subscription. Sincerely, The Fashions of India Team http://www.ymlp.com/confirm.php?13360_03060117504118 __ You receive this message because your email address was entered at http://www.fashions-of-india.com/newsletter.htm ( IP: 139.175.150.11 ; Netscape 5.0 ; FreeBSD ) If this message was sent in error, please disregard it and no further messages will be sent. Powered by http://www.YourMailingListProvider.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Trolling and forge subscribes.
Can someone find out who's trying to add the freebsd mailinglist to other mailinglists? This is getting annoying. PLEASE DO NOT REPLY TO ANY OF THESE TROLLS! Turn on your filters, train your spam-assassins etc. Please DON'T contribute to the traffic. The best way to make a troll go away is to ignore it. I'm dealing with the problem. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fatal trap on RELENG_5_1 SMP
Could you build your kernel with options DDB and debugging symbols, and when the kernel drops to the debugger on this panic, copy and past the stack trace into an e-mail? Alternatively, or perhaps as well, extract the information with a core. There are some excellent instructions on generating some comprehensive crash reports here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html This looks like it's a NULL pointer dereference, so the question we need to answer is: which pointer? To do that, we'll need to turn that back into a C line number, which will need the kernel with debugging symbols. Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Sun, 1 Jun 2003, Magnus J wrote: Hello everyone I'm getting a fatal trap when I do 'shutdown' on an SMP-box that I did cvsup on RELENG_5_1 yesterday. 'reboot' works without any problems. This is the message: Fatal trap 12: page fault while in kernel mode cpuid=1; lapic.id = 0100 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xe0197d11 stack pointer = 0x10:0xe0197cec frame pointer = 0x10:0x8 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 = 11 (idle: cpu1) trap number = 12 panic: page fault cpuid=1; lapic.id = 0100 boot() called on cpu#1 The machine is a 2x933 MHz PIII, Mainboard is Tyan Tiger 230, 1.5 GB RAM. If you need more details, please let me know. I'm not a member of this mailing list. Regards Magnus _ Gå före i kön och få din sajt värderad på nolltid med Yahoo! Express Se mer på: http://se.docs.yahoo.com/info/express/help/index.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
subscribe {current,chat}@freebsd.org
___ / _|_ _ ___| | __ | |_| | | |/ __| |/ / | _| |_| | (__| |_| \__,_|\___|_|\_\ _ _ _ __ _ _| | | | '_ \| | | | | | | |_) | |_| | | | | .__/ \__,_|_|_| |_| _ _ | |__ ___ _ __ _ __ (_)_ __ __ _ | '_ \ / _ \ '_ \| '_ \| | '_ \ / _` | | | | | __/ | | | | | | | | | | (_| | |_| |_|\___|_| |_|_| |_|_|_| |_|\__, | |___/ _ | | _ _ __ ___ _ __ | |/ / _` | '_ ` _ \| '_ \ |(_| | | | | | | |_) | |_|\_\__,_|_| |_| |_| .__/ |_| This message released under the Fuck Fumerola License -- Jason Stryker [EMAIL PROTECTED] -- http://www.fastmail.fm - Send your email first class ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
subscribe {current,chat}@freebsd.org
___ / _|_ _ ___| | __ | |_| | | |/ __| |/ / | _| |_| | (__| |_| \__,_|\___|_|\_\ _ _ _ __ _ _| | | | '_ \| | | | | | | |_) | |_| | | | | .__/ \__,_|_|_| |_| _ _ | |__ ___ _ __ _ __ (_)_ __ __ _ | '_ \ / _ \ '_ \| '_ \| | '_ \ / _` | | | | | __/ | | | | | | | | | | (_| | |_| |_|\___|_| |_|_| |_|_|_| |_|\__, | |___/ _ | | _ _ __ ___ _ __ | |/ / _` | '_ ` _ \| '_ \ |(_| | | | | | | |_) | |_|\_\__,_|_| |_| |_| .__/ |_| This message released under the Fuck Fumerola License -- Jason Stryker [EMAIL PROTECTED] -- http://www.fastmail.fm - Choose from over 50 domains or use your own ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
subscribe {current,chat}@freebsd.org
___ / _|_ _ ___| | __ | |_| | | |/ __| |/ / | _| |_| | (__| |_| \__,_|\___|_|\_\ _ _ _ __ _ _| | | | '_ \| | | | | | | |_) | |_| | | | | .__/ \__,_|_|_| |_| _ _ | |__ ___ _ __ _ __ (_)_ __ __ _ | '_ \ / _ \ '_ \| '_ \| | '_ \ / _` | | | | | __/ | | | | | | | | | | (_| | |_| |_|\___|_| |_|_| |_|_|_| |_|\__, | |___/ _ | | _ _ __ ___ _ __ | |/ / _` | '_ ` _ \| '_ \ |(_| | | | | | | |_) | |_|\_\__,_|_| |_| |_| .__/ |_| This message released under the Fuck Fumerola License -- Jason Stryker [EMAIL PROTECTED] -- http://www.fastmail.fm - A fast, anti-spam email service. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
subscribe {current,chat}@freebsd.org
___ / _|_ _ ___| | __ | |_| | | |/ __| |/ / | _| |_| | (__| |_| \__,_|\___|_|\_\ _ _ _ __ _ _| | | | '_ \| | | | | | | |_) | |_| | | | | .__/ \__,_|_|_| |_| _ _ | |__ ___ _ __ _ __ (_)_ __ __ _ | '_ \ / _ \ '_ \| '_ \| | '_ \ / _` | | | | | __/ | | | | | | | | | | (_| | |_| |_|\___|_| |_|_| |_|_|_| |_|\__, | |___/ _ | | _ _ __ ___ _ __ | |/ / _` | '_ ` _ \| '_ \ |(_| | | | | | | |_) | |_|\_\__,_|_| |_| |_| .__/ |_| This message released under the Fuck Fumerola License -- Jason Stryker [EMAIL PROTECTED] -- http://www.fastmail.fm - Or how I learned to stop worrying and love email again ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
subscribe {current,chat}@freebsd.org
___ / _|_ _ ___| | __ | |_| | | |/ __| |/ / | _| |_| | (__| |_| \__,_|\___|_|\_\ _ _ _ __ _ _| | | | '_ \| | | | | | | |_) | |_| | | | | .__/ \__,_|_|_| |_| _ _ | |__ ___ _ __ _ __ (_)_ __ __ _ | '_ \ / _ \ '_ \| '_ \| | '_ \ / _` | | | | | __/ | | | | | | | | | | (_| | |_| |_|\___|_| |_|_| |_|_|_| |_|\__, | |___/ _ | | _ _ __ ___ _ __ | |/ / _` | '_ ` _ \| '_ \ |(_| | | | | | | |_) | |_|\_\__,_|_| |_| |_| .__/ |_| This message released under the Fuck Fumerola License -- Jason Stryker [EMAIL PROTECTED] -- http://www.fastmail.fm - Does exactly what it says on the tin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Polishing touch
Hello, just in case re@ or a maintainer finds this worhtwhile : from my /etc/rc.conf : ifconfig_tap0=lladdr 00:90:27:3f:12:9f apm_enable=YES apmd_enable=YES This gives me in dmesg-a (today's CVS) : 1) Setting hostname: M. module_register: module if_tap already exists! Module if_tap failed to register: 17 can't re-use a leaf (if_tap_debug)! tap0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 ether 00:90:27:3f:12:9f bit I just compiled if_tap into my kernel, and I nowehere asked explicitly for kldloading if_tap (IIRC) 2) NFS access cache time=2 Starting usbd. Starting apm. Starting apm. Starting apmd. I somehow twice get 'Starting apm' ; voila, Arno ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Polishing touch
On Sunday 01 June 2003 18:45, [EMAIL PROTECTED] wrote: Hello, Hi Arno just in case re@ or a maintainer finds this worhtwhile : 1) Setting hostname: M. module_register: module if_tap already exists! Module if_tap failed to register: 17 can't re-use a leaf (if_tap_debug)! tap0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 ether 00:90:27:3f:12:9f bit I just compiled if_tap into my kernel, and I nowehere asked explicitly for kldloading if_tap (IIRC) I don't exactly know why it tries to load if_tap when it is already present, but FreeBSD should not allow it to be double-linked into the kernel. I created a patch that (hopefully ;) disallows this. You can find it at : http://hobbes.bsd-dk.dk/~npp/kern_linker.patch I would appreciate if you have the time to test this to see if it aborts the loading correctly. I know it's not exactly the real fix but it should stop some panics. Could you also test if unloading the if_tap module panic's the system ? This should ofcourse be tested without my patch and preferably when a tap device is in use. voila, Arno Best regards, Nicolai Petri catpipe Systems ApS Ps. If any commiter reads this and would help getting this into the tree please let me know. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
Alexander Leidinger wrote: On Sun, 1 Jun 2003 09:00:13 -0400 (EDT) Robert Watson [EMAIL PROTECTED] wrote: Areas requiring immediate testing I already reported to -current that I wasn't able to umount a msdosfs slice a while ago (umount failed with busy and the slice was still mounted), last week I had the possibility to test it with a May 25 kernel again and I still wasn't able to umount the msdosfs slice. I tried not with the same harddisk as last time and the slices wheren't created by the same Windows system, so I exclude the possibility of a damaged slice. I try to get time to connect the harddisk again to my system (with a May 30 kernel) before I return the disk, but I think the issue should get added to the list of issues to look at before 5.1 (at least to be able to add it to the errata). Bye, Alexander. I've mounted many MSDOS filesystems recently without problems. Do have any other information about this? Did you verify that there were no open vnodes on the filesystem? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Polishing touch
On Sunday 01 June 2003 18:45, [EMAIL PROTECTED] wrote: module_register: module if_tap already exists! Module if_tap failed to register: 17 can't re-use a leaf (if_tap_debug)! FWIW, same thing happens for if_tun. -- | Michael Nottebrock| KDE on FreeBSD | ,ww | | [EMAIL PROTECTED] | --- | ,wWWCybaWW_) | | --- | http://freebsd.kde.org | free `WSheepW'| | http://tigress.com/lofi | --- | node II II | pgp0.pgp Description: signature
Re: 5.1-RELEASE TODO
On Sun, 01 Jun 2003 11:46:34 -0600 Scott Long [EMAIL PROTECTED] wrote: I've mounted many MSDOS filesystems recently without problems. Do have any other information about this? Did you verify that there were no open vnodes on the filesystem? I just copied 13 GB from the msdosfs to an ufs slice and 8 GB from an ufs to the msdosfs slice. After that the system was idle for a while (several minutes, maybe 2 hours). Then I just did some 'ls' invocations to verify the copy procedure and tried to umount. I hadn't any program running with legitimate access to /mnt and I have no program running which accesses a random filesystem path, so no vnodes should have been open then. At the moment I have a simulation running in the background, so I can't reconnect the harddisk to the system, but I reconnect it tomorrow and present the typescript of the terminal session. Is there a way to set breakpoints in the kernel (no serial console) and if so, what would be interesting to look at? Bye, Alexander. -- The computer revolution is over. The computers won. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
GEOM buildworld failure
Getting the following message on a buildworld: mkdep -f .depend -a -I/usr/src/lib/libgeom /usr/src/lib/libgeom/geom_getxml.c /usr/src/lib/libgeom/geom_stats.c /usr/src/lib/libgeom/geom_xml2tree.c /usr/src/lib/libgeom/geom_ctl.c /usr/src/lib/libgeom/geom_ctl.c:48:27: geom/geom_ext.h: No such file or directory mkdep: compile failed Doing a 'find' doesn't turn up the header file: pilgrim:/usr/src# find . -name 'geom_ext*' pilgrim:/usr/src# ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM buildworld failure
This is already be fixed. In message [EMAIL PROTECTED], David Magda writes: Getting the following message on a buildworld: mkdep -f .depend -a -I/usr/src/lib/libgeom /usr/src/lib/libgeom/geom_getxml.c /usr/src/lib/libgeom/geom_stats.c /usr/src/lib/libgeom/geom_xml2tree.c /usr/src/lib/libgeom/geom_ctl.c /usr/src/lib/libgeom/geom_ctl.c:48:27: geom/geom_ext.h: No such file or directory mkdep: compile failed Doing a 'find' doesn't turn up the header file: pilgrim:/usr/src# find . -name 'geom_ext*' pilgrim:/usr/src# -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
i2c modules not hooked up to the build?
Hi, is there a specific reason why the i2c modules aren't hooked up to the build in sys/modules/Makefile? diff -u -r1.324 Makefile --- Makefile2003/05/31 18:36:40 1.324 +++ Makefile2003/06/01 19:11:36 @@ -177,6 +177,7 @@ gnufpu \ hea \ hfa \ + i2c \ ibcs2 \ ie \ linprocfs \ Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Fatal trap on RELENG_5_1 SMP
Hello I've rebuilt the kernel with these debug-options, and now I'm having difficulty reproducing the problem. That was not an issue before. Everytime I did 'shutdown', it crashed. Will continue trying. Any suggestions? Regards Magnus --- Robert Watson [EMAIL PROTECTED] skrev: Could you build your kernel with options DDB and debugging symbols, and when the kernel drops to the debugger on this panic, copy and past the stack trace into an e-mail? Alternatively, or perhaps as well, extract the information with a core. There are some excellent instructions on generating some comprehensive crash reports here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html This looks like it's a NULL pointer dereference, so the question we need to answer is: which pointer? To do that, we'll need to turn that back into a C line number, which will need the kernel with debugging symbols. Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories On Sun, 1 Jun 2003, Magnus J wrote: Hello everyone I'm getting a fatal trap when I do 'shutdown' on an SMP-box that I did cvsup on RELENG_5_1 yesterday. 'reboot' works without any problems. This is the message: Fatal trap 12: page fault while in kernel mode cpuid=1; lapic.id = 0100 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xe0197d11 stack pointer = 0x10:0xe0197cec frame pointer = 0x10:0x8 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 = 11 (idle: cpu1) trap number = 12 panic: page fault cpuid=1; lapic.id = 0100 boot() called on cpu#1 The machine is a 2x933 MHz PIII, Mainboard is Tyan Tiger 230, 1.5 GB RAM. If you need more details, please let me know. I'm not a member of this mailing list. Regards Magnus _ Gå före i kön och få din sajt värderad på nolltid med Yahoo! Express Se mer på: http://se.docs.yahoo.com/info/express/help/index.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] _ Gå före i kön och få din sajt värderad på nolltid med Yahoo! Express Se mer på: http://se.docs.yahoo.com/info/express/help/index.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
RAIDframe is non-functional in 5.1 and -current [kern/50541] and it would be unwise to use it in 5.0 for anything other than experimentation. Hopefully it will be fixed before 5.2. Makes one wonder how broken code ever got into the tree in the first place... Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on ia64/ia64
TB --- 2003-06-01 20:12:52 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-06-01 20:12:52 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-01 20:15:32 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools [...] error before `:' token In file included from /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gperf/src/bool-array.h:59, from /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gperf/src/bool-array.cc:21: /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gperf/src/options.h:150:1: unterminated #ifdef /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gperf/src/options.h:32:1: unterminated #ifndef In file included from /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gperf/src/bool-array.cc:21: /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gperf/src/bool-array.h:55:1: unterminated #ifdef /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/contrib/gperf/src/bool-array.h:27:1: unterminated #ifndef *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/gnu/usr.bin/gperf. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-06-01 20:15:40 - /usr/bin/make returned exit code 1 TB --- 2003-06-01 20:15:40 - ERROR: failed to build world TB --- 2003-06-01 20:15:40 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-06-01 20:15:41 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-01 20:15:41 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-01 20:18:17 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools [...] error before `:' token In file included from /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gperf/src/bool-array.h:59, from /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gperf/src/bool-array.cc:21: /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gperf/src/options.h:150:1: unterminated #ifdef /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gperf/src/options.h:32:1: unterminated #ifndef In file included from /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gperf/src/bool-array.cc:21: /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gperf/src/bool-array.h:55:1: unterminated #ifdef /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/contrib/gperf/src/bool-array.h:27:1: unterminated #ifndef *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/gnu/usr.bin/gperf. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-01 20:18:25 - /usr/bin/make returned exit code 1 TB --- 2003-06-01 20:18:25 - ERROR: failed to build world TB --- 2003-06-01 20:18:25 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
Petri Helenius wrote: RAIDframe is non-functional in 5.1 and -current [kern/50541] and it would be unwise to use it in 5.0 for anything other than experimentation. Hopefully it will be fixed before 5.2. Makes one wonder how broken code ever got into the tree in the first place... Pete Just settle down a bit. If you rewind to last October, RAIDFrame worked well. Unfortunately, some kernel interfaces changed in between now and then and RAIDFrame was left behind. I am remis in not fixing it, but please understand that I also have quite a few other responsibilities, and I get paid $0 to work on RAIDframe. As for hardware raid, what cards have you tried, and what problems have you experienced? You last message was jsut a shot in the dark that few of us would be able to help with. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Native JDK with libthr/libkse
On Sun, 1 Jun 2003, Sheldon Hearn wrote: On (2003/06/01 00:50), Daniel Eischen wrote: I just built jdk13 a couple of days ago. No problem whatsoever. You guys must have rotten karma or something. Did you already have a native JDK installed? I built the native 1.4.1 JDK two weeks ago, first without the native JDK for bootstrapping, and then with the native JDK. Both worked without a hitch. If you're having problems with the build, your input would be appreciated on freebsd-java. The absence of credible Java support in FreeBSD has lost us significant penetration in the past, and it would be disastrous if the perceptions of the past shaped the future. credible rather sounds like 'comes on the installation cd, doesn't have significantly more bugs than linux/solaris/xxx version' 8-( FreeBSD now has some seriously committed Java people working hard on the port, and it'd be a shame if they didn't get to hear about the problem you've encountered. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
installing kernel with securelevel set to 2
FreeBSD-current@ I just tried installing a kernel after compiling May 31st source and figured I would have to reboot to a lower securelevel, as I'm running with kern.securelevel set to 2. However, it slipped my mind and i've noticed it installed anyhow. Has this behavior changed? I thought that the kernel file (/boot/kernel/kernel) and its modules could not be replaced at that securelevel? Note: I'm currently running an April 6th -CURRENT. Also, all filesystems are UFS1, currently. As you can see, it installed kernel just fine for some reason. In the past, if the machine was running in secure mode it would stop at this point: [...] cd /usr/obj/usr/src/sys/TSERVER; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE=i686 GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy/usr/share/tmac PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/ legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/src/ i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/ games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel install thiskernel=`sysctl -n kern.bootfile` ; if [ $thiskernel = /boot/kernel.old/kernel ] ; then chflags -R noschg /boot/kernel ; rm -rf /boot/kernel ; else if [ -d /boot/kernel.old ] ; then chflags -R noschg /boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv /boot/kernel /boot/kernel.old ; if [ $thiskernel = /boot/kernel/kernel ] ; then sysctl kern.bootfile=/boot/kernel.old/kernel ; fi; fi kern.bootfile: /boot/kernel/kernel - /boot/kernel.old/kernel mkdir -p /boot/kernel install -p -m 555 -o root -g wheel kernel /boot/kernel cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/TSERVER/modules KMODDIR=/boot/kernel MACHINE=i386 make install [...] Looks like it was able to remove the immutable flag w/o a problem, which isn't supposed to be allowed at securelevel 1 or 2. From securelevel(8): 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem, and /dev/kmem may not be opened for writing; kernel modules (see kld(4)) may not be loaded or unloaded. 2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with file systems by unmounting them, but also inhibits running newfs(8) while the system is multi- user. Here's how I checked the securelevel: # sysctl kern.securelevel kern.securelevel: 2 # Also, checking the flags on /boot/kernel/kernel after the make -j2 kernelinstall there appears to be no flags set on the kernel file or any of its modules: # ls -lo /boot/kernel/kernel -r-xr-xr-x 1 root wheel - 3553557 Jun 1 16:24 /boot/kernel/kernel # Odd, no? Is there a new sysctl(8) directive that I'm missing? Maybe its a bug that's been fixed since Apr. 6th. Thanks, -rory ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Native JDK with libthr/libkse
On Sunday 01 June 2003 02:03, Christopher Johnson wrote: On Sat, 31 May 2003, Dag-Erling Smorgrav wrote: Daniel Eischen [EMAIL PROTECTED] writes: What are the above error messages? Sorry, I've never been able to build native java for FreeBSD. # cd /usr/ports/java/jdk13 # make install clean DES I disagree. I recently built jdk13 on Friday and it died on me, complaining about needing npapi.h. The build instructions did mention downloading the Sun SDK source and eyesbeyond patchset, but did not mention the Qt Netscape Plugin Extension. Okay, the problem here is (probably) that you have Qt 3.1.2 installed, which clobbers a couple of headers that it shouldn't, one of which is the npapi.h one. [EMAIL PROTECTED] is currently working on some patches to the qt31 port to fix this. In the meantime, your fix should be good enough -- Andy Fawcett | [EMAIL PROTECTED] | [EMAIL PROTECTED] In an open world without walls and fences, | [EMAIL PROTECTED] we wouldn't need Windows and Gates. -- anon | [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installing kernel with securelevel set to 2
I think I answered my own question. The kernel isn't installed with immutable flags to begin with -- So, my question is, why is this? I thought the advantage of making the kernel immutable was to better protect the system if root was compromised? I searched the archives regarding this, but found nothing that related to it. -rory From: Rory Arms [EMAIL PROTECTED] Date: Sun Jun 1, 2003 17:07:53 US/Eastern To: [EMAIL PROTECTED] Subject: installing kernel with securelevel set to 2 X-Mailer: Apple Mail (2.552) FreeBSD-current@ I just tried installing a kernel after compiling May 31st source and figured I would have to reboot to a lower securelevel, as I'm running with kern.securelevel set to 2. However, it slipped my mind and i've noticed it installed anyhow. Has this behavior changed? I thought that the kernel file (/boot/kernel/kernel) and its modules could not be replaced at that securelevel? Note: I'm currently running an April 6th -CURRENT. Also, all filesystems are UFS1, currently. As you can see, it installed kernel just fine for some reason. In the past, if the machine was running in secure mode it would stop at this point: [...] cd /usr/obj/usr/src/sys/TSERVER; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE=i686 GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy/usr/share/tmac PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/ legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/ src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/ usr/games:/sbin:/bin:/usr/sbin:/usr/bin make KERNEL=kernel install thiskernel=`sysctl -n kern.bootfile` ; if [ $thiskernel = /boot/kernel.old/kernel ] ; then chflags -R noschg /boot/kernel ; rm -rf /boot/kernel ; else if [ -d /boot/kernel.old ] ; then chflags -R noschg /boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv /boot/kernel /boot/kernel.old ; if [ $thiskernel = /boot/kernel/kernel ] ; then sysctl kern.bootfile=/boot/kernel.old/kernel ; fi; fi kern.bootfile: /boot/kernel/kernel - /boot/kernel.old/kernel mkdir -p /boot/kernel install -p -m 555 -o root -g wheel kernel /boot/kernel cd /usr/src/sys/modules; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/TSERVER/modules KMODDIR=/boot/kernel MACHINE=i386 make install [...] Looks like it was able to remove the immutable flag w/o a problem, which isn't supposed to be allowed at securelevel 1 or 2. From securelevel(8): 1 Secure mode - the system immutable and system append-only flags may not be turned off; disks for mounted file systems, /dev/mem, and /dev/kmem may not be opened for writing; kernel modules (see kld(4)) may not be loaded or unloaded. 2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. This level precludes tampering with file systems by unmounting them, but also inhibits running newfs(8) while the system is multi- user. Here's how I checked the securelevel: # sysctl kern.securelevel kern.securelevel: 2 # Also, checking the flags on /boot/kernel/kernel after the make -j2 kernelinstall there appears to be no flags set on the kernel file or any of its modules: # ls -lo /boot/kernel/kernel -r-xr-xr-x 1 root wheel - 3553557 Jun 1 16:24 /boot/kernel/kernel # Odd, no? Is there a new sysctl(8) directive that I'm missing? Maybe its a bug that's been fixed since Apr. 6th. Thanks, -rory ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ftp.freebsd.org
Just a quick note.. I noticed that packages-5-current directlry just got cleared out. (I guess a new set of packages is on the way). (bummer I was just upgrading a package from it :-) While it was almost empty I noticed that there is one file left dated May 8 in the All directory.. Whoever is responcible for that machine might like to rm it.. it's 7MB (called #cvs.cvsup-40860.3547). When it fills up again it'll be lost in the noise again.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gbde Performance - 35Mb/s vs 5.2 MB/s
Personally I think it would make more sense for gdbe init to pull the sectorsize from the fs for the user. But, I'm not volunteering to write the code. :) Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ftp.freebsd.org
too late.. you already got it :-) This brings up a question.. How do we find out who to contact for each mirror etc.? I notice cvsup14 has been unreachable for a month now.. On Sun, 1 Jun 2003, Julian Elischer wrote: Just a quick note.. I noticed that packages-5-current directlry just got cleared out. (I guess a new set of packages is on the way). (bummer I was just upgrading a package from it :-) While it was almost empty I noticed that there is one file left dated May 8 in the All directory.. Whoever is responcible for that machine might like to rm it.. it's 7MB (called #cvs.cvsup-40860.3547). When it fills up again it'll be lost in the noise again.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ftp.freebsd.org
On 2003.06.01 14:57:41 -0700, Julian Elischer wrote: This brings up a question.. How do we find out who to contact for each mirror etc.? In the handbook :) http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html or perhaps the hubs mailling list if contact information is out of date. I notice cvsup14 has been unreachable for a month now.. According to the handbook it should be adminitered by: cvsup14.FreeBSD.org (maintainer [EMAIL PROTECTED]), California -- Simon L. Nielsen pgp0.pgp Description: PGP signature
Re: Polishing touch
Hello, just in case re@ or a maintainer finds this worhtwhile : from my /etc/rc.conf : ifconfig_tap0=lladdr 00:90:27:3f:12:9f apm_enable=YES apmd_enable=YES This gives me in dmesg-a (today's CVS) : 1) Setting hostname: M. module_register: module if_tap already exists! Module if_tap failed to register: 17 can't re-use a leaf (if_tap_debug)! tap0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 ether 00:90:27:3f:12:9f bit I just compiled if_tap into my kernel, and I nowehere asked explicitly for kldloading if_tap (IIRC) here what is (probably) going on. when system starts up you have no tap0 interface. ifconfig(8) can not find tap0 interface and tries to kldload(8) if_tap(4) module. since you already have if_tap(4) compiled into the kernel you get these messages. now the thing about tap(4) (and tun(4)) interfaces is that they are *virtual*, i.e. in order to create interface one need to open corresponding character device first, i.e. /dev/tapX (or /dev/tunX). i'm not sure why do you need to ifconfig tap0 interface in system startup script. the application that *uses* tap0 interface is supposed to do that. thanks, max __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Polishing touch
module_register: module if_tap already exists! Module if_tap failed to register: 17 can't re-use a leaf (if_tap_debug)! tap0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 ether 00:90:27:3f:12:9f bit I just compiled if_tap into my kernel, and I nowehere asked explicitly for kldloading if_tap (IIRC) I don't exactly know why it tries to load if_tap when it is already present, but FreeBSD should not allow it to be double-linked into the kernel. I created a patch that (hopefully ;) disallows this. You can find it at : http://hobbes.bsd-dk.dk/~npp/kern_linker.patch I would appreciate if you have the time to test this to see if it aborts the loading correctly. I know it's not exactly the real fix but it should stop some panics. more or less : Setting hostname: M. linker_file_register_modules: Cannot load module if_tap.ko. linker_file_register_modules: Module if_tap is already loaded. linker_load_file: register_modules_failed linker_file_register_modules: Cannot load module if_tap.ko. linker_file_register_modules: Module if_tap is already loaded. linker_load_file: register_modules_failed tap0: flags=8802BROADCAST,SIMPLEX,MULTICAST mtu 1500 Could you also test if unloading the if_tap module panic's the system ? This should ofcourse be tested without my patch and preferably when a tap device is in use. no more panic. thanx, Arno ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems building today's world
I've just cvsupped the latest -CURRENT, and it dies on me in gnu/usr.bin/gperf/doc: === gnu/usr.bin/gperf/doc c++ -O -pipe -std=iso9899:1999 -I/usr/obj/src/FreeBSD/5-CURRENT-ZAPHOD/src/i386/legacy/usr/include -I/src/FreeBSD/5-CURRENT-ZAPHOD/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/FreeBSD/5-CURRENT-ZAPHOD/src/gnu/usr.bin/gperf -c /src/FreeBSD/5-CURRENT-ZAPHOD/src/contrib/gperf/src/bool-array.cc In file included from /src/FreeBSD/5-CURRENT-ZAPHOD/src/contrib/gperf/src/options.h:154, from /src/FreeBSD/5-CURRENT-ZAPHOD/src/contrib/gperf/src/bool-array.h:59, from /src/FreeBSD/5-CURRENT-ZAPHOD/src/contrib/gperf/src/bool-array.cc:21: /src/FreeBSD/5-CURRENT-ZAPHOD/src/contrib/gperf/src/options.icc:27: syntax error before `:' token In file included from /src/FreeBSD/5-CURRENT-ZAPHOD/src/contrib/gperf/src/bool-array.h:59, from /src/FreeBSD/5-CURRENT-ZAPHOD/src/contrib/gperf/src/bool-array.cc:21: /src/FreeBSD/5-CURRENT-ZAPHOD/src/contrib/gperf/src/options.h:150:1: unterminated #ifdef /src/FreeBSD/5-CURRENT-ZAPHOD/src/contrib/gperf/src/options.h:32:1: unterminated #ifndef In file included from /src/FreeBSD/5-CURRENT-ZAPHOD/src/contrib/gperf/src/bool-array.cc:21: /src/FreeBSD/5-CURRENT-ZAPHOD/src/contrib/gperf/src/bool-array.h:55:1: unterminated #ifdef /src/FreeBSD/5-CURRENT-ZAPHOD/src/contrib/gperf/src/bool-array.h:27:1: unterminated #ifndef *** Error code 1 Stop in /src/FreeBSD/5-CURRENT-ZAPHOD/src/gnu/usr.bin/gperf. *** Error code 1 Stop in /src/FreeBSD/5-CURRENT-ZAPHOD/src. *** Error code 1 Stop in /src/FreeBSD/5-CURRENT-ZAPHOD/src. *** Error code 1 Stop in /src/FreeBSD/5-CURRENT-ZAPHOD/src. The funny thing is that there's nothing obviously wrong with the source files. I suspect c++, which dates from: -r-xr-xr-x 3 root wheel 78708 May 22 17:38 /usr/bin/c++ Is there something I should be doing first? Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
VFS: C99 sparse format for struct vfsops
Gang, My fingers have been itching to do this since the day phk@ planted this idea in my brain (re: cdevsw initialisations). Basically, it changes the vfsops to use C99 sparse format, just like cdevsw. It removes a lot of junk default initialisations, and duplication. Just like phk@ said in his mail for cdevsw; likewise, we wil be able to add new vfsops without having to hunt down each driver to match. Except this patch was not generated automatically. While there, I have also nuked all the prototypes for the vfsops, and replaced them with the typedefs, available in sys/mount.h, i.e. vfs_op_t. If this patch gets approved by some senior mac-daddies of FreeBSD, I can kindly ask my mentor, DES, to commit this for me. 8-) The patch: http://people.FreeBSD.ORG/~hmp/patches/vfs-voodoo.patch My mentor, and some other developers on secret IRC channel have given this a cursory glance. I am composing my email from a kernel running with this patch -- no rabbits, or hard disks were harmed in the making of this patch. Cheers. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems building today's world
On Monday, 2 June 2003 at 10:54:06 +0930, Greg 'groggy' Lehey wrote: I've just cvsupped the latest -CURRENT, and it dies on me in gnu/usr.bin/gperf/doc: *sigh* Yes, of course I saw the dialogue between DES and obrien, and the subsequent commit, so I re-supped and cvs updated and it still happened. But then, I should have updated the correct tree :-( Sorry for the noise Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
i386-P4 make world from 06.01.2003 source failed: (csu/i386-elf)ISO CB89 long long error
System: i386 P4 5.1-BETA2 (cvsup 06.01.2003.2114CDT) cd /usr/src cvsup standard-supfile make world . . . cc -O -pipe -mcpu=pentiumpro -elf -Wall -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -pedantic -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/lib/csu/i386-elf/crt1.c -o crt1.o cc1: warnings being treated as errors In file included from /usr/src/lib/csu/i386-elf/crt1.c:33: /usr/obj/usr/src/i386/usr/include/stdlib.h:134: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:135: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:140: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:148: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:151: warning: ISO C89 does not support `long long' *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on alpha/alpha
TB --- 2003-06-02 04:00:10 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-06-02 04:00:10 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-02 04:02:05 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries [...] /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include/stdlib.h:135: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include/stdlib.h:140: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include/stdlib.h:148: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include/stdlib.h:151: warning: ISO C89 does not support `long long' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/lib/csu/alpha. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-06-02 04:08:37 - /usr/bin/make returned exit code 1 TB --- 2003-06-02 04:08:37 - ERROR: failed to build world TB --- 2003-06-02 04:08:37 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on i386/i386
TB --- 2003-06-02 04:08:37 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-06-02 04:08:37 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-02 04:10:30 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4: building libraries [...] /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include/stdlib.h:135: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include/stdlib.h:140: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include/stdlib.h:148: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include/stdlib.h:151: warning: ISO C89 does not support `long long' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/lib/csu/i386-elf. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-06-02 04:17:15 - /usr/bin/make returned exit code 1 TB --- 2003-06-02 04:17:15 - ERROR: failed to build world TB --- 2003-06-02 04:17:15 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on i386/pc98
TB --- 2003-06-02 04:17:15 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-06-02 04:17:15 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-02 04:18:50 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4: building libraries [...] /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/stdlib.h:135: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/stdlib.h:140: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/stdlib.h:148: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/stdlib.h:151: warning: ISO C89 does not support `long long' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/lib/csu/i386-elf. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-06-02 04:25:19 - /usr/bin/make returned exit code 1 TB --- 2003-06-02 04:25:19 - ERROR: failed to build world TB --- 2003-06-02 04:25:19 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Remove absolute symlink in $MAKEOBJDIR
In usual buildworld, we have absolute symbolic links in $MAKEOBJDIR.
This causes built $MAKEOBJDIR can use to install the world on other
boxen only if same /usr/src (or etc.) location and same $MAKEOBJDIR.
I'm using this patch for months to avoid this situation.
(1) Copy man pages rather than absolute symlinks.
(2) Use correct dependency in sys/boot/i386/kgzldr.
I'll commit this if noone objects.
Index: bin/csh/Makefile
===
RCS file: /home/ncvs/src/bin/csh/Makefile,v
retrieving revision 1.30
diff -u -r1.30 Makefile
--- bin/csh/Makefile2 May 2003 06:39:13 - 1.30
+++ bin/csh/Makefile2 May 2003 15:01:02 -
@@ -73,7 +73,7 @@
.endfor
csh.1: tcsh.man
- ln -sf ${.ALLSRC} ${.TARGET}
+ cp ${.ALLSRC} ${.TARGET}
build-tools: gethost
Index: gnu/usr.bin/cc/cpp/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cpp/Makefile,v
retrieving revision 1.22
diff -u -r1.22 Makefile
--- gnu/usr.bin/cc/cpp/Makefile 5 Jun 2002 21:30:45 - 1.22
+++ gnu/usr.bin/cc/cpp/Makefile 23 Jan 2003 23:20:00 -
@@ -17,6 +17,6 @@
CLEANFILES= cpp.1
cpp.1: cccp.1
- ln -sf ${.ALLSRC} ${.TARGET}
+ cp ${.ALLSRC} ${.TARGET}
.include bsd.prog.mk
Index: gnu/usr.bin/cc/f77/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/f77/Makefile,v
retrieving revision 1.19
diff -u -r1.19 Makefile
--- gnu/usr.bin/cc/f77/Makefile 9 Jun 2002 00:03:56 - 1.19
+++ gnu/usr.bin/cc/f77/Makefile 23 Jan 2003 23:20:10 -
@@ -18,6 +18,6 @@
CLEANFILES= f77.1
f77.1: g77.1
- ln -sf ${.ALLSRC} ${.TARGET}
+ cp ${.ALLSRC} ${.TARGET}
.include bsd.prog.mk
Index: lib/libform/Makefile
===
RCS file: /home/ncvs/src/lib/libform/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- lib/libform/Makefile21 May 2002 07:08:30 - 1.7
+++ lib/libform/Makefile23 Jan 2003 13:45:48 -
@@ -45,7 +45,7 @@
CLEANFILES+=${page:T:S/x$//g}
MAN+=${page:T:S/x$//g}
${page:T:S/x$//g}: ${page}
- ln -s ${.ALLSRC} ${.TARGET}
+ cp ${.ALLSRC} ${.TARGET}
.endfor
MLINKS+=form_cursor.3 pos_form_cursor.3
Index: lib/libmenu/Makefile
===
RCS file: /home/ncvs/src/lib/libmenu/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- lib/libmenu/Makefile21 May 2002 07:08:30 - 1.9
+++ lib/libmenu/Makefile23 Jan 2003 13:46:03 -
@@ -42,7 +42,7 @@
CLEANFILES+=${page:T:S/x$//g}
MAN+=${page:T:S/x$//g}
${page:T:S/x$//g}: ${page}
- ln -s ${.ALLSRC} ${.TARGET}
+ cp ${.ALLSRC} ${.TARGET}
.endfor
MLINKS+=menu_attributes.3 menu_back.3 menu_attributes.3 menu_fore.3 \
Index: lib/libncurses/Makefile
===
RCS file: /home/ncvs/src/lib/libncurses/Makefile,v
retrieving revision 1.69
diff -u -r1.69 Makefile
--- lib/libncurses/Makefile 30 Apr 2003 15:49:40 - 1.69
+++ lib/libncurses/Makefile 1 May 2003 22:54:23 -
@@ -410,7 +410,7 @@
CLEANFILES+=${page:T:S/x$//g}
MAN+=${page:T:S/x$//g}
${page:T:S/x$//g}: ${page}
- ln -sf ${.ALLSRC} ${.TARGET}
+ cp ${.ALLSRC} ${.TARGET}
.endfor
MLINKS+=ncurses.3 curses.3
Index: lib/libpanel/Makefile
===
RCS file: /home/ncvs/src/lib/libpanel/Makefile,v
retrieving revision 1.8
diff -u -r1.8 Makefile
--- lib/libpanel/Makefile 21 May 2002 05:41:07 - 1.8
+++ lib/libpanel/Makefile 23 Jan 2003 13:46:33 -
@@ -32,7 +32,7 @@
CLEANFILES+= panel.3
MAN= panel.3
panel.3: panel.3x
- ln -s ${.ALLSRC} ${.TARGET}
+ cp ${.ALLSRC} ${.TARGET}
MLINKS+=panel.3 bottom_panel.3 panel.3 del_panel.3 panel.3 hide_panel.3 \
panel.3 move_panel.3 panel.3 new_panel.3 panel.3 panel_above.3 \
Index: sys/boot/i386/kgzldr/Makefile
===
RCS file: /home/ncvs/src/sys/boot/i386/kgzldr/Makefile,v
retrieving revision 1.12
diff -u -r1.12 Makefile
--- sys/boot/i386/kgzldr/Makefile 30 Sep 2002 20:37:57 - 1.12
+++ sys/boot/i386/kgzldr/Makefile 24 Jan 2003 07:01:52 -
@@ -1,8 +1,10 @@
# $FreeBSD: src/sys/boot/i386/kgzldr/Makefile,v 1.12 2002/09/30 20:37:57 peter Exp $
-FILES= kgzldr.o
+PROG= kgzldr.o
+NOMAN=
+STRIP=
+BINMODE=444
SRCS= start.s boot.c inflate.c lib.c crt.s sio.s
-OBJS= ${SRCS:N*.h:R:S/$/.o/g}
CFLAGS=-ffreestanding
CFLAGS+=-Os
CFLAGS+=-DKZIP
@@ -15,7 +17,9 @@
BOOT_COMCONSOLE_PORT?= 0x3f8
AFLAGS+=--defsym SIO_PRT=${BOOT_COMCONSOLE_PORT}
-kgzldr.o: ${OBJS}
- ${CC} ${LDFLAGS} -o ${.TARGET} ${OBJS}
+.if target(${PROG})
+CFLAGS=${LDFLAGS}
+LDADD=
+.endif
.include
[-CURRENT tinderbox] failure on ia64/ia64
TB --- 2003-06-02 04:25:20 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-06-02 04:25:20 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-02 04:26:47 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. [...] /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/stdlib.h:135: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/stdlib.h:140: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/stdlib.h:148: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/stdlib.h:151: warning: ISO C89 does not support `long long' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin/nfsiod. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sbin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-06-02 05:20:34 - /usr/bin/make returned exit code 1 TB --- 2003-06-02 05:20:34 - ERROR: failed to build world TB --- 2003-06-02 05:20:34 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Remove absolute symlink in $MAKEOBJDIR
On Mon, Jun 02, 2003 at 02:13:55PM +0900, Jun Kuriyama wrote:
Index: bin/csh/Makefile
===
RCS file: /home/ncvs/src/bin/csh/Makefile,v
retrieving revision 1.30
diff -u -r1.30 Makefile
--- bin/csh/Makefile 2 May 2003 06:39:13 - 1.30
+++ bin/csh/Makefile 2 May 2003 15:01:02 -
@@ -73,7 +73,7 @@
.endfor
csh.1: tcsh.man
- ln -sf ${.ALLSRC} ${.TARGET}
+ cp ${.ALLSRC} ${.TARGET}
build-tools: gethost
Please don't use cp(1). When source files are read-only, such as for
perforce trees, a buildworld -DNOCLEAN can fail because the copy in
the object directory will be read-only too. Use cat(1) or something
else that yields a copy that is writable.
Thanks,
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-06-02 05:20:34 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-02 05:20:34 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-02 05:22:27 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. [...] /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/stdlib.h:135: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/stdlib.h:140: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/stdlib.h:148: warning: ISO C89 does not support `long long' /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/stdlib.h:151: warning: ISO C89 does not support `long long' *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin/nfsiod. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sbin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-02 06:06:37 - /usr/bin/make returned exit code 1 TB --- 2003-06-02 06:06:37 - ERROR: failed to build world TB --- 2003-06-02 06:06:37 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Remove absolute symlink in $MAKEOBJDIR
On Mon, Jun 02, 2003 at 02:13:55PM +0900, Jun Kuriyama wrote: In usual buildworld, we have absolute symbolic links in $MAKEOBJDIR. This causes built $MAKEOBJDIR can use to install the world on other boxen only if same /usr/src (or etc.) location and same $MAKEOBJDIR. I'm using this patch for months to avoid this situation. (1) Copy man pages rather than absolute symlinks. I prefer the ln's over cp. Are you sure this is the only reason for the same $MAKEOBJDIR requirement? Also, typically one sets MAKEOBJDIRPREFIX, not MAKEOBJDIR. Are you sure you're using the right one for what you're wanting to do? -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Remove absolute symlink in $MAKEOBJDIR
At Sun, 1 Jun 2003 23:33:04 -0700,
David O'Brien wrote:
I prefer the ln's over cp. Are you sure this is the only reason for the
same $MAKEOBJDIR requirement? Also, typically one sets MAKEOBJDIRPREFIX,
not MAKEOBJDIR. Are you sure you're using the right one for what you're
wanting to do?
Actually, I'm using MAKEOBJDIRPREFIX. The only thing I want to do is,
o Nightly buildworld in /work/HEAD/src, /work/RELENG_5_0/src and
/work/RELENG_5_1/src with MAKEOBJDIRPREFIX=/work/${BRANCH}/obj.
o Use /work/${BRANCH}/{src,obj} for installing the world on the other
box.
But without this patch, I have symlinks like this:
% ls -l /work/RELENG_5_1/obj/work/RELENG_5_1/src/bin/csh/csh.1
lrwxr-xr-x 1 god god 56 Jun 2 05:40
/work/RELENG_5_1/obj/work/RELENG_5_1/src/bin/csh/csh.1 -
/work/RELENG_5_1/src/bin/csh/../../contrib/tcsh/tcsh.man
This causes problem when installing on the other box as mounting
/usr/src and /usr/obj.
I'll appreciate if you can teach me how to build absolute-path-free
objdir in another way...
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED] // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
malloc non-sleepablelocks held messages for nvidia.ko at boottime
I have no apparent problems using the NVIDIA_FreeBSD-1.0-3203 driver, but under 5.1-BETA I see the following messages, which I assume are informational only, but I don't really know what it is that they are trying to tell me: Jun 2 01:43:16 kern.info freebsd2 syslogd: kernel boot file is /boot/kernel/kernel malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc64a1b88) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 65536 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc64a1b88) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of DP fakepg with the following non-sleepablelocks held: exclusive sleep mutex ctl.mtx_api r = 0 (0xc084f4c8) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc64a1b88) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 4096 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc64a1b88) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc64a1b88) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 32768 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc64a1b88) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of DP fakepg with the following non-sleepablelocks held: exclusive sleep mutex ctl.mtx_api r = 0 (0xc084f4c8) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Pedantic and Werror together...
pedantic and Werror together cause problems again... I presume we really need the quad type here. (or is this one due to a compiler upgrade?) -- Pete --- === lib/csu/i386-elf rm -f .depend mkdep -f .depend -a-I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include/usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S mkdep -f .depend -a-I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include /usr/src/lib/csu/i386-elf/crt1.c cc -O -pipe -march=pentium3 -elf -Wall -I/usr/src/lib/csu/i386-elf/../common -I/usr/src/lib/csu/i386-elf/../../libc/include -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -pedantic -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /usr/src/lib/csu/i386-elf/crt1.c -o crt1.o cc1: warnings being treated as errors In file included from /usr/src/lib/csu/i386-elf/crt1.c:33: /usr/obj/usr/src/i386/usr/include/stdlib.h:134: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:135: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:140: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:143: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:145: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:148: warning: ISO C89 does not support `long long' /usr/obj/usr/src/i386/usr/include/stdlib.h:151: warning: ISO C89 does not support `long long' *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Sun, 01 Jun 2003 11:46:34 -0600
Scott Long [EMAIL PROTECTED] wrote:
I've mounted many MSDOS filesystems recently without problems. Do have
any other information about this? Did you verify that there were no
open vnodes on the filesystem?
Simply mounting, reading and umount the fs works:
---snip---
Monday, 02. June 2003, 09:15:01
{0} FreeBSD 5.1-BETA [Magelan:~]
(1) [EMAIL PROTECTED] # mount_msdosfs -l -u netchild /dev/ad1s1 /mnt
Monday, 02. June 2003, 09:15:56
{0} FreeBSD 5.1-BETA [Magelan:~]
(2) [EMAIL PROTECTED] # du -hd0 /mnt
22G/mnt
Monday, 02. June 2003, 09:16:26
{0} FreeBSD 5.1-BETA [Magelan:~]
(3) [EMAIL PROTECTED] # umount /mnt
---snip---
This is the problem case:
---snip---
Monday, 02. June 2003, 09:16:31
{0} FreeBSD 5.1-BETA [Magelan:~]
(4) [EMAIL PROTECTED] # mount_msdosfs -l -u netchild /dev/ad1s1 /mnt
Monday, 02. June 2003, 09:16:40
{0} FreeBSD 5.1-BETA [Magelan:~]
(5) [EMAIL PROTECTED] # cp ftpchroot-test.sh /mnt
Monday, 02. June 2003, 09:16:59
{0} FreeBSD 5.1-BETA [Magelan:~]
(6) [EMAIL PROTECTED] # cp /mnt/ftpchroot-test.sh /tmp/
Monday, 02. June 2003, 09:17:12
{0} FreeBSD 5.1-BETA [Magelan:~]
(7) [EMAIL PROTECTED] # umount /tmp
umount: unmount of /tmp failed: Device busy
Monday, 02. June 2003, 09:17:15
{1} FreeBSD 5.1-BETA [Magelan:~]
(8) [EMAIL PROTECTED] # sync;sync;sync
Monday, 02. June 2003, 09:17:22
{0} FreeBSD 5.1-BETA [Magelan:~]
(9) [EMAIL PROTECTED] # umount /tmp
umount: unmount of /tmp failed: Device busy
---snip---
The copied file has a size of 212 bytes.
Bye,
Alexander.
--
It's not a bug, it's tradition!
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
-snip-
Monday, 02. June 2003, 09:16:59
{0} FreeBSD 5.1-BETA [Magelan:~]
(6) [EMAIL PROTECTED] # cp /mnt/ftpchroot-test.sh /tmp/
Monday, 02. June 2003, 09:17:12
{0} FreeBSD 5.1-BETA [Magelan:~]
(7) [EMAIL PROTECTED] # umount /tmp
umount: unmount of /tmp failed: Device busy
Monday, 02. June 2003, 09:17:15
{1} FreeBSD 5.1-BETA [Magelan:~]
(8) [EMAIL PROTECTED] # sync;sync;sync
Monday, 02. June 2003, 09:17:22
{0} FreeBSD 5.1-BETA [Magelan:~]
(9) [EMAIL PROTECTED] # umount /tmp
umount: unmount of /tmp failed: Device busy
---snip---
Umm shouldn't you be trying to umount /mnt ?
--
Mark Sergeant [EMAIL PROTECTED]
SNSOnline Technical Services
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vm-related panic with 5.1RC1
Hi, This is exactly the panic I am seeing on my dual-processor box. My current suspicion is that it somehow relates to the same pcb_ext being freed twice. I do not need OpenOffice to trigger the bug, on SMP configuration it happens all the time. In the meantime the box did not panic anymore. Can you look and try if limiting maxmem makes anything different on the SMP box ? cat /boot/loader.conf hw.physmem=256M I think it's coincidence, but who knows ... Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
curses header conflict (wchar_t,wint_t)
When trying to install python2.3 on either stable or current the python curses module doesn't build. I get the following compiler complaints: STABLE (line numbers in brackets are from CURRENT) /usr/include/ncurses.h:236(289): conflicting types for `wchar_t' /usr/include/stdlib.h:58(57): previous declaration of `wchar_t' /usr/include/ncurses.h:239(292): conflicting types for `wint_t' /usr/include/wchar.h:89(96): previous declaration of `wint_t' Can somebody tell me the story of _WCHAR_T and _BSD_WCHAR_T, or tell me where I can find some hints? I found several long threads on seemingly related problems but haven't been enlightened yet. (One drastic fix is to remove the relevant lines from ncurses.h while building python.) - Till ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On 02 Jun 2003 17:38:28 +1000 Mark Sergeant [EMAIL PROTECTED] wrote: Umm shouldn't you be trying to umount /mnt ? I retested this and now used /mnt in the umount invocation... (blushI hope I'm awake now./blush). It umounts now successfully. I noticed some commits to the vfs layer between my last kernel and the actual one, either the bug is fixed now (I'm sure last time I had the problems I used /mnt in the umount invocation, not any other mounted FS), or the bug only get's triggered only in a specific situation I wasn't able to reproduce now. Bye, Alexander. -- The best things in life are free, but the expensive ones are still worth a look. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
So far I´ve tried asr and aac, both cards end up in kernel panics and/or array hang in a few minutes (multiple hardware platforms so I don´t think the motherboard is to blame) After the bad experience with asr I thought I give aac a try with somewhat similar results. And asr does not work with 4G machines anyway (although I don´t put that amount of memory in the servers now, I don´t want to generate a barrier because of a disk controller) Judging from the limited set of responses, Mylex stuff seems to work. My offer to help you to debug the aac code is still valid. You mean this one as shot in the dark? I got this when configuring an array on 5.1-BETA and aaccli: lock order reversal 1st 0xc2671134 AAC sync FIB lock (AAC sync FIB lock) @ /usr/src/sys/dev/aac/aac.c:1703 2nd 0xc03f5f20 Giant (Giant) @ vm/vm_fault.c:210 Stack backtrace: backtrace(c0397297,c03f5f20,c0393ecb,c0393ecb,c03a4e34) at backtrace+0x17 witness_lock(c03f5f20,8,c03a4e34,d2,d1d33ad8) at witness_lock+0x697 _mtx_lock_flags(c03f5f20,0,c03a4e2b,d2,2) at _mtx_lock_flags+0xb1 vm_fault(c03f1940,0,1,0,c267) at vm_fault+0x59 trap_pfault(d1d33c70,0,8,d1d33c40,8) at trap_pfault+0xef trap(18,c2670010,c2670010,d26402a4,c2671000) at trap+0x39d calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc24e5959, esp = 0xd1d33cb0, ebp = 0xd1d33ce0 --- aac_handle_aif(c2671000,d2640284,d1d33cfc,d1d33d00,7d0) at aac_handle_aif+0x139 aac_command_thread(c2671000,d1d33d48,c0392341,310,0) at aac_command_thread+0x179 fork_exit(c24e36c0,c2671000,d1d33d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd1d33d7c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc31f3959 stack pointer = 0x10:0xd1d39cb0 frame pointer = 0x10:0xd1d39ce0 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 = 550 (aac0aif) kernel: type 12 trap, code=0 Stopped at aac_handle_aif+0x139: cmpl0x8(%edx),%ecx db trace aac_handle_aif(c2679000,d2635284,d1d39cfc,d1d39d00,7d0) at aac_handle_aif+0x139 aac_command_thread(c2679000,d1d39d48,c0392341,310,c2670260) at aac_command_thread+0x179 fork_exit(c31f16c0,c2679000,d1d39d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd1d39d7c, ebp = 0 --- db Before that I got some message on GEOM not being properly locked but that scrolled off buffer before I could catch it. Pete - Original Message - From: Scott Long [EMAIL PROTECTED] To: Petri Helenius [EMAIL PROTECTED] Cc: Tim Robbins [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 01, 2003 11:20 PM Subject: Re: raidframe Petri Helenius wrote: RAIDframe is non-functional in 5.1 and -current [kern/50541] and it would be unwise to use it in 5.0 for anything other than experimentation. Hopefully it will be fixed before 5.2. Makes one wonder how broken code ever got into the tree in the first place... Pete Just settle down a bit. If you rewind to last October, RAIDFrame worked well. Unfortunately, some kernel interfaces changed in between now and then and RAIDFrame was left behind. I am remis in not fixing it, but please understand that I also have quite a few other responsibilities, and I get paid $0 to work on RAIDframe. As for hardware raid, what cards have you tried, and what problems have you experienced? You last message was jsut a shot in the dark that few of us would be able to help with. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
If you rewind to last October, RAIDFrame worked well. Unfortunately, some kernel interfaces changed in between now and then and RAIDFrame was left behind. I am remis in not fixing it, but please understand that I also have quite a few other responsibilities, and I get paid $0 to work on RAIDframe. Not being a native english speaker I probably didn´t understand that experimental equals broken. If that equation cannot be justified, then the release notes should have said has critical defects or broken, not just experimental. I appreciate the work you and everybody else puts in, it just does not make sense to have people go through the same hoops and hit the wall when that could be saved by a single line noting that that the wall exists. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
On 2003.06.02 11:18:34 +0300, Petri Helenius wrote: So far I´ve tried asr and aac, both cards end up in kernel panics and/or array hang in a few minutes (multiple hardware platforms so I don´t think the motherboard is to blame) I have an asr based RAID controller (Adaptec 2400A), though it is an IDE RAID controller, it uses the SCSI asr driver. My controller has worked very well with FreeBSD 5.x, and the server is currently running 5.1-BETA. The only thing that doesn't work, is the userland utilities to control / get status from the card, but that's not so important. -- Simon L. Nielsen pgp0.pgp Description: PGP signature
Re: Native JDK with libthr/libkse
On (2003/06/01 23:53), Narvi wrote: The absence of credible Java support in FreeBSD has lost us significant penetration in the past, and it would be disastrous if the perceptions of the past shaped the future. credible rather sounds like 'comes on the installation cd, doesn't have significantly more bugs than linux/solaris/xxx version' 8-( And I think we'll get there. I'm currently doing some Java development on a FreeBSD-CURRENT workstation using a native jdk14. It's good enough for testing components in a J2EE application server (JBoss), and performance is comparable to that seen on an equivalent Windows workstation. Would I use FreeBSD as a production J2EE server reliant on 1.4.1? No. But the time is coming, so don't write FreeBSD off just yet. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: malloc non-sleepablelocks held messages for nvidia.ko at boottime
Hello, almost the same here: FreeBSD jmmr.no-ip.com 5.1-BETA FreeBSD 5.1-BETA #16: Sat May 31 15:51:17 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/BSD5ROUTER i386 Interesting lines from dmesg: Preloaded elf module /boot/kernel/nvidia.ko at 0xc05cb1f4. ... nvidia0: RIVA TNT2 Ultra mem 0xe400-0xe5ff,0xe600-0xe6ff irq 11 at device 0.0 on pci1 ... lock order reversal 1st 0xc46e2534 vm object (vm object) @ vm/vm_object.c:512 2nd 0xc082f110 system map (system map) @ vm/vm_kern.c:325 Stack backtrace: malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc150dd88) locked @ /usr/ports/x11/nvi dia-driver/work/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 65536 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc150dd88) locked @ /usr/ports/x11/nvi dia-driver/work/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of DP fakepg with the following non-sleepablelocks held: exclusive sleep mutex ctl.mtx_api r = 0 (0xc05ae4c8) locked @ /usr/ports/x11/nvi dia-driver/work/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc150dd88) locked @ /usr/ports/x11/nvi dia-driver/work/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 4096 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc150dd88) locked @ /usr/ports/x11/nvi dia-driver/work/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc150dd88) locked @ /usr/ports/x11/nvi dia-driver/work/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 32768 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc150dd88) locked @ /usr/ports/x11/nvi dia-driver/work/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of DP fakepg with the following non-sleepablelocks held: exclusive sleep mutex ctl.mtx_api r = 0 (0xc05ae4c8) locked @ /usr/ports/x11/nvi dia-driver/work/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 On Mon, 2 Jun 2003 02:01:42 -0500 (CDT) [EMAIL PROTECTED] wrote: I have no apparent problems using the NVIDIA_FreeBSD-1.0-3203 driver, but under 5.1-BETA I see the following messages, which I assume are informational only, but I don't really know what it is that they are trying to tell me: Jun 2 01:43:16 kern.info freebsd2 syslogd: kernel boot file is /boot/kernel/kernel malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc64a1b88) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 65536 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc64a1b88) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of DP fakepg with the following non-sleepablelocks held: exclusive sleep mutex ctl.mtx_api r = 0 (0xc084f4c8) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc64a1b88) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 4096 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc64a1b88) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 32 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc64a1b88) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of 32768 with the following non-sleepablelocks held: exclusive sleep mutex dev.mtx_api r = 0 (0xc64a1b88) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 malloc() of DP fakepg with the following non-sleepablelocks held: exclusive sleep mutex ctl.mtx_api r = 0 (0xc084f4c8) locked @ /var/tmp/NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c:711 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Reboot America. pgp0.pgp Description: PGP signature
Re: Remove absolute symlink in $MAKEOBJDIR
On Mon, 2 Jun 2003, Jun Kuriyama wrote:
In usual buildworld, we have absolute symbolic links in $MAKEOBJDIR.
This causes built $MAKEOBJDIR can use to install the world on other
boxen only if same /usr/src (or etc.) location and same $MAKEOBJDIR.
I'm using this patch for months to avoid this situation.
(1) Copy man pages rather than absolute symlinks.
As marcel pointed out, there are technical reasons for not using cp.
Use cat.
(2) Use correct dependency in sys/boot/i386/kgzldr.
This is too hackish for me. Try using the same method as for lib/csu.
I think you nmainly care about make install building things. This is
from longstanding brokenness of installation of man pages which was
cloned to brokenness of installation of FILES.
Index: sys/boot/i386/kgzldr/Makefile
===
RCS file: /home/ncvs/src/sys/boot/i386/kgzldr/Makefile,v
retrieving revision 1.12
diff -u -r1.12 Makefile
--- sys/boot/i386/kgzldr/Makefile 30 Sep 2002 20:37:57 - 1.12
+++ sys/boot/i386/kgzldr/Makefile 24 Jan 2003 07:01:52 -
...
@@ -15,7 +17,9 @@
BOOT_COMCONSOLE_PORT?= 0x3f8
AFLAGS+=--defsym SIO_PRT=${BOOT_COMCONSOLE_PORT}
-kgzldr.o: ${OBJS}
- ${CC} ${LDFLAGS} -o ${.TARGET} ${OBJS}
+.if target(${PROG})
+CFLAGS= ${LDFLAGS}
+LDADD=
+.endif
.include bsd.prog.mk
Especially-hackish part :-).
Setting LDADD is not needed.
The boot Makefiles already have too many abuses of PROG for non-programs
and/or non-primary targets.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
Alexander Leidinger wrote: On Sun, 01 Jun 2003 11:46:34 -0600 Scott Long [EMAIL PROTECTED] wrote: I've mounted many MSDOS filesystems recently without problems. Do have any other information about this? Did you verify that there were no open vnodes on the filesystem? I just copied 13 GB from the msdosfs to an ufs slice and 8 GB from an ufs to the msdosfs slice. After that the system was idle for a while (several minutes, maybe 2 hours). Then I just did some 'ls' invocations to verify the copy procedure and tried to umount. I hadn't any program running with legitimate access to /mnt and I have no program running which accesses a random filesystem path, so no vnodes should have been open then. Alas, lsof (ports) would be a better way of checking if there are vnodes open or not. I think fstat does that too, but I'm too used to lsof. Also, what is the error message? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Spellng is overated anywy. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Native JDK with libthr/libkse
On Mon, 2 Jun 2003, Sheldon Hearn wrote: On (2003/06/01 23:53), Narvi wrote: The absence of credible Java support in FreeBSD has lost us significant penetration in the past, and it would be disastrous if the perceptions of the past shaped the future. credible rather sounds like 'comes on the installation cd, doesn't have significantly more bugs than linux/solaris/xxx version' 8-( And I think we'll get there. And I encourage the java developers to let us threads guys know what they're having problems with. It has been stated that jdk is not guaranteed to work with anything but libc_r, so contact us over at [EMAIL PROTECTED] We want to see a fast and stable jdk as much as anyone else does. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
On Mon, Jun 02, 2003 at 11:36:18AM +0300, Petri Helenius [EMAIL PROTECTED] wrote: left behind. I am remis in not fixing it, but please understand that I also have quite a few other responsibilities, and I get paid $0 to work on RAIDframe. Not being a native english speaker I probably didnt understand that experimental equals broken. If that equation cannot be justified, then the release notes should have said has critical defects or broken, not just experimental. I appreciate the work you and everybody else puts in, it just does not make sense to have people go through the same hoops and hit the wall when that could be saved by a single line noting that that the wall exists. FreeBSD 5.x series is slowly progressing, but is nowhere near to production quality. As the things are currently, you simply waste your time. This is only my opinion and I don't want to offend anyone. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
FreeBSD 5.x series is slowly progressing, but is nowhere near to production quality. As the things are currently, you simply waste your time. This is only my opinion and I don't want to offend anyone. IMO, software does not magically get better but it must be actively being used and problems reported and fixed in reasonable time. So if 5.x never gets users it never gets production quality. Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
MAXLOGNAME 17 ?
Hi, in my service I have one box linux runing openldap with five thousand accounts. Many servers linux do authentication in this box and everything is fine. We also use box freebsd 4, however without this feature because not works nss_ldap in this version. Well, whith the begin of the 5.1, a could see this working (thanks Vidrine). My problem is size of username, that can be bigger than seventeen caracteres. The define MAXLOGNAME in /usr/include/sys/param.h and UT_NAMESIZE in /usr/include/utmp.h show me this. I think that change this value can resolv. After one cvsup of current, my login and syslogd were compiled again but not works. Then I did one attach with gdb in login and I watched that mistake was in setlogin(username) in the child process. - May 30 18:51:57 ws-tor-0012 login: setlogin(procergs-carlos-louzada): Invalid argument - exiting - If this is true, I need recompile the kernel and libc (make world) with the new values? What can I do in this case? ps. About 5.1-beta2, my console is full of warnings: -- May 30 17:17:51 ws-tor-0012 kernel: Sleeping on stopevent with the following non-sleepa blelocks held: May 30 17:17:51 ws-tor-0012 kernel: exclusive sleep mutex sigacts r = 0 (0xc42c4aa8) lock ed @ /usr/src/sys/kern/subr_trap.c:248 May 30 17:17:51 ws-tor-0012 kernel: lock order reversal May 30 17:17:51 ws-tor-0012 kernel: 1st 0xc42c4aa8 sigacts (sigacts) @ /usr/src/sys/kern/ subr_trap.c:248 May 30 17:17:51 ws-tor-0012 kernel: 2nd 0xc4187608 process lock (process lock) @ /usr/src /sys/kern/kern_synch.c:312 May 30 17:17:51 ws-tor-0012 kernel: Stack backtrace: May 30 17:17:59 ws-tor-0012 kernel: Sleeping on stopevent with the following non-sleepa blelocks held: May 30 17:17:59 ws-tor-0012 kernel: exclusive sleep mutex sigacts r = 0 (0xc42d4aa8) lock ed @ /usr/src/sys/kern/subr_trap.c:248 -- -- milo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MAXLOGNAME 17 ?
On Mon, Jun 02, 2003 at 12:52:38AM -0300 I heard the voice of
milo, and lo! it spake thus:
I think that change this value can resolv. After one cvsup of current,
my login and syslogd were compiled again but not works. Then I did one
attach with gdb in login and I watched that mistake was in
setlogin(username) in the child process.
Yes, you can.
Just change the values, then do your buildworld/buildkernel etc. You may
also need to recompile some ports that mess with usernames. I used to do
this on 2.2.x to get 16-char usernames, and had to rebuild things like
sshd to handle it ('course, with ssh in base now, that's one less).
There were occasional weirdnesses (wtmp got screwy sometimes, never
tracked it down), but overall it worked fine.
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
