Re: upgrade from static to dynamic root
On Sun, 14 Sep 2003, Ruslan Ermilov wrote:
RE>On Thu, Sep 11, 2003 at 02:44:55PM +0200, Harti Brandt wrote:
RE>>
RE>> Hi,
RE>>
RE>> I just tried to upgrade one of my systems from a static root from july to
RE>> an actual dynamic root. The installworld went fine 'til the place where
RE>> /bin/test is installed. At that point the installation stopped with "ELF
RE>> interpreter /libexec/ld-elf.so.1 not found". And really /libexec is not
RE>> populated yet. May it be, that the makefile uses one of the newly
RE>> installed tools during install? For example 'ln' to make the link test ->
RE>> [?
RE>>
RE>It shouldn't happen, because we save test and [ in ${INSTALLTMP}.
RE>It looks like something hardcodes /bin/test. I've grepped the
RE>src/ makefiles and cannot find such a place. Where exactly did
RE>it happen in the installworld for you?
It installed /bin/test and then failed just when it was going to make the
link to '['. Unfortunately this is rather hard to reproduce, unless I roll
everything back.
harti
RE>> Also, wouldn't it be helpful to populate /rescue before /bin? Just in
RE>> the case something goes wrong between installing been and rescue for the
RE>> first time?
RE>>
RE>Good idea!
RE>
RE>
RE>Cheers,
RE>
--
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mystery kernel spew
On Sun, Sep 14, 2003 at 07:13:09PM -0700, Doug White wrote: >Incidentally, if you are getting wrapping even without this, you can use a >serial console to capture the output. I've had to do this for doing nasty >ACPI debugging with lots of the options enabled. For kernel spew, you can also increase the kernel message buffer: # Size of the kernel message buffer. Should be N * pagesize. options MSGBUF_SIZE=40960 And for the VTYs, you can increase the scroll-back size: options SC_HISTORY_SIZE=200 # number of history buffer lines Both these are kernel compile-time options. Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA DVD-ROM failure
It seems Dario Freni wrote: > > Could you please boot verbose and mail me the output of dmesg ? > > Sure. That's in attachment. Okies, you need to update as there has been changes since this that should fix the problem. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devd/devctl
On Friday, September 12, 2003, at 06:26 pm, Suleiman Souhlal wrote: I was wondering if it would be a good idea to modify devd and devctl for them to handle other events than attaching and detaching devices.. For example, they could be used to mark a network interface as down, when the network cable is pulled out, and run dhclient when it is put back in. I think there are other applications too. Just something that occured to me in a slightly G&T addled state. The GNOME folks have this really cool application at the moment called 'dashboard'. Basically it works by receiving what they've dubbed 'clue packets' from whatever application that you happen to be using at the time, and distributing these to multiple backend plugins that either: a) rewrite the clue packet so that it contains additional information, and/or trigger additional clue packets or b) process it in some way, and update the information that's being displayed by the dashboard The canonical example they use at the moment is receiving an e-mail from someone. Your e-mail app sends a clue packet with the e-mail address of the person you've received it from, and the various backends pull out their address details from your address book, a photo, their web page link (if your browser knows it), their picture, the last five messages they've sent you, and so on, and so forth. I wonder if this model could be adopted for kernel and system events. Instead of a devd, usbd, and others, we need a more generic eventd, which can receive events from the kernel, and distribute them to backends, which can act on them, or augment them as necessary. We've reached cruising altitude, so I can't provide web links, but a google for 'gnome dashboard' should turn up useful info. N ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck failed after hard crash
(...) > >> unexpected soft-update inconsistency, unable to write block, etc. > >> > >> going back to my 9/9/2003 "good" kernel, it works. > > > > i tried to use my old kernel; build with sources from fbsd 5.1 release). > > i rebooted the system and started fsck -y /usr again but the same > > problems occur :( > > > > now there are two possibilities i guess: > > - something in userland is broken too > > - my ufs2 is really dead > I'm using ufs1, FWIW, and my userland is from september 9 as well. > So, either 5.1R is too far back or you are in trouble. > > FWIW. > > so here i go again :) - partly at least ... i booted the live CD and was able to fix my ufs2 fs (still some errors reported but marked as clean). then i re-installed the sources from fbsd 5.1 release cd, built a new kernel and did a "make world" - everything seems to be ok now :) so there seems to be something broken in sources from 13.9.2003 ? seb (...) ___ [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: Text file busy
Terry Lambert wrote:
Wesley Morgan wrote:
It's also unfortunate that this protection does not seem to extend to
libaries. I've had some in-use X libraries get overwritten with some very
colorful results.
So send patches.
I did a year ago :-) See PR 37554. (Not the original patch, the
self-follow-up).
That was for 4.5-STABLE: It's been running on a box that does nightly
builds of -current and -stable (and infrequent installworlds of -stable)
since then without any ill effects. A -current equivalent (with a sysctl
knob, "vm.mmap_exec_immutable", to turn the behaviour on/off) is
attached, in case anyone's interested.
As noted in the original PR, the choice of PROT_EXEC to decide to add
VV_TEXT to the vnode might be better done with a new mmap flag, say,
PROT_IMMUTABLE or something, but PROT_EXEC works fine for me.
Index: sys/vm/vm_mmap.c
===
RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/sys/vm/vm_mmap.c,v
retrieving revision 1.165
diff -u -r1.165 vm_mmap.c
--- sys/vm/vm_mmap.c7 Sep 2003 18:47:54 - 1.165
+++ sys/vm/vm_mmap.c15 Sep 2003 13:36:46 -
@@ -91,6 +91,11 @@
static int max_proc_mmap;
SYSCTL_INT(_vm, OID_AUTO, max_proc_mmap, CTLFLAG_RW, &max_proc_mmap, 0, "");
+static int mmap_exec_immutable = 1;
+SYSCTL_INT(_vm, OID_AUTO, mmap_exec_immutable, CTLFLAG_RW,
+&mmap_exec_immutable, 1, "mmap(2) of a regular file for execute access "
+"marks the file as immutable");
+
/*
* Set the maximum number of vm_map_entry structures per process. Roughly
* speaking vm_map_entry structures are tiny, so allowing them to eat 1/100
@@ -443,8 +448,18 @@
error = vm_mmap(&vms->vm_map, &addr, size, prot, maxprot,
flags, handle, pos);
mtx_lock(&Giant);
- if (error == 0)
+ if (error == 0) {
+ /*
+* If mapping a regular file as PROT_EXEC, and configured to,
+* mark the file as immutable
+*/
+ if (mmap_exec_immutable &&
+ handle != NULL && vp != NULL &&
+ (prot & PROT_EXEC) && vp->v_type == VREG)
+ vp->v_vflag |= VV_TEXT;
td->td_retval[0] = (register_t) (addr + pageoff);
+ }
+
done:
if (vp)
vput(vp);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mtools access to floppy stopped working with recent -current
With a recent version of -current (09-14-2003) I can no longer write to a floppy drive with mtools commands. I get the following when trying to delete a file: plain_io: Bad address buffer_flush: write: Bad address plain_io: Bad address buffer_flush: write: Bad address plain_io: Bad address buffer_flush: write: Bad address This worked fine with a -current from about a week ago. -- Glenn Johnson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
system hang on boot w/ "atapicam0: timeout waiting for ATAPI ready" (5.1-CURRENT, IBM T30)
As reported on Fri, 05 Sep 2003, I am seeing a hang on boot when I have the CD-RW/DVD installed in my T30's ultrabay. When I remove the drive the system boots fine. Having a CD in the drive does not help. The system hangs hard enough that I have to hit the power button to get it's attention. Is anyone else seeing this? : || tylendel.castle.org [2] ; uname -a FreeBSD tylendel.castle.org 5.1-CURRENT FreeBSD 5.1-CURRENT #56: Mon Sep 15 09:00:54 PDT 2003 [EMAIL PROTECTED]:/users/FreeBSD-5.0/obj/users/FreeBSD-5.0/src/sys/TYLENDEL i386 thanks, nomad >Yesterday's cvsup'd and compiled kernel hung at > acd0: CDRW at ata1-master UDMA33 > atapicam0: timeout waiting for ATAPI ready > >I waited until today and did another cvsup, same problem. > >What I expect to see is: > > acd0: CDRW at ata1-master UDMA33 > Mounting root from ufs:/dev/ad0s1a > >It does this if there is a CD in the drive as well as when there isn't. > >Removing atapicam from the kernel def and recompile removed the hang. > >: || tylendel.castle.org [4] ; uname -a >FreeBSD tylendel.castle.org 5.1-CURRENT FreeBSD 5.1-CURRENT #48: Fri Sep 5 >10:53:09 PDT 2003 [EMAIL >PROTECTED]:/users/FreeBSD-5.0/obj/users/FreeBSD-5.0/src/sys/TYLENDEL i386 nomad --- - Lee "nomad" Damon - \ play: [EMAIL PROTECTED]or castle!nomad \ work: [EMAIL PROTECTED] \ /\ Seneschal, Castle PAUS./ \ "Celebrate Diversity" /\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
bad block 8239054478774324592, ino 3229486
bad block 7021770428354685254, ino 3229486
panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
Debugger("panic")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c043aa25,c04ac1c0,c0435bc2,cd1d1980,100) at Debugger+0x54
panic(c0435bc2,5d2e4000,ffca8803,c7725d50,c0440989) at panic+0xd5
g_dev_strategy(c7725d50,0,c29b42e4,1,c0439d9c) at g_dev_strategy+0xa7
spec_xstrategy(c29c9920,c7725d50,0,c29b42e4,0) at spec_xstrategy+0x3ef
spec_specstrategy(cd1d1a60,cd1d1a84,c02b2982,cd1d1a60,0) at spec_specstrategy+0x72
spec_vnoperate(cd1d1a60,0,e544,4000,0) at spec_vnoperate+0x18
breadn(c29c9920,1ae9720,e544,4000,0) at breadn+0x122
bread(c29c9920,1ae9720,e544,4000,0) at bread+0x4c
ffs_blkfree(c29d4800,c29c9920,6c6c69,6f747561,4000) at ffs_blkfree+0x286
indir_trunc(c4abe200,313a0e0,0,0,c) at indir_trunc+0x334
handle_workitem_freeblocks(c4abe200,0,2,c04af748,c26acc00) at
handle_workitem_freeblocks+0x21e
process_worklist_item(0,0,3f65f661,0,c32961e0) at process_worklist_item+0x1fd
softdep_process_worklist(0,0,c044228c,6f4,0) at softdep_process_worklist+0xe0
sched_sync(0,cd1d1d48,c04383a9,312,20) at sched_sync+0x304
fork_exit(c02c4e30,0,cd1d1d48) at fork_exit+0xcf
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xcd1d1d7c, ebp = 0 ---
db>
Is this disk corruption, or a bug?
Kris
pgp0.pgp
Description: PGP signature
Re: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
8239054478774324592 = 0x72570065646F4D70 = "rW\0edoMp"
7021770428354685254 = 0x617257006C6C6946 = "arW\0lliF"
That looks suspicious to me...
In message <[EMAIL PROTECTED]>, Kris Kennaway writes:
>
>--OgqxwSJOaUobr8KG
>Content-Type: text/plain; charset=us-ascii
>Content-Disposition: inline
>
>bad block 8239054478774324592, ino 3229486
>bad block 7021770428354685254, ino 3229486
>panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
>Debugger("panic")
>Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
>db> trace
>Debugger(c043aa25,c04ac1c0,c0435bc2,cd1d1980,100) at Debugger+0x54
>panic(c0435bc2,5d2e4000,ffca8803,c7725d50,c0440989) at panic+0xd5
>g_dev_strategy(c7725d50,0,c29b42e4,1,c0439d9c) at g_dev_strategy+0xa7
>spec_xstrategy(c29c9920,c7725d50,0,c29b42e4,0) at spec_xstrategy+0x3ef
>spec_specstrategy(cd1d1a60,cd1d1a84,c02b2982,cd1d1a60,0) at spec_specstrategy+0x72
>spec_vnoperate(cd1d1a60,0,e544,4000,0) at spec_vnoperate+0x18
>breadn(c29c9920,1ae9720,e544,4000,0) at breadn+0x122
>bread(c29c9920,1ae9720,e544,4000,0) at bread+0x4c
>ffs_blkfree(c29d4800,c29c9920,6c6c69,6f747561,4000) at ffs_blkfree+0x286
>indir_trunc(c4abe200,313a0e0,0,0,c) at indir_trunc+0x334
>handle_workitem_freeblocks(c4abe200,0,2,c04af748,c26acc00) at
>handle_workitem_freeblocks+0x21e
>process_worklist_item(0,0,3f65f661,0,c32961e0) at process_worklist_item+0x1fd
>softdep_process_worklist(0,0,c044228c,6f4,0) at softdep_process_worklist+0xe0
>sched_sync(0,cd1d1d48,c04383a9,312,20) at sched_sync+0x304
>fork_exit(c02c4e30,0,cd1d1d48) at fork_exit+0xcf
>fork_trampoline() at fork_trampoline+0x1a
>--- trap 0x1, eip = 0, esp = 0xcd1d1d7c, ebp = 0 ---
>db>
>
>Is this disk corruption, or a bug?
>
>Kris
>
>--OgqxwSJOaUobr8KG
>Content-Type: application/pgp-signature
>Content-Disposition: inline
>
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1.2.3 (FreeBSD)
>
>iD8DBQE/ZgHiWry0BWjoQKURAvPFAJ9vLJrNmZgRDT9Hhoked8il+5YGbACdENuh
>U4x0Dyqvq01pYLya7q4Xo60=
>=vAfZ
>-END PGP SIGNATURE-
>
>--OgqxwSJOaUobr8KG--
>
--
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: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
On Mon, Sep 15, 2003 at 08:24:24PM +0200, Poul-Henning Kamp wrote: > > 8239054478774324592 = 0x72570065646F4D70 = "rW\0edoMp" > > 7021770428354685254 = 0x617257006C6C6946 = "arW\0lliF" > > That looks suspicious to me... Suspicious as indicating a kernel bug, or suspicious as in this panic is spurious and likely due to hardware failure? Kris pgp0.pgp Description: PGP signature
fsck & mtools problems
At the start of the weekend, I made a typo in a commit that changed vmapbuf() to use a new pmap function. The result was that raw disk access sometimes failed. I recognized and fixed the problem last night. Simply update your vfs_bio.c to the latest version and you should be fine. Sorry for the inconvenience, Alan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bad performance
> i recently switched from mandrake to freebsd. i used a second system, > to install freebsd 5.1 (release) on a 15 gb western digital disk. i > installed the whole system without problems and managed to start gdm and > gnome2. everything worked fine and performance (launching gdm, gnome2 > and firebird) was really good (better then mdk :) > > then i moved the disk from the hardware used during install into the > "production" environment which includes VIA 82C8363 (Apollo KT133A) > board, NVidia GeForce2 grafic card (using nvidia native driver for x11), > AMD Duron 750 MHz, 512 mb ram. > > everything worked fine again. BUT: launching gdm needs a lot of time, > same for gnome2. when i start moz-firebird i am unabled to use it for > minutes (!) until it reacts on user events (typing inet adress into > address bar), same for gaim. > i checked the ata settings; the drive is running in udma66 (as > expected). > > cause i am new to *bsd i do not really know where to start or what > further information to provide. any hint/idea would be great ! At any time during the above, did you recompile your kernel? If so, comment out these options from your kernel config and recompile again: options INVARIANTS options INVARIANT_SUPPORT options WITNESS options WITNESS_SKIPSPIN -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Bus error
Hi today, cvsup'ed my source and build world ... and now get an so called Bus error while i want to su, anyone know about it (or fixed it) tnx wasa there is a fine line between sanaty and insanaty, i walk that line . ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
DVD+RW not working with ATAng.
As a status report, a recent CVSup fixed the phantom ad3 issue, but... ATAng is failing to allow my DVD+RW to cut DVD+R's. growisofs fails with 'permission denied' as it's penultimate error ... even when run as root. It also seems to coaster the DVD ... which is getting expensive. This is all using the atapicam layer ... as DVD software seems to only understand the emulated SCSI. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ACPI problems with this morning's -CURRENT
Thus spake Nate Lawson ([EMAIL PROTECTED]) [13/09/03 14:42]: > The post you reference shows the user with a kernel that has both APM and > ACPI installed, apparently. This is not valid. > > Please report your kernel config. If GENERIC in 2003/9/6 booted fine with > ACPI and then your rebuilt kernel from 2003/9/7 fails, it is almost > certainly the devices you included. There were no ACPI-related commits in > that timeframe. It's attached. There's no APM in there. I did some more testing -- GENERIC works for the -CURRENT date I stated before, and 5.1-R. As soon as I compile my own kernel, it breaks. I'm working on compiling this with debugging, so I can take a closer look at what's going on. ident pandora machine i386 cpu I686_CPU maxusers0 options INCLUDE_CONFIG_FILE #optionsCPU_WT_ALLOC options MAXMEM=(512*1024) options DEVICE_POLLING options HZ=1000 device isa device pci device agp device speaker device random device pty device md device npx device sio options CONSPEED=115200 options GEOM_BDE options GEOM_BSD options GEOM_VOL options SCHED_4BSD options COMPAT_43 options COMPAT_FREEBSD4 options SYSVSHM options SYSVSEM options SYSVMSG options INET options INET6 options IPSEC options IPSEC_ESP device ether device loop device bpf device disc device gif device faith device stf options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK options PFIL_HOOKS options RANDOM_IP_ID options ACCEPT_FILTER_DATA options ACCEPT_FILTER_HTTP options TCP_DROP_SYNFIN options FFS options NFSCLIENT options NFSSERVER options PROCFS options PSEUDOFS options SOFTUPDATES options UFS_DIRHASH options UFS_EXTATTR options UFS_EXTATTR_AUTOSTART options UFS_ACL options _KPOSIX_PRIORITY_SCHEDULING options P1003_1B_SEMAPHORES #optionsMAC #optionsMAC_BSDEXTENDED #optionsMAC_SEEOTHERUIDS # These are worth looking into, but require configuration #optionsMAC_BIBA #optionsMAC_LOMAC #optionsMAC_MLS # These two are also worth looking at, and take less configuration #optionsMAC_PARTITION #optionsMAC_PORTACL device atkbdc device atkbd options KBD_INSTALL_CDEV device vga options VGA_ALT_SEQACCESS device splash device sc #device daemon_saver #device fade_saver device fire_saver #device green_saver #device logo_saver #device rain_saver #device star_saver #device warp_saver device ata device atadisk device miibus device fxp device smbus device ichsmb device smb device iicbus device iicbb device iicsmb #device crypto # core crypto support #device cryptodev # /dev/crypto for access to h/w # #device rndtest # FIPS 140-2 entropy tester # #device hifn# Hifn 7951, 7781, etc. #optionsHIFN_DEBUG # enable debugging support: hw.hifn.debug #optionsHIFN_RNDTEST# enable rndtest support # #device ubsec # Broadcom 5501, 5601, 58xx #optionsUBSEC_DEBUG # enable debugging support: hw.ubsec.debug #optionsUBSEC_RNDTEST # enable rndtest support ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
wi0 - 5.1 problems
Hi There. Someone knows why the Freebsd wireless Access Point work so bad on Freebsd 5.1?? I try lot of thing but I couldn't make it work fine, the wireless card crash the connection , the speed is very slow whan is working, is imposible to use. but same setting , same wireless card, work perfect on Freebsd 5.0. I tried different computer, adapters, settings, wireless card, but always is crap on Freebsd 5.1 current or 5.1 realese. May be I need an Special setup? thanks -- Marcos Biscaysaqu Systems Administrator ThePacific.Net Ltd. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: upgrade from static to dynamic root
On Mon, Sep 15, 2003 at 09:42:27AM +0200, Harti Brandt wrote:
> On Sun, 14 Sep 2003, Ruslan Ermilov wrote:
>
> RE>On Thu, Sep 11, 2003 at 02:44:55PM +0200, Harti Brandt wrote:
> RE>>
> RE>> Hi,
> RE>>
> RE>> I just tried to upgrade one of my systems from a static root from july to
> RE>> an actual dynamic root. The installworld went fine 'til the place where
> RE>> /bin/test is installed. At that point the installation stopped with "ELF
> RE>> interpreter /libexec/ld-elf.so.1 not found". And really /libexec is not
> RE>> populated yet. May it be, that the makefile uses one of the newly
> RE>> installed tools during install? For example 'ln' to make the link test ->
> RE>> [?
> RE>>
> RE>It shouldn't happen, because we save test and [ in ${INSTALLTMP}.
> RE>It looks like something hardcodes /bin/test. I've grepped the
> RE>src/ makefiles and cannot find such a place. Where exactly did
> RE>it happen in the installworld for you?
>
> It installed /bin/test and then failed just when it was going to make the
> link to '['. Unfortunately this is rather hard to reproduce, unless I roll
> everything back.
>
I will see if I can reproduce it on my devbox.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
Re: upgrade from static to dynamic root
On Thu, Sep 11, 2003 at 02:44:55PM +0200, Harti Brandt wrote:
>
> Hi,
>
> I just tried to upgrade one of my systems from a static root from july to
> an actual dynamic root. The installworld went fine 'til the place where
> /bin/test is installed. At that point the installation stopped with "ELF
> interpreter /libexec/ld-elf.so.1 not found". And really /libexec is not
> populated yet. May it be, that the makefile uses one of the newly
> installed tools during install? For example 'ln' to make the link test ->
> [?
>
> Also, wouldn't it be helpful to populate /rescue before /bin? Just in
> the case something goes wrong between installing been and rescue for the
> first time?
A dynamic root is still a little bit of a no seatbelt kind of activity.
We should probably bring back the ${OBJDIR}/bin/sh test and if we fail,
install /libexec/ld-elf.so.1 then reattempt the ${OBJDIR}/bin/sh test
and continue on with life.
-gordon
pgp0.pgp
Description: PGP signature
Re: ACPI problems with this morning's -CURRENT
(To recap: I'm having ACPI problems on a DFI CD70-SC, with both 5.1-R and
5-CURRENT. Booting GENERIC doesn't show any problems, however, so there's a
good chance it's a misconfiguration issue.)
Thus spake Damian Gerow ([EMAIL PROTECTED]) [15/09/03 17:34]:
> It's attached. There's no APM in there. I did some more testing -- GENERIC
> works for the -CURRENT date I stated before, and 5.1-R. As soon as I
> compile my own kernel, it breaks.
>
> I'm working on compiling this with debugging, so I can take a closer look at
> what's going on.
Okay, here's a backtrace with debugging. Unfortunately, when dropped to the
debugging prompt, I don't know what to do. Attached is the kernel config I
used to generate this on 5.1-R, I can re-do this on -CURRENT if need be.
Here's a snippet of boot, and the stack backtrace:
...
Preloaded elf kernel "/boot/kernel/kernel" at 0xc04b8000
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04b81f4
...
real memory = 536870912 (512 MB)
avail memory = 516313088 (492 MB)
panic: pmap_mapdev: Couldn't allocate kernel virtual memory
Stack backtrace:
backtrace(c035b0cc,c03baea0,c0372994,c04dabbc,100) at backtrace+0x17
panic(c0372994,c036f000,0,0,0) at panic+0x93
pmap_mapdev(1fff3000,c036ec14,c04dac48,c04dabcc,c048e880) at pmap_mapdev+0x4b
AcpiOsMapMemory(1fff3000,0,c036ec14,c04dabbc,c04dabc4) at AcpiOsMapMemory+0x1e
AcpiTbGetThisTable(c04dac48,c04dac00,c04dac58,c04dac48,c04dac48) at
AcpiTbGetThisTable+0xf0
AcpiTbGetTableBody(c04dac48,c04dac00,c04dac58,c0387ebc,c036ec14) at
AcpiTbGetTableBody+0x4c
AcpiTbGetTable(c04dac48,c04dac58,9,1fff3000,0) at AcpiTbGetTable+0x38
AcpiTbGetTableRsdt(c04daca0,c04daca0,c04dacb4,1,f6010) at AcpiTbGetTableRsdt+0x23
AcpiLoadTables(c04a8bc0,c04a49ac,0,0,0) at AcpiLoadTables+0xa6
acpi_identify(c04a7528,c151cb00,c0379a14,c1506190,c151cb00) at acpi_identify+0xb4
DEVICE_IDENTIFY(c04a7528,c151cb00,c151cb00,c151cb00,c04dad18) at
DEVICE_IDENTIFY+0x50
bus_generic_probe(c151cb00,c3fcc098,c04dad34,c01da1b8,c151cb00) at
bus_generic_probe+0x2e
nexus_attach(c151cb00,c3fcc098,c0379a1c,c151cb00,c151d000) at nexus_attach+0x14
DEVICE_ATTACH(c151cb00,c151cb00,0,c14ea5d8,1) at DEVICE_ATTACH+0x48
device_probe_and_attach(c151cb00,c14ea5d8,c04dad80,c0321635,c151d000) at
device_probe_and_attach+0x7d
root_bus_configure(c151d000,c0371fdc,0,c04dad98,c01960a5) at
root_bus_configure+0x28
configure(0,4d7000,4d7c00,4d7000,0) at configure+0x35
mi_startup() at mi_startup+0xb5
being() at begin+0x2c
Debugger("panic")
Stopped atDebugger+0x54:xchgl %ebx,in_Debugger.0
db> print
c01c08b0
db> show pcpu
cpuid = 0
curthread = 0xc03b4640: pid 0 "swapper"
curpcb = 0
fpcurthread = none
idlethread = 0xc151f850: pid 11 "idle"
currentldt = 0x28
db> show map
Task map 0xc01c08b0: pmap=0x4de80574, nentries=604293056, version=742228750
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4c70500
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc02f3a40
stack pointer = 0x10: 0xc04da940
frame pointer = 0x10: 0xc04da960
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 0 (swapper)
kernel: type 12 trap, code=0
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db>
Given that I caused a panic while in the debugger, and that I don't know
what I'm looking for, I stopped here. (Further 'show map's didn't result in
a panic, however.)
Note that if I /don't/ boot with ACPI, I can boot just fine, with no power
management.
ident pandora
machine i386
cpu I686_CPU
maxusers0
makeoptions DEBUG=-g
options DDB
options DDB_TRACE
options KTRACE
options DIAGNOSTIC
options INCLUDE_CONFIG_FILE
options CPU_FASTER_5X86_FPU
options CPU_UPGRADE_HW_CACHE
#optionsCPU_WT_ALLOC
options MAXMEM=(512*1024)
options DEVICE_POLLING
options HZ=1000
device isa
device pci
device agp
device speaker
device random
device pty
device md
device npx
device sio
options CONSPEED=115200
options GEOM_BDE
options GEOM_BSD
options GEOM_VOL
options SCHED_4BSD
options COMPAT_43
options COMPAT_FREEBSD4
options SYSVSHM
options SYSVSEM
options SYSVMSG
options INET
options INET6
options IPSEC
options IPSEC_ESP
device ether
device loop
device bpf
device disc
device gif
device faith
device stf
options IPFILTER
o
ath0, Driver support?
Hi There . I have in comming a couple a Proxim 8480- pcmcia , with Atheros Chipset and 8482- pci . someone knows if this card work on Freebsd? thanks -- Marcos Biscaysaqu Systems Administrator ThePacific.Net Ltd. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
On Mon, 15 Sep 2003, Kris Kennaway wrote:
> bad block 8239054478774324592, ino 3229486
> bad block 7021770428354685254, ino 3229486
> panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
> Debugger("panic")
> Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
> db> trace
> Debugger(c043aa25,c04ac1c0,c0435bc2,cd1d1980,100) at Debugger+0x54
> panic(c0435bc2,5d2e4000,ffca8803,c7725d50,c0440989) at panic+0xd5
> g_dev_strategy(c7725d50,0,c29b42e4,1,c0439d9c) at g_dev_strategy+0xa7
> spec_xstrategy(c29c9920,c7725d50,0,c29b42e4,0) at spec_xstrategy+0x3ef
> spec_specstrategy(cd1d1a60,cd1d1a84,c02b2982,cd1d1a60,0) at spec_specstrategy+0x72
> spec_vnoperate(cd1d1a60,0,e544,4000,0) at spec_vnoperate+0x18
> breadn(c29c9920,1ae9720,e544,4000,0) at breadn+0x122
> bread(c29c9920,1ae9720,e544,4000,0) at bread+0x4c
> ffs_blkfree(c29d4800,c29c9920,6c6c69,6f747561,4000) at ffs_blkfree+0x286
> indir_trunc(c4abe200,313a0e0,0,0,c) at indir_trunc+0x334
> handle_workitem_freeblocks(c4abe200,0,2,c04af748,c26acc00) at
> handle_workitem_freeblocks+0x21e
> process_worklist_item(0,0,3f65f661,0,c32961e0) at process_worklist_item+0x1fd
> softdep_process_worklist(0,0,c044228c,6f4,0) at softdep_process_worklist+0xe0
> sched_sync(0,cd1d1d48,c04383a9,312,20) at sched_sync+0x304
> fork_exit(c02c4e30,0,cd1d1d48) at fork_exit+0xcf
> fork_trampoline() at fork_trampoline+0x1a
> --- trap 0x1, eip = 0, esp = 0xcd1d1d7c, ebp = 0 ---
> db>
>
> Is this disk corruption, or a bug?
This is either disk corruption or an ffs bug. ffs passes the garbage
block number 0xe5441ae9720 to bread. GEOM then handles this austerely
by panicing. Garbage block numbers, including negative ones, can possibly
be created by applications seeking to preposterous offsets, so they should
not be handled with panics.
The following script (with edits to turn off avoiding the bugs) demonstrated
related bugs the last time I tried it (about 6 months ago).
%%%
#!/bin/sh
SOMEFILE=/c/tmp/zz
# Bugs:
# (1) md silently truncates sizes (in DEV_BSIZE'ed units) mod 2^32.
# (2) at least pre-GEOM versions of md get confused by this and cause a
# null pointer panic in devstat.
#
# Use the maximum size that works (2^32 - 1). Unfortunately, this prevents
# testing of file systems with size 2 TB or larger.
dd if=/dev/zero of=$SOMEFILE oseek=0xFFFE count=1
mdconfig -a -t vnode -f ${SOMEFILE} -u 0
# The large values here are more to make newfs not take too long than to
# get a large maxfilesize.
newfs -O 1 -b 65536 -f 65536 -i 6533600 /dev/md0
# Note that this reports a very large maxfilesise (2282 TB). This is the
# size associated with the triple indirect block limit, not the correct
# one. I think the actual limit should be 64 TB (less epsilon).
dumpfs /dev/md0 | grep maxfilesize
mount /dev/md0 /mnt
# Bugs:
# (1) fsbtodb(nb) overflows when nb has type ufs1_daddr_t and the result
# should be larger than (2^31 - 1).
# (2) dscheck() used to detect garbage block numbers caused by (1) (if the
# garbage happened to be negative or too large). Then it reported the error
# and invalidated the buffer. GEOM doesn't detect any error. It apparently
# passes on the garbage, so the error is eventually detected by ffs (since
# md0 is on an ffs vnode) (if the garbage is preposterous). ffs_balloc_ufs1()
# eventually sees the error as an EFBIG returned be bwrite() and gives up.
# But the buffer says in the buffer cache to cause problems later.
# (3) The result of bwrite() is sometimes ignored.
#
# Chop a couple of F's off the seek so that we don't get an EFBIG error.
# Unfortunately, this breaks testing for files of size near 2282 TB.
dd if=/dev/zero of=/mnt/zz oseek=0xFE count=1
ls -l /mnt/zz
# Bugs:
# (1) umount(2) returns the undocumented errno EFBIG for the unwriteable
# buffer.
# (2) umount -f and unmount at reboot fail too (the latter leaving all file
# systems dirty).
#
# Removing the file clears the problem.
rm /mnt/zz
umount /mnt
# Since we couldn't demonstrate files larger than 2 TB on md0, demonstrate
# one near ${SOMEFILE}.
dumpfs /c | egrep '(^bsize|^fsize|maxfilesize)'
dd if=/dev/zero of="$SOMEFILE"-bigger oseek=0x3FFFE count=1
ls -l "$SOMEFILE"-bigger
rm "$SOMEFILE"-bigger
mdconfig -d -u 0
rm $SOMEFILE
%%%
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: Negative bio_offset (-15050100712783872) on bio 0xc7725d50
On Tue, Sep 16, 2003 at 10:42:38AM +1000, Bruce Evans wrote: > This is either disk corruption or an ffs bug. Thanks. The disk this occurred on is a flaky IBM drive which periodically experiences other kinds of FS corruption, so I'm inclined to blame it. Kris pgp0.pgp Description: PGP signature
Release Engineering Status Report
All, I'd like to give a status report for 4.x and 5.x for the developers and users who didn't attend the DevSummit this past weekend. 4.9: The 4.9 release is likely going to be pushed back for a few weeks while the recent instability reports are tracked down. The target goal is two weeks, but hopefully things can be resolved before then. The problems appear to stem from the recent PAE import. The consensus reached at the DevSummit is that PAE is a critical feature for 4.x and that removing it isn't desirable unless the problems persist. We encourage anyone to help with this. 5.x: The 5-stable roadmap document received a major overhaul yesterday. I encourage everyone to take a look at it at http://www.freebsd.org/doc/en_US.ISO8859-1/articles/5-roadmap/index.html. Among the highlights, KSE is progressing extremely well and is no longer a major source of concern for 5-stable. Stability is also at a very good level. However, while performance has improved in some areas, it is not at the level that we want it to be. Since improving performance will likely involve changing some API's and adding short-term risk to stability, it's looking like the 5-stable branch will be delayed until 5.3. 5.2 will be released in late Nov/early Dec and will feature the vastly improved KSE, partially-improved network performance, optional dynamically-linked root filesystem, and many stability fixes, along with numerous new features. I thank all of the developers, contributors, and users for the highly productive summer and ask that that enthusiasm continue as we push towards 5.2 and 5.3. Scott The Release Engineering Team ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled
On Fri, Sep 12, 2003 at 08:54:59AM +0200, Morten Rodal wrote: > A little bit of history first. I am having great trouble in running > any of the Mozilla web browsers under -CURRENT with libkse. (If you > are really interested see the thread on threads@) > > When I ran Mozilla Firebird with the --debug (which lets you run > Mozilla Firebird from within gdb) the machine paniced. The backtrace > is rather long and I am not sure if the subject of this email is the > real panic either. This computer is/was (I am currently rebuilding > the kernel to todays sources) running: > > FreeBSD slurp.rodal.no 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Fri Aug 22 18:06:03 CEST > 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp i386 > > More details are available upon request. > Since the last panic I upgraded to FreeBSD slurp.rodal.no 5.1-CURRENT FreeBSD 5.1-CURRENT #2: Fri Sep 12 08:59:58 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/slurp i386 (both world and kernel). I am still able to reproduce this, and it is fairly simple. On a smp machine (haven't tried my laptop, and I got more important stuff there that I dont want to lose in a panic) do the following: 1) Install the mozilla-firebird port 2) Edit libmap.conf so that it uses libkse 3) Start it by running "firebird --debug", this will present you with a gdb prompt. Type run here and watch your computer panic. (It takes a little while) So this brings up the question, is there a known problem with debugging multi-threaded applications (which use libkse) that can cause a panic? I will bring home my laptop, and will be able to use a serial debugger if that would help anyone willing to trace this down. -- Morten Rodal Script started on Tue Sep 16 08:25:54 2003 slurp# gdb -k kernel.13 vmcore.13 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"... panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled panic messages: --- panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 0; lapic.id = 0100 Stack backtrace: boot() called on cpu#0 syncing disks, buffers remaining... panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled cpuid = 0; lapic.id = 0100 boot() called on cpu#0 Uptime: 3d19h39m32s Dumping 447 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 --- Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/linux/linux.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/linux/linux.ko.debug Reading symbols from /boot/kernel/snd_sb16.ko...done. Loaded symbols for /boot/kernel/snd_sb16.ko Reading symbols from /boot/kernel/snd_sbc.ko...done. Loaded symbols for /boot/kernel/snd_sbc.ko Reading symbols from /boot/kernel/snd_pcm.ko...done. Loaded symbols for /boot/kernel/snd_pcm.ko Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/acpi/acpi.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/acpi/acpi.ko.debug Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/if_gif/if_gif.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/if_gif/if_gif.ko.debug Reading symbols from /boot/kernel/nvidia.ko...done. Loaded symbols for /boot/kernel/nvidia.ko Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/cd9660/cd9660.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/cd9660/cd9660.ko.debug Reading symbols from /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/nfsserver/nfsserver.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/slurp/modules/usr/src/sys/modules/nfsserver/nfsserver.ko.debug #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc01de9b6 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc01dee08 in panic () at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc0320467 in smp_tlb_shootdown (vector=0, addr1=0, addr2=0) at /usr/src/sys/i386/i386/mp_machdep.c:2396 #4 0xc03207a9 in smp_invlpg_range (addr1=0, addr2=0) at /usr/src/sys/i386/i386/mp_machdep.c:2527 #5 0xc0322b38 in pmap_invalidate_range (pmap=0xc03eda40, sva=3440447488, eva=3440463872) at /usr/src/sys/i386/i386/pmap.c:719 #6 0xc0323011 in pmap_qremove (sva=3440447488, count=0) at /usr/src/sys/i386/i386/pmap.c:985 #7 0xc022ba4a in vfs_vmio_release (bp=0xcca1ec60) at /usr/src/sys/kern/vf
ad4 device
I tried to install the 9/15 snapshot which looks like it now supports Adaptec SATA and Adaptec 1200A Raid controllers. Unfortuneatly on two systems I tried to install this on, both failed with the error /dev/ad4s1a no device present. Since devices are automatically created in 5.X is there any work around to this? -Derek [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading to FreeBSD 5.1
On Mon, Sep 15, 2003 at 11:18:24PM +0300, Ruslan Ermilov wrote: > You mean you upgrade to RELENG_5_1? Beware that this branch > is currently not buildable: libpthread build is broken. Eh? By `this branch' you mean RELENG_5_1? How is it broken? If there is a problem (I don't know of any --- it built after I made the commits for the last security advisory), it is critical to fix it. -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [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: Upgrading to FreeBSD 5.1
On Mon, Sep 15, 2003 at 03:54:09PM -0500, Jacques A. Vidrine wrote:
> On Mon, Sep 15, 2003 at 11:18:24PM +0300, Ruslan Ermilov wrote:
> > You mean you upgrade to RELENG_5_1? Beware that this branch
> > is currently not buildable: libpthread build is broken.
>
> Eh? By `this branch' you mean RELENG_5_1? How is it broken?
>
building shared library libkse.so.1
thr_libc.So: In function `sigaction':
thr_libc.So(.text+0x54): multiple definition of `_sigaction'
thr_sigaction.So(.text+0x0): first defined here
thr_libc.So: In function `sigprocmask':
thr_libc.So(.text+0x34): multiple definition of `_sigprocmask'
thr_sigprocmask.So(.text+0x0): first defined here
*** Error code 1
Basically, see the log for libpthread/support/Makefile.inc,v 1.2
where it talks why -L/usr/lib in a makefile is a Bad Idea (TM).
> If
> there is a problem (I don't know of any --- it built after I made the
> commits for the last security advisory), it is critical to fix it.
>
This worked for you because you probably test built RELENG_5_1
on a fresh HEAD system. Please see the attached messages that
is still unanswered that talks about files/revisions involved
into a fix.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
--- Begin Message ---
On Tue, Sep 02, 2003 at 12:37:11PM -0700, Alexander Kabaev wrote:
> kan 2003/09/02 12:37:11 PDT
>
> FreeBSD src repository
>
> Modified files:
> lib/libpthread Makefile
> lib/libpthread/support Makefile.inc
> Log:
> Rethink the way thr_libc.So is generated. Relying on GCC to extract
> only needed symbols from libc_pic is not working on sparc64.
>
> Requested by: jake
>
> Revision ChangesPath
> 1.48 +0 -6 src/lib/libpthread/Makefile
> 1.6 +32 -4 src/lib/libpthread/support/Makefile.inc
>
Excellent! This means that revs. 1.365 and 1.367 to Makefile.inc1 can
go away now?
%%%
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.389
diff -u -r1.389 Makefile.inc1
--- Makefile.inc1 1 Sep 2003 06:43:24 - 1.389
+++ Makefile.inc1 3 Sep 2003 07:16:30 -
@@ -813,8 +813,6 @@
# gnu/lib/csu, gnu/lib/libgcc and lib/csu must be built before all
# shared libraries for ELF.
#
-# lib/libc (libc_pic.a) must be built before lib/libpthread.
-#
_startup_libs= gnu/lib/csu gnu/lib/libgcc
.if exists(${.CURDIR}/lib/csu/${MACHINE_ARCH}-elf)
_startup_libs+=lib/csu/${MACHINE_ARCH}-elf
@@ -823,6 +821,7 @@
.endif
_prebuild_libs=
+
_generic_libs= gnu/lib
.if exists(${.CURDIR}/kerberos5) && exists(${.CURDIR}/crypto) && \
@@ -834,9 +833,6 @@
_generic_libs+=kerberos5/lib
.endif
-.if !defined(NOLIBPTHREAD)
-_prebuild_libs+= lib/libc
-.endif
_prebuild_libs+= lib/libcom_err lib/libcrypt lib/libexpat \
lib/libkvm lib/libmd \
lib/libncurses lib/libopie lib/libpam lib/libradius \
%%%
BTW, the build of RELENG_5_1 is currently broken in libpthread due
to the same issue fixed in these revisions and rev. 1.2 to
libpthread/support/Makefile.inc. Can you please fix the build of
RELENG_5_1 as well?
And, what's so special about Sparc64 that it didn't work there?
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software Ltd,
[EMAIL PROTECTED] FreeBSD committer
pgp0.pgp
Description: PGP signature
--- End Message ---
pgp1.pgp
Description: PGP signature
Re: Upgrading to FreeBSD 5.1
Try without the -j option. -Mike On Mon, 15 Sep 2003, Didier Rwitura wrote: > Date: Mon, 15 Sep 2003 15:13:30 -0400 > From: Didier Rwitura <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Upgrading to FreeBSD 5.1 > > I am trying to upgrade my sysstem from 4.8-RELEASE-p4 to 5.1 > > and i getting this error message when I run "make -j4 buildworld" > > > [admin]/usr/src(101)#make -j4 buildworld > Running test variables > PASS: Test variables detected no regression, output matches. > Running test targets > PASS: Test targets detected no regression. > Running test sysvmatch > PASS: Test sysvmatch detected no regression. > Running test lhs_expn > FAIL: Test failed: regression detected. See above. > *** Error code 1 > 1 error > *** Error code 2 > -- > Building an up-to-date make(1) > -- > > what do I need to check to fix this . I read the /src/UPDATING ... I didnt find any > info about this error message. > > > Thanx > - > Didier > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > 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: Upgrading to FreeBSD 5.1
On Mon, Sep 15, 2003 at 03:13:30PM -0400, Didier Rwitura wrote: > I am trying to upgrade my sysstem from 4.8-RELEASE-p4 to 5.1 > > and i getting this error message when I run "make -j4 buildworld" > > > [admin]/usr/src(101)#make -j4 buildworld > Running test variables > PASS: Test variables detected no regression, output matches. > Running test targets > PASS: Test targets detected no regression. > Running test sysvmatch > PASS: Test sysvmatch detected no regression. > Running test lhs_expn > FAIL: Test failed: regression detected. See above. > *** Error code 1 > 1 error > *** Error code 2 > -- > Building an up-to-date make(1) > -- > > what do I need to check to fix this . I read the /src/UPDATING ... I didnt find any > info about this error message. > You mean you upgrade to RELENG_5_1? Beware that this branch is currently not buildable: libpthread build is broken. The error above is expected error, and does not (should not) the buildworld to fail -- as the first step, src/Makefile checks to see if the available make(1) binary is adequate to build world; it does this by passing it by running the make regression tests, and should they fail, builds a new make from fresh sources. The errors above indicate that some of the regression tests have failed, and this causes the new make to be built. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Upgrading to FreeBSD 5.1
I am trying to upgrade my sysstem from 4.8-RELEASE-p4 to 5.1 and i getting this error message when I run "make -j4 buildworld" [admin]/usr/src(101)#make -j4 buildworld Running test variables PASS: Test variables detected no regression, output matches. Running test targets PASS: Test targets detected no regression. Running test sysvmatch PASS: Test sysvmatch detected no regression. Running test lhs_expn FAIL: Test failed: regression detected. See above. *** Error code 1 1 error *** Error code 2 -- Building an up-to-date make(1) -- what do I need to check to fix this . I read the /src/UPDATING ... I didnt find any info about this error message. Thanx - Didier ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upgrading to FreeBSD 5.1
On Mon, Sep 15, 2003 at 03:13:30PM -0400, Didier Rwitura wrote: > I am trying to upgrade my sysstem from 4.8-RELEASE-p4 to 5.1 > > and i getting this error message when I run "make -j4 buildworld" Does it actually stop there, or does it go on to rebuild make as the message suggests it will, and as it is supposed to? Kris pgp0.pgp Description: PGP signature
