Dell Inspiron 6000

[Sejam]

Let's go on talking about troubles that suck... What pisses me off is that I sometimes switch from X to a text console and find myself in front of a black screen. I can switch back to X, screen is still black. I can also restart X (typing blind commands, of course), still black.

Note the computer is not hung. It is just displaying nothing. Backlight is on but every single pixel on the screen is black. I must reboot for a "cure". I presume running vbetool post would as well though I never tried.

I'm starting to suspect cpufreqd as I just re-enabled it a couple of days ago and I (think I) never experienced a black screen meanwhile. What also sucks is that it can happen after switching once... or twice... or five time... or even longer...

Anyone witnesses this?

Funny, that's the reason I'm checking this again is because after reinstalling because of too many problems after the bios update, I have everything working, but am experiencing the same issues with the blank screen. Even the tricks I used to use in the past don't work. One thing to note is that I am not using cpufreqd and it is still occurring for me.

Reliefed (but not glad) the problem has been reproduced. I have BIOS A07, how about you, Sejam? Should we suspect Dell Video BIOS or the kernel or X's video driver? Does it also happen only when the PC is on batteries or did it also happen while on AC?

I'm currently using the latest bios available, which is A08. This does occur no matter if the laptop is plugged in or on battery. If the screen shuts off because of power management, and then turned back up (like moving a mouse, etc), the screen itself turns on, but nothing is every displayed again without resetting. As mentioned in another forum I was in with you, I have a very sneeky suspicion that this could be caused by the agp patch that is being applied. I wish I had more time to spend debugging the code, but I'm spending 60 hours / week at work right now and am in middle of a house purchase which takes the rest of the time.

[VinzC]

...
As mentioned in another forum I was in with you, I have a very sneeky suspicion that this could be caused by the agp patch that is being applied...

You mean the [topic=364512]lnx_agp[/topic] patch that enables DRI?

[PolarXL]

The sound problem I was having (permission to /dev/dsp denied to some applications), I've found out what the issue was... As suggested, I simply needed to chgrp all the /dev/ files that point to things in /dev/dsp to the "audio" group. Before, it looked like this:

Code: Select all

>ls -l /dev/dsp | grep sound
rwxrwxrwx  1 root root        10 Sep 28 21:10 adsp -> sound/adsp
lrwxrwxrwx  1 root root        11 Sep 28 21:10 audio -> sound/audio
lrwxrwxrwx  1 root root         9 Sep 28 21:10 dsp -> sound/dsp
lrwxrwxrwx  1 root root        11 Sep 28 21:10 mixer -> sound/mixer
lrwxrwxrwx  1 root root        15 Sep 28 14:10 sequencer -> sound/sequencer
lrwxrwxrwx  1 root root        16 Sep 28 14:10 sequencer2 -> sound/sequencer2
lrwxrwxrwx  1 root root        24 Sep 28 14:10 sndstat -> /proc/asound/oss/sndstat
d---------  2 root root         0 Sep 18 13:42 sound

Everything that stuff points to in "/dev/sound/" is already in the audio group... no problem, it pretty much stays that way. It's the softlinks in /dev that are the source of my problem.

That problem being, if I go through and change everything listed above with "chgrp audio", as soon as I reboot my /dev/ directory returns to the state it is above, with everything in the "root" group and not the "audio" group.

