[lkml]   [2011]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Lock up when faking MMIO read[bwl] on some machines [WAS: Faking MMIO ops? Fooling a driver]
    W dniu 18 czerwca 2011 12:57 użytkownik Rafał Miłecki
    <> napisał:
    > W dniu 18 czerwca 2011 12:39 użytkownik Pekka Paalanen <> napisał:
    >> On Sat, 18 Jun 2011 00:31:32 +0200
    >> Rafał Miłecki <> wrote:
    >>> I use attached patch to fake result of read[bwl] performed by
    >>> closed source driver (ndiswrapper+bcmwl and wl).
    >>> 1) It works great on my Sony VAIO with Intel(R) Core(TM)2 Duo CPU
    >>> P8400 2) It locks up Macbook Pro 8,1 with some 8-cores Intel
    >>> Do you have any idea why it causes the lockup? Function causing
    >>> problem is "set_ins_reg_val". I've created it as copy of
    >>> get_ins_reg_val, it just sets values in struct pt_regs, instead of
    >>> reading them).
    >> Sorry, I have no insight to that... does unmodified mmiotrace
    >> work properly? Are you tracing the exact same kernel binary blob
    >> on both machines? Maybe it's using some rare instruction
    >> mmiotrace does not decode properly? Maybe with a rep prefix?
    >> Do those CPUs have any differences in their registers or
    >> struct pt_regs?
    >> I'm not even sure how "legal" it is to poke pt_regs there. :-/
    > Not modified MMIO tracing works great on this machine, I've grabbed
    > dumps 10-20 times without a lock up or anything.
    > I'm using different drivers on both machines, because Macbook Pro 8,1
    > has unique BCM4331 card that I can not buy and that is not available
    > with PCI(e) slot. Is uses some vendor specific, PCIe compatible slot.
    > Simple commenting out "set_ins_reg_val" work fine on this Macbook, PHY
    > reads are tracked correctly.
    > As for differences in struct pt_regs... yeah, I think that happens.
    > I'm using x86 kernel, while on Macbook we use x86_64 as it's required
    > to use 64bit driver in ndiswrapper.
    > I can try to find out, which register we try to overwrite on Macbook.

    This is what does happen on my machine (working):
    [ 122.550991] mmiotrace: ZAJEC: read PHY 0x20
    [ 122.550994] mmiotrace: ZAJEC: overwriting 0x20 with 0xFFFF
    [ 122.550997] [ZAJEC] setting AX with 0xFFFF
    [ 122.551071] mmiotrace: ZAJEC: read PHY 0x22
    [ 122.551074] mmiotrace: ZAJEC: overwriting 0x22 with 0xFFFF
    [ 122.551077] [ZAJEC] setting AX with 0xFFFF
    [ 122.551198] mmiotrace: ZAJEC: read PHY 0x27
    [ 122.551201] mmiotrace: ZAJEC: overwriting 0x27 with 0xFFFF
    [ 122.551204] [ZAJEC] setting AX with 0xFFFF

    This is what does happen on Macbook:
    [ 166.886438] mmiotrace: ZAJEC: read PHY 0x810
    [ 166.886649] mmiotrace: ZAJEC: overwriting 0x810 with 0xFFFF
    [ 166.886860] [ZAJEC] setting AX with 0xFFFF

    So on both machines we modify AX register in the same place. My
    function set_ins_reg_val is a copy of get_ins_reg_val which works
    fine... So no idea what may we be doing wrong on this Macbook

    You can see I've changed 0x20, 0x22, 0x27 to 0x810 on Macbook. That's
    because first 3 registers are not used by BCM4331. I've been testing
    them with BCM43225.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2011-06-18 13:29    [W:0.024 / U:1.900 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site