CURRENT: Issue with ZFS and 2TB WD HDD (WDC WD20EURS-63Z9B1 80.00A80)
I'm running a newly setup FreeBSD 9.0-CURRENT/amd64 SMP box. The former OS was FreeBSD 8.1-PRE/amd64. Attached to the system are three WD harddrives with ZFS as filesystem on GPT partitioning scheme. Two 1TB HDD are spanning a volume with 2 TB capacity which is quite fast due to parallel access through ZFS. The underlying layout is, as mentioned, GPT, bot devices are named /dev/ada1p1 and /dev/ada2p1. The thir drive is a WD Caviar Green 2TB HDD acting as a compressed ZFS backup media, also based on a GPT partitioning scheme and known as device /dev/ada3p1. In FreeBSD 8.2-PRE/amd64 I can use the JBOD volume resembled from two 1TB HDD without problems, mounting is all right, dismounting, also with the 2TB HDD, labeld as BACKUP00 volume in ZFS. Doing a "zpool export" on both ZFS volumes works fine in FBSD 8, importing is also no problem. The system's log does not show any kind of irregularities, errors or something else indicating soemthing weird with one of the three devices. Exporting both volumes in FreeBSD 8 works. But importing them in FreeBSD 9.0-CURRENT/amd64 as with the most recent make world of today fails on the 2TB HDD (ZFS pool/volume BACKUP00). Issuing "zpool import BACKUP00" results in cannot import 'BACKUP': no such pool available and on console I receive message ZFS WARNING: Unable to attach to ada1 But the drive is and was ada3! Looking with zpool status, I get the follwoing picture: pool: BACKUP00 state: FAULTED status: One or more devices could not be used because the label is missing or invalid. There are insufficient replicas for the pool to continue functioning. action: Destroy and re-create the pool from a backup source. see: http://www.sun.com/msg/ZFS-8000-5E scrub: none requested config: NAMESTATE READ WRITE CKSUM BACKUP00FAULTED 0 0 0 corrupted data ada3 UNAVAIL 0 0 0 corrupted data pool: THOR00 state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM THOR00 ONLINE 0 0 0 ada1p1ONLINE 0 0 0 ada2p1ONLINE 0 0 0 errors: No known data errors This picture differs from what I see i FreeBSD 8.2-PRE/amd issuing the same command! I did a full "zpool scrub" on both pools - no effect. Surprisingly, the GPT partition of the pool BACKUP00 isn't shown in FreeBSD 9, while I see ada3p1 in FreeBSD 8.2. gpart show ada3 lists this: =>34 3907029101 ada3 GPT (1.8T) 344062- free - (2.0M) 4096 3907025039 1 freebsd-zfs (1.8T) The drive in question is a WesternDigital Caviar Green WD (WD20EURS-63Z9B1 80.00A80> at scbus7 target 0 lun 0 (pass3,ada3)). Can someone explain what#s going on? The drive in question is one of the new 4k sized physical block devices. Why is FreeBSD 8 dealing with the HDD, FreeBSD 9 not? Any help at this point? Hope the volume is not lost. Thanks in advance, Oliver ___ 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: two issues with cdfs
On Sun Nov 28 10, Tim Kientzle wrote: > On Nov 28, 2010, at 8:58 AM, Alexander Best wrote: > >>> On Fri Nov 26 10, Andriy Gapon wrote: > on 26/11/2010 00:25 Alexander Best said the following: > > > 1) take a > 4 GB example.file > > Likely we don't support multi-extent files at the moment. > >>> > > i found a way to access the data on such disks. i simply copied the whole > > iso > > to my hdd using dd and then threw tar at it. since tar understands cdfs and > > also seems to support multi-extent i got the whole file. :) > > I believe this works without actually copying the image: > >tar xvf /dev/cd0 ahh thanks. you're right. that's even more convenient. :) > > Cheers, > > Tim -- a13x ___ 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: 40 vs 44 bit memory addressing HP DL580/980
On Monday, November 22, 2010 8:01:34 pm Alan Cox wrote: > On 11/22/2010 1:47 PM, John Baldwin wrote: > > On Monday, November 22, 2010 1:37:45 pm Alan Cox wrote: > >> On Mon, Nov 22, 2010 at 6:59 AM, John Baldwin wrote: > >> > >>> On Sunday, November 21, 2010 8:05:26 pm Sean Bruno wrote: > Looks like these HP boxes have the capability to do 44 bit memory > addressing if configured to do so from the BIOS. > > Is anyone interested in any data from that setting? > >>> Does it boot ok? :) The MTRR code should handle that (there is a CPUID > >>> field that tells the OS how many bits are significant). Not sure if there > >>> are any places in the pmap that assume 40 bits, but a test boot is > >>> certainly > >>> worth trying. > >>> > >>> > >> Since we don't boot with 40-bit addressing, I can easily predict the > >> outcome. :-) > >> > >> The trouble with this machine is that the second 128GB of RAM is being > >> placed between 512G and 1T in the physical address space, which is beyond > >> the range of the (current) direct map. So, we take a page fault on the > >> first access to a page in the second 128GB through the direct map. > > Heh, I guess that is what your earlier patch did? Once that patch is > > applied > > I think Sean should just try 44-bit mode if so. > > > > Yes. > > If 44-bit addressing makes the placement of DRAM in the physical address > space any sparser, then we'll again have an insufficiently large direct > map. Also, I fear that we won't be able to allocate the vm_page_array > without enabling VM_PHYSSEG_SPARSE, which itself requires a change in > order to work. I believe someone has a change for that on amd64 already? -- 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: Regarding pciids
On Tuesday, November 23, 2010 6:20:03 pm Alexander Best wrote: > On Tue Nov 23 10, Andriy Gapon wrote: > > on 18/10/2010 18:28 Alexander Best said the following: > > > On Mon Oct 18 10, Alexander Best wrote: > > >> On Fri Sep 17 10, Alex Dupre wrote: > > >>> I created hackish scripts to generate pci_vendors file from Boemler and > > >>> Mares (pciids.sf.net) lists. I haven't found the Hart list. > > >>> > > >>> The results of the scripts are here: > > >> > > >> sorry it seems i missed your post back then. > > >> > > >> i found two more lists: > > >> > > >> http://rh-software.com/downloads/pcidevs.txt > > >> and > > >> http://hobbes.nmsu.edu/h-browse.php?dir=/pub/incoming (seems to be based > > >> on the > > >> Hart list) > > >> > > >> the actual Hart list seems to have vanished and the web location is no > > >> longer > > >> accessible. > > >> > > >> personally i don't think it's necessary to combine the data of two > > >> files. the > > >> mares database seems extremely elaborate. all my pci devices get > > >> described > > >> properly. also making use of only one databse would make it more easy to > > >> submit > > >> additional info back to the vendor. > > >> > > >> so any objections to switching to the mares list? > > >>> > > >>> http://www.alexdupre.com/pci_vendors/mares.txt > > >>> http://www.alexdupre.com/pci_vendors/boemler.txt > > >>> http://www.alexdupre.com/pci_vendors/mares-boemler.txt > > >>> http://www.alexdupre.com/pci_vendors/boemler-mares.txt > > >>> > > >>> The first two are generated from single lists, the last two are > > >>> combined, with different preference order. > > > > > > oh...and i think it would be a good idea to move from ";" as comment > > > character > > > to "#". that way we wouldn't need to run a script, but could include the > > > vendor > > > file directly into the src tree. > > > > So, guys, perhaps I missed the patch(es) - I think that I am interested in > > reviewing them and getting them committed. > > > > Many thanks! > > iirc the problem is that some entries in the current pciid list are not > present > in the mares list. this leaves two options: > > 1) take the mares list and add the missing entries from the current pciid >version or > 2) try to get all entries from the current pciid committed upstream to the >mares list and once that's been done do a complete import of the mares > list, >replacing the current pciid file entirely. I think go for 1) for now. Has anyone asked the mares folks about 2)? -- 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: msk0 interface stops working when downloading
On Tuesday, November 23, 2010 6:25:06 pm Andrew Moran wrote: > > Hey guys, > > After banging my head against this for a few hours, I've decided to ask for help. I installed FreeBSD 8.1 amd64 on a Shuttle J1 4100 system (tech specs here http://us.shuttle.com/J1_4100.aspx). I installed from DVD and the install went fine. > > I notice when I pkg_add -r anything, the network stops responding. > > Some details: > > 1) I can reproduce it 100% by downloading a large file. low traffic like the SSH connection does not trigger it. I think it's being triggered by traffic above a certain rate. > 2) I can recover by restarting the network interfaces (/etc/rc.d/netif stop; /etc/rc.d/netif start) > 3) I see no errors in dmesg or /var/log/messages. Nothing at all. > 4) I've tried the following in /etc/sysctl.conf: > net.inet.tcp.tso=0 > net.inet.tcp.inflight.enable=0 > > and in /boot/loader.conf: > hw.pci.enable_msix="0" > hw.pci.enable_msi="0" > hw.bce.tso_enable="0" > > But the problem persists. > > The interface is identified as: > > mskc0: port 0xe800-0xe8ff mem 0xfebfc000-0xfebf irq 17 at device 0.0 on pci2 > msk0: on mskc0 > msk0: Ethernet address: 80:ee:73:01:60:7d > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > mskc0: [ITHREAD] When I've seen this on my netbook I did a tcpdump on another machien on the same hub and found that my msk0 device was spewing an endless stream of pause frames. I've only had this problem with a gigE switch, it works fine for me on a 10/100 switch. -- 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: panic: sched_priority: invalid priority 2906: nice 0, ticks 122865664 ftick 516947 ltick 517947 tick pri 2726
On Friday, November 26, 2010 4:38:49 pm David Rhodus wrote: > I hit this panic on my NFS server. > > -DR > > coke.fun dumped core - see /var/crash/vmcore.2 > > Fri Nov 26 14:50:48 UTC 2010 > > FreeBSD coke.fun 9.0-CURRENT FreeBSD 9.0-CURRENT #14 r215800: Wed Nov > 24 12:35:30 UTC 2010 r...@coke.fun:/usr/obj/usr/src/sys/GENERIC > i386 > > panic: sched_priority: invalid priority 2906: nice 0, ticks 122865664 > ftick 516947 ltick 517947 tick pri 2726 I ran the numbers and assuming a hz of 1000, this requires you to have a very large value for ts_ticks (about (2726 * 24) << 10). I suspect this is due to sched_tick() being invoked for a long idle sleep combined with the eventtimer changes. Can you go to frame 10 and 'p td->td_sched->ts_ticks'? -- 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: Should green_saver.ko shut off a laptop's backlight?
On Saturday, November 27, 2010 11:30:56 pm Adam Vande More wrote: > On Sat, Nov 27, 2010 at 6:39 PM, Doug Barton wrote: > > > My recollection is that green_saver should turn off an LCD backlight, but I > > just loaded it up on my laptop and it's not doing so. It does remove the > > text from the screen, but the backlight is still on (i.e., it is doing > > exactly what blank_saver does). > > > > When running X DPMS works on that same laptop, so I know the hardware is > > capable. This is 9-current amd64 at r214025. Any suggestions are welcome. > > > > It's never worked for me either and this has been around awhile. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=114928&cat= green_saver just ask's your video card's BIOS to shut the screen off. If the BIOS doesn't turn off the backlight, that is the BIOS's problem, not something we can fix. -- 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: Broken make distribution on amd64?
On Fri, Nov 26, 2010 at 05:22:06PM +0200, Kostik Belousov wrote: > On Fri, Nov 26, 2010 at 09:59:09AM -0500, Kris Moore wrote: > > > > For about 2 weeks now I've been seeing failures when trying to spin ISOs > > of CURRENT (amd64) and using "make distribution" specifically: > > > > > > pwd_mkdb -L -i -p -d /usr/pcbsd-build90/buildworld/etc > > /usr/pcbsd-build90/buildworld/etc/master.passwd > > *** Signal 6 > > > > Stop in /usr/pcbsd-build90/fbsd-source/9.0/etc. > > *** Error code 1 > > > > - > > > > It looks like the pwd_mkdb command is core dumping every time: > > > > pwd_mkdb -L -i -p -d /usr/pcbsd-build90/buildworld/etc > > /usr/pcbsd-build90/buildworld/etc/master.passwd > > Abort (core dumped) > > > > Whats odd is that with the same source tree, I'm spinning ISOs of i386 no > > problem. I've tried rebuilding the world / pwd_mkdb command with the latest > > source a few times, and no luck so far. > > > > Is anybody else seeing this on amd64? Here's the core file: > > > > http://www.pcbsd.org/~kris/pwd_mkdb.core.gz > The core file is only useful for somebody who has a binary and full set > of dsos that were loaded into the image. > > I think you should start with build containing debug symbols and show > us the full backtrace from gdb. Ok, I was able to figure this out the cause of the crash. I had a number of entries in /etc/shells from some odd port builds I had been doing. When I cleaned this up, the core dump went away. I haven't had a chance to look much farther than this, but somewhere in there it doesn't like /etc/shells with lots of entries :) If somebody wants to look into this great, otherwise sorry about the noise. -- Kris Moore PC-BSD Software ___ 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: Broken make distribution on amd64?
On Mon, Nov 29, 2010 at 8:05 AM, Kris Moore wrote: > On Fri, Nov 26, 2010 at 05:22:06PM +0200, Kostik Belousov wrote: >> On Fri, Nov 26, 2010 at 09:59:09AM -0500, Kris Moore wrote: >> > >> > For about 2 weeks now I've been seeing failures when trying to spin ISOs >> > of CURRENT (amd64) and using "make distribution" specifically: >> > >> > >> > pwd_mkdb -L -i -p -d /usr/pcbsd-build90/buildworld/etc >> > /usr/pcbsd-build90/buildworld/etc/master.passwd >> > *** Signal 6 >> > >> > Stop in /usr/pcbsd-build90/fbsd-source/9.0/etc. >> > *** Error code 1 >> > >> > - >> > >> > It looks like the pwd_mkdb command is core dumping every time: >> > >> > pwd_mkdb -L -i -p -d /usr/pcbsd-build90/buildworld/etc >> > /usr/pcbsd-build90/buildworld/etc/master.passwd >> > Abort (core dumped) >> > >> > Whats odd is that with the same source tree, I'm spinning ISOs of i386 no >> > problem. I've tried rebuilding the world / pwd_mkdb command with the latest >> > source a few times, and no luck so far. >> > >> > Is anybody else seeing this on amd64? Here's the core file: >> > >> > http://www.pcbsd.org/~kris/pwd_mkdb.core.gz >> The core file is only useful for somebody who has a binary and full set >> of dsos that were loaded into the image. >> >> I think you should start with build containing debug symbols and show >> us the full backtrace from gdb. > > Ok, I was able to figure this out the cause of the crash. I had a number of > entries in /etc/shells > from some odd port builds I had been doing. When I cleaned this up, the core > dump went away. > > I haven't had a chance to look much farther than this, but somewhere in there > it doesn't like > /etc/shells with lots of entries :) If somebody wants to look into this > great, otherwise sorry > about the noise. Just for future reference, what were your build machine's src.conf WITHOUT_* knobs? 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: Broken make distribution on amd64?
On Mon, Nov 29, 2010 at 08:22:37AM -0800, Garrett Cooper wrote: > On Mon, Nov 29, 2010 at 8:05 AM, Kris Moore wrote: > > On Fri, Nov 26, 2010 at 05:22:06PM +0200, Kostik Belousov wrote: > >> On Fri, Nov 26, 2010 at 09:59:09AM -0500, Kris Moore wrote: > >> > > >> > For about 2 weeks now I've been seeing failures when trying to spin ISOs > >> > of CURRENT (amd64) and using "make distribution" specifically: > >> > > >> > > >> > pwd_mkdb -L -i -p -d /usr/pcbsd-build90/buildworld/etc > >> > ?/usr/pcbsd-build90/buildworld/etc/master.passwd > >> > *** Signal 6 > >> > > >> > Stop in /usr/pcbsd-build90/fbsd-source/9.0/etc. > >> > *** Error code 1 > >> > > >> > - > >> > > >> > It looks like the pwd_mkdb command is core dumping every time: > >> > > >> > pwd_mkdb -L -i -p -d /usr/pcbsd-build90/buildworld/etc > >> > /usr/pcbsd-build90/buildworld/etc/master.passwd > >> > Abort (core dumped) > >> > > >> > Whats odd is that with the same source tree, I'm spinning ISOs of i386 no > >> > problem. I've tried rebuilding the world / pwd_mkdb command with the > >> > latest > >> > source a few times, and no luck so far. > >> > > >> > Is anybody else seeing this on amd64? Here's the core file: > >> > > >> > http://www.pcbsd.org/~kris/pwd_mkdb.core.gz > >> The core file is only useful for somebody who has a binary and full set > >> of dsos that were loaded into the image. > >> > >> I think you should start with build containing debug symbols and show > >> us the full backtrace from gdb. > > > > Ok, I was able to figure this out the cause of the crash. I had a number of > > entries in /etc/shells > > from some odd port builds I had been doing. When I cleaned this up, the > > core dump went away. > > > > I haven't had a chance to look much farther than this, but somewhere in > > there it doesn't like > > /etc/shells with lots of entries :) If somebody wants to look into this > > great, otherwise sorry > > about the noise. > > Just for future reference, what were your build machine's src.conf > WITHOUT_* knobs? > Thanks, > -Garrett On this system src.conf is empty, so should just be defaults. -- Kris Moore PC-BSD Software ___ 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: 40 vs 44 bit memory addressing HP DL580/980
John Baldwin wrote: On Monday, November 22, 2010 8:01:34 pm Alan Cox wrote: On 11/22/2010 1:47 PM, John Baldwin wrote: On Monday, November 22, 2010 1:37:45 pm Alan Cox wrote: On Mon, Nov 22, 2010 at 6:59 AM, John Baldwin wrote: On Sunday, November 21, 2010 8:05:26 pm Sean Bruno wrote: Looks like these HP boxes have the capability to do 44 bit memory addressing if configured to do so from the BIOS. Is anyone interested in any data from that setting? Does it boot ok? :) The MTRR code should handle that (there is a CPUID field that tells the OS how many bits are significant). Not sure if there are any places in the pmap that assume 40 bits, but a test boot is certainly worth trying. Since we don't boot with 40-bit addressing, I can easily predict the outcome. :-) The trouble with this machine is that the second 128GB of RAM is being placed between 512G and 1T in the physical address space, which is beyond the range of the (current) direct map. So, we take a page fault on the first access to a page in the second 128GB through the direct map. Heh, I guess that is what your earlier patch did? Once that patch is applied I think Sean should just try 44-bit mode if so. Yes. If 44-bit addressing makes the placement of DRAM in the physical address space any sparser, then we'll again have an insufficiently large direct map. Also, I fear that we won't be able to allocate the vm_page_array without enabling VM_PHYSSEG_SPARSE, which itself requires a change in order to work. I believe someone has a change for that on amd64 already? Yes. Alan ___ 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: CURRENT: Issue with ZFS and 2TB WD HDD (WDC WD20EURS-63Z9B1 80.00A80)
"O. Hartmann" writes: > I'm running a newly setup FreeBSD 9.0-CURRENT/amd64 SMP box. The former > OS was FreeBSD 8.1-PRE/amd64. Attached to the system are three WD > harddrives with ZFS as filesystem on GPT partitioning scheme. Two 1TB > HDD are spanning a volume with 2 TB capacity which is quite fast due to > parallel access through ZFS. The underlying layout is, as mentioned, > GPT, bot devices are named /dev/ada1p1 and /dev/ada2p1. The thir drive > is a WD Caviar Green 2TB HDD acting as a compressed ZFS backup media, > also based on a GPT partitioning scheme and known as device /dev/ada3p1. > In FreeBSD 8.2-PRE/amd64 I can use the JBOD volume resembled from two > 1TB HDD without problems, mounting is all right, dismounting, also with > the 2TB HDD, labeld as BACKUP00 volume in ZFS. Doing a "zpool export" on > both ZFS volumes works fine in FBSD 8, importing is also no problem. The > system's log does not show any kind of irregularities, errors or > something else indicating soemthing weird with one of the three devices. > > Exporting both volumes in FreeBSD 8 works. But importing them in FreeBSD > 9.0-CURRENT/amd64 as with the most recent make world of today fails on > the 2TB HDD (ZFS pool/volume BACKUP00). Issuing "zpool import BACKUP00" > results in > > cannot import 'BACKUP': no such pool available > > and on console I receive message > > ZFS WARNING: Unable to attach to ada1 > > But the drive is and was ada3! > > Looking with zpool status, I get the follwoing picture: > > pool: BACKUP00 > state: FAULTED > status: One or more devices could not be used because the label is missing > or invalid. There are insufficient replicas for the pool to > continue > functioning. > action: Destroy and re-create the pool from a backup source. >see: http://www.sun.com/msg/ZFS-8000-5E > scrub: none requested > config: > > NAMESTATE READ WRITE CKSUM > BACKUP00FAULTED 0 0 0 corrupted data > ada3 UNAVAIL 0 0 0 corrupted data > > pool: THOR00 > state: ONLINE > scrub: none requested > config: > > NAMESTATE READ WRITE CKSUM > THOR00 ONLINE 0 0 0 > ada1p1ONLINE 0 0 0 > ada2p1ONLINE 0 0 0 > > errors: No known data errors > > > This picture differs from what I see i FreeBSD 8.2-PRE/amd issuing the > same command! > > I did a full "zpool scrub" on both pools - no effect. > > Surprisingly, the GPT partition of the pool BACKUP00 isn't shown in > FreeBSD 9, while I see ada3p1 in FreeBSD 8.2. > gpart show ada3 lists this: > > =>34 3907029101 ada3 GPT (1.8T) > 344062- free - (2.0M) > 4096 3907025039 1 freebsd-zfs (1.8T) > > The drive in question is a WesternDigital Caviar Green WD ( WD20EURS-63Z9B1 80.00A80> at scbus7 target 0 lun 0 (pass3,ada3)). > > Can someone explain what#s going on? The drive in question is one of the > new 4k sized physical block devices. Why is FreeBSD 8 dealing with the > HDD, FreeBSD 9 not? Any help at this point? Hope the volume is not lost. > > Thanks in advance, > > Oliver > Hi Oliver, just a wild guess and maybe completely wrong: are the ZFS version numbers and zpool version numbers the same across 8.1 and 9-CURRENT ? Best Regards, Leonidas ___ 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"
Extracting tgz file: Attempt to write to an empty file
Hi. I see these errors when tar (not limited to but including the version from FreeBSD -current) extracts directories from archive compressed with gtar. file reports: gzip compressed data, from Unix, last modified: Tue Nov 23 04:31:22 2010, max speed bsdtar taken from Google Code trunk extracts *without* such errors. Given above I suspect it was fixed in Google Code tree. If such then it would be nice to have it merged in FreeBSD. bsdtar version in FreeBSD: bsdtar 2.8.3 - libarchive 2.7.901a bsdtar version from Google Code trunk: bsdtar 3.0.0a - libarchive 3.0.0a Seen errors: # bsdtar -xf ~/arch.tgz ./: Attempt to write to an empty file ./.cpan/: Attempt to write to an empty file ./.cpan/CPAN/: Attempt to write to an empty file ./.cpan/build/: Attempt to write to an empty file ./.cpan/build/tmp/: Attempt to write to an empty file ./.cpan/sources/: Attempt to write to an empty file ./.cpan/sources/authors/: Attempt to write to an empty file ./.cpan/sources/authors/id/: Attempt to write to an empty file ./.cpan/sources/authors/id/D/: Attempt to write to an empty file ./.cpan/sources/authors/id/D/DA/: Attempt to write to an empty file ./.cpan/sources/authors/id/D/DA/DANKOGAI/: Attempt to write to an empty file [...] -- wbr, pluknet ___ 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: sched_priority: invalid priority 2906: nice 0, ticks 122865664 ftick 516947 ltick 517947 tick pri 2726
On 29.11.2010 17:07, John Baldwin wrote: On Friday, November 26, 2010 4:38:49 pm David Rhodus wrote: I hit this panic on my NFS server. -DR coke.fun dumped core - see /var/crash/vmcore.2 Fri Nov 26 14:50:48 UTC 2010 FreeBSD coke.fun 9.0-CURRENT FreeBSD 9.0-CURRENT #14 r215800: Wed Nov 24 12:35:30 UTC 2010 r...@coke.fun:/usr/obj/usr/src/sys/GENERIC i386 panic: sched_priority: invalid priority 2906: nice 0, ticks 122865664 ftick 516947 ltick 517947 tick pri 2726 I ran the numbers and assuming a hz of 1000, this requires you to have a very large value for ts_ticks (about (2726 * 24)<< 10). I suspect this is due to sched_tick() being invoked for a long idle sleep combined with the eventtimer changes. Can you go to frame 10 and 'p td->td_sched->ts_ticks'? As I can see, this is VirtualBox virtual machine. So it is still a question what side makes so large hole in sched_tick() on some CPUs. It could be interesting to get ktr(4) dump with KTR_SPARE2 mask: options KTR options ALQ options KTR_ALQ options KTR_ENTRIES=131072 options KTR_COMPILE=(KTR_SPARE2) options KTR_MASK=(KTR_SPARE2) -- 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"
kern_sysctl.c compilation failure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Seems that 'treat warnings as errors' snags on this .. patch attached,
imb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAkz0B/YACgkQQv9rrgRC1JKLBgCeNhKn2W6Z2XFN/zt70PbFhKbP
eHcAoIwI0Iz0g5TmU/pjbnG8zlcY6a1y
=a/KQ
-END PGP SIGNATURE-
*** src/sys/kern/kern_sysctl.c~ Mon Nov 29 14:02:22 2010
--- src/sys/kern/kern_sysctl.c Mon Nov 29 14:32:56 2010
***
*** 845,851
sysctl_sysctl_name2oid(SYSCTL_HANDLER_ARGS)
{
char *p;
! int error, oid[CTL_MAXNAME], len;
struct sysctl_oid *op = 0;
if (!req->newlen)
--- 845,851
sysctl_sysctl_name2oid(SYSCTL_HANDLER_ARGS)
{
char *p;
! int error, oid[CTL_MAXNAME], len = 0;
struct sysctl_oid *op = 0;
if (!req->newlen)
___
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: kern_sysctl.c compilation failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/10 15:25, Matthew Fleming wrote: > On Mon, Nov 29, 2010 at 12:07 PM, Michael Butler > wrote: > Seems that 'treat warnings as errors' snags on this .. patch attached, > >> Which compiler are you using? I didn't have any trouble with this >> file on a make universe last night... > >> There's nothing wrong with the patch; I'd just like to understand why >> you see an error and I do not. gcc complains of 'len' being used uninitialized after SVN r216059, imb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (FreeBSD) iEUEARECAAYFAkz0DykACgkQQv9rrgRC1JLWNQCY/ZlpeKnLBH80N4X/ENSbqLqo bQCgqFld9e7+eK2sntXzOcqe5y8e2j0= =NiUc -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: Should green_saver.ko shut off a laptop's backlight?
On 11/29/2010 07:09, John Baldwin wrote: On Saturday, November 27, 2010 11:30:56 pm Adam Vande More wrote: On Sat, Nov 27, 2010 at 6:39 PM, Doug Barton wrote: My recollection is that green_saver should turn off an LCD backlight, but I just loaded it up on my laptop and it's not doing so. It does remove the text from the screen, but the backlight is still on (i.e., it is doing exactly what blank_saver does). When running X DPMS works on that same laptop, so I know the hardware is capable. This is 9-current amd64 at r214025. Any suggestions are welcome. It's never worked for me either and this has been around awhile. http://www.freebsd.org/cgi/query-pr.cgi?pr=114928&cat= green_saver just ask's your video card's BIOS to shut the screen off. If the BIOS doesn't turn off the backlight, that is the BIOS's problem, not something we can fix. Ok, so does the attached seem reasonable? -- 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/ Index: splash.4 === --- splash.4(revision 216062) +++ splash.4(working copy) @@ -26,7 +26,7 @@ .\" .\" $FreeBSD$ .\" -.Dd April 7, 2010 +.Dd November 29, 2010 .Dt SPLASH 4 .Os .Sh NAME @@ -114,7 +114,12 @@ .It Pa fire_saver.ko A fire which becomes higher as load increases. .It Pa green_saver.ko -If the monitor supports power saving mode, it will be turned off. +The screen will be blanked, similar to +.Pa blank_saver.ko . +If the monitor and/or the video card's BIOS support it, +the screen will also be powered off. +The latter may not work with LCD monitors, +or monitors connected to a Digital Visual Interface (DVI) port. .It Pa logo_saver.ko Animated graphical .Fx ___ 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: Should green_saver.ko shut off a laptop's backlight?
On Monday, November 29, 2010 4:10:02 pm Doug Barton wrote: > On 11/29/2010 07:09, John Baldwin wrote: > > On Saturday, November 27, 2010 11:30:56 pm Adam Vande More wrote: > >> On Sat, Nov 27, 2010 at 6:39 PM, Doug Barton wrote: > >> > >>> My recollection is that green_saver should turn off an LCD backlight, but > >>> I > >>> just loaded it up on my laptop and it's not doing so. It does remove the > >>> text from the screen, but the backlight is still on (i.e., it is doing > >>> exactly what blank_saver does). > >>> > >>> When running X DPMS works on that same laptop, so I know the hardware is > >>> capable. This is 9-current amd64 at r214025. Any suggestions are welcome. > >>> > >> > >> It's never worked for me either and this has been around awhile. > >> > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=114928&cat= > > > > green_saver just ask's your video card's BIOS to shut the screen off. If > > the > > BIOS doesn't turn off the backlight, that is the BIOS's problem, not > > something we can fix. > > Ok, so does the attached seem reasonable? I would say 'If the monitor and the video card's BIOS support it' because both things have to be true for green_saver to work. and/or implies that only one has to be true. I'm not sure the second paragraph is truly needed since I've seen it work fine with LCD's on other laptops and other external monitors as well. I think simply adding the text about the video card's BIOS is sufficient (and a definite improvement). -- 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: panic: sched_priority: invalid priority 2906: nice 0, ticks 122865664 ftick 516947 ltick 517947 tick pri 2726
2010/11/29 Alexander Motin : > On 29.11.2010 17:07, John Baldwin wrote: >> >> On Friday, November 26, 2010 4:38:49 pm David Rhodus wrote: >>> >>> I hit this panic on my NFS server. >>> >>> -DR >>> >>> coke.fun dumped core - see /var/crash/vmcore.2 >>> >>> Fri Nov 26 14:50:48 UTC 2010 >>> >>> FreeBSD coke.fun 9.0-CURRENT FreeBSD 9.0-CURRENT #14 r215800: Wed Nov >>> 24 12:35:30 UTC 2010 r...@coke.fun:/usr/obj/usr/src/sys/GENERIC >>> i386 >>> >>> panic: sched_priority: invalid priority 2906: nice 0, ticks 122865664 >>> ftick 516947 ltick 517947 tick pri 2726 >> >> I ran the numbers and assuming a hz of 1000, this requires you to have a >> very >> large value for ts_ticks (about (2726 * 24)<< 10). I suspect this is due >> to >> sched_tick() being invoked for a long idle sleep combined with the >> eventtimer >> changes. Can you go to frame 10 and 'p td->td_sched->ts_ticks'? > > As I can see, this is VirtualBox virtual machine. So it is still a question > what side makes so large hole in sched_tick() on some CPUs. It could be > interesting to get ktr(4) dump with KTR_SPARE2 mask: > > options KTR > options ALQ > options KTR_ALQ > options KTR_ENTRIES=131072 > options KTR_COMPILE=(KTR_SPARE2) > options KTR_MASK=(KTR_SPARE2) I'm sure gianni (CC'ed) got this bug and got some conclusions on it before (maybe he also has a patch). Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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"
[head tinderbox] failure on sparc64/sun4v
TB --- 2010-11-29 20:08:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-11-29 20:08:01 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-11-29 20:08:01 - cleaning the object tree TB --- 2010-11-29 20:08:14 - cvsupping the source tree TB --- 2010-11-29 20:08:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-11-29 20:08:30 - building world TB --- 2010-11-29 20:08:30 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-29 20:08:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-29 20:08:30 - TARGET=sun4v TB --- 2010-11-29 20:08:30 - TARGET_ARCH=sparc64 TB --- 2010-11-29 20:08:30 - TZ=UTC TB --- 2010-11-29 20:08:30 - __MAKE_CONF=/dev/null TB --- 2010-11-29 20:08:30 - cd /src TB --- 2010-11-29 20:08:30 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 29 20:08:31 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Nov 29 21:11:40 UTC 2010 TB --- 2010-11-29 21:11:40 - generating LINT kernel config TB --- 2010-11-29 21:11:40 - cd /src/sys/sun4v/conf TB --- 2010-11-29 21:11:40 - /usr/bin/make -B LINT TB --- 2010-11-29 21:11:40 - building LINT kernel TB --- 2010-11-29 21:11:40 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-29 21:11:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-29 21:11:40 - TARGET=sun4v TB --- 2010-11-29 21:11:40 - TARGET_ARCH=sparc64 TB --- 2010-11-29 21:11:40 - TZ=UTC TB --- 2010-11-29 21:11:40 - __MAKE_CONF=/dev/null TB --- 2010-11-29 21:11:40 - cd /src TB --- 2010-11-29 21:11:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Nov 29 21:11:40 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Nov 29 21:34:25 UTC 2010 TB --- 2010-11-29 21:34:25 - building GENERIC kernel TB --- 2010-11-29 21:34:25 - MAKEOBJDIRPREFIX=/obj TB --- 2010-11-29 21:34:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-11-29 21:34:25 - TARGET=sun4v TB --- 2010-11-29 21:34:25 - TARGET_ARCH=sparc64 TB --- 2010-11-29 21:34:25 - TZ=UTC TB --- 2010-11-29 21:34:25 - __MAKE_CONF=/dev/null TB --- 2010-11-29 21:34:25 - cd /src TB --- 2010-11-29 21:34:25 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Nov 29 21:34:26 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_switch.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_sx.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/kern/kern_synch.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medany -msoft-f
Re: Should green_saver.ko shut off a laptop's backlight?
On 11/29/2010 13:14, John Baldwin wrote: On Monday, November 29, 2010 4:10:02 pm Doug Barton wrote: On 11/29/2010 07:09, John Baldwin wrote: On Saturday, November 27, 2010 11:30:56 pm Adam Vande More wrote: On Sat, Nov 27, 2010 at 6:39 PM, Doug Barton wrote: My recollection is that green_saver should turn off an LCD backlight, but I just loaded it up on my laptop and it's not doing so. It does remove the text from the screen, but the backlight is still on (i.e., it is doing exactly what blank_saver does). When running X DPMS works on that same laptop, so I know the hardware is capable. This is 9-current amd64 at r214025. Any suggestions are welcome. It's never worked for me either and this has been around awhile. http://www.freebsd.org/cgi/query-pr.cgi?pr=114928&cat= green_saver just ask's your video card's BIOS to shut the screen off. If the BIOS doesn't turn off the backlight, that is the BIOS's problem, not something we can fix. Ok, so does the attached seem reasonable? I would say 'If the monitor and the video card's BIOS support it' because both things have to be true for green_saver to work. and/or implies that only one has to be true. I'm not sure the second paragraph is truly needed since I've seen it work fine with LCD's on other laptops and other external monitors as well. I think simply adding the text about the video card's BIOS is sufficient (and a definite improvement). Ok, done in r216065, thanks. I will update the PR soon'ish. Doug -- 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: panic: sched_priority: invalid priority 2906: nice 0, ticks 122865664 ftick 516947 ltick 517947 tick pri 2726
On Mon, Nov 29, 2010 at 9:56 PM, Attilio Rao wrote: > 2010/11/29 Alexander Motin : >> On 29.11.2010 17:07, John Baldwin wrote: >>> >>> On Friday, November 26, 2010 4:38:49 pm David Rhodus wrote: I hit this panic on my NFS server. -DR coke.fun dumped core - see /var/crash/vmcore.2 Fri Nov 26 14:50:48 UTC 2010 FreeBSD coke.fun 9.0-CURRENT FreeBSD 9.0-CURRENT #14 r215800: Wed Nov 24 12:35:30 UTC 2010 r...@coke.fun:/usr/obj/usr/src/sys/GENERIC i386 panic: sched_priority: invalid priority 2906: nice 0, ticks 122865664 ftick 516947 ltick 517947 tick pri 2726 >>> >>> I ran the numbers and assuming a hz of 1000, this requires you to have a >>> very >>> large value for ts_ticks (about (2726 * 24)<< 10). I suspect this is due >>> to >>> sched_tick() being invoked for a long idle sleep combined with the >>> eventtimer >>> changes. Can you go to frame 10 and 'p td->td_sched->ts_ticks'? >> >> As I can see, this is VirtualBox virtual machine. So it is still a question >> what side makes so large hole in sched_tick() on some CPUs. It could be >> interesting to get ktr(4) dump with KTR_SPARE2 mask: >> >> options KTR >> options ALQ >> options KTR_ALQ >> options KTR_ENTRIES=131072 >> options KTR_COMPILE=(KTR_SPARE2) >> options KTR_MASK=(KTR_SPARE2) > > I'm sure gianni (CC'ed) got this bug > and got some conclusions on it > before (maybe he also has a patch). I got it on QEMU and assumed that QEMU was not doing a proper job of distributing run-time amongst cores (so VirtualBox???). I figured out that sched_tick is being passed a huge number of ticks elapsed for the cpu at startup, in my case, by hardclock_anycpu (kern_clock.c). I haven't a patch only a dirty hack just to make sure we won't be running for more than 5s solid, if we have a huge number of ticks in input to sched_tick, which is something that ULE can still handle. Hope this helps. diff -r d16464301129 sys/kern/kern_clock.c --- a/sys/kern/kern_clock.c Thu Sep 23 11:56:35 2010 -0400 +++ b/sys/kern/kern_clock.c Sun Oct 03 17:53:39 2010 -0400 @@ -525,7 +525,7 @@ hardclock_anycpu(int cnt, int usermode) PROC_SUNLOCK(p); } thread_lock(td); - sched_tick(cnt); + sched_tick((cnt < (hz*10)/2) ? cnt : (hz*10)/2); td->td_flags |= flags; thread_unlock(td); -- Giovanni Trematerra ___ 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: sched_priority: invalid priority 2906: nice 0, ticks 122865664 ftick 516947 ltick 517947 tick pri 2726
On 29.11.2010 23:47, Giovanni Trematerra wrote: I got it on QEMU and assumed that QEMU was not doing a proper job of distributing run-time amongst cores (so VirtualBox???). I figured out that sched_tick is being passed a huge number of ticks elapsed for the cpu at startup, in my case, by hardclock_anycpu (kern_clock.c). Problem with many ticks at CPU startup should be fixed by r214987. I haven't a patch only a dirty hack just to make sure we won't be running for more than 5s solid, if we have a huge number of ticks in input to sched_tick, which is something that ULE can still handle. Hope this helps. diff -r d16464301129 sys/kern/kern_clock.c --- a/sys/kern/kern_clock.c Thu Sep 23 11:56:35 2010 -0400 +++ b/sys/kern/kern_clock.c Sun Oct 03 17:53:39 2010 -0400 @@ -525,7 +525,7 @@ hardclock_anycpu(int cnt, int usermode) PROC_SUNLOCK(p); } thread_lock(td); - sched_tick(cnt); + sched_tick((cnt< (hz*10)/2) ? cnt : (hz*10)/2); td->td_flags |= flags; thread_unlock(td); -- Giovanni Trematerra -- 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: kern_sysctl.c compilation failure
On Mon, Nov 29, 2010 at 12:07 PM, Michael Butler wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Seems that 'treat warnings as errors' snags on this .. patch attached, Which compiler are you using? I didn't have any trouble with this file on a make universe last night... There's nothing wrong with the patch; I'd just like to understand why you see an error and I do not. Thanks, matthew > > imb > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (FreeBSD) > > iEYEARECAAYFAkz0B/YACgkQQv9rrgRC1JKLBgCeNhKn2W6Z2XFN/zt70PbFhKbP > eHcAoIwI0Iz0g5TmU/pjbnG8zlcY6a1y > =a/KQ > -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" > ___ 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"
CFT: patch for process shared pthread objects
Hi, I finally have worked out first patch to make our pthread library support process shared pthread objects: http://people.freebsd.org/~davidxu/pshared/patch1.diff Many changes are related to redesigned pthread condition variable, these changes try to eliminate extra context switch when pthread_cond_signal is called which could reduce performance. There are two parts in the condition variable implementation. A pure usermode condition variable and kernel-based condition variable. All priority protected, inherited mutexs and process shared mutex will use kernel base condition variable, for a normal mutex, the usermode condition variable is used. Both user-mode and kernel-based try to migrate a thread from condition variable wait queue to mutex wait queue. Another added feature is robust mutex support, http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_setrobust.html Which I think is mostly used for process-shared mutex. In the patch, if mutex attribute is robust, the thread library also uses kernel base condition variable which does not have internal lock in userland. 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"
Re: CFT: patch for process shared pthread objects
On Mon, Nov 29, 2010 at 9:48 PM, David Xu wrote: > Hi, > > I finally have worked out first patch to make our pthread library > support process shared pthread objects: > > http://people.freebsd.org/~davidxu/pshared/patch1.diff > > Many changes are related to redesigned pthread condition variable, > these changes try to eliminate extra context switch when > pthread_cond_signal is called which could reduce performance. > There are two parts in the condition variable implementation. > A pure usermode condition variable and kernel-based condition > variable. All priority protected, inherited mutexs and process > shared mutex will use kernel base condition variable, for a > normal mutex, the usermode condition variable is used. > Both user-mode and kernel-based try to migrate a thread from > condition variable wait queue to mutex wait queue. > > Another added feature is robust mutex support, > http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_setrobust.html > Which I think is mostly used for process-shared mutex. > > In the patch, if mutex attribute is robust, the thread library > also uses kernel base condition variable which does not have > internal lock in userland. Doesn't build :/...: ===> lib/libthr (obj,depend,all,install) make: don't know how to make thr_sleepq.c. Stop *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. 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: CFT: patch for process shared pthread objects
Garrett Cooper wrote: Doesn't build :/...: ===> lib/libthr (obj,depend,all,install) make: don't know how to make thr_sleepq.c. Stop *** Error code 2 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Thanks, -Garrett Sorry, I have updated it, please download it again, or just download file: http://people.freebsd.org/~davidxu/pshared/thr_sleepq.c and put it in directory src/lib/libthr/thread/ ___ 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"
