Re: pageout question

on 25/07/2010 02:31 RW said the following: > On Sat, 24 Jul 2010 23:23:07 +0300 > Andriy Gapon wrote: > >> There is a good deal of comments in the vm_pageout.c code that imply >> that we use a hysteresis approach to deal with low available pages >> condition. >>

Re: pageout question

on 25/07/2010 16:41 RW said the following: > On Sun, 25 Jul 2010 13:07:21 +0300 > Andriy Gapon wrote: > >> on 25/07/2010 02:31 RW said the following: > >>> As I understand it the hysteresis is done inside vm_pageout_scan, >>> and the expectation is that

Re: pageout question

on 25/07/2010 23:28 RW said the following: > On Sun, 25 Jul 2010 17:19:41 +0300 > Andriy Gapon wrote: > >> on 25/07/2010 16:41 RW said the following: > >>> In FreeBSD the inactive queue contains disk cache pages which >>> normally provide most of the c

Re: pageout question

on 25/07/2010 23:43 Andriy Gapon said the following: > on 25/07/2010 23:28 RW said the following: >> I didn't say it say it was guaranteed. I just think the scenario where >> a first pass ends up between the watermarks is rare. And when it >> happens I don't see

Re: pageout question

;t reach the high watermark, then we are in a high pressure situation and so we would have to do some heavy-lifting anyways. In my opinion, it's better to start doing more work at once than trying to pretend that situation would somehow resolve itself. -- Andriy Gapon

Re: coherence-problem on the mapped memory buffer

eeBSD/SMP: 4 package(s) x 2 core(s) > ... > > 2. uname -v > FreeBSD 9.0-CURRENT #3 > > 3. sysctl kern.osreldate > kern.osreldate: 900014 > > 4. //depot/projects/soc2010/ringmap/ No help, but just curious - do use amd64 variant? If yes, can you reproduce the problem wi

Re: coherence-problem on the mapped memory buffer

on 29/07/2010 19:13 Andriy Gapon said the following: > on 29/07/2010 17:13 Alexander Fiveg said the following: >> P.S. Details about hardware and used software: >> 1. /var/run/dmesg.boot : >> ... >> CPU: Dual Core AMD Opteron(tm) Processor 865 (1800.01-MHz

Re: coherence-problem on the mapped memory buffer

on 29/07/2010 19:45 Alexander Fiveg said the following: > On Thursday 29 July 2010 18:13:23 Andriy Gapon wrote: >> on 29/07/2010 17:13 Alexander Fiveg said the following: >>> P.S. Details about hardware and used software: >>> 1. /var/run/dmesg.boot : >>> .

Re: coherence-problem on the mapped memory buffer

on 29/07/2010 23:02 Sergey Babkin said the following: > Jul 29, 2010 12:58:07 PM, a...@icyb.net.ua wrote: > >> on 29/07/2010 19:13 Andriy Gapon said the following: >>> on 29/07/2010 17:13 Alexander Fiveg said the following: >> In fact I have a suspicion that the pr

Re: coherence-problem on the mapped memory buffer

for way to change caching type for a memory mapping 4. hope that more knowledgeable people (experts) provide their advice, keep nudging them via mailing list(s) :-) -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/

Re: Winbond Watchdog [Was Re: Supermicro BIOS's watchdog feature?]

f Super I/O chips. http://people.freebsd.org/~avg/w83977.diff There are quite a few possibilities about how this chip could be wired and programmed (e.g. watchdog output may go to any of three multifunctional pins), but I really implemented only one configuration (the one that I actually

uma: zone fragmentation

uff */ freei = ((unsigned long)item - (unsigned long)slab->us_data) Unfortunately I don't have any conclusive results to report. The numbers seem to be better with the patch, but they are changing all the time depending on system usage. I couldn't think of any good test that wo

uma_zcreate: additional arg for uminit/fini

kmem_cache: http://docs.sun.com/app/docs/doc/816-5180/kmem-cache-create-9f?a=view -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-uns

ZFS arc_reclaim_needed: better cooperation with pagedaemon

d) "lime" color - v_free_count+v_cache_count indeed :) Y axis - % of total page count. I think the graphs speak for themselves. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: ZFS arc_reclaim_needed: better cooperation with pagedaemon

g http://people.freebsd.org/~avg/pages.png http://people.freebsd.org/~avg/arc3.png What do you see? What do you think? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe,

Re: ZFS arc_reclaim_needed: better cooperation with pagedaemon

