Re: Strange problem with tty layer

[Lennart Sorensen]

On Fri, Jan 26, 2007 at 09:06:52AM -0600, Paul Fulghum wrote:
> ioctl(TIOCSETD/TIOCGETD) sets/returns an integer identifier
> that can be compared agains the N_XXX macros. If you are
> not explicitly setting this then is is probably the default N_TTY.

Yes it is N_TTY (value 0).  I never set it.

> Also at the application level, look at tcsetattr() for setting
> the termios features. Look specifically at the c_cc[VTIME] and c_cc[VMIN]
> members of the termios structure. These settings control how
> much data must be available before returning data to a read().
> Try VTIME=0 and VMIN=1.
> 
> Since your 'missing' data is always on the tail end, maybe
> VMIN is set to 64 or something.

OK, the tty settings according to stty that I am using are:
# stty -F /dev/ttyn0 -a
speed 230400 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = 
; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff 
-iuclc -ixany -imaxbel
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon iexten -echo -echoe echok -echonl -noflsh -xcase -tostop -echoprt 
echoctl echoke

So min and time seems good.  I am not explicitly setting those in my
test program (unless one of the other settings implies it).  I will add
it explicitly just in case too.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange problem with tty layer

[Lennart Sorensen]

On Fri, Jan 26, 2007 at 08:51:02AM -0600, Paul Fulghum wrote:
> You can eliminate the tty buffering altogether
> by observing what gets passed to the line discipline.

I will have to find where in the code that is happening.

> I assume you are using the default line discipline N_TTY.
> 
> Look at what is passed to drivers/char/n_tty.c:n_tty_receive_buf()
> If all the data gets that far, then there is some issue
> with the line discipline or something further downstream.
> If not, then the problem is with the tty buffering (assuming
> you are correct that all data gets to the tty buffering code
> followed by a tty_flip_buffer_push call).

I am not sure actually.  I just open /dev/ttyn0 and /dev/ttyn1 and write
to one, and read from the other.  I didn't even know about the line
diciplines actually.  How do I tell which one I am using?

I have confirmed that all the data is being passed to
tty_insert_flip_string() in jsm_input().

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange problem with tty layer

[Lennart Sorensen]

On Thu, Jan 25, 2007 at 10:16:39AM -0500, Lennart Sorensen wrote:
> I am now trying this, which so far seem to help (I had a printk in there
> earlier and managed to trigger that).
> 
> --- ori/drivers/char/tty_io.c 2007-01-24 18:02:48.0 -0500
> +++ new/drivers/char/tty_io.c 2007-01-25 09:50:02.0 -0500
> @@ -2774,6 +2778,14 @@
>   spin_lock_irqsave(&tty->buf.lock, flags);
>   while((tbuf = tty->buf.head) != NULL) {
>   while ((count = tbuf->commit - tbuf->read) != 0) {
> + if (!tty->receive_room) {
> + schedule_delayed_work(&tty->buf.work, 1);
> + spin_unlock_irqrestore(&tty->buf.lock, flags);
> + goto out;
> + }
> + if (count > tty->receive_room) {
> + count = tty->receive_room;
> + }
>   char_buf = tbuf->char_buf_ptr + tbuf->read;
>   flag_buf = tbuf->flag_buf_ptr + tbuf->read;
>   tbuf->read += count;
> 
> This appeared to be (essentially) the key change in 2.6.18 related to
> the check of tty->receive_room.
> 
> I will now run a bunch more tests to see if it manages to keep it from
> having any more character losses.
> 
> Thank you for the suggestion of where to look.

Well it turns out that didn't help.  Neither does 2.6.18 (that one was
the easiest newer one to try).  It does seem as if the error rate is
lower with 2.6.18 than with 2.6.16, so perhaps there was more than one
place that could cause losses in the tty buffering.  I had only 2
failures in 15 hours with 2.6.18, rather than a whole lot of failures
with 2.6.16.  I guess I will have to try 2.6.19 or even something newer.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange problem with tty layer

[Lennart Sorensen]

On Wed, Jan 24, 2007 at 03:20:53PM -0600, Paul Fulghum wrote:
> In 2.6.16 the tty buffering pushes data to the line
> discipline without regard to tty->receive_room.
> If the line discipline can't keep up, the data gets dropped.
> I observed this data loss at higher speeds when
> placing the system under heavy load.
> 
> 2.6.18 added code to respect tty->receive_room.
> 
> This may or may not be your problem, but you should
> be able to check by adding a conditional printk
> to drivers/char/tty_io.c:flush_to_ldisc()
> 
> If tty->receive_room is less than the size of the buffer
> passed to disc->receive_buf() then you are losing data.

I am now trying this, which so far seem to help (I had a printk in there
earlier and managed to trigger that).

--- ori/drivers/char/tty_io.c   2007-01-24 18:02:48.0 -0500
+++ new/drivers/char/tty_io.c   2007-01-25 09:50:02.0 -0500
@@ -2774,6 +2778,14 @@
spin_lock_irqsave(&tty->buf.lock, flags);
while((tbuf = tty->buf.head) != NULL) {
while ((count = tbuf->commit - tbuf->read) != 0) {
+   if (!tty->receive_room) {
+   schedule_delayed_work(&tty->buf.work, 1);
+   spin_unlock_irqrestore(&tty->buf.lock, flags);
+   goto out;
+   }
+   if (count > tty->receive_room) {
+   count = tty->receive_room;
+   }
char_buf = tbuf->char_buf_ptr + tbuf->read;
flag_buf = tbuf->flag_buf_ptr + tbuf->read;
tbuf->read += count;

This appeared to be (essentially) the key change in 2.6.18 related to
the check of tty->receive_room.

I will now run a bunch more tests to see if it manages to keep it from
having any more character losses.

Thank you for the suggestion of where to look.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange problem with tty layer

[Lennart Sorensen]

On Wed, Jan 24, 2007 at 03:20:53PM -0600, Paul Fulghum wrote:
> In 2.6.16 the tty buffering pushes data to the line
> discipline without regard to tty->receive_room.
> If the line discipline can't keep up, the data gets dropped.
> I observed this data loss at higher speeds when
> placing the system under heavy load.
> 
> 2.6.18 added code to respect tty->receive_room.
> 
> This may or may not be your problem, but you should
> be able to check by adding a conditional printk
> to drivers/char/tty_io.c:flush_to_ldisc()
> 
> If tty->receive_room is less than the size of the buffer
> passed to disc->receive_buf() then you are losing data.

Sounds plausible.  Certainly higher cpu load makes the problem occour
more often, and making the system slower made it worse too.  I will take
a look at the tty_io.c in 2.6.18 and compare it against 2.6.16.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Strange problem with tty layer

[Lennart Sorensen]

On Wed, Jan 24, 2007 at 03:19:53PM -0600, Kilau, Scott wrote:
> There are a couple interesting things I would do here.
> 
> 1) The tty "flip" buffer stuff was changed in 2.6.16+.
> 
> Maybe you could try going downwards to 2.6.15 or below and see if the
> problem
> still exists.

That looked like a lot of changes to the tty layer.  I think going up
sounds better.  Finding the bug fix and backporting it would be
preferable of course.

> Then try going up to 2.6.19, I believe there were some bugs fixed
> in 2.6.17/18/19, not sure how many of those made it backported into
> 2.6.16.25.

Well I can certainly compare the code between those versions, and I have
a 2.6.18 kernel I could try out too.

> 2) Try using Digi's "Out-Of-Kernel-Source-Tree"/GPL version of the
> driver.
> You can grab the latest and greatest beta version of it from here:
> ftp://ftp1.digi.com/support/beta/linux/dgnc/
> Its in source rpm format, let me know if you need it in a tarball format
> instead.

Yes, I run Debian.  rpm has very little interest.  I can convert it
though.

> You obviously will have to add in your specific PCI id into the driver,
> but that should be a problem.

I did that.

> 3) I seem to recall that someone mentioned that the Exar 17D154 PCI
> chips were
> easily "pushed" into the 8250 driver.
> It might be interesting to try that route as well.

I am using the GPIO lines too, and didn't want to mess with the 8250
driver (since I use that for a serial console on a 16550 UART), plus
being able to use the 64byte fifo rather than 16byte 16550 mode fifo
seems nicer.  I had to take the exar out of the 8250 driver to make it
not take control of it (although now the eeprom has been added to the
board so it no longer appears as a generic exar chip).

Thanks for the suggestions though.  Gives me a few things to try.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Strange problem with tty layer

[Lennart Sorensen]

I am seeing a very strange problem which seems to be in the tty layer.

I am using an exar 17D154 based PCI card (like the digi neo style card)
using the jsm driver.  Kernel version 2.6.16.25.

My test involves connecting two ports together with a cross over cable
and then sending a test pattern of characters.  I am currently using
11520 characters at 230400bps (so 0.5s for the transfer).

Most of the time, it works perfectly, but once in a while, I never
receiver the last few characters (between 1 and 65 or so characters it
seems).

I have confirmed that the driver does in fact receive all the
characters, and that they are correct, and that they are being passed to
the tty layer using tty_insert_flip_string, and that it returns that all
the characters have been passed to the tty layer.  The user space
application however still doesn't see the last few characters (when it
fails).

The problem seems to occour every few hours of testing on a 266MHz Geode
SC1200.  When I change the clock to 133MHz, it happens every few minutes
instead (so much more frequently).  I suspect there is some race
condition that allows the tty layer to not get around to processing all
the data in the buffer, even when asked for data by the application
(which is waiting on the serial port using select, with a 4s timeout).

Any suggestions on where to head next to debug this?

Sending a few more characters when the receive times out before getting
the complete message does not cause the missing data to arive it seems,
only completely closing and starting the test program again seems to
recover it, although I may just not have been patient enough.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20-rc5: known unfixed regressions (v3) (part 2)

[Lennart Sorensen]

On Wed, Jan 24, 2007 at 05:38:01PM +0100, Adrian Bunk wrote:
> Was the removed
>   setCx86(CX86_CCR3, ccr3);
> without any effects?

I didn't think that was ever checked in.  I thought the patch was still
being discussed.

The line missing will not as far as I can see cause any problems, it
will leave some registers accessible that normaly are not, but unless
something was to try and access them that shouldn't matter.  It is of
course more correct to reprotect them after the required changes are
done so it should be put back (if it was ever actually removed).

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.20-rc5: known unfixed regressions (v3) (part 2)

[Lennart Sorensen]

On Wed, Jan 24, 2007 at 04:47:25PM +0100, Adrian Bunk wrote:
> Subject: fix geode_configure()
> References : http://lkml.org/lkml/2007/1/9/216
> Submitter  : Lennart Sorensen <[EMAIL PROTECTED]>
> Caused-By  : takada <[EMAIL PROTECTED]>
>  commit e4f0ae0ea63caceff37a13f281a72652b7ea71ba
> Handled-By : takada <[EMAIL PROTECTED]>
>  Lennart Sorensen <[EMAIL PROTECTED]>
> Status : patches are being discussed

I wouldn't call this a regression.  It appears to go way back.  I also
didn't find it, I just commented on it since it does affect the platform
I work on.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Lennart Sorensen]

On Mon, Jan 22, 2007 at 06:36:19PM +, Alan wrote:
> K is Kelvin, k is kilo-

K is a unit is Kelvin, k/K as a prefix is kilo.

> See ISO 31. There is a standard for this stuff which is used worldwide
> and only bits of the computing industry appear incapable of following it.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Lennart Sorensen]

On Mon, Jan 22, 2007 at 05:58:42PM +0100, Jan Engelhardt wrote:
> For "F"s sake, when you gotta use abbreviations, then just use k=1000 and
> K=1024 already, b for bits and B for bytes. Problem gone.

And for 10^6 vs 2^20?

> kegs perhaps? :)

Hmm, Mega -> Megs, Kilo -> Kils?

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Lennart Sorensen]

On Sun, Jan 21, 2007 at 12:10:00PM +0100, Eduard Bloch wrote:
> And I cannot seriosly believe that you are cappable of reading his
> examples. Megabananas are a ridiculous demonstration becase of the
> object beeing counted itself, but if you take stuff from real life then
> I doubt that you expect a kilometer to be 1024 meters. Same for
> kilogram. And a megatone is not 1048576 tones, even not 104857600 kg,
> and not 107374182400 grams. Wanna more stupid examples created by
> abusing decimal units?

The computer world has a long history of borrowing and abusing terms.
Probably the majority of computer terms came to be that way.  Why should
we change any of them now?  Should we stop calling it booting because
some people might be confused and think it means kicking the computer?
Should we rename threads because people might think it has something to
do with sewing stuff together?

> You talk for everybody, or is it just your (and only your) mind refusing
> to accept new terms? For my taste, kib and mib are even easier to
> speech, easier than {KiLoBytE} resp. {MeGaBytE} or KaaaBe / eMmmBe.

There is too much legacy code and systems around for it to ever be
nonambiguous.  It is too late to fix it, and the units that this
"standard" came up with just sound too stupid to be taken seriously.

You also don't pronounce units just because it looks like you can.  So
KiB is not easier than KB.  Heck most people in speach wouild just call
them Ks (kays or something like that).  And MBs just become Megs.  Same
for Gigs.

Whoever wasted their time coming up with this standard, well they simply
wasted their time.  It will NEVER catch on, and it will never replace
the common usage.  It's about 50 or 60 years to late for that.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: KB->KiB, MB -> MiB, ... (IEC 60027-2)

[Lennart Sorensen]

On Sun, Jan 21, 2007 at 10:12:55PM +0100, Jan Engelhardt wrote:
> Same lie like with harddrives. It's around 80, not 100.
> But it depends on how you look at it. 80 for Layer3, possibly
> a little more for Layer2/1.

Strange, I tend to get about 95 for layer 3.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fix typo in geode_configre()@cyrix.c

[Lennart Sorensen]

On Wed, Jan 17, 2007 at 01:38:35AM +0900, takada wrote:
> You are right. I agree to your comment. These variables are needless.
> I made a patch again.
> 
> diff -Narup linux-2.6.19.orig/arch/i386/kernel/cpu/cyrix.c 
> linux-2.6.19/arch/i386/kernel/cpu/cyrix.c
> --- linux-2.6.19.orig/arch/i386/kernel/cpu/cyrix.c2006-11-30 
> 06:57:37.0 +0900
> +++ linux-2.6.19/arch/i386/kernel/cpu/cyrix.c 2007-01-16 19:55:05.0 
> +0900
> @@ -161,19 +161,15 @@ static void __cpuinit set_cx86_inc(void)
>  static void __cpuinit geode_configure(void)
>  {
>   unsigned long flags;
> - u8 ccr3, ccr4;
>   local_irq_save(flags);
>  
>   /* Suspend on halt power saving and enable #SUSP pin */
>   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
>  
> - ccr3 = getCx86(CX86_CCR3);
> - setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);   /* Enable */
> + setCx86(CX86_CCR3, (getCx86(CX86_CCR3) & 0x0f) | 0x10); /* Enable */
>   
> - ccr4 = getCx86(CX86_CCR4);
> - ccr4 |= 0x38;   /* FPU fast, DTE cache, Mem bypass */
> - 
> - setCx86(CX86_CCR3, ccr3);
> + /* FPU fast, DTE cache, Mem bypass */
> + setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x30);

Actually is it possible that the original intent was:

ccr3 = getCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);   /* Enable */ /* enable advanced 
register access?  */

ccr4 = getCx86(CX86_CCR4);
ccr4 |= 0x38;   /* FPU fast, DTE cache, Mem bypass */
setCx86(CX86_CCR4, ccr4);

setCx86(CX86_CCR3, ccr3); /* restore ccr3 register */

Seems something similar with ccr3 was taking place elsewhere in the
function.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fix typo in geode_configre()@cyrix.c

[Lennart Sorensen]

On Wed, Jan 17, 2007 at 01:38:35AM +0900, takada wrote:
> You are right. I agree to your comment. These variables are needless.
> I made a patch again.

Of course there are also lots of "magic numbers" around, but I must
admit I don't personally really feel like going through the data sheet
and naming all of them.

> diff -Narup linux-2.6.19.orig/arch/i386/kernel/cpu/cyrix.c 
> linux-2.6.19/arch/i386/kernel/cpu/cyrix.c
> --- linux-2.6.19.orig/arch/i386/kernel/cpu/cyrix.c2006-11-30 
> 06:57:37.0 +0900
> +++ linux-2.6.19/arch/i386/kernel/cpu/cyrix.c 2007-01-16 19:55:05.0 
> +0900
> @@ -161,19 +161,15 @@ static void __cpuinit set_cx86_inc(void)
>  static void __cpuinit geode_configure(void)
>  {
>   unsigned long flags;
> - u8 ccr3, ccr4;
>   local_irq_save(flags);
>  
>   /* Suspend on halt power saving and enable #SUSP pin */
>   setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
>  
> - ccr3 = getCx86(CX86_CCR3);
> - setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);   /* Enable */
> + setCx86(CX86_CCR3, (getCx86(CX86_CCR3) & 0x0f) | 0x10); /* Enable */
>   
> - ccr4 = getCx86(CX86_CCR4);
> - ccr4 |= 0x38;   /* FPU fast, DTE cache, Mem bypass */
> - 
> - setCx86(CX86_CCR3, ccr3);
> + /* FPU fast, DTE cache, Mem bypass */
> + setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x30);

Why did that change from 0x38 to 0x30?

>   set_cx86_memwb();
>   set_cx86_reorder(); 
> @@ -415,15 +411,14 @@ static void __cpuinit cyrix_identify(str
>   
>   if (dir0 == 5 || dir0 == 3)
>   {
> - unsigned char ccr3, ccr4;
> + unsigned char ccr3;
>   unsigned long flags;
>   printk(KERN_INFO "Enabling CPUID on Cyrix 
> processor.\n");
>   local_irq_save(flags);
>   ccr3 = getCx86(CX86_CCR3);
> - setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10); /* enable 
> MAPEN  */
> - ccr4 = getCx86(CX86_CCR4);
> - setCx86(CX86_CCR4, ccr4 | 0x80);  /* enable 
> cpuid  */
> - setCx86(CX86_CCR3, ccr3); /* disable 
> MAPEN */
> + setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);  /* 
> enable MAPEN  */
> + setCx86(CX86_CCR4, getCx86(CX86_CCR4) | 0x80); /* 
> enable cpuid  */
> + setCx86(CX86_CCR3, ccr3);  /* 
> disable MAPEN */
>   local_irq_restore(flags);
>   }
>   }

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Choosing a HyperThreading/SMP/MultiCore kernel ?

[Lennart Sorensen]

On Fri, Jan 12, 2007 at 10:38:43PM -0500, [EMAIL PROTECTED] wrote:
> amd64 will only work on a core2duo if it's a T7200 or higher - the
> lower numbers are 32-bit-only chipsets.  I admit not knowing what
> exact variant the Mac has.

The Core Duo had 32bit only (being a Pentium M), but the Core 2 Duo
should always be 64bit capable (at least that is what this list says:
http://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors#Core_2_Duo_2
)

> CONFIG_MCORE2=y

Oh good.  Makes life much simpler for users.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Choosing a HyperThreading/SMP/MultiCore kernel ?

[Lennart Sorensen]

On Fri, Jan 12, 2007 at 06:55:32PM +0530, Sunil Naidu wrote:
> There are 2 cases:-
> 
> #1 Intel Pentium 4 Workstation with HyperThreading
> 
> Since kernel takes HT as 2 processors, I did say in KConfig as:
> 
> CONFIG_SMP= y
> CONFIG_NR_CPUS=2
> CONFIG_SCHED_MC=not set
> CONFIG_MPENTIUM4=y (Or should I say CONFIG_X86_PC=y)
> CONFIG_SCHED_SMT=y
> CONFIG_SCHED_MC=not set
> RESOURCES_64BIT=not set
> HOTPLUG_CPU=not set
> 
> 
> Pl correct me if am wrong.
> 
> 
> #2 Intel Core2Duo Processor - Laptop
> 
> CONFIG_SMP= y
> CONFIG_NR_CPUS=4 ??
> CONFIG_SCHED_MC=y
> CONFIG_X86_PC=y ?  (if wrong, what should I set for Xeon QuadCore)
> CONFIG_SCHED_SMT=not set
> CONFIG_SCHED_MC=y
> RESOURCES_64BIT=not set
> HOTPLUG_CPU=not set
> 
> I didn't start this yet (still with Mac, will install in weekend), is
> this correct one?
> 
> [OT] I don't know if I can ask about a suggested distro here or not?
> Anyway, me read that Fedore & Yellow Dog suits well for this?

I would expect any distribution should work on these (as long as the
kernel they use isn't too old.).  Of course if it is a Mac, you need a
distribution that supports their firmware (which is of course not a PC
bios).  As long as you can boot it, any i386 or amd64 kernel with smp
enabled should use all the processors present (well amd64 on the
core2duo and on the p4 if it is em64t enabled).

I believe the closest optimization for a Core2 is probably the Pentium M
(certainly not the P4/netburst).  Not entirely sure though.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Lennart Sorensen]

On Wed, Jan 10, 2007 at 06:56:05PM +0100, Prakash Punnoor wrote:
> Intel wants you to buy hw with ICH8R. ICH8 isn't get the advanced features 
> for 
> free

But the BIOS has AHCI mode as an option.  I don't want their fake raid,
just ahci.  That isn't an advanced feature, it is native mode. :)

> To get the driver going: Put your hd to the jmicron, install driver, put hd 
> back to ich8...

Hmm, could try that, assuming the jmicron controller doesn't mind.  Of
course the jmicron can also be set to ahci mode (not that I have an ahci
driver for it either under windows).

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Lennart Sorensen]

On Wed, Jan 10, 2007 at 10:25:52AM -0700, Jeff V. Merkey wrote:
> No doubt part of the Wintel (intel + Microsoft) strategy to perpetually 
> break non-windows platforms with new incompatible
> hardware like the switch over from the e1000 MT adapters to e1000 GT 
> which are not backward compatible with the older chipsets.
> 
> I still have not seen the GT adapter work correctly off windows.

But isn't AHCI a new standard intel helped develop?  Why would they want
to make it hard to use intel hardware using a standard interface intel
helped create?  It makes no sense.  Linux doesn't care if the sata is
set to the old PATA compatible interface, or the new AHCI mode.  Windows
simply can't boot in AHCI mode and refuses to install a driver for
AHCI mode when it is not already in AHCI mode.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Lennart Sorensen]

On Wed, Jan 10, 2007 at 06:29:28PM +0100, Prakash Punnoor wrote:
> You can install the Intel Matrix driver after "adjusting" the inf file...

Hmm, I guess a good question is: Why should I have to edit the inf file?
Is it an issue of them making it only install if your hardware is
already set to ahci mode?  But how am I supposed to boot and install the
driver until I have the driver installed then.  Well I might try that
next time I go there.  How stupid of intel.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Lennart Sorensen]

On Wed, Jan 10, 2007 at 09:58:21AM -0500, Jeff Garzik wrote:
> Enhanced mode means separate SATA and PATA.
> 
> (I recommend avoiding the "IDE" acronym, it is largely meaningless and 
> confusing these days)

Good idea.

> We're talking about Linux here.  Linux regularly supports hardware 
> before Windows does.  This is nothing new.

That is certainly true.  I just found it odd that intel wouldn't have an
ahci driver available.  But then again if ahci is standard I guess they
would expect microsoft to provide the driver instead, which they
probably aren't doing until vista.  Linux always seems so much easier.
:)  The drivers are just included for everything.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Lennart Sorensen]

On Tue, Jan 09, 2007 at 07:25:00PM -0500, Jeff Garzik wrote:
> Combined mode is a technical term.  Judging from your answers, you are 
> not using combined mode.

I would have thought 'sata 3.0 + IDE' sounded a lot like combined mode,
unless it means seperate sata and ide.

> Judging from your answers, you are not in AHCI mode.
> 
> Side note:  You should use AHCI if available.  Emulating a PATA 
> interface for SATA devices is error prone [in the silicon].  AHCI is 
> native SATA, "enhanced mode" is not.

I tried setting my sister's new machine to AHCI mode (Asus P5B with 965
chipset), but I eventually gave up since it also needed windows xp on it
and I can't for the life of me find an AHCI driver for windows that
would install.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Gaming Interface

[Lennart Sorensen]

On Tue, Jan 09, 2007 at 06:02:20PM -0500, [EMAIL PROTECTED] wrote:
> When it's installed on 95% of the computers, it's a de-facto standard. 

And "de facto" does not make it a real one.  opengl is installed on more
machines that directx.  If installation numbers is what decides it, then
opengl will beat directx easily and obviously means opengl should be the
de facto standard everyone uses.  I think what you meant is that windows
which has both opengl and directx is by far the most common
installation, and microsoft says to use directx rather than opengl on
their systems even though it has both and both work, and ID software
thinks microsoft's direct3d isn't as good as opengl, but that apparently
doesn't actually matter either.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATA/IDE Dual Mode w/Intel 945 Chipset or HOW TO LIQUIFY a flash IDE chip under 2.6.18

[Lennart Sorensen]

On Tue, Jan 09, 2007 at 01:46:42PM -0700, Jeff V. Merkey wrote:
> I just finished pulling out a melted IDE flash drive out of a Shuttle 
> motherboard with the intel 945 chipset which claims to support
> SATA and IDE drives concurrently under Linux 2.6.18.
> 
> The chip worked for about 30 seconds before liquifying in the chassis.  
> I note that the 945 chipset in the shuttle PC had some serious
> issues recognizing 2 x SATA devices and a IDE device concurrently.   Are 
> there known problems with the Linux drivers
> with these newer chipsets.

Had the drive ever been used in any other machine?  Had any ide device
ever been used in this machine before?  It really sounds like a hardware
problem, since I can't think of anything software could do to make that
kind of current go through the flash drive.

I remember seeing the controller chip on a 730MB quantum scsi drive
start to glow red many years ago, just before the drive stopped
responding to the system (and I turned off the power).  Hardware does
fail.  It almost never has anything to do with software.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fix typo in geode_configre()@cyrix.c

[Lennart Sorensen]

On Tue, Jan 09, 2007 at 06:41:56PM +0900, takada wrote:
> In kernel 2.6, write back wrong register when configure Geode processor.
> Instead of storing to CCR4, it stores to CCR3.
> 
> --- linux-2.6.19/arch/i386/kernel/cpu/cyrix.c.orig2007-01-09 
> 16:45:21.0 +0900
> +++ linux-2.6.19/arch/i386/kernel/cpu/cyrix.c 2007-01-09 17:10:13.0 
> +0900
> @@ -173,7 +173,7 @@ static void __cpuinit geode_configure(vo
>   ccr4 = getCx86(CX86_CCR4);
>   ccr4 |= 0x38;   /* FPU fast, DTE cache, Mem bypass */
>   
> - setCx86(CX86_CCR3, ccr3);
> + setCx86(CX86_CCR4, ccr4);
>   
>   set_cx86_memwb();
>   set_cx86_reorder(); 
> -

One more comment on this:

Why is this function using 3 different styles to do the same thing to 3
different registers?

First it does CCR2 by doing:
setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);

Nice, no temp values, and it is obvious this is a permanent change.

Then for the next one it does:
ccr3 = GetCx86(CX86_CCR3);
setCx86(CX86_CCR3, (ccr3 & 0x0f) | 0x10);

Couldn't that have been:
setCx86(CX86_CCR3, (getCx86(CX86_CCR3) & 0x0f) | 0x10);

No temp variable, and again it clearly does not intend to restore the
value again later (even though the bug actually did cause the value to
be restored by accident).

Then the last case does:
ccr4 = GetCx86(CX86_CCR4);
ccr4 |= 0x38;
setCx86(CX86_CCR4, ccr4); (after fixing the typo you found of course).

Why did this one have to modify the variable first before using it?
Maybe the ccr3 and ccr4 cases would have made the line too long and
needed wrapping, but at least those two cases should be done the same
way.  It makes it look like it was written by 3 different people who
didn't look at the lines around the changes they were making.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Gaming Interface

[Lennart Sorensen]

On Tue, Jan 09, 2007 at 04:16:51PM +1000, Trent Waddington wrote:
> We're totally off topic now, but what the hell.. You wanna encourage
> ports?  Write a step by step guide on how to most easily port a modern
> game from Windows to Linux.  My suggestion would be to use winelib and
> include all the workarounds needed to make the game compatible with
> the DirectX support in wine.

Why not start by suggesting using standard api's instead when writing
the original game engine.  That would make porting it easier later.
DirectX is not a standard api.

> As far as I'm aware, there is no such guide, so if a games company was
> to decide to port their game to Linux (for whatever whacky reason)
> they wouldn't even know how much work they have ahead of them.

Well Bioware managed to port neverwinters nights using SDL without that
much dificulty by the looks of it, although it already had opengl in
use.  I believe that is how they did the mac port too.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Gaming Interface

[Lennart Sorensen]

On Tue, Jan 09, 2007 at 08:14:13AM +0100, Dirk wrote:
> I tried to get WoW installed with Cedega 5.2.9 for two days now.
> 
> Cedega is not a replacement for ports. And it does not encourage ports.
> 

It seems more like an excuse offered to game companies for not writing
ports.  And then there are the license issues and fights that seems to
have taken place between wine and cedega. :)

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Gaming Interface

[Lennart Sorensen]

On Tue, Jan 09, 2007 at 08:22:20AM +0100, Dirk wrote:
> If there is no problem with Linux gaming I should shut the hell up and 
> start buying all these Linux games I keep hearing about and seeing in 
> those TV commercials.

There is no problem with linux gaming.  There is a problem with game
development companies and their marketing decisions.  Unless you somehow
make linux have 100% compatible directx and able to natively execute
windows code, the game companies aren't going to give a @#$#.  They have
a limited budget and for them it is more important to aim for 99% of the
market than 100% of the market if it means saving 20 or 30% in
development costs.  Even if it saves 5% in development cost, it makes
sense financially.

Some companies of course realize that the installation base does not
always equal the gamer installation base and write portable code in the
first place using abstraction layers where needed, and stick to opengl
and such.  This is why quake, and other titles from ID are ported to
linux and mac and such.  Some companies believe the hype from microsoft
about directx and write for that instead, which makes the games not
portable to mac or linux or anything else.

The problem is not that linux doesn't have any decent stable api for
games.  The problem is that it isn't directx which is what a lot of
companies believe they want to use.

I play neverwinters nights on my linux system.  I have never seen it on
windows.  Linux uses opengl, while I have no idea if the windows version
is opengl or directx or maybe lets you pick (some games offer a choice
of rendering engine).  I do know the game runs great for the most part
even though my hardware is below the minimum specs if I was running on
windows (at least according to the box for the game).

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fix typo in geode_configre()@cyrix.c

[Lennart Sorensen]

On Tue, Jan 09, 2007 at 06:41:56PM +0900, takada wrote:
> In kernel 2.6, write back wrong register when configure Geode processor.
> Instead of storing to CCR4, it stores to CCR3.
> 
> --- linux-2.6.19/arch/i386/kernel/cpu/cyrix.c.orig2007-01-09 
> 16:45:21.0 +0900
> +++ linux-2.6.19/arch/i386/kernel/cpu/cyrix.c 2007-01-09 17:10:13.0 
> +0900
> @@ -173,7 +173,7 @@ static void __cpuinit geode_configure(vo
>   ccr4 = getCx86(CX86_CCR4);
>   ccr4 |= 0x38;   /* FPU fast, DTE cache, Mem bypass */
>   
> - setCx86(CX86_CCR3, ccr3);
> + setCx86(CX86_CCR4, ccr4);
>   
>   set_cx86_memwb();
>   set_cx86_reorder(); 

Any idea what the consequence of this would be?  Any chance that while
fixing this file anyhow, adding a missing variant could be done?

The patch I currently run with is this (To cyrix.c):
@@ -257,6 +257,8 @@
break;

case 4: /* MediaGX/GXm or Geode GXM/GXLV/GX1 */
+   case 11: /* SC1200 seems to return 11 or something but it is a geode 
gx1 too as far as I know */
+   dir0_msn = 4;
 #ifdef CONFIG_PCI
/* It isn't really a PCI quirk directly, but the cure is the
   same. The MediaGX has deep magic SMM stuff that handles the

After the patch I get this:

# cat /proc/cpuinfo
processor   : 0
vendor_id   : CyrixInstead
cpu family  : 5
model   : 9
model name  : Geode(TM) Integrated Processor by National Semi
stepping: 1
cpu MHz : 266.759
cache size  : 16 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu tsc msr cx8 cmov mmx cxmmx
bogomips: 535.09

Before that the cpu type was unknown, the cache size wasn't there,
and a number of fixups were not being applied as far as I could tell.

I know I have had to fix the jsm serial driver which uses memcpy_toio,
and I got characters out of order on transmit on the geode, while on a
pentium 4 or athlon it works perfectly fine with the same card and driver.

My workaround (which of course isn't good for efficiency) has been:
-   memcpy_toio(&ch->ch_neo_uart->txrxburst, ch->ch_wqueue + tail, 
s);
+   for(i=0;ich_neo_uart->txrxburst[i]), 
ch->ch_wqueue + tail + i, 1);
+   }
+   /*memcpy_toio(&ch->ch_neo_uart->txrxburst, ch->ch_wqueue + 
tail, s);*/

Could the wrong register being saved have anything to do with that?

Without my fix a burst transfer of the data 0123456789ABCDEF results in
the other end receiving: 123056749AB8DEFC

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: wireless Q

[Lennart Sorensen]

On Thu, Jan 04, 2007 at 09:48:36PM -0500, Gene Heskett wrote:
> Possibly in the future John.  I took the Belkin back and got a Netgear 
> WG311T for another $35.  Staples let me open it there and based on the 
> fact that the cd has some drivers on it that start with ATHE_* (the 
> chipset has a tincover soldered to the board over it so we can't ID it 
> that way), I'm assuming its an Atheros chipset, and Brian does has that 
> support available in DD-WRT, which is where this puppy will live.  But 
> I'm up to my butt in alligators ATM, so it may be a day or 3 till I can 
> try it.  I have a 160GB drive laying on the lappies carry case in the 
> doorway, to go up and be installed in the neighbors box to replace a 30GB 
> that upchucked all over their windows install, and convince it to let me 
> install windows on that box the 2nd time.  M$ are such rectums over that.  
> Its piracy you know. :(

Atheros makes a lot of different chipsets.  Not all are supported.  Many
newer ones require annoying firmware loaded into an arm processor on the
card.  Hopefully you found one that does have a working driver.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Binary Drivers

[Lennart Sorensen]

On Fri, Dec 15, 2006 at 09:59:43PM +, Alan wrote:
> 3DFx invented SLI many years ago. The SLI programming information for the
> 3DFx cards is public. Nvidia are a bit late to the party except on the PR
> front.

Well they do work differently.  3Dfx just did alternate line rendering,
while nvidia does a lot more methods of dividing the work load (many of
which are likely to be more efficient than alternate line rendering in
general).  No doubt why they picked the name SLI though.  They did also
buy out 3Dfx so I guess by that they can claim to have "invented" it. :)

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: data corruption with nvidia chipsets and IDE/SATA drives // memory hole mapping related bug?!

[Lennart Sorensen]

On Wed, Dec 13, 2006 at 08:57:23PM +0100, Christoph Anton Mitterer wrote:
> Don't understand me wrong,.. I don't use Windows (expect for upgrading
> my Plextor firmware and EAC ;) )... but I ask because the more
> information we get (even if it's not Linux specific) the more steps we
> can take ;)

