[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: AMD/ATI SB700 support to Debian



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



Reply to: