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 wrote: > On Thu, Sep 11, 2014 at 6:08 PM, Lundberg, Johannes > 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"
Re: [PATCH] Unbreak makefs -M
On Thu, Sep 11, 2014 at 7:26 PM, Garrett Cooper wrote: > On Thu, Sep 11, 2014 at 7:16 PM, Davide Italiano > 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: [PATCH] Unbreak makefs -M
On Thu, Sep 11, 2014 at 7:16 PM, Davide Italiano 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"
[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: Intel i915 GPU hung
On Thu, Sep 11, 2014 at 6:08 PM, Lundberg, Johannes 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"
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 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
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 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: 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
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=265698&view=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
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: 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: [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: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov 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: 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: 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"
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"
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"
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
Re: UEFI boot failure: BIOS smap did not include a basemem segment!
On 10 September 2014 15:00, Jean-Sébastien Pédron 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: 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 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 wrote: > >> On 05.09.14 19:37, John Nielsen wrote: >>> On Sep 5, 2014, at 11:30 AM, Glen Barber 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%2F&ts=1410181876&use_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@
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: [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"
