devil-linux-develop Mailing List for Devil-Linux (Page 30)

Andrzej Odyniec wrote:
> I will check it in near future, but as for now, I tried to compile other Intel 
> driver dedicated to new Intel circuits: e1000e

First!
======

OPS!

All I wrote was true except report from netdriverinfo. Should be (after 
today's second compilation):

> root@Devil # ./netdriverinfo.sh
> eth0 : 00:19.0
>     Make/Model = ASUSTeK Computer Inc. Device 8268
>     Ethernet controller = Intel Corporation 82566DM Gigabit Network Connection
>     VenID:DevID = 8086:104a
>     Driver name = e1000e
>     Driver version = 0.5.18.3-NAPI
> eth1 : 03:00.0
>     Make/Model = Intel Corporation PRO/1000 PT Quad Port Server Adapter
>     Ethernet controller = Intel Corporation 82571EB Gigabit Ethernet Controller
>     VenID:DevID = 8086:10a4
>     Driver name = e1000e
>     Driver version = 0.5.18.3-NAPI
> eth2 : 03:00.1
>     Make/Model = Intel Corporation PRO/1000 PT Quad Port Server Adapter
>     Ethernet controller = Intel Corporation 82571EB Gigabit Ethernet Controller
>     VenID:DevID = 8086:10a4
>     Driver name = e1000e
>     Driver version = 0.5.18.3-NAPI
> eth3 : 04:00.0
>     Make/Model = Intel Corporation PRO/1000 PT Quad Port Server Adapter
>     Ethernet controller = Intel Corporation 82571EB Gigabit Ethernet Controller
>     VenID:DevID = 8086:10a4
>     Driver name = e1000e
>     Driver version = 0.5.18.3-NAPI
> eth4 : 04:00.1
>     Make/Model = Intel Corporation PRO/1000 PT Quad Port Server Adapter
>     Ethernet controller = Intel Corporation 82571EB Gigabit Ethernet Controller
>     VenID:DevID = 8086:10a4
>     Driver name = e1000e
>     Driver version = 0.5.18.3-NAPI

Previus was from original kernel driver (because of little bug in my script 
compiled driver was not properly installed in CD image). As we can see, kernel 
has e1000e driver but in older version than this from Intel. In Ubuntu forums 
I found, that this old driver is not working correctly in some situations and 
guys used Intel 0.5.18.3 instead. I need this DL installation for my main 
router, so I will compile actual Intel driver using my script, reducing (I 
hope) risk.

Second!
=======

But I detected second problem in default config compiled DL 1.4RC1. I have in 
/etc/sysconfig/config RUNFROMRAM=yes. Look, please, onto console display:

> ********************************************************************************
> *                                                                              *
> *                           Welcome to Devil-Linux                             *
> *                                                                              *
> ********************************************************************************
>                           http://www.devil-linux.org/
> 
> Version 1.4RC1-2009-04-22
> Kernel 2.6.29.1-grsec
> Mounting SHM FS on /shm
> waiting until usb-storage driver has initialized all devices ...
> Creating devices in /dev
> 
> Searching for configuration media
> Checking for "etc-mods.tar.bz2" on "/dev/sdb2" ... file not found
> Checking for "etc-mods.tar.bz2" on "/dev/sdb1" ... success!
> loading configuration
> Searching for Devil-Linux CD-ROM
> Search list: /dev/hdb
> checking /dev/hdb Found on /dev/hdb
> System is configured to run from ram
> Copying system image (327 MB) to ramdisk...|done.
> ERROR: ramdisk size calculation error
>        the image to copy was bigger than expected
> 
> Please report to bu...@de...
> 
> Falling back to standard mount...
> Mounting SHM FS on /cdrom/shm
> Unmounting  proc
> Starting up final system...
> Using AUFS for /etc/
> aufs 2-standalone.tree-29-20090413
> Changed Root
> Un-Mounting old Filesystems
> Freeing InitRD memory

I don't know, why? Do You have this same effect or not?

Best regards

-- 
Andrzej Odyniec

<an...@ma...>
Rada Nadzorcza Macrologic SA
ul. Chroscickiego 49, 02-414 Warszawa
tel. +48(22)8637681x132, fax: +48(22)8639861
ul. Jagiellonska 36, 03-719 Warszawa
tel. +48(22)5118115, fax: +48(22)5118117

Heiko,

I wrote:
>>I will check this after weekend. Especially because Intel e1000 is not
>>compiling. I need e1000 --- in my router I have four port Intel server
>>card and as I remember, standard kernel drivers has problems with this card.

And You wrote:
> We're using the drivers from the Intel website. There's a slightly newer
> one, but it got created way before the 2.6.29 kernel.
> 
> Try the Kernel driver, maybe it's working now with your card.

I will check it in near future, but as for now, I tried to compile other Intel 
driver dedicated to new Intel circuits: e1000e

This diver was updated last days, and they (Intel engineers?) write, that is 
good for new controllers.

In 1.4RC1 build environment I copied script e1000 to e1000e and corrected (de 
facto adding "e" letter after e1000 in some places). Into source directory I 
inserted driver package (actually from Intel page on Sourceforge: 
http://downloads.sourceforge.net/e1000/e1000e-0.5.18.3.tar.gz) and unpacked 
manually into tmp directory. After this in .config I set variable 
CONFIG_INTEL_E1000E=y
checked in altered script and did "make prepare" and "make build". As effect I 
obtained in e1000e log:

> make[1]: Entering directory `/build/tmp/e1000e-0.5.18.3/src'
> make -C /build/tmp/linux-2.6.29 SUBDIRS=/build/tmp/e1000e-0.5.18.3/src modules
> make[2]: Entering directory `/build/tmp/linux-2.6.29'
>   CC [M]  /build/tmp/e1000e-0.5.18.3/src/netdev.o
>   CC [M]  /build/tmp/e1000e-0.5.18.3/src/ethtool.o
>   CC [M]  /build/tmp/e1000e-0.5.18.3/src/param.o
>   CC [M]  /build/tmp/e1000e-0.5.18.3/src/e1000_82571.o
>   CC [M]  /build/tmp/e1000e-0.5.18.3/src/e1000_ich8lan.o
>   CC [M]  /build/tmp/e1000e-0.5.18.3/src/e1000_80003es2lan.o
>   CC [M]  /build/tmp/e1000e-0.5.18.3/src/e1000_mac.o
>   CC [M]  /build/tmp/e1000e-0.5.18.3/src/e1000_nvm.o
>   CC [M]  /build/tmp/e1000e-0.5.18.3/src/e1000_phy.o
>   CC [M]  /build/tmp/e1000e-0.5.18.3/src/e1000_manage.o
>   CC [M]  /build/tmp/e1000e-0.5.18.3/src/kcompat.o
>   LD [M]  /build/tmp/e1000e-0.5.18.3/src/e1000e.o
>   Building modules, stage 2.
>   MODPOST 1 modules
> WARNING: modpost: Found 23 section mismatch(es).
> To see full details build your kernel with:
> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>   CC      /build/tmp/e1000e-0.5.18.3/src/e1000e.mod.o
>   LD [M]  /build/tmp/e1000e-0.5.18.3/src/e1000e.ko
> make[2]: Leaving directory `/build/tmp/linux-2.6.29'
> make[1]: Leaving directory `/build/tmp/e1000e-0.5.18.3/src'
> removing debug symbols from binaries

Supposing that "section mismatches" are properly serviced I burn new iso and 
boot. All seems is working. In boot log (dmesg) I have:

> e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k6
> e1000e: Copyright (c) 1999-2008 Intel Corporation.
> e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> e1000e 0000:00:19.0: setting latency timer to 64
> e1000e 0000:00:19.0: irq 29 for MSI/MSI-X
> parport_pc 00:07: reported by Plug and Play ACPI
> parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]
> 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:18:f3:f0:0f:94
> 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
> 0000:00:19.0: eth0: MAC: 5, PHY: 6, PBA No: ffffff-0ff
> e1000e 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> e1000e 0000:03:00.0: setting latency timer to 64
> e1000e 0000:03:00.0: irq 30 for MSI/MSI-X
> ata5: SATA link down (SStatus 0 SControl 300)
> ohci1394 0000:07:01.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
> ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[20]  MMIO=[febff800-febfffff]  Max Packet=[2048]  IR/IT contexts=[4/8]
> 0000:03:00.0: eth1: (PCI Express:2.5GB/s:Width x4) 00:15:17:33:f9:34
> 0000:03:00.0: eth1: Intel(R) PRO/1000 Network Connection
> 0000:03:00.0: eth1: MAC: 0, PHY: 4, PBA No: d47316-004
> e1000e 0000:03:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17
> e1000e 0000:03:00.1: setting latency timer to 64
> e1000e 0000:03:00.1: irq 31 for MSI/MSI-X
> 0000:03:00.1: eth2: (PCI Express:2.5GB/s:Width x4) 00:15:17:33:f9:35
> 0000:03:00.1: eth2: Intel(R) PRO/1000 Network Connection
> 0000:03:00.1: eth2: MAC: 0, PHY: 4, PBA No: d47316-004
> e1000e 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> e1000e 0000:04:00.0: setting latency timer to 64
> e1000e 0000:04:00.0: irq 32 for MSI/MSI-X
> ata6: SATA link down (SStatus 0 SControl 300)
> 0000:04:00.0: eth3: (PCI Express:2.5GB/s:Width x4) 00:15:17:33:f9:36
> 0000:04:00.0: eth3: Intel(R) PRO/1000 Network Connection
> 0000:04:00.0: eth3: MAC: 0, PHY: 4, PBA No: d47316-004
> e1000e 0000:04:00.1: PCI INT B -> GSI 18 (level, low) -> IRQ 18
> e1000e 0000:04:00.1: setting latency timer to 64
> e1000e 0000:04:00.1: irq 33 for MSI/MSI-X
> 0000:04:00.1: eth4: (PCI Express:2.5GB/s:Width x4) 00:15:17:33:f9:37
> 0000:04:00.1: eth4: Intel(R) PRO/1000 Network Connection
> 0000:04:00.1: eth4: MAC: 0, PHY: 4, PBA No: d47316-004
> ieee1394: Host added: ID:BUS[0-00:1023]  GUID[0011d8000103f9cb]
> end_request: I/O error, dev fd0, sector 0
> end_request: I/O error, dev fd0, sector 0
> Buffer I/O error on device fd0, logical block 0
> end_request: I/O error, dev fd0, sector 0
> Buffer I/O error on device fd0, logical block 0
> kjournald starting.  Commit interval 5 seconds
> EXT3 FS on sdg4, internal journal
> EXT3-fs: mounted filesystem with ordered data mode.
> 802.1Q VLAN Support v1.8 Ben Greear <gr...@ca...>
> All bugs added by David S. Miller <da...@re...>
> e1000e 0000:00:19.0: irq 29 for MSI/MSI-X
> e1000e 0000:00:19.0: irq 29 for MSI/MSI-X
> e1000e 0000:03:00.0: irq 30 for MSI/MSI-X
> e1000e 0000:03:00.0: irq 30 for MSI/MSI-X
> e1000e 0000:03:00.1: irq 31 for MSI/MSI-X
> e1000e 0000:03:00.1: irq 31 for MSI/MSI-X
> e1000e 0000:04:00.0: irq 32 for MSI/MSI-X
> e1000e 0000:04:00.0: irq 32 for MSI/MSI-X
> NET: Registered protocol family 10

Intel script: netdriverinfo.sh gives this output:

> root@Devil:/var # ./netdriverinfo.sh
> eth0 : 00:19.0
>     Make/Model = ASUSTeK Computer Inc. Device 8268
>     Ethernet controller = Intel Corporation 82566DM Gigabit Network Connection
>     VenID:DevID = 8086:104a
>     Driver name = e1000e
>     Driver version = 0.3.3.3-k6
> eth1 : 03:00.0
>     Make/Model = Intel Corporation PRO/1000 PT Quad Port Server Adapter
>     Ethernet controller = Intel Corporation 82571EB Gigabit Ethernet Controller
>     VenID:DevID = 8086:10a4
>     Driver name = e1000e
>     Driver version = 0.3.3.3-k6
> eth2 : 03:00.1
>     Make/Model = Intel Corporation PRO/1000 PT Quad Port Server Adapter
>     Ethernet controller = Intel Corporation 82571EB Gigabit Ethernet Controller
>     VenID:DevID = 8086:10a4
>     Driver name = e1000e
>     Driver version = 0.3.3.3-k6
> eth3 : 04:00.0
>     Make/Model = Intel Corporation PRO/1000 PT Quad Port Server Adapter
>     Ethernet controller = Intel Corporation 82571EB Gigabit Ethernet Controller
>     VenID:DevID = 8086:10a4
>     Driver name = e1000e
>     Driver version = 0.3.3.3-k6
> eth4 : 04:00.1
>     Make/Model = Intel Corporation PRO/1000 PT Quad Port Server Adapter
>     Ethernet controller = Intel Corporation 82571EB Gigabit Ethernet Controller
>     VenID:DevID = 8086:10a4
>     Driver name = e1000e
>     Driver version = 0.3.3.3-k6

ethtool -p blinks on all RJ45 sockets correctly. All sockets detects link. For 
example:

> root@Devil:/var # ethtool eth1
> Settings for eth1:
>         Supported ports: [ TP ]
>         Supported link modes:   10baseT/Half 10baseT/Full
>                                 100baseT/Half 100baseT/Full
>                                 1000baseT/Full
>         Supports auto-negotiation: Yes
>         Advertised link modes:  10baseT/Half 10baseT/Full
>                                 100baseT/Half 100baseT/Full
>                                 1000baseT/Full
>         Advertised auto-negotiation: Yes
>         Speed: 1000Mb/s
>         Duplex: Full
>         Port: Twisted Pair
>         PHYAD: 1
>         Transceiver: internal
>         Auto-negotiation: on
>         Supports Wake-on: pumbag
>         Wake-on: g
>         Current message level: 0x00000001 (1)
>         Link detected: yes

I can connect to box via ssh.

So I think: If Intel is not upgrading e1000 to 2.6.29 net structures, there is 
time to replace e1000 -> e1000e in 1.4RC1.

Best regards

-- 
Andrzej Odyniec

<an...@ma...>
Rada Nadzorcza Macrologic SA
ul. Chroscickiego 49, 02-414 Warszawa
tel. +48(22)8637681x132, fax: +48(22)8639861
ul. Jagiellonska 36, 03-719 Warszawa
tel. +48(22)5118115, fax: +48(22)5118117

Hey,

> -----Original Message-----
> From: Andrzej Odyniec [mailto:an...@ma...]
> Sent: Saturday, April 18, 2009 7:03 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] 1.4rc1
> 
> Serge Leschinsky wrote:
> > There is a chance to check it once again. I've updated dst package
> without
> > changing its name. On my box the update was successful (timestamps?).
> Please pay
> > attention to the update of dst on your system
> 
> I will check this after weekend. Especially because Intel e1000 is not
> compiling. I need e1000 --- in my router I have four port Intel server
> card
> and as I remember, standard kernel drivers has problems with this card.