I upgrade my plextor firmware using linux.  pxupdate for most devices,
and pxfw for new drivers (like the PX760).  Works perfectly for me.  It
is one of the reasons I buy plextors.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 64-bit app on 32-bit kernel supported?

[Lennart Sorensen]

On Fri, Dec 08, 2006 at 09:06:06PM +0530, Srivatsa Vaddagiri wrote:
> Somebody was asking this : "Does any 32-bit Linux kernel support running 
> 64-bit 
> app on top of it (in a 64-bit platform that is)?"
> 
> AFAIK its not supported, but wanted to make sure ..

You can run 32bit programs on many 64bit kernels, but a 32bit kernel
only runs 32bit code, since the code can't use 64bit features if the
kernel doesn't know about them and know how to context switch without
loosing the 64bit extensions.  As far as I know this is true of at least
x86, hppa (not sure 64bit is supported in linux since I never worked with
one), mips and sparc.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to go about debuging a system lockup?

[Lennart Sorensen]

On Fri, Nov 17, 2006 at 09:29:28AM -0500, Lennart Sorensen wrote:
> Wow, that looks really neat.  I will have to go read up on that tool.

OK, I have now tried connecting with firescope to just follow the dmesg
buffer across firewire.  Works great, until the system hangs, then
firescope reports that it couldn't perform the read.  I wonder what part
of the system has to lock up for the firewire card to no longer be able
to read memory on the system.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to go about debuging a system lockup?

[Lennart Sorensen]

On Fri, Nov 17, 2006 at 02:43:36PM +0100, Stefan Richter wrote:
> If the PCI bus itself isn't brought down, you could debug from remote
> using Benjamin Herrenschmidt's Firescope on the remote node and a
> FireWire card in the test machine. Once the ohci1394 driver was loaded,
> the FireWire controller is able to read and write to the 32bit PCI
> address range (and thus to system memory) without assistance of
> interrupt handlers.

Wow, that looks really neat.  I will have to go read up on that tool.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to go about debuging a system lockup?

[Lennart Sorensen]

On Thu, Nov 16, 2006 at 04:01:03PM -0600, Protasevich, Natalie wrote:
> If you can't drop in kdb, or no sysreq, then your interrupts are
> disabled. I used to be (with older systems anyway) that NMI button was
> on the system, so one could send an NMI and make the handler to print a
> trace. Newer systems might not have that, so you can built your own PCI
> card to send an NMI :)

I still haven't found a place to send an NMI on the Geode SC1200.  I
really want one for exactly that reason.  I have been suspecting that it
gets stuck somewhere with interrupts disabled, but I can't make sense of
where that could be.  They mention something about the NMI being
implemented by SMM in their VSA.  I don't like their virtual hardware
part very much.

> Another possibility is to use port 80 and make suspicious code print
> something to it. Once we used a small self-built thing with LEDs to
> catch the output to the parallel port while debugging silent boot
> failure. There are some port 80 cards that you can buy:
> http://auctions.yahoo.com/i:Port%2080%20Card%20and%20power%20supply%20te
> ster:102201489
> http://www.amazon.com/gp/product/B000234U3I/ref=pd_cp_e_title/103-887558
> 8-5330221

Hmm, one of those on the PCI bus might work.  Or perhaps the parallel
port will.  Of course if the problem is that somehow the PCI bus is
locked up, then I won't get a message anywhere since all the busses are
connected via PCI it seems.  I don't know if a PCI bus can lock up, but
for now I was assuming anything was possible.

> If your system has a jtag then in target probe would be useful if you
> have one (or can borrow one, those are expensive).

I have asked the system on a board maker if it has jtag anywhere.  Still
waiting on the answer to that.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How to go about debuging a system lockup?

[Lennart Sorensen]

On Thu, Nov 16, 2006 at 09:49:06PM +0100, Jesper Juhl wrote:
> Well, I have a few ideas that are hopefully useul.
> 
> - If you have not done so already, then go in to the "Kernel Hacking"
> section of the kernel configuration and enable some (all?) of the
> debug options and see if that produces anything that will help you
> track down the problem.

I enabled the things that sounded useful.  I will try enabling the rest.

> - You could enable 'magic sysrq' and see if you can manage to get a
> backtrace with it when it hangs (see Documentation/sysrq.txt) (ohh and
> raise the console log level so you get all messages, including debug
> ones).

Yeah I did that.  No response to sysrq (at least not on the serial
console.  Maybe I should get a keyboard connector put on.)  Normally we
run without VGA/keyboard/etc, and just serial console.  Of course the
serial console requires working interrupts.  Not sure about the keyboard
driver.

> - You could also try kdb (http://oss.sgi.com/projects/kdb/) or kgdb
> (http://kgdb.linsyssoft.com/). That might help you pinpoint the
> failure.

Can I run that remotely somehow?  I never really looked at kdb or kgdb
before.

> See also : http://kerneltrap.org/node/112
> 
> - If you have (or can identify) an older, working, kernel version and
> you are confident that you can reproduce the problem reliably, then
> doing a git bisection search starting with your newest "known good"
> and oldest "known bad" kernel versions, should help you pinpoint the
> commit causing the breakage.

I don't know of a good version yet.  I so far don't know if there ever
was one.  This could even be a bug in the PCI hardware, or the way the
BIOS on this system on a board configured the PCI controller.  Maybe I
should go back and try a 2.4 kernel.

> Hope some of that helps :)

Well hopefully.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: When is the kernel moving to GPLv3? (probably feeding a troll :)

[Lennart Sorensen]

On Thu, Nov 16, 2006 at 09:56:44AM -0700, Jeffrey V. Merkey wrote:
> /"Red Hat has slammed the door shut 
>  on any possibility 
> of entering into a patent protection deal similar to the one Microsoft 
> recently announced with Novell, eWeek is reporting. While Microsoft has 
> repeatedly said it wants to work with Red Hat and would like to 
> structure a relationship where its customers can be assured of the same 
> thing as Novell's customers 
>  now 
> are, Mark Webbink, Red Hat's deputy general counsel, says 'we do not 
> believe there is a need for or basis for the type of relationship 
> defined in the Microsoft-Novell announcement.' Interestingly enough, 
> Microsoft also says that it has not ruled out going it alone and 
> providing some sort of indemnification for its customers who also use 
> Red Hat Linux."/
> 
> "Meanwhile, Eben Moglen, the FSF general counsel, promises that GPLv3 
> will explicitly outlaw 
> 
>  
> deals like this. (Of course everyone's on v2, so calling the Novell deal 
> "DOA" would be premature.)"
> 
> So when is the kernel moving to GPLv3?   I have seen some discussions 
> about moving off v2, is there concensus about moving to v3 to remove
> threats of patent claims against v2 code by M$ and others who may use 
> Linux in hardware based projects.

The "consensus" seems to be: The kernel is currently GPLv2 (and nothing
else) and changing that is almost an imposible task, and the majority of
the major active contributers also don't seem interested in considering
the GPLv3 in its current form.  It really seems to be that simple.

Some people claim Novell's "Deal" isn't even permitted under the GPLv2,
or that the "Deal" has no meaning or purpose at all.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

How to go about debuging a system lockup?

[Lennart Sorensen]

We have a router with a Geode SC1200 cpu, with 4 AMD 972 ethernet ports
(pcnet32) behind a PLX 6152 PCI-PCI bridge, which quite regularly locks
up completely if we try to do simultanius traffic on all 4 ports (our
test case sends data from port 1 to port 2, and back and from port 3 to
port 4 and back at a rate of 8000 packets per second using 1500byte
packets).  We usually manage to run the test for about 1 minute before
the system hangs.  This happens on every one of the systems we have
tried so far.  If we only run 2 ports, it seems to never die, and with 3
ports we haven't seen any failures yet, although maybe we just haven't
tested long enough.  If we just receive the packets but don't forward
them out again, then we never crash, so it seems to be related to
simultanious transmit on the pcnet32s.

So far I have tried printing a message everytime the pcnet32 driver
enables and disables interrupts to find out if it hangs somewhere with
interrupts disabled, but that didn't seem to indicate anything
meaningful.

So far I have tried this with 2.6.8, 2.6.16.22, and 2.6.18.2 and no
difference so far.  I can't think of what kind of even could cause the
system to just hang with no further console output or a kernel panic or
oops or anything.  Usually most errors produce some kind of message.

Does anyone have any suggestions for where I go from here to find out
what is happening and where to look?  I don't even know if I should
suspect the hardware or the software at this point.  I want to know if
the program counter is still changing, or if the cpu is simply hung or
something, but I have no idea how to get at that.

--
Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Brand-new notebook useless with Linux...

[Lennart Sorensen]

On Thu, Sep 08, 2005 at 03:19:32PM -0400, Chuck Ebbert wrote:
>  What fun is that?  I have learned that HP/Compaq is hostile to Linux,
> for one thing, which was interesting (my system is a Compaq Presario
> V2312US.)

Well they may be hostile but so far no problems with a compaq r3240.
Well the silly TI media card reader is useless, but it's useless in
windows too (who limits cards to 512M these days?).

>  Can you help me find out why my codec is unknown?  I gave up trying to
> figure out how to get the codec ID and hacked the source to print it:
> 
> atiixp: codec 0 not available for modem
> atiixp: no codec available
> ALSA device list:
>   #0 ATI IXP rev 2 with 0x43585430 at 0xd0003400, irq 177
> 
> So it's a Conexant codec with ID 0x30 on an atiixp.  OSS has some support
> for this codec, apparently.

I know I am not going near ati hardware any time soon.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Surround via SPDIF with ALSA/emu10k1?

[Lennart Sorensen]

On Sat, Aug 27, 2005 at 05:47:08PM -0400, Lee Revell wrote:
> For the best S/N ratio and dynamic range all mixer controls SHOULD be at
> 100%, assuming the volume control in your driver only attenuates
> signals.  This is the case for the emu10k1 which implements all mixer
> controls via DSP programs that run on the soundcard anyway, and handles
> overflow itself.

Well I don't want them all at 100% since I do want to be able to have
even levels between the cd, midi and wave, which isn't always the case
at 100%.  They sure sounded worse.

I certainly know some simpler sound cards would have more distrosion
when you ran the amplifiers on the card at 100%.

> Think about it, if you lower the mixer controls to 75%, you're not
> getting the full 16 bits of dynamic range, it's probably more like 14 or
> 15.  16 bits is barely enough headroom anyway, so you really don't want
> this.

Bit 16 is used as soon as the signal passes 50%.  After all it is
required when the signal goes past 32767 and is on all the way to 65535.

So at 75% depending on how things are done internally I will be either
using the full range just not amplified to the same amount, or if truly
done entirely digitally, then I will be using 75% of the range, which is
still more than even 15bit could handle (since 15 bit has half the range
of 16bit).

> Anyway the problem here is a bug in the emu10k1 driver, see alsa-devel
> for the resolution.

Well that probably helps.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Surround via SPDIF with ALSA/emu10k1?

[Lennart Sorensen]

On Sat, Aug 27, 2005 at 08:18:59PM +0200, Thomas Zehetbauer wrote:
> I have now been told that SPDIF cannot support more than 2 channels
> except with AC3 compression. Given the fact that we can send 580MBit/s
> over USB2.0 I would not have even remotely considered this to be the
> problem and find it an incredible shame that audio industry is using
> such a crippled standard.
> 
> I have now solved my problem by buying and connecting an analog 5.1
> speaker set. Unfortunately I get audible distortions when I turn both
> the "PCM" and "Wave" mixers to the maximum setting. I wonder if anyone
> can provide more insight what these controls really do and whether it's
> better to turn down "PCM", "Wave" or both.

I thought the limitation on SPDIF was normally that most decoders only
support 2 channels of PCM, except for a few multimedia speaker systems
which support 3 pairs of PCM streams at the same time to support digital
out on some sound cards.

Most digital decoders do support AC3 of course and sometimes also DTS
both of which of course support encoding more than 2 channels.

So really I think it is just a problem of what standards the receivers of
the digital data know what to do with.

As for volume settings, I always try to keep the sound card mixers at
around 75 to 80% since it seems most amplifiers and mixer do distort a
bit when you max them out.  Why would you want them all at 100% anyhow,
then you might as well not have mixing control for the seperate audio
channels at all.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The Linux FAT issue on SD Cards.. maintainer support please

[Lennart Sorensen]

On Wed, Aug 24, 2005 at 06:48:20PM +0530, Mukund JB. wrote:
> My controller itself alone handle FOUR device at a time (u mea these
> should be (tfa, b , c d)
> But how do I represent if I have more than one such controller i.e. it
> is more 4 devices each with more parttions again.

Well the scsi and ide way is that the next controller continues with tfe
f g h, and the next controller has tfi j k and l, etc.  Doesn't mean you
should do it that way, just that that is how it is done for ide and scsi
when multiple controllers are present.  After all normal ide controllers
handle 4 disks maximum (through two ports).  A system with two dual port
ide controllers would have hda ... hdh.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The Linux FAT issue on SD Cards.. maintainer support please

[Lennart Sorensen]

On Wed, Aug 24, 2005 at 02:03:16PM +0530, Mukund JB. wrote:
> Dear Lenneart,
> 
> One good news
> I have implemented the partition support in the driver.
> I am able to mount the partition of the individual device.
> I partition them using the fdisk and mounted them.
> The architecture this some thing like this
> The whole device is represented by tfa0
> And rest of the partitions by tfa0p1, tfa0p2 and so on...
> If there is a device in second socket, the whole device is represented
> by tfa1 and rest of the partitions by tfa1p1, tfa1p2 and so on... I am
> following the above conventions. Is the is what in general all Linux
> devices follow. 

Most common for disk devices is XXYZ where XX is some name for the
driver (hd for ide, sd for scsi, other things for other drive types), Y
is a letter (a for first, b for second, c for third, etc) and Z is the
partition number.  So in your case you could have:

tfaa for first slot
tfaa1 for first partition on first slot.
tfab for second slot
tfab4 for 4th partition on second slot.

Or call it tf and use tfa1 tfb4 etc.

> I have four sockets on which I have to support individual device with
> partitions on them. Is there a better conventional way to represent all
> the four devices? My driver also supports 4 such controllers. To support
> first socket device on the second controller I am using tfb0, tfb0p1,
> tfb0p2...

Well at least ide and scsi don't care which controller, they still just
name them in order.  You could just use tfa up to tfp for the devices.
That is what I would do unless the seperate controllers really make more
sense to users (counting to slot 16 might be a bit much using letters
for some users).

Maybe tf1a2 for controller 1 slot a partition 2 would be nicer to the
user.  Some raid cards do use /dev/raidname/c1d2p3 for card 1 device 2
partition 3.  Maybe you prefer that arangement.

> I have left with handling lot of generalization in the code.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Alsa-devel] Re: [Alsa drivers] Creatives X-Fi chip

[Lennart Sorensen]

On Tue, Aug 23, 2005 at 09:41:11PM +0100, Peter Zubaj wrote:
> This is too expensive card to be only able use it as simple card.
> My advice buy something else.
> I don't think fight with creative can bring anything good to linux.
> Leave Creative as is. There is plenty of other hardware from other
> manufacturer worth money.

If I could get the same level of support as my sb live has, I would be
quite happy.  I don't need EAX, but I do want midi synth and multi
channel audio playback and recording and such to work, and all the line
in and out on the device.  We have that on the emu10kx cards as far as I
can tell (at least everything I have used on my sb live platinum works).

I don't mind if the fancy DSP algorithms and EAX is windows only, since
it really only applies to games, and if I want to play a windows game, I
will reboot to windows.  Doesn't happen very often lately, but with an
athlon 700, it isn't that surprising really.  Maybe when someday I get
an athlon 64 instead.

So I would buy creative's new card if it had the same level of support in
alsa as the current emu10kx cards do.  Any more I don't expect, but any
less would mean I don't buy one.  The emu10k1 sb live was the first
creative product I was ever willing to buy and with the support it has
in linux I have been happy with it.  I didn't want their older cards,
and I don't want most of the other cheap crap cards that have been
around (I used to have a few gravis cards and liked those).

Most onboard audio seems to pretty decent these days, but if you expect
midi to work, you want something a bit better.

So I for one would love to see creative offer enough documentation or
example code to replicate the features of the emu10kx on the new chip,
even if we still don't get DSP algorithms.  If they don't, well I won't
buy one, and I won't recomend it to anyone either.  If they do, I will
highly recomend it (if it works as well as it appears it should), and I
will buy one too.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: Incorrect RAM Detected at kernel init

[Lennart Sorensen]

On Sun, Aug 21, 2005 at 11:27:51PM -0400, Terry wrote:
> Not sure if I have provided enough info, or to much info, but here it goes:
> 
> [1.] One line summary of the problem:
> Not Detecting all the memory installed in the system.
> 
> [2.] Full description of the problem/report:
> I have Linux Kernel 2.4.31 running on a Compaq 5000R server with 2 PPro 200
> processors, 768M RAM, RealTeck 8139 Network Card, and Compaq Smart 2 Raid
> controller with 5 9.1G drives in Raid 5 configuration.
> The kernel appears to compile perfectly, installs fine, but after reboot it
> is only reporting 16M of RAM. I have tried with and without the mem=768M
> boot up option in the lilo.conf script. All other modules and boot up
> includes appear to run perfectly fine. I had a 2.4.18 kernel running on this
> box just fine, detected all 768M of RAM and ran perfectly. The 2.4.31 Kernel
> runs almost perfectly, the only hold back is the false detection of memory.

Compaq machines of that era are known to have non standard bios methods
for identifying ram.  Do a google search for how to pass memory maps to
2.6 kernels on a compaq.

ie something like:

mem=exactmap [EMAIL PROTECTED] [EMAIL PROTECTED]

Add that to the kernel command line when booting and see what happens.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Posix file attribute support on VFAT (take #2)

[Lennart Sorensen]

On Mon, Aug 22, 2005 at 01:46:29PM +0200, Pavel Machek wrote:
> Unfortunately, it makes sense. If you have compact flash card, you
> really want to have VFAT there, so that it is a) compatible with
> windows and b) so that you don't kill the hardware.

