Johnny Billquist writes:
> Ok. I oversimplified.
>
> If I remember right, the point was that something sub 200ms is perceived
> by the brain as being "instananeous" response. It don't mean that one
> cannot discern shorter times, just that from an action-reaction point of
> view, anything below
> > try "options DB_MAX_LINE=0" in your kernel?
>
> Right. Unfortunately that fails the "without having to rebuild the
> kernel" requirement :-)
another option would be to use say, gdb :-), to change the value of
the "db_max_line" variable from default of 24 to 0, and then boot
that modified
Andrew Cagney writes:
> > > thanks, I'll add that (it won't help with my immediate problem of a
> > > panic during boot though)
> >
> > From DDB command prompt "set $lines = 0" ...
>
> Um, the test framework's VM is stuck waiting for someone to hit the
> space bar :-)
>
> I guess I could modify my
ah, i am reminded of this channge that went in recently:
https://mail-index.netbsd.org/source-changes/2023/11/06/msg148463.html
can you try a -current snapshot and see if it works less badly?
.mrg.
some random ideas/info about this, no real help yet.
Josh Moyer writes:
> I hacked kern/init_main.c to panic on line 739 before the display goes dark
> and the last two dmesgs are:
>
> pci_mem_find: void region (dev/pci/pci_map.c)
hmm, this one happens when the mapping size is 0. can you post
> By now I think we should just delete sys/external/bsd/drm; it has been
> unmaintained for so long it is unlikely to work. If there's interest
> in the legacy UMS drivers, they should all still be in the drm2 tree
> and can be adapted like I did with viadrmums. But I have no hardware
> for most
have we considered checking in tiny binaries actually built for
the emulation and using them?
various methods discussed so far have their own advantages, but
this is the only way that tests actual binaries built for eg
linux and run with compat_linux. anything else is limited in
it's ability to
> Reading symbols from /usr/libdata/debug//usr/lib/libm.so.0.12.debug...
> (No debugging symbols found in
> /usr/libdata/debug//usr/lib/libm.so.0.12.debug)
> Reading symbols from /usr/lib/libc.so.12...
> Reading symbols from /usr/libdata/debug//usr/lib/libc.so.12.220.debug...
> (No debugging
> This completed apparently normally, reporting the build directory and
> telling me to remember to make depend. I then went to ~/kbuild/GEN91
> and ran make depend && make. It failed fast - no more than a second or
> two - with
>
> make[1]: don't know how to make absvdi2.c. Stop
what happens
matthew green writes:
> hmm, someone seems to have broken this recently? on my system
> i'm seeing cpu0 and cpu16 both reporting:
>
>cpu0: SMT ID 0
>cpu16: SMT ID 0
duh. this is user error. it also said:
Cannot bind to target CPU. Output may not accurately desc
> we just did that).I guess we could look and skip the update on
> the hyperthread companion cores (pseudo-cores) but that's not what I am
> proposing, partly because I'd have to work out how to do that, but also
> because that by itself would only solve half the problem.
we should do this as
your change seems to fix a clear but to me.
> - if (*bmajor < 0)
> + if ((bdev != NULL) && (*bmajor < 0))
> *bmajor = conv->d_bmajor;
there's also this line i'm curious about, just below:
if (*bmajor != conv->d_bmajor || *cmajor !=
> dd if=/dev/urandom bs=65536 of=/dev/mem
FWIW, secururelevel > 0 fixes this issue. so, perhaps you
can rephrase by including something about correct separation
of privs, since root write-access to /dev/mem is literally
giving it kernel-level privs.
.mrg.
hi folks.
i saw a report about ghc94 related crashes, and while it's easy
to build ghc94 itself, it's easy to trigger a crash by having
packages use it. for me 'pandoc' wants a bunch of hs-* pkgs and
i had crashes in 2 separate ones.
i added some addditional logging to the failed assert to
> 9.597827] wsdisplay0 at nouveaufb0 kbdmux 1: console (default, vt100
> emulation), using wskbd0
what's the pci device? (ie, what's the card? or at least, what's
the chipset the pci id claims -- flashed cards can have a different
pci id than reality and drivers work because they check
are you trying to trim a really large section at once? i
think that's what i see:
> [ - root] 3> date; ./trim /dev/rwd1d 4 2; date
at least in my experience, the problem is that most devices
take a while to handle a TRIM request, longer than the 30s
timeout typically used.
this is why
it seems that pcc is missing '#pragma once' support. at least,
the version in src.
ragge, can you fix it? :-) thanks.
.mrg.
i am a fan of #pragma once. the main reason is that it avoids
the class of bugs where you copy a header and forget to change
the #define and then sometimes the header is empty upon use,
and you end up having to use cpp output to debug it.
i'd be ok with using it anywhere -- AFAIK the compiler
i really like this except for the if () do { ... } while (0); else
abuse portion. please rework that part. it looks easiest to push
into a separate function, perhaps.
thanks.
.mrg.
> However, I wonder why this kind of info is embedded in ELF files, what
> point does that have? Maybe it would be better to have them just say
> x.99 (and forget the kernel ABI bump number) ?
i would rather keep the info. i use it as a quick check of
whether i reinstalled recently or not.
this should be fixed now. be sure to have usbnet.c 1.112.
.mrg.
> I got two off-list mails suggesting LOCKDEBUG. I tried that today -
> I added LOCKDEBUG and VNODE_LOCKDEBUG both (the latter I found in the
> ALL config when grepping for LOCKDEBUG).
>
> That kernel panicked promptly on boot
>
> panic: vop_read: vp: locked 0, expected 1
just use LOCKDEBUG for
> But it's less a lack of interest and more an unwillingness to ignore
> the licensing issues. `Modern' GCC is licensed under the GPLv3. I
try clang, which usually has newer/better sanitizers.
hi folks.
i recently changed the evbmarm/fdt code to avoid forcing the
'booted_device' to be set to something if it was already set
(in that case, by the raidframe "soft root" code).
i surveyed all the cpu_rootconf() implementations. there are
a lot, some are fixed but many are not.
i'm not
matthew green writes:
> "J. Hannken-Illjes" writes:
> > I'm now able to reproduce it here -- takes about six hours to trigger.
> >
> > I suppose vrelel() lost a check for new references with my last changes,
> > currently testing the diff attached.
>
"J. Hannken-Illjes" writes:
> I'm now able to reproduce it here -- takes about six hours to trigger.
>
> I suppose vrelel() lost a check for new references with my last changes,
> currently testing the diff attached.
well, this ran until i ran out of file building the native gcc,
it had been
that's this:
175 vmcmd_map_pagedvn(struct lwp *l, struct exec_vmcmd *cmd)
176 {
[ ... ]
181 vm_prot_t prot, maxprot;
182
183 KASSERT(vp->v_iflag & VI_TEXT);
christos said this happened to him on a 8c/16t 64GB machine, using
build.sh -j40, and i was able reproduce it on a 6c/12th
while rebooting a quartz64 with a usb attached disk that just
had a about 3.5GB of data written to it, i the umass gave some
errorse and then i got a panic shortly later:
[ 5869.8702963] unmounting 0x0001f9fdb000 /mnt (/dev/sd1a)...
[ 5879.8716525] umass1: Invalid CSW: tag 0 should be 428938
it seems to me that if some driver depends upon altq, then
altq should simply always refuse to unload if a driver is
loaded that depends upon it. this should be an explicit
dependency, and probably implicit via symbols.
if, say there's a fully modular system with two NICs, and
only one of them
> I propose that we deprecate or remove the "extsrc/" tree,
> as the name name-complete conflicts with "external/".
yes, please.
.mrg.
Riza Dindir writes:
> Hello All,
>
> Finally... I was able to enable and use my Kaveri device
> (0x1002/0x1309), at the end. It is using the external monitor and is
> using the correct 1440x900 resolution. This is very nice.
>
> There is one thing that I would like to ask.
>
> There is a
> I am trying to make the radeonr7 m265 display device to work on NetBSD
> 9.2 (amd64). In the radeon_bios.c file there is a definition used,
> named CONFIG_ACPI. Some functions are using this definition. I want to
> enable this. Where can I do this? In the configuration file (GENERIC
> for
Riza Dindir writes:
> Hello
>
> I am using NetBSD 9.2 (amd64). Am trying to make the radeon driver work.
>
> In the file "sys/external/bsd/drm2/dist/drm/radeon/radeon_cik.c",
> there is a reference to a kaveri_mec2.bin file. But this file is not
> present in the "src/sys/dev/microcode/radeon/"
> > a full dmesg might also be useful -- might help identify what
> > else has mapped this. (perhaps vga@something.)
>
> Tha is probably I did not hava a bus_space_unmap in my code. And since
> the system finds two radeon devices one is (0x1002, 0x1309) and the
> other is (0x1002, 0x6604) it is
> I am using NetBSD 9.2 (amd64). I have a laptop that has a radeon r7
> m265 video card (vendor 0x1002, product 0x6604). The system does not
> recognize this card. It fails with this message:
are you booting uefi or bios?
sometimes modern systems don't work properly with bios and gpus,
not being
this looks good. thanks for doing it.
> Comments:
> Switched to a single MK tunable for it - that is probably unneeded.
> Might be an issue for not obsoleting directories on non-DRM archs.
please put back the separate firmwares -- there are x86-only
ones coming so we want to be able to choose
i like it.
> Index: sys/sys/un.h
> ===
> RCS file: /cvsroot/src/sys/sys/un.h,v
> retrieving revision 1.59
> diff -u -r1.59 un.h
> --- sys/sys/un.h 6 Nov 2020 14:50:13 - 1.59
> +++ sys/sys/un.h 5 Aug 2021 13:19:20
i'm not sure, but i'm guessing that it happens here:
audio.c:2491: error = fd_clone(fp, fd, flags, _fileops, af);
audio.c:3541: error = fd_clone(fp, fd, flags, _fileops, af);
audio.c:8167: error = fd_clone(fp, fd, flags, _fileops, af);
with
> @@ -146,8 +146,10 @@
> {
> extern int kern_logsigexit; /* defined in kern/kern_sig.c */
> extern fixpt_t ccpu;/* defined in kern/kern_synch.c */
> extern int dumponpanic; /* defined in kern/subr_prf.c */
> + extern int maxlocksperuid; /*
Brian Buhrow writes:
> hello David. What I don't see in your proposal is a way of
> implementing a dynamic device
> filesystem. NetBSD, and possibly OpenBSD, are the last Unix-like OS's that
> I'm aware of that
> use static special files in their filesystems to point to devices. If your
> > Me too. I was - am - rather puzzled by it.
>
> Right. That was my issue. Claiming that you'd get more problems with
> rounding and issues with coarsness when running at a higher frequency,
> when it in fact is the exact opposite. With a higher frequency you have
> more accuracy and less
Manuel Bouyer writes:
> On Wed, May 26, 2021 at 05:35:53PM +1000, matthew green wrote:
> > Manuel Bouyer writes:
> > > On Tue, May 25, 2021 at 10:46:04PM -, Michael van Elst wrote:
> > > > bou...@antioche.eu.org (Manuel Bouyer) writes:
> > > >
>
Manuel Bouyer writes:
> On Tue, May 25, 2021 at 10:46:04PM -, Michael van Elst wrote:
> > bou...@antioche.eu.org (Manuel Bouyer) writes:
> >
> > >Another issue could be mstohz() called with a delay too short;
> > >mstohz() will round it up to 1 tick.
> >
> >
> > # define mstohz(ms)
> > +optionsHZ=8000
this can become a problem due to integer division.
any number of ticks less than hz (8000) will be rounded
down to 0 in a number of places now, where as before it
was only less than 100. i've seen this trip up in the
kernel before, and sometimes that '0' means 'poll',
> > It was REALLY obvious that there was a lot of blind copy-pasta
> > lurking around as I audited everything.
>
> I appreciate the work you did to audit this! But we should make it
> easier, not harder, for the compiler to audit mistakes if we're going
> to make tree-wide changes; this appears
> Thanks for the idea - however machdep.user_ldt was already 0 :-(
>
> I'll pull the older sources and try and find the change which caused the
> problem
oops! i meant to say "=1".
Dave Tyson writes:
> I have wine 4.4 working under NetBSD 9.99.23 amd64 (> 1 year ago) and
> recently
> tried against a recent current - 9.99.81.
>
> Wine now complains:
> i386_set_ldt: Operation not permitted
> Did you reconfigure the kernel with "options USER_LDT"?
>
> but GENERIC has the
one additional thing about the behaviour of vm.*{min,max}
is that they do not (currently?) consider how much memory
is consumed by major kernel consumers like pools. eg, there
is a known radeondrmkms leak we have not figured out why it
happens only sometimes, and this ends up making the kmem-160
> In this particular example server it's in a Dell R510 with a pair of
> 6-core E5645 CPUs that "cpuid" shows the following for (in the dom0):
this is a westmere-ep CPU, which does not support rdseed
or rdrand. rdrand appeared in ivybridge (2 generations
later, with sandybridge in the middle.)
hi folks.
while we were debugging some memory starvation issues i noticed that
the "kmem-02048" pool only has 1 item per page on a system with 4KiB
pages, same similarly "kmem-04096" on 8KiB page systems. i assume
this also occurs on 16KiB page systems for the "kmem-08192" pool.
this happens
> [ 1.03] cpu0: Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz, id 0x506e3
[ .. ]
> [ 7.099124] warning:
> ../../../../external/bsd/drm2/dist/drm/i915/i915_drv.c:591:
> WARN_ON(!IS_KABYLAKE(dev_priv))kern info: [drm] Memory usable by graphics
> device = 4096M
this is odd. it indicates
> @@ -395,9 +401,8 @@ pipeunlock(struct pipe *pipe)
> KASSERT(pipe->pipe_state & PIPE_LOCKFL);
>
> pipe->pipe_state &= ~PIPE_LOCKFL;
> - if (pipe->pipe_state & PIPE_LWANT) {
> - pipe->pipe_state &= ~PIPE_LWANT;
> - cv_broadcast(>pipe_lkcv);
> + if
Kamil Rytarowski writes:
> Switch the last user (ypserv) from CIRCLEQ to TAILQ.
> This is inspired by analogous refactoring from OpenBSD:
> https://github.com/openbsd/src/commit/d53c0cf4d32fdbd8b42debfba068f1b0efa423dc#diff-8d0a4fbb89658213ebf314ff188581d7
>
> Remove the CIRCLEQ API completely
Reinoud Zandijk writes:
> On Wed, Sep 16, 2020 at 12:09:43PM +0200, Martin Husemann wrote:
> > On Wed, Sep 16, 2020 at 12:05:26PM +0200, Anthony Mallet wrote:
> > > I was also wondering if it would be possible to pass arguments to the
> > > primary or secondary bootloader via reboot(2) and the
> By the way, I'm not so familiar to sparc.
> audioamd(4) has many assembly code (though they look very old stuff).
> Is there any (historical or traditional) reason why I should not
> remove these?
i would just ignore it. it's currently unused and if someone
wants to fix it up, it's sitting
Jason Thorpe writes:
> From my reading of the code, it seems that there are no longer any
> circumstances where pmap_activate() will be called with non-curlwp, at
> least in MI code.
>
> Is this a correct reading?
seems right, and only vax has one MD caller that appears to
not be curlwp but
> On 20-07-12 10:01, Luke Mewburn wrote:
> | I propose that the NetBSD C style guide in to /usr/share/misc/style
> | is reworded to more explicitly permit braces around single statements,
> | instead of the current discourgement.
> |
> | IMHO, permitting braces to be consistently used:
>
i'm not very interested in a solution that doesn't use tools
available to the build. you've not shown that there is
sufficient pain here to force an external solution. i'm not
sure i buy your claims about awk and size of program. IME,
it just requires that one is strict to rules.
if you want
glad to see this effort and the clean up already!
ideally, we can break the kernel build if large stack consumers
are added to the kernel. i'd be OK with it being default on,
with of course a way to skip it, and if necessary it can have
a whitelist of "OK large users."
> 1264cdioctl at
what's the use-case for disabling encrypted swap later?
i'd argue we should avoid kauth for this and simply disable
it always as i've been unable to think of any use case that
is the only solution.
.mrg.
have you looked at xrandr? you may be able to just run
xrandr --auto after connecting the display, or you can
explicitly ask for a mode with it with --output
--mode .
.mrg.
> This reminds me that we need to find a way to release upper layer
> vnodes when the lower layer is recyclable -- see the comment in
> layer_inactive. Otherwise files deleted under a null mount while open
> through the null mount may persist on disk indefinitely as long as the
> upper layer is
> > Nonsense, I think it's fair to classify that as a bug. That sort of
> > stuff is *not* supposed to happen if -ffreestanding is passed to the
> > compiler.
>
> If we use 0x0, it can be a valid pointer.
>
> If we use NULL, it's not expected to work and will eventually generate a
> syntax
> It seems to me the proper approach is to teach the tool to accept
> this, and to avoid cluttering the tree with churn to work around the
> tool's deficiency, unless there's actually a serious compelling
> argument -- beyond a language-lawyering troll -- that (char *)NULL + 0
> is meaningfully
Jarom?r Dole?ek writes:
> Le lun. 17 f=C3=A9vr. 2020 =C3=A0 17:55, matthew green =
> a =C3=A9crit :
> >
> > FWIW, i've been running my radeon with a patch that exlicitly drops
> > kernel lock around the "real attach" function (the one that config
> > mount
FWIW, i've been running my radeon with a patch that exlicitly drops
kernel lock around the "real attach" function (the one that config
mountroot ends up calling.)
we really need to MPSAFE-ify the autoconf subsystem. right now, it
is expected that autoconf runs with kernel lock... i am not sure
> As far as I can tell, there are many races caused by autoloading.
i have long advocated that we should turn off both
module autoload and autounload, as they're security
and reliability nightmares.
*perhaps* autoload, for a specific list of known OK
modules would be OK in the default for me,
Andreas Gustafsson writes:
> matthew green wrote:
> > [misread everything]
ah, please go ahead.
.mrg.
Andreas Gustafsson writes:
> Hi all,
>
> I have this patch to replace the debug printfs in sys/dev/usb/if_urtwn.c
> by usbhist calls, roughly modelled after the use of usbhist in if_axe.c:
>
> https://www.gson.org/netbsd/patches/urtwn-usbhist.patch
>
> OK to commit?
this looks fine, but if
_always()?
> - If we do not want to stick with the C11 API (its emulation), then I
> would suggest to use the similar terminology, e.g. atomic_load_relaxed()
> and atomic_store_relaxed(), or Linux READ_ONCE()/WRITE_ONCE(). There is
> no reason invent new terminology; it might just add more confusion.
i
> Yes, we will - but can't we make that something detectable? If the
> kernel invents a lael, it says "fictitious" in the label field.
i had a similar idea, and i like your "converted" idea too.
i was looking at struct disklabel itself, and while i realised
we could probably abuse d_subtype to
> Comments?
i like the clean up. it's clearly a step forward.
i only don't understand why 32 bit platforms can't handle
large values here but 64 bit ones can. is it only so that the
32 bit platforms don't use 64 bit maths when it's not needed?
it just seems wrong to me to limit 32 bit
> Does anyone have any comments on this plan?
yes, please.
.mrg.
Emmanuel Dreyfus writes:
> Generally speaking, does anyone see any usage fpr GPT and RAIDframe
> support, or multiboot 2 support for dosboot, pxeboot and netboot? If
> not, we could disable the features for that boostraps, which would
> save space for later.
i use raidframe and gpt with pxeboot.
not really commenting on the proposal itself, but ..
> Let us not forget that you need a binary inside the chroot that can
> call fexecve() on a file descriptor or the ability to build such a
> binary.
this is only one buffer overflow away... ie, strength in
layers would imply you should not
> No performance cost, because these guarded buffers are allocated only when the
> pools grow, which is a rare operation that occurs almost only at boot time. No
> actual memory consumption either, because unmapped areas don't consume
> physical
> memory, only virtual, and on 64bit arches we have
> /*
> * The next two structures are marked "__packed" as they normally end up
> * being padded in 64-bit mode.
> */
> struct netbsd32_vnd_ioctl {
> netbsd32_charp vnd_file; /* pathname of file to mount */
> int vnd_flags; /* flags; see below */
>
hi folks.
i recently fixed a bunch of problems in several usb ethernet
drivers and there's a lot of copied code among them.
to avoid this i wrote this patch which introduces a common
library for usb ethernet drivers and converts if_axen.c to
use it. these are the areas handled:
- USB
> Introduce a simple COREDUMP_MACHDEP_LWP_NOTES logic to provide machdep
> API for injecting per-LWP notes into coredumps, and use it to append
> PT_GETXSTATE note.
this macro is pretty gross. these are the problems i see:
- assumes 'int error'
- assumes 'struct lwp *l = curlwp'
- assumes
i fully support making debugging work. that means debugging
32 bit apps on 64 it kernels, and also, eventually?, using
a 32 bit debugger on 64 bit kernel.
these are all real-world cases people use and expect to work.
thanks.
.mrg.
> Ok, thanks, I've fixed it and the machine shuts down correctly now.
i saw the commit - thanks for making it better.
> However there seem to be other problems in the attach/detach. ehci_init()
> and ehci_detach() are not symmetrical, the former initializes more stuff
> than the latter
> Do we really expect module updates without updating kernel
> to work?
>
> If yes will do iot next time.
yes - if you add, not just change, to the kernel abi in a way
that modules will notice, please bump the version. it should
make this sort of problem more obvious (due to missing file
errors,
thanks for working on this.
> + case PT_FIRSTMACH + 0:
> + return PT_STEP;
> + case PT_FIRSTMACH + 1:
> + return PT_GETREGS;
[ ... ]
these magic numbers are a little ugly. can you avoid them?
is there a way to have amd64 have direct access to the i386
values?
>
> So here's our deadlock: cpu 0 holds the kernel lock and wants the pool spin
> mutex; cpu 1 holds the spin mutex and wants the kenrel lock.
AFAICT, cpu 1 is at fault here. this locking order is
backwards.
not sure why arm32 pmap operations on the kernel map are
with the kernel lock instead of
Iain Hibbert writes:
> On Thu, 28 Feb 2019, Masanobu SAITOH wrote:
>
> > I'd like to get new number for new ioctl. How should I find unused number
> > for it? I'm going to add new SIOCXXX. It may not enough to grep sys/net/*.h,
> > so I made usr.bin/kdump-ioctl.c and did
> >
> > grep \'i
> This might be FAQ...
>
> I'd like to get new number for new ioctl. How should I find unused number
> for it? I'm going to add new SIOCXXX. It may not enough to grep sys/net/*.h,
> so I made usr.bin/kdump-ioctl.c and did
>
> grep \'i kdump-ioctl.c | sort -n -k 5,5 | uniq | column -t
>
> > On Feb 23, 2019, at 4:04 PM, matthew green wrote:
> >
> > i like this. the current API is ... odd.
>
> Oh any thoughts on have intrsafe or not?
if we can get away without it, that would be best. how hard is
the single(?) caller to fix? :-)
.mrg.
i like this. the current API is ... odd.
can you add alignment documentation? eg, if only to say that it
must support aligned or unaligned accesses for the relevant
datatypes. not sure what we need currently, ie, if unaligned is
needed because that happens today, or we can define it as wrong
> The only different is that my GENERIC has DEBUG and LOCKDEBUG... And as
> you can see from the command line, there is
> -Wno-error=implicit-fallthrough
hmmm.. is this being missed some how?
> cat conf/copts.mk
# $NetBSD: copts.mk,v 1.3 2019/02/10 05:01:59 mrg Exp $
# MI per-file
> I am not sure if the following is correct, so I am posting it here instead
> of committing...
see my post to source-changes-d -- most of these should
be ignored for warings already, so i'm curious why you
had to fix them.
wrt what is correct, i found several fixes needed by our
copy of
> >>> @@ -472,6 +472,9 @@
> >>> const char *bootname = device_xname(bdv);
> >>> size_t len = strlen(bootname);
> >>>
> >>> + if (bdv == NULL)
> >>> + return 0;
> >>> +
> >>
> >> This looked suspicious, even before I read the code.
> >>
> >> The question is if it is ever legitimate for
> > @@ -472,6 +472,9 @@
> > const char *bootname = device_xname(bdv);
> > size_t len = strlen(bootname);
> >
> > + if (bdv == NULL)
> > + return 0;
> > +
>
> This looked suspicious, even before I read the code.
>
> The question is if it is ever legitimate for bdv to be
i will have a look at the audioplay changes in the next week.
.mrg.
> | for xhci, all of these seem to be the same issue and it
> | appears to be a "high level allocator doesn't know what
> | it is allocating and does not align properly". the
> | problem is likely:
> |
> | #define XHCI_TRB_ALIGN 16
> | struct xhci_trb {
> | ...
> | } __packed
> http://netbsd.org/~kamil/kubsan/0007-boot-real-hardware.txt
for xhci, all of these seem to be the same issue and it
appears to be a "high level allocator doesn't know what
it is allocating and does not align properly". the
problem is likely:
#define XHCI_TRB_ALIGN 16
struct xhci_trb {
...
}
> Of course larger transfers would also mitigate the overhead for each I/O
> operation, but we already do several Gigabyte/s with 64k transfers and
> filesystem I/O tends to be even smaller.
yes - the benefits will be in the 0-10% range for most things. it
will help, but only a fairly small
hi folks.
my laptop has been crashing in i915 the last few days and we finally
tracked down the cause. cv_wait_sig() can return ERESTART, which has
the value of -3. when linux code returns errors it often does it
encoded in a pointer, and in the low negative range, so typically a
return value
Christos Zoulas writes:
> In article <3af3b7c6-d34e-471d-8cf8-a411e9032...@me.com>,
> Jason Thorpe wrote:
> >While I agree that it’s not exactly difficult to maintain the a.out
> >exec package, I do wonder if there is anyone out there actually running
> >ancient a.out binaries.
>
> Well, I
Jason Thorpe writes:
> ...and while we're talking about "questionable utility"...
>
> COMPAT_AOUT_M68K, COMPAT_M68K4K, and COMPAT_VAX1K are merely exec glue
> (well, mostly; COMPAT_AOUT_M68K has some ancient stat()-related
> emulation) for what are, at this point, ridiculously old a.out
1 - 100 of 414 matches
Mail list logo
