Re: Can't use gcc in a clang built world

[Andrew Turner]

On Thu, 27 Jun 2013 13:06:07 +0200
Dimitry Andric  wrote:

> On 2013-06-27 02:02, Kevin Day wrote:
> > Are you supposed to be able to use gcc to build userland binaries
> > if you built world with clang?
> >
> > I'm on -CURRENT as of a few days ago (using armv6 but i'm not sure
> > if that matters).
> 
> Yes, the arch matters a lot.  For arm, adding __clear_cache() to
> libgcc was explicitly disabled by Andrew here:
> 
> http://svnweb.freebsd.org/base?view=revision&revision=244382
> 
> "Don't provide clear_cache or the __sync_* functions on ARM with clang
> as they are provided by clang as builtin functions."
> 
> Maybe those functions should be in libgcc after all, if other programs
> depend on this.

The reason to disable __clear_cache is incorrect in r244382 as it is a
builtin in clang, but calls into an external copy of __clear_cache. The
reason __clear_cache was disabled was because of a bug in clang where
it is unable to compile a builtin function, however I only found this
out recently.

The issue with clang has been fixed, and, as of r251791 __clear_cache
is enabled in compiler-rt.

Andrew
> 
> -Dimitry
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscr...@freebsd.org"
> 
> 

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: Multiple page size support on FreeBSD?

[Andrew Duane]

Like all "performance" items (especially VM), it depends on the hardware and 
the load. On systems with small TLBs it helps more than with large TLBs. With 
software that needs access to lots of different areas the TLB gets more traffic 
so large ones help more. The answer for your firefox browser box with i386 is 
probably different from my compilation engine running MIPS, or his web server 
running AMD.

Back at Digital, we spent a lot of time trying to find the "one true answer" to 
superpages, only to discover there wasn't one. We ended up with a combination 
of automatic use from big allocations, a rarely used API to advise for big 
TLBs, and some background work that coalesced when possible.

 ....
Andrew L. Duane
Resident Architect - AT&T Technical Lead
m   +1 603.770.7088
o   +1 408.933.6944 (2-6944)
skype: andrewlduane
adu...@juniper.net



-Original Message-
From: owner-freebsd-hack...@freebsd.org 
[mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Alfred Perlstein
Sent: Wednesday, April 10, 2013 4:00 PM
To: Benjamin Kaduk
Cc: Wojciech Puchar; Sebastian Feld; freebsd-hackers@freebsd.org
Subject: Re: Multiple page size support on FreeBSD?

On 4/10/13 11:42 AM, Benjamin Kaduk wrote:
> On Wed, 10 Apr 2013, Wojciech Puchar wrote:
>
>>> How do your tests work?  Do you examine PTEs directly to check for 
>>> superpages or are you relying on the vm.pmap.pde sysctls?
>>
>> the later.
>>
>> anyway - algorithm described on list - that heuristics detects 
>> consecutive page access doesn't really help the urgent case - RANDOM 
>> access to large amount of memory.
>
> The algorithm is not a heuristic based on consecutive accesses, 
> promotion occurs when the entire superpage's worth of memory has 
> actually been accessed.  If I remember correctly, the performance gain 
> from superpages was only a few percent, so spending more time trying 
> to decide when to use them would make the algorithm a net wash.
>
> You should really watch the talk I linked to if you're interested, it 
> was quite interesting.
>
>> sequential access will get minimal improvement.
>>
>> IMHO the only way that really make sens is to add options to madvise 
>> to give kernel information about usage.
>
> Maybe.

It is cool that FreeBSD got this work via Alan Cox and the others that 
contributed.

I am wondering if it makes sense to have an explicit model.

At one place, for a platform with high performance but a very small TLB, we 
made it possible to explicitly request a large TLB for our process and it made 
a BIG difference for performance.

Sometimes being "general purpose" means that you can expose such low level 
things for the user to tune instead of requiring them to fit the app to a 
heuristic that may change.

-Alfred


>
> -Ben Kaduk
> ___
> freebsd-hackers@freebsd.org mailing list 
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscr...@freebsd.org"
>

___
freebsd-hackers@freebsd.org mailing list 
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Providing a default graphical environment on FreeBSD

[Andrew Young]

I spent years using Linux before I truly appreciated the key difference between 
a "desktop environment" and a "graphical environment". Probably because 
everyone had to have a desktop environment. 

I define graphical environment as simply X11 and a window manager. That's all 
you need to run Firefox, Gimp, etc. Because x11 is the underlying base, any 
toolkit (gtk, qt, whatever) will work just fine. A developer can pick the 
toolkit they're most comfortable with and it will work on anyone's system. 

In contrast, a "desktop environment" builds an entirely separate layer on top 
primarily to allow the desktop applications to communicate with one another. 
Things like network monitoring and message notifications are usually included. 
This is also where developers suddenly need to choose. Do you write code for 
KDE, Gnome, or another? Users will only run one desktop environment so choosing 
one will alienate the others. 

IMHO, a graphical environment is useful for running applications like Firefox 
and Gimp. I never run either of these on a server so I would never want to 
install even a graphical environment on my servers. 

I have no use at all for desktop environments. They're often bloated, buggy, 
and provide no real value to me. I would much rather install x11 and dwm. 

> this: a default, officially supported modern desktop environment is
> essential to FreeBSD.

I completely disagree. X11 + WM is more than adequate for my needs. And I don't 
need either of these on the servers whee I rely on FreeBSD. 

Andy

On Sep 17, 2012, at 1:53 PM, Zhihao Yuan  wrote:

>> From a programmer's point of view, GUI is a protocol, a graphical
> language. It's true. But users don't care. Users don't care how their
> graphical commands are being implemented.
> 
> Well, let's make it more straightforward. I hope people can agree with
> this: a default, officially supported modern desktop environment is
> essential to FreeBSD.
> 
> On Mon, Sep 17, 2012 at 12:06 PM, Mike Meyer  wrote:
>> On Mon, 17 Sep 2012 11:40:33 -0500
>> Zhihao Yuan  wrote:
>>> GUI is a concept. People can use WM or DE as their GUIs. X11 is not
>>> usable from a user's point of view, so it's out of the question. So
>>> far, your statement "Assume X11 _is_ the graphical environment" is
>>> already nonsense.
>> 
>> As someone who's used X without a WM or DE, I have to disagree. I
>> think PHK is dead on - X11 is a collection of protocols for working in
>> a bit mapped display + pointer (aka "graphical") environment. As
>> compared to a character-mapped display + keyboard (aka "command line")
>> environment.
>> 
>>> And then, a modern GUI should take care of Wifi, automount, and many
>>> things can't be done with a single WM.
>> 
>> You seem to be using GUI in a different manner than I'm used
>> to. Graphic User Interfaces don't *do* things, they provide a
>> graphical communications path (the Interface in GUI) between the user
>> and tools. Asking for a GUI that takes care of Wifi and automount and
>> other such things makes no more sense than asking for a mouse that
>> does those things. Those things are done by *tools*. You can have
>> tools with GUIs that do those things - a desktop manager, or a window
>> manager (and if you think a single WM can't do all those things, you
>> are looking at wimpy WMs), or a taskbar manager, or even a web-based
>> systems manager.
>> 
>> Until you two can agree on what the terms mean, you're going to be
>> talking past each other. But PHK seems to be using the common
>> definitions.
>> 
>> Or maybe you should start over, and describe the behavior of the
>> program you think FreeBSD should adopt, rather than trying to name it.
>> 
>>> --
>> Mike Meyer   http://www.mired.org/
>> Independent Software developer/SCM consultant, email for more information.
>> 
>> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
>> ___
>> freebsd-hackers@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
> 
> 
> 
> -- 
> Zhihao Yuan, nickname lichray
> The best way to predict the future is to invent it.
> ___
> 4BSD -- http://4bsd.biz/
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Question on io monitoring tools such as gstat and iostat

[Andrew Young]

Thanks Andrey!

Sent from my iPhone

On Aug 28, 2012, at 1:42 PM, Andrey Zonov  wrote:

> On 8/28/12 3:14 PM, Andy Young wrote:
>> I am relatively new to using IO monitoring tools and wanted to confirm I
>> understand them correctly. If I specify an interval of 5 seconds, my
>> assumption is that the data displayed is an average over that 5 second
>> interval. Is that correct or am I misunderstanding how intervals work?
>> 
> 
> Yes, you are right.  For more information you can read devstat(3) or
> sources in src/lib/libdevstat/devstat.c.
> 
> -- 
> Andrey Zonov
> 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: /proc filesystem

[Andrew Duane]

> -Original Message-
> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> hack...@freebsd.org] On Behalf Of Ian Lepore
> Sent: Thursday, July 12, 2012 6:42 PM
> To: Wojciech Puchar
> Cc: freebsd-hackers@freebsd.org
> Subject: Re: /proc filesystem
> 
> On Tue, 2012-06-19 at 06:47 +0200, Wojciech Puchar wrote:
> > that is what i need.
> >
> > but still need some explanation after using it and reading manual
> >
> > say:
> >PID  STARTEND PRT  RES PRES REF SHD  FL
> TP PATH
> >   1378   0x40   0x5ac000 r-x  385  415   2   1 CN- vn 
> > /usr/local/bin/Xorg
> >   1378   0x7ab000   0x7bc000 rw-   170   1   0 C-- vn 
> > /usr/local/bin/Xorg
> >   1378   0x7bc000   0x80 rw-   140   1   0 C-- df
> >   13780x8007ab0000x8007c3000 r-x   240  32   0 CN- vn 
> > /libexec/ld-elf.so.1
> >   13780x8007c30000x8007f rw-   430   1   0 C-- df
> >   13780x8007f0x8007f2000 rw-10   4   0 --- dv
> >   13780x8007f20000x8007f4000 rw-20   4   0 --- dv
> >   13780x8007f40000x800874000 rw-   110   4   0 --- dv
> >   13780x8008740000x800884000 rw-   160   4   0 --- dv
> >   13780x8008840000x800895000 rw-   100   1   0 CN- df
> >   13780x8009c20000x8009c5000 rw-30   1   0 C-- df
> >
> > 1) Xorg is mapped twice - IMHO first is text/rodata second is data. But
> > what "REF" really means here and why it is 2 once and 1 second.
> >
> > 2) what really PRES ("private resident") means? df (default) mappings are
> > IMHO anonymous maps==private data of process. so why RES is nonzero while
> > PRES is zero, while on shared code PRES is nonzero and large. what does it
> > really means?
> >
> > thanks.
> >
> 
> I'm catching up on threads I was following before I went on vacation,
> and it looks like there was never a response to this.  I'm interested in
> the answers to these questions too, so today I did some spelunking in
> the code to see what I could figure out.  I don't think I really
> understand things too well, but I'll just say what I think I found and
> hopefully the experts will correct anything I get wrong.
> 
> I think you're right about the first two mappings in that procstat
> output.  The REF value is the reference count on the vm object (the
> vnode for the exe file, I presume).  I think the reason the reference
> count is 2 is that one reference is the open file itself, and the other
> is the shadow object.  I've always been a bit confused about the concept
> of shadow objects in freebsd's vm, but I think it's somehow related to
> the running processes that are based on that executable vnode.  For
> example, if another copy of Xorg were running, I think REF would be 3,
> and SHD would be 2.
> 
> I don't know why there is no shadow object for the writable data mapping
> and why the refcount is only 1 for that.

BSS that doesn't exist in the file?

 ...
Andrew Duane
Juniper Networks
+1 978-589-0551 (o)
+1 603-770-7088 (m)
adu...@juniper.net

 



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: dtraceall.ko with old nfsclient

[Andrew Boyer]

On Jul 12, 2012, at 3:39 PM, Andriy Gapon wrote:

> on 12/07/2012 22:36 Fabian Keil said the following:
>> Andriy Gapon  wrote:
>> 
>>> on 12/07/2012 21:17 Fabian Keil said the following:
>>>> Benjamin Kaduk  wrote:
>>>> 
>>>>> On Wed, 11 Jul 2012, Fabian Keil wrote:
>>>>> 
>>>>>> I'm using the following modification of Sean's patch:
>>>> 
>>>> This way it seems to work as expected:
>>>> 
>>>> diff --git a/sys/modules/dtrace/dtraceall/Makefile 
>>>> b/sys/modules/dtrace/dtraceall/Makefile index 456efd1..628583b 100644
>>>> --- a/sys/modules/dtrace/dtraceall/Makefile +++ 
>>>> b/sys/modules/dtrace/dtraceall/Makefile @@ -1,7 +1,7 @@ # $FreeBSD: 
>>>> src/sys/modules/dtrace/dtraceall/Makefile,v 1.3 2011/04/09 09:07:31 uqs
>>>> Exp $
>>>> 
>>>> KMOD=  dtraceall -SRCS=  dtraceall.c opt_compat.h
>>>> +SRCS= dtraceall.c opt_compat.h opt_nfs.h
>>>> 
>>>> CFLAGS+=   -I${.CURDIR}/../../..
>>>> 
>>> 
>>> If you do cd sys/modules/dtrace/dtraceall && make [obj depend] all, does
>>> it compile OK with the above change?
>> 
>> Depends on your expectations I guess. As neither NFS-related option gets
>> defined, no dependency on either NFS module is registered. The compiler has
>> no complaints, though.
> 
> Interesting.  Could you repeat after sufficient cleaning up?
> I am not sure where from opt_nfs.h file could come.
> 

Maybe related: check out sys/modules/ipfw/Makefile.  It makes its own option 
headers for INET and INET6.

-A

--
Andrew Boyerabo...@averesystems.com




___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: distinguish between Maxmem, realmem, physmem

[Andrew Boyer]

On Jun 28, 2012, at 11:18 AM, Andrew Boyer wrote:
> It gets its info from the BIOS, which probed the SPD on each EEPROM at boot 
> time. 

Meant to say "SPD EEPROM on each DIMM."

-A

------
Andrew Boyerabo...@averesystems.com




___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: distinguish between Maxmem, realmem, physmem

[Andrew Boyer]

On Jun 28, 2012, at 10:46 AM, Steve Rikli wrote:

> On Thu, Jun 28, 2012 at 09:58:13AM -0400, John Baldwin wrote:
>> On Tuesday, June 26, 2012 3:41:10 pm Ping Chen wrote:
>>> 
>>> I am a bit confused with all these variables defined in
>>> freebsd(especially in freebsd 6.1): Which one of this represents the
>>> real memory of a system? Say we bought a system with 4G ram, which one
>>> tells me the RAM is 4G?
>>> 
>>> Accordign to source code:
>>> Maxmem ==> the highest page of phisycal address page  : if I understand
>>> correctly, this is the highest page number of physical memory that is
>>> usable?
>>> 
>>> realMem --> somehow get assigned by realmem = Maxmem:  this is confuing, if
>>> they are the same, why bother a realmem variables
>> 
>> I think realMem is legacy.
>> 
>>> physmem --> the number of usage pages : this seems the right one extract
>>> the memory info, however, it seems system allocate portion of memory to
>>> messge buffer which makes this physmem < 4G (assume RAM is 4G)
>> 
>> Correct.  Note that the firmware can also take up part of RAM as well (e.g.
>> to hold ACPI tables).
> 
> Given that, are the values for real & avail memory from 'dmesg' presented
> anywhere like sysctl?  E.g. one of my small servers has these from dmesg:
> 
> real memory  = 1073741824 (1024 MB)
> avail memory = 1023852544 (976 MB)
> 
> but the presumably equivalent sysctl values are different:
> 
> hw.realmem: 1065287680
> hw.physmem: 1047953408
> 
> For system hardware inventory purposes (I assume OP is asking for reasons
> along those lines, as am I) I'd want the value which reflects 1024MB of
> RAM in this case, understanding that it may not be precisely the amount
> available for system/user/etc. usage.
> 
> Is dmesg the (only?) place to get that number?
> 
> Cheers,
> sr.

Here I use hw.physmem and round up to the nearest 1GB.

You can also check the output of 'dmidecode -t 17' and total up the listed size 
of each DIMM.  It gets its info from the BIOS, which probed the SPD on each 
EEPROM at boot time.  dmidecode is in ports/sysutils/dmidecode.

Sometimes a flaky motherboard won't find all of the memory, so it's useful to 
make sure they match.

-Andrew

--
Andrew Boyerabo...@averesystems.com




___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Wide character types

[Andrew Turner]

I've been working on getting the ARM EABI working with FreeBSD.

As part of the EABI spec the Procedure Call Standard for the ARM
Architecture (AAPCS) defines wchar_t as either an unsigned int or an
unsigned short with the former as the preferred type. FreeBSD defines
wchar_t as a __wchar_t, which is defined as a __ct_rune_t, which is
defined as an int.

wint_t and rune_t are also defined in terms of __ct_rune_t. wint_t must
be a signed type as it needs to hols a WEOF which is defined as -1.

The type of rune_t appears to need to be the same as wint_t as the tow*
and isw* functions are defined as taking a wint_t by the documentation
but __ct_rune_t in the code and compare this value against __rune_t
values.

My question is am I correct in thinking rune_t and wint_t should be
defined as __ct_rune_t with __ct_rune_t defined as an int while wchar_t
should be defined as an unsigned int in ARM EABI and defined as an int
elsewhere?

Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: proper newfs options for SSD disk

[Andrew Duane]

