Re: panic: softdep_move_dependencies: need merge code (driver mtp(4)?)
Sorry, my answer to this is to move away from softupdates and towards journalling. I'm working on that, albeit slowly due to the many other NFS and VFS bugs that I have to deal with. Scott Marcus Alves Grando wrote: Someone have one idea about that? Apparently that's occurs after high disk load (bsdtar). Matt, your changes in mpt driver are stable? Regards Scott Long wrote: Heh, that's supposed to be a 'this will never happen' case. Scott Marcus Alves Grando wrote: panic: softdep_move_dependencies: need merge code Maybe something in mtp(4) driver? FreeBSD 6.1-PRERELEASE #0: Sat Apr 1 04:20:17 BRT 2006 db> sh msgbuf msgbufp = 0xc103afe4 magic = 63062, size = 32740, r= 35282, w = 66579, ptr = 0xc1033000, cksum= 2663542 mpt0: Attempting to Abort Req 0xc4bd3238 mpt0: Request 0xc4bd36e8 Timed out. mpt0: Request 0xc4bd2e00 Timed out. ... g_vfs_done():da0s1g[READ(offset=36612947968, length=16384)]error = 5i g_vfs_done():da0s1g[READ(offset=37008271360, length=2048)]error = 5n g_vfs_done():da0s1g[READ(offset=37725519872, length=8192)]error = 5 g_vfs_done():da0s1g[WRITE(offset=40080080896, length=16384)]error = 5 panic: softdep_move_dependencies: need merge code cpuid = 1 KDB: enter: panic xited on signal 11 db> bt Tracing pid 3 tid 100016 td 0xc4ae6af0 kdb_enter(c0791fcb) at kdb_enter+0x2b panic(c079eff5,d8bf6bc0,c4f4e830,4,e35dcc90) at panic+0x127 softdep_move_dependencies(d8bf6bc0,d8bcf040) at softdep_move_dependencies+0x1f ffs_backgroundwritedone(d8bf6bc0) at ffs_backgroundwritedone+0xca bufdone(d8bf6bc0) at bufdone+0x42 g_vfs_done(c5d9e084) at g_vfs_done+0xab biodone(c5d9e084) at biodone+0x8b g_io_schedule_up(c4ae6af0) at g_io_schedule_up+0x86 g_up_procbody(0,e35dcd38) at g_up_procbody+0x92 fork_exit(c05270b8,0,e35dcd38) at fork_exit+0x71 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe35dcd6c, ebp = 0 --- All DDB info: http://marcus.grupos.com.br:8080/patch/panic-server.log Thanks ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: softdep_move_dependencies: need merge code (driver mtp(4)?)
Someone have one idea about that? Apparently that's occurs after high disk load (bsdtar). Matt, your changes in mpt driver are stable? Regards Scott Long wrote: > Heh, that's supposed to be a 'this will never happen' case. > > Scott > > > Marcus Alves Grando wrote: >> panic: softdep_move_dependencies: need merge code >> >> Maybe something in mtp(4) driver? >> >> FreeBSD 6.1-PRERELEASE #0: Sat Apr 1 04:20:17 BRT 2006 >> >> db> sh msgbuf >> msgbufp = 0xc103afe4 >> magic = 63062, size = 32740, r= 35282, w = 66579, ptr = 0xc1033000, >> cksum= 2663542 >> mpt0: Attempting to Abort Req 0xc4bd3238 >> mpt0: Request 0xc4bd36e8 Timed out. >> mpt0: Request 0xc4bd2e00 Timed out. >> ... >> g_vfs_done():da0s1g[READ(offset=36612947968, length=16384)]error = 5i >> g_vfs_done():da0s1g[READ(offset=37008271360, length=2048)]error = 5n >> g_vfs_done():da0s1g[READ(offset=37725519872, length=8192)]error = 5 >> g_vfs_done():da0s1g[WRITE(offset=40080080896, length=16384)]error = 5 >> panic: softdep_move_dependencies: need merge code >> cpuid = 1 >> KDB: enter: panic >> xited on signal 11 >> >> db> bt >> Tracing pid 3 tid 100016 td 0xc4ae6af0 >> kdb_enter(c0791fcb) at kdb_enter+0x2b >> panic(c079eff5,d8bf6bc0,c4f4e830,4,e35dcc90) at panic+0x127 >> softdep_move_dependencies(d8bf6bc0,d8bcf040) at >> softdep_move_dependencies+0x1f >> ffs_backgroundwritedone(d8bf6bc0) at ffs_backgroundwritedone+0xca >> bufdone(d8bf6bc0) at bufdone+0x42 >> g_vfs_done(c5d9e084) at g_vfs_done+0xab >> biodone(c5d9e084) at biodone+0x8b >> g_io_schedule_up(c4ae6af0) at g_io_schedule_up+0x86 >> g_up_procbody(0,e35dcd38) at g_up_procbody+0x92 >> fork_exit(c05270b8,0,e35dcd38) at fork_exit+0x71 >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0x1, eip = 0, esp = 0xe35dcd6c, ebp = 0 --- >> >> All DDB info: >> http://marcus.grupos.com.br:8080/patch/panic-server.log >> >> Thanks >> > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Marcus Alves Grando marcus(at)corp.grupos.com.br | Grupos Internet S/A mnag(at)FreeBSD.org | FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portsnap mirror servers
On Tue, Apr 18, 2006 at 01:43:52AM +0100, Chris wrote: > How many mirrors does portsnap have, it seems to only have around 3 or > 4 and they all located in the .us whilst cvs has dozens around the > world. > > Is there a eu pool of mirrors available to use or if not is their a > way I can apply to host an eu mirror or even 2 eu mirrors. According to Colin's writeup here: http://people.freebsd.org/~cperciva/funding.html > Right now [the mirroring code] uses around one thousand times more > bandwidth than an individual client machine; as a result, I've been > asking people to use the existing mirrors rather than creating their > own, but for a variety of reasons this isn't ideal for everybody. Hopefully that will be fixed this summer and then we'll have lots of mirrors. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp9sLI2bla7I.pgp Description: PGP signature
portsnap mirror servers
How many mirrors does portsnap have, it seems to only have around 3 or 4 and they all located in the .us whilst cvs has dozens around the world. Is there a eu pool of mirrors available to use or if not is their a way I can apply to host an eu mirror or even 2 eu mirrors. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CPUTYPE=athlon-xp and loader
On Mon, April 17, 2006 6:23 pm, James Long said: >> Date: Sun, 16 Apr 2006 17:43:58 +0300 >> From: Evren Yurtesen <[EMAIL PROTECTED]> >> Subject: CPUTYPE=athlon-xp and loader >> To: freebsd-stable@freebsd.org >> Message-ID: <[EMAIL PROTECTED]> >> >> >> Hello, >> >> >> I have a problem which I have found out from mailing lists that some >> other people had. However there is no clear solution. >> >> The CPUTYPE=athlon-xp in make.conf breaks /boot/loader that system >> instant reboots. I am using 6-stable and from what I can see the problem >> goes back till about 5.3... Sometime between Oct 12-15, 2005 > I don't propose this as a solution, but as far as I know, the best > practice is: > > CPUTYPE?=athlon-xp Does anyone know if this improves performance on an ahtlon-xp ? -kim -- [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CPUTYPE=athlon-xp and loader
> Date: Sun, 16 Apr 2006 17:43:58 +0300 > From: Evren Yurtesen <[EMAIL PROTECTED]> > Subject: CPUTYPE=athlon-xp and loader > To: freebsd-stable@freebsd.org > Message-ID: <[EMAIL PROTECTED]> > > Hello, > > I have a problem which I have found out from mailing lists that some > other people had. However there is no clear solution. > > The CPUTYPE=athlon-xp in make.conf breaks /boot/loader that system > instant reboots. I am using 6-stable and from what I can see the problem > goes back till about 5.3... Sometime between Oct 12-15, 2005 > > http://archive.netbsd.se/?ml=freebsd-current&a=2004-10&m=435817 > > I wonder if this will ever be fixed or I shouldnt use CPUTYPE=athlon-xp > anymore on FreeBSD because of this? > > Thanks, > Evren I don't propose this as a solution, but as far as I know, the best practice is: CPUTYPE?=athlon-xp Note the question mark. I don't know that this will solve your problem, just pointing out the correct syntax, for whatever CPUTYPE you decide to use. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB & ACPI getting better but not quite there - IBM T42p
Am Samstag, den 15.04.2006, 20:50 +0200 schrieb Georg-W. Koltermann: > Hi, > > I was delighted to see that my laptop now wakes up fine when booted from > an external USB disk with 6.1-RC1 (actually RELENG_6_1 supped > yesterday). I had inadvertently suspended, and it did come back up when > hitting the power switch! Hmm, I regret to follow up that this only works in rare cases. Most of the time the machine hangs during suspend, or runs into USB timeouts (umass0: BBB reset failed, TIMEOUT), or both -- I'm not sure, I may have been impatient before seeing the USB timeout message sometimes. Also on one occasion where the suspend did work I then power cycled the disk before resume, and then at resume I got a panic about not being able to access the disk. So I guess I was wrong with about 98% of my statements :-( -- it doesn't work yet. -- Regards, Georg. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bge0 problem on 6.1-PR
On Thu, Apr 13, 2006 at 11:01:51PM +0900, SungGON Yi. wrote: > I am using 6.x on Tyan S2885ANRF board and add one more NIC. > Device names are bge0 (board lan) and bge1 (additional NIC). > > These worked well on FreeBSD 6.0-amd64 stable. > But when I updated to 6.1-PRERELEASE version, I had below messages and bge0 > did not work. > bge1 worked well as before. > > > bge0: watchdog timeout -- resetting > > > I am using 6.0-RELEASE now. > > > bge0: mem > 0xfc6f-0xfc6f irq 27 at device 8.0 on pci2 > miibus0: on bge0 > brgphy0: on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge0: Ethernet address: 00:04:76:f3:e8:c9 > bge1: mem > 0xfc6e-0xfc6e irq 24 at device 9.0 on pci2 > miibus1: on bge1 > brgphy1: on miibus1 > brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, > 1000baseTX-FDX, auto > bge1: Ethernet address: 00:e0:81:27:a0:f6 > --- > > > $ ifconfig > bge0: flags=8843 mtu 1500 > options=1b > inet6 fe80::204:76ff:fef3:e8c9%bge0 prefixlen 64 scopeid 0x1 > inet xxx.xxx.xxx.xxx netmask 0xff00 broadcast xxx.xxx.xxx.xxx > ether 00:04:76:f3:e8:c9 > media: Ethernet autoselect (100baseTX ) > status: active > bge1: flags=8843 mtu 1500 > options=1b > inet6 fe80::2e0:81ff:fe27:a0f6%bge1 prefixlen 64 scopeid 0x2 > inet 192.168.24.106 netmask 0xff00 broadcast 192.168.24.255 > ether 00:e0:81:27:a0:f6 > media: Ethernet autoselect (1000baseTX ) > status: active > lo0: flags=8049 mtu 16384 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 > inet 127.0.0.1 netmask 0xff00 > pfsync0: flags=0<> mtu 2020 > pflog0: flags=0<> mtu 33160 > > > SungGON Yi. > [EMAIL PROTECTED] > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" I've seen one report about broken onboard bcm5701 asic rev 0x105. Unfortunatly i dont have such motherboard to play with. I have PCI nic with same chip/revision which works fine. Do you mind of doing binary search on if_bge.c (rev. 1.95 - 1.118) ? -- Oleg. pgpPDYZcHFUr4.pgp Description: PGP signature
Re: [LOR] bpf vs. USB (perhaps #147?)
Hello again, found some other LORs on 6.1-PRERELEASE while running kismet and tcpdump on ural0 at the same time. They all look very similar, though one is in usb_read, the other in usb_write. ... lock order reversal: (Giant after non-sleepable) 1st 0xc079c280 bpf global lock (bpf global lock) @ /usr/src/sys/net/bpf.c:425 2nd 0xc07502c0 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:216 ... added with LOR ID #184 to "the LOR page": http://sources.zabbadoz.net/freebsd/lor.html#184 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CPUTYPE=athlon-xp and loader
Evren Yurtesen wrote: Bartosz Fabianowski wrote: I filed a bug report for this in January of 2005: http://www.freebsd.org/cgi/query-pr.cgi?pr=75898 Wow, that was a long time ago! I am thinking that the Makefile fix is very attractive because the only problem is the loader for me. It seems like it is the same for most other people. So why not just fix the loader's Makefile so it wont use these instructions until some more permanent fix is found? Actually, this was done prior to 5.4 and 6.0. For details see revision 1.10 of src/sys/boot/i386/Makefile.inc (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/Makefile.inc). What CFLAGS are you using and when did you last rebuild world/kernel? It is really not nice when I need to boot my computer with Freesbie and change the loader since there is no way that I can boot FreeBSD once this happens. Speaking of which, revision 1.11 of src/sys/boot/i386/Makefile.inc should be MFC'd before 5.5 and 6.1. -Jonathan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CPUTYPE=athlon-xp and loader
Evren Yurtesen wrote: I have a problem which I have found out from mailing lists that some other people had. However there is no clear solution. The CPUTYPE=athlon-xp in make.conf breaks /boot/loader that system instant reboots. I am using 6-stable and from what I can see the problem goes back till about 5.3... Sometime between Oct 12-15, 2005 I've seen no problems using CPUTYPE?=athlon-xp. http://archive.netbsd.se/?ml=freebsd-current&a=2004-10&m=435817 I wonder if this will ever be fixed or I shouldnt use CPUTYPE=athlon-xp anymore on FreeBSD because of this? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
failing PXE boot/HP-DL145
I can boot this HP Proliant DL145/amd64 box from the CD, but fails when booting via PXE. My guess the problem is in the pxeboot, but comparing to an older pxeboot that works (around Nov, 1005) the diffs seem cosmetic. The current pxeboot works fine with other diskless hosts. danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: CPUTYPE=athlon-xp and loader
Bartosz Fabianowski wrote: I filed a bug report for this in January of 2005: http://www.freebsd.org/cgi/query-pr.cgi?pr=75898 - Bartosz Wow, that was a long time ago! I am thinking that the Makefile fix is very attractive because the only problem is the loader for me. It seems like it is the same for most other people. So why not just fix the loader's Makefile so it wont use these instructions until some more permanent fix is found? It is really not nice when I need to boot my computer with Freesbie and change the loader since there is no way that I can boot FreeBSD once this happens. Thanks, Evren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