r my taste). The fragmentation is too high and very significant portion of memory is effectively lost to it. E.g. ARC may think that it uses only 1GB but another 1GB is used by free items in ZFS zones (of 4GB total). -- Andriy Gapon ___ freebsd-

Re: kld modules remain loaded if MOD_LOAD handler returns an error

> The MOD_LOAD handler is called from a SYSINIT, and there's no >> immediately obvious way to pass information about the failure from the >> SYSINIT to the kernel linker. Anybody have any thoughts on this? > > Yeah, it's not

Re: Debugging Loadable Modules Using GDB

ld work too [see relation between add-*symbol*-file and .ko.*symbols* ? :-) ] -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: System freezes unexpectly

gt; > -- >>> > Glen Barber >>> > >> Tried doing this. But no output. > > Try recompiling the port with the option for debug enabled. That'll get you > some > output. :) Guys asking questions about firefox, etc, why do you do that? :) Did you mis

Re: Debugging Loadable Modules Using GDB

d debug info without > loading the .kld file ? As I've already suggested the symbols are in *.symbols files. If you have those then they should be loaded automatically, as John has suggested. If you don't have them, then arrange to hav

minidump: a hack to prevent vm_page_dump bitmap change during dumping

= pa & 63; + vm_page_dump[idx] |= 1ul << bit; +} + +void +dump_drop_page_priv(vm_paddr_t pa) +{ + int idx, bit; + + pa >>= PAGE_SHIFT; + idx = pa >> 6; /* 2^6 = 64 */ + bit = pa & 63; + vm_page_dump[idx] &= ~(

Re: minidump: a hack to prevent vm_page_dump bitmap change during dumping

on 03/09/2010 19:10 Matthew Jacob said the following: > You can do it this way, but IMO, the best thing to do is to when you're > panicing > stop all other CPUs. Entirely agree, that's the way it should be handled. Unfortunately, all I could come up with was the patch that I

zfs + uma

e size, but not multiple of page size. Internally they would still consume multiple of page size per item, so we potentially can have two zones that use the same number of pages per zone, but with different item size. With the patch they are collapsed into a single zone. -- Andriy Gapon diff --g

Re: zfs + uma

less. This kind of flexibility seems like a very good idea. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

KDB_TRACE and no backend

i = 0; i < st.depth; i++) + printf("#%d %p\n", i, (void*)(uintptr_t)st.pcs[i]); } } -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: zfs + uma

t, just in case, this thread is not about fragmentation, it's about per-cpu buckets, number of items in them and size of the items. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: zfs + uma

: small items vs huge items. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: KDB_TRACE and no backend

B. Thank you for the tip! BTW, why is this under an option? It seems like something like this won't add much to kernel size and won't affect performance at all. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.o

Re: KDB_TRACE and no backend

on 18/09/2010 21:41 Andriy Gapon said the following: > on 18/09/2010 21:26 Attilio Rao said the following: >> >> You have to eventually wrap this logic within the 'STACK' option >> (opt_stack.h for the check) because stack_save() will be uneffective >> otherwi

Re: KDB_TRACE and no backend

on 18/09/2010 22:00 Andriy Gapon said the following: > Oh, wow, and I totally overlooked stack_print(). > Should have read stack(9) from the start. New patch. Hope this is better. I don't like that the printf is duplicated, but couldn't figure out a way to combine pre-processor

Re: KDB_TRACE and no backend

long as it offers the backend, but with your change it is a global > functionality. Not sure if it worths changing it but however you may > have more opinions). It seems that we don't have kdb(4) ? -- Andriy Gapon ___ freebsd-hackers@f

Re: zfs + uma

would be happy to review patches from anyone who wishes to undertake it. FWIW, the approach of simply limiting maximum bucket size based on item size seems to work rather well too, as my testing with zfs+uma shows. I will also try to add code to completely bypass the per-cpu cache for "really huge&qu

Re: zfs + uma

ich don't require > per-cpu caching and are very large why even use UMA? Good point. Right now I am running with 4 items/bucket limit for items larger than 32KB. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org

Re: zfs + uma

on 19/09/2010 11:27 Jeff Roberson said the following: > On Sun, 19 Sep 2010, Andriy Gapon wrote: > >> on 19/09/2010 01:16 Jeff Roberson said the following: >>> Additionally we could make a last ditch flush mechanism that runs on each >>> cpu in >>> turn an

Re: zfs + uma

