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.
