from:"Gerold Jury"

Re: extra bytes written to SATA DVD drive on kernel 2.6.23 till 2.6.24.2

2008-02-26 Thread Gerold Jury

It does happen with 2.6.22 too.

Do you see any known pattern in these extra bytes ?

Best Regards
Gerold


  2a 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |[EMAIL PROTECTED]|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0002  2a 00 00 00 00 40 00 00  40 00 00 00 00 40 00 00  |[EMAIL 
PROTECTED]@[EMAIL PROTECTED]|
00020010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0004  2a 00 00 00 00 80 00 00  40 00 00 00 00 80 00 00  |[EMAIL PROTECTED]|
00040010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0006  2a 00 00 00 00 c0 00 00  02 00 00 00 00 c0 00 00  |*...|
00060010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
00061010  00 00 00 00 00 00 00 00  2a 00 00 00 00 c2 00 00  |*...|
00061020  40 00 00 00 00 c2 00 00  00 00 00 00 00 00 00 00  |@...|
00061030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
00081010  00 00 00 00 00 00 00 00  2a 00 00 00 01 02 00 00  |*...|
00081020  40 00 00 00 01 02 00 00  00 00 00 00 00 00 00 00  |@...|
00081030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
000a1010  00 00 00 00 00 00 00 00  2a 00 00 00 01 42 00 00  |*B..|
000a1020  40 00 00 00 01 42 00 00  00 00 00 00 00 00 00 00  |@B..|
000a1030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
000c1010  00 00 00 00 00 00 00 00  2a 00 00 00 01 82 00 00  |*...|
000c1020  40 00 00 00 01 82 00 00  00 00 00 00 00 00 00 00  |@...|
000c1030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*



On Tuesday 26 February 2008 00:32:49 Andrew Morton wrote:
>On Mon, 25 Feb 2008 20:05:22 +0100 Gerold Jury <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> I have two DVD drives, one connected to the SATA port (LG) the other to
>> the IDE port (PHILIPS) of a via chipset.
>> They are driven by VIA SATA support (SATA_VIA) and VIA PATA support
>> (PATA_VIA).
>>
>> When I write an iso image to the drive on the SATA port /dev/sr0 it has
>> some extra bytes on disk which make the disk unreadable.
>> Writing to the IDE drive /dev/sr1 works well.
>>
>> A simple test with a DVD RAM and dd instead of growisofs
>>
>> dd if=/dev/zero of=/dev/srX bs=1024k count=10
>>
>> and a readback afterwards
>>
>> dd if=/dev/srX of=imageX.bin bs=1024k count=10
>>
>> gives me an all zero file from the IDE drive but a file
>> full of probably scsi commands for the SATA drive and looks like
>>
>>   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
>> || *
>> 0002  2a 00 00 00 00 40 00 00  40 00 00 00 00 40 00 00 
>> |[EMAIL PROTECTED]@[EMAIL PROTECTED]| 00020010  00 00 00 00 00 00 00 00  00 
>> 00 00 00 00 00 00
>> 00  || *
>> 0004  2a 00 00 00 00 80 00 00  40 00 00 00 00 80 00 00 
>> |[EMAIL PROTECTED]| 00040010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
>> 00  || *
>> 0006  2a 00 00 00 00 c0 00 00  02 00 00 00 00 c0 00 00 
>> |*...| 00060010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
>> 00  || *
>> 00061010  00 00 00 00 00 00 00 00  2a 00 00 00 00 c2 00 00 
>> |*...| 00061020  40 00 00 00 00 c2 00 00  00 00 00 00 00 00 00
>> 00  |@...| 00061030  00 00 00 00 00 00 00 00  00 00 00 00 00
>> 00 00 00  || *
>> 00081010  00 00 00 00 00 00 00 00  2a 00 00 00 01 02 00 00 
>> |*...| 00081020  40 00 00 00 01 02 00 00  00 00 00 00 00 00 00
>> 00  |@...| 00081030  00 00 00 00 00 00 00 00  00 00 00 00 00
>> 00 00 00  || *
>> 000a1010  00 00 00 00 00 00 00 00  2a 00 00 00 01 42 00 00 
>> |*B..| 000a1020  40 00 00 00 01 42 00 00  00 00 00 00 00 00 00
>> 00  |@B..| 000a1030  00 00 00 00 00 00 00 00  00 00 00 00 00
>> 00 00 00  || *
>> 000c1010  00 00 00 00 00 00 00 00  2a 00 00 00 01 82 00 00 
>> |*...| 000c1020  40 00 00 00 01 82 00 00  00 00 00 00 00 00 00
>> 00  |@...| 000c1030  00 00 00 00 00 00 00 00  00 00 00 00 00
>> 00 00 00  ||
>>
>> I really need some hints to make the SATA drive usable, please.
>
>(added linux-ide)
>
>Did any earlier kernel work OK?  2.6.22?
>
>Thanks.
>
>> uname -a
>> Linux blaubaer 2.6.24.2 #4 Sun Feb 24 21:50:21 CET 2008 x86_64 AMD
>> Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux
>>
>> lspvi -v
>>
>> 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID
>>

Re: extra bytes written to SATA DVD drive on kernel 2.6.23 till 2.6.24.2

2008-02-26 Thread Gerold Jury

It does happen with 2.6.22 too.

Do you see any known pattern in these extra bytes ?

Best Regards
Gerold


  2a 00 00 00 00 00 00 00  40 00 00 00 00 00 00 00  |[EMAIL PROTECTED]|
