I did as before, updated from 0.13, this time the wireless worked on the first boot, that was the last I saw of it, a reboot showed nothing, I installed the b43 drivers but it made no difference same as before I have to load the driver manually but it don't find the hardware.pemasu wrote:Geoffrey.
Your new dmesg log shows that the firmware loading fails.
Okay. I did this in Saluki-014. I downloaded needed b43-firmware-cutter, compiled it, then I downloaded the correct source of firmwares and installed them. I created the pet of the result.
These 117 firmwares are basically the same as the included but they are prepared in Saluki-014.
I dont know if they make any difference, but we need a candidate to test.
This pet basically overwrites the existing firmwares in /lib/firmware/b43. You can first manually delete them to be sure.
Saluki
- antiloquax
- Posts: 405
- Joined: Fri 27 Jan 2012, 09:17
That's great!jemimah wrote:
I've split the Python3 packages and added it to the repo:
My System:Arch-Arm on RPi!
"[url=http://murga-linux.com/puppy/viewtopic.php?t=76049l]RacyPy[/url]" puplet on Toshiba Tecra 8200. PIII, 256 MB RAM.
[url=http://raspberrypy.tumblr.com/]RaspberryPy[/url]: Lobster and I blog about the RPi.
"[url=http://murga-linux.com/puppy/viewtopic.php?t=76049l]RacyPy[/url]" puplet on Toshiba Tecra 8200. PIII, 256 MB RAM.
[url=http://raspberrypy.tumblr.com/]RaspberryPy[/url]: Lobster and I blog about the RPi.
UPnP,DLNA,DAAP,RSP,MPD
Jemimah wrote:
Avahi now works, however one has to still adduser avahi then reboot for it to auto start. If you are yet finish up on saluki 15, i would suggest that from your curent setup you do .
four files are modified in the /etc folder these are 'group' 'gshadow' 'passwd' and 'shadow' you could place the modified files in woof so that saluki always has the user avahi. Then all it takes is for one to install avahi and the start up scripts handle the rest. Works for me i remastered saluki with those four files and all works.
Code: Select all
Also I fixed avahi to run as root and added the startup scripts. I'm still not sure it is working so let me know.
Code: Select all
adduser avahi
four files are modified in the /etc folder these are 'group' 'gshadow' 'passwd' and 'shadow' you could place the modified files in woof so that saluki always has the user avahi. Then all it takes is for one to install avahi and the start up scripts handle the rest. Works for me i remastered saluki with those four files and all works.
new version of pfind
Zigbert has a new version of pfind that cures some bugs with Saluki
http://murga-linux.com/puppy/viewtopic. ... &start=420
_______________________________________________________________
http://murga-linux.com/puppy/viewtopic. ... &start=420
_______________________________________________________________
Re: reality
Well last week was commvault training, and it looks like I'll be interviewing for a bladelogic gig sometime this week. That's good news - it's not fun to be on the bench for this long.Volhout wrote:Jemimah,
How is the new job ?
Fresh manual frugal install of Saluki 015 on my main Athlon XP Linux box. Sound and internet good on initial boot , display incorrect at 1280x1024 instead of 1440x900. At least had a desktop and the ability to use xorgwizard through firstrun.
Installed several assorted pets, no problems.
# report-video
Saluki, version 015 on Tue 20 Mar 2012
Chip description:
0.0 VGA compatible controller
nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev c1)
oem: NVidia
product: NV18 () Board Chip Rev A2
X Server: Xorg
Driver used: nouveau
X.Org version: 1.11.0
dimensions: 1440x900 pixels (380x238 millimeters)
depth of root window: 24 planes
...the above also recorded in /tmp/root/ as report-video,
and archived with xorg.conf and Xorg.0.log as report-video-full.gz
# glxgears
530 frames in 5.0 seconds = 105.971 FPS
544 frames in 5.0 seconds = 108.604 FPS
536 frames in 5.0 seconds = 107.036 FPS
526 frames in 5.0 seconds = 105.199 FPS
519 frames in 5.0 seconds = 103.631 FPS
Summary
Computer
Processor AMD Athlon(tm) XP 2400+
Memory 1033MB (198MB used)
Operating System Unknown distribution
User Name root (root)
Date/Time Tue 20 Mar 2012 10:40:25 PM CDT
Display
Resolution 1440x900 pixels
OpenGL Renderer Software Rasterizer
X11 Vendor The X.Org Foundation
Multimedia
Audio Adapter VIA8233 - VIA 8235
Installed several assorted pets, no problems.
# report-video
Saluki, version 015 on Tue 20 Mar 2012
Chip description:
0.0 VGA compatible controller
nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x] (rev c1)
oem: NVidia
product: NV18 () Board Chip Rev A2
X Server: Xorg
Driver used: nouveau
X.Org version: 1.11.0
dimensions: 1440x900 pixels (380x238 millimeters)
depth of root window: 24 planes
...the above also recorded in /tmp/root/ as report-video,
and archived with xorg.conf and Xorg.0.log as report-video-full.gz
# glxgears
530 frames in 5.0 seconds = 105.971 FPS
544 frames in 5.0 seconds = 108.604 FPS
536 frames in 5.0 seconds = 107.036 FPS
526 frames in 5.0 seconds = 105.199 FPS
519 frames in 5.0 seconds = 103.631 FPS
Summary
Computer
Processor AMD Athlon(tm) XP 2400+
Memory 1033MB (198MB used)
Operating System Unknown distribution
User Name root (root)
Date/Time Tue 20 Mar 2012 10:40:25 PM CDT
Display
Resolution 1440x900 pixels
OpenGL Renderer Software Rasterizer
X11 Vendor The X.Org Foundation
Multimedia
Audio Adapter VIA8233 - VIA 8235
I believe this kernel sources is the right one:
http://www.smokey01.com/pemasu/Saluki/k ... ixed-aufs/
http://www.smokey01.com/pemasu/Saluki/k ... ixed-aufs/
v.15: Well done, angel! Can now get a picture on a wide range of monitors and video cards at boot up. The best results are on 10yr old lcd monitors and bog standard 12yr old AGP cards (typically early Rage), mostly defaulting to correct 1024x768 native. However, the serious problem of overdriving the latest led monitors @1600x1200 represents a real risk to the HW, even though the CTRL-ALT-BKSPCE/xorgwizard or nox cheat code expedients are now available. Still not clear were the 'feature' originates, but the common led monitor default of 1440x900 is missing from the Quickset option list. Fortunately, that res. does still appear in your xorg Probe list, but no longer in BK's Racy & Wary lists.
Probably-hopefully one of the expert gurus like Tman/Mick/pemasu will already have an answer to this worrying aspect before somebody's shiny new monitor goes pop!
Best Wishes for the jobsearch.
Probably-hopefully one of the expert gurus like Tman/Mick/pemasu will already have an answer to this worrying aspect before somebody's shiny new monitor goes pop!
Best Wishes for the jobsearch.
b43, udev etc
I fount some time to look at the b43 failure issue during the 013 to 014 upgrade 1, 2, 3, 4
The problem is which shows that the driver is loaded OK but this change makes ssb to fail
This is a recent ssb bug and there is a discussion/patch in the b43 mailing list.
I'm not sure this has anything to do with udev which loads 20 sec later
after the kernel has made the change (there is a different kernel compile between 013 and 014, right?), or the firmware per se.
Would be interesting to see a 013 to 015 update that have the same (?) udev and update (?) firmware.
The problem is
Code: Select all
[ 5.375580] b43-pci-bridge 0000:04:00.0: enabling device (0000 -> 0002)
Code: Select all
[ 5.407846] ssb: Unsupported SPROM revision 255 detected. Will extract v1
[ 5.423406] ssb: Sonics Silicon Backplane found on PCI device 0000:04:00.0
I'm not sure this has anything to do with udev which loads 20 sec later
Code: Select all
[ 25.621093] udev[8902]: starting version 167
Would be interesting to see a 013 to 015 update that have the same (?) udev and update (?) firmware.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
pop ?
Sage,
The time that monitors would get defect from wrong resolution settings is long gone..... Earlier tube monitors (CGA / Hercules) could be driven with too high frame rates, where the high voltage circuit got overheated. Since the apearance of multi sync monitors (even with the tubes) that stopped since the high voltage was generated independent from the verical sync frequency.
With the flat sceens you only get a message "choose different resolution".
No pops anymore .... the world gets less exciting ....
The time that monitors would get defect from wrong resolution settings is long gone..... Earlier tube monitors (CGA / Hercules) could be driven with too high frame rates, where the high voltage circuit got overheated. Since the apearance of multi sync monitors (even with the tubes) that stopped since the high voltage was generated independent from the verical sync frequency.
With the flat sceens you only get a message "choose different resolution".
No pops anymore .... the world gets less exciting ....
Sage wrote:v.15: Well done, angel! Can now get a picture on a wide range of monitors and video cards at boot up. The best results are on 10yr old lcd monitors and bog standard 12yr old AGP cards (typically early Rage), mostly defaulting to correct 1024x768 native. However, the serious problem of overdriving the latest led monitors @1600x1200 represents a real risk to the HW, even though the CTRL-ALT-BKSPCE/xorgwizard or nox cheat code expedients are now available. Still not clear were the 'feature' originates, but the common led monitor default of 1440x900 is missing from the Quickset option list. Fortunately, that res. does still appear in your xorg Probe list, but no longer in BK's Racy & Wary lists.
Probably-hopefully one of the expert gurus like Tman/Mick/pemasu will already have an answer to this worrying aspect before somebody's shiny new monitor goes pop!
Best Wishes for the jobsearch.
ok so i downloaded and tested Saluki both 014 and 015 from a flash drive, they will not work. I can boot into the desktop ok, with the usual puppy first time boot welcome screen. that's it.I cannot use mouse, keyboard, mousepad, or do anything
I have managed to set up Saluki to run in vbox. it runs ok. i like the look and feel it has. have to run full install for best results.
hopefully you have some suggestions i can try to get it going. from usb
I figure one of the boot options for Saluki might do the trick. but running from usb does not show the puppy boot options like from cd.
I would really like to use Saluki for my build project click here but without a working usb install its no good to me.
I have managed to set up Saluki to run in vbox. it runs ok. i like the look and feel it has. have to run full install for best results.
hopefully you have some suggestions i can try to get it going. from usb
I figure one of the boot options for Saluki might do the trick. but running from usb does not show the puppy boot options like from cd.
I would really like to use Saluki for my build project click here but without a working usb install its no good to me.
No pops anymore
Not too sure about that. Multi-synch means native and anything less! Solid state line o.p. stages are the most over-worked devices in the entire package. Apart from lcd tubes (and badcaps, which start that way), they account for the majority of failures I've seen. Mostly, component selection only just about meets the native resolution, like all modern electronics. In the olden days, they built in at least a 2x tolerance. Those days are long gone - it's all about cost now.
Yes, but the repo is up to date, so you should be able to download headers and the source sfs from the repo.pemasu wrote:I believe this kernel sources is the right one:
http://www.smokey01.com/pemasu/Saluki/k ... ixed-aufs/
Re: b43, udev etc
Not sure it is udev, but that's only only thing that changed between 13 and 14 that should have affected firmware in any way. 13 and 14 had the same firmware and kernel - the only change was udev.mavrothal wrote:I fount some time to look at the b43 failure issue during the 013 to 014 upgrade 1, 2, 3, 4
The problem iswhich shows that the driver is loaded OK but this change makes ssb to failCode: Select all
[ 5.375580] b43-pci-bridge 0000:04:00.0: enabling device (0000 -> 0002)
This is a recent ssb bug and there is a discussion/patch in the b43 mailing list.Code: Select all
[ 5.407846] ssb: Unsupported SPROM revision 255 detected. Will extract v1 [ 5.423406] ssb: Sonics Silicon Backplane found on PCI device 0000:04:00.0
I'm not sure this has anything to do with udev which loads 20 sec laterafter the kernel has made the change (there is a different kernel compile between 013 and 014, right?), or the firmware per se.Code: Select all
[ 25.621093] udev[8902]: starting version 167
Would be interesting to see a 013 to 015 update that have the same (?) udev and update (?) firmware.
Let's see if the problem has improved or not.