On Sun, Jan 4, 2009 at 9:34 PM, David Miller <davem@xxxxxxxxxxxxx> wrote: > From: "Jeff Kirsher" <jeffrey.t.kirsher@xxxxxxxxx> > Date: Sun, 4 Jan 2009 18:20:24 -0800 > >> On Sun, Jan 4, 2009 at 4:06 PM, David Miller <davem@xxxxxxxxxxxxx> wrote: >> > From: "Jeff Kirsher" <jeffrey.t.kirsher@xxxxxxxxx> >> > Date: Tue, 30 Dec 2008 14:33:36 -0800 >> > >> >> Please hold off on committing, until we have had ample time to do some >> >> regression testing. While this patch may have been in linux-next, >> >> this is the first we have seen of it. >> >> >> >> I am concerned that IPMI traffic will be adversely affected by this patch. >> > >> > Status please? >> > -- >> >> The only testing left to do is to make sure that ICH devices still >> work and to make sure the IPMI traffic is not affected by this patch. >> All other testing looks good. I am sorry that I have been slow to >> give status, the holiday's have put a strain on available resources. > > Ok, thanks for the update. > -- > So here is the latest testing update... The only testing that we were not able to do was the IPMI testing, because of the lack of resources. All other testing passed. While all other testing passed, I am concerned about not being able to test whether or not this change affects the ability to pass IPMI traffic. I am not sure if the "gain" of using request_firmware() out weighs the potential risk that IPMI traffic may be broken with this patch. I guess I wondering what the gain is in using the request_firmware() function? >From past experience with IPMI traffic and the e100, the loading of the microcode in the correct manner greatly affected whether IPMI traffic would pass or not. -- Cheers, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