on 19/09/2010 11:42 Andriy Gapon said the following: > on 19/09/2010 11:27 Jeff Roberson said the following: >> I don't like this because even with very large buffers you can still have >> high >> enough turnover to require per-cpu caching. Kip specifically added UMA

Re: zfs + uma

oop that binds to each > core > in succession. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: zfs + uma

behavior that _might_ result from adaptive algorithms. Anyway, I have some early patches to implement first two of your suggestions and I am testing them now. Looks good to me so far. Parameters in the adaptions would probably need some additional tuning. -- Andriy Gapon _

Re: zfs + uma

on 21/09/2010 09:35 Jeff Roberson said the following: > On Tue, 21 Sep 2010, Andriy Gapon wrote: > >> on 19/09/2010 01:16 Jeff Roberson said the following: >>> Additionally we could make a last ditch flush mechanism that runs on each >>> cpu in >> >> Ho

Re: zfs + uma

f 2. patch that attempts to implement Jeff's three suggestions; I've tested per-CPU cache size adaptive behavior, works well, but haven't tested per-CPU cache draining yet: http://people.freebsd.org/~avg/uma-2.diff -- Andriy Gapon ___ fr

Re: zfs + uma

on 22/09/2010 10:25 Andriy Gapon said the following: > 2. patch that attempts to implement Jeff's three suggestions; I've tested > per-CPU cache size adaptive behavior, works well, but haven't tested per-CPU > cache draining yet: > http://people.freebsd.org/~avg/uma-2.

Re: question regarding link_elf.c

e valid location of > '.data' section > in memory. > > Sorry if my question is stupid, but im wondering why it is so ? I guess > it has something > to do with virtual memory mapping (?). Perhaps the reason is simpler, like a bug in your code :-) You can do

Re: question regarding link_elf.c

rts at lf->address + 0x3e7. How do I know ? I've > added global > initialized string variable in empty test module, and Im looking at the > memory to determine > it's location. I'm not sure what is wrong then. Can you post a link to the compiled test module? -- Andriy Gapon

Re: question regarding link_elf.c

on 29/09/2010 17:44 PL said the following: > Dnia 29-09-2010 o godz. 16:23 Andriy Gapon napisał(a): >> on 29/09/2010 17:13 PL said the following: >>> It seems like it is not a problem in my own code, since readelf -S on a >>> elf file >>> gives me the sam

sysctl for querying kmem_map->size

er way to decide whether to use SYSCTL_ADD_UINT or SYSCTL_ADD_ULONG depending on real type behind vm_size_t. Comments, suggestions? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To u

Re: sysctl for querying kmem_map->size

on 30/09/2010 21:52 Garrett Cooper said the following: > On Thu, Sep 30, 2010 at 10:17 AM, Andriy Gapon wrote: >> >> Here's a patch that adds a sysctl for querying kmem_map->size, which may be >> useful >> for system state/resources monitoring: >&

Re: sysctl for querying kmem_map->size

on 30/09/2010 20:17 Andriy Gapon said the following: > > Here's a patch that adds a sysctl for querying kmem_map->size, which may be > useful > for system state/resources monitoring: > http://people.freebsd.org/~avg/sysctl-kmem_map_size.diff > > I am quite unsur

zfs: ru_inblock/ru_oublock accounting

A simple, probably incomplete and perhaps incorrect patch for ru_inblock/ru_oublock accounting in zfs: http://people.freebsd.org/~avg/zfs-ru.diff Still quite better than nothing. P.S. This is about top -m io. -- Andriy Gapon ___ freebsd-hackers

panic_cpu should be volatile

ut this is not necessary, of course. Big thanks to mdf@ for the hint and to kib@ and kan@ for memory model expertise. P.S. The assembly: .loc 1 544 0 movlpanic_cpu(%rip), %eax .LVL134: .p2align 4,,7 .L210: cmpl$255, %eax jne .L210 jmp .L

generic_stop_cpus: prevent parallel execution

ty to make amd64-specific suspend_cpus() function use generic_stop_cpus() instead of rolling out essentially duplicate code. I couldn't see any reason no to consolidate, but perhaps I missed something. Big thanks to Matthew and his employer for the idea and example. -

Re: sysctl for querying kmem_map->size

on 05/10/2010 18:27 Andriy Gapon said the following: > Here's an updated patch: > http://people.freebsd.org/~avg/sysctl-kmem_map_size2.diff > The new code wraps kmem_map->size into SYSCTL_PROC() to handle vm_size_t type > differences for different platforms. The idea is sugges

Re: zfs: ru_inblock/ru_oublock accounting

