I built a KLD with multiple firmware images, as shown here:
KMOD=foo
FIRMWS= foo.bin:foo:1.0.0.0
FIRMWS+=bar.bin:bar:1.0.0.0
FIRMWS+= ...
.include
"foo" is the parent firmware and a firmware_get(foo) can autoload the
KLD. "bar" and the rest are available only if the KLD is loaded (by
whatever m
On Wed, Nov 2, 2011 at 1:44 PM, Garrett Cooper wrote:
> On Wed, Nov 2, 2011 at 12:56 PM, Navdeep Parhar wrote:
>> I built a KLD with multiple firmware images, as shown here:
>>
>> KMOD=foo
>> FIRMWS= foo.bin:foo:1.0.0.0
>> FIRMWS+=bar.bin:bar:1.0.0.0
>> F
On Tue, Nov 08, 2011 at 10:00:27AM -0500, John Baldwin wrote:
> On Wednesday, November 02, 2011 3:56:29 pm Navdeep Parhar wrote:
> > I built a KLD with multiple firmware images, as shown here:
> >
> > KMOD=foo
> > FIRMWS= foo.bin:foo:1.0.0.0
> > FIRMW
There seems to be a regression in 8.3 in the way the kernel selects CPUs
for interrupts. For example, cxgb(4) on 8.3 ends up with all
its ithreads on the same CPU (CPU7 in this case).
12 root -68- 0K 816K WAIT7 0:55 0.00% intr{irq279:
cxgbc0}
12 root -68- 0K 8
On 05/02/12 14:28, Ryan Stone wrote:
On Wed, May 2, 2012 at 5:16 PM, Navdeep Parhar wrote:
There seems to be a regression in 8.3 in the way the kernel selects CPUs
for interrupts. For example, cxgb(4) on 8.3 ends up with all
its ithreads on the same CPU (CPU7 in this case).
12 root -68
On 05/02/12 14:44, Ryan Stone wrote:
On Wed, May 2, 2012 at 5:39 PM, Navdeep Parhar wrote:
I will try it. But would this explain why it used to work with 8.2 but
broke in 8.3?
Navdeep
If other driver changed between 8.2 and 8.3 to start binding intr
threads to CPUs then your driver would
On 05/02/12 14:48, Navdeep Parhar wrote:
On 05/02/12 14:44, Ryan Stone wrote:
On Wed, May 2, 2012 at 5:39 PM, Navdeep Parhar wrote:
I will try it. But would this explain why it used to work with 8.2 but
broke in 8.3?
Navdeep
If other driver changed between 8.2 and 8.3 to start binding intr
On 05/04/12 10:05, Wojciech Puchar wrote:
cxgbc0}
12 root -68 - 0K 816K WAIT 7 0:31 0.00% intr{irq280: cxgbc0}
Back in the day there used to be code in cxgb to bind different
interrupts to different CPUs but it was removed because the kernel
distributed them across CPUs anyway. So what changed?
I have a system with multiple cards supported by cxgbe(4). When I build
a kernel with the driver compiled in, it attaches to the cards in a
different order from when it's loaded as a module. Why? The network
interfaces get re-ordered and this is quite annoying.
Regards,
Navdeep
built-in:
t
On a very recent clang-built HEAD, I see that some static structures
have a ".n" appended to their name. For example, this declaration in
the cxgbe driver now results in a t4_list.0 symbol in the KLD:
static SLIST_HEAD(, adapter) t4_list;
# nm if_cxgbe.ko | grep t4_list
0020 b t4_li
. It is only making things harder for
debuggers.
Regards,
Navdeep
>
> I dont know why scsi_low_statics is there multiple times.
>
> On Fri, Nov 16, 2012 at 12:36:13PM -0800, Navdeep Parhar wrote:
>> On a very recent clang-built HEAD, I see that some static structures
>>
On Sun, Nov 18, 2012 at 02:37:11PM +0100, Dimitry Andric wrote:
> On 2012-11-16 23:04, Navdeep Parhar wrote:
> >On 11/16/12 13:49, Roman Divacky wrote:
> >>Yes, it does that. iirc so that you can have things like
> >>
> >>void foo(int cond) {
> >
I build kernel-toolchain and MAKE_JUST_KERNELS (often with NO_CLEAN, but
not this time) as part of my pre-commit checklist. It doesn't seem to
work after the switch to bmake. What am I missing? This on a system
at r251171 with nothing in make.conf or src.conf:
# make -j12 universe UNIVERSE_TARG
On 05/30/13 18:43, Navdeep Parhar wrote:
> I build kernel-toolchain and MAKE_JUST_KERNELS (often with NO_CLEAN, but
> not this time) as part of my pre-commit checklist. It doesn't seem to
> work after the switch to bmake. What am I missing? This on a system
> at r25117
On 06/03/13 14:20, Eitan Adler wrote:
> On 3 June 2013 23:13, Navdeep Parhar wrote:
>> On 05/30/13 18:43, Navdeep Parhar wrote:
>>> I build kernel-toolchain and MAKE_JUST_KERNELS (often with NO_CLEAN, but
>>> not this time) as part of my pre-commit checklist. It doe
On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote:
> On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote:
> > on 21/06/2010 18:43 John Baldwin said the following:
> > > np@ has a patch to gdb to fix this for kgdb. I haven't committed it as
> > > it
> > > patched gdb internals and wa
On Tue, Jun 22, 2010 at 12:34:49AM +0300, Andriy Gapon wrote:
> on 21/06/2010 23:44 Navdeep Parhar said the following:
> > On Mon, Jun 21, 2010 at 04:10:45PM -0400, John Baldwin wrote:
> >> On Monday 21 June 2010 11:57:17 am Andriy Gapon wrote:
> >>> on 21/06/20
Hello everyone,
I'm looking for the fastest way to get a full mercurial repository of
HEAD.
I tried using hgsvn and the tree at http://svn.freebsd.org/base/head
but it looks like the first hgpullsvn operation will take days (literally):
$ hgimportsvn http://svn.freebsd.org/base/head
$ cd head
$
>> Hello everyone,
>>
>> I'm looking for the fastest way to get a full mercurial repository of
>> HEAD.
>>
>> I tried using hgsvn and the tree at http://svn.freebsd.org/base/head
>> but it looks like the first hgpullsvn operation will take days (literally):
>>
>> $ hgimportsvn http://svn.freebsd.or
Hello everyone,
The add-kld command in kgdb does not work as expected on amd64
(I'm using a recent HEAD, problem may affect others too). It uses
the same address for all sections:
(kgdb) add-kld if_cxgb.ko
add symbol table from file "/boot/kernel/if_cxgb.ko" at
.text_addr = 0x810
Hello John,
The patch did NOT fix the problem. Read on for more
On Wed, Sep 17, 2008 at 8:31 AM, John Baldwin <[EMAIL PROTECTED]> wrote:
> On Tuesday 16 September 2008 04:07:46 pm Navdeep Parhar wrote:
>> Hello everyone,
>>
>> The add-kld command in kgdb does no
> Well, this means gdb can't handle loading .o's, though I guess that is to be
> expected. :( Even if I fix add-kld there's probably no way I can easily fix
> the sharedlibrary stuff w/o ripping gdb itself up a bunch.
>
> --
> John Baldwin
>
I thought I'd leave this patch here on the list in case
On Tue, Oct 7, 2008 at 10:53 AM, alan yang <[EMAIL PROTECTED]> wrote:
> Could people shed some light how to get remote debugging going, must
> be something that i overlooked, really appreciate.
>
Do you have the right flags for sio or uart in /boot/device.hints? I
have this (for a recent HEAD)::
This may interest puc and uart maintainers.
I needed an extra serial port on my FreeBSD machine and bought a
store-branded "1-Port Serial PCI Adapter" from a local computer
store.
This is what pciconf shows:
p...@pci0:4:1:0: class=0x070002 card=0x00011000 chip=0x98359710
rev=0x01 hdr=0x00
And he
On Tue, Mar 03, 2009 at 09:04:32AM -0800, Marcel Moolenaar wrote:
>
> On Mar 3, 2009, at 8:59 AM, John Baldwin wrote:
>
>> On Tuesday 03 March 2009 11:48:42 am Marcel Moolenaar wrote:
>>>
>>> On Mar 3, 2009, at 6:15 AM, John Baldwin wrote:
>>>
> diff -r 025cb00d19d7 sys/dev/puc/puc.c
> ---
On Tue, Mar 3, 2009 at 11:51 AM, Navdeep Parhar wrote:
> On Tue, Mar 03, 2009 at 09:04:32AM -0800, Marcel Moolenaar wrote:
>>
>> On Mar 3, 2009, at 8:59 AM, John Baldwin wrote:
>>
>>> On Tuesday 03 March 2009 11:48:42 am Marcel Moolenaar wrote:
>>>>
>
It appears that the KLD build process is missing a ctfmerge at the end, and
this results in KLDs with incomplete CTF information.
Here is a patch that fixes this. I verified it on amd64 with various KLDs.
Before:
# ctfdump /boot/kernel/if_cxgb.ko | wc -l
2269
# ctfdump /boot/kernel/zfs.ko | wc
objdump -h shows that most, but not all, KLDs on amd64 have a "set_pcpu"
section of size 0. Why? What is the difference between having a 0
sized set_pcpu vs. not having it at all?
The kernel linker considers the alignment requirements of these empty
sections and advances mapsize/mapbase. This b
On Fri, Nov 27, 2009 at 08:51:41AM +, Bjoern A. Zeeb wrote:
> On Tue, 24 Nov 2009, Navdeep Parhar wrote:
>
> Hi,
>
> >objdump -h shows that most, but not all, KLDs on amd64 have a "set_pcpu"
> >section of size 0. Why? What is the difference between ha
29 matches
Mail list logo
