Rob Benwell recommends this site
Your friend Rob Benwell(instantprof...@yahoo.com) has recommended this site to you, and sends you the following message: Hello Friend, GUARANTEED!: Get your $778.83 instantprofit Commissions Now!!! Underground Automated Method Allows 19 Years Old Kid Blogger To Raid The Market For $23.6 Million And Takes Complete Newbie To $37,730 In Just 30 Days It Doesn\'t Matter If You\'ve Never Even Earned A Single Cent Online Before... If A Total Beginner Can Make $37,730 In His First Month Then Anyone Can Do This... Imagine waking up at 10 in the morning.. doing your short workout routine.. opening your computer..and finding out you made $100 up to $200 - while you were a sleep! It\'s Easy To Make Money Everyday Even If You\'re Starting From Scratch With Zero Knowledge, Experience Or Budget!I\'ll Show You Exactly How. We\'ve Start putting New 39 Members in YOUR TEAM for the January 1th-20th 2011 commission cycle... and GROWING everyday earn by $100 up to $200 or more. IMPORTANT: January 20, 2011 is the Cut-Off day to lock in your position then faster you act the higher commission you will earn!!! Go Here To Secure not less than $778.83 commission Now and it still growing as many people joining under you. if you secure your position right away: The $778.83 commission will Arrive Through your Paypal or Credit Card on February 20/2011 next month. Hurry\'this limited time, only 8 days remaining Positions are available Now. You will access your money in any ATM when you join early & follow the instructions you receive. Click below!! https://www.plimus.com/jsp/redirect.jsp?contractId=2896494&referrer=lanielami TYPE DATE & TIME --- NEW MEMBERS --- COUNTRY P -- JAN.3 @ 2:38 AM-Dianna Rosebilt- United States P -- JAN.3 @ 2:53 AM-JOan-- Jacckson United Kingdom P -- JAN.3 @ 2:56 AM-Mandene -- Jecob Germany M -- JAN.3 @ 4:19 AM-Cristy Chan- Hungary P -- JAN.3 @ 4:28 AM-Carlo- Wonder--- Italy M -- JAN.2 @ 6:01 AM-lalaine--- ferguson- Australia P -- JAN.2 @ 7:11 AM-Rebecca--- Underwood Canada P -- JAN.2 @ 7:39 AM-Jericho--- Morales-- Mexico P -- JAN.2 @ 9:42 AM-Thomas Silva --- California M -- JAN.2 @ 9:58 PM-Grace- Taylor--- Singapore P -- JAN.2 @ 10:21 PM-Gina-- Henry New Zealand P -- JAN.1 @ 11:24 PM-Mohammed-- Ahmen --- Oman M -- JAN.1 @ 11:33 PM-Tracia Furlong-- Puerto Rico P -- JAN.1 @ 11:41 PM-Jane-- Mckay Russia P -- JAN.1 @ 9:42 AM-Steve- Scott --- Netherlands M -- JAN.1 @ 9:58 PM-Greg-- Stanley-- Denmark P -- JAN.1 @ 10:21 PM-Jack-- Perkins-- Amsterdam P -- JAN.1 @ 11:24 PM-Arlene Tan - China M -- JAN.1 @ 11:33 PM-Andy-- Hopekins- New York P -- JAN.1 @ 11:41 PM-Jhon-- Robinson- United States M -- JAN.1 @ 2:34 AM --- Kevin- Hunt Sweden P -- JAN.1 @ 12:34 AM --- Delia- Lane New York P -- JAN.1 @ 6:45 AM --- Mohamed--- Suhail--- Saudi Arabia M -- JAN.1 @ 5:34 AM --- Aleks- Gjuroski Japan P -- JAN.1 @ 12:34 PM --- Andrew Karim --- England P -- JAN.1 @ 8:23 AM --- Carla- Pereira - South Korea P -- JAN.1 @ 2:34 PM --- Carl-- Krause -- India M -- JAN.1 @ 9:14 AM --- David- Cook Denmark P - JAN.1 @ 7:46 AM --- Paul-- Amid Taiwan P -- JAN.1 @ 1:54 AM --- Dennis Wilkins - Findland P -- JAN.1 @ 12:34 AM --- Jonathan-- Wangyu -- Thailand P -- JAN.1 @ 6:45 AM --- Mackie Anhui Indonesia M -- JAN.1 @ 5:34 AM --- Alexis Mathew -- Jerosalim P -- JAN.1 @ 8:23 AM --- Cheryl Moran --- Philippines P -- JAN.1 @ 2:34 PM --- Vergie Petter -- Ingland M -- JAN.1 @ 9:14 AM --- Tito-- Warren -- Bangladish P - JAN.1 @ 7:46 AM --- Raul-- Strogher United States Therefore, you have a GUARANTEED $778.83 CommissionS every month from now on!. Earn $19.97 Per Process!Each $19.97 x 39 = $778.83 Commission will be yours...! Be Sure to Copy the link below & Paste into your browser and press enter: To Secure your $778.83 commission! You will access your money in any ATM when you follow the instructions you receive. https://www.plimus.com/jsp/redirect.jsp?contractId=2896494&referrer=lanielami Big Chance to you ,Becuase $19.97 membership only automatic back to you,Guaranteed you can recieve lifetime commissions every 20th of the month. Today its $778.83 For the start of the month of January if goes up daily until the end of the month. You must UPGRADE right away or before others do Caring for Your Success, Rob Benwell https://kap7waterpolo.com/proddetail.php?prod=kap103Junior ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mai
FreeBSD 7.0 and Samba 3.3.2 crash over ZFS share
Hi, I have small home file server running FreeBSD 7.0 and 4x500 GBytes ZFS volume. Currently I have Samba 3.0.34 from ports working fine. When I install latest Samba 3.3.2 from ports any access to shares residing on ZFS volume cause panic in samba. Access to UFS share is fine. Any body see same problem? Is it possible to fix? uname -a FreeBSD 7.0-RELEASE-p11 #25: Fri Mar 27 19:13:25 EDT 2009 r...@storage:/usr/obj/usr/src/sys/VIAC7 i386 Thank you, Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[no subject]
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
shutdown
Hi ! My laptop (dell inspiron 1150) do nothing when i want to shutdown it from power button. How can i fix this trouble ? FreeBSD dell1.xx 5.4-STABLE FreeBSD 5.4-STABLE #1: Thu Oct 13 16:11:55 MSD 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DELL1KERN5X i386 dell1# cat /var/log/messages | grep acpi|grep butt Oct 14 09:44:52 dell1 kernel: acpi_button0: on acpi0 Oct 14 09:44:52 dell1 kernel: acpi_button1: on acpi0 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re[2]: Java for FreeBSD
Hello Andrew, Tuesday, February 12, 2002, 5:54:15 AM, you wrote: AR> On Mon, Feb 11, 2002 at 02:28:34PM +0100, Gunnar Flygt wrote: >> What's the status for Java native version for FreeBSD, that was >> announced in stable a few weeks ago? AR> I've just installed the native j2ee_sdk that lives in AR> /usr/ports/java/jdk13, seemingly without problems. I had to AR> have the linux-jdk13 port installed first, which wasn't AR> expressed as a package dependancy, but wasn't hard to fix, AR> either. Is there away to install JDK 1.3+ without X? I tried to install it on 4.4 but it wanted to install X and asked me lot of quistions about it. I also needed to download two compressed files by hand (normal). Didn't hear anything about needing linux-jdk due. -- Best regards, Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
build world & kernel
Hello , I got a problem on the latest world sources. I cvsup them all and i did a build world & kernel (takes a day). As fas as i can see all went well. But when i rebooted the software complained it couldn't find the root partition. I solved the problem by loading the old kernel. I build the GENERIC kernel with some extra options for my firewall and such. The root partition exist on a IDE drives. I read something about ATA, but don't know any more about this. Any help, suggestions, ect. is very welcome and appreciated. -- Best regards, Alex mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
installworld failure on -STABLE [/usr/src/gnu/usr.bin/perl/library]
Hi all, I have just installed FreeBSD 4.8 -RELEASE and updated /usr/src to track RELENG_4. Buildworld builds fine, along with buildkernel. However, installworld fails with: ===> gnu/usr.bin/perl ===> gnu/usr.bin/perl/libperl install -C -o root -g wheel -m 444 libperl.a /usr/lib install -C -o root -g wheel -m 444 libperl_p.a /usr/lib install -s -o root -g wheel -m 444 libperl.so.3 /usr/lib ln -fs libperl.so.3 /usr/lib/libperl.so ===> gnu/usr.bin/perl/miniperl ===> gnu/usr.bin/perl/perl install -s -o root -g wheel -m 555 perl /usr/bin /usr/bin/perl5 -> /usr/bin/perl /usr/bin/perl5.00503 -> /usr/bin/perl ===> gnu/usr.bin/perl/suidperl install -s -o root -g wheel -m 511 suidperl /usr/bin /usr/bin/sperl5 -> /usr/bin/suidperl /usr/bin/sperl5.00503 -> /usr/bin/suidperl ===> gnu/usr.bin/perl/library cd: can't cd to /usr/src/gnu/usr.bin/perl/library/lib *** Error code 2 Stop in /usr/src/gnu/usr.bin/perl/library. *** Error code 1 Stop in /usr/src/gnu/usr.bin/perl. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 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. Any ideas ? I'm desperate to get this box up and running. - Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI internal modem
Warner Losh wrote: > > In message <[EMAIL PROTECTED]> Wayne M Barnes writes: > : How do I get my PCI modem card to work with FreeBSD 3.4? > > *IF* it isn't a win modem, soft modem, etc, then you can apply the > following patch, rebuild your kernel and create /dev/cua4, et al in > /dev. > > If it is a win modem, you lose. Sell it to some sucker and buy a real > pci modem. > > Patch: http://www.freebsd.org/~imp/Psio Just wondering - why isn't this in the tree? You seem to have had this patch for quite some time now (or at least announced it several months ago). Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: CVSup woes
Mark Ovens wrote: > > > I haven't seen any problems like this under 3.4. Have you tried > > some other mirror sites? There are only about 50 of them to choose > > from. :-) > > > > Since you're in the UK try > > *default host=cvsup.uk.FreeBSD.org Yeah, it used to be Imperial College London, but now Easynet seems to be taking over the world... (running FreeBSD mostly BTW). They have a pretty damn fast link to NY, so I wouldn't be surprised if it was faster even for some people in the US. Alex > > in your sup-file > > I get excellent d/l speeds from there (some of the US servers are > painfully slow from the UK, unless you pick a time when everyone's > asleep over The Pond). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: linux emulation on 3.4-stable
Steve O'Hara-Smith wrote: > > On 27-Dec-99 Mamoru Iwaki wrote: > > Hi, > > > > I met warnings like > > > > LINUX: 'ioctl' fd=9, typ=0x44d(M), num=0x76 not implemented > > LINUX: 'ioctl' fd=7, typ=0x44d(M), num=0x76 not implemented > > > > when realplay was running. The program is an alpha 2 release of > > RealPlayer G2 for Linux 2.0/2.2 and we can get from > > http://www.real.com/products/player/linux.html > > Did the RealPlayer G2 work ? > > A few unimplemented messages do not necessarily prevent linux apps from > running (I have no idea what these ones do BTW). Nor are they necessarily a bug > or problem sometimes they simply reflect things required in Linux and not in > FreeBSD. > > > Please implement these ioctl's. > > I suspect that this will only happen if/when > > i) They are needed (to make something work). > > ii) Somebody implements them. It's the OSS_GETVERSION ioctl, and it was implemented in -current 6 months ago. The version can now be changed through the sysctl variable compat.linux.oss_version. See PR/12917. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Best way to switch from Linux to BSD
,--- Michal (Tue, 29 Mar 2011 20:20:04 +0200) * | There is also no Microsoft Windows Management Console for FreeBSD, does | it make FreeBSD lacking, insufficient, or broken in some specific server | area? It's time to switch this char elsewhere, to -help, perhaps, no? -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: recommendations for laptop and desktop [SEC=UNCLASSIFIED]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 0n Thu, Jul 14, 2011 at 04:08:48PM +0200, Julian H. Stacey wrote: >Zoran Kolic wrote: >> > Zoran's comments that http://laptop.bsdgroup.de/freebsd/ is 'obsolete' >> > are a bit misplaced regarding older kit that some of us use by choice or >> > necessity (eg my 2.5 Thinkpad T23s :) >> >> Sorry for the word chosen in this case. I use one even older >> lapper, HP nx9020, with real 4:3 screen, matte. I'm ready to >> write about it. The only problem is that it is not possible >> to find anymore. So, no use. > >Theres a difference between have / find / buy / receive a laptop ;-) >So it's still nice to docu. older hardware if they supports BSD, >because sometimes people get old laptops thrust upon them :-) > "Here take this thing, I'm not using, I've heard you say BSD >is more efficient than MS, so maybe'll get some use out of it" >Then you get home with it & look it up on the web ... :-) There is always iXsystems invincibook - at least it should "just work" http://www.ixsystems.com/ix/servers/home-and-office/invincibook-freebsd-laptop -Alex -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOHvqEAAoJEMv3KTBtKivP590H/ipNA4d7EBp+LdBBOby0qwWR F2k4ORP084IyXYkUCI/NG6LadrHggsdZ34pbOIM3ZkS25PgFCvxDo4pJuhTWoGR/ Bn6W1zsFXCNyAKiyB/YR0AtNymNKYYvhJPg7t1IIJbHWZepmSorfK560Z8Y01EfE epSPtGXxrvBZz2Ej/69AGnh3+LP3wx4dOC5JM+E9fCwy+56lOkpcjeyrKEWtPasp ADr56ofRLQbUIL8q1ehOTs6Cw7ZBhO/4Bk2YN5zZV7rAz2afv7z1qfSByWHp5KD5 fSLQKZHrtJ/hFcrbfe8FKLqZWZ+wklV7FhjVmaq+hOimp8BZg4YgY/gmKM2R1rE= =kW53 -END PGP SIGNATURE- IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Dtrace with PHP scripts works on FreeBSD8-STABLE!
Hello,
I was able to compile [1] and and run PHP Dtrace provider on
FreeBSD-STABLE. Everything works as expected and looks very cool. It
works both from Apache (mod_php) and cli. If there are port commiters
with dtrace experience - please, take it.
Below there is a small demo:
This is a test script:
PrintTest();
class demoClass{
function demoClass(){
@chdir("/notexists");
}
function PrintTest(){
echo "TEST\n";
}
}
?>
This is the most basic output to demonstrate how provider works:
# dtrace -n 'php*::: /arg0/
{printf("\t\t%s%s%s",copyinstr(arg3),copyinstr(arg4),copyinstr(arg0))}'
dtrace: description 'php*::: ' matched 24 probes
dtrace: buffer size lowered to 2m
CPU IDFUNCTION:NAME
2 44455 php_dtrace_execute_internal:function-entry
file_get_contents
2 44457 php_dtrace_execute_internal:function-return
file_get_contents
2 44456 php_dtrace_execute:function-entry
demoClass::demoClass
2 44455 php_dtrace_execute_internal:function-entry chdir
2 44457 php_dtrace_execute_internal:function-return chdir
2 44458 php_dtrace_execute:function-return
demoClass::demoClass
2 44456 php_dtrace_execute:function-entry
demoClass::PrintTest
2 44458 php_dtrace_execute:function-return
demoClass::PrintTest
As you could see there is information about all functions (and
classnames) in our test.
Also there is a possibility to trace syscalls used by PHP function. This
is output from ./php_syscolors.d (with minor modifications):
for the file_get_contents (reads file to variable):
1 16019/100898 6 test.php:4func ->
file_get_contents
1 16019/100898 18 ":-syscall-> __getcwd
1 16019/100898 8 ":-syscall <- __getcwd
1 16019/100898 8 ":-syscall->
clock_gettime
1 16019/100898 4 ":-syscall <- clock_gettime
1 16019/100898 5 ":-syscall-> open
1 16019/100898 9 ":-syscall <- open
1 16019/100898 5 ":-syscall-> fstat
1 16019/100898 5 ":-syscall <- fstat
1 16019/100898 4 ":-syscall-> lseek
1 16019/100898 4 ":-syscall <- lseek
1 16019/100898 5 ":-syscall-> fstat
1 16019/100898 4 ":-syscall <- fstat
1 16019/100898 4 ":-syscall-> read
1 16019/100898 6 ":-syscall <- read
1 16019/100898 9 ":-syscall-> read
1 16019/100898 5 ":-syscall <- read
1 16019/100898 4 ":-syscall-> read
1 16019/100898 4 ":-syscall <- read
1 16019/100898 5 ":-syscall-> close
1 16019/100898 10 ":-syscall <- close
1 16019/100898 8 test.php:4func <- file_get_contents
Of course it is possible to use aggregations, filtering and all other
dtrace features.
Problems: I found that buffer size in dtrace is always about 2m. I am
using a lot of events while trying to debug running web server.
Todo: latest PHP alpha releases include dtrace support internally (and
it is extended, compared to this pecl extension). Currently build
failing on BSD and i had no time to investigate problem source (i think
they are using some ugly linker hacks). It would be great to get it
fixed before PHP release to have it in FreeBSD out of the box.
[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=158983
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
dtrace/mysqld
If anyone interested - i was able to compile dtrace support in mysql-server55 port. During this i found a bug in dtrace/bsd - if it is running more then 1 time on the same object (this is the case for mysqld) then object is broken. I was able to do workaround (with preserving original object and then copying it) and then everything compiled and started correctly. This is an example: bsd# ./work/mysql-5.5.14/support-files/dtrace/query-time.d dtrace: buffer size lowered to 2m Who Database QueryTime(ms) root@localhost mysqlselect sleep(1) from user limit 11000 root@localhost mysqlselect * from user limit 1 0 I will try to cleanup my patches (its currently very dirty hacks) and submit them to the mysql bugtracker (and port). Feel free to contact me if you want to test this (or to fix dtrace/obects bug). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: dtrace ustack kernel panic
Hi, I just tried your test on -STABLE + 1 fix from current [1] and got no trap. dtrace: buffer size lowered to 2m CPU IDFUNCTION:NAME 4 42224accept:return nc accept:return Assertion failed: (dpr != NULL), file /usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_proc.c, line 751. Abort (core dumped) Also 1st dtrace was killed as well. I tried 2 times with the same result. Box is amd64. This is bt from gdb: (gdb) bt #0 0x000800fa2f9c in thr_kill () from /lib/libc.so.7 #1 0x00080103f6cb in abort () from /lib/libc.so.7 #2 0x000800786758 in dt_proc_lookup () from /lib/libdtrace.so.2 #3 0x0008007867db in dt_proc_lock () from /lib/libdtrace.so.2 #4 0x0008007a5bcb in dt_print_ustack () from /lib/libdtrace.so.2 #5 0x0008007a8504 in dt_print_agg () from /lib/libdtrace.so.2 #6 0x0008007a88ca in dtrace_consume () from /lib/libdtrace.so.2 #7 0x00080077e1a2 in dtrace_work () from /lib/libdtrace.so.2 #8 0x004044ba in ?? () #9 0x0040222e in ?? () [skip] [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/159064 On 07/26/2011 03:20 AM, maestro something wrote: Hi, when using the ustack action on the latest FreeBSD8.2 i386 the kernel panics. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bad sector in gmirror HDD
You can run long self-test in smartmontools (-t long). Then you can get failed sector number from the smartmontools (-l selftest) and then you can use DD to write zero to the specific sector. Also i am highly recommending to setup smartd as daemon and to monitor number of relocated sectors. If they will grow again - then it is a good time to utilize this disk. [root@bast:~] # dd of=/dev/null if=/dev/ad2 bs=1m conv=noerror dd: /dev/ad2: Input/output error 2717+0 records in 2717+0 records out 2848980992 bytes transferred in 127.128503 secs (22410246 bytes/sec) dd: /dev/ad2: Input/output error 38170+1 records in 38170+1 records out 40025063424 bytes transferred in 1544.671423 secs (25911701 bytes/sec) [root@bast:~] # That seems to indicate two problems. Are those the values I should be using with dd? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bad sector in gmirror HDD
"The SMART tests you did didn't really amount to anything; no surprise. short and long tests usually do not test the surface of the disk. There are some drives which do it on a long test, but as I said before, everything varies from drive to drive." It is not correct statement, sorry. Long test trying to read all the data from surface (and doing some other things). // one of the smartmontools developers and sysutils/smartmontools maintainer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smartctl / mpt on 9.0-RC1
Hello, I am smartmontools developer and FreeBSD port maintainer. If you could provide shell access to the affected system i can try to debug issue. I have no access to the mpt devices myself and it is unclear what going on from provided backtrace. On 11/03/2011 09:40 AM, Frank Razenberg wrote: Was this system "upgraded" from RELENG_8 to RELENG_9, or was a fresh install of 9.x put on it directly? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smartctl / mpt on 9.0-RC1
Thank you. I currently got shell, but user-only, what is useless for me ;-) (All ioctl/cam commands require superuser) I asked for the root and now waiting for it. You can also provide shell so i will have more boxes to test. I am expecting some very trivial bug caused by some wrong data returned from the driver without strict check in smartctl. On 11/03/2011 07:43 PM, James wrote: On Thu, Nov 3, 2011 at 12:12 PM, Alex Samorukov wrote: I am smartmontools developer and FreeBSD port maintainer. If you could provide shell access to the affected system i can try to debug issue. I have no access to the mpt devices myself and it is unclear what going on from provided backtrace. Hi Alex. If you're unable to get shell access from Frank, I'd be glad to help out. I have mps(4) and mpt(4) hardware available and experience the same bug. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smartctl / mpt on 9.0-RC1
Thank you,
it is really caused by MFC r225950 and smartctl way to detect sense
length. I decided not to add ifdefs, but change the logic.
I fixed this in SVN [1], patch in the unified diff format could be
downladed at [2]. Please test this, and if it works fine - i will submit
PR to the port.
[1]
https://sourceforge.net/apps/trac/smartmontools/changeset?old_path=%2Ftrunk%2Fsmartmontools%2Fos_freebsd.cpp&old=3468&new_path=%2Ftrunk%2Fsmartmontools%2Fos_freebsd.cpp&new=3467
[2]
https://sourceforge.net/apps/trac/smartmontools/changeset?format=diff&new=3467&old=3468&new_path=trunk%2Fsmartmontools%2Fos_freebsd.cpp&old_path=trunk%2Fsmartmontools%2Fos_freebsd.cpp
:On 11/03/2011 08:05 PM, Thomas Eberhardt wrote:
Hi. I got the same problem. After some debugging I came up with the
following patch:
--- os_freebsd.cpp.orig 2011-10-06 18:43:44.0 +0200
+++ os_freebsd.cpp 2011-10-23 11:19:31.492599837 +0200
@@ -1044,8 +1044,13 @@
}
if (iop->sensep) {
+#if CAM_VERSION< 0x16
memcpy(iop->sensep,&(ccb->csio.sense_data),sizeof(struct
scsi_sense_data));
iop->resp_sense_len = sizeof(struct scsi_sense_data);
+#else
+memcpy(iop->sensep,&(ccb->csio.sense_data),sizeof(struct
scsi_sense_data_fixed));
+iop->resp_sense_len = sizeof(struct scsi_sense_data_fixed);
+#endif
}
iop->scsi_status = ccb->csio.scsi_status;
On 03.11.2011, at 19:52, Alex Samorukov wrote:
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smartctl / mpt on 9.0-RC1
On 11/03/2011 08:37 PM, James wrote: On Thu, Nov 3, 2011 at 1:52 PM, Alex Samorukov wrote: Thank you. I currently got shell, but user-only, what is useless for me ;-) (All ioctl/cam commands require superuser) I asked for the root and now waiting for it. You can also provide shell so i will have more boxes to test. I am expecting some very trivial bug caused by some wrong data returned from the driver without strict check in smartctl. No problem. Send me your public key privately and I'll set you up. Could you please try to build latest svn version (see [1]) ? I think i fixed this bug. [1] https://sourceforge.net/apps/trac/smartmontools/wiki/Download ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smartctl / mpt on 9.0-RC1
On 11/03/2011 09:35 PM, James wrote: Thanks, Alex. Looks like you fixed it. smartctl no longer segfaults. Thank you for testing. I submitter PR [1] with this patch. It also contain patch to avoid problems with SATA drives on LSI (SAS) controllers. [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=162276 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [smartmontools-support] smartctl / mpt on 9.0-RC1
This is fixed by me in SVN. Also fix already applied in the ports, so please update your smartmontools port. On 11/02/2011 10:57 PM, Frank Razenberg wrote: Ever since I tried 9.0-RC1 I haven't been able to read SMART values of the disks attached to my Intel SASUC8i (LSI 1068e rebrand) controller with smartctl. Similar disks on motherboard SATA ports can be queried as expected. # smartctl -a /dev/da0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RC1 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net Segmentation fault (core dumped) The controller was flashed to run in IT-mode. The relevant smartctl.core dump is available at http://files.zzattack.org/smartctl.core.zip ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smartctl / mpt on 9.0-RC1
On 11/06/2011 04:52 PM, Marat N.Afanasyev wrote: I wonder is there a possibility to monitor sas drives on twa controllers? Hi Marat, I have no access to such hardware so don`t know if it works or not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smartctl / mpt on 9.0-RC1
it doesn't work :( sata drives are accessible, but for sas all we have: # smartctl -d 3ware,0 -a /dev/twa0 smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.2-RELEASE amd64] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net Command failed, ata.status=(0x00), ata.command=(0xec), ata.flags=(0x01) WARNING - NO DEVICE FOUND ON 3WARE CONTROLLER (disk 0) Smartctl: Device Read Identity Failed (not an ATA/ATAPI device) A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. Ok, looking in the code i found that on "3ware" device only "ata_command_interface" is implemented (with TW_OSL_IOCTL_FIRMWARE_PASS_THROUGH). The question is if that interface actually supports SAS drives at all. From the quick view of the sources i found TWE_Command_ATA packet description, but nothing related to SCSI/SATA packets. So i am not sure that it is possible at all. If you know any tool which able to get health information for SAS drives we can try to debug ioctl it using to find the way to talk with disk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smartctl / mpt on 9.0-RC1
On 11/06/2011 09:37 PM, Alex Samorukov wrote: Command failed, ata.status=(0x00), ata.command=(0xec), ata.flags=(0x01) WARNING - NO DEVICE FOUND ON 3WARE CONTROLLER (disk 0) Smartctl: Device Read Identity Failed (not an ATA/ATAPI device) A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. Ok, looking in the code i found that on "3ware" device only "ata_command_interface" is implemented (with TW_OSL_IOCTL_FIRMWARE_PASS_THROUGH). The question is if that interface actually supports SAS drives at all. From the quick view of the sources i found TWE_Command_ATA packet description, but nothing related to SCSI/SATA packets. So i am not sure that it is possible at all. If you know any tool which able to get health information for SAS drives we can try to debug ioctl it using to find the way to talk with disk. One more update - there is TWA_FW_CMD_EXECUTE_SCSI command in the twa driver, so it should be possible to get required data. I have no access to such hardware, but if anyone if going to provide it - i could try at least. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smartctl / mpt on 9.0-RC1
On 11/07/2011 02:06 PM, Jeremy Chadwick wrote: On Mon, Nov 07, 2011 at 04:53:36PM +0400, Marat N.Afanasyev wrote: btw, 3dm can tell about reallocated sector count on sas somehow, while smartctl cannot, even on supported controller :( I think this is getting into a separate discussion topic. I realise we're discussing SAS, but what's shown above looks pure and total SCSI output from smartmontools. I'm very familiar with it (we predominantly used SCSI disks at my workplace up until ~1 year ago). I will be satisfied with scsi-like output of smartctl for my sas drive on twa controller ;) Did you actually look at the output I provided? It's more or less the same, minus data which you want that isn't being shown (at all). That includes things like drive manufacturing date, etc.. The problem could be in one of the following layers: 1. smartmontools itself Hi Jeremy, It is "smartmontools itself" problem. On twa (3ware devices) we are using ATA-type of packets to speak with the device. It is fine for ATA/SATA disks, but not for SATA, which are using SCSI commands. The code for the SCSI conversation just needs to be written (btw, the same on Linux). Driver itself provides TWA_FW_CMD_EXECUTE_SCSI type of the packet, so it probably (!) possible to speak with underlying disks using it, but it needs to be tested. The problem is that i have no such controllers or drives. I could try to add this functionality if anyone will provide me access, but it should not be production system with any important data. E.g. when i was working on LSI code i had array degradations and controller hangs on legitimate SAT commands. 2. CAM translation layer (e.g. pass(4) or related bits) 3. twa(4) driver 2. is not in use, smartmontools using ioctl api to send commands to firmware. 3. - under the question. 4. 3Ware controller firmware 4. Yes, needs to be tested. It is common to see bugs in firmware in this area, it is not usually well tested (LSI with SAT protocol is a good example, i did workaround for this in recent smartmontools update). It is possible to determine if #1 and #2 are responsible by enabling CAMDEBUG and/or using "camcontrol debug" to watch all CDBs which are submit to the controller. I'm not sure which one is responsible for obtaining defect counts and so on -- I would need to review SAS and/or SCSI specifications. The information should be available per T10's SCSI and SAS specification documents. An alternate way to check would be to boot into a Linux LiveCD and install smartmontools (in RAM) and see if it provides the data. It would not. Just because SCSI interface for this driver is not implemented. My point: don't be so quick to assume smartmontools is responsible when there are 4 (maybe even 5) "layers" to how SCSI I/O makes it to the actual drive. This is one of the many reasons I try to avoid hardware RAID controllers -- too much crap between me and the device I wish to speak to. Its controversy statement. From my own point of view - device authors should implement passX devices for the disks like it done on mfip.ko or with Adaptec (at least on Linux). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mfip and smartctl Re: smartctl / mpt on 9.0-RC1
On 11/07/2011 02:47 PM, Andrew Boyer wrote: [GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on'] No self-tests have been logged Long (extended) Self Test duration: 1740 seconds [29.0 minutes] btw, 3dm can tell about reallocated sector count on sas somehow, while smartctl cannot, even on supported controller :( Notice how the device type is "<31>"? The mfip driver masks off the SCSI INQUIRY peripheral device type bits to prevent CAM from attached da* devices to the disks. See sys/dev/mfi/mfi_cam.c, search for T_DIRECT. That confuses smartctl and prevents it from displaying information like the Grown Defect List. I added a local hack to smartctl to interpret a peripheral device type of 0x1f (unknown or missing) to 0x0 (disk), but I don't think the hack is appropriate for general consumption. What we need is better way for mfi and aac to block CAM from attaching without corrupting the inquiry results I can add hack to the sources with checking if underlying driver is mfi (there are already some for buggy SAT fw implementation). It is probably easiest way to do this. I just tested - firmware itself returns correct (disk) status. Of course in the feature its better to fix in mfi_cam to avoid such hacks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smartctl / mpt on 9.0-RC1
On 11/07/2011 03:10 PM, Jeremy Chadwick wrote: I see. I wasn't aware there was an ioctl(2) interface to twa(4). This makes me wonder: why does Marat use /dev/passX as his device when using smartctl? Because Marat using LSI mfi (not 3ware twa!) driver in this case. mfip.ko exports /dev/passX devices for every disk in the raid. Could this have some bearing on why he doesn't see the necessary data returned from (if even submit to) the underlying disk? The syntax of his command was: "smartctl -a /dev/pass1". I would have expected the syntax to be "smartctl -a -d 3ware,1 /dev/twa". What I'm trying to get at here is whether or not smartmontools "does the right thing" in this situation. Does the output differ between the above two syntaxes? I don't see any mention in twa(4)'s man page that pass(4) is even registered/used -- though I do see it mentioned that CAM is used by twa(4). Smartmontools will not work on twa with SAS drives, because it is using IOCTL packet format for the ATA protocol. And we need to use SCSI packets to speak with SAS devices. This code is currently not written. Furthermore, later comments below indicate CAM isn't involved, which further confuses me. Can someone help relieve my confusion on this matter? Because Marat provided output for another controller and another driver. For me it is also unclear why :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: smartctl / mpt on 9.0-RC1
On 11/08/2011 09:33 PM, Marat N.Afanasyev wrote: why :) just a little misunderstanding, I suppose ;) I just showed what I'd expect from #smartctl -a -d 3ware,0 /dev/twa0 in case of sas drive on channel 0 Yes. BTW, if you able to provide access to the BSD box with MFI and SAS i could fix "defect sectors" status report. For the twa/SAS much work needs to be done, but if there is anyone with such controller and hardware (not in production!) i could try, at least. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
disk devices speed is ugly
Hi, I ported exfat fuse module to FreeBSD (PR 164473) and found that it works much slower then on Linux. I found 2 reasons for this: 1) FreeBSD kernel do not allow to have nonalignment access to device with standard read/write commands. mmap to the entire disk (/dev/da0s1) doesn`t work also (EINVAL). When its not a big deal for read requests, for write it becomes a real issue - to write non-aligned data i need to read beginning and end of the block. So in fact for one write request i can get 2 reads. 2) It seems that there is a very simple read caching on such devices without write caching at all. It makes write performance enormously slow. I found geom_cache module, but it provides only read optimization. I decided to compare speed on Linux and FreeBSD and below are my results. I used old USB flash drive to do the tests. Read Speed of 100Mb: Linux 3.0.0: 22.7 Mb/sec FreeBSD: 10.22 Mb/sec FreeBSD + gcache: 18.75 Mb/sec (!) Write speed of 100Mb file: Linux: 90Mb/sec (cache, much higher then device speed) FreeBSD: 0.52 Mb/sec (!) FreeBSD + gcache: 0.52 Mb/sec As you could see write performance is enormously slow. May be we need to create some geom provider for such caching or i am missing something? I think, that other fuse modules like ntfs-3g and fuse-ext4 having same issue. Also i found that fuse4bsd itself is non stable and may crash the system without any visible reasons. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: disk devices speed is ugly
On 01/31/2012 11:19 AM, Harald Schmalzbauer wrote: schrieb Alex Samorukov am 26.01.2012 14:52 (localtime): Hi, I ported exfat fuse module to FreeBSD (PR 164473) and found that it works much slower then on Linux. I found 2 reasons for this: Thanks a lot! I saw the new port :-) Hope that someone can help you improove fusefs-kmod. I remember more porters were blaming FreeBSDs fusefs support making their work hard/impossible (TrueCrypt). Hopefully some kernel hacker will read and help... Thank you for comment. It is now mostly not about fuse itself, but about non-buffered raw device access. I really think that something like improved geom_cache should solve this. I`ll add soon updated version of the patch with [optional] libublio support. This improves performance a lot. Read speed is comparable with Linux (about 20 Mb/sec on my old USB) and write is much faster aw well (but not so good as in Linux and with a lot read requests for align). Also i contacted upstream about unaligned writes and he told that it is in his todo list, but probably after 1.0.0 version, because it will require a lot of changes in the code. Also i found a libexfat bug in a fat time handling and creating patch to use freebsd code for this instead. So if you are using exfat any testing and comments are welcome. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New BSD Installer
On 02/10/2012 06:56 PM, Joe Holden wrote: Guys, This should really be reverted to sysinstall until the new installer is at least in a state where it consistently works... the most important part of a new users experience is the installer and the few new installs I have done lately I've just installed 8.2 and upgraded from there as the new installer is terribly buggy. Hi, I am highly against reverting. Old installer is not GPT aware and in fact is unmaintained for a very long time. About ftp - its probably needs to be handled better, but most of the user i think using cd/dvd image, so it is not an issue. And new installer is written on shell, so i think its better to fix broken parts then to revert it to outdated and unmaintained code. P.S. i personally had no problems with a new installer, used it from DVD. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: disk devices speed is ugly
On 02/12/2012 01:54 AM, Adrian Chadd wrote: Hi, What about the disk access is unaligned? Do you mean not sector aligned? or? Hi. Sector aligned. This is a common problem people face doing disk IO analysis. The whole point about not allowing unaligned access is to make the disk IO path cleaner. It does mean that the filesystem code (and GEOM modules involved) need to be smarter. If the filesystem is doing ridiculously unaligned access then it likely should be fixed. Yes. But it will nit fix non-cached access to the disk (raw) devices. And this is the main reason why ntfs-3g and exfat are much slower then working on Linux. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: disk devices speed is ugly
On 02/13/2012 06:27 AM, Adrian Chadd wrote: On 12 February 2012 09:34, Alex Samorukov wrote: Yes. But it will nit fix non-cached access to the disk (raw) devices. And this is the main reason why ntfs-3g and exfat are much slower then working on Linux. But _that_ can be fixed with the appropriate application of a sensible caching layer. With every application? :) Are you know anyone who wants to do this? At least for 3 fuse filesystems. Also, caching in user-land is much slower and more dangerous. There is a libublio utility which is done to provide userland caching (it implements pwrite/pread replacement) and it is in use by this 2 ports. So if there are alignment issues, let's fix those up first so filesystems act sensibly with the block device layer. Then yes, adding a caching layer that works. I didn't get very good performance with g_cache when i last tried it. Because its very primitive. Once again - try to compare performance of the exfat or ntfs-3g on Linux and FreeBSD. Raw device speed (i used USB) is pretty the same, but resulting speed is very different, as well as I/O characteristic. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: disk devices speed is ugly
On 02/13/2012 02:28 PM, Gary Palmer wrote: Yes. But it will nit fix non-cached access to the disk (raw) devices. And this is the main reason why ntfs-3g and exfat are much slower then working on Linux. But _that_ can be fixed with the appropriate application of a sensible caching layer. With every application? :) Are you know anyone who wants to do this? At least for 3 fuse filesystems. The filesystem is the *BEST* place to do caching. It knows what metadata is most effective to cache and what other data (e.g. file contents) doesn't need to be cached. Any attempt to do this in layers between the FS and the disk won't achieve the same gains as a properly written filesystem. e.g. in a UFS implementation the disk layer may see a lot of I/Os for blocks, not necessarily sequential, as a program lists a directory and stats all the files which pulls in the inode tables. The filesystem knows that it needs the inode tables and is likely to need not only the current inode table disk block but subsequent ones also, and instead of requesting the disk sector that it needs to service the immediate stat(2) request but maybe the next few also. Without that insight into whats going on it is difficult to see how a highly effective cache could be done at the geom layer. I think we are playing in a "captain obvious". I have nothing against statement that FS is a "best place for caching". Also - i am absolutely sure that its better to have kernel space fs driver then FUSE one. But unfortunately there is no kernel space driver for the exfat, kernel driver for ntfs is ugly and buggy (and r/o) and i don`t think that anyone is going to change this. And i really don`t understand why are you trying to tell that it cannot be effective when its so easy to proof that it can. Just try this with fuse based filesystems in Linux, and you will get speed compared to underlying device (especially on relatively slow USB devices). Then try the same code on FreeBSD to see how ugly things are. And yes, in ideal world ever fs needs to have good written cache implementation and kernel should not care about caching raw devices at all. But as i mentioned before - there is no kernel-space drivers with a good cache implementation for this 2 widely used systems (and probably not only). Linux is a good example that device-level caching works, and works fine. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: disk devices speed is ugly
On 02/15/2012 05:50 AM, Scott Long wrote: What would be nice is a generic caching subsystem that any FS can use - similar to the old block devices but with hooks to allow the FS to request read-ahead, advise of unwanted blocks and ability to flush dirty blocks in a requested order with the equivalent of barriers (request Y will not occur until preceeding request X has been committed to stable media). This would allow filesystems to regain the benefits of block devices with minimal effort and then improve performance& cache efficiency with additional work. Any filesystem that uses bread/bwrite/cluster_read are already using the "generic caching subsystem" that you propose. This includes UDF, CD9660, MSDOS, NTFS, XFS, ReiserFS, EXT2FS, and HPFS, i.e. every local storage filesystem in the tree except for ZFS. Not all of them implement VOP_GETPAGES/VOP_PUTPAGES, but those are just optimizations for the vnode pager, not requirements for using buffer-cache services on block devices. As Kostik pointed out in a parallel email, the only thing that was removed from FreeBSD was the userland interface to cached devices via /dev nodes. This has nothing to do with filesystems, though I suppose that could maybe sorta kinda be an issue for FUSE?. May be its possible to provide some generic interface for fuse based filesystems to use this generic cache? I can test it and report performance. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
cdcontrol close: Invalid argument
On one of my FreeBSD 9 machines, 'cdcontrol eject' works fine but 'cdcontrol close' fails. Any ideas on the cause? (I have never seen anything like this on other machines, in any FreeBSD release.) Starting from the closed tray and seeing a successful physical eject: dmesg > /tmp/d1; id -u; uname -r; for c in close eject close; do cmd="cdcontrol $c"; echo == $cmd; $cmd && echo 'OK' || echo 'not OK'; done; dmesg > /tmp/d2; diff /tmp/d1 /tmp/d2 0 9.0-STABLE == cdcontrol close cdcontrol: Invalid argument not OK == cdcontrol eject OK == cdcontrol close cdcontrol: Invalid argument not OK 618a619,626 > (cd0:ata0:0:0:0): START STOP UNIT. CDB: 1b 0 0 0 3 0 > (cd0:ata0:0:0:0): CAM status: SCSI Status Error > (cd0:ata0:0:0:0): SCSI status: Check Condition > (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) > (cd0:ata0:0:0:0): START STOP UNIT. CDB: 1b 0 0 0 3 0 > (cd0:ata0:0:0:0): CAM status: SCSI Status Error > (cd0:ata0:0:0:0): SCSI status: Check Condition > (cd0:ata0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
9-STABLE + Infiniband - incorrect interface counters
Hi, I'm playing with two FreeBSD 9-STABLE boxes connected via 10Gbps Infiniband (more details below) in Infiniband connected mode. I see incorrect interface statistics (e.g. in netstat output), output counters are 2x more than expected. EXAMPLE, ftp transfer of 1 GiB file: ftp> put file /dev/null local: file remote: /dev/null 229 Entering Extended Passive Mode (|||57978|) 150 Opening BINARY mode data connection for '/dev/null'. 100% |***| 953 MiB 390.43 MiB/s 00:00 ETA 226 Transfer complete. 10 bytes sent in 00:02 (390.13 MiB/s) Netstat on receiving side, counters are correct (for input): lexa@home-gw:/home/lexa# netstat -I ib1 5 input (ib1) output packets errs idrops bytespackets errs bytes colls 0 0 0 0 0 0 0 0 13955 0 0 222688126 9027 01192796 0 48921 0 0 780832960 32129 04240596 0 0 0 0 0 0 0 80 0 Sum of bytes (input) is 1003521086, as expected. Netstat on sending size, output is 2x more: lexa@new-gw:/home/lexa# netstat -I ib0 5 input (ib0) output packets errs idrops bytespackets errs bytes colls 1 0 0100 0 0 0 0 41162 0 02305210 62878 0 2008325984 0 1 0 0100 0 0 0 0 It looks like packet count is correct (13955+48921=62876, two packets missed somewhere), while byte count is exact 2x more. More details on my setup FreeBSD 9-STABLE, cvsuped today. One box is Core 2 Quad (Q9300), second one Core i7-920 1) Device MELLANOX MHEA28-XTC 10GBPS INFINIBAND HCA CARD (two port) Boot message: ib_mthca0: mem 0xfe90-0xfe9f,0xfd00-0xfd7f irq 16 at device 0.0 on pci1 ib_mthca: Mellanox InfiniBand HCA driver v1.0-ofed1.5.2 (August 4, 2010) Two cards connected via cable, no Infiniband switch 2) Kernel config: include GENERIC options OFED options SDP device ipoib options IPOIB_CM device mthca 3) Regardles of MTU settings (tried 16000, 32000, 48000), actual packed size in tcp flow is about 16000. Have not investigated it in details 4) There is no packet loss: lexa@new-gw:/home/lexa# ping -s 32000 -c 1 -f 10.1.1.1 PING 10.1.1.1 (10.1.1.1): 32000 data bytes . --- 10.1.1.1 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.157/0.225/1.758/0.156 ms -- Alex Tutubalin Web: http://blog.lexa.ru mailto:l...@lexa.ru ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: High load event idl.
On Sun, Apr 29, 2012 at 03:07:40PM +0300, Alexander Motin wrote: > On 04/29/12 15:04, Oliver Pinter wrote: > > Removing dummynet from kernel don't chanage anything, that is releated > > to load average. The loadavg hold to 0.70 +/- 0.2. (single user : sh + > > top) > > New ktr dump? I have similar issue on one of my laptops. Should I provide ktr dump? http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027133.html -- Adios ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: High load event idl.
On Sun, Apr 29, 2012 at 04:39:29PM +0300, Alexander Motin wrote: > On 04/29/12 16:30, Alex Kozlov wrote: > > On Sun, Apr 29, 2012 at 04:11:20PM +0300, Alexander Motin wrote: > >> On 04/29/12 15:27, Alex Kozlov wrote: > >>> On Sun, Apr 29, 2012 at 03:07:40PM +0300, Alexander Motin wrote: > >>>> On 04/29/12 15:04, Oliver Pinter wrote: > >>>>> Removing dummynet from kernel don't chanage anything, that is releated > >>>>> to load average. The loadavg hold to 0.70 +/- 0.2. (single user : sh + > >>>>> top) > >>>> > >>>> New ktr dump? > >>> I have similar issue on one of my laptops. Should I provide ktr dump? > >>> http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027133.html > >> In your case HPET also shares interrupt with other devices. I suspect > >> that may be a reason. Every time when swi thread runs loadavg, other CPU > >> runs shared interrupt handler, that is accounted as result. Please show > >> your verbose dmesg. > > Attached. > In your case HPET could solely use IRQ22 that seems free now. After > recent changes in ACPI code it is detected before PCI devices and so > doesn't avoids sharing. You may try to hint it specific IRQ by adding to > loader,conf line: > hint.hpet.0.allowed_irqs="0x0040" Thanks, it helped. Still it would be nice, if loadavg accounting was fixed. -- Adios ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: /usr/bin/unzip not being installed on 8.3-STABLE
On Tue, May 29, 2012 at 12:55:24PM +0800, Martin Wilke wrote: > Yes I can do that. It doesn't make sense to do exp-run before libarchive 3.04 MFV and premission patch for unzip will be commited. To many ports failures. > > +-oOO--(_)--OOo-+ > With best Regards, >Martin Wilke (miwi_(at)_FreeBSD.org) > > Mess with the Best, Die like the Rest > > On May 29, 2012, at 12:36 PM, Doug Barton wrote: > > > This needs more than diff-posting, it needs actual testing. By humans, > > and an -exp run. Since miwi is on the cc list, perhaps he can arrange it? > > > > Doug > > > > > > On 5/28/2012 10:59 AM, Jason Hellenthal wrote: > >> > >> Here is the unzip diff from stable/8 -> head > >> > >> On Mon, May 28, 2012 at 07:20:03PM +0200, Dag-Erling Smørgrav wrote: > >>> Jason Hellenthal writes: > >>>> Could someone MFC this to stable/8 please... > >>> > >>> Is unzip in stable/8 identical to unzip in head and stable/9? If not, > >>> this should be addressed first. Otherwise, there is a good chance that > >>> many ports will fail to build. -- Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Why Are You NOT Using FreeBSD ?
,--- Dave Hayes (Fri, 01 Jun 2012 17:12:14 -0700) * | 2) I don't use FreeBSD for a 'modern' desktop. By 'modern' I mean | areas which most rank and file users would need: day-to-day non | technical browsing with flash, applications like skype, syncing to | mobile devices, etc. First, two statements and one statement/question: S1. Flash works pretty well -- sometimes almost perfectly -- in FreeBSD: in Firefox, Opera or Chrome. Some software upgrades (the plugin in ports or base, I haven't figured out) lead to periodic hangs on (I think) plugin disconnects, so the plugin processes better to be cleaned up by 'kill' periodically. A nuisance but can be lived with, if FreeBSD seems a better option in other respects (which it does for me.) I visit scores of very "flashy" Web sites every day and am, on the balance, happy with what I get with either of the mentioned browsers in FreeBSD there. S2. I tried Skype in FreeBSD 9 a few months back and, IIRC, all there worked: at least I was able to use Skype for instant messaging. S3? Syncing to Ip*d and BB PlayBook is something I would really like to do in FreeBSD and I haven't figured out if that is possible. I played with "fuse", "gtkpod" and other things that work in Linux. No luck for me. So does anybody know if this is possible somehow? (After all, one can see these devices as SCSI "something". Is "fuse" of any good for this?) | I'd imagine this is important for rank and file users. However, I'm an | old schooler who likes text based applications and command lines, and I | personally feel that a lot of the desktop technologies out there (Gnome, | KDE, Aqua, Windows) are inherently unsafe (security wise) for a desktop | I do software development on. One glance at my X-mailer should tell many | people where I'm at. ;) You don't have to use anything of Gnome or KDE in order to use the technologies mentioned in my S1 and S2 -- I use TWM, for example. | Thus, in many ways I feel it's a *feature* of FreeBSD that the desktop | software lags behind everyone else. I don't want flash in my Firefox. I | don't want hal, bonjour, or dbus as an extra attack surface. I don't | want gnome to auto discover all the fileshares on my network(s). I don't run 'hal'; 'dbus' may be harder to avoid. It would be really nice to be able to talk to Apple and BB mobile devices from FreeBSD -- and that is my only current grievance about FreeBSD as a desktop environment. Everything else is shining brilliant for me. Thanks all who made it so! -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Is there known problem with USB flash readers?
Hi Guys! I have a strange problem with my flash card reader when dd'ing NanoBSD images onto a CF card. It works for some time (3-4 writes of images), then I start getting scsi error messages and dd hangs. I have to disconnect/re-connect the reader to be able to write to CF again, but sometimes even this trick doesn't work. One day it stopped working for me and since I had a deadline to meet, went to local shop and bought another one (different model and brand). It worked fine for few write iterations and then it developed the same problem. When I decided (out of desperation) to try the old one again, it worked. So, I ended up using the two and swapping between it when either of the units stopped working. First thing I though that it might be the size of the image (2 or 4GB) that I was writing with dd and it was heating up the electronics, but yesterday a friend of mine stumbled upon the same problem and when his flash reader (different brand and model to mine) stopped working, he unplugged it from the FreeBSD box, plugged it in into his Linux laptop and it worked without a problem. In his view it laid to rest my theory about components heating too much as he did it without giving it a minute of rest. I vaguely recall there were problems with USB support in stable some time ago, but I thought it was all fixed and searching the list and the Internet doesn't give me anything. Both of us were using 7-stable. I can email model of the card readers later (not home at the moment). Basically, I have two questions: 1) is it something that well known and not model related 2) is there a well known reliable model of card reader I can buy. I don't mind the price if the device is rock solid. Any pointers/ideas are greatly appreciated! Regards, Alex. -- "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." --- William Wilberforce PGP fingerprint: B030 9111 CE41 5C09 2710 E9E6 3120 F406 197B DA8E ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
SIGEPIPE after update to 8.1-RC2
Hi, stable After updating my buildbox from 26 April 8-STABLE to 8.1-RC2 I constantly getting SIGEPIPE portsnap: Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 0 metadata files... done. Fetching 27 patches.1020... done. Applying patches... done. Fetching 3 new ports or files... done. sort: write failed: standard output: Broken pipe sort: write error Removing old files and directories... done. sudo make -C /usr/ports/converters/ascii2binary: ===> Patching for ascii2binary-2.13_2 ===> Applying FreeBSD patches for ascii2binary-2.13_2 ===> ascii2binary-2.13_2 depends on shared library: intlgrep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe grep: writing output: Broken pipe - found ===> Configuring for ascii2binary-2.13_2 Does anyone know something about this issue? -- Adios ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SIGEPIPE after update to 8.1-RC2
On Sat, Jul 17, 2010 at 06:58:29PM +0200, Ronald Klop wrote: > Try rebuilding bash or sh or whatever you are using as shell. I'm not sure > though. I done only preliminary testing, but replacing /bin/sh by one from 8.0-RELEASE seems to help. Thanks. Now I will try to find particular commit that broke sh. -- Adios ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mysqld_safe holding open a pty/tty on FreeBSD (7.x and 8.x)
Jeremy Chadwick ha scritto: > Until rc(8) can be updated to support daemon(8) natively, This would be the Right Thing IMHO. > the ~76 ports > which Do The Wrong Thing(tm) should get updated to do it this way. Ones > like mysqlXX-server should be placed high on the priority list given > their popularity/importance. If you have an already tested patch for the mysql rc script, I'll commit it asap. -- Alex Dupre ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: VirtualBox OpenSolaris guest
,--- You/Harald (Fri, 8 Oct 2010 20:00:46 +0200) * | My hope to find an interim solution for the flashplayer nightmare | (while waiting for gnash) can be measured by the amount of hours | I've spent to get flash - easily and long-term-wise - playing on FreeBSD, | Ubuntu, PCBSD... | | I guess that FreeBSD will never be supported by Adobe. Flash works beautifully for me on FreeBSD 8.1 in both Firefox 3.6 (use the instructions at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/desktop-browsers.html) and in Opera (linux and native.) Is your problem "flash" or "audio" (i.e. can you play an mp3 file with mpg123, for example)? -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: VirtualBox OpenSolaris guest
,--- You/Harald (Sat, 9 Oct 2010 22:36:30 +0200) * | On Fri, Oct 08, 2010 at 02:34:11PM -0400, Alex Goncharov wrote: | > | I guess that FreeBSD will never be supported by Adobe. | > | > Flash works beautifully for me on FreeBSD 8.1 in both Firefox 3.6... | > and in Opera (linux and native.) | | Yes, I know that very well and used it with success many times. There is | a message exchange on the questions mailing list - "concerning flash | under freebsd" starting on last June 15 - which confirms my own | experience of ugly things like npviewer.bin coredumps and browser | freezing. Out of the box, with the current 8.1-STABLE and ports, Firefox 3.6 works pretty good with Flash -- the freezes have been rare for me. But it can freeze forever on some sites. The latest www/linux-opera (run on FreeBSD) absolutely sucks when working with flash and other plugins, on the other hand. www/opera won't work with flash (it seems first). But I've found a non-trivial solution which for me works better than either of "(any) Opera by itself" or "Firefox by itself". The solution is: * Install Firefox plugins through www/nspluginwrapper-devel: nspluginwrapper -v -a -i You'll get e.g. ~/.mozilla/plugins/npwrapper.libflashplayer.so * Use www/opera, for which (there are many bizarre pieces below, but they all turned out to be necessary in my experiments (the names of newly created files can vary, of course): ** Disable all plugin paths ** ln -s ~/.mozilla ~/mozilla ** cp ~/mozilla/plugins/npwrapper.libflashplayer.so ~/mozilla/plugins/npwrapper.mvflashplayer.so ** Add ~/mozilla/plugins to the plugins path ** Discover the new plugins. ** Use "opera:config / Extensions" to set "PluginResponseTimeout" (mine is 8 sec). Yes, you may hang on some URI's (and what do you do?) but only for a limited time and not having to kill your browser. There are sites which predictably had hung my www/linux-opera, every time -- forever. And I am now happily visiting them with www/opera. | I found the suggestion interesting to install VirtualBox and | OpenSolaris which is an operating system supported by Adobe. That's | the reason why I gave it a try. If you insist on using VirtualBox as your "browser solution", you'd be much much better off installing Debian as your guest. For audio, OpenSolaris sucks (and it sucks in many other ways, too.) Don't go there, that would be my advice -- it's has been a time sink and the source of constant frustration for me. | > Is your problem "flash" or "audio" (i.e. can you play an mp3 file with | > mpg123, for example)? | | "flash" installs like a charm. It's audio. There is no audio whatsoever | after a perfectly clean OpenSolaris guest installation. The guest cannot | determine the correct audio driver for the underlying audio card. | Needless to say that the audio card works for the FreeBSD host (still | on 8.0 for the moment). I'll repeat: OpenSolaris is a disaster with (some) audio drivers. And I had asked about your experience running audio on FreeBSD. If it works for you, try my Opera recipe above. -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: VirtualBox OpenSolaris guest
,--- You/Emil (Sun, 10 Oct 2010 04:42:17 +0200) * | > www/opera won't work with flash (it seems first). | | It works for me for years. Just install www/opera, | www/opera-linuxplugins, www/linux-f10-flashplugin10. Don't install any | www/nspluginwrapper* ports. Do you mean that in order www/opera to work with flash, one must not have www/nspluginwrapper installed? Or www/nspluginwrapper does not do any harm for www/opera? What version of www/opera are you running now? | > ** Use "opera:config / Extensions" to set "PluginResponseTimeout" | >(mine is 8 sec). | | I don't think it is necessary. I would be happy to learn how to make that unnecessary -- tried it all before ending up with my bizarre solution. So, tell me again, please: * You are running Flash inside the most recent www/(non-linux)opera, right? * What version of www/opera? I'll repeat your setup today, when we are clear what precisely you have done (provided you use www/opera from the most recent ports.) Thanks, -- Alex -- goncharov.a...@gmail.com -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: VirtualBox OpenSolaris guest
,--- You/Emil (Sun, 10 Oct 2010 16:41:39 +0200) * | www/opera and www/nspluginwrapper can coexist, but Opera should not use | nspluginwrapper-generated plugins. | | opera-10.61.6430 | opera-linuxplugins-10.61.6430 | linux-f10-flashplugin-10.1r85 ,--- Torfinn Ingolfsen (Sun, 10 Oct 2010 19:56:02 +0200) * | Aha, I was missing opera-linuxplugins. Installed now, seems to be | working fine. Very useful. Thanks! `* Ditto -- opera-linuxplugins is what I was missing; I had completely forgotten about it!... Years ago I had it (or so I think now) but Flash 10 didn't work, so I started to use linux-opera, which actually looked better than the native version, too. Happily used linux-opera until 10.61 came out, which having switched to a different UI toolkit turned out to be a pretty different animal... Ultimately I got tired of the flood of messages "syscall not implemented" and last weekend made the effort to make www/opera use linux plugins. Was successful but at the cost of that horrible setup; bizarre or not, I was happy with the www/opera's handling flash and most everything else. Fortunately, this topic was raised just a few days after, and you showed us the path. Thank you *very much*! (It only www/opera stopped crashing on File/Exit now...) -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: VirtualBox OpenSolaris guest
,--- Artem Belevich (Sun, 10 Oct 2010 23:21:19 -0700) * | | I think I've accidentally stumbled on a workaround for this crash on | exit issue. | | Once you've started opera and opened a page (any page), turn on print | preview on and off (Menu->Print->Print preview). Once it's done, opera | will exit cleanly. It beats me why print preview has anything to do | with exiting opera, but in my case it certainly does. Amazingly, that works for me, too -- thank you! | Another option is to delete liboperagtk.so once opera has been | installed. The downside is that file dialogs will be horrible. I | personally stick with the print preview workaround. Yeah, this workaround is quite tolerable -- in any case, the crash-on-exit is only a mild puzzling annoyance and I have every reason to believe that Opera folks will fix that soon (I, for one, clicked "Send the report" on crash more than once). ,--- Jakub Lach (Mon, 11 Oct 2010 04:32:39 -0700 (PDT)) * | | I think you are able to choose toolkit in opera:config. | | Was it -1 for plain X? For me, with liboperagtk.so in place, "opera:config / Preferences Editor" shows (after playing with Print Preview) 0. | Remedy for ugly file dialogs is skin with skinned ones. | | e.g. http://my.opera.com/community/customize/skins/info/?id=10071 This is an interesting link... I've never tried Opera skins... maybe I should... Thank you Artem and Jakub! -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: VirtualBox OpenSolaris guest
,--- You/Harald (Tue, 12 Oct 2010 21:56:29 +0200) * | www/opera built and installed quickly. I really like it, except for the | crash on exit. The workaround does apply for me as well. | | www/opera-linuxplugins stopped with | | ===> Installing for linux-f10-expat-2.0.1 | ===> Generating temporary packing list | brandelf: error opening file usr/bin/xmlwf: No such file or directory | *** Error code 1 Do you have this: kldstat | grep linux => 91 0x80c4b000 1ca6alinux.ko mount -p | grep /compat/linux => linprocfs /usr/compat/linux/proc linprocfs rw 0 0 | This is exactly the sort of problem I've encountered whenever I tried to | install all that linux stuff required just for the Flash plugin some weeks | after all other ports. I believe you need to figure these things out, Flash or not Flash. Looks like Linux compatibility issues; they should not be that hard to fix. Start with the basics: -- emulators/linux_base-f10 x11/linux-f10-xorg-libs textproc/linux-f10-aspell -- look at your logs, make sure that all installs correctly. -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Reproducible Kernel Panic on 8.1-STABLE [SEC=UNCLASSIFIED]
Hi all, I have come across a bug that triggers a kernel panic on 8.1-STABLE(r213395) through the use of /usr/ports/sysutils/fusefs-sshfs. Typically i do an sshfs mount as such: #sshfs usern...@hostname:/home/username local_mountpoint/ This mounts the remote filesystem fine. However, when i edit and save a file in say vi on the remote sshfs i get the following panic everytime: FreeBSD/amd64 (hostname.com) (ttyu0) login: Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xff80e9d1d9d0 frame pointer = 0x28:0xff80e9d1db50 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1749 (vim) trap number = 12 panic: page fault cpuid = 2 Uptime: 17m11s Physical memory: 8096 MB Dumping 1591 MB: It then seems to hang and not actually do a dump and i need to physically reset the box. If there is anything i can do to further assist in debugging please let me know. -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Reproducible Kernel Panic on 8.1-STABLE [SEC=UNCLASSIFIED]
0n Thu, Oct 14, 2010 at 02:13:27PM +0600, Sergey Nikolenko wrote: >On 14.10.2010 09:26, Wilkinson, Alex wrote: >> I have come across a bug that triggers a kernel panic on 8.1-STABLE(r213395) through the >> use of /usr/ports/sysutils/fusefs-sshfs. Typically i do an sshfs mount as such: >> >> #sshfs usern...@hostname:/home/username local_mountpoint/ >> >> This mounts the remote filesystem fine. However, when i edit and save a file in >> say vi on the remote sshfs i get the following panic everytime: > >Try this out >http://www.freebsd.org/cgi/query-pr.cgi?pr=149674 Yes! GREAT! This patch fixes the kernel panic! Can we get this committed ASAP ? -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Reproducible Kernel Panic on 8.1-STABLE [SEC=UNCLASSIFIED]
0n Thu, Oct 14, 2010 at 04:51:10PM +0800, Wilkinson, Alex wrote: >0n Thu, Oct 14, 2010 at 02:13:27PM +0600, Sergey Nikolenko wrote: > >>On 14.10.2010 09:26, Wilkinson, Alex wrote: >>> I have come across a bug that triggers a kernel panic on 8.1-STABLE(r213395) through the >>> use of /usr/ports/sysutils/fusefs-sshfs. Typically i do an sshfs mount as such: >>> >>> #sshfs usern...@hostname:/home/username local_mountpoint/ >>> >>> This mounts the remote filesystem fine. However, when i edit and save a file in >>> say vi on the remote sshfs i get the following panic everytime: >> >>Try this out >>http://www.freebsd.org/cgi/query-pr.cgi?pr=149674 > >Yes! GREAT! This patch fixes the kernel panic! Can we get this committed ASAP ? Committed! |--+--+--| | [ 12:44 beat ] Original commit message # | | | | | | | | ports/sysutils/fusefs-kmod/Makefile 1.31 diff | | | | ports/sysutils/fusefs-kmod/files/patch-fuse_module__fuse_main.c 1.1 | | | | | | | | - Fix panic on FreeBSD 8.x and newer | | | | - Bump PORTREVISION | | | | | | | | PR: ports/149674 | | | | Submitted by: Dmitrij Tejblum | | | | Approved by:Anish Mistry (maintainer) | | | |--+--+--| -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Reproducible Kernel Panic on 8.1-STABLE [SEC=UNCLASSIFIED]
0n Fri, Oct 15, 2010 at 04:27:51PM +0200, Ivan Voras wrote: >On 10/15/10 03:43, Wilkinson, Alex wrote: >> >> 0n Thu, Oct 14, 2010 at 04:51:10PM +0800, Wilkinson, Alex wrote: >> >> > 0n Thu, Oct 14, 2010 at 02:13:27PM +0600, Sergey Nikolenko wrote: >> > >> > >On 14.10.2010 09:26, Wilkinson, Alex wrote: >> > >> I have come across a bug that triggers a kernel panic on 8.1-STABLE(r213395) through the >> > >> use of /usr/ports/sysutils/fusefs-sshfs. Typically i do an sshfs mount as such: >> > >> >> > >> #sshfs usern...@hostname:/home/username local_mountpoint/ >> > >> >> > >> This mounts the remote filesystem fine. However, when i edit and save a file in >> > >> say vi on the remote sshfs i get the following panic everytime: >> > > >> > >Try this out >> > >http://www.freebsd.org/cgi/query-pr.cgi?pr=149674 >> > >> >Yes! GREAT! This patch fixes the kernel panic! Can we get this committed ASAP ? >> >> Committed! > >How stable is fuse & sshfs lately? It looks like every time in the past >I tried it I soon ended up panicking the system. since this patch it has been very stable so far! -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: VirtualBox OpenSolaris guest [becomes: linux-f10-expat]
,--- You/Harald (Mon, 18 Oct 2010 14:02:27 +0200) *
| What else could I possibly do?
| - portmaster www/opera-linuxplugins # installing linux_base-f10-10_3,
| then stopping as follows:
| ===> Installing for linux-f10-expat-2.0.1
| ===> Generating temporary packing list
| brandelf: error opening file usr/bin/xmlwf: No such file or directory
| *** Error code 1
| Stop in /usr/ports/textproc/linux-f10-expat.
I am not using portmaster; try do it simply through make. I just did
it now:
--
cat /compat/linux/etc/fedora-release
Fedora release 10 (Cambridge)
make -C textproc/linux-f10-expat deinstall clean configure build install
NOCLEANDEPENDS=yes
===> Deinstalling for textproc/linux-f10-expat
===> Deinstalling linux-f10-expat-2.0.1
===> Cleaning for linux-f10-expat-2.0.1
===> Vulnerability check disabled, database not found
===> License check disabled, port has not defined LICENSE
===> Extracting for linux-f10-expat-2.0.1
=> MD5 Checksum OK for rpm/i386/fedora/10/expat-2.0.1-5.i386.rpm.
=> SHA256 Checksum OK for rpm/i386/fedora/10/expat-2.0.1-5.i386.rpm.
===> linux-f10-expat-2.0.1 depends on file: /usr/local/bin/rpm2cpio - found
===> Patching for linux-f10-expat-2.0.1
===> Configuring for linux-f10-expat-2.0.1
===> Installing for linux-f10-expat-2.0.1
===> linux-f10-expat-2.0.1 depends on file: /compat/linux/etc/fedora-release
- found
===> Generating temporary packing list
===> Checking if textproc/linux-f10-expat already installed
cd /usr/ports/.x/amd64/usr/ports/textproc/linux-f10-expat/work && /usr/bin/find
* -type d -exec /bin/mkdir -p "/compat/linux/{}" \;
cd /usr/ports/.x/amd64/usr/ports/textproc/linux-f10-expat/work && /usr/bin/find
* ! -type d | /usr/bin/cpio -pm -R root:wheel /compat/linux
367 blocks
===> Running linux ldconfig
/compat/linux/sbin/ldconfig -r /compat/linux
===> Registering installation for linux-f10-expat-2.0.1
ls -l /compat/linux/usr/bin/xmlwf
-rwxr-xr-x 1 root wheel 20844 Oct 18 08:27 /compat/linux/usr/bin/xmlwf*
file /compat/linux/usr/bin/xmlwf
/compat/linux/usr/bin/xmlwf: ELF 32-bit LSB executable, Intel 80386, version 1
(GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
stripped
--
-- Alex -- alex-goncha...@comcast.net --
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kpanic on install >32GB of RAM [SEC=UNCLASSIFIED]
0n Mon, Oct 18, 2010 at 04:33:34AM -0700, Jeremy Chadwick wrote: >On Sun, Oct 17, 2010 at 03:10:06PM -0700, Sean Bruno wrote: >> >> > We've successfully installed RHEL 5u4 on it, I'll fire that up and post >> > the boot output shortly. >> > >> > Sean >> >> >> Perhaps this is something as simple as a hardware failure? HP DL980 >> looks sick, but I'm not sure. Here's the hardware logs, from the iLO on >> the box as screen scraping on the console is pointless as it's garbled >> too badly. >> >> Bad CPU, Bad Ram or other? >> >> http://people.freebsd.org/~sbruno/dl980_Machcheck_exceptions.png > >Hard to say -- the MCE will need to be decoded. I'm working on a >program which can do this, though I know John Baldwin already has one >which should work. Will it work something like http://freshmeat.net/projects/mcelog/ ? -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: VirtualBox OpenSolaris guest [becomes: linux-f10-expat]
,--- Ronald Klop (Tue, 19 Oct 2010 09:15:46 +0200) * | Alex, | | What does pkg_info -W /compat/linux/usr/bin/xmlwf say? Maybe | linux-f10-expat misses a dependency which you have installed already. | `--* -- pkg_info -W /compat/linux/usr/bin/xmlwf => /compat/linux/usr/bin/xmlwf was installed by package linux-f10-expat-2.0.1 -- That's what Harald could not build :-) ,--- Harald Weis (Tue, 19 Oct 2010 13:09:39 +0200) * | | > cat /compat/linux/etc/fedora-release | > Fedora release 10 (Cambridge) | | Ah, I see, that's it. I can't run this cat command because my | /compat/linux directory is empty. | Now I will go and reinstall for the third time all ports with | portmaster `cat ~/installed-port-list` which did work like a charm | last time and then install the linux ports with make. | `--* OK, good to know we've located a likely culprit. Good luck -- enjoy your working Flash on FreeBSD soon! -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED]
0n Wed, Nov 10, 2010 at 04:21:12AM -0800, Kirill Yelizarov wrote: >All my em cards running 8.1 stable don't reply to icmp echo requests packets larger than 1472 bytes. > >On stable 7.2 the same hardware works as expected: ># ping -s 1500 192.168.64.99 >PING 192.168.64.99 (192.168.64.99): 1500 data bytes >1508 bytes from 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms >1508 bytes from 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms > >Here is the dump on em interface >15:06:31.452043 IP 192.168.66.65 > *: ICMP echo request, id 28729, seq 5, length 1480 >15:06:31.452047 IP 192.168.66.65 > : icmp >15:06:31.452069 IP > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length 1480 >15:06:31.452071 IP *** > 192.168.66.65: icmp > >Same ping from same source (it's a 8.1 stable with fxp interface) to em card running 8.1 stable >#pciconf -lv >e...@pci0:3:4:0: class=0x02 card=0x10798086 chip=0x10798086 rev=0x03 hdr=0x00 >vendor = 'Intel Corporation' >device = 'Dual Port Gigabit Ethernet Controller (82546EB)' >class = network >subclass = ethernet > ># ping -s 1472 192.168.64.200 >PING 192.168.64.200 (192.168.64.200): 1472 data bytes >1480 bytes from 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms >^C > ># ping -s 1473 192.168.64.200 >PING 192.168.64.200 (192.168.64.200): 1473 data bytes >^C >--- 192.168.64.200 ping statistics --- >4 packets transmitted, 0 packets received, 100.0% packet loss works fine for me: FreeBSD 8.1-STABLE #0 r213395 e...@pci0:0:25:0:class=0x02 card=0x3035103c chip=0x10de8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Gigabit network connection (82567LM-3 )' class = network subclass = ethernet #ping -s 1473 host PING host(192.168.1.1): 1473 data bytes 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 time=31.506 ms 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 time=31.493 ms 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 time=31.550 ms ^C -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: New event timers for 8-STABLE [SEC=UNCLASSIFIED]
0n Fri, Nov 12, 2010 at 02:40:28AM +0200, Alexander Motin wrote: >I've created a patch, merging all kernel event timers related stuff from >HEAD to 8-STABLE. The only thing I have skipped at this moment was mips >architecture, because of too big code difference there between HEAD and >8-STABLE. Patch appeared to be quite large and includes more then 60 SVN >revisions from HEAD. I hope I haven't missed anything important. I would >like to ask interested people to test it. Patched code successfully >builds on all platforms and successfully runs on my amd64 test machine. > >In HEAD code seems to be working enough stable, There only two known >open issues at the moment: > - kernel freeze on XEN HVM when using LAPIC timer in one-shot mode -- >can be workarounded by switching to periodic mode or other timer. > - if HPET interrupt shared with other device, system load average may >lie (report +1 value) -- not a timer problem and not fatal. >Please report me if you find anything else. > >Latest patch can be found here: >http://people.freebsd.org/~mav/timers_merge/timers_merge-2010.patch > >Merge instructions (list of revisions, if somebody want to redo it): >http://people.freebsd.org/~mav/timers_merge/guide-2010 > >After patching you need just rebuild/reinstall the kernel. I haven't >merged related manual pages yet, so, if needed, consult with man pages >from HEAD: eventtimers(7), attimer(4), atrtc(4), hpet(4). patches apply cleanly but buildkernel fails: make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -march=nocona -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/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector cc: /usr/src/sys/kern/kern_et.c: No such file or directory cc: /usr/src/sys/kern/kern_clocksource.c: No such file or directory /usr/src/sys/dev/acpica/acpi_hpet.c:46:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/x86/local_apic.c:52:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/isa/atrtc.c:45:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/isa/clock.c:60:24: error: sys/timeet.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/obj/usr/src/sys/MARGS. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: www/chromium ignores proxy settings [SEC=UNCLASSIFIED]
0n Mon, Nov 22, 2010 at 02:19:32PM +, Tom Evans wrote: >On Mon, Nov 22, 2010 at 2:00 PM, Alexander Logvinov wrote: >> ??Use ??chrome --proxy-server="http://proxy:3128/"; :) >That didn't work either, it would not even make any connections then. >With '--proxy-server=proxy:3128' though, it works correctly! >It would still be nice to be able to set these options in the right >place in the gui, and have them work :) Try: --proxy-pac-url="http://proxy-server:port"; Work for me. -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
8.2-PRERELEASE: bsdtar does not recognise xz -z9 compression
Hi, stable Can anyone reproduce this? $uname FreeBSD 8.2-PRERELEASE #0: Thu Dec 23 10:11:09 i386 $cd /tmp $dd if=/dev/random of=junk bs=1024 count=1 1+0 records in 1+0 records out 1024 bytes transferred in 0.77 secs (13297112 bytes/sec) $tar cvf junk.tar junk a junk $xz -z9ck junk.tar >junk-z9.tar.xz $xz -ck junk.tar >junk.tar.xz $file junk.tar.xz junk-z9.tar.xz junk.tar.xz:XZ compressed data junk-z9.tar.xz: XZ compressed data $tar tvf junk.tar.xz -rw-r--r-- 0 kozlov kozlov 1024 Dec 23 10:52 junk $tar tvf junk-z9.tar.xz tar: Unrecognized archive format tar: Error exit delayed from previous errors. $xzcat junk.tar.xz>1 $xzcat junk-z9.tar.xz>2 $md5 -r junk.tar 1 2 d2f8de384f6dc1b3969c76ce7fe6ff00 junk.tar d2f8de384f6dc1b3969c76ce7fe6ff00 1 d2f8de384f6dc1b3969c76ce7fe6ff00 2 -- Adios ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2-PRERELEASE: bsdtar does not recognise xz -z9 compression
On Thu, Dec 23, 2010 at 02:30:34AM -0800, Jeremy Chadwick wrote: > On Thu, Dec 23, 2010 at 11:15:17AM +0200, Alex Kozlov wrote: >> Hi, stable >> >> Can anyone reproduce this? >> >> $uname >> FreeBSD 8.2-PRERELEASE #0: Thu Dec 23 10:11:09 i386 >> $cd /tmp >> $dd if=/dev/random of=junk bs=1024 count=1 >> 1+0 records in >> 1+0 records out >> 1024 bytes transferred in 0.77 secs (13297112 bytes/sec) >> $tar cvf junk.tar junk >> a junk >> $xz -z9ck junk.tar >junk-z9.tar.xz >> $xz -ck junk.tar >junk.tar.xz >> $file junk.tar.xz junk-z9.tar.xz >> junk.tar.xz:XZ compressed data >> junk-z9.tar.xz: XZ compressed data >> $tar tvf junk.tar.xz >> -rw-r--r-- 0 kozlov kozlov 1024 Dec 23 10:52 junk >> $tar tvf junk-z9.tar.xz >> tar: Unrecognized archive format >> tar: Error exit delayed from previous errors. >> $xzcat junk.tar.xz>1 >> $xzcat junk-z9.tar.xz>2 >> $md5 -r junk.tar 1 2 >> d2f8de384f6dc1b3969c76ce7fe6ff00 junk.tar >> d2f8de384f6dc1b3969c76ce7fe6ff00 1 >> d2f8de384f6dc1b3969c76ce7fe6ff00 2 > > I can reproduce this problem on RELENG_8 dated November 27th, with > libarchive.so.5 confirmed to be linked to liblzma.so.5. > > The problem happens with any xz compression level 7 or higher. Yes, bsdtar from STABLE (bsdtar 2.7.0 - libarchive 2.7.0) autodetects xz up to -z6 (default), bsdtar from CURRENT (bsdtar 2.8.3 - libarchive 2.7.901a) recognizes xz with any compression level. $ls -l junk.tar.xz junk-z9.tar.xz -rw-r--r-- 1 kozlov kozlov 1200 Dec 23 11:02 junk-z9.tar.xz -rw-r--r-- 1 kozlov kozlov 1200 Dec 23 11:02 junk.tar.xz $cmp -x junk.tar.xz junk-z9.tar.xz 0010 16 1c 0014 74 10 0015 2f cf 0016 e5 58 0017 a3 cc -- Adios ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2-PRERELEASE: bsdtar does not recognise xz -z9 compression
Hi, stable
Possible fix for this issue. (MFC r201167):
--
Adios
Index: lib/libarchive/archive_read_support_compression_xz.c
@@ -48,6 +48,7 @@
#endif
#include "archive.h"
+#include "archive_endian.h"
#include "archive_private.h"
#include "archive_read_private.h"
@@ -205,37 +206,100 @@
{
const unsigned char *buffer;
ssize_t avail;
+ uint32_t dicsize;
+ uint64_t uncompressed_size;
int bits_checked;
(void)self; /* UNUSED */
- buffer = __archive_read_filter_ahead(filter, 6, &avail);
+ buffer = __archive_read_filter_ahead(filter, 14, &avail);
if (buffer == NULL)
return (0);
- /* First byte of raw LZMA stream is always 0x5d. */
+ /* First byte of raw LZMA stream is commonly 0x5d.
+* The first byte is a special number, which consists of
+* three parameters of LZMA compression, a number of literal
+* context bits(which is from 0 to 8, default is 3), a number
+* of literal pos bits(which is from 0 to 4, default is 0),
+* a number of pos bits(which is from 0 to 4, default is 2).
+* The first byte is made by
+* (pos bits * 5 + literal pos bit) * 9 + * literal contest bit,
+* and so the default value in this field is
+* (2 * 5 + 0) * 9 + 3 = 0x5d.
+* lzma of LZMA SDK has options to change those parameters.
+* It means a range of this field is from 0 to 224. And lzma of
+* XZ Utils with option -e records 0x5e in this field. */
+ /* NOTE: If this checking of the first byte increases false
+* recognition, we should allow only 0x5d and 0x5e for the first
+* byte of LZMA stream. */
bits_checked = 0;
- if (buffer[0] != 0x5d)
- return (0);
- bits_checked += 8;
-
- /* Second through fifth bytes are dictionary code, stored in
-* little-endian order. The two least-significant bytes are
-* always zero. */
- if (buffer[1] != 0 || buffer[2] != 0)
+ if (buffer[0] > (4 * 5 + 4) * 9 + 8)
return (0);
- bits_checked += 16;
-
- /* ??? TODO: Fix this. ??? */
- /* NSIS format check uses this, but I've seen tar.lzma
-* archives where this byte is 0xff, not 0. Can it
-* ever be anything other than 0 or 0xff?
-*/
-#if 0
- if (buffer[5] != 0)
+ /* Most likely value in the first byte of LZMA stream. */
+ if (buffer[0] == 0x5d || buffer[0] == 0x5e)
+ bits_checked += 8;
+
+ /* Sixth through fourteenth bytes are uncompressed size,
+* stored in little-endian order. `-1' means uncompressed
+* size is unknown and lzma of XZ Utils always records `-1'
+* in this field. */
+ uncompressed_size = archive_le64dec(buffer+5);
+ if (uncompressed_size == (uint64_t)ARCHIVE_LITERAL_LL(-1))
+ bits_checked += 64;
+
+ /* Second through fifth bytes are dictionary size, stored in
+* little-endian order. The minimum dictionary size is
+* 1 << 12(4KiB) which the lzma of LZMA SDK uses with option
+* -d12 and the maxinam dictionary size is 1 << 27(128MiB)
+* which the one uses with option -d27.
+* NOTE: A comment of LZMA SDK source code says this dictionary
+* range is from 1 << 12 to 1 << 30. */
+ dicsize = archive_le32dec(buffer+1);
+ switch (dicsize) {
+ case 0x1000:/* lzma of LZMA SDK option -d12. */
+ case 0x2000:/* lzma of LZMA SDK option -d13. */
+ case 0x4000:/* lzma of LZMA SDK option -d14. */
+ case 0x8000:/* lzma of LZMA SDK option -d15. */
+ case 0x0001:/* lzma of XZ Utils option -0 and -1.
+* lzma of LZMA SDK option -d16. */
+ case 0x0002:/* lzma of LZMA SDK option -d17. */
+ case 0x0004:/* lzma of LZMA SDK option -d18. */
+ case 0x0008:/* lzma of XZ Utils option -2.
+* lzma of LZMA SDK option -d19. */
+ case 0x0010:/* lzma of XZ Utils option -3.
+* lzma of LZMA SDK option -d20. */
+ case 0x0020:/* lzma of XZ Utils option -4.
+* lzma of LZMA SDK option -d21. */
+ case 0x0040:/* lzma of XZ Utils option -5.
+* lzma of LZMA SDK option -d22. */
+ case 0x0080:/* lzma of XZ Utils option -6.
+* lzma of LZMA SDK option -d23. */
+ case 0x0100:/* lzma of XZ Utils option -7.
+* lzma of LZMA SDK option -d24. */
+ case 0x0200:/* lzma of XZ Utils option -8.
+* lzma of LZMA SDK option -d25. */
+ case 0x0400:/* lzma of XZ Utils option -9.
+* lzma of LZMA SDK option -d26. */
+ case 0x0800:/* lzma of LZMA SDK option -d27. */
+ bits_checked += 32;
+ break;
+ default:
+
Re: 8.2-PRERELEASE and Flash
[ Suggest not to cc: freebsd-stable@ from this point on; freebsd-ports@ is added ] ,--- You/ben (Tue, 04 Jan 2011 15:16:26 +) * | I've followed the steps at | http://www.freebsd.org/doc/handbook/desktop-browsers.html without any | errors, except that neither Firefox nor any other browser will play | flash movies. about:plugins doesn't show a flash plugin. | I've spent a while googling and all I can find is variations on the | instructions from the handbook. I don't know where to start looking for | the problem. I play Flash in Firefox, (native) Opera and Chrome -- perfectly now. For Firefox, the instructions in the Handbook worked for me. | I'd be really grateful to whoever could point me in the right direction. Search freebsd-ports@ for "opera", "flash" and my name -- I was a part of a conversation about it, some three months ago. Running Opera with -debugplugin helps. -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Groff in FreeBSD
I am trying to refresh my old groff skills, playing with it for the
first time on FreeBSD -- and getting very confused with understanding
groff's place and organization here. (I am writing this on FreeBSD 7.0
but I could start an 8.0 system if somebody suggested to take a look
there).
Let's start with the practical end of it: I wanted to find a good
macro package, good by modern standards. In the past, I've tried 'mm',
'ms', 'me' -- and could never decide which one was the most practical
one (well, 'mm', perhaps). These days, it seems like 'mom' is a
popular package, worth a serious attention.
So, I am trying to see if 'mom' is available on my system, and it is
not.
I do various online searches, and the only thing that comes up is:
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2003-11/0407.html
groff macro package 'mom' not installed
Date: 11/24/03
(and similar entries)
'mom' is, of course, in the source tree:
ls -ld /usr/src/contrib/groff/contrib/mom
drwxr-xr-x 4 root wheel 512 Mar 26 19:30
/usr/src/contrib/groff/contrib/mom/
as is 'mm':
ls -ld /usr/src/contrib/groff/contrib/mm
drwxr-xr-x 4 root wheel 512 Mar 26 19:29 /usr/src/contrib/groff/contrib/mm/
But while the latter has "tmac" files installed:
ls /usr/share/tmac/mm*
0.MT 4.MT 5.MT locale mm.tmacmmse.tmac ms.cov
se_locale se_ms.cov
the former does not:
ls /usr/share/tmac/mom*
ls: /usr/share/tmac/mom*: No such file or directory
So, I try to build something relevant by hand, and nothing good comes
out of it. But I notice that the '/usr/src/contrib/groff/contrib/mm'
directory is not the only place for 'mm' -- there is also
ls -ld /usr/src/gnu/usr.bin/groff/contrib/mm
drwxr-xr-x 2 root wheel 512 Aug 10 17:48
/usr/src/gnu/usr.bin/groff/contrib/mm/
which is a built entity.
At this point, I begin not care about having 'mom' -- I just want to
understand the groff organization in FreeBSD.
Things that puzzle me:
1. Under '/usr/obj', there is a 'tmp/legacy' directory, which has an
empty 'mm' directory deep down:
find tmp/legacy/usr/share/tmac/mm -ls
5184624 drwxr-xr-x2 root wheel 512
Aug 9 23:05 tmp/legacy/usr/share/tmac/mm
What is this 'tmp/legacy'?
2. There is an odd relationship between "tmac" files under '/usr/src'
and '/usr/obj':
for cmd in "ls -l" "diff -q"; do for f in pic.tmac doc.tmac; do $cmd
/usr/src/contrib/groff/tmac/$f /usr/obj//usr/src/tmp/legacy/usr/share/tmac/$f;
done; done
-rwxr-xr-x 1 root wheel 117 Apr 17 2001
/usr/obj/i386/x01/freebsd/7.0/usr/src/tmp/legacy/usr/share/tmac/pic.tmac
-rw-r--r-- 1 root wheel 117 Apr 17 2001 /usr/src/contrib/groff/tmac/pic.tmac
-rwxr-xr-x 1 root wheel 73079 Aug 9 23:05
/usr/obj/i386/x01/freebsd/7.0/usr/src/tmp/legacy/usr/share/tmac/doc.tmac
-rw-r--r-- 1 root wheel 148585 Oct 20 2005
/usr/src/contrib/groff/tmac/doc.tmac
Files /usr/src/contrib/groff/tmac/doc.tmac and
/usr/obj/i386/x01/freebsd/7.0/usr/src/tmp/legacy/usr/share/tmac/doc.tmac differ
I.e. some files under '/usr/obj' are regenerated (see "Aug 9" for
'doc.tmac'), and others are not ('pic.mac'). Some files are
identical in both places, and others are not.
What is the logic and mechanics here?
Can anybody shed some light on this?
And also, if somebody had a recommendation on the most practical
choice of the macro package, it would be highly appreciated.
Thank you,
-- Alex -- [EMAIL PROTECTED] --
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Groff is not working in the latest code
The following happens in 7.0-STABLE built from the source "csup"ed
either yesterday's or this morning:
$ groff -mm -t -Tascii tmp.mm
groff: can't find `DESC' file
groff:fatal error: invalid device `ascii'
$ truss -mm -t -Tascii tmp.mm 2>&1 | grep DESC
++ [ ~/doc1/employ/ab-initio ] ++
truss groff -mm -t -Tascii tmp.mm 2>&1 | grep DESC
open("/usr/local/share/groff/site-font/devascii/DESC",O_RDONLY,0666)
ERR#2 'No such file or directory'
open("/usr/local/share/groff/1.19.2/font/devascii/DESC",O_RDONLY,0666)
ERR#2 'No such file or directory'
open("/usr/lib/font/devascii/DESC",O_RDONLY,0666) ERR#2 'No such file
or directory'
groff: can't find `DESC' file
write(2,"groff: can't find `DESC' file\n",30)= 30 (0x1e)
$ ls -l /usr/share/groff_font/devascii/DESC
-r--r--r-- 1 root wheel 95 Aug 18 08:59
/usr/share/groff_font/devascii/DESC
$ GROFF_FONT_PATH=/usr/share/groff_font groff -mm -t -Tascii tmp.mm
troff: fatal error: can't find macro file m
$ which groff
/usr/bin/groff
Note an attempt to look for a file under /usr/local, which should not
happen for a program in "base".
This behavior is very new -- no such problem existed in the code
fetched last Saturday. There, I see:
$ truss groff -mm -t -Tascii tmp.mm 2>&1 | grep DESC
open("/usr/share/groff_font/devascii/DESC",O_RDONLY,0666) = 3 (0x3)
Anybody know of what happened?
Thanks,
-- Alex -- [EMAIL PROTECTED] --
/*
* Machines that have broken down will work perfectly when the
* repairman arrives.
*/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
An oops [Re: Groff is not working in the latest code]
Oops, scratch (do not see) this piece in my previous message: ,--- I/Alex (Mon, 18 Aug 2008 11:09:10 -0400) * | $ truss -mm -t -Tascii tmp.mm 2>&1 | grep DESC | ++ [ ~/doc1/employ/ab-initio ] ++ `-* Thanks, -- Alex -- [EMAIL PROTECTED] -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Another attempt [Re: Groff is not working in the latest code]
`groff' is still not working for me, and with it `man' doesn't:
$ uname -srv
FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #34: Tue Aug 26 18:14:46 EDT
2008...
$ man man
/usr/bin/groff: can't find `DESC' file
/usr/bin/groff:fatal error: invalid device `ascii'
I may have found some clues -- jump to under the quoted (and trimmed)
message -- but I still can't make it build right, and am wondering if
this is really only my personal issue and everybody else can use "man"
all right...
(I do the update/rebuild daily now.)
,--- I/Alex (Mon, 18 Aug 2008 11:09:10 -0400) *
|
| The following happens in 7.0-STABLE built from the source "csup"ed
| either yesterday's or this morning:
|
|
| $ truss -mm -t -Tascii tmp.mm 2>&1 | grep DESC
| truss groff -mm -t -Tascii tmp.mm 2>&1 | grep DESC
| open("/usr/local/share/groff/site-font/devascii/DESC",O_RDONLY,0666)
| groff: can't find `DESC' file
| write(2,"groff: can't find `DESC' file\n",30)= 30 (0x1e)
|
| $ ls -l /usr/share/groff_font/devascii/DESC
| -r--r--r-- 1 root wheel 95 Aug 18 08:59
| /usr/share/groff_font/devascii/DESC
|
|
|
| Note an attempt to look for a file under /usr/local, which should not
| happen for a program in "base".
|
| This behavior is very new -- no such problem existed in the code
| fetched last Saturday. There, I see:
|
|
| $ truss groff -mm -t -Tascii tmp.mm 2>&1 | grep DESC
| open("/usr/share/groff_font/devascii/DESC",O_RDONLY,0666) = 3 (0x3)
|
|
`-*
So, I looked at how things are being built and think that the
following is supposed to happen with respect to `groff' -- a GNU
program:
1. The build is driven by `gnu/usr.bin/groff/Makefile' (all paths in
the following are relative to `/usr/src'.
2. During the build, the original "contrib" code is used, to be found
in `contrib/groff'.
That code is configured by the pristine `contrib/groff/configure'
and results in setting the "prefix" to the GNU-usual `/usr/local'
and generating the FreeBSD-unaware `defs.h' and `config.h'.
3. Then some magic "is supposed to happen / was happening two weeks
ago for me", when the newly generated `defs.h' and `config.h' are
replaced with the FreeBSD hard versions that had been delivered
from CVS -- and the paths get corrected to eliminate the `local'
component from them and do other path adjustments to bring it all
to the FreeBSD standards:
$ diff contrib/groff/src/include/defs.h gnu/usr.bin/groff/src/include/defs.h |
head -n 12
0a1,2
> /* $FreeBSD: src/gnu/usr.bin/groff/src/include/defs.h,v 1.4 2001/04/17
> 12:37:07 ru Exp $ */
>
3,6c5,7
< #define INSTALLPATH "/usr/local"
< #define BINPATH "/usr/local/bin"
< #define FONTPATH
"/usr/local/share/groff/site-font:/usr/local/share/groff/1.19.2/font:/usr/lib/font"
< #define MACROPATH
"/usr/local/lib/groff/site-tmac:/usr/local/share/groff/site-tmac:/usr/local/share/groff/1.19.2/tmac"
---
> #define BINPATH "/usr/bin"
> #define FONTPATH "/usr/share/groff_font"
> #define MACROPATH "/usr/share/tmac"
$ diff contrib/groff/src/include/config.h
gnu/usr.bin/groff/src/include/config.h
0a1,2
> /* $FreeBSD: src/gnu/usr.bin/groff/src/include/config.h,v 1.5 2005/10/20
> 10:57:52 ru Exp $ */
>
4. Then the build happens with whatever `defs.h' and `config.h' will
be found at that time under `contrib/groff/src/include'.
If the step 3 worked before but is not working now, it explains my
current end results.
But how about others: everything works for you? What could have
triggered the change in the process for me a week or so ago?
Anybody is able and willing to lead me out of my lasting misery?
Thanks,
-- Alex -- [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: Another attempt [Re: Groff is not working in the latest code]
The bottom line: the problem is solved -- thank you! The details below... ,--- You/Yuri (Wed, 27 Aug 2008 08:13:14 +0400) * | Alex Goncharov wrote: | > `groff' is still not working for me, and with it `man' doesn't: | > | > So, I looked at how things are being built and think that the | > following is supposed to happen with respect to `groff' -- a GNU | > program: | > | > 1. The build is driven by `gnu/usr.bin/groff/Makefile' (all paths in | >the following are relative to `/usr/src'. | > | > 2. During the build, the original "contrib" code is used, to be found | >in `contrib/groff'. | > | >That code is configured by the pristine `contrib/groff/configure' | >and results in setting the "prefix" to the GNU-usual `/usr/local' | >and generating the FreeBSD-unaware `defs.h' and `config.h'. | | contrib/groff/configure shouldn't be called at all, Let me ask you here: what should be called then? Note this for the make file there: $ cat contrib/groff/Makefile [snip] all: $(SHELL) configure $(MAKE) all | looks like there's something wrong with your local build | environment. This is what I was trying to find: the same environment hadn't given me trouble for more than a year, till about August 15 -- and leads to a good build this morning. Why would my environment matter for a standard build, however? Which part of it? | > 3. Then some magic "is supposed to happen / was happening two weeks | >ago for me", when the newly generated `defs.h' and `config.h' are | >replaced with the FreeBSD hard versions that had been delivered | >from CVS -- and the paths get corrected to eliminate the `local' | >component from them and do other path adjustments to bring it all | >to the FreeBSD standards: | > | > | > $ diff contrib/groff/src/include/defs.h gnu/usr.bin/groff/src/include/defs.h | head -n 12 | yuri:/usr/src> diff -u contrib/groff/src/include/defs.h | gnu/usr.bin/groff/src/include/defs.h | diff: contrib/groff/src/include/defs.h: No such file or directory When I saw this, and combining this with your statement that `contrib/groff/configure' was not supposed to be called, I realized that, in fact, yesterday I ran it by hand, trying to figure out what was going on -- and I thought it had to be called by the standard build. So, seeing your output, I removed both `contrib/groff' and `gnu/usr.bin/groff', did `cvsup' again and rebuild. And guess what? The newly built groff doesn't look for files under `/usr/local' -- so it's definitely using the hard-coded` gnu/usr.bin/groff/src/include/defs.h' paths. I install worlds and now have a perfectly functioning `groff' and `man'. | > But how about others: everything works for you? What could have | > triggered the change in the process for me a week or so ago? | | `man man` works for me on 7.0-RELEASE with groff built from RELENG_7 | src. | HTH, It did help enormously -- just a simple knowledge that `groff' works for you and comparing the small notes. (But it's still a mystery for me why I was having bad builds for two weeks -- what led me in, and what led me out of the trouble. And the build process for `groff' remains a puzzle for me... Will try to understand it better...) Thank you very much! -- Alex -- [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: WARNING: 7-STABLE BROKEN -- please wait to upgrade
,--- You/Kostik (Wed, 27 Aug 2008 19:04:32 +0300) * | cd into /usr/src/gnu/usr.bin/cc/cc1, | and do | make install DEBUG_FLAGS=-g That simple thing didn't work for me: make install DEBUG_FLAGS=-g install -o root -g wheel -m 555 cc1 /usr/libexec install: cc1: No such file or directory *** Error code 71 I updated and installed world this morning -- and indeed had this gcc: Internal error: Abort trap: 6 (program cc1) while compiling something, as a result. But I've found what may be an extremely easy way out of this hole: I copied over /usr/libexec/cc1 from another machine, which had a code built on Aug 17. Then my `cc1' worked fine and I tripped on a SEGV in `as'. Then I copied over `as', then `ld', then `gcc'. And that was it -- the build began to work. So if anybody wants it, I can just send a package with these four executables, to be deployed in place of the broken ones. Let me know... -- Alex -- [EMAIL PROTECTED] -- /* * The end of the world will occur at 3:00 p.m., this Friday, with * symposium to follow. */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WARNING: 7-STABLE BROKEN -- please wait to upgrade
Still having problems... ,--- I/Alex (Wed, 27 Aug 2008 20:42:00 -0400) * | ,--- You/Kostik (Wed, 27 Aug 2008 19:04:32 +0300) * | | cd into /usr/src/gnu/usr.bin/cc/cc1, | | make install DEBUG_FLAGS=-g | | That simple thing didn't work for me: | But I've found what may be an extremely easy way out of this hole: I | copied over /usr/libexec/cc1 from another machine, which had a code | built on Aug 17. Then my `cc1' worked fine and I tripped on a SEGV in | `as'. Then I copied over `as', then `ld', then `gcc'. And that was | it -- the build began to work. `-* I have been happily using the four replacement tools to build various user-land programs. Then yesterday I decided to try to update the OS. The build finished successfully (or so it seemed), I rebooted, installed world, and now I have the same issue as everybody else had this week: cc: Internal error: Abort trap: 6 (program cc1) $ ls -l /usr/libexec/cc1 -r-xr-xr-x 1 root wheel 5435068 Aug 31 09:03 /usr/libexec/cc1* $ uname -svr FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #36: Sun Aug 31 00:08:48 EDT 2008 I am going to replace the four cc components again, with the old and tried ones, and update/build again, but this doesn't feel right. Is there anything else I should have done to avoid these problems? Is everything supposed to work out of box now? Thanks, -- Alex -- [EMAIL PROTECTED] -- /* * Progress was all right. Only it went on too long. * * -- James Thurber */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: WARNING: 7-STABLE BROKEN -- please wait to upgrade
,--- You/John (Sun, 31 Aug 2008 22:36:36 +) * | If you still have the obj tree from the problem build, there are two things | you can do: | | 1. make STRIP= installworld Thank you -- that's good to know, for the future. For now, I updated again and using my saved "four cc tools kit" rebuilt the world and kernel. After another reboot everything was fine -- I can use the new `cc' all right now. | or | | 2. Delete the obj tree before building anything new. | | > Is everything supposed to work out of box now? | | Yes, but an obj tree from a broken build will cause problems. That's a bit strange: 1. What in it could cause problems? Doesn't `buildworld' clean out everything in the `obj' tree, other than the "build counter"? 2. I did my rebuild (after the message I sent out this morning), without touching `obj' by hand -- and everything came out all right. (Just wondering) Thank you, -- Alex -- [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: WARNING: 7-STABLE BROKEN -- please wait to upgrade
,--- You/John (Sun, 31 Aug 2008 23:35:38 +) * | It's supposed to, but I don't trust it. There is no substitute for | a rm -rf of the obj tree. That's also quicker. Ah, OK... | Sorry about the problems. Oh, no problem at all -- I learned a lot as a result. Just wanted to make sure I understand the state of affairs and ways to act. Thank you! -- Alex -- [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: Request for testing - top 3.8b1 in the base system
Edwin Groothuis пишет: I have made an update for the top(1) utility in the FreeBSD base system to get it from the 3.5b12 version to the 3.8b1 version. I have tried them on the amd64 architecture on FreeBSD -current and FreeBSD 7.0 and on the i386 architecture on FreeBSD 7.0. The big new features are a line upper part with kernel statistics (context-switches, traps, interrupts, faults etc) and the FLG table (if you window is big enough) Some features specific to FreeBSD (dual display (press m)), threaded processes, and jails have been ported to 3.8b1. The biggest fix (AFAICT) is the TIME and CPU table for threaded processes, which are now calculated properly. The new code can be found on http://www.mavetju.org/~edwin/freebsd-top-3.8b1-A.tar.gz Go to 3.8b1/usr.sbin/top and run "make" there to produce the binary, then run it via "./top". Please report any issues with it (compile time, run time) and a way to reproduce it (if possible). Thanks for your help! Edwin Some strange. Count running processes not match with system top = system top = last pid: 30285; load averages: 0.99, 0.91, 0.91 up 0+21:08:49 12:10:40 45 processes: 2 running, 43 sleeping CPU: 24.3% user, 0.0% nice, 1.3% system, 0.0% interrupt, 74.4% idle Mem: 236M Active, 1693M Inact, 414M Wired, 137M Cache, 214M Buf, 5187M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 87008 root 1 80 58728K 43028K wait 0 0:05 0.00% ruby18 87002 root 1 440 5688K 1124K select 2 0:02 0.00% script 1168 root 1 440 22872K 4308K select 3 0:01 0.00% sshd 30284 root 1 970 97420K 90844K CPU1 1 0:01 0.00% cc1plus 721 root 1 440 10696K 4000K select 0 0:01 0.00% sendmail 86980 lissyara 1 440 33764K 4840K select 2 0:00 0.00% sshd 584 root 1 440 5688K 1364K select 2 0:00 0.00% syslogd 733 root 1 80 6744K 1436K nanslp 0 0:00 0.00% cron 52451 lissyara 1 440 33764K 4840K select 0 0:00 0.00% sshd new top == last pid: 30280; load avg: 0.99, 0.91, 0.91; up 0+21:08:48 12:10:39 99 processes: 6 running, 76 sleeping, 17 waiting CPU: 23.6% user, 0.0% nice, 1.9% system, 0.0% interrupt, 74.5% idle Kernel: 4192 ctxsw, 21398 trap, 4 intr, 1000 soft, 4 fork, 21427 flt, 26140 fr Mem:239M Active, 1693M Inact, 414M Wired, 137M Cache, 214M Buf, 5184M Free Swap: 4096M Total, 4096M Free PID USERNAME THR PRI NICE SIZE RES STATE FLG C TIMECPU COMMAND 30279 root 1 980 97M 91M CPU1 + 1 0:01 48.94% cc1plus 30280 root 1 -80 2176K 1688K piperd + 0 0:00 0.14% as 30277 root 1 80 7060K 1884K wait + 1 0:00 0.06% sh 30278 root 1 80 4600K 1284K wait + 0 0:00 0.06% c++ 30245 root 1 440 8112K 2220K select + 0 0:00 0.04% top 30219 root 1 440 8112K 2284K CPU2 + 2 0:00 0.02% top 86980 lissyara 1 440 33M 4840K select 2 0:00 0.01% sshd 29472 root 1 80 3200K 1392K wait + 3 0:00 0.01% make 87008 root 1 80 57M 42M wait + 0 0:05 0.00% ruby18 87002 root 1 440 5688K 1124K select + 2 0:02 0.00% script 1168 root 1 440 22M 4308K select s 3 0:01 0.00% sshd == FreeBSD serv2.hos-ting.ru 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Sat Sep 27 14:50:59 MSD 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HOSTING amd64 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Samsung SCX-4200 printer
On Mon, Jan 05, 2009 at 11:26:23PM +0100, Roland Smith wrote: > On Mon, Jan 05, 2009 at 05:44:03PM +0100, Erwan David wrote: > > On Mon, Jan 05, 2009 at 05:36:35PM CET, Torfinn Ingolfsen > > said: > > > On Sun, 04 Jan 2009 23:14:22 +0100 > > > Harald Weis wrote: > > > > > > > Is there a way to install the SCX-4200 printer on a FreeBSD box ? > > > > The printer is delivered with the install software required for Linux. > > > > And CUPS does not seem to "know" it. > > It is not always sufficient. My Brother DCP-540 CN is said to work > > perfectly, but only with brother binary linux drivers, under linux. I > > did not find any way to make it work under freeBSD. > > This should be a FAQ: do yourself a favor and get a printer that > supports postscript. It will work with little effort with most > UNIX-based program (because they usually support postscript output) and > with most spoolers. Try to install the cupsys, cupsys-bsd, cupsomatic-ppd and foomatic-db ports and take a look at this link: http://forums.linux-foundation.org/read.php?31,302,320,quote=1 -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Samsung SCX-4200 printer
,--- You/Harald (Thu, 8 Jan 2009 12:11:27 +0100) * | > Try to install the cupsys, cupsys-bsd, cupsomatic-ppd and foomatic-db | > ports and take a look at this link: | | None of these exist in the FreeBSD port index (/usr/ports/INDEX-7) So, you've now looked :-) I've had good experience with foomatic use for most various printers in the past and wanted to give you a pointer to that package, no promises, since you didn't seem to be familiar it. I didn't have the printing packages installed in the machine I sent the original mail from, so could not check the correct package names -- I can check what I have now: $ pkg_info -L foomatic-db-20070124_1| grep -ic samsung 62 $ pkg_info -L foomatic-db-20070124_1| grep -ic scx 0 So, that printer is not yet in BSD foomatic-db. | >http://forums.linux-foundation.org/read.php?31,302,320,quote=1 | | Refers only to Linux :-( I know -- but I often used Linux-based advice as a clue for solving printing problems on FreeBSD. Sorry this didn't help you (and I am sure you saw this http://www.openprinting.org/show_printer.cgi?recnum=Samsung-SCX-4200). -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/Dan (Wed, 28 Jan 2009 20:39:10 -0700) * | > While this enabled the mouse (without HAL), it did nothing good about: | > | >a. The bogus keyboard scans. You are quoting me and I need to clarify... | Everyone is talking about an xorg.conf | The new X.org 7.4 upgrade hit me too: no keyboard & no mouse! Bummer. | I found that if I simply added to /etc/rc.conf: |hald_enable="YES" | that things now work for me. | Previously I never have had hald in my rc.conf. | Hope this helps. `--* My worst case is not HAL-related: I had the same behavior with or without HAL, and the behaviour was, e.g.: * I press the keys "TAB q w" over an `xev' window and see the bogus key scan codes -- nothing related to the pressed keys. * In a moment the xev-monitoring xterm window shows a non-stopping flow of events, even though I am not touching anything on the computer. * With some combination of a few key presses over the `xterm' window, suddenly a long stream of `2's appears. Or `z'. Or something else, unrelated to the keys I had pressed. There has been nothing of this sort on my desktop, where I am typing this message -- so, I think I know how to configure X :-). On this desktop I am currently running this new X (installed it on Sunday) -- first I ran it with HAL, then today I switched to the HAL-less mode. I did complain about the garbage in my windows -- and it got me, there was so much of it: I switched to the HAL-less mode a few hours ago and so far it seems I have less of it. Another thing that I am certain about, is that in the HAL mode (I am not yet sure about the behavior in my current HAL-less mode), there is a dramatically higher mouse pointer captivity by some applications (e.g. `opera') -- it sometimes takes (took?) about 10 seconds after shifting a pointer into an xterm or Emacs to be able to produce any keyboard input. I did notice these things with the old X, but on a scale dramatically smaller. ,--- You/Dan (Wed, 28 Jan 2009 21:11:13 -0700) * | This 7.4 version of X.org is not ready for STABLE! `--* I hate to say this, but the new X (as exists in the current FreeBSD ports) sucks and gets in the way of work big time. -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/Robert (Wed, 28 Jan 2009 23:16:11 -0500) * | > Now I can use X again BUT... Firefox 3.0.5 is still broken. It has =20 | > worked fine until this new Xorg. | | Firefox not working is one of the symptoms of a botched upgrade. If you | ldd firefox-bin you will likely find that it is linked to both | libxcb.so.1 and libxcb.so.2. This is not good, ensure that everything | that depends on libxcb has been rebuilt. FWIW, firefox3 works for me (just installed it on my desktop). -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/Bruce (Thu, 29 Jan 2009 12:06:45 +) * | One theory is that somehow the mouse driver ioctls which are passed | to ums, are somehow hosing USB, although why that would be, I don't | understand. ums currently doesn't have driver instrumentation in that path. | | I pulled a fairly detailed IRC log of my collaborative debugging | session with Robert, please ping me if you need details of this. `* Thank you for the detailed write up! No help to me, though -- on my Latitude laptop, there was no problem with any mouse: USB or the built-in "pointing device". It was the keyboard -- and, trust me, I did try many variations of the machine configuration, and I did do a lot of reading on various relevant topics (writing, too, as you have seen :-() As I mentioned elsewhere, my way of resolving the problem after a one-and-a-half day's of struggle was to revert to the old X (on that laptop). On the topic of how this upgrade was introduced, I can't help but refer to my recent experience helping to fix TWM: ,--- Eeri Kask (Mon, 29 Sep 2008 12:21:17 +0200) * | > I have used the new version of TWM for five days, using it less | > intensively than usual. No problems in seen during my (light) use. | | Hello Alex, no problem at all! Improved solutions have priority over | promised deadlines. | | Thank you for your time helping to improve TWM, :-) | `* Eeri Kask and I worked together all past September on fixing TWM crashes: I was willingly trying his multiple versions of the code, but I knew what I was risking, could choose convenient times for building and trying every new version (we tried about 30 of them) -- and I could always go back to the previous version (or the original TWM from ports). I would be happy to try a new X on my machines, if it were labeled as experimental, with an easy way to revert to the old X (while being in the testing stage). As it is, this upgrade brought a lot of problems to unsuspecting people, at the time they don't quite choose, with potential dangers not disclosed. In honesty, this upgrade should have been presented this way, way before the code was placed in the ports source tree: * We'll have a new X in ports soon -- there are multiple reports of problems with it on Linux. * We want to try it on FreeBSD -- but nobody is forcing you to do the upgrade. * If you, of your own free will, choose to upgrade, you may have hours and days of problems -- but heck, it was your choice. * If your problems cannot be fixed, you'll have to figure out something yourself. * If you choose not to upgrade, you are frozen with the pre-existing ports collection: there may be no automated ways to upgrade your packages, with the old X in place. Of course, you can somehow get pieces on new ports, unrelated to X. * The choice is totally yours. -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/Robert (Thu, 29 Jan 2009 08:40:11 -0500) * | I've had patches available for probably a couple of months now posted to | freebsd-...@. For the few people who tested it, I had no real issues | reported. We were stalled for a long time, While X kept moving, so the | amount of change was large. This update also brings in support for a | lot of people who are running newer hardware. | | I realize that there are some issues with the mouse driver... I'm | trying to look at and resolve, but I don't really know input drivers, so | I doing a lot of guess work. On top of that I do have a day job, so | time is limited. Understood. Would you have spent more time if the new X was introduced as two (?) new ports: xorg-server-devel and libxcb-devel. Is X less complicated, less dangerous, less "user-binding" than firefox or emacs? -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/Robert (Thu, 29 Jan 2009 09:12:47 -0500) * | Problem is, it isn't just the Xserver... All of the pieces are | intertwined and so in many cases to update Xserver you also need to | update some/several libraries as well as all of your drivers. Xorg is | about 60 or 70 ports now. That can be handled, it seems to me. My current port upgrade problem is that I cannot csup the tree and get the old X to rebuild dependent components. | FWIW, I have Xserver 1.6 and xrandr bits that are rc already... as well | as a new intel driver that I don't want to update without xserver 1.6. I would be willing to test 1.6 on my many different machines, provided there is a clear and inexpensive (< 2 hours) path to a rollback. -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/Peter (Sat, 31 Jan 2009 06:53:11 +1100) * | X11 is a critical component for anyone who is using FreeBSD as a | desktop and having upgrades fail or come with significant POLA | violations and regressions for significant numbers of people is not | acceptable. Fully agree with this. | I suggest that this approach needs to be followed for every future | release of X.org until (if) the X.org Project demonstrates that they | can provide release-quality code. And agree with this, as far as the future is concerned -- but this leaves out the issue of what is going to be done for people whose systems became practically incapacitated in a matter of one day. Screw us? I realize that personally I haven't contributed much (hey, a simple port's maintainer!) to FreeBSD, so a disregard to my situation may be well deserved. But "you" (whoever this "you" is: the "ports manager", the X port maintainers) have to be aware that leaving the things in the state they are now, you are screwing somebody. | > This update also brings in support for a lot of people who are | >running newer hardware. | | And breaks support for lots of people who used to have functional X | servers. Just so. ,--- Kostik Belousov (Fri, 30 Jan 2009 22:25:09 +0200) * | Just to give a different view on *this* update. I have exactly opposing | experience. | | So far 1.5.3 + updated DRM works good on all my Radeons. | And, I did not have a problem with i945GM on 1.4.2 and 1.5.3. `--* Well, glad for you -- meanwhile I will be reverting my desktop to the old X this weekend: the garbage on the screen is ugly, but the fact that in the new X "opera" can grab a pointer for about a minute makes the combined use of the browser and xterms/Emacses plain intolerable. After I do this, as I did with my laptop already, I think I am completely cut off from the ports automated upgrade cycle. -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/vehemens (Sat, 31 Jan 2009 11:53:58 -0800) * | In general when upgrading, you take your chances. If a port upgrade | fails, you should fall back to what worked. So, a *fundamental* (practically an OS component) port is brought in -- and it disables my system. What is my way of action? Right -- install the old packages, taken from an FTP site (is there a way to get the previous "source", that is all the ports/*/*/Makefile files? Csup can only go forward -- or can it go back?) When I install the old packages, I can no longer rebuild and install new (say `csup'ed on 2009-03-01) port components, as one whole -- I can only do it selectively, excluding from the upgrade most X-dependent things. That sucks and will lead to a problem earlier or later. | Trying to partial rebuild ports versus rebuilding from scratch after | a major update is just asking for problems. Exactly -- but I haven't done this -- and I have big problems with the new X. | There probably needs to be a more incremental approach when | upgrading major ports. For example, I updated my system a piece at | a time over the last several months, and had no significant problems | with the offical x11 upgrade as the changes were small. I've been rebuilding and reinstalling ports every weekend, for about 1.5 years -- with no problem until the last one, when the new X was in. | And last, many of the video drivers have little if any support. If | you have something other then ati/intel/nivdia, you should expect | problems. Input drivers are in a similar state. Both my systems I've been reporting problems with are using the `nv' driver: $ grep /modules/drivers /var/log/Xorg.0.log (II) Loading /usr/local/lib/xorg/modules/drivers//nv_drv.so One system (Dell Latitude) could not be made operational with the new X at all; the other has garbage in the windows and the "captive mouse pointer" -- both issues new in the new X. -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/vehemens (Sat, 31 Jan 2009 13:54:42 -0800) * | On Saturday 31 January 2009 01:25:21 pm Alex Goncharov wrote: | > So, a *fundamental* (practically an OS component) port is brought in | > -- and it disables my system. What is my way of action? Right -- | > install the old packages, taken from an FTP site (is there a way to | > get the previous "source", that is all the ports/*/*/Makefile files? | > Csup can only go forward -- or can it go back?) | | You ignored the first part of the email which is that the ports | system is flawed due to the lack of a stable versus current branch. The FreeBSD model as what it is and I, for one, prefer it to Linux distros' models. In other words what you call a flaw, I call a virtue. | It seems to me that you want to run a stable branch, while the ports | tree is effectively a current branch. If somebody tells me that running the new X on my computers will be better if I switch the base system from STABLE to CURRENT, I'll do it in a heartbeat. (In fact one of my other systems does run CURRENT, only I never installed X there -- I don't use that system as a front end.) | > When I install the old packages, I can no longer rebuild and install | > new (say `csup'ed on 2009-03-01) port components, as one whole -- I | > can only do it selectively, excluding from the upgrade most | > X-dependent things. That sucks and will lead to a problem earlier or | > later. | | I never update /usr/ports directly. I have a separate csup ports | area. When I update, I save the old ports tree and replace it with | a new one. If a problem occurs, I can fall back to the old tree or | pieces of it. An interesting model -- but how would you be better off falling back to the old ports tree in case of a bad (for you) new X? Yes, you could rebuild and return to using the old X. Then what? Would you be able to keep up with ports upgrades. You may assume that X is going to be fixed -- but what if not, in, say a year? | Well, it depends on which ports you are updating. All. | If you only run X, then I would expect your statement to be correct. Not sure what you mean here: nobody "runs only X". It's impossible. | > | And last, many of the video drivers have little if any support. If | > | you have something other then ati/intel/nivdia, you should expect | > | problems. Input drivers are in a similar state. | > | > Both my systems I've been reporting problems with are using the `nv' | > driver: | > | > $ grep /modules/drivers /var/log/Xorg.0.log | > (II) Loading /usr/local/lib/xorg/modules/drivers//nv_drv.so | > | > One system (Dell Latitude) could not be made operational with the new | > X at all; the other has garbage in the windows and the "captive mouse | > pointer" -- both issues new in the new X. | | See above :) Which point? :-) -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- I/Alex (Sun, 01 Feb 2009 08:11:21 -0500) *
| Knowing about specific things now fixed for specific users is very
| encouraging.
|
| Thanks a lot!
`-*
,--- You/Matt (Sun, 1 Feb 2009 14:17:16 +) *
| I had better post to the lists exactly what I did, having thrown that
| encouraging word out:
I'll make a pass on your list, to compare notes etc.
| Ensure the files section doesn't contain anything like RGBPath if
| you've upgraded, then add Option "AllowEmptyInput" "False" and
| Option "AutoAddDevices" "False" to the server layout section in
| xorg.conf.
I did that -- when I was using HAL.
| Then create a file ${LOCALBASE}/etc/hal/fdi/policy/x11-input.fdi
| with the following contents:
|
|
|
|
|
| gb
|
|
|
Not applicable to me, here in the USA.
| Restart hald etc.
Not applicable to me, running without HAL.
| This cleared up all issues of not playing nice with moused, missing keyboards
| and quotemarks on my @ key ;o) Obviously, you'll want to replace "gb" with
| whatever layout you require from ${LOCALBASE}/share/X11/xkb/symbols/. Note I
| have not tried hotplugging a USB mouse on this configuration. That's to come
| on the laptop, which works fine with its trackpad (although middle and right
| clicks have been redefined to three and two finger taps respectively - it was
| the other way around) with the updated xf86-input-synaptics driver.
This is an interesting bit...
So, I have a lousy new X on a desktop, and had a fully disfunctional
one on my Latitude notebook (due to "crazy" keyboard" events), the
latter being reverted to xorg-server 1.4.
The laptop has a touch pad, which is reasonable to assume to be
"synaptics" -- but I don't use the pad (I've physically covered it,
and use only the "pointing stick" in the middle of the keyboard);
during one my experiments I also disabled the thing in BIOS.
And: I have never used the xf86-input-synaptics driver.
Is this something to think about -- what is the role of this driver?
Can the lack of it bring the storm of bogus key events with wrong scan codes?
| Which brings me to another little niggle: Has anyone on list noticed
| that statically compiling a keymap in your kernel >7.0-RELEASE ends up with
| the US layout in single user mode regardless? This used to work, but now it
| doesn't, unless I've missed something in NOTES somewhere.
I can't comment on it -- but why to do it: why not to use the xkb
extensions (Option "XkbLayout" "gb" -- or something of that sort)?
-- Alex -- alex-goncha...@comcast.net --
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- Alexandre \ (Sun, 01 Feb 2009 12:03:06 -0500) * | > When I install the old packages, I can no longer rebuild and install | > new (say `csup'ed on 2009-03-01) port components, as one whole -- I | > can only do it selectively, excluding from the upgrade most | > X-dependent things. That sucks and will lead to a problem earlier or | > later. | Will combination of sysutils/portdowngrade and HOLD_PKGS variable | in /usr/local/etc/pkgtools.conf accomplish what you are trying to | accomplish? `--* I'll try something of that nature (not today) with your and other people's advice. Thank you! -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/Matthew (Sun, 1 Feb 2009 14:48:15 -0600) * | On Sat, Jan 31, 2009 at 04:25:21PM -0500 I heard the voice of | Alex Goncharov, and lo! it spake thus: | > Csup can only go forward -- or can it go back?) | | You can specify a date in a supfile since, like, ever. `-* Yes, other people have already pointed this out and I just got the code as of 2009.01.23.12.00.00 -- four hours before the first submission of the new X. Now I just need to think through my next steps :-) Thank you! -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Teltonika ModemPCI/G10
Hi Guys! Is there anybody who uses Teltonika ModemPCI/G10 under 7-stable? I see that USB version of it (ModemUSB/G10) works for people via uftdi driver. Regards, Alex. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Follow-up on Teltonika ModemPCI/G10
Hi Guys! I guess I have just answered the question myself. I decided to buy the modem and try it. Guys in Teltonika told me that they haven't done any FreeBSD testing since they have nobody to do this. But they have sent me pdf with instruction how to setup the modem on Linux. The modem is working, but it required a bit of a work :-). I added few lines into /usr/src/sys/dev/puc/pucdata.c and recompiled kernel with the following additional configuration lines after that: device puc options COM_MULTIPORT After reboot I had two new serial ports cuau0 and cuau1 and was able to send an SMS message to my mobile phone. The question is how would I go about submitting the lines to developers, so they can review and hopefully commit it? :-) I have posted details of how I made it work to my wiki http://markelov.org/wiki/index.php/Teltonika_ModemPCI/G10_under_FreeBSD Hope it may help someone. Regards, Alex. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zpool vdev vs. glabel
Use gpart and add created partition to your raidz- for example [code] backupstorage# gpart create -s GPT ad0 backupstorage# gpart add -b 34 -s 1953525101 -i 1 -t freebsd-zfs -l disk0 ad0 backupstorage# gpart show =>34 1953525101 da0 GPT (932G) 34 19535251011 freebsd-zfs (932G) backupstorage# gpart show -l =>34 1953525101 da0 GPT (932G) 34 19535251011 disk0 (932G) backupstorage# ls /dev/gpt disk0 backupstorage# zpool status -v pool: storage state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM storageONLINE 0 0 0 raidz1 ONLINE 0 0 0 gpt/disk0 ONLINE 0 0 0 gpt/disk1 ONLINE 0 0 0 gpt/disk2 ONLINE 0 0 0 gpt/disk3 ONLINE 0 0 0 gpt/disk4 ONLINE 0 0 0 gpt/disk5 ONLINE 0 0 0 gpt/disk6 ONLINE 0 0 0 gpt/disk7 ONLINE 0 0 0 [code] Try to remove and insert disks- all it should happy =) PS: sorry for my english =) Gerrit Kühn пишет: Hi, I have created a raidz2 with disk I labeled with glabel before. Right after creation this pool looked fine, using devices label/tank[1-6]. I did some tests with replacing/swapping disks and so on. After doing a zpool offline tank label/tank6 remove disk camcontrol rescan all insert disk camcontrol rescan all zpool online tank label/tank6 I got the disk back, but not under the requested label, but under the da device name: pool: tank state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:56:37 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/tank1 ONLINE 0 0 0 8.50K resilvered label/tank2 ONLINE 0 0 0 7.50K resilvered label/tank3 ONLINE 0 0 0 8.50K resilvered label/tank4 ONLINE 0 0 0 7.50K resilvered label/tank5 ONLINE 0 0 0 9K resilvered da6 ONLINE 0 0 0 13.5K resilvered errors: No known data errors Why does this happen? Is there any way to get zfs to use the label again? After the device is in use, the label in /dev/label disappears. When taking the device offline again, the label is there, but cannot be used: pigpen# zpool offline tank da6 pigpen# zpool status pool: system state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:49:14 2010 config: NAME STATE READ WRITE CKSUM system ONLINE 0 0 0 mirror ONLINE 0 0 0 label/system1 ONLINE 3 617 0 126K resilvered label/system2 ONLINE 0 0 0 41K resilvered errors: No known data errors pool: tank state: DEGRADED status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: resilver completed after 0h0m with 0 errors on Tue Feb 9 14:56:37 2010 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz2 DEGRADED 0 0 0 label/tank1 ONLINE 0 0 0 8.50K resilvered label/tank2 ONLINE 0 0 0 7.50K resilvered label/tank3 ONLINE 0 0 0 8.50K resilvered label/tank4 ONLINE 0 0 0 7.50K resilvered label/tank5 ONLINE 0 0 0 9K resilvered da6 OFFLINE 038 0 13.5K resilvered errors: No known data errors pigpen# ll /dev/label/ total 0 crw-r- 1 root operator0, 104 Feb 9 14:04 lisacrypt1 crw-r- 1 root operator0, 112 Feb 9 14:04 lisacrypt2 crw-r- 1 root operator0, 113 Feb 9 14:04 lisacrypt3 crw-r- 1 root operator0, 134 Feb 9 14:48 system1 crw-r- 1 root operator0, 115 Feb 9 14:04 system2 crw-r- 1 root operator0, 116 Feb 9 14:04 tank1 crw-r- 1 root operator0, 117 Feb 9 14:04 tank2 crw-r- 1 root operator0, 118 Feb 9 14:04 tank3 crw-r-
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
Stephen Hurd wrote: Jeremy Chadwick wrote: SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 253 253 063Pre-fail Always - 4 This shows you've had 4 reallocated sectors, meaning your disk does in fact have bad blocks. In 90% of the cases out there, bad blocks continue to "grow" over time, due to whatever reason (I remember reading an article explaining it, but I can't for the life of me find the URL). This is unusual now? I've always "known" that a small number of bad blocks is normal. Time to readjust my knowledge again? I have bought disks where the value of Reallocated_Sector_Ct was not 0, at least by the time I looked at it with smartctl. Nothing bad has happened to those disks in several years (hope that's not tempting fate). I have always assumed that what matters is when this value *changes*. If it's not changing, who cares? smartd will monitor disks and email you when certain attributes change (e.g. Pre-fail attributes like Reallocated_Sector_Ct). If it changed, it would mean that an attempt to write data had failed and that reallocation had happened. e.g. from smartd.conf /dev/ad4 -o on -S on -a -m root -M daily If your Current_Pending_Sector were non-zero you'd be in trouble, I believe. 0.02, pinch of salt, not an expert, slippery when hot, long time since I read the specs, etc etc. --Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet
World was cvsupped on March 6th, around 18:00 GMT. Built and installed kernel + world, with options WITNESS and WITNESS_SKIPSPIN. Short background: 7.0-RELEASE had excellent performance on the machine, but it would randomly lock up after some hours (usually over 10 hours). The lockups were hard, meaning nothing seemed to work (NumLock didn't toggle the keyboard LED, no replies to ping, no disk activity). We changed the motherboard and RAM and had the same behaviour. 6.2-REL is rock solid on this machine (had over 50 days uptime), but upgrading to 6.3-REL made it lock up just like 7.0 (so we put 6.2 back and accepted the lower performance for the time being). The LOR messages from dmesg of 7.0-STABLE are as follows: lock order reversal: 1st 0xb19e0680 pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6729 2nd 0xff00042ea0f0 radix node head (radix node head) @ /usr/src/sys/net/route.c:147 lock order reversal: 1st 0x80938508 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 2nd 0x80938c48 tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:400 More details about the machine in the attached dmesg. It's a SMP with 4GB of RAM, 3 gigabit cards (em0, em1 and, depending on the motherboard we used, either bge0 or msk0). Only em0 is linked to a gigabit port, the others are 100Mbits/s My setup has in-kernel IPFIREWALL, IPFIREWALL_VERBOSE, IPFIREWALL_DEFAULT_TO_ACCEPT, DUMMYNET. I have commented out INET6, SCTP and the wireless interfaces. WITNESS and WITNESS_SKIPSPIN were only added in the hope of figuring out what locks it up, and they did signal these 2 LORs. pf and pflog are loaded as modules (pf_enable and pflog_enable set to yes in rc.conf). - The ipfw/dummynet side: I use net.link.ether.ipfw = 1 for MAC address checking, ipfw + dummynet for traffic shaping (4 queues at 95Mbits/s for the 2 external interfaces in/out, and 4 more queues for traffic that goes outside the AS group for which we have fast access). Deciding which queue traffic goes in depends on its source address and whether its destination is in ipfw tables 1, 2 or none. These tables are synchronized from pf tables via a custom script in crontab, which runs every 3 minutes. The pf tables used as source for these are controlled by OpenBGPD. - The pf side: Filtering is done here, as is policy routing. Filtering also contains redirecting to a transparent squid proxy of traffic destined to port 80 but not bound for networks received via BGP and saved to tables and . Metro and special port 80 traffic goes directly to the destination server. Traffic from net1 and net2 is routed via the "other" external interface, which doesn't contain the default route... with the exception of traffic to pf table (from BGP, same as table 2 in ipfw). Traffic to is routed via fastroute in pf (meaning using the default route). Attached are full dmesg and the kernel config. I still have access to the hard drive with 7.0-STABLE on it, but not the motherboard/CPU and the network cards... they are running off the hard drive with 6.2 on it. -- "Computer science is no more about computers than astronomy is about telescopes" -- E. W. Dijkstra # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.484.2.2.2.1 2008/02/06 03:24:28 scottl Exp $ cpu HAMMER ident GENERIC # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options WITNESS options WITNESS_SKIPSPIN options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking #optionsINET6 # IPv6 communications protocols #optionsSCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH
Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet (extra details)
Extra details: The machine shows no problems when running 6.2-RELEASE-p7 / i386. Upgrading to 6.3-RELEASE / i386 caused the machine to start randomly locking up, much faster than 7.0 (about 4 hours versus 12+) Have tried 7.0-RELEASE/i386, 7.0-RELEASE/amd64, both with SMP support. I've also tried 7.0-RELEASE/i386 without SMP support. All of them exhibited the lockups (amd64 with SMP locked up after most time, the others were much faster to lock up but this isn't statistically proven). Alex -- "Computer science is no more about computers than astronomy is about telescopes" -- E. W. Dijkstra ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet
This is a mixed reply to both the previous mails, bear with me please. On Sat, Mar 15, 2008 at 10:16:54PM +0100, Max Laier wrote: > On Saturday 15 March 2008, Robert Watson wrote: > > On Fri, 14 Mar 2008, Alex Popa wrote: > > > [snip] > > > The LOR messages from dmesg of 7.0-STABLE are as follows: > > > > > > lock order reversal: > > > 1st 0xb19e0680 pf task mtx (pf task mtx) @ > > > /usr/src/sys/modules/pf/../../contrib/pf/net/pf.c:6729 2nd > > > 0xff00042ea0f0 radix node head (radix node head) @ > > > /usr/src/sys/net/route.c:147 > > I haven't seen this one before, can you obtain the trace for this, please? > You might need KDB & DDB for that - not sure. I'll do my best (see below for my questions about getting a trace). > > > lock order reversal: > > > 1st 0x80938508 PFil hook read/write mutex (PFil hook > > > read/write mutex) @ /usr/src/sys/net/pfil.c:73 2nd 0x80938c48 > > > tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:400 > > This one is most certainly harmless and can be ignored. It is caused by > user/group rules, but a LOR with the read instance of a rwlock will not > lead to a deadlock. I'm not using uid/gid/jail rules as far as I remember. I'll add another reply with pf.conf and the script I use to generate and reload the ipfw rules (but I'll anonymize them). > > Dear Alex, > > > > Thanks for this report, and sorry about the problem. It could well be > > that the lock order warning from WITNESS is related to the hang, and > > might reflect a recursion-related bug in the pf policy routing code. > > I'm not sure to what extent you can tolerate further downtime, but it > > would be useful to gather some more information about the hang itself > > to try and confirm the involvement of lock order. In particular, if > > it's feasible, it would be very helpful if you could boot back to the > > 7-STABLE kernel (keeping the 6.2-STABLE userspace should be fine, I > > you'll need at least a new pfctl, because the ioctl interface to /dev/pf > has changed. Switching between 6.2-RELEASE-p7 (not STABLE, because as I said 6.3 exhibited the lockups too) and 7-STABLE isn't that much of a problem. The upgrade path was "buy a new hard drive, set up everything and then adapt the old config files"... actually we bought 2 harddrives, and I set them up one with amd64 and another with i386. I think /etc and /usr/local/etc are perfectly identical on these 2 (I adapted the configs from 6.2 to 7.0, but I just copied them from amd64 to i386). So, actions needed to switch: Backup the database on 6.2 (with IP/MAC mappings and a bit more), put in the 7.0 hard drive, boot off 7.0, restore DB, let it run. Total downtime should be around 7 minutes tops. > > think), and when the hang occurs, use the console debuggger (ideally > > hooked up to serial or firewire) to run the following debugging > > commands: > > > >show pcpu > >show allpcpu > >trace > >alltrace > >show allocks > >show witness > >show lockedvnods > >show uma > >show malloc This is where things get a bit tricky, and I need advice. As I said, my observation is that the keyboard seems to stop working when the lockup occurs, that is, pressing Num Lock won't toggle the state of the LED. Thus I have some doubts that trying the good-old Control-Alt-ESC would have the desired effect (dropping me into the debugger). However, I'm not that familiar with the FreeBSD architecture, and wouldn't be surprised if the LED toggling would be in another thread and the macine will actually respond to the keyboard interrupt and drop me into ddb. Also, judging by the lack of NumLock activity (it works fine when the system's up), would serial console or firewire be functional during the lockup? Also, a bit of explanations: Why I'm asking the above: The current motherboard has a serial port (and it works, we've used it), but not a firewire port. The other motherboard we tried has firewire, but no serial. As a console workstation, I can get a few with serials, but not so easy with firewire. The null modem cable might be a problem too, depending on length. Also, since the lockup isn't easily reproducible, I'll probably need to spend some hours on location and if I'm going to do that, I'd like a degree of hope that either keyboard, serial console or firewire will work. Also, firewire will require me to switch motherboards, but that can be done together with the hard drive swapping, during the night. After a bit of studying NOTES, I was wondering if a combination of serial console (or just plain console) w
Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet (extra extra details - config files)
Attached are pf.conf and ipfw.txt. The former is loaded by the standard means, and the latter is loaded via ipfw -q /path/to/ipfw.txt Some comments: I've anonymized the files. Address in the 10.0.0.0/8 range stand for "internal" IP addresses, meaning one /27 and three /24 networks, and address in the 192.168.0.0/16 range stand for addresses on the directly connected "external" networks, meaning the 2 fibers to the ISP. Also I've junked all but the last byte of MAC addresses in ipfw. I know the ipfw setup looks scary, but worst case a layer2 packet (I should say frame) gets checked against 38 rules (39 if it's dropped). I could probably optimize a few more rules out of this, but I'm not sure it's worth the effort. For layer3 I haven't counted, but I doubt it's more than 10 rules (more likely 6-7). Tables "metro" and "special" in pf are contolled by OpenBGPD. They are synced to ipfw tables 1 and 2 respectively, by cron jobs that run every 3 minutes and only make the necessary changes. ipfw rules below the "DO NOT EDIT" line are automatically generated from a database of IP/MAC mappings. This can change asynchronously and can cause the script to be regenerated and run. The classification is supposed to speed things up a little, by not comparing a MAC address against all hosts in its subnet, but only against sqrt(hosts) other IPs and another sqrt(hosts) IP/MAC pairs. [and it's not exactly sqrt, but about half of the bits in the host part of the IP address] Have fun Alex -- "Computer science is no more about computers than astronomy is about telescopes" -- E. W. Dijkstra set move 0 to 1 set disable 0 # scary stuff, allow arp add 10 allow mac-type 0x0806 # filter MAC on input add 10 skipto 100 in recv em0 layer2 add 11 allow out xmit em0 layer2 add 12 allow in layer2 add 13 allow out layer2 # em0 - internal add 20 skipto 22000 in recv em0 add 25 allowout xmit em0 # em1 - external 1 - shape on 2 (in) / 20500 (out) add 30 skipto 2 in recv em1 add 35 skipto 20500 out xmit em1 # bge0 - extern 2 - shape on 21000 (in) / 21500 (out) add 40 skipto 21000 in recv bge0 add 45 skipto 21500 out xmit bge0 add 90 allow ip from any to any via lo0 add 95 allow ip from any to any -f zero # # TABLES # # 1 - metro # 2 - special # 10 - internal (all) # 11 - internal - routing external 1 (em1) # 12 - internal - routing external 2 (bge0) # 100 bandwidth A # 101 bandwidth B # 120, 121, 122 : this server: All IPs, IP bw A, IP bw B # NOTE: tables 1 and 2 are synchronized to pf tables named # "metro" and "special" by a script which runs every 3 minutes table 10 flush table 10 add 10.0.10.0/27 table 10 add 10.0.20.0/24 table 10 add 10.0.30.0/24 table 10 add 10.0.40.0/24 table 10 add 192.168.11.11 table 10 add 192.168.22.22 table 11 flush table 11 add 10.0.20.0/24 table 11 add 10.0.40.0/24 table 11 add 192.168.11.11 table 11 add 192.168.22.22 table 12 flush table 12 add 10.0.10.0/27 table 12 add 10.0.30.0/24 table 100 flush table 100 add 10.0.20.0/24 table 100 add 10.0.30.0/24 table 100 add 10.0.40.0/24 table 100 add 192.168.11.11 table 101 flush table 101 add 10.0.10.0/27 table 101 add 192.168.22.22 table 120 flush table 120 add 10.0.10.1 table 120 add 10.0.20.1 table 120 add 10.0.30.1 table 120 add 192.168.33.33 table 120 add 192.168.11.11 table 120 add 192.168.22.22 table 121 flush table 121 add 10.0.20.1 table 121 add 10.0.30.1 table 121 add 10.0.40.1 table 121 add 192.168.11.11 table 122 flush table 122 add 10.0.10.1 table 122 add 192.168.33.33 table 122 add 192.168.22.22 # # PIPES and QUEUES # -f pipe flush # bw A - in 1/out 2 pipe 1 config bw 4500kbits/s queue 1 config pipe 1 weight 10 mask dst-ip 0x pipe 2 config bw 200kbits/s mask src-ip 0x # bw B - in 3/out 4 pipe 3 config bw 1000kbits/s queue 3 config pipe 3 weight 10 mask dst-ip 0x pipe 4 config bw 1000kbits/s queue 4 config pipe 4 weight 10 mask src-ip 0x # external interface 1 (em1) - 11 in/12 out pipe 11 config bw 95Mbits/squeue 100 queue 11 config pipe 11 weight 10 mask dst-ip 0xqueue 100 pipe 12 config bw 95Mbits/squeue 100 queue 12 config pipe 12 weight 10 mask src-ip 0xqueue 100 # external interface 2 (bge0) - 21 in/22 out pipe 21 config bw 95Mbits/squeue 100 queue 21 config pipe 21 weight 10 mask dst-ip 0xqueue 100 pipe 22 config bw 95Mbits/squeue 100 queue 22 config pipe 22 weight 10 mask src-ip 0xqueue 100 ### # # Shaping - check order: Metro / Special / A / B (3 in, 3 out) # ### # em1 - ext 1 shaping - 2/20500 add 2 queue 11 ip from table(1) toany add 20005 queue 11 ip from table(2) toany a
Re: Lock Order Reversal on 7.0-STABLE with pf and ipfw / dummynet
On Sun, Mar 16, 2008 at 10:16:20PM +, ian j hart wrote: > Keyboard LEDs are broken for me on 6.3 amd64 (kbdmux). > I'd double check they work before you rely on this as a diagnostic tool. > > -- > ian j hart Well, that was the most basic test. I should have mentioned that, during the lockup: (a) Before I removed the "saver" line in rc.conf, hitting a key wouldn't turn the screensaver off. I removed it in case the kernel was writing *something* to the console, so I could get a glimpse. (b) Console switching no longer worked. Hope this helps Alex -- "Computer science is no more about computers than astronomy is about telescopes" -- E. W. Dijkstra ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Plentiful NFS debug messages in /var/log/messages
The system is built from source so that: # uname -sr FreeBSD 7.0-RELEASE # cat KERNEL-CONFIG | FILTER-DEBUG options KDB options KDB_TRACE options DDB options WITNESS options WITNESS_SKIPSPIN An NFS client (an application using an NFS file system) runs unbelievably slow, compared with when a local file system is used. The NFS server shows this: # vmstat 4 200 procs memory page disk faults cpu r b w avmfre flt re pi pofr sr ad0 in sy cs us sy id 3 0 0 142408 31712410 0 0 010 0 0 69 80 409 0 1 99 2 0 0 142408 316756 0 0 0 0 0 0 1 406 3288 1336 1 99 0 2 0 0 142408 316276 0 0 0 0 4 0 5 409 4837 1350 1 98 1 2 0 0 142408 315812 168 0 0 0 143 0 6 401 5251 1341 1 98 1 0 0 0 142408 315396 0 0 0 044 0 25 365 4396 1252 1 80 20 0 0 0 142408 314892 0 0 0 027 0 34 287 2449 1101 1 37 62 0 0 0 142408 314244 0 0 0 016 0 18 272 1215 1051 0 20 80 0 0 0 142408 313828 0 0 0 0 6 0 14 197 545 862 0 9 91 0 0 0 142408 313236 0 0 0 0 6 0 10 232 536 933 0 9 91 0 0 0 142408 312680 0 0 0 010 0 14 229 977 944 1 14 85 0 0 0 142408 312208 0 0 0 012 0 16 216 1053 895 0 16 84 0 0 0 142408 311936 0 0 0 0 4 0 7 133 410 668 0 6 93 These messages are meanwhile streaming into `/var/log/messages': Mar 18 11:47:42 fasolt kernel: --- syscall (155, FreeBSD ELF32, nfssvc), eip = 0x280c4a2b, esp = 0xbfbfeb2c, ebp = 0xbfb feb48 --- Mar 18 11:47:42 fasolt kernel: uma_zalloc_arg: zone "mbuf" with the following non-sleepable locks held: Mar 18 11:47:42 fasolt kernel: exclusive sleep mutex nfsd_mtx r = 0 (0xc09456a0) locked @ /mnt/wdx/freebsd/7.0/usr/src/s ys/nfsserver/nfs_srvsock.c:654 KDB: stack backtrace: db_trace_self_wrapper(c08485d5,d5f1faf8,c0615eed,c084895a,d5f1fb0c,...) at db_trace_self_ kdb_backtrace(c084895a,d5f1fb0c,4,1,0,...) at kdb_backtrace+0x29 witness_warn(5,0,c085e59c,c084c9c8,d5f1fb1c,...) at witness_warn+0x1cd uma_zalloc_arg(c1067d20,d5f1fb70,2,8,c2bf94a4,...) at uma_zalloc_arg+0x34 nfs_realign(c09456a0,0,c08595b8,28e,0,...) at nfs_realign+0x6f nfsrv_rcv(c2daf948,c2bf9480,2,160,0,...) at nfsrv_rcv+0x42a nfssvc(c2c0caa0,d5f1fcfc,8,c2c0caa0,c089eac8,...) at nfssvc+0x664 syscall(d5f1fd38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 I could, of course, rebuild the kernel without the debug options but perhaps somebody sees a problem with this behavior and can advise me on a better course of actions. Thanks, -- Alex -- [EMAIL PROTECTED] -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
