Re: I need reply in Embedded FreeBSD Kernel Theme
hi sorry for being late in reply but I had some problems in the last week. I hope u still remeber what I was talking about :) @chargen Thanx for ur reply. Embedded computer systems permeate all aspects of our daily lives. Alarm clocks, coffee makers, digital watches, cell phones, and automobiles are just a few of the devices that make use of embedded systems. The design and development of such systems is unique, because the design constraints are different for each system. I supposed a new design for reducing the size of the kernel to be able to work in such an environment which has some constraints make it does not have the ability to get large memory, large storage devices or others. / as far as your document goes: "We will unload all the drivers that indicated with zeros in the module metadata file. That would make the OS to be a few of Megabytes." unload? what is the logic here? I'm sorry but what is the real gain here, // The configuration file is dependent on the kernel (which is included as a compiled kernel). If I unload these unneeded drivers, I decrease the size of the compiled kernel So it will have the ability to work in more constrained environment and that is suitable to work for Operating Systems for small chips for embedded systems. As the Internet grew, the requirements of embedded systems also began to grow in complexity. In addition to solving classic embedded systems problems, system designers were required to add connectivity for sending and receiving data or providing an automated method for software upgrades. Rather than increase the development effort, system designers have moved toward using third-party hardware and evaluating open source software. Thanx Chargen @ andrew Thanx for your reply. I appreciate your effort to download the document. Regarding the uploading of the document to that site, I am sorry for that but I tried to attach it with the email but it was refused because its size was too large. I did not send it in the text part because the text format and tables will be lost. I am sorry for that. / After a couple of quick readings, I'm not sure I correctly understand what you plan to achieve. It sounds like you are trying to achive something like hardware specific dynamic module loading (like in Solaris, for example), but then it also sounds like you are trying to build a kernel based on a generated config which somehow involves building a tiny binary hardware profile built from POST data. Are you compiling a kernel at some point rather than just generating a loader.conf for modules in order to minimise the running size? This approach will combine the two both. It will build a kernel based on a generated config which somehow involves building a tiny binary hardware profile built from POST data. It also will use hardware specific dynamic module loading because I don't have to load all the drivers for devices connected to the machine. I will use this dynamic module loading at the start-up only not at the run time because some considerations of the embedded systems for chips not being to load modules and change how to work at run time. that would make power problems. I was most confused by We will unload all the drivers that indicated with zeros in the > module metadata file. That would make the OS to be a > few of Megabytes. > Whether you are compiling a kernel for the (chosen) hardware based on a generated kernel or loader config, I don't see a sensible case in which you would ever need to "unload" any driver. /// yeah I know it is not sensible but I wrote it as a result of what I supposed before so it has no meaning. just a result to clarify what I reduced here. Thanx for ur sympathy and I will be glad to send you my next file to get ur comments about. As much fun as it is spending hours manually tweaking and testing a kernel config for each system and deciding what modules to use, I like the idea of a one time guided process based on accurately identified hardware to build an optimal kernel, so I hope that's what you're proposing. // Actually, I am deciding many time guided process based on accurately identified hardware to build an optimal kernel because I think this is more dynamic for considerations of changing the purpose of the embedded system. I mean sometimes u may need to perform deterministic operation in this boot so u do not have to load all drivers which there will be a lot of unneeded drivers of them at this boot process. I will determine the dependencies to provide optimal kernel. Thanx Andrew @ Matt Thanx for ur reply Matt. /
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)
On Wed, Jun 23, 2010 at 08:45:31AM -0700, Ted Faber wrote: > On Wed, Jun 23, 2010 at 11:03:45AM -0400, Ryan Stone wrote: > > I have to admit that I'm more than a little surprised that this > > problem does not affect modules that in src, but maybe that's because > > I don't know all that much about FreeBSD's build infrastructure. Are > > the src modules being linked with a linker script that is not being > > used for out-of-src modules? Are the people affected by this not > > using the base compiler to build ports?(I see that this affects PC-BSD > > as well, and I'd be a little surprised to learn that it wasn't using > > the base compiler). > > I had the problem on i386, base compiler. It also affects the sample > module in /usr/share/examples/kld/cdev/ which also uses the base > compiler, if you want a case w/o the ports infrastructure. Just so it gets into Google: Andriy Gapon went a few rounds of debugging with me and it turns out that the problem was that the binutils port had installed a loader in /usr/local/bin/ld that was incompatible with the module system. (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr commands from cupsd, though it's evidently a bit of a dangerous idea.) Basically if the linker you're using to compile isn't /usr/bin/ld you may have problems building kernel modules. The easiest way to detect this is to get the -v output (version number) from the linker in use and compare it against /usr/bin/ld . I was able to do that by adding LDFLAGS += -v to the Makefile in question. Thanks Andriy! -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpXJGFp1X6q8.pgp Description: PGP signature
Re: zfs panic
On Wed, Jun 23, 2010 at 01:47:33PM -0700, Xin LI wrote: > > > > panic: _sx_xlock_hard: recursed on non-recursive sx > > buf_hash_table.ht_locks[i].ht_lock @ > > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/c > > ommon/fs/zfs/arc.c:1626 > > Any chance to obtain a backtrace for the panic? >From r209229: db:0:kdb.enter.default> bt Tracing pid 3233 tid 100396 td 0xff013600f000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x1c8 _sx_xlock_hard() at _sx_xlock_hard+0x93 _sx_xlock() at _sx_xlock+0xaa arc_buf_remove_ref() at arc_buf_remove_ref+0x7b dbuf_rele() at dbuf_rele+0x15d zfs_freebsd_reclaim() at zfs_freebsd_reclaim+0xe1 VOP_RECLAIM_APV() at VOP_RECLAIM_APV+0xe8 vgonel() at vgonel+0x186 vnlru_free() at vnlru_free+0x2f4 vfs_lowmem() at vfs_lowmem+0x31 kmem_malloc() at kmem_malloc+0x12c page_alloc() at page_alloc+0x18 keg_alloc_slab() at keg_alloc_slab+0xe6 keg_fetch_slab() at keg_fetch_slab+0x18e zone_fetch_slab() at zone_fetch_slab+0x4f uma_zalloc_arg() at uma_zalloc_arg+0x56b arc_get_data_buf() at arc_get_data_buf+0xaa arc_read_nolock() at arc_read_nolock+0x1cb arc_read() at arc_read+0x71 dbuf_read() at dbuf_read+0x4ea dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x119 dmu_buf_hold_array() at dmu_buf_hold_array+0x57 dmu_read_uio() at dmu_read_uio+0x3f zfs_freebsd_read() at zfs_freebsd_read+0x558 VOP_READ_APV() at VOP_READ_APV+0xe2 vn_read() at vn_read+0x1d0 dofileread() at dofileread+0x97 kern_preadv() at kern_preadv+0x6a pread() at pread+0x52 syscallenter() at syscallenter+0x217 syscall() at syscall+0x39 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (475, FreeBSD ELF64, pread), rip = 0x80100c14c, rsp = 0x7fbfeb48, rbp = 0x2 --- Thanks. ___ 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: No issues, just informative QEMU boot
On Wed, 2010-06-23 at 15:00 -0500, Alexander Motin wrote: > hint.atrtc.0.clock=0 > hint.attimer.0.clock=0 > hint.hpet.0.legacy_route=1 after adding those to the VM: Copyright (c) 1992-2010 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 9.0-CURRENT #2 r209470: Wed Jun 23 11:15:21 PDT 2010 sbr...@test:/mnt/nfs/fbsd/head/sys/amd64/compile/SEAN amd64 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0x80b72000. Calibrating TSC clock ... TSC clock: 2527057361 Hz CPU: QEMU Virtual CPU version 0.11.0 (2527.06-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x623 Family = 6 Model = 2 Stepping = 3 Features=0x783fbfd Features2=0x8001> AMD Features=0x20100800 real memory = 2147483648 (2048 MB) Physical memory chunk(s): 0x1000 - 0x0009afff, 630784 bytes (154 pages) 0x00ba - 0x7c38, 2071920640 bytes (505840 pages) avail memory = 2059055104 (1963 MB) Event timer "LAPIC" frequency 0 Hz quality 500 ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 x86bios: IVT 0x00-0x0004ff at 0xff00 x86bios: SSEG 0x01-0x01 at 0xff80d000 x86bios: EBDA 0x09f000-0x09 at 0xff09f000 x86bios: ROM 0x0a-0x0e at 0xff0a ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xfbd40 00014 (v0 QEMU ) ACPI: RSDT 0x7fff 00034 (v1 QEMU QEMURSDT 0001 QEMU 0001) ACPI: FACP 0x7fff01b4 00074 (v1 QEMU QEMUFACP 0001 QEMU 0001) ACPI: DSDT 0x7fff0280 01DD4 (v1 BXPC BXDSDT 0001 INTL 20090123) ACPI: FACS 0x7fff0240 00040 ACPI: SSDT 0x7fff2054 009E3 (v1 BXPC BXSSDT 0001 INTL 20090123) ACPI: APIC 0x7fff2a38 000EA (v1 QEMU QEMUAPIC 0001 QEMU 0001) ACPI: HPET 0x7fff2b90 00038 (v1 QEMU QEMUHPET 0001 QEMU 0001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 5, irq 5 ioapic0: intpin 5 trigger: level MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level MADT: Interrupt override: source 10, irq 10 ioapic0: intpin 10 trigger: level MADT: Interrupt override: source 11, irq 11 ioapic0: intpin 11 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00050014 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400 cmci: 0x random: io: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: null: acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.PX13.P13C -> bus 0 dev 1 func 3 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.ISA_.P40C -> bus 0 dev 1 func 0 ACPI timer: 0/211 0/1431 0/166 0/168 0/38700 0/22874 0/2046 0/22171 0/204 0/579 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 pci_link0:Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 10 11 Validation 0 10 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 pci_link1:Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 10 11 Validation 0 10 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 pci_link2:Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 10 11 Validation 0 11 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 pci_link3:Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 10 11 Validation 0 11 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 hpet0: iomem 0xfed0-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 1Hz 64bit, 3 timers, legacy route hpet0: t0: irqs 0x0004 (0), 64bit, periodic hpet0: t1: irqs 0x0004 (0), 64bit, periodic hpet0: t2: irqs 0x0004 (0), 64bit, periodic Timecounter "HPET" frequency 1 Hz quality 900 ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 49 hpet0: [MPSAFE] hpet0: [FILTER] ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 50 hpet0: [MPSAFE] hpet0: [FILTER] Even
Re: zfs panic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Ben, On 2010/06/23 09:44, ben wilber wrote: > Hi, > > Since at least r208174, I've been getting the following panic every few days > on > my fairly heavily loaded amd64 machine: > > panic: _sx_xlock_hard: recursed on non-recursive sx > buf_hash_table.ht_locks[i].ht_lock @ > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/c > ommon/fs/zfs/arc.c:1626 > > The machine has 36 disks behind mfi(4), plus some SATA L2ARC. This > panic is sometimes preempted by "kmem_map too small", so I apologize in > advance if this is caused by memory shortage. Any chance to obtain a backtrace for the panic? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMInLlAAoJEATO+BI/yjfB2GMH+wUzic+knneIShCqZJltR9Xe WyvEvMAkzEqg+4quLbDT8n5fge/wLY6NKODDwHCNOwku3HQqwon+lQpA9YqiWplm MH+x+Nxa8evE/Fc84Xl8ajgjzWVqAfGWl6mhruBCjeVf/oY3ZujiX9mCPNKMzDU/ 86To+UkeiQfVHDcwh8xDp+vIb+QvYEyKY1cmqi4Uu1nojAGBgCPs3ISUG0/834/J H0pv+CeAi3zlDzeOSUBtpf2RutJ/oH1MuyHoB1LORk1FPVe3WvbGx+lpQonoedta UVZqYeAqpliTbqQOXfrl7+6g0bqnCobyri8YNtyLS2h6NsA05lclYEbTJyR9QgI= =JTmj -END PGP SIGNATURE- ___ 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: No issues, just informative QEMU boot
Sean Bruno wrote: > With the large amount of churn in key parts of FreeBSD ongoing, I > thought I'd post a dmesg from a booting FreeBSD Current instance I use > all the time. This is under KVM/QEMU on Fedora 12. > > there's some interesting things relating to timers and such. Thanks. I've noticed one thing there: QEMU seems don't enumerate i8254 timer device over ACPI. I was wondering if such systems exist, and now I see one. Luckily there is enough other timers to work fine without it. You may also try to check two HPET timers working in even more fresh "legacy route" mode by adding to /boot/loader.conf: hint.atrtc.0.clock=0 hint.attimer.0.clock=0 hint.hpet.0.legacy_route=1 -- Alexander Motin ___ 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: Deadlock with kgmon -p
I can't help you with the problems with gprof, but Fabien Thomas has been working on support for software-triggered pmc events. He posted a patch here: http://groups.google.com/group/pmctools-discuss/browse_thread/thread/1eb4fa78c7ab8522 You could try this out to use pmcstat to profile your application using the soft-clock event. ___ 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: Deadlock with kgmon -p
Yes. Using it as we speak. "config -p" *seems* to be ok at the moment on 7 and -Current Sean ___ 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: Deadlock with kgmon -p
On Wed, 2010-06-23 at 13:00 -0500, Matthew Jacob wrote: > On 6/23/2010 10:53 AM, Sean Bruno wrote: > > Trying to track down a nasty with regard to Xen stuff and am now > > experiencing deadlocks on -current with a kernel configured with -g > > -ppp. > > > > The lockup will happen when I attempt to get the profiling data via > > kgmon -p. > > > > Not sure when this broke, but it's definitely broken in stable-7 as well > > as -current. Ideas? > > > > > > Dunno about anyone else's experience, but I can't get amd64 stable-7 > kernels on forward to even finish booting if built with config -pp. "config -p" *seems* to be ok at the moment on 7 and -Current Sean ___ 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: Deadlock with kgmon -p
On 6/23/2010 10:53 AM, Sean Bruno wrote: Trying to track down a nasty with regard to Xen stuff and am now experiencing deadlocks on -current with a kernel configured with -g -ppp. The lockup will happen when I attempt to get the profiling data via kgmon -p. Not sure when this broke, but it's definitely broken in stable-7 as well as -current. Ideas? Dunno about anyone else's experience, but I can't get amd64 stable-7 kernels on forward to even finish booting if built with config -pp. ___ 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"
Deadlock with kgmon -p
Trying to track down a nasty with regard to Xen stuff and am now experiencing deadlocks on -current with a kernel configured with -g -ppp. The lockup will happen when I attempt to get the profiling data via kgmon -p. Not sure when this broke, but it's definitely broken in stable-7 as well as -current. Ideas? Sean ___ 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"
No issues, just informative QEMU boot
With the large amount of churn in key parts of FreeBSD ongoing, I thought I'd post a dmesg from a booting FreeBSD Current instance I use all the time. This is under KVM/QEMU on Fedora 12. there's some interesting things relating to timers and such. booted with boot.config set to -v Sean Copyright (c) 1992-2010 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 9.0-CURRENT #0 r209470: Wed Jun 23 09:21:57 PDT 2010 sbr...@test:/mnt/nfs/fbsd/head/sys/amd64/compile/SEAN amd64 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0x80b61000. Calibrating TSC clock ... TSC clock: 2527049714 Hz CPU: QEMU Virtual CPU version 0.11.0 (2527.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x623 Family = 6 Model = 2 Stepping = 3 Features=0x783fbfd Features2=0x8001> AMD Features=0x20100800 real memory = 2147483648 (2048 MB) Physical memory chunk(s): 0x1000 - 0x0009afff, 630784 bytes (154 pages) 0x00b8f000 - 0x7c38, 2071990272 bytes (505857 pages) avail memory = 2059124736 (1963 MB) Event timer "LAPIC" frequency 0 Hz quality 500 ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 x86bios: IVT 0x00-0x0004ff at 0xff00 x86bios: SSEG 0x01-0x01 at 0xff80d000 x86bios: EBDA 0x09f000-0x09 at 0xff09f000 x86bios: ROM 0x0a-0x0e at 0xff0a ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xfbd40 00014 (v0 QEMU ) ACPI: RSDT 0x7fff 00034 (v1 QEMU QEMURSDT 0001 QEMU 0001) ACPI: FACP 0x7fff01b4 00074 (v1 QEMU QEMUFACP 0001 QEMU 0001) ACPI: DSDT 0x7fff0280 01DD4 (v1 BXPC BXDSDT 0001 INTL 20090123) ACPI: FACS 0x7fff0240 00040 ACPI: SSDT 0x7fff2054 009E3 (v1 BXPC BXSSDT 0001 INTL 20090123) ACPI: APIC 0x7fff2a38 000EA (v1 QEMU QEMUAPIC 0001 QEMU 0001) ACPI: HPET 0x7fff2b90 00038 (v1 QEMU QEMUHPET 0001 QEMU 0001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 5, irq 5 ioapic0: intpin 5 trigger: level MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level MADT: Interrupt override: source 10, irq 10 ioapic0: intpin 10 trigger: level MADT: Interrupt override: source 11, irq 11 ioapic0: intpin 11 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00050014 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400 cmci: 0x random: io: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: null: acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.PX13.P13C -> bus 0 dev 1 func 3 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.ISA_.P40C -> bus 0 dev 1 func 0 ACPI timer: 0/190 0/188 0/2068 0/2143 0/760 0/2019 0/141 0/139 0/1745 0/135 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 pci_link0:Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 10 11 Validation 0 10 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 pci_link1:Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 10 11 Validation 0 10 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 pci_link2:Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 10 11 Validation 0 11 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 pci_link3:Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 10 11 Validation 0 11 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 hpet0: iomem 0xfed0-0xfed003ff on acpi0 hpet0: vendor 0x8086, rev 0x1, 1Hz 64bit, 3 timers, legacy route hpet0: t0: irqs 0x0004 (0), 64bit, periodic hpet0: t1: irqs 0x0004 (0), 64bit, periodic hpet0: t2: irqs 0x0004 (0), 64bit, periodic Timecounter "HPET" frequency 1 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0
zfs panic
Hi, Since at least r208174, I've been getting the following panic every few days on my fairly heavily loaded amd64 machine: panic: _sx_xlock_hard: recursed on non-recursive sx buf_hash_table.ht_locks[i].ht_lock @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/c ommon/fs/zfs/arc.c:1626 The machine has 36 disks behind mfi(4), plus some SATA L2ARC. This panic is sometimes preempted by "kmem_map too small", so I apologize in advance if this is caused by memory shortage. ___ 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: Problem with buildworld with CLANG
On Wed, Jun 23, 2010 at 3:15 PM, Tom Evans wrote: > Top of the '[TESTING] Clang..' email: > >> hi, >> >> ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to >> import >> into HEAD in roughly a week. We would like the initial import to be as >> painless >> as possible and therefore we ask you to test ClangBSD to assure that the >> revision >> we are importing does not have some really embarassing bugs. >> >> How to do it (on i386 and amd64): >> 1) svn co http://svn.freebsd.org/base/projects/clangbsd src i already did it and it worked, two weeks ago. now i wanted to try with clan in system >> 2) echo NO_WERROR= >> /etc/src.conf ; echo WERROR= >> /etc/src.conf > So uncomment your src.conf lines that are incompatible. forgot to tell before. i tried with and without those lines. -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.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: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On Wed, Jun 23, 2010 at 11:03:45AM -0400, Ryan Stone wrote: > I have to admit that I'm more than a little surprised that this > problem does not affect modules that in src, but maybe that's because > I don't know all that much about FreeBSD's build infrastructure. Are > the src modules being linked with a linker script that is not being > used for out-of-src modules? Are the people affected by this not > using the base compiler to build ports?(I see that this affects PC-BSD > as well, and I'd be a little surprised to learn that it wasn't using > the base compiler). I had the problem on i386, base compiler. It also affects the sample module in /usr/share/examples/kld/cdev/ which also uses the base compiler, if you want a case w/o th eports infrastructure. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpk7CXCsISMP.pgp Description: PGP signature
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
on 23/06/2010 18:03 Ryan Stone said the following: > On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon wrote: >> Which also brings the question - what arch(s) is affected? >> I tested on amd64. > > This should explain it. It looks to me like i386 uses kern/link_elf.c > as its linker, while amd64 uses kern/link_elf_obj.c. link_elf.c can > only find the sections containing the sysinits(and some related > things) via the magic symbols. link_elf_obj.c seems to understand ELF > objects much better and doesn't need those symbols to be present. It > just looks up the section that contains the sysinits directly via the > ELF metadata that is already present. Yes, you are absolutely correct. This comes from the fact that amd64 uses simple objects files (aka .o) as kernel modules and i386 uses full-blow dso. > As far as I can tell, amd64 is the only arch in the tree that uses > link_elf_obj.c, so all other arches may be affected. > > I have to admit that I'm more than a little surprised that this > problem does not affect modules that in src, but maybe that's because > I don't know all that much about FreeBSD's build infrastructure. Are > the src modules being linked with a linker script that is not being > used for out-of-src modules? No, we don't have any special linker script for modules. > Are the people affected by this not > using the base compiler to build ports?(I see that this affects PC-BSD > as well, and I'd be a little surprised to learn that it wasn't using > the base compiler). I think that even out-of-base modules still use the same module build infrastructure (bsd.kmod.mk). At least this is the case for cuse4bsd. > The link line that I gave was a hack. The proper solution is to use a > linker script that unconditionally puts the magic symbols in. Module link process on i386 is like this (simplified): 1) combine object files into a single object file mod.kld ld -r -o mod.kld 1.o 2.o 2) convert it to dso ld -Bshareable -d -warn-common -o mod.ko mod.kld I believe that __start/__stop symbols for sections should be automatically added at step 2 by linker. Reference: http://sourceware.org/binutils/docs/ld/Orphan-Sections.html#Orphan-Sections -- Andriy Gapon ___ 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: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On 06/23/2010 10:55, Hans Petter Selasky wrote: Hi, Not unless there is a bug in my module. I'm a little bit busy right now, though I think that other modules like "fuse.ko" might be affected aswell. Could you try to make a cuse4bsd build on a stock 8-stable and compare the resulting cuse4bsd.ko (i386 build) like described earlier in this thread. Or something like this: objdump -D -x cuse4bsd.ko> a.txt objdump -D -x cuse4bsd.ko> b.txt diff -u a.txt b.txt I'll have to try that on another system, all amd64 here, and rebuilding the port gives identical cuse4bsd.ko to what we already include in system. What compiler did you bundle with the PCBSD 8.1 RC1 and how did you build the cuse4bsd ports module? Did you use something like clang? The system is just regular FreeBSD 8.1-RC1, no clang or other funky make options. The port was built with in a chroot environment with the stock FreeBSD 8.1-RC1 loaded in it. I haven't checked too much yet, but it appears that like Andriy is reporting that it's not a problem for everyone. When booting PCBSD 8.1 RC1 you will see warnings from the webcamd rc.d. --HPS Yea, i see the error messages here as well, but only on my laptop. My desktops use the same build, but don't throw the error, even though cuse4bsd is loaded. (Of course they don't have a webcam connected, which I'm sure is part of it) -- Kris Moore PC-BSD Software iXsystems ___ 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: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On Wed, Jun 23, 2010 at 3:10 AM, Andriy Gapon wrote: > > Which also brings the question - what arch(s) is affected? > I tested on amd64. This should explain it. It looks to me like i386 uses kern/link_elf.c as its linker, while amd64 uses kern/link_elf_obj.c. link_elf.c can only find the sections containing the sysinits(and some related things) via the magic symbols. link_elf_obj.c seems to understand ELF objects much better and doesn't need those symbols to be present. It just looks up the section that contains the sysinits directly via the ELF metadata that is already present. As far as I can tell, amd64 is the only arch in the tree that uses link_elf_obj.c, so all other arches may be affected. I have to admit that I'm more than a little surprised that this problem does not affect modules that in src, but maybe that's because I don't know all that much about FreeBSD's build infrastructure. Are the src modules being linked with a linker script that is not being used for out-of-src modules? Are the people affected by this not using the base compiler to build ports?(I see that this affects PC-BSD as well, and I'd be a little surprised to learn that it wasn't using the base compiler). The link line that I gave was a hack. The proper solution is to use a linker script that unconditionally puts the magic symbols in. ___ 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: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On Wed, Jun 23, 2010 at 10:10:59AM +0300, Andriy Gapon wrote: > on 23/06/2010 10:02 Andriy Gapon said the following: > > I don't dispute that it is found broken in particular environments, I just > > think > > that the analysis could be incorrect. > > Which also brings the question - what arch(s) is affected? > I tested on amd64. Right. I'm i386 and I have the problem. Good point! -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG pgpVLIqZ5Js9n.pgp Description: PGP signature
Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On Wednesday 23 June 2010 16:43:31 Kris Moore wrote:
> On 06/23/2010 02:52, Hans Petter Selasky wrote:
> > On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote:
> >> on 23/06/2010 03:38 Hans Petter Selasky said the following:
> >>> Hi,
> >>>
> >>> I'm creating a new thread on this issue.
> >>>
> >>> On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote:
> I saw similar behaviour a couple of years ago when I switched from
> using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules.
> The problem ended up being a change in the linker script used by GNU
> ld for linking kernel modules. It used to always put some magic
> symbols used by the linker to implement things like sysinits into the
> module. It was changed to only provide those symbols, which
> apparently means that the linker would discard those symbols if
> nothing referenced them(and nothing did reference them). I had to
> work around it by adding the following to my link line:
>
> -u __start_set_sysinit_set -u __start_set_sysuninit_set \
> -u __start_set_sysctl_set -u __start_set_modmetadata_set \
> -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \
> -u __stop_set_sysctl_set -u __stop_set_modmetadata_set
> >>>
> >>> It appears many kmods are broken because the linker is stripping away
> >>> static data declared with the section attribute in FreeBSD 8.1-RC1.
> >>>
> >>>
> >>>
> >>> I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd
> >>> port made the module and the result loads and creates the /dev/cuse
> >>> file.
> >>>
> >>> Here's a diff relative to
> >>> /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so
> >>> it's clear what I did.
> >>>
> >>>
> >>> --- Makefile.kmod.orig 2010-02-11 03:28:02.0 -0800
> >>> +++ Makefile.kmod 2010-06-22 14:02:52.0 -0700
> >>> @@ -30,4 +30,10 @@
> >>> KMOD= cuse4bsd
> >>> SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h
> >>>
> >>> +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \
> >>> + -u __start_set_sysctl_set -u __start_set_modmetadata_set \
> >>> + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \
> >>> + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set
> >>> +
> >>> +
> >>> .include
> >>>
> >>> Running nm -o on the two modules, the difference seems to be that the
> >>> -u results in some additional absolute symbols being defined:
> >>>
> >>> Bad module:
> >>> $ nm -o /boot/modules/cuse4bsd.ko| grep sys
> >>> /boot/modules/cuse4bsd.ko:275c r
> >>> __set_sysinit_set_sym_cuse_kern_init_sys_init
> >>> /boot/modules/cuse4bsd.ko:2758 r
> >>> __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit
> >>> /boot/modules/cuse4bsd.ko:3194 d cuse_kern_init_sys_init
> >>> /boot/modules/cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit
> >>
> >> I am not sure if this analysis is correct.
> >> I tested on head and stable/8 and my nm output is exactly like above
> >> ("bad module"), still the module loads fine and creates /dev/cuse.
> >>
> >> I don't think there were any recent changes related to build
> >> infrastructure or linker in 8.1.
> >>
> >> Please consider other possibilities.
> >
> > I installed PC-BSD 8.1-RC1 and the stock cuse4bsd module is broken.
> > Andriy, make sure that you re-make the toolchain before building the
> > module in question. Also I think you have to:
> >
> > cd /usr/src ; make buildenv TARGET_ARCH=xxx_target
> >
> > Then you cd to the module directory and type make.
> >
> > --HPS
>
> Are you going to be updating the port soon to fix the build? We're just
> doing a regular "make install" on the cuse4bsd-kmod port for our RC1
> build, and it would be nice to have this fixed for 8.1-Release.
>
Hi,
Not unless there is a bug in my module. I'm a little bit busy right now,
though I think that other modules like "fuse.ko" might be affected aswell.
Could you try to make a cuse4bsd build on a stock 8-stable and compare the
resulting cuse4bsd.ko (i386 build) like described earlier in this thread.
Or something like this:
objdump -D -x cuse4bsd.ko > a.txt
objdump -D -x cuse4bsd.ko > b.txt
diff -u a.txt b.txt
What compiler did you bundle with the PCBSD 8.1 RC1 and how did you build the
cuse4bsd ports module? Did you use something like clang?
I haven't checked too much yet, but it appears that like Andriy is reporting
that it's not a problem for everyone. When booting PCBSD 8.1 RC1 you will see
warnings from the webcamd rc.d.
--HPS
___
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: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On 06/23/2010 02:52, Hans Petter Selasky wrote:
On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote:
on 23/06/2010 03:38 Hans Petter Selasky said the following:
Hi,
I'm creating a new thread on this issue.
On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote:
I saw similar behaviour a couple of years ago when I switched from
using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules.
The problem ended up being a change in the linker script used by GNU
ld for linking kernel modules. It used to always put some magic
symbols used by the linker to implement things like sysinits into the
module. It was changed to only provide those symbols, which
apparently means that the linker would discard those symbols if
nothing referenced them(and nothing did reference them). I had to
work around it by adding the following to my link line:
-u __start_set_sysinit_set -u __start_set_sysuninit_set \
-u __start_set_sysctl_set -u __start_set_modmetadata_set \
-u __stop_set_sysinit_set -u __stop_set_sysuninit_set \
-u __stop_set_sysctl_set -u __stop_set_modmetadata_set
It appears many kmods are broken because the linker is stripping away
static data declared with the section attribute in FreeBSD 8.1-RC1.
I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port
made the module and the result loads and creates the /dev/cuse file.
Here's a diff relative to
/usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so
it's clear what I did.
--- Makefile.kmod.orig 2010-02-11 03:28:02.0 -0800
+++ Makefile.kmod 2010-06-22 14:02:52.0 -0700
@@ -30,4 +30,10 @@
KMOD= cuse4bsd
SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h
+LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \
+ -u __start_set_sysctl_set -u __start_set_modmetadata_set \
+ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \
+ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set
+
+
.include
Running nm -o on the two modules, the difference seems to be that the -u
results in some additional absolute symbols being defined:
Bad module:
$ nm -o /boot/modules/cuse4bsd.ko| grep sys
/boot/modules/cuse4bsd.ko:275c r
__set_sysinit_set_sym_cuse_kern_init_sys_init
/boot/modules/cuse4bsd.ko:2758 r
__set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit
/boot/modules/cuse4bsd.ko:3194 d cuse_kern_init_sys_init
/boot/modules/cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit
I am not sure if this analysis is correct.
I tested on head and stable/8 and my nm output is exactly like above ("bad
module"), still the module loads fine and creates /dev/cuse.
I don't think there were any recent changes related to build infrastructure
or linker in 8.1.
Please consider other possibilities.
I installed PC-BSD 8.1-RC1 and the stock cuse4bsd module is broken. Andriy,
make sure that you re-make the toolchain before building the module in
question. Also I think you have to:
cd /usr/src ; make buildenv TARGET_ARCH=xxx_target
Then you cd to the module directory and type make.
--HPS
Are you going to be updating the port soon to fix the build? We're just
doing a regular "make install" on the cuse4bsd-kmod port for our RC1
build, and it would be nice to have this fixed for 8.1-Release.
--
Kris Moore
PC-BSD Software
iXsystems
___
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: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
Anton Shterenlikht writes: > I think it's possible that at some point, in anger, I did "make > installworld" after a failed, or otherwise interrupted "make > buildworld". Perhaps I got an inconsistent set of binaries as a > result... Would that explain an error like this? No, because at this point buildworld is using the toolchain and libraries that it built earlier. Can you do % find /usr/obj/usr/src -name liblzma.a There should be at least one in /usr/obj/usr/src/lib/liblzma and one in /usr/obj/usr/src/tmp/usr/lib, and they should be identical. Next, do % nm /usr/obj/usr/src/lib/liblzma/liblzma.a | grep physmem and show us the result. While you're at it, do this as well: % nm /usr/lib/liblzma.a | grep physmem DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Problem with buildworld with CLANG
On Wed, Jun 23, 2010 at 1:38 PM, Cristiano Deana wrote: > # uname -a > FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #3: Tue Jun 22 16:04:38 > CEST 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 > > # cat /etc/src.conf > #NO_WERROR= > #WERROR= > CC= clang > CXX= clang++ > > sources from this morning, i got this error: > > clang -O2 -pipe -I/usr/src/lib/libc/include > -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -DNLS > -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa > -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv > -D_ACL_PRIVATE -DPOSIX_MISTAKE > -I/usr/src/lib/libc/../../contrib/tzcode/stdtime > -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES > -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING > -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall > -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c > /usr/src/lib/libc/sys/stack_protector.c > /usr/src/lib/libc/sys/stack_protector.c:88:19: error: format string is > not a string literal (potentially insecure) [-Wformat-security] > syslog(LOG_CRIT, msg); > ^~~ > 1 error generated. > *** Error code 1 > Top of the '[TESTING] Clang..' email: > hi, > > ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to > import > into HEAD in roughly a week. We would like the initial import to be as > painless > as possible and therefore we ask you to test ClangBSD to assure that the > revision > we are importing does not have some really embarassing bugs. > > How to do it (on i386 and amd64): > > 0) install fresh devel/llvm-devel port > > 1) svn co http://svn.freebsd.org/base/projects/clangbsd src > > 2) echo NO_WERROR= >> /etc/src.conf ; echo WERROR= >> /etc/src.conf > > 3) cd src && make buildworld So uncomment your src.conf lines that are incompatible. Cheers Tom ___ 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: Problem with buildworld with CLANG
2010/6/23 Cristiano Deana : > # uname -a > FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #3: Tue Jun 22 16:04:38 > CEST 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 > > # cat /etc/src.conf > #NO_WERROR= > #WERROR= > CC= clang > CXX= clang++ > > sources from this morning, i got this error: > [.. error ..] If you are using HEAD sources, then an error-free build with clang is not guaranteed. There is a separate branch of HEAD, clangbsd, which can be built (almost) completely with clang, see http://wiki.freebsd.org/BuildingFreeBSDWithClang Rene ___ 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"
Problem with buildworld with CLANG
# uname -a FreeBSD test 9.0-CURRENT FreeBSD 9.0-CURRENT #3: Tue Jun 22 16:04:38 CEST 2010 r...@test:/usr/obj/usr/src/sys/GENERIC amd64 # cat /etc/src.conf #NO_WERROR= #WERROR= CC= clang CXX=clang++ sources from this morning, i got this error: clang -O2 -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/sys/stack_protector.c /usr/src/lib/libc/sys/stack_protector.c:88:19: error: format string is not a string literal (potentially insecure) [-Wformat-security] syslog(LOG_CRIT, msg); ^~~ 1 error generated. *** Error code 1 -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.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: r209240 ia64 -> buildworld -> undefined reference to `lzma_physmem'
On Mon, Jun 21, 2010 at 01:27:52PM -0700, Marcel Moolenaar wrote: > > On Jun 21, 2010, at 8:04 AM, Anton Shterenlikht wrote: > > > On Mon, Jun 21, 2010 at 04:45:03PM +0200, Dag-Erling Smørgrav wrote: > >> jhell writes: > >>> Anton Shterenlikht writes: > What do you mean by "updating your headers"? > >>> cd /usr/src/include && make obj && make depend && make all && make install > >> > >> wrong. > >> > >> % cd /usr/src > >> % make obj > >> % make cleandepend > >> % make depend > >> % make buildincludes > >> % make installincludes > >> > >> DES > >> -- > >> Dag-Erling Smørgrav - d...@des.no > > > > Sorry, just to take one step back, why has this become > > necessary for this particular box? If /usr/obj is empty, > > and "svn up", followed by "svn diff", doesn't show any > > local changes, why can't I go straight to make buildworld? > > In other words, why do my headers need updating on this > > particular box, and not on other ia64 boxes? > > I must've screwed something up, haven't I? > > Anton, > > My suggestion would be to destroy the sandbox entirely > and simply checkout a new one from scratch, provided > you're not sharing sandboxes across NFS. I would also > manually destroy your object tree under /usr/obj (or > whereever you have it) before doing the buildworld. > > It's not impossible (double negative to emphasize that > the possibility may not be big enough to worry about, > but that I don't want to go there), that you have some > corruption that is not exposed by "svn diff", but that > is causing the build-breakages. A clean slate helps... Marcel, I did just that - removed the whole of /usr/src and started from scratch. I got the same error as before: cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo exp .lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.l rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdc nfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fs rand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5. o mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_n llfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorde .lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.l atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo mca.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo xz.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_clas .o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lc ypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm xz.lo(.text+0x5202): In function `hardware_init': : undefined reference to `lzma_physmem' I think it's possible that at some point, in anger, I did "make installworld" after a failed, or otherwise interrupted "make buildworld". Perhaps I got an inconsistent set of binaries as a result... Would that explain an error like this? PS: I'm now at # svn info Path: . URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 209429 Node Kind: directory Schedule: normal Last Changed Author: rwatson Last Changed Rev: 209429 Last Changed Date: 2010-06-22 11:46:57 +0100 (Tue, 22 Jun 2010) many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: panic during boot on 8.0-RELEASE
on 23/06/2010 10:28 Nicholas Mills said the following: > I was afraid someone would say that, because it's been very difficult to > reproduce the issue. Happens maybe 1 out of every 8 reboots. I'll give > it a look tomorrow and see what I can find. > > Just to be clear, I should send you the output of the "where" command in > ddb? Yes, that should get things going. -- Andriy Gapon ___ 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: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
On Wednesday 23 June 2010 09:10:59 Andriy Gapon wrote: > on 23/06/2010 10:02 Andriy Gapon said the following: > > I don't dispute that it is found broken in particular environments, I > > just think that the analysis could be incorrect. Ok. > > Which also brings the question - what arch(s) is affected? > I tested on amd64. > I tested on i386. --HPS ___ 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: panic during boot on 8.0-RELEASE
I was afraid someone would say that, because it's been very difficult to reproduce the issue. Happens maybe 1 out of every 8 reboots. I'll give it a look tomorrow and see what I can find. Just to be clear, I should send you the output of the "where" command in ddb? On Wed, Jun 23, 2010 at 3:15 AM, Andriy Gapon wrote: > on 23/06/2010 10:09 Nicholas Mills said the following: > > http://www.parl.clemson.edu/~nlmills/Screenshot.png > > Ah, no stack trace. Unfortunately, this looks undebuggable as it is. > Custom kernel with debug options is needed. > > -- > Andriy Gapon > ___ 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: panic during boot on 8.0-RELEASE
on 23/06/2010 10:09 Nicholas Mills said the following: > http://www.parl.clemson.edu/~nlmills/Screenshot.png Ah, no stack trace. Unfortunately, this looks undebuggable as it is. Custom kernel with debug options is needed. -- Andriy Gapon ___ 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: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
on 23/06/2010 10:02 Andriy Gapon said the following: > I don't dispute that it is found broken in particular environments, I just > think > that the analysis could be incorrect. Which also brings the question - what arch(s) is affected? I tested on amd64. -- Andriy Gapon ___ 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: panic during boot on 8.0-RELEASE
I've since disabled the cdrom drive in Parallels as it was causing all sorts of errors. On Wed, Jun 23, 2010 at 2:15 AM, Andriy Gapon wrote: > on 23/06/2010 02:41 Nicholas Mills said the following: > > Hey all, > > > > Screenshot of panic message is attached. Machine is a VM running under > > Parallels Server Bare Metal 4. The cdrom device was enabled but not > > connected during boot. System was attempting to boot into single user > mode. > > This occurred after a fresh install of 8.0-RELEASE. > > > > Let me know how I can provide more useful info. > > ENOATTACHMENTDETECTED > Please post links, upload possibilities are numerous nowadays. > http://www.parl.clemson.edu/~nlmills/Screenshot.png > > -- > Andriy Gapon > ___ 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: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1
on 23/06/2010 09:52 Hans Petter Selasky said the following:
> On Wednesday 23 June 2010 08:47:52 Andriy Gapon wrote:
>> on 23/06/2010 03:38 Hans Petter Selasky said the following:
>>> Hi,
>>>
>>> I'm creating a new thread on this issue.
>>>
>>> On Tue, Jun 22, 2010 at 04:39:17PM -0400, Ryan Stone wrote:
I saw similar behaviour a couple of years ago when I switched from
using gcc 4.0.2 to gcc 4.3.0 to compile some out-of-tree KLD modules.
The problem ended up being a change in the linker script used by GNU
ld for linking kernel modules. It used to always put some magic
symbols used by the linker to implement things like sysinits into the
module. It was changed to only provide those symbols, which
apparently means that the linker would discard those symbols if
nothing referenced them(and nothing did reference them). I had to
work around it by adding the following to my link line:
-u __start_set_sysinit_set -u __start_set_sysuninit_set \
-u __start_set_sysctl_set -u __start_set_modmetadata_set \
-u __stop_set_sysinit_set -u __stop_set_sysuninit_set \
-u __stop_set_sysctl_set -u __stop_set_modmetadata_set
>>> It appears many kmods are broken because the linker is stripping away
>>> static data declared with the section attribute in FreeBSD 8.1-RC1.
>>>
>>>
>>>
>>> I added those lines to the LDFLAGS in Makefile.kmod in the cuse4bsd port
>>> made the module and the result loads and creates the /dev/cuse file.
>>>
>>> Here's a diff relative to
>>> /usr/ports/multimedia/cuse4bsd-kmod/work/cuse4bsd-kmod-0.1.11 just so
>>> it's clear what I did.
>>>
>>>
>>> --- Makefile.kmod.orig 2010-02-11 03:28:02.0 -0800
>>> +++ Makefile.kmod 2010-06-22 14:02:52.0 -0700
>>> @@ -30,4 +30,10 @@
>>> KMOD= cuse4bsd
>>> SRCS= cuse4bsd_kmod.c device_if.h bus_if.h vnode_if.h
>>>
>>> +LDFLAGS += -u __start_set_sysinit_set -u __start_set_sysuninit_set \
>>> + -u __start_set_sysctl_set -u __start_set_modmetadata_set \
>>> + -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \
>>> + -u __stop_set_sysctl_set -u __stop_set_modmetadata_set
>>> +
>>> +
>>> .include
>>>
>>> Running nm -o on the two modules, the difference seems to be that the -u
>>> results in some additional absolute symbols being defined:
>>>
>>> Bad module:
>>> $ nm -o /boot/modules/cuse4bsd.ko| grep sys
>>> /boot/modules/cuse4bsd.ko:275c r
>>> __set_sysinit_set_sym_cuse_kern_init_sys_init
>>> /boot/modules/cuse4bsd.ko:2758 r
>>> __set_sysuninit_set_sym_cuse_kern_uninit_sys_uninit
>>> /boot/modules/cuse4bsd.ko:3194 d cuse_kern_init_sys_init
>>> /boot/modules/cuse4bsd.ko:3184 d cuse_kern_uninit_sys_uninit
>> I am not sure if this analysis is correct.
>> I tested on head and stable/8 and my nm output is exactly like above ("bad
>> module"), still the module loads fine and creates /dev/cuse.
>>
>> I don't think there were any recent changes related to build infrastructure
>> or linker in 8.1.
>>
>> Please consider other possibilities.
>
> I installed PC-BSD 8.1-RC1 and the stock cuse4bsd module is broken.
I don't dispute that it is found broken in particular environments, I just think
that the analysis could be incorrect.
> Andriy,
> make sure that you re-make the toolchain before building the module in
> question. Also I think you have to:
>
> cd /usr/src ; make buildenv TARGET_ARCH=xxx_target
>
> Then you cd to the module directory and type make.
I don't think that this is needed when _not_ cross-building for a different
architecture.
--
Andriy Gapon
___
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"
