(no subject)

[redzic fadil]

hello


I hope I don't disturb,


I have tried to compile the hello.c module under kernel 2.6.3.
And I'd like to insert the hello.o module in the kernel.
But this doesn't work with kernel 2.6.3 .

I have compiled this module with kernel 2.4.* and it is well.

Also I cannot include the header file module.h, because I get error 
messages.

my module:
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>


int initial_module (void)
{
	printk("\ninitial module\n");
	return (0);
}

void delete_module (void)
{
	printk("\ndelete module\n");
}

module_init(initial_module);
module_exit(delete_module);


my Makefile:
CC=gcc
CFLAGS=-isystem /lib/modules/`uname -r`/build/include -O2 -D__KERNEL__ 
-DMODULE
all: hello.o

If you have any idea please send an E-Mail:  redzic_fadil@hotmail.com

thanks

_________________________________________________________________
Die ultimative Fan-Seite für den MSN Messenger http://www.ilovemessenger.de 
Emoticons und Hintergründe kostenlos downloaden!

Re:

[Larry Reaves]

I suggest that you read
http://linuxdevices.com/articles/AT4389927951.html it is an article
about the differences between modules for 2.4 and 2.6.  Basically all
you need to do to get it to work is delete your Makefile and create a
new one with only this line:
obj-m := hello.o
and then issue the following command:
make -C /usr/src/linux-2.6.3 SUBDIRS=$PWD modules
your module compiles fine on my box using this method

On Sun, 2004-02-22 at 12:51, redzic fadil wrote:
> hello
> 
> 
> I hope I don't disturb,
> 
> 
> I have tried to compile the hello.c module under kernel 2.6.3.
> And I'd like to insert the hello.o module in the kernel.
> But this doesn't work with kernel 2.6.3 .
> 
> I have compiled this module with kernel 2.4.* and it is well.
> 
> Also I cannot include the header file module.h, because I get error 
> messages.
> 
> my module:
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/init.h>
> 
> 
> int initial_module (void)
> {
> 	printk("\ninitial module\n");
> 	return (0);
> }
> 
> void delete_module (void)
> {
> 	printk("\ndelete module\n");
> }
> 
> module_init(initial_module);
> module_exit(delete_module);
> 
> 
> my Makefile:
> CC=gcc
> CFLAGS=-isystem /lib/modules/`uname -r`/build/include -O2 -D__KERNEL__ 
> -DMODULE
> all: hello.o
> 
> If you have any idea please send an E-Mail:  redzic_fadil@hotmail.com
> 
> thanks
> 
> _________________________________________________________________
> Die ultimative Fan-Seite für den MSN Messenger http://www.ilovemessenger.de
> Emoticons und Hintergründe kostenlos downloaden!
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Larry Reaves <larry@moonshinecomputers.com>

Re: No Subject

[Ludootje]

On Sun, 2004-02-22 at 17:51, redzic fadil wrote:
> hello
> 
> 
> I hope I don't disturb,
> 
> 
> I have tried to compile the hello.c module under kernel 2.6.3.
> And I'd like to insert the hello.o module in the kernel.
> But this doesn't work with kernel 2.6.3 .
> 
> I have compiled this module with kernel 2.4.* and it is well.


See http://lwn.net/Articles/21817 for porting hello world.
(or http://lwn.net/Articles/driver-porting for the entire article)

Ludootje

No subject

[auto595907]

Bug-Entry	: http://bugzilla.kernel.org/show_bug.cgi?id=16423
Subject		: netfilter/iptables stopped logging 2.6.35-rc
Submitter	: auto401300@hushmail.com
Date		: 2010-07-17 10:20 (44 days old)
Message-ID	: <20100717072036.1BBE52804B@smtp.hushmail.com>
References	: 
http://lkml.indiana.edu/hypermail/linux/kernel/1007.2/00440.html


this patch fixes the bug above:
(http://marc.info/?l=netfilter-devel&m=128116762801769&w=2)

fixed in 2.6.36-rc3


thanks

No subject

[auto595907]

>I created a Bugzilla entry at 
>https://bugzilla.kernel.org/show_bug.cgi?id=16423
>for your bug report, please add your address to the CC list in 
>there, thanks!
>
>-- 
>Maciej Rutecki
>http://www.maciek.unixy.pl


this patch fixes the bug above
(http://marc.info/?l=netfilter-devel&m=128116762801769&w=2)


thanks.

(no subject)

[Andi Kleen]

Sender: ak@wotan.suse.de
To: Rik van Riel <riel@redhat.com>
cc: linux-kernel@vger.kernel.org, akpm@osdl.org,
	Ian Pratt <Ian.Pratt@cl.cam.ac.uk>, Steven.Hand@cl.cam.ac.uk,
	Christian.Limpach@cl.cam.ac.uk, Keir.Fraser@cl.cam.ac.uk
Subject: arch/xen considered harmful was Re: Xen VMM patch set - take 2
References: <E1CXLph-0000XC-00@mta1.cl.cam.ac.uk.suse.lists.linux.kernel>
	<Pine.LNX.4.61.0411281206100.12575@chimarrao.boston.redhat.com.suse.lists.linux.kernel>
From: Andi Kleen <ak@suse.de>
Date: 14 Dec 2004 17:49:07 +0100
In-Reply-To: <Pine.LNX.4.61.0411281206100.12575@chimarrao.boston.redhat.com.suse.lists.linux.kernel>
Message-ID: <p73mzwgddvg.fsf_-_@wotan.suse.de>
Lines: 48
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Rik van Riel <riel@redhat.com> writes:

[very late answer]

> Stunned silence I guess - merging an architecture is
> usually much more controversial ;)

In my opinion it's still an extremly bad idea to have arch/xen
an own architecture. It will cause a lot of work long term
to maintain it, especially when it gets x86-64 support too.
It would be much better to just merge it with i386/x86-64.

Currently it's already difficult enough to get people to
add fixes to both i386 and x86-64, adding fixes to three
or rather four (xen32 and xen64) architectures will be quite bad.
In practice we'll likely get much worse code drift and missing
fixes. Also I still suspect Ian is underestimating how much
work it is long term to keep an Linux architecture uptodate.

I cannot imagine the virtualization hooks are intrusive anyways. The
only things it needs to hook idle and the page table updates, right?
Doing that cleanly in the existing architectures shouldn't be that
hard.

I suspect xen64 will be rather different from xen32 anyways
because as far as I can see the tricks Xen32 uses to be
fast (segment limits) just plain don't work on 64bit
because the segments don't extend into 64bit space.
So having both in one architecture may also end up messy.

And i386 and x86-64 are in many pieces very different anyways,
I have my doubts that trying to mesh them together in arch/xen
will be very pretty.

Also the other thing I'm worried about is that there is no clear
specification on how the Xen<->Linux interface works. Assuming
there will be other para Hypervisors in the future too will we
end up with even more virtual architectures? It would be much
better to have at least a somewhat defined "linux virtual interface"
first that is actually understood by multiple people outside
the Xen group.

I think before merging stuff the hypervisor interfaces need to be
discussed on linux-kernel. Splitting the patches and posting them
as individual pieces for i386 with good description will be a good
first step for that.

-Andi

Re: No Subject

[Alan Cox]

The Xen interface seems to me better described that most of the kernel
interfaces and has more papers written on it. I would rather see
arch/xen and public exposure and use of the platform before considering
major redesigns. The s390 people have proved we can remove/fold arch
directories effectively and after original implementation without
problems.

I'm not convinced by your arguments about arch/xen although I am long
term in favour because I'd like see it easy to build a kernel which can
be used without Xen and can switch into Xen guest mode on Xen loading.

Alan

(no subject)

[Hermann Gottschalk]

unsubscribe

Re: No Subject

[Jesse Stockall]

On Fri, 2004-07-16 at 12:54, Hermann Gottschalk wrote:
> unsubscribe

Please follow the instructions at the bottom of every message.

Jesse

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

(no subject)

[News Admin]

>From news Fri Feb 21 14:43:28 2003
Received: (from news@localhost)
	by nimloth.ics.muni.cz (8.11.6+Sun/8.10.0.Beta12) id h1LDhSm13508
	for newsmaster; Fri, 21 Feb 2003 14:43:28 +0100 (MET)
Newsgroups: cz.muni.redir.linux-kernel
Path: news
From: Zdenek Kabelac <kabi@i.am>
Subject: SMP kernel 2.4 and gcc-3.2
Message-ID: <3E562CFC.774860C7@i.am>
Sender: UNKNOWN@decibel.fi.muni.cz
Date: Fri, 21 Feb 2003 13:43:24 GMT
X-Nntp-Posting-Host: decibel.fi.muni.cz
Content-Transfer-Encoding: 7bit
X-Accept-Language: cs, en
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.19-rc3-ac3 i686)
Organization: unknown

Hello

As I've so far not noticed any such post - maybe it's just me.

But I simply can not build usable SMP 2.4.2x kernel
with gcc-3.2

Whenever I use gcc-3.2 - the compiled kernel just immediately
reboots machine - Exactly the same kernel with same configuration
compiled with gcc-2.95 works normaly.
The box is Abit BP6/256MB Ram/Matrox G400 with 2xCelerons

I've just seen slightly different behavior with various
versions - sometime it just locked the box (i.e. GRUB screen
has stayed on the screen and I had to press 'reset' button
myself)

Ok - what should I do to help fix this problem - as I've said
I've tried various configuration - I don't think there
is something special in there (http://www.fi.muni.cz/~kabi/.config)

$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.3/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared
--with-system-zlib --enable-nls --without-included-gettext
--enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm
--enable-objc-gc i386-linux
Thread model: posix
gcc version 3.2.3 20030210 (Debian prerelease)


please Cc: me

-- 
  .''`.
 : :' :    Zdenek Kabelac  kabi@{debian.org, users.sf.net, fi.muni.cz}
 `. `'           Debian GNU/Linux maintainer - www.debian.{org,cz}
   `-

Re: No Subject

[Alan Cox]

On Fri, 2003-02-21 at 13:43, News Admin wrote:
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.3/specs
> Configured with: ../src/configure -v
> --enable-languages=c,c++,java,f77,proto,pascal,objc,ada --prefix=/usr
> --mandir=/usr/share/man --infodir=/usr/share/info
> --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared
> --with-system-zlib --enable-nls --without-included-gettext
> --enable-__cxa_atexit --enable-clocale=gnu --enable-java-gc=boehm
> --enable-objc-gc i386-linux
> Thread model: posix
> gcc version 3.2.3 20030210 (Debian prerelease)

How about using a released gcc compiler not a snapshot. gcc 3.2.1
and 3.2.2 appear to work fine. According to the FSF there is no
gcc 3.2.3 yet, so it isn't suprising a snapshot would have bugs

(no subject)

[Christos Kartsaklis]

Folks, I got this Oops on my box (Redhat 7.1) while mounting one of my disks. 
After the Oops report comes info which might be of some use to you. 

I have two 60.0 GB ATA133 hard disks installed on my system, a Maxtor D740X-6L
and a Quantum Fireball Plus AS 60.0 GB (not identified properly in dmesg),
both in EXT2 fs. I see why the system got poked that sharply, I don't know
why this _random_ behaviour is caused though. Note also that the BIOS cannot
identify any of them. I have been using these two disks on Redhat 7.2, and
today I tried to install them on another box (the offending one) running Redhat
7.1, not being used for ~7 months. 

If you need more info, let me know. I hope this helps, and yes, I know that I
should get a newer kernel version. 

Please CC me all, as I am not subscribed to the list.


ksymoops 2.4.1 on i686 2.4.7-10.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.7-10/ (default)
     -m /boot/System.map-2.4.7-10 (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (expand_objects): cannot stat(/lib/sd_mod.o) for sd_mod
Error (expand_objects): cannot stat(/lib/scsi_mod.o) for scsi_mod
Error (pclose_local): find_objects pclose failed 0x100
Warning (compare_maps): mismatch on symbol partition_name  , ksyms_base says c01b3570, System.map says c0155720.  Ignoring ksyms_base entry
Warning (compare_maps): mismatch on symbol lp_table  , lp says c885d640, /lib/modules/2.4.7-10/kernel/drivers/char/lp.o says c885d440.  Ignoring /lib/modules/2.4.7-10/kernel/drivers/char/lp.o entry
Warning (compare_maps): mismatch on symbol usb_devfs_handle  , usbcore says c88479a0, /lib/modules/2.4.7-10/kernel/drivers/usb/usbcore.o says c88474c0.  Ignoring /lib/modules/2.4.7-10/kernel/drivers/usb/usbcore.o entry
Warning (compare_maps): mismatch on symbol sd  , sd_mod says c881bce4, /lib/modules/2.4.7-10/kernel/drivers/scsi/sd_mod.o says c881bba0.  Ignoring /lib/modules/2.4.7-10/kernel/drivers/scsi/sd_mod.o entry
Warning (compare_maps): mismatch on symbol proc_scsi  , scsi_mod says c8817568, /lib/modules/2.4.7-10/kernel/drivers/scsi/scsi_mod.o says c8815df0.  Ignoring /lib/modules/2.4.7-10/kernel/drivers/scsi/scsi_mod.o entry
Warning (compare_maps): mismatch on symbol scsi_devicelist  , scsi_mod says c8817594, /lib/modules/2.4.7-10/kernel/drivers/scsi/scsi_mod.o says c8815e1c.  Ignoring /lib/modules/2.4.7-10/kernel/drivers/scsi/scsi_mod.o entry
Warning (compare_maps): mismatch on symbol scsi_hostlist  , scsi_mod says c8817590, /lib/modules/2.4.7-10/kernel/drivers/scsi/scsi_mod.o says c8815e18.  Ignoring /lib/modules/2.4.7-10/kernel/drivers/scsi/scsi_mod.o entry
Warning (compare_maps): mismatch on symbol scsi_hosts  , scsi_mod says c8817598, /lib/modules/2.4.7-10/kernel/drivers/scsi/scsi_mod.o says c8815e20.  Ignoring /lib/modules/2.4.7-10/kernel/drivers/scsi/scsi_mod.o entry
Warning (compare_maps): mismatch on symbol scsi_logging_level  , scsi_mod says c8817564, /lib/modules/2.4.7-10/kernel/drivers/scsi/scsi_mod.o says c8815dec.  Ignoring /lib/modules/2.4.7-10/kernel/drivers/scsi/scsi_mod.o entry
CPU:    0
EIP:    0010:[<c018cf9a>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010212
eax: 00000000   ebx: 00001640   ecx: 00000000   edx: 00000000
esi: c02de2c4   edi: 00001100   ebp: 00000040   esp: c440dee8
ds: 0018   es: 0018   ss: 0018
Process mount (pid: 1190, stackpage=c440d000)
Stack: 00001600 00000040 00000464 00000001 c02de458 00000330 c018d031 00001640
       00000001 c02de2c4 c75ce440 c449faa0 c449faa0 c018d0ef c75d2860 c75ce440
       c013cb97 c75ce440 c449faa0 c449faa0 c75ce440 c13df300 c0134e03 c75ce440
Call Trace: [<c018d031>] [<c018d0ef>] [<c013cb97>] [<c0134e03>] [<c0134d2d>]
   [<c013f63e>] [<c0135006>] [<c0106f0b>]
Code: 8b 40 28 85 c0 74 04 56 ff d0 5a 80 a6 ae 00 00 00 fb 8d 86

>>EIP; c018cf9a <ide_revalidate_disk+da/110>   <=====
Trace; c018d031 <revalidate_drives+61/90>
Trace; c018d0ef <ide_open+2f/100>
Trace; c013cb97 <blkdev_open+47/80>
Trace; c0134e03 <dentry_open+c3/140>
Trace; c0134d2d <filp_open+4d/60>
Trace; c013f63e <getname+5e/a0>
Trace; c0135006 <sys_open+36/b0>
Trace; c0106f0b <system_call+33/38>
Code;  c018cf9a <ide_revalidate_disk+da/110>
00000000 <_EIP>:
Code;  c018cf9a <ide_revalidate_disk+da/110>   <=====
   0:   8b 40 28                  mov    0x28(%eax),%eax   <=====
Code;  c018cf9d <ide_revalidate_disk+dd/110>
   3:   85 c0                     test   %eax,%eax
Code;  c018cf9f <ide_revalidate_disk+df/110>
   5:   74 04                     je     b <_EIP+0xb> c018cfa5 <ide_revalidate_disk+e5/110>
Code;  c018cfa1 <ide_revalidate_disk+e1/110>
   7:   56                        push   %esi
Code;  c018cfa2 <ide_revalidate_disk+e2/110>
   8:   ff d0                     call   *%eax
Code;  c018cfa4 <ide_revalidate_disk+e4/110>
   a:   5a                        pop    %edx
Code;  c018cfa5 <ide_revalidate_disk+e5/110>
   b:   80 a6 ae 00 00 00 fb      andb   $0xfb,0xae(%esi)
Code;  c018cfac <ide_revalidate_disk+ec/110>
  12:   8d 86 00 00 00 00         lea    0x0(%esi),%eax


10 warnings and 3 errors issued.  Results may not be reliable.


cat /proc/version:
------------------
Linux version 2.4.7-10 (bhcompile@stripples.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)) #1 Thu Sep 6 17:27:27 EDT 2001

dmesg:
------
Linux version 2.4.7-10 (bhcompile@stripples.devel.redhat.com) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)) #1 Thu Sep 6 17:27:27 EDT 2001
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000007ff0000 (usable)
 BIOS-e820: 0000000007ff0000 - 0000000007ff3000 (ACPI NVS)
 BIOS-e820: 0000000007ff3000 - 0000000008000000 (ACPI data)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
Scanning bios EBDA for MXT signature
On node 0 totalpages: 32752
zone(0): 4096 pages.
zone(1): 28656 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=linux ro root=302 BOOT_FILE=/boot/vmlinuz-2.4.7-10
Initializing CPU#0
Detected 451.033 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 897.84 BogoMIPS
Memory: 125148k/131008k available (1269k kernel code, 4576k reserved, 90k data, 220k init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0383f9ff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383f9ff 00000000 00000000 00000000
CPU:     After generic, caps: 0383f9ff 00000000 00000000 00000000
CPU:             Common caps: 0383f9ff 00000000 00000000 00000000
CPU: Intel Pentium III (Katmai) stepping 03
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb230, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
Limiting direct PCI/PCI transfers.
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.14)
mxt_scan_bios: enter
Starting kswapd v1.8
VFS: Diskquotas version dquot_6.5.0 initialized
pty: 2048 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
Real Time Clock Driver v1.10d
block: queued sectors max/low 83064kB/27688kB, 256 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz PCI bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
hda: QUANTUM FIREBALL CR8.4A, ATA DISK drive
hdc: MAXTOR 6L060J3, ATA DISK drive
hdd: AEA\x02@\x01, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 16514064 sectors (8455 MB) w/418KiB Cache, CHS=1027/255/63, UDMA(33)
hdc: 117266688 sectors (60041 MB) w/1819KiB Cache, CHS=116336/16/63, UDMA(33)
hdd: 0 sectors (0 MB) w/1900KiB Cache, CHS=513/0/3
hdd: INVALID GEOMETRY: 0 PHYSICAL HEADS?
ide-floppy driver 0.97
Partition check:
 hda: hda1 hda2 hda3 < hda5 hda6 hda7 >
 hdc: hdc1
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
hdd: 0 sectors (0 MB) w/1900KiB Cache, CHS=513/0/3
hdd: INVALID GEOMETRY: 0 PHYSICAL HEADS?
ide-floppy driver 0.97
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 378k freed
EXT2-fs warning: checktime reached, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
SCSI subsystem driver Revision: 1.00
Freeing unused kernel memory: 220k freed
Adding Swap: 136512k swap-space (priority -1)
Adding Swap: 88316k swap-space (priority -2)
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.259 $ time 17:36:49 Sep  6 2001
usb-uhci.c: High bandwidth mode enabled
usb-uhci.c: USB UHCI at I/O 0xe000, IRQ 3
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
usb-uhci.c: v1.251:USB Universal Host Controller Interface driver
parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
8139too Fast Ethernet driver 0.9.18a
PCI: Found IRQ 10 for device 00:10.0
PCI: Sharing IRQ 10 with 00:04.0
eth0: RealTek RTL8139 Fast Ethernet at 0xc8866100, 00:00:21:db:01:e7, IRQ 10
eth0:  Identified 8139 chip type 'RTL-8139B'
eth0: Setting half-duplex based on auto-negotiated partner ability 0000.
parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
lp0: using parport0 (polling).
lp0: console ready

Re: No Subject

[Alan Cox]

Red Hat put out an errata for the 2.4.7-10 kernel a long time ago. It
fixes numerous problems and indirect bugs as a result. Can you try that
first of all

(no subject)

[Pawel Kot]

Hi,

The problem I reported once, still exist in 2.4.19. See my previous emails
for the reference:
http://marc.theaimsgroup.com/?l=linux-kernel&m=102495067602135&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=102277249800423&w=2
It is fixed in -ac series though.

As Bartek Zolnierkiewicz pointed me, the problem was introduced by two
factors:
 - checking the return value of pci_enable_device(dev)
 - some settings problem with PCI resources -- BIOS/controller does
prepare them for XP
(these are more-less Bartek's words).

What helped me was using fixup_device_piix() from -ac in
ide_scan_pcidev(). My controler's ID is DEVID_ICH3M.
It is used in a different, more generic way in -ac, so I don't post the
patch.

Alan, Marcelo: is there any chance that this change will be ported from
-ac in 2.4.20?

many thanks to Bartek,
pkot
-- 
mailto:pkot@linuxnews.pl :: mailto:pkot@slackware.pl
http://kt.linuxnews.pl/ :: Kernel Traffic po polsku

Re: No Subject

[Alan Cox]

On Sat, 2002-08-03 at 20:26, Pawel Kot wrote:
> What helped me was using fixup_device_piix() from -ac in
> ide_scan_pcidev(). My controler's ID is DEVID_ICH3M.
> It is used in a different, more generic way in -ac, so I don't post the
> patch.
> 
> Alan, Marcelo: is there any chance that this change will be ported from
> -ac in 2.4.20?

I plan to send Marcelo all the IDE updates. Note btw the checking of the
return value on pci_enable_device is critical - some old kernels hang on
boot with crappy bioses through not checking.

What I begin to the think the right answer is, is to relax the IDE fixup
block in the i386 kernel boot up. Right now we avoid assigning
unassigned resources for IDE controllers. Clearly we should be doing so.

Re: No Subject

[Bartlomiej Zolnierkiewicz]

On 3 Aug 2002, Alan Cox wrote:

> On Sat, 2002-08-03 at 20:26, Pawel Kot wrote:
> > What helped me was using fixup_device_piix() from -ac in
> > ide_scan_pcidev(). My controler's ID is DEVID_ICH3M.
> > It is used in a different, more generic way in -ac, so I don't post the
> > patch.
> >
> > Alan, Marcelo: is there any chance that this change will be ported from
> > -ac in 2.4.20?
>
> I plan to send Marcelo all the IDE updates. Note btw the checking of the
> return value on pci_enable_device is critical - some old kernels hang on
> boot with crappy bioses through not checking.

Of course it is critical :-).

> What I begin to the think the right answer is, is to relax the IDE fixup
> block in the i386 kernel boot up. Right now we avoid assigning
> unassigned resources for IDE controllers. Clearly we should be doing so.

I think so.
Andre what do you think?

And one more thing in ide-pci.c:ide_setup_pci_device() after explicitly
enabling device's IOs we may need to update dev->resource and we don't
do this (we place chipset in native mode so i.e. on VIA base addresses
are just showing up). How to update them?

Regards
--
Bartlomiej

Re: No Subject

[Bartlomiej Zolnierkiewicz]

On Sat, 3 Aug 2002, Bartlomiej Zolnierkiewicz wrote:

>
> On 3 Aug 2002, Alan Cox wrote:
>
> > On Sat, 2002-08-03 at 20:26, Pawel Kot wrote:
> > > What helped me was using fixup_device_piix() from -ac in
> > > ide_scan_pcidev(). My controler's ID is DEVID_ICH3M.
> > > It is used in a different, more generic way in -ac, so I don't post the
> > > patch.
> > >
> > > Alan, Marcelo: is there any chance that this change will be ported from
> > > -ac in 2.4.20?
> >
> > I plan to send Marcelo all the IDE updates. Note btw the checking of the
> > return value on pci_enable_device is critical - some old kernels hang on
> > boot with crappy bioses through not checking.
>
> Of course it is critical :-).
>
> > What I begin to the think the right answer is, is to relax the IDE fixup
> > block in the i386 kernel boot up. Right now we avoid assigning
> > unassigned resources for IDE controllers. Clearly we should be doing so.
>
> I think so.
> Andre what do you think?