We're using the drivers from the Intel website. There's a slightly newer
one, but it got created way before the 2.6.29 kernel.

http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProductID=838&DwnldID
=9180&strOSs=39&OSFullName=Linux*&lang=eng

Try the Kernel driver, maybe it's working now with your card.

Heiko

I wrote:
> I will check this after weekend. Especially because Intel e1000 is not 
> compiling. I need e1000 --- in my router I have four port Intel server card 
> and as I remember, standard kernel drivers has problems with this card. Look 
> into build log, please:
> 
>>make[2]: Entering directory `/build/tmp/e1000-8.0.6/src'
>>make[2]: warning: -jN forced in submake: disabling jobserver mode.
>>make -C /build/tmp/linux-2.6.29 SUBDIRS=/build/tmp/e1000-8.0.6/src modules
>>make[3]: Entering directory `/build/tmp/linux-2.6.29'
>>  CC [M]  /build/tmp/e1000-8.0.6/src/e1000_main.o
>>/build/tmp/e1000-8.0.6/src/e1000_main.c: In function 'e1000_io_error_detected':
>>/build/tmp/e1000-8.0.6/src/e1000_main.c:4894: error: 'struct net_device' has no member named 'priv'
>>/build/tmp/e1000-8.0.6/src/e1000_main.c: In function 'e1000_io_slot_reset':
>>/build/tmp/e1000-8.0.6/src/e1000_main.c:4916: error: 'struct net_device' has no member named 'priv'
>>/build/tmp/e1000-8.0.6/src/e1000_main.c: In function 'e1000_io_resume':
>>/build/tmp/e1000-8.0.6/src/e1000_main.c:4944: error: 'struct net_device' has no member named 'priv'
>>make[4]: *** [/build/tmp/e1000-8.0.6/src/e1000_main.o] Error 1
>>make[3]: *** [_module_/build/tmp/e1000-8.0.6/src] Error 2
>>make[3]: Leaving directory `/build/tmp/linux-2.6.29'
>>make[2]: *** [default] Error 2
>>make[2]: Leaving directory `/build/tmp/e1000-8.0.6/src'

