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
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
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 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
Well, the diff was -c-209704. But you're right, I still see this in the
merge record. Sigh.
On 11/26/2010 11:46 AM, Kostik Belousov wrote:
On Fri, Nov 26, 2010 at 11:18:36AM -0800, Matthew Jacob wrote:
Something like that. 209704 got itself recorded as merged from head. But
nothing ch
Something like that. 209704 got itself recorded as merged from head. But
nothing changed. I'm undoing that so I can do it right. This is the
reason why the geom multipath stuff ended up totally broken in 8.1 even
though I though I had merged it.
Or have I missed something?
On 11/26/2010 8:38
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
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
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
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-
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
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.
__
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
Never mind, reproduced it.
A 'camcontrol devlist -v' on this system would be helpful.
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org
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
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 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 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/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
Ow. No need to be rude :-).
No, I didn't, why do you ask?
Wow, did you copy this from windows? :-)
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr
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
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
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-all@freebsd.org mailing list
http://lists.freebsd.org/mailma
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
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
Pointed out by: scottl
1st bde
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
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
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
Just a total swag here, but reduce the openings via camcontrol to < 32,
or even < 16
1. Any thoughts on how to resolve the regression in the mpt driver
with the r203889 commit?
2. Any thoughts on the behaviour I'm seeing with the mpt_cam_event
messages? Is it possible it's just a driver is
Marcel Moolenaar wrote:
We really need to get to a point where we treat partition types
seriously and
use it to help avoid false positives. Reducing or eliminating false
positives
is critical if we ever want to go towards DWIM or auto-mounting. With the
partition type taken into consideration
30 matches
Mail list logo