Just rethough it. What if chipset is in compatibility mode?
Like VIA with base addresses set to 0?

(please note I am not a PCI resource menagament expert ;-)

> And one more thing in ide-pci.c:ide_setup_pci_device() after explicitly
> enabling device's IOs we may need to update dev->resource and we don't
> do this (we place chipset in native mode so i.e. on VIA base addresses
> are just showing up). How to update them?
>
> Regards
> --
> Bartlomiej

Re: No Subject

[Alan Cox]

On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:
> Just rethough it. What if chipset is in compatibility mode?
> Like VIA with base addresses set to 0?

If we found a register that was marked as unassigned with a size then we
would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
device attached to the south bridge.

What problems does that cause for the VIA stuff ?

Re: No Subject

[Bartlomiej Zolnierkiewicz]

On 4 Aug 2002, Alan Cox wrote:

> On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:
> > Just rethough it. What if chipset is in compatibility mode?
> > Like VIA with base addresses set to 0?
>
> If we found a register that was marked as unassigned with a size then we
> would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
> device attached to the south bridge.
>
> What problems does that cause for the VIA stuff ?

In compatibility mode IDE chipsets have IO at legacy ISA ports and
PCI_BASE_ADDRESS0-3 are set to them or to zero (at least on VIA).
And they can't be programmed to any other ports (unless native mode).

