Re: Upgrading, 11.4 -> 12.1

[Navdeep Parhar]

On 8/31/20 12:44 PM, George Mitchell wrote:
> 1. Is there a way to shut "make delete-old" up?  For most minor
> upgrades, of course, it never says anything.  But for an upgrade such
> as this, it forces me to type "y" upwards of a hundred times.
> All the things it's deleting look plausible to me and I've never had
> occasion to tell it NOT to delete a file.  Is there a way to tell it
> to just assume "y"?

Use "make -DBATCH_DELETE_OLD_FILES ...".  See build(7) for details.

Regards,
Navdeep
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: support of PCIe NVME drives

[Navdeep Parhar]

On 4/16/20 12:30 PM, Miroslav Lachman wrote:
> Pete Wright wrote on 04/16/2020 20:23:
>>
>>
>> On 4/16/20 11:12 AM, Miroslav Lachman wrote:
>>> Kurt Jaeger wrote on 04/16/2020 20:07:
> 
>> I would try booting via UEFI if you can.  I just installed a laptop
>> yesterday which has a nvme root device, it was detected by the
>> 12-STABLE snapshot I used to boot from.  no other modifications were
>> necessary on my end.
> 
> I changed BIOS settings to use UEFI boot method, booted 12.1 installer
> ISO but without luck. Still no NVME disks :(
> 
> You can see it on printscreen from iDRAC https://ibb.co/tPnymL7
> 
> Anything more I can test?

Does the nvme controller show up in pciconf -l?

# pciconf -l | grep nvme

Regards,
Navdeep

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

Re: Kernel panic, stable/12 r341604, swapon -a in SU mode, geli encrypted swap, Chelsio T6225-CR, and ccr(4)

[Navdeep Parhar]

Can you please file a bug at https://bugs.freebsd.org/bugzilla/ and
assign it to me?

Regards,
Navdeep

On 12/6/18 4:02 AM, Trond Endrestøl wrote:
> After booting stable/12 r341604, running a custom kernel including 
> cxgbe(4), cxgbev(4), and ccr(4), and running swapon -a in SU mode:
> 
> GEOM_ELI: Device gpt/swap0.eli created.
> GEOM_ELI: Encryption: AES-XTS 256
> GEOM_ELI: Crypto: hardware
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 06
> fault virtual address   = 0x0
> fault code  = supervisor write data, page not present
> instruction pointer = 0x20:0x805be1b2
> stack pointer   = 0x28:0xfe00a6253770
> frame pointer   = 0x28:0xfe00a6253770
> 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 = 65 (g_eli[3] gpt/swap0)
> trap number = 12
> panic: page fault
> cpuid = 3
> time = 1544087308
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0x8055d9eb = 
> db_trace_self_wrapper+0x2b/frame 0xfe00a6253420
> vpanic() at 0x808754d3 = vpanic+0x1a3/frame 0xfe00a6253480
> panic() at 0x80875323 = panic+0x43/frame 0xfe00a62534e0
> trap_fatal() at 0x80bd745f = trap_fatal+0x35f/frame 0xfe00a6253530
> trap_pfault() at 0x80bd74b9 = trap_pfault+0x49/frame 
> 0xfe00a4b7f590
> trap() at 0x80bd6ade = trap+0x29e/frame 0xfe00a4b7f6a0
> calltrap() at 0x80bb3935 = calltrap+0x8/frame 0xfe00a4b7f6a0
> --- trap 0xc, rip = 0x805be1b2, rsp = 0xfe00a4b7f770, rbp = 
> 0xfe00a4b7f770
> t4_wrq_tx_locked() at 0x805be1b2 = t4_wrq_tx_locked+0x12/frame 
> 0xfe00a6253770
> ccr_process() at 0x805e3fc3 = ccr_process+0x1953/frame 
> 0xfe00a4b7f970
> crypto_dispatch() at 0x80ae3fa4 = crypto_dispatch+0x144/frame 
> 0xfe00a4b7f9b0
> g_eli_crypto_run() at 0x807b5cb3 = g_eli_crypto_run+0x273/frame 
> 0xfe00a4b7fa10
> g_eli_worker() at 0x807aebc8 = g_eli_worker+0x3c8/frame 
> 0xfe00a4b7fa70
> fork_exit() at 0x80834d93 = fork_exit+0x83/frame 0xfe00a4b7fab0
> fork_trampoline() at 0x80bb491e = fork_trampoline+0xe/frame 
> 0xfe00a4b7fab0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> Uptime: 14s
> Automatic reboot in 15 seconds - press a key on the console to abort
> --> Press a key on the console to reboot,
> 
> The Chelsio NIC is a T6225-CR.
> 
> Kernel config is 
> https://ximalas.info/~trond/create-zfs/canmount/ENTERPRISE-amd64-stable-12
> 
> I tried stable/12 r341623 with ccr(4) removed from the kernel, and I 
> had no problems engaging geli encrypted swap in SU mode nor in normal 
> mode.
> 
> Has anyone else tried ccr(4) on recent stable/12?
> Are we discouraged from using ccr(4)?
> I was hoping to take advantage of the crypto accelerator.
> 


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

Re: [HEADS UP] - OFED/RDMA stack update

[Navdeep Parhar]

iw_cxgbe still doesn't build in the branch because of some socket
changes in head that are not in 11.  I need to add the 11 equivalent of
the dequeue_socket code to iw_cxgbe to get it to compile, and then try
it to see if it actually works.

Regards,
Navdeep

On 03/22/2018 04:36, Meny Yossefi wrote:
> Hi Navdeep, 
> 
> What's the current iWARP status on the project branch? 
> If it's ready we'd like to merge it to FreeBSD11-STABLE immediately. 
> 
> -Meny
> 
> 
> -Original Message-
> From: Navdeep Parhar [mailto:npar...@gmail.com] On Behalf Of Navdeep Parhar
> Sent: Tuesday, March 20, 2018 10:08 PM
> To: Hans Petter Selasky <h...@selasky.org>; Konstantin Belousov 
> <k...@freebsd.org>; 'freebsd-infinib...@freebsd.org' 
> <freebsd-infinib...@freebsd.org>; freebsd-drivers 
> <freebsd-driv...@mellanox.com>; Meny Yossefi <me...@mellanox.com>; 
> 'FreeBSD-stable@FreeBSD.org' <FreeBSD-stable@FreeBSD.org>; freebsd-arch 
> <freebsd-a...@freebsd.org>
> Subject: Re: [HEADS UP] - OFED/RDMA stack update
> 
> On 03/17/2018 13:03, Hans Petter Selasky wrote:
>> On 03/17/18 20:52, Navdeep Parhar wrote:
>>> Hold your horses.  Do you have confirmation from the affected party 
>>> that the shims are adequate for them?  I have been waiting for that 
>>> before looking at this branch.
>>
>> Hi Navdeep,
>>
>> Mellanox has received an API list from at least one party, and has 
>> taken the action to support all the required APIs.
>>
>>> Is the iw_cxgbe breakage a simple merge conflict as previously 
>>> discussed or do the shims require driver changes?
>>
>> It is a merge conflict. The code already compiles in 12-current.
> 
> I tried backing out r329391 and r329017 in a local copy and then was able to 
> merge r320418, r323082, and r326169 in that order without any conflicts.  But 
> iw_cxgbe/cm.c still doesn't compile in the projects branch because it has 
> some socket code that relies on some of glebius's changes available only in 
> head (I checked with him and they aren't MFC'able).  I'm trying to figure out 
> what to do about those.
> 
> And what about the cxgb breakage?  Is there any simple way to make an old 
> style driver work with the new stack?  T3 iw_cxgb in head was retired before 
> the ofed overhaul.
> 
> Regards,
> Navdeep
> 


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

Re: [HEADS UP] - OFED/RDMA stack update

[Navdeep Parhar]

On 03/17/2018 13:03, Hans Petter Selasky wrote:
> On 03/17/18 20:52, Navdeep Parhar wrote:
>> Hold your horses.  Do you have confirmation from the affected party that
>> the shims are adequate for them?  I have been waiting for that before
>> looking at this branch.
> 
> Hi Navdeep,
> 
> Mellanox has received an API list from at least one party, and has taken
> the action to support all the required APIs.
> 
>> Is the iw_cxgbe breakage a simple merge conflict as previously discussed
>> or do the shims require driver changes?  
> 
> It is a merge conflict. The code already compiles in 12-current.

I tried backing out r329391 and r329017 in a local copy and then was
able to merge r320418, r323082, and r326169 in that order without any
conflicts.  But iw_cxgbe/cm.c still doesn't compile in the projects
branch because it has some socket code that relies on some of glebius's
changes available only in head (I checked with him and they aren't
MFC'able).  I'm trying to figure out what to do about those.

And what about the cxgb breakage?  Is there any simple way to make an
old style driver work with the new stack?  T3 iw_cxgb in head was
retired before the ofed overhaul.

Regards,
Navdeep

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

Re: [HEADS UP] - OFED/RDMA stack update

[Navdeep Parhar]

On Sat, Mar 17, 2018 at 09:03:40PM +0100, Hans Petter Selasky wrote:
> On 03/17/18 20:52, Navdeep Parhar wrote:
> >Hold your horses.  Do you have confirmation from the affected party that
> >the shims are adequate for them?  I have been waiting for that before
> >looking at this branch.
> 
> Hi Navdeep,
> 
> Mellanox has received an API list from at least one party, and has taken the
> action to support all the required APIs.
> 
> >Is the iw_cxgbe breakage a simple merge conflict as previously discussed
> >or do the shims require driver changes?
> 
> It is a merge conflict. The code already compiles in 12-current.

Ok that doesn't sound that bad.  I'll take a look early this week.

Regards,
Navdeep

> 
> >If they don't then it should be
> >possible to drop the iw_cxgbe from head into this branch and it should
> >just work, is that correct?
> 
> Yes, it shouldn't be too hard to do and I would appreciate if Chelsio could
> throw some resources at this ASAP. I believe the new code will benefit
> everyone using Infiniband/RoCE and iWarp with FreeBSD.
> 
> --HPS
> ___
> freebsd-a...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [HEADS UP] - OFED/RDMA stack update

[Navdeep Parhar]

Hold your horses.  Do you have confirmation from the affected party that
the shims are adequate for them?  I have been waiting for that before
looking at this branch.

Is the iw_cxgbe breakage a simple merge conflict as previously discussed
or do the shims require driver changes?  If they don't then it should be
possible to drop the iw_cxgbe from head into this branch and it should
just work, is that correct?

Regards,
Navdeep

On Fri, Mar 16, 2018 at 05:44:41PM +0100, Hans Petter Selasky wrote:
> Hi,
> 
> The bsd_rdma_4_9_stable_11 projects branch is close to being merged into
> FreeBSD 11-stable. Mellanox plans to merge no later than 12:00 CEST TUE 20th
> of March 2018, unless objections are received.
> 
> A compatibility header file has been created, ib_verbs_compat.h, which
> offers full source compatibility to existing OFED kernel applications, as a
> response to the raised conserns. User-space compatibility is maintained
> through library symbol versioning.
> 
> https://svnweb.freebsd.org/base/projects/bsd_rdma_4_9_stable_11/sys/ofed/include/rdma/ib_verbs_compat.h
> 
> An example client for this header file can be found here:
> 
> https://svnweb.freebsd.org/base/projects/bsd_rdma_4_9_stable_11/sys/contrib/rdma/krping_compat/
> 
> Currently the cxgb and cxgbe i-Warp drivers are not building, and will be
> stubbed from the kernel build before the branch is merged, unless Chelsio
> can add patches for these.
> 
> Here is a quick and dirty patch to make the bsd_rdma_4_9_stable_11 branch
> build:
> 
> >diff --git a/sys/modules/Makefile b/sys/modules/Makefile
> >index 6b005c854d7..b918a208f21 100644
> >--- a/sys/modules/Makefile
> >+++ b/sys/modules/Makefile
> >@@ -530,7 +530,7 @@ _txp=   txp
> > .if ${MK_SOURCELESS_UCODE} != "no" && ${MACHINE_CPUARCH} != "arm" && \
> >${MACHINE_ARCH:C/mips(el)?/mips/} != "mips" && \
> >${MACHINE_ARCH} != "powerpc" && ${MACHINE_CPUARCH} != "riscv"
> >-_cxgbe=cxgbe
> >+#_cxgbe=   cxgbe
> > .endif
> > .if ${MK_TESTS} != "no" || defined(ALL_MODULES)
> >@@ -554,7 +554,7 @@ _vpo=   vpo
> > _sym=  sym
> > # intr_disable() is a macro, causes problems
> > .if ${MK_SOURCELESS_UCODE} != "no"
> >-_cxgb= cxgb
> >+#_cxgb=cxgb
> > .endif
> > .endif
> 
> --HPS
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: [HEADS UP] - OFED/RDMA stack update

[Navdeep Parhar]

+freebsd-arch@

Hi Meny,

Can you please post the KPI/KBI analysis that you generated to some
public location and provide a link here?  A straight MFC would be a
major break of KPI/KBI in -STABLE and the options we're looking at are:

a) Ignore the breakage and let downstream consumers deal with the
fallout.  This obviously isn't ideal in a -STABLE branch.

b) Provide compat shims to at least preserve the KPI.  One challenge is
that the changes include functions with the same name but different
signature/behavior.  See, for example, ib_create_cq in Meny's list once
he publishes it.

c) Have two versions of the OFED interfaces in 11-STABLE and not break
existing downstream consumers at all.

I've reached out to users that I know of and know will be affected.
If you use OFED and FreeBSD 11 this would be a good time to weigh
in with your thoughts, ideas, concerns etc..

Regards,
Navdeep

On Mon, 2018-02-26 at 14:49 +, Meny Yossefi wrote:
> Hi, 
> 
> We are currently working on MFC'ing the OFED/RDMA stack update
> mentioned below to FreeBSD11-STABLE.
> 
> We already have working version in 'projects/bsd_rdma_4_9_stable_11'
> (pending iWARP updates) and currently working on ULP integration.
> 
> Again, as always, for any concern/comments you might have, please
> don't hesitate contacting us.
> 
> freebsd-driv...@mellanox.com
> 
> 
> Regards, 
> 
> Meny Yossefi, 
> Mellanox technologies
> 
> 
> -Original Message-
> From: Meny Yossefi 
> Sent: Monday, November 13, 2017 11:09 AM
> To: 'freebsd-infinib...@freebsd.org' ;
> 'freebsd-curr...@freebsd.org' 
> Cc: freebsd-drivers 
> Subject: [HEADS UP] - OFED/RDMA stack update 
> 
> Hi, 
> 
> This is to inform you that by end of this week we plan to merge the
> OFED/RDMA stack update from the project - 'bsd_rdma_4_9' into 12-
> CURRENT.
> The update aligns the OFED common code and RDMA vendor drivers with
> Linux v4.9.
> 
> We are still working on final modifications and build testing it prior
> to submission.
> 
> 
> For any concern/comments you might have, please don't hesitate
> contacting us.
> 
> freebsd-driv...@mellanox.com
> 
> 
> Regards, 
> 
> Meny Yossefi, 
> Mellanox technologies
> ___
> freebsd-infinib...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-infiniband
> To unsubscribe, send any mail to "freebsd-infiniband-unsubscribe@freeb
> sd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: coredump when loading cxgb after boot with routing daemon already running (RELENG11)

