Re: extra bytes written to SATA DVD drive on kernel 2.6.23 till 2.6.24.2
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 >> Co
extra bytes written to SATA DVD drive on kernel 2.6.23 till 2.6.24.2
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 18:20
Re: memcpy(a,b,CONST) is not inlined by gcc 3.4.1 in Linux kernel
>> 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
>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
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: [PATCH][RFC] Signal-per-fd for RT signals
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: Happy new year^H^H^H^Hkernel..
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..
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..
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
@@ -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
