Call for 2.8.2 soon

Call for 2.8.2 soon

[Mark Studebaker]

After -test10 comes out (assuming it has Khali's patches in it),
then I want to fix up libsensors to match the magnitudes and sysfs names
that test10 has in it, then release 2.8.2.

The one thing I'd like to get in besides that is the amd756 fixup
to add the 8111 support back in. Philip?

Anything else people want to get into the next release?

Call for 2.8.2 soon

[Jean Delvare]

> After -test10 comes out (assuming it has Khali's patches in it),
> then I want to fix up libsensors to match the magnitudes and sysfs
> names that test10 has in it, then release 2.8.2.

Test10 is out, without the patches. Looks like Greg wants to wait until
Linux 2.6.0 is out before applying patches again. This policy is likely
to slow down Mark's plan.

> Anything else people want to get into the next release?

Here comes my TODO list:

1* /proc write problem in libsensors.
2* Get rid of dmidecode dependency in sensors-detect.
3* Remove ACPI method in sensors-detect, leave only VPD in.
4* The limit init removal left a few variables unused. Fix that.
5* Sysfs support in sensors-detect?

Point #1 can obviously be postponed, since it's probable I won't find
the solution in time.
Point #5 would require me to have a working Linux 2.6.0-testX kernel,
which I don't really have at the moment.

Everyone add points to the list if you want.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Call for 2.8.2 soon

[Mark Studebaker]

Jean Delvare wrote:


> 
> Here comes my TODO list:
> 
> 1* /proc write problem in libsensors.
> 2* Get rid of dmidecode dependency in sensors-detect.
> 3* Remove ACPI method in sensors-detect, leave only VPD in.
> 4* The limit init removal left a few variables unused. Fix that.
> 5* Sysfs support in sensors-detect?
> 
> Point #1 can obviously be postponed, since it's probable I won't find
> the solution in time.
> Point #5 would require me to have a working Linux 2.6.0-testX kernel,
> which I don't really have at the moment.

How about if I tar up my /sys and send it to you for testing?
Then you could test on 2.4.

Call for 2.8.2 soon

[Greg KH]

On Mon, Nov 24, 2003 at 09:23:58PM +0100, Jean Delvare wrote:
> > After -test10 comes out (assuming it has Khali's patches in it),
> > then I want to fix up libsensors to match the magnitudes and sysfs
> > names that test10 has in it, then release 2.8.2.
> 
> Test10 is out, without the patches. Looks like Greg wants to wait until
> Linux 2.6.0 is out before applying patches again. This policy is likely
> to slow down Mark's plan.

Sorry about that, but I'll only let real bugfixes in right now.
Everything else (like the patches sent to me already) are queueing up
for 2.6.1.

thanks,

greg k-h

Call for 2.8.2 soon

[Mark Studebaker]

Some of it really is "real bugfixes".
Fixing the magnitudes in the w83781d temperatures
is probably the most important...
Can we agree on the "real bugfixes" and push only those over?

Greg KH wrote:

> On Mon, Nov 24, 2003 at 09:23:58PM +0100, Jean Delvare wrote:
> 
>>>After -test10 comes out (assuming it has Khali's patches in it),
>>>then I want to fix up libsensors to match the magnitudes and sysfs
>>>names that test10 has in it, then release 2.8.2.
>>
>>Test10 is out, without the patches. Looks like Greg wants to wait until
>>Linux 2.6.0 is out before applying patches again. This policy is likely
>>to slow down Mark's plan.
> 
> 
> Sorry about that, but I'll only let real bugfixes in right now.
> Everything else (like the patches sent to me already) are queueing up
> for 2.6.1.
> 
> thanks,
> 
> greg k-h
> 

Call for 2.8.2 soon

[Mark M. Hoffman]

* Greg KH <greg@kroah.com> [2003-11-24 13:29:15 -0800]:
> On Mon, Nov 24, 2003 at 09:23:58PM +0100, Jean Delvare wrote:
> > 
> > Test10 is out, without the patches. Looks like Greg wants to wait until
> > Linux 2.6.0 is out before applying patches again. This policy is likely
> > to slow down Mark's plan.
> 
> Sorry about that, but I'll only let real bugfixes in right now.
> Everything else (like the patches sent to me already) are queueing up
> for 2.6.1.

Hi Greg: could you {generate, post a link to} a patch vs. -test10 of your
i2c-sensors-queued-up-for-2.6.1 tree?  Actually, it'd be cool if you auto-
updated such a patch whenever you queue one or pull/merge from Linus.  I
think that will help us get the userspace into shape; and I know it would
help me not to put stuff off until 2.6.1.

Thanks and regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

Call for 2.8.2 soon

[Jean Delvare]

> Some of it really is "real bugfixes".
> Fixing the magnitudes in the w83781d temperatures
> is probably the most important...

There is no patch for this yet AFAIK. I took a look at the code, and I'm
not sure I understand how to fix it. The conversion macros are much too
complicated IMHO, and could probably be simplified. If anyone wants to
take a chance...

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Call for 2.8.2 soon

[Mark Studebaker]

Since we don't expect magnitudes to be fixed soon, and maybe not the
names either,
I'll go ahead and put the additional exceptions into lib/chips.c so that
it matches what's in the kernel now.
We can release with that and do another release when the patches go in.


Jean Delvare wrote:
> 
> > Some of it really is "real bugfixes".
> > Fixing the magnitudes in the w83781d temperatures
> > is probably the most important...
> 
> There is no patch for this yet AFAIK. I took a look at the code, and I'm
> not sure I understand how to fix it. The conversion macros are much too
> complicated IMHO, and could probably be simplified. If anyone wants to
> take a chance...
> 
> --
> Jean Delvare
> http://www.ensicaen.ismra.fr/~delvare/

Call for 2.8.2 soon

[Jean Delvare]

> How about if I tar up my /sys and send it to you for testing?
> Then you could test on 2.4.

Thanks for the proposal, but that wouldn't have been a good idea. This
would have left me in my laziness and I would never have installed 2.6.
Now this is done :)

I have 2.6.0-test11 up and running on my other (non-laptop) computer.
Couldn't get it on my laptop (which is also my main development system),
it's getting too old and I would have had to update half a dozen system
tools and libraries. The other system is much more recent and I could
get 2.6.0-test11 to work on it, almost perfectly. I have sound working,
my DC10+ board also works (although the visual quality is rather poor,
don't know why). I also have a brand new LCD display on that machine,
(which in turn could become my main development system again ;)) and
have a 1280x1024 framebuffer console and X running with reasonable
performance (you don't need too much for a text editor and a shell). And
now I also have sensors working. Eeprom support is missing though, and
for some reason the via686a driver failed to detect my hardware, while
it used to do. I don't really care because the chip is actually not
wired so it returns useless values, but this probably means there's
something waiting for us to fix it in there.

The eeprom problem isn't really important, I think. We could even
consider disabling detection in sensors-detect for a while, until the
problem is fixed. Since eeprom contents are now returned in a binary
form, I guess it'll be harder to get it to work through libsensors.
Same problem for decode-*.pl scripts I guess.

Anyway, I will now be able to test and develop on a 2.6 system, so feel
free to request my assistance whenever needed.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Call for 2.8.2 soon

[Mark Studebaker]

great. I too waited too long to begin playing with 2.6.
It was a pain to get everything going but now I'm in pretty good shape.

On via686a, sometimes it would register and sometimes it wouldn't.
Try rmmoding and modprobing a few times. I think if I rmmodded the
whole i2c stack including i2c-core and starting over it would show up.
Haven't gotten to the bottom of it yet. Maybe you can.

Thanks for fixing sensors segfault.

Jean Delvare wrote:
> 
> > How about if I tar up my /sys and send it to you for testing?
> > Then you could test on 2.4.
> 
> Thanks for the proposal, but that wouldn't have been a good idea. This
> would have left me in my laziness and I would never have installed 2.6.
> Now this is done :)
> 
> I have 2.6.0-test11 up and running on my other (non-laptop) computer.
> Couldn't get it on my laptop (which is also my main development system),
> it's getting too old and I would have had to update half a dozen system
> tools and libraries. The other system is much more recent and I could
> get 2.6.0-test11 to work on it, almost perfectly. I have sound working,
> my DC10+ board also works (although the visual quality is rather poor,
> don't know why). I also have a brand new LCD display on that machine,
> (which in turn could become my main development system again ;)) and
> have a 1280x1024 framebuffer console and X running with reasonable
> performance (you don't need too much for a text editor and a shell). And
> now I also have sensors working. Eeprom support is missing though, and
> for some reason the via686a driver failed to detect my hardware, while
> it used to do. I don't really care because the chip is actually not
> wired so it returns useless values, but this probably means there's
> something waiting for us to fix it in there.
> 
> The eeprom problem isn't really important, I think. We could even
> consider disabling detection in sensors-detect for a while, until the
> problem is fixed. Since eeprom contents are now returned in a binary
> form, I guess it'll be harder to get it to work through libsensors.
> Same problem for decode-*.pl scripts I guess.
> 
> Anyway, I will now be able to test and develop on a 2.6 system, so feel
> free to request my assistance whenever needed.
> 
> --
> Jean Delvare
> http://www.ensicaen.ismra.fr/~delvare/

Call for 2.8.2 soon

[Jean Delvare]

> Here comes my TODO list:
> 
> 1* /proc write problem in libsensors.
> 2* Get rid of dmidecode dependency in sensors-detect.
> 3* Remove ACPI method in sensors-detect, leave only VPD in.
> 4* The limit init removal left a few variables unused. Fix that.
> 5* Sysfs support in sensors-detect?
> 
> Point #1 can obviously be postponed, since it's probable I won't find
> the solution in time.
> Point #5 would require me to have a working Linux 2.6.0-testX kernel,
> which I don't really have at the moment.

Everything but #1 is done. I added code to catch problem #1 (embraced
with #ifdef DEBUG), it doesn't have to be fixed before we release 2.8.2.
If another user complains someday, we'll have him/her compile with
DEBUG=1 and see.

I have two new items on my TODO list:
6* Unknown adapters in sensors.
7* Addresses exclusion mechanism in sensors-detect.

Should be quite easy, after that we can release if everyone's OK.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Call for 2.8.2 soon

[Mark Studebaker]

let's only do 6 and 7 if they aren't very disruptive.

And let's spend the next 2-3 days reviewing and correcting all the top
level
documentation in both packages (README, INSTALL, etc...)


Jean Delvare wrote:
> 
> > Here comes my TODO list:
> >
> > 1* /proc write problem in libsensors.
> > 2* Get rid of dmidecode dependency in sensors-detect.
> > 3* Remove ACPI method in sensors-detect, leave only VPD in.
> > 4* The limit init removal left a few variables unused. Fix that.
> > 5* Sysfs support in sensors-detect?
> >
> > Point #1 can obviously be postponed, since it's probable I won't find
> > the solution in time.
> > Point #5 would require me to have a working Linux 2.6.0-testX kernel,
> > which I don't really have at the moment.
> 
> Everything but #1 is done. I added code to catch problem #1 (embraced
> with #ifdef DEBUG), it doesn't have to be fixed before we release 2.8.2.
> If another user complains someday, we'll have him/her compile with
> DEBUG=1 and see.
> 
> I have two new items on my TODO list:
> 6* Unknown adapters in sensors.
> 7* Addresses exclusion mechanism in sensors-detect.
> 
> Should be quite easy, after that we can release if everyone's OK.
> 
> --
> Jean Delvare
> http://www.ensicaen.ismra.fr/~delvare/

Call for 2.8.2 soon

[Jean Delvare]

> > I have two new items on my TODO list:
> > 6* Unknown adapters in sensors.
> > 7* Addresses exclusion mechanism in sensors-detect.
> 
> let's only do 6 and 7 if they aren't very disruptive.

6 should be rather safe. 7 is a bit more complex and can be delayed
until after 2.8.2 if you want.

> And let's spend the next 2-3 days reviewing and correcting all the top
> level documentation in both packages (README, INSTALL, etc...)

Interesting proposal, I'll try to help. BTW, let's not forget i2c in the
process. I wouldn't be surprised if that part of the documentation is
also slightly outdated.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Call for 2.8.2 soon

[Greg KH]

On Mon, Nov 24, 2003 at 08:45:34PM -0500, Mark M. Hoffman wrote:
> * Greg KH <greg@kroah.com> [2003-11-24 13:29:15 -0800]:
> > On Mon, Nov 24, 2003 at 09:23:58PM +0100, Jean Delvare wrote:
> > > 
> > > Test10 is out, without the patches. Looks like Greg wants to wait until
> > > Linux 2.6.0 is out before applying patches again. This policy is likely
> > > to slow down Mark's plan.
> > 
> > Sorry about that, but I'll only let real bugfixes in right now.
> > Everything else (like the patches sent to me already) are queueing up
> > for 2.6.1.
> 
> Hi Greg: could you {generate, post a link to} a patch vs. -test10 of your
> i2c-sensors-queued-up-for-2.6.1 tree?  Actually, it'd be cool if you auto-
> updated such a patch whenever you queue one or pull/merge from Linus.  I
> think that will help us get the userspace into shape; and I know it would
> help me not to put stuff off until 2.6.1.

I should be caught up on all i2c patches that people have sent me
recently.  I'll generate a patch and repo and post it here in a little
bit that shows everything that I have.  If I've missed anything, please
let me know.

thanks,

greg k-h