0010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0002  2a 00 00 00 00 40 00 00  40 00 00 00 00 40 00 00  |[EMAIL 
PROTECTED]@[EMAIL PROTECTED]|
00020010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0004  2a 00 00 00 00 80 00 00  40 00 00 00 00 80 00 00  |[EMAIL PROTECTED]|
00040010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0006  2a 00 00 00 00 c0 00 00  02 00 00 00 00 c0 00 00  |*...|
00060010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
00061010  00 00 00 00 00 00 00 00  2a 00 00 00 00 c2 00 00  |*...|
00061020  40 00 00 00 00 c2 00 00  00 00 00 00 00 00 00 00  |@...|
00061030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
00081010  00 00 00 00 00 00 00 00  2a 00 00 00 01 02 00 00  |*...|
00081020  40 00 00 00 01 02 00 00  00 00 00 00 00 00 00 00  |@...|
00081030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
000a1010  00 00 00 00 00 00 00 00  2a 00 00 00 01 42 00 00  |*B..|
000a1020  40 00 00 00 01 42 00 00  00 00 00 00 00 00 00 00  |@B..|
000a1030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
000c1010  00 00 00 00 00 00 00 00  2a 00 00 00 01 82 00 00  |*...|
000c1020  40 00 00 00 01 82 00 00  00 00 00 00 00 00 00 00  |@...|
000c1030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*



On Tuesday 26 February 2008 00:32:49 Andrew Morton wrote:
On Mon, 25 Feb 2008 20:05:22 +0100 Gerold Jury [EMAIL PROTECTED] wrote:
 Hello,

 I have two DVD drives, one connected to the SATA port (LG) the other to
 the IDE port (PHILIPS) of a via chipset.
 They are driven by VIA SATA support (SATA_VIA) and VIA PATA support
 (PATA_VIA).

 When I write an iso image to the drive on the SATA port /dev/sr0 it has
 some extra bytes on disk which make the disk unreadable.
 Writing to the IDE drive /dev/sr1 works well.

 A simple test with a DVD RAM and dd instead of growisofs

 dd if=/dev/zero of=/dev/srX bs=1024k count=10

 and a readback afterwards

 dd if=/dev/srX of=imageX.bin bs=1024k count=10

 gives me an all zero file from the IDE drive but a file
 full of probably scsi commands for the SATA drive and looks like

   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 
 || *
 0002  2a 00 00 00 00 40 00 00  40 00 00 00 00 40 00 00 
 |[EMAIL PROTECTED]@[EMAIL PROTECTED]| 00020010  00 00 00 00 00 00 00 00  00 
 00 00 00 00 00 00
 00  || *
 0004  2a 00 00 00 00 80 00 00  40 00 00 00 00 80 00 00 
 |[EMAIL PROTECTED]| 00040010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
 00  || *
 0006  2a 00 00 00 00 c0 00 00  02 00 00 00 00 c0 00 00 
 |*...| 00060010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
 00  || *
 00061010  00 00 00 00 00 00 00 00  2a 00 00 00 00 c2 00 00 
 |*...| 00061020  40 00 00 00 00 c2 00 00  00 00 00 00 00 00 00
 00  |@...| 00061030  00 00 00 00 00 00 00 00  00 00 00 00 00
 00 00 00  || *
 00081010  00 00 00 00 00 00 00 00  2a 00 00 00 01 02 00 00 
 |*...| 00081020  40 00 00 00 01 02 00 00  00 00 00 00 00 00 00
 00  |@...| 00081030  00 00 00 00 00 00 00 00  00 00 00 00 00
 00 00 00  || *
 000a1010  00 00 00 00 00 00 00 00  2a 00 00 00 01 42 00 00 
 |*B..| 000a1020  40 00 00 00 01 42 00 00  00 00 00 00 00 00 00
 00  |@B..| 000a1030  00 00 00 00 00 00 00 00  00 00 00 00 00
 00 00 00  || *
 000c1010  00 00 00 00 00 00 00 00  2a 00 00 00 01 82 00 00 
 |*...| 000c1020  40 00 00 00 01 82 00 00  00 00 00 00 00 00 00
 00  |@...| 000c1030  00 00 00 00 00 00 00 00  00 00 00 00 00
 00 00 00  ||

 I really need some hints to make the SATA drive usable, please.

(added linux-ide)

Did any earlier kernel work OK?  2.6.22?

Thanks.

 uname -a
 Linux blaubaer 2.6.24.2 #4 Sun Feb 24 21:50:21 CET 2008 x86_64 AMD
 Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux

 lspvi -v

 00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID
 Controller (rev 80)
 Subsystem: ASUSTeK Computer Inc. A7V600/K8V Deluxe/K8V-X/A8V
 Deluxe motherboard
 Flags: bus master, medium devsel, latency 64, IRQ 20
 I/O ports at e800 [size=8]
 I/O ports at e400 [size=4]
 I/O ports at e000 [size=8]
 I/O ports at d800 [size=4]
 I/O ports at d400 [size=16]
 I/O ports at d000 [size=256]
 Capabilities: [c0] Power Management version 2
 Kernel driver in use: sata_via

 00:0f.1 IDE interface: VIA

extra bytes written to SATA DVD drive on kernel 2.6.23 till 2.6.24.2

2008-02-25 Thread Gerold Jury

Hello,

I have two DVD drives, one connected to the SATA port (LG) the other to the 
IDE port (PHILIPS) of a via chipset.
They are driven by VIA SATA support (SATA_VIA) and VIA PATA support 
(PATA_VIA).

When I write an iso image to the drive on the SATA port /dev/sr0 it has some 
extra bytes on disk which make the disk unreadable.
Writing to the IDE drive /dev/sr1 works well.

A simple test with a DVD RAM and dd instead of growisofs

dd if=/dev/zero of=/dev/srX bs=1024k count=10

and a readback afterwards

dd if=/dev/srX of=imageX.bin bs=1024k count=10

