Re: kern/79266: [pci] [patch] RELENG_4 pci CONF1_ENABLE_MSK depend MFCed incorrectly?

Synopsis: [pci] [patch] RELENG_4 pci CONF1_ENABLE_MSK depend MFCed incorrectly? State-Changed-From-To: open->closed State-Changed-By: gavin State-Changed-When: Sat Jun 23 16:05:52 UTC 2007 State-Changed-Why: Now that 4.x has been marked End-of-Life, this PR is no longer relevant. The prob

Re: Stop in buildworld under RELENG_4

On Tue, Aug 08, 2006 at 07:59:41PM -0400, Eric Millbrandt wrote: > Is buildworld broken under RELENG_4. No. > I made sure to start out with a > clean buildtree and to delete /usr/obj. Here is the stop and attached > is the entire script. > DING! [EMAIL PROTECTED]:/us

Re: INVARIANTS (was Re: RELENG_4 -> 5 -> 6: significant performance regression)

Hello! On Sat, 13 May 2006, Matthew D. Fuller wrote: On Sat, May 13, 2006 at 11:58:26AM -0400 I heard the voice of Kris Kennaway, and lo! it spake thus: FYI, INVARIANTS adds checks but does not (is not supposed to) divert code paths. It does at least in UMA; it does a lot of bzero()/NULL'in

Re: RELENG_4 -> 5 -> 6: significant performance regression

tems on uniprocessor i386 system, and (for now) it's significantly worse than under RELENG_4. So I've used fxp just for comparison (and to rule out possible specific regression in rl NIC driver), not for anything more serious. Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195

Re: INVARIANTS (was Re: RELENG_4 -> 5 -> 6: significant performance regression)

Matthew D. Fuller wrote: > On Sat, May 13, 2006 at 11:58:26AM -0400 I heard the voice of > Kris Kennaway, and lo! it spake thus: > > > > FYI, INVARIANTS adds checks but does not (is not supposed to) divert > > code paths. > > It does at least in UMA; it does a lot of bzero()/NULL'ing out of > mem

Re: INVARIANTS (was Re: RELENG_4 -> 5 -> 6: significant performance regression)

On Sat, May 13, 2006 at 11:58:26AM -0400 I heard the voice of Kris Kennaway, and lo! it spake thus: > > FYI, INVARIANTS adds checks but does not (is not supposed to) divert > code paths. It does at least in UMA; it does a lot of bzero()/NULL'ing out of memory, which might hide later uninitialized

Re: INVARIANTS (was Re: RELENG_4 -> 5 -> 6: significant performance regression)

On Sat, May 13, 2006 at 10:52:32AM -0500, Matthew D. Fuller wrote: > On Sat, May 13, 2006 at 10:37:40AM -0400 I heard the voice of > Kris Kennaway, and lo! it spake thus: > > > > With respect to INVARIANTS, you just need to get used to the fact > > that running thousands of checks for bugs is inco

INVARIANTS (was Re: RELENG_4 -> 5 -> 6: significant performance regression)

