So here goes the first pre of 2.4.21 including the new IDE code merged
from Alan's tree.
Test it carefully, since the new IDE code is not yet fully tested.
Do not use it with critical data.
Summary of changes from v2.4.20 to v2.4.21-pre1
============================================
<[email protected]>:
o usbdevfs: finalize urbs on interface release
o usbdevfs: finalize urbs on interface release
o usbdevfs: more list cleanups
<[email protected]>:
o [SPARC]: Add missing iounmap to display7seg driver
<[email protected]>:
o RATOC USB-60 patch
<[email protected]>:
o efirtc update
<[email protected]>:
o USB: added support for Palm Tungsten T devices to visor driver
<[email protected]>:
o USB ipaq: brown paper bag bug - uninitialized spinlock fixed
o USB ipaq: added support for insmod options to specify vendor/product id
<[email protected]>:
o [netdrvr tulip] new pci id
<[email protected]>:
o [PATCH 2.4.20-rc1] scanner.h: add/fix vendor/product ids
<[email protected]>:
o ide-scsi update to new IDE
o Remove IDE init calls from blk_dev_init (IDE merge)
o Add missing system.h bits (IDE merge)
<[email protected][holtmann]>:
o [Bluetooth] Add RFCOMM protocol support
o [Bluetooth] UART driver update
o [Bluetooth] Add HCI UART PC Card driver
o [Bluetooth] Add BCSP TXCRC option
<[email protected]>:
o AGP support for VIA KT400
<[email protected]>:
o use of unplugged scanner oops fix
<[email protected]>:
o USB: pegasus: the kmalloc/kfree crap removed from [get|set]_registers();
<[email protected]>:
o usb-midi patch for 2.4.20-pre11
<[email protected]>:
o [netdrvr starfire] add netif_carrier_{on,off} calls
<[email protected]>:
o sonypi driver update
o meye driver update
o export pci symbols for pcmcia modules
<[email protected]>:
o usb-uhci, fixed memory leak with one-shot interrupt transfers
<[email protected]>:
o USB: add USB powermate driver
<[email protected]>:
o [netdrvr de620] remove unneeded, and ifdef'd out, check_region call
Adam Kropelin <[email protected]>:
o [netdrvr ewrk3] fix and enable ethtool phys-id ioctl
o [netdrvr ewrk3] allow user to change MAC address via SIOCSIFHWADDR
Adrian Bunk <[email protected]>:
o CONFIG_AGP_AMD_8151 Configure.help entry
o Fix pcmcia_net link error
Alan Cox <[email protected]>:
o ppc stuff for new ide layer
o update mousedriver docs as in 2.5
o bring loop device up to date
o parisc mux console config
o add scx200 drivers
o work around ALi magick chipset hangs with video capture
o fix cyclades resource handling
o vendor update for mpt fusion
o pcmcia networking updates
o lanstreamer updates
o pcmcia parport update
o new pci ids
o reserve some I/O ports on the ATI radeon IGP
o new pci idents
o pcmcia core updates from David Hinds
o backport 2.5 advansys off by one fix
o ac IDE merge
o t128 compile fix if non modular
o core code for new nsp32 driver
o fix ac97 string formatting errors
o fix mad16 bugs
o some laptops need longer delay
o make cdcether work
o latest i810 audio update
o BeOS fs updates
o fix off by one in module loader rename of module
o work around 8253 timer funnies
o ensure memcpy_to/from_io don't prefetch
o Sort out the tachyon driver
Andrew Morton <[email protected]>:
o Fix for the ext3 data=journal unmount problem
Arnaldo Carvalho de Melo <[email protected]>:
o Add support for JTEC FA8101 USB to Ethernet device
Charles White <[email protected]>:
o Add support for the SA641, SA642 and SA6400 controllers
Christoph Hellwig <[email protected]>:
o small sd error handling fix
o update scsi largelun blacklist
o make flock Posix 2001 compatible
Christoph Hellwig <[email protected]>:
o cleanup b_inode usage and fix onstack inode abuse
o backport 2.5 inode allocation changes
o fix memory leak in sd.c
Dave Jones <[email protected]>:
o Intel cache handling fixes
Dave Kleikamp <[email protected]>:
o Add more statistics to /proc/fs/jfs/ to help with performance tuning
o JFS: Avoid writing partial log pages for lazy transactions
o JFS: forced metadata pages were not being flushed to disk
o jfs_clear_inode should skip bad inodes instead of choking on them
o JFS: Move index table out of directory inode's address space
o JFS: Fix off-by one error when symlink size == 256 bytes
o JFS: flush pending commit records to journal during unmount
o jfs_truncate needs to call block_truncate_page
David Brownell <[email protected]>:
o usbnet talks to Zaurus
David Brownell <[email protected]>:
o USB: USB 2.0 controller and hubs bugfixes
David S. Miller <[email protected]>:
o [SPARC]: Ignore SIGURG if not caught
o [SPARC]: NR_IRQS is off by one
o [SPARC64]: Fix dnotify_parent call in do_readv_writev32
o [SPARC64]: Add some missing semicolons newer gcc warns about
o [SPARC64]: Add -finline-limit=100000 to CFLAGS if gcc supports it
o [SPARC64]: Clobber register l1 in switch_to if gcc >= 3.0
o [SPARC]: Synchronize MAINTAINERS entry with 2.5.x
o [SPARC]: Fix dependency on previous NR_IRQS value
o [SPARC64]: Export __flush_dcache_range
o [SPARC64]: Update defconfig
o [SPARC]: Implement local_irq_set
o [SPARC64]: Fix read_pil_and_sti
Edward Peng <[email protected]>:
o dl2k net driver update from vendor
o [netdrvr dl2k] only read 0x100 through 0x150 statistics registers if mem mapping
Eric Brower <[email protected]>:
o [SPARC]: Make APC idle a boot time cmdline option
Greg Kroah-Hartman <[email protected]>:
o Cset exclude: [email protected]|ChangeSet|20021011180213|25533
o USB: added support for Clie NX60 device
o removed vicamurbs.h
o USB: added Palm Tungsten W support
Ivan Kokshaysky <[email protected]>:
o alpha: alcor and sable fixes
o alpha misc fixes
o alpha initrd fix
o asm-alpha/regdef.h
o alpha __stxncpy fixes
o Fixup Alpha IDE PCI
Jeff Garzik <[email protected]>:
o Add 00-INDEX file describing contents of Documentation/BK-usage directory
o Small clarification in BK kernel howto
o In several drivers, use pci_[gs]et_drvdata instead of directly referencing struct pci_dev::driver_data.
o [net drivers] update hamachi and starfire to use MII lib
o Update my email address
o Remove performance barrier in i810_rng char driver
o [netdrvr bmac] remove init_timer call that was erroneously removed
o [netdrvr fealnx] remove bogus line due to patch error
o [netdrvr] add "r8169", a new Realtek 8169 gigabit ethernet driver
o [netdrvr r8169] large style cleanup
o [netdrvr r8169] minor functional cleanups and bug fixes
o Handle internal proc_register failure in proc_symlink, proc_mknod, proc_mkdir, and create_proc_entry.
o [netdrvr] Make a special section in drivers/net/Makefile for
o [netdrvr sunhme] remove memset in init, alloc_etherdev does it for us
o [netdrvr] fix Stanford checker buffer overflows in ni52, 3c523 (rarely if ever would be hit)
o [netdrvr 3c515] fix unlikely buffer overrun when >8 adapters present
o [netdrvr] zap PCI_VPD_ADDR constants from skfp, sk98lin drivers
o [netdrvr r8169] use pci_[gs]et_drvdata instead of pdev->driver_data
o Clarify locking/context docs for network interfaces, in Documentation/networking/netdevices.txt.
Joe Burks <[email protected]>:
o Vicam patch against 2.4.20-pre9
John Stultz <[email protected]>:
o Summit chipset support: Clustered apic tweaks
o Summit chipset support: Logical/Physical apicid additions
o Summit chipset support: CLUSTERED_APIC_XAPIC switches
o Summit chipset support: CONFIG_X86_SUMMIT, auto-detection, cleanup
Juan Quintela <[email protected]>:
o Fix journalling api documentation
Kent Yoder <[email protected]>:
o [netdrvr lanstreamer] a fix and a feature addition
Maksim Krasnyanskiy <[email protected]>:
o RFCOMM TTY fixes
o BNEP fixes
o HCI UART fixes
o Fix typo in hci_usb_open() (MAX_BULK_TX -> MAX_BULK_RX)
o Fix L2CAP client/server PSM clash
o Fix hci_dev_get_list() for big endian machines
o Ordinary users are not allowed to use raw L2CAP sockets
o BNEP extension headers handling fix
Manfred Spraul <[email protected]>:
o [netdrvr 8139too] skb_copy_and_csum_dev use allows us to enable the NETIF_F_HIGHDMA feature.
Marcel Holtmann <[email protected]>:
o [Bluetooth] Module description cleanup for BNEP
o [Bluetooth] Config cleanup for BNEP
o [Bluetooth] Add HCI id for Bluetooth PCI cards
o [Bluetooth] Support for suspend/resume interface for HCI devices
o [Bluetooth] Fix typo in role change event size
o [Bluetooth] Cosmetic changes to the config files
o [Bluetooth] Initialize hardware broadcast
o [Bluetooth] Check for signals while waiting for DLC
o [Bluetooth] Fix operator precedence for modem status
o [Bluetooth] Don't do wakeup if protocol is not set
o [Bluetooth] Fix some bits of the modem status handling
o [Bluetooth] Free skbs with kfree_skb() instead of kfree()
o [Bluetooth] Fix another operator precedence for modem status
o [Bluetooth] Update help entry for CONFIG_BLUEZ
o [Bluetooth] The function l2cap_do_connect() should be static
o [Bluetooth] Don't use %d notation for non devfs name field of tty_driver
o Disable bluetooth.o if Bluetooth subsystem is used
Marcelo Tosatti <[email protected]>:
o megaraid driver update
o Update gdth driver
o Cset exclude: [email protected]|ChangeSet|20021202135530|52474
o Backout wrong change of gdth update
o Cset exclude: [email protected]|ChangeSet|20021129142249|58780
o Add missing x86 system.h bits from IDE -ac merge
o Changed EXTRAVERSION to -pre1
o Cset exclude: [email protected]|ChangeSet|20021210155107|09736
o Cset exclude: [email protected]|ChangeSet|20021210165533|06540
Matt Domsch <[email protected]>:
o aacraid Dell PERC 320/DC support
Matthew Wilcox <[email protected]>:
o update lasi_82596 net driver to use spinlock instead of cli/sti
o Add PCI-X register definitions
Olaf Hering <[email protected]>:
o minor fixes for compile warnings in 2.4.20pre11 , usb-2.4 tree
Pete Zaitcev <[email protected]>:
o [SPARC]: Clobber l3 in context switch
o [SPARC]: kill NR_IRQS + 1 stuff
Randy Dunlap <[email protected]>:
o USB: use time_before() to compare times
o tiglusb timeouts
Randy Dunlap <[email protected]>:
o USB requires MIDI
Richard Henderson <[email protected]>:
o [ALPHA] Add local_irq_set
o [ALPHA] Fix asm clobber problem diagnosed by current gcc 3.3 snap
o CREDITS
Rob Radez <[email protected]>:
o [SPARC]: Fix loop terminator in iommu_get_scsi_sgl_pflush
Roger Luethi <[email protected]>:
o [netdrvr ns83820] fix oops in ioctl, and initialize dev->priv to prevent such slipups again
o [netdrvr via-rhine] version bump, C99 initializers
o [netdrvr via-rhine] fix up strange C99 notation in previous patch
Rolf Eike Beer <[email protected]>:
o Kill unneeded declaration from drivers/scsi/sim710.h
Romain Lievin <[email protected]>:
o USB: tiglusb sync with 2.5
Scott Feldman <[email protected]>:
o e100 net driver: remove driver-isolated flag/lock
Takayoshi Kouchi <[email protected]>:
o ACPI PCI hotplug updates
Tim Waugh <[email protected]>:
o 2.4.20: fix aladdin card hang
On Tue, Dec 10, 2002 at 06:37:14PM -0200, Marcelo Tosatti wrote:
> So here goes the first pre of 2.4.21 including the new IDE code merged
> from Alan's tree.
>
> Test it carefully, since the new IDE code is not yet fully tested.
>
> Do not use it with critical data.
>
> Summary of changes from v2.4.20 to v2.4.21-pre1
> ============================================
>...
> Alan Cox <[email protected]>:
>...
> o ac IDE merge
>...
The ac IDE merge broke the compilation of hd.c (it was already broken in
ac):
<-- snip -->
...
gcc -D__KERNEL__ -I/home/bunk/linux/kernel-2.4/linux-2.4.20/include
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing
-fno-common -pipe -mpreferred-stack-boundary=2 -march=k6 -I../
-nostdinc -iwithprefix include -DKBUILD_BASENAME=hd -c -o hd.o hd.c
hd.c:78: conflicting types for `recal_intr'
/home/bunk/linux/kernel-2.4/linux-2.4.20/include/linux/ide.h:1487:
previous declaration of `recal_intr'
hd.c: In function `dump_status':
hd.c:171: `QUEUE_EMPTY' undeclared (first use in this function)
hd.c:171: (Each undeclared identifier is reported only once
hd.c:171: for each function it appears in.)
hd.c:171: `CURRENT' undeclared (first use in this function)
hd.c:169: warning: `devc' might be used uninitialized in this function
hd.c: In function `hd_out':
hd.c:284: `DEVICE_INTR' undeclared (first use in this function)
hd.c:284: `TIMEOUT_VALUE' undeclared (first use in this function)
hd.c: In function `do_reset_hd':
...
make[4]: *** [hd.o] Error 1
make[4]: Leaving directory `/home/bunk/linux/kernel-2.4/linux-2.4.20/drivers/ide/legacy'
<-- snip -->
cu
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
>The ac IDE merge broke the compilation of hd.c (it was already broken in
>ac):
><-- snip -->
Hmm.. I was able to build it with no problem. Can you
post your .config??
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
On Tue, 10 Dec 2002, Marcelo Tosatti wrote:
> So here goes the first pre of 2.4.21 including the new IDE code merged
> from Alan's tree.
>
> Test it carefully, since the new IDE code is not yet fully tested.
>
> Do not use it with critical data.
Oh, speaking of "carefully", could Andrew Morton's mount -o dirsync
feature patch for 2.4.21 please be merged early in v2.4.21-pre? User
space (util-linux, e2fsprogs' lsattr/chattr) has been supporting it for
a while, just the kernel lacked it.
This -o dirsync feature is necessary to give applications that are
either unaware of Linux' default -o async or that do not want to cater
for deliberate incompatibilities a big performance boost: these
applications (Postfix on ext2fs but not on 2.4 ext3fs or reiserfs, qmail
on any Linux fs, probably a lot others I haven't even looked at)
traditionally *require* chattr +S or mount -o sync to work reliably,
after the merge, they could instead go with mount -o dirsync or chattr
+D, which improves write speed quite a bit.
Not applying the dirsync patch means that a stupid BSD ffs in default
configuration will beat Linux (that needs -o sync) hands-down without
any tuning the admin could do. One might also consider making -o dirsync
the default while one's there, to give users a default-reliable setting,
but this is going to rouse the performance fetishists who don't care
about data persistence and who don't care to collect their new files
from lost+found on ext2fs but rather cheat benchmarks.
I can elaborate a bit more, but this has been discussed multiple times
and after all, the code is there.
> Summary of changes from v2.4.20 to v2.4.21-pre1
...
* Marcelo Tosatti <[email protected]>:
> So here goes the first pre of 2.4.21 including the new IDE code merged
> from Alan's tree.
>
> Test it carefully, since the new IDE code is not yet fully tested.
And, alas, I do have problems with exactly that code. Background:
I've been trying the -ac kernels for quite some time now, but on my
new Toshiba Satellite Pro 6100 they all fail miserably.
I made three screenshots which illuminate the problem:
http://www.stahl.bau.tu-bs.de/~hildeb/kernel/
* 2.4.20/2.4.19/2.4.20-ck1 all boot OK, the old IDE code detects my drives.
* 2.4.19-acX, 2.4.20-ac1 or 2.4.21-pre1 boot, but then fail to detect my drives.
My /etc/lilo.conf contains as addiditonal boot parameters only:
append="hdc=ide-scsi max_scsi_luns=1 video=vesa:ywrap,mtrr"
lspci reports:
00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04)
00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04)
00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BAM/CAM PCI Bridge (rev 42)
00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio (rev 02)
00:1f.6 Modem: Intel Corp. 82801CA/CAM AC'97 Modem (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go] (rev a3)
02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) Chipset Ethernet Controller (rev 42)
02:0a.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01)
02:0b.0 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to Cardbus Bridge with ZV Support (rev 32)
02:0b.1 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to Cardbus Bridge with ZV Support (rev 32)
02:0d.0 System peripheral: Toshiba America Info Systems: Unknown device 0805 (rev 03)
--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
"Looking at the proliferation of personal web pages on the net, it
looks like very soon everyone on earth will have 15 Megabytes of fame."
-MG Siriam
On Wednesday 11 December 2002 09:55, Matthias Andree wrote:
Hi Matthias,
> Oh, speaking of "carefully", could Andrew Morton's mount -o dirsync
> feature patch for 2.4.21 please be merged early in v2.4.21-pre? User
> space (util-linux, e2fsprogs' lsattr/chattr) has been supporting it for
> a while, just the kernel lacked it.
> I can elaborate a bit more, but this has been discussed multiple times
> and after all, the code is there.
sorry, where can we find it?
ciao, Marc
--
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.
On Wed, 2002-12-11 at 09:08, Ralf Hildebrandt wrote:
> 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04)
> 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04)
> 00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02)
> 00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02)
> 00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02)
Drive and controllers are what ?
* Alan Cox <[email protected]>:
> On Wed, 2002-12-11 at 09:08, Ralf Hildebrandt wrote:
> > 00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 04)
> > 00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 04)
> > 00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02)
> > 00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02)
> > 00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02)
>
> Drive and controllers are what ?
According to the 2.4.20 kernel (see
http://www.stahl.bau.tu-bs.de/~hildeb/kernel/2.4.20.jpg for a snapshot
of the boot process!) the drives are:
hda: TOSHIBA MK4019GAX, ATA DISK drive
hdc: TOSHIBA DVD-ROM SD-R2102, ATAPI CD/DVD-ROM drive
And the controller:
ICH3M: chipset revision 2
--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
* Ralf Hildebrandt <[email protected]>:
> According to the 2.4.20 kernel (see
> http://www.stahl.bau.tu-bs.de/~hildeb/kernel/2.4.20.jpg for a snapshot
> of the boot process!) the drives are:
>
> hda: TOSHIBA MK4019GAX, ATA DISK drive
> hdc: TOSHIBA DVD-ROM SD-R2102, ATAPI CD/DVD-ROM drive
>
> And the controller:
> ICH3M: chipset revision 2
More details (lspci -vv):
00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) (prog-if 8a [Master SecP PriP])
Subsystem: Toshiba America Info Systems: Unknown device 0001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at cff8 [size=8]
Region 1: I/O ports at cff4 [size=4]
Region 2: I/O ports at cfe8 [size=8]
Region 3: I/O ports at cfe4 [size=4]
Region 4: I/O ports at cfa0 [size=16]
Region 5: Memory at 10000000 (32-bit, non-prefetchable) [size=1K]
--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
Why you can't find your system administrators:
The Cray's Chiller decided to go on vacation, and (S)he got stuck to one of the vents on the Y-MP after switching to air-cooled mode.
--Jeff Wolfe [email protected]
Ok this seems to be the problem
00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) (prog-if
8a [Master SecP PriP])
Subsystem: Toshiba America Info Systems: Unknown device 0001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at cff8 [size=8]
Region 1: I/O ports at cff4 [size=4]
Region 2: I/O ports at cfe8 [size=8]
Region 3: I/O ports at cfe4 [size=4]
The hardware isnt at the normal ide base addresse, yet the chip is
reporting that it isnt in native mode. As far as I can see this
configuration isnt allowed.
We see that the chip isnt in native mode so we defer to the legacy
scanner. Since the ports are not valid the legacy scanner doesn't find
them.
Any thoughts on how we should handle this case Andre ?
Alan
On 11 Dec 02 at 17:29, Alan Cox wrote:
> Ok this seems to be the problem
>
> 00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) (prog-if
> 8a [Master SecP PriP])
> Subsystem: Toshiba America Info Systems: Unknown device 0001
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Interrupt: pin A routed to IRQ 11
> Region 0: I/O ports at cff8 [size=8]
> Region 1: I/O ports at cff4 [size=4]
> Region 2: I/O ports at cfe8 [size=8]
> Region 3: I/O ports at cfe4 [size=4]
>
>
> The hardware isnt at the normal ide base addresse, yet the chip is
> reporting that it isnt in native mode. As far as I can see this
> configuration isnt allowed.
An old, pre-BMDMA, "PCI IDE Controller Specification, rev 1.0, 3/4/94"
I have here says on page 3, in chapter 2.4, second and third paragraphs say:
--
When a channel is in 'compatibility' mode, the controller can either
disable the first four Base Address registers (i.e.; make them not
writable and return 0's when read) or leave them fully programmable. In
either case the values in these registers are ignored as long as the
channel is in 'compatibility' mode.
When a channel is in compatibility mode the IRQ used by the channel
must be the 'compatibility' IRQ. PCI interrupt lines must not be effected
by that channel's interrupt. Conversely, when the channel is in native-PCI
mode the channel's interrupt should be connected to the appropriate INTx#.
Compatibility IRQs should not be effected (i.e.; they should be tristated).
--
> We see that the chip isnt in native mode so we defer to the legacy
> scanner. Since the ports are not valid the legacy scanner doesn't find
> them.
>
> Any thoughts on how we should handle this case Andre ?
We should ignore BARs (and reported INT#) when chip is not in native mode,
but I'm sure that it breaks something else (note that I do not know any
chip which honors BARs when using compatible mode; only problematic piece
of hardware I know is PDC20265, but this one does not report itself
as IDE hardware, so for this chip we have special cases in the code already;
maybe VIA uses IRQ number specified in PCI config space instead of
14/15?).
Petr Vandrovec
[email protected]
On Tue Dec 10, 2002 at 06:37:14PM -0200, Marcelo Tosatti wrote:
>
> So here goes the first pre of 2.4.21 including the new IDE code merged
> from Alan's tree.
>
> Test it carefully, since the new IDE code is not yet fully tested.
A few off things here...
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20267: IDE controller at PCI slot 00:0b.0
PDC20267: chipset revision 2
PDC20267: not 100%% native mode: will probe irqs later
PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0xb800-0xb807, BIOS settings: hde:DMA, hdf:DMA
ide3: BM-DMA at 0xb808-0xb80f, BIOS settings: hdg:pio, hdh:pio
VP_IDE: IDE controller at PCI slot 00:11.1
PCI: No IRQ known for interrupt pin A of device 00:11.1.
VP_IDE: chipset revision 6
VP_IDE: not 100%% native mode: will probe irqs later
VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
ide0: BM-DMA at 0xbc00-0xbc07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xbc08-0xbc0f, BIOS settings: hdc:DMA, hdd:DMA
hda: IC35L080AVVA07-0, ATA DISK drive
hdb: IC35L040AVER07-0, ATA DISK drive
hda: DMA disabled
^^^^^^^^^^^^^^^^^
What's up with this? For each drive in my system it claims it
has disabled DMA. But hdparm later reports that DMA is in fact
enabled. In fact, later on the kernel ever reports the drive
as being in UDMA 100 mode... I think these "DMA disabled"
messages are bogus.
blk: queue c03c4a00, I/O limit 4095Mb (mask 0xffffffff)
hdb: DMA disabled
^^^^^^^^^^^^^^^^^
blk: queue c03c4b4c, I/O limit 4095Mb (mask 0xffffffff)
hdc: PCRW804, ATAPI CD/DVD-ROM drive
hdd: Pioneer DVD-ROM ATAPIModel DVD-116 0122, ATAPI CD/DVD-ROM drive
hdc: DMA disabled
hdd: DMA disabled
^^^^^^^^^^^^^^^^^
hde: IC35L040AVER07-0, ATA DISK drive
hde: DMA disabled
^^^^^^^^^^^^^^^^^
Yet more bogus DMA disabled messages....
blk: queue c03c52d8, I/O limit 4095Mb (mask 0xffffffff)
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0x1800-0x1807,0xac02 on irq 11
hda: host protected area => 1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=10011/255/63, UDMA(100)
Now we see the funky "host protected area => 1" message. As
discussed earlier with Andre, this message should be removed from
the kernel. The message as written implies that the drive
actually has an active HPA -- which is not the case at all! All
this is doing is enumerating support for a particular drive
feature. Do we really care that the drive has Host Protected
Area feature set support? I don't care. I suppose it might be
interesting to note if there is actually an HPA in effect, but
this as is the message is just noise. If we are going to
enumerate drive capabilities, why not useful ones like the Power
Management feature set, or the Power-Up In Standby feature set...
I think we should kill the "host protected area => 1" message. If
people care about their drives supported feature set, they can
run 'hdparm -I' to find this out,
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
On Thu, 2002-12-12 at 01:35, Erik Andersen wrote:
> hda: DMA disabled
> ^^^^^^^^^^^^^^^^^
>
> What's up with this? For each drive in my system it claims it
> has disabled DMA. But hdparm later reports that DMA is in fact
> enabled. In fact, later on the kernel ever reports the drive
> as being in UDMA 100 mode... I think these "DMA disabled"
> messages are bogus.
Cosmetic and known. It in fact turns DMA back on - quietly
> ide2 at 0x1800-0x1807,0xac02 on irq 11
> hda: host protected area => 1
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=10011/255/63, UDMA(100)
>
> Now we see the funky "host protected area => 1" message. As
> discussed earlier with Andre, this message should be removed from
> the kernel. The message as written implies that the driv
Before 2.4.21 agreed
On Tue, Dec 10, 2002 at 07:58:37PM -0800, Alex Davis wrote:
> >The ac IDE merge broke the compilation of hd.c (it was already broken in
> >ac):
>
> ><-- snip -->
>
> Hmm.. I was able to build it with no problem. Can you
> post your .config??
It's attached (it's a compile-as-much-as-possible-statically .config
to find compile errors).
cu
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
> > hda: DMA disabled
> > ^^^^^^^^^^^^^^^^^
> >
> > What's up with this? For each drive in my system it claims it
> > has disabled DMA. But hdparm later reports that DMA is in fact
> > enabled. In fact, later on the kernel ever reports the drive
> > as being in UDMA 100 mode... I think these "DMA disabled"
> > messages are bogus.
>
> Cosmetic and known. It in fact turns DMA back on - quietly
Alan, I sent you a patch fixing this last week, can resend if necessary.
--
Tomas Szepe <[email protected]>
On Fri, 2002-12-13 at 14:23, Tomas Szepe wrote:
> Alan, I sent you a patch fixing this last week, can resend if necessary.
In my queue along with some other pci fixes to sort out the mixed up
native/legacy configurations and a driver for the Triflex contributed by
Compaq
* Alan Cox <[email protected]>:
> The hardware isnt at the normal ide base addresse, yet the chip is
> reporting that it isnt in native mode. As far as I can see this
> configuration isnt allowed.
>
> We see that the chip isnt in native mode so we defer to the legacy
> scanner. Since the ports are not valid the legacy scanner doesn't find
> them.
Will the fix be for thatbe in 2.4.20-ac3 / 2.4.21-pre2?
--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
How can you have an email virus? Mail software doesn't execute code,
it just displays messages.
On Sun, 2002-12-15 at 09:56, Ralf Hildebrandt wrote:
> * Alan Cox <[email protected]>:
>
> > The hardware isnt at the normal ide base addresse, yet the chip is
> > reporting that it isnt in native mode. As far as I can see this
> > configuration isnt allowed.
> >
> > We see that the chip isnt in native mode so we defer to the legacy
> > scanner. Since the ports are not valid the legacy scanner doesn't find
> > them.
>
> Will the fix be for thatbe in 2.4.20-ac3 / 2.4.21-pre2?
Soon I hope
* Ralf Hildebrandt <[email protected]>:
> And, alas, I do have problems with exactly that code. Background:
>
> I've been trying the -ac kernels for quite some time now, but on my
> new Toshiba Satellite Pro 6100 they all fail miserably.
>
> I made three screenshots which illuminate the problem:
> http://www.stahl.bau.tu-bs.de/~hildeb/kernel/
Alan's patch in the Message with "Subject: IDE but no disks" fixes the
problem.
--
Ralf Hildebrandt (Im Auftrag des Referat V a) [email protected]
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
Real programmers never work 9 to 5. If any real programmers are around
at 9 am, it's because they were up all night.
