Re: need some debugging help
On Fri, Aug 29, 2003 at 10:03:57PM -0600, Kenneth D. Merry wrote: +> I've been working on a set of patches to remove the sysctl variable creation +> from interrupt context in the cd(4) and da(4) drivers. +> +> To fix the problem, I've created a new taskqueue that runs in a thread +> context, instead of inside a software interrupt like the current task +> queues. (The eventual fix will involve moving the CAM probe inside a +> thread; this will provide a more temporary solution that will hopefully +> also work on -stable, until we can change the CAM probe code.) +> +> I think I have everything setup correctly, but I keep getting panics inside +> the GEOM code with these patches. (Memory modified after free.) I don't +> know whether I've just exposed some race condition, or whether I've done +> something wrong. +> +> I've seen several different panics, all with the same root cause (memory +> modified after free), and with two different previous memory pools -- geom +> and devbuf. I was getting same panics while I was working on GEOM Gate. After many hours of debugging I've tracked this down - I've initialized a mutex, but I haven't destroy it. As I susspect you're loading cd(4) as kld module? It seems, that you're making exactly same bug: mtx_init(&kthread_mutex, "taskqueue kthread", NULL, MTX_DEF); And where is mtx_destroy()? -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Filesystem problem
I also tried doing a umount now and it's hanging. Here's the ps: root 36373 0.0 0.0 580 352 d0 D+5:15PM 0:00.02 umount /mirror 0 31569 0 -4 0 ufs Now I also notice a zombie'd sh. Not sure where that came from. root 0 0.0 0.0 00 p2 ZW+ - 0:00.00 (sh)0 36046 0 -84 0 - - I'd also like to note that if I go into single user mode and fsck a couple times -- it works fine still in single user mode. If I go back into multi-- up pops the weasel. --- Kevin Bockman <[EMAIL PROTECTED]> wrote: > Thanks for the help. I'm positive that this is an > OS > problem as there are no hard errors reported on the > console. This problem just happened to start 10 > minutes after I rebooted and updated -STABLE on Aug > 10th. I was running -STABLE from April before I > believe for 4 months straight with no problems. > > Here I'm trying to do a make buildword: > > -- > >>> stage 2: rebuilding the object tree > -- > cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj > MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= > GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin > GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font > > GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy/usr/share/tmac > DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh > /usr/src/tools/install.sh" > PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin > make -f Makefile.inc1 par-obj > ===> share/info > ===> include > > As you see it is hanging at making the include dir. > > Here's the ps output: > > 0 31604 31597 3 8 0 512 372 wait I+ > p2 > 0:00.00 make buildworld > 0 31647 31604 3 8 0 896 628 wait I+ > p20:00.00 /bin/sh -ec cd /usr/src; > PATH=/sbin:/bin:/usr/sbin:/usr/bin `if [ -x > /usr/obj/usr/src/make.i386/make ]; then echo > /usr/obj/usr/src/make.i386/make; else echo make; fi` > > -m /usr/src/share/mk -f Makefile.inc1 buildworld > 0 31649 31647 43 8 0 752 620 wait I+ > p20:00.02 make -m /usr/src/share/mk -f > Makefile.inc1 buildworld >0 36046 36045 43 8 0 748 616 wait I+ > p2 >0:00.01 make -f Makefile.inc1 par-obj > 0 36055 36046 43 8 0 892 624 wait I+ > p20:00.00 /bin/sh -ec if test -d > /usr/src/include.i386; then echo "===> > include.i386"; > edir=include.i386; cd /usr/src/${edir}; else > echo > "===> include"; edir=include; cd /usr/src/${edir}; > > fi; make obj DIRPRFX=${edir}/ > 0 36056 36055 43 8 0 680 564 wait I+ > p20:00.02 make obj DIRPRFX=include/ > 0 36057 36056 43 8 0 892 624 wait I+ > p20:00.00 (sh) > 0 36058 36057 43 -11 0 200 96 chkiq2 D+ > p20:00.00 mkdir -p /usr/obj/usr/src/include > > Hope this helps. > > Thanks, > > Kevin > > --- Robert Watson <[EMAIL PROTECTED]> wrote: > > > > On Sun, 31 Aug 2003, Kevin Bockman wrote: > > > > > Anyone have any suggestions? I can not > control-C > > out of 'man vmstat'. > > > While doing 'make' in /usr/src/sys/boot it was > > hanging on as, when I > > > restarted it, it got to i386/libi386 and will > not > > do anything else. I'm > > > running that through serial console, it let me > ^C > > out of that. I tried > > > going into single user mode and running umount, > > now it just sits there > > > and I can't ^C. I have no ideas, this was all > > working yesterday!! :-) > > > > > > Any ideas on what else to check or other helpful > > hints would help > > > bunches. > > > > > > Sorry for the cross-posts. Just not sure where > to > > go with this one. > > > > Could you show the output of: > > > > ps axlwww > > > > when things are hanging? I'm particularly > > interested in the WCHAN entries > > for hung processes and kernel threads. That entry > > is the wait channel for > > kernel thread sleeps, which should give us some > > sense of what they're > > waiting for. If it's a UFS bug of some sort, > you'll > > likely see a lot of > > processes blocked in "inode" -- this could also > > happen in a hardware > > scenario, but should still be useful. In addition, > > do you have the entire > > serial console log output since boot? It would be > > interesting to know if > > you've had kernel log messages regarding your hard > > disk controller, etc. > > This might help distinguish a hardware problem > from > > a software problem. > > > > Robert N M Watson FreeBSD Core Team, > > TrustedBSD Projects > > [EMAIL PROTECTED] Network Associates > > Laboratories > > > > > > > > > > > > Thanks, > > > > > > Kevin > > > > > > > > > > > > ___
Re: need some debugging help
On Mon, Sep 01, 2003 at 02:13:45AM +0200, Pawel Jakub Dawidek wrote: +> I was getting same panics while I was working on GEOM Gate. +> After many hours of debugging I've tracked this down - I've initialized +> a mutex, but I haven't destroy it. +> +> As I susspect you're loading cd(4) as kld module? No, you don't need to load it as kld module, because you initiate this mutex on every function call (and mutex is locally allocated to), so try to put mtx_destroy() on the end of this function, this should help. (I hope there is no problem with calling msleep(9) with mutex from stack) -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Kernel fails to compile
Sources fetched an hour ago. Running make in /usr/src/sys/i386/compile/MYKERNEL : cc -c -O -pipe -march=i486 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../dev/pcic/i82365.c ../../../dev/pcic/i82365.c: In function `pcic_chip_do_mem_map': ../../../dev/pcic/i82365.c:850: error: structure has no member named `offset' ../../../dev/pcic/i82365.c:855: error: structure has no member named `offset' ../../../dev/pcic/i82365.c: In function `pcic_chip_mem_map': ../../../dev/pcic/i82365.c:928: error: structure has no member named `offset' *** Error code 1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel fails to compile
On Mon, 1 Sep 2003, Martin Jessa wrote: > Sources fetched an hour ago. > Running make in /usr/src/sys/i386/compile/MYKERNEL : Remove device pcic from your kernel config. My understanding is that it's broken anyway, so you're not losing anything by removing it. HTH, Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
threading problems
Hello gentlemen, I seem to have threading problems with 5.1-RELEASE. Every time I run a multithreaded application (linked against libc_r) on a SMP system, I get only 1 CPU loaded at any moment given. I tried different software, including Viewperf, but results remain the same. When linked against Linuxthreads, some applications work excellent, some segfault. Here is some kind of a simple multithreaded program for a 2-way SMP system that writes zeros to a memory array as fast as possible; it runs fine with Linuxthreads or directly under Linux. # gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -pthread # ./smp 4Gb per pass mode INTEGER | WRITING 8 Kb block: 1351 Mb/s res0: 674 res1: 677 # gcc -O2 -fomit-frame-pointer -march=i686 -o smp2 smp.c -L/usr/local/lib -llthread # ./smp2 4Gb per pass mode INTEGER | WRITING 8 Kb block: 2697 Mb/s res0: 1349 res1: 1348 --- Regards, Rhett Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ smp.c Description: smp.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Spurious "ACPI-1287 ... Method execution failed ..." messages
With a relatively current CURRENT on an MSI 875P-Neo (MS-6758) motherboard, I see the following spurious about "ACPI-1287..." messages, but this does not seem to affect the system boot or anything else. 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 #0: Wed Aug 20 20:36:05 CDT 2003 Preloaded elf kernel "/boot/kernel/kernel" at 0xc088f000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc088f244. Preloaded elf module "/boot/kernel/snd_emu10k1.ko" at 0xc088f2f0. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc088f3a0. Preloaded elf module "/boot/kernel/snd_ich.ko" at 0xc088f44c. Preloaded elf module "/boot/kernel/nvidia.ko" at 0xc088f4f8. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc088f5a4. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.20GHz (3207.28-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1073676288 (1023 MB) avail memory = 1033912320 (986 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f7680 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.MDET] (Node 0xc25b97c0), AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0._CRS] (Node 0xc25b96c0), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0._CRS] (Node 0xc25b96c0), AE_AML_REGION_LIMIT can't fetch resources for \\_SB_.PCI0 - AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.MDET] (Node 0xc25b97c0), AE_AML_REGION_LIMIT ACPI-1287: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (Node 0xc65a00c0), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\\_SB_.MEM_._CRS] (Node 0xc65a00c0), AE_AML_REGION_LIMIT can't fetch resources for \\_SB_.MEM_ - AE_AML_REGION_LIMIT acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 pcib0: on acpi0 pci0: on pcib0 IOAPIC #0 intpin 16 -> irq 2 IOAPIC #0 intpin 19 -> irq 5 IOAPIC #0 intpin 18 -> irq 10 IOAPIC #0 intpin 23 -> irq 11 IOAPIC #0 intpin 17 -> irq 16 agp0: mem 0xf000-0xf7ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 . . . vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec IP Filter: v3.4.31 initialized. Default = pass all, Logging = enabled acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% . . . SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da2s1a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel fails to compile
Hi. Great, now it compiles cleanly. Thanks Doug. > On Mon, 1 Sep 2003, Martin Jessa wrote: > >> Sources fetched an hour ago. >> Running make in /usr/src/sys/i386/compile/MYKERNEL : > > Remove device pcic from your kernel config. My understanding is that > it's broken anyway, so you're not losing anything by removing it. > > HTH, > > Doug ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: threading problems
On Mon, 1 Sep 2003 03:13:31 +0100 (BST) RMH <[EMAIL PROTECTED]> wrote: > # gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -pthread > # ./smp > 4Gb per pass mode > INTEGER | WRITING 8 Kb block: 1351 Mb/s > res0: 674 > res1: 677 > # gcc -O2 -fomit-frame-pointer -march=i686 -o smp2 smp.c -L/usr/local/lib > -llthread > # ./smp2 > 4Gb per pass mode > INTEGER | WRITING 8 Kb block: 2697 Mb/s > res0: 1349 > res1: 1348 Hum... with Linux Thread # gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -I/usr/local/include/pthread -L/usr/local/lib -llthread # ./smp 4Gb per pass mode INTEGER | WRITING 8 Kb block: 7613 Mb/s res0: 3808 res1: 3805 with libc_r (1:M thread model) # gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -lc_r # ./smp 4Gb per pass mode INTEGER | WRITING 8 Kb block: 3828 Mb/s res0: 1902 res1: 1926 with libthr (1:1 thread model) # gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -lthr # ./smp 4Gb per pass mode INTEGER | WRITING 8 Kb block: 7447 Mb/s res0: 3763 res1: 3684 with libkse (M:N thread model) # gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -lkse # ./smp 4Gb per pass mode INTEGER | WRITING 8 Kb block: 7592 Mb/s res0: 3789 res1: 3803 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone ported HCF/HSF modem drivers to FreeBSD?
On Monday 01 September 2003 08:41, Mark Kettenis wrote: >Date: Sun, 31 Aug 2003 15:02:36 -0700 (PDT) >From: Nate Lawson <[EMAIL PROTECTED]> > >I asked this on -hackers a little while ago but no response. I'm > curious if anyone has made an attempt to port these Winmodem drivers. >http://www.linuxant.com/drivers/ > > I did look into it, but concluded that it was pretty hopeless. For > starters, the DSP routines in there seem to need the FPU, and FreeBSD > doesn't seem to allow that in the kernel. Apart from that, almost I don't think that would be _that_ hard to fix at least for that specific driver, but I'm not 100% sure. > 100% of the code is in the binary-only modules, including a lot of > Linux-specific code, which makes it very hard to see how the code is > supposed to interface with the kernel. Have you seen these drivers -> http://www.smlink.com/main/index1.php?ln=en&main_id=32 It seems to support a lot of software modems, ie HAMR5600 based AMR/CNR/MDC/ACR modem cards on the following Southbridge chips: - Intel ICH0, ICH2 - Via 686A, 686B, 8231, 8233 - SiS 630 - ALI 1535. SmartPCI56, SmartPCI561, SmartPCI563 based PCI modem cards. SmartUSB56 based USB modem. And the binary code appears to only call shim routines for which the source is available. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: threading problems
In the last episode (Sep 01), RMH said: > Hello gentlemen, > > I seem to have threading problems with 5.1-RELEASE. Every time I run > a multithreaded application (linked against libc_r) on a SMP system, > I get only 1 CPU loaded at any moment given. I tried different Correct. libc_r is a userland threading library, which means that all threads run as a single plain process. Linuxthreads forks a new process for each thread. Try linking with -lkse or -lthr; both of these threading libraries allow multiple threads to run simultaneously on multiple CPUs. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
is there a "knob" for devfs rules?
Hi all, in debugging /dev/usb* and /dev/ugen* permissions problems so that I could access my digital camera as a mere-mortal user, I came across this posting to -questions: http://www.freebsd.org/cgi/getmsg.cgi?fetch=1203173+1206388+/usr/local/www/db/text/2003/freebsd-questions/20030622.freebsd-questions Indeed what Jesse posted worked like a charm: devfs ruleset 10 devfs rule add path 'ugen*' mode 664 Since the ugen* devices are "dynamic," putting entries in /etc/devfs.conf doesn't work unless you "restart" devfs once the camera is turned on. Thus, the rule above works nicely. He had asked in the mail where the "appropriate" place for these commands should be, but the thread ended there. So, I pose the question to this list. I didn't see anything in /etc/defaults/rc.conf regarding devfs. So, would the "appropriate" thing be to create a .sh file in /usr/local/etc/rc.d which contained the rule commands one would want and just have them be applied via this mechanism once it was very clear that devfs was up and running, etc.? Thanks, -Jr -- John & Jennifer Reynolds johnjen at reynoldsnet.orgwww.reynoldsnet.org Sr. Physical Design Engineer - WCCG/CCE PDE jreynold at sedona.ch.intel.com Running FreeBSD since 2.1.5-RELEASE. FreeBSD: The Power to Serve! "Unix is user friendly, it's just particular about the friends it chooses." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: ACPI problems with Compaq Evo N610c
I got interested in this recently because I inherited one of these laptops from work. On Wed, 30 Jul 2003, Cagle, John (ISS-Houston) wrote: > Which version of the N610C BIOS are you using? (F.14 is the latest on > the hp.com website.) I know that the _OSI("Windows 2001") bug will be > fixed in the F.15 release, but I don't think the _GL_ portion of your > patch will be included. Did you have to remove the Acquire & Release > of _GL_ in order to get xbat to work? (This is not a problem we see > with Linux ACPI in 2.4.21, so I think that FreeBSD's ACPI stack needs > updating.) I just updated to F.15, and it does indeed fix the windows bit in the output of 'acpidump -d'. However, even with Tony's recommendation of removing the acquire/release of _GL in methods C12C and C12D, I still can't get xbatt or wmbattery to run, even with the very latest -current (which has had at least one acpi stack upgrade since 7/30). When I run either command, it locks the box tight. If I ever get a cursor back, I have to Ctrl-Alt-Backspace to get out of X, since I can't actually type anything. I have a feeling that my acpi table didn't actually get overridden though, due to the following from dmesg: ACPI: DSDT was overridden. -0424: *** Error: UtAllocate: Could not allocate size 6e49202a ACPI-0428: *** Error: Could not allocate table memory for [/* ] length 6e49202a ACPI-0368: *** Error: Could not copy override ACPI table, AE_NO_MEMORY Also, the "before" and "after" acpidump's don't show anything different. So, I'm curious if wmbatt is still working for Tony and Robert or not with the latest -current. The other problem I'm having is that doing 'sysctl -a', or just 'sysctl hw.acpi' locks the system tight for a couple minutes, and never completes. The last line that's printed to the screen is: hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 Any ideas on that one? Thanks, Doug > > > /boot/loader.conf is now > > > > > > hw.pci.allow_unsupported_io_range=1 > > > acpi_dsdt_load="YES" > > > acpi_dsdt_name="/boot/acpi_dsdt.aml -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: threading problems
Oh yes, user threading doesn't support multiple CPUs... Thanks for pointing me. Both libkse and libthr work with that code snippet, but Viewperf when linked against any of them locks my machine pretty deadly. With Linuxthreads it just segfaults ;) --- Regards, Rhett Dan Nelson wrote: > > In the last episode (Sep 01), RMH said: > > Hello gentlemen, > > > > I seem to have threading problems with 5.1-RELEASE. Every time I run > > a multithreaded application (linked against libc_r) on a SMP system, > > I get only 1 CPU loaded at any moment given. I tried different > > Correct. libc_r is a userland threading library, which means that all > threads run as a single plain process. Linuxthreads forks a new > process for each thread. Try linking with -lkse or -lthr; both of > these threading libraries allow multiple threads to run simultaneously > on multiple CPUs. > > -- > Dan Nelson > [EMAIL PROTECTED] Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Kernel fails to compile
In message: <[EMAIL PROTECTED]> "Martin Jessa" <[EMAIL PROTECTED]> writes: : Sources fetched an hour ago. : Running make in /usr/src/sys/i386/compile/MYKERNEL : : : : cc -c -O -pipe -march=i486 -Wall -Wredundant-decls -Wnested-externs : -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline : -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. : -I../../../contrib/dev/acpica -I../../../contrib/ipfilter : -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -D_KERNEL : -include opt_global.h -fno-common -finline-limit=15000 : -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 : -ffreestanding -Werror ../../../dev/pcic/i82365.c : ../../../dev/pcic/i82365.c: In function `pcic_chip_do_mem_map': : ../../../dev/pcic/i82365.c:850: error: structure has no member named `offset' : ../../../dev/pcic/i82365.c:855: error: structure has no member named `offset' : ../../../dev/pcic/i82365.c: In function `pcic_chip_mem_map': : ../../../dev/pcic/i82365.c:928: error: structure has no member named `offset' : *** Error code 1 Don't use pcic and pccard in the same kernel. It can't possibly work, and I'm working on a replacement that does. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: threading problems
In the last episode (Sep 01), RMH said: > Oh yes, user threading doesn't support multiple CPUs... Thanks for > pointing me. > > Both libkse and libthr work with that code snippet, but Viewperf > when linked against any of them locks my machine pretty deadly. > With Linuxthreads it just segfaults ;) Try updating to a -current kernel and libkse/libthr libraries; I have no problems running your test program with either of them, and neither did Norikatsu Shigemura, apparently. -- 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: ACPI problems with Compaq Evo N610c
I don't seem to have these problems. I use xbattbar without problem. I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl On Sun, Aug 31, 2003 at 07:50:03PM -0700, Doug Barton wrote: > I got interested in this recently because I inherited one of these > laptops from work. > > On Wed, 30 Jul 2003, Cagle, John (ISS-Houston) wrote: > > I just updated to F.15, and it does indeed fix the windows bit in the > output of 'acpidump -d'. However, even with Tony's recommendation of > removing the acquire/release of _GL in methods C12C and C12D, I still > can't get xbatt or wmbattery to run, even with the very latest -current > (which has had at least one acpi stack upgrade since 7/30). When I run > either command, it locks the box tight. If I ever get a cursor back, I > have to Ctrl-Alt-Backspace to get out of X, since I can't actually type > anything. > > I have a feeling that my acpi table didn't actually get overridden > though, due to the following from dmesg: > > ACPI: DSDT was overridden. > -0424: *** Error: UtAllocate: Could not allocate size 6e49202a > ACPI-0428: *** Error: Could not allocate table memory for [/* > ] length 6e49202a > ACPI-0368: *** Error: Could not copy override ACPI table, > AE_NO_MEMORY > > Also, the "before" and "after" acpidump's don't show anything different. > So, I'm curious if wmbatt is still working for Tony and Robert or not > with the latest -current. > > The other problem I'm having is that doing 'sysctl -a', or just 'sysctl > hw.acpi' locks the system tight for a couple minutes, and never > completes. The last line that's printed to the screen is: > > hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > > Any ideas on that one? > > Thanks, > > Doug > > -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Re: automated clean up of /usr/lib because of /lib
On Sun, Aug 31, 2003 at 08:31:49PM +0200, Alexander Leidinger wrote: > shouldn't we add something like > ---snip--- > for i in /lib/lib*.so.*; do > lib=$(basename $i) > [ -f /usr/lib/$lib ] && chflags noschg /usr/lib/$lib && rm /usr/lib/$lib > done > ---snip--- > into UPDATING or append it to the end of installworld? I think a better way is to add a new target to src/Makefile.inc1, say "installcleanworld". It would do this: mv /usr/include /usr/include.OLD mkdir /usr/lib.OLD mv /usr/lib/*.* /usr/lib.OLD ldconfig -m /usr/lib.OLD make installworld rm -rf /usr/lib.OLD /usr/include.OLD I may even make a patch for this myself. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /lib symlinks problem?
On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote: > > > I might be missing an obvious, but I just don't see a reason > > > why we should use relative linking here: we should just link > > > to where we really install. With the attached patch, I get: ... > +.if ${LIBDIR} != ${SHLIBDIR} > + ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK} Why are we making *any* symlinks here?? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: threading problems
On Mon, 1 Sep 2003, [iso-8859-1] RMH wrote: > Oh yes, user threading doesn't support multiple CPUs... Thanks for > pointing me. > > Both libkse and libthr work with that code snippet, but Viewperf > when linked against any of them locks my machine pretty deadly. > With Linuxthreads it just segfaults ;) you probably need to upgrade to 5.1-current as 5.1 thread support was very green. Lots of bugs fixed since then also threading questions to [EMAIL PROTECTED] > > --- > Regards, > Rhett > > Dan Nelson wrote: > > > > In the last episode (Sep 01), RMH said: > > > Hello gentlemen, > > > > > > I seem to have threading problems with 5.1-RELEASE. Every time I run > > > a multithreaded application (linked against libc_r) on a SMP system, > > > I get only 1 CPU loaded at any moment given. I tried different > > > > Correct. libc_r is a userland threading library, which means that all > > threads run as a single plain process. Linuxthreads forks a new > > process for each thread. Try linking with -lkse or -lthr; both of > > these threading libraries allow multiple threads to run simultaneously > > on multiple CPUs. > > > > -- > > Dan Nelson > > [EMAIL PROTECTED] > > > Want to chat instantly with your online friends? Get the FREE Yahoo! > Messenger http://uk.messenger.yahoo.com/ > ___ > [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: /lib symlinks problem?
On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote: > On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote: > > > > I might be missing an obvious, but I just don't see a reason > > > > why we should use relative linking here: we should just link > > > > to where we really install. With the attached patch, I get: > ... > > +.if ${LIBDIR} != ${SHLIBDIR} > > + ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK} > > Why are we making *any* symlinks here?? > : revision 1.150 : date: 2003/08/17 23:56:29; author: gordon; state: Exp; lines: +2 -3 : When creating .so symlinks, use SHLIBDIR instead of LIBDIR so symlinks : are created in the correct location. Always make them. For libraries : that live in /lib, this causes a /lib/libfoo.so and a compatibility : /usr/lib/libfoo.so to be created. We may want to drop the : /usr/lib/libfoo.so symlink at some future point. I think that Gordon took a safe path with creating compatibility symlinks. Besides, creating compatibility symlinks has a nicety of removing your stale symlinks in /usr/lib. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: need some debugging help
On Sun, Aug 31, 2003 at 12:52:47 +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, "Kenneth D. Merry" writes: > > >Anyway, I got some debugging output, and I've attached dmesg output. Let > >me know whether anything in there looks suspicious or points to a possible > >problem. > > There's nothing which jumps out at me, and I guess the best strategy is > hunting down the devbuf thing by changing all users of M_DEVBUF until > something trips... Thanks. That did the trick. As it turns out, it was a one-line problem in the da(4) patches that was causing the problem. Anyway, that's fixed, and things seem to work fine. I've attached a new version of the patches. I'll try to come up with a -stable version that'll fix things there as well. If anyone wants to take a look at the way I'm using mutexes here, especially in the new taskqueue thread, I'd appreciate it. In particular, I went through some interesting permutations in taskqueue_kthread() to make things work right: - I tried holding Giant when calling tsleep, but it complained that I didn't own Giant. - I tried not holding a mutex at all when calling tsleep, but ran into this assert in msleep(): KASSERT(timo != 0 || mtx_owned(&Giant) || mtx != NULL, ("sleeping without a mutex")); - I tried just holding a mutex all the time, but obviously you can't malloc while holding a mutex (except Giant), and the sysctl code does a number of mallocs. (The original cause of this problem -- M_WAITOK mallocs.) So in the end, I just acquire a mutex, drop it for taskqueue_run(), re-acquire it and and pass it into the msleep call so that it can drop it and re-acquire it for me. There's no other reason for it. The taskqueue stuff already has its own mutex that isn't exposed to taskqueue_run(), and it shouldn't be held anyway when the task's function is called. I also put code in the sysctl functions in the cd(4) and da(4) drivers to acquire Giant, since I'm assuming that the sysctl code needs it. Comments are welcome. Thanks, Ken -- Kenneth Merry [EMAIL PROTECTED] //depot/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c#39 - /usr/home/ken/perforce2/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c *** /tmp/tmp.319.0 Mon Sep 1 00:33:39 2003 --- /usr/home/ken/perforce2/FreeBSD-ken/src/sys/cam/scsi/scsi_cd.c Mon Sep 1 00:21:23 2003 *** *** 62,67 --- 62,68 #include #include #include + #include #include #include *** *** 154,159 --- 155,161 eventhandler_tagclonetag; int minimum_command_size; int outstanding_cmds; + struct task sysctl_task; struct sysctl_ctx_list sysctl_ctx; struct sysctl_oid *sysctl_tree; STAILQ_HEAD(, cd_mode_params) mode_queue; *** *** 598,603 --- 600,642 } } + static void + cdsysctlinit(void *context, int pending) + { + struct cam_periph *periph; + struct cd_softc *softc; + char tmpstr[80], tmpstr2[80]; + + periph = (struct cam_periph *)context; + softc = (struct cd_softc *)periph->softc; + + snprintf(tmpstr, sizeof(tmpstr), "CAM CD unit %d", periph->unit_number); + snprintf(tmpstr2, sizeof(tmpstr2), "%d", periph->unit_number); + + mtx_lock(&Giant); + + sysctl_ctx_init(&softc->sysctl_ctx); + softc->sysctl_tree = SYSCTL_ADD_NODE(&softc->sysctl_ctx, + SYSCTL_STATIC_CHILDREN(_kern_cam_cd), OID_AUTO, + tmpstr2, CTLFLAG_RD, 0, tmpstr); + + if (softc->sysctl_tree == NULL) { + printf("cdsysctlinit: unable to allocate sysctl tree\n"); + return; + } + + /* +* Now register the sysctl handler, so the user can the value on +* the fly. +*/ + SYSCTL_ADD_PROC(&softc->sysctl_ctx,SYSCTL_CHILDREN(softc->sysctl_tree), + OID_AUTO, "minimum_cmd_size", CTLTYPE_INT | CTLFLAG_RW, + &softc->minimum_command_size, 0, cdcmdsizesysctl, "I", + "Minimum CDB size"); + + mtx_unlock(&Giant); + } + /* * We have a handler function for this so we can check the values when the * user sets them, instead of every time we look at them. *** *** 642,648 struct ccb_setasync csa; struct ccb_pathinq cpi; struct ccb_getdev *cgd; ! char tmpstr[80], tmpstr2[80]; caddr_t match; cgd = (struct ccb_getdev *)arg; --- 681,687 struct ccb_setasync csa; struct ccb_pathinq cpi; struct ccb_getdev *cgd; ! char tmpstr[80]; caddr_t match; cgd = (struct ccb_getdev *)arg; *** *** 696,712 if (cpi.ccb_h.status == CAM_REQ_CMP && (cpi.hba_misc & PIM_NO_6_BYTE)) softc->quirks |= CD_Q_10_BYTE_ONLY; ! snprintf(tmpstr, sizeof(tmpstr), "CAM CD unit %d"
Re: /lib symlinks problem?
On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote: > I think that Gordon took a safe path with creating compatibility symlinks. > Besides, creating compatibility symlinks has a nicety of removing your > stale symlinks in /usr/lib. I always asked myself whether there is a tool or some kind of database at which one can throw an existing installation and it knows about which files have to be there and where and which ain't to be there (like such symlink relicts), maybe a hook in install,cp,ln and what else is being used in the world install process. That way it could tell me what files are candidates for deleting. -- Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: need some debugging help
On Mon, Sep 01, 2003 at 02:23:18 +0200, Pawel Jakub Dawidek wrote: > On Mon, Sep 01, 2003 at 02:13:45AM +0200, Pawel Jakub Dawidek wrote: > +> I was getting same panics while I was working on GEOM Gate. > +> After many hours of debugging I've tracked this down - I've initialized > +> a mutex, but I haven't destroy it. > +> > +> As I susspect you're loading cd(4) as kld module? > > No, you don't need to load it as kld module, because you initiate > this mutex on every function call (and mutex is locally allocated to), > so try to put mtx_destroy() on the end of this function, this should help. > (I hope there is no problem with calling msleep(9) with mutex from stack) Well, keep in mind that this function, taskqueue_kthread(), is only called once, when the kthread is forked off. It then runs in an infinite loop forever. So far it doesn't seem like there's any problem with calling msleep() with a mutex allocated on the stack. The problem I was having turned out to be that I forgot to deference periph->softc in dasysctlinit(). Ken -- Kenneth Merry [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src Makefile.inc1
On Sun, Aug 31, 2003 at 11:43:25PM -0700, Scott Long wrote: > scottl 2003/08/31 23:43:25 PDT > > FreeBSD src repository > > Modified files: > .Makefile.inc1 > Log: > Clarify the numbering of some of the build stages. > > Revision ChangesPath > 1.389 +9 -9 src/Makefile.inc1 > How about if we get rid of the numbering here completely? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: /lib symlinks problem?
On Mon, Sep 01, 2003 at 08:58:19AM +0200, Christoph P. Kukulies wrote: > On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote: > > I think that Gordon took a safe path with creating compatibility symlinks. > > Besides, creating compatibility symlinks has a nicety of removing your > > stale symlinks in /usr/lib. > > I always asked myself whether there is a tool or some kind of > database at which one can throw an existing installation and it > knows about which files have to be there and where and which ain't > to be there (like such symlink relicts), maybe a hook in install,cp,ln > and what else is being used in the world install process. > That way it could tell me what files are candidates for deleting. > Hold on, Warner is almost ready for an real solution here, I think. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: /lib symlinks problem?
In message: <[EMAIL PROTECTED]> Ruslan Ermilov <[EMAIL PROTECTED]> writes: : On Mon, Sep 01, 2003 at 08:58:19AM +0200, Christoph P. Kukulies wrote: : > On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote: : > > I think that Gordon took a safe path with creating compatibility symlinks. : > > Besides, creating compatibility symlinks has a nicety of removing your : > > stale symlinks in /usr/lib. : > : > I always asked myself whether there is a tool or some kind of : > database at which one can throw an existing installation and it : > knows about which files have to be there and where and which ain't : > to be there (like such symlink relicts), maybe a hook in install,cp,ln : > and what else is being used in the world install process. : > That way it could tell me what files are candidates for deleting. : > : Hold on, Warner is almost ready for an real solution here, I think. My tool is initially just a 'delete these files' tool, but now that I think about it, it wouldn't be hard to say also 'create these symlinks'. The hard part here is generating the 'obsolete' lists. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src Makefile.inc1
Ruslan Ermilov wrote: On Sun, Aug 31, 2003 at 11:43:25PM -0700, Scott Long wrote: scottl 2003/08/31 23:43:25 PDT FreeBSD src repository Modified files: .Makefile.inc1 Log: Clarify the numbering of some of the build stages. Revision ChangesPath 1.389 +9 -9 src/Makefile.inc1 How about if we get rid of the numbering here completely? Cheers, I like the numbering since it can give me an idea of progress at a quick glance without having to memorize the name of each step. But, I'm flexible, I guess. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cvs commit: src Makefile.inc1
In message: <[EMAIL PROTECTED]> Scott Long <[EMAIL PROTECTED]> writes: : >> Clarify the numbering of some of the build stages. : > How about if we get rid of the numbering here completely? : I like the numbering since it can give me an idea of progress at a : quick glance without having to memorize the name of each step. But, : I'm flexible, I guess. I'm flxible too, but I kinda like the numbering, so long as I know what is being counted to :-) (eg, 1.1, 1.2, 1.3, 2.1, 2.2 ... 4.6 vs 1, 2, 3, ... 26 doesn't matter, so long as I know the terminus). Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng not detecting drives
On Sun, Aug 31, 2003 at 04:57:57PM +0200, Soren Schmidt wrote: > It seems Jan Srzednicki wrote: > > ad0: 19546MB [39714/16/63] at ata0-master UDMA66 > > ad1: 39093MB [79428/16/63] at ata0-slave UDMA66 > > ata1-slave: FAILURE - ATA_IDENTIFY status=51 > > error=4 > > acd0: CDROM at ata1-master UDMA33 > > cd0 at ata1 bus 0 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-0 device > > cd0: 33.000MB/s transfers > > cd0: cd present [2154583490 x 838860800 byte records] > > Mounting root from ufs:/dev/ad0s2a > > > > (it's this ata1-slave thing). > > Previously, it has been seen as: > > > > acd1: CD-RW at ata1-slave UDMA33 > > Ok, I've finally managed to get a setup that exhibits this problem, > expect a fix soon... Anyway, the syncer problem (giving up on just one buffer) appeared again, this time without any heavy disk loads. I'm sure it hasn't been happening before the upgrade, yet I have no idea how can I provide more feedback about it. -- -- wrzask --= v =-- Winfried --===-- GG# 3838383 --- -- [EMAIL PROTECTED] --- [EMAIL PROTECTED] --===-- http://violent.dream.vg/ --- --=< Ride the wild wind - push the envelope, don't sit on the fence, --- -- Ride the wild wind - live life on the razor's edge! >=-- Queen -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /lib symlinks problem?
On Mon, Sep 01, 2003 at 01:22:49AM -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Ruslan Ermilov <[EMAIL PROTECTED]> writes: > : On Mon, Sep 01, 2003 at 08:58:19AM +0200, Christoph P. Kukulies wrote: > : > On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote: > : > > I think that Gordon took a safe path with creating compatibility symlinks. > : > > Besides, creating compatibility symlinks has a nicety of removing your > : > > stale symlinks in /usr/lib. > : > > : > I always asked myself whether there is a tool or some kind of > : > database at which one can throw an existing installation and it > : > knows about which files have to be there and where and which ain't > : > to be there (like such symlink relicts), maybe a hook in install,cp,ln > : > and what else is being used in the world install process. > : > That way it could tell me what files are candidates for deleting. > : > > : Hold on, Warner is almost ready for an real solution here, I think. > > My tool is initially just a 'delete these files' tool, but now that I > think about it, it wouldn't be hard to say also 'create these > symlinks'. The hard part here is generating the 'obsolete' lists. > But ``delete these files'' is what's actually needed here. ;-) Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: ACPI problems with Compaq Evo N610c
On Mon, 1 Sep 2003, Robert [unknown-8bit] Blacquière wrote: > I don't seem to have these problems. I use xbattbar without problem. Argh. How recent is your -current? I compile regularly, and I was up to date as of this afternoon. > I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl Thanks for the suggestion... I tried that one, but got the same error about not enough memory to load the override file. I attached a verbose dmesg, just in case someone wants to take a look. Doug -- This .signature sanitized for your protection ified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1794188892 Hz CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz (1794.19-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebf9ff real memory = 536674304 (511 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00503000 - 0x1f6aafff, 521830400 bytes (127400 pages) avail memory = 51598 (492 MB) bios32: Found BIOS32 Service Directory header at 0xc00fa000 bios32: Entry = 0xf (c00f) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0x3a2 pnpbios: Found PnP BIOS data at 0xc00f4330 pnpbios: Entry = f:435e Rev = 1.0 pnpbios: Event flag at f4356 pnpbios: OEM ID 4d00110e Other BIOS signatures found: null: random: mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 00 01 ff 01 00 01 19 01 00 01 2f 01 00 01 34 01 00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01 VESA: 60 mode(s) found VESA: v2.0, 32704k memory, flags:0x1, mode table:0xc03f08e2 (122) VESA: ATI MOBILITY RADEON 7500 VESA: ATI Technologies Inc. P7 01.00 ACPI: DSDT was overridden. -0424: *** Error: UtAllocate: Could not allocate size 50204453 ACPI-0428: *** Error: Could not allocate table memory for [/* R] length 50204453 ACPI-0368: *** Error: Could not copy override ACPI table, AE_NO_MEMORY npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x80010014 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=1a308086) pcibios: BIOS version 2.10 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 1 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 2 dev 6 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 2 dev 6 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: power button is handled as a fixed feature programming model. ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 ACPI timer looks GOOD min = 4, max = 4, width = 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) acpi_cpu0: port 0x530-0x537 on acpi0 mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) acpi_tz0: port 0x530-0x537 on acpi0 mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) acpi_tz1: port 0x530-0x537 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.C045.C0C2 irq 0: [ 5 10 11] low,level,sharable 0.31.0 \\_SB_.C045.C0C1 irq 11: [ 5 10 11] low,level,sharable 0.31.1 before setting priority for links \\_SB_.C045.C0C2: interrupts: 51011 penalty: 110 110 210 references: 1 priority: 0 before fixup boot-disabled links - \\_SB_.C045.C0C2: interrupts: 51011 penalty: 110 110 210 references: 1 priority: 143 after fixup boot-disabled links -- arbitrated configuration - \\_SB_.C045.C0C2 irq 10: [ 5 10 11] low,level,sharable 0.31.0 \\_SB_.C045.C0C1 irq 11: [ 5 10 11] low,level,sharable 0.31.1 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base 60
Re: /lib symlinks problem?
On Mon, 1 Sep 2003, M. Warner Losh wrote: > My tool is initially just a 'delete these files' tool, but now that I > think about it, it wouldn't be hard to say also 'create these > symlinks'. The hard part here is generating the 'obsolete' lists. I posted one approach to this today... touch a file right before you start installworld, then consider anything not newer than that file a candidate for disposal. There is currently something weird going on in /usr/lib though... a lot of the files don't have newer dates, I haven't tracked down why yet. Also, I highly recommend NOT deleting the files, but moving them somewhere. This makes it much easier to recover if you delete something you shouldn't have. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: need some debugging help
In message <[EMAIL PROTECTED]>, "Kenneth D. Merry" writes: >In particular, I went through some interesting permutations in >taskqueue_kthread() to make things work right: > > - I tried holding Giant when calling tsleep, but it complained that I > didn't own Giant. I have had a similar issue a couple of places in the giant/no-giant shims for GEOM. I found one convenient trick was to sleep with a timeout instead. It's not beautiful but it works. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problems with Compaq Evo N610c
Oeps I've put the old one up... Now ik have the new one. I don't load the VESA modules, it seems these are loaded before acpi code is replaced? Robert On Mon, Sep 01, 2003 at 01:49:42AM -0700, Doug Barton wrote: > On Mon, 1 Sep 2003, Robert [unknown-8bit] Blacquire wrote: > > > I don't seem to have these problems. I use xbattbar without problem. > > Argh. How recent is your -current? I compile regularly, and I was up to > date as of this afternoon. > > > I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl > > Thanks for the suggestion... I tried that one, but got the same error > about not enough memory to load the override file. > > I attached a verbose dmesg, just in case someone wants to take a look. > > Doug > > -- > -- Microsoft: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming or what? OpenBSD: He guys you left some holes out there! pgp0.pgp Description: PGP signature
Kernel Panic near inphy0
I am currently trying to upgrade from 5.1-RELEASE to current on my Sony VAIO laptop, model number GRX-570. On first boot of CURRENT kernel a panic occurs right after inphy: Fatal trap 12: page fault while in kernel mode Fault virtual address= 0xdeadc0de Fault code= supervisor write, page not present Instruction pointer=0x8:0xc0 Stack pointer= 0x10:0xc077e7b8 Frame pointer= 0x10:0xc077e7d8 Code segment= base 0x0, limit 0xf, type 0x1b DBL0, pres 1, def32, gran 1 Processor eflags= interrupt enabled resume, IOPL = 0 Current process= 0 (swapper) Kernel type 12 trap, code = 0 Stopped at ithread_add_handler+0x143 movl %ebx,0(%eax) Is there a fix or workaround currently for this error? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /lib symlinks problem?
On Mon, Sep 01, 2003 at 01:58:52AM -0700, Doug Barton wrote: > On Mon, 1 Sep 2003, M. Warner Losh wrote: > > > My tool is initially just a 'delete these files' tool, but now that I > > think about it, it wouldn't be hard to say also 'create these > > symlinks'. The hard part here is generating the 'obsolete' lists. > > I posted one approach to this today... touch a file right before you > start installworld, then consider anything not newer than that file a > candidate for disposal. There is currently something weird going on in > /usr/lib though... a lot of the files don't have newer dates, I haven't > tracked down why yet. > This is because static libraries are installed with -C. The reasoning was like this: On Sat, Mar 30, 2002 at 02:15:56PM +0100, Dag-Erling Smorgrav wrote: > Ruslan Ermilov <[EMAIL PROTECTED]> writes: > > On Fri, Mar 22, 2002 at 12:28:17PM -0800, Dag-Erling Smorgrav wrote: > > > Log: > > > Install static and profiled libraries with -C. > > Um why, what's so special about them? > > They appear in dependency lists. This was discussed on -arch. This also will not work for anything that has not changed and is installed with -C, that is includes, rtld-elf, and some parts of /sys/boot. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: /lib symlinks problem?
On Mon, 1 Sep 2003, Ruslan Ermilov wrote: > > I posted one approach to this today... touch a file right before you > > start installworld, then consider anything not newer than that file a > > candidate for disposal. There is currently something weird going on in > > /usr/lib though... a lot of the files don't have newer dates, I haven't > > tracked down why yet. > > > This is because static libraries are installed with -C. The reasoning > was like this: > > On Sat, Mar 30, 2002 at 02:15:56PM +0100, Dag-Erling Smorgrav wrote: > > Ruslan Ermilov <[EMAIL PROTECTED]> writes: > > > On Fri, Mar 22, 2002 at 12:28:17PM -0800, Dag-Erling Smorgrav wrote: > > > > Log: > > > > Install static and profiled libraries with -C. > > > Um why, what's so special about them? > > > > They appear in dependency lists. This was discussed on -arch. Can you fill in a little more detail here? I really prefer the old behavior, not using -C. > This also will not work for anything that has not changed and is > installed with -C, that is includes, I posted my script to -current just today. I 'mv include include-old' to handle this. I also blow away /usr/share/man, since creating it from scratch is just as easy as trying to cleanse it. > rtld-elf, and some parts of /sys/boot. I haven't touched /boot yet, I'm not that brave. :) There are a couple other things that my script doesn't handle just on the basis of "newer than," but as a proof of concept it's quite functional. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: automated clean up of /usr/lib because of /lib
On Sun, 31 Aug 2003 15:02:21 -0700 (PDT) Doug Barton <[EMAIL PROTECTED]> wrote: > There was a discussion of this recently, and the conclusion was more or > less that doing this in an automated fashion is frought with danger, > since you don't know for sure what else besides system components the > user has put in the various directories. > > I've been using the following combination of a bash function (that could > just as easily be its own script) and a script I call > after_installworld. [script which does the right thing] > This combination keeps things squeaky clean for me. Yes, it does it for you (and for everyone else who does the right thing), but I've seen abuse of your system directories to many times, so this would perhaps screw some of our users. So I don't think we should add something like you do or something like David does into installworld. My snipped just looks if there are libs in /usr/lib which also are in /lib and removes them from /usr/lib. That's one specific thing we know we have to do now. I don't insist of adding it to installworld, but we should at least add something into UPDATING which tells the user to clean up his /usr/lib after we added /lib (and my snipped automates this). Bye, Alexander. -- Secret hacker rule #11: hackers read manuals. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: need some debugging help
On Mon, Sep 01, 2003 at 12:48:41AM -0600, Kenneth D. Merry wrote: +> - I tried just holding a mutex all the time, but obviously you can't +>malloc while holding a mutex (except Giant), and the sysctl code does a +>number of mallocs. (The original cause of this problem -- M_WAITOK +>mallocs.) I've proposed some time ago changing M_WAITOK to M_NOWAIT, because function/macros responsible for sysctl creation could failed from other reasons, so I don't see any reason why they couldn't fail because of insufficient memory. Caller is obliged to check return value... -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
ATAng probe updated please test
I've gone over the probe code once again. Please test, and in case it fails to detect or misdetects anything, mail me the output of dmesg from a verbose boot, and state what devices actually are there. Thanks! -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is there a "knob" for devfs rules?
Check out the header comments in the recently created /etc/defaults/devfs.rules and the new rc.conf variable devfs_system_ruleset. In your case below, you'd probably need an /etc/devfs.rules like: # Create local ruleset [local_ruleset=10] add path 'ugen*' mode 664 And then you'd add the following line to /etc/rc.conf: devfs_system_ruleset="local_ruleset" On Sunday 31 August 2003 10:44 pm, John Reynolds wrote: > Hi all, in debugging /dev/usb* and /dev/ugen* permissions problems > so that I could access my digital camera as a mere-mortal user, I > came across this posting to -questions: > > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=1203173+1206388+/usr/lo >cal/www/db/text/2003/freebsd-questions/20030622.freebsd-questions > > Indeed what Jesse posted worked like a charm: > > devfs ruleset 10 > devfs rule add path 'ugen*' mode 664 > > Since the ugen* devices are "dynamic," putting entries in > /etc/devfs.conf doesn't work unless you "restart" devfs once the > camera is turned on. Thus, the rule above works nicely. > > He had asked in the mail where the "appropriate" place for these > commands should be, but the thread ended there. So, I pose the > question to this list. I didn't see anything in > /etc/defaults/rc.conf regarding devfs. > > So, would the "appropriate" thing be to create a .sh file in > /usr/local/etc/rc.d which contained the rule commands one would > want and just have them be applied via this mechanism once it was > very clear that devfs was up and running, etc.? > > Thanks, > > -Jr ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: buildworld seg faulting.
On Monday, 01 September 2003 02:24, Steve Kargl wrote: > On Sun, Aug 31, 2003 at 07:52:15PM +1000, Alastair G. Hogge wrote: > > Hello list, > > > > For the past couple of weeks I've been tyring to keep my system up to > > date with cvsup. However, when ever I run a buildworld I get problems > > with gcc (I think it's gcc). I've tried nuking /usr/obj and running "make > > clean" many tims before each build but this doesn't help. What I've > > noticed is that the seg fault doesn't occur in the same place. > > There isn't enough context in the error messages you reported. > Are you using the -j option during your buildworld? No. just plain old "make buildworld" i did also try -j3 > However, your last sentence in the above quoted paragraph, > suggests that you have bad memory or a heating problem or a > suspect power supply. Ahhh. I don't like the sound of that. Is there something else I'm leaving out. I really hope it isn't memory I sold my thumbs to get 512megs of Corsair XSM :-( -Al ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: buildworld seg faulting.
Alastair G. Hogge wrote: On Monday, 01 September 2003 02:24, Steve Kargl wrote: On Sun, Aug 31, 2003 at 07:52:15PM +1000, Alastair G. Hogge wrote: Hello list, For the past couple of weeks I've been tyring to keep my system up to date with cvsup. However, when ever I run a buildworld I get problems with gcc (I think it's gcc). I've tried nuking /usr/obj and running "make clean" many tims before each build but this doesn't help. What I've noticed is that the seg fault doesn't occur in the same place. There isn't enough context in the error messages you reported. Are you using the -j option during your buildworld? No. just plain old "make buildworld" i did also try -j3 However, your last sentence in the above quoted paragraph, suggests that you have bad memory or a heating problem or a suspect power supply. Ahhh. I don't like the sound of that. Is there something else I'm leaving out. I really hope it isn't memory I sold my thumbs to get 512megs of Corsair XSM :-( Download memtest86 and let it run for a couple of hours. If you see any errors at all, try and get that memory replaced under warranty. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cdcontrol no longer needs 'c' partition?
On Fri, 22 Aug 2003, 19:49+0400, Maxim Konovalov wrote: > On Fri, 22 Aug 2003, 10:39-0400, Craig Rodrigues wrote: > > > On Fri, Aug 22, 2003 at 09:00:32AM +0400, Maxim Konovalov wrote: > > > On Sun, 17 Aug 2003, 17:21-0400, Craig Rodrigues wrote: > > > > > > > Hi, > > > > > > > > With GEOM in place, is the 'c' partition for a CD device no > > > > longer necessary for cdcontrol? At least on my system, > > > > the CD shows up as /dev/acd0, not as /dev/acd0c. > > > > > > What's about CDROM environment var defined in login.conf? > > > > I don't understand your question. > > If the CDROM environment variable is set to a device name, cdcontrol will > > try to open that device. This is documented in the cdcontrol man page. > > If the CDROM environment variable is not set, a default device > > name of of /dev/cd0c is used, unless you override this with the -f flag. > > Ah, nevermind, I messed with my local login.conf modifications. > > Your patch looks OK, I will commit it on the next week if nobody > objects. done. -- Maxim Konovalov, [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: ATAng probe updated please test
Soren Schmidt wrote: I've gone over the probe code once again. Please test, and in case it fails to detect or misdetects anything, mail me the output of dmesg from a verbose boot, and state what devices actually are there. Thanks! -Søren Mine is working perfectly now (see below). With atapicam as well. Thankyou very much for your work! Regards, Matt. ad0: 76319MB [155061/16/63] at ata0-master UDMA100 acd0: DVDROM at ata1-master PIO4 acd1: CDRW at ata1-slave PIO4 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: cd present [3284421 x 1835364913 byte records] cd1 at ata1 bus 0 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 16.000MB/s transfers cd1: cd present [15421890 x 0 byte records] [EMAIL PROTECTED] root]# cdrecord --scanbus Cdrecord 2.00.3 (i386-unknown-freebsd5.1) Copyright (C) 1995-2002 Jörg Schilling Using libscg version 'schily-0.7' scsibus2: 2,0,0 200) 'Compaq ' 'DVD-ROM SD-616T ' 'F304' Removable CD-ROM 2,1,0 201) 'SAMSUNG ' 'CD-R/RW SW-240B ' 'R407' Removable CD-ROM ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng probe updated please test
Matt wrote: Soren Schmidt wrote: I've gone over the probe code once again. Please test, and in case it fails to detect or misdetects anything, mail me the output of dmesg from a verbose boot, and state what devices actually are there. Thanks! -Søren Mine is working perfectly now (see below). With atapicam as well. Thankyou very much for your work! Regards, Matt. ad0: 76319MB [155061/16/63] at ata0-master UDMA100 acd0: DVDROM at ata1-master PIO4 acd1: CDRW at ata1-slave PIO4 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: cd present [3284421 x 1835364913 byte records] cd1 at ata1 bus 0 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 16.000MB/s transfers cd1: cd present [15421890 x 0 byte records] [EMAIL PROTECTED] root]# cdrecord --scanbus Cdrecord 2.00.3 (i386-unknown-freebsd5.1) Copyright (C) 1995-2002 Jörg Schilling Using libscg version 'schily-0.7' scsibus2: 2,0,0 200) 'Compaq ' 'DVD-ROM SD-616T ' 'F304' Removable CD-ROM 2,1,0 201) 'SAMSUNG ' 'CD-R/RW SW-240B ' 'R407' Removable CD-ROM Actually saying that is this perfectly? There are no cd's in either of those two drives and it says cd present in that dmesg ? Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.1-RELEASE-p2 buildworld crash - help!!
Hello gurus, I have a dead system! No service will start at all, but if I can get over this buildworld failure, then maybe I can compile a new kernel and get my services running. It's not a production box, but a test box. The problem started this way: I cvsup-ped, make buildworld, then kind of I forgot to buildkernel/ installkernel/installworld. I did another cvsup (I hadn't rebooted even, and yes, I do build{world|kernel} in server mode, then do installworld/mergemaster in single user mode. Now after cvsupping afresh, I have failed to buildworld completely, even doing cvsup N times again. Buildworld always fails with the error depicted in the log output below: http://ns2.wananchi.com/~wash/FreeBSD/ - that text file in there. Thanks in advance for any pointers that may enable me over this. -Wash -- Odhiambo Washington <[EMAIL PROTECTED]> "The box said 'Requires Wananchi Online Ltd. www.wananchi.com Windows 95, NT, or better,' Tel: +254 2 313985-9 +254 2 313922 so I installed FreeBSD." GSM: +254 72 743223 +254 733 744121 This sig is McQ! :-) Demographic polls show that you have lost credibility across the board. Especially with those 14 year-old Valley girls. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.2-RELEASE TODO
This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. FreeBSD 5.2 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.2. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.2-RELEASE ++ |Issue| Status | Responsible |Description | |-+---+-+| | | | | KSE M:N threading | | | | | support is | | | | | reaching | | | | | experimental yet | | | | Julian | usable status on | | Production-quality | In| Elischer, David | i386 for | | M:N threading | progress | Xu, Daniel | 5.1-RELEASE. M:N | | | | Eischen | threading should | | | | | be productionable | | | | | and usable on all | | | | | platforms by | | | | | 5.2-RELEASE. | |-+---+-+| | | | | Kernel bits are| | | | | implemented but| | KSE support for | In| | untested. Userland | | sparc64 | progress | Jake Burkholder | bits are not | | | | | implemented. | | | | | Required for | | | | | 5.2-RELEASE. | |-+---+-+| | | | | Kernel and | | KSE support for | | Marcel | userland bits | | ia64| Complete. | Moolenaar | implemented but| | | | | unstable. Required | | | | | for 5.2-RELEASE. | |-+---+-+| | | | | Userland bits | | | | | implemented, | | KSE support for | In| Marcel | kernel bits not| | alpha | progress. | Moolenaar | implemented. | | | | | Required for | | | | | 5.2-RELEASE. | |-+---+-+| | | | | Kris Kennaway | | | | | reports high | | | | | instability of | | | | | 5-CURRENT on ia64 | | | | | machines, such as | | ia64 stability | In| Marcel | the pluto* | | | Progress | Moolenaar | machines. These| | | | | problems need to | | | | | be fixed in order | | | | | to get a | | | | | successful package | | | | | build. | |-+---+-+| | | | | A reworking of the | | | | | sio driver is | | | | | needed to support | | | | | serial terminal| | | | Marcel | devices on sparc64 | | New serial UART | In| Moolenaar, | and ia64 | | framework | progress | Warner Losh | platforms, among | | | | | others. This is| | | |
Re: pcic device causes kernel build failure
"M. Warner Losh" wrote: > Don't build pcic with newcard. It is broken, doesn't work and isn't > supported. I have a rewrite in my p4 tree that I'm slugging through, > but pcic is likely to coninue to not compile until that's committed. Will that eventually fix support for the following (dmesg fragment from 4.8-STABLE)?: pcic0: at port 0x3e0 iomem 0xd on isa0 pcic0: Polling mode pccard0: on pcic0 pccard1: on pcic0 I'd like to run CURRENT on this laptop, but this thwarted me last time by revoking my network. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bsd.lib.mk and bsd.own.mk ignore /etc/make.conf(INSTALL)
Hi Any idea why '-C' is hard coded for bsd.lib.mk and bsd.own.mk? I thought that the make.conf variable was there to allow or disallow this. The following comes from bsd.lib.mk: .if defined(LIB) && !empty(LIB) && !defined(NOINSTALLLIB) ${INSTALL} -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ ${_INSTALLFLAGS} lib${LIB}.a ${DESTDIR}${LIBDIR} .endif .if !defined(NOPROFILE) && defined(LIB) && !empty(LIB) ${INSTALL} -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \ ${_INSTALLFLAGS} lib${LIB}_p.a ${DESTDIR}${LIBDIR} .endif Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Question About Disk Access.
After making world as of August 30 i am seeing weird disk access when i boot up the little yellow LED that shows disk access is constantly lit there is no way of turning it off and i dont see/know a way to see ehats making it do what it does fstat,lsof dont seem to find anything its a bit anoying heh later ill add a verbose dmesg or whatever is needed to fix this. _ MSN 8: Get 6 months for $9.95/month. http://join.msn.com/?page=dept/dialup ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is there a "knob" for devfs rules?
From: "John Reynolds" <[EMAIL PROTECTED]> > Hi all, in debugging /dev/usb* and /dev/ugen* permissions problems so that I > could access my digital camera as a mere-mortal user, I came across this > posting to -questions: > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=1203173+1206388+/usr/local/www/db/text/2003/freebsd-questions/20030622.freebsd-questions > > Indeed what Jesse posted worked like a charm: > > devfs ruleset 10 > devfs rule add path 'ugen*' mode 664 > You would need to add the following to /etc/devfs.rules: [devfsrules_ugen=50] add path 'ugen*' mode 664 Then add to /etc/rc.conf: devfs_system_ruleset="devfsrules_ugen" Scot ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng probe updated please test
>I've gone over the probe code once again. I upgraded, and now my DVDROM (ata1-slave) is working again, but my Plextor 8/4/32A CDRW (ata1-master) still won't probe correctly. atacontrol list appears to send out the same message as before. dmesg & atacontrol list output attached. Andrew Lankford Latest ATAng kernel (without atapicam): 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 #18: Mon Aug 25 19:55:14 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARL5KERNEL Preloaded elf kernel "/boot/kernel/kernel" at 0xc04e2000. Preloaded elf module "/boot/kernel/vesa.ko" at 0xc04e2228. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc04e22d4. Preloaded elf module "/boot/kernel/if_sis.ko" at 0xc04e2380. Preloaded elf module "/boot/kernel/if_xl.ko" at 0xc04e242c. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04e24d8. Preloaded elf module "/boot/kernel/snd_es137x.ko" at 0xc04e2584. Preloaded elf module "/boot/kernel/usb.ko" at 0xc04e2634. Preloaded elf module "/boot/kernel/ums.ko" at 0xc04e26dc. Preloaded elf module "/boot/kernel/agp.ko" at 0xc04e2784. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04e282c. Calibrating clock(s) ... i8254 clock: 1193163 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 737022692 Hz CPU: Intel Pentium III (737.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 535736320 (510 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00509000 - 0x1f5c9fff, 520884224 bytes (127169 pages) avail memory = 515031040 (491 MB) bios32: Found BIOS32 Service Directory header at 0xc00f1430 bios32: Entry = 0xf0bf0 (c00f0bf0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdf0 pnpbios: Found PnP BIOS data at 0xc00fc070 pnpbios: Entry = f:c0a0 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: null: random: mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 00 01 10 00 53 25 2e 01 00 01 40 01 00 01 63 01 00 01 1c 01 09 01 0a 01 0b 01 0c 01 1d 01 0e 01 00 01 27 01 28 01 01 01 10 01 11 01 12 01 02 01 VESA: 20 mode(s) found VESA: v3.0, 1024k memory, flags:0x1, mode table:0xc03fdc62 (122) VESA: Intel(R) 810, Intel(R) 815 Chipset Video BIOS VESA: Intel Corporation Intel(R) 810, Intel(R) 815 Chipset Hardware Version 0.0 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=11308086) pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00f1360 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 72540A 0x60 3 4 5 7 9 10 11 12 slot 72540B 0x61 3 4 5 7 9 10 11 12 embedded02A 0x60 3 4 5 7 9 10 11 12 embedded0 31A 0x60 3 4 5 7 9 10 11 12 embedded0 31B 0x61 3 4 5 7 9 10 11 12 embedded0 31C 0x6b 3 4 5 7 9 10 11 12 embedded0 31D 0x63 3 4 5 7 9 10 11 12 slot 1 19A 0x69 3 4 5 7 9 10 11 12 slot 1 19B 0x6a 3 4 5 7 9 10 11 12 slot 1 19C 0x6b 3 4 5 7 9 10 11 12 slot 1 19D 0x68 3 4 5 7 9 10 11 12 slot 2 1 10A 0x6a 3 4 5 7 9 10 11 12 slot 2 1 10B 0x6b 3 4 5 7 9 10 11 12 slot 2 1 10C 0x68 3 4 5 7 9 10 11 12 slot 2 1 10D 0x69 3 4 5 7 9 10 11 12 slot 3 1 11A 0x6b 3 4 5 7 9 10 11 12 slot 3 1 11B 0x68 3 4 5 7 9 10 11 12 slot 3 1 11C 0x69 3 4 5 7 9 10 11 12 slot 3 1 11D 0x6a 3 4 5 7 9 10 11 12 slot 4 1 12A 0x68 3 4 5 7 9 10 11 12 slot 4 1 12B 0x69 3 4 5 7 9 10 11 12 slot 4 1 12C 0x6a 3 4 5 7 9 10 11 12 slot 4 1 12D 0x6b 3 4 5 7 9 10 11 12 slot 5 1 13A 0x69 3 4 5 7 9 10 11 12 slot 5 1 13B 0x6a 3 4 5 7 9 10 11 12 slot 5 1 13C 0x6b 3 4 5 7 9 10 11 12 slot 5 1 13D 0x68 3 4 5 7 9 10 11 12 slot 6 1 14A 0x62 3 4 5 7 9 10 11 12 slot 6 1 14B 0x63 3 4 5 7 9 10 11 12 slot 6 1 14C 0x60 3 4 5 7 9 10 11 12 slot 6 1 14D 0x61 3 4 5 7 9 10 11 12 embedded18A 0x68 3 4 5 7 9 10 11 12 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: power button is handled as a fixed feature programming model. ACPI timer looks BAD min = 3, max = 778, width = 775 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks BAD min = 3, max = 785,
Re: is there a "knob" for devfs rules?
[ On Monday, September 1, Scot W. Hetzel wrote: ] > From: "John Reynolds" <[EMAIL PROTECTED]> > I > http://www.freebsd.org/cgi/getmsg.cgi?fetch=1203173+1206388+/usr/local/www/db/text/2003/freebsd-questions/20030622.freebsd-questions > You would need to add the following to /etc/devfs.rules: > > [devfsrules_ugen=50] > add path 'ugen*' mode 664 > > Then add to /etc/rc.conf: > > devfs_system_ruleset="devfsrules_ugen" > > Scot Thanks! This is what another person has suggested, but just for the archives, this is for a "recent" -current (as I don't have this particular "knob" that the rc files recognize yet). At least more recent than Aug 19th. Thanks again for the pointer. I will CVSup and re-install today! -Jr -- John & Jennifer Reynolds johnjen at reynoldsnet.orgwww.reynoldsnet.org Sr. Physical Design Engineer - WCCG/CCE PDE jreynold at sedona.ch.intel.com Running FreeBSD since 2.1.5-RELEASE. FreeBSD: The Power to Serve! "Unix is user friendly, it's just particular about the friends it chooses." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
wi0: detach/reattach on pcmcia card pull?
I have a wi0 (Linksys WPC11 V3) card that is usually in the pcmcia slot of my laptop, but occasionally I need to pull it to use the built in nic. Is dhclient supposed to be killed on remove? Is dhclient supposed to be restarted on insert? Both of these are NOT happening on my box. -CURRENT from today. Thanks! LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng probe updated please test (ERRATA)
>I upgraded, and now my DVDROM (ata1-slave) is working again, but >my Plextor 8/4/32A CDRW (ata1-master) still won't probe >correctly. > >atacontrol list appears to send out the same message as before. > >dmesg & atacontrol list output attached. > >Andrew Lankford Crap, I attached the wrong file (an earlier boot). Sorry about that. Here we go again: 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 #23: Mon Sep 1 10:32:42 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARL5KERNEL Preloaded elf kernel "/boot/kernel/kernel" at 0xc04e4000. Preloaded elf module "/boot/kernel/vesa.ko" at 0xc04e4228. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc04e42d4. Preloaded elf module "/boot/kernel/if_sis.ko" at 0xc04e4380. Preloaded elf module "/boot/kernel/if_xl.ko" at 0xc04e442c. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04e44d8. Preloaded elf module "/boot/kernel/snd_es137x.ko" at 0xc04e4584. Preloaded elf module "/boot/kernel/usb.ko" at 0xc04e4634. Preloaded elf module "/boot/kernel/ums.ko" at 0xc04e46dc. Preloaded elf module "/boot/kernel/agp.ko" at 0xc04e4784. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04e482c. Calibrating clock(s) ... i8254 clock: 1193162 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 737022114 Hz CPU: Intel Pentium III (737.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 535736320 (510 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0050b000 - 0x1f5c9fff, 520876032 bytes (127167 pages) avail memory = 515022848 (491 MB) bios32: Found BIOS32 Service Directory header at 0xc00f1430 bios32: Entry = 0xf0bf0 (c00f0bf0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdf0 pnpbios: Found PnP BIOS data at 0xc00fc070 pnpbios: Entry = f:c0a0 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: null: random: mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 00 01 10 00 53 25 2e 01 00 01 40 01 00 01 63 01 00 01 1c 01 09 01 0a 01 0b 01 0c 01 1d 01 0e 01 00 01 27 01 28 01 01 01 10 01 11 01 12 01 02 01 VESA: 20 mode(s) found VESA: v3.0, 1024k memory, flags:0x1, mode table:0xc0400c62 (122) VESA: Intel(R) 810, Intel(R) 815 Chipset Video BIOS VESA: Intel Corporation Intel(R) 810, Intel(R) 815 Chipset Hardware Version 0.0 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x805c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=11308086) pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00f1360 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs slot 72540A 0x60 3 4 5 7 9 10 11 12 slot 72540B 0x61 3 4 5 7 9 10 11 12 embedded02A 0x60 3 4 5 7 9 10 11 12 embedded0 31A 0x60 3 4 5 7 9 10 11 12 embedded0 31B 0x61 3 4 5 7 9 10 11 12 embedded0 31C 0x6b 3 4 5 7 9 10 11 12 embedded0 31D 0x63 3 4 5 7 9 10 11 12 slot 1 19A 0x69 3 4 5 7 9 10 11 12 slot 1 19B 0x6a 3 4 5 7 9 10 11 12 slot 1 19C 0x6b 3 4 5 7 9 10 11 12 slot 1 19D 0x68 3 4 5 7 9 10 11 12 slot 2 1 10A 0x6a 3 4 5 7 9 10 11 12 slot 2 1 10B 0x6b 3 4 5 7 9 10 11 12 slot 2 1 10C 0x68 3 4 5 7 9 10 11 12 slot 2 1 10D 0x69 3 4 5 7 9 10 11 12 slot 3 1 11A 0x6b 3 4 5 7 9 10 11 12 slot 3 1 11B 0x68 3 4 5 7 9 10 11 12 slot 3 1 11C 0x69 3 4 5 7 9 10 11 12 slot 3 1 11D 0x6a 3 4 5 7 9 10 11 12 slot 4 1 12A 0x68 3 4 5 7 9 10 11 12 slot 4 1 12B 0x69 3 4 5 7 9 10 11 12 slot 4 1 12C 0x6a 3 4 5 7 9 10 11 12 slot 4 1 12D 0x6b 3 4 5 7 9 10 11 12 slot 5 1 13A 0x69 3 4 5 7 9 10 11 12 slot 5 1 13B 0x6a 3 4 5 7 9 10 11 12 slot 5 1 13C 0x6b 3 4 5 7 9 10 11 12 slot 5 1 13D 0x68 3 4 5 7 9 10 11 12 slot 6 1 14A 0x62 3 4 5 7 9 10 11 12 slot 6 1 14B 0x63 3 4 5 7 9 10 11 12 slot 6 1 14C 0x60 3 4 5 7 9 10 11 12 slot 6 1 14D 0x61 3 4 5 7 9 10 11 12 embedded18A 0x68 3 4 5 7 9 10 11 12 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: power button is handled as a fixed feature programming model. ACPI timer looks BAD min = 3, max = 786, width = 783 ACPI timer looks GOOD min = 3, max = 4, width = 1 ACPI timer looks BAD min =
Re: ATAng suspend/resume support broken
Hi. On Thu, 28 Aug 2003 21:57:24 -0700 (PDT) Nate Lawson <[EMAIL PROTECTED]> wrote: > With today's ATAng, I can suspend my laptop but when I resume, the system > hangs. I'll try to get the exact dmesg with a serial console since > syscons gets screwed up by resuming (this is normal behavior). In any > case, my laptop hangs with the drive light on while trying to reset the > ata controller. I can't enter DDB. By reverting just the ATAng commit to > 2003/08/23, suspend and resume work well. Here is my dmesg from a working > suspend/resume... > > -Nate My laptop has same behavior. So I compare ATAng with ATAold and solve this problem. I found re-init routine must necessary at wakeup. I made patches and attach to this mail. These three are patches for re-init. At least, this works for my machine. ata-all.c.diff ata-all.h.diff ata-disk.c.diff And I make one more patch "ata-lowlevel.c.diff". The Reason is ATAng code fonund ghost device on slave at resume time like this. ad1: 8994829560181951MB <\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M- %\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M-%\M^?\M- %\M^?\M-%\M^?\M-%\M^?\M-%> [676635847171814/165/165] at ata0-slave UDMA66 Mysteriously, ATAold and ATAng code using variable "ostat[01]" that save status before reset channel. I'm not familier with ATA, so maybe I'm misunderstanding. Please consider these patches. At last, I can sleep (-.-) -- Hiroyuki Aizu ata-all.c.diff Description: Binary data ata-all.h.diff Description: Binary data ata-disk.c.diff Description: Binary data ata-lowlevel.c.diff Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1-RELEASE-p2 buildworld crash - help!!
* Steve Kargl <[EMAIL PROTECTED]> [20030901 18:36]: wrote: > On Mon, Sep 01, 2003 at 05:00:44PM +0300, ODHIAMBO Washington wrote: > > > > Now after cvsupping afresh, I have failed to buildworld completely, > > even doing cvsup N times again. Buildworld always fails with the > > error depicted in the log output below: > > > > http://ns2.wananchi.com/~wash/FreeBSD/ - that text file in there. > > > > A 4.8M file? If build world dies, scroll to the end and post I did that earlier ;) cc -fpic -DPIC -O -pipe -mcpu=pentiumpro -DPTHREAD_KERNEL -I/usr/src/lib/libpthread/../libc/include -I/usr/src/lib/libpthread/threa d -I/usr/src/lib/libpthread/../../include -I/usr/src/lib/libpthread/arch/i386/include -I/usr/src/lib/libpthread/sys -I/usr/src/lib /libpthread/../../libexec/rtld-elf -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/usr/src/lib/libpthread/../libc/i386 -I/usr/src/lib/libpthread/thread -c /usr/src/lib/libpthread/arch/i386/i386/thr_enter_uts.S -o thr_enter_uts.So cc -fpic -DPIC -O -pipe -mcpu=pentiumpro -DPTHREAD_KERNEL -I/usr/src/lib/libpthread/../libc/include -I/usr/src/lib/libpthread/threa d -I/usr/src/lib/libpthread/../../include -I/usr/src/lib/libpthread/arch/i386/include -I/usr/src/lib/libpthread/sys -I/usr/src/lib /libpthread/../../libexec/rtld-elf -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/usr/src/lib/libpthread/../libc/i386 -I/usr/src/lib/libpthread/thread -c /usr/src/lib/libpthread/arch/i386/i386/thr_getcontext.S -o thr_getcontext.So cc -fpic -DPIC -O -pipe -mcpu=pentiumpro -DPTHREAD_KERNEL -I/usr/src/lib/libpthread/../libc/include -I/usr/src/lib/libpthread/threa d -I/usr/src/lib/libpthread/../../include -I/usr/src/lib/libpthread/arch/i386/include -I/usr/src/lib/libpthread/sys -I/usr/src/lib /libpthread/../../libexec/rtld-elf -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -I/usr/src/lib/libpthread/../libc/i386 -I/usr/src/lib/libpthread/thread -c /usr/src/lib/libpthread/arch/i386/i386/thr_switch.S -o thr_switch.So cc -fpic -DPIC -O -pipe -mcpu=pentiumpro -DPTHREAD_KERNEL -I/usr/src/lib/libpthread/../libc/include -I/usr/src/lib/libpthread/threa d -I/usr/src/lib/libpthread/../../include -I/usr/src/lib/libpthread/arch/i386/include -I/usr/src/lib/libpthread/sys -I/usr/src/lib /libpthread/../../libexec/rtld-elf -fno-builtin -D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall -c /usr/src/lib/libpthread/sys/lock.c - o lock.So building shared library libkse.so.1 *** Error code 1 Stop in /usr/src/lib/libpthread. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -Wash PS::REQUEST Whenever responding, please, put your response _under_ the original (previous) posting/message(s), not above them. This is the basics of Netiquette. Also, remove unneeded fragments of previous message(s), especially any "commercial" adverts and signatures. It's really ugly, space-wasting and hard-answerable to have all that junk nested a couple of times. Thank you. Q: Because it reverses the logical flow of conversation. A: Why is top posting frowned upon? -- Odhiambo Washington <[EMAIL PROTECTED]> "The box said 'Requires Wananchi Online Ltd. www.wananchi.com Windows 95, NT, or better,' Tel: +254 2 313985-9 +254 2 313922 so I installed FreeBSD." GSM: +254 72 743223 +254 733 744121 This sig is McQ! :-) Every absurdity has a champion who will defend it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /lib symlinks problem?
In message: <[EMAIL PROTECTED]> Doug Barton <[EMAIL PROTECTED]> writes: : On Mon, 1 Sep 2003, M. Warner Losh wrote: : : > My tool is initially just a 'delete these files' tool, but now that I : > think about it, it wouldn't be hard to say also 'create these : > symlinks'. The hard part here is generating the 'obsolete' lists. : : I posted one approach to this today... touch a file right before you : start installworld, then consider anything not newer than that file a : candidate for disposal. There is currently something weird going on in : /usr/lib though... a lot of the files don't have newer dates, I haven't : tracked down why yet. No. That's not what I'm talking about. That approach is crap, because installworld doesn't touch all files. : Also, I highly recommend NOT deleting the files, but moving them : somewhere. This makes it much easier to recover if you delete something : you shouldn't have. I don't care the method of removal. I care more about the list. If you want to mv them them instead of rm, it isn't a big deal to change that detail. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /lib symlinks problem?
In message: <[EMAIL PROTECTED]> Doug Barton <[EMAIL PROTECTED]> writes: : On Mon, 1 Sep 2003, Ruslan Ermilov wrote: : : > > I posted one approach to this today... touch a file right before you : > > start installworld, then consider anything not newer than that file a : > > candidate for disposal. There is currently something weird going on in : > > /usr/lib though... a lot of the files don't have newer dates, I haven't : > > tracked down why yet. : > > : > This is because static libraries are installed with -C. The reasoning : > was like this: : > : > On Sat, Mar 30, 2002 at 02:15:56PM +0100, Dag-Erling Smorgrav wrote: : > > Ruslan Ermilov <[EMAIL PROTECTED]> writes: : > > > On Fri, Mar 22, 2002 at 12:28:17PM -0800, Dag-Erling Smorgrav wrote: : > > > > Log: : > > > > Install static and profiled libraries with -C. : > > > Um why, what's so special about them? : > > : > > They appear in dependency lists. This was discussed on -arch. : : Can you fill in a little more detail here? I really prefer the old : behavior, not using -C. : : > This also will not work for anything that has not changed and is : > installed with -C, that is includes, : : I posted my script to -current just today. I 'mv include include-old' to : handle this. I also blow away /usr/share/man, since creating it from : scratch is just as easy as trying to cleanse it. : : > rtld-elf, and some parts of /sys/boot. : : I haven't touched /boot yet, I'm not that brave. :) There are a couple : other things that my script doesn't handle just on the basis of "newer : than," but as a proof of concept it's quite functional. The mv /usr/foo -> /usr/foo.old is too dangerous, and I think it is the wrong way to go. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pcic device causes kernel build failure
In message: <[EMAIL PROTECTED]> Ian Freislich <[EMAIL PROTECTED]> writes: : "M. Warner Losh" wrote: : > Don't build pcic with newcard. It is broken, doesn't work and isn't : > supported. I have a rewrite in my p4 tree that I'm slugging through, : > but pcic is likely to coninue to not compile until that's committed. : : Will that eventually fix support for the following (dmesg fragment : from 4.8-STABLE)?: : : pcic0: at port 0x3e0 iomem 0xd on isa0 : pcic0: Polling mode : pccard0: on pcic0 : pccard1: on pcic0 : : I'd like to run CURRENT on this laptop, but this thwarted me last : time by revoking my network. I do plan on supporting it, the support isn't there today. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /lib symlinks problem?
On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote: > On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote: > > On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote: > > > > > I might be missing an obvious, but I just don't see a reason > > > > > why we should use relative linking here: we should just link > > > > > to where we really install. With the attached patch, I get: > > ... > > > +.if ${LIBDIR} != ${SHLIBDIR} > > > + ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK} > > > > Why are we making *any* symlinks here?? > > > : revision 1.150 > : date: 2003/08/17 23:56:29; author: gordon; state: Exp; lines: +2 -3 > : When creating .so symlinks, use SHLIBDIR instead of LIBDIR so symlinks > : are created in the correct location. Always make them. For libraries > : that live in /lib, this causes a /lib/libfoo.so and a compatibility > : /usr/lib/libfoo.so to be created. We may want to drop the > : /usr/lib/libfoo.so symlink at some future point. > > I think that Gordon took a safe path with creating compatibility symlinks. > Besides, creating compatibility symlinks has a nicety of removing your > stale symlinks in /usr/lib. Reguardless, I think we should just not have the compatibility symlinks. I can't think of anything that really uses them. -- -- David ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /lib symlinks problem?
On Mon, Sep 01, 2003 at 09:31:29AM -0700, David O'Brien wrote: > On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote: > > On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote: > > > On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote: > > > > > > I might be missing an obvious, but I just don't see a reason > > > > > > why we should use relative linking here: we should just link > > > > > > to where we really install. With the attached patch, I get: > > > ... > > > > +.if ${LIBDIR} != ${SHLIBDIR} > > > > + ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK} > > > > > > Why are we making *any* symlinks here?? > > > > > : revision 1.150 > > : date: 2003/08/17 23:56:29; author: gordon; state: Exp; lines: +2 -3 > > : When creating .so symlinks, use SHLIBDIR instead of LIBDIR so symlinks > > : are created in the correct location. Always make them. For libraries > > : that live in /lib, this causes a /lib/libfoo.so and a compatibility > > : /usr/lib/libfoo.so to be created. We may want to drop the > > : /usr/lib/libfoo.so symlink at some future point. > > > > I think that Gordon took a safe path with creating compatibility symlinks. > > Besides, creating compatibility symlinks has a nicety of removing your > > stale symlinks in /usr/lib. > > Reguardless, I think we should just not have the compatibility symlinks. > I can't think of anything that really uses them. > If you want my opinion, I was very surprised to see this committed, and support the idea of removing the compatibility symlinks, but I'd like to hear from Gordon first about why he did this, in the first place. Perhaps, he did that before our linker was taught to look in /lib, I don't know... If it's only to get rid of stale symlinks, I have a few lines patch to bsd.lib.mk that takes care of removing them; otherwise, we can wait for the Warner's "hoover" script to reach the tools/ tree. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: 5.2-RELEASE TODO
On Mon, Sep 01, 2003 at 10:00:17AM -0400, Robert Watson wrote: > |-+---+-+| > | | | | Productionable | > | | | | support for the| > | | | | AMD64 platform.| > | | | | Currently, AMD64 | > | | | | runs fully in | > | | | | 32-bit emulation | > | Tier-1 Support for | In| Peter Wemm, | mode, and boots to | > | AMD64 Hammer| progress | David O'Brien | single-user in | > | | | | 64-bit mode. We| > | | | | expect full| > | | | | production support | > | | | | for the AMD64 | > | | | | architecture in| > | | | | 5.2-RELEASE. | > |-+---+-+| PLEASE, PLEASE update this. Not implying that FreeBSD/amd64 doesn't make it multiuser and can build its own world would be sufficient. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
David O'Brien wrote: On Mon, Sep 01, 2003 at 10:00:17AM -0400, Robert Watson wrote: |-+---+-+| | | | | Productionable | | | | | support for the| | | | | AMD64 platform.| | | | | Currently, AMD64 | | | | | runs fully in | | | | | 32-bit emulation | | Tier-1 Support for | In| Peter Wemm, | mode, and boots to | | AMD64 Hammer| progress | David O'Brien | single-user in | | | | | 64-bit mode. We| | | | | expect full| | | | | production support | | | | | for the AMD64 | | | | | architecture in| | | | | 5.2-RELEASE. | |-+---+-+| PLEASE, PLEASE update this. Not implying that FreeBSD/amd64 doesn't make it multiuser and can build its own world would be sufficient. Sorry, I missed this when I did my scrub yesterday. I'll fix it now. Btw, does X work on it? Can I compile/install it without hassle? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Syncer "giving up" on buffers
Hello, I have a problem with kernels, built the last couple of days, where during shutdown syncer is "giving up" on buffers. During the next boot all filesystems are checked because of improper dismount. Here follow the exact messages I get: Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks, buffers remaining... 8 8 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 giving up on 6 buffers Uptime: 41m20s pfs_vncache_unload(): 1 entries remaining Shutting down ACPI Rebooting... After some testing I found out that this does _not_ happen if I manually unmount my ext2 filesystems, before shutting down. In this case syncer finishes without any problems. My last kernel which did not have this problem, is the one I built on Wed Aug 27 23:14:12 EEST 2003. The output of dmesg from the verbose boot of the kernel, can be found here: http://members.hellug.gr/lefcha/dmesg.out Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1-RELEASE-p2 buildworld crash - help!!
On Monday 01 September 2003 09:17 am, ODHIAMBO Washington wrote: > * Steve Kargl <[EMAIL PROTECTED]> [20030901 18:36]: wrote: > > On Mon, Sep 01, 2003 at 05:00:44PM +0300, ODHIAMBO Washington wrote: > > > Now after cvsupping afresh, I have failed to buildworld > > > completely, even doing cvsup N times again. Buildworld always > > > fails with the error depicted in the log output below: > > > > > > http://ns2.wananchi.com/~wash/FreeBSD/ - that text file in there. > > > > A 4.8M file? If build world dies, scroll to the end and post > You could save a lot of time by turning off profiling in /etc/make.conf. If you aren't using it, there isn't any reason to build it. Set NOPROFILE= true Kent -- Kent Stewart Richland, WA http://users.owt.com/kstewart/index.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
David O'Brien wrote: On Mon, Sep 01, 2003 at 10:00:17AM -0400, Robert Watson wrote: |-+---+-+| | | | | Productionable | | | | | support for the| | | | | AMD64 platform.| | | | | Currently, AMD64 | | | | | runs fully in | | | | | 32-bit emulation | | Tier-1 Support for | In| Peter Wemm, | mode, and boots to | | AMD64 Hammer| progress | David O'Brien | single-user in | | | | | 64-bit mode. We| | | | | expect full| | | | | production support | | | | | for the AMD64 | | | | | architecture in| | | | | 5.2-RELEASE. | |-+---+-+| PLEASE, PLEASE update this. Not implying that FreeBSD/amd64 doesn't make it multiuser and can build its own world would be sufficient. Raising you through the normal channels does not seem to be working at the moment. Please go ahead and update this entry as you see fit. It's in www/en/releases/5.2R. Thanks! Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Syncer "giving up" on buffers
On Mon, 1 Sep 2003, Lefteris Chatzibarbas wrote: > I have a problem with kernels, built the last couple of days, where > during shutdown syncer is "giving up" on buffers. During the next boot > all filesystems are checked because of improper dismount. Here follow > the exact messages I get: > > Waiting (max 60 seconds) for system process `vnlru' to stop...stopped > Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped > Waiting (max 60 seconds) for system process `syncer' to stop...stopped > > syncing disks, buffers remaining... 8 8 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 > giving up on 6 buffers > Uptime: 41m20s > pfs_vncache_unload(): 1 entries remaining > Shutting down ACPI > Rebooting... > > After some testing I found out that this does _not_ happen if I manually > unmount my ext2 filesystems, before shutting down. In this case syncer > finishes without any problems. > > My last kernel which did not have this problem, is the one I built on > Wed Aug 27 23:14:12 EEST 2003. Apparently the bug fixed in ext2fs/fs.h revs 1.3, 1.4 and 1.6 (etc.) was restored in rev.1.14. I think this is because B_LOCKED buffers were ignored in the sync() in boot() and flushed later when vfs_unmountall() calls ext2fs_unmount(), but they are now seen in the sync() so vfs_unmountall() is not called. Rev.1.3 of ext2fs/fs.h (etc.) abuses B_LOCKED to do little more than make the sync() ignore ext2fs's private buffers (its complications are mainly to handle the resulting B_LOCKED buffers). It wants to brelse() the buffers so that their BUF_REFCOUNT() is 0 and the sync() in boot() is happy to handle them. In the original fix, I think the buffers could be B_DELWRI and then the sync() would fulush them, but setting B_DELWRI was wrong and was changed (in rev.1.4) to setting the private flag B_DIRTY instead. Rev.1.13 esssentially removes the brelse() and adds a new complication (BUF_KERNPROC()) and keeps the old ones. I think the BUF_KERNPROC() is less than useful -- without the brelse()'s, the buffers are completely private to the file system. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
Is anyone going to be fixing the sysinstall problem of not being able to re-slice a drive? For those who are not technical whizes this IS a big problem. We do still care about them right? Nicole |\ __ /| (`\ | o_o |__ ) ) // \\ - [EMAIL PROTECTED] - Powered by FreeBSD - -- " Daemons" will now be known as "spiritual guides" -Politically Correct UNIX Page ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
In message <[EMAIL PROTECTED]>, Nicole writes: > > Is anyone going to be fixing the sysinstall problem of not being able to >re-slice a drive? For those who are not technical whizes this IS a big problem. >We do still care about them right? If you are talking about using sysinstall to modify drives in use, then the answer is probably no. For that job you want to use the correct tools: fdisk(8) and bsdlabel(8) (tacitly assuming i386 here). If you are talking about a problem during initial install of FreeBSD you need to provide more details about it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
So are you saying it Will work in single user mode perhaps? (drives in use) or are you saying gee we have this nice new version that if you need to modify any disk slice you did after an install your screwed into going back to caveman tools (which I admit I have NO IDEA how to use and I bet many others don't as well.) I have been using FreeBSD since 1997 and have never HAD to use anything else. Way to win over those Linux users. Nicole On 01-Sep-03 Unnamed Administration sources reported Poul-Henning Kamp said : > In message <[EMAIL PROTECTED]>, Nicole writes: >> >> Is anyone going to be fixing the sysinstall problem of not being able to >>re-slice a drive? For those who are not technical whizes this IS a big >>problem. >>We do still care about them right? > > If you are talking about using sysinstall to modify drives in use, > then the answer is probably no. > > For that job you want to use the correct tools: fdisk(8) and > bsdlabel(8) (tacitly assuming i386 here). > > If you are talking about a problem during initial install of FreeBSD > you need to provide more details about it. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. |\ __ /| (`\ | o_o |__ ) ) // \\ - [EMAIL PROTECTED] - Powered by FreeBSD - -- " Daemons" will now be known as "spiritual guides" -Politically Correct UNIX Page "Witchcraft is in essence the worship of the powers of this world, beautiful and terrible, but all in a circle under the turning sky that is the One." -C.A. Burland, "Echoes of Magic" "Connecting with energy is something humans have to be open to and talking about and expecting, otherwise the whole human race can go back to pretending that life is about power over others and exploiting the planet. If we go back to doing this, then we won't survive." -James Redfield, "The Celestine Prophecy" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /lib symlinks problem?
On Mon, 1 Sep 2003, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Doug Barton <[EMAIL PROTECTED]> writes: > : On Mon, 1 Sep 2003, M. Warner Losh wrote: > : > : > My tool is initially just a 'delete these files' tool, but now that I > : > think about it, it wouldn't be hard to say also 'create these > : > symlinks'. The hard part here is generating the 'obsolete' lists. > : > : I posted one approach to this today... touch a file right before you > : start installworld, then consider anything not newer than that file a > : candidate for disposal. There is currently something weird going on in > : /usr/lib though... a lot of the files don't have newer dates, I haven't > : tracked down why yet. > > No. That's not what I'm talking about. That approach is crap, > because installworld doesn't touch all files. Please tell us how you really feel! :) I have never said that my suggestion was a complete solution to the problem. But it does get you pretty far down the road for any given instance of installworld, without needing to maintain complicated databases of what files have been installed by the system. I would think that using my suggestion in directories where we _do_ touch every file (like *[s]bin) would make your task easier, but since I haven't seen your WIP yet, I'll reserve further comment till I do. > : Also, I highly recommend NOT deleting the files, but moving them > : somewhere. This makes it much easier to recover if you delete something > : you shouldn't have. > > I don't care the method of removal. I care more about the list. If > you want to mv them them instead of rm, it isn't a big deal to change > that detail. Ok, consider this a request to do that then. As suggestions, I currently use two different methods to deal with this. In the after_installworld script I posted, I create an 0ld directory in the same directory as the files I want to back up. I use zero as the first character so it always sorts at the top for easy identification. For mergemaster's -P option, I create /var/tmp/mergemaster/preserved-files-yymmdd-hhmmss, where the time is the time that the run of mergemaster started. Both approaches have merit. For binaries and libs my thinking was that leaving them on the same file system will make it possible to recover if one of the things you happened to mv turned out to be important during mount time/boot time. > The mv /usr/foo -> /usr/foo.old is too dangerous, and I think it is > the wrong way to go. Well, I started doing it for /usr/include and /usr/share/man personally because nothing from either directory is needed for installworld, and I know for a fact that I'm rigorous about not putting any foreign stuff in there. I'm certainly not married to the idea of doing it that way. As I've been saying all along, the stuff I've been posting is little more than Proof of Concept work atm. My goal has been to defeat the inertia surrounded by "we cannot make this work!" by demonstrating one method that does work, albeit imperfectly. The fact that you're moving farther down this road is music to my ears. :) Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Question related to FreeBSD Serial Console...
I have a question related to FreeBSD Serial console, I am aware you can use -Dh for both internal and serial, but is it possible to see the 'kernel' "boot" messages sent on both the serial and the console? It was a question that was asked to me by a client, and after researching it more, it seems that it's not possible. Am i wrong? or did I miss an option that's not documented? Sincerely, Scott M. Likens signature.asc Description: This is a digitally signed message part ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
xl0: reset didn't complete
I am using -CURRENT cvsup'd August 29 and having some problems with a 3com 3c575B PC Card. I am running on a Dell Latitude C600 and -CURRENT has, for the most part, worked perfectly for me. The problem is that the 3Com card is no longer getting activated. The system sees when the card is plugged in and attempts to initialize it, but the initialization always fail with an "xl0 reset didn't complete". I did a quick couple of google searches and grep'd my email folders and didn't turn up anything helpful to me. I will also point out that, unlike Soeren's problems on August 13, wi0 is working just fine for me. Attached are the results of a boot -v, as well as the results from me setting hw.cardbus.debug and hw.pccard.debug to 1. For grins, I have also included my kernel configuration. Sorry for the long email. Any help would be greatly appreciated. Mik boot -v: 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 #0: Fri Aug 29 23:35:14 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BULLET Preloaded elf kernel "/boot/kernel/kernel" at 0xc04af000. Preloaded elf module "/boot/kernel/snd_ess.ko" at 0xc04af1cc. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04af278. Preloaded elf module "/boot/kernel/snd_sbc.ko" at 0xc04af324. Preloaded acpi_dsdt "/boot/acpi_dsdt.aml" at 0xc04af3d0. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04af418. Calibrating clock(s) ... i8254 clock: 1193123 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 751706469 Hz CPU: Intel Pentium III (751.71-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383f9ff real memory = 268283904 (255 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x004d6000 - 0x0fb34fff, 258338816 bytes (63071 pages) avail memory = 255438848 (243 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xc12e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: wlan: <802.11 Link Layer> null: mem: Pentium Pro MTRR support enabled random: ACPI: DSDT was overridden. ACPI-0375: *** Info: Table [DSDT] replaced by host OS npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x8060 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 Using $PIR table, 9 entries at 0xc00fbd70 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded07D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded10A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded10B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded03A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded03B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded08A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded0 16A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded0 16B 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded80A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded81A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded0 13A 0x62 11 embedded0 17A 0x62 11 embedded0 17B 0x62 11 embedded0 17C 0x62 11 embedded0 17D 0x62 11 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 6, width = 4 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.PCI0.LNKA irq 11: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.7.0 \\_SB_.PCI0.LNKB irq 5: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.7.1 \\_SB_.PCI0.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] low,level,sharable 0.7.2 \\_SB_.PCI0.LNKD irq 11: [ 3 4 5 6 7 9 10 1
Re: ACPI problems with Compaq Evo N610c
Doug Barton wrote: > > I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl > > Thanks for the suggestion... I tried that one, but got the same error > about not enough memory to load the override file. > > I attached a verbose dmesg, just in case someone wants to take a look. | ACPI: DSDT was overridden. | -0424: *** Error: UtAllocate: Could not allocate size 50204453 | ACPI-0428: *** Error: Could not allocate table memory for [/* | R] length 50204453 | ACPI-0368: *** Error: Could not copy override ACPI table, AE_NO_MEMORY I'm going to go out on a limb here and suggest that perhaps the problem is that the damn thing appears to be 50 Megabytes... -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problems with Compaq Evo N610c
On Mon, 1 Sep 2003, Terry Lambert wrote: > Doug Barton wrote: > > > I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl > > > > Thanks for the suggestion... I tried that one, but got the same error > > about not enough memory to load the override file. > > > > I attached a verbose dmesg, just in case someone wants to take a look. > > | ACPI: DSDT was overridden. > | -0424: *** Error: UtAllocate: Could not allocate size 50204453 > | ACPI-0428: *** Error: Could not allocate table memory for [/* > | R] length 50204453 > | ACPI-0368: *** Error: Could not copy override ACPI table, AE_NO_MEMORY > > > I'm going to go out on a limb here and suggest that perhaps the > problem is that the damn thing appears to be 50 Megabytes... Well, you could have verified that easily enough for yourself by downloading the file at that URL above. :) It turns out that it's only 142k, which is another reason I think that something very odd is happening. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bsd.lib.mk and bsd.own.mk ignore /etc/make.conf(INSTALL)
On Mon, 1 Sep 2003, Ian Freislich wrote: > Hi > > Any idea why '-C' is hard coded for bsd.lib.mk and bsd.own.mk? I > thought that the make.conf variable was there to allow or disallow > this. The following comes from bsd.lib.mk: I'd also like to see this option be a knob, preferably defaulting to without -C. Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: need some debugging help
Pawel Jakub Dawidek wrote: > On Mon, Sep 01, 2003 at 12:48:41AM -0600, Kenneth D. Merry wrote: > +> - I tried just holding a mutex all the time, but obviously you can't > +>malloc while holding a mutex (except Giant), and the sysctl code does a > +>number of mallocs. (The original cause of this problem -- M_WAITOK > +>mallocs.) > > I've proposed some time ago changing M_WAITOK to M_NOWAIT, because > function/macros responsible for sysctl creation could failed from other > reasons, so I don't see any reason why they couldn't fail because of > insufficient memory. Caller is obliged to check return value... M_WAITOK is obliged to wait for fricking ever if it can't allocate the memory, rather than failing and returning a NULL pointer that then gets dereferenced because the function returned when the code expected the traditional M_WAITOK semantics. In other words, this problem derives from a semantics change, not from any actual bug. If you don't like it, then you need to change every instance of a call to malloc with M_WAITOK to check its return value before using it. Doing this does'nt require introducing yet another semantic. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /lib symlinks problem?
In message: <[EMAIL PROTECTED]> Doug Barton <[EMAIL PROTECTED]> writes: : On Mon, 1 Sep 2003, M. Warner Losh wrote: : > In message: <[EMAIL PROTECTED]> : > Doug Barton <[EMAIL PROTECTED]> writes: : > : On Mon, 1 Sep 2003, M. Warner Losh wrote: : > : > My tool is initially just a 'delete these files' tool, but now that I : > : > think about it, it wouldn't be hard to say also 'create these : > : > symlinks'. The hard part here is generating the 'obsolete' lists. : > : : > : I posted one approach to this today... touch a file right before you : > : start installworld, then consider anything not newer than that file a : > : candidate for disposal. There is currently something weird going on in : > : /usr/lib though... a lot of the files don't have newer dates, I haven't : > : tracked down why yet. : > : > No. That's not what I'm talking about. That approach is crap, : > because installworld doesn't touch all files. : : Please tell us how you really feel! :) Maybe I was a little strong in what I said. : I have never said that my : suggestion was a complete solution to the problem. But it does get you : pretty far down the road for any given instance of installworld, without : needing to maintain complicated databases of what files have been : installed by the system. We need to keep some database. Either incrementally as we go, so that we know all that belongs in certain directories (which is risky because some third party software installs stuff into them), or we need to keep track of what we've shipped in the past so we can remove it when it is obsolete. Your solution kills the ability to keep old libraries around in /usr/lib/compat, for example, without freshly installing them every time. : I would think that using my suggestion in directories where we _do_ : touch every file (like *[s]bin) would make your task easier, but since I : haven't seen your WIP yet, I'll reserve further comment till I do. Right now it is a set of tools that can be used to build a database of files that FreeBSD used to have, but doesn't any more. This is the most conservative approach that we can take. Given the unknown nature of most systems, I think we need to be conservative here. Also, it doesn't move things out of the way in such a way that's hard to recover from should things go wrong in the middle somewhere. This list of files can be moved or removed, that nit doesn't really matter and is really an uninteresting part of the problem: let the user decide. The hard part is coming up with this list. : > The mv /usr/foo -> /usr/foo.old is too dangerous, and I think it is : > the wrong way to go. : : Well, I started doing it for /usr/include and /usr/share/man personally : because nothing from either directory is needed for installworld, and I : know for a fact that I'm rigorous about not putting any foreign stuff in : there. I'm certainly not married to the idea of doing it that way. /usr/include isn't too bad, and /usr/share/man is obviously completely safe since the man pages are available on the web and assuming no third party software. /usr/lib is very dangerous and can result in weird things happening, especially for the case where something bad happens while installworld is running. : As I've been saying all along, the stuff I've been posting is little : more than Proof of Concept work atm. My goal has been to defeat the : inertia surrounded by "we cannot make this work!" by demonstrating one : method that does work, albeit imperfectly. The fact that you're moving : farther down this road is music to my ears. :) Yes. I hope to have something by BSDcon to show to people. Work has kept me busier than I'd have liked, and the remaining time has been soaked up by getting NEWCARD in better shape for 5.2. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /lib symlinks problem?
"M. Warner Losh" wrote: > In message: <[EMAIL PROTECTED]> > Doug Barton <[EMAIL PROTECTED]> writes: > : I posted one approach to this today... touch a file right before you > : start installworld, then consider anything not newer than that file a > : candidate for disposal. There is currently something weird going on in > : /usr/lib though... a lot of the files don't have newer dates, I haven't > : tracked down why yet. > > No. That's not what I'm talking about. That approach is crap, > because installworld doesn't touch all files. > > : Also, I highly recommend NOT deleting the files, but moving them > : somewhere. This makes it much easier to recover if you delete something > : you shouldn't have. > > I don't care the method of removal. I care more about the list. If > you want to mv them them instead of rm, it isn't a big deal to change > that detail. You are going to need to generate the list from a clean install. You will either need to register things into the package system (the cleanest approach) or generate an mtree with MD5's, and that a huge hit scanning the system for changes. It'd be fairly easy to compare deltas between such files, but it would be cleaner if all subsequent systems installed as packages, and the package version amangement could be used. For the first system that does this, all you'd need to do is dump the package packing list files into the place pkg_add would have dumped them, had you actually installed a package (it won't care that there's not a "real" package, when you go to upgrade). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problems with Compaq Evo N610c
Doug Barton wrote: > On Mon, 1 Sep 2003, Terry Lambert wrote: > > > I attached a verbose dmesg, just in case someone wants to take a look. > > > > | ACPI: DSDT was overridden. > > | -0424: *** Error: UtAllocate: Could not allocate size 50204453 > > | ACPI-0428: *** Error: Could not allocate table memory for [/* > > | R] length 50204453 > > | ACPI-0368: *** Error: Could not copy override ACPI table, AE_NO_MEMORY > > > > I'm going to go out on a limb here and suggest that perhaps the > > problem is that the damn thing appears to be 50 Megabytes... > > Well, you could have verified that easily enough for yourself by > downloading the file at that URL above. :) And getting 50M, if your dmesg was right... 8-) 8-). > It turns out that it's only 142k, which is another reason I think > that something very odd is happening. My guesses, in order, would be (1) an unitialized variable, or (2) it loads sparsely, or (3) it has a really bogus table entry that claims it needs that much memory. It doesn't look magic enough to be a sign extension/signed-unsigned pun error. Other than starting at the code that's supposed to load the table in, and printf'ing until you find out why it's thinks 50M is a nuce number, I don't know what to tell you... -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone ported HCF/HSF modem drivers to FreeBSD?
Daniel O'Connor wrote: > On Monday 01 September 2003 08:41, Mark Kettenis wrote: > >I asked this on -hackers a little while ago but no response. I'm > > curious if anyone has made an attempt to port these Winmodem drivers. > >http://www.linuxant.com/drivers/ > > > > I did look into it, but concluded that it was pretty hopeless. For > > starters, the DSP routines in there seem to need the FPU, and FreeBSD > > doesn't seem to allow that in the kernel. Apart from that, almost > > I don't think that would be _that_ hard to fix at least for that specific > driver, but I'm not 100% sure. I ported the HCF driver for use on my Sony VAIO, a while back, and the author of the thing was kind enough to compile it as PIC so that I could load it as a kernel module. The FPU stuff is pretty embedded; without disassembling, changing, and reassembling the code, which is prohibited by the license, there's really no way to yank the FPU stuff out. So you have to change the lazy FPU context switching, to enable use of the FPU inside the kernel. Which really blows, on many levels. > > 100% of the code is in the binary-only modules, including a lot of > > Linux-specific code, which makes it very hard to see how the code is > > supposed to interface with the kernel. > > Have you seen these drivers -> > http://www.smlink.com/main/index1.php?ln=en&main_id=32 No good for the HCF modems. > And the binary code appears to only call shim routines for which the source is > available. The HCF drivers have threading and timer code dependencies. They also have an expectation of being able to import symbols from the Linux kernel (though most of them actually use a jump-table via a registration function that you pass a structure to). The main problem I ran into was the FPU code; the next main problem was the PIC code (as I said, though, the author was willing to go PIC on the code, and I believe that's still how it's now distributed for Linux). The next main problem was emulating enough of the Linux kernel environment to pass glue functions down to the modem (and the big mess there was interval timers -- the driver tends to use a lot of CPU time). I would really recommend what I ended up doing, which is leaving the FPU code along and using a real modem in a PCMCIA slot, instead. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
current: network collition increase
Hi. I noticed that network collition increase, in log of 7/26. Such still a state continues. What became like this owing to? 5.1-CURRENT-20030720 (daily run 7/26): Network interface status: NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll dc01500 00:90:cc:a2:59:56 38342027 441061 0 260568 dc01500 192.168.200 * 374698 - 431325 - - dc11500 00:c0:ca:10:91:89 190866 0 136617 4124 70128 5.1-CURRENT-20030713 (daily run 7/17): Network interface status: NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll dc01500 00:90:cc:a2:59:5656144 364299 0 0 dc01500 192.168.200 *27732 -23965 - - dc11500 00:c0:ca:10:91:8963447 046153 054 dc0: port 0xa000-0xa07f mem 0xe580-0xe580007f irq 4 at device 10.0 on pci0 dc0: Ethernet address: 00:c0:ca:10:91:8c miibus0: on dc0 dcphy0: on miibus0 dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: port 0x9400-0x947f mem 0xe400-0xe47f irq 3 at device 13.0 on pci0 dc1: Ethernet address: 00:c0:ca:10:91:89 miibus1: on dc1 dcphy1: on miibus1 dcphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: flags=8843 mtu 1500 inet 192.168.200.1 netmask 0xff00 broadcast 192.168.200.255 inet6 fe80::2c0:caff:fe10:918c%dc0 prefixlen 64 scopeid 0x1 ether 00:c0:ca:10:91:8c media: Ethernet autoselect (100baseTX ) status: active dc1: flags=8843 mtu 1500 inet6 fe80::2c0:caff:fe10:9189%dc1 prefixlen 64 scopeid 0x2 ether 00:c0:ca:10:91:89 media: Ethernet autoselect (10baseT/UTP) status: active ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question related to FreeBSD Serial Console...
On Sep 1, 2003, at 2:47 PM, Scott M. Likens wrote: I have a question related to FreeBSD Serial console, I am aware you can use -Dh for both internal and serial, but is it possible to see the 'kernel' "boot" messages sent on both the serial and the console? If your BIOS supports serial port redirection you can do GRUB over serial :) I used to. I don't know that FreeBSD can run its serial driver before its kernel that loads the driver is loaded. [got that? I didn't :)] Of course the boot loader could always support it right? It was a question that was asked to me by a client, and after researching it more, it seems that it's not possible. Am i wrong? or did I miss an option that's not documented? Sincerely, Scott M. Likens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO
On 01-Sep-03 Unnamed Administration sources reported Marc G. Fournier said : > > > On Mon, 1 Sep 2003, Nicole wrote: > >> >> So are you saying it Will work in single user mode perhaps? (drives in use) >> >> or are you saying gee we have this nice new version that if you need to >> modify any disk slice you did after an install your screwed into going >> back to caveman tools (which I admit I have NO IDEA how to use and I bet >> many others don't as well.) > > Ummm ... if you are talking about something that I just went through, why > can't you just boot up off the floppies and do the reconfig from there? Well Server not even in same city as I am would be a start. I thought detrimeatures were more a MS thing. "You didn't really NEED that feature did you.. there is a way around it, but you need our $$ training course then." You want to compete with Linux and Solaris who has all the nice friendly features and now its ok to eliminate them and make someones job require on-site visits and downbooting to floppies? Hellooo?? Nicole |\ __ /| (`\ | o_o |__ ) ) // \\ - [EMAIL PROTECTED] - Powered by FreeBSD - -- " Daemons" will now be known as "spiritual guides" -Politically Correct UNIX Page "Witchcraft is in essence the worship of the powers of this world, beautiful and terrible, but all in a circle under the turning sky that is the One." -C.A. Burland, "Echoes of Magic" "Connecting with energy is something humans have to be open to and talking about and expecting, otherwise the whole human race can go back to pretending that life is about power over others and exploiting the planet. If we go back to doing this, then we won't survive." -James Redfield, "The Celestine Prophecy" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO -2
BTW - I do thank you Marc for your advice. I know you were trying to assist. It just drives me crazy when important things get broken and people act like.. What the big deal. I don't need it why should you? I still have not solved the going to comsonsole mode if there is no keyboard detected crap, new "feature". Yea great for those who could benifit from it.. But I have YET to have one person be able to show me how to STOP it from doing that. Why??? gosh why?? Becouse I don't want serial console and I don't have a keyboard on every server. So if I walk into the datacenter and try to access a server that has been rebooted.. I'm screwed! I have to ssh from some other server that has not been rebooted and if I NEED console.. then I have to reb oot the server. That detrimeature still has me pissed and the people I do work for scratching their head wanting to know why I install such a "broken" OS. They don't know and can't directly see the good things... managers and clients can only see it when you have to strugle to do something that should not be so obtuse. Nicole On 01-Sep-03 Unnamed Administration sources reported Marc G. Fournier said : > > > On Mon, 1 Sep 2003, Nicole wrote: > >> >> So are you saying it Will work in single user mode perhaps? (drives in use) >> >> or are you saying gee we have this nice new version that if you need to >> modify any disk slice you did after an install your screwed into going >> back to caveman tools (which I admit I have NO IDEA how to use and I bet >> many others don't as well.) > > Ummm ... if you are talking about something that I just went through, why > can't you just boot up off the floppies and do the reconfig from there? |\ __ /| (`\ | o_o |__ ) ) // \\ - [EMAIL PROTECTED] - Powered by FreeBSD - -- " Daemons" will now be known as "spiritual guides" -Politically Correct UNIX Page "Witchcraft is in essence the worship of the powers of this world, beautiful and terrible, but all in a circle under the turning sky that is the One." -C.A. Burland, "Echoes of Magic" "Connecting with energy is something humans have to be open to and talking about and expecting, otherwise the whole human race can go back to pretending that life is about power over others and exploiting the planet. If we go back to doing this, then we won't survive." -James Redfield, "The Celestine Prophecy" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question related to FreeBSD Serial Console...
Scott M. Likens wrote: I have a question related to FreeBSD Serial console, I am aware you can use -Dh for both internal and serial, but is it possible to see the 'kernel' "boot" messages sent on both the serial and the console? It was a question that was asked to me by a client, and after researching it more, it seems that it's not possible. Am i wrong? or did I miss an option that's not documented? Sincerely, Scott M. Likens I'm a little confused by your request, but maybe adding the following line to /boot/loader.conf will get what you want? console="comconsole" There is also a way to get the console directed to both the video and serial at the same time, but I've forgotten the magic and can't find it at the moment. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question related to FreeBSD Serial Console...
On 01-Sep-03 Unnamed Administration sources reported Scott Long said : > Scott M. Likens wrote: >> I have a question related to FreeBSD Serial console, >> >> I am aware you can use -Dh for both internal and serial, but is it >> possible to see the 'kernel' "boot" messages sent on both the serial and >> the console? >> >> It was a question that was asked to me by a client, and after >> researching it more, it seems that it's not possible. >> >> Am i wrong? or did I miss an option that's not documented? >> >> Sincerely, >> >> Scott M. Likens >> >> > > I'm a little confused by your request, but maybe adding the following > line to /boot/loader.conf will get what you want? > > console="comconsole" > > There is also a way to get the console directed to both the video and > serial at the same time, but I've forgotten the magic and can't find it > at the moment. Heh magic is the right word ;) According to what I have found it is supposed to be: console="vidconsole" To make it still choose internal console even if it does not find a keyboard present at boot time. So you can walk up later and connect a keyboard and have it work. Everytime I asked on the lists I got.. Oh go look here for the answer. Which I had.. to which I got, oh well the answers in there.. No one ever was able to say DO THIS. Let alone anyone saying do this and have it work :( If you find the Magic please do let me know :) Nicole > Scott > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" |\ __ /| (`\ | o_o |__ ) ) // \\ - [EMAIL PROTECTED] - Powered by FreeBSD - -- " Daemons" will now be known as "spiritual guides" -Politically Correct UNIX Page "Witchcraft is in essence the worship of the powers of this world, beautiful and terrible, but all in a circle under the turning sky that is the One." -C.A. Burland, "Echoes of Magic" "Connecting with energy is something humans have to be open to and talking about and expecting, otherwise the whole human race can go back to pretending that life is about power over others and exploiting the planet. If we go back to doing this, then we won't survive." -James Redfield, "The Celestine Prophecy" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question related to FreeBSD Serial Console...
My notes on getting a serial console at 115200 -must be com1 -com1 must be at port 0x3F8 irq 4 -in bios set the port and irq as above -in bios set serial redirection to com1 -in bios set baud rate 115200 -in bios set RTS/CTS flow control -edit (or create) /etc/make.conf to add these lines: BOOT_COMCONSOLE_PORT= 0x3F8 BOOT_COMCONSOLE_SPEED= 115200 -cd /sys/boot -make clean -make -make install -fdisk -B No im not kidding. Part of the boot knowing baud rate loader lives in the main disk boot block. -cd /boot -edit loader.conf -add a line: console=comconsole -edit /boot.config make it read (with a return after it): -Dh (the above is minus D h return, thats 4 characters) -cd /usr/src/sys/i386/conf -edit PASODOBLE (or whatever your kernconf is called) -add: options CONSPEED=115200 # Console Redirection -cd /usr/src -make buildkernel KERNCONF=PASODOBLE -make installkernel KERNCONF=PASODOBLE -reboot -pray ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question related to FreeBSD Serial Console...
Aaron Wohl wrote: My notes on getting a serial console at 115200 -must be com1 -com1 must be at port 0x3F8 irq 4 -in bios set the port and irq as above -in bios set serial redirection to com1 -in bios set baud rate 115200 -in bios set RTS/CTS flow control -edit (or create) /etc/make.conf to add these lines: BOOT_COMCONSOLE_PORT= 0x3F8 BOOT_COMCONSOLE_SPEED= 115200 -cd /sys/boot -make clean -make -make install -fdisk -B No im not kidding. Part of the boot knowing baud rate loader lives in the main disk boot block. -cd /boot -edit loader.conf -add a line: console=comconsole -edit /boot.config make it read (with a return after it): -Dh (the above is minus D h return, thats 4 characters) -cd /usr/src/sys/i386/conf -edit PASODOBLE (or whatever your kernconf is called) -add: options CONSPEED=115200 # Console Redirection -cd /usr/src -make buildkernel KERNCONF=PASODOBLE -make installkernel KERNCONF=PASODOBLE -reboot -pray At one time I was working on patches to the loader to make the console speed configurable. At the time, at least, I didn't see any evidence that the settings were stored in the boot0 block, but maybe I was wrong. In any case, finishing this up is on my TODO list. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question related to FreeBSD Serial Console...
*SIGH* No what I want is NO serial console. DO NOT FOR ANY REASON turn off/not resp ond to the keyboard port Nicole On 01-Sep-03 Unnamed Administration sources reported Scott Long said : > Aaron Wohl wrote: >> My notes on getting a serial console at 115200 >> >> -must be com1 >> -com1 must be at port 0x3F8 irq 4 >> -in bios set the port and irq as above >> -in bios set serial redirection to com1 >> -in bios set baud rate 115200 >> -in bios set RTS/CTS flow control >> -edit (or create) /etc/make.conf to add these lines: >> BOOT_COMCONSOLE_PORT= 0x3F8 >> BOOT_COMCONSOLE_SPEED= 115200 >> -cd /sys/boot >> -make clean >> -make >> -make install >> -fdisk -B >> No im not kidding. Part of the boot knowing baud rate loader lives in >> the main disk boot block. >> -cd /boot >> -edit loader.conf >> -add a line: >> console=comconsole >> -edit /boot.config make it read (with a return after it): >> -Dh >> (the above is minus D h return, thats 4 characters) >> -cd /usr/src/sys/i386/conf >> -edit PASODOBLE (or whatever your kernconf is called) >> -add: >> options CONSPEED=115200 # Console Redirection >> -cd /usr/src >> -make buildkernel KERNCONF=PASODOBLE >> -make installkernel KERNCONF=PASODOBLE >> -reboot >> -pray >> > > > At one time I was working on patches to the loader to make the console > speed configurable. At the time, at least, I didn't see any evidence > that the settings were stored in the boot0 block, but maybe I was wrong. > In any case, finishing this up is on my TODO list. > > Scott > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" |\ __ /| (`\ | o_o |__ ) ) // \\ - [EMAIL PROTECTED] - Powered by FreeBSD - -- " Daemons" will now be known as "spiritual guides" -Politically Correct UNIX Page "Witchcraft is in essence the worship of the powers of this world, beautiful and terrible, but all in a circle under the turning sky that is the One." -C.A. Burland, "Echoes of Magic" "Connecting with energy is something humans have to be open to and talking about and expecting, otherwise the whole human race can go back to pretending that life is about power over others and exploiting the planet. If we go back to doing this, then we won't survive." -James Redfield, "The Celestine Prophecy" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Question related to FreeBSD Serial Console...
On Sep 1, 2003, at 6:36 PM, Nicole wrote: *SIGH* No what I want is NO serial console. DO NOT FOR ANY REASON turn off/not resp ond to the keyboard port -Dh means both keyboard and serial console... what's the problem? And please stop shouting. Dave Nicole On 01-Sep-03 Unnamed Administration sources reported Scott Long said : Aaron Wohl wrote: My notes on getting a serial console at 115200 -must be com1 -com1 must be at port 0x3F8 irq 4 -in bios set the port and irq as above -in bios set serial redirection to com1 -in bios set baud rate 115200 -in bios set RTS/CTS flow control -edit (or create) /etc/make.conf to add these lines: BOOT_COMCONSOLE_PORT= 0x3F8 BOOT_COMCONSOLE_SPEED= 115200 -cd /sys/boot -make clean -make -make install -fdisk -B No im not kidding. Part of the boot knowing baud rate loader lives in the main disk boot block. -cd /boot -edit loader.conf -add a line: console=comconsole -edit /boot.config make it read (with a return after it): -Dh (the above is minus D h return, thats 4 characters) -cd /usr/src/sys/i386/conf -edit PASODOBLE (or whatever your kernconf is called) -add: options CONSPEED=115200 # Console Redirection -cd /usr/src -make buildkernel KERNCONF=PASODOBLE -make installkernel KERNCONF=PASODOBLE -reboot -pray At one time I was working on patches to the loader to make the console speed configurable. At the time, at least, I didn't see any evidence that the settings were stored in the boot0 block, but maybe I was wrong. In any case, finishing this up is on my TODO list. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" |\ __ /| (`\ | o_o |__ ) ) // \\ - [EMAIL PROTECTED] - Powered by FreeBSD - -- " Daemons" will now be known as "spiritual guides" -Politically Correct UNIX Page "Witchcraft is in essence the worship of the powers of this world, beautiful and terrible, but all in a circle under the turning sky that is the One." -C.A. Burland, "Echoes of Magic" "Connecting with energy is something humans have to be open to and talking about and expecting, otherwise the whole human race can go back to pretending that life is about power over others and exploiting the planet. If we go back to doing this, then we won't survive." -James Redfield, "The Celestine Prophecy" ___ [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: /lib symlinks problem?
On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote: > > Now it looks like this: > > install -C -o root -g wheel -m 444 libalias.a /foo/usr/lib > install -s -o root -g wheel -m 444 libalias.so.4 /foo/lib > ln -fs libalias.so.4 /foo/lib/libalias.so > ln -fs /lib/libalias.so.4 /foo/usr/lib/libalias.so > > This is also consistent with how we handle SYMLINKS: > > # make -f bsd.prog.mk BINDIR=/bin SYMLINKS='${BINDIR}/file1 ${BINDIR}/file2' install > DESTDIR=/foo > /foo/bin/file2 -> /bin/file1 > # ls -l /foo/bin > total 0 > lrwxr-xr-x 1 root wheel 10 Aug 31 17:44 file2 -> /bin/file1 This *really* breaks the build-tools part, which is why I made it a relative symlink in the first place. -gordon pgp0.pgp Description: PGP signature
Re: /lib symlinks problem?
On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote: > On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote: > > > > I might be missing an obvious, but I just don't see a reason > > > > why we should use relative linking here: we should just link > > > > to where we really install. With the attached patch, I get: > ... > > +.if ${LIBDIR} != ${SHLIBDIR} > > + ln -fs ${SHLIBDIR}/${SHLIB_NAME} ${DESTDIR}${LIBDIR}/${SHLIB_LINK} > > Why are we making *any* symlinks here?? It was before we corrected ld(1) to look in /lib. I'm happy with removing them now that it has been corrected. -gordon pgp0.pgp Description: PGP signature
.fsck_snapshot file
I have a file .fsck_snapshot in /usr (of 7 GB ?!) -r 1 root wheel 7220781056 Aug 22 18:08 .fsck_snapshot I hope I can delete it without consequences (after chmod'ing it of course :-) -- Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.2-RELEASE TODO -2
On Mon, 1 Sep 2003, Scott Long wrote: > Device flags are not specified in the kernel config anymore unless you > try really, really hard. /etc/device.hints is the correct place to > adjust this flag. Yeah, I was looking at the kernel config on the wrong box. This flag did used to be in GENERIC, so it's worth double-checking the kernel config anyway just to be sure, but it should definitely be updated in /boot/device.hints if it's there. Sorry for the confusion, Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng detection issues
It seems Petri Helenius wrote: > > I also noticed that earlier ATAng spits out these messages; (cut&pasting boot -v > is a little tedious, but I can copy it all if it helps) > > The err=0x01 caught my eye. Err=0x01 is actually "OK Im' there" signal from an ATA device :) What I need to know is if the probe find all it should or not. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng raid not being detected
It seems Petri Helenius wrote: > ATAng does not seem to detect my RAID set, while ATAold boots it > fine, first boot -v with ATAng kernel and then ATAold. > > Any ideas if raid configs should be compatible between them? Should > make sense that they are so people upgrading don't get burned... Do you have device ataraid in your config file ? (se UPDATING) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"