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]
Message-ID: <4F13C333.4050609@intel.com>
Date:	Sun, 15 Jan 2012 22:26:59 -0800
From:	Darren Hart <darren.hart@...el.com>
To:	Tomoya MORINAGA <tomoya.rohm@...il.com>
CC:	"lkml," <linux-kernel@...r.kernel.org>,
	Wang Qi <qi.wang@...el.com>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: Porting pch_pcieqos to 3.2 for Intel EG20T with no MAC

On 01/15/2012 07:06 PM, Tomoya MORINAGA wrote:
> Hi Darren,
> 
> Can you execute like below
> root@(none):/# find /sys/bus/pci/drivers/pch_phub/0000:02:00.0
> 
> You must see pch_mac.
> 
> Or
> Is your pch_phub integrated as module ?
> If module, you can access from below.
> /sys/module/pch_phub/drivers/pci:pch_phub/0000:02:00.0

I have since resolved this particular issue. I did not disable the
pcieqos driver I forward ported. With that disabled, pch_phub works as
expected. Which is to say it lists pch_mac, reads all 0's, and does
nothing on write (since the MAC ROM doesn't exist). Please see the patch
thread from Friday to address this using a random mac if the ROM is
missing or invalid.

--
Darren

> 
> thanks,
> tomoya
> 
> 
> 2012/1/14 Darren Hart <darren.hart@...el.com>:
>> On 01/10/2012 05:58 PM, Darren Hart wrote:
>>> I find myself with a development board with no MAC address for the pch_gbe in
>>> the Platform Controller Hub EG20T. I've dusted off an old patch and am trying
>>> to get it working so it can be included upstream.
>>>
>>> I found the phub_util_mac utility on sourceforge which appears to require the
>>> following patch:
>>>
>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-extras/plain/recipes-kernel/linux/linux-netbook-2.6.33.2/linux-2.6.34-pch-pcieqos.patch
>>>
>>> I've made the obvious changes to the driver to use unlocked_ioctl as ioctl has
>>> been removed upstream. With this driver built and installed, the
>>> topcliff_mac_util command reports no errors and reads the MAC address as:
>>>
>>> 00:00:00:00:00:00
>>>
>>> Trying to set it reports no errors either, and the instrumentation suggests it
>>> is at least trying to write the correct data. Reading back still results in all
>>> zeros.
>>>
>>> During boot, the pch_gbe driver reports:
>>> [    2.211233] pch_gbe 0000:02:00.1: enabling device (0000 -> 0003)
>>> [    2.217271] pch_gbe 0000:02:00.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
>>> [    2.224349] pch_gbe 0000:02:00.1: setting latency timer to 64
>>> [    2.233388] pch_gbe 0000:02:00.1: Invalid MAC Address
>>> [    2.238821] pch_gbe 0000:02:00.1: PCI INT A disabled
>>> [    2.243809] pch_gbe: probe of 0000:02:00.1 failed with error -5
>>>
>>> The patch itself follows, I have attached a rather lengthy log which includes a
>>> read/write/read cycle demonstrating the write not taking effect.
>>>
>>> Can you shed some light on why this might be the case?
>>
>> After stumbling around blindly for a bit longer, I ran across the pch_phub
>> driver, which appears to be intended for the same purpose, but uses a sysfs
>> interface rather than an ioctl interface with a separate userpsace utility.
>> Do I have this right?
>>
>> Enabling this driver doesn't change the above pch_gbe messages which still
>> include the failed probe of 0000:02:00.1. pch_phub has entries in /sys:
>>
>> root@(none):/# find /sys/bus/pci/drivers/pch_phub
>> /sys/bus/pci/drivers/pch_phub
>> /sys/bus/pci/drivers/pch_phub/uevent
>> /sys/bus/pci/drivers/pch_phub/unbind
>> /sys/bus/pci/drivers/pch_phub/bind
>> /sys/bus/pci/drivers/pch_phub/new_id
>> /sys/bus/pci/drivers/pch_phub/remove_id
>>
>> but no "pch_mac" as I was expecting after reviewing pch_phub.c.
>>
>> Am I still barking up the wrong tree here?
>>
>> --
>> Darren Hart
>> Intel Open Source Technology Center
>> Yocto Project - Linux Kernel


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