lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Tue, 18 Mar 2014 15:00:46 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	linux-kernel@...r.kernel.org
Subject: Re: v3.14-rc1+: new error: "nsc-ircc, Wrong chip version ff"

Paul Bolle <pebolle@...cali.nl> writes:

> Rafael,
>
> 0) Ever since v3.14-rc1 I've noticed two new boot messages on an,
> outdated, ThinkPad X41:
>     nsc-ircc, Found chip at base=0x164e
>     nsc-ircc, Wrong chip version ff

Looks like that driver calls request_region for its "fir_base" IO ports
too late.

Parts of nsc_ircc_open:

..
        IRDA_MESSAGE("%s, Found chip at base=0x%03x\n", driver_name,
                     info->cfg_base);

        if ((nsc_ircc_setup(info)) == -1)
                return -1;

=> fails while attempting to write to info->fir_base + 3 and then read
   from info->fir_base + 0

..
        /* Initialize IO */
        self->io.cfg_base  = info->cfg_base;
        self->io.fir_base  = info->fir_base;
        self->io.irq       = info->irq;
        self->io.fir_ext   = CHIP_IO_EXTENT;
        self->io.dma       = info->dma;
        self->io.fifo_size = 32;
        
        /* Reserve the ioports that we need */
        ret = request_region(self->io.fir_base, self->io.fir_ext, driver_name);

Maybe reorder this a bit, requesting the fir_base IO ports before
calling nsc_ircc_setup?  You'll have to reorder the error cleanups too.


> The first is printed at info level, so I would have ignored it, but the
> second is printed at error level.
>
> 1) I've finally managed to bisect these messages to commit 202317a573b2
> ("ACPI / scan: Add acpi_device objects for all device nodes in the
> namespace"). That's a rather big commit, so I've not even bothered to
> try to revert it on top on v3.14-rc6.

My guess is that you've got some pnp device now claiming the FIR IO
ports.  cat /proc/ioports may help you find out what to look for?


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists