Problem till din faktura : 87-4484524812668
Hej! Åtkomst till ditt konto är begränsat eftersom vi har märkt att du har betalat din faktura tva ganger på samma gång, och det är på grund av ett tekniskt fel. När du bekräftar informationen på kortet, kommer vi att återbetala till ditt konto Detaljer : Beställningsnummer : 87-4484524812668 Mobile operator: Telia Betalas av : Kreditkort Status : Väntar på återbetalning Återbetala process: 1 -ladda ner det bifogade dokumentet och öppna den i ett webbläsarfönster. 2 -öppnad kommer du bli ombedd att följa en uppsättning instruktioner. Tack för ditt förtroende, Vi ses snart på www.telia.se Detta mail har skickats automatiskt. Snälla, inte svara, skulle din förfrågan inte verkställas. Telia se @ 2013 ___ 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: 9.2 panic with wcb4xxp (dahdi-kmod26-2.6.1.r10738)
On Thu, Sep 19, 2013 at 7:35 PM, Harald Schmalzbauer < h.schmalzba...@omnilan.de> wrote: > Hello, > > unloading the kernel module of dahdi-kmod26-2.6.1.r10738 leads to this > panic: > > wcb4xxp0: <6>Did not do the highestorder stuff > <6>dahdi: Detected time shift. > <5>dahdi_echocan_mg2: Registered echo canceler 'MG2' > > Starting asterisk afterwards also leads to panic. > I guess dahdi development stalled, but I wanted to try it because I'd > prefer freeswitch and need BRI support... > Is somebody familiar with dahdi and interested in making it work with > FreeBSD 9.2? > > Thanks, > > -Harry (not subscribed to isdn@) > > > Have you been able to solve the problem? I am running Freeswitch (from git, not port) and dahdi/dahdi-kmod26 (from port) with PRI line (Digium 8 span and single span) without any problems on 9.1. Will test it on 9.2 and get back to you if I see a panic . Amitabh ___ 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: 9.2PRERELEASE ZFS panic in lzjb_compress
One last piece of information I just got: the problem is not specific to LZJB compression. I switched to LZ4 and get the same sort of panic: Fatal trap 12: page fault while in kernel mode cpuid = 8; apic id = 28 fault virtual address = 0xff8581c48000 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8195f6d1 stack pointer= 0x28:0xffcf950ee850 frame pointer= 0x28:0xffcf950ee8f0 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 = 0 (zio_write_issue_hig) trap number = 12 panic: page fault cpuid = 8 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame 0xffcf950ee2e0 kdb_backtrace() at kdb_backtrace+0x37/frame 0xffcf950ee3a0 panic() at panic+0x1ce/frame 0xffcf950ee4a0 trap_fatal() at trap_fatal+0x290/frame 0xffcf950ee500 trap_pfault() at trap_pfault+0x211/frame 0xffcf950ee590 trap() at trap+0x344/frame 0xffcf950ee790 calltrap() at calltrap+0x8/frame 0xffcf950ee790 --- trap 0xc, rip = 0x8195f6d1, rsp = 0xffcf950ee850, rbp = 0xffcf950ee8f0 --- lz4_compress() at lz4_compress+0x81/frame 0xffcf950ee8f0 zio_compress_data() at zio_compress_data+0x92/frame 0xffcf950ee920 zio_write_bp_init() at zio_write_bp_init+0x24b/frame 0xffcf950ee970 zio_execute() at zio_execute+0xc3/frame 0xffcf950ee9b0 taskqueue_run_locked() at taskqueue_run_locked+0x74/frame 0xffcf950eea00 taskqueue_thread_loop() at taskqueue_thread_loop+0x46/frame 0xffcf950eea20 fork_exit() at fork_exit+0x11f/frame 0xffcf950eea70 fork_trampoline() at fork_trampoline+0xe/frame 0xffcf950eea70 --- trap 0, rip = 0, rsp = 0xffcf950eeb30, rbp = 0 --- (I am now trying without any compression.) On Fri, Sep 20, 2013 at 11:25 AM, olivier wrote: > Got another, very similar panic again on recent 9-STABLE (r255602); I > assume the latest 9.2 release candidate is affected too. Anybody have any > idea of what could be causing this, and of a workaround other than turning > compression off? > Unlike the last panic I reported, this one did not occur during a zfs > send/receive operation. There were just a number of processes potentially > writing to disk at the same time. > All hardware is healthy as far as I can tell (memory is ECC and no errors > in logs; zpool status and smartctl show no problems). > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 4; apic id = 24 > cpuid = 51; apic id = 83 > fault virtual address = 0xff8700a9cc65 > fault virtual address = 0xff8700ab0ea9 > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0x8195ff47 > fault code = supervisor read data, page not present > stack pointer= 0x28:0xffcf951390a0 > Fatal trap 12: page fault while in kernel mode > frame pointer= 0x28:0xffcf951398f0 > Fatal trap 12: page fault while in kernel mode > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > instruction pointer = 0x20:0x8195ffa4 > stack pointer= 0x28:0xffcf951250a0 > processor eflags = frame pointer= 0x28:0xffcf951258f0 > interrupt enabled, code segment = base 0x0, limit 0xf, type 0x1b > > resume, IOPL = 0 > cpuid = 28; apic id = 4c > Fatal trap 12: page fault while in kernel mode > = DPL 0, pres 1, long 1, def32 0, gran 1 > current process = 0 (zio_write_issue_hig) > processor eflags = fault virtual address = 0xff8700aa22ac > interrupt enabled, fault code = supervisor read data, page not present > resume, IOPL = 0 > trap number = 12 > instruction pointer = 0x20:0x8195ffa4 > current process = 0 (zio_write_issue_hig) > panic: page fault > cpuid = 4 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame > 0xffcf95138b30 > kdb_backtrace() at kdb_backtrace+0x37/frame 0xffcf95138bf0 > panic() at panic+0x1ce/frame 0xffcf95138cf0 > trap_fatal() at trap_fatal+0x290/frame 0xffcf95138d50 > trap_pfault() at trap_pfault+0x211/frame 0xffcf95138de0 > trap() at trap+0x344/frame 0xffcf95138fe0 > calltrap() at calltrap+0x8/frame 0xffcf95138fe0 > --- trap 0xc, rip = 0x8195ff47, rsp = 0xffcf951390a0, rbp = > 0xffcf951398f0 --- > lzjb_compress() at lzjb_compress+0xa7/frame 0xffcf951398f0 > zio_compress_data() at zio_compress_data+0x92/frame 0xffcf95139920 > zio_write_bp_init() at zio_write_bp_init+0x24b/frame 0xffcf95139970 > zio_execute() at zio_execute+0xc3/frame 0xffcf951399b0 > taskqueue_run_locked() at taskqueue_run_locked+0x74/frame > 0xffcf95139a00 > taskqueue_thread_loop() at taskqueue_thread_loop+0x46/frame > 0xffcf95139a20 > fork_exit() at fork_exit+0x11f/frame 0xffcf95139a70 > fork_trampoline() at fork_trampoline+0xe/frame 0xffcf95139a70 > --- trap 0, rip = 0, rsp = 0xffcf95139b30, rbp = 0 --- >
Re: FreeBSD 9-Stable + Atom D510 Freeze
Gary Palmer [gpal...@freebsd.org] wrote: > It used to be that ports had MAKE_JOBS_SAFE in the Makefile to mark that > the port could be built using parallel compiles with the '-j' argument > to make. It appears that the logic has been switched and now you have > to mark them as MAKE_JOBS_UNSAFE to say that parallel builds shouldn't be > done, indicating that parallel builds are the default now (unless I'm > misreading the code) > > You can try putting > > DISABLE_MAKE_JOBS=yes > > into /etc/make.conf to see if that stops the problem on port builds. > Gary: Making that change worked for me. I built both Subversion and Tshark, my two problem children. The build time was not too much different than without the flag. Only 1 CPU was active with cc1 at a time. I had no 'pfault' states on any entries in top for both builds. I guess that we can close out this issue. Thank you and the list for the suggestion. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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: Rescuing a GPT ZFS boot setup
On Fri, Sep 20, 2013 at 6:59 AM, Volodymyr Kostyrko wrote: > 20.09.2013 10:41, Andy Moran wrote: > >> WIth the 10-ALPHA2 LiveCD, I get: gpart: attrib 'active': Device not configured >>> GPT partitions don't have active attribute. You should omit -i argument. >>> Just run `gpart unset -a active ada0`. >>> >>> -- >>> WBR, Andrey V. Elsukov >>> >>> -- >>> WBR, Andrey V. Elsukov >>> >> >> >> That ran without errors.. but sadly did not solve my problem of the UEFI >> not recognizing it as a bootable disk. I think the problem is my >> particular UEFI doesn't recognize GPT drives that don't have an EFI >> partition on them. >> >> So I gave up. My server has been down for too long. I took half the >> zfs mirror, created it with a MBR partition and installed FreeBSD 9.2 on >> it, and my UEFI can boot it in legacy mode. From there I can mount the >> other half of the mirror and copy files off. A painful process but at >> least I have a way forward. >> > > Please, name your poison on list so that successors can google it in case > someone wants to by the same piece of hardware. For what little it's worth, Lenovo BIOSes that support UEFI and GPT have made the assumption that any GPT partitioned disk is UEFI and fail to see a bootable drive if it is an MBR GPT disk. I have found this fairly easy to work around on my system by having a disk that has traditional partitions with booteasy. I make his my "boot disk" (ada0 with BIOS set to boot from that drive) and then tell booteasy to boot from "Other DIsk". N.B., there is no ZFS involvement here, just working around the boot issue. I should also mention that I received a note that Lenovo may have fixed this in the latest BIOS, but I have not gotten around to testing. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.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: 9.2PRERELEASE ZFS panic in lzjb_compress
Got another, very similar panic again on recent 9-STABLE (r255602); I
assume the latest 9.2 release candidate is affected too. Anybody have any
idea of what could be causing this, and of a workaround other than turning
compression off?
Unlike the last panic I reported, this one did not occur during a zfs
send/receive operation. There were just a number of processes potentially
writing to disk at the same time.
All hardware is healthy as far as I can tell (memory is ECC and no errors
in logs; zpool status and smartctl show no problems).
Fatal trap 12: page fault while in kernel mode
cpuid = 4; apic id = 24
cpuid = 51; apic id = 83
fault virtual address = 0xff8700a9cc65
fault virtual address = 0xff8700ab0ea9
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x8195ff47
fault code = supervisor read data, page not present
stack pointer= 0x28:0xffcf951390a0
Fatal trap 12: page fault while in kernel mode
frame pointer= 0x28:0xffcf951398f0
Fatal trap 12: page fault while in kernel mode
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
instruction pointer = 0x20:0x8195ffa4
stack pointer= 0x28:0xffcf951250a0
processor eflags = frame pointer= 0x28:0xffcf951258f0
interrupt enabled, code segment = base 0x0, limit 0xf, type 0x1b
resume, IOPL = 0
cpuid = 28; apic id = 4c
Fatal trap 12: page fault while in kernel mode
= DPL 0, pres 1, long 1, def32 0, gran 1
current process = 0 (zio_write_issue_hig)
processor eflags = fault virtual address = 0xff8700aa22ac
interrupt enabled, fault code = supervisor read data, page not present
resume, IOPL = 0
trap number = 12
instruction pointer = 0x20:0x8195ffa4
current process = 0 (zio_write_issue_hig)
panic: page fault
cpuid = 4
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/frame
0xffcf95138b30
kdb_backtrace() at kdb_backtrace+0x37/frame 0xffcf95138bf0
panic() at panic+0x1ce/frame 0xffcf95138cf0
trap_fatal() at trap_fatal+0x290/frame 0xffcf95138d50
trap_pfault() at trap_pfault+0x211/frame 0xffcf95138de0
trap() at trap+0x344/frame 0xffcf95138fe0
calltrap() at calltrap+0x8/frame 0xffcf95138fe0
--- trap 0xc, rip = 0x8195ff47, rsp = 0xffcf951390a0, rbp =
0xffcf951398f0 ---
lzjb_compress() at lzjb_compress+0xa7/frame 0xffcf951398f0
zio_compress_data() at zio_compress_data+0x92/frame 0xffcf95139920
zio_write_bp_init() at zio_write_bp_init+0x24b/frame 0xffcf95139970
zio_execute() at zio_execute+0xc3/frame 0xffcf951399b0
taskqueue_run_locked() at taskqueue_run_locked+0x74/frame 0xffcf95139a00
taskqueue_thread_loop() at taskqueue_thread_loop+0x46/frame
0xffcf95139a20
fork_exit() at fork_exit+0x11f/frame 0xffcf95139a70
fork_trampoline() at fork_trampoline+0xe/frame 0xffcf95139a70
--- trap 0, rip = 0, rsp = 0xffcf95139b30, rbp = 0 ---
0x51f47 is in lzjb_compress
(/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/lzjb.c:74).
69 }
70 if (src > (uchar_t *)s_start + s_len - MATCH_MAX) {
71 *dst++ = *src++;
72 continue;
73 }
74 hash = (src[0] << 16) + (src[1] << 8) + src[2];
75 hash += hash >> 9;
76 hash += hash >> 5;
77 hp = &lempel[hash & (LEMPEL_SIZE - 1)];
78 offset = (intptr_t)(src - *hp) & OFFSET_MASK;
dmesg output is at http://pastebin.com/U34fwJ5f
kernel config is at http://pastebin.com/c9HKfcsz
I can provide more information if useful.
Thanks
On Fri, Jul 19, 2013 at 6:52 AM, Volodymyr Kostyrko wrote:
> 19.07.2013 07:04, olivier wrote:
>
>> Hi,
>> Running 9.2-PRERELEASE #19 r253313 I got the following panic
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 22; apic id = 46
>> fault virtual address = 0xff827ebca30c
>> fault code = supervisor read data, page not present
>> instruction pointer = 0x20:0x81983055
>> stack pointer = 0x28:0xffcf75bd60a0
>> frame pointer = 0x28:0xffcf75bd68f0
>> 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 = 0 (zio_write_issue_hig)
>> trap number = 12
>> panic: page fault
>> cpuid = 22
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a/**frame
>> 0xffcf75bd5b30
>> kdb_backtrace() at kdb_backtrace+0x37/frame 0xffcf75bd5bf0
>> panic() at panic+0x1ce/frame 0xffcf75bd5cf0
>> trap_fatal() at trap_fatal+0x290/frame 0xffcf75bd5d50
>> trap_pfault() at trap_pfault+0x211/frame 0xffcf75bd5de0
>> trap() at trap+0x344/frame 0xffcf75bd5fe0
>> calltrap() at calltrap+0x8/frame 0xffcf75bd5fe0
>> --- trap 0xc, rip = 0x81983055, rsp = 0xffcf75bd60a0, rbp =
>> 0xffcf75bd68f0 ---
>> lzjb_compress() at lzjb_compress+0x185/frame 0xffcf75bd68f0
>> zio_compress
Re: FreeBSD 9-Stable + Atom D510 Freeze
Gary Palmer [gpal...@freebsd.org] wrote: > It's not a compiler flag, it's a make flag. make -j n will fork off up to > n compilers to do the build. If you just do "make buildworld" then there > is no parallel compilation. > > It used to be that ports had MAKE_JOBS_SAFE in the Makefile to mark that > the port could be built using parallel compiles with the '-j' argument > to make. It appears that the logic has been switched and now you have > to mark them as MAKE_JOBS_UNSAFE to say that parallel builds shouldn't be > done, indicating that parallel builds are the default now (unless I'm > misreading the code) > > You can try putting > > DISABLE_MAKE_JOBS=yes > > into /etc/make.conf to see if that stops the problem on port builds. > Gary: I don't see that as an option in /usr/share/examples/etc/make.conf. Did you find that one by reading the source code? I will add that to my /etc/make.conf and see if it makes a difference. This issue is very intermittant and may not trigger for weeks or months. I'll repost to the list if any problems show up after setting the flag in my /etc/make.conf Thanks for the help. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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: FreeBSD 9-Stable + Atom D510 Freeze
On 20 September 2013 11:52, Gary Palmer wrote: > On Fri, Sep 20, 2013 at 10:49:28AM -0400, Thomas Laus wrote: >> Gary Palmer [gpal...@freebsd.org] wrote: >> > >> > When building kernel & world do you use the '-j' argument to do parallel >> > builds? AFAIK thats not done by default, but it is for some ports. >> > >> Gary: >> >> I just use the system defaults when building anything. If there is a >> '-j' argument passed to the compiler, I was not the one that did it. >> Does this mean that the port building process needs to determine the >> processor type in the configure stage? I only use portmaster to keep >> the ports updated. I don't know of a global hook that will change the >> compiler build flags in portmaster. > > Hi Tim, > > It's not a compiler flag, it's a make flag. make -j n will fork off up to > n compilers to do the build. If you just do "make buildworld" then there > is no parallel compilation. > > It used to be that ports had MAKE_JOBS_SAFE in the Makefile to mark that > the port could be built using parallel compiles with the '-j' argument > to make. It appears that the logic has been switched and now you have > to mark them as MAKE_JOBS_UNSAFE to say that parallel builds shouldn't be > done, indicating that parallel builds are the default now (unless I'm > misreading the code) > > You can try putting > > DISABLE_MAKE_JOBS=yes > > into /etc/make.conf to see if that stops the problem on port builds. > Alternatively I think you could do > > portmaster -m DISABLE_MAKE_JOBS=yes > > However you'd have to do that each time you run portmaster. I think > putting > > PM_MAKE_ARGS="DISABLE_MAKE_JOBS=yes" > > in your .portmasterrc may do the same thing (not tried it). > > Note: this is NOT a fix. If it works, it merely stops the ports builder > from triggering the problem by not doing parallel compiles. The compiles > will also take longer. > I believe that both world/kernel & ports will honour MAKE_JOBS_NUMBER=1 #(in /etc/make.conf) which should restrict all builds to 1 "parallel" thread, yes? -- -- ___ 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: FreeBSD 9-Stable + Atom D510 Freeze
On Fri, Sep 20, 2013 at 10:49:28AM -0400, Thomas Laus wrote: > Gary Palmer [gpal...@freebsd.org] wrote: > > > > When building kernel & world do you use the '-j' argument to do parallel > > builds? AFAIK thats not done by default, but it is for some ports. > > > Gary: > > I just use the system defaults when building anything. If there is a > '-j' argument passed to the compiler, I was not the one that did it. > Does this mean that the port building process needs to determine the > processor type in the configure stage? I only use portmaster to keep > the ports updated. I don't know of a global hook that will change the > compiler build flags in portmaster. Hi Tim, It's not a compiler flag, it's a make flag. make -j n will fork off up to n compilers to do the build. If you just do "make buildworld" then there is no parallel compilation. It used to be that ports had MAKE_JOBS_SAFE in the Makefile to mark that the port could be built using parallel compiles with the '-j' argument to make. It appears that the logic has been switched and now you have to mark them as MAKE_JOBS_UNSAFE to say that parallel builds shouldn't be done, indicating that parallel builds are the default now (unless I'm misreading the code) You can try putting DISABLE_MAKE_JOBS=yes into /etc/make.conf to see if that stops the problem on port builds. Alternatively I think you could do portmaster -m DISABLE_MAKE_JOBS=yes However you'd have to do that each time you run portmaster. I think putting PM_MAKE_ARGS="DISABLE_MAKE_JOBS=yes" in your .portmasterrc may do the same thing (not tried it). Note: this is NOT a fix. If it works, it merely stops the ports builder from triggering the problem by not doing parallel compiles. The compiles will also take longer. Regards, Gary ___ 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"
ports/gimp mostly broken - ports/182069: [PATCH] devel/py-gobject: Fix GFlags messages
Greetings, I sent a PR for troubles I was having with ports/gimp, and other programs (ports) that depend on lang/python (Python-2.7), after an upgrade. In my quest to find a resolution to this problem, I stumbled on to this PR (patch): ports/182069: [PATCH] devel/py-gobject: Fix GFlags messages ( http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182069 ). Which was submitted on the 14th of this month, and appears to reconcile th(is|ese) issues. What is the "patch schedule"? In other words; when do patches that appear to be good, and have no apparent consequences, get pushed into the ports tree? Thank you for all your time, and consideration. --Chris ___ 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: FreeBSD 9-Stable + Atom D510 Freeze
Gary Palmer [gpal...@freebsd.org] wrote: > > When building kernel & world do you use the '-j' argument to do parallel > builds? AFAIK thats not done by default, but it is for some ports. > Gary: I just use the system defaults when building anything. If there is a '-j' argument passed to the compiler, I was not the one that did it. Does this mean that the port building process needs to determine the processor type in the configure stage? I only use portmaster to keep the ports updated. I don't know of a global hook that will change the compiler build flags in portmaster. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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: FreeBSD 9-Stable + Atom D510 Freeze
On Fri, Sep 20, 2013 at 09:12:09AM -0400, Thomas Laus wrote: > > Tom, > > I have had multiple D510's and now D525's that are part of my test > > systems, all are 4GB machines and all run the latest (ie 2 days old) 9.X > > Stable. They're faultless. I have a D510 in production serving 30 > > users - yes its a 1G system running, sendmail, squid, samba as PDC. > > It's been in place for at least 7 months and runs without any hiccups. > > > > Though I would point out that the Atom processor does NOT do out of > > order processing, so a VIA motherboard that is of lower GHz builds > > worlds/ports in less time that a supposedly faster Atom. > > > > Your question re HT, yes HT introduces some additional latency, but is > > unlikely to be the problem. > > > Thanks for the information about the HT CPU's. I asked the question to the > group because I did not know if they were functionally any different than a > traditional CPU. I successfully built my problem port, Tshark, yesterday > while monitoring 'top' on another console. I observed that all 4 cpu's were > in service for the build and at times were running at 100 percent each. The > State column on all 4 occasionally showed a 'pfault' on all 4 but recovered > and the build continued to successful completion. > > > When I experience something like spurious reboots and it is definately > > not hardware, then I delete /usr/src and /usr/ports and perform a > > complete rebuild. (Yes seriously, and on the Atom's we're talking days, > > aren't we :) ) > > > I have been using this Atom D510 since it was released about 3 years ago. It > ran on FreeBSD 8-Stable until about a month ago. I installed an Intel 520 > SSD and loaded a fresh copy of a FreeBSD 9 Snapshot. After getting the > source and ports tarballs, I used svnup to bring both up to date. I built > and installed world and the kernel to bring me up to Stable. I rebuilt all > of my ports using Portmaster. > > The spurious reboot issue existed for the last 3 years when running FreeBSD-8 > Stable. I never had the problem building world or kernel. It only occurred > when building some ports. Subversion and Tshark more often than others. > FreeBSD 9-Stable was frozen when I tried to build tshark, but I was able to > build it OK yesterday. Everything hardware related other than the Atom > microprocessor and the Intel motherboard itself is new. The OS is now a > different version and all of the source was rebuilt monthly. The ports have > been been built many times in the last 3 years. When building kernel & world do you use the '-j' argument to do parallel builds? AFAIK thats not done by default, but it is for some ports. Gary ___ 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: Rescuing a GPT ZFS boot setup
20.09.2013 10:41, Andy Moran wrote: WIth the 10-ALPHA2 LiveCD, I get: gpart: attrib 'active': Device not configured GPT partitions don't have active attribute. You should omit -i argument. Just run `gpart unset -a active ada0`. -- WBR, Andrey V. Elsukov -- WBR, Andrey V. Elsukov That ran without errors.. but sadly did not solve my problem of the UEFI not recognizing it as a bootable disk. I think the problem is my particular UEFI doesn't recognize GPT drives that don't have an EFI partition on them. So I gave up. My server has been down for too long. I took half the zfs mirror, created it with a MBR partition and installed FreeBSD 9.2 on it, and my UEFI can boot it in legacy mode. From there I can mount the other half of the mirror and copy files off. A painful process but at least I have a way forward. Please, name your poison on list so that successors can google it in case someone wants to by the same piece of hardware. -- Sphinx of black quartz, judge my vow. ___ 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: Possible kqueue related issue on STABLE/RC.
Le Thu, 12 Sep 2013 10:36:43 +0300, Konstantin Belousov a écrit : Hello, > Might be, your issue is that some filesystems do not care about proper > locking mode for the fifos. UFS carefully disables shared locking for > VFIFO, but it seems ZFS is not. I can propose the following band-aid, > which could help you. > > I have no idea is it the same issue as the kqueue panic. > > diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c > index c53030a..00bd998 100644 > --- a/sys/kern/vfs_vnops.c > +++ b/sys/kern/vfs_vnops.c > @@ -267,6 +267,8 @@ vn_open_vnode(struct vnode *vp, int fmode, struct > ucred *cred, return (error); > } > } > + if (vp->v_type == VFIFO && VOP_ISLOCKED(vp) != LK_EXCLUSIVE) > + vn_lock(vp, LK_UPGRADE | LK_RETRY); > if ((error = VOP_OPEN(vp, fmode, cred, td, fp)) != 0) > return (error); > > @@ -358,7 +360,7 @@ vn_close(vp, flags, file_cred, td) > struct mount *mp; > int error, lock_flags; > > - if (!(flags & FWRITE) && vp->v_mount != NULL && > + if (vp->v_type != VFIFO && !(flags & FWRITE) && > vp->v_mount != NULL && vp->v_mount->mnt_kern_flag & > MNTK_EXTENDED_SHARED) lock_flags = LK_SHARED; > else Hmmm, So what is the fix for 9.2-STABLE ? As far I can see there is no function vn_open_vnode() here and I don't see where I should patch. I see this panic too (with STABLE of today), while using poudriere + ZFS like Jimmy. Thanks, regards ___ 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: FreeBSD 9-Stable + Atom D510 Freeze
> Tom, > I have had multiple D510's and now D525's that are part of my test > systems, all are 4GB machines and all run the latest (ie 2 days old) 9.X > Stable. They're faultless. I have a D510 in production serving 30 > users - yes its a 1G system running, sendmail, squid, samba as PDC. > It's been in place for at least 7 months and runs without any hiccups. > > Though I would point out that the Atom processor does NOT do out of > order processing, so a VIA motherboard that is of lower GHz builds > worlds/ports in less time that a supposedly faster Atom. > > Your question re HT, yes HT introduces some additional latency, but is > unlikely to be the problem. > Thanks for the information about the HT CPU's. I asked the question to the group because I did not know if they were functionally any different than a traditional CPU. I successfully built my problem port, Tshark, yesterday while monitoring 'top' on another console. I observed that all 4 cpu's were in service for the build and at times were running at 100 percent each. The State column on all 4 occasionally showed a 'pfault' on all 4 but recovered and the build continued to successful completion. > When I experience something like spurious reboots and it is definately > not hardware, then I delete /usr/src and /usr/ports and perform a > complete rebuild. (Yes seriously, and on the Atom's we're talking days, > aren't we :) ) > I have been using this Atom D510 since it was released about 3 years ago. It ran on FreeBSD 8-Stable until about a month ago. I installed an Intel 520 SSD and loaded a fresh copy of a FreeBSD 9 Snapshot. After getting the source and ports tarballs, I used svnup to bring both up to date. I built and installed world and the kernel to bring me up to Stable. I rebuilt all of my ports using Portmaster. The spurious reboot issue existed for the last 3 years when running FreeBSD-8 Stable. I never had the problem building world or kernel. It only occurred when building some ports. Subversion and Tshark more often than others. FreeBSD 9-Stable was frozen when I tried to build tshark, but I was able to build it OK yesterday. Everything hardware related other than the Atom microprocessor and the Intel motherboard itself is new. The OS is now a different version and all of the source was rebuilt monthly. The ports have been been built many times in the last 3 years. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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 using mergemaster for 10-alpha
On 20/09/2013 19:39, Bryan Drewery wrote: On Fri, Sep 20, 2013 at 03:38:17PM +0930, Shane Ambler wrote: When using mergemaster with -a I get the following error *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot install: illegal option -- l *** FATAL ERROR: Cannot 'cd' to /home/shane/Projects/f10-test/src and install files to the temproot environment See /usr/src/UPDATING entry 20130425 UPDATING describes mergemster -p as the issue and installing the new version as a fix. The new version fixes the fatal error above but it doesn't honour the -D option so doesn't install anything into /mnt still leaving me with manually copying from temproot. ___ 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 using mergemaster for 10-alpha
On Fri, Sep 20, 2013 at 03:38:17PM +0930, Shane Ambler wrote:
> I have setup a few machines in the past from CD installer and my current
> machine started with CD install and was then updated from source.
> Currently my machine runs 9.1-RELEASE-p3
>
> Yesterday I started to setup a clean 10.0 install onto a new drive that
> I can boot from to test ports building with, but had trouble running
> mergemaster to get the config files into place. I manually copied the
> /etc files from /var/tmp/temproot to get the system running.
>
> The steps I used are based on the handbook upgrade steps but I don't
> see any variations to do a clean install from source (I created empty
> src.conf and make.conf to prevent using my current files) -
>
> setenv TOPDIR ~/Projects/f10-test
> setenv TMPTESTROOT /mnt
> setenv MAKEOBJDIRPREFIX ${TOPDIR}/obj
> cd ${TOPDIR}
> svn co svn://svn0.us-west.FreeBSD.org/base/head src
> touch make.conf
> touch src.conf
> setenv __MAKE_CONF ${TOPDIR}/make.conf
> setenv SRCCONF ${TOPDIR}/src.conf
> cd ${TOPDIR}/src
> make -j4 buildworld
> make -j4 buildkernel
> mount /dev/da4p3 ${TMPTESTROOT}
> make installkernel DESTDIR=${TMPTESTROOT}
> mergemaster -p -a -m ${TOPDIR}/src -D ${TMPTESTROOT}
> make installworld DESTDIR=${TMPTESTROOT}
> mergemaster -a -m ${TOPDIR}/src -D ${TMPTESTROOT}
>
>
>
> When using mergemaster with -a I get the following error
>
>
> *** Creating the temporary root environment in /var/tmp/temproot
> *** /var/tmp/temproot ready for use
> *** Creating and populating directory structure in /var/tmp/temproot
>
> install: illegal option -- l
> usage: install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
> [-o owner] file1 file2
> install [-bCcMpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
> [-o owner] file1 ... fileN directory
> install -d [-v] [-g group] [-m mode] [-o owner] directory ...
>
>*** FATAL ERROR: Cannot 'cd' to /home/shane/Projects/f10-test/src and
> install files to
>the temproot environment
See /usr/src/UPDATING entry 20130425
>
> ___
> 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"
pgpIPRopjCqsN.pgp
Description: PGP signature
Re: Rescuing a GPT ZFS boot setup
On Sep 19, 2013, at 8:16 PM, "Andrey V. Elsukov" wrote: > On 20.09.2013 06:34, Andy Moran wrote: >> WIth the 10-ALPHA2 LiveCD, I get: >> >> gpart: attrib 'active': Device not configured >> > > GPT partitions don't have active attribute. You should omit -i argument. > Just run `gpart unset -a active ada0`. > > -- > WBR, Andrey V. Elsukov > > -- > WBR, Andrey V. Elsukov That ran without errors.. but sadly did not solve my problem of the UEFI not recognizing it as a bootable disk. I think the problem is my particular UEFI doesn't recognize GPT drives that don't have an EFI partition on them. So I gave up. My server has been down for too long. I took half the zfs mirror, created it with a MBR partition and installed FreeBSD 9.2 on it, and my UEFI can boot it in legacy mode. From there I can mount the other half of the mirror and copy files off. A painful process but at least I have a way forward. Thanks for the suggestions. --Andy ___ 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"