on 07/10/2010 20:33 Andriy Gapon said the following: > > A simple, probably incomplete and perhaps incorrect patch for > ru_inblock/ru_oublock accounting in zfs: > http://people.freebsd.org/~avg/zfs-ru.diff I've updated the patch at the same location. Thanks to "swell.k&

[HEADSUP] changes to cam_get_device() and cam_open_device()

is committed. Thank you. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [PATCH] Bug with powerof2 macro in sys/param.h

ply powerof2 to zero and the users of the macro should do the check on their own if they expect zero as input (many places in the do not allow that). -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/fr

Re: addition of sysctl nodes after compile time

iable and [snip] > does this limitation still exist? I don't think so. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "fr

Re: SYSCALL_MODULE() macro and modfind() issues

ing the required > information to perform the syscall. > > Also tested, the demo syscall module: After commit r205320 and, apparently, its MFC you need to prefix the module with "sys/". For example: modstat(modfind("sys/syscall"), &stat); P

Re: i386 cpu_reset_real: code/comment mismatch

nce between hard and soft reset? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: i386 cpu_reset_real: code/comment mismatch

on 20/05/2008 18:24 John Baldwin said the following: On Tuesday 20 May 2008 09:37:54 am Andriy Gapon wrote: BTW, I understand that there is a difference between hard and soft reset in terms of hardware signals being asserted, but I don't quite understand general consequences. I.e. what

public svn (ro) access?

Is there already a way for public read-only svn access to FreeBSD src repository? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: public svn (ro) access?

on 03/07/2008 19:36 Brooks Davis said the following: > On Thu, Jul 03, 2008 at 07:09:41PM +0300, Andriy Gapon wrote: >> Is there already a way for public read-only svn access to FreeBSD src >> repository? > > svn://svn.freebsd.org/base/ > Thank you! The branch/tag h

tilt/horizontal scroll support

river could be taught to interpret such values as special button presses (similarly to how vertical scrolling is handled in it). Thank you in advance for advices and opinions. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://list

Re: tilt/horizontal scroll support

e just adding some new bytes to the protocol or growing a new protocol (level) or something else... P.S. I replaced usb ml with arch@ in cc. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/

memtest86+ can not link: binutils issue?

sion 2.18.50.0.6-5.fc9 20080403 Can anybody suggest anything about this problem? If somebody is working on newer version of binuitls for FreeBSD I can help as a tester. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.f

Re: memtest86+ can not link: binutils issue?

on 30/10/2008 20:46 Peter Jeremy said the following: > On 2008-Oct-30 18:08:35 +0200, Andriy Gapon <[EMAIL PROTECTED]> wrote: >> 1. obtain and extract >> http://www.memtest.org/download/2.01/memtest86+-2.01.bin.gz > > This is a compressed bootable image and can't b

Re: usb keyboard dying at loader prompt

on 06/11/2008 14:34 Andriy Gapon said the following: > I have a quite strange problem. > This is with 7-BETA amd64. > All of USB is out of kernel and is loaded via modules. > BIOS has "Legacy USB" enabled. > I have only a USB keyboard, no PS/2 port. > > The keyb

Re: ukbd attachment and root mount

on 12/11/2008 14:14 Jeremy Chadwick said the following: > On Wed, Nov 12, 2008 at 01:58:58PM +0200, Andriy Gapon wrote: [snip] >> 2. if ukbd driver is not attached then I don't see any way USB keyboard >> would work in non-legacy way > > Regarding #2: at which stage?

Re: ukbd attachment and root mount

fore the mount root. I am not interested in BIOS, boot chain, etc. I am not even interested in speculations about whether keyboard would work or not at mountroot prompt if it were attaching before it. -- Andriy Gapon ___ freebsd-hackers@freebsd.org ma

Re: ukbd attachment and root mount

on 05/11/2008 17:24 Andriy Gapon said the following: > System is FreeBSD 7.1-BETA2 amd64. > > Looking through my dmesg I see that relative order of ukbd attachment > and root mounting is not deterministic. Sometime keyboard is attached > first, sometimes root filesystem is mount

Re: ukbd attachment and root mount

on 12/11/2008 13:53 Nate Eldredge said the following: > On Wed, 12 Nov 2008, Andriy Gapon wrote: > >> on 05/11/2008 17:24 Andriy Gapon said the following: > [...] >>> I have a legacy-free system (no PS/2 ports, only USB) and I wanted to >>> try a kernel with

