Bruce Evans <[EMAIL PROTECTED]> writes:
> I saw this too. It is caused by garbage in the source tree (crtbegin.s
> in this case) and bug(s) in in the rule to create crtbegin.o). I'm
> not sure what created the garbage. For me, I think it was caused by
> playing with cross-compiles (I tried MACH
Hi everyone !
I installed -CURRENT some time ago... i would like to help and do some
testing on my spare time.
for now i build (once a week on average) and use as much as i can.
many ports don't work (but i think it's normal, problems with pthread
-> seg fault), so i compile them on my -STABLE sy
On Thu, Jul 19, 2001 at 12:24:07AM -0700, Terry Lambert wrote:
> > > I'm saying "fix it both places, or it obviously is not a
> > > sufficient justification for a decision".
> > >
> > > Or to put it another way "if you are willing to live with
> > > it in one place, why not two?".
> >
> > What on
On Wed, Jul 18, 2001 at 12:32:40PM -0700, Manfred Antar wrote:
> (/usr/local/bin)505}./pnmtopng
> /usr/libexec/ld-elf.so.1: /usr/lib/crtn.o: unsupported file type
Fix is in the pipeline. Sometimes the commit process to the FSF/GNU tree
is a slow one.
--
-- David ([EMAIL PROTECTED])
To Uns
Top of tree:
--
>>> stage 4: building libraries
--
cd /usr/src; MAKEOBJDIRPREFIX=/sec/obj
COMPILER_PATH=/sec/obj/usr/src/i386/usr/libexec:/sec/obj/usr/src/i386/usr/bin
LIBRA
Kris Kennaway wrote:
> a) libcrypt has been "reunified" for 7 months now; Peter did it last
> December.
Someone needs to tell my newly installed 4.3 system this.
4.3-RELEASE _did_ come out after that, right?
I guess this wasn't MFC'ed? It seems to _still_ not have
been MFC'ed in my 4.3-STABLE
On Tue, 17 Jul 2001, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Bruce Evans <[EMAIL PROTECTED]> wrote:
> > I have used essentially the same patch (with ${LDFLAGS} instead of
> > -static) for a year or two, but I don't quite understand why you needed
> > it. make_keys and make_hash
On Thu, Jul 19, 2001 at 01:37:16AM -0700, Terry Lambert wrote:
> Kris Kennaway wrote:
> > a) libcrypt has been "reunified" for 7 months now; Peter did it last
> > December.
>
> Someone needs to tell my newly installed 4.3 system this.
>
> 4.3-RELEASE _did_ come out after that, right?
>
> I gues
On Wed, 18 Jul 2001, Matthew Jacob wrote:
> So, I took a SCSi disk away. Diskcheckd started complaining. However,
> a camcontrol rescan couldn't make the disk go away until I killed off
> diskcheckd, which then closed the disk, allowing the rescan to remove it.
> Bad. Bad. Bad.
This may also hav
On Thu, Jul 19, 2001 at 02:01:31AM -0700, Kris Kennaway wrote:
> On Thu, Jul 19, 2001 at 01:37:16AM -0700, Terry Lambert wrote:
> > Kris Kennaway wrote:
> > > a) libcrypt has been "reunified" for 7 months now; Peter did it last
> > > December.
> >
> > Someone needs to tell my newly installed 4.3
> > So, I took a SCSi disk away. Diskcheckd started complaining. However,
> > a camcontrol rescan couldn't make the disk go away until I killed off
> > diskcheckd, which then closed the disk, allowing the rescan to remove it.
> > Bad. Bad. Bad.
>
> This may also have caused your disklabel problem
I did not test this myself, but adding -lz to the LFDLAGS in pnmtopng linking
command or removing bogus empty -L before existing -lz switch
might help to work around the problem. The bug is triggered by the code in ld
which tries to determine what other shared libraries binary should depend on in
On Thu, 19 Jul 2001 [EMAIL PROTECTED] wrote:
> > > So, I took a SCSi disk away. Diskcheckd started complaining. However,
> > > a camcontrol rescan couldn't make the disk go away until I killed off
> > > diskcheckd, which then closed the disk, allowing the rescan to remove it.
> > > Bad. Bad. Bad.
On 19 Jul 2001, Dag-Erling Smorgrav wrote:
> Top of tree:
>
> --
> >>> stage 4: building libraries
> --
> ...
> cd /usr/src/gnu/lib/csu; make _EXTRADEPEND
> cc -O -pipe -march=
With a July 18, 2001 sources, it seems like the kernel hands at
the entropy harvesting stage ctrl-t shows:
load : 098 cmd : sycctl 51 [running] 4.51u 210.37s 0% 172k
It will just sit there forever until ctrl-c is hit. Anyone knows
what's wrong? Thanks.
Cheers,
Vince - [E
>Date: Thu, 19 Jul 2001 02:48:10 -1000 (HST)
>From: Vincent Poy <[EMAIL PROTECTED]>
> With a July 18, 2001 sources, it seems like the kernel hands at
>the entropy harvesting stage ctrl-t shows:
>load : 098 cmd : sycctl 51 [running] 4.51u 210.37s 0% 172k
>It will just sit ther
Please take a minute to review the attachment. Thank you.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Wed, Jul 18, 2001 at 09:34:41PM -0400, a little birdie told me
that Garance A Drosihn remarked
> At 11:18 PM -0700 7/17/01, Peter Wemm wrote:
> >If I had to guess, I'd put the total [genuine] -current userbase
> >at between 20 and 50 people. And many of those intentionally lag
> >by a few week
> On Wed, 18 Jul 2001, Matthew Jacob wrote:
>
> > So, I took a SCSi disk away. Diskcheckd started complaining. However,
> > a camcontrol rescan couldn't make the disk go away until I killed off
> > diskcheckd, which then closed the disk, allowing the rescan to remove it.
> > Bad. Bad. Bad.
>
> T
At 12:24 AM -0700 7/19/01, Terry Lambert wrote:
>I guess I need to paint a picture...
I guess we need to just ignore you on this particular topic.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instit
On 19 Jul, David Wolfskill wrote:
>>It will just sit there forever until ctrl-c is hit. Anyone knows
>>what's wrong? Thanks.
>
> This was discussed (to some extent) aboust a week & a half ago in -current.
> It seems (pointed out by Alexander Leidinger <[EMAIL PROTECTED]>)
> that -- for
fatal kernel trap:
trap entry = 0x2 (memory management fault)
cpuid = 0
faulting va= 0x48
type = access violation
cause = load instructon
pc = 0xfc4ce89c
ra = 0xfc4ce874
sp = 0
Could you please try the attached patch and see if it helps?
On Thu, Jul 19, 2001 at 12:40:11PM -0700, Matthew Jacob wrote:
>
> fatal kernel trap:
>
> trap entry = 0x2 (memory management fault)
> cpuid = 0
> faulting va= 0x48
> type = access violation
I'll try it if I can get booted again :-)
Yea, I found the panic line-
/* Record statistics for this interface address. */
if (!(flags & IP_FORWARDING)) {
* ia->ia_ifa.if_opackets++;
ia->ia_ifa.if_obytes += m->m_p
Had to make a minor change to make sure isbroadcast was set, but yes, that
worked, thank you!
-matt
Index: ip_output.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v
retrieving revision 1.130
diff -u -r1.130 ip_out
+---[ Manfred Antar ]--
| The port netpbm builds and installs fine on current.
| When trying to build the docs in /usr/docs the program peps calls
|/usr/local/bin/pnmtopng
| This is from the netpbm port.
|
| (/usr/local/bin)505}./pnmtopng
| /usr/libexec/ld-elf.so.1: /usr
+---[ Andrew Kenneth Milton ]--
| +---[ Manfred Antar ]--
| | The port netpbm builds and installs fine on current.
| | When trying to build the docs in /usr/docs the program peps calls
|/usr/local/bin/pnmtopng
| | This is from the netpbm port.
|
| I
On 19 Jul 2001, Dag-Erling Smorgrav wrote:
> Bruce Evans <[EMAIL PROTECTED]> writes:
> > I saw this too. It is caused by garbage in the source tree (crtbegin.s
> > in this case) and bug(s) in in the rule to create crtbegin.o). I'm
> > not sure what created the garbage. For me, I think it was c
On Thu, 19 Jul 2001, David Wolfskill wrote:
> >Date: Thu, 19 Jul 2001 02:48:10 -1000 (HST)
> >From: Vincent Poy <[EMAIL PROTECTED]>
>
> > With a July 18, 2001 sources, it seems like the kernel hands at
> >the entropy harvesting stage ctrl-t shows:
>
> >load : 098 cmd : sycctl 51 [running
On Thu, 19 Jul 2001, Alexander Leidinger wrote:
> On 19 Jul, David Wolfskill wrote:
>
> >>It will just sit there forever until ctrl-c is hit. Anyone knows
> >>what's wrong? Thanks.
> >
> > This was discussed (to some extent) aboust a week & a half ago in -current.
> > It seems (pointed
Hi.
I'm running -current whose source tree was checked out as
TZ=UTC cvs co -D'2001-07-12' src
on VAIO PCG-C1XE(PentiumII with 64Mbytes of RAM)
and have some problems:
1. Acpica modules hangs in
AcpiRsCalculateByteStreamLength() called from
AcpiRsCreateByteStream() called from
Acp
> Hi.
> I'm running -current whose source tree was checked out as
> TZ=UTC cvs co -D'2001-07-12' src
> on VAIO PCG-C1XE(PentiumII with 64Mbytes of RAM)
> and have some problems:
>
> 1. Acpica modules hangs in
> AcpiRsCalculateByteStreamLength() called from
> AcpiRsCreateByteStream() ca
Please let me know if you have *any* LD problems with the updated LD.
The proper version (from ld -v) is "2.11.2 20010719 [FreeBSD]".
Note, I plan to MFC this for 4.4.
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-
In article <[EMAIL PROTECTED]> you wrote:
> On Thu, 19 Jul 2001, David Wolfskill wrote:
>
>> >Date: Thu, 19 Jul 2001 02:48:10 -1000 (HST)
>> >From: Vincent Poy <[EMAIL PROTECTED]>
>>
>> > With a July 18, 2001 sources, it seems like the kernel hands at
>> >the entropy harvesting stage ctrl
On Thu, 19 Jul 2001, David Wolfskill wrote:
> >Date: Thu, 19 Jul 2001 02:48:10 -1000 (HST)
> >From: Vincent Poy <[EMAIL PROTECTED]>
>
> > With a July 18, 2001 sources, it seems like the kernel hands at
> >the entropy harvesting stage ctrl-t shows:
>
> >load : 098 cmd : sycctl 51 [running
I now commited ACPI S2-S4BIOS code.
In some machine, there are problem after resume.
For example, keyboard will not work.
(Keyboard reset required in DEVICE_RESUME method.)
But it worked.
Please try it.
Takanori Watanabe
http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html";>
Public Key
Key fing
Hi,
I did a "make release" on a CURRENT (Jul 15) system and find I
can't boot from the CD if my adaptec 29160 SCSI controller &
my Sony SDT-11000 4mm DAT are installed.
The kernel probe successfully finds the devices, but the
booting hangs with "probing for system devices (this may take a while
37 matches
Mail list logo
