[PATCH] Against sk98lin driver from syskonnect [was: Re: PCI-Express not working/unuseable on Intel 925XE since 2.6.12-rc1[mm1-4]]
Bjorn Helgaas napisaÅ(a):
>>Version from syskonnect site require only changing usage of
>>pci_dev->slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After
>>that everything should work fine. So I think there is no need to post my
>>path here but if you really whant I may do this. Whole path agains
>>2.6.12-rc2 take about 1.2 MB (diffstat attached below).
>
>
> I agree, no need to post a whole 1.2MB patch (goodness, what's
> in this driver, anyway, that it would need a 1.2MB *patch*? :-))
I'm wondering too :)
> But you seem to be saying that the driver from syskonnect (and possibly
> the one in 2.6.12-rc1-bk3 as well) does not work as-is, and that you have
> a small patch that makes it work.
The one that is in 2.6.12-rc1-bk2 and latest 2.6.13-rc2 doesn't work
with Marvell Yukon 88E8053 GigE.
Attached patch convert pci_dev->slot_name usage to pci_name() in skge.c
and skethtool.c. First you must apply patch generated by install script
and after that apply this patch:-)
Regards
Jacek
---
drivers/net/sk98lin/skethtool.c |2 +-
drivers/net/sk98lin/skge.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
---
--- linux-2.6.12-rc2/drivers/net/sk98lin/skge.c 2005-04-09 14:49:39.0
+0200
+++ linux/drivers/net/sk98lin/skge.c2005-04-09 02:04:49.0 +0200
@@ -4026,7 +4026,7 @@
*/
* ((SK_U32 *)pMemBuf) = 0;
* ((SK_U32 *)pMemBuf + 1) = pdev->bus->number;
- * ((SK_U32 *)pMemBuf + 2) =
ParseDeviceNbrFromSlotName(pdev->slot_name);
+ * ((SK_U32 *)pMemBuf + 2) =
ParseDeviceNbrFromSlotName(pci_name(pdev));
if(copy_to_user(Ioctl.pData, pMemBuf, Length) ) {
Err = -EFAULT;
goto fault_diag;
--- linux-2.6.12-rc2/drivers/net/sk98lin/skethtool.c2005-04-09
14:49:39.0 +0200
+++ linux/drivers/net/sk98lin/skethtool.c 2005-04-09 02:04:49.0
+0200
@@ -1136,7 +1136,7 @@
strncpy(edrvinfo->driver, DRIVER_FILE_NAME , 32);
strncpy(edrvinfo->version, versionString , 32);
strncpy(edrvinfo->fw_version, "N/A", 32);
- strncpy(edrvinfo->bus_info, pAC->PciDev->slot_name, 32);
+ strncpy(edrvinfo->bus_info, pci_name(pAC->PciDev), 32);
#ifdef ETHTOOL_GSTATS
edrvinfo->n_stats = SK98LIN_STATS_LEN;
#endif
[PATCH] Against sk98lin driver from syskonnect [was: Re: PCI-Express not working/unuseable on Intel 925XE since 2.6.12-rc1[mm1-4]]
Bjorn Helgaas napisa(a):
Version from syskonnect site require only changing usage of
pci_dev-slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After
that everything should work fine. So I think there is no need to post my
path here but if you really whant I may do this. Whole path agains
2.6.12-rc2 take about 1.2 MB (diffstat attached below).
I agree, no need to post a whole 1.2MB patch (goodness, what's
in this driver, anyway, that it would need a 1.2MB *patch*? :-))
I'm wondering too :)
But you seem to be saying that the driver from syskonnect (and possibly
the one in 2.6.12-rc1-bk3 as well) does not work as-is, and that you have
a small patch that makes it work.
The one that is in 2.6.12-rc1-bk2 and latest 2.6.13-rc2 doesn't work
with Marvell Yukon 88E8053 GigE.
Attached patch convert pci_dev-slot_name usage to pci_name() in skge.c
and skethtool.c. First you must apply patch generated by install script
and after that apply this patch:-)
Regards
Jacek
---
drivers/net/sk98lin/skethtool.c |2 +-
drivers/net/sk98lin/skge.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
---
--- linux-2.6.12-rc2/drivers/net/sk98lin/skge.c 2005-04-09 14:49:39.0
+0200
+++ linux/drivers/net/sk98lin/skge.c2005-04-09 02:04:49.0 +0200
@@ -4026,7 +4026,7 @@
*/
* ((SK_U32 *)pMemBuf) = 0;
* ((SK_U32 *)pMemBuf + 1) = pdev-bus-number;
- * ((SK_U32 *)pMemBuf + 2) =
ParseDeviceNbrFromSlotName(pdev-slot_name);
+ * ((SK_U32 *)pMemBuf + 2) =
ParseDeviceNbrFromSlotName(pci_name(pdev));
if(copy_to_user(Ioctl.pData, pMemBuf, Length) ) {
Err = -EFAULT;
goto fault_diag;
--- linux-2.6.12-rc2/drivers/net/sk98lin/skethtool.c2005-04-09
14:49:39.0 +0200
+++ linux/drivers/net/sk98lin/skethtool.c 2005-04-09 02:04:49.0
+0200
@@ -1136,7 +1136,7 @@
strncpy(edrvinfo-driver, DRIVER_FILE_NAME , 32);
strncpy(edrvinfo-version, versionString , 32);
strncpy(edrvinfo-fw_version, N/A, 32);
- strncpy(edrvinfo-bus_info, pAC-PciDev-slot_name, 32);
+ strncpy(edrvinfo-bus_info, pci_name(pAC-PciDev), 32);
#ifdef ETHTOOL_GSTATS
edrvinfo-n_stats = SK98LIN_STATS_LEN;
#endif
Re: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
> Version from syskonnect site require only changing usage of > pci_dev->slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After > that everything should work fine. So I think there is no need to post my > path here but if you really whant I may do this. Whole path agains > 2.6.12-rc2 take about 1.2 MB (diffstat attached below). I agree, no need to post a whole 1.2MB patch (goodness, what's in this driver, anyway, that it would need a 1.2MB *patch*? :-)) But you seem to be saying that the driver from syskonnect (and possibly the one in 2.6.12-rc1-bk3 as well) does not work as-is, and that you have a small patch that makes it work. If so, I think it's worth posting the small patch, so other users of the device can at least get it working until syskonnect gets things squared away. My apologies if I'm misunderstanding the situation. - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Bjorn Helgaas wrote: > On Fri, 2005-04-01 at 21:23 +0200, Jacek Luczak wrote: > >>Michael Thonke napisał(a): >> >>>Hello Jacek, >>> >>>I finially got it working :-) my PCI-Express devices working now... >>>I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia >>>everything except the Marvell Yokon PCI-E device working. >>>I hope Andrew will look into the mm-line to find the bug? >>> >> >>I've got Marvell Yukon 88E8053 GigE and it works fine with fixed (by >>myself :]) driver from syskonnect. If you wont I may send it to you! > > > Please post your patch here and copy the maintainers: > > MARVELL YUKON / SYSKONNECT DRIVER > P: Mirko Lindner > M: [EMAIL PROTECTED] > P: Ralph Roesler > M: [EMAIL PROTECTED] > W: http://www.syskonnect.com > S: Supported > > > Hi I sent my patch to Mirko about 3 weeks ago. Mirko replied that he consider it. Since that time new version of sk98lin driver appeared. Version from syskonnect site require only changing usage of pci_dev->slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After that everything should work fine. So I think there is no need to post my path here but if you really whant I may do this. Whole path agains 2.6.12-rc2 take about 1.2 MB (diffstat attached below). Jacek --- drivers/net/Kconfig | 113 - drivers/net/sk98lin/Makefile | 64 drivers/net/sk98lin/h/lm80.h |4 drivers/net/sk98lin/h/skaddr.h|4 drivers/net/sk98lin/h/skcsum.h|6 drivers/net/sk98lin/h/skdebug.h | 20 drivers/net/sk98lin/h/skdrv1st.h | 41 drivers/net/sk98lin/h/skdrv2nd.h | 978 ++--- drivers/net/sk98lin/h/skerror.h | 12 drivers/net/sk98lin/h/skgedrv.h |4 drivers/net/sk98lin/h/skgehw.h| 1377 ++--- drivers/net/sk98lin/h/skgehwt.h |4 drivers/net/sk98lin/h/skgei2c.h | 210 -- drivers/net/sk98lin/h/skgeinit.h | 369 ++- drivers/net/sk98lin/h/skgepnm2.h | 12 drivers/net/sk98lin/h/skgepnmi.h | 141 - drivers/net/sk98lin/h/skgesirq.h | 40 drivers/net/sk98lin/h/skgetwsi.h | 241 ++ drivers/net/sk98lin/h/ski2c.h | 177 - drivers/net/sk98lin/h/skqueue.h | 13 drivers/net/sk98lin/h/skrlmt.h|4 drivers/net/sk98lin/h/sktimer.h |4 drivers/net/sk98lin/h/sktwsi.h| 177 + drivers/net/sk98lin/h/sktypes.h | 62 drivers/net/sk98lin/h/skversion.h | 34 drivers/net/sk98lin/h/skvpd.h | 84 drivers/net/sk98lin/h/sky2le.h| 891 drivers/net/sk98lin/h/xmac_ii.h | 621 +++--- drivers/net/sk98lin/sk98lin.txt | 203 +- drivers/net/sk98lin/skaddr.c | 79 drivers/net/sk98lin/skcsum.c |6 drivers/net/sk98lin/skdim.c | 1027 +++--- drivers/net/sk98lin/skethtool.c | 1379 ++--- drivers/net/sk98lin/skge.c| 3779 -- drivers/net/sk98lin/skgehwt.c | 52 drivers/net/sk98lin/skgeinit.c| 1683 drivers/net/sk98lin/skgemib.c | 186 + drivers/net/sk98lin/skgepnmi.c| 2282 +++--- drivers/net/sk98lin/skgesirq.c| 1244 +++- drivers/net/sk98lin/ski2c.c | 1296 - drivers/net/sk98lin/sklm80.c | 10 drivers/net/sk98lin/skproc.c | 587 - drivers/net/sk98lin/skqueue.c | 103 - drivers/net/sk98lin/skrlmt.c | 258 +- drivers/net/sk98lin/sktimer.c | 61 drivers/net/sk98lin/sktwsi.c | 1355 + drivers/net/sk98lin/skvpd.c | 195 + drivers/net/sk98lin/skxmac2.c | 2235 +- drivers/net/sk98lin/sky2.c| 2728 +++ drivers/net/sk98lin/sky2le.c | 510 + 50 files changed, 18204 insertions(+), 8761 deletions(-) - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
On Fri, 2005-04-01 at 21:23 +0200, Jacek Luczak wrote: > Michael Thonke napisał(a): > > Hello Jacek, > > > > I finially got it working :-) my PCI-Express devices working now... > > I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia > > everything except the Marvell Yokon PCI-E device working. > > I hope Andrew will look into the mm-line to find the bug? > > > > I've got Marvell Yukon 88E8053 GigE and it works fine with fixed (by > myself :]) driver from syskonnect. If you wont I may send it to you! Please post your patch here and copy the maintainers: MARVELL YUKON / SYSKONNECT DRIVER P: Mirko Lindner M: [EMAIL PROTECTED] P: Ralph Roesler M: [EMAIL PROTECTED] W: http://www.syskonnect.com S: Supported - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
On Fri, 2005-04-01 at 21:23 +0200, Jacek Luczak wrote: Michael Thonke napisa(a): Hello Jacek, I finially got it working :-) my PCI-Express devices working now... I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia everything except the Marvell Yokon PCI-E device working. I hope Andrew will look into the mm-line to find the bug? I've got Marvell Yukon 88E8053 GigE and it works fine with fixed (by myself :]) driver from syskonnect. If you wont I may send it to you! Please post your patch here and copy the maintainers: MARVELL YUKON / SYSKONNECT DRIVER P: Mirko Lindner M: [EMAIL PROTECTED] P: Ralph Roesler M: [EMAIL PROTECTED] W: http://www.syskonnect.com S: Supported - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Bjorn Helgaas wrote: On Fri, 2005-04-01 at 21:23 +0200, Jacek Luczak wrote: Michael Thonke napisa(a): Hello Jacek, I finially got it working :-) my PCI-Express devices working now... I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia everything except the Marvell Yokon PCI-E device working. I hope Andrew will look into the mm-line to find the bug? I've got Marvell Yukon 88E8053 GigE and it works fine with fixed (by myself :]) driver from syskonnect. If you wont I may send it to you! Please post your patch here and copy the maintainers: MARVELL YUKON / SYSKONNECT DRIVER P: Mirko Lindner M: [EMAIL PROTECTED] P: Ralph Roesler M: [EMAIL PROTECTED] W: http://www.syskonnect.com S: Supported Hi I sent my patch to Mirko about 3 weeks ago. Mirko replied that he consider it. Since that time new version of sk98lin driver appeared. Version from syskonnect site require only changing usage of pci_dev-slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After that everything should work fine. So I think there is no need to post my path here but if you really whant I may do this. Whole path agains 2.6.12-rc2 take about 1.2 MB (diffstat attached below). Jacek --- drivers/net/Kconfig | 113 - drivers/net/sk98lin/Makefile | 64 drivers/net/sk98lin/h/lm80.h |4 drivers/net/sk98lin/h/skaddr.h|4 drivers/net/sk98lin/h/skcsum.h|6 drivers/net/sk98lin/h/skdebug.h | 20 drivers/net/sk98lin/h/skdrv1st.h | 41 drivers/net/sk98lin/h/skdrv2nd.h | 978 ++--- drivers/net/sk98lin/h/skerror.h | 12 drivers/net/sk98lin/h/skgedrv.h |4 drivers/net/sk98lin/h/skgehw.h| 1377 ++--- drivers/net/sk98lin/h/skgehwt.h |4 drivers/net/sk98lin/h/skgei2c.h | 210 -- drivers/net/sk98lin/h/skgeinit.h | 369 ++- drivers/net/sk98lin/h/skgepnm2.h | 12 drivers/net/sk98lin/h/skgepnmi.h | 141 - drivers/net/sk98lin/h/skgesirq.h | 40 drivers/net/sk98lin/h/skgetwsi.h | 241 ++ drivers/net/sk98lin/h/ski2c.h | 177 - drivers/net/sk98lin/h/skqueue.h | 13 drivers/net/sk98lin/h/skrlmt.h|4 drivers/net/sk98lin/h/sktimer.h |4 drivers/net/sk98lin/h/sktwsi.h| 177 + drivers/net/sk98lin/h/sktypes.h | 62 drivers/net/sk98lin/h/skversion.h | 34 drivers/net/sk98lin/h/skvpd.h | 84 drivers/net/sk98lin/h/sky2le.h| 891 drivers/net/sk98lin/h/xmac_ii.h | 621 +++--- drivers/net/sk98lin/sk98lin.txt | 203 +- drivers/net/sk98lin/skaddr.c | 79 drivers/net/sk98lin/skcsum.c |6 drivers/net/sk98lin/skdim.c | 1027 +++--- drivers/net/sk98lin/skethtool.c | 1379 ++--- drivers/net/sk98lin/skge.c| 3779 -- drivers/net/sk98lin/skgehwt.c | 52 drivers/net/sk98lin/skgeinit.c| 1683 drivers/net/sk98lin/skgemib.c | 186 + drivers/net/sk98lin/skgepnmi.c| 2282 +++--- drivers/net/sk98lin/skgesirq.c| 1244 +++- drivers/net/sk98lin/ski2c.c | 1296 - drivers/net/sk98lin/sklm80.c | 10 drivers/net/sk98lin/skproc.c | 587 - drivers/net/sk98lin/skqueue.c | 103 - drivers/net/sk98lin/skrlmt.c | 258 +- drivers/net/sk98lin/sktimer.c | 61 drivers/net/sk98lin/sktwsi.c | 1355 + drivers/net/sk98lin/skvpd.c | 195 + drivers/net/sk98lin/skxmac2.c | 2235 +- drivers/net/sk98lin/sky2.c| 2728 +++ drivers/net/sk98lin/sky2le.c | 510 + 50 files changed, 18204 insertions(+), 8761 deletions(-) - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Version from syskonnect site require only changing usage of pci_dev-slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After that everything should work fine. So I think there is no need to post my path here but if you really whant I may do this. Whole path agains 2.6.12-rc2 take about 1.2 MB (diffstat attached below). I agree, no need to post a whole 1.2MB patch (goodness, what's in this driver, anyway, that it would need a 1.2MB *patch*? :-)) But you seem to be saying that the driver from syskonnect (and possibly the one in 2.6.12-rc1-bk3 as well) does not work as-is, and that you have a small patch that makes it work. If so, I think it's worth posting the small patch, so other users of the device can at least get it working until syskonnect gets things squared away. My apologies if I'm misunderstanding the situation. - 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.12-rc1-mm1: e100 fails to resume from swsusp
Sorry for this poor bugreport, but I haven't had time to track it down more carefully. Hardware: Vaio r505te, i815, onboard e100 Kernel: 2.6.12-rc1-mm1 plus patch to fix GlidePoint resume hang After a swsusp resume, the onboard e100 does not pass traffic. When I was running 2.6.11-rc2 (IIRC) the network worked fine after resume. I will try to verify this today. Oddly enough, things are at least well-enough connected that the driver does print "link up" messages when I connect the cat5. doing a "rmmod e100; modprobe e100" brings it back to life. /var/log/dmesg, current dmesg buffer, and lspci -vvx are attached. I'm guessing an ACPI interrupt routing issue? -andy [4294667.296000] Linux version 2.6.12-rc1-mm1 ([EMAIL PROTECTED]) (gcc version 3.3.4 (Debian 1:3.3.4-9ubuntu5)) #3 Tue Mar 29 19:02:39 PST 2005 [4294667.296000] BIOS-provided physical RAM map: [4294667.296000] BIOS-e820: - 0009e800 (usable) [4294667.296000] BIOS-e820: 0009e800 - 000a (reserved) [4294667.296000] BIOS-e820: 000c - 000cc000 (reserved) [4294667.296000] BIOS-e820: 000d8000 - 0010 (reserved) [4294667.296000] BIOS-e820: 0010 - 13cf (usable) [4294667.296000] BIOS-e820: 13cf - 13cfc000 (ACPI data) [4294667.296000] BIOS-e820: 13cfc000 - 13d0 (ACPI NVS) [4294667.296000] BIOS-e820: 13d0 - 13e8 (usable) [4294667.296000] BIOS-e820: 13e8 - 1400 (reserved) [4294667.296000] BIOS-e820: ff80 - ffc0 (reserved) [4294667.296000] BIOS-e820: fff0 - 0001 (reserved) [4294667.296000] 318MB LOWMEM available. [4294667.296000] On node 0 totalpages: 81536 [4294667.296000] DMA zone: 4096 pages, LIFO batch:1 [4294667.296000] Normal zone: 77440 pages, LIFO batch:16 [4294667.296000] HighMem zone: 0 pages, LIFO batch:1 [4294667.296000] DMI present. [4294667.296000] ACPI: RSDP (v000 PTLTD ) @ 0x000f7120 [4294667.296000] ACPI: RSDT (v001 SONY U1 0x20010312 PTL 0x) @ 0x13cf74cb [4294667.296000] ACPI: FADT (v001 SONY U1 0x20010312 PTL 0x0100) @ 0x13cfbf64 [4294667.296000] ACPI: BOOT (v001 SONY U1 0x20010312 PTL 0x0001) @ 0x13cfbfd8 [4294667.296000] ACPI: DSDT (v001 SONY U1 0x20010312 PTL 0x010b) @ 0x [4294667.296000] Allocating PCI resources starting at 1400 (gap: 1400:eb80) [4294667.296000] Built 1 zonelists [4294667.296000] Local APIC disabled by BIOS -- you can enable it with "lapic" [4294667.296000] mapped APIC to d000 (0127f000) [4294667.296000] Initializing CPU#0 [4294667.296000] Kernel command line: root=/dev/hda2 ro [4294667.296000] PID hash table entries: 2048 (order: 11, 32768 bytes) [0.00] Detected 596.455 MHz processor. [ 15.311856] Using tsc for high-res timesource [ 15.313642] Console: colour VGA+ 80x25 [ 15.315287] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 15.316679] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 15.353760] Memory: 319712k/326144k available (1691k kernel code, 5800k reserved, 778k data, 160k init, 0k highmem) [ 15.353835] Checking if this processor honours the WP bit even in supervisor mode... Ok. [ 15.354093] Calibrating delay loop... 1175.55 BogoMIPS (lpj=587776) [ 15.374454] Security Framework v1.0.0 initialized [ 15.374531] Mount-cache hash table entries: 512 [ 15.374833] CPU: After generic identify, caps: 0383f9ff [ 15.374855] CPU: After vendor identify, caps: 0383f9ff [ 15.374882] CPU: L1 I cache: 16K, L1 D cache: 16K [ 15.374925] CPU: L2 cache: 256K [ 15.374959] CPU: After all inits, caps: 0383f9ff 0040 [ 15.374975] CPU: Intel Pentium III (Coppermine) stepping 06 [ 15.375030] Enabling fast FPU save and restore... done. [ 15.375071] Enabling unmasked SIMD FPU exception support... done. [ 15.375116] Checking 'hlt' instruction... OK. [ 15.411716] ACPI: setting ELCR to 0200 (from 0628) [ 15.446665] softlockup thread 0 started up. [ 15.447647] NET: Registered protocol family 16 [ 15.448645] PCI: PCI BIOS revision 2.10 entry at 0xfd9b0, last bus=1 [ 15.448698] PCI: Using configuration type 1 [ 15.448734] mtrr: v2.0 (20020519) [ 15.449666] ACPI: Subsystem revision 20050309 [ 15.486102] ACPI: Interpreter enabled [ 15.486152] ACPI: Using PIC for interrupt routing [ 15.489646] ACPI: PCI Root Bridge [PCI0] (:00) [ 15.489692] PCI: Probing PCI hardware (bus 00) [ 15.492194] ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 [ 15.521604] Boot video device is :00:02.0 [ 15.522701] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 15.527935] ACP
2.6.12-rc1-mm1: e100 fails to resume from swsusp
Sorry for this poor bugreport, but I haven't had time to track it down more carefully. Hardware: Vaio r505te, i815, onboard e100 Kernel: 2.6.12-rc1-mm1 plus patch to fix GlidePoint resume hang After a swsusp resume, the onboard e100 does not pass traffic. When I was running 2.6.11-rc2 (IIRC) the network worked fine after resume. I will try to verify this today. Oddly enough, things are at least well-enough connected that the driver does print link up messages when I connect the cat5. doing a rmmod e100; modprobe e100 brings it back to life. /var/log/dmesg, current dmesg buffer, and lspci -vvx are attached. I'm guessing an ACPI interrupt routing issue? -andy [4294667.296000] Linux version 2.6.12-rc1-mm1 ([EMAIL PROTECTED]) (gcc version 3.3.4 (Debian 1:3.3.4-9ubuntu5)) #3 Tue Mar 29 19:02:39 PST 2005 [4294667.296000] BIOS-provided physical RAM map: [4294667.296000] BIOS-e820: - 0009e800 (usable) [4294667.296000] BIOS-e820: 0009e800 - 000a (reserved) [4294667.296000] BIOS-e820: 000c - 000cc000 (reserved) [4294667.296000] BIOS-e820: 000d8000 - 0010 (reserved) [4294667.296000] BIOS-e820: 0010 - 13cf (usable) [4294667.296000] BIOS-e820: 13cf - 13cfc000 (ACPI data) [4294667.296000] BIOS-e820: 13cfc000 - 13d0 (ACPI NVS) [4294667.296000] BIOS-e820: 13d0 - 13e8 (usable) [4294667.296000] BIOS-e820: 13e8 - 1400 (reserved) [4294667.296000] BIOS-e820: ff80 - ffc0 (reserved) [4294667.296000] BIOS-e820: fff0 - 0001 (reserved) [4294667.296000] 318MB LOWMEM available. [4294667.296000] On node 0 totalpages: 81536 [4294667.296000] DMA zone: 4096 pages, LIFO batch:1 [4294667.296000] Normal zone: 77440 pages, LIFO batch:16 [4294667.296000] HighMem zone: 0 pages, LIFO batch:1 [4294667.296000] DMI present. [4294667.296000] ACPI: RSDP (v000 PTLTD ) @ 0x000f7120 [4294667.296000] ACPI: RSDT (v001 SONY U1 0x20010312 PTL 0x) @ 0x13cf74cb [4294667.296000] ACPI: FADT (v001 SONY U1 0x20010312 PTL 0x0100) @ 0x13cfbf64 [4294667.296000] ACPI: BOOT (v001 SONY U1 0x20010312 PTL 0x0001) @ 0x13cfbfd8 [4294667.296000] ACPI: DSDT (v001 SONY U1 0x20010312 PTL 0x010b) @ 0x [4294667.296000] Allocating PCI resources starting at 1400 (gap: 1400:eb80) [4294667.296000] Built 1 zonelists [4294667.296000] Local APIC disabled by BIOS -- you can enable it with lapic [4294667.296000] mapped APIC to d000 (0127f000) [4294667.296000] Initializing CPU#0 [4294667.296000] Kernel command line: root=/dev/hda2 ro [4294667.296000] PID hash table entries: 2048 (order: 11, 32768 bytes) [0.00] Detected 596.455 MHz processor. [ 15.311856] Using tsc for high-res timesource [ 15.313642] Console: colour VGA+ 80x25 [ 15.315287] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 15.316679] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 15.353760] Memory: 319712k/326144k available (1691k kernel code, 5800k reserved, 778k data, 160k init, 0k highmem) [ 15.353835] Checking if this processor honours the WP bit even in supervisor mode... Ok. [ 15.354093] Calibrating delay loop... 1175.55 BogoMIPS (lpj=587776) [ 15.374454] Security Framework v1.0.0 initialized [ 15.374531] Mount-cache hash table entries: 512 [ 15.374833] CPU: After generic identify, caps: 0383f9ff [ 15.374855] CPU: After vendor identify, caps: 0383f9ff [ 15.374882] CPU: L1 I cache: 16K, L1 D cache: 16K [ 15.374925] CPU: L2 cache: 256K [ 15.374959] CPU: After all inits, caps: 0383f9ff 0040 [ 15.374975] CPU: Intel Pentium III (Coppermine) stepping 06 [ 15.375030] Enabling fast FPU save and restore... done. [ 15.375071] Enabling unmasked SIMD FPU exception support... done. [ 15.375116] Checking 'hlt' instruction... OK. [ 15.411716] ACPI: setting ELCR to 0200 (from 0628) [ 15.446665] softlockup thread 0 started up. [ 15.447647] NET: Registered protocol family 16 [ 15.448645] PCI: PCI BIOS revision 2.10 entry at 0xfd9b0, last bus=1 [ 15.448698] PCI: Using configuration type 1 [ 15.448734] mtrr: v2.0 (20020519) [ 15.449666] ACPI: Subsystem revision 20050309 [ 15.486102] ACPI: Interpreter enabled [ 15.486152] ACPI: Using PIC for interrupt routing [ 15.489646] ACPI: PCI Root Bridge [PCI0] (:00) [ 15.489692] PCI: Probing PCI hardware (bus 00) [ 15.492194] ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 [ 15.521604] Boot video device is :00:02.0 [ 15.522701] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 15.527935] ACPI: PCI Interrupt Routing Table [\_SB_
Re: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Michael Thonke napisaÅ(a): Hello Jacek, I finially got it working :-) my PCI-Express devices working now... I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia everything except the Marvell Yokon PCI-E device working. I hope Andrew will look into the mm-line to find the bug? I've got Marvell Yukon 88E8053 GigE and it works fine with fixed (by myself :]) driver from syskonnect. If you wont I may send it to you! Jacek - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Hello Jacek, I finially got it working :-) my PCI-Express devices working now... I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia everything except the Marvell Yokon PCI-E device working. I hope Andrew will look into the mm-line to find the bug? Greets and Best regards |Jacek Luczak schrieb: hello Michael :) This message: ACPI: No ACPI bus support for 00:00 means that acpi_get_bus_type() is unable to determinate bus type! Mayby someone forgot about PCI-E? Regards Jacek - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
hello Michael :) This message: ACPI: No ACPI bus support for 00:00 means that acpi_get_bus_type() is unable to determinate bus type! Mayby someone forgot about PCI-E? Regards Jacek - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
hello Jacek, its not related to the vendor so far we are :-) Maybe Andrew Morton or some other will read this. Because 2.6.12 should be a stable version not a flacky one. But what is wrong now on 2.6.12-rc1 **. It work flawlessly on 2.6.11.X kernels. Mebye we back that out :-) Greetz |Jacek Luczak schrieb: Michael Thonke napisaÅ(a): Hello, since the first version of 2.6.12-rc1 and mm[1-4] kernel I can't use any of my PCI-Express devices that worked with all 2.6.11.[1-6] kernels. It's a real odd right now. I have 25 computers with an Intel 925XE Chipset based motherboards and Intel 6xx CPU on it. So far it does not metter which vendor I choose (ASUS,ABIT,MSI etc.) the problem stay the same and spread all over.I tried to boot with pci=routeicq but it did not help to get one device working with any 2.6.12-rc1-xx kernel. As I mentioned before I tested it with on several (over 25 computer) with various motherboards (with ASUS,ABIT,MSI etc.) no luck. Its an 64bit system with [EMT64] and SMP/SMT and preempt enabled + cpufreq. My first look was on PCI Routingtable and I found a difference to 2.6.11.x working kernel: I've got the same problem with i915 on Asus P5GDC V Deluxe Mainboard. This fragment of dmesg is from 2.6.12-rc1-mm4 kernel: PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 Boot video device is :00:02.0 PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Can't get handler for :00:02.0 ACPI: Can't get handler for :00:02.1 ACPI: Can't get handler for :00:1b.0 ACPI: Can't get handler for :00:1f.3 ACPI: Can't get handler for :02:00.0 ACPI: Can't get handler for :01:04.0 ACPI: Can't get handler for :01:0a.0 ACPI: Can't get handler for :01:0b.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 *4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: No ACPI bus support for 00:00 ACPI: No ACPI bus support for 00:01 ACPI: No ACPI bus support for 00:02 ACPI: No ACPI bus support for 00:03 ACPI: No ACPI bus support for 00:04 ACPI: No ACPI bus support for 00:05 ACPI: No ACPI bus support for 00:06 ACPI: No ACPI bus support for 00:07 ACPI: No ACPI bus support for 00:08 ACPI: No ACPI bus support for 00:09 ACPI: No ACPI bus support for 00:0a ACPI: No ACPI bus support for 00:0b ACPI: No ACPI bus support for 00:0c ACPI: No ACPI bus support for 00:0d ACPI: No ACPI bus support for 00:0e ACPI: No ACPI bus support for 00:0f ACPI: No ACPI bus support for 00:10 pnp: PnP ACPI: found 17 devices SCSI subsystem initialized LSPCI OUTPUT: 00:00.0 Host bridge: Intel Corp.: Unknown device 2580 (rev 04) Subsystem: Intel Corp.: Unknown device 2580 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] #09 [2109] 00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2582 (rev 04) (prog-if 00 [VGA]) Subsystem: Asustek Computer, Inc.: Unknown device 2582 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at cfc8 (32-bit, non-prefetchable) [size=512K] I/O ports at 9800 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at cfd8 (32-bit, non-prefetchable) [size=256K] Expansion ROM at [disabled] Capabilities: [d0] Power Management version 2 00:02.1 Display controller: Intel Corp.: Unknown device 2782 (rev 04) Subsystem: Asustek Computer, Inc.: Unknown device 2582 Flags: bus master, fast devsel, latency 0 Memory at cfd0 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 00:1b.0 Class 0403: Intel Corp.: Unknown device 2668 (rev 03) Subsystem: Asustek Computer, Inc.: Unknown device 813d Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at cfdf4000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [70] #10 [0091] 00:1c.0 PCI bridge: Intel Corp. I/O Controller Hub PCI Express Port 0 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: e000-efff Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled
Re: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Michael Thonke napisaÅ(a): Hello, since the first version of 2.6.12-rc1 and mm[1-4] kernel I can't use any of my PCI-Express devices that worked with all 2.6.11.[1-6] kernels. It's a real odd right now. I have 25 computers with an Intel 925XE Chipset based motherboards and Intel 6xx CPU on it. So far it does not metter which vendor I choose (ASUS,ABIT,MSI etc.) the problem stay the same and spread all over.I tried to boot with pci=routeicq but it did not help to get one device working with any 2.6.12-rc1-xx kernel. As I mentioned before I tested it with on several (over 25 computer) with various motherboards (with ASUS,ABIT,MSI etc.) no luck. Its an 64bit system with [EMT64] and SMP/SMT and preempt enabled + cpufreq. My first look was on PCI Routingtable and I found a difference to 2.6.11.x working kernel: I've got the same problem with i915 on Asus P5GDC V Deluxe Mainboard. This fragment of dmesg is from 2.6.12-rc1-mm4 kernel: PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 Boot video device is :00:02.0 PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Can't get handler for :00:02.0 ACPI: Can't get handler for :00:02.1 ACPI: Can't get handler for :00:1b.0 ACPI: Can't get handler for :00:1f.3 ACPI: Can't get handler for :02:00.0 ACPI: Can't get handler for :01:04.0 ACPI: Can't get handler for :01:0a.0 ACPI: Can't get handler for :01:0b.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 *4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: No ACPI bus support for 00:00 ACPI: No ACPI bus support for 00:01 ACPI: No ACPI bus support for 00:02 ACPI: No ACPI bus support for 00:03 ACPI: No ACPI bus support for 00:04 ACPI: No ACPI bus support for 00:05 ACPI: No ACPI bus support for 00:06 ACPI: No ACPI bus support for 00:07 ACPI: No ACPI bus support for 00:08 ACPI: No ACPI bus support for 00:09 ACPI: No ACPI bus support for 00:0a ACPI: No ACPI bus support for 00:0b ACPI: No ACPI bus support for 00:0c ACPI: No ACPI bus support for 00:0d ACPI: No ACPI bus support for 00:0e ACPI: No ACPI bus support for 00:0f ACPI: No ACPI bus support for 00:10 pnp: PnP ACPI: found 17 devices SCSI subsystem initialized LSPCI OUTPUT: 00:00.0 Host bridge: Intel Corp.: Unknown device 2580 (rev 04) Subsystem: Intel Corp.: Unknown device 2580 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] #09 [2109] 00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2582 (rev 04) (prog-if 00 [VGA]) Subsystem: Asustek Computer, Inc.: Unknown device 2582 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at cfc8 (32-bit, non-prefetchable) [size=512K] I/O ports at 9800 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at cfd8 (32-bit, non-prefetchable) [size=256K] Expansion ROM at [disabled] Capabilities: [d0] Power Management version 2 00:02.1 Display controller: Intel Corp.: Unknown device 2782 (rev 04) Subsystem: Asustek Computer, Inc.: Unknown device 2582 Flags: bus master, fast devsel, latency 0 Memory at cfd0 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 00:1b.0 Class 0403: Intel Corp.: Unknown device 2668 (rev 03) Subsystem: Asustek Computer, Inc.: Unknown device 813d Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at cfdf4000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [70] #10 [0091] 00:1c.0 PCI bridge: Intel Corp. I/O Controller Hub PCI Express Port 0 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: e000-efff Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 00:1c.1 PCI bridge: Intel Corp. I/O Controller Hub PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02,
PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Hello, since the first version of 2.6.12-rc1 and mm[1-4] kernel I can't use any of my PCI-Express devices that worked with all 2.6.11.[1-6] kernels. It's a real odd right now. I have 25 computers with an Intel 925XE Chipset based motherboards and Intel 6xx CPU on it. So far it does not metter which vendor I choose (ASUS,ABIT,MSI etc.) the problem stay the same and spread all over.I tried to boot with pci=routeicq but it did not help to get one device working with any 2.6.12-rc1-xx kernel. As I mentioned before I tested it with on several (over 25 computer) with various motherboards (with ASUS,ABIT,MSI etc.) no luck. Its an 64bit system with [EMT64] and SMP/SMT and preempt enabled + cpufreq. My first look was on PCI Routingtable and I found a difference to 2.6.11.x working kernel: So far Thanks in advance and best regards //possible bug/problem PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 Boot video device is :04:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Can't get handler for :00:1b.0 --> why this happen ACPI: Can't get handler for :00:1f.3 --> it does not appear ACPI: Can't get handler for :04:00.0 --> on 2.6.11.x kernels. ACPI: Can't get handler for :02:00.0 --> - * - ACPI: Can't get handler for :01:09.0 --> - * - ACPI: Can't get handler for :01:0a.0 --> - * - //this looks like a garbage routing and handler table here ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 *4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15) //lspci -v output :00:00.0 Host bridge: Intel Corporation 925X/XE Memory Controller Hub (rev 0e) Subsystem: Intel Corporation: Unknown device 2580 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] #09 [0109] :00:01.0 PCI bridge: Intel Corporation 925X/XE PCI Express Root Port (rev 0e) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: d2f0-d7ff Prefetchable memory behind bridge: d800-dfff Expansion ROM at e000 [disabled] [size=4K] Capabilities: [88] #0d [] Capabilities: [80] Power Management version 2 Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [a0] #10 [0141] :00:1b.0 Class 0403: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 04) Subsystem: ASUSTeK Computer Inc.: Unknown device 813d Flags: bus master, fast devsel, latency 0, IRQ 169 Memory at d2cf4000 (64-bit, non-prefetchable) Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [70] #10 [0091] :00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: d000-dfff Expansion ROM at d000 [disabled] [size=4K] Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 :00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: d2e0-d2ef Expansion ROM at c000 [disabled] [size=4K] Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 :00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6 Flags: bus master, medium devsel, latency 0, IRQ 50 I/O ports at 9880 [size=32] :00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6
PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Hello, since the first version of 2.6.12-rc1 and mm[1-4] kernel I can't use any of my PCI-Express devices that worked with all 2.6.11.[1-6] kernels. It's a real odd right now. I have 25 computers with an Intel 925XE Chipset based motherboards and Intel 6xx CPU on it. So far it does not metter which vendor I choose (ASUS,ABIT,MSI etc.) the problem stay the same and spread all over.I tried to boot with pci=routeicq but it did not help to get one device working with any 2.6.12-rc1-xx kernel. As I mentioned before I tested it with on several (over 25 computer) with various motherboards (with ASUS,ABIT,MSI etc.) no luck. Its an 64bit system with [EMT64] and SMP/SMT and preempt enabled + cpufreq. My first look was on PCI Routingtable and I found a difference to 2.6.11.x working kernel: So far Thanks in advance and best regards //possible bug/problem PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 Boot video device is :04:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Can't get handler for :00:1b.0 -- why this happen ACPI: Can't get handler for :00:1f.3 -- it does not appear ACPI: Can't get handler for :04:00.0 -- on 2.6.11.x kernels. ACPI: Can't get handler for :02:00.0 -- - * - ACPI: Can't get handler for :01:09.0 -- - * - ACPI: Can't get handler for :01:0a.0 -- - * - //this looks like a garbage routing and handler table here ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 *4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15) //lspci -v output :00:00.0 Host bridge: Intel Corporation 925X/XE Memory Controller Hub (rev 0e) Subsystem: Intel Corporation: Unknown device 2580 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] #09 [0109] :00:01.0 PCI bridge: Intel Corporation 925X/XE PCI Express Root Port (rev 0e) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: d2f0-d7ff Prefetchable memory behind bridge: d800-dfff Expansion ROM at e000 [disabled] [size=4K] Capabilities: [88] #0d [] Capabilities: [80] Power Management version 2 Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [a0] #10 [0141] :00:1b.0 Class 0403: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 04) Subsystem: ASUSTeK Computer Inc.: Unknown device 813d Flags: bus master, fast devsel, latency 0, IRQ 169 Memory at d2cf4000 (64-bit, non-prefetchable) Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [70] #10 [0091] :00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: d000-dfff Expansion ROM at d000 [disabled] [size=4K] Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 :00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: d2e0-d2ef Expansion ROM at c000 [disabled] [size=4K] Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 :00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6 Flags: bus master, medium devsel, latency 0, IRQ 50 I/O ports at 9880 [size=32] :00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6
Re: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Michael Thonke napisa(a): Hello, since the first version of 2.6.12-rc1 and mm[1-4] kernel I can't use any of my PCI-Express devices that worked with all 2.6.11.[1-6] kernels. It's a real odd right now. I have 25 computers with an Intel 925XE Chipset based motherboards and Intel 6xx CPU on it. So far it does not metter which vendor I choose (ASUS,ABIT,MSI etc.) the problem stay the same and spread all over.I tried to boot with pci=routeicq but it did not help to get one device working with any 2.6.12-rc1-xx kernel. As I mentioned before I tested it with on several (over 25 computer) with various motherboards (with ASUS,ABIT,MSI etc.) no luck. Its an 64bit system with [EMT64] and SMP/SMT and preempt enabled + cpufreq. My first look was on PCI Routingtable and I found a difference to 2.6.11.x working kernel: I've got the same problem with i915 on Asus P5GDC V Deluxe Mainboard. This fragment of dmesg is from 2.6.12-rc1-mm4 kernel: PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 Boot video device is :00:02.0 PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Can't get handler for :00:02.0 ACPI: Can't get handler for :00:02.1 ACPI: Can't get handler for :00:1b.0 ACPI: Can't get handler for :00:1f.3 ACPI: Can't get handler for :02:00.0 ACPI: Can't get handler for :01:04.0 ACPI: Can't get handler for :01:0a.0 ACPI: Can't get handler for :01:0b.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 *4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: No ACPI bus support for 00:00 ACPI: No ACPI bus support for 00:01 ACPI: No ACPI bus support for 00:02 ACPI: No ACPI bus support for 00:03 ACPI: No ACPI bus support for 00:04 ACPI: No ACPI bus support for 00:05 ACPI: No ACPI bus support for 00:06 ACPI: No ACPI bus support for 00:07 ACPI: No ACPI bus support for 00:08 ACPI: No ACPI bus support for 00:09 ACPI: No ACPI bus support for 00:0a ACPI: No ACPI bus support for 00:0b ACPI: No ACPI bus support for 00:0c ACPI: No ACPI bus support for 00:0d ACPI: No ACPI bus support for 00:0e ACPI: No ACPI bus support for 00:0f ACPI: No ACPI bus support for 00:10 pnp: PnP ACPI: found 17 devices SCSI subsystem initialized LSPCI OUTPUT: 00:00.0 Host bridge: Intel Corp.: Unknown device 2580 (rev 04) Subsystem: Intel Corp.: Unknown device 2580 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] #09 [2109] 00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2582 (rev 04) (prog-if 00 [VGA]) Subsystem: Asustek Computer, Inc.: Unknown device 2582 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at cfc8 (32-bit, non-prefetchable) [size=512K] I/O ports at 9800 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at cfd8 (32-bit, non-prefetchable) [size=256K] Expansion ROM at unassigned [disabled] Capabilities: [d0] Power Management version 2 00:02.1 Display controller: Intel Corp.: Unknown device 2782 (rev 04) Subsystem: Asustek Computer, Inc.: Unknown device 2582 Flags: bus master, fast devsel, latency 0 Memory at cfd0 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 00:1b.0 Class 0403: Intel Corp.: Unknown device 2668 (rev 03) Subsystem: Asustek Computer, Inc.: Unknown device 813d Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at cfdf4000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [70] #10 [0091] 00:1c.0 PCI bridge: Intel Corp. I/O Controller Hub PCI Express Port 0 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: e000-efff Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 00:1c.1 PCI bridge: Intel Corp. I/O Controller Hub PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00,
Re: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
hello Jacek, its not related to the vendor so far we are :-) Maybe Andrew Morton or some other will read this. Because 2.6.12 should be a stable version not a flacky one. But what is wrong now on 2.6.12-rc1 **. It work flawlessly on 2.6.11.X kernels. Mebye we back that out :-) Greetz |Jacek Luczak schrieb: Michael Thonke napisa(a): Hello, since the first version of 2.6.12-rc1 and mm[1-4] kernel I can't use any of my PCI-Express devices that worked with all 2.6.11.[1-6] kernels. It's a real odd right now. I have 25 computers with an Intel 925XE Chipset based motherboards and Intel 6xx CPU on it. So far it does not metter which vendor I choose (ASUS,ABIT,MSI etc.) the problem stay the same and spread all over.I tried to boot with pci=routeicq but it did not help to get one device working with any 2.6.12-rc1-xx kernel. As I mentioned before I tested it with on several (over 25 computer) with various motherboards (with ASUS,ABIT,MSI etc.) no luck. Its an 64bit system with [EMT64] and SMP/SMT and preempt enabled + cpufreq. My first look was on PCI Routingtable and I found a difference to 2.6.11.x working kernel: I've got the same problem with i915 on Asus P5GDC V Deluxe Mainboard. This fragment of dmesg is from 2.6.12-rc1-mm4 kernel: PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 Boot video device is :00:02.0 PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Can't get handler for :00:02.0 ACPI: Can't get handler for :00:02.1 ACPI: Can't get handler for :00:1b.0 ACPI: Can't get handler for :00:1f.3 ACPI: Can't get handler for :02:00.0 ACPI: Can't get handler for :01:04.0 ACPI: Can't get handler for :01:0a.0 ACPI: Can't get handler for :01:0b.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 *4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init ACPI: No ACPI bus support for 00:00 ACPI: No ACPI bus support for 00:01 ACPI: No ACPI bus support for 00:02 ACPI: No ACPI bus support for 00:03 ACPI: No ACPI bus support for 00:04 ACPI: No ACPI bus support for 00:05 ACPI: No ACPI bus support for 00:06 ACPI: No ACPI bus support for 00:07 ACPI: No ACPI bus support for 00:08 ACPI: No ACPI bus support for 00:09 ACPI: No ACPI bus support for 00:0a ACPI: No ACPI bus support for 00:0b ACPI: No ACPI bus support for 00:0c ACPI: No ACPI bus support for 00:0d ACPI: No ACPI bus support for 00:0e ACPI: No ACPI bus support for 00:0f ACPI: No ACPI bus support for 00:10 pnp: PnP ACPI: found 17 devices SCSI subsystem initialized LSPCI OUTPUT: 00:00.0 Host bridge: Intel Corp.: Unknown device 2580 (rev 04) Subsystem: Intel Corp.: Unknown device 2580 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] #09 [2109] 00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2582 (rev 04) (prog-if 00 [VGA]) Subsystem: Asustek Computer, Inc.: Unknown device 2582 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at cfc8 (32-bit, non-prefetchable) [size=512K] I/O ports at 9800 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at cfd8 (32-bit, non-prefetchable) [size=256K] Expansion ROM at unassigned [disabled] Capabilities: [d0] Power Management version 2 00:02.1 Display controller: Intel Corp.: Unknown device 2782 (rev 04) Subsystem: Asustek Computer, Inc.: Unknown device 2582 Flags: bus master, fast devsel, latency 0 Memory at cfd0 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 00:1b.0 Class 0403: Intel Corp.: Unknown device 2668 (rev 03) Subsystem: Asustek Computer, Inc.: Unknown device 813d Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at cfdf4000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [70] #10 [0091] 00:1c.0 PCI bridge: Intel Corp. I/O Controller Hub PCI Express Port 0 (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: e000-efff Capabilities: [40] #10 [0141] Capabilities: [80] Message
Re: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
hello Michael :) This message: ACPI: No ACPI bus support for 00:00 means that acpi_get_bus_type() is unable to determinate bus type! Mayby someone forgot about PCI-E? Regards Jacek - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Hello Jacek, I finially got it working :-) my PCI-Express devices working now... I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia everything except the Marvell Yokon PCI-E device working. I hope Andrew will look into the mm-line to find the bug? Greets and Best regards |Jacek Luczak schrieb: hello Michael :) This message: ACPI: No ACPI bus support for 00:00 means that acpi_get_bus_type() is unable to determinate bus type! Mayby someone forgot about PCI-E? Regards Jacek - 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Michael Thonke napisa(a): Hello Jacek, I finially got it working :-) my PCI-Express devices working now... I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia everything except the Marvell Yokon PCI-E device working. I hope Andrew will look into the mm-line to find the bug? I've got Marvell Yukon 88E8053 GigE and it works fine with fixed (by myself :]) driver from syskonnect. If you wont I may send it to you! Jacek - 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/
Unusable/non working PCI-Express on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Hello, since the first version of 2.6.12-rc1 and mm[1-4] kernel I can't use any of my PCI-Express devices that work with all 2.6.11.[1-6] kernels. Its a real odd right now. I have 25 computers with an Intel 925XE Chipset and Intel 6xx CPU. It does not metter which vendor I choose the problem spread all over.I tried to boot with pci=routeicq but it did not help to get one device working ith 2.6.12-rc1-xx kernel. As I mentioned before I tested it with over 25 computer (with ASUS,ABIT,MSI etc.) no luck. Its an 64bit system [EMT64] and SMP/SMT enabled and preempt. My first look was on PCI Routingtable and what I found in difference to 2.6.11.x working kernel is that: Here I print the posssible bug/problem, lspci and dmesg output from kernel. So far Thanks in advance and best regards //possible bug/problem PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 Boot video device is :04:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Can't get handler for :00:1b.0 ACPI: Can't get handler for :00:1f.3 ACPI: Can't get handler for :04:00.0 ACPI: Can't get handler for :02:00.0 ACPI: Can't get handler for :01:09.0 ACPI: Can't get handler for :01:0a.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 *4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15) //lspci -v output :00:00.0 Host bridge: Intel Corporation 925X/XE Memory Controller Hub (rev 0e) Subsystem: Intel Corporation: Unknown device 2580 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] #09 [0109] :00:01.0 PCI bridge: Intel Corporation 925X/XE PCI Express Root Port (rev 0e) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: d2f0-d7ff Prefetchable memory behind bridge: d800-dfff Expansion ROM at e000 [disabled] [size=4K] Capabilities: [88] #0d [] Capabilities: [80] Power Management version 2 Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [a0] #10 [0141] :00:1b.0 Class 0403: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 04) Subsystem: ASUSTeK Computer Inc.: Unknown device 813d Flags: bus master, fast devsel, latency 0, IRQ 169 Memory at d2cf4000 (64-bit, non-prefetchable) Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [70] #10 [0091] :00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: d000-dfff Expansion ROM at d000 [disabled] [size=4K] Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 :00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: d2e0-d2ef Expansion ROM at c000 [disabled] [size=4K] Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 :00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6 Flags: bus master, medium devsel, latency 0, IRQ 50 I/O ports at 9880 [size=32] :00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6 Flags: bus master, medium devsel, latency 0, IRQ 233 I/O ports at 9c00 [size=32] :00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB
Unusable/non working PCI-Express on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Hello, since the first version of 2.6.12-rc1 and mm[1-4] kernel I can't use any of my PCI-Express devices that work with all 2.6.11.[1-6] kernels. Its a real odd right now. I have 25 computers with an Intel 925XE Chipset and Intel 6xx CPU. It does not metter which vendor I choose the problem spread all over.I tried to boot with pci=routeicq but it did not help to get one device working ith 2.6.12-rc1-xx kernel. As I mentioned before I tested it with over 25 computer (with ASUS,ABIT,MSI etc.) no luck. Its an 64bit system [EMT64] and SMP/SMT enabled and preempt. My first look was on PCI Routingtable and what I found in difference to 2.6.11.x working kernel is that: Here I print the posssible bug/problem, lspci and dmesg output from kernel. So far Thanks in advance and best regards //possible bug/problem PCI: Ignoring BAR0-3 of IDE controller :00:1f.1 Boot video device is :04:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Can't get handler for :00:1b.0 ACPI: Can't get handler for :00:1f.3 ACPI: Can't get handler for :04:00.0 ACPI: Can't get handler for :02:00.0 ACPI: Can't get handler for :01:09.0 ACPI: Can't get handler for :01:0a.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 *10 11 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKD] (IRQs *3 4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 *4 5 6 7 10 11 12 14 15) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled. ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11 12 14 15) //lspci -v output :00:00.0 Host bridge: Intel Corporation 925X/XE Memory Controller Hub (rev 0e) Subsystem: Intel Corporation: Unknown device 2580 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] #09 [0109] :00:01.0 PCI bridge: Intel Corporation 925X/XE PCI Express Root Port (rev 0e) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: d2f0-d7ff Prefetchable memory behind bridge: d800-dfff Expansion ROM at e000 [disabled] [size=4K] Capabilities: [88] #0d [] Capabilities: [80] Power Management version 2 Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [a0] #10 [0141] :00:1b.0 Class 0403: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 04) Subsystem: ASUSTeK Computer Inc.: Unknown device 813d Flags: bus master, fast devsel, latency 0, IRQ 169 Memory at d2cf4000 (64-bit, non-prefetchable) Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [70] #10 [0091] :00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: d000-dfff Expansion ROM at d000 [disabled] [size=4K] Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 :00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 04) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: d2e0-d2ef Expansion ROM at c000 [disabled] [size=4K] Capabilities: [40] #10 [0141] Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable+ Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 :00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 04) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6 Flags: bus master, medium devsel, latency 0, IRQ 50 I/O ports at 9880 [size=32] :00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 04) (prog-if 00 [UHCI]) Subsystem: ASUSTeK Computer Inc.: Unknown device 80a6 Flags: bus master, medium devsel, latency 0, IRQ 233 I/O ports at 9c00 [size=32] :00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB
Re: 2.6.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi,
On Friday, 25 of March 2005 01:49, you wrote:
]--snip--[
> > > I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and
> > > definitely required for S3). Unclear if it's ok for S4, so please try
> > > revert the patch.
> >
> > 2.6.11-rc1-mm1 with the patch reverted works fine. :-)
> So just remove the pci_enable/disable_device call in the driver makes
> the system work?
I'm a bit confused. :-) I'm not sure if the patch that I have reverted is
related
to pci_enable/disable_device. It's this one:
diff -Naru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
+++ b/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
@@ -72,10 +72,12 @@
u8 active; /* Current IRQ */
u8 edge_level; /* All IRQs */
u8 active_high_low;/* All IRQs */
- u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
+ u8 initialized:1;
+ u8 suspend_resume:1;
+ u8 reserved:6;
};
struct acpi_pci_link {
@@ -530,6 +532,10 @@
ACPI_FUNCTION_TRACE("acpi_pci_link_allocate");
+ if (link->irq.suspend_resume) {
+ acpi_pci_link_set(link, link->irq.active);
+ link->irq.suspend_resume = 0;
+ }
if (link->irq.initialized)
return_VALUE(0);
@@ -713,38 +719,24 @@
return_VALUE(result);
}
-
-static int
-acpi_pci_link_resume (
- struct acpi_pci_link*link)
-{
- ACPI_FUNCTION_TRACE("acpi_pci_link_resume");
-
- if (link->irq.active && link->irq.initialized)
- return_VALUE(acpi_pci_link_set(link, link->irq.active));
- else
- return_VALUE(0);
-}
-
-
static int
-irqrouter_resume(
- struct sys_device *dev)
+irqrouter_suspend(
+ struct sys_device *dev,
+ u32 state)
{
struct list_head*node = NULL;
struct acpi_pci_link*link = NULL;
- ACPI_FUNCTION_TRACE("irqrouter_resume");
+ ACPI_FUNCTION_TRACE("irqrouter_suspend");
list_for_each(node, _link.entries) {
-
link = list_entry(node, struct acpi_pci_link, node);
if (!link) {
ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Invalid link
context\n"));
continue;
}
-
- acpi_pci_link_resume(link);
+ if (link->irq.active && link->irq.initialized)
+ link->irq.suspend_resume = 1;
}
return_VALUE(0);
}
@@ -856,7 +848,7 @@
static struct sysdev_class irqrouter_sysdev_class = {
set_kset_name("irqrouter"),
-.resume = irqrouter_resume,
+.suspend = irqrouter_suspend,
};
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
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.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi,
On Friday, 25 of March 2005 01:49, you wrote:
]--snip--[
I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and
definitely required for S3). Unclear if it's ok for S4, so please try
revert the patch.
2.6.11-rc1-mm1 with the patch reverted works fine. :-)
So just remove the pci_enable/disable_device call in the driver makes
the system work?
I'm a bit confused. :-) I'm not sure if the patch that I have reverted is
related
to pci_enable/disable_device. It's this one:
diff -Naru a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
--- a/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
+++ b/drivers/acpi/pci_link.c 2005-03-24 04:57:27 -08:00
@@ -72,10 +72,12 @@
u8 active; /* Current IRQ */
u8 edge_level; /* All IRQs */
u8 active_high_low;/* All IRQs */
- u8 initialized;
u8 resource_type;
u8 possible_count;
u8 possible[ACPI_PCI_LINK_MAX_POSSIBLE];
+ u8 initialized:1;
+ u8 suspend_resume:1;
+ u8 reserved:6;
};
struct acpi_pci_link {
@@ -530,6 +532,10 @@
ACPI_FUNCTION_TRACE(acpi_pci_link_allocate);
+ if (link-irq.suspend_resume) {
+ acpi_pci_link_set(link, link-irq.active);
+ link-irq.suspend_resume = 0;
+ }
if (link-irq.initialized)
return_VALUE(0);
@@ -713,38 +719,24 @@
return_VALUE(result);
}
-
-static int
-acpi_pci_link_resume (
- struct acpi_pci_link*link)
-{
- ACPI_FUNCTION_TRACE(acpi_pci_link_resume);
-
- if (link-irq.active link-irq.initialized)
- return_VALUE(acpi_pci_link_set(link, link-irq.active));
- else
- return_VALUE(0);
-}
-
-
static int
-irqrouter_resume(
- struct sys_device *dev)
+irqrouter_suspend(
+ struct sys_device *dev,
+ u32 state)
{
struct list_head*node = NULL;
struct acpi_pci_link*link = NULL;
- ACPI_FUNCTION_TRACE(irqrouter_resume);
+ ACPI_FUNCTION_TRACE(irqrouter_suspend);
list_for_each(node, acpi_link.entries) {
-
link = list_entry(node, struct acpi_pci_link, node);
if (!link) {
ACPI_DEBUG_PRINT((ACPI_DB_ERROR, Invalid link
context\n));
continue;
}
-
- acpi_pci_link_resume(link);
+ if (link-irq.active link-irq.initialized)
+ link-irq.suspend_resume = 1;
}
return_VALUE(0);
}
@@ -856,7 +848,7 @@
static struct sysdev_class irqrouter_sysdev_class = {
set_kset_name(irqrouter),
-.resume = irqrouter_resume,
+.suspend = irqrouter_suspend,
};
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll Alice's Adventures in Wonderland
-
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.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
On Thu, 2005-03-24 at 21:42, Rafael J. Wysocki wrote: > Hi, > > On Thursday, 24 of March 2005 02:27, Li Shaohua wrote: > > On Thu, 2005-03-24 at 09:03, Len Brown wrote: > > > On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: > > > > Hi, > > > > > > > > On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: > > > > > Hi! > > > > > > > > > > > > > > Will this do it for the moment? > > > > > > > > > > > > > > > > Its certainly better. > > > > > > > > > > > > > > With the Len's patch applied I have to unload the modules: > > > > > > > > > > > > > > ohci_hcd > > > > > > > ehci_hcd > > > > > > > yenta_socket > > > > > > > > > > > > > > before suspend as each of them hangs the box solid during > > > either > > > > > > > suspend or resume. Moreover, when I tried to load the > > > ehci_hcd > > > > > > > module back after resume, it hanged the box solid too. > > > > > > Is this failure with suspend to RAM or to disk? > > > > > > How about if you try this patch? > > > > > > http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] > > > > > > patch -Rp1 from 2.6.12-rc1-mm1 and see if it stops being broken > > > or patch -Np1 to 2.6.12-rc and see if it starts being broken. > > > > > > This one removes an earlier attempt at resuming PCI links -- now > > > putting the onus on the drivers to be properly written > > > to release and acquire their interrupt for a successful > > > suspend/resume. > > > > > > > > > In theory, this is taken care of something like this: > > > driver.resume > > > pci_enable_device > > > pci_enable_device_bars > > > pcibios_enable_device > > > pcibios_enable_irq > > > acpi_pci_irq_enable > > > > > > but if the patch above makes a difference, then theory != practice:-) > > It looks like that. ;-) > > > > I'd believe that ohci_hcd and ehci_hcd are fragile since glancing > > > at their lengthy .resume routines it isn't immediately obvious > > > that they do this. But yenta_dev_resume has a pci_enable_device(), > > > so that failure may be less straightforward. > > > > > > cheers, > > > -Len > > > > > > ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled > > > boot, that would help -- for it will show if we're even using pci > > > interrupt links (and programming them) for these devices on this box. > > Yes, we changed the behavior of device suspend/resume. Every PCI device > > should call 'pci_disable_device' at suspend and call 'pci_enable_device' > > at resume. It fixes a bug and more important thing is it's safer (Eg. it > > disable interrupts, bus master and etc). > > I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and > > definitely required for S3). Unclear if it's ok for S4, so please try > > revert the patch. > > 2.6.11-rc1-mm1 with the patch reverted works fine. :-) So just remove the pci_enable/disable_device call in the driver makes the system work? Strange, I tried them on two laptops (one HP nx5000, and one Toshiba M2N), both works (no hang, and USB mouse works after S3/S4. I didn't try yenta, since I have no pc card) for S3/S4. Is it possible it's another bug or just because of different BIOS? Thanks, Shaohua - 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.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Thursday, 24 of March 2005 02:03, Len Brown wrote: > On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: ]-- snip --[ > I'd believe that ohci_hcd and ehci_hcd are fragile since glancing > at their lengthy .resume routines it isn't immediately obvious > that they do this. But yenta_dev_resume has a pci_enable_device(), > so that failure may be less straightforward. > > cheers, > -Len > > ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled > boot, that would help -- for it will show if we're even using pci > interrupt links (and programming them) for these devices on this box. The dmesg output is at: http://www.sisk.pl/kernel/050325/2.6.11-rc1-dmesg.log Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Thursday, 24 of March 2005 02:27, Li Shaohua wrote: > On Thu, 2005-03-24 at 09:03, Len Brown wrote: > > On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: > > > Hi, > > > > > > On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: > > > > Hi! > > > > > > > > > > > > Will this do it for the moment? > > > > > > > > > > > > > > Its certainly better. > > > > > > > > > > > > With the Len's patch applied I have to unload the modules: > > > > > > > > > > > > ohci_hcd > > > > > > ehci_hcd > > > > > > yenta_socket > > > > > > > > > > > > before suspend as each of them hangs the box solid during > > either > > > > > > suspend or resume. Moreover, when I tried to load the > > ehci_hcd > > > > > > module back after resume, it hanged the box solid too. > > > > Is this failure with suspend to RAM or to disk? > > > > How about if you try this patch? > > > > http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] > > > > patch -Rp1 from 2.6.12-rc1-mm1 and see if it stops being broken > > or patch -Np1 to 2.6.12-rc and see if it starts being broken. > > > > This one removes an earlier attempt at resuming PCI links -- now > > putting the onus on the drivers to be properly written > > to release and acquire their interrupt for a successful > > suspend/resume. > > > > > > In theory, this is taken care of something like this: > > driver.resume > > pci_enable_device > > pci_enable_device_bars > > pcibios_enable_device > > pcibios_enable_irq > > acpi_pci_irq_enable > > > > but if the patch above makes a difference, then theory != practice:-) It looks like that. ;-) > > I'd believe that ohci_hcd and ehci_hcd are fragile since glancing > > at their lengthy .resume routines it isn't immediately obvious > > that they do this. But yenta_dev_resume has a pci_enable_device(), > > so that failure may be less straightforward. > > > > cheers, > > -Len > > > > ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled > > boot, that would help -- for it will show if we're even using pci > > interrupt links (and programming them) for these devices on this box. > Yes, we changed the behavior of device suspend/resume. Every PCI device > should call 'pci_disable_device' at suspend and call 'pci_enable_device' > at resume. It fixes a bug and more important thing is it's safer (Eg. it > disable interrupts, bus master and etc). > I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and > definitely required for S3). Unclear if it's ok for S4, so please try > revert the patch. 2.6.11-rc1-mm1 with the patch reverted works fine. :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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.12-rc1-mm1: Kernel BUG at pci:389
Hi! > > You can't put -ENODEV into pci_power_t ... but maybe we should create > > PCI_ERROR and pass it in cases like this one? > That makes sense, please do it. Added: #define PCI_POWER_ERROR ((pci_power_t __force) -1) Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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.12-rc1-mm1: Kernel BUG at pci:389
Hi! You can't put -ENODEV into pci_power_t ... but maybe we should create PCI_ERROR and pass it in cases like this one? That makes sense, please do it. Added: #define PCI_POWER_ERROR ((pci_power_t __force) -1) Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Thursday, 24 of March 2005 02:27, Li Shaohua wrote: On Thu, 2005-03-24 at 09:03, Len Brown wrote: On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: Hi, On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: Hi! Will this do it for the moment? Its certainly better. With the Len's patch applied I have to unload the modules: ohci_hcd ehci_hcd yenta_socket before suspend as each of them hangs the box solid during either suspend or resume. Moreover, when I tried to load the ehci_hcd module back after resume, it hanged the box solid too. Is this failure with suspend to RAM or to disk? How about if you try this patch? http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] patch -Rp1 from 2.6.12-rc1-mm1 and see if it stops being broken or patch -Np1 to 2.6.12-rc and see if it starts being broken. This one removes an earlier attempt at resuming PCI links -- now putting the onus on the drivers to be properly written to release and acquire their interrupt for a successful suspend/resume. In theory, this is taken care of something like this: driver.resume pci_enable_device pci_enable_device_bars pcibios_enable_device pcibios_enable_irq acpi_pci_irq_enable but if the patch above makes a difference, then theory != practice:-) It looks like that. ;-) I'd believe that ohci_hcd and ehci_hcd are fragile since glancing at their lengthy .resume routines it isn't immediately obvious that they do this. But yenta_dev_resume has a pci_enable_device(), so that failure may be less straightforward. cheers, -Len ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled boot, that would help -- for it will show if we're even using pci interrupt links (and programming them) for these devices on this box. Yes, we changed the behavior of device suspend/resume. Every PCI device should call 'pci_disable_device' at suspend and call 'pci_enable_device' at resume. It fixes a bug and more important thing is it's safer (Eg. it disable interrupts, bus master and etc). I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and definitely required for S3). Unclear if it's ok for S4, so please try revert the patch. 2.6.11-rc1-mm1 with the patch reverted works fine. :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - 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.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Thursday, 24 of March 2005 02:03, Len Brown wrote: On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: ]-- snip --[ I'd believe that ohci_hcd and ehci_hcd are fragile since glancing at their lengthy .resume routines it isn't immediately obvious that they do this. But yenta_dev_resume has a pci_enable_device(), so that failure may be less straightforward. cheers, -Len ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled boot, that would help -- for it will show if we're even using pci interrupt links (and programming them) for these devices on this box. The dmesg output is at: http://www.sisk.pl/kernel/050325/2.6.11-rc1-dmesg.log Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - 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.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
On Thu, 2005-03-24 at 21:42, Rafael J. Wysocki wrote: Hi, On Thursday, 24 of March 2005 02:27, Li Shaohua wrote: On Thu, 2005-03-24 at 09:03, Len Brown wrote: On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: Hi, On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: Hi! Will this do it for the moment? Its certainly better. With the Len's patch applied I have to unload the modules: ohci_hcd ehci_hcd yenta_socket before suspend as each of them hangs the box solid during either suspend or resume. Moreover, when I tried to load the ehci_hcd module back after resume, it hanged the box solid too. Is this failure with suspend to RAM or to disk? How about if you try this patch? http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] patch -Rp1 from 2.6.12-rc1-mm1 and see if it stops being broken or patch -Np1 to 2.6.12-rc and see if it starts being broken. This one removes an earlier attempt at resuming PCI links -- now putting the onus on the drivers to be properly written to release and acquire their interrupt for a successful suspend/resume. In theory, this is taken care of something like this: driver.resume pci_enable_device pci_enable_device_bars pcibios_enable_device pcibios_enable_irq acpi_pci_irq_enable but if the patch above makes a difference, then theory != practice:-) It looks like that. ;-) I'd believe that ohci_hcd and ehci_hcd are fragile since glancing at their lengthy .resume routines it isn't immediately obvious that they do this. But yenta_dev_resume has a pci_enable_device(), so that failure may be less straightforward. cheers, -Len ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled boot, that would help -- for it will show if we're even using pci interrupt links (and programming them) for these devices on this box. Yes, we changed the behavior of device suspend/resume. Every PCI device should call 'pci_disable_device' at suspend and call 'pci_enable_device' at resume. It fixes a bug and more important thing is it's safer (Eg. it disable interrupts, bus master and etc). I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and definitely required for S3). Unclear if it's ok for S4, so please try revert the patch. 2.6.11-rc1-mm1 with the patch reverted works fine. :-) So just remove the pci_enable/disable_device call in the driver makes the system work? Strange, I tried them on two laptops (one HP nx5000, and one Toshiba M2N), both works (no hang, and USB mouse works after S3/S4. I didn't try yenta, since I have no pc card) for S3/S4. Is it possible it's another bug or just because of different BIOS? Thanks, Shaohua - 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.11-mm4 and 2.6.12-rc1-mm1
On Wednesday 23 March 2005 11:17, Andrew Morton wrote: > Borislav Petkov <[EMAIL PROTECTED]> wrote: > > On Thursday 17 March 2005 10:18, Andrew Morton wrote: > > > Borislav Petkov <[EMAIL PROTECTED]> wrote: > > > > Mar 17 09:19:28 zmei kernel: [4.109241] PM: Checking swsusp > > > > image. Mar 17 09:19:28 zmei kernel: [4.109244] PM: Resume from > > > > disk failed. Mar 17 09:19:28 zmei kernel: [4.112220] VFS: Mounted > > > > root (ext2 filesystem) readonly. Mar 17 09:19:28 zmei kernel: [ > > > > 4.112465] Freeing unused kernel memory: 188k freed Mar 17 09:19:28 > > > > zmei kernel: [ 4.142002] logips2pp: Detected unknown logitech mouse > > > > model 1 Mar 17 09:19:28 zmei kernel: [4.274620] input: PS/2 > > > > Logitech Mouse on isa0060/serio1 [EOF] > > > > <-- and here it stops waiting forever. What actually has to come > > > > next is the init process, i.e. something of the likes of: > > > > INIT version x.xx loading > > > > but it doesn't. And by the way, how do you debug this? serial > > > > console? > > > > > > Serial console would be useful. Do sysrq-P and sysrq-T provide any > > > info? - > > > > > > > > Hi Andrew, > > > > I've tried 2.6.12-rc1-mm1 today and it stops booting at the same point as > > 2.6.11-mm4. What might help is the info that rc1 boots just fine so it is > > something in the mm series that impedes the boot process. However, > > sysrq-P and sysrq-T do not provide anything - sysrq doesn't show any > > activity at all, i.e. it doesn't even print the usage info message. > > Infact, the keyboard is dead, it doesn't even turn on or off any lights > > (NumLock etc). > > > > Any ideas? (Additional printk's added manually, etc..) > > - Make sure that io-apic is enabled, boot with `nmi_watchdog=1'. no results. > - Make sure that CONFIG_DETECT_SOFTLOCKUP is enabled yep > - Add `initcall_debug' to the boot command line, see if that tells us > anything. nothing > - Disable CONFIG_DEBUG_PAGEALLOC, if it was enabled it was disabled > - Send me your .config. attached. > kgdb is the way to diagnose this one. Yeah, this is going to take a while. I've ordered an usb-to-serial converter for my laptop so that I can connect it to the desktop machine over the serial port and this is gonna be here next week so then I'll give kgdb a try. Regards, Boris. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc1-mm1 # Thu Mar 24 08:04:48 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_CLEAR_PAGES=y # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODE is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TI
Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389
On Tue, 2005-03-22 at 20:20, Pavel Machek wrote:
> Hi!
>
> > >> > Yes, but it is needed. There are many drivers, and they look at
> > >> > numerical value of PMSG_*. I'm proceeding in steps. I hopefully
> > killed
> > >> > all direct accesses to the constants, and will switch constants
> to
> > >> > something else... But that is going to be tommorow (need some
> > sleep).
> > >> The patches are going to acquire correct PCI device sleep state
> for
> > >> suspend/resume. We discussed the issue several months ago. My
> plan is
> > we
> > >> first introduce 'platform_pci_set_power_state', then merge the
> > >> 'platform_pci_choose_state' patch after Pavel's pm_message_t
> > conversion
> > >> finished. Maybe Len mislead my comments.
> > >>
> > >> Anyway for the callback, my intend is platform_pci_choose_state
> > accept
> > >> the pm_message_t parameter, and it return an 'int', since
> platform
> > >> method possibly failed and then pci_choose_state translate the
> return
> > >> value to pci_power_t.
> > >
> > >You can't just retype around like that. You may want it take
> > >pci_power_t * as an argument, and then return 0/-ENODEV or
> something
> > >like that. But you can't retype between int and pm_message_t...
> > No, taking pci_power_t as an argument is meaningless. For ACPI, we
> > should know the exact sleep state, pm_message_t will tell us. But
> I'm ok
> > to let it return a pci_power_t, and the failure case returns
> > -ENODEV.
>
> You can't put -ENODEV into pci_power_t ... but maybe we should create
> PCI_ERROR and pass it in cases like this one?
That makes sense, please do it.
>
> > >> > Could you just revert those two patches? First one is very
> > >> > wrong. Second one might be fixed, but... See comments below.
> > >> I think the platform_pci_set_power_state should be ok, did you
> see it
> > >> causes oops?
> > >
> > >No its just ugly and uses __force in "creative" way. That one can
> be
> > >recovered.
> > Do you mean this?
> >
> > > + static int state_conv[] = {
> > > + [0] = 0,
> > > + [1] = 1,
> > > + [2] = 2,
> > > + [3] = 3,
> > > + [4] = 3
> > > + };
> > > + int acpi_state = state_conv[(int __force) state];
> >
> > The table should be
> > [PCI_D0] = 0,
> >
> > I'm not sure, but then could we use state_conv[state] directly? It
> seems
>
> I think so. Of course it is wrong, but it is less wrong than forcing
> it to integer than index, without using macros at all.
>
> Or perhaps you should do
>
> switch (state) {
> case PCI_D0: ...
> }
>
> ...and handle default case somehow.
That's ok for me. I'll change it later.
Thanks,
Shaohua
-
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.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
On Thu, 2005-03-24 at 09:03, Len Brown wrote: > On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: > > Hi, > > > > On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: > > > Hi! > > > > > > > > > > Will this do it for the moment? > > > > > > > > > > > > Its certainly better. > > > > > > > > > > With the Len's patch applied I have to unload the modules: > > > > > > > > > > ohci_hcd > > > > > ehci_hcd > > > > > yenta_socket > > > > > > > > > > before suspend as each of them hangs the box solid during > either > > > > > suspend or resume. Moreover, when I tried to load the > ehci_hcd > > > > > module back after resume, it hanged the box solid too. > > Is this failure with suspend to RAM or to disk? > > How about if you try this patch? > > http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] > > patch -Rp1 from 2.6.12-rc1-mm and see if it stops being broken > or patch -Np1 to 2.6.12-rc and see if it starts being broken. > > This one removes an earlier attempt at resuming PCI links -- now > putting the onus on the drivers to be properly written > to release and acquire their interrupt for a successful > suspend/resume. > > > In theory, this is taken care of something like this: > driver.resume > pci_enable_device > pci_enable_device_bars > pcibios_enable_device > pcibios_enable_irq > acpi_pci_irq_enable > > but if the patch above makes a difference, then theory != practice:-) > > I'd believe that ohci_hcd and ehci_hcd are fragile since glancing > at their lengthy .resume routines it isn't immediately obvious > that they do this. But yenta_dev_resume has a pci_enable_device(), > so that failure may be less straightforward. > > cheers, > -Len > > ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled > boot, that would help -- for it will show if we're even using pci > interrupt links (and programming them) for these devices on this box. Yes, we changed the behavior of device suspend/resume. Every PCI device should call 'pci_disable_device' at suspend and call 'pci_enable_device' at resume. It fixes a bug and more important thing is it's safer (Eg. it disable interrupts, bus master and etc). I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and definitely required for S3). Unclear if it's ok for S4, so please try revert the patch. Thanks, Shaohua - 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.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: > Hi, > > On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: > > Hi! > > > > > > > > Will this do it for the moment? > > > > > > > > > > Its certainly better. > > > > > > > > With the Len's patch applied I have to unload the modules: > > > > > > > > ohci_hcd > > > > ehci_hcd > > > > yenta_socket > > > > > > > > before suspend as each of them hangs the box solid during either > > > > suspend or resume. Moreover, when I tried to load the ehci_hcd > > > > module back after resume, it hanged the box solid too. Is this failure with suspend to RAM or to disk? How about if you try this patch? http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] patch -Rp1 from 2.6.12-rc1-mm and see if it stops being broken or patch -Np1 to 2.6.12-rc and see if it starts being broken. This one removes an earlier attempt at resuming PCI links -- now putting the onus on the drivers to be properly written to release and acquire their interrupt for a successful suspend/resume. In theory, this is taken care of something like this: driver.resume pci_enable_device pci_enable_device_bars pcibios_enable_device pcibios_enable_irq acpi_pci_irq_enable but if the patch above makes a difference, then theory != practice:-) I'd believe that ohci_hcd and ehci_hcd are fragile since glancing at their lengthy .resume routines it isn't immediately obvious that they do this. But yenta_dev_resume has a pci_enable_device(), so that failure may be less straightforward. cheers, -Len ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled boot, that would help -- for it will show if we're even using pci interrupt links (and programming them) for these devices on this box. - 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.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: > Hi! > > > > > > Will this do it for the moment? > > > > > > > > Its certainly better. > > > > > > With the Len's patch applied I have to unload the modules: > > > > > > ohci_hcd > > > ehci_hcd > > > yenta_socket > > > > > > before suspend as each of them hangs the box solid during either > > > suspend or resume. Moreover, when I tried to load the ehci_hcd > > > module back after resume, it hanged the box solid too. > > > > This behavior is apparently caused by the call to pci_write_config_word() > > with > > pmcsr = 0 in drivers/pci/pci.c:pci_set_power_state(). > > > > Well, I don't think I can do anything more about it myself. :-) > > Can you just revert those two patches from Len, and see what happens? Reverting them doesn't change anything, so there's something else that breaks things, apparently. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi! > > > > Will this do it for the moment? > > > > > > Its certainly better. > > > > With the Len's patch applied I have to unload the modules: > > > > ohci_hcd > > ehci_hcd > > yenta_socket > > > > before suspend as each of them hangs the box solid during either > > suspend or resume. Moreover, when I tried to load the ehci_hcd > > module back after resume, it hanged the box solid too. > > This behavior is apparently caused by the call to pci_write_config_word() with > pmcsr = 0 in drivers/pci/pci.c:pci_set_power_state(). > > Well, I don't think I can do anything more about it myself. :-) Can you just revert those two patches from Len, and see what happens? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
On Tue, 2005-03-22 at 21:41 +0200, Indrek Kruusa wrote: > Lee Revell <[EMAIL PROTECTED]> wrote: > > > >/ On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote:/ > >/ > From: [EMAIL PROTECTED]/ > >/ > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel > panic when loading the EMU10K1 driver/ > >/ > / > >/ / > >/ This one is a real mystery. No one can reproduce it./ > > Not quite true. This bug was current till today in Mandrake's kernel, > but with 2.6.11-5mdk they managed to get rid of it. > The problem is not with loading the driver but when alsactl tries to > store/restore mixer settings. > Please, make sure to use "reply to all" when replying to LKML mail. I easily could have missed this. Do you have a link to the Mandrake bug report? If other people have been hitting this, they have not been updating the bug report: http://bugme.osdl.org/show_bug.cgi?id=4282 > I have tried again with 2.6.12-rc1-mm1 and it is still there (for > example the Gnome won't start due to this). > Below the oops part from messages. Does it work if you just blow away the old mixer settings rather than trying to restore them? Anyway, this might be fixed in ALSA CVS. Lee - 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.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Tuesday, 22 of March 2005 22:49, Rafael J. Wysocki wrote: > Hi, > > On Tuesday, 22 of March 2005 12:01, Pavel Machek wrote: > > Hi! > > > > > Will this do it for the moment? > > > > Its certainly better. > > With the Len's patch applied I have to unload the modules: > > ohci_hcd > ehci_hcd > yenta_socket > > before suspend as each of them hangs the box solid during either > suspend or resume. Moreover, when I tried to load the ehci_hcd > module back after resume, it hanged the box solid too. This behavior is apparently caused by the call to pci_write_config_word() with pmcsr = 0 in drivers/pci/pci.c:pci_set_power_state(). Well, I don't think I can do anything more about it myself. :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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 2.6.12-rc1-mm1 3/3] perfctr: 64-bit values in register descriptors
On Wed, 23 Mar 2005 14:34:30 +1100, David Gibson wrote:
>On Wed, Mar 23, 2005 at 04:00:03AM +0100, Mikael Pettersson wrote:
>> - : Change value fields in register descriptors
>> to 64 bits. This will be needed for ppc64, and ppc32 user-space
>> on ppc64 kernels, and may eventually also be needed on x86.
>> We could have different descriptor types for 32 and 64-bit
>> registers, but that just complicates things for no real benefit.
>>
>> Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
>
>Erm.. won't this stop i386 binaries working on an x86_64 kernel, since
>kernel and user will have different ideas of the alignment...?
Indeed it does. A brown paper bag occasion :-(
Andrew, please apply the following fix on top of the previous patch.
This has been tested with i386 binaries on an x86_64 kernel.
- : Change number fields in register descriptors to 64 bits.
Otherwise i386 binaries break on x86_64 kernels since the descriptors
get larger alignment and sizes on x86_64 than on i386.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
include/linux/perfctr.h |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -rupN linux-2.6.12-rc1-mm1.perfctr-update-common/include/linux/perfctr.h
linux-2.6.12-rc1-mm1.perfctr-update-common-fix/include/linux/perfctr.h
--- linux-2.6.12-rc1-mm1.perfctr-update-common/include/linux/perfctr.h
2005-03-23 20:59:47.0 +0100
+++ linux-2.6.12-rc1-mm1.perfctr-update-common-fix/include/linux/perfctr.h
2005-03-23 20:59:57.0 +0100
@@ -29,7 +29,7 @@ struct vperfctr_control {
/* common description of an arch-specific control register */
struct perfctr_cpu_reg {
- __u32 nr;
+ __u64 nr;
__u64 value;
};
-
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: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
> Lee Revell <[EMAIL PROTECTED]> wrote: > > > > On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote: > > > From: [EMAIL PROTECTED] > > > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when > > > loading the EMU10K1 driver > > > > > > > > This one is a real mystery. No one can reproduce it. > Not quite true. This bug was current till today in Mandrake's kernel, > but with 2.6.11-5mdk they managed to get rid of it. > The problem is not with loading the driver but when alsactl tries to store/restore > mixer settings. > I have tried again with 2.6.12-rc1-mm1 and it is still there (for example the > Gnome won't start due to this). > Below the oops part from messages. uhh...sorry about that noise. I misread your e-mail. > >/ From: [EMAIL PROTECTED]/ > >/ Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 and/ > >/ / > > This one is fixed in ALSA CVS. Here is the patch. I had this problem indeed and of course this patch fixed 2.6.12-rc1-mm1 for me. Thank you and sorry again, Indrek - 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.11-mm4 and 2.6.12-rc1-mm1
Borislav Petkov <[EMAIL PROTECTED]> wrote: > > On Thursday 17 March 2005 10:18, Andrew Morton wrote: > > Borislav Petkov <[EMAIL PROTECTED]> wrote: > > > Mar 17 09:19:28 zmei kernel: [4.109241] PM: Checking swsusp image. > > > Mar 17 09:19:28 zmei kernel: [4.109244] PM: Resume from disk failed. > > > Mar 17 09:19:28 zmei kernel: [4.112220] VFS: Mounted root (ext2 > > > filesystem) readonly. Mar 17 09:19:28 zmei kernel: [4.112465] Freeing > > > unused kernel memory: 188k freed Mar 17 09:19:28 zmei kernel: [ > > > 4.142002] logips2pp: Detected unknown logitech mouse model 1 Mar 17 > > > 09:19:28 zmei kernel: [4.274620] input: PS/2 Logitech Mouse on > > > isa0060/serio1 [EOF] > > > <-- and here it stops waiting forever. What actually has to come next is > > > the init process, i.e. something of the likes of: > > > INIT version x.xx loading > > > but it doesn't. And by the way, how do you debug this? serial console? > > > > Serial console would be useful. Do sysrq-P and sysrq-T provide any info? > > - > > > Hi Andrew, > > I've tried 2.6.12-rc1-mm1 today and it stops booting at the same point as > 2.6.11-mm4. What might help is the info that rc1 boots just fine so it is > something in the mm series that impedes the boot process. However, sysrq-P > and sysrq-T do not provide anything - sysrq doesn't show any activity at all, > i.e. it doesn't even print the usage info message. Infact, the keyboard is > dead, it doesn't even turn on or off any lights (NumLock etc). > > Any ideas? (Additional printk's added manually, etc..) > - Make sure that io-apic is enabled, boot with `nmi_watchdog=1'. - Make sure that CONFIG_DETECT_SOFTLOCKUP is enabled - Add `initcall_debug' to the boot command line, see if that tells us anything. - Disable CONFIG_DEBUG_PAGEALLOC, if it was enabled - Send me your .config. kgdb is the way to diagnose this one. - 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.11-mm4 and 2.6.12-rc1-mm1
On Thursday 17 March 2005 10:18, Andrew Morton wrote: > Borislav Petkov <[EMAIL PROTECTED]> wrote: > > Mar 17 09:19:28 zmei kernel: [4.109241] PM: Checking swsusp image. > > Mar 17 09:19:28 zmei kernel: [4.109244] PM: Resume from disk failed. > > Mar 17 09:19:28 zmei kernel: [4.112220] VFS: Mounted root (ext2 > > filesystem) readonly. Mar 17 09:19:28 zmei kernel: [4.112465] Freeing > > unused kernel memory: 188k freed Mar 17 09:19:28 zmei kernel: [ > > 4.142002] logips2pp: Detected unknown logitech mouse model 1 Mar 17 > > 09:19:28 zmei kernel: [4.274620] input: PS/2 Logitech Mouse on > > isa0060/serio1 [EOF] > > <-- and here it stops waiting forever. What actually has to come next is > > the init process, i.e. something of the likes of: > > INIT version x.xx loading > > but it doesn't. And by the way, how do you debug this? serial console? > > Serial console would be useful. Do sysrq-P and sysrq-T provide any info? > - Hi Andrew, I've tried 2.6.12-rc1-mm1 today and it stops booting at the same point as 2.6.11-mm4. What might help is the info that rc1 boots just fine so it is something in the mm series that impedes the boot process. However, sysrq-P and sysrq-T do not provide anything - sysrq doesn't show any activity at all, i.e. it doesn't even print the usage info message. Infact, the keyboard is dead, it doesn't even turn on or off any lights (NumLock etc). Any ideas? (Additional printk's added manually, etc..) Regards, Boris. - 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.11-mm4 and 2.6.12-rc1-mm1
On Thursday 17 March 2005 10:18, Andrew Morton wrote: Borislav Petkov [EMAIL PROTECTED] wrote: Mar 17 09:19:28 zmei kernel: [4.109241] PM: Checking swsusp image. Mar 17 09:19:28 zmei kernel: [4.109244] PM: Resume from disk failed. Mar 17 09:19:28 zmei kernel: [4.112220] VFS: Mounted root (ext2 filesystem) readonly. Mar 17 09:19:28 zmei kernel: [4.112465] Freeing unused kernel memory: 188k freed Mar 17 09:19:28 zmei kernel: [ 4.142002] logips2pp: Detected unknown logitech mouse model 1 Mar 17 09:19:28 zmei kernel: [4.274620] input: PS/2 Logitech Mouse on isa0060/serio1 [EOF] -- and here it stops waiting forever. What actually has to come next is the init process, i.e. something of the likes of: INIT version x.xx loading but it doesn't. And by the way, how do you debug this? serial console? Serial console would be useful. Do sysrq-P and sysrq-T provide any info? - snip Hi Andrew, I've tried 2.6.12-rc1-mm1 today and it stops booting at the same point as 2.6.11-mm4. What might help is the info that rc1 boots just fine so it is something in the mm series that impedes the boot process. However, sysrq-P and sysrq-T do not provide anything - sysrq doesn't show any activity at all, i.e. it doesn't even print the usage info message. Infact, the keyboard is dead, it doesn't even turn on or off any lights (NumLock etc). Any ideas? (Additional printk's added manually, etc..) Regards, Boris. - 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.11-mm4 and 2.6.12-rc1-mm1
Borislav Petkov [EMAIL PROTECTED] wrote: On Thursday 17 March 2005 10:18, Andrew Morton wrote: Borislav Petkov [EMAIL PROTECTED] wrote: Mar 17 09:19:28 zmei kernel: [4.109241] PM: Checking swsusp image. Mar 17 09:19:28 zmei kernel: [4.109244] PM: Resume from disk failed. Mar 17 09:19:28 zmei kernel: [4.112220] VFS: Mounted root (ext2 filesystem) readonly. Mar 17 09:19:28 zmei kernel: [4.112465] Freeing unused kernel memory: 188k freed Mar 17 09:19:28 zmei kernel: [ 4.142002] logips2pp: Detected unknown logitech mouse model 1 Mar 17 09:19:28 zmei kernel: [4.274620] input: PS/2 Logitech Mouse on isa0060/serio1 [EOF] -- and here it stops waiting forever. What actually has to come next is the init process, i.e. something of the likes of: INIT version x.xx loading but it doesn't. And by the way, how do you debug this? serial console? Serial console would be useful. Do sysrq-P and sysrq-T provide any info? - snip Hi Andrew, I've tried 2.6.12-rc1-mm1 today and it stops booting at the same point as 2.6.11-mm4. What might help is the info that rc1 boots just fine so it is something in the mm series that impedes the boot process. However, sysrq-P and sysrq-T do not provide anything - sysrq doesn't show any activity at all, i.e. it doesn't even print the usage info message. Infact, the keyboard is dead, it doesn't even turn on or off any lights (NumLock etc). Any ideas? (Additional printk's added manually, etc..) - Make sure that io-apic is enabled, boot with `nmi_watchdog=1'. - Make sure that CONFIG_DETECT_SOFTLOCKUP is enabled - Add `initcall_debug' to the boot command line, see if that tells us anything. - Disable CONFIG_DEBUG_PAGEALLOC, if it was enabled - Send me your .config. kgdb is the way to diagnose this one. - 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: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
Lee Revell [EMAIL PROTECTED] wrote: On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote: From: [EMAIL PROTECTED] Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver This one is a real mystery. No one can reproduce it. Not quite true. This bug was current till today in Mandrake's kernel, but with 2.6.11-5mdk they managed to get rid of it. The problem is not with loading the driver but when alsactl tries to store/restore mixer settings. I have tried again with 2.6.12-rc1-mm1 and it is still there (for example the Gnome won't start due to this). Below the oops part from messages. uhh...sorry about that noise. I misread your e-mail. / From: [EMAIL PROTECTED]/ / Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 and/ / / This one is fixed in ALSA CVS. Here is the patch. I had this problem indeed and of course this patch fixed 2.6.12-rc1-mm1 for me. Thank you and sorry again, Indrek - 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 2.6.12-rc1-mm1 3/3] perfctr: 64-bit values in register descriptors
On Wed, 23 Mar 2005 14:34:30 +1100, David Gibson wrote:
On Wed, Mar 23, 2005 at 04:00:03AM +0100, Mikael Pettersson wrote:
- linux/perfctr.h: Change value fields in register descriptors
to 64 bits. This will be needed for ppc64, and ppc32 user-space
on ppc64 kernels, and may eventually also be needed on x86.
We could have different descriptor types for 32 and 64-bit
registers, but that just complicates things for no real benefit.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
Erm.. won't this stop i386 binaries working on an x86_64 kernel, since
kernel and user will have different ideas of the alignment...?
Indeed it does. A brown paper bag occasion :-(
Andrew, please apply the following fix on top of the previous patch.
This has been tested with i386 binaries on an x86_64 kernel.
- linux/perfctr.h: Change number fields in register descriptors to 64 bits.
Otherwise i386 binaries break on x86_64 kernels since the descriptors
get larger alignment and sizes on x86_64 than on i386.
Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]
include/linux/perfctr.h |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -rupN linux-2.6.12-rc1-mm1.perfctr-update-common/include/linux/perfctr.h
linux-2.6.12-rc1-mm1.perfctr-update-common-fix/include/linux/perfctr.h
--- linux-2.6.12-rc1-mm1.perfctr-update-common/include/linux/perfctr.h
2005-03-23 20:59:47.0 +0100
+++ linux-2.6.12-rc1-mm1.perfctr-update-common-fix/include/linux/perfctr.h
2005-03-23 20:59:57.0 +0100
@@ -29,7 +29,7 @@ struct vperfctr_control {
/* common description of an arch-specific control register */
struct perfctr_cpu_reg {
- __u32 nr;
+ __u64 nr;
__u64 value;
};
-
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.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Tuesday, 22 of March 2005 22:49, Rafael J. Wysocki wrote: Hi, On Tuesday, 22 of March 2005 12:01, Pavel Machek wrote: Hi! Will this do it for the moment? Its certainly better. With the Len's patch applied I have to unload the modules: ohci_hcd ehci_hcd yenta_socket before suspend as each of them hangs the box solid during either suspend or resume. Moreover, when I tried to load the ehci_hcd module back after resume, it hanged the box solid too. This behavior is apparently caused by the call to pci_write_config_word() with pmcsr = 0 in drivers/pci/pci.c:pci_set_power_state(). Well, I don't think I can do anything more about it myself. :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - 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: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
On Tue, 2005-03-22 at 21:41 +0200, Indrek Kruusa wrote: Lee Revell [EMAIL PROTECTED] wrote: / On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote:/ / From: [EMAIL PROTECTED]/ / Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver/ / / / / / This one is a real mystery. No one can reproduce it./ Not quite true. This bug was current till today in Mandrake's kernel, but with 2.6.11-5mdk they managed to get rid of it. The problem is not with loading the driver but when alsactl tries to store/restore mixer settings. Please, make sure to use reply to all when replying to LKML mail. I easily could have missed this. Do you have a link to the Mandrake bug report? If other people have been hitting this, they have not been updating the bug report: http://bugme.osdl.org/show_bug.cgi?id=4282 I have tried again with 2.6.12-rc1-mm1 and it is still there (for example the Gnome won't start due to this). Below the oops part from messages. Does it work if you just blow away the old mixer settings rather than trying to restore them? Anyway, this might be fixed in ALSA CVS. Lee - 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.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi! Will this do it for the moment? Its certainly better. With the Len's patch applied I have to unload the modules: ohci_hcd ehci_hcd yenta_socket before suspend as each of them hangs the box solid during either suspend or resume. Moreover, when I tried to load the ehci_hcd module back after resume, it hanged the box solid too. This behavior is apparently caused by the call to pci_write_config_word() with pmcsr = 0 in drivers/pci/pci.c:pci_set_power_state(). Well, I don't think I can do anything more about it myself. :-) Can you just revert those two patches from Len, and see what happens? Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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.12-rc1-mm1: resume regression [update] (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: Hi, On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: Hi! Will this do it for the moment? Its certainly better. With the Len's patch applied I have to unload the modules: ohci_hcd ehci_hcd yenta_socket before suspend as each of them hangs the box solid during either suspend or resume. Moreover, when I tried to load the ehci_hcd module back after resume, it hanged the box solid too. Is this failure with suspend to RAM or to disk? How about if you try this patch? http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] patch -Rp1 from 2.6.12-rc1-mm and see if it stops being broken or patch -Np1 to 2.6.12-rc and see if it starts being broken. This one removes an earlier attempt at resuming PCI links -- now putting the onus on the drivers to be properly written to release and acquire their interrupt for a successful suspend/resume. In theory, this is taken care of something like this: driver.resume pci_enable_device pci_enable_device_bars pcibios_enable_device pcibios_enable_irq acpi_pci_irq_enable but if the patch above makes a difference, then theory != practice:-) I'd believe that ohci_hcd and ehci_hcd are fragile since glancing at their lengthy .resume routines it isn't immediately obvious that they do this. But yenta_dev_resume has a pci_enable_device(), so that failure may be less straightforward. cheers, -Len ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled boot, that would help -- for it will show if we're even using pci interrupt links (and programming them) for these devices on this box. - 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.12-rc1-mm1: resume regression [update] (was: Re:2.6.12-rc1-mm1: Kernel BUG at pci:389)
On Thu, 2005-03-24 at 09:03, Len Brown wrote: On Wed, 2005-03-23 at 18:49, Rafael J. Wysocki wrote: Hi, On Wednesday, 23 of March 2005 23:39, Pavel Machek wrote: Hi! Will this do it for the moment? Its certainly better. With the Len's patch applied I have to unload the modules: ohci_hcd ehci_hcd yenta_socket before suspend as each of them hangs the box solid during either suspend or resume. Moreover, when I tried to load the ehci_hcd module back after resume, it hanged the box solid too. Is this failure with suspend to RAM or to disk? How about if you try this patch? http://linux-acpi.bkbits.net:8080/to-akpm/[EMAIL PROTECTED] patch -Rp1 from 2.6.12-rc1-mm and see if it stops being broken or patch -Np1 to 2.6.12-rc and see if it starts being broken. This one removes an earlier attempt at resuming PCI links -- now putting the onus on the drivers to be properly written to release and acquire their interrupt for a successful suspend/resume. In theory, this is taken care of something like this: driver.resume pci_enable_device pci_enable_device_bars pcibios_enable_device pcibios_enable_irq acpi_pci_irq_enable but if the patch above makes a difference, then theory != practice:-) I'd believe that ohci_hcd and ehci_hcd are fragile since glancing at their lengthy .resume routines it isn't immediately obvious that they do this. But yenta_dev_resume has a pci_enable_device(), so that failure may be less straightforward. cheers, -Len ps. if point me to a full dmesg -s64000 from 2.6.12-rc1 acpi-enabled boot, that would help -- for it will show if we're even using pci interrupt links (and programming them) for these devices on this box. Yes, we changed the behavior of device suspend/resume. Every PCI device should call 'pci_disable_device' at suspend and call 'pci_enable_device' at resume. It fixes a bug and more important thing is it's safer (Eg. it disable interrupts, bus master and etc). I actually added such calls in uhci, ehci and yenta. It's ok for S3 (and definitely required for S3). Unclear if it's ok for S4, so please try revert the patch. Thanks, Shaohua - 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.12-rc1-mm1: Kernel BUG at pci:389
On Tue, 2005-03-22 at 20:20, Pavel Machek wrote:
Hi!
Yes, but it is needed. There are many drivers, and they look at
numerical value of PMSG_*. I'm proceeding in steps. I hopefully
killed
all direct accesses to the constants, and will switch constants
to
something else... But that is going to be tommorow (need some
sleep).
The patches are going to acquire correct PCI device sleep state
for
suspend/resume. We discussed the issue several months ago. My
plan is
we
first introduce 'platform_pci_set_power_state', then merge the
'platform_pci_choose_state' patch after Pavel's pm_message_t
conversion
finished. Maybe Len mislead my comments.
Anyway for the callback, my intend is platform_pci_choose_state
accept
the pm_message_t parameter, and it return an 'int', since
platform
method possibly failed and then pci_choose_state translate the
return
value to pci_power_t.
You can't just retype around like that. You may want it take
pci_power_t * as an argument, and then return 0/-ENODEV or
something
like that. But you can't retype between int and pm_message_t...
No, taking pci_power_t as an argument is meaningless. For ACPI, we
should know the exact sleep state, pm_message_t will tell us. But
I'm ok
to let it return a pci_power_t, and the failure case returns
-ENODEV.
You can't put -ENODEV into pci_power_t ... but maybe we should create
PCI_ERROR and pass it in cases like this one?
That makes sense, please do it.
Could you just revert those two patches? First one is very
wrong. Second one might be fixed, but... See comments below.
I think the platform_pci_set_power_state should be ok, did you
see it
causes oops?
No its just ugly and uses __force in creative way. That one can
be
recovered.
Do you mean this?
+ static int state_conv[] = {
+ [0] = 0,
+ [1] = 1,
+ [2] = 2,
+ [3] = 3,
+ [4] = 3
+ };
+ int acpi_state = state_conv[(int __force) state];
The table should be
[PCI_D0] = 0,
I'm not sure, but then could we use state_conv[state] directly? It
seems
I think so. Of course it is wrong, but it is less wrong than forcing
it to integer than index, without using macros at all.
Or perhaps you should do
switch (state) {
case PCI_D0: ...
}
...and handle default case somehow.
That's ok for me. I'll change it later.
Thanks,
Shaohua
-
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.11-mm4 and 2.6.12-rc1-mm1
On Wednesday 23 March 2005 11:17, Andrew Morton wrote: Borislav Petkov [EMAIL PROTECTED] wrote: On Thursday 17 March 2005 10:18, Andrew Morton wrote: Borislav Petkov [EMAIL PROTECTED] wrote: Mar 17 09:19:28 zmei kernel: [4.109241] PM: Checking swsusp image. Mar 17 09:19:28 zmei kernel: [4.109244] PM: Resume from disk failed. Mar 17 09:19:28 zmei kernel: [4.112220] VFS: Mounted root (ext2 filesystem) readonly. Mar 17 09:19:28 zmei kernel: [ 4.112465] Freeing unused kernel memory: 188k freed Mar 17 09:19:28 zmei kernel: [ 4.142002] logips2pp: Detected unknown logitech mouse model 1 Mar 17 09:19:28 zmei kernel: [4.274620] input: PS/2 Logitech Mouse on isa0060/serio1 [EOF] -- and here it stops waiting forever. What actually has to come next is the init process, i.e. something of the likes of: INIT version x.xx loading but it doesn't. And by the way, how do you debug this? serial console? Serial console would be useful. Do sysrq-P and sysrq-T provide any info? - snip Hi Andrew, I've tried 2.6.12-rc1-mm1 today and it stops booting at the same point as 2.6.11-mm4. What might help is the info that rc1 boots just fine so it is something in the mm series that impedes the boot process. However, sysrq-P and sysrq-T do not provide anything - sysrq doesn't show any activity at all, i.e. it doesn't even print the usage info message. Infact, the keyboard is dead, it doesn't even turn on or off any lights (NumLock etc). Any ideas? (Additional printk's added manually, etc..) - Make sure that io-apic is enabled, boot with `nmi_watchdog=1'. no results. - Make sure that CONFIG_DETECT_SOFTLOCKUP is enabled yep - Add `initcall_debug' to the boot command line, see if that tells us anything. nothing - Disable CONFIG_DEBUG_PAGEALLOC, if it was enabled it was disabled - Send me your .config. attached. kgdb is the way to diagnose this one. Yeah, this is going to take a while. I've ordered an usb-to-serial converter for my laptop so that I can connect it to the desktop machine over the serial port and this is gonna be here next week so then I'll give kgdb a try. Regards, Boris. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc1-mm1 # Thu Mar 24 08:04:48 2005 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_CLEAR_PAGES=y # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODE is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET_TIMER=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_SCHED_SMT=y CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set
Re: 2.6.12-rc1-mm1: hostap stack usage
(netdev added to cc:)
On Tue, Mar 22, 2005 at 05:33:40PM +0100, Adrian Bunk wrote:
> The stack usage in some files under drivers/net/wireless/hostap/ is
> too high.
Thanks; I'll fix these and submit a patch (or two) after some testing.
> drivers/net/wireless/hostap/hostap_ioctl.c:
>
> prism2_ioctl_giwaplist:
> struct sockaddr addr[IW_MAX_AP];
> struct iw_quality qual[IW_MAX_AP];
>
> 64 * (16 + 4) Bytes = 1280 Bytes
OK.
> prism2_ioctl_ethtool:
> struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO };
>
> 196 Bytes
This seems to be somewhat obsolete now since most drivers have moved to
use get_drvinfo of ethtool_ops; I'll do the same.
> __prism2_translate_scan:
> char buf[MAX_WPA_IE_LEN * 2 + 30];
>
> (64 * 2) + 30 Bytes = 158 Bytes
OK.
> drivers/net/wireless/hostap/hostap_cs.c:
>
> prism2_config:
> cisparse_t parse;
> u_char buf[64];
> config_info_t conf;
>
> The main offender seems to be "parse" (but I'm too lame counting how
> many bytes it's exactly) resulting in nearly 1 kB stack usage.
This is actually very common for PC Card drivers in the current kernel
tree.. I'll change Host AP to kmalloc this, but someone might consider
going through all *_cs.c drivers..
> drivers/net/wireless/hostap/hostap_plx.c:
>
> prism2_plx_check_cis:
> #define CIS_MAX_LEN 256
> u8 cis[CIS_MAX_LEN];
OK.
--
Jouni MalinenPGP id EFC895FA
-
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 2.6.12-rc1-mm1 3/3] perfctr: 64-bit values in register descriptors
On Wed, 23 Mar 2005 04:00:03 +0100 (MET) Mikael Pettersson <[EMAIL PROTECTED]>
wrote:
>
> diff -rupN linux-2.6.12-rc1-mm1/include/linux/perfctr.h
> linux-2.6.12-rc1-mm1.perfctr-update-common/include/linux/perfctr.h
> --- linux-2.6.12-rc1-mm1/include/linux/perfctr.h 2005-03-22
> 21:59:08.00000 +0100
> +++ linux-2.6.12-rc1-mm1.perfctr-update-common/include/linux/perfctr.h
> 2005-03-23 02:19:45.0 +0100
> @@ -27,10 +27,10 @@ struct vperfctr_control {
> #define VPERFCTR_CONTROL_RESUME 0x03
> #define VPERFCTR_CONTROL_CLEAR 0x04
>
> -/* common description of an arch-specific 32-bit control register */
> +/* common description of an arch-specific control register */
> struct perfctr_cpu_reg {
> __u32 nr;
> - __u32 value;
> + __u64 value;
> };
I don't know if you support 32 bit binaries on x86_64, but if you do (or
intend to), then this structure will need translating. The x86 compiler
aligns 64 bit quantities on 32 bit boundaries (as far as I am aware)
whereas (I am pretty sure) the x86_64 compiler aligns them to 64 bit
boundaries. This is fine for ppc/ppc64 as both align 64bit quantities on
64 bit boundaries.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpwzNfAAWatv.pgp
Description: PGP signature
Re: [PATCH 2.6.12-rc1-mm1 3/3] perfctr: 64-bit values in register descriptors
On Wed, Mar 23, 2005 at 04:00:03AM +0100, Mikael Pettersson wrote:
> - : Change value fields in register descriptors
> to 64 bits. This will be needed for ppc64, and ppc32 user-space
> on ppc64 kernels, and may eventually also be needed on x86.
> We could have different descriptor types for 32 and 64-bit
> registers, but that just complicates things for no real benefit.
>
> Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
Erm.. won't this stop i386 binaries working on an x86_64 kernel, since
kernel and user will have different ideas of the alignment...?
> include/linux/perfctr.h |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff -rupN linux-2.6.12-rc1-mm1/include/linux/perfctr.h
> linux-2.6.12-rc1-mm1.perfctr-update-common/include/linux/perfctr.h
> +++ linux-2.6.12-rc1-mm1.perfctr-update-common/include/linux/perfctr.h
> 2005-03-23 02:19:45.0 +0100
> @@ -27,10 +27,10 @@ struct vperfctr_control {
> #define VPERFCTR_CONTROL_RESUME 0x03
> #define VPERFCTR_CONTROL_CLEAR 0x04
>
> -/* common description of an arch-specific 32-bit control register */
> +/* common description of an arch-specific control register */
> struct perfctr_cpu_reg {
> __u32 nr;
> - __u32 value;
> + __u64 value;
> };
>
> /* state and control domain numbers
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
-
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/
[PATCH 2.6.12-rc1-mm1 2/3] perfctr: ppc32 fix and cleanups
ppc32 fix and cleanups:
- If check_ireset() fails, clear state->cstatus to undo any
settings check_control() may have left there.
- Eliminate power-of-two sizeof assumption in access_regs().
- Merge check_ireset() and setup_imode_start_values().
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
drivers/perfctr/ppc.c | 27 ---
1 files changed, 8 insertions(+), 19 deletions(-)
diff -rupN linux-2.6.12-rc1-mm1/drivers/perfctr/ppc.c
linux-2.6.12-rc1-mm1.perfctr-update-ppc/drivers/perfctr/ppc.c
--- linux-2.6.12-rc1-mm1/drivers/perfctr/ppc.c 2005-03-22 21:59:08.0
+0100
+++ linux-2.6.12-rc1-mm1.perfctr-update-ppc/drivers/perfctr/ppc.c
2005-03-23 02:16:26.0 +0100
@@ -573,7 +573,7 @@ unsigned int perfctr_cpu_identify_overfl
return pmc_mask;
}
-static inline int check_ireset(const struct perfctr_cpu_state *state)
+static inline int check_ireset(struct perfctr_cpu_state *state)
{
unsigned int nrctrs, i;
@@ -583,27 +583,15 @@ static inline int check_ireset(const str
unsigned int pmc = state->pmc[i].map;
if ((int)state->control.ireset[pmc] < 0) /* PPC-specific */
return -EINVAL;
- }
- return 0;
-}
-
-static inline void setup_imode_start_values(struct perfctr_cpu_state *state)
-{
- unsigned int cstatus, nrctrs, i;
-
- cstatus = state->cstatus;
- nrctrs = perfctr_cstatus_nrctrs(cstatus);
- for(i = perfctr_cstatus_nractrs(cstatus); i < nrctrs; ++i) {
- unsigned int pmc = state->pmc[i].map;
state->pmc[i].start = state->control.ireset[pmc];
}
+ return 0;
}
#else /* CONFIG_PERFCTR_INTERRUPT_SUPPORT */
static inline void perfctr_cpu_isuspend(struct perfctr_cpu_state *state) { }
static inline void perfctr_cpu_iresume(const struct perfctr_cpu_state *state)
{ }
-static inline int check_ireset(const struct perfctr_cpu_state *state) { return
0; }
-static inline void setup_imode_start_values(struct perfctr_cpu_state *state) {
}
+static inline int check_ireset(struct perfctr_cpu_state *state) { return 0; }
#endif /* CONFIG_PERFCTR_INTERRUPT_SUPPORT */
static int check_control(struct perfctr_cpu_state *state)
@@ -627,12 +615,13 @@ int perfctr_cpu_update_control(struct pe
if (err < 0)
return err;
err = check_ireset(state);
- if (err < 0)
+ if (err < 0) {
+ state->cstatus = 0;
return err;
+ }
state->cstatus |= perfctr_mk_cstatus(state->control.header.tsc_on,
state->control.header.nractrs,
state->control.header.nrictrs);
- setup_imode_start_values(state);
return 0;
}
@@ -672,10 +661,10 @@ static int access_regs(struct perfctr_cp
unsigned int i, nr_regs, *where;
int offset;
- if (argbytes & (sizeof(struct perfctr_cpu_reg) - 1))
+ nr_regs = argbytes / sizeof(struct perfctr_cpu_reg);
+ if (nr_regs * sizeof(struct perfctr_cpu_reg) != argbytes)
return -EINVAL;
regs = (struct perfctr_cpu_reg*)argp;
- nr_regs = argbytes / sizeof(struct perfctr_cpu_reg);
for(i = 0; i < nr_regs; ++i) {
offset = get_reg_offset(regs[i].nr);
-
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/
[PATCH 2.6.12-rc1-mm1 3/3] perfctr: 64-bit values in register descriptors
- : Change value fields in register descriptors
to 64 bits. This will be needed for ppc64, and ppc32 user-space
on ppc64 kernels, and may eventually also be needed on x86.
We could have different descriptor types for 32 and 64-bit
registers, but that just complicates things for no real benefit.
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
include/linux/perfctr.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -rupN linux-2.6.12-rc1-mm1/include/linux/perfctr.h
linux-2.6.12-rc1-mm1.perfctr-update-common/include/linux/perfctr.h
--- linux-2.6.12-rc1-mm1/include/linux/perfctr.h2005-03-22
21:59:08.0 +0100
+++ linux-2.6.12-rc1-mm1.perfctr-update-common/include/linux/perfctr.h
2005-03-23 02:19:45.0 +0100
@@ -27,10 +27,10 @@ struct vperfctr_control {
#define VPERFCTR_CONTROL_RESUME0x03
#define VPERFCTR_CONTROL_CLEAR 0x04
-/* common description of an arch-specific 32-bit control register */
+/* common description of an arch-specific control register */
struct perfctr_cpu_reg {
__u32 nr;
- __u32 value;
+ __u64 value;
};
/* state and control domain numbers
-
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/
[PATCH 2.6.12-rc1-mm1 1/3] perfctr: x86 fix and cleanups
Some small fixes and cleanups. The ppc64 code should be next,
but I'm waiting for David Gibson to look over and ACK the API
changes I've inflicted on his code first.
x86 fix and cleanups:
- finalise_backpatching() now exercises all control flow paths,
to ensure that calls in cloned control flows are backpatched properly.
This is needed for gcc-4.0.
- Eliminate power-of-two sizeof assumption in access_regs().
- Merge check_ireset() and setup_imode_start_values().
Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
drivers/perfctr/x86.c | 34 --
1 files changed, 12 insertions(+), 22 deletions(-)
diff -rupN linux-2.6.12-rc1-mm1/drivers/perfctr/x86.c
linux-2.6.12-rc1-mm1.perfctr-update-x86/drivers/perfctr/x86.c
--- linux-2.6.12-rc1-mm1/drivers/perfctr/x86.c 2005-03-22 21:59:08.0
+0100
+++ linux-2.6.12-rc1-mm1.perfctr-update-x86/drivers/perfctr/x86.c
2005-03-23 02:18:14.0 +0100
@@ -1018,7 +1018,7 @@ unsigned int perfctr_cpu_identify_overfl
return pmc_mask;
}
-static inline int check_ireset(const struct perfctr_cpu_state *state)
+static inline int check_ireset(struct perfctr_cpu_state *state)
{
unsigned int nrctrs, i;
@@ -1028,27 +1028,15 @@ static inline int check_ireset(const str
unsigned int pmc = state->pmc[i].map & P4_MASK_FAST_RDPMC;
if ((int)state->control.ireset[pmc] >= 0)
return -EINVAL;
- }
- return 0;
-}
-
-static inline void setup_imode_start_values(struct perfctr_cpu_state *state)
-{
- unsigned int cstatus, nrctrs, i;
-
- cstatus = state->cstatus;
- nrctrs = perfctr_cstatus_nrctrs(cstatus);
- for(i = perfctr_cstatus_nractrs(cstatus); i < nrctrs; ++i) {
- unsigned int pmc = state->pmc[i].map & P4_MASK_FAST_RDPMC;
state->pmc[i].start = state->control.ireset[pmc];
}
+ return 0;
}
#else /* CONFIG_X86_LOCAL_APIC */
static inline void perfctr_cpu_isuspend(struct perfctr_cpu_state *state) { }
static inline void perfctr_cpu_iresume(const struct perfctr_cpu_state *state)
{ }
-static inline int check_ireset(const struct perfctr_cpu_state *state) { return
0; }
-static inline void setup_imode_start_values(struct perfctr_cpu_state *state) {
}
+static inline int check_ireset(struct perfctr_cpu_state *state) { return 0; }
#endif /* CONFIG_X86_LOCAL_APIC */
static int (*check_control)(struct perfctr_cpu_state*, int);
@@ -1073,7 +1061,6 @@ int perfctr_cpu_update_control(struct pe
state->cstatus = perfctr_mk_cstatus(state->control.header.tsc_on,
state->control.header.nractrs,
state->control.header.nrictrs);
- setup_imode_start_values(state);
return 0;
}
@@ -1135,10 +1122,10 @@ static int access_regs(struct perfctr_cp
unsigned int i, nr_regs, *where;
int offset;
- if (argbytes & (sizeof(struct perfctr_cpu_reg) - 1))
+ nr_regs = argbytes / sizeof(struct perfctr_cpu_reg);
+ if (nr_regs * sizeof(struct perfctr_cpu_reg) != argbytes)
return -EINVAL;
regs = (struct perfctr_cpu_reg*)argp;
- nr_regs = argbytes / sizeof(struct perfctr_cpu_reg);
for(i = 0; i < nr_regs; ++i) {
offset = get_reg_offset(regs[i].nr);
@@ -1264,10 +1251,13 @@ static void __init finalise_backpatching
cache = get_cpu_cache();
memset(cache, 0, sizeof *cache);
memset(, 0, sizeof state);
- state.cstatus =
- (perfctr_info.cpu_features & PERFCTR_FEATURE_PCINT)
- ? __perfctr_mk_cstatus(0, 1, 0, 0)
- : 0;
+ if (perfctr_info.cpu_features & PERFCTR_FEATURE_PCINT) {
+ state.cstatus = __perfctr_mk_cstatus(0, 1, 0, 0);
+ perfctr_cpu_sample();
+ perfctr_cpu_resume();
+ perfctr_cpu_suspend();
+ }
+ state.cstatus = 0;
perfctr_cpu_sample();
perfctr_cpu_resume();
perfctr_cpu_suspend();
-
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.12-rc1-mm1: resume regression (was: Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389)
Hi, On Tuesday, 22 of March 2005 12:01, Pavel Machek wrote: > Hi! > > > Will this do it for the moment? > > Its certainly better. With the Len's patch applied I have to unload the modules: ohci_hcd ehci_hcd yenta_socket before suspend as each of them hangs the box solid during either suspend or resume. Moreover, when I tried to load the ehci_hcd module back after resume, it hanged the box solid too. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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.12-rc1-mm1: REISER4_FS <-> 4KSTACKS
Adrian Bunk wrote: >On Tue, Mar 22, 2005 at 09:50:14AM -0800, Hans Reiser wrote: > > > >>All of my technical arguments on this topic were nicely obliterated by >>Andrew. The only real reason remaining (that I know of) is that I want >>to first eliminate all things which are a barrier to inclusion before >>dealing with this because it requires man hours to fix it. If you want >>to send us a cleanup patch that fixes it, I would be grateful for your >>time donatioin. >> >> > >My plan is to send a patch to Andrew that unconditionally enables >4KSTACKS for shaking out the last bugs before possibly removing >8 kB stacks completely. > >I don't know whether this is barrier to inclusion, but this will make >reiser4 unavailable on i386... > > > >>Hans >> >> > >cu >Adrian > > > Sigh. Could you wait a few weeks until we have done all the other things, and then I can have Vladimir work with you on it? - 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: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
Lee Revell <[EMAIL PROTECTED]> wrote: > >/ On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote:/ >/ > From: [EMAIL PROTECTED]/ >/ > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver/ >/ > / >/ / >/ This one is a real mystery. No one can reproduce it./ Not quite true. This bug was current till today in Mandrake's kernel, but with 2.6.11-5mdk they managed to get rid of it. The problem is not with loading the driver but when alsactl tries to store/restore mixer settings. I have tried again with 2.6.12-rc1-mm1 and it is still there (for example the Gnome won't start due to this). Below the oops part from messages. thanks, Indrek Mar 22 21:05:21 bedroom alsa: succeeded Mar 22 21:05:21 bedroom kernel: Unable to handle kernel NULL pointer dereference at virtual address 000c Mar 22 21:05:21 bedroom kernel: printing eip: Mar 22 21:05:21 bedroom kernel: dfa929e8 Mar 22 21:05:21 bedroom kernel: *pde = Mar 22 21:05:21 bedroom kernel: Oops: [#1] Mar 22 21:05:21 bedroom kernel: SMP Mar 22 21:05:21 bedroom kernel: Modules linked in: snd_pcm_oss snd_mixer_oss snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore af_packet eth1394 e100 mii ide_cd ohci1394 ieee1394 nls_iso8859_15 nls_cp850 vfat fat intel_agp agpgart hw_random emu10k1_gp gameport ata_piix libata ehci_hcd uhci_hcd usbcore evdev Mar 22 21:05:21 bedroom kernel: CPU:0 Mar 22 21:05:21 bedroom kernel: EIP: 0060:[pg0+527297000/1069851648]Not tainted VLI Mar 22 21:05:21 bedroom kernel: EIP:0060:[]Not tainted VLI Mar 22 21:05:21 bedroom kernel: EFLAGS: 00010002 (2.6.12-r1m1) Mar 22 21:05:21 bedroom kernel: EIP is at snd_emu10k1_efx_send_routing_put+0x98/0xd5 [snd_emu10k1] Mar 22 21:05:21 bedroom kernel: eax: ebx: dd6cb1a8 ecx: 000c edx: 0004 Mar 22 21:05:21 bedroom kernel: esi: 0004 edi: ebp: dd6ca000 esp: dce73ed4 Mar 22 21:05:21 bedroom kernel: ds: 007b es: 007b ss: 0068 Mar 22 21:05:21 bedroom kernel: Process alsactl (pid: 5019, threadinfo=dce72000 task=decaa550) Mar 22 21:05:21 bedroom kernel: Stack: dd6ca508 000f 0001 0246 ddc3c14c Mar 22 21:05:21 bedroom kernel:ddfe9200 de1a0440 ddc3c000 dfa18e30 ddfe9200 de1a0400 Mar 22 21:05:21 bedroom kernel: ddfe9200 c01b845c ddfe9200 fff3 decc1180 de1a0400 bf886950 Mar 22 21:05:21 bedroom kernel: Call Trace: Mar 22 21:05:21 bedroom kernel: [pg0+526798384/1069851648] snd_ctl_elem_write+0x126/0x177 [snd] Mar 22 21:05:21 bedroom kernel: [] snd_ctl_elem_write+0x126/0x177 [snd] Mar 22 21:05:21 bedroom kernel: [copy_from_user+70/126] copy_from_user+0x46/0x7e Mar 22 21:05:21 bedroom kernel: [] copy_from_user+0x46/0x7e Mar 22 21:05:21 bedroom kernel: [pg0+526798563/1069851648] snd_ctl_elem_write_user+0x62/0xaf [snd] Mar 22 21:05:21 bedroom kernel: [] snd_ctl_elem_write_user+0x62/0xaf [snd] Mar 22 21:05:21 bedroom kernel: [do_ioctl+154/169] do_ioctl+0x9a/0xa9 Mar 22 21:05:21 bedroom kernel: [] do_ioctl+0x9a/0xa9 Mar 22 21:05:21 bedroom kernel: [vfs_ioctl+101/481] vfs_ioctl+0x65/0x1e1 Mar 22 21:05:21 bedroom kernel: [] vfs_ioctl+0x65/0x1e1 Mar 22 21:05:21 bedroom kernel: [sys_ioctl+69/109] sys_ioctl+0x45/0x6d Mar 22 21:05:21 bedroom kernel: [] sys_ioctl+0x45/0x6d Mar 22 21:05:21 bedroom kernel: [sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75 Mar 22 21:05:21 bedroom kernel: [] sysenter_past_esp+0x54/0x75 Mar 22 21:05:21 bedroom kernel: Code: 24 10 23 4c 90 44 0f b6 04 13 39 c8 74 0b 88 0c 13 c7 44 24 14 01 00 00 00 83 c2 01 39 f2 7c da 8b 44 24 14 85 c0 74 0b 8b 43 38 <8b> 44 b8 0c 85 c0 75 19 8b 44 24 0c 8b 54 24 18 e8 c9 3c 83 e0 - 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.12-rc1-mm1: REISER4_FS <-> 4KSTACKS
[ Pruned Hans from Cc: list] On Tue, 22 March 2005 20:21:22 +0100, Adrian Bunk wrote: > > My plan is to send a patch to Andrew that unconditionally enables > 4KSTACKS for shaking out the last bugs before possibly removing > 8 kB stacks completely. In that case you might find this output relevant. It was generated for 2.6.11 (no -mm). Without recursions I cannot find a single code path chewing up 3k or more, so any bugs will likely be somewhere in this list. WARNING: trivial recursion detected: 120 find_in_devfs WARNING: trivial recursion detected: 0 apm_console_blank WARNING: trivial recursion detected: 0 unregister_proc_table WARNING: trivial recursion detected: 0 register_proc_table WARNING: recursion detected: 0 handle_stop_signal 128 do_notify_parent_cldstop 0 __group_send_sig_info WARNING: trivial recursion detected: 12 __vmalloc WARNING: trivial recursion detected: 0 blkdev_put WARNING: trivial recursion detected: 28 remove_tree WARNING: trivial recursion detected: 20 find_tree_dqentry WARNING: trivial recursion detected: 36 do_insert_tree WARNING: recursion detected: 16 affs_get_extblock_slow 0 affs_get_extblock WARNING: trivial recursion detected: 12 _devfs_walk_path WARNING: trivial recursion detected: 20 _devfs_unregister WARNING: trivial recursion detected: 20 ext2_free_branches WARNING: trivial recursion detected: 24 ext3_free_branches WARNING: trivial recursion detected: 48 vxfs_bmap_indir WARNING: trivial recursion detected: 28 jffs_print_tree WARNING: trivial recursion detected: 48 dbAdjCtl WARNING: recursion detected: 0 lmGCwrite 16 lbmWrite 16 lbmStartIO 16 lbmIODone 12 lmPostGC WARNING: recursion detected: 16 lbmWrite 16 lbmStartIO 16 lbmIODone 12 lmPostGC WARNING: trivial recursion detected: 12 free_branches WARNING: trivial recursion detected: 12 free_branches WARNING: recursion detected: 0 unhash_stateowner 0 release_stateid 0 release_stateid_lockowner 0 release_stateowner WARNING: trivial recursion detected: 44 __ntfs_bitmap_set_bits_in_run WARNING: trivial recursion detected: 60 __ntfs_cluster_free WARNING: recursion detected: 0 journal_join 60 do_journal_begin_r WARNING: recursion detected: 28 flush_commit_list 12 flush_older_commits WARNING: recursion detected: 40 flush_journal_list 0 flush_older_journal_lists WARNING: trivial recursion detected: 16 free_branches WARNING: trivial recursion detected: 40 __udf_read_inode WARNING: trivial recursion detected: 16 udf_load_logicalvolint WARNING: trivial recursion detected: 44 xfs_attr_node_inactive WARNING: trivial recursion detected: 24 xfs_bmap_count_tree WARNING: recursion detected: 56 xfs_map_unwritten 60 xfs_convert_page WARNING: trivial recursion detected: 44 qsort WARNING: trivial recursion detected: 20 acpi_os_derive_pci_id_2 WARNING: trivial recursion detected: 32 acpi_ex_dump_operand WARNING: trivial recursion detected: 0 aligned_kmalloc WARNING: recursion detected: 0 set_dor 0 floppy_release_irq_and_dma WARNING: trivial recursion detected: 36 xd_command WARNING: trivial recursion detected: 80 pkt_make_request WARNING: recursion detected: 12 read_subcode 12 check_drive_status WARNING: recursion detected: 448 extract_entropy 0 xfer_secondary_pool WARNING: recursion detected: 20 ipmi_heartbeat 0 ipmi_set_timeout WARNING: recursion detected: 16 hd_request 16 reset_hd WARNING: trivial recursion detected: 60 ide_timing_compute WARNING: trivial recursion detected: 60 ide_timing_compute WARNING: trivial recursion detected: 60 ide_timing_compute WARNING: trivial recursion detected: 332 idetape_space_over_filemarks WARNING: trivial recursion detected: 40 nodemgr_process_unit_directory WARNING: trivial recursion detected: 28 sbp2_parse_unit_directory WARNING: trivial recursion detected: 16 protocol_message_2_pars WARNING: trivial recursion detected: 16 pars_2_message WARNING: trivial recursion detected: 0 message_2_pars WARNING: recursion detected: 0 plci_remove 0 plci_remove_check 0 CodecIdCheck WARNING: recursion detected: 24 Amd7930_new_ph 0 Amd7930_get_state WARNING: trivial recursion detected: 12 isdn_net_realrm WARNING: trivial recursion detected: 112 isdn_net_hangup WARNING: recursion detected: 52 isdn_tty_modem_result 116 isdn_tty_cmd_ATA WARNING: recursion detected: 0 isdn_wildmat 0 isdn_star WARNING: trivial recursion detected: 112 icn_stopcard WARNING: trivial recursion detected: 76
Re: 2.6.12-rc1-mm1: REISER4_FS <-> 4KSTACKS
On Tue, Mar 22, 2005 at 09:50:14AM -0800, Hans Reiser wrote: > All of my technical arguments on this topic were nicely obliterated by > Andrew. The only real reason remaining (that I know of) is that I want > to first eliminate all things which are a barrier to inclusion before > dealing with this because it requires man hours to fix it. If you want > to send us a cleanup patch that fixes it, I would be grateful for your > time donatioin. My plan is to send a patch to Andrew that unconditionally enables 4KSTACKS for shaking out the last bugs before possibly removing 8 kB stacks completely. I don't know whether this is barrier to inclusion, but this will make reiser4 unavailable on i386... > Hans cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.12-rc1-mm1: REISER4_FS <-> 4KSTACKS
On Tue, Mar 22, 2005 at 07:56:05PM +0100, Jörn Engel wrote: > On Tue, 22 March 2005 18:13:40 +0100, Adrian Bunk wrote: > > > > REISER4_FS is the only option with a dependency on !4KSTACKS which is > > bad since 8 kB stacks on i386 won't stay forever. > > > > Could fix the problems with 4 kB stacks? > > > > Running > > > > make checkstacks | grep reiser4 > > > > inside te kernel sources after compiling gives you hints where problems > > might come from. > > Actually, I've run the Big Ol' checkstack program on reiser4 once. > Without recursions, the code is well below 3k, but some of the > recursions look a bit daunting. Here is the relevant output: >... > 404 jnode_flush >... > 460 rename_hashed >... > 224 coord_by_key >... These would have been missed by the grep I suggested due to the missing reiser4_ prefix. > 208 locks_remove_flock >... That seems to be a generic issue in fs/locks.c . It seems this is the "struct file_lock fl"? > Jörn cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.12-rc1-mm1: REISER4_FS <-> 4KSTACKS
On Tue, 22 March 2005 19:56:05 +0100, Jörn Engel wrote: > > stackframes for call path too long (2808): Maybe I should change the output. "too long" simply means "user gave a stack limit below this value". 2808 bytes is the most expensive path for reiser4 without recursion, so my limit was 2800. ;) Jörn -- When people work hard for you for a pat on the back, you've got to give them that pat. -- Robert Heinlein - 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.12-rc1-mm1: REISER4_FS <-> 4KSTACKS
On Tue, 22 March 2005 18:13:40 +0100, Adrian Bunk wrote: > > REISER4_FS is the only option with a dependency on !4KSTACKS which is > bad since 8 kB stacks on i386 won't stay forever. > > Could fix the problems with 4 kB stacks? > > Running > > make checkstacks | grep reiser4 > > inside te kernel sources after compiling gives you hints where problems > might come from. Actually, I've run the Big Ol' checkstack program on reiser4 once. Without recursions, the code is well below 3k, but some of the recursions look a bit daunting. Here is the relevant output: WARNING: recursion detected: 8 jload_gfp 36 eflush_del 24 eflush_free 36 ef_free_block 0 reiser4_dealloc_block 28 reiser4_dealloc_blocks 0 sa_dealloc_blocks 32 dealloc_blocks_bitmap 36 load_and_lock_bnode 20 prepare_bnode WARNING: recursion detected: 8 zload 16 zload_ra 68 formatted_readahead 0 reiser4_get_right_neighbor 264 reiser4_get_neighbor 108 renew_neighbor 44 renew_sibling_link 48 far_next_coord WARNING: recursion detected: 32 reiser4_grab_space 12 txnmgr_force_commit_all 0 force_commit_atom_nolock 4 txn_restart_current 8 txn_restart 8 txn_end 36 commit_txnh 16 try_commit_txnh 28 commit_current_atom 24 flush_current_atom 404 jnode_flush 88 alloc_pos_and_ancestors 96 alloc_one_ancestor 20 allocate_znode 32 allocate_znode_loaded 84 allocate_znode_update 0 reiser4_alloc_block 24 reiser4_alloc_blocks stackframes for call path too long (2808): size function 460 rename_hashed 112 safe_link_add 108 store_black_box 52 insert_by_key 224 coord_by_key 60 handle_eottl 124 carry 88 lock_carry_node 72 add_tree_root 8 zload 16 zload_ra 68 formatted_readahead 264 reiser4_get_neighbor 0 reiser4_get_parent 28 reiser4_get_parent_flags 8 longterm_unlock_znode 20 forget_znode 8 uncapture_page 36 eflush_del 24 eflush_free 28 reiser4_dealloc_blocks 32 dealloc_blocks_bitmap 20 jinit_new 20 jnode_get_page_locked 16 find_or_create_page 24 add_to_page_cache_lru 24 add_to_page_cache 8 radix_tree_preload 12 kmem_cache_alloc 52 __alloc_pages 8 out_of_memory 8 mmput 16 exit_aio 20 __put_ioctx 40 do_munmap 36 split_vma 40 vma_adjust 8 fput 8 __fput 208 locks_remove_flock 20 lease_modify 16 panic 8 bust_spinlocks 4 unblank_screen 24 do_unblank_screen 20 redraw_screen 16 clear_selection 24 invert_screen 8 printk 100 vprintk 20 vscnprintf 40 vsnprintf 100 number Jörn -- People will accept your ideas much more readily if you tell them that Benjamin Franklin said it first. -- unknown - 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.12-rc1-mm1: REISER4_FS <-> 4KSTACKS
On Tue, 2005-03-22 at 18:13 +0100, Adrian Bunk wrote: > Hi Hans, > > REISER4_FS is the only option with a dependency on !4KSTACKS which is > bad since 8 kB stacks on i386 won't stay forever. > > Could fix the problems with 4 kB stacks? I'd be interested to find out what the problem is as well; after all even with 8Kb stacks your net available stack is somewhere in the 5Kb range anyway... so you're really close to the edge there. - 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.12-rc1-mm1: REISER4_FS <-> 4KSTACKS
Adrian Bunk wrote: >Hi Hans, > >REISER4_FS is the only option with a dependency on !4KSTACKS which is >bad since 8 kB stacks on i386 won't stay forever. > >Could fix the problems with 4 kB stacks? > >Running > > make checkstacks | grep reiser4 > >inside te kernel sources after compiling gives you hints where problems >might come from. > > >TIA >Adrian > > > All of my technical arguments on this topic were nicely obliterated by Andrew. The only real reason remaining (that I know of) is that I want to first eliminate all things which are a barrier to inclusion before dealing with this because it requires man hours to fix it. If you want to send us a cleanup patch that fixes it, I would be grateful for your time donatioin. Hans - 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.12-rc1-mm1: REISER4_FS <-> 4KSTACKS
Hi Hans, REISER4_FS is the only option with a dependency on !4KSTACKS which is bad since 8 kB stacks on i386 won't stay forever. Could fix the problems with 4 kB stacks? Running make checkstacks | grep reiser4 inside te kernel sources after compiling gives you hints where problems might come from. TIA Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.12-rc1-mm1
On Tuesday, March 22, 2005 1:18 am, Adrian Bunk wrote: > On Mon, Mar 21, 2005 at 04:42:00PM -0800, Jesse Barnes wrote: > > On Monday, March 21, 2005 12:25 pm, Adrian Bunk wrote: > > > On Mon, Mar 21, 2005 at 09:15:53AM -0800, Jesse Barnes wrote: > > > > On Monday, March 21, 2005 2:51 am, Andrew Morton wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.1 > > > > >2-rc 1/2. 6.12-rc1-mm1/ > > > > > > > > Andrew, please drop > > > > > > > > revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functi > > > >ons. patch > > > > > > > > The tiocx.c driver is now in the tree, and it uses those functions. > > > > > > IOW: > > > The EXPORT_SYMBOL's should still be removed, but the functions > > > themselves should stay. > > > > Actually, no, since tiocx can be built modular. The patch should just be > > dropped. > > ??? > > config SGI_TIOCX > bool "SGI TIO CX driver support" Hm, ok. I just looked at the Makefile and iirc some old versions of the patch allowed it modular... Jesse - 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/
[PATCH 2.6.12-rc1-mm1] net/ethernet/eth.c - eth_header
Hi,
Please consider applying (or droping).
Thank you.
Description: This patch prevent drivers from calling eth_header with a 802.3
frame using a len>1536. In such a case returns -EINVAL, which was hard to
choose because the ETH_HLEN is supposed to return.
Signed-off-by: Vicente Feito <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1-mm1/net/ethernet/eth.c.orig 2005-03-22 12:49:08.0 +
+++ linux-2.6.12-rc1-mm1/net/ethernet/eth.c 2005-03-22 12:49:36.0 +
@@ -78,6 +78,8 @@ int eth_header(struct sk_buff *skb, stru
{
struct ethhdr *eth = (struct ethhdr *)skb_push(skb,ETH_HLEN);
+ if (type == ETH_P_802_3 && len >= 1536)
+ return -EINVAL;
/*
* Set the protocol type. For a packet of type ETH_P_802_3 we put the length
* in here instead. It is up to the 802.2 layer to carry protocol information.
2.6.12-rc1-mm1: hostap stack usage
On Mon, Mar 21, 2005 at 02:51:59AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.11-mm4:
>...
> bk-netdev.patch
>...
> Latest versions of various bk trees
>...
The stack usage in some files under drivers/net/wireless/hostap/ is
too high.
drivers/net/wireless/hostap/hostap_ioctl.c:
prism2_ioctl_giwaplist:
struct sockaddr addr[IW_MAX_AP];
struct iw_quality qual[IW_MAX_AP];
64 * (16 + 4) Bytes = 1280 Bytes
prism2_ioctl_ethtool:
struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO };
196 Bytes
__prism2_translate_scan:
char buf[MAX_WPA_IE_LEN * 2 + 30];
(64 * 2) + 30 Bytes = 158 Bytes
drivers/net/wireless/hostap/hostap_cs.c:
prism2_config:
cisparse_t parse;
u_char buf[64];
config_info_t conf;
The main offender seems to be "parse" (but I'm too lame counting how
many bytes it's exactly) resulting in nearly 1 kB stack usage.
drivers/net/wireless/hostap/hostap_plx.c:
prism2_plx_check_cis:
#define CIS_MAX_LEN 256
u8 cis[CIS_MAX_LEN];
256 Bytes
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
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/
pm_message_t to struct conversion [was Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389]
Hi!
> to Linus when he reappears and then I'll duck for cover and let you guys
> sort it out ;)
There should be little reason for taking cover, that patches were just
anotating types... BTW this is how switch to pm_message_t is going to
look. If you are developing something pm-related, you should probably
do it against this tree.
Pavel
--- clean/drivers/base/power/resume.c 2004-12-25 13:34:59.0 +0100
+++ linux/drivers/base/power/resume.c 2005-03-22 12:20:53.0 +0100
@@ -41,7 +41,7 @@
list_add_tail(entry, _active);
up(_list_sem);
- if (!dev->power.prev_state)
+ if (!dev->power.prev_state.event)
resume_device(dev);
down(_list_sem);
put_device(dev);
--- clean/drivers/base/power/runtime.c 2005-01-12 11:07:39.0 +0100
+++ linux/drivers/base/power/runtime.c 2005-03-22 12:20:53.0 +0100
@@ -13,10 +13,10 @@
static void runtime_resume(struct device * dev)
{
dev_dbg(dev, "resuming\n");
- if (!dev->power.power_state)
+ if (!dev->power.power_state.event)
return;
if (!resume_device(dev))
- dev->power.power_state = 0;
+ dev->power.power_state = PMSG_ON;
}
@@ -49,10 +49,10 @@
int error = 0;
down(_sem);
- if (dev->power.power_state == state)
+ if (dev->power.power_state.event == state.event)
goto Done;
- if (dev->power.power_state)
+ if (dev->power.power_state.event)
runtime_resume(dev);
if (!(error = suspend_device(dev, state)))
--- clean/drivers/base/power/shutdown.c 2004-08-15 19:14:55.0 +0200
+++ linux/drivers/base/power/shutdown.c 2005-03-22 12:20:53.0 +0100
@@ -29,7 +29,8 @@
dev->driver->shutdown(dev);
return 0;
}
- return dpm_runtime_suspend(dev, dev->detach_state);
+ /* FIXME */
+ return dpm_runtime_suspend(dev, PMSG_FREEZE);
}
--- clean/drivers/base/power/suspend.c 2005-01-12 11:07:39.0 +0100
+++ linux/drivers/base/power/suspend.c 2005-03-22 12:20:53.0 +0100
@@ -43,7 +43,7 @@
dev->power.prev_state = dev->power.power_state;
- if (dev->bus && dev->bus->suspend && !dev->power.power_state)
+ if (dev->bus && dev->bus->suspend && (!dev->power.power_state.event))
error = dev->bus->suspend(dev, state);
return error;
--- clean/drivers/base/power/sysfs.c2004-08-15 19:14:55.0 +0200
+++ linux/drivers/base/power/sysfs.c2005-03-22 12:20:53.0 +0100
@@ -26,19 +26,20 @@
static ssize_t state_show(struct device * dev, char * buf)
{
- return sprintf(buf, "%u\n", dev->power.power_state);
+ return sprintf(buf, "%u\n", dev->power.power_state.event);
}
static ssize_t state_store(struct device * dev, const char * buf, size_t n)
{
- u32 state;
+ pm_message_t state;
char * rest;
int error = 0;
- state = simple_strtoul(buf, , 10);
+ state.event = simple_strtoul(buf, , 10);
+// state.flags = PFL_RUNTIME;
if (*rest)
return -EINVAL;
- if (state)
+ if (state.event)
error = dpm_runtime_suspend(dev, state);
else
dpm_runtime_resume(dev);
--- clean/drivers/ide/ide.c 2005-03-19 00:31:23.0 +0100
+++ linux/drivers/ide/ide.c 2005-03-22 12:20:53.0 +0100
@@ -1390,7 +1390,7 @@
rq.special =
rq.pm =
rqpm.pm_step = ide_pm_state_start_suspend;
- rqpm.pm_state = state;
+ rqpm.pm_state = state.event;
return ide_do_drive_cmd(drive, , ide_wait);
}
@@ -1409,7 +1409,7 @@
rq.special =
rq.pm =
rqpm.pm_step = ide_pm_state_start_resume;
- rqpm.pm_state = 0;
+ rqpm.pm_state = PM_EVENT_ON;
return ide_do_drive_cmd(drive, , ide_head_wait);
}
--- clean/drivers/pci/pci.c 2005-03-19 00:31:43.0 +0100
+++ linux/drivers/pci/pci.c 2005-03-22 12:20:53.0 +0100
@@ -312,22 +312,24 @@
/**
* pci_choose_state - Choose the power state of a PCI device
* @dev: PCI device to be suspended
- * @state: target sleep state for the whole system
+ * @state: target sleep state for the whole system. This is the value
+ * that is passed to suspend() function.
*
* Returns PCI power state suitable for given device and given system
* message.
*/
-pci_power_t pci_choose_state(struct pci_dev *dev, u32 state)
+pci_power_t pci_choose_state(struct pci_dev *dev, pm_message_t state)
{
- if (!pci_find_capability(dev, PCI_CAP_ID_PM))
+ switch (state.event) {
+ case PM_EVENT_ON:
return PCI_D0;
-
- switch (state) {
- case 0: return PCI_D0;
- case 2: return PCI_D2;
- case 3: return PCI_D3hot;
-
Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389
Hi!
> >> > Yes, but it is needed. There are many drivers, and they look at
> >> > numerical value of PMSG_*. I'm proceeding in steps. I hopefully
> killed
> >> > all direct accesses to the constants, and will switch constants to
> >> > something else... But that is going to be tommorow (need some
> sleep).
> >> The patches are going to acquire correct PCI device sleep state for
> >> suspend/resume. We discussed the issue several months ago. My plan is
> we
> >> first introduce 'platform_pci_set_power_state', then merge the
> >> 'platform_pci_choose_state' patch after Pavel's pm_message_t
> conversion
> >> finished. Maybe Len mislead my comments.
> >>
> >> Anyway for the callback, my intend is platform_pci_choose_state
> accept
> >> the pm_message_t parameter, and it return an 'int', since platform
> >> method possibly failed and then pci_choose_state translate the return
> >> value to pci_power_t.
> >
> >You can't just retype around like that. You may want it take
> >pci_power_t * as an argument, and then return 0/-ENODEV or something
> >like that. But you can't retype between int and pm_message_t...
> No, taking pci_power_t as an argument is meaningless. For ACPI, we
> should know the exact sleep state, pm_message_t will tell us. But I'm ok
> to let it return a pci_power_t, and the failure case returns
> -ENODEV.
You can't put -ENODEV into pci_power_t ... but maybe we should create
PCI_ERROR and pass it in cases like this one?
> >> > Could you just revert those two patches? First one is very
> >> > wrong. Second one might be fixed, but... See comments below.
> >> I think the platform_pci_set_power_state should be ok, did you see it
> >> causes oops?
> >
> >No its just ugly and uses __force in "creative" way. That one can be
> >recovered.
> Do you mean this?
>
> > + static int state_conv[] = {
> > + [0] = 0,
> > + [1] = 1,
> > + [2] = 2,
> > + [3] = 3,
> > + [4] = 3
> > + };
> > + int acpi_state = state_conv[(int __force) state];
>
> The table should be
> [PCI_D0] = 0,
>
> I'm not sure, but then could we use state_conv[state] directly? It seems
I think so. Of course it is wrong, but it is less wrong than forcing
it to integer than index, without using macros at all.
Or perhaps you should do
switch (state) {
case PCI_D0: ...
}
...and handle default case somehow.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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.12-rc1-mm1: Kernel BUG at pci:389
>
>> > Yes, but it is needed. There are many drivers, and they look at
>> > numerical value of PMSG_*. I'm proceeding in steps. I hopefully
killed
>> > all direct accesses to the constants, and will switch constants to
>> > something else... But that is going to be tommorow (need some
sleep).
>> The patches are going to acquire correct PCI device sleep state for
>> suspend/resume. We discussed the issue several months ago. My plan is
we
>> first introduce 'platform_pci_set_power_state', then merge the
>> 'platform_pci_choose_state' patch after Pavel's pm_message_t
conversion
>> finished. Maybe Len mislead my comments.
>>
>> Anyway for the callback, my intend is platform_pci_choose_state
accept
>> the pm_message_t parameter, and it return an 'int', since platform
>> method possibly failed and then pci_choose_state translate the return
>> value to pci_power_t.
>
>You can't just retype around like that. You may want it take
>pci_power_t * as an argument, and then return 0/-ENODEV or something
>like that. But you can't retype between int and pm_message_t...
No, taking pci_power_t as an argument is meaningless. For ACPI, we
should know the exact sleep state, pm_message_t will tell us. But I'm ok
to let it return a pci_power_t, and the failure case returns -ENODEV.
>
>Plus that function should have a documentation somewhere!
I will add it.
>
>> > Could you just revert those two patches? First one is very
>> > wrong. Second one might be fixed, but... See comments below.
>> I think the platform_pci_set_power_state should be ok, did you see it
>> causes oops?
>
>No its just ugly and uses __force in "creative" way. That one can be
>recovered.
Do you mean this?
> + static int state_conv[] = {
> + [0] = 0,
> + [1] = 1,
> + [2] = 2,
> + [3] = 3,
> + [4] = 3
> + };
> + int acpi_state = state_conv[(int __force) state];
The table should be
[PCI_D0] = 0,
I'm not sure, but then could we use state_conv[state] directly? It seems
wrong to me (the array accepts a pci_power_t as index?)
Thanks,
Shaohua
-
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: S2R gone with 2.6.12-rc1-mm1
Norbert Preining <[EMAIL PROTECTED]> wrote: > > On Mon, 21 Mär 2005, Andrew Morton wrote: > > > Sorry to bother you again, but I found that S2R does not work anymore > > > with 2.6.12-rc1-mm1, while it works with the exact same software setup > > > with 2.6.11-mm4. > > > > Oh. suspend-to-RAM. > > > > Would this be an ACPI regression? > > Sorry for the S2R. I guess that it is related to the new ACPI stuff > introduced in bk-acpi lately. What would you suggest: Well if you could test 2.6.12-rc1 plus rc1-mm1's bk-apci.patch, that would confirm your theory. Apart from that - please raise a bugzilla entry for the acpi guys. - 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: S2R gone with 2.6.12-rc1-mm1
On Mon, 21 Mär 2005, Andrew Morton wrote: > > Sorry to bother you again, but I found that S2R does not work anymore > > with 2.6.12-rc1-mm1, while it works with the exact same software setup > > with 2.6.11-mm4. > > Oh. suspend-to-RAM. > > Would this be an ACPI regression? Sorry for the S2R. I guess that it is related to the new ACPI stuff introduced in bk-acpi lately. What would you suggest: Taking the bk-acpi patch from 2.6.11-mm4 and use it instead of the one in 2.6.12-rc1-mm1? I guess this will not really work?! Best wishes Norbert --- Norbert Preining Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HALCRO (n.) An adhesive fibrous cloth used to hold babies' clothes together. Thousands of tiny pieces of jam 'hook' on to thousands of tiny-pieces of dribble, enabling the cloth to become 'sticky'. --- Douglas Adams, The Meaning of Liff - 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.12-rc1-mm1: Kernel BUG at pci:389
Hi!
> Will this do it for the moment?
Its certainly better.
What about
> > > +static int acpi_pci_set_power_state(struct pci_dev *dev,
> > pci_power_t state)
> > > +{
> > > + acpi_handle handle = DEVICE_ACPI_HANDLE(>dev);
> > > + static int state_conv[] = {
> > > + [0] = 0,
> > > + [1] = 1,
> > > + [2] = 2,
> > > + [3] = 3,
> > > + [4] = 3
> > > + };
> > > + int acpi_state = state_conv[(int __force) state];
...this force? Then platform_pci_choose_state should not be NULL by
default and acpi_pci_choose_state should really have some more
reasonable calling convention.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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.12-rc1-mm1: Kernel BUG at pci:389
Hi! > > Yes, but it is needed. There are many drivers, and they look at > > numerical value of PMSG_*. I'm proceeding in steps. I hopefully killed > > all direct accesses to the constants, and will switch constants to > > something else... But that is going to be tommorow (need some sleep). > The patches are going to acquire correct PCI device sleep state for > suspend/resume. We discussed the issue several months ago. My plan is we > first introduce 'platform_pci_set_power_state', then merge the > 'platform_pci_choose_state' patch after Pavel's pm_message_t conversion > finished. Maybe Len mislead my comments. > > Anyway for the callback, my intend is platform_pci_choose_state accept > the pm_message_t parameter, and it return an 'int', since platform > method possibly failed and then pci_choose_state translate the return > value to pci_power_t. You can't just retype around like that. You may want it take pci_power_t * as an argument, and then return 0/-ENODEV or something like that. But you can't retype between int and pm_message_t... Plus that function should have a documentation somewhere! > > Could you just revert those two patches? First one is very > > wrong. Second one might be fixed, but... See comments below. > I think the platform_pci_set_power_state should be ok, did you see it > causes oops? No its just ugly and uses __force in "creative" way. That one can be recovered. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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.12-rc1-mm1: Kernel BUG at pci:389
Hi! > And they are both "dangerous" -- they introduce new and untested > functionality while I'm trying to transition from int to > pm_message_t. They also affect all the drivers. Actually, there's one even more severe problem with platform_pci_choose_state... If we are doing freeze for swsusp snapshot (or freeze for kexec or something similar, that ACPI does not know about), it is very wrong to ask ACPI to tell us power levels for devices. ACPI does not even know about those states, it can not tell us anything meaningfull. So if this hook is to be reintroduced, it should go down in the function, and only trigger for ACPI S3 and ACPI S1 cases. Maybe for swsusp/plaform (== ACPI S4). But I'd prefer the hook to go away for now, it clearly needs infrastructure that is not yet there, and provides nothing. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
On Mon, 21 Mar 2005, Lee Revell wrote: > > > This one is fixed in ALSA CVS. > > > > But not in http://linux-sound.bkbits.net/linux-sound yet. How does stuff > > propagate from ALSA CVS into bk? > > The ALSA maintainers periodically ask Linus to pull from the linux-sound > tree. But that's just the general "ALSA update" process. > > I'm not aware of a mechanism for getting critical fixes like this in > ASAP. The last few have been shepherded through manually by various > people. Looks like we need a better system. I am trying to sync the linux-sound BK tree every week with our CVS. For "urgent" fixes we need to find another faster way. Hopefully, they are in most cases small enough, so they might be propagated automagically. I already proposed special "tag" in our CVS commit policy, so we can identify these patches / changesets. I will try to prepare some useable tool in few weeks. Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs - 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: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
At Mon, 21 Mar 2005 20:23:03 -0800, Andrew Morton wrote: > > Lee Revell <[EMAIL PROTECTED]> wrote: > > > > On Mon, 2005-03-21 at 20:10 -0800, Andrew Morton wrote: > > > Lee Revell <[EMAIL PROTECTED]> wrote: > > > > > > > > On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote: > > > > > From: [EMAIL PROTECTED] > > > > > Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel > > > > panic when loading the EMU10K1 driver > > > > > > > > > > > > > This one is a real mystery. No one can reproduce it. > > > > > > OK. But we don't seem to have heard from the originator since March 5th. > > > > > > > > From: [EMAIL PROTECTED] > > > > > Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy > > > > 2 and > > > > > > > > > > > > > This one is fixed in ALSA CVS. > > > > > > But not in http://linux-sound.bkbits.net/linux-sound yet. How does stuff > > > propagate from ALSA CVS into bk? > > > > > > > > > > The ALSA maintainers periodically ask Linus to pull from the linux-sound > > tree. But that's just the general "ALSA update" process. > > Oh. I was always under the impression that > http://linux-sound.bkbits.net/linux-sound contains the latest devel stuff > for -mm. sound-bk includes fairly recent codes but not always the very latest since the sync between ALSA CVS and sound-bk trees are done manually by Jaroslav. We have a mechanism to do sync immediately for critical patches. But I seem to forget to tag it like this case. Sorry for that. Takashi - 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.12-rc1-mm1
On Mon, Mar 21, 2005 at 04:42:00PM -0800, Jesse Barnes wrote: > On Monday, March 21, 2005 12:25 pm, Adrian Bunk wrote: > > On Mon, Mar 21, 2005 at 09:15:53AM -0800, Jesse Barnes wrote: > > > On Monday, March 21, 2005 2:51 am, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc > > > >1/2. 6.12-rc1-mm1/ > > > > > > Andrew, please drop > > > > > > revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functions. > > >patch > > > > > > The tiocx.c driver is now in the tree, and it uses those functions. > > > > IOW: > > The EXPORT_SYMBOL's should still be removed, but the functions > > themselves should stay. > > Actually, no, since tiocx can be built modular. The patch should just be > dropped. ??? config SGI_TIOCX bool "SGI TIO CX driver support" > Thanks, > Jesse cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.12-rc1-mm1
On Mon, Mar 21, 2005 at 04:42:00PM -0800, Jesse Barnes wrote: On Monday, March 21, 2005 12:25 pm, Adrian Bunk wrote: On Mon, Mar 21, 2005 at 09:15:53AM -0800, Jesse Barnes wrote: On Monday, March 21, 2005 2:51 am, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc 1/2. 6.12-rc1-mm1/ Andrew, please drop revert-allow-oem-written-modules-to-make-calls-to-ia64-oem-sal-functions. patch The tiocx.c driver is now in the tree, and it uses those functions. IOW: The EXPORT_SYMBOL's should still be removed, but the functions themselves should stay. Actually, no, since tiocx can be built modular. The patch should just be dropped. ??? config SGI_TIOCX bool SGI TIO CX driver support Thanks, Jesse cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
At Mon, 21 Mar 2005 20:23:03 -0800, Andrew Morton wrote: Lee Revell [EMAIL PROTECTED] wrote: On Mon, 2005-03-21 at 20:10 -0800, Andrew Morton wrote: Lee Revell [EMAIL PROTECTED] wrote: On Mon, 2005-03-21 at 12:41 -0800, Andrew Morton wrote: From: [EMAIL PROTECTED] Subject: [Bug 4282] ALSA driver in Linux 2.6.11 causes a kernel panic when loading the EMU10K1 driver This one is a real mystery. No one can reproduce it. OK. But we don't seem to have heard from the originator since March 5th. From: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 4348] New: snd_emu10k1 oops'es with Audigy 2 and This one is fixed in ALSA CVS. But not in http://linux-sound.bkbits.net/linux-sound yet. How does stuff propagate from ALSA CVS into bk? The ALSA maintainers periodically ask Linus to pull from the linux-sound tree. But that's just the general ALSA update process. Oh. I was always under the impression that http://linux-sound.bkbits.net/linux-sound contains the latest devel stuff for -mm. sound-bk includes fairly recent codes but not always the very latest since the sync between ALSA CVS and sound-bk trees are done manually by Jaroslav. We have a mechanism to do sync immediately for critical patches. But I seem to forget to tag it like this case. Sorry for that. Takashi - 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: ALSA bugs in list [was Re: 2.6.12-rc1-mm1]
On Mon, 21 Mar 2005, Lee Revell wrote: This one is fixed in ALSA CVS. But not in http://linux-sound.bkbits.net/linux-sound yet. How does stuff propagate from ALSA CVS into bk? The ALSA maintainers periodically ask Linus to pull from the linux-sound tree. But that's just the general ALSA update process. I'm not aware of a mechanism for getting critical fixes like this in ASAP. The last few have been shepherded through manually by various people. Looks like we need a better system. I am trying to sync the linux-sound BK tree every week with our CVS. For urgent fixes we need to find another faster way. Hopefully, they are in most cases small enough, so they might be propagated automagically. I already proposed special tag in our CVS commit policy, so we can identify these patches / changesets. I will try to prepare some useable tool in few weeks. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SUSE Labs - 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.12-rc1-mm1: Kernel BUG at pci:389
Hi! And they are both dangerous -- they introduce new and untested functionality while I'm trying to transition from int to pm_message_t. They also affect all the drivers. Actually, there's one even more severe problem with platform_pci_choose_state... If we are doing freeze for swsusp snapshot (or freeze for kexec or something similar, that ACPI does not know about), it is very wrong to ask ACPI to tell us power levels for devices. ACPI does not even know about those states, it can not tell us anything meaningfull. So if this hook is to be reintroduced, it should go down in the function, and only trigger for ACPI S3 and ACPI S1 cases. Maybe for swsusp/plaform (== ACPI S4). But I'd prefer the hook to go away for now, it clearly needs infrastructure that is not yet there, and provides nothing. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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.12-rc1-mm1: Kernel BUG at pci:389
Hi! Yes, but it is needed. There are many drivers, and they look at numerical value of PMSG_*. I'm proceeding in steps. I hopefully killed all direct accesses to the constants, and will switch constants to something else... But that is going to be tommorow (need some sleep). The patches are going to acquire correct PCI device sleep state for suspend/resume. We discussed the issue several months ago. My plan is we first introduce 'platform_pci_set_power_state', then merge the 'platform_pci_choose_state' patch after Pavel's pm_message_t conversion finished. Maybe Len mislead my comments. Anyway for the callback, my intend is platform_pci_choose_state accept the pm_message_t parameter, and it return an 'int', since platform method possibly failed and then pci_choose_state translate the return value to pci_power_t. You can't just retype around like that. You may want it take pci_power_t * as an argument, and then return 0/-ENODEV or something like that. But you can't retype between int and pm_message_t... Plus that function should have a documentation somewhere! Could you just revert those two patches? First one is very wrong. Second one might be fixed, but... See comments below. I think the platform_pci_set_power_state should be ok, did you see it causes oops? No its just ugly and uses __force in creative way. That one can be recovered. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - 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.12-rc1-mm1: Kernel BUG at pci:389
Hi!
Will this do it for the moment?
Its certainly better.
What about
+static int acpi_pci_set_power_state(struct pci_dev *dev,
pci_power_t state)
+{
+ acpi_handle handle = DEVICE_ACPI_HANDLE(dev-dev);
+ static int state_conv[] = {
+ [0] = 0,
+ [1] = 1,
+ [2] = 2,
+ [3] = 3,
+ [4] = 3
+ };
+ int acpi_state = state_conv[(int __force) state];
...this force? Then platform_pci_choose_state should not be NULL by
default and acpi_pci_choose_state should really have some more
reasonable calling convention.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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: S2R gone with 2.6.12-rc1-mm1
On Mon, 21 Mär 2005, Andrew Morton wrote: Sorry to bother you again, but I found that S2R does not work anymore with 2.6.12-rc1-mm1, while it works with the exact same software setup with 2.6.11-mm4. Oh. suspend-to-RAM. Would this be an ACPI regression? Sorry for the S2R. I guess that it is related to the new ACPI stuff introduced in bk-acpi lately. What would you suggest: Taking the bk-acpi patch from 2.6.11-mm4 and use it instead of the one in 2.6.12-rc1-mm1? I guess this will not really work?! Best wishes Norbert --- Norbert Preining preining AT logic DOT at Università di Siena sip:[EMAIL PROTECTED] +43 (0) 59966-690018 gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- HALCRO (n.) An adhesive fibrous cloth used to hold babies' clothes together. Thousands of tiny pieces of jam 'hook' on to thousands of tiny-pieces of dribble, enabling the cloth to become 'sticky'. --- Douglas Adams, The Meaning of Liff - 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: S2R gone with 2.6.12-rc1-mm1
Norbert Preining [EMAIL PROTECTED] wrote: On Mon, 21 Mär 2005, Andrew Morton wrote: Sorry to bother you again, but I found that S2R does not work anymore with 2.6.12-rc1-mm1, while it works with the exact same software setup with 2.6.11-mm4. Oh. suspend-to-RAM. Would this be an ACPI regression? Sorry for the S2R. I guess that it is related to the new ACPI stuff introduced in bk-acpi lately. What would you suggest: Well if you could test 2.6.12-rc1 plus rc1-mm1's bk-apci.patch, that would confirm your theory. Apart from that - please raise a bugzilla entry for the acpi guys. - 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.12-rc1-mm1: Kernel BUG at pci:389
Yes, but it is needed. There are many drivers, and they look at
numerical value of PMSG_*. I'm proceeding in steps. I hopefully
killed
all direct accesses to the constants, and will switch constants to
something else... But that is going to be tommorow (need some
sleep).
The patches are going to acquire correct PCI device sleep state for
suspend/resume. We discussed the issue several months ago. My plan is
we
first introduce 'platform_pci_set_power_state', then merge the
'platform_pci_choose_state' patch after Pavel's pm_message_t
conversion
finished. Maybe Len mislead my comments.
Anyway for the callback, my intend is platform_pci_choose_state
accept
the pm_message_t parameter, and it return an 'int', since platform
method possibly failed and then pci_choose_state translate the return
value to pci_power_t.
You can't just retype around like that. You may want it take
pci_power_t * as an argument, and then return 0/-ENODEV or something
like that. But you can't retype between int and pm_message_t...
No, taking pci_power_t as an argument is meaningless. For ACPI, we
should know the exact sleep state, pm_message_t will tell us. But I'm ok
to let it return a pci_power_t, and the failure case returns -ENODEV.
Plus that function should have a documentation somewhere!
I will add it.
Could you just revert those two patches? First one is very
wrong. Second one might be fixed, but... See comments below.
I think the platform_pci_set_power_state should be ok, did you see it
causes oops?
No its just ugly and uses __force in creative way. That one can be
recovered.
Do you mean this?
+ static int state_conv[] = {
+ [0] = 0,
+ [1] = 1,
+ [2] = 2,
+ [3] = 3,
+ [4] = 3
+ };
+ int acpi_state = state_conv[(int __force) state];
The table should be
[PCI_D0] = 0,
I'm not sure, but then could we use state_conv[state] directly? It seems
wrong to me (the array accepts a pci_power_t as index?)
Thanks,
Shaohua
-
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.12-rc1-mm1: Kernel BUG at pci:389
Hi!
Yes, but it is needed. There are many drivers, and they look at
numerical value of PMSG_*. I'm proceeding in steps. I hopefully
killed
all direct accesses to the constants, and will switch constants to
something else... But that is going to be tommorow (need some
sleep).
The patches are going to acquire correct PCI device sleep state for
suspend/resume. We discussed the issue several months ago. My plan is
we
first introduce 'platform_pci_set_power_state', then merge the
'platform_pci_choose_state' patch after Pavel's pm_message_t
conversion
finished. Maybe Len mislead my comments.
Anyway for the callback, my intend is platform_pci_choose_state
accept
the pm_message_t parameter, and it return an 'int', since platform
method possibly failed and then pci_choose_state translate the return
value to pci_power_t.
You can't just retype around like that. You may want it take
pci_power_t * as an argument, and then return 0/-ENODEV or something
like that. But you can't retype between int and pm_message_t...
No, taking pci_power_t as an argument is meaningless. For ACPI, we
should know the exact sleep state, pm_message_t will tell us. But I'm ok
to let it return a pci_power_t, and the failure case returns
-ENODEV.
You can't put -ENODEV into pci_power_t ... but maybe we should create
PCI_ERROR and pass it in cases like this one?
Could you just revert those two patches? First one is very
wrong. Second one might be fixed, but... See comments below.
I think the platform_pci_set_power_state should be ok, did you see it
causes oops?
No its just ugly and uses __force in creative way. That one can be
recovered.
Do you mean this?
+ static int state_conv[] = {
+ [0] = 0,
+ [1] = 1,
+ [2] = 2,
+ [3] = 3,
+ [4] = 3
+ };
+ int acpi_state = state_conv[(int __force) state];
The table should be
[PCI_D0] = 0,
I'm not sure, but then could we use state_conv[state] directly? It seems
I think so. Of course it is wrong, but it is less wrong than forcing
it to integer than index, without using macros at all.
Or perhaps you should do
switch (state) {
case PCI_D0: ...
}
...and handle default case somehow.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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/
pm_message_t to struct conversion [was Re: 2.6.12-rc1-mm1: Kernel BUG at pci:389]
Hi!
to Linus when he reappears and then I'll duck for cover and let you guys
sort it out ;)
There should be little reason for taking cover, that patches were just
anotating types... BTW this is how switch to pm_message_t is going to
look. If you are developing something pm-related, you should probably
do it against this tree.
Pavel
--- clean/drivers/base/power/resume.c 2004-12-25 13:34:59.0 +0100
+++ linux/drivers/base/power/resume.c 2005-03-22 12:20:53.0 +0100
@@ -41,7 +41,7 @@
list_add_tail(entry, dpm_active);
up(dpm_list_sem);
- if (!dev-power.prev_state)
+ if (!dev-power.prev_state.event)
resume_device(dev);
down(dpm_list_sem);
put_device(dev);
--- clean/drivers/base/power/runtime.c 2005-01-12 11:07:39.0 +0100
+++ linux/drivers/base/power/runtime.c 2005-03-22 12:20:53.0 +0100
@@ -13,10 +13,10 @@
static void runtime_resume(struct device * dev)
{
dev_dbg(dev, resuming\n);
- if (!dev-power.power_state)
+ if (!dev-power.power_state.event)
return;
if (!resume_device(dev))
- dev-power.power_state = 0;
+ dev-power.power_state = PMSG_ON;
}
@@ -49,10 +49,10 @@
int error = 0;
down(dpm_sem);
- if (dev-power.power_state == state)
+ if (dev-power.power_state.event == state.event)
goto Done;
- if (dev-power.power_state)
+ if (dev-power.power_state.event)
runtime_resume(dev);
if (!(error = suspend_device(dev, state)))
--- clean/drivers/base/power/shutdown.c 2004-08-15 19:14:55.0 +0200
+++ linux/drivers/base/power/shutdown.c 2005-03-22 12:20:53.0 +0100
@@ -29,7 +29,8 @@
dev-driver-shutdown(dev);
return 0;
}
- return dpm_runtime_suspend(dev, dev-detach_state);
+ /* FIXME */
+ return dpm_runtime_suspend(dev, PMSG_FREEZE);
}
--- clean/drivers/base/power/suspend.c 2005-01-12 11:07:39.0 +0100
+++ linux/drivers/base/power/suspend.c 2005-03-22 12:20:53.0 +0100
@@ -43,7 +43,7 @@
dev-power.prev_state = dev-power.power_state;
- if (dev-bus dev-bus-suspend !dev-power.power_state)
+ if (dev-bus dev-bus-suspend (!dev-power.power_state.event))
error = dev-bus-suspend(dev, state);
return error;
--- clean/drivers/base/power/sysfs.c2004-08-15 19:14:55.0 +0200
+++ linux/drivers/base/power/sysfs.c2005-03-22 12:20:53.0 +0100
@@ -26,19 +26,20 @@
static ssize_t state_show(struct device * dev, char * buf)
{
- return sprintf(buf, %u\n, dev-power.power_state);
+ return sprintf(buf, %u\n, dev-power.power_state.event);
}
static ssize_t state_store(struct device * dev, const char * buf, size_t n)
{
- u32 state;
+ pm_message_t state;
char * rest;
int error = 0;
- state = simple_strtoul(buf, rest, 10);
+ state.event = simple_strtoul(buf, rest, 10);
+// state.flags = PFL_RUNTIME;
if (*rest)
return -EINVAL;
- if (state)
+ if (state.event)
error = dpm_runtime_suspend(dev, state);
else
dpm_runtime_resume(dev);
--- clean/drivers/ide/ide.c 2005-03-19 00:31:23.0 +0100
+++ linux/drivers/ide/ide.c 2005-03-22 12:20:53.0 +0100
@@ -1390,7 +1390,7 @@
rq.special = args;
rq.pm = rqpm;
rqpm.pm_step = ide_pm_state_start_suspend;
- rqpm.pm_state = state;
+ rqpm.pm_state = state.event;
return ide_do_drive_cmd(drive, rq, ide_wait);
}
@@ -1409,7 +1409,7 @@
rq.special = args;
rq.pm = rqpm;
rqpm.pm_step = ide_pm_state_start_resume;
- rqpm.pm_state = 0;
+ rqpm.pm_state = PM_EVENT_ON;
return ide_do_drive_cmd(drive, rq, ide_head_wait);
}
--- clean/drivers/pci/pci.c 2005-03-19 00:31:43.0 +0100
+++ linux/drivers/pci/pci.c 2005-03-22 12:20:53.0 +0100
@@ -312,22 +312,24 @@
/**
* pci_choose_state - Choose the power state of a PCI device
* @dev: PCI device to be suspended
- * @state: target sleep state for the whole system
+ * @state: target sleep state for the whole system. This is the value
+ * that is passed to suspend() function.
*
* Returns PCI power state suitable for given device and given system
* message.
*/
-pci_power_t pci_choose_state(struct pci_dev *dev, u32 state)
+pci_power_t pci_choose_state(struct pci_dev *dev, pm_message_t state)
{
- if (!pci_find_capability(dev, PCI_CAP_ID_PM))
+ switch (state.event) {
+ case PM_EVENT_ON:
return PCI_D0;
-
- switch (state) {
- case 0: return PCI_D0;
- case 2: return PCI_D2;
- case 3: return PCI_D3hot;
-
[PATCH 2.6.12-rc1-mm1] net/ethernet/eth.c - eth_header
Hi,
Please consider applying (or droping).
Thank you.
Description: This patch prevent drivers from calling eth_header with a 802.3
frame using a len1536. In such a case returns -EINVAL, which was hard to
choose because the ETH_HLEN is supposed to return.
Signed-off-by: Vicente Feito [EMAIL PROTECTED]
--- linux-2.6.12-rc1-mm1/net/ethernet/eth.c.orig 2005-03-22 12:49:08.0 +
+++ linux-2.6.12-rc1-mm1/net/ethernet/eth.c 2005-03-22 12:49:36.0 +
@@ -78,6 +78,8 @@ int eth_header(struct sk_buff *skb, stru
{
struct ethhdr *eth = (struct ethhdr *)skb_push(skb,ETH_HLEN);
+ if (type == ETH_P_802_3 len = 1536)
+ return -EINVAL;
/*
* Set the protocol type. For a packet of type ETH_P_802_3 we put the length
* in here instead. It is up to the 802.2 layer to carry protocol information.
