Re: OpenLDAP/nss_ldap/pam_ldap
On Wednesday 29 October 2003 00:42, you wrote: I just checked the FreeBSD site and do not see any release 5.2 It is not release yet :) Once i can hurl this obsticle, i think FreeBSD might be a viable solution for me. Well, let be it then... I'm running -CURRENT with dynamic root and it works great. Antoine ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1 - stl Kernel compile fails
David O'Brien wrote: On Tue, Oct 28, 2003 at 08:11:33AM +0100, Karl M. Joch wrote: i added a stallion easy i/o to a 5.1 box. compiling the kernel fails with a lot of errors in stallion.c. any chance that this gets corrected soon? Is this an ISA or PCI card? it is an easy i/o 8 PCI card. i have this and the isa card in a lot of servers with 4.x for multiple hylafax modems. i have one production box for testing purposes with 5.1 running very stable. but now it looks like that all the servers with stallion cards are bound to 4.x till one puts the stallions into the trash and buys other cards :-(. on the stallion site there are lot of drivers including bsdi, but none for freebsd. -- Best regards / Mit freundlichen Gruessen, Karl M. Joch http://www.freebsd.at - Das Power Betriebssystem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall's fdisk/disklabel should be improved
On Sun, Oct 26, 2003 at 06:58:52PM +0100, Ulrich Spoerlein wrote: First of all, the Partition Editor has the 'A' option to use all of the available HDD space. It creates a DOS-compatible slice (starting at sector 63 and ending on cylinder boundary). This is completely useless on servers and the help menu says that sysinstall will ask if it should create a DOS-compatible slice or not. However no such question is ever asked. It is NOT useless. Why do you think it is? Perhaps you don't relize that some BIOS's wont boot from a hard disk that isn't partitioned to agree with the specifications of the PeeCee. If you want to treat your PC as a Sun, don't -- buy a Sun, FreeBSD runs on that too. Ok, then the solution would be to drop to a shell and run fdisk by hand. However there is no fdisk/disklabel/newfs in that shell. Even 'ls' is not found. Running the LiveCD will give you a working fdisk/disklabel but the man-pages are not useable (manpath.config can't be found). You're going to a lot of trouble just to save %1 of the available disk space... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1 - stl Kernel compile fails
On Wed, Oct 29, 2003 at 08:11:53AM +0100, Karl M. Joch wrote: On Tue, Oct 28, 2003 at 08:11:33AM +0100, Karl M. Joch wrote: i added a stallion easy i/o to a 5.1 box. compiling the kernel fails with a lot of errors in stallion.c. any chance that this gets corrected soon? Is this an ISA or PCI card? it is an easy i/o 8 PCI card. i have this and the isa card in a lot of servers with 4.x for multiple hylafax modems. i have one production box for testing purposes with 5.1 running very stable. but now it looks like that all the servers with stallion cards are bound to 4.x till one puts the stallions into the trash and buys other cards :-(. on the stallion site there are lot of drivers including bsdi, but none for freebsd. Please email [EMAIL PROTECTED] Stallion, Inc. sent him several cards to fix the driver in newer versions of FreeBSD. In addition, you could offer one of your cards to a FreeBSD developer so someone else could also fix it. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Another ATAng failure.
It seems David Gilbert wrote: I have tried several times in recent days to burn DVDs with burncd, growisofs and cdrecord ... all of which worked before atang. Growisofs complains that it can't flush it's buffers. Burncd doesn't complain ... but the resulting disk is not mountable. I thought at one point that some DVD images were writable. I havn't cvsup'd several times since them. No images appear writable now ... so the problem appears to have gotten worse. Burning CDR and CDRW appears to work fine, however. |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO Hmm, normally I just dont react to these kind of it doesn't work mails, but sometimes we need to set things straight... Anyhow what exactly is it you try to do ? A short description of the commands you run and what error messages it gives is a required minimum. Then in this case where kernel/HW is involved a minimum of the output of dmesg, preferably from a verbose boot is needed as well. You dont contract in IT do yo ? ;) BTW I've made several DVD's over the last week or so, and it worked just dandy, so it does work could have been my answer if we weren't interested in getting things to work, and supply the needed info to get it there... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cp -Rp /a_dir/w_sub_dirs to gbde vnode on SmartMedia Card locks system
Donald Creel [EMAIL PROTECTED] écrivait (wrote) : This has been reproducible for the last few weeks. System will crash if I am strictly from ttyv(n) or using KDE3.x and drag and drop. I have no crashes but i see locks of gbde file systems (no more activity, system idle 100%, file systems unmountable) when copying large files on gbde fs over md. When i restart system, reattach and fsck the gbde fs, all latest modifications are lost (lot of files in lost+found). As this is my first try on gbde, i have not tested against a real disk partition, so maybe this is a md(4) problem. I was running -CURRENT from around 01 October, i have upgraded to yesterday -CURRENT and still the same problem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
On Tue, 28 Oct 2003, Terry Lambert wrote: TLHarti Brandt wrote: TL When applying %*d%d to the string 123 the first 'd' format matches TL the string 123 and the conversion yields the number 123. This is then TL thrown away because assignment is suppressed. The next format specified TL finds an EOF condition on the stream so this counts as an input error TL according to paragraph 9, last sentence of 7.19.6.2. TL TL According to to paragraph 18 (The fscanf function returns the value of TL the macro EOF if an input failure occurs before any conversion. Otherwise, TL the function returns the number of input items assigned, which can be TL fewer than provided for, or even zero, in the event of an early matching TL failure.) the function returns 0, because there was a succesful TL conversion but no assignment. TL TLParagraph 6 of: TL TL http://www.opengroup.org/onlinepubs/007904975/functions/sscanf.html TL TLImplies that the lack of characters in the string following the TLconversion, due to failure in assignment, should result in an TLInput failure. Note also that stdio.h defines EOF as -1. I fail to locate this paragraph. This interpretation would also imply that scanf() always needs to return -1 whenever it cannot match a format specifier. TL TLI think it can be interpreted either way, still. You miss the section about RETURN VALUE: EOF is return on a read error. This is not an input error. You should also read the very 1st paragraph. This clearly states, that ISO is the primary source of information and the ISO text is a lot cleaner. TL TL TL I just had a look at the v7 implementation. In this implementation a TL suppressed assignment is not counted as a match even if the TL match was successful. This explains the return of -1 if the first TL not-suppressed conversion failes. TL TL I think changing current behaviour would be a regression with regard to TL ISO-C (and Posix). TL TLI really hate the idea of conforming to Linux; if I wanted to TLrun Linux, I'd run Linux. TL TLOn the other hand, there's a lot to be said for least common TLdenominator, and it's not like Linux' great idea of updating TLthe select struct timeval here: pretty much everyone has the TLsame behaviour as Linux, which is to say, -1. TL TLI think with a suppressed assignment, it's simply not possible TLto distinguish an error return from an EOF return, which really TLmakes me tempted to say return -1. I think it makes no sense to classify sscanf(123, %*d%d, ... as an error, but sscanf(123, %d%d, ... not, does it? Also at least Solaris 9 return -1 but fails to set errno. Which is simply a bug. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Postfix locks 5.1-servers?
Hi, are anyone familiar with conditions where postfix may bring a 5.1-p10 server to a halt, making the server accept incoming ports (such as 22) but serve nothing, making getty(8) become non-respondent (pressing enter doesn't give any feedback) and making the server ignore ctrl-alt-del etc? I've got two boxes running FreeBSD 5.1-p10 and Postfix 2.0.10,1 and 2.0.13,1. They also have a java process (v1.3.1 and v1.4.1) running, but that one is an extremely tiny process that can only be accessed from one specific IP and when executing lives for a couple of milliseconds. Does this ring any bells with anyone? We've been at it for a while and not being able to figure it out. The boxes are quite different hardwareish, so I don't suspect that being the problem. Cheers Niklas Saers ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ULE top(1) times...
I thought the wizards who can do math would find this amusing: PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 11 root -160 0K12K RUN451:16 101.56% 101.56% idle 738 sean760 52836K 39620K select 16:46 0.78% 0.78% kopete 695 sean760 26008K 16116K select 8:43 0.78% 0.78% kdeinit 646 root760 62540K 53036K select 8:24 0.00% 0.00% XFree86 A ULE UP kernel compiled fresh tonight (2003-10-28). Not critical, but certainly interesting. -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Two crashes in CURRENT from October 7th, both mention Xint0x80_syscall()
Hello. I've experienced some crashes here with FreeBSD 5.1-CURRENT from October 7th. I tried yesterday to upgrade to a more recent CURRENT but it crashed (the 2nd. crash here). Both crashes stop at different places, but they both refer to Xint0x80_syscall - I don't know if this is relevant or not. I'm no kernel hacker / C programmer, so I'm not sure how to debug this. It would be great if someone could give me a clue. :) [EMAIL PROTECTED]:~ uname -a FreeBSD vimes.eivind 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Oct 7 11:54:50 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/VIMES i386 My kernel is GENERIC with just a few small changes (removed special debugging options, added options for IPFILTER): [EMAIL PROTECTED]:/usr/src/sys/i386/conf diff GENERIC VIMES 25c25 ident GENERIC --- ident VIMES 63,66c63,66 options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS options WITNESS #Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN#Don't run witness on spinlocks for speed --- #options INVARIANTS #Enable calls of extra sanity checking #options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS #Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN#Don't run witness on spinlocks for speed 272a273,279 # These options are a subset of the IPFILTER options. options IPFILTER#ipfilter support options IPFILTER_LOG#ipfilter logging options IPFILTER_DEFAULT_BLOCK #block all packets by default options PFIL_HOOKS [EMAIL PROTECTED]:/usr/src/sys/i386/conf Here is the first crash. This first part is manually written down from the output on the screen, the second part is some output from gdb. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc200 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0656611 stack pointer = 0x10:0xd0790bdc frame pointer = 0x10:0xd0790bec 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 = 87468 (make) kernel: type 12 trap, code=0 Stopped at sigtd+0x41:andl0(%eax,%edi,4),%ecx db show reg cs 0x8 ds 0x30010 es0x10 fs 0xf0018 ss0x10 eax 0xc200 ecx0x8 edx 0xc2d31d10 ebx0x8 esp 0xd0790bdc ebp 0xd0790bec esi 0 edi 0 eip 0xc0656611 sigtd+0x41 efl0x10286 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0x0ff0 dr5 0x400 dr6 0x0ff0 dr7 0x400 sigtd+0x41:andl0(%eax,%edi,4),%ecx db trace sigtd(c2e4d3c8,14,90,c2ea6b58,d0790cb8) at sigtd+0x41 psignal(c2e4d3c8,14,c2f03e88,0,c2f792a8) at psignal+0x47 exit1(c2ea85f0,0,c2ea6b58,c2ea85f0,bfbffad0) at exit1+0x12e3 sys_exit(c2ea85f0,d0790d10,4,c,1) at sys_exit+0x67 syscall(2f,2f,2f,bfbffad0,0) at syscall+0x2b0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x806424b, esp = 0xbfbffa8c, ebp = 0xbfbffaa8 --- db Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc200 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0656611 stack pointer = 0x10:0xd0790bdc frame pointer = 0x10:0xd0790bec 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 = 87468 (make) panic: from debugger Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc07f47a4 stack pointer = 0x10:0xd0790954 frame pointer = 0x10:0xd0790960 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= IOPL = 0 current process = 87468 (make) panic: from debugger Uptime: 14h17m57s Dumping 191 MB 16 32 48 64 80 96 112 128 144 160 176 --- Reading symbols from /boot/kernel/vinum.ko...done. Loaded symbols for /boot/kernel/vinum.ko #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc06529c0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc0652da8 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc0475ae2 in
Re: ULE top(1) times...
On Wed, 2003-10-29 at 17:45, Sean Chittenden wrote: A ULE UP kernel compiled fresh tonight (2003-10-28). Not critical, but certainly interesting. -sc Anybody running ULE + KSE on an SMP kernel without any problems? My symptoms are as such: - idle and total cpu usage never goes above 54% - system is extremely slow (compared to 4BSD) - I'll provide follow up timings. - jerky mouse in X (as reported by others), better but unlike others, it's constant. What info should I give to help in tracing this problem? -- Optimized, readable, on time; Pick any two. FreeBSD 5.1-CURRENT i386 6:07PM up 7:01, 4 users, load averages: 0.51, 0.31, 0.23 signature.asc Description: This is a digitally signed message part
Re: Postfix locks 5.1-servers?
Hi, are anyone familiar with conditions where postfix may bring a 5.1-p10 server to a halt, making the server accept incoming ports (such as 22) but serve nothing, making getty(8) become non-respondent (pressing enter doesn't give any feedback) and making the server ignore ctrl-alt-del etc? I've got two boxes running FreeBSD 5.1-p10 and Postfix 2.0.10,1 and 2.0.13,1. They also have a java process (v1.3.1 and v1.4.1) running, but that one is an extremely tiny process that can only be accessed from one specific IP and when executing lives for a couple of milliseconds. Does this ring any bells with anyone? We've been at it for a while and not being able to figure it out. The boxes are quite different hardwareish, so I don't suspect that being the problem. I cant recall any problems with postfix and 5.1-p10, but why dont you run the latest version of postfix? Try upgrading postfix to postfix-2.0.16,1. Maybe it will resolve your problem. -- Med vennlig hilsen / Best regards Christer Solskogen http://dtz.cjb.net - http://carebears.mine.nu Cheap, but not as cheap as your girlfriend! -Spider Jerusalem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1 - stl Kernel compile fails
David O'Brien wrote: On Wed, Oct 29, 2003 at 08:11:53AM +0100, Karl M. Joch wrote: On Tue, Oct 28, 2003 at 08:11:33AM +0100, Karl M. Joch wrote: i added a stallion easy i/o to a 5.1 box. compiling the kernel fails with a lot of errors in stallion.c. any chance that this gets corrected soon? Is this an ISA or PCI card? it is an easy i/o 8 PCI card. i have this and the isa card in a lot of servers with 4.x for multiple hylafax modems. i have one production box for testing purposes with 5.1 running very stable. but now it looks like that all the servers with stallion cards are bound to 4.x till one puts the stallions into the trash and buys other cards :-(. on the stallion site there are lot of drivers including bsdi, but none for freebsd. Please email [EMAIL PROTECTED] Stallion, Inc. sent him several cards to fix the driver in newer versions of FreeBSD. In addition, you could offer one of your cards to a FreeBSD developer so someone else could also fix it. many thanks for the tip. sending one of the cards from austria to USA wouldnt make sence. but i really would appreziate a solution to be able to update the servers in the future. for the 5.1 production box it looks like i have to go back to 4.x meanwhile because there are 6 lines needed in the next few days. everything else with 5.1 on this box looks really good and stable. -- Best regards / Mit freundlichen Gruessen, Karl M. Joch http://www.freebsd.at - Das Power Betriebssystem 4.6.2 pl7 output for stl driver Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.6.2-RELEASE-p17 #0: Wed Sep 3 14:31:15 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FLEISCHERSBG Timecounter i8254 frequency 1193182 Hz CPU: Pentium 4 (1716.95-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf12 Stepping = 2 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,b28,ACC real memory = 536805376 (524224K bytes) avail memory = 517550080 (505420K bytes) Preloaded elf kernel kernel at 0xc04a7000. md0: Malloc disk Using $PIR table, 11 entries at 0xc00fdeb0 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82845 Host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82845 PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib2: Intel 82801BA/BAM (ICH2) Hub to PCI bridge at device 30.0 on pci0 pci2: PCI bus on pcib2 pci2: VGA-compatible display device at 0.0 irq 5 stl0: EasyIO-PCI port 0x9400-0x947f,0x9000-0x907f irq 9 at device 2.0 on pci2 stl0: EasyIO-PCI (driver version 2.0.0) unit=0 nrpanels=1 nrports=8 stl0: driver is using old-style compatibility shims ahc0: Adaptec 19160B Ultra160 SCSI adapter port 0x9800-0x98ff mem 0xe920-0xe9200fff irq 11 at device 3.0 on pci2 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs rl0: RealTek 8139 10/100BaseTX port 0x9c00-0x9cff mem 0xe9201000-0xe92010ff irq 10 at device 4.0 on pci2 rl0: Ethernet address: 00:40:95:32:55:dd miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: RealTek 8139 10/100BaseTX port 0xa000-0xa0ff mem 0xe9202000-0xe92020ff irq 12 at device 5.0 on pci2 rl1: Ethernet address: 00:40:95:32:55:ed miibus1: MII bus on rl1 rlphy1: RealTek internal media interface on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: Intel 82801BA/BAM (ICH2) PCI to LPC bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 ATA100 controller port 0xf000-0xf00f at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: Intel 82801BA/BAM (ICH2) USB controller USB-A at 31.2 irq 11 pci0: unknown card (vendor=0x8086, dev=0x2443) at 31.3 irq 11 pci0: Intel 82801BA/BAM (ICH2) USB controller USB-B at 31.4 irq 12 eisa0: EISA bus on motherboard eisa0: unknown card [EMAIL PROTECTED] (0x1a00) at slot 9 orm0: Option ROM at iomem 0xc-0xc7fff on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 IPv6 packet filtering initialized,
Re: Forward: HEADS UP! Default value of ip6_v6only changed
On Tue, Oct 28, 2003 at 11:51:59PM +, Christian Weisgerber wrote: Hajimu UMEMOTO [EMAIL PROTECTED] wrote: Our default of net.inet6.ip6.v6only was off in 4.X, and was changed to on on 5.X to follow NetBSD's practice. This behavior on 5.X breaks RFC2553/3493, and the change was intentional from security consideration. But, NetBSD changed it off by default. OpenBSD's behavior is equivalent to v6only on, and OpenBSD doesn't even provide a knob. Note that the default choice has a major impact on 3rd party software (ports). If we ship with a default of v6only off, then people will not fix software to open two sockets. This in turn means that turning v6only on will break this software. I predict that a good many people will then consider the v6only option to be useless. I can second this. The first time I noticed this mistake in self written software was when I tested it on NetBSD, where the default was already to v6only while FreeBSD still had it off. -- 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]
Re: panic route.c:565
Sam Leffler wrote: Any chance you can get a stack trace the next time this happens? The LOR by itself is hard to go from... Hi Sam, i get a slightly different LOR. lock order reversal 1st 0xc2dd6c90 rtentry (rtentry) @ /space/src/sys/net/route.c:182 2nd 0xc2d4887c radix node head (radix node head) @ /space/src/sys/net/route.c:544 Stack backtrace: backtrace(c0681530,c2d4887c,c06870aa,c06870aa,c0687100) at backtrace+0x17 witness_lock(c2d4887c,8,c0687100,220,1) at witness_lock+0x672 _mtx_lock_flags(c2d4887c,0,c0687100,220,cf428938) at _mtx_lock_flags+0xba rtrequest1(1,cf428944,cf428998,0,c2eb9eb0) at rtrequest1+0x59 rtrequest(1,c2eb9eb0,c2eb9eb0,cf42899c,405) at rtrequest+0x4a in6_ifloop_request(1,c2eb9e00,0,c2eb9e00,40) at in6_ifloop_request+0x76 in6_ifaddloop(c2eb9e00,0,c2eb9e00,0,cf428cbc) at in6_ifaddloop+0x50 in6_ifinit(c2ce7408,c2eb9e00,cf428c64,1,c04e092b) at in6_ifinit+0x147 in6_update_ifa(c2ce7408,cf428c54,0,0,cf428af4) at in6_update_ifa+0x500 in6_control(c2ea2800,8078691a,cf428c54,c2ce7408,c2e0c130) at in6_control+0x731 ifioctl(c2ea2800,8078691a,cf428c54,c2e0c130,c2e9e7fc) at ifioctl+0x1c8 soo_ioctl(c2e02f68,8078691a,cf428c54,c2e06a00,c2e0c130) at soo_ioctl+0x19c ioctl(c2e0c130,cf428d10,c069ca3f,3ed,3) at ioctl+0x475 syscall(2f,2f,2f,8097785,8078691a) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (54), eip = 0x2828768f, esp = 0xbfbff4ec, ebp = 0xbfbff518 --- hth, flo ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld fails with with de_AT locale
On Wed, Oct 29, 2003 at 12:18:39AM +0100, Bernhard Valenti wrote: hi, a buildworld with a de_AT locale fails in src/lib/libedit, the file fcnl.h that gets created is broken. i found that problem in the mailing list(april this year), and wonder if this has still not been fixed? It already fixed in -current and -stable is not affected (due to obsoleted tr there). -- Andrey Chernov | http://ache.pp.ru/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snd_csa issues in -CURRENT
On Sat, 30 Aug 2003 18:45:49 +1000 matti k [EMAIL PROTECTED] wrote: On Fri, 29 Aug 2003 12:36:56 +0200 Eirik Oeverby [EMAIL PROTECTED] wrote: I might also point out that there are two distinct kinds of distortion happening: The click/pop/crackle kind of distortion, and one where a sound buffer is repeated over and over 5-10 times - as if the hardware has some kind of hickup. Again - this *only* happens in -CURRENT, not in -STABLE or in any other OS (tested OS/2, BeOS, Linux, winXX). Anyone? :) /Eirik I get the same pops/crackling but using a SB Live! I think it started happening when I switched from 4.x to 5.x The strange thing is that sound works fine after a reboot but some hours after that I get the noises. It only happens with music (mp3,ogg). I tried a sound card with a CS4630 chip and still got the same thing. Strange that it takes a while for the noises to appear. Anyway, I was fiddling with settings using XMMS to play mp3's and found changing either resolution from 16bit to 8bit or changing down sample from 1:1(44khz) to 1:2(22khz) fixes the problem. These settings are located under audio i/o plugins - input plugins - mpeg layer 1/2/3 player - configure - decoder. Also after using these settings (1:2(22khz)) for half an hour and then changing them back to defaults ... sound was good. I should add that running gkrellm (/ports/sysutils/gkrellm) _and_ having the cpu monitor enabled makes the noises much worse. Again, on my system this only occurs after several hours and of course if I reboot all is well. If nothing else at least I've found a way to avoid rebooting, I guess. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall's fdisk/disklabel should be improved
On 28 Oct 2003, David O'Brien wrote: It is NOT useless. Why do you think it is? Perhaps you don't relize that some BIOS's wont boot from a hard disk that isn't partitioned to agree with the specifications of the PeeCee. If you want to treat your PC as a Sun, don't -- buy a Sun, FreeBSD runs on that too. This is true. And while I disagree with some of the initial complaints, I do think that fdisk/disklabel in sysinstall need to be improved upon. They do not handle multi-terabyte disk arrays properly at all (unless something has changed since 5.1-RELEASE) and as array sizes increase, it seems like this would be an issue to address lest people think that FreeBSD is not geared toward middle range server duties, which it most obviously handles exceptionally well. :) Having said that, I had to reflect a few seconds myself to figure out how to actually tell fdisk to go into dangerously dedicated mode, but it wasn't entirely impossible. It just wasn't entirely intuitive (although at the moment I cannot imagine why it wouldn't have been!). It's been awhile since I used it admittedly. If you want truly user unfriendly, try using fdisk/disklabel post installation, which both DO handle large slice/partition sizes properly, and through which I finally realized my 1638492118Kb RAID-5 partition. :) -- Mark Nippere-contacts: Computing and Information Services [EMAIL PROTECTED] Texas AM Universityhttp://ops.tamu.edu/nipsy/ College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617 (979)575-3193 MSN: [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- GG/IT d- s++:+ a- C++$ UBL+++$ P---+++ L+++$ E--- W++ N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+ PGP++(+) t 5 X R tv b+++ DI+(++) D+ G e h r++ y+(**) --END GEEK CODE BLOCK-- ---begin random quote of the moment--- If the fool would persist in his folly he would become wise. -- one of the Proverbs of Hell from William Blake's _The Marraige of Heaven and Hell_, 1789-1790 end random quote of the moment ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Postfix locks 5.1-servers?
On 29 Oct 2003, Niklas Saers Mailinglistaccount wrote: are anyone familiar with conditions where postfix may bring a 5.1-p10 server to a halt, making the server accept incoming ports (such as 22) but serve nothing, making getty(8) become non-respondent (pressing enter doesn't give any feedback) and making the server ignore ctrl-alt-del etc? I've only been running 5.1-RELEASE-p10 for a couple of days now with postfix-2.0.14-20030812,1, but so far no lock ups. I'll certainly keep an eye out for it though! :) Maybe it's the Java process... ;) -- Mark Nippere-contacts: Computing and Information Services [EMAIL PROTECTED] Texas AM Universityhttp://ops.tamu.edu/nipsy/ College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617 (979)575-3193 MSN: [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- GG/IT d- s++:+ a- C++$ UBL+++$ P---+++ L+++$ E--- W++ N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+ PGP++(+) t 5 X R tv b+++ DI+(++) D+ G e h r++ y+(**) --END GEEK CODE BLOCK-- ---begin random quote of the moment--- In theory there is no difference between theory and practice. In practice there is. end random quote of the moment ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR in VM...
I don't know if this is a known problem, but... lock order reversal 1st 0xc25cb818 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1319 2nd 0xc0934b40 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pag er.c:1835 3rd 0xc1033534 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:876 Stack backtrace: backtrace(c08426b8,c1033534,c0855afd,c0855afd,c08569ab) at backtrace+0x17 witness_lock(c1033534,8,c08569ab,36c,c0902b80) at witness_lock+0x672 _mtx_lock_flags(c1033534,0,c08569ab,36c,1) at _mtx_lock_flags+0xba obj_alloc(c101f600,1000,c8f95a0f,101,0) at obj_alloc+0x3f slab_zalloc(c101f600,1,8,c08569ab,68c) at slab_zalloc+0xb7 uma_zone_slab(c101f600,1,c08569ab,68c,c101f6b0) at uma_zone_slab+0xe6 uma_zalloc_internal(c101f600,0,1,5c1,72b,c0904a88) at uma_zalloc_internal+0x3e uma_zalloc_arg(c101f600,0,1,72b,2) at uma_zalloc_arg+0x3b9 swp_pager_meta_build(c25cb818,4,0,2,0) at swp_pager_meta_build+0x1b4 swap_pager_putpages(c25cb818,c8f95bd0,1,0,c8f95b40) at swap_pager_putpages+0x32d vm_pageout_flush(c8f95bd0,1,0,eb,32f) at vm_pageout_flush+0x179 vm_pageout_clean(c1186d70,0,c08567c6,32a,0) at vm_pageout_clean+0x305 vm_pageout_scan(0,0,c08567c6,5a9,1f4) at vm_pageout_scan+0x67e vm_pageout(0,c8f95d48,c083d23c,314,0) at vm_pageout+0x31b fork_exit(c079b7f0,0,c8f95d48) at fork_exit+0xcf fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc8f95d7c, ebp = 0 --- ___ [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] Show stopper defects for 5.2-RELEASE ++ | Issue | Status| Responsible | Description | |+-++| | Panic when | || The panic reported in | | rebuilding | -- | -- | PR kern/58228 must be | | ata-raid | || fixed. | | arrays | ||| |+-++| || || The LOR reported in PR | | filedesc LOR | -- | -- | kern/55175 must be | || || fixed. | |+-++| || || Performing a crashdump | | ATAng | || on an ATA device can | | crashdump | In Progress | So/ren Schmidt | result in a corrupted | | causes disk| | Tor Egge | MBR record. Tor has a | | corruption | || possible patch for | || || this. | |+-++| || || ATAng driver looses| || || device interrupts in | | ATAng lost | || certain scenarios, | | interrupts | In Progress | So/ren Schmidt | leading to hangs and | || || poor performance. | || || Possibly related to| || || timing problems. | |+-++| || || Kris Kennaway reports | || || that Alpha packages| | pipe/VM| || builds are being | | corruption on | -- | -- | silently corrupted and | | Alpha | || suspects pipe and vm | || || issues. This must be | || || investigated and | || || resolved. | |+-++| || || Kris Kennaway reports | || || high instability of| || || 5-CURRENT on ia64 | || | Marcel | machines, such as the | | ia64 stability | In Progress | Moolenaar | pluto* machines. These | || || problems need to be| || || fixed in order to get | || || a successful package | || || build. | |+-++| || || Brian Feldman has | || || submitted patches to | || || improve the| || || consistency of the | | MAC Framework | || pathnames passed into | | devfs path | In progress | Robert Watson | the MAC Framework | | fixes | || devfs labeling entry | || || points. These patches | || || need to be thoroughly | || || reviewed and tested, | || || then merged. | |+-++| || ||
Re: 5.2-RELEASE TODO
On Wed, Oct 29, 2003 at 10:00:22AM -0500, Robert Watson wrote: This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: Desired features for 5.2-RELEASE ++ | Issue| Status | Responsible | Description | |+---++--| || || The PCM autdio | || || framework and device | || || drivers have been| || || locked and free of | || || Giant for quite a| | PCM locking and| || while, but LOR | | performance issues | --| -- | problems persist | || || along with reports | || || of poor audio| || || performance under| || || load. The locking| || || needs to be reviewed | || || and corrected. | |+---++--| I just want to notify that Mathew Kanner mat [at] cnd.mcgill.ca sends some sound LOR patches into the -current maillist. -- Rgdz,/\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
Test for scheduling buildworlds: cd /usr/src/usr.bin for i in obj depend all do MAKEOBJDIRPREFIX=/somewhere/obj time make -s -j16 $i done /tmp/zqz 21 (Run this with an empty /somewhere/obj. The all stage doesn't quite finish.) On an ABIT BP6 system with a 400MHz and a 366MHz CPU, with /usr (including /usr/src) nfs-mounted (with 100 Mbps ethernet and a reasonably fast server) and /somewhere/obj ufs1-mounted (on a fairly slow disk; no soft-updates), this gives the following times: SCHED_ULE-yesterday, with not so careful setup: 40.37 real 8.26 user 6.26 sys 278.90 real59.35 user41.32 sys 341.82 real 307.38 user69.01 sys SCHED_ULE-today, run immediately after booting: 41.51 real 7.97 user 6.42 sys 306.64 real59.66 user40.68 sys 346.48 real 305.54 user69.97 sys SCHED_4BSD-yesterday, with not so careful setup: [same as today except the depend step was 10 seconds slower (real)] SCHED_4BSD-today, run immediately after booting: 18.89 real 8.01 user 6.66 sys 128.17 real58.33 user43.61 sys 291.59 real 308.48 user72.33 sys SCHED_4BSD-yesterday, with a UP kernel (running on the 366 MHz CPU) with many local changes and not so careful setup: 17.39 real 8.28 user 5.49 sys 130.51 real60.97 user34.63 sys 390.68 real 310.78 user60.55 sys Summary: SCHED_ULE was more than twice as slow as SCHED_4BSD for the obj and depend stages. These stages have little parallelism. SCHED_ULE was only 19% slower for the all stage. ... I reran this with -current (sched_ule.c 1.68, etc.). Result: no significant change. However, with a UP kernel there was no significant difference between the times for SCHED_ULE and SCHED_4BSD. Test 5 for fair scheduling related to niceness: for i in -20 -16 -12 -8 -4 0 4 8 12 16 20 do nice -$i sh -c while :; do echo -n;done done time top -o cpu With SCHED_ULE, this now hangs the system, but it worked yesterday. Today it doesn't get as far as running top and it stops the nfs server responding. To unhang the system and see what the above does, run a shell at rtprio 0 and start top before the above, and use top to kill processes (I normally use killall sh to kill all the shells generated by tests 1-5, but killall doesn't work if it is on nfs when the nfs server is not responding). This shows problems much more clearly with UP kernels. It gives the nice -20 and -16 processes approx. 55% and 50% of the CPU, respectively (the total is significantly more than 100%), and it gives approx. 0% of the CPU to the other sh processes (perhaps exactly 0). It also apparently gives gives 0% of the CPU to some important nfs process (I couldn't see exactly which) so the nfs server stops responding. SCHED_4BSD errs in the opposite direction by giving too many cycles to highly niced processes so it is naturally immune to this problem. With SMP, SCHED_ULE lets many more processes run. The nfs server also sometimes stops reponding with only non-negatively niced processes (0 through 20 in the above), but it takes longer. The nfs server restarts if enough of the hog processes are killed. Apparently nfs has some critical process running at only user priority and nice 0 and even non-negatively niced processes are enough to prevent it it running. Top output with loops like the above shows many anomalies in PRI, TIME, WCPU and CPU, but no worse than the ones with SCHED_4BSD. PRI tends to stick at 139 (the max) with SCHED_ULE. With SCHED_4BSD, this indicates that the scheduler has entered an unfair scheduling region. I don't know how to interpret it for SCHED_ULE (at first I thought 139 was a dummy value). Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forward: HEADS UP! Default value of ip6_v6only changed
Christian Weisgerber wrote: If we ship with a default of v6only off, then people will not fix software to open two sockets. This in turn means that turning v6only on will break this software. I find the notion of making people fix their software to not rely on RFC-defined behaviour problematic. I'm actually glad to see NetBSD reversed their unfortunate decision regarding the default (and OpenBSD's stunt of not even providing a knob is very evil indeed). I understand that itojun would like to see this aspect of RFC2553 amended. I don't know what the prospects of this happening are on the IETF level. Not too bad, IMHO. The IETF really is the place for this decision to be made and the knob should reflect current standards. Flipping the default when a revised RFC is published would be the right thing to do. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: PGP signature
crash on 5.1 current (Re: FreeBSD 5.1-p10 reproducible crash with Apache2, Postfix locks 5.1-servers?)
Hi, i have similar problems described in see subject. Two differnet Servers: A) PIII 1 GHz Dual, Scsi, 1 GB RAM B) XEON 3.06 GHz Dual, Adaptec SCSI Raid, 4 GB RAM A runs fine, B crashes once a day between 12 and 24 hours uptime. B has Apache (2.0.47) with SSL, now i will log incoming https connections, maybe crashes are related to ssl. I tested several kernel configuration since about 4 weeks, no luck... When i stress the system with various tools local or remote, crashes are very rare or non existent. - NO SMP + SCHED_4BSD: results in one crashed apache (others runs fine and serve requests). Logins via console or ssh freeze after password / motd. No respone to ctrl-alt-del. - SMP + SCHED_ULE / SCHED_4BSD System freezed completely, no responds to ping, keyboard locked up. Any ideas or requests for more information? bye, Andy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Forward: HEADS UP! Default value of ip6_v6only changed
I wrote: I find the notion of making people fix their software to not rely on RFC-defined behaviour problematic. I'm actually glad to see NetBSD reversed their unfortunate decision regarding the default (and OpenBSD's stunt of not even providing a knob is very evil indeed). I understand that itojun would like to see this aspect of RFC2553 amended. I don't know what the prospects of this happening are on the IETF level. FWIW, I wonder if the publication of http://bulk.fefe.de/scalability/, especially the paragraph: OpenBSD also caused a lot of grief on the IPv6 front. The OpenBSD guys intentionally broke their IPv6 stack to not allow IPv4 connections to and from IPv6 sockets using the IPv4 mapped addresses that the IPv6 standard defines for thus purpose. I find this behaviour of pissing on internet standards despicable and unworthy of free operating systems. has inspired NetBSD's move. :-) -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: PGP signature
Re: lots of exclusive sleep mutex
On Sat, Oct 04, 2003 at 02:00:33AM +0800, Clive Lin wrote: Hi, I've seen lots of messages on rescent -CURRENT malloc() of 16 with the following non-sleepable locks held: exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @ /usr/src/sys/geom/geom_io.c:351 malloc() of 16 with the following non-sleepable locks held: exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @ /usr/src/sys/geom/geom_io.c:351 Many of above are still seen on the latest current. malloc() of 16 with the following non-sleepable locks held: exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @ /usr/src/sys/geom/geom_io.c:355 malloc() of 16 with the following non-sleepable locks held: exclusive sleep mutex g_xdown r = 0 (0xe044eca8) locked @ /usr/src/sys/geom/geom_io.c:355 Perhaps it's a ServeRAID specific glitch? dmesg|grep ips ips0: IBM ServeRAID Adapter mem 0xf000-0xf3ff irq 16 at device 1.0 on pci4 ips0: logical drives: 1 ipsd0: Logical Drive on ips0 GEOM: create disk ipsd0 dp=0xc6b25310 ipsd0: Logical Drive (69430MB) Regards, Clive ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems with sysinstall
On Wed, 29 Oct 2003, Sergey Matveychuk wrote: The first one: when I install -current on disk where WinXP on first slice, sysinstall brakes WinXP boot complete. I got 'Missing operation system' everytime. Even I've tried 'fixboot' and reinstall WinXP. Helps only 'dd if=/dev/zero of=/dev/ad0 count=100' and reinstall WinXP on clean disk. I don't know how WinXP's bootblocks are set up, but I have this setup on Win2k and it works as expected with boot0. It sounds like the active partition bit got misplaced, though. Blowing away the whole thing was a bit extreme. Missing operating system comes out of the DOS default bootblock, not the BIOS. When I've installed first -current on first slice and second -current on second slice I got booting only first one. I use grub and either I set root(hd1,0) or root(hd1,1) (yes, it's a second disk) and 'chainloader +1' and 'boot' I've got always first -current boot. Looks like problem with boot sector where hardcoded booting from first slice (?). Don't use chainloader with FreeBSD. Use 'kernel /boot/loader' instead. This is documented in the GRUB info doc. Again, I have set this exact system up with redhat on the first disk and it works perfectly. The second: when I've tried to save results from Fdisk or Label menu I've got the message: 'ERROR: Unable to write data to disk ad0!' Why? I can change slices and partitions only when I boot from CD-ROM. This is normal and for your protection. you can't edit the disk you're running off of. If you are running off of ad1, make sure 1) you're root when you run sysinstall and b) you aren't mounting any filesystems from ad0. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall's fdisk/disklabel should be improved
On Wed, 29 Oct 2003 08:12:17 -0600, Mark Nipper [EMAIL PROTECTED] said: initial complaints, I do think that fdisk/disklabel in sysinstall need to be improved upon. They do not handle multi-terabyte disk arrays properly at all You should probably use GPT on multi-terabyte disk arrays. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems with sysinstall
Doug White wrote: Missing operating system comes out of the DOS default bootblock, not the BIOS. Yes, I know. But I don't feel better then. Don't use chainloader with FreeBSD. Use 'kernel /boot/loader' instead. This is documented in the GRUB info doc. Again, I have set this exact system up with redhat on the first disk and it works perfectly. Grub do not supporting UFS2. So only way to boot -current is chainloader. This is normal and for your protection. you can't edit the disk you're running off of. If you are running off of ad1, make sure 1) you're root when you run sysinstall and b) you aren't mounting any filesystems from ad0. Well, I understand it for slices. But why I can't create new partition in exist slice and newfs it? It was OK in -stable. Sem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: page fault in propagate_priority
On 28-Oct-2003 Dan Nelson wrote:
In the last episode (Oct 28), John Baldwin said:
On 28-Oct-2003 Dan Nelson wrote:
I've gotten the following panic twice in the last few days. I'm
pretty sure truss has something to do with it, since I just started
trussing something when it paniced. No crashdumps unfortunately,
and the system locks up hard so I have to reset it.
The fault address is 0x24 so it looks like a null pointer
dereference of some sort. I've added asserts to propagate_priority
any place a pointer to a structure is dereferenced, so if it
happens again I should have the line number at least.
panic1 was on an Oct 15 kernel, panic2 was on an Oct 27 kernel.
It might help some if you could use gdb -k on your kernel.debug and
do 'l *propagate_priority+0x66' to see where it is dying.
Yes, definitely :)
(gdb) l *propagate_priority+0x66
0xc0575b36 is in propagate_priority (../../../kern/kern_mutex.c:178).
171m = td-td_blocked;
172MPASS(m != NULL);
173
174/*
175 * Check if the thread needs to be moved up on
176 * the blocked chain
177 */
178if (td == TAILQ_FIRST(m-mtx_blocked)) {
179continue;
180}
181
182td1 = TAILQ_PREV(td, threadqueue, td_lockq);
So I guess m was NULL here. If I had INVARIANTS enabled, it would have
paniced at line 172. Time to re-enable those kernel debug options :)
Well, mtx_blocked might be null. You don't happen to have ADAPTIVE_MUTEXES
on do you?
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Postfix locks 5.1-servers?
Usually if networking locks up like this, you should check the mbuf usage. It is possible for resource starvation to cause a situation where TCP connections are accepted, but can't be sent data. netstat -m If that doesn't work, I would recommend cvsup'ping one of the machines to -current. 5.1-p10 just has security fixes, not bug fixes. Tom On Wed, 29 Oct 2003, Niklas Saers Mailinglistaccount wrote: Hi, are anyone familiar with conditions where postfix may bring a 5.1-p10 server to a halt, making the server accept incoming ports (such as 22) but serve nothing, making getty(8) become non-respondent (pressing enter doesn't give any feedback) and making the server ignore ctrl-alt-del etc? I've got two boxes running FreeBSD 5.1-p10 and Postfix 2.0.10,1 and 2.0.13,1. They also have a java process (v1.3.1 and v1.4.1) running, but that one is an extremely tiny process that can only be accessed from one specific IP and when executing lives for a couple of milliseconds. Does this ring any bells with anyone? We've been at it for a while and not being able to figure it out. The boxes are quite different hardwareish, so I don't suspect that being the problem. Cheers Niklas Saers ___ [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: Sysinstall's fdisk/disklabel should be improved
On 29 Oct 2003, Garrett Wollman wrote: On Wed, 29 Oct 2003 08:12:17 -0600, Mark Nipper [EMAIL PROTECTED] said: initial complaints, I do think that fdisk/disklabel in sysinstall need to be improved upon. They do not handle multi-terabyte disk arrays properly at all You should probably use GPT on multi-terabyte disk arrays. At first, I didn't even know what you were saying. :) Then, I remember seeing something about this when I was having my problems, and upon refreshing my memory a second ago, I'm now on the same page! :) But, I don't know too much about the new partitioning scheme you mention (GUID Partition Table, right?), especially with regards to the normal PC BIOS actually recognizing it, etc. I assume you could just use the MBR and do whatever you want with the rest of the drive. Anyway, do you you know of any good links describing the reasons to use it and generally how to use it as well as compatibility issues? I see a few things on google about patches and the like, but know real thorough description of all of this, even just under FreeBSD. -- Mark Nippere-contacts: Computing and Information Services [EMAIL PROTECTED] Texas AM Universityhttp://ops.tamu.edu/nipsy/ College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617 (979)575-3193 MSN: [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- GG/IT d- s++:+ a- C++$ UBL+++$ P---+++ L+++$ E--- W++ N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+ PGP++(+) t 5 X R tv b+++ DI+(++) D+ G e h r++ y+(**) --END GEEK CODE BLOCK-- ---begin random quote of the moment--- Whose woods these are I think I know. His house is in the village though; He will not see me stopping here To watch his woods fill up with snow. My little horse must think it queer To stop without a farmhouse near Between the woods and frozen lake The darkest evening of the year. He gives his harness bells a shake To ask if there is some mistake. The only other sound's the sweep Of easy wind and downy flake. The woods are lovely, dark and deep. But I have promises to keep, And miles to go before I sleep, And miles to go before I sleep. -- Robert Frost, _New Hampshire: A Poem with Notes and Grace Notes_, 1923 end random quote of the moment ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
On Thu, 30 Oct 2003, Bruce Evans wrote: Test for scheduling buildworlds: cd /usr/src/usr.bin for i in obj depend all do MAKEOBJDIRPREFIX=/somewhere/obj time make -s -j16 $i done /tmp/zqz 21 (Run this with an empty /somewhere/obj. The all stage doesn't quite finish.) On an ABIT BP6 system with a 400MHz and a 366MHz CPU, with /usr (including /usr/src) nfs-mounted (with 100 Mbps ethernet and a reasonably fast server) and /somewhere/obj ufs1-mounted (on a fairly slow disk; no soft-updates), this gives the following times: SCHED_ULE-yesterday, with not so careful setup: 40.37 real 8.26 user 6.26 sys 278.90 real59.35 user41.32 sys 341.82 real 307.38 user69.01 sys SCHED_ULE-today, run immediately after booting: 41.51 real 7.97 user 6.42 sys 306.64 real59.66 user40.68 sys 346.48 real 305.54 user69.97 sys SCHED_4BSD-yesterday, with not so careful setup: [same as today except the depend step was 10 seconds slower (real)] SCHED_4BSD-today, run immediately after booting: 18.89 real 8.01 user 6.66 sys 128.17 real58.33 user43.61 sys 291.59 real 308.48 user72.33 sys SCHED_4BSD-yesterday, with a UP kernel (running on the 366 MHz CPU) with many local changes and not so careful setup: 17.39 real 8.28 user 5.49 sys 130.51 real60.97 user34.63 sys 390.68 real 310.78 user60.55 sys Summary: SCHED_ULE was more than twice as slow as SCHED_4BSD for the obj and depend stages. These stages have little parallelism. SCHED_ULE was only 19% slower for the all stage. ... I reran this with -current (sched_ule.c 1.68, etc.). Result: no significant change. However, with a UP kernel there was no significant difference between the times for SCHED_ULE and SCHED_4BSD. There was a significant difference on UP until last week. I'm working on SMP now. I have some patches but they aren't quite ready yet. Test 5 for fair scheduling related to niceness: for i in -20 -16 -12 -8 -4 0 4 8 12 16 20 do nice -$i sh -c while :; do echo -n;done done time top -o cpu With SCHED_ULE, this now hangs the system, but it worked yesterday. Today it doesn't get as far as running top and it stops the nfs server responding. To unhang the system and see what the above does, run a shell at rtprio 0 and start top before the above, and use top to kill processes (I normally use killall sh to kill all the shells generated by tests 1-5, but killall doesn't work if it is on nfs when the nfs server is not responding). This shows problems much more clearly with UP kernels. It gives the nice -20 and -16 processes approx. 55% and 50% of the CPU, respectively (the total is significantly more than 100%), and it gives approx. 0% of the CPU to the other sh processes (perhaps exactly 0). It also apparently gives gives 0% of the CPU to some important nfs process (I couldn't see exactly which) so the nfs server stops responding. SCHED_4BSD errs in the opposite direction by giving too many cycles to highly niced processes so it is naturally immune to this problem. With SMP, SCHED_ULE lets many more processes run. I seem to have broken something related to nice. I only tested interactivity and performance after my last round of changes. I have a standard test that I do that is similar to the one that you have posted here. I used it to gather results for my paper (http://www.chesapeake.net/~jroberson/ULE.pdf). There you can see what the intended nice curve is like. Oddly enough, I ran your test again on my laptop and I did not see 55% of the cpu going to nice -20. It was spread proportionally from -20 to 0 with postive nice values not receiving cpu time, as intended. It did not, however, let interactive processes proceed. This is certainly a bug and it sounds like there may be others which lead to the problems that you're having. The nfs server also sometimes stops reponding with only non-negatively niced processes (0 through 20 in the above), but it takes longer. The nfs server restarts if enough of the hog processes are killed. Apparently nfs has some critical process running at only user priority and nice 0 and even non-negatively niced processes are enough to prevent it it running. This shouldn't be the case, it sounds like my interactivity boost is somewhat broken. Top output with loops like the above shows many anomalies in PRI, TIME, WCPU and CPU, but no worse than the ones with SCHED_4BSD. PRI tends to stick at 139 (the max) with SCHED_ULE. With SCHED_4BSD, this indicates that the scheduler has entered an unfair scheduling region. I don't know how to interpret it for SCHED_ULE (at first I thought 139
Re: Postfix locks 5.1-servers?
Hi, i am using current. Similar problems *without* postfix. Login via ssh results in print motd, but nothing more. Login on local console results in nothing after pressing enter on username. Andy You (Tom) wrote: Usually if networking locks up like this, you should check the mbuf usage. It is possible for resource starvation to cause a situation where TCP connections are accepted, but can't be sent data. netstat -m If that doesn't work, I would recommend cvsup'ping one of the machines to -current. 5.1-p10 just has security fixes, not bug fixes. Tom On Wed, 29 Oct 2003, Niklas Saers Mailinglistaccount wrote: Hi, are anyone familiar with conditions where postfix may bring a 5.1-p10 server to a halt, making the server accept incoming ports (such as 22) but serve nothing, making getty(8) become non-respondent (pressing enter doesn't give any feedback) and making the server ignore ctrl-alt-del etc? I've got two boxes running FreeBSD 5.1-p10 and Postfix 2.0.10,1 and 2.0.13,1. They also have a java process (v1.3.1 and v1.4.1) running, but that one is an extremely tiny process that can only be accessed from one specific IP and when executing lives for a couple of milliseconds. Does this ring any bells with anyone? We've been at it for a while and not being able to figure it out. The boxes are quite different hardwareish, so I don't suspect that being the problem. Cheers Niklas Saers ___ [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] -- Andy Hilker -- mailto:[EMAIL PROTECTED] http://www.cryptobank.de -- PGP Key: https://ca.crypta.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems with sysinstall
Sergey Matveychuk [EMAIL PROTECTED] wrote: Don't use chainloader with FreeBSD. Use 'kernel /boot/loader' instead. This is documented in the GRUB info doc. Again, I have set this exact system up with redhat on the first disk and it works perfectly. Grub do not supporting UFS2. So only way to boot -current is chainloader. Boot -current using the Windows XP bootloader. Unfortunately, I don't know of a single site with correct/complete information, but here are two pages to get you started (BACKUP your Windows partition before using the information in the following): http://bsdatwork.com/sections.php?op=viewarticleartid=3 (Also read the OpenBSD section for additional WinXP info.) http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#NT-BOOTLOADER -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: page fault in propagate_priority
In the last episode (Oct 29), John Baldwin said:
On 28-Oct-2003 Dan Nelson wrote:
In the last episode (Oct 28), John Baldwin said:
On 28-Oct-2003 Dan Nelson wrote:
The fault address is 0x24 so it looks like a null pointer
dereference of some sort. I've added asserts to
propagate_priority any place a pointer to a structure is
dereferenced, so if it happens again I should have the line
number at least.
panic1 was on an Oct 15 kernel, panic2 was on an Oct 27 kernel.
It might help some if you could use gdb -k on your kernel.debug
and do 'l *propagate_priority+0x66' to see where it is dying.
Yes, definitely :)
(gdb) l *propagate_priority+0x66
0xc0575b36 is in propagate_priority (../../../kern/kern_mutex.c:178).
171m = td-td_blocked;
172MPASS(m != NULL);
173
174/*
175 * Check if the thread needs to be moved up on
176 * the blocked chain
177 */
178if (td == TAILQ_FIRST(m-mtx_blocked)) {
179continue;
180}
181
182td1 = TAILQ_PREV(td, threadqueue, td_lockq);
So I guess m was NULL here. If I had INVARIANTS enabled, it would have
paniced at line 172. Time to re-enable those kernel debug options :)
Well, mtx_blocked might be null. You don't happen to have ADAPTIVE_MUTEXES
on do you?
Nope, don't have that set. I still think m was null, since the fault
was at 0x24, and gdb says that mtx_blocked is 24 bytes into struct mtx.
If mtx_blocked were null, you'd get a fault on 0x0 (since tqh_first is
the first element of mtx_blocked):
(gdb) p ((struct mtx *)0)-mtx_blocked
$1 = (struct {...} *) 0x24
--
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Postfix locks 5.1-servers?
All the time or sometimes? An unresponsive local console means that the entire machine is blocked though, not just networking. I'm using 5-current right now, and obviously I'm able to type this e-mail. Tom On Wed, 29 Oct 2003, Andy Hilker wrote: Hi, i am using current. Similar problems *without* postfix. Login via ssh results in print motd, but nothing more. Login on local console results in nothing after pressing enter on username. Andy You (Tom) wrote: Usually if networking locks up like this, you should check the mbuf usage. It is possible for resource starvation to cause a situation where TCP connections are accepted, but can't be sent data. netstat -m If that doesn't work, I would recommend cvsup'ping one of the machines to -current. 5.1-p10 just has security fixes, not bug fixes. Tom On Wed, 29 Oct 2003, Niklas Saers Mailinglistaccount wrote: Hi, are anyone familiar with conditions where postfix may bring a 5.1-p10 server to a halt, making the server accept incoming ports (such as 22) but serve nothing, making getty(8) become non-respondent (pressing enter doesn't give any feedback) and making the server ignore ctrl-alt-del etc? I've got two boxes running FreeBSD 5.1-p10 and Postfix 2.0.10,1 and 2.0.13,1. They also have a java process (v1.3.1 and v1.4.1) running, but that one is an extremely tiny process that can only be accessed from one specific IP and when executing lives for a couple of milliseconds. Does this ring any bells with anyone? We've been at it for a while and not being able to figure it out. The boxes are quite different hardwareish, so I don't suspect that being the problem. Cheers Niklas Saers ___ [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] -- Andy Hilker-- mailto:[EMAIL PROTECTED] http://www.cryptobank.de -- PGP Key: https://ca.crypta.net ___ [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: Postfix locks 5.1-servers?
Hi Tom, not all the time, sorry about my bad english :) Sometimes, mostly once a day... see another mail to list from me, sent a few hours ago. This mail describes the problems more detailed. This night i will change RAM to see if it was faulty. But i do not think so. Andy You (Tom) wrote: All the time or sometimes? An unresponsive local console means that the entire machine is blocked though, not just networking. I'm using 5-current right now, and obviously I'm able to type this e-mail. Tom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: MPSAFE network drivers
I'm committing changes to mark various network drivers' interrupt handlers MPSAFE. To insure folks have a way to backout if they hit problems I've also added a tunable that lets you disable this w/o rebuilding your kernel. By default all network drivers that register an interrupt handler INTR_MPSAFE are setup to run their ISR w/o Giant. If you want to defeat this w/o changing the code you can set debug.mpsafenet=0 from the loader when booting and the MPSAFE bit will automatically be removed. I plan to use this to also control forthcoming changes for registering MPSAFE netisrs. The following drivers are marked MPSAFE: ath, em, ep, fxp, sn, wi, sis I've got changes coming for bge. Other drivers probably can be marked MPSAFE but I'm only doing it for those drivers that I can test. Sam ---BeginMessage--- sam 2003/10/29 10:29:50 PST FreeBSD src repository Modified files: sys/kern subr_bus.c Log: Add a temporary mechanism to disble INTR_MPSAFE from network interface drivers. This is prepatory to running more parts of the network system w/o Giant. Revision ChangesPath 1.135 +13 -0 src/sys/kern/subr_bus.c http://cvsweb.FreeBSD.org/src/sys/kern/subr_bus.c.diff?r1=1.134r2=1.135 ---End Message--- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
Doug White wrote: On Mon, 27 Oct 2003, David Schultz wrote: I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. okay, so the $65,000 question is: Does this make the Diablo JDKs work? :) I could test, should I just get those files from current, integrate with 5.1-p10 and recompile? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Wed, Oct 29, 2003 at 09:13:37PM +0100, John Angelmo wrote: Doug White wrote: On Mon, 27 Oct 2003, David Schultz wrote: I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. okay, so the $65,000 question is: Does this make the Diablo JDKs work? :) I could test, should I just get those files from current, integrate with 5.1-p10 and recompile? That should work. Kris pgp0.pgp Description: PGP signature
Re: sound LOR patches
On Tue, Oct 28, 2003 at 02:24:28PM -0500, Mathew Kanner wrote: Hello All, I tried to fix some LOR in -current and attached you will find some patches. I sent these to the -sound list but I didn't get a response. (Maybe I should mention that I'm also part of the -sound list). So now I don't know what's going in with sound and -current. Thanks very much for looking into this - it has been an outstanding issue for too long. Hopefully some of the people who have reported this can test your patches. Kris pgp0.pgp Description: PGP signature
Re: ethercons: ethernet console driver for 5-current
Robert Watson wrote: I had a fair amount of time over the last week running in disconnected operation, and realized I had too many cables under my desk, so I spent a bit of time exploring the FreeBSD console code. Robert, I just tried this out (version 0.4) and I like it!! Thanks for the great work. Couple of things I noticed, (sorry if you are aware of them), When logged on via miniterm the 'w' command doesn't show the ethercons user. 'Who' does. The output from top is a bit jumbled. I would definitely like to see this functionality added to the base system, once it is ready. Cheers, Cameron PS I tried logging into the same machine twice and the two miniterm's mirror each other! Not sure if that is intended but it is fun :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sound LOR patches
On Oct 29, Kris Kennaway wrote: On Tue, Oct 28, 2003 at 02:24:28PM -0500, Mathew Kanner wrote: Hello All, I tried to fix some LOR in -current and attached you will find some patches. I sent these to the -sound list but I didn't get a response. (Maybe I should mention that I'm also part of the -sound list). So now I don't know what's going in with sound and -current. Thanks very much for looking into this - it has been an outstanding issue for too long. Hopefully some of the people who have reported this can test your patches. Dark Schneider flag at libero.it has tested all but the cmi patch. (He reported the LOR the other day). I've tested the CMI patch. --Mat -- Applicants must also have extensive knowledge of UNIX, although they should have sufficiently good programming taste to not consider this an achievement. - MIT AI Lab job ad in the /Boston Globe/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Wed, 29 Oct 2003, Kris Kennaway wrote: On Wed, Oct 29, 2003 at 09:13:37PM +0100, John Angelmo wrote: Doug White wrote: On Mon, 27 Oct 2003, David Schultz wrote: I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. okay, so the $65,000 question is: Does this make the Diablo JDKs work? :) I could test, should I just get those files from current, integrate with 5.1-p10 and recompile? That should work. Kris I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. [junior] ~ cd /usr/local/diablo-jdk1.3.1/bin [junior] /usr/local/diablo-jdk1.3.1/bin sudo ./java Bus error (core dumped) [junior] /usr/local/diablo-jdk1.3.1/bin sudo gdb ../jre/bin/i386/green_threads/java -core=java.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 i386-undermydesk-freebsd... (no debugging symbols found)... Core was generated by `java'. Program terminated with signal 10, Bus error. Reading symbols from ../jre/lib/i386/green_threads/libhpi.so... (no debugging symbols found)...done. Loaded symbols for ../jre/lib/i386/green_threads/libhpi.so Reading symbols from /usr/lib/compat/libc.so.4... (no debugging symbols found)...done. Loaded symbols for /usr/lib/compat/libc.so.4 Reading symbols from /lib/libm.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.2 Reading symbols from /usr/lib/libc.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libc.so Reading symbols from ../jre/lib/i386/classic/libjvm.so... (no debugging symbols found)...done. Loaded symbols for ../jre/lib/i386/classic/libjvm.so Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)... done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 0x2810fe5c in .cerror () from /usr/lib/compat/libc.so.4 (gdb) bt #0 0x2810fe5c in .cerror () from /usr/lib/compat/libc.so.4 #1 0x28088a51 in open () from ../jre/lib/i386/green_threads/libhpi.so #2 0x2810033c in __hash_open () from /usr/lib/compat/libc.so.4 #3 0x281001fb in dbopen () from /usr/lib/compat/libc.so.4 #4 0x280c3277 in ttyname () from /usr/lib/compat/libc.so.4 #5 0x280881f0 in initializeTTY () from ../jre/lib/i386/green_threads/libhpi.so #6 0x28088529 in InitializeAsyncIO () from ../jre/lib/i386/green_threads/libhpi.so #7 0x28091ca8 in sysThreadBootstrap () from ../jre/lib/i386/green_threads/libhpi.so #8 0x28295f07 in InitializeJavaVM () from ../jre/lib/i386/classic/libjvm.so #9 0x2826b3e4 in JNI_CreateJavaVM () from ../jre/lib/i386/classic/libjvm.so #10 0x08049c4a in InitializeJVM () #11 0x08048f5e in main () #12 0x08048b65 in _start () (gdb) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
Kris Kennaway wrote: On Wed, Oct 29, 2003 at 09:13:37PM +0100, John Angelmo wrote: Doug White wrote: On Mon, 27 Oct 2003, David Schultz wrote: I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. okay, so the $65,000 question is: Does this make the Diablo JDKs work? :) I could test, should I just get those files from current, integrate with 5.1-p10 and recompile? That should work. Kris I get this: cc -fpic -DPIC -O -pipe -march=pentium3 -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -c i387_s_tan.S -o i387_s_tan.So building shared library libm.so.2 e_scalb.So: In function `__ieee754_scalbf': e_scalb.So(.text+0x0): multiple definition of `__ieee754_scalbf' e_scalbf.So(.text+0x0): first defined here *** Error code 1 /John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __fpclassifyd problem
On Wed, Oct 29, 2003 at 03:28:32PM -0700, Scott Long wrote: I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. The binary is linked to: /usr/lib/libm.so.2 /usr/lib/compat/libc.so.4 (and others) (recall: the source of the libm problems was that libc.so.5 was *not* linked in). I'm not sure why gdb says otherwise - perhaps it's confused about the library paths. Perhaps there's some kind of ABI problem here that java is choking on. Kris pgp0.pgp Description: PGP signature
Re: __fpclassifyd problem
On Wed, 29 Oct 2003, Scott Long wrote: On Wed, 29 Oct 2003, Kris Kennaway wrote: On Wed, Oct 29, 2003 at 09:13:37PM +0100, John Angelmo wrote: Doug White wrote: On Mon, 27 Oct 2003, David Schultz wrote: I'm just catching up on -CURRENT, but I wanted to point out that this was fixed last night in: src/lib/msun/src/e_scalbf.c,v1.8 src/lib/msun/src/e_scalb.c,v1.10 The fix was to use the old versions of isnan() and isinf() specifically in the two places in libm where they are needed. okay, so the $65,000 question is: Does this make the Diablo JDKs work? :) I could test, should I just get those files from current, integrate with 5.1-p10 and recompile? That should work. Kris To respond to myself, I got ahold of a 4.8 libm.so and made sure that the linker used it. No change in the problem, and it still hints that the native libc is being linked in. Scott I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. [junior] ~ cd /usr/local/diablo-jdk1.3.1/bin [junior] /usr/local/diablo-jdk1.3.1/bin sudo ./java Bus error (core dumped) [junior] /usr/local/diablo-jdk1.3.1/bin sudo gdb ../jre/bin/i386/green_threads/java -core=java.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 i386-undermydesk-freebsd... (no debugging symbols found)... Core was generated by `java'. Program terminated with signal 10, Bus error. Reading symbols from ../jre/lib/i386/green_threads/libhpi.so... (no debugging symbols found)...done. Loaded symbols for ../jre/lib/i386/green_threads/libhpi.so Reading symbols from /usr/lib/compat/libc.so.4... (no debugging symbols found)...done. Loaded symbols for /usr/lib/compat/libc.so.4 Reading symbols from /lib/libm.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.2 Reading symbols from /usr/lib/libc.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libc.so Reading symbols from ../jre/lib/i386/classic/libjvm.so... (no debugging symbols found)...done. Loaded symbols for ../jre/lib/i386/classic/libjvm.so Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)... done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 0x2810fe5c in .cerror () from /usr/lib/compat/libc.so.4 (gdb) bt #0 0x2810fe5c in .cerror () from /usr/lib/compat/libc.so.4 #1 0x28088a51 in open () from ../jre/lib/i386/green_threads/libhpi.so #2 0x2810033c in __hash_open () from /usr/lib/compat/libc.so.4 #3 0x281001fb in dbopen () from /usr/lib/compat/libc.so.4 #4 0x280c3277 in ttyname () from /usr/lib/compat/libc.so.4 #5 0x280881f0 in initializeTTY () from ../jre/lib/i386/green_threads/libhpi.so #6 0x28088529 in InitializeAsyncIO () from ../jre/lib/i386/green_threads/libhpi.so #7 0x28091ca8 in sysThreadBootstrap () from ../jre/lib/i386/green_threads/libhpi.so #8 0x28295f07 in InitializeJavaVM () from ../jre/lib/i386/classic/libjvm.so #9 0x2826b3e4 in JNI_CreateJavaVM () from ../jre/lib/i386/classic/libjvm.so #10 0x08049c4a in InitializeJVM () #11 0x08048f5e in main () #12 0x08048b65 in _start () (gdb) ___ [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]
5.1-R and 5.1-C floppies will not boot on SuperMicro 6023P-8R
Hi, I'm trying to install 5.1-R or 5.1-C from floppies redirected output to serial port and it won't boot to the install screen. 4.9-R floppies with output redirected to serial port works and installs properly. This is what I get on my serial console when I try to boot on 5.1-C (similar to 5.1-R) seems to hang after the vga0 shows up during boot. Is there anything I can do or provide to resolve my install problem? Uncompressing ... done Console: serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 633kB/4061120kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED], Wed Oct 29 04:14:01 GMT 2003) include /boot/device.hints set hint.fdc.0.at=isa set hint.fdc.0.port=0x3F0 set hint.fdc.0.irq=6 set hint.fdc.0.drq=2 set hint.fd.0.at=fdc0 set hint.fd.0.drive=0 set hint.fd.1.at=fdc0 set hint.fd.1.drive=1 set hint.ata.0.at=isa set hint.ata.0.port=0x1F0 set hint.ata.0.irq=14 set hint.ata.1.at=isa set hint.ata.1.port=0x170 set hint.ata.1.irq=15 set hint.adv.0.at=isa set hint.adv.0.disabled=1 set hint.bt.0.at=isa set hint.bt.0.disabled=1 set hint.aha.0.at=isa set hint.aha.0.disabled=1 set hint.aic.0.at=isa set hint.aic.0.disabled=1 set hint.atkbdc.0.at=isa set hint.atkbdc.0.port=0x060 set hint.atkbd.0.at=atkbdc set hint.atkbd.0.irq=1 set hint.atkbd.0.flags=0x1 set hint.psm.0.at=atkbdc set hint.psm.0.irq=12 set hint.vga.0.at=isa set hint.sc.0.at=isa set hint.sc.0.flags=0x100 set hint.vt.0.at=isa set hint.vt.0.disabled=1 set hint.apm.0.disabled=1 set hint.apm.0.flags=0x20 set hint.pcic.0.at=isa set hint.pcic.0.port=0x3e0 set hint.pcic.0.maddr=0xd set hint.pcic.1.at=isa set hint.pcic.1.irq=11 set hint.pcic.1.port=0x3e2 set hint.pcic.1.maddr=0xd4000 set hint.pcic.1.disabled=1 set hint.sio.0.at=isa set hint.sio.0.port=0x3F8 set hint.sio.0.flags=0x10 set hint.sio.0.irq=4 set hint.sio.1.at=isa set hint.sio.1.port=0x2F8 set hint.sio.1.irq=3 set hint.sio.2.at=isa set hint.sio.2.disabled=1 set hint.sio.2.port=0x3E8 set hint.sio.2.irq=5 set hint.sio.3.at=isa set hint.sio.3.disabled=1 set hint.sio.3.port=0x2E8 set hint.sio.3.irq=9 set hint.ppc.0.at=isa set hint.ppc.0.irq=7 set hint.ed.0.at=isa set hint.ed.0.disabled=1 set hint.ed.0.port=0x280 set hint.ed.0.irq=10 set hint.ed.0.maddr=0xd8000 set hint.cs.0.at=isa set hint.cs.0.disabled=1 set hint.cs.0.port=0x300 set hint.sn.0.at=isa set hint.sn.0.disabled=1 set hint.sn.0.port=0x300 set hint.sn.0.irq=10 set hint.ie.0.at=isa set hint.ie.0.disabled=1 set hint.ie.0.port=0x300 set hint.ie.0.irq=10 set hint.ie.0.maddr=0xd set hint.fe.0.at=isa set hint.fe.0.disabled=1 set hint.fe.0.port=0x300 set hint.le.0.at=isa set hint.le.0.disabled=1 set hint.le.0.port=0x300 set hint.le.0.irq=5 set hint.le.0.maddr=0xd set hint.lnc.0.at=isa set hint.lnc.0.disabled=1 set hint.lnc.0.port=0x280 set hint.lnc.0.irq=10 set hint.lnc.0.drq=0 load /kernel /kernel text=0x23b500 data=0x2f024+0x4bedc / echo \007\007 echo Please insert MFS root floppy and press enter: Please insert MFS root floppy and press enter: read load -t mfs_root /mfsroot set hint.acpi.0.disabled=1 set driver_floppy=YES set module_path=/modules;/dist echo \007\007 autoboot 10 Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/kernel]... 131072K of memory above 4GB ignored Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT-20031029-JPSNAP #0: Wed Oct 29 04:30:49 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BOOTMFS Preloaded elf kernel /kernel at 0xc0af1000. Preloaded mfs_root /mfsroot at 0xc0af12c0. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf25 Stepping = 5 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Hyperthreading: 2 logical CPUs real memory = 4160225280 (3967 MB) avail memory = 4043710464 (3856 MB) Pentium Pro MTRR support enabled md0: Preloaded image /mfsroot 4423680 bytes at 0xc06b7400 npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 29 entries at 0xc00fddf0 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pci_cfgintr: 0:29 INTA BIOS irq 11 pci_cfgintr: 0:29 INTB BIOS irq 10 pci_cfgintr: 0:29 INTC BIOS irq 5 pci0: unknown at device 0.1 (no driver attached) pcib1: PCIBIOS PCI-PCI bridge at device 2.0 on pci0 pci1: PCI bus on pcib1 pci1: base peripheral, interrupt controller at device 28.0 (no driver attached) pcib2: PCIBIOS PCI-PCI bridge at device 29.0 on pci1 pci2: PCI bus on pcib2 pci1: base peripheral, interrupt controller at device 30.0 (no driver attached) pcib3
Re: 5.1-R and 5.1-C floppies will not boot on SuperMicro 6023P-8R
On Wed, Oct 29, 2003 at 04:07:27PM -0700, Stephane Raimbault wrote: Hi, I'm trying to install 5.1-R or 5.1-C from floppies redirected output to serial port and it won't boot to the install screen. 4.9-R floppies with output redirected to serial port works and installs properly. This is what I get on my serial console when I try to boot on 5.1-C (similar to 5.1-R) seems to hang after the vga0 shows up during boot. Is there anything I can do or provide to resolve my install problem? Don't you have to tell the kernel to use an alternate system console? Kris pgp0.pgp Description: PGP signature
Re: 5.1-R and 5.1-C floppies will not boot on SuperMicro 6023P-8R
I followed the instructions found in the handbook. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-advanced.html I've used this method for all my SuperMicro 6013P-8 servers some running 5.1-R and others 4.8-R Thanks, Stephane. - Original Message - From: Kris Kennaway [EMAIL PROTECTED] To: Stephane Raimbault [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 4:11 PM Subject: Re: 5.1-R and 5.1-C floppies will not boot on SuperMicro 6023P-8R ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-R and 5.1-C floppies will not boot on SuperMicro 6023P-8R
On Wed, Oct 29, 2003 at 04:15:00PM -0700, Stephane Raimbault wrote: I followed the instructions found in the handbook. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-advanced.html I've used this method for all my SuperMicro 6013P-8 servers some running 5.1-R and others 4.8-R I didn't see you do 'boot -h' in the log you posted. Kris pgp0.pgp Description: PGP signature
Lock up on boot with LS-120 and CURRENT
Hi, Using todays current, I'm finding that FreeBSD locks up completely on boot if I don't have a disk in my LS-120 drive. There is no panic, it just seems to freeze. I have included a dmesg from a boot with a disk in the drive and indicated the point at which it freezes without the disk in. It worked fine on 5.1-RELEASE. I have atapicam in the kernel. Any ideas as to what may be causing this? Mark Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #1: Wed Oct 29 17:10:51 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MARKS Preloaded elf kernel /boot/kernel/kernel at 0xc0ad7000. Preloaded elf module /boot/kernel/snd_emu10k1.ko at 0xc0ad721c. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0ad72cc. Preloaded elf module /boot/kernel/nvidia.ko at 0xc0ad7378. Preloaded elf module /boot/kernel/linux.ko at 0xc0ad7424. Preloaded elf module /boot/kernel/acpi.ko at 0xc0ad74d0. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (1002.28-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x642 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 402587648 (383 MB) avail memory = 381362176 (363 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: AMIINT VIA_K7 on motherboard pcibios: BIOS version 2.10 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 7 INTD is routed to irq 10 pcib0: slot 7 INTD is routed to irq 10 pcib0: slot 10 INTA is routed to irq 5 pcib0: slot 12 INTA is routed to irq 11 pcib0: slot 13 INTA is routed to irq 9 pcib0: slot 15 INTA is routed to irq 10 pcib0: slot 16 INTA is routed to irq 10 agp0: VIA 82C8363 (Apollo KT133A) host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib0: slot 1 INTA is routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 nvidia0: GeForce DDR mem 0xd000-0xd7ff,0xde00-0xdeff irq 11 at device 0.0 on pci1 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686A UDMA66 controller port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: VIA 83C572 USB controller port 0xb800-0xb81f irq 10 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1# uhub0: 2 ports with 2 removable, self powered ugen0: WINBOND W9967CF, rev 1.10/1.10, addr 2 uhci1: VIA 83C572 USB controller port 0xbc00-0xbc1f irq 10 at device 7.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ugen1: ALCATEL Speed Touch 330, rev 1.10/2.00, addr 2 ulpt0: Canon BJC-6200, rev 1.00/1.04, addr 3, iclass 7/1 ulpt0: using bi-directional mode pci0: serial bus, SMBus at device 7.4 (no driver attached) fxp0: Intel 82559 Pro/100 Ethernet port 0xc000-0xc03f mem 0xdfe0-0xdfef,0xdffcd000-0xdffcdfff irq 5 at device 10.0 on pci0 fxp0: Ethernet address 00:90:27:be:59:fc miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: Creative EMU10K1 port 0xc400-0xc41f irq 11 at device 12.0 on pci0 pcm0: TriTech TR28602 AC97 Codec pci0: network at device 13.0 (no driver attached) bktr0: BrookTree 848A mem 0xdd9ff000-0xdd9f irq 10 at device 15.0 on pci0 bktr0: Pinnacle/Miro TV, Temic PAL I tuner. atapci1: Promise PDC20265 UDMA100 controller port 0xc800-0xc83f,0xcc00-0xcc03,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 mem 0xdffe-0xdfff irq 10 at device 16.0 on pci0 atapci1: [MPSAFE] ata2: at 0xd800 on atapci1 ata2: [MPSAFE] ata3: at 0xd000 on atapci1 ata3: [MPSAFE] acpi_button1: Sleep Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: Parallel port bus on ppc0 plip0: PLIP network interface on ppbus0
Re: problems with sysinstall
On Wed, 29 Oct 2003, Sergey Matveychuk wrote: Doug White wrote: Missing operating system comes out of the DOS default bootblock, not the BIOS. Yes, I know. But I don't feel better then. It means you were barking up the wrong tree :) Don't use chainloader with FreeBSD. Use 'kernel /boot/loader' instead. This is documented in the GRUB info doc. Again, I have set this exact system up with redhat on the first disk and it works perfectly. Grub do not supporting UFS2. So only way to boot -current is chainloader. OK, I didn't test this. It works with UFS1 :) This is normal and for your protection. you can't edit the disk you're running off of. If you are running off of ad1, make sure 1) you're root when you run sysinstall and b) you aren't mounting any filesystems from ad0. Well, I understand it for slices. But why I can't create new partition in exist slice and newfs it? It was OK in -stable. yes, this is a change to -current. It is for your own safety. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Current
Hi There, Any time I try to install my 5.1 current version I have got this error: /usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found and I need install all again someone can help me please thanks -- Marcos Biscaysaqu Systems Administrator ThePacific.Net Ltd. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
java binary incompatibility on 5.x (Re: __fpclassifyd problem)
On Wed, Oct 29, 2003 at 03:28:32PM -0700, Scott Long wrote: I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. With help from peter and dwhite, we tracked down the cause to the following: ./jdk131.patches:+dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); ./jdk131.patches:+void *dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); Java people, this is the cause of the binary incompatibility of 4.x java binaries on 5.x. Can someone please fix? Kris pgp0.pgp Description: PGP signature
Re: Current
On Thu, Oct 30, 2003 at 02:53:44PM +1300, Marcos Biscaysaqu wrote: Hi There, Any time I try to install my 5.1 current version I have got this error: /usr/libexec/ld-elf.so.1: Shared object libc.so.5 not found and I need install all again someone can help me please It sounds like you've made a mistake in upgrading - perhaps you didn't follow the upgrade directions in the handbook? Kris pgp0.pgp Description: PGP signature
Re: Problem w/ ACPI in -CURRENT: Update
On Wed, 1 Oct 2003, Jeremy Bingham wrote: On 30/09/03 15:04 -0700, Nate Lawson wrote: As far as debugging prints, add the following printfs to acpi_cmbat_get_bif(): printf(Before getting BIF\n); as = AcpiEvaluateObject(h, _BIF, NULL, bif_buffer); printf(After getting BIF\n); The second one did not trigger (I had actually been using ACPI_VPRINT for a while to get info like that). I have a dump of my ASL here: http://home.satanosphere.com/bsd/jeremy.asl.gz. As far as my dmesg goes, I can get you one where it boots w/ ACPI disabled, but when it hangs, it hangs before / is mounted at all, so I can't really get it. Should I boot it again and just type the last lines out? I looked at a few other ASL copies I have and you have an old version. Have you done a BIOS update recently? Yours: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d0040b, Others: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d20b07, Others: OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d3050f, Update your BIOS and then do acpidump -t to verify your revision is the latest. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: java binary incompatibility on 5.x (Re: __fpclassifyd problem)
Kris Kennaway wrote: On Wed, Oct 29, 2003 at 03:28:32PM -0700, Scott Long wrote: I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. With help from peter and dwhite, we tracked down the cause to the following: ./jdk131.patches:+dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); ./jdk131.patches:+void *dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); Java people, this is the cause of the binary incompatibility of 4.x java binaries on 5.x. Can someone please fix? Kris Thanks for tracking this down. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: java binary incompatibility on 5.x (Re: __fpclassifyd problem)
On Wed, Oct 29, 2003 at 06:07:11PM -0800, Kris Kennaway wrote: On Wed, Oct 29, 2003 at 03:28:32PM -0700, Scott Long wrote: I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. With help from peter and dwhite, we tracked down the cause to the following: ./jdk131.patches:+dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); ./jdk131.patches:+void *dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); Java people, this is the cause of the binary incompatibility of 4.x java binaries on 5.x. Can someone please fix? I think its already fixed in CVS. I'll try and test it tomorrow. Does anyone know if ref5 has been updated to after the libm fix? I don't have a -CURRENT box at home to test on. -- Greg Lewis Email : [EMAIL PROTECTED] Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
SATA Patch on FreeBSD 4.9
dear all,
i wanna patch my kernel so that my freebsd support SATA
but, when i tried to download the patch, the patch wasn't completed
http://people.freebsd.org/~jhb/patches/sata.patch
+ return 0;
}
if (ch-flags ATA_DMA_ACTIVE) {
please, help me to get the patch
thanks
..::f::..
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: java binary incompatibility on 5.x (Re: __fpclassifyd problem)
On Wed, Oct 29, 2003 at 10:40:29PM -0700, Greg Lewis wrote: On Wed, Oct 29, 2003 at 06:07:11PM -0800, Kris Kennaway wrote: On Wed, Oct 29, 2003 at 03:28:32PM -0700, Scott Long wrote: I just tried running the Diablo JDK under -current from yesterday (with the libm fix from a few days ago). It does not look good; possibly an issue with both the compat libc and native libc being linked in? Maybe libm.so is still bringing in the native libc.so? We don't install the 4.x libm into compat, and I don't have any 4.x machine around to steal it from, so I can't test out that theory. With help from peter and dwhite, we tracked down the cause to the following: ./jdk131.patches:+dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); ./jdk131.patches:+void *dlMain = dlopen(/usr/lib/libc.so, RTLD_LAZY); Java people, this is the cause of the binary incompatibility of 4.x java binaries on 5.x. Can someone please fix? I think its already fixed in CVS. I'll try and test it tomorrow. Does anyone know if ref5 has been updated to after the libm fix? I don't have a -CURRENT box at home to test on. You should be able to roll your own libm and use LD_LIBRARY_PATH. Kris pgp0.pgp Description: PGP signature
Palm and USB: 5-CURRENT, 4-CURRENT, or 4.9-RELEASE?
I am trying to get my Palm Tungsten-E to sync with my FreeBSD 4.8-STABLE from October 23 (about a week ago). I seem not to be able to access /dev/ucom0 from pilot-xfer or jpilot, and the PPP workaround that others have suggested I can't seem to quite get working. I have heard rumors that the USB stack is fixed in newer versions such that I might be able to access the pilot directly -- can you tell me whether 4-CURRENT, 5-CURRENT, or 4.9-RELEASE might have the relevant fixes? Thank you for your help, - Jason Barnes ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.1-p10 reproducible crash with Apache2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. FreeBSD 5.1-p10 (and also possible other 5.1-pX version) can be remotely locked up if the following criteria is met: + apache2 has mod_ssl loaded and enabled + apache2 has the following configuration directives set to the following values: SSLMutex sem SSLSessionCache shm:/some/file(1048576) + client connects via SSL/TLS to apache fast enough. If all conditions above are satisfied except the last one, then lockup doesn't happen. I tested on three 5.1-p10 machines (SMP, uniprocessor, uniprocessor with hypterthreading) with JMeter 1.9.1. It is possible lockup machine with 100 requests (1 concurrent request) in 1-3 seconds. If SSLMutex is set to file:/path/somewhere and SSLSessionCache is set to dbm:/some/dbm lockup does not accour. Linux 2.4.22 is not affected by this issue. Details: apache: 2.0.47 php: 4.3.3 + turck mmcache 2.4.2 web application: horde imp webmail Best regards, Brane -BEGIN PGP SIGNATURE- iD8DBQE/n5iEfiC/E+t8hPcRAu9kAJ4lpD5CJf7HwYxphipHin0gUFaORACfV6ei Wxi5PvScjACrKmCxCEbt0l0= =UVfz -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.1-p10 reproducible crash with Apache2
On Wed, Oct 29, 2003 at 11:37:56AM +0100, Branko F. Gra?nar wrote: Hi. FreeBSD 5.1-p10 (and also possible other 5.1-pX version) can be remotely locked up if the following criteria is met: + apache2 has mod_ssl loaded and enabled + apache2 has the following configuration directives set to the following values: SSLMutex sem SSLSessionCache shm:/some/file(1048576) + client connects via SSL/TLS to apache fast enough. If all conditions above are satisfied except the last one, then lockup doesn't happen. I tested on three 5.1-p10 machines (SMP, uniprocessor, uniprocessor with hypterthreading) with JMeter 1.9.1. It is possible lockup machine with 100 requests (1 concurrent request) in 1-3 seconds. If SSLMutex is set to file:/path/somewhere and SSLSessionCache is set to dbm:/some/dbm lockup does not accour. Linux 2.4.22 is not affected by this issue. Details: What kernel configuration? What hardware? Kris pgp0.pgp Description: PGP signature
