Re: MCE Erros

2007-03-22 Thread Mws
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

2007-03-22 Thread Mws
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

2007-03-13 Thread Mws
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

2007-03-13 Thread Mws
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

2007-03-08 Thread Mws
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

2007-03-08 Thread Mws
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

2007-03-07 Thread Mws
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

2007-03-07 Thread Mws
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

2007-03-01 Thread Mws
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

2007-03-01 Thread Mws
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

2007-02-15 Thread Mws
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

2007-02-15 Thread Mws
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

2006-11-16 Thread Mws
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

2006-11-16 Thread Mws
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

2005-08-30 Thread Mws

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

2005-08-30 Thread Mws

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

2005-08-09 Thread Mws
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

2005-08-09 Thread Mws
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?

2005-07-13 Thread Mws
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?

2005-07-13 Thread Mws
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

2005-03-21 Thread Mws
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

2005-03-21 Thread Mws
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

2005-03-21 Thread Mws
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

2005-03-21 Thread Mws
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

2005-03-21 Thread Mws
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

2005-03-21 Thread Mws
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

2005-03-21 Thread Mws
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

2005-03-21 Thread Mws
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

2005-03-21 Thread Mws
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

2005-03-21 Thread Mws
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

2005-03-01 Thread Mws
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

2005-03-01 Thread Mws
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

2005-03-01 Thread Mws
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

2005-03-01 Thread Mws
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

2005-03-01 Thread Mws
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

2005-03-01 Thread Mws
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

2005-02-25 Thread Mws
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

2005-02-25 Thread Mws
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

2005-02-14 Thread Mws
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

2005-02-14 Thread Mws
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

2005-02-10 Thread Mws
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

2005-02-10 Thread Mws
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

2005-01-31 Thread Mws
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

2005-01-31 Thread Mws
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