[Navdeep Parhar]

Please file a bug against the network stack.

Is zebra easy to install/configure?  Send me details of your
configuration offline and I can try it on head if it's something
straightforward.

Regards,
Navdeep


On Wed, Jan 4, 2017 at 11:15 AM, Mike Tancsa <m...@sentex.net> wrote:
> On 1/4/2017 2:07 PM, Navdeep Parhar wrote:
>> What source line in releng-11 does ifioctl+0x6dd correspond to?
>>
>> (kgdb) l *(ifioctl+0x6dd)
>>
>> This might be race where the ifnet is being created or coming up and
>> zebra pokes it in some way before it's fully ready.  If that's the
>> case it could affect any ifnet.
>
> Hi Navdeep,
> Thanks for looking. yes, I just tried it with igb and a similar panic.
>
>
> igb0: <Intel(R) PRO/1000 Network Connection, Version - 2.5.3-k> port
> 0xc000-0xc01f mem 0xf720-0xf727,0xf728-0xf7283fff irq 17 at
> device 0.0 on pci4
> igb0: Using MSIX interrupts with 5 vectors
> igb0:
> Ethernet address: 00:25:90:47:b5:d8
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 06
> fault virtual address   = 0x0
> fault code  = supervisor read instruction, page not present
> instruction pointer = 0x20:0x0
> stack pointer   = 0x28:0xfe085d4d1728
> frame pointer   = 0x28:0xfe085d4d1750
> igb0: code segment  = base 0x0, limit 0xf, type 0x1b
> Bound queue 0 to cpu 0
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 846 (zebra)
> trap number = 12
> panic: page fault
> cpuid = 3
> KDB: stack backtrace:
> #0 0x806efae7 at kdb_backtrace+0x67
> #1 0x806a6006 at vpanic+0x186
> #2 0x806a5e73 at panic+0x43
> #3 0x80989622 at trap_fatal+0x322
> #4 0x809897ec at trap_pfault+0x1bc
> #5 0x80988ea0 at trap+0x280
> #6 0x8096dab1 at calltrap+0x8
> #7 0x807aa79d at ifioctl+0x6dd
> #8 0x8070d876 at kern_ioctl+0x346
> #9 0x8070d47f at sys_ioctl+0x13f
> #10 0x80989fae at amd64_syscall+0x50e
> #11 0x8096dd9b at Xfast_syscall+0xfb
> Uptime: 1m9s
> Dumping 1267 out of 32675
> MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..91%
> Dump complete
>
>
> kgdb)  l *(ifioctl+0x6dd)
> 0x807b90fd is in ifioctl (/usr/src/sys/net/if.c:2655).
> 2650case SIOCGIFMEDIA:
> 2651case SIOCGIFXMEDIA:
> 2652case SIOCGIFGENERIC:
> 2653if (ifp->if_ioctl == NULL)
> 2654return (EOPNOTSUPP);
> 2655error = (*ifp->if_ioctl)(ifp, cmd, data);
> 2656break;
> 2657
> 2658case SIOCSIFLLADDR:
> 2659error = priv_check(td, PRIV_NET_SETLLADDR);
> Current language:  auto; currently minimal
> (kgdb)
>
>
>
>>
>> Regards,
>> Navdeep
>>
>>
>>
>> On Wed, Jan 4, 2017 at 11:00 AM, Mike Tancsa <m...@sentex.net> wrote:
>>> I ran into a strange problem when manually loading a network driver
>>> after RELENG_11 box starts up with a routing daemon already running.
>>>
>>> If I have zebra running (just a few static routes) and then try and do a
>>> kldload if_cxgb, the box panics.  If I boot the box, load the nic's
>>> driver and then start zebra, all is fine.
>>>
>>> At first, I thought it might be a firmware issue, but I updated the
>>> NIC's firmware and the same behaviour.  Not sure if this is specific to
>>> the chelsio or if any kldload of a NIC driver will do.
>>>
>>>
>>>
>>> cxgbc0:  mem
>>> 0xf7081000-0xf7081fff,0xf680-0xf6ff,0xf708-0xf7080fff irq 16
>>> at device 0.0 on pci5
>>> cxgbc0: PCIe x4 Link, expect reduced performance
>>> cxgbc0: using MSI-X interrupts (5 vectors)
>>> cxgbc0: firmware needs to be updated to version 7.11.0
>>> cJan  4 13:03:02 xgbc0: Firmware Version 5.0.0
>>> cxgb0:  on cxgbc0
>>> cxgb0: Using defaults for TSO: 65518/35/2048
>>> cxgb0:
>>> Ethernet address: 00:07:43:07:9e:14
>>>
>>> offsite2 kernel:Fatal trap 12: page fault while in kernel mode
>>> c found old FW mipuinor version(5.0)d =, driver compile 2; d for version
>>> 7.apic11
>>>  id = 04
>>> fault virtual address   = 0x0
>>> fault code  = supervisor read instruction, page not present
>>> instruction pointer = 0x20:0x0
>>> stack pointer   = 0x28:0xfe085d2df728
>>> frame poin

