Re: What do you use for kernel debugging?
There's also something for XHCI. Please please write it for freebsd. :) -a On 30 September 2014 21:45, O'Connor, Daniel wrote: > > On 1 Oct 2014, at 0:14, Julian Elischer wrote: >> Unfortunately you can't use a USB serial as it requires the USB stack >> be working before it can be used.. >> similar with ethernet connected debugging which requires that the >> driver for the ethernet hardware support it. >> (which why we don't have it in the tree though it has been done >> several times in the past). > > There IS a USB debug standard, Linux has some code to support it. > > I am not sure what percentage of hardware has it hooked up though (the host > controller has a designated debug port but it could physically be anything). > > http://www.coreboot.org/EHCI_Debug_Port > > The hardware is bit more expensive than a null modem or firewire cable though > :( > > Regards, > Daniel O’Connor > > Senior Software Engineer > Isilon Platforms Team > > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What do you use for kernel debugging?
On 1 Oct 2014, at 0:14, Julian Elischer wrote: > Unfortunately you can't use a USB serial as it requires the USB stack > be working before it can be used.. > similar with ethernet connected debugging which requires that the > driver for the ethernet hardware support it. > (which why we don't have it in the tree though it has been done > several times in the past). There IS a USB debug standard, Linux has some code to support it. I am not sure what percentage of hardware has it hooked up though (the host controller has a designated debug port but it could physically be anything). http://www.coreboot.org/EHCI_Debug_Port The hardware is bit more expensive than a null modem or firewire cable though :( Regards, Daniel O’Connor Senior Software Engineer Isilon Platforms Team ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg/ports system terribly messed up?
On Tuesday, September 30, 2014 8:13:01 AM O. Hartmann wrote: > Hello. > > I just made the last update of the ports yesterday (I use portmaster -da > performing this task) and obviously or superficially everything went all > right. > It's portmaster actually. While it -usually- works great, I've noticed that occassionally it loops like that. kill the script, upgrade the port that is looping. That usually fixes it. -- Chuck Burns ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] alc(4) QAC AR816x/AR817x ethernet controller support
On Tue, Sep 30, 2014 at 10:57:41AM +0900, Yonghyeon PYUN wrote: > Hi, > I've added support for QAC AR816x/AR817x ethernet controllers. It > passed my limited testing and I need more testers. You can find > patches from the following URLs. > > http://people.freebsd.org/~yongari/alc/pci.quirk.diff > and > http://people.freebsd.org/~yongari/alc/alc.diff.20140930 > > pci.qurik.diff is to workaround silicon bug of AR816x. Without it > MSI/MSIX interrupt wouldn't work. If you just want to use > legacy INTx interrupt you don't have to apply it but you have to > tell alc(4) not to use MSI/MSIX interrupt with tunables( > hw.alc.msi.disable and hw.alc.msix_disable). > > alc.diff.20140930 will add support for AR8161/AR8162/AR8171/AR8172 > and E2200 controllers. It supports all hardware features except > RSS. If you have any QAC AR816x/AR817x or old AR813x/AR815x > controllers please test and report how the diff works for you. > Thanks. http://people.freebsd.org/~yongari/alc/pci.quirk.diff http://people.freebsd.org/~yongari/alc/alc.diff.20141001 Patch updated to address link establishment issue. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Looping during boot-up process in FreeBSD-11 current
On 9/30/2014 at 7:25 PM José Pérez Arauzo wrote: |[snip] |Try the 271146, |[snip] = I installed the 10.0 release CD. Then (after installing pkg, svn, etc.): cd /usr/src svn update -r271146 make buildkernel make installkernel reboot I got to the login prompt, so it did not exhibit the looping issue I've experienced. /usr/src/UPDATING shows 20140708 p7 as the latest patch for the source. dmesg (with boot -v) follows: (note: when I boot 11.0-current with boot -v, the looping begins right after the place where the "GEOM: new disk cd0" line appears in the dmesg below) Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-RELEASE-p7 #0 r271146: Tue Sep 30 16:38:12 EDT 2014 root@a31pf:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Preloaded elf kernel "/boot/kernel/kernel" at 0xc1678000. Calibrating TSC clock ... TSC clock: 1698592154 Hz CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.70GHz (1698.59-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Family = 0xf Model = 0x2 Stepping = 4 Features=0x3febf9ff Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 64 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 8 KB, 4-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 512 KB, 8-way set associative, sectored cache, 64 byte line size real memory = 1073741824 (1024 MB) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x01826000 - 0x3ee0efff, 1029607424 bytes (251369 pages) avail memory = 1029230592 (981 MB) XEN: CPU 0 has VCPU ID 4294967295 bios32: Found BIOS32 Service Directory header at 0xc00f7030 bios32: Entry = 0xfd7e0 (c00fd7e0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd770+0x18e pnpbios: Found PnP BIOS data at 0xc00f7090 pnpbios: Entry = f:9d76 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: ULE: setup cpu 0 wlan: <802.11 Link Layer> snd_unit_init() u=0x00ff8000 [512] d=0x7c00 [32] c=0x03ff [1024] feeder_register: snd_unit=-1 snd_maxautovchans=16 latency=5 feeder_rate_min=1 feeder_rate_max=2016000 feeder_rate_round=25 Hardware, VIA Nehemiah Padlock RNG: VIA Padlock RNG not present Hardware, Intel IvyBridge+ RNG: RDRAND is not present kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled nfslock: pseudo-device null: Falling back to random adaptor random: initialized VESA: INT 0x10 vector 0xc000:0x206c VESA: information block 56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 0010 00 01 ff 03 00 01 19 01 00 01 2f 01 00 01 34 01 0020 00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 0030 94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01 0040 b2 01 b3 01 b4 01 b5 01 b6 01 c2 01 c3 01 c4 01 0050 c5 01 c6 01 00 01 83 01 84 01 85 01 86 01 01 01 0060 10 01 11 01 12 01 21 01 03 01 13 01 14 01 15 01 0070 22 01 05 01 16 01 17 01 18 01 23 01 07 01 19 01 0080 1a 01 1b 01 24 01 40 01 41 01 42 01 43 01 44 01 0090 72 01 73 01 74 01 75 01 76 01 ff ff 00 00 00 00 00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 41 54 49 20 4d 4f 42 49 4c 49 54 59 20 52 41 44 0110 45 4f 4e 20 37 35 30 30 00 41 54 49 20 54 65 63 0120 68 6e 6f 6c 6f 67 69 65 73 20 49 6e 63 2e 00 50 0130 37 20 20 00 30 31 2e 30 30 00 00 00 00 00 00 00 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 60 mode(s) found VESA: v2.0, 65472k memory, flags:0x1, mode table:0xe3ee6022 (122) VESA: ATI MOBILITY RADEON 7500 VESA: ATI Technologies Inc. P7 01.00 io: hpt27xx: RocketRAID 27xx controller driver v1.1 hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 hptnr: R750/DC7280 controller driver v1.0 ACPI: RSDP 0xf7060 00024 (v02 IBM ) ACPI: XSDT 0
Re: Looping during boot-up process in FreeBSD-11 current
> On Sep 30, 2014, at 10:31, "José Pérez Arauzo" wrote: > > Hi Garrett, > > On Tue, 30 Sep 2014 09:57:19 -0700, Garrett Cooper wrote >>> On Sep 30, 2014, at 7:44, "Mike." wrote: >>> >>> On 9/29/2014 at 11:04 PM José Pérez Arauzo wrote: >>> >>> |This encoded message has been converted to an attachment. >>> | >>> |Hi Mike, >>> | >>> |On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote >>> [...] >>> |So that should put a time bracket on the issue, >>> |roughly the first half of 2014. >>> | >>> |can you boot 271146? Just buildkernel and installkernel. Thank >>> |you. >>> = >>> >>> There doesn't seem to be much, if any, interest on the part of the >>> FreeBSD developers in fixing this recently-introduced issue with >>> booting up FreeBSD. >>> >>> Since I experience the problem only on the one notebook of mine, I'll >>> just re-purpose that notebook for OpenBSD and try to find another old >>> notebook that works with FreeBSD. Seems like the path of least >>> resistance for me >> >> Did you boot with boot -d, using a stripped down kernel, and without >> SMP like I suggested in another post? > > This suggestion was address to me, not Mike. :) > > I tried, as you suggested, I can reach vfs_mountroot if I don't > include AHCI, so it must be that. > > Now I'm trying to take out SMP and add extra debugging things here and > there. Another suggestion might be to compile the driver as a module or vice versa -- what happens then? Why this is slightly more interesting sometimes is that compiling drivers into the kernel statically allows compilers to optimize out code, which may or may not positively effect driver runtime (performance and functionality wise). It shouldn't affect driver load order though; that should be deterministic as long as the drivers and hardware (firmware and configuration) don't change. > I'm not sure what I'm doing, but I do it anyway. In the worst case I'm > learning something. > > Thank you for your suggestions! NP! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Looping during boot-up process in FreeBSD-11 current
Hi Garrett, On Tue, 30 Sep 2014 09:57:19 -0700, Garrett Cooper wrote > > On Sep 30, 2014, at 7:44, "Mike." wrote: > > > > On 9/29/2014 at 11:04 PM José Pérez Arauzo wrote: > > > > |This encoded message has been converted to an attachment. > > | > > |Hi Mike, > > | > > |On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote > > [...] > > |So that should put a time bracket on the issue, > > |roughly the first half of 2014. > > | > > |can you boot 271146? Just buildkernel and installkernel. Thank > > |you. > > = > > > > There doesn't seem to be much, if any, interest on the part of the > > FreeBSD developers in fixing this recently-introduced issue with > > booting up FreeBSD. > > > > Since I experience the problem only on the one notebook of mine, I'll > > just re-purpose that notebook for OpenBSD and try to find another old > > notebook that works with FreeBSD. Seems like the path of least > > resistance for me > > Did you boot with boot -d, using a stripped down kernel, and without > SMP like I suggested in another post? This suggestion was address to me, not Mike. :) I tried, as you suggested, I can reach vfs_mountroot if I don't include AHCI, so it must be that. Now I'm trying to take out SMP and add extra debugging things here and there. I'm not sure what I'm doing, but I do it anyway. In the worst case I'm learning something. Thank you for your suggestions! BR, -- José Pérez Arauzo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Looping during boot-up process in FreeBSD-11 current
> On Sep 30, 2014, at 10:17, "Mike." wrote: > > On 9/30/2014 at 9:57 AM Garrett Cooper wrote: > > > |Did you boot with boot -d, using a stripped down kernel, > |and without SMP like I suggested in another post? > = > > Unfortunately, this is the first message of yours that I've seen on > this topic. I even checked the mailing list archives > ( > http://lists.freebsd.org/pipermail/freebsd-current/2014-September/auth > or.html ) > and I did not see any other message from you. > > Can you resend it? Look for the recent thread titled "what do you use for kernel debugging". It sounds like both you an Jose have run into similar problems recently with mobile hardware. > (I just tried boot -d and found myself in strange territory, a > debugger?) Ah, crud. I meant boot -v (verbose boot) -- sorry bout that :). Cheers! -Garrett PS I would help a bit if I still had netbook hardware and the time to help, but I don't have the former and seem to be short on the latter recently. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Looping during boot-up process in FreeBSD-11 current
Hi Mike, On Tue, 30 Sep 2014 10:44:11 -0400, Mike. wrote > On 9/29/2014 at 11:04 PM José Pérez Arauzo wrote: > > |This encoded message has been converted to an attachment. > | > |Hi Mike, > | > |On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote > [...] > |So that should put a time bracket on the issue, > |roughly the first half of 2014. > | > |can you boot 271146? Just buildkernel and installkernel. Thank > |you. > = > > There doesn't seem to be much, if any, interest on the part of the > FreeBSD developers in fixing this recently-introduced issue with > booting up FreeBSD. The glass is half full. Always. Did you get it to boot with 271146 as I suggested? This would really help and see if we are hitting the same issue or not. > Since I experience the problem only on the one notebook of mine, I'll > just re-purpose that notebook for OpenBSD and try to find another old > notebook that works with FreeBSD. Seems like the path of least > resistance for me C'mon, don't give up now. Try the 271146, I'm trying to find out where it exactly loops. I've done some testing and might be it'AHCI actually. Warner Losh (the maintainer) sent at least 3 messages about this, he's very cooperative I think. I'll try the no-SMP thing now just to see how it works. BR, -- José Pérez Arauzo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Looping during boot-up process in FreeBSD-11 current
On 9/30/2014 at 9:57 AM Garrett Cooper wrote: |Did you boot with boot -d, using a stripped down kernel, |and without SMP like I suggested in another post? = Unfortunately, this is the first message of yours that I've seen on this topic. I even checked the mailing list archives ( http://lists.freebsd.org/pipermail/freebsd-current/2014-September/auth or.html ) and I did not see any other message from you. Can you resend it? (I just tried boot -d and found myself in strange territory, a debugger?) thx. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Looping during boot-up process in FreeBSD-11 current
> On Sep 30, 2014, at 7:44, "Mike." wrote: > > On 9/29/2014 at 11:04 PM José Pérez Arauzo wrote: > > |This encoded message has been converted to an attachment. > | > |Hi Mike, > | > |On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote > [...] > |So that should put a time bracket on the issue, > |roughly the first half of 2014. > | > |can you boot 271146? Just buildkernel and installkernel. Thank > |you. > = > > There doesn't seem to be much, if any, interest on the part of the > FreeBSD developers in fixing this recently-introduced issue with > booting up FreeBSD. > > Since I experience the problem only on the one notebook of mine, I'll > just re-purpose that notebook for OpenBSD and try to find another old > notebook that works with FreeBSD. Seems like the path of least > resistance for me Did you boot with boot -d, using a stripped down kernel, and without SMP like I suggested in another post? Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] nscd
On 09/30/14 04:17, Eggert, Lars wrote: When I start "nscd -n -s -t" and then run top in another shell, top takes ~10 seconds to start up every time; if nscd did its thing, repeat invocations should be much faster. nscd doesn't seem to see any activity either, based on its log: The -t switch will only work after you change the #ifdef in debug.h to define the trace routines, and even then it doesn't give you too much information other than what methods are called. nscd could really use some debug logging but that's a whole other issue. As for why it's not working in your setup I can't say. Have you tried testing with getent to see which database is taking so long, and is that 10 seconds before or after the patch? By default nscd is suppose to timeout after 8 seconds so there might be something else going on in nscd which you're being affected by which is now being exposed. What I do know is when the timeout value is unusually large (in this case due to the bad memcpy) the kevent timer registered at the end of nscd.c:process_socket_event() doesn't seem to be honored. My guess is inside the kernel it's setting it to 0 if it exceeds some threshold so it immediately gets triggered. It's basically shooting itself in the head right when a connection to the socket is made. You can test this by running 'socat UNIX-CONNECT:/var/run/nscd -'. You'll notice that it instantly disconnects without the patch, then 8 seconds with it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What do you use for kernel debugging?
On 9/29/14, 8:31 AM, José Pérez Arauzo wrote: Hi Garrett, On Sun, 28 Sep 2014 13:38:24 -0700, Garrett Cooper wrote On Sep 28, 2014, at 0:34, José Pérez Arauzo wrote: Hello, I am trying to track down a (deadlock?) issue in CURRENT via DDB. The kernel does not complete hw probes on my Acer V5. I get stuck on apic_isr looping which leads nowhere. So I thought maybe things improve if I debug from another machine. What do you use for kernel debugging? According to the handbook kgdb over serial is a good option, do you agree? I'm on a netbook with no ethernet and no option for firewire: can I have a USB / nullmodem setup to work? I have no old-style uarts hardware anymore, as the handbook suggests... Any idea is welcome before I buy extra hw. I have a USB to serial showing up as /dev/cuaU0, do I need to grab another one and a nullmodem cable or there are better alternatives? Thank you. There was some discussion recently about this on an internal list. Unfortunately no, there isn’t a usable way, but there were some interesting viable methods that came up (which haven’t been implemented): ethernet/sound/xHCI. Your best bet, as others have noted, is to use boot -d, use WITNESS to spot locking issues, dtrace to isolate which section of code there are problems, and finally use one of the DEBUG options noted in /sys/conf/NOTES and /sys//conf/NOTES . Hope that helps! Well, it's not so encouraging but I'll work on it. Do you mean that we can get rid of chapter 10.5 of the handbook (On-Line Kernel Debugging Using Remote GDB)? no it works when you have the hardware. but modern laptops have so little hardware.. we really will have to define an API/ABI to add to teh current ethernet driver API so that we can do network based debugging. it's getting harder and harder to find alternatives. (though debugging a VM works well). Just to have it clear, when people develop or fix drivers in FreeBSD their only option is to use the above mentioned tools, as they have no access to a live, on-line kernel debugger?? It's disappointing, to say the least! I hope Dcons + 1394 works where it's applicable. BR, -- José Pérez Arauzo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What do you use for kernel debugging?
On 9/29/14, 9:35 AM, Garrett Cooper wrote: On Sep 28, 2014, at 17:51, "José Pérez Arauzo" wrote: Hi Benjamin, On Sun, 28 Sep 2014 15:54:36 -0400 (EDT), Benjamin Kaduk wrote On Sun, 28 Sep 2014, José Pérez Arauzo wrote: Hello, I am trying to track down a (deadlock?) issue in CURRENT via DDB. The kernel does not complete hw probes on my Acer V5. I get stuck on apic_isr looping which leads nowhere. So I thought maybe things improve if I debug from another machine. What do you use for kernel debugging? According to the handbook kgdb over serial is a good option, do you agree? I'm on a netbook with no ethernet and no option for firewire: can I have a USB / nullmodem setup to work? with hardware related debugging it's always hard.. in the past I used serial and firewire but they are getting hard to find. if it wasn't hardware related then using bhyve with it's gdb debugger hook works fine. Unfortunately you can't use a USB serial as it requires the USB stack be working before it can be used.. similar with ethernet connected debugging which requires that the driver for the ethernet hardware support it. (which why we don't have it in the tree though it has been done several times in the past). You cannot. Oh, what a shame. Why not? Is it because you need hardware probe to be over to use it? Today I bought a shining USB to USB thingy made by Hama, and guess what? It's not supported on FBDS, altought uplcom(4) reports support for Hama USB to RS232 brother. The bootloader doesn't support USB debugging and I'm pretty sure the devices don't support local/remote debugging :(.. I'll do some poking around. I'll talk to some SMEs and see if I can write up a TODO list for a wiki page. Cheers! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg/ports system terribly messed up?
Am 30.09.2014 um 08:13 schrieb O. Hartmann: > > Hello. > > I just made the last update of the ports yesterday (I use portmaster -da > performing this > task) and obviously or superficially everything went all right. > > I'm running on the boxes in question most recent CURRENT. > > On one system, a subsequent start of updating ports starts to freak out when > updateing > lang/gcc: it loops over and over on some ports already updated, especially > devel/binutils, but the port looping on isn't specific and varies. > > On every CURRENT box I tried this morning to update the ports again, I find > this > frsutrating message (depends on installation, but it seems in principal the > same, only > the affected ports in dependency chain varies): > > ===>>> Gathering distinfo list for installed ports > > ===>>> Starting check of installed ports for available updates > ===>>> Launching child to update openldap-sasl-client-2.4.39_2 to > openldap-sasl-client-2.4.40 > > ===>>> All >> openldap-sasl-client-2.4.39_2 (1/1) > > ===>>> Currently installed version: openldap-sasl-client-2.4.39_2 > ===>>> Port directory: /usr/ports/net/openldap24-sasl-client > > ===>>> Launching 'make checksum' for net/openldap24-sasl-client in background > ===>>> Gathering dependency list for net/openldap24-sasl-client from ports > ===>>> Launching child to install > net/openldap24-sasl-client/../../ports-mgmt/pkg > > ===>>> All >> openldap-sasl-client-2.4.39_2 >> > net/openldap24-sasl-client/../../ports-mgmt/pkg (2/2) > > ===>>> Port directory: > /usr/ports/net/openldap24-sasl-client/../../ports-mgmt/pkg > > > ===>>> Update for net/openldap24-sasl-client/../../ports-mgmt/pkg failed > ===>>> Aborting update > > ===>>> Update for openldap-sasl-client-2.4.39_2 failed > ===>>> Aborting update > > You have new mail. > > > This isn't, so far, OpenLDAP specific, on other systems without LDAP the > update fails on > another port. > > Oliver > I am afraid I am observing something similar to what Oliver reported. On a CURRENT box (r272295) I get the following for all ports execpt pkg itself: portmaster indexinfo-0.2 ===>>> Currently installed version: indexinfo-0.2 ===>>> Port directory: /usr/ports/print/indexinfo ===>>> Gathering distinfo list for installed ports ===>>> Launching 'make checksum' for print/indexinfo in background ===>>> Gathering dependency list for print/indexinfo from ports ===>>> Launching child to install print/indexinfo/../../ports-mgmt/pkg ===>>> indexinfo-0.2 >> print/indexinfo/../../ports-mgmt/pkg (1/1) ===>>> Port directory: /usr/ports/print/indexinfo/../../ports-mgmt/pkg ===>>> Update for print/indexinfo/../../ports-mgmt/pkg failed ===>>> Aborting update When I try to build other ports, it does not complain about ports-mgmt/pkg, but something else in the dependency list. For example, for net/mpich2 it complains about devel/binutils ... This does not happen on my other CURRENT boxes (they build ports as exected). All systems have pkg-1.3.8_2 installed. The main difference between these boxes is, that the boxes without problems come from older installations, which were converted via pkg2ng. Only the box in question has all ports built and installed from scratch after installing pkg, without any installations via pkg_* before. As far as I can say, all went well until r369572. After svn'ing to a more recent revision, I was not able to build ports any more ... HTH, Rainer Hurling ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Looping during boot-up process in FreeBSD-11 current
On 9/29/2014 at 11:04 PM José Pérez Arauzo wrote: |This encoded message has been converted to an attachment. | |Hi Mike, | |On Mon, 29 Sep 2014 16:03:44 -0400, Mike. wrote [...] |So that should put a time bracket on the issue, |roughly the first half of 2014. | |can you boot 271146? Just buildkernel and installkernel. Thank |you. = There doesn't seem to be much, if any, interest on the part of the FreeBSD developers in fixing this recently-introduced issue with booting up FreeBSD. Since I experience the problem only on the one notebook of mine, I'll just re-purpose that notebook for OpenBSD and try to find another old notebook that works with FreeBSD. Seems like the path of least resistance for me ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] nscd
Hi,
I've been seeing the same issues with nscd not caching, but unfortunately your
patch doesn't seem to change things, for better or worse.
My nsswitch.conf looks as follows:
group: cache files nis
hosts: cache files dns
networks: cache files
passwd: cache files nis
shells: files
services: cache files nis
protocols: cache files
rpc: cache files
When I start "nscd -n -s -t" and then run top in another shell, top takes ~10
seconds to start up every time; if nscd did its thing, repeat invocations
should be much faster. nscd doesn't seem to see any activity either, based on
its log:
[elars@one: ~] sudo nscd -n -s -t
M1 from main: request agents registered successfully
M2 from cache: cache was successfully initialized
M2 from runtime environment: using socket /var/run/nscd
M2 from runtime environment: successfully initialized
M1 from main: working in single-threaded mode
Lars
On 2014-9-30, at 5:40, David Shane Holden wrote:
> So, I've noticed nscd hasn't worked right for awhile now. Since I
> upgraded to 10.0 it never seemed to cache properly but I never bothered
> to really dig into it until recently and here's what I've found. In my
> environment I have nsswitch set to use caching and LDAP as such:
>
> group: files cache ldap
> passwd: files cache ldap
>
> The LDAP part works fine, but caching didn't on 10.0 for some reason.
> On my 9.2 machines it works as expected though. What I've found is in
> usr.sbin/nscd/query.c
>
> struct query_state *
> init_query_state(int sockfd, size_t kevent_watermark, uid_t euid, gid_t
> egid)
> {
> ...
> memcpy(&retval->timeout, &s_configuration->query_timeout,
> sizeof(struct timeval));
> ...
> }
>
> s_configuration->query_timeout is an 'int' which is being memcpy'd into
> a 'struct timeval' causing it to grab other parts of the s_configuration
> struct along with the query_timeout value and polluting retval->timeout.
> In this case it appears to be grabbing s_configuration->threads_num and
> shoving that into timeout.tv_sec along with the query_timeout. This ends
> up confusing nscd later on (instead of being 8 it ends up being set to
> 34359738376) and breaks it's ability to cache. I've attached a patch to
> set the retval->timeout properly and gets nscd working again. I'm
> guessing gcc was handling this differently from clang which is why it
> wasn't a problem before 10.0.
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
On 2014-09-28 07:00, O. Hartmann wrote: > Am Sun, 28 Sep 2014 12:05:36 +0200 > Jan Kokemüller schrieb: > >> > And as far as I know: even the Linuxulator is ways behind the recent > development and > still 32Bit (ancient, so to speak). I do not want myself having lots of > outdated hard- > and software running and developing on outdated platforms. > There is a working 64bit linuxulator in dchagin's project branch. Hopefully it will be merged into head soon, and we'll have full 64bit linux emulation for FreeBSD 11. -- Allan Jude ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
