[parisc-linux] Printing problem with HP9000 712/80 and two more questions

[parisc-linux] Printing problem with HP9000 712/80 and two more questions

[Vilmos Soti]

Hello,

I have an old HP9000 712/80 box which I would like to use as an
internal file/print server. The printing doesn't work. I tried
the original kernel which came with Debian, I also tried to cross
compile (on a much faster P3 600MHz) numerous kernels, and I also
tried 2.4.20-pa18 from ftp://ftp.parisc-linux.org. I tried to
permute every option regarding the printer in the kernel config
file, and in all cases, including the default Debian kernel and
the 2.4.20-pa18, I consistently cannot get the printer work.

The printer is a HP LaserJet 1100 connected to the parallel port. The
printer works fine on an Intel box, so it is hopefully not a printer
problem. Whenever I try to print from the HPPA box (even something
like "cat /etc/passwd > /dev/lp0"), absolutely nothing happens.

Here are some relevant files:
cat /proc/iomem
00000000-03ffffff : System RAM
  00000000-000009ff : PDC data (Page Zero)
  00100000-002fbfff : Kernel code
  002fc000-003fbcd3 : Kernel data
f0100000-f01fffff : Lasi
  f0100000-f0100fff : Lasi
  f0102000-f0102fff : Parallel
  f0104000-f0104fff : Lasi Harmony
  f0105000-f0105fff : Serial RS232
  f0106000-f0106fff : Lasi SCSI
  f0107000-f0107fff : Apricot
  f0108000-f010800f : keyboard
  f0108100-f01090ff : Lasi psaux
f0500000-f05fffff : Lasi
  f0500000-f0500fff : Lasi
  f0505000-f0505fff : Serial RS232
f8000000-f8000fff : sti (native)
f8100000-f84fffff : stifb mmio
f9000000-f9ffffff : stifb
fff80000-fffaffff : Central Bus
fffb0000-fffdffff : Local Broadcast
  fffbe000-fffbefff : CPU
fffe0000-ffffffff : Global Broadcast

/proc/interrupts
          CPU00
 32:   37262217      PARISC-CPU  timer
 33:     176500      PARISC-CPU  lasi
 34:          0      PARISC-CPU  lasi
 69:       1022            Lasi  keyboard
 82:          9            Lasi  harmony
 86:     126441            Lasi  lasi710
 87:      49028            Lasi  i82596
 88:          0            Lasi  parport0

Here is the dmesg of the box. I won't break the lines so it is
easier to read.

