Re: nfs lockd errors after NetApp software upgrade.
Hi, We had some bully type workloads emerge when we moved a lot of block storage from old XIV to new all flash 3PAR. I wonder if your IMAP issue might have emerged just because suddenly there was the opportunity with all flash. QOS is good on 9.x ONTAP. If anyone says it’s not then they last looked on 8.x. So I suggest you QOS the IMAP workload. Nobody should be using UDP with NFS unless they have a very specific set of circumstances. TCP was a real step forward. Cheers Richard ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: nfs lockd errors after NetApp software upgrade.
Hi, At ONTAP 9.3P6 there is a possible LACP group issue after upgrade. Have you checked any LACP groups, These should not be a problem but I assume network interfaces are at the home ports, not on slower ports or something silly. It is marginally better if the traffic goes direct to the node where the volume is but the difference should nothing. Have you looked at the NetApp performance data? If you are going to do wireshark tcpdumps then you might want to run them from the NetApp as well. https://kb.netapp.com/app/answers/answer_view/a_id/1029833/~/how-to-capture-packet-traces-%28tcpdump%29-on-ontap-9.2%2B-systems- ::> network tcpdump start -node -port e0a -buffer-size 2097151 Let us know how you go, Richard ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: nfs lockd errors after NetApp software upgrade.
Hi, I’m sure the 64 bit identifiers isn’t an issue. Your export isn’t vast. I assume you have restarted statd and lockd on FreeBSD. I did search on the NetApp site earlier and nothing lept out then. Sorry, Richard On Wed, 18 Dec 2019 at 16:06, Daniel Braniss wrote: > > > On 18 Dec 2019, at 17:58, Richard P Mackerras > wrote: > > Hi, > What software version is the NetApp using? > > the very latest :-), but will try and find out later. > > Is the exported volume big? > > about 500G, but many files > as far as I know, only accessed by one host running the web app - moodle. > > Is the vserver configured for 64bit identifiers > > what the issue here? > > ? > > If you enable NFS V4.0 or 4.1 other NFS clients using defaults might mount > NFSv4.x unexpectedly after a reboot so you need to watch that. > > Cheers > > Richard > (NetApp admin) > > On Wed, 18 Dec 2019 at 15:46, Daniel Braniss wrote: > >> >> >> > On 18 Dec 2019, at 16:55, Rick Macklem wrote: >> > >> > Daniel Braniss wrote: >> > >> >> Hi, >> >> The server with the problems is running FreeBSD 11.1 stable, it was >> working fine for >several months, >> >> but after a software upgrade of our NetAPP server it’s reporting many >> lockd errors >and becomes catatonic, >> >> ... >> >> Dec 18 13:11:02 moo-09 kernel: nfs server fr-06:/web/www: lockd not >> responding >> >> Dec 18 13:11:45 moo-09 last message repeated 7 times >> >> Dec 18 13:12:55 moo-09 last message repeated 8 times >> >> Dec 18 13:13:10 moo-09 kernel: nfs server fr-06:/web/www: lockd is >> alive again >> >> Dec 18 13:13:10 moo-09 last message repeated 8 times >> >> Dec 18 13:13:29 moo-09 kernel: sonewconn: pcb 0xf8004cc051d0: >> Listen queue >overflow: 194 already in queue awaiting acceptance (1 >> occurrences) >> >> Dec 18 13:14:29 moo-09 kernel: sonewconn: pcb 0xf8004cc051d0: >> Listen queue >overflow: 193 already in queue awaiting acceptance (3957 >> occurrences) >> >> Dec 18 13:15:29 moo-09 kernel: sonewconn: pcb 0xf8004cc051d0: >> Listen queue >overflow: 193 already in queue awaiting acceptance … >> > Seems like their software upgrade didn't improve handling of NLM RPCs? >> > Appears to be handling RPCs slowly and/or intermittently. Note that no >> one >> > tests it with IPv6, so at least make sure you are still using IPv4 for >> the mounts and >> > try and make sure IP broadcast works between client and Netapp. I think >> the NLM >> > and NSM (rpc.statd) still use IP broadcast sometimes. >> > >> we are ipv4 - we have our own class c :-) >> > Maybe the network guys can suggest more w.r.t. why, but as I've stated >> before, >> > the NLM is a fundamentally broken protocol which was never published by >> Sun, >> > so I suggest you avoid using it if at all possible. >> well, at the moment the ball is on NetAPP court, and switching to NFSv4 >> at the moment is out of the question, it’s >> a production server used by several thousand students. >> >> > >> > - If the locks don't need to be seen by other clients, you can just use >> the "nolockd" >> > mount option. >> > or >> > - If locks need to be seen by other clients, try NFSv4 mounts. Netapp >> filers >> > should support NFSv4.1, which is a much better protocol that NFSv4.0. >> > >> > Good luck with it, rick >> thanks >> danny >> >> > … >> > any ideas? >> > >> > thanks, >> >danny >> > >> > ___ >> > freebsd-stable@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to " >> freebsd-stable-unsubscr...@freebsd.org" >> >> ___ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: nfs lockd errors after NetApp software upgrade.
Hi, What software version is the NetApp using? Is the exported volume big? Is the vserver configured for 64bit identifiers? If you enable NFS V4.0 or 4.1 other NFS clients using defaults might mount NFSv4.x unexpectedly after a reboot so you need to watch that. Cheers Richard (NetApp admin) On Wed, 18 Dec 2019 at 15:46, Daniel Braniss wrote: > > > > On 18 Dec 2019, at 16:55, Rick Macklem wrote: > > > > Daniel Braniss wrote: > > > >> Hi, > >> The server with the problems is running FreeBSD 11.1 stable, it was > working fine for >several months, > >> but after a software upgrade of our NetAPP server it’s reporting many > lockd errors >and becomes catatonic, > >> ... > >> Dec 18 13:11:02 moo-09 kernel: nfs server fr-06:/web/www: lockd not > responding > >> Dec 18 13:11:45 moo-09 last message repeated 7 times > >> Dec 18 13:12:55 moo-09 last message repeated 8 times > >> Dec 18 13:13:10 moo-09 kernel: nfs server fr-06:/web/www: lockd is > alive again > >> Dec 18 13:13:10 moo-09 last message repeated 8 times > >> Dec 18 13:13:29 moo-09 kernel: sonewconn: pcb 0xf8004cc051d0: > Listen queue >overflow: 194 already in queue awaiting acceptance (1 > occurrences) > >> Dec 18 13:14:29 moo-09 kernel: sonewconn: pcb 0xf8004cc051d0: > Listen queue >overflow: 193 already in queue awaiting acceptance (3957 > occurrences) > >> Dec 18 13:15:29 moo-09 kernel: sonewconn: pcb 0xf8004cc051d0: > Listen queue >overflow: 193 already in queue awaiting acceptance … > > Seems like their software upgrade didn't improve handling of NLM RPCs? > > Appears to be handling RPCs slowly and/or intermittently. Note that no > one > > tests it with IPv6, so at least make sure you are still using IPv4 for > the mounts and > > try and make sure IP broadcast works between client and Netapp. I think > the NLM > > and NSM (rpc.statd) still use IP broadcast sometimes. > > > we are ipv4 - we have our own class c :-) > > Maybe the network guys can suggest more w.r.t. why, but as I've stated > before, > > the NLM is a fundamentally broken protocol which was never published by > Sun, > > so I suggest you avoid using it if at all possible. > well, at the moment the ball is on NetAPP court, and switching to NFSv4 at > the moment is out of the question, it’s > a production server used by several thousand students. > > > > > - If the locks don't need to be seen by other clients, you can just use > the "nolockd" > > mount option. > > or > > - If locks need to be seen by other clients, try NFSv4 mounts. Netapp > filers > > should support NFSv4.1, which is a much better protocol that NFSv4.0. > > > > Good luck with it, rick > thanks > danny > > > … > > any ideas? > > > > thanks, > >danny > > > > ___ > > freebsd-stable@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org > " > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Question about bottle neck in storage
I’d be interested to know what the actual throughput is you are getting. Are the disks SATA 7200RPM? What speed is the disk interface? Do you have just 2 disks or more? Richard [Richard Mackerras - Chat @ Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=6bswo) [6bswo] On September 24, 2019 at 16:30 GMT, Kevin P Neal wrote: On Tue, Sep 24, 2019 at 11:45:37AM -0400, John Fleming wrote: > Don't have cpu info hand.. zeon something. DDR3-1600 (128GB) See /var/run/dmesg.boot for the output of the dmesg command as of boot time. It includes the type of CPU, the number of CPUs, the number of threads, features, disabled features, and so on aside from the type of memory. I don't think that's available in dmesg? -- Kevin P. Neal http://www.pobox.com/~kpn/ "Oh, I've heard that paradox a couple of times, but there's something about a cat dying and I hate to think of such things." - Dr. Donald Knuth speaking of Schrodinger's cat, December 8, 1999, MIT ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Crontab Question
In your script put a few commands outputting to a check file pwd > /tmp/checkfile Add a few more like ENV >> /tmp/checkfile Just to make sure it really is in the directory you expect with the environment you expect. If you want it to be run as you never use the root crontab unless you want really crap security. Cheers Sent from my iPad > On 11 Apr 2019, at 16:29, Software Info wrote: > > Well thanks for all the input. I just have to tp keep working at it. Again, > much appreciated. > > > Regards > SI > > Sent from Mail for Windows 10 > > From: Walter Cramer > Sent: Wednesday, April 10, 2019 4:40 PM > To: Software Info > Cc: Jonathan Chen; freebsd-stable@freebsd.org > Subject: RE: Crontab Question > >> On Wed, 10 Apr 2019, Software Info wrote: >> >> OK. So although the script is located in my home directory, it doesn’t >> start there? Sorry but I don’t quite understand. Could you explain a >> little further please? > > Both 'cp' and 'ls' are located in /bin. But if I run the 'ls' command in > /root, 'ls' can't find 'cp' (unless I tell it where to look) - even though > /bin *is* in my PATH - > > server7:/root # ls cp > ls: cp: No such file or directory > server7:/root # ls /bin/cp > /bin/cp > > Where the system looks for *commands*, to execute, is different from where > it looks for other files, which those commands use. The latter is > generally only the current directory (unless you tell it otherwise). > When cron runs a script as root, "current directory" will be /root. > > BUT - for security and other reasons, it would be better to have cron run > your script as you (not root), and as '/home/me/myscript' (instead of > adding your home directory to PATH in /etc/crontab). > > -Walter > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Panic on 11-STABLE with Xen guest
I have the same failure to boot 11-stable as a DomU host on xen_version: 4.4.1 Kernel I was trying was recent, FreeBSD 11.2-STABLE (GENERIC) #23 r334205:340834 commit 340016 for the dynamic IRQ layout seems rather involved and I doubt I could isolate the problem, but maybe it is in 338631: xen: legacy PVH fixes for the new interrupt count Register interrupts using the PIC pic_register_sources method instead of doing it in apic_setup_io. This is now required, since the internal interrupt structures are not yet setup when calling apic_setup_io. -- Richard M. Timoney (richa...@maths.tcd.ie) Tel. +353-1-896 1196 School of Mathematics, Trinity College, Dublin 2, Ireland WWW https://www.maths.tcd.ie/~richardt FAX +353-1-896 2282 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Problem installing 11-stable on a Dell 5510, UEFI boot
Hello, I have a nice new Dell Precision 5510 laptop that I ordered preloaded with Ubuntu 14.10, and I'd *really* like to have FreeBSD on it instead. I've put the memstick image on a 2GB USB stick per the instructions on freebsd.org, but when I bring up the boot menu on the 5510 the USB drive isn't offered as a boot device. I've disabled Secure Boot & I made sure that the 5510 is allowed to boot from a USB device. I then decided to build my own image, following the instructions on the wiki: gpart create -s gpt da0 gpart add -t efi -s 800K da0 gpart add -t freebsd-ufs da0 dd if=/boot/boot1.efifat of=/dev/da0p1 newfs -U -L FreeBSD /dev/da0p2 Followed by: mount /dev/da0p2 /mnt make DESTDIR=/mnt installkernel installworld distribution echo "/dev/da0p2 / ufs rw 1 1" >> /mnt/etc/fstab umount /mnt It took a while to install and apparently worked fine, with no errors, but it still didn't show up in the boot menu. I had created an Ubuntu recovery image when I first fired up the 5510 and wrote it to a USB drive, and it shows up in the boot menu. Just for fun I downloaded a Linux Mint 18 XFCE installation ISO that I copied to the USB drive using the same method I used for the FreeBSD memstick image. It shows up on the boot menu & I verified that I can boot it. I'll run Mint with XFCE if I have to, but I'd really prefer FreeBSD. Can anyone offer suggestions as to what I should try next? Thanks! -- Richard Kuhns <r...@wintek.com> Wintek Corporation 427 N 6th Street Lafayette, IN 47901-2211 Main: 765-742-8428 Direct: 765-269-8541 ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Recently posted academic job vacancies at Computeroxy
Omaha, School of Interdisciplinary Informatics Senior Java Engineer PRIORITY! Sharp Laboratories of America (SLA) Senior Video Coding Researcher PRIORITY! Sharp Laboratories of America (SLA) Senior Communication Systems Researcher PRIORITY! Sharp Laboratories of America (SLA) Affiliate Faculty Position in Software Engineering Regis University, Department of Software Engineering Adjunct Faculty in Mathematics Northwood University, Department of Mathematics Visiting Assistant Professor of Mathematics State University of New York at Oswego, Department of Mathematics Assistant Professor of Mathematics Oral Roberts University, Department of Mathematics Adjunct Assistant Professor of Mathematics Johnson County Community College, Department of Mathematics Assistant Professor of Mathematics Clayton State University, Department of Mathematics Non-Tenure-Track Lecturer in Computer Engineering State University of New York at Geneseo, Department of Computer Engineering Faculty Position in Electronics Engineering Technology ECPI University, Department of Engineering Lecturer in Electrical Engineering Eastern Washington University, Department of Electrical Engineering Assistant Professor of Electrical Engineering Garrett College, Department of Electrical Engineering Adjunct Faculty Position in Electrical Engineering Wentworth Institute of Technology, Department of Electrical Engineering Lecturer in Electrical Engineering California State University, Department of Electrical Engineering Quarterly Adjunct Lecturers in Electrical Engineering Santa Clara University, Department of Electrical Engineering Adjunct Instructor in Computing Technology Marist College, Department of Computer Technology Assistant Professor of Systems Engineering Ashford University, Department of Systems Engineering Instructor in Software Engineering DePaul University, Department of Systems Engineering and many more at Computeroxy.com To learn more about these and other job vacancies, we invite you to visit our website www.computeroxy.com and/or to "register" and/or to "contact us". Want to post a job vacancy? Attract the attention of our academic audience of more than 320.000 professors, lecturers, researchers and academic managers who are at present employed in the highest-ranking schools of computer, electrical and mathematical sciences and engineering worldwide and who receive our specialised newsletters twice a month "post a job vacancy on Computeroxy" and/or to "contact us". Yours faithfully Richard Huber PhD COMPUTEROXY Your Academic Vacancies in Schools of Computer, Electrical and Mathematical Sciences and Engineering Europe - Asia - The Americas - Oceania - The Middle East - Africa computer...@computeroxy.com www.computeroxy.comIf you do not wish to receive Computeroxy newsletters or have received it in error, you may unsubscribe by replying to Computeroxy with the word "unsubscribe" in the subject line. Thank you very much. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Recently posted academic job vacancies at Computeroxy
Marymount California University, Division of Mathematics Assistant Professor of Power Systems and Power Electronics Southern Illinois University Carbondale, Department of Electrical and Computer Engineering Adjunct Instructor in Electrical Engineering Technology Gateway Technical College, Department of Electrical Engineering Technology Instructor in Electronics Engineering Technology Craven Community College Assistant/Associate Professor of Electrical Engineering Arkansas Tech University, Department of Electrical Engineering Adjunct Professor of Electrical Engineering Erie Community College, Department of Electrical Engineering Non-Tenure Track Faculty Position in Electrical Engineering Pennsylvania State University, Department of Electrical Engineering Instructor in Mathematics Keiser University, Department of Mathematics Visiting Assistant Professor of Maths Widener University, Department of Mathematics Assistant/Associate Professor of Mathematics North Greenville University, Department of Mathematics Professor of Mathematics Arizona Western College, Department of Mathematics Visiting Assistant Professor of Mathematics Champlain College, Department of Mathematics Adjunct Assistant Professor of Mathematics Johnson County Community College, Department of Mathematics Postdoctoral Scholar in Electrical Engineering University of California, Department of Electrical Engineering Faculty Assistant professor of Electrical Engineering University of New Haven, Department of Electrical & Computer Engineering Research Assistant Professor of Statistical Signal Processing Barron Associates and many more at Computeroxy.com To learn more about these and other job vacancies, we invite you to visit our website www.computeroxy.com and/or to "register" and/or to "contact us". Want to post a job vacancy? Attract the attention of our academic audience of more than 320.000 professors, lecturers, researchers and academic managers who are at present employed in the highest-ranking schools of computer, electrical and mathematical sciences and engineering worldwide and who receive our specialised newsletters twice a month "post a job vacancy on Computeroxy" and/or to "contact us". Yours faithfully Richard Huber PhD COMPUTEROXY Your Academic Vacancies in Schools of Computer, Electrical and Mathematical Sciences and Engineering Europe - Asia - The Americas - Oceania - The Middle East - Africa computer...@computeroxy.com www.computeroxy.comIf you do not wish to receive Computeroxy newsletters or have received it in error, you may unsubscribe by replying to Computeroxy with the word "unsubscribe" in the subject line. Thank you very much. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Recently posted academic job vacancies at Computeroxy
Keiser University, Department of Mathematics Visiting Assistant Professor of Mathematics Champlain College, Department of Mathematics Adjunct Assistant Professor of Mathematics Johnson County Community College, Department of Mathematics Adjunct Instructor in Math Newbury College, Department of Mathematics Instructor in Mathematics Northern Marianas College, Department of Mathematics Adjunct Instructor in Maths Marymount California University, Division of Mathematics Full Time Faculty Position in Mathematics Massasoit Community College, Division of Mathematics Head of Electronics Engineering Savannah Technical College Research Assistant Professor of Computer Science University of Houston, Department of Computer Science Visiting Assistant Professor of Computer Science Eastern Kentucky University, Department of Computer Science Professor of Computer Science Texas A University, Department of Computer Science Instructor in Computer Science Garden City Community College, Department of Computer Science Visiting Asst Professor/Instructor in Computer Science Miami University, Department of Computer Science Instructor in Computer Science Texas Southmost College, Department of Computer Science Lecturer in Information Systems University of Nevada, Department of Computer Science Faculty Position in Computer Science Texas Southmost College, Department of Computer Science Postdoctoral Research Associate in Computer Science Northeastern University, Department of Computer Science Faculty Position in Computer Programming University of Houston, Department of Computer Science Lecturer in Computer Science Princeton University, Department of Computer Science Assistant Professor of Computer Science Marywood University, Depatment of Computer Science Instructor in Computer Science University of Memphis, Depatment of Computer Science Chair in Software Engineering Iowa State University and many more at Computeroxy.com To learn more about these and other job vacancies, we invite you to visit our website www.computeroxy.com and/or to "register" and/or to "contact us". Want to post a job vacancy? Attract the attention of our academic audience of more than 320.000 professors, lecturers, researchers and academic managers who are at present employed in the highest-ranking schools of computer, electrical and mathematical sciences and engineering worldwide and who receive our specialised newsletters twice a month "post a job vacancy on Computeroxy" and/or to "contact us". Yours faithfully Richard Huber PhD COMPUTEROXY Your Academic Vacancies in Schools of Computer, Electrical and Mathematical Sciences and Engineering Europe - Asia - The Americas - Oceania - The Middle East - Africa computer...@computeroxy.com www.computeroxy.comIf you do not wish to receive Computeroxy newsletters or have received it in error, you may unsubscribe by replying to Computeroxy with the word "unsubscribe" in the subject line. Thank you very much. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Recently posted academic job vacancies at Computeroxy
, Department of Mathematics Assistant Professor of Electrical & Computer Engineering Bradley University, Department of Electrical and Computer Engineering and many more at Computeroxy.com To learn more about these and other job vacancies, we invite you to visit our website www.computeroxy.com and/or to "register" and/or to "contact us". Want to post a job vacancy? Attract the attention of our academic audience of more than 320.000 professors, lecturers, researchers and academic managers who are at present employed in the highest-ranking schools of computer, electrical and mathematical sciences and engineering worldwide and who receive our specialised newsletters twice a month "post a job vacancy on Computeroxy" and/or to "contact us". Yours faithfully Richard Huber PhD COMPUTEROXY Your Academic Vacancies in Schools of Computer, Electrical and Mathematical Sciences and Engineering Europe - Asia - The Americas - Oceania - The Middle East - Africa computer...@computeroxy.com www.computeroxy.comIf you do not wish to receive Computeroxy newsletters or have received it in error, you may unsubscribe by replying to Computeroxy with the word "unsubscribe" in the subject line. Thank you very much. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Recently posted academic job vacancies at Computeroxy
xas A University, Department of Electrical Engineering Non-Tenure Track Instructor in Robotics and Electrical Engineering University of Detroit Mercy, Department of Electrical and Computer Engineering Post Doctoral Fellow in Technology Rochester Institute of Technology Assistant Professor of Computer Science Johnson C. Smith University, Department of Computer Science Full-time Tenure-Track Faculty Position in Computer Science San Mateo County Community College District, Department of Computer Engineering Adjunct Faculty in Mathematics MCPHS University, Department of Mathematics Lecturer in Mathematics and Statistics Washburn University, Department of Mathematics Associate Chair of Mathematics Middlesex County College Postdoctoral Research Associate in Mathematical Sciences Delaware State University, Department of Mathematics Faculty Position in Robotics Johnson & Wales University, Department of Engineering Associate Professor of Mathematics Liberty University, Department of Mathematics Assistant Professor of Electronic Engineering Broward College, Department of Electronic Engineering Instructor in Electronic Engineering Technology Houston Community College, Department of Electronic Engineering Assistant Professor of Mathematics Adrian College, Department of Mathematics and many more at Computeroxy.com To learn more about these and other job vacancies, we invite you to visit our website www.computeroxy.com and/or to "register" and/or to "contact us". Want to post a job vacancy? Attract the attention of our academic audience of more than 320.000 professors, lecturers, researchers and academic managers who are at present employed in the highest-ranking schools of computer, electrical and mathematical sciences and engineering worldwide and who receive our specialised newsletters twice a month "post a job vacancy on Computeroxy" and/or to "contact us". Yours faithfully Richard Huber PhD COMPUTEROXY Your Academic Vacancies in Schools of Computer, Electrical and Mathematical Sciences and Engineering Europe - Asia - The Americas - Oceania - The Middle East - Africa computer...@computeroxy.com www.computeroxy.comIf you do not wish to receive Computeroxy newsletters or have received it in error, you may unsubscribe by replying to Computeroxy with the word "unsubscribe" in the subject line. Thank you very much. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Recently posted academic job vacancies at Computeroxy
nt of Electronic Engineering Instructor in Electronic Engineering Technology Houston Community College, Department of Electronic Engineering Faculty Position in Robotics Johnson & Wales University, Department of Engineering Assistant Professor of Computational Science and Engineering University of Tennessee at Chattanooga, Faculty of Engineering Lecturer in Computer Science Indiana State University, Faculty of Computer Engineering Assistant Professor of Digital Simulation & Gaming Shawnee State University, Faculty of Computer Engineering Postdoctoral Associate in Data Science MIT, Institute for Data, Systems, and Society Instructor in Computer Engineering Indiana State University, ECET Department Assistant Professor of Electrical Engineering Technology/Computer Engineering Technology Northeastern University, Division of Engineering Instructor in Computer Science Hartnell College, Department of Computer Science Postdoctoral Associate in Systems Engineering Boston University, Division of Systems Engineering Faculty Positions in Electrical Engineering Kennesaw State University, Department of Secondary & Middle Grades Education and many more at Computeroxy.com To learn more about these and other job vacancies, we invite you to visit our website www.computeroxy.com and/or to "register" and/or to "contact us". Want to post a job vacancy? Attract the attention of our academic audience of more than 320.000 professors, lecturers, researchers and academic managers who are at present employed in the highest-ranking schools of computer, electrical and mathematical sciences and engineering worldwide and who receive our specialised newsletters twice a month "post a job vacancy on Computeroxy" and/or to "contact us". Yours faithfully Richard Huber PhD COMPUTEROXY Your Academic Vacancies in Schools of Computer, Electrical and Mathematical Sciences and Engineering Europe - Asia - The Americas - Oceania - The Middle East - Africa computer...@computeroxy.com www.computeroxy.comIf you do not wish to receive Computeroxy newsletters or have received it in error, you may unsubscribe by replying to Computeroxy with the word "unsubscribe" in the subject line. Thank you very much. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Recently posted academic job vacancies at Computeroxy
nesaw State University, Department of Secondary & Middle Grades Education Instructor in Computer Engineering Indiana State University, ECET Department Postdoctoral Associate in Systems Engineering Boston University, Division of Systems Engineering Assistant Professor of Electrical Engineering Technology/Computer Engineering Technology Northeastern University, Division of Engineering Assistant Professor of Engineering Technology Sam Houston State University, School of Engineering Faculty Position in Electrical Engineering Bunker Hill Community College, School of Engineering Instructor in Electrical and Computer Engineering University of Alabama at Birmingham, School of Engineering and many more at Computeroxy.com To learn more about these and other job vacancies, we invite you to visit our website www.computeroxy.com and/or to "register" and/or to "contact us". Want to post a job vacancy? Attract the attention of our academic audience of more than 320.000 professors, lecturers, researchers and academic managers who are at present employed in the highest-ranking schools of computer, electrical and mathematical sciences and engineering worldwide and who receive our specialised newsletters twice a month "post a job vacancy on Computeroxy" and/or to "contact us". Yours faithfully Richard Huber PhD COMPUTEROXY Your Academic Vacancies in Schools of Computer, Electrical and Mathematical Sciences and Engineering Europe - Asia - The Americas - Oceania - The Middle East - Africa computer...@computeroxy.com www.computeroxy.comIf you do not wish to receive Computeroxy newsletters or have received it in error, you may unsubscribe by replying to Computeroxy with the word "unsubscribe" in the subject line. Thank you very much. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
New academic vacancies at Computeroxy
RITY! The University of Virginia School of Engineering and Applied Science Chair of Web Design Ashford University, College of Liberal Arts Assistant Professor of Computer Science University of Colorado, Department of Computer Science Faculty Position in Developmental Mathematics Austin Community College, Department of Mathematics Chair of Computer Science and Database Technology Ashford University Assistant Professor of Computer Science Xavier University, Department of Computer Science Open Rank Tenure Track Faculty Position in Electrical and Computer Engineering Chicago Computer Science Department, University of Illinois Non-Tenure Track Teaching Faculty in Computer Science Chicago Computer Science Department, University of Illinois Faculty Position in Computer Security Chicago Computer Science Department, University of Illinois Lecturer in Mathematics Department of Mathematics, University of California, Berkeley Lecturer in Department of Mathematics University of California Berkeley Lecturer in Electrical Engineering and Computer Science University of California Berkeley Lecturer in Electrical Engineering University of California Lecturer in Mathematics University of California and many more at Computeroxy.com To learn more about these and other job vacancies, we invite you to visit our website www.computeroxy.com and/or to "register" and/or to "contact us". Want to post a job vacancy? Attract the attention of our academic audience of more than 320.000 professors, lecturers, researchers and academic managers who are at present employed in the highest-ranking schools of computer, electrical and mathematical sciences and engineering worldwide and who receive our specialised newsletters twice a month "post a job vacancy on Computeroxy" and/or to "contact us". Yours faithfully Richard Huber PhD COMPUTEROXY Your Academic Vacancies in Schools of Computer, Electrical and Mathematical Sciences and Engineering Europe - Asia - The Americas - Oceania - The Middle East - Africa computer...@computeroxy.com www.computeroxy.comIf you do not wish to receive Computeroxy newsletters or have received it by mistake, you may unsubscribe by replying to Computeroxy with the word "unsubscribe" in the subject line. Thank you very much. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
New academic vacancies at Computeroxy
pace Engineering University of Virginia Candidates (all ranks) in Energy Transfer PRIORITY! The Department of Mechanical and Aerospace Engineering University of Virginia Assistant Professor (Multiple Positions) in Autonomous Vehicles and Systems PRIORITY! Department of Aerospace and Mechanical Engineering University of Arizona Professor of Practice, Information Systems PRIORITY! Le Moyne College Syracuse, New York Eight (8) Faculty Positions in Cyber-Physical Systems PRIORITY! The University of Virginia School of Engineering and Applied Science Faculty Position in Computer Science Department of Computer & Mathematics, Dallas County Community College Non-Tenure Track Teaching Faculty in Computer Science Chicago Computer Science Department, University of Illinois Faculty Position in Math Department of Computer & Mathematics, Dallas County Community College Faculty Position in Computer Security Chicago Computer Science Department, University of Illinois Open Rank Tenure Track Faculty Position in Electrical and Computer Engineering Chicago Computer Science Department, University of Illinois Faculty Position in Mathematics Department of Computer & Mathematics, Dallas County Community College Part-time Faculty Position in Electrical Engineering Technology Department of Electrical and Computer Engineering Technology, Kennesaw State University Lecturer in Mathematics Department of Mathematics, University of California, Berkeley Lecturer in Electrical Engineering and Computer Science University of California Berkeley Lecturer in Department of Mathematics University of California Berkeley Lecturer in Electrical Engineering University of California Lecturer in Mathematics University of California and many more at Computeroxy.com To learn more about these and other job vacancies, we invite you to visit our website www.computeroxy.com and/or to "register" and/or to "contact us". Want to post a job vacancy? Attract the attention of our academic audience of more than 320.000 professors, lecturers, researchers and academic managers who are at present employed in the highest-ranking schools of computer, electrical and mathematical sciences and engineering worldwide and who receive our specialised newsletters twice a month "post a job vacancy on Computeroxy" and/or to "contact us". Yours faithfully Richard Huber PhD COMPUTEROXY Your Academic Vacancies in Schools of Computer, Electrical and Mathematical Sciences and Engineering Europe - Asia - The Americas - Oceania - The Middle East - Africa computer...@computeroxy.com www.computeroxy.comIf you do not wish to receive Computeroxy newsletters or have received it by mistake, you may unsubscribe by replying to Computeroxy with the word "unsubscribe" in the subject line. Thank you very much. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Virtualbox on my new Dell 7810
Hi all, I'm having another issue with my new desktop machine, this time with Virtualbox. I originally sent this to freebsd-emulation a few days ago, but I haven't had any response. I'm hoping someone here can help me. My machine is running FreeBSD 10.2-PRERELEASE #2 r284595 with a GENERIC kernel. I built installed virtualbox-ose-4.3.28 (and kmod, of course) from ports. /etc/make.conf contains NO_LPR=yes NO_PROFILE= true CUPS_OVERWRITE_BASE=yes OPTIONS_SET= OPTIMIZED_CFLAGS OPTIONS_UNSET= NLS DEFAULT_VERSIONS=python=2.7 python2=2.7 gcc=4.9 bdb=5 perl=5.22 At boot, I now see the following: vboxdrv: fAsync=1 offMin=0x3ae80 offMax=0x3ae80 supdrvGipCreate: omni timer not supported, falling back to synchronous mode I've never seen the supdrvGipCreate message before. I first moved a 32 bit Windows 7 VM from my old desktop which was running a FreeBSD-stable a week or 2 old (literally; I took the drive out of the old machine). The first time I tried to boot the VM it took about 7 minutes. The CPU I allocated to the VM stayed at 100%. After some googling, I turned off hyperthreading in the 7810's BIOS. The VM now boots in a reasonable time and is almost usable. It'll be ok for 2 or 3 seconds, then almost freeze up for a little while (so far always less than a minute), and then be ok again for a few seconds. When it 'freezes up' its CPU is at 100%. As a test I started installing a 64 bit Windows 8.1 VM. It behaves exactly the same way. Does anyone have any ideas or suggestions? I'm hoping there's a BIOS setting I can tweak to make this work. Thanks in advance! -- Richard Kuhns r...@wintek.com Main Number: 765-742-8428 Wintek Corporation Direct: 765-269-8541 427 N 6th Street Internet Support: 765-269-8503 Lafayette, IN 47901-2211 Consulting: 765-269-8504 ___ 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: Getting going with a new Dell 7810
On 06/17/15 11:43, Adam McDougall wrote: On 06/16/2015 12:55, Richard Kuhns wrote: Greetings all, I've just received a new Dell Precision 7810. I've installed FreeBSD 10.1 (UEFI boot), checked out sources, built world kernel and am now running r284449. So far, so good. The problem is Xorg. I'm running the latest Xorg in ports; I just did a 'make install clean' in /usr/ports/x11/xorg with no errors. The display card is a FirePro W4100. lspci shows: 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde GL [FirePro W4100] If it is brand new, it is probably not supported and probably won't be for a while. Please see https://wiki.freebsd.org/Graphics for a list of devices which does include your Radeon HD 4670. That's what I was afraid of. I was hoping that the message that it was using syscons when my machine was using vt had something to do with it, but based on a couple of other messages that isn't the case. Thanks! -- Richard Kuhns r...@wintek.com Main Number: 765-742-8428 Wintek Corporation Direct: 765-269-8541 427 N 6th Street Internet Support: 765-269-8503 Lafayette, IN 47901-2211 Consulting: 765-269-8504 ___ 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
Getting going with a new Dell 7810
Greetings all, I've just received a new Dell Precision 7810. I've installed FreeBSD 10.1 (UEFI boot), checked out sources, built world kernel and am now running r284449. So far, so good. The problem is Xorg. I'm running the latest Xorg in ports; I just did a 'make install clean' in /usr/ports/x11/xorg with no errors. The display card is a FirePro W4100. lspci shows: 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde GL [FirePro W4100] It has 4 DisplayPorts, and I have 2 monitors plugged in. If I run 'Xorg -configure' it says Number of created screens does not match number of detected devices. Configuration failed. Looking through /var/log/Xorg.0.log it appears that the X server is trying to use the RADEON driver, but ends with: = [ 1292.463] (--) Using syscons driver with X support (version 2.0) [ 1292.463] (--) using VT number 9 [ 1292.485] (II) [KMS] Kernel modesetting enabled. [ 1292.485] (WW) Falling back to old probe method for vesa [ 1292.485] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 1292.485] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [ 1292.485] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [ 1292.485] (==) RADEON(0): Default visual is TrueColor [ 1292.485] (==) RADEON(0): RGB weight 888 [ 1292.485] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [ 1292.485] (--) RADEON(0): Chipset: VERDE (ChipID = 0x682c) [ 1292.579] (EE) RADEON(0): [drm] Failed to open DRM device for pci::03:00.0: No such file or directory [ 1292.579] (EE) RADEON(0): Kernel modesetting setup failed [ 1292.579] (II) UnloadModule: radeon [ 1292.579] (EE) Screen(s) found, but none have a usable configuration. [ 1292.579] (EE) Fatal server error: [ 1292.579] (EE) no screens found(EE) [ 1292.580] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 1292.580] (EE) Please also check the log file at /var/log/Xorg.0.log for additional information. [ 1292.580] (EE) [ 1292.580] (EE) Server terminated with error (1). Closing log file. Should I be able to use this video card? I've done some googling, and apparently at least some Linux people are using it. It's not a huge deal if it doesn't work; I can install a Radeon HD 4670 that I know works. If I've mis-configured something, though, I'd like to fix it. Thanks for any comments! -- Richard Kuhns r...@wintek.com Main Number: 765-742-8428 Wintek Corporation Direct: 765-269-8541 427 N 6th Street Internet Support: 765-269-8503 Lafayette, IN 47901-2211 Consulting: 765-269-8504 ___ 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: Getting going with a new Dell 7810
On 06/16/15 15:58, John Nielsen wrote: On Jun 16, 2015, at 12:39 PM, Ronald Klop ronald-li...@klop.ws wrote: What does 'sysctl kern.vty' say? If it is not 'vt', you need the following stuff. /boot/loader.conf should contain kern.vty=vt And /etc/rc.conf kld_list=radeonkms Or something similar. FreeBSD is in the transition of old-style syscons- and vt-terminal. The last one has support for modern KMS graphics, but is not the default on 10 yet. With UEFI boot it will be using vt but with the efifb driver by default. Hopefully loading the radeon KMS driver (as Ronald suggests above) will let it take over. Try it with just a “kldload radeonkms” before adding it to rc.conf, just in case something gets wedged.. As you said, it is using vt. Unfortunately loading radeonkms didn't help. It actually seems to be a regression; the only RADEON line /var/log/Xorg.0.log now is the one that lists all the supported chipsets. Immediately after that line it ends with [ 4005.835] (II) VESA: driver for VESA chipsets: vesa [ 4005.835] (++) Using config file: /home/rjk/xorg.conf.new [ 4005.836] (==) ServerLayout X.org Configured [ 4005.836] (**) |--Screen Screen0 (0) [ 4005.836] (**) | |--Monitor Monitor0 [ 4005.836] (**) | |--Device Card0 [ 4005.836] (**) |--Screen Screen1 (1) [ 4005.836] (**) | |--Monitor Monitor1 [ 4005.836] (**) | |--Device Card1 [ 4005.836] (**) |--Input Device Mouse0 [ 4005.836] (**) |--Input Device Keyboard0 [ 4005.836] (==) Automatically adding devices [ 4005.836] (==) Automatically enabling devices [ 4005.836] (==) Not automatically adding GPU devices [ 4005.836] (**) FontPath set to: /usr/local/share/fonts/misc/, /usr/local/share/fonts/TTF/, /usr/local/share/fonts/OTF/, /usr/local/share/fonts/Type1/, /usr/local/share/fonts/100dpi/, /usr/local/share/fonts/75dpi/, /usr/local/share/fonts/misc/, /usr/local/share/fonts/TTF/, /usr/local/share/fonts/OTF/, /usr/local/share/fonts/Type1/, /usr/local/share/fonts/100dpi/, /usr/local/share/fonts/75dpi/ [ 4005.836] (**) ModulePath set to /usr/local/lib/xorg/modules [ 4005.836] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. [ 4005.836] (WW) Disabling Mouse0 [ 4005.836] (WW) Disabling Keyboard0 [ 4005.836] (II) [KMS] Kernel modesetting enabled. [ 4005.836] (WW) Falling back to old probe method for vesa [ 4005.836] Number of created screens does not match number of detected devices. Configuration failed. [ 4005.836] (EE) Server terminated with error (2). Closing log file. I noticed in the previous log that it said [ 1292.463] (--) Using syscons driver with X support (version 2.0) which made me think I had something set up incorrectly, since it's using vt, not syscons. On Tue, 16 Jun 2015 18:55:10 +0200, Richard Kuhns r...@wintek.com wrote: Greetings all, I've just received a new Dell Precision 7810. I've installed FreeBSD 10.1 (UEFI boot), checked out sources, built world kernel and am now running r284449. So far, so good. The problem is Xorg. I'm running the latest Xorg in ports; I just did a 'make install clean' in /usr/ports/x11/xorg with no errors. The display card is a FirePro W4100. lspci shows: 03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde GL [FirePro W4100] It has 4 DisplayPorts, and I have 2 monitors plugged in. If I run 'Xorg -configure' it says Number of created screens does not match number of detected devices. Configuration failed. Looking through /var/log/Xorg.0.log it appears that the X server is trying to use the RADEON driver, but ends with: = [ 1292.463] (--) Using syscons driver with X support (version 2.0) [ 1292.463] (--) using VT number 9 [ 1292.485] (II) [KMS] Kernel modesetting enabled. [ 1292.485] (WW) Falling back to old probe method for vesa [ 1292.485] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 1292.485] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [ 1292.485] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [ 1292.485] (==) RADEON(0): Default visual is TrueColor [ 1292.485] (==) RADEON(0): RGB weight 888 [ 1292.485] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [ 1292.485] (--) RADEON(0): Chipset: VERDE (ChipID = 0x682c) [ 1292.579] (EE) RADEON(0): [drm] Failed to open DRM device for pci::03:00.0: No such file or directory [ 1292.579] (EE) RADEON(0): Kernel modesetting setup failed [ 1292.579] (II) UnloadModule: radeon [ 1292.579] (EE) Screen(s) found, but none have a usable configuration. [ 1292.579] (EE) Fatal server error: [ 1292.579] (EE) no screens found(EE) [ 1292.580] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 1292.580] (EE) Please also check the log file at /var/log/Xorg.0.log
Re: Problem building world (amd64) this morning
On 04/10/15 16:42, Dimitry Andric wrote: On 10 Apr 2015, at 21:32, Michael Grimm trash...@odo.in-berlin.de wrote: Dimitry Andric d...@freebsd.org wrote: On 10 Apr 2015, at 20:55, Michael Grimm trash...@odo.in-berlin.de wrote: I can confirm that. r281288 compiles without failing, r281289 fails. I've tried all possible ways of reproducing this problem, but it always works for me. Can somebody who experiences the problem please do a clean build using script(1), and post the full build log somewhere? Preferably a make buildworld without -j, so commands are not interspersed. Compilation at r281289 is on its way. I'll send you a link after completion. Thanks, but you can stop that compilation now. :) I finally managed to reproduce the problem, and it turns out I also had to MFC r272814 and r272815, which I have done in r281382. That should really fix it properly... Sorry for the breakage. -Dimitry Checking back in after being offline for a couple of days, I find it's fixed :-) Many thanks! -- Richard Kuhns r...@wintek.com Main Number: 765-742-8428 Wintek Corporation Direct: 765-269-8541 427 N 6th Street Internet Support: 765-269-8503 Lafayette, IN 47901-2211 Consulting: 765-269-8504 ___ 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: Help with filing a [maybe] ZFS/mmap bug.
On Thu, Jul 18, 2013 at 11:40:51AM -0700, George Hartzell wrote: Removing the mmap support from those two routines seems to avoid the issue. Aha. If so, then the issue is triggered by one or both of those two routines; hack them to print out the exact offsets used on each call and use that to try and code up a simple C++ test case. [...] Your test case doesn't use mmap, I assume that you've offered it up as a hint, not as something that's nearly done. The shell script in particular seems useful. Um, go look at gen4.cpp again. It uses mmap(). The insert_bytes and delete_bytes functions should work the same way as the (mmap-using path of) the functions of the same name in py-mutagen. In my case I'd want to find a particular set of file size, offset, and insertion size that triggers the problem and code up a c/c++ equiv. of the mmap calls that py-mutagen does. Right? Yeah. ___ 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: Help with filing a [maybe] ZFS/mmap bug.
George Hartzell hartz...@alerce.com writes:
Hi All,
I have what I think is a ZFS related bug. Unfortunately my simplest
test case is a bit cumbersome and I haven't definitively proven that
the problem is ZFS related.
I'm hoping for some feedback on how to move forward.
Quick background: I rip my CD's using grip and produce flac files. I
tag the music using Musicbrainz' Picard and transcode it to mp3's
within Picard using a plugin that I wrote. Picard is a python based
app and uses the Mutagen library to tag files.
[summary: Picard seems to trigger an mmap consistency bug in ZFS].
Aw, crud. I ran into what may be this same issue a few years ago,
under almost identical circumstances (picard with Ogg files instead of
flac), but never got around to writing up a proper mailinglist post on it.
I *thought* it had been fixed some time back, though I'm not entirely
sure because I've been running with my local patch to py-mutagen to disable
its mmap() usage.
Anyway, here's what I recall from when I was trying to track this down way
back when:
1) Your suspicions are right, it's definitely a ZFS/mmap interaction bug.
UFS filesystems didn't show the bug.
2) It's triggered by the insert_bytes or delete_bytes function in py-mutagen.
3) As long as the in-memory version of that chunk of the file stuck around
in memory, the file read OK, but the data on disk was corrupt, so if that
data got evicted from cache and had to be reread, or if you forced the
cache data to be disposed of by unmounting and remounting the FS, you would
see a corrupt file. (Rebooting, of course, would also allow the corrupted
file data to become visible again.)
I'll attach my patch to disable py-mutagen's mmap usage in insert/delete_bytes
below. Try it and see if it makes the corruption problems go away. If so,
that narrows your search down to those two routines in py-mutagen and what
they're doing.
I *had* what at the time I recall was a simple C++ test program that
managed to trigger the bug more-or-less reliably. Unfortunately, it
doesn't look like my test case still works, i.e., the test program
doesn't seem to trigger the bug either on the 10-CURRENT box or RELENG-9
VM I'm trying them on now. As I recall, the bug's presence was dependent on
fairly picky details on what exact offsets were used on the mmap()s and the
write()s, so it may be that different offsets from what I tried will still show
the bug.
Anyway, what I'd suggest is the following: see if my patch for py-mutagen
disabling the mmap() in those two functions lets you run picard reliably.
If so, then the issue is triggered by one or both of those two routines;
hack them to print out the exact offsets used on each call and use that to
try and code up a simple C++ test case.
Here's the py-mutagen patch:
--- mutagen/_util.py.orig 2008-06-01 01:33:00.0 -0500
+++ mutagen/_util.py2009-04-11 18:16:53.363758128 -0500
@@ -213,12 +213,6 @@
fobj.write('\x00' * size)
fobj.flush()
try:
-try:
-import mmap
-map = mmap.mmap(fobj.fileno(), filesize + size)
-try: map.move(offset + size, offset, movesize)
-finally: map.close()
-except (ValueError, EnvironmentError, ImportError):
# handle broken mmap scenarios
locked = lock(fobj)
fobj.truncate(filesize)
@@ -272,17 +266,11 @@
try:
if movesize 0:
fobj.flush()
-try:
-import mmap
-map = mmap.mmap(fobj.fileno(), filesize)
-try: map.move(offset, offset + size, movesize)
-finally: map.close()
-except (ValueError, EnvironmentError, ImportError):
-# handle broken mmap scenarios
-locked = lock(fobj)
-fobj.seek(offset + size)
-buf = fobj.read(BUFFER_SIZE)
-while buf:
+# handle broken mmap scenarios
+locked = lock(fobj)
+fobj.seek(offset + size)
+buf = fobj.read(BUFFER_SIZE)
+while buf:
fobj.seek(offset)
fobj.write(buf)
offset += len(buf)
and here's my test case:
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering sh file. Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# gen4.cpp
# test4.sh
#
echo x - gen4.cpp
sed 's/^X//' gen4.cpp 'END-of-gen4.cpp'
X/*
X** Program to create a file of data and do some mmap()ing writes to it.
X*/
X
X#include stdio.h
X#include stdlib.h
X#include stdint.h
X#include unistd.h
X#include string.h
X#include fcntl.h
X#include sys/types.h
X#include sys/mman.h
X
X/* Insert size bytes (zeros) into file at offset */
Xvoid
Xinsert_bytes(int fd, unsigned int size, unsigned int offset)
X{
Re: shutdown -r / shutdown -h / reboot all hang and don't cleanly dismount
On 19/06/2013 12:35, Adam Strohl wrote: Hello -STABLE@, So I've seen this situation seemingly randomly on a number of both physical 9.1 boxes as well as VMs for I would say 6-9 months at least. I finally have a physical box here that reproduces it consistently that I can reboot easily (ie; not a production/client server). No matter what I do: reboot shutdown -p shutdown -r This specific server will stop at All buffers synced and not actually power down or reboot. KB input seems to be ignored. This server is a ZFS NAS (with GMIRROR for boot blocks) but the other boxes which show this are using GMIRRORs for root/swap/boot (no ZFS). Here is what happens on the console: http://i.imgur.com/1H8JMyB.jpg Hi, Just to add a 'me too'. I see this on two different boxes, both currently running recentish 9.1-STABLE, and it has definitely been an issue for me since at least 9.0-RELEASE. One of the boxes is a Dell R210 II with a single WD HDD - dmesg: http://daniel.thekeelecentre.com/dmesg.txt I've tried booting/rebooting without the USB KVM dongle attached too. Notes - does not run moused and no OpenLDAP. The second host I have the issue with is a home-build using a Tyan Toledo i3210W (S5211) and two Seagate HDDs - dmesg: http://daniel.thekeelecentre.com/dmesg-daffy.txt (yes, a disk has failed, but the reboot issue pre-dated this). Note - does not run moused, but did run slapd. I saw the same DB corruption as the OP. I can play with the latter box as it is no longer in use and will try the following suggestions from Jeremy later this evening: 4. Does sysctl hw.usb.no_shutdown_wait=1 help you? 5. Does sysctl hw.acpi.handle_reboot=1 help you? 6. Does sysctl hw.acpi.disable_on_reboot=1 help you? Regards, Richard ___ 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: Sanity Check on Mac Mini
On 03/07/13 17:18, Doug Hardie wrote: On 7 March 2013, at 11:57, Kevin Oberman rkober...@gmail.com wrote: On Thu, Mar 7, 2013 at 11:10 AM, Doug Hardie bc...@lafn.org wrote: On 7 March 2013, at 06:42, Richard Kuhns r...@wintek.com wrote: On 03/07/13 01:59, Doug Hardie wrote: I have a new Mac Mini and have encountered the same problem reported last year by Richard Kuhns. YongHyeon PYUN provided some patches to the kernel that resolved the problem. However, without an internet connection its a bit tricky to get them into the system. Here is the approach I believe will work, but wanted to check first before I really mess things up. 1. Downloaded from current today via svnweb.freebsd.org: sys/dev/bge/if_bgereg.h sys/dev/bge/if_bge.c sys/dev/mii/brgphy.c I believe the patches are incorporated in today's versions. The comments indicate such. Thus I don't need to apply the original supplied patch. 2. Put those on a flash drive. 3. Install 9.1 release from flash drive onto the Mini disk. Have to include the system source. 4. Copy the files from 1 above from flash over the files on the disk. 5. Rebuild the kernel and install it. Thanks, -- Doug That's worked for me 3 times now. Thanks. Well, I got 9.1 Release installed, but it won't boot from the internal disk. It doesn't see the disk as bootable. I installed using the entire disk for FreeBSD. I used the i386 release. Perhaps I need to switch to the amd64 release? I would generally recommend using the amd64 release, but it may not get your system to boot. How is your disk partitioned? GPT? Some BIOSes are broken and assume that a GPT formatted disk is UEFI and will not recognize them if they lack the UEFI boot partition. UEFI boot is a current project that seems likely to reach head in the fairly near future, but it's not possible now. No idea what the default partitioning is for BSDInstall. However the Mini is only EFI or UFEI with some fallbacks although the comments I find in the web indicate that different models have different fallbacks. One comment indicates that an older unit will boot if its MBR partitioning. I don't know if the new installer supports that or not. You may be able to tweak your BIOS to get it to work or you may have to install using the traditional partitioning system. The installer defaults to GPT, but can create either. I have such a system (ThinkPad T520) and I have two disks... one that came with the system and containing Windows, and my GPT formatted FreeBSD disk. I wrote a FreeBSD BootEasy boot into the MBR of the Windows disk and it CAN boot the GPT disk just fine. Not ideal for most, but it works well for me Based on a comment I say, waiting till the empty folder icon appears and then plugging in the install memstick causes the mini to boot from disk. That just downright weird, but it works. I could live with that, but this is an unattended server and would experience some down time if I am not there when there is a power failure. I just found some instructions for using MBR with bsdinstall, but given there is an effort to create a UEFI boot which I suspect would expect to find the GPT boot partition, perhaps I should just go with the memstick approach? -- Doug FWIW, here are the brief notes I made for what has been working for me for the last year or so; most recently with a new Mini purchased about 2 weeks ago. I'm using the entire drive for FreeBSD. Hit Option key while booting, then select 'Windows' USB image. Now trying GPT; looks fine, but will only boot with USB stick in place. If it's not there, just get a folder with a '?' when starting up. Using MBR; boots ok without USB stick. It just takes about 30 seconds before it actually boots. Select YES when asked about GMT. -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: Sanity Check on Mac Mini
On 03/07/13 01:59, Doug Hardie wrote: I have a new Mac Mini and have encountered the same problem reported last year by Richard Kuhns. YongHyeon PYUN provided some patches to the kernel that resolved the problem. However, without an internet connection its a bit tricky to get them into the system. Here is the approach I believe will work, but wanted to check first before I really mess things up. 1. Downloaded from current today via svnweb.freebsd.org: sys/dev/bge/if_bgereg.h sys/dev/bge/if_bge.c sys/dev/mii/brgphy.c I believe the patches are incorporated in today's versions. The comments indicate such. Thus I don't need to apply the original supplied patch. 2. Put those on a flash drive. 3. Install 9.1 release from flash drive onto the Mini disk. Have to include the system source. 4. Copy the files from 1 above from flash over the files on the disk. 5. Rebuild the kernel and install it. Thanks, -- Doug That's worked for me 3 times now. -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: bge on the new Mac Mini
On 11/28/12 19:08, YongHyeon PYUN wrote: On Wed, Nov 28, 2012 at 10:12:05AM -0500, Richard Kuhns wrote: On 11/27/12 19:19, YongHyeon PYUN wrote: On Tue, Nov 27, 2012 at 08:34:13AM -0500, Richard Kuhns wrote: On 11/27/12 00:24, YongHyeon PYUN wrote: On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: On 11/21/12 21:08, YongHyeon PYUN wrote: On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: On 11/20/12 03:52, YongHyeon PYUN wrote: On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: Hi all, Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac Minis via the memstick image; they seem to be pretty good little boxes for things like offsite secondary nameservers, for example, and they're easily replaced in case of problems. However, the newest minis have slightly different hardware, and FreeBSD can't find the built-in NIC. pciconf -lv on the new mini shows it as none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 rev=0x01 It seems this controller is BCM57766. hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet The previous edition mini (that works) reports bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' class = network subclass = ethernet Is there a chance that adding the new card/chip info to the current driver would allow it to work? I'll be happy to test and report back. I'm afraid I'm not familiar enough with hardware at that level to figure out the patch myself. Try attached patch and let me know whether the patch works or not. If the patch works please share dmesg output(bge(4) and brgphy(4) output only). Note, the patch was generated against CURRENT. I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h from I guess you also need to copy brgphy.c from HEAD to /usr/src/sys/dev/mii directory. HEAD using svnweb.freebsd.org. The patch installed cleanly and there were no errors during the build, but still no NIC. Does it mean you're not seeing bge0 interface? Or you can't pass any traffic via bge0? Oops, it seems I've not included your device ID in the diff. Try attach one instead. Make sure you use brgphy.c from HEAD. There's progress! With your latest patch using brgphy.c, if_bge.c, and if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the moment I try to configure it the box locks up completely; it won't even toggle the caps lock LED. Booting single user and running ifconfig shows: bge0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether a8:20:66:11:3b:d6 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active I did a verbose boot; here's the part that seems to be relevant to bge0: bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x57766001 mem 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E ^ All these information are garbage which indicates a bug in the diff. miibus0: MII bus on bge0 brgphy0: BCM57765 1000BASE-T media interface PHY 1 on miibus0 brgphy0: OUI 0x001be9, model 0x0024, rev. 1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: a8:20:66:11:3b:d6 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 I greatly appreciate your efforts. I'm sorry for the delay getting back with you, but we had a busy Thanksgiving weekend. Try again with attached bge.57766.diff3. Thanks for testing! I don't think the patch actually got attached :-( Oops, attached. And there was great rejoicing... It seems to take longer than I'm used to for it to decide it has link (about halfway through 'waiting for the default route interface'), but it works! Great. Could you show me dmesg(bge(4) and brgphy(4) only) and ifconfig bge0 output? Sure. Here's the 'ifconfig bge0' output: bge0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c019bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE ether a8:20:66:11:3b:d6 inet 172.28.1.90 netmask 0xff00 broadcast 172.28.1.255 inet6 fe80::aa20:66ff:fe11:3bd6%bge0 prefixlen 64 scopeid 0x2 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active And here's the dmesg output
Re: bge on the new Mac Mini
On 11/27/12 19:19, YongHyeon PYUN wrote: On Tue, Nov 27, 2012 at 08:34:13AM -0500, Richard Kuhns wrote: On 11/27/12 00:24, YongHyeon PYUN wrote: On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: On 11/21/12 21:08, YongHyeon PYUN wrote: On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: On 11/20/12 03:52, YongHyeon PYUN wrote: On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: Hi all, Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac Minis via the memstick image; they seem to be pretty good little boxes for things like offsite secondary nameservers, for example, and they're easily replaced in case of problems. However, the newest minis have slightly different hardware, and FreeBSD can't find the built-in NIC. pciconf -lv on the new mini shows it as none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 rev=0x01 It seems this controller is BCM57766. hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet The previous edition mini (that works) reports bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' class = network subclass = ethernet Is there a chance that adding the new card/chip info to the current driver would allow it to work? I'll be happy to test and report back. I'm afraid I'm not familiar enough with hardware at that level to figure out the patch myself. Try attached patch and let me know whether the patch works or not. If the patch works please share dmesg output(bge(4) and brgphy(4) output only). Note, the patch was generated against CURRENT. I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h from I guess you also need to copy brgphy.c from HEAD to /usr/src/sys/dev/mii directory. HEAD using svnweb.freebsd.org. The patch installed cleanly and there were no errors during the build, but still no NIC. Does it mean you're not seeing bge0 interface? Or you can't pass any traffic via bge0? Oops, it seems I've not included your device ID in the diff. Try attach one instead. Make sure you use brgphy.c from HEAD. There's progress! With your latest patch using brgphy.c, if_bge.c, and if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the moment I try to configure it the box locks up completely; it won't even toggle the caps lock LED. Booting single user and running ifconfig shows: bge0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether a8:20:66:11:3b:d6 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active I did a verbose boot; here's the part that seems to be relevant to bge0: bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x57766001 mem 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E ^ All these information are garbage which indicates a bug in the diff. miibus0: MII bus on bge0 brgphy0: BCM57765 1000BASE-T media interface PHY 1 on miibus0 brgphy0: OUI 0x001be9, model 0x0024, rev. 1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: a8:20:66:11:3b:d6 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 I greatly appreciate your efforts. I'm sorry for the delay getting back with you, but we had a busy Thanksgiving weekend. Try again with attached bge.57766.diff3. Thanks for testing! I don't think the patch actually got attached :-( Oops, attached. And there was great rejoicing... It seems to take longer than I'm used to for it to decide it has link (about halfway through 'waiting for the default route interface'), but it works! I've just installed subversion, and I'm doing an 'svn co' of stable/9. Many thanks for the work you've done! -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: bge on the new Mac Mini
On 11/27/12 00:24, YongHyeon PYUN wrote: On Mon, Nov 26, 2012 at 10:13:47AM -0500, Richard Kuhns wrote: On 11/21/12 21:08, YongHyeon PYUN wrote: On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: On 11/20/12 03:52, YongHyeon PYUN wrote: On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: Hi all, Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac Minis via the memstick image; they seem to be pretty good little boxes for things like offsite secondary nameservers, for example, and they're easily replaced in case of problems. However, the newest minis have slightly different hardware, and FreeBSD can't find the built-in NIC. pciconf -lv on the new mini shows it as none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 rev=0x01 It seems this controller is BCM57766. hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet The previous edition mini (that works) reports bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' class = network subclass = ethernet Is there a chance that adding the new card/chip info to the current driver would allow it to work? I'll be happy to test and report back. I'm afraid I'm not familiar enough with hardware at that level to figure out the patch myself. Try attached patch and let me know whether the patch works or not. If the patch works please share dmesg output(bge(4) and brgphy(4) output only). Note, the patch was generated against CURRENT. I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h from I guess you also need to copy brgphy.c from HEAD to /usr/src/sys/dev/mii directory. HEAD using svnweb.freebsd.org. The patch installed cleanly and there were no errors during the build, but still no NIC. Does it mean you're not seeing bge0 interface? Or you can't pass any traffic via bge0? Oops, it seems I've not included your device ID in the diff. Try attach one instead. Make sure you use brgphy.c from HEAD. There's progress! With your latest patch using brgphy.c, if_bge.c, and if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the moment I try to configure it the box locks up completely; it won't even toggle the caps lock LED. Booting single user and running ifconfig shows: bge0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether a8:20:66:11:3b:d6 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active I did a verbose boot; here's the part that seems to be relevant to bge0: bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x57766001 mem 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E ^ All these information are garbage which indicates a bug in the diff. miibus0: MII bus on bge0 brgphy0: BCM57765 1000BASE-T media interface PHY 1 on miibus0 brgphy0: OUI 0x001be9, model 0x0024, rev. 1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: a8:20:66:11:3b:d6 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 I greatly appreciate your efforts. I'm sorry for the delay getting back with you, but we had a busy Thanksgiving weekend. Try again with attached bge.57766.diff3. Thanks for testing! I don't think the patch actually got attached :-( -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: bge on the new Mac Mini
On 11/21/12 21:08, YongHyeon PYUN wrote: On Thu, Nov 22, 2012 at 10:49:21AM +0900, YongHyeon PYUN wrote: On Wed, Nov 21, 2012 at 02:59:34PM -0500, Richard Kuhns wrote: On 11/20/12 03:52, YongHyeon PYUN wrote: On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: Hi all, Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac Minis via the memstick image; they seem to be pretty good little boxes for things like offsite secondary nameservers, for example, and they're easily replaced in case of problems. However, the newest minis have slightly different hardware, and FreeBSD can't find the built-in NIC. pciconf -lv on the new mini shows it as none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 rev=0x01 It seems this controller is BCM57766. hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet The previous edition mini (that works) reports bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' class = network subclass = ethernet Is there a chance that adding the new card/chip info to the current driver would allow it to work? I'll be happy to test and report back. I'm afraid I'm not familiar enough with hardware at that level to figure out the patch myself. Try attached patch and let me know whether the patch works or not. If the patch works please share dmesg output(bge(4) and brgphy(4) output only). Note, the patch was generated against CURRENT. I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h from I guess you also need to copy brgphy.c from HEAD to /usr/src/sys/dev/mii directory. HEAD using svnweb.freebsd.org. The patch installed cleanly and there were no errors during the build, but still no NIC. Does it mean you're not seeing bge0 interface? Or you can't pass any traffic via bge0? Oops, it seems I've not included your device ID in the diff. Try attach one instead. Make sure you use brgphy.c from HEAD. There's progress! With your latest patch using brgphy.c, if_bge.c, and if_bgereg.h from head I'm now seeing the bge0 interface. Unfortunately, the moment I try to configure it the box locks up completely; it won't even toggle the caps lock LED. Booting single user and running ifconfig shows: bge0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8009bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE ether a8:20:66:11:3b:d6 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active I did a verbose boot; here's the part that seems to be relevant to bge0: bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x57766001 mem 0xa040-0xa040,0xa041-0xa041 irq 16 at device 0.0 on pci1 bge0: CHIP ID 0x10110142; ASIC REV 0x10110; CHIP REV 0x101101; PCI-E miibus0: MII bus on bge0 brgphy0: BCM57765 1000BASE-T media interface PHY 1 on miibus0 brgphy0: OUI 0x001be9, model 0x0024, rev. 1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: bpf attached bge0: Ethernet address: a8:20:66:11:3b:d6 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 61 I greatly appreciate your efforts. I'm sorry for the delay getting back with you, but we had a busy Thanksgiving weekend. Thank you! -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: bge on the new Mac Mini
On 11/20/12 03:52, YongHyeon PYUN wrote: On Fri, Nov 16, 2012 at 10:30:04AM -0500, Richard Kuhns wrote: Hi all, Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac Minis via the memstick image; they seem to be pretty good little boxes for things like offsite secondary nameservers, for example, and they're easily replaced in case of problems. However, the newest minis have slightly different hardware, and FreeBSD can't find the built-in NIC. pciconf -lv on the new mini shows it as none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 rev=0x01 It seems this controller is BCM57766. hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet The previous edition mini (that works) reports bge0@pci0:2:0:0: class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' class = network subclass = ethernet Is there a chance that adding the new card/chip info to the current driver would allow it to work? I'll be happy to test and report back. I'm afraid I'm not familiar enough with hardware at that level to figure out the patch myself. Try attached patch and let me know whether the patch works or not. If the patch works please share dmesg output(bge(4) and brgphy(4) output only). Note, the patch was generated against CURRENT. I'm afraid it didn't help. I ended up grabbing if_bge.c and if_bgereg.h from HEAD using svnweb.freebsd.org. The patch installed cleanly and there were no errors during the build, but still no NIC. Just to make sure you know, I've made no local modifications at all. This was a fresh install and I've touched nothing except for these 2 files. Thanks! -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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
bge on the new Mac Mini
Hi all, Over the last month or so I've installed FreeBSD 9 (-stable) on several Mac Minis via the memstick image; they seem to be pretty good little boxes for things like offsite secondary nameservers, for example, and they're easily replaced in case of problems. However, the newest minis have slightly different hardware, and FreeBSD can't find the built-in NIC. pciconf -lv on the new mini shows it as none3@pci0:1:0:0: class=0x02 card=0x168614e4 chip=0x168614e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' class = network subclass = ethernet The previous edition mini (that works) reports bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe' class = network subclass = ethernet Is there a chance that adding the new card/chip info to the current driver would allow it to work? I'll be happy to test and report back. I'm afraid I'm not familiar enough with hardware at that level to figure out the patch myself. Thanks! -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: bge on the new Mac Mini
On 11/16/12 10:41, Alfred Perlstein wrote: Often that is all that is needed. It's worth a shot and reporting back. Do you know how to update the table in the driver, rebuild/install kernel and check? -Alfred I'm afraid not. I grepped for the hex value reported on the one that works (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. So I don't know what to add :-( I don't have any problem with rebuilding and installing a new kernel, though. -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: bge on the new Mac Mini
On 11/16/12 11:20, Gary Palmer wrote: On Fri, Nov 16, 2012 at 10:54:00AM -0500, Richard Kuhns wrote: On 11/16/12 10:41, Alfred Perlstein wrote: Often that is all that is needed. It's worth a shot and reporting back. Do you know how to update the table in the driver, rebuild/install kernel and check? -Alfred I'm afraid not. I grepped for the hex value reported on the one that works (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. So I don't know what to add :-( I don't have any problem with rebuilding and installing a new kernel, though. 14e4 is the ID for Broadcom 16b4 is the ID for BCM57765, a NetXtreme Desktop/Mobile chip http://www.broadcom.com/support/ethernet_nic/determine_driver.php has a list of the BCM PCI ID values There is a (frequently incomplete) database of user reported PCI values at http://www.pcidatabase.com. It has the BCM ID (14e4), but not your chip Linux uses the tg3 driver for that chipset apparently, but I think thats a general dumping ground for a lot of Broadcom products. Not sure what the appropriate FreeBSD driver to add the ID code to would be. Regards, Gary Sorry, I should have been more clear. I grepped for those values in /usr/src/sys/dev/bge/*, since that's the driver that's used on the older minis. I assume that's where the table is that Alfred mentioned; I just don't know what to add to it. -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: bge on the new Mac Mini
On 11/16/12 12:09, Gary Palmer wrote: On Fri, Nov 16, 2012 at 11:27:17AM -0500, Richard Kuhns wrote: On 11/16/12 11:20, Gary Palmer wrote: On Fri, Nov 16, 2012 at 10:54:00AM -0500, Richard Kuhns wrote: On 11/16/12 10:41, Alfred Perlstein wrote: Often that is all that is needed. It's worth a shot and reporting back. Do you know how to update the table in the driver, rebuild/install kernel and check? -Alfred I'm afraid not. I grepped for the hex value reported on the one that works (chip=0x16b414e4), but I couldn't find it in its entirety, 16b4, or 14e4. So I don't know what to add :-( I don't have any problem with rebuilding and installing a new kernel, though. 14e4 is the ID for Broadcom 16b4 is the ID for BCM57765, a NetXtreme Desktop/Mobile chip http://www.broadcom.com/support/ethernet_nic/determine_driver.php has a list of the BCM PCI ID values There is a (frequently incomplete) database of user reported PCI values at http://www.pcidatabase.com. It has the BCM ID (14e4), but not your chip Linux uses the tg3 driver for that chipset apparently, but I think thats a general dumping ground for a lot of Broadcom products. Not sure what the appropriate FreeBSD driver to add the ID code to would be. Regards, Gary Sorry, I should have been more clear. I grepped for those values in /usr/src/sys/dev/bge/*, since that's the driver that's used on the older minis. I assume that's where the table is that Alfred mentioned; I just don't know what to add to it. The probe table appears to be bge_devs in if_bge.c. The values there are #define'd in if_bgereg.h, but for a quick hack you just need to add the value to the table Gary Thanks, I found it. I also found that the reason I couldn't find it before was that I didn't tell grep to ignore case :-( -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang
pgctl=1:1 client: fmt=bin size=1575 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e05 text=200 data=1c05 org=0 entry=0 -5 bytes available *** [boot2] Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** [all] Error code 1 Stop in /usr/src/sys/boot/i386. *** [all] Error code 1 Stop in /usr/src/sys/boot. *** [all] Error code 1 Stop in /usr/src/sys. *** [sys.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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
FreeBSD 9.1-BETA1 amd64 fails to mount ZFS rootfs with error 2 when system has more than 3584MB of RAM
Dear Everyone, I am running FreeBSD 9.1-BETA1 amd64 on ZFS in KVM on Gentoo Linux on ZFS. The root pool uses ashift=13 and is on a single disk. The kernel fails to mount the root filesystem if the system has more than 3584MB of RAM. I did a manual binary search to try to find the exact upper limit, but stopped when I tried 3648MB. FreeBSD 9.0-RELEASE works perfectly. Yours truly, Richard Yao signature.asc Description: OpenPGP digital signature
FreeBSD 9.1 Beta 1 fails to install in qemu-kvm on Gentoo Linux
Dear FreeBSD Developers, Trying to install FreeBSD 9.1 Beta 1 in qemu-kvm on Gentoo Linux fails before the kernel dmesg with 'kernel trap 9 with interrupts disabled'. I am running the following command: qemu-system-x86_64 -drive file=/dev/zvol/rpool/KVM/freebsd,if=scsi-bootorder=c -cdrom/mnt/backup/isos/FreeBSD-9.1-BETA1-amd64-disc1.iso -m2048 -smp 6,cores=6,threads=1,sockets=1 -curses -net nic,model=e1000,macaddr=52:54:00:00:ee:04 -cpu host If I use FreeBSD-9.0-RELEASE-amd64-dvd1.iso, I can do an install without any problems. Yours truly, Richard Yao signature.asc Description: OpenPGP digital signature
Re: FreeBSD 9.1 Beta 1 fails to install in qemu-kvm on Gentoo Linux
On 07/20/2012 06:23 PM, Richard Yao wrote: Dear FreeBSD Developers, Trying to install FreeBSD 9.1 Beta 1 in qemu-kvm on Gentoo Linux fails before the kernel dmesg with 'kernel trap 9 with interrupts disabled'. I am running the following command: qemu-system-x86_64 -drive file=/dev/zvol/rpool/KVM/freebsd,if=scsi-bootorder=c -cdrom/mnt/backup/isos/FreeBSD-9.1-BETA1-amd64-disc1.iso -m2048 -smp 6,cores=6,threads=1,sockets=1 -curses -net nic,model=e1000,macaddr=52:54:00:00:ee:04 -cpu host If I use FreeBSD-9.0-RELEASE-amd64-dvd1.iso, I can do an install without any problems. Yours truly, Richard Yao I have an update. 1. There is no backtrace. The only thing that I see printed after the boot screen with beastie is a single line: 'kernel trap 9 with interrupts disabled' 2. Verbose mode does not change it. 3. Removing `-cpu host` fixes it. Here is an excerpt of the host's /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 10 model name : AMD Phenom(tm) II X6 1090T Processor stepping: 0 microcode : 0x1dc cpu MHz : 1600.000 cache size : 512 KB physical id : 0 siblings: 6 core id : 0 cpu cores : 6 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_l m cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb npt lbrv svm_lock nrip_save pausefilter bogomips: 6421.39 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate [9] FreeBSD 9.0 had no problems in KVM with `-cpu host` on this system, so this would seem to be a regression. signature.asc Description: OpenPGP digital signature
Re: FreeBSD 9.1 Beta 1 fails to install in qemu-kvm on Gentoo Linux
On 07/20/2012 08:56 PM, Konstantin Belousov wrote: On Fri, Jul 20, 2012 at 08:40:30PM -0400, Richard Yao wrote: On 07/20/2012 06:23 PM, Richard Yao wrote: Dear FreeBSD Developers, Trying to install FreeBSD 9.1 Beta 1 in qemu-kvm on Gentoo Linux fails before the kernel dmesg with 'kernel trap 9 with interrupts disabled'. I am running the following command: qemu-system-x86_64 -drive file=/dev/zvol/rpool/KVM/freebsd,if=scsi-bootorder=c -cdrom/mnt/backup/isos/FreeBSD-9.1-BETA1-amd64-disc1.iso -m2048 -smp 6,cores=6,threads=1,sockets=1 -curses -net nic,model=e1000,macaddr=52:54:00:00:ee:04 -cpu host If I use FreeBSD-9.0-RELEASE-amd64-dvd1.iso, I can do an install without any problems. Yours truly, Richard Yao I have an update. 1. There is no backtrace. The only thing that I see printed after the boot screen with beastie is a single line: 'kernel trap 9 with interrupts disabled' This line is probably printed after the banner and might be CPU features line. Is this true ? If so, show it. I do not know what the banner is. However, that line is printed immediately after the boot2 menu with Beastie. It occurs when I would expect to see Copyright (c) 1992-2012 The FreeBSD Project.. I see no other visible characters aside from those from the boot2 menu with Beastie. 2. Verbose mode does not change it. 3. Removing `-cpu host` fixes it. Here is an excerpt of the host's /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 10 model name : AMD Phenom(tm) II X6 1090T Processor stepping: 0 microcode : 0x1dc cpu MHz : 1600.000 cache size : 512 KB physical id : 0 siblings: 6 core id : 0 cpu cores : 6 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor cx16 popcnt lahf_l m cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb npt lbrv svm_lock nrip_save pausefilter bogomips: 6421.39 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate [9] FreeBSD 9.0 had no problems in KVM with `-cpu host` on this system, so this would seem to be a regression. Can you boot FreeBSD kernel on this machine bare ? This machine is headless. It would be difficult for me to boot FreeBSD on it. Also it could be useful to show the CPU features lines from FreeBSD 9.0, or just full verbose dmesgs of the boots in KVM with and without -cpu host. Here is the dmesg output from FreeBSD 9.0-RELEASE with -cpu host: Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: AMD Phenom(tm) II X6 1090T Processor (3210.86-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100fa0 Family = 10 Model = a Stepping = 0 Features=0x1783fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT Features2=0x80802001SSE3,CX16,POPCNT,HV AMD Features=0xe6500800SYSCALL,NX,MMX+,FFXSR,Page1GB,LM,3DNow!+,3DNow! AMD Features2=0x1f7LAHF,CMP,SVM,CR8,ABM,SSE4A,MAS,Prefetch real memory = 2147483648 (2048 MB) avail memory = 2045132800 (1950 MB) Event timer LAPIC quality 400 ACPI APIC Table: BOCHS BXPCAPIC FreeBSD/SMP: Multiprocessor System Detected: 6 CPUs FreeBSD/SMP: 1 package(s) x 6 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 ioapic0: Changing APIC ID to 6 ioapic0 Version 1.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: BOCHS BXPCRSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0xb008-0xb00b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 cpu4: ACPI CPU on acpi0 cpu5: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci_link4: Unable to route IRQs: AE_NOT_FOUND isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 WDMA2 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc140-0xc14f at device 1.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 pci0: bridge at device
Re: Text relocations in kernel modules
On 04/02/12 05:56, Tom Evans wrote: On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao r...@cs.stonybrook.edu wrote: There are no security implications, no system resources to be wasted. And if you think there are security implications, then lets see a proof-of-concept. If I find time to write a proof-of-concept, I promise to publish it publicly. Your security team will find out when everyone else does. Richard, I'm not sure what you are trying to accomplish here. You have had a clear explanation of why certain things are done in a certain way in the FreeBSD codebase, and a confirmation that they do not think it causes any security issues in FreeBSD. Your response is to threaten to write an exploit against FreeBSD, and distribute it publicly before disclosing to security@. Some people believe that projects that do not take proper countermeasures against security vulnerabilities do not deserve to have special notification of issues. I happen to be one of them. Are you trying to be an ass? Someone disagrees with you on the internet, so you throw all the toys out the pram? I suggest that you look at things from my perspective. I asked a simple question on your mailing list. I then received several private emails from various FreeBSD developers insulting my intelligence for the act of asking a question. Who is the ass here? signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On 04/02/12 13:13, Tom Evans wrote: On Mon, Apr 2, 2012 at 5:49 PM, Richard Yao r...@cs.stonybrook.edu wrote: On 04/02/12 05:56, Tom Evans wrote: On Sat, Mar 31, 2012 at 3:42 AM, Richard Yao r...@cs.stonybrook.edu wrote: There are no security implications, no system resources to be wasted. And if you think there are security implications, then lets see a proof-of-concept. If I find time to write a proof-of-concept, I promise to publish it publicly. Your security team will find out when everyone else does. Richard, I'm not sure what you are trying to accomplish here. You have had a clear explanation of why certain things are done in a certain way in the FreeBSD codebase, and a confirmation that they do not think it causes any security issues in FreeBSD. Your response is to threaten to write an exploit against FreeBSD, and distribute it publicly before disclosing to security@. Some people believe that projects that do not take proper countermeasures against security vulnerabilities do not deserve to have special notification of issues. I happen to be one of them. This is a straw man argument - FreeBSD does take proper countermeasures against security vulnerabilities - and so your conclusion that you can blithely fully disclose vulnerabilities with no moral concerns is a logical fallacy. My opinion is that any OS that lacks ALSR lacks proper countermeasures against vunerabilities that ASLR would kill. Furthermore, I believe that trying to minimize the impact of bugs that would be addressed by ASLR is ultimately harmful to users' security. Logically, full disclosure would only apply to attacks that ASLR would kill. With that said, I should remind you of the FreeBSD project's license, which disclaims the possibility of moral concerns: THIS SOFTWARE IS PROVIDED BY THE FREEBSD PROJECT ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. It is highly unlikely that anyone who opts for full disclosure of vulnerabilities that ASLR would kill would also be the person who wrote the vulnerable code in the first place. However, should he be the same person, it would seem that you have already accepted a license freeing him of responsibility. there are many people who have commit access. Any of them could intentionally commit vulnerabilities that ASLR would kill. If you do not like this situation, I suggest that you consider alternative operating systems, such as AIX, Mac OS X or Solaris. Their licenses might be more permissive in your ability to hold their makers responsible for flaws. signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On 04/02/12 14:46, Peter Wemm wrote: Remember.. ASLR is a userland thing. .ko files, which is what this thread is about, already use random address layout. When you do a kldload virtio.ko, you have no way to predict what address it will be loaded at. And you don't even have access to the addresses. Of course if you want to talk about ASLR and userland .so files then that's an entirely different thing. But this thread is about your tools finding DT_TEXTREL in a .ko kernel file, not userland .so files. The PaX project's patches to the Linux kernel include kernel stack randomization. The Gentoo Hardened project makes use of this in their fork of the Linux kernel. signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On 04/02/12 15:37, Peter Wemm wrote: On Mon, Apr 2, 2012 at 12:23 PM, Richard Yao r...@cs.stonybrook.edu wrote: On 04/02/12 14:46, Peter Wemm wrote: Remember.. ASLR is a userland thing. .ko files, which is what this thread is about, already use random address layout. When you do a kldload virtio.ko, you have no way to predict what address it will be loaded at. And you don't even have access to the addresses. Of course if you want to talk about ASLR and userland .so files then that's an entirely different thing. But this thread is about your tools finding DT_TEXTREL in a .ko kernel file, not userland .so files. The PaX project's patches to the Linux kernel include kernel stack randomization. The Gentoo Hardened project makes use of this in their fork of the Linux kernel. I looked at their code, and their description here: http://pax.grsecurity.net/docs/randkstack.txt Of note: pax_randomize_kstack() gathers entropy from the rdtsc instruction (read time stamp counter) and applies it to bits 2-6 of the kernel stack pointer. This means that 5 bits are randomized providing a maximum shift of 128 bytes - this was deemed safe enough to not cause kernel stack overflows yet give enough randomness to deter guessing/brute forcing attempts. This has nothing to do with the DT_TEXTREL in .ko that this thread is about and has no bearing on ASLR in any way. There are plenty of techniques employed to do ASLR by both the upstream Linux kernel and the PaX patches to it. I only needed to state one to prove that you were wrong about ASLR being exclusive to userland. If the QA checks had been triggered for an out-of-tree Linux kernel module, the Gentoo developers would consider it to be a bug. I have verified this with the Gentoo Hardened developers. Furthermore, they confirmed that text relocations in out-of-tree kernel modules would negatively affect ASLR. My original email to the list asked if this was an issue in FreeBSD. That question had been answered. However, people went ballistic upon the mere presence of my question, so I assured them that if I ever found time to write exploit code, I would do full disclosure to ensure that this issue was fixed. I stumbled across this issue when setting up an environment in which I could port gptzfsloader to Linux, so I have no reason to implement ASLR in the FreeBSD kernel. Also, the abuse I received over this has lead me to conclude that doing anything for upstream would be deterimental to my mental health, so I am not inclined to try. However, there could be unknown exploits in the wild that would be killed by ASLR in the wild. It would be best for someone, who considers securing FreeBSD to be worth suffering from abuse, to implement it. That person is not me. signature.asc Description: OpenPGP digital signature
Text relocations in kernel modules
As a disclaimer, I would like to clarify that Gentoo/FreeBSD uses a FreeBSD userland and that Gentoo/FreeBSD has nothing to do with Debian GNU/kFreeBSD. People seem to think Gentoo/FreeBSD is related to Debian GNU/kFreeBSD, which has made collaboration difficult. With that said, Gentoo Portage is warning about text relocations in kernel modules. This is in a Gentoo/FreeBSD port of emulators/freebsd-kmod that I wrote. For instance, I see: # readelf -d /boot/modules/virtio.ko Dynamic section at offset 0x2f6c contains 13 entries: TagType Name/Value 0x0004 (HASH) 0xd4 0x6ef5 (GNU_HASH) 0x238 0x0005 (STRTAB) 0x4a8 0x0006 (SYMTAB) 0x298 0x000a (STRSZ) 397 (bytes) 0x000b (SYMENT) 16 (bytes) 0x0011 (REL)0x638 0x0012 (RELSZ) 1568 (bytes) 0x0013 (RELENT) 8 (bytes) 0x0016 (TEXTREL)0x0 0x001e (FLAGS) TEXTREL 0x6ffa (RELCOUNT) 108 0x (NULL) 0x0 Checking /boot/kernel, it seems that all modules have text relocations. My Gentoo/FreeBSD install is a 32-bit chroot on a ZFS Guru install of amd64 FreeBSD. amd64 FreeBSD does not appear to have any text relocations. I don't have a reference i386 install, but according to frogs in ##freebsd on freenode, his i386 FreeBSD also has text relocations. Is this a bug? Yours truly, Richard Yao On 03/30/12 12:49, Richard Yao wrote: Dear Ports Maintainers and kuriyama, emulators/freebsd-kmod has a typo in pkg-descr, where it says lodable instead of loadable. In addition, I have done the work necessary to port emulators/freebsd-kmod to Gentoo/FreeBSD. https://bugs.gentoo.org/show_bug.cgi?id=410199 The ebuild contains a few improvements on the original FreeBSD port where we copy only the parts of SYSDIR that we need to build the module. We also do hardlinks instead of copies when Gentoo Portage builds with user privileges. The NEEDSUBDIRS part of the ebuild was written by naota AT gentoo.org as part of Gentoo's review process. I have permission from him to upstream the improvements we made on the port. Feel free to adopt any improvements in the attachments in that bug report. Lastly, I have sent an email to gentoo-dev AT lists.gentoo.org and gentoo-bsd AT lists.gentoo.org requesting that the FreeBSD specific parts of the portage tree be relicensed under terms of the BSD-2 license. With a little luck, it will be possible to upstream improvements made in Gentoo/FreeBSD without any hassle in the future. Yours truly, Richard Yao signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On 03/30/12 15:07, Konstantin Belousov wrote: Is this a bug? No. This is by design. Why do you consider this a bug ? It occurs on i386, but not amd64. It could be that something is wrong with how things are being compiled i386, or it could be that i386 requires things to be compiled this way. I do not know which. signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On 03/30/12 15:46, Konstantin Belousov wrote: On Fri, Mar 30, 2012 at 03:42:22PM -0400, Richard Yao wrote: On 03/30/12 15:07, Konstantin Belousov wrote: Is this a bug? No. This is by design. Why do you consider this a bug ? It occurs on i386, but not amd64. It could be that something is wrong with how things are being compiled i386, or it could be that i386 requires things to be compiled this way. I do not know which. Again, let me repeat my question. Why do you consider the presence of relocations against text section a problem ? The linker emits warnings: i686-gentoo-freebsd9.0-ld: warning: creating a DT_TEXTREL in object. Furthermore, this triggers a QA check in Gentoo/FreeBSD's package manager. * QA Notice: The following files contain runtime text relocations * Text relocations force the dynamic linker to perform extra * work at startup, waste system resources, and may pose a security * risk. On some architectures, the code may not even function * properly, if at all. * For more information, see http://hardened.gentoo.org/pic-fix-guide.xml * Please include the following list of files in your report: * TEXTREL boot/modules/if_vtnet.ko * TEXTREL boot/modules/virtio_blk.ko * TEXTREL boot/modules/virtio.ko * TEXTREL boot/modules/virtio_balloon.ko * TEXTREL boot/modules/virtio_pci.ko I wrote that ebuild as part of something entirely unrelated. If it is a feature, I can disable the QA check, but I should at least know why the text relocations are needed. Gentoo maintainers are expected to patch text relocations and send patches upstream. The only exception is in the case of binary packages, which they cannot patch. Investigating the text relocations in my port of emulators/virtio-kmod revealed that all kernel modules on i386 Gentoo/FreeBSD have text relocations, yet none have them on amd64 FreeBSD, so I do not know whether this is a bug or a feature. signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On 03/30/12 18:46, Konstantin Belousov wrote: Reread what I wrote to you. Also, it pays off learning how ELF works before making conclusion from the absence of the output of readelf -d. Amd64 modules _are not_ shared objects. Whether or not they are shared objects is irrelevant. The fact is that they have text relocations, which interfere with ASLR. Do I need to produce exploit code before you take me seriously? signature.asc Description: OpenPGP digital signature
Re: Text relocations in kernel modules
On 03/30/12 22:15, Peter Wemm wrote: On Fri, Mar 30, 2012 at 3:47 PM, Richard Yao r...@cs.stonybrook.edu wrote: On 03/30/12 18:46, Konstantin Belousov wrote: Reread what I wrote to you. Also, it pays off learning how ELF works before making conclusion from the absence of the output of readelf -d. Amd64 modules _are not_ shared objects. Whether or not they are shared objects is irrelevant. The fact is that they have text relocations, which interfere with ASLR. Do I need to produce exploit code before you take me seriously? I am the person who wrote it and deliberately chose to cause text relocations to be generated on i386. It is by design, not a bug. All of your concerns are perfectly valid if they were for userland. For the record, our amd64 modules ALSO do this, but your tools simply do not detect it. Here is what happens, and here is why it is not a problem: When you compile with -fpic on an architecture that doesn't support PC-relative addressing adequately, the compiler generates code to do indirect memory references via the global offset table. This is so that all the relocations can be collected into a single location in order to not dirty the MAP_PRIVATE data pages. example: if there is an function at 0x12345, and another function in a different .so file that wants to call it at 0x22345, then the call instruction would have to be relocated. The asm instructions would look like: 0xE8FFEF (offset is -0x1) If the same .so file was loaded in another user process at 0x32345, then the relocation would be different. An entire page would be dirtied by the dynamic linker so that the second instance of the .so file had 0xE8FFDF (-0x2). This is a waste of memory and causes a storm of VM faults at startup. Instead, the code is compiled with -fPIC, which causes an extra memory reference via the global offset table. Instead of the relocations being spread over the text segment, the relocations are in a single page. The dynamic linker has to dirty one page only in order to set up a whole host of relocations. The cost is i386 doesn't have native pc-relative mode, so it has to waste an entire register. We dedicate one of the 6 general purpose registers which costs a hefty performance hit. This is why crypto code tends to be compiled without -fpic, for example. For KERNEL modules, all this changes. In userland, there is a dynamic linker. In the kernel, there is none. In userland, the .so files are mapped with mmap(MAP_PRIVATE), the kernel does not use mmap and always uses a private copy. In userland, the .so files are shared, the kernel NEVER shares them. In userland, doing a relocation causes a copy on write fault, this never happens to the kernel because its using private, exclusive malloc() pages. In userland, we make the performance tradeoff from -fpic in order to share memory pages, the kernel never shares pages so -fpic is a waste. In userland, ASLR has security benefits. The kernel already does this.. if you load a module on one machine it'll ALWAYS be at different address space compared to another. In FreeBSD/i386, we use 'ld -shared -o foo.ko *.o', to wrap the non pic .o files into a container that was more convenient at the time to parse. There is no global-offset-table. In FreeBSD/amd64, we use 'ld -r -o foo.ko *.o' to wrap the same non-pic code into a less convenient form that we can feed back into the linker if we wish. There is no global offset table. Both i386 and amd64 use raw relocations, regardless of where the came from. Text, data, anywhere. This has nothing to do with ASLR, because they are kernel objects, not shared libraries. Most people seem to think that I am unaware of these things, but I already knew most of it. Note that this mostly applies to remarks people are sending me privately. With that said, thank you for the detailed explanation. It filled in a few blanks that I had, specifically in how FreeBSD does things. You posted: * QA Notice: The following files contain runtime text relocations * Text relocations force the dynamic linker to perform extra * work at startup, waste system resources, and may pose a security * risk. On some architectures, the code may not even function * properly, if at all. The key here is dynamic linker. There is no dynamic linker to process this stuff. This is simply a tools problem on your end. It's not a bug. My tools are doing what they were supposed to do. However, people on the list seem to think that the idea that they are checking for a problem to be a matter of opinion. There are no security implications, no system resources to be wasted. And if you think there are security implications, then lets see a proof-of-concept. If I find time to write a proof-of-concept, I promise to publish it publicly. Your security team will find out when everyone else does. You can argue otherwise, but for all I know
AMD Erratum 383 crashes FreeBSD 9-Stable
Dear FreeBSD Developers: I used the ZFS Guru LiveCD to install FreeBSD 9 in KVM on a host system with an AMD Thuban processor (K10h). I then proceeded to compile perl and the VM crashed. Linux's dmesg gave me the following hint as to the cause: [ 3568.234654] KVM: Guest triggered AMD Erratum 383 I also tried installing Gentoo Prefix, a userland package manager like NetBSD pkgsrc, and the VM also crashed with the same message when compiling the first component. AMD has documented this issue, with a workaround for hypervisors and a statement saying that they won't fix it: If system software performs uncommon methods to change the page size of an active page table that is valid, the CPU core may, under a highly specific and detailed set of conditions, form duplicate TLB entries for a single linear address. The CPU core will machine check if this page is then accessed prior to it being invalidated from the TLB. http://support.amd.com/us/Embedded_TechDocs/41322.pdf Has anyone done anything to workaround this issue? I have a Gentoo Hardened VM running on this machine which has no problem compiling software, so I am sure that some sort of page table workaround is possible. Yours truly, Richard Yao signature.asc Description: OpenPGP digital signature
Re: AMD Erratum 383 crashes FreeBSD 9-Stable
On 03/17/12 13:08, Richard Yao wrote: Dear FreeBSD Developers: I used the ZFS Guru LiveCD to install FreeBSD 9 in KVM on a host system with an AMD Thuban processor (K10h). I then proceeded to compile perl and the VM crashed. Linux's dmesg gave me the following hint as to the cause: [ 3568.234654] KVM: Guest triggered AMD Erratum 383 I also tried installing Gentoo Prefix, a userland package manager like NetBSD pkgsrc, and the VM also crashed with the same message when compiling the first component. AMD has documented this issue, with a workaround for hypervisors and a statement saying that they won't fix it: If system software performs uncommon methods to change the page size of an active page table that is valid, the CPU core may, under a highly specific and detailed set of conditions, form duplicate TLB entries for a single linear address. The CPU core will machine check if this page is then accessed prior to it being invalidated from the TLB. http://support.amd.com/us/Embedded_TechDocs/41322.pdf Has anyone done anything to workaround this issue? I have a Gentoo Hardened VM running on this machine which has no problem compiling software, so I am sure that some sort of page table workaround is possible. Yours truly, Richard Yao I was tired when I wrote that, so my eyes seem to have skipped some advice from AMD on how to workaround this in the kernel: Affected software must ensure that page sizes are only increased or decreased after the entry is invalidated and flushed out of all TLBs. When flushing multiple entries from the TLB, software may wish to use a single MOV CR3 value to invalidate the TLB instead of repetitive INVLPG instructions Also, I am not on the mailing list, so please CC replies to me. signature.asc Description: OpenPGP digital signature
Re: AMD Erratum 383 crashes FreeBSD 9-Stable
On 03/17/12 15:21, Alan Cox wrote: When the FreeBSD kernel detects that it is running on an affected processor, it automatically enables the recommended workaround. However, because you are running within a virtual machine, the automatic detection may not be working. Alternatively, you may be using a newer processor revision that still suffers from the bug, but the kernel doesn't enable the workaround for. Can you tell us how the FreeBSD guest sees the underlying processor, e.g., the first few lines of dmesg from the guest? Alan I am currently passing -cpu Opteron_G3,+3dnowext,+3dnow,+3dnowprefetch,+cmp_legacy to KVM at libvirtd's suggestion. I assume this is why the workaround is not being triggered. # dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Sun Jan 15 22:48:55 UTC 2012 root@zfsguru:/usr/obj/usr/src/sys/OFED amd64 module_register: module pci/mps already exists! Module pci/mps failed to register: 17 CPU: AMD Opteron 23xx (Gen 3 Class Opteron) (3210.85-MHz K8-class CPU) Origin = AuthenticAMD Id = 0xf61 Family = f Model = 6 Stepping = 1 Features=0x783fbfdFPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2 Features2=0x80802001SSE3,CX16,POPCNT,HV AMD Features=0xe0100800SYSCALL,NX,LM,3DNow!+,3DNow! AMD Features2=0x1e7LAHF,CMP,SVM,ABM,SSE4A,MAS,Prefetch signature.asc Description: OpenPGP digital signature
Re: AMD Erratum 383 crashes FreeBSD 9-Stable
Alan, thanks for the information. This is a definitely libvirtd bug. Passing '-cpu host' fixes the problem. I replaced libvirtd with Gentoo's kvm-tools, which makes it easy to specify this, so problem solved. I would send a report to the libvirt developers, but I have encountered more problems in libvirt than I have time to describe, so that will not happen right away. On 03/17/12 15:39, Richard Yao wrote: On 03/17/12 15:21, Alan Cox wrote: When the FreeBSD kernel detects that it is running on an affected processor, it automatically enables the recommended workaround. However, because you are running within a virtual machine, the automatic detection may not be working. Alternatively, you may be using a newer processor revision that still suffers from the bug, but the kernel doesn't enable the workaround for. Can you tell us how the FreeBSD guest sees the underlying processor, e.g., the first few lines of dmesg from the guest? Alan I am currently passing -cpu Opteron_G3,+3dnowext,+3dnow,+3dnowprefetch,+cmp_legacy to KVM at libvirtd's suggestion. I assume this is why the workaround is not being triggered. # dmesg Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-RELEASE #0: Sun Jan 15 22:48:55 UTC 2012 root@zfsguru:/usr/obj/usr/src/sys/OFED amd64 module_register: module pci/mps already exists! Module pci/mps failed to register: 17 CPU: AMD Opteron 23xx (Gen 3 Class Opteron) (3210.85-MHz K8-class CPU) Origin = AuthenticAMD Id = 0xf61 Family = f Model = 6 Stepping = 1 Features=0x783fbfdFPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2 Features2=0x80802001SSE3,CX16,POPCNT,HV AMD Features=0xe0100800SYSCALL,NX,LM,3DNow!+,3DNow! AMD Features2=0x1e7LAHF,CMP,SVM,ABM,SSE4A,MAS,Prefetch signature.asc Description: OpenPGP digital signature
csup not updating all files
Sorry to followup on my own post, but I figured out what was going on. It
appears to be a problem with csup.
I've been using csup to maintain 2 CVS Repositories, one at home and one at
work.
The last couple of times I've run csup there were lots of 'checksum mismatches',
so csup said it would download the entire file. I was watching it this morning
and saw it going through {/usr/src}/sys, usr.bin, and usr.sbin. It didn't,
however, actually download all of the files. When it said it was finished
(successfully!), the last file downloaded was in sys/netinet. This was on my
home system (amd64).
I tried on a machine a machine at work (i386) with the same results, except that
csup stopped downloading files much earlier. I restarted the csup; it picked up
where it left off (somewhere in sys/dev) complaining about checksum mismatches.
It then downloaded a fair number of files but still stopped before reaching
usr.bin. (Sorry I don't have hard numbers on how many files).
I installed cvsup. It picked up where csup had left off (also complaining about
checksums), but it updated everything and I've been able to buildworld and
buildkernel without any problems.
So my earlier problem was due to /usr/src/gnu being updated while
/usr/src/sys/sys wasn't :-( .
--
Richard Kuhns r...@wintek.com My Desk: 765-269-8541
Wintek Corporation Internet Support: 765-269-8503
427 N 6th Street STE C Consulting: 765-269-8504
Lafayette, IN 47901-2211 Accounting: 765-269-8502
___
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
Problem building gdb with up-to-date sources
Hello, I just tried to run a buildworld for RELENG_8/amd64 after a fresh csup, and I'm getting the following error: /usr/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c: In function 'fbsd_thread_get_name': /usr/src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c:442: error: 'struct ptrace_lwpinfo' has no member named 'pl_tdname' I looked in /usr/src/sys/sys/ptrace.h, and 'pl_tdname' isn't there. Running 'cvs log' on ptrace.h, though, shows: revision 1.34 date: 2010/11/22 14:42:13; author: attilio; state: Exp; lines: +2 -0 SVN rev 215679 on 2010-11-22 14:42:13Z by attilio Add the ability for GDB to printout the thread name along with other thread specific informations. In order to do that, and in order to avoid KBI breakage with existing infrastructure the following semantic is implemented: - For live programs, a new member to the PT_LWPINFO is added (pl_tdname) ... Any suggestions? I didn't see anything in /usr/src/UPDATING. Thanks in advance! -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: NFS deadlock (unkillable nfsd and no mounts work)
On Thu, Nov 04, 2010 at 10:35:15PM -0700, Josh Carroll wrote: Greetings! I'm having a problem with nfsd hanging and not serving mount points, during which time it can not not be killed. This problem started happening sometime after November 2nd, since kernel from 11/2 sources does not exhibit this problem. I had a similar issue on -current a few weeks ago, with processes that would lock up and become unkillable when they tried to access certain parts of the filesystem (running all zfs here). One time it managed to lock up every time you'd do an ls /, but a reboot would always clear it, then a few days later it would pop up again somewhere else. I never lost any data, zfs never found anything wrong, and the drives and hw all checked out. I sync'd up with the latest -current on oct 18th and it stopped happening (or maybe I just stopped noticing it, entirely possible for a very lightly used personal box), plus I was traveling and super busy at the time, so I didn't bother pursuing it further. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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
Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.).
This is on clean FreeBSD 8.1 RC2, amd64, with 4GB memory. The closest I found by Googling was this: http://forums.freebsd.org/showthread.php?t=9935 And it talks about all kinds of little tweaks, but in the end, the only thing that actually works is the stupid 1-line perl code that forces the kernal to free the memory allocated to (non-zfs) disk cache, which is the Inactive memory in top. I have a 4-disk raidz pool, but that's unlikely to matter. Try to copy large files from non-zfs disk to zfs disk. FreeBSD will cache the data read from non-zfs disk in memory, and free memory will go down. This is as expected, obviously. Once there's very little free memory, one would expect whatever is more important to kick out the cached data (Inact) and make memory available. But when almost all of the memory is taken by disk cache (of non-zfs file system), ZFS disks start threshing like mad and the write throughput goes down in 1-digit MB/second. I believe it should be extremely easy to duplicate. Just plug in a big USB drive formatted in UFS (msdosfs will likely do the same), and copy large files from that USB drive to zfs pool. Right after clean boot, gstat will show something like 20+MB/s movement from USB device (da*), and occasional bursts of activity on zpool devices at very high rate. Once free memory is exhausted, zpool devices will change to constant low-speed activity, with disks threshing about constantly. I tried enabling/disabling prefetch, messing with vnode counts, zfs.vdev.min/max_pending, etc. The only thing that works is that stupid perl 1-liner (perl -e '$x=xx15'), which returns the activity to that seen right after a clean boot. It doesn't last very long, though, as the disk cache again consumes all the memory. Copying files between zfs devices doesn't seem to affect anything. I understand zfs subsystem has its own memory/cache management. Can a zfs expert please comment on this? And is there a way to force the kernel to not cache non-zfs disk data? --rich ___ 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: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.).
On Sun, Jul 11, 2010 at 01:47:57PM -0700, Jeremy Chadwick wrote: On Sun, Jul 11, 2010 at 11:25:12AM -0700, Richard Lee wrote: This is on clean FreeBSD 8.1 RC2, amd64, with 4GB memory. The closest I found by Googling was this: http://forums.freebsd.org/showthread.php?t=9935 And it talks about all kinds of little tweaks, but in the end, the only thing that actually works is the stupid 1-line perl code that forces the kernal to free the memory allocated to (non-zfs) disk cache, which is the Inactive memory in top. I have a 4-disk raidz pool, but that's unlikely to matter. Try to copy large files from non-zfs disk to zfs disk. FreeBSD will cache the data read from non-zfs disk in memory, and free memory will go down. This is as expected, obviously. Once there's very little free memory, one would expect whatever is more important to kick out the cached data (Inact) and make memory available. But when almost all of the memory is taken by disk cache (of non-zfs file system), ZFS disks start threshing like mad and the write throughput goes down in 1-digit MB/second. I believe it should be extremely easy to duplicate. Just plug in a big USB drive formatted in UFS (msdosfs will likely do the same), and copy large files from that USB drive to zfs pool. Right after clean boot, gstat will show something like 20+MB/s movement from USB device (da*), and occasional bursts of activity on zpool devices at very high rate. Once free memory is exhausted, zpool devices will change to constant low-speed activity, with disks threshing about constantly. I tried enabling/disabling prefetch, messing with vnode counts, zfs.vdev.min/max_pending, etc. The only thing that works is that stupid perl 1-liner (perl -e '$x=xx15'), which returns the activity to that seen right after a clean boot. It doesn't last very long, though, as the disk cache again consumes all the memory. Copying files between zfs devices doesn't seem to affect anything. I understand zfs subsystem has its own memory/cache management. Can a zfs expert please comment on this? And is there a way to force the kernel to not cache non-zfs disk data? I believe you may be describing two separate issues: 1) ZFS using a lot of memory but not freeing it as you expect 2) Lack of disk I/O scheduler For (1), try this in /boot/loader.conf and reboot: # Disable UMA (uma(9)) for ZFS; amd64 was moved to exclusively use UMA # on 2010/05/24. # http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html vfs.zfs.zio.use_uma=0 For (2), may try gsched_rr: http://svnweb.freebsd.org/viewvc/base/releng/8.1/sys/geom/sched/README?view=markup -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | vfs.zfs.zio.use_uma is already 0. It looks to be the default, as I never touched it. And in my case, Wired memory is stable at around 1GB. It's the Inact memory that takes off, but only if reading from non-zfs file system. Without other file systems, I can keep moving files around and see no adverse slowdown. I can also scp huge files from another system into the zfs machine, and it doesn't affect memory usage (as reported by top), nor does it affect performance. As for gsched_rr, I don't believe this is related. There is only ONE access to the zfs devices (4 sata drives), which is purely a sequential write. The external USB HDD (UFS2) is a completely different device, and is doing purely sequential read. There is only one cp process doing anything at all. The FreeBSD system files aren't on either of these devices, either not that it's doing anything with the disk during this time. --rich ___ 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: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.).
On Sun, Jul 11, 2010 at 02:45:46PM -0700, Jeremy Chadwick wrote: On Sun, Jul 11, 2010 at 02:12:13PM -0700, Richard Lee wrote: On Sun, Jul 11, 2010 at 01:47:57PM -0700, Jeremy Chadwick wrote: On Sun, Jul 11, 2010 at 11:25:12AM -0700, Richard Lee wrote: This is on clean FreeBSD 8.1 RC2, amd64, with 4GB memory. The closest I found by Googling was this: http://forums.freebsd.org/showthread.php?t=9935 And it talks about all kinds of little tweaks, but in the end, the only thing that actually works is the stupid 1-line perl code that forces the kernal to free the memory allocated to (non-zfs) disk cache, which is the Inactive memory in top. I have a 4-disk raidz pool, but that's unlikely to matter. Try to copy large files from non-zfs disk to zfs disk. FreeBSD will cache the data read from non-zfs disk in memory, and free memory will go down. This is as expected, obviously. Once there's very little free memory, one would expect whatever is more important to kick out the cached data (Inact) and make memory available. But when almost all of the memory is taken by disk cache (of non-zfs file system), ZFS disks start threshing like mad and the write throughput goes down in 1-digit MB/second. I believe it should be extremely easy to duplicate. Just plug in a big USB drive formatted in UFS (msdosfs will likely do the same), and copy large files from that USB drive to zfs pool. Right after clean boot, gstat will show something like 20+MB/s movement from USB device (da*), and occasional bursts of activity on zpool devices at very high rate. Once free memory is exhausted, zpool devices will change to constant low-speed activity, with disks threshing about constantly. I tried enabling/disabling prefetch, messing with vnode counts, zfs.vdev.min/max_pending, etc. The only thing that works is that stupid perl 1-liner (perl -e '$x=xx15'), which returns the activity to that seen right after a clean boot. It doesn't last very long, though, as the disk cache again consumes all the memory. Copying files between zfs devices doesn't seem to affect anything. I understand zfs subsystem has its own memory/cache management. Can a zfs expert please comment on this? And is there a way to force the kernel to not cache non-zfs disk data? I believe you may be describing two separate issues: 1) ZFS using a lot of memory but not freeing it as you expect 2) Lack of disk I/O scheduler For (1), try this in /boot/loader.conf and reboot: # Disable UMA (uma(9)) for ZFS; amd64 was moved to exclusively use UMA # on 2010/05/24. # http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057162.html vfs.zfs.zio.use_uma=0 For (2), may try gsched_rr: http://svnweb.freebsd.org/viewvc/base/releng/8.1/sys/geom/sched/README?view=markup -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | vfs.zfs.zio.use_uma is already 0. It looks to be the default, as I never touched it. Okay, just checking, because the default did change at one point, as the link in my /boot/loader.conf denotes. Here's further confirmation (same thread), the first confirming on i386, the second confirming on amd64: http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057168.html http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057239.html And in my case, Wired memory is stable at around 1GB. It's the Inact memory that takes off, but only if reading from non-zfs file system. Without other file systems, I can keep moving files around and see no adverse slowdown. I can also scp huge files from another system into the zfs machine, and it doesn't affect memory usage (as reported by top), nor does it affect performance. Let me get this straight: The system has ZFS enabled (kernel module loaded), with a 4-disk raidz1 pool defined and used in the past (Wired being @ 1GB, due to ARC). The same system also has UFS2 filesystems. The ZFS pool vdevs consist of their own dedicated disks, and the UFS2 filesystems also have their own disk (which appears to be USB-based). Yes, correct. I have: ad4 (An old 200GB SATA UFS2 main system drive) ad8, ad10, ad12, ad14 (1TB SATA drives) part of raidz1 and nothing else da0 is an external USB disk (1TB), but I don't think it's related to USB. Status looks like this: state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM uchuu ONLINE 0 0 0 raidz1ONLINE 0 0 0 ad8 ONLINE
Re: Freebsd 8.0 kmem map too small
On Wed, May 05, 2010 at 03:33:02PM +0200, Pawel Jakub Dawidek wrote: On Wed, May 05, 2010 at 10:46:31AM +0200, Giulio Ferro wrote: On 05.05.2010 09:52, Jeremy Chadwick wrote: Nope, it's happened again... Now I've tried to rise vm.kmem_size to 6G... [ ... ] Could you try to track down the commit that is causing your problems? Could you try 8-STABLE kernel from before r206815? A quick note to say same here, but on i386. FreeBSD 8.0-STABLE as of 8/5/2010 paniced last night with same symptoms, approx 48 hours uptime. Previous kernel was FreeBSD 8.0-STABLE from Sun Mar 7 14:31:45 EST 2010, perfectly stable for intervening 2 months, about 2 months uptime. Please let me know if full details would help (as opposed to just adding noise :-) -- Richard Perini Internet: r...@ci.com.au Corinthian Engineering Pty Ltd PHONE: +61 2 9552 5500 Sydney, AustraliaFAX: +61 2 9552 5549 ___ 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: Freebsd 8.0 kmem map too small
On Mon, May 10, 2010 at 04:43:26PM -0700, Artem Belevich wrote: You can try disabling ZIO_USE_UMA in sys/modules/zfs/Makefile Comment out following line in that file: CFLAGS+=-DZIO_USE_UMA This should revert memory allocation method back to its previous mode. Let us know whether it helps or not. Thanks Artem, I'll try the suggestion and report back. I'll give it 72 hours. The workload of the machine is fairly consistent day to day. Cheers, -- Richard Perini Internet: r...@ci.com.au Corinthian Engineering Pty Ltd PHONE: +61 2 9552 5500 Sydney, AustraliaFAX: +61 2 9552 5549 ___ 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: FreeBSD8.0 sound on Dell Optiplex 960
On 02/25/10 12:38, Tom Evans wrote: On Thu, Feb 25, 2010 at 5:19 PM, Richard Kuhnsr...@wintek.com wrote: Hello, I'm hoping someone can give me some help getting audio working on this beast. I'm by no means an audiophile; I just like to listen to the occasional CD and/or online station while I work. None of the jacks on the back of the tower seem to do anything. In addition, when starting a Virtual Machine under VirtualBox, I get a popup saying: Some audio devices (PCM_in, PCM_mic) could not be opened. Under Details, the Error ID is HostAudioNotResponding. $ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386) Installed devices: pcm0:HDA ATI R6xx HDMI PCM #0 HDMI (play) default pcm1:HDA Analog Devices AD1984A PCM #0 Analog (play/rec) pcm2:HDA Analog Devices AD1984A PCM #1 Analog (play/rec) Per the snd_hda manpage, I'm also attaching the hda-related output from a verbose boot. Any help would be greatly appreciated! Thanks, - Richart Your default device is currently the HDMI output on your graphics card. You probably want to play with sysctl snd.default_unit=1 (or 2) to set it to one of the analog outputs. One should be the front audio, the other one should be the back. Once you've got it sorted out, add to /etc/sysctl.conf to persist it. Cheers Tom OK, now I can get sound from both vlc and xmms as long as I plug the speakers into the headphone jack on the front of the tower, which is a major improvement! It doesn't make any difference which (non-zero) value I give to hw.snd.default_unit. VMs no longer complain at startup, but there's still no audio from them; there's also no sound from flash. I'm pretty sure that's what BBC Radio uses, and I've always liked to listen to Radio 4's news at 1 (which is 8 AM for me). Many thanks for your help! -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: FreeBSD8.0 sound on Dell Optiplex 960
On 02/25/10 13:42, Richard Kuhns wrote: On 02/25/10 12:38, Tom Evans wrote: On Thu, Feb 25, 2010 at 5:19 PM, Richard Kuhnsr...@wintek.com wrote: Hello, I'm hoping someone can give me some help getting audio working on this beast. I'm by no means an audiophile; I just like to listen to the occasional CD and/or online station while I work. None of the jacks on the back of the tower seem to do anything. In addition, when starting a Virtual Machine under VirtualBox, I get a popup saying: Some audio devices (PCM_in, PCM_mic) could not be opened. Under Details, the Error ID is HostAudioNotResponding. $ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386) Installed devices: pcm0:HDA ATI R6xx HDMI PCM #0 HDMI (play) default pcm1:HDA Analog Devices AD1984A PCM #0 Analog (play/rec) pcm2:HDA Analog Devices AD1984A PCM #1 Analog (play/rec) Per the snd_hda manpage, I'm also attaching the hda-related output from a verbose boot. Any help would be greatly appreciated! Thanks, - Richart Your default device is currently the HDMI output on your graphics card. You probably want to play with sysctl snd.default_unit=1 (or 2) to set it to one of the analog outputs. One should be the front audio, the other one should be the back. Once you've got it sorted out, add to /etc/sysctl.conf to persist it. Cheers Tom OK, now I can get sound from both vlc and xmms as long as I plug the speakers into the headphone jack on the front of the tower, which is a major improvement! It doesn't make any difference which (non-zero) value I give to hw.snd.default_unit. VMs no longer complain at startup, but there's still no audio from them; there's also no sound from flash. I'm pretty sure that's what BBC Radio uses, and I've always liked to listen to Radio 4's news at 1 (which is 8 AM for me). Many thanks for your help! While I know it's generally bad form to follow up to myself, I've made some more progress and it might be useful to someone else. The problem with flash was apparently that I had to symlink /usr/compat/linux/lib/libssl.so.5 to the currently installed version, libssl.so.0.9.8g. Strange but true... At any rate, I now have sound from everything I did before except for VMs under Virtual Box. Once again, thanks, Tom, for your help. -- Richard Kuhns r...@wintek.com My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 ___ 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: ZFS performance degradation over time
Garrett Moore garrettmo...@gmail.com writes: I'm having problems with ZFS performance. When my system comes up, read/write speeds are excellent (testing with dd if=/dev/zero of=/tank/bigfile and dd if=/tank/bigfile of=/dev/null); I get at least 100MB/s on both reads and writes, and I'm happy with that. The longer the system is up, the worse my performance gets. Currently my system has been up for 4 days, and read/write performance is down to about 10MB/s at best. The system is only accessed by 3 clients: myself, my roommate, and our HTPC. Usually, only one client will be doing anything at a time, so it is not under heavy load or anything. This could be due to the amount of memory available for ZFS caching declining as time goes on (for reasons that are not entirely clear, though I suspect it may be due to increasing fragmentation in the kernel memory). You might try doing sysctl kstat.zfs.misc.arcstats.size repeatedly to monitor the amount of memory the ZFS cache is taking up as your system uptime increases. ___ 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: Areca Disk Adapter Question
On 06/12/2009 02:26, Karl Denninger wrote: BUT BUT BUT - there is no way to clear the devices nodes from FreeBSD! If I attempt a camcontrol rescan all after pulling a set the machine instantly panics with uncompleted I/Os to the disks I did not tamper with - whether I tell the adapter I did it first or not. With the 3ware drivers this is propagated through properly. Not so with the Areca drivers. This is a fairly major problem in that it appears that anything you do that causes a da device served by these boards to disappear causes an instant panic. While this is expected behavior if the device is in active use, it really, really sucks if it's not, as it makes it flatly impossible to, for example, pull a disk carrier that has a big drive on it you just ran a dump to. It may be worth you taking this up with Areca support also. I have a handful of their cards at work and one at home and had some issues with the HTTP interface on amd64 recently. They'd got back to me with a solution within a couple of days. Richard ___ 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: FreeBSD 7.x hang-on-boot on Dell 1950
Zaphod Beeblebrox wrote: I have a dell 1950 here on the floor. Since 1950 seems to refer to a lot of things with a lot of configurations, I'm going to attempt to narrow that down a bit. It's got 2x 2.33Ghz dual core pentiums (stepping 06-0F-6 according to the bios) in it and it has an SAS RAID card that FreeBSD recognises. I've upgraded the BIOS to 2.6.1. It has two SAS 70G drives in a RAID 1 configuration and it has a DVD (although it will only boot from CDs). If it helps, it's between 2 and 3 years old, I think. If I allow the machine to boot normally, it stopps after checking the floppy (there is no floppy) with the following message: fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 If I boot the machine without ACPI, it seems to stop at the same place (stopping after having checked the ata controller, which checks right before the floppy) If I boot the machine verbose, I get no more information --- it stopps at the same place. I have tried this (so far) with 7.2-R and 7.1-R. Both do the same thing. Can you try with 7.0 (should be available on ftp-archive)? I have a 1950 from Sept '07 that's now running 7.2-STABLE i386 with the fd devices removed. It started out as 7.0-RELEASE, so maybe its a problem introduced since then? Also, you didn't mention if you were running i386 or amd64. Richard ___ 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: security.bsd.map_at_zero=0 problem with samba33 (including solution)
On Sat, Oct 03, 2009 at 10:27:39PM +, Bjoern A. Zeeb wrote: ... As we will try to keep the default in 8.x and 9.x to disallow user mappings at virtual address 0, we are interested in further issues that were not yet metnioned in either this thread or the Errata Notice. quagga 0.99.15 (built from ports) has the same issue as samba. -- Richard Perini Internet: r...@ci.com.au Corinthian Engineering Pty Ltd PHONE: +61 2 9552 5500 Sydney, AustraliaFAX: +61 2 9552 5549 ___ 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: What happened to DVD writing?
From: Zaphod Beeblebrox zbee...@gmail.com Subject: Re: What happened to DVD writing? To: mahle...@yahoo.com Cc: sta...@freebsd.org Date: Sunday, September 20, 2009, 9:12 PM On Sun, Sep 20, 2009 at 4:35 PM, Richard Mahlerwein mahle...@yahoo.comwrote: I have had several exhibit behavior even more odd. The most unusual was this particular CD writer... It read both DVDs and CDs but would write neither (it had worked fine the week before). I took it out of the drive bay and hooked it to another PC to test and it worked fine there. I put it back in the original PC and it failed. I was swapping things around on that PC (assuming bad cable, bad power, etc) and had it sitting loose on the desk and found that it now worked again. Put it back in the drive cage and it again would not write, though reading was fine. Anyway, I finally figured out that even slight pressure in on the sides where it mounts would make it fail to burn CDs. The cage itself exerted a bit of pressure and that was enough to make it fail at any attempt to burn a CD. This is not necessarily odd. The CD burner is one of the highest draw bits in your system... save possibly your CPU and/or graphics card (depending on what they are). I have found that various DVD drives have been very sensitive to power supply voltages and fail to burn properly when they're marginal. Your description here seems to point in that direction. If it works in computer B, try using B's power supply for A --- or maybe B has other lighter draws. Power supplies can also degrade over time --- especially if you have some cheap capacitors in there. I find the DVD drive is often the canary for spotting power supply problems. Sorry, the kids woke up from naps and I sent without realizing I hadn't quite finished. Yes, you are completely correct. There was another story where it was a power supply that was inadequate (should have been, but it was aged and seemed to just run out of steam earlier than it used to). Anyway, the point I intended to make and forgot to was that in this case I'd confirm that the DVD drive itself is OK by popping it into another PC, if one is available. If it fails in a different known-OK PC it is likely to be a hardware problem. If it works OK there, try a different power cable on your existing PC, or try swapping out the power supply if you can. You could also try just disconnecting any other power-hungry yet unneeded items temporarily (like additional CD/DVD readers/writers or that old 6x 9GB drive SCSI2 RAID array :), if you have any. ___ 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: What happened to DVD writing?
From: Warren Block wbl...@wonkity.com Subject: Re: What happened to DVD writing? Date: Sunday, September 20, 2009, 2:58 PM On Sun, 20 Sep 2009, Zaphod Beeblebrox wrote: FreeBSD lightning 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun Sep 20 07:25:58 MDT 2009 r...@lightning:/usr/obj/usr/src/sys/LIGHTNING i386 Now growisofs starts, but appears to never manage to write to the DVD. It's a DVD-R, one from the same batch that has worked before: 0.77% done, estimate finish Sun Sep 20 07:55:57 2009 and there it stops. Rebooting is needed, and the machine can't quite bring itself to shut down after syncing buffers. /var/log/messages: Another possibility is that the drive is worn out. DVD writers have a limited lifespan largely measured by the number of disks they cut. This drive has probably written under 50 DVDs, all ISOs used for backup. It's a Lite-On DH-20A4P bought in August 2008. It's looking like the drive itself has failed. Which seems odd, since I thought it could still burn CDs. I have had several exhibit behavior even more odd. The most unusual was this particular CD writer... It read both DVDs and CDs but would write neither (it had worked fine the week before). I took it out of the drive bay and hooked it to another PC to test and it worked fine there. I put it back in the original PC and it failed. I was swapping things around on that PC (assuming bad cable, bad power, etc) and had it sitting loose on the desk and found that it now worked again. Put it back in the drive cage and it again would not write, though reading was fine. Anyway, I finally figured out that even slight pressure in on the sides where it mounts would make it fail to burn CDs. The cage itself exerted a bit of pressure and that was enough to make it fail at any attempt to burn a CD. -Rich ___ 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: Fatal Trap 12 in various processes always at address 0x3030313a
--- On Sun, 8/30/09, Gavin Atkinson ga...@freebsd.org wrote: From: Gavin Atkinson ga...@freebsd.org Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a To: Richard Mahlerwein mahle...@yahoo.com Cc: FreeBSD-Stable freebsd-stable@FreeBSD.org Date: Sunday, August 30, 2009, 3:47 PM On Sat, 29 Aug 2009, Richard Mahlerwein wrote: (Sorry, update to subject to be something) 3 weeks ago: I upgraded from 7.1-PRELEASE to -stable and all seemed fine until I rebooted out of single user mode after doing make installworld and mergemaster. At that point, near the end of the boot sequence I got a core dump, apparently triggered by devd. Fatal trap 12: page fault while in kernel mode. cpu id = 0; apic id = 00 fault virtual address = 0x3030313a fault code = supervisor write, page not present [snip] current process = 355 (devd) [snip] Does anyone have a further recommendation on what to do, try, test or change? Firstly, please set up a dump partition by adding 'dumpdev=AUTO' to your rc.conf. Then, can you compile in the kernel debugger (options KGB / options DDB) and when this happens again, please obtain a backtrace from the debugger with the bt command. Then, give the show registers command so that we can establish which register is pointing to the odd address. Finally, issue the call doadump() command to hopefully save a copy of the kernel dump for later analysis. Thanks, Gavin No problem, but for future reference by others reading this thread, the handbook says KGB should be KDB, which is what I'm enabling in the kernel config. DDB is fine. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html ___ 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: Fatal Trap 12 in various processes always at address 0x3030313a
From: Gavin Atkinson ga...@freebsd.org Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a To: Richard Mahlerwein mahle...@yahoo.com Cc: FreeBSD-Stable freebsd-stable@FreeBSD.org Date: Sunday, August 30, 2009, 3:47 PM On Sat, 29 Aug 2009, Richard Mahlerwein wrote: I upgraded from 7.1-PRELEASE to -stable and all seemed fine until I rebooted out of single user mode after doing make installworld and mergemaster. At that point, near the end of the boot sequence I got a core dump, apparently triggered by devd. Fatal trap 12: page fault while in kernel mode. cpu id = 0; apic id = 00 fault virtual address = 0x3030313a fault code = supervisor write, page not present [snip] current process = 355 (devd) Does anyone have a further recommendation on what to do, try, test or change? Firstly, please set up a dump partition by adding 'dumpdev=AUTO' to your rc.conf. Then, can you compile in the kernel debugger (options KGB / options DDB) and when this happens again, please obtain a backtrace from the debugger with the bt command. Then, give the show registers command so that we can establish which register is pointing to the odd address. Finally, issue the call command to hopefully save a copy of the kernel dump for later analysis. Thanks, Gavin Error at virtual address 0x3030313a current process 352(sysctl) bt says (typing blind, but I think I got it): Tracing pid 352 tid 100044 td 0xc3378480 sysctl_devctl_disable(c0c80ac0,0,0,d82fcba4,d82fcba4...) at sysctl_devctl_disable+0xaa sysctl_root(d82fcba4,4,1,d82fcc60,0,...) at sysctl_root+0x187 userland_sysctl(c3378480,d82fcc14,3,0,0,...) at userland_sysctl+0x1c4 __sysctl(c3378480,d82fccfc,18,d82fcd38,d82fcd2c,...) at __sysctl_0x94 syscall(d82fcd38) at syscall_0x335 Xint0x80_syscall() at Xint0x80_syscall_0x20 --- syscall (202,FreeBSD ELF32, __sysctl, eip = 0x2815beaf, esp=0xbfbfe55c, epb = 0xbfbfe588 --- show registers : cs 0x20 ds 0xc1470028 es 0xc1470028 fs 0xc1460008 ss 0x28 eax 0xc0cea0cc devsoftc_0x4c ecx 0 edx 0x30303132 ebx 0xc3181350 esp 0xd82fcb34 ebp 0xd82fcb54 esi 0 edi 0 eip 0xc08218da sysctl_devctl_disable+0xaa efl 0x10202 sysctl_devctl_disable+0xaa: movl %eax,0x8(%edx) I hope that tells someone on the list way more than it tells me. Thanks again for all the help so far! -Rich ___ 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: Fatal Trap 12 in various processes always at address 0x3030313a
From: Richard Mahlerwein mahle...@yahoo.com Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a To: FreeBSD-Stable freebsd-stable@freebsd.org Date: Tuesday, September 1, 2009, 2:58 PM From: Gavin Atkinson ga...@freebsd.org Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a To: Richard Mahlerwein mahle...@yahoo.com Cc: FreeBSD-Stable freebsd-stable@FreeBSD.org Date: Sunday, August 30, 2009, 3:47 PM On Sat, 29 Aug 2009, Richard Mahlerwein wrote: I upgraded from 7.1-PRELEASE to -stable and all seemed fine until I rebooted out of single user mode after doing make installworld and mergemaster. At that point, near the end of the boot sequence I got a core dump, apparently triggered by devd. Fatal trap 12: page fault while in kernel mode. cpu id = 0; apic id = 00 fault virtual address = 0x3030313a fault code = supervisor write, page not present [snip] current process = 355 (devd) Does anyone have a further recommendation on what to do, try, test or change? Firstly, please set up a dump partition by adding 'dumpdev=AUTO' to your rc.conf. Then, can you compile in the kernel debugger (options KGB / options DDB) and when this happens again, please obtain a backtrace from the debugger with the bt command. Then, give the show registers command so that we can establish which register is pointing to the odd address. Finally, issue the call command to hopefully save a copy of the kernel dump for later analysis. Thanks, Gavin Error at virtual address 0x3030313a current process 352(sysctl) bt says (typing blind, but I think I got it): Tracing pid 352 tid 100044 td 0xc3378480 sysctl_devctl_disable(c0c80ac0,0,0,d82fcba4,d82fcba4...) at sysctl_devctl_disable+0xaa sysctl_root(d82fcba4,4,1,d82fcc60,0,...) at sysctl_root+0x187 userland_sysctl(c3378480,d82fcc14,3,0,0,...) at userland_sysctl+0x1c4 __sysctl(c3378480,d82fccfc,18,d82fcd38,d82fcd2c,...) at __sysctl_0x94 syscall(d82fcd38) at syscall_0x335 Xint0x80_syscall() at Xint0x80_syscall_0x20 --- syscall (202,FreeBSD ELF32, __sysctl, eip = 0x2815beaf, esp=0xbfbfe55c, epb = 0xbfbfe588 --- show registers : cs 0x20 ds 0xc1470028 es 0xc1470028 fs 0xc1460008 ss 0x28 eax 0xc0cea0cc devsoftc_0x4c ecx 0 edx 0x30303132 ebx 0xc3181350 esp 0xd82fcb34 ebp 0xd82fcb54 esi 0 edi 0 eip 0xc08218da sysctl_devctl_disable+0xaa efl 0x10202 sysctl_devctl_disable+0xaa: movl %eax,0x8(%edx) I hope that tells someone on the list way more than it tells me. Thanks again for all the help so far! -Rich I hope changing back to non-text (to get around some messed-up-ed-ness I've been having in my Yahoo account) won't mess this up too bad. Please don't yell at me if it does - just a polite mention will do. :) I changed devd_enable=NO to devd_enable=YES in rc.conf, and get THIS error (which is back to being almost the same as the original one I got on the first attempt at a new kernel) vault virtual address 0x3030313a fault code = supervisor write, page not present instruction pointer = 0x20:0xc08216dc stack pointer = 0x28: 0xd8311b70 frame pointer = 0x28:0xd8300b8c code segment = base 0x0, limit 0xf, type 0x1b =DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process -= 255 (devd) [thread pid 355 tid 100045 ] stopped at devread+0x12c: movl %eax,0x8(%edx) bt says: Tracing pid 355 tid 100045 tc 0xc3378240 devread(c30df400,d8300c60,0,c3434564,d8300bd8,...) at devread+0x12c giant_read(c30df400,d8300c60,0,0,400,...) at giant_read+0x89 devfs_read_f(c33adb48,d8300c60,c3071300,0,c33adb48,...) at dofileread+0x96 kern_readv(c3378240,3,d8300c60,bfbfe9f7,400,...) at kern_readv+0x58 read(c3378240,d8300cfc,c,8000,369e99,...) at read+0x4f syscall(d8300d38) at syscall_0x335 Xint0x80_syscall() at Xint0x80_syscall_0x20 --- syscall (3, FreeBSD ELF32, read), eip - 0x8086c7f, esp = 0xbfbfe9bc, ebp = 0xbfbfee98 --- And show registers: cs=20,ds=d8300028, es=d8300028,fs= d838, ss=28, eax=c0cea0cc devsoftc_0x4c ecx=0x4,, edx=0x30303132, ebx=oxc3181350, esp=pxd8300b70, ebp=oxd8300b8c, esi=0xc30df400, edi=0x6, eip=oxc08216dc devread_0x12c, efl=0x10202 devread+0x12c: movl %eax, 0x8(%edx) I'm still not quite sure what that's telling me, but is it significant that it's the same virtual location with a different piece of code loaded there because of a change in options? No other change was made, just changing devd_enable. I'm going to check loader.conf, too, as someone else suggested (but at this point, I didn't want to muddy the waters by changing two things at once). ___ 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: Fatal Trap 12 in various processes always at address 0x3030313a
From: Richard Mahlerwein mahle...@yahoo.com Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a To: FreeBSD-Stable freebsd-stable@freebsd.org Date: Tuesday, September 1, 2009, 2:58 PM From: Gavin Atkinson ga...@freebsd.org Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a To: Richard Mahlerwein mahle...@yahoo.com Cc: FreeBSD-Stable freebsd-stable@FreeBSD.org Date: Sunday, August 30, 2009, 3:47 PM On Sat, 29 Aug 2009, Richard Mahlerwein wrote: I upgraded from 7.1-PRELEASE to -stable and all seemed fine until I rebooted out of single user mode after doing make installworld and mergemaster. At that point, near the end of the boot sequence I got a core dump, apparently triggered by devd. Fatal trap 12: page fault while in kernel mode. cpu id = 0; apic id = 00 fault virtual address = 0x3030313a fault code = supervisor write, page not present [snip] current process = 355 (devd) Does anyone have a further recommendation on what to do, try, test or change? Firstly, please set up a dump partition by adding 'dumpdev=AUTO' to your rc.conf. Then, can you compile in the kernel debugger (options KGB / options DDB) and when this happens again, please obtain a backtrace from the debugger with the bt command. Then, give the show registers command so that we can establish which register is pointing to the odd address. Finally, issue the call command to hopefully save a copy of the kernel dump for later analysis. Thanks, Gavin TWO Pieces of information here, and please excuse the repost - darn mailer's making me look like such a noob (not like I need help at that!). Again, mention it if this screws up the formatting too badly. Now that I know certain stuff doesn't come across, I have not used it so hopefully this will turn out nicely. Error at virtual address 0x3030313a current process 352(sysctl) bt says (typing blind, but I think I got it): Tracing pid 352 tid 100044 td 0xc3378480 sysctl_devctl_disable(c0c80ac0,0,0,d82fcba4,d82fcba4...) at sysctl_devctl_disable+0xaa sysctl_root(d82fcba4,4,1,d82fcc60,0,...) at sysctl_root+0x187 userland_sysctl(c3378480,d82fcc14,3,0,0,...) at userland_sysctl+0x1c4 __sysctl(c3378480,d82fccfc,18,d82fcd38,d82fcd2c,...) at __sysctl_0x94 syscall(d82fcd38) at syscall_0x335 Xint0x80_syscall() at Xint0x80_syscall_0x20 --- syscall (202,FreeBSD ELF32, __sysctl, eip = 0x2815beaf, esp=0xbfbfe55c, epb = 0xbfbfe588 --- show registers : cs 0x20 ds 0xc1470028 es 0xc1470028 fs 0xc1460008 ss 0x28 eax 0xc0cea0cc devsoftc_0x4c ecx 0 edx 0x30303132 ebx 0xc3181350 esp 0xd82fcb34 ebp 0xd82fcb54 esi 0 edi 0 eip 0xc08218da sysctl_devctl_disable+0xaa efl 0x10202 sysctl_devctl_disable+0xaa: movl %eax,0x8(%edx) I hope that tells someone on the list way more than it tells me. On a hunch, I changed devd_enable=NO to devd_enable=YES in rc.conf, and get THIS error (which is back to being almost the same as the original one I got on the first attempt at a new kernel) vault virtual address 0x3030313a fault code = supervisor write, page not present instruction pointer = 0x20:0xc08216dc stack pointer = 0x28: 0xd8311b70 frame pointer = 0x28:0xd8300b8c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process -= 255 (devd) [thread pid 355 tid 100045 ] stopped at devread+0x12c: movl %eax,0x8(%edx) bt says: Tracing pid 355 tid 100045 tc 0xc3378240 devread(c30df400,d8300c60,0,c3434564,d8300bd8,...) at devread+0x12c giant_read(c30df400,d8300c60,0,0,400,...) at giant_read+0x89 devfs_read_f(c33adb48,d8300c60,c3071300,0,c33adb48,...) at dofileread+0x96 kern_readv(c3378240,3,d8300c60,bfbfe9f7,400,...) at kern_readv+0x58 read(c3378240,d8300cfc,c,8000,369e99,...) at read+0x4f syscall(d8300d38) at syscall_0x335 Xint0x80_syscall() at Xint0x80_syscall_0x20 --- syscall (3, FreeBSD ELF32, read), eip - 0x8086c7f, esp = 0xbfbfe9bc, ebp = 0xbfbfee98 --- And show registers: cs=20, ds=d8300028, es=d8300028, fs= d838, ss=28, eax=c0cea0cc devsoftc_0x4c ecx=0x4, edx=0x30303132, ebx=oxc3181350, esp=pxd8300b70, ebp=oxd8300b8c, esi=0xc30df400, edi=0x6, eip=oxc08216dc devread_0x12c, efl=0x10202 devread+0x12c: movl %eax, 0x8(%edx) I'm still not quite sure what that's telling me, but is it significant that it's the same virtual location with a different piece of code loaded there because of a change in options? No other change was made, just changing devd_enable. I'm going to check loader.conf, too, as someone else suggested (but at this point, I didn't want to muddy the waters by changing two things at once). Thanks again, Rich ___ 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
Fatal Trap 12 in various processes always at address 0x3030313a
(Sorry, update to subject to be something) 3 weeks ago: I upgraded from 7.1-PRELEASE to -stable and all seemed fine until I rebooted out of single user mode after doing make installworld and mergemaster. At that point, near the end of the boot sequence I got a core dump, apparently triggered by devd. Fatal trap 12: page fault while in kernel mode. cpu id = 0; apic id = 00 fault virtual address = 0x3030313a fault code = supervisor write, page not present [snip] current process = 355 (devd) I redid the *whole* process in single user mode, yet no difference. I was out of town for 2.5 weeks after that, then busy for a few days, which brings me to now: TODAY: I booted to my memtest86+ CD, let it run through which it did with no issues noted. I blew away my /usr/src and resynced as of about noon today. After following through all steps to rebuild, I now get a fatal trap 12... Fatal trap 12: page fault while in kernel mode. cpu id = 0; apic id = 00 fault virtual address = 0x3030313a fault code = supervisor write, page not present [snip] current process = 352 (sysctl) Same virtual address, different process. Umm. Interesting. I'm at a loss. Google's been of little help, and searching these lists hasn't turned up much either. Does anyone have a further recommendation on what to do, try, test or change? BTW, I'm GENERIC. Rich Mahlerwein ___ 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)
3 weeks ago: I upgraded from 7.1-PRELEASE to -stable and all seemed fine until I rebooted out of single user mode after doing make installworld and mergemaster. At that point, near the end of the boot sequence I got a core dump, apparently triggered by devd. Fatal trap 12: page fault while in kernel mode. cpu id = 0; apic id = 00 fault virtual address = 0x3030313a fault code = supervisor write, page not present [snip] current process = 355 (devd) I redid the *whole* process in single user mode, yet no difference. I was out of town for 2.5 weeks after that, then busy for a few days, which brings me to now: TODAY: I booted to my memtest86+ CD, let it run through which it did with no issues noted. I blew away my /usr/src and resynced as of about noon today. After following through all steps to rebuild, I now get a fatal trap 12... Fatal trap 12: page fault while in kernel mode. cpu id = 0; apic id = 00 fault virtual address = 0x3030313a fault code = supervisor write, page not present [snip] current process = 352 (sysctl) Same virtual address, different process. Umm. Interesting. I'm at a loss. Google's been of little help, and searching these lists hasn't turned up much either. Does anyone have a further recommendation on what to do, try, test or change? BTW, I'm GENERIC. Rich Mahlerwein ___ 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: (no subject)
--- On Sat, 8/29/09, Torfinn Ingolfsen torfinn.ingolf...@broadpark.no wrote: Do you have any kmod's from ports on that system? Loaded in loader.conf maybe? If so, try to no load them and see what happens. HTH -- Regards, Torfinn Ingolfsen Addendum: While I found I can do a buildworld while in single user mode without error, I have also notice that, AS I SHUT DOWN from there it gives the same fatal trap 12 error. I hadn't always noticed because if I wait for 15 seconds it reboots anyway. So, in regular mode it fails at boot up. In single-user mode it's usable until I try to shut down. I do not believe I have anything of my doing in loader.conf - it's basically a samba box without much else on it. I'll check it specifically later after the kids are in bed. ___ 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: Fatal Trap 12 in various processes always at address 0x3030313a
--- On Sat, 8/29/09, Marat N.Afanasyev ama...@ksu.ru wrote: From: Marat N.Afanasyev ama...@ksu.ru Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a To: mahle...@yahoo.com Cc: FreeBSD-Stable freebsd-stable@freebsd.org Date: Saturday, August 29, 2009, 6:59 PM Richard Mahlerwein wrote: (Sorry, update to subject to be something) 3 weeks ago: I upgraded from 7.1-PRELEASE to -stable and all seemed fine until I rebooted out of single user mode after doing make installworld and mergemaster. At that point, near the end of the boot sequence I got a core dump, apparently triggered by devd. Fatal trap 12: page fault while in kernel mode. cpu id = 0; apic id = 00 fault virtual address = 0x3030313a fault code = supervisor write, page not present [snip] current process = 355 (devd) I redid the *whole* process in single user mode, yet no difference. I was out of town for 2.5 weeks after that, then busy for a few days, which brings me to now: TODAY: I booted to my memtest86+ CD, let it run through which it did with no issues noted. I blew away my /usr/src and resynced as of about noon today. After following through all steps to rebuild, I now get a fatal trap 12... Fatal trap 12: page fault while in kernel mode. cpu id = 0; apic id = 00 fault virtual address = 0x3030313a fault code = supervisor write, page not present [snip] current process = 352 (sysctl) Same virtual address, different process. Umm. Interesting. I'm at a loss. Google's been of little help, and searching these lists hasn't turned up much either. Does anyone have a further recommendation on what to do, try, test or change? BTW, I'm GENERIC. Rich Mahlerwein ___ 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 such trap could be triggered by 'floating' memory/cache error. and i think that you should try to suspect memory first. memtest helps to diagnose most of memory problems, but not all. -- SY, Marat How can I test that? If a buildworld will complete successfully several times (with mildly different source, even), and memtest86+ won't find it, how can I tell if that's the problem 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
sade(8) on a gmirror device
A little background - the system in question , running 7.2-RELEASE has 2 1TB disks in a gmirror, ez0. ad4 and ad6 are the two providers for the gmirror device. It was created after a 30GB slice had been created on ad4 for the various system partitions required. This system is running fine, with the partitions mounted from /dev/mirror/ez0s1a for example. What I would now like to do is create a second slice from the remaining 900-odd GB left on the mirror. However, sade (and sysinstall) do not display the ez0 device to operate on, only the providers: ad4 and ad6. fdisk(8) will happily read the partition table from the mirror: *** Working on device /dev/mirror/ez0 *** parameters extracted from in-core disklabel are: cylinders=121601 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=121601 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 62914257 (30719 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 15/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED However, dumping the partition table and passing back to fdisk also fails: ezekiel# fdisk -f fd.e *** Working on device /dev/mirror/ez0 *** fdisk: Geom not found: ez0 fdisk: Failed to write sector zero This also occurs if I set kern.geom.debugflags to 16, by the way. Does anyone have any suggestions for how to proceed? The only method I can think of is to break the mirror, add the slice to ad4, then recreate the mirror. Not being able to use sade on a gmirror is a real PITA. Regards, Richard smime.p7s Description: S/MIME Cryptographic Signature
Re: (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step
Mike Tancsa wrote: At 08:19 AM 6/10/2009, Andre Oppermann wrote: Today I upgraded an AMD64 server from FreeBSD 6.4 to 7-STABLE and got a big nasty surprise with the Areca RAID controller: arcmsr0: Areca SATA Host Adapter RAID Controller (RAID6 capable) mem 0xfdbff000-0xfdb40 irq16 at device 14.0 on pci18 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.46 2009-01-06 arcmsr0: [ITHREAD] ... (probe23:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config As a further datapoint, I see no problems with amd64 RELENG_7 from May 20th, though I am running an older firmware version. I also don't appear to receive the probe error the two of you are seeing. arcmsr0: Areca SATA Host Adapter RAID Controller (RAID6 capable) mem 0xf450-0xf4500fff,0xf400-0xf43f irq 18 at device 14.0 on pci7 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 arcmsr0: [ITHREAD] da0 at arcmsr0 bus 0 target 0 lun 0 da0: Areca BigVol01 R001 Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz DT, offset 32, 16bit) da0: Command Queueing Enabled da0: 1831054MB (374616 512 byte sectors: 255H 63S/T 233426C) ___ 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: buildworld fails with WITHOUT_CDDL=yes in src.conf
Kip Macy wrote: The second bug is the use of LOADER_ZFS_SUPPORT without any consideration of WITHOUT_CDDL and/or WITHOUT_ZFS (or MK_ZFS) I'll try get it fixed by Wednesday. Kip, I noticed a fix went in with revision 193494 but was then backed out straight away with no reason. Will this be fixed soon? It is still not possible to build RELENG_7 sources WITHOUT_CDDL. Regards, Richard ___ 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: 7.1 Panic on degraded disk w/mpt
Charles Sprickman said: Howdy, I dug around and can't find a PR on this, and the only other report I saw was in this mailing list post that has no replies: http://www.nabble.com/7.1-BETA2-panic-on-mpt-degrade-td20183173.html The hardware is a Dell PowerEdge 860 with the Dell/LSI SAS5 controller: mpt0: LSILogic SAS/SATA Adapter port 0xec00-0xecff mem 0xfe9fc000-0xfe9f,0xfe9e-0xfe9e irq 16 at device 8.0 on pci2 mpt0: MPI Version=1.5.13.0 The panic is repeatable by forcing the array into a degraded state. I think this is PR 130330. http://www.freebsd.org/cgi/query-pr.cgi?pr=130330cat= I am trying to get another test machine available - the machines I had have gone into production with 7.0 installed. (Apologies if this email doesn't appear correctly, done what I can!) ___ 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: Problem with SATA/SAS 5iR
Kevin Smith wrote: Hi, I have a problem with a Dell Poweredge SC440 computer. It's equipped with a Dell SATA/SAS 5iR controller, it's from LSI actually (maybe megaraid). I'm using FreeBSD 7.1 Release I have 2x 500 GB SATA in a synchronised(status optimal) RAID-1 logical volume. The machine is brand new, first problem arised early after the installer started to install the files, the install was very slow, (I know it is because write cache is not enabled, that can be done with a management program, and I will enable it later) and sysinstall could not install the ports collection, the error it gave was write error on transfer to cpio process, try of 1024 bytes after OK, write error popped up. I found this error too, but I found no clue what could have happened. Installing the system without the ports collection (installed it later with cvsup)in another run gave no error at all, and in dmesg is see the logical volume: mpt0:vol0(mpt0:0:0): Settings ( Hot-Plug-Spares High-Priority-ReSync ) mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 mpt0:vol0(mpt0:0:0): 2 Members: (mpt0:1:32:0): Primary Online (mpt0:1:1:0): Secondary Online mpt0:vol0(mpt0:0:0): RAID-1 - Optimal mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:0:0) (mpt0:vol0:1): Online (mpt0:vol0:0): Physical (mpt0:0:32:0), Pass-thru (mpt0:1:1:0) (mpt0:vol0:0): Online da0 at mpt0 bus 0 target 0 lun 0 da0: Dell VIRTUAL DISK 1028 Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: 476837MB (976562176 512 byte sectors: 255H 63S/T 60788C) It looks OK, but then I found this after typing df -h, and it gives me the creeps: Filesystem SizeUsed Avail Capacity Mounted on /dev/da0s1a496M138M318M30%/ devfs 1.0K1.0K 0B 100%/dev /dev/da0s1e3.9G 14K3.6G 0%/tmp /dev/da0s1f440G537M404G 0%/usr /dev/da0s1d2.9G1.3M2.7G 0%/var I'm reading the freebsd-current list, and I found another buffer related problem there, but they say nothing about these. If you have any explanation/solution for these problems pls share them! What's wrong with the dmesg? The used/available inconsistencies are due to space being reserved. Regarding disk performance, you need to put hw.mpt.enable_sata_wc=1 in /boot/loader.conf to reenable the write cache (it's disabled by default for consistency reasons when using SATA disks leading to poor write performance). Regards, Richard ___ 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: Problem with SATA/SAS 5iR
Kevin Smith wrote: Thanks for your advice, this was unusual for me, because even on a 4iR I couldnt see this space reservation. What about sysinstalls write error when extracting the ports collection? Bad install media perhaps? Have you encountered any other issues? Richard ___ 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: Problem with SATA/SAS 5iR
Kevin Smith wrote: Just another thing, can you change or monitor the behaviour of this spare space reservation? Looking into man mpt gave nothing useful regarding this issue. The tunefs manpage has a little about the space reservation. You can set it with -m IIRC when doing the newfs, but I believe it's generally best to leave it at the default. Note that root can still use the space, just not ordinary users (this leads to negative available space reported by df). Regards, Richard ___ 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: 7.1, mpt and slow writes
Charles Sprickman wrote: Hello, I think this needs a few more eyes: http://lists.freebsd.org/pipermail/freebsd-scsi/2009-January/003782.html In short, writes are slow, likely do to the write-cache being enabled on the controller. The sysctl used in 6.x to turn the cache off don't seem to be in 7.x. I have two Dell 860's here also running 7.1-REL. A simple dd on one shows roughly 60MB/s writes to a mirror of 2 320GB disks on what I'm assuming is the same LSI controller card (SAS5) rich...@moses:~# cat /boot/loader.conf hw.mpt.enable_sata_wc=1 Seems to work just fine for me. Regards, Richard smime.p7s Description: S/MIME Cryptographic Signature
Re: 7.1, mpt and slow writes
Peter C. Lai wrote: I am guessing this is only related to SATA drives on SAS controllers? The only mpt hardware I have is LSILogic 1030 Ultra4 and it writes sustained 40MB/s to my LTO-2 drives out of the box without any tweaking. Correct. When SATA drives are used instead of SAS drives on this controller it disables the write cache resulting in poor performance. The tunable was added by Scott Long to solve the problem (though at the cost of greater risk to data). Richard smime.p7s Description: S/MIME Cryptographic Signature
Re: NIC for VLAN
Edvaldo Silva wrote: Hello, guys! Please, can someone point a NIC, PCI 2.2 specs, full VLAN capable under FreeBSD? I´m finding terrible issues using RTL8169 and 3C9x, almost all for the fact NIC cannot handle MTU a little bigger than 1500 (1500 + vlan tagging). I don´t wish reducing MTU. Intel Pro/100 (fxp driver) or Pro/1000 (em/igb driver) are probably the best supported and best performing on FreeBSD, and the Pro/1000 at least has excellent VLAN support. Regards, Richard Tector smime.p7s Description: S/MIME Cryptographic Signature
Re: 7.1-PRERELEASE: arcmsr write performance problem
David Kelly wrote: On Dec 1, 2008, at 11:45 PM, Jan Mikkelsen wrote: Replying to my own post ... I have done a test on the same machine comparing 6.3-p1 to 7.1-PRE. The performance is the expected ~6MB/s (because of the lack of cache) on 6.3-p1, so the BIOS change doesn't seem to be at fault. This seems to be a regression somewhere between 6.3 to 7.1. The Areca driver is the same in 6.3 and 7.1, so the problem seems to be elsewhere. I think this is more than just a performance problem. The observations with gstat showing extremely high ms/w values (I have seen them as high as 22000) makes it look like IO completion interrupts are being lost. Any suggestions on where to look next? Are there obvious candidates? ATA maximum block transfer has dropped from 128k to 64k in 7.x. Am not sure where the handle is to tweak it back up but has slowed peak thruput on my Dell PE400SC. Can watch with systat -v Worse, I have a stripped array of 2 drives that won't transfer more than 43k at a chunk because apparently the stripe metadata didn't align nicely on 64k multiples. Would changes to ATA have affected arcmsr? As far as I know it is not linked to the ATA subsystem at all, though it would explain some odd instances of one of my machines becoming unresponsive a couple of times a day. Richard smime.p7s Description: S/MIME Cryptographic Signature
Random hangs with 7.1-PRE
I'm not discounting hardware here, but I'm having problems with a previously stable amd64 system (dmesg attached) now running: FreeBSD 7.1-PRERELEASE #1: Wed Nov 26 00:10:41 GMT 2008 and previously running a RELENG_7 from around Oct 15th which also exhibited the problem. The system appears to hang with SSH terminals eventually timing out, and no other services being available. The odd thing is, when I go to the console, I can switch between terminals with Alt-F2, etc, but can not type anything. Pressing the power button a couple of times gives an acpi not ready message, so it doesn't appear the system has completely hung. The system is in a cool room and under little load running basic services: samba, postgres, dhcp, etc. Never seen problems with the machine previously. Does anyone have any thoughts or suggestions on narrowing down the cause? Regards, Richard Tector Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #1: Wed Nov 26 00:10:41 GMT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DAFFY Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1795.51-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fd Stepping = 13 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe39dSSE3,RSVD2,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF Cores per package: 2 usable memory = 2137554944 (2038 MB) avail memory = 2062880768 (1967 MB) ACPI APIC Table: PTLTD APIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: PTLTDXSDT on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 uhci0: UHCI (generic) USB controller port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0x1840-0x185f irq 17 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: UHCI (generic) USB controller on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: UHCI (generic) USB controller port 0x1860-0x187f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: UHCI (generic) USB controller on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xf4a02800-0xf4a02bff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: EHCI (generic) USB 2.0 controller on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 on usb3 uhub3: 6 ports with 6 removable, self powered umass0: Cypress Semiconductor USB2.0 Storage Device, class 0/0, rev 2.00/0.01, addr 2 on uhub3 pcib1: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci5: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci5 pci6: ACPI PCI bus on pcib2 pcib3: PCI-PCI bridge at device 8.0 on pci6 pci7: PCI bus on pcib3 arcmsr0: Areca SATA Host Adapter RAID Controller (RAID6 capable) mem 0xf450-0xf4500fff,0xf400-0xf43f irq 18 at device 14.0 on pci7 ARECA RAID ADAPTER0: Driver Version 1.20.00.15 2007-10-07 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.42 2006-10-13 arcmsr0: [ITHREAD] pcib4: ACPI PCI-PCI bridge irq 16 at device 28.4 on pci0 pci13: ACPI PCI bus on pcib4 em0: Intel(R) PRO/1000 Network Connection 6.9.5 port 0x2000-0x201f mem 0xf448-0xf449,0xf440-0xf447 irq 16 at device 0.0 on pci13 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:e0:81:79:fd:0e pcib5: ACPI PCI-PCI bridge irq 17 at device 28.5 on pci0 pci15: ACPI PCI bus on pcib5 em1: Intel(R) PRO/1000 Network Connection 6.9.5 port 0x3000-0x301f mem 0xf468-0xf469,0xf460-0xf467 irq 17 at device 0.0 on pci15 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:e0:81:79:fd:0f uhci3: UHCI (generic) USB controller port 0x1880-0x189f irq 16 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: UHCI (generic
Re: Keyspan USB serial adapter
On Tue, Sep 16, 2008 at 09:24:26PM -0700, Jeremy Chadwick wrote: Since you're still in the market: I've heard wonderful things about any of the USB serial adapters that use the Prolific chip; see uplcom(4). I can second that. I use a Sitecom CN-104 (also Prolific) with several devices like Sun hardware and Soekris/Wrap systems boards and it al works perfectly (FreeBSD/Linux and Windows). http://www.sitecom.com/product.php?productname=USB+to+serial+cable+%96+60cmproductcode=CN-104productid=31subgroupid=20 -- Regards, Richard. /* Homo Sapiens non urinat in ventum */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any working ichsmb(4) platforms out there?
Bruce M Simpson wrote: Does anyone have ichsmb(4) actually seeing SMBus devices? e.g. you run smbmsg -p on your FreeBSD-STABLE system and see something. I just tried it again on my IBM ThinkPad T43 and saw nothing, all I get is: ichsmb0: device timeout, status=0x41 ...in dmesg. I have an ICH9 machine, Tyan motherboard: FreeBSD 7.0-STABLE #0: Fri Aug 1 14:57:33 BST 2008 ichsmb0: SMBus controller port 0x18e0-0x18ff mem 0xf4a03000-0xf4a030ff irq 17 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] daffy# smbmsg -p Probing for devices on /dev/smb0: Device @0x2e: rw Device @0x44: rw Device @0x60: rw Device @0x88: w Device @0xae: rw Device @0xc4: rw Device @0xe0: rw daffy# Any use? Richard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any working ichsmb(4) platforms out there?
Bruce M Simpson wrote: Richard, Thanks for this. Richard Tector wrote: I have an ICH9 machine, Tyan motherboard: FreeBSD 7.0-STABLE #0: Fri Aug 1 14:57:33 BST 2008 ichsmb0: SMBus controller port 0x18e0-0x18ff mem 0xf4a03000-0xf4a030ff irq 17 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] daffy# smbmsg -p Probing for devices on /dev/smb0: Device @0x2e: rw ... So it looks like yours works! I see no differences to RELENG_7_0. Are you using any hardware monitoring devices? Can you give bsdhwmon a shot? cheers BMS Sure. If yourself or Jeremy could send over the tarball? I don't use any hardware monitoring on it currently. Interestingly, I just tried on a couple of our webservers. Dell PowerEdge 860's with ICH7 running 7.0-STABLE, amd64. Loading the ichsmb module gives: ichsmb0: Intel 82801GB (ICH7) SMBus controller port 0x8c0-0x8df at device 31.3 on pci0 pcib0: no PRT entry for 0.31.INTB ichsmb0: can't get IRQ device_attach: ichsmb0 attach returned 6 Richard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any working ichsmb(4) platforms out there?
Richard Tector wrote: Interestingly, I just tried on a couple of our webservers. Dell PowerEdge 860's with ICH7 running 7.0-STABLE, amd64. Loading the ichsmb module gives: ichsmb0: Intel 82801GB (ICH7) SMBus controller port 0x8c0-0x8df at device 31.3 on pci0 pcib0: no PRT entry for 0.31.INTB ichsmb0: can't get IRQ device_attach: ichsmb0 attach returned 6 I found one another ICH7 machine. 6.3-STABLE, i386. It exhibits the same problems you were having. An unkillable smbmsg, and several ichsmb0: device timeout, status=0x41 Regards, Richard ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with mod_fcgid on AMD64
Earlier today I reinstalled one of our web servers (Dell PowerEdge 860 running dual or quad core Xeons) with amd64 RELENG_7 as of today, replacing i386 RELENG_7 from about a month back (clean install). After installing Apache 2.2.9 and mod_fcgid 2.2 from ports exactly as on the other i386 machines, Apache fails to start with: [Sat Sep 06 19:48:19 2008] [notice] suEXEC mechanism enabled (wrapper: /usr/local/sbin/suexec) [Sat Sep 06 19:48:19 2008] [emerg] (12)Cannot allocate memory: mod_fcgid: Can't create share memory for size %zu byte The only information I can find on the web relating to this error suggests (on Linux) adding a SharememPath config option to httpd.conf, but setting this makes no difference. A zero byte file is created, and that's it. The exact same configuration works fine with i386. Is it possible there is some incompatibility with amd64? Regards, Richard smime.p7s Description: S/MIME Cryptographic Signature
Re: ICRC's
Jeremy Chadwick [EMAIL PROTECTED] writes: If Larry was using UFS, he'd also see the above errors from the kernel. FreeBSD reports the CRC errors reported by the ATA device, ZFS reports the said data as corrupted during scrubbing or standard usage (hence the CKSUM field in 'zpool status'), and ZFS also *repairs* the corrupted data. I can't explain how the repair works, but it's one of the many features of the filesystem. I believe journalling filesystems (e.g. Um, not exactly. It's one of the features of the filesystem when you're running on a ZFS pool which is mirrored or raidz. If your ZFS pool is not mirrored or raidz-ed, checksum errors *will* be unrepairable and should show up as read errors to the application. AFAIK, the repair is just ZFS either finding a good copy of the block from the other half of the mirror (if mirrored) or reconstructing the missing block thru parity (if raidz-ed) and rewriting it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lenovo Thinkpad t61p and FreeBSD?
On Wed, Jun 04, 2008 at 07:45:12AM -0500, Josh Paetzel wrote: Hi, I'm interested in whatever cooling solutions people have... For my T60 i made a perl script for controlling the fans and the cpu speed. A few months ago i changed it to work together with powerd and i must say, i got it pretty workable now. With a normal workload (browsing the internet, reading mail, ssh'ing to control the rest of the world), the temp is under 60 degrees. http://www.unixguru.nl/made/ibm_fancontrol_fbsd.txt -- Regards, Richard. /* Homo Sapiens non urinat in ventum */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
PCI add-in parallel port problem
Hi,
I'm trying to get a PCI-express add-in parallel port card working with
7.0-STABLE, and after trying the following, I'm unable to get it to
attach to the ppc bus. The card has a MosChip NM9805 chip. Motherboard
is an ASUS P5E64 WS. (which of course has no on-board parallel port).
The card seems to be recognised by the puc layer.
I've added
device puc
to the kernel config file, and added
{ 0x9710, 0x9805, 0x, 0,
MosChip NM9805 Dual 1284 Printer port,
0,
PUC_PORT_2P, 0x10, 8, 0,
},
to sys/dev/puc/pucdata.c and with verbose booting, get the following
extracts from dmesg: (full dmesg attached below)
pcib3: slot 0 INTB hardwired to IRQ 17
pcib4: slot 1 INTA is routed to irq 17
pcib5: slot 0 INTA is routed to irq 17
pcib6: slot 0 INTA is routed to irq 17
ppc0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xdc00
ppc0: using extended I/O port range
puc0: MosChip NM9805 Dual 1284 Printer port port
0xdc00-0xdc07,0xd880-0xd887,0xd800-0xd807,0xd480-0xd487,0xd400-0xd407,0xd080-0xd08f
irq 17 at device 0.0 on pci10
pcib6: puc0 requested I/O range 0xdc00-0xdc07: in range
pcib5: puc0 requested I/O range 0xdc00-0xdc07: in range
pcib4: puc0 requested I/O range 0xdc00-0xdc07: in range
pcib3: puc0 requested I/O range 0xdc00-0xdc07: in range
puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xd800
puc0: [FILTER]
ppc0: using extended I/O port range
ppc0: using extended I/O port range
[ and later ]
ppc0: parallel port not found.
ppc0: Parallel port failed to probe at irq 7 on isa0
Any suggestions would be appreciated.
--
Richard
Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.0-STABLE #8: Sat Mar 29 16:40:32 EST 2008
[EMAIL PROTECTED]:/u3/obj/usr/src/sys/LOCAL
Preloaded elf kernel /boot/kernel/kernel at 0xc0ef1000.
Preloaded elf module /boot/kernel/snd_driver.ko at 0xc0ef1188.
Preloaded elf module /boot/kernel/snd_ad1816.ko at 0xc0ef1238.
Preloaded elf module /boot/kernel/sound.ko at 0xc0ef12e8.
Preloaded elf module /boot/kernel/snd_als4000.ko at 0xc0ef1394.
Preloaded elf module /boot/kernel/snd_atiixp.ko at 0xc0ef1444.
Preloaded elf module /boot/kernel/snd_cmi.ko at 0xc0ef14f4.
Preloaded elf module /boot/kernel/snd_cs4281.ko at 0xc0ef15a0.
Preloaded elf module /boot/kernel/snd_csa.ko at 0xc0ef1650.
Preloaded elf module /boot/kernel/snd_ds1.ko at 0xc0ef16fc.
Preloaded elf module /boot/kernel/snd_emu10kx.ko at 0xc0ef17a8.
Preloaded elf module /boot/kernel/snd_envy24.ko at 0xc0ef1858.
Preloaded elf module /boot/kernel/snd_spicds.ko at 0xc0ef1908.
Preloaded elf module /boot/kernel/snd_envy24ht.ko at 0xc0ef19b8.
Preloaded elf module /boot/kernel/snd_es137x.ko at 0xc0ef1a6c.
Preloaded elf module /boot/kernel/snd_ess.ko at 0xc0ef1b1c.
Preloaded elf module /boot/kernel/snd_sbc.ko at 0xc0ef1bc8.
Preloaded elf module /boot/kernel/snd_fm801.ko at 0xc0ef1c74.
Preloaded elf module /boot/kernel/snd_mss.ko at 0xc0ef1d24.
Preloaded elf module /boot/kernel/snd_hda.ko at 0xc0ef1dd0.
Preloaded elf module /boot/kernel/snd_ich.ko at 0xc0ef1e7c.
Preloaded elf module /boot/kernel/snd_maestro.ko at 0xc0ef1f28.
Preloaded elf module /boot/kernel/snd_maestro3.ko at 0xc0ef1fd8.
Preloaded elf module /boot/kernel/snd_neomagic.ko at 0xc0ef208c.
Preloaded elf module /boot/kernel/snd_sb16.ko at 0xc0ef2140.
Preloaded elf module /boot/kernel/snd_sb8.ko at 0xc0ef21f0.
Preloaded elf module /boot/kernel/snd_solo.ko at 0xc0ef229c.
Preloaded elf module /boot/kernel/snd_t4dwave.ko at 0xc0ef234c.
Preloaded elf module /boot/kernel/snd_via8233.ko at 0xc0ef23fc.
Preloaded elf module /boot/kernel/snd_via82c686.ko at 0xc0ef24ac.
Preloaded elf module /boot/kernel/snd_vibes.ko at 0xc0ef2560.
Preloaded elf module /boot/kernel/atapicam.ko at 0xc0ef2610.
Preloaded elf module /boot/kernel/acpi.ko at 0xc0ef26c0.
Calibrating clock(s) ... i8254 clock: 1193200 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254 frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 2999672289 Hz
CPU: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz (2999.67-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x6fb Stepping = 11
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xe3fdSSE3,RSVD2,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
AMD Features=0x2010NX,LM
AMD Features2=0x1LAHF
Cores per package: 2
Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries
1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size
1st-level data cache: 32 KB, 8-way set associative, 64 byte line size
L2 cache: 4096 kbytes, 16-way associative, 64 bytes/line
real memory = 2146697216 (2047 MB)
Physical memory chunk(s
Re: PCI add-in parallel port problem
On Sun, Mar 30, 2008 at 12:56:31AM +0100, Erik Trulsson wrote:
On Sun, Mar 30, 2008 at 10:05:09AM +1100, Richard Perini wrote:
Hi,
I'm trying to get a PCI-express add-in parallel port card working with
7.0-STABLE, and after trying the following, I'm unable to get it to
attach to the ppc bus. The card has a MosChip NM9805 chip. Motherboard
is an ASUS P5E64 WS. (which of course has no on-board parallel port).
The card seems to be recognised by the puc layer.
I've added
device puc
to the kernel config file, and added
{ 0x9710, 0x9805, 0x, 0,
MosChip NM9805 Dual 1284 Printer port,
0,
PUC_PORT_2P, 0x10, 8, 0,
},
to sys/dev/puc/pucdata.c and with verbose booting, get the following
extracts from dmesg: (full dmesg attached below)
pcib3: slot 0 INTB hardwired to IRQ 17
pcib4: slot 1 INTA is routed to irq 17
pcib5: slot 0 INTA is routed to irq 17
pcib6: slot 0 INTA is routed to irq 17
ppc0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xdc00
ppc0: using extended I/O port range
puc0: MosChip NM9805 Dual 1284 Printer port port
0xdc00-0xdc07,0xd880-0xd887,0xd800-0xd807,0xd480-0xd487,0xd400-0xd407,0xd080-0xd08f
irq 17 at device 0.0 on pci10
pcib6: puc0 requested I/O range 0xdc00-0xdc07: in range
pcib5: puc0 requested I/O range 0xdc00-0xdc07: in range
pcib4: puc0 requested I/O range 0xdc00-0xdc07: in range
pcib3: puc0 requested I/O range 0xdc00-0xdc07: in range
puc0: Reserved 0x8 bytes for rid 0x18 type 4 at 0xd800
puc0: [FILTER]
ppc0: using extended I/O port range
ppc0: using extended I/O port range
[ and later ]
ppc0: parallel port not found.
ppc0: Parallel port failed to probe at irq 7 on isa0
Any suggestions would be appreciated.
Take a look in /boot/device.hints
Do you have any lines in there referring to ppc0 ?
If so try commenting them out.
Thanks for the suggestion, Erik.
I commented out
hint.ppc.0.at=isa
hint.ppc.0.irq=7
from /boot/device.hints and that got rid of
ppc0: parallel port not found.
ppc0: Parallel port failed to probe at irq 7 on isa0
from dmesg, but unfortunately nothing else changed.
--
Richard Perini
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad0 READ_DMA TIMEOUT errors on install of 7.0-RELEASE
This is just a 'me too'. I've experienced the following on 2 seperate and very different i386 systems: ad4: TIMEOUT - READ_DMA retrying (1 retry left) LBA=1520671 ad4: TIMEOUT - READ_DMA retrying (0 retries left) LBA=1520671 ad4: FAILURE - READ_DMA timed out LBA=1520671 That was on an Intel i815 based board running a Celeron 1.3 but with a Highpoint HPT370 IDE RAID controller. The above disk is a Seagate Barracuda 7200.10 80GB, and one of a pair (both have the same problem). The error occurs just after disk detection at the end of the boot where normally it would mount / and start running rc The second system is a Dual P3 Serverworks system with an IBM 60GXP Deskstar 40GB disk connected to the onboard UDMA33 controller. Disabling DMA in loader.conf does the trick and allows both machines to boot. I have tried different drive combinations and controllers but to no avail. Neither of the systems are required for use just at the moment, so I'm quite happy to test patches once they're available, or provide further details as required. Regards, Richard Tector smime.p7s Description: S/MIME Cryptographic Signature