VFAT is plenty good at killing hardware.  It's a terrible filesystem for
flash cards (if they don't do their own wear leveling properly).  Most
of the linux filesystems may not be any better but they are also no
worse.  Windows compatibility is completely irrelevant if the card is
being used as your root filesystem since any extensions you make to vfat
wouldn't be understood by windows anyhow, so at best it makes a mess of
it.

> I guess being able to use CF card for root filesystem is usefull,
> too

I run ext3 on CF and so far, no problems.  I run with noatime and try to
avoid writing in general as much as possible.  VFAT would be crap since,
well, I run linux on the system.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The Linux FAT issue on SD Cards.. maintainer support please

[Lennart Sorensen]

On Fri, Aug 19, 2005 at 05:09:06PM +0530, Mukund JB`. wrote:
> To handle it in a similarly in Linux we need to support this driver with
> partitions. There looks a loop hole in the driver. 
> I will verify and fix it today.

I suggest having a look at how other drivers use the add_disk call,
since it calls the partition checking code already in the kernel
automatically as far as I can tell.  You really shouldn't have to write
any of the partition parsing code at all.  You should just have to setup
a structure describing the disk and which major/minor numbers it uses,
and passing that to add_disk and it should deal with the rest.

> Just out of inquisitive ness.
> 
> What r u the minor numbers of those zip devices.
> ll /dev/zip 
> ll /dev/zip4

They are symlinks:
/dev/zip -> /dev/sda
/dev/zip4 -> /dev/sda4

sda uses major,minor: 8,0
sda1: 8.1
sda2: 8,2
...
sda15: 8,15
sdb: 8,16
sdb1: 8.17
...
sdb15: 8,31

That is how scsi does it.

If your driver supports multiple slots at once, decide how many to
support, or decide to only allow a few partitions, and space them by 8
or 16 (allowing 7 and 15 partitions respectively), and it should be easy
to deal with.  sda of course accesses the whole device, while sda1 and
up are for those partitions.  I am pretty sure there is standard
partition handling code in the kernel you should be accessing.

> Thanks for ur support.
> I will check with partition support in the driver & update it.
> Let me fix it there and come back.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The Linux FAT issue on SD Cards.. maintainer support please

[Lennart Sorensen]

On Thu, Aug 18, 2005 at 06:21:39PM +0530, Mukund JB`. wrote:
> Dear all,
> 
> I have few updates in this issue.
> I have attached the Images as well as the mount-log to this mail.
> Please see the comments inline.
> 
> I think, fdisk it trying to portray that n/o cylinders 448. So, it also
> takes care of displaying the relevant n/o sector & NO more or NO less.
> 
> I have implemented the partition support in the driver but some HOW I am
> NOT able to get the driver working with all the sockets. It is just
> working with the socket 0 and NO other socket. 
> I mean I am able to mount windows & linux formatted SD card with new
> driver present from socket 0.
> 
> I have an update on this.
> 
> I found some common things between the windows formatted SD & Linux
> formatted SD.
> I found that both of then do NOT have the partition table.
> I found that both of them have FAT12 FS in the sector 0 starting at
> offset 0.
> Why? I am NOT able to guess.

If you don't use fdisk to create a partition on the card, then you won't
have one.  If you mkdosfs on /dev/tfa0 then you loose the partition
table and get a filesystem on just the whole disk.  If you do it with
/dev/tfa0p1 then you do it on the first partition which would then have
the FAT filesystem starting at the offset of the first partition (as it
should).

> For Windows formatted SD there is NO partition table at all.
> I went on more R&D and tried to get to format the USB-Thumb drive.
> Even that did NOT have a partition table. 
> It looks like windows treats all removable media device as devices with
> NO partitions.

That is right.  Although I believe if windows sees one with a partition
table it will just use the first valid partition table entry it finds
and ignore the rest.

> Even on Linux formatted SD there is NO partition table present.
> 
> Please have a look at the images I am attaching to this mail.
> I have attached CAM-MS, WIN-Ms & Linux-MS first 512 byte length Images.
> These are the Images of first 512 bytes of sector 0.
> You can find the FS there on Lin & Win Images.
> 
> I have verified this by keeping some DEBUG messages in the FAT layer &
> seeing what data is being passed to this fat_boot_sector structure when
> mount call is issued.
> I am also attaching those LOG messages. please Have a LOOK at them too &
> you will have a fair understanding.
> 
> I have verified it with fdisk -l -u /dev/tfa0 
> It has shown that it is the partition 0 & nothing else.
> 
> Please see the Images-All-MS-512.tar.gz.

Well to mount anything without a partition table, you would mount the
whole device (/dev/tfa0) and to mount one with a partition table on it,
you would mount /dev/tfa0p1 or tfa0p4 or whichever partition it is.

Zip drives used to be the same way.  Some were formated with 1 partition
(usually 1 or 4) and some had no partition table at all and used the
whole disk for the filesystem.  I always had a /zip and /zip4 mount
point I used depending on the particular disk I was looking at.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The Linux FAT issue on SD Cards.. maintainer support please

[Lennart Sorensen]

On Wed, Aug 17, 2005 at 10:32:03PM +0530, Mukund JB`. wrote:
> A have a new fining here.
> 
> fdisk -l -u /dev/tfa0:
> debdev1:~# fdisk -l -u /dev/tfa0
> 
> Disk /dev/tfa0: 14 MB, 14680064 bytes
> 2 heads, 32 sectors/track, 448 cylinders, total 28672 sectors Units =
> sectors of 1 * 512 = 512 bytes
> 
>Device Boot  Start End  Blocks   Id  System
> /dev/ tfa0p1  57   28799   14371+   1  FAT12
> 
> On a keen look on the above fdisk output on my 16MB SD card, you can
> find the cylinder information as 448 where as my driver ioctl returns
> 450.
> 
> I have found from the partition table that Total n/o sector for the
> primary partition is 28743 (total sectors).
> But my ioctl returns total cylinders as 450 i.e. 28800 sectors.
> As 28743 is NOT any multiple of 64(2*32)i.e sectors*heads, the fdisk
> tried manipulates it to get multiples of 64.
> So, finally the best multiple 448 cylinders (i.e. 28672 sector)
> So, finally that NOT a BUG in the driver instead is a generalization
> made by fdisk command.

If the partition starts at sector 57 and is 28743 sectors long, then
that matches 28800 sectors total.  No problem there.

If on the other hand fdisk reports 28672 sectors total then there is a
problem somewhere.

> This is a policy & NO policy is the driver should be implemented.
> I think we need NOT handle all this in the driver. The upper layer of
> the mount application looks into verifying this.

Well then you have to implement full partition support and present a
seperate device for each partition in /dev so that mount can access each
partition.

> There is a partition table in the CAM formatted device & it looks like
> there is also a partition table in the win formatted device.
> The details of there at offset 0x1BE are below.
> 
> CAM formatted SD Details
> - 0x1BE offset detailed messages (decimal no
> )-- Reading data from sector '0' at offset
> 0x1BE(Partition table start addr)
> 
> bootable  = 0x80  (0x1BE)
> beg-chs.heads = 0x1
> beg-chs.sect  = 0x1A
> beg-chs.cylin = 0x0
> sys-type  = 0x1
> end-chs.heads = 0x1
> end-chs.sect  = 0x60
> end-chs.cylin = 0xC1
> start sect= 0x39
> n/o sec in part   = 0x7047

Well that one looks pretty sane.

> Win formatted SD Details
> - 0x1BE offset detailed messages (decimal no
> )-- Reading data from sector '0' at offset
> 0x1BE(Partition table start addr)
> 
> bootable  = 0x6F  (0x1BE)
> beg-chs.heads = 0x74
> beg-chs.sect  = 0x68
> beg-chs.cylin = 0x65
> sys-type  = 0x72
> end-chs.heads = 0x20
> end-chs.sect  = 0x6D
> end-chs.cylin = 0x65
> start sect= 0x2E61964
> n/o sec in part   = 0x440A0DFF

That one looks more like random numbers.  Maybe the partition entry that
it really uses is not number 1, but number 2 3 or 4, or no partition
table at all.

Could you do dd if=/dev/sda bs=512 count=1 | xxd

For each of your two cards.  Then we can really see what is in the
partition tables of those two cards.

> NO, I think driver is NOT broken instead the partition tables speaks SO.
> sfdisk returns 448 cylinders for my 16MB SD card, where as my driver
> ioctl returns 450.

Well I wouldn't ever trust sfdisk.  fdisk -l -u I trust more.

> I have found from the partition table that Total n/o sector for the
> primary partition is 28743 (total sectors) whereas my ioctl returns
> total cylinders as 450 i.e. 28800 sectors. 
> 
> As 28743 is NOT any multiple of 64(2*32)i.e sectors*heads, the sfdisk
> manipulates it to get multiples of 64. The best multiple is 448
> cylinders (i.e. 28672 sector). This is where we are missing 128 sectors.
> 
> So, finally that NOT a BUG in the driver instead is a generalization
> made by sfdisk command.

Well I believe sfdisk has been broken in the past.  It wouldn't surprise
me if it still has bugs.

> I added BLKGETSIZE ioctl. When I tried to note the ioctl called at mount
> time I find it is all the time HDIO_GETGEO.
> 
> At this angle it clear that sfdisk output is Not the result of BUG in
> the driver instead it is a result of partition table TOTAL SECTORS
> entry. 
> 
> I have a doubt where Linux is treating this a separate class of device.
> I heard some thing about the FS found on the Floppies. 
> I guess FS on win & linux SD is such kind of FS & so I am able to mount
> it.
> 
> How do I verify this? I am clean about the FS on Floppies. I will try to
> find it tomorrow on the NET.
> 
> As CAM SD has altogether HD like info. And that is why we are NOT able
> to mount it.
> 
> Can you comment on this?

Well if you inlcude the hex dump of the two MBR sectors then I may be
able to comment on it.

fdisk -u -l /dev/sda for each card would also help (using the usb reader
preferably if you got that working yet.)

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EM

Re: The Linux FAT issue on SD Cards.. maintainer support please

[Lennart Sorensen]

On Tue, Aug 16, 2005 at 07:04:34PM +0530, Mukund JB. wrote:
> I have bought a "entermultimedia" USB 2.0 21-in-1 card.
> There are no Linux driver support in the CD  provided.
> Can u suggest me what is best bug (USB card reader) with Linux driver
> support in the Market.

Load usb drivers and usb-storage driver and scsi disk module (sd_mod).
Then it should show up as a scsi disk.  No modern OS requires drivers
added for usb drives.  They are just included.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The Linux FAT issue on SD Cards.. maintainer support please

[Lennart Sorensen]

On Tue, Aug 16, 2005 at 06:54:40PM +0530, Mukund JB. wrote:
> Yes, I agree. My sentence formation was wrong.
> 
> My question here is:
> 
> If I have NO multiple partition support implemented in the driver, will
> it effect mounting the first partition on the device?

Yes.  If you have no partition support, then you can only mount cards
without a partition table since that is all you are presenting.  cards
which have a partition table will have their start of filesystem offset
by a few sectors to the start of partition 1 or 4 or whichever it is
using.

> i.e. If I said alloc_disk(1) (single partition), and if I am trying to
> mount the very first partition, will I be able to do it?
> 
> Existing gendisk code:
> ---
>   alloc_disk(1);
>   first_minor = socket_no; // Device socket no varies from 0 - 3.
>// so, each device- we have
> just one node; // NO partitions on
> each device.
> 
> Device Interface: mknod /dev/tfa0 b 252 0
> 
> Will I have to modify the above code? 

I don't even know what that code is doing.

> Will you tell me what else do I need to handle multiple partition in my
> driver apart from alloc_disk(n) & first_minor modifications as per n(n/o
> partitions)?

Well you can either support partitions fully by making your driver work
like the ide and scsi and such drivers do things, or you can just make
it simpler and only support devices without a partition table and those
with a single partition entry in the partition table.  That would
support probably 99.99% of cards you would encounter.  You just have to
check if a partition table exists, if it doesn't, just present the whole
device as the disk, while if a partition table exists, scan it for a
partition that is not a blank entry, then find the start of that
partition and present the device to the user starting at that sector.

> The partition layout mentioned in the partition table is same for the
> Windows formatted SD & CAM formatted SD. I assume partition layout
> starts at 0x1BE.

If there is a partition table then it starts there.

> >> Sfdisk -l /dev/tfa0 ( CAM & win)
> >> Disk /dev/tfa0: 448 cylinders, 2 heads, 32 sectors/track
> >> Units = cylinders of 32768 bytes, blocks of 1024 bytes, counting from
> 0
> >>
> >>Device Boot Start End   #cyls#blocks   Id  System
> >> /dev/tfa0p1   *  0+449 450- 14371+   1  FAT12
> >> /dev/tfa0p2  0   -   0  00  Empty
> >> /dev/tfa0p3  0   -   0  00  Empty
> >> /dev/tfa0p4  0   -   0  00  Empty
> >> Warning: partition 1 extends past end of disk
> >>
> Can you quote your comments on the warning given by sfdisk command
> above?

The warning means the driver is broken and says the wrong number of
cylinders for the device.

> These files belong to the same device. They are just different sectors
> of the device file. 
>   
>   Cluster-0.txt - First 16 Blocks of the device
>   Phy-Cam-57-sector.txt - 57th sector of the device (claimed FAT
>   
> Sector)

Oh ok.  So on that card the first partition probably starts that that
sector.

> >So for the device above with one partition, you would have to check
> >the partition table entry to find the start sector number of the
> >partition and then offset requests by that amount.
> 
> You mean the application like mount should check the partition table
> entry to find the start sector number of the partition and then mount
> the particular partition.
> 
> >For example:
> >fdisk -l -u /dev/sde:
> >debdev1:~# fdisk -l -u /dev/sde
> >
> >Disk /dev/sde: 14 MB, 14745600 bytes
> >2 heads, 32 sectors/track, 450 cylinders, total 28800 sectors
> >Units = sectors of 1 * 512 = 512 bytes
> >
> >   Device Boot  Start End  Blocks   Id  System
> >/dev/sde1  57   28799   14371+   1  FAT12
> >
> >So if you skip 57 sectors you would see the FAT12 filesystem.
> >
> 
> Can you comment on the fdisk output which says the total sectors are
> 28672 while the total n/o sector passed to fdisk through the HDIO_GETGEO
> ioctl is 28800.

You are missing 128 sectors which happens to be 2 heads * 32 sectors *
2 cylinders.  So 28672 matches 2 heads, 32 sectors 448 cylinders, so
may the real problem you had with sfdisk was that it decided your total
sector size was wrong, and fixed the cylinder count down by 2 to match
the number of sectors.  Your driver SHOULD be returning 28800 for the
number of sectors.

> I have a single ioctl implemented in the driver i.e HDIO_GETGEO ioctl.

Perhaps one of the more modern ways of getting disk size would return
the full number of sectors instead.  For example the ioctl BLKSSZGET and
BLKGETSIZE and BLKGETSIZE64.

Now on the other hand, I think you may have an error in your total size
calculation in the driver too, since 2 heads * 32 sectors * 450
cylinders is 28800 sectors total.

> fdisk -l -u /dev/

Re: fdisk & LBA

[Lennart Sorensen]

On Fri, Aug 12, 2005 at 10:29:13PM +0300, Nanakos Chrysostomos wrote:
> Hi all,i want to retrieve the partition table of a primary extended
> partition.
> My MBR partition table ,says that the LBA Partition Start sector for the
> extended partition is 10281600.It is the same that i find with my C code
> and through fdisk usage.
> How can i use this value to seek(lseek) to this point through the main
> block file (/dev/hda or /dev/hdb) and read the partition table of the
> logical partition?

Multiply by the sector size (probably 512 bytes).

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The Linux FAT issue on SD Cards.. maintainer support please

[Lennart Sorensen]

On Fri, Aug 12, 2005 at 09:16:56PM +0530, Mukund JB. wrote:
> When I said mount, I guess FAT will read sector 0 to get the partition
> info. And is it due to lack of partition support in the driver that will
> affect the FAT layer reading the device.
> Please update?

No, the kernel read the partition table if it is there, and presents
each partition as a device.

The user can then mount the partition or the whole device (whichever is
appropriate for the card) using the FAT filesystem driver.  The fat
driver only works when pointed at the right location and has no clue
about partitions (and it should not have a clue).

> Yes, right, my card size if 16 MB. FS type is FAT12.
> 
> The SD card has partitions on it (both: cam, windows).
> So, my device node accessing is direct. 
> You can see below the SD card has a single primary partition.
> 
> So, I say "mount -tvfat /dev/tfa0 /mnt" which works for windows
> formatted SD.
> The same does NOT work with CAM formatted SD.

Well if you ignore the partition table and just use a hardcoded offset
to the start of the partition, well then it likely won't work if the
partitioning layout is different for the two cards.

> Sfdisk -l /dev/tfa0 ( CAM & win)
> Disk /dev/tfa0: 448 cylinders, 2 heads, 32 sectors/track
> Units = cylinders of 32768 bytes, blocks of 1024 bytes, counting from 0
> 
>Device Boot Start End   #cyls#blocks   Id  System
> /dev/tfa0p1   *  0+449 450- 14371+   1  FAT12
> /dev/tfa0p2  0   -   0  00  Empty
> /dev/tfa0p3  0   -   0  00  Empty
> /dev/tfa0p4  0   -   0  00  Empty
> Warning: partition 1 extends past end of disk
> 
> I don't understand, what is /dev/tfa0p1? I have no such device.

Well that would be the partition 1 on the tfa0 device, which you need
since that card has a partition there.

> Will you please elaborate this?
> What kind of partition support is required in the driver to support the
> Camera Fat12 formatted SD Card?
> 
> I dumped the 1st sector of SD when formatted on CAM.
> I have attached the files. Please have a look at them
> 
>   Cluster-0.txt - First 16 Blocks of the device
>   Phy-Cam-57-sector.txt - 57th sector of the device (claimed FAT
> sector
> in Partition table)

Well one of the two files you sent appears to contain a FAT12 filesystem
directly on the device and has no partitions.  The other appears to
contain a partition table with one partition, and I suspect that
partition contains a FAT12 filesystem.

To read one you access the whole device and mount that.  To access the
other you have to use the partition and mount that instead.  This is why
your driver MUST support partitions, or at the very least look for a
partition table, and if it sees one, skip to the sector the partition
table says is the start and present the device from that location on as
the device (although that MAY mess up FAT, since I don't know if fat
uses relative sector numbers from the start of the partition, or
physical drive sector numbers.  I would think it was relative, in which
case you should be ok just offseting all requests to the device by the
number of sectors to the start of the partition found.

So for the device above with one partition, you would have to check
the partition table entry to find the start sector number of the
partition and then offset requests by that amount.

For example:
fdisk -l -u /dev/sde:
debdev1:~# fdisk -l -u /dev/sde

Disk /dev/sde: 14 MB, 14745600 bytes
2 heads, 32 sectors/track, 450 cylinders, total 28800 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot  Start End  Blocks   Id  System
/dev/sde1  57   28799   14371+   1  FAT12

So if you skip 57 sectors you would see the FAT12 filesystem.

On your card without a partition table, the FAT12 starts at sector 0, on
the other it is offset by the number of sectors to the start of the
first partition.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The Linux FAT issue on SD Cards.. maintainer support please

[Lennart Sorensen]

On Fri, Aug 12, 2005 at 07:52:31PM +0530, Mukund JB. wrote:
> I dumped the 0th sector of SD when formatted on 
>   1) CAM &
>   2) Windows
> The partition table exists on both.
> But, the Master Boot Code is NOT present on the CAM formatted SD but is
> available on windows formatted SD card.
> 
> Can you comment on the Master Boot Code? What is it required on Linux
> HOW does windows managed without it? I mean how is Windows able to mount
> the SD?
> 
> My driver does NOT support partitions? I mean I have implemented it as
> alloc_disk(1) & relative first_minor chage obviously.

If you don't at least read the partition table to find where the first
partition starts, then you won't know where to start looking for a FAT
filesystem.

> Is it why I am NOT able to mount the CAM formatted device?
> Is this a problem?

Well in the past I have seen cards that had a partition table, with one
partition in it (usually either primary partition 1 or 4) and had that
partition formated with FAT12, 16 or 32 (depending on size).  Some had
no partitions, and just had the whole device formated with FAT like a
floppy.  Windows seems to deal with both, as does linux (as long as you
ask it to mount the right device such as /dev/sda1 sda4 or sda depending
on which partition (if any) the card uses.

If you ignore partitions entirely, many cards will not work for you
since they do have partitions on them.  Some will work if they use the
entire device without partitions like a floppy would.

The SD card I have here formated by my Canon SD200 has this as the
MBR/partition table (first sector):
000: fa33 c08e d0bc 007c 8bf4 5007 501f fbfc  .3.|..P.P...
010: bf00 06b9 0001 f2a5 ea1d 0600 00be be07  
020: b304 803c 8074 0e80 3c00 751c 83c6 10fe  ...<.t..<.u.
030: cb75 efcd 188b 148b 4c02 8bee 83c6 10fe  .u..L...
040: cb74 1a80 3c00 74f4 be8b 06ac 3c00 740b  .t..<.t.<.t.
050: 56bb 0700 b40e cd10 5eeb f0eb febf 0500  V...^...
060: bb00 7cb8 0102 57cd 135f 730c 33c0 cd13  ..|...W.._s.3...
070: 4f75 edbe a306 ebd3 bec2 06bf fe7d 813d  Ou...}.=
080: 55aa 75c7 8bf5 ea00 7c00 0049 6e76 616c  U.u.|..Inval
090: 6964 2070 6172 7469 7469 6f6e 2074 6162  id partition tab
0a0: 6c65 0045 7272 6f72 206c 6f61 6469 6e67  le.Error loading
0b0: 206f 7065 7261 7469 6e67 2073 7973 7465   operating syste
0c0: 6d00 4d69 7373 696e 6720 6f70 6572 6174  m.Missing operat
0d0: 696e 6720 7379 7374 656d  8158 3315  ing system...X3.
0e0:          
0f0:          
100:          
110:          
120:          
130:          
140:          
150:          
160:          
170:          
180:          
190:          
1a0:          
1b0:        0001  
1c0: 1a00 0101 60c1 3900  4770    `.9...Gp
1d0:          
1e0:          
1f0:        55aa  ..U.

The first sector of the partition is this:
000: eb00 9050 7772 5368 6f74 2000 0220 0100  ...PwrShot .. ..
010: 0200 0247 70f8 0300 2000 0200 3900   ...Gp... ...9...
020:   8000 294e cf68 6f43 414e 4f4e  ..)N.hoCANON
030: 5f44 4320 2020 4641 5431 3220 2020 33ff  _DC   FAT12   3.
040: 8edf be00 7c8d 9ce4 018e 4702 fcb9 0002  |.G.
050: f3a4 c707 5800 ff2f 8cc8 fa8e d0bc 0006  X../
060: fb8b ec83 ec16 c536 7800 8976 f68c 5ef8  ...6x..v..^.
070: 8d7e eab9 0b00 57f3 a45f 8ed9 be78 0089  .~W.._...x..
080: 3c8c 4402 0e1f c645 0412 c645 090f b200  <.DE...E
090: 91cd 13a0 1800 f626 1a00 8946 fa83 3eea  ...&...F..>.
0a0: 0100 7520 a010 0098 f626 1600 0306 0e00  ..u .&..
0b0: a3ea 0191 b820 00f7 2611 00f7 360b 0003  . ..&...6...
0c0: c1a3 ec01 33d2 a1ea 01b9 0100 c41e e001  3...
0d0: e890 00b0 20f6 26e8 01c4 3ee0 0103 f8be   .&...>.
0e0: f101 b90b 00f3 a674 24be a501 e849 0032  ...t$I.2
0f0: e4cd 16e8 0200 cd19 33c0 8ed8 bb78 00c4  3x..
100: 7ef6 893f 8c47 02c3 becc 01eb dfc4 1ee0  ~..?.G..
110: 018b 16ee 01a1 ec01 8a0e f001 b500 e842  ...B
000