Re: coredump when loading cxgb after boot with routing daemon already running (RELENG11)

[Navdeep Parhar]

What source line in releng-11 does ifioctl+0x6dd correspond to?

(kgdb) l *(ifioctl+0x6dd)

This might be race where the ifnet is being created or coming up and
zebra pokes it in some way before it's fully ready.  If that's the
case it could affect any ifnet.

Regards,
Navdeep



On Wed, Jan 4, 2017 at 11:00 AM, Mike Tancsa  wrote:
> I ran into a strange problem when manually loading a network driver
> after RELENG_11 box starts up with a routing daemon already running.
>
> If I have zebra running (just a few static routes) and then try and do a
> kldload if_cxgb, the box panics.  If I boot the box, load the nic's
> driver and then start zebra, all is fine.
>
> At first, I thought it might be a firmware issue, but I updated the
> NIC's firmware and the same behaviour.  Not sure if this is specific to
> the chelsio or if any kldload of a NIC driver will do.
>
>
>
> cxgbc0:  mem
> 0xf7081000-0xf7081fff,0xf680-0xf6ff,0xf708-0xf7080fff irq 16
> at device 0.0 on pci5
> cxgbc0: PCIe x4 Link, expect reduced performance
> cxgbc0: using MSI-X interrupts (5 vectors)
> cxgbc0: firmware needs to be updated to version 7.11.0
> cJan  4 13:03:02 xgbc0: Firmware Version 5.0.0
> cxgb0:  on cxgbc0
> cxgb0: Using defaults for TSO: 65518/35/2048
> cxgb0:
> Ethernet address: 00:07:43:07:9e:14
>
> offsite2 kernel:Fatal trap 12: page fault while in kernel mode
> c found old FW mipuinor version(5.0)d =, driver compile 2; d for version
> 7.apic11
>  id = 04
> fault virtual address   = 0x0
> fault code  = supervisor read instruction, page not present
> instruction pointer = 0x20:0x0
> stack pointer   = 0x28:0xfe085d2df728
> frame pointer   = 0x28:0xfe085d2df750
> 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 = 420 (zebra)
> trap number = 12
> panic: page fault
> cpuid = 0
> KDB: stack backtrace:
> #0 0x806fe447 at kdb_backtrace+0x67
> #1 0x806b4966 at vpanic+0x186
> #2 0x806b47d3 at panic+0x43
> #3 0x80997f82 at trap_fatal+0x322
> #4 0x8099814c at trap_pfault+0x1bc
> #5 0x80997800 at trap+0x280
> #6 0x8097c411 at calltrap+0x8
> #7 0x807b90fd at ifioctl+0x6dd
> #8 0x8071c1d6 at kern_ioctl+0x346
> #9 0x8071bddf at sys_ioctl+0x13f
> #10 0x8099890e at amd64_syscall+0x50e
> #11 0x8097c6fb at Xfast_syscall+0xfb
> Uptime: 3m9s
> Dumping 1635 out of 32675
> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
> --
> ---
> Mike Tancsa, tel +1 519 651 3400
> Sentex Communications, m...@sentex.net
> Providing Internet services since 1994 www.sentex.net
> Cambridge, Ontario Canada   http://www.tancsa.com/
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 11.0 stuck on high network load