There's some bad ways to fix this... Add my users to the "root" group, throw down a startup script that chgrp's everything (not necessarily a bad fix, but it's a symptom fix, and I'd rather kill off the source of the problem in case it's wreaking havok elsewhere... But I'd really rather find out what's CAUSING all this and fix THAT instead.

If it helps, I'm running alsa (As kernel modules, not drivers) as per the Gentoo guide instructions, and primarily using KDE.

Kinda weirding me out, most of the problems with Gentoo I've encountered so far have been compatibility speedbumps with the Inspiron 6000 hardware... But apparently most of you haven't hit this specific problem... Hoping some of you have?

Much appreciated.
-Alex

[VinzC]

The sound problem I was having (permission to /dev/dsp denied to some applications), I've found out what the issue was... As suggested, I simply needed to chgrp all the /dev/ files that point to things in /dev/dsp to the "audio" group. Before, it looked like this:

Code: Select all

>ls -l /dev/dsp | grep sound
rwxrwxrwx  1 root root        10 Sep 28 21:10 adsp -> sound/adsp
lrwxrwxrwx  1 root root        11 Sep 28 21:10 audio -> sound/audio
lrwxrwxrwx  1 root root         9 Sep 28 21:10 dsp -> sound/dsp
lrwxrwxrwx  1 root root        11 Sep 28 21:10 mixer -> sound/mixer
lrwxrwxrwx  1 root root        15 Sep 28 14:10 sequencer -> sound/sequencer
lrwxrwxrwx  1 root root        16 Sep 28 14:10 sequencer2 -> sound/sequencer2
lrwxrwxrwx  1 root root        24 Sep 28 14:10 sndstat -> /proc/asound/oss/sndstat
d---------  2 root root         0 Sep 18 13:42 sound

Everything that stuff points to in "/dev/sound/" is already in the audio group... no problem, it pretty much stays that way. It's the softlinks in /dev that are the source of my problem.

That problem being, if I go through and change everything listed above with "chgrp audio", as soon as I reboot my /dev/ directory returns to the state it is above, with everything in the "root" group and not the "audio" group.

There's some bad ways to fix this... Add my users to the "root" group, throw down a startup script that chgrp's everything (not necessarily a bad fix, but it's a symptom fix, and I'd rather kill off the source of the problem in case it's wreaking havok elsewhere... But I'd really rather find out what's CAUSING all this and fix THAT instead.

If it helps, I'm running alsa (As kernel modules, not drivers) as per the Gentoo guide instructions, and primarily using KDE.

Kinda weirding me out, most of the problems with Gentoo I've encountered so far have been compatibility speedbumps with the Inspiron 6000 hardware... But apparently most of you haven't hit this specific problem... Hoping some of you have?

Much appreciated.
-Alex

As I told you earlier this *is* UDEV related. Check in /etc/udev/rules.d/ for the presence of a file, 50-udev.rules. You should have such a section:

Code: Select all

# sound devices
KERNEL=="adsp",                 NAME="sound/%k", SYMLINK+="%k", GROUP="audio"
KERNEL=="adsp[0-9]*",           NAME="sound/%k", SYMLINK+="%k", GROUP="audio"
KERNEL=="audio",                NAME="sound/%k", SYMLINK+="%k", GROUP="audio"
KERNEL=="audio[0-9]*",          NAME="sound/%k", SYMLINK+="%k", GROUP="audio"
KERNEL=="dsp",                  NAME="sound/%k", SYMLINK+="%k", GROUP="audio"
KERNEL=="dsp[0-9]*",            NAME="sound/%k", SYMLINK+="%k", GROUP="audio"
KERNEL=="mixer",                NAME="sound/%k", SYMLINK+="%k", GROUP="audio"
KERNEL=="mixer[0-9]*",          NAME="sound/%k", SYMLINK+="%k", GROUP="audio"
KERNEL=="sequencer",            NAME="sound/%k", SYMLINK+="%k", GROUP="audio"
KERNEL=="sequencer[0-9]*",      NAME="sound/%k", SYMLINK+="%k", GROUP="audio"

If not you might have a custom UDEV rule files (more information on how to write UDEV rules).

If you want you can copy/paste any existing rule from /etc/udev/rules.d/50-udev.rules and only change the equal sign into a colon+equal sign to prevent UDEV from overwriting what you've setup. Example:

Code: Select all

KERNEL=="adsp",                 NAME="sound/%k", SYMLINK+="%k", GROUP:="audio"

[seppelrockt]

Serious Clock problems! I can do what I want, my clock is at least 10 minutes ahead the current time one day after I set it to the corrrect time. This seems to be hard to track down, because I use Windows on the same maschine, too.

I suspect the timer in the kernel to cause the problem, cause the problem is here since the Pentium-M speedstep works, I guess. My current settings are:

# in /etc/conf.d/clock:

Code: Select all

CLOCK="local"
CLOCK_SYSTOHC="no"

My BIOS clock is set to the local time to not scare Windows. The CLOCK_SYSTOHC entry say whether or not one wants to sync the BIOS clock to system clock on shutdown. Since I have no possibility for NTP "no" is good choise here I think. But this would say, the maybe wrong time I get after running Gentoo for a longer time (e.g. in speedstep) would not affect BIOS time and after reboot the time should be fine. But it isn't! To make the linux part work, do you use HPET_TIMER in the kernel? I don't.

What about Windows? Can I say Windows not to change the BIOS time (or does it per default?) And it doesn't check NTP servers per default, right? I ask because there are said to be some wrongly set up NTP Server in the local net.

And are there know hardware problems that might solve a wrong clock/timer?

Sorry for the confusing posts, but I have no clue were to start with my problem - it seems like whatever I do with my Latop, the time is wrong about ~ 10 Minutes on the next day.

[VinzC]

My BIOS clock is set to the local time to not scare Windows. The CLOCK_SYSTOHC entry say whether or not one wants to sync the BIOS clock to system clock on shutdown.

Not much I can tell about that. I only know you should set CLOCK="local" if you dual boot with Windows.

Since I have no possibility for NTP "no" is good choise here I think. But this would say, the maybe wrong time I get after running Gentoo for a longer time (e.g. in speedstep) would not affect BIOS time and after reboot the time should be fine. But it isn't! To make the linux part work, do you use HPET_TIMER in the kernel? I don't.

I think I had to use HPET timer for I had messages like "too much clock skew detected" or something like that. There is an option to add to the kernel that fixes that problem. You might want to check it out. I can't tell you which one right now for I'm not running Gentoo for the moment.

What about Windows? Can I say Windows not to change the BIOS time (or does it per default?) And it doesn't check NTP servers per default, right?

Well Windoze is not known for its ability to carefully listen to your needs and what you say... (flame war again ). Anyway you can use different NTP servers if you want in Windows and Linux as well. Say pool.ntp.org is the generic choice. Windows XP however suggests time.windows.com but does not enable it by default. You have to either go to your clock and date properties and enable servers you want in the Internet Time tab or run the following command:

Code: Select all

net time /setsntp:"de.pool.ntp.org time.windows.com pool.ntp.org"

Your corporate firewall must allow in/out traffic on TCP/UDP port 123 however. Also note that your local DHCP might as well override what you set manually (if I'm right). The difference in Linux is you can prevent dhcpcd from overwriting /etc/ntp.conf if you've, say, configured it manually.

I ask because there are said to be some wrongly set up NTP Server in the local net.

Are you sure about your LAN NTP servers? Normally an NTP server is not that hard to configure as they rely in fine on the same NTP root servers.

[seppelrockt]

Since I have no possibility for NTP "no" is good choise here I think. But this would say, the maybe wrong time I get after running Gentoo for a longer time (e.g. in speedstep) would not affect BIOS time and after reboot the time should be fine. But it isn't! To make the linux part work, do you use HPET_TIMER in the kernel? I don't.

I think I had to use HPET timer for I had messages like "too much clock skew detected" or something like that. There is an option to add to the kernel that fixes that problem. You might want to check it out. I can't tell you which one right now for I'm not running Gentoo for the moment.

OK, would be nice if you can post the details later.

What about Windows? Can I say Windows not to change the BIOS time (or does it per default?) And it doesn't check NTP servers per default, right?

Well Windoze is not known for its ability to carefully listen to your needs and what you say... (flame war again ). Anyway you can use different NTP servers if you want in Windows and Linux as well. Say pool.ntp.org is the generic choice. Windows XP however suggests time.windows.com but does not enable it by default. You have to either go to your clock and date properties and enable servers you want in the Internet Time tab or run the following command:

Code: Select all

net time /setsntp:"de.pool.ntp.org time.windows.com pool.ntp.org"

Your corporate firewall must allow in/out traffic on TCP/UDP port 123 however. Also note that your local DHCP might as well override what you set manually (if I'm right). The difference in Linux is you can prevent dhcpcd from overwriting /etc/ntp.conf if you've, say, configured it manually.

Well, NTP Lookup was checked in Windows and I unchecked it now. I can only use the local NTP (which I don't trust) because I have no access to the firewall rules though they are not subject to change for me (university network). I guess that's the reason why the local NTPs are not accurate - they have the same port restrictions and can not sync themselves.
I run Windows only yesterday and checked the time today before I booted Linux. In Win it was exactly the time as shown on uhrzeit.org/atomuhr.html - thus Windows doesn't mess up the time. After that I booted Linux and voilà: 13 Minutes time missmatch. But I do not have any dmesg output about lost ticks or something.

[VinzC]

I suggest you erased the drift log from your Linux box. I think it might help for it seems Linux remembers the amount of time the clock is late or ahead. You can find where the drift log is located by inspecting your /etc/ntp.conf. Do it after you shutdown /etc/init.d/ntpd.

EDIT: ntpd on Linux does now the same as the ntp-client + ntpd pair did before. It first steps then continuously skews the clock. Before that both applications could synchronize with different NTP servers if you wanted, which is no longer true now with ntpd.

[VinzC]

OK, would be nice if you can post the details later.

After all I'm not using HPET.

Code: Select all

$ zgrep -i hpet /proc/config.gz
# CONFIG_HPET_TIMER is not set
# CONFIG_HPET is not set

But I have CONFIG_X86_PM_TIMER flag set in Power Management Options > ACPI

Code: Select all

[*] ACPI Support
<*>   AC Adapter
<*>   Battery
<*>   Button
<*>   Video
<*>   Fan
<*>   Processor
<*>     Thermal Zone
[*]   Power Management Timer Support

[seppelrockt]

OK, my clock is working as it should again - it was just my fault I think! When it went wrong the first time I just tried to correct it in to many different pleaces (e.g. when you change the time within KDE is syncs hwclock, two). It helped to read the hwclock man page and to delete the /etc/adjtime (which stored very high values in my case because I handled my clock problem wrong).

Other question: Is anybody here using kernel 2.6.13? I wonder why the gentoo version of it is marked stable but not the vanilla one ...

[VinzC]

OK, my clock is working as it should again - it was just my fault I think! When it went wrong the first time I just tried to correct it in to many different pleaces (e.g. when you change the time within KDE is syncs hwclock, two). It helped to read the hwclock man page and to delete the /etc/adjtime (which stored very high values in my case because I handled my clock problem wrong).

Glad you could solve your problem .

Other question: Is anybody here using kernel 2.6.13? I wonder why the gentoo version of it is marked stable but not the vanilla one ...

Probably because the unpatched version is not stable and the patched version is. Thanks Gentoo devs. Also DEVFS has been now completely removed from 2.6.13, which is Gentoo's way. Maybe they wanted the change to be smoother for the rest of the community.

[latzer]

Before I compiled and switched to gcc-3.4.3, my cflag was -march=pentium3 and after switching to gcc-3.4.3 i changed that to -march=pentium-m. Did a emerge gcc, then used gcc-config to switch to using 3.4.3. Of course doing this can cause problems with other packages in portage. If you chose just to stick with gcc-3.3.5 i would recommend using -march=pentium3 and not -march=pentium-m or -march=pentium4.

how do I get gcc-3.4.3 ????

[VinzC]

how do I get gcc-3.4.3 ????

As explained in the original post, unmasking GCC will give you GCC 3.4.3. You'll have to... compile it with GCC 3.3.x. This article will probably help you trough. GCC 3.4.y is still masked and you'll have to unmask it to use it. Recompile your packages - mostly GLIBC - with the new GCC *after* you have switched to GCC 3.4 as both versions are not mutually exclusive.

[seppelrockt]

Damn, I lost the bug entries for the ACPI LID problem (on kernel bugger) and about full support of the TWO devices / pipes / what_ever_it_is_called of the GMA900 (on the freedesktop bugger). Is anybody here subcribed or CCed for them and can tell me the bug numbers (or provide links)? Thanks in advance!

EDIT: And did anybody test the xorg-server-0.99.1.x (and related) split ebuilds yet? The new ebuilds from today are from latest xorg CVS so maybe there is something new inside for Intel GMA900 / GM915?

[seppelrockt]

I have a problem with ripping Audio-CDs that might be hardware related. If you want to help me please look
here. Thanks!

EDIT: link fixed.

[VinzC]

I have a problem with ripping Audio-CDs that might be hardware related. If you want to help me please look
[post=396657]here[/post]. Thanks!

This topic does not exists ...
Ok, fixed now

[seppelrockt]

I am testing the 2.6.14 vanilla sources ATM. First good thing: ieee80211 + ipw2200 are included into the kernel now, no stupid extermal kernal module installs now. Great!

Second promissing feature:

[libata] allow ATAPI to be enabled with new atapi_enabled module option

ATAPI is getting close to being ready. To increase exposure, we enable
the code in the upstream kernel, but default it to off (present
behavior). Users must pass atapi_enabled=1 as a module option (if
module) or on the kernel command line (if built in) to turn on
discovery of their ATAPI devices.

drivers/scsi/libata-core.c blob | diff | history
drivers/scsi/libata-scsi.c blob | diff | history
drivers/scsi/libata.h blob | diff | history
include/linux/libata.h blob | diff | history

This means the libata-atapi.patch doesn't work but is not need anymore. Tried to get it working by adding atapi_enabled=1 to my grub kernel boot line (stuff in in kernel, no module) but the DVD drive is not shown Did I do something wrong or do I need any other kernel stuff? What is the exact kernel "module" to which the atapi_enable applies?

EDIT: Works! The kernel parameter must be libata.atapi_enabled=1 !

EDIT2: Damn, it doesn't work when I comes to burning CDs/DVDs ... is cdrecord to blame for it (claims not to be able to attach driver to the drive)?

[seppelrockt]

PLEASE: Can somebody try if the Dell I6000 freezes when one wants to rip a Audio-CD with Konqueror audiocd:/ KIO? When I try this the KIO eates all my RAM + CPU and freezes when the SWAP is full.

I have 1 GB RAm and highmem NOT set in the kernel? Should I try highmem?

I use kde 3.5 beta2.

Thanks in advance!

[VinzC]

I have 1 GB RAm and highmem NOT set in the kernel? Should I try highmem?

If you have 1 GB RAM then you should enable HIGMEM. It will let the kernel access to about 384 MB above 1 GB limit.

[seppelrockt]

I have 1 GB RAm and highmem NOT set in the kernel? Should I try highmem?

If you have 1 GB RAM then you should enable HIGMEM. It will let the kernel access to about 384 MB above 1 GB limit.

Yes, I alraedy did this today and indead I have more RAM available now. But it doesn't solve my problem concerning the KIO slave. Same problem remains I wonder whether I should blame the experimental libata stuff or the KIO itself? It would be great if a Dell I6000 user who uses libata for the CD drive could simpy put a Audio CD in the drive and start the KDE audiocd:/ KIO - and then tell me what happens.

[VinzC]

... As mentioned in another forum I was in with you, I have a very sneeky suspicion that this could be caused by the agp patch that is being applied. I wish I had more time to spend debugging the code, but I'm spending 60 hours / week at work right now and am in middle of a house purchase which takes the rest of the time.

Well I've just happened to run Xorg 6.8.99.15-r4 without the lnx_agp patch and the problem came again. This means the black screen we both experienced has nothing to do with it. There must be something else that caused that bug.

[VinzC]

Anyone tried Xorg 7.0 rc1 already?

[seppelrockt]

Anyone tried Xorg 7.0 rc1 already?

Hmmm, I might try it without the patch first - right? Well, let's see what the next hours bring. I will test the monolitic one. Buy the way: the monolitic one shouldn't be called 7.0 but 6.9 - that's here portage hits its limitations I guess

Any news about 2.6.14 kernel? I moved back to 2.6.12.5 cause the DVD burner has problems with 2.6.14 and the ipw2200 in the kernel is said to be very old. But hey, they head in the right direction at least

[seppelrockt]

OK, xorg-x11-7.0.0_rc1 work here. The patch is not needed - DRI works out of the box (with vanilla-sources-2.6.12.5). I have ~1200 FPS with 1280x800@24bit on my Intel GMA900 (same os before with patch).

What I like is that I now have only ~50% of the stuff that belongs to xorg installed, and the OpenOffice transparency bug is solved, too.

I will write some more lines when it all run stable for some days (and I have some free minutes) - I have to investigate in the fonts topic for example.

[VinzC]

What I like is that I now have only ~50% of the stuff that belongs to xorg installed...

What do you mean exactly? Is there more than one package required for Xorg now?