Linux version 2.4.20-pa18 (bame@dsl2) (gcc version 3.0.3) #1 Fri Dec 27 06:12:20 MST 2002
FP[0] enabled: Rev 1 Model 13
The 32-bit Kernel has started...
Determining PDC firmware type: Snake.
model 00006010 00000481 00000000 00000000 77da0338 00000000 00000004 00000072 00000072
vers  00000009
model 9000/712
Total Memory: 64 Mb
pagetable_init
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/sda2 HOME=/ console=tty0 sti=1 sti_font=VGA8x16 TERM=linux palo_kernel=2/boot/vmlinux
Console: colour dummy device 160x64
Calibrating delay loop... 79.66 BogoMIPS
Memory: 61624k available
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Searching for devices...
Found devices:
1. Gecko 80 GSC Core Graphics (10) at 0xf8000000 [1], versions 0x1c, 0x0, 0x85
2. Gecko 80 Core BA (11) at 0xf0100000 [2], versions 0x1c, 0x0, 0x81
3. Gecko 80 Core SCSI (10) at 0xf0106000 [2/0/1], versions 0x1c, 0x0, 0x82
4. Gecko 80 Core LAN (802.3) (10) at 0xf0107000 [2/0/2], versions 0x1c, 0x0, 0x8a
5. Gecko 80 Core RS-232 (10) at 0xf0105000 [2/0/4], versions 0x1c, 0x0, 0x8c
6. Gecko 80 Core Centronics (10) at 0xf0102000 [2/0/6], versions 0x1c, 0x0, 0x74
7. Gecko 80 Audio (10) at 0xf0104000 [2/0/8], versions 0x1c, 0x0, 0x7b
8. Gecko 80 Core PC Floppy (10) at 0xf010a000 [2/0/10], versions 0x1c, 0x0, 0x83
9. Gecko 80 Core PS/2 Port (10) at 0xf0108000 [2/0/11], versions 0x1c, 0x0, 0x84
10. Gecko 80 Core PS/2 Port (10) at 0xf0108100 [2/0/12], versions 0x1c, 0x0, 0x84
11. Gecko 80 Core BA (11) at 0xf0500000 [6], versions 0x1c, 0x0, 0x81
12. Gecko Optional RS-232 (10) at 0xf0505000 [6/0/4], versions 0x18, 0x0, 0x8c
13. Gecko 80 (712/80) (0) at 0xfffbe000 [8], versions 0x601, 0x0, 0x4
14. Memory (1) at 0xfffbf000 [9], versions 0x38, 0x0, 0x9
CPU(s): 1 x PA7100LC (PCX-L) at 80.000000 MHz
Lasi version 0 at 0xf0100000 found.
Lasi version 0 at 0xf0500000 found.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Gecko-style soft power switch enabled.
Starting kswapd
Journalled Block Device driver loaded
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
parport_init_chip: initialize bidirectional-mode.
parport0: PC-style at 0xf0102800, irq 88 [PCSPP,TRISTATE]
STI GSC/PCI graphics driver version 0.9
STI word mode ROM at f0080000, hpa at f8000000
STI id 2b4ded6d-40a00499, conforms to spec rev. 8.04
STI device: HPA208LC1280
Console: switching to colour frame buffer device 160x64
fb0: stifb 1280x1024-8 frame buffer device, id: 2b4ded6d, mmio: 0xf8100000
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at iomem 0xf0105800 (irq = 90) is a 16550A
ttyS01 at iomem 0xf0505800 (irq = 122) is a 16550A
PS/2 keyboard port at 0xf0108000 (irq 69) found, device attached.
PS/2 psaux port at 0xf0108100 (irq 69) found, no device attached.
lp0: using parport0 (interrupt-driven).
Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Found i82596 at 0xf0107000, IRQ 87
eth0: 82596 at 0xf0107000, 08 00 09 83 F6 4A IRQ 87.
82596.c $Revision: 1.30 $
SCSI subsystem driver Revision: 1.00
53c700: Version 2.8 By James.Bottomley@HansenPartnership.com
scsi0: 53c710 rev 2 
scsi0 : LASI SCSI 53c700
scsi0: (6:0) Synchronous at offset 8, period 100ns
  Vendor: MICROP    Model: 2112              Rev: 4024
  Type:   Direct-Access                      ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 6, lun 0
SCSI device sda: 2051460 512-byte hdwr sectors (1050 MB)
Partition check:
 sda: sda1 sda2 sda3
Lasi Harmony Audio driver V0.9a, h/w id 20, rev. 18 at 0xf0104000, IRQ 82
mice: PS/2 mouse device common for all mice
HP SDC: No SDC found.
HP SDC MLC: Registering the System Domain Controller's HIL MLC.
HP SDC MLC: Request for raw HIL ISR hook denied
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
raid5: measuring checksumming speed
   8regs     :    60.800 MB/sec
   8regs_prefetch:    60.800 MB/sec
   32regs    :    70.800 MB/sec
   32regs_prefetch:    70.800 MB/sec
raid5: using function: 32regs_prefetch (70.800 MB/sec)
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 266k freed
Adding Swap: 130836k swap-space (priority -1)
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,2), internal journal
eth0: link ok.


