Re: high system cpu load during intense disk i/o
So I would assume that delay_tsc() probably only makes the situation worse for the libata tests, but the real problem is at __switch_to() and schedule(). Do you agree with these assumptions? Yes. I agree that percentage of CPU time is unreasonably high for these functions. But not only for them. Is there a way to for oprofile to report the time spent in function calls depending on the call trace? I don't know any. Thanks again for the help. I guess if that doesn't lead anywhere I'll just start compiling older vanilla kernels and see when the problem dissapears. But this needs a lot of time and I'm not sure for how long I'll be able to not offer any service with those disks (I was supposed to use RAID 0 to provide storage space with them, but with the current problems that wouldn't be so wise). Probably this is the best and fastest way to diagnose problem. Dimitris Regards Rafał -- Taśm Renaty i Andrzeja tu nie znajdziesz. Mamy coś lepszego ... http://link.interia.pl/f1b41 - 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: high system cpu load during intense disk i/o
So I would assume that delay_tsc() probably only makes the situation worse for the libata tests, but the real problem is at __switch_to() and schedule(). Do you agree with these assumptions? Yes. I agree that percentage of CPU time is unreasonably high for these functions. But not only for them. Is there a way to for oprofile to report the time spent in function calls depending on the call trace? I don't know any. Thanks again for the help. I guess if that doesn't lead anywhere I'll just start compiling older vanilla kernels and see when the problem dissapears. But this needs a lot of time and I'm not sure for how long I'll be able to not offer any service with those disks (I was supposed to use RAID 0 to provide storage space with them, but with the current problems that wouldn't be so wise). Probably this is the best and fastest way to diagnose problem. Dimitris Regards Rafał -- Taśm Renaty i Andrzeja tu nie znajdziesz. Mamy coś lepszego ... http://link.interia.pl/f1b41 - 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: high system cpu load during intense disk i/o
Hello again, Hi, I 'm now using libata on the same system described before (see attached dmesg.txt). When writing to both disks I think the problem is now worse (pata_oprof_bad.txt, pata_vmstat_bad.txt), even the oprofile script needed half an hour to complete! For completion I also attach the same tests when I write to only one disk (pata_vmstat_1disk.txt, pata_oprof_1disk.txt), whence everything is normal. FWIW, libata did not give me any performance benefit, 20MB/s is again the peak hdparm reports. This OProfile thing is extremly not usefull in this case. It says that Your system is using 25% CPU time for no-op loops, but it doesn't say why. Your system really isn't very busy. Look here: procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 2 2 0 225352 5604 9170000 18112 1664 28145 6315 29 71 0 0 2 2 0 225360 5604 9170000 18496 1664 27992 6358 30 70 0 0 1 2 0 225360 5604 9170000 18432 1472 28511 6315 28 72 0 0 1 2 0 225360 5604 9170000 18240 1536 28031 6153 31 69 0 0 + video 720x576 25fps yuv stream over PCI. And system is fully responsive. Of course programs which need disk access must wait a bit longer, but later are running fine. I don't have disks so fast like Yours and I can't do destructive write test. First disk: 1 1 0 241848 7312 10076800 27712 0 927 1270 29 13 0 58 1 1 0 241052 7580 10089600 4612 4676 519 702 34 12 0 54 Second disk: 0 1 0 237752 7268 10098000 6464 0 468 583 37 10 0 53 0 1 0 241060 7532 10088400 1728 1728 465 578 31 9 0 60 Both: 0 2 0 241592 7384 10077600 33024 0 905 1415 33 16 0 51 1 2 0 240804 7528 10088400 6848 6848 642 780 38 10 0 52 So sda + sdc = both. Your single disk: 0 1 0 128804 19620 8248400 0 21120 335 675 0 4 0 96 Both: 5 2 0 168480 10972 4715200 0 16000 252 470 22 78 0 0 I would expect 2*21k, but we have only 2*8k and it is lower then single disk case. Of course this math isn't moving us forward. Only thing which would help would be function call trace as Andrew wrote. Which function is calling delay_tsc()? Is it calling it often or once but with long delay? So far it looks like some kind of hardware limit for me. Do You have any options in BIOS which can degrade PCI or disk performance? Thanks, Dimitris Rafał -- Wszystko czego potrzebujesz latem: kremy do opalania, stroje kapielowe, maly romans http://link.interia.pl/f1b15 - 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: high system cpu load during intense disk i/o
Hello again, Hi, I 'm now using libata on the same system described before (see attached dmesg.txt). When writing to both disks I think the problem is now worse (pata_oprof_bad.txt, pata_vmstat_bad.txt), even the oprofile script needed half an hour to complete! For completion I also attach the same tests when I write to only one disk (pata_vmstat_1disk.txt, pata_oprof_1disk.txt), whence everything is normal. FWIW, libata did not give me any performance benefit, 20MB/s is again the peak hdparm reports. This OProfile thing is extremly not usefull in this case. It says that Your system is using 25% CPU time for no-op loops, but it doesn't say why. Your system really isn't very busy. Look here: procs ---memory-- ---swap-- -io -system-- cpu r b swpd free buff cache si sobibo in cs us sy id wa 2 2 0 225352 5604 9170000 18112 1664 28145 6315 29 71 0 0 2 2 0 225360 5604 9170000 18496 1664 27992 6358 30 70 0 0 1 2 0 225360 5604 9170000 18432 1472 28511 6315 28 72 0 0 1 2 0 225360 5604 9170000 18240 1536 28031 6153 31 69 0 0 + video 720x576 25fps yuv stream over PCI. And system is fully responsive. Of course programs which need disk access must wait a bit longer, but later are running fine. I don't have disks so fast like Yours and I can't do destructive write test. First disk: 1 1 0 241848 7312 10076800 27712 0 927 1270 29 13 0 58 1 1 0 241052 7580 10089600 4612 4676 519 702 34 12 0 54 Second disk: 0 1 0 237752 7268 10098000 6464 0 468 583 37 10 0 53 0 1 0 241060 7532 10088400 1728 1728 465 578 31 9 0 60 Both: 0 2 0 241592 7384 10077600 33024 0 905 1415 33 16 0 51 1 2 0 240804 7528 10088400 6848 6848 642 780 38 10 0 52 So sda + sdc = both. Your single disk: 0 1 0 128804 19620 8248400 0 21120 335 675 0 4 0 96 Both: 5 2 0 168480 10972 4715200 0 16000 252 470 22 78 0 0 I would expect 2*21k, but we have only 2*8k and it is lower then single disk case. Of course this math isn't moving us forward. Only thing which would help would be function call trace as Andrew wrote. Which function is calling delay_tsc()? Is it calling it often or once but with long delay? So far it looks like some kind of hardware limit for me. Do You have any options in BIOS which can degrade PCI or disk performance? Thanks, Dimitris Rafał -- Wszystko czego potrzebujesz latem: kremy do opalania, stroje kapielowe, maly romans http://link.interia.pl/f1b15 - 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: HPET force-enable investigations on Via VT8235
Hi, BTW, is there any obvious chipset ecosystem difference in your system? Are any other important PCI IDs/revs different from mine? I don't see any differences. 00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8623 [Apollo CLE266] [1106:3123] 00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] [1106:b091] 00:0d.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. IEEE 1394 Host Controller [1106:3044] (rev 80) 00:10.0 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.1 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.2 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.3 USB Controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 82) 00:11.0 ISA bridge [0601]: VIA Technologies, Inc. VT8235 ISA Bridge [1106:3177] 00:11.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06) 00:11.5 Multimedia audio controller [0401]: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller [1106:3059] (rev 50) 00:12.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6102 [Rhine-II] [1106:3065] (rev 74) 00:14.0 Multimedia controller [0480]: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder [1131:7134] (rev 01) 01:00.0 VGA compatible controller [0300]: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics [1106:3122] (rev 03) Andreas Mohr Regards Rafał -- Plaza plazy nierowna Kliknij http://link.interia.pl/f1af7 - 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: high system cpu load during intense disk i/o
Just tested (plain curiosity). via82cxxx average result @533MHz: /dev/hda: Timing cached reads: 232 MB in 2.00 seconds = 115.93 MB/sec Timing buffered disk reads: 64 MB in 3.12 seconds = 20.54 MB/sec pata_via average result @533MHz: /dev/sda: Timing cached reads: 234 MB in 2.01 seconds = 116.27 MB/sec Timing buffered disk reads: 82 MB in 3.05 seconds = 26.92 MB/sec Interesting! I haven't tried libata myself on that system, I only have remote access to it so I'm a bit afraid... Just change root=/dev/hda1 to append="root=/dev/sda1" in lilo.conf. And change fstab. If You don't change "/" then system will go into single user mode after reboot. Rafal, I hope that system you run hdparm on isn't the archlinux one! Is it easy to load an old kernel (even two years old) and do the same test? If it is, please let me know of the results. I don't think it is possible. If I remember right kernel can't be older then glibc kernel headers. Btw. My disk is 20GB 2,5" ATA33. I wonder how 26MB/s is possible. I don't expect more. Thanks in advance, Dimitris Regards Rafał -- Wszystko czego potrzebujesz latem: kremy do opalania, stroje kapielowe, maly romans http://link.interia.pl/f1b15 - 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: HPET force-enable investigations on Via VT8235
RB> VT8235 does *NOT* have a HPET(*). Only part which has HPET is VT8237. It RB> is device 00:17.0 too, but only 1106:3227 has HPET enable and memory RB> base registers. VT8235 one and only feature which doesn't have driver RB> yet seems to be hardware watchdog. RB> (*) Datasheet revision 2.03 March 16, 2005 We have an Asrock K7VT4A+ board with VT8235 southbridge in our lab and it does have an HPET. Just because the datasheet does not document HPET does not mean it is not implemented. My guess is that newer revisions of VT8235 have HPET whereas older revisions do not. I'll get an lspci dump from our box tomorrow. Indeed datasheet lies. I have VIA EPIA M1 Rev. B motherboard. % uname -r 2.6.23-rc1-hrt1 % dmesg | grep -i hpet Force enabled HPET at base address 0xfed0 hpet clockevent registered hpet0: at MMIO 0xfed0, IRQs 2, 8, 0 hpet0: 3 32-bit timers, 14318180 Hz Time: hpet clocksource has been installed. % cat /proc/timer_list [...] Tick Device: mode: 1 Clock Event Device: hpet max_delta_ns: 2147483647 min_delta_ns: 3352 mult: 61496110 shift: 32 mode: 3 next_event: 67266400 nsecs set_next_event: hpet_legacy_next_event set_mode: hpet_legacy_set_mode event_handler: hrtimer_interrupt 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge Subsystem: VIA Technologies, Inc. Unknown device aa01 Flags: bus master, stepping, medium devsel, latency 0 Capabilities: [c0] Power Management version 2 00: 06 11 77 31 87 00 10 02 00 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 01 aa 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 40: 45 00 f0 00 00 00 00 00 0c 20 00 00 44 00 0a 08 50: 81 1d 09 00 00 b0 a5 30 03 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 04 80 00 d0 fe 00 00 00 00 70: 06 11 01 aa 00 00 00 00 00 00 00 00 20 00 00 00 80: 20 84 59 00 b2 30 00 00 01 04 00 00 00 18 00 00 90: 00 1f 50 88 b0 c0 00 00 00 97 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 01 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 14 88 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 16 00 00 00 00 00 01 00 00 00 Cheers, - Udo Regards Rafał -- Plaza plazy nierowna Kliknij http://link.interia.pl/f1af7 - 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: HPET force-enable investigations on Via VT8235
RB VT8235 does *NOT* have a HPET(*). Only part which has HPET is VT8237. It RB is device 00:17.0 too, but only 1106:3227 has HPET enable and memory RB base registers. VT8235 one and only feature which doesn't have driver RB yet seems to be hardware watchdog. RB (*) Datasheet revision 2.03 March 16, 2005 We have an Asrock K7VT4A+ board with VT8235 southbridge in our lab and it does have an HPET. Just because the datasheet does not document HPET does not mean it is not implemented. My guess is that newer revisions of VT8235 have HPET whereas older revisions do not. I'll get an lspci dump from our box tomorrow. Indeed datasheet lies. I have VIA EPIA M1 Rev. B motherboard. % uname -r 2.6.23-rc1-hrt1 % dmesg | grep -i hpet Force enabled HPET at base address 0xfed0 hpet clockevent registered hpet0: at MMIO 0xfed0, IRQs 2, 8, 0 hpet0: 3 32-bit timers, 14318180 Hz Time: hpet clocksource has been installed. % cat /proc/timer_list [...] Tick Device: mode: 1 Clock Event Device: hpet max_delta_ns: 2147483647 min_delta_ns: 3352 mult: 61496110 shift: 32 mode: 3 next_event: 67266400 nsecs set_next_event: hpet_legacy_next_event set_mode: hpet_legacy_set_mode event_handler: hrtimer_interrupt 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge Subsystem: VIA Technologies, Inc. Unknown device aa01 Flags: bus master, stepping, medium devsel, latency 0 Capabilities: [c0] Power Management version 2 00: 06 11 77 31 87 00 10 02 00 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 01 aa 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 40: 45 00 f0 00 00 00 00 00 0c 20 00 00 44 00 0a 08 50: 81 1d 09 00 00 b0 a5 30 03 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 04 80 00 d0 fe 00 00 00 00 70: 06 11 01 aa 00 00 00 00 00 00 00 00 20 00 00 00 80: 20 84 59 00 b2 30 00 00 01 04 00 00 00 18 00 00 90: 00 1f 50 88 b0 c0 00 00 00 97 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 01 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 14 88 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 16 00 00 00 00 00 01 00 00 00 Cheers, - Udo Regards Rafał -- Plaza plazy nierowna Kliknij http://link.interia.pl/f1af7 - 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: high system cpu load during intense disk i/o
Just tested (plain curiosity). via82cxxx average result @533MHz: /dev/hda: Timing cached reads: 232 MB in 2.00 seconds = 115.93 MB/sec Timing buffered disk reads: 64 MB in 3.12 seconds = 20.54 MB/sec pata_via average result @533MHz: /dev/sda: Timing cached reads: 234 MB in 2.01 seconds = 116.27 MB/sec Timing buffered disk reads: 82 MB in 3.05 seconds = 26.92 MB/sec Interesting! I haven't tried libata myself on that system, I only have remote access to it so I'm a bit afraid... Just change root=/dev/hda1 to append=root=/dev/sda1 in lilo.conf. And change fstab. If You don't change / then system will go into single user mode after reboot. Rafal, I hope that system you run hdparm on isn't the archlinux one! Is it easy to load an old kernel (even two years old) and do the same test? If it is, please let me know of the results. I don't think it is possible. If I remember right kernel can't be older then glibc kernel headers. Btw. My disk is 20GB 2,5 ATA33. I wonder how 26MB/s is possible. I don't expect more. Thanks in advance, Dimitris Regards Rafał -- Wszystko czego potrzebujesz latem: kremy do opalania, stroje kapielowe, maly romans http://link.interia.pl/f1b15 - 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: HPET force-enable investigations on Via VT8235
Hi, BTW, is there any obvious chipset ecosystem difference in your system? Are any other important PCI IDs/revs different from mine? I don't see any differences. 00:00.0 Host bridge [0600]: VIA Technologies, Inc. VT8623 [Apollo CLE266] [1106:3123] 00:01.0 PCI bridge [0604]: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] [1106:b091] 00:0d.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. IEEE 1394 Host Controller [1106:3044] (rev 80) 00:10.0 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.1 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.2 USB Controller [0c03]: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller [1106:3038] (rev 80) 00:10.3 USB Controller [0c03]: VIA Technologies, Inc. USB 2.0 [1106:3104] (rev 82) 00:11.0 ISA bridge [0601]: VIA Technologies, Inc. VT8235 ISA Bridge [1106:3177] 00:11.1 IDE interface [0101]: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE [1106:0571] (rev 06) 00:11.5 Multimedia audio controller [0401]: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller [1106:3059] (rev 50) 00:12.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6102 [Rhine-II] [1106:3065] (rev 74) 00:14.0 Multimedia controller [0480]: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder [1131:7134] (rev 01) 01:00.0 VGA compatible controller [0300]: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics [1106:3122] (rev 03) Andreas Mohr Regards Rafał -- Plaza plazy nierowna Kliknij http://link.interia.pl/f1af7 - 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: high system cpu load during intense disk i/o
Hello Rafal, Hello, However I find it quite possible to have reached the throughput limit because of software (driver) problems. I have done various testing (mostly "hdparm -tT" with exactly the same PC and disks since about kernel 2.6.8 (maybe even earlier). I remember with certainty that read throughput the early days was about 50MB/s for each of the big disks, and combined with RAID 0 I got ~75MB/s. Those figures have been dropping gradually with each new kernel release and the situation today, with 2.6.22, is that hdparm gives maximum throughput 20MB/s for each disk, and for RAID 0 too! Just tested (plain curiosity). via82cxxx average result @533MHz: /dev/hda: Timing cached reads: 232 MB in 2.00 seconds = 115.93 MB/sec Timing buffered disk reads: 64 MB in 3.12 seconds = 20.54 MB/sec pata_via average result @533MHz: /dev/sda: Timing cached reads: 234 MB in 2.01 seconds = 116.27 MB/sec Timing buffered disk reads: 82 MB in 3.05 seconds = 26.92 MB/sec Same 2.6.23-rc1-git11 kernel. Yes - constant 6MB/s difference (31%). Cool. Dimitris Regards Rafał -- Jestes sexy? Dodaj swoje fotki i daj sie ocenic na http://link.interia.pl/f1b21 - 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: HPET force-enable investigations on Via VT8235
Hi, Hi, So, *please* (I'd *love* to get this working somehow): whoever has a VT8235 and is listening here, - give a "lspci -nn" (two 'n'!), to figure out details of chipset revision etc. - give a "lspci -d 1106:3177 -xxx", to try to figure out whether there happen to be additional magical "enable" bits to map in those HPET I/O areas which some BIOS versions configure and some don't (that's my fragile theory at least) - oh, and don't forget to tell whether HPET works or not VT8235 does *NOT* have a HPET(*). Only part which has HPET is VT8237. It is device 00:17.0 too, but only 1106:3227 has HPET enable and memory base registers. VT8235 one and only feature which doesn't have driver yet seems to be hardware watchdog. Thanks a lot, Andreas Mohr (*) Datasheet revision 2.03 March 16, 2005 Regards Rafał -- Jak najszybciej dostac sie na wymarzona plaze? Znajdz trase ekspresowa http://link.interia.pl/f1b0c - 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: high system cpu load during intense disk i/o
Hello and thanks for your reply. Hello again, The cron job that is running every 10 min on my system is mpop (a fetchmail-like program) and another running every 5 min is mrtg. Both normally finish within 1-2 seconds. The fact that these simple cron jobs don't finish ever is certainly because of the high system CPU load. If you see the two_discs_bad.txt which I attached on my original message, you'll see that *vmlinux*, and specifically the *scheduler*, take up most time. And the fact that this happens only when running two i/o processes but when running only one everything is absolutely snappy (not at all slow, see one_disc.txt), makes me sure that this is a kernel bug. I'd be happy to help but I need some guidance to pinpoint the problem. In Your oprofile output I find "acpi_pm_read" particulary interesting. Unlike other VIA chipsets, which I know, Your doesn't use VLink to connect northbridge to southbridge. Instead PCI bus connects these two. As You probably know maximal PCI throughtput is 133MiB/s. In theory. In practice probably less. ACPI registers are located on southbridge. This probably means that processor needs access to PCI bus in order to read ACPI timer register. Now some math. 20GiB disk probably can send data at 20MiB/s rate. 200GiB disk probably about 40MiB/s. So 20+2*40=100MiB/s. I think that this could explain why simple inl() call takes so much time and why Your system isn't very responsive. Thanks, Dimitris Let me know if You find my theory amazing or amusing. Rafał -- Kobiety klamia o wiele skuteczniej niz mezczyzni. Sprawdz, jak sie na nich poznac http://link.interia.pl/f1b16 - 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: high system cpu load during intense disk i/o
Hello and thanks for your reply. Hello again, The cron job that is running every 10 min on my system is mpop (a fetchmail-like program) and another running every 5 min is mrtg. Both normally finish within 1-2 seconds. The fact that these simple cron jobs don't finish ever is certainly because of the high system CPU load. If you see the two_discs_bad.txt which I attached on my original message, you'll see that *vmlinux*, and specifically the *scheduler*, take up most time. And the fact that this happens only when running two i/o processes but when running only one everything is absolutely snappy (not at all slow, see one_disc.txt), makes me sure that this is a kernel bug. I'd be happy to help but I need some guidance to pinpoint the problem. In Your oprofile output I find acpi_pm_read particulary interesting. Unlike other VIA chipsets, which I know, Your doesn't use VLink to connect northbridge to southbridge. Instead PCI bus connects these two. As You probably know maximal PCI throughtput is 133MiB/s. In theory. In practice probably less. ACPI registers are located on southbridge. This probably means that processor needs access to PCI bus in order to read ACPI timer register. Now some math. 20GiB disk probably can send data at 20MiB/s rate. 200GiB disk probably about 40MiB/s. So 20+2*40=100MiB/s. I think that this could explain why simple inl() call takes so much time and why Your system isn't very responsive. Thanks, Dimitris Let me know if You find my theory amazing or amusing. Rafał -- Kobiety klamia o wiele skuteczniej niz mezczyzni. Sprawdz, jak sie na nich poznac http://link.interia.pl/f1b16 - 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: HPET force-enable investigations on Via VT8235
Hi, Hi, So, *please* (I'd *love* to get this working somehow): whoever has a VT8235 and is listening here, - give a lspci -nn (two 'n'!), to figure out details of chipset revision etc. - give a lspci -d 1106:3177 -xxx, to try to figure out whether there happen to be additional magical enable bits to map in those HPET I/O areas which some BIOS versions configure and some don't (that's my fragile theory at least) - oh, and don't forget to tell whether HPET works or not VT8235 does *NOT* have a HPET(*). Only part which has HPET is VT8237. It is device 00:17.0 too, but only 1106:3227 has HPET enable and memory base registers. VT8235 one and only feature which doesn't have driver yet seems to be hardware watchdog. Thanks a lot, Andreas Mohr (*) Datasheet revision 2.03 March 16, 2005 Regards Rafał -- Jak najszybciej dostac sie na wymarzona plaze? Znajdz trase ekspresowa http://link.interia.pl/f1b0c - 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: high system cpu load during intense disk i/o
Hello Rafal, Hello, However I find it quite possible to have reached the throughput limit because of software (driver) problems. I have done various testing (mostly hdparm -tT with exactly the same PC and disks since about kernel 2.6.8 (maybe even earlier). I remember with certainty that read throughput the early days was about 50MB/s for each of the big disks, and combined with RAID 0 I got ~75MB/s. Those figures have been dropping gradually with each new kernel release and the situation today, with 2.6.22, is that hdparm gives maximum throughput 20MB/s for each disk, and for RAID 0 too! Just tested (plain curiosity). via82cxxx average result @533MHz: /dev/hda: Timing cached reads: 232 MB in 2.00 seconds = 115.93 MB/sec Timing buffered disk reads: 64 MB in 3.12 seconds = 20.54 MB/sec pata_via average result @533MHz: /dev/sda: Timing cached reads: 234 MB in 2.01 seconds = 116.27 MB/sec Timing buffered disk reads: 82 MB in 3.05 seconds = 26.92 MB/sec Same 2.6.23-rc1-git11 kernel. Yes - constant 6MB/s difference (31%). Cool. Dimitris Regards Rafał -- Jestes sexy? Dodaj swoje fotki i daj sie ocenic na http://link.interia.pl/f1b21 - 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: high system cpu load during intense disk i/o
Hello and thanks for your reply.
Hi,
The cron job that is running every 10 min on my system is mpop (a
fetchmail-like program) and another running every 5 min is mrtg. Both
normally finish within 1-2 seconds.
The fact that these simple cron jobs don't finish ever is certainly because of
the high system CPU load. If you see the two_discs_bad.txt which I attached
on my original message, you'll see that *vmlinux*, and specifically the
*scheduler*, take up most time.
And the fact that this happens only when running two i/o processes but when
running only one everything is absolutely snappy (not at all slow, see
one_disc.txt), makes me sure that this is a kernel bug. I'd be happy to help
but I need some guidance to pinpoint the problem.
OK, but first can You try to fix Your cron daemon? Just make sure that if mpop
is already started it won't be started again. Maybe something like "pgrep mpop"
and "if [ $?".
I don't remember exactly, but some time ago somebody had problem with to large
disk buffers and sync(). Check LKML archives. MPOP is doing fsync().
You have VIA chipset. Me too. It isn't very reliable. Don't You have something
like "error { d0 BUSY }" in dmesg? This would explain high CPU load. Simply
DMA isn't used after such error and disk goes to PIO mode. On two disk system
load is about 4.0 in this case. Simple program takes hours to complete if
there is havy I/O in progress. Btw. SLUB seems to behave better in this
situation (at least up to 8.0).
Thanks,
Dimitris
Regards
Rafał
--
Dowiedz sie, co naprawde podnieca kobiety. Wiecej wiesz, latwiej je
oczarujesz
http://link.interia.pl/f1b17
-
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: high system cpu load during intense disk i/o
Hello again, Hi! was my report so complicated? Perhaps I shouldn't have included so many oprofile outputs. Anyway, if anyone wants to have a look, the most important is two_discs_bad.txt oprofile output, attached on my original message. The problem is 100% reproducible for me so I would appreciate if anyone told me he has similar experiences. Probably nobody replied to Your message because people at this list think that Your problem isn't kernel related. In this moment I'm using "Arch Linux" too, so I checked /etc/cron directory. There simple jobs You are talking about are not so simple: - update the "locate" database, - update the "whatis" database. Both jobs are scaning "/" partition. I don't know how dcron works, but I can imagine situation in which it is polling cron.daily and says: "hey it wasn't done today yet" and it is starting same jobs over and over again. More and more tasks scans the "/" partition and in result access is slower and slower. Thanks, Dimitris Let me know if I'm wrong Rafał -- Zmien konto na takie o nieograniczonej pojemnosci. Za darmo w INTERIA.PL http://link.interia.pl/f1b0a - 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: high system cpu load during intense disk i/o
Hello again, Hi! was my report so complicated? Perhaps I shouldn't have included so many oprofile outputs. Anyway, if anyone wants to have a look, the most important is two_discs_bad.txt oprofile output, attached on my original message. The problem is 100% reproducible for me so I would appreciate if anyone told me he has similar experiences. Probably nobody replied to Your message because people at this list think that Your problem isn't kernel related. In this moment I'm using Arch Linux too, so I checked /etc/cron directory. There simple jobs You are talking about are not so simple: - update the locate database, - update the whatis database. Both jobs are scaning / partition. I don't know how dcron works, but I can imagine situation in which it is polling cron.daily and says: hey it wasn't done today yet and it is starting same jobs over and over again. More and more tasks scans the / partition and in result access is slower and slower. Thanks, Dimitris Let me know if I'm wrong Rafał -- Zmien konto na takie o nieograniczonej pojemnosci. Za darmo w INTERIA.PL http://link.interia.pl/f1b0a - 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: high system cpu load during intense disk i/o
Hello and thanks for your reply.
Hi,
The cron job that is running every 10 min on my system is mpop (a
fetchmail-like program) and another running every 5 min is mrtg. Both
normally finish within 1-2 seconds.
The fact that these simple cron jobs don't finish ever is certainly because of
the high system CPU load. If you see the two_discs_bad.txt which I attached
on my original message, you'll see that *vmlinux*, and specifically the
*scheduler*, take up most time.
And the fact that this happens only when running two i/o processes but when
running only one everything is absolutely snappy (not at all slow, see
one_disc.txt), makes me sure that this is a kernel bug. I'd be happy to help
but I need some guidance to pinpoint the problem.
OK, but first can You try to fix Your cron daemon? Just make sure that if mpop
is already started it won't be started again. Maybe something like pgrep mpop
and if [ $?.
I don't remember exactly, but some time ago somebody had problem with to large
disk buffers and sync(). Check LKML archives. MPOP is doing fsync().
You have VIA chipset. Me too. It isn't very reliable. Don't You have something
like error { d0 BUSY } in dmesg? This would explain high CPU load. Simply
DMA isn't used after such error and disk goes to PIO mode. On two disk system
load is about 4.0 in this case. Simple program takes hours to complete if
there is havy I/O in progress. Btw. SLUB seems to behave better in this
situation (at least up to 8.0).
Thanks,
Dimitris
Regards
Rafał
--
Dowiedz sie, co naprawde podnieca kobiety. Wiecej wiesz, latwiej je
oczarujesz
http://link.interia.pl/f1b17
-
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] Remove bdput from do_open() in fs/block_dev.c
I mistyped
# echo /dev/hdc1 >/sys/module/block2mtd/parameters/block2mt
instead of sdc1. There is no /dev/hdc1. I have DVD-ROM as /dev/hdc.
# dmesg
block2mtd: version $Revision: 1.30 $
block2mtd: error: cannot open device /dev/hdc1
Looks right, but tray is locked. And it doesn't want to get out.
# eject
hdc: irq timeout: status=0xd0 { Busy }
ide: failed opcode was: unknown
WARNING: at kernel/irq/resend.c:70 check_irq_resend()
[] check_irq_resend+0xab/0xc0
[] enable_irq+0x4a/0xa0
[] ide_error+0x47/0xa0
[] cdrom_newpc_intr+0x0/0x300
[] ide_timer_expiry+0x1e0/0x2d0
[] ide_timer_expiry+0x0/0x2d0
[] run_timer_softirq+0x116/0x160
[] hrtimer_interrupt+0x165/0x1a0
[] __do_softirq+0x42/0x90
[] do_softirq+0x26/0x30
[] irq_exit+0x5a/0x60
[] do_IRQ+0x47/0x80
[] common_interrupt+0x23/0x30
[] acpi_processor_idle+0x162/0x380
[] cpu_idle+0x4e/0x70
[] start_kernel+0x1f5/0x240
[] unknown_bootoption+0x0/0x1e0
===
Removing bdput from do_open() in fs/block_dev.c seems
to be a cure for irq timeout.
Signed-off-by: Rafał Bilski <[EMAIL PROTECTED]>
---
diff --git a/fs/block_dev.c b/fs/block_dev.c
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1120,7 +1120,6 @@ static int do_open(struct block_device *
disk = get_gendisk(bdev->bd_dev, );
if (!disk) {
unlock_kernel();
- bdput(bdev);
return ret;
}
owner = disk->fops->owner;
--
Wszystko czego potrzebujesz latem: kremy do opalania,
stroje kapielowe, maly romans
http://link.interia.pl/f1b15
-
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] Remove bdput from do_open() in fs/block_dev.c
I mistyped
# echo /dev/hdc1 /sys/module/block2mtd/parameters/block2mt
instead of sdc1. There is no /dev/hdc1. I have DVD-ROM as /dev/hdc.
# dmesg
block2mtd: version $Revision: 1.30 $
block2mtd: error: cannot open device /dev/hdc1
Looks right, but tray is locked. And it doesn't want to get out.
# eject
hdc: irq timeout: status=0xd0 { Busy }
ide: failed opcode was: unknown
WARNING: at kernel/irq/resend.c:70 check_irq_resend()
[c013444b] check_irq_resend+0xab/0xc0
[c0133e2a] enable_irq+0x4a/0xa0
[c02c26e7] ide_error+0x47/0xa0
[c02d1e60] cdrom_newpc_intr+0x0/0x300
[c02c2bc0] ide_timer_expiry+0x1e0/0x2d0
[c02c29e0] ide_timer_expiry+0x0/0x2d0
[c011b986] run_timer_softirq+0x116/0x160
[c0127e75] hrtimer_interrupt+0x165/0x1a0
[c0118772] __do_softirq+0x42/0x90
[c01187e6] do_softirq+0x26/0x30
[c0118aaa] irq_exit+0x5a/0x60
[c0104817] do_IRQ+0x47/0x80
[c0102c23] common_interrupt+0x23/0x30
[c0281a46] acpi_processor_idle+0x162/0x380
[c0100d0e] cpu_idle+0x4e/0x70
[c0524ac5] start_kernel+0x1f5/0x240
[c05243a0] unknown_bootoption+0x0/0x1e0
===
Removing bdput from do_open() in fs/block_dev.c seems
to be a cure for irq timeout.
Signed-off-by: Rafał Bilski [EMAIL PROTECTED]
---
diff --git a/fs/block_dev.c b/fs/block_dev.c
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1120,7 +1120,6 @@ static int do_open(struct block_device *
disk = get_gendisk(bdev-bd_dev, part);
if (!disk) {
unlock_kernel();
- bdput(bdev);
return ret;
}
owner = disk-fops-owner;
--
Wszystko czego potrzebujesz latem: kremy do opalania,
stroje kapielowe, maly romans
http://link.interia.pl/f1b15
-
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] mtd: Makefile fix (was Re: [PATCH] mtdsuper: licensce = GPL)
[PATCH] mtd: Makefile fix
We want drivers/mtd/{mtdcore, mtdsuper, mtdpart}.c to be built and linked
into the same mtd.ko module. Fix the Makefile to ensure this, and remove
duplicate MODULE_ declarations in mtdpart.c, as mtdcore.c already has them.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
Ok. I have mtd.ko now.
Thank You
Rafał
--
Wszystko czego potrzebujesz latem: kremy do opalania,
stroje kapielowe, maly romans
http://link.interia.pl/f1b15
-
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] mtd: Makefile fix (was Re: [PATCH] mtdsuper: licensce = GPL)
[PATCH] mtd: Makefile fix
We want drivers/mtd/{mtdcore, mtdsuper, mtdpart}.c to be built and linked
into the same mtd.ko module. Fix the Makefile to ensure this, and remove
duplicate MODULE_ declarations in mtdpart.c, as mtdcore.c already has them.
Signed-off-by: Satyam Sharma [EMAIL PROTECTED]
Ok. I have mtd.ko now.
Thank You
Rafał
--
Wszystko czego potrzebujesz latem: kremy do opalania,
stroje kapielowe, maly romans
http://link.interia.pl/f1b15
-
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/
JFFS2 BUG
Hi, I can't find JFFS2 maintainer so I'm sending it to MTD maintainer. I don't have luck in this week :-( Linux: 2.6.23-rc1-git3 (2.6.22.1 patched - that's why version is wrong) Command which caused BUG(): chmod o+r * ezri user.warn kernel: argh. node added in wrong place ezri user.alert kernel: BUG: unable to handle kernel paging request at virtual address ffee ezri user.alert kernel: printing eip: ezri user.warn kernel: c68375f4 ezri user.alert kernel: *pde = 00016067 ezri user.alert kernel: *pte = ezri user.emerg kernel: Oops: [#1] ezri user.warn kernel: Modules linked in: jffs2 mtdsuper block2mtd mtdpart mtdcore ezri user.emerg kernel: CPU:0 ezri user.emerg kernel: EIP:0060:[]Not tainted VLI ezri user.emerg kernel: EFLAGS: 00210246 (2.6.22.1 #6) ezri user.emerg kernel: EIP is at jffs2_read_dnode+0x2c/0x2ee [jffs2] ezri user.emerg kernel: eax: ffea ebx: c200a000 ecx: edx: c1040140 ezri user.emerg kernel: esi: c0d28990 edi: c0a41000 ebp: c0cde7b0 esp: c1a4dc70 ezri user.emerg kernel: ds: 007b es: 007b fs: gs: 0033 ss: 0068 ezri user.emerg kernel: Process vsftpd (pid: 1324, ti=c1a4c000 task=c16da580 task.ti=c1a4c000) ezri user.emerg kernel: Stack: 000c c1a4dcd8 c268ef9c c683f360 c056ed20 c5244600 ezri user.emerg kernel:fff4 000c 0001 c0a41000 c0cde7b0 c68379b8 c0a41000 ezri user.emerg kernel:1000 c6837d9f c0a41000 c056ed20 c5244600 00011000 1000 ezri user.emerg kernel: Call Trace: ezri user.emerg kernel: [] jffs2_flash_direct_write+0x22/0x2a [jffs2] ezri user.emerg kernel: [] jffs2_read_inode_range+0x102/0x146 [jffs2] ezri user.emerg kernel: [] jffs2_mark_node_obsolete+0x353/0x40f [jffs2] ezri user.emerg kernel: [] update_curr+0x232/0x253 ezri user.emerg kernel: [] jffs2_do_readpage_nolock+0x54/0x72 [jffs2] ezri user.emerg kernel: [] jffs2_prepare_write+0x24c/0x274 [jffs2] ezri user.emerg kernel: [] __alloc_pages+0x63/0x292 ezri user.emerg kernel: [] skb_copy_datagram_iovec+0x54/0x1d0 ezri user.emerg kernel: [] generic_file_buffered_write+0x260/0x5ba ezri user.emerg kernel: [] release_sock+0xc/0x74 ezri user.emerg kernel: [] tcp_prequeue_process+0x4e/0x5b ezri user.emerg kernel: [] __generic_file_aio_write_nolock+0x434/0x482 ezri user.emerg kernel: [] sock_aio_read+0xc0/0xc8 ezri user.emerg kernel: [] generic_file_aio_write+0x5e/0xbf ezri user.emerg kernel: [] do_sync_write+0xc6/0x109 ezri user.emerg kernel: [] autoremove_wake_function+0x0/0x33 ezri user.emerg kernel: [] enqueue_hrtimer+0x5a/0x62 ezri user.emerg kernel: [] do_sync_write+0x0/0x109 ezri user.emerg kernel: [] vfs_write+0x8a/0x112 ezri user.emerg kernel: [] sys_write+0x41/0x67 ezri user.emerg kernel: [] syscall_call+0x7/0xb ezri user.emerg kernel: [] sctp_datamsg_from_user+0x297/0x2a7 ezri user.emerg kernel: === ezri user.emerg kernel: Code: 57 56 53 83 ec 28 89 ce 89 44 24 18 89 54 24 14 e8 47 ff ff ff 89 c3 c7 44 24 20 f4 ff ff ff 85 c0 0f 84 ba 02 00 00 8b 06 31 c9 <8b> 50 04 8d 44 24 24 83 e2 fc 89 44 24 04 8b 44 24 18 89 5c 24 ezri user.emerg kernel: EIP: [] jffs2_read_dnode+0x2c/0x2ee [jffs2] SS:ESP 0068:c1a4dc70 ezri user.warn kernel: Node totlen on flash (0x1044) != totlen from node ref (0x0044) ezri user.warn kernel: argh. node added in wrong place ezri user.alert kernel: BUG: unable to handle kernel paging request at virtual address ffee ezri user.alert kernel: printing eip: ezri user.warn kernel: c6837a6c ezri user.alert kernel: *pde = 00016067 ezri user.alert kernel: *pte = ezri user.emerg kernel: Oops: [#2] ezri user.warn kernel: Modules linked in: jffs2 mtdsuper block2mtd mtdpart mtdcore ezri user.emerg kernel: CPU:0 ezri user.emerg kernel: EIP:0060:[]Tainted: G D VLI ezri user.emerg kernel: EFLAGS: 00210282 (2.6.22.1 #6) ezri user.emerg kernel: EIP is at jffs2_mark_node_obsolete+0x20/0x40f [jffs2] ezri user.emerg kernel: eax: c5244600 ebx: ecx: edx: ffea ezri user.emerg kernel: esi: c5244600 edi: c200a048 ebp: ffea esp: c277fce4 ezri user.emerg kernel: ds: 007b es: 007b fs: gs: 0033 ss: 0068 ezri user.emerg kernel: Process vsftpd (pid: 1327, ti=c277e000 task=c16db080 task.ti=c277e000) ezri user.emerg kernel: Stack: c15133b0 c38e2450 c1de43f0 c68372c0 c15133b0 c5244600 c1de4404 ezri user.emerg kernel: c1de43f0 c200a048 c15133b0 c683a7d1 c0cd2800 0327 0003 ezri user.emerg kernel: c5244600 0327 0582 e958 c0cd2800 ezri user.emerg kernel: Call Trace: ezri user.emerg kernel: [] jffs2_add_full_dnode_to_inode+0x2a7/0x2d4 [jffs2] ezri user.emerg kernel: [] jffs2_write_inode_range+0x1dd/0x279 [jffs2] ezri user.emerg kernel: [] jffs2_commit_write+0xdd/0x1a3 [jffs2] ezri user.emerg kernel: [] generic_file_buffered_write+0x3fc/0x5ba ezri user.emerg
Re: CS5530 Alsa driver fails
The 5530 in native mode only generates SMI. I've always felt however that if you make the buffers big enough you ought to be able to drive it off the 1KHz timer tick by polling. Interesting project. Looks like somebody did it already. I will try it as soon as I can. You btw won't have removed the SMM firmware or the box wouldn't boot. The 5530 uses SMM to emulate some of the most basic PC components including the VGA video. Hmm. I don't have VGA. Linux was always starting without VGA console. I had to disable display (power off the DAC's) because of constant "Checking FLASH" screen. Alan Rafał -- Sprawdz czy Ty i Twoj partner pasujecie do siebie emocjonalnie i seksualnie http://link.interia.pl/f1b14 - 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] mtdsuper: licensce = GPL
You should apply -rcN or -gitX patches on the previous Linus' kernel (2.6.x) and not the 2.6.x.y "-stable" ones -- those are a "parallel" tree. Done. Hmm, you've got mtdpart build separately as well. Could you redo as per what I suggested above (take 2.6.22, apply -rc1, then -rc1-git3) and then rebuild after "make oldconfig" ... and let us know if you still end up with these modules? This time I used Linux-2.6.23-rc1-git11 with config for my desktop plus MTD selected as . Previous config was for my "router". Let me know if You need "desktop" config too. CC [M] drivers/mtd/mtdcore.o CC [M] drivers/mtd/mtdsuper.o CC [M] drivers/mtd/mtdchar.o CC [M] drivers/mtd/mtd_blkdevs.o CC [M] drivers/mtd/mtdblock.o [...] CC drivers/mtd/chips/chipreg.mod.o LD [M] drivers/mtd/chips/chipreg.ko CC drivers/mtd/devices/block2mtd.mod.o LD [M] drivers/mtd/devices/block2mtd.ko CC drivers/mtd/mtd_blkdevs.mod.o LD [M] drivers/mtd/mtd_blkdevs.ko CC drivers/mtd/mtdblock.mod.o LD [M] drivers/mtd/mtdblock.ko CC drivers/mtd/mtdchar.mod.o LD [M] drivers/mtd/mtdchar.ko CC drivers/mtd/mtdcore.mod.o LD [M] drivers/mtd/mtdcore.ko CC drivers/mtd/mtdsuper.mod.o LD [M] drivers/mtd/mtdsuper.ko % ls *.ko mtd_blkdevs.ko mtdblock.ko mtdchar.ko mtdcore.ko mtdsuper.ko Could also be a make/toolchain issue at your end, for all I know. I'm using "Arch Linux" now. % make -v GNU Make 3.81 [...] This program built for i686-pc-linux-gnu % gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.2.1 20070704 (prerelease) % ld -v GNU ld version 2.17 Satyam Rafał -- Jak najszybciej dostac sie na wymarzona plaze? Znajdz trase ekspresowa http://link.interia.pl/f1b0d - 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] mtdsuper: licensce = GPL
block2mtd: version $Revision: 1.30 $ block2mtd: mtd0: [d: /dev/sdc2] erase_size = 64KiB [65536] mtdsuper: module license 'unspecified' taints kernel. mtdsuper: Unknown symbol get_mtd_device mtdsuper: Unknown symbol put_mtd_device jffs2: Unknown symbol get_sb_mtd jffs2: Unknown symbol kill_mtd_super That's weird. I'm wondering how did you manage to build mtdsuper as a separate module in the first place? It always gets linked with mtdcore (which has all the necessary module decoration stuff) into the "mtd" module itself, at least that;s what the Makefile says ... I don't know. Just "make oldconfig" (~2.6.21) and "make". I have mtdcore as a separate module too. That's weird: /Makefile claims that it is 2.6.22.1, but looking at the sources I see changes present in 2.6.23-rc1. I have downloaded 2.6.22.1 in the first place and patched it with -rc1 and -rc1-git3 patch. # ls *.ko ftl.ko mtd_blkdevs.ko mtdblock.ko mtdchar.ko mtdcore.ko mtdpart.ko mtdsuper.ko # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22.1 # Wed Aug 1 19:27:00 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set 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_PARAVIRT 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_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # 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_MGEODEGX1=y # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=4 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_TSC=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set
Re: [PATCH] mtdsuper: licensce = GPL
block2mtd: version $Revision: 1.30 $ block2mtd: mtd0: [d: /dev/sdc2] erase_size = 64KiB [65536] mtdsuper: module license 'unspecified' taints kernel. mtdsuper: Unknown symbol get_mtd_device mtdsuper: Unknown symbol put_mtd_device jffs2: Unknown symbol get_sb_mtd jffs2: Unknown symbol kill_mtd_super That's weird. I'm wondering how did you manage to build mtdsuper as a separate module in the first place? It always gets linked with mtdcore (which has all the necessary module decoration stuff) into the mtd module itself, at least that;s what the Makefile says ... I don't know. Just make oldconfig (~2.6.21) and make. I have mtdcore as a separate module too. That's weird: /Makefile claims that it is 2.6.22.1, but looking at the sources I see changes present in 2.6.23-rc1. I have downloaded 2.6.22.1 in the first place and patched it with -rc1 and -rc1-git3 patch. # ls *.ko ftl.ko mtd_blkdevs.ko mtdblock.ko mtdchar.ko mtdcore.ko mtdpart.ko mtdsuper.ko # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22.1 # Wed Aug 1 19:27:00 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # CONFIG_SMP is not set 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_PARAVIRT 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_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # 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_MGEODEGX1=y # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=4 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_TSC=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set # CONFIG_X86_UP_APIC is not set CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set CONFIG_VM86=y #
Re: [PATCH] mtdsuper: licensce = GPL
You should apply -rcN or -gitX patches on the previous Linus' kernel (2.6.x) and not the 2.6.x.y -stable ones -- those are a parallel tree. Done. Hmm, you've got mtdpart build separately as well. Could you redo as per what I suggested above (take 2.6.22, apply -rc1, then -rc1-git3) and then rebuild after make oldconfig ... and let us know if you still end up with these modules? This time I used Linux-2.6.23-rc1-git11 with config for my desktop plus MTD selected as M. Previous config was for my router. Let me know if You need desktop config too. CC [M] drivers/mtd/mtdcore.o CC [M] drivers/mtd/mtdsuper.o CC [M] drivers/mtd/mtdchar.o CC [M] drivers/mtd/mtd_blkdevs.o CC [M] drivers/mtd/mtdblock.o [...] CC drivers/mtd/chips/chipreg.mod.o LD [M] drivers/mtd/chips/chipreg.ko CC drivers/mtd/devices/block2mtd.mod.o LD [M] drivers/mtd/devices/block2mtd.ko CC drivers/mtd/mtd_blkdevs.mod.o LD [M] drivers/mtd/mtd_blkdevs.ko CC drivers/mtd/mtdblock.mod.o LD [M] drivers/mtd/mtdblock.ko CC drivers/mtd/mtdchar.mod.o LD [M] drivers/mtd/mtdchar.ko CC drivers/mtd/mtdcore.mod.o LD [M] drivers/mtd/mtdcore.ko CC drivers/mtd/mtdsuper.mod.o LD [M] drivers/mtd/mtdsuper.ko % ls *.ko mtd_blkdevs.ko mtdblock.ko mtdchar.ko mtdcore.ko mtdsuper.ko Could also be a make/toolchain issue at your end, for all I know. I'm using Arch Linux now. % make -v GNU Make 3.81 [...] This program built for i686-pc-linux-gnu % gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.2.1 20070704 (prerelease) % ld -v GNU ld version 2.17 Satyam Rafał -- Jak najszybciej dostac sie na wymarzona plaze? Znajdz trase ekspresowa http://link.interia.pl/f1b0d - 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: CS5530 Alsa driver fails
The 5530 in native mode only generates SMI. I've always felt however that if you make the buffers big enough you ought to be able to drive it off the 1KHz timer tick by polling. Interesting project. Looks like somebody did it already. I will try it as soon as I can. You btw won't have removed the SMM firmware or the box wouldn't boot. The 5530 uses SMM to emulate some of the most basic PC components including the VGA video. Hmm. I don't have VGA. Linux was always starting without VGA console. I had to disable display (power off the DAC's) because of constant Checking FLASH screen. Alan Rafał -- Sprawdz czy Ty i Twoj partner pasujecie do siebie emocjonalnie i seksualnie http://link.interia.pl/f1b14 - 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/
JFFS2 BUG
Hi, I can't find JFFS2 maintainer so I'm sending it to MTD maintainer. I don't have luck in this week :-( Linux: 2.6.23-rc1-git3 (2.6.22.1 patched - that's why version is wrong) Command which caused BUG(): chmod o+r * ezri user.warn kernel: argh. node added in wrong place ezri user.alert kernel: BUG: unable to handle kernel paging request at virtual address ffee ezri user.alert kernel: printing eip: ezri user.warn kernel: c68375f4 ezri user.alert kernel: *pde = 00016067 ezri user.alert kernel: *pte = ezri user.emerg kernel: Oops: [#1] ezri user.warn kernel: Modules linked in: jffs2 mtdsuper block2mtd mtdpart mtdcore ezri user.emerg kernel: CPU:0 ezri user.emerg kernel: EIP:0060:[c68375f4]Not tainted VLI ezri user.emerg kernel: EFLAGS: 00210246 (2.6.22.1 #6) ezri user.emerg kernel: EIP is at jffs2_read_dnode+0x2c/0x2ee [jffs2] ezri user.emerg kernel: eax: ffea ebx: c200a000 ecx: edx: c1040140 ezri user.emerg kernel: esi: c0d28990 edi: c0a41000 ebp: c0cde7b0 esp: c1a4dc70 ezri user.emerg kernel: ds: 007b es: 007b fs: gs: 0033 ss: 0068 ezri user.emerg kernel: Process vsftpd (pid: 1324, ti=c1a4c000 task=c16da580 task.ti=c1a4c000) ezri user.emerg kernel: Stack: 000c c1a4dcd8 c268ef9c c683f360 c056ed20 c5244600 ezri user.emerg kernel:fff4 000c 0001 c0a41000 c0cde7b0 c68379b8 c0a41000 ezri user.emerg kernel:1000 c6837d9f c0a41000 c056ed20 c5244600 00011000 1000 ezri user.emerg kernel: Call Trace: ezri user.emerg kernel: [c683f360] jffs2_flash_direct_write+0x22/0x2a [jffs2] ezri user.emerg kernel: [c68379b8] jffs2_read_inode_range+0x102/0x146 [jffs2] ezri user.emerg kernel: [c6837d9f] jffs2_mark_node_obsolete+0x353/0x40f [jffs2] ezri user.emerg kernel: [c010fefc] update_curr+0x232/0x253 ezri user.emerg kernel: [c68364b8] jffs2_do_readpage_nolock+0x54/0x72 [jffs2] ezri user.emerg kernel: [c6836930] jffs2_prepare_write+0x24c/0x274 [jffs2] ezri user.emerg kernel: [c0130e7a] __alloc_pages+0x63/0x292 ezri user.emerg kernel: [c01f237b] skb_copy_datagram_iovec+0x54/0x1d0 ezri user.emerg kernel: [c012e59f] generic_file_buffered_write+0x260/0x5ba ezri user.emerg kernel: [c01ed934] release_sock+0xc/0x74 ezri user.emerg kernel: [c021fb65] tcp_prequeue_process+0x4e/0x5b ezri user.emerg kernel: [c012ed2d] __generic_file_aio_write_nolock+0x434/0x482 ezri user.emerg kernel: [c01eb6df] sock_aio_read+0xc0/0xc8 ezri user.emerg kernel: [c012edd9] generic_file_aio_write+0x5e/0xbf ezri user.emerg kernel: [c0142c67] do_sync_write+0xc6/0x109 ezri user.emerg kernel: [c0120836] autoremove_wake_function+0x0/0x33 ezri user.emerg kernel: [c0122741] enqueue_hrtimer+0x5a/0x62 ezri user.emerg kernel: [c0142ba1] do_sync_write+0x0/0x109 ezri user.emerg kernel: [c01433da] vfs_write+0x8a/0x112 ezri user.emerg kernel: [c0143864] sys_write+0x41/0x67 ezri user.emerg kernel: [c0103bd2] syscall_call+0x7/0xb ezri user.emerg kernel: [c026] sctp_datamsg_from_user+0x297/0x2a7 ezri user.emerg kernel: === ezri user.emerg kernel: Code: 57 56 53 83 ec 28 89 ce 89 44 24 18 89 54 24 14 e8 47 ff ff ff 89 c3 c7 44 24 20 f4 ff ff ff 85 c0 0f 84 ba 02 00 00 8b 06 31 c9 8b 50 04 8d 44 24 24 83 e2 fc 89 44 24 04 8b 44 24 18 89 5c 24 ezri user.emerg kernel: EIP: [c68375f4] jffs2_read_dnode+0x2c/0x2ee [jffs2] SS:ESP 0068:c1a4dc70 ezri user.warn kernel: Node totlen on flash (0x1044) != totlen from node ref (0x0044) ezri user.warn kernel: argh. node added in wrong place ezri user.alert kernel: BUG: unable to handle kernel paging request at virtual address ffee ezri user.alert kernel: printing eip: ezri user.warn kernel: c6837a6c ezri user.alert kernel: *pde = 00016067 ezri user.alert kernel: *pte = ezri user.emerg kernel: Oops: [#2] ezri user.warn kernel: Modules linked in: jffs2 mtdsuper block2mtd mtdpart mtdcore ezri user.emerg kernel: CPU:0 ezri user.emerg kernel: EIP:0060:[c6837a6c]Tainted: G D VLI ezri user.emerg kernel: EFLAGS: 00210282 (2.6.22.1 #6) ezri user.emerg kernel: EIP is at jffs2_mark_node_obsolete+0x20/0x40f [jffs2] ezri user.emerg kernel: eax: c5244600 ebx: ecx: edx: ffea ezri user.emerg kernel: esi: c5244600 edi: c200a048 ebp: ffea esp: c277fce4 ezri user.emerg kernel: ds: 007b es: 007b fs: gs: 0033 ss: 0068 ezri user.emerg kernel: Process vsftpd (pid: 1327, ti=c277e000 task=c16db080 task.ti=c277e000) ezri user.emerg kernel: Stack: c15133b0 c38e2450 c1de43f0 c68372c0 c15133b0 c5244600 c1de4404 ezri user.emerg kernel: c1de43f0 c200a048 c15133b0 c683a7d1 c0cd2800 0327 0003 ezri user.emerg kernel: c5244600 0327 0582 e958 c0cd2800 ezri user.emerg kernel: Call Trace: ezri user.emerg kernel: [c68372c0] jffs2_add_full_dnode_to_inode+0x2a7/0x2d4 [jffs2] ezri user.emerg
Problem with udev and block2mtd
Hi! I have changed static /dev to udev on my machine. It has a lot of RAM (94MB) so I was expecting that udev will not make things worse. Unfortunately udev isn't noticing that new mtd device was born. I was suspecting that this is my fault, but udev's /dev is populated and: UEVENT[1185991604.930847] add@/module/mtdcore UEVENT[1185991604.969089] add@/module/mtdpart UEVENT[1185991605.005954] add@/module/block2mtd UEVENT[1185991647.726551] add@/module/mtdsuper UEVENT[1185991647.783396] add@/module/jffs2 UEVENT[1185991647.801242] add@/slab/jffs2_i UDEV [1185991647.815670] add@/slab/jffs2_i UEVENT[1185991647.827608] add@/slab/:072 UDEV [1185991647.842338] add@/slab/:072 I don't see nothing about new device. Is this situation known? Or this is 2.6.23-rc1-git3 regression? Or is my udev misconfigured? Regards Rafał -- Wszystko czego potrzebujesz latem: kremy do opalania, stroje kapielowe, maly romans http://link.interia.pl/f1b15 - 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: CS5530 Alsa driver fails
Hi Rafał, It seems that you're already using irq 9 for another device, and as Alan says the cs5530 audio device doesn't seem to do irq sharing. It seems to me that you need to go into your BIOS settings at startup and tell the device to use an irq line that's not already in use by some other device. Can you please let me know if this works? Sorry, I should mention earlier that this is Wyse 3360SE. I don't know how to enter BIOS (if there is any). The ALSA CS5530 driver is one that I ported from Alan's OSS Kahlua driver, so there may be some things that I've missed. If the above advice doesn't work, please confirm whether or not the device is functioning correctly in your current set up with Alan's original OSS driver. I will give up. I didn't checked code earlier. This driver is using SMM. Probably firmware isn't what it should be, or I have overwritten it when I was flashing Linux. I see in datasheet that it isn't possible to write driver in other way. Sadly sound card is generating SMI only. Thanks, Ash Thank You Rafał -- Dowiedz sie, co naprawde podnieca kobiety. Wiecej wiesz, latwiej je oczarujesz http://link.interia.pl/f1b17 - 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] mtdsuper: licensce = GPL
block2mtd: version $Revision: 1.30 $
block2mtd: mtd0: [d: /dev/sdc2] erase_size = 64KiB [65536]
mtdsuper: module license 'unspecified' taints kernel.
mtdsuper: Unknown symbol get_mtd_device
mtdsuper: Unknown symbol put_mtd_device
jffs2: Unknown symbol get_sb_mtd
jffs2: Unknown symbol kill_mtd_super
Signed-off-by: Rafał Bilski <[EMAIL PROTECTED]>
---
drivers/mtd/mtdsuper.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/mtdsuper.c b/drivers/mtd/mtdsuper.c
index aca3319..3510ed0 100644
--- a/drivers/mtd/mtdsuper.c
+++ b/drivers/mtd/mtdsuper.c
@@ -230,3 +230,5 @@ void kill_mtd_super(struct super_block *sb)
}
EXPORT_SYMBOL_GPL(kill_mtd_super);
+MODULE_LICENSE("GPL");
+
--
--
Zmien konto na takie o nieograniczonej pojemnosci.
Za darmo w INTERIA.PL
http://link.interia.pl/f1b0a
-
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: CS5530 Alsa driver fails
Might be worth setting the IRQ to sharable. I've never seen a 5530 with the sound IRQ shared so I don't know if that works and is a valid configuration for the VSA firmware The relevant patch is below. Please give it a try. Takashi - if (request_irq(irq, irq_handler, hardware == SB_HW_ALS4000 ? + if (request_irq(irq, irq_handler, + (hardware == SB_HW_ALS4000 || +hardware == SB_HW_CS5530) ? CS5530: XpressAudio at 0x220 CS5530: MPU at 0x330 CS5530: IRQ: 9 DMA8: 0 DMA16: 5 ALSA sound/isa/sb/sb_common.c:91: snd_sbdsp_reset [0x220] failed... CS5530: Could not create SoundBlaster Does this mean that interrupt cannot be shared? Or is this something worse? Thanks Rafał -- Dowiedz sie, co naprawde podnieca kobiety. Wiecej wiesz, latwiej je oczarujesz http://link.interia.pl/f1b17 - 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: CS5530 Alsa driver fails
Might be worth setting the IRQ to sharable. I've never seen a 5530 with the sound IRQ shared so I don't know if that works and is a valid configuration for the VSA firmware The relevant patch is below. Please give it a try. Takashi - if (request_irq(irq, irq_handler, hardware == SB_HW_ALS4000 ? + if (request_irq(irq, irq_handler, + (hardware == SB_HW_ALS4000 || +hardware == SB_HW_CS5530) ? CS5530: XpressAudio at 0x220 CS5530: MPU at 0x330 CS5530: IRQ: 9 DMA8: 0 DMA16: 5 ALSA sound/isa/sb/sb_common.c:91: snd_sbdsp_reset [0x220] failed... CS5530: Could not create SoundBlaster Does this mean that interrupt cannot be shared? Or is this something worse? Thanks Rafał -- Dowiedz sie, co naprawde podnieca kobiety. Wiecej wiesz, latwiej je oczarujesz http://link.interia.pl/f1b17 - 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] mtdsuper: licensce = GPL
block2mtd: version $Revision: 1.30 $ block2mtd: mtd0: [d: /dev/sdc2] erase_size = 64KiB [65536] mtdsuper: module license 'unspecified' taints kernel. mtdsuper: Unknown symbol get_mtd_device mtdsuper: Unknown symbol put_mtd_device jffs2: Unknown symbol get_sb_mtd jffs2: Unknown symbol kill_mtd_super Signed-off-by: Rafał Bilski [EMAIL PROTECTED] --- drivers/mtd/mtdsuper.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/mtdsuper.c b/drivers/mtd/mtdsuper.c index aca3319..3510ed0 100644 --- a/drivers/mtd/mtdsuper.c +++ b/drivers/mtd/mtdsuper.c @@ -230,3 +230,5 @@ void kill_mtd_super(struct super_block *sb) } EXPORT_SYMBOL_GPL(kill_mtd_super); +MODULE_LICENSE(GPL); + -- -- Zmien konto na takie o nieograniczonej pojemnosci. Za darmo w INTERIA.PL http://link.interia.pl/f1b0a - 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: CS5530 Alsa driver fails
Hi Rafał, It seems that you're already using irq 9 for another device, and as Alan says the cs5530 audio device doesn't seem to do irq sharing. It seems to me that you need to go into your BIOS settings at startup and tell the device to use an irq line that's not already in use by some other device. Can you please let me know if this works? Sorry, I should mention earlier that this is Wyse 3360SE. I don't know how to enter BIOS (if there is any). The ALSA CS5530 driver is one that I ported from Alan's OSS Kahlua driver, so there may be some things that I've missed. If the above advice doesn't work, please confirm whether or not the device is functioning correctly in your current set up with Alan's original OSS driver. I will give up. I didn't checked code earlier. This driver is using SMM. Probably firmware isn't what it should be, or I have overwritten it when I was flashing Linux. I see in datasheet that it isn't possible to write driver in other way. Sadly sound card is generating SMI only. Thanks, Ash Thank You Rafał -- Dowiedz sie, co naprawde podnieca kobiety. Wiecej wiesz, latwiej je oczarujesz http://link.interia.pl/f1b17 - 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/
Problem with udev and block2mtd
Hi! I have changed static /dev to udev on my machine. It has a lot of RAM (94MB) so I was expecting that udev will not make things worse. Unfortunately udev isn't noticing that new mtd device was born. I was suspecting that this is my fault, but udev's /dev is populated and: UEVENT[1185991604.930847] add@/module/mtdcore UEVENT[1185991604.969089] add@/module/mtdpart UEVENT[1185991605.005954] add@/module/block2mtd UEVENT[1185991647.726551] add@/module/mtdsuper UEVENT[1185991647.783396] add@/module/jffs2 UEVENT[1185991647.801242] add@/slab/jffs2_i UDEV [1185991647.815670] add@/slab/jffs2_i UEVENT[1185991647.827608] add@/slab/:072 UDEV [1185991647.842338] add@/slab/:072 I don't see nothing about new device. Is this situation known? Or this is 2.6.23-rc1-git3 regression? Or is my udev misconfigured? Regards Rafał -- Wszystko czego potrzebujesz latem: kremy do opalania, stroje kapielowe, maly romans http://link.interia.pl/f1b15 - 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/
CS5530 Alsa driver fails
Hello, Linux: 2.6.23-rc1-git3 Hardware: CX5530 After "modprobe snd-cs5530" I have: CS5530: XpressAudio at 0x220 CS5530: MPU at 0x330 CS5530: IRQ: 9 DMA8: 0 DMA16: 5 sb: can't grab irq 9 CS5530: Could not create SoundBlaster CS5530_Audio: probe of :00:12.3 failed with error -16 Thank You Rafał ~ $ cat /proc/interrupts CPU0 0: 26624XT-PIC-XTtimer 2: 0XT-PIC-XTcascade 4:428XT-PIC-XTserial 8: 0XT-PIC-XTrtc 9: 10793XT-PIC-XTohci_hcd:usb1 10: 1326XT-PIC-XTeth0 NMI: 0 ERR: 0 ~ $ lspci -v 00:00.0 Host bridge: Cyrix Corporation PCI Master Flags: bus master, medium devsel, latency 0 00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller Subsystem: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at f800 [size=256] Memory at 1001 (32-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at 1000 [disabled] [size=64K] Capabilities: [40] Power Management version 2 00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] Flags: bus master, medium devsel, latency 0 00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua] Flags: medium devsel Memory at 40012000 (32-bit, non-prefetchable) [size=256] 00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua] (prog-if 80 [Master]) Flags: medium devsel [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at 1000 [disabled] [size=128] 00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua] Flags: medium devsel Memory at 40011000 (32-bit, non-prefetchable) [size=128] 00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua] (prog-if 00 [VGA]) Flags: medium devsel Memory at 4001 (32-bit, non-prefetchable) [size=4K] 00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev 06) (prog-if 10 [OHCI]) Subsystem: Compaq Computer Corporation ZFMicro Chipset USB Flags: bus master, medium devsel, latency 64, IRQ 9 Memory at 000cc000 (32-bit, non-prefetchable) [size=4K] -- Kobiety klamia o wiele skuteczniej niz mezczyzni. Sprawdz, jak sie na nich poznac http://link.interia.pl/f1b16 - 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/
CS5530 Alsa driver fails
Hello, Linux: 2.6.23-rc1-git3 Hardware: CX5530 After modprobe snd-cs5530 I have: CS5530: XpressAudio at 0x220 CS5530: MPU at 0x330 CS5530: IRQ: 9 DMA8: 0 DMA16: 5 sb: can't grab irq 9 CS5530: Could not create SoundBlaster CS5530_Audio: probe of :00:12.3 failed with error -16 Thank You Rafał ~ $ cat /proc/interrupts CPU0 0: 26624XT-PIC-XTtimer 2: 0XT-PIC-XTcascade 4:428XT-PIC-XTserial 8: 0XT-PIC-XTrtc 9: 10793XT-PIC-XTohci_hcd:usb1 10: 1326XT-PIC-XTeth0 NMI: 0 ERR: 0 ~ $ lspci -v 00:00.0 Host bridge: Cyrix Corporation PCI Master Flags: bus master, medium devsel, latency 0 00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller Subsystem: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at f800 [size=256] Memory at 1001 (32-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at 1000 [disabled] [size=64K] Capabilities: [40] Power Management version 2 00:12.0 ISA bridge: Cyrix Corporation 5530 Legacy [Kahlua] Flags: bus master, medium devsel, latency 0 00:12.1 Bridge: Cyrix Corporation 5530 SMI [Kahlua] Flags: medium devsel Memory at 40012000 (32-bit, non-prefetchable) [size=256] 00:12.2 IDE interface: Cyrix Corporation 5530 IDE [Kahlua] (prog-if 80 [Master]) Flags: medium devsel [virtual] Memory at 01f0 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 03f0 (type 3, non-prefetchable) [disabled] [size=1] [virtual] Memory at 0170 (32-bit, non-prefetchable) [disabled] [size=8] [virtual] Memory at 0370 (type 3, non-prefetchable) [disabled] [size=1] I/O ports at 1000 [disabled] [size=128] 00:12.3 Multimedia audio controller: Cyrix Corporation 5530 Audio [Kahlua] Flags: medium devsel Memory at 40011000 (32-bit, non-prefetchable) [size=128] 00:12.4 VGA compatible controller: Cyrix Corporation 5530 Video [Kahlua] (prog-if 00 [VGA]) Flags: medium devsel Memory at 4001 (32-bit, non-prefetchable) [size=4K] 00:13.0 USB Controller: Compaq Computer Corporation ZFMicro Chipset USB (rev 06) (prog-if 10 [OHCI]) Subsystem: Compaq Computer Corporation ZFMicro Chipset USB Flags: bus master, medium devsel, latency 64, IRQ 9 Memory at 000cc000 (32-bit, non-prefetchable) [size=4K] -- Kobiety klamia o wiele skuteczniej niz mezczyzni. Sprawdz, jak sie na nich poznac http://link.interia.pl/f1b16 - 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] Hardware MPEG audio fix for SAA7134 based "KNC One TV-Station DVR" card
With previous patch card is generating MPEG audio stream too. Unfortunatly I2S audio output is muted. Unmute it. Signed-off-by: Rafal Bilski <[EMAIL PROTECTED]> --- drivers/media/video/saa7134/saa7134-empress.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/saa7134/saa7134-empress.c b/drivers/media/video/saa7134/saa7134-empress.c --- a/drivers/media/video/saa7134/saa7134-empress.c +++ b/drivers/media/video/saa7134/saa7134-empress.c @@ -96,6 +96,10 @@ static int ts_open(struct inode *inode, struct file *file) if (dev->empress_users) goto done_up; + /* Unmute audio */ + saa_writeb(SAA7134_AUDIO_MUTE_CTRL, + saa_readb(SAA7134_AUDIO_MUTE_CTRL) & ~(1 << 6)); + dev->empress_users++; file->private_data = dev; err = 0; @@ -121,6 +125,10 @@ static int ts_release(struct inode *inode, struct file *file) /* stop the encoder */ ts_reset_encoder(dev); + /* Mute audio */ + saa_writeb(SAA7134_AUDIO_MUTE_CTRL, + saa_readb(SAA7134_AUDIO_MUTE_CTRL) | (1 << 6)); + mutex_unlock(>empress_tsq.lock); return 0; } -- -- W sklepie orange.pl dostaniesz wiecej minut na rozmowy i telefon od 1 zl. Kup on-line >>> http://link.interia.pl/f1aad - 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] Alsa fix for SAA7134 based "KNC One TV-Station DVR" card
Sound recording doesn't work for this card because ACNI and ACPF
are not set before snd_card_saa7134_capture_prepare(). As a result
timeout occurs. These registers aren't poked because thread
never gets wake up signal. ACNI initialization is done in the
thread.
Sound is muted when capture stops. Shouldn't be because it may
be used during TV playback.
Signed-off-by: Rafal Bilski <[EMAIL PROTECTED]>
---
drivers/media/video/saa7134/saa7134-alsa.c | 16 +++-
drivers/media/video/saa7134/saa7134-cards.c |2 +-
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c
b/drivers/media/video/saa7134/saa7134-alsa.c
--- a/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/drivers/media/video/saa7134/saa7134-alsa.c
@@ -75,7 +75,8 @@ typedef struct snd_card_saa7134 {
struct saa7134_dev *dev;
unsigned long iobase;
- int irq;
+ s16 irq;
+ u16 mute_was_on;
spinlock_t lock;
} snd_card_saa7134_t;
@@ -589,8 +590,10 @@ static int snd_card_saa7134_capture_close(struct
snd_pcm_substream * substream)
snd_card_saa7134_t *saa7134 = snd_pcm_substream_chip(substream);
struct saa7134_dev *dev = saa7134->dev;
- dev->ctl_mute = 1;
- saa7134_tvaudio_setmute(dev);
+ if (saa7134->mute_was_on) {
+ dev->ctl_mute = 1;
+ saa7134_tvaudio_setmute(dev);
+ }
return 0;
}
@@ -637,8 +640,11 @@ static int snd_card_saa7134_capture_open(struct
snd_pcm_substream * substream)
runtime->private_free = snd_card_saa7134_runtime_free;
runtime->hw = snd_card_saa7134_capture;
- dev->ctl_mute = 0;
- saa7134_tvaudio_setmute(dev);
+ if (dev->ctl_mute != 0) {
+ saa7134->mute_was_on = 1;
+ dev->ctl_mute = 0;
+ saa7134_tvaudio_setmute(dev);
+ }
if ((err = snd_pcm_hw_constraint_integer(runtime,
SNDRV_PCM_HW_PARAM_PERIODS)) < 0)
return err;
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -400,7 +400,7 @@ struct saa7134_board saa7134_boards[] = {
.inputs = {{
.name = name_tv,
.vmux = 1,
- .amux = LINE2,
+ .amux = TV,
.tv = 1,
.gpio = 0x2,
},{
--
--
Ile masz w domu niepotrzebnych rzeczy?
Wymien sie z sasiadami >> http://link.interia.pl/f1a93
-
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] Alsa fix for SAA7134 based KNC One TV-Station DVR card
Sound recording doesn't work for this card because ACNI and ACPF
are not set before snd_card_saa7134_capture_prepare(). As a result
timeout occurs. These registers aren't poked because thread
never gets wake up signal. ACNI initialization is done in the
thread.
Sound is muted when capture stops. Shouldn't be because it may
be used during TV playback.
Signed-off-by: Rafal Bilski [EMAIL PROTECTED]
---
drivers/media/video/saa7134/saa7134-alsa.c | 16 +++-
drivers/media/video/saa7134/saa7134-cards.c |2 +-
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c
b/drivers/media/video/saa7134/saa7134-alsa.c
--- a/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/drivers/media/video/saa7134/saa7134-alsa.c
@@ -75,7 +75,8 @@ typedef struct snd_card_saa7134 {
struct saa7134_dev *dev;
unsigned long iobase;
- int irq;
+ s16 irq;
+ u16 mute_was_on;
spinlock_t lock;
} snd_card_saa7134_t;
@@ -589,8 +590,10 @@ static int snd_card_saa7134_capture_close(struct
snd_pcm_substream * substream)
snd_card_saa7134_t *saa7134 = snd_pcm_substream_chip(substream);
struct saa7134_dev *dev = saa7134-dev;
- dev-ctl_mute = 1;
- saa7134_tvaudio_setmute(dev);
+ if (saa7134-mute_was_on) {
+ dev-ctl_mute = 1;
+ saa7134_tvaudio_setmute(dev);
+ }
return 0;
}
@@ -637,8 +640,11 @@ static int snd_card_saa7134_capture_open(struct
snd_pcm_substream * substream)
runtime-private_free = snd_card_saa7134_runtime_free;
runtime-hw = snd_card_saa7134_capture;
- dev-ctl_mute = 0;
- saa7134_tvaudio_setmute(dev);
+ if (dev-ctl_mute != 0) {
+ saa7134-mute_was_on = 1;
+ dev-ctl_mute = 0;
+ saa7134_tvaudio_setmute(dev);
+ }
if ((err = snd_pcm_hw_constraint_integer(runtime,
SNDRV_PCM_HW_PARAM_PERIODS)) 0)
return err;
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -400,7 +400,7 @@ struct saa7134_board saa7134_boards[] = {
.inputs = {{
.name = name_tv,
.vmux = 1,
- .amux = LINE2,
+ .amux = TV,
.tv = 1,
.gpio = 0x2,
},{
--
--
Ile masz w domu niepotrzebnych rzeczy?
Wymien sie z sasiadami http://link.interia.pl/f1a93
-
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] Hardware MPEG audio fix for SAA7134 based KNC One TV-Station DVR card
With previous patch card is generating MPEG audio stream too. Unfortunatly I2S audio output is muted. Unmute it. Signed-off-by: Rafal Bilski [EMAIL PROTECTED] --- drivers/media/video/saa7134/saa7134-empress.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/saa7134/saa7134-empress.c b/drivers/media/video/saa7134/saa7134-empress.c --- a/drivers/media/video/saa7134/saa7134-empress.c +++ b/drivers/media/video/saa7134/saa7134-empress.c @@ -96,6 +96,10 @@ static int ts_open(struct inode *inode, struct file *file) if (dev-empress_users) goto done_up; + /* Unmute audio */ + saa_writeb(SAA7134_AUDIO_MUTE_CTRL, + saa_readb(SAA7134_AUDIO_MUTE_CTRL) ~(1 6)); + dev-empress_users++; file-private_data = dev; err = 0; @@ -121,6 +125,10 @@ static int ts_release(struct inode *inode, struct file *file) /* stop the encoder */ ts_reset_encoder(dev); + /* Mute audio */ + saa_writeb(SAA7134_AUDIO_MUTE_CTRL, + saa_readb(SAA7134_AUDIO_MUTE_CTRL) | (1 6)); + mutex_unlock(dev-empress_tsq.lock); return 0; } -- -- W sklepie orange.pl dostaniesz wiecej minut na rozmowy i telefon od 1 zl. Kup on-line http://link.interia.pl/f1aad - 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/
Problem with SAA7134 driver
Hi! I have bought recently 00:14.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: KNC One KNC One TV-Station DVR Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at d6003000 (32-bit, non-prefetchable) [size=1K] Capabilities: [40] Power Management version 1 It was very cheap - 12 euro. I couldn't resist because it has hardware MPEG2 video and audio encoder. TV is working OK. I have video and analog audio. But saa7134-alsa driver wasn't working and audio stream wasn't present in MPEG-TS stream. After receiving "User guide" from NXP I have started to dig in driver. Problem is caused by ACNI and ACPF not set before snd_card_saa7134_capture_prepare(). If I set them manually in this function then DMA capture is starting to working and audio stream is present in MPEG-TS. Unfortunatly MPlayer can't play audio from this stream. Also I have to set 32.11MHz as master clock, but driver is using 24.576MHz for this card? I see that ACNI is set in saa7134-tvaudio.c/tvaudio_init(). How it gets cleared? I will dig further, but if somebody has any idea... Would be OK to make saa7134-empress driver MPlayer compatible? All MPlayer needs is audio input (now present) and info about current standard. I see that at least one other driver has MPlayer compatibility. Please CC me. Rafał saa7130/34: v4l2 driver version 0.2.14 loaded saa7134[0]: found at :00:14.0, rev: 1, irq: 11, latency: 32, mmio: 0xd6003000 saa7134[0]: subsystem: 1894:a006, board: KNC One TV-Station DVR [card=24,autodetected] saa7134[0]: board init: gpio is 83 saa7134[0]: i2c eeprom 00: 94 18 06 a0 06 80 00 01 00 00 00 00 00 00 01 00 saa7134[0]: i2c eeprom 10: 00 ff 86 0e ff 20 ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 20: 01 40 01 02 02 03 01 03 06 ff 01 df ff ff ff ff saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 40: ff 05 00 c0 86 ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 70: 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner 1-0043: chip found @ 0x86 (saa7134[0]) tda9887 1-0043: tda988[5/6/7] found @ 0x43 (tuner) tuner 1-0060: All bytes are equal. It is not a TEA5767 tuner 1-0060: chip found @ 0xc0 (saa7134[0]) tuner 1-0060: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3)) tuner 1-0060: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3)) saa6752hs 1-0020: saa6752hs: chip found @ 0x40 saa7134[0]: registered device video0 [v4l2] saa7134[0]: registered device vbi0 saa7134[0]: registered device radio0 -- Po meczu.kurde...:) >>> http://link.interia.pl/f1a72 - 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/
Problem with SAA7134 driver
Hi! I have bought recently 00:14.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: KNC One KNC One TV-Station DVR Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at d6003000 (32-bit, non-prefetchable) [size=1K] Capabilities: [40] Power Management version 1 It was very cheap - 12 euro. I couldn't resist because it has hardware MPEG2 video and audio encoder. TV is working OK. I have video and analog audio. But saa7134-alsa driver wasn't working and audio stream wasn't present in MPEG-TS stream. After receiving User guide from NXP I have started to dig in driver. Problem is caused by ACNI and ACPF not set before snd_card_saa7134_capture_prepare(). If I set them manually in this function then DMA capture is starting to working and audio stream is present in MPEG-TS. Unfortunatly MPlayer can't play audio from this stream. Also I have to set 32.11MHz as master clock, but driver is using 24.576MHz for this card? I see that ACNI is set in saa7134-tvaudio.c/tvaudio_init(). How it gets cleared? I will dig further, but if somebody has any idea... Would be OK to make saa7134-empress driver MPlayer compatible? All MPlayer needs is audio input (now present) and info about current standard. I see that at least one other driver has MPlayer compatibility. Please CC me. Rafał saa7130/34: v4l2 driver version 0.2.14 loaded saa7134[0]: found at :00:14.0, rev: 1, irq: 11, latency: 32, mmio: 0xd6003000 saa7134[0]: subsystem: 1894:a006, board: KNC One TV-Station DVR [card=24,autodetected] saa7134[0]: board init: gpio is 83 saa7134[0]: i2c eeprom 00: 94 18 06 a0 06 80 00 01 00 00 00 00 00 00 01 00 saa7134[0]: i2c eeprom 10: 00 ff 86 0e ff 20 ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 20: 01 40 01 02 02 03 01 03 06 ff 01 df ff ff ff ff saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 40: ff 05 00 c0 86 ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 70: 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner 1-0043: chip found @ 0x86 (saa7134[0]) tda9887 1-0043: tda988[5/6/7] found @ 0x43 (tuner) tuner 1-0060: All bytes are equal. It is not a TEA5767 tuner 1-0060: chip found @ 0xc0 (saa7134[0]) tuner 1-0060: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3)) tuner 1-0060: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3)) saa6752hs 1-0020: saa6752hs: chip found @ 0x40 saa7134[0]: registered device video0 [v4l2] saa7134[0]: registered device vbi0 saa7134[0]: registered device radio0 -- Po meczu.kurde...:) http://link.interia.pl/f1a72 - 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: NOHZ: local_softirq_pending 08
>> Hi! >> >> A lot of "NOHZ: local_softirq_pending 08" messages (about 100) and >> then suddenly stoped to show. I have 2.6.21.1. I checked .2 and .3 >> changelogs but I don't see anything about this message. >> What does it mean? >> >> Is "08" IRQ number? >> 8: 2XT-PIC-XTrtc >> >> Please CC me. > Does this patch [ http://lkml.org/lkml/2007/5/22/35 ] helps you fix it ? > > Regards > Ananitya Thanks. Looks like it will. Regards Rafał -- Ile masz w domu niepotrzebnych rzeczy? Wymien sie z sasiadami >> http://link.interia.pl/f1a93 - 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: NOHZ: local_softirq_pending 08
Hi! A lot of NOHZ: local_softirq_pending 08 messages (about 100) and then suddenly stoped to show. I have 2.6.21.1. I checked .2 and .3 changelogs but I don't see anything about this message. What does it mean? Is 08 IRQ number? 8: 2XT-PIC-XTrtc Please CC me. Does this patch [ http://lkml.org/lkml/2007/5/22/35 ] helps you fix it ? Regards Ananitya Thanks. Looks like it will. Regards Rafał -- Ile masz w domu niepotrzebnych rzeczy? Wymien sie z sasiadami http://link.interia.pl/f1a93 - 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/
NOHZ: local_softirq_pending 08
Hi! A lot of "NOHZ: local_softirq_pending 08" messages (about 100) and then suddenly stoped to show. I have 2.6.21.1. I checked .2 and .3 changelogs but I don't see anything about this message. What does it mean? Is "08" IRQ number? 8: 2XT-PIC-XTrtc Please CC me. Thank You Rafał -- Ile masz w domu niepotrzebnych rzeczy? Wymien sie z sasiadami >> http://link.interia.pl/f1a93 - 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/
NOHZ: local_softirq_pending 08
Hi! A lot of NOHZ: local_softirq_pending 08 messages (about 100) and then suddenly stoped to show. I have 2.6.21.1. I checked .2 and .3 changelogs but I don't see anything about this message. What does it mean? Is 08 IRQ number? 8: 2XT-PIC-XTrtc Please CC me. Thank You Rafał -- Ile masz w domu niepotrzebnych rzeczy? Wymien sie z sasiadami http://link.interia.pl/f1a93 - 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/
Problem with 82365SL driver in 2.6.21.1
Hello, I have problem with PC card slot in Wyse 3360SE terminal. Card insertion or removal is detected, but nothing more. I tried two different cards. Same behaviour. Hardware is: > Intel ISA PCIC probe: > Intel i82365sl A step ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 1 socket > host opts [0]: none > ISA irqs (default) = 3,4,5,7,9,10,11,12,14,15 polling interval = 1000 ms Dmesg after inserting card: > pccard: PCMCIA card inserted into slot 0 I have similar hardware in other machine: > Intel i82365sl B step ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets >host opts [0]: none >host opts [1]: none >ISA irqs (scanned) = 3,4,7,9,11,12 status change on irq 11 Which is working: > pccard: PCMCIA card inserted into slot 0 > cs: memory probe 0x0d-0x0d: excluding 0xd-0xd1fff > cs: memory probe 0x0e-0x0e: clean. > pcmcia: registering new device pcmcia0.0 I checked 82365 registers. Wyse has 0x82 at offset 0 and 0 at offset 6. In working case it is 0x83 at offset 0 and 1 at offset 6. Next differences at and above 0x10 offset. I tried all "pccardctl" options. No change. Please point me direction in which I should search for solution. I don't know if it is important: after reboot 82365 isn't detected at all on Wyse. Please CC me. Thank You Rafał -- Daj ogloszenie za darmo do nowego serwisu Populada >>>http://link.interia.pl/f1a89 - 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/
Problem with 82365SL driver in 2.6.21.1
Hello, I have problem with PC card slot in Wyse 3360SE terminal. Card insertion or removal is detected, but nothing more. I tried two different cards. Same behaviour. Hardware is: Intel ISA PCIC probe: Intel i82365sl A step ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 1 socket host opts [0]: none ISA irqs (default) = 3,4,5,7,9,10,11,12,14,15 polling interval = 1000 ms Dmesg after inserting card: pccard: PCMCIA card inserted into slot 0 I have similar hardware in other machine: Intel i82365sl B step ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets host opts [0]: none host opts [1]: none ISA irqs (scanned) = 3,4,7,9,11,12 status change on irq 11 Which is working: pccard: PCMCIA card inserted into slot 0 cs: memory probe 0x0d-0x0d: excluding 0xd-0xd1fff cs: memory probe 0x0e-0x0e: clean. pcmcia: registering new device pcmcia0.0 I checked 82365 registers. Wyse has 0x82 at offset 0 and 0 at offset 6. In working case it is 0x83 at offset 0 and 1 at offset 6. Next differences at and above 0x10 offset. I tried all pccardctl options. No change. Please point me direction in which I should search for solution. I don't know if it is important: after reboot 82365 isn't detected at all on Wyse. Please CC me. Thank You Rafał -- Daj ogloszenie za darmo do nowego serwisu Populada http://link.interia.pl/f1a89 - 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] Longhaul - Broken again
Not so long ago Longhaul was marked broken, because to protect system from lockup it was clearing BMDMA master bit on each device. Later I came with patches which make use of hardware support present in VIA north and south bridges. Unfortunately after some time this support seems to be broken for many cases. First report was for older model of Epia mainboard and seemed to be only case. There is no explanation for it. Hardware is exactly the same as for my M1, with exception of one additional NIC. There is no way to detect broken chipsets. All hardware revisions are exactly the same as on perfectly working system. Yesterday Longhaul was reported as broken for VIA Eden ESP 7000 CPU (http://lkml.org/lkml/2007/5/4/115). Transition is successful, but lock up is only question of short time. CPU has Nehemiah core and it is claiming that it is supporting Longhaul MSR. And it is true. Info in Longhaul MSR is correct. Yesterday Longhaul was reported to cause lockup. Looks like chipset is blocking AGP DMA, internal PCI DMA and processor access to PCI bus, but it is granting DMA request to additional PCI card (Hauppauge PVR150). Reported by Wander Winkelhorst. Yesterday Longhaul was reported to cause lockup after 2 or 3 hours of use (http://lkml.org/lkml/2007/5/4/513). It may sound great on Windows(tm) based systems, but for Linux it is unacceptable short time. Probably there are many more systems on which Longhaul is causing trouble directly, by lockup during transition, or triggering bug in other hardware. Simply it wasn't reported as broken so far. Even if there are systems on which Longhaul is perfectly OK (I'm writting from such system now) there is no place for it in the kernel because there is no way to know how to setup hardware to correct state (looks like it is more than one bit or register) and there is no way to detect broken hardware (looks like there is more then one revision). Signed-off-by: Rafal Bilski <[EMAIL PROTECTED]> --- arch/i386/kernel/cpu/cpufreq/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/i386/kernel/cpu/cpufreq/Kconfig b/arch/i386/kernel/cpu/cpufreq/Kconfig --- a/arch/i386/kernel/cpu/cpufreq/Kconfig +++ b/arch/i386/kernel/cpu/cpufreq/Kconfig @@ -206,7 +206,7 @@ config X86_LONGRUN config X86_LONGHAUL tristate "VIA Cyrix III Longhaul" select CPU_FREQ_TABLE - depends on ACPI_PROCESSOR + depends on ACPI_PROCESSOR && BROKEN help This adds the CPUFreq driver for VIA Samuel/CyrixIII, VIA Cyrix Samuel/C3, VIA Cyrix Ezra and VIA Cyrix Ezra-T -- -- Kasia Cichopek eksponuje biust >>> http://link.interia.pl/f1a6f - 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: cpufreq longhaul locks up
>> Well. You have very good CPU - 4,4W typical and 6,0W is a factory maximum. > > Says who? TM5800 draws around 2.0W (or even less) when idle [333 MHz]. :) > Though it has a different hardware engine than most x86. Datasheet. It says that Your CPU needs 4,4W (typical) when 100% busy. -- NIE KUPUJ!!! ...zanim nie porownasz cen >> http://link.interia.pl/f1a5e - 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: cpufreq longhaul locks up
> Nevermind, it does not look like it gets any cooler at lower frequencies, > so it's a nobrainer to run it at the default 733. Well. You have very good CPU - 4,4W typical and 6,0W is a factory maximum. My is eating 6,78W while *sleeping* at 1GHz or about 5W while *sleeping* at 533MHz. > Jan Rafał -- Wicie, rozumicie Zobacz >>> http://link.interia.pl/f1a74 - 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: cpufreq longhaul locks up
> <6>No local APIC present or hardware disabled > <7>mapped APIC to d000 (011ea000) > <5>Local APIC not detected. Using dummy APIC emulation. I/O APIC is very bad thing with Longhaul, but You don't have local APIC, so it shouldn't be used. > <6>ACPI: Using PIC for interrupt routing Looks like it isn't. > <4>ACPI: PCI Interrupt Link [ALKA] (IRQs *20), disabled. > <4>ACPI: PCI Interrupt Link [ALKB] (IRQs *21) > <4>ACPI: PCI Interrupt Link [ALKC] (IRQs *22) > <4>ACPI: PCI Interrupt Link [ALKD] (IRQs *23), disabled. This is pointing to I/O APIC, but I don't see later that such high interrupts are used. And if I/O APIC would be in use You would have lockup in the moment of transition. I was suspecting: > One of the 2.6.21 regressions was Guilherme's problem seeing his box > lock up when the system detected an unstable TSC and dropped back to > using the HPET. > > In digging deeper, we found the HPET is not actually incrementing on > this system. And in fact, the reason why this issue just cropped up was > because of Thomas's clocksource watchdog code was comparing the TSC to > the HPET (which wasn't moving) and thought the TSC was broken. because I know that VT8237 has HPET built in. But I don't see any lines starting with "hpet: enabled" or something similar. But I don't know what to search for. I didn't have contact with HPET earlier. It is very similar and Your problem with ondemand is starting right after > May 3 19:17:22 cn kernel: Clocksource tsc unstable (delta = -136422685 > ns) I don't see such message as long as "performance" governor is used. Anyway adding "hpet=disable" at boot should confirm for sure that it isn't it. And I think that John already ruled this out by clocksource=acpi_pm. Sorry Rafał --- Linda jako gospodyni domowa - zobacz!!! >>> http://link.interia.pl/f1a79 - 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: cpufreq longhaul locks up
6No local APIC present or hardware disabled 7mapped APIC to d000 (011ea000) 5Local APIC not detected. Using dummy APIC emulation. I/O APIC is very bad thing with Longhaul, but You don't have local APIC, so it shouldn't be used. 6ACPI: Using PIC for interrupt routing Looks like it isn't. 4ACPI: PCI Interrupt Link [ALKA] (IRQs *20), disabled. 4ACPI: PCI Interrupt Link [ALKB] (IRQs *21) 4ACPI: PCI Interrupt Link [ALKC] (IRQs *22) 4ACPI: PCI Interrupt Link [ALKD] (IRQs *23), disabled. This is pointing to I/O APIC, but I don't see later that such high interrupts are used. And if I/O APIC would be in use You would have lockup in the moment of transition. I was suspecting: One of the 2.6.21 regressions was Guilherme's problem seeing his box lock up when the system detected an unstable TSC and dropped back to using the HPET. In digging deeper, we found the HPET is not actually incrementing on this system. And in fact, the reason why this issue just cropped up was because of Thomas's clocksource watchdog code was comparing the TSC to the HPET (which wasn't moving) and thought the TSC was broken. because I know that VT8237 has HPET built in. But I don't see any lines starting with hpet: enabled or something similar. But I don't know what to search for. I didn't have contact with HPET earlier. It is very similar and Your problem with ondemand is starting right after May 3 19:17:22 cn kernel: Clocksource tsc unstable (delta = -136422685 ns) I don't see such message as long as performance governor is used. Anyway adding hpet=disable at boot should confirm for sure that it isn't it. And I think that John already ruled this out by clocksource=acpi_pm. Sorry Rafał --- Linda jako gospodyni domowa - zobacz!!! http://link.interia.pl/f1a79 - 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: cpufreq longhaul locks up
Nevermind, it does not look like it gets any cooler at lower frequencies, so it's a nobrainer to run it at the default 733. Well. You have very good CPU - 4,4W typical and 6,0W is a factory maximum. My is eating 6,78W while *sleeping* at 1GHz or about 5W while *sleeping* at 533MHz. Jan Rafał -- Wicie, rozumicie Zobacz http://link.interia.pl/f1a74 - 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: cpufreq longhaul locks up
Well. You have very good CPU - 4,4W typical and 6,0W is a factory maximum. Says who? TM5800 draws around 2.0W (or even less) when idle [333 MHz]. :) Though it has a different hardware engine than most x86. Datasheet. It says that Your CPU needs 4,4W (typical) when 100% busy. -- NIE KUPUJ!!! ...zanim nie porownasz cen http://link.interia.pl/f1a5e - 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] Longhaul - Broken again
Not so long ago Longhaul was marked broken, because to protect system from lockup it was clearing BMDMA master bit on each device. Later I came with patches which make use of hardware support present in VIA north and south bridges. Unfortunately after some time this support seems to be broken for many cases. First report was for older model of Epia mainboard and seemed to be only case. There is no explanation for it. Hardware is exactly the same as for my M1, with exception of one additional NIC. There is no way to detect broken chipsets. All hardware revisions are exactly the same as on perfectly working system. Yesterday Longhaul was reported as broken for VIA Eden ESP 7000 CPU (http://lkml.org/lkml/2007/5/4/115). Transition is successful, but lock up is only question of short time. CPU has Nehemiah core and it is claiming that it is supporting Longhaul MSR. And it is true. Info in Longhaul MSR is correct. Yesterday Longhaul was reported to cause lockup. Looks like chipset is blocking AGP DMA, internal PCI DMA and processor access to PCI bus, but it is granting DMA request to additional PCI card (Hauppauge PVR150). Reported by Wander Winkelhorst. Yesterday Longhaul was reported to cause lockup after 2 or 3 hours of use (http://lkml.org/lkml/2007/5/4/513). It may sound great on Windows(tm) based systems, but for Linux it is unacceptable short time. Probably there are many more systems on which Longhaul is causing trouble directly, by lockup during transition, or triggering bug in other hardware. Simply it wasn't reported as broken so far. Even if there are systems on which Longhaul is perfectly OK (I'm writting from such system now) there is no place for it in the kernel because there is no way to know how to setup hardware to correct state (looks like it is more than one bit or register) and there is no way to detect broken hardware (looks like there is more then one revision). Signed-off-by: Rafal Bilski [EMAIL PROTECTED] --- arch/i386/kernel/cpu/cpufreq/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/i386/kernel/cpu/cpufreq/Kconfig b/arch/i386/kernel/cpu/cpufreq/Kconfig --- a/arch/i386/kernel/cpu/cpufreq/Kconfig +++ b/arch/i386/kernel/cpu/cpufreq/Kconfig @@ -206,7 +206,7 @@ config X86_LONGRUN config X86_LONGHAUL tristate VIA Cyrix III Longhaul select CPU_FREQ_TABLE - depends on ACPI_PROCESSOR + depends on ACPI_PROCESSOR BROKEN help This adds the CPUFreq driver for VIA Samuel/CyrixIII, VIA Cyrix Samuel/C3, VIA Cyrix Ezra and VIA Cyrix Ezra-T -- -- Kasia Cichopek eksponuje biust http://link.interia.pl/f1a6f - 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: cpufreq longhaul locks up
>> :-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. >> Would be good to check if PLL really can go downto x4,0. Can You >> limit minimal CPU multiplier to 5,0 and check if is stable? If it >> is check 4,5. > > I directly wrote to /sys/devices/system/cpu/cpu0/cpufreq, which > worked better than `cpufreq -u xxx -d xxx`. > > Lockup after 9 minutes. (Perhaps the longest time so far.) Can You send me Your entire boot log with performance governor set? > Jan Rafał -- Po meczu.kurde...:) >>> http://link.interia.pl/f1a72 - 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: cpufreq longhaul locks up
Is patch attached below making things better?
You should see in log that You are using VT8235 support now.
---
arch/i386/kernel/cpu/cpufreq/longhaul.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c
b/arch/i386/kernel/cpu/cpufreq/longhaul.c
index 5548e5b..c3c9096 100644
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
@@ -635,6 +635,8 @@ static int longhaul_setup_vt8235(void)
/* Find VT8235 southbridge */
dev = pci_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8235, NULL);
+ if (dev == NULL)
+ dev = pci_find_device(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_8237, NULL);
if (dev != NULL) {
/* Set transition time to max */
pci_read_config_byte(dev, 0xec, _cmd);
@@ -771,11 +773,11 @@ static int __init longhaul_cpu_init(struct cpufreq_policy
*policy)
}
}
/* Check if northbridge is friendly */
- if (enable_arbiter_disable()) {
+/* if (enable_arbiter_disable()) {
longhaul_flags |= USE_NORTHBRIDGE;
goto print_support_type;
}
- /* Use VT8235 southbridge if present */
+*/ /* Use VT8235 southbridge if present */
if (longhaul_version == TYPE_POWERSAVER && vt8235_present) {
longhaul_flags |= USE_VT8235;
goto print_support_type;
--
--
Wicie, rozumicie
Zobacz >>> http://link.interia.pl/f1a74
-
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: cpufreq longhaul locks up
>> I found one line which wasn't were it should be. Probably this will not >> fix Your problem with powersave governor, but it is a bit related. >> Looks like Longhaul isn't skipping frequency transtition when it is asked >> to set f which is already set. Now after first transition it will not >> try to set same frequency again. Second part contains some magic >> because I don't have CN400 datasheet. It is NDA protected :-( Should >> print You one byte in hex and will try to set one register. I don't >> know if anything will change but it is worth testing. > > Did not help unfortunately. The output the printk line generated was > longhaul: 0x0 > > (Strangely enough, %#02x with glibc outputs "00", not "0x0". > And I would have expected "0x00". Subtleties of the kernel > printk/glibc?) :-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. Would be good to check if PLL really can go downto x4,0. Can You limit minimal CPU multiplier to 5,0 and check if is stable? If it is check 4,5. Please send me below part of Your dmesg too: CPU: After generic identify, caps: 0381b83f CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) CPU: L2 Cache: 64K (32 bytes/line) CPU: After all inits, caps: 0381b93f 00dd "dd" is very important here. > Jan Rafał -- Kasia Cichopek eksponuje biust >>> http://link.interia.pl/f1a6f - 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: cpufreq longhaul locks up
> I just wonder why x86info says I have a C5XL while `modprobe longhaul`
> says it is a C5P.
I have changed names to names which VIA is using.
>
> cn:/dev/shm # ./x86info -v -v
You need to be root and use -a option. I'm interested in:
FCR: MSR: 0x1107=0x9e3f1ad6 : 1000 0011 00011010 11010110
Power management: Powersaver
MSR: 0x110a=0x07ff000d000280f0 : 0111 1101
0010 1000
RevisionID: 0 : Initial revision (Software clock multiplier only, no SoftVID)
Software clock multiplier is disabled
Please send me below part of Your dmesg too:
CPU: After generic identify, caps: 0381b83f
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
CPU: After all inits, caps: 0381b93f
00dd
>
> And the BIOS announces it as a "Via Eden ESP 6000" (as does the manufacturer).
Great. I think that I saw datasheet somewhere.
> Jan
Rafał
--
Wicie, rozumicie
Zobacz >>> http://link.interia.pl/f1a74
-
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: cpufreq longhaul locks up
I found one line which wasn't were it should be. Probably this will not
fix Your problem with powersave governor, but it is a bit related.
Looks like Longhaul isn't skipping frequency transtition when it is asked
to set f which is already set. Now after first transition it will not
try to set same frequency again. Second part contains some magic
because I don't have CN400 datasheet. It is NDA protected :-( Should
print You one byte in hex and will try to set one register. I don't
know if anything will change but it is worth testing.
Fingers crossed
Rafał
---
arch/i386/kernel/cpu/cpufreq/longhaul.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c
b/arch/i386/kernel/cpu/cpufreq/longhaul.c
index 2b030d6..5548e5b 100644
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
@@ -88,6 +88,7 @@ static int clock_ratio[32];
static int eblcr_table[32];
static int longhaul_version;
static struct cpufreq_frequency_table *longhaul_table;
+static unsigned int old_ratio = -1;
#ifdef CONFIG_CPU_FREQ_DEBUG
static char speedbuffer[8];
@@ -252,7 +253,6 @@ static void longhaul_setstate(unsigned int
clock_ratio_index)
{
int speed, mult;
struct cpufreq_freqs freqs;
- static unsigned int old_ratio=-1;
unsigned long flags;
unsigned int pic1_mask, pic2_mask;
@@ -603,7 +603,12 @@ static int enable_arbiter_disable(void)
/* Find CN400 V-Link host bridge */
if (dev == NULL)
dev = pci_find_device(PCI_VENDOR_ID_VIA, 0x7259, NULL);
-
+ if (dev != NULL) {
+ pci_read_config_byte(dev, 0x47, _cmd);
+ printk(KERN_INFO PFX "%#02x\n", pci_cmd);
+ pci_cmd |= 0xf;
+ pci_write_config_byte(dev, 0x47, pci_cmd);
+ }
}
if (dev != NULL) {
/* Enable access to port 0x22 */
--
--
Po meczu.kurde...:)
>>> http://link.interia.pl/f1a72
-
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: cpufreq longhaul locks up
>> Can You send output of x86info program and output of > > Where do I find this? http://www.codemonkey.org.uk/projects/x86info/ It needs msr device support in kernel. -- NIE KUPUJ!!! ...zanim nie porownasz cen >> http://link.interia.pl/f1a5e - 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: cpufreq longhaul locks up
>> Can You send output of x86info program and output of >> lspci command? Longhaul wasn't working for You since 2.6.18 right? > > Output from x86info (I know you didn't ask me, but hey, information > wants to be free) > > x86info v1.20. Dave Jones 2001-2006 > Feedback to <[EMAIL PROTECTED]>. > > Found 1 CPU > -- > Family: 6 Model: 9 Stepping: 8 > CPU Model : VIA C3 (Nehemiah) [C5XL] > Feature flags: > fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse > Extended feature flags: Sorry. I'm asking You now. Can You send entire output? -- NIE KUPUJ!!! ...zanim nie porownasz cen >> http://link.interia.pl/f1a5e - 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: cpufreq longhaul locks up
> Switching from acpi_pm+performance to acpi_pm+ondemand also > locks up after a few minutes. Yep. Sounds like an ondemand issue. Thanks for verifying this for me. >>> Nah, it also happens with cpufreq_powersave. I just need to check >>> through some archives and try booting with governor=powersave so that it >>> always stays low. >> You have a lockup when switching from other governor to powersave? Or if >> You are using it for some time? > > After some time. Don't understand me wrong, but this is very weird. I think that powersave is changing frequency only one time, when it is loaded. I will look into its code to be sure. Probably Longhaul is making something what isn't allowed or there is hardware bug somewhere. > Jan Rafał -- Po meczu.kurde...:) >>> http://link.interia.pl/f1a72 - 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: cpufreq longhaul locks up
Can You send output of x86info program and output of lspci command? Longhaul wasn't working for You since 2.6.18 right? Output from x86info (I know you didn't ask me, but hey, information wants to be free) x86info v1.20. Dave Jones 2001-2006 Feedback to [EMAIL PROTECTED]. Found 1 CPU -- Family: 6 Model: 9 Stepping: 8 CPU Model : VIA C3 (Nehemiah) [C5XL] Feature flags: fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse Extended feature flags: Sorry. I'm asking You now. Can You send entire output? -- NIE KUPUJ!!! ...zanim nie porownasz cen http://link.interia.pl/f1a5e - 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: cpufreq longhaul locks up
Switching from acpi_pm+performance to acpi_pm+ondemand also locks up after a few minutes. Yep. Sounds like an ondemand issue. Thanks for verifying this for me. Nah, it also happens with cpufreq_powersave. I just need to check through some archives and try booting with governor=powersave so that it always stays low. You have a lockup when switching from other governor to powersave? Or if You are using it for some time? After some time. Don't understand me wrong, but this is very weird. I think that powersave is changing frequency only one time, when it is loaded. I will look into its code to be sure. Probably Longhaul is making something what isn't allowed or there is hardware bug somewhere. Jan Rafał -- Po meczu.kurde...:) http://link.interia.pl/f1a72 - 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: cpufreq longhaul locks up
Can You send output of x86info program and output of Where do I find this? http://www.codemonkey.org.uk/projects/x86info/ It needs msr device support in kernel. -- NIE KUPUJ!!! ...zanim nie porownasz cen http://link.interia.pl/f1a5e - 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: cpufreq longhaul locks up
I found one line which wasn't were it should be. Probably this will not
fix Your problem with powersave governor, but it is a bit related.
Looks like Longhaul isn't skipping frequency transtition when it is asked
to set f which is already set. Now after first transition it will not
try to set same frequency again. Second part contains some magic
because I don't have CN400 datasheet. It is NDA protected :-( Should
print You one byte in hex and will try to set one register. I don't
know if anything will change but it is worth testing.
Fingers crossed
Rafał
---
arch/i386/kernel/cpu/cpufreq/longhaul.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c
b/arch/i386/kernel/cpu/cpufreq/longhaul.c
index 2b030d6..5548e5b 100644
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
@@ -88,6 +88,7 @@ static int clock_ratio[32];
static int eblcr_table[32];
static int longhaul_version;
static struct cpufreq_frequency_table *longhaul_table;
+static unsigned int old_ratio = -1;
#ifdef CONFIG_CPU_FREQ_DEBUG
static char speedbuffer[8];
@@ -252,7 +253,6 @@ static void longhaul_setstate(unsigned int
clock_ratio_index)
{
int speed, mult;
struct cpufreq_freqs freqs;
- static unsigned int old_ratio=-1;
unsigned long flags;
unsigned int pic1_mask, pic2_mask;
@@ -603,7 +603,12 @@ static int enable_arbiter_disable(void)
/* Find CN400 V-Link host bridge */
if (dev == NULL)
dev = pci_find_device(PCI_VENDOR_ID_VIA, 0x7259, NULL);
-
+ if (dev != NULL) {
+ pci_read_config_byte(dev, 0x47, pci_cmd);
+ printk(KERN_INFO PFX %#02x\n, pci_cmd);
+ pci_cmd |= 0xf;
+ pci_write_config_byte(dev, 0x47, pci_cmd);
+ }
}
if (dev != NULL) {
/* Enable access to port 0x22 */
--
--
Po meczu.kurde...:)
http://link.interia.pl/f1a72
-
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: cpufreq longhaul locks up
I just wonder why x86info says I have a C5XL while `modprobe longhaul`
says it is a C5P.
I have changed names to names which VIA is using.
cn:/dev/shm # ./x86info -v -v
You need to be root and use -a option. I'm interested in:
FCR: MSR: 0x1107=0x9e3f1ad6 : 1000 0011 00011010 11010110
Power management: Powersaver
MSR: 0x110a=0x07ff000d000280f0 : 0111 1101
0010 1000
RevisionID: 0 : Initial revision (Software clock multiplier only, no SoftVID)
Software clock multiplier is disabled
Please send me below part of Your dmesg too:
CPU: After generic identify, caps: 0381b83f
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 64K (32 bytes/line)
CPU: After all inits, caps: 0381b93f
00dd
And the BIOS announces it as a Via Eden ESP 6000 (as does the manufacturer).
Great. I think that I saw datasheet somewhere.
Jan
Rafał
--
Wicie, rozumicie
Zobacz http://link.interia.pl/f1a74
-
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: cpufreq longhaul locks up
I found one line which wasn't were it should be. Probably this will not fix Your problem with powersave governor, but it is a bit related. Looks like Longhaul isn't skipping frequency transtition when it is asked to set f which is already set. Now after first transition it will not try to set same frequency again. Second part contains some magic because I don't have CN400 datasheet. It is NDA protected :-( Should print You one byte in hex and will try to set one register. I don't know if anything will change but it is worth testing. Did not help unfortunately. The output the printk line generated was longhaul: 0x0 (Strangely enough, %#02x with glibc outputs 00, not 0x0. And I would have expected 0x00. Subtleties of the kernel printk/glibc?) :-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. Would be good to check if PLL really can go downto x4,0. Can You limit minimal CPU multiplier to 5,0 and check if is stable? If it is check 4,5. Please send me below part of Your dmesg too: CPU: After generic identify, caps: 0381b83f CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) CPU: L2 Cache: 64K (32 bytes/line) CPU: After all inits, caps: 0381b93f 00dd dd is very important here. Jan Rafał -- Kasia Cichopek eksponuje biust http://link.interia.pl/f1a6f - 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: cpufreq longhaul locks up
Is patch attached below making things better?
You should see in log that You are using VT8235 support now.
---
arch/i386/kernel/cpu/cpufreq/longhaul.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c
b/arch/i386/kernel/cpu/cpufreq/longhaul.c
index 5548e5b..c3c9096 100644
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
@@ -635,6 +635,8 @@ static int longhaul_setup_vt8235(void)
/* Find VT8235 southbridge */
dev = pci_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8235, NULL);
+ if (dev == NULL)
+ dev = pci_find_device(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_8237, NULL);
if (dev != NULL) {
/* Set transition time to max */
pci_read_config_byte(dev, 0xec, pci_cmd);
@@ -771,11 +773,11 @@ static int __init longhaul_cpu_init(struct cpufreq_policy
*policy)
}
}
/* Check if northbridge is friendly */
- if (enable_arbiter_disable()) {
+/* if (enable_arbiter_disable()) {
longhaul_flags |= USE_NORTHBRIDGE;
goto print_support_type;
}
- /* Use VT8235 southbridge if present */
+*/ /* Use VT8235 southbridge if present */
if (longhaul_version == TYPE_POWERSAVER vt8235_present) {
longhaul_flags |= USE_VT8235;
goto print_support_type;
--
--
Wicie, rozumicie
Zobacz http://link.interia.pl/f1a74
-
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: cpufreq longhaul locks up
:-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. Would be good to check if PLL really can go downto x4,0. Can You limit minimal CPU multiplier to 5,0 and check if is stable? If it is check 4,5. I directly wrote to /sys/devices/system/cpu/cpu0/cpufreq, which worked better than `cpufreq -u xxx -d xxx`. Lockup after 9 minutes. (Perhaps the longest time so far.) Can You send me Your entire boot log with performance governor set? Jan Rafał -- Po meczu.kurde...:) http://link.interia.pl/f1a72 - 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: cpufreq longhaul locks up
Jan, Can You send output of x86info program and output of lspci command? Longhaul wasn't working for You since 2.6.18 right? I'm going to work now, but I will be available after 14:00 UTC. If You have problem with longhaul+powersave there may be one thing related. When I started to change Longhaul it was causing lockups on Epia 800. I added transition protection. Helped, but not for long. After one or two hours machine locked up anyway. I found datasheet in Google and changed "disable BMDMA bit on PCI device" to northbridge support. Problem fixed. Somehow CLE133 chipset didn't like touching "BMDMA master" bits. Second: I didn't get answer from VIA why they are blocking ACPI C3 on CPU's faster then 1GHz. I don't know if it is standard practice and if Intel and AMD are doing it too. Things worth checking: disable PREEMPT, change it to "Voluntary preemption". Check if using conservative governor makes any difference. I know that this may sound strange, but transition latency is directly proportional to difference between current and destination frequency. Maybe for faster processors it isn't allowed to change frequency directly from min to max? Rafał -- NIE KUPUJ!!! ...zanim nie porownasz cen >> http://link.interia.pl/f1a5e - 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: cpufreq longhaul locks up
>>> Switching from acpi_pm+performance to acpi_pm+ondemand also >>> locks up after a few minutes. >> Yep. Sounds like an ondemand issue. Thanks for verifying this for me. > > Nah, it also happens with cpufreq_powersave. I just need to check > through some archives and try booting with governor=powersave so that it > always stays low. You have a lockup when switching from other governor to powersave? Or if You are using it for some time? -- Wicie, rozumicie Zobacz >>> http://link.interia.pl/f1a74 - 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: cpufreq longhaul locks up
>> Btw. I've been writting many times: if You want to use ondemand with >> Longhaul You don't need cpufreq at all. > > Does VIA Nehemiah do hardware-driven autoregulation like Transmeta > Crusoe too? (I suspect no, have not seen that happen.) No. >> It is just one another cool gadget for You. >> Longhaul wasn't designed to change frequency often. > > Is there a way I can start with a specific governor (powersave) right > from the start so that all devices that Linux will initialize assume > the CPU runs at MHz? You have to search cpufreq mail list archives. I think that I saw patch recently. >> It has big latency and requires so much preparation that it isn't worth >> if You don't need to save power or cool down CPU. > > I found frequency switching on my VIA to be fast enough. Timer frequency equal to 1000Hz? > Jan Rafał -- Wicie, rozumicie Zobacz >>> http://link.interia.pl/f1a74 - 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: cpufreq longhaul locks up
> Hi Rafał, Hi >> > >> > I found that setting the cpufreq governor to ondemand making the box >> > lock up solid in 2.6.20.2 and 2.6.21 after a few seconds. >> > [...] >> >> I can't explain this. Some motherboards are running fine, some don't. >> I'm running longhaul too. It is working fine. No lockups at all. >> So far I heard only about one Epia which had problems with longhaul. >> It was almost like my Epia but older. >> What is possible: >> - some chipsets revisions are broken and aren't blocking DMA, >> - special setup is required, some versions of BIOS are doing >> necessary things, some don't, > > Which BIOS are you using? Latest beta BIOS which was supposed to fix Linux "DMA timeout" bug. I don't remember exact version, It wasn't fixing this bug. > [...] >> Btw. I've been writting many times: if You want to use ondemand with >> Longhaul You don't need cpufreq at all. It is just one another cool >> gadget for You. Longhaul wasn't designed to change frequency often. >> It has big latency and requires so much preparation that it isn't worth >> if You don't need to save power or cool down CPU. > > What should I use instead of ondemand? I do want to save power and > have my machine run cooler (I have a htpc that is on 24/7, it's > running kind of hot and allready has blown a PSU) I'm using conservative. It is allowing me to turn off fan with bigger cooler borowed from AMD CPU. > Does the userspace governor have the same problems? (I'd guess so) For testing I was using userspace governor. 1s interval, Min to max. 1s interval. Max to min. I don't like userspace programs. Most of them is doing exactly the same thing which ondemand does. > I'd like to take this opportunity to thank you for the work you have > already done on cpufreq! > So: thanks Rafał! I appreciate it! Thanks, but it isn't working. It isn't good job. It isn't nothing more then luck. > [...] > I am using the onboard mpeg2 hardware decoder with the Openchrome drivers Me too. Works great. As usual not thanks to VIA, but good developers diging in binary drivers. > I hope this helps someone > Wander. Regards Rafał --- Linda jako gospodyni domowa - zobacz!!! >>> http://link.interia.pl/f1a79 - 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: cpufreq longhaul locks up
> [...] > > The below is in the cpufreq git tree. > > (Maybe also ondemand needs to be disabled for Longhaul?) Would be great. Is this possible? Just kidding. I don't like ondemand. It isn't doing anything good for C3. There is no significant difference between halt/ACPI C2/ACPI C3 on 533Mhz and 999MHz. Difference is when processor is *running*. With ondemand it is running very short on 533MHz. When I was testing ondemand my CPU was running max f most the time. With conservative it is running min f most the time. CPU is much cooler and it is running fanless for most the time. Best part is that conservative is doing more transitions when system is busy because it needs to do all the steps (66MHz step for me) from min (533) to max (999). Ondemand is doing only one transition - from min to max. > From: Rafal Bilski <[EMAIL PROTECTED]> > Date: Sun, 22 Apr 2007 10:26:04 + (+0200) > Subject: [CPUFREQ] Longhaul - Revert Longhaul ver. 2 > X-Git-Url: > http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fdavej%2Fcpufreq.git;a=commitdiff_plain;h=07844252ffd81ec192a62014bada1016c9703765 > > [CPUFREQ] Longhaul - Revert Longhaul ver. 2 > No. It is new thing in 2.6.21 which will stop Longhaul from changing frequencies. As usual tested by email. Works for one, not works for others. Without this patch older C3 will not change frequency. Longhaul will be disabled for good. But both processors which we are talking about are "Powersaver". New. -- Wicie, rozumicie Zobacz >>> http://link.interia.pl/f1a74 - 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: cpufreq longhaul locks up
> Hi, Hello all > > I found that setting the cpufreq governor to ondemand making the box > lock up solid in 2.6.20.2 and 2.6.21 after a few seconds. > [...] I can't explain this. Some motherboards are running fine, some don't. I'm running longhaul too. It is working fine. No lockups at all. So far I heard only about one Epia which had problems with longhaul. It was almost like my Epia but older. What is possible: - some chipsets revisions are broken and aren't blocking DMA, - special setup is required, some versions of BIOS are doing necessary things, some don't, - some chipsets revisions are broken and drivers are not aware. At the beginning Unichrome driver was causing lockups on my machine, but Openchrome was fine. Longhaul may trigger, somehow, other hardware bug. Anyway I don't belive in Longhaul anymore. It is working for me. It is working for others. And it isn't working for others. VIA isn't supporting this driver. Support came only from Centaur and Dave Jones. If special setup is required for north/southbridge then it is necessary to have documentation. I will not receive it from VIA. I'm asking about advice. Make it BROKEN again? Add "big fat warning" and "enable" option? I know that this is Dave Jones decision, but I would like to heard what people are thinking, becuse I've been messing a lot with this driver. Btw. I've been writting many times: if You want to use ondemand with Longhaul You don't need cpufreq at all. It is just one another cool gadget for You. Longhaul wasn't designed to change frequency often. It has big latency and requires so much preparation that it isn't worth if You don't need to save power or cool down CPU. Sorry for bad English Rafał -- NIE KUPUJ!!! ...zanim nie porownasz cen >> http://link.interia.pl/f1a5e - 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: cpufreq longhaul locks up
Hi, Hello all I found that setting the cpufreq governor to ondemand making the box lock up solid in 2.6.20.2 and 2.6.21 after a few seconds. [...] I can't explain this. Some motherboards are running fine, some don't. I'm running longhaul too. It is working fine. No lockups at all. So far I heard only about one Epia which had problems with longhaul. It was almost like my Epia but older. What is possible: - some chipsets revisions are broken and aren't blocking DMA, - special setup is required, some versions of BIOS are doing necessary things, some don't, - some chipsets revisions are broken and drivers are not aware. At the beginning Unichrome driver was causing lockups on my machine, but Openchrome was fine. Longhaul may trigger, somehow, other hardware bug. Anyway I don't belive in Longhaul anymore. It is working for me. It is working for others. And it isn't working for others. VIA isn't supporting this driver. Support came only from Centaur and Dave Jones. If special setup is required for north/southbridge then it is necessary to have documentation. I will not receive it from VIA. I'm asking about advice. Make it BROKEN again? Add big fat warning and enable option? I know that this is Dave Jones decision, but I would like to heard what people are thinking, becuse I've been messing a lot with this driver. Btw. I've been writting many times: if You want to use ondemand with Longhaul You don't need cpufreq at all. It is just one another cool gadget for You. Longhaul wasn't designed to change frequency often. It has big latency and requires so much preparation that it isn't worth if You don't need to save power or cool down CPU. Sorry for bad English Rafał -- NIE KUPUJ!!! ...zanim nie porownasz cen http://link.interia.pl/f1a5e - 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: cpufreq longhaul locks up
[...] The below is in the cpufreq git tree. (Maybe also ondemand needs to be disabled for Longhaul?) Would be great. Is this possible? Just kidding. I don't like ondemand. It isn't doing anything good for C3. There is no significant difference between halt/ACPI C2/ACPI C3 on 533Mhz and 999MHz. Difference is when processor is *running*. With ondemand it is running very short on 533MHz. When I was testing ondemand my CPU was running max f most the time. With conservative it is running min f most the time. CPU is much cooler and it is running fanless for most the time. Best part is that conservative is doing more transitions when system is busy because it needs to do all the steps (66MHz step for me) from min (533) to max (999). Ondemand is doing only one transition - from min to max. From: Rafal Bilski [EMAIL PROTECTED] Date: Sun, 22 Apr 2007 10:26:04 + (+0200) Subject: [CPUFREQ] Longhaul - Revert Longhaul ver. 2 X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fdavej%2Fcpufreq.git;a=commitdiff_plain;h=07844252ffd81ec192a62014bada1016c9703765 [CPUFREQ] Longhaul - Revert Longhaul ver. 2 No. It is new thing in 2.6.21 which will stop Longhaul from changing frequencies. As usual tested by email. Works for one, not works for others. Without this patch older C3 will not change frequency. Longhaul will be disabled for good. But both processors which we are talking about are Powersaver. New. -- Wicie, rozumicie Zobacz http://link.interia.pl/f1a74 - 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: cpufreq longhaul locks up
Hi Rafał, Hi I found that setting the cpufreq governor to ondemand making the box lock up solid in 2.6.20.2 and 2.6.21 after a few seconds. [...] I can't explain this. Some motherboards are running fine, some don't. I'm running longhaul too. It is working fine. No lockups at all. So far I heard only about one Epia which had problems with longhaul. It was almost like my Epia but older. What is possible: - some chipsets revisions are broken and aren't blocking DMA, - special setup is required, some versions of BIOS are doing necessary things, some don't, Which BIOS are you using? Latest beta BIOS which was supposed to fix Linux DMA timeout bug. I don't remember exact version, It wasn't fixing this bug. [...] Btw. I've been writting many times: if You want to use ondemand with Longhaul You don't need cpufreq at all. It is just one another cool gadget for You. Longhaul wasn't designed to change frequency often. It has big latency and requires so much preparation that it isn't worth if You don't need to save power or cool down CPU. What should I use instead of ondemand? I do want to save power and have my machine run cooler (I have a htpc that is on 24/7, it's running kind of hot and allready has blown a PSU) I'm using conservative. It is allowing me to turn off fan with bigger cooler borowed from AMD CPU. Does the userspace governor have the same problems? (I'd guess so) For testing I was using userspace governor. 1s interval, Min to max. 1s interval. Max to min. I don't like userspace programs. Most of them is doing exactly the same thing which ondemand does. I'd like to take this opportunity to thank you for the work you have already done on cpufreq! So: thanks Rafał! I appreciate it! Thanks, but it isn't working. It isn't good job. It isn't nothing more then luck. [...] I am using the onboard mpeg2 hardware decoder with the Openchrome drivers Me too. Works great. As usual not thanks to VIA, but good developers diging in binary drivers. I hope this helps someone Wander. Regards Rafał --- Linda jako gospodyni domowa - zobacz!!! http://link.interia.pl/f1a79 - 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: cpufreq longhaul locks up
Btw. I've been writting many times: if You want to use ondemand with Longhaul You don't need cpufreq at all. Does VIA Nehemiah do hardware-driven autoregulation like Transmeta Crusoe too? (I suspect no, have not seen that happen.) No. It is just one another cool gadget for You. Longhaul wasn't designed to change frequency often. Is there a way I can start with a specific governor (powersave) right from the start so that all devices that Linux will initialize assume the CPU runs at choose something MHz? You have to search cpufreq mail list archives. I think that I saw patch recently. It has big latency and requires so much preparation that it isn't worth if You don't need to save power or cool down CPU. I found frequency switching on my VIA to be fast enough. Timer frequency equal to 1000Hz? Jan Rafał -- Wicie, rozumicie Zobacz http://link.interia.pl/f1a74 - 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: cpufreq longhaul locks up
Switching from acpi_pm+performance to acpi_pm+ondemand also locks up after a few minutes. Yep. Sounds like an ondemand issue. Thanks for verifying this for me. Nah, it also happens with cpufreq_powersave. I just need to check through some archives and try booting with governor=powersave so that it always stays low. You have a lockup when switching from other governor to powersave? Or if You are using it for some time? -- Wicie, rozumicie Zobacz http://link.interia.pl/f1a74 - 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: cpufreq longhaul locks up
Jan, Can You send output of x86info program and output of lspci command? Longhaul wasn't working for You since 2.6.18 right? I'm going to work now, but I will be available after 14:00 UTC. If You have problem with longhaul+powersave there may be one thing related. When I started to change Longhaul it was causing lockups on Epia 800. I added transition protection. Helped, but not for long. After one or two hours machine locked up anyway. I found datasheet in Google and changed disable BMDMA bit on PCI device to northbridge support. Problem fixed. Somehow CLE133 chipset didn't like touching BMDMA master bits. Second: I didn't get answer from VIA why they are blocking ACPI C3 on CPU's faster then 1GHz. I don't know if it is standard practice and if Intel and AMD are doing it too. Things worth checking: disable PREEMPT, change it to Voluntary preemption. Check if using conservative governor makes any difference. I know that this may sound strange, but transition latency is directly proportional to difference between current and destination frequency. Maybe for faster processors it isn't allowed to change frequency directly from min to max? Rafał -- NIE KUPUJ!!! ...zanim nie porownasz cen http://link.interia.pl/f1a5e - 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 0/2] natsemi: Improve DspCfg workaround
> The natsemi driver contains a workaround for broken hardware which can > on some boards cause more problems than it solves. The following patch > series improves this by making the diagnostic more obvious and allowing > users to disable the workaround if it causes them problems. Works great. Thank You all for help. Thanks Rafał -- NIE KUPUJ!!! ...zanim nie porownasz cen >> http://link.interia.pl/f1a5e - 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: Natsemi DP83815 driver spaming
>> What about module option? > > That would work, though you crossed in the post with me writing a patch > adding a sysfs file; I merged the two for overkill (below). I also have > a patch which changes the log message for the workaround so that it is > displayed by default in order to make this easier to diagnose. Applied. I set default value to 0. Flashed. However > + if (!NATSEMI_CREATE_FILE(pdev, dspcfg_workaround)) > + goto err_create_file; is going to err_create_file. Without these lines drivers works fine. Rafał -- NIE KUPUJ!!! ...zanim nie porownasz cen >> http://link.interia.pl/f1a5e - 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: Natsemi DP83815 driver spaming
What about module option? That would work, though you crossed in the post with me writing a patch adding a sysfs file; I merged the two for overkill (below). I also have a patch which changes the log message for the workaround so that it is displayed by default in order to make this easier to diagnose. Applied. I set default value to 0. Flashed. However + if (!NATSEMI_CREATE_FILE(pdev, dspcfg_workaround)) + goto err_create_file; is going to err_create_file. Without these lines drivers works fine. Rafał -- NIE KUPUJ!!! ...zanim nie porownasz cen http://link.interia.pl/f1a5e - 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 0/2] natsemi: Improve DspCfg workaround
The natsemi driver contains a workaround for broken hardware which can on some boards cause more problems than it solves. The following patch series improves this by making the diagnostic more obvious and allowing users to disable the workaround if it causes them problems. Works great. Thank You all for help. Thanks Rafał -- NIE KUPUJ!!! ...zanim nie porownasz cen http://link.interia.pl/f1a5e - 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: Natsemi DP83815 driver spaming
>> > I'm not sure what the right answer is. The code was designed to do
>> > the right thing, and yet in your case it's broken. Does it need to be
>> > a build option to work around broken hardware? Yuck.
>>
>> Without a system that really needs the original problem that was being
>> worked around it's going to be hard to see if the workaround still does
>> the job. Given the nature of the failure I wouldn't be surprised if it
>> broke different things on every board that has problems.
>
> I'm sure if you were to revert that code today, you'd find people who
> had problems :)
>
>> How about a sysfs tuneable? It's not nice but at least it's runtime.
>
> Fine by me - but I have very little time to do the work.
What about module option?
---
drivers/net/natsemi.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index 349b96a..933e106 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -90,6 +90,10 @@ static int rx_copybreak;
static int options[MAX_UNITS];
static int full_duplex[MAX_UNITS];
+/* Used to disable "is PHY alive" check for compatibility with broken
+ * designs using rev. C chips. */
+static int disable_phy_check;
+
/* Operational parameters that are set at compile time. */
/* Keep the ring sizes a power of two for compile efficiency.
@@ -141,6 +145,7 @@ module_param(debug, int, 0);
module_param(rx_copybreak, int, 0);
module_param_array(options, int, NULL, 0);
module_param_array(full_duplex, int, NULL, 0);
+module_param(disable_phy_check, int, 0);
MODULE_PARM_DESC(mtu, "DP8381x MTU (all boards)");
MODULE_PARM_DESC(debug, "DP8381x default debug level");
MODULE_PARM_DESC(rx_copybreak,
@@ -148,6 +153,8 @@ MODULE_PARM_DESC(rx_copybreak,
MODULE_PARM_DESC(options,
"DP8381x: Bits 0-3: media type, bit 17: full duplex");
MODULE_PARM_DESC(full_duplex, "DP8381x full duplex setting(s) (1)");
+MODULE_PARM_DESC(disable_phy_check, "DP8381[56]: PHY lockup check disable"
+ " (all boards)");
/*
Theory of Operation
@@ -1753,7 +1760,7 @@ static void netdev_timer(unsigned long data)
writew(1, ioaddr+PGSEL);
dspcfg = readw(ioaddr+DSPCFG);
writew(0, ioaddr+PGSEL);
- if (dspcfg != np->dspcfg) {
+ if (!disable_phy_check && dspcfg != np->dspcfg) {
if (!netif_queue_stopped(dev)) {
spin_unlock_irq(>lock);
if (netif_msg_hw(np))
--
1.5.0.6
--
Zrob numer kumplom >> http://link.interia.pl/f1a5d
-
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: Natsemi DP83815 driver spaming
[...] > >> With code commented out I have 1 error / 3 transmitted packets from >> DP83815C. I have 1 error / 10 transmitted packets to DP83815C. Maybe >> it works at all because I have short cable, only 10m long. >> I don't remember any errors with plain 2.6.21.1. Sorry. I mean transmition errors, but of course log was full of "wakeup" messages. > Well, I certainly haven't changed anything in there. If the behavior > has changed in recent kernels, check the rest of the diffs. > > Tim 2.6.21.1 is first kernel which I'm using at this device. Earlier it was WindowsCE terminal. It is hardware fault. Commenting out the code is my way to avoid "wakeup" messages in log, but I don't want to change anything in vanilla kernel. I'm lucky that NIC is working at all. Thank You Rafał -- NIE KUPUJ!!! ...zanim nie porownasz cen >> http://link.interia.pl/f1a5e - 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: Natsemi DP83815 driver spaming
[...] With code commented out I have 1 error / 3 transmitted packets from DP83815C. I have 1 error / 10 transmitted packets to DP83815C. Maybe it works at all because I have short cable, only 10m long. I don't remember any errors with plain 2.6.21.1. Sorry. I mean transmition errors, but of course log was full of wakeup messages. Well, I certainly haven't changed anything in there. If the behavior has changed in recent kernels, check the rest of the diffs. Tim 2.6.21.1 is first kernel which I'm using at this device. Earlier it was WindowsCE terminal. It is hardware fault. Commenting out the code is my way to avoid wakeup messages in log, but I don't want to change anything in vanilla kernel. I'm lucky that NIC is working at all. Thank You Rafał -- NIE KUPUJ!!! ...zanim nie porownasz cen http://link.interia.pl/f1a5e - 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: Natsemi DP83815 driver spaming
I'm not sure what the right answer is. The code was designed to do
the right thing, and yet in your case it's broken. Does it need to be
a build option to work around broken hardware? Yuck.
Without a system that really needs the original problem that was being
worked around it's going to be hard to see if the workaround still does
the job. Given the nature of the failure I wouldn't be surprised if it
broke different things on every board that has problems.
I'm sure if you were to revert that code today, you'd find people who
had problems :)
How about a sysfs tuneable? It's not nice but at least it's runtime.
Fine by me - but I have very little time to do the work.
What about module option?
---
drivers/net/natsemi.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/natsemi.c b/drivers/net/natsemi.c
index 349b96a..933e106 100644
--- a/drivers/net/natsemi.c
+++ b/drivers/net/natsemi.c
@@ -90,6 +90,10 @@ static int rx_copybreak;
static int options[MAX_UNITS];
static int full_duplex[MAX_UNITS];
+/* Used to disable is PHY alive check for compatibility with broken
+ * designs using rev. C chips. */
+static int disable_phy_check;
+
/* Operational parameters that are set at compile time. */
/* Keep the ring sizes a power of two for compile efficiency.
@@ -141,6 +145,7 @@ module_param(debug, int, 0);
module_param(rx_copybreak, int, 0);
module_param_array(options, int, NULL, 0);
module_param_array(full_duplex, int, NULL, 0);
+module_param(disable_phy_check, int, 0);
MODULE_PARM_DESC(mtu, DP8381x MTU (all boards));
MODULE_PARM_DESC(debug, DP8381x default debug level);
MODULE_PARM_DESC(rx_copybreak,
@@ -148,6 +153,8 @@ MODULE_PARM_DESC(rx_copybreak,
MODULE_PARM_DESC(options,
DP8381x: Bits 0-3: media type, bit 17: full duplex);
MODULE_PARM_DESC(full_duplex, DP8381x full duplex setting(s) (1));
+MODULE_PARM_DESC(disable_phy_check, DP8381[56]: PHY lockup check disable
+(all boards));
/*
Theory of Operation
@@ -1753,7 +1760,7 @@ static void netdev_timer(unsigned long data)
writew(1, ioaddr+PGSEL);
dspcfg = readw(ioaddr+DSPCFG);
writew(0, ioaddr+PGSEL);
- if (dspcfg != np-dspcfg) {
+ if (!disable_phy_check dspcfg != np-dspcfg) {
if (!netif_queue_stopped(dev)) {
spin_unlock_irq(np-lock);
if (netif_msg_hw(np))
--
1.5.0.6
--
Zrob numer kumplom http://link.interia.pl/f1a5d
-
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: Natsemi DP83815 driver spaming
>> > > * 2) check for sudden death of the NIC: >> > > *It seems that a reference set for this chip went out with >> incorrect info, >> > > *and there exist boards that aren't quite right. An >> unexpected voltage >> > > *drop can cause the PHY to get itself in a weird state >> (basically reset). >> > > *NOTE: this only seems to affect revC chips. >> >> > Code commented out and NIC is working OK. Strange. >> > eth0: DSPCFG accepted after 0 usec. >> > eth0: link up. >> > eth0: Setting full-duplex based on negotiated link capability. >> > dspcfg = 0x np->dspcfg = 0x5060 >> >> Oh, that's entertaining. I have to confess that I've never seen an that >> triggered the workaround before - adding the maintainer, Tim Hockin, who >> may be able to shed some light on the expected behaviour here? > > It's been quite a while since I dealt with this issue, so I am going > on faulty memory. A particular reference design for this chip had bad > resistor values, or something similar. That caused the chip to get > very very confused and need a reset. Can You send me documentation? I can't find anything in datasheet. I will replace bad resitors with correct ones. > So the driver is finding your chip to be hosed over and over again. > dspcfg = 0x00 is bad. I'd be very surprised if you don't get > other wierdness - bad performance or noise or who knows what. No. It is much better. Much less packets need to be retransmitted. I was blaming w3cache.tkdami.net earlier. > You could take out the error message and just let the driver do it's > thing, or you can try to run with that logic removed. But I'd measure > both and see what they do. Specifically - look for packet errors. With code commented out I have 1 error / 3 transmitted packets from DP83815C. I have 1 error / 10 transmitted packets to DP83815C. Maybe it works at all because I have short cable, only 10m long. I don't remember any errors with plain 2.6.21.1. > Tim Rafał -- NIE KUPUJ!!! ...zanim nie porownasz cen >> http://link.interia.pl/f1a5e - 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: Natsemi DP83815 driver spaming
>> eth0: Media selection timer tick. >> eth0: possible phy reset: re-initializing > > This is why the reset is being triggered - it's a workaround for a hardware > bug which checks to make sure the hardware is in the state that the > kernel thinks it is is going off. The code has this explanatory comment: > > * 2) check for sudden death of the NIC: > *It seems that a reference set for this chip went out with incorrect > info, > *and there exist boards that aren't quite right. An unexpected voltage > *drop can cause the PHY to get itself in a weird state (basically reset). > *NOTE: this only seems to affect revC chips. > Code commented out and NIC is working OK. Strange. eth0: DSPCFG accepted after 0 usec. eth0: link up. eth0: Setting full-duplex based on negotiated link capability. dspcfg = 0x np->dspcfg = 0x5060 dspcfg = 0x np->dspcfg = 0x5060 dspcfg = 0x np->dspcfg = 0x5060 dspcfg = 0x np->dspcfg = 0x5060 dspcfg = 0x np->dspcfg = 0x5060 dspcfg = 0x np->dspcfg = 0x5060 dspcfg = 0x np->dspcfg = 0x5060 One problem solved in mean time :-) > PCI: CS5530 video turned off. [BTW, as Andrew said please don't drop people from the CC.] I didn't. It is Thunderbird. I'm included instead of You. Fixed manually this time. Regards Rafał --- Linda jako gospodyni domowa - zobacz!!! >>> http://link.interia.pl/f1a79 - 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/