Re: NCQ support NVidia NForce4 (CK804) SATAII

[Lennart Sorensen]

On Thu, Aug 11, 2005 at 07:38:12PM +0200, Michael Thonke wrote:
> I have a ASUS A8V Deluxe too, and can't use the AMD X2 processor on 
> it...this is a feature..right?
> Supposed to run with DualCore but don't post..hm.

Well according to Asus you can if you run BIOS 1013 or 1014 on the
board.  Any less and it won't boot.

Now I certainly can't try it given I don't have such a CPU.

> My SATA II devices. Get not regonized from the VIA SATA 
> controller...this bug is known.
> So I want to use my HDD's I bought ...why should I set my SATA II device 
> to be SATA I.

So a SATA II drive doesn't work at all?

> Is also a feature of VIA Chipsets, right?
> 
> "It's not a bug, hey let's say is a feature."

Common practice it seems.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NCQ support NVidia NForce4 (CK804) SATAII

[Lennart Sorensen]

On Thu, Aug 11, 2005 at 07:44:49PM +0200, Michael Thonke wrote:
> AMD X2 DualCore?

If you buy me one I will try it. :)

> Yes, Marvell, Silicon Image  no problem as they provide OpenSource drivers.
> On a normal setup is  nearly everything okay.
> 
> I hold up a hardware testlab  to find b** *features* the specification 
> don't show/hold.

That sounds like it could be complicated work.

> Things that can go scary for production usage - that's my job.

I just want the machines I buy to work.  So far they do.  I try to check
for support before buying any hardware.

> USB works also great for all chipsets :-)

That I wouldn't be 100% sure about.  I remember reading about USB
problems on a few chipsets in the past.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NCQ support NVidia NForce4 (CK804) SATAII

[Lennart Sorensen]

On Thu, Aug 11, 2005 at 01:20:56PM -0400, Jeff Garzik wrote:
> What specifically does not work, on VIA+AMD64 combination, under Linux?
> 
> My Athlon64 with VIA chipset works great.

Mine does too.  Asus A8V Deluxe.  No problems so far.  Everything on the
board I have tried just works.

Can't say my A7N8X-E Deluxe has any real issues either.  I may only get
ac97 audio level out of the nifty DSP, but I hardly use sound on the
system anyhow, so I don't mind.  forcedeth driver works for networking,
sil3112a sata works with WD drives no problem, nvidia ide controller
seems to work fine with dvd drives, firewire works, yukon sk98lin works
too, usb is fine.  No complaints from me.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: The Linux FAT issue on SD Cards.. maintainer support please

[Lennart Sorensen]

On Thu, Aug 11, 2005 at 10:57:14AM +0530, Mukund JB. wrote:
> I am Linux driver programmer. 
> 
> I have a FAT12 issue on my SD cards. I have got these addresses from the
> fs-lists as the maintainer support mail IDs for FAT-FS.
> 
> I am using the 2.6.10 kernel, X86 like systems.
> 
> I am NOT able to mount the Camera formatted FAT12 filesystem on my linux
> BOX. SD card is of size 16MB. At the same time I am able to mount the SD
> cards formatted in windows & linux.
> 
> I have identified fat_fill_super() in fs/fat/inode.c file as the
> function that reads the super block of as MS-DOS FS.
> 
> To debug, I have rebuilt my kernel 2.6.10 inserting some debug messages
> in the FS sub-system to know what data is coming into "struct
> fat_boot_sector *b" structure in fs/fat/inode.c file after sb_bread()
> call.
> 
> I believe that this data in the "struct fat_boot_sector *b" should be
> FAT12 information.
> 
> On the camera formatted SD that is NOT mounting I have found this
> structure to be all '0' till total_sectors variable (relevant till here
> on - FAT12).
> 
> Will you please verify if there & tell me if the problem is in the FAT
> sub-system.

A few things I would try:

Stick the SD card in a generic cheap USB media reader, and see what the
kernel thinks of the cards then.  Do both work?

If the answer is still no, then it really seems the card is formated
incorrectly, or linux has a bug in the fat driver.

If both work fine that way, then there is a problem in the driver for
the sd reader you are using that needs to be resolved.

Using a known to work for people in general driver (usb-storage) with
a standard usb card reader sure does seem like a good start until you
know if the card is formated properly or not.

You could also use that do dd the first few blocks from the card to see
what the partition table and fat tables look like, in case your SD
driver is somehow messing that part up.  By having a copy you can
compare more easily.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Partitioning problems on x86_64 (fwd)

[Lennart Sorensen]

On Thu, Aug 11, 2005 at 03:32:14AM +0100, Ken Moffat wrote:
>  Apologies if these are known problems, but I don't recall seeing them
> mentioned recently.
> 
>  I'm running an athlon64 with 2.6.12.3, in the middle of rebuilding it
> to run 64-bit.  The main drive used to be in an i686 machine for
> testing, and it got to a point where I wanted to repartition.
> 
>  Under a 64-bit kernel, every time I tried to rewrite the partition
> table in fdisk I got an error 16, device or resource busy, with a
> message that the new partition table would be used at the next boot.
> (Yes, I had umounted everything except '/' on hda5. )  Since making a
> filesystem on my new /dev/hda7 and mounting it showed the size of the
> old hda7 in 'df', I tried rebooting but the failure to rewrite the
> partition table continued.

The kernel won't reread the partition table as long as ANY part of that
disk is mounted.  Reboot (which of course unmounts everything) to reread
the partition table.

>  At one point, I thought I'd try the stronger magic of sfdisk, but that
> just reported some error in the number of bytes read, and decided it
> couldn't read the partition table.
> 
>  In the end I was able to repartition successfully by rebooting to a
> 2.6.12.1 i686 kernel.  This box is destined to become my new home
> server, so running test kernels on it isn't something I'm keen to try,
> but I thought I'd better report this, and the successful workaround of
> using an i686 kernel, which will be a bit of a pain on pure64.

Just any reboot should have worked.  Once you reboot it reads the
updated partition table and THEN you can mkfs the new partitions.  Until
/proc/partitions matches what you see in fdisk, you really don't want to
try access the partitions since it won't match on the next boot anyhow.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NCQ support NVidia NForce4 (CK804) SATAII

[Lennart Sorensen]

On Wed, Aug 10, 2005 at 01:53:47PM -0700, Allen Martin wrote:
> Likely the only way nForce4 NCQ support could be added under Linux would
> be with a closed source binary driver, and no one really wants that,
> especially for storage / boot volume.  We decided it wasn't worth the
> headache of a binary driver for this one feature.  Future nForce
> chipsets will have a redesigned SATA controller where we can be more
> open about documenting it.

I never have been able to understand how some hardware that seems so
simple can possibly have anything secret in it.  3D video drivers I can
understand, sound chips I can't (well DSP algorithms maybe, but not
plain doing input.output), network chips should be real simple, and well
ide/sata controllers don't seem like they should be very complex to
program either.

But what do I know...  I find it hard enough to get specs for some
network chips under NDA when you are actually buying the darn chips from
the company.  Some companies appear to fail to realize they are
_hardware_ companies making money selling hardware, not intellectual
property companies.

Well it will be nice to see fully open SATA/IDE controllers in future
nvidia chipsets.  I guess I will put off upgrading my athlon 700 until
those come out. :)

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SATALink Sil3112 and Linux woes

[Lennart Sorensen]

On Mon, Aug 08, 2005 at 11:45:22PM +, Shaun Jackman wrote:
> I have a Silicon Image SATALink Sil3112 PCI card connected to two 200
> GB SATA Seagate drives.  I'm running into many problems with this
> setup. Is this card well supported under Linux? If it's a black sheep,
> could someone please recommend a PCI SATA card that works well?

There have certainly in the past been known problems with Sil SATA
controllers and Seagate drives due to both doing something stupid as far
as I understand it.  It seems this only applies to seagate drives with
an ide to sata convert onboard rather than a true native sata drive
(which only very resent models would be).  It also seems only the
Sil3112 controller has a stupid assumption that upsets the seagate sata
to ide convertor.

> I am really having no luck. I would love to...
>   solve the ten-minute boot delay issue
>   replace the Sil3112 with a better supported card
>   use Knoppix to somehow fix my newly installed Debian partition

