Re: nvme controller reset failures on recent -CURRENT

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: >

Re: nvme timeout issues with hardware and bhyve vm's

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

Re: CAM: extract HDD informations about failure/to fail?

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

Re: Future of ident(1)

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

Re: Patch for patch, but not foreach :-)

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 :-) > > > >

Re: Deprecating ftpd in the FreeBSD base system?

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

Re: CTF: UEFI HTTP boot support

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 Filesystem

Re: FreeBSD 12 kernel broken

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 >

Re: SCSI and dmesg

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

Re: UEFI booting survey

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

Re: r316958: booting a server takes >10 minutes!

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

Re: Destroy GPT partition scheme absolutely, how?

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.

Re: [PATCH] randomized delay in locking primitives, take 2

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

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

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

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

have some more specific questions, I'll be glad to help. -Max On Wed, Jul 13, 2016 at 6:52 AM, Glen Barber <g...@freebsd.org> 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 >

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

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

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

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

Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

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

Re: BBB (cpsw(4)) seems to be broken in the latest 11-current

hite <kwh...@site.uottawa.ca> wrote: > > > On 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 > &

Re: console in 11.0-ALPHA4

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 <sobo...@freebsd.org> wrote: > Ed, I think th

Re: console in 11.0-ALPHA4

MHO. -Max On Thu, Jun 30, 2016 at 6:42 AM, Ed Schouten <e...@nuxi.nl> wrote: > Hi Maxim, > > 2016-06-28 21:14 GMT+02:00 Maxim Sobolev <sobo...@freebsd.org>: > > P.S. Just if somebody is interested in fixing those "fast scrolling text > > turns into garbage&

Re: console in 11.0-ALPHA4

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

Re: PostgreSQL performance on FreeBSD

this could be replaced with kqueue(2) EVFILT_PROC, > but no one has done that yet. > > -sc > > > > -- > Sean Chittenden > s...@chittenden.org > > > On Jun 22, 2016, at 07:26 , Maxim Sobolev <sobo...@freebsd.org> wrote: > > > > Konstantin, > > &

Re: PostgreSQL performance on FreeBSD

22, 2016 at 3:02 AM, Konstantin Belousov <kostik...@gmail.com> 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 FreeB

Re: console in 11.0-ALPHA4

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.

Re: PostgreSQL performance on FreeBSD

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

Re: console in 11.0-ALPHA4

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 <sobo...@sippysoft.com> wrote: > Ed, > > For once, we have pretty good

Re: console in 11.0-ALPHA4

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,

Re: BBB (cpsw(4)) seems to be broken in the latest 11-current

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 <kwh...@site.uottawa.ca> wrote: > On Mon, 20 Jun 2016, Luiz Otavio O Souza wrote: > > On Sun, Jun 19, 2016 at 1:11 AM, Maxi

Re: BBB (cpsw(4)) seems to be broken in the latest 11-current

: watchdog timeout cpsw0: Unable to cleanly shutdown transmitter On Sat, Jun 18, 2016 at 2:09 PM, Maxim Sobolev <sobo...@freebsd.org> 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 ar

Re: BBB (cpsw(4)) seems to be broken in the latest 11-current

MAC mode. > > These were lightly tested on BBB prior to being committed. > > -- Jim > > > On Jun 18, 2016, at 11:49 AM, Maxim Sobolev <sobo...@freebsd.org> wrote: > > > > Well, I am not sure either as I don't have any issue restarting it > > afterwards. >

Re: BBB (cpsw(4)) seems to be broken in the latest 11-current

cpswss0: Unable to cleanly shutdown transmitter On Sat, Jun 18, 2016 at 1:09 AM, Svatopluk Kraus <onw...@gmail.com> wrote: > On Sat, Jun 18, 2016 at 8:50 AM, Maxim Sobolev <sobo...@freebsd.org> > wrote: > > Updated my BBB to the latest -current, immediately got this wh

BBB (cpsw(4)) seems to be broken in the latest 11-current

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

Re: memstick && Invalid partition table

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

Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads

Yeah, indeed false positive, app error. Sorry for noise and thanks for feedback. -Max On Jun 3, 2016 10:18 AM, "Konstantin Belousov" <kostik...@gmail.com> wrote: > On Fri, Jun 03, 2016 at 08:04:29AM -0700, Maxim Sobolev wrote: > > Konstantin, > > > >

Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads

> 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's cal

Re: CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads

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

CLOCK_MONOTONIC / CLOCK_UPTIME is not really monotonic between threads

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

