> Is your kernel up to r337773 yet? That should have addressed the EFIRT
> boot issue.
>
>
Rebuilding now. Not sure how late I started so I might have missed it.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freeb
On Tue, Aug 14, 2018 at 3:00 PM, Matthias Gamsjager
wrote:
> Ok missed the solution posted earlier: adding ' efi.rt.disabled=1' to
> loader.conf fixed the issue for me as well
Is your kernel up to r337773 yet? That should have addressed the EFIRT
boot issue.
Thanks,
Kyle Evans
_
On 8/14/18, Matthias Gamsjager wrote:
> Hi list,
>
> just compiled current and after reboot into the new kernel the machine
> reboots itself at the marked line below. No further info as the reset is
> sudden. Reboot with the old kernel from 12 aug works. Removed all kernel
> m
Ok missed the solution posted earlier: adding ' efi.rt.disabled=1' to
loader.conf fixed the issue for me as well
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "free
Hi list,
just compiled current and after reboot into the new kernel the machine
reboots itself at the marked line below. No further info as the reset is
sudden. Reboot with the old kernel from 12 aug works. Removed all kernel
modules but with no result.
Any pointers how to approach this?
Aug 14
[ toolchain-metadata.mk is missing when kernel-toolchain is used.
I've no clue if this is intentional or not. ]
On 2018-Jul-16, at 6:13 PM, Mark Millard wrote:
> On 2018-Jul-16, at 4:47 PM, Bryan Drewery wrote:
>
>> On 7/16/2018 3:49 PM, Mark Millard wrote:
>>>
>>>
>>> On 2018-Jul-16, at 3:3
On 2018-Jul-16, at 4:47 PM, Bryan Drewery wrote:
> On 7/16/2018 3:49 PM, Mark Millard wrote:
>>
>>
>> On 2018-Jul-16, at 3:31 PM, Bryan Drewery wrote:
>>
>>> On 7/16/18 1:21 PM, Mark Millard wrote:
I attempted a from-scratch (. . ./arm64.aarch64/ empty) kernel-toolchain
buildker
On 7/16/2018 3:49 PM, Mark Millard wrote:
>
>
> On 2018-Jul-16, at 3:31 PM, Bryan Drewery wrote:
>
>> On 7/16/18 1:21 PM, Mark Millard wrote:
>>> I attempted a from-scratch (. . ./arm64.aarch64/ empty) kernel-toolchain
>>> buildkernel
>>> targeting aarch64 from amd64 based on head -r336349 . I
On 2018-Jul-16, at 3:31 PM, Bryan Drewery wrote:
> On 7/16/18 1:21 PM, Mark Millard wrote:
>> I attempted a from-scratch (. . ./arm64.aarch64/ empty) kernel-toolchain
>> buildkernel
>> targeting aarch64 from amd64 based on head -r336349 . It failed by ending up
>> using an ld that can only ta
On 7/16/18 1:21 PM, Mark Millard wrote:
> I attempted a from-scratch (. . ./arm64.aarch64/ empty) kernel-toolchain
> buildkernel
> targeting aarch64 from amd64 based on head -r336349 . It failed by ending up
> using an ld that can only target elf_x86_64_fbsd elf_i386_fbsd :
I probably extended th
I attempted a from-scratch (. . ./arm64.aarch64/ empty) kernel-toolchain
buildkernel
targeting aarch64 from amd64 based on head -r336349 . It failed by ending up
using an ld that can only target elf_x86_64_fbsd elf_i386_fbsd :
. . .
--- buildkernel ---
Building
/usr/obj/cortexA53_clang/arm64.aar
> On Jun 5, 2017, at 08:20, Bryan Drewery wrote:
>
> On 6/5/2017 2:34 AM, Alexander Leidinger wrote:
>>
>> Quoting Bryan Drewery (from Sun, 4 Jun 2017 14:38:07
>> -0700):
>>
>>> On 6/4/17 5:09 AM, Alexander Leidinger wrote:
>>>> Hi,
&g
On 6/5/2017 2:34 AM, Alexander Leidinger wrote:
>
> Quoting Bryan Drewery (from Sun, 4 Jun 2017 14:38:07
> -0700):
>
>> On 6/4/17 5:09 AM, Alexander Leidinger wrote:
>>> Hi,
>>>
>>> new kernel (surely r318877 and later) and old syslog in a jail = N
Quoting Bryan Drewery (from Sun, 4 Jun 2017
14:38:07 -0700):
On 6/4/17 5:09 AM, Alexander Leidinger wrote:
Hi,
new kernel (surely r318877 and later) and old syslog in a jail = NOK.
What branch and revision is the syslogd? From my understanding the bug
exists in a head version of
Hi,
new kernel (surely r318877 and later) and old syslog in a jail = NOK.
I remember some mails about syslog going 100% COU some weeks ago, but
thought it was solved. As we have the goal to keep backward
compatibility, what is the issue here? I have this in the kernel:
---snip---
options
s the
>>> main reason
>>> for another breakage in HEAD.
>>
>> Does this fix the broken ifconfig on new kernel + old world?
>
> Amongst other things, yes.
Awesome, thanks! It bit me again recently, but fortunately I knew the
answer already.
Doug
--
On 11. Feb 2012, at 06:19 , Doug Barton wrote:
> On 02/10/2012 22:15, Bjoern A. Zeeb wrote:
>> Hey,
>>
>> as the UPDATING message says, if you updated your HEAD between 2011-12-15
>> and now
>> you need to recompile libc again with the new kernel. If you are
On 02/10/2012 22:15, Bjoern A. Zeeb wrote:
> Hey,
>
> as the UPDATING message says, if you updated your HEAD between 2011-12-15 and
> now
> you need to recompile libc again with the new kernel. If you are updating
> from
> outside that window, especially from any STABLE
Hey,
as the UPDATING message says, if you updated your HEAD between 2011-12-15 and
now
you need to recompile libc again with the new kernel. If you are updating from
outside that window, especially from any STABLE branch, things should be a lot
more
happy now, which (in addition to make the
On Fri, Nov 14, 2003 at 06:38:28AM +1100, Bruce Evans wrote:
> On Thu, 13 Nov 2003, John Hay wrote:
>
> > Is it ok to run a new kernel (after the statfs changes) and older
> > programs? I thought so from what i gathered out of the commit
> > messages, but my test bo
On Thu, 13 Nov 2003, John Hay wrote:
> Is it ok to run a new kernel (after the statfs changes) and older
> programs? I thought so from what i gathered out of the commit
> messages, but my test box doesn't like it at all... Well except
> if something else broke stuff:
I have n
Hi,
Is it ok to run a new kernel (after the statfs changes) and older
programs? I thought so from what i gathered out of the commit
messages, but my test box doesn't like it at all... Well except
if something else broke stuff:
##
...
Mounting root from ufs:/dev/da0s1a
pid 50 (sh),
Ian Freislich wrote:
> Andre Guibert de Bruet wrote:
> > Ian,
> >
> > The new ipfw binary will work with an up-to-date kernel. What you need to
> > do is boot this new kernel and only then try out the new ipfw binary.
>
> That doesn't really explain why the
es instead of the new ones. You may also be
> > missing a cvs update on the ipfw sources themselves (specifically,
> > ipfw2.c).
>
> No, it did compile ipfw2.c (r1.24). I also installed all new
> includes before I compiled ipfw and re-worlding to no avail. I
> figured an old kernel
Yep got it all figured out now. I didn't realize that the interface had
changed, so I built a new kernel and rebooted before an installworld and
ipfw bitched at me. Lesson learnt ;)
Thanks for the feedback
-John
Alas make buildworld fails for the past few days:
===> usr.sbi
> Alas make buildworld fails for the past few days:
> ===> usr.sbin/config
>
[snip]
> > Short term, cd /usr/src/sbin/ipfw; make depend && make all install ought
> > to fix it.
>
> I tried that as well, but the new binary also dumps core, but works
> well with previous versions of the firewal
Try rebuilding ipfw.
Ken
On Mon, 9 Jun 2003, John Stockdale wrote:
> Hey everyone,
>
> I just cvsup'd my src today and was going to buildworld later tonight
> but when I installed the newly built kernel with IPFIREWALL etc. and
> rebooted, ipfw fell over, specifically, even after ipfw firewall e
On Tue, 10 Jun 2003, Ian Freislich wrote:
> Andre Guibert de Bruet wrote:
> >
> > The new ipfw binary will work with an up-to-date kernel. What you need to
> > do is boot this new kernel and only then try out the new ipfw binary.
>
> That doesn't really expl
Andre Guibert de Bruet wrote:
> Ian,
>
> The new ipfw binary will work with an up-to-date kernel. What you need to
> do is boot this new kernel and only then try out the new ipfw binary.
That doesn't really explain why the new ipfw binary core dumped
with the new kernel, but wor
Ian,
The new ipfw binary will work with an up-to-date kernel. What you need to
do is boot this new kernel and only then try out the new ipfw binary.
Regards,
> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/>
On
, it did compile ipfw2.c (r1.24). I also installed all new
includes before I compiled ipfw and re-worlding to no avail. I
figured an old kernel with a working firewall was better than a new
kernel with no firewall.
Ian
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Ian Freislich wrote:
> Alas make buildworld fails for the past few days:
> ===> usr.sbin/config
>
> In file included from config.c:1:
> /usr/include/stdlib.h:102: conflicting types for `restrict'
> /usr/include/stdlib.h:102: previous declaration of `restrict'
> /usr/include/stdlib.h:102: warning:
"Daniel C. Sobral" wrote:
> John Stockdale wrote:
> > Hey everyone,
> >
> > I just cvsup'd my src today and was going to buildworld later tonight
> > but when I installed the newly built kernel with IPFIREWALL etc. and
> > rebooted, ipfw fell over, specifically, even after ipfw firewall enable,
John Stockdale wrote:
Hey everyone,
I just cvsup'd my src today and was going to buildworld later tonight
but when I installed the newly built kernel with IPFIREWALL etc. and
rebooted, ipfw fell over, specifically, even after ipfw firewall enable,
an ipfw show resulted in a core dump. If its us
Hey everyone,
I just cvsup'd my src today and was going to buildworld later tonight
but when I installed the newly built kernel with IPFIREWALL etc. and
rebooted, ipfw fell over, specifically, even after ipfw firewall enable,
an ipfw show resulted in a core dump. If its useful, I can post the i
On Wed, Oct 30, 2002 at 01:14 -0700, M. Warner Losh wrote:
>
> UPDATING has the closest thing to a comprehensive guide. As far as I
> can tell, it is definitive in its list of potential issues, but if I'm
> wrong, let me know.
>
> I'm just glad I don't have to document all the things that mergem
In message: <[EMAIL PROTECTED]>
Doug Barton <[EMAIL PROTECTED]> writes:
: This should go on the "Comprehensive guide to updating from source to 5.0"
: that I'm sure our trusty release engineers are producing?
UPDATING has the closest thing to a comprehensive guide. As far as I
can tel
If memory serves me right, Doug Barton wrote:
> This should go on the "Comprehensive guide to updating from source to 5.0"
> that I'm sure our trusty release engineers are producing?
Some of this is described in the early adopter's guide (still a work in
progress) that I committed to the release
IMO it's more a matter of POLA for those upgrading to -current for the
first time. For those that don't realize exactly how different 5.x is,
spelling out the steps of installing device.hints, installing the new
loader, etc. makes their life easier.
This should go on the "Comprehensive guide to up
< said:
> /boot/loader though is a different story. 'make installkernel' does not
> install the new loader. However, most non-ancient 4.x loaders can
> boot a 5.x kernel sufficiently well that this shouldn't be a crisis. Or,
> they used to be able to when I last tried it (not too long ago).
In message: <[EMAIL PROTECTED]>
Peter Wemm <[EMAIL PROTECTED]> writes:
: If it does need them, somebody had better tell my systems. I've got old
: 3.x bootblocks on some of them.
Sorry, you are right.
: /boot/loader though is a different story. 'make installkernel' does not
: instal
"M. Warner Losh" wrote:
> In message: <[EMAIL PROTECTED]>
> Tim Kientzle <[EMAIL PROTECTED]> writes:
> : Peter Wemm wrote:
> :
> : > 'make installworld' without ... a new kernel would be rather messy.
> :
> : > ... a remin
In message: <[EMAIL PROTECTED]>
Tim Kientzle <[EMAIL PROTECTED]> writes:
: M. Warner Losh wrote:
:
: > Tim Kientzle <[EMAIL PROTECTED]> writes:
:
: > : ... 'installkernel' is not filling it's contract: it is
: > : not ensuring that the next
On Mon, Oct 28, 2002 at 11:56:34AM -0800, Tim Kientzle wrote:
> M. Warner Losh wrote:
>
> >Tim Kientzle <[EMAIL PROTECTED]> writes:
>
> >: ... 'installkernel' is not filling it's contract: it is
> >: not ensuring that the next boot uses the new ker
M. Warner Losh wrote:
Tim Kientzle <[EMAIL PROTECTED]> writes:
: ... 'installkernel' is not filling it's contract: it is
: not ensuring that the next boot uses the new kernel.
Are you sure you need new bootblocks? I've not had issues and am
pretty careless about
> Nearly all GNOME applications crash with an "Abort trap" error, and the
> only way I can log out is to restart the X server. Nautilus is
> particularly evil because it can get into a situation where it crashes,
> restarts itself, and crashes again--repeating the process indefinitely.
I'm runn
Juli Mallett wrote:
* De: Patrick Hartling <[EMAIL PROTECTED]> [ Data: 2002-10-28 ]
[ Subjecte: Re: HEADS UP: you need to install a new kernel before an installworld. ]
Peter Wemm wrote:
Due to sigaction(2) syscall number changes, doing a 'make installworld'
without hav
* De: Patrick Hartling <[EMAIL PROTECTED]> [ Data: 2002-10-28 ]
[ Subjecte: Re: HEADS UP: you need to install a new kernel before an
installworld. ]
> Peter Wemm wrote:
> > Due to sigaction(2) syscall number changes, doing a 'make installworld'
> > without h
Peter Wemm wrote:
Due to sigaction(2) syscall number changes, doing a 'make installworld'
without having booted a new kernel would be rather messy. For example, if
you tried to reboot with the old kernel, /sbin/init and /bin/sh would get a
signal and abort. That would be bad.
Does
In message: <[EMAIL PROTECTED]>
Tim Kientzle <[EMAIL PROTECTED]> writes:
: Peter Wemm wrote:
:
: > 'make installworld' without ... a new kernel would be rather messy.
:
: > ... a reminder of the sequence is probably in order:
: > buildworld
: &g
On Sat, Oct 26, 2002 at 11:42:02AM -0700, Tim Kientzle wrote:
> Peter Wemm wrote:
>
> >'make installworld' without ... a new kernel would be rather messy.
>
> >... a reminder of the sequence is probably in order:
> > buildworld
> > buildkernel
&g
Quoting Tim Kientzle <[EMAIL PROTECTED]>:
| Peter Wemm wrote:
|
| > 'make installworld' without ... a new kernel would be rather messy.
|
| > ... a reminder of the sequence is probably in order:
| > buildworld
| > buildkernel
| > installkernel
Peter Wemm wrote:
'make installworld' without ... a new kernel would be rather messy.
... a reminder of the sequence is probably in order:
buildworld
buildkernel
installkernel
reboot
installworld
reboot
This _does_not_work_ because 'installkernel' does
not update
Due to sigaction(2) syscall number changes, doing a 'make installworld'
without having booted a new kernel would be rather messy. For example, if
you tried to reboot with the old kernel, /sbin/init and /bin/sh would get a
signal and abort. That would be bad.
I've added an ant
On Mon, 27 May 2002, Nick Hibma wrote:
> CONSPEED is used for both console and gdb. This is a bit awkward because
> it means that I have to run my kernel console on 9600 baud on my
> diskless box. The attached patch fixes this by introducing another
> variable GDBSPEED.
>
> The patch makes the de
CONSPEED is used for both console and gdb. This is a bit awkward because
it means that I have to run my kernel console on 9600 baud on my
diskless box. The attached patch fixes this by introducing another
variable GDBSPEED.
The patch makes the default for GDBSPEED 9600, so anyone who uses a
high
On Sat, Dec 30, 2000 at 11:58:05AM -0500, Raymond Hicks wrote:
> Please respond directly to [EMAIL PROTECTED] as I am not on this mailing
> list..
>
> I am hoping that this is not something I am doing wrong ... the procedur
> ei followed was cvsup src and ports... using supfile in handbook for
Please respond directly to [EMAIL PROTECTED] as I am not on this mailing
list..
I am hoping that this is not something I am doing wrong ... the procedur
ei followed was cvsup src and ports... using supfile in handbook for
going to current.. from there i did /usr/src make buildworld then make
i
From: Ilya Naumov <[EMAIL PROTECTED]>
Date: Fri, 7 Jul 2000 16:47:39 +0400 (MSD)
::
::i'm experiencing a problem with vmware2 build 570 (installed from
::ports) and latest kernels. vmware runs perfectly with kernel built on
::July, 3, but crashes my box with later kernel versions (July, 6 and
::7)
i'm experiencing a problem with vmware2 build 570 (installed from
ports) and latest kernels. vmware runs perfectly with kernel built on
July, 3, but crashes my box with later kernel versions (July, 6 and
7). any ideas?
sincerely,
ilya naumov (at work)
To Unsubscribe: send mail to [EMAIL PROT
> * Julian Elischer <[EMAIL PROTECTED]> [000627 12:36] wrote:
> > So I cvsupped yesterday, and tehn made a new kernel.
> > so suddenly ssh doesn't work any more.
>
> cvsup again and recompile and reload the randomdev module, it should
> resume working.
And ``
Julian,
"me too."
Note that if I go back to kernel.saved, it works again.
--Bosko
On Tue, 27 Jun 2000, Julian Elischer wrote:
> So I cvsupped yesterday, and tehn made a new kernel.
> so suddenly ssh doesn't work any more.
>
> it says:
>
&g
* Julian Elischer <[EMAIL PROTECTED]> [000627 12:36] wrote:
> So I cvsupped yesterday, and tehn made a new kernel.
> so suddenly ssh doesn't work any more.
cvsup again and recompile and reload the randomdev module, it should
resume working.
-Alfred
To Unsubscribe: se
| ssh: no RSA support in libssl and libcrypto. See ssl(8).
| Disabling protocol version 1
| Protocol major versions differ: 2 vs. 1
i just had the same problem. this was probably discussed
in the /dev/[u]random thread and i missed it.
you can either kldload /modules/randomdev.ko or add
"option
So I cvsupped yesterday, and tehn made a new kernel.
so suddenly ssh doesn't work any more.
it says:
jules# ssh www.elischer.org
ssh: no RSA support in libssl and libcrypto. See ssl(8).
Disabling protocol version 1
Protocol major versions differ: 2 vs. 1
jules#
luckily /usr/local/bi
Hello,
I had a pre-config-change kernel that picked up my PCM audio nicely
pcm0: at port
0x220-0x233,0x530-0x537,0x388-0x38f,0x330-0x333,0x538-0x539 irq 5 drq 1,0 on isa0
Today, with a post-config-change kernel, I don't detect it at boot.
Both kernel configs have the same pcm config line:
d
On Tuesday, June 13, 2000, John DeBoskey wrote:
> modules-install modules-install.debug:
> .if !defined(NO_MODULES_OLD)
> mkdir -p ${DESTDIR}/modules.old
> cp -p ${DESTDIR}/modules/* ${DESTDIR}/modules.old
I'd suggest changing the above line to:
test -f ${DESTDIR}/mod
Hi,
On a freshly installed snap (5.0-2612-SNAP), after
compiling up a new kernel, the make install fails.
Basically, it tries to 'cp /modules/* /modules.old'
but /modules is empty and the cp fails. We need to
either recognize an empty directory, or not fail
if the cp fail
David Gilbert wrote:
>
> Well... I copied the new(er) versions of the loader from my
> workstation to /boot on the laptop and then "disklabel -B wd0" on the
> laptop. Is there some other (non-obvious) step required?
No, there isn't.
The version you want is 0.7. That's the version on FreeBSD 3.
> "Daniel" == Daniel C Sobral <[EMAIL PROTECTED]> writes:
Daniel> David Gilbert wrote:
>> This is what it says:
>>
>> /kernel.G4 text=0x1f5482 elf_loadexec: archsw.readin failed can't
>> load module '/kernel.G4': input/output error
>>
>> ... both errors were much the same. Now... I though
David Gilbert wrote:
>
> This is what it says:
>
> /kernel.G4 text=0x1f5482
> elf_loadexec: archsw.readin failed
> can't load module '/kernel.G4': input/output error
>
> ... both errors were much the same. Now... I thought that this might
> be that the boot loaders needed to be updated (the on
In preparation for upgrading my laptop, I made it a 4.0-CURRENT kernel
(cvsup'd Saturday morning) and tried to boot. When this didn't work,
I made a GENERIC kernel (just in case some combination that I'd chosen
was borked)... and it failed, too.
This is what it says:
/kernel.G4 text=0x1f5482
Yes! That is exactly the problem I have been having since the 1999/10/09 12:57:15 PDT
ATA commit. Here is the link to the email I sent earlier:
http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=1326170+1331912+/usr/local/www/db/text/1999/freebsd-current/19991212.freebsd-current
Basically, on my Pen
Hi,
Before people start wondering about my name being mangled in the From:
field of my previous message: Sorry, it happens regularly when cutting
and pasting into the mailer of the Netscape Communicator 4.7. Maybe I
have to switch to another mailtool...
Cheers,
Hans
To Unsubscribe: send mail
Matthew Dillon wrote:
>
> Well guys, I tried upgrading one of my older machines today to the
> latest 4.0. It was running an older 4.0 kernel (Nov 29 1999).
>
[ Detailed description deleted ]
> HELP! Whats happening!!! :-( :-( :-(
>
> At the moment I am stymied. I s
Matthew Dillon wrote:
>
> Well guys, I tried upgrading one of my older machines today to the
> latest 4.0. It was running an older 4.0 kernel (Nov 29 1999).
>
..
> HELP! Whats happening!!! :-( :-( :-(
>
> At the moment I am stymied. I switched to a GENERIC kernel
In message <[EMAIL PROTECTED]> Doug Ambrisko writes:
: Tonight I will try to define
: ATA_16BIT_ONLY
: in my kernel and try to boot with ata. This may have to be set in GENERIC
: for installs to work ... or the ata driver learn how to figure this out
: automatically on the fly.
Look at m
:Anyways more work and lots of testing needs to be done. Even though I like
:the new ata stuff and use it on all machines (except for one) this is scary
:since a bunch of 4.0 users could get screwed with older good hardware.
:
:Tonight I will try to define
: ATA_16BIT_ONLY
:in my kernel
Matthew Dillon writes:
| Well guys, I tried upgrading one of my older machines today to the
| latest 4.0. It was running an older 4.0 kernel (Nov 29 1999).
I ran into a similar problem when upgrading my server at home. It is an
old 486 with an Intel Saturn chipset. I found the IDE dri
It seems Matthew Dillon wrote:
>
> :From what I can tell so far, something during the kernel boot is
> :disabling the timer interrupt. The ATA probe does a tsleep() which
> :never times out. Output is queued to the console during the boot
> :sequence which is never printed (unti
:From what I can tell so far, something during the kernel boot is
:disabling the timer interrupt. The ATA probe does a tsleep() which
:never times out. Output is queued to the console during the boot
:sequence which is never printed (until I CTL-ALT-ESC)...
:
:has someone m
:
:: * First, it locks up with process 0 stuck in 'atawait' while
:
:
: I meant 'atacmd' here.
:
: -Matt
From what I can tell so far, something
: * First, it locks up with process 0 stuck in 'atawait' while
I meant 'atacmd' here.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
Well guys, I tried upgrading one of my older machines today to the
latest 4.0. It was running an older 4.0 kernel (Nov 29 1999).
I've included the dmesg output from the (successfully booting) older
kernel at the end.
The newer kernel locks up in several ways:
* Fi
hello,
I make world and new kernel with ctm source up to src-cur.4115
successfully. However, my system go to panic when I boot it with new
kernel. The error was
=== Error ===
resume IOPL = 0
interrupt mask none <-- SMPXXX
trap number = 12
mp_lock = 0102 cpuid = 1
boot() c
IL PROTECTED]>
Sent: Friday, November 19, 1999 6:03 PM
Subject: Re: Compile new kernel with MCA support
> [moved to -current]
>
> On Friday, 19 November 1999 at 17:27:15 -0500, Jason Craig wrote:
> On Friday, 19 November 1999 at 17:32:20 -0500, Jason Craig wrote:
> On Friday, 19
> I am quite well aware of the mailing list etiquette. I read through many of
> them frequently.
Then you're aware that cross posts are also strongly frowned upon,
especially on both -current and -hackers. Only one mailing list at a
time please, no cross posts.
- Jordan
To Unsubscribe: send
Ok..in addition to my earlier post, I am NOT using Linux netscape and I
built the whole system from the source code. dist/module/kernel they are
all from the same source tree. The thing is I never had this kind of
problem before. It was working fine then.
I built the world/kernel at Tue Nov
On Thu, 11 Nov 1999, Byung Yang wrote:
>
> I supped two days ago and compiled everything. Now, if I try to launch
> netscape, the computer just freezes right up there. First, I thought it
> was the netscape, but when I was searching for a file on my computer, but
> took longer than I thought a
On Thu, 11 Nov 1999, Stephan van Beerschoten wrote:
> On Thu, Nov 11, 1999 at 08:36:11AM +, Byung Yang wrote:
> > I supped two days ago and compiled everything. Now, if I try to launch
> > netscape, the computer just freezes right up there. First, I thought it
> > was the netscape, but when
On Thu, Nov 11, 1999 at 08:36:11AM +, Byung Yang wrote:
> I supped two days ago and compiled everything. Now, if I try to launch
> netscape, the computer just freezes right up there. First, I thought it
> was the netscape, but when I was searching for a file on my computer, but
> took longer
I supped two days ago and compiled everything. Now, if I try to launch
netscape, the computer just freezes right up there. First, I thought it
was the netscape, but when I was searching for a file on my computer, but
took longer than I thought and pressed ^C, it froze again.
I heard and also s
I run pre-signal-change-current on my
gateway-apache-squid-imap-sendmail-mysql-roxen server and
post-signal-change-current on my other box.
I have compiled a new kernel on the post-signal-change machine, and
installed it (as kernel.new) on the old machine.
But I get a panic, trap 12 while in
After the vm subsystem changes that went in yesterday, I expierence crashes
under heavy load situations (typically when running quake2 in OpenGL mode). A
kernel built on the 23rd works fine. A kernel backtrace follows
# gdb -k kernel.debug /var/crash/vmcore.12
GNU gdb 4.18
Copyright 1998 Free S
Brian Feldman wrote:
> On Mon, 19 Apr 1999, Ilya Naumov wrote:
>
> >
> > i have compiled the latest kernel and encountered a problem with IPDIVERT.
even
> > with "options IPDIVERT" string in kernel config, kernel says the following:
> >
> > IP packet filtering initialized, divert disabled,
On Mon, 19 Apr 1999, Ilya Naumov wrote:
>
> i have compiled the latest kernel and encountered a problem with IPDIVERT.
> even
> with "options IPDIVERT" string in kernel config, kernel says the following:
>
> IP packet filtering initialized, divert disabled, rule-based forwarding
> disabled, lo
i have compiled the latest kernel and encountered a problem with IPDIVERT. even
with "options IPDIVERT" string in kernel config, kernel says the following:
IP packet filtering initialized, divert disabled, rule-based forwarding
disabled, logging disabled
of course, firewall rules like "add dive
[moved to -current]
On Friday, 19 November 1999 at 17:27:15 -0500, Jason Craig wrote:
On Friday, 19 November 1999 at 17:32:20 -0500, Jason Craig wrote:
On Friday, 19 November 1999 at 17:38:07 -0500, Jason wrote:
> Hello all,
>
> I have a few FreeBSD machines that I am playing around with now, and
>Did a make world and then
>rm -rf ../../compile/TITAN
>config TITAN
>cd ../../compile/TITAN
>make depend all
>
>See errors below ...
>
>Am I missing something ?
See
http://www.freebsd.org/~yokota/sc_update.txt
and update your kernel config file.
Kazu
To Unsubscribe: send mail to majo
Did a make world and then
rm -rf ../../compile/TITAN
config TITAN
cd ../../compile/TITAN
make depend all
See errors below ...
Am I missing something ?
loading kernel
syscons.o: In function `scvidprobe':
syscons.o(.text+0x231): undefined reference to `vid_configure'
syscons.o(.text+0x24e): und
1 - 100 of 102 matches
Mail list logo