Well if what I have read about Sil + Seagate is correct, you can either
replace the drives with drives that follow the SATA standard correctly
(WD, Maxter, etc) or you can find another supported controller chip and
get a card using that.

I have no problem with the Sil3112A myself on an Asus board using WD
drives.

For me personally it has been simpler to avoid seagate drives than to
avoid Sil controllers given how often they are used as onboard
controllers on motherboards.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Where's the list of needed hardware for donating?

[Lennart Sorensen]

On Sun, Jul 31, 2005 at 10:06:38PM +, Richard Hubbell wrote:
> Ok, here's the list:
> 
> Adaptec AHA-1510A
> (ISA, centronix-style external connector with terminator, one internal
> ribbon cable,
> I probably have some centronix-style external cables around too, this
> card doesn't have it's own boot ROM)
> 
> Gravis UltraSound a.k.a. GUS
> (ISA, fully loaded with memory, 1megabyte (I think))

Hasn't that been fully supported for years in ALSA?  I remember the guy
that started ALSA had written an amazing driver for the GUS before
starting ALSA.

> Pertec MyTape 800
> (I think this is a QIC tape drive that connects via the floppy interface)

I thought QIC floppy connected tape drives were supported as well.

> TEAC 1.44  3.5 inch Floppy FDR
> (FD-235HF)

Standard 3.5" floppy drive?

> Rocket Port 8-port serial board
> (ISA, 8 - RJ11 jacks, made by Comtrol, brand-new in-box)

I know nothing about the support of the rest of the hardware.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unable to mount the SD card formatted using the DIGITAL CAMREA on Linux box

[Lennart Sorensen]

On Mon, Aug 01, 2005 at 05:01:00PM +0530, Mukund JB. wrote:
> Dear all,
> 
> Below are my driver messages logged at initialization time & sfdisk call
> time. 
> 
> when module is initialized
> 
> TIFM INFO | TI init Routine Invoked!
> ReportMediaModel: ( SD card Details)
>   Size= 14 [MB]
>   mwCylinders   = 450
>   mwHeadCount   = 2
>   mwSectorsPerTrack = 32

Well the 450 cylinders there is right, so why is the driver passing info
down to user space saying the device has 448 cylinders?  Somehow you are
loosing 2 cylinders in your driver somewhere.

> When the ioctl is invoked through the "sfdisk -lV /dev/tfa0"
> 
> TIFM INFO |  invoked! 
> TIFM INFO | dev no. [ 0 ] sock no. [ 0 ]
> TIFM INFO |  geo.cylinders = 450
> TIFM INFO |  geo.heads = 2
> TIFM INFO |  geo.sectors = 32
> TIFM INFO |  geo.start = 0
> 
> This means that I am giving the proper details to the user program but
> the sfdisk is printing it wrong (probably manipulation).
> 
> And when I try to mount ..
> 
> mount /dev/tfa0 /mnt
> FAT: bogus number of reserved sectors
> Mount: you must specify the filesystem type 

Well if the partition table/fs size is larger than the device currently
claims to be, the FS will fail and mount will fail.  Nothing wrong in
mount, just broken device driver.

> mount -tvfat /dev/tfa0 /mnt
> FAT: bogus number of reserved sectors
> Mount: wrong fs type, bad option, bas superblock on /dev/tfa0,
>or too many mounted file systems
> 
> I have gone through the mount.c code in order to understand where I am
> exactly failing. 
> mount is failing in guess_fstype_and_mount() in do_mount_syscall after
> issuing the mount sys call.
> I am attaching the source code of mount functionality which may be on
> some help to u in u8ndertaing why exactly its failing.

Perhaps adding more debuging to your driver wherever user space calls in
to get the size of the device, to make sure you have the right
information passed along.  Heads and sectors looks fine, but the
cylinder count needs fixing since it is currently reporting 2 less than
it really is.  This has to be 100% a problem in the device driver.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unable to mount the SD card formatted using the DIGITAL CAMREA on Linux box

[Lennart Sorensen]

On Fri, Jul 29, 2005 at 11:05:50PM +0530, Mukund JB. wrote:
> camera formatted info
> --
> Disk /dev/tfa0: 448 cylinders, 2 heads, 32 sectors/track
> Units = cylinders of 32768 bytes, blocks of 1024 bytes, counting from 0
> 
>Device Boot Start End   #cyls#blocks   Id  System
> /dev/tfa0p1   *  0+449 450- 14371+   1  FAT12
> /dev/tfa0p2  0   -   0  00  Empty
> /dev/tfa0p3  0   -   0  00  Empty
> /dev/tfa0p4  0   -   0  00  Empty
> Warning: partition 1 extends past end of disk

Why excactly does the partition table say 450 cylinders when the kernel
believes it to be 448 cylinders?  Someone is wrong.  Either the device
was partitioned wrong and hence formated wrong, or whatever driver the
kernel is using to read it is broken and returns the wrong size for the
device.

I have never heard of /dev/tfa0p* either.  What is that?

> Windows formatted info
> --
> Disk /dev/tfa0: 448 cylinders, 2 heads, 32 sectors/track
> Units = cylinders of 32768 bytes, blocks of 1024 bytes, counting from 0
> 
>Device Boot Start End   #cyls#blocks   Id  System
> /dev/tfa0p1   *  0+449 450- 14371+   1  FAT12
> /dev/tfa0p2  0   -   0  00  Empty
> /dev/tfa0p3  0   -   0  00  Empty
> /dev/tfa0p4  0   -   0  00  Empty
> Warning: partition 1 extends past end of disk

Identical.  Sure makes it look like a driver error on the linux side in
that case.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unable to mount the SD card formatted using the DIGITAL CAMREA on Linux box

[Lennart Sorensen]

On Fri, Jul 29, 2005 at 08:02:14AM -0400, linux-os (Dick Johnson) wrote:
> Execute linux `fdisk` on the device. You may find that the
> ID byte is wrong.
> 
> Also, why do you need a special block device driver? The SanDisk
> and CompacFlash devices should look like IDE drives.

SD usually is secure digital (MMC compatible somewhat I believe).  It
does not provide IDE unlike CompactFlash.  SD uses a serial interface if
I remember correctly.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Helpme WitCh Cpu Scaling. Hi People

[Lennart Sorensen]

On Thu, Jul 28, 2005 at 03:56:49PM +0200, gabri wrote:
> I have 2.6.12.3 and 2.6.8 too
> I hace amd mobile sempron 28000

What brand and model is the laptop.  Certainly the error says it is a
bios error, so most likely the maker of the laptop has to fix their
mistakes in the PST table.  I guess mobile semprons being rather new,
bios mistakes are bound to happen in the less tested areas.  And perhaps
windows doesn't care, or maybe frequency scaling doesn't work in windows
either.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Helpme WitCh Cpu Scaling. Hi People

[Lennart Sorensen]

On Thu, Jul 28, 2005 at 04:20:10PM +0200, gabri wrote:
> In windows i have a driver that regulate the mhz of amd mobile sempron but 
> in linux i can not load any module for amd. The laptop is "supratech 
> xpert2601"and procesor is amd mobile sempron

Well the website for the company sure looks useless (not that I
understand spanish).  Do they actually offer bios upgrades?  Do they
actually say what chipset the laptop uses anywhere?  Is it ATI, nvidia,
amd, via, or what?

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: RFC: Raise required gcc version to 3.2 ?

[Lennart Sorensen]

On Thu, Jul 28, 2005 at 02:39:12PM +0200, Krzysztof Halasa wrote:
> Compilation speed? Don't know, using 3 (4?) years old Athlon 2000
> it's not a problem unless I need full build 30 times a day.
> 
> But people on 266 MHz ARM5 may notice.

Hmm, an a 400Mhz PXA 255 I found using gcc 3.x meant I could use xscale
rather than older optimizations, and the resulting kernel certainly felt
much faster (I never did actually meassure if it was faster or not).
Using gcc 2.95 requried changing the cpu optimization lines in the
kernel.  Of course this was in a kernel patched with the pxa arm patches
so it isn't quite the same as the mainline kernel.  I certainly won't
consider using gcc 2.95 on an arm anymore (although perhaps on older arm
models it does make sense).

I have no idea if it took longer to compile with gcc 3.x, but the result
seemed better to me.  To me performance of the resulting kernel is more
important than performance compiling the kernel.

Of course if you leave the choice as 2.95 and above rather than 3.2 and
above, people can pick whatever they want based on their needs.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Helpme WitCh Cpu Scaling. Hi People

[Lennart Sorensen]

On Wed, Jul 27, 2005 at 11:33:36PM +0200, gabri wrote:
> It is the first mail that I write. I call gabri and I am 18 years old. I am
> Spanish. I want to comment that me program does not work ningun to regulate
> the Mhz of the processor. " Cpufreq, cpuydn, powernow ". I do not manage to
> load ningun module from the kernel inside cpuscalig in that it(he,she)
> fences with an amd mobile sempron.
> The modules of athlon do not go.
> Do they work to give support to the mobile sempron in the future versions of
> the kernel?
> what can I do ?

Is this your message?
08:44 < gabri> Jul 28 16:25:26 debian kernel: powernow-k8: Found 1 AMD Athlon 
64 / Opteron processors (version 1.00.09b)
08:45 < gabri> Jul 28 16:25:26 debian kernel: powernow-k8: BIOS error: maxvid 
exceeded with pstate 0

You should probably also list the kernel version(s) (uname -a) and cpuinfo
(cat /proc/cpuinfo) just to have some more info to go on.

I don't actually know anything about the cpu frequency scaling myself,
since I just leave my systems running full speed all the time (I use
desktop machines, not laptops).

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: nVidia stuff again

[Lennart Sorensen]

On Thu, Apr 21, 2005 at 08:15:02AM -0400, Doug Ledford wrote:
> Ha!  That's the whole damn point Dave.  Use your head.  Just because ATI
> is getting more complex with their GPU does *not* mean nVidia is.  Go
> back to my original example of the aic7xxx cards.  The alternative to
> their simple hardware design is something like the BusLogic or QLogic
> cards that are far more complex.  Your assuming that because the ATI
> cards are getting more complex and people are less able to discern their
> makeup just by reading the specs that the nVidia cards are doing the
> same, nVidia is telling you otherwise, and you are just blowing that off
> as though you know more about their cards than they do.  Reality is that
> they *could* be telling the truth and the fact that their card is a more
> simplistic card than ATIs may be the very reason that ATI has ponied up
> specs and they haven't.  Therefore, you can reliably discern absolutely
> *zero* information about the nVidia cards from a reference to ATI specs.

Certainly possible.  Maybe all their real IP is in the code, although if
that was true, letting opensource peope ahve the programing spec and
have to do their own drivers wouldn't expose that IP.  I have no idea.

> "It's what you know, not what you think you know, that matters."  I
> don't know why nVidia keeps their specs secret.  All I know is what they
> tell the world.  But what I do know is that it's *possible* they could
> be telling the truth, and I have no proof otherwise, regardless of any
> suspicions.

At least as far as I have understood things, the 3D hardware in the old
SGIs was very simple.  Lots and lots of multiple and add units which the
drivers then used in clever ways to implement fast 3D.  nvidia certainly
employs many ex-SGI people, so perhaps internally it is still based on
that idea, although I doubt it's quite that simple anymore.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /proc/cpuinfo format - arch dependent!

[Lennart Sorensen]

On Tue, Apr 19, 2005 at 10:00:12PM +0200, Nico Schottelius wrote:
> Can you tell me which ones?

top for example would probably break.  Maybe not but I suspect it would.
mplayer probably would since it uses it to find the cpu type and
features that cpu supports.

> And if there are really that many tools, which are dependent on
> those information, wouldn't it be much more senseful to make
> it (as far as possible) the same?

Well the tools that care are often architecture specific.  After all the
info in cpuinfo is very architecture specific.

> I must say I was really impressed, how easy I got the number of
> cpus on *BSD (I am not a bsd user, still impressed).

Well there still is that sysconf call to get the number of cpus, which
is way better in C than parsing a text file to get the info as far as I
am concerned.

> They also have the same format on every arch and mostly the same
> between different bsds (as far as I have seen).

What info do they provide in that on BSD?

> In general, where are the advantages of having very different cpuinfo
> formats? Tools would need to know less about the arch and could
> depend on "I am on Linux" only.

The info in cpuinfo is only of interest to a tool that knows about the
architecture it is on.

It is not meant to look up the number of cpus the system has.  It is
meant to provide the info about the cpus in the system, which means it
provides info relevant to the cpu on a given architecture.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 violation by CorAccess?

[Lennart Sorensen]

On Tue, Apr 19, 2005 at 05:57:43PM +, Karel Kulhavy wrote:
> I have seen a device by CorAccess which apparently uses Linux and didn't find
> anything that would suggest it complies to GPL, though I had access to the
> complete shipping package. Does anyone know about known cause of violation by
> this company or should I investigate further?

Well what is the case if you use unmodified GPL code, do you still have
to provide sources to the end user if you give them binaries?  I would
guess yes, but IANAL.

As far as I can tell their system is a geode GX1 so runs standard x86
software.  Maybe they didn't have to modify any of the linux kernel to
run what they needed.  Their applications are their business of course.
It looks like they use QT as the gui toolkit, which I don't off hand
know the current license conditions of.  Then there is the web browser
and such, which has it's own license conditions.  Of course for all I
know their user manual has an offer of sending a CD with the sources if
you ask.  Does anyone actually have their product that could check for
that?

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /proc/cpuinfo format - arch dependent!

[Lennart Sorensen]

On Tue, Apr 19, 2005 at 02:15:30PM +0200, Nico Schottelius wrote:
> When I wrote schwanz3(*) for fun, I noticed /proc/cpuinfo
> varies very much on different architectures.
> 
> Is it possible to make it look more identical (as far as the different
> archs allow it)?
> 
> So that one at least can count the cpus on every system the same way.
> 
> If so, who would the one I should contact and who would accept / verify
> a patch doing that?

If you change it now, how many tools would break?

Maybe if you can list what statistics you think should be common to all
systems, that could be presented in another file that is always the same
format on each architecture.

Certainly looking at arm and i386, other than the bogomips field there
is nothing in common between their cpuinfo contents.  THey don't even
capitalize bogomips the same either.

I doubt this is really doable.  If all you want is the number of CPUs
then something like sysconf(_SC_NPROCESSORS_CONF) should do.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: DVD writer and IDE support (solved)...

[Lennart Sorensen]

On Sat, Apr 16, 2005 at 08:26:38PM +0200, [EMAIL PROTECTED] wrote:
> Through a very painful procedure I got w98 installed and bumped my 
> firmware revision. The filename of the installation binary was 
> duw1608_r108.exe suggesting R1.08 but the windows screen mentioned
> that the bumping was from 060 to 080 or thereabouts...
> 
> At any rate, now everything seems to work as it should, using the 
> ide-cd driver. That you all for the help!

Sounds like you had 1.06 and went to 1.08 and that solved the problem.
Always nice when companies fix their firmware bugs. :)

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Rootkits

[Lennart Sorensen]

On Fri, Apr 15, 2005 at 06:15:37PM +, Allison wrote:
> I got the terminology mixed up. I guess what I really want to know is,
> what are the different types of exploits by which rootkits
> (specifically the ones that modify the kernel) can get installed on
> your system.(other than buffer overflow and somebody stealing the root
> password)
> 
> I know that SucKIT is a rootkit that gets loaded as a kernel module
> and adds new system calls. Some other rootkits change machine
> instructions in several kernel functions.
> 
> Once these are loaded into the kernel, is there no way the kernel
> functions can be protected ?

Well you could build a monilithic kernel with module loading turned off
entirely, but that doesn't prevent replacing libc which most programs
use to make those system calls.  Could make the filesystem readonly,
that would prevent writing a module to load into the kernel, and
replacing libc as long as you make it imposible to remount the
filesystem at all.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: DVD writer and IDE support...

[Lennart Sorensen]

On Thu, Apr 14, 2005 at 06:25:39PM +0200, [EMAIL PROTECTED] wrote:
> > On Thu, Apr 14, 2005 at 03:35:22PM +0200, [EMAIL PROTECTED] wrote:
> > Well there is a cdwrite mailing list hosted on lists.debian.org which is
> > a great place to figure out what weird errors are and such, and the
> > authors of the programs used for writing discs are on thoses lists too,
> > so you may want to ask for advice there.
> > 
> Thanks, I'll get myself onto that list...
> 
> > Did you try writing using ide-scsi mode with growisofs ?  Any
> > difference?  Does dvd+rw-media return anything with a disc in the drive?
> > 
> With this array of modules:
> sg 34112  0 
> sr_mod 17700  0 
> ide_scsi   15556  0 
> scsi_mod  126952  3 sg,sr_mod,ide_scsi
> ide_cd 40004  0 
> 
> Where ide_cd was told to ignore hdc (inspired from the dvd+rw-tools 
> web), I got this:
> tippex root # dvd+rw-mediainfo /dev/sr0
> INQUIRY:[AOPEN   ][DUW1608/ARR ][A060]
> GET [CURRENT] CONFIGURATION:
>  Mounted Media: 14h, DVD-RW Sequential
>  Multi-session Info:[EMAIL PROTECTED]
[snip]
> READ CAPACITY:  2298496*2048=4707319808
> 
> Not sure what it says, but I see one sesssion there. I guess that's 
> from my previos burn attempt. I seemed to be successful with:

Well that looks normal at least.

> tippex root # dvd+rw-format -blank /dev/sr0
> * DVD?RW/-RAM format utility by <[EMAIL PROTECTED]>, version 4.10.
> * 4.7GB DVD-RW media in Sequential mode detected.
> * blanking |
> 
> No errors reported! Now I get:
> tippex root # dvd+rw-mediainfo /dev/sr0
> INQUIRY:[AOPEN   ][DUW1608/ARR ][A060]
> GET [CURRENT] CONFIGURATION:
>  Mounted Media: 14h, DVD-RW Sequential
>  Media ID:  CMCW02  
[snip]
>  Next Writable Address: 0*2KB
>  Free Blocks:   2297888*2KB
>  Track Size:2297888*2KB
> READ CAPACITY:  1*2048=2048

And so does that.

> ... which seems consistent with expectations. Now another try with 
> the burner:
> tippex root # growisofs -Z /dev/sr0 -R -J /tmp/quilt-0.32/
> Executing 'mkisofs -R -J /tmp/quilt-0.32/ | builtin_dd of=/dev/sr0 obs=32k 
> seek=0'
> Using SNAPS000.TES;1 for  /tmp/quilt-0.32/test/snapshot.test (snapshot2.test)
> /dev/sr0: FEATURE 21h is not on, engaging DAO...
> /dev/sr0: reserving 432 block, warning for short DAO recording
> /dev/sr0: "Current Write Speed" is 2.0x1385KBps.
> :-( unable to [EMAIL PROTECTED]: Input/output error
> :-( attempt to re-run with -dvd-compat -dvd-compat to engage DAO or apply 
> full blanking procedure
> :-( write failed: Input/output error
> 
> and the kernel log has:
> Apr 14 18:12:54 tippex hdc: DMA timeout retry
> Apr 14 18:12:54 tippex hdc: timeout waiting for DMA
> Apr 14 18:12:54 tippex hdc: ATAPI reset complete
> Apr 14 18:13:14 tippex scsi: Device offlined - not ready after error 
> recovery: host 0 channel 0 id 8 lun 0
> Apr 14 18:13:14 tippex SCSI error : <0 0 8 0> return code = 0x600
> Apr 14 18:13:14 tippex scsi0 (8:0): rejecting I/O to offline device

Maybe try growisofs -dvd-compat -dvd-compat -Z /dev/sr0  like it suggested.
Maybe the drive's firmware doesn't support the modes normally expected
by growisofs.

growisofs has some odd options in the source code, and the authors on
the cdwrite list may be able to help.  I think it is starting to look
like bad firmware or a defective drive.

> 
> Yep. I get the feeling my media and the drive as-is don't like each
> other. What are the chances that the device is faulty but i can still 
> blank the media (btw where can I read up on blanking vs. formating?)

Well I am not sure it's the media either.  I think the drive isn't quite
up to the specs growisofs expects.  The authors may be better able to
answer that.  They also have some tools they may ask you to run to ask
the drive what features it has so they can see if the drive is a bit odd
or not.

> Starting to seem like a wise choice...

I got the PX716A a few weeks ago while they had a $30 mail in rebate.
Made it not much more than buying a lesser drive.  Unfortuantely that
expired at the end of March.

On the other hand, not having to run around trying weird things,
wondering if my media is bad, I just burn discs.  Sometimes it burns 8x
media at 2x if it doesn't think they are high enough quality, but it
burns them right each time.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: DVD writer and IDE support...

[Lennart Sorensen]

On Thu, Apr 14, 2005 at 12:02:14PM -0300, Jeremy Muise wrote:
> > > It's an AOPEN  DUW1608/ARR
> I just thought I should chime in because I have the same burner running
> under a 2.6.11 kernel, and using ide-cd. The drive burns just fine, linux
> support was good, but I did run into two problems:
> 1) I had to shop around till I found a brand of DVD-R (I haven't tried RW yet)
> that would work, finally settled on TDK.
> 2) it failed to write to slower media, I think anything below 4 it had
> trouble with

So it is a very picky drive, or the firmware is still in need of fixes
(I saw at least 4 firmware updates each adding improved media
compatibility, so perhaps it is something they are working on).

Perhaps not the best writer around, but I bet the price is nice.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: DVD writer and IDE support...

[Lennart Sorensen]

On Thu, Apr 14, 2005 at 03:35:22PM +0200, [EMAIL PROTECTED] wrote:
> It's an AOPEN  DUW1608/ARR 
> http://usa.aopen.com/products/dvd+rw/DUW1608ARR.htm
> 
> Should I consider changing it? (I got an 'if this doesn't run on Linux 
> I can trade it in' warranty at the shop)

Well there is a cdwrite mailing list hosted on lists.debian.org which is
a great place to figure out what weird errors are and such, and the
authors of the programs used for writing discs are on thoses lists too,
so you may want to ask for advice there.

Did you try writing using ide-scsi mode with growisofs ?  Any
difference?  Does dvd+rw-media return anything with a disc in the drive?

> I noticed a firmware upgrade on the web page (.exe) will try to get a 
> dos disk running... Sigh...

It might require windows.  Certainly their firmware updates mostly seem
to cover 'improved media coverage'.

I have only been buying the plextor drives personally, since I have
never had a problem with a plextor drive yet, and I like not needing
windows to update the firmware and I find I save time by spending a bit
more on getting the best hardware I can reasonably afford.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: DVD writer and IDE support...

[Lennart Sorensen]

On Wed, Apr 13, 2005 at 10:59:49PM +0200, [EMAIL PROTECTED] wrote:
> Nope. No go. The kernel log getsb these 4 lines:
> Apr 13 22:08:30 tippex SCSI error : <0 0 0 0> return code = 0x802
> Apr 13 22:08:30 tippex sr0: Current: sense key: Medium Error
> Apr 13 22:08:36 tippex SCSI error : <0 0 0 0> return code = 0x802
> Apr 13 22:08:36 tippex sr0: Current: sense key: Medium Error
> 
> and the application bails out with:
> :-[ [EMAIL PROTECTED] failed with SK=5h/ASC=30h/ACQ=05h]: Wrong medium type
> :-( media is not formatted or unsupported.
> :-( write failed: Wrong medium type
> 
> This is with a fresh from the box DVD-RW. Do I need to 'format' the
> thing before writing to it? This is getting tricky... Are these kind
> of errors normally indicative of lack of support or a faulty unit?
> I have no windows around to test it with the shipped nero-cd :-(

What brand/model drive is this?

It is possible to get very weird errors if you have unsupported media in
the drive and some drives don't like certain media types.  Sometimes a
firmware update on the drive fixes it although it usually requires
windows (or sometimes dos) to install the update (or linux will do if
the drive is a plextor).

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: DVD writer and IDE support...

[Lennart Sorensen]

On Wed, Apr 13, 2005 at 09:07:56PM +0200, [EMAIL PROTECTED] wrote:
> It's with 2.6.11.7

Probably close to the 2.6.11 kernel I run on Debian-pure64/sarge.

> Dunno yet. What's the fastest way to dump a file to a (fs on) a blank 
> 4.7 GB DVD RW? As I said this is not my home turf so I have to read 
> up on the commands to use (I guess I'm not dd'ing an iso image to 
> /dev/hdc...)

growisofs -Z /dev/hdc -J -R /path/to/dir/with/less/than/4.5GB/of/files

That should do it.  To do scsi I suspect it would be /dev/sg0 or
/dev/scd0.  I haven't actually tried burning in scsi emulation mode with
these drives.

growisofs is part of dvd+rw-tools.  It will autoformat the disc if
needed.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: DVD writer and IDE support...

[Lennart Sorensen]

On Wed, Apr 13, 2005 at 08:14:21PM +0200, [EMAIL PROTECTED] wrote:
> I've just gotten myself a new DVD burner which triggers some 
> interesting events in the kernel. From the log:
> 
> hdc: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.20
> hdc: packet command error: status=0x51 { DriveReady SeekComplete Error }
> hdc: packet command error: error=0x40 { LastFailedSense=0x04 }
> ide: failed opcode was: unknown
> ATAPI device hdc:
>   Error: Hardware error -- (Sense key=0x04)
>   Focus servo failure -- (asc=0x09, ascq=0x02)
>   The failed "Read Cd/Dvd Capacity" packet command was: 
>   "25 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "

Well certainly something appears to go wrong.  So far I have used a dvd
writer (PX708A and PX716A) on kernels up to 2.6.10 (i386) and 2.6.11
(amd64) and had no problems using ide-cd to do the burning (writing
DVDs using growisofs of course, and CDs using cdrecord).

> rmmod'ing the icd-cd module and modprob'ing the ide-scsi (seeing as 
> that used to be the common approach for folks (I'm new to burners...))
> I got this in the log:
> 
> ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as 
> device
> scsi0 : SCSI host adapter emulation for IDE ATAPI devices
>   Vendor: AOPEN Model: DUW1608/ARR   Rev: A060
>   Type:   CD-ROM ANSI SCSI revision: 02
> sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray
> Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
> 
> How should I interprete this? That the device is not supported under
> the icd-cd module but the scsi support detects and supports it ok?
> I've not tried to burn anything with it yet so I have no hard facts on
> if there is enough support (yet).
> 
> If there is any sort of data which need to be shipped somewhere to 
> make this device supported by ide-cd, I'd be glad to help...

Well it does look odd that it loads with one and not the other.  Which
kernel is this with?

Does writing CDs and DVDs actually work using ide-scsi?  Does it work
using ide-cd?

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Exploit in 2.6 kernels

[Lennart Sorensen]

On Wed, Apr 13, 2005 at 09:26:28AM -0500, Eric Rannaud wrote:
> On Wed, 2005-04-13 at 09:02 -0400, Lennart Sorensen wrote:
> > modprobe nvidia || m-a -t prepare nvidia && m-a -t build nvidia && m-a -t 
> > install nvidia && modprobe nvidia
> 
> Something along the lines of:
> modprobe nvidia || sh NVIDIA-Linux-x86-1.0-6629-pkg1.run -s -f --no-network 
> && modprobe nvidia
> 
> should work on any distribution (it runs NVIDIA installer silently).
> (see sh NVIDIA-Linux-x86-1.0-6629-pkg1.run --advanced-options)

It will work on most.  Some don't like where the nvidia installer dumps
it files in some cases.  Certainly doesn't work on every amd64 system
since they can't agree where 64bit libs should go yet.

It also violates my principles more than using binary only drivers does.
All files in /usr (except /usr/local) _must_ be installed by one package
management tool.  No excaptions allowed.  I haven't had to reinstall for
6 years, so I am sticking with my principles.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Exploit in 2.6 kernels

[Lennart Sorensen]

On Wed, Apr 13, 2005 at 03:06:46PM +0200, Lars Marowsky-Bree wrote:
> On 2005-04-13T08:59:21, Lennart Sorensen <[EMAIL PROTECTED]> wrote:
> 
> > It is becoming harder and harder to find supported cards it seems.
> > Finding a card with decent 2D drivers for X can still be done, but 3D is
> > just not really an option it seems.  Even 2D seems to be a problem on
> > many cards if you don't use a binary only driver.
> 
> You are confusing the cause with the symptom.

Graphics card companies don't realize they are hardware companies not
software companies and that it is hardware they make their money from?
Oh and they have too many lawyers?

It seems to me that 2D graphics are a done deal, with no new inovation
taking place.  Releasing programing specs for that part should be a no
brainer.  If the nifty 3D routines are so important to keep secret from
the other guys then well keep those.  Release the 2D programing specs!

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Exploit in 2.6 kernels

[Lennart Sorensen]

On Tue, Apr 12, 2005 at 10:32:59PM +0100, John M Collins wrote:
> I'll do that - trouble is round where I am they dish out Nvidia cards
> like confetti, I've got them in the machine I use most and another 2 and
> you have to do all that gyrating with running the script to FTP down and
> build the secret module before you can run X. This is a big disincentive
> when it comes to installing new kernels.
> 
> I wish some kind soul would speak nicely to Nvidia and get them to see
> reason on the point but I suspect I'm not the first person to wish that.
> (Or is there a sneaky way of patching the modules so they'll work in
> another kernel without tainting it?).

Well on my ssytem I can do something as simple as this in a script at
boot (before starting X) and it should nicely take care of it:

modprobe nvidia || m-a -t prepare nvidia && m-a -t build nvidia && m-a -t 
install nvidia && modprobe nvidia

Most likely I will have a working loaded nvidia driver at that point and
X will start successfully.

m-a is module-assistant which is used on debian to build a module
mathcing the running kernel (assuming it has access to either the source
of the running kernel or the headers of the running kernel) using the
sources from in this case nvidia-kernel-source package.  I don't know if
anything other than debian has anything like this, but it makes dealing
with nvidia's binary drivers fairly tolerable.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Exploit in 2.6 kernels

[Lennart Sorensen]

On Wed, Apr 13, 2005 at 11:47:46AM +0200, Helge Hafting wrote:
> You're not.  Complain to nvidia - using both email and snailmail.
> If everybody with such problems did that, chances are they see
> the light someday. Oh, and complain to the guy handing out
> nvidia cards like confetti, state your preference for some other
> card.  Perhaps that is easier to achieve.

What card would you recomend to people?

> Whats wrong with tainting?  It is just a message, telling you that
> the kernel is unsupported.  In this case because you're running a
> closed-source module.  The tainting message itself does not do
> anything bad.  There is a way - which is to write an open nvidia
> driver.  To do that, you'll need to get the specs out of nvidia or
> figure it out by reverse-engineering some other nvidia driver. Either
> approach is hard, so people generally find it cheaper to just buy
> a supported card.

It is becoming harder and harder to find supported cards it seems.
Finding a card with decent 2D drivers for X can still be done, but 3D is
just not really an option it seems.  Even 2D seems to be a problem on
many cards if you don't use a binary only driver.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How's the nforce4 support in Linux?

[Lennart Sorensen]

On Wed, Mar 30, 2005 at 05:00:23PM +0200, Tomasz Torcz wrote:
>  It an glaring example, dmix is unsufficient in one third of my sound
> uses (other two beeing movie and music playback)
>  But you advertise dmix like it was silver bullet.

An emu10k1 is a silver bullet. :)

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [OT] Re: How's the nforce4 support in Linux?

[Lennart Sorensen]

On Thu, Mar 24, 2005 at 10:33:03AM +, Asfand Yar Qazi wrote:
> No, but I do need NCQ

Perhaps a stupid question... but: Why do you _need_ NCQ?  If you need it
that badly (not sure why anyone would), you could always get SCSI or a
3ware controller.

NCQ is a nice feature, but hardly essential.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How's the nforce4 support in Linux?

[Lennart Sorensen]

On Thu, Mar 24, 2005 at 10:00:46AM +, Asfand Yar Qazi wrote:
> http://www.neoseeker.com/Articles/Hardware/Previews/nvnforce4/3.html
> 
> You're right there - some semi-hardware support combined with drivers 
> apparently result in lower CPU usage that software firewalls.  Apparently.
> 
> Actually, these people like it:
> http://www.bjorn3d.com/read.php?cID=712&pageID=1096
> 
> However one feature that you can't laugh at is the fact that it can be 
> made to block packets in the span of time between the OS being loaded 
> up, and the "real" firewall coming up.  This small time span 
> theoretically leaves the PC vulnerable, so I think this is the only 
> use for "ActiveAmor Firewall".

Until the OS loads network drivers AND configures IP support AND starts
accepting packets in, there is nothing for the firewall to do.
Certainly on Linux I can make sure iptables is populated (or least has a
sane policy set) before I bring up networking.  In other words: "Who
cares".

> However, this doesn't answer my original question (which I suppose I 
> should have made clearer): can I get SATA II NCQ support in Linux with 
> an nForce 4 chipset?

Don't know.  I think 3ware's controllers do their own NCQ, which is
pretty neat.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How's the nforce4 support in Linux?

[Lennart Sorensen]

On Thu, Mar 24, 2005 at 04:30:32AM -0500, Jeff Garzik wrote:
> Well, let's cut through the B.S. ;-)
> 
> * Even when the SATA core is updated to support NCQ, nForce will not
> support it under Linux.  No hardware info.

Hmm, either that or someone will figure it out anyhow, like they did
with forcedeth.  Would be nice if nvidia would realize just how dumb not
releasing programing specs is.  How can that be considered a secret.
Maybe they just have a company wide policy of "release nothing" rather
than "don't release the clever 3D acceleration in our drivers that ATI
can't have".  Some comapnies just don't seem to realize they are in the
business of _selling_ hardware, not hardware interface specifications.

> * "hardware firewall" -- sounds silly.  Pretty sure Linux doesn't support
> it in any case.
> 
> * overclocking -- overclockers are always playing with fire.  any
> overclocked hardware is suspect and unsupportable.
> 
> * via comes with gigabit lan these days.  My own VIA-based Athlon64
> system comes with r8169 gigabit.

I think the r8139 has ruined realtek for me forever.  I like the Marvell
Yukon chip Asus includes on many boards (although some people have
reported problems with some Asus boards using them with Linux).

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [SATA] sata-via : bug?

[Lennart Sorensen]

On Mon, Mar 21, 2005 at 04:18:16PM -0600, Jay Roplekar wrote:
> I  have  a brand new Western Digital sata drive, VIA KT600  based ECS 
> motherboard on which I am trying to install various distros (with installers 
> based on 2.4.26, 2.6.7, 2.6.8, 2.6.11 etc)  all of them fail to detect the HD 
> (and bomb out) because sata-via is ignoring it .  I have only one disk, I am 
> not interested in raid.
>  
>  lspci which tells me it is VIA 6420 and should be  supported based on 
> sata-via.c.   Following are syslog snippets that show more.
> I would appreciate your help in resolving this. Thanks,
> 
> Jay
> ##
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge (prog-if 00 
> [Normal decode])
> Flags: bus master, 66Mhz, medium devsel, latency 0
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: a000-afff
> Memory behind bridge: e000-e1ff
> Prefetchable memory behind bridge: d800-dfff
> Capabilities: [80] Power Management version 2
> 
> 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID 
> Controller (rev 80)
> Subsystem: Elitegroup Computer Systems: Unknown device 1884
> Flags: bus master, medium devsel, latency 32, IRQ 11
> I/O ports at b000 [size=8]
> I/O ports at b400 [size=4]
> I/O ports at b800 [size=8]
> I/O ports at bc00 [size=4]
> I/O ports at c000 [size=16]
> I/O ports at c400 [size=256]
> Capabilities: [c0] Power Management version 2
> 
> ##Dmesg when I connect the disk on channel 1
> libata version 1.10 loaded.
> sata_via version 1.1
> ACPI: PCI interrupt :00:0f.0[B] -> GSI 11 (level, low) -> IRQ 11
> sata_via(:00:0f.0): routed to hard irq line 11
> ata1: SATA max UDMA/133 cmd 0xB000 ctl 0xB402 bmdma 0xC000 irq 11
> ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xBC02 bmdma 0xC008 irq 11
> ata1: dev 0 cfg 49:3030 82:0078 83:0078 84: 85: 86:3fff 87:0010 
> 88:000f
> ata1: no dma/lba
> ata1: dev 0 not supported, ignoring
> scsi0 : sata_via
> ata2: no device found (phy stat )
> scsi1 : sata_via
> ##with disk on second channel following
> ata1: no device found (phy stat )
> scsi0 : sata_via
> ata2: dev 0 cfg 49:3030 82:0078 83:0078 84:0078 85: 86: 87: 
> 88:
> ata2: no dma/lba
> ata2: dev 0 not supported, ignoring
> scsi1 : sata_via
> ## I took this disk and sata cable on a different (ICH5 based) motherboard 
> and 
> ## knoppix detected the disk ok and associated sda with it. 

Any modes in the bios for the SATA ports?  Maybe it is in a mode not
supported by linux.  I know the ICH5 only wanted to work for me in
native (enhanced?) mode, not compatible (emulating PATA) mode.  Maybe
via does something similar.  I am puzzles by the UDMA/133 message which
makes no sense for SATA which should be 150 or 300 not 133.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] DM9000 network driver

[Lennart Sorensen]

On Fri, Mar 18, 2005 at 08:41:52PM +0530, Hong Kong Phoey wrote:
> Sacrificing readibility a little bit, you could do something useful.
> Instead of those ugly switch statements you could define function
> pointer arrays and call appropriate function
> 
> switch(foo) {
> 
>   case 1:
>  f1();
>   case2 :
>  f2();
> };
> 
> could well become
> 
> void (*func)[] = { f1, f2 };
> 
> func(i);

Ewww!

How about sticking with obvious readable code rather than trying to save
a couple of conditional branches.  If it is an obvious good
optimization, let the compiler do it.  of course if you ever needed to
pass different parameters to f1 and/or f2 it would have to be rewritten
back to the original again.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Devices/Partitions over 2TB

[Lennart Sorensen]

On Wed, Mar 16, 2005 at 12:16:57PM +, Stephen C. Tweedie wrote:
> For LVM, the lvm2 package contains all the necessary tools.  I know
> Alasdair did some kernel fixes for lvm2 striping on >2TB partitions
> recently, though, so older kernels might not work perfectly if you're
> using stripes.
> 
> To use genuine partitions > 2TB, though, you need alternative
> partitioning; the GPT disk label supports that, and "parted" can create
> and partition such disk labels.  (Note that most x86 BIOSes can't boot
> off them, though, so don't do this on your boot disk!)

Does the BIOS actually support partitions in general?  I thought that
was a problem for the code in the MBR.  As long as your bootcode in the
MBR supports whatever partition scheme you come up with, I can't see how
it should be a problem, but maybe I am missing something.  So what does
GRUB/LILO support?

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Support for GEODE CPUs

[Lennart Sorensen]

On Fri, Mar 11, 2005 at 11:02:33AM +, Alan Cox wrote:
> Either revert it or make it Geode GX and correct the options set. I've
> no problem with a Geode option that sets the right options 8)

Maybe it should say GX1 unless someone is sure the GX1 and GX2 (now GX
[EMAIL PROTECTED] it seems) like the same optimizations.  The SCx200 could go in
the help text to clarify that those too are GX1 based.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: binary drivers and development

[Lennart Sorensen]

On Thu, Mar 10, 2005 at 12:24:15PM -0500, John Richard Moser wrote:
> I've done more thought, here's a small list of advantages on using
> binary drivers, specifically considering UDI.  You can consider a
> different implementation for binary drivers as well, with most of the
> same advantages.
> 
>  - Smaller kernel tree
>The kernel tree would no longer contain all of the drivers; they'd
>slowly have to bleed into UDI until most were there

Users would have to go hunting for drivers to add to their kernel to get
hardware supported.  Making a CD with a kernel and drivers for a wide
variety of hardware would be a nightmare.

>  - Better focused development
>The kernel's core would be the core.  Driver code would be isolated,
>so work on the kernel would affect the kernel only and not any
>drivers.  UDI is a standard interface that shouldn't be broken.  This
>means that work on the high-level drivers will not need to be sanity
>checked a thousand times against the PCI Bus interface or the USB
>host controler API or whatnot.

But anything that runs in kernel memory space can still go trampling on
memory in the kernel by accident and is very difficult to debug without
the sources.

>  - Faster rebuilding for developers
>The isolation between drivers and core would make rebuilding involve
>the particular component (driver, core).  A "broken driver" would
>just require recoding and rebuilding the driver; a "broken kernel"
>would require building pretty much a skeletal core

That can already be done basicly.  The makefiles work just fine for
rebuilding only what has changed in general.

>  - UDI supplies SMP safety
>The UDI page brags[1]:
> 
>"An advanced scheduling model. Multiple driver instances can be run
> in parallel on multiple processors with no lock management performed
> by the driver. Free paralllism and scalability!"
> 
>Drivers can be considered SMP safe, apparently.  Inside the same
>driver, however, I have my doubts; I can see a driver maintaining a
>linked list that needs to be locked during insertions or deletions,
>which needs lock managment for the driver.  Still, no consideration
>for anything outside the driver need be made, apparently.
>  - Vendor drivers and religious issues
>Vendors can supply third party drivers until there are open source
>alternatives, since they have this religious thing where they don't
>want people to see their driver code, which is kind of annoying and
>impedes progress

I imagine a driver writer could still easily do something not SMP safe,
but I don't know that for sure.  It sounds like a very complex thing to
promise a perfect solution for.

> Disadvantages:
> 
>  - Preemption
>Is it still possible to implement a soft realtime kernel that
>responds to interrupts quickly?
>  - Performance
>UDI's developers claim that the performance overhead is negligible.
>It's still added work, but it remains to be seen if it's significant
>enough to degrade performance.
>  - Religious battles
>People have this religious thing about binary drivers, which is kind
>of annoying and impedes progress

Many of the disadvantages are a good reason why they have these opinions
on binary drivers.  They do impede getting work done if you have to use
them on your system and something isn't working right.

>  - Constriction
>This would of course create an abstraction layer that constricts the
>driver developer's ability to do low level complex operations for any
>portable binary driver

You forgot the very important:
   - Only works on architecture it was compiled for.  So anyone not
 using i386 (and maybe later x86-64) is simply out of luck.  What do
 nvidia users that want accelerated nvidia drivers for X DRI do
 right now if they have a powerpc or a sparc or an alpha?  How about
 porting Linux to a new architecture.  With binary drivers you now
 start out with no drivers on the new architecture except for the
 ones you have source for.  Not very productive.

[snip]

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Support for GEODE CPUs

[Lennart Sorensen]

On Wed, Mar 09, 2005 at 09:59:26PM +, Alan Cox wrote:
> If you build 486 it will still use the TSC because it is available (The
> PIT is buggy but the kernel knows about that anyway and handles it). 

Hmm, I thought that was the whole point of the different cpu type
choices in the kernel.  Then again the MTRR is still available with a
386 kernel on a newer cpu as far as I remember, so I guess I will try a
486 optimized kernel next.

> There are a few Geode tricks to know for performance
> 
> - Turn off the video

That is the plan long term, although the BIOS's serial console doesn't
seem to work well with grub at least on minicom.  I think switching to
lilo may help that.

> - If you can't turn it off use solid areas of colour to speed the system
> up (The hardware uses RLE encoding to reduce ram fetch bandwidth)
> - Remember the cache is only 16K (12K when running X11 as 4K is borrowed
> for the blitter)

Even more reason to keep the video off (I think it steals some system
ram when on as well).

> - The onboard audio is a software SB emulation on older GX. It burns
> CPU.

I have audio disabled since I have no need for it.

> Also avoid touching various legacy registers as much as possible, many
> cause BIOS traps in SMM emulation code. The list I have is NDA but you
> can use rdtsc/inb or outb/rdtsc to work out which 8)

Only PCI and LPC devices in use, so I don't think I will be poking any
legacy registers directly, although I have no idea if the kernel would
be poking any of them as part of running the drivers.  Hopefully not.

Thanks for the information.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Support for GEODE CPUs

[Lennart Sorensen]

On Wed, Mar 09, 2005 at 05:01:09PM +, Alan Cox wrote:
[snip]
> And I have each time pointed out it is wrong over time because
> 
> a) "Geode" (Geode GX) runs -m486 code faster than -m586
> b) "Geode" as a name also includes AMD Athlon "Geode NX" processors
> c) Geode GX does not need OOSTORE because the processor manages DMA
> snooping in hardware.

It even looks to me like the Geode GX1 (SCx200 family) is a Cyrix MediaGX
design, the Geode GX2 (Geode GX [EMAIL PROTECTED] and company) I suspect is an
AMD k6 based design (given the 400Mhz speed, and the inclusion of 3Dnow
and MMX), and of course the Geode NX is athlon based.

Now if the Geode GX1 in fact runs faster optimized for 486 rather than
586 (I have been running one as 586tsc since it had mmx and tsc in its
feature list), then I think I will be recompiling my kernel to see if I
can't make this 266MHz GX1 run almost as fast as a 400MHz PXA255 (arm).
Right now it has somewhat lower ethernet bandwidth than the arm.

Len Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device

[Lennart Sorensen]

On Tue, Feb 15, 2005 at 08:48:13PM +0100, Kiniger, Karl (GE Healthcare) wrote:
> I can confirm that. Creating a correct  iso image from a CD is a
> major pain w/o ide-scsi. Depending on what one has done before the iso
> image is missing some data at the end most of the time.
> (paired with lots of kernel error messages)
> 
> Testing was done here using Joerg Schilling's sdd:
> 
> sdd ivsize=`isosize /dev/cdxxx` if=/dev/cdxxx of=/dev/null \
>   bs=
> 
> and most of the time it results in bad iso images

I have only ever used his readcd program for doing such things.  It has
been so long I can't even remember if it was using ide-scsi or ide-cd.

For burning I use ide-cd with cdrecord and growisofs, and so far it has
worked great.  Flashing firmware on the plextor still requires ide-scsi
though.

Lennart Sorensen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Banging my head on SATA / ATAPI DMA problem. Help?

[Lennart Sorensen]

On Tue, Jan 25, 2005 at 07:57:58PM -0800, Rick Bressler wrote:
> I've played with a lot of hardware since the Linux 1.0.9 days but not
> yet run into something quite like this.  Alan has been talking a lot
> lately about ATA/SATA patches, and while I mostly lurk on this list,
> thought this one might be interesting enough for somebody to give me
> some advice.
> 
> A friend of mine won an IBM 8482-2RU at Linux World last year and he is
> trying to get it working with a 2.6.x kernel.
> 
> The problem I'm unable to resolve is that his primary drive, a Seagate
> ST3160023AS (SATA) works fine in DMA mode, but whenever it is plugged
> in, he can't get his PLEXTOR PX-716A DVD/CD-RW (PATA) to come up in DMA
> mode.  (Works in PIO mode.)
> 
> At first I was wondering if it wasn't a BIOS setting (legacy mode ATA
> etc) but he swears he can't find anything like that in his BIOS.  (He's
> on the latest BIOS that IBM has for the box.)
> 
> He's in California and I'm in Washington so I have to take his word for
> it.
> 
> hdparm says the DVD/CD can do DMA, and in theory is being configured by the
> BIOS
> 
>   DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4
> 
> The kernel doesn't detect it.  It can't be turned on manually with
> hdparm.  If the hard drive is unplugged, I note that it is recognizes
> the CD as as being on an ICH5 chipset, but it doesn't seem to identify
> it as such with the hard drive plugged in.  Odd hardware?  Strange
> hardware detection?  Something subtle in the kernel config that I keep
> missing?  (BLK_DEV_PIIX is turned on.)
> 
> Both drives come up DMA on 2.4.x (no libata). but no 2.6 kernel we've
> tried (2.6.6, 2.6.9, 2.6.10 2.6.10-ac10) seems to be able to manage it.
> 
> I've been working with him for a couple of weeks, but have exhausted my
> luck on Google, list archives etc. and decided it is time to see if
> anybody can give me some ideas on how to proceed.  Maybe it is just
> flakey hardware...
> 
> Any help, pointers or suggestions  that you may care to offer would be
> appreciated.
> 
> I monitor the list (in nightly batch mode) so feel free to reply any way
> you like, list or email...
> 
> Thanks in advance.
> 
> His PCI layout:
> 
> # lspci
> :00:00.0 Host bridge: Intel Corp. 82875P/E7210 Memory Controller Hub (rev 
> 02)
> :00:03.0 PCI bridge: Intel Corp. 82875P/E7210 Processor to PCI to CSA 
> Bridge (rev 02)
> :00:1c.0 PCI bridge: Intel Corp. 6300ESB 64-bit PCI-X Bridge (rev 02)
> :00:1d.0 USB Controller: Intel Corp. 6300ESB USB Universal Host 
> Controller (rev 02)
> :00:1d.1 USB Controller: Intel Corp. 6300ESB USB Universal Host 
> Controller (rev 02)
> :00:1d.4 System peripheral: Intel Corp. 6300ESB Watchdog Timer (rev 02)
> :00:1d.5 PIC: Intel Corp. 6300ESB I/O Advanced Programmable Interrupt 
> Controller (rev 02)
> :00:1d.7 USB Controller: Intel Corp. 6300ESB USB2 Enhanced Host 
> Controller (rev 02)
> :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 0a)
> :00:1f.0 ISA bridge: Intel Corp. 6300ESB LPC Interface Controller (rev 02)
> :00:1f.2 IDE interface: Intel Corp. 6300ESB SATA Storage Controller (rev 
> 02)
> :00:1f.3 SMBus: Intel Corp. 6300ESB SMBus Controller (rev 02)
> :02:01.0 Ethernet controller: Intel Corp. 82547GI Gigabit Ethernet 
> Controller
> :03:04.0 SCSI storage controller: Adaptec AIC-7901 U320 (rev 10)
> :04:02.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY 
> [Radeon 7000/VE]
> :04:08.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 
> 10)
> 
> A boot from a Knoppix CD with the hard drive unplugged yielded a working
> DMA enabled CDROM with a 2.6.9 kernel.
> 
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ICH5: IDE controller at PCI slot :00:1f.1
> ACPI: PCI interrupt :00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
> ICH5: chipset revision 2
> ICH5: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0x1460-0x1467, BIOS settings: hda:DMA, hdb:pio
> ide1: BM-DMA at 0x1468-0x146f, BIOS settings: hdc:pio, hdd:pio
> Probing IDE interface ide0...
> hda: PLEXTOR DVDR PX-716A, ATAPI CD/DVD-ROM drive

Above the piix drive was loaded and took care of the IDE channel.

> Bits of dmesg for the failure case:
> 
> No DMA on CD-ROM with hd plugged in
> 
> Probing IDE interface ide0...
> hda: PLEXTOR DVDR PX-716A, ATAPI CD/DVD-ROM drive
> ide1: I/O resource 0x170-0x177 not free.
> ide1: ports already in use, skipping probe
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> hda: ATAPI 40X DVD-ROM DVD-R CD-R/RW drive, 8192kB Cache
> Uniform CD-ROM driver Revision: 3.20

This looks like ide-generic which doesn't do DMA since it isn't chipset
specific.  Make SURE you load the piix driver for the PATA channels, and
don't let the system auto load ide-generic when you try to access the
CD.  On debian I add these lines to /etc/modules to ensure they are
loaded in that order early in boot:

piix
ide-generic
ide-cd

W