[Navdeep Parhar]

>  I see, thus just for the context:  The TCP stack in sys/dev/cxgb* is a
> TOE (TCP Offload Engine?) TCP stack for Chelsio NICs, it is a
> separate/side TCP stack that is used only with TCP_OFFLOAD option.
> 
>  This TOE TCP stack actually has its own set of detach()/input()
> functions and seems to check INP_DROPPED flag properly.  I guess @np
> check fixes in socket TCP stack and decides which one can also impact

Yes, I do keep an eye on the changes in the stack and keep the TOE
drivers up to date.  The good part is that those drivers are trying to
do the exact same thing with the locks and various bits of state as the
software stack so they don't have any special requirements.

If any patch comes out of this discussion I'll update the TOE drivers
(if needed).

btw, if you're looking at TOE drivers then read the sys/dev/cxgbe/t4_tom
code (instead of the old T3 chip's cxgb/ulp/tom) as that's the most
actively maintained and tested.

Regards,
Navdeep
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: freebsd downgrade

[Navdeep Parhar]

On Fri, Jul 24, 2015 at 10:50:10AM +0300, Slawa Olhovchenkov wrote:
   
   For me -- degradate network performance, about 30%. I am do
   verification now, by downgrading kernel.
  
  What kind of workload and what NIC are you using?
 
 Chelsio T580-LP-CR, http serving.
 r276179 can utilise 40Gbit, r281264 -- only 28Gbit.

Can you please try -RC1 when it comes out and report back if you still
see degraded network performance? 

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

multiple NFS mounts with bg,retrycount=0

[Navdeep Parhar]

I updated a FreeBSD 9-STABLE system to r250290 and noticed an NFS oddity
-- fstab entries that specify a retrycnt are mounted multiple times.

I have this in /etc/fstab:
:/remote/ /local/ nfs rw,bg,retrycnt=0 0 0

And this in /etc/rc.conf:
rpcbind_enable=YES
nfs_client_enable=YES
nfs_server_enable=YES
nfsv4_server_enable=YES
nfsuserd_flags=-domain XX
rpc_lockd_enable=YES
rpc_statd_enable=YES

If I run mount immediately after the system boots up I don't see
anything mounted on /local/.  If I wait a minute or so and recheck I
see two identical mounts on /local/.

# mount | grep /local
:/remote/ on /local/ (nfs)
:/remote/ on /local/ (nfs)

It is almost as if the system tried to mount the remote FS, failed, and
then forked multiple (?) processes to retry the operation, and all of
them succeed later.  Unfortunately, I can't reboot the system for a
couple of days so I can't go looking for mount_nfs processes right after
a fresh boot.

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

Re: IPMI serial console

[Navdeep Parhar]

On 02/21/13 13:56, Daniel O'Connor wrote:
 
 On 22/02/2013, at 2:19, John Baldwin j...@freebsd.org wrote:
 Does anyone have any hints?

 Rather than using all these hints, just use these three in loader.conf:

 console=comconsole vidconsole
 console_speed=115200
 console_port=0xblah  (where blah is the correct I/O port for COM3, 
 0x3e8 
 maybe?)
 
 
 No dice :(
 
 I also tried booting with '-D -h -S 115200' but nothing either.

What does dmesg | grep uart show?  I have a PCI serial card whose
serial port I'm using as a console.  I had to setup comconsole_pcidev,
comconsole_port, and comconsole_speed properly in loader.conf to get it
to work.

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

Re: IPMI serial console

[Navdeep Parhar]

On 02/21/13 14:15, Konstantin Belousov wrote:
 On Thu, Feb 21, 2013 at 02:07:57PM -0800, Navdeep Parhar wrote:
 On 02/21/13 13:56, Daniel O'Connor wrote:

 On 22/02/2013, at 2:19, John Baldwin j...@freebsd.org wrote:
 Does anyone have any hints?

 Rather than using all these hints, just use these three in loader.conf:

 console=comconsole vidconsole
 console_speed=115200
 console_port=0xblah  (where blah is the correct I/O port for COM3, 
 0x3e8 
 maybe?)


 No dice :(

 I also tried booting with '-D -h -S 115200' but nothing either.

 What does dmesg | grep uart show?  I have a PCI serial card whose
 serial port I'm using as a console.  I had to setup comconsole_pcidev,
 comconsole_port, and comconsole_speed properly in loader.conf to get it
 to work.
 
 Do you need the comconsole_port if comconsole_pcidev is set properly ?
 comconsole_port should be set automatically (i.e., read from the BAR)
 if _pcidev is correct.
 

I just tried it -- it works without the comconsole_port.  So yes, it's
reading the port value automatically. (I see it in kenv and of course I
can see that my console is working).

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

Re: IPMI serial console

[Navdeep Parhar]

On 02/21/13 14:42, Daniel O'Connor wrote:
 
 On 22/02/2013, at 8:37, Navdeep Parhar npar...@gmail.com wrote:
 I also tried booting with '-D -h -S 115200' but nothing either.

 What does dmesg | grep uart show?  I have a PCI serial card whose
 serial port I'm using as a console.  I had to setup comconsole_pcidev,
 comconsole_port, and comconsole_speed properly in loader.conf to get it
 to work.
 
 
 uart0: 16550 or compatible port 0x3f8-0x3ff irq 4 on acpi0
 uart1: 16550 or compatible port 0x2f8-0x2ff irq 3 on acpi0
 uart2: 16550 or compatible port 0x3e8-0x3ef irq 5 flags 0x30 on acpi0
 
 The loader talks on the serial console fine, it's the kernel that doesn't use 
 it which is the problem.

And what do you see in kenv | egrep 'uart|com' ?

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

Re: IPMI serial console

[Navdeep Parhar]

On 02/21/13 14:48, Daniel O'Connor wrote:
 
 On 22/02/2013, at 9:15, Navdeep Parhar npar...@gmail.com wrote:
 uart0: 16550 or compatible port 0x3f8-0x3ff irq 4 on acpi0
 uart1: 16550 or compatible port 0x2f8-0x2ff irq 3 on acpi0
 uart2: 16550 or compatible port 0x3e8-0x3ef irq 5 flags 0x30 on acpi0

 The loader talks on the serial console fine, it's the kernel that doesn't 
 use it which is the problem.

 And what do you see in kenv | egrep 'uart|com' ?
 
 comconsole_port=0x3e8
 comconsole_speed=115200
 hint.uart.0.at=isa
 hint.uart.0.flags=0x00
 hint.uart.0.irq=4
 hint.uart.0.port=0x3F8
 hint.uart.1.at=isa
 hint.uart.1.flags=0x00
 hint.uart.1.irq=3
 hint.uart.1.port=0x2F8
 hint.uart.2.flags=0x30
 menu_command[1]=boot
 menu_command[2]=goto_prompt
 menu_command[4]=toggle_acpi
 menu_command[5]=toggle_safemode
 menu_command[6]=toggle_singleuser
 menu_command[7]=toggle_verbose
 menu_timeout_command=boot

No hw.uart.console, hmmm.  It may be time to put some printf's in
comc_setup() in boot/i386/libi386/comconsole.c and see what's up.  One
last thing before you take that route: if you create an environment
variable named hw.uart.console in loader.conf (set it to anything), do
you at least see it getting unset?  That'll tell you whether
comc_setup() even ran.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: IPMI serial console

[Navdeep Parhar]

 One
 last thing before you take that route: if you create an environment
 variable named hw.uart.console in loader.conf (set it to anything), do
 you at least see it getting unset?  That'll tell you whether
 comc_setup() even ran.
 

Ignore this part, this don't quite work as I thought it did.


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

Re: No buffer space available / tcp_inpcb value

[Navdeep Parhar]

On 10/30/12 06:21, Adam Strohl wrote:

Hey -STABLE,

I've got a client who we've setup a FreeBSD cluster for with about a
dozens servers, all behind two front end proxies/LBs/firewalls which
also act as NAT gateways for the internal servers.

On the active front end proxy we've started seeing fatal: socket: No
buffer space available errors during high-peak times.   I can see in
vmstat -z that this is what is getting denied:

ITEM   SIZE  LIMIT USED FREE  REQ FAIL SLEEP
tcp_inpcb:  392,  32770,   19398, 13372,1449734621,6312858,   0

We've got a lot of the other values bumped, and it appears to be this
input limit that is getting hit.  There are no other non-zero FAILed
counters except 64 and 128 buckets which I believe are normal.

I cannot seem to find the sysctl (or equiv) that controls this limit
though, or even what it is.  Anyone know?


kern.ipc.maxsockets controls this limit.  See in_pcbinfo_init() for details.

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

Re: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE

[Navdeep Parhar]

On Wed, Dec 1, 2010 at 5:37 PM, Zhihao Yuan lich...@gmail.com wrote:
 I guess such an error has nothing to do with the difference between
 compilers... I assumed that you used similar KERNCONF on your two systems.
 So, a hypothesis is: Dtrace does not work correctly on amd64.

It works just fine for me.  I built my amd64 kernel a week or so back
with this KERNCONF:
include GENERIC
ident DWARF
options KDTRACE_FRAME
options KDTRACE_HOOKS
options KDB
options DDB
options DDB_CTF

Can you check with ctfdump if you objects actually have CTF
information in them?  Something like this:
# ctfdump -S /boot/kernel/kernel

# ctfdump /boot/kernel/kernel | grep ...

Regards,
Navdeep


 On Wed, Dec 1, 2010 at 6:37 PM, Brandon Gooch
 jamesbrandongo...@gmail.comwrote:

 On Wed, Dec 1, 2010 at 6:27 PM, Jeremy Chadwick
 free...@jdc.parodius.com wrote:
  On Wed, Dec 01, 2010 at 06:22:40PM -0600, Brandon Gooch wrote:
  On Wed, Dec 1, 2010 at 4:30 PM, Zhihao Yuan lich...@gmail.com wrote:
   OK. Let's make this more clear: anyone has a working 8-2-PRERELEASE
 kernel
   (amd64 is preferred) with Dtrace supports, which can run the
   scripts/commands on the wiki? If so, please post your kernel
 configurations
   here, thanks.
 
  I have an i386 system working:
  [snip]
 
  Can you please try the command the OP originally provided?  See command
  here:
 
 
 http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/060216.html

 d820# dtrace -lP syscall | head
   ID   PROVIDER            MODULE                          FUNCTION NAME
   17    syscall                                             syscall entry
   18    syscall                                             syscall return
   19    syscall                                                exit entry
   20    syscall                                                exit return
   21    syscall                                                fork entry
   22    syscall                                                fork return
   23    syscall                                                read entry
   24    syscall                                                read return
   25    syscall                                               write entry

 The error the OP received from the above command was pretty much
 exactly what I was seeing when I attempting to use DTrace on my HEAD
 system, built with clang. Same error, at least this part:

 /usr/lib/dtrace/psinfo.d, line 88: failed to resolve type
 kernel`struct thread * for identifier curthread: Unknown type name

 I was running simply 'dtrace -l' to list all probes...

 -Brandon




 --
 Zhihao Yuan
 The best way to predict the future is to invent it.
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

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

Re: LRO support for cxgb in stable/7

[Navdeep Parhar]

On Thu, Nov 19, 2009 at 10:48:40AM -0800, Matthew Fleming wrote:
 r193754 to stable/7 appears to have unintended code.  The MFC note
 indicates it is a backport of 190206, 190330, 192537, 192540, 192584 and
 192933.  I looked over all of them and none have the offending snippet:
 
 #ifndef LRO_SUPPORTED
 #ifdef IFCAP_LRO
 #undef IFCAP_LRO
 #endif
 #define IFCAP_LRO 0x0
 #endif
 
 cxgb had LRO support on releng/7.1 and now it does not, since
 LRO_SUPPORTED is not defined anywhere as a config option, or in the cxgb
 Makefile.
 
 Is this analysis correct?  Should the above lines be deleted from the
 stable/7 repository?

You're correct.  This has now been fixed in r199544.

Regards,
Navdeep

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

Re: cxgb LOR

[Navdeep Parhar]

A lot of these LORs were fixed in cxgb in FreeBSD 8.  You can look at
cxgb_main.c in 8 for details.  I'll also try and figure out if those
changes are easily MFC'able.

Regards,
Navdeep

On Mon, Sep 14, 2009 at 2:29 PM, Matthew Fleming
matthew.flem...@isilon.com wrote:
 We got a cxgb LOR report of:

 1st 0xff8001e37be0 vlan_global (vlan_global) @
 /build/mnt/src/sys/modules/if_vlan/../../net/if_vlan.c:1310
  2nd 0xff80010892f0 cxgb port lock (cxgb port lock) @
 /build/mnt/src/sys/modules/cxgb/../../dev/cxgb/cxgb_main.c:1956
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 witness_checkorder() at witness_checkorder+0x9e2
 _sx_xlock() at _sx_xlock+0x55
 cxgb_ioctl() at cxgb_ioctl+0x1e8
 vlan_ioctl() at vlan_ioctl+0x359
 ifhwioctl() at ifhwioctl+0xb1
 ifioctl() at ifioctl+0xb1
 kern_ioctl() at kern_ioctl+0xa3
 ioctl() at ioctl+0xf1
 freebsd32_ioctl() at freebsd32_ioctl+0x13e
 isi_syscall() at isi_syscall+0x94
 ia32_syscall() at ia32_syscall+0x1a3
 Xint0x80_syscall() at Xint0x80_syscall+0x60
 --- syscall (54, FreeBSD ELF32, freebsd32_ioctl), rip = 0x2868db1b, rsp
 = 0xd4bc, rbp = 0xda38 ---


 So we tried changing cxgb to not USE_SX.  This resulted in a different
 LOR:

 lock order reversal: (sleepable after non-sleepable)
  1st 0xff8000f9d508 cxgb controller lock 0 (cxgb controller lock 0)
 @
 /build/mnt/src/sys/modules/cxgb/cxgb/../../../dev/cxgb/cxgb_main.c:1889
  2nd 0x806064e0 ACPI root bus (ACPI root bus) @
 /build/mnt/src/sys/dev/acpica/acpi.c:1040
 KDB: stack backtrace:
 [8018e9fa] db_trace_self_wrapper+0x2a
 [80298e89] witness_checkorder+0x719
 [8025bf75] _sx_xlock+0x55
 [8019678a] acpi_alloc_resource+0x9a
 [80281714] resource_list_alloc+0x184
 [801d9f98] pci_alloc_resource+0x158
 [802814b9] bus_alloc_resource+0x89
 [81804201] cxgb_setup_interrupts+0x51
 [81807f33] cxgb_up+0xa3
 [818083c0] cxgb_init_locked+0x1b0
 [81808539] cxgb_init+0x39
 [81808758] cxgb_ioctl+0x1f8
 [8031e9e1] ifhwioctl+0xb1
 [8031f720] ifioctl+0xb0
 [8029a873] kern_ioctl+0xa3
 [8029aad1] ioctl+0xf1
 [8041eb93] freebsd32_ioctl+0xb3
 [8025d963] isi_syscall+0x83
 [8041de63] ia32_syscall+0x1a3
 [803efc60] Xint0x80_syscall+0x60
 --- syscall (54, FreeBSD ELF32, freebsd32_ioctl), rip = 0x2826ea67, rsp
 = 0xd8ac, rbp = 0xd928 ---

 (we modified cxgb_ioctl to call cxgb_init because otherwise the cxgb
 interface would require an ifconfig up before it detected a link, which
 was different behaviour from the em driver.  Since the locks in question
 are acquired inside cxgb_init() I don't think the rest of the stack is
 relevant, but network stack isn't my area of expertise).

 So it seems that with cxgb we're damned if we do, damned if we don't.
 Any advice on which LOR is worse or if one is harmless, or how to make
 it go away?

 Note also that if cxgb uses a mtx then it will do malloc while holding
 the mtx in this stack:

 [803cc58a] uma_zalloc_arg+0x2da
 [80241ef9] malloc+0x89
 [8023115f] intr_event_add_handler+0x5f
 [803f26d2] intr_add_handler+0x72
 [801dc171] pci_setup_intr+0x41
 [801dc171] pci_setup_intr+0x41
 [802807e6] bus_setup_intr+0x96
 [8180423c] cxgb_setup_interrupts+0x8c
 [81807f33] cxgb_up+0xa3
 [818083c0] cxgb_init_locked+0x1b0
 [81808539] cxgb_init+0x39

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

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

Re: ZFS MFC heads down

[Navdeep Parhar]

On Wed, May 20, 2009 at 4:43 PM, Kip Macy km...@freebsd.org wrote:
 On Wed, May 20, 2009 at 2:59 PM, Kip Macy km...@freebsd.org wrote:
 I will be MFC'ing the newer ZFS support some time this afternoon. Both
 world and kernel will need to be re-built. Existing pools will
 continue to work without upgrade.


 If you choose to upgrade a pool to take advantage of new features you
 will no longer be able to use it with sources prior to today. 'zfs
 send/recv' is not expected to inter-operate between different pool
 versions.


 The MFC went in r192498. Please let me know if you have any problems.

Not really a problem but a question:  Is the v13 on-disk format
exactly the same as that used by Solaris/Opensolaris?  Does this make
it possible to have a ZFS-only dual boot system running FreeBSD-stable
and Solaris, with a shared home directory between the two
environments?  Has anyone tried anything like this?

Regards,
Navdeep


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

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

Re: ZFS MFC heads down

[Navdeep Parhar]

On Wed, May 20, 2009 at 5:00 PM, Kip Macy km...@freebsd.org wrote:
 Not really a problem but a question:  Is the v13 on-disk format
 exactly the same as that used by Solaris/Opensolaris?

 It is supposed to be. The sources are the same. However, I have not
 tested interoperability.


 Does this make
 it possible to have a ZFS-only dual boot system running FreeBSD-stable
 and Solaris, with a shared home directory between the two
 environments?

 It should be.

Has anyone tried anything like this?


 Google anyone? :-)

My google-fu is weak today, and considering that this went into
-stable a few minutes back, I didn't look that hard for
v13/fbsd-stable/opensolaris adventures. :-)

I'm feeling brave.  I think I'll try it myself.  Thanks for getting
this into -stable!

Navdeep


 -Kip

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

7.2RC2 panic in drm_open_helper on amd64

[Navdeep Parhar]

[ Normally I'd have replied to the original email but I couldn't
figure out a way to subscribe to a list, and then reply to an email
already posted to the list.]

I have this very problem (with a different card):
http://lists.freebsd.org/pipermail/freebsd-stable/2009-April/049618.html

It looks like drm_open_helper() gets a NULL dev parameter and a panic
occurs when it attempts to set dev-flags = flags.  r189668, which was
the MFC of r189052, seems to be the point where the problem showed up
in the 7-STABLE branch.

Regards,
Navdeep

=
vgap...@pci0:3:1:0: class=0x03 card=0x02021787 chip=0x51591002
rev=0x00 hdr=0x00
vendor = 'ATI Technologies Inc'
device = 'RV100 Radeon 7000 / Radeon VE'
class  = display
subclass   = VGA

=
Unread portion of the kernel message buffer:
drm2: ATI Radeon QY RV100 7000/VE on vgapci2
device_attach: drm2 attach returned 2


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x3c
fault code  = supervisor write data, page not present
instruction pointer = 0x8:0x80e28bfe
stack pointer   = 0x10:0xfffebe6f36a0
frame pointer   = 0x10:0xfffebe6f36f0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 3
current process = 1103 (Xorg)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 30m9s
Physical memory: 2033 MB
Dumping 120 MB: 105 89 73 57 41 25 9

Reading symbols from /boot/kernel/drm.ko...Reading symbols from
/boot/kernel/drm.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/drm.ko
Reading symbols from /boot/kernel/radeon.ko...Reading symbols from
/boot/kernel/radeon.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/radeon.ko
#0  doadump () at pcpu.h:195
195 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0  doadump () at pcpu.h:195
#1  0x0004 in ?? ()
#2  0x8049a8b1 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:418
#3  0x8049acec in panic (fmt=0x104 Address 0x104 out of
bounds) at /usr/src/sys/kern/kern_shutdown.c:574
#4  0x8075e70a in trap_fatal (frame=0xff0001c476e0,
eva=Variable eva is not available.
) at /usr/src/sys/amd64/amd64/trap.c:764
#5  0x8075eab1 in trap_pfault (frame=0xfffebe6f35f0,
usermode=0) at /usr/src/sys/amd64/amd64/trap.c:680
#6  0x8075f36f in trap (frame=0xfffebe6f35f0) at
/usr/src/sys/amd64/amd64/trap.c:449
#7  0x807447ae in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:209
#8  0x80e28bfe in drm_open_helper (kdev=0xff0001bbb200,
flags=3, fmt=Variable fmt is not available.
)
at /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_fops.c:50
#9  0x80e27510 in drm_open (kdev=0xff0001bbb200, flags=3,
fmt=8192, p=0xff0001c476e0)
at /usr/src/sys/modules/drm/drm/../../../dev/drm/drm_drv.c:597
#10 0x80464275 in giant_open (dev=0xff0001bbb200,
oflags=3, devtype=8192, td=0xff0001c476e0)
at /usr/src/sys/kern/kern_conf.c:342
#11 0x804341c7 in devfs_open (ap=0xfffebe6f38e0) at
/usr/src/sys/fs/devfs/devfs_vnops.c:916
#12 0x8051f0ec in vn_open_cred (ndp=0xfffebe6f3a20,
flagp=0xfffebe6f396c, cmode=Variable cmode is not available.
) at vnode_if.h:199
#13 0x8051ce23 in kern_open (td=0xff0001c476e0,
path=0x7fffe850 Address 0x7fffe850 out of bounds,
pathseg=Variable pathseg is not available.
) at /usr/src/sys/kern/vfs_syscalls.c:1042
#14 0x8075ed1c in syscall (frame=0xfffebe6f3c80) at
/usr/src/sys/amd64/amd64/trap.c:907
#15 0x807449bb in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:330
#16 0x0008019c8ffc in ?? ()
Previous frame inner to this frame (corrupt stack?)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org