freebsd-current Digest, Vol 398, Issue 3
Tom Hicks
thicks at averesystems.com
Wed Jun 1 14:35:44 UTC 2011
On Jun 1, 2011, at 8:03, freebsd-current-request at freebsd.org wrote:
> Send freebsd-current mailing list submissions to
> freebsd-current at freebsd.org
>
> 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 at freebsd.org
>
> You can reach the person managing the list at
> freebsd-current-owner at freebsd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-current digest..."
>
>
> Today's Topics:
>
> 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)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 31 May 2011 14:34:22 +0200
> From: Goran Lowkrantz <glz at hidden-powers.com>
> Subject: Re: Testing new nfs and VIMAGE
> To: freebsd-current at freebsd.org
> Cc: Rick Macklem <rmacklem at uoguelph.ca>
> Message-ID: <1DE98FADA8318788A5DD5505@[172.16.2.57]>
> Content-Type: text/plain; charset="us-ascii"
>
> For the list: Attached patch works.
>
> /glz
>
> --On May 28, 2011 19:28:43 -0400 Rick Macklem <rmacklem at uoguelph.ca> wrote:
>
>>> It worked when I added CURVNET_SET/CURVNET_RESTORE around the
>>> RTFREE_LOCKED
>>> macro too. Attached a complete patch.
>>>
>>> Thank you.
>>>
>> 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.)
>>
>> 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.
>>
>> If not, maybe bz@ could either commit it or review it?
>> (or whoever is doing the VIMAGE stuff these days?)
>>
>> rick
>
> -------------- 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/20110531/2c83e02d/curvnet-0001.bin
>
> ------------------------------
>
> Message: 2
> Date: Tue, 31 May 2011 09:34:44 -0400
> From: Attilio Rao <attilio at freebsd.org>
> Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code
> To: Andriy Gapon <avg at freebsd.org>
> Cc: "freebsd-current at freebsd.org" <freebsd-current at freebsd.org>,
> "freebsd-arch at freebsd.org" <freebsd-arch at freebsd.org>
> Message-ID: <BANLkTinLwVZqQ3C0E4Ey=tWNV5bLZ+Ugcw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> 2011/5/31 Andriy Gapon <avg at freebsd.org>:
>> on 29/05/2011 06:06 Attilio Rao said the following:
>>> 2011/5/28 Attilio Rao <attilio at freebsd.org>:
>>>> 2011/5/25 Andriy Gapon <avg at freebsd.org>:
>>>>> The patch is here:
>>>>> http://people.freebsd.org/~avg/cpu-offline-sysctl.diff
>>>>> It should implement the strategy described above.
>>>>>
>>>>
>>>> I don't see the point in keeping alive mp_grab_cpu_hlt() and
>>>> supporting, actually.
>>>>
>>>> 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
>>
>> Yes, I agree, thank you.
>>
>>>> If you are happy with it, just commit as long as Garrett tests that.
>>
>>
>> OK. Waiting for test feedback.
>>
>>>> On a second round of changes we can discuss mp_watchdog and eventual
>>>> removal / improvements to it.
>>>
>>> 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.
>>
>> Sure. Thank you!
>>
>> BTW, I guess there would be no reason to MFC this change?
>
> You mean no reason to not MFC it?
>
> 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.
>
> Attilio
>
>
> --
> Peace can only be achieved by understanding - A. Einstein
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 31 May 2011 16:40:45 +0300
> From: Andriy Gapon <avg at FreeBSD.org>
> Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code
> To: Attilio Rao <attilio at FreeBSD.org>
> Cc: "freebsd-current at freebsd.org" <freebsd-current at FreeBSD.org>,
> "freebsd-arch at freebsd.org" <freebsd-arch at FreeBSD.org>
> Message-ID: <4DE4EFDD.8070803 at FreeBSD.org>
> Content-Type: text/plain; charset=us-ascii
>
> on 31/05/2011 16:34 Attilio Rao said the following:
>> 2011/5/31 Andriy Gapon <avg at freebsd.org>:
>>> on 29/05/2011 06:06 Attilio Rao said the following:
>>>> 2011/5/28 Attilio Rao <attilio at freebsd.org>:
>>>>> 2011/5/25 Andriy Gapon <avg at freebsd.org>:
>>>>>> The patch is here:
>>>>>> http://people.freebsd.org/~avg/cpu-offline-sysctl.diff
>>>>>> It should implement the strategy described above.
>>>>>>
>>>>>
>>>>> I don't see the point in keeping alive mp_grab_cpu_hlt() and
>>>>> supporting, actually.
>>>>>
>>>>> 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
>>>
>>> Yes, I agree, thank you.
>>>
>>>>> If you are happy with it, just commit as long as Garrett tests that.
>>>
>>>
>>> OK. Waiting for test feedback.
>>>
>>>>> On a second round of changes we can discuss mp_watchdog and eventual
>>>>> removal / improvements to it.
>>>>
>>>> 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.
>>>
>>> Sure. Thank you!
>>>
>>> BTW, I guess there would be no reason to MFC this change?
>>
>> You mean no reason to not MFC it?
>
> I meant exactly what I asked :-)
> As in: I didn't see any reason for MFC.
>
>> 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.
>
> --
> Andriy Gapon
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 31 May 2011 16:04:49 +0200
> From: Alexander Leidinger <Alexander at Leidinger.net>
> Subject: Re: ZFS install from -CURRENT snapshot
> To: Daniel Staal <DStaal at usa.net>
> Cc: freebsd-current at freebsd.org, George Kontostanos
> <gkontos.mail at gmail.com>
> Message-ID: <20110531160449.19667dub2cfejdkx at webmail.leidinger.net>
> Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
>
> Quoting Daniel Staal <DStaal at usa.net> (from Mon, 30 May 2011 11:01:06 -0400):
>
>> --As of May 29, 2011 9:10:57 AM -0400, George Kontostanos,
>> freebsd-current at freebsd.org is alleged to have said:
>>
>>> --As of May 29, 2011 12:06:30 PM +0300, George Kontostanos is alleged to
>>> have said:
>>>
>>>> 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 :
>>>>
>>>> "http://www.aisecure.net/?p=132"
>>>
>>> --As for the rest, it is mine.
>>>
>>> Thanks, that's about what I expected the install procedure to be at this
>>> point. Nice to have the reminder about the zpool.cache. (Do I have to
>>> use the Live CD mode? Can I use shell mode instead?)
>>
>> --As for the rest, it is mine.
>>
>> Ok, I've tried shell mode and live CD mode. I've re-partitioned my
>> disks several different ways.
>>
>> Nothing gets me a system that will actually boot. Or even recognize
>> that there is an OS loaded anywhere. Help?
>
> I did it like this:
> http://www.leidinger.net/blog/2011/05/03/another-root-on-zfs-howto-optimized-for-4k-sector-drives/
>
>> (My preferred partitioning:
>>
>> ada1:
>> 1 freebsd-boot
>> 2 freebsd-swap 8G
>> 3 freebsd-zfs 4G (zil)
>> 4 freebsd-zfs 17G (cache)
>>
>> ada0: Managed by ZFS, ~250G Main filesystem.
>
> You show the boot partition on ada1, but you do not tell if ada0 has a
> boot partition too or not. Did you try to have the boot partition on
> the same disk as the pool?
>
> I hope ada1 is a SSD. If not, it does not make much sense to have a
> cache there (a cache needs to have lower latency than the main pool, I
> do not expect that just another spindle gives a significant perf
> improvement).
>
> Bye,
> Alexander.
>
> --
> Please don't put a strain on our friendship
> by asking me to do something for you.
>
> http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
> http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 31 May 2011 10:39:37 -0400
> From: John Baldwin <jhb at freebsd.org>
> Subject: Re: pcib allocation failure
> To: freebsd-current at freebsd.org
> Cc: "deeptech71 at gmail.com" <deeptech71 at gmail.com>
> Message-ID: <201105311039.37935.jhb at freebsd.org>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> On Saturday, May 28, 2011 9:45:48 pm deeptech71 at gmail.com wrote:
>> On Thu, May 26, 2011 at 3:40 PM, John Baldwin <jhb at freebsd.org> wrote:
>>> Ohh, you have two devices behind this bridge that have prefetch ranges.
>>>
>>> As a hack, can you try this:
>>>
>>> Index: pci_pci.c
>>> ===================================================================
>>> --- 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;
>>>
>>> dev = sc->dev;
>>> + cmd = 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 = pci_read_config(dev, PCIR_IOBASEL_1, 1);
>>> if ((val & PCIM_BRIO_MASK) == 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,
> 2);
>>> pci_write_config(dev, PCIR_PMLIMITL_1, sc->pmem.limit >>
> 16, 2);
>>> }
>>> + if (cmd & (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
>>> + pci_write_config(dev, PCIR_COMMAND, cmd, 2);
>>> }
>>>
>>> static void
>>> @@ -337,6 +344,9 @@ pcib_probe_windows(struct pcib_softc *sc)
>>> pci_read_config(dev, PCIR_PMLIMITL_1, 2));
>>> max = 0xffffffff;
>>> }
>>> + /* XXX: Testing hack */
>>> + if (device_get_unit(sc->sc_dev) == 1)
>>
>> i'm assuming that "sc->sc_dev" should be "dev" (this fixes a compilation
> error).
>>
>>> + sc->pmem.limit = 0xefffffff;
>>> pcib_alloc_window(sc, &sc->pmem, SYS_RES_MEMORY,
>>> RF_PREFETCHABLE, max);
>>> }
>>
>> that seems to work!
>
> Hmmm, ok. This may not be easy to fix properly for the time being as it
> requires the PCI-PCI bridge to scan all the devices behind the bus to find
> what resource ranges are actually needed before programming its windows. Note
> that this is all to work around your BIOS being very broken. :(
>
>> btw, is my machine a test-pig for an upcoming change to the PCI bus driver?
>
> Well, it's been a good test thus far.
>
> --
> John Baldwin
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 31 May 2011 09:42:15 -0600
> From: "Kenneth D. Merry" <ken at freebsd.org>
> Subject: Re: message buffer scrambling fix
> To: Julian Elischer <julian at freebsd.org>
> Cc: current at freebsd.org
> Message-ID: <20110531154215.GA45877 at nargothrond.kdm.org>
> Content-Type: text/plain; charset=us-ascii
>
> 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,
>>>
>>> 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 syslog)
>>> to address log scrambling.
>>>
>>> This fixes the same issue that 'options PRINTF_BUFR_SIZE=128' fixes for the
>>> console.
>>>
>>> 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.
>>>
>>> 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 instead of
>>> atomic operations to insert the string into the message buffer.
>>>
>>> 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.
>>>
>>> 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 newline.
>>> So much of the console output (the part that came from putcons() at least)
>>> had two carriage returns at the end.
>>>
>>> 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 output.
>>>
>>> You'll see something like this on the console:
>>>
>>> Updating motd:.
>>>
>>> But this in dmesg -a:
>>>
>>> Updating motd:
>>> .
>>>
>>> That is because "Updating motd:" is written first, log_console() appends a
>>> newline, and then ".\n" is written.
>>>
>>> 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 think
>>> we should be able to safely remove it.
>>>
>>> Also, the new msgbuf_addstr() function allows the caller to optionally ask
>>> for carriage returns to be stripped out. However, in my testing I haven't
>>> seen any carriage returns to strip.
>>>
>>> Let me know if you have any comments. I'm planning to check this into head
>>> next week.
>>
>> looks good.. as long as we don't end up with the behaviour that I
>> think I see on
>> Linux (it's hard to tell sometimes) where the last message (the one
>> you really
>> want to see) doesn't make it out.
>
> 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.
>
> 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 from
> getting scrambled.
>
> Ken
> --
> Kenneth Merry
> ken at FreeBSD.ORG
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 31 May 2011 19:38:50 +0200 (CEST)
> From: Michael Reifenberger <mike at reifenberger.com>
> Subject: Re: mount root from zfs fails under current with "error 6"
> To: pjd at freebsd.org
> Cc: Garrett Cooper <yanegomi at gmail.com>, FreeBSD-Current
> <current at freebsd.org>
> Message-ID: <alpine.BSF.2.00.1105311925330.3376 at gw.reifenberger.com>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> Hi,
>
> On Tue, 31 May 2011, Michael Reifenberger wrote:
> ...
>> (fs)(root) gpart show ada0
>> => 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)
>>
> ...
>
> maybe I found something:
> After setting vfs.zfs.debug=1 I got two new verbose bootlogs:
> http://people.freebsd.org/~mr/boot_fail2.txt
> http://people.freebsd.org/~mr/boot_success2.txt
>
> 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
> correct devices)
>
> Bye/2
> ---
> Michael Reifenberger
> Michael at Reifenberger.com
> http://www.Reifenberger.com
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 31 May 2011 22:28:54 +0300
> From: Andriy Gapon <avg at FreeBSD.org>
> Subject: Re: mount root from zfs fails under current with "error 6"
> To: Michael Reifenberger <mike at reifenberger.com>
> Cc: Garrett Cooper <yanegomi at gmail.com>, pjd at FreeBSD.org,
> FreeBSD-Current <current at FreeBSD.org>
> Message-ID: <4DE54176.3080702 at FreeBSD.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> on 31/05/2011 20:38 Michael Reifenberger said the following:
>> Hi,
>>
>> On Tue, 31 May 2011, Michael Reifenberger wrote:
>> ...
>>> (fs)(root) gpart show ada0
>>> => 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)
>>>
>> ...
>>
>> maybe I found something:
>> After setting vfs.zfs.debug=1 I got two new verbose bootlogs:
>> http://people.freebsd.org/~mr/boot_fail2.txt
>> http://people.freebsd.org/~mr/boot_success2.txt
>>
>> 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
>> correct devices)
>
> Maybe try to enable GEOM debug to see if/when tasting of the GPT partitions occurs.
> --
> Andriy Gapon
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 31 May 2011 22:21:42 +0200
> From: Luigi Rizzo <rizzo at iet.unipi.it>
> Subject: "lazy" mmap for a device driver ?
> To: current at freebsd.org
> Message-ID: <20110531202142.GA7105 at onelab2.iet.unipi.it>
> Content-Type: text/plain; charset=us-ascii
>
> 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().
>
> 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 ?
>
> thanks
> luigi
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 31 May 2011 23:45:18 +0300
> From: Kostik Belousov <kostikbel at gmail.com>
> Subject: Re: "lazy" mmap for a device driver ?
> To: Luigi Rizzo <rizzo at iet.unipi.it>
> Cc: current at freebsd.org
> Message-ID: <20110531204518.GX48734 at deviant.kiev.zoral.com.ua>
> Content-Type: text/plain; charset="us-ascii"
>
> 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().
>>
>> 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 ?
>
> 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.
>
> More, the driver can do any appropriate setup by ctr method.
> The new interface is supposed to be used with d_mmap_single().
>
> 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/20110531/6e617d43/attachment-0001.pgp
>
> ------------------------------
>
> Message: 11
> Date: Tue, 31 May 2011 16:50:14 -0400
> From: Jung-uk Kim <jkim at FreeBSD.org>
> Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge)
> To: Xin LI <delphij at gmail.com>
> Cc: "George V. Neville-Neil" <gnn at neville-neil.com>,
> freebsd-current at freebsd.org, Johannes Dieterich
> <dieterich.joh at googlemail.com>
> Message-ID: <201105311650.16164.jkim at FreeBSD.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Friday 27 May 2011 01:14 pm, Xin LI wrote:
>> On Thu, May 19, 2011 at 5:18 AM, Johannes Dieterich
>>
>> <dieterich.joh at googlemail.com> wrote:
>>> On Wed, May 18, 2011 at 7:40 PM, Xin LI <delphij at delphij.net>
> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>> Try this patch?
>>>
>>> The attached patch makes 9-CURRENT-amd64 boot on the X220 w/o any
>>> hints or BIOS fixes needed. Thanks a lot! :-)
>>>
>>>> (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)
>>>
>>> What does this mean concerning getting the fix into CURRENT?
>>
>> 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.
>>
>> 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.
>>
>> 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).
>
> 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. :-(
>
> Are you guys sure that INT 15h is causing hangs? Maybe INT 16h is the
> real culprit (which is more probable, BTW)?
>
> Jung-uk Kim
>
>
> ------------------------------
>
> Message: 12
> Date: Tue, 31 May 2011 16:56:25 -0400
> From: Jung-uk Kim <jkim at FreeBSD.org>
> Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge)
> To: Xin LI <delphij at gmail.com>
> Cc: "George V. Neville-Neil" <gnn at neville-neil.com>,
> freebsd-current at freebsd.org, Johannes Dieterich
> <dieterich.joh at googlemail.com>
> Message-ID: <201105311656.27244.jkim at FreeBSD.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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. :-(
>>
>> Are you guys sure that INT 15h is causing hangs? Maybe INT 16h is
>> the real culprit (which is more probable, BTW)?
>
> BTW, it shouldn't call INT 16h at all unless INT 15h succeeded
> somehow. So, I am totally lost. :-(
>
> Jung-uk Kim
>
>
> ------------------------------
>
> Message: 13
> Date: Tue, 31 May 2011 20:03:28 -0400
> From: Jung-uk Kim <jkim at FreeBSD.org>
> Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge)
> To: Xin LI <delphij at gmail.com>
> Cc: "George V. Neville-Neil" <gnn at neville-neil.com>,
> freebsd-current at freebsd.org, Johannes Dieterich
> <dieterich.joh at googlemail.com>
> Message-ID: <201105312003.29931.jkim at FreeBSD.org>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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
>>>
>>> <dieterich.joh at googlemail.com> wrote:
>>>> On Wed, May 18, 2011 at 7:40 PM, Xin LI <delphij at delphij.net>
>>
>> wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA256
>>>>>
>>>>> Try this patch?
>>>>
>>>> The attached patch makes 9-CURRENT-amd64 boot on the X220 w/o
>>>> any hints or BIOS fixes needed. Thanks a lot! :-)
>>>>
>>>>> (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)
>>>>
>>>> What does this mean concerning getting the fix into CURRENT?
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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).
>>
>> 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. :-(
>>
>> Are you guys sure that INT 15h is causing hangs? Maybe INT 16h is
>> the real culprit (which is more probable, BTW)?
>
> I found something strange about this BIOS (well, if we can call it
> that). Please try this:
>
> Index: sys/dev/atkbdc/atkbd.c
> ===================================================================
> --- 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);
>
> - if (x86bios_get_intr(0x15) == 0 || x86bios_get_intr(0x16) == 0)
> + if (x86bios_get_intr(0x15) != 0xf000f859 ||
> + x86bios_get_intr(0x16) != 0xf000e82e)
> return (ENODEV);
>
> /* Is BIOS system configuration table supported? */
>
> You must re-enable typematic probing from loader to test it, of
> course. I think the following line should do:
>
> hint.atkbd.0.flags="0x10"
>
> Note: You may add printf() before and after the check to make sure it
> is being called (and it fails immediately).
>
> A long answer goes like this. INT 0x15 and 0x16 vectors have fixed
> entry points in *real* BIOS, i.e., 0xf000:0xf859 and 0xf000:0xe82e.
> For this BIOS (or CSM), INT 0x16 vector is correct but INT 0x15
> vector is not (0xf000:0xb4f1). Funny thing is 0xf000:0xf859 actually
> points to a working INT 15h handler, it seems, which confused me
> totally. Probably it was done like this because (U)EFI CSM spec.
> mandated it to be located @ 0xf000:0xf859. If we follow the
> interrupt vector (0xf000:0xb4f1), it gets nowhere (or jumps to an
> unknown external interrupt handler). If we follow the fixed address,
> it will exit gracefully. So, actually there are two possible
> solutions, i.e., 1) check whether the interrupt vector is modified
> (the above patch), or 2) jump directly to the fixed interrupt entry
> point. I chose Option #1 because it is very hard to find BIOS
> typematic support these days (as you pointed out).
>
> Cheers,
>
> Jung-uk Kim
>
>
> ------------------------------
>
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
> End of freebsd-current Digest, Vol 398, Issue 3
> ***********************************************
More information about the freebsd-current
mailing list