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_at_[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_at_ 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 _at_ Leidinger.net: PGP ID = B0063FE7 > http://www.FreeBSD.org netchild _at_ 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) >>> _at__at_ -162,8 +162,13 _at__at_ 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) { >>> _at__at_ -192,6 +197,8 _at__at_ 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 >>> _at__at_ -337,6 +344,9 _at__at_ 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) > _at__at_ -1100,7 +1100,8 _at__at_ 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 _at_ 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 > ***********************************************Received on Wed Jun 01 2011 - 12:35:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:14 UTC