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

[Andrew Turner]

On Thu, 27 Jun 2013 13:06:07 +0200
Dimitry Andric dimi...@andric.com 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=revisionrevision=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 - ATT 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 lich...@gmail.com 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 m...@mired.org wrote:
 On Mon, 17 Sep 2012 11:40:33 -0500
 Zhihao Yuan lich...@gmail.com 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
 --
 Mike Meyer m...@mired.org  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 z...@freebsd.org 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: 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 a...@freebsd.org wrote:
 
 on 12/07/2012 21:17 Fabian Keil said the following:
 Benjamin Kaduk ka...@mit.edu 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: /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: 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

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

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 kient...@freebsd.org 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]

 Andy Young ayo...@mosaicarchive.com 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

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]

 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

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 jul...@freebsd.org 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-**hackershttp://lists.freebsd.org/mailman/listinfo/freebsd-hackers
 To unsubscribe, send any mail to freebsd-hackers-unsubscribe@**
 freebsd.org 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: 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 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: 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: 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 l...@foolishgames.com, 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 e...@80386.nl
  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 gre...@freebsd.org 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 gre...@freebsd.org 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

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

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: a3d64dc0-58c3-451b-b85f-0072bb069...@bsdimp.com
X-Mozilla-Status:   0011
X-Mozilla-Status2:  
X-Mozilla-Keys: 
Return-Path:i...@bsdimp.com
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 
lankfordand...@charter.net; 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 i...@bsdimp.com
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: a3d64dc0-58c3-451b-b85f-0072bb069...@bsdimp.com
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 Loshi...@bsdimp.com  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

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

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

[Andrew Turner]

On Sun, 27 Mar 2011 22:07:30 +0200
Stefan Farfeleder ste...@fafoe.narf.at 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
  wchar.h and machine/_stdint.h. 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 wchar.h and stdint.h shall
 define WCHAR_MIN and WCHAR_MAX. You cannot simply include
 machine/_stdint.h from wchar.h because the former contains a lot
 of other macros.
I thought that might be the case. I could create machine/_wchar.h 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

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

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
machine/_types.h 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 wchar.h
and machine/_stdint.h. 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 arun...@freebsd.org 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 m...@my.gd 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 j...@berklix.com:
 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=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT
  Features2=0x802009SSE3,MON,CX16,POPCNT
  AMD 
Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!
  AMD 
Features2=0x37ffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT
  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 yanef...@gmail.com wrote:
 On Sun, Jun 20, 2010 at 3:06 PM, Stathis Kamperis ekamp...@gmail.com wrote:
 2010/6/21 Garrett Cooper yanef...@gmail.com:
    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 kostik...@gmail.com 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 kime...@gmail.com 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 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: 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 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: ATA 4K sector issues

[Andrew Stesin]

2010/3/17 Matthew Dillon dil...@apollo.backplane.com:
    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 n...@opensesame.st 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

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: sysctl with regex?

[Andrew Brampton]

2010/2/9 Dag-Erling Smørgrav d...@des.no:
 Andrew Brampton brampton+free...@gmail.com 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

Re: sysctl with regex?

[Andrew Brampton]

On Wed, Feb 10, 2010 at 12:14 AM, Garrett Cooper yanef...@gmail.com 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]

On Wed, Feb 10, 2010 at 12:51 AM, Garrett Cooper yanef...@gmail.com 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: 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

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

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; currently c

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

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

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:



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

[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 lankfordand...@charter.net
User-Agent: Thunderbird 2.0.0.23 (X11/20090822)
MIME-Version:   1.0
To: Yuri y...@rawbw.com, 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

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

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

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

[Andrew D. Boyd]

Ed Schouten wrote:
 * Paul B Mahol one...@gmail.com 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

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: Make top display thread IDs

[Andrew Brampton]

2009/10/7 Ryan Stone ryst...@gmail.com:
 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 %-*.*sPRI 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 %-*.*sPRI 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

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 Link#4  00:1b:21:20:f9:07 12687951213 432913
1 0 0
wait a second
ix09000 Link#4  00:1b:21:20:f9:07 12691545431 435439
1 0 0
wait a second
ix09000 Link#4  00:1b:21:20:f9:07 12692054413 434735
1 0 0
wait a second and traffic has stopped
ix09000 Link#4  00:1b:21:20:f9:07 12696499228 300785
1 0 0
wait a second
ix09000 Link#4  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

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

[Andrew Brampton]

2009/8/31 John Baldwin j...@freebsd.org:
 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 at 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

DTrace lockup on a dual processor VMWare

[Andrew Brampton]

VMWare it prints out:
 hotkernel
Sampling... Hit Ctrl+C to end
dtrace: buffer size lowered to 1m
dtrace: aggregation size lowered to 1m

When I run it on the dual-processor VMWare it only prints
 hotkernel
Sampling... Hit Ctrl+C to end

So I suspect it is locking up before it gets to the code that prints
buffer size lowered.

Additionally, I 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 ryst...@gmail.com:
 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 sys/param.h
#include sys/module.h
#include sys/kernel.h
#include sys/cdefs.h
#include sys/proc.h
#include sys/pcpu.h
#include sys/kthread.h
#include sys/sched.h
#include sys/systm.h

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

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: Definition of NULL

[Andrew Brampton]

2009/5/2 Erik Trulsson ertr1...@student.uu.se:
 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

Re: FreeBSD memguard + spinlocks

[Andrew Brampton]

2009/4/11 Robert Watson rwat...@freebsd.org:
 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

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: pahole - Finding holes in kernel structs

[Andrew Brampton]

2009/2/12 Kostik Belousov kostik...@gmail.com:
 On Thu, Feb 12, 2009 at 02:08:22PM +, 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

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