On 1/20/13 6:07 PM, Willem Jan Withagen wrote:
> On 17-1-2013 4:18, Ian Lepore wrote:
>> On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote:
>>> Thank you for your response, very helpful.
>>> one question - how do i configure auto-reboot once kernel panic occurs?
>
in advance
Sami
בתאריך 20 בינו 2013 16:07, מאת "Willem Jan Withagen" :
> On 17-1-2013 4:18, Ian Lepore wrote:
> > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote:
> >> Thank you for your response, very helpful.
> >> one question - how do i configure
On 17-1-2013 4:18, Ian Lepore wrote:
> On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote:
>> Thank you for your response, very helpful.
>> one question - how do i configure auto-reboot once kernel panic occurs?
>>
>> Sami
>>
>
> From src/sys/conf/NOT
On Wednesday, January 16, 2013 4:27:53 pm Sami Halabi wrote:
> Thank you for your response, very helpful.
> one question - how do i configure auto-reboot once kernel panic occurs?
Unless you've added DDB and KDB to your kernel it will reboot by default
on a panic. Stable kernel c
2013 at 6:45 AM, Sami Halabi wrote:
> > >
> > > > Its only a kernel option? There is no flag to pass to the loader?
> > > >
> > > > SAMI
> > <> 17 2013 05:18, "Ian Lepore" :
> > > >
> > > >
only a kernel option? There is no flag to pass to the loader?
> > >
> > > SAMI
> <> 17 2013 05:18, "Ian Lepore" :
> > >
> > > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote:
> > >> > Thank you for your response, very helpful.
>
13 at 6:45 AM, Sami Halabi wrote:
>
> > Its only a kernel option? There is no flag to pass to the loader?
> >
> > SAMI
<> 17 2013 05:18, "Ian Lepore" :
> >
> > On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote:
> >> > Thank you for your
3 05:18, מאת "Ian Lepore" :
>
> On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote:
>> > Thank you for your response, very helpful.
>> > one question - how do i configure auto-reboot once kernel panic occurs?
>> >
>> > Sami
&g
Its only a kernel option? There is no flag to pass to the loader?
SAMI
בתאריך 17 בינו 2013 05:18, מאת "Ian Lepore" :
> On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote:
> > Thank you for your response, very helpful.
> > one question - how do i configure auto-reboot
On Wed, 2013-01-16 at 23:27 +0200, Sami Halabi wrote:
> Thank you for your response, very helpful.
> one question - how do i configure auto-reboot once kernel panic occurs?
>
> Sami
>
>From src/sys/conf/NOTES, this may be what you're looking for...
#
# Don't en
Thank you for your response, very helpful.
one question - how do i configure auto-reboot once kernel panic occurs?
Sami
On Wed, Jan 16, 2013 at 10:13 PM, John Baldwin wrote:
> On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote:
> > Hi everyone,
> > I have a production
On Wednesday, January 16, 2013 2:25:33 pm Sami Halabi wrote:
> Hi everyone,
> I have a production box, in which I want to install new kernel without any
> remotd kvn.
> my problem is its 2 hours away, and if a kernel panic occurs I got a
> problem.
> I woner if I can seg fails
Hi everyone,
I have a production box, in which I want to install new kernel without any
remotd kvn.
my problem is its 2 hours away, and if a kernel panic occurs I got a
problem.
I woner if I can seg failsafe script to load the old kernel in case of
psnic.
Sami
Hi,
On 25 Sep 2012, at 21:25, Iordan Iordanov wrote:
> Hi Bob,
>
> On 09/21/12 14:25, Bob Bishop wrote:
>>> #5 0x806ab507 at uart_bus_attaeh+0x187
>>
>> Hmm. Can you disable serial ports in the BIOS? Might be a workaround.
>
> Disabling the serial ports ch
n see that the crash is produced by the
*fr_checknatin()* function (at
/usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c),
in the em0 interface, that then call to a trap (number 12) which becomes
fatal and then that produces a kernel panic.
Looking in the source code of ip_nat.c
n see that the crash is produced by the
*fr_checknatin()* function (at
/usr/src/sys/modules/ipfilter/../../contrib/ipfilter/netinet/ip_nat.c),
in the em0 interface, that then call to a trap (number 12) which becomes
fatal and then that produces a kernel panic.
Looking in the source code of ip_nat.c
on 13/10/2011 17:47 Filippo Sironi said the following:
> Hi guys,
>
> I have an odd problem regarding memory.
> The (slightly) modified kernel of FreeBSD 7.2 I'm using panics with this
> error: "panic: smp_tlb_shootdown: interrupts disabled" upon calling free() on
> three out of four memory buff
Hi guys,
I have an odd problem regarding memory.
The (slightly) modified kernel of FreeBSD 7.2 I'm using panics with this error:
"panic: smp_tlb_shootdown: interrupts disabled" upon calling free() on three
out of four memory buffers I allocate using malloc() in M_TEMP. Unfortunately
no informat
Ok now, all works great IF md root, isn't statically compiled, into the kernel.
When I statically compile it, into the kernel, I get ROOT MOUNT error.
When I list available devices via '?', md0 does exist!
I point mountroot to it, but nada, I get MOUNT ROOT ERROR.
I've tried to statically compile
> Hi,
>
> On Mon, May 16, 2011 at 11:36 AM, wrote:
> > I have a 4 GB or ram, so why kernel panic with my MD ROOT, if larger then
> > ~40 MB?
> > I've tried to split up root in 20MB image and usr in 160 MB
> > Via loader.conf root becomes md0 and usr md1 a
Hi,
On Mon, May 16, 2011 at 11:36 AM, wrote:
> I have a 4 GB or ram, so why kernel panic with my MD ROOT, if larger then
> ~40 MB?
> I've tried to split up root in 20MB image and usr in 160 MB
> Via loader.conf root becomes md0 and usr md1 and panic occurs even when
> they
On Mon, May 16, 2011 at 11:36 AM, wrote:
> I have a 4 GB or ram, so why kernel panic with my MD ROOT, if larger then
> ~40 MB?
> I've tried to split up root in 20MB image and usr in 160 MB
> Via loader.conf root becomes md0 and usr md1 and panic occurs even when
> they are sp
I have a 4 GB or ram, so why kernel panic with my MD ROOT, if larger then
~40 MB?
I've tried to split up root in 20MB image and usr in 160 MB
Via loader.conf root becomes md0 and usr md1 and panic occurs even when
they are split
I had to get rid of md1, to be able to boot with md0 as a
On 11/12/2010 18:28, mezgani ali wrote:
> Can you tell me on which module depend usbbus and uhub ?
>
> On Fri, Nov 12, 2010 at 11:20 PM, jhell wrote:
>
>> On 11/12/2010 16:41, mezgani ali wrote:
>>> Hello,
>>>
>>> I compiled a custom kernel, and i got this error message :
>>>
>>> Root mount wait
Can you tell me on which module depend usbbus and uhub ?
On Fri, Nov 12, 2010 at 11:20 PM, jhell wrote:
> On 11/12/2010 16:41, mezgani ali wrote:
> > Hello,
> >
> > I compiled a custom kernel, and i got this error message :
> >
> > Root mount waiting for: usbbus3
> > uhub3: 8ports with 8 removab
On 11/12/2010 16:41, mezgani ali wrote:
> Hello,
>
> I compiled a custom kernel, and i got this error message :
>
> Root mount waiting for: usbbus3
> uhub3: 8ports with 8 removable, self powered
> Trying to mount root from ufs:/dev/ad0s1a
> ROOT MOUNT ERROR:
> If you have invalid mount, reboot, a
Hello,
I compiled a custom kernel, and i got this error message :
Root mount waiting for: usbbus3
uhub3: 8ports with 8 removable, self powered
Trying to mount root from ufs:/dev/ad0s1a
ROOT MOUNT ERROR:
If you have invalid mount, reboot, and first try
i think that i've missed a device in my con
Ivan Radovanovic wrote:
> I was testing FreeBSD's behavior when running many threads at the same
> time (and I find it performs excellent) when I wanted to test how system
> will behave towards program that spawns itself too many times. I wrote a
> very simple program
>
> #include
> #include
>
Julian Elischer napisa:
Cheng Renquan wrote:
On Mon, Sep 7, 2009 at 6:59 PM, Ivan Radovanovic
wrote:
I was testing FreeBSD's behavior when running many threads at the
same time
(and I find it performs excellent) when I wanted to test how system
will
behave towards program that spawns itself to
ote a very
simple program
#include
#include
int main() {
while(1)
fork();
return 0;
}
After running this program I got kernel panic with message
"get_pv_entry: increase vm.pmap.shpgperproc"
IMHO it is not very good idea to bring entire system down if one process
misbehaves in this w
very
> simple program
>
> #include
> #include
>
> int main() {
> while(1)
> fork();
> return 0;
> }
>
> After running this program I got kernel panic with message
> "get_pv_entry: increase vm.pmap.shpgperproc"
> IMHO it is not very good idea to br
Hi,
On 07/09/2009, at 8:59 PM, Ivan Radovanovic wrote:
...
After running this program I got kernel panic with message
"get_pv_entry: increase vm.pmap.shpgperproc"
IMHO it is not very good idea to bring entire system down if one
process misbehaves in this way, it is maybe much bett
Jan Mikkelsen napisa:
A quick observation: This is not "one process misbehaving", it is a
large number of processes misbehaving. From an administrative point
of view, I think the response is "call setrlimit(RLIMIT_NPROC, ...)",
otherwise the expected behaviour is for your machine to stop makin
fork();
return 0;
}
After running this program I got kernel panic with message
"get_pv_entry: increase vm.pmap.shpgperproc"
IMHO it is not very good idea to bring entire system down if one process
misbehaves in this way, it is maybe much better to kill offending
process and to send this me
On Friday 07 August 2009 19:19:37 cronfy wrote:
> Hello!
>
> Is there a way to find out was system rebooted by power fail or by
> kernel panic?
>
> The problem is that there is no free space on devices to store kernel
> core dump (swap is smaller than physical memory, no more
Hello!
Is there a way to find out was system rebooted by power fail or by
kernel panic?
The problem is that there is no free space on devices to store kernel
core dump (swap is smaller than physical memory, no more dump devices
exist). Will FreeBSD report about panic somehow if it cannot
"Garrett Cooper" writes:
> Dag-Erling Smørgrav writes:
> > Peter Jeremy writes:
> > > If you press any key during the first spinner [...] You can then
> > > enter the name of the program you wish to run - eg /boot/loader.old
> > That won't work - he changed the forth code, not the compiled code
On Mon, Jan 12, 2009 at 6:50 AM, Dag-Erling Smørgrav wrote:
> Peter Jeremy writes:
>> Kamlesh Patel writes:
>> > How do i recover the system from this error. I can't reload the
>> > loader.old
>>
>> If you press any key during the first spinner [...] You can then
>> enter the name of the progra
Peter Jeremy writes:
> Kamlesh Patel writes:
> > How do i recover the system from this error. I can't reload the
> > loader.old
>
> If you press any key during the first spinner [...] You can then
> enter the name of the program you wish to run - eg /boot/loader.old
That won't work - he changed
On 2009-Jan-09 00:05:47 -0800, Kamlesh Patel wrote:
>How do i recover the system from this error. I can't reload the loader.old
If you press any key during the first spinner, you should get a prompt
similar to the following:
>> FreeBSD/i386 BOOT
Default: 0:ad(0,a)/boot/loader
boot:
You can then
Kamlesh Patel wrote:
Hi all,
I am having a problem of kernel panic in FreeBSD 7.0:
In sys/boot/forth/beastie.4th
variable rebootkey
variable mykey (added line)
After building and installing the kernel, when i reboot the system it gives me the following error
Hi all,
I am having a problem of kernel panic in FreeBSD 7.0:
In sys/boot/forth/beastie.4th
variable rebootkey
variable mykey (added line)
After building and installing the kernel, when i reboot the system it gives me
the following error
Hi there,
I changed the following file of FreeBSD 7.0:
sys/boot/forth/beastie.4th
variable rebootkey
variable mykey (added line)
I built and installed kernel, then i reboot the system, it gives me the
following error:
---
" panic: free: gu
lousov" <[EMAIL PROTECTED]>
To: "Steven Hartland" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, December 02, 2008 8:39 PM
Subject: Re: unionfs kernel panic on 7.1-PRERELEASE
Is it reproducible ?
The start of *fdp structure looks very suspicious,
fd_ofiles = 0x140, fd_ofileflags = 0x
ux ABI and unionfs interaction which is causing the
issue.
Regards
Steve
- Original Message -
From: "Kostik Belousov" <[EMAIL PROTECTED]>
To: "Steven Hartland" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, December 02, 2008 8:39 PM
Subject: Re: uni
On Tue, Dec 02, 2008 at 04:42:58PM -, Steven Hartland wrote:
> Not sure where to go with this one any help appreciated:-
> FreeBSD dedicated11.multiplay.co.uk 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE
> #4: Tue Dec 2 16:53:30 UTC 2008
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MULTIPLAY i386
>
>
Not sure where to go with this one any help appreciated:-
FreeBSD dedicated11.multiplay.co.uk 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Tue Dec 2 16:53:30 UTC 2008
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MULTIPLAY i386
kgdb kernel /var/crash/vmcore.1
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free
Hello all, I keep getting a kernel panic every Saturday night, so I
figured I would go through the core dump.
# uname -a
FreeBSD xx.fsklaw.com 7.0-RELEASE FreeBSD 7.0-RELEASE #1: Wed Apr 23
08:01:10 PDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TEST amd64
to# kgdb kernel.symbols
Hi all,
I am getting panic()s upon each shutdown (visibly after disks have been
synced). kgdb reveals the at /usr/src/sys/kern/kern_mutex.c:335
_mtx_lock_sleep() as the culprit.
Running 7.0-RELEASE with root mounted from a ZFS file system. Seems to
only have started since creating a second r
Bartosz Giza wrote:
Hi,
We are using a lot of i386 computers as routers for out network. All of those
routers are using FreeBSD from 4.x to 7.x (exept 5.x)
We are having problem with kernel panic on routers based on 6.x and 7.x while
using tcpdump or trafshow. It is not that always we got
Hi,
We are using a lot of i386 computers as routers for out network. All of those
routers are using FreeBSD from 4.x to 7.x (exept 5.x)
We are having problem with kernel panic on routers based on 6.x and 7.x while
using tcpdump or trafshow. It is not that always we got kernel panics. We got
On 10/24/07, Patrick Dung <[EMAIL PROTECTED]> wrote:
> Hi
>
> I have ZFS (and snapshot) mounted.
> Then shutdown by `shutdown -p now`.
>
> There is the dump:
>
> # kgdb /boot/kernel/kernel.symbols vmcore.0
> [GDB will not be able to debug user-mode threads:
> /usr/lib/libthread_db.so: Undefined sym
Hi
I have ZFS (and snapshot) mounted.
Then shutdown by `shutdown -p now`.
There is the dump:
# kgdb /boot/kernel/kernel.symbols vmcore.0
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free S
Sorry to waste your time. I discovered a similar PR with unp_gc and there
may be a patch already. I will see if that works.
Thanks,
Benjie
On 9/26/07, Benjie Chen <[EMAIL PROTECTED]> wrote:
>
> We got this bt after setting kernel dump stuff up. For some reason kgdb
> did not find debugging symbo
We got this bt after setting kernel dump stuff up. For some reason kgdb did
not find debugging symbols, even though the kernel was compiled with -g.
Hopefully this helps and I will go dig some more to find why we don't have a
debug symbol.
#0 0xc0674fae in doadump ()
#1 0xc067550a in boot ()
#2
You are right, they may not be the same. From first look it seems like they
are similar based on the description of the problems -- system stable, then
under load related to network, get panic after different time intervals. I
just assumed that kernel is typically stable enough that this kind of pa
Well I spoke too soon. I increased the load even more and it crashed again.
Same IP. So FYI, mpsafenet did not work, although it did allow me to stress
the system for longer than I've ever done before. Perhaps that just reduced
the concurrency enough. I will try kernel trace next.
Thanks,
Benjie
On 25/09/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> Not in the sense of transmuting a sleep mutex into a spin mutex, no.
> sleep mutexes will spin when the lock holder is currently running, but
> this happens within the context of the mtx_lock_sleep function itself.
Ok, thanks, this clears
Ivan Voras wrote:
Kris Kennaway wrote:
Does it really? i.e. did you compare the function names in detail and
find that they match precisely, or do you just mean "they are both
panics of some description and I dunno what it all means"? :) I ask
because the linked trace does not involve a spin
Benjie Chen wrote:
You are right, they may not be the same. From first look it seems like
they are similar based on the description of the problems -- system
stable, then under load related to network, get panic after different
time intervals. I just assumed that kernel is typically stable enou
Kris Kennaway wrote:
Does it really? i.e. did you compare the function names in detail and
find that they match precisely, or do you just mean "they are both
panics of some description and I dunno what it all means"? :) I ask
because the linked trace does not involve a spinlock, which means i
Benjie Chen wrote:
Ivan and Kris,
I will try to get a kernel trace -- it may not happen for awhile since I am
not in the office and working remotely for awhile so it may not be easy to
get a trace... but I will check.
It looks like the problem reported by that link, and some of the links from
t
...
Benjie
On 9/24/07, Ivan Voras <[EMAIL PROTECTED]> wrote:
>
> Benjie Chen wrote:
>
> > Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin
> > c066c7b4 T _mtx_lock_spin
> > c066c85c T _mtx_unlock_sleep
> >
> > So this could mea
On 24/09/2007, Benjie Chen <[EMAIL PROTECTED]> wrote:
> Ivan and Kris,
>
> I will try to get a kernel trace -- it may not happen for awhile since I am
> not in the office and working remotely for awhile so it may not be easy to
> get a trace... but I will check.
It's fairly easy:
1) add lines lik
On 24/09/2007, Kris Kennaway <[EMAIL PROTECTED]> wrote:
> Ivan Voras wrote:
> > http://lists.freebsd.org/pipermail/freebsd-current/2007-September/076932.html
>
> Surely it cannot be since it involves a different function ;-)
:)
When all you have is a hammer...
___
Ivan Voras wrote:
Benjie Chen wrote:
Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin
c066c7b4 T _mtx_lock_spin
c066c85c T _mtx_unlock_sleep
So this could mean that independent stress tests will not result in
panic if
there aren't enough concurrency to
Benjie Chen wrote:
Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock_spin
c066c7b4 T _mtx_lock_spin
c066c85c T _mtx_unlock_sleep
So this could mean that independent stress tests will not result in panic if
there aren't enough concurrency to cause the problem.
Wh
Borja Marcos wrote:
On 24 Sep 2007, at 11:33, Kris Kennaway wrote:
Borja Marcos wrote:
I don't have the exact IP address involved, but we experienced
consistent panics in two heavily loaded mail servers (same hardware
models, Dell Powereedge) runnning Postfix and FreeBSD 6.2.
Suspecting an i
On 24 Sep 2007, at 11:33, Kris Kennaway wrote:
Borja Marcos wrote:
I don't have the exact IP address involved, but we experienced
consistent panics in two heavily loaded mail servers (same
hardware models, Dell Powereedge) runnning Postfix and FreeBSD 6.2.
Suspecting an issue with the IP st
Benjie Chen wrote:
Hi FreeBSD hackers and engineers,
I am experiencing a kernel panic that comes on when my new PowerEdge 1950
FreeBSD 6.2 setup is under a certain stress load. I've emailed a few people
on the list who have given me useful comments, some of which I am still
following up.
Borja Marcos wrote:
On 22 Sep 2007, at 00:26, Benjie Chen wrote:
FreeBSD 6.2 on PowerEdge 1950, RAID1 setup with mfi driver (PERC5i). 4GB
RAM. I am currently running i386, and not amd64, due to various reasons.
Kernel panic is at 0xC066C731, which from nm shows it's in mtx_lock
On 22 Sep 2007, at 00:26, Benjie Chen wrote:
FreeBSD 6.2 on PowerEdge 1950, RAID1 setup with mfi driver
(PERC5i). 4GB
RAM. I am currently running i386, and not amd64, due to various
reasons.
Kernel panic is at 0xC066C731, which from nm shows it's in
mtx_lock_spin
c066c
Hi FreeBSD hackers and engineers,
I am experiencing a kernel panic that comes on when my new PowerEdge 1950
FreeBSD 6.2 setup is under a certain stress load. I've emailed a few people
on the list who have given me useful comments, some of which I am still
following up. But I wanted to s
On Jul 7, 2007, at 9:14 PM, M. Warner Losh wrote:
In message: <[EMAIL PROTECTED]>
"M. Warner Losh" <[EMAIL PROTECTED]> writes:
: In message: <[EMAIL PROTECTED]>
: Bert JW Regeer <[EMAIL PROTECTED]> writes:
: : I have a USB 10/100 FastEthernet device, that is identified a
In message: <[EMAIL PROTECTED]>
"M. Warner Losh" <[EMAIL PROTECTED]> writes:
: In message: <[EMAIL PROTECTED]>
: Bert JW Regeer <[EMAIL PROTECTED]> writes:
: : I have a USB 10/100 FastEthernet device, that is identified as a
: : RealTek device. On 6.2-RELEASE it works with
In message: <[EMAIL PROTECTED]>
Bert JW Regeer <[EMAIL PROTECTED]> writes:
: I have a USB 10/100 FastEthernet device, that is identified as a
: RealTek device. On 6.2-RELEASE it works without any issues, and some
: older versions of CURRENT it worked perfectly as well. I csup'ed to
Hello,
I have a USB 10/100 FastEthernet device, that is identified as a
RealTek device. On 6.2-RELEASE it works without any issues, and some
older versions of CURRENT it worked perfectly as well. I csup'ed to
CURRENT today (2007-07-07 at 16:30 MST), rebuild my kernel and it
failed, so I g
On Fri, Jun 08, 2007 at 03:10:10PM +, Allan Jude wrote:
> I recreated it again, and the 'stopped at' in the kernel panic is:
>
> userret+0x22 movq0(%rdi),%rbx
Ok so apparently userret was called with a bogus td arg, can you find
out from where? (there should be
Markus Oestreicher wrote:
Scott Oertel schrieb:
I have 8 machines running 6.2-RELEASE, they're all under pretty
heavy load. All but one is running Dual Opterons on Tyan
motherboards, the other is running 2x Dual Core Xeon, on a
Supermicro mb. I am receiving this panic on all the machines, some
Scott Oertel wrote:
Hello all,
I have 8 machines running 6.2-RELEASE, they're all under pretty heavy
load. All but one is running Dual Opterons on Tyan motherboards, the
other is running 2x Dual Core Xeon, on a Supermicro mb. I am receiving
this panic on all the machines, some of them it happ
Hello all,
I have 8 machines running 6.2-RELEASE, they're all under pretty heavy
load. All but one is running Dual Opterons on Tyan motherboards, the
other is running 2x Dual Core Xeon, on a Supermicro mb. I am receiving
this panic on all the machines, some of them it happens once a month,
ot
- Original Message -
From: "Joe Auty" <[EMAIL PROTECTED]>
To: "Ted Mittelstaedt" <[EMAIL PROTECTED]>
Cc: "Daan Vreeken [PA4DAN]" <[EMAIL PROTECTED]>; "Kip Macy"
<[EMAIL PROTECTED]>; ;
Sent: Monday, February 26, 2007 10:01
- Original Message -
From: "Mike Meyer" <[EMAIL PROTECTED]>
To: "Ted Mittelstaedt" <[EMAIL PROTECTED]>
Cc: "Joe Auty" <[EMAIL PROTECTED]>; "Daan Vreeken [PA4DAN]"
<[EMAIL PROTECTED]>; "Kip Macy" <[EMAIL PROTECT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sort of...
Thanks for everybody that has helped me!
It turns out I had a couple of rc.d scripts in /usr/local/etc/rc.d
that were doing kldloads: rtc.sh and kqemu.sh - one of these was
causing the panic. It might be worthwhile adding to the world
<[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Well,
My system does boot off of disc 1 of the FreeBSD 6.2 CD. However,
even when copying the /boot directory from the CD to my machine, it
still produces the same kernel panic, even when starting in safe
mode. I've ru
ry from the CD to my machine, it
>still produces the same kernel panic, even when starting in safe
>mode.
Can you confirm that you have either deleted or renamed /boot before
replacing it with files from the CD. An out-of-sync module does sound
the most likely problem. If that doesn't h
,
even when copying the /boot directory from the CD to my machine, it
still produces the same kernel panic, even when starting in safe
mode. I've run a memtest, and it checked out fine.
There must be something in my user space or world that it barfs on. I
guess I will try a clean install and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Well,
My system does boot off of disc 1 of the FreeBSD 6.2 CD. However,
even when copying the /boot directory from the CD to my machine, it
still produces the same kernel panic, even when starting in safe
mode. I've run a memtest, a
MAIL PROTECTED]>; ;
Sent: Sunday, February 25, 2007 10:39 PM
Subject: Re: kernel panic at boot on any 6.x OS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 25, 2007, at 7:56 PM, Ted Mittelstaedt wrote:
- Original Message -
From: "Joe Auty" <[EMAIL PROTECTED]>
In <[EMAIL PROTECTED]>, Ted Mittelstaedt <[EMAIL PROTECTED]> typed:
> > For instance, is rebuilding world between point releases (e.g. 5.4 to
> > 5.5) an okay idea, compared to across major releases (e.g. 5.5 to 6.2)?
For the record, I do a rebuild between point releases - actually, I
track -stabl
- Original Message -
From: "Joe Auty" <[EMAIL PROTECTED]>
To: "Ted Mittelstaedt" <[EMAIL PROTECTED]>
Cc: "Daan Vreeken [PA4DAN]" <[EMAIL PROTECTED]>; "Kip Macy"
<[EMAIL PROTECTED]>; ;
Sent: Sunday, February 25, 2007 10:39 P
>; ;
Sent: Sunday, February 25, 2007 8:14 AM
Subject: Re: kernel panic at boot on any 6.x OS
Any idea how this could have happened after disabling everything in
my /etc/loader.conf, and simply running a:
make buildworld
make buildkernel KERNCONF=myconfig
make installkernel KERNCONF=mycon
- Original Message -
From: "Joe Auty" <[EMAIL PROTECTED]>
To: "Daan Vreeken [PA4DAN]" <[EMAIL PROTECTED]>
Cc: "Kip Macy" <[EMAIL PROTECTED]>; ;
Sent: Sunday, February 25, 2007 8:14 AM
Subject: Re: kernel panic at boot on any 6.x OS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 25, 2007, at 11:14 AM, Joe Auty wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 25, 2007, at 5:46 AM, Daan Vreeken [PA4DAN] wrote:
On Sunday 25 February 2007 08:59, Kip Macy wrote:
It looks as if you've hit a device driver th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hey Kip,
I'd gladly try a snapshot kernel, but I'm not sure which one to pick
out of this list:
ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/6.2-RELEASE/kernels
Any suggestions?
On Feb 25, 2007, at 2:59 AM, Kip Macy wrote:
It looks as if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 25, 2007, at 5:46 AM, Daan Vreeken [PA4DAN] wrote:
On Sunday 25 February 2007 08:59, Kip Macy wrote:
It looks as if you've hit a device driver that is trying to print out
a null string. The message you've given doesn't provide any more
info
On Sunday 25 February 2007 08:59, Kip Macy wrote:
> It looks as if you've hit a device driver that is trying to print out
> a null string. The message you've given doesn't provide any more
> information than that. If you install a snapshot kernel it will
> probably have ddb compiled in which will a
It looks as if you've hit a device driver that is trying to print out
a null string. The message you've given doesn't provide any more
information than that. If you install a snapshot kernel it will
probably have ddb compiled in which will allow you to at least get a
backtrace. I'm sorry you're ha
Hello,
(sorry, don't know whether kernel problems should go to questions or
hackers, or both)..
This has been a long-standing problem of mine, but I always ignored
it hoping it would go away on its own with a future 6.x release, but
it remains...
No matter whether I boot into safe mode
Hello,
just some information for the brave to work on:
cat info.0
Dump header from device /dev/ad0s1b
2 Architecture: i386
3 Architecture Version: 2
4 Dump Length: 2138505216B (2039 MB)
5 Blocksize: 512
6 Dumptime: Sun Jan 14 12:59:53 2007
7 Hostname: gahrtop.localhost
8 Ma
1 - 100 of 297 matches
Mail list logo