I am just asking if it can cause some problems.

--
Bartlomiej

Re: No Subject

[Henning P. Schmiedehausen]

Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> writes:

>On 4 Aug 2002, Alan Cox wrote:

>> On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:
>> > Just rethough it. What if chipset is in compatibility mode?
>> > Like VIA with base addresses set to 0?
>>
>> If we found a register that was marked as unassigned with a size then we
>> would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
>> device attached to the south bridge.
>>
>> What problems does that cause for the VIA stuff ?

>In compatibility mode IDE chipsets have IO at legacy ISA ports and
>PCI_BASE_ADDRESS0-3 are set to them or to zero (at least on VIA).
>And they can't be programmed to any other ports (unless native mode).

Hi,

this sounds like a problem that I have with the ServerWorks OSB5
chipset. I actually have PCI_BASE_ADDRESS0-3 at 0 and
PCI_BASE_ADDRESS4 = 0x3a0.

Does this hold true here, too? Or is this VIA specific?

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: No Subject

[Daniela Engert]

On Sun, 4 Aug 2002 13:28:46 +0000 (UTC), Henning P. Schmiedehausen
wrote:

>Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> writes:
>>On 4 Aug 2002, Alan Cox wrote:
>>> On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:

>>> > Just rethough it. What if chipset is in compatibility mode?
>>> > Like VIA with base addresses set to 0?
>>>
>>> If we found a register that was marked as unassigned with a size then we
>>> would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
>>> device attached to the south bridge.
>
>>In compatibility mode IDE chipsets have IO at legacy ISA ports and
>>PCI_BASE_ADDRESS0-3 are set to them or to zero (at least on VIA).
>>And they can't be programmed to any other ports (unless native mode).

>this sounds like a problem that I have with the ServerWorks OSB5
>chipset. I actually have PCI_BASE_ADDRESS0-3 at 0 and
>PCI_BASE_ADDRESS4 = 0x3a0.
>
>Does this hold true here, too? Or is this VIA specific?

PCI IDE controller chips in compatibility mode may exhibit the
following BAR0-3 values (sorted by likelihood of occurance):

most likely:  BAR0-3 are all zero
rare       :  BAR0-3 show the legacy IDE port values
very rare  :  BAR0-3 contain garbage

In fact, the best strategy is to *ignore* BAR0-3 in compatibility mode
because they have no meaning then!

Ciao,
  Dani

Re: No Subject

[Petr Vandrovec]

On Sun, Aug 04, 2002 at 12:38:00AM +0100, Alan Cox wrote:
> On Sat, 2002-08-03 at 23:16, Bartlomiej Zolnierkiewicz wrote:
> > Just rethough it. What if chipset is in compatibility mode?
> > Like VIA with base addresses set to 0?
> 
> If we found a register that was marked as unassigned with a size then we
> would map it to a PCI address. That would go for BAR0-3 on any PCI IDE
> device attached to the south bridge.
> 
> What problems does that cause for the VIA stuff ?

We must read PCI config register 9 (programming interface), and check its value.

If r9 & 0x05 == 0x05, we can program BARs. 

Otherwise if r9 & 0x0A != 0x0A, we must not touch hardware: it supports 
only legacy 0x1F0/0x170 assignment (PCI-IDE spec says that BAR0-BAR3
can be either hardwired to zero, or it can be writeable, but written
value must be ignored).

If r9 & 0x0A == 0x0A, we must write r9 | 0x05 to PCI config register 9,
and then (after verifying that write suceeded... it does not suceed
in VMware, for example...) we must (re)program BARs.

Worst problem is that (some) VIA chips have BAR0-BAR3 writeable,
but are programmed to ignore them by BIOS (as IRQ14/IRQ15 routing is
not available when in native mode). Current kernel code will believe
that device was relocated, but reality will be different, because of device
ignores BAR0-BAR3 value until programming interface is modified.
					Best regards,
						Petr Vandrovec
						vandrove@vc.cvut.cz

No Subject

[abraxas2]

hi everybody,

i have implemented an improved linux ntfs driver.

the following changes have been done :

- full deletion support
- full hardlink support
- support for multiple mft records
- support for chmod, rename, truncate, df, du, ...
- implemented new tools ntchmod, ntlink, ntrm, ntundel (undeletion)
  there is a NT port of the tools, too
- fixed a bunch of FIXME's and another bunch of bugs

the kernel part of the sources increased almost to the double.

one of the performed tests was a complete linux kernel build on a
ntfs volume. without any complaints by chkdsk.


this is currently for kernel 2.2.x.

work is in progress for the following items :
- support for kernel 2.4.x
- support for symlinks, device files and chown/chgrp
- full support for compressed files

if you are interested, please send me an email. please indicate if you
want only the kernel part or the complete sources.

Abraxas

<abraxas2@findhere.com>