Failure during buildworld of FreeBSD 9 on FreeBSD 12.0-CURRENT
Gentlefolk,
I have run into a problem building a FreeBSD 9 world & kernel on a
FreeBSD 12.0-CURRENT host.
I have my FreeBSD 9 tree located in /usr/src-9 which was refreshed via svn
yesterday.
The build is being executed on a host running FreeBSD 12.0-CURRENT #3 r308389 .
The steps that were followed were:
cd /usr/src-10
svn update
make buildworld -j8
This starts and emits the following:
root@fmaster:/usr/src-9 # make buildworld -j8
--- upgrade_checks ---
--- make ---
--
>>> Building an up-to-date make(1)
--
--- obj ---
--- _proginstall ---
sh /usr/src-9/tools/install.sh -s -o root -g wheel -m 555 make
/usr/obj/usr/src-9/make.amd64/make
--- buildworld ---
Unknown modifier 'U'
"/usr/share/mk/bsd.compiler.mk", line 38: Malformed conditional
(${MK_CCACHE_BUILD:Uno} == "yes" && !make(showconfig) &&
(${CC:M*ccache/world/*} == "" || ${CXX:M*ccache/world/*} == ""))
"/usr/share/mk/bsd.compiler.mk", line 107: missing `in' in for
X_ in CC $${_empty_var_} XCC X_
"/usr/share/mk/bsd.compiler.mk", line 108: Malformed conditional (${cc} == "CC"
|| !empty(XCC))
Unknown modifier 'h'
Error expanding embedded variable.
"/usr/src-9/Makefile.inc1", line 134: warning:
"/usr/obj/usr/src-9/make.amd64/make -C /usr/src-9/release -V REVISION" returned
non-zero status
Unknown modifier 'U'
"/usr/share/mk/bsd.compiler.mk", line 38: Malformed conditional
(${MK_CCACHE_BUILD:Uno} == "yes" && !make(showconfig) &&
(${CC:M*ccache/world/*} == "" || ${CXX:M*ccache/world/*} == ""))
"/usr/share/mk/bsd.compiler.mk", line 107: missing `in' in for
X_ in CC $${_empty_var_} XCC X_
"/usr/share/mk/bsd.compiler.mk", line 108: Malformed conditional (${cc} == "CC"
|| !empty(XCC))
Unknown modifier 'h'
Error expanding embedded variable.
"/usr/src-9/Makefile.inc1", line 135: warning:
"/usr/obj/usr/src-9/make.amd64/make -C /usr/src-9/release -V BRANCH" returned
non-zero status
---
I realized that the build was using /usr/share/mk/bsd.compiler.mk
I then set the environment variable MAKESYSPATH to /usr/src-9/share/mk and
retried.
The inital errors/warning about Malformed conditionals dissapear, however
the buildworld then fails at the same point as before.
Note that a build using a FreeBSD 9 jail hosted on the same
FreeBSD 12.0-CURRENT server works correctly without problems.
I do not have any problem doing a buildworld of FreeBSD 10 world done on the sam
e FreeBSD 12.0 host.
The FreeBSD 12.0-CURRENT host does not have an /etc/make.conf or /etc/src.conf
My understanding is that building like this should work seamlessly.
I have transcripts of both builds available if required but I cannot attach
them to this email becuse of mailing list posting size limitations.
--
David Dodd
Bing Technologies Pty Ltd
Suite 54, Jones Bay Wharf
26-32 Pirrama Road
Pyrmont NSW 2009 Australia
Telephone +612 9552 5500 Fax +612 9552 5549
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
trivial freebsd 9 (and later) route patch reminder / question
Noticed in 2013 a problem with FreeBSD 9 due to a MFC which broke my VPN. There's a bug report with a trivial patch at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=179829 The problem is still present in FreeBSD 10 and the code in HEAD also looks unchanged (meaning the problem likely still exists). It would nice to fix the problem before FreeBSD 11 is branched. Does the current bug report suffice, or is it buried since it was originally discovered on FreeBSD 9? Basically I wasn't sure if I needed to open a new report against HEAD. -- John - | Feith Systems | Voice: 1-215-646-8000 | Email: j...@feith.com | |John Wehle| Fax: 1-215-540-5495 | | - ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Awful FreeBSD 9 block IO performance in KVM
- Original Message - From: Dieter BSD dieter...@engineer.com To: hack...@freebsd.org, curr...@freebsd.org Sent: Sunday, July 22, 2012 1:19:32 AM Subject: Re: Awful FreeBSD 9 block IO performance in KVM da0: 3.300MB/s transfers da0: Command Queueing enabled root@freebsd:/root # dd if=/dev/zero of=/dev/da1 bs=16384 count=262144 4294967296 bytes transferred in 615.840721 secs (6974153 bytes/sec) 1) Does a larger block size (bs=1m) help? 2) That's roughly the speed I'd expect without queueing. Is it really making effective use of queueing, or is something limiting queueing to one transfer at a time? The likely fix here is basically do vtblk_startio() in a separate kproc that vtblk_strategy() enqueues bio's to. This has been on my todo for a while, but haven't had the time. Also, the use of bioq_disksort() probably doesn't gain much for virtualized disks, but I never found much of a difference in my testing. ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Awful FreeBSD 9 block IO performance in KVM
On 19 July 2012 11:27, Richard Yao r...@gentoo.org wrote: Dear Everyone, FreeBSD 9 has awful block IO performance in KVM. I have experienced it and others have experienced it. Someone posted slides to slideshare with benchmarks documenting it: http://www.slideshare.net/TakeshiHasegawa1/runningfreebsdonlinuxkvm Slides 13 and 20 are particular eye openers. Does anyone know what is wrong? For those watching at home - this is bad performance _with_ the virtio drivers themselves, not just with SCSI emulation. Slide 17 is very telling - the operation latency is quite high. Richard, are you able to easily test out things on FreeBSD-HEAD guest in a Linux KVM? If so, some of the storage/block/GEOM driver people may be able to step up and start offering some ideas. Thanks, Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Awful FreeBSD 9 block IO performance in KVM
On 07/20/2012 03:44 PM, Adrian Chadd wrote: On 19 July 2012 11:27, Richard Yao r...@gentoo.org wrote: Dear Everyone, FreeBSD 9 has awful block IO performance in KVM. I have experienced it and others have experienced it. Someone posted slides to slideshare with benchmarks documenting it: http://www.slideshare.net/TakeshiHasegawa1/runningfreebsdonlinuxkvm Slides 13 and 20 are particular eye openers. Does anyone know what is wrong? For those watching at home - this is bad performance _with_ the virtio drivers themselves, not just with SCSI emulation. Slide 17 is very telling - the operation latency is quite high. Richard, are you able to easily test out things on FreeBSD-HEAD guest in a Linux KVM? If so, some of the storage/block/GEOM driver people may be able to step up and start offering some ideas. Thanks, Adrian Dear Adrian, I am in the process of setting up a VM instance specifically for this. While installing it, I noticed that qemu-kvm printed 'lsi_scsi: error: ORDERED queue not implemented', which might be a clue as to why the block device performance is bad. Also, I will try testing raw disk IO for Ivan after I have it setup. Yours truly, Richard Yao signature.asc Description: OpenPGP digital signature
Re: Awful FreeBSD 9 block IO performance in KVM
On 20 July 2012 15:26, Richard Yao r...@gentoo.org wrote: I am in the process of setting up a VM instance specifically for this. While installing it, I noticed that qemu-kvm printed 'lsi_scsi: error: ORDERED queue not implemented', which might be a clue as to why the block device performance is bad. Also, I will try testing raw disk IO for Ivan after I have it setup. Thanks for setting this up. Setting up an easily reproducible environment is by far the biggest and most helpful step here. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On 06/22/12 08:22, Hans Petter Selasky wrote: On Friday 22 June 2012 08:01:38 O. Hartmann wrote: I have a USB drive/stick, Lexar USB Flash drive as reported by FreeBSD shown below. When first used, I was able to put approx. 30 GB of data on it - it was visible to FreeBSD 9 and 10 as expected. A Linux system at the lab was also capable of recognizing it. After that, I tried to operate on the stick on a Notebook, FreeBSD 9, and another station, FreeBSD 10. But FreeBSD didn't recognize the USB drive anymore - sometimes, but this seems to be a gambling issue :-( Trying Linux on different hardware platforms and even those machines prior not recognizing the USB drive do recognize the drive as Lexar USB Flash drive with 64GB. That is Suse Linux (some 12.XX), that is Ubuntu 12.04, that is Windows 7 Pro/x64. I can format the drive, I can push and pull data from it. So, since the USB drive won't work with three different FreeBSD boxes (one running 9-STABLE, two 10-CURRENT, all systems most recent sources and buildworld from a day ago). I suspect either a weird configuration issue I use on all platforms in questions in common triggering the weird beviour - or FreeBSD is simply incapable of handling the 64GB drive. I do not have issues with USB drives with capacities of 32, 8 or 4 GB of different brands. As shown in the portion of the dmesg below, the USB drive is recognized physically. It doesn't matter whether USB port I use (I tried all available on all boxes and in most cases I use a Dell UltraSharp powered in-screen HUB). Since other OSes handle the drive as expected, I exclude hardware issues. All FreeBSD in common is the fact I use the new device ahaci/device ata CAM/ATA scheme with devcie scbus in the kernel (I use custom kernels!). Apart from trying a GENERIC kernel (which is next I will do this weekend), does anyone have similar experiences and probably solutions? Regards, oh ugen7.6: Lexar at usbus7 umass1: Lexar USB Flash Drive, class 0/0, rev 2.00/11.00, addr 6 on usbus7 (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Error 5, Retries exhausted Hi, After plugging the device, try: usbconfig -d 7.6 add_quirk UQ_MSC_NO_INQUIRY Then re-plug it. I'm sorry to say a lot of USB flash sticks out there are broken and only tested with the timing of MS Windows. Part of the problem is that it is difficult to autodetect these issues, because once you trigger the non- supported SCSI command, then the flash key stops working like you experience. I would be more than glad to open up an office to certify USB devices for use with FreeBSD :-) --HPS I tried the USB drive this morning with the recommended quirk shown above on FreeBSD 10.0-CURRENT #1 r237462: Sat Jun 23 01:00:35 CEST 2012 without success. I get the same error message as shown above. With or without quirk. I then started Windows 7 on the same box. The USB drive is seen as expected and reflects what I experienced on every other non-FreeBSD box and hardware in the lab on last week. I reformatted the USB drive with extFAT and standard block size on Windows 7. The USB drive is now seen again on FreeBSD and recognized as a drive. Seen in my sloppy terminology means: recognized as a disk. The hardware is recognized, but it is not recognized as a drive. The fact, that the very first time after I bought that USB drive, I was able to put several GB on it, use it on both FreeBSD 9-STABLE and 10-CURRENT, and then it broke, drives me nuts. Using the very same pen drive on other OSes even on the same hardware without issues makes me believe FreeBSD does have an issue, not the USB drive. I will fill the USB drive with data and try to use it very often on FreeBSD. Last time the error occured, it was read by a Suse Linux box. If I wouldn't know better I would say Linux tries to kill the USB drive ... But Linux did see it all the time. A usual customer would see it the same way, I guess. I will test and report next week when I have access to the other boxes and OSes again. Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
At 09:21 23/06/2012, you wrote: I tried the USB drive this morning with the recommended quirk shown above on FreeBSD 10.0-CURRENT #1 r237462: Sat Jun 23 01:00:35 CEST 2012 without success. I get the same error message as shown above. With or without quirk. I then started Windows 7 on the same box. The USB drive is seen as expected and reflects what I experienced on every other non-FreeBSD box and hardware in the lab on last week. I reformatted the USB drive with extFAT and standard block size on Windows 7. The USB drive is now seen again on FreeBSD and recognized as a drive. Seen in my sloppy terminology means: recognized as a disk. The hardware is recognized, but it is not recognized as a drive. AFAIK extFAT is not directly supported by FreeBSD current. You must use fusefs-exfat to mount them. If you try to mount it as if it is a fat32, it won't work or weird problems may happen. It may be that fusefs-extfat has a bug and you get a 00 on rolldice encounter table. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On 21 June 2012 23:22, Hans Petter Selasky hsela...@c2i.net wrote: usbconfig -d 7.6 add_quirk UQ_MSC_NO_INQUIRY Then re-plug it. I'm sorry to say a lot of USB flash sticks out there are broken and only tested with the timing of MS Windows. Part of the problem is that it is difficult to autodetect these issues, because once you trigger the non- supported SCSI command, then the flash key stops working like you experience. I would be more than glad to open up an office to certify USB devices for use with FreeBSD :-) Question - if that's the case, then why are we even doing that by default? Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On 06/23/12 10:39, Eduardo Morras wrote: At 09:21 23/06/2012, you wrote: I tried the USB drive this morning with the recommended quirk shown above on FreeBSD 10.0-CURRENT #1 r237462: Sat Jun 23 01:00:35 CEST 2012 without success. I get the same error message as shown above. With or without quirk. I then started Windows 7 on the same box. The USB drive is seen as expected and reflects what I experienced on every other non-FreeBSD box and hardware in the lab on last week. I reformatted the USB drive with extFAT and standard block size on Windows 7. The USB drive is now seen again on FreeBSD and recognized as a drive. Seen in my sloppy terminology means: recognized as a disk. The hardware is recognized, but it is not recognized as a drive. AFAIK extFAT is not directly supported by FreeBSD current. You must use fusefs-exfat to mount them. If you try to mount it as if it is a fat32, it won't work or weird problems may happen. It may be that fusefs-extfat has a bug and you get a 00 on rolldice encounter table. ... but even this does not work if FreeBSD does not recognize a device like /dev/da1, does it? Even with a ext4 filesystem, the computer should recognize a devcie I could access to mount via /dev/da1 signature.asc Description: OpenPGP digital signature
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On Saturday 23 June 2012 11:52:53 Adrian Chadd wrote: On 21 June 2012 23:22, Hans Petter Selasky hsela...@c2i.net wrote: usbconfig -d 7.6 add_quirk UQ_MSC_NO_INQUIRY Then re-plug it. I'm sorry to say a lot of USB flash sticks out there are broken and only tested with the timing of MS Windows. Part of the problem is that it is difficult to autodetect these issues, because once you trigger the non- supported SCSI command, then the flash key stops working like you experience. I would be more than glad to open up an office to certify USB devices for use with FreeBSD :-) Question - if that's the case, then why are we even doing that by default? Hi, Do you want a blacklist or do you want a whitelist? Please explain the pros and cons. I believe that those that program wrong shall be held responsible for that and given a chance to clean up, and not the opposite way around. As a senior programmer I can only testify that many people care equally little about what their computer is made of and what they eat. We probably need a control body to certify USB devices that is cheaper than USB.org, simply put. I think it is a bad idea to cripple all USB SCSI devices because what looks like the majority do not obey the rules of the specifications they are supposed to support. Else we need to make a new USB SCSI class for devices that are certified and one for devices that are not certified. Non-certified devices can have a limited SCSI command set, which should be implemented in the CAM layer like some kind of flag. If we could join heads on the Linux guys on this, we might be able to do something! Like having a pop-up every time a USB device fails certain tests. From the history we can predict what people will do when they do not know what they are doing. They will nail the guy doing it right and let the guy doing it wrong go free. And it seems like this happened before too ;-) I have a personal FreeBSD-native USB test utilty that runs mass storage devices through a series of tests. Most USB mass storage devices I've tested so far have obvious bugs, which either means their firmware can be hacked or made to crash. Also worth noting, that many USB device are not certified at all. It might be clever to look for the USB logo from USB.org next time you want to transfer X GB of personal data from location X to Y. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
and hardware in the lab on last week. I reformatted the USB drive with extFAT and standard block size on Windows 7. The USB drive is now seen again on FreeBSD and recognized as this points that the pendrive's controller is not just flaky but horrid. The communiation with OS, and how/whether it is configured properly should not depend on what data is written to it - in your case exFAT metadata. It seems that controller manufacturer just did something to run on windows and linux instead of something that conform to USB mass storage interface standard :( Sorry but it may be hopeless case. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
I have a USB drive/stick, Lexar USB Flash drive as reported by FreeBSD shown below. When first used, I was able to put approx. 30 GB of data on it - it was visible to FreeBSD 9 and 10 as expected. A Linux system at the lab was also capable of recognizing it. After that, I tried to operate on the stick on a Notebook, FreeBSD 9, and another station, FreeBSD 10. But FreeBSD didn't recognize the USB drive anymore - sometimes, but this seems to be a gambling issue :-( Trying Linux on different hardware platforms and even those machines prior not recognizing the USB drive do recognize the drive as Lexar USB Flash drive with 64GB. That is Suse Linux (some 12.XX), that is Ubuntu 12.04, that is Windows 7 Pro/x64. I can format the drive, I can push and pull data from it. So, since the USB drive won't work with three different FreeBSD boxes (one running 9-STABLE, two 10-CURRENT, all systems most recent sources and buildworld from a day ago). I suspect either a weird configuration issue I use on all platforms in questions in common triggering the weird beviour - or FreeBSD is simply incapable of handling the 64GB drive. I do not have issues with USB drives with capacities of 32, 8 or 4 GB of different brands. As shown in the portion of the dmesg below, the USB drive is recognized physically. It doesn't matter whether USB port I use (I tried all available on all boxes and in most cases I use a Dell UltraSharp powered in-screen HUB). Since other OSes handle the drive as expected, I exclude hardware issues. All FreeBSD in common is the fact I use the new device ahaci/device ata CAM/ATA scheme with devcie scbus in the kernel (I use custom kernels!). Apart from trying a GENERIC kernel (which is next I will do this weekend), does anyone have similar experiences and probably solutions? Regards, oh ugen7.6: Lexar at usbus7 umass1: Lexar USB Flash Drive, class 0/0, rev 2.00/11.00, addr 6 on usbus7 (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Error 5, Retries exhausted signature.asc Description: OpenPGP digital signature
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On Thu, Jun 21, 2012 at 11:01 PM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: I have a USB drive/stick, Lexar USB Flash drive as reported by FreeBSD shown below. When first used, I was able to put approx. 30 GB of data on it - it was visible to FreeBSD 9 and 10 as expected. A Linux system at the lab was also capable of recognizing it. After that, I tried to operate on the stick on a Notebook, FreeBSD 9, and another station, FreeBSD 10. But FreeBSD didn't recognize the USB drive anymore - sometimes, but this seems to be a gambling issue :-( Trying Linux on different hardware platforms and even those machines prior not recognizing the USB drive do recognize the drive as Lexar USB Flash drive with 64GB. That is Suse Linux (some 12.XX), that is Ubuntu 12.04, that is Windows 7 Pro/x64. I can format the drive, I can push and pull data from it. So, since the USB drive won't work with three different FreeBSD boxes (one running 9-STABLE, two 10-CURRENT, all systems most recent sources and buildworld from a day ago). I suspect either a weird configuration issue I use on all platforms in questions in common triggering the weird beviour - or FreeBSD is simply incapable of handling the 64GB drive. I do not have issues with USB drives with capacities of 32, 8 or 4 GB of different brands. As shown in the portion of the dmesg below, the USB drive is recognized physically. It doesn't matter whether USB port I use (I tried all available on all boxes and in most cases I use a Dell UltraSharp powered in-screen HUB). Since other OSes handle the drive as expected, I exclude hardware issues. All FreeBSD in common is the fact I use the new device ahaci/device ata CAM/ATA scheme with devcie scbus in the kernel (I use custom kernels!). Apart from trying a GENERIC kernel (which is next I will do this weekend), does anyone have similar experiences and probably solutions? I don't personally have any relevant experience with this device, but having the exact revisions of code where this was working and where it was failing would be helpful, in order to perform a binary search to determine whether or not this is a regression. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On Friday 22 June 2012 08:01:38 O. Hartmann wrote: I have a USB drive/stick, Lexar USB Flash drive as reported by FreeBSD shown below. When first used, I was able to put approx. 30 GB of data on it - it was visible to FreeBSD 9 and 10 as expected. A Linux system at the lab was also capable of recognizing it. After that, I tried to operate on the stick on a Notebook, FreeBSD 9, and another station, FreeBSD 10. But FreeBSD didn't recognize the USB drive anymore - sometimes, but this seems to be a gambling issue :-( Trying Linux on different hardware platforms and even those machines prior not recognizing the USB drive do recognize the drive as Lexar USB Flash drive with 64GB. That is Suse Linux (some 12.XX), that is Ubuntu 12.04, that is Windows 7 Pro/x64. I can format the drive, I can push and pull data from it. So, since the USB drive won't work with three different FreeBSD boxes (one running 9-STABLE, two 10-CURRENT, all systems most recent sources and buildworld from a day ago). I suspect either a weird configuration issue I use on all platforms in questions in common triggering the weird beviour - or FreeBSD is simply incapable of handling the 64GB drive. I do not have issues with USB drives with capacities of 32, 8 or 4 GB of different brands. As shown in the portion of the dmesg below, the USB drive is recognized physically. It doesn't matter whether USB port I use (I tried all available on all boxes and in most cases I use a Dell UltraSharp powered in-screen HUB). Since other OSes handle the drive as expected, I exclude hardware issues. All FreeBSD in common is the fact I use the new device ahaci/device ata CAM/ATA scheme with devcie scbus in the kernel (I use custom kernels!). Apart from trying a GENERIC kernel (which is next I will do this weekend), does anyone have similar experiences and probably solutions? Regards, oh ugen7.6: Lexar at usbus7 umass1: Lexar USB Flash Drive, class 0/0, rev 2.00/11.00, addr 6 on usbus7 (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Error 5, Retries exhausted Hi, After plugging the device, try: usbconfig -d 7.6 add_quirk UQ_MSC_NO_INQUIRY Then re-plug it. I'm sorry to say a lot of USB flash sticks out there are broken and only tested with the timing of MS Windows. Part of the problem is that it is difficult to autodetect these issues, because once you trigger the non- supported SCSI command, then the flash key stops working like you experience. I would be more than glad to open up an office to certify USB devices for use with FreeBSD :-) --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
incapable of handling the 64GB drive. I do not have issues with USB it's not about capacity. But seems some quirks for that pendrive (which have buggy firmware) has to be added, as it doesn't respond for inquiry command. sorry i am not USB expert. umass1: Lexar USB Flash Drive, class 0/0, rev 2.00/11.00, addr 6 on usbus7 (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Error 5, Retries exhausted ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On Fri, 22 Jun 2012 08:22:19 +0200 Hans Petter Selasky hsela...@c2i.net wrote: (snip) I would be more than glad to open up an office to certify USB devices for use with FreeBSD :-) My elder colleague often told me that it is the easiest and well-working way to check whether the one is certified to work for Mac OS X to get USB mass storage devices which work with *BSD :) Just my 5 yen, -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On 22.06.12 09:22, Hans Petter Selasky wrote: I'm sorry to say a lot of USB flash sticks out there are broken and only tested with the timing of MS Windows. Part of the problem is that it is difficult to autodetect these issues, because once you trigger the non- supported SCSI command, then the flash key stops working like you experience. Morale of the story: Don't even dare put any hardware that you need working on FreeBSD under control of Linux or Windows. grin OS X is safe. By the way, I am serious! Sometimes, I am inclined to believe the conspiracy theory that those operating systems do this on purpose. Often to claim superiority as in see, it works with our OS, ok?. I believe if we get enough details of how this particular USB stick is exactly recognized an quirk definition for it could be added to save future users from such behavior. But the bit it was used with Linux might need to be supplied by the user. Daniel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On Fri, Jun 22, 2012 at 1:01 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: I have a USB drive/stick, Lexar USB Flash drive as reported by FreeBSD shown below. When first used, I was able to put approx. 30 GB of data on it - it was visible to FreeBSD 9 and 10 as expected. A Linux system at the lab was also capable of recognizing it. After that, I tried to operate on the stick on a Notebook, FreeBSD 9, and another station, FreeBSD 10. But FreeBSD didn't recognize the USB drive anymore - sometimes, but this seems to be a gambling issue :-( Trying Linux on different hardware platforms and even those machines prior not recognizing the USB drive do recognize the drive as Lexar USB Flash drive with 64GB. That is Suse Linux (some 12.XX), that is Ubuntu 12.04, that is Windows 7 Pro/x64. I can format the drive, I can push and pull data from it. So, since the USB drive won't work with three different FreeBSD boxes (one running 9-STABLE, two 10-CURRENT, all systems most recent sources and buildworld from a day ago). I suspect either a weird configuration issue I use on all platforms in questions in common triggering the weird beviour - or FreeBSD is simply incapable of handling the 64GB drive. I do not have issues with USB drives with capacities of 32, 8 or 4 GB of different brands. As shown in the portion of the dmesg below, the USB drive is recognized physically. It doesn't matter whether USB port I use (I tried all available on all boxes and in most cases I use a Dell UltraSharp powered in-screen HUB). Since other OSes handle the drive as expected, I exclude hardware issues. All FreeBSD in common is the fact I use the new device ahaci/device ata CAM/ATA scheme with devcie scbus in the kernel (I use custom kernels!). Apart from trying a GENERIC kernel (which is next I will do this weekend), does anyone have similar experiences and probably solutions? Regards, oh ugen7.6: Lexar at usbus7 umass1: Lexar USB Flash Drive, class 0/0, rev 2.00/11.00, addr 6 on usbus7 (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Error 5, Retries exhausted I see similar behavior and output on my Dell M6500 notebook running CURRENT, but only on two ports which are some type of hybrid USB 2.0/3.0 (configurable via BIOS setting). If I use either of these ports with a USB 2.0 device while running the ports in USB 3.0 mode (using xhci(4)), I can't reliably get a device to properly attach. I say reliably, because every once in a while, I can plug a device in and it works fine, even multiple times and after reboots. If I configure these ports to run in USB 2.0 mode (using ehci(4)), all of my USB 2.0 devices seem to work without fail. However, USB 3.0 devices do not attach on these ports when they are configured as USB 2.0 ports. So, at least on my notebook, these ports must be configured at either 2.0 or 3.0, depending on which device I plan on using :( I have one other port on this same system that is USB 2.0-only, and it works all of the time :) I'll have to try and add a hub into the mix to see if perhaps it is a power issue (although with a recent Linux kernel and Windows 7, all is well no matter what configuration I provide). It may be that FreeBSD's USB subsystem lacks some extra bit of code required to configure the ports properly in regard to power. -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
About kern.ipc.semmap on FreeBSD 9
Hello. I’m currently testing FreeBSD 9.0, I want to use it as a OS for a PostgreSQL Server. However, it is recommended to modified some paramerts such as semaphores (http://www.postgresql.org/docs/9.1/static/kernel-resources.html ): kern.ipc.semmap=256 But when I tried to change the value on FreeBSD this pops up: sysctl: unknown oid 'kern.ipc.semmap' What Can I do to resolve this issue?. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: About kern.ipc.semmap on FreeBSD 9
Efraín Déctor wrote: Hello. I’m currently testing FreeBSD 9.0, I want to use it as a OS for a PostgreSQL Server. However, it is recommended to modified some paramerts such as semaphores (http://www.postgresql.org/docs/9.1/static/kernel-resources.html ): kern.ipc.semmap=256 But when I tried to change the value on FreeBSD this pops up: sysctl: unknown oid 'kern.ipc.semmap' What Can I do to resolve this issue?. This one can be modified only in /boot/loader.conf -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: About kern.ipc.semmap on FreeBSD 9
Hello. Thank you for your answer. Where can i find this type of changes?. Because on FreeBSD 8.2 I had to put kern.ipc.semmap=256 on sysctl.conf. Thanks in advance. -Mensaje original- From: Volodymyr Kostyrko Sent: Thursday, March 22, 2012 10:15 AM To: Efraín Déctor Cc: freebsd-current@freebsd.org Subject: Re: About kern.ipc.semmap on FreeBSD 9 Efraín Déctor wrote: Hello. I’m currently testing FreeBSD 9.0, I want to use it as a OS for a PostgreSQL Server. However, it is recommended to modified some paramerts such as semaphores (http://www.postgresql.org/docs/9.1/static/kernel-resources.html ): kern.ipc.semmap=256 But when I tried to change the value on FreeBSD this pops up: sysctl: unknown oid 'kern.ipc.semmap' What Can I do to resolve this issue?. This one can be modified only in /boot/loader.conf -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: About kern.ipc.semmap on FreeBSD 9
On Thu, 22 Mar 2012 10:02:15 -0600 Efraín Déctor efraindec...@motumweb.com wrote: Hello. I’m currently testing FreeBSD 9.0, I want to use it as a OS for a PostgreSQL Server. However, it is recommended to modified some paramerts such as semaphores (http://www.postgresql.org/docs/9.1/static/kernel-resources.html ): kern.ipc.semmap=256 But when I tried to change the value on FreeBSD this pops up: sysctl: unknown oid 'kern.ipc.semmap' What Can I do to resolve this issue?. This has been removed in r224016: http://svnweb.freebsd.org/base/head/sys/kern/sysv_sem.c?r1=223825r2=224016 -- Herbert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: About kern.ipc.semmap on FreeBSD 9
Thank you, I don't know why PostgreSQL still recommends to use it. But now I can keep testing FreeBSD 9. Thanks everyone. -Mensaje original- From: Herbert J. Skuhra Sent: Thursday, March 22, 2012 3:52 PM To: Efraín Déctor Cc: freebsd-current@freebsd.org Subject: Re: About kern.ipc.semmap on FreeBSD 9 On Thu, 22 Mar 2012 10:02:15 -0600 Efraín Déctor efraindec...@motumweb.com wrote: Hello. I’m currently testing FreeBSD 9.0, I want to use it as a OS for a PostgreSQL Server. However, it is recommended to modified some paramerts such as semaphores (http://www.postgresql.org/docs/9.1/static/kernel-resources.html ): kern.ipc.semmap=256 But when I tried to change the value on FreeBSD this pops up: sysctl: unknown oid 'kern.ipc.semmap' What Can I do to resolve this issue?. This has been removed in r224016: http://svnweb.freebsd.org/base/head/sys/kern/sysv_sem.c?r1=223825r2=224016 -- Herbert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: About kern.ipc.semmap on FreeBSD 9
On 03/23/2012 01:52, Herbert J. Skuhra wrote: On Thu, 22 Mar 2012 10:02:15 -0600 Efraín Déctorefraindec...@motumweb.com wrote: Hello. I’m currently testing FreeBSD 9.0, I want to use it as a OS for a PostgreSQL Server. However, it is recommended to modified some paramerts such as semaphores (http://www.postgresql.org/docs/9.1/static/kernel-resources.html ): kern.ipc.semmap=256 But when I tried to change the value on FreeBSD this pops up: sysctl: unknown oid 'kern.ipc.semmap' What Can I do to resolve this issue?. This has been removed in r224016: http://svnweb.freebsd.org/base/head/sys/kern/sysv_sem.c?r1=223825r2=224016 Hello. Could someone briefly explain, why this tunable was removed? I couldn't find anything relevant in 9.0 release notes. -- Best regards, Alexander Pyhalov, system administrator of Computer Center of Southern Federal University ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: About kern.ipc.semmap on FreeBSD 9
On 23 March 2012 09:20, Alexander Pyhalov a...@rsu.ru wrote: On 03/23/2012 01:52, Herbert J. Skuhra wrote: On Thu, 22 Mar 2012 10:02:15 -0600 Efraín Déctorefraindec...@motumweb.com wrote: Hello. I’m currently testing FreeBSD 9.0, I want to use it as a OS for a PostgreSQL Server. However, it is recommended to modified some paramerts such as semaphores (http://www.postgresql.org/docs/9.1/static/kernel-resources.html ): kern.ipc.semmap=256 But when I tried to change the value on FreeBSD this pops up: sysctl: unknown oid 'kern.ipc.semmap' What Can I do to resolve this issue?. This has been removed in r224016: http://svnweb.freebsd.org/base/head/sys/kern/sysv_sem.c?r1=223825r2=224016 Hello. Could someone briefly explain, why this tunable was removed? I couldn't find anything relevant in 9.0 release notes. Hey, as it was explained in the comment to the commit that removed semmap, this tune didn't do nothing since its appearance. If that really hurts you, and you think that this will make you feel better, then you can always revert that revision and continue to tune its option up :) -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: add k3772z 3g modem support for FreeBSD-9
Hi! Would you please submit this as a PR? That way it Doesn't get (as) lost. Thanks! adrian On 6 March 2012 16:53, Oliver Pinter pin...@tresorium.hu wrote: Hi all! I wrote a patch, to add support for Vodafone K3772-Z 3g modem. -- Oliver Pinter (Tresorium) ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: add k3772z 3g modem support for FreeBSD-9
Hi! usb/165815 On 3/7/12, Adrian Chadd adr...@freebsd.org wrote: Hi! Would you please submit this as a PR? That way it Doesn't get (as) lost. Thanks! adrian On 6 March 2012 16:53, Oliver Pinter pin...@tresorium.hu wrote: Hi all! I wrote a patch, to add support for Vodafone K3772-Z 3g modem. -- Oliver Pinter (Tresorium) ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
add k3772z 3g modem support for FreeBSD-9
Hi all!
I wrote a patch, to add support for Vodafone K3772-Z 3g modem.
--
Oliver Pinter
(Tresorium)
commit 092aa1246e1dde0ffe11a7bc06b540f4fa5851c9
Author: Oliver Pinter oliver.p...@gmail.com
Date: Wed Mar 7 01:47:51 2012 +0100
added support for Vodafone 3772-Z to u3g driver
ugen1.2: Vodafone at usbus1
ugen1.2: Vodafone at usbus1 (disconnected)
ugen1.2: Vodafone at usbus1
umodem0: Vodafone K3772-Z, class 2/0, rev 2.00/0.01, addr 2 on usbus1
umodem0: data interface 2, has CM over data, has break
umodem1: Vodafone K3772-Z, class 2/0, rev 2.00/0.01, addr 2 on usbus1
umodem1: data interface 4, has CM over data, has break
cdce0: Vodafone K3772-Z, class 2/0, rev 2.00/0.01, addr 2 on usbus1
ue0: USB Ethernet on cdce0
ue0: Ethernet address: 02:77:c1:XX:XX:XX
umass0: Vodafone K3772-Z, class 2/0, rev 2.00/0.01, addr 2 on usbus1
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0
(probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(probe0:umass-sim0:0:0:0): SCSI status: Check Condition
(probe0:umass-sim0:0:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to rea
dy change, medium may have changed)
Signed-off-by: Oliver Pinter oliver.p...@gmail.com
diff --git a/share/man/man4/u3g.4 b/share/man/man4/u3g.4
index 4df0b26..a2122cb 100644
--- a/share/man/man4/u3g.4
+++ b/share/man/man4/u3g.4
@@ -61,6 +61,8 @@ Option GT 3G, GT 3G Quad, etc.
.It
Vodafone Mobile Connect Card 3G
.It
+Vodafone Mobile Broadband K3772-Z
+.It
Qualcomm Inc. CDMA MSM
.It
Huawei B190, E180v, E220 ('Huawei Mobile')
diff --git a/sys/dev/usb/serial/u3g.c b/sys/dev/usb/serial/u3g.c
index e0b38bd..23b0f6c 100644
--- a/sys/dev/usb/serial/u3g.c
+++ b/sys/dev/usb/serial/u3g.c
@@ -422,6 +422,7 @@ static const STRUCT_USB_HOST_ID u3g_devs[] = {
U3G_DEV(QUALCOMMINC, SURFSTICK, 0),
U3G_DEV(QUALCOMMINC, E2002, 0),
U3G_DEV(QUALCOMMINC, E2003, 0),
+ U3G_DEV(QUALCOMMINC, K3772_Z, U3GINIT_SCSIEJECT),
U3G_DEV(QUALCOMMINC, MF626, 0),
U3G_DEV(QUALCOMMINC, MF628, 0),
U3G_DEV(QUALCOMMINC, MF633R, 0),
diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs
index c770043..bc990c8 100644
--- a/sys/dev/usb/usbdevs
+++ b/sys/dev/usb/usbdevs
@@ -2744,6 +2744,7 @@ product QUALCOMMINC E0078 0x0078 3G modem
product QUALCOMMINC E0082 0x0082 3G modem
product QUALCOMMINC E0086 0x0086 3G modem
product QUALCOMMINC SURFSTICK 0x0117 11 Surf Stick
+product QUALCOMMINC K3772_Z 0x1179 3G modem
product QUALCOMMINC ZTE_STOR 0x2000 USB ZTE Storage
product QUALCOMMINC E2002 0x2002 3G modem
product QUALCOMMINC E2003 0x2003 3G modem
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: mps module compilation issue on FreeBSD-9 amd64
-Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] On Behalf Of Desai, Kashyap Sent: Monday, January 30, 2012 2:45 PM To: freebsd-sta...@freebsd.org; freebsd-current@freebsd.org Cc: gi...@freebsd.org; Kenneth D. Merry; McConnell, Stephen Subject: mps module compilation issue on FreeBSD-9 amd64 Hi, I am seeing some uncommon problem while doing compilation of mps driver (this is a latest driver from LSI). Here are the steps I followed. CASE-1 1. remove mps directory from sys/dev and sys/module and overwrite those two directories with my latest code. 2. go to sys/module/mps and run make. [Things works fine.] CASE-2. 1. remove mps directory from sys/dev and sys/module and overwrite those two directories with my latest code. 2. go to main directory ( In my case it is /usr/trees/9.0.0) 3. Run below command make -j8 buildkernel KERNCONF=GENERIC MODULES_OVERRIDE=mps TARGET_ARCH=amd64 SYSDIR=/usr/trees/9.0.0/sys -DNO_CLEAN - DNO_KERNELCONFIG -DNO_KERNELCLEAN -DNO_KERNELDEPEND Here I am seeing mps.ko file is generated, but it is failing at linking kernel.debug steps. (this step is only seen in CASE-1). Typo: It should be this step is only seen in CASE-2. Also, I have first finished buildworld before I tried mps (LSI driver) compilation. Any Idea How to resolve this issue ? INFO: I am using FreeBSD-8.2-Release amd64.case-1 and case-2 both passes for i386. --- Compilation failure log for CASE-2 ld -d -warn-common -r -d -o mpslsi.ko.debug mps_pci.o mps.o mps_sas.o mps_table.o mps_user.o mps_config.o mps_mapping.o mps_sas_lsi.o : export_syms awk -f /usr/trees/9.0.0/sys/conf/kmod_syms.awk mpslsi.ko.debug export_syms | xargs -J% objcopy % mpslsi.ko.debug /usr/local/bin/svnversion objcopy --only-keep-debug mpslsi.ko.debug mpslsi.ko.symbols objcopy --strip-debug --add-gnu-debuglink=mpslsi.ko.symbols mpslsi.ko.debug mpslsi.ko cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g - Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing- prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer- sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show- option -nostdinc -I. -I/usr/trees/9.0.0/sys - I/usr/trees/9.0.0/sys/contrib/altq -D_KERNEL - DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline- limit=8000 --param inline-unit-growth=100 --param large-function- growth=1000 -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red- zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables - ffreestanding -fstack-protector -Werror vers.c linking kernel.debug mps.o: In function `mps_startup': /usr/trees/9.0.0/sys/dev/mps/mps.c:1249: undefined reference to `mps_mapping_initialize' mps.o: In function `mps_free': /usr/trees/9.0.0/sys/dev/mps/mps.c:1410: undefined reference to `mps_mapping_free_memory' mps.o: In function `mps_attach': /usr/trees/9.0.0/sys/dev/mps/mps.c:1204: undefined reference to `mps_base_static_config_pages' /usr/trees/9.0.0/sys/dev/mps/mps.c:1224: undefined reference to `mpssas_ir_shutdown' mps_sas.o: In function `mps_attach_sas': /usr/trees/9.0.0/sys/dev/mps/mps_sas.c:614: undefined reference to `mpssas_firmware_event_work' mps_sas.o: In function `mpssas_register_events': /usr/trees/9.0.0/sys/dev/mps/mps_sas.c:576: undefined reference to `mpssas_evt_handler' mps_sas.o: In function `mpssas_portenable_complete': /usr/trees/9.0.0/sys/dev/mps/mps_sas.c:3069: undefined reference to `mps_wd_config_pages' mps_user.o: In function `mps_user_btdh': /usr/trees/9.0.0/sys/dev/mps/mps_user.c:2038: undefined reference to `mps_mapping_get_sas_id_from_handle' mps_user.o: In function `mps_user_get_adapter_data': /usr/trees/9.0.0/sys/dev/mps/mps_user.c:1101: undefined reference to `mps_config_get_bios_pg3' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error Failed : make -j8 buildkernel KERNCONF=GENERIC MODULES_OVERRIDE=mps TARGET_ARCH=amd64 SYSDIR=/usr/trees/9.0.0/sys -DNO_CLEAN - DNO_KERNELCONFIG -DNO_KERNELCLEAN -DNO_KERNELDEPEND ___ freebsd-sta...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
mps module compilation issue on FreeBSD-9 amd64
Hi, I am seeing some uncommon problem while doing compilation of mps driver (this is a latest driver from LSI). Here are the steps I followed. CASE-1 1. remove mps directory from sys/dev and sys/module and overwrite those two directories with my latest code. 2. go to sys/module/mps and run make. [Things works fine.] CASE-2. 1. remove mps directory from sys/dev and sys/module and overwrite those two directories with my latest code. 2. go to main directory ( In my case it is /usr/trees/9.0.0) 3. Run below command make -j8 buildkernel KERNCONF=GENERIC MODULES_OVERRIDE=mps TARGET_ARCH=amd64 SYSDIR=/usr/trees/9.0.0/sys -DNO_CLEAN -DNO_KERNELCONFIG -DNO_KERNELCLEAN -DNO_KERNELDEPEND Here I am seeing mps.ko file is generated, but it is failing at linking kernel.debug steps. (this step is only seen in CASE-1). Any Idea How to resolve this issue ? INFO: I am using FreeBSD-8.2-Release amd64.case-1 and case-2 both passes for i386. --- Compilation failure log for CASE-2 ld -d -warn-common -r -d -o mpslsi.ko.debug mps_pci.o mps.o mps_sas.o mps_table.o mps_user.o mps_config.o mps_mapping.o mps_sas_lsi.o : export_syms awk -f /usr/trees/9.0.0/sys/conf/kmod_syms.awk mpslsi.ko.debug export_syms | xargs -J% objcopy % mpslsi.ko.debug /usr/local/bin/svnversion objcopy --only-keep-debug mpslsi.ko.debug mpslsi.ko.symbols objcopy --strip-debug --add-gnu-debuglink=mpslsi.ko.symbols mpslsi.ko.debug mpslsi.ko cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/trees/9.0.0/sys -I/usr/trees/9.0.0/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug mps.o: In function `mps_startup': /usr/trees/9.0.0/sys/dev/mps/mps.c:1249: undefined reference to `mps_mapping_initialize' mps.o: In function `mps_free': /usr/trees/9.0.0/sys/dev/mps/mps.c:1410: undefined reference to `mps_mapping_free_memory' mps.o: In function `mps_attach': /usr/trees/9.0.0/sys/dev/mps/mps.c:1204: undefined reference to `mps_base_static_config_pages' /usr/trees/9.0.0/sys/dev/mps/mps.c:1224: undefined reference to `mpssas_ir_shutdown' mps_sas.o: In function `mps_attach_sas': /usr/trees/9.0.0/sys/dev/mps/mps_sas.c:614: undefined reference to `mpssas_firmware_event_work' mps_sas.o: In function `mpssas_register_events': /usr/trees/9.0.0/sys/dev/mps/mps_sas.c:576: undefined reference to `mpssas_evt_handler' mps_sas.o: In function `mpssas_portenable_complete': /usr/trees/9.0.0/sys/dev/mps/mps_sas.c:3069: undefined reference to `mps_wd_config_pages' mps_user.o: In function `mps_user_btdh': /usr/trees/9.0.0/sys/dev/mps/mps_user.c:2038: undefined reference to `mps_mapping_get_sas_id_from_handle' mps_user.o: In function `mps_user_get_adapter_data': /usr/trees/9.0.0/sys/dev/mps/mps_user.c:1101: undefined reference to `mps_config_get_bios_pg3' *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error Failed : make -j8 buildkernel KERNCONF=GENERIC MODULES_OVERRIDE=mps TARGET_ARCH=amd64 SYSDIR=/usr/trees/9.0.0/sys -DNO_CLEAN -DNO_KERNELCONFIG -DNO_KERNELCLEAN -DNO_KERNELDEPEND ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Improving the FreeBSD-9 boot menu
On 21 September 2011 05:46, Warren Block wbl...@wonkity.com wrote: The patch in PR 160818 makes some clarifications and improvements to the new boot menu. Obviously this is not for 9.0-RELEASE, just wanting to get it out there so people can look at it. http://www.freebsd.org/cgi/query-pr.cgi?pr=160818 I just committed it to head and will merge it to stable/9 in 1 week. Thanks! -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Improving the FreeBSD-9 boot menu
On Tue, 20 Sep 2011, Warren Block wrote: The patch in PR 160818 makes some clarifications and improvements to the new boot menu. Obviously this is not for 9.0-RELEASE, just wanting to get it out there so people can look at it. http://www.freebsd.org/cgi/query-pr.cgi?pr=160818 Among other things, the patch removes the word boot from options that don't actually boot. The options are lined up, and enabled options are drawn in reverse video when loader_color=1 is set in /boot/loader.conf. Just reminding people about this now that 9.0 is out. It makes what I feel are genuine usability and readability improvements to the boot menu. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Improving the FreeBSD-9 boot menu
On 20-01-2012 7:57, Warren Block wrote: On Tue, 20 Sep 2011, Warren Block wrote: The patch in PR 160818 makes some clarifications and improvements to the new boot menu. Obviously this is not for 9.0-RELEASE, just wanting to get it out there so people can look at it. http://www.freebsd.org/cgi/query-pr.cgi?pr=160818 Among other things, the patch removes the word boot from options that don't actually boot. The options are lined up, and enabled options are drawn in reverse video when loader_color=1 is set in /boot/loader.conf. Just reminding people about this now that 9.0 is out. It makes what I feel are genuine usability and readability improvements to the boot menu. I agree. Definitely an improvement. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Improving the FreeBSD-9 boot menu
On Fri, Jan 20, 2012 at 11:38 AM, Joel Dahl j...@vnode.se wrote: On 20-01-2012 7:57, Warren Block wrote: On Tue, 20 Sep 2011, Warren Block wrote: The patch in PR 160818 makes some clarifications and improvements to the new boot menu. Obviously this is not for 9.0-RELEASE, just wanting to get it out there so people can look at it. http://www.freebsd.org/cgi/query-pr.cgi?pr=160818 Among other things, the patch removes the word boot from options that don't actually boot. The options are lined up, and enabled options are drawn in reverse video when loader_color=1 is set in /boot/loader.conf. Just reminding people about this now that 9.0 is out. It makes what I feel are genuine usability and readability improvements to the boot menu. I agree. Definitely an improvement. Is this in the release notes? -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9 recompile ports
George Kontostanos wrote: Greetings all and my apologies for cross posting! There seems to be a confusion regarding the ABI change in FreeBSD 9 and if this affects the usual upgrade path which includes a full port rebuild. The relevant post is here: http://forums.freebsd.org/showthread.php?t=28831 Frankly, I am also confused because I remember a relevant discussion a few months ago in the lists. Traditionally a major RELEASE upgrade requires a full ports rebuild, however this time there is no COMPAT_FREEBSD8 in GENERIC and most upgraded systems seem to be working fine. On the other hand this is stated in UPDATING: 20110828: Bump the shared library version numbers for libraries that do not use symbol versioning, have changed the ABI compared to stable/8 and which shared library version was not bumped. Done as part of 9.0-RELEASE cycle. Your input would be appreciated! Why can't it be that only shared libraries should be bumped, but no kernel incompatible changes were introduced? -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9 recompile ports
On 01/13/2012 02:06, Volodymyr Kostyrko wrote: Why can't it be that only shared libraries should be bumped, but no kernel incompatible changes were introduced? Because one of the reasons we have major branches is so that we can change the various API/KPI/etc. in the newer branch. Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9 recompile ports
on 13/01/2012 12:19 Doug Barton said the following: On 01/13/2012 02:06, Volodymyr Kostyrko wrote: Why can't it be that only shared libraries should be bumped, but no kernel incompatible changes were introduced? Because one of the reasons we have major branches is so that we can change the various API/KPI/etc. in the newer branch. Are you saying that every major branch _has_ to introduce incompatibilities into a at least one system call? Otherwise, you are answering a question different from what Volodymyr asked :) -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9 recompile ports
On Fri, Jan 13, 2012 at 2:34 PM, Johan Hendriks joh.hendr...@gmail.com wrote: George Kontostanos schreef: On Fri, Jan 13, 2012 at 12:55 PM, Andriy Gapona...@freebsd.org wrote: on 13/01/2012 11:59 Doug Barton said the following: On 01/13/2012 01:52, George Kontostanos wrote: On Thu, Jan 12, 2012 at 8:42 PM, George Kontostanos gkontos.m...@gmail.com wrote: Greetings all and my apologies for cross posting! There seems to be a confusion regarding the ABI change in FreeBSD 9 and if this affects the usual upgrade path which includes a full port rebuild. The relevant post is here: http://forums.freebsd.org/showthread.php?t=28831 Frankly, I am also confused because I remember a relevant discussion a few months ago in the lists. Traditionally a major RELEASE upgrade requires a full ports rebuild, however this time there is no COMPAT_FREEBSD8 in GENERIC and most upgraded systems seem to be working fine. On the other hand this is stated in UPDATING: 20110828: Bump the shared library version numbers for libraries that do not use symbol versioning, have changed the ABI compared to stable/8 and which shared library version was not bumped. Done as part of 9.0-RELEASE cycle. Your input would be appreciated! Hmm, anyone :) ? If your question is, Do I need to rebuild my ports when doing a major OS version upgrade? the answer is always Yes. The method described at the end of the portmaster man page is preferred, whether you actually use portmaster to do the upgrade or not. (I.e., good backups, delete everything, start over from scratch.) I think that another part of the question was why there is no COMPAT_FREEBSD8 kernel option in 9? and I think that Volodymyr has tried to answer this part with another question. -- Andriy Gapon Hi guys, I am aware of the proper procedure which requires a full rebuild after a major upgrade. Doug, the question had to to with COMPAT_FREEBSD8 missing from GENERIC. It seems this and the fact that some upgrades from 8.2-STABLE worked fine without a recompile, has created the confusion. Did he do make delete-old-libs, if you leave them, then no recompile is needed, and the ports still have there old libs laying around.! If you do the make delete-old-libs command, your ports do not work anymore. regards Johan Hendriks Very good point! Still the question remains regarding COMPAT_FREEBSD8 and how does this affects ports/misc/compat8x/ Cheers -- George Kontostanos Aicom telecoms ltd http://www.aisecure.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9 recompile ports
on 13/01/2012 14:57 George Kontostanos said the following: Still the question remains regarding COMPAT_FREEBSD8 and how does this affects ports/misc/compat8x/ Looks like all the previous hints have not been clear enough. There is no direct relation between COMPAT_FREEBSD8 and misc/compat8x. COMPAT_FREEBSDX options are only needed when going from release X to release X+1 there was a change to an existing system call at the kernel-userland boundary. A side note: kernel options affect only what's in the kernel, quite obviously. misc/compatXx contains versions of shared libraries from release X that are no longer present in X+1. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9 recompile ports
On Fri, Jan 13, 2012 at 04:11:22PM +0200, Andriy Gapon wrote: on 13/01/2012 14:57 George Kontostanos said the following: Still the question remains regarding COMPAT_FREEBSD8 and how does this affects ports/misc/compat8x/ Looks like all the previous hints have not been clear enough. There is no direct relation between COMPAT_FREEBSD8 and misc/compat8x. COMPAT_FREEBSDX options are only needed when going from release X to release X+1 there was a change to an existing system call at the kernel-userland boundary. A side note: kernel options affect only what's in the kernel, quite obviously. misc/compatXx contains versions of shared libraries from release X that are no longer present in X+1. Additional twist is that not every change at the kernel/usermode boundary is covered with backward-compatibility shims. Recent example is the CAM ABI change, which makes libcam.so.5 from the compat8x useless. pgpuaqFjafo46.pgp Description: PGP signature
Re: FreeBSD 9 recompile ports
On Fri, Jan 13, 2012 at 4:18 PM, Kostik Belousov kostik...@gmail.com wrote: On Fri, Jan 13, 2012 at 04:11:22PM +0200, Andriy Gapon wrote: on 13/01/2012 14:57 George Kontostanos said the following: Still the question remains regarding COMPAT_FREEBSD8 and how does this affects ports/misc/compat8x/ Looks like all the previous hints have not been clear enough. There is no direct relation between COMPAT_FREEBSD8 and misc/compat8x. COMPAT_FREEBSDX options are only needed when going from release X to release X+1 there was a change to an existing system call at the kernel-userland boundary. A side note: kernel options affect only what's in the kernel, quite obviously. misc/compatXx contains versions of shared libraries from release X that are no longer present in X+1. Additional twist is that not every change at the kernel/usermode boundary is covered with backward-compatibility shims. Recent example is the CAM ABI change, which makes libcam.so.5 from the compat8x useless. Thanks to all for your input. It looks quite obvious to me know and I think this clears any further confusion. Best Regards, George ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FreeBSD 9 recompile ports
Greetings all and my apologies for cross posting! There seems to be a confusion regarding the ABI change in FreeBSD 9 and if this affects the usual upgrade path which includes a full port rebuild. The relevant post is here: http://forums.freebsd.org/showthread.php?t=28831 Frankly, I am also confused because I remember a relevant discussion a few months ago in the lists. Traditionally a major RELEASE upgrade requires a full ports rebuild, however this time there is no COMPAT_FREEBSD8 in GENERIC and most upgraded systems seem to be working fine. On the other hand this is stated in UPDATING: 20110828: Bump the shared library version numbers for libraries that do not use symbol versioning, have changed the ABI compared to stable/8 and which shared library version was not bumped. Done as part of 9.0-RELEASE cycle. Your input would be appreciated! Regards, -- George Kontostanos Aicom telecoms ltd ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Is there a FreeBSD 9+ version of this?
http://www.freebsd.org/doc/handbook/geom-mirror.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Is there a FreeBSD 9+ version of this?
On Tue, 6 Dec 2011, Sean Bruno wrote: http://www.freebsd.org/doc/handbook/geom-mirror.html Not in the Handbook. To make gmirror work with GPT, create GPT partitions and mirror those. I wrote an article on that using multiple partitions: http://www.wonkity.com/~wblock/docs/html/gmirror.html However, it's since been pointed out that rebuilding the mirror could suffer from head contention. Using a single GPT partition over the whole drive should not have that problem, but I haven't tested either way. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ahci in FreeBSD 9
On Fri, 2 Dec 2011 16:22:10 +1100 Greg 'groggy' Lehey g...@freebsd.org wrote: On Friday, 2 December 2011 at 1:50:19 +0100, Gary Jennejohn wrote: On Thu, 1 Dec 2011 21:31:18 +0200 George Kontostanos gkontos.m...@gmail.com wrote: Does this mean that loading ahci in loader.conf is useless ? No, I load mine from there. It's not necessary to have device ahci in your kernel config file since the module will be generated and installed by default. JOOI, why? Habit. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ahci in FreeBSD 9
Hi everyone, From my understanding as of 20110424 revision device ahci has been integrated into kernel: It is possible to load devices ahci, ata, siis and mvs as modules, but option ATA_CAM should remain in kernel configuration to make ata module work as CAM driver supporting legacy ATA controllers. Device ata still can be used in modular fashion ... No kernel config options or code have been removed, so if a problem arises, please report it and optionally revert to the old ATA stack. In order to do it you can remove from the kernel config: optionsATA_CAM device ahci Does this mean that loading ahci in loader.conf is useless ? Thanks -- George Kontostanos Aicom telecoms ltd http://www.barebsd.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ahci in FreeBSD 9
On Thu, 1 Dec 2011 21:31:18 +0200 George Kontostanos gkontos.m...@gmail.com wrote: Hi everyone, From my understanding as of 20110424 revision device ahci has been integrated into kernel: It is possible to load devices ahci, ata, siis and mvs as modules, but option ATA_CAM should remain in kernel configuration to make ata module work as CAM driver supporting legacy ATA controllers. Device ata still can be used in modular fashion ... No kernel config options or code have been removed, so if a problem arises, please report it and optionally revert to the old ATA stack. In order to do it you can remove from the kernel config: optionsATA_CAM device ahci Does this mean that loading ahci in loader.conf is useless ? No, I load mine from there. It's not necessary to have device ahci in your kernel config file since the module will be generated and installed by default. This is what I have makeoptions MODULES_OVERRIDE=ahci linux linprocfs msdosfs pseudofs ... #device ahci so it's obvious that I'm using only the module. -- Gary Jennejohn ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
multimedia/vlc: no graphical interface on FreeBSD 9 and 10
Since a while, vlc on my FreeBSD 10 and FreeBSD 9 boxes do not show a graphical interface anymore. Compiling multimedia/vlc works, either with the legacy gcc or clang. But either way I compile vlc, the result is always the same: no GUI. Instead, I receive the below show message: VLC media player 1.1.12 The Luggage (revision exported) Blocked: call to unsetenv(DBUS_ACTIVATION_ADDRESS) Blocked: call to unsetenv(DBUS_ACTIVATION_BUS_TYPE) [0x802080a70] main interface error: no suitable interface module [0x8020691b0] main libvlc error: interface globalhotkeys,none initialization failed [0x8020691b0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [0x802080a70] main interface error: option qt-volume-complete does not exist [0x802080a70] skins2 interface error: no suitable dialogs provider found (hint: compile the qt4 plugin, and make sure it is loaded properly) [0x802080a70] skins2 interface error: cannot instanciate qt4 dialogs provider I tried several times to recompile everything vlc depends on, but with not success. I also tried to delete every configuration file vlc created in the past and my now suffer from legzy options, but that hadn't any effect - as far as I could catch each config file. Is anybody out here having had the same or similar problem and solved it? Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: multimedia/vlc: no graphical interface on FreeBSD 9 and 10
On Sun, Nov 27, 2011 at 7:40 AM, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Since a while, vlc on my FreeBSD 10 and FreeBSD 9 boxes do not show a graphical interface anymore. Compiling multimedia/vlc works, either with the legacy gcc or clang. But either way I compile vlc, the result is always the same: no GUI. Instead, I receive the below show message: That means one or more plugins crashed the system. vlc is lowsy when it comes to diagnostic messages and it isn't overly apparent what the root cause is when running ldd because it dl_open's a bunch of libraries. Try running vlc -vv or ktrace'ing the binary. Cheers, -Garrett PS Please don't cross-post. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
Thank you! I see this fix in 9 STABLE.
Works)
2011/11/8 John Baldwin j...@freebsd.org:
On Tuesday, November 08, 2011 2:10:51 pm Pavel Timofeev wrote:
FreeBSD accessor 9.0-RC2 FreeBSD 9.0-RC2 #0: Tue Nov 8 20:52:11 MSK
2011 mox@accessor:/usr/obj/usr/src/sys/GENERIC amd64
RC2 is coming. Nothing changed.
Sorry, haven't been able to merge them to 9 yet.
2011/10/25 John Baldwin j...@freebsd.org:
On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote:
On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
I'd like to test these patches on my Supermicro machine as well.
Unfortunately, I don't know how to go about it, but I'm hopeful to be able
to
figure it out with some basic instructions. I'm currently running a fresh
RC1
install, and I'm able to boot the system if I set the BIOS to IDE mode,
rather
than AHCI.
Any help would be much appreciated,
I just committed them to HEAD (226748 along with a cleanup in 226746).
They
should backport to 9.
--
John Baldwin
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Proftpd + Freebsd 9 + mod_mysql
Not sure if anyone else is having problem with proftpd on freebsd 9, but here is a patch to stop it terminating, should be included in next release, courtesy of TJ saunders working with me on it. Dan. -- Dan The Man CTO/ Senior System Administrator Websites, Domains and Everything else http://www.SunSaturn.com Email: d...@sunsaturn.com freebsd-mysql-signal.patch Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
FreeBSD accessor 9.0-RC2 FreeBSD 9.0-RC2 #0: Tue Nov 8 20:52:11 MSK
2011 mox@accessor:/usr/obj/usr/src/sys/GENERIC amd64
RC2 is coming. Nothing changed.
2011/10/25 John Baldwin j...@freebsd.org:
On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote:
On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
I'd like to test these patches on my Supermicro machine as well.
Unfortunately, I don't know how to go about it, but I'm hopeful to be able to
figure it out with some basic instructions. I'm currently running a fresh RC1
install, and I'm able to boot the system if I set the BIOS to IDE mode, rather
than AHCI.
Any help would be much appreciated,
I just committed them to HEAD (226748 along with a cleanup in 226746). They
should backport to 9.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Tuesday, November 08, 2011 2:10:51 pm Pavel Timofeev wrote:
FreeBSD accessor 9.0-RC2 FreeBSD 9.0-RC2 #0: Tue Nov 8 20:52:11 MSK
2011 mox@accessor:/usr/obj/usr/src/sys/GENERIC amd64
RC2 is coming. Nothing changed.
Sorry, haven't been able to merge them to 9 yet.
2011/10/25 John Baldwin j...@freebsd.org:
On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote:
On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
I'd like to test these patches on my Supermicro machine as well.
Unfortunately, I don't know how to go about it, but I'm hopeful to be able
to
figure it out with some basic instructions. I'm currently running a fresh
RC1
install, and I'm able to boot the system if I set the BIOS to IDE mode,
rather
than AHCI.
Any help would be much appreciated,
I just committed them to HEAD (226748 along with a cleanup in 226746). They
should backport to 9.
--
John Baldwin
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
Le 30.10.2011 01:31, Daniel O'Connor a écrit : On 30/10/2011, at 24:40, David Marec wrote: But, now running FreeBSD 9, I get new usb/devd behavior issues. First, the ulpt module is always loaded. Is there any elegant way to get rid of this 'self loading' behavior, except to remove it from /boot/modules ? Anyway, it sounds like HPLIP is now working with the ulpt module loaded. I'm not sure what would load it automatically - it may be built into the kernel though. Anyway, as you say it should work with ulpt loaded anyway. I'm quite sure it was not; I mean, if ulpt.ko has been manually removed from /boot/modules, this module is not loaded when I plugged in the printer. And, how to handle them with devd ? I have a similar problem.. [ ATTACH statement in devd.conf] However this doesn't seem to work anymore, it certainly used to.. :( Yep, sounds like it is the same here. I tried adding the system, subsystem type parts and changing device-name to cdev but no luck.. I also tried to add entries into /usr/local/etc/devd/devd.conf instead of /etc/devd.conf. And some more unsuccessful attempts, like changing system/subsystem and others, as you did. -- David Marec, mailto:david.ma...@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
Le 29.10.2011 21:58, Jilles Tjoelker a écrit :
On Sat, Oct 29, 2011 at 04:10:46PM +0200, David Marec wrote:
So, what's should be the news groupuser's rights required by HPLIP/cups
on FreeBSD 9 ?
And, how to handle them with devd ?
Use devfs rules.
Doing this, device rights become unreliable.
[devfsrules_mybox=10]
add path 'fd0*' mode 660
What are the user rights that the devfs interface should set ?
mode 0666 for all usb entries ('usb*') ?
- ugen stands for generic usb support. -
Setting 'cups:hplip' rights for 'ugen[0-9]' doesn't do the trick
anymore: HPlip needs the suitable rights on 'usb/x.y.*' too, which are
now targeted by the ugenx.y links.
--
David Marec, mailto:david.ma...@davenulle.org
http://user.lamaiziere.net/david/Site
http://www.diablotins.org/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
It would be nice, If somebody would write updated manual documenting whole process of setting up hplip. In past, I could only get it to the point of printing test pages (sigh...) Before release preferably? -- View this message in context: http://freebsd.1045724.n5.nabble.com/Freebsd-9-amd64-USB-HPLIP-what-s-the-new-right-way-to-manage-hplip-usb-plugged-printers-running-Free9-tp4948737p4949780.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
Or just extend hplip section in handbook. http://www.freebsd.org/doc/handbook/printing-lpd-alternatives.html It could be roughly based upon this: http://freebsd.kde.org/howtos/hplip.php -- View this message in context: http://freebsd.1045724.n5.nabble.com/Freebsd-9-amd64-USB-HPLIP-what-s-the-new-right-way-to-manage-hplip-usb-plugged-printers-running-Free9-tp4948737p4949796.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
Le 30.10.2011 10:04, Jakub Lach a écrit : Or just extend hplip section in handbook. http://www.freebsd.org/doc/handbook/printing-lpd-alternatives.html It should be a good idea, I agree. Especially in this case, where nobody now knows how and where HPLIP rights have to be settled. It could be roughly based upon this: http://freebsd.kde.org/howtos/hplip.php This one is really outdated. It seems that `hpiod` and `hpssd` are not useful in any way, and, mostly, the use of devfs stands for :setting rights for everyone (or close to) on USB system. -- Et je vais rater ma béarnaise si je continue à répondre. http://user.lamaiziere.net/david/Site http://www.diablotins.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
Le 30.10.2011 08:28, David Marec a écrit :
I have a similar problem..
Le 30.10.2011 08:28, David Marec a écrit :
I have a similar problem..
A new behavior occurs since I updated the world kernel this morning.
`devd` now executes the entry for hplip, as I defined it inside
/usr/local/etc/devd/devd.conf.
But, with `ulpt0` forwarded as device node.
That sounds ok since ulpt has been loaded and attached by devd (or some
other stuff, i dont know);
What comes now as the major issue.
hold it... since the update, ulpt keeps on being quiet while the printer
gets plugged..
So, I changed my script to:
#!/bin/sh
#
# set up /dev/$1.$2.* to cups:hplip -rw-rw---
#
logger HPLIP printer found on $1.$2
logger setting suitable rights for $1.$2
/usr/sbin/chown cups:hplip /dev/usb/$1.$2.[0-9]
/bin/chmod g+rw /dev/usb/$1.$2.[0-9]
...and used the nomatch key instead of the attach key into
/usr/local/etc/devd/devd.conf
nomatch 100 {
match vendor 0x03f0;
match product 0x4712;
action /root/sbin/ugen-hdle $port $devaddr;
};
'looks like it works .
--
David Marec, mailto:david.ma...@davenulle.org
http://user.lamaiziere.net/david/Site
http://www.diablotins.org/
A new behavior occurs since i update the world kernel this morning.
`devd` now executes the entry for hplip, as I defined it inside
/usr/local/etc/devd/devd.conf.
But, with `ulpt0` forwarded as device node.
That sounds ok since ulpt has been loaded and attached by devd (or some
other stuff, i dont know);
What comes now as the major issue.
And, up to now, ulpt keep on being stuck.
So, i change my script to
#!/bin/sh
#
# set up /dev/$1.$2.* to cups:hplip -rw-rw---
#
logger HPLIP printer found on $1.$2
logger setting suitable rights for $1.$2
/usr/sbin/chown cups:hplip /dev/usb/$1.$2.[0-9]
/bin/chmod g+rw /dev/usb/$1.$2.[0-9]
And uses nomatch instead of attach into /usr/local/etc/devd/devd.conf
nomatch 100 {
match vendor 0x03f0;
match product 0x4712;
action /root/sbin/ugen-hdle $port $devaddr;
};
seems to work finally.
--
Délicieuse cette béarnaise.
http://user.lamaiziere.net/david/Site
http://www.diablotins.org/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
On Sunday 30 October 2011 01:31:21 Daniel O'Connor wrote: I'm not sure what would load it automatically - it may be built into the kernel though. Anyway, as you say it should work with ulpt loaded anyway. Hi, ulpt is autoloaded by /etc/devd/usb.conf --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
Hi list,
While I was running Freebsd 8, I used to set the suitable rights for my
hplip printer, plugged via usb, in this way:
* ulpt removed from the kernel.
* scripting /etc/devd.conf, to catch usb printers events, as follows:
attach 10 {
#device-name ugen[0-9]+;
match vendor 0x03f0;
match product 0x4712;
#action logger Chalut la foule;
action /root/sbin/ugen-hdle $device-name;
};
with
david:~less /root/sbin/ugen-hdle
#!/bin/sh
echo Printer detected on $1
dev=`echo $1 | /usr/bin/awk 'BEGIN { } { s = substr($0, 5, 99); } END {
print s; }'`
#
echo setting suitable rights for $dev
/usr/sbin/chown cups:hplip /dev/usb/$dev.[0-9]
/bin/chmod g+rw /dev/usb/$dev.[0-9]
But, now running FreeBSD 9, I get new usb/devd behavior issues.
First, the ulpt module is always loaded. Is there any elegant way to get
rid of this 'self loading' behavior, except to remove it from
/boot/modules ?
Anyway, it sounds like HPLIP is now working with the ulpt module loaded.
But, devd never sets the suitable rights on ugen.
Moreover, switching to the 'action' that only logs something, reveals
that devd never executes this entry.
So, what's should be the news groupuser's rights required by HPLIP/cups
on FreeBSD 9 ?
And, how to handle them with devd ?
However, there is a new devd directory inside of /etc.
Is there new usbdevd procedures for FreeBSD9 ?
[fu2 freebsd-...@freebsd.org]
regards
--
David Marec, mailto:david.ma...@davenulle.org
http://user.lamaiziere.net/david/Site
http://www.diablotins.org/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
On Sat, Oct 29, 2011 at 04:10:46PM +0200, David Marec wrote: So, what's should be the news groupuser's rights required by HPLIP/cups on FreeBSD 9 ? And, how to handle them with devd ? Use devfs rules. Pasting from http://www.stack.nl/~jilles/unix/freebsd-devfs.txt Create or edit /etc/devfs.rules and put something like this in it: [devfsrules_mybox=10] add path 'fd0*' mode 660 See man 8 devfs for more information. Then put in /etc/rc.conf devfs_system_ruleset=devfsrules_mybox If you want to edit other /dev mountpoints (e.g. for jails) use something like devfs_set_rulesets=/usr/jails/jail1/dev=devfsrules_jail1 /usr/jails/jail2/dev=devfsrules_jail2 -- Jilles Tjoelker ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
Le Sat, 29 Oct 2011 21:58:53 +0200, Jilles Tjoelker jil...@stack.nl a écrit : On Sat, Oct 29, 2011 at 04:10:46PM +0200, David Marec wrote: So, what's should be the news groupuser's rights required by HPLIP/cups on FreeBSD 9 ? And, how to handle them with devd ? Use devfs rules. Pasting from http://www.stack.nl/~jilles/unix/freebsd-devfs.txt Create or edit /etc/devfs.rules and put something like this in it: [devfsrules_mybox=10] add path 'fd0*' mode 660 The problem is that the printer appears as ugenXXX.Y, but other usb devices (disk, usb-key, ...) also have an entry in /dev/ugen/ You really don't want to allow the users to access these devices, but *only* the printer. This is why we use a devd rule that test the type of the device. I don't think we can do this with devfs. And the ugen number differs if the usb port is not always the same. Regards. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [Freebsd 9] [amd64] [USB] [HPLIP] what's the (new) right way to manage hplip usb-plugged printers, running Freebsd 9
On 30/10/2011, at 24:40, David Marec wrote:
But, now running FreeBSD 9, I get new usb/devd behavior issues.
First, the ulpt module is always loaded. Is there any elegant way to get rid
of this 'self loading' behavior, except to remove it from /boot/modules ?
Anyway, it sounds like HPLIP is now working with the ulpt module loaded.
I'm not sure what would load it automatically - it may be built into the kernel
though. Anyway, as you say it should work with ulpt loaded anyway.
But, devd never sets the suitable rights on ugen.
Moreover, switching to the 'action' that only logs something, reveals that
devd never executes this entry.
So, what's should be the news groupuser's rights required by HPLIP/cups on
FreeBSD 9 ?
And, how to handle them with devd ?
I have a similar problem..
Looking at /etc/devd/uath.conf I see..
notify 100 {
match system USB;
match subsystem DEVICE;
match typeATTACH;
match vendor 0x168c;
match product 0x0002;
action /usr/sbin/uathload -d /dev/$cdev;
};
Also, I have devd entries for NUT (UPS software) which look like so..
attach 100 {
match vendor 0x0463;
match product 0x;
action chown :uucp /dev/$device-name; chmod 660 /dev/$device-name;
};
However this doesn't seem to work anymore, it certainly used to.. :(
I tried adding the system, subsystem type parts and changing device-name to
cdev but no luck..
I ran devd -Dd and checked the output but while it says it parses nut.conf it
doesn't seem to match the entries.
devd output looks like so..
Processing event '!system=USB subsystem=DEVICE type=ATTACH ugen=ugen1.3
cdev=ugen1.3 vendor=0x046
3 product=0x devclass=0x00 devsubclass=0x00 sernum=0
release=0x4241 mode=host port=
3 parent=ugen1.1'
Pushing table
setting system=USB
setting subsystem=DEVICE
setting type=ATTACH
setting ugen=ugen1.3
setting cdev=ugen1.3
setting vendor=0x0463
setting product=0x
setting devclass=0x00
setting devsubclass=0x00
setting sernum=0
setting release=0x4241
setting mode=host
setting port=3
setting parent=ugen1.1
Processing notify event
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
2011/10/24 Dimitry Andric d...@freebsd.org On 2011-10-23 21:56, Dennis Koegel wrote: On Sun, Oct 23, 2011 at 08:57:59PM +0300, Andriy Gapon wrote: I found a document that suggests a possibility of BIOS writing more bytes to the array than its current size of 0x42: [...] Could you please test this hypothesis by trying the following patch? With -O1 and this patch, it boots. Thank you! If you have some time, can you also re-check the other cases you listed before? E.g.: gcc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time \ -mno-align-long-strings -mrtd [from before r225530]: gcc -Os -mrtd: gcc -O1 -mrtd: gcc -O1: gcc -O0: gcc -Os: clang -O1: clang -Os: clang -Oz: My 5 cents: tested on my HP Proliant DL360 G5 with Andriy's patch clang -O1: ok (VirtualBox with ahci boots too) clang -Os: ok clang -Oz: ok Thanks. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
on 24/10/2011 21:23 John Baldwin said the following: On Monday, October 24, 2011 12:25:09 pm Andriy Gapon wrote: Also, perhaps edd_params_v3 and edd_params_v4 should inherit edd_params in some smarter way to avoid verbatim duplicates. Yeah, probably so. We will probably never even use them anyway (just as we don't use edd_packet_v3 even though we could probably make use of it to avoid some bounce buffering in the loader). Other than these issues the patch looks great! Perhaps later we could do detailed definitions for things like interface paths for various cases, etc. I doubt we will ever use them. In theory we could pass that information from loader to kernel, so that in a booted system we could try to build a mapping between kernel disks and bios disks, with the boot disk potentially being of the most interest. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Monday, October 24, 2011 7:21:27 pm Gunnar Schaefer wrote:
On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
I'd like to test these patches on my Supermicro machine as well.
Unfortunately, I don't know how to go about it, but I'm hopeful to be able to
figure it out with some basic instructions. I'm currently running a fresh RC1
install, and I'm able to boot the system if I set the BIOS to IDE mode, rather
than AHCI.
Any help would be much appreciated,
I just committed them to HEAD (226748 along with a cleanup in 226746). They
should backport to 9.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Friday, October 21, 2011 5:37:16 pm Andriy Gapon wrote: on 22/10/2011 00:27 Andriy Gapon said the following: on 21/10/2011 23:33 John Baldwin said the following: On Friday, October 21, 2011 4:58:51 am Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. Working offline with Dennis, we found that changing the CFLAGS in sys/boot/i386/gptboot/Makefile from -O1 to -Os -mrtd (partially reverting an earlier commit) fixed gptboot. The next test for someone to do would be to try just adding -mrtd and leaving -O1 as-is to see if that fixes it. Hmm, this is quite unexpected... Do you have a hypothesis why not using -mrtd could cause a problem (a miscompilation?) ? I've just got one: maybe the trouble is caused by the sio_putc procedure in sys/boot/i386/btx/btx/btx.S. It seems to be the only place in the boot code where 'ret number' instruction is explicitly used. A litmus question: do those experiencing the trouble all have BTX_SERIAL defined? No, they all have an HP machine. P.S. BTW, is BTX_SERIAL documented anywhere? It is not, and I strongly doubt anyone has it enabled. You can't use it with boot2 for example due to size bloat. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote:
on 23/10/2011 18:27 Dennis Koegel said the following:
On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote:
Working offline with Dennis, we found that changing the CFLAGS in
sys/boot/i386/gptboot/Makefile from -O1 to -Os -mrtd (partially
reverting
an earlier commit) fixed gptboot. The next test for someone to do would
be to
try just adding -mrtd and leaving -O1 as-is to see if that fixes it.
More test results:
gcc -Os -fno-guess-branch-probability -fomit-frame-pointer
-fno-unit-at-a-time \
-mno-align-long-strings -mrtd [from before r225530]: Boots OK
gcc -Os -mrtd: Boots OK
gcc -O1 -mrtd: Fails
gcc -O1: Fails
gcc -O0: Fails
gcc -Os: Boots OK
clang -O1: Fails
clang -Os: Fails
clang -Oz: Fails
I've put some printf()s into gpt{,boot}.c to trace where the reboot is
triggered. It appears to be in drvsize() (called from gptread()). OTOH
the debug output may have changed where the problem occurs, I don't
know about that.
With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure
out what happens. But as for why gcc's magic -Os is required and clang's
output doesn't work at all, I'm clueless.
Thank you for your very valuable analysis!
I looked at a difference in assembly code of the drvsize function produced by
gcc -Os and by gcc -O1. One thing that was immediately obvious is that gcc
places the params array and the sectors variable in a different order for
different options. One idea is that if BIOS actually writes beyond the end of
the array, then in one case it could be harmless (overwrites the sector
variable), but in the other case it could be more harmful.
I found a document that suggests a possibility of BIOS writing more bytes to
the
array than its current size of 0x42:
http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf
Of course, the size of the array is passed to BIOS at the start of the array
and
so a _non-buggy_ BIOS should not write beyond the array, but we live in a
non-perfect world.
Hmm, I think we've had to do a similar workaround in the past for a different
BIOS call (SMAP maybe?). However, I do have one request, can we declare an
actual structure instead of a silly char array? Then we can remove the weird
casts with offsets into it, etc. Having an actual struct would be far more
readable and less bug-prone.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
on 24/10/2011 16:41 John Baldwin said the following:
On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote:
on 23/10/2011 18:27 Dennis Koegel said the following:
On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote:
Working offline with Dennis, we found that changing the CFLAGS in
sys/boot/i386/gptboot/Makefile from -O1 to -Os -mrtd (partially
reverting
an earlier commit) fixed gptboot. The next test for someone to do would
be to
try just adding -mrtd and leaving -O1 as-is to see if that fixes it.
More test results:
gcc -Os -fno-guess-branch-probability -fomit-frame-pointer
-fno-unit-at-a-time \
-mno-align-long-strings -mrtd [from before r225530]: Boots OK
gcc -Os -mrtd: Boots OK
gcc -O1 -mrtd: Fails
gcc -O1: Fails
gcc -O0: Fails
gcc -Os: Boots OK
clang -O1: Fails
clang -Os: Fails
clang -Oz: Fails
I've put some printf()s into gpt{,boot}.c to trace where the reboot is
triggered. It appears to be in drvsize() (called from gptread()). OTOH
the debug output may have changed where the problem occurs, I don't
know about that.
With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure
out what happens. But as for why gcc's magic -Os is required and clang's
output doesn't work at all, I'm clueless.
Thank you for your very valuable analysis!
I looked at a difference in assembly code of the drvsize function produced by
gcc -Os and by gcc -O1. One thing that was immediately obvious is that gcc
places the params array and the sectors variable in a different order for
different options. One idea is that if BIOS actually writes beyond the end
of
the array, then in one case it could be harmless (overwrites the sector
variable), but in the other case it could be more harmful.
I found a document that suggests a possibility of BIOS writing more bytes to
the
array than its current size of 0x42:
http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf
Of course, the size of the array is passed to BIOS at the start of the array
and
so a _non-buggy_ BIOS should not write beyond the array, but we live in a
non-perfect world.
Hmm, I think we've had to do a similar workaround in the past for a different
BIOS call (SMAP maybe?). However, I do have one request, can we declare an
actual structure instead of a silly char array? Then we can remove the weird
casts with offsets into it, etc. Having an actual struct would be far more
readable and less bug-prone.
I am all for this.
Unfortunately. ENOTIME to do this properly at the moment.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Monday, October 24, 2011 9:47:42 am Andriy Gapon wrote:
on 24/10/2011 16:41 John Baldwin said the following:
On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote:
on 23/10/2011 18:27 Dennis Koegel said the following:
On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote:
Working offline with Dennis, we found that changing the CFLAGS in
sys/boot/i386/gptboot/Makefile from -O1 to -Os -mrtd (partially
reverting
an earlier commit) fixed gptboot. The next test for someone to do would
be to
try just adding -mrtd and leaving -O1 as-is to see if that fixes it.
More test results:
gcc -Os -fno-guess-branch-probability -fomit-frame-pointer
-fno-unit-at-a-time \
-mno-align-long-strings -mrtd [from before r225530]: Boots OK
gcc -Os -mrtd: Boots OK
gcc -O1 -mrtd: Fails
gcc -O1: Fails
gcc -O0: Fails
gcc -Os: Boots OK
clang -O1: Fails
clang -Os: Fails
clang -Oz: Fails
I've put some printf()s into gpt{,boot}.c to trace where the reboot is
triggered. It appears to be in drvsize() (called from gptread()). OTOH
the debug output may have changed where the problem occurs, I don't
know about that.
With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure
out what happens. But as for why gcc's magic -Os is required and clang's
output doesn't work at all, I'm clueless.
Thank you for your very valuable analysis!
I looked at a difference in assembly code of the drvsize function produced
by
gcc -Os and by gcc -O1. One thing that was immediately obvious is that gcc
places the params array and the sectors variable in a different order for
different options. One idea is that if BIOS actually writes beyond the
end of
the array, then in one case it could be harmless (overwrites the sector
variable), but in the other case it could be more harmful.
I found a document that suggests a possibility of BIOS writing more bytes
to the
array than its current size of 0x42:
http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf
Of course, the size of the array is passed to BIOS at the start of the
array and
so a _non-buggy_ BIOS should not write beyond the array, but we live in a
non-perfect world.
Hmm, I think we've had to do a similar workaround in the past for a
different
BIOS call (SMAP maybe?). However, I do have one request, can we declare an
actual structure instead of a silly char array? Then we can remove the
weird
casts with offsets into it, etc. Having an actual struct would be far more
readable and less bug-prone.
I am all for this.
Unfortunately. ENOTIME to do this properly at the moment.
Ugh, it looks like in EDD 4.0 they silently expanded the path field to 16 bytes
instead of 8 as in EDD 3.0 which is why the HP BIOS is probably writing an extra
four bytes.
Ah, so the deal is that the device path bit is variable length and the caller is
supposed to set the length on input which we aren't doing. However, we don't
care about the device path stuff anyway, so we can set a smaller input value.
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
on 24/10/2011 18:33 John Baldwin said the following:
On Monday, October 24, 2011 9:47:42 am Andriy Gapon wrote:
on 24/10/2011 16:41 John Baldwin said the following:
On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote:
[snip]
I found a document that suggests a possibility of BIOS writing more bytes
to the
array than its current size of 0x42:
http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf
Of course, the size of the array is passed to BIOS at the start of the
array and
so a _non-buggy_ BIOS should not write beyond the array, but we live in a
non-perfect world.
Hmm, I think we've had to do a similar workaround in the past for a
different
BIOS call (SMAP maybe?). However, I do have one request, can we declare an
actual structure instead of a silly char array? Then we can remove the
weird
casts with offsets into it, etc. Having an actual struct would be far more
readable and less bug-prone.
I am all for this.
Unfortunately. ENOTIME to do this properly at the moment.
Ugh, it looks like in EDD 4.0 they silently expanded the path field to 16
bytes
instead of 8 as in EDD 3.0 which is why the HP BIOS is probably writing an
extra
four bytes.
Yes, that's exactly what I meant above, but probably wasn't clear about that.
Ah, so the deal is that the device path bit is variable length and the caller
is
supposed to set the length on input which we aren't doing. However, we don't
care about the device path stuff anyway, so we can set a smaller input value.
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
+struct edd_params {
+ uint16_tlen;
+ uint16_tflags;
+ uint32_tcylinders;
+ uint32_theads;
+ uint32_tsectors_per_track;
+ uint64_tsectors;
+ uint32_tsector_size;
sector_size should be uint16_t, I think. Ditto for edd_params_v3 and
edd_params_v4.
sizeof(struct edd_params) should be 30, judging from the specs.
+ uint16_tedd_params_seg;
+ uint16_tedd_params_off;
+};
Perhaps the structures should be declared __packed (if only just in case)?
Also, perhaps edd_params_v3 and edd_params_v4 should inherit edd_params in some
smarter way to avoid verbatim duplicates.
Other than these issues the patch looks great!
Perhaps later we could do detailed definitions for things like interface paths
for
various cases, etc.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Monday, October 24, 2011 12:25:09 pm Andriy Gapon wrote:
on 24/10/2011 18:33 John Baldwin said the following:
On Monday, October 24, 2011 9:47:42 am Andriy Gapon wrote:
on 24/10/2011 16:41 John Baldwin said the following:
On Sunday, October 23, 2011 1:57:59 pm Andriy Gapon wrote:
[snip]
I found a document that suggests a possibility of BIOS writing more
bytes to the
array than its current size of 0x42:
http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf
Of course, the size of the array is passed to BIOS at the start of the
array and
so a _non-buggy_ BIOS should not write beyond the array, but we live in a
non-perfect world.
Hmm, I think we've had to do a similar workaround in the past for a
different
BIOS call (SMAP maybe?). However, I do have one request, can we declare
an
actual structure instead of a silly char array? Then we can remove the
weird
casts with offsets into it, etc. Having an actual struct would be far
more
readable and less bug-prone.
I am all for this.
Unfortunately. ENOTIME to do this properly at the moment.
Ugh, it looks like in EDD 4.0 they silently expanded the path field to 16
bytes
instead of 8 as in EDD 3.0 which is why the HP BIOS is probably writing an
extra
four bytes.
Yes, that's exactly what I meant above, but probably wasn't clear about that.
Ah, so the deal is that the device path bit is variable length and the
caller is
supposed to set the length on input which we aren't doing. However, we
don't
care about the device path stuff anyway, so we can set a smaller input
value.
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
+struct edd_params {
+ uint16_tlen;
+ uint16_tflags;
+ uint32_tcylinders;
+ uint32_theads;
+ uint32_tsectors_per_track;
+ uint64_tsectors;
+ uint32_tsector_size;
sector_size should be uint16_t, I think. Ditto for edd_params_v3 and
edd_params_v4.
sizeof(struct edd_params) should be 30, judging from the specs.
Oops, yeah.
+ uint16_tedd_params_seg;
+ uint16_tedd_params_off;
+};
Perhaps the structures should be declared __packed (if only just in case)?
Also, perhaps edd_params_v3 and edd_params_v4 should inherit edd_params in
some
smarter way to avoid verbatim duplicates.
Yeah, probably so. We will probably never even use them anyway (just as we
don't
use edd_packet_v3 even though we could probably make use of it to avoid some
bounce buffering in the loader).
Other than these issues the patch looks great!
Perhaps later we could do detailed definitions for things like interface
paths for
various cases, etc.
I doubt we will ever use them.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
Thanks!
- D.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Oct 24, 2011, at 2:40 PM, Dennis Koegel wrote:
On Mon, Oct 24, 2011 at 11:33:23AM -0400, John Baldwin wrote:
Perhaps try http://www.freebsd.org/~jhb/patches/edd_params.patch
GCC chokes here in drv.c:{49,50}: cannot convert to a pointer type:
v86.ds = VTOPSEG(params);
v86.esi = VTOPOFF(params);
Changed this to params. Also changed sector_size to uint16_t as noted
by Andriy. Boots perfectly! (Tested with gcc and clang)
I'd like to test these patches on my Supermicro machine as well. Unfortunately,
I don't know how to go about it, but I'm hopeful to be able to figure it out
with some basic instructions. I'm currently running a fresh RC1 install, and
I'm able to boot the system if I set the BIOS to IDE mode, rather than AHCI.
Any help would be much appreciated,
Gunnar___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: replacement of ataidle for freebsd 9
23.10.2011 11:12, Eugene Dzhurinsky wrote: In the mentime, can you please advice how can I use camcontrol in order to disable APM for my HDD? @reboot camcontrol idle ada0 -t 300 ; camcontrol idle ada1 -t 300 -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: replacement of ataidle for freebsd 9
On Sat, Oct 22, 2011 at 09:59:45PM +0100, Bruce Cran wrote: On 22/10/2011 16:21, Eugene Dzhurinsky wrote: ataidle -P 0 /dev/ada0 ataidle: error opening /dev/ada0 Thanks for reporting the breakage, I'll see if I can get it fixed in time for 9.0. Wow, it would be great! :) In the mentime, can you please advice how can I use camcontrol in order to disable APM for my HDD? Many thanks! -- Eugene N Dzhurinsky pgpK7gnXfMGv4.pgp Description: PGP signature
Re: Fresh installed Freebsd 9 don't boot from hd
on 22/10/2011 01:22 Gunnar Schaefer said the following: On Oct 21, 2011, at 2:37 PM, Andriy Gapon wrote: A litmus question: do those experiencing the trouble all have BTX_SERIAL defined? Not sure where BTX_SERIAL would be defined, but I'm seeing the problem with the generic kernel. Does that answer your question? It's a make knob for boot code. Also, how does this relate to my observation that my system boots in IDE mode, but hangs in AHCI mode? No relation. I do not have any explanation for what you experience. I believe that FreeBSD code doesn't know anything about IDE vs AHCI and interacts with HDDs entirely through BIOS interfaces. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote:
Working offline with Dennis, we found that changing the CFLAGS in
sys/boot/i386/gptboot/Makefile from -O1 to -Os -mrtd (partially reverting
an earlier commit) fixed gptboot. The next test for someone to do would be
to
try just adding -mrtd and leaving -O1 as-is to see if that fixes it.
More test results:
gcc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time \
-mno-align-long-strings -mrtd [from before r225530]: Boots OK
gcc -Os -mrtd: Boots OK
gcc -O1 -mrtd: Fails
gcc -O1: Fails
gcc -O0: Fails
gcc -Os: Boots OK
clang -O1: Fails
clang -Os: Fails
clang -Oz: Fails
I've put some printf()s into gpt{,boot}.c to trace where the reboot is
triggered. It appears to be in drvsize() (called from gptread()). OTOH
the debug output may have changed where the problem occurs, I don't
know about that.
With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure
out what happens. But as for why gcc's magic -Os is required and clang's
output doesn't work at all, I'm clueless.
- D.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
on 23/10/2011 18:27 Dennis Koegel said the following:
On Fri, Oct 21, 2011 at 04:33:38PM -0400, John Baldwin wrote:
Working offline with Dennis, we found that changing the CFLAGS in
sys/boot/i386/gptboot/Makefile from -O1 to -Os -mrtd (partially
reverting
an earlier commit) fixed gptboot. The next test for someone to do would be
to
try just adding -mrtd and leaving -O1 as-is to see if that fixes it.
More test results:
gcc -Os -fno-guess-branch-probability -fomit-frame-pointer
-fno-unit-at-a-time \
-mno-align-long-strings -mrtd [from before r225530]: Boots OK
gcc -Os -mrtd: Boots OK
gcc -O1 -mrtd: Fails
gcc -O1: Fails
gcc -O0: Fails
gcc -Os: Boots OK
clang -O1: Fails
clang -Os: Fails
clang -Oz: Fails
I've put some printf()s into gpt{,boot}.c to trace where the reboot is
triggered. It appears to be in drvsize() (called from gptread()). OTOH
the debug output may have changed where the problem occurs, I don't
know about that.
With 9.0R drawing near, CFLAGS should be s/-O1/-Os/, until we can figure
out what happens. But as for why gcc's magic -Os is required and clang's
output doesn't work at all, I'm clueless.
Thank you for your very valuable analysis!
I looked at a difference in assembly code of the drvsize function produced by
gcc -Os and by gcc -O1. One thing that was immediately obvious is that gcc
places the params array and the sectors variable in a different order for
different options. One idea is that if BIOS actually writes beyond the end of
the array, then in one case it could be harmless (overwrites the sector
variable), but in the other case it could be more harmful.
I found a document that suggests a possibility of BIOS writing more bytes to the
array than its current size of 0x42:
http://www.t13.org/documents/UploadedDocuments/docs2008/e08134r1-BIOS_Enhanced_Disk_Drive_Services_4.0.pdf
Of course, the size of the array is passed to BIOS at the start of the array and
so a _non-buggy_ BIOS should not write beyond the array, but we live in a
non-perfect world.
Could you please test this hypothesis by trying the following patch?
diff --git a/sys/boot/i386/common/drv.c b/sys/boot/i386/common/drv.c
index 11f6628..5996a80 100644
--- a/sys/boot/i386/common/drv.c
+++ b/sys/boot/i386/common/drv.c
@@ -37,10 +37,10 @@ __FBSDID($FreeBSD$);
uint64_t
drvsize(struct dsk *dskp)
{
- unsigned char params[0x42];
+ unsigned char params[0x4A];
uint64_t sectors;
- *(uint32_t *)params = sizeof(params);
+ *(uint16_t *)params = sizeof(params);
v86.ctl = V86_FLAGS;
v86.addr = 0x13;
P.S. the assembly diff to which I referred above:
--- drvsize.Os.S2011-10-23 20:17:56.871996966 +0300
+++ drvsize.O1.S2011-10-23 20:18:27.430995560 +0300
@@ -4,8 +4,8 @@
pushl %ebp
movl%esp, %ebp
subl$76, %esp
- leal-74(%ebp), %ecx
- movl$66, -74(%ebp)
+ leal-66(%ebp), %ecx
+ movl$66, -66(%ebp)
movl$262144, __v86
movl$19, __v86+4
movl$18432, __v86+24
@@ -28,20 +28,20 @@
pushl %eax
pushl $.LC4
callprintf
- xorl%eax, %eax
- xorl%edx, %edx
- popl%ecx
- popl%ecx
+ movl$0, %eax
+ movl$0, %edx
+ addl$8, %esp
jmp .L16
+ .p2align 2,,3
.L14:
pushl $8
- leal-58(%ebp), %eax
+ leal-50(%ebp), %eax
pushl %eax
- leal-8(%ebp), %eax
+ leal-76(%ebp), %eax
pushl %eax
callmemcpy
- movl-8(%ebp), %eax
- movl-4(%ebp), %edx
+ movl-76(%ebp), %eax
+ movl-72(%ebp), %edx
addl$12, %esp
.L16:
leave
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Sun, Oct 23, 2011 at 08:57:59PM +0300, Andriy Gapon wrote: I found a document that suggests a possibility of BIOS writing more bytes to the array than its current size of 0x42: [...] Could you please test this hypothesis by trying the following patch? With -O1 and this patch, it boots. Thank you! - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On 2011-10-23 21:56, Dennis Koegel wrote: On Sun, Oct 23, 2011 at 08:57:59PM +0300, Andriy Gapon wrote: I found a document that suggests a possibility of BIOS writing more bytes to the array than its current size of 0x42: [...] Could you please test this hypothesis by trying the following patch? With -O1 and this patch, it boots. Thank you! If you have some time, can you also re-check the other cases you listed before? E.g.: gcc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time \ -mno-align-long-strings -mrtd [from before r225530]: gcc -Os -mrtd: gcc -O1 -mrtd: gcc -O1: gcc -O0: gcc -Os: clang -O1: clang -Os: clang -Oz: Thanks. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
replacement of ataidle for freebsd 9
Hello, can somebody please advice how to disable APM power management for HDD on laptops? camcontrol cmd ada0 -a EF 05 00 00 00 00 00 00 00 00 00 00 -v camcontrol: error sending command (pass0:ahcich0:0:0:0): SETFEATURES. ACB: ef 05 00 00 00 00 00 00 00 00 00 00 (pass0:ahcich0:0:0:0): CAM status: ATA Status Error (pass0:ahcich0:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (pass0:ahcich0:0:0:0): RES: 51 04 00 00 00 00 00 00 00 00 00 What else should I try? uname -a FreeBSD devbox 9.0-RC1 FreeBSD 9.0-RC1 #0: Thu Oct 20 08:48:57 EEST 2011 root@devbox:/usr/obj/usr/src/sys/GENERIC amd64 Thanks! -- Eugene N Dzhurinsky pgpXWhgKl3KiZ.pgp Description: PGP signature
Re: replacement of ataidle for freebsd 9
Why do you not want to use ataidle? -- Bruce Cran (ataidle maintainer) On 22 Oct 2011, at 11:36, Eugene Dzhurinsky jdeve...@gmail.com wrote: Hello, can somebody please advice how to disable APM power management for HDD on laptops? camcontrol cmd ada0 -a EF 05 00 00 00 00 00 00 00 00 00 00 -v camcontrol: error sending command (pass0:ahcich0:0:0:0): SETFEATURES. ACB: ef 05 00 00 00 00 00 00 00 00 00 00 (pass0:ahcich0:0:0:0): CAM status: ATA Status Error (pass0:ahcich0:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) (pass0:ahcich0:0:0:0): RES: 51 04 00 00 00 00 00 00 00 00 00 What else should I try? uname -a FreeBSD devbox 9.0-RC1 FreeBSD 9.0-RC1 #0: Thu Oct 20 08:48:57 EEST 2011 root@devbox:/usr/obj/usr/src/sys/GENERIC amd64 Thanks! -- Eugene N Dzhurinsky ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: replacement of ataidle for freebsd 9
On Sat, Oct 22, 2011 at 02:23:53PM +0100, Bruce Cran wrote: Why do you not want to use ataidle? ataidle -P 0 /dev/ada0 ataidle: error opening /dev/ada0 ataidle -P 0 /dev/ad4 ataidle: error: identify device /dev/ad4 ls -l /dev | grep ad lrwxr-xr-x 1 root wheel4 Oct 22 18:16 ad4@ - ada0 lrwxr-xr-x 1 root wheel6 Oct 22 18:16 ad4s1@ - ada0s1 lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1a@ - ada0s1a lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1b@ - ada0s1b lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1d@ - ada0s1d lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1e@ - ada0s1e lrwxr-xr-x 1 root wheel7 Oct 22 18:16 ad4s1f@ - ada0s1f lrwxr-xr-x 1 root wheel6 Oct 22 18:16 ad4s2@ - ada0s2 crw-r- 1 root operator0, 81 Oct 22 18:16 ada0 crw-r- 1 root operator0, 84 Oct 22 18:16 ada0s1 crw-r- 1 root operator0, 88 Oct 22 21:16 ada0s1a crw-r- 1 root operator0, 90 Oct 22 18:16 ada0s1b crw-r- 1 root operator0, 92 Oct 22 21:16 ada0s1d crw-r- 1 root operator0, 94 Oct 22 21:16 ada0s1e crw-r- 1 root operator0, 96 Oct 22 21:16 ada0s1f crw-r- 1 root operator0, 86 Oct 22 21:16 ada0s2 smartctl -a /dev/ada0 smartctl 5.42 2011-10-20 r3458 [FreeBSD 9.0-RC1 amd64] (local build) Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Device Model: ST9500423AS Serial Number:W2V003TQ LU WWN Device Id: 5 000c50 03d75b968 Firmware Version: 0002SDM1 User Capacity:500,107,862,016 bytes [500 GB] Sector Sizes: 512 bytes logical, 4096 bytes physical Device is:Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is:Sat Oct 22 18:20:22 2011 EEST SMART support is: Available - device has SMART capability. SMART support is: Enabled -- Eugene N Dzhurinsky pgpFw5hq6gcCH.pgp Description: PGP signature
Re: replacement of ataidle for freebsd 9
On 22/10/2011 16:21, Eugene Dzhurinsky wrote: ataidle -P 0 /dev/ada0 ataidle: error opening /dev/ada0 Thanks for reporting the breakage, I'll see if I can get it fixed in time for 9.0. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. I've used the BETA3 bsdinstall on other (amd64) hardware with GPT and it worked fine. Also, manually adding the GPT label, partitions and bootcode using gpart, then rebooting, shows the exact same behaviour (this was done using the BETA3 Live CD). I suspect it's something in the vicinity of pmbr bootcode vs. newer HP BIOS. (BTW, not related to this issue: hw.memtest.tests=0 should be default. The kernel on a system with 128 GB of RAM needs about two minutes (!) before emitting a single line of output. At first we didn't know about this test and thought there was a serious problem.) - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
2011/10/21 Dennis Koegel d...@neveragain.de On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. I've used the BETA3 bsdinstall on other (amd64) hardware with GPT and it worked fine. Also, manually adding the GPT label, partitions and bootcode using gpart, then rebooting, shows the exact same behaviour (this was done using the BETA3 Live CD). I suspect it's something in the vicinity of pmbr bootcode vs. newer HP BIOS. I don't know, but earlier snapshots, for example, ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201105/FreeBSD-9.0-CURRENT-201105-amd64-dvd1.iso doesn't have such problems. Does anybody have BETA-2 iso? (BTW, not related to this issue: hw.memtest.tests=0 should be default. The kernel on a system with 128 GB of RAM needs about two minutes (!) before emitting a single line of output. At first we didn't know about this test and thought there was a serious problem.) - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
2011/10/21 Dennis Koegel d...@neveragain.de On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. I've used the BETA3 bsdinstall on other (amd64) hardware with GPT and it worked fine. Also, manually adding the GPT label, partitions and bootcode using gpart, then rebooting, shows the exact same behaviour (this was done using the BETA3 Live CD). I suspect it's something in the vicinity of pmbr bootcode vs. newer HP BIOS. (BTW, not related to this issue: hw.memtest.tests=0 should be default. The kernel on a system with 128 GB of RAM needs about two minutes (!) before emitting a single line of output. At first we didn't know about this test and thought there was a serious problem.) My proliant have 1Gb RAM =) - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Fri, Oct 21, 2011 at 10:58:51AM +0200, Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. I've used the BETA3 bsdinstall on other (amd64) hardware with GPT and it worked fine. Also, manually adding the GPT label, partitions and bootcode using gpart, then rebooting, shows the exact same behaviour (this was done using the BETA3 Live CD). I suspect it's something in the vicinity of pmbr bootcode vs. newer HP BIOS. (BTW, not related to this issue: hw.memtest.tests=0 should be default. The kernel on a system with 128 GB of RAM needs about two minutes (!) before emitting a single line of output. At first we didn't know about this test and thought there was a serious problem.) Or at least there should be a message that the memtest is running... pgpY4GqxDI5oP.pgp Description: PGP signature
Re: Fresh installed Freebsd 9 don't boot from hd
On Oct 21, 2011, at 1:58 AM, Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. I'm seeing the same behavior on a Supermicro X8DT3 BIOS. The latest BIOS update changed the behavior from hanging forever to hanging for 2 seconds before rebooting. The problem occurs with BETA3 and RC1, but not with BETA2. Changing SATA mode from AHCI to IDE in the BIOS gets the OS to boot just fine. Cheers, Gunnar I've used the BETA3 bsdinstall on other (amd64) hardware with GPT and it worked fine. Also, manually adding the GPT label, partitions and bootcode using gpart, then rebooting, shows the exact same behaviour (this was done using the BETA3 Live CD). I suspect it's something in the vicinity of pmbr bootcode vs. newer HP BIOS. (BTW, not related to this issue: hw.memtest.tests=0 should be default. The kernel on a system with 128 GB of RAM needs about two minutes (!) before emitting a single line of output. At first we didn't know about this test and thought there was a serious problem.) - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Friday, October 21, 2011 4:58:51 am Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. Working offline with Dennis, we found that changing the CFLAGS in sys/boot/i386/gptboot/Makefile from -O1 to -Os -mrtd (partially reverting an earlier commit) fixed gptboot. The next test for someone to do would be to try just adding -mrtd and leaving -O1 as-is to see if that fixes it. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
on 21/10/2011 23:33 John Baldwin said the following: On Friday, October 21, 2011 4:58:51 am Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. Working offline with Dennis, we found that changing the CFLAGS in sys/boot/i386/gptboot/Makefile from -O1 to -Os -mrtd (partially reverting an earlier commit) fixed gptboot. The next test for someone to do would be to try just adding -mrtd and leaving -O1 as-is to see if that fixes it. Hmm, this is quite unexpected... Do you have a hypothesis why not using -mrtd could cause a problem (a miscompilation?) ? I previously assumed that -O1 is typically a quite safe optimization, not sure if it's even worth trying -O0 for a test. Or could this be about a size of gptboot blob? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
on 22/10/2011 00:27 Andriy Gapon said the following: on 21/10/2011 23:33 John Baldwin said the following: On Friday, October 21, 2011 4:58:51 am Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. Working offline with Dennis, we found that changing the CFLAGS in sys/boot/i386/gptboot/Makefile from -O1 to -Os -mrtd (partially reverting an earlier commit) fixed gptboot. The next test for someone to do would be to try just adding -mrtd and leaving -O1 as-is to see if that fixes it. Hmm, this is quite unexpected... Do you have a hypothesis why not using -mrtd could cause a problem (a miscompilation?) ? I've just got one: maybe the trouble is caused by the sio_putc procedure in sys/boot/i386/btx/btx/btx.S. It seems to be the only place in the boot code where 'ret number' instruction is explicitly used. A litmus question: do those experiencing the trouble all have BTX_SERIAL defined? P.S. BTW, is BTX_SERIAL documented anywhere? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fresh installed Freebsd 9 don't boot from hd
On Oct 21, 2011, at 2:37 PM, Andriy Gapon wrote: on 22/10/2011 00:27 Andriy Gapon said the following: on 21/10/2011 23:33 John Baldwin said the following: On Friday, October 21, 2011 4:58:51 am Dennis Koegel wrote: On Thu, Oct 20, 2011 at 11:28:08AM +0400, Pavel Timofeev wrote: I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. [...] It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. We have the same issue on a DL580 G7. Install runs fine, but when it's time for the first boot, the bootcode emits a single '-' (where usually it would be spinning for a moment while loading), hangs for about two seconds, and then reboots. Working offline with Dennis, we found that changing the CFLAGS in sys/boot/i386/gptboot/Makefile from -O1 to -Os -mrtd (partially reverting an earlier commit) fixed gptboot. The next test for someone to do would be to try just adding -mrtd and leaving -O1 as-is to see if that fixes it. Hmm, this is quite unexpected... Do you have a hypothesis why not using -mrtd could cause a problem (a miscompilation?) ? I've just got one: maybe the trouble is caused by the sio_putc procedure in sys/boot/i386/btx/btx/btx.S. It seems to be the only place in the boot code where 'ret number' instruction is explicitly used. A litmus question: do those experiencing the trouble all have BTX_SERIAL defined? Not sure where BTX_SERIAL would be defined, but I'm seeing the problem with the generic kernel. Does that answer your question? Also, how does this relate to my observation that my system boots in IDE mode, but hangs in AHCI mode? P.S. BTW, is BTX_SERIAL documented anywhere? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Fresh installed Freebsd 9 don't boot from hd
I used FreeBSD 9 amd64 on my HP Proliant DL360 G5 (smart array p400i mirror) as test. It was installed long time ago and often I did csup/rebuild. Yesterday I updated it to 9.0-RC1 and everything was fine. Today I downloaded BETA3 iso and tried to install it. bsdinstall is good. CD ISO boots and installs good. It was fresh install and I choose guided partitioning (GPT) But after reboot my server don't boot from hd. I see HP splash screen, checks for iLo, smart array and when I should see message like Attempting boot from harddrive and then BTX it reboots. If I use MBR (new install) - system boots from hd normally. I tied 10.0-HEAD-20111018-JPSNAP snapshot from http://pub.allbsd.org/FreeBSD-snapshots/ I tried 9.0-RC1 iso that sometimes appears in ftp.freebsd.org Same story. Is it bsdinstall bug? P.S. in VirtualBox everything is fine. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9: Fn+* keyboard combinations aren't working anymore.
On Sun, 2 Oct 2011 15:49:44 +0400 arrowdodger 6year...@gmail.com wrote: On Wed, Sep 28, 2011 at 5:44 PM, arrowdodger 6year...@gmail.com wrote: On Wed, Sep 28, 2011 at 5:32 PM, Lars Engels lars.eng...@0x20.net wrote: On Wed, Sep 28, 2011 at 05:30:25PM +0400, arrowdodger wrote: Hello. I've used FreeBSD 8-STABLE on my Asus K40IN notebook. This notebook has an key combination (Fn+F6/F7)to change monitor brightness. After i've updated my system to 9-STABLE, these combinations stopped working. It's worth mentioning, that these combinations still work at boot screen. Have you tried loading acpi_asus.ko? I've tried to do so when i was on 8-STABLE and it didn't work. It's not working for me on 9-STABLE too: acpi_asus0: Unsupported Asus laptop: K40IN All hotkeys, except ones for switching Wi-Fi and adjusting volume, were working on 8-STABLE. If no one knows a fix for this problem, maybe someone can point me to relevant code? I may try to bisect revisions, or to check commit log. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org /usr/src/sys/dev/acpi_support/acpi_asus.c Might be a good place to start? You can use 'acpidump -dt acpidump.aml' to get a dump of the laptop's acpi in the file acpidump.aml...This may allow you to determine what changed, either in the acpi_asus or in your laptop's ACPI Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9: Fn+* keyboard combinations aren't working anymore.
On Mon, Oct 3, 2011 at 8:56 PM, matt sendtom...@gmail.com wrote: /usr/src/sys/dev/acpi_support/acpi_asus.c Might be a good place to start? You can use 'acpidump -dt acpidump.aml' to get a dump of the laptop's acpi in the file acpidump.aml...This may allow you to determine what changed, either in the acpi_asus or in your laptop's ACPI Matt If that acpi_asus.c file is from acpi_asus.ko, then it has nothing to do with my problem - i'm not using it. I will take a look on acpidump, thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9: Fn+* keyboard combinations aren't working anymore.
On Wed, Sep 28, 2011 at 5:44 PM, arrowdodger 6year...@gmail.com wrote: On Wed, Sep 28, 2011 at 5:32 PM, Lars Engels lars.eng...@0x20.net wrote: On Wed, Sep 28, 2011 at 05:30:25PM +0400, arrowdodger wrote: Hello. I've used FreeBSD 8-STABLE on my Asus K40IN notebook. This notebook has an key combination (Fn+F6/F7)to change monitor brightness. After i've updated my system to 9-STABLE, these combinations stopped working. It's worth mentioning, that these combinations still work at boot screen. Have you tried loading acpi_asus.ko? I've tried to do so when i was on 8-STABLE and it didn't work. It's not working for me on 9-STABLE too: acpi_asus0: Unsupported Asus laptop: K40IN All hotkeys, except ones for switching Wi-Fi and adjusting volume, were working on 8-STABLE. If no one knows a fix for this problem, maybe someone can point me to relevant code? I may try to bisect revisions, or to check commit log. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
