Intel 945GM: 2.6.25-rc3 report (with a possible regression)
Hi, this mail is to give feedback about the 2.6.25-rc3 kernel, on an Ubuntu 7.10 system, running on a Toshiba Satellite U305. Video is a Intel 845GM, and I run 915resolution at start to make X happy with the correct widescreen resolution. A lot of data is collected here (if more is needed, tell me): http://www.dea.icai.upcomillas.es/romano/linux/info/ 1) The minor regression is that I cannot have any more a correct console. I tried a lot of combinations, but without a framebuffer, console is garbled by ubuntu splash and/or X. With the .config copied in the site above, I do not have console (a random pattern appears as I switch consoles). With intelfb framebuffer, sometime it works, sometime it doesn't work, and everytime break resume from STR. (I mean, the laptop seems to resume, but the screen is blank). I have a doubt about this: is it possible that some state is maintained across reboots? Because sometime two reboots in a row led to different results; for example, after following https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/147606 I had a nice console, but after the failed resume and a sysrq-b reboot, no console again. 2) LCD/CRT switch. It's the first time I tried it, so no idea if it ever worked. Without a CRT connected, nothing happens pressing the key combination (fn-F5), correctly. When I connected a overhead proyector (CRT), pressed fn-F5, and the LCD went off and the CRT on (ok); after that the LCD never came on again. pressing again fn-f5 two times lead to a all-off, a third time made the CRT switch on, and again. The laptop is working but the LCD stay black till the next reboot. (It is very similar to what seems to happen after resume). 3) on the nice side of things, it seems that now echo mem > /sys/power/state works (at least in X, I do not have a console to test it...). Thank you very much, Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Intel 945GM: 2.6.25-rc3 report (with a possible regression)
Hi, this mail is to give feedback about the 2.6.25-rc3 kernel, on an Ubuntu 7.10 system, running on a Toshiba Satellite U305. Video is a Intel 845GM, and I run 915resolution at start to make X happy with the correct widescreen resolution. A lot of data is collected here (if more is needed, tell me): http://www.dea.icai.upcomillas.es/romano/linux/info/ 1) The minor regression is that I cannot have any more a correct console. I tried a lot of combinations, but without a framebuffer, console is garbled by ubuntu splash and/or X. With the .config copied in the site above, I do not have console (a random pattern appears as I switch consoles). With intelfb framebuffer, sometime it works, sometime it doesn't work, and everytime break resume from STR. (I mean, the laptop seems to resume, but the screen is blank). I have a doubt about this: is it possible that some state is maintained across reboots? Because sometime two reboots in a row led to different results; for example, after following https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/147606 I had a nice console, but after the failed resume and a sysrq-b reboot, no console again. 2) LCD/CRT switch. It's the first time I tried it, so no idea if it ever worked. Without a CRT connected, nothing happens pressing the key combination (fn-F5), correctly. When I connected a overhead proyector (CRT), pressed fn-F5, and the LCD went off and the CRT on (ok); after that the LCD never came on again. pressing again fn-f5 two times lead to a all-off, a third time made the CRT switch on, and again. The laptop is working but the LCD stay black till the next reboot. (It is very similar to what seems to happen after resume). 3) on the nice side of things, it seems that now echo mem /sys/power/state works (at least in X, I do not have a console to test it...). Thank you very much, Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ndiswrapper tainting
On Thu, 2008-02-21 at 20:02 -0500, Pavel Roskin wrote: > Hello! > > What are the chances that incorrect tainting of ndiswrapper will be > fixed in 2.6.25? > Please let's not turn it into another empty discussion. > > Seconded. Please. -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ndiswrapper tainting
On Thu, 2008-02-21 at 20:02 -0500, Pavel Roskin wrote: Hello! What are the chances that incorrect tainting of ndiswrapper will be fixed in 2.6.25? Please let's not turn it into another empty discussion. Seconded. Please. -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Thu, 2008-02-21 at 02:02 +0800, Jeff Chua wrote: > On Feb 21, 2008 1:52 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > Ahh. You're using the BIOS to re-initialize your video, aren't you? > > I don't know. Just pure simple "s2ram" without any options. Well, as far as I know, s2ram could be doing vbe save/restore for you. Even without parameter, if your laptop is in the whitelist. > > Let's try to narrow it down to what the interaction is. Are you using > > something like acpi_sleep=s3_bios or similar? > > No. Not additional command line option except for resume=/dev/sda3 reboot=bios My laptop (a Toshiba satellite U305, intel 945GM chipset, used to need s2ram -f -p -m to STR correctly. In 2.6.25-rc2 I can simply STR with echo mem > /sys/power/state. Romano I imagine this will be received as blasphemy, but if only ndiswrapper were not horribly broken, this will be my day-by-day kernel. I just hope ath5k will arrive to my chipset soon... -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.
On Thu, 2008-02-21 at 02:02 +0800, Jeff Chua wrote: On Feb 21, 2008 1:52 AM, Linus Torvalds [EMAIL PROTECTED] wrote: Ahh. You're using the BIOS to re-initialize your video, aren't you? I don't know. Just pure simple s2ram without any options. Well, as far as I know, s2ram could be doing vbe save/restore for you. Even without parameter, if your laptop is in the whitelist. Let's try to narrow it down to what the interaction is. Are you using something like acpi_sleep=s3_bios or similar? No. Not additional command line option except for resume=/dev/sda3 reboot=bios My laptop (a Toshiba satellite U305, intel 945GM chipset, used to need s2ram -f -p -m to STR correctly. In 2.6.25-rc2 I can simply STR with echo mem /sys/power/state. Romano I imagine this will be received as blasphemy, but if only ndiswrapper were not horribly broken, this will be my day-by-day kernel. I just hope ath5k will arrive to my chipset soon... -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc1/2 regression: first-time login into gnome fails
Hi, I have a very strange, but fully reproducible, regression with 2.6.25-rc1 -rc2. I have an ubuntu 7.10 fully updated. The first time after boot, when I login to gnome (through gdm) the login half-fails with a Setting Daemon error: failed to connect to socket /tmp/dbus-: connection refused. Nothing in the logs, and there is no such socket in /tmp. If I log out and then log in again, all works ok. With 2.6.24.2 there is no such a problem. .config, dmesg (2M buffer size) and syslog here: http://www.dea.icai.upcomillas.es/romano/linux/info/ Romano (Back to 2.6.24.2, because ndiswrapper broke again, and ath5k doesn't like (yet) my atheros adapter...) -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc1/2 regression: first-time login into gnome fails
Hi, I have a very strange, but fully reproducible, regression with 2.6.25-rc1 -rc2. I have an ubuntu 7.10 fully updated. The first time after boot, when I login to gnome (through gdm) the login half-fails with a Setting Daemon error: failed to connect to socket /tmp/dbus-some random stuff: connection refused. Nothing in the logs, and there is no such socket in /tmp. If I log out and then log in again, all works ok. With 2.6.24.2 there is no such a problem. .config, dmesg (2M buffer size) and syslog here: http://www.dea.icai.upcomillas.es/romano/linux/info/ Romano (Back to 2.6.24.2, because ndiswrapper broke again, and ath5k doesn't like (yet) my atheros adapter...) -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Rationalise ACPI backlight implementation
On Sat, 2008-02-02 at 09:30 -0200, Henrique de Moraes Holschuh wrote: > On Fri, 01 Feb 2008, Len Brown wrote: > > You might check if CONFIG_ACPI_VIDEO=m is set and you can load the "video" > > module. > > While the sony may be non-standard and not load, your thinkpad may work. [...] > > We really need to solve the userspace mess, though. > I do not know if this is relevant... but for example, with a i915 hw here (toshiba laptop): #cat max_brightness 100 #echo 50 > brightness ; cat actual_brightness 0 #echo 60 > brightness ; cat actual_brightness 0 #echo 70 > brightness ; cat actual_brightness 70 #echo 80 > brightness ; cat actual_brightness 0 #echo 90 > brightness ; cat actual_brightness 0 #echo 100 > brightness ; cat actual_brightness 100 #uname -a Linux rukbat 2.6.24 #13 SMP PREEMPT Fri Feb 1 13:12:23 CET 2008 i686 GNU/Linux which is at least strange (and probably broken). actual_brightness is real, when it says 0 backlight is off. You can imagine what happens using the backlight up/down control... flashing lights! Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Rationalise ACPI backlight implementation
On Sat, 2008-02-02 at 09:30 -0200, Henrique de Moraes Holschuh wrote: On Fri, 01 Feb 2008, Len Brown wrote: You might check if CONFIG_ACPI_VIDEO=m is set and you can load the video module. While the sony may be non-standard and not load, your thinkpad may work. [...] We really need to solve the userspace mess, though. I do not know if this is relevant... but for example, with a i915 hw here (toshiba laptop): #cat max_brightness 100 #echo 50 brightness ; cat actual_brightness 0 #echo 60 brightness ; cat actual_brightness 0 #echo 70 brightness ; cat actual_brightness 70 #echo 80 brightness ; cat actual_brightness 0 #echo 90 brightness ; cat actual_brightness 0 #echo 100 brightness ; cat actual_brightness 100 #uname -a Linux rukbat 2.6.24 #13 SMP PREEMPT Fri Feb 1 13:12:23 CET 2008 i686 GNU/Linux which is at least strange (and probably broken). actual_brightness is real, when it says 0 backlight is off. You can imagine what happens using the backlight up/down control... flashing lights! Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT] Port 0x80 I/O speed
On Wed, 2007-12-12 at 00:31 +0100, Rene Herman wrote:
> cc -W -Wall -O2 -o port80 port80.c
On a laptop with a CoreDuo T2080/1.73GHz, but running on battery at
800 MHz (on-demand):
(0)rukbat:~/tmp% for i in {1..10}; do
sudo ./port80
done
cycles: out 3575, in 2844
cycles: out 3589, in 2923
cycles: out 3672, in 2864
cycles: out 3575, in 2843
cycles: out 3607, in 2859
cycles: out 3623, in 2877
cycles: out 3604, in 2848
cycles: out 3575, in 2849
cycles: out 3598, in 2861
cycles: out 3613, in 2861
With a cpu-hog running, cpufreq reporting 1.73GHz:
(0)rukbat:~/tmp% for i in {1..10}; do
sudo ./port80
done
cycles: out 3446, in 2652
cycles: out 3499, in 2668
cycles: out 3395, in 2578
cycles: out 3452, in 2662
cycles: out 3448, in 2662
cycles: out 3622, in 2754
cycles: out 3457, in 2662
cycles: out 3451, in 2660
cycles: out 3581, in 2850
cycles: out 3477, in 2696
HTH,
Romano
Romano
--
Sorry for the disclaimer --- ¡I cannot stop it!
--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso
del destinatario indicado en la misma. Si Ud. no es el destinatario indicado,
le informamos que cualquier forma de distribución, reproducción o uso de esta
comunicación y/o de la información contenida en la misma están estrictamente
prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por
favor, notifíquelo inmediatamente al remitente contestando a este mensaje y
proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive
use of the intended addressee. If you are not the intended addressee, please
note that any form of distribution, copying or use of this communication or the
information in it is strictly prohibited by law. If you have received this
communication in error, please immediately notify the sender by reply e-mail
and destroy this message. Thank you for your cooperation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT] Port 0x80 I/O speed
On Wed, 2007-12-12 at 00:31 +0100, Rene Herman wrote:
cc -W -Wall -O2 -o port80 port80.c
On a laptop with a CoreDuo T2080/1.73GHz, but running on battery at
800 MHz (on-demand):
(0)rukbat:~/tmp% for i in {1..10}; do
sudo ./port80
done
cycles: out 3575, in 2844
cycles: out 3589, in 2923
cycles: out 3672, in 2864
cycles: out 3575, in 2843
cycles: out 3607, in 2859
cycles: out 3623, in 2877
cycles: out 3604, in 2848
cycles: out 3575, in 2849
cycles: out 3598, in 2861
cycles: out 3613, in 2861
With a cpu-hog running, cpufreq reporting 1.73GHz:
(0)rukbat:~/tmp% for i in {1..10}; do
sudo ./port80
done
cycles: out 3446, in 2652
cycles: out 3499, in 2668
cycles: out 3395, in 2578
cycles: out 3452, in 2662
cycles: out 3448, in 2662
cycles: out 3622, in 2754
cycles: out 3457, in 2662
cycles: out 3451, in 2660
cycles: out 3581, in 2850
cycles: out 3477, in 2696
HTH,
Romano
Romano
--
Sorry for the disclaimer --- ¡I cannot stop it!
--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso
del destinatario indicado en la misma. Si Ud. no es el destinatario indicado,
le informamos que cualquier forma de distribución, reproducción o uso de esta
comunicación y/o de la información contenida en la misma están estrictamente
prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por
favor, notifíquelo inmediatamente al remitente contestando a este mensaje y
proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive
use of the intended addressee. If you are not the intended addressee, please
note that any form of distribution, copying or use of this communication or the
information in it is strictly prohibited by law. If you have received this
communication in error, please immediately notify the sender by reply e-mail
and destroy this message. Thank you for your cooperation.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: namespace support requires network modules to say "GPL"
On Sat, 2007-12-01 at 22:34 -0500, Mark Lord wrote: > Stephen Hemminger wrote:. > >> > > I spoke too soon earlier, ndiswrapper builds and loads against current > > 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again > > I don't > > give a damn, but the enterprise distro vendors certainly care. > ... > > Naw, enterprise (or any other) distro vendors shouldn't have any issues here, > since they can just patch their kernels around any issues. Please pardon me for jumping in; I am not a kernel developer, but I try to help with debugging whenever I can (and it's not just hand-waving, I helped to track down a couple of nasty bugs on MMC or ACPI EC, recently). And I am an engineer and IANAL, so I wouldn't speak about laws here. But I think it's not just a distribution's problem. Unfortunately, I need VMware and ndiswrapper to get work done with my laptop. It's not the perfect world, but the only alternative is to boot in XP. So I normally stick with vendors kernels and, when I have time to "play" with new kernel, I go for it. If ndiswrapper and VMware work, perfect, I can test extensively the new kernel; if I find problems, I *know* I have to restart without proprietary modules, try to reproduce, report back. I did it a lot of times. What I think is that every time VMware or (worst) ndiswrapper breaks, the kernel loose an awful lot of testers. In the span of time before Giri and the VMware team post a patch (-rc1 and -rc4, tipically), my testing activity is just occasional. And I guess a lot of people is in the same situation. These are just my 2cents. I will continue to test new kernels every time I can, and to use native solutions as often as I can (go, ath5k, go!; and LabWindows/CVI for Linux, anyone?). But maybe a bit of tolerance can help everyone... Back in my hole, Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: namespace support requires network modules to say GPL
On Sat, 2007-12-01 at 22:34 -0500, Mark Lord wrote: Stephen Hemminger wrote:. I spoke too soon earlier, ndiswrapper builds and loads against current 2.6.24-rc3. Vmware and proprietary VPN software probably do not. Once again I don't give a damn, but the enterprise distro vendors certainly care. ... Naw, enterprise (or any other) distro vendors shouldn't have any issues here, since they can just patch their kernels around any issues. Please pardon me for jumping in; I am not a kernel developer, but I try to help with debugging whenever I can (and it's not just hand-waving, I helped to track down a couple of nasty bugs on MMC or ACPI EC, recently). And I am an engineer and IANAL, so I wouldn't speak about laws here. But I think it's not just a distribution's problem. Unfortunately, I need VMware and ndiswrapper to get work done with my laptop. It's not the perfect world, but the only alternative is to boot in XP. So I normally stick with vendors kernels and, when I have time to play with new kernel, I go for it. If ndiswrapper and VMware work, perfect, I can test extensively the new kernel; if I find problems, I *know* I have to restart without proprietary modules, try to reproduce, report back. I did it a lot of times. What I think is that every time VMware or (worst) ndiswrapper breaks, the kernel loose an awful lot of testers. In the span of time before Giri and the VMware team post a patch (-rc1 and -rc4, tipically), my testing activity is just occasional. And I guess a lot of people is in the same situation. These are just my 2cents. I will continue to test new kernels every time I can, and to use native solutions as often as I can (go, ath5k, go!; and LabWindows/CVI for Linux, anyone?). But maybe a bit of tolerance can help everyone... Back in my hole, Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
(Cc: trimmed a bit). On Thu, 2007-11-15 at 11:19 -0500, Daniel Barkalow wrote: > On Thu, 15 Nov 2007, Theodore Tso wrote: [...] > > A full kernel build with everything selected can take good 30 minutes or > > more, and that's on a fast dual-core machine with 4gigs of memory and > > 7200rpm disk drives. On a slower, memory limited laptop, doing a single > > kernel build can take more time than the user has patiences; multiply > > that by 7 or 8 build and test boots, and it starts to get tiresome. > > None of this is going to take as long, Well, the compile phase can. Especially if the first time you try to compile the kernel with EXTRAVERSION=`git describe` which force almost a full rebuild every time... But the worst problem is that a full recompile, with a distro .config, will take hours on my 2.66GHz/CoreDuo/1G ram. Trimming down .config is fundamental to be able to bisect effectively, but it's not an easy thing to do for an unexperienced user (and a painful one for all the rest of us). What would be an invaluable help would be a tool that generates a .config with all the modules and subsystems I am using *now*. Should be possible in principle by parsing KConfig and Makefiles and using as input the current .config and lsmod... is it possible to map the kernel object name to the option enabling it? Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
(Cc: trimmed a bit). On Thu, 2007-11-15 at 11:19 -0500, Daniel Barkalow wrote: On Thu, 15 Nov 2007, Theodore Tso wrote: [...] A full kernel build with everything selected can take good 30 minutes or more, and that's on a fast dual-core machine with 4gigs of memory and 7200rpm disk drives. On a slower, memory limited laptop, doing a single kernel build can take more time than the user has patiences; multiply that by 7 or 8 build and test boots, and it starts to get tiresome. None of this is going to take as long, Well, the compile phase can. Especially if the first time you try to compile the kernel with EXTRAVERSION=`git describe` which force almost a full rebuild every time... But the worst problem is that a full recompile, with a distro .config, will take hours on my 2.66GHz/CoreDuo/1G ram. Trimming down .config is fundamental to be able to bisect effectively, but it's not an easy thing to do for an unexperienced user (and a painful one for all the rest of us). What would be an invaluable help would be a tool that generates a .config with all the modules and subsystems I am using *now*. Should be possible in principle by parsing KConfig and Makefiles and using as input the current .config and lsmod... is it possible to map the kernel object name to the option enabling it? Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
I jump in this discussion hoping to have some more insight on git and to report my experience as a tester. I consider myself as half-literate in this (I am here since 1991, more or less, and I am able to compile a kernel and even hand-apply a patch, although I am in no way a kernel programmer). On Tue, 2007-11-13 at 18:01 +0100, Adrian Bunk wrote: > The small instruction below is enough for everyone who is able to > build his own kernel to do a git bisect. > # start bisecting: > cd linux-2.6 > git bisect start > git bisect bad v2.6.21 > git bisect good v2.6.20 > cp /path/to/.config . > This was what I did in my (in the end almost successful) bisecting when trying to find the mmc problem (see the thread named "2.6.24-rc1 eat my SD card"). This is true in theory, but it has some problem. The "this commit does not compile is the easiest and in man git-bisect it's explained how to solve it. The changes in .config options, added or removed, are another problem when jumping back and forth from version (I was bitten by the gadzillions new options added to hda-intel alsa driver, but well, that is solvable with a bit of attention). The main problem I had, and that stopped me to arrive to a definite is this situation: j version-bad i h g unrelated (but similar) bug corrected f e d unrelated (but similar) bug introduced c b a version-good (d was the series to change drivers to use sg helpers, and g was a "fix fallout from sg helpers" patch). Now I have a series of kernels (d, e, f) that did not work at all and so I cannot mark them good or bad. With the number of patches added in the free-for-all week, this is a very probable scenario. There is a way out from this using bisect? Romano PS as a suggestion, I think that added a "Reported-by", or "Tested-by", or "Debugged-by" attribution in the repository, as happened to be in the MMC case, is a nice an d welcomed reward for the effort. -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] New Kernel Bugs
I jump in this discussion hoping to have some more insight on git and to report my experience as a tester. I consider myself as half-literate in this (I am here since 1991, more or less, and I am able to compile a kernel and even hand-apply a patch, although I am in no way a kernel programmer). On Tue, 2007-11-13 at 18:01 +0100, Adrian Bunk wrote: The small instruction below is enough for everyone who is able to build his own kernel to do a git bisect. # start bisecting: cd linux-2.6 git bisect start git bisect bad v2.6.21 git bisect good v2.6.20 cp /path/to/.config . This was what I did in my (in the end almost successful) bisecting when trying to find the mmc problem (see the thread named 2.6.24-rc1 eat my SD card). This is true in theory, but it has some problem. The this commit does not compile is the easiest and in man git-bisect it's explained how to solve it. The changes in .config options, added or removed, are another problem when jumping back and forth from version (I was bitten by the gadzillions new options added to hda-intel alsa driver, but well, that is solvable with a bit of attention). The main problem I had, and that stopped me to arrive to a definite is this situation: j version-bad i h g unrelated (but similar) bug corrected f e d unrelated (but similar) bug introduced c b a version-good (d was the series to change drivers to use sg helpers, and g was a fix fallout from sg helpers patch). Now I have a series of kernels (d, e, f) that did not work at all and so I cannot mark them good or bad. With the number of patches added in the free-for-all week, this is a very probable scenario. There is a way out from this using bisect? Romano PS as a suggestion, I think that added a Reported-by, or Tested-by, or Debugged-by attribution in the repository, as happened to be in the MMC case, is a nice an d welcomed reward for the effort. -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 (esthetic?) regression: auto select interrupt spams my logs
On Thu, 2007-11-08 at 14:52 +0300, Alexey Starikovskiy wrote: > Please open new bug entry at bugzilla.kernel.org. > Your .config might be usefull. Done, http://bugzilla.kernel.org/show_bug.cgi?id=9327 Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc2 (esthetic?) regression: auto select interrupt spams my logs
Hi, After the ACPI changes between 2.6.24-rc1 and -rc2 I have my logs "spammed" (every 2-3 seconds) by: [ 423.112903] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. [ 423.113020] ACPI: EC: non-query interrupt received, switching to interrupt mode [ 426.078972] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. [ 426.079645] ACPI: EC: non-query interrupt received, switching to interrupt mode [ 426.622773] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. [ 426.622889] ACPI: EC: non-query interrupt received, switching to interrupt mode It seems that no harm is done, apart (but it could be another thing) that gnome-panel is much slower on startup. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: *SPAM* Re: 2.6.34-rc1 eat my photo SD card :-(
On Wed, 2007-11-07 at 15:37 -0800, Roland Dreier wrote:
> .
>
> Pierre, assuming Romano tests this patch successfully, please apply!
>
Hi, the patch below solves the problem with my SD card.
Tested-by: Romano Giannetti <[EMAIL PROTECTED]>
Thanks!
Romano
> <-- patch below -->
>
> mmc: Fix sg helper copy-and-paste error
>
> Commit 45711f1a ("[SG] Update drivers to use sg helpers") had the
> following bogus change in drivers/mmc/card/queue.c:
>
> > - src_buf = page_address(src->page) + src->offset;
> > + src_buf = sg_virt(dst);
>
> (Notice that "src" is converted to "dst"). Turn this "dst" back into
> the intended "src".
>
> Cc: Jens Axboe <[EMAIL PROTECTED]>
> Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
> index 9203a0b..1b9c9b6 100644
> --- a/drivers/mmc/card/queue.c
> +++ b/drivers/mmc/card/queue.c
> @@ -310,7 +310,7 @@ static void copy_sg(struct scatterlist *dst, unsigned int
> dst_len,
> }
>
> if (src_size == 0) {
> - src_buf = sg_virt(dst);
> + src_buf = sg_virt(src);
> src_size = src->length;
> }
>
--
Sorry for the disclaimer --- ¡I cannot stop it!
--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso
del destinatario indicado en la misma. Si Ud. no es el destinatario indicado,
le informamos que cualquier forma de distribución, reproducción o uso de esta
comunicación y/o de la información contenida en la misma están estrictamente
prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por
favor, notifíquelo inmediatamente al remitente contestando a este mensaje y
proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive
use of the intended addressee. If you are not the intended addressee, please
note that any form of distribution, copying or use of this communication or the
information in it is strictly prohibited by law. If you have received this
communication in error, please immediately notify the sender by reply e-mail
and destroy this message. Thank you for your cooperation.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: *SPAM* Re: 2.6.34-rc1 eat my photo SD card :-(
On Wed, 2007-11-07 at 15:37 -0800, Roland Dreier wrote:
.
Pierre, assuming Romano tests this patch successfully, please apply!
Hi, the patch below solves the problem with my SD card.
Tested-by: Romano Giannetti [EMAIL PROTECTED]
Thanks!
Romano
-- patch below --
mmc: Fix sg helper copy-and-paste error
Commit 45711f1a ([SG] Update drivers to use sg helpers) had the
following bogus change in drivers/mmc/card/queue.c:
- src_buf = page_address(src-page) + src-offset;
+ src_buf = sg_virt(dst);
(Notice that src is converted to dst). Turn this dst back into
the intended src.
Cc: Jens Axboe [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
---
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 9203a0b..1b9c9b6 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -310,7 +310,7 @@ static void copy_sg(struct scatterlist *dst, unsigned int
dst_len,
}
if (src_size == 0) {
- src_buf = sg_virt(dst);
+ src_buf = sg_virt(src);
src_size = src-length;
}
--
Sorry for the disclaimer --- ¡I cannot stop it!
--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso
del destinatario indicado en la misma. Si Ud. no es el destinatario indicado,
le informamos que cualquier forma de distribución, reproducción o uso de esta
comunicación y/o de la información contenida en la misma están estrictamente
prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por
favor, notifíquelo inmediatamente al remitente contestando a este mensaje y
proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive
use of the intended addressee. If you are not the intended addressee, please
note that any form of distribution, copying or use of this communication or the
information in it is strictly prohibited by law. If you have received this
communication in error, please immediately notify the sender by reply e-mail
and destroy this message. Thank you for your cooperation.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2 (esthetic?) regression: auto select interrupt spams my logs
On Thu, 2007-11-08 at 14:52 +0300, Alexey Starikovskiy wrote: Please open new bug entry at bugzilla.kernel.org. Your .config might be usefull. Done, http://bugzilla.kernel.org/show_bug.cgi?id=9327 Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc2 (esthetic?) regression: auto select interrupt spams my logs
Hi, After the ACPI changes between 2.6.24-rc1 and -rc2 I have my logs spammed (every 2-3 seconds) by: [ 423.112903] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. [ 423.113020] ACPI: EC: non-query interrupt received, switching to interrupt mode [ 426.078972] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. [ 426.079645] ACPI: EC: non-query interrupt received, switching to interrupt mode [ 426.622773] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. [ 426.622889] ACPI: EC: non-query interrupt received, switching to interrupt mode It seems that no harm is done, apart (but it could be another thing) that gnome-panel is much slower on startup. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Tue, 2007-11-06 at 23:17 +0100, Romano Giannetti wrote: > Well, I started bisecting it. It will be a long shot, I suspect... Well, I spent the last 36 hours (more or less) trying to bisect the SD problem. The method I used was to insert the card, umount it, and make 8 dd in a row; the kernel is "bad" if they differs, "good" if they are the same. I could not finish the bisect. The last pair good/bad were: bad: [7aeacf982203fb4dea2f3434eefdc268cfd5d6d9] [BLOCK] blk_rq_map_sg: force clear termination bit good: [e38f981758118d829cd40cfe9c09e3fa81e422aa] exportfs: update documentation The problem to conclude the bisect is that there is a whole series of commits, named [SG] something, that seems to matter; but my three try of a commit between the previous two ended with a MMC layer not working with this oops: [ 81.738991] BUG: unable to handle kernel NULL pointer dereference at virtual address [ 81.739003] printing eip: c01db437 *pde = [ 81.739010] Oops: [#1] SMP [ 81.739016] Modules linked in: mmc_block binfmt_misc rfcomm l2cap bluetooth ppdev i915 drm acpi_cpufreq cpufreq_conservative cpufreq_stats cpufreq_ondemand freq_table cpufreq_userspace cpufreq_powersave dock container sbs sbshc af_packet nls_iso8859_1 nls_cp437 vfat fat nls_utf8 ntfs dm_crypt dm_mod sbp2 parport_pc lp parport fuse snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss iTCO_wdt iTCO_vendor_support serio_raw sdhci snd_seq_midi snd_rawmidi snd_seq_midi_event psmouse pcspkr mmc_core snd_seq snd_timer snd_seq_device snd soundcore video output battery snd_page_alloc ac button intel_agp agpgart evdev ext3 jbd mbcache sg sr_mod cdrom sd_mod ata_piix ehci_hcd ata_generic ohci1394 uhci_hcd ieee1394 libata scsi_mod generic usbcore r8169 thermal processor fan [ 81.739122] [ 81.739127] Pid: 6075, comm: mmcqd Not tainted (2.6.23-bisect #19) [ 81.739132] EIP: 0060:[] EFLAGS: 00010246 CPU: 0 [ 81.739141] EIP is at blk_rq_map_sg+0xd7/0x190 [ 81.739145] EAX: 03619000 EBX: ECX: c3464198 EDX: c3464698 [ 81.739150] ESI: 0361a000 EDI: 1000 EBP: cb82fe24 ESP: cb82fdec [ 81.739154] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [ 81.739159] Process mmcqd (pid: 6075, ti=cb82e000 task=cb2a5550 task.ti=cb82e000) [ 81.739163] Stack: 0292 c366c530 cb839a70 2000 0361b000 c3464698 0001 0001 [ 81.739176] c34e0848 01ae4698 c33ef2b0 c33ef2b0 cb2ec870 cb82fe3c f8e81e6c [ 81.739188]00200200 c3342580 c33ef2b0 cb2ec870 cb82ffb8 f8e816f9 7898775f 5f6f5965 [ 81.739200] Call Trace: [ 81.739204] [] show_trace_log_lvl+0x1a/0x30 [ 81.739213] [] show_stack_log_lvl+0xb1/0xe0 [ 81.739220] [] show_registers+0xc1/0x1d0 [ 81.739226] [] die+0x11a/0x230 [ 81.739232] [] do_page_fault+0x269/0x5f0 [ 81.739239] [] error_code+0x72/0x78 [ 81.739247] [] mmc_queue_map_sg+0x2c/0xe0 [mmc_block] [ 81.739258] [] mmc_blk_issue_rq+0x199/0x750 [mmc_block] [ 81.739267] [] mmc_queue_thread+0x80/0xf0 [mmc_block] [ 81.739275] [] kthread+0x42/0x70 [ 81.739282] [] kernel_thread_helper+0x7/0x10 [ 81.739289] === [ 81.739292] Code: f0 89 45 d8 8b 01 2b 05 80 aa 67 c0 c1 f8 02 69 c0 c5 4e ec c4 c1 e0 0c 03 41 08 39 45 d8 0f 84 8e 00 00 00 f6 03 02 74 52 31 db <8b> 03 c7 43 0c 00 00 00 00 c7 43 08 00 00 00 00 83 e0 03 0b 01 [ 81.739358] EIP: [] blk_rq_map_sg+0xd7/0x190 SS:ESP 0068:cb82fdec It seems to me that the two commits: [BLOCK] blk_rq_map_sg: force clear termination bit [BLOCK] Don't clear sg_dma_len/addr() in blk_rq_map_sg() have the potential to fix the aforementioned oops, but in a way that create for the mmc layer the problem reported. It's just gut feeling, I have not the knowledge of the kernel needed to debug this, but this comment: +* If the driver previously mapped a shorter +* list, we could see a termination bit +* prematurely unless it fully inits the sg +* table on each mapping. We KNOW that there +* must be more entries here or the driver +* would be buggy, so force clear the +* termination bit to avoid doing a full +* sg_init_table() in drivers for each command. +*/ rang a bell. When the bug occurs, it seems that some random page is mapped into the device, so that... maybe the list was not supposed to continue in this case? Well, I hope it can helps someone to find the bug. I am available to test/try whatever patches you send me. Romano Complete git bisect log: git-bisect start # bad: [2655e2cee2d77459fcb7e10228259e4ee0328697] ata_piix: Add additional PCI identifier for 40 wire short cable git-bisect bad 2655e2cee2d77459fcb7e10228259e4ee0328697 # good: [bbf25010f1a6b761914430f5fca081ec8c7accd1] Linux 2.6.23 git-bisect good bbf25010f1a6b761914430f5fca081ec8c7accd1 # good: [f4921aff5b174349bc36551f142a5dbac782ea3f] Merge git://git.li
Re: 2.6.34-rc1 eat my photo SD card :-(
On Tue, 2007-11-06 at 23:17 +0100, Romano Giannetti wrote: Well, I started bisecting it. It will be a long shot, I suspect... Well, I spent the last 36 hours (more or less) trying to bisect the SD problem. The method I used was to insert the card, umount it, and make 8 dd in a row; the kernel is bad if they differs, good if they are the same. I could not finish the bisect. The last pair good/bad were: bad: [7aeacf982203fb4dea2f3434eefdc268cfd5d6d9] [BLOCK] blk_rq_map_sg: force clear termination bit good: [e38f981758118d829cd40cfe9c09e3fa81e422aa] exportfs: update documentation The problem to conclude the bisect is that there is a whole series of commits, named [SG] something, that seems to matter; but my three try of a commit between the previous two ended with a MMC layer not working with this oops: [ 81.738991] BUG: unable to handle kernel NULL pointer dereference at virtual address [ 81.739003] printing eip: c01db437 *pde = [ 81.739010] Oops: [#1] SMP [ 81.739016] Modules linked in: mmc_block binfmt_misc rfcomm l2cap bluetooth ppdev i915 drm acpi_cpufreq cpufreq_conservative cpufreq_stats cpufreq_ondemand freq_table cpufreq_userspace cpufreq_powersave dock container sbs sbshc af_packet nls_iso8859_1 nls_cp437 vfat fat nls_utf8 ntfs dm_crypt dm_mod sbp2 parport_pc lp parport fuse snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss iTCO_wdt iTCO_vendor_support serio_raw sdhci snd_seq_midi snd_rawmidi snd_seq_midi_event psmouse pcspkr mmc_core snd_seq snd_timer snd_seq_device snd soundcore video output battery snd_page_alloc ac button intel_agp agpgart evdev ext3 jbd mbcache sg sr_mod cdrom sd_mod ata_piix ehci_hcd ata_generic ohci1394 uhci_hcd ieee1394 libata scsi_mod generic usbcore r8169 thermal processor fan [ 81.739122] [ 81.739127] Pid: 6075, comm: mmcqd Not tainted (2.6.23-bisect #19) [ 81.739132] EIP: 0060:[c01db437] EFLAGS: 00010246 CPU: 0 [ 81.739141] EIP is at blk_rq_map_sg+0xd7/0x190 [ 81.739145] EAX: 03619000 EBX: ECX: c3464198 EDX: c3464698 [ 81.739150] ESI: 0361a000 EDI: 1000 EBP: cb82fe24 ESP: cb82fdec [ 81.739154] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [ 81.739159] Process mmcqd (pid: 6075, ti=cb82e000 task=cb2a5550 task.ti=cb82e000) [ 81.739163] Stack: 0292 c366c530 cb839a70 2000 0361b000 c3464698 0001 0001 [ 81.739176] c34e0848 01ae4698 c33ef2b0 c33ef2b0 cb2ec870 cb82fe3c f8e81e6c [ 81.739188]00200200 c3342580 c33ef2b0 cb2ec870 cb82ffb8 f8e816f9 7898775f 5f6f5965 [ 81.739200] Call Trace: [ 81.739204] [c01052fa] show_trace_log_lvl+0x1a/0x30 [ 81.739213] [c01053c1] show_stack_log_lvl+0xb1/0xe0 [ 81.739220] [c01054b1] show_registers+0xc1/0x1d0 [ 81.739226] [c01056da] die+0x11a/0x230 [ 81.739232] [c011d7e9] do_page_fault+0x269/0x5f0 [ 81.739239] [c02f3eea] error_code+0x72/0x78 [ 81.739247] [f8e81e6c] mmc_queue_map_sg+0x2c/0xe0 [mmc_block] [ 81.739258] [f8e816f9] mmc_blk_issue_rq+0x199/0x750 [mmc_block] [ 81.739267] [f8e821a0] mmc_queue_thread+0x80/0xf0 [mmc_block] [ 81.739275] [c013d862] kthread+0x42/0x70 [ 81.739282] [c0104ee7] kernel_thread_helper+0x7/0x10 [ 81.739289] === [ 81.739292] Code: f0 89 45 d8 8b 01 2b 05 80 aa 67 c0 c1 f8 02 69 c0 c5 4e ec c4 c1 e0 0c 03 41 08 39 45 d8 0f 84 8e 00 00 00 f6 03 02 74 52 31 db 8b 03 c7 43 0c 00 00 00 00 c7 43 08 00 00 00 00 83 e0 03 0b 01 [ 81.739358] EIP: [c01db437] blk_rq_map_sg+0xd7/0x190 SS:ESP 0068:cb82fdec It seems to me that the two commits: [BLOCK] blk_rq_map_sg: force clear termination bit [BLOCK] Don't clear sg_dma_len/addr() in blk_rq_map_sg() have the potential to fix the aforementioned oops, but in a way that create for the mmc layer the problem reported. It's just gut feeling, I have not the knowledge of the kernel needed to debug this, but this comment: +* If the driver previously mapped a shorter +* list, we could see a termination bit +* prematurely unless it fully inits the sg +* table on each mapping. We KNOW that there +* must be more entries here or the driver +* would be buggy, so force clear the +* termination bit to avoid doing a full +* sg_init_table() in drivers for each command. +*/ rang a bell. When the bug occurs, it seems that some random page is mapped into the device, so that... maybe the list was not supposed to continue in this case? Well, I hope it can helps someone to find the bug. I am available to test/try whatever patches you send me. Romano Complete git bisect log: git-bisect start # bad: [2655e2cee2d77459fcb7e10228259e4ee0328697] ata_piix: Add additional PCI identifier for 40 wire short cable git-bisect bad 2655e2cee2d77459fcb7e10228259e4ee0328697 # good: [bbf25010f1a6b761914430f5fca081ec8c7accd1] Linux 2.6.23 git-bisect good bbf25010f1a6b761914430f5fca081ec8c7accd1
missing IBF_1 confirmations?
Hi, latest git (v2.6.24-rc1-748-g2655e2c) spams my logs with a message like: SYS: Nov 6 23:55:21 rukbat kernel: [ 1479.474976] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. SYS: Nov 6 23:55:21 rukbat kernel: [ 1479.475838] ACPI: EC: non-query interrupt received, switching to interrupt mode every now and then. (0)rukbat:~% dmesg | grep IBF_1 | wc -l 178 Is it dangerous? I didn't happen with a 2.6.24-rc1. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Tue, 2007-11-06 at 22:48 +0100, Romano Giannetti wrote: > I do really suspect a software bug. > Well, I started bisecting it. It will be a long shot, I suspect... Romano BTW: I noticed that if I change EXTRAVERSION, doing a make rebuild almost all the kernel. Is it normal? And it seems to me that the same thing happens if a make oldconfig results in a changed .config... -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Tue, 2007-11-06 at 20:51 +0100, Willy Tarreau wrote: > On Tue, Nov 06, 2007 at 10:58:41AM +0100, Romano Giannetti wrote: > (first time) > > 000 31e4 c363 d908 cb2e > > (fourth time) > > 000 71e4 c36f d908 cb2e > > (fifth time) > > 000 f1e4 c37b d908 cb2e > > Most always, you have only a few bits which change, and always for > the same bytes : > > 31 -> 71 -> f1 (|40, |80) > 63 -> 6f -> 7b (|0c, |10&~4) Yes, but the second, third and sixth it was: 000 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b * which seems to me something poisoned... and the error in the filesystem was a 0x turned 0x. I do really suspect a software bug. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Tue, 2007-11-06 at 20:51 +0100, Willy Tarreau wrote: > It looks like a hardware problem to me. Maybe one version is more > optimized and puts more stress on the device ? I remember having > had comparable problems in the past with a CF connected to a > home-made IDE adapter on which the +5V wire had been cut. The CF > drained its power from the IDE signals and it would most always > work correctly, except when reading large files. Writing to it > finally killed it. > Obviously I cannot be sure, but I tested it a lot under 2.6.23 and Vista and never had a single problem. If it's an HW problem, for sure Linux 2.6.24 has the capacity to trigger it at the first try... Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
(Nick re-added to the Cc: list; sorry, I dropped you without noticing) On Tue, 2007-11-06 at 10:58 +0100, Romano Giannetti wrote: > Hi, > > I have some more data. I really start to think that the mmc layer is > busted. I repeated a dd of the device, unmounted, five or six times in a > row, and look: [ dd if=/dev/mmcblk0 bs=1c count=128 | od -h output differs from time to time ] > I really do not think this is normal. I will try to reboot to 2.6.23 > and to see what's happening... > Tried it. The card is corrupted now, the vfat filesystem panics and a directory is changed into a file; but the dd results are everytime the same... the vfat error is: SYS: Nov 6 11:04:10 rukbat hald: mounted /dev/mmcblk0p1 on behalf of uid 1153 SYS: Nov 6 11:04:10 rukbat kernel: [ 126.597563] FAT: Filesystem panic (dev mmcblk0p1) SYS: Nov 6 11:04:10 rukbat kernel: [ 126.597572] fat_get_cluster: invalid cluster chain (i_pos 0) SYS: Nov 6 11:04:10 rukbat kernel: [ 126.597577] File system has been set read-only SYS: Nov 6 11:04:11 rukbat kernel: [ 127.705440] FAT: Filesystem panic (dev mmcblk0p1) SYS: Nov 6 11:04:11 rukbat kernel: [ 127.705448] fat_get_cluster: invalid cluster chain (i_pos 0) The first difference between the good and bad data is here: --- good.txt2007-11-06 11:20:59.0 +0100 +++ bad.txt 2007-11-06 11:20:49.0 +0100 @@ -48,7 +48,7 @@ 0141720 6120 796e 6b20 7965 7720 6568 206e 6572 0141740 6461 0d79 000a 4f49 2020 2020 2020 5953 0141760 4d53 4453 534f 2020 5320 5359 aa55 -0142000 fff8 0005 0006 0007 0008 +0142000 fff8 0005 0006 0007 0008 0142020 0009 000a 000b 000c 000d 000e 000f 0010 0142040 0011 0012 0013 0014 0015 0016 0017 0018 0142060 0019 001a 001b 001c 001d 001e 001f 0020 @@ -64,7 +64,7 @@ 0142320 0069 006a 006b 0142340 * -0201000 fff8 0005 0006 0007 0008 +0201000 fff8 0005 0006 0007 0008 0201020 0009 000a 000b 000c 000d 000e 000f 0010 0201040 0011 0012 0013 0014 0015 0016 0017 0018 0201060 0019 001a 001b 001c 001d 001e 001f 0020 Well... what now? Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
Hi, I have some more data. I really start to think that the mmc layer is busted. I repeated a dd of the device, unmounted, five or six times in a row, and look: (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0112835 seconds, 11.3 kB/s 000 31e4 c363 d908 cb2e 020 9550 c217 2a10 c012 0100 0010 0200 0020 040 25a8 cb45 af00 cb2a 9550 c217 060 2a10 c012 0100 0010 0200 0020 02e0 cb45 100 6db8 cb2d 9550 c217 2a10 c012 120 0100 0010 0200 0020 ed00 cb4a 70b0 cba5 140 9550 c217 2a10 c012 0100 0010 160 0200 0020 3058 cb7e 7730 cb28 200 (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% uname -a Linux rukbat 2.6.24-rc1 #7 SMP Sun Oct 28 23:51:49 CET 2007 i686 GNU/Linux (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 000 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0114972 seconds, 11.1 kB/s * 200 (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0112756 seconds, 11.4 kB/s 000 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b * 200 (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 000 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b * 200 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0121104 seconds, 10.6 kB/s (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0112943 seconds, 11.3 kB/s 000 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b * 200 (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0112721 seconds, 11.4 kB/s 000 71e4 c36f d908 cb2e 020 9550 c217 2a10 c012 0100 0010 0200 0020 040 25a8 cb45 af00 cb2a 9550 c217 060 2a10 c012 0100 0010 0200 0020 02e0 cb45 100 6db8 cb2d 9550 c217 2a10 c012 120 0100 0010 0200 0020 ed00 cb4a 70b0 cba5 140 9550 c217 2a10 c012 0100 0010 160 0200 0020 3058 cb7e 7730 cb28 200 (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0112219 seconds, 11.4 kB/s 000 f1e4 c37b d908 cb2e 020 9550 c217 2a10 c012 0100 0010 0200 0020 040 25a8 cb45 af00 cb2a 9550 c217 060 2a10 c012 0100 0010 0200 0020 02e0 cb45 100 6db8 cb2d 9550 c217 2a10 c012 120 0100 0010 0200 0020 ed00 cb4a 70b0 cba5 140 9550 c217 2a10 c012 0100 0010 160 0200 0020 3058 cb7e 7730 cb28 200 (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.011198 seconds, 11.4 kB/s 000 3038 3030 3030 000a 020 * 200 I really do not think this is normal. I will try to reboot to 2.6.23 and to see what's happening... I saw in the changelog that there were changes w/ respect to DMA; maybe these changes are the most probable culprit. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
Hi, I have some more data. I really start to think that the mmc layer is busted. I repeated a dd of the device, unmounted, five or six times in a row, and look: (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0112835 seconds, 11.3 kB/s 000 31e4 c363 d908 cb2e 020 9550 c217 2a10 c012 0100 0010 0200 0020 040 25a8 cb45 af00 cb2a 9550 c217 060 2a10 c012 0100 0010 0200 0020 02e0 cb45 100 6db8 cb2d 9550 c217 2a10 c012 120 0100 0010 0200 0020 ed00 cb4a 70b0 cba5 140 9550 c217 2a10 c012 0100 0010 160 0200 0020 3058 cb7e 7730 cb28 200 (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% uname -a Linux rukbat 2.6.24-rc1 #7 SMP Sun Oct 28 23:51:49 CET 2007 i686 GNU/Linux (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 000 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0114972 seconds, 11.1 kB/s * 200 (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0112756 seconds, 11.4 kB/s 000 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b * 200 (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 000 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b * 200 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0121104 seconds, 10.6 kB/s (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0112943 seconds, 11.3 kB/s 000 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b * 200 (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0112721 seconds, 11.4 kB/s 000 71e4 c36f d908 cb2e 020 9550 c217 2a10 c012 0100 0010 0200 0020 040 25a8 cb45 af00 cb2a 9550 c217 060 2a10 c012 0100 0010 0200 0020 02e0 cb45 100 6db8 cb2d 9550 c217 2a10 c012 120 0100 0010 0200 0020 ed00 cb4a 70b0 cba5 140 9550 c217 2a10 c012 0100 0010 160 0200 0020 3058 cb7e 7730 cb28 200 (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.0112219 seconds, 11.4 kB/s 000 f1e4 c37b d908 cb2e 020 9550 c217 2a10 c012 0100 0010 0200 0020 040 25a8 cb45 af00 cb2a 9550 c217 060 2a10 c012 0100 0010 0200 0020 02e0 cb45 100 6db8 cb2d 9550 c217 2a10 c012 120 0100 0010 0200 0020 ed00 cb4a 70b0 cba5 140 9550 c217 2a10 c012 0100 0010 160 0200 0020 3058 cb7e 7730 cb28 200 (0)rukbat:~/software/toshiba/lk2624-rc1-mmc2% sudo dd if=/dev/mmcblk0 bs=1c count=128 | od -h 128+0 records in 128+0 records out 128 bytes (128 B) copied, 0.011198 seconds, 11.4 kB/s 000 3038 3030 3030 000a 020 * 200 I really do not think this is normal. I will try to reboot to 2.6.23 and to see what's happening... I saw in the changelog that there were changes w/ respect to DMA; maybe these changes are the most probable culprit. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
(Nick re-added to the Cc: list; sorry, I dropped you without noticing) On Tue, 2007-11-06 at 10:58 +0100, Romano Giannetti wrote: Hi, I have some more data. I really start to think that the mmc layer is busted. I repeated a dd of the device, unmounted, five or six times in a row, and look: [ dd if=/dev/mmcblk0 bs=1c count=128 | od -h output differs from time to time ] I really do not think this is normal. I will try to reboot to 2.6.23 and to see what's happening... Tried it. The card is corrupted now, the vfat filesystem panics and a directory is changed into a file; but the dd results are everytime the same... the vfat error is: SYS: Nov 6 11:04:10 rukbat hald: mounted /dev/mmcblk0p1 on behalf of uid 1153 SYS: Nov 6 11:04:10 rukbat kernel: [ 126.597563] FAT: Filesystem panic (dev mmcblk0p1) SYS: Nov 6 11:04:10 rukbat kernel: [ 126.597572] fat_get_cluster: invalid cluster chain (i_pos 0) SYS: Nov 6 11:04:10 rukbat kernel: [ 126.597577] File system has been set read-only SYS: Nov 6 11:04:11 rukbat kernel: [ 127.705440] FAT: Filesystem panic (dev mmcblk0p1) SYS: Nov 6 11:04:11 rukbat kernel: [ 127.705448] fat_get_cluster: invalid cluster chain (i_pos 0) The first difference between the good and bad data is here: --- good.txt2007-11-06 11:20:59.0 +0100 +++ bad.txt 2007-11-06 11:20:49.0 +0100 @@ -48,7 +48,7 @@ 0141720 6120 796e 6b20 7965 7720 6568 206e 6572 0141740 6461 0d79 000a 4f49 2020 2020 2020 5953 0141760 4d53 4453 534f 2020 5320 5359 aa55 -0142000 fff8 0005 0006 0007 0008 +0142000 fff8 0005 0006 0007 0008 0142020 0009 000a 000b 000c 000d 000e 000f 0010 0142040 0011 0012 0013 0014 0015 0016 0017 0018 0142060 0019 001a 001b 001c 001d 001e 001f 0020 @@ -64,7 +64,7 @@ 0142320 0069 006a 006b 0142340 * -0201000 fff8 0005 0006 0007 0008 +0201000 fff8 0005 0006 0007 0008 0201020 0009 000a 000b 000c 000d 000e 000f 0010 0201040 0011 0012 0013 0014 0015 0016 0017 0018 0201060 0019 001a 001b 001c 001d 001e 001f 0020 Well... what now? Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Tue, 2007-11-06 at 20:51 +0100, Willy Tarreau wrote: On Tue, Nov 06, 2007 at 10:58:41AM +0100, Romano Giannetti wrote: (first time) 000 31e4 c363 d908 cb2e (fourth time) 000 71e4 c36f d908 cb2e (fifth time) 000 f1e4 c37b d908 cb2e Most always, you have only a few bits which change, and always for the same bytes : 31 - 71 - f1 (|40, |80) 63 - 6f - 7b (|0c, |10~4) Yes, but the second, third and sixth it was: 000 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b 6b6b * which seems to me something poisoned... and the error in the filesystem was a 0x turned 0x. I do really suspect a software bug. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Tue, 2007-11-06 at 22:48 +0100, Romano Giannetti wrote: I do really suspect a software bug. Well, I started bisecting it. It will be a long shot, I suspect... Romano BTW: I noticed that if I change EXTRAVERSION, doing a make rebuild almost all the kernel. Is it normal? And it seems to me that the same thing happens if a make oldconfig results in a changed .config... -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Tue, 2007-11-06 at 20:51 +0100, Willy Tarreau wrote: It looks like a hardware problem to me. Maybe one version is more optimized and puts more stress on the device ? I remember having had comparable problems in the past with a CF connected to a home-made IDE adapter on which the +5V wire had been cut. The CF drained its power from the IDE signals and it would most always work correctly, except when reading large files. Writing to it finally killed it. Obviously I cannot be sure, but I tested it a lot under 2.6.23 and Vista and never had a single problem. If it's an HW problem, for sure Linux 2.6.24 has the capacity to trigger it at the first try... Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
missing IBF_1 confirmations?
Hi, latest git (v2.6.24-rc1-748-g2655e2c) spams my logs with a message like: SYS: Nov 6 23:55:21 rukbat kernel: [ 1479.474976] ACPI: EC: missing IBF_1 confirmations,switch off interrupt mode. SYS: Nov 6 23:55:21 rukbat kernel: [ 1479.475838] ACPI: EC: non-query interrupt received, switching to interrupt mode every now and then. (0)rukbat:~% dmesg | grep IBF_1 | wc -l 178 Is it dangerous? I didn't happen with a 2.6.24-rc1. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Mon, 2007-11-05 at 16:26 +0100, Pierre Ossman wrote: > On Mon, 05 Nov 2007 14:46:33 +0100 > Romano Giannetti <[EMAIL PROTECTED]> wrote: > > > > > On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote: > > > Did you partition and format this card in the camera or in Linux? > > > > In the camera. It happened both with a Kodak and a Panasonic Lumix. > > > > Does it work if you partition and format it in Linux? Well. Now I am quite surprised. I did the following... obtained an image of the same chip, formatted by the camera, both under 2.6.23 and 2.6.24-rc1 [1], after umounting the volume, and: (130)pern:~/software/toshiba/lk2624-rc1-mmc2% od -h image_camera_23.img | head 000 befa 7c00 00bf b97a 0100 0efc 0e1f f307 020 eaa5 7a16 bebb 337b 80c9 803f 0675 040 c5fe f38b 07eb 3f80 7500 fe02 83c1 10c3 060 fb81 7bfe e572 f983 7404 810b 03f9 7401 100 bb0a 7aa5 2ceb 87bb eb7a 8b27 024c 148b 120 01b8 bb02 7c00 13cd 0573 bcbb eb7a 2e13 140 fea1 3d7d aa55 0574 bcbb eb7a ea05 7c00 160 8a2e 3c07 7400 530c 07bb b400 cd0e 200 5b10 eb43 ebed 00fe 220 (0)pern:~/software/toshiba/lk2624-rc1-mmc2% od -h image_camera_24.img | head 000 7000 010a 004a 2303 0eb8 0015 002a 020 7000 010d 1fdd 2303 0ebc 0015 0008 040 7000 011c 002d 2303 0ef4 8e15 0007 060 7000 011f 1d47 2303 0f80 1315 0045 100 7000 013a 1fed 2303 0f80 4015 0028 120 7000 013b 004a 2303 0f84 d815 001d 140 7000 013c 004a 2303 0f88 7015 003f 160 7000 0141 20c0 2303 0f8c 1415 0029 200 7000 0143 004a 2303 0f90 6315 220 7000 014f 004a 2303 0f94 7115 002d Uf. So I reformatted (under 2.6.23) the partition p1, and now the card works both under 2.6.23 and 2.6.24 (although now it's not detected as a photo card, but I suppose that's normal). But again... (0)pern:~/software/toshiba/lk2624-rc1-mmc2% od -h image_linux_23.img | head 000 befa 7c00 00bf b97a 0100 0efc 0e1f f307 020 eaa5 7a16 bebb 337b 80c9 803f 0675 040 c5fe f38b 07eb 3f80 7500 fe02 83c1 10c3 060 fb81 7bfe e572 f983 7404 810b 03f9 7401 100 bb0a 7aa5 2ceb 87bb eb7a 8b27 024c 148b 120 01b8 bb02 7c00 13cd 0573 bcbb eb7a 2e13 140 fea1 3d7d aa55 0574 bcbb eb7a ea05 7c00 160 8a2e 3c07 7400 530c 07bb b400 cd0e 200 5b10 eb43 ebed 00fe 220 (0)pern:~/software/toshiba/lk2624-rc1-mmc2% od -h image_linux_24.img | head 000 dd65 6ffc dffd ebf3 382d 0040 fbbe 020 472b e3d7 5acb 7fd9 ef5f 7fd7 040 b7ed aff9 af67 594e ffbb 0100 7a7f 060 546a 03d5 0800 6fd5 f9ef 1f3e ffdf 100 85bd 8c8d 617d c01b cd88 1901 1f5e 09b0 120 06c9 f7e3 0c6d d827 a376 0b6d 1b5c 7f42 140 8df0 3918 4a53 9923 5305 6f5f 2101 4043 160 f052 9dc9 8005 102e faf1 0e0e 377d 8b8f 200 bb19 dacf 3d7f 6ffb f0ff 0040 cdb3 220 cd4b b346 4000 e9f7 ee6d eade 4000 e6ff Shouldn't they be equal? I have no camera handy now, I will try again. If it's of some interested, I've put the images on line on http://www.dea.icai.upcomillas.es/romano/linux/info/lk2624-rc1-mmc2/ I tried to loop mount them, but I forgot how can I mount a partition of a loop device... I have loop0 but not loop0p1... there where a "seek" magic but I cannot find it now. Romano [1] dd if=/dev/mmcblk0 of=file bs=1M count=128 -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote: > On Mon, 05 Nov 2007 11:51:26 +0100 > Romano Giannetti <[EMAIL PROTECTED]> wrote: Ah, I forgot: I have a dump of the card (made with dd). If you'd happen to need it, simply tell me. dd gave no errors. And to double check, I mounted a VFAT USB stick on the same PC, and there are no VFAT errors. So it seems an interaction VFAT-mmc... Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote: > On Mon, 05 Nov 2007 11:51:26 +0100 > > > > Ok, now this is a bit more telling. The filesystem is indeed corrupt > somehow as it references sectors wy outside the device (at roughly > 280 MB). Yes. The problem is, when I firstly mounted it on 2.6.23 it worked perfectly. If you think it's worthwhile, I can try to reboot in 2.6.23 and try to mount it again. > Did you partition and format this card in the camera or in Linux? In the camera. It happened both with a Kodak and a Panasonic Lumix. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Sun, 2007-11-04 at 08:11 -0800, Roland Dreier wrote: > I had something similar recently, trying to access an SD card in the > internal drive of my thinkpad X60. Fortunately, the data wasn't > actually corrupted, but when I tried to copy the picture files off the > card, I saw garbage filenames in the picture directory, [...] > When I put the same card back in the camera and used the camera's dock > to access the data via USB mass storage, everything worked fine. So > it does seem to be at least somewhat MMC-related. It is reproducible for me, too, with the 128Mbyte card. Full logs are here: http://www.dea.icai.upcomillas.es/romano/linux/info/lk2624-rc1-mmc2/ a rapid grep shows at boot: Nov 5 08:45:40 rukbat kernel: [ 26.538165] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray Nov 5 08:45:40 rukbat kernel: [ 38.456554] PM: Adding info for No Bus:mmc0 Nov 5 08:45:40 rukbat kernel: [ 38.456634] mmc0: SDHCI at 0xd0100800 irq 16 DMA and when loading the card: Nov 5 09:21:14 rukbat kernel: [ 1632.002723] mmc0: new SD card at address e32f Nov 5 09:21:14 rukbat kernel: [ 1632.002947] PM: Adding info for mmc:mmc0:e32f Nov 5 09:21:14 rukbat kernel: [ 1632.024011] mmcblk0: mmc0:e32f SD128 123008KiB Nov 5 09:21:14 rukbat kernel: [ 1632.025327] mmcblk0: p1 Nov 5 09:21:15 rukbat hald: mounted /dev/mmcblk0p1 on behalf of uid 1153 (I've trimmed away the spam by NetworkManager). and opening the folder in Nautilus: Nov 5 09:21:43 rukbat kernel: [ 1654.235333] FAT: Filesystem panic (dev mmcblk0p1) Nov 5 09:21:43 rukbat kernel: [ 1654.235893] FAT: Filesystem panic (dev mmcblk0p1) Nov 5 09:21:43 rukbat kernel: [ 1654.235915] mmcblk0p1: rw=0, want=575135, limit=245919 ...ad libitum. and it's definitely a regression, the card is read under 2.6.23. I've not a lot of time in my hands now, but maybe the next weekend I can try a bisection... Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Sun, 2007-11-04 at 08:11 -0800, Roland Dreier wrote: I had something similar recently, trying to access an SD card in the internal drive of my thinkpad X60. Fortunately, the data wasn't actually corrupted, but when I tried to copy the picture files off the card, I saw garbage filenames in the picture directory, [...] When I put the same card back in the camera and used the camera's dock to access the data via USB mass storage, everything worked fine. So it does seem to be at least somewhat MMC-related. It is reproducible for me, too, with the 128Mbyte card. Full logs are here: http://www.dea.icai.upcomillas.es/romano/linux/info/lk2624-rc1-mmc2/ a rapid grep shows at boot: Nov 5 08:45:40 rukbat kernel: [ 26.538165] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray Nov 5 08:45:40 rukbat kernel: [ 38.456554] PM: Adding info for No Bus:mmc0 Nov 5 08:45:40 rukbat kernel: [ 38.456634] mmc0: SDHCI at 0xd0100800 irq 16 DMA and when loading the card: Nov 5 09:21:14 rukbat kernel: [ 1632.002723] mmc0: new SD card at address e32f Nov 5 09:21:14 rukbat kernel: [ 1632.002947] PM: Adding info for mmc:mmc0:e32f Nov 5 09:21:14 rukbat kernel: [ 1632.024011] mmcblk0: mmc0:e32f SD128 123008KiB Nov 5 09:21:14 rukbat kernel: [ 1632.025327] mmcblk0: p1 Nov 5 09:21:15 rukbat hald: mounted /dev/mmcblk0p1 on behalf of uid 1153 (I've trimmed away the spam by NetworkManager). and opening the folder in Nautilus: Nov 5 09:21:43 rukbat kernel: [ 1654.235333] FAT: Filesystem panic (dev mmcblk0p1) Nov 5 09:21:43 rukbat kernel: [ 1654.235893] FAT: Filesystem panic (dev mmcblk0p1) Nov 5 09:21:43 rukbat kernel: [ 1654.235915] mmcblk0p1: rw=0, want=575135, limit=245919 ...ad libitum. and it's definitely a regression, the card is read under 2.6.23. I've not a lot of time in my hands now, but maybe the next weekend I can try a bisection... Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote: On Mon, 05 Nov 2007 11:51:26 +0100 Ok, now this is a bit more telling. The filesystem is indeed corrupt somehow as it references sectors wy outside the device (at roughly 280 MB). Yes. The problem is, when I firstly mounted it on 2.6.23 it worked perfectly. If you think it's worthwhile, I can try to reboot in 2.6.23 and try to mount it again. Did you partition and format this card in the camera or in Linux? In the camera. It happened both with a Kodak and a Panasonic Lumix. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote: On Mon, 05 Nov 2007 11:51:26 +0100 Romano Giannetti [EMAIL PROTECTED] wrote: Ah, I forgot: I have a dump of the card (made with dd). If you'd happen to need it, simply tell me. dd gave no errors. And to double check, I mounted a VFAT USB stick on the same PC, and there are no VFAT errors. So it seems an interaction VFAT-mmc... Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Mon, 2007-11-05 at 16:26 +0100, Pierre Ossman wrote: On Mon, 05 Nov 2007 14:46:33 +0100 Romano Giannetti [EMAIL PROTECTED] wrote: On Mon, 2007-11-05 at 13:22 +0100, Pierre Ossman wrote: Did you partition and format this card in the camera or in Linux? In the camera. It happened both with a Kodak and a Panasonic Lumix. Does it work if you partition and format it in Linux? Well. Now I am quite surprised. I did the following... obtained an image of the same chip, formatted by the camera, both under 2.6.23 and 2.6.24-rc1 [1], after umounting the volume, and: (130)pern:~/software/toshiba/lk2624-rc1-mmc2% od -h image_camera_23.img | head 000 befa 7c00 00bf b97a 0100 0efc 0e1f f307 020 eaa5 7a16 bebb 337b 80c9 803f 0675 040 c5fe f38b 07eb 3f80 7500 fe02 83c1 10c3 060 fb81 7bfe e572 f983 7404 810b 03f9 7401 100 bb0a 7aa5 2ceb 87bb eb7a 8b27 024c 148b 120 01b8 bb02 7c00 13cd 0573 bcbb eb7a 2e13 140 fea1 3d7d aa55 0574 bcbb eb7a ea05 7c00 160 8a2e 3c07 7400 530c 07bb b400 cd0e 200 5b10 eb43 ebed 00fe 220 (0)pern:~/software/toshiba/lk2624-rc1-mmc2% od -h image_camera_24.img | head 000 7000 010a 004a 2303 0eb8 0015 002a 020 7000 010d 1fdd 2303 0ebc 0015 0008 040 7000 011c 002d 2303 0ef4 8e15 0007 060 7000 011f 1d47 2303 0f80 1315 0045 100 7000 013a 1fed 2303 0f80 4015 0028 120 7000 013b 004a 2303 0f84 d815 001d 140 7000 013c 004a 2303 0f88 7015 003f 160 7000 0141 20c0 2303 0f8c 1415 0029 200 7000 0143 004a 2303 0f90 6315 220 7000 014f 004a 2303 0f94 7115 002d Uf. So I reformatted (under 2.6.23) the partition p1, and now the card works both under 2.6.23 and 2.6.24 (although now it's not detected as a photo card, but I suppose that's normal). But again... (0)pern:~/software/toshiba/lk2624-rc1-mmc2% od -h image_linux_23.img | head 000 befa 7c00 00bf b97a 0100 0efc 0e1f f307 020 eaa5 7a16 bebb 337b 80c9 803f 0675 040 c5fe f38b 07eb 3f80 7500 fe02 83c1 10c3 060 fb81 7bfe e572 f983 7404 810b 03f9 7401 100 bb0a 7aa5 2ceb 87bb eb7a 8b27 024c 148b 120 01b8 bb02 7c00 13cd 0573 bcbb eb7a 2e13 140 fea1 3d7d aa55 0574 bcbb eb7a ea05 7c00 160 8a2e 3c07 7400 530c 07bb b400 cd0e 200 5b10 eb43 ebed 00fe 220 (0)pern:~/software/toshiba/lk2624-rc1-mmc2% od -h image_linux_24.img | head 000 dd65 6ffc dffd ebf3 382d 0040 fbbe 020 472b e3d7 5acb 7fd9 ef5f 7fd7 040 b7ed aff9 af67 594e ffbb 0100 7a7f 060 546a 03d5 0800 6fd5 f9ef 1f3e ffdf 100 85bd 8c8d 617d c01b cd88 1901 1f5e 09b0 120 06c9 f7e3 0c6d d827 a376 0b6d 1b5c 7f42 140 8df0 3918 4a53 9923 5305 6f5f 2101 4043 160 f052 9dc9 8005 102e faf1 0e0e 377d 8b8f 200 bb19 dacf 3d7f 6ffb f0ff 0040 cdb3 220 cd4b b346 4000 e9f7 ee6d eade 4000 e6ff Shouldn't they be equal? I have no camera handy now, I will try again. If it's of some interested, I've put the images on line on http://www.dea.icai.upcomillas.es/romano/linux/info/lk2624-rc1-mmc2/ I tried to loop mount them, but I forgot how can I mount a partition of a loop device... I have loop0 but not loop0p1... there where a seek magic but I cannot find it now. Romano [1] dd if=/dev/mmcblk0 of=file bs=1M count=128 -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: *SPAM* Re: 2.6.24-rc1: OOPS at acpi_battery_update
On Fri, 2007-11-02 at 17:08 +0100, Rafael J. Wysocki wrote: > On Friday, 2 November 2007 00:14, Andrew Morton wrote: > > On Mon, 29 Oct 2007 11:11:04 +0100 [OOPS removed] > > > > Did any earlier kernels do this? In other words, do you believe that this > > is a bug which we added after 2.6.23 was released? Never noticed it before. But it's happening just sometime (I've had it just two times), so I cannot be sure. > This might be the same as http://bugzilla.kernel.org/show_bug.cgi?id=9283 Hmmm... there is too little info for my level in that bug report to understand if it's the same. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Fri, 2007-11-02 at 18:28 +0100, Pierre Ossman wrote: > On Thu, 01 Nov 2007 12:56:42 +0100 > Romano Giannetti <[EMAIL PROTECTED]> wrote: > > Data loss is never fun. I hope you didn't have anything important on the card. > Well. A cousin-in-law marriage, would have been best not to lose it, but I'll survive. > > I have a flight waiting now, so I have put all the dmesgs and syslogs > > over there: > > > > http://www.dea.icai.upcomillas.es/romano/linux/info/2624-rc1-mmc/ > > Hmmm... the Uni server is down today. Darn. > I'm afraid the logs are of little help. They are just filled with > noise from the file system. You also seem to prove the FAT code to > give an invalid pointer (the oops in the first dmesg). > Ok, I suspected it. > Can you reproduce this? To help you I need to see the errors given by > the MMC layer. You should also try reproducing it without a tainted > kernel (i.e. don't load ndiswrapper). I have a spare 128M card I can use to try. The one that failed was a 2G one. I will try to reproduce without tainting the kernel (unfortunately, the Atheros chip I have is not supported by ath5k yet, and the choice is between ndiswrapper or Vista.). Should I enable some debugging option for the MMC layer? > Rgds -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.34-rc1 eat my photo SD card :-(
On Fri, 2007-11-02 at 18:28 +0100, Pierre Ossman wrote: On Thu, 01 Nov 2007 12:56:42 +0100 Romano Giannetti [EMAIL PROTECTED] wrote: Data loss is never fun. I hope you didn't have anything important on the card. Well. A cousin-in-law marriage, would have been best not to lose it, but I'll survive. I have a flight waiting now, so I have put all the dmesgs and syslogs over there: http://www.dea.icai.upcomillas.es/romano/linux/info/2624-rc1-mmc/ Hmmm... the Uni server is down today. Darn. I'm afraid the logs are of little help. They are just filled with noise from the file system. You also seem to prove the FAT code to give an invalid pointer (the oops in the first dmesg). Ok, I suspected it. Can you reproduce this? To help you I need to see the errors given by the MMC layer. You should also try reproducing it without a tainted kernel (i.e. don't load ndiswrapper). I have a spare 128M card I can use to try. The one that failed was a 2G one. I will try to reproduce without tainting the kernel (unfortunately, the Atheros chip I have is not supported by ath5k yet, and the choice is between ndiswrapper or Vista.). Should I enable some debugging option for the MMC layer? Rgds -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: *SPAM* Re: 2.6.24-rc1: OOPS at acpi_battery_update
On Fri, 2007-11-02 at 17:08 +0100, Rafael J. Wysocki wrote: On Friday, 2 November 2007 00:14, Andrew Morton wrote: On Mon, 29 Oct 2007 11:11:04 +0100 [OOPS removed] Did any earlier kernels do this? In other words, do you believe that this is a bug which we added after 2.6.23 was released? Never noticed it before. But it's happening just sometime (I've had it just two times), so I cannot be sure. This might be the same as http://bugzilla.kernel.org/show_bug.cgi?id=9283 Hmmm... there is too little info for my level in that bug report to understand if it's the same. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.34-rc1 eat my photo SD card :-(
Hi, I have a very possible regression to signal. This morning 2.6.24-rc1 eat and destroyed my SD card. I have a toshiba laptop with a card slot and I have used it with 2.6.23-rcX and 2.6.23 without problems so far. This morning I put the card in, nothing happened, removed it. When I put it in again the filesystem in it was completely scr***ed up. I have a flight waiting now, so I have put all the dmesgs and syslogs over there: http://www.dea.icai.upcomillas.es/romano/linux/info/2624-rc1-mmc/ Sunday I'll be back to help debug it. Thank you very much Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.34-rc1 eat my photo SD card :-(
Hi, I have a very possible regression to signal. This morning 2.6.24-rc1 eat and destroyed my SD card. I have a toshiba laptop with a card slot and I have used it with 2.6.23-rcX and 2.6.23 without problems so far. This morning I put the card in, nothing happened, removed it. When I put it in again the filesystem in it was completely scr***ed up. I have a flight waiting now, so I have put all the dmesgs and syslogs over there: http://www.dea.icai.upcomillas.es/romano/linux/info/2624-rc1-mmc/ Sunday I'll be back to help debug it. Thank you very much Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc1: OOPS at acpi_battery_update
Hi, sometime on resuming from s2ram my laptop spew the following oops. Config, dmesg etc are at: http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_6/ [3.475386] Oops: [#1] SMP [3.475602] Process kacpi_notify (pid: 50, ti=c2122000 task=c210c030 task.ti=c2122000) [3.475608] Stack: c35c5060 c02f2a58 0046 6b6b6b6b c2b20298 c2123efc c02f29ac [3.475626]c02166cb f896f3ca f896ff63 0246 c2b20298 a512 [3.475644]c2123f04 c02f2a58 c2123f34 f896f3ed c2123f1c c34fbdb8 c2123f20 c02f3e22 [3.475662] Call Trace: [3.475667] [show_trace_log_lvl+26/48] show_trace_log_lvl+0x1a/0x30 [3.475678] [show_stack_log_lvl+177/224] show_stack_log_lvl+0xb1/0xe0 [3.475695] [die+282/560] die+0x11a/0x230 [3.475687] [show_registers+193/464] show_registers+0xc1/0x1d0 [3.475703] [do_page_fault+415/1648] do_page_fault+0x19f/0x670 [3.475713] [error_code+114/120] error_code+0x72/0x78 [3.475722] [__mutex_unlock_slowpath+172/336] __mutex_unlock_slowpath+0xac/0x150 [3.475731] [mutex_unlock+8/16] mutex_unlock+0x8/0x10 [3.475739] [] acpi_battery_update+0x1ce/0x23c [battery] [3.475753] [] acpi_battery_notify+0x21/0x78 [battery] [3.475764] [acpi_ev_notify_dispatch+79/90] acpi_ev_notify_dispatch+0x4f/0x5a [3.475792] [worker_thread+157/256] worker_thread+0x9d/0x100 [3.475774] [acpi_os_execute_notify+36/47] acpi_os_execute_notify+0x24/0x2f [3.475784] [run_workqueue+288/464] run_workqueue+0x120/0x1d0 [3.475809] [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10 [3.475801] [kthread+66/112] kthread+0x42/0x70 [3.475821] Code: 8d b4 26 00 00 00 00 55 89 e5 83 ec 18 89 5d f8 89 c3 89 75 fc 0f b6 40 04 89 d6 84 c0 7f 24 8d 43 20 3b 43 20 0f 84 e4 00 00 00 <3b> 76 10 0f 85 93 00 00 00 3b 36 90 74 47 8b 5d f8 8b 75 fc 89 [3.475818] === [3.475909] EIP: [debug_mutex_wake_waiter+36/352] debug_mutex_wake_waiter+0x24/0x160 SS:ESP 0068:c2123ebc -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] r8169: don't call napi_disable if not doing NAPI
On Fri, 2007-10-26 at 11:33 -0700, Stephen Hemminger wrote: > Don't call napi_disable if not configured. > And make sure that any misuse of napi_xxx in future fails > with a compile error. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> > This fix the problem for me (at least, after 8 suspend/resume cycles). Thanks. Tested-by: Romano Giannetti <[EMAIL PROTECTED]> -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] r8169: don't call napi_disable if not doing NAPI
On Fri, 2007-10-26 at 11:33 -0700, Stephen Hemminger wrote: Don't call napi_disable if not configured. And make sure that any misuse of napi_xxx in future fails with a compile error. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] This fix the problem for me (at least, after 8 suspend/resume cycles). Thanks. Tested-by: Romano Giannetti [EMAIL PROTECTED] -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc1: OOPS at acpi_battery_update
Hi, sometime on resuming from s2ram my laptop spew the following oops. Config, dmesg etc are at: http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_6/ [3.475386] Oops: [#1] SMP [3.475602] Process kacpi_notify (pid: 50, ti=c2122000 task=c210c030 task.ti=c2122000) [3.475608] Stack: c35c5060 c02f2a58 0046 6b6b6b6b c2b20298 c2123efc c02f29ac [3.475626]c02166cb f896f3ca f896ff63 0246 c2b20298 a512 [3.475644]c2123f04 c02f2a58 c2123f34 f896f3ed c2123f1c c34fbdb8 c2123f20 c02f3e22 [3.475662] Call Trace: [3.475667] [show_trace_log_lvl+26/48] show_trace_log_lvl+0x1a/0x30 [3.475678] [show_stack_log_lvl+177/224] show_stack_log_lvl+0xb1/0xe0 [3.475695] [die+282/560] die+0x11a/0x230 [3.475687] [show_registers+193/464] show_registers+0xc1/0x1d0 [3.475703] [do_page_fault+415/1648] do_page_fault+0x19f/0x670 [3.475713] [error_code+114/120] error_code+0x72/0x78 [3.475722] [__mutex_unlock_slowpath+172/336] __mutex_unlock_slowpath+0xac/0x150 [3.475731] [mutex_unlock+8/16] mutex_unlock+0x8/0x10 [3.475739] [f896f3ed] acpi_battery_update+0x1ce/0x23c [battery] [3.475753] [f896f927] acpi_battery_notify+0x21/0x78 [battery] [3.475764] [acpi_ev_notify_dispatch+79/90] acpi_ev_notify_dispatch+0x4f/0x5a [3.475792] [worker_thread+157/256] worker_thread+0x9d/0x100 [3.475774] [acpi_os_execute_notify+36/47] acpi_os_execute_notify+0x24/0x2f [3.475784] [run_workqueue+288/464] run_workqueue+0x120/0x1d0 [3.475809] [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10 [3.475801] [kthread+66/112] kthread+0x42/0x70 [3.475821] Code: 8d b4 26 00 00 00 00 55 89 e5 83 ec 18 89 5d f8 89 c3 89 75 fc 0f b6 40 04 89 d6 84 c0 7f 24 8d 43 20 3b 43 20 0f 84 e4 00 00 00 3b 76 10 0f 85 93 00 00 00 3b 36 90 74 47 8b 5d f8 8b 75 fc 89 [3.475818] === [3.475909] EIP: [debug_mutex_wake_waiter+36/352] debug_mutex_wake_waiter+0x24/0x160 SS:ESP 0068:c2123ebc -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] r8169: don't call napi_disable if not doing NAPI
On Fri, 2007-10-26 at 11:33 -0700, Stephen Hemminger wrote: > Don't call napi_disable if not configured. > And make sure that any misuse of napi_xxx in future fails > with a compile error. Will test as soon as possible (been without internet in the week end). Thanks. As a bonus, I tried more thing, and I had a signal form lockdep. You can find it here: http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_5/ patching and compiling now. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] r8169: don't call napi_disable if not doing NAPI
On Fri, 2007-10-26 at 11:33 -0700, Stephen Hemminger wrote: Don't call napi_disable if not configured. And make sure that any misuse of napi_xxx in future fails with a compile error. Will test as soon as possible (been without internet in the week end). Thanks. As a bonus, I tried more thing, and I had a signal form lockdep. You can find it here: http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_5/ patching and compiling now. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1 fails with lockup and BUG:
On Wed, 2007-10-24 at 12:44 -0400, Joseph Fannin wrote: > On Wed, Oct 24, 2007 at 03:25:44PM +0200, Romano Giannetti wrote: > > > > > Denis V. Lunev wrote a patch for the NetworkManager thing a day or two > ago (which DaveM has queued). > > Since netlink is involved in the traces you sent, this might do something > for the other too. This *do* fix the "network manager needs to be restarted at boot" part of the problem, but leave as is the worst one (the failed suspend to ram and following bugs). Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1 fails with lockup and BUG:
On Wed, 2007-10-24 at 12:44 -0400, Joseph Fannin wrote: On Wed, Oct 24, 2007 at 03:25:44PM +0200, Romano Giannetti wrote: Denis V. Lunev wrote a patch for the NetworkManager thing a day or two ago (which DaveM has queued). Since netlink is involved in the traces you sent, this might do something for the other too. This *do* fix the network manager needs to be restarted at boot part of the problem, but leave as is the worst one (the failed suspend to ram and following bugs). Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1 fails with lockup and BUG:
On Wed, 2007-10-24 at 18:11 +0200, Peter Zijlstra wrote: > On Wed, 2007-10-24 at 17:55 +0200, Ingo Molnar wrote: > > > > hm, this lockdep warning caused lockdep to turn itself off - hence we > > wont get to the really interesting warnings. We'll try to come up with a > > solution for this. > > Does this help? I tried this, but although I have the D-state processes, I cannot see any debug trace now. Results are at: http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_3/ Can I try anything more? This is quite a show-stopper for me... and before trying to bisect 11Mbyte of patches... Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1 fails with lockup and BUG:
On Wed, 2007-10-24 at 18:11 +0200, Peter Zijlstra wrote: On Wed, 2007-10-24 at 17:55 +0200, Ingo Molnar wrote: hm, this lockdep warning caused lockdep to turn itself off - hence we wont get to the really interesting warnings. We'll try to come up with a solution for this. Does this help? I tried this, but although I have the D-state processes, I cannot see any debug trace now. Results are at: http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_3/ Can I try anything more? This is quite a show-stopper for me... and before trying to bisect 11Mbyte of patches... Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc1 fails with lockup and BUG:
On Wed, 2007-10-24 at 16:27 +0200, Ingo Molnar wrote: > > CONFIG_PROVE_LOCKING=y > CONFIG_DEBUG_LIST=y > CONFIG_FRAME_POINTER=y > CONFIG_DEBUG_SLAB=y > > and please post the resulting dmesg output - does lockdep notice any > lockup reason? (your backtrace suggests some mutex stuff so it might as > well detect it) > Done. The results are at: http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_2/ in the syslog-after-failed-suspend.txt file. After the failed suspend (at line 15766) there where the bunch of things in D-state. I have left the file intact. At line 17646 there is: WARNING: at kernel/lockdep.c:2033 trace_hardirqs_on() I waited a bit and then, on an already-opened root shell, did s2ram -f -p -m (line 17811) and then a lot more things happened, and I am somewhat lost. Hope this could be useful to you. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc1 fails with lockup and BUG:
Hi,
2.6.23-rc1 fails for me. I have the sensation it is network-related, but
I am not sure, so I send this message just to the list.
This same failure was present in git-5734-gd85714d, I sent
a message to the list but it seems it never arrived. I hope this will
pass through. My system is a toshiba satellite A305-S5077, dual core pentium.
The symptoms are quite strange. At boot, NetworkManager fails to activate
my eth0 (r8169). Just stopping/restarting NM will make it works.
Then, after one or two or maximum three suspend to ram and resume that
works, all go awry. Notice that I do not know if the s2ram is the cause, or
simply the way to accelerate the bug.
The suspend-to-ram will fail with a messages:
"gnome-power-manager: (romano) DBUS timed out, but recovering"
and a number of processes go into D state (please find their sysrq-t traces
few lines down). Now I cannot create new windows, nor doing sudo (sudo
anything will go into D limbo), and not even a clean shutdown. Trying that
the system loops forever saying:
BUG: soft lockup - CPU#0 stuck for 11s! [ifconfig: 7481]
and sysrq-b is the only option.
Complete dmesg, config, etc at:
http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_1/
Thanks,
Romano
PS sorry for the disclaimer, I cannot stop it (¡!)
nmbd D ca9cbea4 0 5464 1
c256eaa0 0086 0002 ca9cbea4 ca9cbe9c c256ebdc c17fba80
c250e900 c0426080 c0426080 c22f67d0 c01773a3 0010 c0426080 00013bab
00ff c03bc514 c03bc51c c03bc518
Call Trace:
[cache_alloc_refill+115/1280] cache_alloc_refill+0x73/0x500
[__mutex_lock_slowpath+85/144] __mutex_lock_slowpath+0x55/0x90
[mutex_lock+20/32] mutex_lock+0x14/0x20
[sock_ioctl+0/560] sock_ioctl+0x0/0x230
[dev_ioctl+200/1312] dev_ioctl+0xc8/0x520
[sock_init_data+108/384] sock_init_data+0x6c/0x180
[inet_create+413/832] inet_create+0x19d/0x340
[inotify_d_instantiate+24/128] inotify_d_instantiate+0x18/0x80
[d_alloc+265/400] d_alloc+0x109/0x190
[d_instantiate+59/80] d_instantiate+0x3b/0x50
[udp_ioctl+0/160] udp_ioctl+0x0/0xa0
[inet_ioctl+58/192] inet_ioctl+0x3a/0xc0
[sock_ioctl+207/560] sock_ioctl+0xcf/0x230
[sock_ioctl+0/560] sock_ioctl+0x0/0x230
[do_ioctl+43/144] do_ioctl+0x2b/0x90
[sys_socket+41/80] sys_socket+0x29/0x50
[vfs_ioctl+92/656] vfs_ioctl+0x5c/0x290
[sys_ioctl+61/112] sys_ioctl+0x3d/0x70
[sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
===
x-session-man D c2c49d28 0 5774 5246
c1c4d000 00200082 0002 c2c49d28 c2c49d20 c1c4d13c c1803a80
c2c25c80 c0426080 c0426080 cab12550 c011d3c2 c03a13a0 c0426080 00016269
00ff c03bc514 c03bc51c c03bc518
Call Trace:
[enqueue_task+18/48] enqueue_task+0x12/0x30
[__mutex_lock_slowpath+85/144] __mutex_lock_slowpath+0x55/0x90
[mutex_lock+20/32] mutex_lock+0x14/0x20
[rtnetlink_rcv+8/32] rtnetlink_rcv+0x8/0x20
[netlink_unicast+502/544] netlink_unicast+0x1f6/0x220
[copy_from_user+46/112] copy_from_user+0x2e/0x70
[memcpy_fromiovec+56/80] memcpy_fromiovec+0x38/0x50
[netlink_sendmsg+488/720] netlink_sendmsg+0x1e8/0x2d0
[__wake_up_sync+65/128] __wake_up_sync+0x41/0x80
[sock_sendmsg+206/256] sock_sendmsg+0xce/0x100
[autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
[__wake_up+62/96] __wake_up+0x3e/0x60
[netlink_insert+197/320] netlink_insert+0xc5/0x140
[copy_from_user+46/112] copy_from_user+0x2e/0x70
[sys_sendto+307/384] sys_sendto+0x133/0x180
[move_addr_to_user+95/112] move_addr_to_user+0x5f/0x70
[sys_getsockname+205/208] sys_getsockname+0xcd/0xd0
[__netlink_create+97/176] __netlink_create+0x61/0xb0
[inotify_d_instantiate+24/128] inotify_d_instantiate+0x18/0x80
[d_alloc+265/400] d_alloc+0x109/0x190
[d_instantiate+59/80] d_instantiate+0x3b/0x50
[sock_attach_fd+128/192] sock_attach_fd+0x80/0xc0
[sys_socketcall+408/640] sys_socketcall+0x198/0x280
[sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
[clip_device_event+16/160] clip_device_event+0x10/0xa0
===
ipD cb573d28 0 7487 7486
c1dc7aa0 0082 0002 cb573d28 cb573d20 c1dc7bdc c1803a80
c27ed740 c0426080 c0426080 001280d2 c218eeb0 c218ef54 c0426080 00010bb9
00ff c03bc514 c03bc51c c03bc518
Call Trace:
[__mutex_lock_slowpath+85/144] __mutex_lock_slowpath+0x55/0x90
[mutex_lock+20/32] mutex_lock+0x14/0x20
[rtnetlink_rcv+8/32] rtnetlink_rcv+0x8/0x20
[netlink_unicast+502/544] netlink_unicast+0x1f6/0x220
[copy_from_user+46/112] copy_from_user+0x2e/0x70
[memcpy_fromiovec+56/80] memcpy_fromiovec+0x38/0x50
[netlink_sendmsg+488/720] netlink_sendmsg+0x1e8/0x2d0
[do_lookup+101/400] do_lookup+0x65/0x190
[sock_sendmsg+206/256] sock_sendmsg+0xce/0x100
[] __ext3_journal_dirty_metadata+0x22/0x60 [ext3]
[] journal_get_write_access+0x29/0x40 [jbd]
[autoremove_wake_function+0/80]
2.6.24-rc1 fails with lockup and BUG:
Hi,
2.6.23-rc1 fails for me. I have the sensation it is network-related, but
I am not sure, so I send this message just to the list.
This same failure was present in git-5734-gd85714d, I sent
a message to the list but it seems it never arrived. I hope this will
pass through. My system is a toshiba satellite A305-S5077, dual core pentium.
The symptoms are quite strange. At boot, NetworkManager fails to activate
my eth0 (r8169). Just stopping/restarting NM will make it works.
Then, after one or two or maximum three suspend to ram and resume that
works, all go awry. Notice that I do not know if the s2ram is the cause, or
simply the way to accelerate the bug.
The suspend-to-ram will fail with a messages:
gnome-power-manager: (romano) DBUS timed out, but recovering
and a number of processes go into D state (please find their sysrq-t traces
few lines down). Now I cannot create new windows, nor doing sudo (sudo
anything will go into D limbo), and not even a clean shutdown. Trying that
the system loops forever saying:
BUG: soft lockup - CPU#0 stuck for 11s! [ifconfig: 7481]
and sysrq-b is the only option.
Complete dmesg, config, etc at:
http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_1/
Thanks,
Romano
PS sorry for the disclaimer, I cannot stop it (¡!)
nmbd D ca9cbea4 0 5464 1
c256eaa0 0086 0002 ca9cbea4 ca9cbe9c c256ebdc c17fba80
c250e900 c0426080 c0426080 c22f67d0 c01773a3 0010 c0426080 00013bab
00ff c03bc514 c03bc51c c03bc518
Call Trace:
[cache_alloc_refill+115/1280] cache_alloc_refill+0x73/0x500
[__mutex_lock_slowpath+85/144] __mutex_lock_slowpath+0x55/0x90
[mutex_lock+20/32] mutex_lock+0x14/0x20
[sock_ioctl+0/560] sock_ioctl+0x0/0x230
[dev_ioctl+200/1312] dev_ioctl+0xc8/0x520
[sock_init_data+108/384] sock_init_data+0x6c/0x180
[inet_create+413/832] inet_create+0x19d/0x340
[inotify_d_instantiate+24/128] inotify_d_instantiate+0x18/0x80
[d_alloc+265/400] d_alloc+0x109/0x190
[d_instantiate+59/80] d_instantiate+0x3b/0x50
[udp_ioctl+0/160] udp_ioctl+0x0/0xa0
[inet_ioctl+58/192] inet_ioctl+0x3a/0xc0
[sock_ioctl+207/560] sock_ioctl+0xcf/0x230
[sock_ioctl+0/560] sock_ioctl+0x0/0x230
[do_ioctl+43/144] do_ioctl+0x2b/0x90
[sys_socket+41/80] sys_socket+0x29/0x50
[vfs_ioctl+92/656] vfs_ioctl+0x5c/0x290
[sys_ioctl+61/112] sys_ioctl+0x3d/0x70
[sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
===
x-session-man D c2c49d28 0 5774 5246
c1c4d000 00200082 0002 c2c49d28 c2c49d20 c1c4d13c c1803a80
c2c25c80 c0426080 c0426080 cab12550 c011d3c2 c03a13a0 c0426080 00016269
00ff c03bc514 c03bc51c c03bc518
Call Trace:
[enqueue_task+18/48] enqueue_task+0x12/0x30
[__mutex_lock_slowpath+85/144] __mutex_lock_slowpath+0x55/0x90
[mutex_lock+20/32] mutex_lock+0x14/0x20
[rtnetlink_rcv+8/32] rtnetlink_rcv+0x8/0x20
[netlink_unicast+502/544] netlink_unicast+0x1f6/0x220
[copy_from_user+46/112] copy_from_user+0x2e/0x70
[memcpy_fromiovec+56/80] memcpy_fromiovec+0x38/0x50
[netlink_sendmsg+488/720] netlink_sendmsg+0x1e8/0x2d0
[__wake_up_sync+65/128] __wake_up_sync+0x41/0x80
[sock_sendmsg+206/256] sock_sendmsg+0xce/0x100
[autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50
[__wake_up+62/96] __wake_up+0x3e/0x60
[netlink_insert+197/320] netlink_insert+0xc5/0x140
[copy_from_user+46/112] copy_from_user+0x2e/0x70
[sys_sendto+307/384] sys_sendto+0x133/0x180
[move_addr_to_user+95/112] move_addr_to_user+0x5f/0x70
[sys_getsockname+205/208] sys_getsockname+0xcd/0xd0
[__netlink_create+97/176] __netlink_create+0x61/0xb0
[inotify_d_instantiate+24/128] inotify_d_instantiate+0x18/0x80
[d_alloc+265/400] d_alloc+0x109/0x190
[d_instantiate+59/80] d_instantiate+0x3b/0x50
[sock_attach_fd+128/192] sock_attach_fd+0x80/0xc0
[sys_socketcall+408/640] sys_socketcall+0x198/0x280
[sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
[clip_device_event+16/160] clip_device_event+0x10/0xa0
===
ipD cb573d28 0 7487 7486
c1dc7aa0 0082 0002 cb573d28 cb573d20 c1dc7bdc c1803a80
c27ed740 c0426080 c0426080 001280d2 c218eeb0 c218ef54 c0426080 00010bb9
00ff c03bc514 c03bc51c c03bc518
Call Trace:
[__mutex_lock_slowpath+85/144] __mutex_lock_slowpath+0x55/0x90
[mutex_lock+20/32] mutex_lock+0x14/0x20
[rtnetlink_rcv+8/32] rtnetlink_rcv+0x8/0x20
[netlink_unicast+502/544] netlink_unicast+0x1f6/0x220
[copy_from_user+46/112] copy_from_user+0x2e/0x70
[memcpy_fromiovec+56/80] memcpy_fromiovec+0x38/0x50
[netlink_sendmsg+488/720] netlink_sendmsg+0x1e8/0x2d0
[do_lookup+101/400] do_lookup+0x65/0x190
[sock_sendmsg+206/256] sock_sendmsg+0xce/0x100
[f88fc042] __ext3_journal_dirty_metadata+0x22/0x60 [ext3]
[f88de999] journal_get_write_access+0x29/0x40 [jbd]
Re: 2.6.24-rc1 fails with lockup and BUG:
On Wed, 2007-10-24 at 16:27 +0200, Ingo Molnar wrote: CONFIG_PROVE_LOCKING=y CONFIG_DEBUG_LIST=y CONFIG_FRAME_POINTER=y CONFIG_DEBUG_SLAB=y and please post the resulting dmesg output - does lockdep notice any lockup reason? (your backtrace suggests some mutex stuff so it might as well detect it) Done. The results are at: http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_2/ in the syslog-after-failed-suspend.txt file. After the failed suspend (at line 15766) there where the bunch of things in D-state. I have left the file intact. At line 17646 there is: WARNING: at kernel/lockdep.c:2033 trace_hardirqs_on() I waited a bit and then, on an already-opened root shell, did s2ram -f -p -m (line 17811) and then a lot more things happened, and I am somewhat lost. Hope this could be useful to you. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[REGRESSION] locks with v2.6.23-5734-gd85714d (suspend- or bio- related?)
Hi, I was testing yesterday release of kernel, and I have had a lot of problem with the new kernel. It boots ok, the first time it suspend/resume ok, and then at the second or third attempt to suspend, the suspend process will not go though (I suspend using s2ram -f -p -m); it will just lock the screen (I think that's in Ubuntu scripts) and nothing more. Coming back, there is a message of the style "DBUS locked up, but recovered" (if you need more precise information tell me and I'll do my best). After that, sometime there are processes that go to D state forever... one sure form os triggering it here is to try to do "sudo something". At this point, no new windows opens in gnome; switching to a VT works, and I can start a shutdown, but it locks saying something on the line "soft lockup on CPU#0 detected, 11 seconds stall" forever. I need to d a SysRq-B to restart. I got a track of locked processes with SysRq-T. The common denominator is __mutex_lock_slowpath() here. I do not know if the system fails to suspend given that problem or the other way around. 2.6.23 worked like a charm. The system is a toshiba laptop A305-S5077, sata disk, pretty standard I think. Greetings, Romano First time, one process in D state: [ 52.876178] sudo D 0 6913 6179 [ 52.876182]c29d01f0 0086 c01a42b7 c012105c c29d0324 c17fba00 [ 52.876193]c0433080 c0433080 c0433080 0007a120 0007a120 eec8a6ec [ 52.876204] c03c3c94 c03c3c9c c03c3c98 c29d01f0 c02ed645 c2d3dd3c cab39ec0 [ 52.876215] Call Trace: [ 52.876219] [bio_add_page+55/80] bio_add_page+0x37/0x50 [ 52.876225] [__load_balance_iterator+28/48] __load_balance_iterator+0x1c/0x30 [ 52.876237] [__mutex_lock_slowpath+85/144] __mutex_lock_slowpath+0x55/0x90 [ 52.876245] [mutex_lock+20/32] mutex_lock+0x14/0x20 [ 52.876250] [rtnetlink_rcv+8/32] rtnetlink_rcv+0x8/0x20 [ 52.876257] [netlink_unicast+502/544] netlink_unicast+0x1f6/0x220 [ 52.876262] [copy_from_user+46/112] copy_from_user+0x2e/0x70 [ 52.876269] [memcpy_fromiovec+56/80] memcpy_fromiovec+0x38/0x50 [ 52.876277] [netlink_sendmsg+485/704] netlink_sendmsg+0x1e5/0x2c0 [ 52.876290] [sock_sendmsg+273/304] sock_sendmsg+0x111/0x130 [ 52.876302] [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50 [ 52.876309] [__wait_on_bit_lock+91/112] __wait_on_bit_lock+0x5b/0x70 [ 52.876316] [__lock_page+115/128] __lock_page+0x73/0x80 [ 52.876326] [find_lock_page+47/176] find_lock_page+0x2f/0xb0 [ 52.876334] [filemap_fault+498/1024] filemap_fault+0x1f2/0x400 [ 52.876340] [netlink_insert+206/336] netlink_insert+0xce/0x150 [ 52.876347] [copy_from_user+46/112] copy_from_user+0x2e/0x70 [ 52.876355] [sys_sendto+307/384] sys_sendto+0x133/0x180 [ 52.876362] [__do_fault+534/1008] __do_fault+0x216/0x3f0 [ 52.876375] [handle_mm_fault+280/1824] handle_mm_fault+0x118/0x720 [ 52.876383] [sock_attach_fd+128/192] sock_attach_fd+0x80/0xc0 [ 52.876396] [sys_socketcall+408/640] sys_socketcall+0x198/0x280 [ 52.876407] [sysenter_past_esp+107/161] sysenter_past_esp+0x6b/0xa1 Second time: [ 129.820154] sudo D cae8fd20 0 7562 6096 [ 129.820163]c257f630 0082 0002 cae8fd20 cae8fd18 c257f764 c17fba00 [ 129.820181]c0433080 c0433080 c0433080 000170e3 00ff [ 129.820199] c03c3c94 c03c3c9c c03c3c98 c257f630 c02ed645 c27f9d3c c2e07d3c [ 129.820217] Call Trace: [ 129.820240] [__mutex_lock_slowpath+85/144] __mutex_lock_slowpath+0x55/0x90 [ 129.820258] [mutex_lock+20/32] mutex_lock+0x14/0x20 [ 129.820267] [rtnetlink_rcv+8/32] rtnetlink_rcv+0x8/0x20 [ 129.820278] [netlink_unicast+502/544] netlink_unicast+0x1f6/0x220 [ 129.820290] [copy_from_user+46/112] copy_from_user+0x2e/0x70 [ 129.820302] [memcpy_fromiovec+56/80] memcpy_fromiovec+0x38/0x50 [ 129.820316] [netlink_sendmsg+485/704] netlink_sendmsg+0x1e5/0x2c0 [ 129.820342] [sock_sendmsg+273/304] sock_sendmsg+0x111/0x130 [ 129.820367] [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50 [ 129.820396] [find_lock_page+47/176] find_lock_page+0x2f/0xb0 [ 129.820411] [filemap_fault+498/1024] filemap_fault+0x1f2/0x400 [ 129.820420] [netlink_insert+206/336] netlink_insert+0xce/0x150 [ 129.820434] [copy_from_user+46/112] copy_from_user+0x2e/0x70 [ 129.820450] [sys_sendto+307/384] sys_sendto+0x133/0x180 [ 129.820461] [__do_fault+534/1008] __do_fault+0x216/0x3f0 [ 129.820488] [handle_mm_fault+280/1824] handle_mm_fault+0x118/0x720 [ 129.820502] [sock_attach_fd+128/192] sock_attach_fd+0x80/0xc0 [ 129.820528] [sys_socketcall+408/640] sys_socketcall+0x198/0x280 [ 129.820548] [sysenter_past_esp+107/161] sysenter_past_esp+0x6b/0xa1 [ 129.820574] === [ 205.438026] sudo D cae8fd20 0 7562 6096 [ 205.438032]c257f630 0082 0002 cae8fd20
[REGRESSION] locks with v2.6.23-5734-gd85714d (suspend- or bio- related?)
Hi, I was testing yesterday release of kernel, and I have had a lot of problem with the new kernel. It boots ok, the first time it suspend/resume ok, and then at the second or third attempt to suspend, the suspend process will not go though (I suspend using s2ram -f -p -m); it will just lock the screen (I think that's in Ubuntu scripts) and nothing more. Coming back, there is a message of the style DBUS locked up, but recovered (if you need more precise information tell me and I'll do my best). After that, sometime there are processes that go to D state forever... one sure form os triggering it here is to try to do sudo something. At this point, no new windows opens in gnome; switching to a VT works, and I can start a shutdown, but it locks saying something on the line soft lockup on CPU#0 detected, 11 seconds stall forever. I need to d a SysRq-B to restart. I got a track of locked processes with SysRq-T. The common denominator is __mutex_lock_slowpath() here. I do not know if the system fails to suspend given that problem or the other way around. 2.6.23 worked like a charm. The system is a toshiba laptop A305-S5077, sata disk, pretty standard I think. Greetings, Romano First time, one process in D state: [ 52.876178] sudo D 0 6913 6179 [ 52.876182]c29d01f0 0086 c01a42b7 c012105c c29d0324 c17fba00 [ 52.876193]c0433080 c0433080 c0433080 0007a120 0007a120 eec8a6ec [ 52.876204] c03c3c94 c03c3c9c c03c3c98 c29d01f0 c02ed645 c2d3dd3c cab39ec0 [ 52.876215] Call Trace: [ 52.876219] [bio_add_page+55/80] bio_add_page+0x37/0x50 [ 52.876225] [__load_balance_iterator+28/48] __load_balance_iterator+0x1c/0x30 [ 52.876237] [__mutex_lock_slowpath+85/144] __mutex_lock_slowpath+0x55/0x90 [ 52.876245] [mutex_lock+20/32] mutex_lock+0x14/0x20 [ 52.876250] [rtnetlink_rcv+8/32] rtnetlink_rcv+0x8/0x20 [ 52.876257] [netlink_unicast+502/544] netlink_unicast+0x1f6/0x220 [ 52.876262] [copy_from_user+46/112] copy_from_user+0x2e/0x70 [ 52.876269] [memcpy_fromiovec+56/80] memcpy_fromiovec+0x38/0x50 [ 52.876277] [netlink_sendmsg+485/704] netlink_sendmsg+0x1e5/0x2c0 [ 52.876290] [sock_sendmsg+273/304] sock_sendmsg+0x111/0x130 [ 52.876302] [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50 [ 52.876309] [__wait_on_bit_lock+91/112] __wait_on_bit_lock+0x5b/0x70 [ 52.876316] [__lock_page+115/128] __lock_page+0x73/0x80 [ 52.876326] [find_lock_page+47/176] find_lock_page+0x2f/0xb0 [ 52.876334] [filemap_fault+498/1024] filemap_fault+0x1f2/0x400 [ 52.876340] [netlink_insert+206/336] netlink_insert+0xce/0x150 [ 52.876347] [copy_from_user+46/112] copy_from_user+0x2e/0x70 [ 52.876355] [sys_sendto+307/384] sys_sendto+0x133/0x180 [ 52.876362] [__do_fault+534/1008] __do_fault+0x216/0x3f0 [ 52.876375] [handle_mm_fault+280/1824] handle_mm_fault+0x118/0x720 [ 52.876383] [sock_attach_fd+128/192] sock_attach_fd+0x80/0xc0 [ 52.876396] [sys_socketcall+408/640] sys_socketcall+0x198/0x280 [ 52.876407] [sysenter_past_esp+107/161] sysenter_past_esp+0x6b/0xa1 Second time: [ 129.820154] sudo D cae8fd20 0 7562 6096 [ 129.820163]c257f630 0082 0002 cae8fd20 cae8fd18 c257f764 c17fba00 [ 129.820181]c0433080 c0433080 c0433080 000170e3 00ff [ 129.820199] c03c3c94 c03c3c9c c03c3c98 c257f630 c02ed645 c27f9d3c c2e07d3c [ 129.820217] Call Trace: [ 129.820240] [__mutex_lock_slowpath+85/144] __mutex_lock_slowpath+0x55/0x90 [ 129.820258] [mutex_lock+20/32] mutex_lock+0x14/0x20 [ 129.820267] [rtnetlink_rcv+8/32] rtnetlink_rcv+0x8/0x20 [ 129.820278] [netlink_unicast+502/544] netlink_unicast+0x1f6/0x220 [ 129.820290] [copy_from_user+46/112] copy_from_user+0x2e/0x70 [ 129.820302] [memcpy_fromiovec+56/80] memcpy_fromiovec+0x38/0x50 [ 129.820316] [netlink_sendmsg+485/704] netlink_sendmsg+0x1e5/0x2c0 [ 129.820342] [sock_sendmsg+273/304] sock_sendmsg+0x111/0x130 [ 129.820367] [autoremove_wake_function+0/80] autoremove_wake_function+0x0/0x50 [ 129.820396] [find_lock_page+47/176] find_lock_page+0x2f/0xb0 [ 129.820411] [filemap_fault+498/1024] filemap_fault+0x1f2/0x400 [ 129.820420] [netlink_insert+206/336] netlink_insert+0xce/0x150 [ 129.820434] [copy_from_user+46/112] copy_from_user+0x2e/0x70 [ 129.820450] [sys_sendto+307/384] sys_sendto+0x133/0x180 [ 129.820461] [__do_fault+534/1008] __do_fault+0x216/0x3f0 [ 129.820488] [handle_mm_fault+280/1824] handle_mm_fault+0x118/0x720 [ 129.820502] [sock_attach_fd+128/192] sock_attach_fd+0x80/0xc0 [ 129.820528] [sys_socketcall+408/640] sys_socketcall+0x198/0x280 [ 129.820548] [sysenter_past_esp+107/161] sysenter_past_esp+0x6b/0xa1 [ 129.820574] === [ 205.438026] sudo D cae8fd20 0 7562 6096 [ 205.438032]c257f630 0082 0002 cae8fd20 cae8fd18
Re: 2.6.23-rc6: S4 and S5 no longer listed as supported on ToshibaSatellite A40
On Thu, 2007-09-20 at 18:01 +0200, Maciek Rutecki wrote: > Frans Pop pisze: > >> Unexpected, and potentially pretty serious. Something went wrong with > >> ACPI. Can you try to narrow down when it started happening? > > > > rc1 still had all 4 levels. I'll run a bisect between rc1 and rc6. > > I have the same on HP/Compaq nx6310: > ACPI: (supports S0 S3) > > (kernel 2.6.23-rc6) Linux version 2.6.20-16-generic (ubuntu): ACPI: (supports S0 S3 S4 S5) Linux version 2.6.23-rc2-rg (with a little snd-hda-intel patch) ACPI: (supports S0 S3) So it seems happened between rc1 and rc2 > But suspend to ram/disk works. For me too (with s2ram, not with vanilla echo ram > ...). And the system is otherwise ok. Romano > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc6: S4 and S5 no longer listed as supported on ToshibaSatellite A40
On Thu, 2007-09-20 at 18:01 +0200, Maciek Rutecki wrote: Frans Pop pisze: Unexpected, and potentially pretty serious. Something went wrong with ACPI. Can you try to narrow down when it started happening? rc1 still had all 4 levels. I'll run a bisect between rc1 and rc6. I have the same on HP/Compaq nx6310: ACPI: (supports S0 S3) (kernel 2.6.23-rc6) Linux version 2.6.20-16-generic (ubuntu): ACPI: (supports S0 S3 S4 S5) Linux version 2.6.23-rc2-rg (with a little snd-hda-intel patch) ACPI: (supports S0 S3) So it seems happened between rc1 and rc2 But suspend to ram/disk works. For me too (with s2ram, not with vanilla echo ram ...). And the system is otherwise ok. Romano - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Toshiba A305 hda-intel (Was: Re: easy alsa patches for the stablekernel?)
On Sat, 2007-09-08 at 01:42 +0200, Takashi Iwai wrote: > At Fri, 07 Sep 2007 22:59:07 +0200, > Romano Giannetti wrote: > > > > It's on git.kernel.org, perex/alsa.git tree mm branch. > You can find the information in the download wiki page of > alsa-project.org. > Ah thanks, found. Now, I'd like to know if anybody has any hints over the problem of the offset in the ADC output offset [1] (which is the Mic/Front Mic input offset, that is). I'd like to know if this is a problem of this specific hda-intel chip or if it's a more extended problem, and I am quite willing to help to solve it. It's quite easy to spot with audacity. Booting in Vista (for the third time since I bought the thing) I noticed that there is a "offset compensation" flag in the sound control panel, maybe it's related... [1] https://bugtrack.alsa-project.org/alsa-bug/file_download.php?file_id=2129=bug Romano -- Romano Giannetti --- [EMAIL PROTECTED] Sorry for the following disclaimer, it's attached by our otugoing server and I cannot shut it up. -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Toshiba A305 hda-intel (Was: Re: easy alsa patches for the stablekernel?)
On Sat, 2007-09-08 at 01:42 +0200, Takashi Iwai wrote: At Fri, 07 Sep 2007 22:59:07 +0200, Romano Giannetti wrote: It's on git.kernel.org, perex/alsa.git tree mm branch. You can find the information in the download wiki page of alsa-project.org. Ah thanks, found. Now, I'd like to know if anybody has any hints over the problem of the offset in the ADC output offset [1] (which is the Mic/Front Mic input offset, that is). I'd like to know if this is a problem of this specific hda-intel chip or if it's a more extended problem, and I am quite willing to help to solve it. It's quite easy to spot with audacity. Booting in Vista (for the third time since I bought the thing) I noticed that there is a offset compensation flag in the sound control panel, maybe it's related... [1] https://bugtrack.alsa-project.org/alsa-bug/file_download.php?file_id=2129type=bug Romano -- Romano Giannetti --- [EMAIL PROTECTED] Sorry for the following disclaimer, it's attached by our otugoing server and I cannot shut it up. -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: easy alsa patches for the stable kernel?
On Fri, 2007-09-07 at 21:42 +0200, Thorsten Leemhuis wrote: > On 07.09.2007 14:58, Takashi Iwai wrote: > >>> Ah good. I added it to ALSA HG tree now. Thanks. BTW, is anywhere visible the current hg tree? It seems that http://hg-mirror.alsa-project.org/alsa-kernel/ lags a bit behind... > It's just this line afaics... > + SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA), > ...which afaics is doing nothing more then "if DMI-Data matches FOO then > apply know workaround BAR". Is that correct or am I missing something > here (another patch that this one depends on that isn't in 2.6.23 yet > maybe?)? > Your second guess is right. That line is a patch with respect to current mercurial tree, which is quite ahead of the current kernel alsa code. Although I'd like to know from where Andrew pulled it, because I was not able to find that tree on git.kernel nor alsa-project.org... :-) > Nevertheless let me use to use this moment and say: thx for all your > work Takashi! Seconded. I only hope I will be able to continue to find this patch for the next releases of the 2.6.23 kernel... Romano -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22
Takashi: good news!
On Thu, 2007-09-06 at 23:48 +0200, Romano Giannetti wrote:
> On Thu, 2007-09-06 at 17:25 +0200, Takashi Iwai wrote:
> > At Thu, 06 Sep 2007 17:09:50 +0200,
> > Romano Giannetti wrote:
> > >
> > >
> > > Just one hand up: I haven't tested the patch pointed to by Andrew, will
> > > do asap, but it seems that contains the changes from
> > >
> > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3104
> > >
> > > which are needed to have sound at all on my toshiba (although with some
> > > remaining problems).
> >
> > No, it's a different one. This Toshiba model is still not supported
> > well. The patch in mm tree is basically equivalent with the latest
> > ALSA HG tree, so if you tested ALSA HG version (or daily snapshot),
> > it should be same.
>
> Unfortunately you're right. The patch I posted to the alsa bugtrack,
> extracted from the pshou files, works for me. The alsa-git patch gives
> me a system without sound.
I stand corrected: by loading snd-hda-intel with model=toshiba sound
works (output and input) with my toshiba A305. So, I think that the only
patch needed to make it works out of the box on top of current alsa-git
is:
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 3557865..496d119 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -9044,6 +9044,7 @@ static const char *alc268_models[ALC268_MODEL_LAST] = {
static struct snd_pci_quirk alc268_cfg_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x1205, "ASUS W7J", ALC268_3ST),
SND_PCI_QUIRK(0x1179, 0xff10, "TOSHIBA A205", ALC268_TOSHIBA),
+ SND_PCI_QUIRK(0x1179, 0xff50, "TOSHIBA A305", ALC268_TOSHIBA),
SND_PCI_QUIRK(0x103c, 0x30cc, "TOSHIBA", ALC268_TOSHIBA),
SND_PCI_QUIRK(0x1025, 0x0126, "Acer", ALC268_ACER),
SND_PCI_QUIRK(0x1025, 0x0130, "Acer Extensa 5210", ALC268_ACER),
--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso
del destinatario indicado en la misma. Si Ud. no es el destinatario indicado,
le informamos que cualquier forma de distribución, reproducción o uso de esta
comunicación y/o de la información contenida en la misma están estrictamente
prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por
favor, notifíquelo inmediatamente al remitente contestando a este mensaje y
proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive
use of the intended addressee. If you are not the intended addressee, please
note that any form of distribution, copying or use of this communication or the
information in it is strictly prohibited by law. If you have received this
communication in error, please immediately notify the sender by reply e-mail
and destroy this message. Thank you for your cooperation.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: hda_intel : Patch + Regression in 2.6.18 - 2.6.22
Takashi: good news!
On Thu, 2007-09-06 at 23:48 +0200, Romano Giannetti wrote:
On Thu, 2007-09-06 at 17:25 +0200, Takashi Iwai wrote:
At Thu, 06 Sep 2007 17:09:50 +0200,
Romano Giannetti wrote:
Just one hand up: I haven't tested the patch pointed to by Andrew, will
do asap, but it seems that contains the changes from
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3104
which are needed to have sound at all on my toshiba (although with some
remaining problems).
No, it's a different one. This Toshiba model is still not supported
well. The patch in mm tree is basically equivalent with the latest
ALSA HG tree, so if you tested ALSA HG version (or daily snapshot),
it should be same.
Unfortunately you're right. The patch I posted to the alsa bugtrack,
extracted from the pshou files, works for me. The alsa-git patch gives
me a system without sound.
I stand corrected: by loading snd-hda-intel with model=toshiba sound
works (output and input) with my toshiba A305. So, I think that the only
patch needed to make it works out of the box on top of current alsa-git
is:
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 3557865..496d119 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -9044,6 +9044,7 @@ static const char *alc268_models[ALC268_MODEL_LAST] = {
static struct snd_pci_quirk alc268_cfg_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x1205, ASUS W7J, ALC268_3ST),
SND_PCI_QUIRK(0x1179, 0xff10, TOSHIBA A205, ALC268_TOSHIBA),
+ SND_PCI_QUIRK(0x1179, 0xff50, TOSHIBA A305, ALC268_TOSHIBA),
SND_PCI_QUIRK(0x103c, 0x30cc, TOSHIBA, ALC268_TOSHIBA),
SND_PCI_QUIRK(0x1025, 0x0126, Acer, ALC268_ACER),
SND_PCI_QUIRK(0x1025, 0x0130, Acer Extensa 5210, ALC268_ACER),
--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso
del destinatario indicado en la misma. Si Ud. no es el destinatario indicado,
le informamos que cualquier forma de distribución, reproducción o uso de esta
comunicación y/o de la información contenida en la misma están estrictamente
prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por
favor, notifíquelo inmediatamente al remitente contestando a este mensaje y
proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive
use of the intended addressee. If you are not the intended addressee, please
note that any form of distribution, copying or use of this communication or the
information in it is strictly prohibited by law. If you have received this
communication in error, please immediately notify the sender by reply e-mail
and destroy this message. Thank you for your cooperation.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: easy alsa patches for the stable kernel?
On Fri, 2007-09-07 at 21:42 +0200, Thorsten Leemhuis wrote: On 07.09.2007 14:58, Takashi Iwai wrote: Ah good. I added it to ALSA HG tree now. Thanks. BTW, is anywhere visible the current hg tree? It seems that http://hg-mirror.alsa-project.org/alsa-kernel/ lags a bit behind... It's just this line afaics... + SND_PCI_QUIRK(0x1179, 0xff50, TOSHIBA A305, ALC268_TOSHIBA), ...which afaics is doing nothing more then if DMI-Data matches FOO then apply know workaround BAR. Is that correct or am I missing something here (another patch that this one depends on that isn't in 2.6.23 yet maybe?)? Your second guess is right. That line is a patch with respect to current mercurial tree, which is quite ahead of the current kernel alsa code. Although I'd like to know from where Andrew pulled it, because I was not able to find that tree on git.kernel nor alsa-project.org... :-) Nevertheless let me use to use this moment and say: thx for all your work Takashi! Seconded. I only hope I will be able to continue to find this patch for the next releases of the 2.6.23 kernel... Romano -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22
On Thu, 2007-09-06 at 17:25 +0200, Takashi Iwai wrote: > At Thu, 06 Sep 2007 17:09:50 +0200, > Romano Giannetti wrote: > > > > > > Just one hand up: I haven't tested the patch pointed to by Andrew, will > > do asap, but it seems that contains the changes from > > > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3104 > > > > which are needed to have sound at all on my toshiba (although with some > > remaining problems). > > No, it's a different one. This Toshiba model is still not supported > well. The patch in mm tree is basically equivalent with the latest > ALSA HG tree, so if you tested ALSA HG version (or daily snapshot), > it should be same. Unfortunately you're right. The patch I posted to the alsa bugtrack, extracted from the pshou files, works for me. The alsa-git patch gives me a system without sound. > > I'm still waiting for a patch from pshou for the latest version, but > no reply yet. m here. I can try to "merge" pshou patch with the > alsa-git, but I'm not so confident about my understanding of the > thing... Thanks again Romano -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hda_intel : Patch + Regression in 2.6.18 -> 2.6.22
On Wed, 2007-09-05 at 18:44 +0200, Takashi Iwai wrote: > At Wed, 5 Sep 2007 09:16:33 -0700, > Andrew Morton wrote: > > > > > On Wed, 05 Sep 2007 18:05:44 +0200 Takashi Iwai <[EMAIL PROTECTED]> wrote: > > > Roger, could you try git-alsa patch in the latest mm together with > > > model=acer-aspiore option? If it works, I can easily add your device > > > ID to the table. > > > > http://userweb.kernel.org/~akpm/git-alsa.patch is a copy of the alsa git > > tree as of two minutes ago. That applies against current Linus mainline, > > but should apply OK on 2.6.23-rc5 as well. Please test that, thanks. > > > > Takashi, perhaps that is 2.6.23 material? > > The changes for Acer Aspire is quite big, surely not for 2.6.23. > Let's fix in 2.6.24 in a better way than a temporary hack (that > would work only in a very limited way). Just one hand up: I haven't tested the patch pointed to by Andrew, will do asap, but it seems that contains the changes from https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3104 which are needed to have sound at all on my toshiba (although with some remaining problems). I am not able to say if it's .23 material or not, nor if it's a regression or not, being this a quite new laptop... but maybe it's better to have a release with some sound and then fix it properly after? Thanks for your hard work, Romano -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hda_intel : Patch + Regression in 2.6.18 - 2.6.22
On Wed, 2007-09-05 at 18:44 +0200, Takashi Iwai wrote: At Wed, 5 Sep 2007 09:16:33 -0700, Andrew Morton wrote: On Wed, 05 Sep 2007 18:05:44 +0200 Takashi Iwai [EMAIL PROTECTED] wrote: Roger, could you try git-alsa patch in the latest mm together with model=acer-aspiore option? If it works, I can easily add your device ID to the table. http://userweb.kernel.org/~akpm/git-alsa.patch is a copy of the alsa git tree as of two minutes ago. That applies against current Linus mainline, but should apply OK on 2.6.23-rc5 as well. Please test that, thanks. Takashi, perhaps that is 2.6.23 material? The changes for Acer Aspire is quite big, surely not for 2.6.23. Let's fix in 2.6.24 in a better way than a temporary hack (that would work only in a very limited way). Just one hand up: I haven't tested the patch pointed to by Andrew, will do asap, but it seems that contains the changes from https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3104 which are needed to have sound at all on my toshiba (although with some remaining problems). I am not able to say if it's .23 material or not, nor if it's a regression or not, being this a quite new laptop... but maybe it's better to have a release with some sound and then fix it properly after? Thanks for your hard work, Romano -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hda_intel : Patch + Regression in 2.6.18 - 2.6.22
On Thu, 2007-09-06 at 17:25 +0200, Takashi Iwai wrote: At Thu, 06 Sep 2007 17:09:50 +0200, Romano Giannetti wrote: Just one hand up: I haven't tested the patch pointed to by Andrew, will do asap, but it seems that contains the changes from https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3104 which are needed to have sound at all on my toshiba (although with some remaining problems). No, it's a different one. This Toshiba model is still not supported well. The patch in mm tree is basically equivalent with the latest ALSA HG tree, so if you tested ALSA HG version (or daily snapshot), it should be same. Unfortunately you're right. The patch I posted to the alsa bugtrack, extracted from the pshou files, works for me. The alsa-git patch gives me a system without sound. I'm still waiting for a patch from pshou for the latest version, but no reply yet. m here. I can try to merge pshou patch with the alsa-git, but I'm not so confident about my understanding of the thing... Thanks again Romano -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hang in 2.6.23-rc5
On Mon, 2007-09-03 at 08:39 +0200, Patrick Mau wrote: > In addition I totally agree with Satyam's comment above: either > anybody is testing rc's these days, or people simply stopped reporting. > Hi, I had network-related locks with rc5, but refrained to post here because I am using ndiswrapper... I was waiting to go back home and try to reproduce without it, by connecting the laptop to a wired network. I will try the patch proposed. Thanks, Romano. -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hang in 2.6.23-rc5
On Mon, 2007-09-03 at 08:39 +0200, Patrick Mau wrote: In addition I totally agree with Satyam's comment above: either anybody is testing rc's these days, or people simply stopped reporting. Hi, I had network-related locks with rc5, but refrained to post here because I am using ndiswrapper... I was waiting to go back home and try to reproduce without it, by connecting the laptop to a wired network. I will try the patch proposed. Thanks, Romano. -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Tue, 2007-07-03 at 05:29 +0100, Matthew Garrett wrote: > or alternatively we could do what we do for suspend to RAM on other > platforms (PPC and APM) and just not use the freezer. As a data point, I am running with this patch on top of 2.6.21.2 the last 3+ weeks, with an average of 5/6 STR cycles a day, and had no problems at all. (Sony vaio pcg-fx701). Just normal work, I didn't try to stress the thing, but I have quite a few times suspended/resumed over a big compile without a glitch. What are the risks of this patch supposed to be? Romano -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove process freezer from suspend to RAM pathway
On Tue, 2007-07-03 at 05:29 +0100, Matthew Garrett wrote: or alternatively we could do what we do for suspend to RAM on other platforms (PPC and APM) and just not use the freezer. As a data point, I am running with this patch on top of 2.6.21.2 the last 3+ weeks, with an average of 5/6 STR cycles a day, and had no problems at all. (Sony vaio pcg-fx701). Just normal work, I didn't try to stress the thing, but I have quite a few times suspended/resumed over a big compile without a glitch. What are the risks of this patch supposed to be? Romano -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
On Tue, 2007-05-29 at 07:55 -0700, Linus Torvalds wrote:
>
> On Tue, 29 May 2007, Romano Giannetti wrote:
> >
> > - The good (?) news. I have made 7 suspend/resume cycle (to ram, I
> > haven't tested hibernation) with a 2.6.21.2 with that patch, applied
> > manually. The system did suspend and resume nicely even compiling a
> > kernel and opening openoffice. Normally (le me stress _normally_) no
> > delay was apparent on resume. I do not know how dangerous is this... :-)
> >
> > - The bad (?) news. One time out of 7 I had the 60 seconds delay.
>
> Interesting. If you can re-create it, please do the sysrq-T thing again,
> to see what's up. (Also, you might do "sysrq-p", which gives the current
> process data, which sysrq-T does not).
I've got it, but I had a problem: I filled the dmesg buffer. I will try
to find where to enlarge it. I have posted the partial result to:
http://www.dea.icai.upcomillas.es/romano/linux/info/dmesg-resume-nofreeze.txt
in the hope that something can be used. I am running 2.6.21.2, with the
"no freeze kthreads at all" patch from Matthew Garrett, with this
add-on:
--- drivers/base/firmware_class.c.orig 2007-05-30 12:19:59.0 +0200
+++ drivers/base/firmware_class.c 2007-05-29 19:39:56.0 +0200
@@ -471,7 +471,11 @@
struct device *device)
{
int uevent = 1;
-return _request_firmware(firmware_p, name, device, uevent);
+int rval;
+printk(KERN_ERR "FW: requesting firmware (sync) for %s\n", name);
+rval = _request_firmware(firmware_p, name, device, uevent);
+printk(KERN_ERR "FW: return %d\n", rval);
+return rval;
}
/**
@@ -545,7 +549,9 @@
struct task_struct *task;
struct firmware_work *fw_work = kmalloc(sizeof (struct firmware_work),
GFP_ATOMIC);
-
+
+printk(KERN_ERR "FW: requesting firmware (async) for %s\n", name);
+
if (!fw_work)
return -ENOMEM;
if (!try_module_get(module)) {
@@ -569,8 +575,12 @@
fw_work->cont(NULL, fw_work->context);
module_put(fw_work->module);
kfree(fw_work);
+printk(KERN_ERR "FW: failing return %d\n", PTR_ERR(task));
return PTR_ERR(task);
}
+
+printk(KERN_ERR "FW: normal return\n");
+
return 0;
}
--
Romano Giannetti --- [EMAIL PROTECTED]
Sorry for the following disclaimer, it's attached by our otugoing server
and I cannot shut it up.
--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso
del destinatario indicado en la misma. Si Ud. no es el destinatario indicado,
le informamos que cualquier forma de distribución, reproducción o uso de esta
comunicación y/o de la información contenida en la misma están estrictamente
prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por
favor, notifíquelo inmediatamente al remitente contestando a este mensaje y
proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive
use of the intended addressee. If you are not the intended addressee, please
note that any form of distribution, copying or use of this communication or the
information in it is strictly prohibited by law. If you have received this
communication in error, please immediately notify the sender by reply e-mail
and destroy this message. Thank you for your cooperation.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: USB is nfg after suspend/resume(RAM) cycle onIntel chipset
On Tue, 2007-05-29 at 10:07 -0700, Nish Aravamudan wrote: > Click on "raw"? e.g.: > > summary | shortlog | log | commit | commitdiff | tree > raw (parent: 1ea0975) > > Neare the top. Hmmm...yes, but if you click raw, you ave "500 internal error", and a raw html source (that is, content: header is right :-) a least). Added webmaster to Cc:, as per instruction in the error itself. Romano -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regression: USB is nfg after suspend/resume(RAM) cycle onIntel chipset
On Tue, 2007-05-29 at 10:07 -0700, Nish Aravamudan wrote: Click on raw? e.g.: summary | shortlog | log | commit | commitdiff | tree raw (parent: 1ea0975) Neare the top. Hmmm...yes, but if you click raw, you ave 500 internal error, and a raw html source (that is, content: header is right :-) a least). Added webmaster to Cc:, as per instruction in the error itself. Romano -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
On Tue, 2007-05-29 at 07:55 -0700, Linus Torvalds wrote:
On Tue, 29 May 2007, Romano Giannetti wrote:
- The good (?) news. I have made 7 suspend/resume cycle (to ram, I
haven't tested hibernation) with a 2.6.21.2 with that patch, applied
manually. The system did suspend and resume nicely even compiling a
kernel and opening openoffice. Normally (le me stress _normally_) no
delay was apparent on resume. I do not know how dangerous is this... :-)
- The bad (?) news. One time out of 7 I had the 60 seconds delay.
Interesting. If you can re-create it, please do the sysrq-T thing again,
to see what's up. (Also, you might do sysrq-p, which gives the current
process data, which sysrq-T does not).
I've got it, but I had a problem: I filled the dmesg buffer. I will try
to find where to enlarge it. I have posted the partial result to:
http://www.dea.icai.upcomillas.es/romano/linux/info/dmesg-resume-nofreeze.txt
in the hope that something can be used. I am running 2.6.21.2, with the
no freeze kthreads at all patch from Matthew Garrett, with this
add-on:
--- drivers/base/firmware_class.c.orig 2007-05-30 12:19:59.0 +0200
+++ drivers/base/firmware_class.c 2007-05-29 19:39:56.0 +0200
@@ -471,7 +471,11 @@
struct device *device)
{
int uevent = 1;
-return _request_firmware(firmware_p, name, device, uevent);
+int rval;
+printk(KERN_ERR FW: requesting firmware (sync) for %s\n, name);
+rval = _request_firmware(firmware_p, name, device, uevent);
+printk(KERN_ERR FW: return %d\n, rval);
+return rval;
}
/**
@@ -545,7 +549,9 @@
struct task_struct *task;
struct firmware_work *fw_work = kmalloc(sizeof (struct firmware_work),
GFP_ATOMIC);
-
+
+printk(KERN_ERR FW: requesting firmware (async) for %s\n, name);
+
if (!fw_work)
return -ENOMEM;
if (!try_module_get(module)) {
@@ -569,8 +575,12 @@
fw_work-cont(NULL, fw_work-context);
module_put(fw_work-module);
kfree(fw_work);
+printk(KERN_ERR FW: failing return %d\n, PTR_ERR(task));
return PTR_ERR(task);
}
+
+printk(KERN_ERR FW: normal return\n);
+
return 0;
}
--
Romano Giannetti --- [EMAIL PROTECTED]
Sorry for the following disclaimer, it's attached by our otugoing server
and I cannot shut it up.
--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso
del destinatario indicado en la misma. Si Ud. no es el destinatario indicado,
le informamos que cualquier forma de distribución, reproducción o uso de esta
comunicación y/o de la información contenida en la misma están estrictamente
prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por
favor, notifíquelo inmediatamente al remitente contestando a este mensaje y
proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive
use of the intended addressee. If you are not the intended addressee, please
note that any form of distribution, copying or use of this communication or the
information in it is strictly prohibited by law. If you have received this
communication in error, please immediately notify the sender by reply e-mail
and destroy this message. Thank you for your cooperation.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
.741000] PM: Writing back config space on device :00:01.0 at offset 9 (was fff0, writing 38003800) [ 364.741000] PCI: Setting latency timer of device :00:01.0 to 64 [ 364.754000] ACPI: PCI Interrupt :00:07.2[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9 [ 364.755000] PCI: Setting latency timer of device :00:07.2 to 64 [ 364.755000] usb usb1: root hub lost power or was reset [ 364.766000] ACPI: PCI Interrupt :00:07.3[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9 [ 364.766000] PCI: Setting latency timer of device :00:07.3 to 64 [ 364.766000] usb usb2: root hub lost power or was reset [ 364.803000] ACPI: PCI Interrupt :00:07.5[C] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5 [ 364.803000] PCI: Setting latency timer of device :00:07.5 to 64 [ 365.761000] pccard: CardBus card inserted into slot 0 [ 365.819000] rtl8180: Configuring chip resources [ 365.819000] PCI: Enabling device :02:00.0 ( -> 0003) [ 365.819000] ACPI: PCI Interrupt :02:00.0[A] -> Link [LNKA] -> GSI 9 (level, low) -> IRQ 9 [ 365.819000] PCI: Setting latency timer of device :02:00.0 to 64 [ 365.819000] rtl8180: Memory mapped space @ 0x3400 [ 365.819000] rtl8180: MAC controller is a RTL8180 (v. F) (rtl8180 deleted) [ 367.007000] pccard: PCMCIA card inserted into slot 1 [ 367.007000] pcmcia: registering new device pcmcia1.0 [ 367.061000] pcmcia: request for exclusive IRQ could not be fulfilled. [ 367.061000] pcmcia: the driver needs updating to supported shared IRQ lines. [ 367.112000] eth0: 3Com 3c589, io 0x300, irq 3, hw_addr 00:00:86:1A:4E:A8 [ 367.112000] 8K FIFO split 5:3 Rx:Tx, auto xcvr [ 367.112000] pcmcia: registering new device pcmcia1.1 [ 367.112000] pcmcia: request for exclusive IRQ could not be fulfilled. [ 367.112000] pcmcia: the driver needs updating to supported shared IRQ lines. [ 367.153000] 1.1: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A well, now the modem is S1. Not too much trouble, it's doing this since immemorial time. [ 367.165000] PM: Writing back config space on device :00:0e.0 at offset 3 (was 8, writing 4008) [ 367.165000] PM: Writing back config space on device :00:0e.0 at offset 1 (was 2100012, writing 2100016) [ 367.216000] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[9] MMIO=[e8004000-e80047ff] Max Packet=[2048] IR/IT contexts=[4/8] [ 367.222000] PM: Writing back config space on device :00:10.0 at offset 5 (was 0, writing e8004800) [ 367.222000] PM: Writing back config space on device :00:10.0 at offset 4 (was 1, writing 1801) [ 367.222000] PM: Writing back config space on device :00:10.0 at offset 1 (was 290, writing 293) [ 367.223000] pnp: Device 00:08 activated. [ 367.223000] pnp: Failed to activate device 00:0a. [ 367.223000] pnp: Failed to activate device 00:0b. [ 368.041000] Associated successfully [ 368.041000] Using B rates [ 368.08] usbdev1.2_ep00: PM: resume from 0, parent 1-2 still 2 [ 368.08] usbhid 1-2:1.0: PM: resume from 2, parent 1-2 still 2 [ 368.08] usbdev1.2_ep81: PM: resume from 0, parent 1-2:1.0 still 2 [ 368.08] usbdev1.2: PM: resume from 0, parent 1-2 still 2 [ 368.151000] usb 1-2: USB disconnect, address 2 [ 368.357000] usb 1-2: new low speed USB device using uhci_hcd and address 3 [ 368.498000] usb 1-2: configuration #1 chosen from 1 choice [ 368.515000] input: HID 062a:0001 as /class/input/input8 [ 368.515000] input: USB HID v1.10 Mouse [HID 062a:0001] on usb-:00:07.2-2 [ 369.826000] 8139too Fast Ethernet driver 0.9.28 [ 369.827000] ACPI: PCI Interrupt :00:10.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10 [ 369.828000] eth0: RealTek RTL8139 at 0xe0a98800, 08:00:46:6e:93:a8, IRQ 10 [ 369.828000] eth0: Identified 8139 chip type 'RTL-8139C' [ 371.247000] input: Power Button (FF) as /class/input/input9 [ 371.297000] ACPI: Power Button (FF) [PWRF] [ 371.359000] input: Sleep Button (CM) as /class/input/input10 [ 371.359000] ACPI: Sleep Button (CM) [SBTN] [ 371.402000] input: Lid Switch as /class/input/input11 [ 371.403000] ACPI: Lid Switch [LID] [ 371.607000] ACPI: Thermal Zone [THRM] (54 C) [ 371.661000] ACPI: AC Adapter [ACAD] (on-line) [ 372.01] ACPI: Battery Slot [BAT1] (battery present) [ 372.02] ACPI: Battery Slot [BAT2] (battery absent) -- Romano Giannetti --- [EMAIL PROTECTED] Sorry for the following disclaimer, it's attached by our otugoing server and I cannot shut it up. -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mens
Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review
:07.2[D] - Link [LNKD] - GSI 9 (level, low) - IRQ 9 [ 364.755000] PCI: Setting latency timer of device :00:07.2 to 64 [ 364.755000] usb usb1: root hub lost power or was reset [ 364.766000] ACPI: PCI Interrupt :00:07.3[D] - Link [LNKD] - GSI 9 (level, low) - IRQ 9 [ 364.766000] PCI: Setting latency timer of device :00:07.3 to 64 [ 364.766000] usb usb2: root hub lost power or was reset [ 364.803000] ACPI: PCI Interrupt :00:07.5[C] - Link [LNKC] - GSI 5 (level, low) - IRQ 5 [ 364.803000] PCI: Setting latency timer of device :00:07.5 to 64 [ 365.761000] pccard: CardBus card inserted into slot 0 [ 365.819000] rtl8180: Configuring chip resources [ 365.819000] PCI: Enabling device :02:00.0 ( - 0003) [ 365.819000] ACPI: PCI Interrupt :02:00.0[A] - Link [LNKA] - GSI 9 (level, low) - IRQ 9 [ 365.819000] PCI: Setting latency timer of device :02:00.0 to 64 [ 365.819000] rtl8180: Memory mapped space @ 0x3400 [ 365.819000] rtl8180: MAC controller is a RTL8180 (v. F) (rtl8180 deleted) [ 367.007000] pccard: PCMCIA card inserted into slot 1 [ 367.007000] pcmcia: registering new device pcmcia1.0 [ 367.061000] pcmcia: request for exclusive IRQ could not be fulfilled. [ 367.061000] pcmcia: the driver needs updating to supported shared IRQ lines. [ 367.112000] eth0: 3Com 3c589, io 0x300, irq 3, hw_addr 00:00:86:1A:4E:A8 [ 367.112000] 8K FIFO split 5:3 Rx:Tx, auto xcvr [ 367.112000] pcmcia: registering new device pcmcia1.1 [ 367.112000] pcmcia: request for exclusive IRQ could not be fulfilled. [ 367.112000] pcmcia: the driver needs updating to supported shared IRQ lines. [ 367.153000] 1.1: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A well, now the modem is S1. Not too much trouble, it's doing this since immemorial time. [ 367.165000] PM: Writing back config space on device :00:0e.0 at offset 3 (was 8, writing 4008) [ 367.165000] PM: Writing back config space on device :00:0e.0 at offset 1 (was 2100012, writing 2100016) [ 367.216000] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[9] MMIO=[e8004000-e80047ff] Max Packet=[2048] IR/IT contexts=[4/8] [ 367.222000] PM: Writing back config space on device :00:10.0 at offset 5 (was 0, writing e8004800) [ 367.222000] PM: Writing back config space on device :00:10.0 at offset 4 (was 1, writing 1801) [ 367.222000] PM: Writing back config space on device :00:10.0 at offset 1 (was 290, writing 293) [ 367.223000] pnp: Device 00:08 activated. [ 367.223000] pnp: Failed to activate device 00:0a. [ 367.223000] pnp: Failed to activate device 00:0b. [ 368.041000] Associated successfully [ 368.041000] Using B rates [ 368.08] usbdev1.2_ep00: PM: resume from 0, parent 1-2 still 2 [ 368.08] usbhid 1-2:1.0: PM: resume from 2, parent 1-2 still 2 [ 368.08] usbdev1.2_ep81: PM: resume from 0, parent 1-2:1.0 still 2 [ 368.08] usbdev1.2: PM: resume from 0, parent 1-2 still 2 [ 368.151000] usb 1-2: USB disconnect, address 2 [ 368.357000] usb 1-2: new low speed USB device using uhci_hcd and address 3 [ 368.498000] usb 1-2: configuration #1 chosen from 1 choice [ 368.515000] input: HID 062a:0001 as /class/input/input8 [ 368.515000] input: USB HID v1.10 Mouse [HID 062a:0001] on usb-:00:07.2-2 [ 369.826000] 8139too Fast Ethernet driver 0.9.28 [ 369.827000] ACPI: PCI Interrupt :00:10.0[A] - Link [LNKB] - GSI 10 (level, low) - IRQ 10 [ 369.828000] eth0: RealTek RTL8139 at 0xe0a98800, 08:00:46:6e:93:a8, IRQ 10 [ 369.828000] eth0: Identified 8139 chip type 'RTL-8139C' [ 371.247000] input: Power Button (FF) as /class/input/input9 [ 371.297000] ACPI: Power Button (FF) [PWRF] [ 371.359000] input: Sleep Button (CM) as /class/input/input10 [ 371.359000] ACPI: Sleep Button (CM) [SBTN] [ 371.402000] input: Lid Switch as /class/input/input11 [ 371.403000] ACPI: Lid Switch [LID] [ 371.607000] ACPI: Thermal Zone [THRM] (54 C) [ 371.661000] ACPI: AC Adapter [ACAD] (on-line) [ 372.01] ACPI: Battery Slot [BAT1] (battery present) [ 372.02] ACPI: Battery Slot [BAT2] (battery absent) -- Romano Giannetti --- [EMAIL PROTECTED] Sorry for the following disclaimer, it's attached by our otugoing server and I cannot shut it up. -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use
Re: Long delay in resume from RAM (Was Re: [patch 00/69]-stablereview)
On Thu, 2007-05-24 at 15:49 -0700, Linus Torvalds wrote: > > It really would be nice of you to just "git bisect" this, to see where it > started having that 60-second delay.. ...and while at it, I decided to start by learning a bit more of git, and installed the last version... % git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 Initialized empty Git repository in /usr/src/git/linux-2.6/.git/ Cannot get remote repository information. Perhaps git-update-server-info needs to be run there? I cannot use git protocol from here (overfirewalling, you know...) Romano -- Romano Giannetti --- [EMAIL PROTECTED] Sorry for the following disclaimer, it's attached by our otugoing server and I cannot shut it up. -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Long delay in resume from RAM (Was Re: [patch 00/69]-stablereview)
On Thu, 2007-05-24 at 15:49 -0700, Linus Torvalds wrote: > > On Fri, 25 May 2007, Romano Giannetti wrote: > > > > Another naive doubt I have is: in 2.6.17.13, with additional patches > > http://zeus2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d834c16516d1ebec4766fc58c059bf01311e6045 > > http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=f755c48254ce743a3d4c1fd6b136366c018ee5b2 > > http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=e6248ff596dd15bce0be4d780c60f173389b11c3 > > > > (now in the mainline), it works. And it used the cis file too. > > It really would be nice of you to just "git bisect" this, to see where it > started having that 60-second delay.. > > Linus Yep, it would be nice. I will try; but this has to wait a week or more, end term is approaching and this is a busy period not only for student. Meanwhile, I tried to compile with PCMCIA debug with nil result (it seems that a good part of the kernel do not compile if you override EXTRA_CFLAGS on the make command line). So I tried to define PCMCIA_DEBUG=4 in the source(s) file affected, but no joy... then I checked in a clean tree: cd /linux-2.6.21.3/drivers/pcmcia % grep PCMCIA_DEBUG * Kconfig:config PCMCIA_DEBUG m8xx_pcmcia.c:#ifdef PCMCIA_DEBUG m8xx_pcmcia.c:static int pc_debug = PCMCIA_DEBUG; Makefile:ifeq ($(CONFIG_PCMCIA_DEBUG),y) ...so it's seems that only the m8xx modules uses it, and the modules that load the drivers for my card is yenta_socket... no idea on how to enable debug. Romano -- Romano Giannetti --- [EMAIL PROTECTED] Sorry for the following disclaimer, it's attached by our otugoing server and I cannot shut it up. -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Long delay in resume from RAM (Was Re: [patch 00/69]-stablereview)
On Thu, 2007-05-24 at 15:49 -0700, Linus Torvalds wrote: On Fri, 25 May 2007, Romano Giannetti wrote: Another naive doubt I have is: in 2.6.17.13, with additional patches http://zeus2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d834c16516d1ebec4766fc58c059bf01311e6045 http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=f755c48254ce743a3d4c1fd6b136366c018ee5b2 http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=e6248ff596dd15bce0be4d780c60f173389b11c3 (now in the mainline), it works. And it used the cis file too. It really would be nice of you to just git bisect this, to see where it started having that 60-second delay.. Linus Yep, it would be nice. I will try; but this has to wait a week or more, end term is approaching and this is a busy period not only for student. Meanwhile, I tried to compile with PCMCIA debug with nil result (it seems that a good part of the kernel do not compile if you override EXTRA_CFLAGS on the make command line). So I tried to define PCMCIA_DEBUG=4 in the source(s) file affected, but no joy... then I checked in a clean tree: cd /linux-2.6.21.3/drivers/pcmcia % grep PCMCIA_DEBUG * Kconfig:config PCMCIA_DEBUG m8xx_pcmcia.c:#ifdef PCMCIA_DEBUG m8xx_pcmcia.c:static int pc_debug = PCMCIA_DEBUG; Makefile:ifeq ($(CONFIG_PCMCIA_DEBUG),y) ...so it's seems that only the m8xx modules uses it, and the modules that load the drivers for my card is yenta_socket... no idea on how to enable debug. Romano -- Romano Giannetti --- [EMAIL PROTECTED] Sorry for the following disclaimer, it's attached by our otugoing server and I cannot shut it up. -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Long delay in resume from RAM (Was Re: [patch 00/69]-stablereview)
On Thu, 2007-05-24 at 15:49 -0700, Linus Torvalds wrote: It really would be nice of you to just git bisect this, to see where it started having that 60-second delay.. ...and while at it, I decided to start by learning a bit more of git, and installed the last version... % git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 Initialized empty Git repository in /usr/src/git/linux-2.6/.git/ Cannot get remote repository information. Perhaps git-update-server-info needs to be run there? I cannot use git protocol from here (overfirewalling, you know...) Romano -- Romano Giannetti --- [EMAIL PROTECTED] Sorry for the following disclaimer, it's attached by our otugoing server and I cannot shut it up. -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21.1 fails to suspend/resume to disk (sort of)
On Thu, 2007-05-24 at 21:27 +0200, Rafael J. Wysocki wrote: > On Thursday, 24 May 2007 07:20, Romano Giannetti wrote: > > On Wed, 2007-05-23 at 18:57 +0200, Rafael J. Wysocki wrote: > > > On Wednesday, 23 May 2007 11:57, Romano Giannetti wrote: > > > > On Wed, 2007-05-23 at 11:05 +0200, Rafael J. Wysocki wrote: > > > > > Hi, > > > > > > > > > > On Wednesday, 23 May 2007 09:25, Romano Giannetti wrote: > > > > > > http://lkml.org/lkml/2007/5/23/38 > > > > > > > > > > Please see http://bugzilla.kernel.org/show_bug.cgi?id=8456 > > > > > That seems to resemble the symptoms you describe. > > > > > > > > > > > > > No, I don't think. The delay I observe is on resume (suspend is very > > > > fast). Moreover, I have no SATA. It seems that my problem came from > > > > pcmcia. > > > > > > Hmm, there also is this patch: http://lkml.org/lkml/2007/5/22/434 > > > > > Neither this is related. My report was for a delay of 60 seconds on > > resume, not an infinite delay. And I have no bluetooth here. > > > > I will try to add some data to the bug and then will open a bugzilla > > report. > > OK, please add my address to the bugzilla entry's CC list. > Good news. I tried it in 2.6.21.2, vanilla, without the pcmcia 3COM card (see the other thread) and it works. With the default platform config. Thanks. Romano - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Long delay in resume from RAM (Was Re: [patch 00/69]-stablereview)
On Thu, 2007-05-24 at 08:28 -0700, Linus Torvalds wrote: > Can you compile those two modules with PCMCIA_DEBUG=4? > > Something like > > make EXTRA_CFLAGS=-DPCMCIA_DEBUG=4 > Well, I have to give up for tonight... that make do not works (see the problem explained in other messages, some part of the kernel fails to compile for the redefined EXTRA_CFLAGS); I naively tried to do: make EXTRA_CFLAGS=-DPCMCIA_DEBUG=4 drivers/pcmcia/ (which worked) and then make (alone) but the second one recompiled the drivers/pcmcia/ subdir, too. Too tired to think right now (good excuse), so I will try to find a bit of time tomorrow. Another naive doubt I have is: in 2.6.17.13, with additional patches http://zeus2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d834c16516d1ebec4766fc58c059bf01311e6045 http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=f755c48254ce743a3d4c1fd6b136366c018ee5b2 http://zeus2.kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-fixes-2.6.git;a=commitdiff;h=e6248ff596dd15bce0be4d780c60f173389b11c3 (now in the mainline), it works. And it used the cis file too. Romano -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración. This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)
On Thu, 2007-05-24 at 23:12 +0200, Sam Ravnborg wrote: > > I really cannot see why it makes a difference. > If you use += (and :=) make will resolve EXTRA_CFLAGS when it see it. > Whereas with = make will resolve it only when actually referenced. > > But the way we use EXTRA_CFLAGS it should not matter. > If the fix above really helps nfs I need to take a closer look tomorrow. > No, you're right, it doesn't help. What could help is a form of saying to make "add this EXTRA_CFLAGS to whatever is specified in the command line". No idea if it exists. Romano - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)
On Thu, 2007-05-24 at 13:35 -0700, Linus Torvalds wrote: > > On Thu, 24 May 2007, Linus Torvalds wrote: > > > > Occasional lockups on resume is probably a separate issue, and it might > > well be a race, or even just firmware timing bugs. > > Btw, to solve the 60-second timeout problem, do you actually _need_ to > have CONFIG_PCMCIA_LOAD_CIS enabled for those cards to work for you? Quite > likely that's the "firmware" that screws up for you, and it's also not > totally unlikely that you don't even need it. I could try to undefine it. As a fast try, I simply removed the .cis file, and the card do not work (complains it can't find cis file). I do not remember where, but I read that I need this file --- I think I found it mentioned in the cardmgr->pccardctl conversion HOWTO. Romano - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)
On Thu, 2007-05-24 at 14:01 -0700, Andrew Morton wrote: > On Thu, 24 May 2007 22:14:08 +0200 > Romano Giannetti <[EMAIL PROTECTED]> wrote: > > ntfs is being naughty. > > hm, lots of Makefiles commit the same sin. Sam, is this as busted as > I think it is? Hmmm... CC [M] drivers/ide/pci/amd74xx.o drivers/ide/pci/amd74xx.c:28:24: error: ide-timing.h: No such file or directory (etc etc) ... and in Makefile: EXTRA_CFLAGS:= -Idrivers/ide I changed it to EXTRA_CFLAGS+= -Idrivers/ide but I have the same error. Puzzled (yes, again). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Long delay in resume from RAM (Was Re: [patch 00/69] -stablereview)
On Thu, 2007-05-24 at 08:52 -0700, Linus Torvalds wrote: > > On Thu, 24 May 2007, Linus Torvalds wrote: > > > > Ok. That was probably true even before you added the suspend ordering > > patch. > > Oh, no it apparently wasn't. I missed your other email that said > >"So, I tried to suspend without any card in the pcmcia slot. Guess what? > I extracted the card and the system did not suspend. Just stopped dead." > > so apparently the patch actually did matter for you. Can you double-check > and confirm? > Well, I've made a bit of a mess. The setup that has not the delay when the card is out is a plain 2.6.21.2 (without suspend ordering). The lockup ocurred on a 2.6.21.1 WITH the suspend ordering patch, but was just one time, after I plugged and unplugged the card several time. Could not reproduce it, however. Puzzled. Romano - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
