2.4.0-test12-pre7

2.4.0-test12-pre7

[Linus Torvalds]

The only reason for this pre7 is to resolve some warring patches in the
cs46xx driver.

		Linus


---
 - test7:
    - Kai Germaschewski: ymfpci cleanups and resource leak fixes
    - me: UHCI drivers really need to enable bus mastering.
    - Trond Myklebust: fix up nfs_writepage_sync() to not require "filp".
    - Andrew Morton: "tq_scheduler" is no more. We have keventd.
    - Nils Faerber: cs46xx sounddriver update

 - pre6:
    - Alan Cox: synch. PA-RISC arch and bitops cleanups
    - Maciej Rozycki: even more proper apic setup order.
    - Andrew Morton: exec_usermodehelper fixes
    - Adam Richter, Kai Germaschewski, me: PCI irq routing.
    - revert A20 code changes. We really need to use the keyboard
      controller if one exists.
    - Johannes Erdfelt: USB updates
    - Ralf Baechle: MIPS memmove() fix.

 - pre5:
    - Jaroslav Kysela: ymfpci driver
    - me: get rid of bogus MS_INVALIDATE semantics
    - me: final part of the PageDirty() saga
    - Rusty Russell: 4-way SMP iptables fix
    - Al Viro: oops - bad ext2 inode dirty block bug

 - pre4:
    - Andries Brouwer: final isofs pieces.
    - Kai Germaschewski: ISDN
    - play CD audio correctly, don't stop after 12 minutes.
    - Anton Altaparmakov: disable NTFS mmap for now, as it doesn't work. 
    - Stephen Tweedie: fix inode dirty block handling
    - Bill Hartner: reschedule_idle - prefer right cpu
    - Johannes Erdfelt: USB updates
    - Alan Cox: synchronize
    - Richard Henderson: alpha updates and optimizations
    - Geert Uytterhoeven: fbdev could be fooled into crashing fix
    - Trond Myklebust: NFS filehandles in inode rather than dentry

 - pre3:
    - me: more PageDirty / swapcache handling
    - Neil Brown: raid and md init fixes
    - David Brownell: pci hotplug sanitization.
    - Kanoj Sarcar: mips64 update
    - Kai Germaschewski: ISDN sync
    - Andreas Bombe: ieee1394 cleanups and fixes
    - Johannes Erdfelt: USB update
    - David Miller: Sparc and net update
    - Trond Myklebust: RPC layer SMP fixes
    - Thomas Sailer: mixed sound driver fixes
    - Tigran Aivazian: use atomic_dec_and_lock() for free_uid()

 - pre2:
    - Peter Anvin: more P4 configuration parsing
    - Stephen Tweedie: O_SYNC patches. Make O_SYNC/fsync/fdatasync
      do the right thing.
    - Keith Owens: make mdule loading use the right struct module size
    - Boszormenyi Zoltan: get MTRR's right for the >32-bit case
    - Alan Cox: various random documentation etc
    - Dario Ballabio: EATA and u14-34f update
    - Ivan Kokshaysky: unbreak alpha ruffian
    - Richard Henderson: PCI bridge initialization on alpha
    - Zach Brown: correct locking in Maestro driver
    - Geert Uytterhoeven: more m68k updates
    - Andrey Savochkin: eepro100 update
    - Dag Brattli: irda update
    - Johannes Erdfelt: USB update

 - pre1: (for ISDN synchronization _ONLY_! Not complete!)
    - Byron Stanoszek: correct decimal precision for CPU MHz in
      /proc/cpuinfo
    - Ollie Lho: SiS pirq routing.
    - Andries Brouwer: isofs cleanups
    - Matt Kraai: /proc read() on directories should return EISDIR, not EINVAL
    - me: be stricter about what we accept as a PCI bridge setup.
    - me: always set PCI interrupts to be level-triggered when we enable them.
    - me: updated PageDirty and swap cache handling
    - Peter Anvin: update A20 code to work without keyboard controller
    - Kai Germaschewski: ISDN updates
    - Russell King: ARM updates
    - Geert Uytterhoeven: m68k updates

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

Re: 2.4.0-test12-pre7

[Russell King]

Linus Torvalds writes:
>     - me: UHCI drivers really need to enable bus mastering.

But it'll already be turned on if pci_assign_unassigned_resources() is
called.  This calls pdev_enable_device for every single device, which
turns on the bus master bit in the PCI command register.

Is it intentional that pci_assign_unassigned_resources should:
1. enable all devices?
2. enable bus master on all devices?
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |         Russell King        rmk@arm.linux.org.uk      --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test12-pre7

[Linus Torvalds]

On Thu, 7 Dec 2000, Russell King wrote:
> 
> Is it intentional that pci_assign_unassigned_resources should:
> 1. enable all devices?
> 2. enable bus master on all devices?

Probably intentional, but probably for all the wrong reasons.

The device enabling is still required for all drivers that aren't PCI
aware of PCI PnP issues. And remember - that used to be pretty much every
single Linux driver out there. So a traditional Linux system pretty much
required that all the devices came up fully enabled, because most drivers
wouldn't know to enable them (as shown by the UHCI bug).

These days, we should probably remove all the logic to enable everything
in pci_assign_unassigned_resources(), because these days pretty much all
PCI drivers are supposed to know about enabling the device (otherwise they
wouldn't work in a PC PnP environment anyway).

The only special case to this rule is "legacy devices" - things like
serial ports in legacy regions, VGA consoles etc, where a driver can use
them without even being aware of the fact that the hardware may be PCI.
Those devices tend to need setup even just for booting, though, so they
tend to be enabled rather early for other reasons anyway.

So I would probably vote for getting rid of the device enables in
pci_assign_unassigned_resources() (for all the reasons already mentioned
by others - scribbling over memory due to not being quiescent etc). But
it's not worth breaking now. 2.5.x material. Most PCI drivers may already
do the right thing, but I bet that the USB driver wasn't the only one who
forgot..

		Linus

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

Re: 2.4.0-test12-pre7

[Miles Lane]

Linus Torvalds wrote:

> probably vote for getting rid of the device enables in
> pci_assign_unassigned_resources() (for all the reasons already mentioned
> by others - scribbling over memory due to not being quiescent etc). But
> it's not worth breaking now. 2.5.x material. Most PCI drivers may already
> do the right thing, but I bet that the USB driver wasn't the only one who
> forgot..

Is anyone compiling these change lists for 2.5?  I seem to see a few
of these ideas mentioned on LKML each week.  It would be nice to not
have these ideas fade away.

	Miles

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

Re: 2.4.0-test12-pre7

[Kai Germaschewski]

On Thu, 7 Dec 2000, Russell King wrote:

> Linus Torvalds writes:
> >     - me: UHCI drivers really need to enable bus mastering.
> 
> But it'll already be turned on if pci_assign_unassigned_resources() is
> called.  This calls pdev_enable_device for every single device, which
> turns on the bus master bit in the PCI command register.

Maybe I'm stating something which is obvious to everybody, but note
that pci_assign_unassigned_resources is only called from

./arch/alpha/kernel/pci.c:  pci_assign_unassigned_resources();
./arch/mips/ddb5074/pci.c:  pci_assign_unassigned_resources();
./arch/arm/kernel/bios32.c:     pci_assign_unassigned_resources();

so it looks like most archs don't use it anyway. (And that's supposedly
why pci_set_master helped people on x86)

--Kai


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

Re: 2.4.0-test12-pre7

[Tom Rini]

On Thu, Dec 07, 2000 at 08:01:13PM +0100, Kai Germaschewski wrote:

> Maybe I'm stating something which is obvious to everybody, but note
> that pci_assign_unassigned_resources is only called from

Possibly, but I don't know either. :)

> ./arch/alpha/kernel/pci.c:  pci_assign_unassigned_resources();
> ./arch/mips/ddb5074/pci.c:  pci_assign_unassigned_resources();
> ./arch/arm/kernel/bios32.c:     pci_assign_unassigned_resources();
> 
> so it looks like most archs don't use it anyway. (And that's supposedly
> why pci_set_master helped people on x86)

You're assuming all arches are up to date.  Silly you. :)  I know there's a
patch to use this for some PReP (PPC) machines.  It's quite possible other
arches might be using this but aren't synced up to Linus.

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test12-pre7 [ymfpci doesn't survive suspend to disk]

[Simon Huggins]

Hi,

On Wed, Dec 06, 2000 at 05:29:14PM -0800, Linus Torvalds wrote:
>  - test7:
>     - Kai Germaschewski: ymfpci cleanups and resource leak fixes
>  - pre5:
>     - Jaroslav Kysela: ymfpci driver

Just tried this out on my laptop and it played and didn't give strange
messages that Pete's driver did when I tried 2.2.18presummat (I can
check if it's interesting to know).

However when I then suspended the machine and resumed it sound no longer
worked.  In fact the mpg123 that I used to test it after the resume is
now just sitting there.

000  1000   387   277   9   0  1576  676 ?      S    tty1       0:00
mpg123 a.mp3

I CTRL-C'd it, it spat out:
[0:00] Decoding of a.mp3 finished.
And it's erm still sitting there.

Is this driver apm aware?

lspci says:
00:09.0 Multimedia audio controller: Yamaha Corporation YMF-744B [DS-1S Audio Controller] (rev 02)
        Subsystem: Sony Corporation: Unknown device 8072
        Flags: bus master, medium devsel, latency 64, IRQ 9
        Memory at fedf8000 (32-bit, non-prefetchable) [size=32K]
        I/O ports at fcc0 [size=64]
        I/O ports at fc8c [size=4]
        Capabilities: <available only to root>

It's been assigned interrupt 9 which is also used for the cardbus stuff.
[huggie@langly ~]$ cat /proc/interrupts
           CPU0
  0:     141136          XT-PIC  timer
  1:       3848          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  3:       2988          XT-PIC  pcnet_cs
  9:      27977          XT-PIC  Ricoh Co Ltd RL5c478 (#2), Ricoh Co Ltd RL5c478, ymfpci
 12:       3722          XT-PIC  PS/2 Mouse
 14:       4851          XT-PIC  ide0
 15:          1          XT-PIC  ide1
NMI:          0
ERR:          0

This was compiled on gcc 2.95.2 (so does that mean this bug report hits
/dev/null?)

-- 
----------( Cows turn themselves inside out all the time. -  )----------
----------(               Officer, South Park                )----------
Simon ----(                                                  )---- Nomis
                             Htag.pl 0.0.17
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test12-pre7 [ymfpci doesn't survive suspend to disk]

[Alan Cox]

> However when I then suspended the machine and resumed it sound no longer
> worked.  In fact the mpg123 that I used to test it after the resume is
> now just sitting there.

The driver does not currently support power management. In fact whoever
hacked on the include files went and put __init in there when it was left
non __init for a reason.

You have to completely reload and reinitialise the YMF-7xx cards on most laptops
over a suspend

> Is this driver apm aware?

Bingo.. its not

> 

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