I reconfigured the kernel with PCI hotplugging enabled. I know now why I inadvertently turned it off before -- I had the 'pciehp' module enabled, which is the one the guys want, but further down in the configure application I turned off some other PCI hotplugging, but that also disabled the earlier selection. In other words, you can't just progress downward through the 'menuconfig' menu -- if I had gone back up I would have seen that my earlier enabling of the pciehp module had disappeared. Anyway, this time I was more alert.
I compiled the usual 3rd-party modules:
'extra' folder: martian_dev.ko, rt2860sta.ko, rt2870sta.ko, sysprof-module.ko, ungrab-winmodem.ko
'misc' folder: linmodem.ko, ndiswrapper.ko, pctel_hw.ko, pctel.ko
'slmodem' folder: slamr.ko, slusb.ko
'kernel/fs/unionfs' folder: unionfs.ko
This time I succeeded in compiling the 'sysprof-module.ko' module, needed by the Sysprof application (see System menu). This is a very useful tool to study what system resources an application uses. It monitors an application in real-time while you are using it, then presents you with very interesting summaries.
You also have Sysprof with the 184.108.40.206 kernel.
As Sysprof is mostly of interest to developers, it is in the 'devx' file.
The new kernel patched source is here:
The files are uploading as I type this. Fascinating how this new satellite system works. It seems to have some kind of real-time adaptation (at least, that's what I'm assuming, and it's not some other effect). I'm watching the kernel source uploading, it started off about 20KB/sec and has been steadily climbing, halfway through the 56MB file it is now doing 52KB/sec. I'm typing this offline, don't want to disturb the ftp upload. It has leveled off about 53.5KB/sec. This is particularly interesting because my old BBNet satellite connection had serious problems with uploading, doing it in short bursts, between intense negotiation, and the approx 0.8 second latency involved in that negotiation seemed to be the main problem. Ipstar seem to have got around the latency problem. Nearing the end of that file, still climbing, 55MB uploaded and doing 55.2KB/sec. At the end it was doing 55.7KB/sec.
More 3rd-party modules?
If you tested 4.3beta1 and found that a module is missing that you need, let me know. As long as I don't have to recompile the kernel! Prefer if you can provide a link to the module source so that I don't have to search for it. Note, for compiling modem modules contact rerwin -- he has been waiting for the final build of the 220.127.116.11 kernel so that he can compile modem modules for it.
Better be cautious
I have done a basic sanity check on the new kernel -- built a pup and installed to USB Flash drive -- works fine.
However, I really should test Firefox 3.5.2 before announcing that this is the "final" kernel for 4.3. Ok, will do, and I'll post a report to this thread. If that works, we're in business...
Hmmm, there's another kernel source file uploading, the sfs file, 74MB and speed is still steadily climbing, now at 56.3KB/sec.
Comments:Posted on 22 Aug 2009, 19:06 by Me
Kernel Module Request
Please can We get ProLink PixelView PlayTV Pro 2 TV Tuner Card which has BT878 ChipSet. Hope this Link Helps...
Posted on 22 Aug 2009, 20:27 by tempestuous
The bttv driver is a standard kernel module, and has been included as far back as Puppy v2.01.
This is not relevant to Barry's question about 3rd party drivers.
You clearly need help, Me. Ask in the main forum.
This is the developer forum.
Posted on 22 Aug 2009, 20:38 by BarryK
Unionfs still crashes
C**p, it still crashes.
The Unionfs patch I applied was supposed to have fixed this bug. What a waste of time all that was.
This time I got a log of /var/log/messages, so I'll contact the Unionfs developers.
Posted on 22 Aug 2009, 21:14 by BarryK
Unionfs bug reported
I have reopened a bug report, as it isn't fixed:
Posted on 22 Aug 2009, 22:30 by grndoor
Unionfs bug reports
I have built a Slackware version of Puppy (spup) using woof (woof-14AUG09.tar.gz), Kernel 18.104.22.168 and Unionfs 2.5.2.
This build exhibits the Unionfs bug with Firefox 3.5.2.
I have also built this version of spup Puppy with Unionfs replaced by the latest version of Aufs2 from cvs (very straightforward).
This Aufs2 build does NOT exhibit the problem running Firefox 3.5.2.
I will repeat this exercise using your kernel-22.214.171.124-22aug09 source material and Aufs2.
NOTE: I have only carried out limited testing of the first Aufs2 build (kernel 126.96.36.199), but it appears to be fully functional.
Posted on 23 Aug 2009, 8:35 by kirk
I've been using aufs2 for a few months, no problems. I've been using Firefox 3.5 too. Haven't tried direct saves to lower branches, but I think there's a config option to support that. It's not like Aufs1, where you have to build an external module, you just apply the patches to the kernel, configure and make. Again, Firefox 3 had problems with Puppy 4's version glibc. Don't know if that was fixed with Firefox 3.5.
Posted on 23 Aug 2009, 8:44 by BarryK
Aufs vs Unionfs
Yeah, I'll wait until Erez comes up with another fix for Unionfs, but next time round perhaps I should patch the kernel for both Unionfs and Aufs, so that we have choice, like we have in some of the earlier kernels that Puppy uses.
Posted on 23 Aug 2009, 9:02 by Sit Heel Speak
Puzzled about 188.8.131.52 + unionfs
I must have missed the big mess, so am puzzled as to what is all this about 184.108.40.206 and unionfs; I've been using maggotspawn's 220.127.116.11-based "4.20-rt-smp" (I believe he had help) for a couple months now and have never seen its Seamonkey browser crash. Nor anything else. Not one crash, ever, in 2 months of quite heavy use. Most solid Pup(py) I've ever seen. I routinely load the kernel-src and devx sfs's at bootup.
Whoever compiled Seamonkey in 4.20-rt-smp certainly knows how to compile, and I imagine the lessons would carry over to Firefox 3.5.2. Unfortunately, if you enter about:buildconfig in the address bar, instead of seeing the compile-time switches you get a taunt message.
Ttsskkk ttsskkk how very unpenguinlike...
Posted on 23 Aug 2009, 10:21 by 01micko
Hi Barry, that is the link to the acx driver... not there, just did a Pfind and the firmware is there and that's it. (k18.104.22.168). It is for TI chipsets such as netgear wg311v2 which I have. Thanks.
Posted on 23 Aug 2009, 22:52 by vk6fun
ham radio modules
any chance of having any future puppy kernel configured like this?
this stuff has been in linux for yonx
Code maturity level options --->
[*] Prompt for development and/or incomplete code/drivers
General setup --->
[*] Networking support
Networking options --->
<*> UNIX domain sockets
[*] TCP/IP networking
[*] IP: tunneling
Amateur Radio Support --->
--- Packet Radio protocols
[*] Amateur Radio AX.25 Level 2 protocol
[*] AX.25 DAMA Slave support
[*] Amateur Radio NET/ROM protocol
[*] Amateur Radio X.25 PLP (Rose)
AX.25 network device drivers --->
<M> Serial port KISS driver
<M> Serial port 6PACK driver
<M> BPQ Ethernet driver
<M> High-speed (DMA) SCC driver for AX.25
<M> Z8530 SCC driver
<M> BAYCOM ser12 fullduplex driver for AX.25
<M> BAYCOM ser12 halfduplex driver for AX.25
<M> BAYCOM picpar and par96 driver for AX.25
<M> BAYCOM epp driver for AX.25
<M> Soundcard modem driver
[*] soundmodem support for Soundblaster and compatible cards
[*] soundmodem support for WSS and Crystal cards
[*] soundmodem support for 1200 baud AFSK modulation
[*] soundmodem support for 2400 baud AFSK modulation (7.3728MHz crystal)
[*] soundmodem support for 2400 baud AFSK modulation (8MHz crystal)
[*] soundmodem support for 2666 baud AFSK modulation
[*] soundmodem support for 4800 baud HAPN-1 modulation
[*] soundmodem support for 4800 baud PSK modulation
[*] soundmodem support for 9600 baud FSK G3RUH modulation
<M> YAM driver for AX.25
these drivers are great for networking using old 2-way radios and sound card doing cool things like this http://www.ariss.net