Hello All , I am having a difficulty with the dpt_120 driver &
the sym2-53c8xx driver . I have just placed a Adaptec 2010s raid
controller in my system & it now wants to take device 0800 away
from the sym2 driver at boot time . ALL drivers are statically
built into the kernel . Is there a way at either of the methods
stated in the subjec to get the order back so that I have my real
root file system back on 0800 ? Tia , JimL
--
+------------------------------------------------------------------+
| James W. Laferriere | System Techniques | Give me VMS |
| Network Engineer | P.O. Box 854 | Give me Linux |
| [email protected] | Coudersport PA 16915 | only on AXP |
+------------------------------------------------------------------+
In fa.linux.kernel, you wrote:
>
> Hi,
>
> Here goes release canditate 2. The aic7xxx problems should be fixed.
Hello,
does it "only" correct the aic7xxx probolems, or does it also include
some other changes?
My main interest is the XFS merge that is in 2.4.21-rc1-ac3 ;-)
Thank you very much,
Gr?goire
________________________________________________________________
http://ulima.unil.ch/greg ICQ:16624071 mailto:[email protected]
On Friday 09 May 2003 08:55, Gregoire Favre wrote:
Hi Gregoire,
> > Here goes release canditate 2. The aic7xxx problems should be fixed.
> does it "only" correct the aic7xxx probolems, or does it also include
> some other changes?
http://www.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.21.log
or: http://www.kernel.org -> 2.4.21-rc2 -> Changelog
> My main interest is the XFS merge that is in 2.4.21-rc1-ac3 ;-)
muahaha.
ciao, Marc
Morning,
On Fri, 2003-05-09 at 07:55, Gregoire Favre wrote:
> Hello,
>
> does it "only" correct the aic7xxx probolems, or does it also include
> some other changes?
The answer there is yes, there are plenty of other changes in there.
patch-2.4.21.log details them.
> My main interest is the XFS merge that is in 2.4.21-rc1-ac3 ;-)
Just checked the log, AFAICT there is no XFS fixes in the delta between
-rc1 and -rc2.
HTH,
/Anders
On Fri, May 09, 2003 at 09:07:50AM +0200, Marc-Christian Petersen wrote:
Hello Marc-Christian ;-)
> http://www.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.21.log
>
> or: http://www.kernel.org -> 2.4.21-rc2 -> Changelog
Yes, I agree, but... why no directly write it in the annonce?
And as I would like to have XFS included...
Thank you very much,
Gr?goire
________________________________________________________________
http://ulima.unil.ch/greg ICQ:16624071 mailto:[email protected]
On Friday 09 May 2003 09:31, Gregoire Favre wrote:
Hi Gregoire,
> > or: http://www.kernel.org -> 2.4.21-rc2 -> Changelog
> Yes, I agree, but... why no directly write it in the annonce?
> And as I would like to have XFS included...
I am quite sure he just forgot to include it into the mail.
for XFS, use 2.5.
ciao, Marc
On Fri, May 09, 2003 at 09:35:06AM +0200, Marc-Christian Petersen wrote:
> I am quite sure he just forgot to include it into the mail.
So my "question" ;-)
> for XFS, use 2.5.
Or 2.4.21-rc1-ac[34], yes I know, for me the stability of 2.5 is about
10 minutes if I use DVB, so 2.5 are not yet a solution...
I also use the CVS version of XFS :-)
Have a good day,
Gr?goire
________________________________________________________________
http://ulima.unil.ch/greg ICQ:16624071 mailto:[email protected]
drivers/sound/kahlua.c in 2.4.21-rc2 causes a .text.exit error at the
final linking when compiled statically into a kernel with CONFIG_HOTPLUG
enabled. The pointer to remove_one is __devexit_p and not discarded but
the __exit remove_one is discarded.
The following patch is needed:
--- linux-2.4.21-rc2-full/drivers/sound/kahlua.c.old 2003-05-10 19:03:12.000000000 +0200
+++ linux-2.4.21-rc2-full/drivers/sound/kahlua.c 2003-05-10 19:03:41.000000000 +0200
@@ -182,7 +182,7 @@
return 0;
}
-static void __exit remove_one(struct pci_dev *pdev)
+static void __devexit remove_one(struct pci_dev *pdev)
{
struct address_info *hw_config = pci_get_drvdata(pdev);
sb_dsp_unload(hw_config, 0);
@@ -219,7 +219,7 @@
return pci_module_init(&kahlua_driver);
}
-static void __exit kahlua_cleanup_module(void)
+static void __devexit kahlua_cleanup_module(void)
{
return pci_unregister_driver(&kahlua_driver);
}
Please apply for -rc3
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
ips_remove_device in drivers/scsi/ips.c is __devexit but it's called
from the __devinit ips_insert_device resulting in a compile error when
cmpiled statically into a kernel without CONFIG_HOTPLUG enables.
The patch below solves this by removing the __devexit from
ips_remove_device.
Please apply for -rc3
Adrian
--- linux-2.4.21-pre6-full-nohotplug/drivers/scsi/ips.c.old 2003-03-27 22:25:49.000000000 +0100
+++ linux-2.4.21-pre6-full-nohotplug/drivers/scsi/ips.c 2003-03-27 22:28:51.000000000 +0100
@@ -246,9 +246,6 @@
#define IPS_SG_ADDRESS(sg) ((sg)->address)
#define IPS_LOCK_SAVE(lock,flags) spin_lock_irqsave(&io_request_lock,flags)
#define IPS_UNLOCK_RESTORE(lock,flags) spin_unlock_irqrestore(&io_request_lock,flags)
- #ifndef __devexit_p
- #define __devexit_p(x) x
- #endif
#else
#define IPS_SG_ADDRESS(sg) (page_address((sg)->page) ? \
page_address((sg)->page)+(sg)->offset : 0)
@@ -338,48 +335,48 @@
static char ips_hot_plug_name[] = "ips";
static int __devinit ips_insert_device(struct pci_dev *pci_dev, const struct pci_device_id *ent);
- static void __devexit ips_remove_device(struct pci_dev *pci_dev);
+ static void ips_remove_device(struct pci_dev *pci_dev);
struct pci_driver ips_pci_driver = {
name: ips_hot_plug_name,
id_table: ips_pci_table,
probe: ips_insert_device,
- remove: __devexit_p(ips_remove_device),
+ remove: ips_remove_device,
};
struct pci_driver ips_pci_driver_anaconda = {
name: ips_hot_plug_name,
id_table: ips_pci_table_anaconda,
probe: ips_insert_device,
- remove: __devexit_p(ips_remove_device),
+ remove: ips_remove_device,
};
struct pci_driver ips_pci_driver_5i = {
name: ips_hot_plug_name,
id_table: ips_pci_table_5i,
probe: ips_insert_device,
- remove: __devexit_p(ips_remove_device),
+ remove: ips_remove_device,
};
struct pci_driver ips_pci_driver_6i = {
name: ips_hot_plug_name,
id_table: ips_pci_table_6i,
probe: ips_insert_device,
- remove: __devexit_p(ips_remove_device),
+ remove: ips_remove_device,
};
struct pci_driver ips_pci_driver_i960 = {
name: ips_hot_plug_name,
id_table: ips_pci_table_i960,
probe: ips_insert_device,
- remove: __devexit_p(ips_remove_device),
+ remove: ips_remove_device,
};
struct pci_driver ips_pci_driver_adaptec = {
name: ips_hot_plug_name,
id_table: ips_pci_table_adaptec,
probe: ips_insert_device,
- remove: __devexit_p(ips_remove_device),
+ remove: ips_remove_device,
};
#endif
@@ -7346,7 +7343,7 @@
/* Routine Description: */
/* Remove one Adapter ( Hot Plugging ) */
/*---------------------------------------------------------------------------*/
-static void __devexit ips_remove_device(struct pci_dev *pci_dev)
+static void ips_remove_device(struct pci_dev *pci_dev)
{
int i;
struct Scsi_Host *sh;
#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
CONFIG_MK6=y
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MELAN is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_ALIGNMENT_16=y
CONFIG_X86_HAS_TSC=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_MCE=y
CONFIG_TOSHIBA=m
CONFIG_I8K=m
CONFIG_MICROCODE=m
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_HIGHMEM=y
CONFIG_HIGHIO=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_TSC_DISABLE is not set
CONFIG_X86_TSC=y
#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_ISA=y
CONFIG_PCI_NAMES=y
CONFIG_EISA=y
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y
#
# PCMCIA/CardBus support
#
# CONFIG_PCMCIA is not set
#
# PCI Hotplug Support
#
# CONFIG_HOTPLUG_PCI is not set
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set
# CONFIG_HOTPLUG_PCI_IBM is not set
# CONFIG_HOTPLUG_PCI_ACPI is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=m
CONFIG_PM=y
CONFIG_ACPI=y
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_BUSMGR=m
CONFIG_ACPI_SYS=m
CONFIG_ACPI_CPU=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_AC=m
CONFIG_ACPI_EC=m
CONFIG_ACPI_CMBATT=m
CONFIG_ACPI_THERMAL=m
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
# CONFIG_APM_CPU_IDLE is not set
CONFIG_APM_DISPLAY_BLANK=y
# CONFIG_APM_RTC_IS_GMT is not set
CONFIG_APM_ALLOW_INTS=y
CONFIG_APM_REAL_MODE_POWER_OFF=y
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
CONFIG_PARPORT_SERIAL=m
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_PC_SUPERIO=y
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_SUNBPP is not set
CONFIG_PARPORT_OTHER=y
CONFIG_PARPORT_1284=y
#
# Plug and Play configuration
#
CONFIG_PNP=y
CONFIG_ISAPNP=m
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_XD=m
CONFIG_PARIDE=m
CONFIG_PARIDE_PARPORT=m
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m
CONFIG_PARIDE_ATEN=m
CONFIG_PARIDE_BPCK=m
CONFIG_PARIDE_BPCK6=m
CONFIG_PARIDE_COMM=m
CONFIG_PARIDE_DSTR=m
CONFIG_PARIDE_FIT2=m
CONFIG_PARIDE_FIT3=m
CONFIG_PARIDE_EPAT=m
CONFIG_PARIDE_EPATC8=y
CONFIG_PARIDE_EPIA=m
CONFIG_PARIDE_FRIQ=m
CONFIG_PARIDE_FRPW=m
CONFIG_PARIDE_KBIC=m
CONFIG_PARIDE_KTTI=m
CONFIG_PARIDE_ON20=m
CONFIG_PARIDE_ON26=m
CONFIG_BLK_CPQ_DA=m
CONFIG_BLK_CPQ_CISS_DA=m
CONFIG_CISS_SCSI_TAPE=y
CONFIG_BLK_DEV_DAC960=m
CONFIG_BLK_DEV_UMEM=m
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=64000
CONFIG_BLK_DEV_INITRD=y
# CONFIG_BLK_STATS is not set
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=m
CONFIG_MD_RAID0=m
CONFIG_MD_RAID1=m
CONFIG_MD_RAID5=m
CONFIG_MD_MULTIPATH=m
CONFIG_BLK_DEV_LVM=m
#
# Networking options
#
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=m
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_FWMARK=y
CONFIG_IP_ROUTE_NAT=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_TOS=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_ROUTE_LARGE_TABLES=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=m
CONFIG_IP_NF_FTP=m
# CONFIG_IP_NF_AMANDA is not set
# CONFIG_IP_NF_TFTP is not set
CONFIG_IP_NF_IRC=m
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_LIMIT=m
CONFIG_IP_NF_MATCH_MAC=m
CONFIG_IP_NF_MATCH_PKTTYPE=m
CONFIG_IP_NF_MATCH_MARK=m
CONFIG_IP_NF_MATCH_MULTIPORT=m
CONFIG_IP_NF_MATCH_TOS=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_DSCP=m
CONFIG_IP_NF_MATCH_AH_ESP=m
CONFIG_IP_NF_MATCH_LENGTH=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_MATCH_TCPMSS=m
CONFIG_IP_NF_MATCH_HELPER=m
CONFIG_IP_NF_MATCH_STATE=m
CONFIG_IP_NF_MATCH_CONNTRACK=m
CONFIG_IP_NF_MATCH_UNCLEAN=m
CONFIG_IP_NF_MATCH_OWNER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_MIRROR=m
CONFIG_IP_NF_NAT=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_REDIRECT=m
# CONFIG_IP_NF_NAT_LOCAL is not set
CONFIG_IP_NF_NAT_SNMP_BASIC=m
CONFIG_IP_NF_NAT_IRC=m
CONFIG_IP_NF_NAT_FTP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_TOS=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_DSCP=m
CONFIG_IP_NF_TARGET_MARK=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_IP_NF_TARGET_TCPMSS=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_COMPAT_IPCHAINS=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_COMPAT_IPFWADM=m
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IPV6=m
#
# IPv6: Netfilter Configuration
#
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_LIMIT=m
CONFIG_IP6_NF_MATCH_MAC=m
# CONFIG_IP6_NF_MATCH_RT is not set
# CONFIG_IP6_NF_MATCH_OPTS is not set
# CONFIG_IP6_NF_MATCH_FRAG is not set
# CONFIG_IP6_NF_MATCH_HL is not set
CONFIG_IP6_NF_MATCH_MULTIPORT=m
CONFIG_IP6_NF_MATCH_OWNER=m
CONFIG_IP6_NF_MATCH_MARK=m
# CONFIG_IP6_NF_MATCH_IPV6HEADER is not set
# CONFIG_IP6_NF_MATCH_AHESP is not set
CONFIG_IP6_NF_MATCH_LENGTH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_TARGET_MARK=m
CONFIG_KHTTPD=m
CONFIG_ATM=y
CONFIG_ATM_CLIP=y
CONFIG_ATM_CLIP_NO_ICMP=y
CONFIG_ATM_LANE=m
CONFIG_ATM_MPOA=m
CONFIG_ATM_BR2684=m
# CONFIG_ATM_BR2684_IPFILTER is not set
CONFIG_VLAN_8021Q=m
CONFIG_IPX=m
# CONFIG_IPX_INTERN is not set
CONFIG_ATALK=m
#
# Appletalk devices
#
CONFIG_DEV_APPLETALK=y
CONFIG_LTPC=m
CONFIG_COPS=m
CONFIG_COPS_DAYNA=y
CONFIG_COPS_TANGENT=y
CONFIG_IPDDP=m
CONFIG_IPDDP_ENCAP=y
CONFIG_IPDDP_DECAP=y
CONFIG_DECNET=m
CONFIG_DECNET_SIOCGIFCONF=y
# CONFIG_DECNET_ROUTER is not set
CONFIG_BRIDGE=m
CONFIG_X25=m
CONFIG_LAPB=m
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
CONFIG_ECONET=m
# CONFIG_ECONET_AUNUDP is not set
# CONFIG_ECONET_NATIVE is not set
CONFIG_WAN_ROUTER=m
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_ATM=y
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y
#
# Network testing
#
CONFIG_NET_PKTGEN=m
#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set
# CONFIG_PHONE_IXJ_PCMCIA is not set
#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y
#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_IDEDISK_STROKE=y
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDETAPE=m
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_BLK_DEV_IDESCSI=m
# CONFIG_IDE_TASK_IOCTL is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_OFFBOARD=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_BLK_DEV_ADMA100 is not set
# CONFIG_BLK_DEV_AEC62XX is not set
CONFIG_BLK_DEV_ALI15X3=y
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_AMD74XX_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
CONFIG_BLK_DEV_PDC202XX_OLD=y
CONFIG_PDC202XX_BURST=y
CONFIG_BLK_DEV_PDC202XX_NEW=y
CONFIG_PDC202XX_FORCE=y
# CONFIG_BLK_DEV_RZ1000 is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
CONFIG_IDE_CHIPSETS=y
CONFIG_BLK_DEV_4DRIVES=y
CONFIG_BLK_DEV_ALI14XX=y
# CONFIG_BLK_DEV_DTC2278 is not set
# CONFIG_BLK_DEV_HT6560B is not set
# CONFIG_BLK_DEV_PDC4030 is not set
# CONFIG_BLK_DEV_QD65XX is not set
# CONFIG_BLK_DEV_UMC8672 is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_PDC202XX=y
CONFIG_BLK_DEV_IDE_MODES=y
CONFIG_BLK_DEV_ATARAID=m
CONFIG_BLK_DEV_ATARAID_PDC=m
CONFIG_BLK_DEV_ATARAID_HPT=m
CONFIG_BLK_DEV_ATARAID_SII=m
#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
CONFIG_CHR_DEV_ST=m
CONFIG_CHR_DEV_OSST=m
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_SR_EXTRA_DEVS=4
CONFIG_CHR_DEV_SG=m
# CONFIG_SCSI_DEBUG_QUEUES is not set
CONFIG_SCSI_MULTI_LUN=y
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
#
# SCSI low-level drivers
#
CONFIG_BLK_DEV_3W_XXXX_RAID=m
CONFIG_SCSI_7000FASST=m
CONFIG_SCSI_ACARD=m
CONFIG_SCSI_AHA152X=m
CONFIG_SCSI_AHA1542=m
CONFIG_SCSI_AHA1740=m
CONFIG_SCSI_AACRAID=m
CONFIG_SCSI_AIC7XXX=m
CONFIG_AIC7XXX_CMDS_PER_DEVICE=32
CONFIG_AIC7XXX_RESET_DELAY_MS=5000
CONFIG_AIC7XXX_PROBE_EISA_VL=y
# CONFIG_AIC7XXX_BUILD_FIRMWARE is not set
# CONFIG_SCSI_AIC79XX is not set
CONFIG_SCSI_AIC7XXX_OLD=m
CONFIG_AIC7XXX_OLD_TCQ_ON_BY_DEFAULT=y
CONFIG_AIC7XXX_OLD_CMDS_PER_DEVICE=24
CONFIG_AIC7XXX_OLD_PROC_STATS=y
CONFIG_SCSI_DPT_I2O=m
CONFIG_SCSI_ADVANSYS=m
CONFIG_SCSI_IN2000=m
CONFIG_SCSI_AM53C974=m
CONFIG_SCSI_MEGARAID=m
CONFIG_SCSI_BUSLOGIC=m
# CONFIG_SCSI_OMIT_FLASHPOINT is not set
CONFIG_SCSI_CPQFCTS=m
CONFIG_SCSI_DMX3191D=m
CONFIG_SCSI_DTC3280=m
CONFIG_SCSI_EATA=m
CONFIG_SCSI_EATA_TAGGED_QUEUE=y
CONFIG_SCSI_EATA_LINKED_COMMANDS=y
CONFIG_SCSI_EATA_MAX_TAGS=16
CONFIG_SCSI_EATA_DMA=m
CONFIG_SCSI_EATA_PIO=m
CONFIG_SCSI_FUTURE_DOMAIN=m
CONFIG_SCSI_GDTH=m
CONFIG_SCSI_GENERIC_NCR5380=m
CONFIG_SCSI_GENERIC_NCR53C400=y
CONFIG_SCSI_G_NCR5380_PORT=y
# CONFIG_SCSI_G_NCR5380_MEM is not set
CONFIG_SCSI_IPS=m
CONFIG_SCSI_INITIO=m
CONFIG_SCSI_INIA100=m
CONFIG_SCSI_PPA=m
CONFIG_SCSI_IMM=m
# CONFIG_SCSI_IZIP_EPP16 is not set
# CONFIG_SCSI_IZIP_SLOW_CTR is not set
CONFIG_SCSI_NCR53C406A=m
CONFIG_SCSI_NCR53C7xx=m
# CONFIG_SCSI_NCR53C7xx_sync is not set
CONFIG_SCSI_NCR53C7xx_FAST=y
CONFIG_SCSI_NCR53C7xx_DISCONNECT=y
CONFIG_SCSI_SYM53C8XX_2=m
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
CONFIG_SCSI_NCR53C8XX=m
CONFIG_SCSI_SYM53C8XX=m
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=80
CONFIG_SCSI_NCR53C8XX_PROFILE=y
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
CONFIG_SCSI_NCR53C8XX_PQS_PDS=y
# CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set
CONFIG_SCSI_PAS16=m
CONFIG_SCSI_PCI2000=m
CONFIG_SCSI_PCI2220I=m
CONFIG_SCSI_PSI240I=m
CONFIG_SCSI_QLOGIC_FAS=m
CONFIG_SCSI_QLOGIC_ISP=m
CONFIG_SCSI_QLOGIC_FC=m
CONFIG_SCSI_QLOGIC_FC_FIRMWARE=y
CONFIG_SCSI_QLOGIC_1280=m
CONFIG_SCSI_SEAGATE=m
CONFIG_SCSI_SIM710=m
CONFIG_SCSI_SYM53C416=m
CONFIG_SCSI_DC390T=m
# CONFIG_SCSI_DC390T_NOGENSUPP is not set
CONFIG_SCSI_T128=m
CONFIG_SCSI_U14_34F=m
CONFIG_SCSI_U14_34F_LINKED_COMMANDS=y
CONFIG_SCSI_U14_34F_MAX_TAGS=8
CONFIG_SCSI_ULTRASTOR=m
# CONFIG_SCSI_NSP32 is not set
CONFIG_SCSI_DEBUG=m
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_BOOT is not set
# CONFIG_FUSION_ISENSE is not set
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set
#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set
#
# I2O device support
#
CONFIG_I2O=m
CONFIG_I2O_PCI=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_LAN=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
CONFIG_ARCNET=m
CONFIG_ARCNET_1201=m
CONFIG_ARCNET_1051=m
CONFIG_ARCNET_RAW=m
CONFIG_ARCNET_COM90xx=m
CONFIG_ARCNET_COM90xxIO=m
CONFIG_ARCNET_RIM_I=m
CONFIG_ARCNET_COM20020=m
CONFIG_ARCNET_COM20020_ISA=m
CONFIG_ARCNET_COM20020_PCI=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_ETHERTAP=m
CONFIG_NET_SB1000=m
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_SUNLANCE is not set
CONFIG_HAPPYMEAL=m
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
CONFIG_SUNGEM=m
CONFIG_NET_VENDOR_3COM=y
CONFIG_EL1=m
CONFIG_EL2=m
CONFIG_ELPLUS=m
CONFIG_EL16=m
CONFIG_EL3=m
CONFIG_3C515=m
# CONFIG_ELMC is not set
# CONFIG_ELMC_II is not set
CONFIG_VORTEX=m
# CONFIG_TYPHOON is not set
CONFIG_LANCE=m
CONFIG_NET_VENDOR_SMC=y
CONFIG_WD80x3=m
# CONFIG_ULTRAMCA is not set
CONFIG_ULTRA=m
CONFIG_ULTRA32=m
CONFIG_SMC9194=m
CONFIG_NET_VENDOR_RACAL=y
CONFIG_NI5010=m
CONFIG_NI52=m
CONFIG_NI65=m
CONFIG_AT1700=m
CONFIG_DEPCA=m
CONFIG_HP100=m
CONFIG_NET_ISA=y
CONFIG_E2100=m
CONFIG_EWRK3=m
CONFIG_EEXPRESS=m
CONFIG_EEXPRESS_PRO=m
CONFIG_HPLAN_PLUS=m
CONFIG_HPLAN=m
CONFIG_LP486E=m
CONFIG_ETH16I=m
CONFIG_NE2000=m
CONFIG_NET_PCI=y
CONFIG_PCNET32=m
# CONFIG_AMD8111_ETH is not set
CONFIG_ADAPTEC_STARFIRE=m
CONFIG_AC3200=m
CONFIG_APRICOT=m
CONFIG_CS89x0=m
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
# CONFIG_TULIP_MMIO is not set
CONFIG_DE4X5=m
CONFIG_DGRS=m
CONFIG_DM9102=m
CONFIG_EEPRO100=m
# CONFIG_EEPRO100_PIO is not set
CONFIG_E100=m
CONFIG_LNE390=m
CONFIG_FEALNX=m
CONFIG_NATSEMI=m
CONFIG_NE2K_PCI=m
CONFIG_NE3210=m
CONFIG_ES3210=m
CONFIG_8139CP=m
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
CONFIG_8139TOO_8129=y
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_SIS900=m
CONFIG_EPIC100=m
CONFIG_SUNDANCE=m
# CONFIG_SUNDANCE_MMIO is not set
CONFIG_TLAN=m
CONFIG_TC35815=m
CONFIG_VIA_RHINE=m
# CONFIG_VIA_RHINE_MMIO is not set
CONFIG_WINBOND_840=m
CONFIG_NET_POCKET=y
CONFIG_ATP=m
CONFIG_DE600=m
CONFIG_DE620=m
#
# Ethernet (1000 Mbit)
#
CONFIG_ACENIC=m
# CONFIG_ACENIC_OMIT_TIGON_I is not set
CONFIG_DL2K=m
CONFIG_E1000=m
# CONFIG_MYRI_SBUS is not set
CONFIG_NS83820=m
CONFIG_HAMACHI=m
CONFIG_YELLOWFIN=m
# CONFIG_R8169 is not set
CONFIG_SK98LIN=m
CONFIG_TIGON3=m
CONFIG_FDDI=y
CONFIG_DEFXX=m
CONFIG_SKFP=m
CONFIG_HIPPI=y
CONFIG_ROADRUNNER=m
CONFIG_ROADRUNNER_LARGE_RINGS=y
CONFIG_PLIP=m
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
CONFIG_SLIP=m
CONFIG_SLIP_COMPRESSED=y
CONFIG_SLIP_SMART=y
CONFIG_SLIP_MODE_SLIP6=y
#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
CONFIG_STRIP=m
CONFIG_WAVELAN=m
CONFIG_ARLAN=m
CONFIG_AIRONET4500=m
CONFIG_AIRONET4500_NONCS=m
CONFIG_AIRONET4500_PNP=y
CONFIG_AIRONET4500_PCI=y
CONFIG_AIRONET4500_ISA=y
CONFIG_AIRONET4500_I365=y
CONFIG_AIRONET4500_PROC=m
CONFIG_AIRO=m
CONFIG_HERMES=m
CONFIG_PLX_HERMES=m
CONFIG_PCI_HERMES=m
CONFIG_NET_WIRELESS=y
#
# Token Ring devices
#
CONFIG_TR=y
CONFIG_IBMTR=m
CONFIG_IBMOL=m
CONFIG_IBMLS=m
CONFIG_3C359=m
CONFIG_TMS380TR=m
CONFIG_TMSPCI=m
CONFIG_TMSISA=m
CONFIG_ABYSS=m
# CONFIG_MADGEMC is not set
CONFIG_SMCTR=m
CONFIG_NET_FC=y
CONFIG_IPHASE5526=m
CONFIG_RCPCI=m
CONFIG_SHAPER=m
#
# Wan interfaces
#
CONFIG_WAN=y
CONFIG_HOSTESS_SV11=m
CONFIG_COSA=m
CONFIG_COMX=m
CONFIG_COMX_HW_COMX=m
CONFIG_COMX_HW_LOCOMX=m
CONFIG_COMX_HW_MIXCOM=m
CONFIG_COMX_HW_MUNICH=m
CONFIG_COMX_PROTO_PPP=m
CONFIG_COMX_PROTO_LAPB=m
CONFIG_COMX_PROTO_FR=m
CONFIG_DSCC4=m
CONFIG_LANMEDIA=m
CONFIG_ATI_XX20=m
CONFIG_SEALEVEL_4021=m
CONFIG_SYNCLINK_SYNCPPP=m
CONFIG_HDLC=m
# CONFIG_HDLC_RAW is not set
# CONFIG_HDLC_CISCO is not set
# CONFIG_HDLC_FR is not set
CONFIG_HDLC_PPP=y
CONFIG_HDLC_X25=y
CONFIG_N2=m
CONFIG_C101=m
CONFIG_FARSYNC=m
# CONFIG_HDLC_DEBUG_PKT is not set
# CONFIG_HDLC_DEBUG_HARD_HEADER is not set
# CONFIG_HDLC_DEBUG_ECN is not set
# CONFIG_HDLC_DEBUG_RINGS is not set
CONFIG_DLCI=m
CONFIG_DLCI_COUNT=24
CONFIG_DLCI_MAX=8
CONFIG_SDLA=m
CONFIG_WAN_ROUTER_DRIVERS=y
CONFIG_VENDOR_SANGOMA=m
CONFIG_WANPIPE_CHDLC=y
# CONFIG_WANPIPE_FR is not set
CONFIG_WANPIPE_X25=y
CONFIG_WANPIPE_PPP=y
CONFIG_WANPIPE_MULTPPP=y
CONFIG_CYCLADES_SYNC=m
CONFIG_CYCLOMX_X25=y
CONFIG_LAPBETHER=m
CONFIG_X25_ASY=m
CONFIG_SBNI=m
CONFIG_SBNI_MULTILINE=y
#
# ATM drivers
#
CONFIG_ATM_TCP=m
CONFIG_ATM_LANAI=m
CONFIG_ATM_ENI=m
# CONFIG_ATM_ENI_DEBUG is not set
# CONFIG_ATM_ENI_TUNE_BURST is not set
CONFIG_ATM_FIRESTREAM=m
CONFIG_ATM_ZATM=m
# CONFIG_ATM_ZATM_DEBUG is not set
CONFIG_ATM_ZATM_EXACT_TS=y
CONFIG_ATM_NICSTAR=m
CONFIG_ATM_NICSTAR_USE_SUNI=y
CONFIG_ATM_NICSTAR_USE_IDT77105=y
CONFIG_ATM_IDT77252=m
# CONFIG_ATM_IDT77252_DEBUG is not set
CONFIG_ATM_IDT77252_RCV_ALL=y
CONFIG_ATM_IDT77252_USE_SUNI=y
CONFIG_ATM_AMBASSADOR=m
# CONFIG_ATM_AMBASSADOR_DEBUG is not set
CONFIG_ATM_HORIZON=m
# CONFIG_ATM_HORIZON_DEBUG is not set
CONFIG_ATM_IA=m
# CONFIG_ATM_IA_DEBUG is not set
CONFIG_ATM_FORE200E_MAYBE=m
CONFIG_ATM_FORE200E_PCA=y
CONFIG_ATM_FORE200E_PCA_DEFAULT_FW=y
CONFIG_ATM_FORE200E_TX_RETRY=16
CONFIG_ATM_FORE200E_DEBUG=0
CONFIG_ATM_FORE200E=m
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set
#
# ISDN subsystem
#
CONFIG_ISDN=m
CONFIG_ISDN_BOOL=y
CONFIG_ISDN_PPP=y
CONFIG_ISDN_PPP_VJ=y
CONFIG_ISDN_MPP=y
CONFIG_ISDN_PPP_BSDCOMP=m
CONFIG_ISDN_AUDIO=y
CONFIG_ISDN_TTY_FAX=y
CONFIG_ISDN_X25=y
#
# ISDN feature submodules
#
CONFIG_ISDN_DRV_LOOP=m
CONFIG_ISDN_DIVERSION=m
#
# Passive ISDN cards
#
CONFIG_ISDN_DRV_HISAX=m
CONFIG_ISDN_HISAX=y
CONFIG_HISAX_EURO=y
CONFIG_DE_AOC=y
# CONFIG_HISAX_NO_SENDCOMPLETE is not set
# CONFIG_HISAX_NO_LLC is not set
# CONFIG_HISAX_NO_KEYPAD is not set
CONFIG_HISAX_1TR6=y
CONFIG_HISAX_NI1=y
CONFIG_HISAX_MAX_CARDS=8
# CONFIG_HISAX_16_0 is not set
# CONFIG_HISAX_16_3 is not set
# CONFIG_HISAX_AVM_A1 is not set
# CONFIG_HISAX_IX1MICROR2 is not set
# CONFIG_HISAX_ASUSCOM is not set
# CONFIG_HISAX_TELEINT is not set
# CONFIG_HISAX_HFCS is not set
# CONFIG_HISAX_SPORTSTER is not set
# CONFIG_HISAX_MIC is not set
# CONFIG_HISAX_ISURF is not set
# CONFIG_HISAX_HSTSAPHIR is not set
# CONFIG_HISAX_TELESPCI is not set
# CONFIG_HISAX_S0BOX is not set
# CONFIG_HISAX_FRITZPCI is not set
# CONFIG_HISAX_AVM_A1_PCMCIA is not set
CONFIG_HISAX_ELSA=y
# CONFIG_HISAX_DIEHLDIVA is not set
# CONFIG_HISAX_SEDLBAUER is not set
# CONFIG_HISAX_NETJET is not set
# CONFIG_HISAX_NETJET_U is not set
# CONFIG_HISAX_NICCY is not set
# CONFIG_HISAX_BKM_A4T is not set
# CONFIG_HISAX_SCT_QUADRO is not set
# CONFIG_HISAX_GAZEL is not set
# CONFIG_HISAX_HFC_PCI is not set
# CONFIG_HISAX_W6692 is not set
# CONFIG_HISAX_HFC_SX is not set
# CONFIG_HISAX_ENTERNOW_PCI is not set
# CONFIG_HISAX_DEBUG is not set
# CONFIG_HISAX_SEDLBAUER_CS is not set
# CONFIG_HISAX_ELSA_CS is not set
# CONFIG_HISAX_AVM_A1_CS is not set
# CONFIG_HISAX_ST5481 is not set
# CONFIG_HISAX_FRITZ_PCIPNP is not set
# CONFIG_USB_AUERISDN is not set
#
# Active ISDN cards
#
# CONFIG_ISDN_DRV_ICN is not set
# CONFIG_ISDN_DRV_PCBIT is not set
# CONFIG_ISDN_DRV_SC is not set
# CONFIG_ISDN_DRV_ACT2000 is not set
# CONFIG_ISDN_DRV_EICON is not set
# CONFIG_ISDN_DRV_TPAM is not set
CONFIG_ISDN_CAPI=m
CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y
CONFIG_ISDN_CAPI_MIDDLEWARE=y
CONFIG_ISDN_CAPI_CAPI20=m
CONFIG_ISDN_CAPI_CAPIFS_BOOL=y
CONFIG_ISDN_CAPI_CAPIFS=m
CONFIG_ISDN_CAPI_CAPIDRV=m
# CONFIG_ISDN_DRV_AVMB1_B1ISA is not set
# CONFIG_ISDN_DRV_AVMB1_B1PCI is not set
# CONFIG_ISDN_DRV_AVMB1_B1PCIV4 is not set
# CONFIG_ISDN_DRV_AVMB1_T1ISA is not set
# CONFIG_ISDN_DRV_AVMB1_B1PCMCIA is not set
# CONFIG_ISDN_DRV_AVMB1_AVM_CS is not set
# CONFIG_ISDN_DRV_AVMB1_T1PCI is not set
# CONFIG_ISDN_DRV_AVMB1_C4 is not set
CONFIG_HYSDN=m
CONFIG_HYSDN_CAPI=y
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Input core support
#
CONFIG_INPUT=m
CONFIG_INPUT_KEYBDEV=m
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
CONFIG_INPUT_JOYDEV=m
CONFIG_INPUT_EVDEV=m
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
CONFIG_SERIAL_EXTENDED=y
CONFIG_SERIAL_MANY_PORTS=y
CONFIG_SERIAL_SHARE_IRQ=y
# CONFIG_SERIAL_DETECT_IRQ is not set
CONFIG_SERIAL_MULTIPORT=y
CONFIG_HUB6=y
CONFIG_SERIAL_NONSTANDARD=y
CONFIG_COMPUTONE=m
CONFIG_ROCKETPORT=m
CONFIG_CYCLADES=m
# CONFIG_CYZ_INTR is not set
CONFIG_DIGIEPCA=m
CONFIG_ESPSERIAL=m
CONFIG_MOXA_INTELLIO=m
CONFIG_MOXA_SMARTIO=m
CONFIG_ISI=m
CONFIG_SYNCLINK=m
# CONFIG_SYNCLINKMP is not set
CONFIG_N_HDLC=m
CONFIG_RISCOM8=m
CONFIG_SPECIALIX=m
CONFIG_SPECIALIX_RTSCTS=y
CONFIG_SX=m
CONFIG_RIO=m
CONFIG_RIO_OLDPCI=y
CONFIG_STALDRV=y
CONFIG_STALLION=m
CONFIG_ISTALLION=m
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
CONFIG_PPDEV=m
# CONFIG_TIPAR is not set
#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_PHILIPSPAR=m
CONFIG_I2C_ELV=m
CONFIG_I2C_VELLEMAN=m
# CONFIG_SCx200_I2C is not set
# CONFIG_SCx200_ACB is not set
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ELEKTOR=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_PROC=m
#
# Mice
#
CONFIG_BUSMOUSE=m
CONFIG_ATIXL_BUSMOUSE=m
CONFIG_LOGIBUSMOUSE=m
CONFIG_MS_BUSMOUSE=m
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
CONFIG_82C710_MOUSE=y
CONFIG_PC110_PAD=m
CONFIG_MK712_MOUSE=m
#
# Joysticks
#
CONFIG_INPUT_GAMEPORT=m
CONFIG_INPUT_NS558=m
CONFIG_INPUT_LIGHTNING=m
CONFIG_INPUT_PCIGAME=m
CONFIG_INPUT_CS461X=m
CONFIG_INPUT_EMU10K1=m
CONFIG_INPUT_SERIO=m
CONFIG_INPUT_SERPORT=m
CONFIG_INPUT_ANALOG=m
CONFIG_INPUT_A3D=m
CONFIG_INPUT_ADI=m
CONFIG_INPUT_COBRA=m
CONFIG_INPUT_GF2K=m
CONFIG_INPUT_GRIP=m
CONFIG_INPUT_INTERACT=m
CONFIG_INPUT_TMDC=m
CONFIG_INPUT_SIDEWINDER=m
CONFIG_INPUT_IFORCE_USB=m
CONFIG_INPUT_IFORCE_232=m
CONFIG_INPUT_WARRIOR=m
CONFIG_INPUT_MAGELLAN=m
CONFIG_INPUT_SPACEORB=m
CONFIG_INPUT_SPACEBALL=m
CONFIG_INPUT_STINGER=m
CONFIG_INPUT_DB9=m
CONFIG_INPUT_GAMECON=m
CONFIG_INPUT_TURBOGRAFX=m
CONFIG_QIC02_TAPE=m
CONFIG_QIC02_DYNCONF=y
# CONFIG_IPMI_HANDLER is not set
# CONFIG_IPMI_PANIC_EVENT is not set
# CONFIG_IPMI_DEVICE_INTERFACE is not set
# CONFIG_IPMI_KCS is not set
# CONFIG_IPMI_WATCHDOG is not set
#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_NOWAYOUT=y
CONFIG_ACQUIRE_WDT=m
CONFIG_ADVANTECH_WDT=m
# CONFIG_ALIM1535_WDT is not set
CONFIG_ALIM7101_WDT=m
CONFIG_SC520_WDT=m
CONFIG_PCWATCHDOG=m
CONFIG_EUROTECH_WDT=m
CONFIG_IB700_WDT=m
CONFIG_WAFER_WDT=m
CONFIG_I810_TCO=m
CONFIG_MIXCOMWD=m
CONFIG_60XX_WDT=m
CONFIG_SC1200_WDT=m
# CONFIG_SCx200_WDT is not set
CONFIG_SOFT_WATCHDOG=m
CONFIG_W83877F_WDT=m
CONFIG_WDT=m
CONFIG_WDTPCI=m
CONFIG_WDT_501=y
CONFIG_WDT_501_FAN=y
CONFIG_MACHZ_WDT=m
# CONFIG_AMD7XX_TCO is not set
# CONFIG_SCx200_GPIO is not set
CONFIG_AMD_RNG=m
CONFIG_INTEL_RNG=m
CONFIG_AMD_PM768=m
CONFIG_NVRAM=m
CONFIG_RTC=y
CONFIG_DTLK=m
CONFIG_R3964=m
CONFIG_APPLICOM=m
CONFIG_SONYPI=m
#
# Ftape, the floppy tape device driver
#
CONFIG_FTAPE=m
CONFIG_ZFTAPE=m
CONFIG_ZFT_DFLT_BLK_SZ=10240
CONFIG_ZFT_COMPRESSOR=m
CONFIG_FT_NR_BUFFERS=3
CONFIG_FT_PROC_FS=y
CONFIG_FT_NORMAL_DEBUG=y
# CONFIG_FT_FULL_DEBUG is not set
# CONFIG_FT_NO_TRACE is not set
# CONFIG_FT_NO_TRACE_AT_ALL is not set
CONFIG_FT_STD_FDC=y
# CONFIG_FT_MACH2 is not set
# CONFIG_FT_PROBE_FC10 is not set
# CONFIG_FT_ALT_FDC is not set
CONFIG_FT_FDC_THR=8
CONFIG_FT_FDC_MAX_RATE=2000
CONFIG_FT_ALPHA_CLOCK=0
CONFIG_AGP=m
CONFIG_AGP_INTEL=y
CONFIG_AGP_I810=y
CONFIG_AGP_VIA=y
CONFIG_AGP_AMD=y
CONFIG_AGP_AMD_8151=y
CONFIG_AGP_SIS=y
CONFIG_AGP_ALI=y
CONFIG_AGP_SWORKS=y
CONFIG_DRM=y
# CONFIG_DRM_OLD is not set
CONFIG_DRM_NEW=y
CONFIG_DRM_TDFX=m
CONFIG_DRM_R128=m
CONFIG_DRM_RADEON=m
CONFIG_DRM_I810=m
# CONFIG_DRM_I810_XFREE_41 is not set
CONFIG_DRM_I830=m
CONFIG_DRM_MGA=m
CONFIG_DRM_SIS=m
CONFIG_MWAVE=m
#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m
#
# Video For Linux
#
CONFIG_VIDEO_PROC_FS=y
CONFIG_I2C_PARPORT=m
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_PMS=m
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZR36120=m
CONFIG_VIDEO_MEYE=m
#
# Radio Adapters
#
# CONFIG_RADIO_CADET is not set
# CONFIG_RADIO_RTRACK is not set
# CONFIG_RADIO_RTRACK2 is not set
# CONFIG_RADIO_AZTECH is not set
# CONFIG_RADIO_GEMTEK is not set
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_MIROPCM20 is not set
# CONFIG_RADIO_MIROPCM20_RDS is not set
# CONFIG_RADIO_SF16FMI is not set
# CONFIG_RADIO_SF16FMR2 is not set
# CONFIG_RADIO_TERRATEC is not set
# CONFIG_RADIO_TRUST is not set
# CONFIG_RADIO_TYPHOON is not set
# CONFIG_RADIO_ZOLTRIX is not set
#
# File systems
#
CONFIG_QUOTA=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
CONFIG_ADFS_FS=m
# CONFIG_ADFS_FS_RW is not set
CONFIG_AFFS_FS=m
CONFIG_HFS_FS=m
# CONFIG_BEFS_FS is not set
# CONFIG_BEFS_DEBUG is not set
CONFIG_BFS_FS=m
CONFIG_EXT3_FS=y
CONFIG_JBD=y
CONFIG_JBD_DEBUG=y
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_UMSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_EFS_FS=m
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
CONFIG_CRAMFS=m
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_JFS_FS=m
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
CONFIG_MINIX_FS=y
CONFIG_VXFS_FS=m
CONFIG_NTFS_FS=m
# CONFIG_NTFS_RW is not set
CONFIG_HPFS_FS=m
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
CONFIG_QNX4FS_FS=m
# CONFIG_QNX4FS_RW is not set
CONFIG_ROMFS_FS=m
CONFIG_EXT2_FS=y
CONFIG_SYSV_FS=m
CONFIG_UDF_FS=m
CONFIG_UDF_RW=y
CONFIG_UFS_FS=m
# CONFIG_UFS_FS_WRITE is not set
#
# Network File Systems
#
CONFIG_CODA_FS=m
CONFIG_INTERMEZZO_FS=m
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_ROOT_NFS=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_TCP=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_SMB_FS=m
CONFIG_SMB_NLS_DEFAULT=y
CONFIG_SMB_NLS_REMOTE="cp437"
CONFIG_NCP_FS=m
CONFIG_NCPFS_PACKET_SIGNING=y
CONFIG_NCPFS_IOCTL_LOCKING=y
CONFIG_NCPFS_STRONG=y
CONFIG_NCPFS_NFS_NS=y
CONFIG_NCPFS_OS2_NS=y
CONFIG_NCPFS_SMALLDOS=y
CONFIG_NCPFS_NLS=y
CONFIG_NCPFS_EXTRAS=y
CONFIG_ZISOFS_FS=y
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_OSF_PARTITION=y
# CONFIG_AMIGA_PARTITION is not set
CONFIG_ATARI_PARTITION=y
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
# CONFIG_MINIX_SUBPARTITION is not set
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not set
CONFIG_ULTRIX_PARTITION=y
CONFIG_SUN_PARTITION=y
# CONFIG_EFI_PARTITION is not set
CONFIG_SMB_NLS=y
CONFIG_NLS=y
#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m
#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
CONFIG_VIDEO_SELECT=y
CONFIG_MDA_CONSOLE=m
#
# Frame-buffer support
#
CONFIG_FB=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FB_RIVA=m
CONFIG_FB_CLGEN=m
CONFIG_FB_PM2=m
CONFIG_FB_PM2_FIFO_DISCONNECT=y
CONFIG_FB_PM2_PCI=y
CONFIG_FB_PM3=m
CONFIG_FB_CYBER2000=m
CONFIG_FB_VESA=y
CONFIG_FB_VGA16=m
CONFIG_FB_HGA=m
CONFIG_VIDEO_SELECT=y
CONFIG_FB_MATROX=m
CONFIG_FB_MATROX_MILLENIUM=y
CONFIG_FB_MATROX_MYSTIQUE=y
CONFIG_FB_MATROX_G450=y
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_I2C=m
CONFIG_FB_MATROX_MAVEN=m
# CONFIG_FB_MATROX_PROC is not set
CONFIG_FB_MATROX_MULTIHEAD=y
CONFIG_FB_ATY=m
CONFIG_FB_ATY_GX=y
CONFIG_FB_ATY_CT=y
CONFIG_FB_RADEON=m
CONFIG_FB_ATY128=m
# CONFIG_FB_INTEL is not set
CONFIG_FB_SIS=m
CONFIG_FB_SIS_300=y
CONFIG_FB_SIS_315=y
CONFIG_FB_NEOMAGIC=m
CONFIG_FB_3DFX=m
CONFIG_FB_VOODOO1=m
CONFIG_FB_TRIDENT=m
# CONFIG_FB_VIRTUAL is not set
CONFIG_FBCON_ADVANCED=y
CONFIG_FBCON_MFB=m
CONFIG_FBCON_CFB2=m
CONFIG_FBCON_CFB4=m
CONFIG_FBCON_CFB8=y
CONFIG_FBCON_CFB16=y
CONFIG_FBCON_CFB24=y
CONFIG_FBCON_CFB32=y
CONFIG_FBCON_AFB=m
CONFIG_FBCON_ILBM=m
CONFIG_FBCON_IPLAN2P2=m
CONFIG_FBCON_IPLAN2P4=m
CONFIG_FBCON_IPLAN2P8=m
CONFIG_FBCON_MAC=m
CONFIG_FBCON_VGA_PLANES=m
CONFIG_FBCON_VGA=m
CONFIG_FBCON_HGA=m
# CONFIG_FBCON_FONTWIDTH8_ONLY is not set
CONFIG_FBCON_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
#
# Sound
#
CONFIG_SOUND=m
# CONFIG_SOUND_ALI5455 is not set
CONFIG_SOUND_BT878=m
CONFIG_SOUND_CMPCI=m
CONFIG_SOUND_CMPCI_FM=y
CONFIG_SOUND_CMPCI_FMIO=388
CONFIG_SOUND_CMPCI_FMIO=388
CONFIG_SOUND_CMPCI_MIDI=y
CONFIG_SOUND_CMPCI_MPUIO=330
CONFIG_SOUND_CMPCI_JOYSTICK=y
# CONFIG_SOUND_CMPCI_CM8738 is not set
# CONFIG_SOUND_EMU10K1 is not set
# CONFIG_MIDI_EMU10K1 is not set
# CONFIG_SOUND_FUSION is not set
# CONFIG_SOUND_CS4281 is not set
# CONFIG_SOUND_ES1370 is not set
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_ESSSOLO1 is not set
# CONFIG_SOUND_MAESTRO is not set
# CONFIG_SOUND_MAESTRO3 is not set
# CONFIG_SOUND_FORTE is not set
# CONFIG_SOUND_ICH is not set
# CONFIG_SOUND_RME96XX is not set
# CONFIG_SOUND_SONICVIBES is not set
# CONFIG_SOUND_TRIDENT is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
CONFIG_SOUND_VIA82CXXX=m
# CONFIG_MIDI_VIA82CXXX is not set
CONFIG_SOUND_OSS=m
CONFIG_SOUND_TRACEINIT=y
CONFIG_SOUND_DMAP=y
CONFIG_SOUND_AD1816=m
# CONFIG_SOUND_AD1889 is not set
CONFIG_SOUND_SGALAXY=m
CONFIG_SOUND_ADLIB=m
CONFIG_SOUND_ACI_MIXER=m
CONFIG_SOUND_CS4232=m
CONFIG_SOUND_SSCAPE=m
CONFIG_SOUND_GUS=m
# CONFIG_SOUND_GUS16 is not set
CONFIG_SOUND_GUSMAX=y
CONFIG_SOUND_VMIDI=m
CONFIG_SOUND_TRIX=m
CONFIG_SOUND_MSS=m
CONFIG_SOUND_MPU401=m
CONFIG_SOUND_NM256=m
CONFIG_SOUND_MAD16=m
CONFIG_MAD16_OLDCARD=y
CONFIG_SOUND_PAS=m
# CONFIG_PAS_JOYSTICK is not set
CONFIG_SOUND_PSS=m
CONFIG_PSS_MIXER=y
# CONFIG_PSS_HAVE_BOOT is not set
CONFIG_SOUND_SB=m
CONFIG_SOUND_AWE32_SYNTH=m
# CONFIG_SOUND_KAHLUA is not set
CONFIG_SOUND_WAVEFRONT=m
CONFIG_SOUND_MAUI=m
CONFIG_SOUND_YM3812=m
CONFIG_SOUND_OPL3SA1=m
CONFIG_SOUND_OPL3SA2=m
CONFIG_SOUND_YMFPCI=m
CONFIG_SOUND_YMFPCI_LEGACY=y
CONFIG_SOUND_UART6850=m
CONFIG_SOUND_AEDSP16=m
CONFIG_SC6600=y
CONFIG_SC6600_JOY=y
CONFIG_SC6600_CDROM=4
CONFIG_SC6600_CDROMBASE=0
CONFIG_AEDSP16_SBPRO=y
CONFIG_AEDSP16_MPU401=y
CONFIG_SOUND_TVMIXER=m
#
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_UHCI=m
CONFIG_USB_UHCI_ALT=m
CONFIG_USB_OHCI=m
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_BLUETOOTH is not set
# CONFIG_USB_MIDI is not set
# CONFIG_USB_STORAGE is not set
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
CONFIG_USB_HID=m
CONFIG_USB_HIDINPUT=y
CONFIG_USB_HIDDEV=y
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_DC2XX is not set
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set
# CONFIG_USB_IBMCAM is not set
# CONFIG_USB_KONICAWC is not set
# CONFIG_USB_OV511 is not set
# CONFIG_USB_PWC is not set
# CONFIG_USB_SE401 is not set
# CONFIG_USB_STV680 is not set
# CONFIG_USB_VICAM is not set
# CONFIG_USB_DSBR is not set
# CONFIG_USB_DABUSB is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_CATC is not set
# CONFIG_USB_CDCETHER is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_USS720 is not set
#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_TIGL is not set
# CONFIG_USB_BRLVGER is not set
# CONFIG_USB_LCD is not set
#
# Bluetooth support
#
# CONFIG_BLUEZ is not set
#
# Kernel hacking
#
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_HIGHMEM is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_IOVIRT is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_FRAME_POINTER is not set
#
# Library routines
#
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
On Thu, 08 May 2003, Marcelo Tosatti wrote:
> Here goes release canditate 2. The aic7xxx problems should be fixed.
It's late, but here goes the changelog summary with changes since
2.4.21-rc1 (the usual bk set -d -rv2.4.21-rc1, listing the first lines
of the changesets that make up 2.4.21-rc2 but aren't in 2.4.21-rc1, IOW,
the rc1 -> rc2 changes, grouped by author and sorted by surname:
<lucy:innosys.com>:
o USB: keyspan driver fixes
Muli Ben-Yehuda:
o [NETFILTER]: ip_queue memory leaks
Neil Brown:
o Update umem driver for newer cards
o Return correct result for ACCESS(READ) on eXecute-only
Ben Collins:
o Fix highmem_io for sbp2
o More firewire/IEEE1394 fixes
o Fix IEEE1394 locking problems + cleanups
Alan Cox:
o update hptraid
o fix x.25 parsing
o xdr warning (0 - any)
o fix wrong type
o maintainer updates
o fix base handling in lib stuff
o kill unneeded ifdefs, add rd/ and root=nbd
o headers for sisfb update
o put the ide idents back in working order
o fix wrong types in if_shaper
o sisfb ipdate
o new sis fb idents
o header for arcnet fixes
o remove dead functions
o fix the d_path error cases in umsdos
o more /proc error cases
o fix error cases in procfs
o copy kernel not user object in ncpfs
o handle error case in fs/namespace.c
o fix lots of tdfxfb bugs
o make sstfb work bigendian
o Fix copy_to_user handling in vicam
o make pegasus work on big endian
o mdc800 copy_to_user handling fix
o fix a race and a comment in via_audio
o mpu401 copy_to_user handling fix
o small fix for pcm alloc on i810
o Fix get_user handling in cmpci
o Fix copy_to_user handling in awe_wave
o fix build with newer binutils
o add another card id
o fix qlogicisp leaks
o fix nsp32 build with newer binutils
o fix ide-scsi retry oops
o fix cpqfc leak
o fix time type in aha152x
o fix 82092 crash cases
o Fix copy_user handling in cosa
o sis900 needs to know another PHY
o fix roadrunner memory leak
o fix compile of r8169 with newer binutils
o Fix arcnet crashes with raw socket
o Fix copy_user handling in z36120
o /proc stuff for zoran
o Fix copy_to_user handling in eicon
o add blacklist for barracuda ata iv with CSB5
o IDE: if 0 garbage removal
o fix ide smp deadlock on settings sem
o fix memory leak on rio
o fix overrun in cdu31a
Oleg Drokin:
o Memleak fix for DIGITAL EtherWORKS 3 ethernet driver
Jeff Garzik:
o fix fealnx build on ia64 and other non-x86
o tg3 fix
Christoph Hellwig:
o add intelfb to Config.in
Stephen Hemminger:
o [BRIDGE]: New maintainership
Benjamin Herrenschmidt:
o Fix PPC build
Marcel Holtmann:
o [Bluetooth] Fix L2CAP binding to local address
o [Bluetooth] Respond correctly to RLS packets
Bernhard Kaindl:
o Fixup 2.4 ptrace fix
Andi Kleen:
o Another x86-64 build fix for gcc-3.3-hammer
o Fix SMP x86-64 kernels on simics
o Fix gcc 3.3 build for reverted aic7xxx driver
o Critical fix for x86-64
Dave Kleikamp:
o JFS: Avoid rare deadlock
o JFS: jfs_lookup should check for bad inode returned from iget
o JFS: Performance improvement
Maksim Krasnyanskiy:
o [Bluetooth] Fix race condition in RFCOMM session and dlc scheduler
o [Bluetooth] Improved RFCOMM TTY buffer management. Don't buffer
more data than we have credits for.
Greg Kroah-Hartman:
o IBM PCI Hotplug: fix up a number of memory leaks on the error path
o IBM PCI Hotplug: fix up a lot of memory allocations and leaks just
to figure out a slot name
o i2c: bug fix for 2.4.21-rc1
Paul Mackerras:
o Fix drivers/video/Config.in
o update CREDITS
o PPC32: Compile fix for ppc_ksyms.c - it needs the declaration of
__div64_32
o PPC32: Update the defconfigs
Torben Mathiasen:
o PCI Hotplug: cpqphp 66/100/133MHz PCI-X support
Patrick McHardy:
o [NETFILTER]: Multiple ipt_REJECT fixes
Adam Mercer:
o Fix vesafb with large memory
David S. Miller:
o [NET]: Fix hashing exploits in ipv4 routing, IP conntrack, and TCP
synq
o [NET]: SG without checksum support is illegal
James Morris:
o [IPV4]: Choose new rt_hash_rnd every rt_run_flush
o [NET]: Cosmetic cleanups of jhash code
Paulo Ornati:
o explicit support for nVidia nForce
Ernie Petrides:
o Orphan recovery error path fix
Stelian Pop:
o sonypi fixes
Tom Rini:
o PPC32: Export a missing symbol (__div64_32)
Nivedita Singhvi:
o [AF_UNIX]: Fix max_dgram_qlen procfs permissions
Alan Stern:
o USB: usb-storage fixes
o USB: usb storage async unlink error code fix
Jun Sun:
o kiobuf flush dcache properly
Marcelo Tosatti:
o Changed EXTRAVERSION to -rc2 TAG: v2.4.21-rc2
o aic7xxx PCI posting flush fix from Arjan
o aic7xxx: Go back to old aic7xxx (pre3) since the new one lockups
some cards on initialization. The new driver (aic79xx) is now a new
directory. I know Justin will hate this, but I can't update the
aic7xxx to a fully new driver in -rc stage.
o Avoid is_dumpable() NULL pointer reference
Harald Welte:
o [NETFILTER]: Trivial but important state fix for ipt_conntrack
o [NETFILTER]: Makefile and build fixes
David Woodhouse:
o JFFS2: Fix for_each_inode()
--
Matthias Andree
On Thu, May 08, 2003 at 10:15:12PM -0300, Marcelo Tosatti wrote:
>
> Hi,
>
> Here goes release canditate 2. The aic7xxx problems should be fixed.
Hi Marcello
Here is a patch I sent to lkml a few days ago. It tries to fix a problem
with 2.4.21-rc1 ide driver Makefile.
drivers/ide/Makefile is broken on 2.4.21-rc2 (it's broken at least since
2.4.421-pre6. 2.4.20 is OK).
I try to build a kernel with Old hard disk (MFM/RLL/IDE) support only
(I don't need the Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support).
Here is my .config:
#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y
#
# IDE, ATA and ATAPI Block devices
#
# CONFIG_BLK_DEV_IDE is not set
CONFIG_BLK_DEV_HD_ONLY=y
CONFIG_BLK_DEV_HD=y
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_PDC202XX=y
CONFIG_BLK_DEV_IDE_MODES=y
# CONFIG_BLK_DEV_ATARAID is not set
# CONFIG_BLK_DEV_ATARAID_PDC is not set
# CONFIG_BLK_DEV_ATARAID_HPT is not set
# CONFIG_BLK_DEV_ATARAID_SII is not set
The resulting kernel has no support for ide hard disks:
# ls -l drivers/ide/*.o
-rw-r--r-- 1 root root 8 apr 23 08:56 drivers/ide/idedriver.o
#
The following patch fixes the problem for the x86 arch (sorry, I have no
access to other archs).
*** linux-2.4.21-rc1/drivers/ide/Makefile.orig Wed Apr 23 08:45:48 2003
--- linux-2.4.21-rc1/drivers/ide/Makefile Wed Apr 23 09:20:14 2003
***************
*** 21,26 ****
--- 21,28 ----
subdir-$(CONFIG_BLK_DEV_IDE) += legacy ppc arm raid pci
+ subdir-$(CONFIG_BLK_DEV_HD_ONLY) += legacy
+
# First come modules that register themselves with the core
ifeq ($(CONFIG_BLK_DEV_IDE),y)
***************
*** 50,55 ****
--- 52,60 ----
obj-y += arm/idedriver-arm.o
endif
+ ifeq ($(CONFIG_BLK_DEV_HD_ONLY),y)
+ obj-y += legacy/idedriver-legacy.o
+ endif
ifeq ($(CONFIG_BLK_DEV_IDE),y)
# RAID must be last of all
I used a x86 computer running a debian woody (gcc 2.95.4, glibc 2.2.5)
to build the kernel.
Regards
--
Jerome Chantelauze
Sven Krohlas <[email protected]> wrote:
> > Here goes release canditate 2. The aic7xxx problems should be fixed.
>
> I've still got the same stability problems as with rc1.
> I booted rc2 and it was working fine for two or three hours.
> Then I thought "Hey, while I go to work I could rip and
> encode a CD". Well, so did I, and just as it started to rip
> the 2nd track (and to encode the first one with oggenc) the
> system froze. Sound stopped playing, the mouse froze, nothing
> worked.
You didn't see a kernel panic as well? I'm asking, because I have the same
problems with one of my machines...
When was this problem introduced? Does 2.4.19, or 2.4.20 work well?
> As before I found nothing in the logs.
Me too. The system freezes completly. I believed it's a problem with the
temperature at our server housing location, but it seems it is not (mounted
additional fans during the night and now the system is dead again).
[ ... ]
> My system is a AMD K6-2+, Asus P5A, SB AWE 64 ISA PnP (I used
> Alsa 0.9.2, but in rc1 I also had problems without it),
> nVidia TNT, two cheap network cards and a few disks.
My one is a Dual-P III 1GHz... I have no USB, Sound or that stuff enabled...
It's also a SCSI-only system if this does matter...
Best regards,
Oliver
On Thursday 22 May 2003 17:19, Oliver Pitzeier wrote:
http://people.freebsd.org/~gibbs/linux/SRC/
nothing more to say.
> Sven Krohlas <[email protected]> wrote:
> > > Here goes release canditate 2. The aic7xxx problems should be fixed.
> >
> > I've still got the same stability problems as with rc1.
> > I booted rc2 and it was working fine for two or three hours.
> > Then I thought "Hey, while I go to work I could rip and
> > encode a CD". Well, so did I, and just as it started to rip
> > the 2nd track (and to encode the first one with oggenc) the
> > system froze. Sound stopped playing, the mouse froze, nothing
> > worked.
>
> You didn't see a kernel panic as well? I'm asking, because I have the same
> problems with one of my machines...
>
> When was this problem introduced? Does 2.4.19, or 2.4.20 work well?
>
> > As before I found nothing in the logs.
>
> Me too. The system freezes completly. I believed it's a problem with the
> temperature at our server housing location, but it seems it is not (mounted
> additional fans during the night and now the system is dead again).
>
> [ ... ]
>
> > My system is a AMD K6-2+, Asus P5A, SB AWE 64 ISA PnP (I used
> > Alsa 0.9.2, but in rc1 I also had problems without it),
> > nVidia TNT, two cheap network cards and a few disks.
>
> My one is a Dual-P III 1GHz... I have no USB, Sound or that stuff
> enabled... It's also a SCSI-only system if this does matter...
>
> Best regards,
> Oliver
>
> -
> 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/
--
Kind regards
Marc-Christian Petersen
http://sourceforge.net/projects/wolk
PGP/GnuPG Key: 1024D/569DE2E3DB441A16
Fingerprint: 3469 0CF8 CA7E 0042 7824 080A 569D E2E3 DB44 1A16
Key available at http://www.keyserver.net. Encrypted e-mail preferred.
Marc-Christian Petersen on Thu 22/05 17:31 +0200:
> http://people.freebsd.org/~gibbs/linux/SRC/
Why isn't this in mainline again? It seems everyone and
their grandmother needs it for their machine not to fall
apart. I know I do, my machine won't even run for more than
a few dozen seconds without it. Busy NFS server with it
(I'm using a 7892 HBA)
Hi,
> You didn't see a kernel panic as well? I'm asking, because I have the same
> problems with one of my machines...
No panic, nothing in the logs.
> When was this problem introduced? Does 2.4.19, or 2.4.20 work well?
2.4.19 & .20 worked "fine", well, at least without DMA mode. But they
are stable.
> It's also a SCSI-only system if this does matter...
Well, my system got a SCSI card, too, but no hardware at all is connected
to it:
SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 26)
Have a nice day.
--
BOFH excuse of the day:
The salesman drove over the CPU board.
Hi,
> http://people.freebsd.org/~gibbs/linux/SRC/
> nothing more to say.
One Question:
Is this patch only for problems with the aic79xx driver?
I don't have such a device and it seems I've got similar Problems, too.
My SCSI controller is a LSI Logic / Symbios Logic 53c875 (rev 26).
Have a nice day.
--
BOFH excuse of the day:
The salesman drove over the CPU board.
Scott McDermott wrote:
> Marc-Christian Petersen on Thu 22/05 17:31 +0200:
> > http://people.freebsd.org/~gibbs/linux/SRC/
>
> Why isn't this in mainline again? It seems everyone and
> their grandmother needs it for their machine not to fall
> apart. I know I do, my machine won't even run for more than
> a few dozen seconds without it. Busy NFS server with it
> (I'm using a 7892 HBA)
Thanks for this information. Now it would be great to get a statement from
Marcelo, wouldn't it?
Why did you release the -rc3 without this? I believe there are more people like
me, that have such problems and do not even know about it.
Best regards,
Oliver
[ ... ]
> > You didn't see a kernel panic as well? I'm asking, because
> I have the
> > same problems with one of my machines...
>
> No panic, nothing in the logs.
Same for me...
> > When was this problem introduced? Does 2.4.19, or 2.4.20 work well?
>
> 2.4.19 & .20 worked "fine", well, at least without DMA mode.
> But they are stable.
I installed 2.4.19 (because I know it's stable - at least for me) yesterday on
my machine and no it runs stable again (it seems, because it's now up for more
than 15 hours). With 2.4.21-rc[1,2], I never had such a long uptime. :-)
[ ... ]
OK. So now I have to say: _Don't_ use 2.4.20-rc* if you have a aic7xxx. You can
use 2.4.19 and maybe 2.4.20(?).
Best regards,
Oliver
Hi,
> OK. So now I have to say: _Don't_ use 2.4.20-rc* if you have a aic7xxx. You can
> use 2.4.19 and maybe 2.4.20(?).
Just to clearify: _I don't_ have a aic7xxx!
-------------------
linux:/home/sven # hwinfo --short
cpu:
AMD-K6(tm)-III Processor, 500 MHz
keyboard:
PS/2 Keyboard
mouse:
/dev/input/mice Logitech iFeel Mouse
printer:
/dev/lp0 Hewlett-Packard HP LaserJet 5L
monitor:
PHILIPS 109S
graphics card:
Diamond Viper V550
framebuffer:
NVidia Riva TNT
sound:
Creative Sound Blaster AWE 64
storage:
Floppy disk controller
LSI Logic / Symbios Logic 53c875
Promise 20269
Acer Laboratories Inc. [ALi] M5229 IDE
IDE interface
network:
Realtek RT8139
Realtek RTL-8029(AS)
network interface:
lo Loopback network interface
eth0 Ethernet network interface
eth1 Ethernet network interface
ppp0 Network Interface
sit0 Network Interface
disk:
/dev/hda IC35L120AVV207-0
/dev/hdc IC35L120AVV207-0
/dev/hde Maxtor 4G120J6
/dev/hdf IBM-DJNA-352030
/dev/hdg IC35L120AVV207-0
/dev/hdb IC35L120AVV207-0
cdrom:
/dev/sr0 IDE-CD R/RW 8x4x32
/dev/hdh R/RW 8x4x32
floppy:
/dev/fd0 Floppy Disk
usb controller:
Acer Laboratories Inc. [ALi] USB 1.1 Controller
bios:
BIOS
bridge:
Acer Laboratories Inc. [ALi] ALI M1541 Aladdin V/V+ AGP System Controller
Acer Laboratories Inc. [ALi] M1541 PCI to AGP Controller
Acer Laboratories Inc. [ALi] ALI M7101 Power Management Controller
Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV]
hub:
USB OHCI Root Hub
USB OHCI Root Hub
Hub
USB OHCI Root Hub
USB OHCI Root Hub
USB OHCI Root Hub
USB OHCI Root Hub
memory:
Main Memory
unknown:
FPU
DMA controller
PIC
Timer
RTC
Keyboard controller
/dev/lp0 Parallel controller
PS/2 Controller
ISA PnP Interface
Creative Sound Blaster AWE 64
Creative Sound Blaster AWE 64
/dev/ttyS0 16550A
/dev/ttyS1 16550A
-------------------
Sunday evening I'll try rc3, I'm looking forward to a freezing
system again :-(
Have a nice day.
--
BOFH excuse of the day:
The salesman drove over the CPU board.
> > OK. So now I have to say: _Don't_ use 2.4.20-rc* if you have a
> > aic7xxx. You can use 2.4.19 and maybe 2.4.20(?).
>
> Just to clearify: _I don't_ have a aic7xxx!
[ ... ]
Allright, got it. :-)
> Sunday evening I'll try rc3,
I'm not going to try it... I better wait on 2.4.21 stable release. :-)
> I'm looking forward to a freezing system again :-(
Have fun. :-)
Best regards,
Oliver
On Fri, 23 May 2003 11:32:34 +0200
"Oliver Pitzeier" <[email protected]> wrote:
> > > OK. So now I have to say: _Don't_ use 2.4.20-rc* if you have a
> > > aic7xxx. You can use 2.4.19 and maybe 2.4.20(?).
> >
> > Just to clearify: _I don't_ have a aic7xxx!
> [ ... ]
>
> Allright, got it. :-)
>
> > Sunday evening I'll try rc3,
>
> I'm not going to try it... I better wait on 2.4.21 stable release. :-)
>
> > I'm looking forward to a freezing system again :-(
>
> Have fun. :-)
Ok guys. I have quite the same problem, and I tested justins aic on top of
2.4.21-rc2. You can expect it to perform better. Without justins aic my box
froze every day, with it I just managed to freeze it first time after 14 days.
It looks better, but not solved. I am now out and trying rc3 with justins
driver (20030520).
Regards,
Stephan
On Fri, 2003-05-23 at 04:48, Oliver Pitzeier wrote:
> [ ... ]
>
> OK. So now I have to say: _Don't_ use 2.4.20-rc* if you have a aic7xxx. You can
> use 2.4.19 and maybe 2.4.20(?).
2.4.20 is fine for me here... (Its 2.4.20 with the AA highmem-as-lowmem
patch and 1G of ram):
$ head -n 2 /proc/scsi/aic7xxx/[01];uname -a;uptime
==> /proc/scsi/aic7xxx/0 <==
Adaptec AIC7xxx driver version: 6.2.8
aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
==> /proc/scsi/aic7xxx/1 <==
Adaptec AIC7xxx driver version: 6.2.8
aic7880: Ultra Wide Channel B, SCSI Id=7, 16/253 SCBs
Linux oscar 2.4.20 #1 Sun Mar 2 13:09:09 EST 2003 i686 unknown unknown
GNU/Linux
11:20:24 up 53 days, 19:33, 30 users, load average: 0.14, 0.19, 0.20
--
Disconnect <[email protected]>
On Fri, 23 May 2003, Oliver Pitzeier wrote:
> Scott McDermott wrote:
> > Marc-Christian Petersen on Thu 22/05 17:31 +0200:
> > > http://people.freebsd.org/~gibbs/linux/SRC/
> >
> > Why isn't this in mainline again? It seems everyone and
> > their grandmother needs it for their machine not to fall
> > apart. I know I do, my machine won't even run for more than
> > a few dozen seconds without it. Busy NFS server with it
> > (I'm using a 7892 HBA)
>
> Thanks for this information. Now it would be great to get a statement from
> Marcelo, wouldn't it?
> Why did you release the -rc3 without this? I believe there are more people like
> me, that have such problems and do not even know about it.
>
Because it was too late for it to be included. It is a NEW driver and
there is no WAY I will include it except early -pre's.
On Fri, May 23, 2003 at 02:52:44PM -0300, Marcelo Tosatti wrote:
> > Thanks for this information. Now it would be great to get a statement from
> > Marcelo, wouldn't it?
> > Why did you release the -rc3 without this? I believe there are more people like
> > me, that have such problems and do not even know about it.
>
> Because it was too late for it to be included. It is a NEW driver and
> there is no WAY I will include it except early -pre's.
Marcelo,
although I respect your maintainer's responsible and safe position, I'd like
to state that version 6.2.28 has been in the latest pre-releases for quite some
time, and the reason you invoked for removing it at -rc time was the lockups
people still encounter with the version present in -rc3, perhaps to a lesser
extent. These lockups *SEEM* to have vanished from 6.2.33 for people who
complained previously. Moreover, the lockup I encountered on my systems was
fixed and demonstrated by Justin to really be a locking bug, so this was not
just a "let's see how it behaves" fix.
I think that if at least you had given it a try in -rc3 as a last chance, it
would have been a good opportunity for these people to hope for a stable kernel
on their production machines, and for Justin to have more bug reports if
problems still arose.
By this time, there will be more and more people leaving vanilla kernel for
their machines, and using them only as a base to apply -aa, -ac, -jam, -wolk,
-** + sf.net/* + who_knows_what, and I find it a shame.
I'm convinced that it's now a bit late and risky for a last minute change, but
I hope that 2.4.22 will be a really short release with only bug fixes, and all
the few important build fixes which were posted several times here. This way,
we'll be able to tell people "Don't jump on 2.4.21 yet, 2.4.22 is coming next
and will be a good one".
Just an opinion, not a flame. Have a nice week-end anyway.
Willy
Oliver Pitzeier on Fri 23/05 10:45 +0200:
> > Why isn't this in mainline again? It seems everyone and
> > their grandmother needs it for their machine not to fall
> > apart.
>
> Thanks for this information. Now it would be great to get
> a statement from Marcelo, wouldn't it? Why did you
> release the -rc3 without this? I believe there are more
> people like me, that have such problems and do not even
> know about it.
To be fair, I think it used to be in either a late -pre or
an early -rc but was withdrawn my Marcelo when it broke some
people. But, I think it had been said that those bugs are
fixed now.
We'll just hope for 2.4.22-pre
although I respect your maintainer's responsible and safe position, I'd like
to state that version 6.2.28 has been in the latest pre-releases for quite some
time, and the reason you invoked for removing it at -rc time was the lockups
people still encounter with the version present in -rc3, perhaps to a lesser
extent. These lockups *SEEM* to have vanished from 6.2.33 for people who
complained previously. Moreover, the lockup I encountered on my systems was
fixed and demonstrated by Justin to really be a locking bug, so this was not
just a "let's see how it behaves" fix.
I think there's some misunderstanding about what a release candidate
is. It's an attempt to see if a particular set of code is viable as the
released product. Any bugs reported against a rc that are deemed
problems to the release need to be fixed, either by adding a simple and
easily verifiable bug fix or by reverting the problem code.
The bksend file on http://people.freebsd.org/~gibbs/linux/SRC/
representing the requested updates is 475k compressed. There's no
definition of the phrase "simple and easily verifiable bug fix" I can
encompass that could be applied to a chunk of code that size.
In these circumstances, absent a simple fix for the problem, the only
choice seems to be reversion and trying to get the code base stable at
the beginning of the next -pre, which is the current decision.
James
On 05.23, Sven Krohlas wrote:
> Hi,
>
> > OK. So now I have to say: _Don't_ use 2.4.20-rc* if you have a aic7xxx. You can
> > use 2.4.19 and maybe 2.4.20(?).
>
> Just to clearify: _I don't_ have a aic7xxx!
>
And just to mess it more, I _do have_ an aic7xxx, and aic-20030520 works fine
for me.
00:0e.0 SCSI storage controller: Adaptec AHA-2940U2/U2W / 7890/7891 (rev 01)
Subsystem: Adaptec 2940U2W SCSI Controller
Flags: bus master, medium devsel, latency 64, IRQ 10
BIST result: 00
I/O ports at e800 [disabled] [size=256]
Memory at febff000 (64-bit, non-prefetchable) [size=4K]
Expansion ROM at febc0000 [disabled] [size=128K]
Capabilities: <available only to root>
Using http://giga.cps.unizar.es/~magallon/linux/kernel/2.4.21-rc3-jam1.tar.gz
(and previous).
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.21-rc3-jam1 (gcc 3.2.3 (Mandrake Linux 9.2 3.2.3-1mdk))
On Fri, May 23, 2003 at 07:29:53PM -0400, James Bottomley wrote:
> I think there's some misunderstanding about what a release candidate
> is. It's an attempt to see if a particular set of code is viable as the
> released product. Any bugs reported against a rc that are deemed
> problems to the release need to be fixed, either by adding a simple and
> easily verifiable bug fix or by reverting the problem code.
That's also my point. People were reporting problems till -rc1 which included
driver version 6.2.28. So Marcelo reverted to 6.2.8 for -rc2 (74500 lines of
code reverted, not including doc nor aic79xx which was kept). Then, people were
still reporting problems with -rc2 which they claim are fixed by updating
to last driver updates, which were 16000 lines forward from -rc1, so less than
one fourth of what Marcelo accepted to change from -rc1 to -rc2. Although I
find this big, it's less than the change in fusion/mpt* that has gone from
-rc2 to -rc3. So I think it's not a matter of size here.
> The bksend file on http://people.freebsd.org/~gibbs/linux/SRC/
> representing the requested updates is 475k compressed. There's no
> definition of the phrase "simple and easily verifiable bug fix" I can
> encompass that could be applied to a chunk of code that size.
Most of this is a 1 MB Changelog, files going back to their original place
(Marcelo moved aic79xx to a proper directory to keep it), documentation, and
initialization code which was exploded in more little functions, then bug fixes.
I wish Justin would have proposed a little patch to fix only the locking bugs
in -rc1, but honnestly, why should he fix only these bugs when he knows about
others that must be fixed too ? I can understand he gives up. -rc is for bug
fixes, and his bug fixes are reverted !
As I said, I really hope that we'll have a quick 2.4.22 with bug fixes taken
as a priority. The current pre-releases are as frequent and as big as what
used to be full releases in the past.
Regards,
Willy
On Fri, 23 May 2003 22:30:17 +0200, Willy Tarreau wrote in lkml:
> By this time, there will be more and more people leaving vanilla kernel for
> their machines, and using them only as a base to apply -aa, -ac, -jam, -wolk,
> -** + sf.net/* + who_knows_what, and I find it a shame.
I think you overestimate the number of aic7xxx users. It's not like
99% of all 2.4 users need the driver.
--
Ciao,
Pascal
On Sat, 2003-05-24 at 02:43, Willy Tarreau wrote:
> > I think there's some misunderstanding about what a release candidate
> > is. It's an attempt to see if a particular set of code is viable as the
> > released product. Any bugs reported against a rc that are deemed
> > problems to the release need to be fixed, either by adding a simple and
> > easily verifiable bug fix or by reverting the problem code.
>
> That's also my point. People were reporting problems till -rc1 which included
> driver version 6.2.28. So Marcelo reverted to 6.2.8 for -rc2 (74500 lines of
> code reverted, not including doc nor aic79xx which was kept). Then, people were
> still reporting problems with -rc2 which they claim are fixed by updating
> to last driver updates, which were 16000 lines forward from -rc1, so less than
> one fourth of what Marcelo accepted to change from -rc1 to -rc2. Although I
> find this big, it's less than the change in fusion/mpt* that has gone from
> -rc2 to -rc3. So I think it's not a matter of size here.
It is a question of size and provenance. Alan Cox descriped the mpt
fusion update as "assorted small fixes" and deletions exceed additions
in the patch set by 40%. It's also about user base: aic7xxx is by far
the most widely used SCSI chip, I'm not sure how many 2.4 fusion users
there are but I speculate its probably orders of magnitude fewer.
> Most of this is a 1 MB Changelog, files going back to their original place
> (Marcelo moved aic79xx to a proper directory to keep it), documentation, and
> initialization code which was exploded in more little functions, then bug fixes.
The argument isn't about size, it's about safety. No company that wants
to stay in business accepts code into release stabilisation unless it's
clearly justifiable. Trying to buck the system by including five
features plus one critical bug fix is one of the oldest tricks in the
Software Engineers book---do this and you get hauled before the release
committee whose job will be to pare the addition back to just the bug
fix (and send you away with a flea in your ear to boot).
> I wish Justin would have proposed a little patch to fix only the locking bugs
> in -rc1, but honnestly, why should he fix only these bugs when he knows about
> others that must be fixed too ? I can understand he gives up. -rc is for bug
> fixes, and his bug fixes are reverted !
Marcelo reacted exactly as the release committee would at Adaptec:
either provide the bug fix for assessment or we'll push it out into the
next release. This is industry standard practice, so I don't see any
problem.
> As I said, I really hope that we'll have a quick 2.4.22 with bug fixes taken
> as a priority. The current pre-releases are as frequent and as big as what
> used to be full releases in the past.
I agree. One of the necessary things for a fast release is a good
release manager (and thus one prepared to make unpopular decisions--and
ones you don't necessarily agree with).
James
>> I wish Justin would have proposed a little patch to fix only the locking bugs
>> in -rc1, but honnestly, why should he fix only these bugs when he knows about
>> others that must be fixed too ? I can understand he gives up. -rc is for bug
>> fixes, and his bug fixes are reverted !
>
> Marcelo reacted exactly as the release committee would at Adaptec:
> either provide the bug fix for assessment or we'll push it out into the
> next release. This is industry standard practice, so I don't see any
> problem.
Just for clarification. Marcelo never asked me for a fix. The only
mail I received from him was an informational message indicating that
the code was being backed out. If I had been provided an opportunity
to fix the problem, I would have. Considering that the fix has been
available long before RC2 was cut (May 1st.), it's not hard to see that
getting a proper fix required nothing more than just upgrading the driver
or contacting its maintainer to get a paired down fix.
--
Justin
On Sat, 2003-05-24 at 10:51, Justin T. Gibbs wrote:
> Just for clarification. Marcelo never asked me for a fix. The only
> mail I received from him was an informational message indicating that
> the code was being backed out. If I had been provided an opportunity
> to fix the problem, I would have. Considering that the fix has been
> available long before RC2 was cut (May 1st.), it's not hard to see that
> getting a proper fix required nothing more than just upgrading the driver
> or contacting its maintainer to get a paired down fix.
The kernel, as you have been told several times before, follows a push
model, not a pull one. Just looking after SCSI, I don't have time to go
around asking all the driver writers for updates; likewise Marcelo
really doesn't have the time to do this for everything in the 2.4
kernel.
Every maintained piece of the kernel has a listed maintainer to whom the
bug reports are supposed to go. The expectation is that these
maintainers will see the bug reports and pro-actively provide fixes
before they become release issues. The maintainers also do
enhancements, *but* these enhancements should follow the proper release
cycle (i.e. in at the early -pre stage).
Could you please get with the program? The bug fix vs enhancement issue
hasn't previously mattered that much for 2.5, but I anticipate we'll be
following a similar model when 2.6 is released.
James
Pascal Schmidt wrote:
> On Fri, 23 May 2003 22:30:17 +0200, Willy Tarreau wrote in lkml:
>
>
>>By this time, there will be more and more people leaving vanilla kernel for
>>their machines, and using them only as a base to apply -aa, -ac, -jam, -wolk,
>>-** + sf.net/* + who_knows_what, and I find it a shame.
>
>
> I think you overestimate the number of aic7xxx users. It's not like
> 99% of all 2.4 users need the driver.
>
I think you're smoking crack, I'd say that there are way more than 1% of
the 2.4 users w/ an AIC-7XXX chipset based controller. I don't know how
things are like in Germany, but around here, Adaptec is usually thought
to be the mainstream choice in SCSI solutions for professional
workstations and low-to-mid range servers [I Am Not A Product Market
Analyst, so this is just my personal opinion based on my experiences in
the VAR/Retail sector... YMMV]. Most of the popular OEM's offer some
sort of SCSI option based on an AIC-7XXX series chipset for most of
their non "home-use-only" lines. I can't even count how many
motherboard manufactures have embedded the AIC-7XXX series chip into
their motherboard to provide integrated SCSI solutions. Moreover, most
of what Adaptec produces in their current core SCSI brand line
(excepting DPT, etc) is based on some version of the AIC-7XXX chip. I
can damn well say for sure there are more AIC-7XXX users then there are
Fusion users and, as was pointed out, that code has gone through much
more invasive changes to bring it up to speed.
I think the bottom line is that those of us in Adaptec-userland would
very much appreciate a *working*, current driver in the next kernel
release. AFAICT, the old code base that was reverted to still has some
annoying "quirks", and frankly doesn't perform as well as the current
driver [at least for me]. So, invasive or not, I think we ought to be
"testing the code" of a driver release written by a person who is well
qualified to know the ins and outs of the hardware he is writing the
code for. Obviously Justin has access to a multitude of Adaptec
hardware and I am quite satisfied that he has sufficiently tested his
modifications to the driver. Waiting until 2.4.22, let alone 2.4.21, is
actually released just seems too far down the road to be sane.
Just my $0.02 on this...
Cheers,
Nicholas
On Fri, 2003-05-23 at 23:43, Willy Tarreau wrote:
> As I said, I really hope that we'll have a quick 2.4.22 with bug fixes taken
> as a priority. The current pre-releases are as frequent and as big as what
> used to be full releases in the past.
--
David S. Miller <[email protected]>
On Fri, 2003-05-23 at 23:43, Willy Tarreau wrote:
> As I said, I really hope that we'll have a quick 2.4.22 with bug fixes taken
> as a priority. The current pre-releases are as frequent and as big as what
> used to be full releases in the past.
I really think 2.4.x development is becoming almost non-existent
lately.
It's 5 or 6 days of silence, nothing happening at all, then a flurry
of 10 or 20 checkins and a -rc or -pre release.
If Conectiva needs to task Marcelo to so much work that he can only
really put 1 or 2 days a week into 2.4.x, this needs be rethought at
either one end (Conectiva finding a way to give him more 2.4.x time) or
another (Marcelo splits up the work with someone else or we simply find
another 2.4.x maintainer).
I really want something more -ac paced although that may be too extreme
for some people. :-)
--
David S. Miller <[email protected]>
On Monday 26 May 2003 06:25, David S. Miller wrote:
Hi David,
> I really think 2.4.x development is becoming almost non-existent
> lately.
_full_ ack!
> If Conectiva needs to task Marcelo to so much work that he can only
> really put 1 or 2 days a week into 2.4.x, this needs be rethought at
> either one end (Conectiva finding a way to give him more 2.4.x time) or
> another (Marcelo splits up the work with someone else or we simply find
> another 2.4.x maintainer).
Just in case if there will ever be a new election ...
... */ME stretches his hands up*
ciao, Marc
On Fri, 23 May 2003, Sven Krohlas wrote:
> Hi,
>
> > http://people.freebsd.org/~gibbs/linux/SRC/
> > nothing more to say.
>
> One Question:
> Is this patch only for problems with the aic79xx driver?
> I don't have such a device and it seems I've got similar Problems, too.
> My SCSI controller is a LSI Logic / Symbios Logic 53c875 (rev 26).
That chips needs a different driver (and has in fact three drivers to
choose from, the old ncr53c8xx, the old sym53c8xx, the new sym53c8xx_2).
It has nothing to do with aic7xxx.
On Mon, 25 May 2003, David S. Miller wrote:
> On Fri, 2003-05-23 at 23:43, Willy Tarreau wrote:
> > As I said, I really hope that we'll have a quick 2.4.22 with bug fixes taken
> > as a priority. The current pre-releases are as frequent and as big as what
> > used to be full releases in the past.
>
> I really think 2.4.x development is becoming almost non-existent
> lately.
>
> It's 5 or 6 days of silence, nothing happening at all, then a flurry
> of 10 or 20 checkins and a -rc or -pre release.
>
> If Conectiva needs to task Marcelo to so much work that he can only
> really put 1 or 2 days a week into 2.4.x, this needs be rethought at
> either one end (Conectiva finding a way to give him more 2.4.x time) or
> another (Marcelo splits up the work with someone else or we simply find
> another 2.4.x maintainer).
>
> I really want something more -ac paced although that may be too extreme
> for some people. :-)
I said publically that this situation will change in 2.4.22-pre.
If you think the situation didnt got better during that time, I'm pleased
to giveup 2.4.x maintenance.
Is that fine for you?
On Mon, 25 May 2003, David S. Miller wrote:
> On Fri, 2003-05-23 at 23:43, Willy Tarreau wrote:
> > As I said, I really hope that we'll have a quick 2.4.22 with bug fixes taken
> > as a priority. The current pre-releases are as frequent and as big as what
> > used to be full releases in the past.
>
> I really think 2.4.x development is becoming almost non-existent
> lately.
>
> It's 5 or 6 days of silence, nothing happening at all, then a flurry
> of 10 or 20 checkins and a -rc or -pre release.
>
> If Conectiva needs to task Marcelo to so much work that he can only
> really put 1 or 2 days a week into 2.4.x, this needs be rethought at
> either one end (Conectiva finding a way to give him more 2.4.x time) or
> another (Marcelo splits up the work with someone else or we simply find
> another 2.4.x maintainer).
Splitting up the work with someone is senseless, IMO. As I said before,
2.4.22-pre should be better in that aspect. In case it doesnt, I'm giving
up 2.4.x maintenance.
On Fri, 23 May 2003, Scott McDermott wrote:
> Oliver Pitzeier on Fri 23/05 10:45 +0200:
> > > Why isn't this in mainline again? It seems everyone and
> > > their grandmother needs it for their machine not to fall
> > > apart.
> >
> > Thanks for this information. Now it would be great to get
> > a statement from Marcelo, wouldn't it? Why did you
> > release the -rc3 without this? I believe there are more
> > people like me, that have such problems and do not even
> > know about it.
>
> To be fair, I think it used to be in either a late -pre or
> an early -rc but was withdrawn my Marcelo when it broke some
> people. But, I think it had been said that those bugs are
> fixed now.
>
> We'll just hope for 2.4.22-pre
Again, it will be included in 2.4.22-pre1.
On Mon, May 26, 2003 at 03:42:42PM -0300, Marcelo Tosatti wrote:
> Splitting up the work with someone is senseless, IMO. As I said before,
> 2.4.22-pre should be better in that aspect. In case it doesnt, I'm giving
> up 2.4.x maintenance.
Marcelo,
Reading your words, I have the sad feeling that you take no interest in doing
this job, and that you do it only because people ask you to. What a shame :-(
Although it sure can be annoying, aren't you proud of each new release ?
Usually, kernel integrators are proud of their new kernels when they get
something rock solid ! People like Con Kolivas, J.A.Magallon, Marc-Christian
Pettersen are often proud to announce us the few bits they changed in their
tree and which stabilized it. It seems you only do this as an obligation,
which is sad, really.
I understand that maintaining the stable tree, the one which MUST NOT FAIL,
may be frustrating, not being as excitant as playing with kernels which try
to get the most of every piece of hardware, as others do (although nobody
prevents you from developing your own Wolk). But you don't seem to share much
about your feelings, ideas or doubts with others. Alan, for example, exchanges
a lot with people testing his kernels, suggesting a few tweaks to help them
workaround their problems, and integrating the tweak in the next release if it
succeeds. This fast feedback allows him to release more often. It also makes
his work more intersting for others. People often prefer "here is -rcxx-acxx,
which my EPIA now fully supports" to "here is -rcxx, please test it
extensively".
Perhaps you don't feel assurance when you have to blindly integrate hundreds
of patches from people you don't always trust, and that may explain why you
suddenly announce a new pre-release and keep silent, hoping for patch authors
to reply to questions if any ? If this is the case, jump into the train,
there's no risk, except of being caught by Rik's troll-o-meter, or having Viro
or hch insult you ! And then ? What's the matter ? Every one has his turn. I
even risk it with this OT mail. When you started with 2.4.16, you said that you
were afraid you lacked some skills, but you proved to be very capable, because
the kernel has moved since, and 2.4.21 should be far more stable than 2.4.16 !
This mail is not intended to give you any lesson, but to give a feedback from
a Linux 2.4 user who, as many others, feels more and more forgotten by his
maintainer. Unfortunately, what David wrote is what many people currently think
of 2.4 :-( You threatened to give up, but that would be bad for your image
and for Linux. Giving up means no maintainer for a certain amount of time, then
a self-proclamed new maintainer (or worse, several ones with a tree fork).
Being replaced is cleaner, since you do the job until the new maintainer is
ready to start.
If you don't have enough time to do everything, send a source quench, or apply
one of David's proposed solutions : ask for some help so that only subsystems
maintainers feed you as some already do (eg: David, Jeff, Greg), or ask for a
pure replacement. If you're bored, that I could understand, because having to
deal with arrogant and sometimes even selfish users is not always pleasant,
ask for a replacement. If you're fed up with patches that you don't understand,
reject them LOUDLY asking for more documentation. And if you plan to have a
rest for two weeks, say it, so that people don't send you patches that will be
lost in a full mailbox at your return. Yes, this may be what Linus did before
you, when people already complained. But there should be a middle line between
how he managed his kernel and how you manage it, and BTW, Linus clearly stated
that maintaining 2.4 bored him.
I've just read your mail about -rc[45]. I'm happy we start to see the light at
the end of the 2.4.21 tunnel. As others people, I'm now impatient to both 2.4.21
and 2.4.22-pre1. BTW, as discussed perhaps a year or two ago, you could have a
preview of 2.4.22-pre1 in parallel with 2.4.21-rc, to feed the impatients,
although that may be double work, which you don't necessarily need at the
moment.
And remember, please communicate, communicate, communicate. You and only you
know what problem you have at a given time. If you don't communicate, people
always imagine the worst.
Regards,
Willy
On Mon, 26 May 2003, Willy Tarreau wrote:
> On Mon, May 26, 2003 at 03:42:42PM -0300, Marcelo Tosatti wrote:
>
> > Splitting up the work with someone is senseless, IMO. As I said before,
> > 2.4.22-pre should be better in that aspect. In case it doesnt, I'm giving
> > up 2.4.x maintenance.
>
> Marcelo,
>
> Reading your words, I have the sad feeling that you take no interest in doing
> this job, and that you do it only because people ask you to. What a shame :-(
>
> Although it sure can be annoying, aren't you proud of each new release ?
> Usually, kernel integrators are proud of their new kernels when they get
> something rock solid ! People like Con Kolivas, J.A.Magallon, Marc-Christian
> Pettersen are often proud to announce us the few bits they changed in their
> tree and which stabilized it. It seems you only do this as an obligation,
> which is sad, really.
What I said is that if people think I'm not maintaining 2.4.x (quoting
Davem, "I really think 2.4.x development is becoming almost non-existent
lately.) in a acceptable way, the work should be done by someone else. I
WANT to keep maintaining 2.4, but only if people are happy with that. Do
you understand ?
> I understand that maintaining the stable tree, the one which MUST NOT FAIL,
> may be frustrating, not being as excitant as playing with kernels which try
> to get the most of every piece of hardware, as others do (although nobody
> prevents you from developing your own Wolk). But you don't seem to share much
> about your feelings, ideas or doubts with others. Alan, for example, exchanges
> a lot with people testing his kernels, suggesting a few tweaks to help them
> workaround their problems, and integrating the tweak in the next release if it
> succeeds. This fast feedback allows him to release more often. It also makes
> his work more intersting for others.
> People often prefer "here is -rcxx-acxx, which my EPIA now fully
> supports" to "here is -rcxx, please test it extensively".
I dont understand what you mean.
>
> Perhaps you don't feel assurance when you have to blindly integrate hundreds
> of patches from people you don't always trust, and that may explain why you
> suddenly announce a new pre-release and keep silent, hoping for patch authors
> to reply to questions if any ? If this is the case, jump into the train,
> there's no risk, except of being caught by Rik's troll-o-meter, or having Viro
> or hch insult you ! And then ? What's the matter ? Every one has his turn. I
> even risk it with this OT mail. When you started with 2.4.16, you said that you
> were afraid you lacked some skills, but you proved to be very capable, because
> the kernel has moved since, and 2.4.21 should be far more stable than 2.4.16 !
>
> This mail is not intended to give you any lesson, but to give a feedback from
> a Linux 2.4 user who, as many others, feels more and more forgotten by his
> maintainer. Unfortunately, what David wrote is what many people currently think
> of 2.4 :-( You threatened to give up, but that would be bad for your image
> and for Linux.
>
> Giving up means no maintainer for a certain amount of time, then
> a self-proclamed new maintainer (or worse, several ones with a tree fork).
> Being replaced is cleaner, since you do the job until the new maintainer is
> ready to start.
>
> If you don't have enough time to do everything, send a source quench, or apply
> one of David's proposed solutions : ask for some help so that only subsystems
> maintainers feed you as some already do (eg: David, Jeff, Greg), or ask for a
> pure replacement. If you're bored, that I could understand, because having to
> deal with arrogant and sometimes even selfish users is not always pleasant,
> ask for a replacement. If you're fed up with patches that you don't understand,
> reject them LOUDLY asking for more documentation. And if you plan to have a
> rest for two weeks, say it, so that people don't send you patches that will be
> lost in a full mailbox at your return. Yes, this may be what Linus did before
> you, when people already complained. But there should be a middle line between
> how he managed his kernel and how you manage it, and BTW, Linus clearly stated
> that maintaining 2.4 bored him.
>
> I've just read your mail about -rc[45]. I'm happy we start to see the light at
> the end of the 2.4.21 tunnel. As others people, I'm now impatient to both 2.4.21
> and 2.4.22-pre1. BTW, as discussed perhaps a year or two ago, you could have a
> preview of 2.4.22-pre1 in parallel with 2.4.21-rc, to feed the impatients,
> although that may be double work, which you don't necessarily need at the
> moment.
>
> And remember, please communicate, communicate, communicate. You and only you
> know what problem you have at a given time. If you don't communicate, people
> always imagine the worst.
>
> Regards,
> Willy
>
> > People often prefer "here is -rcxx-acxx, which my EPIA now fully
> > supports" to "here is -rcxx, please test it extensively".
> I dont understand what you mean.
Smaller, more frequent patches, have the advantage of getting more widespread
testing of a common codebase - the problem with testing individual patchsets
separately is that it's quite possible that with only a few people testing any
particular combination, bugs appear in a large -pre or -rc patchset, and prevent
others from testing the rest of that patchset easily. A -pre every week, even
if it only had a few changes, would get more bug reports in, (in my opinion).
John.
Marcelo Tosatti wrote:
>
> Splitting up the work with someone is senseless, IMO. As I said before,
> 2.4.22-pre should be better in that aspect. In case it doesnt, I'm giving
> up 2.4.x maintenance.
Please don't give up!
This e-mail is meant as public encouragement and big THANKS for you.
Every time I hit a bug in 2.4 and sent you a patch, it was applied after
a short time (few days). So far, 2.4 has been working perfectly for me.
There are many users and developers who are happy with the 2.4 kernel
and with you as a maintainer, they just don't say it. Something that
works is often forgotten, once it breaks or doesn't work as expected,
people start crying loudly.
Thank you for maintaining a stable tree,
Carl-Daniel
Marc-Christian Petersen wrote:
> On Tuesday 27 May 2003 00:16, Carl-Daniel Hailfinger wrote:
>
>>This e-mail is meant as public encouragement and big THANKS for you.
>>Every time I hit a bug in 2.4 and sent you a patch, it was applied after
>>a short time (few days). So far, 2.4 has been working perfectly for me.
>>There are many users and developers who are happy with the 2.4 kernel
>>and with you as a maintainer, they just don't say it. Something that
>>works is often forgotten, once it breaks or doesn't work as expected,
>>people start crying loudly.
>>Thank you for maintaining a stable tree,
>
> Sorry, but are you kidding?
No. It works for me(TM). If it didn't work for you during the 2.4.21
release cycle, my apologies. Marcelo stated he wants to take the patches
you complained about for 2.4.22-pre1. That should also fix your issues.
Regards,
Carl-Daniel
On Tuesday 27 May 2003 00:16, Carl-Daniel Hailfinger wrote:
Hi Carl-Daniel,
> This e-mail is meant as public encouragement and big THANKS for you.
> Every time I hit a bug in 2.4 and sent you a patch, it was applied after
> a short time (few days). So far, 2.4 has been working perfectly for me.
> There are many users and developers who are happy with the 2.4 kernel
> and with you as a maintainer, they just don't say it. Something that
> works is often forgotten, once it breaks or doesn't work as expected,
> people start crying loudly.
> Thank you for maintaining a stable tree,
Sorry, but are you kidding?
ciao, Marc
From: Marcelo Tosatti <[email protected]>
Date: Mon, 26 May 2003 14:58:35 -0300 (BRT)
I said publically that this situation will change in 2.4.22-pre.
Great.
If you think the situation didnt got better during that time, I'm
pleased to giveup 2.4.x maintenance.
Is that fine for you?
I have no desire to take you away from your 2.4.x duties. In fact, I
as much as anyone else, want you to work as 2.4.x maintainer.
Therefore, you should not think twice about asking people such as
myself for help if you want it.
I fully expect you to resolve the situation. :-)
On Llu, 2003-05-26 at 05:25, David S. Miller wrote:
> I really want something more -ac paced although that may be too extreme
> for some people. :-)
Its up to Marcelo. If he wants to hand it on to me now 2.2 is basically
a one day a month job he can, or to someone else.
One thing I will say however - I'd have done the *same* thing as Marcelo
with aic7xxx during -rc which is to defer it. A maintainer gets a
continual stream of "completely tested utterly reliable fixes
everything" drivers, none of which prove to be so. The simple truth is
that when you give something to 10,000 users instead of 20 something
breaks. Its not that authors suck its just another testimony to the fact
computer programming is still firmly at the alchemy not the chemistry
end of its history.
If the driver works well fine, but maintainers don't have the ability to
see into the future either.
Alan
On Mon, May 26, 2003 at 06:35:51PM -0300, Marcelo Tosatti wrote:
> What I said is that if people think I'm not maintaining 2.4.x (quoting
> Davem, "I really think 2.4.x development is becoming almost non-existent
> lately.) in a acceptable way, the work should be done by someone else. I
> WANT to keep maintaining 2.4, but only if people are happy with that. Do
> you understand ?
Yes, I understand. I think it's good that people have complained because now
you know what they expect from you, so it's up to you to make them happy :)
> > People often prefer "here is -rcxx-acxx, which my EPIA now fully
> > supports" to "here is -rcxx, please test it extensively".
>
> I dont understand what you mean.
John correctly replied for me. Several -pre didn't even compile for most of us,
but you let them as they were during weeks. When this happens, only a few people
who have the time to follow LKML and grab patches can try these pre-releases.
When that happens, please do apply the trivial fixes and send one more just
after, even the same day so that people can try them. Alan often does this, and
nobody has ever complained about him for releasing 2 kernels the same day, one
with a big bug and the next one without.
I already had collegues saying to me "Yesterday, I've tried to compile
2.4.21-preXX, but it doesn't compile". It's always sad to say to them "wait 3
weeks, hoping for the next one to fix it and not to add new bugs !". I'd really
prefer to reply "you idiot, return to kernel.org and get the next one or send a
patch, Marcelo wouldn't let his kernel in this state".
Regards,
Willy
On Tue, May 27, 2003 at 01:35:09AM +0100, Alan Cox wrote:
> One thing I will say however - I'd have done the *same* thing as Marcelo
> with aic7xxx during -rc which is to defer it.
I think you would at least have forwarded problem reports to Justin, expecting
him to look into the problem first.
I don't reproach Marcelo of not including the last aic7xxx driver in mainline,
but of reverting an enormous amount of code at the last minute without prior
asking the maintainer if he has an idea about the problem people encounter. Of
course, if he hasn't, the driver has to be removed, but he gave him no chance
to fix it, nor any detail about who had problems and what type of problems they
had. And reverting to what it was in 2.4.20 is not safer than trying to fix,
since other code touched in 2.4.21 may bring side effects (APIC ?) which might
explain why it doesn't work for some people.
> The simple truth is that when you give something to 10,000 users instead of
> 20 something breaks. Its not that authors suck its just another testimony to
> the fact computer programming is still firmly at the alchemy not the
> chemistry end of its history.
and that computer makers can't read the specs !
> If the driver works well fine, but maintainers don't have the ability to
> see into the future either.
It reminds me that I often worry when one of my programs runs right on the
first compilation, because it doesn't give me the opportunity of puting my
nose into sensible places where I could find obvious bugs :-)
Regards,
Willy
On Tue, 27 May 2003, Willy Tarreau wrote:
> On Tue, May 27, 2003 at 01:35:09AM +0100, Alan Cox wrote:
>
> > One thing I will say however - I'd have done the *same* thing as Marcelo
> > with aic7xxx during -rc which is to defer it.
>
> I think you would at least have forwarded problem reports to Justin,
> expecting him to look into the problem first.
Justin used to say "use my latest driver" when people reported problems.
Read lkml.
Its great if Justins new driver fixes the problems, but as I told him I
thought it was too late for it to be included. Thats my bad, too, because
if I had included it early in 2.4.21pre it could be in now.
Justin could well have fixed the problems in the current driver instead
answering "use my latest driver", couldnt he?
On Tue, May 27, 2003 at 01:47:13AM -0300, Marcelo Tosatti wrote:
> Justin used to say "use my latest driver" when people reported problems.
> Read lkml.
I agree, but honnestly, when a driver author remembers about hundreds of bugs
fixed between the version the user complains about and the last one, it's
difficult to point the real problem, and then to say to this people "just
apply this little fix for this particular bug, and cross your fingers not to
be caught by the 99 others".
> Justin could well have fixed the problems in the current driver instead
> answering "use my latest driver", couldnt he?
I think he could have tried to fix the most obvious ones and then say
"Marcelo, my old driver is plain buggy, here are a few fixes for the
complainers, but it's about to explode, please plan on a full upgrade soon".
Anyway, what is done is done. It's nonsense always talking about the past,
we'd all better spend our time fixing bugs.
Regards,
Willy
Willy Tarreau <[email protected]> wrote:
> On Tue, May 27, 2003 at 01:35:09AM +0100, Alan Cox wrote:
>
> > One thing I will say however - I'd have done the *same* thing as
> > Marcelo with aic7xxx during -rc which is to defer it.
>
> I think you would at least have forwarded problem reports to
> Justin, expecting him to look into the problem first.
As the one who started this discussion... I'd simply like to quote this and say:
_FULL_ ack!
[ ... ]
I also changed the whole server (the one which had the aix7xxx problems) in the
meantime... Changed the Adaptec 2940, now there is a Adaptec 29160. I switched
from a Dual-P3 to a P4. And well, the interessting part, I switched from
2.4.20(-XX) to 2.4.19. EVERYTHING runs faster and stable now!
Best regards,
Oliver
On Tuesday 27 May 2003 10:38, Oliver Pitzeier wrote:
Hi Oliver,
> I also changed the whole server (the one which had the aix7xxx problems) in
> the meantime... Changed the Adaptec 2940, now there is a Adaptec 29160. I
> switched from a Dual-P3 to a P4. And well, the interessting part, I
> switched from 2.4.20(-XX) to 2.4.19. EVERYTHING runs faster and stable now!
try 2.4.18 and you'll maybe s/faster/"fuck damn fast as speed of light"/
;)
ciao, Marc
>Justin used to say "use my latest driver" when people reported
>problems. Read lkml.
Probably he said that but he also answer its mail and offer support when
someone spend time and tries to accurately report problem. I have been a
long time aic7xxx users (both on professionnal multiprocessor servers
and on my home machine) and Justin provided helps. And now, I have no
more problem altthough I sometime puts GB on a streamer.
>Its great if Justins new driver fixes the problems, but as I told him I
>thought it was too late for it to be included. Thats my bad, too,
> because if I had included it early in 2.4.21pre it could be in now.
Well, I reported the bug as soon as alan included them in 21-pre7-acxx
and mentionned that the bug was fixed for me in newer justin release.
>Justin could well have fixed the problems in the current driver instead
>answering "use my latest driver", couldnt he?
No!. Why should he do that? Either you trust the maintainer and give him
a chance to have its driver more widely tested by including it in stable
kernel upon request. Here you just have applied alan patch without even
searching (I mean asking justin) if this was the right version to
include, thinking that it had already received some testing via alan...
What worries me the most with the current 2.4 status is that if you want
to sell linux to manager, sys admin or anyone who can pay the bills you
face immediately the following problems :
- For server, you need to start applying patches for aic7xx or risk
deadlock or even fail to boot, and probably other SMP race things due to
the 2.4 evolution slowness. As far as I know dell use aic7XXX adapter in
its server line (no word about SCSI RAID drivers...). Of course IDE
cleaning is important for desktop and laptop users but not so much for
servers,
- For laptop, even if IDE seems to be OK, 2.4 is almost unusable
without ACPI patches as you risk to damage your laptop with overheat
5ACPI controlled fan) or not manage IRQ routing correctly or have dead
keys. Then you also need some FB driver update, ... I do not even
mention PPC laptops...
So, besides your availability, which I would regard as something that
may be behond your real control, I would rather suggest to clearly
define priorities for *next* 2.4 kernel so that you can use your spare
time to make 2.4 unpatched usefull again.
-- eric running on 2.4.21-rc2-ac3 + NTFS patches + ACPI update + ...
Marc-Christian Petersen <[email protected]> wrote:
> On Tuesday 27 May 2003 10:38, Oliver Pitzeier wrote:
> > I also changed the whole server (the one which had the aix7xxx
> > problems) in the meantime... Changed the Adaptec 2940, now
> there is a
> > Adaptec 29160. I switched from a Dual-P3 to a P4. And well, the
> > interessting part, I switched from 2.4.20(-XX) to 2.4.19.
> EVERYTHING
> > runs faster and stable now!
> try 2.4.18 and you'll maybe s/faster/"fuck damn fast as speed
> of light"/
Thanks Marc-Christian!
This is what I'll try on my development server. :-) And then I may switch at the
production system as well. :-)
Best regards,
Oliver
On Tue, 27 May 2003, Oliver Pitzeier wrote:
> Willy Tarreau <[email protected]> wrote:
> > On Tue, May 27, 2003 at 01:35:09AM +0100, Alan Cox wrote:
> >
> > > One thing I will say however - I'd have done the *same* thing as
> > > Marcelo with aic7xxx during -rc which is to defer it.
> >
> > I think you would at least have forwarded problem reports to
> > Justin, expecting him to look into the problem first.
>
> As the one who started this discussion... I'd simply like to quote this and say:
>
> _FULL_ ack!
>
> [ ... ]
>
> I also changed the whole server (the one which had the aix7xxx problems) in the
> meantime... Changed the Adaptec 2940, now there is a Adaptec 29160. I switched
> from a Dual-P3 to a P4. And well, the interessting part, I switched from
> 2.4.20(-XX) to 2.4.19. EVERYTHING runs faster and stable now!
Oliver,
Does 2.4.21-rc5 work for you?
On 24 May 2003, James Bottomley wrote:
> The argument isn't about size, it's about safety. No company that wants
> to stay in business accepts code into release stabilisation unless it's
> clearly justifiable. Trying to buck the system by including five
> features plus one critical bug fix is one of the oldest tricks in the
> Software Engineers book---do this and you get hauled before the release
> committee whose job will be to pare the addition back to just the bug
> fix (and send you away with a flea in your ear to boot).
That's nice when someone is working for you. In this case I believe there
were multiple bugs, and the viable choices were to ship with the old known
bugs or do testing on the new version until it is accepted as tested.
Given that the release schedule seems to be measures in generations these
days, shipping a driver known to be bad is probably worse than doing one
more rc and asking people to beat hell out of the driver.
>
> > I wish Justin would have proposed a little patch to fix only the locking bugs
> > in -rc1, but honnestly, why should he fix only these bugs when he knows about
> > others that must be fixed too ? I can understand he gives up. -rc is for bug
> > fixes, and his bug fixes are reverted !
>
> Marcelo reacted exactly as the release committee would at Adaptec:
> either provide the bug fix for assessment or we'll push it out into the
> next release. This is industry standard practice, so I don't see any
> problem.
I bet your release schedule is more frequent, too. There comes a time when
doing a whole new QA is better than trying to be sure a fix works without
doing full QA anyway. As in both faster and more likely to result in a
correct result.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Sat, 24 May 2003, Pascal Schmidt wrote:
> On Fri, 23 May 2003 22:30:17 +0200, Willy Tarreau wrote in lkml:
>
> > By this time, there will be more and more people leaving vanilla kernel for
> > their machines, and using them only as a base to apply -aa, -ac, -jam, -wolk,
> > -** + sf.net/* + who_knows_what, and I find it a shame.
>
> I think you overestimate the number of aic7xxx users. It's not like
> 99% of all 2.4 users need the driver.
Conversely I would bet that somewhere >25% of all SCSI users need that
driver. It depends on how you want to look at it.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
Hi Marcello!
Marcello Tosatti wrote:
[ ... ]
> > I also changed the whole server (the one which had the aix7xxx
> > problems) in the meantime... Changed the Adaptec 2940, now
> > there is a
> > Adaptec 29160. I switched from a Dual-P3 to a P4. And well, the
> > interessting part, I switched from
> > 2.4.20(-XX) to 2.4.19. EVERYTHING runs faster and stable now!
>
> Does 2.4.21-rc5 work for you?
Blame me for this! I was very busy the last few weeks, that's why I answer this
mail soooooo late. Because I have the machine now at home and no longer in a
production environment, I'm able to test everything...
(FYI. The P4 machine still runs stable. :-) ).
I'll try the latest kernel 2.4.22-pre1 on the dual-machine and tell you if it
runs stable or not. I believe there are not too much people who have a Dual-PIII
with an Adaptec controller...(!?)
However...
Keep on going!
Best regards,
Oliver