On Wed, Jul 04, 2007 at 10:55:35AM +0800, Shane Huang wrote: > Hi Dann: > > > > Do you know of any reason these changes wouldn't work on a 2.6.18 > > base? Would you be able to run QA on one of our daily builds if I > > pointed you to snapshot debs with these changes? > > I'm sorry that I do not catch your meaning very much because I'm a > newbie > in Debian, I did not use Debian before and know little about it, the > distribution > I have being using for some time is Redhat/Fedora. My main task here is > to > check whether the SB700 patches have been added into the familiar > distributions > to be released such as Debian 4.1, RHEL5.1 and Fedora 8.
'lenny' is the next major release of Debian (which might be called 4.1). But, that is over a year away whereas adding hardware support to the existing release (4.0, 'etch') is possible sooner. > So could you give me more information about your questions? Such as: > What's the function/usage of "2.6.18 base"? Why are you still using it > if > next Debian 4.1 release will use the kernel after 2.6.23-rc1. etc Debian 'etch' is based on 2.6.18. > > The combined mode patch for sb700 depends on a quirk that was added > > for sb600 after 2.6.18. I could of course backport this quirk only for > > sb700, but is there a good reason for adding it for sb600 as well? > > I think adding both the SB600 patch and SB700 is better, since the > distribution > can be used on motherboards with SB600 or SB700. SB600 support is already there. What I'm saying is that there was a pci quirk added for the SB600 sometime after 2.6.18, and the SB700 uses the same one. So, since we would, in theory, backport it as part of the SB700 backport - what is the value/risk of enabling it for the SB600 as well? We don't want to risk breaking existing SB600 support in etch unless there's a good reason. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]