Fatdog64-620beta1 (Thread closed)

A home for all kinds of Puppy related projects
Message
Author
User avatar
irishrm
Posts: 271
Joined: Sat 14 Mar 2009, 14:09

#31 Post by irishrm »

Jamesbond:
Did the reboot-did the scan-did the reconnect but still no connection.

BC-wl status:
Start at boot: yes
Currently running: yes
Control file: 30-BC-wl.

I have a working install of fatdog 510 and 610.
I also have precise and slacko installs with the wl driver working with frisbee.

I may get a better result with a later release of 620.
Thanks to yourself and kirk for your help.

irishrm.

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#32 Post by jamesbond »

irishrm,

If you don't mind, one last thing - can you dump the output of "dmesg" from terminal here? We may see something that may help. Broadcom isn't a good wireless chips to have, I regret to say (and I'm saying this as one who owns one too) :( The proprietary "wl" drivers haven't been updated in the last two years (check it yourself here: http://www.broadcom.com/support/802.11/linux_sta.php), I think with the intention that the open-source driver will take over, but the open-source driver isn't up to par yet. So what has been done on the "wl" drivers are patches upon patches upon patches by people, without knowing that broadcom is doing internally within their binary blob. Sometimes you hit jackpot and it works, but it then we hit issues like yours.

JustGreg,

I remember something - those "special keys" buttons are problematic. Some of them are "hardcoded" into ACPI bios - they always work whatever the OS you install (even on no OS at all). Some of them are wired through ACPI events. Some of them are wired through ACPI events *only* if you have the right wmi driver loaded (in your case, probably hp_wmi as you said). Some of them are routed through normal keyboard driver, but they are extremely broken (e.g. button generates keypress without corresponding keyrelease, or generates very funny keycode which requires mapping etc). In the latter cases, one needs to capture the "event" and then run a script to do something (e.g."rfkill" to turn on/off the devices). Try to run "xev" first and when the mouse is over the xev window, press F9 key and tell me what you've got. Also try to run "evtest" from terminal, then choose your keyboard input, then press your magic F9 key and see how it goes.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
irishrm
Posts: 271
Joined: Sat 14 Mar 2009, 14:09

#33 Post by irishrm »

Thanks jamesbond.

I'm attaching dmesg.

Don't waste any more time on trying to get a fix.
I have plenty to be going on with. Maybe it might work in the next release.

irishrm.
Attachments
dmesg.zip
(10.32 KiB) Downloaded 521 times

JustGreg
Posts: 782
Joined: Tue 24 May 2005, 10:55
Location: Connecticut USA

#34 Post by JustGreg »

Thanks for the information, JamesBond.

The savefile directory was on an ext2 filesystem partition. Now that I know the spot directory has the needed files, I can try it again and make any changes as needed.

I did the two tests on the key. It turns out the special key is the "F12" key. The F12 key press is not detected by either xev or evtest. I will have to remember those two utilities. The good news is the wifi module can be control by rfkill either rfkill block wlan or rfkill unblock wlan. That problem is solved.

I have been having x server start up "hiccups" with the Radeon driver. Sometimes, it does not start up correctly. I get the mouse cursor with either a white screen or one with no display (cursor can be seen). Fatdog does not have the utility reportvideo like other puppies. It does help with these types of problems. I have tried the Vesa driver and it failed. I have a couple of ideas I will try to see if I get a better information on what is failing to start.

Some additional information

I tried using the older ATI driver to see if the problem would go away. It did not. When the driver/ xserver seem to fail to start, one needs to use the power key to get out of the hung system. This loses any logs. I did find if I do a manual (pfix=nox) start of the x server then it always works. It may take longer to display the desktop, but, it does start. I did notice one item with pfix=nox. The console seems to stop at the command "Starting HAL daemon /usr/sbin/hald --daemon=yes" One needs to press the "enter" key to get the console prompt. I do not know if this is an issue. But, it was the only thing that caught my attention. I hope this helps.
Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

User avatar
smokey01
Posts: 2813
Joined: Sat 30 Dec 2006, 23:15
Location: South Australia :-(
Contact:

#35 Post by smokey01 »

JustGreg,

The report-video here seems to work ok.
http://www.murga-linux.com/puppy/viewto ... 5fc#677225

JustGreg
Posts: 782
Joined: Tue 24 May 2005, 10:55
Location: Connecticut USA

#36 Post by JustGreg »

Thanks Smoke01! I have down loaded the pet and will try it out. It is nice to know that report-video is not arch dependent. Thanks again. I will report how it worked here.

08:48 EST, The pet loaded and started. However, it did not report any information. It may be do to fatdog64 does not have same xorg configuration as the other puppies. The xorg.conf file does not have a video section that lists the driver. It is not clear to me how the graphics video is started. Thanks for the information on the pet.
Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

JustGreg
Posts: 782
Joined: Tue 24 May 2005, 10:55
Location: Connecticut USA

#37 Post by JustGreg »

I have been starting fatdog64 620BETA with the pfix=nox option to insure the x server starts correctly. When I have 620BETA start directly into x server, the x server fails to start correctly. There is no video display and it does not respond to either ctrl alt backspace or ctrl alt delete key commands. The mouse cursor is present and responds correctly. I have tried the ATI driver with the same results. It seems something is interfering with the startup processes (maybe the hal daemon process and window manager?).

I also delete the existing save file and started with nosave file. BETA620 initialized correctly with a x server and window manager. I did create a save directory. I do like the save directory. It does work well. I tried a restart and x server failed. Back to nox option for start up.

I can not get any of the logs to see what is failing.
Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

kirk
Posts: 1553
Joined: Fri 11 Nov 2005, 19:04
Location: florida

#38 Post by kirk »

I also delete the existing save file and started with nosave file. BETA620 initialized correctly with a x server and window manager. I did create a save directory. I do like the save directory. It does work well. I tried a restart and x server failed. Back to nox option for start up.
I just want to make sure I understand what's going on:

With no savefile or booting with savefile=none, the video works? Always?

The save directory is located on a ext2/3/4 partition?

If you boot with pfix=nox and then type xwin the video works? Always?


If the answer to all questions is yes, that makes me think that we might be starting X before your card is ready. Fatdog64-620 boots pretty fast. This can cause problems with some hardware, especially if that hardware has to load and initialize firmware. Which some radoens do. So if the answer to the last question is always yes add sleep 3 to /etc/rc.d/rc.local. You can open a terminal and do this:

Code: Select all

echo "sleep 3" >> /etc/rc.d/rc.local


or do it with Geany. If that works, you might be able to reduce that number from 3 using Geany to edit /etc/rc.d/rc.local.

JustGreg
Posts: 782
Joined: Tue 24 May 2005, 10:55
Location: Connecticut USA

#39 Post by JustGreg »

Answers to your questions:
With no savefile or booting with savefile=none, the video works? Always?
Yes
The save directory is located on a ext2/3/4 partition?
It is an ext2 partition. I am planning to change to ext3 with final version of 620.
If you boot with pfix=nox and then type xwin the video works? Always?
No, sometimes it would fail usually after a cold boot from power off. After reboot, the problem would not occur. However, if I used rfkill to block the wifi, then it would always work.

I added the sleep 3 to /etc/rc.d/rc.local and it seems to have solve the issue. This works for both power on boot and reboot.

I also did some search on Hal daemon and failure to start X. The Radeon driver seem to be associated with most of the reports. It either solved the problem or had no impact. Based on the rfkill block wlan command helping, I was going to ask how does one prevent wpa_gui from initializing the wifi at start up?

Fatdog64 does work well. I consider this problem to be a normal one encounter in BETA testing. Thanks as always for the help on this.
Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

kirk
Posts: 1553
Joined: Fri 11 Nov 2005, 19:04
Location: florida

#40 Post by kirk »

No, sometimes it would fail usually after a cold boot from power off. After reboot, the problem would not occur. However, if I used rfkill to block the wifi, then it would always work.

I added the sleep 3 to /etc/rc.d/rc.local and it seems to have solve the issue. This works for both power on boot and reboot.
If booting with pfix=nox and then typing xwin did not always work, I would be surprised that adding the sleep would fix it. If you don't want the wpa_supplicant stuff to run right-click on wpa_gui and select Network Wizard. Then uncheck the box at the bottom. The Hal daemon thing is nothing to worry about.

JustGreg
Posts: 782
Joined: Tue 24 May 2005, 10:55
Location: Connecticut USA

#41 Post by JustGreg »

Thank you Kirk for the reply. I had another failure to start from power on (cold boot). I have increased the sleep time to 5 seconds. It seems to help. I have tried three cold starts in a row with about 5 minutes between the shut off and start. Not a single failure. I will keep an eye on it. Thanks again for the help.
Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

User avatar
Ray MK
Posts: 774
Joined: Tue 05 Feb 2008, 09:10
Location: UK

#42 Post by Ray MK »

Fatdog64 620beta1

Manual frugal to an ntfs partition and booting via grub4dos on an SDcard.

Finally got hold of a 64bit laptop again (sadly the screen is cracked) so using an old ProView LCD monitor that seems to work quite well.

The laptop is an E732 (Emachines / Acer) with an i3proc. and 2gig ram.

Fantastic Puppy - so fast - it screams.

Boots in seconds - wifi seems ok and all the basics seem fine OOTB.

Many thanks to kirk, james bond & others for helping to make what is probably the best 64bit distro on the planet.

Hinfo report FYI. Very best regards - Ray
Attachments
hardinfo_report.html.gz
not a gz. rename to html.
(46.54 KiB) Downloaded 477 times
[b]Asus[/b] 701SD. 2gig ram. 8gb SSD. [b]IBM A21m[/b] laptop. 192mb ram. PIII Coppermine proc. [b]X60[/b] T2400 1.8Ghz proc. 2gig ram. 80gb hdd. [b]T41[/b] Pentium M 1400Mhz. 512mb ram.

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#43 Post by nooby »

Seamonkey in this lastest version seems different to the one
in 611. Local htmlfiles works as expected in the old FatDog
but totally fails in the new. I dl from smokey because the
other server was extremely slow some 63kb instead of 3MBsec

I trust the iso are same on both?
I use Google Search on Puppy Forum
not an ideal solution though

Post Reply