Re: b_to_q to a clist with no reserved cblocks
I don't know exactly what causes the b_to_q message. It is most likely a race in close. You can first-open tty's that are blocked in last-close, and having this open succeed is very important for unblocking the close usi9ng comcontrol /dev/foo drainwait small, but the tty system doesn't seem to do nearly enough to handle races here. It happened to me on shutdown, with a serial console. Mar 15 00:58:10 stash reboot: rebooted by fenner panic: b_to_q to a clist with no reserved cblocks. Debugger(panic) Stopped at Debugger+0x40: xorl%eax,%eax db t Debugger(c03ebb5b) at Debugger+0x40 panic(c03f18c0) at panic+0x70 b_to_q(c7f9bb14,35,c1361a38,0,c7f9bcc8) at b_to_q+0x35 ttwrite(c1361a00,c7f9bcc8,20011,c04b5e80,c7f9bbb4) at ttwrite+0x34c siowrite(c04b5e80,c7f9bcc8,20011,c04b5e80,c7f9bb80) at siowrite+0x78 cnwrite(c04b63d0,c7f9bcc8,20011,c04b63d0,35) at cnwrite+0x74 spec_write(c7f9bc20,c7f9bc34,c02b0c23,c7f9bc20,35) at spec_write+0x5d spec_vnoperate(c7f9bc20,35,c7615500,0,11) at spec_vnoperate+0x15 vn_write(c1392b40,c7f9bcc8,c0a8c980,0,c7615500) at vn_write+0x19f writev(c7615500,c7f9bd20,8054000,bfbfef64,bfbfef34) at writev+0x19a syscall(2f,2f,bfbf002f,bfbfef34,bfbfef64) at syscall+0x278 syscall_with_err_pushed() at syscall_with_err_pushed+0x1b --- syscall (121, FreeBSD ELF, writev), eip = 0x280aae73, esp = 0xbfbfe960, ebp = 0xbfbfe9cc --- I have a dump, if it'd help. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: gcc -O broken in CURRENT
2) Bug is in os delivered gcc but not in port gcc. a) port has more or less patches / os gcc has been modified -- Didn't someone told they are the same? b) other options were set at compile time -- Why dont change to the same in the port? Leads it to a broken world? If the only difference is the lost of binary compatibility, i would say, ok... do it now and we'll need to compile or ports... SOme bugs are related to the FreeBSD use of setjmp/longjmp to do exception unwinding rather than using the DWARF primitives. When you change the toolchain, you change the exception unwinding code when you use the ports version. You also introduce incompatabilities with the installed libstdc++ library, which uses the setjmp/longjmp exception unwinding, which will be in conflict with any exception throwing/handling code compiled with the ports compiler that uses the DWARF2 version. The tests that show it working with the ports version do not test anything other than bare-bones operation, without testing code interoperability eith vendor libraries. Does that clear things up for you? A little bit... most of you argumenting about binary incompatibility for -stable. OK... no chance to do it there, its my opinion too. But why not doing it for current and using that most common dwarf unwinding now (for a later ia64 port it should be faster than setjump i think). Okay everything needs a recompile but this -current is current and not a production os. You're right that we need a patch for -stable. But if we take the approach for -current maybe we leave these problems behind us and following the path of the rank and file (using dwarf2) and making profit of their experience versus doing this ourself and creating patches. -Original Message- From: David O'Brien [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 14, 2002 7:16 PM To: Jan Stocker Cc: Alexander Kabaev; Martin Blapp; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: gcc -O broken in CURRENT On Thu, Mar 14, 2002 at 06:36:05PM +0100, Jan Stocker wrote: 2) Bug is in os delivered gcc but not in port gcc. a) port has more or less patches / os gcc has been modified -- Didn't someone told they are the same? Port has less patches. If you look at /usr/src/contrib/gcc/contrib/freebsd.h and /usr/src/contrib/gcc/contrib/i386/freebsd.h you will see how much things have to be modified because we support dual ELF/a.out [still]. This may be changed too for 5.0 shouldnt it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
duplicate lock message on boot
Hi All, Has anybody seen this message before? CPU: Pentium III/Pentium III Xeon/Celeron (595.58-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA T,PSE36,MMX,FXSR,SSE real memory = 134152192 (131008K bytes) avail memory = 125829120 (122880K bytes) acquiring duplicate lock of same type: thrd_sleep 1st @ ../../../vm/vm_map.c:2288 2nd @ ../../../vm/vm_kern.c:172 It's a 5.0-CURRENT from Fri Mar 15 01:14:08 JST 2002 Thanks, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI autoload failed -- unable to install
With apologies for an incomplete report, I am including the (manually
transcribed) dump information. I have been able to network boot from a
combination of the boot.flp and bin distribution (though there are
problems with getting sysinstall to find disks that prevent that approach
so far) and confirm that the hw.pcic interrupt routing sysctls *are*
required. So the report that follows is based on using floppies from
5.0-20020314-CURRENT, including the one referred to as 'acpi.ko.flp' in
the Failed workaround description below.
To reproduce, follow the steps 1-7 outlined below. The tail end of the
process appears as:
OK load acpi.ko
/boot/kernel/acpi.ko text=0x2b5a0 data=0x1558+0x6cc
syms=[0x4+0x4ed0+0x4+0x675a]
OK boot
/
int=0006 err= efl=00010006 eip=c03069f0
eax=0001 ebx=009aec00 ecx= edx=0102
esi=009ae000 edi=009b6000 ebp= esp=c09b1d98
cs=0008 ds=0010 es=0010fs=0010 gs=0010 ss=0010
cs:eip=ff ff ff 83 ec 18 57 ff-ff a1 84 15 37 c0 a3 0c
77 38 c0 a1 88 15 37 c0-a3 e4 77 38 c0 05 a0 1d
ss:esp=04 94 12 c0 00 60 9b 00-00 e0 9a 00 00 00 00 00
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
BTX halted
I am willing to try reasonable steps and debugging here. Unfortunately,
the BIOS driving the USB floppy seems to take about 10 min. to read a
floppy, so it testing multiple scenarios is somewhat painful. I will be
working with bootable CD configurations today, though the iLINK
(IEEE-1394) connection there has its own share of problems (no non-BIOS
support of the drive). At least with floppies, it *should* be a supported
configuration. (Note however the reported issues with fixit only being
mountable from /dev/fd0, not /dev/da0).
Jeff
On Thu, 14 Mar 2002, Jeff Kletsky wrote:
Date: Thu, 14 Mar 2002 18:49:35 -0800 (PST)
From: Jeff Kletsky [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: ACPI autoload failed -- unable to install (fwd)
Tried the obvious -- manually loading acpi.ko -- still fails
On Thu, 14 Mar 2002, Jeff Kletsky wrote:
Date: Thu, 14 Mar 2002 17:41:01 -0800 (PST)
From: Jeff Kletsky [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: ACPI autoload failed -- unable to install
Having been unable to confirm a complete and proper installation of
5.0-CURRENT on my Sony PCG-SRX7/EP (similar to SRX77) laptop using the
4.5-RELEASE installer, I have made a bootable CD from
5.0-20020313-CURRENT, as well as floppies from 5.0-20020314-CURRENT.
Both exhibit the same set of symptoms.
[...]
Results in:
ACPI autoload failed - no such file or directory
-
[dump followed]
Failed workaround:
1) Create floppies using dd
2) Make another copy of the mfsroot floopy,
mount /dev/fd0 /mnt
rm -rf /mnt/*
mkdir -p /mnt/boot/kernel
copy acpi.ko to /mnt/boot/kernel
### Note that copying to root of floppy fails on load attempt ###
### This is inconsistent with the loader (8) manpage in 5.0 ###
umount /mnt
3) Boot from kern.flp
4) Load mfsroot.flp
5) Interrupt boot process
set hw.pcic.intr_path=1
set hw.pcic.irq=0
6) Remove mfsroot.flp, insert 'acpi.ko.flp'
load acpi.ko
('boot'ing here causes the BTX to halt if the acpi.ko.flp is still
in the drive)
7) Remove acpi.ko.flp, insert mfsroot.flp
boot
...and watch the BTX halt
Jeff
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
Jan Stocker wrote: [ ... DWARF vs. setjmp/longjmp ... ] A little bit... most of you argumenting about binary incompatibility for -stable. OK... no chance to do it there, its my opinion too. But why not doing it for current and using that most common dwarf unwinding now (for a later ia64 port it should be faster than setjump i think). Okay everything needs a recompile but this -current is current and not a production os. You're right that we need a patch for -stable. But if we take the approach for -current maybe we leave these problems behind us and following the path of the rank and file (using dwarf2) and making profit of their experience versus doing this ourself and creating patches. I guess it's possible to change over entirely. That would mean we would loase a.out support because the GNU tools are becoming incapable of supporting a.out (all machines we run on are Linux machines syndrome). If we really wanted to avoid problems like this in the future, we'd just scrap FreeBSD entirely, and go to Linux, a bit at a time, starting with ELF, then DWARF2 exceptions, and then the Linux ABI instead of the FreeBSD ABI, and then all of Linux, a piece at a time. PS: If I sound annoyed, it's because it's sometimes annoying to have your toolchain controlled by someone with an interest in a product that competes with yours; that works for people competing with Microsoft products on Microsoft platforms with a need to use Microsoft tools, and it applies to Cygnus being owned by RedHat and them controlling the FreeBSD tools. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
On Thu, Mar 14, 2002 at 05:54:40PM -0800, Alex Zepeda wrote: As far as Qt goes, rip out that objprelink crap. Without it Qt will build and work just fine. At least Qt 3.whatever works for me. I don't know why objprelink isn't working correctly for Qt, but I don't really care. For me disabling WITNESS does more than enough to make KDE useable on my -current box (2xP2-450). Um.. objprelink is disabled if OSVERSION = 500029. So it is already ripped out for -current. -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preparing innocent users for -current
Doug Barton [EMAIL PROTECTED] writes: 1. phk malloc debugging flags enabled by default. Solutions include recompiling apps, and toggling things off in /etc/malloc.conf. No recompiling needed; if you don't like the default options, just # ln -s aj /etc/malloc.conf 2. pam modules break backwards compatibility with pam apps compiled on RELENG_4. The only solution I've been offered is to recompile things (or, my preferred solution, don't use pam). Wrong. PAM modules are now versioned, and old (unversioned) modules will not be clobbered. We might want to put the old libpam and modules in COMPAT_4X though. 3. xconsole causes periodic panics. The problem (according to BDE) is a well-know bug in printf(9), caused by The TIOCCONS ioctl ... panics when printf() is called while sched_lock is held. I reported this bug in October 2001, if anyone wants to look through the archives. Ages-old, very difficult to fix. Just don't use xconsole. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
On Fri, Mar 15, 2002 at 01:37:39PM +0100, Jan Stocker wrote: A little bit... most of you argumenting about binary incompatibility for -stable. OK... no chance to do it there, its my opinion too. But why not doing it for current and using that most common dwarf unwinding now (for a There is no need to cause developers to go thru several ABI changes such that they cannot get their other FreeBSD development done. With GCC 3.1 a number of ABI changes will happen. Port has less patches. If you look at /usr/src/contrib/gcc/contrib/freebsd.h and /usr/src/contrib/gcc/contrib/i386/freebsd.h you will see how much things have to be modified because we support dual ELF/a.out [still]. This may be changed too for 5.0 shouldnt it? Why? I don't see how you justfied removing the functionality and I don't see how it is causing you any problems being there. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Problem booting FreeBSD a SYM53C896 SCSI controller.
I have installed current on a sym53c896 scsi controller but can't boot. It has two disks with boot manager installed and I get the F1 F5 options but neither do anything by clicking or by waiting. I can boot from floppy or cd and mount da0s1a, execute commands from bin and sbin but I cannot get it to boot. I even tried installing RELENG4 and the same problem. Has anyone seen this and have a solution? Thanks, ed - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to -CURRENT ( 1 week Feature Slush )
On Thu, 14 Mar 2002, Nate Williams wrote: Only in very rare cases do we run into a problem where we have to create a branch. In that case, the developer responsible for the release creates a branch from his checked out tree (there's no law against creating a branch from sources that are older than the HEAD), and then makes any necessary changes. It's worth noting that the rationale for the branch was that we *want* -CURRENT development to continue at a wild and merry pace, and *expect* that it will. Once the branch occurs, Jeff is free to replace the kernel memory allocator, etc. Local tweaks on the branch may include backing out some of the more recent changes to locking (the VM changes, for example -- there have been some reports of stability problems from Alfred). I.e., there is a specific development process goal to be accomplished using the branch. My feeling is that at this point, we probably should just use Perforce due to limitations in CVS. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Gvim link problem is still actual
Hi Just tried again with newly built world and kernel using vim from ports. This is built with ATHENA widget support and the only difference in make.conf from default is CPUTYPE=i686. What's wrong with -current? Gvim will build and work well under -stable. /usr/ports/editors/vim/Makefile: $FreeBSD: ports/editors/vim/Makefile,v 1.186 2002/03/10 18:45:45 obrien Exp $ myhakas:root# ldd /opt/portbuild/usr/ports/editors/vim/work/vim61b/src/vim /opt/portbuild/usr/ports/editors/vim/work/vim61b/src/vim: libXaw.so.7 = /usr/X11R6/lib/libXaw.so.7 (0x28159000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x281ac000) libncurses.so.5 = /usr/lib/libncurses.so.5 (0x281b9000) libgiconv.so.2 = /usr/local/lib/libgiconv.so.2 (0x281fb000) libc.so.5 = /usr/lib/libc.so.5 (0x282cf000) libXThrStub.XDeleteProperty = not found (0x0) libXThrStubXtVaGetValues = not found (0x0) libXThrStub.XDefaultScreen = not found (0x0) libXThrStub.XpmFreeAttributes = not found (0x0) libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0x28385000) libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x2839a000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x283e3000) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x283ec000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x28402000) libXpm.so.4 = /usr/X11R6/lib/libXpm.so.4 (0x284ba000) libXThrStub.so.6 = /usr/X11R6/lib/libXThrStub.so.6 (0x284c8000) -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CVS Issues with branch.. Was: Re: HEADS UP: Be nice to-CURRENT ( 1 week Feature Slush )
At 2:17 PM -0500 3/15/02, Robert Watson wrote: My feeling is that at this point, we probably should just use Perforce due to limitations in CVS. This seems fine to me. I am uneasy about perforce in cases where someone is developing something which is *meant* to be merged back into the main branch, and anyone interested in that change is told just check the P4 repository. That is not what is happening here. I would not *push* to have this done in P4, but I certainly do not mind if the RE team wants to handle it that way. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 4.5-5.0 kldxref:No such file or directory
Emiel Kollof [EMAIL PROTECTED] writes:
Why not test for it like this (or similar):
[ -x /usr/sbin/kldxref ] /usr/bin/kldxref (etcetera...)
A better solution is
@(kldxref ${DESTDIR}${KMODDIR} || \
echo Ignoring non-fatal kldxref failure)
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: malloc() and the stock Perl in -CURRENT (and -STABLE)
John Indra [EMAIL PROTECTED] writes: Glad to know that there is no problem with malloc() in -CURRENT. But I still think that this must be addressed in Perl. So maybe, the stock Perl should be built against its own malloc library? No! That would break anything that loads system libraries into Perl, like Authen::PAM, because you'd end up calling system malloc() followed by Perl free(), or the other way around. Please stop pretending this is a FreeBSD bug - it's a bug in Perl, which anally tries to conserve microscopic amounts of memory by growing strings in small increments instead of using the traditional (and far more efficient and elegant) 2n + 1 algorithm. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
I guess it's possible to change over entirely. That would mean we would loase a.out support because the GNU tools are becoming incapable of supporting a.out (all machines we run on are Linux machines syndrome). If we really wanted to avoid problems like this in the future, we'd just scrap FreeBSD entirely, and go to Linux, a bit at a time, starting with ELF, then DWARF2 exceptions, and then the Linux ABI instead of the FreeBSD ABI, and then all of Linux, a piece at a time. At the risk of being yelled at, I have a question: Why do we still need to support a.out? I know that a lot of people MIGHT still have some a.out binaries lying around, but FreeBSD's default binary format has been ELF for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should entirely switch over to the regular gnu toolchain, but is it really necessary to keep supporting a.out? Just my $0.02 Ken PS: If I sound annoyed, it's because it's sometimes annoying to have your toolchain controlled by someone with an interest in a product that competes with yours; that works for people competing with Microsoft products on Microsoft platforms with a need to use Microsoft tools, and it applies to Cygnus being owned by RedHat and them controlling the FreeBSD tools. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
strange apm/acpi message on CPQ Armada E700
Hi I just went -current with my Compaq Armada E700 laptop. Coming from -stable. I'm a bit puzzled by: WKB ~: apm APM version: 1.2 APM Managment: Enabled AC Line status: off-line Battery status: charging Remaining battery life: invalid value (0x) Remaining battery time: unknown Number of batteries: 0 APM Capacities: unknown dmesg also has some strange things it appears Rebooting... Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #2: Fri Mar 15 22:48:40 CET 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/WILKLT Preloaded elf kernel /boot/kernel/kernel at 0xc0436000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04360a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 498669634 Hz CPU: Pentium III/Pentium III Xeon/Celeron (498.67-MHz 686-class CPU) Origin = GenuineIntel Id = 0x681 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268369920 (262080K bytes) avail memory = 256614400 (250600K bytes) Pentium Pro MTRR support enabled Using $PIR table, 268435454 entries at 0xc00f0970 npx0: math processor on motherboard npx0: INT 16 interface acpi0: COMPAQ RSDTBL on motherboard ACPI-1305: *** Error: Method execution failed, AE_AML_REGION_LIMIT acpi0: power button is handled as a fixed feature programming model. ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 ACPI timer looks BAD min = 2, max = 6, width = 5 Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x5008-0x500b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_acad0: AC adapter on acpi0 pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pcic0: TI PCI-1450 PCI-CardBus Bridge mem 0x4110-0x41100fff irq 11 at device 4.0 on pci0 pcic0: TI12XX PCI Config Reg: [speaker enable][pwr save][CSC serial isa irq] pccard0: PC Card bus (classic) on pcic0 pcic1: TI PCI-1450 PCI-CardBus Bridge mem 0x4118-0x41180fff irq 11 at device 4.1 on pci0 pcic1: TI12XX PCI Config Reg: [speaker enable][pwr save][CSC serial isa irq] pccard1: PC Card bus (classic) on pcic1 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0x3420-0x342f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0x3400-0x341f irq 11 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: bridge, PCI-unknown at device 7.3 (no driver attached) pcm0: ESS Technology Maestro-2E port 0x3000-0x30ff irq 11 at device 8.0 on pci0 fxp0: Intel Pro 10/100B/100+ Ethernet port 0x3440-0x347f mem 0x4120-0x4121,0x4128-0x41280fff irq 11 at device 9.0 on pci0 fxp0: Ethernet address 00:d0:59:0b:f3:c2 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: simple comms, UART at device 9.1 (no driver attached) orm0: Option ROMs at iomem 0xd-0xd17ff,0xc-0xc on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 IPsec: Initialized Security Association Processing. acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5% system power profile changed to 'economy' ad0: 17301MB IBM-DARA-218000 [35152/16/63] at ata0-master UDMA33 acd0:
Re: gcc -O broken in CURRENT
On Fri, Mar 15, 2002 at 04:54:59PM -0500, Kenneth Culver wrote: At the risk of being yelled at, I have a question: Why do we still need to support a.out? I know that a lot of people MIGHT still have some a.out binaries lying around, but FreeBSD's default binary format has been ELF for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should entirely switch over to the regular gnu toolchain, but is it really necessary to keep supporting a.out? Just my $0.02 Rather than offer $0.02, send the patch. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
At the risk of being yelled at, I have a question: Why do we still need to support a.out? I know that a lot of people MIGHT still have some a.out binaries lying around, but FreeBSD's default binary format has been ELF for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should entirely switch over to the regular gnu toolchain, but is it really necessary to keep supporting a.out? Just my $0.02 Rather than offer $0.02, send the patch. Well, I was just asking if it is necessary, I'd make a patch if there was interest. My mail was asking if there is interest. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
On Fri, Mar 15, 2002 at 05:26:37PM -0500, Kenneth Culver wrote: At the risk of being yelled at, I have a question: Why do we still need to support a.out? I know that a lot of people MIGHT still have some a.out ... Rather than offer $0.02, send the patch. Well, I was just asking if it is necessary, I'd make a patch if there was interest. My mail was asking if there is interest. We aren't changing this for GCC 2.95 in 5-CURRENT. PEROID. There is zero reason for subjecting users to this ABI change for what would be gained. If you want to do something productive, submit patches that Bmake GCC 3.1 (which move us to Dwarf2 unwinding as a product). -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preparing innocent users for -current
Dag-Erling Smorgrav wrote: | 3. xconsole causes periodic panics. The problem (according to BDE) is a | well-know bug in printf(9), caused by The TIOCCONS ioctl ... panics when | printf() is called while sched_lock is held. I reported this bug in | October 2001, if anyone wants to look through the archives. | | Ages-old, very difficult to fix. Just don't use xconsole. You left out the final sentence with the suggested alternative. Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
Kenneth Culver wrote: At the risk of being yelled at, I have a question: Why do we still need to support a.out? I know that a lot of people MIGHT still have some a.out binaries lying around, but FreeBSD's default binary format has been ELF for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should entirely switch over to the regular gnu toolchain, but is it really necessary to keep supporting a.out? Just my $0.02 The switchover is not trivial. You're asking someone to do work for something that's not really valuable to them. There are certain boot code features that require the use of a.out kernels; this is less an issue than it was, but there were a number of things lost when we went to the new loader that are important for embedded environments. Cross-building for older platforms (not as big an issue, IMO). Other reasons I haven't even thought of yet 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
Hiten Pandya [EMAIL PROTECTED] writes: I have a tru 5.0-CURRENT environment.. also.. is there any changes where my ENABLE_NLS dillema can be solved.. s/dillema/dilemma/. It's not a dilemma, anyway; it's an issue, a condition, a situation, a problem, a failure; a conundrum (though not in the most usual sense of the word); a predicament; a jam, a fix, a (fine) pickle you've landed yourself in; possibly an impasse, if you really can't figure out a solution; an asperity, an exigency, or if you're in a hurry to get it fixed, maybe even an emergency - but definitely not a dilemma. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
I've recompiled kernet right before building qt... And have great prob with compiling -CURRENT right before Mar 8... I've installed -CURRENT SNAP on 20020219 which seems have broken binutils... Because xv and some other my packages coredumped with bus error (libpng issue, seemed to be solved Feb 22th) So, I was unable to compile -CURRENT after CVSup at Mar 6th (libpam issue), then was unable to run it (crypt_md5 bug). I was able to make -CURRENT up multiuser at Mar 11th, then deleted ALL packages and rebuilded from scratch... Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] On Thu, 14 Mar 2002, Kris Kennaway wrote: On Fri, Mar 15, 2002 at 08:36:29AM +0600, Maxim M. Kazachek wrote: I've installed qt23 from ports painlessly Fine, I'm glad to hear it :) The compile problems seem to be related to recent compiler toolchain changes, which you might not see unless you recompiled everything qt23 depends on from scratch (which the package cluster does). Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Preparing innocent users for -current
Greg Black [EMAIL PROTECTED] writes: Dag-Erling Smorgrav wrote: | Ages-old, very difficult to fix. Just don't use xconsole. You left out the final sentence with the suggested alternative. There is no suggested alternative. The problem is well-known and has been around for a long time, and there is simply no easy way to fix it. Your options are: 1) use xconsole, deal with the panics. 2) don't use xconsole, avoid the panics. 3) fix it yourself. For further details, consult _The New Hacker's Dictionary_, under Don't do that, then! (p. 157 in the 3rd ed.) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
We aren't changing this for GCC 2.95 in 5-CURRENT. PEROID. There is zero reason for subjecting users to this ABI change for what would be gained. If you want to do something productive, submit patches that Bmake GCC 3.1 (which move us to Dwarf2 unwinding as a product). Oh ok, that's another story altogether... If nobody has gotten to it by the May timeframe I'll do it. I've been looking for a way to contribute to the FreeBSD project anyway. Right now I'm working nearly 40 hrs a week and going to college full-time, so I don't really have time to do anything else. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
At the risk of being yelled at, I have a question: Why do we still need to support a.out? I know that a lot of people MIGHT still have some a.out binaries lying around, but FreeBSD's default binary format has been ELF for 3 or 4 years (Since 3.0-3.1 I believe). I'm not saying that we should entirely switch over to the regular gnu toolchain, but is it really necessary to keep supporting a.out? Just my $0.02 The switchover is not trivial. You're asking someone to do work for something that's not really valuable to them. There are certain boot code features that require the use of a.out kernels; this is less an issue than it was, but there were a number of things lost when we went to the new loader that are important for embedded environments. Cross-building for older platforms (not as big an issue, IMO). Other reasons I haven't even thought of yet 8-). Yeah, I was just wondering if there were issues making us keep a.out stuff in FreeBSD aside from the I wanna run 2.2.x programs issue. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
Kenneth Culver wrote: Other reasons I haven't even thought of yet 8-). Yeah, I was just wondering if there were issues making us keep a.out stuff in FreeBSD aside from the I wanna run 2.2.x programs issue. Linking with third party a.out libraries. Other reasons I haven't even thought of yet 8-). I can probably add one new reason per email indefinitely, if you want to insist... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
[ Trim the CC's a bit ]
On Fri, Mar 15, 2002 at 04:00:08PM -0800 I heard the voice of
Terry Lambert, and lo! it spake thus:
Kenneth Culver wrote:
Other reasons I haven't even thought of yet 8-).
Yeah, I was just wondering if there were issues making us keep a.out stuff
in FreeBSD aside from the I wanna run 2.2.x programs issue.
Linking with third party a.out libraries.
Other reasons I haven't even thought of yet 8-).
(ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
/usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
demand paged dynamically linked executable
Now, if you'd like to talk Netscape into building a version intended for
a version of FreeBSD newer than, say, 3 years, 3.5 months (approximately)
old...
--
Matthew Fuller (MF4839) |[EMAIL PROTECTED]
Unix Systems Administrator |[EMAIL PROTECTED]
Specializing in FreeBSD |http://www.over-yonder.net/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
[Cc's trimmed]
Kenneth Culver wrote:
| (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
| /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
|demand paged dynamically linked executable
|
| Now, if you'd like to talk Netscape into building a version intended for
| a version of FreeBSD newer than, say, 3 years, 3.5 months (approximately)
| old...
|
| I didn't realize anyone still used netscape 4.x. It's so disgustingly
| unstable and slow.
It's less slow and much more reliable than mozilla and remains
the only available browser that can access most of the sites I
need to access.
Greg
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ACPI autoload failed -- unable to install
I find it impossible to install 5.0-CURRENT from floppies, for both a current desktop and a current laptop machine. With this now occurring on two disparate machines, I have to believe there is either something very broken with the install floppies, or with me. If it is me, *please* let me know! I have gotten today's snapshot, 5.0-20020315-CURRENT, created the kernel and mfsroot 1.44 floppies, and attempted to boot a desktop machine from them. This is (from my 4.5-STABLE hard drive): CPU: Pentium III/Pentium III Xeon/Celeron (733.13-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE, MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 402571264 (393136K bytes) It is an Asus MB with a VIA chipset. Full (4.5) dmesg.boot is attached at the end of this message. Once again, the error message is that ACPI cannot be found. BTX then halts with: int=0006 err= efl=00010006 eip=c0306b40 eax=0081 ebx=0082fc00 ecx= edx=0102 esi=0082f000 edi=009b6000 ebp= esp=c09b1d98 cs=0008 ds=0010 es=0010fs=0010 gs=0010 ss=0010 cs:eip=ff ff ff ff ff 18 57 56-ff a1 e4 16 37 c0 a3 6c 78 38 c0 a1 e8 16 37 c0-a3 44 79 38 c0 05 a0 1d ss:esp=04 94 12 c0 00 70 83 00-00 f0 82 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted Thanks for your help, Jeff On Fri, 15 Mar 2002, Jeff Kletsky wrote: Date: Fri, 15 Mar 2002 07:52:17 -0800 (PST) From: Jeff Kletsky [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: ACPI autoload failed -- unable to install With apologies for an incomplete report, I am including the (manually transcribed) dump information. I have been able to network boot from a combination of the boot.flp and bin distribution (though there are problems with getting sysinstall to find disks that prevent that approach so far) and confirm that the hw.pcic interrupt routing sysctls *are* required. So the report that follows is based on using floppies from 5.0-20020314-CURRENT, including the one referred to as 'acpi.ko.flp' in the Failed workaround description below. To reproduce, follow the steps 1-7 outlined below. The tail end of the process appears as: OK load acpi.ko /boot/kernel/acpi.ko text=0x2b5a0 data=0x1558+0x6cc syms=[0x4+0x4ed0+0x4+0x675a] OK boot / int=0006 err= efl=00010006 eip=c03069f0 eax=0001 ebx=009aec00 ecx= edx=0102 esi=009ae000 edi=009b6000 ebp= esp=c09b1d98 cs=0008 ds=0010 es=0010fs=0010 gs=0010 ss=0010 cs:eip=ff ff ff 83 ec 18 57 ff-ff a1 84 15 37 c0 a3 0c 77 38 c0 a1 88 15 37 c0-a3 e4 77 38 c0 05 a0 1d ss:esp=04 94 12 c0 00 60 9b 00-00 e0 9a 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted I am willing to try reasonable steps and debugging here. Unfortunately, the BIOS driving the USB floppy seems to take about 10 min. to read a floppy, so it testing multiple scenarios is somewhat painful. I will be working with bootable CD configurations today, though the iLINK (IEEE-1394) connection there has its own share of problems (no non-BIOS support of the drive). At least with floppies, it *should* be a supported configuration. (Note however the reported issues with fixit only being mountable from /dev/fd0, not /dev/da0). Jeff On Thu, 14 Mar 2002, Jeff Kletsky wrote: Date: Thu, 14 Mar 2002 18:49:35 -0800 (PST) From: Jeff Kletsky [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: ACPI autoload failed -- unable to install (fwd) Tried the obvious -- manually loading acpi.ko -- still fails On Thu, 14 Mar 2002, Jeff Kletsky wrote: Date: Thu, 14 Mar 2002 17:41:01 -0800 (PST) From: Jeff Kletsky [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: ACPI autoload failed -- unable to install Having been unable to confirm a complete and proper installation of 5.0-CURRENT on my Sony PCG-SRX7/EP (similar to SRX77) laptop using the 4.5-RELEASE installer, I have made a bootable CD from 5.0-20020313-CURRENT, as well as floppies from 5.0-20020314-CURRENT. Both exhibit the same set of symptoms. [...] Results in: ACPI autoload failed - no such file or directory - [dump followed] Failed workaround: 1) Create floppies using dd 2) Make another copy of the mfsroot floopy, mount /dev/fd0 /mnt rm -rf /mnt/* mkdir -p /mnt/boot/kernel copy acpi.ko to /mnt/boot/kernel ### Note that copying to root of floppy fails on load attempt ### ### This is inconsistent with the loader (8) manpage in 5.0 ### umount /mnt 3) Boot from kern.flp 4) Load mfsroot.flp 5) Interrupt boot process set hw.pcic.intr_path=1 set hw.pcic.irq=0 6) Remove mfsroot.flp, insert 'acpi.ko.flp' load acpi.ko
Re: gcc -O broken in CURRENT
It's less slow and much more reliable than mozilla and remains the only available browser that can access most of the sites I need to access. That's odd, I've never had any mozilla problems. All I know is that it doesn't crash on sites that Netscape crashes on (anything java) and for me it runs much faster than netscape. It loads slower, but renders pages much faster, and I tend to load my browser once per day, and just leave it on. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
That's odd, I've never had any mozilla problems. All I know is that it doesn't crash on sites that Netscape crashes on (anything java) and for me it runs much faster than netscape. It loads slower, but renders pages much faster, and I tend to load my browser once per day, and just leave it on. Anyway, this is way OT, so that was my last message about it. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
On Sat, 16 Mar 2002, Greg Black wrote:
[Cc's trimmed]
Kenneth Culver wrote:
| (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
| /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
|demand paged dynamically linked executable
|
| Now, if you'd like to talk Netscape into building a version intended for
| a version of FreeBSD newer than, say, 3 years, 3.5 months (approximately)
| old...
|
| I didn't realize anyone still used netscape 4.x. It's so disgustingly
| unstable and slow.
It's less slow and much more reliable than mozilla and remains
the only available browser that can access most of the sites I
need to access.
and I use it's mail reader a lot..
Greg
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
On Friday 15 March 2002 08:53 pm, Kenneth Culver wrote:
| (ttypa):{1078}% file /usr/local/lib/netscape/communicator-4.7.us.bin
| /usr/local/lib/netscape/communicator-4.7.us.bin: FreeBSD/i386 compact
|demand paged dynamically linked executable
|
| Now, if you'd like to talk Netscape into building a version intended for
| a version of FreeBSD newer than, say, 3 years, 3.5 months (approximately)
| old...
|
| I didn't realize anyone still used netscape 4.x. It's so disgustingly
| unstable and slow.
Well, the linux-netscape 4 is the only browser I know that can handle Java
pages on FreeBSD.
Are there others?
If you mean the FreeBSD-native netscape 4.x; yes, it's perfectly silly to run
*that*.
|
| Ken
|
|
| To Unsubscribe: send mail to [EMAIL PROTECTED]
| with unsubscribe freebsd-hackers in the body of the message
--
Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work)
Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal)
ME -- http://www.babbleon.org
http://www.eff.org -- GOOD GUYS -- http://www.programming-freedom.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: gcc -O broken in CURRENT
Err--the linux netscape 6 runs fine. It's also quite slow to load, but
so far appears to be rather robust.
Cheers,
Ben
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Brian
T.Schellenberger
Sent: Friday, March 15, 2002 10:41 PM
To: Kenneth Culver; Matthew D. Fuller
Cc: Terry Lambert; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: gcc -O broken in CURRENT
On Friday 15 March 2002 08:53 pm, Kenneth Culver wrote:
| (ttypa):{1078}% file
/usr/local/lib/netscape/communicator-4.7.us.bin
| /usr/local/lib/netscape/communicator-4.7.us.bin:
FreeBSD/i386 compact
|demand paged dynamically linked executable
|
| Now, if you'd like to talk Netscape into building a
version intended for
| a version of FreeBSD newer than, say, 3 years, 3.5 months
(approximately)
| old...
|
| I didn't realize anyone still used netscape 4.x. It's so
disgustingly
| unstable and slow.
Well, the linux-netscape 4 is the only browser I know that
can handle Java
pages on FreeBSD.
Are there others?
If you mean the FreeBSD-native netscape 4.x; yes, it's
perfectly silly to run
*that*.
|
| Ken
|
|
| To Unsubscribe: send mail to [EMAIL PROTECTED]
| with unsubscribe freebsd-hackers in the body of the message
--
Brian T. Schellenberger . . . . . . . [EMAIL PROTECTED] (work)
Brian, the man from Babble-On . . . . [EMAIL PROTECTED] (personal)
ME -- http://www.babbleon.org
http://www.eff.org -- GOOD GUYS --
http://www.programming-freedom.org
To Unsubscribe: send
mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
[Unnecessary carbon copies trimmed.] On Fri, 15 Mar 2002 22:41:26 -0500, Brian T.Schellenberger [EMAIL PROTECTED] said: If you mean the FreeBSD-native netscape 4.x; yes, it's perfectly silly to run *that*. I don't see anything silly about it. It works with all the Web sites I care about (which is more than I can say for either mozilla or konqueror). It has a sensible (i.e., non-Windows-oriented) user interface. It has a few annoying bugs, but none of them are sufficiently problematic to keep me from getting my work done. What problems do you have with it? -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
Hi.
In [EMAIL PROTECTED], Maxim M. Kazachek wrote:
I've installed qt23 from ports painlessly
Does uic command provided by qt23 port work on your system? On my
-CURRENT (updated in Mar 11), that binary was linked with weird
liblcms.so_edata as next:
% ldd uic
uic:
libqutil.so.1 = /usr/X11R6/lib/libqutil.so.1 (0x28099000)
libqt2.so.4 = /usr/X11R6/lib/libqt2.so.4 (0x280a)
libstdc++.so.3 = /usr/lib/libstdc++.so.3 (0x28545000)
libm.so.2 = /usr/lib/libm.so.2 (0x2858a000)
libc_r.so.5 = /usr/lib/libc_r.so.5 (0x285a5000)
libc.so.5 = /usr/lib/libc.so.5 (0x285c3000)
liblcms.so_edata = not found (0x0)
libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x28676000)
libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x28684000)
libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x2875f000)
libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x28768000)
libXft.so.1 = /usr/X11R6/lib/libXft.so.1 (0x2877e000)
libpng.so.5 = /usr/local/lib/libpng.so.5 (0x287a7000)
libz.so.2 = /usr/lib/libz.so.2 (0x287c9000)
libjpeg.so.9 = /usr/local/lib/libjpeg.so.9 (0x287d6000)
libmng.so.1 = /usr/local/lib/libmng.so.1 (0x287f4000)
libXThrStub.so.6 = /usr/X11R6/lib/libXThrStub.so.6 (0x28826000)
libXrender.so.1 = /usr/X11R6/lib/libXrender.so.1 (0x28828000)
libfreetype.so.9 = /usr/local/lib/libfreetype.so.9 (0x2882d000)
liblcms.so.1 = /usr/local/lib/liblcms.so.1 (0x2886b000)
I don't know how to fix this. Only I can do is a makeshift disposition
as below:
diff -urN /usr/ports/x11-toolkits/qt23/Makefile qt23/Makefile
--- /usr/ports/x11-toolkits/qt23/Makefile Wed Feb 20 01:50:44 2002
+++ qt23/Makefile Sat Mar 16 05:59:21 2002
@@ -16,6 +16,8 @@
MAINTAINER?= [EMAIL PROTECTED]
+PLIST= ${WRKDIR}/pkg-plist
+
LIB_DEPENDS= mng.1:${PORTSDIR}/graphics/libmng \
png.5:${PORTSDIR}/graphics/png \
jpeg.9:${PORTSDIR}/graphics/jpeg
@@ -88,6 +90,13 @@
qt-pre-configure:
@true
+post-extract:
+ ${RM} -f ${PLIST}
+.if ${OSVERSION} = 500029
+ ${ECHO_CMD} lib/liblcms.so_edata ${PLIST}
+.endif
+ ${CAT} ${PKGDIR}/pkg-plist ${PLIST}
+
post-patch:
.if ${MACHINE_ARCH} == i386 !defined(NO_QT_OBJPRELINK)
.if !exists(${WRKDIR}/.${PKGNAME}.objprelink_patched)
@@ -170,6 +179,11 @@
.endfor
${INSTALL_MAN} ${WRKSRC}/doc/man/man3/q* ${PREFIX}/man/man3
.endif
+.endif
+
+post-install:
+.if ${OSVERSION} = 500029
+ ${CP} ${LOCALBASE}/lib/libmng.so ${PREFIX}/lib/liblcms.so_edata
.endif
.include bsd.port.post.mk
Thank you.
--
SASAKI Katuhiro
mailto: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
Hi.
In [EMAIL PROTECTED], Will Andrews wrote:
Um.. objprelink is disabled if OSVERSION = 500029. So it is
already ripped out for -current.
I think it better to rip objprelink out of kde port on -CURRENT, too. On
my -CURRENT (updated in Mar 11), many kde binaries build with using
objprelink dump cores (I confirmed kde-config, artsd and so on.). And
they seems to work fine when I set NO_KDE_OBJPRELINK at build time. I
show a patch to disable objprelink on -CURRENT below. How about this,
Will?
diff -urN /usr/ports/audio/kdemultimedia2/Makefile audio/kdemultimedia2/Makefile
--- /usr/ports/audio/kdemultimedia2/MakefileFri Jan 18 00:00:19 2002
+++ audio/kdemultimedia2/Makefile Sat Mar 16 04:40:50 2002
@@ -28,13 +28,13 @@
CONFIGURE_ARGS+=--with-qt-includes=${X11BASE}/include/qt2 \
--with-qt-libraries=${X11BASE}/lib
-_NO_KDE_FINAL= yes
-.include ${.CURDIR}/../../x11/kde2/Makefile.kde
-
USE_GMAKE= yes
MAKE_ENV= ${CONFIGURE_ENV}
.include bsd.port.pre.mk
+
+_NO_KDE_FINAL= yes
+.include ${.CURDIR}/../../x11/kde2/Makefile.kde
pre-configure:
${PERL} -pi -e s@all_includes=\@all_includes=\-I/usr/include @g \
diff -urN /usr/ports/deskutils/kdepim/Makefile deskutils/kdepim/Makefile
--- /usr/ports/deskutils/kdepim/MakefileWed Mar 6 00:01:08 2002
+++ deskutils/kdepim/Makefile Sat Mar 16 04:40:50 2002
@@ -24,6 +24,8 @@
INSTALLS_SHLIB=yes
GNU_CONFIGURE= yes
+.include bsd.port.pre.mk
+
.include ${.CURDIR}/../../x11/kde2/Makefile.kde
QTCPPFLAGS=-I${LOCALBASE}/include -L${LOCALBASE}/lib
@@ -55,4 +57,4 @@
find ${WRKSRC}/libical -name Makefile.in | xargs ${PERL} -pi -e \
s|INSTALL = \@INSTALL\@|INSTALL=${INSTALL} ${COPY} -o ${BINOWN} -g
${BINGRP}|g
-.include bsd.port.mk
+.include bsd.port.post.mk
diff -urN /usr/ports/devel/kdesdk/Makefile devel/kdesdk/Makefile
--- /usr/ports/devel/kdesdk/MakefileSat Jan 12 00:01:13 2002
+++ devel/kdesdk/Makefile Sat Mar 16 04:40:50 2002
@@ -22,6 +22,8 @@
USE_BZIP2= yes
GNU_CONFIGURE= yes
+.include bsd.port.pre.mk
+
.include ${.CURDIR}/../../x11/kde2/Makefile.kde
USE_GMAKE= yes
@@ -41,4 +43,4 @@
cd ${WRKSRC} env PATH=${WRKSRC}/auto-bin:$$PATH \
${GMAKE} -f Makefile.cvs
-.include bsd.port.mk
+.include bsd.port.post.mk
diff -urN /usr/ports/devel/kdevelop/Makefile devel/kdevelop/Makefile
--- /usr/ports/devel/kdevelop/Makefile Sat Jan 12 00:01:13 2002
+++ devel/kdevelop/Makefile Sat Mar 16 04:40:50 2002
@@ -38,6 +38,8 @@
GNU_CONFIGURE= yes
CONFIGURE_ARGS+= --with-qtdoc-dir=${X11BASE}/share/doc/qt2/html
+.include bsd.port.pre.mk
+
.include ${.CURDIR}/../../x11/kde2/Makefile.kde
pre-everything::
@@ -62,4 +64,4 @@
pre-build:
${PERL} -pi -e [EMAIL PROTECTED]@libkdeui.so@g ${WRKSRC}/kdevelop/main.cpp
-.include bsd.port.mk
+.include bsd.port.post.mk
diff -urN /usr/ports/editors/koffice/Makefile editors/koffice/Makefile
--- /usr/ports/editors/koffice/Makefile Sat Jan 12 00:01:47 2002
+++ editors/koffice/MakefileSat Mar 16 04:40:50 2002
@@ -26,6 +26,8 @@
GNU_CONFIGURE= yes
USE_GMAKE= yes
+.include bsd.port.pre.mk
+
_NO_KDE_OBJPRELINK=yes
.include ${.CURDIR}/../../x11/kde2/Makefile.kde
@@ -56,4 +58,4 @@
${MV} ${PREFIX}/bin/kivio ${PREFIX}/bin/kivio.real
${INSTALL_SCRIPT} ${FILESDIR}/kivio.sh ${PREFIX}/bin/kivio
-.include bsd.port.mk
+.include bsd.port.post.mk
diff -urN /usr/ports/games/kdegames2/Makefile games/kdegames2/Makefile
--- /usr/ports/games/kdegames2/Makefile Sat Jan 12 00:02:15 2002
+++ games/kdegames2/MakefileSat Mar 16 04:40:50 2002
@@ -22,6 +22,8 @@
GNU_CONFIGURE= yes
USE_GMAKE= yes
+.include bsd.port.pre.mk
+
.include ${.CURDIR}/../../x11/kde2/Makefile.kde
pre-configure:
@@ -35,4 +37,4 @@
cd ${WRKSRC} env PATH=${WRKSRC}/auto-bin:$$PATH \
${GMAKE} -f Makefile.cvs
-.include bsd.port.mk
+.include bsd.port.post.mk
diff -urN /usr/ports/graphics/kdegraphics2/Makefile graphics/kdegraphics2/Makefile
--- /usr/ports/graphics/kdegraphics2/Makefile Sat Jan 12 00:02:37 2002
+++ graphics/kdegraphics2/Makefile Sat Mar 16 04:40:50 2002
@@ -26,9 +26,9 @@
USE_GMAKE= yes
CONFIGURE_ARGS+=--without-kamera
-.include ${.CURDIR}/../../x11/kde2/Makefile.kde
-
.include bsd.port.pre.mk
+
+.include ${.CURDIR}/../../x11/kde2/Makefile.kde
# temporarily disable kamera, it requires gphoto2
PLIST_SUB+=KAMERA=@comment
diff -urN /usr/ports/misc/kdeaddons/Makefile misc/kdeaddons/Makefile
--- /usr/ports/misc/kdeaddons/Makefile Sat Jan 12 00:04:12 2002
+++ misc/kdeaddons/Makefile Sat Mar 16 04:40:50 2002
@@ -27,9 +27,9 @@
PLIST_SUB+=RM=${RM}
CONFIGURE_ENV+=SDL_CONFIG=${LOCALBASE}/bin/sdl11-config
-.include ${.CURDIR}/../../x11/kde2/Makefile.kde
-
.include bsd.port.pre.mk
+
+.include ${.CURDIR}/../../x11/kde2/Makefile.kde
pre-configure:
${MKDIR} ${WRKSRC}/auto-bin
diff -urN
RE: ACPI autoload failed -- unable to install
Jeff, FWIW, the Asus A7A266 is not completely ACPI compliant. Yours may not be either. It may be worth researching *cough* or replacing *cough*. -Otter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Kletsky Sent: Friday, March 15, 2002 10:07 PM To: Jeff Kletsky Cc: [EMAIL PROTECTED] Subject: Re: ACPI autoload failed -- unable to install I find it impossible to install 5.0-CURRENT from floppies, for both a current desktop and a current laptop machine. With this now occurring on two disparate machines, I have to believe there is either something very broken with the install floppies, or with me. If it is me, *please* let me know! I have gotten today's snapshot, 5.0-20020315-CURRENT, created the kernel and mfsroot 1.44 floppies, and attempted to boot a desktop machine from them. This is (from my 4.5-STABLE hard drive): CPU: Pentium III/Pentium III Xeon/Celeron (733.13-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE, MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 402571264 (393136K bytes) It is an Asus MB with a VIA chipset. Full (4.5) dmesg.boot is attached at the end of this message. Once again, the error message is that ACPI cannot be found. BTX then halts with: int=0006 err= efl=00010006 eip=c0306b40 eax=0081 ebx=0082fc00 ecx= edx=0102 esi=0082f000 edi=009b6000 ebp= esp=c09b1d98 cs=0008 ds=0010 es=0010fs=0010 gs=0010 ss=0010 cs:eip=ff ff ff ff ff 18 57 56-ff a1 e4 16 37 c0 a3 6c 78 38 c0 a1 e8 16 37 c0-a3 44 79 38 c0 05 a0 1d ss:esp=04 94 12 c0 00 70 83 00-00 f0 82 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted Thanks for your help, Jeff On Fri, 15 Mar 2002, Jeff Kletsky wrote: Date: Fri, 15 Mar 2002 07:52:17 -0800 (PST) From: Jeff Kletsky [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: ACPI autoload failed -- unable to install With apologies for an incomplete report, I am including the (manually transcribed) dump information. I have been able to network boot from a combination of the boot.flp and bin distribution (though there are problems with getting sysinstall to find disks that prevent that approach so far) and confirm that the hw.pcic interrupt routing sysctls *are* required. So the report that follows is based on using floppies from 5.0-20020314-CURRENT, including the one referred to as 'acpi.ko.flp' in the Failed workaround description below. To reproduce, follow the steps 1-7 outlined below. The tail end of the process appears as: OK load acpi.ko /boot/kernel/acpi.ko text=0x2b5a0 data=0x1558+0x6cc syms=[0x4+0x4ed0+0x4+0x675a] OK boot / int=0006 err= efl=00010006 eip=c03069f0 eax=0001 ebx=009aec00 ecx= edx=0102 esi=009ae000 edi=009b6000 ebp= esp=c09b1d98 cs=0008 ds=0010 es=0010fs=0010 gs=0010 ss=0010 cs:eip=ff ff ff 83 ec 18 57 ff-ff a1 84 15 37 c0 a3 0c 77 38 c0 a1 88 15 37 c0-a3 e4 77 38 c0 05 a0 1d ss:esp=04 94 12 c0 00 60 9b 00-00 e0 9a 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted I am willing to try reasonable steps and debugging here. Unfortunately, the BIOS driving the USB floppy seems to take about 10 min. to read a floppy, so it testing multiple scenarios is somewhat painful. I will be working with bootable CD configurations today, though the iLINK (IEEE-1394) connection there has its own share of problems (no non-BIOS support of the drive). At least with floppies, it *should* be a supported configuration. (Note however the reported issues with fixit only being mountable from /dev/fd0, not /dev/da0). Jeff On Thu, 14 Mar 2002, Jeff Kletsky wrote: Date: Thu, 14 Mar 2002 18:49:35 -0800 (PST) From: Jeff Kletsky [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: ACPI autoload failed -- unable to install (fwd) Tried the obvious -- manually loading acpi.ko -- still fails On Thu, 14 Mar 2002, Jeff Kletsky wrote: Date: Thu, 14 Mar 2002 17:41:01 -0800 (PST) From: Jeff Kletsky [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: ACPI autoload failed -- unable to install Having been unable to confirm a complete and proper installation of 5.0-CURRENT on my Sony PCG-SRX7/EP (similar to SRX77) laptop using the 4.5-RELEASE installer, I have made a bootable CD from 5.0-20020313-CURRENT, as well as floppies from 5.0-20020314-CURRENT. Both exhibit the same set of symptoms. [...] Results in: ACPI autoload failed - no such file or directory - [dump followed] Failed workaround: 1) Create floppies using dd 2) Make another copy of the mfsroot floopy, mount /dev/fd0 /mnt rm -rf /mnt/* mkdir -p /mnt/boot/kernel copy acpi.ko to /mnt/boot/kernel ### Note that copying
Re: gcc -O broken in CURRENT
Brian T.Schellenberger wrote: Well, the linux-netscape 4 is the only browser I know that can handle Java pages on FreeBSD. Are there others? If you mean the FreeBSD-native netscape 4.x; yes, it's perfectly silly to run *that*. 4.7 does this just fine, if you don't move the mouse until it's done loading. That restriction only exists for image mapped interfaces, where the Java GIF loader is used, and then only if the image loading is not serialized by the page design. Note that only Solaris, Windows, and Linux, all of which assume (incorrectly) that a threaded process that is preempted involuntarily will resume executin in the thread that was runningat preemption time, handle the concurrent image loading correctly, if you move the mouse or otherwise cause input to the browser before the loads are complete. Basically, it's bad threading assumptions, and it's fixed in a more recent version, if you can find one. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
Garrett Wollman [EMAIL PROTECTED] writes: What problems do you have with it? Slow. Eats memory. Crashes all the time. Does not save state between sessions. Does not render HTML 4 properly. Does not support CSS properly. Does not zoom. Does not display PNG properly. Incorrectly ignores cache-control headers on images. The list goes on... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc -O broken in CURRENT
Dag-Erling Smorgrav wrote: Garrett Wollman [EMAIL PROTECTED] writes: What problems do you have with it? Slow. Eats memory. Crashes all the time. Does not save state between sessions. Does not render HTML 4 properly. Does not support CSS properly. Does not zoom. Does not display PNG properly. Incorrectly ignores cache-control headers on images. The list goes on... If you use a real network socket instead of the shared memory extension, it won't eat memory. THis lost memory due to it instancing regions for which it loses the reference counts; it's arguably a resource tracking bug in the X server, actually, since they are associated with windows that go away. I admit, this is an annoying one... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
problem with libz 1.1.4 when installing linux_base ports
Hi All, After the import of libz 1.1.4, rpm (from ports) dumps core when trying to install linux_base. # make install === Installing for linux_base-6.1_1 setup-2.0.5-1.noarch.rpm filesystem-1.3.5-1.noarch.rpm basesystem-6.0-4.noarch.rpm ldconfig-1.9.5-15.i386.rpm Segmentation fault - core dumped *** Error code 139 Stop in /usr/ports/emulators/linux_base. *** Error code 1 When runing rpm inside gdb, SEGV seems to be happing inside libz. Starting program: /usr/local/bin/rpm -U --ignoreos --root /compat/linux --dbpath /var/lib/rpm --nodeps --replacepkgs --noscripts /usr/ports/distfiles/rpm/ldconfig-1.9.5-15.i386.rpm Program received signal SIGSEGV, Segmentation fault. 0x80a42b3 in inflate_codes () (gdb) where #0 0x80a42b3 in inflate_codes () #1 0x80a1d13 in inflate_blocks () #2 0x809f737 in inflate () #3 0x809ea94 in gzread () #4 0x808184f in gzdRead (cookie=0x813a900, buf=0x81453f0 ' repeats 200 times..., count=14) at rpmio.c:2230 I then went into src/lib/libz and checked the difference between libz 1.1.4 and older 1.1.3. I found that if I backout the change for infcodes.c 1.3, rpm does not dump core. Could someone take a look into this? Thanks, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