Re: ukbd attachment and root mount

on 12/11/2008 14:33 Jeremy Chadwick said the following: > On Wed, Nov 12, 2008 at 02:20:41PM +0200, Andriy Gapon wrote: >> on 12/11/2008 14:14 Jeremy Chadwick said the following: >>> On Wed, Nov 12, 2008 at 01:58:58PM +0200, Andriy Gapon wrote: >> [snip] >>>> 2.

Re: ukbd attachment and root mount

(addr 1) cno=3 attr=0xa0, selfpowered=0, power=100 usbd_set_config_index: set config 1 ukbd0: on uhub2 Full dmesg is here: http://www.icyb.net.ua/~avg/ukbd.dmesg.gz -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mai

Re: ukbd attachment and root mount

ums0: 8 buttons and Z dir. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ukbd attachment and root mount

on 27/11/2008 15:23 Andriy Gapon said the following: > I increased debug level in uhub and also switched mouse and keyboard > ports hoping that order might matter. It didn't. > > Here's fresh usbdevs output snippet: > Controller /dev/usb2: > addr 1: full speed, self

dd if=/dev/mem can hang a machine?

any issues. Could this be related to some modern form of memory-mapped IO? Or to Intel Management Engine (that seems t bite into DRAM)? Or something else? Just wondering. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http

Re: dd if=/dev/mem can hang a machine?

on 30/11/2008 22:14 Julian Stacey said the following: > Gary Jennejohn wrote: >> On Fri, 28 Nov 2008 15:28:35 +0200 >> Andriy Gapon <[EMAIL PROTECTED]> wrote: >> >>> I have a new machine with DG33TL mainboard (ICH9/G33). >>> In a course of some hackin

Re: ichwd problem: watchdog doesn't "bark"

on 28/11/2008 16:28 Andriy Gapon said the following: > uname: > FreeBSD 7.1-PRERELEASE r185311 amd64 > > dmesg: > ichwd0: on isa0 > ichwd0: Intel ICH9R watchdog timer (ICH9 or equivalent) > ichwd0: timer disabled > > pciconf: > [EMAIL PROTECTED]:0:31:0: class

Re: dd if=/dev/mem can hang a machine?

BTW, I think it was related to reading memory-mapped registers intended to put CPU into Cx states (x >= 2). -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send

Re: RFC: small syscons and kbd patch

