I think it is a very important feature to ensure release builds are not
polluted by local changes in /etc/src.conf, etc. I think it would be good
to support both models perhaps, but for our official release builds I think
we need the clean environment. I certainly use 'make release' now for m
Ow. No need to be rude :-).
No, I didn't, why do you ask?
Wow, did you copy this from windows? :-)
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsub
On 5/12/2010 7:23 AM, Scott Long wrote:
On May 12, 2010, at 8:20 AM, Matthew Jacob wrote:
Ow. No need to be rude :-).
No, I didn't, why do you ask?
Wow, did you copy this from windows? :-)
Actually I'm impressed that someone is using my code. I wrote it on
On 05/12/2010 11:12 AM, Dmitry Marakasov wrote:
* Matt Jacob (mja...@freebsd.org) wrote:
- (void)make_dev_alias(softc->dev, "sg%c", 'a' + periph->unit_number);
+ if (periph->unit_number< 26) {
+ (void)make_dev_alias(softc->dev, "sg%c", periph->unit_number +
'a');
On 5/15/2010 8:17 PM, Rob Farmer wrote:
On Sat, May 15, 2010 at 1:26 PM, Matt Jacob wrote:
Author: mjacob
Date: Sat May 15 20:26:10 2010
New Revision: 208119
URL: http://svn.freebsd.org/changeset/base/208119
Log:
Whap. Hook up some wires that were forgotten a few months ago and restore
On 6/7/2010 12:20 PM, Alexander Kabaev wrote:
On Mon, 7 Jun 2010 17:41:34 + (UTC)
Matt Jacob wrote:
+ /*
+* Add some addressing info.
+*/
+ memset(&cts, 0, sizeof (cts));
Hi,
you need to declare what cts is first. Kernel cannet be compiled right
now
On 6/28/2010 2:23 PM, Chagin Dmitry wrote:
On Wed, Jun 02, 2010 at 06:06:32PM +, Matt Jacob wrote:
Author: mjacob
Date: Wed Jun 2 18:06:32 2010
New Revision: 208752
URL: http://svn.freebsd.org/changeset/base/208752
Log:
Protect periph drivers list and rearrange things to minimize th
Never mind, reproduced it.
A 'camcontrol devlist -v' on this system would be helpful.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.
Fixed, thanks.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Excuse my ignorance, but aren't signals supposed to be to processes, not
specific threads?
My memory/knowledge of Posix in this area is very rusty.
On Tuesday 29 June 2010 5:05:22 pm Ed Schouten wrote:
* John Baldwin wrote:
Log:
Send SIGPIPE to the thread that issued the offend
John Baldwin wrote:
On Wednesday 30 June 2010 9:59:34 am Matthew Jacob wrote:
Excuse my ignorance, but aren't signals supposed to be to processes, not
specific threads?
Not for synchronous events. For example, when you get a segfault due to a
NULL pointer the SIGSEGV is sent t
On 8/17/2010 10:59 AM, Scott Long wrote:
This is violates the policy that CAM has effectively had for a long time that
separates protocol error handling in the periph from transport error recovery
in the SIM. I think it's better to encourage SIMs to register an
AC_LOST_DEVICE event and handle
But not amd64 please.
Keep in mind the PAE case where you cannot effectively specify a 4GB
boundary. I used a 2GB boundary for twa(4) in the PAE case to deal
with the boundary issue. Probably though, bus_dma should just always
enforce a 4GB boundary, at least on x86.
__
FWIW, policy should be set the callers of g_io_request (IMO)
I don't feel strongly one way or the other, but I thought that
g_io_request()'s job was to execute the request and to test invariants,
not to set policy. Perhaps I misinterpreted it's role.
--
Justin
Err, I don't think _mtx_lock_sleep() is guarded in that fashion? I have an
old patch to do that but have never committed it. If we want that we should
probably change rwlocks and sxlocks to have also not block when panicstr is
set.
Seems to me you are backing into interesting territory here-
Absolutely. I have patches for RELENG_7, but have had trouble moving
it to head.
Seems to me you are backing into interesting territory here- getting a
bit more like Solaris.
If you *do* do this, then you really *do* need to stop all other CPUs
when you panic, or else it's likely you'll doubl
FWIW, I think that this would be a *good* thing. One of the problems
with panic is that you can't really reset the state of the world, so
most kernel services are not reliable. Unfortunately, mechanisms for
preserving forensics for debug require some kernel services.
Seems to me you are backin
There are a lot of accelerations that can be applied here- so much so
that Panasas elected to stick with minidumps rather than go to text
dumps, even though there is a fairly hard time limit that a blade can be
down before more drastic error recovery mechanisms for the shelf kick in.
It turns
On 12/7/2010 1:54 PM, Andriy Gapon wrote:
on 07/12/2010 22:46 Bruce Cran said the following:
Don't warn if a partition appears not to be aligned on a track boundary.
Modern disks use LBA and create a fake CHS geometry that doesn't have any
relation to the on-disk layout of data.
You
Geometry is still important. Trying booting a USB flash drive on all
BIOS' with a 63/255 geometry instead of a 64/32 geometry.
On 12/7/2010 2:14 PM, Andriy Gapon wrote:
on 08/12/2010 00:05 Matthew Jacob said the following:
On 12/7/2010 1:54 PM, Andriy Gapon wrote:
on 07/12/2010 22:46
On 5/12/2013 8:54 AM, Dmitry Morozovsky wrote:
On Sun, 12 May 2013, Eitan Adler wrote:
Author: eadler
Date: Sun May 12 15:23:59 2013
New Revision: 250565
URL: http://svnweb.freebsd.org/changeset/base/250565
Log:
Make newsyslog compress logs with xz instead of bzip2 to save space.
While it
On 6/15/2013 5:46 AM, Alexander Motin wrote:
Author: mav
Date: Sat Jun 15 12:46:38 2013
New Revision: 251792
URL: http://svnweb.freebsd.org/changeset/base/251792
Log:
Restore use of polling mode for disk cache flush in case of kernel panic.
While I am not sure that any extra hardware acces
As well as breaking several RFCs
A stock kernel cannot ping 127.0.0.1. It is claimed there is no route to
127.0.0.1. David Wolfskill has the same problem, as have others in the
freebsd-current@ mailing list. I don't know about others, but not being
able to connect to 127.0.0.1 totally breaks
On 03/10/2010 10:26 AM, Julian Elischer wrote:
Matthew Jacob wrote:
As well as breaking several RFCs
A stock kernel cannot ping 127.0.0.1. It is claimed there is no
route to
127.0.0.1. David Wolfskill has the same problem, as have others in the
freebsd-current@ mailing list. I don't
Pointed out by: scottl
1st bde
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
On 3/18/2010 6:16 PM, Xin LI wrote:
Author: delphij
Date: Fri Mar 19 01:16:53 2010
New Revision: 205307
URL: http://svn.freebsd.org/changeset/base/205307
Log:
SSE is enabled by default about 5 years ago so there is no point pretending
that we support I486 and I586 CPUs in the GENERIC kerne
And the crowd roars it's approval!
or not.
If I'm not mistaken this means that the install CDs will no longer
even boot on a lot of machines.
If I'm not mistaken, the GENERIC kernels won't boot and run fully on a
real i386/i486 anyway.
___
sv
Does anyone out there have a 486 DX4 even? Can you boot 8.0 CDs?
or not.
If I'm not mistaken this means that the install CDs will no longer
even boot on a lot of machines.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailm
On 3/18/2010 7:11 PM, Mark Linimon wrote:
On Thu, Mar 18, 2010 at 06:44:45PM -0700, Julian Elischer wrote:
If I'm not mistaken this means that the install CDs will no longer even
boot on a lot of machines.
I wonder how much RAM most of those systems have ...
mcl
IIRC, my DX2 486
On 3/19/2010 5:10 AM, Poul-Henning Kamp wrote:
In message<201003190759.56385@freebsd.org>, John Baldwin writes:
On Thursday 18 March 2010 9:16:53 pm Xin LI wrote:
All the x86 world is not rack-mounted 64-bit servers. We should not remove
support for non-686 CPUs for no good r
30 matches
Mail list logo
