Greetings Andrew;
2.6.11-mm2 seems to work, mostly.
First, the ieee1394 stuff seems to have fixed up that driver, and kino
can access my movie cameras video over the firewire very nicely
without applying the bk-ieee1394-patch. The camera has builtin
stereo mics in it, but nary a peep can be heard from it thru the
firewire. Am I supposed to be able to hear that?
Second, I have a pdHDTV-3000 card, and up till now I've been
overwriting the bttv stuffs with the drivers in pcHDTV-1.6.tar.gz by
doing a make clean;make;make install. But now thats broken, and the
error message doesn't seem to make sense to this old K&R C guy.
The error exit:
make[1]: Entering directory `/usr/src/linux-2.6.11-mm2'
CC
[M] /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o
/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362:
error: unknown field `id' specified in initializer
/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362:
warning: missing braces around initializer
/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362:
warning: (near initialization for
`bttv_i2c_client_template.released')
make[2]: ***
[/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o]
Error 1
make[1]: ***
[_module_/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver] Error
2
make[1]: Leaving directory `/usr/src/linux-2.6.11-mm2'
make: *** [modules] Error 2
The braces are indeed there.
Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've lost
my sensors except for one on the motherboard called THRM by
gkrellm-2.28. Nothing seems to be able to bring the w83627hf back to
life.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Gene Heskett <[email protected]> wrote:
>
> Greetings Andrew;
g'day.
> 2.6.11-mm2 seems to work, mostly.
>
> First, the ieee1394 stuff seems to have fixed up that driver, and kino
> can access my movie cameras video over the firewire very nicely
> without applying the bk-ieee1394-patch. The camera has builtin
> stereo mics in it, but nary a peep can be heard from it thru the
> firewire. Am I supposed to be able to hear that?
Was it working with 2.6.11+bk-ieee1394.patch? Or with anything else?
Cc'ed [email protected]
> Second, I have a pdHDTV-3000 card, and up till now I've been
> overwriting the bttv stuffs with the drivers in pcHDTV-1.6.tar.gz by
> doing a make clean;make;make install. But now thats broken, and the
> error message doesn't seem to make sense to this old K&R C guy.
>
> The error exit:
> make[1]: Entering directory `/usr/src/linux-2.6.11-mm2'
> CC
> [M] /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o
> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362:
> error: unknown field `id' specified in initializer
> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362:
> warning: missing braces around initializer
> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362:
> warning: (near initialization for
> `bttv_i2c_client_template.released')
> make[2]: ***
> [/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o]
> Error 1
> make[1]: ***
> [_module_/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver] Error
> 2
> make[1]: Leaving directory `/usr/src/linux-2.6.11-mm2'
> make: *** [modules] Error 2
>
> The braces are indeed there.
What's pcHDTV-1.6.tar.gz? If it was merged up then these things wouldn't
happen.
CC'ed [email protected]
> Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've lost
> my sensors except for one on the motherboard called THRM by
> gkrellm-2.28. Nothing seems to be able to bring the w83627hf back to
> life.
CC'ed [email protected]
On Wednesday 09 March 2005 01:44, Andrew Morton wrote:
>Gene Heskett <[email protected]> wrote:
>> Greetings Andrew;
>
>g'day.
>
g'day to you, sir.
>> 2.6.11-mm2 seems to work, mostly.
>>
>> First, the ieee1394 stuff seems to have fixed up that driver, and
>> kino can access my movie cameras video over the firewire very
>> nicely without applying the bk-ieee1394-patch. The camera has
>> builtin stereo mics in it, but nary a peep can be heard from it
>> thru the firewire. Am I supposed to be able to hear that?
>
>Was it working with 2.6.11+bk-ieee1394.patch? Or with anything
> else?
It did work previously with the svn download from the ieee1394 site
for the kernels in the series of RT stuff that Ingo Molnar was
working on. Also, since I posted this, I tried catting a .wav file
to /dev/dsp, which is the output that kino is expecting to use, and
that sort of worked, playing the file at half speed and pitch. So I
believe its the upload from the camera, and the stripping of the
audio data from the stream from the camera thats at fault. But thats
just a SWAG on my part, & I probably should not have used the S
there. :)
>Cc'ed [email protected]
>
>> Second, I have a pdHDTV-3000 card, and up till now I've been
>> overwriting the bttv stuffs with the drivers in pcHDTV-1.6.tar.gz
>> by doing a make clean;make;make install. But now thats broken,
>> and the error message doesn't seem to make sense to this old K&R C
>> guy.
>>
>> The error exit:
>> make[1]: Entering directory `/usr/src/linux-2.6.11-mm2'
>> CC
>> [M]
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: error: unknown field `id' specified in initializer
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: warning: missing braces around initializer
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: warning: (near initialization for
>> `bttv_i2c_client_template.released')
>> make[2]: ***
>> [/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o]
>> Error 1
>> make[1]: ***
>> [_module_/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver]
>> Error 2
>> make[1]: Leaving directory `/usr/src/linux-2.6.11-mm2'
>> make: *** [modules] Error 2
>>
>> The braces are indeed there.
>
>What's pcHDTV-1.6.tar.gz? If it was merged up then these things
> wouldn't happen.
>
This is the latest driver set for this card, downloadable from the
pcHDTV site. It overwrites, when it builds and installs, the bttv
and cx88xx stuffs in the modules dir. And it has worked up to
2.6.11-mm2, but I didn't get around to trying mm1. It worked with the
last of the RT's from Ingo, and for 2.6.11(.1).
>CC'ed [email protected]
>> Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've
>> lost my sensors except for one on the motherboard called THRM by
>> gkrellm-2.28. Nothing seems to be able to bring the w83627hf back
>> to life.
I'm back on 2.6.11-rc5 and thats working as expected now.
>CC'ed [email protected]
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Hi Gene, Andrew, all,
(Gene, note that I cannot write to you directly because Verizon are
idiots. Let's just hope you'll read that.)
[Gene Heskett]
> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:362:
> error: unknown field `id' specified in initializer
I've dropped the "id" member of struct i2c_client, as it were useless.
Third-party driver authors now need to do the same.
Patches to pcHDTV 1.6 and 2.0 attached (untested). Feel free to push the
latter to the author of hdPCTV. Note that the removed struct member was
really not used before, so the driver will still work with earlier
kernels.
[Andrew Morton]
> What's pcHDTV-1.6.tar.gz? If it was merged up then these things
> wouldn't happen.
I second that, especially since the pcHDTV package is made up of
modified bttv and cx88 drivers, not an original driver. Merging the
changes into the kernel would obviously make everyone's life easier.
As a side note, I have (many) other changes to the i2c subystem in my
plans, some of them are rather intrusive, so expect pcHDTV to break
again soon, unless it gets merged until then.
[Gene Heskett]
> Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've
> lost my sensors except for one on the motherboard called THRM by
> gkrellm-2.28. Nothing seems to be able to bring the w83627hf back
> to life.
THRM is most likely a temperature you get from /proc/acpi/thermal_zone,
and isn't related with the w83627hf driver.
I think that you are affected by recent changes made by the ACPI folks
to the way resources are reserved. See bug #4014:
http://bugzilla.kernel.org/show_bug.cgi?id=4014
You can check /proc/ioports on the working system after loading
w83627hf, and compare with /proc/ioports on the non-working system. I'd
expect you to find that the non-working system has reserved a subrange
of what the w83627hf driver attempts to grab, making it fail.
--
Jean Delvare
On Wednesday 09 March 2005 14:33, Jean Delvare wrote:
>Hi Gene, Andrew, all,
>
>(Gene, note that I cannot write to you directly because Verizon are
>idiots. Let's just hope you'll read that.)
Got it, & can't argue with that label. Some of the labels I've
applied to them are even more 'colorfull'.. Unforch, they are the
*only* game in this town. :-(
>[Gene Heskett]
>
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: error: unknown field `id' specified in initializer
>
>I've dropped the "id" member of struct i2c_client, as it were
> useless. Third-party driver authors now need to do the same.
Aha! As in just 'dd' any line containing the .id in vim?
>Patches to pcHDTV 1.6 and 2.0 attached (untested). Feel free to push
> the latter to the author of hdPCTV. Note that the removed struct
> member was really not used before, so the driver will still work
> with earlier kernels.
Good. But where did you get the 2.0? My 1.6 is only 2 weeks old here
as thats about as long as I've had the card, but I haven't checked
the dl page on Jacks site since yesterday sometime...
Humm, I see its labeled as for FC3, but since the kernel I'm booted to
right now is linux-2.6.11.2-RT-V0.7.39-02, I'm going to make the
assumption that I can use it till I find otherwise.
That kernel is locally built, using these patches, from my script:
VERP1="../2.6.11.1"
VERP2="../2.6.11.2"
VERP3="../2.6.11.2-RT-V0.7.39-02"
VERP4="../bk-ieee1394.patch"
VERP5="../2.6.11-forcedeth-fix"
VERP6="../Kconfig-1-patch"
VERP7="../Kconfig-2-patch"
The last 3 remove the '&& EXPERIMENTAL' from the respective Kconfigs
for nforce2 stuffs. If its not 'stable' yet, then lets get them
fixed, this keeping stuff in experimental forever when half the
planet is using them without any reported gotchas for extended
periods just plain sucks. So does the lag in getting
bk-ieee1394.patch into mainline. Firewire has been broken for quite
a few moons now, so I fail to see the reason for the lag when the
patch itself is demonstratably working great. My hats off to Dan
Dennedy & company there.
The only thing that didn't apply clean was Ingo's last RT patch, I
dropped the ball on the EXTRAVERSION it was looking for in the main
Makefile. But vim fixed that right up after the fact.
So basicly, I'm cutting a fresh trail here, trying to scratch my
personal itches and its not working too bad. Not bad for an old
fart. I'll go see if the pcHDTV-2.0 version for kernels >2.6.9 works
now, and get back to the list. Thanks for the heads up on that.
>[Andrew Morton]
>
>> What's pcHDTV-1.6.tar.gz? If it was merged up then these things
>> wouldn't happen.
>
>I second that, especially since the pcHDTV package is made up of
>modified bttv and cx88 drivers, not an original driver. Merging the
>changes into the kernel would obviously make everyone's life easier.
>
>As a side note, I have (many) other changes to the i2c subystem in
> my plans, some of them are rather intrusive, so expect pcHDTV to
> break again soon, unless it gets merged until then.
I'll second that, this having to do everything to build a new kernel
twice before its actually built and working is a major PITA. I'm
also doing the same thing with the spca5xx stuffs for a webcam.
Silly Q? How much trouble would it be for me to just copy over the
revelant src code modules once the patch has been applied? I could
make that bit of copying a part of my buildit26 script, a snippet of
which you see above. This is my src code tree builder.
>[Gene Heskett]
>
>> Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've
>> lost my sensors except for one on the motherboard called THRM by
>> gkrellm-2.28. Nothing seems to be able to bring the w83627hf back
>> to life.
>
>THRM is most likely a temperature you get from
> /proc/acpi/thermal_zone, and isn't related with the w83627hf
> driver.
Humm, it is the highest temp reported, as is temp2 in gkrellm, so I
had assumed it was somehow a dup of the diode in the cpu, or of the
thermistor against the bottom of it inside the socket. Wrong
assumption?
But I just in the last half hour managed to get it working again!
Somehow, in my playing with the CONFIG_BROKEN, (if you have an nforce2
equipt board, never, ever, uncheck that option, its friggin dangerous
to your sanity!) the building of the i2c-isa got erased from
the .config. Modularizing everything I needed, making sure the
correct modprobe lines were in my rc.local, and fetching and
installing the user portions of lm_sensors-2.9.0 to replace the 2.8.7
stuff, and its suddenly working.
So now, sensors is working, as is gkrellm, and kino is working audio
and all, but tvtime suddenly has a 2 second delay in anything it does
including its on-screen clock sitting on a blue screen. No video,
just audio.
>I think that you are affected by recent changes made by the ACPI
> folks to the way resources are reserved. See bug #4014:
> http://bugzilla.kernel.org/show_bug.cgi?id=4014
>
I haven't looked at that yet.
>You can check /proc/ioports on the working system after loading
>w83627hf, and compare with /proc/ioports on the non-working system.
> I'd expect you to find that the non-working system has reserved a
> subrange of what the w83627hf driver attempts to grab, making it
> fail.
Its working again, see above.
Many, many thanks to Jean D., and all on this.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Wednesday 09 March 2005 14:33, Jean Delvare wrote:
>Hi Gene, Andrew, all,
>[Gene Heskett]
>
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: error: unknown field `id' specified in initializer
>
>I've dropped the "id" member of struct i2c_client, as it were
> useless. Third-party driver authors now need to do the same.
>
>Patches to pcHDTV 1.6 and 2.0 attached (untested). Feel free to push
> the latter to the author of hdPCTV. Note that the removed struct
> member was really not used before, so the driver will still work
> with earlier kernels.
I unpacked and patched the pcHDTV-2.0 driver kit, but the make bails
out with this:
/usr/src/pcHDTV-2.0/cx88-cards.c: In function `hauppauge_eeprom_dvb':
/usr/src/pcHDTV-2.0/cx88-cards.c:772: warning: control reaches end of
non-void function
[...]
That one I may be able to fix, probably a braces error.
Then 10 lines or so later:
CC [M] /usr/src/pcHDTV-2.0/saa7134-tvaudio.o
/usr/src/pcHDTV-2.0/saa7134-tvaudio.c: In function
`saa7134_tvaudio_init2':
/usr/src/pcHDTV-2.0/saa7134-tvaudio.c:988: warning: implicit
declaration of function `DECLARE_MUTEX_LOCKED'
/usr/src/pcHDTV-2.0/saa7134-tvaudio.c:988: error: `sem' undeclared
(first use in this function)
/usr/src/pcHDTV-2.0/saa7134-tvaudio.c:988: error: (Each undeclared
identifier is reported only once
/usr/src/pcHDTV-2.0/saa7134-tvaudio.c:988: error: for each function it
appears in.)
/usr/src/pcHDTV-2.0/saa7134-tvaudio.c:989: warning: ISO C90 forbids
mixed declarations and code
make[2]: *** [/usr/src/pcHDTV-2.0/saa7134-tvaudio.o] Error 1
make[1]: *** [_module_/usr/src/pcHDTV-2.0] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.11.2-RT-V0.7.39-02'
make: *** [default] Error 2
Header file error?
I'll go try the 1.6 patch now.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Wednesday 09 March 2005 14:33, Jean Delvare wrote:
>Hi Gene, Andrew, all,
>[Gene Heskett]
>
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: error: unknown field `id' specified in initializer
>
>I've dropped the "id" member of struct i2c_client, as it were
> useless. Third-party driver authors now need to do the same.
>
>Patches to pcHDTV 1.6 and 2.0 attached (untested). Feel free to push
> the latter to the author of hdPCTV. Note that the removed struct
> member was really not used before, so the driver will still work
> with earlier kernels.
The 1.6 patch won't apply due to -pn problems, so I did it by hand.
It now builds and installs ok, but tvtime is still dead, taking about
5 seconds to open its initial window, and another 15 to display just
the channel and time on a permanent blue screen, with its time
display only being updated about every 3 seconds. Audio works ok.
Clicking on the exit also takes about 5 seconds for it to quit.
Running it from a shell with the -vv doesn't show any problems that
look like showstoppers:
---------
[root@coyote driver]# tvtime -vv
Running tvtime 0.9.15.
Reading configuration from /etc/tvtime/tvtime.xml
Reading configuration from /root/.tvtime/tvtime.xml
cpuinfo: CPU AMD Athlon(tm) XP 2800+, family 6, model 10, stepping 0.
cpuinfo: CPU measured at 2079.706MHz.
xcommon: Display :0.0, vendor The X.Org Foundation, vendor release
60801901
xfullscreen: Single-head detected, pixel aspect will be calculated.
xfullscreen: Pixel aspect ratio on the primary head is: 1/1 == 1.00.
xfullscreen: Using the XFree86-VidModeExtension to calculate
fullscreen size.
xfullscreen: Fullscreen to 0,0 with size 1600x1200.
xcommon: Have XTest, will use it to ping the screensaver.
xcommon: Pixel aspect ratio 1:1.
xcommon: Pixel aspect ratio 1:1.
xcommon: Window manager is KWin and is EWMH compliant.
xcommon: Using EWMH state fullscreen property.
xcommon: Using EWMH state above property.
xcommon: Using EWMH state below property.
xcommon: Pixel aspect ratio 1:1.
xcommon: Displaying in a 768x576 window inside 768x576 space.
xvoutput: Using XVIDEO adaptor 69: ATI Radeon Video Overlay.
speedycode: Using MMXEXT optimized functions.
station: Reading stationlist from /root/.tvtime/stationlist.xml
videoinput: Using video4linux2 driver 'cx8800', card 'pcHDTV HD3000
HDTV' (bus PCI:0000:01:07.0).
videoinput: Version is 4, capabilities 5010011.
videoinput: Width 768 too high, using 640 instead as suggested by the
driver.
videoinput: Maximum input width: 640 pixels.
tvtime: Sampling input at 640 pixels per scanline.
xcommon: Pixel aspect ratio 1:1.
xcommon: Displaying in a 768x576 window inside 768x576 space.
xcommon: Received a map, marking window as visible (71).
xcommon: Window fully obscured, marking window as hidden (71).
xcommon: Window made visible, marking window as visible (71).
------------
And unless the diff between 640 and 768 is the problem, there isn't
much else to go on there.
Since this involves x, its xorg-6.8.1, locally built, and so far (4
months?) absolutely dead stable.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Hi Gene,
> > I've dropped the "id" member of struct i2c_client, as it were
> > useless. Third-party driver authors now need to do the same.
>
> Aha! As in just 'dd' any line containing the .id in vim?
Exactly. Don't kill all lines with .id though, only the i2c_client id
was dropped, and there are plenty of other ids in the media/video
drivers.
> > THRM is most likely a temperature you get from
> > /proc/acpi/thermal_zone, and isn't related with the w83627hf
> > driver.
>
> Humm, it is the highest temp reported, as is temp2 in gkrellm, so I
> had assumed it was somehow a dup of the diode in the cpu, or of the
> thermistor against the bottom of it inside the socket. Wrong
> assumption?
Not necessarily wrong. It is possible that the same diode temperature is
read from the W83627HF chip by both the ACPI subsystem and by the
w83627hf driver. But if this is the case, I would be worried by
concurrent I/O accesses to the chip, which could possibly cause trouble.
--
Jean Delvare
On Thursday 10 March 2005 03:52, Jean Delvare wrote:
>Hi Gene,
>
>> > I've dropped the "id" member of struct i2c_client, as it were
>> > useless. Third-party driver authors now need to do the same.
>>
>> Aha! As in just 'dd' any line containing the .id in vim?
>
>Exactly. Don't kill all lines with .id though, only the i2c_client
> id was dropped, and there are plenty of other ids in the
> media/video drivers.
I found the patch location, it was off by about -30 lines after the
other patches, and applied them. It builds now, but still doesn't
work, very slow screen updates and no video in tvtime. It works
properly with 2.6.11, 2.6.11.1, and 2.6.11.2. As I didn't have the
card until 2.6.11 was out, I should back up to the last rc4-RT, and
see if this card will work with that. At least that will narrow the
guilty patchset down a wee bit. I'll try that later today if the
honeydo's don't get in the way.
I noted last night too, that while my scanner worked, it was gawdawful
slow at retrieving the data over the usb when running at a measly
300dpi, 3 to 4 minutes for an 8.5x11, 23 MB of data (according to
xsane) scan. IIRC Its been only 45-50 seconds in past times. So
that may indicate a usb slowdown too, in the read path only. The usb
printer in 1440x1440 color was about its usual speed, needing a
surveyer to measure page ejection progress. :)
That printer does very very nice indeed color work, but in those
modes, theres no way to convince the frogs that an Epson C82 is
faster than watching paint dry. 10 to 20 minutes a page depending on
content.
OTOH, my output, after tweaking a few things, was a hell of a lot more
brilliant than the page I scanned in! (Plus the award recipients
name is now spelled correctly, the reason for that little 3 hour
exersize, ain't the gimp wunnerful?)
>> > THRM is most likely a temperature you get from
>> > /proc/acpi/thermal_zone, and isn't related with the w83627hf
>> > driver.
>>
>> Humm, it is the highest temp reported, as is temp2 in gkrellm, so
>> I had assumed it was somehow a dup of the diode in the cpu, or of
>> the thermistor against the bottom of it inside the socket. Wrong
>> assumption?
>
>Not necessarily wrong. It is possible that the same diode
> temperature is read from the W83627HF chip by both the ACPI
> subsystem and by the w83627hf driver. But if this is the case, I
> would be worried by concurrent I/O accesses to the chip, which
> could possibly cause trouble.
I don't believe I'm seeing any evidence of that here. OTOH, I don't
run sensors very often when gkrellm is running. Or are there other
processes accessing through that bus that wouldn't play well?
>--
>Jean Delvare
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Wednesday 09 March 2005 01:44, Andrew Morton wrote:
>Gene Heskett <[email protected]> wrote:
>> Greetings Andrew;
>
>g'day.
>
>> 2.6.11-mm2 seems to work, mostly.
>>
>> First, the ieee1394 stuff seems to have fixed up that driver, and
>> kino can access my movie cameras video over the firewire very
>> nicely without applying the bk-ieee1394-patch. The camera has
>> builtin stereo mics in it, but nary a peep can be heard from it
>> thru the firewire. Am I supposed to be able to hear that?
>
>Was it working with 2.6.11+bk-ieee1394.patch? Or with anything
> else?
Yes, as long as that patch was applied.
>Cc'ed [email protected]
>
>> Second, I have a pdHDTV-3000 card, and up till now I've been
>> overwriting the bttv stuffs with the drivers in pcHDTV-1.6.tar.gz
>> by doing a make clean;make;make install. But now thats broken,
>> and the error message doesn't seem to make sense to this old K&R C
>> guy.
>>
>> The error exit:
>> make[1]: Entering directory `/usr/src/linux-2.6.11-mm2'
>> CC
>> [M]
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: error: unknown field `id' specified in initializer
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: warning: missing braces around initializer
>> /usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.c:36
>>2: warning: (near initialization for
>> `bttv_i2c_client_template.released')
>> make[2]: ***
>> [/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver/bttv-i2c.o]
>> Error 1
>> make[1]: ***
>> [_module_/usr/pcHDTV3000/linux/pcHDTV-1.6/kernel-2.6.x/driver]
>> Error 2
>> make[1]: Leaving directory `/usr/src/linux-2.6.11-mm2'
>> make: *** [modules] Error 2
>>
>> The braces are indeed there.
>
>What's pcHDTV-1.6.tar.gz? If it was merged up then these things
> wouldn't happen.
>
>CC'ed [email protected]
>
>> Third, somewhere between 2.6.11-rc5-RT-V0.39-02 and 2.6.11, I've
>> lost my sensors except for one on the motherboard called THRM by
>> gkrellm-2.28. Nothing seems to be able to bring the w83627hf back
>> to life.
>
>CC'ed [email protected]
That I got, somewhere in trying to build a working kernel without the
config_broken, i2c-isa got lost. Restored that and all is well in
that dept.
I've got 3 patches that remove the '&& EXPERIMENTAL' from the Kconfigs
for the nforce2 stuffs, and even posted one here, but got .000zip
response, so I don't know if they are welcome or not...
>
>--
>video4linux-list mailing list
>Unsubscribe
> mailto:[email protected]?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
On Monday 21 March 2005 20:45, Andrew Morton wrote:
[...]
>> Lemme see if I've grabbed that patch, brb. No, but I'll go get it
>> right now. Got it. Edited my two scripts and its building now.
After 2 days of running rc1-mm1, I've reverted to plain rc1, for one
reason. The last 2 days, its taken amdump/amverify till after 5am to
finish, and its only done 2, instead of 3, units of setiathome, which
is now shareing time with the einstein boinc project.
Running plain rc1, the amdump/amverify run was commonly done by a bit
after 2am, starting at 1am, and seti was getting enough time to do 3
units all the time. So an hour to hour & 45 max, to over 4 hours is
the comparison there.
Note that we're talking mm1 here, not the mm2 in the subject line as
it wasn't visible when I went after the patch at kernel.org. And
there still is not an -mm2 there, so I assume that was a typu.
So while -mm1 didn't crash, and in fact was quite frugal with its
memory use, so I haven't had the oom crashes some have reported. It
just isn't as fast by a noticable amount.
And I have no idea where to point fingers. Running kino, there were
many noticable instances of its video import being hung for at least
a second at a time, something I haven't noticed with rc1 to anything
near that extent. A night and day difference, showstopper to usable
there.
tvtime also had many more few stutters & skipped frames. In either
case, I'd often have to restart tvtime with the new settings to get
decent audio, so there is no change there.
Scheduler? DarnedifIknow. All I could see was the canary getting
sick, sorry. :(
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.