colinux-devel — Cooperative Linux development mailing list

[coLinux-devel] autobuild org.colinux.devel 20110218 21:32:54 r1577

[coLinux a. <col...@he...>]

The autobuild system has detected a new revision in the source repository.
Review last changed from changelog.txt, also attached in mail.

Download the compiled version:
http://www.henrynestler.com/colinux/autobuild/devel-20110218/

 colinux-0.7.9-20110218.src.tgz  (1083575 Bytes)
 daemons-0.7.9-20110218.dbg.zip  (686844 Bytes)
 daemons-0.7.9-20110218.zip  (567020 Bytes)
 modules-2.6.33.7-co-0.7.9-r1577-20110218.tgz  (4131329 Bytes)
 vmlinux-2.6.33.7-co-0.7.9-r1577-20110218.zip  (2222173 Bytes)

Note, the autobuild compilation does not include an installer.
Remember to reload the driver with these commands:

	colinux-daemon.exe --remove-driver
	colinux-daemon.exe --install-driver

Inside coLinux please update modules as follow:

	rm -rf /lib/modules/*-co-*
	tar -xzf modules-*-co-*-20110218.tgz -C /

The autobuild compilations are not official releases of Cooperative Linux
software.  There is no warranty that any autobuild version is stable.  If
use this autobuild version, please give us feedback of your experience.

Job runs on machine with 64 bit version of gcc 4.3.2.
A service from http://gcc.gnu.org/wiki/CompileFarm

-- 
Lots of fun with newest version,
Henry Nestler
------------------------------------------------------------------------
r1577 | henryn | 2011-02-18 21:32:54 +0000 (Fri, 18 Feb 2011) | 2 lines
Changed paths:
   M /branches/devel/patch/scsi-2.6.33.diff
   M /branches/devel/patch/scsi-core.diff

* scsi: Fixes KERN_WARN isn't defined and correct data_dump log output.
  (Vladislav Grishenko)
------------------------------------------------------------------------

[coLinux-devel] autobuild org.colinux.devel 20110216 23:27:25 r1575

[coLinux a. <col...@he...>]

The autobuild system has detected a new revision in the source repository.
Review last changed from changelog.txt, also attached in mail.

Download the compiled version:
http://www.henrynestler.com/colinux/autobuild/devel-20110216/

 colinux-0.7.9-20110216.src.tgz  (1083498 Bytes)
 daemons-0.7.9-20110216.dbg.zip  (686464 Bytes)
 daemons-0.7.9-20110216.zip  (567045 Bytes)
 modules-2.6.33.7-co-0.7.9-r1575-20110216.tgz  (4131607 Bytes)
 vmlinux-2.6.33.7-co-0.7.9-r1575-20110216.zip  (2222174 Bytes)

Note, the autobuild compilation does not include an installer.
Remember to reload the driver with these commands:

	colinux-daemon.exe --remove-driver
	colinux-daemon.exe --install-driver

Inside coLinux please update modules as follow:

	rm -rf /lib/modules/*-co-*
	tar -xzf modules-*-co-*-20110216.tgz -C /

The autobuild compilations are not official releases of Cooperative Linux
software.  There is no warranty that any autobuild version is stable.  If
use this autobuild version, please give us feedback of your experience.

Job runs on machine with 64 bit version of gcc 4.3.2.
A service from http://gcc.gnu.org/wiki/CompileFarm

-- 
Lots of fun with newest version,
Henry Nestler
------------------------------------------------------------------------
r1575 | henryn | 2011-02-16 23:27:25 +0000 (Wed, 16 Feb 2011) | 3 lines
Changed paths:
   M /branches/devel/NEWS
   M /branches/devel/patch/scsi-core.diff

* scsi: Set scsi_level = SCSI_SPC_2 will disable 16 byte command interface.
  Supress warnings "READ CAPACITY(16) failed" and "Sense not available".

------------------------------------------------------------------------

Re: [coLinux-devel] Booting colinux with network block device

[Henry N. <hen...@ar...>]

On 11.02.2011 13:29, Sergio Paracuellos wrote:
> I'd like to start colinux from a NBD partition, is this possible?
>
> Imagine you have a export for the device with all the files in a windows
> nbd server. ¿in what way can colinux start with that disk? I understand
> I have to Modify initrd and run nbd-client for get the exported device
> in /dev/nbd0 but I don't know if I have to do something with the command
> line of colinux for make colinux to see the disk.

After the device nbd is working, there is the same than native Linux. I 
don't know how you can use nbd as root filesystem, and I also don't know 
how a Windows NBD server would work with special device nodes (files in 
/dev and special files like fifi/pipe).

You should first start from normal running coLinux and try to mount the 
nbd. After you can see the complete file structure with all binaries 
(/bin, /sbin, /usr/bin,...) and all special devices in /dev, than you 
can begin to run this from initrd.

You needs to give the same command line as in native Linux. This is the 
base:
   colinux-daemon kernel=vmlinux initrd=initrd.gz root=/dev/ram0

First you should mount a cofs to load the modules and other Linux files 
(nbd client?) from Windows host. In your initrd you needs to load the 
module for device "nbd" and do all the networking setups. All this you 
should do step by step from command line. After you know what you need, 
you can put all steps into a script and all missing files into the 
initrd. The script you can name /MyStart.sh in root directory of initrd. 
Than add "init=/MyStart.sh" to the colinux-daemon command line above.

-- 
Henry N.

[coLinux-devel] Booting colinux with network block device

[Sergio P. <spa...@zi...>]

Hi all,

I'd like to start colinux from a NBD partition, is this possible?

Imagine you have a export for the device with all the files in a windows
nbd server. ¿in what way can colinux start with that disk? I understand
I have to Modify initrd and run nbd-client for get the exported device
in /dev/nbd0 but I don't know if I have to do something with the command
line of colinux for make colinux to see the disk. 

Any help is appreciated.

Regards,

-- 
Sergio Paracuellos
---------
ADVERTENCIA LEGAL: Este mensaje va dirigido, de manera exclusiva, a su
destinatario y contiene información confidencial y sujeta al secreto
profesional, cuya divulgación no está permitida por la ley. En de haber
recibido este mensaje por error, le rogamos que, de forma inmediata, nos
lo comunique mediante correo electrónico remitido a nuestra atención o a
través del teléfono  +34 914170710 y proceda a su eliminación, así como
a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos
que la distribución, copia o utilización de este mensaje, o de cualquier
documento adjunto, está prohibida por la ley.

[coLinux-devel] [ colinux-Bugs-1780633 ] Clock drift every 5 seconds

[SourceForge.net <no...@so...>]

Bugs item #1780633, was opened at 2007-08-24 00:24
Message generated for change (Comment added) made by henryn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=1780633&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Daemons (Windows)
Group: v0.7.x (release)
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Henry N. (henryn)
Summary: Clock drift every 5 seconds

Initial Comment:
Hello,

I installed both coLinux 0.6.4 and 0.7.1 and the Debian 4.0 image from sourceforge. The problem remains:

Every 5 seconds, the system clock is increased by 8 hours, 35 minutes and 45 seconds.

Example:

debian:~# while sleep 1; do date; done
Sat Aug 25 10:44:38 CEST 2007
Sat Aug 25 10:44:39 CEST 2007
Sat Aug 25 10:44:40 CEST 2007
Sat Aug 25 10:44:41 CEST 2007
Sat Aug 25 19:20:26 CEST 2007
Sat Aug 25 19:20:27 CEST 2007
Sat Aug 25 19:20:28 CEST 2007
Sat Aug 25 19:20:29 CEST 2007
Sat Aug 25 19:20:30 CEST 2007
Sun Aug 26 03:56:27 CEST 2007
Sun Aug 26 03:56:28 CEST 2007
Sun Aug 26 03:56:30 CEST 2007
Sun Aug 26 03:56:31 CEST 2007
Sun Aug 26 03:56:32 CEST 2007
Sun Aug 26 12:32:17 CEST 2007
Sun Aug 26 12:32:18 CEST 2007
Sun Aug 26 12:32:19 CEST 2007
Sun Aug 26 12:32:20 CEST 2007
Sun Aug 26 12:32:21 CEST 2007
Sun Aug 26 21:07:54 CEST 2007
Sun Aug 26 21:08:19 CEST 2007
[...]
debian:~# uname -a
Linux debian 2.6.12-co-0.7.1 #1 Sun Dec 31 20:25:16 UTC 2006 i686 GNU/Linux

The host is an AMD Athlon 64 3200+ system with 1 GB RAM, SATA harddisk and Windows XP Home SP2.

----------------------------------------------------------------------

>Comment By: Henry N. (henryn)
Date: 2011-02-06 21:53

Message:
This bug should also fixed in current release candidate 0.7.9.
I will close tracker now.

----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2010-10-20 02:20

Message:
Negative glitches from QueryPerformanceCounter and the inaccuracy
co_div64() was detected as the problem here.
Should fixed in devel SVN r1539 now.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2010-05-20 12:19

Message:
Update: I've tried the same kernel and system on a native XP SP2: It works
perfectly.
The problem with my previous test may be the fact that my XP runs in
VirtualBox? (Too much virtualisation)  , SP3?



----------------------------------------------------------------------

Comment By: vAx (re-vax)
Date: 2010-05-17 19:18

Message:
Same problem with my gentoo and coLinux: 2.6.33-co-0.8.0 #1 PREEMPT Sun Mar
21 19:46:28 UTC 2010 i686 Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz
GenuineIntel GNU/Linux

( >=2.6.27 kernel is required for UDEV to work. )

all is running on XP SP3 (uptodate).

I've tried to solve with ntpd, but it dosen't.
It's a shame, time is so important for my project (file server).

How can I help?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-07 11:21

Message:
Logged In: NO 

Hello,

some months ago I wrote this bug report.

Now I found out the the problem only occurs under Windows XP Home SP2.
With SP1, the clock behaves normal. I tested both the OEM Version of
Windows XP deliviered with the PC, and a vanilla Windows XP CD from
Microsoft. No matter which Install medium was used, installation of SP2
breaks the clock under coLinux.

Installing SP2 also leads to two other oddities on this machine. The
machine does not fully power down when shutting down under Windows; you
have to press the power button for 5 seconds to shut down entirely. And no
VMware product is working under SP2; I've tested Workstation, Player, and
Server. With SP1, all theres products run fine. However, Innotec VirtualBox
runs fine under SP2.

Not nice, but I can live with it.

Thanks to all who helped.

----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2007-09-02 22:54

Message:
Logged In: YES 
user_id=579204
Originator: NO

Reinstalling windows would not help, I'm afraid. coLinux time base use an
windows software timer for the HZ value (100ms). This should work in all
cases.

You can running native linux. Ok.
Please compaire the kernel bootmessages (dmesg). Have the native kernel
any special hacks for this cpu? Compair also the /proc/cpuinfo. Any
difference with the TSC?

Please enable colinux-debug after boot, for 10 seconds, than stop it with
CTRL-C and view into the file. coLinux would print, if detect some
problems.
  colinux-debug-daemon.exe -d -p -s prints=31,misc=31 -f debug.xml
Hope you will see and problems.

Have you tried to go into runlevel S ("init s" after boot). Can you check
any other time recources? wath does /proc/uptime? The same as you see on
"top".

PS: German is no problem.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-08-26 22:35

Message:
Logged In: NO 

Hallo,

thanks for your hints. Unfortunately, they did not help. :-(

I have now tried daemons-0.8.0-20070810.zip together with
vmlinux-2.6.22-co-0.8.0-20070808.zip . Same problem.
On another machine (Celeron, 512 MB, SATA HD) with Windows XP Professional
SP2, the same coLinux+kernel combination works without problems.

The file /etc/adjtime containes "0.0 0 0.0".

There is no process under the linux system which could change the time. I
have stopped all processes, and also tried the kernel parameter
"init=/bin/bash", but the time drift remains.

I can hardly believe that the host CPU is broken, because native Linux
runs fine on the system.
Maybe the Windows XP should be reinstalled...

Btw, the technical details of the PC are listed here:
http://www.heise.de/ct/hintergrund/meldung/45580
The page is in German, but the table at the end should be readable without
German language skills.

----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2007-08-24 12:45

Message:
Logged In: YES 
user_id=579204
Originator: NO

All kernels before 2.6.22 have the same source code for time (coLinux
0.7.1 and before). Perhaps the 2.6.22 solved it? The code for timer is
completely new there.
But, I'm afraid, it is some in the configuration or with the host cpu.
Please check that /etc/adjtime has "0 0 0" in the first line.

>From coLinux no such process is known to change the time all 5 seconds.
Has you a process, what does such? Try to start colinux in the lowest
runlevel "init s" or "init 1". Than, check the time warp again.

PS: Please use the tested snapshot http://www.colinux.org/snapshots/, not
the autobuilds.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2007-08-24 07:42

Message:
Logged In: NO 

Those versions are both horribly out of date.  If you're interested in
using colinux, you really should subscribe to the mailing list at
https://lists.sourceforge.net/lists/listinfo/colinux-devel (about 5
messages per week).

That's where the new releases are available.

The latest version is this one:
http://sourceforge.net/mailarchive/forum.php?thread_name=20070810085406.4E919112C6A%40HNE-LX.terminal&forum_name=colinux-devel

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=1780633&group_id=98788

[coLinux-devel] [ colinux-Bugs-2899010 ] scsi disk disconnects while creating an ext3 filesystem

[SourceForge.net <no...@so...>]

Bugs item #2899010, was opened at 2009-11-17 11:43
Message generated for change (Comment added) made by henryn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2899010&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: scsi disk disconnects while creating an ext3 filesystem

Initial Comment:
I'm trying to make a mkfs.ext3 /dev/sda1 , while sda is scsi0=\Device\Harddisk2\Partition0 , an 8 GB USB Flash Pen drive. 
Before mkfs ends, the linux console starts complaining with lots of lines like:

sd:0:0:0:0: rejecting I/O to offline device

and after stop, /sda is no longer visible.

Tried with the 20091115 snapshot.

----------------------------------------------------------------------

>Comment By: Henry N. (henryn)
Date: 2011-02-06 21:50

Message:
Inside SCSI driver we have fixed two bugs, that can be results here. Ones
was a 4GB limit and an other was an internal error with addressing of SG
table.
Both fixed as SVN revisions 1572 and 1547.
New bugs should open new report please.

----------------------------------------------------------------------

Comment By: German Salvador (germansalvador)
Date: 2009-12-02 14:20

Message:
Hi again,

I have been able to work around the problem, using cobd0 for
\Device\Harddisk2\Partition0 and then creating offseted loops that simulate
the different partitions. Not pretty, but works.

The write performance is not very good, though, about 5 MB/s

Regards,
 German



----------------------------------------------------------------------

Comment By: Peter Kuznetsov (peter_kuznetsov)
Date: 2009-11-20 19:31

Message:
1. I am sorry. From MS docs I knows, that the disks are numbered from 0,
and partitions from 1. When I want to access entire disk, I newer use
"\PartitonY". So I've noticed word "partition",
and ignored its number :).

2. I tried to reproduce the error several times, using Flash Drives 4, 8
and 32 Gb, but did not succeed. The message "coscsi0: unable to open
device..." may indicate that the disk is used by another process. The drive
letter does not matter, because is the letter of the partition. The
NT-program can access entire disk as "\\.\PhysicalDriveX" and disk can be
locked. So it is very important to know what processes, system or not, are
running at NT-side when you started coLinux.

Peter.


----------------------------------------------------------------------

Comment By: German Salvador (germansalvador)
Date: 2009-11-20 17:49

Message:
About the bug:

I have tried using cobd0=\device\harddisk2\partition0 instead of scsi, and
it works ok. Only that then I can't access the partitions as cobd01 or
something like that. I think I can make a workaround using several
consecutive invocations to colinux:
- scsi0=... for creating the partitions
- several cobdX  for formatting and installing the data I need.

I'll try as soon as I can.

Thanks in advance,

And about \device\harddiskX\partition0 or not:

Peter,

I didn't used \\.\PhysicalDriveX\Partition0, but
\device\harddiskX\Partition0. It's not the same thing.

Anyway, I wanted to know if \device\harddiskX and
\device\harddiskX\partition0 are synonyms, but it doesn't seem like that:

With a new 8 GB flash pen and colinux using
scsi0=\device\harddisk2\partition0:

scsi0 : Cooperative Linux SCSI Adapter
scsi 0:0:0:0: Direct-Access     coLinux  CODISK           1.01 PQ: 0 ANSI:
5
sd 0:0:0:0: [sda] 15646720 512-byte hardware sectors (8011 MB)
...
sd 0:0:0:0: [sda] 15646720 512-byte hardware sectors (8011 MB)
..
 sda: sda1
sd 0:0:0:0: [sda] Attached SCSI disk

colinux:~# fdisk -l
Disk /dev/sda: 8011 MB, 8011120640 bytes
247 heads, 62 sectors/track, 1021 cylinders
Units = cylinders of 15314 * 512 = 7840768 bytes
Disk identifier: 0x1ceab904


With, as suggested, scsi0=\device\harddisk2:

scsi0 : Cooperative Linux SCSI Adapter
scsi 0:0:0:0: Direct-Access     coLinux  CODISK           1.01 PQ: 0 ANSI:
5
coscsi0: unable to open device! rc: 1
coscsi0: unable to open device! rc: 1
coscsi0: unable to open device! rc: 1
coscsi0: unable to open device! rc: 1
sd 0:0:0:0: [sda] READ CAPACITY failed
sd 0:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x00
sd 0:0:0:0: [sda] Sense not available.
...
sd 0:0:0:0: [sda] Attached SCSI disk

colinux:~# fdisk -l
colinux:~#

I  haven't tried with the \\.\PhysicalDriveX.. syntax, because the
previous version of the tool I'm making, wich is just a kind of dd but in
windows, uses \device\harddiskX\Partition0 for writting raw binary disk
images, with MBR and usually 4 partitions, and works fine.

References:
* From http://www.cygwin.com/cygwin-ug-net/using-specialnames.html

The new fixed POSIX names are mapped to NT internal devices as follows:
...
/dev/sda	        \device\harddisk0\partition0	(whole disk)
/dev/sda1	\device\harddisk0\partition1	(first partition)
...
/dev/sda15	\device\harddisk0\partition15	(fifteenth partition

So,

/dev/sda  is like \device\harddisk0\partition0
/dev/sda1 is like \device\harddisk0\partition1

The partition numbers start with 1, not with 0. In windows the partition0
is then reserved for the whole disk, wich is just what I need to access in
colinux


Germán

----------------------------------------------------------------------

Comment By: Peter Kuznetsov (peter_kuznetsov)
Date: 2009-11-20 14:09

Message:
Please, read about "scsiX=..." parameter in "colinux-daemon.txt" more
carefully:
        ...
        <path to image file> can be a raw disk drive, with format
        "\\.\PhysicalDriveX", where X starts with 0 for first harddisk. Be
        carefully with these configs, you risk datas on your drive C:.
        Don't mount a partition that is in use on windows side!
        ...

"\\.\PhysicalDriveX", but not "\\.\PhysicalDriveX\PartitionY".

Peter.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-11-20 13:31

Message:
Article "HOW TO: Create Multiple Partitions by Using the Bmpart.exe Tool in
Automated Deployment Services"
(http://support.microsoft.com/?scid=kb%3Ben-us%3B821303&x=14&y=11 )
describes only input parameters for Bmpart.exe: "The DeviceName PARAMETER,
\device\harddisk0\partition0, refers to the whole hard disk", not the
structure of the hard disk.  Bmpart.exe can extract  the whole hard disk
NAME "\device\harddisk0" from the string "\device\harddisk0\partition0".

What way and why it will be done "mkfs.ext3"? This program has no idea
that somewhere on  the NT-side you made a mistake in the parameters of
another program, "colinux-daemon.exe". 

Peter.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2009-11-20 12:05

Message:
I know, Peter. I didn't say otherwise. 

Read again my message. I'm only stating that, in Windows block device
nomenclature, ...\Partition0 is the whole disk
I don't like it that way, and would rather prefer \Device\HarddiskN as the
whole disk, but ask MS why is it like that.

If you don't belive it, ok. 
quote:  "The DeviceName parameter, \device\harddisk0\partition0, refers to
the whole hard disk."

(taken from
http://support.microsoft.com/?scid=kb%3Ben-us%3B821303&x=14&y=11 )


----------------------------------------------------------------------

Comment By: Peter Kuznetsov (peter_kuznetsov)
Date: 2009-11-19 15:17

Message:
Each Harddisk has only one Master Boot Record (512 byte sector at the very
beging of the  disk with partition table at the end of the MBR) . Each
partion has own boot sector, also 512 bytes, but wihout  partition table.
Please read documentation, for example
http://en.wikipedia.org/wiki/Master_boot_record

Peter.

----------------------------------------------------------------------

Comment By: German Salvador (germansalvador)
Date: 2009-11-19 09:02

Message:
As far as I know, \Device\HarddiskN\Partition0 refers to the whole device,
including MBR and all partitions. I'm, using it like that in other tool
without problems for a long time. I need access to the MBR because I need
to repartition the device.

About the other comment, I had a normal usage pattern while mkfs'ing the
disk, I opened other windows, change active focus, etc. I didn't did any
heavy task, but I was neither frozen while it worked. 

The Flash disk didn't had associated any drive letter, either.

German

----------------------------------------------------------------------

Comment By: Peter Kuznetsov (peter_kuznetsov)
Date: 2009-11-17 18:34

Message:
Just now I've noticed the error in your parameter:
scsi0=\Device\Harddisk2\Partition0 <== scsi0 is disk with Master Boot
Record, it is NOT partition.

When you run 'mkfs.ext3 /dev/sda1', you are trying to use  /dev/sda1 as
"the partition of of the partition", not as the partition of of the disk.
  
Your should use scsi0=\Device\Harddisk2 
(without '\Partition0)

Peter.


----------------------------------------------------------------------

Comment By: Peter Kuznetsov (peter_kuznetsov)
Date: 2009-11-17 17:02

Message:
Before 20091115 snapshot I've had the similar error. With 20091115
everything works. But you and me have different preconditions:

      My case                                            Your case 
        Image on hard drive                             USB pen drive 
        Only while switching NT processes    ???
 
When I've tested new SVN revision r1293, have tried only "simple" magic: 
  1. Open "Process Explorer" window.
  2. While 'mkfs' working, mouse clicked at "Process Explorer" and back at
"colinux-console-nt".

For previous revision with this two conditions the error was reproduced.
With last revision - not. 

If you want somebody to reproduce this error, please write, what have you
exactly did while 'mkfs.ext3' worked? I mean your activity with mouse,
keyboard, or other user interface input devices, which coLinux console was
used and so on. Some NT processes may block (lock) devices for it's
"individual use" and it is erroneus to work with  the drive or partition 
at this time from coLinux. So your "magic" may be much complicated than my.

Then I can check three USB Flash Drives of various vendors: 4, 8, and 32
Gb.

Peter.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2899010&group_id=98788

[coLinux-devel] [ colinux-Bugs-2780261 ] ttyS0: BUG: scheduling while atomic

[SourceForge.net <no...@so...>]

Bugs item #2780261, was opened at 2009-04-24 10:43
Message generated for change (Comment added) made by henryn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2780261&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Crash / BSOD
Group: v0.7.x (release)
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Henry N. (henryn)
Summary: ttyS0: BUG: scheduling while atomic

Initial Comment:
I'm developing a serial driver for NTPD that opens a symbolic link to /dev/ttyS0, and copies some bytes to a PTY. After a few minutes of operation, it crashes NTPD (although sshd and vncserver continue to work). My kernel command line is simply root=/dev/cobd0, and the serial port is set up with ttys0=COM3,"BAUD=9600 PARITY=n DATA=8 STOP=1 dtr=on rts=on". I have attached the text of the bug notification.

I'm using Windows 2000 as the host system, with Debian 5.0 running on coLinux 0.7.4-rc1. Incidentally, this bug seems to be a less severe form of one I encountered under 0.7.3, which occured under exactly the same circumstances, but brought the entire system crashing instead of just NTPD and the coLinux console.

----------------------------------------------------------------------

>Comment By: Henry N. (henryn)
Date: 2011-02-06 21:44

Message:
coLinux 0.7.9 with kernel 2.6.33.7 uses a new implementation for serial
device.
Committed as SVN revision 1544.
This bug we can close now.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622063&aid=2780261&group_id=98788

[coLinux-devel] [ colinux-Feature Requests-3109149 ] Reiserfs baked in the kernel like v0.7.7.1

[SourceForge.net <no...@so...>]

Feature Requests item #3109149, was opened at 2010-11-14 17:24
Message generated for change (Comment added) made by henryn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=3109149&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reiserfs baked in the kernel like v0.7.7.1

Initial Comment:
Hi,

I have been using version 0.7.7.1 for a while and it worked great. Today I decided to upgrade to 0.7.8.
But now my virtual machines don't want to boot anymore. I tried reverting to 0.7.7.1 and everything seems fine again.

With v0.7.8 I get this as the last couple of messages:

VFS: Mounted root (ext2 filesystem) on device 1:0.
EXT3-fs (hda): error: can't find ext3 filesystem on dev hda.
EXT2-fs (hda): error: can't find an ext2 filesystem on dev hda.
EXT4-fs (hda): VFS: Can't find ext4 filesystem
ISOFS: Unable to identify CD-ROM format.
List of all partitions:
0300         2097152 hda (driver?)
No filesystem could mount root, tried:  ext3 ext2 ext4 iso9660
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(3,0)

Especially this line is interesting: "No filesystem could mount root, tried:  ext3 ext2 ext4 iso9660"
Because I know the filesystem is actually reiserfs.

It seems to me that older versions of colinux had the reiserfs module baked in so it was always available. When I look in the vmlinux-modules.tar.gz for both versions I see a reiserfs module in the one for version 0.7.8 and it's not present in 0.7.7.1.

The question: are my assessments correct? And if so, is the baked in reiserfs module coming back?
And if not, what is the reason it has been made a module instead of baked in?

Greetings,
Keith

----------------------------------------------------------------------

>Comment By: Henry N. (henryn)
Date: 2011-02-06 21:39

Message:
Reiserfs is enabled in current release candidate.
Close this tracker now.

----------------------------------------------------------------------

Comment By: Keith (keith3056)
Date: 2010-11-16 12:35

Message:
Thanks Henry.
Case closed on my part.

----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2010-11-14 22:06

Message:
There was no specific condition to have Reiserfs as module, unless to have
faster build in very first experiences of kernel porting and forgotten
later to enable it as build in.

Reiserfs is compiled in again now. Please use todays snapshot of devel
from SVN revision 1546.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=3109149&group_id=98788

[coLinux-devel] [ colinux-Feature Requests-3094228 ] Request: CONFIG_KEYS

[SourceForge.net <no...@so...>]

Feature Requests item #3094228, was opened at 2010-10-24 18:05
Message generated for change (Comment added) made by henryn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=3094228&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Mantas (grawity)
>Assigned to: Henry N. (henryn)
Summary: Request: CONFIG_KEYS

Initial Comment:
I'm using coLinux mainly to access the filesystems of a dual-boot Linux installation, and it works really well... Except I set up eCryptFS yesterday, and it requires kernel keyring support:

    "Security options"/"Enable access key retention support" (CONFIG_KEYS)

Can this be added to coLinux kernel?

(Right now I'm using http://www.henrynestler.com/colinux/autobuild/devel-20100920/)

----------------------------------------------------------------------

>Comment By: Henry N. (henryn)
Date: 2011-02-06 21:36

Message:
CONFIG_KEYS is enabled in stable release candidate.
I will close this tracker here.

----------------------------------------------------------------------

Comment By: Mantas (grawity)
Date: 2010-11-11 23:28

Message:
Thanks, eCryptFS is working now.

(Although for some reason, "ecryptfs-mount-private" does not insert the
apropriate FNEK for file name decryption, as it would do in the dualbooted
system. I'll try to figure it out later.)

----------------------------------------------------------------------

Comment By: Henry N. (henryn)
Date: 2010-11-10 00:25

Message:
CONFIG_KEYS and CONFIG_ECRYPT_FS are enabled in SVN rev 1542 now, see
snapshot
https://sourceforge.net/projects/colinux/files/Snapshots/devel-20101109-Snapshot/

Please tell if you need more options to enable.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=3094228&group_id=98788

[coLinux-devel] [ colinux-Feature Requests-2891618 ] Driver name as parameter

[SourceForge.net <no...@so...>]

Feature Requests item #2891618, was opened at 2009-11-04 03:11
Message generated for change (Comment added) made by henryn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2891618&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: Next Release (example)
>Status: Closed
Priority: 5
Private: No
Submitted By: Peter Kuznetsov (peter_kuznetsov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Driver name as parameter

Initial Comment:
For debuging purposes it will be very usefull to add options for changing driver  name instead of linux.sys.
Example:
  colinux-daemon.exe --remove-driver-name colinux-0.80-00.sys
  colinux-daemon.exe --install-driver-name colinux-0.80-01.sys



----------------------------------------------------------------------

>Comment By: Henry N. (henryn)
Date: 2011-02-06 21:34

Message:
This would not need.
A colinux.sys must close to the same colinux-daemon.exe.
So, hold any versions of coLinux in a separate directory, and you can do:

cd .../coLinux-0.8.x
colinux-daemon.exe --remove-driver
colinux-daemon.exe --install-driver

cd .../coLinux-0.8.y
colinux-daemon.exe --remove-driver
colinux-daemon.exe --install-driver

It's very simple and I'm using this way for long time with multiple of
coLinux versions.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=2891618&group_id=98788

[coLinux-devel] autobuild org.colinux.devel 20110205 01:06:00 r1572

[coLinux a. <col...@he...>]

The autobuild system has detected a new revision in the source repository.
Review last changed from changelog.txt, also attached in mail.

Download the compiled version:
http://www.henrynestler.com/colinux/autobuild/devel-20110205/

 colinux-0.7.9-20110205.src.tgz  (1084084 Bytes)
 daemons-0.7.9-20110205.dbg.zip  (686854 Bytes)
 daemons-0.7.9-20110205.zip  (567032 Bytes)
 modules-2.6.33.7-co-0.7.9-r1572-20110205.tgz  (4131505 Bytes)
 vmlinux-2.6.33.7-co-0.7.9-r1572-20110205.zip  (2222181 Bytes)

Note, the autobuild compilation does not include an installer.
Remember to reload the driver with these commands:

	colinux-daemon.exe --remove-driver
	colinux-daemon.exe --install-driver

Inside coLinux please update modules as follow:

	rm -rf /lib/modules/*-co-*
	tar -xzf modules-*-co-*-20110205.tgz -C /

The autobuild compilations are not official releases of Cooperative Linux
software.  There is no warranty that any autobuild version is stable.  If
use this autobuild version, please give us feedback of your experience.

Job runs on machine with 64 bit version of gcc 4.3.2.
A service from http://gcc.gnu.org/wiki/CompileFarm

-- 
Lots of fun with newest version,
Henry Nestler
------------------------------------------------------------------------
r1572 | henryn | 2011-02-05 01:06:00 +0000 (Sat, 05 Feb 2011) | 2 lines
Changed paths:
   M /branches/devel/src/colinux/os/winnt/kernel/scsi.c

* scsi: Bugfix mapping SG array, that overlaps two pages. Debug message was like
"co_monitor_host_linuxvm_transfer_map:44|monitor: transfer map: bad size: 2520 (1216)"
------------------------------------------------------------------------
r1571 | henryn | 2011-02-05 00:58:42 +0000 (Sat, 05 Feb 2011) | 1 line
Changed paths:
   M /branches/devel/src/colinux/kernel/transfer.c
   M /branches/devel/src/colinux/os/winnt/kernel/block.c

* Text changes in comments.
------------------------------------------------------------------------
r1570 | henryn | 2011-02-04 22:07:14 +0000 (Fri, 04 Feb 2011) | 1 line
Changed paths:
   M /branches/devel/conf/linux-2.6.33.7-config

* Add iscsi kernel support (CONFIG_ISCSI_TCP) for kernel 2.6.33.7
------------------------------------------------------------------------

Re: [coLinux-devel] Faster colinux scsi driver, is it posible??

[Henry N. <hen...@ar...>]

On 02.02.2011 15:37, Sergio Paracuellos wrote:
> I'd like to know how to make faster the access to disk with the linux
> scsi driver and cobd in colinux.
>
> It is been limited or something for any special reason?

There are no limits. It goes fastest as it can. The limit is your 
(cache-)memory under Windows and the CPU speed.

scsi driver should be the fastest way to access.

-- 
Henry N.

[coLinux-devel] Faster colinux scsi driver, is it posible??

[Sergio P. <spa...@zi...>]

Hi all,

I'd like to know how to make faster the access to disk with the linux
scsi driver and cobd in colinux. 

It is been limited or something for any special reason?

Thanks in advance,

Cheers,

Sergio

-- 
Sergio Paracuellos
---------
ADVERTENCIA LEGAL: Este mensaje va dirigido, de manera exclusiva, a su
destinatario y contiene información confidencial y sujeta al secreto
profesional, cuya divulgación no está permitida por la ley. En de haber
recibido este mensaje por error, le rogamos que, de forma inmediata, nos
lo comunique mediante correo electrónico remitido a nuestra atención o a
través del teléfono  +34 914170710 y proceda a su eliminación, así como
a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos
que la distribución, copia o utilización de este mensaje, o de cualquier
documento adjunto, está prohibida por la ley.

[coLinux-devel] autobuild org.colinux.devel 20110127 21:07:52 r1568

[coLinux a. <col...@he...>]

The autobuild system has detected a new revision in the source repository.
Review last changed from changelog.txt, also attached in mail.

Download the compiled version:
http://www.henrynestler.com/colinux/autobuild/devel-20110127/

 colinux-0.7.9-20110127.src.tgz  (1083964 Bytes)
 daemons-0.7.9-20110127.dbg.zip  (686710 Bytes)
 daemons-0.7.9-20110127.zip  (566932 Bytes)
 modules-2.6.33.7-co-0.7.9-r1568-20110127.tgz  (4074883 Bytes)
 vmlinux-2.6.33.7-co-0.7.9-r1568-20110127.zip  (2222165 Bytes)

Note, the autobuild compilation does not include an installer.
Remember to reload the driver with these commands:

	colinux-daemon.exe --remove-driver
	colinux-daemon.exe --install-driver

Inside coLinux please update modules as follow:

	rm -rf /lib/modules/*-co-*
	tar -xzf modules-*-co-*-20110127.tgz -C /

The autobuild compilations are not official releases of Cooperative Linux
software.  There is no warranty that any autobuild version is stable.  If
use this autobuild version, please give us feedback of your experience.

Job runs on machine with 64 bit version of gcc 4.3.2.
A service from http://gcc.gnu.org/wiki/CompileFarm

-- 
Lots of fun with newest version,
Henry Nestler
------------------------------------------------------------------------
r1568 | henryn | 2011-01-27 21:07:52 +0000 (Thu, 27 Jan 2011) | 2 lines
Changed paths:
   M /branches/devel/patch/base-2.6.33.diff

* Don't "spurious_fault" for page faults outside of VMALLOC_START and VMALLOC_END.
  Fix endless page fault loops on 0xC0000000 (PAGE_OFFSET) for buggy code.
------------------------------------------------------------------------

[coLinux-devel] autobuild org.colinux.devel 20110125 21:49:51 r1567

[coLinux a. <col...@he...>]

The autobuild system has detected a new revision in the source repository.
Review last changed from changelog.txt, also attached in mail.

Download the compiled version:
http://www.henrynestler.com/colinux/autobuild/devel-20110125/

 colinux-0.7.9-20110125.src.tgz  (1083576 Bytes)
 daemons-0.7.9-20110125.dbg.zip  (686725 Bytes)
 daemons-0.7.9-20110125.zip  (566937 Bytes)
 modules-2.6.33.7-co-0.7.9-r1567-20110125.tgz  (4074969 Bytes)
 vmlinux-2.6.33.7-co-0.7.9-r1567-20110125.zip  (2222152 Bytes)

Note, the autobuild compilation does not include an installer.
Remember to reload the driver with these commands:

	colinux-daemon.exe --remove-driver
	colinux-daemon.exe --install-driver

Inside coLinux please update modules as follow:

	rm -rf /lib/modules/*-co-*
	tar -xzf modules-*-co-*-20110125.tgz -C /

The autobuild compilations are not official releases of Cooperative Linux
software.  There is no warranty that any autobuild version is stable.  If
use this autobuild version, please give us feedback of your experience.

Job runs on machine with 64 bit version of gcc 4.3.2.
A service from http://gcc.gnu.org/wiki/CompileFarm

-- 
Lots of fun with newest version,
Henry Nestler
------------------------------------------------------------------------
r1567 | henryn | 2011-01-25 21:49:51 +0000 (Tue, 25 Jan 2011) | 1 line
Changed paths:
   M /branches/devel/NEWS
   D /branches/devel/conf/linux-2.6.33.5-config
   A /branches/devel/conf/linux-2.6.33.7-config (from /branches/devel/conf/linux-2.6.33.5-config:1566)
   M /branches/devel/patch/base-2.6.33.diff
   D /branches/devel/patch/series-2.6.33.5
   A /branches/devel/patch/series-2.6.33.7 (from /branches/devel/patch/series-2.6.33.5:1566)
   M /branches/devel/patch/unionfs-2.5.4_for_2.6.33.diff

* Update Linux kernel to 2.6.33.7
------------------------------------------------------------------------

[coLinux-devel] autobuild org.colinux.devel 20110110 22:49:05 r1566

[coLinux a. <col...@he...>]

The autobuild system has detected a new revision in the source repository.
Review last changed from changelog.txt, also attached in mail.

Download the compiled version:
http://www.henrynestler.com/colinux/autobuild/devel-20110110/

 colinux-0.7.9-20110110.src.tgz  (1082448 Bytes)
 daemons-0.7.9-20110110.dbg.zip  (686705 Bytes)
 daemons-0.7.9-20110110.zip  (566921 Bytes)

Note, the autobuild compilation does not include an installer.
Remember to reload the driver with these commands:

	colinux-daemon.exe --remove-driver
	colinux-daemon.exe --install-driver

The vmlinux and modules are up to date. Please use last version from
http://www.henrynestler.com/colinux/autobuild/devel-20110109/

The autobuild compilations are not official releases of Cooperative Linux
software.  There is no warranty that any autobuild version is stable.  If
use this autobuild version, please give us feedback of your experience.

Job runs on machine with 64 bit version of gcc 4.3.2.
A service from http://gcc.gnu.org/wiki/CompileFarm

-- 
Lots of fun with newest version,
Henry Nestler
------------------------------------------------------------------------
r1566 | henryn | 2011-01-10 22:49:05 +0000 (Mon, 10 Jan 2011) | 2 lines
Changed paths:
   M /branches/devel/src/colinux/kernel/monitor.c
   M /branches/stable/src/colinux/kernel/monitor.c

* console: Bugfix offset calculation breakage got BSOD (Vladislav Grishenko).
  Bug was injected by adding macro co_offsetof at revision r1560.
------------------------------------------------------------------------

Re: [coLinux-devel] offset calculation breakage

[Vladislav G. <the...@ma...>]

Dear Henry,

> OK. That give the test result:
> 10 5 10 10
> 
> Is the "MEMBER + const" right in usage of that macro?
> Or is that a side effect in calculation?

It's right only within braces but the logic isn't good due non clear struct
pointer arithmetics.
Your committed variant seems to be more readable and fixes my issue, of
course.

Thank you and
Best Regards, theMIROn
ICQ: 303357
Skype: the.miron

> -----Original Message-----
> From: Henry Nestler [mailto:hen...@ar...]
> Sent: Tuesday, January 11, 2011 5:01 AM
> To: Vladislav Grishenko
> Cc: col...@li...
> Subject: Re: [coLinux-devel] offset calculation breakage
> 
> Hello Vladislav,
> 
> On 11.01.2011 00:13, Vladislav Grishenko wrote:
> > Dear Henry,
> > Sure it was't work the way you wrote
> >> #define co_offsetof(TYPE, MEMBER) ((int)&((TYPE *)0)->MEMBER)
> > But proposed define had member-whatever-it-contains bracket escaping
> >> #define co_offsetof(TYPE, MEMBER) ((int) (&((TYPE *)0)->MEMBER))
> > So, with MEMBER == field+const it will be equal to start_of_field +
> > const*size_of_filed
> 
> OK. That give the test result:
> 10 5 10 10
> 
> Is the "MEMBER + const" right in usage of that macro?
> Or is that a side effect in calculation?
> 
> > Anyway, I'd like to see it fixed in svn :) Btw, there's a lot of
> > places with old style calculations, I mean without co_offsetof usage,
> > even right several lines below the discussing line.
> 
> I only changed that line in revision 1560, because the GCC 4.4.1 under
Linux
> as host has a warning.
> If you have more such changes, be welcome.
> 
> --
> Henry N.
> 
> 
>
----------------------------------------------------------------------------
--
> Gaining the trust of online customers is vital for the success of any
company
> that requires sensitive data to be transmitted over the Web.   Learn how
to
> best implement a security strategy that keeps consumers' information
> secure
> and instills the confidence they need to proceed with transactions.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel

Re: [coLinux-devel] offset calculation breakage

[Henry N. <hen...@ar...>]

Hello Vladislav,

On 11.01.2011 00:13, Vladislav Grishenko wrote:
> Dear Henry,
> Sure it was't work the way you wrote
>> #define co_offsetof(TYPE, MEMBER) ((int)&((TYPE *)0)->MEMBER)
> But proposed define had member-whatever-it-contains bracket escaping
>> #define co_offsetof(TYPE, MEMBER) ((int) (&((TYPE *)0)->MEMBER))
> So, with MEMBER == field+const it will be equal to start_of_field +
> const*size_of_filed

OK. That give the test result:
10 5 10 10

Is the "MEMBER + const" right in usage of that macro?
Or is that a side effect in calculation?

> Anyway, I'd like to see it fixed in svn :)
> Btw, there's a lot of places with old style calculations, I mean without
> co_offsetof usage,  even right several lines below the discussing line.

I only changed that line in revision 1560, because the GCC 4.4.1 under 
Linux as host has a warning.
If you have more such changes, be welcome.

-- 
Henry N.

Re: [coLinux-devel] offset calculation breakage

[Vladislav G. <the...@ma...>]

Dear Henry,
Sure it was't work the way you wrote
> #define co_offsetof(TYPE, MEMBER) ((int) &((TYPE *)0)->MEMBER)

But proposed define had member-whatever-it-contains bracket escaping
> #define co_offsetof(TYPE, MEMBER) ((int) (&((TYPE *)0)->MEMBER))
So, with MEMBER == field+const it will be equal to start_of_field +
const*size_of_filed
Anyway, I'd like to see it fixed in svn :)
Btw, there's a lot of places with old style calculations, I mean without
co_offsetof usage,  even right several lines below the discussing line.

Best Regards, theMIROn
ICQ: 303357
Skype: the.miron


> -----Original Message-----
> From: Henry Nestler [mailto:hen...@ar...]
> Sent: Tuesday, January 11, 2011 3:41 AM
> To: Vladislav Grishenko
> Cc: col...@li...
> Subject: Re: offset calculation breakage
> 
> Hello Vladislav,
> 
> 
> On 10.01.2011 21:36, Vladislav Grishenko wrote:
> > Dear Henry,
> >
> > My Windows 7 x86 installation goes into BSOD right on/after console
> attach.
> > I've bisected it to recent r1560 changeset introduced co_offsetof macro.
> >
> >> size = (char*)(&message->putcs + 1) - (char*)message +
> >> bytes_per_line;
> > Original construction means the struct length, excluding the member
> > plus size of one member, not its offset actually.
> >
> >> #define co_offsetof(TYPE, MEMBER) ((int)&((TYPE *)0)->MEMBER) size =
> >> co_offsetof(co_console_message_t, putcs) + 1 + bytes_per_line;
> > New one means the struct length excluding the member + one byte,
> > that's seems wrong.
> >
> > So, to keep co_offsetof macro and restore binary compability, I
> > suggest following changes:
> >> #define co_offsetof(TYPE, MEMBER) ((int) (&((TYPE *)0)->MEMBER)) size
> >> = co_offsetof(co_console_message_t, putcs + 1) + bytes_per_line;
> 
> many thanks for pointing to that bug!
> 
> You are right, that this should give the size for struct without the data
self.
> The +1 was to point directly behind the element "putcs".
> Your changes was not working on my test with gcc 4.4.1:
> 
> // Building:
> //   DIR=$HOME/colinux/build/devel-gcc412.svn
> //   gcc -m32 -I$DIR/linux-2.6.33.5-source/include
> -I$DIR/linux-2.6.33.5-build/include
> -I$DIR/linux-2.6.33.5-source/arch/x86/include foo.c
> 
> #include <stdio.h>
> #include <linux/cooperative.h>
> 
> #define bytes_per_line 0
> #define co_offsetof(TYPE, MEMBER) ((int) &((TYPE *)0)->MEMBER)
> 
> int main()
> {
>      co_console_message_t*<->message;
>      int size1 = (char*)(&message->putcs + 1) - (char*)message +
> bytes_per_line;    // old
>      int size2 = co_offsetof(co_console_message_t, putcs) + 1 +
> bytes_per_line;    // Henry
>      int size3 = co_offsetof(co_console_message_t, putcs + 1) +
> bytes_per_line;    // Vladislav
>      int size4 = co_offsetof(co_console_message_t, putcs.data) +
> bytes_per_line;    // right
>      return printf("%d %d %d %d\n", size1, size2, size3, size4); }
> 
> Result:
> 10 5 5 10
> 
> So, the right calculation would be:
> 
> -       size = co_offsetof(co_console_message_t, putcs) + 1 +
> bytes_per_line;
> +       size = co_offsetof(co_console_message_t, putcs.data) +
> bytes_per_line;
> 
> --
> Henry N.

Re: [coLinux-devel] offset calculation breakage

[Henry N. <hen...@ar...>]

Hello Vladislav,


On 10.01.2011 21:36, Vladislav Grishenko wrote:
> Dear Henry,
>
> My Windows 7 x86 installation goes into BSOD right on/after console attach.
> I've bisected it to recent r1560 changeset introduced co_offsetof macro.
>
>> size = (char*)(&message->putcs + 1) - (char*)message + bytes_per_line;
> Original construction means the struct length, excluding the member plus
> size of one member, not its offset actually.
>
>> #define co_offsetof(TYPE, MEMBER) ((int)&((TYPE *)0)->MEMBER)
>> size = co_offsetof(co_console_message_t, putcs) + 1 + bytes_per_line;
> New one means the struct length excluding the member + one byte, that's
> seems wrong.
>
> So, to keep co_offsetof macro and restore binary compability, I suggest
> following changes:
>> #define co_offsetof(TYPE, MEMBER) ((int) (&((TYPE *)0)->MEMBER))
>> size = co_offsetof(co_console_message_t, putcs + 1) + bytes_per_line;

many thanks for pointing to that bug!

You are right, that this should give the size for struct without the 
data self.
The +1 was to point directly behind the element "putcs".
Your changes was not working on my test with gcc 4.4.1:

// Building:
//   DIR=$HOME/colinux/build/devel-gcc412.svn
//   gcc -m32 -I$DIR/linux-2.6.33.5-source/include 
-I$DIR/linux-2.6.33.5-build/include 
-I$DIR/linux-2.6.33.5-source/arch/x86/include foo.c

#include <stdio.h>
#include <linux/cooperative.h>

#define bytes_per_line 0
#define co_offsetof(TYPE, MEMBER) ((int) &((TYPE *)0)->MEMBER)

int main()
{
     co_console_message_t*<->message;
     int size1 = (char*)(&message->putcs + 1) - (char*)message + 
bytes_per_line;    // old
     int size2 = co_offsetof(co_console_message_t, putcs) + 1 + 
bytes_per_line;    // Henry
     int size3 = co_offsetof(co_console_message_t, putcs + 1) + 
bytes_per_line;    // Vladislav
     int size4 = co_offsetof(co_console_message_t, putcs.data) + 
bytes_per_line;    // right
     return printf("%d %d %d %d\n", size1, size2, size3, size4);
}

Result:
10 5 5 10

So, the right calculation would be:

-       size = co_offsetof(co_console_message_t, putcs) + 1 + 
bytes_per_line;
+       size = co_offsetof(co_console_message_t, putcs.data) + 
bytes_per_line;

-- 
Henry N.

[coLinux-devel] [ colinux-Feature Requests-3141166 ] Multiple initramfs (initrd.gz)

[SourceForge.net <no...@so...>]

Feature Requests item #3141166, was opened at 2010-12-21 09:58
Message generated for change (Comment added) made by ok-man
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=3141166&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Chris (ok-man)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multiple initramfs (initrd.gz)

Initial Comment:
Is it possible to specify multiple initramfs to be extracted during boot.  This can be useful if you want to create a generic initramfs (or use one from a distro) and then add modifications in separate files (for example a custom /init or extract the coLinux modules).  I think it will be a simple way to convert a distro (would this be useful for running from different types of iso images?).  It is also a convenient if you need to upgrade a distro - without needing to re-master the initramfs.  You can specify multiple initramfs archives in grub and syslinux config.  I have tried using multiple initrd lines in coLinux but this did not seem to work.

The kernel will extract these files in the order they are specified.  The files will all be extracted into the same place, this means files from later archives will overwrite former ones if they have the same filename.  Also note that it is possible to have an initramfs archive embedded in the kernel as well as extra ones specified in the config.  The archive in the kernel will be extracted first, followed by the ones in the config.

----------------------------------------------------------------------

>Comment By: Chris (ok-man)
Date: 2011-01-10 21:49

Message:
This would help with my dual-boot & colinux installation.  I would not have
to tamper with my standard install if I could overlay when using colinux.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=3141166&group_id=98788

[coLinux-devel] offset calculation breakage

[Vladislav G. <the...@ma...>]

Dear Henry,

My Windows 7 x86 installation goes into BSOD right on/after console attach.
I've bisected it to recent r1560 changeset introduced co_offsetof macro.

> size = (char*)(&message->putcs + 1) - (char*)message + bytes_per_line;
Original construction means the struct length, excluding the member plus
size of one member, not its offset actually.

> #define co_offsetof(TYPE, MEMBER) ((int) &((TYPE *)0)->MEMBER)
> size = co_offsetof(co_console_message_t, putcs) + 1 + bytes_per_line; 
New one means the struct length excluding the member + one byte, that's
seems wrong.

So, to keep co_offsetof macro and restore binary compability, I suggest
following changes:
> #define co_offsetof(TYPE, MEMBER) ((int) (&((TYPE *)0)->MEMBER))
> size = co_offsetof(co_console_message_t, putcs + 1) + bytes_per_line;

And, kindly please, is it possible to make daemons package to be built with
svn revision too.
Both patches attached, works for me.
Thank you.

Best Regards, theMIROn
ICQ: 303357
Skype: the.miron

[coLinux-devel] autobuild org.colinux.devel 20110109 21:09:01 r1564

[coLinux a. <col...@he...>]

The autobuild system has detected a new revision in the source repository.
Review last changed from changelog.txt, also attached in mail.

Download the compiled version:
http://www.henrynestler.com/colinux/autobuild/devel-20110109/

 colinux-0.7.9-20110109.src.tgz  (1082468 Bytes)
 daemons-0.7.9-20110109.dbg.zip  (686686 Bytes)
 daemons-0.7.9-20110109.zip  (566893 Bytes)
 modules-2.6.33.5-co-0.7.9-r1564-20110109.tgz  (4074065 Bytes)
 vmlinux-2.6.33.5-co-0.7.9-r1564-20110109.zip  (2221940 Bytes)

Note, the autobuild compilation does not include an installer.
Remember to reload the driver with these commands:

	colinux-daemon.exe --remove-driver
	colinux-daemon.exe --install-driver

Inside coLinux please update modules as follow:

	rm -rf /lib/modules/*-co-*
	tar -xzf modules-*-co-*-20110109.tgz -C /

The autobuild compilations are not official releases of Cooperative Linux
software.  There is no warranty that any autobuild version is stable.  If
use this autobuild version, please give us feedback of your experience.

Job runs on machine with 64 bit version of gcc 4.3.2.
A service from http://gcc.gnu.org/wiki/CompileFarm

-- 
Lots of fun with newest version,
Henry Nestler
------------------------------------------------------------------------
r1564 | henryn | 2011-01-09 21:09:01 +0000 (Sun, 09 Jan 2011) | 1 line
Changed paths:
   M /branches/devel/patch/base-2.6.33.diff
   M /branches/devel/patch/video-core.diff

* cofb: Move function co_console_message0 out from cooperative_internal.h, into fbcon.c.
------------------------------------------------------------------------

[coLinux-devel] autobuild org.colinux.devel 20110107 20:27:49 r1563

[coLinux a. <col...@he...>]

The autobuild system has detected a new revision in the source repository.
Review last changed from changelog.txt, also attached in mail.

Download the compiled version:
http://www.henrynestler.com/colinux/autobuild/devel-20110107/

 colinux-0.7.9-20110107.src.tgz  (1082424 Bytes)
 daemons-0.7.9-20110107.dbg.zip  (686712 Bytes)
 daemons-0.7.9-20110107.zip  (566932 Bytes)

Note, the autobuild compilation does not include an installer.
Remember to reload the driver with these commands:

	colinux-daemon.exe --remove-driver
	colinux-daemon.exe --install-driver

The vmlinux and modules are up to date. Please use last version from
http://www.henrynestler.com/colinux/autobuild/devel-20101130/

The autobuild compilations are not official releases of Cooperative Linux
software.  There is no warranty that any autobuild version is stable.  If
use this autobuild version, please give us feedback of your experience.

Job runs on machine with 64 bit version of gcc 4.3.2.
A service from http://gcc.gnu.org/wiki/CompileFarm

-- 
Lots of fun with newest version,
Henry Nestler
------------------------------------------------------------------------
r1563 | henryn | 2011-01-07 20:27:49 +0000 (Fri, 07 Jan 2011) | 1 line
Changed paths:
   M /branches/devel/configure

* configure: ABI check much simpler, without temp file.
------------------------------------------------------------------------

[coLinux-devel] [ colinux-Feature Requests-3141166 ] Multiple initramfs (initrd.gz)

[SourceForge.net <no...@so...>]

Feature Requests item #3141166, was opened at 2010-12-21 09:58
Message generated for change (Tracker Item Submitted) made by ok-man
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=3141166&group_id=98788

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Chris (ok-man)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multiple initramfs (initrd.gz)

Initial Comment:
Is it possible to specify multiple initramfs to be extracted during boot.  This can be useful if you want to create a generic initramfs (or use one from a distro) and then add modifications in separate files (for example a custom /init or extract the coLinux modules).  I think it will be a simple way to convert a distro (would this be useful for running from different types of iso images?).  It is also a convenient if you need to upgrade a distro - without needing to re-master the initramfs.  You can specify multiple initramfs archives in grub and syslinux config.  I have tried using multiple initrd lines in coLinux but this did not seem to work.

The kernel will extract these files in the order they are specified.  The files will all be extracted into the same place, this means files from later archives will overwrite former ones if they have the same filename.  Also note that it is possible to have an initramfs archive embedded in the kernel as well as extra ones specified in the config.  The archive in the kernel will be extracted first, followed by the ones in the config.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=622066&aid=3141166&group_id=98788