Now one thing I found is that the interrupt count for the
printer port doesn't increase even if I send a file to /dev/lp0
or print through the printer daemon. I tried to run
"tunelp /dev/lp0 -i 0", but it complained about invalied argument
to ioctl (maybe wasn't updated since 2.2?) and it says "using IRQ 88".

Anyone has any idea how to solve this problem?

And two more questions. Is the sound card full duplex? My standard
method of determinig, "cat /dev/audio > /dev/audio" told me that
"Device or resource busy" therefore it seems it is not. Is it true?

The other question. I am using emacs, and I regularly see these messages:

Jan  8 23:52:33 hp kernel: emacs(17795): unaligned access to 0x001cdaf2 at ip=0x0008937f
Jan  8 23:52:33 hp kernel: emacs(17795): unaligned access to 0x001cdaf2 at ip=0x0008930b

What are they?

TIA, Vilmos

Re: [parisc-linux] unaligned accesses

[Randolph Chung]

> The other question. I am using emacs, and I regularly see these messages:
> 
> Jan  8 23:52:33 hp kernel: emacs(17795): unaligned access to 0x001cdaf2 at ip=0x0008937f
> Jan  8 23:52:33 hp kernel: emacs(17795): unaligned access to 0x001cdaf2 at ip=0x0008930b
> 
> What are they?

Blame LaMont!
(yes, I'm just kidding, I've just been waiting for my chance to say
this... :-)

On a more serious note, on parisc load/stores to half-words, words,
doublewords have specific address alignment requirements. the message
usually means the program in question is buggy and is making unaligned
accesses. The unaligned access is trapped and emulated by the kernel, 
so normally the message itself is simply informational.

This is definitely a FAQ.... maybe we should add it to the list :)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] unaligned accesses

[jsoe0708]

>-- Original Message --
>From: Randolph Chung <randolph@tausq.org>
>To: parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] unaligned accesses
>Reply-To: Randolph Chung <randolph@tausq.org>
>Date: Thu, 9 Jan 2003 00:29:02 -0800
>
>
>> The other question. I am using emacs, and I regularly see these messag=
es:
>> 
>> Jan  8 23:52:33 hp kernel: emacs(17795): unaligned access to 0x001cdaf=
2
>at ip=3D0x0008937f
>> Jan  8 23:52:33 hp kernel: emacs(17795): unaligned access to 0x001cdaf=
2
>at ip=3D0x0008930b
>> 
>> What are they?
>
>Blame LaMont!
>(yes, I'm just kidding, I've just been waiting for my chance to say
>this... :-)
>
Do you think that this tcpdump pb is also related to Lamont job (to be ho=
nest
I do not remember what was it?):
...
Jan  9 09:59:58 fw01 kernel: tcpdump(4638): unaligned access to 0x0011e78=
a
at ip=3D0x0002ab83
Jan  9 09:59:34 fw01 kernel: tcpdump(4638): unaligned access to 0x0011e78=
e
at ip=3D0x0002ab83
...

>On a more serious note, on parisc load/stores to half-words, words,
>doublewords have specific address alignment requirements. the message
>usually means the program in question is buggy and is making unaligned

hmmm buggy: not always, the triky case is when you have to access to thos=
e
kind of data encapsulated into a structure. I do not yet find any workaro=
und
or how to fix this kind of pb. Any idea (gcc-3.3?)?

>accesses. The unaligned access is trapped and emulated by the kernel, 
>so normally the message itself is simply informational.
>
>This is definitely a FAQ.... maybe we should add it to the list :)
>
Yes, works fine but this consume a lot of CPU resources.

Joel


********************************************
Promo Tiscali ADSL: 35 Euros/mois, 1er mois et activation =3D 0 Euro http=
://adsl.tiscali.be

Re: [parisc-linux] unaligned accesses

[Randolph Chung]

> >Blame LaMont!
> >(yes, I'm just kidding, I've just been waiting for my chance to say
> >this... :-)
> >
> Do you think that this tcpdump pb is also related to Lamont job (to be honest
> I do not remember what was it?):

LaMont recently improved the unaligned handler to be more correct and
more robust... as well as handle more cases.
> ...
> Jan  9 09:59:58 fw01 kernel: tcpdump(4638): unaligned access to 0x0011e78a
> at ip=0x0002ab83
> Jan  9 09:59:34 fw01 kernel: tcpdump(4638): unaligned access to 0x0011e78e
> at ip=0x0002ab83
> ...

yes, tcpdump (and several other network tools) are known to generate a
lot of unaligned accesses.

> hmmm buggy: not always, the triky case is when you have to access to those
> kind of data encapsulated into a structure. I do not yet find any workaround
> or how to fix this kind of pb. Any idea (gcc-3.3?)?

eh? what do you mean? 

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] unaligned accesses

[jsoe0708]

>-- Original Message --
>Date: Thu, 9 Jan 2003 23:36:59 -0800
>From: Randolph Chung <randolph@tausq.org>
>To: jsoe0708@tiscali.be
>Cc: parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] unaligned accesses
>Reply-To: Randolph Chung <randolph@tausq.org>
>
>
...
>> hmmm buggy: not always, the triky case is when you have to access to
those
>> kind of data encapsulated into a structure. I do not yet find any work=
around
>> or how to fix this kind of pb. Any idea (gcc-3.3?)?
>
>eh? what do you mean? 
>
well I will try to find back the example I encounter (somewhere in jfs-1.=
0.23
IIRC)

Cheers,
    Joel

********************************************
Promo Tiscali ADSL: 35 Euros/mois, 1er mois et activation =3D 0 Euro http=
://adsl.tiscali.be

Re: [parisc-linux] unaligned accesses

[jsoe0708]

>-- Original Message --
>Date: Thu, 9 Jan 2003 23:36:59 -0800
>From: Randolph Chung <randolph@tausq.org>
>To: jsoe0708@tiscali.be
>Cc: parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] unaligned accesses
>Reply-To: Randolph Chung <randolph@tausq.org>
>
>
...
>
>> hmmm buggy: not always, the triky case is when you have to access to
those
>> kind of data encapsulated into a structure. I do not yet find any work=
around
>> or how to fix this kind of pb. Any idea (gcc-3.3?)?
>
>eh? what do you mean? 

Sorry, I met well a problem of unaligne access problem with fsck.jfs (wit=
h
kernel 2.4.19-pa24+jfs 1.0.23 support):
...
fsck.jfs(6995): unaligned access to 0xfaf00757 at ip=3D0x0002ee1b
fsck.jfs(6995): unaligned access to 0xfaf00757 at ip=3D0x0002ee37
fsck.jfs(6995): unaligned access to 0xfaf00757 at ip=3D0x0002ed3f
...

which occurs in fsckmsgs.c for ip=3D0x0002ee1b (for exapmple) at:

        strncpy(prlimit, msgprms[prmidx], prmval[prmidx]);
with 
...
extern char *msgprms[];
...
   int prmidx;
...    
   int16_t *prmval;

So it is not related with the struct problem I encounter.

I will try to find back this example.

Joel

PS:  with ext3 (which I use) problem I hesitate to install 2.4.20 and wai=
ting
for 2.4.21 and evms, jfs, xfs support for this system)

********************************************
Promo Tiscali ADSL: 35 Euros/mois, 1er mois et activation =3D 0 Euro http=
://adsl.tiscali.be

Re: [parisc-linux] unaligned accesses

[Matthieu Delahaye]

> >
> well I will try to find back the example I encounter (somewhere in jfs-1.0.23
> IIRC)
> 
> Cheers,
>     Joel

I remind a word access on a table of char at an odd index. Thought it
was reiserFS code.

Matthieu

Re: [parisc-linux] unaligned accesses

[jsoe0708]

>-- Original Message --
>From: jsoe0708@tiscali.be
>Subject: Re: [parisc-linux] unaligned accesses
>To: "Randolph Chung" <randolph@tausq.org>
>Cc: parisc-linux@lists.parisc-linux.org
>Date: Fri, 10 Jan 2003 09:24:40 +0100
>
>
>
>>-- Original Message --
>>Date: Thu, 9 Jan 2003 23:36:59 -0800
>>From: Randolph Chung <randolph@tausq.org>
>>To: jsoe0708@tiscali.be
>>Cc: parisc-linux@lists.parisc-linux.org
>>Subject: Re: [parisc-linux] unaligned accesses
>>Reply-To: Randolph Chung <randolph@tausq.org>
>>
>>
>...
>>> hmmm buggy: not always, the triky case is when you have to access to
>those
>>> kind of data encapsulated into a structure. I do not yet find any wor=
karound
>>> or how to fix this kind of pb. Any idea (gcc-3.3?)?
>>
>>eh? what do you mean?
>>
>well I will try to find back the example I encounter (somewhere in jfs-1=
.0.23
>IIRC)
>
Yes here it was in evms(1.1.0 since the bug was fix but it is still a sam=
ple
:-)

[this small example was composed of code coming from evms-1.1.0]
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

typedef u_int8_t  BOOLEAN;

#ifndef TRUE
  #define TRUE  1
#endif
#ifndef FALSE
  #define FALSE 0
#endif

struct partition {
    unsigned char boot_ind;     /* 0x80 - active */
    unsigned char head;     /* starting head */
    unsigned char sector;       /* starting sector */
    unsigned char cyl;      /* starting cylinder */
    unsigned char sys_ind;      /* What partition type */
    unsigned char end_head;     /* end head */
    unsigned char end_sector;   /* end sector */
    unsigned char end_cyl;      /* end cylinder */
    unsigned int start_sect;    /* starting sector counting from 0 */
    unsigned int nr_sects;      /* nr of sectors in partition */
};

BOOLEAN isa_null_partition_record(struct partition *p)
{
    int          i;
    u_int32_t   *uip =3D (u_int32_t *) p;

    for (i=3D0; i<4; i++) {
        if (*uip!=3D0x00) return FALSE;
    }

    return TRUE;
}

int main(int argc, char * * argv, char * * env) {

    struct partition p1, p2;

    p1.boot_ind=3D0;
    p1.head=3D0;
    p1.sector=3D0;
    p1.cyl=3D0;
    p1.sys_ind=3D0;
    p1.end_head=3D0;
    p1.end_sector=3D0;
    p1.end_cyl=3D0;
    p1.start_sect=3D0;
    p1.nr_sects=3D0;
 
    printf("Is that p1 is a null partition: %u\n", isa_null_partition_rec=
ord(&p1));

    p2.boot_ind=3D1;
    p2.head=3D2;
    p2.sector=3D3;
    p2.cyl=3D4;
    p2.sys_ind=3D5;
    p2.end_head=3D6;
    p2.end_sector=3D7;
    p2.end_cyl=3D8;
    p2.start_sect=3D9;
    p2.nr_sects=3D10;
 
    printf("Is that p2 is a null partition: %u\n", isa_null_partition_rec=
ord(&p2));
    return 0;
}

Unfortunately this doesn't reproduce the actual problem of which I save
the following traces (from the evms_vgscan 1.1.0: once again this was fix=

since next release):
...
(isa_valid_partition_record) file checks.c
part.start_sect add: 0x27116
part.start_sect    : 0
part.nr_sects   add: 0x2711a
part.nr_sects      : 0
p            add: 0x2710e
p.boot_ind   add: 0x2710e
p.head       add: 0x2710f
p.sector     add: 0x27110
p.cyl        add: 0x27111
p.sys_ind    add: 0x27112
p.end_head   add: 0x27113
p.end_sector add: 0x27114
p.end_cyl    add: 0x27115
p.start_sect add: 0x27116
p.start_sect    : 0
p.nr_sects   add: 0x2711a
p.nr_sects      : 0
p            add: 0x2710e
p.boot_ind   add: 0x2710e
p.head       add: 0x2710f
p.sector     add: 0x27110
p.cyl        add: 0x27111
p.sys_ind    add: 0x27112
p.end_head   add: 0x27113
p.end_sector add: 0x27114
p.end_cyl    add: 0x27115
p.start_sect add: 0x27116
p.start_sect    : 0
p.nr_sects   add: 0x2711a
p.nr_sects      : 0
...

in which we can see that p.start_sect (an int) address (0x27166 =3D=3D 16=
0102)
is not well align (160102/4=3D40025.5).

HTH,
    Joel


********************************************
Promo Tiscali ADSL: 35 Euros/mois, 1er mois et activation =3D 0 Euro http=
://adsl.tiscali.be

Re: [parisc-linux] unaligned accesses

[John David Anglin]

> >> hmmm buggy: not always, the triky case is when you have to access to
> those
> >> kind of data encapsulated into a structure. I do not yet find any workaround
> >> or how to fix this kind of pb. Any idea (gcc-3.3?)?
> >
> >eh? what do you mean? 
> >
> well I will try to find back the example I encounter (somewhere in jfs-1.0.23
> IIRC)

I think what Randolph is saying is that structures don't provide a machine
independent way of transfering data from one machine to another.  If you
want to do that, you need a machine independent specification for the data.
Having worked on code to decode realtime telemetry data from various
spacecraft, I know that you need to be very aware of type sizes, alignment
and endianness issues on each architecture.  The same kind of issues come
up in handling graphics data.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] unaligned accesses

[Randolph Chung]

> Unfortunately this doesn't reproduce the actual problem of which I save
> the following traces (from the evms_vgscan 1.1.0: once again this was fix
> since next release):

i'm not sure i correctly parsed what you wrote... the structure you
posted is fine, but that doesn't mean it cannot cause unaligned accesses
if used incorrectly.

for a simple example:
struct foo {
    int bar;
};

this structure if placed on the stack by gcc is always int-aligned. but
you can easily generate unaligned accesses from it:

void botch(void)
{
    char buf[1024];
    struct foo x;
    struct foo *a, *b;

    a = &x;
    b = (struct foo *)buf[2];

    printf("%d\n", a->bar); /* aligned */
    printf("%d\n", b->bar); /* unaligned! */
}

in this case, the structure gives you no guarantees that things will be
aligned properly.

it's also possible to have much more involved scenarios, (e.g. with
unions of things with different alignments), where things can get messed
up.... you need to carefully look at how the code works to debug these
things. while gcc may not be bug-free in this area, it's much more
likely to be an application bug than a gcc one.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] unaligned accesses

[Matthew Wilcox]

On Fri, Jan 10, 2003 at 11:51:41AM +0100, jsoe0708@tiscali.be wrote:
> PS:  with ext3 (which I use) problem I hesitate to install 2.4.20 and waiting
> for 2.4.21 and evms, jfs, xfs support for this system)

um, you use the data=ordered mount option (or whatever it was)?

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] unaligned accesses

[jsoe0708]

>-- Original Message --
>Date: Fri, 10 Jan 2003 17:08:13 +0000
>From: Matthew Wilcox <willy@debian.org>
>To: jsoe0708@tiscali.be
>Cc: Randolph Chung <randolph@tausq.org>,
>	parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] unaligned accesses
>
>
>On Fri, Jan 10, 2003 at 11:51:41AM +0100, jsoe0708@tiscali.be wrote:
>> PS:  with ext3 (which I use) problem I hesitate to install 2.4.20 and
waiting
>> for 2.4.21 and evms, jfs, xfs support for this system)
>
>um, you use the data=3Dordered mount option (or whatever it was)?
>
Good question? I will investigate and let you inform.

Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] unaligned accesses

[Thibaut VARENE]

On Fri, 10 Jan 2003 19:47:52 +0100
jsoe0708@tiscali.be wrote:

