Re: MCE Erros
On Thursday 22 March 2007, Thomas Glanzmann wrote: > Hello, > I have two Dual Opteron Machines where I get two MCE errors on. The > first one is: > > MCE 0 > HARDWARE ERROR. This is *NOT* a software problem! > Please contact your hardware vendor > CPU 0 4 northbridge TSC edc587de6e99 > ADDR 1001a > Northbridge GART error >bit61 = error uncorrected > TLB error 'generic transaction, level generic' > STATUS a405001b MCGSTATUS 0 > > I see this error exactly 8 times. What does 'GART' mean? Graphics Address Remapping Table used with agp regards marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: MCE Erros
On Thursday 22 March 2007, Thomas Glanzmann wrote: Hello, I have two Dual Opteron Machines where I get two MCE errors on. The first one is: MCE 0 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 0 4 northbridge TSC edc587de6e99 ADDR 1001a Northbridge GART error bit61 = error uncorrected TLB error 'generic transaction, level generic' STATUS a405001b MCGSTATUS 0 I see this error exactly 8 times. What does 'GART' mean? Graphics Address Remapping Table used with agp regards marcel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [1/6] 2.6.21-rc3: known regressions
On Tuesday 13 March 2007, Pierre Ossman wrote: > Pavel Machek wrote: > > > > Uhuh. User error, lets close the report. > > > > mmc changed the major to > > > > 236 mmc > > > > ... while it was something else in 2.6.20. Can we get stable device > > allocation for mmc? > > What kind of savages do not use udev these days?! ;) > > I don't have the time and energy to jump through all the hoops required to get > an official number right now. Most users use udev and those that don't can use > the "major" parameter for mmc_block. > > Rgds hi, i don't know if you ever used linux on embedded devices like set-top-boxes. you have a mostly fixed device infrastructure on those devices. even if you call it a "kind of savage", using udev there instead of fixed major device numbers is crap. best regards marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [1/6] 2.6.21-rc3: known regressions
On Tuesday 13 March 2007, Pierre Ossman wrote: Pavel Machek wrote: Uhuh. User error, lets close the report. mmc changed the major to 236 mmc ... while it was something else in 2.6.20. Can we get stable device allocation for mmc? What kind of savages do not use udev these days?! ;) I don't have the time and energy to jump through all the hoops required to get an official number right now. Most users use udev and those that don't can use the major parameter for mmc_block. Rgds hi, i don't know if you ever used linux on embedded devices like set-top-boxes. you have a mostly fixed device infrastructure on those devices. even if you call it a kind of savage, using udev there instead of fixed major device numbers is crap. best regards marcel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: irq nobody cared issue on 2.6.2x
On Wednesday 07 March 2007, Linus Torvalds wrote: > > On Wed, 7 Mar 2007, Mws wrote: > > > > if you would be so kind to provide me some infos, > > > > how i would be able to track the problem down _and_ maybe how to fix it. > > The first step is to figure out as exactly as possible _when_ it started > happening. > > > please find two snippets of dmesg after booting 2.6.21-rc3-git > > (2.6.20-1 has got the same results) > > So is 2.6.19 good? 2.6.20-rc1? -rc2? went down to 2.6.17 - earlier is lacking due to correctly booting my machine. > If you're a git user (or even just marginally interested in learning), the > best thing to do is to find some good kernel (the more recent, the better, > but the keyword is *some* kernel that works well), and a bad kernel (the > older the better, just to avoid unnecessary work, but again, you can just > take the most recent too), and then just use "git bisect". > > If you bisect it down to one particular commit, that will help us a lot, > but even if you only bisect it down by booting a handful of kernels (say, > 5-6), it will already have cut things down a lot, and probably more easily > and efficiently than if you just downloaded daily snapshots and tried to > narrow it down that way. > > Linus i started to bring in a load of printk's into v4l dvb repository to find out what exactly is causing the interrupt to appear and why it is not handled. the bug is reproducible by insmod/rmmod dvb_ttpci over and over. yesterday late night i tried a bit too much and my machine freezed as a whole. even kernel sysrq didn't work anymore. i found some point, that after fireware load the interrupt is fired again. will check if there is a solution to create a workaround and try to fix it afterwards. it does NOT appear on a different computer same card. i think it is a problem in combination chipset - card - bios dunno by now, but will find out. thanks for your information, linus. marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: irq nobody cared issue on 2.6.2x
On Wednesday 07 March 2007, Linus Torvalds wrote: On Wed, 7 Mar 2007, Mws wrote: if you would be so kind to provide me some infos, how i would be able to track the problem down _and_ maybe how to fix it. The first step is to figure out as exactly as possible _when_ it started happening. please find two snippets of dmesg after booting 2.6.21-rc3-git (2.6.20-1 has got the same results) So is 2.6.19 good? 2.6.20-rc1? -rc2? went down to 2.6.17 - earlier is lacking due to correctly booting my machine. If you're a git user (or even just marginally interested in learning), the best thing to do is to find some good kernel (the more recent, the better, but the keyword is *some* kernel that works well), and a bad kernel (the older the better, just to avoid unnecessary work, but again, you can just take the most recent too), and then just use git bisect. If you bisect it down to one particular commit, that will help us a lot, but even if you only bisect it down by booting a handful of kernels (say, 5-6), it will already have cut things down a lot, and probably more easily and efficiently than if you just downloaded daily snapshots and tried to narrow it down that way. Linus i started to bring in a load of printk's into v4l dvb repository to find out what exactly is causing the interrupt to appear and why it is not handled. the bug is reproducible by insmod/rmmod dvb_ttpci over and over. yesterday late night i tried a bit too much and my machine freezed as a whole. even kernel sysrq didn't work anymore. i found some point, that after fireware load the interrupt is fired again. will check if there is a solution to create a workaround and try to fix it afterwards. it does NOT appear on a different computer same card. i think it is a problem in combination chipset - card - bios dunno by now, but will find out. thanks for your information, linus. marcel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
irq nobody cared issue on 2.6.2x
hi all, i just moved my win tv dvb-s card (PCI) from my old to my actual pc. its an ASUS M2N32 WS Professional AMD64 X2 Board equiped with the nvidia nForce 590 SLI MCP chipset. in the past, i had to use the noapic kernel cmdline param to get linux booting and working properly. iirc versions >=2.6.18 of the kernel fixed all of my previous problems, thus i am not using noapic since then. if you would be so kind to provide me some infos, how i would be able to track the problem down _and_ maybe how to fix it. please find two snippets of dmesg after booting 2.6.21-rc3-git (2.6.20-1 has got the same results) best regards marcel snip of logs _normal_ boot on 2.6.21-rc3 git Freeing unused kernel memory: 264k freed saa7146: register extension 'dvb'. ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16 ACPI: PCI Interrupt :02:06.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 16 saa7146: found saa7146 @ mem c207 (revision 1, irq 16) (0x13c2,0x0003). DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.X). adapter has MAC addr = 00:d0:5c:1f:6d:3f irq 16: nobody cared (try booting with the "irqpoll" option) Call Trace: [] [] [] [] [] [] [] [] [] handlers: [] Disabling IRQ #16 dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 80f12623 dvb-ttpci: firmware @ card 0 supports CI link layer interface boot on 2.6.21-rc3 git irqpoll option Freeing unused kernel memory: 260k freed saa7146: register extension 'dvb'. ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16 ACPI: PCI Interrupt :02:06.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 16 saa7146: found saa7146 @ mem c2026000 (revision 1, irq 16) (0x13c2,0x0003). DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.X). adapter has MAC addr = 00:d0:5c:1f:6d:3f dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 80f12623 dvb-ttpci: firmware @ card 0 supports CI link layer interface dvb-ttpci: adac type set to 0 @ card 0 saa7146_vv: saa7146 (0): registered device video0 [v4l2] saa7146_vv: saa7146 (0): registered device vbi0 [v4l2] DVB: registering frontend 0 (ST STV0299 DVB-S)... input: DVB on-card IR receiver as /class/input/input3 dvb-ttpci: found av7110-0. XFS mounting filesystem sda1 later on Adding 1004052k swap on /dev/hda2. Priority:-1 extents:1 across:1004052k irq 16: nobody cared (try booting with the "irqpoll" option) Call Trace: [] [] [] [] [] [] [] handlers: [] Disabling IRQ #16 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
irq nobody cared issue on 2.6.2x
hi all, i just moved my win tv dvb-s card (PCI) from my old to my actual pc. its an ASUS M2N32 WS Professional AMD64 X2 Board equiped with the nvidia nForce 590 SLI MCP chipset. in the past, i had to use the noapic kernel cmdline param to get linux booting and working properly. iirc versions =2.6.18 of the kernel fixed all of my previous problems, thus i am not using noapic since then. if you would be so kind to provide me some infos, how i would be able to track the problem down _and_ maybe how to fix it. please find two snippets of dmesg after booting 2.6.21-rc3-git (2.6.20-1 has got the same results) best regards marcel snip of logs _normal_ boot on 2.6.21-rc3 git Freeing unused kernel memory: 264k freed saa7146: register extension 'dvb'. ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16 ACPI: PCI Interrupt :02:06.0[A] - Link [APC1] - GSI 16 (level, low) - IRQ 16 saa7146: found saa7146 @ mem c207 (revision 1, irq 16) (0x13c2,0x0003). DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.X). adapter has MAC addr = 00:d0:5c:1f:6d:3f irq 16: nobody cared (try booting with the irqpoll option) Call Trace: IRQ [801473d7] [801475e2] [80147e97] [8010a62c] [8010c0e2] [8010882e] [80109a41] EOI [80108857] [801088bc] handlers: [88015619] Disabling IRQ #16 dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 80f12623 dvb-ttpci: firmware @ card 0 supports CI link layer interface boot on 2.6.21-rc3 git irqpoll option Freeing unused kernel memory: 260k freed saa7146: register extension 'dvb'. ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16 ACPI: PCI Interrupt :02:06.0[A] - Link [APC1] - GSI 16 (level, low) - IRQ 16 saa7146: found saa7146 @ mem c2026000 (revision 1, irq 16) (0x13c2,0x0003). DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.X). adapter has MAC addr = 00:d0:5c:1f:6d:3f dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 80f12623 dvb-ttpci: firmware @ card 0 supports CI link layer interface dvb-ttpci: adac type set to 0 @ card 0 saa7146_vv: saa7146 (0): registered device video0 [v4l2] saa7146_vv: saa7146 (0): registered device vbi0 [v4l2] DVB: registering frontend 0 (ST STV0299 DVB-S)... input: DVB on-card IR receiver as /class/input/input3 dvb-ttpci: found av7110-0. XFS mounting filesystem sda1 later on Adding 1004052k swap on /dev/hda2. Priority:-1 extents:1 across:1004052k irq 16: nobody cared (try booting with the irqpoll option) Call Trace: IRQ [80147763] [80147982] [801481a6] [8010a7cc] [8010c291] [80108a3e] [80109c51] EOI handlers: [88015612] Disabling IRQ #16 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [linux-dvb] 2.6.21-rc1-git2 is incompilable
On Thursday 01 March 2007, Uwe Bugla wrote: > Hi folks, > trying to compile kernel 2.6.21-rc1-git2 is impossible. The broken module > where the compiler gives up is /arch/i386/kernel/io_apic.c. > > Regards > > Uwe > > P. S.: Wouldn't it be a good idea to test at least error-free compilation > before stuff like this is being published? > hi uwe, according to kernel.org 2.6.21-rc2-git1 is an actual snapshot but, those are iirc auto generated. thus not being able to compile can happen. it also depends on your special .config best regards marcel p.s. wouldn't it be a good idea to check your mail recipients instead of sending mails to e.g. linux-dvb that do have no use with fixes of floppy drivers and or compile status in io_apic? :) dont take it too hard man... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [linux-dvb] 2.6.21-rc1-git2 is incompilable
On Thursday 01 March 2007, Uwe Bugla wrote: Hi folks, trying to compile kernel 2.6.21-rc1-git2 is impossible. The broken module where the compiler gives up is /arch/i386/kernel/io_apic.c. Regards Uwe P. S.: Wouldn't it be a good idea to test at least error-free compilation before stuff like this is being published? hi uwe, according to kernel.org 2.6.21-rc2-git1 is an actual snapshot but, those are iirc auto generated. thus not being able to compile can happen. it also depends on your special .config best regards marcel p.s. wouldn't it be a good idea to check your mail recipients instead of sending mails to e.g. linux-dvb that do have no use with fixes of floppy drivers and or compile status in io_apic? :) dont take it too hard man... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: GPL vs non-GPL device drivers
hi vj, On Thursday 15 February 2007, v j wrote: > This is in reference to the following thread: > > http://lkml.org/lkml/2006/12/14/63 > > I am not sure if this is ever addressed in LKML, but linux is _very_ > popular in the embedded space. We (an embedded vendor) chose Linux 3 > years back because of its lack of royalty model, robustness and > availability of infinite number of open-source tools. > > We recently decided to move to Linux 2.6 for our next product, mainly > because Linux has worked so well for us in the past, and we would like > to move up to keep up with the latest and greatest. you choose to move to linux 2.6 for your next product - fine. it has worked for you well in the past - fine. you would like to keep along with the latest and greatest - fine. _but_ for all those reasons you have to get along with all rules, licenses and at least all changes that the kernel community decided to perform. > However in moving to 2.6, we noticed a number of alarming things. > Porting drivers over from devfs to udev, though easy raised a number > of alarming issues. Driver's no longer could dynamically allocate > their MAJOR/MINOR numbers. Doing so would mean they would have to use > sysfs. However it seems that sysfs (and the class_ interface) is only > available to GPL modules. This is very concerning. The drivers which > we have written over the last three years are suddenly under threat. > We don't mind statically assigning MAJOR/MINOR numbers to our drivers. > We can do this and modify our user space applications too. > > However we have a worrying trend here. If at some point it becomes > illegal to load our modules into the linux kernel, then it is > unacceptable to us. We would have been better off choosing VxWorks or > OSE 3 years ago when we made an OS choice. The fact that Linux is > becoming more and more closed is very very alarming. the trend is not worrying. we are not responsible for your decisions you made in the past. the only real FACT is that linux is being stated to BE OPEN and what is much more important to STAY OPEN for everybody. you chose it years ago, because of those facts. of course linux is very popular on embedded systems. i am working within some open source projects that also run on embedded hardware designs. your main mistake in understanding linux and our way to have it also more open in future than by now. what actually costs you more in future? opening your drivers, as much it must be, to have your hardware supported under 2.6 _or_ paying license fees for runtime/development tools for vxworks, ose whatever? and what will do complain at windriver or other companies, if they decide not to support your used cpu architecture anymore? this were my 0.2$ marcel p.s. you said you like linux for its royalty model - that also includes that you accept all the other rules and terms. e.g. gpl license _and_ its fullfillment. > vj. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: GPL vs non-GPL device drivers
hi vj, On Thursday 15 February 2007, v j wrote: This is in reference to the following thread: http://lkml.org/lkml/2006/12/14/63 I am not sure if this is ever addressed in LKML, but linux is _very_ popular in the embedded space. We (an embedded vendor) chose Linux 3 years back because of its lack of royalty model, robustness and availability of infinite number of open-source tools. We recently decided to move to Linux 2.6 for our next product, mainly because Linux has worked so well for us in the past, and we would like to move up to keep up with the latest and greatest. you choose to move to linux 2.6 for your next product - fine. it has worked for you well in the past - fine. you would like to keep along with the latest and greatest - fine. _but_ for all those reasons you have to get along with all rules, licenses and at least all changes that the kernel community decided to perform. However in moving to 2.6, we noticed a number of alarming things. Porting drivers over from devfs to udev, though easy raised a number of alarming issues. Driver's no longer could dynamically allocate their MAJOR/MINOR numbers. Doing so would mean they would have to use sysfs. However it seems that sysfs (and the class_ interface) is only available to GPL modules. This is very concerning. The drivers which we have written over the last three years are suddenly under threat. We don't mind statically assigning MAJOR/MINOR numbers to our drivers. We can do this and modify our user space applications too. However we have a worrying trend here. If at some point it becomes illegal to load our modules into the linux kernel, then it is unacceptable to us. We would have been better off choosing VxWorks or OSE 3 years ago when we made an OS choice. The fact that Linux is becoming more and more closed is very very alarming. the trend is not worrying. we are not responsible for your decisions you made in the past. the only real FACT is that linux is being stated to BE OPEN and what is much more important to STAY OPEN for everybody. you chose it years ago, because of those facts. of course linux is very popular on embedded systems. i am working within some open source projects that also run on embedded hardware designs. your main mistake in understanding linux and our way to have it also more open in future than by now. what actually costs you more in future? opening your drivers, as much it must be, to have your hardware supported under 2.6 _or_ paying license fees for runtime/development tools for vxworks, ose whatever? and what will do complain at windriver or other companies, if they decide not to support your used cpu architecture anymore? this were my 0.2$ marcel p.s. you said you like linux for its royalty model - that also includes that you accept all the other rules and terms. e.g. gpl license _and_ its fullfillment. vj. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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] ALSA: hda-intel - Disable MSI support by default
On Wednesday 15 November 2006 22:10, Mws wrote: > On Wednesday 15 November 2006 21:14, Linus Torvalds wrote: > > > > On Wed, 15 Nov 2006, Mws wrote: > > > > > > after some small discussions on alsa-user ml i recognised this > > > thread today. > > > i thought my problem could also exist on this msi stuff. > > > i disabled msi in kernel config, reboot, and, after starting x & kde > > > i got immediately a freeze. > > > last and maybe important last try has been to > > > enable msi support _but_ boot kernel with cmdline pci=nomsi > > > this finally did work out. i got a working sound environment again. > > > > I expect that you have the exact same issue as Olivier: the "hang" is > > probably because you started using the sound device (beeping on the > > console is handled by the old built-in speaker, but in X a single beep > > tends to be due to sound device drivers), and because of sound irq > > misrouting you had some other device (like your harddisk) that got their > > irq disabled due to the "nobody cared" issue. > > > > > i find it a bit abnormal that the disabling msi in kernel config behaviour > > > is different from kernel cmdline pci=nomsi option. > > > > Now, that does actually worry me. It _should_ have worked with CONFIG_MSI > > disabled. I wonder if some of the MSI workarounds actually broke the HDA > > driver subtly. > > > > Anyway, it would be a good idea to test the current -git tree if you can, > > both with CONFIG_MSI and without (and _without_ any "pci=nomsi" kernel > > command line). It should hopefully work, exactly because the HDA driver > > now shouldn't even try to do any MSI stuff by default. > > > > Knock wood. > > > > Linus > hi, > > linus, just cloned current git, but will test it tomorrow morning. > > will inform you on the results. > > thanks > marcel hi, i just tried the git that i cloned yesterday, when you asked me to, linus. i don't get any freezes and sound is fine. no cmdline option pci=nomsi and msi enabled in .config thanks for your help. best regards marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ALSA: hda-intel - Disable MSI support by default
On Wednesday 15 November 2006 22:10, Mws wrote: On Wednesday 15 November 2006 21:14, Linus Torvalds wrote: On Wed, 15 Nov 2006, Mws wrote: after some small discussions on alsa-user ml i recognised this thread today. i thought my problem could also exist on this msi stuff. i disabled msi in kernel config, reboot, and, after starting x kde i got immediately a freeze. last and maybe important last try has been to enable msi support _but_ boot kernel with cmdline pci=nomsi this finally did work out. i got a working sound environment again. I expect that you have the exact same issue as Olivier: the hang is probably because you started using the sound device (beeping on the console is handled by the old built-in speaker, but in X a single beep tends to be due to sound device drivers), and because of sound irq misrouting you had some other device (like your harddisk) that got their irq disabled due to the nobody cared issue. i find it a bit abnormal that the disabling msi in kernel config behaviour is different from kernel cmdline pci=nomsi option. Now, that does actually worry me. It _should_ have worked with CONFIG_MSI disabled. I wonder if some of the MSI workarounds actually broke the HDA driver subtly. Anyway, it would be a good idea to test the current -git tree if you can, both with CONFIG_MSI and without (and _without_ any pci=nomsi kernel command line). It should hopefully work, exactly because the HDA driver now shouldn't even try to do any MSI stuff by default. Knock wood. Linus hi, linus, just cloned current git, but will test it tomorrow morning. will inform you on the results. thanks marcel hi, i just tried the git that i cloned yesterday, when you asked me to, linus. i don't get any freezes and sound is fine. no cmdline option pci=nomsi and msi enabled in .config thanks for your help. best regards marcel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Second "CPU" of 1-core HyperThreading CPU not found in 2.6.13
Pallipadi, Venkatesh wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chase Venters Sent: Monday, August 29, 2005 9:04 PM To: linux-kernel@vger.kernel.org Subject: Second "CPU" of 1-core HyperThreading CPU not found in 2.6.13 Greetings kind hackers... I recently switched to 2.6.13 on my desktop. I noticed that the second "CPU" (is there a better term to use in this HyperThreading scenario?) that used to be listed in /proc/cpuinfo is no longer present. Complete 'dmesg' please. Thanks, Venki - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ just verified. i have got the same problem here. p4 asus mainboard most recent bios prescott cpu everything is fine for detecting cpu with 2.6.13-rc1 i just tested 2.6.13-rc7 and release today only 1 cpu is shown regards marcel ps. dmesg will follow tomorrow if nothin has reached the ml then. (i need the machine now compiling some stuff) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Second CPU of 1-core HyperThreading CPU not found in 2.6.13
Pallipadi, Venkatesh wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chase Venters Sent: Monday, August 29, 2005 9:04 PM To: linux-kernel@vger.kernel.org Subject: Second CPU of 1-core HyperThreading CPU not found in 2.6.13 Greetings kind hackers... I recently switched to 2.6.13 on my desktop. I noticed that the second CPU (is there a better term to use in this HyperThreading scenario?) that used to be listed in /proc/cpuinfo is no longer present. Complete 'dmesg' please. Thanks, Venki - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ just verified. i have got the same problem here. p4 asus mainboard most recent bios prescott cpu everything is fine for detecting cpu with 2.6.13-rc1 i just tested 2.6.13-rc7 and release today only 1 cpu is shown regards marcel ps. dmesg will follow tomorrow if nothin has reached the ml then. (i need the machine now compiling some stuff) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux 2.6.13-rc6 Marvell/Yukon networking problems
hi there, due to non supporting Marvell Network drivers for the i have to use the syskonnect sk98lin driver from their homepage. even if these drivers are open-source they were rejected by kernel net maintainers until now. there is a skge driver that is integrated into mainline kernel, but that is not able to support this driver. 2.6.13 - rc 1 is fine and working properly. since -rc2 i got problems with having a rejected irq 153. problem still exists with latest rc6 kernel. complete vanilla except for the sysconnect drivers. anyone i can provide with infos of the adapters? even testing shouldn't be a problem at all. regards marcel lspci output :02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 Gigabit Ethernet Controller (rev 15) Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet Controller (Asus) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR+ TAbort- SERR+ APIC IRQ transform: :00:1b.0[A] -> IRQ 137 PCI->APIC IRQ transform: :00:1d.0[A] -> IRQ 193 PCI->APIC IRQ transform: :00:1d.1[B] -> IRQ 161 PCI->APIC IRQ transform: :00:1d.2[C] -> IRQ 153 PCI->APIC IRQ transform: :00:1d.3[D] -> IRQ 137 PCI->APIC IRQ transform: :00:1d.7[A] -> IRQ 193 PCI->APIC IRQ transform: :00:1f.1[A] -> IRQ 153 PCI->APIC IRQ transform: :00:1f.2[B] -> IRQ 161 PCI->APIC IRQ transform: :00:1f.3[B] -> IRQ 161 PCI->APIC IRQ transform: :05:00.0[A] -> IRQ 137 PCI->APIC IRQ transform: :03:00.0[A] -> IRQ 137 PCI->APIC IRQ transform: :02:00.0[A] -> IRQ 137 PCI->APIC IRQ transform: :01:00.0[A] -> IRQ 169 PCI->APIC IRQ transform: :01:03.0[A] -> IRQ 177 PCI->APIC IRQ transform: :01:04.0[A] -> IRQ 193 PCI->APIC IRQ transform: :01:05.0[A] -> IRQ 185 PCI->APIC IRQ transform: :01:0a.0[A] -> IRQ 177 PCI: Bridge: :00:01.0 IO window: e000-efff MEM window: d7f0-d7ff PREFETCH window: d800-dfff PCI: Bridge: :00:1c.0 IO window: d000-dfff MEM window: disabled. PREFETCH window: disabled. PCI: Bridge: :00:1c.1 IO window: c000-cfff MEM window: d7e0-d7ef PREFETCH window: c000-c00f PCI: Bridge: :00:1c.2 IO window: b000-bfff MEM window: d7d0-d7df PREFETCH window: c010-c01f PCI: Bridge: :00:1e.0 IO window: 9000-afff MEM window: d7c0-d7cf PREFETCH window: c020-c02f PCI: No IRQ known for interrupt pin A of device :00:01.0. Probably buggy MP table. PCI: Setting latency timer of device :00:01.0 to 64 PCI: No IRQ known for interrupt pin A of device :00:1c.0. Probably buggy MP table. PCI: Setting latency timer of device :00:1c.0 to 64 PCI: No IRQ known for interrupt pin B of device :00:1c.1. Probably buggy MP table. PCI: Setting latency timer of device :00:1c.1 to 64 PCI: No IRQ known for interrupt pin C of device :00:1c.2. Probably buggy MP table. PCI: Setting latency timer of device :00:1c.2 to 64 PCI: Setting latency timer of device :00:1e.0 to 64 Machine check exception polling timer started. IA-32 Microcode Update Driver: v1.14 <[EMAIL PROTECTED]> highmem bounce pool size: 64 pages SGI XFS with large block numbers, no debug enabled Initializing Cryptographic API PCI: No IRQ known for interrupt pin A of device :00:01.0. Probably buggy MP table. PCI: Setting latency timer of device :00:01.0 to 64 pcie_portdrv_probe->Dev[2585:8086] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[pcie00] PCI: No IRQ known for interrupt pin A of device :00:1c.0. Probably buggy MP table. PCI: Setting latency timer of device :00:1c.0 to 64 pcie_portdrv_probe->Dev[2660:8086] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[pcie00] Allocate Port Service[pcie02] PCI: No IRQ known for interrupt pin B of device :00:1c.1. Probably buggy MP table. PCI: Setting latency timer of device :00:1c.1 to 64 pcie_portdrv_probe->Dev[2662:8086] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[pcie00] Allocate Port Service[pcie02] PCI: No IRQ known for interrupt pin C of device :00:1c.2. Probably buggy MP table. PCI: Setting latency timer of device :00:1c.2 to 64 pcie_portdrv_probe->Dev[2664:8086] has invalid IRQ. Check vendor BIOS assign_interrupt_mode Found MSI capability Allocate Port Service[pcie00] Allocate Port Service[pcie02] lp: driver loaded but no devices found Real Time Clock Driver v1.12 hw_random: RNG not detected Linux agpgart interface v0.101 (c) Dave Jones [drm] Initialized drm 1.0.0 20040925 serio: i8042 AUX port at 0x60,0x64 irq 12 serio: i8042 KBD port at 0x60,0x64 irq 1 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A parport0:
linux 2.6.13-rc6 Marvell/Yukon networking problems
hi there, due to non supporting Marvell Network drivers for the i have to use the syskonnect sk98lin driver from their homepage. even if these drivers are open-source they were rejected by kernel net maintainers until now. there is a skge driver that is integrated into mainline kernel, but that is not able to support this driver. 2.6.13 - rc 1 is fine and working properly. since -rc2 i got problems with having a rejected irq 153. problem still exists with latest rc6 kernel. complete vanilla except for the sysconnect drivers. anyone i can provide with infos of the adapters? even testing shouldn't be a problem at all. regards marcel lspci output :02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 Gigabit Ethernet Controller (rev 15) Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet Controller (Asus) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR+ PERR- Latency: 0, cache line size 04 Interrupt: pin A routed to IRQ 137 Region 0: Memory at d7dfc000 (64-bit, non-prefetchable) [size=16K] Region 2: I/O ports at b800 [size=256] Expansion ROM at c010 [disabled] [size=128K] Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [50] Vital Product Data Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Address: Data: Capabilities: [e0] #10 [0011] :03:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 Gigabit Ethernet Controller (rev 15) Subsystem: ASUSTeK Computer Inc. Marvell 88E8053 Gigabit Ethernet Controller (Asus) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR+ PERR- Latency: 0, cache line size 04 Interrupt: pin A routed to IRQ 137 Region 0: Memory at d7efc000 (64-bit, non-prefetchable) [size=16K] Region 2: I/O ports at c800 [size=256] Expansion ROM at c000 [disabled] [size=128K] Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [50] Vital Product Data Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 Enable- Address: Data: Capabilities: [e0] #10 [0011] Linux version 2.6.13-rc6 ([EMAIL PROTECTED]) (gcc version 3.4.4 (Gentoo 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)) #1 SMP Tue Aug 9 13:56:55 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - bffb (usable) BIOS-e820: bffb - bffbe000 (ACPI data) BIOS-e820: bffbe000 - bfff (ACPI NVS) BIOS-e820: bfff - c000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 2175MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000ff780 On node 0 totalpages: 786352 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 556976 pages, LIFO batch:31 DMI 2.3 present. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: INTELProduct ID: Premium APIC at: 0xFEE0 Processor #0 15:3 APIC version 20 I/O APIC #2 Version 32 at 0xFEC0. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 1 Allocating PCI resources starting at c000 (gap: c000:3fb0) Built 1 zonelists Kernel command line: root=/dev/hda3 vga=2 gentoo=nodevfs mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Initializing CPU#0 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 3412.864 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x43 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 3111836k/3145408k available (4417k kernel code, 32364k reserved, 1794k data, 216k init, 2227904k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 6834.40 BogoMIPS (lpj=13668808) Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 441d CPU: After vendor identify, caps: bfebfbff
Re: SysKonnect ethernet support for Asus A8VE Deluxe Motherboard?
On Wednesday 13 July 2005 13:51, you wrote: > Hamish Marson wrote: > > I just installed Gentoo distribution on a new PC for a friend who's > > new to Linux, and discovered that although SysKonnect kindly provide > > full source code drivers for their various products on their website, > > that even the latest released kernel sources (i.e. 2.6.12) still don't > > support the device on this motherboard (Along with a whole host of > > other PCI id's that appear in the syskonnect sources). > > Gentoo 2.6.12 kernels provide the skge driver which supports this hardware (I > believe). skge will be included in mainline 2.6.13. > > > I've logged a bug on gentoo.org about it, but thought I'd ask, if > > there's any reason that the syskonnect (sk98lin) drivers are so back > > leve in the kernel sources when syskonnect seem to have published the > > drivers for so many more of their devices in source... > > The driver updates that syskonnect released are ugly and have been rejected by > the network driver maintainers. skge was written as a response to this. > > The very latest sk98lin updates add support for the new Yukon-II PCI-express > adapters. These are not supported by skge -- the Yukon-II is very different > and will eventually be supported by a separate driver. The techniques which > sk98lin uses to support two vastly different network chipsets (yukon/yukon-II) > in the same driver are generally not accepted in the kernel. but they have one advantage for now. they do work. i am using them for about 9 months now including upgrades. regards marcel > > Daniel > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > pgpPpOg4vp3pA.pgp Description: PGP signature
Re: SysKonnect ethernet support for Asus A8VE Deluxe Motherboard?
On Wednesday 13 July 2005 13:51, you wrote: Hamish Marson wrote: I just installed Gentoo distribution on a new PC for a friend who's new to Linux, and discovered that although SysKonnect kindly provide full source code drivers for their various products on their website, that even the latest released kernel sources (i.e. 2.6.12) still don't support the device on this motherboard (Along with a whole host of other PCI id's that appear in the syskonnect sources). Gentoo 2.6.12 kernels provide the skge driver which supports this hardware (I believe). skge will be included in mainline 2.6.13. I've logged a bug on gentoo.org about it, but thought I'd ask, if there's any reason that the syskonnect (sk98lin) drivers are so back leve in the kernel sources when syskonnect seem to have published the drivers for so many more of their devices in source... The driver updates that syskonnect released are ugly and have been rejected by the network driver maintainers. skge was written as a response to this. The very latest sk98lin updates add support for the new Yukon-II PCI-express adapters. These are not supported by skge -- the Yukon-II is very different and will eventually be supported by a separate driver. The techniques which sk98lin uses to support two vastly different network chipsets (yukon/yukon-II) in the same driver are generally not accepted in the kernel. but they have one advantage for now. they do work. i am using them for about 9 months now including upgrades. regards marcel Daniel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ pgpPpOg4vp3pA.pgp Description: PGP signature
Re: [PATCH][2/2] SquashFS
Pavel Machek wrote: -snip- So we are replacing severely-limited cramfs with also-limited squashfs... I think that's rather unfair, Squashfs is significantly better than cramfs. The main aim of Squashfs has been to achieve the best Yes, it *is* rather unfair. Sorry about that. But having 2 different limited compressed filesystems in kernel does not seem good to me. what do you need e.g. reiserfs 4 for? or jfs? or xfs? does not ext2/3 the journalling job also? is there really a need for cifs and samba and ncpfs and nfs v3 and nfs v4? why? -snip- Well, out-of-tree maintainenance takes lot of time, too, so by keeping limited code out-of-kernel we provide quite good incentive to make those limits go away. Perhaps squashfs is good enough improvement over cramfs... But I'd like those 4Gb limits to go away. Pavel we all do - but who does really care about stupid 4Gb limits on embedded systems with e.g. 8 or 32 Mb maybe more of Flash Ram? really noboby if you want to have a squashfs for DVD images e.g. not 4.7Gb but DualLayer ect., why do you complain? you are maybe not even - nor you will be - a user of squashfs. but there are many people outside that use squashfs on different platforms and want to have it integrated to mainline kernel. so why are you blocking? did you have a look at the code? did you find a "trojan horse"? no and no? so why are you blocking? if the coding style is not that what nowadays kernel coder have as coding style? if you care - fix it - otherwise give hints and other people will do. regards marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
Pavel Machek wrote: Hi! [I'm not sure if I should further feed the trolls.] Yes, it *is* rather unfair. Sorry about that. But having 2 different limited compressed filesystems in kernel does not seem good to me. what do you need e.g. reiserfs 4 for? or jfs? or xfs? does not ext2/3 the journalling job also? is there really a need for cifs and samba and ncpfs and nfs v3 and nfs v4? why? Take a look at debate that preceded xfs merge. And btw reiserfs4 is *not* merged. And people merging xfs/reiserfs4/etc did address problems pointed out in their code. Pavel i do not know if i act like a troll - i think a troll is something totally different. yes of course i know xfs or e.g. the kernel version named debate. but - seriously - is it worth spending so many time to discuss instead of just fixing the code meanwhile? that is the main problem also in some other open source projects. discussing instead of developing - not really efficient. ps. FYI no, i am not a troll, and i am also taking part in some open source projects contributing code. regards marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
Pavel Machek wrote: Hi, -snip- but if there is a contribution from the outside - it is not taken "as is" and maybe fixed up, which should be nearly possible in the same time like analysing and commenting the code - it ends up in having less supported hardware. imho if a hardware company does indeed provide us with opensource drivers, we should take these things as a gift, not as a "not coding guide a'like" intrusion which has to be defeated. Remember that horse in Troja? It was a gift, too. of course there had been a horse in troja., but thinking like that nowadays is a bit incorrect - don't you agree? code is reviewed normally - thats what i told before and i stated as good feature - but there is no serious reason to blame every code to have potential "trojan horses" inside and to reject it. I should have added a smiley. I'm not seriously suggesting that it contains deliberate problem. But codestyle uglyness and arbitrary limits may come back and haunt us in future. Once code is in kernel, it is very hard to change on-disk format, for example. Pavel yes, i agree at that point. but, there are many people using this already and if it will _not_ become merged to mainline kernel, maybe these portions of code will get lost. ps: pavel, don't take my opinions as a personal attack or something like this. it is just to bring out my thinking of how things "could" be. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
Pavel Machek wrote: Hi! Also, this filesystem seems to do the same thing as cramfs. We'd need to understand in some detail what advantages squashfs has over cramfs to justify merging it. Again, that is something which is appropriate to the changelog for patch 1/1. Well, probably Phillip can answer this better than me, but the main differences that affect end users (and that is why we are using SquashFS right now) are: CRAMFS SquashFS Max File Size 16Mb 4Gb Max Filesystem Size256Mb 4Gb? So we are replacing severely-limited cramfs with also-limited squashfs... For live DVDs etc 4Gb filesystem size limit will hurt for sure, and 4Gb file size limit will hurt, too. Can those be fixed? ... but if there is a contribution from the outside - it is not taken "as is" and maybe fixed up, which should be nearly possible in the same time like analysing and commenting the code - it ends up in having less supported hardware. imho if a hardware company does indeed provide us with opensource drivers, we should take these things as a gift, not as a "not coding guide a'like" intrusion which has to be defeated. Remember that horse in Troja? It was a gift, too. Pavel of course there had been a horse in troja., but thinking like that nowadays is a bit incorrect - don't you agree? code is reviewed normally - thats what i told before and i stated as good feature - but there is no serious reason to blame every code to have potential "trojan horses" inside and to reject it. regards marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
hi everybody, hi pavel >On Monday 21 March 2005 11:14, you wrote: > Hi! > > > >Also, this filesystem seems to do the same thing as cramfs. We'd need to > > >understand in some detail what advantages squashfs has over cramfs to > > >justify merging it. Again, that is something which is appropriate to the > > >changelog for patch 1/1. > > > > Well, probably Phillip can answer this better than me, but the main > > differences that affect end users (and that is why we are using SquashFS > > right now) are: > > CRAMFS SquashFS > > > > Max File Size 16Mb 4Gb > > Max Filesystem Size256Mb 4Gb? > > So we are replacing severely-limited cramfs with also-limited > squashfs... For live DVDs etc 4Gb filesystem size limit will hurt for > sure, and 4Gb file size limit will hurt, too. Can those be fixed? > > Pavel no - squashfs _is_ indeed an advantage for embedded systems in comparison to cramfs. why does everybody think about huge systems with tons of ram, cpu power whatever - there are also small embedded systems which have real small resources. some notes maybe parts are OT - but imho it must be said someday - reviewing the code is absolutely ok. - adding comments helps the coder and also the users to understand _how_ kernel coding is to be meant - but why can't people just stop to blame every really good thing? in this case it means: of course cramfs and squashfs are to different solutions for saving data in embedded environments like set-top-boxes, pda, ect., but there is a need for having inventions as higher compression rates or more data security. in other cases that means: of course there are finished network drivers from Syskonnect/Marvel/Yukon for the GBit network interfaces. Also they were send to the ml. but nearly the same thing happened to them reviewing the code, critics, and rejection of their code. this all ends up in not supported hardware - or - someday supported hardware cause somebody is in reel need of those features and just publishes the patches online like a DIY-Patchset for different kernel versions. Hasn't it been the aim of linux to run on different architectures, support lots of filesystems, partition types, network adapters, bus-systems whatever? but if there is a contribution from the outside - it is not taken "as is" and maybe fixed up, which should be nearly possible in the same time like analysing and commenting the code - it ends up in having less supported hardware. imho if a hardware company does indeed provide us with opensource drivers, we should take these things as a gift, not as a "not coding guide a'like" intrusion which has to be defeated. ready to take your comments :) regards marcel pgpCLHSCz2wEB.pgp Description: PGP signature
Re: [PATCH][2/2] SquashFS
hi everybody, hi pavel On Monday 21 March 2005 11:14, you wrote: Hi! Also, this filesystem seems to do the same thing as cramfs. We'd need to understand in some detail what advantages squashfs has over cramfs to justify merging it. Again, that is something which is appropriate to the changelog for patch 1/1. Well, probably Phillip can answer this better than me, but the main differences that affect end users (and that is why we are using SquashFS right now) are: CRAMFS SquashFS Max File Size 16Mb 4Gb Max Filesystem Size256Mb 4Gb? So we are replacing severely-limited cramfs with also-limited squashfs... For live DVDs etc 4Gb filesystem size limit will hurt for sure, and 4Gb file size limit will hurt, too. Can those be fixed? Pavel no - squashfs _is_ indeed an advantage for embedded systems in comparison to cramfs. why does everybody think about huge systems with tons of ram, cpu power whatever - there are also small embedded systems which have real small resources. some notes maybe parts are OT - but imho it must be said someday - reviewing the code is absolutely ok. - adding comments helps the coder and also the users to understand _how_ kernel coding is to be meant - but why can't people just stop to blame every really good thing? in this case it means: of course cramfs and squashfs are to different solutions for saving data in embedded environments like set-top-boxes, pda, ect., but there is a need for having inventions as higher compression rates or more data security. in other cases that means: of course there are finished network drivers from Syskonnect/Marvel/Yukon for the GBit network interfaces. Also they were send to the ml. but nearly the same thing happened to them reviewing the code, critics, and rejection of their code. this all ends up in not supported hardware - or - someday supported hardware cause somebody is in reel need of those features and just publishes the patches online like a DIY-Patchset for different kernel versions. Hasn't it been the aim of linux to run on different architectures, support lots of filesystems, partition types, network adapters, bus-systems whatever? but if there is a contribution from the outside - it is not taken as is and maybe fixed up, which should be nearly possible in the same time like analysing and commenting the code - it ends up in having less supported hardware. imho if a hardware company does indeed provide us with opensource drivers, we should take these things as a gift, not as a not coding guide a'like intrusion which has to be defeated. ready to take your comments :) regards marcel pgpCLHSCz2wEB.pgp Description: PGP signature
Re: [PATCH][2/2] SquashFS
Pavel Machek wrote: Hi! Also, this filesystem seems to do the same thing as cramfs. We'd need to understand in some detail what advantages squashfs has over cramfs to justify merging it. Again, that is something which is appropriate to the changelog for patch 1/1. Well, probably Phillip can answer this better than me, but the main differences that affect end users (and that is why we are using SquashFS right now) are: CRAMFS SquashFS Max File Size 16Mb 4Gb Max Filesystem Size256Mb 4Gb? So we are replacing severely-limited cramfs with also-limited squashfs... For live DVDs etc 4Gb filesystem size limit will hurt for sure, and 4Gb file size limit will hurt, too. Can those be fixed? ... but if there is a contribution from the outside - it is not taken as is and maybe fixed up, which should be nearly possible in the same time like analysing and commenting the code - it ends up in having less supported hardware. imho if a hardware company does indeed provide us with opensource drivers, we should take these things as a gift, not as a not coding guide a'like intrusion which has to be defeated. Remember that horse in Troja? It was a gift, too. Pavel of course there had been a horse in troja., but thinking like that nowadays is a bit incorrect - don't you agree? code is reviewed normally - thats what i told before and i stated as good feature - but there is no serious reason to blame every code to have potential trojan horses inside and to reject it. regards marcel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
Pavel Machek wrote: Hi, -snip- but if there is a contribution from the outside - it is not taken as is and maybe fixed up, which should be nearly possible in the same time like analysing and commenting the code - it ends up in having less supported hardware. imho if a hardware company does indeed provide us with opensource drivers, we should take these things as a gift, not as a not coding guide a'like intrusion which has to be defeated. Remember that horse in Troja? It was a gift, too. of course there had been a horse in troja., but thinking like that nowadays is a bit incorrect - don't you agree? code is reviewed normally - thats what i told before and i stated as good feature - but there is no serious reason to blame every code to have potential trojan horses inside and to reject it. I should have added a smiley. I'm not seriously suggesting that it contains deliberate problem. But codestyle uglyness and arbitrary limits may come back and haunt us in future. Once code is in kernel, it is very hard to change on-disk format, for example. Pavel yes, i agree at that point. but, there are many people using this already and if it will _not_ become merged to mainline kernel, maybe these portions of code will get lost. ps: pavel, don't take my opinions as a personal attack or something like this. it is just to bring out my thinking of how things could be. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
Pavel Machek wrote: Hi! [I'm not sure if I should further feed the trolls.] Yes, it *is* rather unfair. Sorry about that. But having 2 different limited compressed filesystems in kernel does not seem good to me. what do you need e.g. reiserfs 4 for? or jfs? or xfs? does not ext2/3 the journalling job also? is there really a need for cifs and samba and ncpfs and nfs v3 and nfs v4? why? Take a look at debate that preceded xfs merge. And btw reiserfs4 is *not* merged. And people merging xfs/reiserfs4/etc did address problems pointed out in their code. Pavel i do not know if i act like a troll - i think a troll is something totally different. yes of course i know xfs or e.g. the kernel version named debate. but - seriously - is it worth spending so many time to discuss instead of just fixing the code meanwhile? that is the main problem also in some other open source projects. discussing instead of developing - not really efficient. ps. FYI no, i am not a troll, and i am also taking part in some open source projects contributing code. regards marcel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2/2] SquashFS
Pavel Machek wrote: -snip- So we are replacing severely-limited cramfs with also-limited squashfs... I think that's rather unfair, Squashfs is significantly better than cramfs. The main aim of Squashfs has been to achieve the best Yes, it *is* rather unfair. Sorry about that. But having 2 different limited compressed filesystems in kernel does not seem good to me. what do you need e.g. reiserfs 4 for? or jfs? or xfs? does not ext2/3 the journalling job also? is there really a need for cifs and samba and ncpfs and nfs v3 and nfs v4? why? -snip- Well, out-of-tree maintainenance takes lot of time, too, so by keeping limited code out-of-kernel we provide quite good incentive to make those limits go away. Perhaps squashfs is good enough improvement over cramfs... But I'd like those 4Gb limits to go away. Pavel we all do - but who does really care about stupid 4Gb limits on embedded systems with e.g. 8 or 32 Mb maybe more of Flash Ram? really noboby if you want to have a squashfs for DVD images e.g. not 4.7Gb but DualLayer ect., why do you complain? you are maybe not even - nor you will be - a user of squashfs. but there are many people outside that use squashfs on different platforms and want to have it integrated to mainline kernel. so why are you blocking? did you have a look at the code? did you find a trojan horse? no and no? so why are you blocking? if the coding style is not that what nowadays kernel coder have as coding style? if you care - fix it - otherwise give hints and other people will do. regards marcel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc5
On Tuesday 01 March 2005 22:38, Benjamin Herrenschmidt wrote: > On Tue, 2005-03-01 at 12:36 +0100, Mws wrote: > > hi benjamin > > > > now i had some spare time to do some investigation > > > > booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1 > > brings up a framebuffer console. everything is fine. > > starting xorg-x11 with Ati binary only drivers just brings up a black screen > > without a mouse cursor and freezes the hole machine. even network ect. > > is no more reachable from outside the machine. worst thing out of that > > a tail on the log files (on another machine) does immediately stop - also > > no > > output is written to syslog :/ > > > > next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1 > > starting xorg-x11 with Xorg Radeon driver. > > a grey screen comes up - mouse cursor is visible and also able to move for > > 5 - 8 seconds after screen display - then freezes the whole machine again. > > Ok, so it's not dynamic clocks. At this point, i have no idea what's > going on. I don't yet have any access to PCI Express hardware. You > should report this to X.org list where others can try to help me track > this down. > > Ben. it's possible to do so, but i also will try to find out whats going on. i don't know if i will have success. regards marcel pgp2GpCGx86XC.pgp Description: PGP signature
Re: 2.6.11-rc5
On Tuesday 01 March 2005 15:36, Helge Hafting wrote: > Mws wrote: > > >hi benjamin > > > >now i had some spare time to do some investigation > > > >booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1 > >brings up a framebuffer console. everything is fine. > >starting xorg-x11 with Ati binary only drivers just brings up a black screen > >without a mouse cursor and freezes the hole machine. even network ect. > >is no more reachable from outside the machine. worst thing out of that > >a tail on the log files (on another machine) does immediately stop - also no > >output is written to syslog :/ > > > >next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1 > >starting xorg-x11 with Xorg Radeon driver. > >a grey screen comes up - mouse cursor is visible and also able to move for > >5 - 8 seconds after screen display - then freezes the whole machine again. > > > > > Did you try without dri? (Comment out dri in the X config file) > I use a radeon 7000 VE at work, where X will hang after a few > seconds if dri is enabled in X. Disable dri, and it is > rock solid. xfree or x.org makes no difference here. > > Helge Hafting hi, i had dri disabled already :/ regards marcel pgpml38TTNxWC.pgp Description: PGP signature
Re: 2.6.11-rc5
hi benjamin now i had some spare time to do some investigation booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1 brings up a framebuffer console. everything is fine. starting xorg-x11 with Ati binary only drivers just brings up a black screen without a mouse cursor and freezes the hole machine. even network ect. is no more reachable from outside the machine. worst thing out of that a tail on the log files (on another machine) does immediately stop - also no output is written to syslog :/ next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1 starting xorg-x11 with Xorg Radeon driver. a grey screen comes up - mouse cursor is visible and also able to move for 5 - 8 seconds after screen display - then freezes the whole machine again. regards marcel On Saturday 26 February 2005 01:50, Benjamin Herrenschmidt wrote: > On Fri, 2005-02-25 at 14:30 +0100, Mws wrote: > > hi, > > > > i also have problems with 2.6.11-rc5 and radeon: > > > > i am using a ATI Radeon X600 PciExpress. > > > > a) now the console framebuffer seems to bee working, thx benjamin :) > > b) when bootup seq ist completed and i want to start X (xorg-x11) with > > ati-drivers > > x is freezing - not your problem, but the console is not correctly > > restored :/ the only way > > out is to reset the machine :/ > > 2.6.11-rc3 was running fine in this case > > Hrm, the binary drivers ? oh well... some users had them freezing vs. > radeonfb before and not now. I don't know what they do and don't have > access to a machine with them (there are no ppc versions) so it will be > difficult to track. I suspect they completely reconfigure the chip and > don't restore it properly tho. > What exactly is happening. Does X launches at all ? When does it > freeze ? On X launch or when exiting it ? Have you tried disabling > dynamic clock tweaking ? (radeonfb.default_dynclk=-1 or 0 on the > cmdline, first one means "don't touch the registers", secoond one means > "disable dynamic clocks"). pgpBlKkcSxfka.pgp Description: PGP signature
Re: 2.6.11-rc5
hi benjamin now i had some spare time to do some investigation booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1 brings up a framebuffer console. everything is fine. starting xorg-x11 with Ati binary only drivers just brings up a black screen without a mouse cursor and freezes the hole machine. even network ect. is no more reachable from outside the machine. worst thing out of that a tail on the log files (on another machine) does immediately stop - also no output is written to syslog :/ next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1 starting xorg-x11 with Xorg Radeon driver. a grey screen comes up - mouse cursor is visible and also able to move for 5 - 8 seconds after screen display - then freezes the whole machine again. regards marcel On Saturday 26 February 2005 01:50, Benjamin Herrenschmidt wrote: On Fri, 2005-02-25 at 14:30 +0100, Mws wrote: hi, i also have problems with 2.6.11-rc5 and radeon: i am using a ATI Radeon X600 PciExpress. a) now the console framebuffer seems to bee working, thx benjamin :) b) when bootup seq ist completed and i want to start X (xorg-x11) with ati-drivers x is freezing - not your problem, but the console is not correctly restored :/ the only way out is to reset the machine :/ 2.6.11-rc3 was running fine in this case Hrm, the binary drivers ? oh well... some users had them freezing vs. radeonfb before and not now. I don't know what they do and don't have access to a machine with them (there are no ppc versions) so it will be difficult to track. I suspect they completely reconfigure the chip and don't restore it properly tho. What exactly is happening. Does X launches at all ? When does it freeze ? On X launch or when exiting it ? Have you tried disabling dynamic clock tweaking ? (radeonfb.default_dynclk=-1 or 0 on the cmdline, first one means don't touch the registers, secoond one means disable dynamic clocks). pgpBlKkcSxfka.pgp Description: PGP signature
Re: 2.6.11-rc5
On Tuesday 01 March 2005 15:36, Helge Hafting wrote: Mws wrote: hi benjamin now i had some spare time to do some investigation booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1 brings up a framebuffer console. everything is fine. starting xorg-x11 with Ati binary only drivers just brings up a black screen without a mouse cursor and freezes the hole machine. even network ect. is no more reachable from outside the machine. worst thing out of that a tail on the log files (on another machine) does immediately stop - also no output is written to syslog :/ next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1 starting xorg-x11 with Xorg Radeon driver. a grey screen comes up - mouse cursor is visible and also able to move for 5 - 8 seconds after screen display - then freezes the whole machine again. Did you try without dri? (Comment out dri in the X config file) I use a radeon 7000 VE at work, where X will hang after a few seconds if dri is enabled in X. Disable dri, and it is rock solid. xfree or x.org makes no difference here. Helge Hafting hi, i had dri disabled already :/ regards marcel pgpml38TTNxWC.pgp Description: PGP signature
Re: 2.6.11-rc5
On Tuesday 01 March 2005 22:38, Benjamin Herrenschmidt wrote: On Tue, 2005-03-01 at 12:36 +0100, Mws wrote: hi benjamin now i had some spare time to do some investigation booting the 2.6.11-rc5 with radeonfb.default_dynclk=0 or with -1 brings up a framebuffer console. everything is fine. starting xorg-x11 with Ati binary only drivers just brings up a black screen without a mouse cursor and freezes the hole machine. even network ect. is no more reachable from outside the machine. worst thing out of that a tail on the log files (on another machine) does immediately stop - also no output is written to syslog :/ next scenario - test 2.6.11-rc5 with radeonfb.default_dynclock=0 and -1 starting xorg-x11 with Xorg Radeon driver. a grey screen comes up - mouse cursor is visible and also able to move for 5 - 8 seconds after screen display - then freezes the whole machine again. Ok, so it's not dynamic clocks. At this point, i have no idea what's going on. I don't yet have any access to PCI Express hardware. You should report this to X.org list where others can try to help me track this down. Ben. it's possible to do so, but i also will try to find out whats going on. i don't know if i will have success. regards marcel pgp2GpCGx86XC.pgp Description: PGP signature
Re: 2.6.11-rc5
hi, i also have problems with 2.6.11-rc5 and radeon: i am using a ATI Radeon X600 PciExpress. a) now the console framebuffer seems to bee working, thx benjamin :) b) when bootup seq ist completed and i want to start X (xorg-x11) with ati-drivers x is freezing - not your problem, but the console is not correctly restored :/ the only way out is to reset the machine :/ 2.6.11-rc3 was running fine in this case i have attached my lspci -vv & lspci -tv output and following a small seq of the dmesg output when initializing the radeon fb. if i can provide/assit you with testing, i am available to do so, also if you need more information on my system. i am subscribed to lkml, but i would like to be included into cc seprately, thx. radeonfb_pci_register BEGIN ACPI: PCI interrupt :05:00.0[A] -> GSI 16 (level, low) -> IRQ 16 radeonfb (:05:00.0): Found 131072k of DDR 128 bits wide videoram radeonfb (:05:00.0): mapped 16384k videoram radeonfb: Found Intel x86 BIOS ROM Image radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=400.00 Mhz, System=300.00 MHz radeonfb: PLL min 2 max 4 1 chips in connector info - chip 1 has 2 connectors * connector 0 of type 2 (CRT) : 2300 * connector 1 of type 3 (DVI-I) : 3221 Starting monitor auto detection... radeonfb: I2C (port 1) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: Monitor 1 type CRT found radeonfb: EDID probed radeonfb: Monitor 2 type no found Display is GTF capable hStart = 1344, hEnd = 1504, hTotal = 1728 vStart = 1025, vEnd = 1028, vTotal = 1072 h_total_disp = 0x9f00d7hsync_strt_wid = 0x14054a v_total_disp = 0x3ff042f vsync_strt_wid = 0x30400 pixclock = 6349 freq = 15750 freq = 15750, PLL min = 2, PLL max = 4 ref_div = 12, ref_clk = 2700, output_freq = 31500 ref_div = 12, ref_clk = 2700, output_freq = 31500 post div = 0x1 fb_div = 0x8c ppll_div_3 = 0x1008c Console: switching to colour frame buffer device 160x64 radeonfb (:05:00.0): ATI Radeon [b radeonfb_pci_register END -[00]-+-00.0 Intel Corp. 925X/XE Memory Controller Hub +-01.0-[05]--+-00.0 ATI Technologies Inc RV370 5B62 [Radeon X600 (PCIE)] |\-00.1 ATI Technologies Inc: Unknown device 5b72 +-1b.0 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller +-1c.0-[04]-- +-1c.1-[03]00.0 Marvell Technology Group Ltd. Gigabit Ethernet Controller +-1c.2-[02]00.0 Marvell Technology Group Ltd. Gigabit Ethernet Controller +-1d.0 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 +-1d.1 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 +-1d.2 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 +-1d.3 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 +-1d.7 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller +-1e.0-[01]--+-00.0 Marvell Technology Group Ltd.: Unknown device 1fa7 |+-03.0 Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller |+-04.0 Integrated Technology Express, Inc. IT/ITE8212 Dual channel ATA RAID controller (PCI version seems to be IT8212, embedded seems to be ITE8212) |+-05.0 Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3114 [SATALink/SATARaid] Serial ATA Controller |\-0a.0 Philips Semiconductors SAA7146 +-1f.0 Intel Corp. 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge +-1f.1 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller +-1f.2 Intel Corp. 82801FR/FRW (ICH6R/ICH6RW) SATA Controller \-1f.3 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller :00:00.0 Host bridge: Intel Corp. 925X/XE Memory Controller Hub (rev 04) Subsystem: Intel Corp.: Unknown device 2580 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Reset- FastB2B- Capabilities: [88] #0d [] Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Address: Data: Capabilities: [a0] #10 [0141] :00:1b.0 Class 0403: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 03) Subsystem: ASUSTeK Computer Inc.: Unknown device 813d Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Re: 2.6.11-rc5
hi, i also have problems with 2.6.11-rc5 and radeon: i am using a ATI Radeon X600 PciExpress. a) now the console framebuffer seems to bee working, thx benjamin :) b) when bootup seq ist completed and i want to start X (xorg-x11) with ati-drivers x is freezing - not your problem, but the console is not correctly restored :/ the only way out is to reset the machine :/ 2.6.11-rc3 was running fine in this case i have attached my lspci -vv lspci -tv output and following a small seq of the dmesg output when initializing the radeon fb. if i can provide/assit you with testing, i am available to do so, also if you need more information on my system. i am subscribed to lkml, but i would like to be included into cc seprately, thx. radeonfb_pci_register BEGIN ACPI: PCI interrupt :05:00.0[A] - GSI 16 (level, low) - IRQ 16 radeonfb (:05:00.0): Found 131072k of DDR 128 bits wide videoram radeonfb (:05:00.0): mapped 16384k videoram radeonfb: Found Intel x86 BIOS ROM Image radeonfb: Retreived PLL infos from BIOS radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=400.00 Mhz, System=300.00 MHz radeonfb: PLL min 2 max 4 1 chips in connector info - chip 1 has 2 connectors * connector 0 of type 2 (CRT) : 2300 * connector 1 of type 3 (DVI-I) : 3221 Starting monitor auto detection... radeonfb: I2C (port 1) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 2) ... not found radeonfb: I2C (port 4) ... not found radeonfb: I2C (port 3) ... found CRT display radeonfb: Monitor 1 type CRT found radeonfb: EDID probed radeonfb: Monitor 2 type no found Display is GTF capable hStart = 1344, hEnd = 1504, hTotal = 1728 vStart = 1025, vEnd = 1028, vTotal = 1072 h_total_disp = 0x9f00d7hsync_strt_wid = 0x14054a v_total_disp = 0x3ff042f vsync_strt_wid = 0x30400 pixclock = 6349 freq = 15750 freq = 15750, PLL min = 2, PLL max = 4 ref_div = 12, ref_clk = 2700, output_freq = 31500 ref_div = 12, ref_clk = 2700, output_freq = 31500 post div = 0x1 fb_div = 0x8c ppll_div_3 = 0x1008c Console: switching to colour frame buffer device 160x64 radeonfb (:05:00.0): ATI Radeon [b radeonfb_pci_register END -[00]-+-00.0 Intel Corp. 925X/XE Memory Controller Hub +-01.0-[05]--+-00.0 ATI Technologies Inc RV370 5B62 [Radeon X600 (PCIE)] |\-00.1 ATI Technologies Inc: Unknown device 5b72 +-1b.0 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller +-1c.0-[04]-- +-1c.1-[03]00.0 Marvell Technology Group Ltd. Gigabit Ethernet Controller +-1c.2-[02]00.0 Marvell Technology Group Ltd. Gigabit Ethernet Controller +-1d.0 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 +-1d.1 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 +-1d.2 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 +-1d.3 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 +-1d.7 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller +-1e.0-[01]--+-00.0 Marvell Technology Group Ltd.: Unknown device 1fa7 |+-03.0 Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller |+-04.0 Integrated Technology Express, Inc. IT/ITE8212 Dual channel ATA RAID controller (PCI version seems to be IT8212, embedded seems to be ITE8212) |+-05.0 Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3114 [SATALink/SATARaid] Serial ATA Controller |\-0a.0 Philips Semiconductors SAA7146 +-1f.0 Intel Corp. 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge +-1f.1 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller +-1f.2 Intel Corp. 82801FR/FRW (ICH6R/ICH6RW) SATA Controller \-1f.3 Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller :00:00.0 Host bridge: Intel Corp. 925X/XE Memory Controller Hub (rev 04) Subsystem: Intel Corp.: Unknown device 2580 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Capabilities: [e0] #09 [2109] :00:01.0 PCI bridge: Intel Corp. 925X/XE PCI Express Root Port (rev 04) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0, cache line size 04 Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: d7f0-d7ff Prefetchable memory behind bridge: d800-dfff Expansion ROM at e000 [disabled] [size=4K] BridgeCtl:
Re: [BK] upgrade will be needed
On Monday 14 February 2005 03:08, Larry McVoy wrote: > This is a heads up that the BK tree for the kernel is currently at 59,000 > changesets give or take a few. The BK that you are using uses unsigned > shorts for the internal names of each delta which means you folks are > about 100 days away from things no longer working. > > The good news is that the openlogging tree for the kernel has 135,000 > changesets so we've obviously long since fixed this problem. > > The bad news is that you will need to upgrade your BK binary in order > to pass over the 64K changeset boundary. The data is stored on disk in > ascii so it doesn't matter if you upgrade until you hit the problem but > sooner or later you will need to upgrade. > > We'll get the fix into bk-3.2.4 which should be out by the end of the > month. When we release that we'll send out notice and it would be good > if people gave it a try and let us know if they hit issues because in a > couple of months everyone is going to have to upgrade. > > It's possible that we'll be changing the BK license to conform more with > our commercial license but we won't do that without running it by Linus & > Co to make sure that it's acceptable. One change we'd like to make there > is to clarify the non-compete stuff. We've had some people who have > indicated that they believed that if they used BK they were agreeing > that they would never work on another SCM system. We can see how it > is possible that people would interpret the license that way but that > wasn't our intent. What we would like to do is change the language to > say that if you use BK you are agreeing that you won't work on another > SCM for 1 year after you stop using BK. But after that you would be > able to hack on anything that you wanted. That was more of what we > had in mind in the first place but we didn't make it clear. If you all > thought that using BK meant you had no right to hack on SCM ever again, > that's just not fair. We need to protect our IP but you should have > the right to choose to go hack SCM if that's what you (our first choice > is that you came and worked here, we really like kernel hackers, but if > you don't want to that's cool too). Hi, do you mean "if you use BK you are agreeing that you won't work on another SCM for 1 year after you stop using BK." for the kernel tree and developers or in general? i think this statement is just a kind of trying the MicrosoftBeingTheOneAndOnly way. it's a kind of extortion - use bk or die :/ if it is really being that way - say goodbye to bk as soon as possible. regards mws pgp0ZYl8k8Cae.pgp Description: PGP signature
Re: [BK] upgrade will be needed
On Monday 14 February 2005 03:08, Larry McVoy wrote: This is a heads up that the BK tree for the kernel is currently at 59,000 changesets give or take a few. The BK that you are using uses unsigned shorts for the internal names of each delta which means you folks are about 100 days away from things no longer working. The good news is that the openlogging tree for the kernel has 135,000 changesets so we've obviously long since fixed this problem. The bad news is that you will need to upgrade your BK binary in order to pass over the 64K changeset boundary. The data is stored on disk in ascii so it doesn't matter if you upgrade until you hit the problem but sooner or later you will need to upgrade. We'll get the fix into bk-3.2.4 which should be out by the end of the month. When we release that we'll send out notice and it would be good if people gave it a try and let us know if they hit issues because in a couple of months everyone is going to have to upgrade. It's possible that we'll be changing the BK license to conform more with our commercial license but we won't do that without running it by Linus Co to make sure that it's acceptable. One change we'd like to make there is to clarify the non-compete stuff. We've had some people who have indicated that they believed that if they used BK they were agreeing that they would never work on another SCM system. We can see how it is possible that people would interpret the license that way but that wasn't our intent. What we would like to do is change the language to say that if you use BK you are agreeing that you won't work on another SCM for 1 year after you stop using BK. But after that you would be able to hack on anything that you wanted. That was more of what we had in mind in the first place but we didn't make it clear. If you all thought that using BK meant you had no right to hack on SCM ever again, that's just not fair. We need to protect our IP but you should have the right to choose to go hack SCM if that's what you (our first choice is that you came and worked here, we really like kernel hackers, but if you don't want to that's cool too). Hi, do you mean if you use BK you are agreeing that you won't work on another SCM for 1 year after you stop using BK. for the kernel tree and developers or in general? i think this statement is just a kind of trying the MicrosoftBeingTheOneAndOnly way. it's a kind of extortion - use bk or die :/ if it is really being that way - say goodbye to bk as soon as possible. regards mws pgp0ZYl8k8Cae.pgp Description: PGP signature
Re: DVB at76c651.c driver seems to be dead code
On Friday 11 February 2005 00:56, Adrian Bunk wrote: > I didn't find any way how the drivers/media/dvb/frontends/at76c651.c > driver would do anything inside kernel 2.6.11-rc3-mm2. All it does is to > EXPORT_SYMBOL a function at76c651_attach that isn't used anywhere. > > Is a patch to remove this driver OK or did I miss anything? > > cu > Adrian > FYI The atmel at76c651 frontend driver is used for the Sagem DBox2 Digital Cable Receiver. As all other parts of the dbox2 drivers are atm not hosted at kernel cvs but at cvs.tuxbox.org you won't find any components in mainline kernel tree using this. thus we are a hobby project - but even well known - there are not so many developer available to make every kernel driver and other parts of it "kernel-style-alike". maybe there is more progress and kernel driver patching into mainline in the future. we are having 2.6.9 running on dbox2 - higher versions are atm broken for support of the mpc 823 architecture :/ removing this driver is not wanted. regards Marcel Siegert [EMAIL PROTECTED] pgpkLhF3AFyg8.pgp Description: PGP signature
Re: DVB at76c651.c driver seems to be dead code
On Friday 11 February 2005 00:56, Adrian Bunk wrote: I didn't find any way how the drivers/media/dvb/frontends/at76c651.c driver would do anything inside kernel 2.6.11-rc3-mm2. All it does is to EXPORT_SYMBOL a function at76c651_attach that isn't used anywhere. Is a patch to remove this driver OK or did I miss anything? cu Adrian FYI The atmel at76c651 frontend driver is used for the Sagem DBox2 Digital Cable Receiver. As all other parts of the dbox2 drivers are atm not hosted at kernel cvs but at cvs.tuxbox.org you won't find any components in mainline kernel tree using this. thus we are a hobby project - but even well known - there are not so many developer available to make every kernel driver and other parts of it kernel-style-alike. maybe there is more progress and kernel driver patching into mainline in the future. we are having 2.6.9 running on dbox2 - higher versions are atm broken for support of the mpc 823 architecture :/ removing this driver is not wanted. regards Marcel Siegert [EMAIL PROTECTED] pgpkLhF3AFyg8.pgp Description: PGP signature
strange behaviour using cryptoloop & ext2
hi, i just tried to set up a 120 gb S-ATA device using cryptoloop. losetup worked. mkfs.ext2 results into following dmesg output when nearly 400/896 blocks are finished. oom-killer: gfp_mask=0xd0 DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 cpu 1 hot: low 2, high 6, batch 1 cpu 1 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 cpu 1 hot: low 32, high 96, batch 16 cpu 1 cold: low 0, high 32, batch 16 HighMem per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 cpu 1 hot: low 32, high 96, batch 16 cpu 1 cold: low 0, high 32, batch 16 Free pages: 699244kB (695360kB HighMem) Active:102229 inactive:193160 dirty:0 writeback:176544 unstable:0 free:174811 slab:42715 mapped:101414 pagetables:857 DMA free:68kB min:68kB low:84kB high:100kB active:156kB inactive:6744kB present:16384kB pages_scanned:1997 all_unreclaimable? no protections[]: 0 0 0 Normal free:3816kB min:3756kB low:4692kB high:5632kB active:756kB inactive:700644kB present:901120kB pages_scanned:1193 all_unreclaimable? no protections[]: 0 0 0 HighMem free:695360kB min:512kB low:640kB high:768kB active:408004kB inactive:65324kB present:1179328kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 DMA: 3*4kB 1*8kB 1*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 68kB Normal: 0*4kB 63*8kB 13*16kB 9*32kB 2*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3816kB HighMem: 11378*4kB 8793*8kB 3051*16kB 1276*32kB 760*64kB 537*128kB 409*256kB 137*512kB 71*1024kB 33*2048kB 14*4096kB = 695360kB Swap cache: add 0, delete 0, find 0/0, race 0+0 Out of Memory: Killed process 29470 (konqueror). oom-killer: gfp_mask=0x80d0 DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 cpu 1 hot: low 2, high 6, batch 1 cpu 1 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 cpu 1 hot: low 32, high 96, batch 16 cpu 1 cold: low 0, high 32, batch 16 HighMem per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 cpu 1 hot: low 32, high 96, batch 16 cpu 1 cold: low 0, high 32, batch 16 otherwise mkfs.xfs worked properly and gave the following output. mkfs.xfs /dev/loop0 meta-data=/dev/loop0 isize=256agcount=16, agsize=1831535 blks = sectsz=512 data = bsize=4096 blocks=29304560, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=14308, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 util-linux is @version util-linux-2.12p kernel is 2.6.11-rc2 having the ITE8212 patch from the ac patchset glibc is GNU C Library 20041102 release version 2.3.4, by Roland McGrath et al. gcc is versioned gcc-3.4.3.20050110 HD is Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3120026AS Rev: 3.05 Type: Direct-AccessANSI SCSI revision: 05 lspci shows lspci :00:00.0 Host bridge: Intel Corp. 925X/XE Memory Controller Hub (rev 04) :00:01.0 PCI bridge: Intel Corp. 925X/XE PCI Express Root Port (rev 04) :00:1b.0 Class 0403: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 03) :00:1c.0 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) :00:1c.1 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 03) :00:1c.2 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 03) :00:1d.0 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) :00:1d.1 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) :00:1d.2 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) :00:1d.3 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) :00:1d.7 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev d3) :00:1f.0 ISA bridge: Intel Corp. 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) :00:1f.1 IDE interface: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) :00:1f.2 Class 0106: Intel Corp. 82801FR/FRW (ICH6R/ICH6RW) SATA Controller (rev 03) :00:1f.3 SMBus: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) :01:00.0 Ethernet controller: Marvell Technology Group Ltd.: Unknown device 1fa7 (rev 07) :01:03.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller (rev 01) :01:04.0
strange behaviour using cryptoloop ext2
hi, i just tried to set up a 120 gb S-ATA device using cryptoloop. losetup worked. mkfs.ext2 results into following dmesg output when nearly 400/896 blocks are finished. oom-killer: gfp_mask=0xd0 DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 cpu 1 hot: low 2, high 6, batch 1 cpu 1 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 cpu 1 hot: low 32, high 96, batch 16 cpu 1 cold: low 0, high 32, batch 16 HighMem per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 cpu 1 hot: low 32, high 96, batch 16 cpu 1 cold: low 0, high 32, batch 16 Free pages: 699244kB (695360kB HighMem) Active:102229 inactive:193160 dirty:0 writeback:176544 unstable:0 free:174811 slab:42715 mapped:101414 pagetables:857 DMA free:68kB min:68kB low:84kB high:100kB active:156kB inactive:6744kB present:16384kB pages_scanned:1997 all_unreclaimable? no protections[]: 0 0 0 Normal free:3816kB min:3756kB low:4692kB high:5632kB active:756kB inactive:700644kB present:901120kB pages_scanned:1193 all_unreclaimable? no protections[]: 0 0 0 HighMem free:695360kB min:512kB low:640kB high:768kB active:408004kB inactive:65324kB present:1179328kB pages_scanned:0 all_unreclaimable? no protections[]: 0 0 0 DMA: 3*4kB 1*8kB 1*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 68kB Normal: 0*4kB 63*8kB 13*16kB 9*32kB 2*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 3816kB HighMem: 11378*4kB 8793*8kB 3051*16kB 1276*32kB 760*64kB 537*128kB 409*256kB 137*512kB 71*1024kB 33*2048kB 14*4096kB = 695360kB Swap cache: add 0, delete 0, find 0/0, race 0+0 Out of Memory: Killed process 29470 (konqueror). oom-killer: gfp_mask=0x80d0 DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 cpu 1 hot: low 2, high 6, batch 1 cpu 1 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 cpu 1 hot: low 32, high 96, batch 16 cpu 1 cold: low 0, high 32, batch 16 HighMem per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 cpu 1 hot: low 32, high 96, batch 16 cpu 1 cold: low 0, high 32, batch 16 otherwise mkfs.xfs worked properly and gave the following output. mkfs.xfs /dev/loop0 meta-data=/dev/loop0 isize=256agcount=16, agsize=1831535 blks = sectsz=512 data = bsize=4096 blocks=29304560, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=14308, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 util-linux is @version util-linux-2.12p kernel is 2.6.11-rc2 having the ITE8212 patch from the ac patchset glibc is GNU C Library 20041102 release version 2.3.4, by Roland McGrath et al. gcc is versioned gcc-3.4.3.20050110 HD is Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: ATA Model: ST3120026AS Rev: 3.05 Type: Direct-AccessANSI SCSI revision: 05 lspci shows lspci :00:00.0 Host bridge: Intel Corp. 925X/XE Memory Controller Hub (rev 04) :00:01.0 PCI bridge: Intel Corp. 925X/XE PCI Express Root Port (rev 04) :00:1b.0 Class 0403: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) High Definition Audio Controller (rev 03) :00:1c.0 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03) :00:1c.1 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 03) :00:1c.2 PCI bridge: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 03) :00:1d.0 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) :00:1d.1 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) :00:1d.2 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) :00:1d.3 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) :00:1d.7 USB Controller: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev d3) :00:1f.0 ISA bridge: Intel Corp. 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03) :00:1f.1 IDE interface: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03) :00:1f.2 Class 0106: Intel Corp. 82801FR/FRW (ICH6R/ICH6RW) SATA Controller (rev 03) :00:1f.3 SMBus: Intel Corp. 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03) :01:00.0 Ethernet controller: Marvell Technology Group Ltd.: Unknown device 1fa7 (rev 07) :01:03.0 FireWire (IEEE 1394): Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller (rev 01) :01:04.0