> -Original Message-
> From: owner-freebsd-hack...@freebsd.org 
> [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Tim Kientzle
> Sent: Thursday, May 24, 2012 12:49 AM
> To: Warren Block
> Cc: freebsd-hackers@freebsd.org; Matthias Apitz
> Subject: Re: proper newfs options for SSD disk
> 
> GPart's alignment option doesn't work for MBR slices.
> It rounds to the requested alignment, and then rounds again
> to the track size, which defaults to 63 sectors.
> 
> I'm not convinced this is a bug in the design of MBR.  I don't
> think anything in the MBR design requires that partitions
> be track-aligned.
> 
> Tim

It really doesn't. This is old school thinking based around minimizing seek and 
rotation time on slow multiplatter HDDs. It also helped the redundant 
superblock layout scheme of UFS make that spiral striping down a set of disk 
platters. My bet is no one has ever bothered to rethink this in the 25 years 
since


...
Andrew Duane
Juniper Networks
+1 978-589-0551 (o)
+1 603-770-7088 (m)
adu...@juniper.net

 



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash

[Andrew Boyer]

On May 21, 2012, at 12:41 PM, Mark Felder wrote:

> OK guys I've been talking with another user who can recreate this crash and 
> the last bit of information we've learned seems to be leaning towards 
> interrupts/IRQ issues like someone (bz@ perhaps?) suggested.
> 
> I'm still trying to test this myself, but the other user was able to recreate 
> my crash pretty much on demand. The fix was to not use the first NIC in the 
> VM because it will always share an IRQ with mpt0. Once mpt0 is on its own the 
> crash does not seem to be reproducible anymore.
> 
> Before:
> 
> $ vmstat -i
> interrupt  total   rate
> irq1: atkbd0 378  0
> irq6: fdc0 9  0
> irq15: ata1   34  0
> irq16: em1687237  1
> irq18: em0 mpt0319094024539
> cpu0: timer236770821400
> Total  556552503940
> 
> After:
> 
> $ vmstat -i
> interrupt  total   rate
> irq1: atkbd0  38  0
> irq6: fdc0 9  0
> irq15: ata1   34  0
> irq16: em1  2811 15
> irq17: em2 5  0
> cpu0: timer71013398
> irq256: mpt0   12163 68
> Total  86073483
> 
> 
> Is there any other way we can make mpt0 get its own dedicated IRQ without 
> having to do this? The problem is that it causes us to have to make rc.conf 
> changes, pf.conf changes, and who knows what other software could be on these 
> machines that is trying to bind to a specific NIC...
> 
> 
> Thanks!
> 

You could try switching mpt to MSI.  MSI interrupts are never shared.  Add this 
to /boot/device.hints:

> hint.mpt.0.msi_enable="1"


-Andrew

--
Andrew Boyerabo...@averesystems.com




___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: GSoC Project: Automated Kernel Crash Reporting System - Discussion

[Andrew Duane]

I'm interested in the server side of this project, as it's something we've been 
working on here. We are developing an internal tool for our own crash reporting 
that does analysis of backtraces and provides a pretty accurate synopsis of 
what happened. I have a set of heuristics that can find various panic and trap 
issues across different CPU architectures, and walk up the trace to the real 
culprit. This includes, for example, that if memset traps the real problem was 
memset's caller, not memset itself.

We then use this information to be able to search for duplicate bug reports 
before opening new ones, and can help assign to the right team based on some 
lists of file and/or routine patterns. There is also a "hint" facility to 
extend the crash dump data collection for different kinds of crashes (e.g. 
memory exhaustion, lock issues, etc.)

 .......
Andrew Duane
Juniper Networks
+1 978-589-0551 (o)
+1 603-770-7088 (m)
adu...@juniper.net

 

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: How does loader(8) decide where to load the kernel?

[Andrew Turner]

On Mon, 7 May 2012 22:32:10 -0700
Tim Kientzle  wrote:

> 
> On May 7, 2012, at 6:57 AM, John Baldwin wrote:
> 
> > On Saturday, May 05, 2012 1:06:13 am Tim Kientzle wrote:
> >> I have ubldr loading the ELF kernel on BeagleBone and am now
> >> trying to untangle some of the hacks I used to get this working.
> >> 
> >> Unfortunately, there's one area of the common loader(8) code
> >> that I really don't understand:  How does
> >> sys/boot/common/load_elf.c determine the physical address at which
> >> to load the kernel?
> >> 
> >> __elfN(loadfile) has the following comment:
> >> 
> >> [The file] will be stored at (dest).
> >> 
> >> But that's not really true.  For starters, loadfile maps dest
> >> through archsw.arch_loadaddr.   (This mechanism seems
> >> to only be used on ia64 and pc98, though the result is
> >> later discarded on those platforms.)
> >> 
> >> Loadfile then passes the value to loadimage which does
> >> very strange things:
> >> 
> >> On i386, amd64, powerpc, and arm,  loadimage subtracts
> >> the dest value from the address declared in the actual ELF
> >> headers so that the kernel always gets loaded into low memory.
> >> (there's some intermediate bit-twiddling I'm glossing over, but
> >> this is the general idea).
> > 
> > The bit twiddling is supposed to be the equivalent of subtracting
> > KERNBASE from the load address.  On both i386 and amd64, there is
> > a direct mapping of the kernel text such that KERNBASE maps address
> > 0, etc.  By default on i386 KERNBASE is 0xc000.
> 
> Exactly my problem.  This all assumes that you're loading
> the kernel into low memory.
> 
> On the AM3358, the DRAM starts at 0x8000 
> on boot, so I'm trying to find a clean way to convince
> the loader's ELF code to put the kernel there.

I have a script at [1] that builds an image to load the kernel directly
from U-Boot. It figures out where to tell U-Boot to load a kernel by
using readelf to find the value of physaddr and kernbase to use to
calculate what physical addresses to use to load the kernel to and
where the first instruction to execute is.

Andrew

[1] http://fubar.geek.nz/files/freebsd/omap/build_beagle.sh
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Ways to promote FreeBSD?

[Andrew Young]

> On Fri, Apr 27, 2012 at 08:27:07PM +0200, Wojciech Puchar wrote:
> 
>>> After using Linux for almost 15 years, I only recently started using
>>> FreeBSD. I own an internet startup and was looking for a solution for
>> 
>> Those who need FreeBSD already use it. no need to promote. Or maybe need 
>> to promote bigger donations to FreeBSD community from big users.
>> 
>> Those who actually need high performers and have servers that are loaded 
>> and are working not toying around - use FreeBSD.
> 
> Not really true and kind of a poor attitude.
> Yes. many people needing high performance already use FreeBSD, but
> there are lots of services that could benefit from FreeBSD who are
> not very aware of it.  They may have heard the name, and even know
> that it is an OS, but have heard it passed off as a non-entity in
> the field and do not know better than that.   
> 
> Sure, if people take the time and come to the web site and then
> download and use it and learn it, they know and don't need to
> be told much.  But, most others are not yet in that situation.
> They might appreciate the help.   Of course, some may be too
> lazy or prejudiced to go through that, but many just need some
> more information and encouragement I would guess.
> 
> jerry  
> 

Information, encouragement and just more awareness would have helped me out a 
lot. I can't help but think that getting students involved earlier on would 
pave the way for more awareness and adoption later on. 

Andy

> 
>> 
>> ___
>> freebsd-hackers@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Ways to promote FreeBSD?

[Andrew Young]

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 4/27/12 10:16 AM, Andy Young wrote:
>> After using Linux for almost 15 years, I only recently started
>> using FreeBSD. I own an internet startup and was looking for a
>> solution for implementing large-scale storage servers. In my
>> research I found ZFS and subsequently found FreeBSD. As I learned
>> more about it, I was incredibly impressed. There are so many
>> elements of FreeBSD that I love, I've completely ditched Linux and
>> am deploying FreeBSD exclusively on my company's server
>> infrastructure. I can't help wonder why I hadn't heard all about it
>> before. Sure, I knew the name, but I had never seen it in use, 
>> either in college or in over ten years as a software developer
>> since then. In contrast Linux is everywhere! Even though there are
>> so many applications where FreeBSD seems to be a better or at least
>> more mature solution.
>> 
>> What are the current efforts to promote and educate people on
>> FreeBSD? I'd love to help spread the word.
>> 
> 
> Hi Andrew,
> 
> Your message caught my eye because of your company name in your
> signature.  I thought I had seen it somewhere before, and I had - I
> was at the VentureX competition at the abi when you won the grand prize!
> 
> I'm down the road in Hollis, NH, and I have been to a few of the
> Wednesday meetups at the abi.  I am a FreeBSD ports tree committer,
> and like you, I found it a number of years ago after getting so
> frustrated with the multitude of different Linux flavors.  I needed an
> OS that was packaged consistently, and the ports tree was a huge win
> for me.
> 
> After submitting a number of PRs over the years, I was invited to
> become a committer, and I have mentored other new committers since
> then.  If that is ever an interest to you, we should talk about it.
> 
> Anyway, I would be happy to meet with you to talk about FreeBSD in
> general, as well as advocacy, if you want.  I'm interested to learn
> more about how you are managing your infrastructure, too.  We
> currently making heavy use of jails and are also in the midst of a
> project implementing a Puppet-based server provisioning framework.
> 
> We could certainly give a short overview of FreeBSD in one of the
> meetups at the abi, and maybe there's even call for a user group, if
> there's enough interest in the area.
> 
> Cheers,
> Greg
> 

Wow! Talk about a small world. I'd love to meet up. I'll send you a direct 
email and maybe we can grab coffee or something next week. 

> - -- 
> Greg Larkin
> 
> http://www.FreeBSD.org/   - The Power To Serve
> http://www.sourcehosting.net/ - Ready. Set. Code.
> http://twitter.com/cpucycle/  - Follow you, follow me
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk+a79kACgkQ0sRouByUApCR+gCePd4rfkcdyq0OuOecxOAbRz6Q
> 5e4An15lkn9QRL6T9LvDgCMgYt4TATjp
> =B/1h
> -END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Ways to promote FreeBSD?

[Andrew Young]

> Andy Young  wrote:
>> After using Linux for almost 15 years, I only recently started using
>> FreeBSD. I own an internet startup and was looking for a solution for
>> implementing large-scale storage servers. In my research I found ZFS and
>> subsequently found FreeBSD. As I learned more about it, I was incredibly
>> impressed. There are so many elements of FreeBSD that I love,
> 
> Can you name a few?

Zfs, jails, and ip aliases are the first that come to mind. I also really like 
the defaults concept of the config file layout. 

> 
>> I've
>> completely ditched Linux and am deploying FreeBSD exclusively on my
>> company's server infrastructure.
> 
> It would be interesting to read about your infrastructure, the reasons
> why you found FreeBSD to be a better fit than what you used before,
> challenges during deployment and migration, any resulting
> performance/maintenance improvements, etc.
> 
> A short article or a blog post with the above maybe?
> 

Sounds like a good idea. 

>> I can't help wonder why I hadn't heard all
>> about it before. Sure, I knew the name, but I had never seen it in use,
>> either in college or in over ten years as a software developer since then.
>> In contrast Linux is everywhere! Even though there are so many applications
>> where FreeBSD seems to be a better or at least more mature solution.
>> 
>> What are the current efforts to promote and educate people on FreeBSD? I'd
>> love to help spread the word.
> 
> (Adding freebsd-advocacy@ to CC).
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

cron(8): openlog: ProgramName -> "cron"

[Andrew Pantyukhin]

Hello!

cron(8) is one of the rare services that puts something complicated in
ident (aka progname aka programname)  field of the syslog messages it
sends: /usr/sbin/cron[PID]. Would anyone be against changing it to
just "cron" to ease filtering with stock and third-party syslog
daemons, expecting no ":", "[", and "/" in the field?


Best,
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: mount_nfs does not like exports longer then 88 chars

[Andrew Duane]

MNAMELEN is used to bound the Mount NAMe LENgth, and is used in many many 
places. It may seem to work fine, but there are lots of utilities and such that 
will almost certainly fail managing it. Search the source code for MNAMELEN.

 ...
Andrew Duane
Juniper Networks
+1 978-589-0551 (o)
+1 603-770-7088 (m)
adu...@juniper.net

 


> -Original Message-
> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> hack...@freebsd.org] On Behalf Of Mark Saad
> Sent: Thursday, April 19, 2012 3:46 PM
> To: freebsd-hackers@freebsd.org
> Subject: mount_nfs does not like exports longer then 88 chars
> 
> Hello Hackers
>   I was wondering if anyone has come across this issue. This exists in
> FreeBSD 6, 7, and 9 , and probably in 8 but I am not using it at this time.
> When a nfs export path and host name total to more then 88 characters
> mount_nfs bombs out with the following error when it attempts to mount it.
> 
> mount_nfs: nyisilon2-13.grp2:/ifs/clients/www/csar884520456/files_cms- 
> stage-BK/imagefield_default_images:
> File name too long
> 
> I traced this down to a check in mount_nfs.c . This is about line 560
> in the 7-STABLE version  and  734 in the 9-STABLE version
> 
> 
> /*
>  * If there has been a trailing slash at mounttime it seems
>  * that some mountd implementations fail to remove the mount
>  * entries from their mountlist while unmounting.
>  */
> for (speclen = strlen(spec);
> speclen > 1 && spec[speclen - 1] == '/';
> speclen--)
> spec[speclen - 1] = '\0';
> if (strlen(hostp) + strlen(spec) + 1 > MNAMELEN) {
> warnx("%s:%s: %s", hostp, spec, strerror(ENAMETOOLONG));
> return (0);
> }
> 
> Does any one know why the check for hostp + spec +1 to be less then
> MNAMELEN is there for ?
> 
>  I removed the check on my 9-STABLE box and it mounts the long mounts fine
> 
> I submitted a pr for this its kern/167105
> http://www.freebsd.org/cgi/query-pr.cgi?pr=167105 as there is no
> mention of this in the man page and I cant find any reason for the check at 
> all.
> 
> 
> --
> mark saad | nones...@longcount.org
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-
> unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Rebooting/Halting system from kernel module

[Andrew Davis]

>do you want to sync the disks first? of just hard reset?

Why would anyone ever want to do that, you're a kernel mod, if you want to
do that just triple-fault.

On Sun, Jan 22, 2012 at 9:32 PM, Julian Elischer  wrote:

> On 1/22/12 2:19 AM, geoffrey levand wrote:
>
>> Hi,
>>
>> how would i reboot/halt the system from a kernel module ?
>>
>
> the answer is "that depends"..
>
> do you want to sync the disks first? of just hard reset?
>
>
>
> __**_
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@**
> freebsd.org "
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: mfi (Dell H700) + hot swapping doesn't appear to work with RC1

[Andrew Boyer]

On Dec 16, 2011, at 12:47 AM, Jan Mikkelsen wrote:
> On 16/12/2011, at 3:40 AM, Andrew Boyer wrote:
>> On Dec 15, 2011, at 4:19 AM, Jan Mikkelsen wrote:
>> 
>>> For the mfi controllers I have been testing recently (MegaRAID 9261-8i), 
>>> you need to install the sysutils/megacli port, and use that to clear the 
>>> "foreignness" of the disk you just added. Something like:
>>> 
>>> MegaCli -CfgForeign -Clear -a0
>> 
>> I don't think that's what you want.  You want to use -Import, not -Clear, to 
>> keep your data intact.
> 
> OK. When I did a -Clear and recreated the drive as a single disk raid0 
> volume, the data was still there, but I wanted it to go away.

The RAID identity is stored on a 512MB partition at the end of the disk.  
Clearing and recreating it doesn't actually affect your data, as you 
discovered.  You can even plug one of your RAID0 disks into a non-RAID 
controller and your data will be there.

mfiutil has a 'drive clear' feature to zero disks.  Or you could just dd a few 
megs of zeroes to the beginning of the disk.

> 
>> I recommend you always run with this configuration:
>> 
>> # MegaCli -AdpSetProp AutoEnhancedImportEnbl -aALL
>> # MegaCli -AdpSetProp MaintainPdFailHistoryEnbl -0 -aALL
>> 
>> AutoEnhancedImportEnbl will bring the foreign disk back in on a reboot.  LSI 
>> recommends turning off MaintainPdFailHistory when using single-disk RAID0 
>> configurations.
> 
> What does PD Fail History actually do?

See: http://kb.lsi.com/KnowledgebaseArticle16570.aspx

-Andrew

--
Andrew Boyerabo...@averesystems.com




___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: mfi (Dell H700) + hot swapping doesn't appear to work with RC1

[Andrew Boyer]

On Dec 15, 2011, at 1:10 PM, Hugo Silva wrote:

> On 12/15/11 16:40, Andrew Boyer wrote:
>> I'm not sure it would even be possible to come up with a worse interface.  
>> It boggles the mind.
>> 
>> I recommend you always run with this configuration:
>> 
>> # MegaCli -AdpSetProp AutoEnhancedImportEnbl -aALL
>> # MegaCli -AdpSetProp MaintainPdFailHistoryEnbl -0 -aALL
>> 
>> AutoEnhancedImportEnbl will bring the foreign disk back in on a reboot.  LSI 
>> recommends turning off MaintainPdFailHistory when using single-disk RAID0 
>> configurations.
>> 
> 
> Any gotchas with this enabled? I'm thinking putting in a disk from
> another card, which is part of a raid, in this server, for instance.
> 

My understanding is that it only imports a foreign configuration if it's 
complete - but I've never tested it.

>> To bring in a foreign disk without rebooting:
>> 
>> # MegaCli -CfgForeign -Scan -aALL
>> # MegaCli -CfgForeign -Import [x] -aN (where x is the config number listed 
>> in the scan, and N is the adapter number)
>> 
>> Adding these capabilities to mfiutil is on my list of things to do, but it's 
>> not ready yet.
>> 
>> Has anyone managed to get the real JBOD mode working on this controller?  It 
>> advertises support in the firmware but doesn't seem to do anything.  The 
>> documentation only lists JBOD mode as a feature of the lower-end controllers.
>> 
>> Hope this helps.
>> 
>> -Andrew
> 
> It does help - thanks! For the same disk being removed and then
> reinserted, the provided commands brought the disk/volume back to
> mfiutil show drives/volumes output, and after a zpool clear, ZFS has no
> complains.
> 
> 
> For recovery from a software-induced fail (mfiutil fail eX:sX), I
> couldn't perform a recovery using just mfiutil. MegaCli -PDOnline
> -PhysDrv[eX:sX] -aN did it, in that case.
> 
> For the still-untested case of an altogether new disk being inserted, I
> guess mfiutil create jbod N would do the trick.
> 
> 
> BTW, the mfiutil is coredumping when provided with inexistant disks
> (just noticed)


Can you provide the exact command that produces a core?

-Andrew

--
Andrew Boyerabo...@averesystems.com




___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: mfi (Dell H700) + hot swapping doesn't appear to work with RC1

[Andrew Boyer]

On Dec 15, 2011, at 4:19 AM, Jan Mikkelsen wrote:

> For the mfi controllers I have been testing recently (MegaRAID 9261-8i), you 
> need to install the sysutils/megacli port, and use that to clear the 
> "foreignness" of the disk you just added. Something like:
> 
>   MegaCli -CfgForeign -Clear -a0

I don't think that's what you want.  You want to use -Import, not -Clear, to 
keep your data intact.

On Dec 15, 2011, at 11:03 AM, Hugo Silva wrote:

> On 12/15/11 15:28, Hugo Silva wrote:
>> As Borja said, part of the difficulty is the H700 abstracting a single
>> disk as a RAID-0, I guess. So far I've been unable to find a way to
>> bring the drive back, except by rebooting and recreating.
> 
> Turns out no interaction is needed after reboot. It was something else
> unrelated. The main issue then is convincing the controller to once
> again accept the hard disk. I'm going through MegaCli "documentation"
> (ie --help).. it's not a pretty place.

I'm not sure it would even be possible to come up with a worse interface.  It 
boggles the mind.

I recommend you always run with this configuration:

# MegaCli -AdpSetProp AutoEnhancedImportEnbl -aALL
# MegaCli -AdpSetProp MaintainPdFailHistoryEnbl -0 -aALL

AutoEnhancedImportEnbl will bring the foreign disk back in on a reboot.  LSI 
recommends turning off MaintainPdFailHistory when using single-disk RAID0 
configurations.

To bring in a foreign disk without rebooting:

# MegaCli -CfgForeign -Scan -aALL
# MegaCli -CfgForeign -Import [x] -aN (where x is the config number listed in 
the scan, and N is the adapter number)

Adding these capabilities to mfiutil is on my list of things to do, but it's 
not ready yet.

Has anyone managed to get the real JBOD mode working on this controller?  It 
advertises support in the firmware but doesn't seem to do anything.  The 
documentation only lists JBOD mode as a feature of the lower-end controllers.

Hope this helps.

-Andrew

--
Andrew Boyerabo...@averesystems.com




___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: BUG: 'glabel label' name's lenght, is truncated without err/warn

[Andrew Duane]

Checking the return code of strlcpy won't say if the entire string fit 
(exactly) correctly, or if it was truncated. I think explicitly checking the 
length of label first is cleaner and more correct. 

I would, however, replace "15" with "sizeof(md.md_label) - 1" both in the check 
and the printf.

 .......
Andrew Duane
Juniper Networks
o   +1 978 589 0551
m  +1 603-770-7088
adu...@juniper.net

 