gives me an all zero file from the IDE drive but a file
full of probably scsi commands for the SATA drive and looks like

  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0002  2a 00 00 00 00 40 00 00  40 00 00 00 00 40 00 00  |[EMAIL 
PROTECTED]@[EMAIL PROTECTED]|
00020010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0004  2a 00 00 00 00 80 00 00  40 00 00 00 00 80 00 00  |[EMAIL PROTECTED]|
00040010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0006  2a 00 00 00 00 c0 00 00  02 00 00 00 00 c0 00 00  |*...|
00060010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
00061010  00 00 00 00 00 00 00 00  2a 00 00 00 00 c2 00 00  |*...|
00061020  40 00 00 00 00 c2 00 00  00 00 00 00 00 00 00 00  |@...|
00061030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
00081010  00 00 00 00 00 00 00 00  2a 00 00 00 01 02 00 00  |*...|
00081020  40 00 00 00 01 02 00 00  00 00 00 00 00 00 00 00  |@...|
00081030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
000a1010  00 00 00 00 00 00 00 00  2a 00 00 00 01 42 00 00  |*B..|
000a1020  40 00 00 00 01 42 00 00  00 00 00 00 00 00 00 00  |@B..|
000a1030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
000c1010  00 00 00 00 00 00 00 00  2a 00 00 00 01 82 00 00  |*...|
000c1020  40 00 00 00 01 82 00 00  00 00 00 00 00 00 00 00  |@...|
000c1030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||

I really need some hints to make the SATA drive usable, please.

best Regards
Gerold


uname -a
Linux blaubaer 2.6.24.2 #4 Sun Feb 24 21:50:21 CET 2008 x86_64 AMD Athlon(tm) 
64 Processor 3400+ AuthenticAMD GNU/Linux

lspvi -v

00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID 
Controller (rev 80)
Subsystem: ASUSTeK Computer Inc. A7V600/K8V Deluxe/K8V-X/A8V Deluxe 
motherboard
Flags: bus master, medium devsel, latency 64, IRQ 20
I/O ports at e800 [size=8]
I/O ports at e400 [size=4]
I/O ports at e000 [size=8]
I/O ports at d800 [size=4]
I/O ports at d400 [size=16]
I/O ports at d000 [size=256]
Capabilities: [c0] Power Management version 2
Kernel driver in use: sata_via

00:0f.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a 
[Master SecP PriP])
Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X/A8V Deluxe motherboard
Flags: bus master, medium devsel, latency 32, IRQ 20
[virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1]
[virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 0370 (type 3, non-prefetchable) [size=1]
I/O ports at fc00 [size=16]
Capabilities: [c0] Power Management version 2
Kernel driver in use: pata_via

cat /var/log/messages

Feb 25 18:20:57 blaubaer sata_via :00:0f.0: version 2.3
Feb 25 18:20:57 blaubaer ACPI: PCI Interrupt :00:0f.0[B] -> GSI 20 (level, 
low) -> IRQ 20
Feb 25 18:20:57 blaubaer sata_via :00:0f.0: routed to hard irq line 10
Feb 25 18:20:57 blaubaer scsi3 : sata_via
Feb 25 18:20:57 blaubaer scsi4 : sata_via
Feb 25 18:20:57 blaubaer ata4: SATA max UDMA/133 cmd 0xe800 ctl 0xe400 bmdma 
0xd400 irq 20
Feb 25 18:20:57 blaubaer ata5: SATA max UDMA/133 cmd 0xe000 ctl 0xd800 bmdma 
0xd408 irq 20
Feb 25 18:20:57 blaubaer ata4: SATA link down 1.5 Gbps (SStatus 0 SControl 
300)
Feb 25 18:20:57 blaubaer ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 
300)
Feb 25 18:20:57 blaubaer ata5.00: ATAPI: HL-DT-ST DVDRAM GH20NS10, EL00, max 
UDMA/100
Feb 25 18:20:57 blaubaer ata5.00: configured for UDMA/100
Feb 25 18:20:57 blaubaer scsi 4:0:0:0: CD-ROMHL-DT-ST DVDRAM 
GH20NS10  EL00 PQ: 0 ANSI: 5
Feb 25 18:20:57 blaubaer sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw 
xa/form2 cdda tray
Feb 25 18:20:57 blaubaer Uniform CD-ROM driver Revision: 3.20
Feb 25 18:20:57 blaubaer sr 4:0:0:0: Attached scsi CD-ROM sr0
Feb 25 18:20:57 blaubaer sr 4:0:0:0: Attached scsi generic sg2 type 5
Feb 25 18:20:57 blaubaer pata_via :00:0f.1: version 0.3.3
Feb 25

extra bytes written to SATA DVD drive on kernel 2.6.23 till 2.6.24.2

2008-02-25 Thread Gerold Jury

Hello,

I have two DVD drives, one connected to the SATA port (LG) the other to the 
IDE port (PHILIPS) of a via chipset.
They are driven by VIA SATA support (SATA_VIA) and VIA PATA support 
(PATA_VIA).

When I write an iso image to the drive on the SATA port /dev/sr0 it has some 
extra bytes on disk which make the disk unreadable.
Writing to the IDE drive /dev/sr1 works well.

A simple test with a DVD RAM and dd instead of growisofs

dd if=/dev/zero of=/dev/srX bs=1024k count=10

and a readback afterwards

dd if=/dev/srX of=imageX.bin bs=1024k count=10

gives me an all zero file from the IDE drive but a file
full of probably scsi commands for the SATA drive and looks like

  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0002  2a 00 00 00 00 40 00 00  40 00 00 00 00 40 00 00  |[EMAIL 
PROTECTED]@[EMAIL PROTECTED]|
00020010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0004  2a 00 00 00 00 80 00 00  40 00 00 00 00 80 00 00  |[EMAIL PROTECTED]|
00040010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
0006  2a 00 00 00 00 c0 00 00  02 00 00 00 00 c0 00 00  |*...|
00060010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
00061010  00 00 00 00 00 00 00 00  2a 00 00 00 00 c2 00 00  |*...|
00061020  40 00 00 00 00 c2 00 00  00 00 00 00 00 00 00 00  |@...|
00061030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
00081010  00 00 00 00 00 00 00 00  2a 00 00 00 01 02 00 00  |*...|
00081020  40 00 00 00 01 02 00 00  00 00 00 00 00 00 00 00  |@...|
00081030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
000a1010  00 00 00 00 00 00 00 00  2a 00 00 00 01 42 00 00  |*B..|
000a1020  40 00 00 00 01 42 00 00  00 00 00 00 00 00 00 00  |@B..|
000a1030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
*
000c1010  00 00 00 00 00 00 00 00  2a 00 00 00 01 82 00 00  |*...|
000c1020  40 00 00 00 01 82 00 00  00 00 00 00 00 00 00 00  |@...|
000c1030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||

I really need some hints to make the SATA drive usable, please.

best Regards
Gerold


uname -a
Linux blaubaer 2.6.24.2 #4 Sun Feb 24 21:50:21 CET 2008 x86_64 AMD Athlon(tm) 
64 Processor 3400+ AuthenticAMD GNU/Linux

lspvi -v

00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID 
Controller (rev 80)
Subsystem: ASUSTeK Computer Inc. A7V600/K8V Deluxe/K8V-X/A8V Deluxe 
motherboard
Flags: bus master, medium devsel, latency 64, IRQ 20
I/O ports at e800 [size=8]
I/O ports at e400 [size=4]
I/O ports at e000 [size=8]
I/O ports at d800 [size=4]
I/O ports at d400 [size=16]
I/O ports at d000 [size=256]
Capabilities: [c0] Power Management version 2
Kernel driver in use: sata_via

00:0f.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a 
[Master SecP PriP])
Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X/A8V Deluxe motherboard
Flags: bus master, medium devsel, latency 32, IRQ 20
[virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 03f0 (type 3, non-prefetchable) [size=1]
[virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 0370 (type 3, non-prefetchable) [size=1]
I/O ports at fc00 [size=16]
Capabilities: [c0] Power Management version 2
Kernel driver in use: pata_via

cat /var/log/messages

Feb 25 18:20:57 blaubaer sata_via :00:0f.0: version 2.3
Feb 25 18:20:57 blaubaer ACPI: PCI Interrupt :00:0f.0[B] - GSI 20 (level, 
low) - IRQ 20
Feb 25 18:20:57 blaubaer sata_via :00:0f.0: routed to hard irq line 10
Feb 25 18:20:57 blaubaer scsi3 : sata_via
Feb 25 18:20:57 blaubaer scsi4 : sata_via
Feb 25 18:20:57 blaubaer ata4: SATA max UDMA/133 cmd 0xe800 ctl 0xe400 bmdma 
0xd400 irq 20
Feb 25 18:20:57 blaubaer ata5: SATA max UDMA/133 cmd 0xe000 ctl 0xd800 bmdma 
0xd408 irq 20
Feb 25 18:20:57 blaubaer ata4: SATA link down 1.5 Gbps (SStatus 0 SControl 
300)
Feb 25 18:20:57 blaubaer ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 
300)
Feb 25 18:20:57 blaubaer ata5.00: ATAPI: HL-DT-ST DVDRAM GH20NS10, EL00, max 
UDMA/100
Feb 25 18:20:57 blaubaer ata5.00: configured for UDMA/100
Feb 25 18:20:57 blaubaer scsi 4:0:0:0: CD-ROMHL-DT-ST DVDRAM 
GH20NS10  EL00 PQ: 0 ANSI: 5
Feb 25 18:20:57 blaubaer sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw 
xa/form2 cdda tray
Feb 25 18:20:57 blaubaer Uniform CD-ROM driver Revision: 3.20
Feb 25 18:20:57 blaubaer sr 4:0:0:0: Attached scsi CD-ROM sr0
Feb 25 18:20:57 blaubaer sr 4:0:0:0: Attached scsi generic sg2 type 5
Feb 25 18:20:57 blaubaer pata_via :00:0f.1: version 0.3.3
Feb 25

Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel

2005-03-29 Thread Gerold Jury


>> On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote:
>> > /*
>> >  * This looks horribly ugly, but the compiler can optimize it totally,
>> >  * as the count is constant.
>> >  */
>> > static inline void * __constant_memcpy(void * to, const void * from,
>> > size_t n) {
>> > if (n <= 128)
>> > return __builtin_memcpy(to, from, n);
>>
>> The problem is that in GCC < 4.0 there is no constant propagation
>> pass before expanding builtin functions, so the __builtin_memcpy
>> call above sees a variable rather than a constant.
>
>or change "size_t n" to "const size_t n" will also fix the issue.
>As we do some (well very little and with inlining and const values)
>const progation before 4.0.0 on the trees before expanding the builtin.
>
>-- Pinski
>-
I used the following "const size_t n" change on x86_64
and it reduced the memcpy count from 1088 to 609 with my setup and gcc 3.4.3.
(kernel 2.6.12-rc1, running now)

--- include/asm-x86_64/string.h.~1~ 2005-03-02 08:38:33.0 +0100
+++ include/asm-x86_64/string.h 2005-03-30 03:24:35.0 +0200
@@ -28,9 +28,9 @@
function. */

 #define __HAVE_ARCH_MEMCPY 1
-extern void *__memcpy(void *to, const void *from, size_t len);
+extern void *__memcpy(void *to, const void *from, const size_t len);
 #define memcpy(dst,src,len) \
-   ({ size_t __len = (len);\
+   ({ const size_t __len = (len);  \
   void *__ret; \
   if (__builtin_constant_p(len) && __len >= 64)\
 __ret = __memcpy((dst),(src),__len);   \
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel

2005-03-29 Thread Gerold Jury


 On Tue, Mar 29, 2005 at 05:37:06PM +0300, Denis Vlasenko wrote:
  /*
   * This looks horribly ugly, but the compiler can optimize it totally,
   * as the count is constant.
   */
  static inline void * __constant_memcpy(void * to, const void * from,
  size_t n) {
  if (n = 128)
  return __builtin_memcpy(to, from, n);

 The problem is that in GCC  4.0 there is no constant propagation
 pass before expanding builtin functions, so the __builtin_memcpy
 call above sees a variable rather than a constant.

or change size_t n to const size_t n will also fix the issue.
As we do some (well very little and with inlining and const values)
const progation before 4.0.0 on the trees before expanding the builtin.

-- Pinski
-
I used the following const size_t n change on x86_64
and it reduced the memcpy count from 1088 to 609 with my setup and gcc 3.4.3.
(kernel 2.6.12-rc1, running now)

--- include/asm-x86_64/string.h.~1~ 2005-03-02 08:38:33.0 +0100
+++ include/asm-x86_64/string.h 2005-03-30 03:24:35.0 +0200
@@ -28,9 +28,9 @@
function. */

 #define __HAVE_ARCH_MEMCPY 1
-extern void *__memcpy(void *to, const void *from, size_t len);
+extern void *__memcpy(void *to, const void *from, const size_t len);
 #define memcpy(dst,src,len) \
-   ({ size_t __len = (len);\
+   ({ const size_t __len = (len);  \
   void *__ret; \
   if (__builtin_constant_p(len)  __len = 64)\
 __ret = __memcpy((dst),(src),__len);   \
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BK] upgrade will be needed

2005-02-14 Thread Gerold Jury

>if they really need the more powerful features.  Or we could donate
>some on a case by case basis.
>
>If the hackers who are using BK can reach agreement that it would be
>better if the BK they had didn't move forward unless they got commercial
>seats then we could start moving towards a license on the free product
>that was less restrictive.  What that would mean is that the BK you have

I want to pay the fee for Linus and Alan.

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

Re: [BK] upgrade will be needed

2005-02-14 Thread Gerold Jury

Hi Larry
Hi Everyone

To me it looks like lot's of users (and myself) simply want to track the 
kernel development very closely.
Some are looking out for a specific bug to be fixed.
Some want to see the direction of some developments going on.
The first place a change arrives at is the bitkeeper repository.
There are others who already have an idea to contribute.
They will already know what the pros and cons of bitkeeper are, or soon find 
out.
Do you think it is possible to make a split licence that will distinguish 
between active changes and passive watching/tracking ?
The web interface does not provide the functionality for a quick overview 
about the latest changes.
It may be sufficient for a part of the people in this discussion.

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

Re: [BK] upgrade will be needed

2005-02-14 Thread Gerold Jury

Hi Larry
Hi Everyone

To me it looks like lot's of users (and myself) simply want to track the 
kernel development very closely.
Some are looking out for a specific bug to be fixed.
Some want to see the direction of some developments going on.
The first place a change arrives at is the bitkeeper repository.
There are others who already have an idea to contribute.
They will already know what the pros and cons of bitkeeper are, or soon find 
out.
Do you think it is possible to make a split licence that will distinguish 
between active changes and passive watching/tracking ?
The web interface does not provide the functionality for a quick overview 
about the latest changes.
It may be sufficient for a part of the people in this discussion.

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

Re: [BK] upgrade will be needed

2005-02-14 Thread Gerold Jury

if they really need the more powerful features.  Or we could donate
some on a case by case basis.

If the hackers who are using BK can reach agreement that it would be
better if the BK they had didn't move forward unless they got commercial
seats then we could start moving towards a license on the free product
that was less restrictive.  What that would mean is that the BK you have

I want to pay the fee for Linus and Alan.

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

Re: [PATCH][RFC] Signal-per-fd for RT signals

2001-05-19 Thread Gerold Jury


Vitaly Luban wrote:
> 
> Hi,
> 

> the form of POLL_... This will bring functionality of RT
> signals event notification on the level with 'select' or
> 'poll' one, while more efficient and scalable. If there's
> an interest in such a feature, I'd be eager to publish a
> patch.
> 
> Thanks,
> Vitaly.
> 
I have been waiting for this patch since 2.4.0.

The SIGIO signal is a nightmare when it arrives :
  The machine is already under high load and has to stop
  using the most efficient way to handle it.

The filter changes would be the cream on top of this patch.
Do not hurry, but please not for long.

best Regards

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

Re: [PATCH][RFC] Signal-per-fd for RT signals

2001-05-19 Thread Gerold Jury


Vitaly Luban wrote:
 
 Hi,
 
snip/
 the form of POLL_... This will bring functionality of RT
 signals event notification on the level with 'select' or
 'poll' one, while more efficient and scalable. If there's
 an interest in such a feature, I'd be eager to publish a
 patch.
 
 Thanks,
 Vitaly.
 
I have been waiting for this patch since 2.4.0.

The SIGIO signal is a nightmare when it arrives :
  The machine is already under high load and has to stop
  using the most efficient way to handle it.

The filter changes would be the cream on top of this patch.
Do not hurry, but please not for long.

best Regards

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

Re: Happy new year^H^H^H^Hkernel..

2001-01-02 Thread Gerold Jury


It works for me.
With and without the divert module loaded.

Thanks a lot

Gerold

Kai Germaschewski wrote:

> I think I found it. Could everybody who was getting the crash on ISDN line
> hangup try if the following patch fixes the problem?
> 

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

Re: Happy new year^H^H^H^Hkernel..

2001-01-02 Thread Gerold Jury

Sorry for that stupid mistake.
The patches to the isdn part do not make a difference to the kernel hang
that i experienced lately.
When i reversed the patch for the mentioned files i checked the kernel 
configuration and noticed that the "diversion services for isdn" where 
on, a feature that i cannot use at the moment with my carrier.
I switched them off before i compiled the new kernel.
This is what makes the difference.
Kernel 2.4.0-test13-pre4 was the previous one that I used (with 
diversion services on, i am a fan of make oldconfig) and that did not 
show the problem (as all of the previous kernels, test9, test10, test12).

I have reversed the patches part by part, the only thing that makes a 
difference is the diversion services.
The reason for this remains unknown for me.

I use a fritz pnp/isa card, driver compiled as a module.
No SMP, isdn in kernel.
Close to nothing running during the hangup.

The problem is reproducable and i would be glad to help testing any 
suggestions.

Gerold

Gerold Jury wrote:

> The ISDN changes for the HISAX drivers
> that came in since test12 have introduced a bug that causes a 
> AIEE-something and a complete kernel hang when i hangup the isdn line.
> I have reversed the patch for all occurences of INIT_LIST_HEAD in the 
> isdn patch part and it works for me now.
> 
> The relevant part is attached. Please back it out for 2.4.0.
> 
> Happy new year
> 
> Gerold Jury
> 

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

Re: Happy new year^H^H^H^Hkernel..

2001-01-02 Thread Gerold Jury


Sorry for that stupid mistake.
The patches to the isdn part do not make a difference to the kernel hang
that i experienced lately.
When i reversed the patch for the mentioned files i checked the kernel 
configuration and noticed that the "diversion services for isdn" where 
on, a feature that i cannot use at the moment with my carrier.
I switched them off before i compiled the new kernel.
This is what makes the difference.
Kernel 2.4.0-test13-pre4 was the previous one that I used (with 
diversion services on, i am a fan of make oldconfig) and that did not 
show the problem (as all of the previous kernels, test9, test10, test12).

I have reversed the patches part by part, the only thing that makes a 
difference is the diversion services.
The reason for this remains unknown for me.

I use a fritz pnp/isa card, driver compiled as a module.
No SMP, isdn in kernel.
Close to nothing running during the hangup.

The problem is reproducable and i would be glad to help testing any 
suggestions.

Gerold


Gerold Jury wrote:

 The ISDN changes for the HISAX drivers
 that came in since test12 have introduced a bug that causes a 
 AIEE-something and a complete kernel hang when i hangup the isdn line.
 I have reversed the patch for all occurences of INIT_LIST_HEAD in the 
 isdn patch part and it works for me now.
 
 The relevant part is attached. Please back it out for 2.4.0.
 
 Happy new year
 
 Gerold Jury
 

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

Re: Happy new year^H^H^H^Hkernel..

2001-01-02 Thread Gerold Jury


It works for me.
With and without the divert module loaded.

Thanks a lot

Gerold

Kai Germaschewski wrote:

 I think I found it. Could everybody who was getting the crash on ISDN line
 hangup try if the following patch fixes the problem?
 

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

Re: Happy new year^H^H^H^Hkernel..

2001-01-01 Thread Gerold Jury


The ISDN changes for the HISAX drivers
that came in since test12 have introduced a bug that causes a 
AIEE-something and a complete kernel hang when i hangup the isdn line.
I have reversed the patch for all occurences of INIT_LIST_HEAD in the 
isdn patch part and it works for me now.

The relevant part is attached. Please back it out for 2.4.0.

Happy new year

Gerold Jury


diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/hisax/config.c 
linux/drivers/isdn/hisax/config.c
--- v2.4.0-test12/linux/drivers/isdn/hisax/config.c Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/hisax/config.c   Fri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: config.c,v 2.57.6.3 2000/11/29 17:48:59 kai Exp $
+/* $Id: config.c,v 2.57.6.6 2000/12/10 23:39:19 kai Exp $
  *
  * Author   Karsten Keil ([EMAIL PROTECTED])
  *  based on the teles driver from Jan den Ouden
@@ -1180,7 +1180,6 @@
cs->tx_skb = NULL;
cs->tx_cnt = 0;
cs->event = 0;
-   INIT_LIST_HEAD(>tqueue.list);
cs->tqueue.sync = 0;
cs->tqueue.data = cs;
 
@@ -1756,6 +1755,7 @@
{PCI_VENDOR_ID_CCD,  PCI_DEVICE_ID_CCD_B00B, PCI_ANY_ID, 
PCI_ANY_ID},
{PCI_VENDOR_ID_CCD,  PCI_DEVICE_ID_CCD_B00C, PCI_ANY_ID, 
PCI_ANY_ID},
{PCI_VENDOR_ID_CCD,  PCI_DEVICE_ID_CCD_B100, PCI_ANY_ID, 
PCI_ANY_ID},
+   {PCI_VENDOR_ID_ABOCOM,   PCI_DEVICE_ID_ABOCOM_2BD1,  PCI_ANY_ID, 
+PCI_ANY_ID},
{PCI_VENDOR_ID_ASUSTEK,  PCI_DEVICE_ID_ASUSTEK_0675, PCI_ANY_ID, 
PCI_ANY_ID},
{PCI_VENDOR_ID_BERKOM,   PCI_DEVICE_ID_BERKOM_T_CONCEPT, PCI_ANY_ID, 
PCI_ANY_ID},
{PCI_VENDOR_ID_BERKOM,   PCI_DEVICE_ID_BERKOM_A1T,   PCI_ANY_ID, 
PCI_ANY_ID},
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/hisax/isdnl1.c 
linux/drivers/isdn/hisax/isdnl1.c
--- v2.4.0-test12/linux/drivers/isdn/hisax/isdnl1.c Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/hisax/isdnl1.c   Fri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: isdnl1.c,v 2.41 2000/11/24 17:05:37 kai Exp $
+/* $Id: isdnl1.c,v 2.41.6.1 2000/12/10 22:01:04 kai Exp $
  *
  * isdnl1.c common low level stuff for Siemens Chipsetbased isdn cards
  *  based on the teles driver from Jan den Ouden
@@ -15,7 +15,7 @@
  *
  */
 
-const char *l1_revision = "$Revision: 2.41 $";
+const char *l1_revision = "$Revision: 2.41.6.1 $";
 
 #define __NO_VERSION__
 #include 
@@ -343,7 +343,6 @@
 
bcs->cs = cs;
bcs->channel = bc;
-   INIT_LIST_HEAD(>tqueue.list);
bcs->tqueue.sync = 0;
bcs->tqueue.routine = (void *) (void *) BChannel_bh;
bcs->tqueue.data = bcs;
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/hysdn/boardergo.c 
linux/drivers/isdn/hysdn/boardergo.c
--- v2.4.0-test12/linux/drivers/isdn/hysdn/boardergo.c  Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/hysdn/boardergo.cFri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: boardergo.c,v 1.5 2000/11/22 17:13:13 kai Exp $
+/* $Id: boardergo.c,v 1.5.6.1 2000/12/10 22:01:04 kai Exp $
 
  * Linux driver for HYSDN cards, specific routines for ergo type boards.
  *
@@ -458,7 +458,6 @@
card->writebootseq = ergo_writebootseq;
card->waitpofready = ergo_waitpofready;
card->set_errlog_state = ergo_set_errlog_state;
-   INIT_LIST_HEAD(>irq_queue.list);
card->irq_queue.sync = 0;
card->irq_queue.data = card;/* init task queue for interrupt */
card->irq_queue.routine = (void *) (void *) ergo_irq_bh;
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/isdn_net.c 
linux/drivers/isdn/isdn_net.c
--- v2.4.0-test12/linux/drivers/isdn/isdn_net.c Sun Nov 19 18:44:08 2000
+++ linux/drivers/isdn/isdn_net.c   Fri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: isdn_net.c,v 1.140 2000/11/01 17:54:01 detabc Exp $
+/* $Id: isdn_net.c,v 1.140.6.1 2000/12/10 22:01:04 kai Exp $
 
  * Linux ISDN subsystem, network interfaces and related functions (linklevel).
  *
@@ -181,7 +181,7 @@
 int isdn_net_force_dial_lp(isdn_net_local *);
 static int isdn_net_start_xmit(struct sk_buff *, struct net_device *);
 
-char *isdn_net_revision = "$Revision: 1.140 $";
+char *isdn_net_revision = "$Revision: 1.140.6.1 $";
 
  /*
   * Code for raw-networking over ISDN
@@ -2371,7 +2371,7 @@
netdev->local->netdev = netdev;
netdev->local->next = netdev->local;
 
-   memset(>local->tqueue, 0, sizeof(struct tq_struct));
+   netdev->local->tqueue.sync = 0;
netdev->local->tqueue.routine = isdn_net_softint;
netdev->local->tqueue.data = netdev->local;
spin_lock_init(>local->xmit_lock);
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/pcbit/drv.c 
linux/drivers/isdn/pcbit/drv.c
--- v2.4.0-test12/linux/drivers/isdn/pcbit/drv.cMon Dec 11 17:59

Re: Happy new year^H^H^H^Hkernel..

2001-01-01 Thread Gerold Jury


The ISDN changes for the HISAX drivers
that came in since test12 have introduced a bug that causes a 
AIEE-something and a complete kernel hang when i hangup the isdn line.
I have reversed the patch for all occurences of INIT_LIST_HEAD in the 
isdn patch part and it works for me now.

The relevant part is attached. Please back it out for 2.4.0.

Happy new year

Gerold Jury


diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/hisax/config.c 
linux/drivers/isdn/hisax/config.c
--- v2.4.0-test12/linux/drivers/isdn/hisax/config.c Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/hisax/config.c   Fri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: config.c,v 2.57.6.3 2000/11/29 17:48:59 kai Exp $
+/* $Id: config.c,v 2.57.6.6 2000/12/10 23:39:19 kai Exp $
  *
  * Author   Karsten Keil ([EMAIL PROTECTED])
  *  based on the teles driver from Jan den Ouden
@@ -1180,7 +1180,6 @@
cs-tx_skb = NULL;
cs-tx_cnt = 0;
cs-event = 0;
-   INIT_LIST_HEAD(cs-tqueue.list);
cs-tqueue.sync = 0;
cs-tqueue.data = cs;
 
@@ -1756,6 +1755,7 @@
{PCI_VENDOR_ID_CCD,  PCI_DEVICE_ID_CCD_B00B, PCI_ANY_ID, 
PCI_ANY_ID},
{PCI_VENDOR_ID_CCD,  PCI_DEVICE_ID_CCD_B00C, PCI_ANY_ID, 
PCI_ANY_ID},
{PCI_VENDOR_ID_CCD,  PCI_DEVICE_ID_CCD_B100, PCI_ANY_ID, 
PCI_ANY_ID},
+   {PCI_VENDOR_ID_ABOCOM,   PCI_DEVICE_ID_ABOCOM_2BD1,  PCI_ANY_ID, 
+PCI_ANY_ID},
{PCI_VENDOR_ID_ASUSTEK,  PCI_DEVICE_ID_ASUSTEK_0675, PCI_ANY_ID, 
PCI_ANY_ID},
{PCI_VENDOR_ID_BERKOM,   PCI_DEVICE_ID_BERKOM_T_CONCEPT, PCI_ANY_ID, 
PCI_ANY_ID},
{PCI_VENDOR_ID_BERKOM,   PCI_DEVICE_ID_BERKOM_A1T,   PCI_ANY_ID, 
PCI_ANY_ID},
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/hisax/isdnl1.c 
linux/drivers/isdn/hisax/isdnl1.c
--- v2.4.0-test12/linux/drivers/isdn/hisax/isdnl1.c Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/hisax/isdnl1.c   Fri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: isdnl1.c,v 2.41 2000/11/24 17:05:37 kai Exp $
+/* $Id: isdnl1.c,v 2.41.6.1 2000/12/10 22:01:04 kai Exp $
  *
  * isdnl1.c common low level stuff for Siemens Chipsetbased isdn cards
  *  based on the teles driver from Jan den Ouden
@@ -15,7 +15,7 @@
  *
  */
 
-const char *l1_revision = "$Revision: 2.41 $";
+const char *l1_revision = "$Revision: 2.41.6.1 $";
 
 #define __NO_VERSION__
 #include linux/init.h
@@ -343,7 +343,6 @@
 
bcs-cs = cs;
bcs-channel = bc;
-   INIT_LIST_HEAD(bcs-tqueue.list);
bcs-tqueue.sync = 0;
bcs-tqueue.routine = (void *) (void *) BChannel_bh;
bcs-tqueue.data = bcs;
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/hysdn/boardergo.c 
linux/drivers/isdn/hysdn/boardergo.c
--- v2.4.0-test12/linux/drivers/isdn/hysdn/boardergo.c  Mon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/hysdn/boardergo.cFri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: boardergo.c,v 1.5 2000/11/22 17:13:13 kai Exp $
+/* $Id: boardergo.c,v 1.5.6.1 2000/12/10 22:01:04 kai Exp $
 
  * Linux driver for HYSDN cards, specific routines for ergo type boards.
  *
@@ -458,7 +458,6 @@
card-writebootseq = ergo_writebootseq;
card-waitpofready = ergo_waitpofready;
card-set_errlog_state = ergo_set_errlog_state;
-   INIT_LIST_HEAD(card-irq_queue.list);
card-irq_queue.sync = 0;
card-irq_queue.data = card;/* init task queue for interrupt */
card-irq_queue.routine = (void *) (void *) ergo_irq_bh;
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/isdn_net.c 
linux/drivers/isdn/isdn_net.c
--- v2.4.0-test12/linux/drivers/isdn/isdn_net.c Sun Nov 19 18:44:08 2000
+++ linux/drivers/isdn/isdn_net.c   Fri Dec 29 14:07:22 2000
@@ -1,4 +1,4 @@
-/* $Id: isdn_net.c,v 1.140 2000/11/01 17:54:01 detabc Exp $
+/* $Id: isdn_net.c,v 1.140.6.1 2000/12/10 22:01:04 kai Exp $
 
  * Linux ISDN subsystem, network interfaces and related functions (linklevel).
  *
@@ -181,7 +181,7 @@
 int isdn_net_force_dial_lp(isdn_net_local *);
 static int isdn_net_start_xmit(struct sk_buff *, struct net_device *);
 
-char *isdn_net_revision = "$Revision: 1.140 $";
+char *isdn_net_revision = "$Revision: 1.140.6.1 $";
 
  /*
   * Code for raw-networking over ISDN
@@ -2371,7 +2371,7 @@
netdev-local-netdev = netdev;
netdev-local-next = netdev-local;
 
-   memset(netdev-local-tqueue, 0, sizeof(struct tq_struct));
+   netdev-local-tqueue.sync = 0;
netdev-local-tqueue.routine = isdn_net_softint;
netdev-local-tqueue.data = netdev-local;
spin_lock_init(netdev-local-xmit_lock);
diff -u --recursive --new-file v2.4.0-test12/linux/drivers/isdn/pcbit/drv.c 
linux/drivers/isdn/pcbit/drv.c
--- v2.4.0-test12/linux/drivers/isdn/pcbit/drv.cMon Dec 11 17:59:44 2000
+++ linux/drivers/isdn/pcbit/drv.c  Fri Dec 29 14:07:22 2000
@@ -134,8 +134,6 @@
me

Re: extra bytes written to SATA DVD drive on kernel 2.6.23 till 2.6.24.2

Re: extra bytes written to SATA DVD drive on kernel 2.6.23 till 2.6.24.2

extra bytes written to SATA DVD drive on kernel 2.6.23 till 2.6.24.2

extra bytes written to SATA DVD drive on kernel 2.6.23 till 2.6.24.2

Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel

Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel

Re: [BK] upgrade will be needed

Re: [BK] upgrade will be needed

Re: [BK] upgrade will be needed

Re: [BK] upgrade will be needed

Re: [PATCH][RFC] Signal-per-fd for RT signals

Re: [PATCH][RFC] Signal-per-fd for RT signals

Re: Happy new year^H^H^H^Hkernel..

Re: Happy new year^H^H^H^Hkernel..

Re: Happy new year^H^H^H^Hkernel..

Re: Happy new year^H^H^H^Hkernel..

Re: Happy new year^H^H^H^Hkernel..

Re: Happy new year^H^H^H^Hkernel..

18 matches

Site Navigation

Mail list logo

Footer information