Re: [CFT] packaging the base system with pkg(8)

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

Re: Heads up

On Fri, Apr 15, 2016 at 10:30 AM, Warner Losh <i...@bsdimp.com> wrote: > > > On Fri, Apr 15, 2016 at 11:25 AM, Maxim Sobolev <sobo...@freebsd.org> > wrote: > >> Conrad, yes, you can, but sticking it into FreeBSD source tree IMHO >> restricts your options

Re: Heads up

or something. On Fri, Apr 15, 2016 at 9:22 AM, Conrad Meyer <c...@freebsd.org> 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 F

Re: Heads up

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

Re: Packaging the FreeBSD base system with pkg(8)

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 <s...@zxy.spb.ru> wrote: > On Thu, Jan 28, 2016 at 10:30:25PM -0800, Maxim Sobolev wrote: > > > That would be like trying to install FreeBSD 11

Re: Packaging the FreeBSD base system with pkg(8)

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

Re: Too low PTHREAD_STACK_MIN value?

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

posix_fallocate(2) && posix_fadvise(2) are somewhat broken

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

Re: posix_fallocate(2) && posix_fadvise(2) are somewhat broken

<kostik...@gmail.com> wrote: > On Tue, Dec 08, 2015 at 04:52:05PM +0100, Dag-Erling Sm??rgrav wrote: > > Maxim Sobolev <sobo...@freebsd.org> writes: > > > Hi, while working on some unrelated feature I've noticed that at least > > > those two system calls are n

Re: posix_fallocate(2) && posix_fadvise(2) are somewhat broken

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

Re: Depreciate and remove gbde

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

Panic in the udp_input() under heavy load

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

Re: Panic in the udp_input() under heavy load

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

Re: Panic in the udp_input() under heavy load

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

Re: Panic in the udp_input() under heavy load

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

Re: Weird issue with hastd(8)

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

Re: Weird issue with hastd(8)

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.patch

Weird issue with hastd(8)

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

Re: Weird issue with hastd(8)

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

Re: Weird issue with hastd(8)

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

Re: Randomization in hastd(8) synchronization thread

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

Randomization in hastd(8) synchronization thread

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

Making hastd working over WAN links (was: Randomization in hastd(8) synchronization thread)

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 synchronization

Randomization in hastd(8) synchronization thread

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

Bumping MAXCPU on amd64?

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

Re: Bumping MAXCPU on amd64?

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

Re: Making IFQ_MAXLEN tunable

Gary Jennejohn wrote: On Fri, 30 Apr 2010 13:23:13 -0700 Maxim Sobolev sobo...@sippysoft.com 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

Making IFQ_MAXLEN tunable

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

Re: Making IFQ_MAXLEN tunable

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

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

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

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

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 present sooner

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

Alexander Sack wrote: On Tue, Apr 27, 2010 at 5:25 PM, John Baldwin j...@freebsd.org 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

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

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

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

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

Re: Switchover to CAM ATA?

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

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

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

Re: Switchover to CAM ATA?

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

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

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 minute-long boot delays

SYSCTL_XXX(9) manual page deficiency

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

FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

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:

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

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

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

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

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

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 memory probing

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

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 memory probing

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

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 minutes from boot command

Re: newfs broken in -CURRENT after 204654

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

Bug in make release regarding install.cfg

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

Re: Annoucning DragonFly BSD!

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

disklabel is broken (GEOM related)

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:

Re: disklabel is broken (GEOM related)

[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 -r option and you will be ok. Thank you Poul for your very-very

Re: _fpathconf() and __semctl() prototypes

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

Re: IBM Thinkpad 600E

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 Thinkpad

Re: DP2 won't stay powered off

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 power on

Re: 5.0 showstopper

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

Re: perl5.6.1 wrapper

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

Re: URGENT: Over 700 ports missing perl dependencies

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

Re: X problem,Undefined symbol __sF

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; done $

`nroff -mandoc foo.X | less' is broken

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

Re: short uid/gid

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 APIs.

Re: short uid/gid

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 flag should be easier from the coding perspective

Re: short uid/gid

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

Re: tar problems with --fast-read

Committed, thank you very much! -Maxim On Wed, Oct 09, 2002 at 11:49:12AM +1000, Tim Robbins wrote: On Tue, Oct 08, 2002 at 10:01:09AM -0700, Gordon Tetlow wrote: I was trying out the fast-read feature of tar and got the following: gtetlow@roark:~$ touch testa testb gtetlow@roark:~$

  1   2   3   4   5   6   >