Date: Wed, 1 Jun 2011 10:19:00 -0400 (EDT) From: Tom Hicks <thicks@averesystems.com> To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: freebsd-current Digest, Vol 398, Issue 3 Message-ID: <97920B9E-F6F3-47D0-8B37-E5D05D90D357@averesystems.com> In-Reply-To: <20110601120005.CEF1210656E6@hub.freebsd.org> References: <20110601120005.CEF1210656E6@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 1, 2011, at 8:03, freebsd-current-request@freebsd.org wrote: > Send freebsd-current mailing list submissions to > freebsd-current@freebsd.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-current > or, via email, send a message with subject or body 'help' to > freebsd-current-request@freebsd.org >=20 > You can reach the person managing the list at > freebsd-current-owner@freebsd.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-current digest..." >=20 >=20 > Today's Topics: >=20 > 1. Re: Testing new nfs and VIMAGE (Goran Lowkrantz) > 2. Re: [rfc] remove hlt_cpus et al sysctls and related code > (Attilio Rao) > 3. Re: [rfc] remove hlt_cpus et al sysctls and related code > (Andriy Gapon) > 4. Re: ZFS install from -CURRENT snapshot (Alexander Leidinger) > 5. Re: pcib allocation failure (John Baldwin) > 6. Re: message buffer scrambling fix (Kenneth D. Merry) > 7. Re: mount root from zfs fails under current with "error 6" > (Michael Reifenberger) > 8. Re: mount root from zfs fails under current with "error 6" > (Andriy Gapon) > 9. "lazy" mmap for a device driver ? (Luigi Rizzo) > 10. Re: "lazy" mmap for a device driver ? (Kostik Belousov) > 11. Re: Boot halts on Thinkpad X220 (Sandy Bridge) (Jung-uk Kim) > 12. Re: Boot halts on Thinkpad X220 (Sandy Bridge) (Jung-uk Kim) > 13. Re: Boot halts on Thinkpad X220 (Sandy Bridge) (Jung-uk Kim) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Tue, 31 May 2011 14:34:22 +0200 > From: Goran Lowkrantz <glz@hidden-powers.com> > Subject: Re: Testing new nfs and VIMAGE > To: freebsd-current@freebsd.org > Cc: Rick Macklem <rmacklem@uoguelph.ca> > Message-ID: <1DE98FADA8318788A5DD5505@[172.16.2.57]> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > For the list: Attached patch works. >=20 > /glz >=20 > --On May 28, 2011 19:28:43 -0400 Rick Macklem <rmacklem@uoguelph.ca> wrot= e: >=20 >>> It worked when I added CURVNET_SET/CURVNET_RESTORE around the >>> RTFREE_LOCKED >>> macro too. Attached a complete patch. >>>=20 >>> Thank you. >>>=20 >> and thanks for finding/reporting/testing it. I've attached another >> variant of the patch that maybe you could try? >> (I don't think it's necessary to do twice, so I just moved the >> CURVNET_RESTORE() to after the RTFREE_LOCKED() macro instead.) >>=20 >> I don't know if you are a committer for this stuff or not? >> If you are feel free to commit whichever variant of the patch you >> find works and prefer. >>=20 >> If not, maybe bz@ could either commit it or review it? >> (or whoever is doing the VIMAGE stuff these days?) >>=20 >> rick >=20 > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: curvnet.patch > Type: text/x-patch > Size: 1144 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/2011= 0531/2c83e02d/curvnet-0001.bin >=20 > ------------------------------ >=20 > Message: 2 > Date: Tue, 31 May 2011 09:34:44 -0400 > From: Attilio Rao <attilio@freebsd.org> > Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code > To: Andriy Gapon <avg@freebsd.org> > Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>, > "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> > Message-ID: <BANLkTinLwVZqQ3C0E4Ey=3DtWNV5bLZ+Ugcw@mail.gmail.com> > Content-Type: text/plain; charset=3DUTF-8 >=20 > 2011/5/31 Andriy Gapon <avg@freebsd.org>: >> on 29/05/2011 06:06 Attilio Rao said the following: >>> 2011/5/28 Attilio Rao <attilio@freebsd.org>: >>>> 2011/5/25 Andriy Gapon <avg@freebsd.org>: >>>>> The patch is here: >>>>> http://people.freebsd.org/~avg/cpu-offline-sysctl.diff >>>>> It should implement the strategy described above. >>>>>=20 >>>>=20 >>>> I don't see the point in keeping alive mp_grab_cpu_hlt() and >>>> supporting, actually. >>>>=20 >>>> On the top of your patch I made some modifies that use directly >>>> ap_watchdog() in cpu_idle() which I think is better for the time >>>> being: >>>> http://www.freebsd.org/~attilio/avg_rem_cpuhlt.diff >>=20 >> Yes, I agree, thank you. >>=20 >>>> If you are happy with it, just commit as long as Garrett tests that. >>=20 >>=20 >> OK. Waiting for test feedback. >>=20 >>>> On a second round of changes we can discuss mp_watchdog and eventual >>>> removal / improvements to it. >>>=20 >>> I almost forgot: this change would also require an UPDATE entry, where >>> you explicitly mention the "new" way to deal with CPUs. Use your >>> prefer wording. >>=20 >> Sure. Thank you! >>=20 >> BTW, I guess there would be no reason to MFC this change? >=20 > You mean no reason to not MFC it? >=20 > In general, I think that users may expect those sysctls to be alive > (IMHO we should consider sysctls to be part of the userland API) so > that we can add some more, but we should not axe them. > So probabilly MFC is not the best option here. >=20 > Attilio >=20 >=20 > --=20 > Peace can only be achieved by understanding - A. Einstein >=20 >=20 > ------------------------------ >=20 > Message: 3 > Date: Tue, 31 May 2011 16:40:45 +0300 > From: Andriy Gapon <avg@FreeBSD.org> > Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code > To: Attilio Rao <attilio@FreeBSD.org> > Cc: "freebsd-current@freebsd.org" <freebsd-current@FreeBSD.org>, > "freebsd-arch@freebsd.org" <freebsd-arch@FreeBSD.org> > Message-ID: <4DE4EFDD.8070803@FreeBSD.org> > Content-Type: text/plain; charset=3Dus-ascii >=20 > on 31/05/2011 16:34 Attilio Rao said the following: >> 2011/5/31 Andriy Gapon <avg@freebsd.org>: >>> on 29/05/2011 06:06 Attilio Rao said the following: >>>> 2011/5/28 Attilio Rao <attilio@freebsd.org>: >>>>> 2011/5/25 Andriy Gapon <avg@freebsd.org>: >>>>>> The patch is here: >>>>>> http://people.freebsd.org/~avg/cpu-offline-sysctl.diff >>>>>> It should implement the strategy described above. >>>>>>=20 >>>>>=20 >>>>> I don't see the point in keeping alive mp_grab_cpu_hlt() and >>>>> supporting, actually. >>>>>=20 >>>>> On the top of your patch I made some modifies that use directly >>>>> ap_watchdog() in cpu_idle() which I think is better for the time >>>>> being: >>>>> http://www.freebsd.org/~attilio/avg_rem_cpuhlt.diff >>>=20 >>> Yes, I agree, thank you. >>>=20 >>>>> If you are happy with it, just commit as long as Garrett tests that. >>>=20 >>>=20 >>> OK. Waiting for test feedback. >>>=20 >>>>> On a second round of changes we can discuss mp_watchdog and eventual >>>>> removal / improvements to it. >>>>=20 >>>> I almost forgot: this change would also require an UPDATE entry, where >>>> you explicitly mention the "new" way to deal with CPUs. Use your >>>> prefer wording. >>>=20 >>> Sure. Thank you! >>>=20 >>> BTW, I guess there would be no reason to MFC this change? >>=20 >> You mean no reason to not MFC it? >=20 > I meant exactly what I asked :-) > As in: I didn't see any reason for MFC. >=20 >> In general, I think that users may expect those sysctls to be alive >> (IMHO we should consider sysctls to be part of the userland API) so >> that we can add some more, but we should not axe them. >> So probabilly MFC is not the best option here. >=20 > --=20 > Andriy Gapon >=20 >=20 > ------------------------------ >=20 > Message: 4 > Date: Tue, 31 May 2011 16:04:49 +0200 > From: Alexander Leidinger <Alexander@Leidinger.net> > Subject: Re: ZFS install from -CURRENT snapshot > To: Daniel Staal <DStaal@usa.net> > Cc: freebsd-current@freebsd.org, George Kontostanos > <gkontos.mail@gmail.com> > Message-ID: <20110531160449.19667dub2cfejdkx@webmail.leidinger.net> > Content-Type: text/plain; charset=3DUTF-8; DelSp=3D"Yes"; format=3D"flowe= d" >=20 > Quoting Daniel Staal <DStaal@usa.net> (from Mon, 30 May 2011 11:01:06 -04= 00): >=20 >> --As of May 29, 2011 9:10:57 AM -0400, George Kontostanos, =20 >> freebsd-current@freebsd.org is alleged to have said: >>=20 >>> --As of May 29, 2011 12:06:30 PM +0300, George Kontostanos is alleged t= o >>> have said: >>>=20 >>>> The new bsdinstall has a different layout so the previous guides don't >>>> work. I have prepared one that works for recent 9-Current at : >>>>=20 >>>> "http://www.aisecure.net/?p=3D132" >>>=20 >>> --As for the rest, it is mine. >>>=20 >>> Thanks, that's about what I expected the install procedure to be at thi= s >>> point. Nice to have the reminder about the zpool.cache. (Do I have t= o >>> use the Live CD mode? Can I use shell mode instead?) >>=20 >> --As for the rest, it is mine. >>=20 >> Ok, I've tried shell mode and live CD mode. I've re-partitioned my =20 >> disks several different ways. >>=20 >> Nothing gets me a system that will actually boot. Or even recognize =20 >> that there is an OS loaded anywhere. Help? >=20 > I did it like this: > http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimi= zed-for-4k-sector-drives/ >=20 >> (My preferred partitioning: >>=20 >> ada1: >> 1 freebsd-boot >> 2 freebsd-swap 8G >> 3 freebsd-zfs 4G (zil) >> 4 freebsd-zfs 17G (cache) >>=20 >> ada0: Managed by ZFS, ~250G Main filesystem. >=20 > You show the boot partition on ada1, but you do not tell if ada0 has a = =20 > boot partition too or not. Did you try to have the boot partition on =20 > the same disk as the pool? >=20 > I hope ada1 is a SSD. If not, it does not make much sense to have a =20 > cache there (a cache needs to have lower latency than the main pool, I = =20 > do not expect that just another spindle gives a significant perf =20 > improvement). >=20 > Bye, > Alexander. >=20 > --=20 > Please don't put a strain on our friendship > by asking me to do something for you. >=20 > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE= 7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 7207713= 7 >=20 >=20 > ------------------------------ >=20 > Message: 5 > Date: Tue, 31 May 2011 10:39:37 -0400 > From: John Baldwin <jhb@freebsd.org> > Subject: Re: pcib allocation failure > To: freebsd-current@freebsd.org > Cc: "deeptech71@gmail.com" <deeptech71@gmail.com> > Message-ID: <201105311039.37935.jhb@freebsd.org> > Content-Type: Text/Plain; charset=3D"iso-8859-1" >=20 > On Saturday, May 28, 2011 9:45:48 pm deeptech71@gmail.com wrote: >> On Thu, May 26, 2011 at 3:40 PM, John Baldwin <jhb@freebsd.org> wrote: >>> Ohh, you have two devices behind this bridge that have prefetch ranges. >>>=20 >>> As a hack, can you try this: >>>=20 >>> Index: pci_pci.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- pci_pci.c (revision 222285) >>> +++ pci_pci.c (working copy) >>> @@ -162,8 +162,13 @@ pcib_write_windows(struct pcib_softc *sc, int mask >>> { >>> device_t dev; >>> uint32_t val; >>> + uint16_t cmd; >>>=20 >>> dev =3D sc->dev; >>> + cmd =3D pci_read_config(dev, PCIR_COMMAND, 2); >>> + if (cmd & (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN)) >>> + pci_write_config(dev, PCIR_COMMAND, >>> + cmd & ~(PCIM_CMD_PORTEN | PCIM_CMD_MEMEN), 2); >>> if (sc->io.valid && mask & WIN_IO) { >>> val =3D pci_read_config(dev, PCIR_IOBASEL_1, 1); >>> if ((val & PCIM_BRIO_MASK) =3D=3D PCIM_BRIO_32) { >>> @@ -192,6 +197,8 @@ pcib_write_windows(struct pcib_softc *sc, int mask >>> pci_write_config(dev, PCIR_PMBASEL_1, sc->pmem.base >> 16= ,=20 > 2); >>> pci_write_config(dev, PCIR_PMLIMITL_1, sc->pmem.limit >>= =20 > 16, 2); >>> } >>> + if (cmd & (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN)) >>> + pci_write_config(dev, PCIR_COMMAND, cmd, 2); >>> } >>>=20 >>> static void >>> @@ -337,6 +344,9 @@ pcib_probe_windows(struct pcib_softc *sc) >>> pci_read_config(dev, PCIR_PMLIMITL_1, 2)); >>> max =3D 0xffffffff; >>> } >>> + /* XXX: Testing hack */ >>> + if (device_get_unit(sc->sc_dev) =3D=3D 1) >>=20 >> i'm assuming that "sc->sc_dev" should be "dev" (this fixes a compilation= =20 > error). >>=20 >>> + sc->pmem.limit =3D 0xefffffff; >>> pcib_alloc_window(sc, &sc->pmem, SYS_RES_MEMORY, >>> RF_PREFETCHABLE, max); >>> } >>=20 >> that seems to work! >=20 > Hmmm, ok. This may not be easy to fix properly for the time being as it= =20 > requires the PCI-PCI bridge to scan all the devices behind the bus to fin= d=20 > what resource ranges are actually needed before programming its windows. = Note=20 > that this is all to work around your BIOS being very broken. :( >=20 >> btw, is my machine a test-pig for an upcoming change to the PCI bus driv= er? >=20 > Well, it's been a good test thus far. >=20 > --=20 > John Baldwin >=20 >=20 > ------------------------------ >=20 > Message: 6 > Date: Tue, 31 May 2011 09:42:15 -0600 > From: "Kenneth D. Merry" <ken@freebsd.org> > Subject: Re: message buffer scrambling fix > To: Julian Elischer <julian@freebsd.org> > Cc: current@freebsd.org > Message-ID: <20110531154215.GA45877@nargothrond.kdm.org> > Content-Type: text/plain; charset=3Dus-ascii >=20 > On Sat, May 28, 2011 at 11:26:50 -0700, Julian Elischer wrote: >> On 5/27/11 3:45 PM, Kenneth D. Merry wrote: >>> Hey folks, >>>=20 >>> I have attached some patches to the kernel message buffer code (this >>> affects dmesg(8) output as well as kernel messages that go to the syslo= g) >>> to address log scrambling. >>>=20 >>> This fixes the same issue that 'options PRINTF_BUFR_SIZE=3D128' fixes f= or the >>> console. >>>=20 >>> The problem is that you can have multiple kernel threads writing to the >>> message buffer at the same time, and so their characters will get >>> interleaved. All of the characters will get in there, because they're >>> written with atomic operations, but the output might looked scrambled. >>>=20 >>> So the fix is to use the same stack buffer that is used for the console >>> output (so the stack size doesn't increase), and use a spin lock instea= d of >>> atomic operations to insert the string into the message buffer. >>>=20 >>> The result is that dmesg and syslog output should look the same as the >>> console output. As long as individual kernel prints fit in the printf >>> buffer size, they will be put into the message buffer atomically. >>>=20 >>> I also fixed a couple of other long-standing issues. putcons() (in >>> subr_prf.c) was adding a carriage return before calling cnputs(). But >>> cnputs() calls cnputc(), which adds a carriage return before every newl= ine. >>> So much of the console output (the part that came from putcons() at lea= st) >>> had two carriage returns at the end. >>>=20 >>> The other issue was that log_console() was inserting a newline for any >>> console write that didn't already have one at the end. The issue with = that >>> can be seen if you do a 'dmesg -a' and compare that to the console outp= ut. >>>=20 >>> You'll see something like this on the console: >>>=20 >>> Updating motd:. >>>=20 >>> But this in dmesg -a: >>>=20 >>> Updating motd: >>> . >>>=20 >>> That is because "Updating motd:" is written first, log_console() append= s a >>> newline, and then ".\n" is written. >>>=20 >>> I added a loader tunable and sysctl to turn the old behavior back on >>> (kern.log_console_add_linefeed) if you want the old behavior, but I thi= nk >>> we should be able to safely remove it. >>>=20 >>> Also, the new msgbuf_addstr() function allows the caller to optionally = ask >>> for carriage returns to be stripped out. However, in my testing I have= n't >>> seen any carriage returns to strip. >>>=20 >>> Let me know if you have any comments. I'm planning to check this into = head >>> next week. >>=20 >> looks good.. as long as we don't end up with the behaviour that I=20 >> think I see on >> Linux (it's hard to tell sometimes) where the last message (the one=20 >> you really >> want to see) doesn't make it out. >=20 > Everything passed into the kernel printf() call should make it out to the > console, message buffer, etc. before the printf call completes. The only > way that wouldn't happen is if spin locks break for some reason. >=20 > One thing I forgot to mention is that I think the PRINTF_BUFR_SIZE option > should be made non-optional. Even on smaller embedded machines, I think = we > should be able to afford the 128 bytes of stack space to keep messages fr= om > getting scrambled. >=20 > Ken > --=20 > Kenneth Merry > ken@FreeBSD.ORG >=20 >=20 > ------------------------------ >=20 > Message: 7 > Date: Tue, 31 May 2011 19:38:50 +0200 (CEST) > From: Michael Reifenberger <mike@reifenberger.com> > Subject: Re: mount root from zfs fails under current with "error 6" > To: pjd@freebsd.org > Cc: Garrett Cooper <yanegomi@gmail.com>, FreeBSD-Current > <current@freebsd.org> > Message-ID: <alpine.BSF.2.00.1105311925330.3376@gw.reifenberger.com> > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed >=20 > Hi, >=20 > On Tue, 31 May 2011, Michael Reifenberger wrote: > ... >> (fs)(root) gpart show ada0 >> =3D> 34 5860533101 ada0 GPT (2.7T) >> 34 990 1 freebsd-boot (495k) >> 1024 2098176 2 freebsd-swap (1.0G) >> 2099200 5858433928 3 freebsd-zfs (2.7T) >> 5860533128 7 - free - (3.5k) >>=20 > ... >=20 > maybe I found something: > After setting vfs.zfs.debug=3D1 I got two new verbose bootlogs: > http://people.freebsd.org/~mr/boot_fail2.txt > http://people.freebsd.org/~mr/boot_success2.txt >=20 > As you can see, in the failing case ZFS tries to attach to ada[0123] > whereas in the succeeding case ZFS attaches to ada[0123]p3 (which are the= =20 > correct devices) >=20 > Bye/2 > --- > Michael Reifenberger > Michael@Reifenberger.com > http://www.Reifenberger.com >=20 >=20 >=20 > ------------------------------ >=20 > Message: 8 > Date: Tue, 31 May 2011 22:28:54 +0300 > From: Andriy Gapon <avg@FreeBSD.org> > Subject: Re: mount root from zfs fails under current with "error 6" > To: Michael Reifenberger <mike@reifenberger.com> > Cc: Garrett Cooper <yanegomi@gmail.com>, pjd@FreeBSD.org, > FreeBSD-Current <current@FreeBSD.org> > Message-ID: <4DE54176.3080702@FreeBSD.org> > Content-Type: text/plain; charset=3DISO-8859-1 >=20 > on 31/05/2011 20:38 Michael Reifenberger said the following: >> Hi, >>=20 >> On Tue, 31 May 2011, Michael Reifenberger wrote: >> ... >>> (fs)(root) gpart show ada0 >>> =3D> 34 5860533101 ada0 GPT (2.7T) >>> 34 990 1 freebsd-boot (495k) >>> 1024 2098176 2 freebsd-swap (1.0G) >>> 2099200 5858433928 3 freebsd-zfs (2.7T) >>> 5860533128 7 - free - (3.5k) >>>=20 >> ... >>=20 >> maybe I found something: >> After setting vfs.zfs.debug=3D1 I got two new verbose bootlogs: >> http://people.freebsd.org/~mr/boot_fail2.txt >> http://people.freebsd.org/~mr/boot_success2.txt >>=20 >> As you can see, in the failing case ZFS tries to attach to ada[0123] >> whereas in the succeeding case ZFS attaches to ada[0123]p3 (which are th= e >> correct devices) >=20 > Maybe try to enable GEOM debug to see if/when tasting of the GPT partitio= ns occurs. > --=20 > Andriy Gapon >=20 >=20 > ------------------------------ >=20 > Message: 9 > Date: Tue, 31 May 2011 22:21:42 +0200 > From: Luigi Rizzo <rizzo@iet.unipi.it> > Subject: "lazy" mmap for a device driver ? > To: current@freebsd.org > Message-ID: <20110531202142.GA7105@onelab2.iet.unipi.it> > Content-Type: text/plain; charset=3Dus-ascii >=20 > hi, > i have a kernel module implementing a memory mapped special device > which exports a large block of memory to the process. > I see that when the process calls mmap(), my routine foo_mmap() > is called immediately once per page, even though the process is > not actually touching the pages. I believe this happens > through dev_pager_alloc(). >=20 > Right now i can live with that because all the memory is allocated > at module load time, but i might want to have a sparse memory > region which is populated dynamically, so i was wondering if > there is a way to achieve this. I see there are two other > device routines, d_mmap2 and d_mmap_single, any pointer to > documentation or comments on how they differ ? >=20 > thanks > luigi >=20 >=20 > ------------------------------ >=20 > Message: 10 > Date: Tue, 31 May 2011 23:45:18 +0300 > From: Kostik Belousov <kostikbel@gmail.com> > Subject: Re: "lazy" mmap for a device driver ? > To: Luigi Rizzo <rizzo@iet.unipi.it> > Cc: current@freebsd.org > Message-ID: <20110531204518.GX48734@deviant.kiev.zoral.com.ua> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > On Tue, May 31, 2011 at 10:21:42PM +0200, Luigi Rizzo wrote: >> hi, >> i have a kernel module implementing a memory mapped special device >> which exports a large block of memory to the process. >> I see that when the process calls mmap(), my routine foo_mmap() >> is called immediately once per page, even though the process is >> not actually touching the pages. I believe this happens >> through dev_pager_alloc(). >>=20 >> Right now i can live with that because all the memory is allocated >> at module load time, but i might want to have a sparse memory >> region which is populated dynamically, so i was wondering if >> there is a way to achieve this. I see there are two other >> device routines, d_mmap2 and d_mmap_single, any pointer to >> documentation or comments on how they differ ? >=20 > During the porting of GEM to our kernel, I had to make a device > pager interface more flexible. In particular, the updated pager allows > the device to handle individual faults and return an explicit > page to satisfy the fault, instead of the physical address. >=20 > More, the driver can do any appropriate setup by ctr method. > The new interface is supposed to be used with d_mmap_single(). >=20 > http://people.freebsd.org/~kib/misc/device_pager.2.patch > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 196 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/2011= 0531/6e617d43/attachment-0001.pgp >=20 > ------------------------------ >=20 > Message: 11 > Date: Tue, 31 May 2011 16:50:14 -0400 > From: Jung-uk Kim <jkim@FreeBSD.org> > Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) > To: Xin LI <delphij@gmail.com> > Cc: "George V. Neville-Neil" <gnn@neville-neil.com>, > freebsd-current@freebsd.org, Johannes Dieterich > <dieterich.joh@googlemail.com> > Message-ID: <201105311650.16164.jkim@FreeBSD.org> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > On Friday 27 May 2011 01:14 pm, Xin LI wrote: >> On Thu, May 19, 2011 at 5:18 AM, Johannes Dieterich >>=20 >> <dieterich.joh@googlemail.com> wrote: >>> On Wed, May 18, 2011 at 7:40 PM, Xin LI <delphij@delphij.net>=20 > wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>>=20 >>>> Try this patch? >>>=20 >>> The attached patch makes 9-CURRENT-amd64 boot on the X220 w/o any >>> hints or BIOS fixes needed. Thanks a lot! :-) >>>=20 >>>> (I'm still opted to disable the typematic rate detection by >>>> default at least for amd64, as we don't do it in the past for >>>> amd64) >>>=20 >>> What does this mean concerning getting the fix into CURRENT? >>=20 >> Well, that's not a perfect fix and we do lose the ability of >> detecting typematic rate (by default), so technically it's a >> workaround (sufficient to make the kernel boot and work, though) >> and doesn't fix anything. >>=20 >> I have committed it anyway since we do not have better fix (yet), >> and have updated atkbd(4) manual page so one can enable it again >> when wanted. >>=20 >> The problem we had was that it seems that running the BIOS in the >> x86emu emulator on amd64 would cause problem. This doesn't seem to >> be fixable without hands-on experiments on a system in question, >> it's either a BIOS bug or an emulator bug. The strange part of the >> problem is that the functionality is quite common in the Good Old >> Days (TM). >=20 > I got BIOS dump from gnn last week. I've been scratching my head=20 > cause it should just fail and exit gracefully unless I am totally=20 > missing something. :-( >=20 > Are you guys sure that INT 15h is causing hangs? Maybe INT 16h is the=20 > real culprit (which is more probable, BTW)? >=20 > Jung-uk Kim >=20 >=20 > ------------------------------ >=20 > Message: 12 > Date: Tue, 31 May 2011 16:56:25 -0400 > From: Jung-uk Kim <jkim@FreeBSD.org> > Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) > To: Xin LI <delphij@gmail.com> > Cc: "George V. Neville-Neil" <gnn@neville-neil.com>, > freebsd-current@freebsd.org, Johannes Dieterich > <dieterich.joh@googlemail.com> > Message-ID: <201105311656.27244.jkim@FreeBSD.org> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > On Tuesday 31 May 2011 04:50 pm, Jung-uk Kim wrote: >> I got BIOS dump from gnn last week. I've been scratching my head >> cause it should just fail and exit gracefully unless I am totally >> missing something. :-( >>=20 >> Are you guys sure that INT 15h is causing hangs? Maybe INT 16h is >> the real culprit (which is more probable, BTW)? >=20 > BTW, it shouldn't call INT 16h at all unless INT 15h succeeded=20 > somehow. So, I am totally lost. :-( >=20 > Jung-uk Kim >=20 >=20 > ------------------------------ >=20 > Message: 13 > Date: Tue, 31 May 2011 20:03:28 -0400 > From: Jung-uk Kim <jkim@FreeBSD.org> > Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge) > To: Xin LI <delphij@gmail.com> > Cc: "George V. Neville-Neil" <gnn@neville-neil.com>, > freebsd-current@freebsd.org, Johannes Dieterich > <dieterich.joh@googlemail.com> > Message-ID: <201105312003.29931.jkim@FreeBSD.org> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > On Tuesday 31 May 2011 04:50 pm, Jung-uk Kim wrote: >> On Friday 27 May 2011 01:14 pm, Xin LI wrote: >>> On Thu, May 19, 2011 at 5:18 AM, Johannes Dieterich >>>=20 >>> <dieterich.joh@googlemail.com> wrote: >>>> On Wed, May 18, 2011 at 7:40 PM, Xin LI <delphij@delphij.net> >>=20 >> wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA256 >>>>>=20 >>>>> Try this patch? >>>>=20 >>>> The attached patch makes 9-CURRENT-amd64 boot on the X220 w/o >>>> any hints or BIOS fixes needed. Thanks a lot! :-) >>>>=20 >>>>> (I'm still opted to disable the typematic rate detection by >>>>> default at least for amd64, as we don't do it in the past for >>>>> amd64) >>>>=20 >>>> What does this mean concerning getting the fix into CURRENT? >>>=20 >>> Well, that's not a perfect fix and we do lose the ability of >>> detecting typematic rate (by default), so technically it's a >>> workaround (sufficient to make the kernel boot and work, though) >>> and doesn't fix anything. >>>=20 >>> I have committed it anyway since we do not have better fix (yet), >>> and have updated atkbd(4) manual page so one can enable it again >>> when wanted. >>>=20 >>> The problem we had was that it seems that running the BIOS in the >>> x86emu emulator on amd64 would cause problem. This doesn't seem >>> to be fixable without hands-on experiments on a system in >>> question, it's either a BIOS bug or an emulator bug. The strange >>> part of the problem is that the functionality is quite common in >>> the Good Old Days (TM). >>=20 >> I got BIOS dump from gnn last week. I've been scratching my head >> cause it should just fail and exit gracefully unless I am totally >> missing something. :-( >>=20 >> Are you guys sure that INT 15h is causing hangs? Maybe INT 16h is >> the real culprit (which is more probable, BTW)? >=20 > I found something strange about this BIOS (well, if we can call it=20 > that). Please try this: >=20 > Index: sys/dev/atkbdc/atkbd.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/dev/atkbdc/atkbd.c (revision 222550) > +++ sys/dev/atkbdc/atkbd.c (working copy) > @@ -1100,7 +1100,8 @@ get_typematic(keyboard_t *kbd) > if (!(kbd->kb_config & KB_CONF_PROBE_TYPEMATIC)) > return (ENODEV); >=20 > - if (x86bios_get_intr(0x15) =3D=3D 0 || x86bios_get_intr(0x16) =3D=3D= 0) > + if (x86bios_get_intr(0x15) !=3D 0xf000f859 || > + x86bios_get_intr(0x16) !=3D 0xf000e82e) > return (ENODEV); >=20 > /* Is BIOS system configuration table supported? */ >=20 > You must re-enable typematic probing from loader to test it, of=20 > course. I think the following line should do: >=20 > hint.atkbd.0.flags=3D"0x10" >=20 > Note: You may add printf() before and after the check to make sure it=20 > is being called (and it fails immediately). >=20 > A long answer goes like this. INT 0x15 and 0x16 vectors have fixed=20 > entry points in *real* BIOS, i.e., 0xf000:0xf859 and 0xf000:0xe82e. =20 > For this BIOS (or CSM), INT 0x16 vector is correct but INT 0x15=20 > vector is not (0xf000:0xb4f1). Funny thing is 0xf000:0xf859 actually=20 > points to a working INT 15h handler, it seems, which confused me=20 > totally. Probably it was done like this because (U)EFI CSM spec.=20 > mandated it to be located @ 0xf000:0xf859. If we follow the=20 > interrupt vector (0xf000:0xb4f1), it gets nowhere (or jumps to an=20 > unknown external interrupt handler). If we follow the fixed address,=20 > it will exit gracefully. So, actually there are two possible=20 > solutions, i.e., 1) check whether the interrupt vector is modified=20 > (the above patch), or 2) jump directly to the fixed interrupt entry=20 > point. I chose Option #1 because it is very hard to find BIOS=20 > typematic support these days (as you pointed out). >=20 > Cheers, >=20 > Jung-uk Kim >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " >=20 > End of freebsd-current Digest, Vol 398, Issue 3 > ***********************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?97920B9E-F6F3-47D0-8B37-E5D05D90D357>