Re: [HEADSUP][CFT] pkgng beta1 is out
On Feb 6, 2012 3:50 AM, Radio młodych bandytów radiomlodychbandy...@o2.pl wrote: I wonder if I'm the only one thinking about a decentralised package management First, a decentralised transport layer. Torrents are faster and more reliable than servers. Second, decentralised management when anybody can upload a port directly into the system. -- Twoje radio Such a system would need to support traditional protocols such as FTP HTTP due to many corporate environments not allowing anything else. I'm all for a distributed system but you can't forget the corporate users. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] Xorg Upgrade 7.5.2
Does this mean I can stop using 10.0-current on my Lenovo X121e? ;-) It works surprisingly well but it does feel a bit wrong. On Mon, 6 Feb 2012, Martin Wilke wrote: Knock knock... The X11 Team is pleased to announce the next round of Xorg updates. Note that this is experimental so you really have to know what you are doing, read UPDATING in the repository, and follow our exact instructions. We are specifically looking for feedback from Intel, ATI and NVIDIA users. Summary of changes: xf86-video-nouveau has been removed along with the WITHOUT_NOUVEAU knob. We suggest switching to the nvidia blob. KMS Support [1]: Unfortunately, the intel KMS driver will only work for the latest FreeBSD 9-STABLE or 10-CURRENT users. The patch for HEAD current is named all.13.1.patch. The higher the version the newer the patch is. Other needed patches are already available in the Xorg update. HEAD Users: Get the latest patchset from Kib here: http://people.freebsd.org/~kib/drm/ 9-STABLE Users: 'meowthink' is currently maintaining the backport to 9 STABLE. Make sure you have the latest FreeBSD 9-STABLE source. Get the patch from here: https://docs.google.com/leaf?id=0BxbPi2OX4_B-NWY3NWU3MzEtNDBjYy00NTljLThlZGItMWFlYjIyYjI4Yjk3hl=en_US Rebuild your Kernel and reboot. Known issuse: There will be a patch reject in the sys/dev/drm/i915_suspend.c file. The solution is to manually undo the expansion of the $FreeBSD: $ tag, so it only saysis $FreeBSD$. Checkout Xorg Development Repo: You will need to install devel/subversion in order to checkout the xorg repo. Next, you will need to add WITH_NEW_XORG=yes in your /etc/make.conf if you want to try out the new Xorg and mesa. Intel users: note that if you are not qualified for the KMS patch, you shouldn't use WITH_NEW_XORG=yes because the old intel driver doesn't build with the new X server. If you are qualified, you should also set WITH_KMS=yes in /etc/make.conf. svn co https://trillian.chruetertee.ch/svn/ports/tags/xorg_7_5_2 A small merge script to merge the svn checkout into the real portstree can be found here: http://people.freebsd.org/~miwi/xorg/xorgmerge The script is a modified version of the old kdemerge script. Please set the KDEDIR variable to the path of your X.org ports. After merging, run one of the following command, depending on which tool you use to manage your installed packages. portupgrade -af \* portmaster -a After installing these, you will have to rebuild all xf86-* ports. We will bump all related ports during the commit to the ports tree. Roadmap: Our current plan is to let the CFT running until the last weekend of February. We hope to get a lot feedback to solve as many problems as possible. So please help us to get the best xorg update ever in! Links: http://wiki.freebsd.org/Intel_GPU [1] http://wiki.freebsd.org/Xorg http://miwi.bsdcrew.de/2012/02/working-on-xorg-stuff/ Your FreeBSD Xorg Team PS: Please reply to the x11@ mailing list. Cross posted due to the potentially disruptive nature of the change and need to get a wide variety of testers. -- +--oOO--(_)--OOo+ With best Regards, Martin Wilke (miwi_(at)_FreeBSD.org) ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org _ Daniel Stolpe Tel: 08 - 688 11 81 sto...@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm ___ 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
panic
On ia64 I've built kernel and world with r230941. After installkernel, reboot, installworld, mergemaster, make remove-old, I reboot and get this panic at the very end: Recovering vi editor sessions:. /usr/local/etc/rc.d/svnserve: set_rcvar: not found Starting svnserve. su: unknown login: svn /etc/rc: WARNING: failed to start svnserve Updating motd:. Starting ntpd. /usr/local/etc/rc.d/rsyncd: set_rcvar: not found Starting rsyncd. /usr/local/etc/rc.d/gmond: set_rcvar: not found /etc/rc: WARNING: /usr/local/etc/rc.conf is not readable. /etc/rc: WARNING: failed precmd routine for rc /usr/local/etc/rc.d/bsdstats: set_rcvar: not found Starting bsdstats. fatal kernel trap (cpu 1): trap vector = 0x14 (Page Not Present) cr.iip = 0x9ffc008cb960 cr.ipsr = 0x1010080a6018 (ac,mfl,ic,i,dt,dfh,rt,cpl=0,it,ri=0,bn) cr.isr = 0x4 (code=0,vector=0,r,ei=0) cr.ifa = 0x168 curthread = 0xe00011a9f9e0 pid = 760, comm = dig [ thread pid 760 tid 100073 ] Stopped at cpu_set_upcall+0x190: [M0]ld8 r14=[r14] ;; db db show proc 760 Process 760 (dig) at 0xe00011a9a8e0: state: NORMAL uid: 0 gids: 0 parent: pid 759 at 0xe00011b64000 ABI: FreeBSD ELF64 arguments: dig threads: 1 100073 Run CPU 1 dig db db thread 100073 [ thread pid 760 tid 100073 ] cpu_set_upcall+0x190: [M0]ld8 r14=[r14] ;; db db bt Tracing pid 760 tid 100073 td 0xe00011a9f9e0 cpu_set_upcall(0xe00011a9e8a0, 0xe00011a9f9e0, 0xa000f87ab780, 0xa000f87ab550) at cpu_set_upcall+0x190 create_thread(0xe00011a9f9e0, 0x0, 0x1209a7090, 0x120c04800, 0x7f9fe000, 0x20, 0x12039c200, 0x120c04800) at create_thread+0x1c0 kern_thr_new(0xe00011a9f9e0, 0xa000f872b330, 0x9ffc00436360) at kern_thr_new+0x100 sys_thr_new(0xe00011a9f9e0, 0xa000f872b4e8, 0x9ffc008c6bf0, 0x48d) at sys_thr_new+0xa0 syscall(0xe00011a9a8e0, 0xa000f872b3a8, 0x120c0442c, 0xe00011a9f9e0, 0x0, 0x0, 0x9ffc008c2ec0, 0x8) at syscall+0x550 epc_syscall_return() at epc_syscall_return db Please advise -- 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: ia64 fatal kernel trap [WAS: panic]
On Mon, Feb 06, 2012 at 02:22:39PM +, Anton Shterenlikht wrote: On ia64 I've built kernel and world with r230941. After installkernel, reboot, installworld, mergemaster, make remove-old, I reboot and get this panic at the very end: Recovering vi editor sessions:. /usr/local/etc/rc.d/svnserve: set_rcvar: not found Starting svnserve. su: unknown login: svn /etc/rc: WARNING: failed to start svnserve Updating motd:. Starting ntpd. /usr/local/etc/rc.d/rsyncd: set_rcvar: not found Starting rsyncd. /usr/local/etc/rc.d/gmond: set_rcvar: not found /etc/rc: WARNING: /usr/local/etc/rc.conf is not readable. /etc/rc: WARNING: failed precmd routine for rc /usr/local/etc/rc.d/bsdstats: set_rcvar: not found Starting bsdstats. fatal kernel trap (cpu 1): trap vector = 0x14 (Page Not Present) cr.iip = 0x9ffc008cb960 cr.ipsr = 0x1010080a6018 (ac,mfl,ic,i,dt,dfh,rt,cpl=0,it,ri=0,bn) cr.isr = 0x4 (code=0,vector=0,r,ei=0) cr.ifa = 0x168 curthread = 0xe00011a9f9e0 pid = 760, comm = dig [ thread pid 760 tid 100073 ] Stopped at cpu_set_upcall+0x190: [M0]ld8 r14=[r14] ;; db db show proc 760 Process 760 (dig) at 0xe00011a9a8e0: state: NORMAL uid: 0 gids: 0 parent: pid 759 at 0xe00011b64000 ABI: FreeBSD ELF64 arguments: dig threads: 1 100073 Run CPU 1 dig db db thread 100073 [ thread pid 760 tid 100073 ] cpu_set_upcall+0x190: [M0]ld8 r14=[r14] ;; db db bt Tracing pid 760 tid 100073 td 0xe00011a9f9e0 cpu_set_upcall(0xe00011a9e8a0, 0xe00011a9f9e0, 0xa000f87ab780, 0xa000f87ab550) at cpu_set_upcall+0x190 create_thread(0xe00011a9f9e0, 0x0, 0x1209a7090, 0x120c04800, 0x7f9fe000, 0x20, 0x12039c200, 0x120c04800) at create_thread+0x1c0 kern_thr_new(0xe00011a9f9e0, 0xa000f872b330, 0x9ffc00436360) at kern_thr_new+0x100 sys_thr_new(0xe00011a9f9e0, 0xa000f872b4e8, 0x9ffc008c6bf0, 0x48d) at sys_thr_new+0xa0 syscall(0xe00011a9a8e0, 0xa000f872b3a8, 0x120c0442c, 0xe00011a9f9e0, 0x0, 0x0, 0x9ffc008c2ec0, 0x8) at syscall+0x550 epc_syscall_return() at epc_syscall_return db Please advise If I boot kernel.old, r224965, then the network doesn't work: mech-as28# ifconfig -a em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:13:21:5b:05:1c nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:13:21:5b:05:1d nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM nd6 options=21PERFORMNUD,AUTO_LINKLOCAL mech-as28# ifconfig em0 inet 137.222.187.28 ifconfig: ioctl (SIOCAIFADDR): Invalid argument mech-as28# How can recover from this? Thanks -- 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: ia64 fatal kernel trap [WAS: panic]
On Mon, Feb 06, 2012 at 02:44:44PM +, Anton Shterenlikht wrote: On Mon, Feb 06, 2012 at 02:22:39PM +, Anton Shterenlikht wrote: On ia64 I've built kernel and world with r230941. After installkernel, reboot, installworld, mergemaster, make remove-old, I reboot and get this panic at the very end: Recovering vi editor sessions:. /usr/local/etc/rc.d/svnserve: set_rcvar: not found Starting svnserve. su: unknown login: svn /etc/rc: WARNING: failed to start svnserve Updating motd:. Starting ntpd. /usr/local/etc/rc.d/rsyncd: set_rcvar: not found Starting rsyncd. /usr/local/etc/rc.d/gmond: set_rcvar: not found /etc/rc: WARNING: /usr/local/etc/rc.conf is not readable. /etc/rc: WARNING: failed precmd routine for rc /usr/local/etc/rc.d/bsdstats: set_rcvar: not found Starting bsdstats. It looks to me your mergemaster didn't go as planned. Quoting UPDATING: 20120114: The set_rcvar() function has been removed from /etc/rc.subr. All base and ports rc.d scripts have been updated, so if you have a port installed with a script in /usr/local/etc/rc.d you can either hand-edit the rcvar= line, or reinstall the port. An easy way to handle the mass-update of /etc/rc.d: rm /etc/rc.d/* mergemaster -i Maybe give this a shot. Glen pgpi4YnqFHpyT.pgp Description: PGP signature
SOLVED: Re: ia64 fatal kernel trap [WAS: panic]
On Mon, Feb 06, 2012 at 02:44:44PM +, Anton Shterenlikht wrote: On Mon, Feb 06, 2012 at 02:22:39PM +, Anton Shterenlikht wrote: On ia64 I've built kernel and world with r230941. After installkernel, reboot, installworld, mergemaster, make remove-old, I reboot and get this panic at the very end: Recovering vi editor sessions:. /usr/local/etc/rc.d/svnserve: set_rcvar: not found Starting svnserve. su: unknown login: svn /etc/rc: WARNING: failed to start svnserve Updating motd:. Starting ntpd. /usr/local/etc/rc.d/rsyncd: set_rcvar: not found Starting rsyncd. /usr/local/etc/rc.d/gmond: set_rcvar: not found /etc/rc: WARNING: /usr/local/etc/rc.conf is not readable. /etc/rc: WARNING: failed precmd routine for rc /usr/local/etc/rc.d/bsdstats: set_rcvar: not found Starting bsdstats. fatal kernel trap (cpu 1): trap vector = 0x14 (Page Not Present) cr.iip = 0x9ffc008cb960 cr.ipsr = 0x1010080a6018 (ac,mfl,ic,i,dt,dfh,rt,cpl=0,it,ri=0,bn) cr.isr = 0x4 (code=0,vector=0,r,ei=0) cr.ifa = 0x168 curthread = 0xe00011a9f9e0 pid = 760, comm = dig [ thread pid 760 tid 100073 ] Stopped at cpu_set_upcall+0x190: [M0]ld8 r14=[r14] ;; db db show proc 760 Process 760 (dig) at 0xe00011a9a8e0: state: NORMAL uid: 0 gids: 0 parent: pid 759 at 0xe00011b64000 ABI: FreeBSD ELF64 arguments: dig threads: 1 100073 Run CPU 1 dig db db thread 100073 [ thread pid 760 tid 100073 ] cpu_set_upcall+0x190: [M0]ld8 r14=[r14] ;; db db bt Tracing pid 760 tid 100073 td 0xe00011a9f9e0 cpu_set_upcall(0xe00011a9e8a0, 0xe00011a9f9e0, 0xa000f87ab780, 0xa000f87ab550) at cpu_set_upcall+0x190 create_thread(0xe00011a9f9e0, 0x0, 0x1209a7090, 0x120c04800, 0x7f9fe000, 0x20, 0x12039c200, 0x120c04800) at create_thread+0x1c0 kern_thr_new(0xe00011a9f9e0, 0xa000f872b330, 0x9ffc00436360) at kern_thr_new+0x100 sys_thr_new(0xe00011a9f9e0, 0xa000f872b4e8, 0x9ffc008c6bf0, 0x48d) at sys_thr_new+0xa0 syscall(0xe00011a9a8e0, 0xa000f872b3a8, 0x120c0442c, 0xe00011a9f9e0, 0x0, 0x0, 0x9ffc008c2ec0, 0x8) at syscall+0x550 epc_syscall_return() at epc_syscall_return db Please advise If I boot kernel.old, r224965, then the network doesn't work: mech-as28# ifconfig -a em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:13:21:5b:05:1c nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:13:21:5b:05:1d nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM nd6 options=21PERFORMNUD,AUTO_LINKLOCAL mech-as28# ifconfig em0 inet 137.222.187.28 ifconfig: ioctl (SIOCAIFADDR): Invalid argument mech-as28# How can recover from this? I removed bsdstats, this was enough to stop the panic. I can now boot r230941. -- 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: [CFT] Xorg Upgrade 7.5.2
A big thanks to all. [adamk@memory ~]$ cat /var/log/Xorg.0.log | head -n 10 [46.127] X.Org X Server 1.10.4 Release Date: 2011-08-19 [46.128] X Protocol Version 11, Revision 0 [46.128] Build Operating System: FreeBSD 9.0-STABLE amd64 [46.128] Current Operating System: FreeBSD memory.visualtech.com 9.0-STABLE FreeBSD 9.0-STABLE #5: Thu Jan 26 22:09:39 EST 2012 r...@memory.visualtech.com:/usr/obj/usr/src/sys/MEMORY amd64 [46.128] Build Date: 06 February 2012 09:37:45AM [46.128] [46.128] Current version of pixman: 0.24.0 [46.128]Before reporting problems, check http://wiki.x.org [adamk@memory ~]$ glxinfo | grep -i OpenGL IRQ's not enabled, falling back to busy waits: 2 0 OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: Mesa DRI R600 (RV710 954F) TCL OpenGL version string: 2.1 Mesa 7.11.2 OpenGL shading language version string: 1.20 OpenGL extensions: 3D compositing works with KDE's desktop effects. compiz works as well (though enabling the magnifier plugin crashes X). xmoto, foobillard, neverball and openarena are all (to varying degrees) playable. Adam ___ 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 9.0 release and dmesg
dmesg no longer outputs the kernel messages. $ dmesg $ $ which dmesg /sbin/dmesg $what /sbin/dmesg /sbin/dmesg: So, I have no idea what version of dmesg got installed. Anyone on 9.0 Release have this problem? How to fix it? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP][CFT] pkgng beta1 is out
On 2012-02-06 08:40, Matt Thyer wrote: On Feb 6, 2012 3:50 AM, Radio młodych bandytów radiomlodychbandy...@o2.pl mailto:radiomlodychbandy...@o2.pl wrote: I wonder if I'm the only one thinking about a decentralised package management First, a decentralised transport layer. Torrents are faster and more reliable than servers. Second, decentralised management when anybody can upload a port directly into the system. -- Twoje radio Such a system would need to support traditional protocols such as FTP HTTP due to many corporate environments not allowing anything else. I'm all for a distributed system but you can't forget the corporate users. True. While some corporations are moving to P2P software distribution already, it's a long way before it becomes standard. -- Twoje radio ___ 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: LSI supported mps(4) driver available
Sorry for the swarm of screenshots :) Spare drive should be a iDRAC Virtual usb. On that particular machine, as I said, two RAID arrays (1 and 10) http://oi39.tinypic.com/10hlfmg.jpg -- they initialized as they should. http://oi43.tinypic.com/2db83g8.jpg -- loader recognizes 3 disks (3rd one is the iDRAC usb as I suppose) So, I flashed the FW and installed the latest one from Dell (7.15.08.00 \ 7.03.05.00), and things have gone slightly better. http://oi39.tinypic.com/69dtuq.jpg -- controller . http://oi44.tinypic.com/10s6jxi.jpg -- still. http://oi42.tinypic.com/ipmh37.jpg -- It boots in single user, in multiuser it prints probe errors, skips them and hang on the daemon startup. http://oi43.tinypic.com/13yhz02.jpg -- in single user they initialized\UFSed\mounted just fine. To sum everything up, FW upgrade helped, still some device handle errors and SCSI errors, hangs in multiuser-mode(may or may not be related). Tested with the same FreeBSD10-CURRENT r230857, I saw ken@'s commit to -STABLE and will try it somewhere tomorrow. Thanks for your time:) On Fri, Feb 3, 2012 at 12:10 PM, Desai, Kashyap kashyap.de...@lsi.com wrote: From: Stas Orlov [mailto:senn...@gmail.com] Sent: Thursday, February 02, 2012 8:29 PM To: Desai, Kashyap Cc: Kenneth D. Merry; freebsd-s...@freebsd.org; freebsd-current@freebsd.org; Dennis Glatting Subject: Re: LSI supported mps(4) driver available (Again clarify which version of FreeBSD you are using) As I've stated earlier it's current snapshot from the other day, to be more specific FreeBSD10-CURRENT r230857 Ok, I'll try to upgrade firmware. On Thu, Feb 2, 2012 at 6:43 PM, Desai, Kashyap kashyap.de...@lsi.com wrote: Can you switch your mail client to default text mode reply. It is always turning into html format and difficult for inline reply. I have done some analysis on of your logs provided at http://oi40.tinypic.com/25gdw8o.jpg; 1. it seems Driver is somehow not handling error condition which should be better handled at driver. e.a driver does not reinit HBA if any config request time out. I will add this feature sometime later, since I have some more item queued up as well. 2. Your logs mentioned there are three different handled got from FW to add as Bare Drive. (it is not a volume entry) So just curious to know why those entries are coming as bare drive. ? (do you have any other bare drives in your topology ? ) ` Kashyap From: Stas Orlov [mailto:senn...@gmail.com] Sent: Thursday, February 02, 2012 7:45 PM To: Desai, Kashyap Cc: Kenneth D. Merry; freebsd-s...@freebsd.org; freebsd-current@freebsd.org; Dennis Glatting Subject: Re: LSI supported mps(4) driver available Sure, I've made two RAID (1 and 10 ) arrays within LSI Config Utility and tried to install fresh current, every time I get error linked above, so yes, it's reproducible. - What I understood here is, you have two raid volumes RAID1 and RAID10, and trying to install FreeBSD (Again clarify which version of FreeBSD you are using) Try erasing a controller FW completely and re-install everything from fresh. (Here make sure you flash completely. Hope you are aware of controller firmware upgrade process) Our board has DPM tables and for Raid volume it is maximum 2 entry. When you have more than two inactive volumes, we cannot add another raid volume. There is some implementation recently done by BIOS team related to this area. Where BIOS itself will erase inactive Raid volume entry from DPM pages. ~ Kashyap MPT Firmware 2.15.63.00-IR Package Version 7.01.33.00 I do have another spare R610 with that card, I'll test it with current later this evening. On Thu, Feb 2, 2012 at 5:53 PM, Desai, Kashyap kashyap.de...@lsi.com wrote: -Original Message- From: owner-freebsd-s...@freebsd.org [mailto:owner-freebsd- s...@freebsd.org] On Behalf Of Stas Orlov Sent: Thursday, February 02, 2012 6:48 PM To: Kenneth D. Merry Cc: freebsd-s...@freebsd.org; freebsd-current@freebsd.org; Dennis Glatting Subject: Re: LSI supported mps(4) driver available Hi, We have a pack of identical Dell R610 mahcines with H200 cards. pciconf from R610 with FreeBSD9 on ZFS, disks in JBOD mode. mps0@pci0:3:0:0: class=0x010700 card=0x1f1e1028 chip=0x00721000 rev=0x02 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon]' class = mass storage subclass = SAS bar [10] = type I/O Port, range 32, base 0xfc00, size 256, enabled bar [14] = type Memory, range 64, base 0xdf2b, size 65536, enabled bar [1c] = type Memory, range 64, base 0xdf2c, size 262144, enabled cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[68] = PCI-Express 2 endpoint max data 128(4096) link x4(x8) cap 03[d0] = VPD cap 05[a8] = MSI supports 1 message, 64 bit cap 11[c0] = MSI-X supports 15 messages
Re: Freebsd 9.0 release and dmesg
On Mon, 2012-02-06 at 09:24 -0800, JD wrote: dmesg no longer outputs the kernel messages. $ dmesg $ $ which dmesg /sbin/dmesg $what /sbin/dmesg /sbin/dmesg: So, I have no idea what version of dmesg got installed. Anyone on 9.0 Release have this problem? How to fix it? I would assume that something is writing a lot to the console? Is there any indication of this in /var/log/messages? 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: [ptrace] please review follow fork/exec changes
I see what is going on. The wait loop for P_PPWAIT in do_fork() simply
do not allow the ptracestop() in the syscall return path to be reached.
There seems to be more problems. In particular, I do not see anything
which would prevent the child from being reapped while the loop is
executing (assume that the parent is multithreaded and other thread
processed SIGCHLD and called wait).
Lets deal with these bugs after your proposal for interface changes is
dealt with.
OK.
Yes, I agree with the proposal to add flag to the child lwp info.
I think it will be easier if the flag is different from PL_FLAG_FORKED.
I named it PL_FLAG_CHILD.
PT_FOLLOW_EXEC is easy to implement, but my question is, how can debugger
operate (correctly) if it ignores exec events ? After exec, the whole
cached state of the debuggee must be invalidated, and since debugger
ignores the notification when the invalidation shall be done, it probably
gets very confused.
You're right, the debugger needs to handle exec() events implicitly when it
starts up executables. The problem is that there is OS-independent machinery in
gdb which handles statup fork-exec sequence differently from when the debuggee
itself does an exec(). Basically in the event handling code I need to be able
to distinguish app startup by gdb from an exec done by the app. Other OS-es
have flags like PL_FLAG_EXEC set on demand: they have an equivalent of
PT_FOLLOW_EXEC. I attached a modified patch that solves the problem. It tries
to separate the always-on TDB_EXEC from the on-demand TDB_FOLLOWEXEC without
changing existing functionality. Let me know if it's acceptable.
Another issue I'm investigating is that after the switch-over to the child gdb
gets a SIGHUP when it continues the child. I think it has to do with the
re-parenting/orphan business. I'll let you know what I find, but if you have an
idea what might be causing it, please let me know.
Thanks.
Dmitry.
Index: kern/kern_exec.c
===
--- kern/kern_exec.c (revision 231088)
+++ kern/kern_exec.c (working copy)
@@ -890,6 +890,8 @@ exec_fail_dealloc:
if (error == 0) {
PROC_LOCK(p);
td-td_dbgflags |= TDB_EXEC;
+ if (p-p_flag P_FOLLOWEXEC)
+ td-td_dbgflags |= TDB_FOLLOWEXEC;
PROC_UNLOCK(p);
/*
Index: kern/kern_fork.c
===
--- kern/kern_fork.c (revision 231088)
+++ kern/kern_fork.c (working copy)
@@ -1035,7 +1035,9 @@ fork_return(struct thread *td, struct trapframe *f
p-p_oppid = p-p_pptr-p_pid;
proc_reparent(p, dbg);
sx_xunlock(proctree_lock);
+ td-td_dbgflags |= TDB_CHILD;
ptracestop(td, SIGSTOP);
+ td-td_dbgflags = ~TDB_CHILD;
} else {
/*
* ... otherwise clear the request.
Index: kern/sys_process.c
===
--- kern/sys_process.c (revision 231088)
+++ kern/sys_process.c (working copy)
@@ -660,6 +660,7 @@ kern_ptrace(struct thread *td, int req, pid_t pid,
case PT_TO_SCX:
case PT_SYSCALL:
case PT_FOLLOW_FORK:
+ case PT_FOLLOW_EXEC:
case PT_DETACH:
sx_xlock(proctree_lock);
proctree_locked = 1;
@@ -873,6 +874,12 @@ kern_ptrace(struct thread *td, int req, pid_t pid,
else
p-p_flag = ~P_FOLLOWFORK;
break;
+ case PT_FOLLOW_EXEC:
+ if (data)
+ p-p_flag = ~P_FOLLOWEXEC;
+ else
+ p-p_flag |= P_FOLLOWEXEC;
+ break;
case PT_STEP:
case PT_CONTINUE:
@@ -936,7 +943,8 @@ kern_ptrace(struct thread *td, int req, pid_t pid,
p-p_sigparent = SIGCHLD;
}
p-p_oppid = 0;
- p-p_flag = ~(P_TRACED | P_WAITED | P_FOLLOWFORK);
+ p-p_flag = ~(P_TRACED | P_WAITED | P_FOLLOWFORK |
+ P_FOLLOWEXEC);
/* should we send SIGCHLD? */
/* childproc_continued(p); */
@@ -1141,10 +1149,14 @@ kern_ptrace(struct thread *td, int req, pid_t pid,
pl-pl_flags |= PL_FLAG_SCX;
if (td2-td_dbgflags TDB_EXEC)
pl-pl_flags |= PL_FLAG_EXEC;
+ if (td2-td_dbgflags TDB_FOLLOWEXEC)
+ pl-pl_flags |= PL_FLAG_FOLLOWEXEC;
if (td2-td_dbgflags TDB_FORK) {
pl-pl_flags |= PL_FLAG_FORKED;
pl-pl_child_pid = td2-td_dbg_forked;
}
+ if (td2-td_dbgflags TDB_CHILD)
+ pl-pl_flags |= PL_FLAG_CHILD;
pl-pl_sigmask = td2-td_sigmask;
pl-pl_siglist = td2-td_siglist;
strcpy(pl-pl_tdname, td2-td_name);
Index: kern/subr_syscall.c
===
--- kern/subr_syscall.c (revision 230847)
+++ kern/subr_syscall.c (working copy)
@@ -216,7 +216,8 @@ syscallret(struct thread *td, int error, struct sy
((td-td_dbgflags (TDB_FORK | TDB_EXEC)) != 0 ||
(p-p_stops S_PT_SCX) != 0))
ptracestop(td, SIGTRAP);
- td-td_dbgflags = ~(TDB_SCX | TDB_EXEC | TDB_FORK);
+ td-td_dbgflags =
+ ~(TDB_SCX | TDB_EXEC | TDB_FOLLOWEXEC | TDB_FORK);
PROC_UNLOCK(p);
}
}
Index: sys/proc.h
===
--- sys/proc.h (revision 231088)
+++
Re: Freebsd 9.0 release and dmesg
Am 06.02.2012 18:24, schrieb JD: dmesg no longer outputs the kernel messages. $ dmesg $ $ which dmesg /sbin/dmesg $what /sbin/dmesg /sbin/dmesg: So, I have no idea what version of dmesg got installed. Anyone on 9.0 Release have this problem? How to fix it? What does dmesg -a print? Regards, STefan ___ 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: [ptrace] please review follow fork/exec changes
Oops, this should be the part of the patch that sets the flag: @@ -873,6 +872,12 @@ kern_ptrace(struct thread *td, int req, pid_t pid, else p-p_flag = ~P_FOLLOWFORK; break; +case PT_FOLLOW_EXEC: +if (data) +p-p_flag |= P_FOLLOWEXEC; +else +p-p_flag = ~P_FOLLOWEXEC; +break; The SIGHUP I mentioned is due to the fact that the parent exits immediately. I guess that's not a particularly well written program. On 02/06/2012 01:19 PM, Dmitry Mikulin wrote: I see what is going on. The wait loop for P_PPWAIT in do_fork() simply do not allow the ptracestop() in the syscall return path to be reached. There seems to be more problems. In particular, I do not see anything which would prevent the child from being reapped while the loop is executing (assume that the parent is multithreaded and other thread processed SIGCHLD and called wait). Lets deal with these bugs after your proposal for interface changes is dealt with. OK. Yes, I agree with the proposal to add flag to the child lwp info. I think it will be easier if the flag is different from PL_FLAG_FORKED. I named it PL_FLAG_CHILD. PT_FOLLOW_EXEC is easy to implement, but my question is, how can debugger operate (correctly) if it ignores exec events ? After exec, the whole cached state of the debuggee must be invalidated, and since debugger ignores the notification when the invalidation shall be done, it probably gets very confused. You're right, the debugger needs to handle exec() events implicitly when it starts up executables. The problem is that there is OS-independent machinery in gdb which handles statup fork-exec sequence differently from when the debuggee itself does an exec(). Basically in the event handling code I need to be able to distinguish app startup by gdb from an exec done by the app. Other OS-es have flags like PL_FLAG_EXEC set on demand: they have an equivalent of PT_FOLLOW_EXEC. I attached a modified patch that solves the problem. It tries to separate the always-on TDB_EXEC from the on-demand TDB_FOLLOWEXEC without changing existing functionality. Let me know if it's acceptable. Another issue I'm investigating is that after the switch-over to the child gdb gets a SIGHUP when it continues the child. I think it has to do with the re-parenting/orphan business. I'll let you know what I find, but if you have an idea what might be causing it, please let me know. Thanks. Dmitry. ___ 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: [ptrace] please review follow fork/exec changes
On 2012/1/26 7:48, Dmitry Mikulin wrote: snip The debugger needs to intercept fork() in both parent and child so it can detach from the old process and attach to the new one. Maybe it'll make more sense in the context of gdb changes. Should I send them too? Don't think Marcel included that patch... Does the orphan list change intended to not lost the child after fork ? But the child shall be traced, so debugger would get the SIGTRAP on the attach on fork returning to usermode. I remember that I explicitely tested this when adding followfork changes. Yes, the debugger gets SIGTRAPs. The problem arises when the real parent of the forked process has the code to collect termination status. Since attaching to a process changes the parent/child relationships, we need to keep track of the children lost due to re-parenting so we can properly attribute their exit status to the real parent. I recall that someone brought a topic in the list said that this should be fixed, debugging a process should not change parent-child relation, instead a new link list data structure should be added to struct proc to trace debugged process, this will make code clean with a small memory overhead. Regards, David Xu ___ 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
