Re: [RFC] Patch to improve TSO limitation formula in general
Hi Rick, Did you get a chance to look further at my patch? Is this something we can commit? --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
CDC-WDM driver (4G modems)
Folks, Hans-Petter, Is anyone aware of an effort to create support for QMI based 4G modems? The following parts need to be implemented I think: - CDC-WDM support - Wrapper driver to access QMI devices as WDM? - libqmi port to FreeBSD This would support any modem from Telit, Sierra Wireless, Option, etc. that works with the Qualcomm chipsets. If you look in the cdc-wdm qmi driver in Linux, it is a long list. I could not find any mention of FreeBSD and QMI on the same page, so I assume no one is working on it. Nick Hibma ___ 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: UEFI display frozen on Retina MacBook Pro
On 09/09/2014 17:56, John Nielsen wrote: On Sep 8, 2014, at 7:21 AM, Anders Bolt Evensen andersb...@icloud.com wrote: On 05.09.14 19:37, John Nielsen wrote: On Sep 5, 2014, at 11:30 AM, Glen Barber g...@freebsd.org wrote: On Fri, Sep 05, 2014 at 11:20:21AM -0600, John Nielsen wrote: I have a MacBook Pro Retina, Mid 2012 (MacBookPro10,1) on which I'd like to be able to boot FreeBSD from an external USB drive. For testing I've been using the mini-memstick images from the -CURRENT snapshots, most recently the one from 20140903. I am able to select EFI Boot on the USB device from the Mac's boot menu, and it does _something_, but the screen never changes--the image of the boot menu is displayed indefinitely. I think it is actually booting since there is drive activity and the caps lock key indicator starts working a few seconds in, but the screen just stays the same. Thinking the resolution of the Retina display may have been an issue, I tried booting with it disabled (lid closed) and an external monitor and keyboard. The result was the same--Mac boot menu frozen on the external display. Is there anything I should try to troubleshoot or debug this issue? Anything else I should include in a PR? I can test patches if needed (probably after building an image including the patch from a VM). To be clear, which boot menu do you see? If you see the FreeBSD loader menu, escape to the loader prompt and try: set kern.vty=vt set hw.vga.textmode=1 boot I am a bit unclear under which conditions 'hw.vga.textmode=1' is required, though. No, I don't ever see the FreeBSD loader. I see the menu you get on a Mac when you hold down the option (alt) key while booting--big disk icons representing the bootable disks/partitions in the system. In my case it was the Macintosh HD volume (Mac OS Mavericks), my Windows partition, and the USB stick with the FreeBSD memstick image on it, which the Mac just called EFI Boot (and the icon was that of a USB disk). There is also a little section at the bottom that allows wifi network booting (if you've done all the black magic (not PXE) to get that to happen). It shows a circular activity animation while it scans for wireless networks. That animation stops when I select the USB EFI icon and press enter (and that is the only visual indication I get that I made a selection). To see the FreeBSD (U)EFI boot loader on the Mac, you need to install an EFI shell like rEFIt on either your hard drive or a HFS formatted memory stick: 1) Download the rEFIt installer from here: http://downloads.sourceforge.net/project/refit/rEFIt/0.14/rEFIt-0.14.dmg?r=http%3A%2F%2Frefit.sourceforge.net%2Fts=1410181876use_mirror=optimate 2) Open the downloaded file 3) Run the following command from the terminal: sudo installer -pkg /Volumes/rEFIt/rEFIt.mpkg -tgt /Volumes/memstick (in this example, I'm using an HFS formatted memory stick). 4) Run the command sudo /Volumes/memstick/efi/enable.sh 5) When you reboot your Mac, when you hold down the alt key, choose rEFIt on the startup menu. Then, choose the BOOTx64.efi from … option If everything now goes as it should, you should see the FreeBSD loader. When the Press enter to boot or any other key to go to loader in X seconds (or whatever it says), press a random key. Then try to type the commands suggested by [Glen Barber]. Thanks all, made _some_ progress. I installed rEFInd on my internal hard drive and now I can get to (and see!) the FreeBSD EFI loader. Unfortunately that's about as far as it gets. Once I tell the loader to boot it displays the EFI framebuffer information and then nothing else. This happens with 'kern.vty=vt' set and with or without 'hw.vga.textmode=1'. Screenshot here: https://blog.jnielsen.net/images/efiloader.jpg What should the next troubleshooting steps be? Just wanted to add a me too. I've finding exactly the same thing trying a usb or DVD 11-CURRENT snapshot. Hardware is MacBook Pro (15-inch, Mid 2010) Model Name:MacBook Pro Model Identifier:MacBookPro6,2 Processor Name:Intel Core i7 Processor Speed:2.66 GHz Number of Processors:1 Total Number of Cores:2 L2 Cache (per Core):256 KB L3 Cache:4 MB Memory:8 GB Processor Interconnect Speed:4.8 GT/s Boot ROM Version:MBP61.0057.B0F SMC Version (system):1.58f17 Can upload a screenshot but its more or less identical to Johns. Vince JN ___ 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: CDC-WDM driver (4G modems)
On 09/11/14 15:23, Nick Hibma wrote: Folks, Hans-Petter, Is anyone aware of an effort to create support for QMI based 4G modems? The following parts need to be implemented I think: - CDC-WDM support - Wrapper driver to access QMI devices as WDM? - libqmi port to FreeBSD This would support any modem from Telit, Sierra Wireless, Option, etc. that works with the Qualcomm chipsets. If you look in the cdc-wdm qmi driver in Linux, it is a long list. I could not find any mention of FreeBSD and QMI on the same page, so I assume no one is working on it. Hi, I'm not aware of any projects in that area. --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: UEFI boot failure: BIOS smap did not include a basemem segment!
On 10 September 2014 15:00, Jean-Sébastien Pédron dumbb...@freebsd.org wrote:
Hello!
I tried the following FreeBSD snapshot on my Clevo W860CU with UEFI
enabled:
FreeBSD-11.0-CURRENT-amd64-20140903-r270990-memstick.img
Thanks for trying it out.
The boot fails early with the following error:
panic: BIOS smap did not include a basemem segment!
This panic means the memory map does not include usable memory (for
the kernel) with physaddr 0.
if (physmap[i] == 0x) {
basemem = physmap[i + 1] / 1024;
basemem == 0 produces the panic.
The requirement for a usable memory range with physaddr 0 doesn't hold
for UEFI, and the md startup hasn't yet been reworked to accommodate
that.
Here's a video of a verbose boot (the quality is really low, I can try
to redo it if this one doesn't help):
http://www.dumbbell.fr/~dumbbell/FreeBSD-Clevo-W860CU-UEFI-no-basemem-segment.mov
Pausing the video immediately after the kernel starts confirms this:
the UEFI firmware has RuntimeServicesData at physaddr 0, so not
available for kernel use.
Do you mind submitting a PR to keep track of this issue?
___
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: UEFI boot failure: BIOS smap did not include a basemem segment!
On 11.09.2014 16:12, Ed Maste wrote: The requirement for a usable memory range with physaddr 0 doesn't hold for UEFI, and the md startup hasn't yet been reworked to accommodate that. Thank you for the explanation! Do you mind submitting a PR to keep track of this issue? Here it is: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193564 -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Intel i915 GPU hung
Hello, I have just upgrade my laptop, a Samsung Ativ Book 2 with an integrated Intel HD Graphics 4000, to: FreeBSD ativ.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271400: Wed Sep 10 21:40:48 CEST 2014 root@ativ.local:/usr/obj/usr/src/sys/NEWCONS amd64 Using Firefox, after some minutes, I receive the error: error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung info: [drm] capturing error event; look for more information in sysctl hw.dri.0.info.i915_error_state This error is not related to r271400, but I first saw it few months ago in current. The output of the command sysctl hw.dri.0.info.i915_error_state is: https://drive.google.com/file/d/0BzoWQoMqq1sfa0tyVGJVYVBhRnc/edit?usp=sharing After the error I am not able to run mplayer for videos: the window is black. Regards, Maurizio ___ 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
UEFI cd boots, what it installs doesn't
Hello Currents, I grabbed FreeBSD-11.0-CURRENT-amd64-20140903-r270990-disc1.iso, burned it to disk then booted from it. It boots up fine, and it goes through the install routine fine. The problem is, after the install is finished, when I try to boot the installed system, it gives me the option to select 0 or 1. Whatever I select, I get a flashing cursor then nothing. If I leave it at nothing eventually the bios asks what the problem is. What am I doing wrong? The board is an Asus Z87-PRO and the disks are Hitatchi 3TB drives. I'm trying to install to ad1, ad0 is a SSD. I've tried ad0 ad2 and ad3 to no avail. PC-BSD will install if the default options are chosen. It installs GRUB. Ubuntu 14 and Mint 17 also install. I don't want pc-bsd because it imposes zfs, all I need is freebsd with ufs and gconcat and also /var and /tmp on the ssd. thanks, -- John ___ 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: UEFI cd boots, what it installs doesn't
On 09/11/14 07:42, John wrote: Hello Currents, I grabbed FreeBSD-11.0-CURRENT-amd64-20140903-r270990-disc1.iso, burned it to disk then booted from it. It boots up fine, and it goes through the install routine fine. The problem is, after the install is finished, when I try to boot the installed system, it gives me the option to select 0 or 1. Whatever I select, I get a flashing cursor then nothing. If I leave it at nothing eventually the bios asks what the problem is. What am I doing wrong? The board is an Asus Z87-PRO and the disks are Hitatchi 3TB drives. I'm trying to install to ad1, ad0 is a SSD. I've tried ad0 ad2 and ad3 to no avail. PC-BSD will install if the default options are chosen. It installs GRUB. Ubuntu 14 and Mint 17 also install. I don't want pc-bsd because it imposes zfs, all I need is freebsd with ufs and gconcat and also /var and /tmp on the ssd. thanks, Can you test the memstick image? That uses the same bootblocks as an installed system. -Nathan ___ 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: UEFI cd boots, what it installs doesn't
Hello Currents, I grabbed FreeBSD-11.0-CURRENT-amd64-20140903-r270990-disc1.iso, burned it to disk then booted from it. It boots up fine, and it goes through the install routine fine. The problem is, after the install is finished, when I try to boot the installed system, it gives me the option to select 0 or 1. Whatever I select, I get a flashing cursor then nothing. If I leave it at nothing eventually the bios asks what the problem is. What am I doing wrong? The board is an Asus Z87-PRO and the disks are Hitatchi 3TB drives. I'm trying to install to ad1, ad0 is a SSD. I've tried ad0 ad2 and ad3 to no avail. PC-BSD will install if the default options are chosen. It installs GRUB. Ubuntu 14 and Mint 17 also install. I don't want pc-bsd because it imposes zfs, all I need is freebsd with ufs and gconcat and also /var and /tmp on the ssd. I've run into issues in the past, when attempting to install FreeBSD on a disk that grub had been put on from another OS. I found that blowing away the MBR, a couple of times, solved it. More specifically; Writing a generic MSDOS type MBR on the disk. I've forgotten the incantation. But it can be done from the live FreeBSD install media, or the GPARTD CD, if you have one. HTH --Chris thanks, -- John ___ 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: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov a...@freebsd.org wrote: On 09.09.2014 21:53, Patrick Kelsey wrote: I don't think it is worth the trouble, as given the larger pattern of libc routines requiring multiple capsicum rights, it seems one will in general have to have libc implementation knowledge when using it in concert with capsicum. For example, consider the limitfd() routine in kdump.c, which provides rights for the TIOCGETA ioctl to be used on stdout so the eventual call to isatty() via printf() will work as intended. I think the above kdump example is a good one for the subtle issues that can arise when using capsicum with libc. That call to isatty() is via a widely-used internal libc routine __smakebuf(). __smakebuf() also calls __swhatbuf(), which in turn calls _fstat(), all to make sure that output to a tty is line buffered by default. It would appear that programs that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT could be disabling the normally default line buffering when stdout is a tty. kdump goes the distance, but dhclient does not (restricting stdout to CAP_WRITE only). In any event, the patch attached to my first message is seeming like the way to go. Well, then commit it (if capsicum team agrees). Will do - thanks for the feedback. -Patrick ___ 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: [RFC] Patch to improve TSO limitation formula in general
Hans Petter Selasky wrote: Hi Rick, Did you get a chance to look further at my patch? Ok, I just took a quick look. (I didn't try and figure out if the code in tcp_output() looked correct.) Is this something we can commit? Well, I'd like to sound more positive, but here are a number of problems I see with the patch: 1 - if_hw_tsomax is already in use by at least one driver, so I think it would be a POLA violation to replace it and make it very difficult to MFC. -- I'd leave if_hw_tsomax as is and add your new stuff as separate fields so things don't get broken for drivers that don't support your new fields. 2 - As above, most drivers don't even set if_hw_tsomax, so it will take some time for drivers to be converted. -- As such, the defaults need to be such that an NFS mbuf list of 35 mbufs totalling just over 64K works. (The drivers that handle 32 mbufs in a list need to get an mbuf list with no more that 64K minus ethernet headers, so they can squeeze the TSO segment into 32 mclbyte mbuf clusters via m_defrag().) 3 - I don't think making the fields log 2 is necessary or appropriate. Many current drivers support 35 mbufs in the fragment list. This is enough for NFS and is not a power of 2. I think each field should be just a u_int that can replace spares in struct ifnet. -- I do not think that the size of ethernet headers needs to be specified if if_hw_tsomax still exists, since the driver can reduce the max size by that much. (It also varies depending on network type and whether or not VLAN headers are done by the hardware or driver.) In summary, I'd add two u_ints to struct ifnet: 1 - for max size of a fragment 2 - for max # of transmit fragments then I'd set the defaults for these so that current code (ie. old drivers) don't break. This would probably mean a large default for both of these along with the current default value for if_hw_tsomax. Then the fun part..Make tcp_output() generate TSO segments that are limited by all three of the above. rick ps: Hopefully others will comment on this, since I'm not a networking guy. (I just ended up involved in this because NFS over TSO enabled net interfaces was badly broken and I got tired of telling people to disable TSO.) --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-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: Intel i915 GPU hung
I often get this on HD3000 when I push the GPU too hard.. (Well not really hard at all, but the harder I push it the sooner I get GPU crash). After the crash the desktop works fine but pure OpenGL apps don't (ie nothing shows up on the screen). I assume it has switched to software rendering(?) I'll try to get the error_state next time and post it. This is the only problem I have running FreeBSD on my Intel laptop and it is quite annoying when computer (GPU) crashes during demo for visitors and potential customers.. Anyone have any clue on what the problem might be? On Thu, Sep 11, 2014 at 11:49 PM, Ranjan1018 . 21474...@gmail.com wrote: Hello, I have just upgrade my laptop, a Samsung Ativ Book 2 with an integrated Intel HD Graphics 4000, to: FreeBSD ativ.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271400: Wed Sep 10 21:40:48 CEST 2014 root@ativ.local:/usr/obj/usr/src/sys/NEWCONS amd64 Using Firefox, after some minutes, I receive the error: error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung info: [drm] capturing error event; look for more information in sysctl hw.dri.0.info.i915_error_state This error is not related to r271400, but I first saw it few months ago in current. The output of the command sysctl hw.dri.0.info.i915_error_state is: https://drive.google.com/file/d/0BzoWQoMqq1sfa0tyVGJVYVBhRnc/edit?usp=sharing After the error I am not able to run mplayer for videos: the window is black. Regards, Maurizio ___ 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 -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. ___ 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: Intel i915 GPU hung
On Thu, Sep 11, 2014 at 7:18 PM, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: I often get this on HD3000 when I push the GPU too hard.. (Well not really hard at all, but the harder I push it the sooner I get GPU crash). After the crash the desktop works fine but pure OpenGL apps don't (ie nothing shows up on the screen). I assume it has switched to software rendering(?) I'll try to get the error_state next time and post it. This is the only problem I have running FreeBSD on my Intel laptop and it is quite annoying when computer (GPU) crashes during demo for visitors and potential customers.. Anyone have any clue on what the problem might be? If possible, have you tried the SNA acceleration method? Just add Option AccelMethod sna to your device section of xorg.conf. I had GPU hung before, and after I switched to SNA, it never happened. On Thu, Sep 11, 2014 at 11:49 PM, Ranjan1018 . 21474...@gmail.com wrote: Hello, I have just upgrade my laptop, a Samsung Ativ Book 2 with an integrated Intel HD Graphics 4000, to: FreeBSD ativ.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271400: Wed Sep 10 21:40:48 CEST 2014 root@ativ.local:/usr/obj/usr/src/sys/NEWCONS amd64 Using Firefox, after some minutes, I receive the error: error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung info: [drm] capturing error event; look for more information in sysctl hw.dri.0.info.i915_error_state This error is not related to r271400, but I first saw it few months ago in current. The output of the command sysctl hw.dri.0.info.i915_error_state is: https://drive.google.com/file/d/0BzoWQoMqq1sfa0tyVGJVYVBhRnc/edit?usp=sharing After the error I am not able to run mplayer for videos: the window is black. Regards, Maurizio ___ 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 -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org -- Cheers, Henry ___ 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: Inconsistent behavior with dd(1)
Hey, any thoughts on this? Does it need more work? Can it get merged?
On 08/25/2014 09:49 PM, William Orr wrote:
On 8/18/14 12:00 PM, William Orr wrote:
Reply inline.
On 08/16/2014 10:34 AM, John-Mark Gurney wrote:
Alan Somers wrote this message on Fri, Aug 15, 2014 at 10:42 -0600:
On Thu, Aug 14, 2014 at 11:55 PM, William Orr w...@worrbase.com
wrote:
Hey,
I found some inconsistent behavior with dd(1) when it comes to
specifying arguments in -CURRENT.
[ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null
count=18446744073709551616
dd: count: Result too large
[ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null
count=18446744073709551617
dd: count: Result too large
[ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null
count=18446744073709551615
dd: count cannot be negative
[ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null
count=-18446744073709551615
1+0 records in
1+0 records out
512 bytes transferred in 0.000373 secs (1373071 bytes/sec)
[ worr on terra ] ( ~ ) % dd if=/dev/zero of=/dev/null count=-1
dd: count cannot be negative
???
Any chance someone has the time and could take a look?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191263
Thanks,
William Orr
???
IMHO, this is a bug in strtouq(3), not in dd(1). Why should it parse
negative numbers at all, when there is stroq(3) for that purpose? The
standard is clear that it must, though. Oddly enough, stroq would
probably not accept -18446744073709551615, even though strtouq does.
Specific comments on your patch below:
Here???s the patch:
Index: bin/dd/args.c
===
--- bin/dd/args.c (revision 267712)
+++ bin/dd/args.c (working copy)
@@ -186,46 +186,31 @@
static void
f_bs(char *arg)
{
- uintmax_t res;
-
- res = get_num(arg);
- if (res 1 || res SSIZE_MAX)
- errx(1, bs must be between 1 and %jd,
(intmax_t)SSIZE_MAX);
- in.dbsz = out.dbsz = (size_t)res;
+ in.dbsz = out.dbsz = get_num(arg);
+ if (in.dbsz 1 || out.dbsz 1)
Why do you need to check both in and out? Aren't they the same?
Also, you eliminated the check for overflowing SSIZE_MAX. That's not
ok, because these values get passed to places that expect signed
numbers, for example in dd.c:303.
The type of dbsz is size_t, so really:
+ errx(1, bs must be between 1 and %ju,
(uintmax_t)-1);
This should be SIZE_MAX, except there isn't a define for this? So maybe
the code really should be:
(uintmax_t)(size_t)-1
to get the correct value for SIZE_MAX...
Otherwise on systems that uintmax_t is 32bits and size_t is 32bits,
the error message will be wrong...
Yes, this should probably be SIZE_MAX rather than that cast. Same with
the others
}
static void
f_cbs(char *arg)
{
- uintmax_t res;
-
- res = get_num(arg);
- if (res 1 || res SSIZE_MAX)
- errx(1, cbs must be between 1 and %jd,
(intmax_t)SSIZE_MAX);
- cbsz = (size_t)res;
+ cbsz = get_num(arg);
+ if (cbsz 1)
+ errx(1, cbs must be between 1 and %ju,
(uintmax_t)-1);
}
Again, you eliminated the check for SSIZE_MAX, but cbsz must be signed.
What do you mean by this? cbsz is size_t which is unsigned...
I believe he's referring to this use of cbsz/in.dbsz/out.dbsz:
https://svnweb.freebsd.org/base/head/bin/dd/dd.c?revision=265698view=markup#l171
Really, this is more wrong since there is math inside of a malloc(3)
call without any overflow handling. By virtue of making this max out at
a ssize_t, it becomes more unlikely that you'll have overflow.
This math should probably be done ahead of time with proper overflow
handling. I'll include that in my next patch, if there's no objection.
I don't see any other reason why in.dbsz, out.dbsz or cbsz should be
signed, but it's very possible that I didn't look hard enough.
Again, the cast above is wrong... Maybe we should add a SIZE_MAX
define so we don't have to see the double cast...
static void
f_count(char *arg)
{
- intmax_t res;
-
- res = (intmax_t)get_num(arg);
- if (res 0)
- errx(1, count cannot be negative);
- if (res == 0)
- cpy_cnt = (uintmax_t)-1;
This is a special case. See dd_in(). I think that eliminating this
special case will have the unintended effect of breaking count=0.
- else
- cpy_cnt = (uintmax_t)res;
+ cpy_cnt = get_num(arg);
}
static void
f_files(char *arg)
{
-
Don't eliminate these blank lines.. they are intentional per style(9):
/* Insert an empty line if the function has no local
variables. */
files_cnt = get_num(arg);
if (files_cnt 1)
- errx(1, files must be between 1 and %jd,
(uintmax_t)-1);
+ errx(1, files must be between 1 and %ju,
Re: Intel i915 GPU hung
I have a feeling I tried that before but I will try it again and report back the results. I would also like to enable tear free by setting swapbufferswait and tearfree to true but when testing with glxgears I get very variable framerate and jerky animation. I don't know if this is a bug in glxgears or somewhere else... Any experience with this? -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Fri, Sep 12, 2014 at 8:46 AM, Henry Hu henry.hu...@gmail.com wrote: On Thu, Sep 11, 2014 at 7:18 PM, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: I often get this on HD3000 when I push the GPU too hard.. (Well not really hard at all, but the harder I push it the sooner I get GPU crash). After the crash the desktop works fine but pure OpenGL apps don't (ie nothing shows up on the screen). I assume it has switched to software rendering(?) I'll try to get the error_state next time and post it. This is the only problem I have running FreeBSD on my Intel laptop and it is quite annoying when computer (GPU) crashes during demo for visitors and potential customers.. Anyone have any clue on what the problem might be? If possible, have you tried the SNA acceleration method? Just add Option AccelMethod sna to your device section of xorg.conf. I had GPU hung before, and after I switched to SNA, it never happened. On Thu, Sep 11, 2014 at 11:49 PM, Ranjan1018 . 21474...@gmail.com wrote: Hello, I have just upgrade my laptop, a Samsung Ativ Book 2 with an integrated Intel HD Graphics 4000, to: FreeBSD ativ.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271400: Wed Sep 10 21:40:48 CEST 2014 root@ativ.local:/usr/obj/usr/src/sys/NEWCONS amd64 Using Firefox, after some minutes, I receive the error: error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung info: [drm] capturing error event; look for more information in sysctl hw.dri.0.info.i915_error_state This error is not related to r271400, but I first saw it few months ago in current. The output of the command sysctl hw.dri.0.info.i915_error_state is: https://drive.google.com/file/d/0BzoWQoMqq1sfa0tyVGJVYVBhRnc/edit?usp=sharing After the error I am not able to run mplayer for videos: the window is black. Regards, Maurizio ___ 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 -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org -- Cheers, Henry -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. ___ 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: Intel i915 GPU hung
First try with sna+swapbufferswait+tearfree gave me this after a while Xorg.log [ 1901.000] (EE) intel(0): sna_mode_redisplay: page flipping failed, disabling CRTC:3 (pipe=0) [ 1901.365] (EE) intel(0): sna_mode_redisplay: page flipping failed, disabling CRTC:5 (pipe=1) [ 1901.441] (EE) intel(0): Detected a hung GPU, disabling acceleration. [ 2841.578] (II) UnloadModule: mouse [ 2841.578] (II) UnloadModule: kbd [ 2841.579] (II) intel(0): switch to mode 1366x768@60.0 on pipe 0 using LVDS1, position (0, 0), rotation normal [ 2841.632] (EE) intel(0): failed to set mode: Unknown error: -22 [ 2841.632] (II) intel(0): switch to mode 1280x720@60.3 on pipe 1 using VGA1, position (0, 0), rotation normal [ 2841.683] (EE) intel(0): failed to set mode: Unknown error: -22 [ 2841.710] Server terminated successfully (0). Closing log file. messages log Sep 12 09:47:13 kernel: Sep 12 09:47:13 kernel: error: [drm:pid1488:intel_pipe_set_base] *ERROR* pin fence failed Sep 12 09:47:13 kernel: error: [drm:pid1488:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:3] Sep 12 09:47:13 kernel: error: [drm:pid1488:intel_pipe_set_base] *ERROR* pin fence failed Sep 12 09:47:13 kernel: error: [drm:pid1488:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:5] Sep 12 09:47:14 syslogd: exiting on signal 15 Unfortunately I could not access the console after this so I could not get the intel error state. Now I'm trying another run without swapbufferswait and tearfree, only sna enabled. -- Johannes Lundberg On Fri, Sep 12, 2014 at 9:29 AM, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: I have a feeling I tried that before but I will try it again and report back the results. I would also like to enable tear free by setting swapbufferswait and tearfree to true but when testing with glxgears I get very variable framerate and jerky animation. I don't know if this is a bug in glxgears or somewhere else... Any experience with this? -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Fri, Sep 12, 2014 at 8:46 AM, Henry Hu henry.hu...@gmail.com wrote: On Thu, Sep 11, 2014 at 7:18 PM, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: I often get this on HD3000 when I push the GPU too hard.. (Well not really hard at all, but the harder I push it the sooner I get GPU crash). After the crash the desktop works fine but pure OpenGL apps don't (ie nothing shows up on the screen). I assume it has switched to software rendering(?) I'll try to get the error_state next time and post it. This is the only problem I have running FreeBSD on my Intel laptop and it is quite annoying when computer (GPU) crashes during demo for visitors and potential customers.. Anyone have any clue on what the problem might be? If possible, have you tried the SNA acceleration method? Just add Option AccelMethod sna to your device section of xorg.conf. I had GPU hung before, and after I switched to SNA, it never happened. On Thu, Sep 11, 2014 at 11:49 PM, Ranjan1018 . 21474...@gmail.com wrote: Hello, I have just upgrade my laptop, a Samsung Ativ Book 2 with an integrated Intel HD Graphics 4000, to: FreeBSD ativ.local 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r271400: Wed Sep 10 21:40:48 CEST 2014 root@ativ.local:/usr/obj/usr/src/sys/NEWCONS amd64 Using Firefox, after some minutes, I receive the error: error: [drm:pid12:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung info: [drm] capturing error event; look for more information in sysctl hw.dri.0.info.i915_error_state This error is not related to r271400, but I first saw it few months ago in current. The output of the command sysctl hw.dri.0.info.i915_error_state is: https://drive.google.com/file/d/0BzoWQoMqq1sfa0tyVGJVYVBhRnc/edit?usp=sharing After the error I am not able to run mplayer for videos: the window is black. Regards, Maurizio ___ 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 -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-x11 To unsubscribe, send any mail to freebsd-x11-unsubscr...@freebsd.org
Re: Intel i915 GPU hung
On Thu, Sep 11, 2014 at 6:08 PM, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: First try with sna+swapbufferswait+tearfree gave me this after a while Xorg.log [ 1901.000] (EE) intel(0): sna_mode_redisplay: page flipping failed, disabling CRTC:3 (pipe=0) [ 1901.365] (EE) intel(0): sna_mode_redisplay: page flipping failed, disabling CRTC:5 (pipe=1) [ 1901.441] (EE) intel(0): Detected a hung GPU, disabling acceleration. [ 2841.578] (II) UnloadModule: mouse [ 2841.578] (II) UnloadModule: kbd [ 2841.579] (II) intel(0): switch to mode 1366x768@60.0 on pipe 0 using LVDS1, position (0, 0), rotation normal [ 2841.632] (EE) intel(0): failed to set mode: Unknown error: -22 [ 2841.632] (II) intel(0): switch to mode 1280x720@60.3 on pipe 1 using VGA1, position (0, 0), rotation normal [ 2841.683] (EE) intel(0): failed to set mode: Unknown error: -22 This looks off -- it's the Linux kernel error code for EINVAL (FreeBSD error codes in the kernel being positive). Cheers, -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
[PATCH] Unbreak makefs -M
r258695 introduces a sanity check for makefs in order to verify that minimum image size specified is always less than maximum image size. If makefs(1) is invoked specifying minimum image size, but not maximum one, the program exits with an error. Example: # sudo -E makefs -M 538968064 -B be /home/davide/disk.img $DESTDIR makefs: `/home/davide/tftproot/mips' minsize of 538968064 rounded up to ffs bsize of 8192 exceeds maxsize 0. Lower bsize, or round the minimum and maximum sizes to bsize. I guess it's meaningful to assert that minsize maxsize iff maxsize is actually specified. The following patch tries to fix the problem. Visual inspection of code also shows that maxsize == 0 is treated as maxsize not specified. I'm not by any means familiar with makefs(1) code, so I may miss something here. % git diff diff --git a/usr.sbin/makefs/ffs.c b/usr.sbin/makefs/ffs.c index 92d5508..83e9eae 100644 --- a/usr.sbin/makefs/ffs.c +++ b/usr.sbin/makefs/ffs.c @@ -361,7 +361,8 @@ ffs_validate(const char *dir, fsnode *root, fsinfo_t *fsopts) if (ffs_opts-avgfpdir == -1) ffs_opts-avgfpdir = AFPDIR; - if (roundup(fsopts-minsize, ffs_opts-bsize) fsopts-maxsize) + if (fsopts-maxsize 0 +roundup(fsopts-minsize, ffs_opts-bsize) fsopts-maxsize) errx(1, `%s' minsize of %lld rounded up to ffs bsize of %d exceeds maxsize %lld. Lower bsize, or round the minimum and maximum sizes to bsize., dir, -- Davide There are no solved problems; there are only problems that are more or less solved -- Henri Poincare ___ 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: [PATCH] Unbreak makefs -M
On Thu, Sep 11, 2014 at 7:16 PM, Davide Italiano dav...@freebsd.org wrote: r258695 introduces a sanity check for makefs in order to verify that minimum image size specified is always less than maximum image size. If makefs(1) is invoked specifying minimum image size, but not maximum one, the program exits with an error. Example: # sudo -E makefs -M 538968064 -B be /home/davide/disk.img $DESTDIR makefs: `/home/davide/tftproot/mips' minsize of 538968064 rounded up to ffs bsize of 8192 exceeds maxsize 0. Lower bsize, or round the minimum and maximum sizes to bsize. I guess it's meaningful to assert that minsize maxsize iff maxsize is actually specified. The following patch tries to fix the problem. Visual inspection of code also shows that maxsize == 0 is treated as maxsize not specified. I'm not by any means familiar with makefs(1) code, so I may miss something here. % git diff diff --git a/usr.sbin/makefs/ffs.c b/usr.sbin/makefs/ffs.c index 92d5508..83e9eae 100644 --- a/usr.sbin/makefs/ffs.c +++ b/usr.sbin/makefs/ffs.c @@ -361,7 +361,8 @@ ffs_validate(const char *dir, fsnode *root, fsinfo_t *fsopts) if (ffs_opts-avgfpdir == -1) ffs_opts-avgfpdir = AFPDIR; - if (roundup(fsopts-minsize, ffs_opts-bsize) fsopts-maxsize) + if (fsopts-maxsize 0 +roundup(fsopts-minsize, ffs_opts-bsize) fsopts-maxsize) - Should roundup be used with fsopts-maxsize) ? - style(9): put the `` on the previous line. errx(1, `%s' minsize of %lld rounded up to ffs bsize of %d exceeds maxsize %lld. Lower bsize, or round the minimum and maximum sizes to bsize., dir, This (and the other rev) should really be pushed back to NetBSD.. 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: [PATCH] Unbreak makefs -M
On Thu, Sep 11, 2014 at 7:26 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Thu, Sep 11, 2014 at 7:16 PM, Davide Italiano dav...@freebsd.org wrote: r258695 introduces a sanity check for makefs in order to verify that minimum image size specified is always less than maximum image size. If makefs(1) is invoked specifying minimum image size, but not maximum one, the program exits with an error. Example: # sudo -E makefs -M 538968064 -B be /home/davide/disk.img $DESTDIR makefs: `/home/davide/tftproot/mips' minsize of 538968064 rounded up to ffs bsize of 8192 exceeds maxsize 0. Lower bsize, or round the minimum and maximum sizes to bsize. I guess it's meaningful to assert that minsize maxsize iff maxsize is actually specified. The following patch tries to fix the problem. Visual inspection of code also shows that maxsize == 0 is treated as maxsize not specified. I'm not by any means familiar with makefs(1) code, so I may miss something here. % git diff diff --git a/usr.sbin/makefs/ffs.c b/usr.sbin/makefs/ffs.c index 92d5508..83e9eae 100644 --- a/usr.sbin/makefs/ffs.c +++ b/usr.sbin/makefs/ffs.c @@ -361,7 +361,8 @@ ffs_validate(const char *dir, fsnode *root, fsinfo_t *fsopts) if (ffs_opts-avgfpdir == -1) ffs_opts-avgfpdir = AFPDIR; - if (roundup(fsopts-minsize, ffs_opts-bsize) fsopts-maxsize) + if (fsopts-maxsize 0 +roundup(fsopts-minsize, ffs_opts-bsize) fsopts-maxsize) - Should roundup be used with fsopts-maxsize) ? No. Maxsize is a hard limit, while minsize is always rounded up to at least the bsize. If you attempt to specify an improperly-rounded quantity as both the minimum and the maximum (for instance, because the bsize makefs decides to use has increased between executions), you'll always produce an image which is too large. That's exactly what this check was added to catch (and make less obtuse.) - style(9): put the `` on the previous line. errx(1, `%s' minsize of %lld rounded up to ffs bsize of %d exceeds maxsize %lld. Lower bsize, or round the minimum and maximum sizes to bsize., dir, This (and the other rev) should really be pushed back to NetBSD.. 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: Intel i915 GPU hung
Now with only sna enabled (which I think I read somewhere should be the default and that's why I didn't enable it before) I got GPU hung again. uname -a: FreeBSD bsd 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 r...@snap.freebsd.org:/usr/ obj/usr/src/sys/GENERIC amd64 dmesg, error_state, pciconf, pkginfo and Xorg.0.log can be downloaded here https://dl.dropboxusercontent.com/u/10335306/GPU_hung_logs.zip -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Fri, Sep 12, 2014 at 10:14 AM, Garrett Cooper yaneurab...@gmail.com wrote: On Thu, Sep 11, 2014 at 6:08 PM, Lundberg, Johannes johan...@brilliantservice.co.jp wrote: First try with sna+swapbufferswait+tearfree gave me this after a while Xorg.log [ 1901.000] (EE) intel(0): sna_mode_redisplay: page flipping failed, disabling CRTC:3 (pipe=0) [ 1901.365] (EE) intel(0): sna_mode_redisplay: page flipping failed, disabling CRTC:5 (pipe=1) [ 1901.441] (EE) intel(0): Detected a hung GPU, disabling acceleration. [ 2841.578] (II) UnloadModule: mouse [ 2841.578] (II) UnloadModule: kbd [ 2841.579] (II) intel(0): switch to mode 1366x768@60.0 on pipe 0 using LVDS1, position (0, 0), rotation normal [ 2841.632] (EE) intel(0): failed to set mode: Unknown error: -22 [ 2841.632] (II) intel(0): switch to mode 1280x720@60.3 on pipe 1 using VGA1, position (0, 0), rotation normal [ 2841.683] (EE) intel(0): failed to set mode: Unknown error: -22 This looks off -- it's the Linux kernel error code for EINVAL (FreeBSD error codes in the kernel being positive). Cheers, -Garrett -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. ___ 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