> -Original Message-
> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> hack...@freebsd.org] On Behalf Of Ed Schouten
> Sent: Tuesday, November 08, 2011 6:34 AM
> To: Lucas Holt
> Cc: rank1see...@gmail.com; hack...@freebsd.org
> Subject: Re: BUG: 'glabel label' name's lenght, is truncated without
> err/warn
> 
> * Lucas Holt , 2005 15:24:
> > --- src/sbin/geom/class/label/geom_label.c  2008/11/21 21:05:31
>   1.3
> > +++ src/sbin/geom/class/label/geom_label.c  2011/11/05 14:15:23
>   1.4
> > @@ -118,6 +118,12 @@ label_label(struct gctl_req *req)
> > return;
> > }
> >
> > +   label = gctl_get_ascii(req, "arg0");
> > +   if (strlen(label) > 15) {
> > +   gctl_error(req, "Label cannot exceed 15 characters");
> > +   return;
> > +   }
> > +
> > /*
> >  * Clear last sector first to spoil all components if device
> exists.
> >  */
> > @@ -131,7 +137,6 @@ label_label(struct gctl_req *req)
> >
> > strlcpy(md.md_magic, G_LABEL_MAGIC, sizeof(md.md_magic));
> > md.md_version = G_LABEL_VERSION;
> > -   label = gctl_get_ascii(req, "arg0");
> > strlcpy(md.md_label, label, sizeof(md.md_label));
> > md.md_provsize = g_get_mediasize(name);
> > if (md.md_provsize == 0) {
> 
> Why not simply perform the strlcpy and check whether
> 
>   if (strlcpy(...) >= sizeof(md.md_label)
> 
> ?
> 
> --
>  Ed Schouten 
>  WWW: http://80386.nl/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: Hello World assembly language

[Andrew Duane]

Add a 0x0d to the end of the string (0xa = LF, 0xd = CR)

 ...
Andrew Duane
Juniper Networks
o   +1 978 589 0551
m  +1 603-770-7088
adu...@juniper.net

 

> -Original Message-
> From: owner-freebsd-hack...@freebsd.org [mailto:owner-freebsd-
> hack...@freebsd.org] On Behalf Of Colin Barnabas
> Sent: Wednesday, September 28, 2011 1:27 PM
> To: freebsd-hackers@freebsd.org
> Subject: Hello World assembly language
> 
> I found a hello world program written in assembly language which
> runs on my amd64 8.2 stable box. However, I can not seem to get
> it to print a new line. Any suggestions on how to print a line
> feed in assembly?
> 
> Here is the code-
> 
> section .data
> 
> message:
> db  'hello, world!', 0x0a
> 
> section .text
> 
> global _start
> _start:
> mov rax, 4
> mov rdi, 1
> mov rsi, message
> mov rdx, 13
> syscall
> 
> mov rax, 1
> xor rdi, rdi
> syscall
> 
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-
> unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: Soliciting opinions on an extension of the bootinfo structure

[Andrew Duane]

Since this has turned out to be a more contentious idea than I thought, and the 
upcoming FDT work will probably remove the need for it at all, I'm withdrawing 
the idea. Although our current code uses such a platform extension structure, 
we can make do with either metadata or environment variables for the time being.

 ...
Andrew Duane
Juniper Networks
o   +1 978 589 0551
m  +1 603-770-7088
adu...@juniper.net

 


-Original Message-
From: John Baldwin [mailto:j...@freebsd.org] 
Sent: Friday, September 09, 2011 8:32 AM
To: freebsd-a...@freebsd.org
Cc: Peter Wemm; Peter Grehan; freebsd-hackers@freebsd.org; Andrew Duane
Subject: Re: Soliciting opinions on an extension of the bootinfo structure

On Thursday, September 08, 2011 6:48:19 pm Peter Wemm wrote:
> On Thu, Sep 8, 2011 at 3:25 PM, Peter Grehan  wrote:
> >> I'm proposing an extension framework for the bootinfo structure used
> >> to pass information from the bootstrap/loader to the kernel. Although
> >> I'm only proposing this for the MIPS bootinfo, it's completely
> >> applicable to any of them.
> >>
> >> What I propose is adding an optional platform extension structure:
> >> bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT
> >
> >  Any reason not to put the vendor bits into another piece of loader 
metadata
> > ? That seems the extensible way to add additional info from the loader,
> > rather than extending bootinfo (as was the case pre-loader days).
> >
> > later,
> 
> It sounds like they're not using loader, which is probably a
> reasonable thing for their environment.

That doesn't stop you from adding metadata to the kernel.  It is just an array 
of variable length blobs appended after 'end'.  Any boot loader can support
adding metadata.

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: Soliciting opinions on an extension of the bootinfo structure

[Andrew Duane]

That's correct. This is actually part of a larger effort to open up the MIPS 
code to a range of new bootstraps. Some bootstraps use the bootinfo facility 
extensively. It's an easy way to pass some simple information to the kernel 
without the clutter of metadata and other such things.

 .......
Andrew Duane
Juniper Networks
o   +1 978 589 0551
m  +1 603-770-7088
adu...@juniper.net

 

-Original Message-
From: Peter Wemm [mailto:pe...@wemm.org] 
Sent: Thursday, September 08, 2011 6:48 PM
To: Peter Grehan
Cc: Andrew Duane; freebsd-hackers@freebsd.org; freebsd-a...@freebsd.org
Subject: Re: Soliciting opinions on an extension of the bootinfo structure

On Thu, Sep 8, 2011 at 3:25 PM, Peter Grehan  wrote:
>> I'm proposing an extension framework for the bootinfo structure used
>> to pass information from the bootstrap/loader to the kernel. Although
>> I'm only proposing this for the MIPS bootinfo, it's completely
>> applicable to any of them.
>>
>> What I propose is adding an optional platform extension structure:
>> bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT
>
>  Any reason not to put the vendor bits into another piece of loader metadata
> ? That seems the extensible way to add additional info from the loader,
> rather than extending bootinfo (as was the case pre-loader days).
>
> later,

It sounds like they're not using loader, which is probably a
reasonable thing for their environment.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Soliciting opinions on an extension of the bootinfo structure

[Andrew Duane]

I'm proposing an extension framework for the bootinfo structure used to pass 
information from the bootstrap/loader to the kernel. Although I'm only 
proposing this for the MIPS bootinfo, it's completely applicable to any of them.

What I propose is adding an optional platform extension structure: 
bootinfo_pext, surrounded by #ifdef BOOTINFO_PEXT

struct bootinfo {

u_int32_t   bi_kernend; /* end of kernel space */
u_int32_t   bi_envp;/* environment */
u_int32_t   bi_modulep; /* preloaded modules */
+#ifdef BOOTINFO_PEXT
+   struct bootinfo_pextbi_pext;/* platform extensions if 
defined */
+#endif
 };

Then, any vendor, platform, architecture, family, or developer could define a 
new header file (or expand an existing one) with a definition of struct 
bootinfo_pext, and a #define BOOTINFO_PEXT. Include the new (or existing) 
header file in your source, and you have whatever extensions you want, without 
affecting other platforms, architectures, families, or developers. The file 
we're looking to add is sys/mips/cavium/bootinfo_octeon.h:

+/*
+ * Platform bootinfo extensions for OCTEON bootinfo structure
+ *
+ * Specific vendors can add their own bootinfo_pext structures
+ * surrounded by #ifdef OCTEON_VENDOR_XXX
+ */
+
+#include "opt_cvmx.h"  /* For OCTEON_VENDOR_XXX definitions */
+
+#ifdef OCTEON_VENDOR_JUNIPER
+#define BOOTINFO_PEXT  /* include bootinfo_pext in main structure */
+#define BOOTINFO_PEXT_MAGIC0xCADECADE
+#define BOOTINFO_PEXT_VERSION  1
+
+struct bootinfo_pext {
+int pext_i2cid;
+u_int32_t   pext_flags;
+u_int32_t   pext_magic; /* Magic number for octeon 
pext */
+u_int32_t   pext_version;   /* Version of pext */
+u_int16_t   pext_uboot_major_rev;
+u_int16_t   pext_uboot_minor_rev;
+u_int16_t   pext_loader_major_rev;
+u_int16_t   pext_loader_minor_rev;
+};
+#endif /* OCTEON_VENDOR_JUNIPER */


Reasonable? Unreasonable? Insane?

--
Andrew Duane Juniper Networks
978-589-0551  10 Technology Park Dr
adu...@juniper.net  Westford, MA  01886-3418
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Dumping core over NFS

[Andrew Duane]

We have a strange problem in 6.2 that we're wondering if anyone else has seen. 
If a process is dumping core to an NFS-mounted directory, sending SIGINT, 
SIGTERM, or SIGKILL to that process causes NFS to wedge. The nfs_asyncio starts 
complaining that 20 iods are already processing the mount, but nothing makes 
any forward progress.

Sending SIGUSR1, SIGUSR2, or SIGABRT seem to work fine, as does any signal if 
the core dump is going to a local filesystem.

Before I dig into this apparent deadlock, just wondering if it's been seen 
before.

 .......

Andrew Duane
Juniper Networks
o   +1 978 589 0551
m  +1 603-770-7088
adu...@juniper.net





___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: DEBUG - analysing core dumps

[Andrew Duane]

Damien Fleuriot wrote:
> Hello list,
> 
> 
> 
> We've got these boxes at work running FreeBSD 8.1-STABLE amd64 and
> serving as firewalls and openvpn gateways.
> 
> We use CARP interfaces to provide an active-passive fault tolerant
> system. 
> 
> 
> Today, we received a nagios alert from the master box saying it's
> rsyslogd process had crashed.
> 
> I logged on to it and tried to relaunch it, to no avail:
> pid 2303 (rsyslogd), uid 0: exited on signal 11 (core dumped)
> 
> 
> 
> 
> I would like advice on how to debug the output from the core dump.
> 
> This is what I get from gdb:
> 
> # gdb
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are welcome to change it and/or distribute copies of it under
> certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details. This GDB was configured as "amd64-marcel-freebsd".
> (gdb) core rsyslogd.core
> Core was generated by `rsyslogd'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x004258ec in ?? ()
> 
> 
> Sadly, getting a backtrace with "bt" gives me more lines with "??",
> which is totally not helpful:
> [SNIP]
> #13 0x7f1f9d70 in ?? ()
> #14 0x in ?? ()
> #15 0x6f70732f7261762f in ?? ()
> #16 0x6c737973722f6c6f in ?? ()
> #17 0x5f6e70766f2f676f in ?? ()
> #18 0x746174732e676f6c in ?? ()
> #19 0x0065 in ?? ()
> #20 0x in ?? ()
> [SNIP]
> 
> I am not sure what steps I should follow to get more information ?
> 
> 
> 
> Also, I believe that often, core dumps with signal 11 = RAM problems
> and I would like a confirmation here.
> 
> I am concerned because rsyslogd is the only process that crashes in
> this way, even after I rebooted the firewall.
> 
> Thanks for your input :)

For what it's worth, the addresses shown in frames 15, 16, 17, and 18 are ASCII:

ops/rav/
lsysr/lo
_npvo/go
tats.gol

/Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: device_detach() on a device used by ixgbe driver (FreeBSD 7-STABLE through to 9-CURRENT)

[Andrew Boyer]

On May 23, 2011, at 10:32 AM, John Baldwin wrote:

> On Monday, May 23, 2011 10:13:41 am Philip Soeberg wrote:
>> I would also expect the ixgbe.c driver to do a quick resource_disabled() 
>> in it's attach() function, so that we can disable specific adapters 
>> through kenv hint.ix.0.disabled=1..
> 
> That is not universally supported (i.e. it's not a part of new-bus 
> specifically).  For buses that support hinted devices, they do all generally 
> support being able to disable a hinted device, but disabling bus-enumerated 
> devices is not generally supported.
> 

FYI, I submitted a patch to Jack to add this in all of the e1000/ixgbe drivers. 
 Setting a disabled="1" hint causes the attach to fail with ENXIO.  I don't 
know if it's 'correct' or not but it serves a purpose in our testing and I 
thought it would be useful for others.

-Andrew

--
Andrew Boyerabo...@averesystems.com




___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Fwd: Re: scd and mcd

[Andrew Lankford]

My last desktop machine had an ASUS Pentium-3 (no ISA slots), USB1 
only.  It has outlived the original hard drive, CDROM, and power supply, 
but I think it makes more sense these days to throw these systems out 
rather than "future-proof" them, especially if a fanless SoC could be 
less power-hungry and noisy.   It seems to me that people who want to 
get more life out 10yr old hardware need to be part of some sort of 
trimmed down "LegacyBSD" project that caters to their special needs.  
You all know more than I do about the orgs that are following the 
stable-6 or stable-7 branches, but are they using  ancient CDROMS with a 
limited life span?


 Original Message 
From:   - Sat Apr 23 19:53:48 2011
X-Account-Key:  account2
X-UIDL: 
X-Mozilla-Status:   0011
X-Mozilla-Status2:  
X-Mozilla-Keys: 
Return-Path:
Received: 	from imp04 ([10.20.200.4]) by mta52.charter.net (InterMail 
vM.7.09.02.04 201-2219-117-106-20090629) with ESMTP id 
<20110423234226.QAAM13475.mta52.charter.net@imp04> for 
; Sat, 23 Apr 2011 19:42:26 -0400
Received: 	from harmony.bsdimp.com ([199.45.160.85]) by imp04 with 
charter.net id bBiR1g01x1qqkgf04BiSRj; Sat, 23 Apr 2011 19:42:26 -0400

X-Chzlrs:   ??
X-Authority-Analysis: 	v=1.1 
cv=ACdvlZsxPtp6/8rt9ATxQxe5eelQ5vQqaf1LwcbVAy0= c=1 sm=1 
a=Ucbx8mQ_rlYA:10 a=MV1VDysopeJvYeH43xkbGw==:17 a=GKysJfYJ:8 
a=7Qk2ozbK:8 a=VHkpZ49OhpeKkUvcBWkA:9 a=ABrYPtnIPbQqMp5bbigA:7 
a=CjuIK1q_8ugA:10 a=cvZW9r6VXHAA:10 a=aNaW_GFDrTlh0hGR9xgA:9 
a=P0Ne2a3NTbHX3BCDdCkA:7 a=MV1VDysopeJvYeH43xkbGw==:117
Received: 	from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) 
(authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP 
id p3NNbvwt006040 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA 
bits=128 verify=NO); Sat, 23 Apr 2011 17:37:59 -0600 (MDT) 
(envelope-from i...@bsdimp.com)

Subject:Re: scd and mcd
Mime-Version:   1.0 (Apple Message framework v1084)
Content-Type:   multipart/alternative; boundary=Apple-Mail-4-1024646444
From:   Warner Losh 
In-Reply-To:<4db35e8a.r5ldmfg8cygirbff%per...@pluto.rain.com>
Date:   Sat, 23 Apr 2011 17:37:57 -0600
Cc: hack...@freebsd.org, lankfordand...@charter.net
Message-Id: 
References: 	<4db3142a.4000...@charter.net> 
<1e3f5b85-5a1a-4118-a9d8-932f46619...@bsdimp.com> 
<4db35e8a.r5ldmfg8cygirbff%per...@pluto.rain.com>

To: per...@pluto.rain.com
X-Mailer:   Apple Mail (2.1084)
X-Greylist: 	Sender succeeded SMTP AUTH, not delayed by 
milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 23 Apr 2011 
17:37:59 -0600 (MDT)




On Apr 23, 2011, at 5:19 PM, per...@pluto.rain.com wrote:


 Warner Losh  wrote:


 mcd and scd are ISA-only devices ... They were important for the
 386 (now not supported) and 486 machines.  Since the 486 machines
 in question maxed out at 32MB, and 8.x has trouble running in 32MB
 on x86, I'm guessing there aren't too many 486 SX/DX machines
 running 8.x.


 486 were the last for which ISA was the primary bus, but ISA was
 still present (bridged from PCI) on most Pentium systems and common
 at least as recently as Pentium-II.  (I don't have a disassembled
 P-III handy to check whether it has an ISA slot.)


Most Pentium II and newer systems had IDE connectors on the motherboard.  Many 
of the Pentium I ones did too.  Only if you didn't have IDE connectors on mobo 
would you be likely to consider one of these CD's.  Also, I think they topped 
out at 4x or 8x speed since they had a custom interface.

Warner



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

scd and mcd

[Andrew Lankford]

While we're talking about recent MFC's for SATA hardware (works for me, 
but I still need the old ata drivers for my cdrom), is anyone out there 
really still using the mcd (fbsd 1.0 vintage) and scd (2.0.5) drivers?

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: retry mounting with ro when rw fails

[Andrew Duane]

For SCSI-attached disks, yes. But other hardware has write-protect sensing (SD 
cards, CD-roms, our platform). So if you can do that, you should

Cleaning up after a failed write is a real problem, one that I needed to avoid. 


/Andrew
 

-Original Message-
From: Andriy Gapon [mailto:a...@freebsd.org] 
Sent: Friday, April 08, 2011 11:23 AM
To: Andrew Duane
Cc: Bruce Evans; freebsd...@freebsd.org; FreeBSD Hackers; 
freebsd-s...@freebsd.org
Subject: Re: retry mounting with ro when rw fails

on 08/04/2011 15:36 Andrew Duane said the following:
> What I was hoping to do was design a better mechanism for passing that R/O
> detection from the device to the filesystem code. Our implementation uses a
> platform sysctl that checks the incoming device name against some hardware or
> software settings. Ick. I don't know enough about device/GEOM calls to do it
> better though.

I am actually not aware of any way to inquiry write-protection status from
hardware.  There are distinct SCSI sense codes for that, but you get them only
after a failed write attempt.

But there are many things that I don't know about...

-- 
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: retry mounting with ro when rw fails

[Andrew Duane]

I had been letting this discussion settle a little bit before jumping in, but 
we've done some work in this area for a few of our platforms. The work was 
rather ham-fisted, but I've been looking for a way to try to get it cleaned up 
and back to FreeBSD.

Basically, we have a way of detecting that our disk is physically 
write-protected, a pretty common scenario. Given that, I made some surgical 
changes to the mount path to prevent read-write mounts of the disk at all. You 
can't allow that, because even attempts to update the superblock or timestamp 
will fail and leave buffers outstanding. Over time, this eventually panics the 
system. My implementation simply drops the read-write flag and mounts the FS 
readonly, rather than return a failure (which stopped the startup RC scripts).

What I was hoping to do was design a better mechanism for passing that R/O 
detection from the device to the filesystem code. Our implementation uses a 
platform sysctl that checks the incoming device name against some hardware or 
software settings. Ick. I don't know enough about device/GEOM calls to do it 
better though.

 ...
Andrew Duane
Juniper Networks
o   +1 978 589 0551
m  +1 603-770-7088
adu...@juniper.net

 


-Original Message-
From: owner-freebsd-hack...@freebsd.org 
[mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Bruce Evans
Sent: Friday, April 08, 2011 8:20 AM
To: Andriy Gapon
Cc: Garrett Cooper; freebsd...@freebsd.org; Jeremy Chadwick; FreeBSD Hackers
Subject: Re: retry mounting with ro when rw fails

On Fri, 8 Apr 2011, Andriy Gapon wrote:

> on 08/04/2011 03:00 Jeremy Chadwick said the following:
>> On Thu, Apr 07, 2011 at 01:20:53PM -0700, Garrett Cooper wrote:
>>> As a generic question / observation, maybe we should just
>>> implement 'errors=remount-ro' (or a reasonable facsimile) like Linux
>>> has in our mount(8) command? Doesn't look like NetBSD, OpenBSD, or
>>> [Open]Solaris sported similar functionality.
>>
>> I was going to recommend exactly this.  :-)
>>
>> I like the idea of Andriy's patch, but would feel more comfortable if it
>> were only used if a mount option was specified (-o errors=remount-ro").
>
> Having the option is appealing, but my main motivation was the simplicity that
> comes from having that enabled by default.
> That is, you absolutely want an R/W mount then use -o rw, you need R/O then
> explicitly -o ro, you "just want" to get that media mounted then the default
> behavior tries its best.

But the default behaviour is backwards, especially for read-mostly
removable media.  The default should be ro, possibly with an automagic
upgrade to rw iff the media really needs to be written too.  Writing
timestamps for file system and inode access times doesn't count as
"really needs to be written to".

I think I prefer requiring an explicit upgrade to rw.  rw implies
writing access times unless you also use noatime, and I wouldn't want
noatime to be set automagically depending on whether rw is set explicitly,
so I would want noatime to be set explicitly, and once you do that
then you can easily set rw or ro at the same time.  A new rm (read mostly)
or "rwa" (read or write automagically) flag could give automatic upgrade
from ro to rw.  I'd also like automatic downgrade to ro after a file
system has not been written to for some time (this would avoid fscks
in most cases for read-mostly file systems.  The ro flag should be
per-cylinder-group in ffs so that on big disks, most parts are read-only
most of the time and don't need to be checked).

Bruce
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: looking for error codes

[Andrew Duane]

My work around read-only systems extended this, to allow a general FreeBSD 
system to come up with "main media" write locked. In the RC files, MFS 
partitions were made for /tmp, /var, and other places we needed to write. Now 
that we're upgrading to a later BSD, I hope to refit these with union 
filesystems instead, to save space and complexity.

--
Andrew Duane Juniper Networks
978-589-0551  10 Technology Park Dr
adu...@juniper.net  Westford, MA  01886-3418


From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] On 
Behalf Of Warner Losh [i...@bsdimp.com]
Sent: Saturday, April 02, 2011 11:54 AM
To: per...@pluto.rain.com
Cc: freebsd-hackers@freebsd.org; m.e.sanlit...@gmail.com; a...@freebsd.org; 
freebsd-a...@freebsd.org
Subject: Re: looking for error codes

On Apr 2, 2011, at 1:50 AM, per...@pluto.rain.com wrote:
>
>> With respect to my knowledge , no one of the operating systems
>> has a facility to separate read-only and modifiable parts ...
>
> SunOS 4 had a partial solution to this, by rearranging the FS layout
> so that /usr could be mounted read-only (and often, from a server --
> IIRC a single /usr could be shared among multiple diskless clients).
> They used quite a few symlinks so that things could be found in
> their accustomed places although actually located elsewhere.  The
> scheme was fairly well described in the SunOS 4 manual set; granted
> _finding_ a SunOS 4 manual set these days may be a challenge :)

FreeBSD can do this too.  In fact, NanoBSD relies heavily on having most of the 
system mounted read-only, and has MFS partitions for /etc and /var.

Warner


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: looking for error codes

[Andrew Duane]

My work is absolutely NOT in any shape at all to even consider, it's a really 
tailored point solution to a specific platform issue. I've been working with 
another engineer to expand it and make it more generic, but that effort is 
stalled at the moment.

My plan was to add something like an ioctl to a device that would query it for 
read/write status, and percolate that up through the geom layer to capture it 
for mount requests. The correct place to stop it is at mount time. Even 
mounting a read-only device as read-write will eventually panic the system as 
super-block flag updates will not be able to complete. Once that is done, any 
attempt to open a file for writing fails.

--
Andrew Duane Juniper Networks
978-589-0551  10 Technology Park Dr
adu...@juniper.net  Westford, MA  01886-3418


From: Andriy Gapon [a...@freebsd.org]
Sent: Friday, April 01, 2011 11:18 AM
To: Andrew Duane
Cc: Warner Losh; FreeBSD Hackers; FreeBSD Arch
Subject: Re: looking for error codes

on 01/04/2011 18:04 Andrew Duane said the following:
> AFAIK, FreeBSD does not really detect read-only media. This was something I 
> had to add as a small project here at work, and was considering cleaning up 
> to try to get into CURRENT. If there's a real need for it, I could speed that 
> up.
>

Yes, that's exactly the problem that I am looking at.
So if you have anything to share it will be greatly appreciated at least by me.
But I think many more people could benefit from it (e.g. those having 
SD/SDHC/etc
cards).
Thanks!

> 
> From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] 
> On Behalf Of Warner Losh [i...@bsdimp.com]
> Sent: Friday, April 01, 2011 10:51 AM
> To: Andriy Gapon
> Cc: FreeBSD Hackers; FreeBSD Arch
> Subject: Re: looking for error codes
>
> On Apr 1, 2011, at 8:29 AM, Andriy Gapon wrote:
>
>>
>> I am looking for error codes that would unambiguously signal that a disk 
>> drive has
>> readonly or write-protected media and that disk drive has no media at the 
>> moment.
>> I foresee these error codes being used mostly between disk peripheral 
>> drivers and
>> filesystem drivers.
>>
>> I will appreciate your suggestions.
>>
>> P.S.
>> I see that Linux uses EROFS and ENOMEDIUM for these purposes.
>> I am not sure about EROFS in this role.
>> And we don't have ENOMEDIUM (nor EMEDIUMTYPE).
>
> Maybe we could add ENOMEDIA for that (spelled however Linux spells it) after 
> EDAVE.

--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: looking for error codes

[Andrew Duane]

AFAIK, FreeBSD does not really detect read-only media. This was something I had 
to add as a small project here at work, and was considering cleaning up to try 
to get into CURRENT. If there's a real need for it, I could speed that up.

--
Andrew Duane Juniper Networks
978-589-0551  10 Technology Park Dr
adu...@juniper.net  Westford, MA  01886-3418


From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] On 
Behalf Of Warner Losh [i...@bsdimp.com]
Sent: Friday, April 01, 2011 10:51 AM
To: Andriy Gapon
Cc: FreeBSD Hackers; FreeBSD Arch
Subject: Re: looking for error codes

On Apr 1, 2011, at 8:29 AM, Andriy Gapon wrote:

>
> I am looking for error codes that would unambiguously signal that a disk 
> drive has
> readonly or write-protected media and that disk drive has no media at the 
> moment.
> I foresee these error codes being used mostly between disk peripheral drivers 
> and
> filesystem drivers.
>
> I will appreciate your suggestions.
>
> P.S.
> I see that Linux uses EROFS and ENOMEDIUM for these purposes.
> I am not sure about EROFS in this role.
> And we don't have ENOMEDIUM (nor EMEDIUMTYPE).

Maybe we could add ENOMEDIA for that (spelled however Linux spells it) after 
EDAVE.

Warner


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: New Boot-Loader

[Andrew Duane]

-Original Message-
From: owner-freebsd-hack...@freebsd.org 
[mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of Andriy Gapon
Sent: Monday, March 28, 2011 8:00 AM
To: Alexander Best
Cc: FreeBSD Hackers
Subject: Re: New Boot-Loader

Please note that graphical loaders are not very serial console friendly ;-)

-- 
Andriy Gapon


Amen, and we have a whole lot of platforms that are only serial consoles (and 
9600 baud at that).
Also, I like the letters instead of numbers for boot options, for those of us 
that have known for years that "s" is single user mode, "v" is verbose, etc


 ...
Andrew Duane
Juniper Networks
o   +1 978 589 0551
m  +1 603-770-7088
adu...@juniper.net

 



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Unsigned wchar_t

[Andrew Turner]

On Sun, 27 Mar 2011 22:07:30 +0200
Stefan Farfeleder  wrote:

> On Mon, Mar 28, 2011 at 08:36:57AM +1300, Andrew Turner wrote:
> > Along with this WCHAR_MIN and WCHAR_MAX are defined both in
> >  and . I would like to remove the copy
> > from wchar.h and add an include to machine/_stdint.h.
> > 
> > Would there be any problems with either of these or is there a
> > better place to put the __wchar_t typedef and define WCHAR_MIN and
> > WCHAR_MAX?
> 
> The C standard specifies that both  and  shall
> define WCHAR_MIN and WCHAR_MAX. You cannot simply include
>  from  because the former contains a lot
> of other macros.
I thought that might be the case. I could create  for
the defines unless there is a better place for them.

Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Unsigned wchar_t

[Andrew Turner]

Hello hackers@

I'm working on getting FreeBSD working with the ARM EABI. As part of
this the Procedure Call Standard for the ARM Architecture (AAPCS)
defines wchar_t as an unsigned int.

Looking at sys/sys/_types.h rune_t, wchar_t and wint_t are of type
__ct_rune_t which is an int. Furthermore as per the comment above the
typedef rune_t must be signed to hold EOF of -1 and wchar_t must be the
same type as rune_t. Because wchar_t is defined as an unsigned int
would there be any issues with moving the typedef for __wchar_t to
 and changing it from __ct_rune_t to int with the
exception of the ARM EABI case?

Along with this WCHAR_MIN and WCHAR_MAX are defined both in 
and . I would like to remove the copy from wchar.h
and add an include to machine/_stdint.h.

Would there be any problems with either of these or is there a better
place to put the __wchar_t typedef and define WCHAR_MIN and WCHAR_MAX?

Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: seeking into /dev/{null,zero}

[Andrew Duane]

I thought seeking past EOF was valid; writing something creates a file with a 
hole in it. I always assumed that was standard semantics.

As for /dev/zero and /dev/null, you could easily ask "who cares about the file 
position?" But I think some programs might want to seek around and check 
values, and those shouldn't change behaviour if someone uses /dev/null as a 
test file. It seems pretty trivial to update it, so why not make it behave the 
same.

--
Andrew Duane Juniper Networks
978-589-0551  10 Technology Park Dr
adu...@juniper.net  Westford, MA  01886-3418


From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] On 
Behalf Of Garrett Cooper [gcoo...@freebsd.org]
Sent: Tuesday, February 22, 2011 11:22 AM
To: Alexander Best
Cc: freebsd-hackers@freebsd.org
Subject: Re: seeking into /dev/{null,zero}

On Tue, Feb 22, 2011 at 6:11 AM, Alexander Best  wrote:
> hi there,
>
> there's a PR [1] regarding seeking into /dev/null and /dev/zero. i just wanted
> to ask what the overall opinion is on this matter. technically it's quite easy
> to seek into those files upon fwrite(3) and fread(3). the point is, if the 
> file
> position should be repositioned according the the amount of bytes read or
> written.
>
> the zero(4) and null(4) manual pages claim that both devices act as "ordinary"
> files. right now only reading from /dev/zero will seek into the file. writing
> to /dev/zero and reading/writing to /dev/null will *not* adjust the file
> position.

lseek on CURRENT (and its assorted functions) is funky. Try this as an example:

1. Create a zero character file.
2. lseek with SEEK_SET to byte 1.

2. will always return 1.

My Fedora Linux 13 VM on the other hand actually reports the error
when you try and seek outside the bounds of the file descriptor (this
makes more sense IMO because it accurately reflects reality). This is
an extension to the POSIX spec though as the spec doesn't say whether
or not seeking past the bounds of the descriptor is legal or illegal.
So what I'm trying to say is that the seek family functions in general
don't report helpful data except with success.

Found this when trying to write testcases for lseek(2) the night before last.

I'll get back to you about the POSIXness of those /dev's in the most
recent spec once I get access back to the OpenGroup download section
-_-...

Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: reverse of getchar() read() open() fopen() ?

[Andrew Duane]

I've never seen any such thing, but I've done similar things a lot. I'd say 
malloc/read the whole file in and use a decrementing pointer to return the 
"previous" character.

--
Andrew Duane Juniper Networks
978-589-0551  10 Technology Park Dr
adu...@juniper.net  Westford, MA  01886-3418


From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] On 
Behalf Of Julian H. Stacey [j...@berklix.com]
Sent: Friday, February 11, 2011 4:32 PM
To: hack...@freebsd.org
Subject: reverse of  getchar() read() open() fopen() ?

Hi hackers@,
Do we have C libraries with reverse of getchar() [ & maybe read()
] & fopen() [ & maybe open() ] etc, to read from end of file toward
beginning ?  I dont see anything in the See Also sections.  I'm not
looking to write, just read.  I'm looking for something that returns
last char in file as first etc, I'm not interested in wchars etc,
I could write some C functions, with seek etc & probably will, if
none exist, but no point if they already exist ?

Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
 Mail plain text;  Not quoted-printable, Not HTML, Not base 64.
 Reply below text sections not at top, to avoid breaking cumulative context.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Strange problems in the old libc malloc routines

[Andrew Duane]

We are still using the FreeBSD 6 malloc routines, and are rather suddenly 
having a large number of problems with one or two of our programs. Before I dig 
into the 100+ crash dumps I have, I thought I'd see if anyone else has ever 
encountered this.

The problems all seem to stem from some case of malloc returning the pointer 
"1" instead of either NULL or a valid pointer. Always exactly "1". Where this 
goes bad depends on where it happens (in the program or inside malloc itself), 
but that pointer value of "1" is always involved. Some of the structures like 
page_dir look corrupted too. It seems as if maybe the "1" is coming from 
sbrk(0) which is just returning the value of curbrk (which is correct, and not 
even close to "1"). 

Does this ring any bells?

--
Andrew Duane Juniper Networks
978-589-0551  10 Technology Park Dr
adu...@juniper.net  Westford, MA  01886-3418
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: KERN - mfi driver for Dell raid h200 on r210 servers

[Andrew Thompson]

On 30 January 2011 06:20, Damien Fleuriot  wrote:
> Hello lists,
>
>
>
> I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 server.
>
> It ships with a SATA/SAS h200 RAID controller.
>

This card may need the mps(4) driver which is only in HEAD at the moment.


Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Question about process rlimits

[Andrew Duane]

I've been poking at some bugs we have around pushing user memory to/past the 
limits of our box, and decided to try seeing what happens on a stock FreeBSD 
system (7.1 in this case).

Basically I have a program that mallocs big memory chunks and zeros them to 
consume both physical and virtual memory. I had expected the program to stop 
malloc'ing when brk() reaches the process' RLIMIT_DATA (512MB cur and max). It 
didn't. It happily malloc'd many gigabytes of memory until I stopped it.

On our 6.2 based product boxes, RLIMIT_DATA correctly stops the malloc from 
continuing, just like the manuals say.

Am I missing something?

--

Andrew Duane Juniper Networks
978-589-0551 10 Technology Park Dr
adu...@juniper.net   Westford, MA  01886-3418
 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: international crypto laws

[Andrew Stesin]

I think this is reasonable.

WBR,
Andrew

2010/10/15 Julian H. Stacey :
> To quote 8.1-RELEASE/src/crypto/README
>        ...
>        The separation between src/contrib and src/crypto
>        is the result of an old USA law, which made these sources export
>        controlled, so they had to be kept separate.
>
> As international crypto laws are ever changing play things of
> ignorant politicians, & a pain in the orifice to track, & as FreeBSD
> is an international project, it's not just USA law that can be problematic.
>
> We could outsource disinterest in the wold's mess of crypto laws,
> by adding a URL to this:
>        http://rechten.uvt.nl/koops/cryptolaw/
>        Crypto Law Survey indexed by country
>
> Cheers,
> Julian
> --
> Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
>  Mail plain text;  Not HTML, quoted-printable & base 64 spam formats.
>        Top posting cripples itemised cumulative responses.
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: disassembler

[Andrew MacIntyre]

Aryeh Friedman wrote:

I should of said USB drive I just think of all USB drives as "flash"
drives... it is a Lacie external drive


If this is a 3.5" drive with an external power supply, then the drive 
itself might be okay but the circuitry adapting it to the USB connector 
might have developed a problem - I not long ago had this happen to me, 
and the drive, when extracted (with some difficulty) from the case, 
could be accessed when connected directly to a P-ATA interface.


--
-----
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andy...@bullseye.apana.org.au  (pref) | Snail: PO Box 370
   andy...@pcug.org.au (alt) |Belconnen ACT 2616
Web:http://www.andymac.org/   |Australia
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: 8.1-STABLE amd64 machine check

[Andrew Heybey]

On Aug 11, 2010, at 6:47 AM, Dan Langille wrote:

> I am encountering a situation similar to one reported by Andrew Heybey 
> at http://docs.freebsd.org/cgi/mid.cgi?6E83197B-9DD5-4C7E-846D-AD176C25464D
> 
> This morning I found this in my /var/log/messages:
> 
> Aug 11 01:59:48 kraken kernel: MCA: Bank 4, Status 0x94614c62001c011b
> Aug 11 01:59:48 kraken kernel: MCA: Global Cap 0x0106, 
> Status 0x
> Aug 11 01:59:48 kraken kernel: MCA: Vendor "AuthenticAMD", ID 0x100f42, 
> APIC ID 0
> Aug 11 01:59:48 kraken kernel: MCA: CPU 0 COR GCACHE LG RD error
> Aug 11 01:59:48 kraken kernel: MCA: Address 0x5d0fe8c
> 
> Andrew: You posted about this on July 14.  Anything new since then?

I took jkim's advice and RMAed the CPU to newegg since it was only a week old.  
No machine checks from the new one yet.

andrew

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: 8.1RC2 amd64 machine check question

[Andrew Heybey]

On Jul 15, 2010, at 8:07 AM, John Baldwin wrote:

> On Wednesday, July 14, 2010 11:25:29 am Andrew Heybey wrote:
>> Got the following in /var/log/messages on my one-week-old amd64 box running 
>> 8.1RC2:
>> 
>> Jul 13 20:30:17 spaten kernel: MCA: Global Cap 0x0106, Status 
>> 0x
>> Jul 13 20:30:17 spaten kernel: MCA: Vendor "AuthenticAMD", ID 0x100f43, APIC 
>> ID 0
>> Jul 13 20:30:17 spaten kernel: MCA: CPU 0 COR GCACHE LG EVICT error
>> Jul 13 20:30:17 spaten kernel: MCA: Address 0x2a49464c
> 
> I tend to use mcelog to get more detailed results.  Unfortunately this is
> missing the first line which contains the bank number and status register, so
> I can't provide any extra details.

Doh.  Sorry, thought that I had cut-and-paste everything.

Jul 13 20:30:17 spaten kernel: MCA: Bank 4, Status 0x942c4880001c017b

andrew

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

8.1RC2 amd64 machine check question

[Andrew Heybey]

Got the following in /var/log/messages on my one-week-old amd64 box running 
8.1RC2:

Jul 13 20:30:17 spaten kernel: MCA: Global Cap 0x0106, Status 
0x
Jul 13 20:30:17 spaten kernel: MCA: Vendor "AuthenticAMD", ID 0x100f43, APIC ID 0
Jul 13 20:30:17 spaten kernel: MCA: CPU 0 COR GCACHE LG EVICT error
Jul 13 20:30:17 spaten kernel: MCA: Address 0x2a49464c

I read through sys/amd64/amd64/mca.c and it seems to be a correctable error on 
my L3 cache, but I am not 100% sure I am interpreting it correctly.

Motherboard is an ASUS M4A785TD-V EVO w/ 2x 2GB ECC RAM and and an AMD Phenom 
X2:

FreeBSD 8.1-RC2 #0: Tue Jun 29 20:21:55 UTC 2010
r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Phenom(tm) II X2 550 Processor (3113.67-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x100f43  Family = 10  Model = 4  Stepping = 3
  
Features=0x178bfbff
  Features2=0x802009
  AMD 
Features=0xee500800
  AMD 
Features2=0x37ff
  TSC: P-state invariant
real memory  = 4294967296 (4096 MB)
avail memory = 4112510976 (3921 MB)
ACPI APIC Table: <041510 APIC1115>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1

My questions are:

1. Did I interpret the message correctly (correctable error on my L3 cache)?

2. Is it anything to worry about?  Or is this just one of those things that 
happens but now it gets logged whereas before I was blissfully ignorant?

thanks,
andrew

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]

[Andrew Reilly]

On Thu, Jun 24, 2010 at 09:23:37AM +0200, Gary Jennejohn wrote:
> in /etc/src.conf - WITHOUT_LPR=yes
> 
> and these symbolic links in /usr/bin
> lrwxr-xr-x  1 root  wheel  17 Mar 18  2009 /usr/bin/lp -> 
> /usr/local/bin/lp
> lrwxr-xr-x  1 root  wheel  24 Mar 18  2009 /usr/bin/lpoptions -> 
> /usr/local/bin/lpoptions
> lrwxr-xr-x  1 root  wheel  18 Mar 18  2009 /usr/bin/lpq -> 
> /usr/local/bin/lpq
> lrwxr-xr-x  1 root  wheel  18 Mar 18  2009 /usr/bin/lpr -> 
> /usr/local/bin/lpr
> lrwxr-xr-x  1 root  wheel  19 Mar 18  2009 /usr/bin/lprm -> 
> /usr/local/bin/lprm
> lrwxr-xr-x  1 root  wheel  21 Mar 18  2009 /usr/bin/lpstat -> 
> /usr/local/bin/lpstat
> 
> and /usr/bin is _before_ /usr/local/bin in my PATH.

Since you have /usr/local/bin in your path, why bother with
the symlinks at all?  Your shell will find them in their new
locations just fine.  You'll want to remove the old ones from
/usr/bin, but make delete-old will probably do that nicely
anyway.

Cheers,

-- 
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: loader prompt: list / on other device

[Andrew Duane]

You *should*  be able to use device1s2a:/ as a syntax, but I noticed a bug in 
our old loader code that parses devicenames like that where it wouldn't work 
correctly with unit numbers. I don't know if that bug is still around, but 
setting currdev did work around it.

/Andrew
 
 

> -Original Message-
> From: owner-freebsd-hack...@freebsd.org 
> [mailto:owner-freebsd-hack...@freebsd.org] On Behalf Of 
> rank1see...@gmail.com
> Sent: Wednesday, June 23, 2010 12:04 PM
> To: freebsd-hackers@freebsd.org
> Subject: loader prompt: list / on other device
> 
> I've escaped to loader prompt:
> Current device is disk0s3a, from which this loader is running.
> 
> My USB stick is device1 and device1s2a is UFS /, on which I 
> would like to reach some file or simply list directory.
> 
> Syntax? 
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to 
> "freebsd-hackers-unsubscr...@freebsd.org"
> ___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Are POSIX mqueues supposed to be functional on FreeBSD?

[Andrew Thompson]

On 21 June 2010 10:11, Garrett Cooper  wrote:
> On Sun, Jun 20, 2010 at 3:06 PM, Stathis Kamperis  wrote:
>> 2010/6/21 Garrett Cooper :
>>>    Err... I ran an mqueue test and it popped up with ENOSYS. Which
>>> makes me wonder, are POSIX mqueues implemented 100% on FreeBSD? I
>>> looked into sys/kern/uip_mqueue.c and it _appears_ functional, but I
>>
>> Hi,
>>
>> did you first load the respective kernel module (mqueuefs or something
>> like that) ?
>
> Duh... should have checked that first I suppose: no, it isn't loaded.
> However, it doesn't appear to compile with my copy of src:
>
> # make -C /sys/modules/mqueue/ all install
> Warning: Object directory not changed from original 
> /usr/src/sys/modules/mqueue
> cc -O2 -pipe -fno-strict-aliasing -pipe -O2 -march=nocona -Werror
> -D_KERNEL -DKLD_MODULE -nostdinc   -I. -I@ -I@/contrib/altq
> -finline-limit=8000 --param inline-unit-growth=100 --param
> large-function-growth=1000 -fno-common  -fno-omit-frame-pointer
> -mcmodel=kernel -mno-red-zone  -mfpmath=387 -mno-sse -mno-sse2
> -mno-sse3 -mno-mmx -mno-3dnow  -msoft-float
> -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector
> -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls
> -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes
> -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign
> -fformat-extensions -c
> /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c
> /usr/src/sys/modules/mqueue/../../kern/uipc_mqueue.c:48:24: error:
> opt_compat.h: No such file or directory
> *** Error code 1
>
> Stop in /usr/src/sys/modules/mqueue.
> # find /usr/src/ -name opt_compat.h
>
> So I'll need to hunt down what's going on with the missing header.

opt_* headers are auto-generated by the kernel config. Just add
opt_compat.h to sys/modules/mqueue/Makefile right after opt_posix.h


Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [FreeBSD 8/9] [64-bit IOCTL] Using the USB stack from a 32-bit application under a 64-bit kernel.

[Andrew Thompson]

On 31 May 2010 10:19, Kostik Belousov  wrote:
> On Sun, May 30, 2010 at 09:50:15PM +0200, Hans Petter Selasky wrote:
>> Hi,
>>
>> The USB team in FreeBSD has discussed this issue internally and would like
>> some advice how to best resolve the 32 bit to 64 bit IOCTL conversion issue.
>>
>> Sometimes IOCTL requests contain userland pointers of type "void *". When
>> compiled on a 64-bit OS, sizeof(void *) is 8 bytes and when compiled on a 32-
>> bit OS sizeof(void *) is 4 bytes. This size difference makes it impossible to
>> forward IOCTLs 1:1 from a 32-bit application running under a 64-bit kernel.
>>
>> This issue does not only apply to the USB subsystem, but also other kernel
>> IOCTL interfaces. I suggest a more general solution:
>>
>> typedef uint64_t pvoid64;
>>
>> When an IOCTL needs to reference pointers in userspace, then they should
>> always pad the pointer to 64-bit and use the pvoid64, which could have been a
>> compiler type, so that we can easily convert to "void *" without using casts.
>>
>>
>> When converting 32-bit userland pointers into 64-bit ones, there is no 
>> pointer
>> conversion except for the unsigned expansion and resulting zero-padding. I
>> assume this assumption will always be valid.
>>
>>
>> Please find attached an example patch to make the USB stack in 8 and 9 fully
>> 64-bit compatible.
>>
>>
>> Any comments are welcome!
>>
>>
>> --HPS
>> --- src/sys/dev/usb/usb_ioctl.h       2010-02-14 12:03:51.0 
>> +++ src/sys/dev/usb/usb_ioctl.h       2010-02-14 12:03:51.0 
>> @@ -131,9 +131,10 @@
>>        * NOTE: isochronous USB transfer only use one buffer, but can have
>>        * multiple frame lengths !
>>        */
>> -     void  **ppBuffer;               /* pointer to userland buffers */
>> -     uint32_t *pLength;              /* pointer to frame lengths, updated
>> -                                      * to actual length */
>> +     uint64_t ppBuffer;              /* pointer to 64-bit userland buffer 
>> pointers */
>> +     uint64_t pLength;               /* pointer to 32-bit frame lengths, 
>> which
>> +                                      * get updated to the actual length 
>> after
>> +                                      * the transfer is complete. */
>>       uint32_t nFrames;               /* number of frames */
>>       uint32_t aFrames;               /* actual number of frames */
>>       uint16_t flags;
>
> Doesn't this change the existing ABI for 32bit platforms ?
>
> You may take a look at the sys/net/bpf.c, where the similar
> issue is handled for bpf ioctls. To keep the ABI intact, you
> would need to define the 32bit ABI structures and define
> compat ioctls, then handle the ioctls by converting the structures
> and calling the native handler. BIOCSRTIMEOUT32 is a good example.

This has been done for other usb ioctls but the above struct has a
pointer to an array of pointers in userland which makes it difficult.
It isnt copied in with the ioctl so doesnt get the chance to be fixed
up.

so far, http://people.freebsd.org/~thompsa/linux_usb_amd64_2.diff


Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: bad RAM? prove it with a crash dump?

[Andrew Duane]

owner-freebsd-hack...@freebsd.org wrote:
> On Thu, 6 May 2010, Boris Kochergin wrote:
> 
>> My experience with bad memory is that if it causes the machine to
>> crash, it won't always happen while the machine is running the same
>> process (or kernel thread)--so look for it crashing in a wide
>> variety of places--and upon inspection of the core dump, a pointer
>> somewhere will be pointing to garbage.
> 
> 
> so really i'd need to collect two or more crash dumps, and if they
> point to different addresses then i can reasonably say the RAM is bad?
> 
> thanks...

It's not just that they point to different addresses, it is garbage in many 
completely independent places. For example, pulling bad registers/return 
addresses off the stack, or garbage in random unrelated 
buffers/structures/pointers. On the other hand, if you often have garbage in 
some structure's "foo" pointer, that indicates a problem (maybe locking) in how 
your code manages setting that foo pointer. It's a subtle difference.

It is also useful to make sure that the garbage itself is different. As 
mentioned before, a single bit error in an otherwise valid value, or maybe a 
missing/scrambled byte, these are good indications of memory problems. If 
random places are often overwritten with something else, that could just be 
another piece of misbehaving code that is writing someplace it shouldn't. I've 
often found code that writes some buffer into e.g. a piece of memory it no 
longer owns that looks like memory corruption until you realize the garbage is 
always something specific like a vnode structure.

/Andrew

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: GSoC:Complete Package support in the pkg_install tools and cleanup

[Andrew Brampton]

On Tue, May 4, 2010 at 3:28 AM, Julien Laffaye  wrote:
>
> Hello,
>
> During this summer, I'll work on the pkg_install tools to add complete
> package support.
> A complete package is a package which includes all the required
> dependencies in its tarball.
> Unlike the PBI package format of PC-BSD, once a complete package is installed,
> it appears as every package contained in the complete package was
> installed separately.
>
[snip]
>
> Best regards,
> Julien Laffaye

Hi Julien,

Glad you got onto the GSoC programme. I'm curious, what benefit is a
complete package over many individual ones?

Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: kenv - output needed

[Andrew Thompson]

On Wed, Mar 24, 2010 at 02:09:41PM +1300, Atom Smasher wrote:
> On Tue, 23 Mar 2010, Garrett Cooper wrote:
> 
>> Are you looking for data represented similar to sysctl(8)?
> 
> 
> it doesn't quite have to be, but it is being parsed in a script.

How about pulling the kenv variables into the script.

#!/bin/sh

eval $(kenv | awk -F= '/^smbios/ { gsub("\\\.","_",$1); print $1 "=" $2}')

echo $smbios_chassis_maker
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: kenv - output needed

[Andrew Thompson]

On Wed, Mar 24, 2010 at 08:06:23AM +1300, Atom Smasher wrote:
> On Wed, 24 Mar 2010, Andrew Thompson wrote:
> 
>> On Tue, Mar 23, 2010 at 05:12:47PM +1300, Atom Smasher wrote:
>>> i'm trying to figure out what might be reasonable output from kenv. on 
>>> the three machines that i have access to i'm already seeing wide 
>>> variations of formatting and usefulness.
>>> 
>>> i'd like to collect as much output as i can get (off-list should be fine) 
>>> from one of these two commands:
>>> 
>>> 1) preferred:
>>> kenv | egrep bios
>>> 
>>> 2) i can also use this:
>>> kenv | egrep 'product|maker'
>> 
>> kenv is essentially dumping all the variables set by the bootloader prior 
>> to starting the kernel. If you want something more structured then maybe 
>> the dmidecode utility would be useful.
> ===
> 
> structure is cool, but it seems like you're being human-centric in your 
> reference to structure; i actually want to parse the info with a script, 
> making kenv preferable.
> 
> i want the ability to run the script without any privileges; again making 
> kenv preferable.
> 
> so with an unprivileged script, i'm leaning towards kenv to find out what 
> hardware is running (motherboard & system info, eg "Dell Inc., 0H603H, 
> PowerEdge 2950" or "Acer, Navarro, Aspire 5100").
> 
> other than being formatted more nicely (for humans, anyway) and only 
> running with root privileges, is there any ~real~ difference between the 
> information i would get from dmidecode rather than kenv (as it relates to 
> motherboard & system make & model)? it seems like in either case, i'm just 
> getting the info from smbios... and that info could be good, bad or ugly 
> regardless of how it's formatted.

Yea, both methods get the info from smbios. So back to the original
question about reasonable output from kenv, I would expect it to contain
all the same basic information that dmidecode fetches. If it is missing
something then it is a bug, otherwise that is the data the bios maker
has provided and the script will need to handle it.


cheers,
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: kenv - output needed

[Andrew Thompson]

On Tue, Mar 23, 2010 at 05:12:47PM +1300, Atom Smasher wrote:
> i'm trying to figure out what might be reasonable output from kenv. on the 
> three machines that i have access to i'm already seeing wide variations of 
> formatting and usefulness.
> 
> i'd like to collect as much output as i can get (off-list should be fine) 
> from one of these two commands:
> 
> 1) preferred:
>   kenv | egrep bios
> 
> 2) i can also use this:
>   kenv | egrep 'product|maker'

kenv is essentially dumping all the variables set by the bootloader
prior to starting the kernel. If you want something more structured then
maybe the dmidecode utility would be useful.


cheers,
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: ATA 4K sector issues

[Andrew Stesin]

2010/3/17 Matthew Dillon :
>    you absolutely must use a 4K fragment size (32K block size) and an
>    aligned partition when using UFS with 4K physical sector drives.

Sorry for my ignorance, but what's wrong with making this the default
setting for newfs regardless of whatever the drive is?

Thanks,
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: Dead store elimination in the kernel?

[Andrew Duane]

owner-freebsd-hack...@freebsd.org wrote:
> Hello,
> 
> I'm asking if FreeBSD is safe regarding dead store elimination made
> by gcc? 
> 
> By example, in crypto drivers, sensitive datas are cleared by a
> bzero() after use to avoid potential leakages.  But the bzero() by
> itself is useless, is it removed by gcc?
> 
> Thanks, regards.
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscr...@freebsd.org"

I would think the "correct" way to handle this is to make sure all appropriate 
items are declared volatile. This would eliminate dead store elimination, as 
the compiler can tell they are not dead.

Unfortunately, the history of drivers (or any code) correctly using volatile 
declarations is intermittent at best.

/Andrew

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Per core, per device interrupt counts

[Andrew Brampton]

After reading though the kernel source I realise what I want isn't
implemented at the moment but I wanted to discuss if this feature
would be an useful addition.

Basically I want to see counts of how many interrupts for a particular
interrupt have fired on each core. Linux has provided this kind of
information for a while and I've found it quite useful. I would like
this information when I am pinning particular interrupts to one (or
more cores). This is useful when I'm tweaking a system with, for
example, 10Gig network cards which have multiple queues (thus multiple
IRQs).

Having a look in the kernel I see that the count is kept in the
is_count field of the intsrc struct. This field seems to be backed by
the global intrcnt array. Could this be modified to perhaps use the
new PCPU macros, so there is a different count for each core? If I was
given a few pointers I might find time to implement this myself.

thanks
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

RE: Future CPUs - 128 threads

[Andrew Duane]

owner-freebsd-hack...@freebsd.org wrote:
> Artem Belevich wrote:
>>> Seriously, simply because of curiosity - are MIPS CPUs used in any
>>> kind of "general purpose" machines?
>> 
>> I'm not aware of any multi-core general-purpose MIPS box.
>> Low-end MIPS CPUs are ubiquitous in low-end networking gear.
>> High-end multicore MIPS chips are mostly going into mid-to-high end
>> networking gear like firewalls.
> 
> 
> However several companies are using FreeBSD as a base kernel for their
> appliance, based on these chips. So they are of direct interest to us.
>> 
>> They are probably not a very good fit for general purpose computing.
>> 
>> --Artem


I believe I know of one such company... :-)

--

Andrew Duane Juniper Networks
978-589-0551 10 Technology Park Dr
adu...@juniper.net   Westford, MA  01886-3418
 


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: KLD hello.ko: depends on kernel - not available or version mismatch

[Andrew Brampton]

On Thu, Feb 11, 2010 at 2:25 AM, james toy  wrote:
> Hello Hackers,
>
>    I am working on learning to write FreeBSD drivers; however, I have
> some practice writing IOKit drivers for MacOSX (they are entirely
> different I know!).  The code I am working with can be found here:
>
> http://pastebin.com/m2bbb393c
>
> and I am getting the error:
>
> dontpanic# kldload ./hello.ko
> kldload: can't load ./hello.ko: Exec format error
>
> dmesg reads:
>
> dontpanic# kldload ./hello.ko
> kldload: can't load ./hello.ko: Exec format error
>
> and finally uname -a:
>
> FreeBSD dontpanic.union.edu 9.0-CURRENT FreeBSD 9.0-CURRENT #1
> r198859: Wed Feb 10 09:59:54 EST 2010
> ja...@dontpanic.union.edu:/usr/obj/usr/src_klog/sys/DONTPANIC  amd64
>
> any information pointing me to being able to load this driver would be
> greatly appreciated.
>
> respectfully,
>
> james toy

I just built your code on my FreeBSD 8 box and it compiles and loads
fine. How are you compiling your code? I used this makefile
http://pastebin.com/f3ab71917 and all I typed was this:

make
sudo make install
sudo make load

and I get the "hello, fail" message, and then I typed
sudo make unload

and I got the "unload fail" message.

Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: sysctl with regex?

[Andrew Brampton]

On Wed, Feb 10, 2010 at 12:51 AM, Garrett Cooper  wrote:
>        fnmatch is for matching filenames... I think there's a better way to 
> do it with globs, but I'll have to take a quick peek at python's glob module 
> so I don't reinvent the wheel (using fnmatch(3) // glob(3) to string match 
> seems kind of stupid to do...).
>

I think fnmatch() is used to match filenames but reading its
documentation I don't see why it has to be used only for filenames. It
takes a pattern and a string and returns true if they match. Having a
quick look in the FreeBSD source it is used in a few non-filesystem
places, for example, contrib/binutils/ld/ldlang.c to match section
names, sys/netinet/ipfw/ip_fw2.c to match interface names. I'm sure
there are other examples. However, if you can find a better suited
function then sure, I just don't like reinventing the wheel, even if
this wheel is the wrong colour ;)

Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: sysctl with regex?

[Andrew Brampton]

On Wed, Feb 10, 2010 at 12:14 AM, Garrett Cooper  wrote:
> C-shell globs as some programming languages referring to it as, i.e. perl 
> (which this is a subset of the globs concept) allow for expansion via `*' to 
> be `anything'. Regexp style globs for what you're looking for would be either 
> .* (greedy) or .+ (non-greedy), with it being most likely the latter case.
>

Ah I understand the difference now. Thanks.

>        I'll see if I can whip up a quick patch in the next day or so -- but 
> before I do that, does it make more sense to do globs or regular expressions? 
> There are pluses and minuses to each version and would require some degree of 
> parsing (and potentially escaping).

I think going for the simpler glob option might be best. In my earlier
example a regex would have problems with all the periods, would it
not? Also if I want to match anything I would always forget to write
.* instead of just *

I was just having a quick look at how to implement this, would it be
best to use the fnmatch function? Having a quick browse of the FreeBSD
source I found csh_match in /usr.sbin/pkg_install/lib/match.c:L456
which seems to do something similar to what we want.

BTW Feel free to implement this, I was going to have a go but I doubt
I'd actually get around to it :(

Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: sysctl with regex?

[Andrew Brampton]

2010/2/9 Dag-Erling Smørgrav :
> Andrew Brampton  writes:
>> Today I was writing a script to read all the dev.cpu.?.temperature
>> sysctl OIDs. I was parsing them using a simple grep, but it occurred
>> to me it might be better if sysctl supported some form of regexp.
>
> You mean glob, not regexp...

Could you explain why do I mean glob instead or regexp?
Is glob simple matches, ie * and ?
and regexp more complex like [a-z]*

>> For example instead of typing:
>> sysctl -a | grep dev.cpu.*.temperature
>>
>> I could write:
>> sysctl dev.cpu.*.temperature
>
> Sounds like a good idea.  Shouldn't be too hard to implement either.

If I get time I might submit a patch.

Thanks
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

sysctl with regex?

[Andrew Brampton]

Today I was writing a script to read all the dev.cpu.?.temperature
sysctl OIDs. I was parsing them using a simple grep, but it occurred
to me it might be better if sysctl supported some form of regexp. For
example instead of typing:
sysctl -a | grep dev.cpu.*.temperature

I could write:
sysctl dev.cpu.*.temperature

which would display all the OIDs that match dev.cpu.*.temperature.
This is better than grep because when I issue a "sysctl -a" the
program retrieves many variables that I am not interested in (which
later get filtered by grep). This would in a way be similar to: sysctl
dev.cpu

which lists all the OIDs under dev.cpu. Is this a feature people would
find useful? Or would I be optimising a problem that doesn't exist?

Thanks for any input
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: devfs panic w/INVARIANTS

[Andrew Gallatin]

Kostik Belousov wrote:

On Fri, Feb 05, 2010 at 08:51:25AM -0500, Andrew Gallatin wrote:

Kostik Belousov wrote:

On Thu, Feb 04, 2010 at 03:40:28PM -0500, Andrew Gallatin wrote:

I've got a commercial driver that uses device cloning.
At unload time, the driver calls clone_cleanup(). When I unload
the driver when the kernel is built with INVARIANTS, I'll see a
panic in devfs_populate_loop().  This happens in 6-stable,
as well as 8-stable.


>From what I can see the clone has been freed, but it

remains on the devfs cdevp_list.   Then the next time
devfs_populate_loop() is called, it trips over the bad
entry (cdp->cdp_dirents points to 0xdeadc0dedeadc0de)
See appended kgdb session.

If I trace the code path, it looks like clone_cleanup()
calls destroy_devl().  And destroy_devl() will eventually
call devfs_free() if the si_refcnt is zero.  But I don't
see anything which will get the cdev removed from
the cdevp_list prior to it being freed.

The only code I see which will get the cdev removed from
the cdevp_list() seems to be the "GC any lingering devices"
block in devfs_populate_loop

What am I missing?

You did not mentioned it, but my guess is that you create clones from
the dev_clone event handler. Please note that devfs_lookup() that fires

Yes, I do.


dev_clone event, consumes a device reference. Thus clone handlers shall
do dev_ref().

Due to races with cleanup, you should use MAKEDEV_REF flag for
make_dev_credv(9) KPI instead of doing make_dev()/dev_ref() pair.

I need to support FreeBSD going all the way back to 6, so that's not an
option in some versions.

But, I'm talking about device removal time.  If I call clone_cleanup()
where the clones have dev->si_refcount==1, then I get the use-after-free
panic.  If I hack things to elevate the reference count (such that
dev->si_refcount==2 when clone_cleanup() is called), then I don't
get the panic.

Are you saying I should have been taking the extra reference
via my dev_clone eventhandler?   Won't having the extra reference
lead to a memory leak?   Or am I just mis-reading the code, and
this will lead to things being freed normally?

Yes, clone handler shall do dev_ref(). Either by doing race-free
make_dev_credf(MAKEDEV_REF) call, or by using dev_ref() after make_dev().


OK, cool.  The man pages are handy.  When I started this
back in the FreeBSD 5 days, the man pages didn't exist :)


That said, do you really need clones at all ?

I need to support FreeBSD back to 6.x, and I need to support the
linux-like model of opening the "same" /dev/node multiple times
and getting unique handles.  So I think I need clones.


Wouldn't it be cleaner to use cdevpriv for the 7/8/HEAD where it is
present ? And have special #ifdef-ed code for 6, that could be
eventually dropped.


Yes, the cdevpriv() is a much cleaner interface.  I'll probably add
support for that soon.

Thanks for the help,

Drew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: devfs panic w/INVARIANTS

[Andrew Gallatin]

Kostik Belousov wrote:

On Thu, Feb 04, 2010 at 03:40:28PM -0500, Andrew Gallatin wrote:

I've got a commercial driver that uses device cloning.
At unload time, the driver calls clone_cleanup(). When I unload
the driver when the kernel is built with INVARIANTS, I'll see a
panic in devfs_populate_loop().  This happens in 6-stable,
as well as 8-stable.

From what I can see the clone has been freed, but it
remains on the devfs cdevp_list.   Then the next time
devfs_populate_loop() is called, it trips over the bad
entry (cdp->cdp_dirents points to 0xdeadc0dedeadc0de)
See appended kgdb session.

If I trace the code path, it looks like clone_cleanup()
calls destroy_devl().  And destroy_devl() will eventually
call devfs_free() if the si_refcnt is zero.  But I don't
see anything which will get the cdev removed from
the cdevp_list prior to it being freed.

The only code I see which will get the cdev removed from
the cdevp_list() seems to be the "GC any lingering devices"
block in devfs_populate_loop

What am I missing?


You did not mentioned it, but my guess is that you create clones from
the dev_clone event handler. Please note that devfs_lookup() that fires


Yes, I do.


dev_clone event, consumes a device reference. Thus clone handlers shall
do dev_ref().

Due to races with cleanup, you should use MAKEDEV_REF flag for
make_dev_credv(9) KPI instead of doing make_dev()/dev_ref() pair.


I need to support FreeBSD going all the way back to 6, so that's not an
option in some versions.

But, I'm talking about device removal time.  If I call clone_cleanup()
where the clones have dev->si_refcount==1, then I get the use-after-free
panic.  If I hack things to elevate the reference count (such that
dev->si_refcount==2 when clone_cleanup() is called), then I don't
get the panic.

Are you saying I should have been taking the extra reference
via my dev_clone eventhandler?   Won't having the extra reference
lead to a memory leak?   Or am I just mis-reading the code, and
this will lead to things being freed normally?


That said, do you really need clones at all ?


I need to support FreeBSD back to 6.x, and I need to support the
linux-like model of opening the "same" /dev/node multiple times
and getting unique handles.  So I think I need clones.

Thanks for the help!
Drew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

devfs panic w/INVARIANTS

[Andrew Gallatin]

I've got a commercial driver that uses device cloning.
At unload time, the driver calls clone_cleanup(). When I unload
the driver when the kernel is built with INVARIANTS, I'll see a
panic in devfs_populate_loop().  This happens in 6-stable,
as well as 8-stable.

From what I can see the clone has been freed, but it
remains on the devfs cdevp_list.   Then the next time
devfs_populate_loop() is called, it trips over the bad
entry (cdp->cdp_dirents points to 0xdeadc0dedeadc0de)
See appended kgdb session.

If I trace the code path, it looks like clone_cleanup()
calls destroy_devl().  And destroy_devl() will eventually
call devfs_free() if the si_refcnt is zero.  But I don't
see anything which will get the cdev removed from
the cdevp_list prior to it being freed.

The only code I see which will get the cdev removed from
the cdevp_list() seems to be the "GC any lingering devices"
block in devfs_populate_loop

What am I missing?


Thanks,

Drew


Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 01
instruction pointer = 0x8:0x803e8780
stack pointer   = 0x10:0xade623b0
frame pointer   = 0x10:0xade62400
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 896 (ps)
Dumping 510 MB (2 chunks)
Dumping 510 MB (2 chunks)
Dumping 510 MB (2 chunks)
  chunk 0: 1MB (156 pages) ... ok
  chunk 1: 510MB (130528 pages) 494 478 462 446 430 414 398 382 366 350 
334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 
30 14


#0  doadump () at pcpu.h:172
172 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) bt
#0  doadump () at pcpu.h:172
#1  0x801b8d91 in db_fncall (dummy1=0, dummy2=0, dummy3=0, 
dummy4=0x0) at ../../../ddb/db_command.c:493
#2  0x801b91e5 in db_command_loop () at 
../../../ddb/db_command.c:408
#3  0x801bb0ed in db_trap (type=-1377427040, code=0) at 
../../../ddb/db_main.c:222
#4  0x80468b99 in kdb_trap (type=9, code=0, 
tf=0xade62300) at ../../../kern/subr_kdb.c:473
#5  0x806c5d14 in trap_fatal (frame=0xade62300, 
eva=18446742974557577824)

at ../../../amd64/amd64/trap.c:660
#6  0x806c62eb in trap (frame=
  {tf_rdi = -2136471632, tf_rsi = -2136471656, tf_rdx = 
-2401050962867404578, tf_rcx = 1, tf_r8 = -2136471624, tf_r9 = 
-1099151973792, tf_rax = 0, tf_rbx = -1099307447040, tf_rbp = 
-1377426432, tf_r10 = 0, tf_r11 = 4, tf_r12 = 0, tf_r13 = 
-1099086652928, tf_r14 = -1099307447040, tf_r15 = 86032452, tf_trapno = 
9, tf_addr = 0, tf_flags = -2143029088, tf_err = 0, tf_rip = 
-2143385728, tf_cs = 8, tf_rflags = 66071, tf_rsp = -1377426496, tf_ss = 
16}) at ../../../amd64/amd64/trap.c:470
#7  0x806ad84b in calltrap () at 
../../../amd64/amd64/exception.S:168
#8  0x803e8780 in devfs_populate_loop (dm=0xff000c2b8d00, 
cleanup=0) at ../../../fs/devfs/devfs_devs.c:370
#9  0x803e8beb in devfs_populate (dm=0xff000c2b8d00) at 
../../../fs/devfs/devfs_devs.c:486
#10 0x803eafab in devfs_lookup (ap=0x0) at 
../../../fs/devfs/devfs_vnops.c:587
#11 0x80724a2e in VOP_LOOKUP_APV (vop=0x80948600, 
a=0xade62630) at vnode_if.c:99

#12 0x804aadb2 in lookup (ndp=0xade629c0) at vnode_if.h:56
#13 0x804abb66 in namei (ndp=0xade629c0) at 
../../../kern/vfs_lookup.c:216
#14 0x804c1be2 in vn_open_cred (ndp=0xade629c0, 
flagp=0xade6290c, cmode=0,

cred=0xff09ac00, fdidx=3) at ../../../kern/vfs_vnops.c:183
#15 0x804b8d64 in kern_open (td=0xff00156fe260, 
path=0xmode=373490024) at ../../../kern/vfs_syscalls.c:1016
#16 0x804b9455 in open (td=0x80a807b0, 
uap=0xade62bc0) at ../../../kern/vfs_syscalls.c:971

#17 0x806c6b52 in syscall (frame=
  {tf_rdi = 4218321, tf_rsi = 0, tf_rdx = 0, tf_rcx = 0, tf_r8 = 
140737488348272, tf_r9 = 0, tf_rax = 5, tf_rbx = 5300224, tf_rbp = 
4218321, tf_r10 = 0, tf_r11 = 5300224, tf_r12 = 4218321, tf_r13 = 0, 
tf_r14 = 140737488348272, tf_r15 = 6, tf_trapno = 12, tf_addr = 5300224, 
tf_flags = 0, tf_err = 2, tf_rip = 34369309420, tf_cs = 43, tf_rflags = 
514, tf_rsp = 140737488347528, tf_ss = 35}) at 
../../../amd64/amd64/trap.c:807
#18 0x806ada48 in Xfast_syscall () at 
../../../amd64/amd64/exception.S:287

#19 0x000800920aec in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 7
#7  0x806ad84b in calltrap () at 
../../../amd64/amd64/exception.S:168

168 calltrap
Current language:  auto; currently asm
(kgdb) up
#8  0x803e8780 in devfs_populate_loop (dm=0xff000c2b8d00, 
cleanup=0) at ../../../fs/devfs/devfs_devs.c:370

370 if ((cleanup || !(cdp->cdp_flags & CDP_ACTIVE)) &&
Current language:  auto; curre

RE: Spin down HDD after disk sync or before power off

[Andrew Duane]

From: owner-freebsd-hack...@freebsd.org [owner-freebsd-hack...@freebsd.org] On 
Behalf Of Warren Block [wbl...@wonkity.com]
Sent: Wednesday, February 03, 2010 7:43 PM
To: Erich Dollansky
Cc: freebsd-hackers@freebsd.org
Subject: Re: Spin down HDD after disk sync or before power off

On Thu, 4 Feb 2010, Erich Dollansky wrote:
> In case of a reboot, it is already known when the command is given that the 
> machine will restart without being powered of.
>
> If you spin-down the disk, you lose one start cycle.
>
> It is not that important but if it can be done with just one if, please, just 
> do it.

AFAICT ad_shutdown can't tell whether it's called for a reboot or a
poweroff, it's just told to "shut down".  So maybe it's one if, but it's
somewhere above ata-disk.c but below reboot(RB_POWEROFF).

-Warren Block * Rapid City, South Dakota USA


You can register for a shutdown even that *does* get to know the "howto" 
variable; we do this quite a bit on some of our platforms that need special 
handling at power-off versus halt.

extern void jsrxnle_poweroff_devices(void *junk, int howto);

/* Registering power-off handler to be called at the system shutdown */
EVENTHANDLER_REGISTER(shutdown_final, jsrxnle_poweroff_devices, NULL, 
SHUTDOWN_PRI_LAST + 10);

The howto argument can be checked for RB_POWEROFF:

    if (howto & RB_POWEROFF) {
   /* Spin Down */
}

--
Andrew Duane Juniper Networks
978-589-0551  10 Technology Park Dr
adu...@juniper.net  Westford, MA  01886-3418

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Cross-building amd64->i386 fails at RESCUE

[Andrew Thompson]

On Wed, Jan 13, 2010 at 09:35:53AM +0800, Mars G Miro wrote:
> Hi List!
> 
> Has anyone successfully cross-built amd64->i386 in 8.0? I tried
> but got these:
> http://pastebin.com/f1cafe40d .

All the time. You didnt mention how you are doing the build, I use

 % make buildworld buildkernel TARGET=i386

You may want to clear out your /usr/obj and try again.


Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: heap limits: mmap(2) vs. break(2) on i386

[Andrew MacIntyre]

Maxim Sobolev wrote:

Jason Evans wrote:


I would set MAXDSIZ to 0, so that the maximum amount of memory is 
available for mapping shared libraries and files, and allocating via 
malloc.  This may cause problems with a couple of ports that implement 
their own memory allocators based on sbrk, but otherwise it should be 
all good.  You might also set /etc/malloc.conf  to 'd' in order to 
disable the sbrk calls.


I see, thank you for the explanation. One of the problem that we are 
having is that we use a lot of interpreted languages in our environment 
(python, php etc), and most of those implement their own memory 
allocators, some of which rely on sbrk(2) unfortunately. I believe 
that's where that 2GB limit of ours comes from - one of our Python 
applications is very memory hungry and we had to bump that limit to 
allow it sufficient room.


While Python has its own allocator, it relies on the platform malloc()
rather than sbrk(), and therefore Jason's suggestion to use '-d' in
/etc/malloc.conf should be effective for it.

--
-----
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andy...@bullseye.apana.org.au  (pref) | Snail: PO Box 370
   andy...@pcug.org.au (alt) |Belconnen ACT 2616
Web:http://www.andymac.org/   |Australia
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

[Fwd: Failure to boot from HD formatted not by FreeBSD]

[Andrew Lankford]

I mentioned that I've set up my laptop to boot using the Windows Vista 
boot menu.  I have, and I needed to copy /boot/boot1 from 7-stable to my 
NTFS partition in order to successfully boot  to my FreeBSD 8.0 
partition.  Last night, I tried replacing the 7-stable boot1 block with 
a version from 8.0-RC1, and now it doesn't successfully boot.  I gather 
from the 8.0 release notes that there have been some changes to some 
part of the boot code.  In any case, I can boot via the Windows boot 
menu with the help of 7-stable's /boot/boot1 file.


Hoping that helps 

Andrew Lankford

 Original Message 
From:   - Thu Oct 22 20:54:06 2009
X-Mozilla-Status:   0001
X-Mozilla-Status2:  0080
X-Mozilla-Keys: 
Message-ID: <4ae0fea5.9070...@charter.net>
Date:   Thu, 22 Oct 2009 20:53:57 -0400
From:   Andrew Lankford 
User-Agent: Thunderbird 2.0.0.23 (X11/20090822)
MIME-Version:   1.0
To: Yuri , freebsd-hackers@freebsd.org
Subject:Failure to boot from HD formatted not by FreeBSD
Content-Type:   text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding:  7bi



Looks to me like you're trying to get your computer to dual-boot Vista 
and FreeBSD 8.0, something I finally succeeded in doing.  If by "MBR" 
you mean the first-stage boot program (512 bytes), I couldn't get that 
to work, nor could I use the standard boot0 menu from FreeBSD.  I'm 
using the windows boot program instead.  I think what I did was copy 
"/boot/boot1" from my root partition to my NTFS partition and then added 
an option to the Windows boot menu to boot with it. 

I get the GEOM "track boundary" complaint when I boot up as well.   The 
FBSD 8.0 kernel has a new option 'GEOM_PART_MBR" on by default.   Vista 
insisted on partitioning my drive, so if the new partition handler 
doesn't like it, it can lump it.  In order to get the 8.0 kernel to 
recognise your old partitions, you need the "GEOM_MBR" option 
activated.  That means you need to load "geom_mbr.ko" into memory before 
you load and boot from the 8.0 kernel.  If you're booting from a FreeBSD 
8.0 CD directly into sysinstall, you can escape to a shell and kldload 
geom_mbr.ko, but you have to then restart sysinstall without rebooting 
the computer in order for your hard disk partitions to show up.  The 
only reliable way I could find to restart systinstall without rebooting 
was by pressing the power button.  Wierd, eh?  I added "option GEOM_MBR" 
back into my kernel, recompiled, fiddled with my network settings, and 
now everything seems to work alright.


Anyway, all this procedure should be 75% correct since I've managed to 
successfully upgrade to 8.0 from 7-stable this way.  For all I know, I 
might end up with a corrupted partition six months from now.  Either 
that or Marcel Moolenar will get angry at me.


Regards,

Andrew Lankford


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: semaphores between processes

[Andrew Gallatin]

Daniel Eischen wrote:



We already use umtx.  This really is a hack and I wouldn't
advocate it.  I'm not sure how you could make it work and
not break existing ability to return appropriate error
codes without slowing down the path in the non-shared
case.  You'd have to check to see if the address space
was shared or not, which would require a system call.


I'm probably missing something.  What does it matter if the
address space is shared, as long as the umtx struct is
in shared memory?

From my quick read, the umtx operations use a lock word
in userspace. For uncontested locks, they use atomic
ops to flip an id into the lock word.  The kernel takes
over for contested locks, and does sleeping, wakup, etc.
Is this correct?  Is there something here that matters
if the address space (and not just the lock word) is
shared?


All our public pthread_foo() symbols are weak.  You
can easily override them in your application code in
the #ifdef freebsd case.  What is wrong with providing
your own library that overrides them to do what you
require - this shouldn't change your application code?



For our code, I was thinking of something like:

#ifdef FreeBSD
#define lock(x) umtx_lock(x, getpid())
#define unlock(x) umtx_unlock(x, getpid())
#else
#define lock(x) pthread_mutex_lock(x)
#define unlock(x) pthread_mutex_lock(x)
#endif


I should probably just shut up and try it..

Drew

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: semaphores between processes

[Andrew Gallatin]

Daniel Eischen wrote:

On Fri, 23 Oct 2009, Andrew Gallatin wrote:


Daniel Eischen wrote:

On Fri, 23 Oct 2009, John Baldwin wrote:


On Thursday 22 October 2009 5:17:07 pm Daniel Eischen wrote:

On Thu, 22 Oct 2009, Andrew Gallatin wrote:


Daniel Eischen wrote:

On Thu, 22 Oct 2009, Andrew Gallatin wrote:


Hi,

We're designing some software which has to lock access to
shared memory pages between several processes, and has to
run on Linux, Solaris, and FreeBSD.  We were planning to
have the lock be a pthread_mutex_t residing in the
shared memory page.  This works well on Linux and Solaris,
but FreeBSD (at least 7-stable) does not support
PTHREAD_PROCESS_SHARED mutexes.

We then moved on to posix semaphores.  Using sem_wait/sem_post
with the sem_t residing in a shared page seems to work on
all 3 platforms.  However, the FreeBSD (7-stable) man page
for sem_init(3) has this scary text regarding the pshared
value:

The sem_init() function initializes the unnamed semaphore 
pointed to

by
sem to have the value value.  A non-zero value for pshared 
specifies

a
shared semaphore that can be used by multiple processes, 
which this

implementation is not capable of.

Is this text obsolete?  Or is my test just "getting lucky"?


I think you're getting lucky.


Yes, after playing with the code some, I now see that. :(


Is there recommended way to do this?


I believe the only way to do this is with SYSV semaphores
(semop, semget, semctl).  Unfortunately, these are not as
easy to use, IMHO.


Yes, they are pretty ugly, and we were hoping to avoid them.
Are there any plans to support either PTHREAD_PROCESS_SHARED
mutexes, or pshared posix semaphores in FreeBSD?


It's planned, just not (yet) being actively worked on.
It's a API change mostly, and then adding in all the
compat hooks so we don't break ABI.


There are also an alternate set of patches on threads@ to allow just 
shared
semaphores I think w/o the changes to the pthread types.  I can't 
recall
exactly what they did, but I think rrs@ was playing with using umtx 
directly

to implement some sort of process-shared primitive.


That's really not the way to go.  The structs really need
to become public.



It would be great if they were, but that discussion was 6 months
ago, and nothing seems to have happened.  Plus we need to support
at least 7.X and probably 6, so any changes here might not even
help us.

What is wrong  with just using umtx directly?  It seems to do
exactly what we need.


Because you can't do anything more than use umtx directly,
like check for mutex types and return appropriate error
codes.  Just look at other implementations - Solaris,
Linux, all have their pthread_*_t as public structs.


I'm not saying that having pthread*t public, and getting all
the features of real PTHREAD_PROCESS_SHARED would not be far
better in general.  But in this case all we need is a lock around
a shared resource.  Eg, nothing fance.  So our choices seem to be
either:

1) use sysv semaphores (ick)
2) use a hand rolled spinlock (ick)
3) use some sort of hack built into our driver (ick, ick)
4) use umtx

Is there some bug or limitation in umtx that makes it inappropriate?
(beyond the obvious, like the potential to leave a resource locked
forever if the lock holder exits).

Thanks,

Drew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: semaphores between processes

[Andrew Gallatin]

Daniel Eischen wrote:

On Fri, 23 Oct 2009, John Baldwin wrote:


On Thursday 22 October 2009 5:17:07 pm Daniel Eischen wrote:

On Thu, 22 Oct 2009, Andrew Gallatin wrote:


Daniel Eischen wrote:

On Thu, 22 Oct 2009, Andrew Gallatin wrote:


Hi,

We're designing some software which has to lock access to
shared memory pages between several processes, and has to
run on Linux, Solaris, and FreeBSD.  We were planning to
have the lock be a pthread_mutex_t residing in the
shared memory page.  This works well on Linux and Solaris,
but FreeBSD (at least 7-stable) does not support
PTHREAD_PROCESS_SHARED mutexes.

We then moved on to posix semaphores.  Using sem_wait/sem_post
with the sem_t residing in a shared page seems to work on
all 3 platforms.  However, the FreeBSD (7-stable) man page
for sem_init(3) has this scary text regarding the pshared
value:

The sem_init() function initializes the unnamed semaphore 
pointed to

by
sem to have the value value.  A non-zero value for pshared 
specifies

a
shared semaphore that can be used by multiple processes, which 
this

implementation is not capable of.

Is this text obsolete?  Or is my test just "getting lucky"?


I think you're getting lucky.


Yes, after playing with the code some, I now see that. :(


Is there recommended way to do this?


I believe the only way to do this is with SYSV semaphores
(semop, semget, semctl).  Unfortunately, these are not as
easy to use, IMHO.


Yes, they are pretty ugly, and we were hoping to avoid them.
Are there any plans to support either PTHREAD_PROCESS_SHARED
mutexes, or pshared posix semaphores in FreeBSD?


It's planned, just not (yet) being actively worked on.
It's a API change mostly, and then adding in all the
compat hooks so we don't break ABI.


There are also an alternate set of patches on threads@ to allow just 
shared

semaphores I think w/o the changes to the pthread types.  I can't recall
exactly what they did, but I think rrs@ was playing with using umtx 
directly

to implement some sort of process-shared primitive.


That's really not the way to go.  The structs really need
to become public.



It would be great if they were, but that discussion was 6 months
ago, and nothing seems to have happened.  Plus we need to support
at least 7.X and probably 6, so any changes here might not even
help us.

What is wrong  with just using umtx directly?  It seems to do
exactly what we need.

Thanks,
Drew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Failure to boot from HD formatted not by FreeBSD

[Andrew Lankford]

Looks to me like you're trying to get your computer to dual-boot Vista 
and FreeBSD 8.0, something I finally succeeded in doing.  If by "MBR" 
you mean the first-stage boot program (512 bytes), I couldn't get that 
to work, nor could I use the standard boot0 menu from FreeBSD.  I'm 
using the windows boot program instead.  I think what I did was copy 
"/boot/boot1" from my root partition to my NTFS partition and then added 
an option to the Windows boot menu to boot with it. 

I get the GEOM "track boundary" complaint when I boot up as well.   The 
FBSD 8.0 kernel has a new option 'GEOM_PART_MBR" on by default.   Vista 
insisted on partitioning my drive, so if the new partition handler 
doesn't like it, it can lump it.  In order to get the 8.0 kernel to 
recognise your old partitions, you need the "GEOM_MBR" option 
activated.  That means you need to load "geom_mbr.ko" into memory before 
you load and boot from the 8.0 kernel.  If you're booting from a FreeBSD 
8.0 CD directly into sysinstall, you can escape to a shell and kldload 
geom_mbr.ko, but you have to then restart sysinstall without rebooting 
the computer in order for your hard disk partitions to show up.  The 
only reliable way I could find to restart systinstall without rebooting 
was by pressing the power button.  Wierd, eh?  I added "option GEOM_MBR" 
back into my kernel, recompiled, fiddled with my network settings, and 
now everything seems to work alright.


Anyway, all this procedure should be 75% correct since I've managed to 
successfully upgrade to 8.0 from 7-stable this way.  For all I know, I 
might end up with a corrupted partition six months from now.  Either 
that or Marcel Moolenar will get angry at me.


Regards,

Andrew Lankford
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: semaphores between processes

[Andrew Gallatin]

Daniel Eischen wrote:

On Thu, 22 Oct 2009, Andrew Gallatin wrote:


Hi,

We're designing some software which has to lock access to
shared memory pages between several processes, and has to
run on Linux, Solaris, and FreeBSD.  We were planning to
have the lock be a pthread_mutex_t residing in the
shared memory page.  This works well on Linux and Solaris,
but FreeBSD (at least 7-stable) does not support
PTHREAD_PROCESS_SHARED mutexes.

We then moved on to posix semaphores.  Using sem_wait/sem_post
with the sem_t residing in a shared page seems to work on
all 3 platforms.  However, the FreeBSD (7-stable) man page
for sem_init(3) has this scary text regarding the pshared
value:

The sem_init() function initializes the unnamed semaphore pointed 
to by
sem to have the value value.  A non-zero value for pshared 
specifies a

shared semaphore that can be used by multiple processes, which this
implementation is not capable of.

Is this text obsolete?  Or is my test just "getting lucky"?


I think you're getting lucky.


Yes, after playing with the code some, I now see that. :(


Is there recommended way to do this?


I believe the only way to do this is with SYSV semaphores
(semop, semget, semctl).  Unfortunately, these are not as
easy to use, IMHO.


Yes, they are pretty ugly, and we were hoping to avoid them.
Are there any plans to support either PTHREAD_PROCESS_SHARED
mutexes, or pshared posix semaphores in FreeBSD?


Thanks,

Drew

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

semaphores between processes

[Andrew Gallatin]

Hi,

We're designing some software which has to lock access to
shared memory pages between several processes, and has to
run on Linux, Solaris, and FreeBSD.  We were planning to
have the lock be a pthread_mutex_t residing in the
shared memory page.  This works well on Linux and Solaris,
but FreeBSD (at least 7-stable) does not support
PTHREAD_PROCESS_SHARED mutexes.

We then moved on to posix semaphores.  Using sem_wait/sem_post
with the sem_t residing in a shared page seems to work on
all 3 platforms.  However, the FreeBSD (7-stable) man page
for sem_init(3) has this scary text regarding the pshared
value:

 The sem_init() function initializes the unnamed semaphore pointed 
to by

 sem to have the value value.  A non-zero value for pshared specifies a
 shared semaphore that can be used by multiple processes, which this
 implementation is not capable of.

Is this text obsolete?  Or is my test just "getting lucky"?

Is there recommended way to do this?

Thanks,

Drew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: namei (via firmware_get(9)) from taskq in 7.x

[Andrew Gallatin]

Kostik Belousov wrote:


It seems that you want a merge of r178042,183614,184842,188057 (one of


Yes,  I finally figured this out on Fri.  I probably should
have posted a response to this thread to avoid others
wasting time on this.

Drew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: crashtar

[Andrew D. Boyd]

Mikolaj Golub wrote:
> On Sat, 10 Oct 2009 12:34:05 +0200 (CEST) Alexander Best wrote:
> 
>  AB> thanks. this is a cool script and very useful indeed. only thing you 
> might
>  AB> want to do is check for root privileges at the beginning to avoid nasty 
> error
>  AB> messages like.
> 
>  AB> awk: can't open file /var/crash/info.0
>  AB>  source line number 12
> 
> In some cases you might not need root privileges. E.g. on some servers I don't
> have root but SA gives me read access to crashdumps. In this case if the
> script had a check for root privileges I would not be able to use it.
> 
> Actually as for me the message looks informative enough, it says that we have
> some problems with accessing crash dump files, so permissions should be
> checked.
> 

Instead of checking for root you could check if the file is readable:

if [ -r FILE ]

and then print an error message.

Although the awk error message is sufficient some people might find this
helpful.

Regards,
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: sysinstall colours

[Andrew D. Boyd]

Ed Schouten wrote:
> * Paul B Mahol  wrote:
>> This have nothing to do with ncurses, colors you like  simple can not
>> be displayed in current syscons(4) and making support for 256 colors
>> or even true bit color in sysinstall(so that it looks amazing in
>> konsole) is waste of time.
> 
> Yes. As of recently, our terminal emulator gained 256 color support, but
> this gets smashed down to 8 colors, simply because Syscons cannot handle
> more than 16 foreground and 8 background colors.
> 
> This is how colors are converted:
> 
>   http://80386.nl/pub/xterm-256.png
>   http://80386.nl/pub/teken-256.png
> 

My God that is hideous. Save us Ed! Three cheers for your recent console
work.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

namei (via firmware_get(9)) from taskq in 7.x

[Andrew Gallatin]

Hi,

I'm trying to re-initialize a NIC which uses firmware(9)
after a hardware fault.  As part of the process, I need
to re-load the firmware using firmware_get().  If the
firmware kld is not resident, then the machine will panic
like this:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x20
fault code  = supervisor read data, page not present
instruction pointer = 0x8:0x805b05d4
stack pointer   = 0x10:0xff880460
frame pointer   = 0x10:0xff880510
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 21 (swi5: +)
[thread pid 21 tid 100021 ]
Stopped at  namei+0x174:movq0x20(%rbx),%rax
db> bt
Tracing pid 21 tid 100021 td 0xff00013c3ae0
namei() at namei+0x174
vn_open_cred() at vn_open_cred+0x3a4
linker_load_module() at linker_load_module+0x1f2
linker_reference_module() at linker_reference_module+0xae
firmware_get() at firmware_get+0x136
mxge_load_firmware() at mxge_load_firmware+0x2d
mxge_watchdog_task() at mxge_watchdog_task+0x2f6
taskqueue_run() at taskqueue_run+0x9d
ithread_loop() at ithread_loop+0x17d
fork_exit() at fork_exit+0x11f
fork_trampoline() at fork_trampoline+0xe

Looking at it in gdb, it seems like the problem is that namei
is trying to use ndp->ni_cnd.cn_thread->td_proc->p_fd->fd_cdir
which is null in this context.

Can somebody tell me what kernel context it is safe to
call firmware_get() (and hence namei) from?  Is there
a safe way to do it from a taskq?

FWIW, this seems to work fine (even from a callout context)
in 8 and higher.  It is only 7 and earlier where I'm having
this problem.

Thanks,
Drew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Make top display thread IDs

[Andrew Brampton]

2009/10/7 Ryan Stone :
> If a thread has a name, top -H will display it in parentheses after
> the executable name.  One option would be to print the tid there if
> the thread has no name.
>

Thanks for your suggestion. I would like the TID always to be
displayed, so displaying it when there is no name wouldn't work for
me. If you haven't looked at the patch I placed the TID directly after
the PID column (when displaying threads in -H mode).

thanks
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Make top display thread IDs

[Andrew Brampton]

Hello,

I was using "top -H" to display all the different threads on my
system. I then wanted to use cpuset to pin a thread to a particular
core, however, I couldn't find the thread ID. So I've hacked top to
display thread IDs. Hopefully this patch is useful to something, and
perhaps it should be included with FreeBSD.

I'd be grateful for any feedback or suggestions.

thanks
Andrew
Index: usr.bin/top/machine.c
===
--- usr.bin/top/machine.c   (revision 197611)
+++ usr.bin/top/machine.c   (working copy)
@@ -108,18 +108,18 @@
 static char smp_header_thr[] =
 "  PID%s %-*.*s  THR PRI NICE   SIZERES STATE   C   TIME %6s COMMAND";
 static char smp_header[] =
-"  PID%s %-*.*s "   "PRI NICE   SIZERES STATE   C   TIME %6s COMMAND";
+"  PIDTID%s %-*.*s PRI NICE   SIZERES STATE   C   TIME %6s 
COMMAND";
 
 #define smp_Proc_format \
-"%5d%s %-*.*s %s%3d %4s%7s %6s %-6.6s %2d%7s %5.2f%% %.*s"
+"%5d%s%s %-*.*s %s%3d %4s%7s %6s %-6.6s %2d%7s %5.2f%% %.*s"
 
 static char up_header_thr[] =
 "  PID%s %-*.*s  THR PRI NICE   SIZERES STATETIME %6s COMMAND";
 static char up_header[] =
-"  PID%s %-*.*s "   "PRI NICE   SIZERES STATETIME %6s COMMAND";
+"  PIDTID%s %-*.*s PRI NICE   SIZERES STATETIME %6s COMMAND";
 
 #define up_Proc_format \
-"%5d%s %-*.*s %s%3d %4s%7s %6s %-6.6s%.0d%7s %5.2f%% %.*s"
+"%5d%s%s %-*.*s %s%3d %4s%7s %6s %-6.6s%.0d%7s %5.2f%% %.*s"
 
 
 /* process state names for the "STATE" column of the display */
@@ -757,7 +757,7 @@
int state;
struct rusage ru, *rup;
long p_tot, s_tot;
-   char *proc_fmt, thr_buf[6], jid_buf[6];
+   char *proc_fmt, tid_buf[8], thr_buf[6], jid_buf[6];
char *cmdbuf = NULL;
char **args;
 
@@ -942,14 +942,19 @@
 
/* format this entry */
proc_fmt = smpmode ? smp_Proc_format : up_Proc_format;
-   if (ps.thread != 0)
+   if (ps.thread) {
thr_buf[0] = '\0';
-   else
+   snprintf(tid_buf, sizeof(tid_buf), "%*d",
+   sizeof(tid_buf) - 1, pp->ki_tid);
+   } else {
+   tid_buf[0] = '\0';
snprintf(thr_buf, sizeof(thr_buf), "%*d ",
sizeof(thr_buf) - 2, pp->ki_numthreads);
+   }
 
sprintf(fmt, proc_fmt,
pp->ki_pid,
+   tid_buf,
jid_buf,
namelength, namelength, (*get_userid)(pp->ki_ruid),
thr_buf,
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: netstat -i Ierrs column, Is it total, or per second?

[Andrew Brampton]

2009/8/31 John Baldwin :
> It should be total and it sounds like a bug in the device driver.  It looks
> like ixgbe_update_stats_counters() overwrites the accumulated value of
> if_ierrors:
>
>        /* Rx Errors */
>        ifp->if_ierrors = total_missed_rx + adapter->stats.crcerrs +
>                adapter->stats.rlec;
>
> It also increments if_ierrors in ixgbe_rxeof().  The driver should only do one
> or the other, but probably not both.
>
> --
> John Baldwin
>

Thanks for your reply. I had wondered that, but looking at
e1000/if_em.c it does a similar thing. However, a quick look at
non-intel drivers and it seems others don't. So perhaps this is a
problem across the intel drivers?

So anyway I spent my afternoon reading the ixgbe spec sheet and
creating the attached patch, which hopefully fixes this problem. I
will forward this patch to freebsd  intel.com unless someone can
point me toward the maintainers email address, or should I just create
a PR?

thanks
Andrew
diff -u ixgbe.old/ixgbe.c ixgbe/ixgbe.c
--- ixgbe.old/ixgbe.c   2009-08-31 18:15:05.0 +0100
+++ ixgbe/ixgbe.c   2009-08-31 19:52:14.0 +0100
@@ -3978,7 +3978,6 @@
 
if (eop) {
rxr->fmp->m_pkthdr.rcvif = ifp;
-   ifp->if_ipackets++;
rxr->rx_packets++;
/* capture data for AIM */
rxr->bytes += rxr->fmp->m_pkthdr.len;
@@ -4000,8 +3999,9 @@
rxr->lmp = NULL;
}
} else {
-   ifp->if_ierrors++;
 discard:
+   adapter->dropped_pkts++;
+
/* Reuse loaded DMA map and just update mbuf chain */
if (hlen) {
mh = rxr->rx_buffers[i].m_head;
@@ -4459,12 +4459,15 @@
u32  missed_rx = 0, bprc, lxon, lxoff, total;
 
adapter->stats.crcerrs += IXGBE_READ_REG(hw, IXGBE_CRCERRS);
+   adapter->stats.illerrc += IXGBE_READ_REG(hw, IXGBE_ILLERRC);
+   adapter->stats.errbc   += IXGBE_READ_REG(hw, IXGBE_ERRBC);
 
for (int i = 0; i < 8; i++) {
int mp;
mp = IXGBE_READ_REG(hw, IXGBE_MPC(i));
missed_rx += mp;
adapter->stats.mpc[i] += mp;
+   adapter->stats.mpctotal += mp;
adapter->stats.rnbc[i] += IXGBE_READ_REG(hw, IXGBE_RNBC(i));
}
 
@@ -4532,8 +4535,11 @@
ifp->if_collisions = 0;
 
/* Rx Errors */
-   ifp->if_ierrors = missed_rx + adapter->stats.crcerrs +
-   adapter->stats.rlec;
+   ifp->if_ierrors = adapter->stats.mpctotal +
+ adapter->stats.crcerrs +
+ adapter->stats.illerrc +
+ adapter->stats.errbc +
+ adapter->stats.rlec;
 }

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

netstat -i Ierrs column, Is it total, or per second?

[Andrew Brampton]

Hi FreeBSD-Hackers,

netstat -i will print out statistics for each interface, including
input/output packets, input/output bytes, and input/output errors. Now
packets and bytes columns seem to be absolute counts, whereas the
errors column seems to be a count over the last second. For example,
when I am filling a link (and then stop), I get output like so:

NameMtu Network   Address  Ipkts IerrsOpkts Oerrs  Coll
ix09000   00:1b:21:20:f9:07 12687951213 432913
1 0 0

ix09000   00:1b:21:20:f9:07 12691545431 435439
1 0 0

ix09000   00:1b:21:20:f9:07 12692054413 434735
1 0 0

ix09000   00:1b:21:20:f9:07 12696499228 300785
1 0 0

ix09000   00:1b:21:20:f9:07 12696499228 01
0 0

As you can see the "Ipkts" value continues to rise, but the "Ierrs"
goes up and down, eventually falling to zero. So my question is,
should this "Ierrs" count be per second?, if so how can I change this
behaviour. I looked at the source code for the driver (ixgbe) and the
OS, looking for every reference to ifp->if_ierrors, but I didn't find
anything that reset this value over time. I also tried a similar
experiment with the e1000 driver but I couldn't get that interface to
list any errors.

I'm running these tests on FreeBSD 8.0-Beta3, but I observed the same
behaviour on FreeBSD 7.2.

Thanks
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

DTrace lockup on a dual processor VMWare

[Andrew Brampton]

have built my own kernel, using all the standard
options and sources, with just the following extra options:
options KDTRACE_FRAME   # Ensure frames are compiled in
options KDTRACE_HOOKS   # Kernel DTrace hooks
options DDB_CTF

options DEVICE_POLLING
options KDB
options KDB_UNATTENDED
options DDB
options GDB
options BREAK_TO_DEBUGGER
options INVARIANTS
options INVARIANT_SUPPORT
options WITNESS
options WITNESS_SKIPSPIN
options DEBUG_MEMGUARD
options HWPMC_HOOKS
device  hwpmc

Can anyone suggest anything to try and debug/fix this problem. I'm
happy to hack the kernel sources if need be.

thanks
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

vm_map_protect / pmap_protect Can't lower protection

[Andrew Brampton]

Hi,
I've been playing with memguard(9) and so far it works well until it
starts to run out of memory. For those who don't know, memguard is a
replacement debugging malloc for the kernel, which is designed to
catch use after free errors. It achieves this by setting any free'd
pages to read-only, therefore any writes to the page should generate a
page fault, and a backtrace allowing you to figure out where your code
is using freed memory. To stop memguard using all your system's RAM
and setting every page to read-only, it begins to recycle previously
freed pages. To do this it must first make the page read-write, and
then return it from malloc.

The problem I am facing is when memguard, unguards a page (ie changes
the page to read-write) it does not actually do this, and the page
remains read-only. I have tracked the problem down but I don't know
how to fix it.

memguard_guard calls vm_map_protect with a read-only flag.
vm_map_protect updates the vm_map_entry, and then calls pmap_protect
to set the actual pte.
pmap_protect successfully sets the pte to read-only and everything
works as it should.

However, memguard_unguard doesn't work correctly. It first calls
vm_map_protect with a read-write flag.
vm_map_protect correctly updates the vm_map_entry, and then calls
pmap_protect to set the actual pte.
pmap_protect is lazy and notices that we are reducing the protection
on the page and therefore does nothing. It assumes that later that a
page fault will occur, call vm_fault, and then fix up the pte then.

The problem I seem to be having is that vm_fault is not called,
because when the page fault occurs, calltrap then trap gets called,
but it falls into trap_fatal because a non-sleepable lock is held.

So my question is, can I call a function which sets the pte in a
non-lazy way? I considered rewriting pmap_protect to do this, but I
thought it be best to do it another way. Another idea I had was to
call vm_fault myself straight after vm_map_protect, but I was unsure
if that was allowed. Also, some googling found the function
pmap_page_protect claims to do what I want, but has long been missing
from FreeBSD.

In case it matters, I'm using FreeBSD 7.2, on a amd64 machine. I've
looked at HEAD and the relevant code looks the same, so I suspect I
will still have problems with that.

thanks for any help
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: kthreads and sched_relinquish

[Andrew Brampton]

2009/5/8 Ryan Stone :
> Your kernel thread likely has a higher priority than userspace threads.
>
> Ryan Stone
>

Thanks for your reply Ryan.

So that I understand this correctly, if I had two kernel threads, one
with a high priority, and one with a low priority, and both are
PRI_TIMESHARE, then the high priority thread will run uninterrupted
until it sleeps? Or is it that kernel threads trumps userspace
threads?

>From my experience in userspace, all threads will get a chance to run,
even if there is a higher priority thread ready to run.

The exact problem I am having is that this code (written by someone
else) has implemented their own spin locks (which of course does not
sleep), so when the lower priority user thread obtains the lock, and
higher priority thread sometimes gets rescheduled before the user
thread has released the lock. Now the high priority thread spins
forever waiting for it to be released, which doesn't seem to give the
lower thread a chance. Of course the correct solution to this is to
remove these custom built spin locks and start to use the locking
mechanisms provided by FreeBSD. While I've started to do that, I
wanted to explore this more for my general understanding.

thanks
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

kthreads and sched_relinquish

[Andrew Brampton]

Hi,
I'm writing a FreeBSD kernel module and I think I really misunderstand
something. My module spawns a thread, which should be running while
the module is loaded. The thread does some work and then should yield
for other threads. However, if there are no other threads waiting,
then I would like to continue to do more work. The problem is that I
am getting weird deadlocks so I wrote a simple test app to ask why
this doesn't work:


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static void test_thread(void *blah) {
unsigned int i = 1; /* Limit the number of iterations */

printf("Test Thread Started\n");

while (i > 0) {
sched_relinquish(curthread);
i--;
}

printf("Test Thread Exited\n");
kthread_exit(0);
}

/* The function called at load/unload. */
static int event_handler(struct module *module, int event, void *arg) {
int e = 0; /* Error, 0 for normal return status */
switch (event) {
case MOD_LOAD:
printf("Test Module Loaded\n");
kthread_create(test_thread, NULL, NULL, 0, 0, "test");
break;
case MOD_UNLOAD:
printf("Test Module Unloaded\n");
break;
default:
e = EOPNOTSUPP; /* Error, Operation Not Supported */
}

return e;
}

/* The second argument of DECLARE_MODULE. */
static moduledata_t test_conf = {
"test_mod", /* module name */
event_handler,  /* event handler */
NULL/* extra data */
};

DECLARE_MODULE(test_mod, test_conf, SI_SUB_DRIVERS, SI_ORDER_MIDDLE);



While my thread is running the rest of the system is unresponsive. The
thread should sched_relinquish() every time round the loop, and from
my understanding that should yield to allow other threads to run, for
example the thread which executes my shell (bash). I suspect my thread
is yielding and getting instantly rescheduled.  I noticed that
poll_idle() in sys/kern_poll.c does something similar to me, but they
first lower their priority. This however has not worked for me, since
my more complex module interacts with higher priority threads and ends
up deadlocking.

So I just want to ask, Why does this example code lock the system? Am
I using sched_relinquish correctly? Or should I be doing something
else? I did try using tsleep(...,1), but I don't want my thread
sleeping if there are no other threads waiting.

I would also be grateful if people could point me at other examples in
the kernel where something like this is done. I have looked in quite a
few places, but I can't see why my simple app is wrong.

thanks
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Definition of NULL

[Andrew Brampton]

2009/5/2 Erik Trulsson :
> On Sat, May 02, 2009 at 04:59:03PM +0100, Andrew Brampton wrote:
>> I'm writing a C++ Kernel Module, and one thing that has been bugging
>> me is the kernel's definition of NULL.
>
> Is the use of C++ inside the kernel really supported?  I don't think so,
> but I could be wrong.

There are a few projects (other than mine) which uses C++ inside the
kernel, the biggest being the Click modular router.  So, with minimal
effort and no kernel patches it is easy to build a C++ kernel module,
thus I must assume it is supported even if it is unofficial. The
question of if C++ is sensible inside the kernel is left for another
day, and perhaps has been answered in numerous other freebsd-hackers@
threads.

>> >From what I've read online the definition of NULL in C is (void *)0,
>> whereas in C++ it should be 0, or 0L (on 64bit machines).
>
> Not quite.  Any of those (as well as a whole bunch more) are legal
> definitions of NULL in C.  NULL is defined (in the C standard) to be a null
> pointer constant.  A null pointer constant is defined as a constant integer
> expression with value zero, or such an expression cast to (void*). (In C++
> it the cast to (void*) is not allowed.)
> This means that it would be perfectly legal (but of dubious utility) to have
> NULL defined as (5*5L+('1'-'0')-26) for example.
>
> The decision to define NULL as 0 or 0L or ((void*)0) is pretty much just a
> question of which buggy programs one wishes to break, or hide the bugs in.
> A correct C program should work regardless of which of those is used.

Thanks for the additional information.

>
>
>>
>> Now, my C++ kernel module is built with _KERNEL definited, like any
>> other C kernel module. This leads to NULL being defined incorrectly.
>>
>> So I have a question and two suggestions. Firstly, why is the #if
>> defined(_KERNEL) in _null.h? Is it to stop userland application
>> applications picking up this definition? Or for another reason?
>
> Perhaps to stop people from mistakenly using C++ inside the kernel?

The definition doesn't stop C++, it just generates additional warnings
and sometimes errors. I have avoided those warning by defining NULL
myself, however, I thought changing it in _null.h might help others,
even if you think they are mistakenly using C++.

>
> ...
>
> Erik Trulsson
> ertr1...@student.uu.se
>

Thanks for your input.

Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Definition of NULL

[Andrew Brampton]

I'm writing a C++ Kernel Module, and one thing that has been bugging
me is the kernel's definition of NULL.

sys/sys/_null.h (in CURRENT):

#if defined(_KERNEL) || !defined(__cplusplus)
#define NULL((void *)0)
#else
#if defined(__GNUG__) && defined(__GNUC__) && __GNUC__ >= 4
#define NULL__null
#else
#if defined(__LP64__)
#define NULL(0L)
#else
#define NULL0
#endif  /* __LP64__ */
#endif  /* __GNUG__ */
#endif  /* _KERNEL || !__cplusplus */

>From what I've read online the definition of NULL in C is (void *)0,
whereas in C++ it should be 0, or 0L (on 64bit machines).

Now, my C++ kernel module is built with _KERNEL definited, like any
other C kernel module. This leads to NULL being defined incorrectly.

So I have a question and two suggestions. Firstly, why is the #if
defined(_KERNEL) in _null.h? Is it to stop userland application
applications picking up this definition? Or for another reason?

and two, how about we change the first line of _null.h so that we use
a && instead of a || like so:
#if defined(_KERNEL) && !defined(__cplusplus)

That should ensure the definition is correct. Or, a more radical
approach, we could remove the check for _KERNEL, since I can't figure
out why it is needed and do something like:

#if defined(__GNUG__) && defined(__GNUC__) && __GNUC__ >= 4
# define NULL__null
#elif !defined(__cplusplus)
# define NULL((void *)0)
#elif defined(__LP64__)
# define NULL(0L)
#else
# define NULL0
#endif

That way, if we are using GCC 4+ we use their __null definition,
otherwise if we are not c++ we use the standard (void *)0, and then if
we are 64bit we use 0L, and finally anything else uses 0. A quick
amd64 kernel compile seems to allow my new definition

I hope this makes sense, and I welcome all feedback.
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD memguard + spinlocks

[Andrew Brampton]

2009/4/11 Robert Watson :
> On Sat, 11 Apr 2009, Andrew Brampton wrote:
>
> Your understanding is mostly right.  The missing bit is this: there are two
> kinds of interrupt contexts -- fast/filter interrupt handlers, which borrow
> the stack and execution context of the kernel thread they preempt, and
> interrupt threads, which get their own complete thread context.
>
> Fast interrupt handlers are allowed unlock to acquire spinlocks so as to
> avoid deadlock because of the borrowed context.  This means they can't
> perform any sort of sleep, or acquire any locks that might sleep, since the
> thread they've preempted may hold conflicting locks, or be the one that
> would have woken up the sleep that the handler performed.  Almost no code
> will run in fast handlers -- perhaps checking some device registers, doing
> work on a lockless or spinlock-protected queue, and waking up a worker
> thread.
>
> This is why, BTW, spin locks disable interrupt: they need to control
> preemption by other interrupt handlers to avoid deadlock, but they are not
> intended for use except when either in the scheduler, in a few related IPI
> contexts, or when synchronizing between normal kernel code and a fast
> handler.
>
> Full interrupt thread contexts are permitted to perform short lock sleeps,
> such as those performed when contending default mutexes, rwlocks, and
> rmlocks. They are permitted to invoke kernel services such as malloc(9),
> UMA(9), the network stack, etc, as long as they use M_NOWAIT and don't
> invoke msleep(9) or similar unbounded sleeps -- again to avoid the
> possibility of deadlocks, since you don't want an interrupt thread sleeping
> waiting for an event that only it can satisfy.
>
> So the first question, really, is whether you are or mean to be using
> fast/filter interrupt handler.  Device drivers will never call memory
> allocation, free, etc, from there, but will defer it to an ithread using the
> filter mechanism in 8.x, or to a task queue or other worker in 7.x and
> earlier.  If you're using a regular INTR_MPSAFE ithread, you should be able
> to use only default mutexes (a single atomic operation if uncontended)
> without disabling interrupts, etc.
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
>

Thanks very much for your detailed reply. I'm slowly understanding how
everything in FreeBSD fits together, and I appreciate your help.

I've been given a project to take over, and all of the design
decisions were made before I started working on it, thus I'm playing
catch up. One of the decisions was to implement their own version of a
spin lock, which literally looks something like this:

lock_aquire() {
  critical_enter();
  while (! lockHeld ) {}
  lockHeld++;
}

This was actually the code tripping up MemGuard, as it is inside a
critical section, which MemGuard is unable to sleep within. This is
all running inside a kthread_create thread (I'm unsure of the proper
name of this type of thread).

Anyway, that is why I also asked about a lighter weight spin lock
(perhaps similar to this one). I tempted to replace this custom
spinlock with the standard MTX_DEF, however I'm unsure of its impact.
The custom spin lock seems quick and light to acquire, and it does not
concern me that a interrupt can potentially interrupt the code.

On a related note, if you change the lock in memguard to a MTX_SPIN,
it panics the kernel during boot. So that is not an option :) I was
only using memguard because I suspected memory being used after it was
freed. However, I think I will either change my locks to MTX_DEF or
live without memguard.

I realise I've not really asked any questions, but I would be grateful
for any insights anyone may have.
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

FreeBSD memguard + spinlocks

[Andrew Brampton]

Hi,
I'm having a problem with memguard(9) on FreeBSD 7.1 but before I ask
about that I just need to check my facts about malloc.

When in interrupt context malloc must be called with M_NOWAIT, this is
because I can't sleep inside a interrupt. Now when I hold a spinlock
(MTX_SPIN) I am also not allowed to sleep or obtain a sleepable mutex
(such as MTX_DEF). So I assume while holding a spin lock any mallocs I
do must have the M_NOWAIT flag? This was not clear from the manual
pages, but at least makes sense to me.

So my problem with memguard stems from the fact that I am locking a
spinlock, and then I'm calling malloc with M_NOWAIT. But inside
memguard_alloc a MTX_DEF is acquired causing WITNESS to panic.

So I think fundamental memguard is flawed and should be using MTX_SPIN
instead of MTX_DEF otherwise it can't be called from inside a
interrupt or when a spin lock is held. But maybe I'm missing
something?

Also on a related note, I see that MTX_SPIN disables interrupts,
making it a rather "heavy" spinlock. Is there a lighter spin lock that
literally just spins? I read that MTX_DEF are far quicker to acquire ,
but surely a light spinlock would be easier to acquire than sleeping?

I think for the moment I will fix my code by not using a MTX_SPIN
(since the code is not in a interrupt), however, I think memguard
should change its lock.

thanks
Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: pahole - Finding holes in kernel structs

[Andrew Brampton]

2009/2/12 Kostik Belousov :
> On Thu, Feb 12, 2009 at 02:08:22PM +0000, Andrew Brampton wrote:
>>
>> So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that
> Did you ported it to FreeBSD, or run on the Linux host ?
>

Sorry no, I just ran it from a Linux host, but to my surprised it
seemed to work fine.

Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

pahole - Finding holes in kernel structs

[Andrew Brampton]

I found this useful tool called pahole[1]. It basically finds holes
within structs, so for example on my 64bit machine this struct:

struct test {
   int foo;
   const char *bar;
   int blah;
}

Would have a hole between foo and bar of 4 bytes because both for and
bar have been aligned on a 8 byte boundary, and the struct would also
have 4 bytes of padding on the end. However, if I simply moved blah
between foo and bar then the struct has shrunk by 8 bytes, which could
be a good thing. This could also help keep structs within single cache
lines, and just generally keep memory usage to a minimum when the
struct is used many times (for example in an array).

So I ran the tool pahole over a 7.1 FreeBSD Kernel, and found that
many of the struct had holes, and some of which could be rearranged to
fill the gap. I've made the list available here[2]. So my questions
are two fold:

1) Is it worth my time trying to rearrange structs? If so do you think
many of my patches would be accepted?

2) Is there a way to find out the most heavily used structs? There are
~3600 structs, and ~2000 holes, it might be a waste of my time fixing
the structs which are only used once.

thanks
Andrew

[1] http://lwn.net/Articles/206805/
[2] http://bramp.net/projects/kernel.pahole.bz2 (~260kB)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: CFT: Graphics support for /boot/loader

[Andrew Thompson]

On Thu, Feb 05, 2009 at 11:18:36PM +0100, Oliver Fromme wrote:
> Hello fellow hackers,
> 
> Some of you might remember that I'm working on graphics
> support for our /boot/loader.  Unfortunately, progress has
> been rather slow because of non-FreeBSD-related activity.
> 
> Anyway, I have now prepared a tarball containing a loader
> binary for public testing.  If you are eager to give it a
> try, please feel free to do so.  It should work with any
> FreeBSD version on i386 and amd64 platforms.
> 
> I have posted detailed instructions on the FreeBSD wiki:
> 
> http://wiki.freebsd.org/OliverFromme/BootLoaderTest
> 
> Any kind of feedback is welcome.

Works well here, tried various combinations of the options. This is very
cool.


Andrew
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"