Re: clang and postgresql90
On Mon, Apr 4, 2011 at 12:47 AM, Dimitry Andric d...@freebsd.org wrote: On 2011-04-03 20:15, Christer Solskogen wrote: I'm just wondering if anyone else has trouble compiling postgresql90 with clang. I get this (and I cant seem to find anything online that somebody else had that same problem): ... libpq/auth.o: In function `ClientAuthentication': auth.c:(.text+0x51e): undefined reference to `gss_accept_sec_context' auth.c:(.text+0x5c7): undefined reference to `gss_release_buffer' ... This error is not related to clang, but a problem with postgresql's configure script, in combination with the updated binutils in the base system. You will get the same error if you use gcc. Patch: http://www.andric.com/freebsd/binutils/bu217-databases-postgresql90-server-1.diff Similar one for postgres 8.4: http://www.andric.com/freebsd/binutils/bu217-databases-postgresql84-server-1.diff Okay, thanks :-) -- chs, ___ 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: gpg-agent bus error (signal 10)
On Mon, 4 Apr 2011 09:57:13 +0400 Yuri Pankov yuri.pan...@gmail.com wrote: http://lists.freebsd.org/pipermail/freebsd-ports/2011-March/066146.html The workaround is `ln -sf j /etc/malloc.conf`. Thanks a lot. It solved the issue. :-) Sincerely, Gour -- “In the material world, conceptions of good and bad are all mental speculations…” (Sri Caitanya Mahaprabhu) http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: Any success stories for HAST + ZFS?
On Sat, Apr 2, 2011 at 1:44 AM, Pawel Jakub Dawidek p...@freebsd.org wrote: On Thu, Mar 24, 2011 at 01:36:32PM -0700, Freddie Cash wrote: [Not sure which list is most appropriate since it's using HAST + ZFS on -RELEASE, -STABLE, and -CURRENT. Feel free to trim the CC: on replies.] I'm having a hell of a time making this work on real hardware, and am not ruling out hardware issues as yet, but wanted to get some reassurance that someone out there is using this combination (FreeBSD + HAST + ZFS) successfully, without kernel panics, without core dumps, without deadlocks, without issues, etc. I need to know I'm not chasing a dead rabbit. I just committed a fix for a problem that might look like a deadlock. With trociny@ patch and my last fix (to GEOM GATE and hastd) do you still have any issues? Just to confirm, this is commit r220264, 220265, 220266 to -CURRENT? Looking through the commit logs, I don't see any of these MFC'd to -STABLE yet, so I can't test them directly. The storage box that was having the issues is running 8-STABLE r219754 at the moment (with ZFSv28 and Mikolag's ggate patches). I see there have been a lot of hast/ggate-related MFCs in the past week, but they don't include the deadlock patches. Once the deadlock patches above are MFC'd to -STABLE, I can do an upgrade cycle and test them. I do have the previous 9-CURRENT install saved, just nothing to run it on atm. -- Freddie Cash fjwc...@gmail.com ___ 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
crash on r220282
Someone suggested I might get better results including the actual panic: panic: Freeing unused sector 4918950 6 c41f Meanwhile the core.txt.1 file is in my home directory on freefall. Doug #0 sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/sched_ule.c:1854 #1 0x8042b16d in mi_switch (flags=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/kern_synch.c:450 #2 0x8045ce3a in sleepq_switch (wchan=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/subr_sleepqueue.c:538 #3 0x8045d303 in sleepq_timedwait (wchan=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/subr_sleepqueue.c:652 #4 0x8042abe8 in _sleep (ident=Variable ident is not available. ) at /home/svn/head/sys/kern/kern_synch.c:230 #5 0x8065cfa0 in scheduler (dummy=0x0) at /home/svn/head/sys/vm/vm_glue.c:771 #6 0x803dc2b3 in mi_startup () at /home/svn/head/sys/kern/init_main.c:258 #7 0x8027164f in btext () #8 0x80acba60 in bootverbose () #9 0x80a81a80 in tdq_cpu () #10 0x80acba60 in bootverbose () #11 0x80a83800 in sleepq_chains () #12 0x80caab80 in ?? () #13 0x80caab28 in ?? () #14 0xfe00015d4000 in ?? () #15 0x80442cd7 in sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/sched_ule.c:1848 Previous frame inner to this frame (corrupt stack?) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: multiple issues with devstat_*(9)
On Fri Apr 1 11, John Baldwin wrote:
On Thursday, March 31, 2011 6:33:39 pm Alexander Best wrote:
hi there,
i think there are multiple issues with devstat. i found the following in
devicestat.h:
/*
* These types are intended to aid statistics gathering/display programs.
* The first 13 types (up to the 'target' flag) are identical numerically
* to the SCSI device type numbers. The next 3 types designate the device
* interface. Currently the choices are IDE, SCSI, and 'other'. The last
* flag specifies whether or not the given device is a passthrough device
* or not. If it is a passthrough device, the lower 4 bits specify which
* type of physical device lies under the passthrough device, and the next
* 4 bits specify the interface.
*/
typedef enum {
DEVSTAT_TYPE_DIRECT = 0x000,
DEVSTAT_TYPE_SEQUENTIAL = 0x001,
DEVSTAT_TYPE_PRINTER= 0x002,
DEVSTAT_TYPE_PROCESSOR = 0x003,
DEVSTAT_TYPE_WORM = 0x004,
DEVSTAT_TYPE_CDROM = 0x005,
DEVSTAT_TYPE_SCANNER= 0x006,
DEVSTAT_TYPE_OPTICAL= 0x007,
DEVSTAT_TYPE_CHANGER= 0x008,
DEVSTAT_TYPE_COMM = 0x009,
DEVSTAT_TYPE_ASC0 = 0x00a,
DEVSTAT_TYPE_ASC1 = 0x00b,
DEVSTAT_TYPE_STORARRAY = 0x00c,
DEVSTAT_TYPE_ENCLOSURE = 0x00d,
DEVSTAT_TYPE_FLOPPY = 0x00e,
DEVSTAT_TYPE_MASK = 0x00f,
DEVSTAT_TYPE_IF_SCSI= 0x010,
DEVSTAT_TYPE_IF_IDE = 0x020,
DEVSTAT_TYPE_IF_OTHER = 0x030,
DEVSTAT_TYPE_IF_MASK= 0x0f0,
DEVSTAT_TYPE_PASS = 0x100
} devstat_type_flags;
also the devstat(9) man page says:
Each device is given a device type. Pass-through devices have the same
underlying device type and interface as the device they provide an
inter-
face for, but they also have the pass-through flag set. The base
device
types are identical to the SCSI device type numbers, so with SCSI
periph-
erals, the device type returned from an inquiry is usually ORed with
the
SCSI interface type and the pass-through flag if appropriate. The
device
type flags are as follows:
...so let's get started:
otaku% iostat -n100
ttyada0 ada1 md0
cd0pass0pass1pass2 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps
MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
192 21.18 0 0.01 24.37 12 0.29 0.00 0 0.00 60.27 0
0.01 0.37 0 0.00 0.37 0 0.00 0.00 0 0.00 5 0 4 0 90
..so far so good
otaku% iostat -t da
ttyada0 ada1 md0 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
192 21.18 0 0.01 24.37 12 0.29 0.00 0 0.00 5 0 4 0 90
...not good! this should include two pass devices!
This is probably due to the hard drives being IDE (really ATA) rather than
SCSI. I agree this should show the pass devices.
h...one could argue. the drives are ATA, however they are being associated
to the CAM subsystem. depends what one considers under scsi interface.
personally i'd like to see them inder scsi.
otaku% iostat -t scsi
tty cd0 cpu
tin tout KB/t tps MB/s us ni sy in id
192 60.27 0 0.01 5 0 4 0 90
..what?
If cd0 is an ATAPI CD-ROM drive, then this shouldn't even show cd0 as all of
your devices are IDE/ATA, not SCSI.
otaku% iostat -t ide
ttycpu
tin tout us ni sy in id
192 5 0 4 0 90
otaku% iostat -t other
ttycpu
tin tout us ni sy in id
192 5 0 4 0 90
...what about md0? ada0? ada1? md0?
md0 is a memory disk, it is neither SCSI nor IDE. However, -t ide (or even
better, a -t ata), should show all of your other devices (adaX and cd0) along
with their passX devices I think.
so md0 should show up under -t other. i don't think there's a -t ata.
otaku% iostat -t cd0
tty cd0 cpu
tin tout KB/t tps MB/s us ni sy in id
192 60.27 0 0.01 5 0 4 0 90
...this should also include a pass device
Agreed.
otaku% iostat -t pass
tty pass0pass1pass2 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
192 0.37 0 0.00 0.37 0 0.00 0.00 0 0.00 5 0 4 0 90
...this one's working as expected.
funny thing is i found the following in scsi_pass.c:
softc-device_stats = devstat_new_entry(pass,
periph-unit_number, 0,
sched_4bsd startup crash trying to run a bound thread on an AP that hasn't started
I'm running into a bootup crash under sched_4bsd on HEAD. The crash happens when I have a thread bound to a single CPU that isn't the BSP, and that thread is scheduled. If the AP that the thread is bound hasn't been started up, kick_other_cpu() crashes because pcpu-pc_curthread is NULL for the AP. I've put a small test kld in http://people.freebsd.org/~rstone/4bsd_bind/ that reproduces the problem. I'm not sure what the best way to address the crash is. ULE is not affected by the problem; it seems to run the swi thread on CPU 0 until CPU 1 is running. Here's a sample backtrace: Fatal trap 12: page fault while in kernel mode^M^M cpuid = 0; apic id = 00^M^M fault virtual address = 0x2fa^M^M fault code = supervisor read data, page not present^M^M instruction pointer = 0x20:0x803b473b^M^M stack pointer = 0x28:0x80a2c740^M^M frame pointer = 0x28:0x80a2c790^M^M code segment= base 0x0, limit 0xf, type 0x1b^M^M = DPL 0, pres 1, long 1, def32 0, gran 1^M^M processor eflags= resume, IOPL = 0^M^M current process = 0 (swapper)^M^M trap number = 12^M^M panic: page fault^M^M cpuid = 0^M^M KDB: stack backtrace:^M^M db_trace_self_wrapper() at 0x801cac8a = db_trace_self_wrapper+0x2a^M^M panic() at 0x8038ef92 = panic+0x182^M^M trap_fatal() at 0x8057d32d = trap_fatal+0x2ad^M^M trap() at 0x8057e01f = trap+0x29f^M^M calltrap() at 0x80561397 = calltrap+0x8^M^M --- trap 0xc, rip = 0x803b473b, rsp = 0x80a2c740, rbp = 0xfff f80a2c790 ---^M^M sched_add() at 0x803b473b = sched_add+0xeb^M^M intr_event_schedule_thread() at 0x803633e0 = intr_event_schedule_thread+0 xa0^M^M hardclock_device_poll() at 0x8037f9a5 = hardclock_device_poll+0x35^M^M hardclock() at 0x80342dd3 = hardclock+0x43^M^M lapic_handle_timer() at 0x80568033 = lapic_handle_timer+0xf3^M^M Xtimerint() at 0x80561ecc = Xtimerint+0x8c^M^M ___ 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: multiple issues with devstat_*(9)
On Monday, April 04, 2011 4:43:16 pm Alexander Best wrote: On Fri Apr 1 11, John Baldwin wrote: This is probably due to the hard drives being IDE (really ATA) rather than SCSI. I agree this should show the pass devices. h...one could argue. the drives are ATA, however they are being associated to the CAM subsystem. depends what one considers under scsi interface. personally i'd like to see them inder scsi. No, SCSI is a transport protocol. Alexandar Motin's work added a new transport layer that speaks ATA and that is what ada uses. CAM does not send SCSI commands to adaX devices AFAIK. otaku% iostat -t ide ttycpu tin tout us ni sy in id 192 5 0 4 0 90 otaku% iostat -t other ttycpu tin tout us ni sy in id 192 5 0 4 0 90 ...what about md0? ada0? ada1? md0? md0 is a memory disk, it is neither SCSI nor IDE. However, -t ide (or even better, a -t ata), should show all of your other devices (adaX and cd0) along with their passX devices I think. so md0 should show up under -t other. i don't think there's a -t ata. Yes, I think we should possibly add a -t ata, possibly as an alias for -t ide. -- John Baldwin ___ 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: crash on r220282
On Mon, Apr 04, 2011 at 01:09:32PM -0700, Doug Barton wrote: Someone suggested I might get better results including the actual panic: panic: Freeing unused sector 4918950 6 c41f Meanwhile the core.txt.1 file is in my home directory on freefall. Doug #0 sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/sched_ule.c:1854 #1 0x8042b16d in mi_switch (flags=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/kern_synch.c:450 #2 0x8045ce3a in sleepq_switch (wchan=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/subr_sleepqueue.c:538 #3 0x8045d303 in sleepq_timedwait (wchan=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/subr_sleepqueue.c:652 #4 0x8042abe8 in _sleep (ident=Variable ident is not available. ) at /home/svn/head/sys/kern/kern_synch.c:230 #5 0x8065cfa0 in scheduler (dummy=0x0) at /home/svn/head/sys/vm/vm_glue.c:771 #6 0x803dc2b3 in mi_startup () at /home/svn/head/sys/kern/init_main.c:258 #7 0x8027164f in btext () #8 0x80acba60 in bootverbose () #9 0x80a81a80 in tdq_cpu () #10 0x80acba60 in bootverbose () #11 0x80a83800 in sleepq_chains () #12 0x80caab80 in ?? () #13 0x80caab28 in ?? () #14 0xfe00015d4000 in ?? () #15 0x80442cd7 in sched_switch (td=dwarf2_read_address: Corrupted DWARF expression. ) at /home/svn/head/sys/kern/sched_ule.c:1848 Previous frame inner to this frame (corrupt stack?) The backtrace is for the wrong thread. There should be the thread that panicked, and it is the thread backtrace that is interesting. pgpdB6lICszxo.pgp Description: PGP signature
KGDB stack traces in the kernel.
currently in kernel stack traces I see: [Switching to Thread 100246] 0x814617f3 in fio_local_to_global_packet () from x/mumble.ko (kgdb) bt #0 0x814617f3 in () from x/mumble.ko #1 0x8146171f in () from x/mumble.ko [...] #14 0x805c4b8e in fork_exit (callout=0x814dfe30 mumble_kthread_wrapper, arg=0x7d8b48000421dbe8, frame=0x814fc340c6c74800) at ../../../kern/kern_fork.c:859 #15 0xf045c748e87d8948 in ?? () #16 0xb5058b48 in ?? () #17 0x000130054800074e in ?? () #18 0x950fc0850c408b00 in ?? () and then the stack trace goes on forever with garbage. #19 0x74c08548c0b60fc0 in ?? () #20 0x814fdb70c6c74816 in ?? () #21 0xb80007bf in ?? () #22 0x48000425b9e8 in ?? () #23 0x1210c78148e87d8b in ?? () #24 0x480bd1ba in ?? () #25 0x3de8814fc340c6c7 in ?? () #26 0x558b4828eb000421 in ?? () #27 0xc68148e8758b48f0 in ?? () #28 0xe87d8b481210 in ?? () #29 0xe81178c78148 in ?? () #30 0x83fc458900041bdc in ?? () #31 0x7d8b480d7400fc7d in ?? () #32 0xc085fdfae8e8 in ?? () #33 0x8148e87d8b48cb74 in ?? () #34 0x0bdcba1210c7 in ?? () #35 0x4fc340c6c748 in ?? () #36 0x8b48000420aae881 in ?? () #37 0x07600548e845 in ?? () #38 0x0019bfc68948 in ?? () etc is there anyone here with enough gdb/kgdb source experience to know what we would need to put on the stack at fork_exit() to make it stop when it gets there? not only is it annoying but it slows down debugging because kgdb and the ddd front end ask for stacks a LOT. sometimes it actually just hangs as the stack goes into a loop and never ends. I had a quick look but didn't spot how gdb decides it has reached the end of a stack. Julian ___ 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
Setting up a running FreeBSD/PCBSD system to enter kgdb on panic
Hi All, Is there some way I can setup a running FreeBSD - (I use PCBSD7.2) - to break into kgdb when the system panics. I am trying to get a stack trace when Fatal trap 12: page fault while in kernel mode happens. thanks david S. This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. ___ 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: Setting up a running FreeBSD/PCBSD system to enter kgdb on panic
On Mon, Apr 4, 2011 at 7:35 PM, David Somayajulu david.somayaj...@qlogic.com wrote: Hi All, Is there some way I can setup a running FreeBSD - (I use PCBSD7.2) - to break into kgdb when the system panics. I am trying to get a stack trace when Fatal trap 12: page fault while in kernel mode happens. debug.debugger_on_panic=1 -- Eitan Adler ___ 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: Setting up a running FreeBSD/PCBSD system to enter kgdb on panic
On 4/4/11 4:35 PM, David Somayajulu wrote: Hi All, Is there some way I can setup a running FreeBSD - (I use PCBSD7.2) - to break into kgdb when the system panics. I am trying to get a stack trace when Fatal trap 12: page fault while in kernel mode happens. thanks david S. sure but firstly have you already got everything set up so you can get into kgdb normally? (serial cable? (or firewire?) ports all set up right? second machine? here are som bits of the puzzle for my machine: from /boot/device.hints: hint.uart.1.at=isa hint.uart.1.port=0x2F8 hint.uart.1.flags=0x80 hint.uart.1.irq=3 hint.uart.1.baud=115200 in /etc/sysctl.conf: debug.kdb.current=gdb but usually I find it better to go to ddb first and do a ps and backtrace as ps is a pain on gdb and needs macros etc. and of course kgdb needs to be set up correctly the handbook says a lot about that. This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message. ___ 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: Setting up a running FreeBSD/PCBSD system to enter kgdb on panic
On Mon, Apr 4, 2011 at 5:26 PM, Julian Elischer jul...@freebsd.org wrote: On 4/4/11 4:35 PM, David Somayajulu wrote: Hi All, Is there some way I can setup a running FreeBSD - (I use PCBSD7.2) - to break into kgdb when the system panics. I am trying to get a stack trace when Fatal trap 12: page fault while in kernel mode happens. thanks david S. sure but firstly have you already got everything set up so you can get into kgdb normally? (serial cable? (or firewire?) ports all set up right? second machine? here are som bits of the puzzle for my machine: from /boot/device.hints: hint.uart.1.at=isa hint.uart.1.port=0x2F8 hint.uart.1.flags=0x80 hint.uart.1.irq=3 hint.uart.1.baud=115200 .flags on uart(4) doesn't support 0x20, 0x40, like on sio(4). Interesting. 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: KGDB stack traces in the kernel.
On Apr 4, 2011, at 6:57 PM, Julian Elischer wrote: is there anyone here with enough gdb/kgdb source experience to know what we would need to put on the stack at fork_exit() to make it stop when it gets there? not only is it annoying but it slows down debugging because kgdb and the ddd front end ask for stacks a LOT. sometimes it actually just hangs as the stack goes into a loop and never ends. I had a quick look but didn't spot how gdb decides it has reached the end of a stack. Julian From my experience, it checks for a NULL stack chain pointer. Once that reaches NULL, it's the end of the stack. - Justin ___ 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