I compared include/linux/netdevice.h in 2.6.27 and 2.6.29
And answer is simple: in 2.6.29 kernel structure net_device has changed. There 
is no pointer priv (used in Intel 8.0.6 drivers) but for getting private data 
function call is used. So 8.0.6 version of Intel driver will not be compilling 
with 2.6.29 kernel. All hope in standard e1000 drivers --- maybe they will 
work now with server Intel Ethernet cards. If not --- we must wait for newer 
version (or try e1000e?).

Current e1000 conf option is unusable.

Best Regards

Andrzej Odyniec

Serge Leschinsky wrote:
> There is a chance to check it once again. I've updated dst package without
> changing its name. On my box the update was successful (timestamps?). Please pay
> attention to the update of dst on your system

I will check this after weekend. Especially because Intel e1000 is not 
compiling. I need e1000 --- in my router I have four port Intel server card 
and as I remember, standard kernel drivers has problems with this card. Look 
into build log, please:

> make[2]: Entering directory `/build/tmp/e1000-8.0.6/src'
> make[2]: warning: -jN forced in submake: disabling jobserver mode.
> make -C /build/tmp/linux-2.6.29 SUBDIRS=/build/tmp/e1000-8.0.6/src modules
> make[3]: Entering directory `/build/tmp/linux-2.6.29'
>   CC [M]  /build/tmp/e1000-8.0.6/src/e1000_main.o
> /build/tmp/e1000-8.0.6/src/e1000_main.c: In function 'e1000_io_error_detected':
> /build/tmp/e1000-8.0.6/src/e1000_main.c:4894: error: 'struct net_device' has no member named 'priv'
> /build/tmp/e1000-8.0.6/src/e1000_main.c: In function 'e1000_io_slot_reset':
> /build/tmp/e1000-8.0.6/src/e1000_main.c:4916: error: 'struct net_device' has no member named 'priv'
> /build/tmp/e1000-8.0.6/src/e1000_main.c: In function 'e1000_io_resume':
> /build/tmp/e1000-8.0.6/src/e1000_main.c:4944: error: 'struct net_device' has no member named 'priv'
> make[4]: *** [/build/tmp/e1000-8.0.6/src/e1000_main.o] Error 1
> make[3]: *** [_module_/build/tmp/e1000-8.0.6/src] Error 2
> make[3]: Leaving directory `/build/tmp/linux-2.6.29'
> make[2]: *** [default] Error 2
> make[2]: Leaving directory `/build/tmp/e1000-8.0.6/src'

In Sourceforge there are no newer Intel drivers. Maybe there is option 
correcting this problem. I need read comments about it. But as we see, there 
are changed struct net_device in headers. With 2.6.27 kernel Intel e1000 
compiled and work correct.

Best Regards

Andrzej Odyniec

Andrzej Odyniec wrote:

> 
> now I see, contents of kernel patches package is different.
> Always update_src removed old package and downoladed new one.
> But this package was NOT replaced. Maybe because has this same name as old one?
There is a chance to check it once again. I've updated dst package without
changing its name. On my box the update was successful (timestamps?). Please pay
attention to the update of dst on your system


Serge

Heiko Zuerker:
> Did you run the update_src against our main ftp server? Maybe the  
> mirror is not updated completely.

I always do update_src against:
(1) Devil-Linux FTP-Server       Luxembourg-Kirchberg

The one trick I'm doing is copying all sources from my private repository 
before doing update_src, for not overloading FTP-Server in Luxemburg. After 
update_src I'm copying differences again to my private repository.

But...

now I see, contents of kernel patches package is different.
Always update_src removed old package and downoladed new one.
But this package was NOT replaced. Maybe because has this same name as old one?

Message from lftp was:

Verifying md5 checksums
src/kernel-patches-2.6.tar.bz2: FAILED

but was immediately covered by mc window.

So I have new experience:
-- look for messages of this kind and eventually remove packages with bad sum
-- and after repeat update_src again

Thanks for help

Regards

-- 
Andrzej Odyniec

<an...@ma...>
Rada Nadzorcza Macrologic SA
ul. Chroscickiego 49, 02-414 Warszawa
tel. +48(22)8637681x132, fax: +48(22)8639861
ul. Jagiellonska 36, 03-719 Warszawa
tel. +48(22)5118115, fax: +48(22)5118117

Quoting Andrzej Odyniec <an...@ma...>:

> Heiko Zuerker wrote:
>
>> Mine compiled fine last night, so I'm not sure why yours fails. I used
>> the default config with 4 parallel jobs.
>>
>> I'm uploading the build right now, it would be great if folks could
>> double check it before I create an official version.
>
> I'm sure, You right. Maybe my build process get files to early. I used the
> following in /usr/src directory, where was no lfssystem subdirectory:
>
>> tar -xjvf /mnt/lfs/sources/devil/lfssystem-SVN-20070314-cleaned.tar.bz2
>> cd lfssystem
>> cvs  
>> -d:pserver:ano...@de...:/cvsroot/devil-linux  
>> login </dev/null
>> cvs -z3  
>> -d:pserver:ano...@de...:/cvsroot/devil-linux  
>> co build
>> cd build
>> ./update_src
>
> and after proper chroot change (cr) and
> make menuconfig and after
> make unpack prepare makefile
>
> This sequence always worked
>
> Maybe in time, I get files, it wasn't be fresh on cvs or in source package
> repository. I will repeat all process again  to new lfssystem directory

Did you run the update_src against our main ftp server? Maybe the  
mirror is not updated completely.


-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Heiko Zuerker wrote:

> Mine compiled fine last night, so I'm not sure why yours fails. I used  
> the default config with 4 parallel jobs.
> 
> I'm uploading the build right now, it would be great if folks could  
> double check it before I create an official version.

I'm sure, You right. Maybe my build process get files to early. I used the 
following in /usr/src directory, where was no lfssystem subdirectory:

> tar -xjvf /mnt/lfs/sources/devil/lfssystem-SVN-20070314-cleaned.tar.bz2
> cd lfssystem
> cvs -d:pserver:ano...@de...:/cvsroot/devil-linux login </dev/null
> cvs -z3 -d:pserver:ano...@de...:/cvsroot/devil-linux co build
> cd build
> ./update_src

and after proper chroot change (cr) and
make menuconfig and after
make unpack prepare makefile

This sequence always worked

Maybe in time, I get files, it wasn't be fresh on cvs or in source package 
repository. I will repeat all process again  to new lfssystem directory

Regards


-- 
Andrzej Odyniec

<an...@ma...>
Rada Nadzorcza Macrologic SA
ul. Chroscickiego 49, 02-414 Warszawa
tel. +48(22)8637681x132, fax: +48(22)8639861
ul. Jagiellonska 36, 03-719 Warszawa
tel. +48(22)5118115, fax: +48(22)5118117

Mine compiled fine last night, so I'm not sure why yours fails. I used  
the default config with 4 parallel jobs.

I'm uploading the build right now, it would be great if folks could  
double check it before I create an official version.

Heiko

Quoting Serge Leschinsky <fi...@in...>:

> Hi Andrzej,
>
> Andrzej Odyniec wrote:
>> Heiko Zuerker wrote:
>>> not sure if you saw it, but I changed the version of 1.3 into 1.4RC1.
>>> I'm compiling a version right now which I'll upload as the official
>>> 1.4RC1 (hopefully this weekend).
>
> kernel-patches is old:
>>
> ...
>>> applying patch: /build/tmp/kernel-patches-2.6/140-netfilter_time.patch
>>> patching file include/linux/netfilter_ipv4/ipt_time.h
>>> patching file net/ipv4/netfilter/ipt_time.c
>>> patching file net/ipv4/netfilter/Kconfig
>>> Hunk #1 FAILED at 57.
>>> 1 out of 1 hunk FAILED -- saving rejects to file  
>>> net/ipv4/netfilter/Kconfig.rej
>>> patching file net/ipv4/netfilter/Makefile
>>> Hunk #1 succeeded at 52 with fuzz 2 (offset 2 lines).
>> Regards
>>
>
> [root@sjcspare8 tmp]# ll kernel-patches-2.6/
> total 48
> -rw-r--r--  1 root root   365 Dec 10 14:06 004-extra_optimization.patch
> -rw-r--r--  1 root root 15311 Jan 10 19:26 050-frandom.patch
> -rw-r--r--  1 root root 24484 Dec 10 14:06 150-netfilter_imq.patch
> -rw-r--r--  1 root root  1106 Dec 10 19:32 151-imq-2.6.27-hotfix.patch
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Hi Andrzej,

Andrzej Odyniec wrote:
> Heiko Zuerker wrote:
>> not sure if you saw it, but I changed the version of 1.3 into 1.4RC1.
>> I'm compiling a version right now which I'll upload as the official  
>> 1.4RC1 (hopefully this weekend).

kernel-patches is old:
> 
...
>> applying patch: /build/tmp/kernel-patches-2.6/140-netfilter_time.patch
>> patching file include/linux/netfilter_ipv4/ipt_time.h
>> patching file net/ipv4/netfilter/ipt_time.c
>> patching file net/ipv4/netfilter/Kconfig
>> Hunk #1 FAILED at 57.
>> 1 out of 1 hunk FAILED -- saving rejects to file net/ipv4/netfilter/Kconfig.rej
>> patching file net/ipv4/netfilter/Makefile
>> Hunk #1 succeeded at 52 with fuzz 2 (offset 2 lines).
> Regards
> 

[root@sjcspare8 tmp]# ll kernel-patches-2.6/
total 48
-rw-r--r--  1 root root   365 Dec 10 14:06 004-extra_optimization.patch
-rw-r--r--  1 root root 15311 Jan 10 19:26 050-frandom.patch
-rw-r--r--  1 root root 24484 Dec 10 14:06 150-netfilter_imq.patch
-rw-r--r--  1 root root  1106 Dec 10 19:32 151-imq-2.6.27-hotfix.patch

Heiko Zuerker wrote:
> not sure if you saw it, but I changed the version of 1.3 into 1.4RC1.
> I'm compiling a version right now which I'll upload as the official  
> 1.4RC1 (hopefully this weekend).

Fresh system, created from scratch. No nice. No parallel...
But for now is not compiling... broken in prepare.
Maybe we need wait to monday...
There is prepare log:
> `/build/scripts/config/linux-2.6/config_linux' -> `/build/tmp/linux-2.6.29/.config'
> applying patch: /build/tmp/kernel-patches-2.6/004-extra_optimization.patch
> patching file Makefile
> Hunk #1 succeeded at 560 (offset 11 lines).
> applying patch: /build/tmp/kernel-patches-2.6/050-frandom.patch
> patching file arch/um/Kconfig.char
> Hunk #1 succeeded at 230 with fuzz 2 (offset 2 lines).
> patching file drivers/char/Kconfig
> Hunk #1 succeeded at 66 (offset 9 lines).
> patching file drivers/char/Makefile
> Hunk #1 succeeded at 9 with fuzz 2.
> patching file drivers/char/frandom.c
> patching file drivers/char/random.c
> Hunk #1 succeeded at 1269 (offset 38 lines).
> patching file include/linux/sysctl.h
> Hunk #1 succeeded at 242 (offset -6 lines).
> applying patch: /build/tmp/kernel-patches-2.6/140-netfilter_time.patch
> patching file include/linux/netfilter_ipv4/ipt_time.h
> patching file net/ipv4/netfilter/ipt_time.c
> patching file net/ipv4/netfilter/Kconfig
> Hunk #1 FAILED at 57.
> 1 out of 1 hunk FAILED -- saving rejects to file net/ipv4/netfilter/Kconfig.rej
> patching file net/ipv4/netfilter/Makefile
> Hunk #1 succeeded at 52 with fuzz 2 (offset 2 lines).
Regards

-- 
Andrzej Odyniec

<an...@ma...>
Rada Nadzorcza Macrologic SA
ul. Chroscickiego 49, 02-414 Warszawa
tel. +48(22)8637681x132, fax: +48(22)8639861
ul. Jagiellonska 36, 03-719 Warszawa
tel. +48(22)5118115, fax: +48(22)5118117

Quoting Philippe Weill <phi...@ae...>:

> Heiko Zuerker a écrit :
>> Hey guys,
>>
>> not sure if you saw it, but I changed the version of 1.3 into 1.4RC1.
>> I'm compiling a version right now which I'll upload as the official
>> 1.4RC1 (hopefully this weekend).
>>
> did you put bind 9.6 on 1.4rc1 ?

No.
I'll update it and give it a try.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Heiko Zuerker a écrit :
> Hey guys,
> 
> not sure if you saw it, but I changed the version of 1.3 into 1.4RC1.
> I'm compiling a version right now which I'll upload as the official  
> 1.4RC1 (hopefully this weekend).
> 
did you put bind 9.6 on 1.4rc1 ?

-- 
  Weill Philippe -  Administrateur Systeme et Reseaux
  CNRS/UPMC/IPSL   LATMOS (UMR 8190)
  Tour 45/46 3e Etage B302 - 4 Place Jussieu - 75252 Paris Cedex 05 -  FRANCE
  Email:phi...@la... | tel:+33 0144274759 Fax:+33 0144273776

Hey guys,

not sure if you saw it, but I changed the version of 1.3 into 1.4RC1.
I'm compiling a version right now which I'll upload as the official  
1.4RC1 (hopefully this weekend).

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

The next 1.3 release will have kernel 2.6.29.1.

I'll upload a new version as soon as I get through my testing.

Heiko

Quoting "Rudner, Björn" <br...@ba...>:

> Hi developers, I just wanted to inform you that there is some nasty ?new
> feature? in kernel 2.6.27 that brings Apache to segfault its
> childs. Take a look at:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=46467 Seems as  
> this Problem is fixed with kernel 2.6.28, so 2.6.27 will
> be no good candidate for a Release-Version of DL 1.3 (The Problem  
> encountered also on older Versions of apache, so this
> will not do the trick. Also raising
> /proc/sys/fs/epoll/max_user_instances to any higher value (I tried
> 40960) did not work for long on my proxy-servers) Mit freundlichen  
> Grüßen/Kind regards,
>
> Björn Rudner
> Administrator
>
> phone: +49 (89) 930 839-16[1]
> pers. fax.: 01805-456 987-200 16[2]
> mobile: +49 (151) 121 623 71
> e-mail: br...@ba... -------------------------
> baulogis GmbH
> Zamdorfer Str. 100
> 81677 München / Munich
> Deutschland / Germany
> www.baulogis.com[3]
>
> Geschäftsführer / Managing Director: Thomas Bachmaier
> HRB 133832, Amtsgericht München
> Ust-ID: DE 212 020 193
>
> Der Inhalt dieser E-Mail ist vertraulich und ausschließlich für
> den bezeichneten Adressaten bestimmt.
> Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen
> Vertreter sein sollten, so beachten Sie bitte, dass jede Form der
> Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Wiedergabe
> des Inhalts dieser E-Mail unzulässig ist.
> Bitte setzen Sie sich in diesem Fall mit dem Absender der E-Mail in
> Verbindung (br...@ba...).

-- 

Regards
   Heiko Zuerker
http://www.devil-linux.org

Links:
------
[1] tel:+49-89-930839-16
[2] fax:+49-1805-456987-20016
[3] http://www.baulogis.com/


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Hi developers,

I just wanted to inform you that there is some nasty "new feature" in kernel 2.6.27 that brings Apache to segfault its childs.
Take a look at: https://issues.apache.org/bugzilla/show_bug.cgi?id=46467

Seems as this Problem is fixed with kernel 2.6.28, so 2.6.27 will be no good candidate for a Release-Version of DL 1.3
(The Problem encountered also on older Versions of apache, so this will not do the trick. Also raising /proc/sys/fs/epoll/max_user_instances to any higher value (I tried 40960) did not work for long on my proxy-servers)


Mit freundlichen Grüßen/Kind regards,

Björn Rudner
Administrator

phone: +49 (89) 930 839-16<tel:+49-89-930839-16>
pers. fax.: 01805-456 987-200 16<fax:+49-1805-456987-20016>
mobile: +49 (151) 121 623 71
e-mail: br...@ba...<mailto:br...@ba...>


________________________________
baulogis GmbH
Zamdorfer Str. 100
81677 München / Munich
Deutschland / Germany
www.baulogis.com<http://www.baulogis.com/>

Geschäftsführer / Managing Director: Thomas Bachmaier
HRB 133832, Amtsgericht München
Ust-ID: DE 212 020 193

Der Inhalt dieser E-Mail ist vertraulich und ausschließlich für den bezeichneten Adressaten bestimmt.
Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Wiedergabe des Inhalts dieser E-Mail unzulässig ist.
Bitte setzen Sie sich in diesem Fall mit dem Absender der E-Mail in Verbindung (br...@ba...).

Hey guys,

 

Just double checking, but it seems to me that we can remove the linx-wlan-ng
package, since it seems everything is now in the Kernel.

Does anybody disagree with that conclusion?

 

Heiko

Looking for a patch for something?
Check this out: http://daniel.holba.ch/harvest/age.html

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Oliver Niesner wrote:
> Stefan Engel wrote:
>> Hi,
> 
>> I just wanted to start a full rebuild of the current CVS version of DL
>> 1.3, but update_src reported an error regarding stunnel.

Fixed. It seems I had deleted the package while src update the last time.
I'm sorry,

Serge

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Engel wrote:
> Hi,
> 
> I just wanted to start a full rebuild of the current CVS version of DL
> 1.3, but update_src reported an error regarding stunnel.
> 
> md5sum.lst contains the entry for src/stunnel-4.26.tar.gz. But this
> package got removed during the last run of update_src, because it is no
> longer available on the ftp server.
> 
> Bug or feature?
> 
> Best regards,
> Stefan

I can confirm.
I had to add stunnel manually or disable it in menuconfig to do a clean
compile.

Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFJsCqS724ZL5LNhNcRAu3yAJ9KoHynkh0WR5xWKHsh2GcG40hn1wCfYfY4
tcYHFDeJzFVQ+79Az5o6pTc=
=fPQx
-----END PGP SIGNATURE-----

Hi,

I just wanted to start a full rebuild of the current CVS version of DL
1.3, but update_src reported an error regarding stunnel.

md5sum.lst contains the entry for src/stunnel-4.26.tar.gz. But this
package got removed during the last run of update_src, because it is no
longer available on the ftp server.

Bug or feature?

Best regards,
Stefan

It's fixed.
The problem only occurred when you were using the pre-unionfs etc.tar.bz2.

Heiko

-----Original Message-----
From: Heiko Zuerker [mailto:he...@zu...] 
Sent: Friday, February 20, 2009 4:36 PM
To: dev...@li...
Subject: Re: [Devil-linux-develop] 1.4rc1 ?

Hey,

I did some debugging and this is what happens.
After the first call of mount_cdrom from linuxrc, the script finds the ISO
images, but doesn't completely mount it. The loopback device is set up, but
the iso images is not mounted. This is why the mount_cdrom gets called again
from linuxrc, since it doesn't find /cdrom/DEVIL-LINUX.
I did manually umount /cd and deleted the loopback device before the 2nd
mount_cdrom run and then everything works fine.
Not sure why it doesn't completely finish the first time it tries.
Unfortunately I ran out of time and can't look any more (maybe next week
again).

Heiko

-----Original Message-----
From: Heiko Zuerker [mailto:he...@zu...] 
Sent: Friday, February 20, 2009 12:58 PM
To: dev...@li...
Subject: Re: [Devil-linux-develop] 1.4rc1 ?

Actually I think it's just going wrong when it looks for the ISO image.
It finds it at first, then later complains. It's been a very long time since
I worked on the boot behavior of DL....

I tried the latest version from CVS.

Heiko

-----Original Message-----
From: Serge Leschinsky [mailto:fi...@in...]
Sent: Thursday, February 19, 2009 11:35 PM
To: dev...@li...
Subject: Re: [Devil-linux-develop] 1.4rc1 ?

Heiko Zuerker wrote:
> Quoting Serge Leschinsky <fi...@in...>:
> 
>> Heiko Zuerker wrote:
>>
>>> Yes I tried the bootcd.iso.new.
>>> It seemed to have replaced all files correctly, but had trouble 
>>> finding the iso image later. As far as I remember it actually said 
>>> it found it and then failed. Not sure when I can test it again.
>> OK. Let's wait another case.
I think I've found the reason of the failure (at least one :-) ) It's
migration from initrd to initramfs - as we didn't update boot loader config
file, parameters "root=xxx", "init=xxx" became invalid.... It causes boot
failure.  Will we fix it?

>>> You can remount the partition in rw mode:
>>> mount -o remount, rw /var/adm/boot    (Or whatever the path was).
>>> That's how I upload the new iso image. 
>>>
>> Yes, I missed that. This code is in pre_init file. I tried several 
>> times, but it seems not working with INITRAMFS (after switch_root). 
>> Would you mind if I move this feature to linuxrc?
> 
> As always, do whatever you deem necessary. As long as it works 
> afterwards.... ;-)

 :-)
Done. Verified on initramfs and initrd. Seems to be working.

--
Sincerely,
Serge

----------------------------------------------------------------------------
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H _______________________________________________
Devil-linux-develop mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-develop


----------------------------------------------------------------------------
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Devil-linux-develop mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Hey,

I did some debugging and this is what happens.
After the first call of mount_cdrom from linuxrc, the script finds the ISO
images, but doesn't completely mount it. The loopback device is set up, but
the iso images is not mounted. This is why the mount_cdrom gets called again
from linuxrc, since it doesn't find /cdrom/DEVIL-LINUX.
I did manually umount /cd and deleted the loopback device before the 2nd
mount_cdrom run and then everything works fine.
Not sure why it doesn't completely finish the first time it tries.
Unfortunately I ran out of time and can't look any more (maybe next week
again).

Heiko

-----Original Message-----
From: Heiko Zuerker [mailto:he...@zu...] 
Sent: Friday, February 20, 2009 12:58 PM
To: dev...@li...
Subject: Re: [Devil-linux-develop] 1.4rc1 ?

Actually I think it's just going wrong when it looks for the ISO image.
It finds it at first, then later complains. It's been a very long time since
I worked on the boot behavior of DL....

I tried the latest version from CVS.

Heiko

-----Original Message-----
From: Serge Leschinsky [mailto:fi...@in...]
Sent: Thursday, February 19, 2009 11:35 PM
To: dev...@li...
Subject: Re: [Devil-linux-develop] 1.4rc1 ?

Heiko Zuerker wrote:
> Quoting Serge Leschinsky <fi...@in...>:
> 
>> Heiko Zuerker wrote:
>>
>>> Yes I tried the bootcd.iso.new.
>>> It seemed to have replaced all files correctly, but had trouble 
>>> finding the iso image later. As far as I remember it actually said 
>>> it found it and then failed. Not sure when I can test it again.
>> OK. Let's wait another case.
I think I've found the reason of the failure (at least one :-) ) It's
migration from initrd to initramfs - as we didn't update boot loader config
file, parameters "root=xxx", "init=xxx" became invalid.... It causes boot
failure.  Will we fix it?

>>> You can remount the partition in rw mode:
>>> mount -o remount, rw /var/adm/boot    (Or whatever the path was).
>>> That's how I upload the new iso image. 
>>>
>> Yes, I missed that. This code is in pre_init file. I tried several 
>> times, but it seems not working with INITRAMFS (after switch_root). 
>> Would you mind if I move this feature to linuxrc?
> 
> As always, do whatever you deem necessary. As long as it works 
> afterwards.... ;-)

 :-)
Done. Verified on initramfs and initrd. Seems to be working.

--
Sincerely,
Serge

----------------------------------------------------------------------------
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H _______________________________________________
Devil-linux-develop mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Actually I think it's just going wrong when it looks for the ISO image.
It finds it at first, then later complains. It's been a very long time since
I worked on the boot behavior of DL....

I tried the latest version from CVS.

Heiko

-----Original Message-----
From: Serge Leschinsky [mailto:fi...@in...] 
Sent: Thursday, February 19, 2009 11:35 PM
To: dev...@li...
Subject: Re: [Devil-linux-develop] 1.4rc1 ?

Heiko Zuerker wrote:
> Quoting Serge Leschinsky <fi...@in...>:
> 
>> Heiko Zuerker wrote:
>>
>>> Yes I tried the bootcd.iso.new.
>>> It seemed to have replaced all files correctly, but had trouble
>>> finding the iso image later. As far as I remember it actually said it
>>> found it and then failed. Not sure when I can test it again.
>> OK. Let's wait another case.
I think I've found the reason of the failure (at least one :-) )
It's migration from initrd to initramfs - as we didn't update boot loader
config
file, parameters "root=xxx", "init=xxx" became invalid.... It causes boot
failure.  Will we fix it?

>>> You can remount the partition in rw mode:
>>> mount -o remount, rw /var/adm/boot    (Or whatever the path was).
>>> That's how I upload the new iso image. 
>>>
>> Yes, I missed that. This code is in pre_init file. I tried several  
>> times, but it
>> seems not working with INITRAMFS (after switch_root). Would you mind  
>> if I move
>> this feature to linuxrc?
> 
> As always, do whatever you deem necessary. As long as it works  
> afterwards.... ;-)

 :-)
Done. Verified on initramfs and initrd. Seems to be working.

--
Sincerely,
Serge

----------------------------------------------------------------------------
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Devil-linux-develop mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-develop