Re: Intel 10Gb network card
On 09/04/2013 08:25 AM, Daniel Braniss wrote: > Q: does the copper (10G Based T) version work? Works fine for me. Julian ___ 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: Reproducable Infiniband panic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/10/2013 06:15 PM, John Baldwin wrote: > Can you please retest this updated version? I had thought that I > didn't need a reference count on the vnode, but devfs drops its > reference count before the cdevpriv destructor is called. Works for me. Julian -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlG2QhMACgkQ2EtjUdW3H9nLnQCfcX0+h5PiypoIFGewe40uOh0c Jh4AoLhx1eORFAZB3RPsiL/tT6yXlqbF =9I3M -END PGP SIGNATURE- ___ 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: Reproducable Infiniband panic
On 06/07/2013 06:06 PM, John Baldwin wrote: > On Friday, June 07, 2013 5:07:34 am Julian Stecklina wrote: >> On 06/06/2013 08:57 PM, John Baldwin wrote: >>> On Thursday, June 06, 2013 9:54:35 am Andriy Gapon wrote: >> [...] >>>> The problem seems to be in incorrect interaction between devfs_close_f > and >>>> linux_file_dtor. The latter expects curthread->td_fpop to have a valid > reasonable >>>> value. But the former sets curthread->td_fpop to fp only around > vnops.fo_close() >>>> call and then restores it back to some (what?) previous value before > calling >>>> devfs_fpdrop->devfs_destroy_cdevpriv. In this case the previous value is > NULL. >>> >>> It is normally NULL in this case. Why does linux_file_dtor even look at >>> td_fpop? >>> >>> Ah. I think it should not do that and make the data it uses in the dtor > more >>> self-contained: [...] Seems to fix my panic. Thanks! Julian ___ 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: Reproducable Infiniband panic
On 06/06/2013 08:57 PM, John Baldwin wrote:
> On Thursday, June 06, 2013 9:54:35 am Andriy Gapon wrote:
[...]
>> The problem seems to be in incorrect interaction between devfs_close_f and
>> linux_file_dtor. The latter expects curthread->td_fpop to have a valid
>> reasonable
>> value. But the former sets curthread->td_fpop to fp only around
>> vnops.fo_close()
>> call and then restores it back to some (what?) previous value before calling
>> devfs_fpdrop->devfs_destroy_cdevpriv. In this case the previous value is
>> NULL.
>
> It is normally NULL in this case. Why does linux_file_dtor even look at
> td_fpop?
>
> Ah. I think it should not do that and make the data it uses in the dtor more
> self-contained:
>
> Index: sys/ofed/include/linux/linux_compat.c
> ===
> --- linux_compat.c(revision 251465)
> +++ linux_compat.c(working copy)
> @@ -212,7 +212,7 @@ linux_file_dtor(void *cdp)
> struct linux_file *filp;
>
> filp = cdp;
> - filp->f_op->release(curthread->td_fpop->f_vnode, filp);
> + filp->f_op->release(filp->f_vnode, filp);
> kfree(filp);
> }
>
> @@ -232,6 +232,7 @@ linux_dev_open(struct cdev *dev, int oflags, int d
> filp->f_dentry = &filp->f_dentry_store;
> filp->f_op = ldev->ops;
> filp->f_flags = file->f_flag;
> + filp->f_vnode = file->f_vnode;
> if (filp->f_op->open) {
> error = -filp->f_op->open(file->f_vnode, filp);
> if (error) {
>
Doesn't compile for me. Did you forget to add the f_vnode member to
struct linux_file?
sys/ofed/include/linux/linux_compat.c: In function 'linux_file_dtor':
sys/ofed/include/linux/linux_compat.c:214: error: 'struct linux_file'
has no member named 'f_vnode'
sys/ofed/include/linux/linux_compat.c: In function 'linux_dev_open':
sys/ofed/include/linux/linux_compat.c:234: error: 'struct linux_file'
has no member named 'f_vnode'
Julian
___
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"
Reproducable Infiniband panic
Hello,
I see a reproducable panic when doing ibping and aborting it with ^C. My
setup is two machines with Mellanox Infinihost III HCAs (one Linux one
FreeBSD) connected back-to-back.
Details below. I can upload 2 crash dumps, if this is useful. For some
reason the port doesn't become ACTIVE, so no packets arrive, but that is
probably unrelated.
% uname -a
FreeBSD cosel.inf.tu-dresden.de 9.1-STABLE FreeBSD 9.1-STABLE #0
r+b6547e3: Wed Jun 5 18:29:51 CEST 2013
jul...@cosel.inf.tu-dresden.de:/usr/obj/usr/home/julian/src/freebsd/sys/COSEL
amd64
% sudo ibping 2
^C
--- (Lid 2) ibping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5161 ms
rtt min/avg/max = 0.000/0.000/0.000 ms
Fatal trap 12: page fault while in kernel mode
cpuid = 6; apic id = 06
fault virtual address = 0x18
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x807a3d83
stack pointer = 0x28:0xff8092c97890
frame pointer = 0x28:0xff8092c978b0
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 = 1489 (ibping)
trap number = 12
panic: page fault
cpuid = 6
KDB: stack backtrace:
#0 0x80632a96 at kdb_backtrace+0x66
#1 0x805f9fce at panic+0x1ce
#2 0x808a7380 at trap_fatal+0x290
#3 0x808a76e1 at trap_pfault+0x211
#4 0x808a7c94 at trap+0x344
#5 0x80891043 at calltrap+0x8
#6 0x80513c39 at devfs_destroy_cdevpriv+0x69
#7 0x80513e47 at devfs_close_f+0x57
#8 0x805b4b23 at _fdrop+0x23
#9 0x805b65ec at closef+0x4c
#10 0x805b76cc at fdfree+0x23c
#11 0x805c4945 at exit1+0x305
#12 0x805c5d0e at sys_sys_exit+0xe
#13 0x808a6b56 at amd64_syscall+0x5d6
#14 0x80891327 at Xfast_syscall+0xf7
Full backtrace from kgdb:
#0 doadump (textdump=) at pcpu.h:234
No locals.
#1 0x805f9aa4 in kern_reboot (howto=260) at
/usr/home/julian/src/freebsd/sys/kern/kern_shutdown.c:449
_ep = (struct eventhandler_entry *) 0x0
_el =
first_buf_printf = 1
#2 0x805f9fa7 in panic (fmt=0x1 ) at
/usr/home/julian/src/freebsd/sys/kern/kern_shutdown.c:637
td = (struct thread *) 0x1
bootopt =
newpanic =
ap = {{gp_offset = 16, fp_offset = 48, overflow_arg_area =
0xff8092b934f0, reg_save_area = 0xff8092b93410}}
panic_cpu = 7
buf = "page fault", '\0'
#3 0x808a7380 in trap_fatal (frame=0xc, eva=) at /usr/home/julian/src/freebsd/sys/amd64/amd64/trap.c:878
code =
ss = 40
type = 12
esp =
softseg = {ssd_base = 0, ssd_limit = 1048575, ssd_type = 27, ssd_dpl =
0, ssd_p = 1, ssd_long = 1, ssd_def32 = 0, ssd_gran = 1}
msg =
#4 0x808a76e1 in trap_pfault (frame=0xff8092b937e0,
usermode=0) at /usr/home/julian/src/freebsd/sys/amd64/amd64/trap.c:794
id =
va = 0
vm =
map = 0xfe000b0a3498
rv = 0
ftype = 255 'ÿ'
td = (struct thread *) 0xfe000b0af000
p = (struct proc *) 0xfe000b181950
eva = 24
#5 0x808a7c94 in trap (frame=0xff8092b937e0) at
/usr/home/julian/src/freebsd/sys/amd64/amd64/trap.c:463
regs = {r_r15 = -2136840320, r_r14 = -547294202144, r_r13 =
-547294202208, r_r12 = -2140660471, r_r11 = -2136840320, r_r10 = 594,
r_r9 = -547294202160, r_r8 = -2198830683992, r_rdi = 0, r_rsi =
-2136780531, r_rbp = 219043332096, r_rbx = -2198837989376,
r_rdx = -547294202048, r_rcx = 215695, r_rax = -2133265824,
r_trapno = 192571360, r_fs = 65024, r_gs = 65535, r_err = 525312,
r_es = 65408, r_ds = 65535, r_rip = -2136840320, r_cs = -547294202064,
r_rflags = -2133515200, r_rsp = -547294201968, r_ss = 0}
td = (struct thread *) 0xfe000b0af000
p =
i =
ucode =
code = 0
type = 12
addr =
ksi = {ksi_link = {tqe_next = 0xfe000553ac00, tqe_prev =
0xfe000b0af000}, ksi_info = {si_signo = -1833355440, si_errno = -128,
si_code = -2140661293, si_pid = -1, si_uid = 0, si_status = 0,
si_addr = 0xfe00, si_value = {sival_int = -1833355392,
sival_ptr = 0xff8092b93780, sigval_int = -1833355392,
sigval_ptr = 0xff8092b93780}, _reason = {_fault = {_trapno =
-2138032854},
_timer = {_timerid = -2138032854, _overrun = -1}, _mesgq = {_mqd =
-2138032854}, _poll = {_band = -2138032854}, __spare__ = {
__spare1__ = -2138032854, __spare2__ = {192571360, -512,
192571360, -512, 2, 0, 0, ksi_flags = -1833355296,
ksi_sigq = 0x806955f3}
#6 0x80891043 in calltrap () at
/usr/home/julian/src/freebsd/sys/amd64/amd64/exception.S:228
No locals.
#7 0x807a3d83 in linux_file_dtor (cdp=0xfe000aeabb80) at
/usr/home/julian/src/freebsd/sy
Re: time issues and ZFS
Thus spake Daniel Braniss : > In the meantime here is some info: > Intel(R) Xeon(R) CPU E5645: running with no problems > LAPIC(600) HPET(450) HPET1(440) HPET2(440) HPET3(440) i8254(100) RTC(0) > > Intel(R) Xeon(R) CPU X5550: this is the problematic, at least for the moment > HPET(450) HPET1(440) HPET2(440) HPET3(440) LAPIC(400) i8254(100) RTC(0) Does anyone know why the LAPIC is given a lower priority than HPET in this case? If you have an LAPIC, it should always be prefered to HPET, unless something is seriously wrong with it... Julian ___ 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: Some new hardware with 9.1 does not reboot easily
Steven Hartland wrote: >- Original Message - >From: "Andriy Gapon" > > >> on 11/01/2013 21:38 Willem Jan Withagen said the following: >>> On 2013-01-07 18:06, Julian Stecklina wrote: >>>> Has this been resolved? I still see a hang on reboot/shutdown on my >box >>>> (zfs root on USB thumb drive), but I am not sure if the problem is >>>> related. >>> >>> Could very well be be. >>> >>> I have again the same problem as I reported before with the full and >new >>> 9.1 code. >>> But did not have time yet to build a system te test with. >>> >>> My other 9.1 box is my ZFS only fileserver. And I do not want to >fidle >>> to much with it. > >Not sure if this has been suggested or ruled out as yet but if you have >usb >enabled, you don't need to be using it, try the following see if it >helps? > >sysctl hw.usb.no_shutdown_wait=1 With that sysctl set the box shuts down just fine. Thanks! > >If it does >1. Temporary fix is to pop that in /etc/sysctl.conf >2. Worth investigating which USB component isn't dropping references >correctly. I only have an USB thumb drive and a USB soundcard attached. I tried it without the soundcard attached and would still not reset/shutdown, so that does not seem to be the problem. I attached usbconfig list output. Julian -- Sent from Kaiten Mail. Please excuse my brevity.ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen3.1: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen5.1: at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen2.2: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.2: at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ___ 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: Some new hardware with 9.1 does not reboot easily
Hello, Willem Jan Withagen wrote: > >A reboot work around that works for me: > reboot -n > shutdown -n now >Of which the manual pages say: option should not be used. >But I have not yet found bad effects. Perhaps becuase I only have ZFS >fs-systems Thanks for the workaround! But as you said, it doesn't feel very safe... Julian -- Sent from Kaiten Mail. Please excuse my brevity. ___ 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: Some new hardware with 9.1 does not reboot easily
Thus spake Andriy Gapon : > on 29/11/2012 17:16 Willem Jan Withagen said the following: >> Would that mean that the regular checkout of stable/9 contains enough >> code to allow "painless" rebooting... > > Not yet... Has this been resolved? I still see a hang on reboot/shutdown on my box (zfs root on USB thumb drive), but I am not sure if the problem is related. Julian ___ 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: Problem with new DRI/DRM support for Intel 855GM
Patrick Lamaizière <[EMAIL PROTECTED]> writes: > Le Mardi 27 Décembre 2005 02:48, Julian Stecklina a écrit : > > Hello, > >> I just discovered that the DRM drivers have been updated and my 855GM >> is now supported by i915.ko. >> >> If I load the module, the driver attaches: > ... >> The problem is easily spotted, as there is only /dev/dri/card1. If I >> try to symlink card1 to card0, the kernel says: >> error: [drm:pid890:drm_unlock] *ERROR* Process 890 using kernel context 0 > > Look this thread : > http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020815.html It seems the PR is unrelated to my problem. Or do I miss something? At least no DRM/DRI problems are reported. I'll try -CURRENT one day or the other. Regards, -- Julian Stecklina When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop. - Alan Perlis ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Problem with new DRI/DRM support for Intel 855GM
Hello, I just discovered that the DRM drivers have been updated and my 855GM is now supported by i915.ko. If I load the module, the driver attaches: drmsub1: mem 0xe800-0xefff,0xfaf0-0xfaf7 at device 2.1 on pci0 info: [drm] AGP at 0xf000 128MB info: [drm] Initialized i915 1.2.0 20041217 But when I start X.org (xorg-server-6.8.99.903), it says: drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed The problem is easily spotted, as there is only /dev/dri/card1. If I try to symlink card1 to card0, the kernel says: error: [drm:pid890:drm_unlock] *ERROR* Process 890 using kernel context 0 (PID 890 is the X server.) while the X.org log file reports: drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::61:00.0 drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::61:00.0 ... (II) I810(0): [drm] Registers = 0xfaf8 (II) I810(0): [drm] Back Buffer = 0xf600 (II) I810(0): [drm] Depth Buffer = 0xf500 (II) I810(0): [drm] ring buffer = 0xf000 (II) I810(0): [drm] textures = 0xf0a54000 (EE) I810(0): [drm] failure adding irq handler (II) I810(0): [drm] removed 1 reserved context for kernel (II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xc5074000 at 0x28783000 The complete log is at: http://www.inf.tu-dresden.de/~s1054849/Xorg.0.log uname -a: FreeBSD dellbeast.localnet 6.0-STABLE FreeBSD 6.0-STABLE #2: Sun Dec 18 05:59:59 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DELLBEAST i386 But anyway: It's very nice to see that 3D acceleration is going to work Real Soon Now(tm) on my laptop. :-) Regards, -- Julian Stecklina When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop. - Alan Perlis ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
