Foxconn NanoPC nT-i1250 fails to boot after install

[Kent Fritz]

Install works fine, but consistently stops after printing:
wskbd0 at pckbd0: console keyboard, using wsdisplay0

Same behavior for 5.2 release, current, amd64 and i386, and another
model nT-i2847.  Any hints where to poke next?

dmesg from booting bsd.rd follows.  Thanks.

Kent

OpenBSD 5.2-current (RAMDISK_CD) #14: Tue Jan  8 14:28:01 MST 2013
    [hidden email]:/usr/src/sys/arch/i386/compile/RAMDISK_CD
cpu0: Intel(R) Atom(TM) CPU D2550 @ 1.86GHz ("GenuineIntel" 686-class) 1.87 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,LAHF,PERF,ITSC
real mem  = 2132189184 (2033MB)
avail mem = 2089598976 (1992MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 05/09/11, SMBIOS rev. 2.7 @
0x7f002010 (46 entries)
bios0: vendor American Megatrends Inc. version "4.6.5" date 03/14/2012
bios0: Foxconn nT-i1000 Series
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG SSDT SSDT SSDT IFEU
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 133MHz
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 4 pa 0xfec00000, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 3 (P0P8)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus 2 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
bios0: ROM list: 0xc0000/0xf400! 0xcf800/0x1000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x0bf3 rev 0x03
vga1 at pci0 dev 2 function 0 vendor "Intel", unknown product 0x0be2 rev 0x09
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: apic 4 int 16
pci1 at ppb0 bus 1
vendor "Intel", unknown product 0x0890 (class network subclass
miscellaneous, rev 0xc4) at pci1 dev 0 function 0 not configured
ppb1 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x02: apic 4 int 17
pci2 at ppb1 bus 2
re0 at pci2 dev 0 function 0 "Realtek 8168" rev 0x07:
RTL8168E/8111E-VL (0x2c80), apic 4 int 17, address d0:27:88:d5:72:6e
rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 5
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 4 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 4 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 4 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 4 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 4 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb2 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
pci3 at ppb2 bus 3
pcib0 at pci0 dev 31 function 0 "Intel NM10 LPC" rev 0x02
ahci0 at pci0 dev 31 function 2 "Intel 82801GR AHCI" rev 0x02: msi, AHCI 1.1
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: <ATA, WDC WD1600BEVT-0, 01.0> SCSI3
0/direct fixed naa.50014ee657159cc7
sd0: 152627MB, 512 bytes/sector, 312581808 sectors
"Intel 82801GB SMBus" rev 0x02 at pci0 dev 31 function 3 not configured
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb3 at uhci2: USB revision 1.0
uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb4 at uhci3: USB revision 1.0
uhub4 at usb4 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
umass0 at uhub0 port 6 configuration 1 interface 0 " CENTON USB" rev
2.00/11.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus1 at umass0: 2 targets, initiator 0
sd1 at scsibus1 targ 1 lun 0: <CENTON, , 1100> SCSI2 0/direct
removable serial.090c1000000000002196
sd1: 30600MB, 512 bytes/sector, 62668800 sectors
umass1 at uhub0 port 7 configuration 1 interface 0 "Generic
USB2.0-CRW" rev 2.00/38.82 addr 3
umass1: using SCSI over Bulk-Only
scsibus2 at umass1: 2 targets, initiator 0
sd2 at scsibus2 targ 1 lun 0: <Generic-, Multi-Card, 1.00> SCSI0
0/direct removable serial.0bda0138516388200000
uhub5 at uhub0 port 8 "vendor 0x105b product 0x0d7d" rev 2.00/77.64 addr 4
uhub6 at uhub3 port 1 "ALCOR Generic USB Hub" rev 1.10/3.12 addr 2
uhidev0 at uhub6 port 1 configuration 1 interface 0 "Dell Dell USB
Keyboard" rev 1.10/3.01 addr 3
uhidev0: iclass 3/1
ukbd0 at uhidev0
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
uhidev1 at uhub6 port 2 configuration 1 interface 0 "vendor 0x0461 USB
Optical Mouse" rev 2.00/2.00 addr 4
uhidev1: iclass 3/1
uhid at uhidev1 not configured
uhidev2 at uhub6 port 3 configuration 1 interface 0 "No brand 4 Port
KVMSwicther" rev 1.10/1.00 addr 5
uhidev2: iclass 3/0
ukbd1 at uhidev2
wskbd2 at ukbd1 mux 1
wskbd2: connecting to wsdisplay0
uhidev3 at uhub6 port 3 configuration 1 interface 1 "No brand 4 Port
KVMSwicther" rev 1.10/1.00 addr 5
uhidev3: no input interrupt endpoint
softraid0 at root
scsibus3 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b

[Stefan Sperling-8]

On Wed, Jan 09, 2013 at 04:30:21PM -0800, Kent Fritz wrote:
> Install works fine, but consistently stops after printing:
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
>
> Same behavior for 5.2 release, current, amd64 and i386, and another
> model nT-i2847.  Any hints where to poke next?

Shot in the dark: Does it not hang if you disable the pms driver
via boot -c? See the boot_config(8) man page.

The RAMDISK_CD kernel doesn't have pms compiled in, and it might be
the next thing pckbd0 is trying to initialise in the GENERIC kernel.

[Kent Fritz]

On Wed, Jan 9, 2013 at 5:34 PM, Stefan Sperling <[hidden email]> wrote:
> Shot in the dark: Does it not hang if you disable the pms driver
> via boot -c? See the boot_config(8) man page.
>
> The RAMDISK_CD kernel doesn't have pms compiled in, and it might be
> the next thing pckbd0 is trying to initialise in the GENERIC kernel.

You must have night-vision goggles -- that did the trick.  If there's
anything I can do to help debug this further, let me know.  Otherwise,
I'm happy with the workaround.

[Stefan Sperling-8]

On Thu, Jan 10, 2013 at 08:56:15AM -0800, Kent Fritz wrote:

> On Wed, Jan 9, 2013 at 5:34 PM, Stefan Sperling <[hidden email]> wrote:
> > Shot in the dark: Does it not hang if you disable the pms driver
> > via boot -c? See the boot_config(8) man page.
> >
> > The RAMDISK_CD kernel doesn't have pms compiled in, and it might be
> > the next thing pckbd0 is trying to initialise in the GENERIC kernel.
>
> You must have night-vision goggles -- that did the trick.  If there's
> anything I can do to help debug this further, let me know.  Otherwise,
> I'm happy with the workaround.

Can you please try to find out which protocol probe routine is
responsible for hanging the machine?

There is a table of protocols in /usr/src/sys/dev/pckbc/pms.c.
In -current, it looks like this:

        const struct pms_protocol pms_protocols[] = {
                /* Generic PS/2 mouse */
                {
                        PMS_STANDARD, 3,
                        NULL, pms_ioctl_mouse,
                        pms_sync_mouse,
                        pms_proc_mouse,
                        NULL
                },
                /* Microsoft IntelliMouse */
                {
                        PMS_INTELLI, 4,
                        pms_enable_intelli,
                        pms_ioctl_mouse,
                        pms_sync_mouse,
                        pms_proc_mouse,
                        NULL
                },
                /* Synaptics touchpad */
                {
                        PMS_SYNAPTICS, 6,
                        pms_enable_synaptics,
                        pms_ioctl_synaptics,
                        pms_sync_synaptics,
                        pms_proc_synaptics,
                        pms_disable_synaptics
                },
                /* ALPS touchpad */
                {
                        PMS_ALPS, 6,
                        pms_enable_alps,
                        pms_ioctl_alps,
                        pms_sync_alps,
                        pms_proc_alps,
                        NULL
                },
        #ifdef notyet
                /* Elantech touchpad (hardware version 1) */
                {
                        PMS_ELANTECH_V1, 4,
                        pms_enable_elantech_v1,
                        pms_ioctl_elantech,
                        pms_sync_elantech_v1,
                        pms_proc_elantech_v1,
                        NULL
                },
                /* Elantech touchpad (hardware version 2) */
                {
                        PMS_ELANTECH_V2, 6,
                        pms_enable_elantech_v2,
                        pms_ioctl_elantech,
                        pms_sync_elantech_v2,
                        pms_proc_elantech_v2,
                        NULL
                },
        #endif
                /* Elantech touchpad (hardware version 3) */
                {
                        PMS_ELANTECH_V3, 6,
                        pms_enable_elantech_v3,
                        pms_ioctl_elantech,
                        pms_sync_elantech_v3,
                        pms_proc_elantech_v3,
                        NULL
                },
        };

Perhaps start by removing the touchpad protocols first, since
they're most likely to be the cause of this problem.
You could comment out all the touchpad protocols like this:

        const struct pms_protocol pms_protocols[] = {
                /* Generic PS/2 mouse */
                {
                        PMS_STANDARD, 3,
                        NULL, pms_ioctl_mouse,
                        pms_sync_mouse,
                        pms_proc_mouse,
                        NULL
                },
                /* Microsoft IntelliMouse */
                {
                        PMS_INTELLI, 4,
                        pms_enable_intelli,
                        pms_ioctl_mouse,
                        pms_sync_mouse,
                        pms_proc_mouse,
                        NULL
                },
        #if 0   <-- add this here
                /* Synaptics touchpad */
                {

        ...skipping all the lines in-between...

                        pms_sync_elantech_v3,
                        pms_proc_elantech_v3,
                        NULL
                },
        #endif  <-- add this here
        };

If that doesn't hang it, move the #if 0 further down to the next
protocol, and try again.

Note that elantech v1 and elantech v2 are currently disabled
anyway (via #ifdef notyet) because the code hasn't yet been
tested on real hardware. (BTW, in case an eeepc owner is reading
this, you might have such a touchpad, so please try enabling
the v1 and v2 protocols to see if that makes the synaptics
driver attach in X and if the touchpad then works properly).

Once we know which protocol probe routine is causing the
problem we can dig further.

[Kent Fritz]

On Thu, Jan 10, 2013 at 9:26 AM, Stefan Sperling <[hidden email]> wrote:
> Can you please try to find out which protocol probe routine is
> responsible for hanging the machine?
>
None of them.  I tried as you suggested, then just #if'd  out every
entry in that structure.  No change in behavior.

(BTW: First time compiling my own kernel.  The FAQ rocks!)

[Martin Pieuchot-2]

On 10/01/13(Thu) 14:08, Kent Fritz wrote:
> On Thu, Jan 10, 2013 at 9:26 AM, Stefan Sperling <[hidden email]> wrote:
> > Can you please try to find out which protocol probe routine is
> > responsible for hanging the machine?
> >
> None of them.  I tried as you suggested, then just #if'd  out every
> entry in that structure.  No change in behavior.
>
> (BTW: First time compiling my own kernel.  The FAQ rocks!)

Do you have any "usb legacy" option or similar turned on in your bios?
If yes you can try to turn it off.

M.

[Kenneth R Westerback]

On Fri, Jan 11, 2013 at 01:16:53PM +0100, Martin Pieuchot wrote:

> On 10/01/13(Thu) 14:08, Kent Fritz wrote:
> > On Thu, Jan 10, 2013 at 9:26 AM, Stefan Sperling <[hidden email]> wrote:
> > > Can you please try to find out which protocol probe routine is
> > > responsible for hanging the machine?
> > >
> > None of them.  I tried as you suggested, then just #if'd  out every
> > entry in that structure.  No change in behavior.
> >
> > (BTW: First time compiling my own kernel.  The FAQ rocks!)
>
> Do you have any "usb legacy" option or similar turned on in your bios?
> If yes you can try to turn it off.
>
> M.
>

It was "USB Legacy Storage" on one of my machines. If this was on, then
booting hung in the BIOS if a USB disk was plugged in and then the boot
was attempted.

.... Ken

[Kent Fritz]

I dug a little deeper, and defined PCKBCDEBUG in
/usr/src/sys/dev/ic/pckbc.c, and it spews:
pckbc_cmd: lost 0xfc

Looking at pckbc_poll_cmd1, it looks like there's an infinite loop if
it doesn't get back a response it expects.  What's best: specifically
handling 0xfc, or erroring out on any unexpected response with
"cmd->status = ENXIO; return;"?  (I did the former and it works for
me.)

[Stefan Sperling-8]

On Fri, Jan 11, 2013 at 04:44:07PM -0800, Kent Fritz wrote:
> I dug a little deeper, and defined PCKBCDEBUG in
> /usr/src/sys/dev/ic/pckbc.c, and it spews:
> pckbc_cmd: lost 0xfc
>
> Looking at pckbc_poll_cmd1, it looks like there's an infinite loop if
> it doesn't get back a response it expects.  What's best: specifically
> handling 0xfc, or erroring out on any unexpected response with
> "cmd->status = ENXIO; return;"?  (I did the former and it works for
> me.)

I see. So this is happening during pms_probe() which runs before the
protocol is selected. Maybe fix it like this? I think the code should
cope with hardware that returns unrecognizable garbage. But I don't
know very much about PS/2.

Thanks for pinning down the problem!

Index: pckbc.c
===================================================================
RCS file: /cvs/src/sys/dev/ic/pckbc.c,v
retrieving revision 1.31
diff -u -p -r1.31 pckbc.c
--- pckbc.c 17 Oct 2012 19:16:10 -0000 1.31
+++ pckbc.c 12 Jan 2013 01:25:41 -0000
@@ -620,6 +620,11 @@ pckbc_poll_cmd1(struct pckbc_internal *t
 #ifdef PCKBCDEBUG
  printf("pckbc_cmd: lost 0x%x\n", c);
 #endif
+ /* Don't retry cmd forever. */
+ if (cmd->retries++ >= 5) {
+ cmd->status = EIO;
+ return;
+ }
  }
 
  while (cmd->responseidx < cmd->responselen) {

[Kent Fritz]

On Fri, Jan 11, 2013 at 5:29 PM, Stefan Sperling <[hidden email]> wrote:

> I see. So this is happening during pms_probe() which runs before the
> protocol is selected. Maybe fix it like this? I think the code should
> cope with hardware that returns unrecognizable garbage. But I don't
> know very much about PS/2.
>
> Thanks for pinning down the problem!
>
> Index: pckbc.c
> ===================================================================
> RCS file: /cvs/src/sys/dev/ic/pckbc.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 pckbc.c
> --- pckbc.c     17 Oct 2012 19:16:10 -0000      1.31
> +++ pckbc.c     12 Jan 2013 01:25:41 -0000
> @@ -620,6 +620,11 @@ pckbc_poll_cmd1(struct pckbc_internal *t
>  #ifdef PCKBCDEBUG
>                 printf("pckbc_cmd: lost 0x%x\n", c);
>  #endif
> +               /* Don't retry cmd forever. */
> +               if (cmd->retries++ >= 5) {
> +                       cmd->status = EIO;
> +                       return;
> +               }
>         }
>
>         while (cmd->responseidx < cmd->responselen) {

That patch works fine.  Tested on i386 on nT-i1250.  Thanks for
pointing me in the right direction!

[Martin Pieuchot-2]

Hi Kent,

On 14/01/13(Mon) 10:05, Kent Fritz wrote:

> On Fri, Jan 11, 2013 at 5:29 PM, Stefan Sperling <[hidden email]> wrote:
> > I see. So this is happening during pms_probe() which runs before the
> > protocol is selected. Maybe fix it like this? I think the code should
> > cope with hardware that returns unrecognizable garbage. But I don't
> > know very much about PS/2.
> >
> > Thanks for pinning down the problem!
> >
> > Index: pckbc.c
> > ===================================================================
> > RCS file: /cvs/src/sys/dev/ic/pckbc.c,v
> > retrieving revision 1.31
> > diff -u -p -r1.31 pckbc.c
> > --- pckbc.c     17 Oct 2012 19:16:10 -0000      1.31
> > +++ pckbc.c     12 Jan 2013 01:25:41 -0000
> > @@ -620,6 +620,11 @@ pckbc_poll_cmd1(struct pckbc_internal *t
> >  #ifdef PCKBCDEBUG
> >                 printf("pckbc_cmd: lost 0x%x\n", c);
> >  #endif
> > +               /* Don't retry cmd forever. */
> > +               if (cmd->retries++ >= 5) {
> > +                       cmd->status = EIO;
> > +                       return;
> > +               }
> >         }
> >
> >         while (cmd->responseidx < cmd->responselen) {
>
> That patch works fine.  Tested on i386 on nT-i1250.  Thanks for
> pointing me in the right direction!

Could you try the diff below and tell me if it also fix your problem? I
believe it's better to handle the bat failure core (0xfc) like we
already do with the bat completion code rather than exiting for any
value..

M.

Index: pckbc.c
===================================================================
RCS file: /home/ncvs/src/sys/dev/ic/pckbc.c,v
retrieving revision 1.31
diff -u -p -r1.31 pckbc.c
--- pckbc.c 17 Oct 2012 19:16:10 -0000 1.31
+++ pckbc.c 11 Feb 2013 10:24:49 -0000
@@ -48,6 +48,12 @@
 #include <dev/pckbc/pckbdvar.h>
 #endif
 
+#ifdef PCKBCDEBUG
+#define DPRINTF(x...) do { printf(x); } while (0);
+#else
+#define DPRINTF(x...)
+#endif
+
 /* descriptor for one device command */
 struct pckbc_devcmd {
  TAILQ_ENTRY(pckbc_devcmd) next;
@@ -102,9 +108,10 @@ int pckbcintr_internal(struct pckbc_inte
 
 const char *pckbc_slot_names[] = { "kbd", "aux" };
 
-#define KBC_DEVCMD_ACK 0xfa
-#define KBC_DEVCMD_RESEND 0xfe
-#define KBC_DEVCMD_BAT 0xaa
+#define KBC_DEVCMD_ACK 0xfa
+#define KBC_DEVCMD_RESEND 0xfe
+#define KBC_DEVCMD_BAT_DONE 0xaa
+#define KBC_DEVCMD_BAT_FAIL 0xfc
 
 #define KBD_DELAY DELAY(8)
 
@@ -587,39 +594,32 @@ pckbc_poll_cmd1(struct pckbc_internal *t
  break;
  }
 
- if (c == KBC_DEVCMD_ACK) {
+ switch (c) {
+ case KBC_DEVCMD_ACK:
  cmd->cmdidx++;
  continue;
- }
  /*
  * Some legacy free PCs keep returning Basic Assurance Test
  * (BAT) instead of something usable, so fail gracefully.
  */
- if (c == KBC_DEVCMD_RESEND || c == KBC_DEVCMD_BAT) {
-#ifdef PCKBCDEBUG
- printf("pckbc_cmd: %s\n",
+ case KBC_DEVCMD_RESEND:
+ case KBC_DEVCMD_BAT_DONE:
+ case KBC_DEVCMD_BAT_FAIL:
+ DPRINTF("pckbc_cmd: %s\n",
     c == KBC_DEVCMD_RESEND ? "RESEND": "BAT");
-#endif
  if (cmd->retries++ < 5)
  continue;
- else {
-#ifdef PCKBCDEBUG
- printf("pckbc: cmd failed\n");
-#endif
- cmd->status = ENXIO;
- return;
- }
- }
- if (c == -1) {
-#ifdef PCKBCDEBUG
- printf("pckbc_cmd: timeout\n");
-#endif
+
+ DPRINTF("pckbc_cmd: cmd failed\n");
+ cmd->status = ENXIO;
+ return;
+ case -1:
+ DPRINTF("pckbc_cmd: timeout\n");
  cmd->status = EIO;
  return;
+ default:
+ DPRINTF("pckbc_cmd: lost 0x%x\n", c);
  }
-#ifdef PCKBCDEBUG
- printf("pckbc_cmd: lost 0x%x\n", c);
-#endif
  }
 
  while (cmd->responseidx < cmd->responselen) {

[Kent Fritz]

This works for me.  I just installed the latest snapshot, synced the
source, applied your patch, built and installed and it works just
fine.

Hate Gmail for patches, though.

Thanks.  Hope I replied in time to make the 5.3 cut.  :)

Kent.

On Mon, Feb 11, 2013 at 2:34 AM, Martin Pieuchot <[hidden email]> wrote:

> Hi Kent,
>
> On 14/01/13(Mon) 10:05, Kent Fritz wrote:
>> On Fri, Jan 11, 2013 at 5:29 PM, Stefan Sperling <[hidden email]> wrote:
>> > I see. So this is happening during pms_probe() which runs before the
>> > protocol is selected. Maybe fix it like this? I think the code should
>> > cope with hardware that returns unrecognizable garbage. But I don't
>> > know very much about PS/2.
>> >
>> > Thanks for pinning down the problem!
>> >
>> > Index: pckbc.c
>> > ===================================================================
>> > RCS file: /cvs/src/sys/dev/ic/pckbc.c,v
>> > retrieving revision 1.31
>> > diff -u -p -r1.31 pckbc.c
>> > --- pckbc.c     17 Oct 2012 19:16:10 -0000      1.31
>> > +++ pckbc.c     12 Jan 2013 01:25:41 -0000
>> > @@ -620,6 +620,11 @@ pckbc_poll_cmd1(struct pckbc_internal *t
>> >  #ifdef PCKBCDEBUG
>> >                 printf("pckbc_cmd: lost 0x%x\n", c);
>> >  #endif
>> > +               /* Don't retry cmd forever. */
>> > +               if (cmd->retries++ >= 5) {
>> > +                       cmd->status = EIO;
>> > +                       return;
>> > +               }
>> >         }
>> >
>> >         while (cmd->responseidx < cmd->responselen) {
>>
>> That patch works fine.  Tested on i386 on nT-i1250.  Thanks for
>> pointing me in the right direction!
>
> Could you try the diff below and tell me if it also fix your problem? I
> believe it's better to handle the bat failure core (0xfc) like we
> already do with the bat completion code rather than exiting for any
> value..
>
> M.
>
> Index: pckbc.c
> ===================================================================
> RCS file: /home/ncvs/src/sys/dev/ic/pckbc.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 pckbc.c
> --- pckbc.c     17 Oct 2012 19:16:10 -0000      1.31
> +++ pckbc.c     11 Feb 2013 10:24:49 -0000
> @@ -48,6 +48,12 @@
>  #include <dev/pckbc/pckbdvar.h>
>  #endif
>
> +#ifdef PCKBCDEBUG
> +#define DPRINTF(x...)  do { printf(x); } while (0);
> +#else
> +#define DPRINTF(x...)
> +#endif
> +
>  /* descriptor for one device command */
>  struct pckbc_devcmd {
>         TAILQ_ENTRY(pckbc_devcmd) next;
> @@ -102,9 +108,10 @@ int pckbcintr_internal(struct pckbc_inte
>
>  const char *pckbc_slot_names[] = { "kbd", "aux" };
>
> -#define KBC_DEVCMD_ACK 0xfa
> -#define KBC_DEVCMD_RESEND 0xfe
> -#define KBC_DEVCMD_BAT 0xaa
> +#define KBC_DEVCMD_ACK         0xfa
> +#define KBC_DEVCMD_RESEND      0xfe
> +#define KBC_DEVCMD_BAT_DONE    0xaa
> +#define KBC_DEVCMD_BAT_FAIL    0xfc
>
>  #define        KBD_DELAY       DELAY(8)
>
> @@ -587,39 +594,32 @@ pckbc_poll_cmd1(struct pckbc_internal *t
>                                 break;
>                 }
>
> -               if (c == KBC_DEVCMD_ACK) {
> +               switch (c) {
> +               case KBC_DEVCMD_ACK:
>                         cmd->cmdidx++;
>                         continue;
> -               }
>                 /*
>                  * Some legacy free PCs keep returning Basic Assurance Test
>                  * (BAT) instead of something usable, so fail gracefully.
>                  */
> -               if (c == KBC_DEVCMD_RESEND || c == KBC_DEVCMD_BAT) {
> -#ifdef PCKBCDEBUG
> -                       printf("pckbc_cmd: %s\n",
> +               case KBC_DEVCMD_RESEND:
> +               case KBC_DEVCMD_BAT_DONE:
> +               case KBC_DEVCMD_BAT_FAIL:
> +                       DPRINTF("pckbc_cmd: %s\n",
>                             c == KBC_DEVCMD_RESEND ? "RESEND": "BAT");
> -#endif
>                         if (cmd->retries++ < 5)
>                                 continue;
> -                       else {
> -#ifdef PCKBCDEBUG
> -                               printf("pckbc: cmd failed\n");
> -#endif
> -                               cmd->status = ENXIO;
> -                               return;
> -                       }
> -               }
> -               if (c == -1) {
> -#ifdef PCKBCDEBUG
> -                       printf("pckbc_cmd: timeout\n");
> -#endif
> +
> +                       DPRINTF("pckbc_cmd: cmd failed\n");
> +                       cmd->status = ENXIO;
> +                       return;
> +               case -1:
> +                       DPRINTF("pckbc_cmd: timeout\n");
>                         cmd->status = EIO;
>                         return;
> +               default:
> +                       DPRINTF("pckbc_cmd: lost 0x%x\n", c);
>                 }
> -#ifdef PCKBCDEBUG
> -               printf("pckbc_cmd: lost 0x%x\n", c);
> -#endif
>         }
>
>         while (cmd->responseidx < cmd->responselen) {

[Martin Pieuchot-2]

On 14/02/13(Thu) 16:22, Kent Fritz wrote:
> This works for me.  I just installed the latest snapshot, synced the
> source, applied your patch, built and installed and it works just
> fine.
>
> Hate Gmail for patches, though.
>
> Thanks.  Hope I replied in time to make the 5.3 cut.  :)

Yep, it's in thanks.

Martin