> 
> >-- Original Message --
> >Date: Fri, 10 Jan 2003 17:08:13 +0000
> >From: Matthew Wilcox <willy@debian.org>
> >To: jsoe0708@tiscali.be
> >Cc: Randolph Chung <randolph@tausq.org>,
> >	parisc-linux@lists.parisc-linux.org
> >Subject: Re: [parisc-linux] unaligned accesses
> >
> >
> >On Fri, Jan 10, 2003 at 11:51:41AM +0100, jsoe0708@tiscali.be wrote:
> >> PS:  with ext3 (which I use) problem I hesitate to install 2.4.20 and
> waiting
> >> for 2.4.21 and evms, jfs, xfs support for this system)
> >
> >um, you use the data=ordered mount option (or whatever it was)?
it was data=journal
see http://developers.slashdot.org/developers/02/12/02/0128206.shtml?tid=106

FWIW, the default option (used by most people) is data=journal, and is not affected by that bug. We've been using 2.4.20 with ext3 for weeks pretty safely here.


Thibaut VARENE
The PA/Linux ESIEE Team
http://pateam.esiee.fr/

Re: [parisc-linux] unaligned accesses

[Thibaut VARENE]

On Fri, 10 Jan 2003 23:13:13 +0100
"Thibaut VARENE" <varenet@esiee.fr> wrote:

I hate to reply to myself but I said crap in my previous mail.
All apologies:
> FWIW, the default option (used by most people) is data=journal, and is not affected by that bug. We've been using 2.4.20 with ext3 for weeks pretty safely here.
it was: "the default option is data=ordered" of course, which is safe.

HTH,


Thibaut VARENE
The PA/Linux ESIEE Team
http://pateam.esiee.fr/

Re: [parisc-linux] unaligned accesses

[Joel Soete]

Hi Thibaut

Thibaut VARENE wrote:
> On Fri, 10 Jan 2003 23:13:13 +0100
> "Thibaut VARENE" <varenet@esiee.fr> wrote:
> 
> I hate to reply to myself but I said crap in my previous mail.
> All apologies:
> 
>>FWIW, the default option (used by most people) is data=journal, and is not affected by that bug. We've been using 2.4.20 with ext3 for weeks pretty safely here.
> 
> it was: "the default option is data=ordered" of course, which is safe.
> 
I just to ask you additional help: I do not recover the method to get 
the actual setup of my fs ext3 (i do severall test but a time ago and do 
not remember in which state I let it: well operational but what more??)

Thanks,
	Joel

Re: [parisc-linux] unaligned accesses

[Thibaut VARENE]

On Sun, 12 Jan 2003 15:25:05 +0000
"Joel Soete" <joel.soete@freebel.net> wrote:

> Hi Thibaut
> 
> Thibaut VARENE wrote:
> > On Fri, 10 Jan 2003 23:13:13 +0100
> > "Thibaut VARENE" <varenet@esiee.fr> wrote:
> > 
> > I hate to reply to myself but I said crap in my previous mail.
> > All apologies:
> > 
> >>FWIW, the default option (used by most people) is data=journal, and is not affected by that bug. We've been using 2.4.20 with ext3 for weeks pretty safely here.
> > 
> > it was: "the default option is data=ordered" of course, which is safe.
> > 
> I just to ask you additional help: I do not recover the method to get 
> the actual setup of my fs ext3 (i do severall test but a time ago and do
> not remember in which state I let it: well operational but what more??)
To get the actual configuration of a ext[23] fs, you can use 'tune2fs -l <device>'. To get the current state of data mode of an ext3 fs, look at dmesg. I don't know another way to get that info.
The data mode is decided at mount time, with 'mount -o data=xxx <device>'.

FWIW, I remember having found all that info in man tune2fs, man mount and man mke2fs.

HTH,


Thibaut VARENE
The PA/Linux ESIEE Team
http://pateam.esiee.fr/