On Sat, May 13, 2006 at 10:37:40AM -0400 I heard the voice of Kris Kennaway, and lo! it spake thus: > > With respect to INVARIANTS, you just need to get used to the fact > that running thousands of checks for bugs is incompatible with > running at optimal speed. (I'm not sure what the point of sa

Re: RELENG_4 -> 5 -> 6: significant performance regression

l > 34 24 42 > > without INVARIANTS, and > > %Sys %Intr %Idl > 45 40 15 > > with them. Other options like QUOTA and "makeoptions > CONF_CFLAGS=-fno-builtin" make almost no difference. So, under my test > conditions, the best % of idle CPU

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Sat, May 13, 2006 at 08:59:01AM +0300, Dmitry Pryanishnikov wrote: > I'm just trying to understand why performance of RELENG_6 is worse than > in RELENG_4 _that much_, and whether this sad situation can be improved > somehow. The architecture of the system substantially chan

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Sat, May 13, 2006 at 03:01:18AM -0400 I heard the voice of Jonathan Noack, and lo! it spake thus: > > Have you tried putting I586_CPU in there? See > http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020696.html. As Peter Jeremy mentioned in

Re: RELENG_4 -> 5 -> 6: significant performance regression

nd > > %Sys %Intr %Idl > 45 40 15 > > with them. Other options like QUOTA and "makeoptions > CONF_CFLAGS=-fno-builtin" make almost no difference. So, under my test > conditions, the best % of idle CPU time under RELENG_6 is 42%, while > under RELENG

Re: RELENG_4 -> 5 -> 6: significant performance regression

Hello! On Fri, 12 May 2006, Kris Kennaway wrote: So maybe it's time to add, say, options INVARIANTS_EXTENDED for these new and expensive checks, and leave only basic and cheap (yet effective for bug hunting) asserts enabled when only options INVARIANTS is defined? No, they are

Re: RELENG_4 -> 5 -> 6: significant performance regression

ys %Intr %Idl 45 40 15 with them. Other options like QUOTA and "makeoptions CONF_CFLAGS=-fno-builtin" make almost no difference. So, under my test conditions, the best % of idle CPU time under RELENG_6 is 42%, while under RELENG_4 we had %Sys %Intr %Idl 14 14

Re: RELENG_4 -> 5 -> 6: significant performance regression

y times during the transfer - they don't vary more than +/- several > (2-3) % during the main transfer phase (when transfer speed is stable). > My "time md5 -t" runs was used only as a confirmation that systat's numbers > are trustworthy - they simply confirm that there are _m

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Fri, May 12, 2006 at 11:32:44PM +0300, Dmitry Pryanishnikov wrote: > > Hello! > > On Tue, 2 May 2006, Robert Watson wrote: > >>options INVARIANTS > >>options INVARIANT_SUPPORT > > > >In FreeBSD 5.x and FreeBSD 6.x, the INVARIANTS option has been > >significantly expanded to test a muc

Re: RELENG_4 -> 5 -> 6: significant performance regression

Hello! On Tue, 2 May 2006, Robert Watson wrote: options INVARIANTS options INVARIANT_SUPPORT In FreeBSD 5.x and FreeBSD 6.x, the INVARIANTS option has been significantly expanded to test a much larger set of invariants, and also incorporate kernel use-after-free checking, wh

Re: RELENG_4 -> 5 -> 6: significant performance regression

1:43 RELENG_6 + fxp0 30 20 50 1:40 is caused by just these: options INVARIANTS options INVARIANT_SUPPORT (I'll try to find out which one of these takes which % of overhead when I get free time), but still much worse then under RELENG_4, where this particul

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Thu, 27 Apr 2006, Dmitry Pryanishnikov wrote: options INVARIANTS options INVARIANT_SUPPORT In FreeBSD 5.x and FreeBSD 6.x, the INVARIANTS option has been significantly expanded to test a much larger set of invariants, and also incorporate kernel use-after-free checking, w

Re: RELENG_4 -> 5 -> 6: significant performance regression

ead this: using "CONF_CFLAGS=-fno-builtin" inhibits use of > >non-optimal > >> gcc builtin functions, so this option may be useful for getting max. > >> performance. Are this comment and my interpretation still correct now? > > > >I don't know

Re: RELENG_4 -> 5 -> 6: significant performance regression

Dominic Marks wrote: Peter Jeremy wrote: On Sun, 2006-Apr-30 10:05:40 +0100, Chris wrote: Does 'makeoptions DEBUG=-g' add any kind of performance hit or overhead as I noticed it wasnt default in 5.4 but is in 6.0. No. It just means that a debug kernel is built in addition to the normal k

Re: RELENG_4 -> 5 -> 6: significant performance regression

Peter Jeremy wrote: On Sun, 2006-Apr-30 10:05:40 +0100, Chris wrote: Does 'makeoptions DEBUG=-g' add any kind of performance hit or overhead as I noticed it wasnt default in 5.4 but is in 6.0. No. It just means that a debug kernel is built in addition to the normal kernel. The major bene

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Sun, 2006-Apr-30 10:05:40 +0100, Chris wrote: >Does 'makeoptions DEBUG=-g' add any kind of performance hit or >overhead as I noticed it wasnt default in 5.4 but is in 6.0. No. It just means that a debug kernel is built in addition to the normal kernel. The major benefit is that if you do

Re: RELENG_4 -> 5 -> 6: significant performance regression

x27;ve read this: using "CONF_CFLAGS=-fno-builtin" inhibits use of non-optimal > gcc builtin functions, so this option may be useful for getting max. > performance. Are this comment and my interpretation still correct now? I don't know, it needs to be tested in your particular

Re: RELENG_4 -> 5 -> 6: significant performance regression

; inhibits use of non-optimal > gcc builtin functions, so this option may be useful for getting max. > performance. Are this comment and my interpretation still correct now? I don't know, it needs to be tested in your particular case. > >> %Sys %In

Re: RELENG_4 -> 5 -> 6: significant performance regression

m giant-locked, which may also interfere with your network processing. It's also a pity. %Sys %Intr %Idl RELENG_4 + rl0 14 14 72 RELENG_4 + fxp0 14 10 76 RELENG_5 + rl0 40 30 30 RELENG_5 + fxp0 35 25 40 RELENG_6 + rl0

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Thu, Apr 27, 2006 at 01:57:02PM -0700, Doug Hardie wrote: > > On Apr 27, 2006, at 11:12, Kris Kennaway wrote: > > >On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote: > > > >>options QUOTA > > > >This definitely effects performance on 6.x since it makes your > >filesystem

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Apr 27, 2006, at 11:12, Kris Kennaway wrote: On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote: options QUOTA This definitely effects performance on 6.x since it makes your filesystem giant-locked, which may also interfere with your network processing. Any in

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Thu, Apr 27, 2006 at 04:43:07PM -0400, Mike Jakubik wrote: > Kris Kennaway wrote: > >On Thu, Apr 27, 2006 at 03:47:37PM -0400, Mike Jakubik wrote: > > > >>Why isn't QUOTA mpsafe then? > >> > > > >Because code doesn't grow on trees. There are uncommitted patches > >though - perhaps you can

Re: RELENG_4 -> 5 -> 6: significant performance regression

Kris Kennaway wrote: On Thu, Apr 27, 2006 at 03:47:37PM -0400, Mike Jakubik wrote: Why isn't QUOTA mpsafe then? Because code doesn't grow on trees. There are uncommitted patches though - perhaps you can test them and get back to the author with your feedback. What? There is a bea

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Thu, Apr 27, 2006 at 03:47:37PM -0400, Mike Jakubik wrote: > Bartosz Fabianowski wrote: > >>You wrote that Giant is needed in 6.0 and now you write it has been > >>removed. > > > >In 4.x, every UFS write requires the Giant lock. In 6.x, Giant is not > >normally required, making file system oper

Re: RELENG_4 -> 5 -> 6: significant performance regression

Bartosz Fabianowski wrote: You wrote that Giant is needed in 6.0 and now you write it has been removed. In 4.x, every UFS write requires the Giant lock. In 6.x, Giant is not normally required, making file system operations faster. When you enable QUOTA, you basically get back to the 4.x behav

Re: RELENG_4 -> 5 -> 6: significant performance regression

You wrote that Giant is needed in 6.0 and now you write it has been removed. In 4.x, every UFS write requires the Giant lock. In 6.x, Giant is not normally required, making file system operations faster. When you enable QUOTA, you basically get back to the 4.x behavior where Giant is needed f

Re: RELENG_4 -> 5 -> 6: significant performance regression

Kris Kennaway a écrit : On Thu, Apr 27, 2006 at 08:26:06PM +0200, [EMAIL PROTECTED] wrote: Kris Kennaway a ?crit : On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote: options QUOTA This definitely effects performance on 6.x since it makes your filesystem giant-lock

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Thu, Apr 27, 2006 at 08:26:06PM +0200, [EMAIL PROTECTED] wrote: > Kris Kennaway a ?crit : > >On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote: > > > > > >>options QUOTA > > > >This definitely effects performance on 6.x since it makes your > >filesystem giant-locked, which

Re: RELENG_4 -> 5 -> 6: significant performance regression

Kris Kennaway a écrit : On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote: options QUOTA This definitely effects performance on 6.x since it makes your filesystem giant-locked, which may also interfere with your network processing. Why would QUOTA affect performa

Re: RELENG_4 -> 5 -> 6: significant performance regression

On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote: > makeoptions CONF_CFLAGS=-fno-builtin Non-default option; this may conceivably affect performance. > options INVARIANTS > options INVARIANT_SUPPORT These definitely effect performance, much more in 5.x and 6.x

RELENG_4 -> 5 -> 6: significant performance regression

Mbyte/s transfer rate). I've noted CPU utilization which gave "systat -vm 1" once numbers have stabilized. Here are the results (average numbers, %User and %Nice are close to zero): %Sys %Intr %Idl RELENG_4 + rl0 14 14 72 RELENG_4 + fxp0

Re: RELENG_4 on flash disk and swap

On Mon, Mar 13, 2006 at 11:48:06AM -0800, Jon Dama wrote: > > If you feel this situation is undesirable, the first thing to do is to put > together the patches necessary to allow the kernel to actually track how > much ram+swap might be needed to cover the address-space allocations > that have bee

Re: RELENG_4 on flash disk and swap

Hello! I won't reply to the overcommit part of your letter, since my concern is rather local: I'm just not sure whether FreeBSD does it's best during the DoS-attack in swapless environment. On Mon, 13 Mar 2006, Jon Dama wrote: Also, when the system is page-starved it kills the largest consum

Re: RELENG_4 on flash disk and swap

If you feel this situation is undesirable, the first thing to do is to put together the patches necessary to allow the kernel to actually track how much ram+swap might be needed to cover the address-space allocations that have been granted. This isn't trivial: just start thinking about shared all

Re: RELENG_4 on flash disk and swap

>On Fri, 10 Mar 2006, Michael Proto wrote: >> My suggestion would then be to utilize resource limits in >> /etc/login.conf for the sshd user (in your example) or other user >> accounts for applications that you don't want running out of control. >> See login.conf(5) and login_cap(3) for more detai

Re: RELENG_4 on flash disk and swap

On Fri, Mar 10, 2006 at 01:57:50PM +0200, Dmitry Pryanishnikov wrote: > > This is still a concern for me. IMHO it would be useful to have the ability > to disable process killing due to the lack of swap, because having this > enabled on e.g. transit router can lead to very unpleasant scenario. >

Re: RELENG_4 on flash disk and swap

Hello! On Fri, 10 Mar 2006, Michael Proto wrote: My suggestion would then be to utilize resource limits in /etc/login.conf for the sshd user (in your example) or other user accounts for applications that you don't want running out of control. See login.conf(5) and login_cap(3) for more details

Re: RELENG_4 on flash disk and swap

Dmitry Pryanishnikov wrote: > On Sat, 4 Mar 2006, Peter Jeremy wrote: >> Once you've received this message, the OS is free to kill your >> processes until it frees up some swap (which it can't do if you don't >> have any). I suggest you have a quick look through vm/swap_pager.c >> and vm/vm_pageou

Re: RELENG_4 on flash disk and swap

Hello! On Fri, 10 Mar 2006, Michael Proto wrote: [EMAIL PROTECTED] ps axu |grep ssh root 20213 0.0 1.3 54724 3356 ?? Is4:00PM 0:00.10 sshd: dmitry [priv] dmitry 20216 0.0 1.3 54724 3356 ?? I 4:00PM 0:00.03 s

Re: RELENG_4 on flash disk and swap

On Fri, 2006-Mar-10 15:53:43 +0200, Dmitry Pryanishnikov wrote: > But AFAIK the kernel kills NOT the requesting process but the one with the >largest RSS. This selection algorithm seems to be the dumbest one, since >process with largest RSS almost always is the process which does some real >work.

Re: RELENG_4 on flash disk and swap

Hello! On Sat, 11 Mar 2006, Peter Jeremy wrote: But AFAIK the kernel kills NOT the requesting process but the one with the largest RSS. This selection algorithm seems to be the dumbest one, since process with largest RSS almost always is the process which does some real work. This frees up th

Re: RELENG_4 on flash disk and swap

Hello! On Fri, 10 Mar 2006, Kostik Belousov wrote: the largest RSS - it could e.g. be a vital part of the routing software (zebra/ripd/bgpd), and killing this process will render our router unreachable and unusable! Then, what should kernel do ? It kills the process because it _needs_ the pag

Re: RELENG_4 on flash disk and swap

Hello! Date: Fri, 3 Mar 2006 08:04:55 -0500 From: Michael Proto <[EMAIL PROTECTED]> To:freebsd-stable@freebsd.org Subject: Re: RELENG_4 on flash disk and swap I'm running FreeBSD in 64Mb with no swap and it works fine. A few sysctls that I've found hel

Re: RELENG_4 on flash disk and swap

el's config. Do you really believe that RELENG_4 lacks real memory for "make buildworld" on i386 with 256Mb RAM? No. It seems fairly unlikely but it's been a long while (probably pre 4.x) since I've tried building world in a limited memory environment. g++ can eat lots of

Re: RELENG_4 on flash disk and swap

.v_cache_min > vm.stats.vm.v_free_count + vm.stats.vm.v_cache_count >... because I think it wasn't a process which requested a page - it >apparently was a softupdates code. Or possibly the dirhash code - it also needs RAM. > Do you really believe that RELENG_4 >lacks real memory f

Re: RELENG_4 on flash disk and swap

7;t a process which requested a page - it apparently was a softupdates code. Do you really believe that RELENG_4 lacks real memory for "make buildworld" on i386 with 256Mb RAM? I've issued "make buildworld" and "make buildkernel" several times, just to be sure. Eve

Re: RELENG_4 on flash disk and swap

On Fri, 2006-Mar-03 11:16:00 +0200, Dmitry Pryanishnikov wrote: > I'm running some heavy tests on my machine (256Mb RAM, HDD, no swap, >4.11-RELEASE) such as "make buildwolrd". After successful completion of >this procedure I issued "rm -rf /usr/obj/usr" and got the following >(single) message fro

Re: RELENG_4 on flash disk and swap

Pryanishnikov wrote: > Hello! > > Suppose I have machine with 256Mb of RAM and 256Mb flash ATA disk-on-module. > What configuration (using RELENG_4) should I select: > > 1. No swap at all. > 2. /dev/md0 (default 10Mb) added as a swap device. > > In other words, does REL

Re: RELENG_4 on flash disk and swap

Hello! On Fri, 3 Mar 2006, Jeremy Bogan wrote: In other words, does RELENG_4 kernel work stable and robust w/o swap or should I provide a minimum-size swap device? Which configuration (1 or 2) will give more robustness in case of physical memory shortage? I've got 4.11 running on a

RELENG_4 on flash disk and swap

Hello! Suppose I have machine with 256Mb of RAM and 256Mb flash ATA disk-on-module. What configuration (using RELENG_4) should I select: 1. No swap at all. 2. /dev/md0 (default 10Mb) added as a swap device. In other words, does RELENG_4 kernel work stable and robust w/o swap or should I

Re: Switching from RELENG_4 to newer Release that supports ia64

On Fri, Oct 07, 2005 at 12:36:13PM +0200, Michael Schuh wrote: > Hello, > > we plan to change the Hardware from one of our Servers Running RELENG_4. > The New Hardware becomes CPU-Types Xeon w/ EM64 -> ia64 architecture. > > Now i have no experiences to change the OS-Release

Switching from RELENG_4 to newer Release that supports ia64

Hello, we plan to change the Hardware from one of our Servers Running RELENG_4. The New Hardware becomes CPU-Types Xeon w/ EM64 -> ia64 architecture. Now i have no experiences to change the OS-Release under the ass from running Software (postfix/cyrus/postgresql/mysql/perletc.) I be a

Re: RELENG_4 pam update doesn't work correct

Hello, i have also opened a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=85796 regards michael 2005/9/6, Michael Schuh <[EMAIL PROTECTED]>: > Hello, > > yesterday i have made an cvsup from RELENG_4 and made the typically > system-update with: > > make buildworld

RELENG_4 pam update doesn't work correct

Hello, yesterday i have made an cvsup from RELENG_4 and made the typically system-update with: make buildworld kernel mergemaster -p make installworld mergemaster portupgrade -ar Now i have problems with pam. the pam-modules and the Library-Archive libpam.a in /usr/lib are updated correctly

[releng_4 tinderbox] failure on i386/i386

TB --- 2005-07-03 17:30:25 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2005-07-03 17:30:25 - starting RELENG_4 tinderbox run for i386/i386 TB --- 2005-07-03 17:30:25 - cleaning the object tree TB --- 2005-07-03 17:31:48 - checking out the source tree TB --- 2005-07-03 17:31:48 - cd

Re: [RELENG_4] buildkernel failure with MAKEOBJDIRPREFIX

> In <[EMAIL PROTECTED]> > Ruslan Ermilov <[EMAIL PROTECTED]> wrote: > > I think this is a bug of make, *.mk or other Makefiles in /sys but I > > cannot fix it. > No, this is because MAKEOBJDIRPREFIX must be an environment variable > and should not be set on make's command line or in /

Re: [RELENG_4] buildkernel failure with MAKEOBJDIRPREFIX

ke buildkernel' in /usr/src. And got an error "/usr/src: file > system full". Because /usr/src is another partition and has as small > space as /usr/obj. /usr/src is 400MB and /usr/obj is 500MB which are > enouch to build normal RELENG_4 world. > > I noticed that m

[RELENG_4] buildkernel failure with MAKEOBJDIRPREFIX

tion and has as small space as /usr/obj. /usr/src is 400MB and /usr/obj is 500MB which are enouch to build normal RELENG_4 world. I noticed that modules are built in /usr/src/sys/modules not in ${MAKEOBJDIRPREFIX}/usr/src/sys/modules. Of cource, kernel.debug is created in ${MAKEOBJDIRPREFIX}/usr/s

Re: more MFCs to RELENG_4

Julian Elischer wrote: You'll find a diff at: http://www.freebsd.org/~julian/usb-4.diff This merges a lot of the USB infrastructure. I was amazed how little changing had to be done to allow this to work on 4.x. The files become almost teh same as on -current. (minus small changes here and there) i

more MFCs to RELENG_4

You'll find a diff at: http://www.freebsd.org/~julian/usb-4.diff This merges a lot of the USB infrastructure. I was amazed how little changing had to be done to allow this to work on 4.x. The files become almost teh same as on -current. (minus small changes here and there) if you use USB on 4.x, pl

Re: kern/79266: [patch] RELENG_4 pci CONF1_ENABLE_MSK depend MFCed incorrectly?

Forgive me for my ignorance. I'm quite new to FreeBSD. I'm currently having a very similar problem, to what you described. But I don't quite understand the fix to this brief solution. Can you please provide me with a more precise answer to this problem. I could really use the help. Thank you

RE: RELENG_5 problems with Intel 855 (RELENG_4 boots fine)(solved!)

ubject: RE: RELENG_5 problems with Intel 855 (RELENG_4 boots fine) (solved!) At 01:29 PM 01/04/2005, Gray Lilley wrote: >Can you try setting hw.pci.enable_io_modes=0 at the loader prompt then >booting? Thanks! That did the trick!! OK set hw.pci.enable_io_modes=0 OK boot /boot/kernel/acpi.ko t

RE: RELENG_5 problems with Intel 855 (RELENG_4 boots fine) (solved!)

At 01:29 PM 01/04/2005, Gray Lilley wrote: Can you try setting hw.pci.enable_io_modes=0 at the loader prompt then booting? Thanks! That did the trick!! OK set hw.pci.enable_io_modes=0 OK boot /boot/kernel/acpi.ko text=0x41520 data=0x1da4+0x112c syms=[0x4+0x7630+0x4+0x9c97] KDB: debugger backends

RE: RELENG_5 problems with Intel 855 (RELENG_4 boots fine)

ECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Tancsa Sent: 01 April 2005 19:39 To: freebsd-stable@freebsd.org Subject: RELENG_5 problems with Intel 855 (RELENG_4 boots fine) We are trying out an Intel 855 that is not able to boot RELENG_5. It locks up hard (NUM LOCK doesnt work) on bootup a

RELENG_5 problems with Intel 855 (RELENG_4 boots fine)

We are trying out an Intel 855 that is not able to boot RELENG_5. It locks up hard (NUM LOCK doesnt work) on bootup at the same spot. However, RELENG_4 is able to boot just fine. Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993

Re: kern/79266: RELENG_4 pci CONF1_ENABLE_MSK mfc depend

Category: kern >Responsible:freebsd-bugs >Synopsis: RELENG_4 pci CONF1_ENABLE_MSK mfc depend >Arrival-Date: Sat Mar 26 23:20:01 GMT 2005 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/

vinum zero divide crashes under RELENG_4

Dear colleagues, is anyone interested in analyzing vinum crashdumps under RELENG_4? The problem is that crash situations are not easily reproducible (they are related to changing in-memory and on-disk vinum configs), but almost every refers to #6 0xc01ff69b in __divdi3 (a=0x1000, b=0x0) at

Re: building KLDs in RELENG_4

In message: <[EMAIL PROTECTED]> "Peter C. Lai" <[EMAIL PROTECTED]> writes: : On Thu, Feb 24, 2005 at 09:59:01AM -0600, Scot Hetzel wrote: : > On Thu, 24 Feb 2005 09:56:22 -0500, Peter C. Lai <[EMAIL PROTECTED]> wrote: : > > Is there a way to build kernel modules by themselves without ha

Re: building KLDs in RELENG_4

In message: <[EMAIL PROTECTED]> "Peter C. Lai" <[EMAIL PROTECTED]> writes: : Is there a way to build kernel modules by themselves without having to : build the entire kernel? I am adding umass support to a 4.x machine but : I don't want to build the entire kernel. I already have scbus,

sandisk cruzer mini quirks [failure] on RELENG_4

the problem. Notably dd(1) transfers files fine. This is on a RELENG_4 system, cvsup yesterday. Any ideas? thanks, pete -- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant h

Re: building KLDs in RELENG_4

I believe you can cd /usr/src/sys/modules/umass, compile/install/load umass.ko. On Thu, 24 Feb 2005 09:56:22 -0500, Peter C. Lai <[EMAIL PROTECTED]> wrote: > Is there a way to build kernel modules by themselves without having to > build the entire kernel? I am adding umass support to a 4.x mach

Re: building KLDs in RELENG_4

On Thu, Feb 24, 2005 at 09:59:01AM -0600, Scot Hetzel wrote: > On Thu, 24 Feb 2005 09:56:22 -0500, Peter C. Lai <[EMAIL PROTECTED]> wrote: > > Is there a way to build kernel modules by themselves without having to > > build the entire kernel? I am adding umass support to a 4.x machine but > > I don

Re: building KLDs in RELENG_4

On Thu, 24 Feb 2005 09:56:22 -0500, Peter C. Lai <[EMAIL PROTECTED]> wrote: > Is there a way to build kernel modules by themselves without having to > build the entire kernel? I am adding umass support to a 4.x machine but > I don't want to build the entire kernel. I already have scbus, but I need

building KLDs in RELENG_4

Is there a way to build kernel modules by themselves without having to build the entire kernel? I am adding umass support to a 4.x machine but I don't want to build the entire kernel. I already have scbus, but I need da and of course, umass. TIA, pete -- Peter C. Lai University of Connecticut De

Re: RELENG_4 tag in stable-supfile on 5.2.1 box - change it to RELENG_5?

On Tue, 22 Feb 2005, W C wrote: > I would like to upgrade my 5.2.1 box from source with cvsup to 5-STABLE. > > Do I need to change the tag to RELENG_5 for FreeBSD 5-STABLE? Or can I > cvsup a new stable-supfile? At the time 5.2.1 was released, RELENG_4 was still the stable bra

Re: RELENG_4 tag in stable-supfile on 5.2.1 box - change it to RELENG_5?

> From: "W C" <[EMAIL PROTECTED]> > Date: Tue, 22 Feb 2005 14:35:28 -0800 > Sender: [EMAIL PROTECTED] > > I would like to upgrade my 5.2.1 box from source with cvsup to 5-STABLE. > > Do I need to change the tag to RELENG_5 for FreeBSD 5-STABLE? > Or can I cvsup a new stable-supfile? Yes, change

Re: RELENG_4 tag in stable-supfile on 5.2.1 box - change it to RELENG_5?

On Tue, Feb 22, 2005 at 02:35:28PM -0800, W C <[EMAIL PROTECTED]> was witnessed plotting the following conspiracy: > I would like to upgrade my 5.2.1 box from source with cvsup to 5-STABLE. > > Do I need to change the tag to RELENG_5 for FreeBSD 5-STABLE? > Or can I cvsup a new stable-supfile? >

RELENG_4 tag in stable-supfile on 5.2.1 box - change it to RELENG_5?

I would like to upgrade my 5.2.1 box from source with cvsup to 5-STABLE. Do I need to change the tag to RELENG_5 for FreeBSD 5-STABLE? Or can I cvsup a new stable-supfile? thanks, woody p.s. sorry if hotmail is sending HTML, I know, I know, all you pine users hate it. ___

Re: Missing Man-Pages in RELENG_4

On Fri, Jan 07, 2005 at 01:57:20PM +0900, Hideyuki KURASHINA wrote: > Darren, could you please commit following patch? Guido, also please > merge those changes? As Darren seems to be afk untill the 10th, I took the liberty to commit the changes. -Guido ___

Re: Missing Man-Pages in RELENG_4

Hi, >>> On Fri, 7 Jan 2005 00:11:15 +0300, Igor Pokrovsky <[EMAIL PROTECTED]> said: > On Wed, Jan 05, 2005 at 05:26:18PM +0100, Michael Schuh wrote: > > Hi, > > > > i miss the manpages for ipf.conf ipnat.conf > > under RELENG_4 last updated 2005-01-05 &

Re: Missing Man-Pages in RELENG_4

On Wed, Jan 05, 2005 at 05:26:18PM +0100, Michael Schuh wrote: > Hi, > > i miss the manpages for ipf.conf ipnat.conf > under RELENG_4 last updated 2005-01-05 > via cvsup. I guess this is because there are no those man pages. -ip -- The higher the level of prestige accorded th

Re: Missing Man-Pages in RELENG_4

On Wed, Jan 05, 2005 at 05:26:18PM +0100, Michael Schuh wrote: > Hi, > > i miss the manpages for ipf.conf ipnat.conf > under RELENG_4 last updated 2005-01-05 > via cvsup. I guess this is because there are no those man pages. -ip -- The higher the level of prestige accorded th

Missing Man-Pages in RELENG_4

Hi, i miss the manpages for ipf.conf ipnat.conf under RELENG_4 last updated 2005-01-05 via cvsup. thanks regards Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any

[releng_4 tinderbox] failure on i386/i386

TB --- 2004-12-13 00:29:26 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2004-12-13 00:29:26 - starting RELENG_4 tinderbox run for i386/i386 TB --- 2004-12-13 00:29:26 - checking out the source tree TB --- 2004-12-13 00:29:26 - cd /tinderbox/RELENG_4/i386/i386 TB --- 2004-12-13 00:29

[releng_4 tinderbox] failure on i386/i386

TB --- 2004-12-12 12:59:12 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2004-12-12 12:59:12 - starting RELENG_4 tinderbox run for i386/i386 TB --- 2004-12-12 12:59:12 - checking out the source tree TB --- 2004-12-12 12:59:12 - cd /tinderbox/RELENG_4/i386/i386 TB --- 2004-12-12 12:59

Re: misc/74786: Smartlink Modem causes interrupt storm on RELENG_4 and RELENG_5

[cc'ing to FreeBSD-Stable] Hi, I know that the proposed patches I submitted are not the best patches, but given that the next release of RELENG_4 is coming out, would it not be better to commit those to RELENG_4 as they allow the modem to work when it shares an interrupt with another d

vinum crashes by using more then 11 disks on RELENG_4

Hi, Ihas following System dmesg: Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.10-STABLE #1: Tue Nov 30 14:26:29 CET 2004 [EMAIL PROTECTE

vinum crashes the Box by using more then ten disks on RELENG_4

Hi, Ihas following System dmesg: Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.10-STABLE #1: Tue Nov 30 14:26:29 CE

Re: HEADS-UP: RELENG_4 -> 4.11-PRERELEASE

get fixed. The problem is in both RELENG_4 and RELENG_5 http://www.freebsd.org/cgi/query-pr.cgi?pr=74821 I am sure the patches are very ugly looking, but it does fix the problem and it doesnt break default functionality. Without them, anyone using PPPoE against an ERX (most of Canada and a lot

Re: HEADS-UP: RELENG_4 -> 4.11-PRERELEASE

RELENG_4 particularly hard, although RELENG_5 suffers the same problem. ---Mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"

HEADS-UP: RELENG_4 -> 4.11-PRERELEASE

As mentioned in the previous message about the FreeBSD 4.11 Release Cycle beginning, today the RELENG_4 branch was re-named 4.11-PRERELEASE. We are one week away from the initial code freeze for the 4.11 Release. If you are in a position to help with testing and/or debugging for the upcoming

Re: vmstat regression (RELENG_4 -> RELENG_5)

Hello! On Wed, 17 Nov 2004, Paul Mather wrote: kernel devstat(9) subsystem only sees my ad0. Under 4.10-RELEASE, sysctl kern.devstat.numdevs gives 3, but under 5.3-RELEASE only 1. How can I enable disk statistics gathering for disks other than HDD in 5.3-RELEASE? The gstat(8) command will display s

Re: vmstat regression (RELENG_4 -> RELENG_5)

On Wed, 2004-11-17 at 09:51 +0200, Dmitry Pryanishnikov wrote: > Hello! > >While playing with fresh installation of 5.3-RELEASE (GENERIC kernel) I've > noticed that I can only see my HDD in the left lower corner of the systat's > vmstat screen. I also have working floppy and CD-RW drives, both

  1   2   3   >