Re: freebsd-current Digest, Vol 398, Issue 3





On Jun 1, 2011, at 8:03, freebsd-current-request@xxxxxxxxxxx wrote:

Send freebsd-current mailing list submissions to
freebsd-current@xxxxxxxxxxx

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@xxxxxxxxxxx

You can reach the person managing the list at
freebsd-current-owner@xxxxxxxxxxx

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@xxxxxxxxxxxxxxxxx>
Subject: Re: Testing new nfs and VIMAGE
To: freebsd-current@xxxxxxxxxxx
Cc: Rick Macklem <rmacklem@xxxxxxxxxxx>
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@xxxxxxxxxxx> 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@xxxxxxxxxxx>
Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code
To: Andriy Gapon <avg@xxxxxxxxxxx>
Cc: "freebsd-current@xxxxxxxxxxx" <freebsd-current@xxxxxxxxxxx>,
"freebsd-arch@xxxxxxxxxxx" <freebsd-arch@xxxxxxxxxxx>
Message-ID: <BANLkTinLwVZqQ3C0E4Ey=tWNV5bLZ+Ugcw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8

2011/5/31 Andriy Gapon <avg@xxxxxxxxxxx>:
on 29/05/2011 06:06 Attilio Rao said the following:
2011/5/28 Attilio Rao <attilio@xxxxxxxxxxx>:
2011/5/25 Andriy Gapon <avg@xxxxxxxxxxx>:
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@xxxxxxxxxxx>
Subject: Re: [rfc] remove hlt_cpus et al sysctls and related code
To: Attilio Rao <attilio@xxxxxxxxxxx>
Cc: "freebsd-current@xxxxxxxxxxx" <freebsd-current@xxxxxxxxxxx>,
"freebsd-arch@xxxxxxxxxxx" <freebsd-arch@xxxxxxxxxxx>
Message-ID: <4DE4EFDD.8070803@xxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii

on 31/05/2011 16:34 Attilio Rao said the following:
2011/5/31 Andriy Gapon <avg@xxxxxxxxxxx>:
on 29/05/2011 06:06 Attilio Rao said the following:
2011/5/28 Attilio Rao <attilio@xxxxxxxxxxx>:
2011/5/25 Andriy Gapon <avg@xxxxxxxxxxx>:
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@xxxxxxxxxxxxx>
Subject: Re: ZFS install from -CURRENT snapshot
To: Daniel Staal <DStaal@xxxxxxx>
Cc: freebsd-current@xxxxxxxxxxx, George Kontostanos
<gkontos.mail@xxxxxxxxx>
Message-ID: <20110531160449.19667dub2cfejdkx@xxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"

Quoting Daniel Staal <DStaal@xxxxxxx> (from Mon, 30 May 2011 11:01:06 -0400):

--As of May 29, 2011 9:10:57 AM -0400, George Kontostanos,
freebsd-current@xxxxxxxxxxx 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@xxxxxxxxxxx>
Subject: Re: pcib allocation failure
To: freebsd-current@xxxxxxxxxxx
Cc: "deeptech71@xxxxxxxxx" <deeptech71@xxxxxxxxx>
Message-ID: <201105311039.37935.jhb@xxxxxxxxxxx>
Content-Type: Text/Plain; charset="iso-8859-1"

On Saturday, May 28, 2011 9:45:48 pm deeptech71@xxxxxxxxx wrote:
On Thu, May 26, 2011 at 3:40 PM, John Baldwin <jhb@xxxxxxxxxxx> 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@xxxxxxxxxxx>
Subject: Re: message buffer scrambling fix
To: Julian Elischer <julian@xxxxxxxxxxx>
Cc: current@xxxxxxxxxxx
Message-ID: <20110531154215.GA45877@xxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxx


------------------------------

Message: 7
Date: Tue, 31 May 2011 19:38:50 +0200 (CEST)
From: Michael Reifenberger <mike@xxxxxxxxxxxxxxxx>
Subject: Re: mount root from zfs fails under current with "error 6"
To: pjd@xxxxxxxxxxx
Cc: Garrett Cooper <yanegomi@xxxxxxxxx>, FreeBSD-Current
<current@xxxxxxxxxxx>
Message-ID: <alpine.BSF.2.00.1105311925330.3376@xxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxx
http://www.Reifenberger.com



------------------------------

Message: 8
Date: Tue, 31 May 2011 22:28:54 +0300
From: Andriy Gapon <avg@xxxxxxxxxxx>
Subject: Re: mount root from zfs fails under current with "error 6"
To: Michael Reifenberger <mike@xxxxxxxxxxxxxxxx>
Cc: Garrett Cooper <yanegomi@xxxxxxxxx>, pjd@xxxxxxxxxxx,
FreeBSD-Current <current@xxxxxxxxxxx>
Message-ID: <4DE54176.3080702@xxxxxxxxxxx>
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@xxxxxxxxxxxx>
Subject: "lazy" mmap for a device driver ?
To: current@xxxxxxxxxxx
Message-ID: <20110531202142.GA7105@xxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxx>
Subject: Re: "lazy" mmap for a device driver ?
To: Luigi Rizzo <rizzo@xxxxxxxxxxxx>
Cc: current@xxxxxxxxxxx
Message-ID: <20110531204518.GX48734@xxxxxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxx>
Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge)
To: Xin LI <delphij@xxxxxxxxx>
Cc: "George V. Neville-Neil" <gnn@xxxxxxxxxxxxxxxx>,
freebsd-current@xxxxxxxxxxx, Johannes Dieterich
<dieterich.joh@xxxxxxxxxxxxxx>
Message-ID: <201105311650.16164.jkim@xxxxxxxxxxx>
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@xxxxxxxxxxxxxx> wrote:
On Wed, May 18, 2011 at 7:40 PM, Xin LI <delphij@xxxxxxxxxxx>
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@xxxxxxxxxxx>
Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge)
To: Xin LI <delphij@xxxxxxxxx>
Cc: "George V. Neville-Neil" <gnn@xxxxxxxxxxxxxxxx>,
freebsd-current@xxxxxxxxxxx, Johannes Dieterich
<dieterich.joh@xxxxxxxxxxxxxx>
Message-ID: <201105311656.27244.jkim@xxxxxxxxxxx>
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@xxxxxxxxxxx>
Subject: Re: Boot halts on Thinkpad X220 (Sandy Bridge)
To: Xin LI <delphij@xxxxxxxxx>
Cc: "George V. Neville-Neil" <gnn@xxxxxxxxxxxxxxxx>,
freebsd-current@xxxxxxxxxxx, Johannes Dieterich
<dieterich.joh@xxxxxxxxxxxxxx>
Message-ID: <201105312003.29931.jkim@xxxxxxxxxxx>
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@xxxxxxxxxxxxxx> wrote:
On Wed, May 18, 2011 at 7:40 PM, Xin LI <delphij@xxxxxxxxxxx>

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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

End of freebsd-current Digest, Vol 398, Issue 3
***********************************************
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages