Might be an overheating. Today's nvme drives are notoriously flaky if you
run them without proper heat sink attached to it.
-Max
On Mon, Feb 12, 2024, 4:28 PM Don Lewis wrote:
> I just upgraded my package build machine to:
> FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
> from:
> Fr
How quickly it heats up depends on lots of factors. Usually those devices
burn some 3-7 watts per stick at 100% load, so maybe this would give you
some idea. At least some of them support several toggleable performance
modes, which use throttling internally to limit power consumption to a
certain l
Perhaps if you log r/w queue length for all 4 drives with a reasonable
interval (say 1 second) under the load using gstat(8) and plot all 4 as
function of time on the same graph you should have no problem to visually
identify the culprit(s). At least that's how I would do it.
-Maksym
On Sun, Nov
Just in case someone thinks this is something useful, I've got a PR filed
against git to implement custom $Id$. There are no technical issues with
the change but Git developers are not very keen on merging it in, since
they see this as an obscure feature, no one needs. :-/ So if anyone wants
to chi
Replace '*' with ^T perhaps and catch SIGINFO? 🤔
-Max
On Fri., May 7, 2021, 10:11 a.m. Shawn Webb,
wrote:
> On Fri, May 07, 2021 at 03:49:00PM +0200, Hans Petter Selasky wrote:
> > Time has come that I make a patch for the most central patching tool in
> > FreeBSD, patch :-)
> >
> > https://rev
Re: removing HTTP client please no!!! The current drive to "outlaw" HTTP
coming from companies who see all world via web browser. Totally ignoring
the fact that HTTP != HTTPS in particular in cases where reliability and
lower complexity of the system takes precedence over on-the-wire protocol
secur
This is what we have running in AWS right now, kinda proof of concept but
it's not that difficult to generalize:
[root@ip-172-31-10-188 /usr/local/etc/freeswitch]# mdconfig -lv
md0 preload 160M -
[root@ip-172-31-10-188 /usr/local/etc/freeswitch]# df
Filesystem512-blocks
src/UPDATING entry perhaps in order?
-Max
On Fri, Mar 22, 2019, 11:39 AM Konstantin Belousov wrote:
> On Fri, Mar 22, 2019 at 07:08:18PM +0300, Rozhuk Ivan wrote:
> >
> >
> > ld: error: undefined symbol: xz_dec_init
> > >>> referenced by g_uzip_lzma.c:106
> (/usr/src/sys/geom/uzip/g_uzip_lzma.c
Somebody needs to make collection/submission automatic and make a port out
of it, so that it's as easy as pkg install dmesg_survey &&
dmesg_survey_enabled="YES" in the /etc/rc.conf. JIMHO. I'd gladly make it a
default on all dev boxes within our organization. Might also make a nice
SoC project idea
Not really specific to UEFI, but when ZFS is in use the /boot might be
partially or fully located on the drive that does not correspond to your
boot drive. We've bumped into this issue on AWS recently when our kernel
ended up on second drive after upgrade in a pool that were spanning two EBS
volume
Well, all this suggests to me that there must be some issue with the client
syslog code in the libc, so that if syslog daemon hangs or has some
internal issue that would basically render system mostly unusable. I think
that might be an interesting project for somebody who has some spare time
on han
For the whole disk destruction, hopefully one day we'd have BIO_DELETE
coalesce code, so that you can batch of lot of operations into handful SATA
commands. I've heard rumours imp@ was doing something along those lines. As
well as SSD disks smart enough to process those requests in the background.
On Sun, Jul 31, 2016 at 1:36 PM, Mateusz Guzik wrote:
> On Sun, Jul 31, 2016 at 07:03:08AM -0700, Adrian Chadd wrote:
> > Hi,
> >
> > Did you test on any 1, 2, 4, 8 cpu machines? just to see if there are
> > any performance degredations on lower count CPUs?
> >
>
> I did not test on machines whic
Hi Glen, nice update, glad being of some help. The slowdown may be related
to the fact that geom_uzip reads whole compressed cluster, which is 20-30k
typically, even if only single block from that cluster is requested. I
imagine it might impact rc.d, which is essentially bunch of small(ish)
shell s
have some more specific questions, I'll be glad to help.
-Max
On Wed, Jul 13, 2016 at 6:52 AM, Glen Barber wrote:
> On Mon, Jul 11, 2016 at 05:23:32PM -0700, Maxim Sobolev wrote:
> > P.S. Just in case if somebody wants to integrate this method into FreeBSD
> > liveCD build,
Another option for the kvm installs and that we are using for many years
here is to pre-load root UZIP image into RAM. With some easy trimming you
can bring base system down to 30MB or so compressed. Yes, bit of delay to
load, but the kernel alone is around 10MB compressed, so it's not an order
of
P.S. Just in case if somebody wants to integrate this method into FreeBSD
liveCD build, we do a bit of trick there by making normal ISO9660 file
system with compressed kernel and relevant boot pieces and then also
sticking in BSD label on the same disk image. It turns out ISO9660 and BSD
disklabel
You don't need that much for OS really if you compress the underlying FS
(be that ISO9660 or UFS) with the mkuzip. Just as an extreme example of
that, we have liveCD-type image that deals with provisioning a new systems
and troubleshooting issues on around 40MB ISO. That includes nearly all of
the
Mon, 20 Jun 2016, Luiz Otavio O Souza wrote:
> >
> >> On Sun, Jun 19, 2016 at 1:11 AM, Maxim Sobolev wrote:
> >>> Jim, some update from here. Running r283287 of the driver, I still see
> the
> >>> same "watchdog timeout" messages, but they do not lead
P.S. Asynchronous nature of vt is also a poor excuse in my view. There are
plenty ways to do it asynchronously, while preserving updates order. It
should not be one-or-the-other deal.
On Thu, Jun 30, 2016 at 7:21 AM, Maxim Sobolev wrote:
> Ed, I think this is bug, not a feature. People exp
MHO.
-Max
On Thu, Jun 30, 2016 at 6:42 AM, Ed Schouten wrote:
> Hi Maxim,
>
> 2016-06-28 21:14 GMT+02:00 Maxim Sobolev :
> > P.S. Just if somebody is interested in fixing those "fast scrolling text
> > turns into garbage" display issues, here is some screenshots of
P.S. Just if somebody is interested in fixing those "fast scrolling text
turns into garbage" display issues, here is some screenshots of one of my
11-alpha3 systems captured with a camera at 120fps. As you can see text
tears down quite badly. I am curious if it's some lack of proper ordering
of upd
EVFILT_PROC,
> but no one has done that yet.
>
> -sc
>
>
>
> --
> Sean Chittenden
> s...@chittenden.org
>
> > On Jun 22, 2016, at 07:26 , Maxim Sobolev wrote:
> >
> > Konstantin,
> >
> > Not if you do sem_unlink() immediately, AFAIK. A
ax
On Wed, Jun 22, 2016 at 3:02 AM, Konstantin Belousov
wrote:
> On Tue, Jun 21, 2016 at 12:48:00PM -0700, Maxim Sobolev wrote:
> > Thanks, Konstantin for the great work, we are definitely looking forward
> to
> > get all those improvements to be part of the default FreeBSD kernel/p
Ed,
For once, we have pretty good VGL support in the libSDL, at least version
1.x has been tested and seems to be building/working fine with
sc(4)+vesa(4) on supported hardware/VMs.
http://libsdl.org/download-1.2.php
So pretty much any application built against SDL 1.2 library should work.
Unles
Thanks, Konstantin for the great work, we are definitely looking forward to
get all those improvements to be part of the default FreeBSD kernel/port.
Would be nice if you can post an update some day later as to what's
integrated and what's not.
Just in case, I've opened #14206 with PG to switch us
scope gradually, but with vt it might
actually revive it by opening it up for getting it running on most today's
x86 hardware and smaller arm systems as well.
-Max
On Tue, Jun 21, 2016 at 11:33 AM, Maxim Sobolev
wrote:
> Ed,
>
> For once, we have pretty good VGL support in the l
For what it's worth: my two biggest grievances with the vt(4) vs. sc(4) is
the unordered updates in the graphics mode which makes watching quickly
scrolling text on something like virtual machine console funky and lack of
support in the libvgl(3). The latter I find particularly hard to explain,
sin
Nice to hear. I am building it right now. Gotta get you some results in the
next few hours. Thanks!
-Max
On Mon, Jun 20, 2016 at 3:33 PM, Keith White wrote:
> On Mon, 20 Jun 2016, Luiz Otavio O Souza wrote:
>
> On Sun, Jun 19, 2016 at 1:11 AM, Maxim Sobolev wrote:
>>
>>&g
: watchdog timeout
cpsw0: Unable to cleanly shutdown transmitter
On Sat, Jun 18, 2016 at 2:09 PM, Maxim Sobolev wrote:
> Jim,
>
> Yes, I've seen those. There were just handful of revision into the driver
> between my old good kernel and now, most of them are from you guys:
>
>
> These were lightly tested on BBB prior to being committed.
>
> -- Jim
>
> > On Jun 18, 2016, at 11:49 AM, Maxim Sobolev wrote:
> >
> > Well, I am not sure either as I don't have any issue restarting it
> > afterwards.
> >
> > Yes, it seems to
meout
cpswss0: Unable to cleanly shutdown transmitter
On Sat, Jun 18, 2016 at 1:09 AM, Svatopluk Kraus wrote:
> On Sat, Jun 18, 2016 at 8:50 AM, Maxim Sobolev
> wrote:
> > Updated my BBB to the latest -current, immediately got this while trying
> to
> > make world over ssh
Updated my BBB to the latest -current, immediately got this while trying to
make world over ssh console:
06:02:17 CPSW watchdog cpswss0: watchdog timeout
cpswss0: Unable to cleanly shutdown transmitter
Interface seems to be locked after that, no traffic comes in or out.
This is:
FreeBSD 11.0-AL
By the way, as far as I understand, fdisk(8) is long depreciated now,
superseded by the gpart(8). Somebody needs to pick a big shiny axe and root
it out for good.
-Max
On Jun 8, 2016 1:43 AM, "Matthias Apitz" wrote:
> El día Tuesday, June 07, 2016 a las 09:15:03AM -0400, Allan Jude escribió:
>
>
Yeah, indeed false positive, app error. Sorry for noise and thanks for
feedback.
-Max
On Jun 3, 2016 10:18 AM, "Konstantin Belousov" wrote:
> On Fri, Jun 03, 2016 at 08:04:29AM -0700, Maxim Sobolev wrote:
> > Konstantin,
> >
> > Thanks for taking your time looking
wrote:
> On Thu, Jun 02, 2016 at 09:16:47PM -0700, Maxim Sobolev wrote:
> > Hi there, we have an application here which is trying to measure UDP
> > command/response round-trip-time. It runs two posix threads (more
> actually,
> > but that's probably irrelevant), one (let
a. multiple cores.
b. makes no difference
c. yes, I believe so
kern.timecounter.tsc_shift: 1
kern.timecounter.smp_tsc_adjust: 0
kern.timecounter.smp_tsc: 1
kern.timecounter.invariant_tsc: 1
machdep.tsc_freq: 2658118740
machdep.disable_tsc_calibration: 0
machdep.disable_tsc: 0
d. no, single socket
Hi there, we have an application here which is trying to measure UDP
command/response round-trip-time. It runs two posix threads (more actually,
but that's probably irrelevant), one (let's call it A) that does high-level
logic and the second one (B) that does network packet I/O.
The sending side i
I am sorry to maybe sound like an old grudge here, but can somebody take a
sweep at the bug reports filled against ports-mgt/pkg in the last year or
so? Packaging base system is surely challenging and exciting task, and
great bikesheed topic too, but there are lot of critical bugs in the code
that
On Fri, Apr 15, 2016 at 10:30 AM, Warner Losh wrote:
>
>
> On Fri, Apr 15, 2016 at 11:25 AM, Maxim Sobolev
> wrote:
>
>> Conrad, yes, you can, but sticking it into FreeBSD source tree IMHO
>> restricts your options somewhat. If it's your private code you can e
_IOCHED_LOW_LAT or something.
On Fri, Apr 15, 2016 at 9:22 AM, Conrad Meyer wrote:
> Max,
>
> If you implement a new IO scheduler you can name it whatever you like.
> "NG" isn't any more meaningful than "Netflix."
>
> Best,
> Conrad
>
> On Fri, Ap
Great, work Warner, thanks! Small note, though. The CAM_IOSCHED_NETFLIX
seems like a quite poor name for a kernel option. IMHO there is no good
reason for polluting it with the name of the company that sponsored the
development. I don't think we have any precedents of doing this unless the
option i
Pentium-IV in 1980? I think we are talking about +35 years from now.
-Max
On Fri, Jan 29, 2016 at 12:40 AM, Slawa Olhovchenkov wrote:
> On Thu, Jan 28, 2016 at 10:30:25PM -0800, Maxim Sobolev wrote:
>
> > That would be like trying to install FreeBSD 11 on PDP-11 hardware. Good
&
That would be like trying to install FreeBSD 11 on PDP-11 hardware. Good
luck with that, Slawa, you'll need it! :)
On Thu, Jan 28, 2016 at 8:09 AM, Allan Jude wrote:
> On 2016-01-28 11:06, Slawa Olhovchenkov wrote:
> > On Thu, Jan 28, 2016 at 02:18:06PM +0100, Baptiste Daroussin wrote:
> >
> >>
For what it's worth, I agree with David. This looks like definite misuse of
the constant. If app X requires min size of stack of Y, it's fullish of it
if to expect our PTHREAD_STACK_MIN somehow accommodate that. It should be
really using MAX(PTHREAD_STACK_MIN, Y) to set its stack instead. Should be
ousov
wrote:
> On Tue, Dec 08, 2015 at 04:52:05PM +0100, Dag-Erling Sm??rgrav wrote:
> > Maxim Sobolev writes:
> > > Hi, while working on some unrelated feature I've noticed that at least
> > > those two system calls are not returning proper value (-1) on error
Then it's documentation bug or maybe some discrepancy between SUS and
POSIX.
$ man posix_fadvise
RETURN VALUES
The posix_fadvise() function returns the value 0 if successful;
otherwise
the value -1 is returned and the global variable errno is set to
indicate
the error.
STANDARDS
Hi, while working on some unrelated feature I've noticed that at least
those two system calls are not returning proper value (-1) on error.
Instead actual errno value is returned from the syscall verbatim,
i.e. posix_fadvise() returns 22 on EINVAL. Attached patch fixes that
problem, however I am no
For what's worth we are using modded GBDE in one of the products to provide
copy protection for the firmware and encryption of user's data. GELI is
nice, but it's way much more end-user oriented. Also GBDE code is very
stable, which may look bad from somebody using it to protect his pr0n
collection
On 11/7/2011 2:57 PM, Maxim Sobolev wrote:
On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote:
Unlikely; the inp is properly locked there and the udp info attach
better still be valid there; your problem is most likely elsewhere;
try to see if you have other threads and see what they do at the same
On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote:
Unlikely; the inp is properly locked there and the udp info attach
better still be valid there; your problem is most likely elsewhere;
try to see if you have other threads and see what they do at the same
time, etc. You would need to race with udp_det
Panic screenshot is here:
http://sobomax.sippysoft.com/ScreenShot859.png
-Maxim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd
Hi Gang,
We are seeing repeatable panics under high PPS load on our production
systems. It happens when the traffic gets into the range or 200MBps and
150-200K PPS. We have been managed to track it down to the following
piece of code:
(gdb) l *udp_input+0x5d2
0x806f6202 is in udp_inp
Mikolaj,
Upon further investigation it appears that there is a logic mistake in
hastd's server/client buffering code. I've just applied a fix and it
immediately solved the issue for me. Please see r222688 for details.
I plan to MFC it ASAP, as otherwise hastd is not functional when
compressi
On 5/29/2011 4:11 AM, Mikolaj Golub wrote:
This might be MSG_WAITALL issue I described on net@ (look for the thread
"recv() with MSG_WAITALL might stuck when receiving more than rcvbuf", and
also kern/154504).
Could you please try the patch?
http://people.freebsd.org/~trociny/uipc_socket.c.patc
On 5/25/2011 12:07 PM, Daniel Gerzo wrote:
I can only confirm this behavior. I have already reported this to
Mikolaj and we are trying to hunt down the problem. I have started
observing suddenly after some update. Unfortunately I haven't noted
which revision I started to observe this bug ;(
Do y
On 5/25/2011 11:21 AM, Maxim Sobolev wrote:
Hi Pawel,
I am observing strange errors while synchronizing the data between
primary and secondary. I keep getting the following error messages:
May 25 11:09:19 eights hastd[10113]: [test] (secondary) Unable to
receive request header: Socket is not
Hi Pawel,
I am observing strange errors while synchronizing the data between
primary and secondary. I keep getting the following error messages:
May 25 11:09:19 eights hastd[10113]: [test] (secondary) Unable to
receive request header: Socket is not connected.
May 25 11:09:24 eights hastd[3757
On 5/21/2011 8:57 AM, Pawel Jakub Dawidek wrote:
Hmm, hastd keeps separate bitmap for synchronization. It is stored in
am_syncmap field. Blocks that are dirtied during regular writes should
not effect on synchronization bitmap and synchronization progress.
Possibly, but this policy is not very
Hi Pawel,
I am trying to use hastd(8) over slow links and one problem is apparent
right now - current approach with synchronizing content sequentially is
not working in this case. What happens is that hastd hits the first
frequently updated block and cannot make any progress anymore. In my
ca
On 5/17/2011 1:28 PM, Maxim Sobolev wrote:
The next thing to make it usable is to make "async" mode working. I
think simple support for that mode can be easily implemented by not
sending write request to the remote note at all, but instead just doing
it locally and kicking the synch
Hi Pawel,
I am trying to use hastd(8) over slow links and one problem is apparent
right now - current approach with synchronizing content sequentially is
not working in this case. What happens is that hastd hits the first
frequently updated block and cannot make any progress anymore. In my
ca
On 9/22/2010 6:37 AM, John Baldwin wrote:
Unfortunately this can't be MFC'd to 7 as it would destroy the ABI for
existing klds.
Ah, ok, sorry, I did only check RELENG_7. Can we make it a kernel option
then?
Regards,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
T/
Hi,
Is there any reason to keep MAXCPU at 16 in the default kernel config?
There are quite few servers on the market today that have 24 or even 32
physical cores. With hyper-threading this can even go as high as 48 or
64 virtual cpus. People who buy such hardware might get very
disappointed f
Gary Jennejohn wrote:
On Fri, 30 Apr 2010 13:23:13 -0700
Maxim Sobolev wrote:
Hi,
Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to
set length of the outgoing packets queue. The default value for that
parameter is only 50, which is pretty low especially for the cases
Julian Elischer wrote:
On 4/30/10 1:23 PM, Maxim Sobolev wrote:
Hi,
Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to
set length of the outgoing packets queue. The default value for that
parameter is only 50, which is pretty low especially for the cases when
the system
Hi,
Many network drivers in the FreeBSD kernel use the IFQ_MAXLEN value to
set length of the outgoing packets queue. The default value for that
parameter is only 50, which is pretty low especially for the cases when
the system handles lot of small packets and can cause ENOBUFS in
applications
Alexander Sack wrote:
On Tue, Apr 27, 2010 at 5:25 PM, John Baldwin wrote:
On Tuesday 27 April 2010 5:06:37 pm Maxim Sobolev wrote:
John Baldwin wrote:
On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote:
John Baldwin wrote:
Hmm, I think you should definitely commit the atkbdc_isa.c
John Baldwin wrote:
On Tuesday 27 April 2010 4:26:09 pm Maxim Sobolev wrote:
John Baldwin wrote:
Hmm, I think you should definitely commit the atkbdc_isa.c change first of
all. I'm still thinking about the other change. I wonder if we can figure
out that a keyboard isn't pres
John Baldwin wrote:
Hmm, I think you should definitely commit the atkbdc_isa.c change first of
all. I'm still thinking about the other change. I wonder if we can figure
out that a keyboard isn't present sooner somehow? Do you know if the keyboard
appears to be present but just slow vs if the
Richard Tector wrote:
On 22/04/2010 19:48, Maxim Sobolev wrote:
Alexander Motin wrote:
So what is the public opinion: Is the lack of ataraid(4) fatal or we can
live without it?
I believe it's fatal in long run. This would present significant
challenge for users who rely on
John Baldwin wrote:
On Thursday 22 April 2010 2:28:26 pm Maxim Sobolev wrote:
John Baldwin wrote:
On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote:
Maxim Sobolev wrote:
There is already a code to detect non-existing AT keyboard and avoid
attaching atkbd to it. The code is i386-only
Alexander Motin wrote:
So what is the public opinion: Is the lack of ataraid(4) fatal or we can
live without it?
I believe it's fatal in long run. This would present significant
challenge for users who rely on this functionality from upgrading from
8.x to 9.0 later on. Especially for ones usi
John Baldwin wrote:
On Thursday 22 April 2010 6:05:04 am Maxim Sobolev wrote:
Maxim Sobolev wrote:
There is already a code to detect non-existing AT keyboard and avoid
attaching atkbd to it. The code is i386-only at the moment, I am trying
to figure out how to modify it so that it works on
Maxim Sobolev wrote:
There is already a code to detect non-existing AT keyboard and avoid
attaching atkbd to it. The code is i386-only at the moment, I am trying
to figure out how to modify it so that it works on amd64 as well.
Looks like this huge delay is caused by the inb() being
Hi,
According to the manual page for the SYSCTL_XXX(9) family of functions,
in order to use them one needs to include sys/types.h and sys/sysctl.h.
However, if you do just that the code doesn't compile due to missing
DATA_SET() macros, which is defined in sys/linker_set.h. My question is
whet
John Baldwin wrote:
On Tuesday 20 April 2010 7:35:46 pm Matthew Jacob wrote:
On 04/20/2010 03:44 PM, Maxim Sobolev wrote:
Maxim Sobolev wrote:
Maybe try adding
hint.atkbdc.0.disabled="1"
hint.atkbd.0.disabled="1"
to /boot/device.hints? That has reportedly removed minu
Maxim Sobolev wrote:
Maybe try adding
hint.atkbdc.0.disabled="1"
hint.atkbd.0.disabled="1"
to /boot/device.hints? That has reportedly removed minute-long boot
delays on some Nehalem machines.
No, that have not helped at all. I measured the delay - it's about 6
min
John Baldwin wrote:
On Tuesday 20 April 2010 8:30:42 am Maxim Sobolev wrote:
Update: I've discovered that the 7.3 kernels actually boot after some
ridiculously long waiting period after the "boot" command (i.e. 10
minutes or even more). I suspect that it might be caused by the
John Baldwin wrote:
On Tuesday 20 April 2010 8:30:42 am Maxim Sobolev wrote:
Update: I've discovered that the 7.3 kernels actually boot after some
ridiculously long waiting period after the "boot" command (i.e. 10
minutes or even more). I suspect that it might be caused by the
Update: I've discovered that the 7.3 kernels actually boot after some
ridiculously long waiting period after the "boot" command (i.e. 10
minutes or even more). I suspect that it might be caused by the memory
probing, which as far as I know the FreeBSD does to determine if the
physical memory th
Maxim Sobolev wrote:
the boot command, HEAD - filled in console with funny blinking characters.
...and hanged machine after that as well.
-Maxim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
Hi,
For the first time in many years, I've stumbled across a server hardware
where FreeBSD kernel refuses to boot. It's FUJITSU PRIMERGY RX200 S5
server with 2x Quad core E5520 processors and 16GB of RAM. Linux boots
on that hardware just fine. Linux dmesg is available here:
http://sobomax.s
Jayachandran C. wrote:
On Thu, Mar 04, 2010 at 06:34:03PM +0530, C. Jayachandran wrote:
I'm testing this on the mips platform, but I think there is an issue
with change that made sectorsize int64_t, because the ioctl
DIOCGSECTORSIZE used to read sector size seems to take u_int. This
quick chang
Folks,
I've noted that the following inconsistency exists in make release. If
there is a install.cfg file in /usr/src/release when executing make
release (the file which if exists is placed into the root of mfs and
customises behaviour of sysinstall), /usr/src/release/install.cfg takes
precede
No, everything seems real - at least Matt replies to e-mails
sent to him on this topic. There is also a live nntp server
up and running @ dragonflybsd.org, I saw Matt and Terry Lambert
discussing kernel things this morning there. I doubt that somebody
will be able to impersonate both Matt and Terry
[EMAIL PROTECTED] wrote:
>
> In message <[EMAIL PROTECTED]>, Maxim Sobolev writes:
> >Hi,
> >
> >It seems that disklabel is currently broken on -current. In `read' mode it
> >reports incorrect information about disk layout:
>
> Don't use the
Hi,
It seems that disklabel is currently broken on -current. In `read' mode it
reports incorrect information about disk layout:
root@notebook# disklabel -r ad0s1
# /dev/ad0s1c:
type: unknown
disk: amnesiac
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 240
sectors/cylinder: 15
On Sat, Feb 08, 2003 at 03:06:27PM -0800, Kris Kennaway wrote:
> On Sat, Feb 08, 2003 at 02:59:30PM -0800, Kris Kennaway wrote:
> > Can someone take a look at lib/libc/gen/semctl.c and tell me where
> > the __semctl() sysctl should be prototyped?
>
> Also _fpathconf() in lib/libc/gen/statvfs.c
/u
Hmm, strange, pccard works righ OOB on my 600E running current.
-Maxim
Michael Lamb wrote:
>
> First time poster and susbscriber, someone suggested that I email my
> findings to the freebsd-current list, so hopefully this is the right
> place.
>
> I have been playing with FreeBSD 5.0 on my Thin
The same ("automatic" power on after power off ) is here - IBM ThinkPad
600E.
-Maxim
On Sat, Dec 28, 2002 at 08:31:53AM -0500, Mark Evenson wrote:
> Jens Trzaska <[EMAIL PROTECTED]> writes:
>
> > On Thu, Dec 05, 2002 at 10:37:49AM -0800, Nate Lawson wrote:
>
> > > Can everyone with the auto pow
I've also bumped into this problem, when after upgrading memory I
didn't increase swap size, so that after a panic the system
overwrote disklabel. Fortunately, my root partition was placed
after swap, not before it, so that recreating disklaber revived
the system.
-Maxim
On Fri, Dec 13, 2002 at 1
On Wed, Nov 06, 2002 at 05:47:51PM -0800, Kris Kennaway wrote:
> Can someone explain why the perl wrapper needs to be hardlinked to
> perl5.6.1?
>
> The problem I am seeing is this:
>
> USE_PERL5=yes in a port adds the following BUILD_DEPENDS:
>
> enigma# make -V BUILD_DEPENDS
> perl5.6.1:/usr/p
On Sat, Nov 02, 2002 at 08:04:21PM -0800, Kris Kennaway wrote:
> The latest bento run on 5.0 is the first to build without perl
> present: previously, two of the portbuild scripts were written in
> perl, so I had to always pkg_add it into the chroot environment. Now
> that these scripts have been
Hi,
I've noticed that after upgrading my -current box (15 Oct snapshot)
the `nroff -mandoc foo.X | less' construction no longer does produce
valid results. I'm seeing ESC[ all over the place, i.e.:
ESC[1mNAMEESC[0m
ESC[1mradioctl ESC[22m- control radio tuners
ESC[1mSYNOPSISESC[0m
ESC[1
On Sat, Oct 19, 2002 at 12:02:21AM -0700, Julian Elischer wrote:
> Unfortunaly you need to replace almost all X11 stuff..
Not quite. You can easily identify problematic packages by doing something
like:
$ for f in `find /usr/X11R6/ -type f`; do nm $f 2>/dev/null | grep -qw "U __sF" &&
echo $f; d
Robert Watson wrote:
>
> On Wed, 16 Oct 2002, Maxim Sobolev wrote:
>
> > What about source-level compatibility, which IMO is a good thing, at
> > least if it doesn't add too much complexity (it clearly doesn't in this
> > case)? Also, handling single
On Wed, Oct 16, 2002 at 02:03:53AM -0700, Terry Lambert wrote:
> Robert Watson wrote:
> > While I think support for the IPC_64 flag under emulation is useful, I'd
> > rather make use of compatibility system calls and type improvements for
> > the base FreeBSD implementation of the System V IPC API
Linux solved the problem by introducing a new flag for {msg,shm,sem}ctl(3)
interfaces (IPC_64), which if set tells the kernel that user supplies
new version of the structure. The kernel itself internally keeps all
relevant information already in IPC_64 format, doing conversion before
returning it
Maxim Sobolev wrote:
>
> Maxim Sobolev wrote:
> >
> > Maxim Sobolev wrote:
> > >
> > > Andrew Gallatin wrote:
> > > >
> > > > Maxim Sobolev writes:
> > > >
> > > > > > Between this, and the Type1 bezier
1 - 100 of 596 matches
Mail list logo
