Kopete, kplayer, kdelibs etc
I know there ar eknown issues about kopete and it being able to connect to MSN & Yahoo, im runnind KDE4 on AMD64 FreeBSD7.0-STABLE .. cvsupd today so all ports & SRC are upto date portupgrade done and yet kopete still refuses to connect to MSN or yahoo .. is the bug still on going or ? Since upgrading to KDE4 as well, kplayer refuses to run and i have had to goto VLC player to be able to watch vide files ... any reason why this would refuse to load ? When trying to re-compile things like Xchat and other various files that seem to be broken, i run into troubles with an error saying/mentioning kdelibs and QT .. excat error i couldnt say as i have now also lost complete internet access on the machine even though still able to communicate with the router and all other machines ironically running windows, seem to be running aok, so im trying to kill multiple birds using memory and booting from windows to FreeBSD etc At this point im frustrated enough to just fdisk the machine, and isntall everything from scratch with 7.0-STABLE & KDE4 .. so i ask for a lil assistance plz so as i can avoid having to do this drastic measure. -- No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 270.6.5/1619 - Release Date: 18/08/2008 5:39 PM ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
At 07:15 PM 8/18/2008, Robert Watson wrote:
On Mon, 18 Aug 2008, Mike Tancsa wrote:
At 06:32 PM 8/18/2008, Kip Macy wrote:
Could you please check that this doesn't happen on HEAD as well?
This same code has been in 8 since shortly after the branch.
I dont have any easy way to migrate the box to HEAD and
then back. Can I just boot a kernel from HEAD ?
In general yes, but the uart changes in HEAD mean that you may need
to tweak device.hints or change configurations.
I booted with a kernel from HEAD (I grabbed one Kris built from
zoo.freebsd.org, hopefully no strange things with it)
and I see the same problems. Working with Kip last night, I added to
the tcp_offload function
int
tcp_offload_connect(struct socket *so, struct sockaddr *nam)
{
struct ifnet *ifp;
struct toedev *tdev;
struct rtentry *rt;
int error;
return (EINVAL);
and that eliminated the problem.
0[smtp2]% uname -a
FreeBSD smtp2.sentex.ca 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Mon Aug
18 15:14:54 UTC
2008
[EMAIL PROTECTED]:/zoo/kris/p4-nfs/sys/i386/compile/LEOPARD
i386
0[smtp2]% arp -na
? (64.7.153.7) at 00:13:20:c6:86:30 on em1 [ethernet]
? (64.7.153.9) at 00:30:48:90:52:18 on em1 [ethernet]
? (64.7.153.9) at (incomplete) on em1 published (proxy only) [ethernet]
? (64.7.153.9) at (incomplete) on em1 [ethernet]
? (64.7.153.12) at 00:0c:6e:fc:52:2d on em1 [ethernet]
? (64.7.153.18) at 00:14:2a:ad:37:70 on em1 [ethernet]
? (64.7.153.19) at 00:15:17:24:dc:bb on em1 [ethernet]
? (64.7.153.19) at (incomplete) on em1 [ethernet]
? (64.7.153.19) at (incomplete) on em1 [ethernet]
? (64.7.153.19) at (incomplete) on em1 [ethernet]
? (64.7.153.19) at (incomplete) on em1 published (proxy only) [ethernet]
? (64.7.153.19) at (incomplete) on em1 [ethernet]
? (64.7.153.20) at 00:14:2a:e0:c1:1c on em1 [ethernet]
? (64.7.153.20) at (incomplete) on em1 [ethernet]
? (64.7.153.21) at 00:00:5e:00:01:06 on em1 [ethernet]
? (64.7.153.21) at (incomplete) on em1 published (proxy only) [ethernet]
? (64.7.153.24) at 00:e0:81:5a:22:05 on em1 [ethernet]
? (64.7.153.24) at (incomplete) on em1 [ethernet]
? (64.7.153.25) at 00:50:fc:a7:c9:d3 on em1 [ethernet]
? (64.7.153.25) at (incomplete) on em1 published (proxy only) [ethernet]
? (64.7.153.26) at 00:14:2a:13:ea:00 on em1 [ethernet]
? (64.7.153.26) at (incomplete) on em1 published (proxy only) [ethernet]
? (64.7.153.27) at 00:14:2a:99:b1:ad on em1 [ethernet]
? (64.7.153.27) at (incomplete) on em1 published (proxy only) [ethernet]
? (64.7.153.27) at (incomplete) on em1 published (proxy only) [ethernet]
? (199.212.134.1) at 00:15:17:3a:17:9d on em0 [ethernet]
? (199.212.134.1) at (incomplete) on em0 [ethernet]
? (199.212.134.1) at (incomplete) on em0 [ethernet]
? (199.212.134.1) at (incomplete) on em0 [ethernet]
? (199.212.134.1) at (incomplete) on em0 [ethernet]
? (199.212.134.1) at (incomplete) on em0 [ethernet]
? (199.212.134.1) at (incomplete) on em0 published (proxy only) [ethernet]
? (199.212.134.1) at (incomplete) on em0 [ethernet]
? (199.212.134.1) at (incomplete) on em0 [ethernet]
? (199.212.134.1) at (incomplete) on em0 [ethernet]
? (199.212.134.1) at (incomplete) on em0 [ethernet]
? (199.212.134.1) at (incomplete) on em0 [ethernet]
? (199.212.134.1) at (incomplete) on em0 [ethernet]
? (199.212.134.1) at (incomplete) on em0 [ethernet]
? (199.212.134.1) at (incomplete) on em0 [ethernet]
? (199.212.134.2) at 00:30:48:8f:3e:8a on em0 [ethernet]
? (199.212.134.4) at 00:02:b3:5d:ca:f6 on em0 [ethernet]
? (199.212.134.9) at 00:15:17:27:80:9f on em0 permanent [ethernet]
? (199.212.134.10) at 00:e0:81:5e:bd:6f on em0 [ethernet]
? (199.212.134.11) at 00:d0:b7:db:69:6a on em0 [ethernet]
0[smtp2]%
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ICH9 Controller on Asus P5K-E showing up as "Intel AHCI controller"
> As Jeremy said it is ok. In pciconf output you can see > "class=0x010601". Your ICH9 controller has PCI subclass 0x06 (SATA) > and PCI programming interface 0x01 (AHCI). Thank you both! I figured it was operating normally (I've noticed no performance problems or oddities from the controller or devices attached to it). I guess in trying to find out what was going on, I saw this comment: /* is this PCI device flagged as an AHCI compliant chip ? */ if (pci_read_config(dev, PCIR_PROGIF, 1) != PCIP_STORAGE_SATA_AHCI_1_0) Which if I read the comment literally makes me believe if that does not return non-zero/NULL, that my controller is not AHCI compliant. But if it's falling back on a perfectly working generic AHCI implementation, what it reports at boot time is moot. :) Thanks again guys! Josh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
busybox port available (was Re: busybox and small scripting languages on FreeBSD...)
replying to a thread of a couple of weeks ago... I managed to build a reasonable subset of busybox (1.11.1) on FreeBSD, you can find patches at http://info.iet.unipi.it/~luigi/FreeBSD/#busybox-port The linux-specific things (e.g. those relying on /proc or system APIs that we don't have) clearly do not work, and I did not bother trying to implement replacement for them. But many userland commands do work and maybe they are useful to have around in a small system. A sample of the file sizes (the 'dec' column from the 'size' command): 37136 work/busybox-1.11.1/shell/ash.o 18492 work/busybox-1.11.1/libbb/appletlib.o 18258 work/busybox-1.11.1/editors/vi.o 17995 work/busybox-1.11.1/editors/awk.o 9878 work/busybox-1.11.1/networking/httpd.o 9289 work/busybox-1.11.1/archival/bzip2.o 7609 work/busybox-1.11.1/editors/diff.o 6378 work/busybox-1.11.1/miscutils/less.o 6258 work/busybox-1.11.1/editors/sed.o 6170 work/busybox-1.11.1/archival/gzip.o 5367 work/busybox-1.11.1/editors/ed.o 5317 work/busybox-1.11.1/archival/libunarchive/decompress_unzip.o 5132 work/busybox-1.11.1/networking/wget.o 4485 work/busybox-1.11.1/networking/traceroute.o 4277 work/busybox-1.11.1/libbb/dump.o ... overall, the binary in this configuration is around 330kb. cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: trying to mount a write prptected zip disk panics the machine (unless the -r flag is used)
On Monday 18 August 2008 01:44:00 pm Torfinn Ingolfsen wrote:
> On Mon, 18 Aug 2008 10:33:05 -0400
> John Baldwin <[EMAIL PROTECTED]> wrote:
>
> >
> > Can you get the stack trace?
>
> Like this?
> [EMAIL PROTECTED] kgdb kernel.debug /var/crash/vmcore.0
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are welcome to change it and/or distribute copies of it under
> certain conditions. Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details. This GDB was configured as "i386-marcel-freebsd"...
>
> Unread portion of the kernel message buffer:
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x0
> fault code = supervisor read, page not present
> instruction pointer = 0x20:0xc0737b19
> stack pointer = 0x28:0xceb9cbcc
> frame pointer = 0x28:0xceb9cbf8
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 42 (syncer)
> trap number = 12
> panic: page fault
> cpuid = 0
> Uptime: 24m34s
> Physical memory: 307 MB
> Dumping 58 MB: 43 27 11
>
> Reading symbols from /boot/kernel/acpi.ko...Reading symbols
> from /boot/kernel/acpi.ko.symbols...done. done.
> Loaded symbols for /boot/kernel/acpi.ko
> #0 doadump () at pcpu.h:195
> 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> (kgdb)
> (kgdb) backtrace
> #0 doadump () at pcpu.h:195
> #1 0xc078eed7 in boot (howto=260)
> #at /usr/src/sys/kern/kern_shutdown.c:418 2 0xc078f199 in panic
> #(fmt=Variable "fmt" is not available.
> ) at /usr/src/sys/kern/kern_shutdown.c:572
> #3 0xc0a9efbc in trap_fatal (frame=0xceb9cb8c, eva=0)
> #at /usr/src/sys/i386/i386/trap.c:899 4 0xc0a9f240 in trap_pfault
> #(frame=0xceb9cb8c, usermode=0, eva=0)
> #at /usr/src/sys/i386/i386/trap.c:812 5 0xc0a9fbec in trap
> #(frame=0xceb9cb8c) at /usr/src/sys/i386/i386/trap.c:490 6 0xc0a859ab
> #in calltrap () at /usr/src/sys/i386/i386/exception.s:139 7 0xc0737b19
> #in g_io_request (bp=0xc299ba50, cp=0xc29b2e00)
> #at /usr/src/sys/geom/geom_io.c:364 8 0xc073c116 in g_vfs_strategy
> #(bo=0xc29881d4, bp=0xc88efc24) at /usr/src/sys/geom/geom_vfs.c:107 9
> #0xc07f97b0 in bufwrite (bp=0xc88efc24) at buf.h:429 10 0xc07f2618 in
> #bawrite (bp=0xc88efc24) at buf.h:417 11 0xc07fddaa in vop_stdfsync
> #(ap=0xceb9ccd4) at /usr/src/sys/kern/vfs_default.c:479 12 0xc071cbbe
> #in devfs_fsync (ap=0xceb9ccd4)
> #at /usr/src/sys/fs/devfs/devfs_vnops.c:395 13 0xc0ab3ce2 in
> #VOP_FSYNC_APV (vop=0xc0bcf040, a=0xceb9ccd4) at vnode_if.c:1007 14
> #0xc080dff8 in sched_sync () at vnode_if.h:538 15 0xc076bc59 in
> #fork_exit (callout=0xc080d8f0 , arg=0x0, frame=0xceb9cd38)
> at /usr/src/sys/kern/kern_fork.c:781
> #16 0xc0a85a20 in fork_trampoline ()
> #at /usr/src/sys/i386/i386/exception.s:205
>
> Let me know if it was wrong, or if you need something else.
That's right, but not the specific bug I am familiar with. :(
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
