It was pointed out to me that the example in freebsd.mc has been double-quoted
for some time. That's what I get for carrying old config files around for too
long I suppose. Sorry for the noise and thanks again all for the prompt replies.
On Aug 22, 2010, at 3:48 PM, John Nielsen wrote:
l: MCA: CPU 0 COR BUSLG Source RD Memory
> > kernel: MCA: Address 0x7ff670
>
> I believe that you get correctable RAM ECC errors, but not entirely sure.
> There is mcelog utility that decodes such messages into human-friendly
> descriptions.
> The utility is available on Linux-b
of buildworld/buildkernel -- using the
> existing tools... That, however, breaks in the most unexpected place:
Your libstand is too stale.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-st
On Monday, August 23, 2010 5:35:40 pm Matthew D. Fuller wrote:
> On Mon, Aug 23, 2010 at 08:20:35AM -0400 I heard the voice of
> John Baldwin, and lo! it spake thus:
> >
> > It is not private, it is in //depot/projects/mcelog/... in p4.
>
> Which may as well be Siberia for
On Wednesday, August 25, 2010 12:05:09 am Matthew D. Fuller wrote:
> On Tue, Aug 24, 2010 at 11:06:43AM -0400 I heard the voice of
> John Baldwin, and lo! it spake thus:
> >
> > It is actually public at perforce.freebsd.org. :) However, it is
> > tedious to download
corrected errors have to be polled and the
kernel polls once an hour. On newer Intel CPUs (such as Nehalem) there is a
separate interrupt (CMCI) that can fire for corrected errors.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.
hat could this be? All modules (including ath_hal) build correctly...
> Thank you!
You are missing:
options AH_SUPPORT_AR5416 # enable AR5416 tx/rx descriptors
For the 6.x -> 8 upgrade you are doing, I strongly suggest looking at the
changes to GENERI
ects, layout of memory lanes on motherboard, etc.
A while back I found a slide deck from some Intel presentation that claimed
that a modern 4GB DIMM should average 18 corrected errors a month. Your
rate is a bit higher than that, but corrected ECC errors are not that
unexpected.
--
John Baldwin
_
1 How to Find Access Points.
Yes, even with ndis (which is what I use for this adapter, albeit on i386),
you have to use wlan. (ndis on i386 will not have the 'fpudna' issues since
32-bit Windows drivers do not use SSE instructions.) Even with ndis I have to
run ndis_events for WPA aut
roadcom.
For ndis_events you just need to run it without any arguments. I think you
can run it after wpa_supplicant has been started.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
p() at calltrap+0x6
> --- trap 0xc, eip = 0xc3192477, esp = 0xcce578d0, ebp = 0xcce578e0 ---
> e1000_clear_hw_cntrs_base_generic(c2651004,64,c3185850,c2651000,0,...)
> at e1000_clear_hw_cntrs_base_generic+0x3e7
Can you use gdb on your kernel.debug to map this to a source file and line?
--
John Bald
On Wednesday, September 01, 2010 1:11:31 pm pluknet wrote:
> On 1 September 2010 20:06, John Baldwin wrote:
> > On Wednesday, September 01, 2010 11:53:09 am pluknet wrote:
> >> Hi.
> >>
> >> This is reproducible from time to time on boot when
> >> han
cess,v confuse it because moving that file
away make the crash go away. I still have the old access,v if somebody
is interested. A diff does not show anything wierd that I can see.
John
--
John Hay -- j...@meraka.csir.co.za / j...@freebsd.org
--- /tmp/access,v-csup.crash2010-07-31 16:57:51.0
of really old ISA NICs that only do 10Mbps).
Even in that case, the code will always live on in the source code control
repository's history. That means it can always be resurrected if someone shows
up who will maintain it and keep it up to date.
At this point I think this
[ Trimming cc's a bit ]
On Wednesday, September 08, 2010 10:01:22 am Vadim Goncharov wrote:
> Hi John Baldwin!
>
> On Wed, 8 Sep 2010 08:42:28 -0400; John Baldwin wrote about 'Re: Policy for
> removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs
coming soon)
gt;
> > # Write to kernel memory via /dev/mem and /dev/kmem.
> >
> > So I assume it also restricts reading /dev/kmem ?
> >
> >
> OH YUCK, another root isn't really root, so is it also possibly
> the reason for the MSIX failure?? Is this pile, er feature,
On Thursday, September 09, 2010 3:04:27 pm Jack Vogel wrote:
> On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin wrote:
>
> > On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote:
> > > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote:
> > >
> > > >
77 with O_RDWR
> >
> > Ah. I'll have to schedule a reboot then ..
>
> or hack on pciconf.c to not request more permission than it needs.
> It is arguably a bug to open O_RDWR when only examining things.
You have to have RDWR permission to issue the ioctl to read config
re
but it handles it
OK:
...
Rsync CVSROOT-src/access
Edit CVSROOT-src/access,v
CVSROOT-src/access,v: Invalid RCS file: 16249: "String" expected -- will
transfer entire file
...
Applying fixups for collection cvs-all/cvs
Fixup CVSROOT-src/access,v
--
John Marshall
pgp5QlyC3Npm2.pgp
Description: PGP signature
per...@pluto.rain.com wrote:
John Baldwin wrote:
On Friday, September 10, 2010 2:55:15 am per...@pluto.rain.com wrote:
...
It is arguably a bug to open O_RDWR when only examining things.
You have to have RDWR permission to issue the ioctl to read config
registers which pciconf does when
ot/loader.conf ... At least it worked when I first
> installed that machine in September 2000 (yeah, exactly 10
> years ago) with FreeBSD 4.1, then updated it roughly every
> two years ... And it stopped working in 8.x.
Did you update your hints to rename the 'sio' hints to
On Monday, September 13, 2010 11:55:27 am Oliver Fromme wrote:
> John Baldwin wrote:
> > On Monday, September 13, 2010 8:49:48 am Oliver Fromme wrote:
> > > Now I get your point ... Yes, -P does probe the keyboard
> > > first. That's probably why I see t
t rates "higher" than yours? If you're focused on
> the cpuX entries, don't be.
>
> To the OP:
>
> 1) I don't see how/why USB Legacy support would have anything to do with
> your problem (meaning: you stated that things "improved a little" if y
GARGS+='--disable-ipv6'
> +.endif
>
> # Optional features
> .if ${MK_BIND_LARGE_FILE} == "yes"
>
> and leave it to the user to build world without INET6 support if (s)he
> build the kernel without it?
Actually, I frequently build custom kernels w/o INET6, but
truly handle hotplug devices and 'PNP OS == YES', so this is really
FreeBSD's fault rather than ACPI or the BIOS.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
e intel datasheet says at a maximum power of 95w, the
maximum permitted temperature is 72.7C. For the i5-650 at 73w, the maximum
permitted temperature is 66C.
John Theus
TheUsGroup.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org
esn't really cause any problems.
A true uncorrected machine check would trigger a MC# fault and panic. I think
this is just garbage in the MCx banks. Are you running the latest 8-stable?
The change to reset the banks on resume was MFC'd in r210509 on July 26.
--
John Baldwin
___
00806, Status 0x
> MCA: Vendor "GenuineIntel", ID 0x6fb, APIC ID 3
> MCA: CPU 3 UNCOR PCC OVER BUSL0 Source ERR Memory
Are you getting a panic when this happens?
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http:
On Thursday, September 30, 2010 10:53:14 am Vitaly Magerya wrote:
> John Baldwin wrote:
> > A true uncorrected machine check would trigger a MC# fault and panic. I
> > think
> > this is just garbage in the MCx banks. Are you running the latest
> > 8-stable?
>
On Thursday, September 30, 2010 12:33:24 pm Adam Vande More wrote:
> On Thu, Sep 30, 2010 at 8:40 AM, John Baldwin wrote:
>
> > On Thursday, September 30, 2010 2:49:24 am Adam Vande More wrote:
> > > For awhile now, my home server has been acting up. Actually it had a bad
apci6 18112 3
cpu0: timer 9133048 1999
cpu1: timer 9126434 1998
cpu2: timer 9130320 1999
cpu3: timer 9130448 1999
Total
On Thu, Oct 07, 2010 at 02:35:31PM +0200, Ivan Voras wrote:
> On 10/07/10 14:15, John Hay wrote:
> >Hi,
> >
> >I got hold of a SunFire X4500 with 48 X 500G disks and thought to try
> >FreeBSD 8-stable with zfs on it.
> >
> >I have setup the two boot disks in
On Thu, Oct 07, 2010 at 06:19:48PM +0200, Goran Lowkrantz wrote:
> --On October 7, 2010 17:50:42 +0200 John Hay wrote:
>
> >On Thu, Oct 07, 2010 at 02:35:31PM +0200, Ivan Voras wrote:
> >>On 10/07/10 14:15, John Hay wrote:
> >>> Hi,
> >>>
> >&g
On Thu, Oct 07, 2010 at 10:38:58AM -0700, Jeremy Chadwick wrote:
> On Thu, Oct 07, 2010 at 07:31:02PM +0200, John Hay wrote:
> > On Thu, Oct 07, 2010 at 06:19:48PM +0200, Goran Lowkrantz wrote:
> > > --On October 7, 2010 17:50:42 +0200 John Hay wrote:
> > >
> >
On Thu, Oct 07, 2010 at 09:28:22PM +0300, Andriy Gapon wrote:
> on 07/10/2010 20:31 John Hay said the following:
> > Oct 7 17:11:49 thumper1 kernel: mvsch23: EMPTY CRPB 30 (->0) 0 4000
>
> Can you rule out hardware (or driver-level) problems?
> E.g. by dd-ing to/from disk d
://ftp2.pl.freebsd.org/pub/FreeBSD/HEAD/src/sbin/mca/mca.c
> in a script and run it every hour.
>
> Is there a periodic in current for it? IMO it would be handy to do so.
That command is for ia64, not i386 and amd64.
--
John Baldwin
___
freebsd
1
> # LABEL class ignores spoil event
> # dd(1) finishes and closes da2p1
> # GEOM sends taste event to all GEOM classes
> # LABEL class finds no metadata on da2p1 and destroys /dev/ufs/mylabel
What happens if you change the label of a filesystem? I suppose in the UFS
case we don't let you use tunefs to change the label of a mounted filesystem?
Do we have any filesystems where that is the case? If not, I think this
approach sounds fine.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
e_deleted()' callback from
device_delete_child() to the parent bus device to let it know a device had
been removed, but that would be tricky to use since in many cases a bus
device is what invokes device_delete_child() in the first place.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
elog/
I should probably make this into a port, but I really need to e-mail the
mcelog folks about integrating the patches into their tree.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
f we were to
document those every time it would clutter documentation making it harder for
someone who is new to FreeBSD to simply setup a serial console on a box that
they just installed.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
h
ontroller detected.
> > hptrr: no controller detected.
> > m
> >
> Why does FreeBSD think I have a rocket raid controller? This the generic
> kernel.
> Is there some way disable this from loading?
The hptrr driver is in GENERIC in 6.x and it always prints
On Friday, October 29, 2010 3:38:50 pm Nathaniel W Filardo wrote:
> Running
> > sudo make TARGET_ARCH=amd64 TARGET=amd64 DESTDIR=/usr/x86_64 -j4
buildworld
Maybe just set TARGET and not TARGET_ARCH?
--
John Baldwin
___
freebsd-stable@fr
hout a handler. It also seems that, for
whatever reason, IRQ15 is set to level trigger, active low (default for PCI)
instead of edge trigger, active hi (default for ISA). Would be interesting to
see a verbose dmesg from a 7.2 boot perhaps.
--
John Baldwin
_
On Monday, November 01, 2010 8:38:15 am Stephen Clark wrote:
> On 10/29/2010 05:20 PM, John Baldwin wrote:
> > On Friday, October 29, 2010 4:20:24 pm Stephen Clark wrote:
> >
> >>> rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21)
> >&g
On Monday, November 01, 2010 1:30:35 pm Stephen Clark wrote:
> On 11/01/2010 09:54 AM, John Baldwin wrote:
> > On Monday, November 01, 2010 8:38:15 am Stephen Clark wrote:
> >
> >> On 10/29/2010 05:20 PM, John Baldwin wrote:
> >>
> >>> On Frid
to apply to 6.3, did you make sure and
add any intel chipsets that weren't already present in the 6.3 ata-chipset.c?
You will need to grab the #define's for their device ID's from ata-pci.h as
well.
--
John Baldwin
___
freebsd-stable@f
the OS in 7.x+. However,
someone would need to port the EDAC driver (or something similar) to work
with those devices.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
;
> > cat loader.conf:
> >
> > hint.apic.0.disabled="1"
>
> Yes, it is.
> So why do you have it and what happens if you remove it?
The kernel should still not panic if someone disables APIC.
--
John Baldwin
nterrupt doesn't go away when you unload the driver and it's historical
count doesn't go away. vmstat -i just hides interrupts with a count of zero,
but unloading the driver doesn't zero the count, so it will stay there
forever. It might get reused by a different driver that u
> acpi_perf0
> > est0
> > p4tcc0
> > cpufreq0
> > cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1
> > ACPI I/O ports:
> > 0x414
> > 0x415
> > acpi_perf1
> > est1
>
On Thursday, November 18, 2010 4:07:27 pm Andrew Reilly wrote:
> Hi John,
>
> On 18/11/2010, at 23:59 , John Baldwin wrote:
>
> > You used devinfo -v, so it shows the devices that exist even if they failed
> > to attach. Try just using 'devinfo' and seei
On Thursday, November 18, 2010 10:14:44 pm Ian Smith wrote:
> On Thu, 18 Nov 2010, John Baldwin wrote:
> > On Thursday, November 18, 2010 4:07:27 pm Andrew Reilly wrote:
> > > Hi John,
> > >
> > > On 18/11/2010, at 23:59 , John Baldwin wrote:
> > &g
status: active
vlan: 1 parent interface: ix2
ix2.8: flags=8843 metric 0 mtu 1500
ether 00:1b:21:57:ef:7c
inet6 fe80::225:64ff:fef9:eb5d%ix2.8 prefixlen 64 scopeid 0xf
nd6 options=3
media: Ethernet autoselect (10Gbase-SR )
status
ses all connectivity
Yes, this has to do with changes to the driver to fix bugs in its VLAN
hardware filter. If you grab the latest 8-stable it should be back to
working fine by default. If you enable 'vlanhwfilter' via ifconfig you will
loose link when adding or removing v
/ppc/ppc_pci.c instead.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ble the extra concurrency (but at a
performance cost) as a workaround. The most recent 7.x and 8.x have some
changes to open(2) to minimize ESTALE errors that I think get it back to the
same level as when lookup_shared is set to 0.
--
John Baldwin
___
has an LSI SAS3081E-R which is not outrageously expensive, has
> anyone used one?
>
> This post says it should work so it's my current front runner..
> http://forums.freebsd.org/showpost.php?p=59735&postcount=5
It should be supported by mpt(4).
--
John Baldwin
__
graceful than reboot as several people have already told you.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
think this is the expected behavior as nullfs is simply re-exposing /vol0
and it shouldn't be able to create a more privileged mount than the underlying
mount I think (e.g. a read/write nullfs mount of a read-only filesystem would
not make the underlying files read/write). It can be us
_isr1+0xa5
> --- interrupt, rip = 0x808b6cf3, rsp = 0x80ef5c40, rbp =
> 0x80ef5c60 ---
> spinlock_exit() at spinlock_exit+0x33
> ioapic_assign_cpu() at ioapic_assign_cpu+0x123
> intr_shuffle_irqs() at intr_shuffle_irqs+0x9d
> mi_startup() at mi_startup+0x77
> b
prefetch mem transaction
memory access, level generic'
STATUS d0004863 MCGSTATUS 0
MCGCAP 105 APICID 1 SOCKETID 0
CPUID Vendor AMD Family 15 Model 67
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
t; > --- interrupt, rip = 0x808b6cf3, rsp = 0x80ef5c40, rbp =
> > > 0x80ef5c60 ---
> > > spinlock_exit() at spinlock_exit+0x33
> > > ioapic_assign_cpu() at ioapic_assign_cpu+0x123
> > > intr_shuffle_irqs() at intr_shuffle_irqs+0x9d
> > > mi_startup() at mi_startup+0x77
> > > btext() at btext+0x2c
> > > Uptime: 2s
> >
> > Can you do 'l *intr_execute_handlers+0x21' and 'l *ioapic_assign_cpu+0x123'
> > in 'gdb kernel.debug' of your kernel?
>
> sure, as soon as it happens, and it aint happening now :-(
> but when it will happen, I think it won't let me into the debugger
> - probably will have to recompile
You don't need to trigger the panic, you can just run
'gdb /path/to/kernel.debug' (e.g.
'gdb /usr/obj/usr/src/sys/GENERIC/kernel.debug')
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
count software interrupts when we process them. The
> 239 * code here follows previous practice, but there's an
> 240 * argument for counting hardware interrupts when they're
> 241 * processed too.
> 242 */
> 243
gt; > > > 'gdb /usr/obj/usr/src/sys/GENERIC/kernel.debug')
> > > sorry, missed the gdb part.
> > >
> > > gdb /d/7/boot/kernel/kernel
> > > ...
> > > (gdb) l *intr_execute_handlers+0x21
> > > 0x808b1581 is in intr_e
On Saturday, December 25, 2010 6:43:25 am Miroslav Lachman wrote:
> John Baldwin wrote:
> > On Saturday, December 11, 2010 11:51:41 am Miroslav Lachman wrote:
> >> Miroslav Lachman wrote:
> >>> Garrett Cooper wrote:
> >>>> 2010/4/20 Miroslav Lachman<
On Friday, December 24, 2010 3:47:16 am Matthew D. Fuller wrote:
> On Wed, Dec 22, 2010 at 09:57:26AM -0500 I heard the voice of
> John Baldwin, and lo! it spake thus:
> >
> > You are getting corrected ECC errors in your RAM.
>
> Actually, don't
>
> >
On Jan 4, 2011, at 3:40 PM, Dan Allen wrote:
> I just did a csup of stable, and the build is broken.
>
> In function protopr various struct members are not defined. The build halts.
>
> First compile error is at /usr/src/usr.bin/netstat/inet.c line 462
Me too. It seems r216964 is the culprit.
retries and
retransmits for UDP RPCs. The filesystem is equally incoherent for both UDP
and TCP NFSv[23] mounts. TCP did not change any of that.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/free
abled.
My realization this morning is that software interrupts ('int X') in real mode
disable interrupts just like hardware interrupts do. Thus, my patch changes
BTX to disable interrupts for both cases 1) and 2) now. I think this will
fix the hangs. I'm still including the
re talking here (boot0,
> > boot1, boot2, loader?) But if it's one of the former, you dont need to
> > installworld, but install new boot blocks using either fdisk -B or
> > bsdlabel -B (or both).
>
> As Subject: says, I'm talki
On Saturday 09 August 2008 05:22:01 am Eugene Grosbein wrote:
> On Fri, Aug 08, 2008 at 12:49:28PM -0400, John Baldwin wrote:
> > My realization this morning is that software interrupts ('int X') in real
> > mode disable interrupts just like hardware interrupts do. Thus,
On Sunday 10 August 2008 02:27:26 am Eugene Grosbein wrote:
> On Sat, Aug 09, 2008 at 05:17:31PM -0400, John Baldwin wrote:
>
> > In addition to my earlier message, it would probably be good to narrow
down
> > what breaks the loader for you. For example, does it work o
On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote:
> Hi John,
>
> I now figured out the "who", the "why" still eludes me.
>
> So, after your MFC of ichss.c on June 27th the device now attaches at my
> laptop. It didn't before, so it could ca
On Monday 11 August 2008 12:35:17 pm pluknet wrote:
> 2008/8/11 John Baldwin <[EMAIL PROTECTED]>:
> > On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote:
> >> Hi John,
> >>
> >> I now figured out the "who", the "why" still e
On Monday 11 August 2008 01:06:23 pm Eugene Grosbein wrote:
> On Mon, Aug 11, 2008 at 11:31:33AM -0400, John Baldwin wrote:
>
> > > I've just rolled sys/boot/i386/btx back to RELENG_7_0_0_RELEASE
> > > leaving rest of src at 7.0-STABLE (plus your patch) and yes,
xe79decfc)
at /usr/src/sys/kern/sys_generic.c:317
> #17 0xc0a49635 in syscall (frame=0xe79ded38)
at /usr/src/sys/i386/i386/trap.c:1035
> #18 0xc0a2fc70 in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:196
> #19 0x0033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
FYI, you got the panic in ffs/ufs, not fuse. I've seen this at work on 6.x
with NFS with no clues on what causes it. You can start by going to frame 7
and doing 'p *bp'.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote:
> On Monday 11 August 2008 23:04:30 John Baldwin wrote:
> > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote:
> > > Hi,
> > >
> > > I am a kgdb newbie, so please be patient.
> > > I suspect
On Tuesday 12 August 2008 04:36:29 am pluknet wrote:
> 2008/8/11 John Baldwin <[EMAIL PROTECTED]>:
> > On Monday 11 August 2008 12:35:17 pm pluknet wrote:
> >> 2008/8/11 John Baldwin <[EMAIL PROTECTED]>:
> >> > On Saturday 09 August 2008 07:16:37
On Tuesday 12 August 2008 02:23:30 pm Johan Kuuse wrote:
> > On Tuesday 12 August 2008 02:42:52 am Johan Kuuse wrote:
> >> On Monday 11 August 2008 23:04:30 John Baldwin wrote:
> >> > On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote:
> >> > > Hi
On Wednesday 13 August 2008 03:33:45 am pluknet wrote:
> 2008/8/12 John Baldwin <[EMAIL PROTECTED]>:
> > Try http://www.freebsd.org/~jhb/patches/cpufreq_order.patch ichss0 is
only
> > supposed to be used if you don't have est0, and this patch fixes that.
I'm
&
y never be.
>
> I do not want to backport the code to the old context switch, that would
> mean a rewrite from scratch. Instead, I merged the r177535 (optimization
> of context switch by peter@), and commented out corresponding test in
> the cpu_switch.S for the TDP_K
nk the likeliest changes to cause this are the TCP offload
changes. Note that Kip later MFC'd this change which changed ARP stuff:
Author: kmacy
Date: Thu Jul 31 22:42:27 2008
New Revision: 181075
URL: http://svn.freebsd.org/changeset/base/181075
STABLE #0: Fri Aug 15 12:56:35 CEST 2008
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC
> Panic String: page fault
> Dump Parity: 2682527093
> Bounds: 0
> Dump Status: good
>
> (crash dump, 58 Mbyte, available on request).
>
> Is this how it is supposed to be
On Monday 18 August 2008 01:44:00 pm Torfinn Ingolfsen wrote:
> On Mon, 18 Aug 2008 10:33:05 -0400
> John Baldwin <[EMAIL PROTECTED]> wrote:
>
> >
> > Can you get the stack trace?
>
> Like this?
> [EMAIL PROTECTED] kgdb kernel.debug /var/crash/vmcore.0
> G
re you using a serial console? If so, can
you put DDB in your kernel and when it hangs break into ddb and do a 'ps' and
capture the output.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
, CTF generation is turned off. You don't
need or want it yet.
--
John Birrell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Wed, Aug 27, 2008 at 08:43:13AM +0100, N.J. Mann wrote:
> In message <[EMAIL PROTECTED]>,
> John Birrell ([EMAIL PROTECTED]) wrote:
> >
> > This is a belated heads up to let you know that I have merged DTrace to the
> > releng7
> > branch in the ni
or if we can just do some selective patching up. In the mean time,
> > please don't try to update -- wait for an all clear.
>
> Just an update: John Baldwin has identified the set of problematic parts to
> the change, and will shortly be backing them out. Please continue to wait
le.
>
> So what's going on here?
Hard to say. My HP nc6220 laptop gets into a lockup where it spends all its
time processing ACPI events (I think for some of the thermal monitoring the
BIOS does) if I drop the CPU speed below 400. I just set
debug.cpufreq.lowest in /boot/lo
On Wednesday 27 August 2008 10:25:37 pm John Baldwin wrote:
> On Wednesday 27 August 2008 01:29:43 pm Robert Watson wrote:
> > On Wed, 27 Aug 2008, Robert Watson wrote:
> > > It looks like there have been several mismerges in the DTrace MFC.
We're
> > > currentl
_COHERENCE_SIZE - CPUC_SIZE
> +#define CPUC_SIZE1 roundup(CPUC_SIZE,
> CPU_CACHE_COHERENCE_SIZE)
> +#define CPUC_PADSIZECPUC_SIZE1 - CPUC_SIZE
>
> typedef struct cpu_core {
> uint16_tcpuc_dtrace_flags; /* DTrace flags */
--
Jo
This patch merges a few changes from HEAD back to 7.x. I think the endian
changes specifically might solve the issue people saw with zpools created
with non-dtrace kernels not being readable by dtrace kernels and vice versa.
http://www.FreeBSD.org/~jhb/patches/zfs_7.patch
--
John Baldwin
test out the builds. I have no hardware to run an old version
of 6 on.
--
John Birrell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Thursday 28 August 2008 06:36:30 pm John Birrell wrote:
> It goes without saying that this didn't go anywhere near as smoothly as
> I hoped it would. My attention to detail was less than perfect. Sorry
> for the pain I've caused.
>
> A big thanks to those who&#x
int.ipmi.0.at=isa0
hint.ipmi.0.mode=KCS
Either add that to /boot/device.hints or for a test just explicitly set those
variables at the loader prompt before booting.
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org
list of
child interrupt handlers which it invokes from its own interrupt handler. I
don't currently have any boxes running HEAD that have anything hooked up to
their ppc0 port, so I'd appreciate folks testing this if possible.
http://www.FreeBSD.org/~jhb/patches/ppc_intr.patch
--
Jo
On Friday 29 August 2008 03:57:46 am Henri Hennebert wrote:
> Henri Hennebert wrote:
> > John Baldwin wrote:
> >> This patch merges a few changes from HEAD back to 7.x. I think the
> >> endian changes specifically might solve the issue people saw with
> >> zp
The feedback I've been getting indicates that it's safe to go back in the
water again.
--
John Birrell
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail
ction.
I believe that the buildworld that you have is OK, even when built with the
CTF data it's the installworld when things go bad.
Do you need me to send you any files to recover from this problem?
--
John Birrell
___
freebsd-stable@freebs
s problem?
>
> No problem, I have access to a previous 7.0-STABLE.
I am concerned about the high CPU problem. All the hooks that are built in
with KDTRACE_HOOKS are inactive until the DTrace modules are loaded. So there
should be no CPU implications there.
Are you usi
301 - 400 of 1674 matches
Mail list logo