> standard dialect (honestly, this is the first time I've ever seen it > before, but then again I am a younger generation user)? I am not sure what you meant by dialect of C, just in case you meant something different from others understood here's my personal observation: y

Re: usb keyboard dying at loader prompt

the things are much much better. The keyboard doesn't die anymore at the loader prompt! All in all, it seems that this is right direction. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listin

Re: memtest86+ can not link: binutils issue?

on 31/10/2008 15:18 Andriy Gapon said the following: >>> ld --warn-constructors --warn-common -static -T memtest_shared.lds \ >>>-o memtest_shared head.o reloc.o main.o test.o init.o lib.o >>> patn.o screen_buffer.o config.o linuxbios.o memsize.o pci.o contro

Re: memtest86+ on freebsd

on 15/12/2008 16:27 Eygene Ryabinkin said the following: > Andriy, good day. > > Mon, Dec 15, 2008 at 02:08:15PM +0200, Andriy Gapon wrote: >> on 12/12/2008 13:17 Andriy Gapon said the following: >>> Just in case anybody still remembers this issue. >>> It seams t

memtest86+ on freebsd

on 12/12/2008 13:17 Andriy Gapon said the following: > Just in case anybody still remembers this issue. > It seams that the main culprit here was the following line in the linker > script: > > OUTPUT_FORMAT("elf32-i386"); > > I was tipped just today that it sh

usb keyboard vs btx: an SMI theory

SMI is of primary interest here. I also think that this might explain to a certain degree the difference in behavior between "older" btx and "newer" btx. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd

ich watchdog vs intel smm code

_EN is 1: pmbase+0x0030: 0x203b (SMI_EN) "No Reboot (NR)" bit of GCS register is zero: 0x3410: 0x00c01444 -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscrib

Re: ich watchdog vs intel smm code

on 19/01/2009 14:27 Pegasus Mc Cleaft said the following: > > - Original Message - From: "Andriy Gapon" [snip] >> So, if we globally disable SMI, then the watchdog in ICH9 does indeed >> cause a reboot. Evidently this happens after the timer expires twice >

device driver: cdesw questions?

event masks described in poll(2). E.g. what is normal priority, non-zero priority and high priority. Which flags should I care about if all data is the same priority for me? Which flag(s) should I set when I'd like to communicate an error condition (e.g. similar to TCP connection reset)? -- A

Re: device driver: cdesw questions?

Question 3: is it ok to use M_WAITOK in pci attach routine? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-uns

Re: device driver: cdesw questions?

on 21/01/2009 15:35 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: >> Question 1: >> I am writing a driver that would use per-open private data (among other >> features). >> Do I have to use D_TRACKCLOSE flag

Re: device driver: cdesw questions?

on 21/01/2009 15:55 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 03:40:24PM +0200, Andriy Gapon wrote: >> on 21/01/2009 15:35 Kostik Belousov said the following: >>> On Wed, Jan 21, 2009 at 01:20:51PM +0200, Andriy Gapon wrote: >>>> Question 1: &

Re: device driver: cdesw questions?

on 21/01/2009 16:05 Robert Watson said the following: > > On Wed, 21 Jan 2009, Andriy Gapon wrote: > >> Question 1: I am writing a driver that would use per-open private data >> (among other features). Do I have to use D_TRACKCLOSE flag in this >> case? In general

Re: device driver: cdesw questions?

on 21/01/2009 16:15 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 04:12:23PM +0200, Andriy Gapon wrote: >> on 21/01/2009 16:05 Robert Watson said the following: >>> On Wed, 21 Jan 2009, Andriy Gapon wrote: >>> >>>> Question 1: I am writing a

MOD_UNLOAD and driver with cdev

use (in MOD_QUIESCE)? How to check for that best? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: MOD_UNLOAD and driver with cdev

on 21/01/2009 17:39 Kostik Belousov said the following: > On Wed, Jan 21, 2009 at 05:03:20PM +0200, Andriy Gapon wrote: >> Do I need to code for MOD_UNLOAD for driver module that also creates a cdev? >> I see in the current code that one strategy is to simply call >> destroy_

Re: device driver: cdesw questions?

on 21/01/2009 16:05 Robert Watson said the following: > > On Wed, 21 Jan 2009, Andriy Gapon wrote: >> I also would like the driver to provide a select capability quite >> similar to that of network (e.g. TCP) sockets using d_poll. I.e. a >> userland program should be a

Re: usb keyboard vs btx: an SMI theory

on 21/01/2009 21:07 John Baldwin said the following: > On Tuesday 16 December 2008 8:16:44 am Andriy Gapon wrote: >> Again, I am very fuzzy about the exact details, but I think that this is >> something that could be happening and I think that SMI is of primary >> interest he

INTR_FILTER?

INTR_FILTER - what does it do? It doesn't seem to be documented anywhere, but seems to affect interrupt code. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe,

Re: INTR_FILTER?

on 29/01/2009 14:55 Ed Schouten said the following: > * Andriy Gapon wrote: >> INTR_FILTER - what does it do? >> It doesn't seem to be documented anywhere, but seems to affect interrupt >> code. > > Not sure, but I think I was once told that FreeBSD has a `two le

Re: INTR_FILTER?

on 29/01/2009 19:17 Rui Paulo said the following: > > On 29 Jan 2009, at 11:47, Andriy Gapon wrote: > >> INTR_FILTER - what does it do? >> It doesn't seem to be documented anywhere, but seems to affect interrupt >> code. > > INTR_FILTER allows you to skip t

Re: INTR_FILTER?

on 02/02/2009 13:53 Rui Paulo said the following: > > On 2 Feb 2009, at 11:38, Andriy Gapon wrote: > >> on 30/01/2009 00:30 Rui Paulo said the following: >>> On 29 Jan 2009, at 17:51, Andriy Gapon wrote: >>>> BTW, INTR_FILTER seems quite useful. Why, then

Re: INTR_FILTER?

on 30/01/2009 15:08 Paolo Pisati said the following: > Andriy Gapon wrote: >> INTR_FILTER - what does it do? >> It doesn't seem to be documented anywhere, but seems to affect interrupt >> code. >> >> > for a bit more information about interrupt filtering

Re: INTR_FILTER?

on 30/01/2009 00:30 Rui Paulo said the following: > On 29 Jan 2009, at 17:51, Andriy Gapon wrote: >> BTW, INTR_FILTER seems quite useful. Why, then, it is not the default? > > The drivers would have to be ported to INTR_FILTER. Right now, only asmc > is using INTR_FILTER, so I

<    1   2   3   4   5   6   7   >